set tile z-index

[hlfan]

set the z-index to the respective zoom level to bring tiles with higher detail in front of lower detail tiles (e.g. the first tile request has failed) to ensure maximum visibility of loaded details

[Zaczero]

I don't think this is a proper fix for the issue. Ideally, unused tiles should be disposed completely because higher zoom does not equal better experience. When zooming out, lower zoom tiles should have priority. So z-index alone is not good enough in my opinion. But I am willing to accept this as a temporary solution.

[hlfan]

Yes, when changing z-indices while transitioning zoom levels a different approach should be used.

But statically, I sometimes have problems with tile load timeouts, so that three tiles load, one doesn't, and the "replacement tile" one zoom level down covers the already loaded higher detail tiles.

This is what the z-indexing is trying to avoid.

I also thought about changing the behaviour for zooming, but since the higher zoom level tiles

• get faded out on zoom-out and
• load gradually on zoom-in

anyway, I would like to see how this mechanism looks first before spending time to make a minimally better system for transitions.

[Zaczero]

Yes, I know what you are talking about. I also have this problem. But in my opinion it's better to fix it instead of doing this z-index workaround.

[hlfan]

And what would be a non-workaround solution?

[Zaczero]

The same as it is right now for non-timeouting tiles. Just dispose the unnecessary ones, instead of hiding them.

[hlfan]

Why should already loaded-in tiles be discarded in favour of lower resolution/detail tiles? Placing the high-res tiles in the front and the low-res tiles in the background seems like doing exactly what's needed.

Let's say in a WMTS, a point geometry that would be rendered until zoom level 11. This fails for all tiles containing that point, which would mean:

1. All tiles not containing that point get loaded.
2. The request for the tile containing the point times out/fails; the corresponding tile one zoom level lower gets requested.
3. Step 2 repeats until the request doesn't fail for the zoom level 10 tile.

There are three ways how this gets handled and displayed:

• current method The large tile covers every tile before it in the DOM, covering all tiles below and those in the same row to the right.
• my proposed solution The large tile gets placed in the background, leaving it only visible where the initial tile containing the point failed to load.
• your proposed solution Since the large tile covers all other loaded tiles, all tiles with a higher zoom level get disposed of "instead of hiding them".

Am I reading this correctly? If yes, do you want the user in this case to trace detailed features off of a zoom level 10 tile? If not, could you describe your proposed solution in more detail?

[Zaczero]

Why should already loaded-in tiles be discarded in favour of lower resolution/detail tiles?

Because higher resolution does not mean better experience. On some layers it's better to use lower resolution images when zooming out because they sometimes change the element sizes. You only think about satellite/orto images. There are also other types of informational layers which behave differently depending on the zoom factor.

[hlfan]

But when I'm zooming out the higher resolution tiles get removed anyway, so these tiles aren't going to be in front of the lower resolution tiles and don't need to be hidden. And the stack-like nature of requested zoom levels would also be nicely reflected by the stacking of the tiles via the z-index.

Also no layer is going to provide information if one pixel of a low zoom tile is blown up to cover most of the screen. (This was also the reason I wrote this quick fix because it makes iD unusable for using tiles of any kind from a WMS server that doesn't respond in specific conditions.)

[Zaczero]

Okay, now I can see the sense of using the z-index. :+1: Thanks!

[hlfan]

So I found an edge case when the overlays are on a lower zoom level, but to find more issues, I can't bodge that manually and d3 needs to make this transition to find out how it looks when transitioning between zoom levels correctly.