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
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 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 any faster, either, in spite of all that C goodness! 8^)
That's the price to pay for
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 goo
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, 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
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 y
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:
htt
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 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-u
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:
- Or
On 13/05/10 17:22, Martin Davis wrote:
At the moment I haven't spent much time thinking about how to detect
these cases automatically. Of course it would be possible to switch to
using an automated buffer-and-union approach if this could be detected.
But this seems like such a pathological case I
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
prev
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
m
#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
15 matches
Mail list logo
