[OSM-talk] New OSM Quick-Fix service

[Tobias Zwick]

Number 2.

>> [...] 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.
>
> [...] Not showing it can also be easily done by a slight
> modification of the query itself.  This is assuming my reasoning for
> on-OSM tag storage makes sense for other tools. In the mean time, I do
> plan to make a separate reject storage system just to cover all cases.

An on-OSM tag storage? Inventing new tags for (single) tools is
specifically what I mentioned has been strongly opposed!

I see you mention having some OSM tag further below in your message and
you give some arguments why this might be a good idea beyond the ease of
implementation.
I'd say, of course whether such a tag or namespace of tags could make
sense is something that can be discussed. But not after the fact and not
on pressure. Your tool being live, and no way marking something as
false-positive, this does set a discussion about this in exactly in a
bad atmosphere.
Anyway, generally, with everyone raising the alarm about this tool, it
would be a friendly gesture to either take the tool offline for now or
set it to read-only mode (no save button) so that everyone can calm down
and the critical points about it can been addressed and solutions be
found, in an objective non-pressured manner. Since this is a general
consideration that concerns other tools as well then, it should be done
in a separate topic.

Anyway. I am surprised to read that you see the tool actually also in
case #1, as a manually operated automatic edit. It could be that I, and
probably many people here in this topic majorly misunderstood your
intention with this tool.
Let me summarize your arguments why this makes sense over a fully
automated edit:

1. barrier too high for writing a completely automatic bot
  a) automatic edits are too risky, fear of programming errors
  b) too thorough review is required for fully automatic edits, fear of
     uncovered edge cases
  c) a mistake of a bot edit can only be spotted after the fact and a
     (partial) revert of such a bot edit is complex

2. your tool lowers that barrier by creating some kind of staging / test
   area for bot edits by having different users manually confirm or
   reject the proposed fix for any such element
  a) it's relatively easy to add an automatic edit to the tool and that
     same query can be used to run directly on the server for full
     automation
  b) issues with the query can be fixed by anyone (wiki)

---

I can follow your line of argumentation and your vision. There is quite
the discrepancy between this and the concerns mentioned so far in this
topic, which see your tool from a different perspective (which I will
iterate further below).

The concerns are, that the tool will not actually be used to
stage/analyze the impact of an automatic edit that is to be applied
after consensus and thorough testing but to go forward with organized
re-tagging without that (or at least give other users the tool to do
that). If this is not your intention, then the tool must be changed in a
way that it does not lend itself for that purpose.

Furthermore, the argument that a mistake in a completely automatic bot
is complex to revert, seems bogus. If the edit happens in *one* edit, it
is on the contrary, very easy to revert. If, on the other hand, dozens
or even hundreds of people worked on a quick-fix task which needs to be
reverted, again on the contrary, this is much harder to revert because
there are different users, different changesets and over a varying
timespan involved. (Also, I hope the tool at least writes into the
changeset which quick-fix exactly was used, to link quick-fix with
changesets)

> [...] this will be up to the communities to enforce - if
> someone writes a query [that requires actually going there to check],
> others should be quick to point this out.

Better, document that. Here, look for example at the guidelines for new
"quick-fixes" (aka quests) I wrote for my OSM tool:
https://github.com/westnordost/StreetComplete/wiki/Adding-new-Quests-to-StreetComplete

Leaving this kind of supervision to "the community" means that you
generate thankless work for people that constantly "should be quick to"
sound the alarm for quick-fixes that are not correct in one way or the
other (which are immediately live).

Not sure if this came across to you yet, but it has been said a couple
of times in this thread already and it should be repeated in light of
the answer you gave above:

When you say, it is up to the community to point out problems with any
such query that has already been created and is being worked on, then
you basically reverse the whole guidelines for bot-editing - the
community learns about it after the fact, instead of before it is
happening. This is exactly the situation we do not want to have.
This is the fundamental issue with the tool and something that would
also begin to apply to MapRoulette, if such a feature as I suggested in
my last message would be implemented there, despite the usefulness.

I have a solution for that.

You mentioned your vision is to make bot edits easier by providing a
platform for a staging process. Quick-fix being that staging platform in
which users tag the single occurances of to-be-changed elements as
"confirm" or "reject" to find and fix possible edge cases in the SPARQL
query that can be applied directly on the database when properly
reviewed, tested and discussed.

So then, the solution is simple: Make the quick-fix tool to only record
confirms and rejects into a separate database and let the tool not make
actual edits to OSM. The confirms and most importantly the rejects are
shown on the tool's interface, so the problems in the automatic query
can be addressed.
When the process is through and the query is applied to the OSM DB, the
end result is absolutely the same as if the "confirms" from already the
test period would have been written into the OSM database. Actually, the
result will be better, because the places where the quick-fix was wrong
due to an initially faulty query, would not be in the OSM.

I know, this is a fundamental departure from what the tool is currently
able to do, but if you are sincere about your vision for how the tool
should be used, then I see nothing that speaks against it.