Closed mfeingol closed 3 years ago
I'll give this some thought.
I'm open to making breaking changes, to better follow the GPX spec. We'd need to publish a new major version of the library if we did that though.
I've submitted a PR for the simplest solution to this. Please let me know if you have any feedback.
@sibartlett: just wondering if you've had a chance to think about the right path forward for this.
The PR I submitted is a breaking change, and it might make sense to include any other breaking changes in one fell version upgrade swoop.
However, it's not clear that anyone actually needs anything more than what's in the PR. E.g. I have yet to come across a GPX file in the wild whose trackpoints have anything but coordinates and elevation data. I have encountered routepoints with metadata.
Thanks, as always!
Sorry for the delay, things have been busy. I will look soon, no later than the 24th - which is a 10% day at work for me.
Hi, @sibartlett. Looks like the PR went through. Thanks again! 🍾
Do you plan to publish a new NuGet package in the near term?
Published as 1.0.0
Sorry for the delay.
Thank you, sir.
I've noticed that GPX tracks whose route points have names or descriptions don't see that data materialize at the
GpsData
level. The reason isRoute
just has a list ofCoordinate
instances and the serializer doesn't transfer name/desc/comment fields to the public surface area when deserializing.Technically,
Route
points,TrackSegment
points andGpsData
waypoints should probably all be the same type, as they are in the GPX spec, where everything is awptType
.However, that will change a lot of public signatures, and be a fairly breaking change in the library. A more conservative alternative would be to attach new properties to
Coordinate
,Fix
, andWaypoint
respectively.@sibartlett, thoughts? I'm happy to PR a fix, but I'm not sure which direction to take here.
Thanks.