>>> 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?
I planned this ST_AsRasterOutputFormat since a while. I thought I had put it in the spec but apparently I didn't. (Now it's done: http://trac.osgeo.org/postgis/wiki/WKTRaster/SpecificationWorking03) I called it ST_AsGDALRaster(). >> Actually, the only dependence with GDAL is in the ST_DumpAsPolygons >function. We could break this dependence using our polygonize function. >Good point. Yah right now I don't even bother compiling GDAL with >PostgreSQL support or others since it really doesn't need it for our current >use. Which is why the gdal so/dll is all I ever need to package. >I guess using the Tiff, etc. would require us adding additional dependencies >since GDAL depends on tiff drivers and so forth. > >My thinkng though aside from adding more dependencies -- is I really don't >like calling the functions ST_AsJPEG etc. It limits our future options and >to me just creates function bloat. I think ST_AsJPEG, ST_AsTiff, ST_AnyFormat should just be wrapper around this more general ST_AsGDALRaster() using the GDAL dll. Yes this will increase our dependency over GDAL. I don't think we want to/will reduce/eliminate our dependency over GDAL over time. GDAL is a library made for use by software like ours, why not using it if it serve us well. Up to now it reduced our development time for ST_DumpAsPolygons and ST_Intersection by weeks if not months. I plan to use GDAL not only for this ST_AsGDALRaster() function but also to implement transparent use of out-of-db raster and for ST_Resample(). Beside this Paul seemed to be happy that PostGIS could now use GDAL for I don't remember which use. >I'd much rather have the deliberateness encoded in an enum. Now that >PostgreSQL 9.1 will allow altering enums, this will allow for infinite >expansion of possibilities without function bloat and there are a a lot of >raster types out there. > >http://developer.postgresql.org/pgdocs/postgres/sql-altertype.html You will have to elaborate a bit more on this for me to understand. (Sometimes I'm very slow...) Pierre _______________________________________________ postgis-users mailing list [email protected] http://postgis.refractions.net/mailman/listinfo/postgis-users
