Allow GDAL library detection to work with non "dot zero" releases

[Adam Starrh]

Setting up GeoDjango on Windows has stopped working when following the installation instructions in the docs. I suspect there may be a version issue.

I get the following message when I attempt python manage.py migrate

django.contrib.gis.gdal.error.GDALException: Could not find the GDAL library (tried "gdal111", "gdal110", "gdal19", "gdal18", "gdal17"). Try setting GDAL_LIBRARY_PATH in your settings.

Digging around in the OSGeo4Win directories, these are the only files that come close to matching: "gdal201.dll" and "gdal202.dll"

If anyone knows a workaround, please share. This has put the brakes on our project.

Problem occurs for me on Windows 10 with the latest OSGeo4Win installer and Django 1.11 with both Python 3.1 and 3.0.

[Claude Paroz]

Reading your error message, it's not coming from Django 1.11.
See ​https://github.com/django/django/blob/stable/1.11.x/django/contrib/gis/gdal/libgdal.py where this message come from.
Then you may try to set GDAL_LIBRARY_PATH, as the message suggests (also ​https://docs.djangoproject.com/en/1.11/ref/contrib/gis/install/geolibs/#gdallibrarypath).

This looks more like a support request than a Django bug.
https://code.djangoproject.com/wiki/TicketClosingReasons/UseSupportChannels

[Tim Graham]

You could try modifying the libgdal.py file that Claude linked to. For example, if adding str('gdal202') (due to the presence of the gdal202.dll file you mentioned) to the list on line 26 fixes the issue, we might consider that change for Django.

[Adam Starrh]

Tim,

This worked like a charm! Thanks so much, I'd spent three full days looking for a solution.

Claude- I'd already been through the docs you linked to. There is nothing written for Windows in that section and setting GDAL_LIBRARY_PATH directly to the .dlls didn't work either. I think this ticket should be reopened, as this modification to the core code seemed to get it working as normal. Thanks again guys!

[Adam Starrh]

I went ahead and made a Pull Request with this edit:

​https://github.com/django/django/pull/8548

[Tim Graham]

Good to hear, however, the current approach of requiring an update to Django for every major and minor release of GDAL may not be ideal.

[Claude Paroz]

It might be better to provide a working example of a GDAL_LIBRARY_PATH on Windows (if there is one).

[Adam Starrh]

They seem to follow a pattern: "gdal" followed by 2-4 numbers. Would a constrained regular expression be considered reliable enough?

[Adam Starrh]

Requiring the file to be pointed to in the settings would be problematic for someone like me who needs my project to work on both my Windows and Mac machines. From the looks of it, this setting would have to be different per individual coding environment. As well, the location of the .dll can change from one machine to another, if you are switching between 32/64 bit for example.

[Adam Starrh]

Just for reference, I looked up the library being used to search for the file:

​https://docs.python.org/2/library/ctypes.html#finding-shared-libraries

It seems like it has some limitations with regards to Windows:

On Windows, find_library() searches along the system search path, and returns the full pathname, but since there is no predefined naming scheme a call like find_library("c") will fail and return None. If wrapping a shared library with ctypes, it may be better to determine the shared library name at development time, and hardcode that into the wrapper module instead of using find_library() to locate the library at runtime.

I guess that's why the decision was made to do it this way. Perhaps there is a more accommodating library that could be used?

[Tim Graham]

We could generate a list of lib_names of the form gdalXY where X is the supported major versions and Y is in the range 0 through 5 or so (there have been at most five minor versions of ​recent GDAL releases). This doesn't seem ideal. I don't know if there's a better way.

[Adam Starrh]

Actually,

It looks to me like the .dll filenames only seem to change with major releases.

I think

"gdal111", "gdal110", "gdal19", "gdal18", "gdal17"

are versions: 1.11, 1.10, 1.9, 1.8 and 1.7, respectively.

If this is the case, then it's likely that

"gdal201", "gdal202"

are versions: 2.1 and 2.2 with leading zeroes now included.

Given that 2.1 and 2.2 are versions that have been released, its unlikely that I am getting 2.0.1 and 2.0.2 dlls in my download.

[Tim Graham]

Thanks. Then we should correct 'gdal21' to 'gdal201' and we'll have to confirm if any changes are needed to get Django's tests passing with GDAL 2.2 (see ebaa2fef27644430e2b9dfa912f02e39582bfc05 for required documentation changes).

[Tim Graham]

​PR to correct GDAL 2.1 detection on Windows.

Claude or Daniel, are you able to confirm GDAL 2.2 support? We might consider backporting that to Django 1.11 as long as major changes aren't required.

[Tim Graham]

I opened #28257 for confirming support for GDAL 2.2.