[OSM-dev] coastline

Jon Burgess jburgess777 at googlemail.com
Wed Aug 13 21:25:05 BST 2008

On Wed, 2008-08-13 at 21:43 +0200, Martijn van Oosterhout wrote:
> On Wed, Aug 13, 2008 at 9:34 PM, Jon Burgess <jburgess777 at googlemail.com> wrote:
> >> 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.
> Indeed. I store the simplified shapes in, wait for it, a temporary
> file :) If you have some code to cache shapes in memory then we can
> really kick ass...

I've put my changes into a branched version of the file, you can see
them at: http://trac.openstreetmap.org/changeset/9804

> >> 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.
> Ouch. I was thinking of doing it internal to closeshp but I hadn't
> decided on how to simplify it. Since it's happening after the line
> merging it should work better than your approach.

Initially I was also doing it to speed up the closeshp processing, I
guess this isn't required any more.

> > 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.
> Hmm, something like that might work easily also. The overlap is a nice
> and quick way though :)

Even with a large overlap the squares are still visible at zoom 2. I'm
not sure this is a big problem though. I was going to try running the
code again with DIVISION=1. Last time I tried I got a segv after about 5
hours in SHPDestroyTree(). It looked like a buffer or array overflow.
Perhaps something between 1 and 400 with a larger overlap would work.


More information about the dev mailing list