connor/astrokit
1
0 Fork 0
Code Issues 20 Pull Requests Actions Packages Projects Releases Wiki Activity

Reference frames #6

New Issue
Closed
opened 2026-09-30 11:08:02 -04:00 by connor · 3 comments
connor commented 2026-09-30 11:08:02 -04:00
Owner
Copy link
Copy source

GCRF/J2000 to ITRF via ANISE, geodetic site coordinates, topocentric frames. Cross-checks against ANISE's own validated values.

M1.

GCRF/J2000 to ITRF via ANISE, geodetic site coordinates, topocentric frames. Cross-checks against ANISE's own validated values. M1.
connor added this to the M1 milestone 2026-09-30 11:24:56 -04:00
connor added the size/M label 2026-09-30 11:24:56 -04:00
connor commented 2026-09-30 14:29:58 -04:00
Author
Owner
Copy link
Copy source

Scope reduced. The frame type itself, and the Cartesian and equinoctial representations that carry it, move to #26. This issue keeps the actual transformations: GCRF/J2000 to ITRF via ANISE, geodetic site coordinates, topocentric frames, and the ANISE cross-checks.

Scope reduced. The frame type itself, and the Cartesian and equinoctial representations that carry it, move to #26. This issue keeps the actual transformations: GCRF/J2000 to ITRF via ANISE, geodetic site coordinates, topocentric frames, and the ANISE cross-checks.
connor commented 2026-09-30 15:26:05 -04:00
Author
Owner
Copy link
Copy source

Owed by this issue: a path from a body-fixed state to orbital elements.

Cartesian::keplerian currently panics on a non-inertial frame, because a velocity in a rotating frame is not the inertial velocity and converting it anyway returns a plausible wrong answer. That is the right behavior only until the transformations exist. Once they do, the conversion should transform the state to an inertial frame first and then convert, rather than refuse.

That needs an epoch, which a Cartesian does not currently carry — the rotation between ECEF and an inertial frame is a function of time. So this issue also has to settle whether the epoch goes on Cartesian, or is passed to the transformation, or both.

Owed by this issue: **a path from a body-fixed state to orbital elements.** `Cartesian::keplerian` currently panics on a non-inertial frame, because a velocity in a rotating frame is not the inertial velocity and converting it anyway returns a plausible wrong answer. That is the right behavior only until the transformations exist. Once they do, the conversion should transform the state to an inertial frame first and then convert, rather than refuse. That needs an epoch, which a `Cartesian` does not currently carry — the rotation between ECEF and an inertial frame is a function of time. So this issue also has to settle whether the epoch goes on `Cartesian`, or is passed to the transformation, or both.
connor commented 2026-09-30 18:13:49 -04:00
Author
Owner
Copy link
Copy source

Done on branch feature/frames (927043c), not merged — awaiting review.

  • Cartesian::to_frame and to_inertial, rotating position and velocity with v' = R v + R_dot r
  • Geodetic to and from a body-fixed position, plus the local east-north-up rotation and look
  • cross-checks against ANISE for both the geodetic conversion and our body constants

The epoch is passed to the transformation, not carried on Cartesian. An almanac has to be passed anyway, so a field would have bought nothing. The body-fixed to elements path is state.to_inertial(epoch, almanac)?.keplerian().

Two corrections to what earlier comments said:

  1. ANISE's public data host is reachable after all — the failure was a certificate hostname mismatch, and https://storage.googleapis.com/public-data.nyxspace.com/... works.
  2. So pck11.pca is available, which means body-fixed frames for bodies other than Earth do work, contrary to what #5 concluded. Earth uses ITRF93 from the orientation kernel; everything else uses its IAU frame from the constants kernel.
Done on branch `feature/frames` (927043c), not merged — awaiting review. - `Cartesian::to_frame` and `to_inertial`, rotating position and velocity with `v' = R v + R_dot r` - `Geodetic` to and from a body-fixed position, plus the local east-north-up rotation and `look` - cross-checks against ANISE for both the geodetic conversion and our body constants **The epoch is passed to the transformation, not carried on `Cartesian`.** An almanac has to be passed anyway, so a field would have bought nothing. The body-fixed to elements path is `state.to_inertial(epoch, almanac)?.keplerian()`. Two corrections to what earlier comments said: 1. ANISE's public data host is reachable after all — the failure was a certificate hostname mismatch, and `https://storage.googleapis.com/public-data.nyxspace.com/...` works. 2. So `pck11.pca` is available, which means **body-fixed frames for bodies other than Earth do work**, contrary to what #5 concluded. Earth uses ITRF93 from the orientation kernel; everything else uses its IAU frame from the constants kernel.
Sign in to join this conversation.
No Branch/Tag Specified
Labels
Clear labels
size/L
Multiple days
 size/M
A day or so
 size/S
A few hours
No labels size/M
Milestone
No items
No Milestone M1
Projects
Clear projects
No projects
Assignees
Clear assignees
agent connor (Connor Johnstone)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: connor/astrokit#6