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
