[postgis-users] A PostGIS-Raster data proposal

[Frank Warmerdam]

Marshall, Steve wrote:
> I didn't really understand your comment that there are more fundamental
> problems with combining Kakadu in an optional extension to PostGIS.
> Essentially, you did the same thing with GDAL, so there is a precedence.
> The major difference, as I understand it, is the difference in the
> PostGIS and GDAL licenses (GPL vs. X/MIT).  Is there something else here
> I am missing?

Steve,

It is exactly the GPL vs. Kakadu proprietary license I meant.  It
would be contrary to the license of PostGIS to ship in bundled
with the Kakadu library as binaries or as source. (as I understand it).

GDAL does not have this restriction.  But I do find myself in a
position where I can't legally distribute GDAL binaries that include
both GRASS libraries, and Kakadu for instance, since the GRASS libraries
are GPLed.

I think you can avoid this problem to some degree if you virtualize
things through GDAL.  That way, a user can add the Kakadu driver
if they want.  GPL restrictions are on distributing a mixture of
GPLed code and non-open source code, but they don't restrict end users
from combining them for their own use.

>> I'm not sure I entirely buy into the idea of using jpeg2000 
>> as a special native raster data type.  There are a variety
>> of limitations, and odd performance characteristics with 
>> jpeg2000 which would make me nervous.
> 
> I'm not intimately familiar with JPEG 2000 at the low levels, so I don't
> understand the limitations.  Is it related to uncertainty about how the
> specification should be implemented, vagueness in the format spec, or
> something else?

In my somewhat limited experience the different jpeg2000 libraries
sometimes are surprising slow or use surprisingly large amounts of
memory to decode or encode jpeg2000.  Sometimes it depends on
particulars of the options used in encoding the jpeg2000 and in other
cases I have trouble characterizing the problems.

For limitations, I mean stuff like supporting true floating point
data types is not possible with jpeg2000.

> In any event, I'm intrigued by the idea of using GDAL as the
> implementation package for storing images in the databases.  Using GDAL
> would certainly provide more flexibility, but I think the functionality
> would require that we can do streaming data extraction from any format
> without requiring format-specific code.  Does GDAL provide a
> format-neutral interface to get at a pixel subregion of an image, or to
> extract a low-res (subsampled) version of an image?

Yes.  The RasterIO() method allows selecting a specified region of
a specified set of bands, and loading it into a buffer with a
specified decimation or oversampling.  Various format drivers optimize
the implementation of this in different ways.

>> Actually, when I say "any" format, I really mean any format 
>> in GDAL that supports the virtualization interface where 
>> all IO is routed through VSIFOpenL() and related functions.  
>> This is a lot of the drivers, but by no means all.  This 
>> would also allow use of formats like tiled GeoTIFF with 
>> overviews, from which chunks or overviews can be 
>> efficiently extracted with much better understood 
>> performance characteristics.
> 
> 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.

> Using a more flexible set of image format does give me some concern
> regarding image geonavigation.  One thing that drew me towards using a
> single image format for storage was to have less variation in how
> metadata (like image navigation) would be provided.  Assuming a more
> flexible GDAL implementation, how would such metadata be extracted from
> the image?  Does GDAL provide a generic way to extract image navigation
> information from any format, e.g. the location of the image's bounding
> box in earth-oriented coordinates? 

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.

For multi file formats we would either just not support them in PostGIS,
or have some way of treating several files as a "package" in a blob.  I'd
be inclined to ignore multi-file formats for the time being.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org