<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Matthias</div><div dir="ltr"><br></div><div>Thanks for your thoughts...</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 26, 2019 at 5:49 PM Matthias Kuhn <<a href="mailto:matthias@opengis.ch">matthias@opengis.ch</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p>If I understand you correctly, the scaling that you see on OSM is
only done on client side (in javascript)?<br></p></div></blockquote><div>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:</div><div><a href="https://openlayers.org/en/latest/examples/wmts-hidpi.html">https://openlayers.org/en/latest/examples/wmts-hidpi.html</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><blockquote type="cite"><pre class="gmail-m_1411659305677916158moz-quote-pre">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.</pre>
</blockquote>
That sounds like a promising path.
<p>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).<br></p></div></blockquote><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><p>
</p>
<p>Just an idea, I didn't look into if/how this is doable code-wise.<br>
</p>
<blockquote type="cite">
<pre class="gmail-m_1411659305677916158moz-quote-pre">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).</pre>
</blockquote>
<p>I wouldn't worry too much about that and rather have a clean and
powerful API.<br>
</p>
<p>- anything can be hidden in an advanced box in the beginning</p>
<p>- 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</p></div></blockquote><div>Yeah prepared configs from QMS can indeed make things easier.</div><div><br></div><div>The current state of varying DPI support in common protocols seems to be quite poor:</div><div>- WMS 1.3 / WMTS 1.0 protocols simply assume that pixel size is 0.28 millimeters wide (that is ~90 DPI)</div><div>- there are custom extensions to WMS protocol to pass DPI to it (MapServer, GeoServer, QGIS server all use different syntax)</div><div>- XYZ has no standardization either. I think some people use convention <a href="http://example/layer/z/x/y.png">http://example/layer/z/x/y.png</a> for normal tiles and <a href="http://example/layer@2x/z/x/y.png">http://example/layer@2x/z/x/y.png</a> for high-dpi tiles (device pixel ratio 2), but this is far from being standard</div><div>- ArcGIS REST map service seems to report DPI for tilesets ("tileInfo" -> "dpi")</div><div><br></div><div>In terms of support in QGIS API and implementation:</div><div>- 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</div><div>- the value from setDpi() is only used by WMS provider</div><div>- DPI information reported by ArcGIS REST service is not used in QGIS</div><div><br></div><div>Cheers</div><div>Martin</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><div class="gmail-m_1411659305677916158moz-signature"><div class="gmail-m_1411659305677916158moz-signature"><div class="gmail-m_1411659305677916158moz-signature">
</div>
</div>
</div>
</div>
</blockquote></div></div></div></div></div></div>