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: 9-11 dias
Integração com DSS: 9-11 dias
Testes unitários e de integração: 7-9 dias
Revisão e ajustes após feedback do frontend: 7-9 dias
Total estimado: ~5 a 6 semanas

🔗 Depende'les

Time de frontend: para validar a estrutura dos endpoints e a forma como os dados serão consumidos.
Time de backend: para fornecer suporte ao acesso dos serviços ECO-UTM.

📝 Definições técnicas

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

📜 Tarefas

1. Configurar ambiente

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 dados

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

3. Desenvolver interface com o DSS

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. Implementar endpoint 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. Documentar

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.