Glitch in shoreline_300 data

charrois · 2010-10-13T05:17:08.000Z

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.

Dan

stephan75 · 2010-10-13T15:03:45.000Z

More infos at http://help.openstreetmap.org/questions/276/why-do-the-changes-i-have-made-to-coastline-not-appear-on-the-map ?

Ldp · 2010-10-14T20:56:26.000Z

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.

charrois · 2010-10-15T02:01:13.000Z

Thanks, stephan75 and Ldp, for your responses!

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

Dan