[postgis-users] How to import/export PostGIS Raster data? Tools?

[Paragon Corporation]

>> As far as export goes, I think you are right -- we already have that 
>> in the GDAL PostGIS Raster driver, but that gave me a thought that the 
>> planned PostGIS functions ST_AsJPEG, ST_AsTiff etc Maybe should just 
> piggy back on GDAL and be callled
>>
>> ST_AsRasterOutputFormat(rast, 'sometype', 'options')
>>
>> Where sometype would be a type defined in GDAL.  And options would be 
>> a string of options valid for that output format.  In the end  -- the 
>> output of that is just a bytea so PostgreSQL  is not really going to 
>> care either way what comes out of that end.
>>
>> Pierre is unfortunately on a long needed vacation -- so he's not going 
>> to respond anytime soon.  Jorge et. Al, any resason why this is not
feasable?
>>
>> Thanks,
>> Regina

> Yes, could be an option. I'm not sure, but I think the specs for functions
like ST_AsJPEG, ST_AsTiff were made before thinking in link with GDAL. 
> Anyway, the philosophy "being as GDAL-independent as possible" can be
applied here. Understood GDAL-independent as
<any-external-library>-independent as possible.

> Actually, the only dependence with GDAL is in the ST_DumpAsPolygons
function. We could break this dependence using our polygonize function.
Good point.  Yah right now I don't even bother compiling GDAL with
PostgreSQL support or others since it really doesn't need it for our current
use.  Which is why the gdal so/dll is all I ever need to package.
I guess using the Tiff, etc. would require us adding additional dependencies
since GDAL depends on tiff drivers and so forth.

My thinkng though aside from adding more dependencies -- is I really don't
like calling the functions ST_AsJPEG etc.  It limits our future options and
to me just creates function bloat.

In the end they all output bytea and its up to the renderer to figure out
what to do with the binary blob it gets back.  So the only benefit of
breaking these functions out is for deliberateness.

I'd much rather have the deliberateness encoded in an enum.  Now that
PostgreSQL 9.1 will allow altering enums, this will allow for infinite
expansion of possibilities without function bloat and there are a a lot of
raster types out there.

http://developer.postgresql.org/pgdocs/postgres/sql-altertype.html


Thanks,
Regina