Mapping the position of the cycleway and footway relative to each other

[Jofban]

The problem

I’d like to use bicycle:forward and bicycle:backward, but they only apply to their respective directions, and so we lose the geometric information of where they are.
On normal streets, that’s not an issue because the convention is that all lanes in one direction are grouped together. This is obviously not the case with segregated pathways.

New tagging idea (direction:lanes)

@Minh_Nguyen

It would also be highly problematic if access keys behave differently on segregated paths than on unsegregated paths or two-way streets, because routers would have to special-case so much behavior.

Actually, thinking about it, there isn’t much difference between them.
We have a street. On that street is some number of lanes. Each lane has its allowed traffic and primary direction.
Right now, we don’t have a tagging to explicitly mark the primary direction. There are conventions (see above), but they apparently break down in more complicated situations. As such, if we were to introduce new tagging, it might be most fruitful to add such tagging. E.g.

direction:lanes=backward|forward|

This would also apply to e.g. turn:lanes:

direction:lanes=backward|backward|forward|forward
turn:lanes=right|left|left|right

Though I would still recommend using turn:lanes:* for clarity:

direction:lanes=backward|backward|forward|forward
turn:lanes:forward=left|right
turn:lanes:backward=left|right

If an entry is omitted, it would default to bidirectional. If direction:lanes is omitted, it defaults to the current convention of grouping all :forward and all :backward lanes of each mode together (subject to driving_side and oneway). If no :forward or :backward are given, symmetrically divide the number of lanes between them.

Our example

direction:lanes=backward|forward|
bicycle:lanes:forward=designated|no
bicycle:lanes:backward=no|designated
foot:lanes:forward=no|designated
foot:lanes:backward=designated|no

or, using above default conventions,

bicycle:lanes=designated|designated|no
foot:lanes=no|no|designated

Just what we had.

Outlook

How would placement and overtaking interact with this key?

[Minh_Nguyen (Minh Nguyễn)]

My concern with this direction:lanes=* approach would be backwards compatibility, since data consumers already deal with the combination of oneway=no and *:lanes=*, either by ignoring the latter or applying it to both sides individually.

Taking a step back, what if we take advantage of the alternative :left/:right scheme?

lanes=2
segregated=yes
bicycle:left=designated
foot:right=designated

This can coexist with any existing :forward and :backward tagging for other purposes. Existing data consumers don’t need to worry about this tagging scheme, except to the extent that they begin to support any new left/right guidance.

This doesn’t address the case where the pedestrian lanes surround the bike lane, though that starts to look like a shoulder or sidewalk situation. There’s probably a whole ’nuther discussion to have about the choice of designation versus yes and whether a complementary set of access:*=no is required. But does this side-based tagging at least begin to address the problems you’re trying to solve?

[pavvv]

@Minh_Nguyen

Taking a step back, what if we take advantage of the alternative :left/:right scheme?

lanes=2
segregated=yes
bicycle:left=designated
foot:right=designated

How would this work in the case of footways surrounding the cycleway from both sides? This is quite a common occurrence in Poznan.

I’ve also thought about highway:lanes=cycleway|footway. But I think that runs into the same problems as bicycle:lanes=designated|no + foot:lanes=no|designated.

[Minh_Nguyen (Minh Nguyễn)]

How would an ordinary layperson describe this configuration? Do they consider it to be three different paths that happen to be conjoined without an appreciable barrier between them? Or two paths, each with a left and right? Or only one, divided into four lanes? Does the surfacing only remind people of where bikes can go, or does it also suggest that the walkways are subordinate to the bikeway, analogous to the road to the west that has a sidewalk?

Admittedly, :left/:right is a simplistic model that only scales to ways with two sides. (There’s also :both_ways, which essentially means “center”, but it’s terribly confusing in the context of a shared use path on which traffic flows in both directions throughout.)

Your example reminds me of some gnarly edge cases involving driveable roads. In Dayton, Ohio, Marl Road allows walking and cycling in either direction to the left of center, while apparently driving is allowed on both sides of the road in the usual manner (driving on the right).

Much more commonly, a fast food restaurant’s drive-through backs up into a parking lot, squeezed between the parking spaces and parking aisle. Despite the lack of physical separation, I usually see mappers draw a separate service=drive-through way, because the :lanes extension isn’t a natural fit for primary keys or the secondary keys that iteratively refine them.

Sometimes it isn’t even possible to describe the configuration in terms of lanes, as in this restaurant drive-through, also in Dayton:

Or this pharmacy drive-through outside Cincinnati, Ohio:

Tags can only represent geometry so well before they start to break down and we have to map separate ways, theory be darned. But the case of a segregated path is so common and usually so straightforward that it probably deserves a simple tagging scheme, even if it can’t handle more complex cases.

[pavvv]

@Minh_Nguyen

Tags can only represent geometry so well before they start to break down and we have to map separate ways, theory be darned.

I’m willing to go as far as to say that everything can be expressed via one way and sheer tags alone. It just might require obscure, never-used-before tags to be utilized.

[DwarfNebula]

@pavvv

How would this work in the case of footways surrounding the cycleway from both sides? This is quite a common occurrence in Poznan.

highway=cycleway + sidewalk:both=yes

Originally the topic was about the sign indicating a shared path between bike and foot where the bicycles should ride left and the pedestrians walk right. Your situation just look like a normal road with sidewalks, except the road is a bicycle path.

[Yog_Sot]

okey, so i was watching this topic and comments emerged like crazey, so i try to get directly to the point and keep it short and informative.

@pavvv is very much correct there that saying location of footway by cycleway is one of crucial features that is required for mapping one lined cycle|footway.
CyclOSM already does default rendering, but no mainstream mapping app or even main osm.org seems to care.

So what do we do so mainstream apps actually render and use what we try to specify?
Keep it simple.
tagging it as lanes is not simple at all.
specifying siidewalk to be right|left|both is all that’s required. Why sidewalk? Because footway is always built around cycleway even if we pretend em to be equal. I did not see an example where cycleway can be both value.

When tagging for the above is decided, one of the other big issues is tagging the crossing.
Logic behind it has to be solid.
Current logic only applies to crossings over a street and not over one another. Any tagging we try do is pure gueswork and mapping apps designers simply do whatever. This has to be unequivocal so we are leaving no doubt.
Otherwise it’s never be possible to remap two/three-lined bike|foot ways as one-lined without loosing information about crossings.

But going back to the keep it simple rule…
If it’s overcomplicate, it might be no good. And saying simple i mean simple for mapping apps, not just you, if you ever want your work to be used

Two lined mapping does not require this tagging, but it requires relating to one another, which we are not able to do.
That is why we have to specify it to see if the journey will lead us somewhere, because the problem is over 10 years old and none one of us is able to actually do one universal design that works for all cases.
But like i showed numerous times, we somehow agree to map sidewalks separately of even a living_street but many refuse to do when it’s a not a street for everyone, but bicycle designated. Many of you have to actually realise upps and downs of each approach to realise we fail to come up with universal good for all solution, that has to function not only as schematics for routing, but also rendering, including those who actually can’t see it, but can touch it to know before they walk out.

You gues have to realise you’re not mapping just for your own needs, but also for others and you gotta understand needs of other people instead of saying those doesn’t matter just for the sake of your logic.

[Minh_Nguyen (Minh Nguyễn)]

@Yog_Sot

specifying siidewalk to be right|left|both is all that’s required. Why sidewalk? Because footway is always built around cycleway even if we pretend em to be equal. I did not see an example where cycleway can be both value.

Yes, the example from Poznań looks a lot like a sidewalk, at least from the air. If there isn’t any sort of separation, just a change in surface, then it falls into a gray area where maybe we could tag it somehow as a pedestrian lane, for example, footway:both=lane, but if the geometry gets too complicated, separate ways may be a better tradeoff.

Ultimately, the physical separation rule exists to maximize our ability to describe the situation. Normally it works, but sometimes we make exceptions when the rule proves counterproductive. For example, we no longer insist on welding tram lines to roadways but instead map them as separate ways that refer to each other through tags.

As long as these exceptions are common enough and tagged explicitly enough, data consumers can be expected to account for them. What I don’t have a good sense for is whether the Poznań case rises to that prominence.

[Yunkers]

@Yog_Sot

But like i showed numerous times, we somehow agree to map sidewalks separately of even a living_street but many refuse to do when it’s a not a street for everyone, but bicycle designated.

Generally, we don’t agree to do that. I know that in Poland it looks like we map sidewalk separately as this is very common (it could be argued if that’s correct or not) but it’s not that common worldwide.
But I don’t think it’s relevant to this topic. Most of Polish sidewalks are raised that’s why they are mapped separately (again, it’s not clear if kerb is separation or not), but this discussion is mostly about bike lanes separated by line or surface which are usually not considered to be separation.

[Yog_Sot]

tbh, I defy that separation rule, coz many count a strip of sand or grass same as railing, while it’s just silly to two-line path when there is railing and merge into one-liner when its just a lowered kerb after 20 meters.
I rather map it all as one-liner with separation tags or all as multi-liner especially when it starts intersecting with other ways or there are tactiles

Specifying sidewalk to be right|left|both is better than thislane idea. Because actual lanes are possibly only for cycleway and footway next to it could as well i gues with.
Besides you gotta be able to set different surfaces or width for sidewalk:right and sidewalk:left
As to the objection for tagging segregated cycle|footway like this, well it really doesnt matter if the signs are square or round and if there are just bikes on em or also pedestrians.
Footway is a footway and cycleway is just it as well. Why make things so complex while it’s better to keep it simple?
In that example only the left footway is supposed to be part of cycle|footway, while the right one is just a footway, but really, what does it matter?

Lets decide that footway|cycle alignment tags, coz it’s really required so one-lined mapping can be this little bit more better finally

@Minh_Nguyen

For example, we no longer insist on welding tram lines to roadways but instead map them as separate ways that refer to each other through tags.

Could you link such a “refer to each other through tags” example so i can see how it could possibly work for two-lined bike infrastructure mapping? Because yeah, it is one of their shortcomings.

[Minh_Nguyen (Minh Nguyễn)]

@Yog_Sot

@Minh_Nguyen

For example, we no longer insist on welding tram lines to roadways but instead map them as separate ways that refer to each other through tags.

Could you link such a “refer to each other through tags” example so i can see how it could possibly work for two-lined bike infrastructure mapping? Because yeah, it is one of their shortcomings.

A tram line (or any set of railway tracks) is tagged embedded=yes along street-running segments. Conversely, the roadway is tagged embedded_rails=yes. By analogy, a roadway can be tagged sidewalk:right=separate and the sidewalk can be tagged footway=sidewalk (which implies that it runs alongside something). In principle, this should also apply if something else like a bike path has a sidewalk running alongside it.

To be clear, this is not an alternative to generally adhering to the physical separation principle. It’s merely a strategy to mitigate one of the dissociative effects of mapping separate ways. Another is that the name of the path to follow becomes more difficult for routers to access, a problem that is still open for debate.

[Jofban]

I looked around my city for examples and I found this particularly tricky case (on the right): Mapillary You can backup a little to see that it’s indeed marked with DE:241-30: Mapillary

Telling from the surface, it’s basically one big square that has an asphalted cycleway running on it. The square continues on both sides.
Maybe this shouldn’t be tagged like that at all, though all the rules still apply. I would almost go as far as mapping the cycleway separately and using bicycle=use_sidepath on the square…

@Minh_Nguyen

Taking a step back, what if we take advantage of the alternative :left/:right scheme?

lanes=2
segregated=yes
bicycle:left=designated
foot:right=designated

Why then not go all the way to

highway=path
segregated=yes
cycleway=left
footway=right

? (or sidewalk=right to be more consistent)
Then you could even do stuff like

cycleway:surface=asphalt

Not that any router I know of would evaluate such tag.
Though would likely need explicit cycleway:left:oneway=no for bidirectional paths.

And both are equally important. The “middle of the road” we’d usually have just happens to have a width of 0m.
At least for the simple cases.

[Nadjita]

@Jofban

Why then not go all the way to

highway=path
segregated=yes
cycleway=left
footway=right

Because footway=* and cycleway=* are already used for different things like footway=sidewalk.

[Jofban]

Quoting Key:cycleway - OpenStreetMap Wiki :

The cycleway=* tagging is used on linear features tagged with highway=* to map cycling infrastructure that is an inherent part of the road .

Highlighting is left original.
The article also provides an alternative (Key:cycleway - OpenStreetMap Wiki):

It is advisable to use cycleway tags in combination with side attributes , i.e. cycleway:left=*, cycleway:right=* or cycleway:both=* (instead of a simple cycleway=*).

I’d be fine with this. For footway, we could either do the same (though that would be undocumented as yet), or use sidewalk as a passable alternative. What do you think?

Example:

highway=path
segregated=yes
cycleway:left=lane
sidewalk:right=lane

[Minh_Nguyen (Minh Nguyễn)]

Yes, using a side suffix would be prudent, since cycleway=* and footway=* already have homonyms as it is. footway:right=lane and sidewalk:right=lane are two of the tagging schemes documented as a result of this massive thread about pedestrian lanes.

Personally, I favor footway:left/right/both=lane/sidewalk for saying which kind of walkway accompanies the roadway, by analogy with cycleway:left/right/both=*. If it happens to be an (implicit) footway:right=sidewalk, then sidewalk:right=separate is simply iterative refinement.

[Tolstoi21]

@Jofban

Quoting Key:cycleway - OpenStreetMap Wiki :

The cycleway=* tagging is used on linear features tagged with highway=* to map cycling infrastructure that is an inherent part of the road .

Highlighting is left original.

I suppose having cycleway:left|right=lane even on a highway=path is kosher, but:

Quoting Tag:cycleway=lane - OpenStreetMap Wiki :

A cycle lane is bicycle infrastructure that is an inherent part of the road, but set aside for the exclusive use of bicycles, whilst being separated only by paint or other markings, and without a physical separation from vehicles.

Highlighting added by me.

That last bit would, perhaps, imply that =lane tagging applies only to roads that accept vehicles (i.e., cars, etc). But maybe it is already used on highway=cycleways, etc also? And this is a genuine question! I have to say that I’d expect to have a cycleway=lane tag only on a highway that accepts cars, but maybe it is acceptable on a cycleway too?

[pavvv]

As we’ve already discussed, mapping the cycleway and footway using any kind of *:lanes:* is not ideal since it may imply one-directionality. I think using sidewalk=left/right/both should be fine enough already. My question is should this tag be used on top of highway=path or highway=cycleway?

[Minh_Nguyen (Minh Nguyễn)]

Another possibility would be to iteratively refine highway=path with path:left=cycleway and path:right=footway. It’s probably a little less awkward to iteratively refine a primary feature tag with sides than with lanes.

(I can almost see it now: someone will come along with an example of how we need a highway=road because of motorway characteristics on one side and surface street characteristics on the other. )

[Jofban]

Relatedly, there is a similar concept with trains: Richtungs- und Linienbetrieb – Wikipedia
Unfortunately, there seems to only exist the german article. To summarise, multitrack sections can either be grouped by direction or by type/mode. Applied to highways, almost any related tags assume directional grouping by default (notable exceptions are sidewalks).

What we’d need is a way to generically signify that the different parts of the way are actually grouped by mode. This is perhaps a slightly different interpretation of segregated: There are different parts of the way which are grouped by mode and as such shouldn’t be subject to the usual conventions around oneway-ness.

Honestly, the big question for me is then, how a segregated foot-/cycleway differes from a highway=residental with cycleway:right:oneway=no if said cycleway is just a lane separated by paint. Or we just accept that there is a different tagging.

@Tolstoi21

That last bit would, perhaps, imply that =lane tagging applies only to roads that accept vehicles (i.e., cars, etc). But maybe it is already used on highway=cycleways, etc also? And this is a genuine question! I have to say that I’d expect to have a cycleway=lane tag only on a highway that accepts cars, but maybe it is acceptable on a cycleway too?

The combination highway=cycleway and cycleway=lane occurs a few times. From a cursory look though, I think that they aren’t valid tagging. It also doesn’t make sense. If it isn’t separated, it shouldn’t be a separate line; If it is separated, it should be tagged with cycleway=track.
A cycle lane is often thought of as a protection of cyclists from other traffic; in the case of segregated foot-/cycleways, the cycle lane is for the protection of pedestrians (whilst allowing bicycles).

[Yog_Sot]

it could be used both for cycleway and path

• If the cycle|footway is designed so both are nice high quality with equal turns, then path and the actual line would be drawn in the geometric center of both
• but if only the cycleway is high quality, keeps going straight and the footway side keeps jumping from right to left and has variable substandard width/surface… then cycleway would be better with it drawn in the geometric center of the actual cycleway. This variant is rare to happen tho, but of course foot=designated still is required.

Anyway, that’s just a consideration and would likely be part of different proposal.