* Export Geo Coordinates?

[BEJ]

I wish to export a GEDCOM file that includes latitude and longitude coordinates for my places in my FH7. The program to which I wish to import the file maps family places on present-day and historical maps.

I have exported using the Export GEDCOM plugin and the FH export function. The place names come through, but not the coordinates.

Is there a way to export geo coordinates?

[tatewise]

Whether you can transfer Lat/Longitude coordinates depends on what the program expects.
It would be useful for us to know which product you are planning to use.

The FH GEDCOM format uses non-standard Place records to hold the Lat/Longitude, which few other programs recognise.

The 'Export Gedcom File' plugin has options for various popular products and if your product is among them then try that as the GEDCOM Export Mode.
Otherwise, try the (Str) Standard GEDCOM Release 5.5.1 option, which puts the Lat/Longitude with each Place field as required by that standard specification.

I hope you're aware that FH plots Places on the Map Window using OpenStreetMap and NLS Historic Maps for Great Britain.
Also, the 'Map Life Facts' plugin provides alternative mapping capabilities.

[BEJ]

This is the program: https://trackuback.com/

It has detailed information about Sweden and the U.S.

[tatewise]

I have taken a brief look at the Trackuback guides and it makes no mention of importing Lat/Longitude.
It allows a GEDCOM to be imported but only to build a tree with names, facts, places, etc.
The geocoding video only mentions auto-geocoding by Trackuback from Place names (just like FH).
It makes no mention of Address fields, so you may need to rearrange your data to get the best geocoding.
There are also the complications of modern versus historical Place names in your database.
Trackuback only seems to auto-geocode modern Place names and has nothing like the FH Standardized feature.

You will need to experiment with a small sample Project (perhaps the Family Historian Sample Project).
If you confirm that GEDCOM 5.5.1 Lat/Longitude is not imported then you need to contact the developers and suggest they consider that option.

[BEJ]

I did some testing to export from FH7 with the methods noted in my first post. When I look at the resulting GEDCOM in a text editor I can not find lat and long. If I open the exported GEDCOM with FH7, the coordinates are not there.

As you say, Trackuback may not be able to read the info. However, I thought my best bet was to import a GEDCOM that I knew had lat and long, and see how Trackuback handles it. Seems logical to me that if the coordinates do not export, then there’s no way Trackuback can find them.

I gather that FH7 likely does not export Geo coordinates. I did try several options for export in the Export GEDCOM plugin, and will do some more experimenting over the holiday period. Thanks for your response.

As an aside, I have been manually entering the coordinates in GoogleEarth to track family locations, so I may just switch and start entering them manually in Trackuback instead.

[tatewise]

Let me explain where to look for Lat/Long coordinates in GEDCOM files.
I presume you have actually used the FH Map Window to geocode Place names in FH.
i.e. In the Records Window, on the Places tab, the Latitude/Longitude column lists coordinates.

File > Import/Export > Export > GEDCOM File... command

With most Destination: options the exported Place records hold the coordinates in the GEDCOM in the following format, but most products will NOT recognise this structure:

0 @P24@ _PLAC Paris, France
1 MAP
2 LATI N48.856614
2 LONG E2.3522219

With Destination: set to Strict Gedcom (5.5.1) the Place records and coordinates are all excluded.
They are NOT moved into each Place field in the GEDCOM as allowed by GEDCOM 5.5.1. Cannot explain why.

Export Gedcom File plugin

Obtain this plugin from the Plugin Store and set GEDCOM Export Mode: to (Str) Standard GEDCOM Release 5.5.1.
Leave all other options at defaults and use the Click here to export GEDCOM & Media files button to export a GEDCOM file to the Project's ...\Public\Export\ folder with coordinates in this format:

1 BIRT
2 DATE 7 JUN 1924
2 PLAC Paris, France
3 MAP
4 LATI N48.856614
4 LONG E2.3522219

This should be recognised by any products that support GEDCOM 5.5.1 and handle geocoding such as Trackuback, but there is no guarantee.

[tatewise]

I have moved this thread to the Importing and Exporting forum that is more appropriate.

As an experiment, I've created a Trackuback account and uploaded a sample GEDCOM from the Export Gedcom File plugin.
At first sight, it appeared to have recognised the Place field Lat/Longitude values, as 97%, 33 of 34 places, were geocoded.
However, when viewing the plots on the map, most are in the wrong position, including the wrong country.
I tried manually positioning by entering Lat/Longitude values in various formats and eventually got it to accept Degree(+/-) format such as 51.381064 -2.359017 which plotted correctly. It would help if the guides explained the geocoding formats that Trackuback accepts.

So it is trying to import the geocoding, but does not handle the standard GEDCOM 5.5.1 Lat/Longitude format.
Therefore, I manually edited the GEDCOM to convert from
4 LATI N48.856614
4 LONG W2.3522219
to
4 LATI 48.856614
4 LONG -2.3522219
where S and W are replaced by a minus (-) and N and E are simply removed.
However, that made no difference at all.

I then tried its Automatic Geocoding of the entire list, but it only seems to recognise countries and USA States.
i.e. All places in England were plotted in the middle of England, and all places in Scotland in the middle of Scotland, etc.
Maybe it works better with Scandinavian places?

I could not find a way to export the data as a GEDCOM to see what geocoding format they exported.

So after the Xmas holiday, I intend to report these problems to them!

[BEJ]

I presume you have actually used the FH Map Window to geocode Place names in FH.
i.e. In the Records Window, on the Places tab, the Latitude/Longitude column lists coordinates.

I do not use the FH Map Window to geocode Place names. Instead, I manually enter coordinates in the Place Property Box. So, yes, the coordinates appear in the Latitude/Longitude column Place Records Window.

I was using the default Export Gedcom File plugin setting of 5.5, and now changed it to 5.5.1. I reset all other options to default. And, yes I found the coordinates in my export. For example:

1 RESI
2 DATE AFT 1878
2 PLAC Korsgården, Hadängs i Valinga, Skaraborg, Sweden
3 MAP
4 LATI N58.1208612
4 LONG E13.9788559

1 BAPM
2 DATE 12 APR 1952
2 PLAC First Evangelical Lutheran Church, George Street 52, West Haven, New Haven, Connecticut, USA
3 MAP
4 LATI N41.277023
4 LONG W72.9517546

I imported the GEDCOM into Trackuback and it worked.* Perhaps using 5.5.1. instead of 5.5 or resetting all other options to default was the trick. Anyway, thank you--again.

*Well, it almost worked. All the Swedish locations map accurately, but the U.S. locations end up in Asia. Must be a problem with longitude. I express latitude and longitude coordinates as decimal fractions of a degree to conform with the format used in most digital applications, such as GIS. Positive numbers indicate a location north of the equator or east of the prime meridian (Royal Observatory at Greenwich), and negative numbers indicate south or west. FH7 exports coordinates using N, S, E, and W notations. I don't understand why FH7 prefers this outdated mode of expression.

There must be a problem in translating between decimal format and the format used by FH7. I'll contact Trackuback help and see if they have any suggestions.

[BEJ]

@tatewise — Just saw the post about your experiment with Trackuback, after posting mine. I too have only an evaluation, free account ‘till I see if the program does what I want it to do. It’s a promising premise, but only if they can deliver.

Thanks

[AdrianBruce]

... FH7 exports coordinates using N, S, E, and W notations. I don't understand why FH7 prefers this outdated mode of expression. ...

Looking in the GEDCOM 5.5.1 specification, the examples use the N, S, E and W notation, so that's (presumably) why FH7 uses it.

GEDCOM 5.5.5 - the proposal from Tamura Jones et al (not FamilySearch) - continues with the N, S, E and W notation but notes and recommends that

Several applications use the plus (+) and minus (-) sign as sign characters.
GEDCOM readers should accept both styles.

[tatewise]

GEDCOM 7 perpetuates the N, S, E, W prefix notation without mention of + and - notation.

I tried Trackuback with both notations and it seems to ignore all prefixes and just recognises the +ve numbers, which causes all the S and W (i.e. -ve) coordinates to be misrepresented, i.e move to the north & east quadrant.
e.g. Bath, Somerset, England is plotted East of London on the same Latitude but in the English Channel.

[tatewise]

I have discovered what Trackuback needs for coordinates.
It has all its coordinates based on the origin of the intersection of the Greenwich Meridian and the Equator.
Only positive latitude and longitude values from 0 to 360 degrees are acceptable.
So degrees S or W or -ve degrees are not recognised. i.e. W -10 degrees must become E 350 degrees.

The Trackuback designers need to change the GEDCOM import to recognise the GEDCOM LATI/LONG standard.
Otherwise, they cannot really claim to import GEDCOM format files.

[BEJ]

Hmmm, that seems an odd approach for them, if they really want to be a genealogy platform. Earlier today I wrote to Trackuback, sharing both of our experiences. I’ll let you know their response. Thanks for the follow up!

Just got a response from Trackuback. After explaining that they're new and working to do their best, etc., etc., they state the following.

"When it comes to your experiments with how to write long/lat-coordinates, this is great info for us to trim the tool. I am sending this reply to our GIS-expert Mårten Swärd as well, who can answer your more detailed questions, and will most certainly have a look at your comments to improve the tool. We have used only decimals so far, but I realize that we have to fix an interpretation for the N-E-S-W info as well. It shouldn't be too hard to implement for us (that said from me, who doesn't have to do it )

"If you and your colleague would like to, we can extend your trial period for a couple of weeks, so you really can try it out while we trim things at our end. If that is interesting for you, just tell me."

@tatewise -- Do you have any interest in continuing along on this adventure, or are you good for now?

[tatewise]

It sounds like they understand the problem and the solution.
I suspect that the free account will still let me check the improved GEDCOM coordinate handling when that is available.
So I think I am good for now, thank you.