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

[Stefan Keller]

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
doesn't.

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 ) -
should'nt they?

-S.


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