<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7652.24">
<TITLE>RE: [postgis-devel] More Cascade Union Adventures</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Martin,<BR>
Haven't looked at the code yet, but just realized that yes that I think you are describing can be expressed in just SQL with what I will<BR>
call a CROSS JOIN boolean_or (g would be the geometries all dumped out into their constituent geometries)<BR>
<BR>
So looks something like this<BR>
<BR>
SELECT ST_Collect(s.geom) As newgeom<BR>
FROM (SELECT g1.id, g1.geom, boolean_or(g1.geom && g2.geom) As has_intersect<BR>
FROM g As g1 CROSS JOIN g As g2<BR>
WHERE g1.id <> g2.id<BR>
GROUP BY g1.id, g1.geom) As s<BR>
GROUP BY<BR>
CASE WHEN s.has_intersect<BR>
THEN s.id ELSE -1 END<BR>
<BR>
Would collect together all parts that have no intersections and leave the others as separate individual geometries, then I perform my union operation against the above new set.<BR>
<BR>
Not sure how efficient the above would be to do, but I suspect if I do in batches which are ordered, may be quite efficient.<BR>
<BR>
Anyrate I'll give it a go.<BR>
<BR>
Thanks,<BR>
Regina<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: postgis-devel-bounces@postgis.refractions.net on behalf of Martin Davis<BR>
Sent: Thu 8/14/2008 11:55 AM<BR>
To: PostGIS Development Discussion<BR>
Subject: Re: [postgis-devel] More Cascade Union Adventures<BR>
<BR>
You can download JTS 1.9 (with src) from Sourceforge:<BR>
<BR>
<A HREF="http://sourceforge.net/projects/jts-topo-suite/">http://sourceforge.net/projects/jts-topo-suite/</A><BR>
<BR>
Obe, Regina wrote:<BR>
><BR>
> Martin,<BR>
> Well there is plpgsql too which is very procedural so doesn't have to<BR>
> be expressed in sql per se. I use sql because it is generally<BR>
> speedwise faster for the planner to integrate and easier to prototype<BR>
> with (at least for me since I can get my thoughts down more succinctly<BR>
> granted probably harder to read for others) than plpgsql.<BR>
><BR>
> If we replace the garray accum with a custom append - it can also look<BR>
> at the geometries as they are coming in and perhaps do a collect<BR>
> instead of an append and do some other conditional stuff.<BR>
><BR>
> Where would I download this code to see what it looks like (JTS site<BR>
> only seems to go to JTS 1.8). I'm having a hard time picturing what<BR>
> you are saying. But if I see it in Java I can probably figure out the<BR>
> most efficient translation in sql/plpgsql.<BR>
><BR>
> Thanks,<BR>
> Regina<BR>
><BR>
> -----Original Message-----<BR>
> From: postgis-devel-bounces@postgis.refractions.net on behalf of<BR>
> Martin Davis<BR>
> Sent: Wed 8/13/2008 8:08 PM<BR>
> To: PostGIS Development Discussion<BR>
> Subject: Re: [postgis-devel] More Cascade Union Adventures<BR>
><BR>
> While pondering OJ's failure to complete the union on this dataset, I<BR>
> realized that one trick that CascadedUnion uses is that when unioning<BR>
> two MultiPolygons, it *avoids* unioning polygon components which lie<BR>
> outside the intersection of the envelopes of the two input geometries.<BR>
> Those polygon components will be left unchanged by the union, and so can<BR>
> just be added in afterwards. This can make a big difference when large<BR>
> far-flung polygons are being unioned - as is the case with this dataset.<BR>
><BR>
> Not sure if you can use this technique in your algorithm - seems like it<BR>
> might be tricky to express in SQL.<BR>
><BR>
> Obe, Regina wrote:<BR>
> ><BR>
> > Try this set. - this has 2895 records<BR>
> ><BR>
> > My timings are<BR>
> > ---time 161,047 ms = SELECT 161047/1000.0/60 = 2.68 minutes<BR>
> > SELECT ST_CascadeUnion(the_geom)<BR>
> > from usstatebounds;<BR>
> ><BR>
> > --time 121719 ms = SELECT 121719/1000.0/60 = 2.02 minutes<BR>
> > SELECT st_unitecascade_garray_sort(ARRAY(SELECT the_geom FROM<BR>
> > usstatebounds));<BR>
> ><BR>
> > In OJ - it gets to the last round and then fails with a Java out of<BR>
> > Heap space error.<BR>
> ><BR>
> ><BR>
> > ------------------------------------------------------------------------<BR>
> ><BR>
> > *The substance of this message, including any attachments, may be<BR>
> > confidential, legally privileged and/or exempt from disclosure<BR>
> > pursuant to Massachusetts law. It is intended solely for the<BR>
> > addressee. If you received this in error, please contact the sender<BR>
> > and delete the material from any computer. *<BR>
> ><BR>
> > ------------------------------------------------------------------------<BR>
> ><BR>
> > * Help make the earth a greener place. If at all possible resist<BR>
> > printing this email and join us in saving paper. *<BR>
> ><BR>
> > * *<BR>
> ><BR>
> > * *<BR>
> ><BR>
> > ------------------------------------------------------------------------<BR>
> ><BR>
> > _______________________________________________<BR>
> > postgis-devel mailing list<BR>
> > postgis-devel@postgis.refractions.net<BR>
> > <A HREF="http://postgis.refractions.net/mailman/listinfo/postgis-devel">http://postgis.refractions.net/mailman/listinfo/postgis-devel</A><BR>
> > <BR>
><BR>
> --<BR>
> Martin Davis<BR>
> Senior Technical Architect<BR>
> Refractions Research, Inc.<BR>
> (250) 383-3022<BR>
><BR>
> _______________________________________________<BR>
> postgis-devel mailing list<BR>
> postgis-devel@postgis.refractions.net<BR>
> <A HREF="http://postgis.refractions.net/mailman/listinfo/postgis-devel">http://postgis.refractions.net/mailman/listinfo/postgis-devel</A><BR>
><BR>
><BR>
> ------------------------------------------------------------------------<BR>
><BR>
> _______________________________________________<BR>
> postgis-devel mailing list<BR>
> postgis-devel@postgis.refractions.net<BR>
> <A HREF="http://postgis.refractions.net/mailman/listinfo/postgis-devel">http://postgis.refractions.net/mailman/listinfo/postgis-devel</A><BR>
> <BR>
<BR>
--<BR>
Martin Davis<BR>
Senior Technical Architect<BR>
Refractions Research, Inc.<BR>
(250) 383-3022<BR>
<BR>
_______________________________________________<BR>
postgis-devel mailing list<BR>
postgis-devel@postgis.refractions.net<BR>
<A HREF="http://postgis.refractions.net/mailman/listinfo/postgis-devel">http://postgis.refractions.net/mailman/listinfo/postgis-devel</A><BR>
<BR>
<BR>
<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>