Martijn van Oosterhout
kleptog at gmail.com
Wed Aug 13 20:43:52 BST 2008
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...
>> That would be cool. You probably do some kind of simplification also
>> and then run the process on the simplied ways with large blocks,
> 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 <kleptog at gmail.com> http://svana.org/kleptog/
More information about the dev