TLDR: The wiki page doesn’t make it clear which tag should be used for regular kerbs. The examples section suggests kerb=regular. However, this tag was rejected in a 2020 proposal. The opposition votes imply that regular kerbs should use kerb=raised, despite all the examples for that tag being of higher-than-normal kerbs.
The wiki documentation for the kerb key details how to tag kerbs that are dipped, flush or absent. But how do I tag a crossing with kerbs that are the same height as all the “normal” kerbs around it?
kerb=raised appears to mean that a kerb is taller than average, e.g. to be on the level of buses. However, the table doesn’t clarify this. This led me to check the Examples section.
The examples include a photo of an extra-high “raised” kerb at a bus stop, agreeing with my initial idea. A second image confirms this, showing a “raised” kerb that’s significantly higher than normal. It also appears to answer my question, labeling the normal kerb as kerb=regular. Why is this apparently-simple case not mentioned in the table?
Thanks for the insight. I think the term “raised” threw me off, as it suggested that the kerb had been raised from it’s normal height. Another case of confirmation bias?
It’s also good that the wiki no longer contains conflicting information. I’ll take a look at the page myself tomorrow and see if I can clarify things.
Looking at Proposed features/kerb - OpenStreetMap Wiki, I guess the “standard” height was meant as default value with no tag. The purpose of the tag being “Properties of a kerb to aid with accessibility” where elderly people and people with wheelchairs can use public transports thanks to raised platforms, the initial intention for “raised” was IMHO obvious. I don’t get how the meaning has changed overtime.
Looking at Proposed features/kerb - OpenStreetMap Wiki, I guess the “standard” height was meant as default value with no tag. The purpose of the tag being “Properties of a kerb to aid with accessibility” where elderly people and people with wheelchairs can use public transports thanks to raised platforms, the initial intention for “raised” was IMHO obvious. I don’t get how the meaning has changed overtime.
I agree, I always understood the “raised” value to mean a kerb that is higher than what you’d normally expect (expectations may vary across regions, but that’s probably a different issue)
I also agree, in that I’ve always understood “raised” was for sections of kerb raised above normal height. Usually found at bus stops to help passengers that would have problems with a change in height.
I’ve always tagged everything higher than a lowered kerb, as raised. No matter if it’s 5cm, 10cm or 15cm in height. If they are particularly high, like on bus stops, I added kerb:height with the appropriate value
kerb=raised + kerb:height definitely adds the needed data, but unfortunately it lacks semantics: if I’m using OSM data, it’s usually much more helpful to know the type of kerb. This is especially true as kerbs vary in height across regions, making it difficult to distinguish two different-purpose kerbs from each other.
Having said that, the existing scheme does a good job of this 95% of the time, so it’s not a massive issue.
Right, but it’s the same for oneway=no, except that we can add oneway=no. Adding later kerb=normal instead of changing the meaning of raised to “raised or normal”. So we have: lowered,(fine), unknown (OK) or raised(maybe raised maybe not). So we have only one interesting case of two (normal or unknown).
No, do you walk with a decimeter all the time, if not or if you’re using street view (Mapillary for instance) you can’t answer when it’s really raised, do you? You can’t enter the height. So the current schema is missing 50% of the end-user useful target. Before the raised redefinition it was missing no target, “only” quality assurance targets: for the end-user if you don’t know if it’s raised or not, you’ll avoid the kerb if possible.
