[Tagging] Feature Proposal - RFC - "is_sidepath" as a sidepath concept

[Minh Nguyen]

Vào lúc 08:44 2022-12-02, Mateusz Konieczny via Tagging đã viết:
> I have good news! There is preprocessing solution for large (nearly 
> all?) simple cases,
> written in Kotlin and is a part of StreetComplete.
> 
> StreetComplete would be able to handle cases listed in its sidewalk 
> detection
> (used to skip sidewalk/cycleway quests in presence of nearby separately 
> mapped sidewalk
> - note that in new versions this quests are disabled by default as overlays
> are intended to replace them)
> 
> You can test how it works by finding place where roads have no 
> sidewalk=* tags
> and there are separately mapped sidewalks, navigate there in 
> StreetComplete and
> disable all quests except sidewalk/cycleway.
> 
> You will get them on matching roads - except ones with detected nearby 
> sidewalks.
> You can also tweak filter rules to enable sidewalk and cycleway quest 
> for all roads
> to skip tag based filtering (which skips some roads unlikely to have 
> cycleways
> or sidewalks or already tagged with sidewalk* and cycleway* tags)
> 
> This code would handle with slight modifications vast majority of cases.
> Simplest one would be enlarging default buffer and other parameters.
> Possible changes include taking into account cycleway*=separate tags and
> sidewalk*=separate tags to search for larger distance if sidewalk was 
> not found
> and other obvious tweaks - all examples listed here would be handled.

Are you referring to this code? [1] A running time of O(n^3) is not 
necessarily something others would consider a solution. Imagine a router 
running this algorithm over a whole continent or planet when building 
the routing graph. Yet it's also too sensitive to where a way happens to 
be split. Either the footway or the roadway could be split at arbitrary 
points for arbitrary reasons or no reason at all.

A more general algorithmic solution may be feasible, but it would 
probably look much more like Skeletron [2], which conflates dual 
carriageways, or the map matching algorithms in various routing engines, 
which are normally used to align GPS traces to the road network. These 
approaches are overkill for StreetComplete but may be a good fit for a 
routing engine. The edge cases in [3] would require walking the routing 
graph to some extent. This is something the Overpass API was originally 
designed to do, so it isn't inconcievable, but it isn't purely a 
trigonometric problem.

> Yes, it will take some effort to write or adapt this code. But this 
> proposal asks
> mappers to manually preprocess millions of sidewalk sections.
> Just currently marked footway=sidewalk (small part of all separately 
> mapped sidewalks)
> have 3 300 000+ sections.
> Lets take optimistic 5s per section, initial tagging that alone would 
> consume
> 4695 hours of mapping (and also software costs to allow such efficient 
> mapping!).
> And likely 5s per way is very optimistic.
> Add to that all separately mapped sidewalks without footway=sidewalk.

For what it's worth, this would be a similar scope of work as adding 
name=* to each of the sidewalk ways, just as with dual carriageways. 
Mappers in some cities are already systematically adding name=* to 
sidewalk ways, but it hasn't really caught on globally, maybe because of 
how it clutters a typical map. (But a renderer could simply avoid 
labeling footway=sidewalk.)

Inevitably, there will be unhandled edge cases regardless of the 
algorithm. Maybe a compromise would be to treat is_sidepath:of=* as an 
override for difficult cases only, similar to name:pronunciation=*. The 
benefit over name=* is that nothing changes for a renderer unless they 
opt into processing the new key.

[1] 
<https://github.com/streetcomplete/StreetComplete/blob/36f65b4aa918c418710ead05745e5d233c5092f1/app/src/main/java/de/westnordost/streetcomplete/util/math/ElementGeometryMath.kt#L13-L32>
[2] https://github.com/migurski/Skeletron/
[3] 
<https://github.com/OpenSidewalks/OpenSidewalks-Schema/issues/2#issuecomment-1074404560>

-- 
minh at nguyen.cincinnati.oh.us