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. Jon _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
