feat: introduce per-constellation data supertypes#71
Merged
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #71 +/- ##
==========================================
- Coverage 98.15% 98.14% -0.01%
==========================================
Files 14 14
Lines 1517 1513 -4
==========================================
- Hits 1489 1485 -4
Misses 28 28 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Add AbstractGPSData and AbstractGalileoData as intermediate abstract supertypes between AbstractGNSSData and the concrete per-signal data types. Constellation membership is now encoded at each struct definition site (the `<: Abstract*Data` line written anyway), so a new signal inherits the shared behaviour with nothing to remember. is_ephemeris_decoded and is_clock_correction_decoded were byte-identical for Galileo I/NAV (E1B) and F/NAV (E5a) — the same orbital and clock fields must be present — so they are a per-constellation fact. They now dispatch once on AbstractGalileoData (in galileo/galileo.jl) instead of once per signal (4 methods -> 2). Genuinely per-signal checks (is_health_status_decoded, is_decoding_completed_for_positioning, is_sat_healthy) stay on the concrete types. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
giove-a
force-pushed
the
sc/gnss-supertype
branch
from
July 5, 2026 09:55
4a3c746 to
83ee266
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Introduces per-constellation abstract supertypes for decoder data types, mirroring the equivalent refactor in
GNSSSignals.jl. This lets Galileo I/NAV (E1B) and F/NAV (E5a) share their identical ephemeris/clock completeness checks via subtype dispatch instead of duplicated per-signal copies.Two new abstract types sit between
AbstractGNSSDataand the concrete per-signal data types:AbstractGPSData <: AbstractGNSSData—GPSL1CAData,GPSL1C_DData,GPSCNAVDataAbstractGalileoData <: AbstractGNSSData—GalileoE1BData,GalileoE5aDataConstellation membership is now encoded at each struct's definition site (the
<: Abstract*Dataline written anyway), so a new signal inherits the shared behaviour with nothing to remember.What collapsed
is_ephemeris_decodedandis_clock_correction_decodedwere byte-identical for E1B and E5a — the two signals carry the same orbital (t_0e, M_0, e, sqrt_A, …, C_is) and clock (t_0c, a_f0, a_f1, a_f2) field sets. They now dispatch once onAbstractGalileoData(insrc/galileo/galileo.jl) instead of once per signal — 4 methods → 2.Genuinely per-signal checks stay on the concrete types:
is_health_status_decoded(E1B carries E1-B/E5b health, E5a only E5a),is_decoding_completed_for_positioning, andis_sat_healthy.Why GPS didn't collapse equally
The GPS supertype is added for symmetry and future-proofing (a home for any GPS-wide fact that surfaces later), but there is no current GPS duplication to remove:
GPSCNAVDatatype — reuse is at 100%, nothing to collapse.Performance
No runtime or allocation impact. The change is dispatch-only: struct layouts are unchanged, abstract supertypes are a compile-time construct, and Julia specializes methods on the concrete argument type regardless of an abstract signature annotation. Verified on the collapsed method: dispatch resolves to the single
AbstractGalileoDatamethod, return type infers to concreteBool, 0 allocations at a concrete call site, and no dynamic dispatch in the specialized body (pure inlinedgetfield/isnothing).Scope
This is the decoded-data hierarchy only. A cross-package
get_time_system(decoder_state)accessor was considered and deliberately left out: PositionVelocityTime.jl already derives the time system from the ranging signal (GNSSSignals.get_time_system(state.system)), which is the authoritative source, so a parallel decoder-state path would only invite drift.Tests & docs
test/gnss_supertype.jl(wired intoruntests.jl): asserts the type hierarchy, that every Galileo type dispatches to the single supertype method (which), and the collapsed methods' behaviour for both signals.docs/src/api.mddocuments both new supertypes.🤖 Generated with Claude Code