Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#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 Yury Ryabov)

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 Yury Ryabov, 5 years ago

Description: modified (diff)

comment:2 by Mariusz Felisiak, 5 years ago

Summary: Add support for GDAL 2.4 and GDAL 3.0Confirm support for GDAL 3.0.
Triage Stage: UnreviewedAccepted
Type: New featureCleanup/optimization
Version: 2.2master

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

comment:3 by Adam Starrh, 5 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 Claude Paroz, 5 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 Simon Meers, 5 years ago

Cc: Simon Meers added

comment:6 by Claude Paroz, 4 years ago

Owner: changed from nobody to Claude Paroz
Status: newassigned

comment:7 by Claude Paroz, 4 years ago

Has patch: set

comment:8 by Mariusz Felisiak, 4 years ago

Triage Stage: AcceptedReady for checkin

comment:9 by Mariusz Felisiak <felisiak.mariusz@…>, 4 years ago

Resolution: fixed
Status: assignedclosed

In 58f1b07e:

Fixed #30678 -- Added support for GDAL 3.

comment:10 by GitHub <noreply@…>, 4 years ago

In 91e287cc:

Refs #30678 -- Added support for GDAL 3.1.

OSRSetAxisMappingStrategy() really returns void, so no errcheck is
needed. Previously set errcheck was raising positive false exceptions
on GDAL 3.1.

Note: See TracTickets for help on using tickets.
Back to Top