Jump to content

Pocket Query Error II


Recommended Posts

The versions of CacheMate that had a problem with the PQ file changes are now updated, and things are working properly again.

 

There... crisis abated. Back to working on the Google Android version of the app...

Link to post

I've been having trouble recently with the PQ's as well (used to work fine). I'm using GPXSonar. The new zipped PQ's won't load properly (GPXSonar uses the zipped file directly). The problem actually seems to be the -wpts.gpx file. If I open the zipped file, remove the -wpts.gpx file. Rezip it with just the standard .gpx file, then it will work fine.

But this is a very cumbersome process since I cannot do this directly on my pocket pc.

 

If there was an option to just get a .gpx file in a PQ, rather than both the .gpx and -wpts.gpx, that would solve the problem for me.

Edited by ClubMCR
Link to post

This is a puzzle, :) a pq generated before the current fix - when unzipped -- resulted in a gpx file that was useless to our programs and began the discussions on this and other forum threads.

 

When you open the useless file in a text editor - make no changes at all - then save it back to the same gpx file - it works fine.

 

Ok what changed during this process? The two files look identical. Except for (Ôªø) symbols at the the beginning of the file.

 

Seems like I have seen these symbols written about in the forums earlier this year. Still don’t know how they are helpful.

Not that you will understand this, but those would be the UTF-8 BOM (byte order mark) indicating that the file is UTF-8, UTF-16 or UTF-32 encoded. It's only required for UTF16 and 32, though.

http://en.wikipedia.org/wiki/Byte-order_mark

Some older, out of date programs can't handle a BOM at the beginning of a file.

 

"While UTF-8 does not have byte order issues, a BOM encoded in UTF-8 may nonetheless be encountered, and it is explicitly allowed by the Unicode standard, the Unicode standard does not specifically recommend its

usage"

 

Since Groundspeak uses UTF8, it would probably be best if they do not include the BOM since it's not necessarily needed for UTF8. (though it should be allowed, apparently many programs can't handle it)

 

(oh, and the reason they 'go away' when you save the file is you're using an older text editor that can't handle the BOM)

 

-Ben

Thanks for the above explanation. It all makes sense. As one who has dabbled in programming since the 80's, I've found that a high percentage of problems end up being some very small oversight in the code. Sometimes it's a (-) versus a (+) or a single typo or, as in the recent problem with the.loc files, it was the missing "o" in "cord" vs. "coord".

 

The difficulty is find the "oops". This one I'd rate as a D-2.5.

Link to post

I've been having trouble recently with the PQ's as well (used to work fine). I'm using GPXSonar. The new zipped PQ's won't load properly (GPXSonar uses the zipped file directly). The problem actually seems to be the -wpts.gpx file. If I open the zipped file, remove the -wpts.gpx file. Rezip it with just the standard .gpx file, then it will work fine.

But this is a very cumbersome process since I cannot do this directly on my pocket pc.

 

If there was an option to just get a .gpx file in a PQ, rather than both the .gpx and -wpts.gpx, that would solve the problem for me.

 

Same problem here since some 14 days... altough using the explorer on my windows mobile phone I'm able to open the .zip file and delete the "wpts" file. After that the PQ opens perfectly.

 

Is it possible that GPXSonar simply opens the first file it encounters in the zip file? If so, and if this was changed bij Groundspeak, is it possible for the people at Groundspeak to change this file order? Or indeed include an option in the PQ config to leave the aditional WP's out.

 

I would be very gratefull!

 

lennie1975

Link to post

Ok don't know where else to post and not shore when it started.

 

When I go into My PQs page I see alist of PQs I have but now when I click on the icon which should alow me to preview in google maps, all I get when this button is clicked is the standard Green Lake background and the bubble which says Requesting Geocaches. I even tried leaving it but after 15 mintues it was still requesting geocaches.

 

If this should be else where please let me know and I will post it there.

Link to post
Ok don't know where else to post and not shore when it started.

 

If this should be else where please let me know and I will post it there.

 

This should probably be a new thread to draw the appropriate attention to it, since it isn't really related to the problem in this thread.

 

I just checked and I don't have the same problem you have, but a new thread with a title "PQ Preview does not work" (or something like that) would probably get you better suggestions.

Link to post

I have read through this thread, but still don't quite understand what is going on. The new PQ's look different to the older PQs (see examples below - this has also been mentioned earlier in this thread). GSAK does not have a problem, but my self written Excel code that reads PQs and splits them into groups of <200 caches as required by my GPS does not. I read Raines comment about UTF8 but it is Greek to me. The old layout made lots of sense to me and my VBA code as the keywords were always at the beginning of a line.

 

My questions are:

(1) Why has it changed and

(2) what exactly has changed (so that I can alter my coding accordingly)

(3) is this a permanent change - will all future PQs look like the new version (I seemed to get another PQ recently that still looked like the old version)

 

Thanks

 

NEW VERSION:

<?xml version="1.0" encoding="utf-8"?><gpx xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" version="1.0" creator="Groundspeak Pocket Query" xsi:schemaLocation="http://www.topografix.com/GPX/1/0 http://www.topografix.com/GPX/1/0/gpx.xsd http://www.Groundspeak.com/cache/1/0 http://www.Groundspeak.com/cache/1/0/cache.xsd" xmlns="http://www.topografix.com/GPX/1/0"><name>Stellenbosch</name><desc>Geocache file generated by Groundspeak</desc><author>Groundspeak</author><email>contact@Groundspeak.com</email><time>2009-05-07T04:04:25.3480818-07:00</time><keywords>cache, geocache, Groundspeak</keywords><bounds minlat="-34.432683" minlon="18.309217"

 

OLD VERSION:

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

<gpx xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" version="1.0" creator="Groundspeak Pocket Query" xsi:schemaLocation="http://www.topografix.com/GPX/1/0 http://www.topografix.com/GPX/1/0/gpx.xsd http://www.Groundspeak.com/cache/1/0 http://www.Groundspeak.com/cache/1/0/cache.xsd" xmlns="http://www.topografix.com/GPX/1/0">

<name>StbV2</name>

<desc>Geocache file generated by Groundspeak</desc>

<author>Groundspeak</author>

Edited by the pooks
Link to post
GSAK does not have a problem, but my self written Excel code that reads PQs and splits them into groups of <200 caches as required by my GPS does not.

 

I know this isn't a direct answer to your question and assuming that you meant your Excel code does (rather than "does not") have a problem...

 

Are you aware that you could limit the 200 caches sent to your GPS with GSAK?

Link to post
GSAK does not have a problem, but my self written Excel code that reads PQs and splits them into groups of <200 caches as required by my GPS does not.

 

I know this isn't a direct answer to your question and assuming that you meant your Excel code does (rather than "does not") have a problem...

 

Are you aware that you could limit the 200 caches sent to your GPS with GSAK?

 

Yes thanks beejay: I have used the 200 caches GSAK macro. I wrote the VBA code before I knew about the GSAK mersion (took a while, I have to admit - finding out about checksums for instance). But I still like my Excel version - I split the PQ into overlapping circles of caches - but the nice part of it is that I can change centrepoints and radii and see immediately if the caches are <200 and if any have fallen out of the net - so easier to fine-tune.

Link to post

I don't see anything different other than the line breaks. It's valid XML.

 

-Raine

 

I concede that it is valid XML. I have imported the PQ (new version - without line breaks) into GSAK, GPSBabel (which is what GSAK uses, so the same thing really) and Mapsend Lite and exported it as a GPXs and they all save with line breaks, so it seems that although the XML without line breaks is valid it is unusual. I was just curious to know if there was a reason for the change.

Link to post

I have developed a workaround: I made a batch file that invokes GPSbabel to import the gpx files ("New Format") and export them as GPX files again (these are then in "old Format"). So with one click I convert all the required gpx files to a format that my custom program recognizes. I use GPSbabelGUI for single conversions and to guide me regarding the correct format for the batch file. Easy enough for now. Thanks

Link to post
Guest
This topic is now closed to further replies.
×
×
  • Create New...