[OSM-talk] ODbL-clean Coastlines
reviews at pacific-rim.net
Sat Mar 24 11:13:43 GMT 2012
----- Original Message -----
From: "Paul Norman" <penorman at mac.com>
To: <talk at openstreetmap.org>
Sent: Saturday, March 24, 2012 9:34 AM
Subject: [OSM-talk] ODbL-clean Coastlines
>I have been running a nightly coastline generation on my server, using the
> latest data from my jxapi server. Tonight I switched it over to filter out
> data that WTFE reports as dirty. This is somewhat more aggressive than the
> rebuild will be, but the results are worrisome.
> A PNG showing the OSM coastline post-transition along with red dots for
> where the coastcheck program found errors is at
> The red dots represent places where coastcheck found an error
> A few things can be seen:
> No continent will generate a satisfactory rendering. Australia, the US,
> of Africa and most of Eurasia from 50 degrees south will be completely
thanks a lot for generating this, the situation is far worse than I had
thought it was going to be.
> There are 3471 points where coastcheck found errors. Normally I would
> about 10.
> The following areas are particularly bad:
> The west coast of the US
> The US coast of the Great Lakes
> Antarctica (which has significant parts completely missing with no error
> points since there's nothing left to even try to close)
> When examining the data, I found most of the ODbL-dirty status was mainly
> from the following accounts:
> hasse_osm_korinthenkacker (Antarctica)
> Kin (Antarctica)
> Blars (US West coast)
> I see a few ways for dealing with the coastlines:
> - Remapping. Obviously this is the only option where the coastline was
> actually created by the non-acceptor.
One advantage of remapping is the possibility that there are now better data
sets available for import than the PGS data which was originally used. I'm
particularly thinking here of the US & Canada.
> - Adopting changesets. Many of the dirty ways and nodes appear to be
> imported. If the imported just imported PD data than they have no IP in
> ways and they can be retained.
Are you saying that it is impossible for data originally derived from PD to
ever have IP in it, no matter what else is subsequently done to it?
> - odbl=clean. It's generally easy to verify that a way is a coastline from
There is I think one other option. Since a pretty much error free
processed_p.shp file will be available just up to the licence switch over,
then is it not legally possible to continue use this file in Mapnik combined
with post switch over OSM data to create the maps. The missing coastline in
OSM can then be re-mapped on a more leisurely basis.
> My coastline files are available in the usual location of
> http://pnorman.dev.openstreetmap.org/coastlines/ but are named
> and processedc_p. processedc_p has not yet uploaded but will be complete
> about an hour.
> Additional detail of some regions can be found at
> If opening processedc_p in QGIS be sure to make a spatial index or it will
> A refresher on coastlines for those who haven't tagged them in awhile:
> Direction *matters*. Land on the left, water on the right.
> Each end of each way should join with exactly one other natural=coastline
> I am not sure when each processedc_p file will be completed. Cron starts
> job at 5 AM PST and I'd expect it to take about 5 hours, mainly depending
> WTFE server speed and my upload speed to errol. The coastlinec_p files
> be uploaded first so arrive at the server earlier.
> Technical details:
> The results of the jxapi way[natural=coastline] is filtered by cleanway to
> remove any objects reported as severity=normal, leaving behind 0 or 1 node
> ways if necessary. It then is passed to the coastcheck programs and the
> results uploaded.
> A CT-clean way to which a decliner added a tag other than
> would be removed by this algorithm, but not by the rebuild.
> talk mailing list
> talk at openstreetmap.org
More information about the talk