[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