This new category shows kerbs (the edge where a road meets a sidewalk). Read more about this in the OpenStreetMap Wiki. The category uses the colours from the Wiki page. Popups will show additional information: type of kerb (lowered, raised, …), they wheelchair accessibility (if set), if the kerb has tactile paving and the height.
I see the good things about this. Especially to address accessibility issues. Or to point out where wheelchair users can (can’t) drive.
On the other hand, I can imagine that this costs a lot of effort to maintain. I also can’t imagine yet how to map this … as a key for a footpath or as a complete new type of object …
Very much in need after Carto removed =kerb rendering. But should =flush and =no use the same shape? There’s no height difference. At most, this side of the line points to the roadway. Changing to a different style allows less colors to be used, easier for color-weak readers (me). Wiki example icons uses a pictogram to symbolize them, only coloring for flavors.
Moreover, the line is quite thin. The coloring can get visually affected by other feature outlines.
Kerbs are mapped either as a node with barrier=kerb + kerb=* on the way crossing the road, or without barrier tag and just kerb=* on a highway=crossing.
I don’t know, according the Wiki page these values mean different things. I will change the indication to a similar colour.
For my eyes the line seems okay, but I accept different opinions about that. I tell you, what I will do: I will make the thickness of the line configurable.
I’m not to happy with the colours either, I just used the suggestion from the Wiki-Page. Similar to the thickness, I will create several colour schemes to choose from.
Do you want to make a suggestion? You could create a custom category by cloning the category. On the bottom of the code you will find the colour assignments. If you have a scheme with which you are happy with, you can copy&paste the link to your custom category. More about custom categories in my short introduction video: https://www.youtube.com/watch?v=I0x4Kwz6u90 (cloning categories at 1:24).
Great to see an app that renders kerbs! I’ve noticed that the kerb= tag is sometimes used to add detail to a whole footway=crossing way, not just as nodes on the way. Unfortunately, this results in the entire crossing being rendered as a kerb, which is incorrect as the kerb doesn’t actually span across the road.
This information is still useful, so perhaps show the crossing as a line without the marks that show the direction of the kerb? That might still be confusing.
The key is kerb=*, and is used on the node of a highway=footway, highway=cycleway, or highway=path at the location of the kerb (at the edge of the street).
[…]
If the kerb is identical on both sides of a crossing and the location of the actual kerbs is not clear (e.g., due to a lack of high resolution imagery), kerb=* is sometimes added to the highway=crossing node instead.
The kerb is not crossing the road. It does not make sense to add it to footway=crossing. You can add it to the highway=crossing node or at the actual positions of the kerb (but I’d suggest using barrier=kerb instead for this option).
Perhaps on crossings (without separately mapped sidewalks) it would make more sense to add kerb:both=* (or kerb:left/right) to describe the kerb geometry). This appears to have a few thousand uses already.
I dislike highway=footway, kerb=*, because on other uses, kerb is exactly on the way, and here it would be at an offset of width/2. This is confusing.
That’s why I support kerb:both/left/right.
Anyone up for writing a proposal? I do not care enough about this. I’m happy to support this extension, if it gets approved (I could already implement it on a development branch for testing purposes).
You’re welcome to use the icons from Key:kerb as well (or derive a more suitable version from them) if it makes sense. I made them, and have placed them in the public domain for reuse.
I actually like the colour scheme and consider making it the default. Any opinions on that?
I see two potential drawbacks:
It differs from the wiki, which is slightly confusing (not a major point though).
The colours seem to have lost their semantic value: i.e., greenish colours mean wheelchair accessible, reddish colours mean they are effectively wheelchair barriers, and desaturated (black, grey) implies absence (kerb=no) or unclear (kerb=yes) values.