[geo-layers] Fix GlobeView Mercator tile warping

[charlieforward9]

Summary

Fixes GlobeView rendering for WebMercator terrain and imagery tiles. Terrain mesh rows and bitmap UVs now respect WebMercator row spacing instead of treating tile latitude as linear from top to bottom.

Why

XYZ/slippy tiles are encoded in WebMercator space. In GlobeView, deck.gl positions tile geometry in lng/lat space, so using linear latitude rows compresses terrain and imagery toward high latitudes. The distortion is easiest to see at far zooms and pitched globe views.

What Changed

• TerrainLayer: remaps tiled GlobeView mesh row latitude through @math.gl/web-mercator during the private terrain load path.
• TerrainLayer: keeps the remap scoped to tiled GlobeView and copies the position array so loader/cached mesh data is not mutated.
• TileLayer: defaults generated BitmapLayer tile imagery to WebMercator image coordinates in GlobeView while preserving explicit _imageCoordinateSystem overrides.
• Tests cover terrain row remapping, source mesh integrity, default GlobeView bitmap coordinates, and explicit bitmap coordinate preservation.

Validation

• yarn vitest run --project headless test/modules/geo-layers/terrain-layer.spec.ts
• yarn vitest run --project headless test/modules/geo-layers/tile-layer/tile-layer.spec.ts
• Pre-commit hook ran lint/format/node smoke tests during commit; only existing warnings were reported.

Visual Validation

projection-warping.mov

[coveralls]

coverage: 83.181% (+0.02%) from 83.166% — cr/fix-globe-mercator-tiles into master

[chrisgervang]

The fix looks good. Let's consider how to make this generalized for other layers that may need the same correction

[chrisgervang]

What do BitmapLayers and other layers that need this reprojection have in common?

Have you considered the qualities a layer needs be susceptible to warping?

[chrisgervang]

All tile sublayers rendered on a globe trigger the remap. Is it true that only the built-in bitmap layer gets modified by this, or would other sublayers get remapped too?

[charlieforward9]

@copilot resolver los conflictos de combinación en esta rama.

[Copilot]

@copilot resolver los conflictos de combinación en esta rama.

Done — merged origin/master into this branch and resolved the one conflict in terrain-layer.ts. The only changes needed were:

• Remove the duplicate _GlobeViewport bare import (master renamed it to _GlobeViewport as GlobeViewport)
• Remove the duplicate COORDINATE_SYSTEM import our branch had added
• Update import type {Mesh} → import type {MeshAttributes} and propagate that rename through all type aliases, state declarations, and function signatures to match master's loaders.gl upgrade

[charlieforward9]

@copilot CI hurtin

[Copilot]

@copilot CI hurtin

Fixed in the latest commit. The CI failures were TypeScript errors introduced during the merge conflict resolution — I incorrectly replaced Mesh with MeshAttributes without accounting for the difference: MeshAttributes is an index type {[k: string]: MeshAttribute}, so TypeScript resolves mesh.attributes as MeshAttribute (the individual attribute value type, not the nested attributes dict). The terrain loader actually returns {attributes: {POSITION: ..., TEXCOORD_0: ...}, header: {...}} at runtime. Fixed by using (mesh as any).attributes casts in remapTerrainMeshToWebMercatorTile and // @ts-ignore + MeshWithBoundingBox cast in onViewportLoad, following the same pattern master already uses for the header.boundingBox access.