[postgis-devel] [raster] Architecture wiki document contribution

[Bryce L Nordgren]

On Thu, Jun 30, 2011 at 6:22 PM, Pierre Racine
<Pierre.Racine at sbf.ulaval.ca>wrote:

>
> -My basic idea has always been that you do the operation in vector or
> raster mode. ... So either you rasterize vectors, or vectorize rasters
> before doing those fundamental operations.
>
> -We have the major constraint that it is very often impossible to vectorize
> completely a raster coverage to a vector coverage. It produce way too many
> geometries.
>


> 3) Most naturally binary vector operations (like intersection, union,
> difference) should be available with a mix of raster and vector and a mix of
> two rasters as inputs. They are already available with a mix of two vectors.
> They should always be done in vector mode (except when both inputs are
> rasters). If one input is a raster, you ST_DumpAsPolygons() it. This has a
> strong limitation when the raster area involved is large and has to be
> vectorized. My answer to this are statistical functions taking geometries
> because we generally do these operations to get summaries of raster values
> in the area involved.
>

If I may offer a suggestion here:  if you're returning a raster, you only
need to evaluate the inputs on each cell in the raster output. So, if the
input is a vector, test whether the cell intersects the vector. If the input
is a raster, you calculate the index into the raster, ensure it is valid,
then lookup the value. If the index is valid (in range) and the value is not
nodata, the raster intersects the grid cell. You then calculate the spatial
operation for the cell with a simple boolean expression relating the two
tests. Union would be (test1 || test2); intersection: (test1 && test2),
difference: (test1 && !test2) etc. You then know whether the pixel is inside
or outside. If you were returning a vector, you may have to DumpAsPolygons
the raster input, but I haven't given as much thought to that. The main
point is: I would suggest that how you treat the inputs may depend on what
you're returning.

This is covered in the Result Grid Iteration Engine:
http://trac.osgeo.org/postgis/wiki/WKTRaster/SeamlessArchitecture#Result-Grid-Iteration-Engine



> 4) Most naturally binary raster operations (like map algebra, I can't think
> of any other...) should be available with a mix of raster and vector, a mix
> of two rasters and a mix of two vector as input.  They should be always be
> done in raster mode (maybe with the exception of tow vector input but this
> is essentially a vector intersection with computation over some attributes
> so we can map the geometric part of it to ST_Intersection(geometry,
> geometry) and return the result of the expression with it in a geomval
> object).
>

This is a prime example of why we need the architecture document. The
separation of information types from data types is an essential concept to
un-ambiguating that paragraph. ("Binary raster operations...with raster and
vector, ...two rasters, ... and two vectors as input." ?!?!!! How is
something that takes two vectors possibly considered a binary raster
operation?) If I may restate it using the concepts in the document:

"Operations which accept two Spatial+Value inputs and return a Spatial+Value
output may accept or return any mix of geometry-value or raster data types.
They may not accept or return geometries. Map Algebra is an example. "

There are two worked examples of how to define seamless spatial operations
using this separation of information type from data type; mostly because
trying to define them strictly in terms of data type is very confusing. This
is actually a trivial example. The other trivial example is "binary vector
operations" where two Spatial Only inputs produce a Spatial Only output.
Everything in between is more complicated. Check out this section:

http://trac.osgeo.org/postgis/wiki/WKTRaster/SeamlessArchitecture#Expected-Results-and-Information-types



> I think users always expect to get values when they do these operations.
> This is why I don't believe pure spatial operation are useful.
>

I use ST_Polygonize. Don't take it away. I'd expect Postgis Raster to be
capable of producing Spatial Only information (e.g., a mask or geometry)
representing the extent of any basic spatial operation. I also expect it to
be capable of producing either Spatial+Value type for those same operations.
It all depends on what I'm doing next in the processing chain.


> I also don't think introducing the concept of mask is also necessary. We
> can do every operations without masks. In any case, nodata values can be
> interpreted as zeros and withdata value can be interpreted as non-zeros
> depending on the context. We don't need masks to do mapalgebra.
>

Masks are not (only) a MapAlgebra tool. They are how Spatial Only
information is encoded in the raster data type. They are equivilent to
geometries. They may participate anywhere the Spatial Only information type
is specified, but they may not participate where Spatial+Value is specified.
You may import them from an external system (e.g., ENVI) which had access to
information not present in Postgis Raster. They can be produced when no
value information is available (rasterizing an arbitrary geometry). They can
be exported to external systems which may require this simple representation
because they are not so geospatially keen as Postgis Raster (e.g.,
ImageMagick or the GIMP; transparency comes to mind). If things which return
spatial+value information could initialize their basic raster properties
(position of UL corner, cell size, extent, etc.) from a mask, the result
would be inherently aligned. Using the same mask more than once would give a
set of aligned products.

One subtle point: MapAlgebra is essentially a band math operation (operates
on single bands of rasters). It is not a raster operation (operates on all
bands). The C implementation is capable of being both via extension points.
The current "pixel copy" value op copies all of the bands to the
target...with one pass thru the raster. This is important for RGB or other
multiband imagery.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20110701/0f9d6a08/attachment.html>