[OSM-dev] coastline

[Jon Burgess]

On Wed, 2008-08-13 at 20:53 +0200, Martijn van Oosterhout wrote:
> On Wed, Aug 13, 2008 at 8:37 PM, Jon Burgess <jburgess777 at googlemail.com> wrote:
> >> FWIW, I've fixed the process so it's much quicker now, only a couple
> >> of hours, probably less than it takes to load the planet dump.
> >
> > Could you put the changes in SVN?
> 
> Can do. Give me an hour.
> 
> > I've just been tweaking the closeshp code to fix some bugs and currently
> > have it running about 10 times faster by holding all the shapefiles in
> > memory (needs around 1GB of ram).
> 
> I approached it the other way: I generate simplified versions of the
> really long ways (the multi-million point ones) and work out which
> tiles don't intersect with any of them. For the no intersection tiles
> (>90% of them) it only looks at the simplified ways. Much much faster.

Perhaps we can do both and have it finish in a minute or two. My changes
need some cleaning up if we want the ram caching to be optional.

> > I've also been experimenting with changes to allow it to generate
> > shapefiles suitable for lower zoom levels.
> 
> That would be cool. You probably do some kind of simplification also
> and then run the process on the simplied ways with large blocks,
> right?

Yes, this is where I started. I ran the coastline.osm.gz through the
simplify.pl script and then used that for the rest of the processing.
Unfortunately the results were quite bad in some places. The general
point simplification results in multiple ways ending at a single point
and that confuses the line merging algorithm.

Right now I'm falling back to the simpler approach of massive increasing
the overlap. A 10% overlap should be good enough for all or almost all
zooms. This increases the file size by roughly 20%. Then I'll simplify
the resulting shapefiles using the postgis simplify(). I started this
off last night but I'm repeating the process with the new planet dump.

There is probably a middle ground. The initial simplification would
probably work if the start/end points were always left unchanged. There
should be much less of a problem if we only simplify the mid-points.

	Jon