Skip to content

Fix icesat2_vertical_datum config being silently ignored by globato - #35

Merged
mmacferrin merged 1 commit into
mainfrom
fix/globato-vertical-datum-lookup
Jul 17, 2026
Merged

Fix icesat2_vertical_datum config being silently ignored by globato#35
mmacferrin merged 1 commit into
mainfrom
fix/globato-vertical-datum-lookup

Conversation

@mmacferrin

Copy link
Copy Markdown
Collaborator

Summary

  • _process_h5_to_nc() passed an EPSG code string ("EPSG:4979"/"EPSG:3855") as globato.read()'s vertical_datum kwarg.
  • globato's ICESat2Reader only recognizes the literal strings "ellipsoid", "ellipsoid-mean-tide", "geoid", "geoid-mean-tide", and silently falls back to "ellipsoid" for anything else instead of raising.
  • Net effect: IVERT's icesat2_vertical_datum config setting had no effect on the heights globato actually produced — you always got ellipsoid heights back, regardless of what was configured, while the database/granule metadata could still claim EPSG:3855 (geoid) if that's what was requested.

Found while tracking down a separate bug (continuous-dems/globato#127) where bathy_floor photon heights came out geoid-referenced regardless of requested datum — that turned out to be a different bug inside globato itself, but investigating it surfaced this one in IVERT's own call site.

Fix

  • Added _EPSG_TO_GLOBATO_VERTICAL_DATUM, an explicit lookup from IVERT's EPSG-code representation to globato's accepted literal strings.
  • Added _vertical_epsg_to_globato_datum(), which does the lookup and raises ValueError if the EPSG code has no known mapping, or if the mapped literal isn't one globato's reader currently accepts (checked against _GLOBATO_ACCEPTED_VERTICAL_DATUMS, kept separate so a future change to globato's vocabulary is caught explicitly instead of silently mis-mapping again).
  • _process_h5_to_nc() now calls this at the globato.read() call site instead of passing the EPSG string straight through. The EPSG-code representation is unchanged everywhere else (config validation, database/granule metadata storage).

_process_h5_to_nc() was passing an EPSG code string (e.g. "EPSG:4979")
as globato.read()'s vertical_datum kwarg. globato's ICESat2Reader only
recognizes the literal strings "ellipsoid", "ellipsoid-mean-tide",
"geoid", "geoid-mean-tide", and silently falls back to "ellipsoid" for
anything else -- so IVERT's icesat2_vertical_datum config setting had
no effect on the heights globato actually produced, regardless of
whether "ellipsoid" or "geoid" was configured.

Add an explicit EPSG-to-globato-literal lookup and use it at the
globato.read() call site, with a ValueError if the EPSG code has no
known mapping, or if the mapped literal isn't one globato's reader
currently accepts (guards against the lookup silently going stale if
globato's vocabulary changes upstream).
@mmacferrin

Copy link
Copy Markdown
Collaborator Author

Codacy dependency will be removed. Passed all other checks.

@mmacferrin
mmacferrin merged commit 217d028 into main Jul 17, 2026
3 of 4 checks passed
@mmacferrin
mmacferrin deleted the fix/globato-vertical-datum-lookup branch July 17, 2026 00:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant