AstroWay/api v2.190.0 · de
alle Systeme in Ordnung

Wie wir die Genauigkeit unter Kontrolle halten: CI gegen swetest und NASA

Die Genauigkeit in der Astro-API verfällt leicht nach einem Refaktorings der Ephemeriden. Wir analysieren den Schutz: ein Swiss-Ephemeris-Kern auf Browser und Server, hunderte gefrorene Snapshots auf Referenzkarten und die Dreiecksverbindung jedes PR gegen swetest CGI, Kerykeion, Prokerala und das NASA-Schattenkatalog.

Genauigkeit ist das, was der Nutzer unbemerkt überprüft, wenn die aktuelle Karte in eine Winkelstunde gerät. Wenn die aktuelle Karte in eine Winkelstunde gerät, wird der Fehler schnell bemerkt. Und das Schlimmste daran ist, dass die Genauigkeit leicht unmerklich gebrochen werden kann: ein Refactoring im Code der Ephemeriden, und die Hälfte der Endpunkte fahren still in die Sekundärachse.

Hier ist, wie wir das verhindern.

Die Planetenpositionen werden mit Swiss Ephemeris berechnet, das in WASM zusammengestellt ist. Das wichtigste ist, dass es das gleiche Kernal ist, sowohl im Browser als auch auf dem Server. Eine einzige Codebasis core/, die über einen cross-repo-Alias im Backend und in der Build-Datei eingebunden ist. Es gibt keine “Browser” und “Server”-Implementierung, die sich voneinander unterscheiden können.

Für Daten außerhalb des Hauptbereichs der Ephemeriden ist ein analytischer Fallback (Moshier) vorgesehen, der etwas grober ist, aber keine Lücken hat. Eine ehrliche Erklärung: Wir geben die genaue Version der Rückschau nicht an, weil die tatsächliche Version des Kernals unter der neuesten upstream-Version liegt, und eine laute Zahl wäre eine Lüge.

Jeder berechnende Endpunkt hat ein Set von gefrorenen Snapshots - 873 JSON-Fixtures zum Zeitpunkt dieser Build. Der Runner läuft den Endpunkt auf Referenzkarten und vergleicht ihn mit der Fixtur. Jedes Abweichen der Planetenlänge um mehr als 5e-5° (0,18”) führt zu einem Test.

Die Referenzkarten wurden so ausgewählt, dass sie an den Rändern hauen, nicht nur im “angenehmen” Zentrum:

  • Monroe, Diana, Einstein, Bowie - historische Karten mit bekannten Geburtsdaten
  • Polare Breite - wo die Systeme geboren werden
  • Äquatoriale Breite - wo sie anders handeln
  • Südliche Hemisphäre - Überprüfung der Spiegelung

Die Grenzfälle fangen genau die Regressionsfälle, die auf der Karte des konditionierten Bauern nicht sichtbar sind.

Snapshots fangen Regressionsfälle gegen sich selbst. Um die absolute Wahrheit zu überprüfen, wird jeder Release mit unabhängigen Quellen verglichen:

Gegen wasWas überprüftAbweichung
swetest CGI (Astrodienst)Planetenlänge, Kußpäde der Häuser0.000"
Kerykeion (Python, pyswisseph)unabhängige Implementierung von SwEph< 0.2"
Prokerala (sidereal Lahiri)siddereische Positionen8-17" Systemunterschied der Formel Ayanamsha, nicht Rückschau
NASA 5-Millennium Eclipse CatalogZeit und Typ der Finsternisse< 1 min

Die Abweichung von Prokerala ist kein Fehler: es handelt sich um verschiedene Implementierungen der Formel Lahiri, und wir dokumentieren dies offensichtlich, nicht versteckt. Mit swetest, der Industrie-Standard, ist der Fehler Null.

Die astrografischen Linien werden einzeln geometrisch überprüft - die Genauigkeit am Äquator ist besser als 1,5 km.

Genauigkeit ist CI-Gate, kein einmaliges Überprüfen:

  • api-accuracy.yml - auf jedem PR im Backend-Code läuft der gesamte Satz von Snapshots + Dreieck. Der rote Test blockiert den Merge.
  • check-eclipse-accuracy.yml - einmal pro Jahr vergleicht die Finsternisse mit dem NASA-Katalog; Abweichungen über den Schwellenwert führen automatisch zu einem Issue.
  • check-sweph-updates.yml - einmal pro Monat überprüft die upstream Swiss Ephemeris und den WASM-Paket; eine neue Version führt zu einem Issue auf der Rezension, ohne automatischen Merge (das Update der Ephemeriden ist zu empfindlich für einen automatischen Merge).

Garantie einfach: Planetenpositionen innerhalb von < 0.1 Bogensekunden von dem Referenz-Swiss Ephemeris, und diese Grenze wird durch die Automatik geschützt, nicht durch eine Versprechen im README. Wenn jemals ein Regressionsfall auftritt, fällt er in unseren CI, nicht in die Beschwerde deines Nutzers.

Die öffentliche Version dieser Zahlen, mit einer Tabelle der Abweichungen auf bestimmten Karten, lebt auf der Seite Genauigkeit.

MakSeong · AstroWay

Ich entwickle das AstroWay API: packe Swiss Ephemeris in reines REST und schreibe über langweilige Details, die eigentlich wichtig sind.

// darauf aufbauen

Derselbe Swiss Ephemeris wie in Solar Fire - in 4 Zeilen Code.

Kostenloser Schlüssel ohne Kreditkarte. 5.000 Aufrufe pro Monat vor der ersten Zahlung.

Mehr aus dem Blog alle Beiträge →

Engineering 2026-07-15

Drei offizielle SDK: TypeScript, Python, PHP anstelle des rauen curl

Der räudige HTTP funktioniert, aber der typisierte Client spart Stunden: Autocomplete für Routen, Typen für Anfragen und Antworten, eingebauter retry für 408/409/429/5xx und eine Stahlschicht-Struktur für Fehler. Wir zerlegen die drei offiziellen SDK - @astroway/sdk (npm), astroway (PyPI), astroway/sdk (Packagist) - und aus welchem OpenAPI-Kontrakt sie generiert wurden.

Industry 2026-06-05

Free Astrology API: Which One Has the Best Free Tier in 2026?

A side-by-side of free tiers across the major astrology APIs - credits, request caps, card requirements - and how much you can actually build for free.

Engineering 2026-06-05

Horoscope API Tutorial: Build a Daily Horoscope Feature

Add daily, weekly and monthly horoscopes to your app via API - sign-based text vs transit-based personalization - with TypeScript and Python code.