Configure time required to change
Acknowledgments
Please check the following boxes with an x if they apply:
- [x] The feature I want to propose would be useful for the majority of users, not only for me personally.
- [x] I am aware that Transportr is mostly developed by one person in their unpaid spare time.
- [ ] I can help myself to get this feature implemented or know someone who wants to do it.
- [ ] If I want to add support for a new region or country, I checked that this is already available in public-transport-enabler and know the process described on the Transportr homepage.
Is your feature request related to a problem? Please describe.
Sometimes I miss a bus or a tram I need to change to, because I must wait for traffic lights for pedestrians to turn green.
Describe the solution you'd like
Configure a constant time and add it to walking time between two different stops (don't add it when chaning on a single stop, see Additional Context below). The easiest possible (and good enough in most cases) option is a single value for every type of change. However more detailed configuration is also possibe:
- separate value describing time required to get on a specific type of transport — it takes significantly longer to get to a subway platform than to a bus stop.
- a value for a pair of stops in a certain direction (due to traffic lighs configuration)
Describe alternatives you've considered
A visual indicator of short (IMHO <3 min) changes i.e. times between getting off one vehicle and onto another.
Additional context Another time-of-day and travel-distance dependant modifiers could account for traffic congestion (mind rail based vehicles are less prone, however trams make take slightly longer to pass intersections during rush hours) — it is known that a bus won't be on time so add n minutes when looking for a change. These options in turn could benefit from adding ON/OFF button to manually indicate the beginning and the end of each part of the journey. Logging the times for later analysis could make be a nice cherry on top.
As mentioned in #807, this is something where Transportr relies on the capabilities of the (very heterogeneous) data providers. As long as not most of them support this, I see very little value in implementing logic for it on Transportr's side.