From d93bb1ee2c955532a03476bbfd2a4aef98e92a9f Mon Sep 17 00:00:00 2001 From: Senrokai Date: Tue, 29 Sep 2026 19:58:33 +0200 Subject: [PATCH] Say that Pluto's tilt is checked against its own IAU pole, not against Horizons The ETL's obliquity check, its failure message and the renderer spec's test name all compared Pluto's drawn tilt with "the obliquity Horizons gives", as 1c86584 and cdf474b said too. Horizons' Pluto page states none (grep -i obliq finds only the page's IAU76 frame note); the 119.6 degrees is hand-entered in fetchSolarSystem.ts from the IAU WGCCRE 2015 pole (RA 132.993, Dec -6.163), which with Pluto's orbit gives 119.609. So for Pluto the check confirms that the kernel's pole and the sense of W were read as written, which it would still catch misread, but not the pole against a second source. The build.ts comment says so, its message names Pluto's reference as its IAU pole, and the spec's test name and comment no longer attribute Pluto's tilt to Horizons. Labels only; no behaviour changes. Co-Authored-By: Claude Opus 5.5 (1M context) --- .../features/galaxy-system/system-orbits-renderer.spec.ts | 4 +++- tools/etl/build.ts | 6 +++++- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/src/app/features/galaxy-system/system-orbits-renderer.spec.ts b/src/app/features/galaxy-system/system-orbits-renderer.spec.ts index 5ed9372..f498fd1 100644 --- a/src/app/features/galaxy-system/system-orbits-renderer.spec.ts +++ b/src/app/features/galaxy-system/system-orbits-renderer.spec.ts @@ -678,7 +678,9 @@ describe('solar-system bodies against Horizons', () => { return (spin.angleTo(new THREE.Vector3(0, 0, 1).applyQuaternion(line.quaternion)) * 180) / Math.PI; } - it('turns Venus, Uranus and Pluto backwards against their orbits, at the tilts Horizons gives', () => { + it('turns Venus, Uranus and Pluto backwards against their orbits, at the tilts Horizons gives the first two', () => { + // Pluto's Horizons page gives no tilt; 119.6 is the one its IAU pole makes with its orbit, so for + // Pluto this checks that its pole and W are drawn as the kernel gives them, not the pole itself. // The IAU names a planet's north pole by the side of the solar system it lies on, so Venus's W // and Uranus's run backwards; Pluto's pole follows the right-hand rule instead, and points // south. Either way the spin read off the drawn sphere is past 90 degrees from the orbit's pole. diff --git a/tools/etl/build.ts b/tools/etl/build.ts index d4dfd08..a8abb94 100644 --- a/tools/etl/build.ts +++ b/tools/etl/build.ts @@ -209,6 +209,10 @@ const DAY_OFFSET_CEILINGS: Record = { neptune: 0.01 }; * a planet's north pole by the side of the solar system it lies on, whichever way the planet turns. * Measured on this catalogue: at most 0.058 degrees (Venus, 177.358 against 177.3). Taken as the * pole alone, Venus comes out at 2.6 degrees and Uranus at 82.2, which is what this catches. + * + * Pluto's Horizons page states no obliquity: its 119.6 is worked out from the IAU pole itself (see + * `BodySpec.obliquityDeg`), so for Pluto this checks only that the kernel's pole and W were read as + * written, not the pole against a second source. */ const MAX_OBLIQUITY_OFFSET_DEG = 0.1; @@ -327,7 +331,7 @@ function validateBodies(bodies: BodyRecord[], horizonsOrbits: Map