Genauigkeit der Berechnungen

Kurzzusammenfassung

Die AstroWay API nutzt Swiss Ephemeris (offizieller C-Code von Astrodienst, den Schöpfern von astro.com) – dieselbe Engine, die professionelle Astrologen seit über 30 Jahren in Solar Fire ($495), Kepler ($995), Astro Gold ($29.99/Monat) und Janus verwenden. Wir haben sie in WebAssembly kompiliert und als REST-API bereitgestellt, ohne Zwischenhändleraufschlag. Jeder grundlegende Berechnungs-Endpunkt wird durch Regression-Snapshot-Tests abgedeckt; die Genauigkeit der Engine wurde durch Triangulation mit drei unabhängigen Quellen verifiziert, zusätzlich gegen den NASA 5-Millennium Eclipse Catalog:

• Planetenpositionen: Median 0.0013", Maximum 0.561" vs. der offiziellen swetest CGI von Astrodienst (gemessen am 29.07.2026 an 130 Messungen). Die Aufschlüsselung nach Himmelskörpern findest du unten.
• Placidus-Häuser-Kuspen: 0.000" exakter Treffer
• Finsternisse: < 1 Minute vs. NASA Eclipse Catalog
• Astro-Kartografie-Linien (ACG): < 1.5 km am Äquator vs. swetest
• Sonnenauf-/-untergang: < 10 Sekunden vs. timeanddate.com
• Mond-VOC, Eintritte, Planetenkonjunktionen: Genauigkeit bis auf Bruchteile einer Sekunde

Methodik: Wie die Messungen durchgeführt wurden

Diese Zahlen sind keine Schätzung, sondern das Ergebnis von Durchläufen. Das Skript verwendet 10 Karten, verteilt über die Jahre 1900 bis 2050, fragt dieselben Zeitpunkte beim live swetest CGI von Astrodienst ab und vergleicht alle 13 Himmelskörper, die wir zurückgeben. Insgesamt 130 Messungen.

Himmelskörper	Maximale Abweichung
Sonne, Venus, Saturn	0.001"
Merkur	0.002"
Wahrer Mondknoten	0.004"
Mars	0.007"
Jupiter	0.009"
Mond	0.022"
Uranus	0.083"
Pluto	0.097"
Neptun	0.223"
Chiron	0.561"
Mittlerer Apogäum (Lilith)	0.000"

Median aller 130 Messungen: 0.0013".

Früher stand auf dieser Seite das allgemeine Versprechen „< 0.1 Bogensekunden“. Die Messungen vom 29.07.2026 zeigten, dass Neptun, Pluto und Chiron dieses Versprechen nicht halten, daher wurde das Versprechen durch die tatsächlichen Zahlen ersetzt. Chiron und die äußeren Planeten weisen eine größere Abweichung auf, da ihre Positionen aus einem komprimierten Satz von Ephemeriden in der WASM-Build stammen.

Du kannst es selbst nachvollziehen: Das Skript api-calc/scripts/accuracy-vs-swetest.mjs führt genau diese Abfragen aus und gibt dieselbe Tabelle aus.

Überprüfe es selbst. Das Skript, mit dem die oben genannten Zahlen gemessen wurden, liegt im öffentlichen Repository unter MIT-Lizenz: astroway/astrology-accuracy-benchmark. Es funktioniert nicht nur mit uns: Ein Adapter zu einer beliebigen anderen API sind nur etwa 30 Zeilen, sodass du dieselben 130 Messungen gegen einen Konkurrenten laufen lassen und vergleichen kannst. Ein Sandbox-Key reicht aus.

Engine

Komponente	Wert
Bibliothek	Swiss Ephemeris C Code (aloistr/swisseph)
Version	Upstream-Astrodienst-C-Code
Bindings	swisseph-wasm (WebAssembly in Node.js)
Ephemeriden	DE431 JPL Ephemeriden (über .se1-Dateien)
Fallback	Moshier-Analytik (für Daten außerhalb 1800–2399)
Code-Sharing	Shared @/core mit app.astroway.info – eine Engine, zwei Transportwege

Methodik

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

1. swetest CGI (Referenz)

Die offizielle Referenz-Implementierung von Swiss Ephemeris von Astrodienst selbst – die Entwickler von Astro.com, die Millionen von Astrologen weltweit bedienen. Die vertrauenswürdigste öffentliche Quelle. Unsere Engine ist identisch (0.00–0.07 Bogensekunden Abweichung).

2. Kerykeion (Python)

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

3. Prokerala API

Ein entfernter Swiss-Ephemeris-API (siderisch, Lahiri). Systematische Abweichung von 8–17 Bogensekunden, verursacht durch unterschiedliche Versionen der Lahiri-Ayanamsa-Formel, nicht durch die Genauigkeit der Engine.

Triangulationsergebnisse

Karte	vs. swetest (Astrodienst)	vs. Kerykeion (Python)	vs. Prokerala API
Monroe 1926	0.00”	0.19”	16.95” (systematisch)
Diana 1961	0.00”	0.69”	8.18” (systematisch)
Einstein 1879	0.07”	LMT-Artefakt Kerykeion	14.96” (systematisch)

Regression-Tests auf Endpunkt-Ebene

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

Der Snapshot-Suite erkennt:

• Mapping-Fehler der Eingabedaten – falsche Planeten-ID, UT, Häusersystem
• Nachbearbeitung – Rundung, Einheitenumrechnung, Vorzeichenverlust
• Abweichungen bei Standardwerten – mittlerer vs. wahrer Knoten, geozentrisch vs. topografisch
• Schema-Drift – Validierung ließ eine falsche Form durch
• Veraltetes Deployment – die Produktionsdistribution entspricht nicht dem Code

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

Detaillierte Benchmarks

Planetenpositionen (tropisch, vs. swetest)

Karte	Datum	Maximale Abweichung
Marilyn Monroe	01.06.1926	0.00”
Prinzessin Diana	01.07.1961	0.00”
Albert Einstein	14.03.1879	0.07”

Placidus-Häuser-Kuspen (vs. swetest)

Karte	Abweichung ASC	Abweichung MC	Maximale Abweichung der Häusekuspe
Monroe	0.000”	0.000”	0.000”
Diana	0.000”	0.000”	0.000”

Finsternisse (vs. NASA 5-Millennium Catalog)

Ereignis	NASA-Maximum	Unser Maximum	Abweichung
14.03.2025 Totale Mondfinsternis	06:58 UT	06:58 UT	0.8 Min.
29.03.2025 Partielle Sonnenfinsternis	10:47 UT	10:47 UT	0.5 Min.
07.09.2025 Totale Mondfinsternis	18:11 UT	18:11 UT	0.8 Min.
21.09.2025 Partielle Sonnenfinsternis	19:41 UT	19:42 UT	1.0 Min.

Astro-Kartografie (vs. RA-Formel von swetest)

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

Sonnenauf-/-untergang (vs. timeanddate.com)

Standort	Datum	Parameter	Abweichung
London	15.04.2026	Sonnenaufgang	0.6 Sek.
London	15.04.2026	Sonnenuntergang	9 Sek.

Polare Standorte (|Breite| > 66.5°) geben automatisch polarState + eine Warnung zurück, dass normale Planetenstunden nicht definiert sind.

Orbis der Aspekte

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

Aspekt	Sonne	Mond	Innere Planeten	Jupiter	Äußere Planeten
Konjunktion	12°	10°	5°	8°	5°
Sextil	6.5°	6°	5°	5°	5°
Quadrat	10°	8°	5°	7°	5°
Trigon	12°	8°	5°	5°	5°
Opposition	12°	10°	5°	8°	5°

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

Polare Breiten

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

{
  "system": "P",
  "warning": "Система Placidus не визначена для lat=68.96° (> 66.5°). Swiss Ephemeris підставив Porphyry..."
}

Kontinuierliche Überprüfung

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

• api-calc/tests/endpoints/ – 873 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

MCP-Zuverlässigkeit – Typisierte Ausgabe

Die Genauigkeit der Engine ist nur die halbe Vertrauensbasis. Die andere Hälfte ist der Ausgabekontrakt, den ein Agent (Claude, ChatGPT, Cursor) validieren kann. Unser MCP-Server gibt nicht einfach „rohen Text, du musst selbst damit klarkommen“ zurück:

• Typisierter structuredContent. Über 600 MCP-Tools, und die überwiegende Mehrheit davon veröffentlicht ein striktes outputSchema – der MCP-Client erhält eine validierte Struktur, keinen String, den man erraten muss.
• Schutz vor Schema-Drift. Der CI-Test openapi-example-drift validiert jeden Regression-Snapshot gegen das Schema, das aus seinem eigenen Beispiel abgeleitet wurde: Wenn die tatsächliche Ausgabe eines Endpunkts von dem veröffentlichten Schema abweicht, schlägt der Build fehl. Genau diese Art von Abweichung verursacht den MCP-Fehler -32602 Output validation error.
• Fehler sind Fehler. Ein Ausfall eines Tools wird immer mit dem Flag isError und einem typisierten Code (UPPER_SNAKE) zurückgegeben. Wir geben niemals einen rohen Stack Trace oder interne Serverpfade als „Daten“ an das Modell zurück.

Die Integration über MCP ist also genauso vorhersehbar wie ein direkter REST-Aufruf: Was in /openapi.json beschrieben ist, ist genau das, was das Tool zurückgibt.

Bekannte Einschränkungen

• Daten außerhalb des Bereichs (vor 1800 und nach 2399): Es wird Moshier-Analytik verwendet, 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 verwendet (stabiles Verhalten), Wahre Lilith ist über planetIds: [13] verfügbar
• Topografisch vs. geozentrisch: Standardmäßig geozentrisch

Links

• Swiss Ephemeris: https://www.astro.com/swisseph/
• swetest CGI: https://www.astro.com/swisseph/swetest.htm
• NASA-Eclipse-Katalog: https://eclipse.gsfc.nasa.gov/
• Kerykeion: https://github.com/g-battaglia/kerykeion
• Astrodienst: https://www.astro.com/

Kontakt

Bei Fragen zur Genauigkeit: Schreib an support@astroway.info mit den Kartendaten und der erwarteten Referenz (astro.com oder eine andere vertrauenswürdige Quelle).