Improving the Wiki documentation of barrier=kerb and kerb=*

[osmuser63783]

The Wiki documentation for barrier=kerb and kerb=* is incomplete and contradictory. Following on from the previous discussion, I’d like to improve them to better document how the tags are used and how the community agrees that they should be used.

I didn’t want to make major changes without giving people a chance to comment, so here is a summary. This is not a proposal for how things should be mapped, nor am I endorsing how things are currently mapped. (Personally I think it’s confusing that kerb= has so many different meanings.) I’m just trying to improve the documentation so data consumers can make informed decisions and new users can read the page to understand how kerbs are typically tagged.

barrier=kerb
(1) On a way along the length of the kerb, to map the kerb itself.
(2) On a node that is part of a highway, to map the location where someone travelling along the highway has to cross a kerb. This includes situations where the highway crosses a barrier=kerb way, but very often the kerb is not mapped separately as a way. The current version of the Wiki page contradicts itself on this usage.

More information about the kerb can be added by adding the kerb=* key which serves as a rough indicator of the height of the kerb and how much of an obstacle it is. For mapping the exact height of the kerb, on ways height=* is commonly used, on nodes kerb:height=*.

There is agreement that barrier=kerb should only be used on a node that is part of a highway if anyone travelling along the highway has to cross the kerb: therefore it should typically not be used on a highway=crossing or by itself on a node that is part of a road. This would imply that it applies to cars travelling along the road, like some sort of traffic calming measure. Despite this, the use of barrier=kerb on a road is not uncommon and it would (as of March 2023) lead to unexpected results if a data consumer was to assume that all of these slow cars down or present a significant barrier to cyclists travelling along the road.

kerb=*

1. On a barrier=kerb way, at the actual location of the kerb, to indicate the type or approximate height of the kerb
2. On a barrier=kerb node, at the actual location of the kerb, to indicate the type or approximate height of the kerb
3. By itself, on a node that is part of a path, footway, service road or similar, at the actual location of the kerb, for example where the highway crosses a kerb (though the kerb itself is often not mapped separately as a way). When encountering such a case, it makes sense to add the missing “parent tag” barrier=kerb, for clarity (so it becomes an example of usage 2)
4. By itself, on a node on a road (e.g. highway=primary/secondary/…), to mean that there is a kerb on each side of the way at this point. This should not be taken to mean that someone travelling along the road has to cross the kerb, therefore adding barrier=kerb here would be wrong.
5. On something like a highway=crossing node or a highway=bus_stop node. In this use it is an additional tag providing more information, like tactile_paving=yes. It indicates that there is a kerb somewhere near this node that someone visiting the node might want to know about, but the kerb is not necessarily at the exact location of the node and this tagging therefore does not imply a barrier=kerb or wheelchair=no.

Of these 5 different meanings, only no. 3 and 5 are currently documented in the Wiki.

I’m not proposing changes to the documentation of the different values for kerb=*, that’s another story.

Please let me know what you think.

[Nadjita]

@osmuser63783

I’m not proposing changes to the documentation of the different values for kerb=*, that’s another story.

Please let me know what you think.

How exactly did you come to these 5 meanings? Is this what you observed when mapping, or what you could come up with as possible meanings?

1. I don’t map kerbs like this, but it makes sense to do it like this, yes
2. I think, this was part of the proposal for barrier=kerb, because the idea was to make kerb=* a refinement for barrier=kerb, but I could be mis-remembering things. So it actually is in the wiki, just in the one for barrier=kerb. Doesn’t hurt to add it to kerb=*
3. Definitely with you on that one. kerb=* without barrer=kerb is either historic, or half-tagged. These should get a barrier=kerb
4. I don’t think that’s correct to assume. Back when there was no barrier=kerb, people would just use kerb=lowered on any highway to mark the location of the kerb you had to cross. Usually only lowered kerbs, of course. If you wanted to say the sidewalk had lowered kerbs, I did sidewalk:both:kerb=lowered. Everything else seems odd. I wouldn’t add this to the wiki and I wouldn’t encourage mapping kerb=lowered to mean that the kerbs left and right of the road are lowered kerbs.
5. That’s the only meaning of kerb=* that I know of where it’s not required to be on the exact location of the kerb, but rather meant as an additional tag to a feature like “this crossing has lowered kerbs”. But it’s also in the wiki to use either the proper location on the crossing way or the vague tagging on the highway=crossing – not both.

I’m absolutely with you on making kerb (and also tactile paving) tagging more clear on the wiki. Being more clear and less ambiguous is good.

[dieterdreist (Martin Koppenhöfer)]

|
|

• | - |

barrier=kerb

(1) On a way along the length of the kerb, to map the kerb itself.
(2) On a node that is part of a highway, to map the location where someone travelling along the highway has to cross a kerb. This includes situations where the highway crosses a barrier=kerb way, but very often the kerb is not mapped separately as a way. The current version of the Wiki page contradicts itself on this usage.

I do not see the contradiction, barrier=node represents a kerb, you can draw it as a way, or mark the position punctually where it is most relevant (on a crossing footway typically).

More information about the kerb can be added by adding the kerb=* key which serves as a rough indicator of the height of the kerb and how much of an obstacle it is. For mapping the exact height of the kerb, on ways height=* is commonly used, on nodes kerb:height=*.

There is agreement that barrier=kerb should only be used on a node that is part of a highway if anyone travelling along the highway has to cross the kerb: therefore it should typically not be used on a highway=crossing or by itself on a node that is part of a road. This would imply that it applies to cars travelling along the road, like some sort of traffic calming measure.

+1

Despite this, the use of barrier=kerb on a road is not uncommon and it would (as of March 2023) lead to unexpected results if a data consumer was to assume that all of these slow cars down or present a significant barrier to cyclists travelling along the road.

Actually barrier=kerb on a highway is very uncommon, there are 0,2% occurences of this: https://taginfo.openstreetmap.org/tags/barrier=kerb?filter=ways#combinations
barrier=kerb on a node that is part of a highway is expected, but that it is a road highway is not, although it might occur in rare cases for driveways or similar. Did you count these situations and how many were there? Is it concentrated in specific regions?

Just because the data is not completely reliable we should not change the definition of the tag. A barrier=* should always be some sort of barrier (or hole in a barrier, as in barrier=entrance), it doesn’t make sense to add barrier=* to something to indicate a barrier somewhere else. These are just tagging noise / mistakes we should correct.

kerb=*

1. On a barrier=kerb way, at the actual location of the kerb, to indicate the type or approximate height of the kerb
2. On a barrier=kerb node, at the actual location of the kerb, to indicate the type or approximate height of the kerb
3. By itself, on a node that is part of a path, footway, service road or similar, at the actual location of the kerb, for example where the highway crosses a kerb (though the kerb itself is often not mapped separately as a way). When encountering such a case, it makes sense to add the missing “parent tag” barrier=kerb, for clarity (so it becomes an example of usage 2)
4. By itself, on a node on a road (e.g. highway=primary/secondary/…), to mean that there is a kerb on each side of the way at this point. This should not be taken to mean that someone travelling along the road has to cross the kerb, therefore adding barrier=kerb here would be wrong.
5. On something like a highway=crossing node or a highway=bus_stop node. In this use it is an additional tag providing more information, like tactile_paving=yes. It indicates that there is a kerb somewhere near this node that someone visiting the node might want to know about, but the kerb is not necessarily at the exact location of the node and this tagging therefore does not imply a barrier=kerb or wheelchair=no.

Of these 5 different meanings, only no. 3 and 5 are currently documented in the Wiki.

I’m not proposing changes to the documentation of the different values for kerb=*, that’s another story.

to make it short:

barrier=kerb → a kerb feature
kerb=* → a property that describes a kerb or the absence of a kerb

so +1

if the kerb is already mapped as in 2, would you still think that it is recommendable to add or remove kerb=* to/from a nearby crossing node?
if the kerb is already mapped as in 1,should we recommend to add or remove barrier=kerb on/from the nodes where a highway crosses a kerb?

Cheers,
Martin

[osmuser63783]

@dieterdreist

I do not see the contradiction, barrier=node represents a kerb, you can draw it as a way, or mark the position punctually where it is most relevant (on a crossing footway typically).

The contradiction isn’t about whether barrier=kerb should be used for a node or a way. The contradiction is about whether to use kerb=* or barrier=kerb when mapping the location where a highway crosses the kerb (the wiki first directs people to use kerb=* and two sentences later says that barrier=kerb should be used) When in reality it’s perfectly fine (and probably better) to use both.

@dieterdreist

barrier=kerb on a node that is part of a highway is expected, but that it is a road highway is not, although it might occur in rare cases for driveways or similar. Did you count these situations and how many were there? Is it concentrated in specific regions?

There are 3160 of them, on every continent. This Overpass query finds them. I think there is broad agreement that these are tagging mistakes. But if you think there aren’t enough of them to warn data users about, I can just leave the whole paragraph with the warning out. I wasn’t trying to redefine a tag or say that it’s OK to add barrier=* to something to indicate a barrier somewhere else - quite the opposite, I was trying to reinforce that there is broad agreement that this tagging is a mistake.

@dieterdreist

if the kerb is already mapped as in 2, would you still think that it is recommendable to add or remove kerb=* to/from a nearby crossing node?
if the kerb is already mapped as in 1,should we recommend to add or remove barrier=kerb on/from the nodes where a highway crosses a kerb?

I’m not sure. I was trying to keep my opinion out of this, and just document what’s there. But since you asked: for the first question, I think kerbs are interesting only for people who have to cross them, so the kerb=* can be safely removed when there actual locations have been mapped with barrier=kerb. (Otherwise a router might think there are four kerbs to cross) For the second question, even if there’s a barrier=kerb way I think it makes sense to have barrier=kerb on the intersection between that way and the highway, this is analogous to how it’s done for barrier=gate according to the Wiki page of that tag. (It says: “This helps routers as many will just ignore the gate if there is no node”)

[osmuser63783]

Thanks for your comments.

@Nadjita

How exactly did you come to these 5 meanings? Is this what you observed when mapping, or what you could come up with as possible meanings?

Sorry I should have been clearer. I came across all of them in Overpass when I was trying to understand how to map kerbs.

@Nadjita

I don’t think that’s correct to assume. Back when there was no barrier=kerb, people would just use kerb=lowered on any highway to mark the location of the kerb you had to cross. Usually only lowered kerbs, of course. If you wanted to say the sidewalk had lowered kerbs, I did sidewalk:both:kerb=lowered. Everything else seems odd. I wouldn’t add this to the wiki and I wouldn’t encourage mapping kerb=lowered to mean that the kerbs left and right of the road are lowered kerbs.

There are 12,614 examples of kerb=* without barrier=kerb that are on roads: Overpass query I don’t think people meant to say that there is a barrier=kerb on the road that cars have to drive over (I’m not counting service roads here, for driveways this may be common in some places). I’m not trying to encourage anything, just documenting. Could add a warning that this usage is controversial? Have a look also at my previous thread on the topic.

[Nadjita]

@dieterdreist

barrier=kerb on a node that is part of a highway is expected, but that it is a road highway is not

I’m always mapping them when mapping driveways that run over sidewalks. How is this not expected? They have a legal implication over here: you forfeit your priority-to-the right, when passing over one. Cities sometimes even put them in tempo 30 zones instead of give-way signs, because give-way signs are not normally allowed in these zones and just putting a lowered kerb on the street doesn’t require a special permission.

So yes, I’ve probably already mapped hundreds of barrier=kerb+kerb=lowered on regular roads, and they are perfectly fine.

[Nadjita]

@osmuser63783

There are 12,614 examples of kerb=* without barrier=kerb that are on roads: Overpass query I don’t think people meant to say that there is a barrier=kerb on the road that cars have to drive over

Indeed. Could they be from SC maybe? I think when a footway/path crosses a street, and you claim it’s not a highway=crossing, you are, or were, still asked whether there is a lowered/raised kerb. I might be wrong, but I think I read that this was common practice in some areas, where they don’t want to add highway=crossing+crossing=unmarked. We could probably eliminate those with kerb=raised that are on a crossing, or just discourage this usage, because it just doesn’t make any sense to interpret it differently on a per-highway-basis

[osmuser63783]

@Nadjita

I’m always mapping them when mapping driveways that run over sidewalks.
…
So yes, I’ve probably already mapped hundreds of barrier=kerb+kerb=lowered on regular roads, and they are perfectly fine.

I think we all agree that driveways can cross the kerb. There’s just some confusion about terminology. To me “regular roads” excludes highway=service. Specifically, I counted barrier=kerb on highway=(motorway|trunk|primary|secondary|tertiary|unclassified|residential|motorway_link|trunk_link|primary_link|secondary_link|tertiary_link). These are likely mistakes in my view. Do you agree?

-Edit: if not, could you give an example please? Just trying to understand what you were saying about the tempo 30 zones with lowered kerbs on the street

[Nadjita]

@osmuser63783

could you give an example please? Just trying to understand what you were saying about the tempo 30 zones with lowered kerbs on the street

In Germany, a city may not put give-way signs in a tempo 30 area, unless they are given permission. Every time they want to do this, the city will need an exception and request one. Takes time, costs money.
So some cities just put lowered kerbs directly onto residential roads, because then, the vehicles going over the lowered kerb, automatically have to give way. No sign needed

Mapillary view, coming from the east:

Bing view with data of the same crossing

As you can see, this is effectively the same as giving the cars coming from the right side a give-way sign. In the Mapillary picture, there still is one (cut off, but nevertheless), but it has since been removed, because it was disputed and instead, they built the lowered kerb. Clearer now? These constructs are quite common here in low speed zones, because they also reduce the amount of signs needed which is a welcomed benefit.

So you can find them on residential streets, maybe also unclassified. Certainly not higher ones, but who knows…

[osmuser63783]

I see, thanks!

My main takeaway from this is that kerb=* by itself on a node on a highway is just confusing. It can either mean that there’s a kerb on each side of the highway (which is what StreetComplete creates) or that someone travelling along the highway has to go over the kerb (historic usage from before barrier=kerb existed). Therefore, the Wiki page could say something like standalone usage of kerb=x is discouraged (with a reference to this discussion). Such nodes should ideally be resurveyed and either get highway=crossing or crossing=no or barrier=kerb. OK?

And barrier=kerb on a road is not necessarily wrong - people should just be careful before using it that there really is a kerb to cross.

[dieterdreist (Martin Koppenhöfer)]

|
|

• | - |

dieterdreist:

barrier=kerb on a node that is part of a highway is expected, but that it is a road highway is not, although it might occur in rare cases for driveways or similar. Did you count these situations and how many were there? Is it concentrated in specific regions?

There are 3160 of them, on every continent. This Overpass query finds them. I think there is broad agreement that these are tagging mistakes. But if you think there aren’t enough of them to warn data users about, I can just leave the whole paragraph with the warning out.

I don’t know what datauser should do, if they don’t add an exception it would be more likely that the tagging would get fixed because of e.g. routing results making people wonder and look into.
There are 888k barrier=kerb so 3000 is just 0,3%. One can mention it, but I wouldn’t put too much emphasize as it is probably just a minor issue.

I’m not sure. I was trying to keep my opinion out of this, and just document what’s there. But since you asked: for the first question, I think kerbs are interesting only for people who have to cross them, so the kerb=* can be safely removed when there actual locations have been mapped with barrier=kerb. (Otherwise a router might think there are four kerbs to cross) F

I agree, for the same reasons

Cheers,

Martin

[Nadjita]

@osmuser63783

Therefore, the Wiki page could say something like standalone usage of kerb=x is discouraged (with a reference to this discussion). Such nodes should ideally be resurveyed and either get highway=crossing or crossing=no or barrier=kerb. OK?

Discouraging the standalone usage of kerb=* on anything but highway=crossing is definitely going to be an improvement.
But: the reasons SC doesn’t add a highway=crossing for some are plenty fold. We should maybe think about how to model what SC wants to express, and in my opinion, sidewalk:<side>:kerb=* is what we are looking for. Just needs support from this Software as well and maybe some feedback from @westnordost. I know that there was a discussion on GitHub, where the solution was to use kerb=* without crossing=unmarked, because it’s not a real “crossing”, but crossing=no is also wrong, because you are not forbidden to cross either. But leaving kerb=* on a highway and kerb=* historically not needing barrier=kerb makes this kind of meh…

[Mateusz_Konieczny]

Can you list things of proposed wiki changes? I am not sure what in the initial post is part of proposed changes and what wiki describes already.

[osmuser63783]

Most of it is new really. Taking into account the above feedback, the main changes are as follows

• barrier=kerb and kerb= on nodes or ways can be used together, it’s not one or the other; kerb as a subkey of barrier=kerb
• kerb= when used by itself at the actual location of the kerb should also get barrier=kerb, for clarity
• clarification on how to tag exact height
• if you see barrier=kerb on a road where there isn’t actually a kerb that cars have to go over, that’s a mistake and should be corrected
• usage of kerb=* (or only kerb=raised?) to mean that there is a kerb on each side of the way at this point; especially (or only?) in places where one might expect a crossing, because a footway meets a road: this usage is discouraged because of the ambiguity; do not add barrier=kerb here

If no one objects I’ll add Martin’s suggestions too

• for crossings, either map the kerb separately (barrier=kerb plus optionally kerb=) or put kerb= on the crossing node; but not both
• for separately mapped barrier ways, it is still advisable to put barrier=kerb on the intersection with the highway

[westnordost]

Are you documenting how the tag is used or how it should be used?

Streetcomplete sets kerb=raised (without barrier=kerb) on intersections of roads with paths where there is no dedicated crossing, i.e. not even a lowered kerb.
If remember correctly, I initially wanted to use crossing=no but after a looong forum discussion, this came out of it.

[osmuser63783]

I can see why, though I agree with Nadjita’s suggestion that sidewalk:both:kerb=raised would be less ambiguous in that situation.

I’m trying to document how it is used, and only add language like ‘should’ or ‘discouraged’ where there is broad agreement.

[JeroenHoek]

Historically, the key kerb was used by itself on a node at the exact location where a highway crosses the kerb. When encountering this usage, it is advisable to add barrier=kerb to avoid confusion with other uses of the key kerb (see below).

This one seems to go beyond documentation a bit, and moves on to deprecate a not uncommon use of kerb=*. Clearing this up sounds good, but deprecating current use might need a proposal to give everyone a chance to participate.

[osmuser63783]

And to everyone else, I’ve now updated both Wiki pages, comments are welcome.
https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dkerb
https://wiki.openstreetmap.org/wiki/Key:kerb

[osmuser63783]

Thanks! Yes I wasn’t sure about the best way to phrase it. Would you be happy with something like the following?

The key kerb is also sometimes used by itself on a node at the exact location where a highway crosses the kerb. When encountering this usage, it is advisable to add barrier=kerb to avoid confusion with other uses of the key kerb (see below).

[JeroenHoek]

@osmuser63783

Thanks! Yes I wasn’t sure about the best way to phrase it. Would you be happy with something like the following?

The question I raised on the talk page a year ago is exactly about that. Should barrier=kerb be used on those nodes, or is that tag better left exclusively for ways? This is unclear at the moment, with mappers having differing preferences. Clearing that up would be good (you provide a sensible rationale), but I would put it forth as a small proposal on the wiki, as this impacts barrier=kerb as well as kerb=* and a lot of nodes.

If that proposal passes it is that much easier to go ahead and fix documentation (which can then be proscriptive), presets, Map Paint Styles, and diagnostic tools pointing out potential errors.