id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
31712	Inconsistent axes definition between PostGIS and Spatialite for 4326	Jérôme Lebleu	nobody	"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!"	New feature	closed	GIS	3.1	Normal	duplicate			Unreviewed	0	0	0	0	0	0