Comments (16)
I would be super interested in this,it is actually one of the initial problems i still have not solved
I hope you find a solution using the brouter framework
from brouter-profiles.
The problem with uphillcostvalue and uphillcutoffvalue seems to be that high values (like 140/5.0 or 150/6.0) may be required, creating interference with things like cycle routes preference: trade-off: do you prefer lower slopes over safer routes?
Maybe something like exponentially increasing costs for slopes > x would be a solution (which brouter currently doesn't support?)?
from brouter-profiles.
Here's a 5 years old thread on the subject, I think that's the best analysis on the subject:
https://groups.google.com/forum/#!msg/osm-android-bikerouting/suIs8XBlAMQ/yy9eYeOCANUJ
TL;DR
you can use the downhill-term as your "overall" elevation penalty and the uphill-term as a special high-slope penalty by putting a large cutoff. Roland said he had some succuss with 70/3, so e.g.:
assign downhillcost = 60
assign downhillcutoff = 1.5
assign uphillcost = 70
assign uphillcutoff = 3
(though theoretically anything with cost*cutoff > 100 could be instable, but practically 70/3 (=210) seems to work.)
Better results of course you could get by using the incline tagging, butI still don't know how widely used it is.
from brouter-profiles.
I already use the above 1.5/60 3.0/70 as default values in my template for some time as hills=1 parameter set.
Some dual penalisation rate can be achieved via above mentioned dirty trick in the utack issue thread with uphillcostfactor shift and bufferpenaltyreduce , but it is applicable only to low versus medium slopes.
For high slope eliminations, we are out of possibilities within current designs, aside of the incline tags. But as you are afraid, I suppose it will not be reliable due lack of such tagging.
from brouter-profiles.
For C. Kristol:
Be aware MTB factor is a complex parameter, affecting the final uphillcost/cutoff values.
That is reason why I introduced up/downcost/cutoffVALUE as initial values.
The real final parameters, up/downcost/cutoff, used by BRouter, are computed.
Increasing MTB factor is decreasing elevation penalisation, encouraging usage of less flat routes.
from brouter-profiles.
MTB factor is increased but also smallpaved factor, with the first one decreasing elevation penalisation, the latter one increasing it (according to the corresponding wiki page); but I didn't check the profile if to the same extend.
Since 70/3.0 has been used (by setting hills=1) and routes have been quite good except for the holidays in very steep South Tyrol, I'm now unsure if I should change it to 75/3.2 just to fix that one route; but as I already mentioned, I looked at different routes where we live (better known area...) and found that it's not that clear which values are required - it heavily depends on the route you are calculating.
The main problem I currently have is that my "main user" is my wife, with Oruxmaps, brouter and Openandromaps, and maybe it's best to explain her how the color codes of routes have to be interpreted and that she has to look at parts which are red and thus too steep; if she tells me about them, I might add incline tags to OSM. Incline tags are currently not evaluated in brouter/the profiles (but one could use the profile fragment mentioned in the old google group post)?
from brouter-profiles.
Yes, you are right, the effects on elevation cancel each other with the same values.
from brouter-profiles.
As Arndt mentioned more times, values cost*cutoff >> 100 introduce high probability of routing artefacts, e.g adding unjustified microdetours to formally decrease the average slope.
from brouter-profiles.
OSM incline tags: data is included in the brouter data files?
from brouter-profiles.
For now, I recommend preparing routes in advance, and consulting the route with visual map check on BRouter web or the phone.
from brouter-profiles.
Yes, incline tag is there, in form of particular values representing particular percentages.
The problem is, these tags are rarely used in Openstreetmap data.
Another problem is, it is used mainly on MTB tracks, that I suppose will be avoided in your planning.
incline;0000052784 up
incline;0000035413 down
incline;0000001628 yes
incline;0000000779 steep
incline;0000000861 3% 0 1 2 3 0% 1% 2% 3%
incline;0000000724 5% 4 5 4%
incline;0000000530 8% 6 7 8 6% 7%
incline;0000003109 10% 9 10 9% 10�
incline;0000001297 15% 11 12 13 14 15 11% 12% 13% 14%
incline;0000000997 20% 16 17 18 19 20 16% 17% 18% 19%
incline;0000000409 25% 21 22 23 24 25 21% 22% 23% 24%
incline;0000000263 30% 30 40 50 40% 50%
incline;0000000861 -3% -1 -2 -3 -1% -2% -3%
incline;0000000724 -5% -4 -5 -4%
incline;0000000530 -8% -6 -7 -8 -6% -7%
incline;0000001515 -10% -9 -10 -9% -10�
incline;0000001297 -15% -11 -12 -13 -14 -15 -11% -12% -13% -14%
incline;0000000997 -20% -16 -17 -18 -19 -20 -16% -17% -18% -19%
incline;0000000409 -25% -21 -22 -23 -24 -25 -21% -22% -23% -24%
incline;0000000172 -30% -30 -40 -50 -40% -50%
from brouter-profiles.
OK, will try adding a code block for the incline tag (in a few days).
Thanks a lot so far!
from brouter-profiles.
You have to test always just the first value, e.g incline=10% for values 9 10 9% 10%
from brouter-profiles.
Another way, available in LocusMap, not sure about Oruxmaps,is optional colouring of routes by calculated slope from LocusMap SRTM data.
It is quite reliable, even if occasionally influenced by SRTM artefacts.
from brouter-profiles.
Orux does use colors as well, and I added DEM files based on LiDAR manually which seem to be very precise: http://data.opendataportal.at/dataset/dtm-switzerland
from brouter-profiles.
@b-misc Avoiding too steep uphill can be achieved by
- sacrifising uphill penalty, keeping just downhill penalty,
- setting uphillcutoff to the inacceptable steepness threshold
- defining highly penalizing uphillcostfactor
As an illustration see the profile below.
It is based on the original Fastbike-lowtraffic-tertiaries profile for group cycling in small paved roads in range of tertiaries to grade1 track and cycleways.
It was then modified for strong penalizing of unpaved surfaces and steep hills above 7%, as it was aimed for a disabled cyclist on a handbike.
FB-LT-tertiaries-paved-notsteep.zip
from brouter-profiles.
Related Issues (20)
- Not avoiding an unpleasant way HOT 3
- cost for routing over "ford" HOT 16
- Profile Hiking/Trekking near nature HOT 17
- Missing route types used in Budapest HOT 13
- traffic_calming nodes not evaluated for cost factor HOT 3
- sidewalk HOT 1
- Main vs dedicated profiles HOT 9
- Missing Commuting profile HOT 2
- Profiles do not contain expressions for context way (error Osmand 2019/07) HOT 6
- Brouter-profile for touring cyclists with luggage -> long-distance travel HOT 7
- > a script to generate the content of this repo directly might be useful. HOT 1
- Ascent in hiking profile HOT 12
- Avoiding yield/stop signs HOT 7
- Road-race bike profile with 5=No-Flats mode HOT 2
- Ignore bicycle=use_sidepath ways HOT 3
- Add penalty for railway crossings?! HOT 2
- Trekking-dry and other profiles select 16%+ descent on grade2 track HOT 4
- profile=hiking-mountain routes over way with foot=no
- Cross-country skiing profile for Android app
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from brouter-profiles.