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

General talk Tagging general discussion
3


|
|

  • | - |

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

1 Like
4

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.

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.

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

1 Like
5

Thanks for your comments.

Sorry I should have been clearer. I came across all of them in Overpass when I was trying to understand how to map 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.

1 Like
6

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.

7

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 :confused:

2 Likes
8

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

1 Like
9

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:

image
image1041×315 85.3 KB

Bing view with data of the same crossing

image
image888×793 66.6 KB

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…

3 Likes
10

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.

11


|
|

  • | - |

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

1 Like
12

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
13

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.

14

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
15

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
16

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.

17

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.

19

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

1 Like
20

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

21

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.

22

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

23

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