routing over bicycle=use_sidepath

[majkaz]

Is there some reason, why is brouter completely ignoring the bicycle=use_sidepath or is this an omission?

Every bicycle navigation (not only brouter) is sending me on primary and secondary road marked with bicycle=use_sidepath and foot=no, where there are separately mapped bicycle paths. These were tagged as highway=path, bicycle=designated, foot=designated. The path is signposted, official, not separated foot- and cycleway. I don't see the reason why these (with surface=asphalt and lit=yes) in combination with the "use_sidepath" on the primary/secondary road are ignored in every profile. I know you could ignore the legal obligation but there is no reason here to do so. The "main" road is very unsuitable to downright dangerous for bike traffic with an alternative way just a few meter away. 

It is mandatory to use the sidepaths, legally you cannot drive on the "main" road for a big part of the route. There are only small parts where this is not very clear (cycleway on the left, but still mandatory) or not true. All the connections to the bike paths and highways are correctly mapped, cycling needs slightly different route because of this - for example, you ideally have to take the parallel residential road in one small part (again, just a few meters from the secondary road to avoid additional crossings). 

Is there a way to tweak a profile at least to "punish" using the primary/secondary/tertiary road severely, if not forbid their use completely?

I have attached the route (brouter.gpx). The ideal one here would be following the route in the second file. And yes, goes in opposite direction on a residential oneway street for about 100m.

Note - the "highway=path" is currently changed to highway=cycleway to see if it helps, everything else is left how it was. I have nothing against changing the tagging in OSM. However, the initial tagging should IMHO be equivalent to the highway=cycleway, just another way to tag it and preferred by JOSM preset.

To be clear - this route comes from routing only as an alternative, almost every profile is as default routing over some longer route. Again, not sure what in the OSM data is causing this.

Majka

[Poutnik]

Ahoj Majko z Ceskych Budejovic, ( EN KBD here only )

To je velmi hezke ze CB maji cyklistky,
ktere vedi, co je to JOSM a BRouter. :-)

Back to EN for the the Brouter group benefit:

For referring to a particular map scenarios,
it is recommended to provide a permalink ( right down corner link )
from http://brouter.de/brouter-web/

Then one can easily review the OSM tags related to affected ways.

Analyzing scenarios based on GPX is less convenient,
OTOH, the Brouter-web is for now useful on desktops only. (changes soon)

--------

The problem can be divided into 2 separate issues.

1) TAGVALUE AWARE PROFILES

As bicycle=use_sidepath does exist in the
http://brouter.de/brouter/profiles2/lookups.dat
Brouter does not ignore this tag value.

What do ignore this value are Brouter profiles.

Arndt ( the author ) and myself as well usually include
only major tagvalues into the profiles,
based on Germany relative occurrence from lookups.dat.

It gives roughly about 0.04% of all the bicycle=* tagvalues.

what I can see at
https://taginfo.openstreetmap.org/keys/bicycle#values
world-wide usage is muc wider, more than 1% of tagvalues.

It can be easily add to any profile, if needed,
and I have done so for my profile template below.

Not that if there is explict traffic sign "forbidden for bicycle", or
equivalent, thare must be bicycle=no.

bicycle=use_sidepath is for cases,
where there is implicit obligation to use the sidepath,
but no explicit forbidding sign.

2/ ROUTING PREFERENCE.

There is needed to raise cost of main roads with bicycle=use_sidepath
to push the routing away from them to the side paths.

By a quick and dirty way to do so for any profile by this way:
Replace

assign costfactor <whatever expresing till next assign statement>

by

assign costfactor add switch bicycle=use_sidepath 2.0 0.0
<whatever expresing till next assign statement>

This would make any road with such a tag extra twice
as long as is its physical length.

Additionally, it is important
to keep low costfactors even for highway=path,
if is paved ( not so often ) and bicycle= friendly tag is present.

In my profile below, I how done so in more thoughful way.

highway=cycleway is probably even better.

See the map of Ceske budejovice on BRouter-web map ( standard profile )
http://bit.ly/2p8tHAq

And try to upload there, or use on the device this modified version
of my Trekking-Poutnik profile template.
It gives quite good default result.

https://raw.githubusercontent.com/poutnikl/Trekking-Poutnik/develop/Trekking-Poutnik.brf

WayTags
highway=secondary estimated_traffic_class=4
reversedirection=yes highway=residential
reversedirection=yes highway=service
highway=footway route_bicycle_lcn=yes
reversedirection=yes highway=tertiary
reversedirection=yes highway=tertiary
reversedirection=yes highway=tertiary
reversedirection=yes highway=tertiary
highway=residential oneway=no
highway=footway bicycle=yes
highway=path foot=designated bicycle=designated cycleway=crossing
highway=path foot=designated bicycle=designated cycleway=crossing
highway=footway bicycle=yes
highway=path surface=asphalt foot=designated bicycle=designated
smoothness=excellent
highway=path surface=asphalt foot=designated bicycle=designated
smoothness=excellent
reversedirection=yes highway=tertiary
reversedirection=yes highway=tertiary
reversedirection=yes highway=tertiary
reversedirection=yes highway=footway
reversedirection=yes highway=cycleway surface=asphalt foot=designated
bicycle=designated route_bicycle_lcn=yes
highway=residential surface=asphalt oneway=yes route_bicycle_lcn=yes
highway=residential oneway=yes
highway=residential
reversedirection=yes highway=residential route_bicycle_lcn=yes
reversedirection=yes highway=path foot=designated bicycle=designated
route_bicycle_lcn=yes
highway=path foot=designated bicycle=designated route_bicycle_lcn=yes
highway=path foot=designated bicycle=designated route_bicycle_lcn=yes
highway=footway route_bicycle_lcn=yes
highway=footway route_bicycle_lcn=yes
highway=tertiary oneway=yes estimated_traffic_class=3
reversedirection=yes highway=primary oneway=no estimated_traffic_class=4
reversedirection=yes highway=primary oneway=no estimated_traffic_class=4
reversedirection=yes highway=primary estimated_traffic_class=4

--
Poutnik ( The Pilgrim, Der Wanderer )

https://github.com/poutnikl/Brouter-profiles/wiki

[majkaz]

Thanks for the answer. Sorry, I completely missed the permalink when I posted.

The use of bike path is implicit, not signposted, given just by the existence of cycle track.

I tried it with the link you gave, and the trekking profile works (see the third alternative). 

I noticed another problem - the second alternative uses a non-existent tunnel. 

I'll try your profile later, I am usually using yours (perhaps old) profiles on the phone. Not sure if these were not hacked somehow, I'll save it as a clean one. 

Getting it there correct just now is not that important, I am just trying to debug the mapping. I'll try to see why the "original" profile gets so low cost factor, the route is not "that" cyclable. I think I have found few places where the mapping either isn't right or at least is not good enough.

Thanks again.

Majka

[Poutnik]

You are welcome.

Unfortunately, for now, Permalink can refer only to standard profiles,
so I use to define the map scenario and from, to, ( viaN ) points.
The custom profiles has to be subsequently always explicitly uploaded.

It seems you refer to the standard profile,
as the 2nd alternative with non existing tunnel
( highway=construction )
is suggested by the Standard Trekking, not my profile.

the 3rd alternative of the Trekking profile works,
as previous alternatives ruled out the main street,
and it did not have try the sidepath yet.

I have noticed the testing of highway=construction
somehow disappeared in the standard profile.
I bet it was there.
There is still open issue for that.
https://github.com/abrensch/brouter/issues/62

The original Trekking profile gives unconditionally costfactor 1.0
to any cycleroute, and therefore its original suggestion
follows the cycleroute cycleroute along "Na Sadech" street.

( You can switch on the cycleroute marking layer on the top right,
or switching map to Opencyclemap, with visible route marking.:.

The Trekking-Poutnik link I have provided
is a kind of a development "nightly build" of my profile template.

All my published profiles
are based on the older version of this template.

On 05/03/2017 06:04 PM, majkaz wrote:
>
> I tried it with the link you gave, and the trekking profile works (see
> the third alternative

> <http://brouter.de/brouter-web/#zoom=16&lat=48.9788&lon=14.49152&layer=OpenStreetMap&lonlats=14.50146,48.970893%7C14.474423,48.989694&nogos=&alternativeidx=3&format=geojson&profile=trekking>).
>
> *I noticed another problem - the second alternative uses a non-existent
> tunnel. *

>
> I'll try your profile later, I am usually using yours (perhaps old)
> profiles on the phone. Not sure if these were not hacked somehow, I'll
> save it as a clean one.
> Getting it there correct just now is not that important, I am just
> trying to debug the mapping. I'll try to see why the "original" profile
> gets so low cost factor, the route is not "that" cyclable. I think I
> have found few places where the mapping either isn't right or at least
> is not good enough.
>
> Thanks again.
> Majka
>

[Marie Zemanova]

Hello again.

I have just tried your profile in Locus. 

I have run the same setting without any via points with your profile several times, getting back the initial route and 3 alternatives. The initial route back is just fine, going along the signposted cycle route in the second half. This would be the best route *before* the new road was built, I have used it often in the past. There are few parts where I think better tagging for bike - surface, smoothness etc. - would get it even nearer to the reality (the signposted way is just this, signposted, without any real infrastructure). First alternative got mostly the signposted ways (reasonable but somewhat long), second alternative got back roads (again, perfectly reasonable and short) and third alternative got my "ideal" way - keeping the access where legal, short, and mostly bike paths or residential roads.

Just by setting single via point I got the "right" way at the first try, where I couldn't get the standard profiles to accept such an easy route.

I would say, for commuting this profile here just works. 

Thank you for your help.

[maarte...@gmail.com]

I have another problem with bicycle=use_sidepath with the online router at http://brouter.de/brouter-web/.
When I take the fastbike profile, there is a bikeaccess clause:
assign bikeaccess
or nodeaccessgranted=yes
switch bicycle=
switch vehicle=
defaultaccess
switch or vehicle=private vehicle=no
0
1
switch or bicycle=private or bicycle=no bicycle=dismount
0
1

When I add bicycle=use_sidepath, like this:
switch or bicycle=private or bicycle=no or bicycle=use_sidepath bicycle=dismount

I get an error on that line when uploading the profile: Profile error: ParseException at line 209: unknown lookup value: use_sidepath

To make sure it is not an error in the logic, when I change bicycle=no to bicycle=use_sidepath so it reads switch or bicycle=private or bicycle=use_sidepath bicycle=dismount, I get the same error.

The same goes with use_cycleway or opposite.

[maarte...@gmail.com]

Ah wait, I was doing this in the ---context:node section (line 209).
But still: is it correct that this does not work there?

[Poutnik]

The presence of nodeaccessgranted=yes gives me the hint
you have incorrectly placed it in node context section,
while it should be in way context section.

As this tag value is defined for the way bicycle= tag,
but not for the node bicycle= tag.

Another evidence is, that my uptodate nightly Trekking-poutnik template
with applied bicycle=use_sidepath does work.
https://raw.githubusercontent.com/poutnikl/Trekking-Poutnik/develop/Trekking-Poutnik.brf

BTW, it is not good Idea
to put bicycle=use_sidepath to way access restrictions,
this it is not a hard restriction, otherwise bicycle=no should be used.
Rather raise costfactor for a road with such a tag.

Dne 04/05/2017 v 08:36 maarte...@gmail.com napsal(a):

--
Poutnik ( The Wanderer )

My Brouter profiles
https://github.com/poutnikl/Brouter-profiles/wiki

[Poutnik]

As if marked as hard access restriction,
then in case the sidepath is not continuous,
or if it is mapped out of order,
the main road would not be routable.

Dne 04/05/2017 v 08:56 Poutnik napsal(a):

> BTW, it is not good Idea
> to put bicycle=use_sidepath to way access restrictions,
> this it is not a hard restriction, otherwise bicycle=no should be used.
> Rather raise costfactor for a road with such a tag.

[maarte...@gmail.com]

Op donderdag 4 mei 2017 08:56:49 UTC+2 schreef Poutnik:

> BTW, it is not good Idea
> to put bicycle=use_sidepath to way access restrictions,
> this it is not a hard restriction, otherwise bicycle=no should be used.
> Rather raise costfactor for a road with such a tag.

That is a matter of interpretation of tags and associated guidelines when to apply a tag.
Trafficrules may differ in other countries, but in the Netherlands and Germany, you are not allowed on a road which is adjacent to a signposted cycleway (round blue sign with a bicycle), even if that road does not have a specific sign saying bicycles are not allowed.
In practice, the effects are the same for both cases: no cyclists allowed on the main road.

[Poutnik Fornntp]

The effect is not the same.

Bicycle=no means unconditional restriction.

Bicycle=use_sidepath means conditional restriction if sidepath is available.

The difference may seem small, yet it is essential. There are various
physical and wrong mapping scenarios where it is not available.

> --
> You received this message because you are subscribed to the Google Groups
> "OSM Android bikerouting" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osm-android-biker...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[maarte...@gmail.com]

True, I was only looking at situations where it was mapped correctly. A way with bicycle=use_sidepath and no path next to it will result in incorrect routing if you disallow cycle routing completely.

[Poutnik Fornntp]

Even if mapped correctly and the sidepath exists and is mapped along.the
*whole* mainroad,
there can be obstacles or the path can be physically not accessible for
various reasons.

So regardless of suggested routing,you may be justified to make runtime
decision to use the mainroad.

[Poutnik]

The solution is to have such a costfactor policy
that sidepaths always taking precedence over mainroads penalized for
use_sidepath tagvalue.

If the sidepath does not exist, or the sidepath access for bicycles
happened to be forbidden,
it could fallback to the mainroad usage.

On 05/04/2017 11:00 AM, maarte...@gmail.com wrote:
> True, I was only looking at situations where it was mapped correctly. A way with bicycle=use_sidepath and no path next to it will result in incorrect routing if you disallow cycle routing completely.
>

[maarte...@gmail.com]

I'm a bit curious why putting bicycle=use_sidepath at certain points in the profile does not work.

When I take the standard fastbike profile from http://brouter.de/brouter/profiles2/fastbike.brf and change the accesspenalty in the way context to
assign accesspenalty
switch bikeaccess
0
switch footaccess
6
switch bicycle=use_sidepath
7
10000
nothing happens.
I've tried doing this with a boolean like bikeaccess and footaccess, like this:
assign nobike
bicycle=use_sidepath
and then
assign accesspenalty
switch bikeaccess
0
switch footaccess
6
switch nobike
7
10000
but that does not work also

When I add under "assign costfactor" the line add switch bicycle=use_sidepath 7 0 then it works.

[Poutnik Fornntp]

The reason is simple, as it is evaluated within accesspenalty definition
only if variable bikeaccess is false.

But bikeaccess is very probably true, unless access= or vehicle= are no or
private.