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

Patrick pvanlaake at users.sourceforge.net
Wed Dec 6 11:58:18 PST 2006


"Robert Burgholzer" <rburghol at chesapeakebay.net> wrote in message 
news:C9D51E2209AFD04F93E4E2E4CD6E4979027F8B76 at mail1.chesapeakebay.net...

> Where I disagree, however, is that I think that an RDBMS essentially
> does what you refer to here, that is, it disaggregates data, and to make
> effective use of the RDBMS you split your data into the smallest pieces
> possible. You then use queries to grab only the pieces that you need (in
> this case, spatial overlaps, spatial indices).  I think that large
> rasters are problematic, and inefficient in that they force a sort of
> sequential access to the large chunk of data, when really one is
> desiring only a small portion of it.  To optimize performance here, we
> will want the querying of rasters (which on the back end are split into
> little chunks) to make use of the spatial features of postGIS, such as
> indexing.
>
> Perhaps a hybrid approach, similar to the geometry columns table would
> be used, where a raster can be stored in a single row, but it stores its
> tiles in a separate table, one row for each tile. This would make use of
> the existing PostGIS efficiencies, and also create a transparent front
> end to a traditional raster format??

Hi Robert,

What you are saying is exactly what I propose: A raster is an orderly 
collection of data in two dimensions. How it is stored in the DBMS should 
not matter to the client-side. The client requests a chunk and the server 
serves it up.

I am just assuming (predicting?) that the fastest performance will be had if 
clients access the tiles of data as they are stored on the server and then 
assembles the tiles as needed on a display or use it in processing. This 
cuts at least one conversion (internal DBMS => I/O => internal client 
becomes internal DBMS tile transferred as such => internal client) and other 
advantages at the client side may be had as well (such as potentially better 
memory management, less disk flushing).

Cheers,
Patrick 






More information about the postgis-users mailing list