Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#1381 closed enhancement (fixed)

[raster] two-raster ST_Intersection

Reported by: Bborie Park Owned by: Bborie Park
Priority: critical Milestone: PostGIS 2.0.0
Component: raster Version: master
Keywords: history Cc:

Description

Related spec is FV.14 with the addition of a geometry parameter being converted to raster.

Change History (3)

comment:1 by Bborie Park, 12 years ago

Status: newassigned

ST_Intersection will be a plpgsql function.

A set of ST_Intersection functions for raster, raster.

  1. ST_Intersection(

rast1 raster, nband1 int,
rast2 raster, nband2 int,
returnband text DEFAULT 'BOTH',
otheruserfunc regprocedure DEFAULT NULL

);

returnband: can be FIRST, SECOND, BOTH, OTHER

FIRST returns the band of rast1 in the intersecting extent. returning raster will have one band.
SECOND returns the band of rast2 in the intersecting extent. returning raster will have one band.
BOTH returns the bands of rast1 and rast2 in the intersection extent. returning raster will have two bands.
OTHER returns the computed band based upon rast1 and rast2 in the intersecting extent. returning raster will have one band. If OTHER, must provide a regprocedure to otherfunc

otherfunc: function to call when returnband = OTHER. Function format must be identical to tworastuserfunc of 2-raster ST_MapAlgebraFct.

  1. ST_Intersection(

rast1 raster, nband1 int,
rast2 raster, nband2 int,
otheruserfunc regprocedure

);

  1. ST_Intersection(

rast1 raster,
rast2 raster,
returnband text DEFAULT 'BOTH',
otheruserfunc regprocedure DEFAULT NULL

);

  1. ST_Intersection(

rast1 raster,
rast2 raster,
returnband text

);

  1. ST_Intersection(

rast1 raster,
rast2 raster,
otheruserfunc regprocedure

);

A set of ST_Intersection functions for raster, geometry (converted to raster).

  1. ST_Intersection(

rast raster, nband int,
geom geometry,
extent text DEFAULT 'INTERSECTION',
otheruserfunc regprocedure DEFAULT NULL

)

extent: can be INTERSECTION, FIRST, SECOND, UNION

  1. ST_Intersection(

rast raster, nband int,
geom geometry,
otheruserfunc regprocedure

);

  1. ST_Intersection(

rast raster,
geom geometry,
extent text DEFAULT 'INTERSECTON',
otheruserfunc regprocedure DEFAULT NULL

);

  1. ST_Intersection(

rast raster,
geom geometry,
otheruserfunc regprocedure

);

comment:2 by Bborie Park, 12 years ago

Keywords: history added
Resolution: fixed
Status: assignedclosed

Committed in r8434. Final specs will be found in the working specs: http://trac.osgeo.org/postgis/wiki/WKTRaster/SpecificationWorking03

comment:3 by bnordgren, 12 years ago

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?

Note: See TracTickets for help on using tickets.