Jump to content


Photo

How to change GPS latitude/longitude format in GEDCOM output (when did this change?)


  • Please log in to reply
9 replies to this topic

#1 strathglass

strathglass
  • Senior Members
  • 117 posts

Posted 18 March 2014 - 07:47 AM

My TMG used to output GEDCOM files with latitude/longitude information in this format:

"433201N0654342W" (i.e. a contiguous string representation of the form <DD><MM><SS><N|S><DD><MM><SS><E|W>)
 
But now, regardless of how I set the display format for places in the preferences, the GEDCOM output comes out as:
"43.831944,-66.102222" (i.e. simple decimal notation).
 
Is there a way to change the output format? When did this change?
 
Regards,...


#2 Jim Byram

Jim Byram
  • Moderators
  • 7,340 posts
  • Gender:Male
  • Location:Framingham, MA

Posted 18 March 2014 - 08:28 AM

TMG switched to storing latitude/longitude values in the more precise decimal format as of v8.00. And you can't change the GEDCOM output since this is how TMG stores the data.



#3 strathglass

strathglass
  • Senior Members
  • 117 posts

Posted 18 March 2014 - 08:41 AM

OK, thanks. I will update my perl script to handle the new decimal format (need to massage that data for certain other GEDCOM consumers I use).

 

-S



#4 Jim Byram

Jim Byram
  • Moderators
  • 7,340 posts
  • Gender:Male
  • Location:Framingham, MA

Posted 18 March 2014 - 08:46 AM

Keep in mind that the old 'compass' format introduced a considerable degree of rounding imprecision to the actual GPS data that you get from the satellites. The decimal format gives you precise locations with GPS devices and with mapping systems.



#5 strathglass

strathglass
  • Senior Members
  • 117 posts

Posted 22 March 2014 - 10:45 AM

Keep in mind that the old 'compass' format introduced a considerable degree of rounding imprecision to the actual GPS data that you get from the satellites. The decimal format gives you precise locations with GPS devices and with mapping systems.

The good thing is the massaged format (as required by TNG) maintains the decimal format that TMG is exporting.

I'm assuming one of TMG and TNG is not quite compliant to the GEDCOM standard given that I have to do this massaging!!



#6 Jim Byram

Jim Byram
  • Moderators
  • 7,340 posts
  • Gender:Male
  • Location:Framingham, MA

Posted 22 March 2014 - 11:34 AM

I see nothing in the GEDCOM specs that has to do with latitude/longitude. TMG exports this data as a place level like it always has. I have no idea what you mean by "massaged format".



#7 Michael Hannah

Michael Hannah
  • Moderators
  • 2,733 posts
  • Gender:Male
  • Location:Los Ranchos, New Mexico, USA
  • Interests:Genealogy, Computers

Posted 22 March 2014 - 05:03 PM

I can confirm that the GEDCOM standard for locations only defines "names" in a sequence from the lowest to the highest jurisdiction separated by commas, for example, "Cove, Cache, Utah, USA."  No where in the GEDCOM standard is there any mention of, or expectation of, Latitude/Longitude.  I think this is yet another example of the extreme age of this standard specification.  The mere presence of Latitude/Longitude as a place level within a location could be considered an extension of the standard, and thus actually "not quite compliant to the GEDCOM standard."  There is certainly no mention of any "format" for Latitude/Longitude.


Michael
See my book on how I customize TMG My Way.
My website.

#8 strathglass

strathglass
  • Senior Members
  • 117 posts

Posted 23 March 2014 - 07:27 AM

So I guess if it is not standardized, then confusion will abound!

To answer Jim's question, the TNG software requires me to massage the GPS as follows:

If TMG outputs this line:

 

2 PLAC Our Lady of Calvary Cemetery, 134 Forest Street, Yarmouth, Yarmouth County, Nova Scotia, Canada, , , 43.831944,-66.102222

 

Then I need keep that line (but strip off the lat/long info at the end) and add new lines before the closing "0 TRLR" line:

below is what the output would look like.

Note that if a place's "2 PLAC" line occurs multiple times (e.g. I have several people listed as buried in the same cemetery), then the lines I add at the end should only add one entry per unique "2 PLAC" entry".

2 PLAC Our Lady of Calvary Cemetery, 134 Forest Street, Yarmouth, Yarmouth County, Nova Scotia, Canada

...

0 PLAC Our Lady of Calvary Cemetery, 134 Forest Street, Yarmouth, Yarmouth County, Nova Scotia, Canada
1 MAP
2 LATI 43.831944
2 LONG -66.102222

 

 


Edited by strathglass, 23 March 2014 - 08:45 AM.


#9 Michael Hannah

Michael Hannah
  • Moderators
  • 2,733 posts
  • Gender:Male
  • Location:Los Ranchos, New Mexico, USA
  • Interests:Genealogy, Computers

Posted 23 March 2014 - 10:11 AM

These GEDCOM tags and structure of "MAP, LATI, LONG" are not part of the GEDCOM standard.  Someone at some time simply "made up" those tags and that structure.  The GEDCOM standard for "Place Structure" only defines three things subordinate to the "PLAC" tag: a source citation, a note, and a "FORM" code which can indicate that the meanings of each piece of text in the slots within the place hierarchy of this string of comma-separated text is different than the default meanings for the slots of a PLAC within this output file.  There is no standard definition of dealing with Latitude/Longitude, so "confusion" is indeed allowed to abound.
 
The GEDCOM standard does permit creating "user defined" GEDCOM tags, but the standard requires any such non-standard tag names to begin with the underscore character to make it clear that they are not part of the standard. "User defined tags are discouraged but when used must begin with an under-score... and should only be interpreted in the context of the sending system."  Thus the following would be "acceptable" to the GEDCOM standard:

0 PLAC
1 _MAP
2 _LATI 43.831944
2 _LONG -66.102222

But the standard makes it clear that other software is under no obligation to recognize such user-defined tags, or import them, or export them.
 
So based on your examples, I think it is TNG which is non-standard in two ways: the existence of these non-standard tags, and the lack of a leading underscore on their names.

 

TMG is actually more standards compliant by including this data in specific added slots within the hierarchy of the string of comma-separated text.  The standard allows the exporting software to have its own definition of the meaning of what is in each slot as long as their meanings are consistent within that GEDCOM file.  (For example, it is up to the exporting software to decide that the text in slot 3 means City and slot 4 means State, or whatever.  There is no "standard" definition of what the data in each slot means.)  And it is up to the importing software to provide a way to either discard or map the text in each slot to something of equivalent meaning within its system.

 

Hope this helps understand the GEDCOM standard better.


Michael
See my book on how I customize TMG My Way.
My website.

#10 strathglass

strathglass
  • Senior Members
  • 117 posts

Posted 26 March 2014 - 04:43 PM

Thanks Michael! Good to know ... will probably follow up with Darren on the TNG side at some point about this.






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users