[OSM-talk] New OSM Quick-Fix service

[Yuri Astrakhan]

On Thu, Nov 9, 2017 at 4:07 PM, ajt1047 at gmail.com <ajt1047 at gmail.com> wrote:

> On 09/11/2017 20:48, Yuri Astrakhan wrote:
>
>> JB, the "layer=0 removal" is one of the JOSM validations - it
>> automatically gets suggested to anyone editing an area with that object,
>> with the "fix" button autofixing it. JOSM doesn't have a "mark this autofix
>> as invalid" button, which means that even if you don't autofix it, the next
>> person reviewing the same area may. This sounds identical to the issue
>> raised by Simon above:
>> > ...you don't actually "confirm" that something is a good edit or not.
>> You only have the choice of making an edit or leaving it to others to do.
>> ... This makes the whole thing entirely equivalent to a mechanical edit.
>>
>> So we should either A) remove it from JOSM, or B) define when it should
>> be kept vs deleted, because otherwise we are not being consistent with
>> requirements.
>>
>>
> No, the two aren't equivalent.  In JOSM, validator suggestions are made
> after you've been editing in the area.  Typically where "default tags" such
> as "layer=0" (or "oneway=no" for that matter) are used are in places where
> something's an exception (maybe this is the only cross-town two-way street)
> , or there's more information to be mapped (maybe there's something yet to
> be mapped over or under the "layer=0" way that's obvious from the context
> of the data in the area).


Andy, "... obvious from the context of the data in the area" is the exact
problem.  It may be obvious to you, but another mapper who may visit the
same area might not be as experienced, and when they see a suggestion from
JOSM, it will be obvious to them to remove it. And if not them, than the
next person - making it equivalent to what Simon was saying - eventually
there will be a person who will overlook your obvious context and who will
heed to JOSM's advice.  It's just a matter of time.

  All you're doing is blindly performing (or encouraging the performance
> of) mechanical edits, where the mapper has no knowledge of the local area.
>
Incorrect, I am encouraging tagging experts, the same experts that decide
which tags should be used for what on the @tagging, to review just that
specific tag, case by case, and decide if the tag should be fixed, or if a
new rule should be made. Maybe the deprecation was a mistake, and there are
legit use cases?

>
> Ask yourself "in what way does removing layer=0 from a bunch of ways
> improve the quality of OpenStreetMap?".  It certainly adds no valid data.
> It could potentially remove information (if there's a problem with
> something else also tagged layer=0 nearby that will be obvious to a user of
> an interactive editor from context).
>

I strongly disagree, it greatly improves the quality of OSM, because it
simplifies the work that every data consumer has to do.  The layer=0 is a
tiny, perhaps less important subset of the big problem. If I am a data
consumer, I need to handle every case. and if something can be stored in
multiple ways, I need to handle all of them. And this increases my workload.

Fundamentally ,this is not about layer=0, but about all of the deprecated
tagging.  For example, natural=marsh → natural=wetland + wetland=marsh --
this implies that every data processor has to know both of these tagging
schemas.  And there are hundreds of others, with hundreds of thousands of
cases.

If I am a large organization, I have enough resources to handle each case
by my data team. So if OSM wants to cater to the deep pockets, leaving all
these deprecated tagging behind is fine. But if we want individuals and
small organizations to easily use the data without much effort, the data
must be as clean and straightforward as possible. Otherwise every single
data consumer has to redo the same work, and handle every corner case, or
it ends up ignoring or mishandling many of them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20171110/edc3f238/attachment-0001.html>