[postgis-users] A PostGIS-Raster data proposal

[Markus Schaber]

Hi,

Frank Warmerdam wrote:

>> I did take a look at the VSI subsystem in GDAL.  It looks like
>> integration to this API would require providing file access semantics
>> for the underlying relational database storage mechanism.  For TOAST,
>> there might be a problem with being able to seek to an arbitrary
>> location, and then write data.  
> 
> It would indeed be awkward if arbitrary seek on write is not supported.

AFAICS, this is due to the MVCC system used in PostgreSQL. Writing a
column means writing a new row version. So a single-byte change would
imply an implicit copy of the whole row, there are no "inplace" changes.

Besides, the only way to change table data in SQL is due to an UPDATE
command, and UPDATE deals with replacing a column "value" as a whole.

Large Objects are not part of the MVCC and transaction logic. That
allows them to be modified in place, but we lose transaction safety.

> GDAL does support a generic model for geolocation information and
> supports extracting it from the target file or associated files such as
> world files.  In the context of rasters in postgis, I would expect most
> metadata and geolocation information (at least a bounding polygon) would
> actually be kept distinct from the BLOB containing the raster.

Actually, we still can keep it together in the same column, using the
seek-read API for optimizing queries that e. G. do a bbox prechecking.
The blob would contain a header with some meta data (bbox, srid,
jpeg/png/whatever format ID), and then the actual image data.

That optimization is currently not done for PostGIS vector data, we
always detoast the whole geometry, but i might make sense there as an
optimization, too, for some operations. Especially as the SRID and
cached BBox are served in the first bytes of the geometry.


Markus
-- 
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf.     | Software Development GIS

Fight against software patents in Europe! www.ffii.org
www.nosoftwarepatents.org