[Bug]: LMWC: 3.7.8 Trying to print in EPSG: 2193 results in flipped coordinates/failed map?

[timbo-barnes]

What is the bug? (in English)

My existing projects in LMWC 3.6.3 worked fine using the 'old' basemap method- Users could use the normal print dialogue to print a custom map or an Atlas map. Maps are in New Zealand Transverse Mercator (2193) including the base layers (WMTS)

Now in 3.7.8, I can't print using the print button (atlas prints work fine)- It appears the dataframe is somehow flipped so eastings are northings and northings are eastings which, obviously, positions the dataframe somewhere completely different. This happens if using a basemap layer (within the new basemap group), a basemap WMTS outside the group as a normal layer, or with no basemap at all (just trying to print vectors in 2193)

Steps to reproduce the issue

Setup a project in NZ Transverse Mercator (EPSG: 2193), add some layers and a layout.
Try and print using the print button.

Versions, safeguards, check summary etc

Versions :

• Lizmap Web Client : 3.7.8
• Lizmap plugin : 4.3.16
• QGIS Desktop : 3.38.0
• QGIS Server : 3.38.0
• 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 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.2

Browsers

Chrome, Microsoft Edge

Browsers version

Chrome: 126.0.6478.114, Edge: 125.0.2535.92

Relevant log output

No Lizmap error logs. Below is the payload/response from Google Chrome> Developement tools

SERVICE: WMS
REQUEST: GetPrint
VERSION: 1.3.0
FORMAT: pdf
TRANSPARENT: true
CRS: EPSG:2193
DPI: 100
TEMPLATE: Test normal
map0:EXTENT: 1794253.0933229104,5664179.919535279,1804703.0933229104,5671629.919535279
map0:SCALE: 50000
map0:LAYERS: forests,infrastructure_tracks_roads,infrastructure_poly
map0:STYLES: forests,infrastructure_tracks_roads,infrastructure_poly
map0:OPACITIES: 255,255,153

(updated to reflect that this problem still exists in v3.38.0 of server)

[Gustry]

QGIS Server : 3.30.3

We do not recommend any non LTR version, QGIS 3.30 is not supported anymore. Can you try on latest QGIS Server 3.34, thanks.
I think we already got a similar issue which has been fixed.

[timbo-barnes]

QGIS Server : 3.30.3

We do not recommend any non LTR version, QGIS 3.30 is not supported anymore. Can you try on latest QGIS Server 3.34, thanks. I think we already got a similar issue which has been fixed.

Ok thanks for the feedback- Is the server version confirmed to be causing it? Or just something to check on the way to fixing it? (The reason I ask is that its taken many months to get Lizmap +QGIS Server upgraded and may be difficult to get server upgraded)

[Gustry]

I don't know. According to the QGIS roadmap, your versions are out dated for more than a year now. A lot of commits have landed in the QGIS source code in between.

[timbo-barnes]

Ok I've updated server version to 3.38.0 and still get the same issue...I think its due to Easting Northing order within the CRS (maybe particular to Southern Hemisphere CRS compared to Northern, or particular to NZTM) not being taken into account or assumed to be Easting-Northern.
This seems to be a regression as printing was working fine for me before I upgraded

Examining the coordinate order for EPSG 2193 is Northing first then Easting:

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

Examining it for, say EPSG 3943 is Easting then Northing
(used in the test maps which do print succesfully here: https://demo.snap.lizmap.com/lizmap_3_7/index.php/view/map?repository=testsrepository&project=print_in_project_projection)

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

[github-actions]

This issue is missing some feedbacks. 👻
Please have a look to the discussion, thanks. 🦎

[timbo-barnes]

This issue is missing some feedbacks. 👻 Please have a look to the discussion, thanks. 🦎

What feedback is needed?

[timbo-barnes]

Some more information below. Im still unsure if this is an issue with how Lizmap generates a print request or how QGIS server interprets that request, but it is related to coordinate order in WMS 1.3.0 (compared to WMS 1.1.1)

v

From the QGIS server documents (https://docs.qgis.org/3.34/en/docs/server_manual/services/wms.html), it indicates that coordinate order has changed. Does this mean that Lizmap must flip its coordinates when generating it's WMS print request for CRS' with flipped coordinate order?

"The BBOX parameter is formed like min_a,min_b,max_a,max_b but a and b axis definition is different according to the current VERSION parameter:

in WMS 1.1.1, the axis ordering is always east/north

in WMS 1.3.0, the axis ordering depends on the CRS authority

For example in case of EPSG:4326 and WMS 1.1.1, a is the longitude (east) and b the latitude (north), leading to a request like:

http://localhost/qgisserver?
SERVICE=WMS
&REQUEST=GetMap
&VERSION=1.1.1
&SRS=epsg:4326
&BBOX=-180,-90,180,90
&...

But in case of WMS 1.3.0, the axis ordering defined in the EPSG database is north/east so a is the latitude and b the longitude:

http://localhost/qgisserver?
SERVICE=WMS
&REQUEST=GetMap
&VERSION=1.3.0
&CRS=epsg:4326
&BBOX=-90,-180,90,180
&...

"