-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implementing serde (De)Serialize for GPX structs? #59
Comments
Hi @mkroehnert, yes of course. As you say, a feature flag would be the preferred way to implement this. Just out of curiosity, is the JSON actually GeoJSON, and if not, is there a reason for that? I ask because if it is GeoJSON, then perhaps an approach that leverages geozero might be better. |
Thanks for the response @urschrei . |
If someone is interested, I am using the gpx crate in the following prototype, where I am testing different things related to WASM and GPS in the browser. |
Hello all,
first of all I want to say thank you for your work on the GPX crate.
I am using this crate for a hobby project which allows recording GPS tracks via the webbrowser GPS API and exporting them as GPX. See https://gitlab.com/mkroehnert/trailcorder.
In addition to the existing XML export option, I am currently testing a feature for persisting the recorded data in local storage as JSON objects, which requires deriving serde (De)Serialize for the structs in this crate.
Since it is not easily possible to add serde #derive to structs that are not part of my own crate, I added the required changes in the following commit of my fork: https://github.com/mkroehnert/gpx/commit/26a0b8b1bd9c6348a86c9a30ccff2b963245a05f
Before putting more work into hiding the serde dependency behind a feature flag,
I wanted to ask if this is a contribution you would consider adding/merging,
The text was updated successfully, but these errors were encountered: