Pular para conteúdo

C3 — ArcGIS (fluxo dual)

Zoom no fluxo dual do ArcGIS dentro do hub. ArcGIS aparece nos dois lados:

  • Como fonte — inputs do pessoal de campo entram via Container Staging ArcGIS no BANCO STAGE (schema ARCGIS).
  • Como consumidorProjetor ArcGIS constrói um Read Model dedicado (schema ARCGIS em BANCO ARTESP) que o próprio ArcGIS lê.

Não é round-trip: o dado que entra (geometria/atributos coletados em campo) é semanticamente distinto do dado que sai (Read Model consolidado, possivelmente combinando outras fontes além do próprio ArcGIS).

Diagrama

Componentes do Container Staging ArcGIS

# Componente Tecnologia (hipótese) Responsabilidade
1 Extrator de feature classes Cliente ArcGIS REST API (Python arcgis SDK ou .NET) Pull periódico das feature classes/feature services que recebem inputs de campo. Mantém checkpoint por feature class. [B]
2 Normalizador (mínimo) Mesma stack Normaliza atributos para o schema as-is no BANCO STAGE (campos obrigatórios, tipos). Sem regra de negócio. [B]
3 Publisher Staging Driver Oracle Upsert na tabela do schema ARCGIS em BANCO STAGE. Idempotente por objectid (ou identificador composto da feature). [B]

Projetor ArcGIS

Lê de BANCO STAGE (pode combinar o schema ARCGIS com schemas de outras fontes — ex.: Kartado, KAPSCH, Ícaro) e constrói o Read Model ARCGIS em BANCO ARTESP. Esse Read Model contém as camadas geo consolidadas que o ArcGIS-consumidor renderiza.

Aspecto Decisão atual
Tecnologia a definir — Python/.NET ou Oracle PL/SQL com extensão Spatial. [?]
Cadência dispara após batch consolidado de Staging (orquestrado pelo SINCRONIZADOR). [?]
Idempotência Read Model reescrito por feature class; reprocessar é seguro. [B]
Formato de saída Tabelas Oracle Spatial ou view materializada exposta como Feature Service ArcGIS. [?]

Por que ArcGIS é fonte e consumidor

ArcGIS é a plataforma GIS usada pelas equipes de campo da Motiva. Em alguns casos o dado nasce no ArcGIS (técnico em campo registra ocorrência georreferenciada via app ArcGIS Field Maps, Survey123, etc.) — esse dado precisa entrar no hub via Container Staging, ser combinado com outras fontes pelos Projetores, e voltar como Read Model integrado.

A separação fonte ↔ consumidor no diagrama deixa esse ciclo explícito e mantém o fluxo unidirecional (não há round-trip do mesmo registro — entrou um dado bruto, sai um dado projetado).

Decisões pendentes

# Pergunta Confidence atual Onde resolver
D-A1 Quais feature classes do ArcGIS são fonte (escrita por campo) e quais são consumidoras (leitura de Read Model)? [?] Discovery com Motiva (time GIS)
D-A2 Endpoint ArcGIS é Enterprise (on-prem) ou Online (SaaS)? Define padrão (Pull-On-Prem vs Pull-SaaS). [?] Discovery
D-A3 Mecanismo de exposição do Read Model para ArcGIS consumir: Feature Service via ArcGIS Server lendo Oracle Spatial? View materializada? Sync periódico? [?] Design Authority + InfoSec
D-A4 Volume estimado (features/dia) e SLA de freshness [?] Discovery
D-A5 LGPD em feature classes que contêm dado pessoal (ex.: ocorrências envolvendo terceiros) — política [?] Cyber Motiva

Decisões transversais aplicáveis: D3 (modelo do Read Model ARCGIS), D4 (mecanismo de distribuição), D12 (tecnologia SINCRONIZADOR) — ver Apêndice D do blueprint.

Riscos críticos

  • Categorização das feature classes (D-A1) é trabalho prévio à arquitetura — sem isso, não dá pra dimensionar o Container Staging nem o Projetor.
  • Hosting indefinido (D-A2) afeta padrão de ingestão e aprovação Cyber.
  • Loop sutil: se a mesma feature class for fonte E consumidora, há risco de criar loop (input do campo vira Read Model que reescreve a feature class). Evitar — usar feature classes distintas para input vs output, ou nomear schemas/camadas explicitamente.

Referências

  • C2 (containers do hub): c2-containers.md
  • Blueprint da solução: produto/blueprint-solucao.md (no repositório, fora deste site)
  • Ficha de Discovery: tpf-motiva/docs/0-discovery/14-arcgis.md
  • Inventário §3.14: inventarios/fornecedores.md