GPX export is broken

[Bananeweizen]

Hi folks,

your GPX export is broken: https://github.com/cgeo/cgeo/issues/5301

Ciao, Michael

[CraigRat]

Nothing has changed our end since 2011.

Replied in the thread linked

[caughtatwork]

The file is valid and parses correctly according to any number of XML validators. It also parses correctly within the Garmin GPS units.

It would seem that cgeo is not parsing according to the defined schema but the Groundspeak schema which will cause errors.

If the cgeo team can parse the data according to the XSD indicated in the file, the same way that say, GSAK does, then they will find the file is perfectly valid.

[MavEtJu]

iCaching also choked on it, author said he was going to fix it.

Edwin

[caughtatwork]

It's a challenge that people code up for the GC expectation and make assumptions.

This is the same issue with the enumerated cache types. Parsers which do not handle exceptions will never be able to handle new cache types as they expect only the values enumerated and fail if there is an unexpected value. They should refer to the new XSD that accompanies the new file with the new values, but that's hard when your device is not internet connected and you can't get to the XSD.

Either way it's nice that both the iCaching guys and the cgeo guys are willing to look into the situation and hopefully they'll be able to use the valid GPX files generated.

[Bananeweizen]

Your files are surely valid. That's not the issue. But there is no use in having yet another schema, listing the _exact_ same types, values and attributes, just to call them "myThing" instead of "thing". And while you are free to do so, it just doesn't make sense if you want others to understand that "myThings" are actually "things". You don't really expect geocaching parsers to understand and interpret _arbitrary_ schemas that they fetch on demand from the Internet, right?

Why don't you simply change the 3 places where you point to your schema to instead point to the identical schema of groundspeak? That's all we are asking for, as that fixes the issue for everyone consuming your GPX files.

There are a lot of geocaching sites out there which have their own schemas, but I've never experienced someone to _duplicate_ the groundspeak schema. All other schemas I'm aware of are extensions of either the groundspeak schema or the topographix schema that store _additional_ information. cgeo actually interprets 5 different schemas when parsing GPX files, but just because there really is additional information in them...

PS: Since you quoted several other tools of being able to parse your GPX files: Most (if not all of them) don't validate at all, and recognize the cache data just by text pattern matching. Which is why they would also completely ignore your schema changes, if you actually applied some modifications to the schema.

[CraigRat]

I tried using the groundspeak xsd in a trial this morning and c:geo still barfs and doesn't add long description and whatnot. Only cache name and co-ords. There's something else amiss. Dealing with a sick child right now so I can't delve much deeper.

As an aside, we will probably will run with the groundspeak xsd reference on our 'compatible' format as it really doesn't matter that much.

[caughtatwork]

Your files are surely valid. That's not the issue. But there is no use in having yet another schema, listing the _exact_ same types, values and attributes, just to call them "myThing" instead of "thing". And while you are free to do so, it just doesn't make sense if you want others to understand that "myThings" are actually "things". You don't really expect geocaching parsers to understand and interpret _arbitrary_ schemas that they fetch on demand from the Internet, right?

Why don't you simply change the 3 places where you point to your schema to instead point to the identical schema of groundspeak? That's all we are asking for, as that fixes the issue for everyone consuming your GPX files.

There are a lot of geocaching sites out there which have their own schemas, but I've never experienced someone to _duplicate_ the groundspeak schema. All other schemas I'm aware of are extensions of either the groundspeak schema or the topographix schema that store _additional_ information. cgeo actually interprets 5 different schemas when parsing GPX files, but just because there really is additional information in them...

PS: Since you quoted several other tools of being able to parse your GPX files: Most (if not all of them) don't validate at all, and recognize the cache data just by text pattern matching. Which is why they would also completely ignore your schema changes, if you actually applied some modifications to the schema.

It would be nice if you were able to actually use the schema. It hasn't changed in years so will be stable. I don't want to have to change the file for cgeo if it works everywhere else. There may be a lot of unintended consequences if we made that change and then other apps stopped working. I'm sure you can appreciate that a small change to suit one system may impact a lot of others.

If you are able to use the schema as defined, as a basis, you would be doing the geocaching community a huge service. If you are very serious about not handling the appropriate schema, then please let us know and maybe we can have a cgeo specific version of the GPX file which refers to the Groundspeak XSD. Then people can use that version if they want to use your app.

[MavEtJu]

PS: Since you quoted several other tools of being able to parse your GPX files: Most (if not all of them) don't validate at all, and recognize the cache data just by text pattern matching. Which is why they would also completely ignore your schema changes, if you actually applied some modifications to the schema.

As the author of a geocaching app: I don't validate, I just throw it through libxml2 and deal with the (absence of) data when the whole object has been read.

However, the schema as provided by Groundspeak is a good example of how not design a schema and nearly everybody who used it is unable to deal with any changes and as such we will be stuck with a broken schema designed in the early 2000s forever.

(Oh and Groundspeak provides the data in XML GPX files and in JSON format if you use the LiveAPI so you have to make two different parsers to deal with their data. Hint to them: X stands for extensible which means you can improve on it, not that you are stuck with it forever or that you should use a different data format. FML)

Edwin

[Bananeweizen]

For a really nice technical explanation of XML schemasplease read the lengthy comment of Samuel Tardieu over here: https://github.com/cgeo/cgeo/issues/5301

@CraigRat: I replaced 2 references to the schema in the namespace declaration and 1 in the cache element declaration. cgeo reads all the available values in the file after that, tested.

@caughtatwork: I have compared your schema and the groundspeak schema. They are completely identical, except for comments and the namespace declaration. So if you do that change, you will break exactly those tools which are namespace aware and understand _only_ your schema but NOT the groundspeak schema. I expect that to be zero tools. At the same time, your GPX files will suddenly be understood by all the many tools, that are namespace aware and use the groundspeak schema. For me that looks like a clear win for you, as all the other text matching tools will continue to work as before, they aren't affected by namespace changes at all.

And since your schema is semantically identical, I really don't want to add it to cgeo.

@Edwin: I didn't say I like the groundspeak schema. I'm with you that it's horrible. But it's a common ground, and I would like to avoid having 5 more "common" grounds.

Good night.

[caughtatwork]

I tried using the groundspeak xsd in a trial this morning and c:geo still barfs and doesn't add long description and whatnot. Only cache name and co-ords. There's something else amiss. Dealing with a sick child right now so I can't delve much deeper.

As an aside, we will probably will run with the groundspeak xsd reference on our 'compatible' format as it really doesn't matter that much.

There is a trick to what Bananeweizen is suggesting. In the GPX Compatible version, change:

http://www.geocaching.com.au/geocache/1/0/1/

to

http://www.groundspeak.com/cache/1/0/1/

i.e. It's not geocaching.com is groundspeak.com and the geocache/1/0/1 becomes cache/1/0/1

I've mocked up some files and it seems to work. As this is indeed only a GC compatible file, we can probably get this done without screwing other things. I'll have a go tonight and test against GSAK, my Garmin and cgeo. GA Cache is API driven so no impact at all there.

[caughtatwork]

Do you use c:geo for your geocaching and are frustrated that you can't use your Geocaching Australia GPX file and import it?

Well, as of right now you can. Thanks to some generous support from the c:geo folks we have been able to tweak our GPX file so it will now work with c:geo.

To use, simply grab a GPX file from Geocaching Australia, say this one for all known GeGnome ][ geocaches.
http://geocaching.com.au/my/query/gpx/7536

Drop it on your device and import it as you would any other GPX file.

Bingo (no that was 2 years ago) ... GEGNOME! You have a device full of GeGnomes you can chase around with c:geo bringing all of your geocaching enjoyment together in one app.

Logging is not supported but you can at the very least use c:geo to find your GeGnomes.

We hope this change makes you happy.

[Bananeweizen]

Thanks. Since you just mentioned a GA specific API, can you point to some description of it? Maybe we can use some of it from cgeo to provide more than just GPX based functionality.

Feel free to move this post to another forum, if that is more appropriate (I'm to much of a newbie here).

[ziggiau]

To add to the GPX discussion, I emailed Filip at GeoKrety (I'm testing Geokrets out to see if they'll be a valid alternative to Swaggies and Trackables) as to why they hadn't updated their GA data in over 12 months and his response was:

I've found why geocaching.com.au hasnt been updated for so logn. The source gpx downloaded from the service contain wrong waypoint:

<wpt lat="-44.702600" lon="1522.070150"> <time>2012-12-01T00:00:00.000Z</time>
<name>GA3606</name>
<desc>And his name was BINGO</desc>
<src>Geocaching Australia</src>

and a parser failed to read this file. I've applied a workaround, but if you could please contact the cache owner to correct the coordinates (lon).

Does any of this pertain to the current formatting discussion?

[caughtatwork]

To add to the GPX discussion, I emailed Filip at GeoKrety (I'm testing Geokrets out to see if they'll be a valid alternative to Swaggies and Trackables) as to why they hadn't updated their GA data in over 12 months and his response was:

I've found why geocaching.com.au hasnt been updated for so logn. The source gpx downloaded from the service contain wrong waypoint:

<wpt lat="-44.702600" lon="1522.070150"> <time>2012-12-01T00:00:00.000Z</time>
<name>GA3606</name>
<desc>And his name was BINGO</desc>
<src>Geocaching Australia</src>

and a parser failed to read this file. I've applied a workaround, but if you could please contact the cache owner to correct the coordinates (lon).

Does any of this pertain to the current formatting discussion?

No, but I've archived that cache and the co-ords are garbage anyway.