Jump to content


Photo

v9.04.0000-GEDCOM export / Enhanced option / Discussion

GEDCOM export

  • Please log in to reply
27 replies to this topic

#21 Michael Hannah

Michael Hannah
  • Moderators
  • 2,733 posts
  • Gender:Male
  • Location:Los Ranchos, New Mexico, USA
  • Interests:Genealogy, Computers

Posted 04 September 2014 - 09:37 AM

Hmmm...  But I thought that IF the TMG ID was exported as an REFN, then the TMG ID could be used as the RM RIN instead of the INDI.  Seems useful to me?


Michael
See my book on how I customize TMG My Way.
My website.

#22 Jim Byram

Jim Byram
  • Moderators
  • 7,340 posts
  • Gender:Male
  • Location:Framingham, MA

Posted 04 September 2014 - 09:53 AM

Again... The REF_ID is used as the INDI in TMG GEDCOM exports.

 

Tom's post-processing lets the INDI be used as the RM RIN. So you have the same visible ID numbers being used in RM and in TMG.

 

You could export the REF_ID as REFN tags using the ID Numbers option and display those next to the names in RM but why? You would have the same numbers as RINs and in Reference number facts.

 

Other programs such as Legacy 8 give you the option to use the INDIs as the RINs. Family Historian uses the INDIs but I don't recall if that was an option or by default. I suspect that it was by default since FH uses the (updated) GEDCOM as it's database.

 

The ID Number option can always be selected by the user for his/her export but I see no point in recommending it.



#23 TomH

TomH
  • Members
  • 25 posts
  • Gender:Male

Posted 04 September 2014 - 02:53 PM

Some RM users wish for the ability to batch add a Reference Number to each person with the value of the current RIN. I wrote a SQLite query to do that and have used it on databases I have subsequently imported into my main database so that there was a reference back to the original. This is especially useful if there has been a book published from the original that made use of the record number. So I can understand that it may be desirable for the TMG reference number REF_ID to be exported both in INDI and in REFN, regardless of the destination database system. However, it may be desirable, as I have done, to prefix the number in the REFN with something that distinguishes it from other numbers, e.g., "TMG", which might then be readily searched and replaced by whatever the end user wants in some other database system.

#24 Michael Hannah

Michael Hannah
  • Moderators
  • 2,733 posts
  • Gender:Male
  • Location:Los Ranchos, New Mexico, USA
  • Interests:Genealogy, Computers

Posted 05 September 2014 - 07:58 AM

Jim pointed out: "Again... The REF_ID is used as the INDI in TMG GEDCOM exports."

 

Ahhh... that detail had escaped me. :wallbash:   I had not noticed that feature in the TMG GEDCOM exports.  All other programs I had tested did what GEDCOM expects, exports using consecutive INDI numbers with no gaps.   Sorry about my confusion.  Now I understand why the option to export the REF_ID as an additional REFN may have little meaning, especially if the importing program will use the INDI as its own RIN.


Michael
See my book on how I customize TMG My Way.
My website.

#25 TPG

TPG
  • Members
  • 57 posts
  • Gender:Male
  • Location:Silver Spring, Maryland

Posted 05 September 2014 - 08:00 AM

I am somewhat disquieted by the entire proposal to enhance the TMG gedcom export capability to accommodate the specific gedcom import facilities of other genealogy programs.  I'm not sure why I am disturbed, since most of the tweeks added (e.g. the new initial underscore tags) would be ignored in a more general setting. But I do believe that it sets a bad precedent of junking up the standard TMG gedcom export capability with special features when perhaps cleaner options might exist.  I am uncomfortable with the feature of TMG becoming dependent on the import conventions of other genealogy programs.

 

In any case, the gedcom modifications proposed would seem to only approximate the natural import requirements of the specific importing program.  I also ignores other competing products' import requirements.   Rather, I would suggest that we rely on separate standalone programs to provide TMG output compatible with the import facilities of particular genealogy programs.  These programs would, if necessary, read the TMG proprietary data files to produce the necessary input in whatever format was needed by the importing program.  This is easily done as is shown by John Cardinal's TMG Utility and by the availability of the FoxPro OLE module underlying my WitnessTMG program.  We could load up these individual standalone programs with as many features as desired and, if the associated genealogy program's import requirements change, only have to modify the individual program.

 

TomH, while he was testing my witnessTMG program, urged me to adopt many of the suggestions he has made in this forum.  I resisted incorporating the changes, partially on the grounds noted above.

 

By the way, the modifications to the TMG export facility leaves intact what I consider to be the greatest deficiency in its gedcom export facility  - namely the requirement that the owners of a joint event have to be married or at least be the joint parents of a child.  Changing this to allow the event to appear as separate events under each individual should be relatively easy. 



#26 Jim Byram

Jim Byram
  • Moderators
  • 7,340 posts
  • Gender:Male
  • Location:Framingham, MA

Posted 05 September 2014 - 08:54 AM

The new GEDCOM export option is just that... an option that can be selected or unselected. No one is required to use it. It serves the needs of the vast majority of TMG users who wish to migrate to the most obvious alternative choices. It obviously can't be designed to serve every user and to accomodate every program users might want to migrate to. Bottom line... This is a limited practical effort to make it easier for as many TMG users as possible who wish to migrate to other software.

 

 

By the way, the modifications to the TMG export facility leaves intact what I consider to be the greatest deficiency in its gedcom export facility  - namely the requirement that the owners of a joint event have to be married or at least be the joint parents of a child.  Changing this to allow the event to appear as separate events under each individual should be relatively easy.

Custom tags (non-family) with P1 & P2 will also export if the tag type is set to export as an acceptable GEDCOM 5.5 individual attribute or event tag (i.e., enter an appropriate tag name into the GEDCOM field on the Tag Type Definition Screen). They will appear under P1 and P2 in their individual records. For example, you could export a custom event tag having a P1 and a P2 as a GEDCOM RESI tag. The custom tag name will be lost.

 

Taking advantage of this would work poorly if the new GEDCOM export option were used. For example, if such an event had witnesses, you would end up with two tags in individual GEDCOM records each with all linked witnesses and no way to know that the two principals were P1 and P2 of an event tag in the TMG database. 



#27 Michael Hannah

Michael Hannah
  • Moderators
  • 2,733 posts
  • Gender:Male
  • Location:Los Ranchos, New Mexico, USA
  • Interests:Genealogy, Computers

Posted 05 September 2014 - 11:03 AM

Tom,

Most of us, including Jim I strongly suspect, would argue that using GEDCOM even with this proposed Enhanced Export option is only suggested if there is no other feasible alternative. If as you suggest a program exists to directly read TMG project files and construct import input specific to a given product, then that is destined to be a better solution for transferring to that product. But until those programs exist, this option is likely to be very useful to those users who do not wish to wait for such direct-import programs.

 

I, for one, continue to recommend people wait for such programs, and not to use GEDCOM as a transfer mechanism, even with this useful extension option.

As for your comment about two-principal events, Jim explained what TMG export will do with a particular parameter setting for such events.
 

Custom tags (non-family) with P1 & P2 will also export if the tag type is set to export as an acceptable GEDCOM 5.5 individual attribute or event tag (i.e., enter an appropriate tag name into the GEDCOM field on the Tag Type Definition Screen). They will appear under P1 and P2 in their individual records. For example, you could export a custom event tag having a P1 and a P2 as a GEDCOM RESI tag. The custom tag name will be lost.


This will occur, Tom, but notice carefully Jim's comment that "the custom tag name will be lost". Using his example, if you set TMG Tag Type XYZ to export as RESI there is now nothing in the GEDCOM output to distinguish this XYZ TMG tag type output from any other TMG tag type which is also set to output as RESI. Thus this setting has limited value if you want to export several different two-principal custom TMG tag types and keep their output separate in the GEDCOM.

Also note that there is now nothing in either of the duplicated GEDCOM tags to indicate that the other principal was ever linked to this tag. That linkage is lost.

(If you do wish to try this, I would suggest instead of using a GEDCOM tag type such as RESI which may be being exported from TMG by some other tag type, to use one of the two legal individual tag types not used by TMG: CHRA and CREM.  But since they are standard GEDCOM tag types, the importing program may recognize them for their true propose. However, at least using these names any tag type(s) set to one of these GEDCOM tag types would be identifiable and separate from normal TMG tag type output.)


Michael
See my book on how I customize TMG My Way.
My website.

#28 TomH

TomH
  • Members
  • 25 posts
  • Gender:Male

Posted 06 September 2014 - 12:31 PM

RMπ 1.0.4 now processes TMG GEDCOM PLAC values into RootsMagic Place, Place Details and Place Detail Notes with some caveats. For details and download, visit  

RMπ (RMpi) GEDCOM Pre-Import Tweaker for RootsMagic


Edited by TomH, 06 September 2014 - 12:31 PM.






Also tagged with one or more of these keywords: GEDCOM export

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users