+Semper Questio Posted April 24, 2009 Share Posted April 24, 2009 (edited) 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. (Image copied from post in other thread. My error is the same, just a different file name.) Edited April 24, 2009 by Semper Questio Link to comment
+beejay&esskay Posted April 24, 2009 Share Posted April 24, 2009 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. Link to comment
+kayak-cowboy Posted April 24, 2009 Share Posted April 24, 2009 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. (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
+Semper Questio Posted April 24, 2009 Author Share Posted April 24, 2009 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. Link to comment
+benh57 Posted April 24, 2009 Share Posted April 24, 2009 Presuming this is a valid XML file, it looks like a GSAK issue. Try running the GPX file through http://www.validome.org/xml/ Link to comment
+Raine Posted April 24, 2009 Share Posted April 24, 2009 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 Link to comment
+beejay&esskay Posted April 24, 2009 Share Posted April 24, 2009 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.) Link to comment
+Semper Questio Posted April 24, 2009 Author Share Posted April 24, 2009 (edited) 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 April 24, 2009 by Semper Questio Link to comment
+beejay&esskay Posted April 24, 2009 Share Posted April 24, 2009 I just ran a new (route) PQ created after Raine's fix and it loaded into GSAK OK. Link to comment
+Raine Posted April 24, 2009 Share Posted April 24, 2009 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 Link to comment
+David Posted April 24, 2009 Share Posted April 24, 2009 (edited) 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 April 24, 2009 by David Link to comment
+Semper Questio Posted April 24, 2009 Author Share Posted April 24, 2009 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! Link to comment
+Team GPSaxophone Posted April 24, 2009 Share Posted April 24, 2009 (edited) 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 April 24, 2009 by Team GPSaxophone Link to comment
+David Posted April 24, 2009 Share Posted April 24, 2009 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
+benh57 Posted April 24, 2009 Share Posted April 24, 2009 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
+Semper Questio Posted April 25, 2009 Author Share Posted April 25, 2009 (edited) 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 April 25, 2009 by Semper Questio Link to comment
+Team GPSaxophone Posted April 25, 2009 Share Posted April 25, 2009 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. Link to comment
+Allanon Posted April 25, 2009 Share Posted April 25, 2009 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
+wind.chill Posted April 25, 2009 Share Posted April 25, 2009 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 Regards, Heiko Link to comment
+JoenGPS Posted April 25, 2009 Share Posted April 25, 2009 GPX wil not open with anything we own...A new PQ generated Sat morning...?? "The expected file header format cannot be read...." Link to comment
+Lil Devil Posted April 25, 2009 Share Posted April 25, 2009 ...which essentially means, no caching for me 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. Link to comment
geode hunter Posted April 25, 2009 Share Posted April 25, 2009 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? 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
+Semper Questio Posted April 25, 2009 Author Share Posted April 25, 2009 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 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
+beejay&esskay Posted April 25, 2009 Share Posted April 25, 2009 (edited) 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 April 25, 2009 by beejay&esskay Link to comment
+beejay&esskay Posted April 25, 2009 Share Posted April 25, 2009 (edited) (double post due to reported forum error) Edited April 25, 2009 by beejay&esskay Link to comment
+Tequila Posted April 25, 2009 Share Posted April 25, 2009 ...which essentially means, no caching for me 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. How about showing a little respect to a fellow cacher?? Link to comment
geode hunter Posted April 25, 2009 Share Posted April 25, 2009 (edited) 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 Edited April 25, 2009 by geode hunter Link to comment
geode hunter Posted April 25, 2009 Share Posted April 25, 2009 (edited) 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. Edited April 25, 2009 by geode hunter Link to comment
+slegal Posted April 25, 2009 Share Posted April 25, 2009 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
+MillsideMan Posted April 25, 2009 Share Posted April 25, 2009 (edited) 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 April 25, 2009 by MillsideMan Link to comment
+michigansnorkelers Posted April 25, 2009 Share Posted April 25, 2009 (edited) 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 April 25, 2009 by michigansnorkelers Link to comment
+beejay&esskay Posted April 25, 2009 Share Posted April 25, 2009 (edited) 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 Well, it seems YOU are the one to spot a significant difference. Glad I could help by supplying an old file. Edited April 25, 2009 by beejay&esskay Link to comment
+Wadcutter Posted April 25, 2009 Share Posted April 25, 2009 Just ran a PQ and GSAK worked fine. Using version 7.5.2.25 Link to comment
+MillsideMan Posted April 25, 2009 Share Posted April 25, 2009 I tried switching the "xsi" and "xsd" as mentioned in this thread and it then worked in GSAK and Cachemate. Link to comment
+Raine Posted April 26, 2009 Share Posted April 26, 2009 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
geode hunter Posted April 26, 2009 Share Posted April 26, 2009 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. Link to comment
+Freddo Posted April 26, 2009 Share Posted April 26, 2009 GPX edit fix does not work on GSAK 6. Still get the same error. Any other fixes for GSAK 6? Link to comment
+Semper Questio Posted April 26, 2009 Author Share Posted April 26, 2009 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
+Prime Suspect Posted April 26, 2009 Share Posted April 26, 2009 (edited) 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 April 26, 2009 by Prime Suspect Link to comment
+wind.chill Posted April 26, 2009 Share Posted April 26, 2009 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 I'm off caching Heiko Link to comment
+Scenic Routers Posted April 26, 2009 Share Posted April 26, 2009 (edited) thanx Edited April 26, 2009 by Scenic routers Link to comment
+Scenic Routers Posted April 26, 2009 Share Posted April 26, 2009 Just did a pq and all is good ! thanx to all who fixed the problem ! well done, my faith is now restored. Link to comment
+Team GPSaxophone Posted April 26, 2009 Share Posted April 26, 2009 Thanks for the fix. 6.6.5 build 19 is working again! Link to comment
+Maeglin Posted April 26, 2009 Share Posted April 26, 2009 (edited) 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 April 26, 2009 by Maeglin Link to comment
n0wae Posted April 26, 2009 Share Posted April 26, 2009 Thanks for the good and fast work! GSAK 6.6.5 build 20 is working again! Link to comment
geode hunter Posted April 26, 2009 Share Posted April 26, 2009 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
+benh57 Posted April 26, 2009 Share Posted April 26, 2009 (edited) 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 April 26, 2009 by benh57 Link to comment
+gof1 Posted April 26, 2009 Share Posted April 26, 2009 $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. Link to comment
geode hunter Posted April 26, 2009 Share Posted April 26, 2009 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. Link to comment
Recommended Posts