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”…
Yesterday had 130 odd warnings on my Osmose listing added of “barrier blocking highway” and “barrier blocking major highway”. After a half dozen sample visits, they all appear relate to marked crossings mapped as node and line, where the editor/preset asks what kind of kerb there is (StreetComplete does/did too), and then later on getting a thank you for having added N tags that would help walkers/wheelchair users.The new Osmose warning includes even if the crossing kerb has the =flush subtag.
Today I got another few more, looked, barrier=kerb + kerb=flush included, the crossing doubles as cycleway crossing. Not sure to whom this barrier blocks forward on, but since drawn as line, certainly does not block cars as the kerb tag is only on the end nodes where it connects to the foot/cycleway, which is behind a kerb separating cycle/foot from motorised traffic.
Please - just ignore Osmose here. It’s clearly just wrong.
To be fair, the front page of Osmose does say “In no case Osmose-QA should provide you the absolute right way to map, always keep a critical eye”. I’d suggest that people who are “OSM completists”** should never use Osmose, because it is not the tool for them.
** they want to remove every “warning”, regardless of whether it is an error or not.
LoL, had not read that qualification before, and I am one too. Just sound-boarding. Though what is sent as warnings because ‘once upon a time’ I created / edited an object’, the Osmose map itself allows substantial filtering out specific object issues, plus only looking at pins that related to myself in the history, squeaky clean it looks. This one has been added to the no-show and gets the X treatment when showing up in the personal list. ;P)
Thanks, this is interesting. So iD complains when kerb= appears without barrier=kerb and Osmose complains when barrier=kerb appears on a road? This risks creating a lot of very slow edit wars between people who fix the tagging with Osmose and those who “fix” it with iD.
I would actually suggest that we mass remove barrier=kerb from all barrier=kerb kerb=raised nodes where the barrier=kerb was created_by iD after an earlier changeset created_by StreetComplete added kerb=raised. But as long as iD (and possibly other validators?) suggests that kerb=raised alone is a mistake in this situation, such a one-off re-tagging would just be slowly undone again, over time.
By the way, since I created this thread
I have updated the Wiki documentation for barrier=kerb and kerb= to better reflect current tagging practice
It has been pointed out that barrier=kerb kerb=lowered sometimes appears legitimately on roads in Germany. (This doesn’t block cars from using them but signals to drivers that they have to give way.)
It has been discussed on the German forum that OSRM won’t route cars over barrier=kerb except when either kerb=lowered or kerb=flush or highway=crossing is also present on the node
In short, the behaviour of StreetComplete + iD is slowly breaking car routing in some areas for routers (such as OSRM) that avoid barrier=kerb kerb=raised. By my estimate about 3,000 nodes worldwide are affected. I see three ways out of this dilemma
StreetComplete could a different tag than kerb=raised to say that a potential crossing has been surveyed and the kerb is high - I have suggested this to @westnordost
iD could stop adding barrier=kerb (see my iD bug report)
Routers could ignore barrier=kerb altogether (as has been suggested in this OSRM bug report)
My preference would be for solution (2) but I don’t know how the iD programmers - presumably volunteers - prioritise bug reports. I invite everyone who agrees to “thumbs up” the Github issue, or, even better, to have a look at the code so we can create a pull request. I briefly tried this but I have no idea where to start. (I’m not even sure if the problem is in the iD code itself or in the iD tagging schema.)
Yet, again, the barrier=kerb should be mapped at the exact position and I doubt that they are at the intersection of the two ways but rather shortly before/after the intersection only on one way.