strathglass 0 Report post Posted March 18, 2014 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,... Share this post Link to post Share on other sites
Jim Byram 0 Report post Posted March 18, 2014 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. Share this post Link to post Share on other sites
strathglass 0 Report post Posted March 18, 2014 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 Share this post Link to post Share on other sites
Jim Byram 0 Report post Posted March 18, 2014 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. Share this post Link to post Share on other sites
strathglass 0 Report post Posted March 22, 2014 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!! Share this post Link to post Share on other sites
Jim Byram 0 Report post Posted March 22, 2014 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". Share this post Link to post Share on other sites
Michael Hannah 0 Report post Posted March 23, 2014 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. Share this post Link to post Share on other sites
strathglass 0 Report post Posted March 23, 2014 (edited) 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 March 23, 2014 by strathglass Share this post Link to post Share on other sites
Michael Hannah 0 Report post Posted March 23, 2014 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. Share this post Link to post Share on other sites
strathglass 0 Report post Posted March 27, 2014 Thanks Michael! Good to know ... will probably follow up with Darren on the TNG side at some point about this. Share this post Link to post Share on other sites