Not all Place parts appearing if certain dates chosen

Gramps Version: AIO64-5.2.3-r1-aa03f5a
OS: Windows 11

Hi guys, seen some similar Questions to this, but not quite my problem, so here it goes. I was doing some experimenting within my project, making sure at different dates the relative complex characters would appear for places, as well as the changes of ownership, as the place has changed hands a lot of times.

Anyway, I noticed that the changes worked fine, up until I got past 30BC.
Before then, the location would be shown in full, and change as expected/ However, when I go beyond 30BC, only the city/locality shows, see image below to compare

I haven’t changed anything, as far as I understand it, in my methods that would make the other parts of the place show, so any advice would be welcome (can provide more images if required)

Hope you guys can help, thank you.

With the question mark showing (?), Gramps is saying there is no valid name for the event’s date. The entries in question are the Name and Alternative name entries with their date information.

Entering the date ranges using the Date editor may solve the issue if Gramps is having problems with dates entered as text.

1 Like

I don’t mind the question mark, as that provincial division doesn’t exist after a certain point in history.

My concern was more for the third entry, where none of the other elements are showing , question mark or no question mark, just the city.

I am not sure why for that one only the city is shown, whereas for the other two, I have the multiple enclosed by showing as expected (for added context, these are all the same place)

Are you using “before” date ranges in defining the Place names?

Those are NOT open-ended date types. If your Limits preferences are at the defaults of 50 years and the date condition has expired at 30 BCE, then place name will have a date condition more than 50 years later. i.e., later than “Before 20” in CE. (CE or “Common Era” is not recognized by the Date Parser.)

You’ll want to change those into a new open-ended date type created for the 5.2 release: the “To” date.

Likewise, instead of “After” date types, use the new “From”

Date Type

  • To — :zap:new for version 5.2.0: A “to” date is one that is an open-ended span as that occurs prior to a certain day, month, or year. Unlike a “before” Date type, the span is unlimited into the past.

  • From — :zap:new for version 5.2.0: A “from” date is one that is an open-ended span that following a certain day, month, or year. Unlike an “after” Date type, the span is unlimited into the future.

Since “Before” and “After” were the only options prior to 5.2, all your date-limited Place names and Enclosures will need to be revised. This seems like and ideal application for a SuperTool script. (And to create a script to assign missing Dates for Preferred place names.)

This line of inquiry raises another possible oddity… what happens to date-limited data when the Object (Event, Person name, Place name, Place enclosure, address) date is “text” and cannot be evaluated?

1 Like

@emyoulation @DaveSch
No I am not, here is a further screenshot to show how the dates and their coverage is currently shown, on the left is the third level (which will not display ?, unlike the second level) and on the right is the first level.

I must also add that the first level accurately changes depending on date, but just does not show any further levels after that, and that the second span (dubbed in language as “Ancient Egyptian (Span 2)” works fine, all levels show there, so it is not that which is causing any issue.

To add some more info, here are some dummy events that I have made

  1. The first level change
  2. An intermediate change, with multiple enclosure name changes
  3. A point after this, showing successful employment of a repeat element but with new dates
  4. A valid display of details, showing all elements changing script/language, and an accurate and expected showing of the “?” element
  5. First failure: does not show any enclosure elements immediately following change
  6. A second failure, but showing that first level accurately updated to reflect name change at that point.

For an event in 25 BCE, it appears that it should follow the enclosed by entry listed with the Latin language. I suspect (and not going to test) that Gramps is having a problem with the from 12 Aug 30BCE to 643.

Try splitting the enclosed by record into two entries. Both entries would point to the same record.

from 12 Aug 30 BCE to 12 Dec 1 BCE or from 12 Aug 30 BCE to 1 BCE

and…

from 1 to 643

1 Like

Will try that.

I do notice however that, if load from a back up or similar, Gramps does have challenges with those BC to CE dates, typically with the scenario described below.

Notably, it struggles with Estimated on spans e.g. (I have since remade it a span, but before, as the text comment shows, it makes it into a text comment)

Unfortunately that didn’t work, and my exploratory testing made it take a step backwards
See the new state currently
See that I have split BC and CE dates, as suggested

Good news, was able to self resolve it. Looks like the enclosed by functionality was not doing as I expected.

Thank you for talking me through some possibilities though,
Will keep them in mind for future dates :slight_smile:

EDIT:
So you guys can see the actual intended look :slight_smile:

1 Like

Perhaps you could tell us where the functionality differed from your expectations? (The wiki might need some clarification. Strike that… it definitely needs clarification but we need to understand what should be included.)

So, I had expected that, when adding an enclosed by (Place B) to Place A, and multiple at once, that they would automatically associate correctly.
However, it doesn’t seem that occurred, instead, I had to share the Place B’s that was enclosing A after creating them

So
Initially: Make Place A, On Enclosed By tab, make Place B,C,D, and presume that’s fine
What needed: Make Place A, Make Place B,C,D, Share B,C,D to Place A on the Enclosed By tab.

Although not sure if working as intended, that is the way that ensured that all worked. Perhaps the issue happened because added multiple enclosed by at once. I am unsure

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.