Inconsistent axes definition between PostGIS and Spatialite for 4326

[Jérôme Lebleu]

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!

[Mariusz Felisiak]

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.

[Jérôme Lebleu]

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.