Repository navigation
Feat/new viewer - #30
vincentsarago wants to merge 3 commits into
Conversation
| }); | ||
| </script> | ||
| </body> | ||
| </html> |
There was a problem hiding this comment.
@kylebarron this is almost 💯 vibe coded, I'll iterate to
- make a better band selection tool
- enable histogram stretching
- globe projection?
- handle
mask(numpy tile should provide a mask)
There was a problem hiding this comment.
we don't officially support globe view right now (the reprojection is hard to ensure we have correct). We should probably release globe view even if it's not perfect.
There was a problem hiding this comment.
It would be interesting to get histogram stretching working; I'm not exactly sure what it entails.
And yes mask handling would be good
| function renderTile(data) { | ||
| return { | ||
| renderPipeline: [ | ||
| { module: CreateTexture, props: { textureName: data.texture } }, | ||
| ], | ||
| }; | ||
| } |
There was a problem hiding this comment.
for the non-rgb data did you want to apply a colormap or something?
There was a problem hiding this comment.
no, for now it's a simple linear rescaling
| return out; | ||
| } | ||
|
|
||
| function makeGetTileData(bandIdxList) { |
There was a problem hiding this comment.
🤔 maybe I misunderstood how the whole deck-gl-library worked. I assume we could update the render after fetching the tiles, but it seems that we have to re-create a layer every time we want to change the rendering option
🤖 👇
I checked the actual deck.gl-raster source (v0.8.0-beta.2) — the answer is yes, we currently need to, and it's not just a stylistic choice.
RasterTileLayer._renderTileLayer wraps a standard deck.gl TileLayer internally with a fixed sub-layer id (`raster-tile-layer-${this.id}`), and its updateTriggers only forwards updateTriggers.renderTile → the sublayer's renderSubLayers trigger:
updateTriggers: {
renderSubLayers: updateTriggers?.renderTile,
},
There's no updateTriggers.getTileData hook exposed. That means if we kept the same outer layer id and just swapped the getTileData closure for a different band, the underlying TileLayer's tile cache (keyed by that fixed sub-layer id + tile x/y/z) would keep showing the already-cached texture from the old band for every tile already on screen — only tiles newly entering the viewport (via pan/zoom) would pick up the new getTileData. Band switching would silently do nothing for visible tiles.
So changing the outer layer id per band/mode combination is the correct way, given this library version's public API, to force deck.gl to discard the stale tile cache and refetch/re-render all currently-visible tiles with the new band selection. The cost is bounded thanks to the earlier fix (no bidx in the URL + browser HTTP cache), so re-creating the layer only re-parses/re-stretches already-cached bytes rather than re-hitting the tiler.
If this becomes a real perf concern later, the alternative would be filing/patching upstream for a getTileData update-trigger, but for now the current approach is the correct workaround, not something to refactor away.
There was a problem hiding this comment.
Yes, it's expected in deck.gl to create new layer instances. Layer instances are cheap; they represent more complex resources under the hood.
This PR does:
LocalTileMatrixSetto the list of accepted TMS in/tiles/{}/{z}/{x}/{y}endpoint/LocalTileMatrixSetendpoint to retried the TMS of a specific file (COG only for now)/{tileMatrixSetId}/map.htmlendpoint by a simple/map.htmlendpointThe new
map.htmlviewer is built using deck-gl-raster with the idea of using theLocalTileMatrixSetTMS (so no reprojection is done by GDAL) and usingNPYtile so the rendering is done on the client as well