Hmm I see… barrier=kerb is already used more often on nodes than on ways (almost 600,000 times!). And the original proposal said it applies to nodes and ways. So I would have thought the use on nodes was already approved 12 years ago… just never documented on the Wiki
I don’t have the energy at the moment for a proposal to deprecate standalone kerb=*. I’ve probably already spent more time on kerb tagging than I should have so I’m happy as long as the Wiki accurately documents current usage. But I’d help if someone wanted to propose that, of course
I agree, it’s wrong to add barrier=kerb indiscriminately. I suppose the rationale for deprecation would be that standalone kerb=* is ambiguous. If, and only if, there’s a kerb on the way, it is clearer to add barrier=kerb, but if there isn’t, and there’s a just a kerb on each side of the road, and then some new tag like sidewalk:both:kerb=* would be better, to prevent people from wrongly adding barrier=kerb.
Anyway, I have no plans to deprecate anything and I’ve finished my edits to the wiki page unless there are further comments or complaints.
I feel sidewalk::kerb= is a good way to describe the regular kerb used by a section of sidewalk i.e. =raised for standard concrete sidewalk, =rolled for vehicle parking.
For crossings I just use the kerb=* indicate the kerb type at the crossing, especially when it is different from the sidewalk value. In particular I usually tag on the node shared by the sidewalk and crossing ways. I then try to place the transitional node as close to the actual kerb as possible. This is the most effective way layout where the sidewalk becomes a crossing and vise versa.
I will usually place the node on top of a tactile_paving as it reduces the number of nodes and supports those with accessibility by matching sensory aids with the crossing.
I just read this thread and looked at the wiki changes (sorry, I am a little late, I know). It’s really a valuable improvement that I really appreciate! And I can understand that you don’t want to start a proposal regarding the use of the kerb tag. Perhaps someone else has some energy to do that.
For a long time (in Germany) I am tagging crossings and kerb nodes on crossing footways and barrier=kerb ways exactly in the way as you describe it in the wiki now.
I also agree with all the changes, only one detail I would not have worded that way, it concerns the case of kerb=* on a highway=crossing node, if there are also nodes with barrier=kerb + kerb=* at the exact places of the kerb (mostly on a footway=crossing): I would not remove kerb=* on the crossing node, and I wouldn’t be afraid that a router might suspect 4 kerbs here – I think it would then be a fault of the router, because kerb=* on a highway=crossing node only means that there are kerbs to the left and right of it – which in this case are given exactly at their real position, so all the better for the router.
In summary: why should kerb=* hurt on the highway=crossing node? It might be a bit superfluous/redundant because more precise tagging has taken place, but it’s also just a descriptive property of the crossing.
And I still have 3 ideas for wording that could perhaps be added to the wiki texts as a supplement:
With highway=crossing nodes it can happen that different kerb types appear on the left and right of the transition. In that case, it may be necessary to use kerb:right=* and kerb:left=* instead of onekerb=* tag. E.g. kerb:left=flush + kerb:right=lowered. Not sure if this is mentioned anywhere (I’ve been using it for a while).
A good reminder, in my opinion, could be that barrier=kerb (with or without kerb=*, preferably with) should always be used at the exact position of a kerb – and that this is probably the most precise (micro)tagging. This then automatically rules out e.g. setting barrier=kerb + kerb=raised on a highway=residential node or other cases of incorrect tagging. And it also includes the (perhaps rare) cases of barrier=kerb + kerb=lowered on a node of highway=residential (or living_street or service or other) and other cases. And vice versa, it indicates that a node tagged only with kerb=* is either not in the exact position of the kerb, or that a barrier=kerb tag is missing …
In all cases of kerb tagging for crossings, I find it a good practice if tactile_paving=* is also tagged for completion, e.g. for routing for disabled persons, for whom kerb tagging can often be valuable. I.e. especially on kerb nodes at the exact position, because that’s where it’s most valuable for routers for precise output. At the moment, I think it’s only mentioned with kerb=flush. But I also find it valuable as information for other kerb values, also in the form tactile_paving=no, which can be a warning for the blind.
A final note on the practice of StreetComplete and kerb=raised (without barrier=kerb) on highway nodes where no real crossing exists, but perhaps a footway line meets the highway: I don’t find this a very happy solution, although it doesn’t really hurt. The interpretation is at least the same as kerb=* on a highway=crossing node. But I would then find it much better to set a node with barrier=kerb + kerb=raised again at the exact position of the kerb or to ask for it. And in this case I wouldn’t tag kerb=raised on the node of e.g. highway=residential (as in the case of a highway=crossing node), because it seems (for me) like an element with no “mother (or father) element”, like an orphaned child, to stay with the figurative language. It feels like a stopgap that might also be confusing for some mappers (and could result in incorrect additions). And it potentially makes it harder for validators to define appropriate rules. It’s an exception that complicates the kerb issue.
To be honest, me neither. As far as I remember, it was the result of a compromise because some people objected to the use of crossing=no for these cases because they understand that it means it is forbidden to cross.
The current wording in the wiki (without having checked when and why it was last modified) is
crossing=no: Where definitely no crossing is possible/legal. Used at places where one would expect a crossing, but where there isn’t one. As crossing=no excludes the existence of a crossing, it must be used withouthighway=crossing
Sentence two is what we want to indicate, but sentence one postulates that it should only used when it is not possible, which is a pretty strong wording.
I often use this when mapping sidewalks as separate ways and connecting them over a street, even if there’s no lowered kerb. It doesn’t happen often, but there’s still “crossings” like this.
Just trying to understand if there’s a better solution than the current one
Soooo, in summary for myself, when having just ‘normal’ kerbs at the ends of a crossing or at the side of a bus stop, barrier=kerb should suffice without any kerb=* qualifier.
There’s of course this traffic_island=* when not flush with street or having sloped kerbs, I’ve always given them the =raised value.
The term ‘raised’ might need national understanding as here the sidewalks generally have kerbs that are so high as to prevent half_on_kerb parking, bollards not really needed for prevention, the wheel rims could get damaged if approaching them with vigour. Many are of hollow concrete, often have collapsed after too many car encounters. ‘raised’ with tactile I’ve only seen at the constructed, but never put in use trolley way, 6km and 50 million Euro.
Because crossing=unmarked is used on highway=crossing and (some) people are of the opinion that it should only be used in places where there is an actual crossing (that is unmarked). For example, I came across this a few days ago: Node: 602288120 | OpenStreetMap
It seems to be even be part of some kind of walking route relation. You can cross there and the trodden down grass between the car and the tree displays that people also regularly do, but it is definitely not a crossing - even if the kerb at least on one side is lowered.
Yes, in U.S. suburbs, rolled curbs are almost exclusively found along the sides of residential roads where driveways meet the road at a regular interval. It’s cheaper to build a uniform rolled curb than a curb cut and curb ramp for each driveway. I add a barrier=kerbkerb=rolled node to the driveway because sometimes the driveway is the only connection for pedestrians near an intersection, but the rolled curb can be challenging to a wheelchair, baby stroller, or tricycle. (A tall enough curb can also cause a car with a low suspension to bottom out.) Occasionally, there can even be a rolled curb across a residential street, though normally in my area, that would identify the roadway as a shared driveway rather than a public street.
By the way, the tactile_paving=* documentation says this key on a crossing way means the whole crossing is tactile all the way across, not that there’s tactile paving at the curb ramp on either end. This nuance has been surprising a lot of mappers who have become accustomed to redundantly tagging crossing details on both a node and a way.
This is also a bug in OSRM, apparently specific to kerb=rolled. A curb cut (what is meant by barrier=kerb on a node) should generally be traversible by car at low speed. A car with a low suspension would risk bottoming out, but the correct behavior in that case would be to penalize the barrier, not avoid it entirely.
Interesting! Looking at the wiki page for tactile_paving, it says that
Use on ways
On a pedestrian crossing highway=crossing, when the tactile paving is used in a line all across the crossing. Do not use tactile_paving=*
There’s no such thing as a highway=crossing way. I’m guessing that should be footway=crossing?
There are over a million usages of highway=crossing on nodes and I doubt that in all of these cases the car drives over the tactile paving. This should probably be documented on that page?
I’m unsure; if so, then it’s redundant to the next bullet point.
Not quite, I think the page is trying to draw this distinction:
tactile_paving=* on a highway=crossing node: there is tactile paving on the curb cut at either end of this crossing, which may or may not be mapped.
tactile_paving=* on a highway=footwayfootway=crossing way: there is tactile paving all along the crossing.
What’s confusing is that the highway=crossing node would also be present in conjunction with the highway=footwayfootway=crossing way. Even though you’d normally use the same secondary tags on both features (crossing=* etc.), you wouldn’t want to copy the tactile_paving=* tag from one to the other, because that would change the meaning.
I don’t really understand what the problem is (and what is confusing). I tagged a lot of crossings and also ways (footways) with tactile_paving=* and tried to take care of the different meanings of the tag. I’m not very confused, although some crossings can be confusing.
If there is a crossing footway line over a crossing (with a tactile_paving tag), then there will also be tactile_paving at the kerbs (normally in perpendicular direction to the tactile paving on the way). I never saw a case where it wasn’t. It wouldn’t make much sense.
So why shouldn’t there be the tag both on the crossing node AND the way (if it is correct for both objects)? What changes the meaning?
If the wiki says, a tactile_paving tag on a crossing node means: only tactile_paving at the kerbs, then is time to change this wording … I would read it as: yes, there is tactile_paving at the kerbs (which is the beginning and the end of the crossing and the most important position for blind persons) and maybe or not on the way over the crossing (this is less important and should better be tagged on the footway line anyway – and it is rather a rare case in my experience, but it can be different in other places of the world).
I hope, my English is good enough to express what I mean … By the way: it would help if the words “curb” and “kerb” wouldn’t be mixed in the discussion. I know, it’s AE vs BE, but it’s confusing for non-native language users like me … It would be easier if the OpenStreetMap terms would be used. Thank you!
The wiki is saying tactile_paving on the highway=footway way means there’s a continuous strip of tactile paving laid out linearly across the street from one side to the other:
But mappers in some regions have never seen something like this before. All they’re familiar with is tactile paving only at the curb ramps (barrier=kerb):
Other keys like crossing=* and crossing:island=* say the same thing about the crossing whether tagged on the way, node, or both. The corresponding editor fields look the same on both the way preset and node preset, so the mapper has no awareness that tactile_paving=* refers to tactile paving at different locations depending on the feature it’s tagged on.
Well, it might be confusing if you’ve never talked to people using them, I agree, but it’s really simple:
On a node, it means: warning, dangerous spot
On a way, it’s used to guide along the way
The only exception seems to be bus stops mapped as nodes, where the meaning changes to “the bus station has tactile paving”, which automatically includes attention ripples and guiding lanes.
Mapping kerb=* and tactile_paving=* on a highway=crossing if the crossing footway/path is mapped as a separate way is kinda moot anyway, because you can map these at their proper location instead of the simplified highway=crossing node. Having the data redundant isn’t really helpful, I find it confusing at best.
If I map a crossing with separated ways, it just doesn’t make sense to me to put anything but the attributes that are of interest to both ways on the crossing nodes. And I wouldn’t do so, if SC wasn’t going to ask about them later anyway, and I don’t want to risk that people add wrong data
I agree that this data isn’t so useful on the cross node when the crossing is mapped as both a node and a way. I don’t personally add these tags to crossings for this reason. However, there’s nothing stopping someone from coming upon a crossing node and adding a crossing way and barrier=kerb nodes without removing the kerb and tactile_paving tags from the crossing node.
If the tagging scheme is reasonable, then there’s still a usability issue in editor presets that make the fields look like they mean exactly the same thing regardless of the feature they’re on. There’s no visually intuitive distinction between a field about what’s throughout the crossing versus what’s on either side of the crossing. This isn’t a problem when the crossing is only mapped as a way or only as a node, but it is a problem when it’s mapped as both.
It isn’t merely my opinion that it’s confusing. Consider that in the U.S., this linear form of tactile paving is nonstandard for crossings and only installed along “accessible paths” at train stations. Yet currently tactile_paving=* appears on 50,831 ways, including 40,921 footway=crossing ways, compared to the 74,175 occurrences on highway=crossing nodes. (Note that not every crossing node has been redundantly mapped as a crossing way.) That’s a lot of nonstandard crossings that could probably get local authorities sued under the Americans with Disabilities Act! More likely, this is evidence of the confusion and surprise that I’ve seen every time I point out this nuance to mappers.
But aren’t you describing an editor issue? It depend on how the presets for the editor are defined if you have a good, clear and flexible display or a confusing one.
And it may depend on the editor you are using – which one do you mean for example? Did you write it somewhere?
If it’s confusing for you, you could perhaps modify the presets in a way which is more clear and more precise for you. I chose to do that in some cases instead of waiting for years until this is made by the developers (e.g. for Vespucci or JOSM) or requests for changes and optimizations will not be processed further. In my experience, such GUI changes are often not taken seriously (but they could be very helpful).
Yes, I know what you mean and I am aware of the tagging of tactile_paving on a highway=footway. It’s quite clear in the Wiki, I think, and also quite logic. A tag on a node which is a simple form of tagging a physical larger object has to means something (more or less) different than a tag on a way (or it can have a slightly different meaning).
But as I wrote in my post before these 2 photos: tactile_paving=yes on a crossing should mean, that there is a helpful tavtile_paving which help blind people to use the crossing securely. For this purpose, it has to be at least at the kerb position (in my understanding). And this is covered by the wiki. The definition should not rule out the possibility of further tactile pavement (like here on the crossing path).
If it is really ruled out (or unclear), the text should be changed in my opinion.
Or a new subtag should be defined, if you want to tag the position/existence of tactile_paving on a crossing node more precise, e.g. tactile_paving:position=on_kerb_only|on_crossing_way with the possibility of multiple values (but I wouldn’t do that; it’s enough for me as it is).
A last note: a crossing node may also describe a crossing with a crossing island (crossing:island=yes) and there could be a tactile paving along the way on the island (not only on the kerbs) – in my experience, this is even more common than the case in your first photo, specially on more complex islands. So there should also be something like tactile_paving:position=on_island, if you wanted to use such a key.
so I’m happy as long as the Wiki accurately documents current usage. But I’d help if someone wanted to propose that, of course
And I can understand that you don’t want to start a proposal regarding the use of the kerb tag. Perhaps someone else has some energy to do that.
