Avoid very steep uphills

[Roland Pallai]

Hi,

What would be the right configuration to avoid this very steep (>30%) uphill ride after the 2nd kilometer?
 http://www.gpswandern.de/gpxviewer/tvanzeige.shtml?url=http%3A%2F%2Fh2096617.stratoserver.net%2Fcgi-bin%2Fbrouter.sh%3F18.99342_47.51749_18.96029_47.51566_trekking_0

I have some success with high uphillcost/uphillcutoff values (70/3), but I'm afraid that there are some drawbacks. Is there a better solution?

[abre...@googlemail.com]

Am Montag, 20. Januar 2014 16:24:17 UTC+1 schrieb Roland Pallai:

I have some success with high uphillcost/uphillcutoff values (70/3), but I'm afraid that there are some drawbacks. Is there a better solution?

Yes I think that will work (if used in addition to the 60/1.5 downhill term). This means using the downhill-term as the "general" elevation term and the uphill term as a special steepness-penalty.

Generally, I recommend cost*cutoff < 100% for the uphill and the downhill term each.

The reason is that for > 100%, if becomes possible to produce stupid local "micro-detours" that just add distance, but no ascend, and that would be considered as a wrong routing result. However, you will notice if that happens.

Imagine a chessboard-like street-grid made of 100m sections, 6% ascend when going north, 0% if going west. Costfactor=1. You are going north. When will the router start flip-flopping in east-west-direction? Going a triple-step (300m) to the west adds  (300 * 1 costfactor + 2 *90 turncost) = 480 to the cost. On the other side, it reduced your 70/3 uphill term by 70*300*0.03 = 630

So the router would flip-flop in that situation, but you also see that the turncost-term helps preventing that. So I think with your moderate parameters, in practice you will not see stupid effects.

[Roland Pallai]

Thanks for the explanation.

High uphillcost value does a good job, but not always perfect. I've modified lookup.dat and rebuilt my own .rd5 files with included "incline" tag:

lookup.dat:
 incline;0000120746 up_high 20% 21% 22% 23% 24% 25% 26% 27% 28% 29%
 incline;0000120747 down_high -20% -21% -22% -23% -24% -25% -26% -27% -28% -29%
 incline;0000120748 up_extreme 30% 31% 32% 33% 34% 35% 36% 37% 38% 39% 40% 41% 42% 43% 44% 45% 46% 47% 48% 49% 50%
 incline;0000120749 down_extreme -30% -31% -32% -33% -34% -35% -36% -37% -38% -39% -40% -41% -42% -43% -44% -45% -46% -47% -48% -49% -50%

and modified my profile to filter an extreme steep uphill (http://www.openstreetmap.org/way/189952096), but got a problem;
This one does not work as expected:

---context:way
assign extreme_incline_uphill
  and reversedirection=yes incline=down_extreme
assign costfactor
  switch extreme_incline_uphill 100000

but both expressions are true:

# works, way filtered by direction
assign extreme_incline_uphill
  reversedirection=yes

# works, way filtered by incline value
assign extreme_incline_uphill
  incline=down_extreme

Why "and reversedirection=yes incline=down_extreme" false when expressions reversedirection=yes and
incline=down_extreme are true..?

[Roland Pallai]

My bad: it was a data problem, the direction of the incline was reversed..

[abre...@googlemail.com]

Am Dienstag, 22. April 2014 15:03:47 UTC+2 schrieb Roland Pallai:

High uphillcost value does a good job, but not always perfect. I've modified lookup.dat and rebuilt my own .rd5 files with included "incline" tag:

Hi Roland,

interesting. I don't know if the incline-tag has good enough coverage to do the job. Last year I encountered a similar problem with a very steep up-hill when biking up to the monument at "Porta Westfalica"- but I remember this was'nt tagged tagged with "incline".

I would like to link to the other thread on that issue, with a slightly different focus (having a steepness tag to be able to choose way-types depending on steepness):

https://groups.google.com/d/msg/osm-android-bikerouting/WTx-TYPF08E/Bd0bxxq_p6QJ

Zossebarts approach was to calculate a steepness tag dynamically from the SRTM data, however, it seems difficult for me to make sure that these tags are not affected by SRTM-Noise. So using existing OSM tags is of course much more straigt forward. But to be able to add the incline tag you have to remove some other in order to stay within the 64-bit limit for the way description.

And that brings us to point to admit that BRouter's map-access layer with this 64-bit build-in limit needs a refactoring. A new version of the map-access layer should be able to:

• encode ALL Osm tags with a countable value set.
• encode not only bike, but also hiking relations with their tags
• encode turn restrictions
• include bounding boxes to assist wayoint matching
• have some build-in concept for "pre-filters" to replace whats currently done with the carsubset-datafiles

I'm not going to work on that, just looking for a volunteer :-)

[Roland Pallai]

2014. április 26., szombat 10:21:43 UTC+2 időpontban abre...@googlemail.com a következőt írta:

interesting. I don't know if the incline-tag has good enough coverage to do the job. Last year I encountered a similar problem with a very steep up-hill when biking up to the monument at "Porta Westfalica"- but I remember this was'nt tagged tagged with "incline".

Yes, it's mostly incomplete, but can improve with time. I'm working on a script that computes incline tag for OSM ways by bi-linear filtered SRTM data, the output is an OSM changeset - the first results are very impressive.
Refinements are depend on editors. The script can help with some QA later, like identify direction of up/down and warn on conflict.

I think a hybrid solution would be the best in foreseeable future for bicycle routing - use incline tag first and SRTM otherwise.
 

Zossebarts approach was to calculate a steepness tag dynamically from the SRTM data, [...] So using existing OSM tags is of course much more straigt forward.

Yes. Zossebart's solution can work in practice, but I think if there's such auto-calculated data, it should uploaded into OSM database and let the community to do refinements.

This much more straigt forward than calculate steepness again and again in every routing software with the same hard-to-fix errors introduced by SRTM inaccuracies..
 

But to be able to add the incline tag you have to remove some other in order to stay within the 64-bit limit for the way description.

Been there, inconvenient limitation. :(
 

And that brings us to point to admit that BRouter's map-access layer with this 64-bit build-in limit needs a refactoring. A new version of the map-access layer should be able to:

• encode ALL Osm tags with a countable value set.
• encode not only bike, but also hiking relations with their tags
• encode turn restrictions
• include bounding boxes to assist wayoint matching
• have some build-in concept for "pre-filters" to replace whats currently done with the carsubset-datafiles

I'm not going to work on that, just looking for a volunteer :-)

I hope you'll found. :) I've no java skills.

[cikr...@gmail.com]

Le samedi 26 avril 2014 14:21:37 UTC+2, Roland Pallai a écrit :
> I'm working on a script that computes incline tag for OSM ways by bi-linear filtered SRTM data, the output is an OSM changeset - the first results are very impressive.

Hi Roland

When looking through brouter group messages I came across your post back from 2014.

Currently I'm looking at ways to create incline tags for the area where
I'm living. What I already have is sonnys LiDAR-based DEM dataset [1] for Switzerland (integrated into Oruxmaps) and an OSM login (of course ;-)

I'm wondering what could be achieved - since Oruxmaps can show color coding of the incline for calculated routes which looks quite accurate to me.

Can you help me how to generate such changesets for OSM?

Thanks a lot.

[1] http://data.opendataportal.at/dataset/dtm-switzerland