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>
--
m...@nguyen.cincinnati.oh.us
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
