Quantcast

Problems processing c:geo exports

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Problems processing c:geo exports

Steffen Grunewald-2
Hi,

I ran into problems when trying to pass GPX files through GPSbabel, and
importing them into c:geo.
Even a GPX created by c:geo's export, once passed through gpsbabel -igpx
-ogpx, doesn't import anymore ("bad file format: could not parse XML").

Creating an "empty" file using the <gpx> header used by c:geo, and
passing it through gpsbabel again, I think I found the culprit: Some
xmlns:... strings are just stripped from the line.

See the attachments - pp* is the "pretty printed" GPX by c:geo stripped
down to minimum content, and qq* is the gpsbabel output. I
triple-checked that the added lines (time and bounds) are harmless.

This is gpsbabel 1.5.0-3 as delivered with Debian Jessie.

Any advice?

Thanks, S

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

_______________________________________________
Gpsbabel-code mailing list  http://www.gpsbabel.org
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code

pp-empty.gpx (782 bytes) Download Attachment
qq-empty.gpx (810 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problems processing c:geo exports

Steffen Grunewald-2


On 07/31/2015 03:10 PM, Steffen Grunewald wrote:

> Hi,
>
> I ran into problems when trying to pass GPX files through GPSbabel,
> and importing them into c:geo.
> Even a GPX created by c:geo's export, once passed through gpsbabel
> -igpx -ogpx, doesn't import anymore ("bad file format: could not parse
> XML").
>
> Creating an "empty" file using the <gpx> header used by c:geo, and
> passing it through gpsbabel again, I think I found the culprit: Some
> xmlns:... strings are just stripped from the line.
>
> See the attachments - pp* is the "pretty printed" GPX by c:geo
> stripped down to minimum content, and qq* is the gpsbabel output. I
> triple-checked that the added lines (time and bounds) are harmless.
>
> This is gpsbabel 1.5.0-3 as delivered with Debian Jessie.
>
> Any advice?
>
> Thanks, S
I downloaded 1.5.2, and built it myself - now it even gets worse. While
the xmlns:* parts are preserved now, everything "xsi" has gone. SAXCount
is not happy at all.
Attached is the new result...

I used to use gpsbabel to combine multiple input gpx files into one gpx
output, but with such things happening, I can no longer use it for
geocaching purposes.

- S

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

_______________________________________________
Gpsbabel-code mailing list  http://www.gpsbabel.org
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code

rr-empty.gpx (581 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problems processing c:geo exports

Robert Lipe-4
I'm a geocacher and I merge GPX files (PQs) together All The Time.  Your case is unique that you're mixing and matching a bunch of programs that seem to be adding their own stuff to the PQs.

In the general case, merging XML with different extensions (your is mixing groundspeak extensions with gsak extensions and c:geo extensions) doesn't work well.  It's difficult to tell how they'll interact.  We try to pass the tags that aren't known to us through transparently (i.e. we'd give you the union of the gsak: and cgeo: children in wpt) but we can't tell when they're incompatible or how they'll interact.  If you ask us to merge GSAK 1.3 extensions with GSAK 1.5 extensions, we can't know if they're compatible; we'll just slavishly emit the tag structure.  Mixing GPX 1.1 and GPX 1.0 has this problem, too.

At a glance, we could probably do this case better.  In gpx.cc look at the code that handles gpx_namespace_attribute  Just like we special case the xsi, we could probably do the same thing with xmlns.

It's a pretty mechanical thing - just about a copy/paste/tweak (yes, I know that's dangerous)  of every place using gpx_namespace_attribute.   Can you take a pass at it?

This code has roots in GPSBabel's C days when we didn't have QXmlStreamAttributes to handle a lot of the ugliness for us.

Honestly, simply not writing ANY of that stuff should actually work in sane apps.  (SAXCount is one of the few things that actually cares and it's job is to be hyper picky.)  It's not like there's any actual useful information conveyed in the xsi attribute.  You can see, for example, that we can read our own output:


$ ./gpsbabel -i gpx -f ~/Downloads/pp-empty.gpx  -o gpx -F - | ./gpsbabel -i gpx -f - -o gpx -F -


On Fri, Jul 31, 2015 at 1:33 PM, Steffen Grunewald <[hidden email]> wrote:


On 07/31/2015 03:10 PM, Steffen Grunewald wrote:
Hi,

I ran into problems when trying to pass GPX files through GPSbabel, and importing them into c:geo.
Even a GPX created by c:geo's export, once passed through gpsbabel -igpx -ogpx, doesn't import anymore ("bad file format: could not parse XML").

Creating an "empty" file using the <gpx> header used by c:geo, and passing it through gpsbabel again, I think I found the culprit: Some xmlns:... strings are just stripped from the line.

See the attachments - pp* is the "pretty printed" GPX by c:geo stripped down to minimum content, and qq* is the gpsbabel output. I triple-checked that the added lines (time and bounds) are harmless.

This is gpsbabel 1.5.0-3 as delivered with Debian Jessie.

Any advice?

Thanks, S

I downloaded 1.5.2, and built it myself - now it even gets worse. While the xmlns:* parts are preserved now, everything "xsi" has gone. SAXCount is not happy at all.
Attached is the new result...

I used to use gpsbabel to combine multiple input gpx files into one gpx output, but with such things happening, I can no longer use it for geocaching purposes.

- S

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

_______________________________________________
Gpsbabel-code mailing list  http://www.gpsbabel.org
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code



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

_______________________________________________
Gpsbabel-code mailing list  http://www.gpsbabel.org
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code
Loading...