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... >> 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. > 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 :) Have a nice day, -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
