dsp-job-geo-file-generation — Visão geral¶

Job batch do DSP que pré-gera arquivos de download territoriais (níveis 2 e 3) e publica no SeaweedFS (API S3). O backend entrega esses bytes quando existem; senão usa WFS no GeoServer Download. Orquestração: dsp-core (profile object-storage). Na demo local este job costuma ficar desligado.

Sumário¶

• Papel no DSP
• Quando entra em cena
• Fluxo de uma execução
• Coordenação com a migração
• Objetos no bucket
• Formatos e temas
• Limpeza de órfãos
• Bancos e configuração
• Execução no core
• Rodar sem o core
• Onde aprofundar

Papel no DSP¶

Reduz carga no GeoServer Download em consultas públicas de grande volume (ex.: escala consulta CAR).

Quando entra em cena¶

Fluxo de uma execução¶

flowchart LR
  dsp[(dsp-db)]
  geo[(dsp-geoserver-db)]
  job[job geo-file]
  s3[(SeaweedFS)]

  job -->|lê flags pendentes| dsp
  job -->|lê geom / atributos| geo
  job -->|grava CSV e GPKG| s3
  job -->|grava batch + limpa flags| dsp

1. Lista territórios com requires_s3_file_regeneration = true (nível 2 antes do 3).
2. Para cada território, percorre temas habilitados em downloadThemesConfig.json e os formats[] de cada tema.
3. Exporta lendo dsp-geoserver-db (paridade com WFS).
4. Publica no bucket; user-metadata generated-at (ISO UTC) — o backend usa como lastFileGenerated.
5. Só desliga a flag e grava last_generated_s3_file_at quando todos os formatos habilitados do território foram publicados. Falha parcial mantém pendente para a próxima rodada.

Se o bucket não existir, o job registra erro, não publica e termina sem derrubar o processo — flags permanecem para a próxima tentativa.

Coordenação com a migração¶

O geo-file não consulta BATCH_JOB_EXECUTION_SYNC_STATE.

Colunas no dsp-db (só níveis 2 e 3): requires_s3_file_regeneration, last_generated_s3_file_at. Detalhe: Bancos de dados — Pendências.

Objetos no bucket¶

Slug a partir de name (minúsculo, sem acento, hífens). Nível 3 inclui slug do pai (homônimos). API e flags usam id territorial.

O nome do arquivo que o cidadão baixa na UI não é a chave do objeto — o backend monta {tema}_{nível2}.{ext} na resposta HTTP.

Formatos e temas¶

• CSV: mesmo layout do WFS (FID, atributos na ordem da tabela, geometria em WKT).
• GeoPackage (.gpkg): gerado quando o tema declara gpkg em formats[]. Uma tabela de feições por arquivo, com o código do tema, geometria em the_geom (WKB). O SRID vem da camada. Sem SRID, a geometria fica no SRS geográfico indefinido do GeoPackage (srs_id 0); a coluna não aceita valor vazio. Feição sem geometria é ignorada. O backend não tem fallback WFS para esse formato.
• Novo formato: implementar GeoFileExporter e declarar em formats[] do tema — chaves e endpoints do backend permanecem.

Temas e códigos vêm de downloadThemesConfig.json (gerado pelo ./config.sh a partir do adotante).

Limpeza de órfãos¶

Ao final da execução, o job lista {formato}/level-2/ e {formato}/level-3/ no bucket e remove objetos que não correspondem a nenhum (território, tema, formato) válido — por exemplo após renomear um território.

Bancos e configuração¶

Object storage (não é JDBC):

dsp:
  object-storage:
    endpoint: http://dsp-object-storage:8333
    region: us-east-1
    bucket: dsp-geo-files
    access-key: ...
    secret-key: ...
    path-style-access: true

Arquivo de runtime: config/Job-Geo-File-Generation/application/application.yaml (gerado pelo ./config.sh a partir de environment.object_storage no adopter-config.yaml). O bucket deve existir — o job não cria.

| Stack | Java 21, Spring Boot 3.4.2, Spring Batch, PostGIS, AWS SDK v2 (S3), Maven |

Execução no core¶

Container dsp-job-geo-file-generation: sem porta HTTP; sobe junto com dsp-object-storage no adotante real.

Rodar sem o core¶

./mvnw spring-boot:run

Exige application.yaml com os três datasources, bucket acessível e dsp-geoserver-db já populado pela migração. Uso típico: via ./setup.sh do core.

Onde aprofundar¶