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

[Robert Burgholzer]

> To me it doesn't make sense to have a 
> large amount of data, cut it into pieces to fit the hardware/software 
> environment and then aggregate it back when it is needed. The end-user

> having 60,000 rasters of 6 thematic information sources will perceive
this 
> as a jumble. Instead, the end-user would like to see 6 rasters, one
for 
> each thematic source, and not care (and know!) that each raster is
made up > of 10,000 tiles.

I agree with some of this sentiment, but disagree in other places. I am
truly on the fence here, so please excuse me if I am contradicting
myself, and generally musing.

I agree in that our traditional conception of what a raster data source
is, differs greatly from this tiled, granularized form. However, I think
that this is deciding what a raster will be, not what it has been. I can
also agree that if the back end file type is robust, and makes its
splitting/merging transparent to the user, it would be most like what
they are familiar with, and quite functional.

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??

r.b.


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