fix: scale geostationary scan angles (rad) to PROJ metres before inverse projection

[Copilot]

CF-convention geostationary datasets (Himawari-8 AHI, GOES-R ABI) store x_geostationary/y_geostationary as scan angles in radians (units = "rad", e.g. ±0.15 rad). The existing invGeostatPoint formula treats these as PROJ geos metres, dividing by Earth's semi-major axis (~6.4 M m). This maps every coordinate to essentially 0, placing the entire dataset at the sub-satellite nadir — so the globe renders nothing.

Fix

In loadGeostatCoords (zarrUtils.ts), after fetching the coordinate arrays, check their units attribute. When it starts with "rad", scale in-place by satelliteOrbitalRadius = perspective_point_height + semi_major_axis (~42.2 M m) before passing to invGeostatPoint:

const satelliteOrbitalRadius = params.h + params.a;
if (xUnitsRad) {
  for (let i = 0; i < xRaw.length; i++) xRaw[i] *= satelliteOrbitalRadius;
}

Coordinates already in metres (no units = "rad") are passed through unchanged.

Notes

• The "spin, spin" symptom on the 1 km Himawari-8 dataset is the actual data-chunk download time (121 M pixels), not a code hang — the globe will now render correctly once the download completes.
• The suggested nsrdb_india.icechunk URL returns 404; the available dataset in that bucket is nsrdb_himawari7.icechunk, which is also geostationary and should benefit from this fix.

[eeholmes]

@copilot The globe does not update. spin, spin, spin . the vars load and the 'Data loading...' pop up appears and then spin, spin.

The dataset is very large chunks. Try this smaller dataset. I think it has the same issue but here it says it cannot load the data at all
https://data.source.coop/bkr/nsrdb/nsrdb_india.icechunk

[Copilot]

@copilot The globe does not update. spin, spin, spin . the vars load and the 'Data loading...' pop up appears and then spin, spin.

The dataset is very large chunks. Try this smaller dataset. I thin...

Found and fixed the root cause! The bug was a coordinate units mismatch:

Root cause: CF-convention geostationary datasets (Himawari-8 AHI and others) store x_geostationary / y_geostationary as scan angles in radians (e.g. ±0.15 rad covering the full disk). The inverse projection formula (invGeostatPoint) expected PROJ geos coordinates in metres. Because radians are ~42 million times smaller than the equivalent metres value, all grid points mapped to essentially the same location near the sub-satellite nadir — so the globe rendered an invisible dot instead of the full disk.

Fix: In loadGeostatCoords, the code now checks the units attribute of the x/y coordinate arrays. When units start with "rad", each value is scaled by satelliteOrbitalRadius = perspective_point_height + semi_major_axis to convert scan angles to PROJ metres before the inverse projection runs.

---

Re: nsrdb_india.icechunk — that URL returns 404 from S3; the dataset doesn't exist at that path. The available dataset in that bucket is https://data.source.coop/bkr/nsrdb/nsrdb_himawari7.icechunk (NSRDB data derived from Himawari-7), which should work with this fix since it's also a geostationary dataset.

---

Re: "spin spin" on the 1km Himawari-8 dataset — the loading spinner is expected to take a while for very large chunks (a 1km full-disk image is ~121M pixels). The spinner will stop once the download completes. The fix above means the globe will now actually render correctly once the data arrives. If the download is stalling (not just slow), that would be a separate network/chunk-size issue.