[postgis-devel] [PostGIS] #1381: [raster] two-raster ST_Intersection

[PostGIS]

#1381: [raster] two-raster ST_Intersection
-----------------------------+----------------------------------------------
  Reporter:  dustymugs       |       Owner:  dustymugs    
      Type:  enhancement     |      Status:  closed       
  Priority:  critical        |   Milestone:  PostGIS 2.0.0
 Component:  postgis raster  |     Version:  trunk        
Resolution:  fixed           |    Keywords:  history      
-----------------------------+----------------------------------------------

Comment(by bnordgren):

 THis is the first example of how to use the raster iterator.

 https://github.com/bnordgren/postgis/blob/ri-
 gen2-svn/raster/rt_pg/rt_pg.c#L9726

 That function will do any of intersection, difference, symdifference, or
 union between two individual raster objects, returning raster. Similar
 functions may be constructed for vector/raster, raster/vector (order
 doesn't make a difference for intersection, but will for difference.)

 It can handle multiple bands from both rasters (but requires the same
 number of bands from each.)

 It is currently optimized for "return the value from the first raster
 unless NODATA, in which case, return the value from the second raster." It
 really seems bizarre to hardcode "FIRST" or "SECOND" in an intersection
 operation, as that describes "subset" or ST_Clip...particularly in the
 alternatives: geom/raster, raster/geom.

 It does handle on the fly reprojection, but that can be disabled if it's
 unwanted.

 Mostly, it should be instructive to see the code as an example of how to
 use the SPATIAL_COLLECTION type to set up an on-demand computation chain
 which is then queried for a value at each cell location in the output
 raster. It should also demonstrate that once code is written against the
 SPATIAL_COLLECTION type, it suddenly doesn't matter whether the input was
 an LWGEOM or a rt_raster--and that's for each link in the processing
 chain. You can squeeze a lot of reuse out of this because you don't need
 special code for each combination.

 If I adapt this particular function so it matches the signature on this
 ticket, does this sound like a good target for an "initial example of the
 framework"? Is that going to be concrete enough for you guys to evaluate?

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