Talk:Key:kerb

Lowered flush kerb

Is "lowered" intended to mean lower than the rest of the kerb, or does it mean lower than a normal kerb (low enough to be traversed using wheelchairs)? If there's a dip at a crosswalk (perhaps just a slight dip) and the kerb is flush with the pavement there, should it be marked kerb=lowered or kerb=flush? Germyb (talk) 22:59, 8 September 2017 (UTC)

kerb=lowered means a low kerb that can be traversed by someone in a wheelchair. – If you think a blind person with a stick notices the difference in height between the carriageway and the kerb/pavement, tag it kerb=lowered, if not, tag it kerb=flush. Hope I could help. --SelfishSeahorse (talk) 16:48, 28 December 2017 (UTC)

Directionality?

JOSM makes a distinction how kerbs are drawn based on the direction of the way. There's a description on the wiki page for natural=cliff, on how to draw a cliff to indicate which side is higher than the other. Should similar text be included to this wiki page, to indicate which side a kerb rises or lowers? —Preceding unsigned comment added by Mrbrown8 (talk • contribs) 04:33, 19 December 2017

It seems you confuse kerb=* with barrier=kerb. For barrier=kerb, right is bottom, left is up. --SelfishSeahorse (talk) 16:48, 28 December 2017 (UTC)

Resolved: It seems that no action needs to be taken Mateusz Konieczny (talk) 18:33, 26 September 2020 (UTC)

Open issues and suggestions how to solve them

1. Common high kerb

2. Square kerb of low height

3. Kerb ramp

4. Sloped kerb

5. Semi-mountable kerb

1. Contradicting informations whether common high kerbs (see image 1) can be tagged raised or if this value is reserved for very high kerbs at public transport stops

   I think it makes sense to tag them raised too, as it doesn't make a difference for wheelchair users if the kerb is 12 or 30 centimetres high.

2. kerb:left=* and kerb:right=* for asymmetric kerbs tagged on a crossing node

   This doesn't make sense, because a node has no directionality. I think this comment should be removed from the wiki.

3. Undocumented how to tag kerbs along roads or sidewalks

   Suggestion: kerb:left=* and kerb:right=*

4. No default unit for kerb:height=*

   As the default unit for height=*, which is also used for barrier=kerb, is metre, it would be very confusing to use a different unit for kerb:height=*.

5. No distinction is made between square kerbs of low height (ca 2–4 cm; image 2) and kerb ramps / sloped kerbs (images 3 and 4)

   Suggestion: use sloped for kerb ramps and sloped kerbs, leaving lowered for kerbs of low height

6. No value for kerbs that are traversable by vehicles and bicycles, but not wheelchairs, due to too high degrees (image 5).

   Suggestion: new value strongly_sloped

Alternative kerb=* value scheme:

• mountable: mountable for wheelchairs and vehicles
• semi-mountable: not mountable for wheelchairs but mountable for vehicles
• non-mountable: neither mountable for wheelchairs nor vehicles

--SelfishSeahorse (talk) 18:43, 28 December 2017 (UTC) (edited 16:12, 7 January 2018 (UTC))

Here's my take on the open issues:

1. Wheelchair users may not be interested in the difference, but other data consumers will be. So I believe should be possible to distinguish these two types. This was already brought up as an issue back in 2011 when the key was proposed. The suggestions included introducing the value normal (for kerbs like in image 1), the value bus (for those very high public transport kerbs), or both.
2. Crossing nodes must always be part of a road, and the left/right tagging simply refers to the direction of that way. Works fine in practice.
3. How about sidewalk:left:kerb=* and sidewalk:left:kerb=*? This tagging scheme is already mentioned at Key:sidewalk#Additional_tags.
4. I agree that the default unit should be metre.
5. We should distinguish them, but to me, images 2 and 4 seem much more similar than 3 and 4. Can you clarifiy the criteria you would use here?
6. Sounds ok to me.

--Tordanik 18:01, 15 January 2018 (UTC)

Thanks for your feedback!

1. normal might not have the same shape and height everywhere ... Meanwhile, I think it's best to tag the kerb shape (rectangular/sloped/rolled/flushed), height and incline (for sloped kerbs), as this information is unambiguous and universal.
2. Now, I understand. But isn't this a bit unstable if the direction of the road way is reversed? And what if the crossing node is connected with a footway?
3. I was thinking of sidewalks tagged as separate ways.
4. ...
5. The criteria would be difference in height (rectangular) vs no difference in heigh (sloped), or slope (sloped) vs no slope (rectangular).
6. Tagging the kerb shape would make kerb=strongly_sloped unnecessary. A sloped kerb of 45° cloud simply be tagged kerb=sloped + incline=100%.

--SelfishSeahorse (talk) 20:58, 17 January 2018 (UTC)

1. Tagging these facts – height in particular – would indeed make things unambiguous. But people will have a hard time giving kerb height in metres without measuring it, so there's still value in a basic height-based classification. (Right now, this key mixes height and shape, which makes things a bit more tricky.) I agree that "normal" is somewhat unclear, though. So maybe it makes sense to use a special value for the higher ones then, such as "bus_stop" or "Kassel"? Not sure how to call it.
2. JOSM will warn you when you reverse a way containing a node tagged kerb:left, and will offer to change it to kerb:right for you (and the other way round, of course). Not sure about other editors. Footways connecting to crossing nodes are common, but I don't think that's a problem: The left/right has the same meaning as if the footway wasn't there (i.e. it refers to the road way, not the footway way).
3. Oh, nevermind then.
4. ...
5. Maybe the issue is that I haven't seen anything close to the situation depicted in "kerb ramp" in real life, but it would really stand out to me, whereas I would probably barely notice the subtle incline on the stones in the "sloped kerb" image. So intuitively, I'd consider this a separate case from the ramp. Would be interested to get other mappers' impressions.
6. incline is only usable on ways, though. Do you intend to use kerb:incline with special semantics?

--Tordanik 20:40, 23 January 2018 (UTC)

1. bus_stop seems fine, although not all kerbs at bus stops are higher than common high kerbs. kassel, however, couldn't be used for all kerbs at bus stops.
2. There's no warning in iD. But this might not be a big issue, because pedestrian crossings with different kerbs on either side seem to be rare.
3. ...
4. ...
5. You're right, a kerb ramp is quite a bit different from a sloped kerb. Actually, a kerb ramp isn't a feature of the kerb but of the pavement (sidewalk). Maybe ramp for kerb ramps and sloped only for sloped kerbs as depicted in image 4? When mapping pavements as ways, it may make sense to map them as a way too, maybe tagged footway=kerb_ramp.
6. According to Key:incline, this key can also be used on nodes, but kerb:incline=* seems to be fine too.

--SelfishSeahorse (talk) 18:29, 25 January 2018 (UTC)

6. For the kerb shown on picture 5, and multiple times referred as being inclined, why not simply make it kerb=inclined ? Would be easy to use, short, well describing, and fit in the exisiting wording. There is no occurrence of the recommended "strongly_sloped" yet. Kempelen (talk) 20:57, 15 April 2022 (UTC)

value driveway for kerb, and should be associated with wheelchair=limited instead of no

I would add value kerb=driveway in the wiki (value is empty)for driveways (about 100 occurrences in taginfo, not so much though... [1]) AND modify description about wheelchair. A driveway is accessible with assistance so it would be wheelchair=limited instead of no [2]. 1: https://taginfo.openstreetmap.org/tags/kerb=driveway 2: https://wiki.openstreetmap.org/wiki/Key:wheelchair#wheelchair.3Dlimited --Violaine Do (talk) 21:18, 1 April 2020 (UTC)

We should define a value for that case, yes. However, I don't think "driveway" would be a good choice because many of the other kerb types (lowered, flush, rolled) can also be found at driveways. People would probably be confused that kerb=driveway would be incorrect for most kerbs at driveways – especially if, say, lowered kerbs are considered the "normal" driveway kerb in their area. Maybe call it "angled", "angled_sett" or something like that? --Tordanik 18:55, 26 July 2020 (UTC)

Yes, kerb=driveway would be a mistake as driveway may have flush kerb, lowered kerb and raised kerb Mateusz Konieczny (talk) 18:34, 26 September 2020 (UTC)

"Double sided" kerbs

All of the examples listed into this sub seem to be talking about node descriptions for types of kerbs for access restrictions on footways. I tag a lot of kerbs as ways when they are used as a barrier for routing cars and other instances.

While all of these examples cover the the types of kerbs found in America, the most common kerb type in Japan is not represented: the kerb that is raised on both sides. I'm not talking about walls, fences, bollards, bricks, or whatnot - these are precast concrete segments inserted into the ground just like regular precast kerbs, but they are finished on both sides so there is no backfill necessary for the sidewalk surface. this means the kerb is rougly 15-25cm in height for both the roadway and walkway. and rain can drain out of the walkway and roadway to drains under the kerb (urban) or out of the road and across the walkway to the shoulder (rural).

These types of kerbs can be seen (incidentally) in some of my photos here:

https://www.flickr.com/photos/javbw/18254840438/

3m segment in front of an old shop in Kiryu.

https://www.flickr.com/photos/javbw/11091229245/in/album-72157638113676925/

Right side, with yellow reflectors along a busy road in Kiryu).

https://www.flickr.com/photos/javbw/11091451953/in/album-72157638113676925/

2 sidewalks with double-sided kerbs separating them from the separated roadways in Nagano, along a national road (with a sunken center island) with a ped bridge in the distance.

https://www.flickr.com/photos/javbw/11091215254/in/album-72157638113676925/

Extreme left side, separating the walkway from the left side of the road in Niisato.

there are no "cuts" - just an absence of kerb inserts (the ends taper to nothing, not further segments are inserted, and the surfaces meet flush or are the same continuous surface, usually asphalt). While regular kerbs are common in urban areas (with cuts, etc), these are the dominant type because they also present a barrier to foot traffic entering the roadway. there is probably several times more linear length of these "double-sided" kerbs in Japan (suburban and rural sidewalks) than all other type of kerb combined - yet there is no way currently to map this type.

since mapping software, such as iD, labels the assumed "inward/outward" or "higher/lower" attribute of the mapped linear kerb, how should I tag their "double-sided" nature?

—Preceding unsigned comment added by Javbw (talk • contribs) 03:48, 28 April 2020‎ (UTC)

(please sign with `~~~~`) This is an excellent question. I share the same doubt. It is not entirely true that "mapping software, such as iD, labels the assumed "inward/outward" or "higher/lower" attribute of the mapped linear kerb" - they following the definition by the "approved" proposal. I believe it was assumed sidewalks are on the same height as the kerb, and more detailed or general tagging is lacking (such as this issue, and whether a kerb is inclined discussed above Talk:Key:kerb#Open_issues_and_suggestions_how_to_solve_them). This issue is compounded by the reality that we can't really map kerbs as an area, unlike other barrier=*. Japan refers to the effect/result of "kerb" indirectly by the sidewalk height, viz "flat"="フラット" (the subject in question here), "semi-flat"="セミフラット" (chosen as standard), and ”mount-up"="マウントアップ". These are similar to parking block / "curb stop" / bumper kerb at parking spots, so maybe they could be considered together. It seems to me it is not neccesary (however it should take a new proposal to change) to attribute a height difference to barrier=kerb representing the kerbstone, if either the kerb height on each side (ie kerb:left=* & kerb:right=*) is defined on the barrier=kerb, or they can be tagged by a kerb=* on the road or sidewalk.-- Kovposch (talk) 08:35, 28 April 2020 (UTC)

Double-sided curbs in San José, California

@Javbw: I've run into the same issue with the "vertical separation" curbs that San José, California, has been installing in the middle of roadways to create "frontage lanes" that are safer for abutters and cyclists. These curbs aren't even wide enough to stand on, so they can't be mapped as traffic island areas. For now, I'm experimenting with ways that double back on themselves, since barrier=kerb could be interpreted as the physical curb itself, not just the surface of one side of it. – Minh Nguyễn ^💬 06:16, 23 November 2021 (UTC)

I think the problem has been solved somewhat with the addition of two_sided=yes, https://wiki.openstreetmap.org/wiki/Tag:two_sided%3Dyes , but I would still love to have some type attribution. I also like the idea of a regular way that double-backs, mapping all 4 side for such large kerbs. Your examples are much larger and prominent than the narrow (15-20cm/6-8in) precast segmented kerbs I am mapping. I would choose “sloped” as the type (that’s a type, right?), but you probably have a better definition already. Good luck with the kerbs! Javbw (talk) 19:25, 14 June 2022 (UTC)

kerb=regular vs. raised -- add "regular" example

It seems that there is a lack of clarity in the differentiation between raised and regular kerbs. kerb=regular is already used relatively often and should be explicitly distinguished from kerb=raised (especially for better wheelchair/reduced mobility information). The note in the raised-section (Note: may be considered normal or yes pending discussion.) seems to be out of date, kerb=regular seems to be more common in the meantime. In my mapping area I started mapping detailed sidewalk and intersection information and used kerb=regular for "normal", not lowered and not raised kerbs (often on older intersections), as apparently many other mappers do.

Edit: Also kerb=regular is mentioned in the first picture in the examples section without appearing in the tagging list.

So I propose adding the following example to the list:

Value	Typical height	Typical use	Description	Example
regular	~10 cm	Normal kerbs, (older) crossings with reduced accessibility	According to the local standard height. Prevents wheelchairs from crossing and represents a barrier for bicycles, strollers, etc. To be found at older intersections or at intersections that were not designed according to accessibility aspects.

Accordingly, the height for kerb=raised would be ">~10cm". Do kerb=regular in this sense implies wheelchair=no? --Supaplex030 (talk) 19:06, 22 July 2020 (UTC)

As a result of a rejected proposal for kerb=regular, I consider a new solution for clarity between normal, raised (to prevent accessibility) and raised (to create accessibility) kerbs. See discussion.--Supaplex030 (talk) 20:43, 6 September 2020 (UTC)

regular seems to be a big mistake because what is normal/regular will wildly differ from location to location Mateusz Konieczny (talk) 18:36, 26 September 2020 (UTC)

Proposal for "regular" was already rejected. It's on my todo to revise the paragraph for kerb=raised here on this page to integrate the results of the discussions. Haven't found the time yet...--Supaplex030 (talk) 21:09, 26 September 2020 (UTC)

See Proposed features/kerb=regular for the proposal Mateusz Konieczny (talk) 07:06, 25 August 2021 (UTC)

I agree there is a definition gap, where we currently have 3 values for a 0-kerb, 1 for 0-3cm and all the rest is tagged with ‘raised‘ for which someone wrote "more than 3 cm". Tagging the actual height is of course possible, but we should introduce "normal" kerbs and also have a way to distinguish them from high kerbs (higher than normal), and maybe something to split the kerbs between 3cm and normal height(12cm?), i.e. a new group for more than lowered and less than normal. --Dieterdreist (talk) 12:38, 31 March 2023 (UTC)

Both kerb ramps and lowered kerbs are tagged in the same way

See https://wiki.openstreetmap.org/wiki/Key:kerb#Tagging - https://wiki.openstreetmap.org/wiki/File:Lowered_kerb.jpg https://wiki.openstreetmap.org/wiki/File:Dropped_kerb.jpg both tagged kerb=lowered

It was less explicit in the proposal (that never went to vote), but present from start - see https://wiki.openstreetmap.org/wiki/File:FI-Raised-regular-lowered.png from https://wiki.openstreetmap.org/w/index.php?oldid=1207438

Extra additional tag to distinguish this would be nice Mateusz Konieczny (talk) 22:09, 14 January 2021 (UTC)

It seems, some mappers are using sloped for this – could be a good new value. For the term, also see this very old and outdated proposal: Proposed features/sloped curb

kerb=sloped

--Supaplex030 (talk) 22:52, 14 January 2021 (UTC)

Clarify "Raised above the norm"

What about situation where there are no lowered kerbs on crossings at all, and it regular to have the same in each place?

What about place where flush kerb of 0 height is standard and "Raised above the norm" would be rare kerb=lowered?

Maybe replace it by "High kerb, raised so that wheelchair and bicycles have noticeable trouble to pass it. In many places it is above the norm for crossings"?

Note that the current phrasing can be easily misinterpreted as meaning "kerb on crossing is higher than on sides of crossing" - see https://github.com/streetcomplete/StreetComplete/issues/3205#issuecomment-905236423

Mateusz Konieczny (talk) 07:05, 25 August 2021 (UTC)

Change suggested by Mateusz Konieczny looks good to me, making things more clear --mnalis (talk) 13:54, 25 August 2021 (UTC)

Resolved: edited Mateusz Konieczny (talk) 14:35, 18 October 2021 (UTC)

Doppelte Querungsstellen

At least in some parts of Germany so called "doppelte Querungsstellen" (literally "double crossing points") are becoming more widespread. These feature kerbs with two different heights: flush, for wheelchair users and lowered for users of white canes. Typically, additional tactile paving points to the edge where the kerb is flush.

How do we properly map such crossings? I've been using kerb=flush;lowered for a while now and noticed that kerb=lowered;flush is in use too. Are these tags suitable? --Nw520 (talk) 11:14, 26 September 2021 (UTC)

Seems to work for me Mateusz Konieczny (talk) 14:36, 18 October 2021 (UTC)

Not to be too pedantic, but both sides on that photograph seem like kerb=lowered. With flush there should be no detectable grade at all, but that sidewalk sits about 10cm higher than the street. The right side also has an upward slope; it's just less steep than the left one. --JeroenHoek (talk) 12:17, 13 March 2022 (UTC)

I asked the same question in the German Community Forum: https://community.openstreetmap.org/t/fahrbahn-uberquerungsstellen-mit-kombination-aus-abgesenkten-und-nicht-abgesenkten-bordstein/99940/1 I will use the tags kerb=flush;lowered for now. However, this is only clear for barrier=kerb nodes. With highway=crossing this is used when the two sides are different. Maybe we should introduce a new value for this kind of combination. --OSMRogerWilco (talk) 07:13, 16 October 2023 (UTC)

Left/right on node does not work!

Would someone, please, explain me how :left and :right is supposed to work on nodes. I believe it is not working but please proof me wrong. If not, it needs to be explained that kerb:left=* and kerb:left=* are only valid on ways. --Skyper (talk) 13:58, 18 October 2021 (UTC)

It likely intends to use direction from way where such node is embedded. --Mateusz Konieczny (talk) 14:34, 18 October 2021 (UTC)

Yes, but that does not work. There is no editor support when reversing the way direction or splitting the way at the node. The working and easy solution, if the kerb is different on both sides, is to map the kerb as own way node at its position using barrier=kerb + kerb=* and optional height=*. --Skyper (talk) 11:24, 19 October 2021 (UTC)

'right' and 'left' at nodes are not unique if several paths arrive at the node. But it can be done cleanly on the edges. If sidewalks are not mapped separately, splitting the way of the street in the area of the crossing would be the clean solution. What is very unattractive and unwieldy is that the street way is divided into very short sections. --Jo (talk) 17:32, 6 November 2021 (UTC)

directional lowered kerbs?

I don't believe we have a tagging scheme in place to tag whether a flush/lowered kerb are directional (i.e. leading to the other side of the crossing) or not (i.e. shared between two crossings and arranged diagonally between the two) Compare this:

• 

  Nondirectional kerbs

• 

  directional kerbs

• 

  Retrofit tactile paving on nondirectional kerb

Knowing this information could be very important to the blind. Popball (talk) 12:39, 27 May 2022 (UTC)

In case of https://wiki.openstreetmap.org/wiki/File:Marked_crossing_example.png I would consider that maybe it is mapped incorrectly - maybe there should be single footway crossing, branching later into two? 17:21, 27 May 2022 (UTC)

I agree, and the page for crossing=* should probably be updated. The question remains: can any data consumer be expected to tell this implicitly by the highway geometry?

kerb=* cannot tell you anything but the presence (or absence) of a kerb, and that ways passing through it encounter it. That example is mapped mostly correctly, but the short bits of highway=footway between the sidewalk way and the kerb shouldn't be tagged with footway=crossing, only the parts crossing the carriage way between kerbs. A router wanting to advise people who want to cross 'diagonally', should be able to advise them that they have to take two crossings, with a safe point in the middle on the corner of a sidewalk (like this, crossings (footway=crossing) marked in red, 'normal' ways in green). Of course someone can bypass the kerbs in the middle of that route if there is time, but whether that is possible can only be determined by the pedestrian at the time of crossing; not by routing software. --JeroenHoek (talk) 08:28, 28 May 2022 (UTC)

Hi I just wanted to let you know that the "short bits" of footway=crossing between the sidewalk way is just the full length of the crossing way, splitting it up and changing it to sidewalk to intentionally add short bits would be incorrect. Footways are no different than normal roads in how they're tagged. That would be like splitting a driveway into a residential road because it's over the paved area of the residential road. What you're suggesting is exactly the same as saying this image is correct. Also, by adding a small sidewalk if you want to cross the road, you're basically telling a router than you need to turn off the main sidewalk onto another sidewalk and then to the crossing, which makes no sense when the crossing should be connected to the main sidewalk. --Mxdanger (talk) 09:40, 23 September 2022 (UTC)

Separate pieces of footway=crossing, footway=traffic_island, and unspecified or footway=sidewalk bits tell routers and other data consumers exactly how long a crossing is and if and where it has safe refuge areas in between. This is valuable information for pedestrians with disabilities or for whom a long crossing without refuges is something to avoid. A good router will not give different instructions based on the presence of a separate little bit of footway before the crossing. It will just say “turn left and cross the street” based on the data it has available. It is also valuable information for users interested in gathering data about crossings in an area (e.g., for traffic safety and accessibility studies).

Don't worry about the separate bits. Even a relatively normal straight street can be split up into several parts in OSM because of speed limits changing at some point, parking lane information only applying to certain sections, cycling routes using only part of the street, etc. Routers can handle this, and the average user isn't impacted by this. Mapping only the actual crossing with footway=crossing is quite correct. Keep in mind that footway=crossing is not a hierarchical classification, unlike your example of residential/service. It is a functional one declaring a section of footway to be a crossing. --JeroenHoek (talk) 10:18, 23 September 2022 (UTC)

Does this tag require barrier=kerb?

I'm not sure where, but I recall reading a discussion about barrier=kerb not being required for kerb=* as used on a node. However, I keep seeing changesets by mappers blindly applying iD's suggestions and adding barrier=kerb to all kerb=* nodes lacking one. Is this something we should get fixed in iD, or should this page document that barrier=kerb is a requirement? It seems superfluous to me because barrier=kerb is more meant as a linear feature, whereas kerb=* is about adding routing-information for disabled people. --JeroenHoek (talk) 08:19, 31 May 2022 (UTC)

This has now been discussed in the community forum at [1] and [2]. The consensus there was that where there is a node at the actual location of the kerb, it makes sense to add barrier=kerb, because kerb=* by itself is ambiguous. Of course, where kerb=* is just used to provide additional information about something else, barrier=kerb should not be added, and I have reported this as a bug in the iD Github issue tracker. Osmuser63783 (talk) 19:35, 25 March 2023 (UTC)

height=* or kerb:height=*?

This page suggests using kerb:height=*, but Tag:barrier=kerb suggests using height=* instead. What gives? --Waldyrious (talk) 15:57, 16 August 2022 (UTC)

TagInfo suggests kerb:height=* has been used over 23,000 times, and it was part of the original proposal for kerb=* over a decade ago; it is perfectly fine to use. The current unresolved issue with barrier=kerb is that barrier tags are usually meant for linear features, not nodes. The reason it is used together with kerb=* may stem from the warning ID raises when kerb=* isn't accompanied by barrier=kerb; even on nodes. For kerb=* on a node this doesn't seem to be required though, but no one has bothered to get this squared out properly yet. With any barrier=*, height=* can be used to supply the height of that barrier (which includes fences and the like). Either way, height=* probably isn't wrong either, but it may cause confusion when multiple features are tagged on a single node. With kerb:height=* you know that it represent the height of the kerb, and nothing else. --JeroenHoek (talk) 16:38, 16 August 2022 (UTC)

Thanks for the context. Given the high prevalence of kerb:height=*, I think it would make sense to recommend it in Tag:barrier=kerb rather than height=*, then. WDYT? --Waldyrious (talk) 17:07, 16 August 2022 (UTC)

I'm not quite sure. For ways tagged with any barrier=*, height=* is well established. For nodes that mark the point where a path encounters a kerb (useful for wheelchair users) with kerb=*, kerb:height=* is well established. Intuitively, I would then use height=* for a kerb mapped as barrier=kerb (regardless if it has kerb=* too) as a way , and use kerb:height=* only for the nodes tagged with kerb=*. On TagInfo you can see that kerb:height=* is mostly used on nodes. --JeroenHoek (talk) 06:49, 17 August 2022 (UTC)

Yeah, that makes sense. I'll adopt this practice in my mapping. Thanks! --Waldyrious (talk) 11:43, 17 August 2022 (UTC)

I've added the fact that height=* is used more often on barrier=kerb ways and kerb:height=* on nodes to the Wiki page. Osmuser63783 (talk) 19:35, 25 March 2023 (UTC)

I'm confused about kerb=raised implying wheelchair=no

kerb=raised (>3 cm) description says: "When used on pedestrian paths it implies wheelchair=no"
wheelchair=limited description says: "has a step but not higher than 7 cm"
wheelchair=no description says: "has a step higher than 7 cm"

So kerb=raised can be both wheelchair=limited if between 3 and 7cm or wheelchair=no if >7, why is implied only wheelchair=no?
Or is to be read as: "when wheelchair=* is missing, imply the worst scenario"? --Ivanbranco (talk) 13:47, 29 April 2023 (UTC)

I think you're right, so you have to tag wheelchair=limited where this is the case. The rejected proposal for kerb=normal seemed to be for a higher kerb than 7cm, so wouldn't have resolved this. TrekClimbing (talk) 06:45, 26 November 2023 (UTC)

Truck apron kerb

The centre island of a roundabout usually has a "truck apron" which is a kind of rounded/sloped kerb. They are traversable, particularly by large trucks / large wheels. They provide a noticeable (you feel and often hear it) warning when wheels go up the kerb. I've been tagging these kerbs as kerb=truck_apron. Then I noticed similar kerbs are often used as guidance / protection / warning for outer sections of the roundabout area, and also for other road curvature, not only for trucks but for al kinds of wheeled traffic. Once you notice them, you keep seeing them everywhere, often combined with audible paving and even sloped concrete protection/guidance blocks. I think these kerbed road features are also called aprons, without "truck". Is it an idea to use kerb=apron for these protective kerbs? This value would imply wheelchair=no. --Peter Elderson (talk) 07:47, 8 May 2023 (UTC)