[Django] #31712: Inconsistent axes definition between PostGIS and Spatialite for 4326
Django
-----------------------------------------+------------------------
Reporter: Jérôme Lebleu | Owner: nobody
Type: Uncategorized | Status: new
Component: GIS | Version: 3.0
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-----------------------------------------+------------------------
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
[https://postgis.net/2013/08/18/tip_lon_lat 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 [http://www.epsg-
registry.org/report.htm?type=selection&entity=urn:ogc:def:crs:EPSG::4326&reportDetail=short&style=urn:uuid
:report-style:default-with-
code&style_name=OGP%20Default%20With%20Code&title=EPSG::4326 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!
--
Ticket URL: <https://code.djangoproject.com/ticket/31712>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: Jérôme Lebleu | Owner: nobody
Component: GIS | Version: 3.1
Severity: Normal | Resolution: duplicate
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by felixxm):
* status: new => closed
* type: Uncategorized => New feature
* version: 3.0 => 3.1
* resolution: => duplicate
Comment:
Django 3.0 doesn't support GDAL 3. Duplicate of #30678.
--
Ticket URL: <https://code.djangoproject.com/ticket/31712#comment:1>
Django
Reporter: Jérôme Lebleu | Owner: nobody
Type: Uncategorized | Status: new
Component: GIS | Version: 3.0
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/31712#comment:1>
Django
Reporter: Jérôme Lebleu | Owner: nobody
Component: GIS | Version: 3.1
Severity: Normal | Resolution: duplicate
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Jérôme Lebleu):
* status: new => closed
* type: Uncategorized => New feature
* version: 3.0 => 3.1
* resolution: => duplicate
Comment:
Replying to [comment:1 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/31712#comment:2>