[gdal-dev] Request for comments on Rasterio documentation
even.rouault at spatialys.com
Mon Sep 12 06:40:01 PDT 2016
> 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."
> 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.
Spatialys - Geospatial professional services
More information about the gdal-dev