Jump to content


Photo

Fails to import Repository address from TMG GEDCOM

GEDCOM TMG IMPORT

  • Please log in to reply
2 replies to this topic

#1 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6073 posts

Posted 15 August 2014 - 04:19 PM

RM6 does not do appear to do anything with the ADDR line on import. The value is lost and no error is recorded in the .LST file. Who's at fault?
 
0 @R29@ REPO
1 NAME LDS Family History Center
1 ADDR 10445 Clayton Rd.
2 CITY St. Louis
2 STAE Missouri
2 POST 63131

Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#2 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 8198 posts

Posted 15 August 2014 - 05:25 PM

I don't have an answer for that, but I REALLY hate to pull the RootsMagician away from his work on the direct import of TMG to ask a lot of questions about how RM is handling the current GEDCOM import from TMG, when he's trying to fix all these problems.

 

So if I don't answer your TMG questions you will know I'm not really ignoring you, but I kinda am. :) I will leave you all to speculate who's at fault for the GEDCOM issues for now. My personal opinion - it's GEDCOM's fault.


Renee
RootsMagic

#3 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6073 posts

Posted 15 August 2014 - 08:07 PM

Maybe GEDCOM ambiguity and different interpretations alright. This works:

 

0 @R29@ REPO
1 NAME LDS Family History Center
1 ADDR 10445 Clayton Rd.
2 ADR1 10445 Clayton Rd.
2 CITY St. Louis
2 STAE Missouri
2 POST 63131
 
According to GEDCOM (my interpretation), the value on 1 ADDR and the value on 2 ADR1 mean the same thing.
The value on the first 2 CONT after 1 ADDR means the same thing as that on 2 ADR2.
Successive CONTs have no relationship to anything else.
The difference between the ADRn tags and their doppelgangers is that the former are used in systems that have structured addresses, the latter simply correspond to labels and have no structure for indexing and sorting.
CITY, STAE, POST, CTRY round out the structured address structure.
 
Given the intended equivalency of the values on ADDR and ADR1, and likewise for the values on the first CONT and ADR2, it seems reasonable that in the absence of ADRn, the ADDR and 1st CONT values should be handled as if they were respectively ADR1 and ADR2. That seems to be the TMG interpretation while RootsMagic expects explicit structured address tags.
 
I used a regular expression search and replace in Notepad++ to modify the 1 ADDR lines to the two lines you see above:
Find:       1 ADDR (.+)$
Replace: 1 ADDR $1\r\n2 ADR1 $1
 
If there are ADDR lines on other levels then the search and replace would have to be revised for each level. 

Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.