Most of the icons only rendered with access: but not with vehicle:

[gaben]

Lanes and Road Attributes mappaint style

I found that if you create access restrictions on ways, the icons rendered with access:forward, but not with vehicle:forward.

It's a problem because the restrictions usually come from traffic signs which apply only vehicles, making usage of access: wrong (in most cases).

Example:

bicycle:forward=yes|no
hgv:forward=yes|yes
highway=residential
lanes:backward=1
lanes:forward=2
lanes=3
taxi:forward=yes|no
vehicle:forward=no|no /* change this to access:forward to get icons */

Solution

Handle vehicle: similarly as access: when dealing with icons.

[skyper]

There are problems with the transport mode icons and the access definitions, e.g. below does show a warning and the rendering of both the access strips and the bus icon is not right.

access:lanes:forward=no|no
bus:lanes:forward=yes|designated
bus=yes
highway=residential
lanes:backward=1
lanes:forward=2
lanes=3
vehicle=no

• I am not sure about your example. Think you need to add :lanes to all transport mode access tags.
• The lanes-proposal did define access:lanes[:forward/backward] and than allow certain modes again, e.g. you could work around it. Additionally, it was proposed before vehicle got popular. Do I need to add [motor_]vehicle to the Lanes preset?
• Last but least [motor_]vehicle=* is not rendered by the internal style. So I would start there to introduce the rendering of vehicle=*

[skyper]

Replying to gaben:

It's a problem because the restrictions usually come from traffic signs which apply only vehicles, making usage of access: wrong (in most cases).

In my area there, is no difference between vehicle and access most of the time. foot needs to use the sidewalk and horse is treated like vehicle, so I would miss them.

Your example allows foot, horse and hgv on both forward lanes and bicyle and taxi on the left forward lane.

[gaben]

It should have a difference. Think a situation where access used but there aren't any sidewalk drawn on OSM. Usually you can't tweak the routing engine to ignore access restrictions so that way become unroutable with eg. foot routing.

In general I think the access tag is dangerous and should be used very cautiously.

---

Think you need to add :lanes to all transport mode access tags.

Hm, I don't get it. Why is it needed/useful?

Do I need to add [motor_]vehicle to the Lanes preset?

Yeah, I forgot that used your preset :D If you ask me, yes.

I would start there to introduce the rendering of vehicle=*

+1

[skyper]

Replying to gaben:

It should have a difference. Think a situation where access used but there aren't any sidewalk drawn on OSM. Usually you can't tweak the routing engine to ignore access restrictions so that way become unroutable with eg. foot routing.

Not sure if foot routing should use :lanes-tags at all on highways above path/footway/cycleway.

In general I think the access tag is dangerous and should be used very cautiously.

I get your concerns. In my opinion, access:lanes and transport_type:lanes are not 100% equivalent to the tags without :lanes and a access:lanes=no|no without any access=* would not exclude any transport mode from using the highway.

I see use ending up in the same discussion as if a dedicated combined foot and cycleway should have vehicle=no and horse=no

---

Think you need to add :lanes to all transport mode access tags.

Hm, I don't get it. Why is it needed/useful?

transport_mode with forward or backward allows only one value and is general tag for the direction. It is sufficient if only one lane per direction exists but as soon as there are more lanes, you need to use *:lanes:forward and *:lanes:backward

Also note that cycle lanes and sometimes other lanes do not count to lanes[:*] but do get there own value in all other *:lanes tags.

Do I need to add [motor_]vehicle to the Lanes preset?

Yeah, I forgot that used your preset :D If you ask me, yes.

I see, what I can do, foot and horse is also not present. My major concern is that it gets too large (long).

I would start there to introduce the rendering of vehicle=*

+1

see #20020