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.

📝 Definições técnicas

Formato de dados geoespacial: GeoJSON
Estratégia de atualização de dados: polling
Desempenho: implementar cache e paginação (REDIS) nos endpoints para evitar sobrecarga ao DSS.
Autenticação: JWT

📜 Tarefas

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

Criar projeto FastAPI
Configurar ambiente de desenvolvimento e dependências
Implementar estrutura básica do 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. Modelar os dados

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

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)

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

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

Testar filtros e respostas
Simular falhas no DSS e validar comportamento

7. Documentação e OpenAPI

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

✅ Critérios de Aceitação

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