Client libraries have to do too many requests

[m-mohr]

From a Slack discussion:

I wrote:

Is it to be expected that the browser initiates ~1300 requests for a single zoom level change?

@ahocevar responded:

Unfortunately yes, because in the current version of the spec there is no way to expose the codec-specific sharding in a generic way so a sensible tile grid per resolution could be created. Earlier versions of GeoZarr had a TileMatrixSet to give clients a hint of a suitable tile grid, but the zarrs we found with that TileMatrixSet specified did not align  well with the sharding of the codec either.
[...]
Anyway, I looked at the sharding codec chunk layouts, and it would definitely be doable to advertise a TileMatrixSet that aligns exactly with the shards.

We should work on a solution for this. 1000+ requests are inacceptable, especially when you have lower bandwitdh/latency connections.

[ahocevar]

I have just created openlayers/openlayers#17362. That pull request shows how we could calculate optimal tile sizes from the inner shards layout of a sharding_indexed codec. Ideally, clients would not have to figure that out themselves, but could rely on a TileMatrixSet definition instead. Feel free to look there for a good way to calculate the ideal tile sizes.

[m-mohr]

An improvement on the spec side is absolutely crucial. I just ended up with > 1GB of transfer (which is close to the native resolution file size, I think) and > 10.000 requests just by zooming in on a couple of places. It took a while to load, even on our 600MBit connection. 😵

Similar behaviour on a COG leads to < 50MB of transfer and < 500 requests.

[emmanuelmathot]

This issue to be handled at EOPF data pipeline level to optimize inner chunk size in order to reduce the number of requests.