Proposed edit of some `barrier=kerb kerb=raised` nodes

Hi,
still there are 550 cases barrier=kerb + kerb=no…

Funny, maybe they are kerb=flush. Would have to be surveyed me thinketh.

kerb=no is a valid kerb=* value meant for places where a kerb may seem present (on aerial photography) but isn’t. It’s similar to oneway=no: a tag useful in cases where the situation isn’t directly clear, but which are tagged correctly.

kerb=flush means that there is some (minor) detectable transition; kerb=no means there is none at all.

If kerb=* used on nodes not also tagged as highway=crossing should be tagged with barrier=kerb, and kerb=* there treated as a sub-key, than that goes for all six kerb=* values. no, flush, and lowered all interrupt the actual kerb, so singling out kerb=no as the one value which shouldn’t be treated as a subkey of barrier=kerb is inconsistent.

This is one of the drawbacks of making barrier=kerb a requirement for these nodes; best keep barrier=kerb for linear ways marking the physical kerb and leave kerb=* on nodes as a standalone attribute for indicating the accessibility aspects of the ways crossing the kerb.

If you have questions about the way something is tagged, ask the mapper. Don’t just open a note on the map without linking to the relevant discussion. I just happened upon it today, but you could have just looked at the edit history and have mentioned me here directly.

1 Like

Relevant StreetComplete issue: `barrier`=`kerb` should be removed instead of adding `kerb`=`no` · Issue #3983 · streetcomplete/StreetComplete · GitHub

SC has a quest where it asks users “what is the height of this kerb?” for nodes tagged barrier=kerb without a kerb= tag. If the user answers “there is no kerb”, the app used to just add kerb=no. Then someone complained and they changed it, now it also removes the barrier=kerb.

Many barrier=kerb kerb=no nodes were probably created this way by StreetComplete, before this change.

1 Like

I don’t think I can agree to that. barrier=kerb + kerb=no is classic troll-tagging. “There is a kerb at this location. Oh, haha, never mind, there is none”. There’s a difference between saying “The pedestrian crossing doesn’t have any kerbs you have to cross, so it’s exceptionally wheelchair-friendly” and “At these locations, there are no kerbs”. We’re also not tagging non-existing bins or baskets at the location where one might expect them. I think you have to apply some common sense before blindly using any kerb=* value on barrier=kerb. I rather think it’s similar to crossing=no, which explicitly states not to add it to highway=crossing-nodes. Maybe the same should be done for kerbs.

This argument is moot, because you simply cannot tell the height of a kerb from aerial imagery. Even the sheer existence is hard to tell most of the time. But the height? Or are people just adding barrier=kerb and waiting for the surveyor to add the height? I don’t really see the point here. If you’re unsure of the existence, don’t map it :person_shrugging:

But since you’re quoting the wiki, let me do that as well :wink:

If the highway doesn’t cross the kerb, don’t map a barrier=kerb on a node.

1 Like

Or consistent use of a sub-key.

I’m sorry to hear you can’t. In the Netherlands there is a standard type of kerb=lowered outlined in white on standard height sidewalks which can be recognized quite clearly from the 8 cm aerial photography Dutch mappers have available.

I don’t map these unless I am sure there is (or isn’t) a kerb transition. Please don’t imply that I do.

That is a shame, because the six core values alone already are invaluable. kerb=lowered|flush|no implies wheelchair accessibility, kerb=raised doesn’t. Being able to route around those leads to better navigation. Getting those mapped correctly in any large city is a huge task, adding height simple pushes it into the impossible. height is great for exceptional cases, but not required for kerb=* to be useful.

If you feel that kerb=no should not have barrier=kerb, fine: go ahead and edit. But don’t assume that it is used in ignorance.

kerb=no shows other mappers that a place where a kerb is expected or apparent really doesn’t have one. In low-barrier modern bus stations this is common, where platforms may be raised, but pedestrian areas around the busways where travellers cross to aren’t, despite having a very visible surface transition. Other common places are streets which do have raised sidewalks, but where the street surface rises to the same level at certain crossings to slow traffic and allow for barrier-free pedestrian use at the same time.

With kerb=no other mappers can see that the area is fully mapped, and no survey is needed if the aerial photography doesn’t show any discrepancies.

I don’t think it’s a good idea to use a regular key to map meta(survey)-information.

This is not about “consistent” use, when it has different meaning. kerb= can be used as an intrinsic attribute for barrier=kerb, or an accompanying attribute for other features. kerb=no is not valid on barrier=kerb at all. Cf crossing=no not used on highway=crossing alongside.

1 Like

Than make a proposal for a different key; kerb=no is well established. As a separate key without the barrier=kerb parentage you would want something like nokerb=yes (like noname=yes).

The recent set of wiki edits which where broadly discussed here document this use. The wiki now explicitly suggests adding barrier=kerb when kerb=* is not used as a property of another feature (like highway=crossing) to avoid confusion with that type of use. Using kerb=* by itself on a way to mark a transition also gets highlighted by ID as missing barrier=kerb. So either kerb=* is a subkey when used on its own, or it isn’t.

Any data consumer using just barrier=kerb on a node without looking at kerb=* to derive accessibility information will fail, because kerb=lowered, kerb=flush, and kerb=no all imply wheelchair=yes. If you want a semantically clean use of barrier=kerb you would have to disallow all three of those in combination (i.e., if you can cross them with a wheelchair, it is not a barrier). This would just make things more complicated.

It’s the same with highway=crossing and the crossing=*-subtag. You don’t put crossing=no on a highway=crossing, because there is no crossing. Tagging the absence of an expected feature is one thing, but we don’t tag the location where it isn’t. Exceptions like was:building=* are only used for some time until no maps show the demolished building any more, and later on it’s deleted.

We do when the feature is otherwise expected there; like oneway=no on bits of way which need that for routing. But kerb=no does not just map the absence of a detectable kerb, it maps that a transition of one surface to another (where a kerb is visually expected) is in fact smooth and without barriers. Compare this with other accessibility features like handrail=no, ramp=no, or sidewalk=no: it explicitly tags their absence, preventing other mappers from having to redo your analysis if they are not completely re-evaluating an area but are filling gaps, and it informs data consumers interested in such accessibility features about the details.

If a crossing has eight transitions from street to sidewalk, and two of those lack any discernable transition in height, it makes sense to map all eight of them (six perhaps with kerb=lowered, the remaining two with kerb=no). At the least it stops others from wasting time concluding that the missing two are completely flat over and over.

That would be okay for me.

For me, I don’t find having a no*=yes for every attribute a nice solution. crossing=no has been used equally well. No need to change kerb=no for no significant benefit.

3 Likes

Seems Osmose, preemptive sorry, still thinks that StreetComplete is doing it. Here an unmarked crossing mapped as line connecting with a sidewalk.

image

edit: a mapper has been doing the SC round along town and caused quite a few of these flags to pop up where crossings mapped as lines connect to sidewalks. Why pedestrians are deemed not able to step over these curbs, lord knows considering there’s no bicycle tagging on these footways.

image

There are still some routing errors but not so many on major streets.

If OSRM is considered the ‘house’ router, there’s work to do. Was testing a cycleway route few days ago, GraphHopper and OSRM were fine for that one, Valhalla was sending the bike down the main road. GraphHopper is not very good in ATL/ZTL areas where OSRM routes fine. Don’t know which Osmose uses as testing reference.

I thinks Osmose correctly warns there. Those nodes are positioned when one highway=* meets another highway=*. So such tagging would indicate that both highway=footway ways are blocked by that kerb, when it practice, that is almost never the case (usually only the one that crosses the road is blocked by kerb).

I’ve added clarification to wiki.

In other words, StreetComplete user correctly answered StreetComplete question “whether kerbs have tactile paving” in Changeset: 136381823 | OpenStreetMap; but the users before them failed to place that barrier=kerb at correct place, and Osmose complains about that previous error.

The correct solution is to place those kerbs at positions where they actually are - which is not at a node joining the two footways, but on extra node which is on one footway, at position just where it starts to cross to road in physical world (which is not where a highway=footway intersects highway=tertiary either) - e.g. see what I did for that example in Changeset: 139172410 | OpenStreetMap

Why pedestrians are deemed not able to step over these curbs, lord knows considering there’s no bicycle tagging on these footways.

There also exist users in wheelchair (and other classes of pedestrians), for whom such kerb information is of very high importance (much higher then for most bicycle users, in fact - and I say that as a bicycle user. For them, that 9cm kerb might as well be 3m concrete wall with barbed wire at the top, while cyclist can at worst dismount and push over it, or even just hop-on it)

2 Likes