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

[Pierre Racine]

Bryce,

You can get write access to the wiki by creating a userid in this page:

http://www.osgeo.org/osgeo_userid

I'll need more time to look at your patch and comment it.

About my view of what should be seamless raster/vector operations:

-My basic idea has always been that you do the operation in vector or raster mode. We will not reinvent something very new here (unless you want to define very new seamless operators but to me the two most fundamental ones are the overlay vector world operation (intersection, union, difference, etc... and raster world map algebra. With that you can almost do everything possible in terms of GIS analysis)). 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. Doing the reverse operation (rasterizing vectors) is not so much memory intensive if the requested pixelsize is reasonably small.

-We also have the constraints that people are used to get some kind of results from an intersection operation or a map algebra one.

-Another constraint is misaligned rasters. My answer (and I think this is the general answer to this problem) is: always resample one raster to the other before proceeding.

-From that I always had some rules in my mind. Maybe I should have wrote them somewhere:

1) Most unary operations available on vector should also be available on raster when it make sense (ST_Transform, ST_convexHull, ST_Scale, etc...).

2) Most unary operations available on raster should be available on vector when it make sense (ST_MapAlgebra(rast), ST_Flip, ST_Clip, ST_AsJPEG, etc...). In this case vector should be rasterized.

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.

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

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 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. If really users need to build a mask first they can do it using the one raster version of ST_MapAlgebra and pass it to the two rasters MapAlgebra:

SELECT ST_MapAlgebra(rast1, ST_MapAlgebra(rast2, 'CASE WHEN rast < 0 then 0 ELSE 1 END'), 'otherExpression') 

The second ST_MapAlgebra here built a mask that can be used in any way. In brief I think that both versions of ST_MapAlgebra() can be used to build mask and the two raster version can always accept a mask and an expression dealing with this mask. So if, only is users need for some operations, a mask, they can create them without us imposing this concept to people who do not need it.

I will read your next email...

Pierre

> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net [mailto:postgis-devel-
> bounces at postgis.refractions.net] On Behalf Of Bryce L Nordgren
> Sent: Thursday, June 30, 2011 12:43 PM
> To: PostGIS Development Discussion
> Subject: [postgis-devel] [raster] Architecture wiki document contribution
> 
> I like the goal of seamless raster/vector operations. However, I get the sense
> that no one has a real good feel for what that means yet. One and two raster
> operations seem to be covered. Purely vector operations seem to be covered.
> Mixing up rasters and vectors is not something I've seen a plan for, aside from
> some examples for specific cases in the original presentation. It's my firm belief
> that in order to accomplish this goal, it's necessary to figure out what that
> means sooner rather than later. Figuring out what this means (comprehensively,
> in general; and not for specific cases) is what the architecture document is all
> about.
> 
> To be clear, the architecture document has nothing to do with how rasters are
> stored or accessed (one row, many rows, out-database, in Oracle Spatial, on a
> WCS, etc.) so our passionate dialog concerning what and how to "tile" rasters is
> not related to this concept at all. It discusses, in the most general way, the basic
> differences and similarities between geometry, geometry-value, and gridded
> data types; articulating the difference between "information types" and "data
> types". It also observes that there is a lot of commonality in all operations which
> return the raster data type, and articulates a utility similar to
> rt_raster_raster_op_engine() on ticket 1058.  I haven't figured out if
> geometry/geometry-value returning functions have enough in common to
> identify a similar utility for them. These are key, fundamental concepts for
> evenhandedly treating different representations of the same underlying
> information.
> 
> I mean for this document to be a starting point, but it's hard for the document to
> evolve when y'all can't edit it. It really belongs on the PostGIS wiki, but I don't
> have write access. So if one of you fine folks could copy it off of my wiki onto
> yours, I'd be grateful. Or tell me it's not something you want there. Either way,
> I'm going on a two week vacation starting Saturday, and I'd like to try and make
> it possible for it to evolve while I'm gone.
> 
> https://collab.firelab.org/software/projects/modisfire/wiki/Seamless_spatial_o
> perations_architecture
> 
> Bryce