Fix data dropping across the antimeridian

[Shane98c]

Closes #53. Closes #64. Closes #58. This supersedes #65 to point to latest main (sorry for letting that get stale @egagli, I added you as co-author to these commits).

When a viewport straddles 180, MapLibre's getBounds() reports unwrapped longitudes (e.g. west=104, east=255 at center 180), and two selection paths dropped data on one side until the user panned across:

• Tiled (Issue rendering legacy tiled pyramids when crossing the antimeridian #53): getTilesAtZoom clamped lon to [-180, 180] when computing tile-X, so tiles past the dateline were never requested. (EPSG:4326's path never clamped: why tasmax worked but the EPSG:3857 pyramids didn't.)
• Untiled (UntiledMode.getVisibleRegions skips regions on one side of the antimeridian when viewport crosses ±180° #64): getVisibleRegions' overlap test wasn't antimeridian-aware, so far-side regions failed the comparison.

map-utils.ts: getTilesAtZoom no longer clamps lon (existing wrappedX fold handles both wrapped and unwrapped bounds; normal views unchanged). New lonRangeOverlaps does an antimeridian-aware overlap that solves for every world-copy offset k·360 (not just ±360), so it's correct for distant renderWorldCopies pans and 0–360 stores.

untiled-mode.ts: getVisibleRegions uses lonRangeOverlaps; getCandidateRegions widens to all X columns when crossing (the overlap check trims it back, so no over-fetch).

Also ports #65's separate worldFraction fix (co-authored @egagli): proj4 bbox corners can project out-of-domain (e.g. MODIS sinusoidal) -> NaN worldFraction -> broken level selection; falls back to the equatorial strip and clamps to <= 1.

This also covers two more antimeridian rendering paths that the selection fix alone didn't:

zarr-layer.ts: sets wrapTileId = true so Mapbox renders draped tiles into wrapped world copies. Under terrain the draped renderToTile path only drew the canonical world, so one side of the dateline stayed blank even with data loaded (depends on the selection fix above to have data on both sides).

mesh-reprojector.ts: culls out-of-domain reprojected vertices and triangles with globe-spanning edges, so source-projected meshes that wrap past 180 (e.g. sinusoidal) no longer draw a flat sheet through the center of the globe on MapLibre / smear across the whole globe on Mapbox.

Strip-chunked stores on the globe (#58)

Some virtual stores chunk the data into thin strips: a single row of latitude (or column of longitude) spanning the whole extent. A region maps to one chunk, so these became full-width, near-flat strips that didn't reproject correctly on the globe (mercator was fine): they smeared north on the globe.

mesh-reprojector.ts / untiled-mode.ts: the reprojected mesh now tessellates each axis independently (a non-square uniform grid via separate lonSubdivisions/latSubdivisions) instead of a single square subdivision count. Each axis gets ceil(span) (~1 vertex/degree), clamped to [MIN_SUBDIVISIONS, MAX_SUBDIVISIONS]. Two concerns:

• Wide axis — enough vertices to bend around the globe and stay under the long-edge cull. A coarse wide strip would otherwise chord through the globe or get culled entirely.
• Thin axis — MIN_SUBDIVISIONS raised 2 → 8 (constants.ts). A single-row strip has a near-zero short span; with only 2 cross-vertices, hard data/nodata edges smeared on the globe (worst on MapLibre globe). The floor guarantees enough cross-vertices regardless of span. Works for row and column chunks alike — whichever axis is thin hits the floor.

This replaces an earlier longitude-only heuristic; the per-axis ceil(span) + floor subsumes it and also removed the dense-subdivision sliver triangles that flickered when overzoomed.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
zarr-layer	Ready	Preview, Comment	Jun 18, 2026 9:14pm