ShammyLevva
[BUG] Duplicate birth or death events do not show in the Errors list.
Is your feature request related to a problem? Please describe. I have several persons that have duplicate vitals, i.e. birth and death events, due to merging. These duplicates are not shown in the Errors tab, even though other duplicates are shown.
Describe the solution you'd like I like to see duplicate warnings for all types of events, where relevant.
I tried to file this as a Feature Request, but for some unknown reason, the Submit button was not activated, so I couldn't file it.
There’s an option called load alternative facts, this will load alternative facts and analyse them too.
Depending on the app used to create the GEDCOM there may be many facts flagged as alternatives, notably with FTM/Ancestry this often includes duplicates created by the merge.
Can you try turning this option on and see if that does what you are looking for.
Thank. I didn't see that option, and I din't know its meaning, but it does help, a bit. I can see duplicates Christenings and Burials now, but no duplicate births or deaths. And I think that those duplicates exist in my GEDCOM too.
I'm using Gramps, and unlike PAF it does not force you to make a choice when conflicting vitals are found during merges.
I'll get back to you when I've expanded my Gramps XML parser to check for duplicate births and deaths.
I ran another check, and found a person for which duplicate Burial and Christening facts were detected after switching on the option to load alternative facts. And in Gramps, that person had duplicate Birth and Death facts too, which went unnoticed.
The person with the duplicates is the root person of the attached file: Thomas Starr M.D.
I'm seeing duplicate burial and death records for him but not duplicate birth and death facts.
Should I be seeing duplicate birth and death facts?
Oops, my mistake. Looks like I mixed up some persons, and exported the wrong GEDCOM.
But when I edit it, and copy paste Thomas' BIRT event to create a real duplicate birth, it is not shown.
Just tried as you suggested and did a literal copy paste of Thomas Starr's birth Untitled_40.zip
This gives a duplicate birth error in beta 6. So it may have been fixed as part of recent tweaks on alternative facts.
I did note it's not a very sophisticated duplicate check it's looking for exact matches based on a hash that includes the location and comments. However I guess that's ok when it's purpose is to detect duplicates that arise as a result of merges.
OK, I understand, and as far as I'm concerned there are two sides on this. The first is that I can work on making Gramps smarter, so that exact duplicates are detected and eliminated during merging.
The other is, that when I merge data received from relatives, or downloaded from FamilySearch, there may be non identical duplicates caused by different ways of registering locations, misinterpreting dates, etc., so that it's nice to see warnings about such kinds of 'alternative facts', so that they can be decided upon. For me this is most important for birth and death, which are true one time vital events. Baptisms and burials can occur multiple times, and in different places, but those are still rare enough to be warned about, I think.
I'll need to give greater consideration to how best to check duplicate facts. As you mention some facts are more likely to be unique than others although I'd note that it was a fairly common practice in Scotland for poorer families to register the same birth in two different parishes This was down to the poor laws that made parishes responsible for their own poor (their own being defined by someone having been born or married in the parish). Although I guess technically these are baptisms not the birth still many people record them as a birth not a baptism so there needs to be some acknowledgement of issues there.
The present method is a bit of a sledgehammer in that it creates an artificial hash value based on the date, location, fact type etc and considers them identical if the hash values match. Nothing more complex than this. The individual duplicates routine for instance does various formula comparing two individuals to score a likely duplicate. That's a better approach as it allows greater liklihood of a duplicate being spotted due to marginal variations in facts (eg: spelling differences). However it runs into the issues looked into earlier in the year with increasing complexity/slowdowns for calulations as file sizes grow. So I'd need to apply lessons learned to avoid that issue. Perhaps limiting the more detailed checking to only fact types that would be unique. such as the births/deaths.