[geo-layers] Split TerrainLayer mesh and texture max zooms

[charlieforward9]

Summary

Adds separate TerrainLayer controls for terrain mesh zoom and imagery texture zoom.

meshMaxZoom controls the TileLayer mesh zoom. textureMaxZoom controls the imagery zoom, and if unset it falls back to the existing maxZoom prop. There is no separate texture zoom delta prop.

Validation

• npx vitest run --project headless test/modules/geo-layers/terrain-layer.spec.ts

Stacked on #10293.

[coveralls]

Coverage is 83.593% — NEW-HEAT:codex/terrain-texture-max-zoom into visgl:codex/terrain-globe-mercator-remap. No base build found for visgl:codex/terrain-globe-mercator-remap.

[felixpalmer]

Can you justify why this change is needed? It seems a lot of extra complexity and I'm not sure what issue it is solving

[charlieforward9]

cc @felixpalmer, quick field note from trying this in NEW HEAT.

What we need is TerrainLayer using the highest available elevation mesh zoom, while still resolving imagery textures to the imagery provider ceiling. In our current setup that is roughly z15 for elevation and often z21-z23 for satellite imagery.

What we tried was meshMaxZoom: 15 with textureMaxZoom: 21/23. That works conceptually, but direct stitching becomes pathological when the texture zoom is much higher than the mesh zoom: z15 -> z23 requires 65,536 texture child tiles for a single terrain mesh tile. Pitching/dragging then creates huge request bursts and can freeze the app.

Adding a stitch cap makes the layer safe again, but it means the texture never reaches the top imagery resolution. Moving imagery into a separate draped raster layer avoids the request explosion, but then quality depends on the terrain-cover render target and looks under-resolved during interaction.

So the ask is: is there a TerrainLayer-native path where mesh and texture zoom can diverge substantially, without stitching every high-zoom child into one mesh texture and without losing interactive texture fidelity?

[felixpalmer]

Could you use a standard TileLayer with the TerrainExtension providing the 3D?

[charlieforward9]

TileLayer with the TerrainExtension

the draped imagery goes through the TerrainCover render target, and during interaction it looks visibly pixelated / under-resolved compared with directly sampled z21-z23 imagery