Jump to content
Sign in to follow this  
Followers 5
Semper Questio

Pocket Query Error II

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

Share this post


Link to post

In the other thread, there was an indication that old PQs being rerun were OK but new ones were defective.

 

Can anyone confirm that? I'm have PQs scheduled to run tomorrow that I'm going to disable unless I know they will work OK.

Share this post


Link to post

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

Share this post


Link to post

An individual .gpx i downloaded worked fine. I have not tested a GPX file. I think the only things I have is from last Sunday or Monday.

Share this post


Link to post

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

Share this post


Link to post
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.)

Share this post


Link to post

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

Share this post


Link to post

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

Share this post


Link to post

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

Share this post


Link to post

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

 

Just got them on their way. Thanks!

Share this post


Link to post

Raine, I just forwarded the 4 PQs I ran a few minutes ago to your email address. The GPX files work fine when copied to my Colorado 400t but will not load into GSAK. I haven't updated GSAK in a long time so I know it isn't a change on their end.

Edited by Team GPSaxophone

Share this post


Link to post

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.

Share this post


Link to post
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'.

Share this post


Link to post

What version of GSAK are we talking about and with what results?

 

I am 6.6.5 build 20 and get the error

 

Sorry, should have stated...Raine and I have been working with my files. They work in his environment - GSAK Version 7.5.1.28

Edited by Semper Questio

Share this post


Link to post

I use 6.6.5 Build 19.

 

Raine said something about using full unicode in the XML now (whatever that means). He is using 7.5.1.28 and it is working fine for him, but it appears the older version of GSAK is choking on the XML changes. I guess I'll have to wait and see what Clyde can do about it.

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post

GPX wil not open with anything we own...A new PQ generated Sat morning...??

 

"The expected file header format cannot be read...."

Share this post


Link to post
...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:

Share this post


Link to post

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.

Share this post


Link to post

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!

Share this post


Link to post

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

Share this post


Link to post
...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??

Share this post


Link to post

 

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

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post

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

Share this post


Link to post

 

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

Share this post


Link to post

I tried switching the "xsi" and "xsd" as mentioned in this thread and it then worked in GSAK and Cachemate.

Share this post


Link to post

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

Share this post


Link to post

I just ran another pq of the closest to my home and the result was a gpx file that worked as expected in both MacGpsPro and MacCaching.

 

Thanks for the quick fix. you guys are the best.

Share this post


Link to post

GPX edit fix does not work on GSAK 6. Still get the same error.

 

Any other fixes for GSAK 6?

Share this post


Link to post

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!

Share this post


Link to post

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

Share this post


Link to post

I've just released a new version that does not include those "helpful" things.

 

Thanks a lot for this quick fix, it works for my version of Cachemate now :D

 

I'm off caching :unsure:

 

Heiko

Share this post


Link to post

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

Share this post


Link to post

Thanks for the good and fast work! GSAK 6.6.5 build 20 is working again! :)

Share this post


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.

 

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 :) .

Share this post


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

Edited by benh57

Share this post


Link to post

$30 annual PM fee. 365 days in a year. $30÷365=.082

 

When can I expect a check for the day I was without usable PQs?

 

 

 

 

 

 

Thanks for fixing this right away.

Share this post


Link to post

 

Not that you will understand this, but .......

 

Oh........

 

Yet my text editor allowed me to see it and copy it.

 

Yes I did understand what you wrote and made sense after the coma.

Share this post


Link to post
Guest
This topic is now closed to further replies.
Sign in to follow this  
Followers 5

×