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.
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