[postgis-devel] More Cascade Union Adventures
Martin Davis
mbdavis at refractions.net
Thu Aug 14 08:55:17 PDT 2008
You can download JTS 1.9 (with src) from Sourceforge:
http://sourceforge.net/projects/jts-topo-suite/
Obe, Regina wrote:
>
> 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
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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
More information about the postgis-devel
mailing list