<div dir="ltr">Hi Even,<div><br></div><div>Thanks for the comments! More from me below...</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 9, 2016 at 11:40 AM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Sean,<br>
<br>
I've actually a question along Howard's yesterday tweet regarding mutual<br>
incompatiblity between osgeo.gdal and rasterio. From my understanding of the<br>
doc and look at rasterio code (<br>
<a href="https://github.com/mapbox/rasterio/blob/master/rasterio/_drivers.pyx" rel="noreferrer" target="_blank">https://github.com/mapbox/<wbr>rasterio/blob/master/rasterio/<wbr>_drivers.pyx</a> and<br>
<a href="https://github.com/mapbox/rasterio/blob/master/rasterio/env.py" rel="noreferrer" target="_blank">https://github.com/mapbox/<wbr>rasterio/blob/master/rasterio/<wbr>env.py</a>) , it seems the<br>
potential issues would be about driver registration, config options and error<br>
handlers, right ?<br>
<br>
But as rasterio.Env() seems to take care about restoring the environment to<br>
what it was about, I would have thought that folks could do safely things like<br>
<br>
1: do osgeo.gdal stuff<br>
2:  with rasterio.Env(): do rasterio stuff<br>
3 : do osgeo.gdal stuff<br>
<br>
Actually taking a look at rasterio/_drivers.pyx , it seems that the error<br>
handler isn't restored, so could be an issue if folks in 1. would install a<br>
custom global one. I guess the reason for not restoring the previous handler<br>
is for workflows like<br>
<br>
with rasterio.Env()<br>
     src = rasterio.open()<br>
do stuff with src<br>
<br>
where you cannot restore the error handler at a precise point.<br>
<br>
To address this, a possibility would be for rasterio to use<br>
CPLPushErrorHandler() / CPLPopErrorHandler() around each call, or group of<br>
calls, it makes to GDAL.<br></blockquote><div><br></div><div>Yes, this is a good idea. It is achievable and will make Rasterio more compatible with osgeo.gdal (as well as the Fiona modules).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
GDALEnv.start() calls GDALAllRegister, so potentially if folks had de-<br>
registered a driver in 1., then will find it registered again in step 3., but<br>
that's a pretty uncommon use case (I'm not aware of anyone using<br>
driver.Deregister() / driver.Register() except in GDAL autotest suite to make<br>
sure the right jpeg2000 driver is used)<br>
<br>
Apart from that, it isn't obvious to me why things couldn't be mixed in the<br>
same process. I guess that even in 2. you could call osgeo.gdal stuff in a<br>
reasonably safe way (with the environment & error handler set by rasterio of<br>
course)<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Reading again, I'm not sure that "Additionally, gdal and Rasterio register<br>
conflicting error handlers and thus the propagation of exceptions and warnings<br>
may depend on which module was imported last." is true. Importing gdal.osgeo<br>
only calls GDALAllRegister() and as far as I understood importing rasterio is<br>
a no-op regarding calls to the GDAL API.<br></blockquote><div><br></div><div>Thank you for correcting me. It's gdal.UseExceptions() that calls CPLSetErrorHandler(), yes? And so I should say "may depend on whether rasterio.Env() or gdal.UseExceptions() was called last."</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
Regarding the example 'with rasterio.Env(GDAL_CACHEMAX=<wbr>512):', there's a<br>
potential pitfall in that the GDAL_CACHEMAX config option is read *only* the<br>
first time GDALGetCacheMax()/<wbr>GDALGetCacheMax64() is called, so changing it<br>
afterwards will have no effect.<br>
<br>
So if you do things like<br>
<br>
with rasterio.Env(GDAL_CACHEMAX=<wbr>512):<br>
        rasterio.open(...)<br>
<br>
with rasterio.Env(GDAL_CACHEMAX=<wbr>1024):<br>
        rasterio.open(...)  <-- will only see the effect GDAL_CACHEMAX=512<br>
<br>
If you want to actively change the value you must call GDALSetCacheMax() /<br>
GDALSetCacheMax64().<br></blockquote><div><br></div><div>Good to know! I will change my example and deal with this issue in Rasterio.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
More about a rasterio design choice: I see that the master representation used<br>
in rasterio for a crs is the proj.4 string (or +init=epsg:XXXX when detected),<br>
right ? So "src.crs.wkt" will not give you back the original WKT string coming<br>
from GDAL but one that is reconstructed by using OSRImportFromProj4() (or<br>
OSRImportFromEPSG()) and then OSRExportToWKT(). This might work well in most<br>
use cases where the CRS is not too exotic, but you might lose for example the<br>
actual datum name, which could be a problem if folks want to select another<br>
datum shift than the one proposed by default, or think about CRS for imagery<br>
of other planets.<br></blockquote><div><br></div><div>Yes, I think Rasterio's CRS class should probably switch to WKT for its canonical representation sooner than later.</div><div><br></div><div>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.</div><div><br></div></div>-- <br><div class="gmail_signature"><div dir="ltr">Sean Gillies</div></div>
</div></div>