What to tag when there is a different kerb on each side of a crossing?

The situation is of a crossing mapped only as a node, with no paths or footways connected to it (common e.g. in cities without sidewalks mapped separately).

kerb=* can be added to the crossing to denote the kerb height on both sides of the crossing (much like tactile_paving)

However, what should be tagged if the kerb height is different on each side? e.g. unmarked crossing with lowered kerb on one side and raised on the other.

Obvious answer would be kerb:left and kerb:right

But what if crossing is at intersection of two ways in opposite directions (e.g. sidewalk situation changes at that point so road needs to be split):
--->x<---
(x is the crossing)

Asking in view of a StreetComplete quest to ask about kerbs on crossings.

I’m not sure how common this situation is though, so maybe it’s enough of an edge case that it won’t matter?

2 Likes

Maybe just tag the highest of the two kerbs, as that is what matters most?

For wheelchar-users, that would be important, for the blind, it’s the other way around.
We had a discussion about this some weeks ago and the TL;DR is: no real way of doing this unless you map the crossing as a separate way, sorry. I’d leave a comment/fixme for now, until there’s a proper way of doing this.

3 Likes

Agree for StreetComplete quest, leave a note (with a picture).

There is proper way of doing it, as you note - it is to micromap it. e.g. see that Two crossings with lowered kerbs picture from Key:kerb - OpenStreetMap Wiki

But that cannot be done from StreetComplete, but in some more general editor.

1 Like

That is indeed the obvious answer, it even used to be documented on the wiki until JeroenHoek deleted it last year. I’ve restored it; these tags have a few thousand uses and I don’t see a consensus to stop using them.

In this rare situation, you reverse one of the ways so that the direction is unambiguous.

1 Like

Not a consensus, but there were 2 major arguments in addition to the way-splitting one:

  1. left and right are not unambitious, because this is what it would look like from a car perspective. Kerbs on crossings are of close to zero interest to people on the carriageway, so why map them from their perspective?
  2. How do you know which way these kerbs apply to on a crossing of two ways? The way that routers work that route pedestrians / cyclists, they will never see the crossing highway as a way and from that perspective, left and right is either completely wrong, or they would have to download all crossing highways to figure out what left and right means.
       │
       ↓
------→X→------
       ↓
       │

So you’re saying that a node that’s member of 2 ways has a left and right? Where’s X’s left? Left of the X in my drawing, or on top of the X? You can only know this if you know the crossing ways’ attributes and one of them is a road and one is a way. And even then it’s guessing, because you have to assume that the way crosses the road, when in fact, it could be the road crossing the way. We’ve seen it all :wink:

Some things cannot be mapped 100% without separately mapped footways, and this is one of those attributes, where edge cases cannot be mapped reliably.

1 Like

The tags for mapping kerbs on crossing nodes were primarily designed for a scenario in which there is no footway=crossing way and no separately mapped sidewalks, so the situation looks either like this
----------X--------->
or like this:
--------->X--------->

Of course, there can still be situations in which there are footways/paths/… connecting to the crossing node. These they can be ignored for the purpose of determining out what left or right mean on that node. We’re looking at the way(s) being crossed, i.e. those with a highway=residential/tertiary/secondary/... tag.

Sure. That is not an actual problem because you do know the crossing ways’ attributes. (And putting highway=crossing on the intersection of a power line and a fence is simply a mapping error.)

We define left and right from the perspective of the way being crossed because it’s the only way which is always mapped.

It’s also the same meaning of “left” and “right” you would use when adding a tag such as sidewalk=left to the road with the crossing node, so for someone mapping sidewalks as tags, it’s perfectly intuitive.

2 Likes

It’s also the same meaning of “left” and “right” you would use when adding a tag such as sidewalk=left to the road with the crossing node, so for someone mapping sidewalks as tags, it’s perfectly intuitive.

left and right relating to a way are perfectly fine defined, but on a node they are not reliably working, because unlike ways, nodes don’t have a direction.

3 Likes

I was attempting to clarify why some people consider this tagging as invalid. If you don’t have a separate way for a crossing road, then it’s possible to use the kerb:left / kerb:right tags. However, it’s important to be aware of the issues, as mentioned by @dieterdreist, regarding the direction of a node. Even using direction=forward/backward can be problematic. Additionally, even if there is no crossing way, routers would still need to check if there is none in order to determine if :left /:right can be derived or not. Having a node tag that requires you to examine the ways containing the node to understand the meaning of the tag is definitely problematic.

Since the original question was about StreetComplete, my answer stands: note with a picture