Wms and viewport dynamic generated tiles.

[Allroads]

Is it possible to make dynamically generated tiles visible based on the viewport?

Now, every tile has it own visualisation. The gives a tile block effect.

Not very suitable for lidar data.

​The problem is mentioned in the community, with some images.

Used url with coloramp renderingRule=

https://ahn.arcgisonline.nl/arcgis/rest/services/AHNviewer/AHN4_DTM_50cm/ImageServer/exportImage?f=image&renderingRule=%7B%22rasterFunction%22:%22Color%20Ramp%20D%22%7D&bboxSR=3857&imageSR=3857&format=jpgpng&bbox=395179.4362344,6684876.7457084,395332.3102909,6685029.6197649&size=512,512

Is it possible to do it else?

[taylor.smock]

Not at this time.

Right now, all sources are assumed to be tileable, and it looks like it is going to be a major bit of work to support dynamically styled tiles.

Even if we were to make a request for the current viewport, we currently store the retrieved tiles in order to lessen the load on public servers. This would be contradicted by what is desired here; always getting the viewport from the server.

In order to support this specific usecase, we'd probably want to do the following:

• Add a switch to the maps xml definition for WMS
• If that switch is enabled, ask for an image that covers all visible tiles + 1 row in each direction, and cache that response. So on a 4096x2160 display would (worst case) ask for a 5120x3072 image. We'd have to do some stuff so that we use that image until we are reaching or almost reaching the bounds, but that is a coding problem.
• We'd want to do something to avoid sudden changes of the background image.

[Allroads]

Thanks for the explanation.

Mostly we use these layers zoomed in, for example set the MTB path under the leaves.
I have no idea, what is the best ?x? display.
I assume with a smaller display, you get dynamically better detail.

[taylor.smock]

I assume that the ?x? display is for the WMS url. Just use {width},{height} as seen below.

https://ahn.arcgisonline.nl/arcgis/rest/services/AHNviewer/AHN4_DTM_50cm/ImageServer/exportImage?f=image&renderingRule=%7B%22rasterFunction%22:%22Color%20Ramp%20D%22%7D&bboxSR={wkid}&imageSR={wkid}format=jpgpng&bbox={bbox}&size={width},{height}

As a workaround for the tiling problem, a non-perfect method would be to use wiki:Help/Preferences/Imagery#WmsSettings to set the tile size to something larger than the default 512px. For a 1080p monitor, 1028 should be enough. You should prefer a power of two for that. So 512 -> 1024 -> 2048 -> 4096. It looks like we max out at 4096, so keep that in mind. Based off of my testing, it appears that the server may timeout for 2048px and larger, so you may have to play around with the numbers a bit.

[Allroads]

Here I tried, ​this.

Only for one layer, not knowing if this could work.

&size={1024},{1024}

https://ahn.arcgisonline.nl/arcgis/rest/services/AHNviewer/AHN4_DTM_50cm/ImageServer/exportImage?f=image&renderingRule=%7B%22rasterFunction%22:%22Color%20Ramp%20D%22%7D&bboxSR={wkid}&imageSR={wkid}format=jpgpng&bbox={bbox}&size={1024},{1024}

[Allroads]

Also we use this layer in a ​.jos file, as a startup file for JOSM, with the best Netherlands layers.

[taylor.smock]

If you really want to do the &size= thing, it would be &size=1024,1024 (no {}).

But I don't think it is going to do what you want it to do. That will just increase the number of pixels in the tile, which should already be appropriately sized for the screen.

[Allroads]

Your correct, tried it, 1024 -> 2048 , this is not what I want.