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 am interested in enhancing the functionality of this library when adding time data to points. I would like to use elevation data to account for additional time taken when ascending/descending along a route and my intention would be to implement either the Naismith-Langmuir rule or Tobler's hiking function.
However I'm conscious that this functionality would apply solely to walking/hiking, not other activities like cycling or driving, and so might be a bit too opinionated for wider use. Would this still be an accepted addition to this library?
If the suggestion sounds acceptable, are there any considerations for how best to implement?
The immediate issues that came to my mind are:
There are the existing add_missing_times() and fill_time_data_with_regular_intervals() functions for adding time data. To maintain support for these, perhaps they could be given a new, optional argument of estimation_mode with a default of linear for the existing functionality and a value of naismith (or other) for this new functionality?
If both start and end times are available/supplied, this functionality would scale times proportionally based on gradient.
The text was updated successfully, but these errors were encountered:
I am interested in enhancing the functionality of this library when adding time data to points. I would like to use elevation data to account for additional time taken when ascending/descending along a route and my intention would be to implement either the Naismith-Langmuir rule or Tobler's hiking function.
However I'm conscious that this functionality would apply solely to walking/hiking, not other activities like cycling or driving, and so might be a bit too opinionated for wider use. Would this still be an accepted addition to this library?
If the suggestion sounds acceptable, are there any considerations for how best to implement?
The immediate issues that came to my mind are:
add_missing_times()
andfill_time_data_with_regular_intervals()
functions for adding time data. To maintain support for these, perhaps they could be given a new, optional argument ofestimation_mode
with a default oflinear
for the existing functionality and a value ofnaismith
(or other) for this new functionality?The text was updated successfully, but these errors were encountered: