2 gru 2022, 16:54 od o...@tobias-knerr.de: > On 02.12.22 15:02 Mateusz Konieczny wrote: > >> Or is it justifiable because it is outright impossible to do reliably >> with automatic preprocessing? >> > > I would say that's the reason. Of course, it's hard to prove that something > is impossible. But so far no one has built a working solution for inferring > this information where it isn't explicitly mapped. > >> If yes, can you give examples where it would be beneficial >> and explicitly ask to introduce such tagging solely in >> cases where preprocessing is doomed to fail? >> > > Given the current lack of working preprocessing solutions for even the easier > situations you've linked to, I'm not sure it's easy to tell where the > dividing between "solvable" and "unsolvable" is. It would also have to be > defined and explained in such a manner that mappers (and editing tools like > StreetComplete who might some day ask users to fill this in) can easily > understand where it is or isn't needed. > 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. 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. And that is a small part. The worst part is that any time you update highway=* value or name or ref there is an added drudgery to update this on sidewalks. >> If it is second case of preprocessing being impossible - >> why do massive duplication and ask to duplicate ref value >> AND name value AND highway value? >> > > The duplication-free solution of referencing the road's way ID as > is_sidepath:of = w4087515 is going meet some resistance from people pointing > out the need for, and current lack of, editor support to make such values > usable. > > (Not from me, though, I'd love that approach and have dozens of ideas for > other places where it would be helpful. :)) > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
