Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Support for GPX1.1 #20
I read all GPX standard and i found the difference between version.
Regarding the GPX 1.0 and 1.1. I finally found some time to create a script to pretty-print the structures of 1.0 and 1.1.
The results are here:
The problem is that I copied the object model from the sample GPX files I had at the time. Now with 1.1 the object model is different, and that will break existing code.
Any suggestions between 1. and 2. ?
Can you do some sort of superset object model that could handle either format? Reading in a gpx1.0 format file would set a flag for 1.0, gpx1.1 would set it to 1.1. Output would be whatever was already set, or forced by the caller, or default to the more descriptive of the two (1.1, I'm guessing).
If you have to break the API to make improvements, I think it would be worth it. More abstraction and features for those that want to move forward. Anyone that doesn't want to change code can be happy with an older release that keeps on working as is.
I think I'll stick with the GPX1.0 object model for the library, but transparently parse/serialize to 1.0 or 1.1 depending on the specific track. There will probably be some minor API changes.
The 1.1. is more descriptive but I don't think it was worth the change (for example the metadata field in the gpx instead of all those field directly under ...).
Anyway, I'm now rewriting the parser/serializer parts in order to be easier to handle 1.1.
I've tried using gpx-1.1 but not sure how to extract the heart rate data from a file.
When I run
for track in gpx.tracks:
The result is...
Any thoughts? I've just started using python after a long break and I'm not a programmer so any help appreciated.
My Garmin GPX generates extensions like this:
Which are parsed correctly and result in the following usage:
I'm guessing there is a bug in the new parser and how it deals with an arbitrarily long chunk of custom xml. It might be assuming that it would only find a single line. You should file it as a bug, and/or submit a code patch pull request.
This is one of the reasons why I still haven't merged the gpx-1.1 branch into master. The "extensions" thing works only for extensions with (xml tree) depth 1.
...will be parsed into:
But it won't work for:
My (unfinished) idea was to parse this as:
But then there is a problem of how to store attributes for nested xml tags, like:
A possible solution for nested tags is:
...and for attrubtes use something like:
But even the dict for extensions is probably not the best solution, because tags don't need to be unique. For example, what to do when the extension is:
The seconds "aaa" tag will overwrite the first one in the dict.
The "extension" thing should be refactored in order to work as a dict for simple extensions and have some API for more complicated extension constructs.
When you are talking about 'aaa/ccc' for nested tags, that would just be for the object model, right? When you output a new gpx file with gpxpy (after doing whatever processing you do), it will still convert it into the original form (assuming it is untouched), right? I think that is very crucial and just want to make sure that would be the case.
Also, wouldn't putting a slash in the name cause problems since it is a valid, non-reserved character and you might already have an xml element with the name "aaa/ccc"?
@alkino Yes, you found the problem :) what with
But then what to do with
Also note that in the XML the order of subelements is preserved, but translating it into a
@JaniszM If you all guys agree I can merge it in master and release a new version immediately but with one important exception -- the
Ignoring exceptions, I think the gpx-1.1 branch should be ready for merging.
I don't need it right now, so If you can work on exception/extension it's ok for me to wait a bit :) It's not critical point right now to have this
Edit: I haven't time before to read all comment but I just did it.