Loc coordinates error after import of ged file

Hello gramps users,
after import of gedcom file I get an error in location cordinates, by saying can’t read line XY…
In Gramps message is “Invalid coordinates” for the location.
Gramps is setting always a comma as separator, eg N48,6667 and E7,3833.
After changing the comma with point it works. But as I have hundreds of this, this would be a pain.
It does not matter if Gedfile has Loc coordinates with comma as separator or point, Gramps always import with comma.

Appreciate any help.

Gramps 5.1.3 X64, German Language set, Win 10

While not particularly helpful…

Page 58 of the GEDCOM 5.5.1 standard calls for PLACE_LATITUDE:= and PLACE_LONGITUDE:= values to be in decimal format & prepended with a capital letter of the cardinal direction. So whatever wrote the GEDCOM was not complying with GEDCOMs narrow-minded spec.

The quickest short-term workaround would be to set your OS to US English and export the GEDCOM from the original program again.

This might resolve other decimal/comma conflicts. (Some might not generate an error message and be less obvious.)

The available formats are the following:

=========   ============================================================
Format      Description
=========   ============================================================
'D.D4'      degree notation, 4 decimals
            eg +12.0154 , -124.3647
'D.D8'      degree notation, 8 decimals (precision like ISO-DMS)
            eg +12.01543265 , -124.36473268
'DEG'       degree, minutes, seconds notation
            eg 50°52'21.92''N , 124°52'21.92''E ° has UTF-8 code c2b00a
            or N50º52'21.92" , E14º52'21.92"   º has UTF-8 code c2ba0a
            or N50º52.3456' , E14º52.9876' ; decimal minutes, no seconds
'DEG-:'     degree, minutes, seconds notation with :
            eg -50:52:21.92 , 124:52:21.92
'ISO-D'     ISO 6709 degree notation i.e. ±DD.DDDD±DDD.DDDD
'ISO-DM'    ISO 6709 degree, minutes notation
            i.e. ±DDMM.MMM±DDDMM.MMM
'ISO-DMS'   ISO 6709 degree, minutes, seconds notation
            i.e. ±DDMMSS.SS±DDDMMSS.SS
'RT90'      Output format for the Swedish coordinate system RT90
=========   ============================================================

You can replace N and E by nothing
W should be replaced by a minus sign.

The Gedcom import doesn’t change the text of the lat/long, so you should get what is in the Gedcom file. So I don’t understand what you mean when you say “It does not matter if Gedfile has Loc coordinates with comma as separator or point, Gramps always import with comma.”

That said, I have just created and uploaded a new addon tool that can correct this for you. It is the “Fix Place Coordinates” tool, found in “Tools/Family Tree processing/Fix Place Coordinates” menu, after you install it via the “Edit/Preferences/General/Third party addon” methods.

Please run a backup before using this, just in case. The tool should allow Undo/Redo, but if it crashes or otherwise doesn’t work right you can recover.

1 Like

I suspect the problem he was experiencing was in the import parser. So it just passed through a text string.

Aren’t the lat/long format validation conversions applied only when the field is selected in an input form?

Paul’s solution resolves this particular problem. (Thank you! I was hoping one of the Python reformatting tools for fixing Ancestrologie GEDCOM oddnesses might have addressed the same issue. But the archival domain appears to be gone.)

But haven’t there been a bunch of similar issues raised before? Where an import didn’t resolve a data incompatibility that the direct data entry handles easily? And where a solution (when there were just a few offending records) was to activate the ‘bad’ field in the Object Editor and press Enter to force a re-validation?

It seems like a general re-validate tool that automated that process could future-proof against such issues. If course, it might also be a slow & dangerous process.

A while back, I had wanted to add the Lat/Long format that Google returns on a query. But I’m still some experience away from the necessary Python skills.

They have an unexpected space before the cardinal direction.

Googling “rome italy latitude” returns
41.9028° N, 12.4964° E

So I have to take out the 2 extra spaces manually before the parser will accept it.

It is definitevely an error in Family Tree Maker 2019, US version, Gedcom Export function, what is not considering the local settings of the OS for GER.
With emyoulation’s advise the export out of FTM 2019 works, after setting the OS system to US version.
The Plugin from Paul “Conversion for Fix of place coordinates” also works fine, many thanks. It is really a great help, as I am sure that many others in EU countries will have this problem.
Gramps imports the LOC coordinates as they are in the gedcom file.

Thanks again for your help.
Regards Ewald

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.