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

Paragon Corporation lr at pcorp.us
Thu Nov 25 15:57:29 PST 2010


> A. For importing raster data to PostGIS there's gdal2wktraster.py (now
renamed to raster2pgsql.py). raster2pgsql takes any GDAL supported raster
format as input and writes an SQL text file in PostGIS Raster WKT syntax -
similar how shp2pgsql functions for vector formats.
> Inside raster2pgsql, GDAL functions are called to read/import "any"
> raster format, and the Python code writes PostGIS Raster WKT(!) SQL.

> 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

>  In later versions of GDAL (> 1.7) there is a direct PostGIS Raster
writer/export for GDAL where a Postgres DB (WKB!) is the target "format".
PostGIS raster export (no writer yet)


>  B. For exporting PostGIS raster data to any other raster format, one can
already use gdal_translate, gdal_warp etc. commandline tools (which requires
an installed "GDAL PostGIS Raster driver" i.e. a reader). 
> And since many other API tools/projects built on top of GDAL, these are
already capable of using PostGIS raster data (WKB stream) as input source -
given their GDAL library is compiled with PostGIS Raster support.
Correct.  Though I think only MapServer has this exposed at the moment.  I
could be wrong about others.  Say I'd be curious to try this in rgdal but
haven't yet.  In theory it should work in rgdal if you have rgdal compiled
with PostGIS raster support
And that could provide even more power for R.

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

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





More information about the postgis-users mailing list