Motor de cálculo

As posições vêm das efemérides planetárias da NASA JPL — o mesmo conjunto de dados usado para navegar sondas espaciais. São 105 MB de posições tabeladas, de 500 a 2999 d.C., além de 735 estrelas fixas.

Isso importa porque a alternativa é uma aritmética que serve para uma coluna de jornal, mas não para um mapa. Fórmulas de movimento médio desviam alguns graus ao longo dos séculos. É num nascimento em 1890 ou 2090 que isso aparece, e é num mapa divisional que vira outra resposta, e não só uma resposta um pouco diferente. No D60, meio grau já leva um planeta para a divisão seguinte.

A astrologia védica é sideral: as posições são medidas a partir de um ponto fixo no céu, e não do equinócio, que se move. A diferença entre os dois é o ayanamsa, hoje por volta de 24°, e não existe um valor único aceito por todos.

Por isso ele é um parâmetro. A API aceita 48 ayanamsas — Lahiri, Raman, Krishnamurti, Fagan-Bradley, Yukteshwar, Suryasiddhanta e outros —, e o padrão é Lahiri por ser o padrão oficial do governo indiano, não por ser o correto.

{
  "date_time": "1990-08-15T10:30:00+05:30",
  "latitude": 26.9124,
  "longitude": 75.7873,
  "timezone_as_float": 5.5,
  "ayanamsa": "KRISHNAMURTI"
}

Dois astrólogos que discordam sobre o ayanamsa podem usar esta API e cada um recebe o mapa que espera. Uma API que fixa um único ayanamsa no código tomou partido, em silêncio, numa discussão que ainda não terminou.

299 endpoints, agrupados pelo que calculam:

O tempo mediano no servidor é de 62 ms, com 76% dos endpoints abaixo de 100 ms — medido em todos os exemplos publicados, numa execução local. As efemérides ficam mapeadas em memória, então o que pesa num mapa é a aritmética, não o disco.

Quando uma chamada demora mais, é porque o trabalho é mesmo maior: uma busca de trânsitos varre um intervalo de datas, e um relatório em PDF junta uns vinte e cinco endpoints num único documento — e é cobrado como uma chamada só.

A mesma entrada sempre devolve a mesma saída. Não há amostragem nem modelo no caminho, então um mapa calculado hoje e o mesmo mapa calculado daqui a um ano são idênticos byte a byte. É isso que permite fazer cache das respostas, e é isso que permite que 1.783 funções de teste confiram valores exatos, e não faixas.

Também significa que qualquer divergência pode ser verificada. Se a nossa Lua e a do seu software não batem, uma das duas está errada, e o ayanamsa ou o fuso horário vão mostrar qual — em vez de as duas estarem “mais ou menos certas”.

O motor consegue gerar um número para quase tudo. Mas alguns desses números não significariam o que o leitor entende, e esses endpoints não existem.

• Dívidas ancestrais do Lal Kitab. As oito dívidas têm os mesmos nomes em todas as fontes. As condições que ativam cada uma, não — só as regras publicadas para o pitra rin já dão respostas diferentes para o mesmo mapa. Não vamos publicar um veredito sobre os antepassados de alguém que dependa do livro que por acaso lemos.
• Campos sem regra que possamos derivar. Quando um concorrente devolve um valor que não conseguimos fundamentar numa fonte, o campo fica de fora e a resposta explica por quê — em vez de trazer um palpite plausível que quem chama não teria como conferir.
• Nada apresentado como aconselhamento médico, jurídico ou financeiro. Os textos de remédios são atribuições tradicionais e vêm identificados assim.

Quando duas escolas realmente discordam e as duas são defensáveis, a resposta diz qual delas aplicou — para que o resultado possa ser conferido, e não só aceito.

curl -X POST https://api.occultapi.com/api/astro/planet-positions/ \
  -H 'X-API-Key: yt_live_your_key_here' \
  -H 'Content-Type: application/json' \
  -d '{
    "date_time": "1990-08-15T10:30:00+05:30",
    "latitude": 26.9124,
    "longitude": 75.7873,
    "timezone_as_float": 5.5,
    "ayanamsa": "LAHIRI"
  }'

Ou rode no Playground, sem escrever uma linha de código.