Hi all. I’m currently working on a dedicated server to provide hillshaded topography with contour lines overlaid with OSM data for a project I’m working on, and found what seems to be an obvious hiccup in the shoreline_300 shapefile data. At first, I assumed it was something I did wrong, but the same problem is visible directly at http://www.openstreetmap.org/
At zoom levels <=9 (which according to the XML is where the “shoreline_300” shapefile is used), if you look just NE of Ottawa, Canada (near Trois-Rivières), you’ll see a perfectly square patch of landlocked ocean At zoom levels > 9, where “processed_p” is used, the anomaly disappears.
I’ve looked through the documentation I’ve been able to find, and though there are copious references to how to obtain shapefile_300, I wasn’t able to find anything that describes how it is generated in the first place. I’d be happy to re-generate a new shapefile_300 from existing planet OSM data (assuming that’s how it’s done), but have no idea how. Of course, the file should be fixed and re-uploaded to tile.openstreetmap.org too.
Incidentally, and just as a question of interest, what exactly does the “300” in “shoreline_300” refer to? For that matter, what is the “p” in processed_p?
I’d be grateful for any advice anyone out there may be able to offer.
The p is for polygon, and 300 is for the value in meters used in the simplification threshold done when generating shoreline_300 from processed_p.
It’s possible that the shoreline_300 and processed_p shapefiles on the server are out of synch, and that the square you see was also present in an earlier version of processed_p.
processed_p is generated from the planet data, by the Coastline error checker. As mentioned above, shoreline_300 is then derived from processed_p by running ST_Simplify(way,300) on it.
It must have been that the shapefiles on the server are out of sync, or at least were when rendering for the area was last processed, since when zoomed in to a level >9, the problem completely disappeared (it’s not a small anomaly either, and still exists on openstreetmap.org’s tile server). I solved the problem (at least for now) but setting my own XML to have a cutoff point of zoom level 3 when switching between the two shapefiles (<3, and the patch of artificial ocean is too small to be visible). So I’m using processed_p when zoomed further out, which takes a bit more time, but seems reliable enough.
Thanks for the info on how the files are generated - I’ve got some reading to do
At zoom levels > 9, where “processed_p” is used, the anomaly disappears.