When trying to understand how to tag a kerb, I went looking for mapped kerbs and found this example of a node tagged as barrier=kerb, kerb=raised where a highway=footway and a road cross over. There aren’t any other tags on this node.
Looking at the Wiki, I think a better tagging for this node would be highway=crossing, crossing=unmarked, kerb=raised. (The only physical indication that pedestrians are meant to cross there is a gap in the fence along the kerb.)
The presence of barrier=kerb seems to be a clear mistake: According to the Wiki page for barrier=kerb, this tag on a crossing node is wrong because it implies that road users also have to go over the kerb, like some sort of traffic calming feature. According to the Wiki page for the kerb key, kerb=* on the crossing is perfectly fine.
Looking at the history of this node, the addition of kerb=raised to the previously untagged node was prompted by StreetComplete. The addition of barrier=kerb happened in a later changeset. The changeset comment doesn’t indicate why it was added, but I suspect it’s because iD complains when kerb=raised appears on its own, and suggests adding barrier=kerb.
Is it a bug in StreetComplete that it adds kerb=raised without adding highway=crossing?
Is it a bug in iD that it suggests adding barrier=kerb to all nodes tagged only as kerb=raised? A feature that probably makes sense for some other nodes like this one.
Is it a bug in iD that it suggests adding barrier=kerb to all nodes tagged only as kerb=raised?
I would think so. barrier=kerb has to be placed where there is actually a kerb (be it on a node where a highway crosses a kerb or on a way representing the kerb), but the kerb key can be put on other objects as well (e.g. crossings).
Thanks. I agree but I wanted to get some views from others.
In this case, it’s a little bit different. The kerb key hasn’t really been put on another object like a crossing, it is the only key on the node.
Looking into this some more, this seems to be done deliberately by StreetComplete (see this discussion and this one): when a footway meets a road it makes sense to ask what the kerb looks like, but if the user then says “it’s high” they don’t want to add a crossing, even an unmarked one, because crossing the road there might not be (legally or practically) feasible.
Something about this struck me as odd at first, like tactile_paving=yes or wheelchair=yes alone on a node. But after reading the justification, it makes sense.
In this case, it’s a little bit different. The kerb key hasn’t really been put on another object like a crossing, it is the only key on the node.
there are 500000 nodes with barrier=kerb and kerb=* and these are not crossings themselves but intersections of footways with kerbs (likely the footways are part of crossing ways). IMHO barrier=kerb should be added to kerb=* nodes if the kerb is at that position and it seems the prevailing mapping style as well.
Yes… ideally StreetComplete would ask people where exactly the kerb is, and add a node with barrier=kerb here. But it doesn’t do that level of detail.
It puts kerb=* on the node where the footway meets the road (in this case highway=tertiary) which is in the middle of the road. And I think we both agree that this is odd?
-Edit: I meant to say it looks odd but I see where they’re coming from. Whereas I think we agree that adding barrier=kerb to that is just wrong.
You’re right, it doesn’t make any sense to have kerb=* on a node without any other attribute like barrier=kerb or highway=crossing, because it’s not a standalone-tag. So yeah, I’d say it’s a combined bug:
It’s an odd behaviour of street complete to add kerb=* to a node where two highways meet that isn’t a “proper” crossing. kerb=* is not meant to be used standalone. When two highways meet, it’s a crossing and when it’s not an official one, it’s unmarked, no matter what the folks in the GitHub discussion are getting at. Routing engines can then decide what to do with highway=crossing+crossing=unmarked+kerb=raised nodes. But that’s a lengthy discussion of its own.
It’s a bug of iD to add barrier=kerb to any kerb=* without highway=crossing for sure. At least on the crossing node of 2 highways.
I was curious how common this is and wrote two Overpass queries.
This one checks for barriers in the middle of roads (not service roads where lowered kerbs are probably common). These are probably candidates for surveying and removing the barrier=kerb? There are about 80 in Berlin, 40 in Paris, 20 in London.
This one checks for “lonely” kerb keys on roads. There are about 70 in London, 30 in Paris and 300 in Berlin.
I suppose there is a point where it become pointless to discuss if it’s desired behaviour and it’s simply accepted as established practice?
I also wonder how important all of this really is for routing. I tested one of the crossings with some routing engines. They were perfectly happy with routing a pedestrian along the footway where it crossed the highway=tertiary, even before I added the unmarked crossing. I wonder how much of a difference it really makes to routers whether the kerb=raised node is also tagged with highway=crossing and crossing=unmarked or not. Or if they really penalise a road for having a barrier=kerb on it: maybe they ignore them because they are more often mistagged than actual kerbs on roads.
To complicate things further, there are even more examples (Overpass query) of kerb=* on footways, paths, cycleway, service roads… without barrier=kerb that presumably have been mapped at the actual location of a kerb.
In fact this is the main usage of kerb=* documented in the Wiki, and the Wiki page doesn’t even mention that barrier=kerb could be added to such nodes.
So in summary, standalone kerb=* is fairly common. The meaning of it, as it is currently tagged, on roads is “there is a kerb on each side of the way at this point” and on paths, footways etc. it is “there is a kerb on the way at this point”…