[postgis-devel] [PostGIS] #2024: raster: ST_Union is buggy

PostGIS trac at osgeo.org
Fri Oct 5 08:57:02 PDT 2012

#2024: raster: ST_Union is buggy
  Reporter:  robe     |       Owner:  dustymugs    
      Type:  defect   |      Status:  closed       
  Priority:  blocker  |   Milestone:  PostGIS 2.1.0
 Component:  raster   |     Version:  trunk        
Resolution:  fixed    |    Keywords:               

Comment(by dustymugs):

 For each part...

 1. Mostly correct.  What isn't correct is that you're not just copying
 your old working raster to your new working raster.  The new working
 raster will more than likely have a different extent.  A two pass
 aggregate would be nice to have but I'm not expecting it from PostgreSQL.

 2. You could do a line by line memcpy of the intersecting parts from the
 old working raster to the new working raster but I don't know how much
 time that would save.  The MEAN uniontype is the most entertaining of the
 union types as it requires two parallel actions, a COUNT and a separate

 Due to the size of raster tiles, there is no way to use the same method
 used for ST_Union(geometry).  There, the geometries are collected into an
 array and then processed at the end with the final aggregate function.
 This means that all the geometries are stored in memory to the end.  If we
 tried that with rasters, you'll probably run out of memory before getting
 to the end.

 Realistically, we should only be expecting the following:

 1. Is the ST_Union in 2.1 faster than 2.0?

 2. Is the output from ST_Union in 2.1 correct?

 Exploring places to optimize ST_Union would be great... but there are
 other problems to resolve for 2.1.0.  Maybe 2.1.1.

Ticket URL: <http://trac.osgeo.org/postgis/ticket/2024#comment:25>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.

More information about the postgis-devel mailing list