[postgis-devel] More Cascade Union Adventures

[Obe, Regina]

Martin,
Well there is plpgsql too which is very procedural so doesn't have to be expressed in sql per se. I use sql because it is generally speedwise faster for the planner to integrate and easier to prototype with (at least for me since I can get my thoughts down more succinctly granted probably harder to read for others) than plpgsql. 

If we replace the garray accum with a custom append - it can also look at the geometries as they are coming in and perhaps do a collect instead of an append and do some other conditional stuff.

Where would I download this code to see what it looks like (JTS site only seems to go to JTS 1.8).  I'm having a hard time picturing what you are saying.  But if I see it in Java I can probably figure out the most efficient translation in sql/plpgsql.

Thanks,
Regina

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net on behalf of Martin Davis
Sent: Wed 8/13/2008 8:08 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] More Cascade Union Adventures
 
While pondering OJ's failure to complete the union on this dataset, I 
realized that one trick that CascadedUnion uses is that when unioning 
two MultiPolygons, it *avoids* unioning polygon components which lie 
outside the intersection of the envelopes of the two input geometries.  
Those polygon components will be left unchanged by the union, and so can 
just be added in afterwards.  This can make a big difference when large 
far-flung polygons are being unioned - as is the case with this dataset.

Not sure if you can use this technique in your algorithm - seems like it 
might be tricky to express in SQL.

Obe, Regina wrote:
>
> Try this set.  - this has 2895 records
>
> My timings are
> ---time 161,047 ms = SELECT 161047/1000.0/60 = 2.68 minutes
> SELECT ST_CascadeUnion(the_geom)
> from usstatebounds;
>
> --time 121719 ms = SELECT 121719/1000.0/60 = 2.02 minutes
> SELECT st_unitecascade_garray_sort(ARRAY(SELECT the_geom FROM 
> usstatebounds));
>
> In OJ - it gets to the last round and then fails with a Java out of 
> Heap space error.
>
>
> ------------------------------------------------------------------------
>
> *The substance of this message, including any attachments, may be 
> confidential, legally privileged and/or exempt from disclosure 
> pursuant to Massachusetts law. It is intended solely for the 
> addressee. If you received this in error, please contact the sender 
> and delete the material from any computer. *
>
> ------------------------------------------------------------------------
>
> * Help make the earth a greener place. If at all possible resist 
> printing this email and join us in saving paper. *
>
> * *
>
> * *
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022

_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20080814/626b161a/attachment.html>