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

[Pierre Racine]

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

I planned this ST_AsRasterOutputFormat since a while. I thought I had put it in the spec but apparently I didn't. (Now it's done: http://trac.osgeo.org/postgis/wiki/WKTRaster/SpecificationWorking03) I called it ST_AsGDALRaster().

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

I think ST_AsJPEG, ST_AsTiff, ST_AnyFormat should just be wrapper around this more general ST_AsGDALRaster() using the GDAL dll.

Yes this will increase our dependency over GDAL.

I don't think we want to/will reduce/eliminate our dependency over GDAL over time. GDAL is a library made for use by software like ours, why not using it if it serve us well. Up to now it reduced our development time for ST_DumpAsPolygons and ST_Intersection by weeks if not months.

I plan to use GDAL not only for this ST_AsGDALRaster() function but also to implement transparent use of out-of-db raster and for ST_Resample().

Beside this Paul seemed to be happy that PostGIS could now use GDAL for I don't remember which use.

>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

You will have to elaborate a bit more on this for me to understand. (Sometimes I'm very slow...)

Pierre