#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 , 13 years ago
Status: | new → assigned |
---|
comment:2 by , 13 years ago
Keywords: | history added |
---|---|
Resolution: | → fixed |
Status: | assigned → closed |
Committed in r8434. Final specs will be found in the working specs: http://trac.osgeo.org/postgis/wiki/WKTRaster/SpecificationWorking03
comment:3 by , 13 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?
ST_Intersection will be a plpgsql function.
A set of ST_Intersection functions for raster, raster.
);
);
);
);
);
A set of ST_Intersection functions for raster, geometry (converted to raster).
)
);
);
);