[postgis-users] rasters in PostGIS...

[Frank Warmerdam]

Folks,

I'm a bit late to the rasters and postgis discussion.  It seems I setup
a filter on postgis-users during the summer to skip my inbox and I haven't
visited my "all mail" folder since.

On 9/30/05, Matthew Perry <perrygeo at gmail.com> wrote:
> I have no idea what it would take to truly implement rasters in postgis but
> I've been lurking on this whole debate and I have two major questions:
>
>  1. If you're going to run any useful SQL, your "atomic unit" has got to be
> a single "cell", correct? What are the disk space costs of doing this? I can
> imagine storing each cell of 16-bit tiff as a row in my "raster table" would
> take massive amounts of disk space and be painfully slow to access.

The single cell should be addressable somehow in SQL, but the "object"
you put in the database field would presumably be a tile or whole image.

I have skimmed a variety of the other messages in this (lengthy) thread.

I personally hadn't tried to crack the raster-in-rdbms nut with GDAL yet
because I thought it required some thought to do it in a useful way.

Is there someone here who is familiar with the Oracle GeoRaster capabilities
and could summarize them?

Guido Lemoine writes:
> 1. sub-image extracts (e.g. for a polygon, along a line, or plane, for
> 3D data);
> 2. running image processing routines (filters, histogram analysis,
> enhancement);
> 3. data look up (e.g. extract all pixels/regions with a certain [range
> of] values;
> 4. image classification (segmentation), which would be some combination
> of 1-3.
>
> The db should handle *ALL* image metadata, including transformation between
> image space and projections (avoiding reprojection of the images), look
> up tables, tile indexing, etc.

This seems like a reasonable set of desirable functionality.   I would add that
"raster modelling" in the sense of applying various kinds of arithmetic and
logical operators would be desirable.

But we are really talking about implementing a full raster processing and
modelling environment in SQL here.  I think we could define a few levels
of implementation:

 1) Basic raster support in postgres.
     - raster object: supports the various pixel data types in a BLOB format
       that includes metadata on the data type, internal format (just
uncompressed
       raw binary for now),
     - extract subarea (possibly including masked under a postgis polygon)
     - convert data type (16bit->8bit, etc)
     - extract pixel values as a rowset.
     - extract histograms with providing binning parameters.

     This level should not need to depend on external libraries like GDAL, and
     should be a minimum sufficient to use PostgreSQL for raster data
warehousing.

 2) GDAL Enabled
     - Data format translation (to/from any GDAL supported formats
that make sense)
     - image reprojection (possibly using GDAL Warp API)
     - support for storing raster data in particular formats in the
database (ie. GeoTIFF)

 3)  One million operators:
     - arithmetic and logical operators operators
     - various algorithms like classification, etc.

Personally, I feel rather uncomfortable with forging a long ways down this road
without a standard to base implementation on, or at least a good understanding
of how rasters are handled in other RDBMSes.   Funding to support such a
substantial effort is also an issue of course.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent