[OSM-talk] Making dealing with license problem objects easier
David Earl
david at frankieandshadow.com
Wed Jan 4 15:50:04 GMT 2012
Now that we have Frederik's very helpful license vulnerability tool,
I've been doing some pre-emptive work in my area. Without re-opening old
wounds about the merit or otherwise of the forthcoming data loss, I'd
like to make some suggestions arising out of the patterns I've noticed
that mean we don't shoot ourselves in the foot quite so much.
It's really time consuming making these changes and there are a lot of
them. There is a fairly small number of people (about 20) in my area who
have not accepted (and two who have explicitly declined). I imagine most
of the non-accepters are just no longer receiving email - I have had
only one reply to my messages.
While there are a few places I can't deal with, e.g. because I can't see
from Bing what's going on, or I don't personally know the name of
something, in the majority of cases I can verify something from
satellite, OSSV, local knowledge or my own previous surveys.
However, to fix these I have to not only remove e.g. the offending way
but also carefully check or replace all the nodes for connecting
features because those are often independently contaminated. This
process also loses the continuous history of the feature. It's
particularly fiddly (and easy to miss) when objects are part of a number
of relations.
Suggestion 1
I'd like to suggest we invent a tag which says "I have checked this
object for changes by non-accepters and personally verified it against
sources independent of the changes of those non-accepters who made
changes", so that when that tag is added, the changes the non-accepter
made become my responsibility.
e.g. verifylicense=bing ("I checked it against bing") or
verifylicense=bing;local_knowledge ("I checked the route on Bing and I
personally know the name")
This way we don't have to do lots of unnecessary deleting and replacing,
and we keep the history.
Frederik's tool could take account of this tag in what it displays as
vulnerable.
Suggestion 2
A very common pattern is
* non-accepter adds a feature F which is joined to one or more ways W at
node new N; this contaminates the whole of W even though all they've
done is inserted a node into it.
* lots of other people make changes to W in other respects, whose edits
would be lost
In this case, I think it would be reasonable to say that if N is
inserted between two other nodes such that the three form a straight
line (to within some fairly generous tolerance) that the way is not
affected and the node can be removed from it along with the genuinely
offending way without affecting the one involved as a side effect, and
needn't be marked as such in the inspector.
Suggestion 3
There is a particularly pernicious pattern where user 'ulfl' (others
too, but by far the most prolific) went round some years ago changing
lots of tag names without changing anything else, and he has now
explicitly declined the CT, so there are now lots of real changes on top
which will be lost because of these purely mechanical changes.
I think we should not count these as significant edits for the purposes
of the license change. If someone changes shop=barbers to
shop=hairdressers etc, these are admin changes not geographical ones. If
ulfl is still on this list, would you agree or object?
David
More information about the talk
mailing list