[postgis-users] Basic postgis raster questions

[Pierre Racine]

>> It is true that PostGIS raster do not allow yet to reassemble raster
>> tiles into bigger rasters but you don't have to do that in order to 
>> compute histogram on a tiled coverage. Just compute the histogram 
>> for every tiles and aggregate the results using a GROUP BY query. 
>> (Bborie: shouldn't we have a ST_Histogram variant working on a whole
>> table like we have for the other stat functions?)
>
>I may be mistaken, but I did not see a way to ensure that all bins are constant 
>for the individual runs of ST_Histogram on each tile. You can set the number of 
>bins and the width of the bins, but each tile will have its own unique min/max values, 
>which will move the bins around. Without constant bins, there's no way the results can be aggregated. 

Right.

>I may be missing the boat here, but it seems to me that a version of ST_Intersection() 
>which returns a raster would eliminate the need for a separate geometry parameter, and 
>would be more in line with the spirit of "seamless vector/raster" processing. It also 
>would seem that your separate geometry parameter would behave very much like a 
>raster-returning ST_Intersection(), except that it is only usable "vicariously" via the 
>stats functions. 

Right. It would even be of greater value for other functionalities even if, I think, it would be slower for the particular case of computing stats .

>The two things standing in my way appear to be "Objective FV.02" and "Objective FV.03" on 
>this page: http://trac.osgeo.org/postgis/wiki/WKTRaster/PlanningAndFunding   I'm curious if 
>the page is accurate. Are these activities still unfunded and unallocated, and are 
>4 weeks/4800USD (FV.02) and 2 weeks/2400USD (FV.03) still considered a reasonable estimate of 
>the effort required to implement these items? Don't get excited, but if I'm even thinking of 
>running around with my hand out for money, I need ballpark figures.

Those two objectives are still unfunded and unallocated. 

I think the approximation for FV.02 is probably a bit high since ST_AsRaster is planned as a wrapper around GDALRasterizeLayers() and we already have some functions linking with GDAL that you can mimic but I prefer to be conservative. There is already a crude pl/pgSQL version of ST_AsRaster in script/plpgsql/st_asraster.sql

The time required to implement FV.03 (ST_Union()) depend on how you want to do it. You can base everything on a basic ST_Merge function which burn only the last, the first or the mean raster value when there is overlap or you can, as I was planning, use a two rasters version of ST_MapAlgebra (not yet implemented) to express the merging rule with a state and a final SQL expression. There is a plpgsql prototype of such a ST_Union function in script/plpgsql/st_union.sql. You basically pass a state and a final SQL expression to the ST_Union aggregate and ST_MapAlgebra take the expression computation in charge.

A two rasters version of ST_MapAlgebra is hard to implement but most of the hard work is already done. There is two plpgsql prototypes of the two rasters version of ST_MapAlgebra. One in script/plpgsql/st_mapalgebra.sql and an optimized/unfinished one in st_mapalgebra_optimized.sql. Having a two rasters version of ST_MapAlgebra would be of great benefit to the project as it open millions of other possibilities. We almost had a Google summer of code for it but didn't. 

I would estimate the time to implement the first scenario (ST_Union with ST_Merge) to two to three weeks and the second scenario (ST_Union with ST_MapAlgebra) to two months.

Please have a look at those plpgsql prototypes.

Pierre