On Wed, Aug 13, 2008 at 9:25 PM, Jon Burgess <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 land). 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... first steps. Dave _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
