Jump to content

Pocket Query Error II


Semper Questio

Recommended Posts

Just gen'd a PQ a little while ago, downloaded it, and tried to pull it into GSAK and I got this message window. This was reported in another thread about .loc files. It appears that this just started some time today. It's been reported on the GSAK forum also, but I know I have not changed anything in my GSAK for quite a while so I suspect there's somethin' screwy with the file itself.

 

gpxerror.JPG

 

(Image copied from post in other thread. My error is the same, just a different file name.)

Edited by Semper Questio
Link to comment

Just gen'd a PQ a little while ago, downloaded it, and tried to pull it into GSAK and I got this message window. This was reported in another thread about .loc files. It appears that this just started some time today. It's been reported on the GSAK forum also, but I know I have not changed anything in my GSAK for quite a while so I suspect there's somethin' screwy with the file itself.

 

gpxerror.JPG

 

(Image copied from post in other thread. My error is the same, just a different file name.)

 

I just ran a PQ. It generated and in my e-mail in no time. Downloaded to desktop and "drag and drop" into GSAK with NO issues. All is well here. Ready for the weekend.

Kayak-Cowboy

Link to comment

I think that it had to do with .net stripping out the encoding-utf8 from the xml element. I made a hotfix for this already. SQ: I'll regenerate a few of the last ones you just did and you can try them out again.

 

-Raine

 

Just got the regens, tried them, and got the same thing. Could this be a .NET version incompatability issue? Would explain some getting the problem and some not.

 

Interesting note...looks like the child waypoints are making it through fine.

Edited by Semper Questio
Link to comment

This is strange as I'm testing these PQ's against GSAK and EasyGPS and they work just fine for me.

 

Can you forward those 4 that you just got to me @ Groundspeak.com

 

Thanks

 

-Raine

 

That was my error message that SQ quoted from the other thread. Can you look specifically at the PQ I generated #1600206, and test it?

 

Or, could you regenerate 1600206 for me?

 

Thanks.

-David

Edited by David
Link to comment

This is strange as I'm testing these PQ's against GSAK and EasyGPS and they work just fine for me.

 

Can you forward those 4 that you just got to me @ Groundspeak.com

 

Thanks

 

-Raine

 

That was my error message that SQ quoted from the other thread. Can you look specifically at the PQ I generated #1600206, and test it?

 

Or, could you regenerate 1600206 for me?

 

Thanks.

-David

 

I got the new copy and it performs the same way. Same GSAK error. PQs from yesterday work fine.

Link to comment
Presuming this is a valid XML file, it looks like a GSAK issue.

 

Try running the GPX file through http://www.validome.org/xml/

 

That would seem right...except GSAK hasn't changed and we know PQs are being changed here. (The LOC files got "coord" wrong a few days ago.)

 

No, that still doesn't mean Groundspeak is doing anything wrong. The problem is GSAK rejecting a file because it thinks it's not valid GPX. Groundspeak could have changed the GPX format to another perfectly valid format, which the (out of date GSAK) does not believe is 'correct'.

Link to comment

I saw a similar message this morning when I downloaded my "my finds" PQ (thus a GPX file) which was generated last Monday. I re-downloaded the file and tried again (both 'drag-n-drop' to GSAK) and it worked fine. I assumed it was just a bad download.

 

I use Gmail for email and my GSAK is the most current, 7.5.1.28.

Link to comment

Hi,

 

I would like to add that GSAK does not seem to be the only program having problems with the "new" GPX files. An older version of gpsbabel crashed, but I solved this by updating to the newest version of gpsbabel. But even more annoying, Cachemate (for PocketPC, newest version 1.3.4) does not import the "new" GPX files, which essentially means, no caching for me :laughing:

 

Regards,

Heiko

Link to comment

It not just gsak

 

I just ran a pq of our total finds and the resulting gpx file is useless.

 

I use macaching and get a similar error message, i tried loading it into MacGpsPro and it does not work either.

 

Seem so have started after the .loc problem was fixed, are they related?

 

b70d7192-2997-405a-9f74-91d80f771072.jpg

 

173a6900-df17-4c44-aa87-713d04ac0461.jpg

 

I opened it up in a text editor and can see the billion of text, but an obvious problem did not pop up.

 

It is possible I can fix my file in a text editor. What is the header supposed to look like? I did not keep any of the older gpx files to compare.

Link to comment

Hi,

 

I would like to add that GSAK does not seem to be the only program having problems with the "new" GPX files. An older version of gpsbabel crashed, but I solved this by updating to the newest version of gpsbabel. But even more annoying, Cachemate (for PocketPC, newest version 1.3.4) does not import the "new" GPX files, which essentially means, no caching for me :laughing:

 

Regards,

Heiko

 

YIKES! If Cachemate doesn't like it either a LOT of people are in trouble! The Palm version has not been updated in ages!

Link to comment

OK, now I don't know for sure, but I looked at an old PQ and a new one.

 

OLD:

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

<gpx xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 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>500 nearest, unfound, updated 7 days </name>

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

<author>Groundspeak</author>

<email>contact@Groundspeak.com</email>

<time>2009-01-30T19:42:03.8962981-08:00</time>

<keywords>cache, geocache, Groundspeak</keywords>

 

NEW:

<?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>100 mile: 12</name><desc>Geocache file generated by Groundspeak</desc><author>Groundspeak</author><email>contact@Groundspeak.com</email><time>2009-04-25T00:06:27.0951581-07:00</time><keywords>cache, geocache, Groundspeak</keywords>

 

It appears that the newer versions don't have CR/LF in the file. I don't know if that is a "problem" but it would explain the "very long lines" messages one of you is receiving. (The "new line" you see in the above for "new" is due to screen size and not because of a CR/LF forcing a new line.)

 

I would suggest anyone having a problem be very clear on what program and version number is failing. (For instance, it appears some old version of GSAK fail. The newest version is working for me.) It may be Groundspeak is following the standard, but a number of programs may not be able to handle the change they've made.

Edited by beejay&esskay
Link to comment
...which essentially means, no caching for me :laughing:

Boy, aren't we the drama queen today. None of the other dozen ways of getting data to your GPS or PDA will work, eh? There's always (gasp!) paper. :laughing:

 

How about showing a little respect to a fellow cacher??

Link to comment

 

OLD:

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

<gpx xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-

 

NEW:

<?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

 

Who Hoooo!! you found it!!!

 

The first line of the new has an xsi where it should be xsd

 

I changed the little letter in the text file and it now works beautifully.

 

 

Thanks :laughing:

Edited by geode hunter
Link to comment

Just another note

 

The fix I mentioned above worked fine in MacGpsPro and I was able to view all the caches on the map.

 

one more fix had to be made to be readable in MacCaching ( gsak on steroids)

 

<?xml version="1.0" encoding="utf-8"?><gpx xmlns:xsd="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema" version="1.0" creator="Groundspeak Pocket Query"

 

Apparently the xsd needs to be first then the xsi

 

Hope this helps

 

I use cachemate as well and have not yet check the gpx file conversion, but if it does not export maybe the gsak or maccaching programs out there will re-export the files to a gpx that will be usefull.

 

Just trying to live in this windows world. :laughing:

Edited by geode hunter
Link to comment

I tried all of the fixes suggested in this thread. None of them worked in GSAK version 6.6.4 build 20. The fact is that the PQs I received on Thursday morning worked. The PQs I received last night and this afternoon don't work. Blame it on GSAK if you want, but the GSAK program didn't change between Thursday and today, so the change is clearly a problem with the PQ generation. It appears that since there are at least three different threads going on about the same subject, that the problem is affecting a lot of people. So it seems to me that the users shouldn't be the ones that have to figure out how to fix the problem, the folks at Groundspeak should.

 

Folks, you don't need anyone to email their PQs to you. You need to get the PQ generator back to working the way it did Thursday morning. It's that simple.

Link to comment

I am having the same problem with a PQ I generated today. I'm using GSAK...build 20 (just updated today), but had the same problem with the previous build (earlier today). I was hoping that build 20 would correct the problem but I guess not. Do I have to get the GSAK 7.5.1.128? I haven't used GC or GSAK since last fall.

Edited by MillsideMan
Link to comment

BOTH PQs I ran today give the same error; one of those was the MYFINDS query.

 

HOWEVER, an older PQ file still on my desktop ran fine! So, it IS something from today's PQs.

 

Never had any problems with PQs in the past.

 

Using GSAK registered version 6.6.5 Build 20 as I have for a long time.

Edited by michigansnorkelers
Link to comment

 

Who Hoooo!! you found it!!!

 

The first line of the new has an xsi where it should be xsd

 

I changed the little letter in the text file and it now works beautifully.

 

 

Thanks :unsure:

 

Well, it seems YOU are the one to spot a significant difference. Glad I could help by supplying an old file.

Edited by beejay&esskay
Link to comment

The fact that you switch the XSI and XSD tags isn't what fixes it. It's saving the file again. It removes a little piece of information that was recently added to the PQ XML files that tells a "reader" of the document some information about how it's written.

 

In the recent change of the PQ Generator, we updated it to .Net 3.5. This change caused this information which is normally ok to be added to the documents. I've just released a new version that does not include those "helpful" things.

 

Please report any other issues, and happy caching!

 

-Raine

Link to comment

The fact that you switch the XSI and XSD tags isn't what fixes it. It's saving the file again. It removes a little piece of information that was recently added to the PQ XML files that tells a "reader" of the document some information about how it's written.

 

In the recent change of the PQ Generator, we updated it to .Net 3.5. This change caused this information which is normally ok to be added to the documents. I've just released a new version that does not include those "helpful" things.

 

Please report any other issues, and happy caching!

 

-Raine

 

Raine,

 

I just ran my 2 usual PQ's and loaded them into GSAK no problem. Thanks a ton!

Link to comment

Still broken for me. Why were the tabs and CRLFs stripped out, and can they be returned? Sometimes there are characters that cause problems, but you could at least open up the PQ and read it and maybe fix it. Now it's all crammed together. It can't to make the file smaller, since the zipping process will deal with that. Can we get the old formatting back?

Edited by Prime Suspect
Link to comment

CMConvert (the program that does GPX/LOC conversion for CacheMate) doesn't appear to be affected, but the Windows Mobile versions of CacheMate are. I'm working on fixes there, and should be able to get those out today or tomorrow.

Edited by Maeglin
Link to comment

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.

 

Upon closing the gpx file in the text editor it strips these symbol away and the file becomes useful to the mapping and geocaching programs.

 

I bet someone could use this in reverse to make a file that will not allow copies to be made :) .

Link to comment

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

Edited by benh57
Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...