Problem with bicycle routing using elevation data

[Posteinwurf]

Dear all,

the inclusion of elevation data in bicylce routing is great, but there is still one issue. I experienced it in Vienna:

With elevation data on in "safe" mode, the route is changed to a main road with heavy traffic - but without saving any height meters.

Maybe the elevation mode overrides other preferences (in this case, the avoidance of main roads in safe mode)? Or maybe the elevation data just get too much priority over other preferences? Another observation hints in this direction: When elevation mode is on, quite often Osmand will take a totally different route, even if no height meters are saved (or only a few).

I would like to work in this myself, but first I need some basic understanding of how the elevation mode works. Could someone explain the basics to me, please?

1.) Without elevation data, each way gets a speed (e.g. 25 kmh), multiplied by a factor (e.g. 0.9). So how do the elevation values come in here? Do they add a second factor to each way? (So that you get 25 x 0.9 x 1.2 for example)? 2.) I also would like to get some basic knowledge about the different command lines used in the obstacle_srtm_alt_speed section.

Thank you very much!

Malte

[vshcherb]

You can try to play around with it here https://github.com/osmandapp/OsmAnd-resources/blob/master/routing/routing.xml#L725.

Basically it is a multiplier "height difference" * on this value that's add up to routing_time. The best way to try it out in OsmAndMapCreator (routing time shows up in the console)

[Posteinwurf]

thank you for the fast answer!

Maybe I will start to try something this weekend. But still need to know more, because the syntax seems to be different from the rest of routing.xml. Here are my questions:

a) Is the height multiplier added to each road / path individually (like the multiplyer for “asphalt” for example)?

b) what does this command line do? gt value1="-100" value2=":incline"

c) And what are these three lines doing? select value="-1" t="osmand_highway_integrity_brouting_low" v="yes"/ select value="-1" t="highway" v="path"/ select value="-1" t="highway" v="track"/

thank you!

Malte

[Zahnstocher]

I will try to explain.

routing time [seconds] = distance/(speed*priority) + turn time + transition penalty time + obstacle time + height obstacle time

height obstacle time [seconds] = multiplier * height difference [metre]

The multiplier depends on the incline [%]. The incline of the way segment is "rounded", but I don't know the reason: incline = round down((incline + 2)/ 3) * 3 - 2

The height obstacle time is calculated for every segment of a way and then added together (a way could be split up by nodes into several segments).

For example:

<gt value1="25" value2=":incline">
<select value="10"/>
</gt>

means:

If incline > 25%, then the multiplier is 10.

If the select value is negative, the road is not passable.

a) Is the height multiplier added to each road / path individually (like the multiplyer for “asphalt” for example)?

Yes, depends on incline and height difference.

b) what does this command line do? gt value1="-100" value2=":incline"

If incline is more than 100 % down.

c) And what are these three lines doing? select value="-1" t="osmand_highway_integrity_brouting_low" v="yes" select value="-1" t="highway" v="path" select value="-1" t="highway" v="track"

If osmand_highway_integrity_brouting_low == yes or highway=path or highway=track, then multiplier = -1. Negative multiplier means "road not passable".

Thus b) + c) means: If the way goes down more than 100 % (= more than 45 degrees!) and highway integrity for bicycle is low or it is a path or it is a track, then the road is impassable.

[Posteinwurf]

Thank you! Very clear explanation. Now, I can work with that and test how different values affect the routing.

Let’s see if I get it right: If we have an incline of 26% (multiplier 10) and a height difference of 20 meters, the height obstacle time would be 200 seconds, right?

[Posteinwurf]

Dear all,

I have looked at the elevation code, and I think that I have spotted some possibilities to improve it. Could you please check if my general ideas are right? If so, I will then try to change the code to test it on different routes with elevation.

a) When going downhill, a penalty is applied when there is a bad surface (integrity_brouting_low). This is a great idea. But the same penalty is also applied when there is a path (or a track, in that case the penalty is only slightly lower). Improvement: Before applying the penalty for path / track, check first if these have a good surface, because there are many paths / tracks combined with tags like “paved”. Question: If we first check if there is a good surface, before we apply the penalty for paths / tracks, would that work? So if we have: select value="0" t="osmand_highway_integrity_brouting_high" v="yes"/ --> if Osmand detects a good surface with this command line, will it then ignore the two lines that come behind it?

b) A penalty for bad surfaces should also be applied when going uphill, I think.

c) In smoothness_factor_more_plains there is the following set of commands (in this order):

If elevation is greater than 3, then penalty factor is 2 If elevation is greater than 7, then penalty factor is 12 If elevation is greater than 13, then penalty factor is 30 If elevation is greater than 25, then penalty factor is 50. Any other case: Penalty factor is 74.

I think this might be the wrong order: If the elevation is greater than 3, then 2 seconds is already set. Will Osmand then still check if it is greater than 7? Maybe not. And also, the last line might be a problem: The 74 seconds would also be applied, when elevation is between 0 and 2 (and maybe also when elevation is negative?).

d) In the smoothness_factor_hills mode, routes with more hills are even preferred. That means: If there is a route with more elevation, it will even be preferred over a shorter route with less elevation. I think this only makes sense for a very, very small group of users (extreme training with mounting bike). I think that we should change this mode, so that we have three levels, where every level avoids elevation, but to a different degree.

all the best

Malte

[vshcherb]

Very important note, some of the numbers are a bit of compromise of the speed to calculate the route on device. Using srtm data on the device slows down the route calculation sometimes to 5-10 times, so please keep in mind. We did some basic tests in the cities we know to come up with these numbers. Please also don't use much stricter numbers for high incline numbers. Actually 13-25 for immediate incline are not critical numbers! Yes it is critical if you travel 100 meters up with this incline but this is not high it works in reality. In reality you could have 5 meters with incline 30% and 90 meters with 5%. This is not ground truth cause SRTM data have some noise and the incline actually make that noise bigger. So while travelling you might figure out that incline is actually 7% for all 95 meters. That's why the thresholds should be a little over constant (not exponential), in your case I see it is much more than linear (2/3,12/7,30/13,50/25).

[Posteinwurf]

thank you for all the explanations and input!

I am currently working on it and testing. I will try to keep everything in mind. Have already tested with different values and routes for some hours now, and I think I am getting near to the optimum. My test results seem to confirm what you said about the high inclines. So I will not put the numbers for high inclines higher. I think they should even be lower compared to the numbers for low incline. The test results show it, and also one systematic thought: If you have to climb 1000 meters, it is very bad at 13 per cent incline, but still quite bad at 3 per cent incline. You still have to climb these 1000 meters (so also with 3 per cent incline, it is a good idea to take a longer detour to avoid them). Will try to find some really good values.

[xmd5a2]

3 percent incline when climbing up 1000m is no problem at all for trained biker. In mountains incline very often gets more than 5%. As Victor said all these incline numbers are a compromise between speed of calculation and accuracy. I advice you to test routing time in console while testing them. Speed difference much be huge for different values AND different areas (mountains/plains).

[Posteinwurf]

Thank you for all all the input and thoughts. I hope and think they are considered in the suggestion that I just made.

It will still heavily prefer a 1000 meter elevation that is stretched out over the whole route to a steep 1000 meter elevation (and afterwards flat route). Examples from my suggestion (in this case for the “more plains” mode):

If we have 7 % incline instead of 3%, the penalty for these 1000 meters will almost be doubled. If we have 15 % incline instead of 3 %, the penalty for these 1000 meters will be more than doubled. If we have 25 % incline instead of 3 % the penalty for these 1000 meters will be tripled.

In the other modes, the penalty can even be quadrupled in some cases.

Maybe, we can still set the values higher, but I do not think it is necessary. And higher values can lead to errors. If the values get too high, the incline gets so dominant (compared to the other routing factors), that it causes wrong routing. Like the error in Vienna with “Wattmanngasse vs Maxingstrasse”: The last part of the route is steep in both alternatives, but the routing would falsely prefer Maxingstrasse (tertiary without bicycle track), even in “safety” mode. So a slight difference between the two elevations (only 7 meters) lead to a huge chance in routing. And the difference between the two routes could even be due to noise in the elevation data.