@mmd, thanks, but I never said anything about oneway=no, and never proposed
to remove it.  Andy Townsend introduced that into the discussion, and JB
elaborated on it. It is not listed in the deprecated list, nor is it in
JOSM autofixes, so it is a moot point.  BTW, I did find oneway=1 ->
oneway=yes JOSM autofix and added it to Sophox (about 4,250 hits)  here
<https://wiki.openstreetmap.org/wiki/Quick_fixes#Deprecated>

@JB, my only goal with this effort is to reduce the amount of work data
consumers must do to use our data, as I believe this to be a significant
enough problem that raises barrier of entry. You are right that =0 and =no
seem like nobrainers, but if we have listed them as deprecated, we should
not use them. Otherwise - why deprecate, if they still contain meaning?
Perhaps they are bad for discussing Sophox itself, and we should pick some
other deprecated or JOSM autofix.

Second, there is no mechanical edits here. Lets not dilute the meaning of
the words, otherwise eventually almost anything can be called that. These
are tasks, or "challenges", that allows users to review each case
independently, either agree, pick one of the solutions, or mark as invalid.
Some cases can be resolved based on the existing information, e.g. other
tags / satellite imagery / reading OSM wiki / local knowledge / visiting
other web sites.  Some cases require in-person visit to the location.
Sophox is not a magic bullet that will solve all such cases, it is just a
tool to fix some of the existing issues.

If someone points out a problem, surely it's better for the
> developer to think about whether they have a point, about whether your
> software should act this way, rather than just saying "But JOSM does it!".
>
Rory, I agree that any problem raised should be analyzed. At the same time,
if an accepted tool already does something in a certain way, and noone is
raising any objections to it, I think other software should follow in the
same foot steps. Because otherwise we are saying that only existing tool
could have an otherwise discouraged practice.

> Do *you* think removing layer=0 is a good idea? What is the objection to
> removing it?
>
I think that if the community deprecates anything, it should eventually be
fixed. Otherwise we keep creating multiple ways of specifying things, and
each data consumer must understand each of them, making it progressively
harder to parse, and raising the entry bar. This is a general statement
about all deprecation, not specifically layer=0.
The objections stated by Andy are that there *could* be cases when it is
useful to indicate that something exists above/below, but hasn't been drawn
yet.  This might be a valid objection (even though it was not backed up by
any specific examples), but 1) if it caries valid info, why was it
deprecated? 2) how widespread is this usecase? 3) why are we using
deprecated tags to indicate a problem, instead of using fixme= or note= ?
4) With the existing tooling (JOSM), there are very high chances that
someone would delete this tag without realizing it is needed for something.
My tool offers a way to spot and highlight it - shouldn't we use it asap to
find all such cases?

>
> Just because someone else does a bad thing doesn't mean you have to copy
> them. Is your tool merely "JOSM validator, but with SPARQL and on the web"?
>
I haven't heard anyone saying that JOSM validator autofixes do a bad thing
until this conversation. Do you think they are bad? Richard Fairhurst said
that JOSM has been exemplary in matching community editing approaches, and
Jo Hannes mentioned that JOSM's devs are always ready to fix any kind of
issue.  So lets agree - either this is a good feature, in which case other
tools should follow similar approaches, or it's bad, in which case we
should file bug reports, and other tools should rectify it - which Sophox
tries to do already.

My tool goals are listed here, and they have very little to do with SPARQL:
https://wiki.openstreetmap.org/wiki/Sophox#Sophox_design_goals
_______________________________________________
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Reply via email to