5.1.4 win10
In Reports, text reports, Record Report
If I have Oldest Living Person selected
I get people that are 120-150 years old.
If you look at the record for the person, they only have a birth date.
Is this normal?
Is there a filter missing someplace?
Can you explain how to correct this?
I think it should only report those with a DOB and DOD event.
TIA
Not obvious, but this is determined by the Date calculation preference that manages how Gramps determine if someone is alive for the reportsā¦
Keep tripping over this myself maybe a feature should be added to reports or tools with a button that links to the "Date settings used for calculation operations. " preferences?
When I run that report, I get several people who are 109 years old. They have birth dates but no death dates. So, their appearance on the report is consistent with my current preferences setting of 110 years for āMaximum age probably aliveā. (Other people in my database who have birth dates a little further in the past, and no death death dates, do not appear on the report, which is also consistent with the setting.) But in fact, none of those of people are āprobablyā alive. I think it might be more accurate if the preference setting were called āMaximum age possibly aliveā.
I set my āMaximum age probably aliveā to 100 and still get.
Oldest living person
- Campbell, Cecil Berl Lawrence (about 122 years, 14 days)
- Jones, William H (about 119 years, 14 days)
- Hughes, Mair (about 112 years, 14 days)
*** Found the issue***
These records have āabtā and āestimatedā in the DOB fields.
I believe these are acceptable words in this field.
That is what if throwing the calculation off.
Removing those works fixes the report.
You can temporary reduce the scope of the About, Before & After date range modifiers in the Dates Preferences.
Run the reports with these set to One instead of Fifty for a tighter interpretation.
When a date has about, before or after modifiers, the limits on the Preferences Date tab come into play. The default is 50 years. In essence, the year setting defines what the modifiers mean.
What this means is that if a DOB has about 1950 as its entry Gramps sees the date as anywhere between 1900 and 2000. Now add the living calculation and an age of 122 can be returned as a valid age. It can get very confusing.
These modifiers will also have meaning to filters. Ask a filter to return people born in 1970. A person with a birthday about 1920 will return as a person meeting the condition of the filter.
EDIT: And a date modifier added to a filter search parameter has the same effect. Search for DOB = about 1900 looks for dates between 1850 and 1950. Compound that with a personās date about 1800 will return as valid for the filter.
I avoid the use of āaboutā, ābeforeā and āafterā, because (1) no matter what I use in the preferences settings, it wonāt be appropriate in all cases, and (2) I donāt think those settings would appear anywhere outside of Gramps (for example, if I printed a report or exported a GEDCOM file).
Although itās more work, I feel itās safer to enter a distinct date span (my best estimate) for any case where I would otherwise use one of those terms. But mostly I leave dates blank if I donāt have a good idea of the likely range.
I too try to use between <year> and <year> especially on DOB. For death dates where the only information is the date of the will and when it was probated I enter this information with no death date. Likewise, I do not enter after <death> for burial. If I do not know the date, Iāll leave it blank.
Other genealogy programs do accept the modifiers and GEDCOM knows how to deal with them. I used PAF from LDS as my first program and migrated to Gramps with a GEDCOM. Everything came through as expected.
And I have been using reference work compiled by the New England Genealogical and Historical Society. They use the terms but often with more details included. I had one today. after 1735 as a DOB with the added explanation that the boy was underage on another date when a guardian was appointed after the fatherās death.
I changed my Before and After years to 9 and About to 4 The biggest effect for these changes is for filtering. I never use before, after or about. Always using between <year> and <year> option as the filter parameter.
Yes I know. Sorry if I wasnāt clear. What I meant is that although my use of those terms may be printed/exported, my preference settings arenāt included in that output, and so the results might be misinterpreted by recipients.
1 Like
That is actually pointed out in the GEDCOM 5.5.1 docs. It talks about how the scope is undefined.
Butā¦ a ācircaā date in the source staying an āaboutā date in the logged Event is still better than either a blank or a personal re-interpretation that contaminates the data with my bias.
Thanks for all the good answers. Iām going to adjust my preferences and make better use of before, after, between in the date fields.
I learned a lot from the discussion.
I do read the help pages, but fail to pickup the significance sometimes.
It does raise a question. If 50 years is the default in the preference table on these lines discussed, and it is a issue, why hasnāt the default been changed to 5 years??? Just a rhetorical question.
1 Like
I would prefer that Gramps took a number for āDate about rangeā, say 5, and applied it as follows:
if the date is just a year, say 1891, then about 1891 means 1886 to 1896, and
if the date is month year, say April 1891, about April 1891 means November 1890 to September 1891
if the date is day month year, say 10 April 1891, about 10 April 1891 means 5 April 1890 to 15 April 1891
This corresponds better with what people would expect: currently about 10 April 1891 means between 10 April 1886 and 10 April 1896, which is not intuitive.
If I get support for this, Iāll put in an enhancement request.
David Lynch
1 Like
Seems logical to me.
Many times the source records just show the quarter that the event was register in. So for the 2nd quarter I usually put in abt 1891-05-00 (May being the middle month).
If I made the default 3, then it would mean Feb to Aug of that year.
Defaults are something that need serious review. But I donāt think developers should necessarily be the deciding vote.
Defaults have 2 primary targets: newbies & eliminating repetitive steps for experienced users.
There are some defaults that Gramps obviously needs changed for newbies:
- The Themes add-on needs to be folded in so that:
- labeled GUI objects can be the default
- the GUI can detect OS being set to āDarkā themes & adapt
- the GUI can detect to Accessibility OS settings (like oversized fonts) & adapt
- the file selector need to have the Preferences file locations (backup & images), User Directory(?) & examples as shortcut buttons
- the Home & Active person should never be āundefinedā when any Person exists in the Tree
- the default location of the Example files should be in the User Directoryā¦ where that content can be updated using the Plugin Manager
For the advanced users, there are more andorr complex :
- the 4 leading zeroes default is far too low for Events & Citation IDs. (Probably for the others too.)
- the scale for the approximate Date preferences is too loose
- the default Role when a dragānādropping an Event should be definable
- the default action (such a popping up a specific āAbout this Treeā Note or focal Person) when importing a .gramps or .gpkg file should be definable
- the sequential list of default Event types to guess (Birth, Death, Burial) should be editable. Maybe you always want an Occupation, Residence or custom like āCause of Deathā in your sequence of standard Events.
1 Like
This might be a nice enhancement to the Date Calculator add-on or the Date Selection dialog.
Right now, neither tool is very useful and both are user unfriendly.
I support the suggestion from dlynch that any results relying on āaboutā, beforeā, āafterā and so on should be day and month aware.
If a user has enough information about a date that they can narrow it down to a month, or a day, then Gramps ought to recognise that level of precision in its calculations.
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.