GEDCOM file import should terminated
GEDCOM import needs to stop. I have seen more than one well documented family group contaminated by the import of files filled with BAD data. Please end support for GEDCOM files. They do more damage to the integrity of Family Trees and spread bad information into otherwise sound family groups. GEDCOM files allow ignorant and lazy patrons to mess up FamilySearch. Please STOP STOP STOP the use of GEDCOM files. Stopping GEDCOM file import would go a long way to improving the quality of data at FamilySearch.
Comments
-
What! They are still allowing that? I made the GEDCOM mistake myself a few years ago. A nice cousin wrote to me a let me know how I had added tons of duplicates to her part of the tree. She told me about Roots Magic. If I had known about Roots Magic I would not have made the mess I did. I still run into the duplicates I made and keep merging them. Unfortunately, I probably will never be able to find and clean up the mess I made. I sure hope they quit allowing the GEDCOM imports.
0 -
Uploading GEDCOM files into Genealogies performs a useful function. Where things go wrong is, after having uploaded the file, the person uses the Compare facility to transfer names into Family Tree, which, of course, is what most people will do. For some reason, the system is currently very poor at identifying possible duplicates leading to the problems cited. I have experimented with this in a small way and found that, after adding a person via Compare, the system immediately identifies a possible duplicate where the data is virtually identical!!
4 -
As Graham said, the problem isn't GEDCOMs. They have their place, in Genealogies.
The problem is the compare-and-add process. It is badly flawed and leads to wholesale corruption of existing data by well-meaning but clueless users.
That said, that process is not the only culprit for wholesale bad additions to the tree. It is merely the easiest to identify, because it "signs" its additions in the Reason fields. Other processes -- such as the various third-party programs' "sync" capabilities -- are generally somewhat better at finding existing profiles (yeah, I know, damning with faint praise), but can still lead to large numbers of duplicates and other messes. They're just harder to see, because they do not have a uniform reason statement added to everything.
Unfortunately, I don't think FamilySearch will ever completely stop large-scale imports. They can't, really: there will always be people who have spent decades on their research who simply cannot conceive that in the long run, it really is faster and better to add all of that data one person at a time. Thus, there will always be a demand for an import function that avoids any semblance of redoing or retyping, no matter how unrealistic such expectations are for a communal tree.
4 -
Like Graham and Julia say the problem isn't with the tool - at least not entirely... it's how the tool is being used.
I would agree partially with this Idea though I would definitely stay further away from terminated ...
How about this middle ground. Stop allowing imports from developed countries (well contributed countries that have/had the opportunity to contribute for the past decade +) - until the system can better identify duplicates and only allow compare/import differences (sources, memories, ...) definitely not replace an existing well-documented profile? The problem with stopping allowing imports period, full stop - is that is ignores the potential good for good imports/synching (as Julia sited) - especially/potentially from countries where there have been less imports.
0 -
My recollection is the GEDCOM Compare does already compare only one profile at a time - I guess unless someone has automated it somewhere/somehow. Yes it has the profiles all listed and ready to compare - but the person has to go one by one. In that case they may as well use a 3rd party tree management solution with tree synch capability.
1 -
Take a look at last years Rootstech presentation on the topic:
He indicates this can be done safely without duplication.
0 -
They are needed, yes their is issues, this has been a debate for some times, all I can say is I hope they work out the kinks so it don't cause duplicates.
0
