How do I tag normal-height kerbs?

Help and support Tagging help & support
,
#1

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?

This issue has been brought up on the talk page, where the discussion links to a 2020 proposal for kerb=regular. However, it was rejected, and the vote comments suggest that normal-height kerbs fall under the kerb=raised tag.

Does the wiki page need to be updated? Do I misunderstand the proposal? Or is kerb=regular correct after all?

For some additional context, kerb=raised has 13% usage, and kerb=regular has 0.25% usage, under the kerb key. (taginfo)

A photo of three different kerb heights, labeled as "lowered", "regular", and "raised".
A photo of three different kerb heights, labeled as "lowered", "regular", and "raised".1339×393 659 KB

#2

kerb=raised is tagging used for that.

2020 proposal was trying to redefine the existing value “raised” and change its meaning despite that it was used already in a different way.

I made an edit to wiki in Difference between revisions of "Key:kerb" - OpenStreetMap Wiki removing one of examples mismatching actual tag use and rejected in 2020 proposal. Maybe further edits would be useful.

3 Likes
#3

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? :upside_down_face:

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.

#4

If you look at Bus stop with raised kerb on the wiki it’s still clear that “raised kerb” was meant for above normal height.

2 Likes
#5

Yes, and we currently have no tagging for actually raised-above-normal-level kerbs.

I wonder whether people inventing initial tagging scheme provided option for “this is normal kerb with about 10cm height”

From looking at Key:kerb - OpenStreetMap Wiki it seems that it was missing, with predictable results.

3 Likes
#6

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.

2 Likes
#7

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)

5 Likes
#8

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.

1 Like
#9

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 :man_shrugging:t2:

3 Likes
#10

And that was a mistake, people will want to tag also such info (otherwise you cannot distinguish between “not mapped” and “default applies”).

3 Likes
#11

Although this requires more detailed OTG check it is definitely the most accurate solution to avoid any misunderstanding of the term “raised”.

#12

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.

#13

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.

#14

I’ve always seen “raised” as opposite of “lowered”. I.e. if a wheelchair user encounteres kerb=raised (documented on wiki as >3cm) then that is impassable barrier for them (while kerb=lowered would be passable obstacle, although less preferred than kerb=flush).

Usually found at bus stops to help passengers that would have problems with a change in height.

In practice, in my city for example, over 3/4 of kerb=raised are not even near (overpass) bus stops (and of many of those, vast majority seems to be just highway crossings that happen to be near bus stops, as is common here).

1 Like
#15

IMHO the decision to define a 3cm threshold in the wiki and treat everything above indistinctively, was not very wise. While 3cm may be ok for almost everybody, it doesn’t mean that everything above isn’t. It is surely of high significance for someone in a wheelchair to know whether this “raised kerb” is 4cm high, or 20cm. Currently, considering tag values used more than 0.5%, we have 3 values for “0” (“no”, “flush”, “rolled”), one for 0-3cm (lowered) and one for everything above (raised).

Maybe it is too late now to redefine “raised” (assuming that people actually used “raised” in the way the wiki suggests), there are also some lower usage values such as “regular” (0.24%), “normal” (0.09%), and there is “high” (52 times / 0.01%) which seems suitable for a kerb higher than “regular”.

#16

I agree. It may not make a difference to wheelchair users if a kerb is 5cm or 25cm but it makes a big difference to cyclists. Unfortunately since “raised” has come to mean “high” and “lowered” has come to mean “low”, we don’t have a good way of tagging the approximate height of kerbs above 3cm or so. I don’t walk around with a measuring tape so I don’t use kerb:height myself, I’m also not sure if any bicycle routers make use of it. I would support any attempt to improve the situation, though after reading the discussion on the failed kerb=regular proposal I’m not sure how this can best be achieved.

#17

Yes, it does. But so does 0.5cm vs 2cm, 2 cm vs 4 cm, 4 cm vs 8 cm, as well as 8 cm vs 12 cm as well as 12 cm vs 25 cm, and probably more categories.

Depending on the type of bicycle, its load, as well as skill of rider, some of them might be passable, and others not. kerb=regular would not have solved the problem even if it was accepted - you would have to have at least 5-8 different categories of height. After all, it matters greatly if one is running motorized wheelchair with big wheels, one pushed by hand by weakly armed disabled person, child bicycle with supporting wheels, heavily loaded cargo bicycle, road bicycle with thin high-pressure tires, touring bike, trekking bike, or 29" full-suspension MTB - to mention just a few popular use cases.

Meanwhile, kerb:height=* is well documented, and has some 34k+ uses and rising steeply and is much more versatile than kerb=regular could’ve ever been.

I don’t walk around with a measuring tape so I don’t use kerb:height myself

I do, the paper one from IKEA or hardware shops, it’s convenient and it fits in wallet easily. I’d suggest it to any mapper who cares about height of the kerbs too :wink: Also, many smartphones offer some kind of measurements, from low-tech but high-precision drawing of scale on the screen, to higher tech AR measurements (but sometimes less precise for such small measurements). Or you can even just estimate (and add source:kerb:height=* if you care). It’s not such a huge difference for usage whether it’s 4.5 cm or 5.0 cm, and you can probably guess well enough for most uses after little training. Or you can be quite more precise with some preparation (i.e. noting down while at home exactly how fat 1,2,3, or 4 of your fingers are, and then using multiples of that to pretty precisely measure how tall is that kerb)

I only take time to measure the problematic or unexpected ones that I personally care about (same as with the rest of the map: unless extremely bored, I mostly don’t map the things I don’t care about, like e.g. gambling shops)

I’m also not sure if any bicycle routers make use of it

Well, “map it and they will come”, eh? If one wants it, they should contact their favorite router and ask for that functionality (if it is not yet implemented). For example, brouter allows user to customize their own preferences down to scripting level and use that profile without any compiling, so you could yourself make a profile that completely avoid routes requiring too high kerbs for your specific bicycle, and adding different routing penalties depending on height group of lower ones.

1 Like