Aller au contenu
AstroWay/api v2.102.11 · fr
tous les systèmes sont opérationnels

Précision des calculs

L’API AstroWay utilise Swiss Ephemeris (le code C officiel d’Astrodienst, les créateurs d’astro.com) — le même moteur sur lequel les astrologues professionnels travaillent depuis plus de 30 ans avec Solar Fire ($495), Kepler ($995), Astro Gold ($29.99/mois) et Janus. Nous l’avons compilé en WebAssembly et l’avons exposé via une couche REST, sans frais intermédiaires. Chaque endpoint de calcul de base est couvert par des tests de régression snapshot ; la précision du moteur est vérifiée par triangulation avec trois sources indépendantes + contre le NASA 5-Millennium Eclipse Catalog :

  • Positions planétaires : < 0,1 seconde d'arc vs le CGI swetest officiel d’Astrodienst
  • Cuspides des maisons Placidus : 0,000" correspondance exacte
  • Éclipses : < 1 minute vs le catalogue d’éclipses de la NASA
  • Lignes ACG : < 1,5 km à l’équateur vs swetest
  • Lever/coucher du Soleil : < 10 secondes vs timeanddate.com
  • VOC de la Lune, ingressions, conjonctions planétaires : précision à la fraction de seconde
ComposantValeur
BibliothèqueCode C Swiss Ephemeris (aloistr/swisseph)
VersionCode C amont d’Astrodienst
Bindingsswisseph-wasm (WebAssembly dans Node.js)
ÉphéméridesÉphémérides JPL DE431 (via fichiers .se1)
FallbackAnalytique Moshier (pour les dates hors 1800-2399)
Partage de codePartagé @/core avec app.astroway.info — un seul moteur, deux transports

La précision est vérifiée par triangulation — comparaison avec trois sources indépendantes :

L’implémentation de référence officielle de Swiss Ephemeris d’Astrodienst — les commandes qui ont créé Astro.com et qui dessert des millions d’astrologues dans le monde entier. La source publique la plus autoritaire. Notre moteur est identique (dérive de 0,00 à 0,07 seconde d’arc).

Une bibliothèque Python indépendante utilise les bindings pyswisseph au lieu de notre WASM. Elle confirme que notre couche WASM ne déforme pas les données.

Une API Swiss Ephemeris à distance (ayanamsa sidéral Lahiri). Une dérive systémique de 8 à 17 secondes d’arc est liée aux différentes versions de la formule d’ayanamsa de Lahiri, et pas à la précision du moteur.

Cartevs swetest (Astrodienst)vs Kerykeion (Python)vs API Prokerala
Monroe 19260,00”0,19”16,95” (systémique)
Diana 19610,00”0,69”8,18” (systémique)
Einstein 18790,07”Artefact LMT de Kerykeion14,96” (systémique)

Chaque endpoint de calcul de base est couvert par des tests snapshot figés sur 3 cartes de référence (Monroe / Diana / Einstein) = 818 snapshots.

La suite de snapshots détecte :

  • Les bugs de mappage des données d’entrée — mauvais id de planète, UT, système de maisons
  • Le post-traitement — arrondi, conversion d’unités, perte de signe
  • Les divergences par défaut — nœud moyen vs vrai, géocentrique vs topocentrique
  • Les décalages de schéma — la validation a laissé passer une mauvaise forme
  • Les déploiements obsolètes — la dist prod ne correspond pas au code

Tolérance : 5e-5° (≈0,18 seconde d’arc) par défaut pour tous les champs numériques.

CarteDateDérive maximale
Marilyn Monroe1926-06-010,00”
Princesse Diana1961-07-010,00”
Albert Einstein1879-03-140,07”
Cartedérive ASCdérive MCDérive maximale de cuspide
Monroe0,000”0,000”0,000”
Diana0,000”0,000”0,000”
ÉvénementMaximum NASANotre maximumDérive
Éclipse lunaire totale 2025-03-1406:58 UT06:58 UT0,8 min
Éclipse solaire partielle 2025-03-2910:47 UT10:47 UT0,5 min
Éclipse lunaire totale 2025-09-0718:11 UT18:11 UT0,8 min
Éclipse solaire partielle 2025-09-2119:41 UT19:42 UT1,0 min

Toutes les lignes MC/IC/ASC/DSC utilisent la bonne formule longitude = RA − GMST (standard Kenneth Bowser). Dérive par rapport à la référence : < 1,5 km à l’équateur pour toutes les planètes.

LieuDateParamètreDérive
Londres2026-04-15Lever du Soleil0,6 s
Londres2026-04-15Coucher du Soleil9 s

Lieux polaires (|lat| > 66,5°) renvoient automatiquement polarState + un avertissement indiquant que les heures planétaires classiques ne sont pas définies.

AstroWay utilise des orbites variables par planète (règle MIN de deux planètes), comme dans ZET9 et astro.com. Les orbites par défaut (pour une carte natale) :

AspectSoleilLunePlanètes intérieuresJupiterPlanètes extérieures
Conjonction12°10°
Sextile6,5°
Carré10°
Trine12°
Opposition12°10°

Les aspects mineurs (36°, 40°, 45°, 72°, 108°, 135°, 144°) sont désactivés par défaut. Ils s’activent explicitement via ALL_ASPECTS.

Pour |lat| > 66,5°, les systèmes Placidus / Koch / Regiomontanus ne sont pas mathématiquement définis. Dans ces cas, Swiss Ephemeris renvoie automatiquement Porphyry, et notre API ajoute un avertissement :

{
"system": "P",
"warning": "Le système Placidus n'est pas défini pour lat=68,96° (> 66,5°). Swiss Ephemeris a substitué Porphyry..."
}

La régression est vérifiée à chaque PR via CI :

  • api-calc/tests/endpoints/ — 818 snapshots contre les cartes de référence (Monroe / Diana / Einstein) + synastrie / composite / Davison
  • .github/workflows/api-accuracy.yml — exécution automatique sur PR
  • Triangulation vs swetest CGI + Kerykeion — chaque semaine
  • Surveillance de Swiss Ephemeris amont via Dependabot
  • Dates hors plage (avant 1800 et après 2399) : utilisation de l’analytique Moshier, précision ~0,1” (contre < 0,01” pour SWIEPH avec les fichiers DE431)
  • Lilith vrai (id=13) vs Lilith moyen (id=12) : différence jusqu’à 12° — par défaut Lilith moyen (comportement stable), Lilith vrai disponible via planetIds: [13]
  • Topocentrique vs géocentrique : géocentrique par défaut

Pour toute question sur la précision : écris à support@astroway.info avec les données de ta carte et la référence attendue (astro.com ou autre source autoritaire).

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

Dernière mise à jour :