[Feat] New `TileLayer` prop for fetching *multiple tiles* at once

[kylebarron]

Target Use Case

Right now the TileLayer only has a single method for getting per-tile data: the getTileData callback.

This is fine, or at least, the best we can do for most tiled data sources, such as MVT from an API, since there's a separate URL per tile.

But for some data sources, such as PMTiles (which stores a pyramid of MVTs in a single range-request addressable resource) and Cloud-Optimized GeoTIFF (which contain a similar pyramid of raster image data), all tile requests are ranges within one specific URL.

As noted by TileLayer.maxRequests, Chrome only allows 6 concurrent requests per domain on HTTP 1.

But, since:

• these data sources are all contained in a single file/URL
• internal tiles are laid out in a predictable layout, such as horizontal rows or a hilbert curve

If we know we're fetching many tiles at once, we can coalesce adjacent HTTP Ranges and reduce the number of requests we're making.

Right now, since getTileData is called independently for every tile, it's very difficult to know from inside getTileData the set of tiles being fetched at a time, and so it's impossible to do this range coalescing.

Proposal

• Update TileLayer with a new user-facing prop getTileDataBatched (open to naming suggestions) that takes in an array of tiles and fetches all of them. This prop should be optional, falling back to calling getTileData if getTileDataBatched doesn't exist
• Update Tileset2D class to call getTileDataBatched. Ref

  deck.gl/modules/geo-layers/src/tileset-2d/tileset-2d.ts

  Line 264 in 32c5d8d

  this._selectedTiles = tileIndices.map(index => this._getTile(index, true));

ref developmentseed/deck.gl-raster#273

[ibgreen]

It's a great idea at least on paper. Have you worked with multi-range / multi-part requests in practice?

My sense was that many CDNs etc ignore these and just return the entire file instead (which would obviously not be good). And not clear to me how to detect that behavior in advance...

Just assessing what confidence we have in actual gains if we were to do this.

Also some practical concerns like any request cancellation logic would now work on entire batches so can't cancel until all requested tiles are out of view etc.

[kylebarron]

Have you worked with multi-range / multi-part requests in practice?

That's not my suggestion; I've never worked with multi-range requests and I think S3 doesn't support it.

What I want to do is:

• tile 1: byte range 10-40
• tile 2: byte range 40-70
• tile 3: byte range 70-100

Right now, all tile requests are made independently, so we're making 3 requests even though the ranges are adjacent.

With the new API, the client would be able to make 1 request for byte range 10-100, and then split up the response returned to each byte range.

Just assessing what confidence we have in actual gains if we were to do this.

For an example like https://developmentseed.org/deck.gl-raster/examples/land-cover/, the initial load when zoomed out shows 20 individual tiles (you can see the tile boundaries in this case by clicking "show debug overlay" and then bringing "debug opacity" down to 0. Those red squares are the tiles of the COG.)

But with the layout of the COG, all 20 tiles are adjacent to each other on disk. So instead of making 20 requests, we'd make 1 request for the full byte range. (This would have pros/cons; it might be slower to start displaying something but much faster to display everything)

More generally, when not at the base zoom of a COG, each row is adjacent on disk. So if there are 5 columns and 4 rows of tiles on screen, then we'd be making 4 requests instead of 20 requests.

Since we expect to often be fetching directly from S3, since S3 only supports HTTP 1.1, and since chrome throttles to 6 concurrent requests on HTTP 1, I think doing this range coalescing could be significantly helpful for use cases like mine. (The same logic would apply for loading from PMTiles).

Also some practical concerns like any request cancellation logic would now work on entire batches so can't cancel until all requested tiles are out of view etc.

That's true. I hadn't thought of request cancellation. This would have to be opt-in and we'd have to document to developers the pros/cons of using batched tile requests instead of per-tile requests.