Pt:Import/Catalogue/Brazil PMPA Buildings Import
Introdução e Localização
Porto Alegre, Rio Grande do Sul, Brazil - Location: http://www.openstreetmap.org/#map=12/-30.1/-51.2
Demais páginas de documentação das importações em Porto Alegreː
Importação da camada de prédios da PMPA
O seguinte relatório refere-se exclusivamente à importação da camada de 'prédios' (buildings, construções diversas) do .shp cedido pela PMPA (Prefeitura Municipal de Porto Alegre). Previamente foi feita a importação da camada de Marcos Geodésicos, descrita abaixo, para apoio na comparação entre o material da PMPA e o existente no OSM.
Foram cedidas pela PMPA ainda outras camadas de dados no material completo da PMPA (um total de 2,2GB contendo: Eixos Viários, Hidrografia, etc), sendo que havendo interesse ou necessidade de trabalhar estas demais camadas é necessário documentá-las preferencialmente em outros wikis específicos para cada uma.
Em desenvolvimento por: user:smaprs. Com valioso auxílio do colaborador naoliv e demais membros da comunidade OSM no Brasil.
Metodologia e Documentação
Revisada e atualizada no andamento dos trabalhos.
Documentaçãoː
Início da proposta de importação e discussão com a Comunidade OSM-Brasil
Cópia do processo administrativo na Prefeitura autorizando a importação de dados ao OSM
Importação preliminar dos marcos geodésicos da Rede de Referência Cadastral da PMPA como apoio ao mapeamento
Objetivoː ter mapeados no OSM pontos fixos com coordenadas confirmadas, para permanente aferição de posicionamento da imagem do Bing e dados mapeados no OSM.
São 50 marcos na forma de pilares, com base de concreto de 1x1m, em cor clara, colocados pela prefeitura em terrenos em geral sem obstáculos e públicos, muitos visíveis nas imagens do Bing (como mostrado abaixo: basta procurá-lo na imagem Bing na proximidade de cada marco no OSM, num raio de até cerca de 5m do respectivo nó OSM), e alguns também no Mapillary, como os marcos M01, ao lado, e M35.
Eventualmente, após calibrada a imagem do Bing, pode-se usá-la como apoio para proceder calibragem do Mapbox, com elementos que sejam visíveis nesta última. Mas neste caso será uma calibragem derivada, secundária e indireta, não tão precisa quanto uma primária e direta, não devendo ser salva no banco de offset.
Site da PMPA com Sistema Cartográfico de Referência (em .kml / WGS84): http://www2.portoalegre.rs.gov.br/spm/default.php?p_secao=345
Situação: importados marcos de concreto (M) e criada no OSM a relação "Rede de Referência Cadastral de Porto Alegre".
Não importados pinos RN (Referência de Nível) por não ser visíveis na imagem (cerca de 2,5cm).
Comparação prévia entre as camadas de dados para identificação de desvios e possibilidades de resolução de conflitos
- PMPA - marcos geodésicos e alinhamento dos prédios: coordenadas originais
- Strava: compatibilidade com posicionamento dos marcos geodésicos e alinhamento dos prédios da PMPA.
- Bing: a imagem atual do Bing (27/04/2016) apresenta um deslocamento médio de cerca de 5m para Norte em relação aos demais (camadas da PMPA e Strava). Isto é menos do que desvios comuns de GPS (ao redor de 10m, até 30m em áreas com muitos obstáculos). Nas imagens abaixo, exemplo na área central da cidade com referência ao marco M11.
:
.
Os prédios mapeados pela PMPA no Mapa Cadastral de longa data estão posicionados com boa precisão, atualizados com apoio na Rede de Referência Cadastral. Ambos, Rede de Referência (marcos de concreto) e Mapa Cadastral (prédios), se tornam, assim, referência confiável para permanente aferição e manutenção do alinhamento dos dados do OSM no Município de Porto Alegre.
Calibragem da Imagem Bing em Porto Alegre
Utilizou-se como referência os marcos geodésicos visíveis na imagem e suas coordenadas originais conforme "Rede de Referência Cadastral de Porto Alegre" citada abaixo. Para calibrar a imagem Bing em regiões de Porto Alegre, foi usado o plugin do JOSM Imagery Offset Database, um banco de dados de calibragem da imagem, permitindo salvar offset corrigido por regiões (Store Imagery Offset). A imagem disponibilizada atualmente no Mapbox não apresenta ainda resolução suficiente para identificação deste tipo de objeto menor.
Algumas destas calibragens foram salvas e estão disponibilizadas no banco de dados comum do plugin para a cidade. Pode-se salvar mais calibragens. A princípio pode-se tomar como área de calibragem válida até aproximadamente metade da distância aos marcos vizinhos (havendo eventualmente outros pontos de referência com coordenadas precisas e visibilidade no Bing, pode-se incluí-los como novas referências e salvar novos presets).
Uma vez que as imagens eventualmente podem ser atualizadas e alteradas (em geral permanecem por períodos de alguns anos), é possível também, se necessário, invalidar calibragens desatualizadas.
Pode-se facilmente requisitar as calibragens salvas disponíveis através do plugin, em "Get Imagery Offset", selecionando a correspondente para a região.
Exames prévios de comparação entre os prédios do Mapa Cadastral do .shp da PMPA e o existente no OSM
Os dados de prédios do Mapa Cadastral da PMPA são do último aerolevantamento da PMPA de 2010.
Os anteriores levantamentos cadastrais que contribuíram para o histórico dos dados deste mapa foram nos anos de 1941, 1956 e 1982.
Conversão do .shp original de prédios da PMPA
- Formatação de Textos (encoding): formato "system"; conversão compatível com acentuação original em português; textos em maiúsculas, sem diferenciação (necessita conversão posterior)
- Sistema de Coordenadas e Projeção importada no QGIS conforme configuração original do .shp da PMPA: SIRGAS2000 com projeção Transversa de Mercator TM-POA.
Convertido para WGS84 no QGIS e posteriormente subdivido conforme limite do JOSM de 50.000 objetos (equivale a aproximadamente 5.000 features no QGIS).
(Nota do IBGE: "Atualmente não existem parâmetros de transformação entre SIRGAS2000 e WGS 84 porque eles são praticamente iguais, ou seja, DX = 0, DY = 0 e DZ = 0." - http://www.ibge.gov.br/home/geociencias/geodesia/pmrg/faq.shtm#11).
Download dos ways "building=*" existentes no OSM para comparação com os dados da PMPA
- Download do OSM, via overpass, para ways highways=* e building=* em toda área do município para comparação no QGIS.
No QGIS: Exame de conflitos com prédios e vias existentes e filtragem do .shp
Conflitos com prédios mapeados no OSM
Numa primeira filtragem no QGIS (com valioso auxílio do colaborador naoliv), foram removidos da camada da PMPA (originalmente contendo cerca de 500.000 construções mapeadas) aqueles prédios nos locais onde já existem mapeados no OSM (cerca de 4.200 prédios mapeados no município).
A princípio, permanecem os que já estão mapeados no OSM, como recomendado. Eventualmente, se estiverem em significativa desconformidade, podem ser substituídos ou complementados pelos da camada da PMPA. Devendo ser mantidos os dados de etiquetação do OSM.
Conflitos com vias mapeadas no OSM
As vias mapeadas no OSM, nas áreas mais centrais e com disponibilidade de dados de GPS e Strava, tendem a estar em compatibilidade com estes, e do mesmo modo com o mapeamento da PMPA. Em outras áreas tendem a apresentar compatibilidade com a imagem do Bing.
Foram filtrados no QGIS os prédios do .shp que indicam conflito com vias do OSM.
Foi também aberta no JOSM a camada destes prédios para servir de indicação das vias que precisam ser realinhadas, como nas imagens abaixo.
Algumas áreas com pouco deslocamento em vias, variável, em relação ao Bing e às outras camadas de referência, onde foram de modo geral constatados ser áreas de variação de topografia (como no Centro Histórico) ou com históricos de mapeamentos antigos desde 2008, onde o deslocamento, tendendo a ser uniforme, possivelmente é devido a mudanças na imagem do Bing ao longo do tempo.
Na primeira imagem abaixo são destacados em amarelo no mapa da cidade os locais onde foi verificado conflito entre prédios da camada da PMPA e vias no OSM. Nas imagens ao lado, são mostrados exemplos de locais onde é necessária correção do posicionamento das vias conforme a posição dos prédios na camada da PMPA (contornos em vermelho no JOSM), e com apoio de Strava onde houver, sendo ambos mais confiáveis.
Nos casos de conflito entre prédios da PMPA e malha viária do OSM:
- ou são removidos prédios da camada da PMPA que não existem mais;
- ou são realinhadas no OSM as vias que assim necessitem, com base nos dados da PMPA, do Strava e da imagem do Bing previamente realinhada (os prédios da camada da PMPA, em princípio, não devem ser deslocados, por ser mais confiável seu posicionamento).
- ou podem ser casos de vias que de fato atravessam construções, como em portarias e similares, devendo neste caso a via ser seccionada e adicionada a tag "tunnel=building_passage", apenas.
Outros conflitos identificados e possíveis
Poucos casos de prédios desatualizados no material da PMPA, como alguns que havia ainda na Av. Grécia, recentemente aberta na Zona Norte da cidade (imagem ao lado).
Tanto nos dados do OSM, quanto na camada da PMPA, e no Bing, existem as seguintes possibilidades de desatualizações:
- ausência de prédios que existem na realidade (o que é mais comum no mapeamento do OSM, uma vez que é progressivo e evolutivo);
- presença de prédios que na realidade não existem mais (o que é mais comum em levantamentos e mapeamento com alguma desatualização previsível);
- prédios com aumentos, diminuições, ou outras alterações na forma.
Todos dependem da normal evolução do mapeamento e sua manutenção para atualização.
É importante sobretudo procurar detectar e solucionar eventual conflito entre vias no OSM (já bem mapeadas) e prédios da camada da PMPA a ser importados.
Após identificação dos conflitos: separação em novo layer no QGIS dos prédios filtrados sem conflitos
Filtrados os prédios do .shp da PMPA sem conflitos com prédios do OSM (eventualmente importados para substituição de geometria do existente com preservação do histórico). Separados do .shp original em novo layer, e salvos em novo arquivo de trabalho .shp para subdivisão em arquivos menores.
No JOSM: Verificação de conflitos geométricos internos e de tags na validação
- Importação dos arquivos .SHP parciais, um de cada vez, utilizando o plugin Opendata, e salvos como .osm.
- Verificação com o validador do JOSM para encontrar eventuais conflitos geométricos (duplicated nodes) ou de tags incompatíveis.
- Verificação das tags originais e compatibilidade com OSM (conversão das tags feitas no QGIS. Ex: de CLASSE=ESCOLA para "building=school")
No QGIS: Conversão dos "atributos" do .shp da PMPA para "tags" do OSM - sistematização
(Conforme submetido à comunidade OSM no talk-br)
Método e softwares utilizados:
Foi constatado que para trabalhar com maior volume de objetos (como +/-50.000 polígonos/closed ways, em .shp+.dbf de 50MB) é melhor fazer a conversão das tags todas no QGIS, e a importação direta do .shp, previamente convertido para WGS84, no JOSM (usando o plugin OpenData), onde então é convertido para .osm. O programa ogr2osm não se mostrou prático, pois mantém os campos com valores 'null' sem apagar, o que causa grande número de problemas de validação na importação para o JOSM.
Descrição do arquivo original .shp da Prefeitura: "EDIFICACOES_TM-POA.shp"
- Tamanho do Arquivo (.shp+.dbf+...): 396 MB
- Número de objetos conforme Tabela de Atributos QGIS: 538.528
- Prédios com nome: 12.889 (indicado nas tags description e note)
- Prédios com mais de 1 camada: 3.920 (indicado na tag layer=1,2,...)
Filtragem inicial:
-Filtrados e rejeitados por conflito com prédios previamente existentes no OSM: 7.701 (salvos em arquivo para eventual interesse)
-Filtrados com área menor ou igual a 7m2: 16.461 (por inabitabilidade, < 2.5x2.5m2, e pouca significância para visualização no OMS; salvos em arquivo para eventual interesse)
-Eliminados: casos de prédios que não aparecem mais nas imagens, por ocasião da validação em cada importação parcial, na verificação de conflito com as vias atuais do OSM; número não precisado.
Conversão de 'campos e valores' do .shp (PMPA) para 'keys e tags' .osm
Conforme tabela de conversão no ítem mais abaixo.
Conversão dos <campos> do .shp para <keys> .osm (Ex.: de "CLASSE" para "building")
Utilizado o plugin Table Manager :
- renomear os <campos existentes> conforme exigido para .osm;
- para adicionar <novos campos> para as tags .osm 'layer' e 'note'.
Conversão dos <valores> para <tags> .osm (Ex.:de 'ESCOLA' para 'school')
-Aberta a Tabela de atributos, fazendo a pesquisa pelas tags com Select Features Using an Expression : 'ESCOLA'
-Trocados os valores utilizando o Field Calculator , previamente checados os botões Only update selected e Update Existing Field , para os <valores> previamente selecionados, apenas colocando a <tag> própria para .osm a ser substituída na 'expression box' .
-No caso da pesquisa por 'NULL' , é necessário colocar entre 'aspas simples', como para outros strings.
TABELAS DE CONVERSÃO DE ATRIBUTOS: do .shp (PMPA) para .osm
| CLASSE | |
|---|---|
| Valor (string) | Conversão |
| (null) | + building=yes (genérico; todos são buildings) |
| AEROCLUBE | + building=yes (genérico; todos são buildings) |
| CEMITERIO | + building=yes (se já estiver em landuse=cemetery) |
| CRECHE | + building=kindergarten |
| CREMATORIO | + building=yes + amenity=crematorium |
| ESCOLA | + building=school |
| FACULDADE | + building=university (ou building=yes, se já estiver em landuse=university) |
| GINASIO | + building=stadium |
| HOSPITAL | + building=hospital |
| IGREJA | + building=church |
| NOTAVEL | + building=yes + note=nome em description |
| UNIVERSIDADE | + building=university |
| ESTADO | |
|---|---|
| Valor (string) | Conversão |
| CONSTRUCAO | + building=construction |
| FUNDACAO | + building=construction |
| RAMPA | + building=yes (ou substituir por via; examinar caso) |
| PASSARELA | + building=yes + layer=1 (ou substituir por footway; examinar caso) |
| RUINA | + building=ruins |
| NOME | |
|---|---|
| Valor (string) | conversão (somente cerca de 4.000 dos 500.000 objetos) |
| NOME=* | originalmente em MAIÚSCULAS; subsitituído por description=* + note=Nome em description |
| BLOCO (*) | ||
|---|---|---|
| Valor (integer) | Descrição | Conversão ː Adicionado layer = <valor do BLOCO> -1 + note=Layer for 2D; needs survey for 3D |
| 0 | Bloco único | + building=* (s/ uso de layer - layer=0) |
| 1 | Bloco térreo de 1ou+ pavs. | (s/ uso de layer - layer=0) |
| 2 | 2º bloco de 1ou+ pavs. | + layer=1 + note=Layer for 2D; needs survey for 3D |
| 3 | 3º bloco de 1ou+ pavs. | + layer=2 (não necessita adição de 'note', já indicada no inferior layer=1) |
| 4 | 4º bloco de 1ou+ pavs. | + layer=3 (não necessita adição de 'note', já indicada no inferior layer=1) |
| 5 | 5º bloco de 1ou+ pavs. | + layer=4 (não necessita adição de 'note', já indicada no inferior layer=1) |
| 6 | 6º bloco de 1ou+ pavs. | + layer=5 (não necessita adição de 'note', já indicada no inferior layer=1) |
| 7 a 12 | Apenas 16 casos dos 500.000, usados para blocos em separações horizontais; casos examinados individualmente; eventualmente podem ser convertidos para tags 3D. | |
(*) Indica apenas blocos sobrepostos dos mesmos prédios; NÃO representa "número de pavimentos", não serve para conversão direta para 3D (como buildingːlevels), para o que necessita de survey ou consulta a imagens Mapillary.
| SETOR | |
|---|---|
| Valor (string) | Sem conversão |
| 1 a 49; SH; IJ | Representa a divisão interna utilizada para os grupos de autores terceirizados que mapearam o original. Utilizado nesta importação para subdividir o .shp em arquivos menores conforme setores. Campo deletado no JOSM por ser tag incompatível com .osm. |
Após convertidas tags e removidos campos originais, importados para o JOSM como segue, em arquivos .shp subdividios em pacotes de aproximadamente 5.000 features no QGIS (equivalente a cerca de 40.000 objetos no OSM, para ficar abaixo do limite de 50.0000 objetos por changeset no JOSM).
No JOSM: Validação final, interna e externa - preparação para upload (passo a passo)
Importação do .shp, salvo como .osm e verificação da conversão de objetos elementares (ways, multipolygons) e tags
Utilizado plugin OpenData do JOSM par importação do .shp.
Validação interna (verificação e resolução de conflitos geométricos internos e de tags)
Examinar conflitos geométricos internos e de tags, conforme validador do JOSM, no grupo de objetos originais, isoladamente, sem fazer download do existente no OSM.
1- Abrir .shp sudividido no JOSM e salvar como .osm;
2- Alterar a KEY: 'descript' para 'description' (no QGIS o nome do campo/key é limitado a 8 caracteres)
3- Remover campo original 'SETOR';
4- Passar o validador e verificar os seguintes possíveis conflitos geométricos, nesta ordem:
Errors: Building duplicated nodes - Duplicated nodes: resolução com fix ;
Warnings: Mixed type duplicated nodes - Duplicated nodes: resolução: fundidos os nós;
-Importante: resolvendo estes, muitos dos demais conflitos são resolvidos em decorrência (como crossing buildings).
Conflitos geométricos internos observados até o momento: cerca de 0,1% em cada importação.
5- Passar o validador novamente até obter 100% de validação, antes de examinar os próximos possíveis conflitos (muitos podem desaparecer após etapa acima).
Resultado final da Validação interna: 100% validados, prontos para importação.
Validação externa (verificação e resolução de conflitos com dados existentes no OSM)
6- Fazer download do existente no OSM em toda a área de abrangência;
7- Passar o validador na área toda, com todos os objetos (a importar + existentes no OSM), antes de importar definitivamente ao OSM, para verificar eventuais conflitos do material da PMPA com objetos previamente existentes no OSM, ou alguma necessidade de ajuste no que já existe no OSM, sobretudo a respeito de highways e Building inside building .
Após 100% validado (validação interna e externa), está pronto para upload (caso seja postergado upload para mais tarde, fazer novamente validação externa antes por ocasião do upload, sobretudo para detectar eventuais conflitos com novos objetos no OSM).
Importados para o OSM
Histórico da separação em arquivos menores:
-Inicialmente separados seguindo a divisão administrativa por bairros do OSM, no Centro Histórico e bairros vizinhos.
-Depois passaram a ser separados no QGIS conforme o campo SETOR do .shp original (de 1 a 49, mais IJ e SH, total de 51 setores). Porém alguns dos setores possuem mais de 50.000 objetos equivalentes para o JOSM.
-Foi então alterado temporariamente o processo de subdivisão para os restantes, conforme numeração de features na Tabela de Atributos no QGIS, em grupos de 5.000 (equivale a aproximadamente 40.000 a 50.000 objetos totais no JOSM). Conastado problema nas sibdivisões subsequente, de conflito geométrico com as novas importações, exigindo resolver vários conflitos de nós duplicados nos novos prédios vizinhos. Resolvidos manualmente todos os conflitos em cada importação
-Retomada e mantida até o final dos trabalhos de importação a subdivisão conforme o campo SETOR (separados fisicamente conforme áreas da cidade, por ruas), e novamente subdividindo os setores com mais de 5.000 features entre áreas fisicamente separadas (por ruas ou vazios urbanos), evitando assim conflitos de nós duplicados em prédios vizinhos de importações diferentes.
Mantido o número limite para subdivisão de cerca de 5.000 features no QGIS, para manter o limite de 50.000 objetos no JOSM para um único changeset em cada importação (eventualmente pode acontecer de alguns extrapolarem, após eventuais ajustes necessários sobre o existente no OSM concomitantes à importação).
Histórico de Uploads - Importados e validados
Conta para upload da importação:
-Importações preliminar e inicial: http://www.openstreetmap.org/user/smaprs
-A partir de setores 01 a 05: http://www.openstreetmap.org/user/smaprs_import
1) IMPORTAÇÃO PRELIMINAR: Rede de Referência Cadastral de Porto Alegre (Marcos Geodésicos/PMPA):
| changeset: | data: | comment: |
38900662: 26/04/2016: Import: Rede de Referência Cadastral de Porto Alegre
38901600: 26/04/2016: Criada relação " Rede de Referência Cadastral de Porto Alegre" e ordenados membros
2) IMPORTAÇÕES DOS PRÉDIOS:
2.1) SUBDIVISÃO INICIAL EM SELEÇÃO GEOMÉTRICA POR BAIRROS CONFORME OSM:
| bairros: | changeset: | data: |
2.1a- Centro Histórico : 38980822: 29/04/2016: 39007953: 30/04
2.1b - IMPORTAÇÕES COMPLEMENTARES NO CENTRO : 39009304: 30/04:
objetos que haviam sido filtrados por haver existentes no OSM; inseridos com substituição de geometria e conservação de histórico.
2.1c- Casa de Cultura Mario Quintana : 39180376: e consertos em subsequentes
2.1d- CONSERTOS nos importados : 39230610: e subsequentes
2.1e- Galeria Malcom : 39302662, 39323459: e consertos em subsequentes
2.1f - Catedral Metropolitana : 39385742
FEATURES (QGIS) IMPORTADOS NO CENTRO HISTÓRICO : 4.283
2.2- Cidade Baixa: 39303982 : 14/05/2016: FEATURES (QGIS) IMPORTADOS: 2.505
2.3- Bom Fim, Independência, Moinhos de Vento, Marcílio Dias, Floresta: 39411216 e 39412061: FEATURES (QGIS) IMPORTADOS: 8.524
2.2) SUBDIVISÃO POR SETORES: (DOS RESTANTES 01,02,04 e 05, ATÉ SETOR 08, TOTALIZANDO DE 01 a 08):
A partir do changeset 39562295
TOTAL ACUMULADO DE FEATURES (QGIS) IMPORTADOS até a mudança de critério de contagem: 33.677
2.3) SUBDIVISÃO POR NUMERAÇÃO CORRIDA:
A partir do changeset 39642757
Seleção por "numeração ordinária" dos Objetos (Features) no QGIS, a cada 5.000.
Devido ao fato de a partir do SETOR 09, setores apresentam mais de 5.000 objetos no QGIS.
2.2) SUBDIVISÃO POR SETORES E POR ÁREAS:
A partir do SETOR 10 / changeset 39945325
Selecionados conforme SETOR e áreas geográficas separadas, no limite de 5.000 fetures (+/-50.000 objetos no OSM)
Devido ao problema de conflitos de nós entre prédios vizinhos em importações subsequentes.
Mantida esta subdivisão dos .shp parciais até o final dos trabalhos de importação.
IMPORTAÇÃO CONCLUÍDA EM JULHO DE 2016