[QGIS-Developer] WMTS/XYZ on high DPI screens

[Martin Dobias]

Hi Matthias

Thanks for your thoughts...

On Tue, Feb 26, 2019 at 5:49 PM Matthias Kuhn <matthias at opengis.ch> wrote:

> If I understand you correctly, the scaling that you see on OSM is only
> done on client side (in javascript)?
>
Yes this is handled by the client map library. In Javascript there's
window.devicePixelRatio property that gives you ratio between physical
pixels and CSS pixels (i.e. 1 for 96 dpi, 2 for 192 dpi). And if you have
high dpi tiles, then e.g. in OpenLayers you can set WMTS layer's
option tilePixelRatio to 2:
https://openlayers.org/en/latest/examples/wmts-hidpi.html


> This solution could also work nicely with services that provide
> high-res tiles (using 512x512 for each tile instead of 256x256) -
> right now QGIS thinks they are 256x256 so instead of a magnifying
> glass one needs a microscope - you can try it [1]. Setting explicitly
> DPI of high-res tiles to 192 DPI should also fix also that issue.
>
> That sounds like a promising path.
>
> Alternatively, I was wondering if this could be done on layer/renderer
> level instead of provider level, with no provider changes involved, as a
> "magnification factor" on the layer. The advantage would be that it could
> be applied to any raster format (WMS or even local tif files generated
> using the "Convert map to raster" processing algorithm).
>
I was playing with this idea of magnification too. But with plain
magnification the problem is that the projects would not be portable - if I
have high-res screen and give my project to someone else with low-res
screen, the magnification factor would make tiles too large for them. So
rather than magnification factor it would need to be again something more
like reference DPI for a layer.

And I still think we need to have the DPI information in raster providers
so that they can pick the correct resolution. For example with a WMS layer
I would prefer if WMS server gives me the image for 192 DPI rather than it
would request it for 96 DPI and then just scale it - and for this to be
possible I think the DPI information needs to be propagated with raster
block requests into providers.


> Just an idea, I didn't look into if/how this is doable code-wise.
>
> My only worry is if this setting is not going to be too difficult to
> use for ordinary users... But maybe a combo box would make the choice
> easier: "Normal resolution (96 DPI)" / "High resolution (192 DPI)" /
> "Custom resolution" (with a spin box).
>
> I wouldn't worry too much about that and rather have a clean and powerful
> API.
>
> - anything can be hidden in an advanced box in the beginning
>
> - Configuring those is advanced magic anyway, QMS and whatever comes along
> to ease the configuration can ship those parameters pre-filled so the user
> does not need to care about it
>
Yeah prepared configs from QMS can indeed make things easier.

The current state of varying DPI support in common protocols seems to be
quite poor:
- WMS 1.3 / WMTS 1.0 protocols simply assume that pixel size is 0.28
millimeters wide (that is ~90 DPI)
- there are custom extensions to WMS protocol to pass DPI to it (MapServer,
GeoServer, QGIS server all use different syntax)
- XYZ has no standardization either. I think some people use convention
http://example/layer/z/x/y.png for normal tiles and
http://example/layer@2x/z/x/y.png for high-dpi tiles (device pixel ratio
2), but this is far from being standard
- ArcGIS REST map service seems to report DPI for tilesets ("tileInfo" ->
"dpi")

In terms of support in QGIS API and implementation:
- QgsRasterDataProvider has setDpi() method which is used in raster layer
rendering. This approach is quite coarse as it sets DPI for the whole data
provider, while the DPI should be ideally set per raster block request
- the value from setDpi() is only used by WMS provider
- DPI information reported by ArcGIS REST service is not used in QGIS

Cheers
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20190226/a5359a09/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 6671 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20190226/a5359a09/attachment.png>