<br><br><div class="gmail_quote">On Thu, Jun 30, 2011 at 6:22 PM, Pierre Racine <span dir="ltr"><<a href="mailto:Pierre.Racine@sbf.ulaval.ca">Pierre.Racine@sbf.ulaval.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
-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.<br>
<br>
-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. <br>
</blockquote><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">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.<br>
</blockquote><div><br>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.<br>
</div><div><br>This is covered in the Result Grid Iteration Engine: <a href="http://trac.osgeo.org/postgis/wiki/WKTRaster/SeamlessArchitecture#Result-Grid-Iteration-Engine">http://trac.osgeo.org/postgis/wiki/WKTRaster/SeamlessArchitecture#Result-Grid-Iteration-Engine</a><br>
<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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).<br>
</blockquote><div><br>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: <br>
<br>"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. "<br>
<br>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: <br>
<br><a href="http://trac.osgeo.org/postgis/wiki/WKTRaster/SeamlessArchitecture#Expected-Results-and-Information-types">http://trac.osgeo.org/postgis/wiki/WKTRaster/SeamlessArchitecture#Expected-Results-and-Information-types</a><br>
 <br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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.<br></blockquote><div><br>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.<br>
 <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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. <br>
</blockquote><div><br>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.<br>
<br></div>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.<br>

</div>