#30678 closed Cleanup/optimization (fixed)
Confirm support for GDAL 3.0.
| Reported by: | Yury Ryabov | Owned by: | Claude Paroz |
|---|---|---|---|
| Component: | GIS | Version: | dev |
| Severity: | Normal | Keywords: | GDAL, GIS |
| Cc: | Simon Meers | Triage Stage: | Ready for checkin |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description (last modified by )
Neither of these versions works correctly with Django 2.2 as reported here. It causes a lot of inconvenience on systems with openSUSE as modern versions are shipped with GDAL 2.4 or higher.
Please add support for the newer versions of GDAL.
Change History (10)
comment:1 by , 5 years ago
| Description: | modified (diff) |
|---|
comment:2 by , 5 years ago
| Summary: | Add support for GDAL 2.4 and GDAL 3.0 → Confirm support for GDAL 3.0. |
|---|---|
| Triage Stage: | Unreviewed → Accepted |
| Type: | New feature → Cleanup/optimization |
| Version: | 2.2 → master |
comment:3 by , 4 years ago
This still doesn't seem to be working for me. The latest version of Django that I get from pip (2.2.6) does not contain gdal204 in the libgdal.py file as indicated in the above comment (which seems to link to code for the Django 3 beta). Furthermore, if I add it manually, which worked last time, it still doesn't solve the issue. If I set GDAL_LIBRARY_PATH to the .dll directly, I get: OSError: [WinError 126] The specified module could not be found.
Is this working on other Windows systems with the latest version of OSGeo4Win? As it stands, following the directions in the GeoDjango docs isn't resulting in a successful installation for me.
comment:4 by , 4 years ago
See also https://code.djangoproject.com/ticket/30645#comment:5
Basically, it's a matter of interpreting the coordinate ordering, e.g. when an input is POINT(10, -100).
GIS systems tend to always interpret as x (longitude), y (latitude). However, SRS do define their own axis order, and typically the axis order of WGS 84 (GPS) is latitude, longitude.
So GDAL v3 decided to honor the SRS ordering when interpreting coordinates, which of course can be badly backwards incompatible. However they provided an API to restore the old behavior (SetAxisMappingStrategy). We have now to define our strategy to integrate this change in GeoDjango.
comment:5 by , 4 years ago
| Cc: | added |
|---|
comment:6 by , 4 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:8 by , 4 years ago
| Triage Stage: | Accepted → Ready for checkin |
|---|
Support for GDAL 2.4 was confirmed in b2333426deb1ae9529bed79c1412a9a8046da951 and it didn't require any changes in Django (see related PR).
Agreed, we should confirm support for GDAL 3.0+.