Union Aggregate

Coordinator
Sep 14, 2008 at 8:24 PM
[Isaac: Relocated from front-page discussion.]

bixb0012 wrote  Aug 19 at 7:07 AM 
I was glad to see SQL Server Spatial Tools show up on CodePlex. Spatial support, especially OGC-compliant, is a true milestone in the development and use of DBMSs in general. Although SQL Server 2008 finally reaches that milestone, there is plenty of room for enhancement. It is too bad the OGC standards are so mum on issues like MBR types and aggregate operators.

Moving onto more practical comments, it is great to see some aggregates showing up in these tools. A union aggregate is a good starting point, and I hope to soon see the GeometryUnionAggregate as a complement to the GeographyUnionAggregate.

The code for the GeographyUnionAggregate is very similar to the geometry UnionAggregate code posted by Steven Hemingray to the MSDN forums back in December (see 'Geometry Aggregates' thread). A subsequent comment in the thread states the posted code/algorithm is slow, and the commentor suggesst a different methodology for getting a union aggregate. Any thoughts or comments on the performance of different algorithms/approaches/methodologies for creating spatial aggregates?

Maybe I should be content with the fact that people are generously developing aggregates in the first place, but performance is just as important, if not more so, in spatial processing as in aspatial processing of information.
Coordinator
Sep 14, 2008 at 8:25 PM
[Isaac: Relocated from front-page discussion.]

tintor wrote  Tue at 8:56 AM 
One way to improve performance of union aggregate would be to first create a geometrycollection (by populating the SqlGeographyBuilder) out of all input shapes and then forcing a self-union by doing: gc.STUnion(gc.STPointN(1)).