• [x] I agree to follow the project's code of conduct.
• [x] I added an entry to CHANGELOG.md if knowledge of this change could be valuable to users.

Implement changes proposed in https://github.com/georust/gpx/issues/77

I don't expect this to land directly as it adds a breaking change

GPX 1.1 Spec includes an optional Number on Track elements, which support is added for here. Some Gpx files exported from google maps appear to include this so included test + test gpx file from that are used to verify change.

N.b. Number, as a u8, was already present and commented out on the Track struct - in case there was some history there being dragged up (It was already commented out during a refactor 4 years ago and that's as far back as i looked ...)

• [X] I agree to follow the project's code of conduct.
• [x] I added an entry to CHANGELOG.md if knowledge of this change could be valuable to users.

Similar to https://github.com/georust/gpx/issues/70, I have a GPX file that has self-closing elevation tags, which of course, contain no value. This appears to be valid per the GPX spec at https://www.topografix.com/GPX/1/1/#type_ptType.

The GPX file was generated by a Wahoo bike computer.

This change edits the parsing logic to use a default f64 value of 0.00 for these cases. I didn't see a precedence for handling similar optional values in this lib, so let me know if I should handle this differently in accordance with the project's goals.

• [x] I agree to follow the project's code of conduct.
• [x] I added an entry to CHANGELOG.md if knowledge of this change could be valuable to users.

• [x] I agree to follow the project's code of conduct.
• [ ] I added an entry to CHANGELOG.md if knowledge of this change could be valuable to users.

not sure if this is intentionally private, perhaps there is some other way to access time data from waypoints directly as chrono types?

closes #75 if valid

This commit adds the GpxCopyright type and parse/copyright.rs which consumes the tag of the metadata element.

I've also included a Strava route test case as well as some unit tests in the source file.

Fixes issue #45

$ cargo test

test parser::copyright::tests::consume_barebones ... ok
test parser::copyright::tests::consume_simple_copyright ... ok

test gpx_reader_read_test_strava_route ... ok

• [x] I agree to follow the project's code of conduct.
• [x] I added an entry to CHANGELOG.md if knowledge of this change could be valuable to users.

Fixes #54

I noted that the exported GPX files are not accepted by Garmin software (for example Basecamp), and found out this is due to a missing namespace declaration. This PR adds the necessary xmlns tag to the gpx element.

• [X] I agree to follow the project's code of conduct.
• [X] I added an entry to CHANGELOG.md if knowledge of this change could be valuable to users.

The extensions tag is also allowed in the route tag (see https://www.topografix.com/GPX/1/1/#type_rteType).

• [x] I agree to follow the project's code of conduct.
• [ ] I added an entry to CHANGELOG.md if knowledge of this change could be valuable to users.

When opening a file with this format:

<gpx>
    <!--- metadata --->
    <trk>
        <name></name>
        <!--- rest of track data --->
    </trk>
</gpx>

gpx panics with the message: no content inside string.

Is there a reason string::consume is called with allow_empty=false here? Is this construct just invalid and the App I used has generated an invalid gpx file? If that is the case, since all other gpx applications I tested don't have a problem with this, would it make sense to accept this anyways?

Reworked every parser file, with the exception of extensions.rs.

Changes and cleanup were mostly:

• Every parser is now responsible for consuming his own starting and closing tags (previously some parsers would be okay not having any starting tag, and would be used like this). To be able to achieve this any parser that calls further consume functions must use peek() to leave starting tags in the reader for the subparser to handle.
• Many parsers were accepting any amount of their starting tag, and also consuming any closing tag as valid, ignoring the name. Now exactly one opening tag and matching closing tag is required.
• Parsers that were already using peek() were doing so via a level of indirection through some form of "ParseEvent" enum, I think I have found a cleaner solution using .clone() on the event which allows us to remove this indirection and parse XmlEvents more directly even with peek().
• Added some more custom errors, and generally use custom errors more

• [x] I agree to follow the project's code of conduct.
• [x] I added an entry to CHANGELOG.md if knowledge of this change could be valuable to users.

This PR resolves #59, by implementing optional support for (de-)serializing the GPX structs via serde.

I named the feature flag serde-serialize, same as in the wasm-bindgen crate. Using serde for the feature flag name is not yet possible, since it would require the currently unstable cargo namespaced features implementation. See also the related cargo tracking issue.

It was asked in #59, whether it would be possible to use GeoJSON, but for my usecase, it would be overkill to deal with additional data structure conversions. I also checked the Rust API guidelines, which mention that it would be good, if structs implemented serde::{Serialize, Deserialize}.

If the changes are okay and can/should be merged, I'll update the branch with a changelog entry.

• [ x] I agree to follow the project's code of conduct.
• [ ] I added an entry to CHANGELOG.md if knowledge of this change could be valuable to users.

Hey folks, I had to burn some spare time and ran clippy -- -W clippy::pedantic against the project. I applied most of the suggestions and now running clippy -- -W clippy::pedantic -A clippy::used_underscore_binding passes.

The clippy::used_underscore_binding rule still fails because of Waypoint::_type. Renaming it would break the API, hence I did not do that. I suggest to rename the field in some future release to something that aligns with Rust's naming convention ;)

Additionally, I refactored the consume functions in the parser modules as some of the were super long. If applicable, I introduced a private try_from_attribute function that is used for component initialization.

Since this PR is mostly about cosmetics and doesn't change any semantics (hopefully), I did not put it in the changelog :P

Hello,

Thanks a lot for the crate! This makes handling of gpx files really easy.

I have one question though: How can I, as a consumer, properly work with the time of a waypoint? Maybe I'm missing it, but although with the newest commit, the Time struct is exported, I can only format it directly to a string. I would like to have it as a chrono DateTime to further do some calculations on it.

Currently it seems that I have to format it as a String (involving an allocation), just to have it again parsed again by chrono.

What about a chrono feature of the crate, which could transform the Time as a chrono DateTime?

Hello everybody,

first of all thanks for providing this great package!

I stumbled over a GPX file that contains the following time stamp <time>2021-10-10T09:55:20.952</time> which causes an Rfc3339Error during parsing. The file, however, validates against the GPX 1.1 schema

$ xmllint --schema http://www.topografix.com/GPX/1/1/gpx.xsd /tmp/test.gpx --noout
/tmp/test.gpx validates

Both, GPX 1.0 and GPX 1.1 define time stamps as xsd:dateTime which is neither RFC 3339 nor ISO 8601 by definition, although the latter strongly inspired it. See this great visualization for comparison of the standards 😎.

I suggest to assume ISO 8601 by default. Since the world isn't perfect, I also suggest to implement an fall back on RFC 3339 in error cases or, even better, allow for user defined error handlers. In my case, for instance, I don't really care about the time stamp and would pass a callback that simply ignores the "malformed" input.

If you're interested, I can start working on a PR 🙃

I have a GPX file, which has a malformed <time> node:

<time>2022-04-13T11:49:33.749</time>

The rest of the file is fine, but gpx::read fails because of that. Could there be an option to "continue on unimportant errors" for parsing? Thanks.

The GPX schema allows for some tags to include arbitrary XML data in the form of the extensions tag:

<...>
Allow any elements from a namespace other than this schema's namespace (lax validation). [0..*]
</...>

Currently rust-gpx has no functionality that allows this data to be parsed or stored in the resulting Gpx instance. This issue is a tracking issue for this feature.