Motor de cálculo

As posições vêm das efemérides planetárias da NASA JPL, os mesmos dados usados para navegar naves espaciais. São 105 MB de posições tabeladas de 500 a 2999 d.C., mais 735 estrelas fixas.

Isso importa porque a alternativa é uma conta boa o bastante para coluna de jornal, mas não para um mapa. Fórmulas de movimento médio erram por graus ao longo dos séculos. Isso aparece em um nascimento em 1890 ou 2090, e num mapa divisional deixa de ser uma resposta um pouco diferente para virar outra resposta. 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 desloca. A diferença entre os dois é o ayanamsa, hoje em torno de 24°, e não existe um valor único aceito por todos.

Por isso ele é um parâmetro. Aceitamos 48 ayanamsas (Lahiri, Raman, Krishnamurti, Fagan-Bradley, Yukteshwar, Suryasiddhanta e outros), e o Lahiri é o padrão por ser o oficial do governo indiano, e 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, sem avisar, numa discussão que não está encerrada.

299 endpoints, agrupados pelo que calculam:

O tempo mediano no servidor é de 62 ms, e 76% dos endpoints respondem em menos de 100 ms, medidos em todos os exemplos publicados numa execução local. As efemérides ficam mapeadas na memória, então o custo de um mapa é a conta, e não o acesso ao disco.

Quando uma chamada demora mais, é porque o trabalho é realmente maior: uma busca de trânsitos varre um período de datas, e um relatório em PDF junta cerca de vinte e cinco endpoints em um documento e é cobrado como uma só chamada.

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 guardar as respostas em cache, e é isso que permite que 1.783 funções de teste confiram valores exatos, e não faixas de valores.

Também quer dizer que uma divergência pode ser conferida. Se a nossa Lua e a Lua 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. Alguns desses números não significariam o que o leitor acha que significam, 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 para os quais não conseguimos chegar a uma regra. Quando um concorrente devolve um valor que não conseguimos confirmar em nenhuma fonte, o campo fica de fora e a resposta explica o motivo, em vez de trazer um palpite plausível que quem chamou a API 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 como tal.

Quando duas escolas realmente discordam e as duas têm fundamento, a resposta diz qual delas foi aplicada. Assim, o resultado pode ser conferido, e não apenas 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 código.