Pendente makefile e revisao jurisdications

Para requisitos makefile ver issue da Colombia... Antes porém, fechar modelo de dados global:

Dados: todos os dados do país no país, e sem redundância.

Os dados gerais do país precisam ser inclusos num arquivo raiz /data/conf.yaml do país.
Como estará na raiz não precisa por exemplo repetir coluna jurisd_base_id... Mas sem extremos, pode manter p. ex. o isolabel_ext repetindo o prefixo.

Makefiles: opção de standalone orientado à comunidade do país.

decidir se makefile e scripts SQL de jurisdição ficam aqui no projeto Preserv ou no projeto WS.. Ideal é ficar aqui, mas precisa ajustar.
jurisdições locais podem ser recriadas no PostgreSQL com makefile local.
A volta (após UPDATEs de normalização por exemplo) precisa ser (pelo menos) devolução do PostgreSQL para o CSV via makefile local. Os UPDATEs podem ficar na pasta src local. O foco é a autonomia da comunidade do país em gerir seus dados.
todas as jurisdições recriadas no preserv

Discutir abaixo as propostas de modificação e seu impacto.

estrutura do conf.yaml da raiz
esboço dos makefiles
mudanças nos arquivos CSV vigentes

Exemplo de configuração raiz, ver preserv-BR/conf.yaml

Para detectar o fuso

Cobertura Grid UTM do Brasil, sem mar territorial:

               18L, 18M,
               19L, 19M, 19N,
          20K, 20L, 20M, 20N,
     21J, 21K, 21L, 21M, 21N,
22H, 22J, 22K, 22L, 22M, 22N, 
          23K, 23L, 23M,
          24K, 24L, 24M,
          25K, 25L

SELECT srid, auth_name, substr(srtext,1,45)||' ...' srtext_clues
FROM spatial_ref_sys
WHERE (srtext ilike '%SIRGAS%2000%UTM%zone%' OR srtext ilike '%WGS%84%UTM%zone%')
      AND srtext~'(18|19|20|21|22|23|24|25)'
ORDER BY 3;

Projeções oficiais rotuladas como "WGS 84 / UTM zone"
18➔32618, 19➔32619, 20➔32620, 21➔32621, 22➔32622, 23➔32623, 24➔32624, 25➔32625

Projeções oficiais rotuladas como "SIRGAS 2000 / UTM zone"
18➔31972, 19➔31973, 20➔31974, 21➔31975, 22➔31976, 23➔6210, 24➔6211, 25➔31985

Usando SIRGAS, supondo indiferença entre N e S:

{"18L": 31972, "18M": 31972, "19L": 31973, "19M": 31973,
 "20K": 31974, "20L": 31974, "20M": 31974, "20N":31974,
 "21J": 31975, "21K": 31975, "21L": 31975, "21M": 31975, "21N": 31975,
 "22H": 31976, "22J": 31976, "22K": 31976, "22L": 31976, "22M":31976, "22N":31976,
 "23K": 6210, "23L": 6210, "23M":6210,
 "24K": 6211, "24L": 6211, "24M":6211,
 "25K": 31985, "25L": 31985
}

Função de convesão LatLong para UTM grid: longitude-vertical zones vs latitude-horizontal bands,

UTM zones are numbered (UTM Zone Number) from 1 to 60 starting from 180° longitude at the International Date Line and proceeding eastward. Each zone is 6° longitude wide. Therefore Zone 1 lies between 180°W to 174°W longitude lines, Zone 2 is between 174°W and 168°W longitude lines, and Zone 60 lies between 174°E and 180° (International Date Line) longitude lines. Ver também Wikipedia/UTM Zone.
Each zone is divided into horizontal bands, 8° of latitude wide. The 20 bands are labeled with letters (UTM Zone Designators), beginning with C and ending with X from south to north. Letters I and O are omitted to prevent confusion. Note that letter N designates the first latitude band above the equator (so any letter after N refers to northern hemisphere and any N refers to a southern). Ver também Wikipedia/UTM Latitude bands.

Overlap problem: somente entre UTM zones (as UTM bands dentro de uma zona não apresentam problema de sobreposição).

digital-guard / preserv

Pendente makefile e revisao jurisdications #118

Para detectar o fuso