Bug report #6430

QGIS doesn't conform to WMS 1.3.0 resolution spec

Added by Laurent SAEZ almost 8 years ago. Updated almost 7 years ago.

Status:Closed
Priority:Normal
Assignee:-
Category:Web Services clients/WMS
Affected QGIS version:master Regression?:No
Operating System:Windows Easy fix?:No
Pull Request or Patch supplied:No Resolution:worksforme
Crashes QGIS or corrupts data:No Copied to github as #:15674

Description

The standard WMS 1.3.0 specifies the pixel width : 0.28 mm. That value gives a resolution of 25.4/0.28 = 90.71 dpi approximately.
QGIS 1.8 works with a resolution of 96 dpi.
It does not take into account the wms 1.3.0 resolution when it requests WMS 1.3.0 layers.

example:
I work with QGIS which displays the map at 1/10523.
I open a WMS 1.3.0 which is visible from 1/120000 to 1/10000.

QGIS generates the following query:
http://myserver/mapserv?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&BBOX=867728.656028,6249213.922059,871403.943972,6252134.662250&CRS=EPSG:2154&WIDTH=1320&HEIGHT=1049&LAYERS=scan25&STYLES=&FORMAT=image/jpeg&DPI=96

We can already see the DPI=96 which is outside the standard. It can be understood by some WMS servers which extend the standard, but nothing says that this information will be taken into account.

With this request the WMS 1.3.0 server will interpret the following scale:
scale = 1 / ((871403,943972-867728,656028) * (90.71 / (1320 * 0.0254)))
scale = 1/9944 (approximately)

The server will then rightly believe that the layer is requested outside the range of exposure and returns a blank image!

If QGIS reflected the good resolution of the standard, the width will be :
ImageWidth = ((1/10523) * (871403.943972-867728.656028) * 90.71) / 0.0254
ImageWidth = 1247 (approx)

If an image is returned from the server it is still a problem of scale by a factor 96/90.71!

In conclusion, QGIS, with a map at scale X, superimposed local layers at the right scale X with WMS 1.3.0 layers at scale Y!

The standard WMTS 1.0.0 also requires the pixel size to 0.28 mm. It would be nice if QGIS will take into account the right resolution on this standard.

Regard
(I apologize for my very bad English)


Related issues

Related to QGIS Application - Bug report #9222: WMTS being interpolated at native scale Closed 2013-12-17

History

#1 Updated by aperi2007 - almost 8 years ago

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 ?

#2 Updated by Jürgen Fischer almost 8 years ago

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.

#3 Updated by Laurent SAEZ almost 8 years ago

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.
..."

#4 Updated by Giovanni Manghi over 7 years ago

  • Priority changed from High to Normal

#5 Updated by Laurent SAEZ almost 7 years ago

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

#6 Updated by Giovanni Manghi almost 7 years ago

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?

#7 Updated by Laurent SAEZ almost 7 years ago

I'll talk to my department.
Regards

#8 Updated by Jürgen Fischer almost 7 years ago

  • Subject changed from QGIS 1.8 isn't conform with WMS 1.3.0 resolution to QGIS doesn't conform to WMS 1.3.0 resolution spec

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!

What is the actual problem?  The WMS should calculate the scale by using the pixel extents of the requested map and it's bounding box (based on the standard pixel size) - and decide on what to display on the result.  QGIS doesn't have a hand in this.

The DPI parameter is non-standard and QGIS server specific and makes it base it's calculations on actual pixel size of the intended output device.  BTW QGIS now also supports MAP_RESOLUTION for UMN mapserver and FORMAT_OPTIONS for geoserver.

#9 Updated by aperi2007 - almost 7 years ago

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.

#10 Updated by Jürgen Fischer almost 7 years ago

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).

#11 Updated by Jürgen Fischer almost 7 years ago

  • Status changed from Open to Feedback

#12 Updated by Laurent SAEZ almost 7 years ago

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 ;-)

#13 Updated by Jürgen Fischer almost 7 years ago

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.

#14 Updated by Laurent SAEZ almost 7 years ago

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 ?

#15 Updated by Jürgen Fischer almost 7 years ago

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?

#16 Updated by Laurent SAEZ almost 7 years ago

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.

#17 Updated by Jürgen Fischer almost 7 years ago

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.

#18 Updated by Jürgen Fischer almost 7 years ago

  • Status changed from Feedback to Closed
  • Resolution set to worksforme

closing for the lack of feedback.

Also available in: Atom PDF