[postgis-devel] Raster todo list

[Pierre Racine]

> 	I'm thinking of taking incremental steps rather than jumping in all the
> way for a two raster ST_MapAlgebra, as I suspect that this will take significant
> amount of time to implement correctly.  I can see that ST_Clip, ST_Collect,
> ST_Union will all lead to ST_MapAlgebra but having milestones allows more
> functionality to be delivered and consumed in a shorter time-frame.

The disadvantage of this approach is that you will find yourself rewriting often the same kind of code/algorythms. I know that a two rasters version of MapAlgebra is a big effort but it can also be build by incremental steps. And if we always implement what could be implemented with a good MapAlgebra then we will never have it. Providing good MapAlgebra functions to our users is like providing them with a very flexible development environment. We can implement most of the hydrology functions, most of what ArcGIS Spatial Analyst is providing with that... tons of things really!

> I completely agree, and actually I think the structure of the available functions
> should reflect this. For instance, rather than have many thin wrappers over a
> single huge do-it-all function like MapAlgebra, I'd prefer to build a complex
> function (MapAlgebra) from simpler ones (ST_Intersection).

How would you build a very generic MapAlgebra requiring raster expressions like 'rast1 * rast2 + 120' from something like ST_Intersection?

The one raster version of MapAlgebra we have now use the SQL parser to resolve expressions. It is very generic and handle any PostgreSQL expressions (including logical and conditional ones). We certainly don't want to develop our own limited/buggy expression parser. We would need years of work to achieve what we achieve now with one line of code invoking the PostgreSQL parser.

Pierre