Opened 4 years ago

Closed 4 years ago

#31712 closed New feature (duplicate)

Inconsistent axes definition between PostGIS and Spatialite for 4326

Reported by: Jérôme Lebleu Owned by: nobody
Component: GIS Version: 3.1
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

I am using GeoDjango - for the first time, sorry if I missed something - to store a Point field in my model, which is included in a GeoJSON response using the shipped serializer, and finally shown on a map using OpenLayers. The default SRID (4326) is used, and I am using a SQLite database with Spatialite module in development, and a PostgreSQL database with PostGIS in production.

It took me a while to understand - in the hope I am right - that axes are not stored the same way in both backends:

  • in PostGIS, coordinates of a Point are [x = longitude, y = latitude], explained in this quick and old tip and the SRS is:
    GEOGCS["WGS 84",
        DATUM["WGS_1984",
            SPHEROID["WGS 84",6378137,298.257223563,
                AUTHORITY["EPSG","7030"]],
            AUTHORITY["EPSG","6326"]],
        PRIMEM["Greenwich",0,
            AUTHORITY["EPSG","8901"]],
        UNIT["degree",0.0174532925199433,
            AUTHORITY["EPSG","9122"]],
        AUTHORITY["EPSG","4326"]]
    
  • in SpatiaLite, coordinates are [x = latitude, y = longitude], which complies to the current EPSG definition and the SRS:
    GEOGCS["WGS 84",
        DATUM["WGS_1984",
            SPHEROID["WGS 84",6378137,298.257223563,
                AUTHORITY["EPSG","7030"]],
            AUTHORITY["EPSG","6326"]],
        PRIMEM["Greenwich",0,
            AUTHORITY["EPSG","8901"]],
        UNIT["degree",0.0174532925199433,
            AUTHORITY["EPSG","9122"]],
        AXIS["Latitude",NORTH],
        AXIS["Longitude",EAST],
        AUTHORITY["EPSG","4326"]]
    

Thus, currently, when I retrieve a Point field with GeoDjango, the axes order will depend on the database backend. It makes it difficult so to realize a backend-agnostic application and I would prevent checks in the application code to know if [point.x, point.y] or [point.y, point.x] should be returned. Where could that be "solved" - i.e. in the GeoDjango code, or somewhere at the database creation? - and how to always retrieve the same coordinates with GeoDjango?

Also, any tips or help to "fix" this meanwhile would be really appreciate since I am a bit stuck. Thanks in advance!

Change History (2)

comment:1 by Mariusz Felisiak, 4 years ago

It think it's related with GDAL 3.0. Django 3.0 doesn't support it. Can you confirm version of GDAL?

Probably duplicate of #30678.

in reply to:  1 comment:2 by Jérôme Lebleu, 4 years ago

Resolution: duplicate
Status: newclosed
Type: UncategorizedNew feature
Version: 3.03.1

Replying to felixxm:

It think it's related with GDAL 3.0. Django 3.0 doesn't support it. Can you confirm version of GDAL?

Probably duplicate of #30678.

Indeed, I am using GDAL 3.1 in development. Thanks for your quick answer and sorry for this duplicate, I didn't search enough.

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