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

[PostGIS]

#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 pracine):

 Robe, not following you as well. Why adding ST_Clip in the mix if you want
 to test just ST_Union? Quite confusing.

 What I mean is that ST_Union (the C or the plpgsql version) on raster,
 please Bborie tell me if I'm wrong, suffers from two problems:

 1) You can not append a raster to a raster without creating a new raster
 (unlike the geometry type). So the state function will always have to
 recopy the previous raster, creating a new one, before appending the
 passed raster. So your assumption about no more need to copy the raster is
 false. ST_Union for raster will always suffer from that because it is
 inherent to the raster data structure. This is why I think more and more
 that aggregating raster with a PostgreSQL aggregate is not the way to go
 to merge tiles. It would be easier if PostgreSQL AGGREGATE would allow to
 pass an initial function, executed before the beginning the state cycle,
 that would do a first pass on the the raster to aggregate. A kind of two
 passes aggregate. This would allows us to precompute the extent of the
 final raster and then we would just have to copy tiles into it as they
 come and your assumption would be right. This problem worsen when the size
 of the tiles get smaller. That was my point above. And this why the time
 needed will always grow like the square of the number of pixels for a
 constant tile size. At some point, with really big tiled images, that make
 unioning unpracticable.

 2) At every state, when we copy the previous raster to the new state one,
 we could just copy it with a fast line by line memcpy, but no, we copy it
 trying to apply the more complex ST_Union function (like 'MEAN') to the
 whole new raster. We could improve this by applying the 'MEAN' only to the
 changing part of the extent. This is the optimization Bborie was speaking
 about. But this does not broom the first problem.

 So a better test, for me, is to test only ST_Union with bigger images,
 keeping the tile size constant. You should still see a polynomial
 progression. Not a linear one. I have no doubt that the C implementation
 does better than the plpgsql one and that you will have to work with even
 bigger images to see the line curving straight to the sky...

 I wish I would be wrong.

-- 
Ticket URL: <http://trac.osgeo.org/postgis/ticket/2024#comment:24>
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.