Zum Inhalt springen
AstroWay/api v2.102.11 · de
alle Systeme in Ordnung

Genauigkeit der Berechnungen

Die AstroWay API nutzt Swiss Ephemeris (den offiziellen C-Code von Astrodienst, den Schöpfern von astro.com) – dieselbe Engine, auf der professionelle Astrologen seit über 30 Jahren in Solar Fire ($495), Kepler ($995), Astro Gold ($29.99/Monat) und Janus arbeiten. Wir haben sie in WebAssembly kompiliert und mit einer REST-API-Schicht versehen, ohne Zwischenhändleraufschläge. Jeder der grundlegenden Berechnungsendpunkte wird durch Regression-Snapshot-Tests abgedeckt; die Genauigkeit der Engine wurde durch Triangulation mit drei unabhängigen Quellen verifiziert + gegen den NASA 5-Millennium Eclipse Catalog:

  • Planetenpositionen: < 0.1 Bogensekunden vs der offiziellen swetest CGI von Astrodienst
  • Häuserkanten Placidus: 0.000" exakter Treffer
  • Finsternisse: < 1 Minute vs NASA Eclipse Catalog
  • Astrogeographische Linien: < 1.5 km am Äquator vs swetest
  • Sonnenauf-/-untergang: < 10 Sekunden vs timeanddate.com
  • Mond VOC, Eintritte, Planetenkonjunktionen: Genauigkeit bis auf Bruchteile einer Sekunde
KomponenteWert
BibliothekSwiss Ephemeris C Code (aloistr/swisseph)
VersionUpstream Astrodienst C Code
Bindingsswisseph-wasm (WebAssembly in Node.js)
EphemeridenDE431 JPL Ephemeriden (über .se1-Dateien)
FallbackMoshier-Analytik (für Daten außerhalb 1800–2399)
Code-SharingShared @/core mit app.astroway.info – eine Engine, zwei Transportwege

Die Genauigkeit wird durch Triangulation überprüft – ein Vergleich mit drei unabhängigen Quellen:

Die offizielle Referenz-Implementierung von Swiss Ephemeris direkt von Astrodienst – der Code, der Astro.com erschaffen hat und Millionen von Astrologen weltweit bedient. Die maßgebliche öffentliche Quelle. Unsere Engine ist identisch (0.00–0.07 Bogensekunden Drift).

Eine unabhängige Python-Bibliothek, die pyswisseph-Bindings statt unserer WASM-Schicht nutzt. Bestätigt, dass unsere WASM-Schicht die Daten nicht verfälscht.

Eine entfernte Swiss-Ephemeris-API (sidereal Lahiri). Ein systematischer Drift von 8–17 Bogensekunden hängt mit unterschiedlichen Versionen der Lahiri-Ayanamsa-Formel zusammen und nicht mit der Genauigkeit der Engine.

Kartevs swetest (Astrodienst)vs Kerykeion (Python)vs Prokerala API
Monroe 19260.00”0.19”16.95” (systematisch)
Diana 19610.00”0.69”8.18” (systematisch)
Einstein 18790.07”LMT-Artefakt Kerykeion14.96” (systematisch)

Jeder der grundlegenden Berechnungsendpunkte wird durch eingefrorene Snapshot-Tests an 3 Referenzkarten (Monroe / Diana / Einstein) abgedeckt = 818 Snapshots.

Die Snapshot-Suite erkennt:

  • Mapping-Fehler der Eingabedaten – falsche Planeten-ID, UT, Häusersystem
  • Nachbearbeitung – Rundung, Einheitenumrechnung, Vorzeichenverlust
  • Abweichungen der Standardwerte – mittlerer vs wahrer Mondknoten, geozentrisch vs topografisch
  • Schema-Drift – Validierung ließ eine falsche Form durch
  • Veraltete Bereitstellung – die Produktionsdistribution entspricht nicht dem Code

Toleranz: 5e-5° (≈0.18 Bogensekunden) standardmäßig für alle numerischen Felder.

KarteDatumMaximaler Drift
Marilyn Monroe1926-06-010.00”
Prinzessin Diana1961-07-010.00”
Albert Einstein1879-03-140.07”
KarteDrift ASCDrift MCMaximaler Drift der Häuserkante
Monroe0.000”0.000”0.000”
Diana0.000”0.000”0.000”
EreignisNASA-MaximumUnser MaximumDrift
2025-03-14 Totale Mondfinsternis06:58 UT06:58 UT0.8 Min.
2025-03-29 Partielle Sonnenfinsternis10:47 UT10:47 UT0.5 Min.
2025-09-07 Totale Mondfinsternis18:11 UT18:11 UT0.8 Min.
2025-09-21 Partielle Sonnenfinsternis19:41 UT19:42 UT1.0 Min.

Alle Linien MC/IC/ASC/DSC nutzen die korrekte Formel longitude = RA − GMST (Standard nach Kenneth Bowser). Drift zum Referenzwert: < 1.5 km am Äquator für alle Planeten.

StandortDatumParameterDrift
London2026-04-15Sonnenaufgang0.6 s
London2026-04-15Sonnenuntergang9 s

Polare Standorte (|Breite| > 66.5°) liefern automatisch polarState + eine Warnung, dass gewöhnliche Planetenstunden nicht definiert sind.

AstroWay nutzt variable Orbis pro Planet (MIN-Regel zweier Planeten), wie bei ZET9 und astro.com. Standard-Orbis (für Geburtskarten):

AspektSonneMondInnereJupiterÄußere
Konjunktion12°10°
Sextil6.5°
Quadrat10°
Trigon12°
Opposition12°10°

Minor-Aspekte (36°, 40°, 45°, 72°, 108°, 135°, 144°) sind standardmäßig deaktiviert. Sie werden explizit über ALL_ASPECTS aktiviert.

Für |Breite| > 66.5° sind die Systeme Placidus / Koch / Regiomontanus mathematisch undefiniert. In solchen Fällen liefert Swiss Ephemeris automatisch Porphyrius, und unsere API fügt eine Warnung hinzu:

{
"system": "P",
"warning": "Das Placidus-System ist für Breite=68.96° (> 66.5°) undefiniert. Swiss Ephemeris hat Porphyrius verwendet..."
}

Regression wird bei jedem PR durch CI überprüft:

  • api-calc/tests/endpoints/ – 818 Snapshots gegen Referenzkarten (Monroe / Diana / Einstein) + Synastrie / Composite / Davison
  • .github/workflows/api-accuracy.yml – automatischer Start bei PR
  • Triangulation gegen swetest CGI + Kerykeion – wöchentlich
  • Überwachung von upstream Swiss Ephemeris über Dependabot
  • Daten außerhalb des Bereichs (vor 1800 und nach 2399): Es wird die Moshier-Analytik genutzt, Genauigkeit ~0.1” (vs < 0.01” für SWIEPH mit DE431-Dateien)
  • Wahre Lilith (id=13) vs mittlere Lilith (id=12): Unterschied bis zu 12° – standardmäßig wird mittlere Lilith genutzt (stabile Berechnung), wahre Lilith ist über planetIds: [13] verfügbar
  • Topografisch vs geozentrisch: Standardmäßig geozentrisch

Bei Fragen zur Genauigkeit: Schreib uns an support@astroway.info mit den Kartendaten und der erwarteten Referenz (astro.com oder eine andere maßgebliche Quelle).

Hilfreich?
Запропонувати правку

Zuletzt aktualisiert: