osm.list at randomjunk.co.uk
Thu Aug 14 09:43:54 BST 2008
On Wed, Aug 13, 2008 at 9:25 PM, Jon Burgess <jburgess777 at googlemail.com> wrote:
> 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.
If it's any help the current cyclemap is running with OSM coastlines
at all zooms -- we're using inverted coastlines (ie: painting sea, not
What I did was set DIVISIONS=100 and the overlap to 10% of a tile...
that works fine.
Unfortunately I didn't run anything through any simplifiers... so it
takes bloomin ages to render each tile at zooms 1-3... but still...
More information about the dev