Ok, then that's in the same ballpark as JTS. And yes, the union is much
slower than the buffer creation.
Interesting that GEOS seems to have caught up to JTS in terms of
performance. I seem to remember it used to be slower. (But it's not
really any faster, either, in spite of all that C goodness! 8^)
strk wrote:
On Fri, May 14, 2010 at 11:35:45AM -0700, Martin Davis wrote:
Ok, I tried the roads_broken geometry in JTS using the buffer-and-union
approach. The result matches the one you posted, strk.
Time was 2.7 s. So the two systems are pretty close.
It would be interesting if you tried the other geometry as well.
Done, but on another (older) machine:
Intel(R) Pentium(R) 4 CPU 2.66GHz
bogomips : 5333.43
Input points: 11502
Input components: 5615
Output points: 417
$ time psql -c ' select st_npoints(st_union(st_buffer(geom, 0.005)))
from ( select (st_dump(g)).geom from bug ) as foo; '
real 1m9.838s
user 0m0.100s
sys 0m0.028s
Memory is fine, CPU is pretty much fixed at 100%.
Interesting enough the buffer itself is pretty quick:
$ time psql -c ' select sum(st_npoints(st_buffer(geom, 0.005)))
from ( select (st_dump(g)).geom from bug ) as foo;'
real 0m3.170s
user 0m0.108s
sys 0m0.024s
--strk;
() Free GIS & Flash consultant/developer
/\ http://strk.keybit.net/services.html
_______________________________________________
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
_______________________________________________
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
