You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've added a a change to the code in my own private repo that includes the distance_from_start returned from get_points_data() into the named tuple returned by the get_nearest_location and get_nearest_locations routines.
I'm not going to bombard you with a pull request before asking if this change would even be welcome?
My hesitancy in submitting is that it does add an additional element to the NearestLocationsData class, so if someone is accessing it as a tuple, for example, in a for loop, it could cause issues and break the API. However, I doubt many people do, since it is a named tuple, but it is possible.
Why is this useful?
It's carries over expensive to calculate data from get_points_data(), and it's really wonderful to have if you're matching waypoints to tracks for printing out data about a route. https://github.com/pleasantone/gpxtr uses it (had to extend the GPXTrack class since monkey patching wasn't working for me) to produce nice little tables about a given multi-day route:
Some of the changes I needed to make were supporting the idea that "a track might be part of a multi-stop(day) ride" and I needed to have a track-specific version of get_nearest_locations(), and the idea that if a path crosses itself (see day 2), the waypoints should show up multiple times, hence not being able to use get_nearest_location().
The milage was pulled off of my extended version of NearestLocationData returned by get_nearest_locations().
The text was updated successfully, but these errors were encountered:
I've added a a change to the code in my own private repo that includes the
distance_from_start
returned fromget_points_data()
into the named tuple returned by theget_nearest_location
andget_nearest_locations
routines.I'm not going to bombard you with a pull request before asking if this change would even be welcome?
My hesitancy in submitting is that it does add an additional element to the
NearestLocationsData
class, so if someone is accessing it as a tuple, for example, in a for loop, it could cause issues and break the API. However, I doubt many people do, since it is a named tuple, but it is possible.Why is this useful?
It's carries over expensive to calculate data from
get_points_data()
, and it's really wonderful to have if you're matching waypoints to tracks for printing out data about a route. https://github.com/pleasantone/gpxtr uses it (had to extend the GPXTrack class since monkey patching wasn't working for me) to produce nice little tables about a given multi-day route:day1 210 miles: Sunrise: 07:20, Starts: 08:00, Ends: 14:59, Sunset: 16:56
day2 208 miles: Sunrise: 07:08, Starts: 08:00, Ends: 14:54, Sunset: 16:49
day3 167 miles: Sunrise: 07:12, Starts: 08:00, Ends: 13:35, Sunset: 16:48
Some of the changes I needed to make were supporting the idea that "a track might be part of a multi-stop(day) ride" and I needed to have a track-specific version of
get_nearest_locations()
, and the idea that if a path crosses itself (see day 2), the waypoints should show up multiple times, hence not being able to useget_nearest_location()
.The milage was pulled off of my extended version of NearestLocationData returned by
get_nearest_locations()
.The text was updated successfully, but these errors were encountered: