[postgis-users] Re: Rasters
pvanlaake at users.sourceforge.net
Thu Sep 29 13:39:22 PDT 2005
"Paul Ramsey" <pramsey at refractions.net> wrote in message
news:D5628771-98D0-467F-B201-E53AAA356383 at refractions.net...
> OK, raster people. My problem is that I cannot envision the use cases
> for raster in the database, so, make it easy for me! :)
Let me try to enlighten you.
> - What is the atomic unit of storage for rasters in the database? Is it
> complete scenes? Something else?
The answer to this question is not an easy one. On an object-level the
raster itself is the atomic unit. In other words, there should be something
like a pg_rasters table, which lists stored rasters and which allows to
select on global attributes like SRID, envelope, content, purpose, age, etc.
Below that level the raster is composed of bands that each are 2-dimensional
arrays of some data type (IIRC they can be n-dimensional according to ISO
and OGC, but the difference is essentially trivial). Bands define content
more than anything else and they have no particular bearing on design or
implementation. (Unless of course rasters are implemented having multiple
band values represented as a composite type (not unlike
Band data will be stored in tiles which will very likely be the size of the
db page. Applications wanting to read or write entire raster bands will do
so in tile size chunks. Having a TILE(x, y) keyword in would be nice
SELECT TILE(0, 5) FROM myraster;
Below the tile is the pixel. For all practical purposes, pixels would never
be manipulated inside the db, except in raster-level operations such as
coordinate system conversion and resampling.
> - What is some SQL I would apply against my raster tables? Make up some
> descriptive function names and show me some example SQL and tell me what
> it does.
See above. Think INSERT, UPDATE and DELETE. Basically, all of these apply to
tiles of data. What is done to those tiles depends on the application.
> - How do vector data and raster data interact? Note the atomicity
> question above.
That is mostly up to the application. What would have to supported by the db
is the standard set of geometrical operators: return those pixels that
overlap with some geometry object, etc.
In general, I think that it would be best to start humble: manage raster
data in tiles. PostGIS needs to store tiles and serve them up upon request.
This, coupled with the standard DBMS functions of access control,
concurrency control, and backup support, would already be a tremendous
feature. Later more sophisticated options could be added, such as returning
data from arbitrarily sized areas and resampling.
More information about the postgis-users