Genauigkeit der Berechnungen

TL;DR

Die AstroWay API verwendet Swiss Ephemeris (offizieller C-Code von Astrodienst, den Machern von astro.com) – dieselbe Engine, mit der professionelle Astrologen seit über 30 Jahren in Solar Fire ($495), Kepler ($995), Astro Gold ($29.99/Monat) und Janus arbeiten. Wir betreiben sie auf unseren eigenen Servern und stellen sie als REST API-Schicht bereit, ohne Zwischenhändler-Aufschlag. Jeder der grundlegenden Berechnungs-Endpoints ist durch Regression- Snapshot-Tests abgedeckt; die Genauigkeit der Engine wurde durch Triangulation mit drei unabhängigen Quellen + gegen den NASA 5-Millennium Eclipse Catalog verifiziert:

• Planetenpositionen: Median 0.0013", Maximum 0.561" vs. offiziellem swetest CGI Astrodienst (gemessen am 29.07.2026 bei 130 Messungen). Aufschlüsselung nach Körpern unten
• Unabhängiger Lauf mit fremdem Benchmark (RoxyAPI, gegen NASA JPL Horizons DE441): 210 von 210 innerhalb der Toleranz, Median 0.11", Maximum 0.60"
• Placidus-Hausspitzen: 0.000" exakte Übereinstimmung
• Finsternisse: < 1 Minute vs. NASA Eclipse Catalog
• ACG-Linien: < 1.5 km am Äquator vs. swetest
• Sonnenauf-/untergang: < 10 Sekunden vs. timeanddate.com
• Mond VOC, Ingresses, Planetenkonjunktionen: Genauigkeit bis auf Bruchteile einer Sekunde

Methodik: Wie genau gemessen wurde

Diese Zahlen sind keine Schätzung, sondern das Ergebnis eines Laufs. Das Skript nimmt 10 Horoskope, verteilt von 1900 bis 2050, fragt dieselben Momente beim Live-swetest CGI Astrodienst an und vergleicht alle 13 Körper, die wir zurückgeben. Insgesamt 130 Messungen.

Körper	Maximaler Drift
Sonne, Venus, Saturn	0.001"
Merkur	0.002"
true Node	0.004"
Mars	0.007"
Jupiter	0.009"
Mond	0.022"
Uranus	0.083"
Pluto	0.097"
Neptun	0.223"
Chiron	0.561"
mean Apogee (Lilith)	0.000"

Median über alle 130 Messungen: 0.0013".

Zuvor stand auf dieser Seite das allgemeine Versprechen ”< 0.1 Bogensekunde”. Messungen vom 29.07.2026 zeigten, dass Neptun, Pluto und Chiron dies nicht einhalten, daher wurde das Versprechen durch die tatsächlichen Zahlen ersetzt. Chiron und die äußeren Planeten haben einen größeren Drift, da ihre Positionen aus einem komprimierten Ephemeriden-Set stammen, das unser Build verwendet.

Du kannst dies selbst reproduzieren: api-calc/scripts/accuracy-vs-swetest.mjs führt genau diese Anfragen aus und druckt dieselbe Tabelle.

Überprüfe es selbst. Das Skript, mit dem die obigen Zahlen gemessen wurden, befindet sich in einem öffentlichen Repository unter MIT-Lizenz: astroway/astrology-accuracy-benchmark. Es funktioniert nicht nur mit uns: Ein Adapter zu jeder anderen API sind dreißig Zeilen Code, sodass dieselben 130 Messungen gegen einen Konkurrenten ausgeführt und verglichen werden können. Ein Sandbox-Schlüssel ist ausreichend.

Engine

Komponente	Wert
Bibliothek	Swiss Ephemeris C code (aloistr/swisseph)
Version	upstream Astrodienst C code
Ephemeriden	DE431 JPL ephemeris (über .se1 Dateien)
Fallback	Moshier analytical (für Daten außerhalb 1800-2399)
Code-Sharing	Shared @/core mit app.astroway.info - eine Engine, zwei Transporte

Methodik

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

1. swetest CGI (Referenz)

Die offizielle Referenzimplementierung von Swiss Ephemeris von Astrodienst selbst – dem Team, das Astro.com erstellt hat und Millionen von Astrologen weltweit betreut. Die maßgeblichste öffentliche Quelle. Unsere Engine ist identisch (0.00–0.07 Bogensekunden Drift).

2. Kerykeion (Python)

Eine unabhängige Python-Bibliothek verwendet pyswisseph-Bindings, die unabhängig von unserem Build sind. Bestätigt, dass unsere Wrapper-Schicht die Daten nicht verzerrt.

3. Prokerala API

Eine entfernte Swiss Ephemeris API (sidereal Lahiri). Der systemische Drift von 8–17 Bogensekunden ist auf unterschiedliche Versionen der Lahiri-Ayanamsa-Formel zurückzuführen und nicht auf die Genauigkeit der Engine.

Triangulationsergebnisse

Horoskop	gegen swetest (Astrodienst)	gegen Kerykeion (Python)	gegen Prokerala API
Monroe 1926	0.00”	0.19”	16.95” (systemisch)
Diana 1961	0.00”	0.69”	8.18” (systemisch)
Einstein 1879	0.07”	LMT-Artefakt Kerykeion	14.96” (systemisch)

Unabhängige Überprüfung mit einem fremden Tool

RoxyAPI veröffentlicht einen eigenen Benchmark gegen NASA JPL Horizons DE441: MIT-Lizenz, nur Standardbibliothek, 21 Horoskope und 210 Positionen, und ein --base-url-Flag, um es auf jede andere API auszurichten. In ihrem README wird ausdrücklich erwähnt, dass die Toleranzen absichtlich nicht an ihre eigene Engine angepasst wurden, da ein Benchmark, der einen Konkurrenten überprüfen soll, fair sein muss.

Wir haben es auf uns selbst ausgerichtet, ohne eine einzige Zahl in ihrem Code zu ändern. Der Adapter benennt ein Anforderungsfeld um und entfernt einen Antwort-Wrapper.

	AstroWay	RoxyAPI, deren Lauf 29.09.2026
Innerhalb der Toleranz	210 von 210	210 von 210
Median der Abweichung	0.11"	0.05"
Maximum	0.60"	0.78"

Unsere Messung vom 09.09.2026, Kosten 21 API-Anfragen. RoxyAPI ist im September auf direktes Lesen von DE440 umgestiegen, und ihr Median ist jetzt niedriger als unserer; unser Maximum ist niedriger als ihres. Geordnete Ausgabe aller 210 Zeilen: CSV.

Regression-Set auf Endpunkt-Ebene

Jeder der grundlegenden Berechnungs-Endpoints ist durch eingefrorene Snapshot-Tests für 3 Referenzhoroskope (Monroe / Diana / Einstein) abgedeckt = 873 Snapshots.

Die Snapshot-Suite fängt:

• Fehler beim Input-Mapping: falsche Planeten-ID, UT, Haussystem
• Nachbearbeitung: Rundung, Einheitenkonvertierung, Vorzeichenverlust
• Standardabweichung: mittlerer vs. wahrer Knoten, geozentrisch vs. topozentrisch
• Schema-Drift: Validierung hat eine falsche Form übersehen
• Veralteter Deploy: Prod-Dist stimmt nicht mit dem Code überein

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

Detaillierte Benchmarks

Planetenpositionen (tropisch, gegen swetest)

Horoskop	Datum	Maximaler Drift
Marilyn Monroe	1926-06-01	0.00”
Princess Diana	1961-07-01	0.00”
Albert Einstein	1879-03-14	0.07”

Placidus-Hausspitzen (gegen swetest)

Horoskop	Drift ASC	Drift MC	Maximaler Drift Hausspitze
Monroe	0.000”	0.000”	0.000”
Diana	0.000”	0.000”	0.000”

Finsternisse (gegen NASA 5-Millennium Catalog)

Ereignis	NASA Maximum	Unser Maximum	Drift
2025-03-14 Lunar Total	06:58 UT	06:58 UT	0.8 Min
2025-03-29 Solar Partial	10:47 UT	10:47 UT	0.5 Min
2025-09-07 Lunar Total	18:11 UT	18:11 UT	0.8 Min
2025-09-21 Solar Partial	19:41 UT	19:42 UT	1.0 Min

Astro-Kartografie (gegen RA-Formel aus swetest)

MC- und IC-Linien werden nach der Formel longitude = RA − GMST (Standard Kenneth Bowser) konstruiert. Drift vom Referenzwert: < 1.5 km am Äquator für alle Planeten.

Horizontale Linien ASC und DSC werden aus der Horizontgleichung in denselben äquatorialen Koordinaten berechnet: cos H = -tan φ · tan δ, wobei H = (GMST + lng) − RA. Die Hälften unterscheiden sich durch das Vorzeichen des Stundenwinkels: Bei H < 0 ist der Körper östlich des Meridians, d.h. er geht auf. Eine Überprüfung, die wir bei jedem Lauf durchführen: Jeder Punkt jeder horizontalen Kurve wird genommen und die Höhe des Körpers über dem Horizont an diesem Punkt berechnet. Bei 8419 Punkten beträgt die maximale Abweichung 0.0 km, d.h. der Körper steht tatsächlich überall dort am Horizont, wo wir die Linie gezogen haben.

Korrigiert am 12.08.2026: Bis zu diesem Datum waren ASC und DSC vertauscht

Bis zum 12.08.2026 lösten die Horizontkurven eine andere Gleichung (“diese ekliptische Länge am Aszendenten”), und die beiden Hälften unterschieden sich durch einen invertierten Test, so dass ASC dort stand, wo der Körper untergeht. MC und IC waren nie betroffen.

Die zweite, weniger auffällige Hälfte desselben Fehlers: Die alte Gleichung ignorierte die ekliptische Breite des Körpers, so dass die Linie proportional dazu abwich, ungefähr 103 km für jeden Grad Breite. Auf der Karte von Marilyn Monroe sind das 0 km für Sonne und Knoten, 22 km für Merkur, 161 für Pluto, 285 für den Mond, 345 für Lilith. Auf Karten, wo der Körper hoch über der Ekliptik steht, erreichte die Abweichung über 1500 km.

Was das für deinen Code bedeutet. Wenn du den vorherigen Fehler umgangen hast, indem du ASC und DSC bei dir vertauscht hast, entferne diese Umgehung. Wenn du das Feld knownDefect gelesen hast, ist es nicht mehr in den Antworten enthalten. Die Koordinaten der horizontalen Linien für Körper mit signifikanter ekliptischer Breite haben sich geändert, daher sollten zwischengespeicherte Karten neu generiert werden.

Sonnenauf- / -untergang (gegen timeanddate.com)

Ort	Datum	Parameter	Drift
London	2026-04-15	Sunrise	0.6 s
London	2026-04-15	Sunset	9 s

Polare Orte (|lat| > 66.5°) geben automatisch polarState + eine Warnung zurück, dass die normalen Planetenstunden nicht definiert sind.

Aspektorbien

AstroWay verwendet variable Orbien pro Planet (MIN-Regel der beiden Planeten), wie in ZET9 und astro.com. Standard-Orbien (für das Geburtshoroskop):

Aspekt	Sonne	Mond	Inner	Jupiter	Outer
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°

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

Polare Breiten

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

{
  "system": "P",
  "warning": "Placidus system is undefined for lat=68.96° (> 66.5°). Swiss Ephemeris fell back to Porphyry..."
}

Kontinuierliche Überprüfung

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

• api-calc/tests/endpoints/: 873 Snapshots gegen Referenzhoroskope (Monroe / Diana / Einstein) + Synastrie / Komposit / 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 die Hälfte des Vertrauens. Die andere Hälfte ist der Ausgabevertrag, den ein Agent (Claude, ChatGPT, Cursor) validieren kann. Unser MCP-Server gibt nicht “rohen Text, finde es selbst heraus” 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, nicht eine Zeichenkette, die zufällig geparst werden muss.
• Schutz vor Schema-Drift. Der CI-Test openapi-example-drift validiert jeden Regression-Snapshot gegen das aus seinem eigenen Beispiel abgeleitete Schema: Wenn die tatsächliche Ausgabe des Endpunkts vom veröffentlichten Schema abweicht, schlägt der Build fehl. Genau diese Art von Abweichungen verursacht den MCP-Fehler -32602 Output validation error.
• Fehler: Das sind Fehler. Ein Tool-Fehler 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.

Das bedeutet, dass die Integration über MCP genauso vorhersehbar ist wie ein direkter REST-Aufruf: Was in /openapi.json beschrieben ist, ist das, was das Tool zurückgibt.

Bekannte Einschränkungen

• Daten außerhalb des Bereichs (vor 1800 und nach 2399): Es wird Moshier analytical verwendet, Genauigkeit ~0.1” (gegenüber < 0.01” für SWIEPH mit DE431-Dateien)
• True Lilith (id=13) vs. Mean Lilith (id=12): Unterschied bis zu 12° – standardmäßig Mean Lilith (stabiles Verhalten), True Lilith ist über planetIds: [13] verfügbar
• Topozentrisch vs. geozentrisch: standardmäßig geozentrisch

Links

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

Kontakt

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