Separately mapped sidewalk is not detected

[mnalis]

Sidewalk quest get asked even if there are nearby separate footways marked separately with highway=footway+footway=sidewalk. The sidewalk quest should be skipped in such cases.

How to Reproduce

• enable sidewalk quest and navigate for example to this way: https://www.openstreetmap.org/way/34926444
• notice that Does this street have a sidewalk quest gets asked
• notice that there are parallel sidewalks separately mapped already on both sides (on that particular segment of the street, there is not even an green buffer zone between street and sidewalk, like it is a little to the east)

Expected Behavior

• SC should detect separately mapped footway and skip the quest, according to my understanding.

Code itself is unfortunately too complex for me to follow, but comments in the code seem to indicate it should work that way:

StreetComplete/app/src/main/java/de/westnordost/streetcomplete/quests/sidewalk/AddSidewalk.kt

Lines 42 to 45 in d215e40

	/* Unfortunately, the filter above is not enough. In OSM, sidewalks may be mapped as
	* separate ways as well and it is not guaranteed that in this case, sidewalk = separate
	* (or foot = use_sidepath) is always tagged on the main road then. So, all roads should
	* be excluded whose center is within of ~15 meters of a footway, to be on the safe side. */

Versions affected
upstream StreetComplete v47.1, Android 10

Same or similar problem seems to also be present in earlier versions too, e.g. https://www.openstreetmap.org/note/3186207, https://www.openstreetmap.org/note/3186207 etc

[mnalis]

(and there are many similar examples relatively nearby; e.g. https://www.openstreetmap.org/way/804793377, https://www.openstreetmap.org/way/629025256, https://www.openstreetmap.org/way/27314747 etc.)

[Helium314]

Sidewalk is only detected as sidewalk if it's close enough, for minimum distance at which a way is recognizes as a possible sidewalk see

StreetComplete/app/src/main/java/de/westnordost/streetcomplete/quests/sidewalk/AddSidewalk.kt

Line 78 in d215e40

private fun getMinDistanceToWays(tags: Map<String, String>): Float =

[mnalis]

hmmm... according to JOSM, there is about 8m between middle of the road and the middle of the sidewalk, which should be well within ~15m that comment quoted above says (if the comment correct?)

Trying to decipher:

StreetComplete/app/src/main/java/de/westnordost/streetcomplete/quests/sidewalk/AddSidewalk.kt

Lines 78 to 84 in d215e40

	private fun getMinDistanceToWays(tags: Map<String, String>): Float =
	(
	(estimateRoadwayWidth(tags) ?: guessRoadwayWidth(tags)) +
	(estimateParkingOffRoadWidth(tags) ?: 0f) +
	(estimateCycleTrackWidth(tags) ?: 0f)
	) / 2f +
	4f // + generous buffer for possible grass verge

• as there is lanes=3, estimateRoadwayWidth should return at least 9 (3*LANE)
• estimateParkingOffRoadWidth probably is zero, due to parking:lane:both=no_stopping?
• Then there is estimateCyclewaysWidth() (which I'm unable really to decipher what it should return), but due to cycleway:left=lane I'm guessing it might be 1 ?
  

  StreetComplete/app/src/main/java/de/westnordost/streetcomplete/osm/cycleway/Cycleway.kt

  Line 111 in d215e40

  UNSPECIFIED_LANE -> 1f

If so, it should be (9+0+1)/2+4 which is 9m, so it should still (but very narrowly) fit. (although it seems it does not fit)

So, the comment claiming ~15m might probably be changed to ~7-20m?

However, (if I didn't miss something) that calculation does not feel right. If you look at the JOSM picture with aerial background, given that there is no green protection between road and sidewalk, SC seems to estimate that center of footway should be no more than 5m away from center of 3.5lanes road. It does not seem to take into account that sidewalk (which in this case is wide as ~2 lanes) itself is not mapped on its closest edge to the road, but on the middle, which should add extra 3m in this calculation

So its minimum average width in this case should IMHO be 5+3=8 (half the road + half the sidewalk), and possible 4m buffer should be added to that 8m to produce 12m, which would sound reasonable.

[mnalis]

Note that this 4m protection buffer mentioned above is intended to match only slightly larger lanes and kerbs, and possibility that the sidewalk also has segregated cycle track (or often two of them).

And if there is actual grass protection verge (e.g. in a middle left part of the picture, marked with 3.85m long red line), that should be an additional ~4m per side of the road. So for 3.5lane road with wider sidewalk like here (or sidewalk+cycleway) and with grass verge between road and sidewalk, it should calculate about 5+3+4+4=16m total.
Which is double of what it currently estimates.

[mnalis]

So if my reasoning is not faulty, would something like this make sense?

 private fun getMinDistanceToWays(tags: Map<String, String>): Float = 
     ( 
         (estimateRoadwayWidth(tags) ?: guessRoadwayWidth(tags)) + 
         (estimateParkingOffRoadWidth(tags) ?: 0f) + 
+        4f // average sidewalk width should also be accounted for (as sidewalk will be mapped in the middle of it, not on the side closest to the road) 
         (estimateCycleTrackWidth(tags) ?: 0f) 
     ) / 2f + 
+    3f // + allow for kerbs, wider sidewalks, possibly segregated cycleways on sidewalks, lanes little larger than the 3m minimum
     4f // + generous buffer for possible grass verge 

[westnordost]

Since in the sidewalk quest, you can now actually select "displayed separately on map", having a filter that reduces the number of false positives even in edge cases at the cost of producing many false negatives (i.e. quest is not asked in places where it should be) is not really important anymore.

... to the point where I am entertaining the thought to completely drop this "min distance to ways" thing, as it is always better to specify the situation explicitly rather than relying on some fuzzy logic.

On the other hand, of course, the filter makes sense insofar as otherwise a city that is comprehensively mapped with separate sidewalks (but consistently missing sidewalk=separate) may be spammed with such questions which is against the quest guidelines.

So, at least, in my opinion, the filter should at this point rather produce false positives than false negatives. I.e. for the cited calculation, rather not assume generous widths (like 4m for a sidewalk, 3.5 meters for a lane, big grass protection verge etc.)

[mnalis]

So, at least, in my opinion, the filter should at this point rather produce false positives than false negatives. I.e. for the cited calculation, rather not assume generous widths (like 4m for a sidewalk, 3.5 meters for a lane, big grass protection verge etc.)

OK, I can accept that false positives are preferable here.

Still, should some width (instead of current 0) of the sidewalk be calculated, at least?

For example, over here legal minimum width for sidewalk is 1.8m which seems to be the case elsewhere too (1.5m-2.5m minimum), e.g. random first searches:

What is the minimum width of sidewalk in meter?
Footpaths in residential areas require a minimum clear width of 1.8 m, which is enough space for two wheelchairs to pass >each other. For commercial areas, the clear width should be at least 2.5 m (IRC:103-2012, 6.1. 5.2).

or this

Sidewalks have a desired minimum through zone of 6 feet and an absolute minimum of 5 feet. Where a sidewalk is directly adjacent to moving traffic, the desired minimum is 8 feet, providing a minimum 2-foot buffer for street furniture and utilities.

(conversion: 5/6/8 feet are about 1.5m / 1.8m / 2.4m respectively)

[westnordost]

I'd accept a PR that:

• assumes a minimum sidewalk width by default. You cite a minimum width of 1.8m - well, I have seen much narrower ones. But I guess below 1m barely is usable as a sidewalk anymore
• if no explicit tags are given, is always rather pessimistic when estimating widths (just as an example: if no width or lanes is given on a residential road, lean to rather assume a pessimistic width such as 4m rather than a good estimate / what would be expected like 7m or something)
• the same as above for things that allow to estimate the width more accurately like lanes - rather assume narrow than wide lanes etc.