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

[Jorge Arévalo]

On Fri, Nov 26, 2010 at 12:57 AM, Paragon Corporation <lr at pcorp.us> wrote:
>

>> So in fact, gdal2wktraster.py/raster2pgsql.py does not necessary need an
> installed "GDAL PostGIS Raster driver"?
> Correct - though double-check with Jorge, but yes I don't think it uses the
> PostGIS Raster driver at all
>

Yes, that's right.


>> In the near future, there are plans to also have
>> 1. a raster2pgsql (excutable) for direct import into a PostGIS DB
> Correct
>> 2. a pgsql2raster (executable) for direct export out of a PostGIS DB
> (without Python dependency).
> No -- this has not been planned I don't think and like you say it will
> pretty much be GDAL toolkit if that were the case
>
>>  But in both cases I'm not sure what the advantage and what the difference
> of this is compared to a direct call to GDAL tools (>1.7), since in PostGIS
> 2.x, GDAL will be delivered anyway in the PostGIS package?
>
> The GDAL toolkit will NOT be delivered in PostGIS 2.x package -- well at
> least not to my knowledge.  What I meant to say was that just the
> libgdal.so, libgdal.dll PostGIS will have a dependency on, but
> There is technically no requirement to package the accompanying tools --
> e.g. gdal_translate, gdal_warp etc. though this may change.
>
That's right too.

> That does bring up an interesting question though getting back to why we
> even need a raster2pgsql?
> The main advantage I see of a raster2pgsql is that it can generate a raw sql
> file which GDAL doesn't currently do, though behind the scenes it does do
> the same stuff but just goes direct.  That should actually be a feature of
> GDAL I think.
> This is useful to me at any rate -- because it means I can trouble-shoot
> issues in the import more easily and even remove things.  I can also
> currently package up raster data for PostGIS analysis for people that don't
> have the Python/GDAL available.
>

On one hand, we'd like to be as GDAL-independent as possible. Apart
from this, I think we need to improve the loading process, without
using INSERTs. I guess using the PostgreSQL dump format.


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

Best regards,

-- 
Jorge Arévalo
Internet & Mobilty Division, DEIMOS
jorge.arevalo at deimos-space.com
http://mobility.grupodeimos.com/
http://gis4free.wordpress.com