RS-Visao-Real

As enchentes de maio de 2024 no Rio Grande do Sul expuseram um problema que quem trabalha com dados conhece bem: a imagem de satélite existe, o mapa existe, mas entre o dado bruto e uma decisão de campo ficam horas de trabalho manual. O nome e os tópicos deste repositório (satellite-imagery, gis, emergency-response, rio-grande-do-sul) apontam para esse espaço: transformar imagem em leitura objetiva do que está acontecendo no território.

Quero ser direto sobre o estado atual. O README descreve o tipo do projeto (arquitetura de referência), a stack (Python), como montar o ambiente e a estrutura src/ e tests/. Ele não documenta pipeline de processamento, fonte de imagem, formato de saída nem API. Este guia não vai inventar essas partes.

O que dá para afirmar com segurança é o contrato de engenharia: ambiente isolado em venv, dependências declaradas em requirements.txt, código separado de teste e uma esteira de CI herdada de um repositório central.

Por que isso importa: em resposta a emergência, o código que sobrevive não é o mais esperto, é o que outra pessoa consegue rodar às duas da manhã sem precisar falar comigo. Um esqueleto previsível vale mais que uma demo brilhante que só roda na minha máquina.

A estrutura é deliberadamente mínima:

src/
tests/
requirements.txt

src/: onde mora o código do projeto. Separar o código de produção num diretório próprio evita o erro clássico de importar o módulo local em vez do instalado e mascarar bug de empacotamento.

tests/: testes isolados do código. Em projeto geoespacial isso pesa mais que o normal: uma mudança de projeção cartográfica ou de ordem de coordenadas (latitude/longitude contra longitude/latitude) não quebra nada em tempo de execução, só desloca o resultado no mapa. Teste é o único lugar onde esse tipo de erro silencioso aparece.

requirements.txt: a lista de dependências. Abra esse arquivo antes de assumir qualquer biblioteca. O ecossistema geoespacial em Python é rico, mas não afirmo aqui quais bibliotecas este repositório usa: quem decide é o arquivo, não o guia.

A escolha de Python não é acidental para esse domínio. É a linguagem em que a maior parte das ferramentas de sensoriamento remoto e análise espacial tem binding maduro, e é a que analista de geoprocessamento já lê. Num cenário de emergência, isso reduz o tempo entre alguém novo chegar e alguém novo contribuir.

Este repositório não define a própria esteira. Ele segue as convenções de fernandofatech/platform, e isso é uma decisão de manutenção, não de preguiça.

Branch: <tipo>/<escopo>, com feat/, fix/, chore/ ou docs/.

Commit e título de PR: Conventional Commits. O pr-lint barra o que não segue o formato.

Versão: sai dos commits. Ninguém escreve número de versão à mão, então não existe o PR que esquece de subir a versão nem o que sobe duas vezes.

Pipeline: pr-lint, CI, segurança e release vêm de workflows reutilizáveis. Corrigir a régua é mudar um arquivo lá, não aqui.

O custo de manter CI não é escrever o primeiro YAML, é manter dezenas de cópias alinhadas por anos. Com vários repositórios de referência no portfólio, cada um com sua própria esteira, uma correção de segurança no scanner viraria dezenas de PRs quase idênticos. Centralizar troca isso por uma mudança só. O trade-off é real: quem clona este repositório sozinho não vê a definição da esteira localmente e precisa ir ao platform para entender por que um PR foi recusado.