20Re: Good news for your fingertips...
- Jun 8, 2009--- In firstname.lastname@example.org, "Alan S>" <ocifant@...> wrote:
>A good question - which we don't have a definitive answer for just yet.
> --- In email@example.com, "ancestral.atlas" <ancestral.atlas@> wrote:
> > we have tried to re-create this error but we are unable to do so.
> I think I've sorted this. Human error! Each uploaded Gedcom person has multiple events, I just wasn't seeing them as teh my Events list is sorted by Event type rather than person. When adding a new event, the new event shows in the events for the location, thus looking like a duplicate.
> Any thoughts on my supplemental question yet?
> > > Also, my gedcom is a changing document as more information
> > > becomes available. Is there any way to preserve the location
> > > data I've entered if I upload a replacement Gedcom file?
> > > How is it planned to handle this in the future?
The problem boils down to the fact that it's difficult to know which event in an updated GEDCOM file relates to which event previously uploaded.
The GEDCOM standard simply states that each individual record has a unique ID and that if an individual has a number of events that have happened to them, those events are listed as sub-records of the individual's record - there is no particular order to these sub-records.
So, firstly, it's quite possible that your family tree application that generates the GEDCOM files can change the individual record IDs used each time you export - there's no guarantee (nor need to guarantee) that the IDs will remain the same between exports.
Secondly, even if the IDs do remain the same, it's still difficult to identify which events have changed. For example, say you originally uploaded an individual with one marriage, but you then discover that they were married a second time so you try and upload a GEDCOM with this extra marriage information. We would have to detect the second marriage but also resolve which marriage listed in the new GEDCOM was the same as the one we already had and which was the new marriage.
Once this has been ascertained, we must then detect if the location for the existing event (the one previously uploaded) has changed.
So, hopefully, you can see that there are quite a few problems to overcome.
We're not saying that it's impossible - just that we need to make sure that we can actually do this effectively without losing information or, worse still, corrupting it.
- << Previous post in topic Next post in topic >>