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