I'm surprise that PostGIS is so much faster too! Can you supply the
output, so I can check it against JTS?
One thing I notice is that the input I'm using has 5615 elements and
11502 points.
This *might* make a big difference, if you are missing some of the
bigger linestrings which (a) have large buffer polygons and (b)
intersect *all* of the other elements' buffers.
strk wrote:
On Thu, May 13, 2010 at 09:22:49AM -0700, Martin Davis wrote:
Just tried the buffer-and-union approach in JTS. It works fine - about
70 s for the union, less for the initial buffering. Memory usage was low.
I tried buffer-and-union approach in PostGIS.
It was very fast !
Some stats:
- Original geometry is a MULTILINESTRING with 3272 components
- Average number of points per component: 3.3 (from 2 to 93)
- Total number of points: 10677
Postgis operations with timing:
$ time psql -c 'create table bug_dump2 as select (st_dump(g)).* from bug;'
real 0m0.330s
user 0m0.032s
sys 0m0.012s
$ time psql strk -c 'update bug_dump2 set geom = st_buffer(geom, 0.005)';
UPDATE 3272
real 0m0.463s
user 0m0.040s
sys 0m0.008s
$ time psql strk -Ac 'select st_npoints(st_union(geom)) from bug_dump2';
st_npoints: 1336
real 0m1.181s
user 0m0.040s
sys 0m0.008s
This is postgis trunk (to be 2.0.0) with GEOS trunk (to be 3.3.0).
I'm surprised it takes 70 seconds with JTS. Am I doing anything wrong here ?
--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
