Electric bicycle trailer for children

[poutnikl]

Hi

First of all, thank you very much for your work - brouter and Poutnik's profiles are just great.

Our situation might be a bit special since we have a bike trailer used for one (soon: two) children which is powered by a wheel hub motor, combined with "conventional" bikes. This drive likes running at around 25 km/h. We just returned from holidays in Südtirol where routes have been proposed which have been too steep for this system.

So my question is: can your profile be tweaked such that it doesn't route with slope > ~ 10-12% ?

The profile we used is based on the Tandem dry trekking profile which itself is based on v2.6 of Poutnik's Trekking profile, including some modifications:

• cycleroutes_pref 0.5 instead of 0.2
• MTB_factor 0.5 instead of 0.0
• smallpaved_factor 0.5 instead of 0.0
• hascycleway only for tracks (for better safety)
• additional path penalty of 0.5 * haulpenalty if highway=path and not isbike
• slight adjustments for not_isbike_penalty (for better safety)

With these modifications we got excellent routing in the foothills of the Alps (hilly) where we live as well as e.g. in France (Burgundy).

But in Südtirol we got routes proposed with 9.5 km, 286 m elevation gain and a max slope of ~15% for ~300 m, preferred over 12.2 km, 298 m elevation gain and max slope of ~10% (I understand why the shorter route has lower overall costs).
Is there a "workaround" in order to exclude such slopes (> 10-12%) which are unrideable with the trailer (similar to steps)? I've found that with uphillcostvalue 75, uphillcutoffvalue 3.2 the rideable route would be preferred in this very case - but is this the way to go? 50/5.0 would also work, and it would be along "with electric power, smaller slopes (<5%) don't matter" - but if we ride together, my wife takes trailer and motor while I've to pedal myself, without the 'e'... What do you recommend?

Thanks for your help (might also be helpful for others).

C. Kristol

See the original thread on the BRouter discussion group

[utack]

I would be super interested in this,it is actually one of the initial problems i still have not solved

utack/utack_brouter_profile#4

I hope you find a solution using the brouter framework

[b-misc]

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?)?

[abrensch]

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.

[poutnikl]

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.

[poutnikl]

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.

[b-misc]

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)?

[poutnikl]

Yes, you are right, the effects on elevation cancel each other with the same values.

[poutnikl]

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.

[b-misc]

OSM incline tags: data is included in the brouter data files?

[poutnikl]

For now, I recommend preparing routes in advance, and consulting the route with visual map check on BRouter web or the phone.

[poutnikl]

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%

[b-misc]

OK, will try adding a code block for the incline tag (in a few days).

Thanks a lot so far!

[poutnikl]

You have to test always just the first value, e.g incline=10% for values 9 10 9% 10%

[poutnikl]

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.

[b-misc]

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

[poutnikl]

@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