Precyzja obliczeń

TL;DR

AstroWay API wykorzystuje Swiss Ephemeris (oficjalny kod C od Astrodienst, twórców astro.com) – ten sam silnik, na którym profesjonalni astrolodzy od ponad 30 lat pracują w Solar Fire ($495), Kepler ($995), Astro Gold ($29.99/mies) i Janus. Uruchamiamy go na własnych serwerach i udostępniamy jako warstwę REST API, bez pośrednich marż. Każdy z podstawowych endpointów obliczeniowych jest objęty testami regresji snapshot; dokładność silnika jest weryfikowana poprzez triangulację z trzema niezależnymi źródłami + w stosunku do NASA 5-Millennium Eclipse Catalog:

• Pozycje planet: mediana 0.0013", maksimum 0.561" vs oficjalny swetest CGI Astrodienst (zmierzono 2026-07-29 na 130 pomiarach). Szczegóły dla poszczególnych ciał poniżej
• Niezależny test z zewnętrznym benchmarkiem (RoxyAPI, vs NASA JPL Horizons DE441): 210 z 210 w granicach tolerancji, mediana 0.11", maksimum 0.60"
• Kuspisy domów Placidus: 0.000" dokładne dopasowanie
• Zaćmienia: < 1 minuta vs NASA Eclipse Catalog
• Linie ACG: < 1.5 km na równiku vs swetest
• Wschód/zachód Słońca: < 10 sekund vs timeanddate.com
• VOC Księżyca, ingresy, koniunkcje planet: dokładność do ułamka sekundy

Metodologia: jak dokładnie zmierzono

Te liczby to nie szacunki, lecz wyniki testów. Skrypt bierze 10 map, rozłożonych od 1900 do 2050 roku, żąda tych samych momentów od działającego swetest CGI Astrodienst i porównuje wszystkie 13 ciał, które udostępniamy. Łącznie 130 pomiarów.

Ciało	Maksymalny dryf
Słońce, Wenus, Saturn	0.001"
Merkury	0.002"
true Node	0.004"
Mars	0.007"
Jowisz	0.009"
Księżyc	0.022"
Uran	0.083"
Pluton	0.097"
Neptun	0.223"
Chiron	0.561"
mean Apogee (Lilith)	0.000"

Mediana dla wszystkich 130 pomiarów: 0.0013".

Wcześniej na tej stronie znajdowała się ogólna obietnica ”< 0.1 arcsec”. Pomiary z 2026-07-29 wykazały, że Neptun, Pluton i Chiron jej nie spełniają, dlatego obietnica została zastąpiona rzeczywistymi liczbami. Chiron i planety zewnętrzne mają większy dryf, ponieważ ich pozycje są pobierane ze skompresowanego zestawu efemeryd, którego używa nasza kompilacja.

Możesz to odtworzyć samodzielnie: api-calc/scripts/accuracy-vs-swetest.mjs wykonuje dokładnie te zapytania i drukuje tę samą tabelę.

Sprawdź sam. Skrypt, którym zmierzono powyższe liczby, znajduje się w publicznym repozytorium na licencji MIT: astroway/astrology-accuracy-benchmark. Działa nie tylko z nami: adapter do dowolnego innego API to trzydzieści linii kodu, więc te same 130 pomiarów można uruchomić przeciwko konkurentowi i porównać. Klucz sandboxa wystarczy.

Silnik

Komponent	Wartość
Biblioteka	Swiss Ephemeris C code (aloistr/swisseph)
Wersja	upstream Astrodienst C code
Efemerydy	DE431 JPL ephemeris (przez pliki .se1)
Fallback	Moshier analytical (dla dat poza 1800-2399)
Współdzielenie kodu	Współdzielone @/core z app.astroway.info - jeden silnik, dwa transporty

Metodyka

Dokładność jest weryfikowana poprzez triangulację – porównanie z trzema niezależnymi źródłami:

1. swetest CGI (wzorzec)

Oficjalna referencyjna implementacja Swiss Ephemeris od samego Astrodienst – zespołu, który stworzył Astro.com i obsługuje miliony astrologów na całym świecie. Najbardziej autorytatywne publiczne źródło. Nasz silnik jest identyczny (0.00–0.07 sekundy kątowej dryfu).

2. Kerykeion (Python)

Niezależna biblioteka Python wykorzystująca pyswisseph-bindings, niezależne od naszej kompilacji. Potwierdza, że nasza warstwa opakowująca nie zniekształca danych.

3. Prokerala API

Zdalne API Swiss Ephemeris (syderyczny Lahiri). Systemowy dryf 8–17 sekund kątowych jest związany z różnymi wersjami formuły ayanamsy Lahiri, a nie z dokładnością silnika.

Wyniki triangulacji

Mapa	vs swetest (Astrodienst)	vs Kerykeion (Python)	vs Prokerala API
Monroe 1926	0.00”	0.19”	16.95” (systemowy)
Diana 1961	0.00”	0.69”	8.18” (systemowy)
Einstein 1879	0.07”	artefakt LMT Kerykeion	14.96” (systemowy)

Niezależna weryfikacja zewnętrznym narzędziem

RoxyAPI publikuje własny benchmark przeciwko NASA JPL Horizons DE441: licencja MIT, tylko standardowa biblioteka, 21 map i 210 pozycji, oraz flaga --base-url, aby skierować go na dowolne inne API. W ich README jest wyraźnie napisane, że tolerancje celowo nie były dostosowywane do ich własnego silnika, ponieważ benchmark, który proponuje sprawdzenie konkurenta, musi być uczciwy.

Skierowaliśmy go na siebie, nie zmieniając w ich kodzie żadnej liczby. Adapter zmienia nazwę jednego pola zapytania i usuwa jedno opakowanie odpowiedzi.

	AstroWay	RoxyAPI, ich test 2026-09-29
W granicach tolerancji	210 z 210	210 z 210
Mediana odchylenia	0.11"	0.05"
Maksimum	0.60"	0.78"

Nasz pomiar 2026-09-09, koszt 21 zapytań do API. RoxyAPI we wrześniu przeszło na bezpośredni odczyt DE440, i ich mediana jest teraz niższa niż nasza; nasze maksimum jest niższe niż ich. Sekwencyjny wynik wszystkich 210 wierszy: CSV.

Zestaw regresji na poziomie endpointów

Każdy z podstawowych endpointów obliczeniowych jest objęty zamrożonymi testami snapshot na 3 referencyjnych mapach (Monroe / Diana / Einstein) = 873 snapshotów.

Zestaw snapshotów wychwytuje:

• Błędy mapowania danych wejściowych: nieprawidłowe ID planety, UT, system domów
• Post-processing: zaokrąglanie, konwersja jednostek, utrata znaku
• Rozbieżność domyślnych wartości: mean vs true node, geocentric vs topocentric
• Schema drift: walidacja przepuściła nieprawidłową formę
• Przestarzałe wdrożenie: dystrybucja produkcyjna nie odpowiada kodowi

Tolerancja: 5e-5° (≈0.18 sekundy kątowej) domyślnie dla wszystkich pól numerycznych.

Szczegółowe benchmarki

Pozycje planet (tropikalne, vs swetest)

Mapa	Data	Maksymalny dryf
Marilyn Monroe	1926-06-01	0.00”
Princess Diana	1961-07-01	0.00”
Albert Einstein	1879-03-14	0.07”

Kuspisy domów Placidus (vs swetest)

Mapa	dryf ASC	dryf MC	Maksymalny dryf kuspisu
Monroe	0.000”	0.000”	0.000”
Diana	0.000”	0.000”	0.000”

Zaćmienia (vs NASA 5-Millennium Catalog)

Wydarzenie	Maksimum NASA	Nasze maksimum	Dryf
2025-03-14 Całkowite zaćmienie Księżyca	06:58 UT	06:58 UT	0.8 min
2025-03-29 Częściowe zaćmienie Słońca	10:47 UT	10:47 UT	0.5 min
2025-09-07 Całkowite zaćmienie Księżyca	18:11 UT	18:11 UT	0.8 min
2025-09-21 Częściowe zaćmienie Słońca	19:41 UT	19:42 UT	1.0 min

Astrokartografia (vs formuła RA ze swetest)

Linie MC i IC są konstruowane według formuły longitude = RA − GMST (standard Kenneth Bowser). Dryf od wzorca: < 1.5 km na równiku dla wszystkich planet.

Linie horyzontalne ASC i DSC są obliczane z równania horyzontu w tych samych współrzędnych równikowych: cos H = -tan φ · tan δ, gdzie H = (GMST + lng) − RA. Połowy różnią się znakiem kąta godzinnego: przy H < 0 ciało jest na wschód od południka, czyli wschodzi. Weryfikacja, którą przeprowadzamy przy każdym uruchomieniu: bierze się każdy punkt każdej krzywej horyzontalnej i oblicza wysokość ciała nad horyzontem w tym punkcie. Na 8419 punktach maksymalne odchylenie wynosi 0.0 km, co oznacza, że ciało rzeczywiście znajduje się na horyzoncie wszędzie tam, gdzie narysowaliśmy linię.

Poprawiono 2026-08-12: do tej daty ASC i DSC były podpisane odwrotnie

Do 2026-08-12 krzywe horyzontalne rozwiązywały inne równanie (“ta długość ekliptyczna na ascendencie”), a dwie połowy różniły się odwróconym testem, dlatego ASC znajdował się tam, gdzie ciało zachodzi. MC i IC nigdy nie były dotknięte.

Druga, mniej zauważalna część tego samego błędu: stare równanie ignorowało szerokość ekliptyczną ciała, dlatego linia odchylała się proporcjonalnie do niej, w przybliżeniu o 103 km na każdy stopień szerokości. Na mapie Marilyn Monroe to 0 km dla Słońca i węzłów, 22 km dla Merkurego, 161 dla Plutona, 285 dla Księżyca, 345 dla Lilith. Na mapach, gdzie ciało znajduje się wysoko nad ekliptyką, odchylenie sięgało ponad 1500 km.

Co to oznacza dla twojego kodu. Jeśli obchodziłeś poprzedni błąd, zamieniając ASC i DSC miejscami u siebie, usuń ten obejście. Jeśli czytałeś pole knownDefect, nie ma go już w odpowiedziach. Współrzędne linii horyzontalnych dla ciał z zauważalną szerokością ekliptyczną zmieniły się, dlatego buforowane mapy warto przebudować.

Wschód / Zachód Słońca (vs timeanddate.com)

Lokalizacja	Data	Parametr	Dryf
London	2026-04-15	Wschód Słońca	0.6 s
London	2026-04-15	Zachód Słońca	9 s

Lokalizacje polarne (|lat| > 66.5°) automatycznie zwracają polarState + ostrzeżenie, że zwykłe godziny planetarne nie są zdefiniowane.

Orbisy aspektów

AstroWay używa zmiennych orbisów per-planet (zasada MIN dwóch planet), jak w ZET9 i astro.com. Domyślne orbisy (dla mapy natalnej):

Aspekt	Słońce	Księżyc	Wewnętrzne	Jowisz	Zewnętrzne
Koniunkcja	12°	10°	5°	8°	5°
Sekstyl	6.5°	6°	5°	5°	5°
Kwadrat	10°	8°	5°	7°	5°
Trygon	12°	8°	5°	5°	5°
Opozycja	12°	10°	5°	8°	5°

Aspekty mniejsze (36°, 40°, 45°, 72°, 108°, 135°, 144°) są domyślnie wyłączone. Włączane są jawnie poprzez ALL_ASPECTS.

Szerokości polarne

Dla |lat| > 66.5° systemy Placidus / Koch / Regiomontanus są matematycznie nie zdefiniowane. W takich przypadkach Swiss Ephemeris automatycznie zwraca Porphyry, a nasze API dodaje ostrzeżenie:

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

Ciągła weryfikacja

Regresja jest sprawdzana przy każdym PR poprzez CI:

• api-calc/tests/endpoints/: 873 snapshotów przeciwko mapom referencyjnym (Monroe / Diana / Einstein) + synastry / composite / davison
• .github/workflows/api-accuracy.yml: automatyczne uruchamianie przy PR
• Triangulacja przeciwko swetest CGI + Kerykeion: co tydzień
• Monitorowanie upstream Swiss Ephemeris poprzez Dependabot

Niezawodność MCP: typizowany wynik

Dokładność silnika to połowa zaufania. Druga połowa to kontrakt wyjściowy, który agent (Claude, ChatGPT, Cursor) może walidować. Nasz serwer MCP nie zwraca “surowego tekstu, radź sobie sam”:

• Typizowany structuredContent. Ponad 600 narzędzi MCP, a zdecydowana większość z nich publikuje ścisły outputSchema – klient MCP otrzymuje zweryfikowaną strukturę, a nie ciąg znaków, który trzeba parsować na chybił trafił.
• Ochrona przed schema drift. Test CI openapi-example-drift waliduje każdy snapshot regresji przeciwko schematowi, wygenerowanemu z jego własnego przykładu: jeśli rzeczywisty wynik endpointu rozejdzie się z opublikowanym schematem, kompilacja zakończy się błędem. To właśnie ta klasa rozbieżności powoduje błąd MCP -32602 Output validation error.
• Błędy: to błędy. Awaria narzędzia zawsze zwracana jest z flagą isError i typizowanym kodem (UPPER_SNAKE). My nigdy nie przekazujemy modelowi surowego stack trace’u ani wewnętrznych ścieżek serwera jako “danych”.

Oznacza to, że integracja poprzez MCP jest tak samo przewidywalna, jak bezpośrednie wywołanie REST: to, co jest opisane w /openapi.json, jest tym, co zwraca narzędzie.

Znane ograniczenia

• Daty poza zakresem (przed 1800 i po 2399): używany jest Moshier analytical, dokładność ~0.1” (vs < 0.01” dla SWIEPH z plikami DE431)
• True Lilith (id=13) vs Mean Lilith (id=12): różnica do 12° – domyślnie Mean Lilith (stabilne zachowanie), True Lilith dostępna poprzez planetIds: [13]
• Topocentric vs geocentric: domyślnie geocentric

Referencje

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

Kontakt

W sprawie pytań dotyczących dokładności: napisz na support@astroway.info z danymi mapy i oczekiwanym wzorcem (astro.com lub inne autorytatywne źródło).