LOC file format problem

[+sloth96]

Hello,

 

GSAK was complaining about a LOC file having mismatched tags. When I went in and checked manually, the tags did seem to be mismatched.

 

The list was created in the following manner:

go to http://www.geocaching.com/bookmarks/view.aspx?guid=0045c8ed-3264-461c-982e-252931737834

The set results per page to 1000

click the check mark.

Then click Download to .LOC

 

This then resulted in the LOC file that had a mismatched tag. The error appeared in line 282 if iirc.

 

Thanks.

 

Sloth96

[+sloth96]

xmllint agrees with gsak that the xml is not quite right.

[+NYPaddleCacher]

xmllint agrees with gsak that the xml is not quite right.

 

I couldn't even download the .LOC file. Clicking on the Download to .LOC button just reloads the page (in Chrome and IE). I was able to create a PQ from it which saved the list as a .LOC file and it didn't seem to have an problems.

[+Kalkendotters]

The error is caused by the fact that 'GC4W3TZ Mega-Event Cache 2015-08-01 - M3 - Maritime Mega Moncton' is unpublished (retracted?).

If the cache is not published, some internal check makes sure that you dont get the coordinates. This also cause the xml-file to be misformed. It 'forgets' to start the cache with '<waypoint><name id="GC4W3TZ">'

 

(to download the list you have either to click all the checkboxes, or the checkmark in the header to mark them all)

[+NYPaddleCacher]

xmllint agrees with gsak that the xml is not quite right.

 

I couldn't even download the .LOC file. Clicking on the Download to .LOC button just reloads the page (in Chrome and IE). I was able to create a PQ from it which saved the list as a .LOC file and it didn't seem to have an problems.

 

FIrst, I realized that I wasn't getting a download because I hadn't selected any caches from the list.

 

I found where issue is though. When I looked at the XML, where the second to last cache on the list should be listed (2015-08-01 - M3 - Maritime Mega Moncton) , the xml is missing the opening waypoint tag. Showing the previous waypoint and the problem waypoint looks like this:

 

<waypoint>
<name id="GC50FTF"><![CDATA[Mainz Gutenberg 2015 by Gutenberg-Team]]>
</name>
<coord lat="50.001667" lon="8.275917"/>
<type>Geocache</type>
<link text="Cache Details">http://www.geocaching.com/seek/cache_details.aspx?wp=GC50FTF</link>
<difficulty>1</difficulty>
<terrain>1</terrain>
<container>6</container>
</waypoint>

<![CDATA[Thanks for Playing by Nice Try]]></name>
<coord lat="0" lon="0"/>
<type>Geocache</type>
<link text="Cache Details">http://www.geocaching.com/</link>
</waypoint>

 

As you can see, the second waypoint is missing "<waypoint> <name id="GC4W3TZ>

If you try clicking on the link for that event you'll see that it's unpublished. There seems to be in issue in generating the LOC from a bookmark list when it contains an unpublished cache. I think you could just uncheck that cache to exclude it and it will generate the correct LOC.

When the bookmark was saved as a PQ it didn't include the malformed xml for the unpublished and also excluded the waypoint for the previous event in the list.

 

 

[+ecanderson]

There's no 'unchecking' it if you're picking it up using the "Lite" method in GSAK. Needs to be excluded by cache type instead, I would imagine.

[+Lil Devil]

The problem will go away on August 1.

[+ecanderson]

For THAT cache, yes -- but it could just as easily happen again unless the coding is corrected.

[+sloth96]

The problem will go away on August 1.

of 2015 or 2014?

[+ecanderson]

When the event actually occurs on 1 August 2014 and gets published, I suspect. But there is no reason another like this cannot occur again later, causing the same problem, which is why the code that creates the XML should be fixed NOW.

[+sloth96]

As was predicted by Lil Devil, this appeared to go away on August 1.

 

As ecanderson pointed out, this appears to be because the data changed.

 

Hopefully a software change also occured to prevent this from happening again with different data.

 

Thanks all.

 

Sloth96