5 replies to this topic

[hamiljf]

Trying to load 'raw' GED into RM 7.5.4.0, the following apparently valid GED:

 

2 PLAC Slaithwaite, Kirklees, Yorkshire WR, United Kingdom
3 MAP
4 LATI 53.6246
4 LONG -1.87790287

 

gives the error

 

Unknown info (line 1144)
    3 MAP  
    4 LATI 53.6246
    4 LONG -1.87790287

 

even though the GED grammar says

 

PLACE_STRUCTURE:=
  n PLAC <PLACE_VALUE>                        {1:1}
    +1 FORM <PLACE_HIERARCHY>                 {0:1}
    +1 FONE <PLACE_PHONETIC_VARIATION>        {0:M}
      +2 TYPE <PHONETIC_TYPE>                 {1:1}
    +1 ROMN <PLACE_ROMANIZED_VARIATION>       {0:M}
      +2 TYPE <ROMANIZED_TYPE>                {1:1}
    +1 MAP                                    {0:1}
      +2 LATI <PLACE_LATITUDE>                {1:1}
      +2 LONG <PLACE_LONGITUDE>               {1:1}

 

The GED is generated by my own code based on data held in a spreadsheet, and the header specifies GEDC/VERS 5.5.1 so I don't see why it should be rejected. For background I am running RM in a Ubuntu system under Wine with no significant difficulty.

By the way, RM also rejects the tags IDNO and RIN, one of which I would like to use to audit back to my source data.

[kbens0n]

Create a fresh new test database and a dummy individual with facts, sources, places and ETC. that you want to import...
then File->Export and examine how RM chooses to represent TAGs that you are gonna bring into the program.
Then, replicate those for maximum importability.

[hamiljf]

Already tried that, but RM just exports the PLAC tag, for example:

 
2 PLAC Slaithwaite, Kirklees, Yorkshire WR, United Kingdom

 

and doesn't export the MAP coordinates, so I am relying on the standard grammar for guidance.  What is somewhat irritating is that I now have a gazillion places in the new database and it is happy to geolocate them for me: List/Place List/Geocode.  Of course, this works fine, but the Lat/Long now stored aren't necessarily the ones I want and some of the places get a bit messed with during the process.

[joe bloggs]

I suspect that the reason why RootsMagic does not geocode Slaithwaite maybe twofold. WR should be West Riding of Yorkshire (Now West Yorkshire), and secondly, Kirklees is a relatively new administrative entity (created 1 April 1974).
If you juggle with these in your GEDCOM it may work.

[kbens0n]

Already tried that, but RM just exports the PLAC tag, for example:
 
2 PLAC Slaithwaite, Kirklees, Yorkshire WR, United Kingdom
 
and doesn't export the MAP coordinates, so I am relying on the standard grammar for guidance.  What is somewhat irritating is that I now have a gazillion places in the new database and it is happy to geolocate them for me: List/Place List/Geocode.  Of course, this works fine, but the Lat/Long now stored aren't necessarily the ones I want and some of the places get a bit messed with during the process.

Must be the level number differences and not prefacing coordinates with coordinate direction letter, maybe?. When I check a GEDCOM exported from RM, I find examples like this:

1 FAMC @F95@
0 @I190@ INDI
1 NAME Perinne /Sirouiet/
2 GIVN Perinne
2 SURN Sirouiet
2 NSFX (Sirouer, Sirauer)
1 SEX F
1 _UID F5561D52F75ED711B4CAF1C4B740385DB6C0
1 CHAN
2 DATE 9 MAR 2007
1 _COLOR 3
1 NOTE BIRTH: Drouin calls her Sirouer, and the PRDH calls her Sirouiet
1 BIRT
2 DATE ABT 1615
2 _SDATE 1 JUL 1615
2 PLAC Abbaretz, Pays de la Loire, France
...
...
...
0 _PLAC Abbaretz, Pays de la Loire, France
1 MAP
2 LATI N47.5500000
2 LONG W1.5333333

[KFN]

Rather than following the GEDCOM standard, RM looks like they made up their own!

On the bright side they do use the correct data values. The LATI coordinates should be north/south of the equator(N/S) and the LONG east or west of the zero or base meridian (E/W), rather than using a positive or negative number.