Sean, > Yes, I suppose it could be okay to call gdal functions within a > rasterio.Env() block as long as you didn't change the error handler or > config options. I can't help thinking that "you can use a subset of gdal > with Rasterio" advice sets users up for trouble and I'd like to avoid that.
Yes I can understand that. My point is that one currently gets the feeling that things will immediately breaks if you mix rasterio with osgeo.gdal, whereas they might potentially subtely break (anyway folks ready to use osgeo.gdal shouldn't be too afraid of that :-) ) > > Thank you for correcting me. It's gdal.UseExceptions() that > calls CPLSetErrorHandler(), yes? Yes, gdal.UseExceptions() installs a new global handler with CPLSetErrorHandler(), and gdal.DontUseExceptions() restore the previous handler (saved during the call of gdal.UseExceptions()) > And so I should say "may depend on whether > rasterio.Env() or gdal.UseExceptions() was called last." Correct. > > Yes, I think Rasterio's CRS class should probably switch to WKT for its > canonical representation sooner than later. <joke>Which version of WKT: OGC 01-009 or OGC 12-063r5 ?</joke> > > Even, has the idea of an API for getting the current configuration of GDAL, > meaning all the currently set options, ever been proposed and discussed? It > seems like this could help modules coexist better. Do you mean get the list of key=value that would have been pushed with CPLSetConfigOption() ? I'm not sure if this has been discussed, but it should just be a matter of returning the global papszConfigOptions string list (or a copy of it to avoid threading issues) of port/cpl_conv.cpp. There might be some subtelty to take into account as you can also define thread-local configuration options with CPLSetThreadLocalConfigOption(), so such a function would perhaps have to incorporate those thread local ones into the global list (or perhaps have a specific function for getting only the thread local ones). However when GDAL calls CPLGetConfigOption(), it doesn't just use the values set by CPLSetConfigOption() / CPLSetThreadLocalConfigOption() but also the operating system environment variable, so it isn't obvious if they should also be returned by such a function. Even -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
