[postgis-users] How to import/export PostGIS Raster data? Tools?
sfkeller at gmail.com
Thu Nov 25 17:17:13 PST 2010
Ok, sorry for repeating... Here's another thought as discussion shifts
to what's about having raster2pgsql - and possibly pgsql2raster
(although not planned):
Both commands (as executables) - as well as shp2pgsql/pgsql2shp - make
PostGIS as independent as possible from GDAL/OGR (except some of it's
libraries). And raster2pgsql can generate a raw sql file which GDAL
Now, having put into question the existence of raster2pgsql myself
given GDAL could do the job, it comes to my mind that all such
commands - like raster2pgsql, shp2pgsql, pgsql2shp, etc. - could
adhere to the conventions of Postgres environment variables, which
GDAL/OGR would'nt do (see
http://www.postgresql.org/docs/8.0/interactive/libpq-envars.html ) -
2010/11/26 Jorge Arévalo <jorge.arevalo at deimos-space.com>:
> 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
>>> 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?
> 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
> Best regards,
> Jorge Arévalo
> Internet & Mobilty Division, DEIMOS
> jorge.arevalo at deimos-space.com
> postgis-users mailing list
> postgis-users at postgis.refractions.net
More information about the postgis-users