[postgis-users] PostGIS WKT Raster

[Pierre Racine]

Hi raster people,

I'm starting a 2-3 year project to develop a web-based application to
automate certain GIS tasks commonly needed in ecological research. The
tool will support queries over VERY large extent based on a Canada-wide
assemblages of raster and vector data layers. The queries will typically
involve intersecting those layers with buffers defined around points or
transects.

We would like to implement this system with PostGIS, but it currently
does not to support raster data. We could convert all our data to a
single format (raster or vector) and use other tools, however PostGIS
seems to us the best and most powerful vector analysis tool available
and we would prefer to use it. We would like to develop a unified
toolkit so that the application mostly need not worry about whether base
layers are in vector or raster format. We are then strong proponents of
having raster functionality in PostGIS. I have reviewed every thread on
this list on the subject. I have analysed them and I have compiled them
in the wiki
(http://postgis.refractions.net/support/wiki/index.php?RasterNotes). 

The argument goes like this: The geodatabase paradigm has been a major
recent enhancement in GIS technology, I feel that the seamless
integration of raster and vector analysis should be one of the next.
Spatial analysis is emerging, beside the making and publishing of maps,
as one of the main desktop and web-GIS applications. Rastor/vector
seamless integration is already done for display (in most GIS and with
MapServer or ArcIMS on the web) but definitely not for analysis. Desktop
analysts must still learn to use two distinct toolsets within most
(all?) GIS packages: one toolset for raster and another for vector data.
Would not it be easier to build and use applications if we had a unique
data query and analysis toolset independent of the data model? I don't
know any tool having this approach right now. A PostGIS foundation that
addressed this problem would offer better directions to application
developers than the dichotomic one proposed by ESRI since their
beginning. It would provide the necessary abstraction to develop GIS
with ONE set of analysis tools. I feel this is one good reason to
integrate raster in PostGIS. There is "GIS" in the word "PostGIS".
PostGIS should then provide a COMPLETE GIS data foundation (read
"base"!) for geoapplication developers. I think Steve Marshall's design
is a good step in this direction
(http://postgis.refractions.net/pipermail/postgis-users/2006-December/01
4059.html). 

At the same time, we would have a chance to reconsider the raster model
as a coverage instead of a series of images. Spatial databases got rid
of map sheets by allowing complete vector coverages to be stored as
single table (e.g. the entire United States) This approach should works
for raster data as well. Isn't this the approach taken by ArcSDE?

In summary, I think we must stop thinking about PostGIS as a mere vector
data repository to support mapping applications. This is the way most
objectors to raster integration seem to view it. We must think about
PostGIS as a powerfull indexed data analysis tool. Seamless
raster/vector analysis in the database could lead to a major
simplification of geoapplications.

I prepared a PowerPoint presentation with a complete specification of
raster in PostGIS and an analysis of what should be the result of
overlay operation between raster and vector layers. You can download
this PPT at: http://www.cef-cfr.ca/uploads/Membres/WKTRasterPostGIS.ppt
Please have a look at it, feel free to answer questions I ask and
comment.

Here are the main propositions of this design:

-Like a vector feature, rasters are stored as a subtype of "geometry"(a
new WKB/WKT geometry type called RASTER instead of POINT or POLYGON)
-There is no distinction between a raster and a tile. A tile is a raster
and a table of rasters can be seen as a tile coverage. Hence, contrary
to Oracle GeoRaster, only one table is needed to store a coverage and
there is only one type.
-It support raster in the database AND raster out of the database. This
mailing list has shown that both approaches have their pros and cons.
Let's not impose one approach over the other.
-It supports: multi-band, pyramids and variable nodata value, raster
size, pixel size and pixel type for each row.
-It supports import/export from/to Tiff and JPEG.

But moreover seamless raster/vector integration is materialized by
theses propositions:

-A lot of existing vector-only functions are adapted to work with raster
also.
-Most new raster functions are also implemented to work with vector.
Only basic raster derivation functions are proposed.
-Most vector/vector existing functions are adapted to work seamlessly
with raster/vector or raster/raster

I also want to ask:

-What is the status of PGRaster? Is any development now underway?

We have some resources to devote to this project over the next few years
and are very interested in forming collaborations to move this work
forward.

Pierre Racine
GIS/Programmer Analyst
University Laval
http://www.cef-cfr.ca/index.php?n=Membres.PierreRacine