Brazil/Oficial/Carga

From OpenStreetMap Wiki
Jump to navigation Jump to search

Avaliando-se a "tradição OSM", destacam-se duas maneiras de se obter os dados oficiais como linhas ou polígonos passíveis de comparação com os dados OSM:

  1. Carga dos "dados oficiais oficialmente distribuídos", tais como os shapes do IBGE;
  2. Transcrição das descrições oficiais (expressas em Lei), seguida de auditoria e validação da mesma pela Comunidade OSM Brasil.

Pendente revisão de processos, exemplos, etc. por isso LIXO2 (mais recente) e LIXO.

LIXO2

Usando ftp://geoftp.ibge.gov.br/cartas_e_mapas/bases_cartograficas_continuas/bc250/versao2017/postgis e com mais cuidado (ver User:Krauss/Lembretes/Oficial#Carga IBGE e problema da projeção) ftp://geoftp.ibge.gov.br/cartas_e_mapas/bases_cartograficas_continuas/bc250/versao2017/shapefile/Limites_v2017.zip

Outros lembretes e paginas relacionadas:

Instruções do IBGE na carga das areas

Transcrição do arquio de instruções

O arquivo bc250_2017-11-08.tar contém uma cópia em formato tar gerada pelo utilitário pg_dump (versão PostgreSQL 9.3.5).

Este utilitário é facilmente encontrado em máquinas onde esteja instalado o PGAdmin III 1.18.1.

É possível restaurar o dump através da interface do PGAdmin III 1.18.1 (clicando com o botão direito no banco de dados -> opção Restore) ou diretamente através do utilitário pg_restore na linha de comando do DOS.

A restauração deste dump criará um esquema chamado bc250. Se for restaurado com a opção de manter os privilégios (padrão), será atribuída a permissão de leitura a todos (public).

Recomenda-se a restauração com a opção –no-owner no pg_restore, ou Don't save the owner na interface do PG_Admin III, para evitar erros relativos ao owner.

Uma sugestão para uso do comando pg_restore na linha de comando do DOS:

pg_restore.exe --host hhhhhh --port 5432 --username uuuuuu --dbname ddddd --no-owner --password --verbose "bc250_2015-Out.backup"
  • Importante observar o caminho do comando pg_restore e do arquivo de backup
  • Substituir hhhhhh, uuuuuu, ddddd, respectivamente, pelo endereço do servidor, usuário e nome do banco de dados.

Para usuários leigos, recomenda-se utilizar a interface do PGAdmin III 1.18.1.

Rodando carga PostGIS

Segundo descritivo IBGE e Diário Oficial "Para a superfície do Brasil foi mantido o valor de 8.515.759,090 km², publicado no DOU nº 124 de 29/06/2018, conforme Resolução Nº 01, de 28 de junho de 2018". Após a carga portanto basta somar as áreas dos municípios para ver se bate com o dado oficial.

Se por acaso houver discrepância (ex. por área de grandes lagos), comparar um a um com a planilha de áreas oficiais dos municípios). Portanto vale carregar a tabela dos valores oficiais de área municipal, que atua como checksum das geometrias dos municípios, AR_BR_RG_UF_MES_MIC_MUN_2017.ods.

Carga da distribuição oficial PostGIS do IBGE:

# se ainda não existe, criar database separada:
psql postgres://postgres:_SENHA_@localhost  -c "CREATE DATABASE ibge_sandbox;"
psql postgres://postgres:_SENHA_@localhost/ibge_sandbox  -c "CREATE EXTENSION postgis; SELECT postgis_full_version();"
# show e.g. "POSTGIS 2.4.4 etc."

cd ~/sandbox/IBGE_AREA2017
wget -c ftp://geoftp.ibge.gov.br/cartas_e_mapas/bases_cartograficas_continuas/bc250/versao2017/postgis/bc250_2017-11-08.tar

pg_restore --host localhost --port 5432 --username postgres --dbname ibge_sandbox --no-owner --password --verbose "bc250_2017-11-08.tar"

Mensagens do pg_restore:

pg_restore: creating SCHEMA "bc250"
pg_restore: creating TABLE "bc250.asb_cemiterio_p"
pg_restore: creating TABLE "bc250.asb_dep_abast_agua_p"
...
pg_restore: creating TABLE "bc250.tra_tunel_l"
pg_restore: creating TABLE "bc250.tra_tunel_p"
pg_restore: processing data for table "bc250.asb_cemiterio_p"
...
pg_restore: processing data for table "bc250.hid_trecho_drenagem_l"
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 89635; 0 22255026 TABLE DATA hid_trecho_drenagem_l ccar_prod
pg_restore: [archiver (db)] COPY failed for table "hid_trecho_drenagem_l": ERROR:  invalid byte sequence for encoding "UTF8": 0x00
CONTEXT:  COPY hid_trecho_drenagem_l, line 241683
pg_restore: processing data for table "bc250.hid_trecho_massa_dagua_a"
...
pg_restore: processing data for table "bc250.tra_tunel_p"
pg_restore: creating CONSTRAINT "bc250.asb_cemiterio_p_pk"
...
pg_restore: creating CONSTRAINT "bc250.tra_tunel_p_pk"
pg_restore: creating INDEX "bc250.i_asb_cemiterio_p_geom"
pg_restore: creating INDEX "bc250.i_asb_dep_abast_agua_p_geom"
...
pg_restore: creating INDEX "bc250.i_tra_tunel_p_geom"
WARNING: errors ignored on restore: 1

Adaptando SRID

Criando um SRID=952019 arbitrário para usar como projeção Albers da Grade Estatística do IBGE, e supostamente dos cálculos de área. Conferir se faz sentido, aparentemente Proj4 correto:

INSERT into spatial_ref_sys (srid, auth_name, auth_srid, proj4text, srtext)
values ( 952019, 'BR:IBGE', 52019, 
 '+proj=aea +lat_0=-12 +lon_0=-54 +lat_1=-2 +lat_2=-22 +x_0=5000000 +y_0=10000000 +ellps=WGS84 +units=m +no_defs',
 'PROJCS["Conica_Equivalente_de_Albers_Brasil",      GEOGCS["GCS_SIRGAS2000",          DATUM["D_SIRGAS2000",              SPHEROID["Geodetic_Reference_System_of_1980",6378137,298.2572221009113]],          PRIMEM["Greenwich",0],          UNIT["Degree",0.017453292519943295]],      PROJECTION["Albers"],      PARAMETER["standard_parallel_1",-2],      PARAMETER["standard_parallel_2",-22],      PARAMETER["latitude_of_origin",-12],      PARAMETER["central_meridian",-54],      PARAMETER["false_easting",5000000],      PARAMETER["false_northing",10000000],      UNIT["Meter",1]]'
);

Rodando carga Shape

Não seria necessário pois já estamos satisfeitos com a carga PostGIS... Todavia, como houve problema com a consistência entre dados de áreas, foi necessário verificar outras possibilidades. Passo-a-passo:

  1. wget ftp://geoftp.ibge.gov.br/cartas_e_mapas/bases_cartograficas_continuas/bc250/versao2017/shapefile/Limites_v2017.zip
  2. unzip -j Limites_v2017.zip "lim_muni*"
  3. shp2pgsql -s 4326 lim_municipio_a.shp | psql etc

Este comando final é delicado: a opção em -s pode ser SIRGAS2000 (srid 4674), WGS84 (srid 4326) ou SR-ORG:7823 (srid 952019 descrito acima). A documentação do IBGE não esclarece ... A princípio bastaria testar com qual opção funciona (as áreas oficiais batem). A equivalência entre SIRGAS2000 e WGS84, todavia, pode ser utilizada com segurança (OSMgeo garante).

Testes com o novo SRID

Nenhum parece ter o efeito, ou seja, não forneceram o tamanho de área esperado para os municípios ou território total brasileiro. A seguir a descrição de cada um dos experimentos realizados. Foram utilizados dois arquivos oficiais IBGE de carga, o postGIS .. e o shape

dump PostGIS default (entrou com srid 4674)
SELECT count(*) n, round(SUM(st_area(geom,true))/1000000.0) km2 FROM bc250.lim_municipio_a resultou em n=5570 e km2=8501003
dump PostGIS default e transformação para SRID 952019
SELECT count(*) n, round(SUM(st_area( ST_Transform(geom,952019) ))/1000000.0) km2 FROM bc250.lim_municipio_a resultou em n=5570 e km2=8500994. Pouca diferença do default, e mais longe do esperado.
Shape files com carga SRID default
SELECT count(*) n, ... FROM lim_municipio_a resultou em n=...
Shape files com carga SRID 952019
SELECT count(*) n, sum(st_area(geom)) area_tot FROM lim_municipio_a resultou em n=5570 e area_tot=709.362

Testes e probelmas

O SRID das geometrias dos municípios é 4674, o "SIRGAS 2000" (=wgs84), sem projeção Albers.

\d bc250.lim_municipio_a
                           Table "bc250.lim_municipio_a"
       Column        |            Type             | Collation | Nullable | Default 
---------------------+-----------------------------+-----------+----------+---------
 id_objeto           | integer                     |           | not null | 
 nome                | character varying(100)      |           |          | 
 nomeabrev           | character varying(50)       |           |          | 
 geometriaaproximada | character varying(3)        |           |          | 
 geocodigo           | character varying(15)       |           |          | 
 anodereferencia     | integer                     |           |          | 
 geom                | geometry(MultiPolygon,4674) |           |          | 
 id_produtor         | integer                     |           |          | 
 id_elementoprodutor | integer                     |           |          | 
Indexes:
    "lim_municipio_a_pk" PRIMARY KEY, btree (id_objeto)
    "i_lim_municipio_a_geom" gist (geom) WITH (fillfactor='90')

O principal dado de homologação é a área total do Brasil, assim como as áreas municipais. Os municípios estão em lim_municipio_a, e a área de sem projeção (wgs84) requer use_spheroid=true, de modo que:

SELECT count(*) n,  round(sum(st_area(geom,true)/1000000.0)) km2 FROM bc250.lim_municipio_a;
--   n   |   km2   
--  5570 | 8501003

Conforme esperado (por não usar projeção Albers da Grade Estatística oficial do IBGE) o resultado está longe do oficial.

Aguardando solução do problema da projeção.

LIXO

Lagoa dos Patos

Usando como verificação as áreas de AR_BR_RG_UF_MES_MIC_MUN_2017.ods. Nelas, além dos 5570 municípios, aparecem dois itens a mais, que são as lagoas de RS. Como estão registradas na forma de códigos de municípios, e fazem parte da totalização de "áreas do Brasil", convém incluir no dataset. A rigor não é código de município. Consultas SQL:

SELECT count(distinct  geocodigo) n FROM ibge_lim_munic_2017_area; --  5572 
SELECT i.* 
FROM ibge_lim_munic_2017_area i left join brcodes_city b 
   ON b.ibge_id::text=i.geocodigo 
WHERE b.ibge_id is null;

-- geocodigo | uf |      nome       |   area    
-- -----------+----+-----------------+-----------
--  4300001   | RS | LAGOA MIRIM     |  2832.194
--  4300002   | RS | LAGOA DOS PATOS | 10152.408

Carga do IBGE no PostGIS

Além da fonte de geometrias, Limites_v2017.zip, carregar a tabela de verificação de áreas, que atua como checksum, AR_BR_RG_UF_MES_MIC_MUN_2017.ods.

Segundo descritivo IBGE "O reprocessamento dos valores das áreas territoriais, de acordo com a estrutura político-administrativa vigente em 01/07/2017, data de referência das Estimativas Populacionais 2017, incorporaram as alterações de limites territoriais municipais ocorridas após o Censo Demográfico 2010 e praticadas nas Estimativas Populacionais Anuais no período de 2011 a 2017, bem como demais ajustes territoriais ocorridos neste período.".
A princípio podemos conferir se as áreas batem, basta fazer a soma de tudo e conferir se bate com a soma publicada no diário oficial "Para a superfície do Brasil foi mantido o valor de 8.515.759,090 km2, publicado no DOU nº 124 de 29/06/2018, conforme Resolução Nº 01, de 28 de junho de 2018".

Carga do mapa IBGE oficial dos municipios:

  1. wget ftp://geoftp.ibge.gov.br/cartas_e_mapas/bases_cartograficas_continuas/bc250/versao2017/shapefile/Limites_v2017.zip
  2. shp2pgsql lim_municipio_a.shp | psql etc
  3. alter table lim_municipio_a rename to ibge_lim_munic_2017
  4. update ibge_lim_munic_2017 set geom=st_setsrid(geom,4326);

Exemplo dado pelo EuZinho do novo limite de municipio entre Condado (89,64 km² em 2010) e Malta (156,24 km² em 2010) da PB.

SELECT geocodigo, nome, round(st_area(geom,true)/1000000.0) km2 
FROM ibge_lim_munic_2017 
WHERE geocodigo IN ('2504504','2508802');
--  geocodigo |  nome   | km2 
-- -----------+---------+-----
--  2508802   | Malta   | 157
--  2504504   | Condado | 279

-- somata total oficial:
SELECT count(*) n,  round(sum(st_area(geom,true)/1000000.0)) km2 FROM ibge_lim_munic_2017;
--    n   |   km2   
--  ------+---------
--   5570 | 8501003