[Django] #28237: OSGeo4Win & GDAL Version Issue?
Django
--------------------------------------+--------------------------------
Reporter: astarrh | Owner: nobody
Type: Bug | Status: new
Component: GIS | Version: 1.11
Severity: Normal | Keywords: GIS, OSGeo4Win
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 1
UI/UX: 0 |
--------------------------------------+--------------------------------
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/28237>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: Adam Starrh | Owner: nobody
Type: Bug | Status: closed
Component: GIS | Version: 1.11
Severity: Normal | Resolution: worksforme
Keywords: GIS, OSGeo4Win | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Changes (by Claude Paroz):
* status: new => closed
* resolution: => worksforme
Comment:
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
--
Ticket URL: <https://code.djangoproject.com/ticket/28237#comment:1>
Django
Reporter: Adam Starrh | Owner: nobody
Type: Bug | Status: closed
Component: GIS | Version: 1.11
Severity: Normal | Resolution: worksforme
Keywords: GIS, OSGeo4Win | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Comment (by 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/28237#comment:2>
Django
Reporter: Adam Starrh | Owner: nobody
Type: Bug | Status: closed
Component: GIS | Version: 1.11
Severity: Normal | Resolution: worksforme
Keywords: GIS, OSGeo4Win | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Comment (by 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!
--
Ticket URL: <https://code.djangoproject.com/ticket/28237#comment:3>
Django
Reporter: Adam Starrh | Owner: nobody
Type: Bug | Status: closed
Component: GIS | Version: 1.11
Severity: Normal | Resolution: worksforme
Keywords: GIS, OSGeo4Win | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Comment (by Adam Starrh):
I went ahead and made a Pull Request with this edit:
https://github.com/django/django/pull/8548
--
Ticket URL: <https://code.djangoproject.com/ticket/28237#comment:4>
Django
Reporter: Adam Starrh | Owner: nobody
Type: Bug | Status: closed
Component: GIS | Version: 1.11
Severity: Normal | Resolution: worksforme
Keywords: GIS, OSGeo4Win | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Comment (by 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/28237#comment:5>
Django
Reporter: Adam Starrh | Owner: nobody
Type: Bug | Status: closed
Component: GIS | Version: 1.11
Severity: Normal | Resolution: worksforme
Keywords: GIS, OSGeo4Win | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Comment (by Claude Paroz):
It might be better to provide a working example of a `GDAL_LIBRARY_PATH`
on Windows (if there is one).
--
Ticket URL: <https://code.djangoproject.com/ticket/28237#comment:6>
Django
Reporter: Adam Starrh | Owner: nobody
Type: Bug | Status: closed
Component: GIS | Version: 1.11
Severity: Normal | Resolution: worksforme
Keywords: GIS, OSGeo4Win | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Comment (by Adam Starrh):
They seem to follow a pattern: "gdal" followed by 2-4 numbers. Would a
constrained regular expression be considered reliable enough?
--
Ticket URL: <https://code.djangoproject.com/ticket/28237#comment:7>
Django
Reporter: Adam Starrh | Owner: nobody
Type: Bug | Status: closed
Component: GIS | Version: 1.11
Severity: Normal | Resolution: worksforme
Keywords: GIS, OSGeo4Win | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Comment (by 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/28237#comment:8>
Django
Reporter: Adam Starrh | Owner: nobody
Type: Bug | Status: closed
Component: GIS | Version: 1.11
Severity: Normal | Resolution: worksforme
Keywords: GIS, OSGeo4Win | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Comment (by 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?
--
Ticket URL: <https://code.djangoproject.com/ticket/28237#comment:9>
Django
-------------------------------------+-------------------------------------
Reporter: Adam Starrh | Owner: nobody
Cleanup/optimization |
Component: GIS | Version: 1.11
Severity: Normal | Resolution:
| worksforme
Keywords: GIS, OSGeo4Win | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
-------------------------------------+-------------------------------------
Changes (by Tim Graham):
* stage: Unreviewed => Accepted
* type: Bug => Cleanup/optimization
* easy: 1 => 0
Comment:
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
[https://trac.osgeo.org/gdal/wiki/DownloadSource recent GDAL releases]).
This doesn't seem ideal. I don't know if there's a better way.
--
Ticket URL: <https://code.djangoproject.com/ticket/28237#comment:10>
Django
Reporter: Adam Starrh | Owner: nobody
Component: GIS | Version: 1.11
Severity: Normal | Resolution:
Keywords: GIS, OSGeo4Win | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
--------------------------------------+------------------------------------
Changes (by Tim Graham):
* status: closed => new
* resolution: worksforme =>
--
Ticket URL: <https://code.djangoproject.com/ticket/28237#comment:11>
Django
--------------------------------------+------------------------------------
Reporter: Adam Starrh | Owner: nobody
Component: GIS | Version: 1.11
Severity: Normal | Resolution:
Keywords: GIS, OSGeo4Win | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
--------------------------------------+------------------------------------
Comment (by 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.7**, **1.8**, **1.9**, **1.10** and **1.11**
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/28237#comment:12>
Django
--------------------------------------+------------------------------------
Reporter: Adam Starrh | Owner: nobody
Component: GIS | Version: 1.11
Severity: Normal | Resolution:
Keywords: GIS, OSGeo4Win | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
--------------------------------------+------------------------------------
Comment (by 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).
--
Ticket URL: <https://code.djangoproject.com/ticket/28237#comment:13>
Django
--------------------------------------+------------------------------------
Reporter: Adam Starrh | Owner: nobody
Component: GIS | Version: 1.11
Severity: Normal | Resolution:
Keywords: GIS, OSGeo4Win | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
--------------------------------------+------------------------------------
Changes (by Tim Graham):
* cc: Claude Paroz, Daniel Wiesmann (added)
Comment:
[https://github.com/django/django/pull/8558 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/28237#comment:14>
Django
--------------------------------------+------------------------------------
Reporter: Adam Starrh | Owner: nobody
Component: GIS | Version: 1.11
Severity: Normal | Resolution:
Keywords: GIS, OSGeo4Win | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
--------------------------------------+------------------------------------
Comment (by Tim Graham):
I opened #28257 for confirming support for GDAL 2.2.
--
Ticket URL: <https://code.djangoproject.com/ticket/28237#comment:15>
Django
--------------------------------------+------------------------------------
Reporter: Adam Starrh | Owner: nobody
Component: GIS | Version: 1.11
Severity: Normal | Resolution: invalid
Keywords: GIS, OSGeo4Win | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
--------------------------------------+------------------------------------
Changes (by Tim Graham):
* status: new => closed
* resolution: => invalid
--
Ticket URL: <https://code.djangoproject.com/ticket/28237#comment:16>