On 22 April 2012 13:27, Christopher Gray <[email protected]> wrote: > Caroline - it depends on what you are including in the GEDCOM.  For example, > while I can export from TMG using GEDCOM I know that the citation and source > details I have will not be effectively transferred. Chris - I use both TMG 7 and FTM 2012. Problems arise exporting sources and citations if you use either program's built in source templates. That is because the template fields are exported as separate GEDCOM elements and then cobbled back together incorrectly by the importing program. In FTM I ignore the source templates and create my citations using just the citation detail and citation text fields. These export as a whole in a GEDCOM and therefore import correctly into the receiving program. You could achieve the same in TMG by creating your own simple templates with just one field. > I have received GEDCOMs > from people using FTM and I have a number of problems with them - including > how the place names are stored. This may be because they have entered only a "standardised" place name in the place field and put the place details in the description field. Place names are stored as they are entered and, if entered in this split fashion, will export accordingly. You might like to look at the place list on my website: http://www.carosfamily.com/places.php to see how places entered in full in FTM 2012 export correctly in a GEDCOM. > Different programs have different ways of > handling relationships (e.g. step-children, same-sex marriages), places > (e.g. including latitude and longitude) and such as DNA.  So I certainly do > not expect GEDCOM to be able to handle everything. I entirely agree. You only have to read Tamura Jones' acerbic reviews of genealogy software to realise there isn't any program which gets GEDCOM "right". He lambasts them all. But I feel his approach misses the point. Yes, every program creates its own weird and wonderful version of GEDCOM but the really important thing is how the importing software handles those quirks. I think when software developers blame the exporting program they abdicate their own responsibility to their customers. It is not difficult to examine a GEDCOM file produced by another program, identify the non-standard aspects and adapt the import for those files accordingly. A couple of years ago I experienced an outstanding example of this "can do" approach from Mike Voisin of GED-GEN. When I told him that a non-standard GEDCOM was not importing correctly he issued an upgrade specifically designed to deal with the problem. Darrin Lythgoes of The Next Generation has taken a similar approach and his program correctly interprets GEDCOMs from a wide range of different genealogy programs. He also provides the facility to edit the handling of non standard GEDCOM tags post import. > Nor do I expect > developers of any future version of GEDCOM to be able to handle all the data > types / events / relationships that all programs use.  It will be an > improvement on the current version - but I certainly do not expect any way > near perfection. You are so right. The Holy Grail of a perfect GEDCOM standard, perfectly implemented, is unattainable. Which is why those developers who make it easiest for potential customers to import their data from another program warts and all - using GEDCOM or a propietary utility such as Wholly Genes' GenBridge - will continue to have a significant business advantage. Caroline Gurney