Skip to main content

Integração DASA - DSS (parte 1)

DASA UTM

📌 Descrição

Fornecer ao DASA capacidade de acessar entidades UTM através de um serviço intermediário entre o mapa e o ECO-UTM, o que torna o DASA capaz de mostrar as regiões de intenção operacional (OIRs) e restrições (Constraints) com filtros avançados e detalhes via popup.

O serviço deve fornecer endpoints que interagem com o DSS para obter e processar as informações do ECO-UTM.

⏳ Estimativas

  • Desenvolvimento do backend: Médio-Alto (5-7 dias)
  • Integração com DSS: Médio-Alto (5-7 dias)
  • Testes unitários e de integração: Médio (3-4 dias)
  • Revisão e ajustes após feedback do frontend: Baixo-Médio (2-3 dias)
  • Total estimado: ~3 a 4 semanas

🔗 Depende'les

  • Time de frontend: para validar a estrutura dos endpoints e a forma como os dados serão consumidos.
  • DSS: serviço responsável por fornecer os dados das regiões e restrições.

📝 DetalhesDefinições técnicas

  • Formato dosde dados geoespaciais: utilizargeoespacial: GeoJSON
    • para
  • Estratégia representaçde atualização dosde polígonosdados: no frontend.polling
  • Desempenho: implementar cache e paginação (REDIS) nos endpoints para evitar sobrecarga ao DSS.
  • Autenticação: JWT verificar se os endpoints exigem autenticação para acessar os dados.
  • Tolerância a falhas: garantir que, caso o DSS esteja temporariamente indisponível, o sistema não quebre e forneça um fallback adequado.

📜 Tarefas

1️⃣1. Configuração do ambiente (1 ponto)

  • Criar aprojeto FastAPI
  • Configurar ambiente de desenvolvimento e dependências
  • Implementar estrutura dosbásica endpointsdo no FastAPI

    projeto
    • /api/regions/oirs → Retorna OIRs com filtros aplicáveis
    • /api/regions/constraints → Retorna Constraints com filtros aplicáveis
    • /api/regions/details/{id} → Retorna detalhes de um OIR ou Constraint específico

2️⃣2. Modelar os dados

  • Criar modelos Pydantic para OIRs e Constraints
  • Adaptar a resposta do DSS para os modelos internos

3️⃣3. Desenvolvimento da interface com o DSS (2 pontos)

  • Implementar cliente para comunicação com o DSS
  • Desenvolver métodos para busca de OIRs e Constraints
  • Tratar erros de comunicação com o DSS

4. Implementar os filtros nos endpoints

  • Horário/Duração
  • Provedor responsável
  • Altitude
  • Tipo de operação (VLOS, EVLOS, BVLOS)

4️⃣5. Implementação do popup de detalhes

  • OIR: nome do provedor, horário, coordenadas, altitude, contato de emergência
  • Constraint: nome do responsável, tipo (FRZ, temporária, altitude), duração, altitude 

5️⃣ Conectar com DSS e processar os dados

  • Implementar chamadas assíncronas ao DSS
  • Tratar erros de comunicação com o DSS

6️⃣6. Implementar testes unitários e de integração

  • Testar filtros e respostas
  • Simular falhas no DSS e validar comportamento

7️⃣7. Documentação e OpenAPI

  • Documentar endpoints usando FastAPI + Swagger
  • Compartilhar exemplos de uso para o frontend

✅ Critérios de Aceitação

  1. Todos os endpoints devem estar documentados via Swagger
  2. O sistema deve retornar dados geoespaciais em formato compatível exigido pela equipe de frontend
  3. O sistema deve lidar adequadamente com falhas de comunicação com o DSS
  4. Os filtros devem funcionar em combinação (AND lógico)
  5. Os popups devem conter todas as informações especificadas na descrição
  6. Garantir que, caso o DSS esteja temporariamente indisponível, o sistema não quebre e forneça um fallback adequado.

💀 Nível de prioridade

  • Sim
Back to top