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

[Pierre Racine]

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

Could you describe how your Result Grid Iteration Engine is different from MapAlgebra(rast1, rast2)?

I understand it as a mask generation engine but MapAlgebra(rast1, rast2) and MapAlgebra(rast) are also mask generation engines... since a mask is a raster and a raster can easily be viewed as a mask... (nodata = 0 and withdata = 1)

> 	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?) 

I said "naturally binary raster operations" meaning they naturally take rasters as inputs but if we want to have them seamless they must also accept geometries as parameters. I know this is somewhat silly but one might want to do that:

ST_MapAlgebra(geometry1, value1, geometry2, value2) -> raster

I think your document need to define properly concepts like: 

-information types
-data types
-mask

And you also need to list the advantages of developing a modular approach using mask have over the planned approach ST_Mapalgebra(rast), ST_MapAlgebra(rast1, rast2). Up to now I don't see any. Sorry. What can we do with this architecture that we cannot do with a good set of Mapalgebra and set operators like ST_Intersection()?

> "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. "

Could they accept geomval?

> 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 you need to come up with some example function prototypes (or just signatures) so we better understand your proposition. You introduce many concepts and we don't see the functional end of them. 

> 	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). 

ST_AsRaster(geometry, value) is planned to accept a value to be burned in the raster. This value can be different than 1. Rasterized geometries might be masks but they can also convey values. Only one. You can then use them in ST_MapAlgebra(rast1, rast2).

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.

In you view is a mask a special object or merely a 1BB raster?

> 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 

Which one?

>is capable of being both via extension points. 

What are extension points?

This discussion seams endless since we have two (I think) very different approach to the problem of developing seamless operators. I think I will wait for you to come with a final API proposition to comment further. My principal points are:

-What does the introduction of the mask concept add to the whole thing since you can easily produce mask using the existing proposition.
-What does the modular approach add to the whole thing?

Please provide functions signatures and queries examples...

Pierre