[postgis-devel] [WKT Raster] Regular blocking in gdal2wktraster.py

Pierre Racine Pierre.Racine at sbf.ulaval.ca
Fri Mar 27 12:27:37 PDT 2009


>I think it is critical that one "coverage" aka collection of raster
>tiles cannot have overlaps. A coverage can only have one value per band
>per point in space. Otherwise there is no way to do analysis on the
>raster - which value do you use? I think the fact that there is overlaps
>is a clue that they should be defined as separate coverages.

I entirely agree on this, but as with a vector coverage we let to the user to make sure that the data he is loading in the DB is topological (not overlapping). A vector layer with overlapping features is also a problem when doing analysis, but there is no mechanism in PostGIS to ensure that the shapefile you load is topological. We do the same for WKT raster.

And we also supports overlapping tiles because we don't want to loose overlapping information when the vecter feature we rasterize overlap with another vector feature. Anyway there will be tons of overlapping nodatavalue pixels in a rasterized one-feature-per-row version of a vector feature table.

>The use case for overlapping rasters that comes to my mind is the case
>of dynamic mosaicking based on resolution or other parameters. In this
>case you have an 1-meter orthophoto which overlaps with a 10-meter
>satellite image. Which image gets used for the overlapping region is
>based on the resolution of the request, but for the non-overlapping
>parts it is simple. I think this use case would be two separate
>coverages, stored within the same table, and ideally using the same
>blocking (aligned).

Again we agree that significant values in a coverage should not overlap. But they could, when rasterized from a vector feature.

If people wants strick regular-blocking images in the db, they should use something else than WKT Raster. We have already demonstrated that this does not really benefits from the db possibilities. 

If they want a framework to manipulate raster coverage the same way they do with vector coverage then they should use WKT Raster.

>I envision functions to merge multiple overlapping rasters such as this,
>based on some parameters, into a separate, new coverage - ie. building
>the mosaic. One day! :)

This day is near... There will be an aggregate function Accum(rast set, mode) in WKT Raster that will merge tiles together, overlapping or not with the optional mode (first, last, blend, etc...). There will also be a RT_MapAlgebra(raster, [raster...], ‘mathematical expression’) -> raster function.

Pierre


More information about the postgis-devel mailing list