Jump to content

Change to .LOC format


Kloudbuster

Recommended Posts

I tried to open a .loc file that I downloaded today with Mapsource and I got an error message saying it could not be opened.

 

The current .loc file looked like this:

 

<?xml version="1.0" encoding="UTF-8" ?>

- <loc version="1.0" src="Groundspeak">

- <waypoint>

- <name id="GC2BZCC">

- <![CDATA[ Webb Road Waterfall by poisonlady

]]>

</name>

<coord lat="37.694583" lon="-97.227017" />

<type>Geocache</type>

<link text="Cache Details">http://www.geocaching.com/seek/cache_details.aspx?wp=GC2BZCC</link>

<difficulty>3</difficulty>

<terrain>1.5</terrain>

<container>2</container>

</waypoint>

</loc>

 

Looking at an older .Loc file I noticed that the difficulty, terrain and container information was not included. I removed that information leaving:

 

<?xml version="1.0" encoding="UTF-8" ?>

- <loc version="1.0" src="Groundspeak">

- <waypoint>

- <name id="GC2DNC9">

- <![CDATA[ Cross-Town Rivals - FNL Series #10 by frog4peace

]]>

</name>

<coord lat="37.73715" lon="-97.156433" />

<type>Geocache</type>

<link text="Cache Details">http://www.geocaching.com/seek/cache_details.aspx?wp=GC2DNC9</link>

</waypoint>

</loc>

 

Is this a temporary programming error on Groundspeaks part or a "new standard" that Mapquest now will not recogize?

 

Bob Brown

Link to comment

I don't know. .loc was always pretty informally defined. XML readers should ignore unknown tags.

 

I know this weekend that a fellow geocaching programmer submitted a patch to add these changes to GPSBabel and I submitted them when I got home, so GPSBabel built from source from this week will read and write these. (Thanx, Rick!)

Link to comment

I tried to open a .loc file that I downloaded today with Mapsource and I got an error message saying it could not be opened.

 

The current .loc file looked like this:

 

<?xml version="1.0" encoding="UTF-8" ?>

- <loc version="1.0" src="Groundspeak">

- <waypoint>

- <name id="GC2BZCC">

- <![CDATA[ Webb Road Waterfall by poisonlady

]]>

</name>

<coord lat="37.694583" lon="-97.227017" />

<type>Geocache</type>

<link text="Cache Details">http://www.geocaching.com/seek/cache_details.aspx?wp=GC2BZCC</link>

<difficulty>3</difficulty>

<terrain>1.5</terrain>

<container>2</container>

</waypoint>

</loc>

 

Looking at an older .Loc file I noticed that the difficulty, terrain and container information was not included. I removed that information leaving:

 

<?xml version="1.0" encoding="UTF-8" ?>

- <loc version="1.0" src="Groundspeak">

- <waypoint>

- <name id="GC2DNC9">

- <![CDATA[ Cross-Town Rivals - FNL Series #10 by frog4peace

]]>

</name>

<coord lat="37.73715" lon="-97.156433" />

<type>Geocache</type>

<link text="Cache Details">http://www.geocaching.com/seek/cache_details.aspx?wp=GC2DNC9</link>

</waypoint>

</loc>

 

Is this a temporary programming error on Groundspeaks part or a "new standard" that Mapquest now will not recogize?

 

Bob Brown

 

Just curious if you meant MapSource rather than MapQuest? I tried to load a few .loc files directly from Geocaching.com, as I have in the past, and I'm getting a message that says they "can't be imported". I'm using MapSource. I even downloaded the files to my HD and they won't open either. Hoping someone can come up with an answer.

 

David

Link to comment

I tried to open a .loc file that I downloaded today with Mapsource and I got an error message saying it could not be opened.

 

The current .loc file looked like this:

 

<?xml version="1.0" encoding="UTF-8" ?>

- <loc version="1.0" src="Groundspeak">

- <waypoint>

- <name id="GC2BZCC">

- <![CDATA[ Webb Road Waterfall by poisonlady

]]>

</name>

<coord lat="37.694583" lon="-97.227017" />

<type>Geocache</type>

<link text="Cache Details">http://www.geocaching.com/seek/cache_details.aspx?wp=GC2BZCC</link>

<difficulty>3</difficulty>

<terrain>1.5</terrain>

<container>2</container>

</waypoint>

</loc>

 

Looking at an older .Loc file I noticed that the difficulty, terrain and container information was not included. I removed that information leaving:

 

<?xml version="1.0" encoding="UTF-8" ?>

- <loc version="1.0" src="Groundspeak">

- <waypoint>

- <name id="GC2DNC9">

- <![CDATA[ Cross-Town Rivals - FNL Series #10 by frog4peace

]]>

</name>

<coord lat="37.73715" lon="-97.156433" />

<type>Geocache</type>

<link text="Cache Details">http://www.geocaching.com/seek/cache_details.aspx?wp=GC2DNC9</link>

</waypoint>

</loc>

 

Is this a temporary programming error on Groundspeaks part or a "new standard" that Mapquest now will not recogize?

 

Bob Brown

 

Just curious if you meant MapSource rather than MapQuest? I tried to load a few .loc files directly from Geocaching.com, as I have in the past, and I'm getting a message that says they "can't be imported". I'm using MapSource. I even downloaded the files to my HD and they won't open either. Hoping someone can come up with an answer.

 

David

 

David,

 

I'm sorry! I meant MapSource! To top it all off, there is a new update to MapSource but fails on loading.

 

Bob

Link to comment

Not sure the answer to your specific question as I do not use .loc or mapsource but have you tried using gsak? I have Mapsource installed but never use it because GSAK does everything I could imagine.

 

What is it that you are trying to accomplish, maybe we can find a temporary work around.

 

I do use GSAK mainly for poi's, my records and uploading my status to GC.com. Although there are times I just want to take a choice few caches (.loc files) into Mapsource to edit notes or other details plus I can get an idea of the entire grouping of the selected caches on the Mapsourse map. I could click the ticks next to the caches I want to save from GC.com and they would auto open Mapsource, I can edit and send directly from Mapsource to my map60. Probably for another thread but I can't figure out how to choose just a few caches in a GSAK database to send to my GPS as .loc files, it sends the entire database to my Map60.

Link to comment

I don't know. .loc was always pretty informally defined. XML readers should ignore unknown tags.

To reinforce this point, if software can't cope with extra data in .loc files, it is the software's fault and you should approach the developer of the software to rectify it.

 

As Robert mentioned, when [well written] software is reading this kind of file (XML) and it comes across something it doesn't expect or understand, the software should disregard it, not throw a hissy fit and spit out an error. After all, the data that MapSource was expecting to find (waypoint name and coordinates) is still there and failing to handle or gracefully ignore any extra data that the producer of the file has included is a sign of shoddy software design/coding.

 

Take it up with Garmin! :)

Link to comment

I don't know. .loc was always pretty informally defined. XML readers should ignore unknown tags.

To reinforce this point, if software can't cope with extra data in .loc files, it is the software's fault and you should approach the developer of the software to rectify it.

 

As Robert mentioned, when [well written] software is reading this kind of file (XML) and it comes across something it doesn't expect or understand, the software should disregard it, not throw a hissy fit and spit out an error. After all, the data that MapSource was expecting to find (waypoint name and coordinates) is still there and failing to handle or gracefully ignore any extra data that the producer of the file has included is a sign of shoddy software design/coding.

 

Take it up with Garmin! :)

 

+1. Technically, because the .loc file does not contain a DTD or schema reference an xml parser has no way of validating what fields might be included, thus none of the elements are really "extra".

 

I just took a look at an old and newer version of .loc files and confirmed that newer versions contained the additional elements. I also opened up a "new" .loc file from a cache page with the latest version of ExpertGPS. It didn't blow up but it also incorrectly displayed the values for the difficulty, terrain, and container elements. It does, however, parse those values correctly from the gpx file for the same cache.

 

Any idea when the additional fields were added?

Link to comment

Probably for another thread but I can't figure out how to choose just a few caches in a GSAK database to send to my GPS as .loc files, it sends the entire database to my Map60.

 

The easiest way is to just create a separate database, flag the caches you want to send from the original database and copy the waypoints to the second database. Then switch to the second database and send the waypoints.

 

A Map60 GPS doesn't store waypoints as .loc files. It uses some internal memory to store waypoints but they're not stored as "files". The GSAK app may parse the .loc (or gpx) files on your computer but then just uses a bit of code to send the waypoint information to the specific GPS device you defined in a format that the device understands.

Link to comment

Probably for another thread but I can't figure out how to choose just a few caches in a GSAK database to send to my GPS as .loc files, it sends the entire database to my Map60.

 

The easiest way is to just create a separate database, flag the caches you want to send from the original database and copy the waypoints to the second database. Then switch to the second database and send the waypoints.

 

 

Or you could skip the separate database step. Just set the user flag for the caches you want, filter on "User flag set," and then send to GPS.

Link to comment

My suggestion is that Groundspeak get rid of the LOC format entirely, and use a minimal GPX file for non-premium members. The LOC file is obsolete; it was an early XML format from which the GPX standard was derived.

 

+1. I was thinking the same thing yesterday. Basic members would get a GPX file without the Groundspeak extensions. Premium members would get a GPX file with them. It would probably even simplify the code on the web site because the same code could be used to create both.

Link to comment

"Minimal GPX" was proposed and ratified in principle years ago by Jeremy, IIRC. I don't know why LOC is getting life support. I wonder if this is some internal poor-man's API and they needed the extra fields for a map or something.

 

But just as there are broken LOC readers that can't cope with change, you can be sure there are broke GPX readers that can't cope with it, too. Imagine the whining if, say, a discontinued Colorado crash if there was no Groundspeak:container tag. (That's a made up case - I'm not picking on Garmin.) Remember about a year ago when PQs were changed in a completely legal and tasteful way and Delorme's software couldn't handle it?

 

It's probably less risky to change .loc since it's not baked into GPS receiver firmware...

Link to comment

One thing I will mention that I do find rather inconsistent - the container in the Loc file is just a number, where as the in the GPX file it is the more common text version. Other than trial and error I can't find a "legend" to map the number to the corresponding description.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...