>> 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. 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. In the end they all output bytea and its up to the renderer to figure out what to do with the binary blob it gets back. So the only benefit of breaking these functions out is for deliberateness. 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 Thanks, Regina _______________________________________________ postgis-users mailing list [email protected] http://postgis.refractions.net/mailman/listinfo/postgis-users
