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):

• 🚧 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
• 🤔 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.
• 🐿️ 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.
• 💤 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.
• 🕓 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
   
   But not ine these situations:
   

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

[LorenzoStucchi]

In your last picture, I understand the northernmost kerb was added by StreetComplete?

Yes, the top kerb and the bottom kerb.

Why does the sidewalk-footway not continue east?

The mapper stops its mapping, there is not another specific reason for the interruption.

Also, why is the footway in between the two nothernmost kerbs tagged with footway=crossing?

This is the schema decided, the part between the kerb and the sidewalks is part of the crossing. Here an example image inserted in the wiki, with the colours that shows the crossings and the sidewalks.

[matkoniecz]

Here original tagging was inconsistent, with middle segment tagged as sidewalk.

It seems to me that either there should be no footway=sidewalk here at all or that it should start at kerb. Is it really considered as correct to map that way?

[matkoniecz]

The mapper stops its mapping, there is not another specific reason for the interruption.

Yes, that is case mentioned in #1305 (comment) (incomplete mapping) with added bonus of defining that crossing doe not end on kerb and mapping that kerb - despite not mapping sidewalk connection to East/North.

[matkoniecz]

I found it in different points, I correct some of them. This is an example that I kept, the way in OSM, PeWu way, PeWu node.

And thanks for link, now I understand what happened. Not sure yet what should be done with that.

[LorenzoStucchi]

The mapping was consistent as explained in the wiki about the project following the different rules of mapping.
The middle part with the tag footway=sidewalk could be contested, but it represents an area where the user could stop while walking.
This is the tagging used in Italy in different projects.

I don't know if the way this is mapped is as defined as:

Yes, that is case mentioned in #1305 (comment) (incomplete mapping) with added bonus of defining that crossing doe not end on kerb and mapping that kerb - despite not mapping sidewalk connection to East/North.

But I believe that it is not correct that the app adds new nodes with the attributes of the kerbs where these elements are already existing. For me, it should check if other nodes in the crossing have the attributes kerb and add the tag to it.

[matkoniecz]

But I believe that it is not correct that the app adds new nodes with the attributes of the kerbs where these elements are already existing. For me, it should check if other nodes in the crossing have the attributes kerb and add the tag to it.

Checking tags of given node is easy, checking tags and count of attached ways is doable, checking tags on nodes of nearby ways is hard to do.

[LorenzoStucchi]

But I believe that it is not correct that the app adds new nodes with the attributes of the kerbs where these elements are already existing. For me, it should check if other nodes in the crossing have the attributes kerb and add the tag to it.

Checking tags of given node is easy, checking tags and count of attached ways is doable, checking tags on nodes of nearby ways is hard to do.

Not nearby, but nodes in the same way of the crossing. Is this not just recursion?
How it is checked if the tags are not already in an existing node? It is not just the same issue, before proposing the quest to verify the presence of other nodes with the tags in the same way with the tag highway=crossing.

[matkoniecz]

Not nearby, but nodes in the same way of the crossing.

If it is OK to fail on split ways - yes.

How it is checked if the tags are not already in an existing node?

https://github.com/streetcomplete/StreetComplete/blob/master/app/src/main/java/de/westnordost/streetcomplete/quests/kerb_height/AddKerbHeight.kt#L15 but most of checks is in https://github.com/streetcomplete/StreetComplete/blob/master/app/src/main/java/de/westnordost/streetcomplete/quests/kerb_height/KerbUtil.kt

[matkoniecz]

Not nearby, but nodes in the same way of the crossing.

Also, that would break asking for kerb info if one if two kerbs on crossing is mapped already.

[westnordost]

I read up on this thread and came to the conclusion that I think nothing needs to be changed in StreetComplete.

I'll explain why

So it seems, that both

(a)

and

(b)

are accepted / in use schemes to tag a crossing with kerbs. Option (b) with either a single way that connects the two sidewalks or several connected highway=crossing ways. You would want several connected ways as part of the crossing to correctly map the surface tag of for the crossing: The part of the crossing that is still on the sidewalk would be surface=paving_stones, the "real" part of the crossing would be surface=asphalt (usually).

StreetComplete asks mainly for kerb properties for nodes that are either

1. ...already tagged with barrier=kerb, or...
2. ...are the intersection point of a barrier=kerb line with a highway=footway

Additionally, it detects situations where an implicit kerb can be assumed, but only if the crossing is mapped like in situation (a). It specifically excludes situation (b) as to not set a kerb on the intersection between the sidewalk and the crossing, because of the reasons you explained. It ensures that by checking that an implicit kerb can only ever be assumed at the end node of a highway=footway + footway=crossing that connects to exactly one highway=footway + footway=sidewalk, i.e. is a continuation of the crossing and not an intersection of that crossing.
This means that if your community tags kerbs at intersections that way (like (b)), the app will not find if there is a kerb unless you always tag barrier=kerb there.

The situation as depicted here

only comes to pass because the app wrongfully interprets the sidewalk mapped at the top to be the continuation of the crossing that leads to the proper part of the sidewalk. Why? Because the mapping of the intersection is incomplete.

One can use the sidewalk=left/right/both/no scheme to map sidewalks and one can do the more precise scheme with separately mapped sidewalks like done here, both are considered "OK". However, one can not expect that any data consumer (this app is a data consumer in this regard) will interpret the data correctly if there is no proper point where the schemes are brought together.

One example how to do it correctly is here:

https://www.openstreetmap.org/#map=19/53.74883/9.67691
...but it is definitely not correct to do this in the middle of an intersection or stop mapping in the middle of an intersection.

Edit: Using that intersection as an example to show why stopping to map an intersection in detail at that point is really wrong / problematic for data consumers. Imagine the sidewalk-footway on the upper left of that picture would be missing and instead sidewalk=both was mapped on Langelohe starting at the intersection of it with the top-left-most crossing. Then, the most obvious way to route a pedestrian coming from Hamburger Straße and turning right into Langelohe would be to route him like this:

, i.e. cross the road half-way, then continue on Langelohe. Which is obviously wrong.

[westnordost]

I also thought about how to detect the presented situation of an incompletely mapped intersection reliably, but there is none that I can see:

• Checking if there are already two (one for each side) nodes tagged with barrier=kerb on the footway=crossing way won't work because one crossing does not necessarily consist of just one way. It will always be several connecting footway=crossing ways if one wants to record the surface accurately
• Checking that the angle of the supposed continuing footway=sidewalk (in situation (a)) does not deviate for more than 45° from the footway=crossing that leads to it is fuzzy at best and won't work for most intersections, including the one depicted at the bottom of my last post (F.e. imagine the sidewalk-footway on the upper left of that picture would be missing).

[matkoniecz]

So, in case of incomplete data StreetComplete may do something dumb and may require a bit of cleanup from someone completing sidewalks.

But in this case it would require that at the same

(1)

• only some sidewalks leaving crossings were mapped
• kerbs were explicitly mapped

Or

(2)
It would happen in cases where footway=sidewalk were mapped at the island of crossing AND part of footway between kerb and central part of island was mapped as footway=crossing AND kerb was explicitly mapped.

If there is consensus among Italian community that such behavior of StreetComplete is unspeakably evil then the entire quest can be disabled in Italy. But I am not going to implement filtering out such cases as it would disable also places where quest is legitimate.

[westnordost]

@matkoniecz I don't understand (2). Can you illustrate, maybe both points if they haven't yet?

[westnordost]

StreetComplete is unspeakably evil

Well, fact is that the app is adding incorrect data, which is not good. However, my point earlier was that it is only adding incorrect data because the data it worked on was already incorrect. This makes it less bad, especially as the mistake can easily be corrected when the road is mapped further (the sidewalk-mapping is being continued) later.

[matkoniecz]

@matkoniecz I don't understand (2). Can you illustrate, maybe both points if they haven't yet?

#1305 (comment) - StreetComplete added inner kerbs despite outer kerbs being present already.

[matkoniecz]

Well, fact is that the app is adding incorrect data, which is not good. However, my point earlier was that it is only adding incorrect data because the data it worked on was already incorrect. This makes it less bad, especially as the mistake can easily be corrected when the road is mapped further (the sidewalk-mapping is being continued) later.

I agree, but I think that disabling quest on request from local community is OK. Even if the quest works perfectly fine.

As long as it is an actual consensus, not a single person complaining.

[westnordost]

@matkoniecz I don't understand (2). Can you illustrate, maybe both points if they haven't yet?
#1305 (comment) - StreetComplete added inner kerbs despite outer kerbs being present already.

Hm sorry, I don't understand this illustration. The background imagery is so blurred that I don't understand what is the real world situation here and I also don't know what the icons and the slightly different colors of the lines stand for.

[matkoniecz]

My diagnosis is that on such island footway=sidewalk is suspicious at best. And footway=crossing within island, beyond kerb - but not on the entire island between carriageways - makes no sense.

Either crossing should be on the entire island between carriageways or it should not extend beyond kerb.

[westnordost]

Right, understood. I see no problem to use footway=sidewalk on an island, but then it doesn't make sense that the sidewalk part doesn't extend till the kerb... at least I cannot picture a situation where that would make sense.

[LorenzoStucchi]

Right, understood. I see no problem to use footway=sidewalk on an island, but then it doesn't make sense that the sidewalk part doesn't extend till the kerb... at least I cannot picture a situation where that would make sense.

I add the idea of the tagging schema chosen here.
The tagging schema is the one described as (b), because it is also more similar to the mapping of streets. The idea is to transform something that is an area in a line. A new street starts at the insertion with the other, and they follow a schema equal to (b) and not to (a).

(a)

(b)

I'm not sure to the use of the footway=sidewalkin the island, but the size of them could very change and in some cases, they are really sidewalks. However, tag them as footway=crossing should be also wrong in very different cases. There is an alternative?

[LorenzoStucchi]

Not depending on the type of mapping decided, I found an error.

The app proposed the quest for all the nodes that satisfy the characteristics requested, so if in a crossing there are nodes tagged as barrier=kerb and them are not the node in common with the sidewalks, the app adds the quest also on these nodes.

Here an example in the app:

The same way in OSM

The nodes (1) and (4) are the junction with the way mapped as the sidewalk, instead, (2) and (3) are mapped with barrier=kerb. So the app ask for the presence of the tactile paving on all the four nodes.
This should be solved that if in a line there is a node with the barrier=kerb (2) and (3), the app should not ask quests for the external nodes (1) and (4).

[westnordost]

Ehm, I have the impression we are going in circles. Maybe there was a misunderstanding due to the language barrier. I'll try to make it clear:

Here is the linked situation with labels.

I painted the kerb line you assumed onto the screenshot in grey since the photo resolution is so bad.
Rhetoric question: So, if the kerb is there, why then is the section circled in red a highway=crossing, if it is still on he sidewalk?

I assume the answer to that is because you map with this scheme:

i.e. if the part of the crossing is still on the sidewalk, it still counts as part of the crossing and not part of the sidewalk.

Fair enough. But then, please mind what I wrote in the comment above: #1305 (comment) .
This comment summarized: The shown intersection is incomplete. If you are not going to map the sidewalk in Via Trento now, you must do this:

You must lead the sidewalk back to the street with such "helper lines" at the points where you stop the detail-mapping of sidewalks, otherwise data consumers will not be able to ascertain the sidewalk situation correctly / route pedestrians correctly. I explained it in more detail why this is the case in the linked comment. The last two pictures in that comment should be informative.

[LorenzoStucchi]

I painted the kerb line you assumed onto the screenshot in grey since the photo resolution is so bad.
Rhetoric question: So, if the kerb is there, why then is the section circled in red a highway=crossing, if it is still on he sidewalk?

Yes, but if you think in the case of a street. Two street are mapped as (a) or (b)?
The small part in red is on the red streets but it is usually mapped as separe streets, so like (b).
The schema should be the same, why it should be different?

(a)

(a)

(b)

(b)

Fair enough. But then, please mind what I wrote in the comment above: #1305 (comment) .
This comment summarized: The shown intersection is incomplete. If you are not going to map the sidewalk in Via Trento now, you must do this:

This is wrong, in that street, there are no sidewalks.

You must lead the sidewalk back to the street with such "helper lines" at the points where you stop the detail-mapping of sidewalks, otherwise, data consumers will not be able to ascertain the sidewalk situation correctly / route pedestrians correctly. I explained it in more detail why this is the case in the linked comment. The last two pictures in that comment should be informative.

And what is the meaning of the triangle? It is not needed, the router will use the crossing to reach the street and after will use the road, if needed. So the triangle represents somethings that do not exist and it is useless for routing.
And remains in the same case as before, and if there are no sidewalks in the street, is this incorrect mapping? No.

Hoping to close this part, I believe that both the schema are suitable, my last question is why the app asks for attributes on external nodes when there are already nodes in the way with the tag barrier=kerb?

Sorry, for all these long comments, but I think that the mapping with the StreetComplete app is very suitable and useful for people with physical disabilities, and I would like to propose this solution to them for the mapping.

[westnordost]

This is wrong, in that street, there are no sidewalks.

Ok, I didn't know that. But in that case , it makes no sense to map it like that

because if there is no sidewalk in the road going North, the piece of sidewalk beyond the kerb should not be part of the crossing by any definition (neither (a) nor (b) in above examples). It should look like this:

[westnordost]

For comparison:

This is fine for StreetComplete, the app will not ask for kerbs at the blue rectangles

[LorenzoStucchi]

Ok, so I ask you sorry.
If the situation in the last picture is what happens in the app, it is ok so with both the tagging schema. It is only needed to map the yellow square with the tag barrier=kerb. Is this correct?

[westnordost]

Ehm, I am not sure if I undestood your comment.

First picture: Streetcomplete asks for the kerb type for the blue squares
Third picture: StreetComplete does not ask for the kerb type for the blue squares