What meaning does “highway=path” convery to you? How would you react to this often-quoted diary entry?
If it was cycleway:<side>=lane, then not. But I agree that bicycle:lanes = yes|no seems the more elegant solution, because it’s gradually refining, so even routers that don’t look at :lanes can make use of the information. I have the feeling that a lot of people shy away from :lanes-tagging, though.
A path, to me, is basically a way for pedestrians and cyclists (and horse riders, but let’s ignore trhem) and both are equal users of the way. A footway or cycleway, to me, conveys a ranking of one above the other, which in the majority of cases isn’t given on segregated ways.
But the question was whether and how to tag the side where cyclists are supposed to ride on segregated ways. Not which highway=*-value to use.
for me
- footway bicycle=designated foot=designated
- path bicycle=designated foot=designated
- cylceway bicycle=designated foot=designated
is all the same because the designated says that it is the intended type of traffic.
The German community mostly uses path in this case because it is in fact a multi-purpose path. ID prefers cycleway (maybe because cycling ist the faster travel mode). But yes this is controversial since the introduction of path and I do not want to discuss it here.
3 Likes
Back to the topic, what are the options to tag the side of the cycleway on a segregated path?
- define left side as default (on ride hand traffic) for cycleway on a segregated path
- use cycleway:left/right=lane
- use highway:lanes=cycleway|footway
- use bicycle:lanes=yes|no (+ foot:lanes=no|yes)
- bicycle:left=designated + foot:right=designated
- <key?> = bicycle|foot
… ?
At the end, consistent data we will only get, when it is documented and supported by renderers and editors.
I have thought about this issue for quite some time but have not found an answer, yet. The common :lanes tagging does not work as reverting the way’s directions is currently not supported by any editor software and I am not sure if it is even possible to implement it as we end up with different rules depending on the highway value.
For simple cases my solution would be access tags like foot:right=designated and bicycle:left=designated but complex situations with more than two lanes are a problem. How can I tag a way with bicycle lanes per direction and a foot lane in between or at both sides? Here I used :lanes tagging with :backward and :forward for two cycle lanes (one for each direction) and a foot lane on one side but I am not 100% satisfied.
1 Like
Something like this might work if I understand the situation correctly
foot:lanes=no|designated|no
bicycle:lanes=designates|no|designated
oneway:lanes=-1|no|yes
There was once a discussion about automatically changing lane values when reversing the way, but the conclusion was that doing so would be incorrect:
I didn’t understand why you can’t automatically reverse the lanes and why it makes a difference between a road and a path. Could someone please explain with an example?
To be clear, that iD discussion was about whether to automatically reverse the direction of each lane in turn:lanes, so that reversing a one-way street would turn turn:lanes=left|through;right into turn:lanes=right;through|left or maybe turn:lanes=right|through;left. This would’ve been unexpected in the vast majority of cases, with the exception of hook turns in Melbourne. But on a two-way street, turn:lanes:forward=left|through|right already becomes turn:lanes:backward=left|through|right, as it should.
It’s important to note that a two-way’s way direction is just an implementation detail internal to OSM, not something that has any relationship to the real world. So a mapper can feel free to reverse a two-way’s direction for any reason or no reason at all. iD’s existing forward/backward replacement ensures that the user doesn’t break routing when reversing the way.
If the segregated path discussed here is a two-way, then *:lanes would be incorrect. *:lanes subkeys are interpreted with respect to a particular direction, hence bicycle:lanes:forward=* and bicycle:lanes:backward=*. On a two-way, a key that isn’t qualified by a direction, such as maxspeed=*, applies to both directions equally. So bicycle:lanes=yes|no means there are two lanes in either direction. By contrast, the *:left and *:right subkeys apply to the whole path with respect to the way’s direction.
1 Like
Looks good for a first glance but does not work with other keys like width, surface or smoothness, e.g.
width:lanes=2|3|3
I don’t see why not. The issue is, though, as @Minh_Nguyen pointed out, this only really works properly with oneway paths, otherwise we’d need to use :forward, and :backward, or well … :both_ways. So even though there is a way to make it work with :lanes, it would not be a simple solution, so I don’t think it’s worth chasing that thought further.
Oh, all these short quotes ripped out of context
Yes, problem is what to do when changing the way’s direction. In case of a middle lane for pedestrians :forward, :backward and :both_ways might work but not for the case of two bicycle lanes, one per each directions, and on both sides a pedestrian lane. As oneway does not count for foot, foot:forward and foot:backward should be used, which contradict with following tagging:
bicycle:lanes:forward=designated|no
foot:lanes:forward=no|designated
bicycle:lanes:backward=designated|no
foot:lanes:backward=no|designated
By the way, this is (one of) the major problem with my example in #21.
Is there really a need to tag the oneway:lane? I guess the number of cases where this differs from the right or left hand rule of that country is not significant! if it is the case, you can exceptionally draw separate lines.
So we have still the problem with foot in the middle.
I understand that inversing lanes it is not implemented yet. I still don’t see the general problem why lanes (without forward and backward) on non-oneways can’t be automatically reversed.
with normal tags you have to reverse the order bicycle|bicycle|foot → foot|bicycle|bicycle
with oneway you have to reverse and negate -1|-1|0|1 → -1|0|1 |1
The problem is that on a non-oneway street, the :lanes-suffix counts for :forward and :backward, which is unlikely what you want to have. It’s quite counterintuitive.
The problem seems to be, that the :forward :backward scheme (which is in most cases more intuitive) does not work with two-way lanes. I think it is not the problem of lanes, it’s the problem of not allowing to use lanes without a oneway road.
Earlier, Poland was cited as an example of a country where this assumption doesn’t hold. From my own vantage point in the U.S., segregated paths are common enough to have standard signs (below in English and Spanish), but the standard doesn’t require the bike lane to be on the left and the pedestrian lane to be on the right; it specifically allows the symbols to be swapped.
segregated=yes might also be appropriate for multi-use paths where pedestrians must keep off the path, sticking to the soft shoulder, if there are any cyclists nearby. It could be awkward for this key to imply a certain layout if we don’t have a very clear way to override that layout.
It would be easier to use footway:side=left/right/both and cycleway:side=left/right/both instead of bothering with the :lanes syntax.
I think we are talking at cross purposes.
If we assume for example right-hand traffic (you usually drive on the right) and there is (as I know it from Europe) a typical order of lanes (fast in the middle of the road, slow towards the outside).
Foot|Bicycle|Motor vehicle|Motor vehicle|Bicycle|Foot
From the point of view of the respective direction of travel thus
cars on the left, then cyclists on the right pedestrians.
normal direction (slower traffic on right)
reverse direction (slower traffic on left)
In some (sometimes fewer sometimes more) cases it is permitted to ride against the normal (as defined above) direction of travel, i.e. on the left-hand cycle path against the normal direction of travel. For the driver, of course, the order is the other way round. For our OSM line, it is only a question of how it is digitised. We could assume that a roadside separated cycle track and footpath should always be digitized in the normal direction of travel, then the cycle track would normally be on the left and the footpath on the right. Only for a few exceptions would you need additional attributes or draw the line the other way round.
What I actually (my last post) meant was that even if a cycle path on one side of the road can be used in both directions, the left/right rule of the country must typical be adhered to in each case, i.e. in our example I continue to cycle in the direction of travel on the right of my path and cyclists come towards me on the left.
This approach seems elegant to some extent, but I don’t think it can be enforced. I can’t think of any other feature type in which the way’s direction has an implicit significance only if oneway=no and some other key is yes. For that to become an implicit requirement now, after so many segregated paths have been mapped, and so many years after editors, renderers, and routers have added support for footways and cycleways, there would need to be significant coordination within the OSM ecosystem.