On Nov 28, 2022, at 5:57 AM, Maarten Deen <md...@xs4all.nl> wrote: > Your remark seems reasonable ;) Thanks, Maarten, I’m chuckling with mirthful laughter here.
> Thing is: this is not meant as a bot, so the usual caveats apply. That IS an important consideration; thanks for highlighting that aspect. I didn’t know there were / are “usual caveats,” and if there are some, they should be widely known, especially by people who discuss these things in a place, manner and time such as “this, here and now." > It just serves as a highlight of "something might be wrong here", like so > many QA tools do. What the user wielding the QA tool does with that is his > choice. > Does he automatically correct it? Wrong for OSM standards, but who is going > to stop him. Just like who is stopping anyone using a QA tool and > armchairmapping something that he really can not see from a distance. I’m aware of this distinction and again, it is important. Among others (OSMCha [1], there are any number of such tools...), I use Geofabrik's excellent OSM Inspector [2], which “merely shows,” (and superbly) rather than “and fixes, too." Perhaps another example will help: JOSM’s Validator tool gives the opportunity (between clicking the Upload button and actual data being uploaded to OSM) to review “flagged” problems, some as mild Warnings which could be ignored (but shouldn’t be), some as more serious Errors which really ought to be solved. For some of these problems, JOSM is clever enough to “light up” (activate in its user interface) a “Fix” button which is smart enough to “take the right OSM actions” to actually fix the problem. This is great when available, as it solves the tedium of manually doing something which can be automated (so, click the Fix button). And, as JOSM (and OSM) develop, while more and more identified problems are automatically-solvable, some certainly are not, and so the Fix button remains dimmed, meaning “these must be fixed manually.” That’s the distinction I’m making here: I haven’t analyzed Lukas’ code to see where / when / whether (and how) he does this (and again, there are certainly cases where this MIGHT be possible, and where it is, great, do so). I am simply saying “there are times and places where an automated tool CAN fix things” (like naming nameless highways…though this really IS tricky, speaking from personal experience), and there are absolutely times and places where it can’t. Both tool developers (especially) and also, those who wield such tools must be aware of this “sometimes we can, sometimes we can’t” distinctions. And I’m not saying Lukas has done this, but in this realm (and because I know a couple things about “quality” and “mapping” I can say this): it is all-to-easy to glibly make assumptions which are better left not made. Especially in the context of OSM, wider vetting (exactly what Lukas is asking for here) is exactly what is needed. Though, as we get wider input that includes “seems reasonable,” I urge caution. I’ll stop here, as I don’t want to repeat myself. [1] https:osmcha.org [2] https://tools.geofabrik.de _______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
