Re: [QGIS-Developer] WMTS/XYZ on high DPI screens
On Thu, Feb 28, 2019 at 10:06 AM Matthias Kuhn wrote: > > To specify output device DPI there's already > > QgsRasterDataProvider::setDpi() call which is also used when drawing > > raster layers. > > Hmm... I see the docstring that says output device. How does it work > that the provider can hold the output device DPI, when the same provider > will be used for printing and screen rendering? I was assuming that the > output device DPI will be specified per request / rendering context. Or > maybe I have a different understanding of what output device DPI means? The "trick" is that when rendering rasters, the provider gets copied (equivalent of copying feature sources of vector layers) to make sure we will have a local copy for rendering in background. DPI is set in QgsRasterLayerRenderer before the provider is copied, so for each map render we have the correct DPI stored in local provider copy. I am not saying I like this approach - ideally DPI should be a part of block request - but this already works so probably it's something to address in QGIS 4 API. > > I am not sure how do you mean it with specification of "data source > > DPI" ... if I have a tileset with 96 DPI, do you mean that option > > should allow overriding of the source DPI? > > Yes, at least for all data sources that do not natively support > reporting the real DPI (so for most if I understand you correctly). > > For those sources, 96 is just a guess (even though a quite common and > probable one). > > E.g. it could be interesting to use file based tiled layers with > pyramids holding different levels of generalization rendered for HiDPI > as basemaps which need to be scaled down on screens with 96 DPI. With my PR I believe this should work correctly with XYZ layers: if both source and output DPIs are defined, the "best" tile resolution is adjusted based on their ratio. > > In any case, here's my take on fixing three problems in one go: > > - correct rendering of XYZ tiles on high res screen (and in print output) > > - correct rendering of high resolution XYZ tiles (on any screen) > > https://github.com/qgis/QGIS/pull/9296 > > That looks like a good improvement, isolated to WMS, XYZ providers and > not affecting any public API from what I can see. Thanks. That PR does not affect WMS at all. It only affects XYZ and it prepares ground for WMTS (for it we need a mechanism to set DPI for WMTS tilelesets). Cheers Martin ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] WMTS/XYZ on high DPI screens
Hi On 2/27/19 9:45 PM, Martin Dobias wrote: > On Wed, Feb 27, 2019 at 1:03 PM Matthias Kuhn wrote: >>> I am wondering if we should have three options for tile resolutions: >>> - standard (96 DPI) ... autoscaled, for 256x256 tiles for XYZ tiles >>> - high res (192 DPI) ... autoscaled, for 512x512 tiles for XYZ tiles >>> - undefined ... not scaled >> Sounds reasonable. >> >> I can see the following options for what a data provider can offer: >> >> * A predefined set of available DPI from the server (e.g. XYZ) >> >> * Manually specify DPI (e.g. as WMS parameter "DPI=300") >> >> * No scaling available > Right. > > >> Some dataproviders might know what they can offer (WMS might include >> that in the GetCapabilities, AFS maybe?), others might need >> configuration on layer / data provider properties (XYZ, preconfigured >> through QMS or ,qml/.qlr files). > As mentioned in my earlier email, WMS, WMTS, XYZ have no way to tell > the true DPI of tiles (as far as I know). AMS does but QGIS does not > take it into account. What I wanted to say is mostly that the API should be prepared for that (or at least not prevent it) if possible, so AMS can be improved or an enhanced WMS version can communicate what they offer natively. > >> I assume that it's also not always desired to get the maximum resolution. >> >> E.g. in HighRes atlas printing a WMS via a network connection with >> "DPI=3000" parameter could be very slow, so the API should be prepared >> to specify >> >> * "data source DPI", i.e. what's requested from the provider >> >> * and output device DPI, i.e. what it's scaled to for screen/paper > To specify output device DPI there's already > QgsRasterDataProvider::setDpi() call which is also used when drawing > raster layers. Hmm... I see the docstring that says output device. How does it work that the provider can hold the output device DPI, when the same provider will be used for printing and screen rendering? I was assuming that the output device DPI will be specified per request / rendering context. Or maybe I have a different understanding of what output device DPI means? > I am not sure how do you mean it with specification of "data source > DPI" ... if I have a tileset with 96 DPI, do you mean that option > should allow overriding of the source DPI? Yes, at least for all data sources that do not natively support reporting the real DPI (so for most if I understand you correctly). For those sources, 96 is just a guess (even though a quite common and probable one). E.g. it could be interesting to use file based tiled layers with pyramids holding different levels of generalization rendered for HiDPI as basemaps which need to be scaled down on screens with 96 DPI. > In any case, here's my take on fixing three problems in one go: > - correct rendering of XYZ tiles on high res screen (and in print output) > - correct rendering of high resolution XYZ tiles (on any screen) > https://github.com/qgis/QGIS/pull/9296 That looks like a good improvement, isolated to WMS, XYZ providers and not affecting any public API from what I can see. Cheers Matthias > > The PR does not address scaling issues with WMTS layers. Compared to > XYZ layers where one connection = one tile layer, with WMTS there may > be multiple tile layers within one connection, each with different DPI > - and as mentioned above, WMTS does not provide information about DPI. > > Cheers > Martin ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] WMTS/XYZ on high DPI screens
On Wed, Feb 27, 2019 at 1:03 PM Matthias Kuhn wrote: > > > > I am wondering if we should have three options for tile resolutions: > > - standard (96 DPI) ... autoscaled, for 256x256 tiles for XYZ tiles > > - high res (192 DPI) ... autoscaled, for 512x512 tiles for XYZ tiles > > - undefined ... not scaled > > Sounds reasonable. > > I can see the following options for what a data provider can offer: > > * A predefined set of available DPI from the server (e.g. XYZ) > > * Manually specify DPI (e.g. as WMS parameter "DPI=300") > > * No scaling available Right. > Some dataproviders might know what they can offer (WMS might include > that in the GetCapabilities, AFS maybe?), others might need > configuration on layer / data provider properties (XYZ, preconfigured > through QMS or ,qml/.qlr files). As mentioned in my earlier email, WMS, WMTS, XYZ have no way to tell the true DPI of tiles (as far as I know). AMS does but QGIS does not take it into account. > I assume that it's also not always desired to get the maximum resolution. > > E.g. in HighRes atlas printing a WMS via a network connection with > "DPI=3000" parameter could be very slow, so the API should be prepared > to specify > > * "data source DPI", i.e. what's requested from the provider > > * and output device DPI, i.e. what it's scaled to for screen/paper To specify output device DPI there's already QgsRasterDataProvider::setDpi() call which is also used when drawing raster layers. I am not sure how do you mean it with specification of "data source DPI" ... if I have a tileset with 96 DPI, do you mean that option should allow overriding of the source DPI? In any case, here's my take on fixing three problems in one go: - correct rendering of XYZ tiles on high res screen (and in print output) - correct rendering of high resolution XYZ tiles (on any screen) https://github.com/qgis/QGIS/pull/9296 The PR does not address scaling issues with WMTS layers. Compared to XYZ layers where one connection = one tile layer, with WMTS there may be multiple tile layers within one connection, each with different DPI - and as mentioned above, WMTS does not provide information about DPI. Cheers Martin ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] WMTS/XYZ on high DPI screens
HI Martin On 2/27/19 11:23 AM, Martin Dobias wrote: > Hi Nyall > > On Wed, Feb 27, 2019 at 4:40 AM Nyall Dawson wrote: >> So I'm guessing this setting would apply in print layouts too? >> Regardless of the output resolution, it would be exported as though >> it's at 96 dpi? > Yes, that's correct - print output would be affected too. That means > that tiles from a regular XYZ service would be scaled up. Now this is > something I am not 100% sure about how this should work. On one hand > scaling tiles up is useful with tile layers containing labels (they > will have the same size as on the screen), on the other hand for some > tiles this may not be desired (scaling them up would just reduce their > resolution). > > I am wondering if we should have three options for tile resolutions: > - standard (96 DPI) ... autoscaled, for 256x256 tiles for XYZ tiles > - high res (192 DPI) ... autoscaled, for 512x512 tiles for XYZ tiles > - undefined ... not scaled Sounds reasonable. I can see the following options for what a data provider can offer: * A predefined set of available DPI from the server (e.g. XYZ) * Manually specify DPI (e.g. as WMS parameter "DPI=300") * No scaling available Some dataproviders might know what they can offer (WMS might include that in the GetCapabilities, AFS maybe?), others might need configuration on layer / data provider properties (XYZ, preconfigured through QMS or ,qml/.qlr files). I assume that it's also not always desired to get the maximum resolution. E.g. in HighRes atlas printing a WMS via a network connection with "DPI=3000" parameter could be very slow, so the API should be prepared to specify * "data source DPI", i.e. what's requested from the provider * and output device DPI, i.e. what it's scaled to for screen/paper > This should hopefully handle all the cases. I am not sure though which > option should be the default. For compatibility reasons (not to break > existing behavior of QGIS) probably it would be good to have > "undefined" as the default with no scaling of tiles on screen nor for > print. Only when deliberately switched to standard / high res > resolution we would apply scaling. Yes, that sounds like the safest approach. Matthias ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] WMTS/XYZ on high DPI screens
Hi Richard On Wed, Feb 27, 2019 at 10:47 AM Richard Duivenvoorde wrote: > > not sure if this is helpfull, but Matthijs of the OpenGeoGroep.nl > created a hidpi tilecache for mac users not so long ago for an Dutch, > osm based base map. I asked him what he did. He says (translated): > > "Yes we serve two versions, eg" > > http://www.openbasiskaart.nl/mapcache/wmts/?SERVICE=WMTS=GetTile=1.0.0=osm-nb=default=rd=5=16=15=image%2Fpng > > http://www.openbasiskaart.nl/mapcache/wmts/?SERVICE=WMTS=GetTile=1.0.0=osm-nb-hq=default=rd-hq=5=16=15=image%2Fpng Thanks for this - good to have also a WMTS service for testing. HQ tiles look nice and crisp compared to the standard version :-) > "Only the tileing protocol metadata is not really prepeared for HQ > tiles. I now set it up i a way that for HiDPI tiles you have use the > same TILEMATRIX, TILEROW en TILEROW, but you receive either a 256x256 > tile or a 512x512 tile depending on the TILEMATRIXSET. But you have to > fool the tile server a little, so if you use current URL > (http://www.openbasiskaart.nl/mapcache and layer with HQ in QGIS) you > get big labels." Yeah if I am not wrong that's the limitation of WMTS protocol - it does not tell you the true DPI (you _should_ assume 90 DPI according to the standard). For a WMTS offering mixed bag of tile resolutions I am not sure what would be the best solution - a single DPI setting for the whole connection won't work well - you would need two connections... one for normal-res tiles, the other for high-res tiles. Another solution could be per tileset configuration of true DPI, but that would be even more complicated... Cheers Martin ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] WMTS/XYZ on high DPI screens
Hi Nyall On Wed, Feb 27, 2019 at 4:40 AM Nyall Dawson wrote: > > So I'm guessing this setting would apply in print layouts too? > Regardless of the output resolution, it would be exported as though > it's at 96 dpi? Yes, that's correct - print output would be affected too. That means that tiles from a regular XYZ service would be scaled up. Now this is something I am not 100% sure about how this should work. On one hand scaling tiles up is useful with tile layers containing labels (they will have the same size as on the screen), on the other hand for some tiles this may not be desired (scaling them up would just reduce their resolution). I am wondering if we should have three options for tile resolutions: - standard (96 DPI) ... autoscaled, for 256x256 tiles for XYZ tiles - high res (192 DPI) ... autoscaled, for 512x512 tiles for XYZ tiles - undefined ... not scaled This should hopefully handle all the cases. I am not sure though which option should be the default. For compatibility reasons (not to break existing behavior of QGIS) probably it would be good to have "undefined" as the default with no scaling of tiles on screen nor for print. Only when deliberately switched to standard / high res resolution we would apply scaling. > I have a vague feeling that Sourcepole's albiero fork implemented > something similar to this... some possibly related commits are > > https://github.com/sourcepole/kadas-albireo/commit/09bb1c82f296f736ce8ecc07f03b03fc5861ddd3 > https://github.com/sourcepole/kadas-albireo/commit/09a4cb0bac5fe8a6c2563f811171804044c60d65 Thanks for the pointer to those commits! There seems to be a mix of behaviors with somewhat arbitrary threshold of 225 DPI (I guess assuming screens are < 225 while printing uses > 225). If I read the code correctly, for screens it would not apply any scaling, but for print it would scale tiles up. Not sure why the logic is designed this way... Cheers Martin ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] WMTS/XYZ on high DPI screens
On 26/02/2019 17.23, Martin Dobias wrote: > Hi all > > Whenever I use a background map like OpenStreetMap on my high-res > laptop screen (192 DPI) in QGIS, the labels are tiny. That is > "natural" because tiles are made for screens with ~96 DPI where the > size of labels is just fine. When I look at OSM tiles in the browser, > I can see that the browser displays the tiles scaled ... so even > though the tiles do not look super crisp, at least I do not need a > magnifying glass to read labels. > > A similar problem I have encountered before is when using tiles from > WMTS/XYZ in print/PDF output: with higher resolution of print the > rendering engine picks very detailed tiles which again may contain > very tiny labels. > > I would like to fix this in QGIS but I am wondering what would be the > correct approach. > > One simple (and wrong?) solution would be to just scale tiles of all > tile layers, but I guess if the service displays some raw imagery it > would be wasteful to scale them as this unnecessarily would remove > details which could be still shown on high res display. > > Other solution would be to introduce a new flag for WMTS/XYZ layers > where users could set native DPI. By default this flag would be > disabled, but for services like OSM one could explicitly set their DPI > to 96 and get the tiles scaled accordingly. This would need an update > of raster block request API as well where we would also need to > specify output DPI in addition to output width/height (but that should > not be a big deal). > > 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. > > 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). > > Are there any opinions / ideas how to deal with that? Hi Martin, not sure if this is helpfull, but Matthijs of the OpenGeoGroep.nl created a hidpi tilecache for mac users not so long ago for an Dutch, osm based base map. I asked him what he did. He says (translated): "Yes we serve two versions, eg" http://www.openbasiskaart.nl/mapcache/wmts/?SERVICE=WMTS=GetTile=1.0.0=osm-nb=default=rd=5=16=15=image%2Fpng http://www.openbasiskaart.nl/mapcache/wmts/?SERVICE=WMTS=GetTile=1.0.0=osm-nb-hq=default=rd-hq=5=16=15=image%2Fpng "Only the tileing protocol metadata is not really prepeared for HQ tiles. I now set it up i a way that for HiDPI tiles you have use the same TILEMATRIX, TILEROW en TILEROW, but you receive either a 256x256 tile or a 512x512 tile depending on the TILEMATRIXSET. But you have to fool the tile server a little, so if you use current URL (http://www.openbasiskaart.nl/mapcache and layer with HQ in QGIS) you get big labels." Maybe you can use the service to check/test? (note hq is only in EPSG:28992) Regards, Richard Duivenvoorde ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] WMTS/XYZ on high DPI screens
On Wed, 27 Feb 2019 at 02:24, Martin Dobias wrote:
> Other solution would be to introduce a new flag for WMTS/XYZ layers
> where users could set native DPI. By default this flag would be
> disabled, but for services like OSM one could explicitly set their DPI
> to 96 and get the tiles scaled accordingly. This would need an update
> of raster block request API as well where we would also need to
> specify output DPI in addition to output width/height (but that should
> not be a big deal).
>
So I'm guessing this setting would apply in print layouts too?
Regardless of the output resolution, it would be exported as though
it's at 96 dpi?
I have a vague feeling that Sourcepole's albiero fork implemented
something similar to this... some possibly related commits are
https://github.com/sourcepole/kadas-albireo/commit/09bb1c82f296f736ce8ecc07f03b03fc5861ddd3
https://github.com/sourcepole/kadas-albireo/commit/09a4cb0bac5fe8a6c2563f811171804044c60d65
https://github.com/sourcepole/kadas-albireo/commit/09bb1c82f296f736ce8ecc07f03b03fc5861ddd3
Nyall
> 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.
>
> 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).
>
> Are there any opinions / ideas how to deal with that?
>
> Cheers
> Martin
>
> [1] https://tile.osmand.net/hd/{z}/{x}/{y}.png
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] WMTS/XYZ on high DPI screens
Hi Matthias
Thanks for your thoughts...
On Tue, Feb 26, 2019 at 5:49 PM Matthias Kuhn 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
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] WMTS/XYZ on high DPI screens
Hi Martin
Interesting topic.
On 2/26/19 5:23 PM, Martin Dobias wrote:
> Hi all
>
> Whenever I use a background map like OpenStreetMap on my high-res
> laptop screen (192 DPI) in QGIS, the labels are tiny. That is
> "natural" because tiles are made for screens with ~96 DPI where the
> size of labels is just fine. When I look at OSM tiles in the browser,
> I can see that the browser displays the tiles scaled ... so even
> though the tiles do not look super crisp, at least I do not need a
> magnifying glass to read labels.
>
> A similar problem I have encountered before is when using tiles from
> WMTS/XYZ in print/PDF output: with higher resolution of print the
> rendering engine picks very detailed tiles which again may contain
> very tiny labels.
If I understand you correctly, the scaling that you see on OSM is only
done on client side (in javascript)?
> I would like to fix this in QGIS but I am wondering what would be the
> correct approach.
>
> One simple (and wrong?) solution would be to just scale tiles of all
> tile layers, but I guess if the service displays some raw imagery it
> would be wasteful to scale them as this unnecessarily would remove
> details which could be still shown on high res display.
Agreed!
>
> Other solution would be to introduce a new flag for WMTS/XYZ layers
> where users could set native DPI. By default this flag would be
> disabled, but for services like OSM one could explicitly set their DPI
> to 96 and get the tiles scaled accordingly. This would need an update
> of raster block request API as well where we would also need to
> specify output DPI in addition to output width/height (but that should
> not be a big deal).
>
> 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).
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
Best regards
Matthias
>
> Are there any opinions / ideas how to deal with that?
>
> Cheers
> Martin
>
> [1] https://tile.osmand.net/hd/{z}/{x}/{y}.png
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
--
Matthias Kuhn
matth...@opengis.ch
+41 (0)76 435 67 63
OPENGIS.ch Logo
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] WMTS/XYZ on high DPI screens
Hi all
Whenever I use a background map like OpenStreetMap on my high-res
laptop screen (192 DPI) in QGIS, the labels are tiny. That is
"natural" because tiles are made for screens with ~96 DPI where the
size of labels is just fine. When I look at OSM tiles in the browser,
I can see that the browser displays the tiles scaled ... so even
though the tiles do not look super crisp, at least I do not need a
magnifying glass to read labels.
A similar problem I have encountered before is when using tiles from
WMTS/XYZ in print/PDF output: with higher resolution of print the
rendering engine picks very detailed tiles which again may contain
very tiny labels.
I would like to fix this in QGIS but I am wondering what would be the
correct approach.
One simple (and wrong?) solution would be to just scale tiles of all
tile layers, but I guess if the service displays some raw imagery it
would be wasteful to scale them as this unnecessarily would remove
details which could be still shown on high res display.
Other solution would be to introduce a new flag for WMTS/XYZ layers
where users could set native DPI. By default this flag would be
disabled, but for services like OSM one could explicitly set their DPI
to 96 and get the tiles scaled accordingly. This would need an update
of raster block request API as well where we would also need to
specify output DPI in addition to output width/height (but that should
not be a big deal).
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.
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).
Are there any opinions / ideas how to deal with that?
Cheers
Martin
[1] https://tile.osmand.net/hd/{z}/{x}/{y}.png
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
