poutnikl / brouter-profiles Goto Github PK

I wanted to ask about turncost for main roads

assign turncost       if  ismainroad  then 90    else if ispaved then 60   else 30  

Maybe 90 is a bit high.
Often when I go down from a mainroad, I have better vision of what is happening, than when I have to turn in small residential sideroads, and don't have to slow down much more
The tecking-dry also produces something odd here

Just a discussion, I am not entirely certain it is a good idea, but I tried many routes and none got worse, and this problem above was fixed
Also the argument from experience above would tell me that turncost might be the same on small and large roads, in average

Hi,
sorry to start another discussion about profiles here, but I found something that might be interesting to look at again
Using the Trekking-fast profile on this example route:

http://brouter.de/brouter-web/#zoom=15&lat=50.91642&lon=14.15751&layer=OpenStreetMap&lonlats=14.14582,50.917402|14.16966,50.911868&nogos=&alternativeidx=0&format=geojson

A long part of the way is "surface=gravel"
Gravel are really large stones, according to OSM Wiki. It is impossible to go over with a racing bike, and on that part of the way even with a mountainbike you can do no more than 8km/h.
(yes, it is absolutely idiotic that it is part of a cycleroute, but I did not design that route and that is not worth discussing here)
We definitely want to avoid that part and go over the road with asphalt here
How can it be fixed to do so?

Thank you

PS: Let me know if you'd prefer discussions like this on the brouter google group

Hello poutnikl, taking over from brouter repository: In abrensch/brouter#283 you gave some insight, in how ascent is accounted for:

E.g. 5 km of 5% steepness means (5%-3%)x5000m x 7 = 100m x 7 = 700m extra distance penalty.

At 4kmh walking speed, this should take me 1.425 hours (5.7/4)

The swiss formula (acc. to https://de.m.wikipedia.org/wiki/Marschzeitberechnung) goes like this : duration in hours = (ascent in m / 400) + (distance in km / 4). Descent may get a divisor up to 800.

Above walk will take me 1.875 hours (250/400 + 5/4)

Can this be tuned to match? Too lazy now. A thought experiment: When the distance penalty gets larger, the values will get closer. When comparing routes of different length, a bigger penalty will have more influence on the shorter route, than on the longer route. So the router will base its decision less on distance.

Of course this would also work the other way. If you climb 500 m/h, the swiss formula will yield 1.125 hours. I think I got You!

Exposing just major profiles, and referring to the minor ones to template repositories

Hello!

I discovered that in Budapest there are a few more tags used for bicycle relevant roads than in your profiles.
For example:
cycleway=lane
cycleway:right=lane
cycleway=shared_lane

Is it possible to include these too in the profile, or the brouter segments does not contains these by default?
If possible then I can collect them for you, or maybe I can include theese in the profiles if you tell me how to do. :)

Best,
Gabor

I do wish to add traffic_calming nodes into the routing, like traffic signs.

A traffic sign is less annoying then a traffic_calming=bump or traffic_calming=dip.

One road can have multiple traffic_calming nodes, each one should add some cost to the route.

First of all, great work with this router. I use it all the time and I have fun with fine-tuning my profile.

Is there a way to add additional node costs for yield/stop signs? It must account for the direction of the sign and the direction of the route. I believe just adding a cost for highway=give_way or highway=stop will add the cost even if the sign is facing away.

trekking-mtb-light.brf and trekking-smallroads.brf I receive the message: "does not contain expressions for context way (old version?)". "route can't be calculated".

I can do it locally with winmerge in local depository, and then sync with github via github for windows..
Can I do anything like then directly in github, without local software support ? ( PC SW policy )

I'm searching for a cross-country profile to be used in Brouter Android app, which is used by apps like Locus.
Would it be possible to develop profile and ship it with a future release of BRouter's android app?

(This is a Crosspost of abrensch/brouter#652 . I think it would be useful to post answers just in one thread, but I'm not sure which is the better place to discuss profiles)

I use the Walking profile in mixed suburban/rural environments. It generally works wonderfully, but occasionally I see silly routing which I am attributing to the handling of sidewalks.

I am using this to document some experimental changes to the walking profile to better handle sidewalks

Pull request to following if this all works out

Hello,
I like your profiles but I'm missing a special profile for my (and other peoples) purposes:
I like hiking and trekking on ways in or near the nature. I'm missing a profile which prefers forest ways, field ways and small local roads and which avoids (if possible) large roads and main streets. The best results I get from the profile Trekking-MTB-medium.brf but it follows large roads and main streets, when they have footways and/or bicycleways at their side. This is annoying.
Could you create a profile with priority steps like:
HIGH: forest ways => field ways => small local roads => ........... => path=sidepath and/or is_sidepath=yes or similar ways => large roads => main roads. LOW
Such a profile would be perfect.
Best regards -Holger-

See https://bikerouter.de/#map=13/51.0169/11.7373/osm-mapnik-german_style,terrarium-hillshading,Waymarked_Trails-Cycling,Smoothness,route-quality&lonlats=11.761187,51.032423;11.674756,51.006542&profile=Trekking-dry.

The problematic descent is around km 5, south of Frauenprießnitz: a track with tracktype=grade2 on a -16%+ gradient. IMHO that seems like a fairly dangerous suggestion – I'd expect an eroded bumpy surface and difficulty braking because typical trekking tires might lose traction.

IMHO steep descents on unpaved surfaces ought to be penalized harder. OTOH, I think the alternative descent on a secondary road could be penalized less: https://bikerouter.de/#map=13/51.0151/11.7245/osm-mapnik-german_style,terrarium-hillshading,Waymarked_Trails-Cycling,Smoothness,route-quality&lonlats=11.761187,51.032423;11.757259,51.001229;11.674756,51.006542&profile=Trekking-dry

Screenshot of the default suggestion:

Screenshot of what I think is a safer and more enjoyable route:

That does not seem super easy to maintain, having a script to generate the content of this repo directly might be useful as an improvement. So, the conclusion is that user eager to get the latest version should build from the dedicated sub-repositories, if I understood correctly.

The bash script sedbatch, running in termux/Android, already works with git, producing zipped profiles. With a command modifier parameter, it could make the respective commit and push to the Github.

To be implemented. :-)

abrensch/brouter#604

Hi! I am bafled by the lack of a commuting profile both on your collection and on the brouter standard profiles. I understand that one can cook one as per your instructions, though, why not offering one right away?

Hi,

the trekking profile currently seems to have a bug, where it routes through barriers
For example it will go though a "barrier=gate", that does not have bicycle=yes or any other access tag specified

I would suggest to do the following on any barrier:

1. Check if it has a "bicycle" tag, if yes use that
2. Check if it has a "foot" tag, if yes use that (if it has foot=yes and no bicycle information, we can probably push trough it at least)
3. Check if it has a "motor_vehicle" or "motorcar" tag, if yes use that (if a car can pass through and no bicycle information is given, we can likely use it with a bike)
4. If neither is present, check if it has an "access" tag, and if yes use that
5. If none of these tags is present, assume the gate really blocks the way and avoid it

Unfortunately I could not quite figure out where to fix this, help would be really welcome

Thanks
Jakob

Hi poutnikl.
your BRouter profile are great! I use e.g. the MTB profile for my MTB tours.

However, I miss a profile for touring cyclists (with luggage) -> long-distance travel:
if possible on bike paths (all variants)
if possible without car traffic, or little car traffic,, e.g. at least on track type grade3 (grade4?),
avoiding strong gradients (for example > 13%) ...

Does this already exist?

I found your instructions to create it myself - but I'm not sure if I can do it optimally.
-> Release version - or Development/Beta version

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

Hello Poutnikl,

I'm impressed with the profile collection. Since I, next to mountainbike, als use my race bike, and like to do tours in the hilly parts of Flanders, I was looking to combine the 'no-flats' mode with the fast bike profile.

However, I struggle to find the proper settings, especially with the linked parameters MTB_factor and smallpaved_factor.

What is the 'code block' I need just to activate the 'no flats' behaviour, without the preference for smallpaved or other highway settings?

Kind regards

Brouter's trekking bicycle profile sends me ~20meters on a primary highway which is tagged with bicycle=use_sidepath, because it makes a shorter route. In reality this shortcut cannot be taken by a bicycle.

I would expect to be never sent on highways with this tag.

When cycling, I usually try to avoid level railway crossings because they are sometimes closed for 5 minutes or more. This can be encoded in a bike profile like this:

@@ -556,6 +556,7 @@ assign initialcost =
               else if and highway=crossing bicycle=no then 60 
               else if and highway=crossing crossing=no then 300 # workaround affecting road routing
               else if ( ford=yes ) then ford_initialcost_node
+              else if ( railway=crossing|level_crossing ) then 300
               else initial_cost_node )

Would this be a good addition to the generated profiles / the profile templates?

Hi,

I was expecting the MainProfiles folder to be some copies (or symlinks) of the matching profiles in the dedicated folders. For instance, I would have expected MainProfiles/Trekking-dry.brf to be the same as BikeProfiles/Trekking-dry.brf. However, it seems this is not the case and there are a few differences between the two files.

What are the differences between MainProfiles and dedicated profiles then?

Thanks!

The comment in
abrensch/brouter#51 (comment)
explains how to make routing aware of oneway:bicycle=yes
Copy+paste into your trekking profiles worked for me, it should probably be included in all profilkes

Hi,

maybe fords can be added?
https://wiki.openstreetmap.org/wiki/Key:ford
A part of a street that is marked as ford=yes could be assumed flooded, and have a really high penalty. Same goes for crossing a ford=yes point, that is on the way.

Or are they too rare to be considered in the route calculation?

Thanks