> 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 _______________________________________________ postgis-users mailing list [email protected] http://postgis.refractions.net/mailman/listinfo/postgis-users
