GIScience
Considering elevation for duration of travel in routing and isochrones
Considering the elevation information can, if implemented properly, be a useful option for all services. For the isochrones for instance it is quite handy to know how far an object can move in a certain amount of time if the steepness of roads change. The logic of this is already implemented and has been used in the past and should be added again asap; however it but produced some weird artefacts when routing if I recall correctly (ref #212).
I suggest we take a deeper look into this as it has been asked by many users, especially for isochrones (@masain can provide examples). Also, when considering elevation we shouldn't change the route, my suggestion is that should only use the speed information (forward, backward) for the given edge depending which direction is traversed to ultimately end up with more realistic durations.
@rabidllama @marq24 @GIScience/openrouteservice what do you think?
Also, when considering elevation we shouldn't change the route, my suggestion is that should only use the speed information
there is a small dilemma - since adjusting the speed of a way have instant impact on the routing calculations - since the code (always) tries to find the fastest route.
In our previous impl. this speed reduction (uphill) and increase on downhill was the root cause of this "none reasonable" detours (at least for the bike)...
I don't mind to get a closer look into this issue again - since it's quite reasonable that uphill takes longer and this should be reflected in the travel time... the question is, how to calculate "correct" the slowing-down-factor ?!
@marq24 of course, you are right. Even with the artefacts the results were ok for isochrones as this was aggregated data for routing it's a different case.
- Could we actually ignore anything less than 3% for instance and start adding forward/backward speeds for "higher" percentages?
- Could we make this an "optional" setting to be added to the API or would it eat up too much space?
Any further thoughts how to avoid detours that don't make much sense?
please do not get me wrong - I really would like to get this to work... One of the things that makes it quite hard is the filter (how to decide when a "climb" is significant)?
The initial thought is of course you take the start & end of a way and subtract start ALT with end ALT and based on this delta you calculate the "climb"...
The problem (IMHO) is, that you can not be sure, how "long" your actual OSM way is - It could be that you have a 6km constant ascending road going from 100m (above sea level) to 500m... If this road will have no junctions with other ways then this 500-100 is a pretty good indication of a solid climb...
But if this road have joins with other ways, then (if I do not have understood something fundamentally wrong) then we do not have the complete 6km - we will just get chunks of the road - could be sometimes 500m sometimes just 10 (depending of the nature of the joining roads)...
So we will receive plenty of "smaller" elevation deltas - the "overall" the summ should be still the same - but at a certain intersection the delta might be just to low...
I came across this issue when I tried to fix that initial issue in the road bike profile where I decided that a way 'should have' at least a certain length before the elevation speed adjustment would be applied... During my debugging I had to realize that almost all of my ways (that I have reviewed in my testings) have been too short in order that they will taken into account - When I then reduced the length (so that the elevation/speed fix have been applied) the "inaccuracy" of the elevation data messed up every serious calculation...
Calculate the climb (in m) of a certain OSM way is honestly a pain in the ass - I have tried many different things in my GPSLogger application - where I want to announce/display the cyclist "Hey next 3km you have to master 250 altitude meters"... Even if I have now something in my App that can do the math somehow - it can't be applied IMHO to ors - since my code is based on average elevation data for a certain length of the planed route - so I first normalize the distance and then I do some Durchschnittsberechung for the elevation data - IMHO we can't do that in out case - cause "ways" can't be normalized :-/
Yea, it seems to be quite an endeavour @marq24 ;-) could we start of using the current implementation but making it an option to enable/disable (probably disabled by default) ? This way we could benefit from it in the isochrones case at least and then start brainstorming about the directions use case a little more? Could we there just ignore anything less than 3% ?
i hope there are other opinions here as well (we should also start a voice chat about this issue) - for your hybrid solution - I am not aware, that It's possible to encode two different speeds for a single way [and switch dynamically between speedA (default) and speedB (isochrones)] - but I am quit a noob when it comes to this kind of things - no idea how the extra storages are working and how/when they will be used :-)
The implementation of the storages should not be too difficult as soon as we switched to GH 0.12. Storing a further forward and a backward speed with the same precision as for the "normal" speed would require additional 4bytes/edge. However, to make sense of such a feature, we have to clarify many questions. Here are just a few to start a list:
- Is the elevation data sufficiently precise?
- Does it contain bridges, tunnels and other things which influence the altitude of the road?
- How do we deal with hairpin turns?
- What about individual preferences? At which downhill speed one is willing to travel is rather subjective.
@sfendrich - we had implemented this previously (for bike profiles) - we removed it - the issue (but I guess that's a face2face discussion) is, that the data needs to be normalised [elevation gain/loss in a certain distance interval (that is matching the current elevation data grid)] in order to be usable...
@sfendrich thank you, maybe I can shed some light on your questions:
- Is the elevation data sufficiently precise?
It's as good as SRTM/GMTED gets, we might be able to obtain Tandem-X data one day which will increase the spatial resolution, both horizontally and vertically.
- Does it contain bridges, tunnels and other things which influence the altitude of the road?
Graphhopper has worked on this in one of their recent updates: https://github.com/graphhopper/graphhopper/issues/1363
- How do we deal with hairpin turns?
A similar situation as with narrow valleys: we can't very well.
- What about individual preferences? At which downhill speed one is willing to travel is rather subjective.
Correct but we have to start somewhere and depending on the feedback we can iterate, what do you think?
Generally I think we should have this optional - hence an extended storage sounds good!
Consideration of elevations for Isochrone time calculations would be really helpfull especially for the foot-walking, cycling, and wheelchair profiles in hilly areas (like Stuttgart ;). I'm really looking forward to having this implemented in the ORS!
Greetings Fabian
hi
about the removed code (for bike profiles) consider elevation.. this code is commented? or removed totally? can I look for it somewhere in the code?
I look that bike profile ha a option: "encoder_options": "consider_elevation=true"... in app.config here: https://github.com/GIScience/openrouteservice/blob/master/openrouteservice/src/main/resources/app.config.sample#L210 if I understood you discussion this option now does not produce any differents in result right?
many thanks
@stefanocudini sorry for my late reply... The main reason why the code was removed is cause the resulting routes where plausible from the data side point of view - but not very logical for a cyclist.
In the implementation the elevation gain/loss was calculated into a speed boost/penalty... The approach is suboptimal. It would be better to look at the complete profile and compare alternative routes (if they have less alt gain/loss)...
I've stumbled upon the mentioned issues for cyclists and first wrote a comment here https://github.com/GIScience/openrouteservice/issues/806#issuecomment-738791316
Today (late 2020) I believe you have all the data you need to get it implemented: The directions api endpoint returns dist/duration between two points but also steepness of the route - in percentages. So it seems like it would be enough to juest multiply base speed by those to get the duration that factors in elevation. Even having predefined speed penalty/boost for elev gradient would be better than how it is now.
I'd need this feature in matrix endpoint though - I have fairly small amount of points - 11 total but it is still too much permutations to pipe down into directions in reasonable time. Is there any chance this feature will be improved some time soon ? Edit: Graphopper also ignores elevation for MTB. 6km 600m climb in 25min - feels like a pro athlete time
Even having predefined speed penalty/boost for elev gradient would be better than what is now. I totally agree