Axis order of response coordinates does not follow the requested CRS axis order

[komima]

With a collection like

{
  "id" : "jobs",
  "title" : "jobs",
  "description" : "jobs",
  "links" : [ ... ],
  "itemType" : "feature",
  "crs" : [ "http://www.opengis.net/def/crs/OGC/1.3/CRS84", "http://www.opengis.net/def/crs/EPSG/0/4326", "http://www.opengis.net/def/crs/EPSG/0/3903" ],
  "storageCrs" : "http://www.opengis.net/def/crs/EPSG/0/3903"
}

and requesting items with ?crs=http://www.opengis.net/def/crs/EPSG/0/3903 the axis order of the response is not reversed (has E,N), while the CRS has N,E.

There seems to be some confusion on the axis order that should be followed on the response (crs-based or always geojson-easting-northing), but the consensus seems to be on prior arragement: client must understand what it requests, and the response header Content-Crs defined in part 2 now "explicitly and unambiguously" defines the response coordinate contents => axis order follows crs.

geopython/pygeoapi#1174 (comment)
qgis/QGIS#52366 (comment)

This breaks hakunapi-based OAPIF layer use for example in QGIS (3.28.7+, 3.30.2+, 3.32.0+) where the implementation was changed to flip the order according to the crs.

[jampukka]

Thanks for raising the issue. We should move towards a model where hakunapi internally always forces XY-order and let both input and output formats act accordingly.

Something to discuss: should we use external information on the axis order of a certain CRS (for example geotools epsg-hsql) or require configuration for each crs (with sensible/configurable default)? We already do require users to configure available CRSes.

[jratike80]

Maybe JSON-FG makes this issue outdated, and GeoJSON gets reserved for CRS:84 while for any other crs the output should use JSON-FG. Who knows. The specification is not accepted yet, but GDAL-dev has a new driver for JSON-FG that can be used as reference implementation https://gdal.org/drivers/vector/jsonfg.html.

[jratike80]

I do not know how this hakunapi service is configured, but it does return the coordinates in northing-easting order for the Finnish GK zones.
https://avoin-paikkatieto.maanmittauslaitos.fi/kiinteisto-avoin/simple-features/v3/collections/PalstanSijaintitiedot/items?crs=http://www.opengis.net/def/crs/EPSG/0/3878

The service requires an API key, but anybody can get such from https://omatili.maanmittauslaitos.fi/user/new/avoimet-rajapintapalvelut?lang=en.

[jampukka]

#55 should fix this issue and is included in version 1.1.0