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:
-
On Fri, May 14, 2010 at 03:09:40PM +0200, 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
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
On Fri, May 14, 2010 at 09:11:30AM -0700, Martin Davis wrote:
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.
The input I'm using is this:
Ah, ok. I was using this one.
http://trac.osgeo.org/geos/attachment/ticket/344/fail_geom.txt.gz
I'll try the other one and see what kind of performance I get.
strk wrote:
On Fri, May 14, 2010 at 09:11:30AM -0700, Martin Davis wrote:
I'm surprise that PostGIS is so much faster too! Can
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.
Martin Davis wrote:
Ah, ok. I was using this
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
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
Yes, that would be very interesting. Does GGL provide polygon union now?
strk wrote:
On Fri, May 14, 2010 at 02:28:39PM -0700, Martin Davis wrote:
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
On Fri, May 14, 2010 at 03:05:29PM -0700, Martin Davis wrote:
Yes, that would be very interesting. Does GGL provide polygon union now?
Seems so:
http://geometrylibrary.geodan.nl/group__union.html
--strk;
() Free GIS Flash consultant/developer
/\ http://strk.keybit.net/services.html
#343: After applying a buffer over a multiline the library starts growing in
memory usage and hungs
+---
Reporter: sberna | Owner: geos-devel@lists.osgeo.org
Type: defect | Status: new
Yikes! That's one nasty dataset. JTS has issues with it as well - I
wasn't able to get the buffer to complete.
As a workaround, you could buffer each line separately and then
UnaryUnion the results.
GEOS wrote:
#343: After applying a buffer over a multiline the library starts growing in
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.
This geometry is pretty much a poster child for things that defeat the
optimizations used in buffering. It has lots of small geometries, thus
13 matches
Mail list logo
