Opened 7 years ago

Closed 7 years ago

#28237 closed Cleanup/optimization (invalid)

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

Reported by: Adam Starrh Owned by: nobody
Component: GIS Version: 1.11
Severity: Normal Keywords: GIS, OSGeo4Win
Cc: Claude Paroz, Daniel Wiesmann Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


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 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.

Change History (16)

comment:1 by Claude Paroz, 7 years ago

Resolution: worksforme
Status: newclosed

Reading your error message, it's not coming from Django 1.11.
See where this message come from.
Then you may try to set GDAL_LIBRARY_PATH, as the message suggests (also

This looks more like a support request than a Django bug.

comment:2 by Tim Graham, 7 years ago

You could try modifying the 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.

comment:3 by Adam Starrh, 7 years ago


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!

comment:4 by Adam Starrh, 7 years ago

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

comment:5 by Tim Graham, 7 years ago

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.

comment:6 by Claude Paroz, 7 years ago

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

comment:7 by Adam Starrh, 7 years ago

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

comment:8 by Adam Starrh, 7 years ago

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.

Last edited 7 years ago by Adam Starrh (previous) (diff)

comment:9 by Adam Starrh, 7 years ago

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

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?

comment:10 by Tim Graham, 7 years ago

Easy pickings: unset
Summary: OSGeo4Win & GDAL Version Issue?Allow GDAL library detection to work with non "dot zero" releases
Triage Stage: UnreviewedAccepted
Type: BugCleanup/optimization

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.

comment:11 by Tim Graham, 7 years ago

Resolution: worksforme
Status: closednew

comment:12 by Adam Starrh, 7 years ago


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.

Last edited 7 years ago by Adam Starrh (previous) (diff)

comment:13 by Tim Graham, 7 years ago

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).

comment:14 by Tim Graham, 7 years ago

Cc: Claude Paroz Daniel Wiesmann added

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.

comment:15 by Tim Graham, 7 years ago

I opened #28257 for confirming support for GDAL 2.2.

comment:16 by Tim Graham, 7 years ago

Resolution: invalid
Status: newclosed
Note: See TracTickets for help on using tickets.
Back to Top