Streetcomplete: Kerb / Curb quest surface type and tactile plates for sidewalk data

[omgitsgela]

I am suggesting here two quests related to inclusive pedestrian mapping as defined in https://wiki.openstreetmap.org/wiki/Sidewalks. This has the potential to affect a large amount of kerb ramp data in a positive way.

General

1. Define what type of kerb interface a crosswalk has to a sidewalk
   Affected tag(s) to be modified/added: [kerb=] https://wiki.openstreetmap.org/wiki/Key:kerb
   Search for type=point ; barrier=kerb, which should define a single node on a highway= segment
   Ask "How high is this kerb ramp?"
   Answers: flat ; lowered ; raised

2. Ask if a kerb ramp has a tactile plate that would be used by the blind
   Affected tag(s) to be modified/added: tactile_paving=*
   Question asked: Does this kerb ramp have a tactile plate for the blind?
   Answers: yes ; no

Checklist

Checklist for quest suggestions (see guidelines):

• [X] 🚧 To be added tag is established and has a useful purpose
  Purpose is to enhance the inclusive pedestrian network tagging through revision of kerb ramp data to enhance overall accessibility for patrons requiring accessible infrastructure
• [X] 🤔 Any answer the user can give must have an equivalent tagging (Quest should not reappear to other users when solved by one)
  Tags are well defined for both quests proposed.
• [X] 🐿️ Easily answerable by everyone from the outside but a survey is necessary
  With the proper graphical elements in the displayed quest, this would be answerable by anyone.
• [X] 💤 Not an overwhelming percentage of elements have the same answer (No spam)
  These are roughly boolean options, and so many will have the same answer, but I wouldn't consider this spam, rather, completion of features that should be documented for proper routing.
• [X] 🕓 Applies to a reasonable number of elements (Worth the effort)
  Has the potential to improve a vast amount of kerb ramp data.

Ideas for implementation

We should use graphical depictions of the kerb ramp heights to show people what the different types are. There's very good graphics available on the Key:kerb page for each option.

We should also use a graphic to show a tactile plate, so people know what it is when asked.

[pkoby]

I like this idea, but there are some points that will probably need to be taken into consideration.

• tactile_paving=* is already a quest (often disabled, though; check settings), applied to the crossing node where a crosswalk meets a highway. The question asks if both sides of the crosswalk have tactile paving. Unfortunately, this means that one side may have it and the other not, and this is answered as =no. (The wiki page does not suggest this method, but does suggest doing it on the nodes of the sidewalk to crosswalk change: https://wiki.openstreetmap.org/wiki/Key:tactile_paving#Use_on_nodes.)

• Kerb height could be applied similarly, and in the iD editor is asked for crossing nodes as well. I would assume it would be asked similarly to the tactile_paving quest, where both sides would be the same. Of course, if the two ramps are different for one crossing node, I don't know how it would be answered.

• Kerb height could be applied to the nodes where the sidewalk meets the crosswalk lines if they are mapped in detail. I think this is the best way to place the data (and same for the tactile paving, if the sidewalk lines are mapped), but that's currently not how it's done in StreetComplete.

I think the kerb ramp quest ought to be applied only to the nodes of the sidewalk meeting the crosswalk, because unlike tactile paving, there is no =no option that you can apply to the crossing node. If the kerb heights differ, there is no tag that can state that for a single node (https://wiki.openstreetmap.org/wiki/Key:kerb). The wiki page suggests using the tag on the crossing node if they are the same on both sides, but SC can't really do one or the other. Ideally, both kerb height and tactile paving would be applied to the actual sidewalk lines, not the crossing junction. It's not important to know if there is tactile paving at a crosswalk for the road users (car drivers), so there's no reason to add these tags to the road node unless there isn't a sidewalk line. In my opinion, sidewalks should be mapped anyway, and tagging just a crossing node leaves room for improvement.

[omgitsgela]

Are you suggesting that the current StreetComplete quest about tactile_paving applies the tagging to the crosswalk line itself, and not the nodes? That doesn't actually match up with the best case practices for inclusive sidewalk mapping.

What we're doing is using a barrier=kerb node at the interface between the highway=crossing and the highway=footway, and specifically identifying the features of that crosswalk ramp discretely. If you assume data on both sides of the crosswalk is identical, you leave a lot of cases which become messed up, like a lowered curb on one side and a tactile plate equipped flush ramp on the other. Or where crosswalks span multiple nodes or connecting features.

My suggestion for these two quests is absolutely to apply them to the type=node, and definitely not to a way/line.

For your reference, take a look at this area of my town I've mapped: https://www.openstreetmap.org/edit#map=20/42.68770/-71.12140

And Nick Bolten's talk about best practices for distinct sidewalk mapping. https://www.youtube.com/watch?v=DHecYP_b3os

I like this idea, but there are some points that will probably need to be taken into consideration.

• tactile_paving=* is already a quest (often disabled, though; check settings), applied to the crossing node where a crosswalk meets a highway. The question asks if both sides of the crosswalk have tactile paving. Unfortunately, this means that one side may have it and the other not, and this is answered as =no. (The wiki page does not suggest this method, but does suggest doing it on the nodes of the sidewalk to crosswalk change: https://wiki.openstreetmap.org/wiki/Key:tactile_paving#Use_on_nodes.)
• Kerb height could be applied similarly, and in the iD editor is asked for crossing nodes as well. I would assume it would be asked similarly to the tactile_paving quest, where both sides would be the same. Of course, if the two ramps are different for one crossing node, I don't know how it would be answered.
• Kerb height could be applied to the nodes where the sidewalk meets the crosswalk lines if they are mapped in detail. I think this is the best way to place the data (and same for the tactile paving, if the sidewalk lines are mapped), but that's currently not how it's done in StreetComplete.

I think the kerb ramp quest ought to be applied only to the nodes of the sidewalk meeting the crosswalk, because unlike tactile paving, there is no =no option that you can apply to the crossing node. If the kerb heights differ, there is no tag that can state that for a single node (https://wiki.openstreetmap.org/wiki/Key:kerb). The wiki page suggests using the tag on the crossing node if they are the same on both sides, but SC can't really do one or the other. Ideally, both kerb height and tactile paving would be applied to the actual sidewalk lines, not the crossing junction. It's not important to know if there is tactile paving at a crosswalk for the road users (car drivers), so there's no reason to add these tags to the road node unless there isn't a sidewalk line. In my opinion, sidewalks should be mapped anyway, and tagging just a crossing node leaves room for improvement.

[pkoby]

No, I definitely don't think they should be applied to lines (except when there's tactile paving along a whole crosswalk, per the wiki). I think the tags should be applied to the actual location of the ramp/tactile plate, which would be the node connecting the crosswalk and sidewalk. Your example location is exactly how I would do it.

Currently, however, SC only poses the quest for tactile paving on the junction node of the crosswalk line and the road line (where in iD it's labeled Marked Crosswalk on the node). I don't like this format at all, because as you said, there are many cases where each side of the crossing is different.

So to sum up, I think your suggestion is excellent, I agree with all points, and ideally, SC would not ask the quest for the junction on the road, but at the edge of the sidewalk, where it matters to pedestrians.

Incidentally, other quests asked for the crossing node on the road include what type of crosswalk it is (marked, unmarked, etc.), whether there are sound signals for the blind, and whether there are buttons to change the light. I think all of these quests are fine on the road junction node.

[omgitsgela]

Oh, okay, I see what you were saying. Yeah, there's not really a good reason to apply tactile_plate at the junction between the crosswalk and the car roadway line. That's definitely not how it appears in the real world...

[pkoby]

I think the reasoning for how it is right now is that otherwise crossings without the actual line data for the sidewalk network would not have any information about tactile paving.

[goldfndr]

I don't think searching for barrier=kerb would be adequate, but here's an Overpass query for the interfaces between sidewalks and crosswalks:

[bbox:{{bbox}}];
way[highway][footway=sidewalk]->.w1;
way[highway][footway=crossing]->.w2;
node(w.w1)(w.w2);
out;

/* Add this for some coloring */
{{style:
node { color:red; fill-color:red; }
node[kerb] { color:green; fill-color:green; }
}}

[westnordost]

Why do you think that searching for barrier=kerb is not adequate?

I tried out your query and got this: http://overpass-turbo.eu/s/F0T
When searching for barrier=kerb, I think the probability that the interfaces are mapped correctly is somewhat bigger.

[pkoby]

Searching for barrier=kerb would probably not work right, because that tag is usually used on ways. So maybe you'd search for the nodes that intersect a way tagged with barrier=kerb? This depends on these barriers being mapped, which I don't think is likely in many cases. Querying for the interface between crossing and sidewalk should find the correct points where the kerb ramp would actually be.

Either (any) option relies on previously correct mapping in some form or another. The crosswalk tag could be left off, and the quest wouldn't find those nodes. The kerb barrier might not be mapped. Or the crossing way might be in the wrong spot. But based on some quick spot checks in Overpass, the query goldfndr posted seems most promising.

[westnordost]

My point was that with @goldfndr query + asserting that the found nodes must have barrier=kerb tagged would lower the probability to run into cases like the one linked by me somewhat because if the barrier=kerb tag is present, it denotes that someone already prepared the data in a way that is compatible to kerb-mapping.
I mean, the spot I linked, is it really plain a mistake or just not mapped so much in detail than it would need to be to enable proper kerb-mapping?

[pkoby]

By my understanding of the wiki, barrier=kerb is not usually used for tagging nodes, and certainly not in the kerb-ramp situation. The page for kerb=* only mentions barrier=kerb as a "see also" and as an open issue to use kerb=* as a sub-tag for barrier=kerb (but this isn't mentioned in the discussion or anywhere else on this page). The page for barrier=kerb doesn't mention kerb=* at all.

I think in practice, a barrier=kerb line will probably coincide with the kerb=* node at the interface between footway=sidewalk and footway=crossing, but the former is not necessary for the latter. It's just probable that a kerb along the edge of the road will have crossings at certain points (sometimes with kerb cuts), and vice versa a kerb cut will probably be on a kerb line.

[ViolaineDo]

Searching for barrier=kerb would probably not work right, because that tag is usually used on ways. So maybe you'd search for the nodes that intersect a way tagged with barrier=kerb? This depends on these barriers being mapped, which I don't think is likely in many cases. Querying for the interface between crossing and sidewalk _should_ find the correct points where the kerb ramp would actually be.

Either (any) option relies on previously correct mapping in some form or another. The crosswalk tag could be left off, and the quest wouldn't find those nodes. The kerb barrier might not be mapped. Or the crossing way might be in the wrong spot. But based on some quick spot checks in Overpass, the query goldfndr posted seems most promising.

Hi, Just joining this discussion, I am not sure what was the conclusion of this discussion so here is my 2 cents.. I too think this quest (about kerb) would be super interesting to implement.
I am wondering if that would be the best thing to query intersection footway=crossing / footway=sidewalk as I don't think those would be always mapped properly. Here is an example of the kind of mistake I see, which can be quite recurrent if people don't think about tactile_paving or kerbs... https://overpass-turbo.eu/s/IAL
If a kerb was mapped here we would wonder if there is a kerb on the sidewalk near the crossing, or is there a kerb between the sidewalk and the crossing.
So I would query intersection between footway=crossing/footway=sidewalk and with tag barrier=kerb. Indeed people would need to prepare it but else I think it would lead to many mistakes...
Hope I am helping,
Violaine

[westnordost]

I read through this issue again, summarizing the discussion, the type of kerb should probably be asked on the following nodes:

1. on all nodes tagged as barrier=kerb - to catch the case where it is mapped as a node
   
2. on nodes that are at the intersection between a barrier=kerb way and a footway - to catch the case where a footway crosses a kerb line
   
3. on nodes that are each the end-points of two footways, one of them having the tag footway=sidewalk and the other footway=crossing
   
   Not this one unfortunately, because in many places, crossings are mapped like this, which would add the kerb into the middle of the sidewalk then:
   

On topic of the tactile paving, this can be implemented quite easily.

[matkoniecz]

way["barrier"="kerb"]({{bbox}});
node(w)->.kerb_way_nodes;
way["highway"~"^footway|path|cycleway"]({{bbox}});
node(w)->.footway_way_nodes;
node.kerb_way_nodes.footway_way_nodes;
out;
node.footway_way_nodes["barrier"="kerb"];
out;

[matkoniecz]

Answers: flat ; lowered ; raised

I would include raised, lowered, flush. rolled seems really rare.

[matkoniecz]

raised https://wiki.openstreetmap.org/wiki/File:Kerb.jpg (maybe https://wiki.openstreetmap.org/wiki/File:Kerb_regular_Okerstra%C3%9Fe_Lichtenrader_Stra%C3%9Fe_Berlin.jpg )

lowered https://wiki.openstreetmap.org/wiki/File:Dropped_kerb.jpg

missing! Photo with lowered curb without ramp. (also for lowered)

missing: decent photo for flush curb

Hopefully someone will manage to find good picture (frontal view from street) or there will be at least one day with a good light this Autumn in Kraków and I will be able to take a photo.

[westnordost]

raised

better a picture of a concrete curb, stone is really rare and might be confusing. Or, maybe better an icon that just shows the profile?

[matkoniecz]

Or, maybe better an icon that just shows the profile?

I am not entirely sure whatever profile icon would be clear to people - technical and semi technical drawing are surprisingly often not understood by people.

[westnordost]

mh ok

[alesarrett]

Hi all,
sorry for joining this discussion late, but I have a couple of general remarks.
I've mapped a lot of kerbs in Padua for the local Plan for elimination of architectural barriers (here's the poster at the SOTM 2019: https://doi.org/10.5281/zenodo.3370705) and I have two main points:

• in the wiki (https://wiki.openstreetmap.org/wiki/Key:kerb) I didn't find any explicit requirement or even suggestion to use kerb=* as a subtag of barrier=kerb for nodes. So the main search should be in my opinion on nodes with kerb=* and not only on barrier=kerb
• I think there is no reference neither of kerb ramps, so the questions should be on the kerb itself, not the ramp, because the is no common documented way to tag kerb ramps so far. I do agree that we should define better how to map kerb ramps, anyway

[matkoniecz]

So the main search should be in my opinion on nodes with kerb=* and not only on barrier=kerb

Adding resurvey of old kerb=* may be a good idea.

I think there is no reference neither of kerb ramps, so the questions should be on the kerb itself, not the ramp, because the is no common documented way to tag kerb ramps so far.

See https://wiki.openstreetmap.org/wiki/Key:kerb - photo example for lowered value.

[alesarrett]

So the main search should be in my opinion on nodes with kerb=* and not only on barrier=kerb

Adding resurvey of old kerb=* may be a good idea.
Do you mean that all kerb=* should be mapped also with a barrier=kerb?

I think there is no reference neither of kerb ramps, so the questions should be on the kerb itself, not the ramp, because the is no common documented way to tag kerb ramps so far.

See https://wiki.openstreetmap.org/wiki/Key:kerb - photo example for lowered value.

This is really confusing to me.
The whole distinction among raised, lowered and flush kerbs is about height and not the fact that that there is a ramp or not. There are kerbs with ramps that have a height at the connection of sidewalk/crossing that is >3cm, and those are raised kerbs. There are kerbs with just a few centimetres height (0-3) without a ramp, and they still are lowered.
And to me also that image about lowered value is confusing, because in fact it seems to be a flush kerb (~0 cm height) with a ramp.
It seems to me that we are missing a way to correctly tag height of kerbs and presence/absence of ramps at the intersections
between sidewalks and crossings. Might a discussion on this in the mailing list be useful?

[matkoniecz]

Maybe. In this case I see this ramp as being a kerb ("dropped kerb") - https://wiki.openstreetmap.org/wiki/File:Dropped_kerb.jpg

And it is still a bit of a barrier due to its slope. Mixing "kerb but low" and "kerb ramp reaches road surface but is quite step" in kerb=lowered may be not ideal and may be worth distinguishing, but I am not aware about any existing tagging (and SC would not invent a new tagging).

If anyone is interested in proposing new tagging for distinguishing "dropped kerb" and "low kerb but still not 0" then, once such tagging would be accepted (via accepted proposal or by some minor but noticeable use and being documented at wiki) I would gladly use it.

Also, if Wiki is wrong then it should be fixed, but from what I see that tagging practice is accepted.

[matkoniecz]

I will need to look at it a bit more, but it seems that this quest will be the first to add tags to OSM objects that had no tags before the SC edit :)

2020-10-18 22:52:09.935 7417-7417/de.westnordost.streetcomplete.debug E/AndroidRuntime: FATAL EXCEPTION: main
    Process: de.westnordost.streetcomplete.debug, PID: 7417
    java.lang.NullPointerException: element.tags must not be null
        at de.westnordost.streetcomplete.data.quest.QuestController.createOsmQuestChanges(QuestController.kt:154)
        at de.westnordost.streetcomplete.data.quest.QuestController.solveOsmQuest(QuestController.kt:133)
        at de.westnordost.streetcomplete.data.quest.QuestController.solve(QuestController.kt:90)
        at de.westnordost.streetcomplete.map.MainFragment$onAnsweredQuest$1.invoke(MainFragment.kt:326)
        at de.westnordost.streetcomplete.map.MainFragment$onAnsweredQuest$1.invoke(MainFragment.kt:76)
        at de.westnordost.streetcomplete.map.QuestSourceIsSurveyChecker$assureIsSurvey$1.onClick(QuestSourceIsSurveyChecker.kt:41)
        at androidx.appcompat.app.AlertController$ButtonHandler.handleMessage(AlertController.java:167)
        at android.os.Handler.dispatchMessage(Handler.java:107)
        at android.os.Looper.loop(Looper.java:214)
        at android.app.ActivityThread.main(ActivityThread.java:7356)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:930)

[westnordost]

Dang!

I fixed it