[postgis-users] Basic postgis raster questions

Pierre Racine Pierre.Racine at sbf.ulaval.ca
Wed Jun 15 12:02:46 PDT 2011


> Pierre,
> 
> Is it safe to assume that what you're looking for is a ST_AsRaster to convert the
> geometry into a raster so that we can do raster on raster filtering?

This is VERY userful but not sufficient.

> I've been wondering as to which method (covert raster to vector or convert
> vector to raster) is more efficient, hence my delay in adding a geometry
> parameter to filter a raster.

I haven't done any test yet but I am pretty sure that geometry to raster is much faster. You could easily test test "gdal_rasterize" VS "gdal_polygonize.py" even though one is in Python and the other one seems to be in C.

> Then again, I've been thinking that there are fundamental functions that should
> be implemented first, including:
> 
> 1. ST_AsRaster(geometry)
> 
> 2. ST_Resample(raster)
> 
> 3. ST_Intersection(raster, raster)
> 
> 4. ST_Clip(raster, geometry)

I think 3) is more or less optional as it could easily be implemented as a wrapper around the two rasters version of MapAlgebra. I agree that ST_AsRaster(geometry) and ST_Resample(raster) are all very fundamental missing pieces.

ST_Clip could be implemented using ST_AsRaster(geometry) and ST_MapAlgebra(raster, raster) because ST_Mapalgebra have a 'working extent' parameter. If you set it to 'INTERSECTION of both raster' and the computing expression is 'rast2' then ST_MapAlgebra(ST_AsRaster(geometry), raster) is ST_Clip(raster, geometry)

So in my head:

1) ST_AsRaster(geometry)

2) ST_Resample(raster)

3) ST_MapAlgebra(raster, raster)

4) ST_Clip

5) St_Intersection(raster, raster)

With that we can certainly implement stats restricted to geometry:

ST_SummaryStat(ST_Intersection(raster, ST_AsRaster(geometry)))

But how fast would it be? But we can implement thousands of other things with those functions... mostly with ST_Mapalgebra(raster, raster).

Pierre



More information about the postgis-users mailing list