QGIS » QGIS Application

The standard WMS 1.3.0 specifies the pixel width : 0.28 mm

Are you refering to OGC standard or to ISO standard ?

I don't find anything on the OGC version of WMS 1.3 specs. But perhaps I miss them ?

aperi2007 - wrote:

The standard WMS 1.3.0 specifies the pixel width : 0.28 mm

Are you refering to OGC standard or to ISO standard ?

I don't find anything on the OGC version of WMS 1.3 specs. But perhaps I miss them ?

The scale processing depends on the pixel size - see 7.2.4.6.9 Scale denominators. So the scale you see in QGIS is not the scale the WMS considers, when deciding what is to display in the map. A possible fix might be to show the WMS scale somewhere.

I refer to the OGC standard.
Document:
"OpenGIS® Web Map Server Implementation Specification" - Version: 1.3.0 - OGC® 06-042 - 2006-03-15

Page 27:
7.2.4.6.9 Scale denominators
"...
For the purposes of this International Standard, the common pixel size is defined to be 0,28 mm × 0,28 mm. Because arbitrary clients can request maps from a server, the true pixel size of the final rendering device is unknown to the server.
..."

Hi,
I'm a little disappointed that this bug is not taken into account in the new version 2 of QGIS. The severity of this bug is even passed to Normal!
This non-compliance is not blocking for viewing a map, even if the display is very degraded (96 dpi QGIS are "neighbors" of the standard 90.71). However, when printing the estimated QIGS resolution is very different from the standard (300 dpi or more depending on user settings). In this case, the zoom level called for printing doesn't correspond at all to that used in the map window. So, it isn't possible to print what we have on the screen. It's not blocking for QGIS but it is blocking for the human user.
Nevertheless thank you for the improvements of version 2
Regards

Laurent SAEZ wrote:

Hi,
I'm a little disappointed that this bug is not taken into account in the new version 2 of QGIS. The severity of this bug is even passed to Normal!
This non-compliance is not blocking for viewing a map, even if the display is very degraded (96 dpi QGIS are "neighbors" of the standard 90.71). However, when printing the estimated QIGS resolution is very different from the standard (300 dpi or more depending on user settings). In this case, the zoom level called for printing doesn't correspond at all to that used in the map window. So, it isn't possible to print what we have on the screen. It's not blocking for QGIS but it is blocking for the human user.
Nevertheless thank you for the improvements of version 2
Regards

Have you considered funding/sponsoring the resolution of this bug?

I'll talk to my department.
Regards

We usually put as url on an "add wms new lyaer" an url where there is hardcoded a parameter

..&map_resolution=91

When use in the composer it add a its own parameter
map_resolution.

The wms server will use always the last parameter available so the second parameter overlap the our first parameter.

aperi2007 - wrote:

We usually put as url on an "add wms new lyaer" an url where there is hardcoded a parameter

..&map_resolution=91

When use in the composer it add a its own parameter
map_resolution.

The wms server will use always the last parameter available so the second parameter overlap the our first parameter.

This works for UMN mapserver. Other servers might complain about repeated parameters (although that probably doesn't matter here as they'll probably ignore "map_resolution" anyway).

What will happen when the WMS server cascades WMS?
It must add the resolution parameter that it takes into account and also add those known by most popular WMS servers?
I hope that WMS 1.4 will add DPI parameter ;-)

Laurent SAEZ wrote:

What will happen when the WMS server cascades WMS?
It must add the resolution parameter that it takes into account and also add those known by most popular WMS servers?
I hope that WMS 1.4 will add DPI parameter ;-)

Not sure if QGIS server forwards that parameter, but that could be changed. ;)

So what about this ticket? AFAICT it's more an intrinsic problem of WMS with at least three WMS implementations, that try to tackle it and not an actual QGIS problem, right? So this can be closed.

What about WMTS 1.0.0 ?
Tiles are served as they are (pre-)calculated with the layer parameters (with pixel size = 0.28mm to conform to the standard).
Additionnal parameters can't be taken into account... So the tile is distorted and non called at the right scale.
I think the problem exists and it's more a bug than a feedback, isn't it ?

Laurent SAEZ wrote:

I think the problem exists and it's more a bug than a feedback, isn't it ?

"Feedback" means that we want feedback on the matter and can't proceed without further information.

What about WMTS 1.0.0 ?
Tiles are served as they are (pre-)calculated with the layer parameters (with pixel size = 0.28mm to conform to the standard).
Additionnal parameters can't be taken into account... So the tile is distorted and non called at the right scale.

So what is your proposed solution?

There are certainly several solutions.

1. The easiest way would be to change the resolution of a QGIS project (real not just an integer value). Thus, if the user wants to be standards compliant, it can be. It still remains to manage printing for which the resolution is greater than the map window.
2. Keep the current resolution of the map window (96 dpi)
   1. query data with the resolution imposed by the standard, and thus to the real scale on the WMTS server side
   2. resize the image with a factor 96/(25.4/0.28) to match the resolution of QGIS and therefore the current scale of the map window.
      NB : We must construct the WMTS request taking into account the true characteristics of the WMTS layer and then change the answer to fit the characteristics of QGIS.

Currently :
I have a layer (256x256 tiles) with a zoom level 5 at 1/178571 (with a resolution 25.4/0.28, about 90.71 in accordance with WMTS 1.0.0 standard). QGIS displays this data accurately at 1/188976. QGIS magnifies the image with a factor 96/90.71. 256x256 image is actually displayed as 271x271.
This is the same issue to view data from the geoportal of the French state correctly. We have to indicate false scales in QGIS 2.0 project.

Laurent SAEZ wrote:

1. The easiest way would be to change the resolution of a QGIS project (real not just an integer value). Thus, if the user wants to be standards compliant, it can be. It still remains to manage printing for which the resolution is greater than the map window.
2. Keep the current resolution of the map window (96 dpi)

The qgis project doesn't have a resolution. The screen has.

1. query data with the resolution imposed by the standard, and thus to the real scale on the WMTS server side

We query maps with a certain bounding box and a certain extent in pixel (the dpi parameters are not standard - and might not be considered by the server).

1. resize the image with a factor 96/(25.4/0.28) to match the resolution of QGIS and therefore the current scale of the map window.

That's what we do - you just have to set a scale where the displayed image size corresponds to the image size the WMS has assumed based on a pixel size of 0.28mm.
If the screen has the same pixels size the scales will be the same - otherwise different. According to wikipedia 18.1" screens with 1280×1024 have have 280µm pixels - not too common, I suppose.

So essentially it's just wrong to assume that the scale shown in QGIS matches the scale the WMS server used. That's why I said in comment #6430-2 above, just showing the WMS scale would be a way to solve this (ie. make clear that display and WMS scale can be different).

NB : We must construct the WMTS request taking into account the true characteristics of the WMTS layer and then change the answer to fit the characteristics of QGIS.

Right, QGIS chooses the nearest tileset to the current map scale, but ignores the fact that the scales given in WMTS capabilities is not based on the screen's pixel size. Not sure if that's a real problem as that probably only happens between two available scales, where the distortion is probably peaking anyway.

Currently:
I have a layer (256x256 tiles) with a zoom level 5 at 1/178571 (with a resolution 25.4/0.28, about 90.71 in accordance with WMTS 1.0.0 standard). QGIS displays this data accurately at 1/188976. QGIS magnifies the image with a factor 96/90.71. 256x256 image is actually displayed as 271x271.
This is the same issue to view data from the geoportal of the French state correctly. We have to indicate false scales in QGIS 2.0 project.

Scale is the ratio between displayed size and real world size. The pixel size is not directly relevant. If a pixel is 0.28mm wide the tile displays with 71.68mm width on a 1:1 pixel mapping. If that corresponds to scale 1:178571 the tile contains an area of ~12800x12800m (0.28 * 256 / 1000 * 178571). So you have 12800x12800m tiles with 256x256 pixels.

Display one of those tiles at 96dpi with a 1:1 pixel mapping it will only be 67.733mm wide - which means scale 1:188976 (12800/ (25.4/96 * 256 / 1000)). If you want to show it at scale 1:178571 on a 96 dpi display, it still needs to be 71.68mm wide - which as you already noted corresponds to ~271 pixels (71.68/25.4*96).

So the QGIS scale actually corresponds to the scale the map is shown in, which IMHO is correct, while showing the scale WMS assumes wouldn't be.