[postgis-devel] Raster todo list

[dustymugs]

>> ST_Resample:
>>
>> this would be adding the ability to change the scale (pixel size) and the origin
>> (upper-left corner) of a raster using the GDAL library.  How about de-skewing a
>> raster?
>
> I already wrote specifications for that function. I did not put them in the wiki yet though. I can do it ASAP.
>

OK.  I'll be spending the next few days getting familiar with how the 
gdalwarp utility works.  From what I've looked at in GDAL thus far and 
comparing that to ERDAS, it is a standard linear transformation where 
the user provides a transformation matrix.  So, it looks like GDAL can 
change the skew.

>> ST_AsRaster:
>>
>> convert a geometry to a raster using the GDAL library
>
> I also have spec for that. Still have to put them in the wiki.
>

Again, I'll need to see how GDAL handles this and what capabilities it 
exposes.  I'm sure its better and more tested than anything we could 
write from scratch.

>> ST_Accum:
>>
>> be able to bring together a set of tiles to make one unified raster.  I really need
>> to be able to do the following:
>>
>> SELECT
>> 	observation_date,
>> 	ST_Accum(rast)
>> FROM tmax_2011
>> GROUP BY observation_date
>>
>> This function will entail a bunch of issues, such as irregular scales, unclean
>> overlap of tiles, skew and projection.
>>
>> ST_Clip:
>>
>> be able to clip/crop a raster using a geometry or raster as a mask
>>
>> I haven't had much time yet to think of the specifics for each function but I'll get
>> to each when I get there.
>
> Isn't it more something like ST_Union that you need? ST_Accum create an array of geometry. ST_Union merge them together.
>

Yes, I misunderstood the meaning of ST_Accum.  ST_Collect is what I'm 
looking for.  It should be faster than ST_Union and ST_MapAlgebra as it 
does not provide a mechanism for the end-user to provide rules for 
handling the intersection of rasters.  Instead, subsequent rasters being 
added to the "collected" raster will replace the existing value with its 
value.  So, the order in which the rasters get passed to ST_Collect 
determines the value of a pixel in the "collected" raster.

> I think those two last functions should wrappers around an optimized version of two raster MapAlgebra. The non optimized version of Mapalgebra compute one pixel at a time.
>
> There should be an option in the two rasters version of mapalgebra (optimized or not) to say what we want the resulting raster area to be: same as the FIRST raster, same as the SECOND, same as the INTERSECTION of both or same as the UNION of both.
>
> INTERSECTION is very useful to implement ST_Clip  and UNION is very useful to implement ST_Union (or the merge of two rasters).
>
> When you use UNION, very often there are areas that do not overlap. For those areas you want to be able to provide an alternative expression for the missing data. This is also the case when they overlap but one of the raster pixel is nodata.
>
> Also when you use UNION, and where the two rasters expression do not apply. You can optimize the setting of these sub-areas quickly as block (like a memset), not pixel by pixel. You may want to set the whole sub-area to nodata, to a constant or to a copy of one of the two raster (this is the optimum case exploited by ST_Union).
>
> When you use intersection and the expression resume to 'rast1' you have a clip. You also, in this case, want to just copy the pixel values from the first raster to the second. This can be optimized by a ST_SetValues function just copying pixel values from one to the other.
>
> So in the end you have a very flexible Mapalgebra working on two rasters helping you to implement a bunch of other raster processes and optimized for the very useful case of doing Clips and Unions. In bonus you get some editing functions like ST_SetValues very usefull to implement who knows what...
>
> That how I see all this.
>

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.

> Please have a look at script/plpgsql/st_mapalgebra.sql and script/plpgsql/st_mapalgebra_optimized.sql
>

I'll take a look...

-bborie