Skip to content

Resolve vertical datums through transformez and pass tidal datums as its IDs - #132

Merged
mmacferrin merged 2 commits into
mainfrom
fix/vdatum-lookup
Sep 30, 2026
Merged

mmacferrin merged 2 commits into
mainfrom
fix/vdatum-lookup

Conversation

@mmacferrin

@mmacferrin mmacferrin commented Sep 30, 2026 •

Copy link
Copy Markdown
Collaborator

ivert.vdatum_lookup built its name table from transformez.definitions.Datums, which transformez 1.0 removed. The ImportError was caught silently, so every current install has run on IVERT's short built-in table alone, and some of its codes were wrong:

Name Mapped to Problem
mlw EPSG 1091 A vertical datum code, not a CRS; transformez rejects it
mhw EPSG 5868 transformez has no operation registered for it
mtl EPSG 5713 CGVD28 height (Canada), not Mean Tide Level
lwd_igld85 EPSG 9000 ITRF2014, a geographic CRS

-V mlw and -V mhw failed partway through a validation.

This PR:

  • Passes tidal datums to transformez as its own IDs. mllw, mlw, msl, mhw and mhhw resolve to vdatum:mllw etc., leaving transformez to decide how each surface is applied. Geoid and ellipsoid names still resolve to EPSG codes.
  • Checks every datum against transformez before a run starts. -V accepts a name, an EPSG code or a transformez ID, and stops at once, with transformez's reason, on one it cannot transform.
  • Drops names transformez 1.0 cannot transform: ngvd29, igld85, mtl, lwd_igld85 and navd88 height (usft). transformez's VDatum support does list the MTL and DTL surfaces but has no reference to reach them through yet; a comment in vdatum_lookup.py says to add mtl and dtl once it does.
  • Carries a transformez ID through validation. dem_geom.split_srs_string() splits a compound CRS whose vertical part pyproj cannot read (EPSG:4326+vdatum:mllw); transform_points(), validate_dem and plot_photon_clouds_v2.py use it. validate_dem()'s dem_vertical_datum now resolves names itself.
  • Rewrites vdatum_lookup's API: resolve_vdatum(), plus new check_vdatum(), describe_vdatum() and list_vdatums(), which ivert validate --list-vdatums now uses. The descriptions come from transformez.

Datums that worked before give the same results. Comparing main against this branch:

  • Transforming 500 points near Chesapeake Bay to navd88, mllw, msl and mhhw gives identical heights.
  • ivert validate on a CRM Vol 6 tile with -V navd88 and with -V mllw gives identical results files and summary statistics.

The only difference is the manifest, which records vdatum:mllw where it recorded EPSG:5866.

CHANGELOG entries under Fixed and Changed, including a Breaking entry for the dropped names.


🔍 Docs preview: https://ivert--132.org.readthedocs.build/en/132/

…its IDs

vdatum_lookup read its name table from transformez.definitions, which
transformez 1.0 removed, so it had silently fallen back to a built-in table
with wrong codes: mlw and mhw failed partway through a validation, and mtl
and lwd_igld85 pointed at unrelated CRSs. Tidal names now go to transformez
as vdatum:mllw etc., every datum is checked against transformez before a run
starts, and names transformez cannot transform are dropped. transform_points
and validate_dem carry a transformez ID as the vertical part of a compound
CRS. Results for datums that worked before are unchanged.
@mmacferrin
mmacferrin merged commit 47e2f51 into main Sep 30, 2026
4 checks passed
@mmacferrin
mmacferrin deleted the fix/vdatum-lookup branch September 30, 2026 19:23
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