[OSM-talk] New OSM Quick-Fix service

Sun Oct 15 13:24:04 UTC 2017

Tobias, this is the best and most constructive email I have seen yet!
Thank you for a very well thought out analysis. I want to give it justice
and do a thorough reply, but only after getting some sleep.  Thank you for
restoring my faith in the proper communication.

Christoph, once again, what does Wikidata have to do with anything in this
thread?  Wikidata is a heated and important point, and just today I saw
another great use of it - https://opentripmap.com/en/  but this is totally
irrelevant for the current discussion.

On Sun, Oct 15, 2017 at 9:14 AM, Tobias Zwick <osm at westnordost.de> wrote:

> Hi Yuri
>
> I am not aware of the record of your previous interactions with the
> community and I think you cannot be blamed to not respond to any toxic
> feedback and/or accusations thrown at you here, whether they may be
> justified or not.
>
> So, I give you the benefit of the doubt and write up this honest and
> constructive feedback. Substantively, I come to the same conclusions as
> the previous posters: That I find it hard to see that the app will have
> any positive impact - at least "as is". I hope you value it nonetheless,
> I also have some suggestions at the end.
>
> So, the initial question is: What is the conceptual use case for such a
> tool? Where would be its place in the range of available OSM tools?
>
> There is the use case where one tagging scheme has been deprecated by
> community consensus and one (combination of) tag(s) should be changed
> into another (combination of) tag(s) globally.
>
> 1. If this does not require humans because both tagging schemes are
> mutually translatable (i.e. lets say for sport=handball <->
> sport=team_handball), then, the edit can be made automatically by a bot.
>
> 2. If this does require humans to check the transition to the new tag
> because the deprecated tagging scheme is ambiguous (i.e. , such as
> sport=football -> soccer or american/australian/canadian/... football),
> then, an automatic edit cannot be done. Instead, tools like MapRoulette
> are used.
>
> 3. Finally, if this also does require humans because a tag combination
> is suspicious (what would show up as warnings in JOSM and what most of
> Osmose consists of), also, a tool like Osmose or MapRoulette is used.
>
> Though, note, for all three cases, a prior consensus is required, either
> by prior discussion or by looking at what was previously agreed on in
> the wiki. That is the case for *any* organized re-tagging of existing tags.
>
> I reckon you see the quick fix tool to be in category 2 and 3 here,
> along with MapRoulette and Osmose, only with the crucial advantage of
> being quicker to use, since no editor is required.
> But it seems to me, you didn't think this through. If the tool offers
> *one* solution to any re-tagging ("Save" or leave it), then, this is
> pretty much a manually operated automatic bot (case 1), which really
> doesn't make sense. For case 2 and 3, it cannot be used as is, because:
>
> - Quick fix cannot be used to find what kind of football it is (case 2),
> but MapRoulette can, because it leaves the actual editing to the user.
>
> - Quick fix cannot be used to solve any markers which may or may not be
> an actual problem (case 3) because it has no way of marking any of the
> things as false-positives.
>
> Looking at your linked Wiki document (
> https://wiki.openstreetmap.org/wiki/Quick_fixes ), most of these are
> candidates for automatic corrections. I.e.:
> - Convert religion=Christian to religion=christian
> - Convert various common forms of religion=catholic to
> religion=christian + denomination=catholic
> - Convert religion=islam to religion=muslim
> - etc.
>
> (Only) your initial example ( amenity=sanatorium -> leisure=resort +
> resort=sanatorium for ex-USSR-countries) falls in case 2. But then, as
> mentioned, either marking as false-positives or other answer options
> (i.e. "yes, it is a sanatorium in the West European sense") are missing.
>
> Okay, so much for why I think the tool is, as is, not fit to be used and
> probably why you got so many negative responses here.
>
> *However*, the idea as such, to make the clean-up process of either
> clearly wrong tags, deprecated tags or even just warnings
> semi-automatic, is a very good one. The prerequisite is, that there must
> always be the option to *not* apply that fix and save that decision. The
> other very critical point is, that the easier you make it for users to
> apply a predefined fix, the more precautions must be taken to ensure
> that the user really checked the situation.
>
> So, the most critical missing features from my point of view in your
> tool are
>
> a) There must be an option to manually edit this instead and/or marking
> it as a false positive. In any case, the marker may not be shown for
> other users anymore. This was a topic in this thread already and it was
> voiced that inventing new tags just to be used by this tool in not
> acceptable and I agree with that. The other tools also do not require that.
>
> b) I strongly suggest to offer different answer options. As I said, if
> only one option is available, it is really nothing else than a manually
> operated automatic edit. If several options are available (i.e.
> "american football", "soccer" etc. ) as a quick fix, only then the tool
> becomes to be useful. (There are some challenges like that on
> MapRoulette also, such as "Phone or fax number is not in international
> format" and these in my opinion also do not belong there because they
> can be solved automatically)
>
> c) Require users to zoom into the map at around zoom 17 or more to make
> any changes. If the users are supposed to check if something is the case
> (via satellite image), then at least don't let them cheat by just
> solving everything from looking at continents.
>
> d) Finally, I think it does not make sense to have any quick fixes in
> that tool that require actually going there (as opposed to looking at
> the satellite imagery) because the effort to go there actually (let's
> say 20min if you happen to live in the vicinity) is dimensions higher
> than clicking on the "Save" button (1 second). The temptation will be
> big to simply click on that button without actually checking it. If you
> actually go there and check, then, the 1 minute as opposed to 1 second
> you need to get the surveyed result into the map through iD/JOSM does
> not really matter in comparison.
>
> All in all, in my opinion, the best way to go forward from here is to
> take this idea of quick fixes and instead of creating an own tool that
> is otherwise very similar to MapRoulette (because it must for being
> useful, see above), propose it as a feature to MapRoulette, discuss and
> implement it together in accord with the MapRoulette team into their
> tool (or Osmose for that matter). It's all open source.
>
> That feature could look like that the creator of a MapRoulette challenge
> may optionally provide a range of possible (typical) answer options
> ("quick fixes") which are then shown as additional buttons right next to
> [Edit], [False Positive] and [Skip] for every place within a challenge.
> I.e. for football, it could be a dropdown of soccer, american_football etc.
>
> Tobias
>
> On 13/10/2017 23:25, Yuri Astrakhan wrote:
> > I would like to introduce a new quick-fix editing service.  It allows
> > users to generate a list of editing suggestions using a query, review
> > each suggestion one by one, and click "Save" on each change if they
> > think it's a good edit.
> >
> > For example, RU community wants to convert  amenity=sanatorium  ->
> > leisure=resort + resort=sanatorium.  Clicking on a dot shows a popup
> > with the suggested edit. If you think the edit is correct, simply click
> > Save.
> > Try it:  http://tinyurl.com/y8mzvk84
> >
> > I have started a Quick fixes wiki page, where we can share and discuss
> > quick fix ideas.
> > * Quick fixes <https://wiki.openstreetmap.org/wiki/Quick_fixes>
> > * Documentation
> > <https://wiki.openstreetmap.org/wiki/Wikidata%2BOSM_
> SPARQL_query_service#Quick-fix_Editor>
> >
> > This is a very new project, and bugs are likely. Please go slowly, and
> > check the resulting edits. Let me know if you find any problems. Your
> > technical expertise is always welcome, see the code
> > at https://github.com/nyurik/wikidata-query-gui  The service has adapted
> > some code from the Osmose project (thanks!)
> >
> > TODO:
> > * Allow multiple edits per one change set
> > * Show objects instead of the dots
> > * Allow users to change comment before saving
> >
> >
> > _______________________________________________
> > talk mailing list
> > talk at openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk
> >
>
>
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20171015/93d17dfd/attachment-0001.html>