[postgis-devel] [postgis-users] Is there a reason we don't have an ST_Intersection aggregate function

[Paragon Corporation]

Okay forgot about that use case.
So we have a need for all I guess --> ST_Intersection (both array and
aggregate) similar to what we have for others and ST_UnaryIntersection
 
Just questionable (which I 'm sure Paul is thinking)
If any of these are useful enough to pollute the code base with more
functions.
 
Thanks,
Regina

  _____  

From: postgis-users-bounces at lists.osgeo.org
[mailto:postgis-users-bounces at lists.osgeo.org] On Behalf Of Rémi Cura
Sent: Monday, September 01, 2014 9:19 AM
To: PostGIS Users Discussion
Cc: PostGIS Development Discussion
Subject: Re: [postgis-users] [postgis-devel] Is there a reason we don't have
an ST_Intersection aggregate function


sorry was sent too early



2014-09-01 15:18 GMT+02:00 Rémi Cura <remi.cura at gmail.com>:


Hey,

I think you misunderstood me,

of course array of geom are not a replacement of proper use of aggregate.

It's just that in some case you cannot do with aggregate and array function
are very usefull, or the only solution.

(example :

WITH A AS (

SELECT geom1,geom2,geom3,geom4 ..

)


SELECT ST_UNion (ARRAY[geom1,geom2,..]) 


Cheers,
Rémi-c 




2014-09-01 14:39 GMT+02:00 Paragon Corporation <lr at pcorp.us>:



 
 


 >  What I target is not the unioning between the layers but inside the same
layer. The problem is the same -> to do something with more than two
geometries involved.
 

 >  Adding aggregates is really less a priority than adding support for 
>
ARRAY[geom1,geom2,geom3...] for the relevant functions.
> 
> Are you sure that the planner and indexes will manage arrays better?
 
The reason I was thinking an array of aggregates is not as useful as an
ST_Intersection aggregate is that as you intersect geometries you are using
less memory rather than more
with array you'd have to accumulate them first.
 
It really is a sequential thing.
 
That is not to say the ARRAY version isn't useful, but if you have a bunch
of geometries and then have to array them to get an intersection, then it
would be slower.
I could be wrong on that of course. Paul and Nicklas can correct me on that
since they are more familiar with the innards.
 
I have on occasion come into the situation where the things I want to get
intersection of are in separate rows rather than separate layers and it is a
tad bit annoying to work around it. Doesn't come up often though.
 
Now with 9.4 coming with the FILTER syntax now makes the across rows much
easier if I actually had an ST_Intersection aggregate that could take
advantage of it.
 

 >  Yes, I guess you are right that it would be possible to write a function
that does the job from a collection

 >  But the function will have to do the same thing. To calculate a result
from 2 polygons, then use the resulting polygon for calculation against the
third polygon and so on. Just like an aggregate function works.
 
I actually hadn't thought of our ST_UnaryUnion
http://postgis.net/docs/manual-2.1/ST_UnaryUnion.html  equivalent of
ST_Intersection  which is what I think Nicklas is talking about here.  That
would be useful as well.
That introduces another question though?
 
Would an ST_Intersection aggregate double as an ST_UnaryIntersection?
or we just keep them separate.
 
I would say keep them separate so that we have a parallel with ST_UnaryUnion
and also you can use it NOT as an aggregate to satisfy the array like need.
 
 
 
Thanks,
Regina
 
 

_______________________________________________
postgis-users mailing list
postgis-users at lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20140901/75b8e649/attachment.html>