[gdal-dev] Request for comments on Rasterio documentation

[Even Rouault]

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