Coordinate axis order in northing/easting (Y/X) in WFS/GML

[travenin]

My project for City of Helsinki uses coordinate reference system EPSG:3879. We have a problem with latitude and longitude axis order in WFS GML output when using django-gisserver version 1.2.4.

WFS 2.0.0 (with GML 3.2) should respects the axis order defined by the EPSG definition (unlike WFS 1.0.0 which is always easting/northing or (X,Y)). EPSG:3879 defines coordinate axis order as northing/easting (Y,X).

For query <server url>/wfs/?SERVICE=WFS&VERSION=2.0.0&REQUEST=GetFeature&TYPENAMES=signpost&OUTPUTFORMAT=application/gml+xml&srsName=urn:ogc:def:crs:EPSG::3879 we are expecting:

*snip*
<app:location>
  <gml:Point srsName="urn:ogc:def:crs:EPSG::3879" gml:id="signpost.1">
    <gml:pos srsDimension="3">6673364.2700978 25494172.7053077 0</gml:pos>
  </gml:Point>
</app:location>
*snip*

where 6673364.2700978 is latitude (Y) and 25494172.7053077 is longitude (X).

However, the actual result has invert latitude and longitude:

*snip*
<app:location>
  <gml:Point srsName="urn:ogc:def:crs:EPSG::3879" gml:id="signpost.1">
    <gml:pos srsDimension="3">25494172.7053077 6673364.2700978 0</gml:pos>
  </gml:Point>
</app:location>
*snip*

Do I have something wrong in my configuration? Or is this a missing feature or bug in django-gisserver?

[lbam]

Looks like missing functionality. We just render the coordinates in the order django.contrib.gis.geos.Point.coords has them.

[vdboor]

Another factor here might be the used Django version and GDAL version. As of GDAL 3, the axis ordering was changed. Django 3.1 and later have support for that.

In gisserver/geometries.py you'll find some comments regarding this issue. What you might be able to do, is pass a custom backend to the constructed CRS object. For example:

from django.contrib.gis.gdal import AxisOrder, SpatialReference
from gisserver.geometries import CRS

# Define the actual GDAL backend yourself, so the CRS object will use that:
gk25fin = CRS("EPSG:3879", backend=SpatialReference(3879, srs_type="epsg", axis_order=AxisOrder.AUTHORITY))

# Pass the CRS object to the feature type:
feature_types = [
    FeatureType(
        ...,
        crs=gk25fin,
        other_crs=[..., gk25fin],  # or this one.
    )
]

The rest of the code really just reads what GDAL will provide (like @lbam mentioned).

For some background info, see:

• https://gdal.org/tutorials/osr_api_tut.html#crs-and-axis-order
• django/django@58f1b07

Hope this helps!

and bye the way, we love that you guys started using this project too! (and for that matter completely extended it as well, exactly as the design intended).

[jforsman]

Well, atleast does not work like this, any ideas? I will dig in further soonish anyways...

DEFAULT_CRS = CRS.from_srid(3879, backend=SpatialReference(3879, srs_type="epsg", axis_order=AxisOrder.AUTHORITY))

[jforsman]

Well, I gave up and decided to just overwrite a couple of more functions from GML32Renderer

[jforsman]

btw. do you consider this as a feature or a bug?
@register_geos_type(geos.MultiPolygon) def render_gml_multi_geometry(self, value: geos.GeometryCollection, base_attrs): children = "".join(self._render_gml_type(child) for child in value) return f"<gml:MultiGeometry{base_attrs}>{children}</gml:MultiGeometry>"
Currently there is not any rendered for GeometryCollections