[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