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: [email protected] [mailto:[email protected]] 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 <[email protected]>: 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 <[email protected]>: > 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 [email protected] http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
_______________________________________________ postgis-users mailing list [email protected] http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
