Sari la conținut
AstroWay/api v2.254.12 · ro
toate sistemele sunt în stare normală

Vedic FAQ

Am adunat întrebările care apar des la integrarea endpoint-urilor vedice. Dacă nu ai găsit răspunsul, scrie-ne la hello@astroway.info și îl adăugăm.

Ce ayanamsha sunt suportate? Pe care s-o aleg?

Section titled “Ce ayanamsha sunt suportate? Pe care s-o aleg?”

API-ul suportă 9 ayanamsha:

CodNumeCând o alegi
lahiri (default)Chitra PakshaStandardul guvernului indian; cea mai mare piață de masă. Pentru majoritatea aplicațiilor vedice, aceasta este.
ramanB.V. RamanDacă integrezi o aplicație mobilă pentru piața din sudul Indiei (Karnataka, Tamil Nadu).
krishnamurti (alias kp)KPDacă apelezi /v1/vedic/kp/* - KP are propria ayanamsha.
yukteshwarSri YukteshwarDistanța față de Spica; public teozofic / cu înclinație occidentală.
fagan-bradleyFagan/BradleySideral occidental (nu vedic). Pentru astrologii care vin din tradițiile siderale occidentale.
de-luceDe LuceO alegere mai veche a astrologilor, rară.
jn-bhasinJN BhasinȘcoală specifică, rară.
true-citraTrue Chitra PakshaSpica fixată strict la 0° Balanță. Diferă de Lahiri cu 0.01°, deci alege-o doar dacă ai nevoie exact de ancorarea în stea.
djwhal-khulDjwhal KhulȘcoală teozofică, rară. Cea mai mare abatere din tabel.

Școlile principale diferă puțin: Lahiri, True Chitra și KP rămân în limita a 0.1°, Fagan/Bradley, JN Bhasin, Yukteshwar și Raman - până la 1.45°. Separat stau De Luce (3.96° față de Lahiri) și Djwhal Khul (3.82°), iar cu ele o poziție aflată aproape de granița unui semn trece deja în semnul vecin. Măsurat pe 2026-08-18 pe Luna unei singure hărți; la tehnicile bazate pe grade (poziția în Nakshatra, Argala), diferența se vede chiar și în limita a 0.1°.

Sideral sau tropical? Ce returnează API-ul?

Section titled “Sideral sau tropical? Ce returnează API-ul?”

Implicit, endpoint-urile vedice returnează poziții siderale (zodiacul legat de stele, cu ayanamsha aplicată). Endpoint-urile occidentale (/v1/chart, /v1/synastry) returnează poziții tropicale (zodiacul legat de punctul echinocțiului).

Vedicul tropical (un caz rar, propus de Sanjay Rath și Ernst Wilhelm) API-ul nu îl oferă: toate endpoint-urile vedice calculează sideral și ignoră zodiacType din corpul cererii. Pozițiile tropicale le dă ramura occidentală (/v1/chart, /v1/synastry), iar zodiacType: "sidereal" o comută pe zodiacul sideral cu aceeași ayanamsha.

ȘcoalăRegiune / PublicPunct forte
Parashara (BPHS)Întreaga lume vedică - baza universalăCel mai complet corpus de tehnici; începe mereu de aici
JaiminiTamil Nadu + practicieni avansațiPredicții bazate pe karaka; teme de viață conduse de AK
Lal KitabPunjab + nordul IndieiRemedii unice (upaya), Manglik specific
KP (Krishnamurti)Tamil Nadu + Andhra PradeshTeoria sub-lord, precizie în datarea evenimentelor

Pratyangira, AstroSage și alte API-uri mari oferă în principal Parashara. AstroWay acoperă toate patru prin grupuri separate de endpoint-uri.

Ashtakoot sau Dashakoota: pentru ce piață?

Section titled “Ashtakoot sau Dashakoota: pentru ce piață?”
AshtakootDashakoota
RegiuneNordul/centrul Indiei, Pakistan, NepalSudul Indiei (Tamil Nadu, Karnataka, Kerala)
Scalămaximum 36 de puncte10 koota (factori)
ComponenteVarna + Vashya + Tara + Yoni + Graha Maitri + Gana + Bhakoot + NadiDina + Gana + Mahendra + Stree-Deergha + Yoni + Rashi + Rashyadhipati + Vashya + Rajju + Vedha
API/v1/vedic/compatibility/ashtakoot/v1/vedic/compatibility/dashakoota

Dacă serviciul de matchmaking deservește toată India, apelează /v1/vedic/compatibility/full și primești ambele + Manglik + Bhrigu.

Mangal Dosha = Marte în casa 1/2/4/7/8/12 de la Lagna, de la Lună sau de la Venus (școlile diferite o interpretează diferit). În India este un motiv de refuz al căsătoriei: dacă ambii parteneri au afecțiune Mangal fără compensare, un astrolog tradițional nu dă undă verde fără upaya (remedii) sau factori compensatori.

Endpoint-ul API: /v1/vedic/compatibility/manglik-check - returnează { chart1: { manglik: true/false, severity, factors }, chart2: ..., compensation: ... }.

D9 (Navamsha) - de ce este cea mai importantă varga?

Section titled “D9 (Navamsha) - de ce este cea mai importantă varga?”

D9 = împărțirea fiecărui semn în 9 = o hartă detaliată “la nivelul sufletului”. În astrologia vedică se folosește pentru:

  1. Predicții despre căsătorie: Venus + stăpânul casei a 7-a în D9 arată adevărata natură a vieții conjugale
  2. Forța planetelor: o planetă puternică în D1, dar slabă în D9 = “promite, dar nu livrează”
  3. Vargottama: o planetă în același semn în D1 și D9 = forță deosebită

API: /v1/vedic/vargas returnează toate cele 16 diviziuni într-un singur apel; concentrează-te pe D9 pentru funcțiile legate de căsătorie și relații.

De ce este critică ora nașterii? Ce faci dacă nu e cunoscută?

Section titled “De ce este critică ora nașterii? Ce faci dacă nu e cunoscută?”

Astrologia vedică este foarte sensibilă la oră:

  • Lagna (Ascendentul) se schimbă la fiecare ~2 ore: se mută TOATĂ harta
  • Nakshatra Lunii se schimbă la fiecare 6–8 ore
  • Dasha-balance (perioada inițială) depinde de poziția Lunii în nakshatra

Dacă ora exactă nu este cunoscută:

  1. Hartă la răsărit: folosește ora răsăritului Soarelui în locul nașterii ca aproximare. Atunci Soarele se află pe Ascendent, deci Lagna coincide aproximativ cu semnul Soarelui; unii astrologi vedici consideră hărțile la răsărit valide pentru o prognoză a tendințelor generale
  2. Rectificare: apelează /v1/rectification cu 2-3 evenimente de viață cunoscute (căsătorie, copil, schimbare de job) - API-ul returnează o fereastră probabilă pentru ora nașterii
  3. Avertisment pentru utilizator: spune-i că rezultatele cu ora necunoscută sunt o aproximare, nu o hartă exactă

Astrologia vedică folosește tradițional case Whole Sign (tot semnul = o casă). Cea occidentală - Placidus / Koch / Equal etc.

Implicit în AstroWay pentru Vedic = Whole Sign. Pentru endpoint-urile KP - Placidus (convenția KP). Trimite parametrul houseSystem dacă ai nevoie de altceva: whole-sign, placidus, koch, equal, porphyry.

Pot combina Vedic + Western în aceeași aplicație?

Section titled “Pot combina Vedic + Western în aceeași aplicație?”

Da - și chiar este recomandat pentru publicul multi-tradiție. Arhitectura:

  1. Harta natală se calculează o singură dată: endpoint-urile Western și Vedic folosesc același input (date/time/lat/lon)
  2. Afișează un comutator “Western view” / “Vedic view” în interfața ta
  3. Semnul lunar vedic (rashi) este des confundat cu semnul solar occidental: avertizează utilizatorul despre diferență
  4. Compatibilitate: poți afișa AMBELE: Western synastry + Vedic Ashtakoot simultan

Endpoint-ul API /v1/compat/astro-vedic face asta automat - puntea Western synastry × Vedic Ashtakoot.

Ce efemeride se folosesc? Cât de precise sunt?

Section titled “Ce efemeride se folosesc? Cât de precise sunt?”

Swiss Ephemeris (LGPL) - aceleași ca în Solar Fire, Kepler, Astro Gold, Janus, AstroSeek. Precizie:

  • Pozițiile planetelor: ±1 secundă de arc față de efemeridele NASA JPL
  • Cuspidele caselor: ±1 minut de arc
  • Ayanamsha: tabelul Lahiri validat încrucișat cu tabelele oficiale ale guvernului indian

Pentru calculele specific vedice (poziția în Nakshatra, balanța Vimshottari, Varga) - verificat încrucișat cu PyJHora (referința de facto în Python); divergențele, unde există, sunt < 0.01°. Raportul divergențelor - docs/AUDIT-TRAIL.md din repo.

Da - majoritatea endpoint-urilor vedice sunt deterministe pentru același input de hartă. O cheie de cache stabilă: hash(date + time + lat + lon + ayanamsa + endpoint).

API-ul oferă și antetul X-Idempotency-Key - un cache de 5 minute pe partea api-calc. La un cache hit, creditele nu se debitează.

Cum sunt localizate textele din răspunsuri?

Section titled “Cum sunt localizate textele din răspunsuri?”

Endpoint-urile vedice care returnează interpretări (descrieri de yoga, semnificații de dosha, motive de muhurat) acceptă parametrul lang. Suport: 20 de limbi (T0 - uk/en/de/ru manual; T1 - pl/es/pt/hi/fr/ko AI Beta; T2/T3 - planificate). Detalii: /languages/.

Dacă endpoint-ul returnează date numerice (grade, date, indici de semn), acestea sunt neutre din punct de vedere lingvistic. Câmpurile text (note, meaning, manifestation) sunt localizate.

YELLOW = endpoint-ul funcționează, dar are una dintre trei caracteristici:

  1. Școală cu un singur autor (Lal Kitab, KP): nu există verificare încrucișată cu alte școli, pentru că acestea nu există
  2. Bazat pe scoring/euristici (compatibility 0-100, breakup-timing): evaluarea numerică este subiectivă prin natura ei
  3. Limită intrinsecă de precizie (rectification, Bhrigu match): algoritmul are un prag inerent de precizie

Vezi docs/AUDIT-TRAIL.md pentru endpoint-ul concret - acolo scrie de ce este YELLOW și dacă există o cale spre GREEN. Pentru majoritatea nu există (limită intrinsecă), iar acesta este un avertisment onest pentru integrator.

Util?
Sugerează o corectură

Ultima actualizare: