Skip to content

Fix a couple of issues that deal with the RAiDER bias compared to GNSS - #805

Draft
jlmaurer wants to merge 20 commits into
dbekaert:devfrom
jlmaurer:small_fixes
Draft

Fix a couple of issues that deal with the RAiDER bias compared to GNSS#805
jlmaurer wants to merge 20 commits into
dbekaert:devfrom
jlmaurer:small_fixes

Conversation

@jlmaurer

@jlmaurer jlmaurer commented Jul 9, 2026

Copy link
Copy Markdown
Collaborator

This PR came about through comparing RAiDER-derived ZTD to GNSS ZTD and tracking down the source of the differences with the help of Claude Fable.

NOTE: This PR builds on #802; that PR should be integrated before this one.

Description

There were two funadmental changes needed, one of which was already in place but was not being called.

  1. RAiDER was using trapz integration, which introduces a systematic bias when the function is convex or concave. In the case of pressure-level data with only ~27 levels, the bias is especially high (~2 cm). The fix was to directly use the fact that the hydrostatic delay is exponential in shape and use the the log-mean rule, ∫N dz = Δz·(N₀−N₁)/ln(N₀/N₁)), which is exact for N(z) = N₀e^(−z/H).
  2. GNSS station heights are ellipsoidal heights, but the RAiDER calculation is done on geoidal heights. The conversion to geoid heights is built in to llreader.py in Use memory efficiently, GNSS geometric heights #795 , but it was never called. This PR adds the needed infrastructure so that a user can specify a CRS for the GNSS station heights, and those will get converted to geoid heights.

Motivation and Context

These two issues together all but eliminate the bias between GNSS and RAiDER ZTD estimates.

How Has This Been Tested?

Unit tests pass locally

The unit test for getZTD broke because it used a linear function to test. This PR changes the linear function to an exponential, since the new functionality assumes exponential decrease in hydrostatic delay with elevation.

Screenshots (if appropriate):

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

  • I have added an explanation of what your changes do and why you'd like us to include them.
  • I have written new tests for your core changes, as applicable.
  • I have successfully ran tests with your changes locally.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have added docstrings to the code to document these changes.

@jlmaurer

jlmaurer commented Aug 3, 2026

Copy link
Copy Markdown
Collaborator Author

Changing this to draft until I verify the integration method.

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