Pq Xml File Rejected By Mapsource

[+RamblinGirl]

246670.gpx is the file, I don't know if you keep copies. It's also my "2stars" pocket query in my account. Normally, all is well. But when I try to load this file in Mapsource (v. 6.5), it behaves badly. First, I get a dialog asking which kind of waypoint symbols my GPS uses, which I don't normally see. Then, regardless of which of the three radio buttons I select, I get an alert which reads:

 

-------- ------ -------

"<whatever the filepath is on my machine>\....\246670" could not be imported."

A problem was found near line 40

No spaces were found after the record ID.

-------- ----- ----- ---

 

Yes, I would be happy to go through the steps again but I do not want to hit today's limit on queries.

 

I had a look at the XML code and couldn't see anything obvious to edit.

Please let me know if there's something I can do to make this work.

Thx.

[+Yamar]

Normally, all is well. But when I try to load this file in Mapsource (v. 6.5), it behaves badly.

Did you convert it from the .gpx file to something mapsource understands first? mapsource doesn't read the .gpx files directly. You need something to convert it like gpsbabel, or gsak or ...

[+Kai Team]

Did you convert it from the .gpx file to something mapsource understands first? mapsource doesn't read the .gpx files directly. You need something to convert it like gpsbabel, or gsak or ...

Actually, the later versions of Mapsource (6.0 and above, I believe) can read GPX files directly. As an aside, you can update the Mapsource program (but not the maps themselves) for free at the Garmin website.

[+Kai Team]

A problem was found near line 40

No spaces were found after the record ID.

  -------- ----- ----- ---

I had a look at the XML code and couldn't see anything obvious to edit.

Please let me know if there's something I can do to make this work.

Thx.

There may be a waypoint in the PQ using special characters in the name, or something else Mapsource doesn't like. Garmin is picky, and inconsistent, about the characters it will accept. In my experience, most special characters (anything other than letters, numbers or a space) are risky.

 

Import the GPX file into GSAK and then export it to an MPS file - GPSBabel (under the hood in GSAK) will strip out any offending characters. You should then be able to load the MPS file GSAK generated into MapSource.

[robertlipe]

Mapsource doesn't have particularly high standards. It just insists that the file actually be well formed. Unfortunately, there are cases where the PQ's generated by this site are _not_ well formed and rather than gunking up the readers to "guess" what was intended, Mapsource does what XML readers are supposed to do: reject the malformed input.

 

If you have access to an XML validator such as SAX2Count or any of the various online checkers, it's easy to prove on which side lies the 'blame'. If Mapsource is rejecting valid XML, Mapsource is naughty. If the site is hocking up bad XML, the site should be fixed.

[+sbell111]

Or just go the easy way and convert the file using GSAK if mapsource doesn't like it.

[robertlipe]

Please don't be an enabler. Identify the root of the problem and help get it fixed.

[+RamblinGirl]

I just think it's a bug somewhere. Maybe it's Groundspeak's, maybe it's Garmin's. I ran the query again, from a different waypoint, and it worked. So... go figure.

I just updated software & drivers yesterday, so everything's up to date.

 

So anyway, something is definitely wrong here. I will not load it into something else and convert it. It should just work. Thank you, robertlipe for your support. The main reason I'm even mentioning it is because there is a problem that needs to be looked at, and hopefully fixed.

[+Yamar]

Actually, the later versions of Mapsource (6.0 and above, I believe) can read GPX files directly. As an aside, you can update the Mapsource program (but not the maps themselves) for free at the Garmin website.

Cool, thanks. I actually usee a newer copy but didn't know they added that functionality (those changelogs are annoyingly boring to read the few interesting items out of the list of more mundane fixes... I wish they'd separate it into features/fixes).

[+RamblinGirl]

OK, I've been doing some research. If you open the file in Internet Explorer, all seems fine and there are no visible problems. You can open it in Notepad, with no complaints.

 

If you attempt to open it in Word or Excel, they both complain about strange Unicode characters in the file.

 

Hmmm...

Edited June 16, 2005 by RamblinGirl

[+Lil Devil]

That's normal. Notepad doesn't understand Unicode.

 

The first line of the GPX file correctly specifies that the file is Unicode, so that intelligent programs know how to deal with them.

 

Word, Excel, Notepad, and other Microsoft programs, can hardly be considered intelligent

Edited June 16, 2005 by Lil Devil

[robertlipe]

Offline, RamblinGirl sent me the file for analysis. It's indeed broken.

 

Analyzing the offending PQ with the aforementioned tools, the problem pops right out. Mapsource is correct to reject this file.

 

$ SAX2Count 246*gpx

 

Fatal Error at file /home/robertl/Desktop/246670.gpx, line 34381, char 349

Message: Invalid character reference

 

The offending line is a log entry from GCNZE3 :

 

<Groundspeak:text encoded="False">Flyingdogs and I always enjoy returning to this trail in spite of the gun club noise. As described a very easy find, thanks! The Mountain Bike Monkey TB dropped off the Birthday Chainring TB and took the Claw TB, boy has it been a while since we have found a box on a suitable mountain bike trail!</Groundspeak:text>^M

 

XML is about making and keeping promises. The promises that pocket queries make are revealed if we peek in the xsd at

http://www.Groundspeak.com/cache/1/0/cache.xsd

and we see that :text is defined as "xs:string". That is defined fully at

http://www.w3.org/TR/2001/REC-xmlschema-2-...502/#rf-pattern

but the most pertinent part is the definition that strings are composed of characters and characters are defined at

http://www.w3.org/TR/2000/WD-xml-2e-20000814#NT-Char

 

Legal characters in a string don't include '0', yet that's exactly what this one has on the end. So the PQ made a promise that this would contain only certain characters and BLAMMO, here's a character (a null) that's not on the 'in list'.

 

I don't know how it it got there. But a conforming GPX implementation must never produce such output. Most GPX readers will choke on this.

 

This problem got better about a year and half ago, but variations of this problem have haunted this site for a long time, I'm afraid. Unfortunately, the trend has been for the various reviewers (who really are trying to be helpful and dispense short-term pain killers) to go "fix" offending logs and cache pages which, destroys the test case for the likes of Elias to actually fix the problem.

 

To solve your immediate problem, RamblinGirl, just put this cache on your ignore list.

 

[ edit: feel free to refer to this post when you report this to Groundspeak ]

Edited June 16, 2005 by robertlipe

[+RamblinGirl]

Thanks, Robert! I really appreciate your looking at this and zeroing in on the problem.

 

Word, Excel, Notepad, and other Microsoft programs, can hardly be considered intelligent

Ahem... FYI Word & Excel *correctly* rejected the file because it was bad. Their doing so only validates my claim that there's a problem with the file, not Mapsource. Actually, Word has a very nice interface when it comes to viewing XML files. And I must say, my favorite project during my tenure at Microsoft was the very first version of Word for Windows (code-named Opus). That's going off-topic, though.

 

Mainly, I just want to thank Robert for his help here.

[+Lil Devil]

during my tenure at Microsoft

...you were brainwashed, so discussing this point will benefit no one.

[Elias]

This problem got better about a year and half ago, but variations of this problem have haunted this site for a long time, I'm afraid.

Robert -

 

Prior to this thread, I was unaware that these issues were still present. I'm pretty sure that my FixMicrosoftsBadXML() function excludes almost every illegal XML character. However, given this particular character, I can understand how I missed it. I'll update my code to fix this character too, but if you have evidence of other illegal characters, I'd appreciate hearing about them.

 

Elias

[robertlipe]

Prior to this thread, I was unaware that these issues were still present. I'm pretty sure that my FixMicrosoftsBadXML() function excludes almost every illegal XML character. However, given this particular character, I can understand how I missed it. I'll update my code to fix this character too, but if you have evidence of other illegal characters, I'd appreciate hearing about them.

 

Elias

Hi, Elias. Thanx for the follow-up.

 

I've been sending folks to 'contact@' when this is observed, since that's the address given in the PQs. Offhand, I think logs with naughty NULLs and tabs are the biggest remaining offender, though I think I've seen control-A's in a few logs. (No, I don't have any idea how people are doing this stuff.)

 

Given how your CPU cycles are seemingly overextended during XML generation, does it make more sense to catch and "fix" these during page edit and logging time? You may, unfortunately, have to make one scan over the whole DB to retroactively 'fix' anything that's in there now with the naughty characters, but that'd be a one-time cost instead of doing another pass over the data for every PQ generated, right?

 

If you want to drive a stake through the heart of this problem, generate a PQ of every log on every cache and run that through SAX2Count. :-)

 

Thanx.