Gramps 5.1.3-2 on Windows 11
When I open the “Top Surnames” gramplet. and double-click the top name on this list, I get a report for an unrelated surname (Allen, as it happens). Double click on the other 9 names in the list works as expected.
The tree was built via an gedcom exported from Ancestry
Any ideas? Corrupt data? Something fixable?
note I upgraded to the latest version, 5.1.6, same problem
Tests with the example.gramps tree did not reproduce a similar problem with the first linked name on the list.
Are there alternate names in the Names tab if you edit that particular surname? Or perhaps you have Grouped your “Allen” surname with the top surname? Are there a lot of 'Allen’s? In the list? Maybe the same number of people as the Top name reports?
You aren’t getting much in the way of response because we are flying blind. The description doesn’t include enough information to diagnose anything yet.
There’s another report of the same problem. But no sample data has been provided yet
Sure, I appreciate that, but what sample data would you like? I can give you my GEDCOM if that’s what you need, there’s nothing private about it. (Can’t seem to attach it though) If there’s a trace facility, I can’t work out how to activate it.
There are 4 Allens vs 163 Webbs (the top name). No groupings have been created by me; this was my first action post-import. I tired deleting the Allens & they were replaces by Davis’s - 8 of them…
Yes, please send it by eMail. (provided by PrivateMsg) Discourse it very limited in the types of attachments that it will accept.
OK - I followed the link and tried out some of the advice; specifically export/import. That has resolved the problem, in that the reports now function as expected. But I’m happy to provide the original .ged file if anyone wants to follow it up. (it will take me a little while to get up to technical speed to do my own investigation).
Let me know, thx for responding
Interesting things. The “Allen” that seems to trigger the bad behavior has duplicate “Also known as” alternative names in common with the top Surname. (It is actually her husband’s surname that is listed as the top surname. The GEDCOM has 2 separate Alternative names listings under that person… that only differ by the Source cited.)
The other 3 people on the list are of her primary surname. (They were her sister and parents. But that connection is not relevant. After adding a new disconnected person with that surname, he showed up on the list too.) In an alpha-sorted list of “Webb” named People of the top surname, hers was the 1st entry.
That is interesting; also the fact that export/import then eliminates the problem, as you wouldn’t expect that to change the contents of a field.
When I did an export/import cycle, it did NOT correct the issue. Nor did a backup/restore cycle.
I used the XML Gramps Tree for the export. Did you use a different format?
There’s a fair amount of cleanup to be done with the exported GEDCOM data.
There are a lot of Dates that weren’t valid on the Ancestry system. They were saved as ‘Text’ rather than as a ‘Date’.
The valid records are in ‘d Mmm yyyy’ format. So a “5 Sep 1981” would be valid to their system but the Month fully spelled out (“5 September 1981”) or without the proper capitalization (“5 sep 1981”) was considered ‘Text’ by Ancestry when they exported. So they imported through the GEDCOM as text too.
Most software has a hard time parsing dates. And Gramps allows oddly formatted dates to be recorded as text too when the data is unclear. (Like if a date scanned comes in as “3 Mau 1865”. It could just as easily have been ‘May’ or ‘Mar’ in the original document. So keeping it as mangled Text is the right choice if you cannot access the original yet. So keeping imported text AS text might be the right choice in an automated process.
But… you can also force Gramps to re-run the date validation for an imported by adding a space to the end of the text string.
That is kind of a hassle to do manually for a lot of entries.
So you can use a script to force all the invalid dates (or even a selection of them) to revalidate without having to open every event individually. The SuperTool addon is an advanced tool for creating or running such scripts. The script is described in another thread. It leverages the add-on filter rule that looks for Events with Invalid (or Valid) dates.
There are also a lot (a LOT) of duplicate citations. Duplicates (of all object types) are a typical issue with GEDCOM. Merging with the MultiMerge addon gramplet is a lot easier than doing a dozen merges of pairs for 13 duplicates.
hmm - I’ll check when I get home, but I think it was CSV
I really appreciate this input; Ancestry is problematic and I was very naive when I started using it. One of the reasons I’m switching to Gramps is to enforce some discipline on myself. I’ll look into the tools you mention; I’m going to work towards a reasonably detailed understanding of Gramps over time. (hope)
Dates - hate them; I used a lot of SAS back in the day & well do I remember the joy of scrubbing date data.
cheers
Just to confirm it was a csv file for the export-import.
cheers
I think the CSV import does some extra processing.
Do you mind if the GEDCOM is forwarded to a Developer? Some modifications were done to the importer, It’d be nice to do some testing on real data.
Go for it.
appreciate your help
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.