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

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…


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.


  • | - |


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



1 Like

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…

1 Like

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.

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

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.

1 Like

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.

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.

And to everyone else, I’ve now updated both Wiki pages, comments are welcome.

1 Like

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).

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.

Hmm I see… barrier=kerb is already used more often on nodes than on ways (almost 600,000 times!). And the original proposal said it applies to nodes and ways. So I would have thought the use on nodes was already approved 12 years ago… just never documented on the Wiki

I don’t have the energy at the moment for a proposal to deprecate standalone kerb=*. I’ve probably already spent more time on kerb tagging than I should have :smiley: so I’m happy as long as the Wiki accurately documents current usage. But I’d help if someone wanted to propose that, of course

Why should this be deprecated?
barrier=kerb on crossing nodes footway/highway is simply wrong and may disturb routers.

I agree, it’s wrong to add barrier=kerb indiscriminately. I suppose the rationale for deprecation would be that standalone kerb=* is ambiguous. If, and only if, there’s a kerb on the way, it is clearer to add barrier=kerb, but if there isn’t, and there’s a just a kerb on each side of the road, and then some new tag like sidewalk:both:kerb=* would be better, to prevent people from wrongly adding barrier=kerb.

Anyway, I have no plans to deprecate anything and I’ve finished my edits to the wiki page unless there are further comments or complaints.

1 Like

I love what you’ve done to the Wiki page. It captures the current situation and the resulting problems very well. Thanks for your effort!


I feel sidewalk::kerb= is a good way to describe the regular kerb used by a section of sidewalk i.e. =raised for standard concrete sidewalk, =rolled for vehicle parking.

For crossings I just use the kerb=* indicate the kerb type at the crossing, especially when it is different from the sidewalk value. In particular I usually tag on the node shared by the sidewalk and crossing ways. I then try to place the transitional node as close to the actual kerb as possible. This is the most effective way layout where the sidewalk becomes a crossing and vise versa.

I will usually place the node on top of a tactile_paving as it reduces the number of nodes and supports those with accessibility by matching sensory aids with the crossing.

I just read this thread and looked at the wiki changes (sorry, I am a little late, I know). It’s really a valuable improvement that I really appreciate! :partying_face: And I can understand that you don’t want to start a proposal regarding the use of the kerb tag. Perhaps someone else has some energy to do that.

For a long time (in Germany) I am tagging crossings and kerb nodes on crossing footways and barrier=kerb ways exactly in the way as you describe it in the wiki now.

I also agree with all the changes, only one detail I would not have worded that way, it concerns the case of kerb=* on a highway=crossing node, if there are also nodes with barrier=kerb + kerb=* at the exact places of the kerb (mostly on a footway=crossing): I would not remove kerb=* on the crossing node, and I wouldn’t be afraid that a router might suspect 4 kerbs here – I think it would then be a fault of the router, because kerb=* on a highway=crossing node only means that there are kerbs to the left and right of it – which in this case are given exactly at their real position, so all the better for the router.

In summary: why should kerb=* hurt on the highway=crossing node? It might be a bit superfluous/redundant because more precise tagging has taken place, but it’s also just a descriptive property of the crossing.

And I still have 3 ideas for wording that could perhaps be added to the wiki texts as a supplement:

  1. With highway=crossing nodes it can happen that different kerb types appear on the left and right of the transition. In that case, it may be necessary to use kerb:right=* and kerb:left=* instead of one kerb=* tag. E.g. kerb:left=flush + kerb:right=lowered. Not sure if this is mentioned anywhere (I’ve been using it for a while).

  2. A good reminder, in my opinion, could be that barrier=kerb (with or without kerb=*, preferably with) should always be used at the exact position of a kerb – and that this is probably the most precise (micro)tagging. This then automatically rules out e.g. setting barrier=kerb + kerb=raised on a highway=residential node or other cases of incorrect tagging. And it also includes the (perhaps rare) cases of barrier=kerb + kerb=lowered on a node of highway=residential (or living_street or service or other) and other cases. And vice versa, it indicates that a node tagged only with kerb=* is either not in the exact position of the kerb, or that a barrier=kerb tag is missing …

  3. In all cases of kerb tagging for crossings, I find it a good practice if tactile_paving=* is also tagged for completion, e.g. for routing for disabled persons, for whom kerb tagging can often be valuable. I.e. especially on kerb nodes at the exact position, because that’s where it’s most valuable for routers for precise output. At the moment, I think it’s only mentioned with kerb=flush. But I also find it valuable as information for other kerb values, also in the form tactile_paving=no, which can be a warning for the blind.

A final note on the practice of StreetComplete and kerb=raised (without barrier=kerb) on highway nodes where no real crossing exists, but perhaps a footway line meets the highway: I don’t find this a very happy solution, although it doesn’t really hurt. The interpretation is at least the same as kerb=* on a highway=crossing node. But I would then find it much better to set a node with barrier=kerb + kerb=raised again at the exact position of the kerb or to ask for it. And in this case I wouldn’t tag kerb=raised on the node of e.g. highway=residential (as in the case of a highway=crossing node), because it seems (for me) like an element with no “mother (or father) element”, like an orphaned child, to stay with the figurative language. It feels like a stopgap that might also be confusing for some mappers (and could result in incorrect additions). And it potentially makes it harder for validators to define appropriate rules. It’s an exception that complicates the kerb issue.

To be honest, me neither. As far as I remember, it was the result of a compromise because some people objected to the use of crossing=no for these cases because they understand that it means it is forbidden to cross.

The current wording in the wiki (without having checked when and why it was last modified) is

crossing=no: Where definitely no crossing is possible/legal. Used at places where one would expect a crossing, but where there isn’t one. As crossing=no excludes the existence of a crossing, it must be used without highway=crossing

Sentence two is what we want to indicate, but sentence one postulates that it should only used when it is not possible, which is a pretty strong wording.

1 Like

Why not use crossing=unmarked then?

I often use this when mapping sidewalks as separate ways and connecting them over a street, even if there’s no lowered kerb. It doesn’t happen often, but there’s still “crossings” like this.

Just trying to understand if there’s a better solution than the current one :thinking:

1 Like