OpenStreetMap
Large amount of coastline added by user who has not agreed to the new license - what to do?
Posted by compdude on 30 March 2012 in English.I was looking at the OSM Inspector in my area and found that there was a LOT of coastline (and I mean A LOT) of coastline added by a user who hasn’t accepted the new license. This link gives you just a small sample of what I am talking about, zoom out to see more. I sent the user a message and he replied expressing much dissatisfaction with the new license. We all know what that means: A large amount of coastline will be gone in two days, and there’s no way it’s going to be remapped in that short amount of time.
So what do I do to salvage that coastline? I see that there is this odbl=clean tag which basically prevents these kinds of ways from being deleted but I’m unsure about whether to use it. So any suggestions on what I should do about this?
Thanks, Compdude
(Edit: I notice that some county boundaries added by the same user have been marked with the odbl=clean tag, too.)
Discussion
Comment from Zverik on 30 March 2012 at 06:07
There was a discussing in talk@ recently about this: http://gis.19327.n5.nabble.com/ODbL-clean-Coastlines-td5591448.html
Comment from Minh Nguyen on 30 March 2012 at 06:08
The situation in Seattle is mentioned on the talk-us mailing list. There’s a proposal to replace this part of the coast with Canadian GeoBase data.
Comment from asciipip on 30 March 2012 at 20:18
The odbl=clean tag is probably not the way to go for this. That tag means, roughly, “There are people in the edit history of this object who have not agreed to the new license, but I’m saying that its current state is not at all derived from those people’s contributions.” For the coastline, all of its nodes’ positions are from people who haven’t agreed to the new license, and the only way to get it compatible would be to retrace the entire thing. And, as mentioned above, people are looking at ways to replace this tainted data all long the West Coast of the US.
Also, it won’t be horrible if some coastline data is removed during the license changeover. Most renderings don’t use that data directly: they use shapefiles derived from the data, so we can continue to use the old shapefiles until the coastlines are ready to generate new ones. The missing data will still have to dealt with, but we have more time to do it than it might at first appear.
Comment from compdude on 31 March 2012 at 01:04
Lots of of talk and not much action, it seems. This really is a big issue and there has got to be something done about it soon!
Comment from Fabi2 on 31 March 2012 at 17:39
There ist also a coastline map by suncobalt, which was updated today: http://suncobalt.homeip.net:82/coastline.php
Comment from chriscf on 1 April 2012 at 01:00
Depends on what their source is. If they’ve imported it from a public-domain source, then it’s not theirs, plain and simple - that would be an example where it would be safe to odbl=clean it. If the decliner has actually moved things, or has traced from something else, then odbl=clean would not be suitable. Something that would have been nice was the opposite odbl=dirty to explicitly tag objects known to come from incompatible sources, though understandably this would have been open to abuse by TWSNBN.
Comment from compdude on 4 April 2012 at 17:12
@chriscf, what you just said is exactly opposite of what I originally thought. I added the odbl=clean to coastline ways where another user (who had accepted the license) had improved on the lousy PGS import data, but I didn’t know I could slap this tag on things they originally added. That makes sense because the data that they added wasn’t really theirs.
And the fact that the odbl= clean tag was added to administrative boundaries created by the same user gives us all the more reason to tag coastlines as such.
Comment from compdude on 5 April 2012 at 16:39
That’s good, most of the coastline has been replaced with Canadian GeoBase data which is of much better quality than the PGS coastline data. I’m glad someone stepped up and did this. Thank you to whoever took care of that!