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

Vedic FAQ

Hier sind Fragen gesammelt, die bei der Integration der vedischen Endpunkte häufig aufkommen. Wenn du keine Antwort findest, schreib an hello@astroway.info, wir ergänzen sie.

Welche Ayanamsas werden unterstützt? Welche soll ich wählen?

Abschnitt betitelt „Welche Ayanamsas werden unterstützt? Welche soll ich wählen?“

Die API unterstützt 9 Ayanamsas:

CodeNameWann wählen
lahiri (default)Chitra PakshaStandard der indischen Regierung; der größte Massenmarkt. Für die meisten vedischen Apps ist es diese.
ramanB.V. RamanWenn du eine mobile App für den südindischen Markt integrierst (Karnataka, Tamil Nadu).
krishnamurti (Alias kp)KPWenn du /v1/vedic/kp/* aufrufst - KP hat ein eigenes Ayanamsa.
yukteshwarSri YukteshwarAbstand von Spica; theosophisches bzw. westlich orientiertes Publikum.
fagan-bradleyFagan/BradleyWestlich siderisch (nicht vedisch). Für Astrologen, die aus siderisch-westlichen Traditionen kommen.
de-luceDe LuceÄltere Wahl mancher Astrologen, selten.
jn-bhasinJN BhasinEine spezielle Schule, selten.
true-citraTrue Chitra PakshaSpica fest auf 0° Waage. Weicht von Lahiri um 0.01° ab, nimm es also nur, wenn du genau die Verankerung am Stern brauchst.
djwhal-khulDjwhal KhulTheosophische Schule, selten. Die größte Abweichung in der Tabelle.

Die wichtigsten Schulen liegen nah beieinander: Lahiri, True Chitra und KP bleiben innerhalb von 0.1°, Fagan/Bradley, JN Bhasin, Yukteshwar und Raman innerhalb von 1.45°. Abseits stehen De Luce (3.96° von Lahiri) und Djwhal Khul (3.82°); bei ihnen rutscht eine Position nahe der Zeichengrenze bereits ins Nachbarzeichen. Gemessen am 2026-08-18 am Mond eines einzelnen Charts; bei gradbasierten Techniken (Nakshatra-Position, Argala) ist der Unterschied schon innerhalb von 0.1° sichtbar.

Standardmäßig liefern die vedischen Endpunkte siderische Positionen (Tierkreis an den Sternen verankert, mit angewandtem Ayanamsa). Die westlichen Endpunkte (/v1/chart, /v1/synastry) liefern tropische (Tierkreis am Frühlingspunkt verankert).

Ein tropisches Vedic (ein seltener Sonderfall, den Sanjay Rath und Ernst Wilhelm vertreten) liefert die API nicht: Alle vedischen Endpunkte rechnen siderisch und ignorieren zodiacType im Request-Body. Tropische Positionen liefert der westliche Zweig (/v1/chart, /v1/synastry), und zodiacType: "sidereal" schaltet ihn auf den siderischen Tierkreis mit demselben Ayanamsa um.

SchuleRegion / ZielgruppeStärke
Parashara (BPHS)Die gesamte vedische Welt - die universelle GrundlageDas umfangreichste Methodenkorpus; hier fängt man immer an
JaiminiTamil Nadu + fortgeschrittene PraktikerVorhersagen auf Karaka-Basis; vom AK geprägte Lebensthemen
Lal KitabPunjab + NordindienEinzigartige Abhilfen (Upaya), eigene Manglik-Regeln
KP (Krishnamurti)Tamil Nadu + Andhra PradeshSub-Lord-Theorie, präzises Timing von Ereignissen

Pratyangira, AstroSage und andere große APIs bieten überwiegend Parashara. AstroWay deckt alle vier über getrennte Endpunktgruppen ab.

AshtakootDashakoota
RegionNord- und Zentralindien, Pakistan, NepalSüdindien (Tamil Nadu, Karnataka, Kerala)
Skalamax. 36 Punkte10 Kutas (Faktoren)
BestandteileVarna + Vashya + Tara + Yoni + Graha Maitri + Gana + Bhakoot + NadiDina + Gana + Mahendra + Stri-Dirgha + Yoni + Rashi + Rashyadhipati + Vashya + Rajju + Vedha
API/v1/vedic/compatibility/ashtakoot/v1/vedic/compatibility/dashakoota

Wenn dein Matchmaking-Dienst ganz Indien bedient, ruf /v1/vedic/compatibility/full auf - du bekommst beide + Manglik + Bhrigu.

Mangal Dosha = Mars im 1./2./4./7./8./12. Haus von Lagna, Mond oder Venus aus (die Schulen legen das unterschiedlich aus). In Indien ist das ein Ausschlusskriterium für die Ehe: Haben beide Partner eine Mangal-Belastung ohne Ausgleich, gibt ein traditioneller Astrologe ohne Upayas (Abhilfen) oder ausgleichende Faktoren kein grünes Licht.

API-Endpunkt: /v1/vedic/compatibility/manglik-check - liefert { chart1: { manglik: true/false, severity, factors }, chart2: ..., compensation: ... }.

D9 (Navamsha) - warum ist es der wichtigste Varga?

Abschnitt betitelt „D9 (Navamsha) - warum ist es der wichtigste Varga?“

D9 = neunfache Teilung jedes Zeichens = ein detailliertes Chart auf “Seelenebene”. Im Vedic wird es verwendet für:

  1. Vorhersagen zur Ehe: Venus + der Herrscher des 7. Hauses im D9 zeigen die wahre Natur des Ehelebens
  2. Stärke der Planeten: ein Planet, der im D1 stark, im D9 aber schwach ist = “verspricht, aber liefert nicht”
  3. Vargottama: ein Planet im selben Zeichen in D1 und D9 = besondere Stärke

API: /v1/vedic/vargas liefert alle 16 Teilungen in einem Aufruf; für Features rund um Ehe und Beziehungen konzentrierst du dich auf D9.

Warum ist die Geburtszeit entscheidend? Was tun, wenn sie unbekannt ist?

Abschnitt betitelt „Warum ist die Geburtszeit entscheidend? Was tun, wenn sie unbekannt ist?“

Vedic ist sehr zeitempfindlich:

  • Lagna (Aszendent) wechselt etwa alle 2 Stunden: Dann verschiebt sich das GANZE Chart
  • Das Nakshatra des Mondes wechselt alle 6–8 Stunden
  • Die Dasha-Balance (Anfangsperiode) hängt von der Nakshatra-Position des Mondes ab

Wenn die genaue Zeit unbekannt ist:

  1. Sunrise Chart: Nimm die Zeit des Sonnenaufgangs am Geburtsort als Näherung. Die Sonne steht dann auf dem Aszendenten, sodass Lagna ungefähr dem Sonnenzeichen entspricht; manche vedischen Astrologen halten Sunrise Charts für eine Prognose allgemeiner Tendenzen für gültig
  2. Rektifikation: Ruf /v1/rectification mit 2-3 bekannten Lebensereignissen auf (Heirat, Kind, Jobwechsel) - die API liefert ein wahrscheinliches Zeitfenster für die Geburt
  3. Hinweis an den Nutzer: Teile mit, dass Ergebnisse bei unbekannter Zeit eine Näherung sind, kein genaues Chart

Vedic verwendet traditionell Whole Sign Houses (ein ganzes Zeichen = ein Haus). Western nutzt Placidus / Koch / Equal usw.

Der Standard von AstroWay für Vedic = Whole Sign. Für die KP-Endpunkte Placidus (KP-Konvention). Übergib den Parameter houseSystem, wenn du etwas anderes brauchst: whole-sign, placidus, koch, equal, porphyry.

Kann ich Vedic + Western in einer App kombinieren?

Abschnitt betitelt „Kann ich Vedic + Western in einer App kombinieren?“

Ja - für Zielgruppen mehrerer Traditionen ist das sogar empfehlenswert. Architektur:

  1. Das Geburtshoroskop wird einmal berechnet: Western- und Vedic-Endpunkte teilen denselben Input (date/time/lat/lon)
  2. Zeig in deiner UI einen Umschalter “Western view” / “Vedic view”
  3. Das vedische Mondzeichen (Rashi) wird oft mit dem westlichen Sonnenzeichen verwechselt: Weise den Nutzer auf den Unterschied hin
  4. Kompatibilität: Du kannst BEIDES zeigen: Western-Synastrie + Vedic Ashtakoot gleichzeitig

Der API-Endpunkt /v1/compat/astro-vedic macht das automatisch - eine Brücke Western-Synastrie × Vedic Ashtakoot.

Welche Ephemeride wird verwendet? Wie genau ist sie?

Abschnitt betitelt „Welche Ephemeride wird verwendet? Wie genau ist sie?“

Swiss Ephemeris (LGPL) - dieselbe wie in Solar Fire, Kepler, Astro Gold, Janus, AstroSeek. Genauigkeit:

  • Planetenpositionen: ±1 Bogensekunde gegenüber der NASA-JPL-Ephemeride
  • Häuserspitzen: ±1 Bogenminute
  • Ayanamsa: Lahiri-Tabelle gegen die offiziellen Tabellen der indischen Regierung abgeglichen

Die vedisch-spezifischen Berechnungen (Nakshatra-Position, Vimshottari-Balance, Vargas) sind gegen PyJHora gegengeprüft (die De-facto-Referenz in Python); Abweichungen, wo es sie gibt, liegen unter 0.01°. Der Bericht zu den Abweichungen steht in docs/AUDIT-TRAIL.md im Repo.

Ja - die meisten vedischen Endpunkte sind bei gleichem Chart-Input deterministisch. Ein stabiler Cache-Key: hash(date + time + lat + lon + ayanamsa + endpoint).

Die API bietet außerdem den Header X-Idempotency-Key - einen 5-Minuten-Cache auf der Serverseite. Bei einem Cache-Hit werden keine Credits abgebucht.

Wie werden die Texte in den Antworten lokalisiert?

Abschnitt betitelt „Wie werden die Texte in den Antworten lokalisiert?“

Vedische Endpunkte, die Deutungen liefern (yoga descriptions, dosha meanings, muhurat reasons), akzeptieren den Parameter lang. Unterstützt: 20 Sprachen (T0 - uk/en/de/ru manuell; T1 - pl/es/pt/hi/fr/ko AI Beta; T2/T3 - geplant). Details: /languages/.

Liefert ein Endpunkt numerische Daten (degrees, dates, sign indices), sind sie sprachneutral. Textfelder (note, meaning, manifestation) sind lokalisiert.

YELLOW = der Endpunkt funktioniert, hat aber eine von drei Eigenschaften:

  1. Schule eines einzelnen Autors (Lal Kitab, KP): keine Gegenprüfung mit anderen Schulen, weil es keine gibt
  2. Scoring- oder heuristikbasiert (compatibility 0-100, breakup-timing): eine numerische Bewertung ist von Natur aus subjektiv
  3. Inhärente Genauigkeitsgrenze (rectification, Bhrigu match): der Algorithmus hat eine prinzipielle Präzisionsuntergrenze

Sieh für den jeweiligen Endpunkt in docs/AUDIT-TRAIL.md nach - dort steht, warum YELLOW und ob es einen Weg zu GREEN gibt. Bei den meisten nicht (inhärent), und das ist ein ehrlicher Hinweis für den Integrator.

Hilfreich?
Änderung vorschlagen

Zuletzt aktualisiert: