I disagree once more. You are mixing two problems which are completly
different. The one you introduce being easier to agree with than the one
previously at hand.
Layer=0, oneway=no have the same meaning as no information. It can be
useful in some cases, as explained by Andy. Deleting them have no impact
on data consumers. If you are able to parse the oneway=* tag, I
seriously hope you check the value. Having 0/no as a value should not
disturbe your software, or you are doing it wrong (a renderer used to
render oneway=-1 the same as oneway=yes. I hope you agree it was the
consumer's fault, not OSM's).
Deprecated tags, badly applied new tags is another problem, that should
be discussed with the community if a mecanical edit is done.
JB.
Le 10/11/2017 à 08:18, Yuri Astrakhan a écrit :
On Thu, Nov 9, 2017 at 4:07 PM, ajt1...@gmail.com
<mailto:ajt1...@gmail.com> <ajt1...@gmail.com
<mailto:ajt1...@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.
_______________________________________________
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
_______________________________________________
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
