[postgis-users] Re: Re: Proposed SQL interface for PGRaster

[Marshall, Steve]

Patrick,

Sorry to be slow in replying.  I got distracted by other issues
yesterday.  I also needed some time to review what you had written.

I think in looking at your design that we have quite divergent views
about what a PGRaster should be.  You are proposing a multi-table
approach where PGRaster is not a type, but a table, and where the
relationship between rasters, bands, and tiles are modelled as table
relationships.

This approach certainly has some precedence.  It's very similar to the
approach used by Oracle for its SDO_RASTER implementation.  It is also
generic about its SQL usage (no details specific to PostgreSQL), so the
design to apply to nearly any RDBMS.  

However, this purely-relational design goes against my primary goal for
PGRaster: to allow one to relate raster objects and geometry objects,
including converting data from one representation to the other.  In this
design PGRaster is no longer a type, so it is hard to write functions to
operate on PGRasters.  

What I see in your design is a way to use an RDBMS to provide an
application with access to pieces of rasters.  It is up to the RDB
client application to operate on these raster primitives (tiles, bands,
etc).  My vision is to put more of the raster processing logic on the
server-side, i.e. executing in the process space of the postgres
backend.

I think once you jettison the ability to do significant work on the
database server, you end up with a design that provides a very similar
interface to the traditional raster interface, i.e. directly accessing
raster data by seeking within a local data file.  In both cases, the
client is intimately tied to low level details of the data storage, and
must provide the logic to operate on these low-level raster primitives.

While this similarity to file-based access might seem like a strength, I
think it is actually a critical weakness.  The reason is that file
access is going to be much faster than RDB access.  Despite what Oracle
or other RDB vendors may claim, I've found nothing that indicates that
RDB tricks like indexing, etc. will produce better performance than
access to well-formated files.  Thus, the pure relational design just
becomes a slower way to the same functionality as file-based access. 

I think the thing that makes PGRaster worth doing is not performance,
but encapsulation of raster processing capabilities.  By allow vector
and raster objects to be related to one another and combined in
interesting ways, you get some pretty powerful functionality.  By
putting this logic in the database server, you simplify the code that
needs to reside in a database client application, and allow that
capability to be shared by many client applications.

To pursue that goal, I'm going to continue down the road of trying to
implement PGRaster so that GEOMETRY-raster operations can be performed
on the database server.  I think this will liberate client applications
from the need to provide a significant amount of functionality, and that
this benefit will outweigh the inevitable performance cost of a
relational implementation.  I hope that there will be some other
believers in this vision who will want to join me.

However, if you are not one of them, I certainly understand.  If so, I
wish you the best of luck on alternate implementations for raster-in-DB,
and would be pleased (and ready to eat my words) if you prove that such
implementations are superior to what I've proposed.

Yours,
Steve Marshall

-----Original Message-----
From: postgis-users-bounces at postgis.refractions.net
[mailto:postgis-users-bounces at postgis.refractions.net] On Behalf Of
Patrick
Sent: Thursday, December 07, 2006 7:26 AM
To: postgis-users at postgis.refractions.net
Subject: [postgis-users] Re: Re: Proposed SQL interface for PGRaster

"Patrick" <pvanlaake at users.sourceforge.net> wrote in message
news:el6efg$lc$1 at sea.gmane.org...
>
> I would like to suggest that the community puts together some real 
> designs, develop some use-cases, and then work out how the design 
> affects the implementation of some basic operations.
>
Hi all,

Here is my proposal for a raster - raster band - data tile hierarchy.
Note that this is only meant to demonstrate the principle and by no
means complete, let alone definitive. Please shoot.


-- The RASTER object
CREATE TABLE PGRaster(
  rid serial PRIMARY KEY,
  name varchar(64) UNIQUE,
  srid int4 DEFAULT -1,
  num_rows int4 NOT NULL CHECK (num_rows > 0),
  num_cols int4 NOT NULL CHECK (num_cols > 0),
  pixel_x_dim float8 NOT NULL CHECK (pixel_x_dim > 0),
  pixel_y_dim float8 NOT NULL CHECK (pixel_y_dim > 0),
  ulx float8 NOT NULL,
  uly float8 NOT NULL

  :
  : -- other properties
  :
) WITH OIDS;

-- The RASTER BAND object
CREATE TABLE PGRasterBand(
  bid serial PRIMARY KEY,
  rid int4 REFERENCES PGRaster(rid) ON DELETE CASCADE,
  band_order int4 DEFAULT 0,
  name varchar(64),
  data_type int4 NOT NULL,
  :
  : -- other properties
  :
  tile_dim_x int4 NOT NULL CHECK (tile_dim_x > 0),  -- # pixels/tile
  tile_dim_y int4 NOT NULL CHECK (tile_dim_y > 0)
) WITH OIDS;

-- The DATA TILE object
CREATE TABLE PGRasterDataTile(
  bid int4 REFERENCES PGRasterband(bid) ON DELETE CASCADE,
  tile_index_x int4 NOT NULL CHECK (tile_index_x >= 0),
  tile_index_y int4 NOT NULL CHECK (tile_index_y >= 0),
  data bytea, -- or whatever we choose

  :
  : -- other properties
  :
  PRIMARY KEY (bid, tile_index_x, tile_index_y)
) WITH OIDS;

Cheers,
Patrick 



_______________________________________________
postgis-users mailing list
postgis-users at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users