<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><span style="color:rgb(11,83,148)">>Thank you for a very well thought out analysis.</span></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">Surely the analysis should be done at the front of the project.  Making a change during the project has costs.  The further you are into the project normally the higher the cost is to correct something.  This is general not specifically your project.</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">In this case the cost is either we end up with tatty data or some poor muggings has to clean it up plus of course some reputational damage.</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">I suggest pausing and then defining the problem(s) you are trying to address.  Once that is agreed then is the time to work out a solution that is agreeable to more people than the present version.<br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">Cheerio John<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 15 October 2017 at 09:24, Yuri Astrakhan <span dir="ltr"><<a href="mailto:yuriastrakhan@gmail.com" target="_blank">yuriastrakhan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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.<br></div><div><br></div><div>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 - <a href="https://opentripmap.com/en/" target="_blank">https://opentripmap.com/en/</a>  but this is totally irrelevant for the current discussion.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 15, 2017 at 9:14 AM, Tobias Zwick <span dir="ltr"><<a href="mailto:osm@westnordost.de" target="_blank">osm@westnordost.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Yuri<br>
<br>
I am not aware of the record of your previous interactions with the<br>
community and I think you cannot be blamed to not respond to any toxic<br>
feedback and/or accusations thrown at you here, whether they may be<br>
justified or not.<br>
<br>
So, I give you the benefit of the doubt and write up this honest and<br>
constructive feedback. Substantively, I come to the same conclusions as<br>
the previous posters: That I find it hard to see that the app will have<br>
any positive impact - at least "as is". I hope you value it nonetheless,<br>
I also have some suggestions at the end.<br>
<br>
So, the initial question is: What is the conceptual use case for such a<br>
tool? Where would be its place in the range of available OSM tools?<br>
<br>
There is the use case where one tagging scheme has been deprecated by<br>
community consensus and one (combination of) tag(s) should be changed<br>
into another (combination of) tag(s) globally.<br>
<br>
1. If this does not require humans because both tagging schemes are<br>
mutually translatable (i.e. lets say for sport=handball <-><br>
sport=team_handball), then, the edit can be made automatically by a bot.<br>
<br>
2. If this does require humans to check the transition to the new tag<br>
because the deprecated tagging scheme is ambiguous (i.e. , such as<br>
sport=football -> soccer or american/australian/canadian/.<wbr>.. football),<br>
then, an automatic edit cannot be done. Instead, tools like MapRoulette<br>
are used.<br>
<br>
3. Finally, if this also does require humans because a tag combination<br>
is suspicious (what would show up as warnings in JOSM and what most of<br>
Osmose consists of), also, a tool like Osmose or MapRoulette is used.<br>
<br>
Though, note, for all three cases, a prior consensus is required, either<br>
by prior discussion or by looking at what was previously agreed on in<br>
the wiki. That is the case for *any* organized re-tagging of existing tags.<br>
<br>
I reckon you see the quick fix tool to be in category 2 and 3 here,<br>
along with MapRoulette and Osmose, only with the crucial advantage of<br>
being quicker to use, since no editor is required.<br>
But it seems to me, you didn't think this through. If the tool offers<br>
*one* solution to any re-tagging ("Save" or leave it), then, this is<br>
pretty much a manually operated automatic bot (case 1), which really<br>
doesn't make sense. For case 2 and 3, it cannot be used as is, because:<br>
<br>
- Quick fix cannot be used to find what kind of football it is (case 2),<br>
but MapRoulette can, because it leaves the actual editing to the user.<br>
<br>
- Quick fix cannot be used to solve any markers which may or may not be<br>
an actual problem (case 3) because it has no way of marking any of the<br>
things as false-positives.<br>
<br>
Looking at your linked Wiki document (<br>
<a href="https://wiki.openstreetmap.org/wiki/Quick_fixes" rel="noreferrer" target="_blank">https://wiki.openstreetmap.org<wbr>/wiki/Quick_fixes</a> ), most of these are<br>
candidates for automatic corrections. I.e.:<br>
- Convert religion=Christian to religion=christian<br>
- Convert various common forms of religion=catholic to<br>
religion=christian + denomination=catholic<br>
- Convert religion=islam to religion=muslim<br>
- etc.<br>
<br>
(Only) your initial example ( amenity=sanatorium -> leisure=resort +<br>
resort=sanatorium for ex-USSR-countries) falls in case 2. But then, as<br>
mentioned, either marking as false-positives or other answer options<br>
(i.e. "yes, it is a sanatorium in the West European sense") are missing.<br>
<br>
Okay, so much for why I think the tool is, as is, not fit to be used and<br>
probably why you got so many negative responses here.<br>
<br>
*However*, the idea as such, to make the clean-up process of either<br>
clearly wrong tags, deprecated tags or even just warnings<br>
semi-automatic, is a very good one. The prerequisite is, that there must<br>
always be the option to *not* apply that fix and save that decision. The<br>
other very critical point is, that the easier you make it for users to<br>
apply a predefined fix, the more precautions must be taken to ensure<br>
that the user really checked the situation.<br>
<br>
So, the most critical missing features from my point of view in your<br>
tool are<br>
<br>
a) There must be an option to manually edit this instead and/or marking<br>
it as a false positive. In any case, the marker may not be shown for<br>
other users anymore. This was a topic in this thread already and it was<br>
voiced that inventing new tags just to be used by this tool in not<br>
acceptable and I agree with that. The other tools also do not require that.<br>
<br>
b) I strongly suggest to offer different answer options. As I said, if<br>
only one option is available, it is really nothing else than a manually<br>
operated automatic edit. If several options are available (i.e.<br>
"american football", "soccer" etc. ) as a quick fix, only then the tool<br>
becomes to be useful. (There are some challenges like that on<br>
MapRoulette also, such as "Phone or fax number is not in international<br>
format" and these in my opinion also do not belong there because they<br>
can be solved automatically)<br>
<br>
c) Require users to zoom into the map at around zoom 17 or more to make<br>
any changes. If the users are supposed to check if something is the case<br>
(via satellite image), then at least don't let them cheat by just<br>
solving everything from looking at continents.<br>
<br>
d) Finally, I think it does not make sense to have any quick fixes in<br>
that tool that require actually going there (as opposed to looking at<br>
the satellite imagery) because the effort to go there actually (let's<br>
say 20min if you happen to live in the vicinity) is dimensions higher<br>
than clicking on the "Save" button (1 second). The temptation will be<br>
big to simply click on that button without actually checking it. If you<br>
actually go there and check, then, the 1 minute as opposed to 1 second<br>
you need to get the surveyed result into the map through iD/JOSM does<br>
not really matter in comparison.<br>
<br>
All in all, in my opinion, the best way to go forward from here is to<br>
take this idea of quick fixes and instead of creating an own tool that<br>
is otherwise very similar to MapRoulette (because it must for being<br>
useful, see above), propose it as a feature to MapRoulette, discuss and<br>
implement it together in accord with the MapRoulette team into their<br>
tool (or Osmose for that matter). It's all open source.<br>
<br>
That feature could look like that the creator of a MapRoulette challenge<br>
may optionally provide a range of possible (typical) answer options<br>
("quick fixes") which are then shown as additional buttons right next to<br>
[Edit], [False Positive] and [Skip] for every place within a challenge.<br>
I.e. for football, it could be a dropdown of soccer, american_football etc.<br>
<span class="m_5481361784619032316HOEnZb"><font color="#888888"><br>
Tobias<br>
</font></span><span class="m_5481361784619032316im m_5481361784619032316HOEnZb"><br>
On 13/10/2017 23:25, Yuri Astrakhan wrote:<br>
> I would like to introduce a new quick-fix editing service.  It allows<br>
> users to generate a list of editing suggestions using a query, review<br>
> each suggestion one by one, and click "Save" on each change if they<br>
> think it's a good edit.<br>
><br>
> For example, RU community wants to convert  amenity=sanatorium  -> <br>
> leisure=resort + resort=sanatorium.  Clicking on a dot shows a popup<br>
> with the suggested edit. If you think the edit is correct, simply click<br>
> Save.<br>
> Try it:  <a href="http://tinyurl.com/y8mzvk84" rel="noreferrer" target="_blank">http://tinyurl.com/y8mzvk<wbr>84</a><br>
><br>
> I have started a Quick fixes wiki page, where we can share and discuss<br>
> quick fix ideas.<br>
</span><span class="m_5481361784619032316im m_5481361784619032316HOEnZb">> * Quick fixes <<a href="https://wiki.openstreetmap.org/wiki/Quick_fixes" rel="noreferrer" target="_blank">https://wiki.openstreetmap.or<wbr>g/wiki/Quick_fixes</a>><br>
> * Documentation<br>
> <<a href="https://wiki.openstreetmap.org/wiki/Wikidata%2BOSM_SPARQL_query_service#Quick-fix_Editor" rel="noreferrer" target="_blank">https://wiki.openstreetmap.or<wbr>g/wiki/Wikidata%2BOSM_SPARQL_<wbr>query_service#Quick-fix_Editor</a><wbr>><br>
><br>
</span><span class="m_5481361784619032316im m_5481361784619032316HOEnZb">> This is a very new project, and bugs are likely. Please go slowly, and<br>
> check the resulting edits. Let me know if you find any problems. Your<br>
> technical expertise is always welcome, see the code<br>
> at <a href="https://github.com/nyurik/wikidata-query-gui" rel="noreferrer" target="_blank">https://github.com/nyurik/w<wbr>ikidata-query-gui</a>  The service has adapted<br>
> some code from the Osmose project (thanks!)<br>
><br>
> TODO:<br>
> * Allow multiple edits per one change set<br>
> * Show objects instead of the dots<br>
> * Allow users to change comment before saving<br>
><br>
><br>
</span><div class="m_5481361784619032316HOEnZb"><div class="m_5481361784619032316h5">> ______________________________<wbr>_________________<br>
> talk mailing list<br>
> <a href="mailto:talk@openstreetmap.org" target="_blank">talk@openstreetmap.org</a><br>
> <a href="https://lists.openstreetmap.org/listinfo/talk" rel="noreferrer" target="_blank">https://lists.openstreetmap.or<wbr>g/listinfo/talk</a><br>
><br>
<br>
<br>
______________________________<wbr>_________________<br>
talk mailing list<br>
<a href="mailto:talk@openstreetmap.org" target="_blank">talk@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk" rel="noreferrer" target="_blank">https://lists.openstreetmap.or<wbr>g/listinfo/talk</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
talk mailing list<br>
<a href="mailto:talk@openstreetmap.org">talk@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk" rel="noreferrer" target="_blank">https://lists.openstreetmap.<wbr>org/listinfo/talk</a><br>
<br></blockquote></div><br></div>