-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pyogrio.errors.DataSourceError: No driver registered #448
Comments
Thanks for the report! This is a tricky one, and appears to be an order of operations, possibly loading issue loading the GDAL library multiple times from different packages (e.g., pyogrio, rasterio). I can reproduce locally by installing a Conda env based on your environment. I'm seeing that it appears to work properly at first and then fail later. To test this, I edited the When I run the equivalent of your If I run the failing file directly: It loads all drivers successfully and works as expected. If I comment out the contents of I've isolated the problematic line that changes the behavior of loading drivers in pyogrio. If we import pyogrio and list drivers before this, they are as expected. If we import pyogrio after this line, no drivers are loaded. I don't use xarray, so I'm not able to go much further down this rabbit hole. Based on what I'm seeing, this isn't an error that is caused directly by pyogrio (though please follow up here if you discover otherwise). It seems to be based on multiple libraries loading GDAL differently and then based on order of operations, seems to be leaving the drivers available in GDAL in a bad state when subsequent packages try to load GDAL. |
@snowman2 do you have any ideas about what might be causing this order of operations driver loading issue based on |
rioxarray imports rasterio. Did you try importing rasterio before/after pyogrio? |
Here is a much smaller working example (compared to building the PyGMT documentation) to reproduce the issue: import geopandas as gpd
gdf = gpd.read_file("https://www2.census.gov/geo/tiger/TIGER2015/PRISECROADS/tl_2015_15_prisecroads.zip")
import pygmt
fig = pygmt.Figure()
fig.tilemap(region=[-157.84, -157.8, 21.255, 21.285], projection="M12c", zoom=14, frame="afg")
fig.show()
gdf = gpd.read_file("https://www2.census.gov/geo/tiger/TIGER2015/PRISECROADS/tl_2015_15_prisecroads.zip") |
Importing rasterio first works fine (as does simply importing Thanks for the smaller example @seisman . It looks like an offending section in with Session() as lib:
with lib.virtualfile_in(check_kind="raster", data=raster) as vingrd:
lib.call_module(
module="grdimage", args=build_arg_list(kwargs, infile=vingrd)
) |
Thanks so much @brendan-ward for taking the time to debug this! Your comment at #448 (comment) makes a lot of sense (to me at least), I spent hours debugging this and did notice how the first @seisman, it seems like GMT might also be calling |
It's likely. Here is an even smaller example to reproduce it, without calling the
The upstream documentation says (https://gdal.org/api/raster_c_api.html#_CPPv415GDALAllRegisterv):
but apparently, it's called multiple times even in GMT. |
We've been hitting into an issue on pyogrio not being able to detect GDAL drivers in our Sphinx docs build CI since two weeks ago (GenericMappingTools/pygmt#3301), with errors like:
pyogrio.errors.DataSourceError: No driver registered.
pyogrio.errors.DataSourceError: Could not obtain driver: OGR_GMT (check that it was installed correctly into GDAL)
We're using
geopandas=1.0.1 (pyhd8ed1ab_0)
andpyogrio=0.9.0 (py312h8ad7a51_0)
installed from conda-forge, which includes the OGR_GMT driver (installed inGDAL=3.9.0 (py312h86af8fa_5)
). This issue has been very hard to reproduce, because things work when we test things directly, but fail when running the scripts withsphinx-build
. E.g. this code example:would consistently produce a
pyogrio.errors.DataSourceError: No driver registered
error when ran as part ofsphinx-build
:or produce the expected output when ran directly in a Python script or Jupyter notebook:
My guess is that the GDAL drivers are not being registered properly somehow. This was supposedly fixed in #145 (see also #144), but there might be certain cases where the loading doesn't happen correctly? We have a workaround right now that forces the driver load like so:
but given that
_register_drivers
is a private method, we would prefer not to rely on it. We're opening this issue to try to figure out where the GDAL driver loading logic might be failing even after #145. Unsure if puttingGDALAllRegister()
back in _io.pyx and/or _ogr.pyx would help, or if there is another solution we can try.The text was updated successfully, but these errors were encountered: