Trekking profile and cycle-routes

[EssBee59]

It seems, the standard trekking profile do not calculate the right costs when a cycle route is defined on a way

2 examples:

http://brouter.de/brouter-web/#map=14/49.9399/8.9582/osm-mapnik-german_style&lonlats=8.954887,49.953097;8.924436,49.887188

http://brouter.de/brouter-web/#map=13/49.9767/8.5679/osm-mapnik-german_style&lonlats=8.578911,49.990673;8.451819,49.947091

bug_trekking.txt

(see cost of 1.000 / km for secondary and tertiary...)

[quaelnix]

I would call this a feature and not a bug: https://github.com/abrensch/brouter/blob/38fc780055e789ee1beb85b5e4439be7a38d8adc/misc/profiles2/trekking.brf#L279-L282 and if you dislike this behavior you can simply toggle the ignore_cycleroutes switch?

[EssBee59]

I do not understand the behavior, especially by a trekking profile. So I hope the developper(s) of the profile check that, a mistake by the handling cycle_route possibly exists ?

(every trekking router that I know will not route on the secondary hw between Babenhausen and Langstadt, this is too dangerous)
This profile is the default profile of the Brouter, each new user will start with it and the default parameters: Should he first learn how to change the parameters and especially 1 of the 30 parameters of this profile?

See: ...... assign is_ldcr = if ignore_cycleroutes then false else any_cycleroute .... and .... else if ( is_ldcr ) then 1 # always treated as perfect (=1) ... So, a cycle_route (possibly defined for race-bikers who used that way once at a week.end without traffic) impacts the costfactor dramatically (primary get the same cost as the best cycleway t.m "1".

[quaelnix]

The comment in the code says:

always treated as perfect (=1)

and the code does do that.

this is too dangerous

Flip the avoid_unsafe switch?

a mistake by the handling cycle_route possibly exists ?

I don't think that there is a good solution for the dilemma that you cannot make a profile that works perfectly world wide, see the examples in the first post of this thread: https://github.com/abrensch/brouter/issues/479

[quaelnix]

possibly defined for race-bikers who used that way once at a week

• The route relation: https://www.openstreetmap.org/relation/299353#map=13/49.9333/8.9693
• The official description: https://www.rmv.de/c/de/service/freizeitangebote/rhein-main-vergnuegen/rhein-main-vergnuegen-route-5-unterwegs-im-dieburger-land

Bis auf wenige Ausnahmen verläuft sie getrennt vom Autoverkehr.

With a few exceptions, it runs separately from car traffic.

It seems obvious that the route relation in OSM is simply wrong.

[quaelnix]

The official map clearly shows that the route is not supposed to be on the L 3065 between Babenhausen and Langstadt!

[EssBee59]

Of course, errors in OSM are possible. But I think this is not a unique case. See quick search with overpass (not giving a perfect result, but helpful)

rel({{bbox}})["route"="bicycle"]->.rels; (way(r.rels)["highway"="primary"]["cycleway"!~"lane"]["cycleway:both"!~"lane"];>;); out;

or rel({{bbox}})["route"="bicycle"]->.rels; (way(r.rels)["highway"="secondary"]["cycleway"!~"lane"]["cycleway:both"!~"lane"];>;); out;

[quaelnix]

Here is a reasonably correct overpass query: https://overpass-turbo.eu/s/1zDU

[poutnikl]

Nobody should say parameters of the default trekking profile are complex until meeting mine. :-)

[EssBee59]

See discussion in https://github.com/abrensch/brouter/pull/641