<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<div><br></div><div><br></div><div><br></div><div>2 gru 2022, 20:50 od minh@nguyen.cincinnati.oh.us:<br></div><blockquote class="tutanota_quote" style="border-left: 1px solid #93A3B8; padding-left: 10px; margin-left: 5px;"><div>Vào lúc 08:44 2022-12-02, Mateusz Konieczny via Tagging đã viết:<br></div><blockquote><div>I have good news! There is preprocessing solution for large (nearly all?) simple cases,<br></div><div>written in Kotlin and is a part of StreetComplete.<br></div><div><br></div><div>StreetComplete would be able to handle cases listed in its sidewalk detection<br></div><div>(used to skip sidewalk/cycleway quests in presence of nearby separately mapped sidewalk<br></div><div>- note that in new versions this quests are disabled by default as overlays<br></div><div>are intended to replace them)<br></div><div><br></div><div>You can test how it works by finding place where roads have no sidewalk=* tags<br></div><div>and there are separately mapped sidewalks, navigate there in StreetComplete and<br></div><div>disable all quests except sidewalk/cycleway.<br></div><div><br></div><div>You will get them on matching roads - except ones with detected nearby sidewalks.<br></div><div>You can also tweak filter rules to enable sidewalk and cycleway quest for all roads<br></div><div>to skip tag based filtering (which skips some roads unlikely to have cycleways<br></div><div>or sidewalks or already tagged with sidewalk* and cycleway* tags)<br></div><div><br></div><div>This code would handle with slight modifications vast majority of cases.<br></div><div>Simplest one would be enlarging default buffer and other parameters.<br></div><div>Possible changes include taking into account cycleway*=separate tags and<br></div><div>sidewalk*=separate tags to search for larger distance if sidewalk was not found<br></div><div>and other obvious tweaks - all examples listed here would be handled.<br></div></blockquote><div><br></div><div>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.<br></div></blockquote><div dir="auto">Yes, it is just a proof that it is at least partially doable - not something readily usable<br></div><div dir="auto">for planet processing.<br></div><div dir="auto">Still, makes me really dubious about applying this tagging everywhere - especially<br></div><div dir="auto">if people applying it expect people editing highway tags or name tags or ref tags<br></div><div dir="auto">to maintain this new tags.<br></div><blockquote class="tutanota_quote" style="border-left: 1px solid #93A3B8; padding-left: 10px; margin-left: 5px;"><div>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.<br></div></blockquote><div dir="auto">+1<br></div><blockquote class="tutanota_quote" style="border-left: 1px solid #93A3B8; padding-left: 10px; margin-left: 5px;"><blockquote><div>Yes, it will take some effort to write or adapt this code. But this proposal asks<br></div><div>mappers to manually preprocess millions of sidewalk sections.<br></div><div>Just currently marked footway=sidewalk (small part of all separately mapped sidewalks)<br></div><div>have 3 300 000+ sections.<br></div><div>Lets take optimistic 5s per section, initial tagging that alone would consume<br></div><div>4695 hours of mapping (and also software costs to allow such efficient mapping!).<br></div><div>And likely 5s per way is very optimistic.<br></div><div>Add to that all separately mapped sidewalks without footway=sidewalk.<br></div></blockquote><div><br></div><div>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.)<br></div></blockquote><div dir="auto">I would be also against this tagging style for similar reasons. Though at least it has<br></div><div dir="auto">lower duplication and reclassifying highway=* way (not an unusual activity!)<br></div><div dir="auto">is not resulting in pointless drudgery.<br></div><blockquote class="tutanota_quote" style="border-left: 1px solid #93A3B8; padding-left: 10px; margin-left: 5px;"><div>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.<br></div></blockquote><div dir="auto">That would work for me - but this difficult cases should be identified.<br></div><div dir="auto">I expect that relations may be needed for some, and this proposed tags will not<br></div><div dir="auto">be sufficient in especially pathological ones (for example where road splits in multiple<br></div><div dir="auto">named in the same way).<br></div> </body>
</html>