* Extra commas in PLACe field 10

[jimlad68]

I am looking at using position 10 of the GEDCOM PLACe record.
I think this is the last comma delimitated position.
Are there any implications if I have 1 or more commas in that field, i.e 11th, 12th commas etc. In particular in FHv7 and Gedcom files, but I am also interested in any other genealogy scenarios.

The reason I ask is I am considering putting lat/long there and the "easiest" format is signed decimal degrees e.g. 54.83599, -1.494535, this would add the extra comma. (easiest in its format and default for Google and Bing maps)

From trial and error I have found out that most "map" programs will accept various lat/long formats including the above without a comma e.g. 54.83599 -1.494535, so I could input it without the comma.

[BEJ]

Interesting. Can’t answer your question, but curios to know your reasoning. Why not use the lat and long fields for the coordinates.

[jimlad68]

Why not use the lat and long fields for the coordinates.

I think the lat and long fields you refer to are the FH "none standard Gedcom" PLACe record. For the present I prefer to use the 10 standard Gedcom fields as these are much more portable.

One thing I have learnt is that if one creates an 11th comma delineated field and use a query with =TextPart(%_PLAC%,11,1,STD) it shows in the 11th field and is not concatenated to the 10th field. In consequence I will use the lat long without the comma.

[BEJ]

Ah ha. Yes, using geocoordinates in the place field does make sense. It would be particularly useful when sharing data for a location that had evolving names through history. One would know it was the same place due to lat and long, even without the data in the fh PLACe field.

[jimlad68]

... It would be particularly useful when sharing data for a location that had evolving names through history

Yes as a "prime" source location for the lat/long data. However, for practical usage purposes, I don't think many other programs make use of it. I think I recollect TMG used to have it as a "recommended" storage field but did nothing with it. This is something I might look into again, but last time I did there was no "global" consensus how to store "and use" lat/long. Ancestry.com, Family search and others seem to have a good database of "place names" without users needing to know lat/long, but nowhere near as accurate as lat/long, especially as you point out with "location that had evolving names through history" and not much use for a burial plot.

So, if I get around to doing more lat/long, FH PLACES might be an alternative or additional way to store it.

[tatewise]

Several products now support the GEDCOM 5.5.1 Place structure that has separate Lat/Longitude fields.
The Export Gedcom File plugin constructs those fields from the FH Place record Lat/Longitude fields.
The products are Ancestris, Family Tree Maker, Gramps, Heredis, Legacy, My Family Tree, and RootsFinder.

[jimlad68]

Thanks Mike for the illumination, things have moved on since I last looked at this, especially as GEDCOM 5.5.1 is more accepted. I had not realised it had separate Lat/Longitude fields. That said, I have not found much on lat/long via web searches, more on individual products using standardized place names, which unlike lat/long is a past and future moving target!

Looks like FHv7 uses part of the 5.5.1 spec, but your export makes it fully 5.5.1 spec.

So there is no reason for me not to use the FHv7 _PLAC records.

[tatewise]

Looks like FHv7 uses part of the 5.5.1 spec, but your export makes it fully 5.5.1 spec.
So there is no reason for me not to use the FHv7 _PLAC records.

Actually, FH V6 had Lat/Longitude fields in the _PLAC records to support the Map Window and its auto-geocoding.
Maybe CP saw what was coming in the 5.5.1 draft specification.
The plugin had the Lat/Long export option for the same products with FH V6 back in 2020.