[Bug]: WMS print requests for northing-easting coordinate order CRS' are incorrect (result in an incorrectly located map)

[timbo-barnes]

What is the bug? (in English)

When trying to print/send a WMS print request from a map using a CRS with non-standard coordinate order (i.e. EPSG: 2193), the print fails.

In EPSG 2193 (which doesn't print), coordinate order is northing then easting within the CRS definition:

    CS[Cartesian,2],
        AXIS["northing (N)",north,
            ORDER[1],
            LENGTHUNIT["metre",1]],
        AXIS["easting (E)",east,
            ORDER[2],
            LENGTHUNIT["metre",1]],

For EPSG 3857 (which does print), coordinate order is easting then northing:

    CS[Cartesian,2],
        AXIS["easting (X)",east,
            ORDER[1],
            LENGTHUNIT["metre",1]],
        AXIS["northing (Y)",north,
            ORDER[2],
            LENGTHUNIT["metre",1]],

From the QGIS server Documents
Similarly, external layers can be used in GetPrint requests:

http://localhost/qgisserver?
SERVICE=WMS
&REQUEST=GetPrint
&TEMPLATE=A4
&map0:layers=EXTERNAL_WMS:basemap,layer1,layer2
&map0:EXTENT=**<minx,miny,maxx,maxy>**

What's confusing to me, is that the 'extent' string in the print request does appear to be valid (i.e. minx, miny, maxx, maxy) (as shown in the log output below) but the output print is flipped. Is this therefore an issue with QGIS server itself or Lizmap?

In the QGIS server documentation, there are differences in BBOX order between WMS version 1.3 and 1.1.1 but it doesn't list any such differences for EXTENT which is used here

(note this is re-up of the issue here which got closed: #4558)

Steps to reproduce the issue

1. Create lizmap with data in EPSG: 2193 and associated layout
2. Generate a print request
3. Print will be 'flipped' with eastings as northings and northings as eastings. The returned map will be generated somewhere different than expected.

Versions, safeguards, check summary etc

Versions :

• Lizmap Web Client : 3.7.8
• Lizmap plugin : 4.4.2
• QGIS Desktop : 3.38.0
• QGIS Server : 3.38.3
• Py-QGIS-Server : not used
• QGIS Server plugin atlasprint : 3.4.1
• QGIS Server plugin lizmap_server : 2.9.4
• QGIS Server plugin wfsOutputExtension : 1.8.0

List of Lizmap Web Client modules :

* Version Lizmap Web Client 3.8 needed

List of safeguards :

* Mode : normal * Allow parent folder : no * Prevent other drive : yes * Prevent PG service : no * Prevent PG Auth DB : yes * Force PG user&pass : yes * Prevent ECW : yes

Check Lizmap plugin

• I have done the step just before in the Lizmap QGIS desktop plugin before opening this ticket. Otherwise, my ticket is not considered valid and might get closed.

Operating system

Ubuntu Linux 22.04.4

Browsers

Firefox, Chrome, Microsoft Edge

Browsers version

Crhome:129.0.6668.101, Firefox: 131.0, Edge: 129.0.2792.79

Relevant log output

SERVICE=WMS&REQUEST=GetPrint&VERSION=1.3.0&FORMAT=pdf&TRANSPARENT=true&CRS=EPSG%3A2193&DPI=100&TEMPLATE=Test%20normal&map0%3AEXTENT=1797759.0972191186%2C5680485.47608134%2C1802984.0972191186%2C5684210.47608134&map0%3ASCALE=25000&map0%3ALAYERS=Aerial_Imagery_Basemap%2Cforests&map0%3ASTYLES=default%2Cforests&map0%3AOPACITIES=255%2C255&map0%3AGRID_INTERVAL_X=500&map0%3AGRID_INTERVAL_Y=500

[timbo-barnes]

I can confirm that this is an issue with coordinate order of an EXTENT when using SERVICE=WMS&REQUEST=GetPrint&VERSION=1.3.0

Manually changing a GetPrint request to VERSION=1.1.1 correctly generates a print, meaning that coordinate order is not being sent correctly from Lizmap, based on the CRS of the map.

Within wms.js, there appears to be a check to change the xy order depending on CRS for WMS 1.3 requests, but this seems like it's only applying to BBOX, not EXTENT

(for any future reference, for a quick fix, you can edit the minified lizmap.js in assets/js, about line 468. Change to ......REQUEST:"GetPrint",VERSION:"1.1.1" ........).