OpenStreetMap

smaprs's diary

Recent diary entries

Never mapping walking dunes

Posted by smaprs on 23 May 2019 in English (English).

Here is a small evidence of why one should rather avoid mapping “individual” dunes:
they’re usually moving.
Sometimes they may even move across the oceans…
Below is what I could roughly, localy measure, with help from Sentinel & Landsat.

Saharan dunes - Adrar, Algeria
Direction of movement: SW ~200m / 30years
There where the wind turns the corner, at https://www.osm.org/edit#map=6/24.375/-2.875
(or zoom to https://www.osm.org/edit#map=15/24.3750/-2.8750)
(timelapse made with: https://apps.sentinel-hub.com/eo-browser/ - Landsat-5 1987-2011; Sentinel-2 2015-2019)

Harmattan wind (https://en.wikipedia.org/wiki/Harmattan): this wind always goes east-west direction from Sahara, many times throwing parts of the sands it carries on brazilian coasts (https://en.wikipedia.org/wiki/Trade_winds), like at

“Lençóis Maranhenses” National Park, Maranhão, Brazil
Direction of movement: WSW ~200m / 6years
https://www.osm.org/edit#map=13/-2.5552/-42.7955
(timelapse made with: https://apps.sentinel-hub.com/eo-browser/ - Landsat-8 pansharpened 2013-2019)
https://en.wikipedia.org/wiki/Lençóis_Maranhenses_National_Park

Don’t believe they move as far as that?
See https://www.nasa.gov/content/goddard/nasa-satellite-reveals-how-much-saharan-dust-feeds-amazon-s-plants

Location: Bordj Badji Mokhtar, Bordj Badji Mokhtar District, Bordj Badji Mokhtar, 01010, Algeria

On the utility of Sentinel-2 satellite images

Posted by smaprs on 19 May 2019 in English (English).

The great utility of Sentinel images is that it provides the most recent images, almost weekly, at resolutions up to 10m/pixel, that can help much on mapping landuse, urbanization and major features on OSM, mostly on remote places not usally acessible to survey.

Example: Growing human occupation in Amazonia
Location: https://www.openstreetmap.org/edit#map=16/-9.5540/-72.1440

Bing and DG Image (Hi-res), date of tiles here 2006:

EOX Sentinel-2 Cloudless, already added to JOSM image list; but has not enough resolution for urbanization, nor enabled to select dates:

Sentinel Hub (better resolution): SENTINEL-2 L1C, selected 2018-09-05, no clouds.
In this image it can be seen the growth of human occupation compared to 2006 Bing image. Actually it can be used only with a Sentinel Hub account, providing API key. Perhaps further it may be implemented for JOSM.

Sentinel-2 can be used for mapping in OSM.

More info at
https://wiki.openstreetmap.org/wiki/Sentinel-2
https://josm.openstreetmap.de/ticket/14921
https://www.sentinel-hub.com/develop

Location: Coração da Floresta, Jordão, Microrregião de Tarauacá, Região Geográfica Intermediária de Cruzeiro do Sul, Acre, North Region, Brazil

"Mapeamento Colaborativo" e "Informações Geográficas Voluntárias"

Posted by smaprs on 25 November 2018 in Portuguese (Português).

Breves reflexões sobre os conceitos de “Mapeamento Colaborativo” [1] e
“Informações Geográficas Voluntárias”(VGI) [2]
[1] https://en.wikipedia.org/wiki/Collaborative_mapping
https://pt.wikipedia.org/wiki/Mapeamento_colaborativo
[2] https://en.wikipedia.org/wiki/Volunteered_geographic_information
https://es.wikipedia.org/wiki/Informaci%C3%B3n_Geogr%C3%A1fica_Voluntaria
(não tem wiki em português)

Bem resumidamente:

Diferenças:
O “Mapeamento Colaborativo” é a atividade de construir mapas, as bases de dados geográficos para uma cartografia básica. Sendo mapeamento, envolve desenho, construção de “geometrias”: pontos, linhas, áreas. Sobre estas bases “cartográficas” podem ser inseridas “Informações Geográficas Voluntárias” (como “tags” específicas, etc). VGI pode ser entendida como “qualquer informação” voluntariamente (=gratuitamente) fornecida, referenciada geograficamente: exemplo: elemento=área + evento=enchente + data=*; etc. VGI necessita portanto de uma base cartográfica, como interface humanizada, com objetos geográficos elementares, para ser interpretada.

Semelhanças:
Ambos são “Conteúdo Gerado pelo Usuário” (UGC)
https://en.wikipedia.org/wiki/User-generated_content
https://pt.wikipedia.org/wiki/Conte%C3%BAdo_gerado_pelo_usu%C3%A1rio (2008)
https://pt.wikipedia.org/wiki/Conte%C3%BAdo_Gerado_pelo_Utilizador (2014)
(aqui tem uma duplicação de artigo da wikipedia-pt)

Ambos geram informações preciosas. Valem muito.
O seu valor depende da sua “precisão” e “confiabilidade”.
A precisão depende do que exige o “uso” a que é destinada.
A confiabilidade pode ser expressa pela expectativa (estatística, proporção) de elementos verdadeiros, para o uso que lhes solicita.

A precisão dos dados geométricos gerados por um particular com interesse local, como em um levantamento topográfico de um terreno feita pelo proprietário, com conhecimento dos meandros do local e seu entorno, é na grande maioria das vezes maior do que a precisão dos dados gerados por órgãos públicos, como em levantamento cadastral para fins de planejamento urbano e/ou tributação territorial (IPTU). Pela própria escala de enfoque, a resolução tende sempre a ser maior quanto menor e mais local for o enfoque.

Sendo o mapeamento colaborativo uma “atividade” de construção, com resultado de caráter prático -
neste caso construção de informações gráficas, através de desenhos - poderia ser comparado a construir um prédio, tijolo por tijolo. É um “trabalho”, com resultado prático concreto. Ainda que em permanente aprimoramento e crescimento, não estático. Por serem representações da realidade, que é dinâmica, mapas em geral não são estáticos.

O resultado do trabalho de mapeamento colaborativo e inserção de VGI tem muito valor, e pouquíssimo ou nenhum custo. Como um mutirão.
Permite ainda produzir trabalhos derivados, inúmeras interações, projeções, planejamentos e execuções de atividades, etc, sobre dados que outros forneceram.

Pelo grande valor que possuem, ambas atividades, “Mapeamento Colaborativo” e aporte de “Informações Geográficas Voluntárias”(VGI) também podem ser eventualmente interpretadas como “mão de obra barata” para ambientes “proprietários” [https://pt.wikipedia.org/wiki/Mapeamento_colaborativo#Compara%C3%A7%C3%A3o_entre_mapas_colaborativos].
Neste sentido, o resultado do trabalho de ambas pode pertencer a um único proprietário particular (pessoa física ou jurídica), que neste caso recebe de graça o trabalho de outros, e livre para cobrar para que os mesmos colaboradores usem o mapa que construíram; ou pode pertencer à mesma comunidade de colaboradores, permitindo que esta comunidade se beneficie do mapa sem custo algum, e ainda sem discriminação de pessoas, de modo que mesmo quem não colaborou na construção do mapa possa usá-lo.
Em ambos os casos, o produto do trabalho não deixa de ser uma propriedade. A diferença está em ser: ou uma propriedade exclusiva; ou uma propriedade compartilhada e diluída.

Certamente há mais ainda para refletir sobre a compreensão dos conceitos.

Location: Rio Grande do Sul, Região Sul, Brasil

Vetorização semi-automática de matas densas com Sentinel-2

Posted by smaprs on 17 August 2018 in Portuguese (Português). Last updated on 20 August 2018.

Neste post descrevo, e submeto a opiniões, os passos adotados para um teste de processamento semi-automático de vetorização a partir de imagem de satélite Sentinel-2, com controle de parâmetros e validação manuais feitos pelo usuário, tendo em vista a vetorização de áreas de matas com suficiente distinção entre natural=wood e landuse=forest (mata natural e mata cultivada).

Importante:
-Esta metodologia é aqui apresentada como uma preparação para uma possibilidade de proposta de mapeamento para a comunidade OSM, como um metodo auxiliar ao mapeamento, e que tem como foco somente o mapeamento voltado a coberturas de terreno (landcover). Por enquanto trata-se de testes, offline. Não feito upload.
-O processo todo resulta em simplificação, como curvas com espaçamento entre nós não menor que 10m (a resolução da imagem é 10m/px). Por isso não serve para objetos pequenos como lotes, praças, etc., pois não mapearia detalhes que podem ser vistos nas imagens padrão do OSM.

O propósito é:
-poder gerar desenho de grandes áreas de mata densa, em interiores do território, não densamente urbanizados;
-com diferenciação de vegetação usando índices apropriados, para forest e wood, o que não é facilmente, e/ou comumente, distinguido nos desenhos sobre as imagens padrão. Mesmo assim, deve ser verificado visualmente o resultado ao final do processamento, junto com as imagens padrão do OSM.

DESCRIÇÃO INICIAL DOS DADOS:

IMAGENS: SENTINEL-2 / Cobertura: ~100x100Km
Documentação original: https://www.sentinel-hub.com/develop/documentation/eo_products/Sentinel2EOproducts
Licença compatível com OSM: conforme https://wiki.openstreetmap.org/wiki/Sentinel-2
Fonte das imagens: https://earthexplorer.usgs.gov/ : camadas Sentinel-2
Bandas utilizadas: B11 (testadas todas as bandas, B11 se mostrou a melhor para o objetivo; condição:nuvem=0)
Índices utilizados: NDVI; CRE
——————- NDVI: Normalized Difference Vegetation Index : Fórmula: NDVI = (B08 - B04) / (B08 + B04)
CRE: Chlorophyll Red-Edge (abbrv. Chlred-edge) : Fórmula: CRE = (B07 / B05) ^ -1

PROCESSAMENTO - PASSOS:

1)ESCOLHA DA IMAGEM DE SATÉLITE - SENTINEL:
Escolhida imagem em data que não gere discrepâncias (para mais ou para menos) de atividade vegetal: preferencialmente entre equinócio e solstício; evitar alto inverno e alto verão.

Caso Bom Jesus, RS:
https://earthexplorer.usgs.gov/ - Sentinel - “T22JEP_20180420T132231_B11”
Data: 2018/04/20
Hora: 13:22 (09:22 Brasil; gera alguma sombra)
[IMAGEM-1: abaixo. A imagem abaixo pode ser aberta em nova guia para visualizar detalhes em zoom maior.]


2)Examinar no QGIS valores do raster; procurar valores limites de distinções de classes:

-Usar as imagens em cores naturais, Sentinel-TCI (True Color - ver imagem abaixo ) e Bing, para localizar e marcar exemplos claramente identificáveis dos tipos de vegetação a serem distinguidos em classes.

Exige conhecimento da vegetação típica básica, e sobretudo poder identificá-la em imagem de satélite em cores naturais. Além de evidentemente poder distinguir os demais elementos, como área urbanizada, campo ralo, trilhas e corpos de água.

A identificação dos tipos wood e forest é possível de fazer somente sobre imagem Bing. Neste método, deve ser feita ainda preferencialmente sobre a imagem TCI do conjunto Sentinel-2, uma vez que esta apresenta o conjunto dos mesmos objetos no mesmo instante de tempo (áreas de florestas podem ter sido cortadas em diferentes períodos). Basta saber distinguir os tipos, o que é viável com algum pouco treinamento do olho.

O que o presente método propõe é usar uma seleção amostral, feita sobre as imagens em cores naturais, de objetos dos quais se tenha seguro conhecimento, que sejam representantes destes 2 tipos, wood e forest, bem como dos demais objetos que não são estas 2 classe, para, nas imagens dos demais sensores e ínidices Sentinel, avaliar os valores típicos de pixels dos objetos selecionados, testando se os mesmos limites de valores são encontrados em matas típicas em algumas diversas porções da imagem.

Os valores típicos em uma imagem podem apresentar alguma variação em outras imagens e outros locais. Por isso todos os passos do método deve ser repetidos em trabalhos com outras imagens ou territórios.

Uma vez que se encontre os valores limites típicos na imagem, usá-los como parâmetros para deduzir os objetos dos tipos wood e forest na imagem toda.

-Áreas de mata cultivada isoladas são mais fáceis de distinguir na imagem em cor natural. Não tanto quando plantadas em meio a mata natural, o que exige um olhar mais treinado aos detalhes das feições típicas (ver na imagem abaixo).
Assim é preferível procurar primeiramente áreas destacadas de plantação, em campo aberto. Como lotes mais ou menos regulares de mata plantada.
As espécies plantadas mais comuns nesta região de enfoque são sobretudo o Pinus, para indústria de celulose, e menos comumente Eucalipto, mais para construção e lenha.

As florestas de Pinus, e florestas plantadas em geral, costumam apresentar espécimes regularmente espaçados, formando uma malha regular densa, com uma superfície mais regular, como um tapete plano. Procurar por estas feições. São plantadas em campos planos e também em encostas. Nas encostas podem ser detectadas por várias trilhas de serviço para extração, escalonadas. Eucalipto costuma ser plantado ao redor de sedes de fazendas em campo aberto. A superfície de florestas plantadas de modo geral costuma apresentar maior homogeneidade de tamanho de indivíduos.

-As matas nativas ou mais velhas, com menor atividade biológica, e por isso índices diversos nas imagens, são o restante de matas a identificar. Em geral apresentam a superfície da cobertura mais irregular quanto ao tamanho dos indivíduos. Mais facilmente encontradas em locais onde não haja estradas ou trilhas de serviço indicando acesso constante, e em faixas variáveis ao longo das margens de cursos d’água, devido ao estatuto legal de proteção das matas marginais.

Estas áreas exclusivas com respectivos objetos-tipo servirão de amostragem de elementos das classes para avaliação dos valores de pixels. Podem ser feitos polígonos para marca-los, em layer à parte.
Com estes objetos-tipo, serão verificados e anotados os valores típicos dos pixels nas imagens de referência a serem examinadas alternando, sobre o mesmo objeto amostral, os respectivos layers: B11, NDVI, CRE. E anotados os limites de valores em relação aos objetos das demais classes. Estes valores limites típicos serão usados para distinção automática de tipos de vegetais na imagem toda.


CASO: Matas nos municípios de Bom Jesus e Monte Alegre dos Campos, RS:
QGIS: View menu : Identify feature : testar valores de pixels individuais


SENSOR / ÍNDICE :: B11 :: NDVI :: CRE
Min. :: 511 :: -0.87 :: 0.2
Max. :: 2709 :: +0.87 :: 0.75


MATA NATIVA (n.=wood) :: 1200-1800::0.30 /0.80 ::
MATA PLANTADA (l.=forest) ::150-1200 :: 0.70/0.80 ::
Mata na sombra(encosta.Sul) ::150-400 ::0.30/0.65 :: 0.4 - 0.5
Mata no sol (encosta.N.) :: 1200-1800 :: 0.65/0.80:: 0.25-0.3

campo ralo (null) :: 1500 -3000 :: :
urbanização :: 1700-3000 ::-0.10/0.20 :

água parada (açude) :: 50-150 ::-0.10/0.10 :: 0.8-1.0
água corrente (rio) :: 150-300 :: -0.30/0.60 :: 0.5-0.8
valor limite para água :: < 150 :: < 0.3 :: >0.5


Resultado observado:
* B11 distingue bem entre os tipos de matas “wood” e “forest”.
Para isto ver também a documentação Sentinel sobre as aplicações dos diversos sensores e índices:
https://www.sentinel-hub.com/develop/documentation/eo_products/Sentinel2EOproducts
Em diferentes áreas do terreno abrangido na imagem, as mesmas classes de matas apresentam alguma variação, o que pode gerar ainda algum grau de imprecisão para uma distinção absolutamente exata. No entanto o limite de matas x campos ou urbanização é bem distinto. Por outro lado, não separa rios de forest; para isto necessita contrastar B11 com outros índices mais adequados, a seguir.
* NDVI e CRE destacam mais nitidamente o que é e o que não é vegetação, como corpos de água, trilhas, urbanização, etc.

[IMAGEM-2]


3)CORREÇÕES:

A imagem B11 distingue bem entre os tipos de matas wood e forest, mas não distingue bem matas na sombra (encostas Sul) e água corrente. Os índices NDVI e CRE fazem esta distinção. É necessário então corrigir a imagem B11 acrescentando as distinções de NDVI e CRE.

OPERAÇÃO: B11+(1-NDVI)+CRE
QGIS: Raster calculator: SINTAXE: "T22JEP_20180420T132231_B11@1" + ((1-"NDVI@1")*1800) + ("CRE@1" *2600)
Agregados empiricamente os fatores ponderadores NDVI1800 e CRE2600, para que fiquem acima dos valore limites dos tipos em B11 (~2000) , e equilibrar estes índices entre si. Isto é, depende de testes de tentativa-erro-acerto até chegar aos valores de equilíbrio. Precisa ser verificado em cada trabalho com outros conjuntos de imagens diferentes, em outros locais.

RESULTADO: “B11+1-NDVI+CRE.tif” : (10m/px)

[IMAGEM-3]


4)TESTAR CLASSES VISUALMENTE:
-Igual à etapa (2), para B11+1-NDVI+CRE:

Depende igualmente de fazer testes de tentativa-erro-acerto até chegar aos limites significativos e adequados à realidade que possa ser observada nas imagens naturais.
QGIS: Raster Properties :
Style / Categorized Renderer: Equal Interval
Color interpolation: Discrete : testar manualmente classes e valores limites

Resultado para esta imagem do caso-teste:
5 CLASSES :
(1)forest <= 2150 <
(2)wood <= 2600 <
(3)campo alto ou ciliar <= 3500 <
(4)campo ralo ou trilha <= 3950 <
(5)água, estrada, cidade, lavourado


5)PROCESSAR A IMAGEM, REDUZINDO ÀS CLASSES TESTADAS:

CONDICIONAIS “if/then/else”:
QGIS: Raster calculator:
SINTAXE: (("@1"<x)* operação ) => se sim=1(opera); se não=0(não opera)

SINTAXE :
` (1* ( “B11+1-NDVI+CRE@1” <=2150 )) + (2* (( 2150 < “B11+1-NDVI+CRE@1” ) AND ( “B11+1-NDVI+CRE@1” <= 2600 ) )) + (3* (( 2600 < “B11+1-NDVI+CRE@1” ) AND ( “B11+1-NDVI+CRE@1” <= 3500 ) )) + (4* (( 3500 < “B11+1-NDVI+CRE@1” ) AND ( “B11+1-NDVI+CRE@1” <= 3950 ) )) + (5* ( “B11+1-NDVI+CRE@1” > 3950 ))`

Resultado:
Imagem com valores limitados às classes: “B11-5classes.tif”

[IMAGEM-4]


6)SIMPLIFICAR ÁREAS, REMOVER PIXELS ISOLADOS:

OPERAÇÕES: ~1min cada
QGIS: Processing / Toolbox :
* GDAl / Analysis / Sieve
* GRASS / r.neighbor

1 Sieve T3 C8 - Remove até 3px(10x30m)
2 Neig Max 3 Ci - Aumenta borda do maior, 1px cada lado (10m+10m)
3 Sieve T3 C4
4 Neig Mode 3 Sq
5 Sieve T6 C8 - Remove até 6px(20x30m)

Resultado:
5 classes filtradas: “B11-5classes-Filtrado.tif” (10m/px)

[IMAGEM-5]


7)REDUZIR A IMAGEM SOMENTE ÀS CLASSES DE INTERESSE (forest e wood; 1 e 2) E IGUALAR DEMAIS CLASSES (3,4,5) A “ZERO”:

QGIS: Raster calculator: (( "@1" > 2 ) * 0) + (( "@1" <=2 ) * "@1" )


8)CRUZAR O RASTER PROCESSADO COM OS VETORES EXISTENTES NO OSM, DE RIOS E ESTRADAS, PARA MELHORAR RECORTES NAS MATAS:

-Baixar dados do OSM/overpass: highway=* or waterway=* and type:way
-Criar um novo layer vetor SHP contendo as linhas de highway e waterway que servirão para recortar.
-Adicionar um campo de número real, com valor “0”(zero) para todas as linhas/polígonos a serem filtrados
-Gerar um buffer sobre todas as linhas:
QGIS: Vector / Geoprocessing / Buffer : fixed distance
O buffer deve ser maior que a resolução da imagem destino e menor que os menores grupos de pixels após as filtragens. Para não gerar pixels ligados só nos cantos nem elminar a mais do que as filtragens anteriores. Utilizado buffer de 20m; suficiente para imagem de 10m/px. Contendo valor classe=0.
-Salvar o buffer como SHP

RASTERIZAR O VETOR SOBRE A IMAGEM:
-Fazer uma cópia simples do raster anteriormente processado, a ser alterada, como destino; -Adicionar o layer vetor do buffer sobre a imagem destino:
QGIS: Raster / Conversion / Rasterize : SHP com o buffer, campo p/ valor “0”(zero) : imagem destino

ÚLTIMA FILTRAGEM:
simplificar; remover últimos pequenos clumps de até 20 pixels isolados (4x5 pixels) que sobram em alguns recortes:
Sieve T20 C4

Resultado: “B11-0-1-2-Filtrado+OSM.tif”

Não é objetivo do processo captar áreas com menos de 40x40m nas distinções, o que equivale a pouco, o que gera muitas imprecisões. Somente áreas de matas com maior homogeneidade, que possuem dimensões muito maiores.

[IMAGEM-6]


9) ELIMINAR DEMAIS CLASSES NÃO UTILIZADAS - Igualar “zero” a “null”:
(ajuda a reduzir a quantidade de polígnos no poligonize):

QGIS: gdal_translate / -a_nodata < x > : (x = valor da classe p/null)

Resultado:
Raster Classes 1+2+null : “B11-1-2-null+OSM.tif”


10)VETORIZAR - Gerar polígonos do raster:

QGIS: Raster / conversion / poligonize (manter mesma CRS no projeto)
Gera SHP com polígonos para as 2 classes somente.


11)SUAVIZAR POLÍGONOS - despixelizar:
QGIS: GRASS commands -> v.generalize.smooth:
(https://grass.osgeo.org/grass64/manuals/v.generalize.html)

* Sliding Averaging : look_ahead = 3 (mín=3, sempre ímpar) : slide = 0.7

Resultado: ~5min “Sliding-Average-L3-SL07-OK.shp”

[IMAGEM 7 e abaixo]
LEGENDA:
Verde claro: mata nativa (natural=wood)
Verde escuro: mata cultivada (landuse=forest)
Branco: null


12)ADICIONAR TAGS OSM E LIMPAR:

ELIMINAR DO SHP POLÍGONOS TRUNCADOS DE BORDA DE IMAGEM ou RESTRINGIR POLÍGONOS A MUNICÍPIO

Salvar como novo layer: “B11+OSM-limpo.shp”

-Selecionar todo polígono que encosta nas bordas do layer e remover manualmente (pode fazer um buffer menor que os limites do layer);
-Adicionar tags:
QGIS: Table Manager + Field Calculator : landuse=forest; natural=wood;
-Remover tags sem uso (area; classe).
Salvar com CRS para OSM: WGS84-EPSG:4326


13) Opcional: Selecionar por máscara de município
(pois o JOSM fica muito pesado se abrir mais de 10.000 polígonos)

QGIS: Vector / Spatial Query: “SHP-origem” + Intersects + “SHP-máscara” - selection / invert / remove


PROCESSOS NO JOSM:

1)ABRIR CADA SHP SEPARADAMENTE :

-Sem baixar dados do OSM
-salvar como .osm

Já entra como polígono ou multipol(outer/inner); curvas com ~1nó/10m (mesma resolução das imagens raster)

Monte Alegre dos Campos:
QGIS: SHP 5,2MB; features/polígonos= 3.519
JOSM: “B11-MA-4326.osm” : 23,8MB; nodes= 243.070


2)SIMPLIFICAR:
Select: type:way / Symplify way
Resultado: nodes= 136.853


3) VALIDAR SEPARADAMENTE
-Sem baixar dados do OSM

Resultado:
Errors: (0)
Warnings: (28)
Self-intersecting polygon ring (3)
Self-intersecting ways (25)

Todos foram casos de auto-intersecção em cruz (quina) - imagem abaixo.
Talvez possa evitar previamente no QGIS com
QGIS: GRASS commands -> v.generalize.smooth / Displacement
(https://grass.osgeo.org/grass64/manuals/v.generalize.html)

Solução:
Alteração manual: “unglue(G)” nos nós de cada intersecção; afastar nós e ways
Cuidar: testar todos os nós da intersecção após o unglue; manter polígonos e multipolígonos fechados ao final

VALIDAR NOVAMENTE:
Resultado: VALIDAÇÃO COMPLETA (0)


4) TESTES DE CONFLITO COM O EXISTENTE:
-Baixar dados do OSM;
-verificar existência de objetos de landcover previamente mapeados no OSM (como landuse=grass;orchard;…, natural=grassland;scrub;wetland;…, etc): se houver, não substituí-los ou alterá-los; ao contrário, remover no novo conjunto os polígonos que os intersectarem.O método não objetiva alterar objetos das mesmas classes de foco (wood e forest) previamente existentes, apenas acrescentar novos que não estejam em conflito com aqueles.

VALIDAR:
Resultado: VALIDAÇÃO COMPLETA (0)

Pronto para aprovação e upload


5) PARA UPLOAD DOS NOVOS DADOS AO OSM:

Se aceito o método como válido para o OSM , proposto salvar em changesets exclusivos, com a nota:
“adição de polígonos de matas (wood;forest) semi-automatizados com controle de parâmetros e validação manuais”

O arquivo .osm resultante deste teste para verificação pode ser baixado neste repositório (não feito upload ao OSM).


Comentários:

Onde acho que ainda pode melhorar:

-A área da imagem cobre cerca de 100km x 100km. A imagem classificada tem 10m/px. O método permite obter cerca de 250 novos nós de polígonos por km2 (exemplo Monte Alegre dos Campos: 548km2, 136.853 nós), o que para a área inteira significa cerca de 2.500.000 nós. É algo que levaria muito tempo para ser mapeado no OSM somente manualmente sobre imagem Bing (ou muito possivelmente nunca viesse a ser mapeado). É possível ainda pensar em reduzir esta quantidade de nós, simplificando sobretudo linhas mais retas.

Na minha opinião de todo modo é muito recomendável simplificar e eliminar pequenos clusters de pixels, como <40x40m (~16px), que estejam “internos às matas”, ou inclusive descartar todos destas dimensões “fora das matas”, pois:
-o OSM usa simplificação de áreas de terreno, exemplo maior são as coast_lines;
-manter áreas pequenas de <40x40m, tumultua o resultado com objetos pequenos sem alta precisão para a imagem, objetos que não são objetivo do processo;
-o objetivo é mapear as áreas grandes de mata densa e mais homogêneas, sem invadir áreas de campos ou urbanização, o que já é suficientemente bem obtido pela limitação dos índices, não sendo necessários portanto este tipo de pequenas “ilhas”.

-Na filtragem, seria melhor manter o mesmo buffer de aumento e retorno de limites de áreas vizinhas. Ficou um pouco a mais, 10m maior, pra dentro da mata. Por um lado evita invadir outras coisas. Mas usando os vetores do OSM para buffer de estradas e waterway, isso já resolve

-A distinção “matas” x “o que não é mata”, é bem precisa.
A distinção matas “wood” x matas “forest”, por outro lado, é muito boa na maior parte, mas nem sempre permanece exatamente a mesma, sob os mesmos valores limites, em todas as porções da imagem. Há poucas situações em que uma é classifica no lugar da outra, por variações dos índices. Uma distinção absoluta poderia ser comprovada somente com uma análise completa de campo. O que provavelmente nunca será viável para o OSM, e pouco provável de ser feito mesmo em qualquer órgão ambiental governamental.

Em resumo, somente por mapeamento totalmente manual e sobre imagem natural como Bing, sem recorrer aos recursos de maior precisão de distinção de tipos vegetais que sensores e índices como do Sentinel proporcionam para uma classificação mais precisa, e sem contar com ferramentas de desenho automatizado (vetorização) sobre classes previamente determinadas, com controle do usuário, para desenhar grandes áreas, como o QGIS oferece:
-dificilmente se mapeará semelhantes grandes áreas de matas;
-se ainda assim forem manualmente mapeadas, dificilmente terão a precisão de distinções que sensores específicos de satélite e indices derivados oferecem como possibilidade.

Resta a comunidade avaliar:
-se é desejável e/ou aceitável esta forma de mapeamento semi-automatizado de matas;
-se é aceitável o grau de imprecisão inerente por generalização e simplificação.

Mesmo com o limite de precisão inerente ao método, pode-se observar aí melhores resultados de mapeamento, tanto em qualidade da geometria como em distinção dos tipos, do que comumente em mapeamentos manuais existentes no OSM, em geral bastante simplificados, pela própria limitação dos recursos de imagem natural.

Por favor, fiquem à vontade para tecer comentários se desejarem, como se vale ou não vale a pena investir neste tipo de processo para desenhar áreas de mata densa, em regiões de interior, para o OSM.

Location: Capão do Tigre, Bom Jesus, Região Geográfica Imediata de Vacaria, Região Geográfica Intermediária de Caxias do Sul, Rio Grande do Sul, Região Sul, Brasil

Locais onde falta mapeamento no Brasil - máscara KML para iD e JOSM

Posted by smaprs on 28 December 2017 in Portuguese (Português).

Está também disponível para download arquivo com máscaras KML de setores submapeados, para uso no iD e JOSM.
Contém os setores onde não há sequer 01 nó por habitante, “zero” (havendo habitantes no setor, conforme IBGE-Censo 2010).
Permite trabalhar com maior resolução dos limites, em menor escala. Fundidos perímetros de polígonos adjacentes.

Para download do arquivo DNH-zero-BR.zip, com os setores em KML, dividos pelas 5 regiões do Brasil,
clique aqui (via wiki), ou diretamente aqui (dropbox zip).

PASSO-A-PASSO para uso do KML no iD ou JOSMː
-Faça download do zip acima, contendo os KML das 5 regiões, e descompacte-o em uma pasta;
-Escolha o arquivo KML com a região do Brasil que você tenha interesse;
-Na tela de “edição” do iD (ou JOSM), no menu “Dados do Mapa”, simplesmente arraste o arquivo KML para a tela (ou abra a pasta).
Prontoǃ
Basta identificar um setor submapeado, destacado na sua região de interesse, verificar e completar o mapeamento básico (como rede viária, etc).

NOTA: alguns destes locais destacados, como próximo de regiões metropolitanas, ao redor de capitais, representam setores muito pequenos, como do tamanho de uma única quadra, onde há habitantes. Isso quer dizer: dentro da área em si não há nada mapeado, como prédios (por isso constam como “zero nós”), mas pode já haver bom mapeamento da rede viária ao redor. Também pode acontecer que, da época em que foram contabilizados os nós OSM (Setembro/2017), até o momento atual, já tenha sido aumentado o mapeamento. Mas de modo geral não deve ainda ter alterado muito a situação.

Location: Formoso do Araguaia, Microrregião de Rio Formoso, Região Geográfica Intermediária de Gurupi, Tocantins, Região Norte, Brasil

Locais onde mais falta mapeamento no Brasil (Nodes/Habitantes)

Posted by smaprs on 26 December 2017 in Portuguese (Português).

Está disponível para download, para uso no JOSM, a
camada-mapa de “Nós-OSM por Habitante no Brasil”,
desenvolvida a partir da contabilização do total de nós OSM no Brasil, e da Densidade Demográfica, por setores censitários, do Censo 2010 do IBGE.
Você pode fazer download:
aqui (via wiki), ou diretamente aqui (dropbox zip com imagem 3000px, previamente calibrada).

Propósito:
Ajudar a encontrar os locais menos mapeados no Brasil, proporcionalmente à densidade demográfica.
Isto é, a camada mostra graficamente, em um mapa do Brasil, a classificação dos locais (setores IBGE) conforme o índice adotado de “total de nós OSM” dividida pelo “total de habitantes”, em cada um dos 316.574 setores censitários do Censo 2010 do IBGE.

O mapa resultante destaca os locais menos mapeados, isto é, com:
-menos de 01 nó por habitante (em vermelho);
-nem sequer 01 nó por habitante, “zero” (em amarelo).
(Ver legenda).

Colocada esta camada no JOSM (em sobreposição de transparência às demais imagens, como OSM e Bing), basta fazer zoom a um local de interesse e verificar ali o mapeamento, como a presença de habitações que faltam ser mapeadas, ou sua acessibilidade (rede viária).

PASSO-A-PASSO para uso no JOSMː
-Habilite o plugin JOSM/Plugins/PicLayer, no JOSM, em configurações / plugins;
-Abra a imagem no JOSM;
-Carregue o arquivo de calibragem (*.cal) da imagem: o posicionamento correto entrará automaticamente;
-Mova para o topo da lista de camadas (layers);
-Ajuste a opacidade (~50%) de modo a permitir visualizar as demais camadas de baixo.
Prontoǃ Basta buscar um local para mapear.

A documentação completa está em:
https://wiki.openstreetmap.org/wiki/Demografia_do_Brasil_como_auxiliar_no_OSM

Location: Formoso do Araguaia, Microrregião de Rio Formoso, Região Geográfica Intermediária de Gurupi, Tocantins, Região Norte, Brasil

Dymaxion Globe backlighted

Posted by smaprs on 15 November 2017 in English (English).

Dymaxion Globe, finally backlighted version (A3 paper size and acetate sheet, handcrafted).
I know, not 100% ok. First try.

Location: Praia de Belas, Porto Alegre, Metropolitan Region of Porto Alegre, Região Geográfica Intermediária de Porto Alegre, Rio Grande do Sul, South Region, Brazil

Concentração de 2/3 da população total do Brasil em 1/5 dos municípios

Posted by smaprs on 9 September 2017 in Portuguese (Português).

Conforme estimativa populacional IBGE 2017:
Os 1.114 Top 20% municípios (1/5 dos 5.570 no Brasil) em densidade demográfica de 66,36 a 12511,59 hab/km2.
O somatório da população estimada destes é: 137.988.243 habitantes, 66,4% da população total estimada do Brasil, de 207milhões.
2/3 da população do Brasil estão nestes municípios, destacados no mapa abaixo.

Isso significa que nestas pequenas áreas do Brasil devem estar cerca de 2/3 das vias residenciais e similares, Pontos de Interesse (POIs), construções, e tudo o mais relacionado ao mapeamento urbano.
Não significando obviamente que o restante 1/3 do Brasil não necessite.
Para questão do mapeamento de áreas urbanas, densamente povoadas, o mapa abaixo indica possibilidades de foco.

Fonteː
Estimativas populacionais para os municípios e para as Unidades da Federação brasileiros em 01.07.2017
http://www.ibge.gov.br/home/estatistica/populacao/estimativa2017/estimativa_dou.shtm

Location: Crixás, Microrregião de São Miguel do Araguaia, Região Geográfica Intermediária de Porangatu-Uruaçu, Goiás, Região Centro-Oeste, 76510000, Brasil

uMap: 3D Modelos Digitais de Elevação

Posted by smaprs on 26 June 2017 in Portuguese (Português).

Alguns modelos 3D que fiz com QGIS, plugin Qgis2threejs (https://plugins.qgis.org/plugins/Qgis2threejs/), NASA SRTM, imagens de várias fontes (créditos no modelo e/ou metadados), mais alguns dados do OSM, mapeados no uMap.

Alguns modelos podem demorar um pouco para carregar (de 6 a 12MB).

http://umap.openstreetmap.co/m/1095/

Alt text

Location: 0.000, 0.000

uMap of some 3D Digital Elevation Models

Posted by smaprs on 26 June 2017 in English (English).

3D Models made with QGIS, plugin Qgis2threejs (https://plugins.qgis.org/plugins/Qgis2threejs/), NASA SRTM, Images from various sources (credits printed and/or quoted in metadata of each model), some OSM data. And uMap of course.
Some models may take a while to download (6 to 12MB).

http://umap.openstreetmap.co/m/1095/

Alt text

Location: 0.000, 0.000

Mount Everest 3D DEM - real time orbit view

Posted by smaprs on 30 May 2017 in English (English). Last updated on 14 June 2017.

Hi, I share here a 3D digital elevation model of Mount Everest I’ve made, showing the main climbing routes and localities, with Landsat image backgound.

See and browse it at:
https://smaprs.github.io/Everest-3D/

Hope you enjoy it. 3D digital elevation model of Mount Everest

Made in QGIS using:
-Nasa Shuttle Radar data SRTMGL1 GeoTiff image for contour lines and 3D relief model, obtained from https://gdex.cr.usgs.gov/gdex/ (https://wiki.openstreetmap.org/wiki/SRTM#Official_versions);
-Background Image LANDSAT 4 Geo Tiff LC81400412016324LGN00.tif Date:2016/11/19. Courtesy of the NASA EOSDIS Land Processes Distributed Active Archive Center (LP DAAC), USGS/Earth Resources Observation and Science (EROS) Center, Sioux Falls, South Dakota. Online resource: USGS Global Visualization Viewer - http://glovis.usgs.gov/
-Contour lines made with Raster plugin from GdalTools;
-Qgis2threejs (https://github.com/minorua/Qgis2threejs), very frienldy to use (just confirm project CRS is set to EPSG:3857);
-Map data (location points and lines) from OpenStreetMap.

Thanks to members of brazilian OSM community for many tips, specially to brazilian OSM contributor http://www.openstreetmap.org/user/cassioeskelsen for helping when I was struggling with parameters, he works with and knows a lot of GIS.

This derived work I’ve made is free to copy and share under CC-BY-SA 2.0. It’s only for non-comercial use, meaning educational.

Location: Tashi Dzom, Tingri County, Shigatse, China

uMap "OSM 'Find-a-plane' "

Posted by smaprs on 26 April 2017 in English (English).

Global map of airplanes found “on-the-fly” at OSM background imagery:

See at: http://umap.openstreetmap.co/m/979/

*Just zoom max to the plane and click in “open in iD” at left.
You can ad other planes you’ve found…

Example:
Alt text
(at https://www.openstreetmap.org/edit?editor=id#map=17/-18.12747/-45.78904)

Location: Veredas, João Pinheiro, Microrregião Paracatu, Região Geográfica Intermediária de Patos de Minas, Minas Gerais, Southeast Region, Brazil

"O que é o OSM" e "Como funciona" (PDF apresentação/presentation)

Posted by smaprs on 27 November 2016 in Brazilian Portuguese (Português do Brasil). Last updated on 27 January 2017.

Olá,
por sugestão da comunidade OSM-BR, apresento aqui para toda a comunidade OSM em língua portuguesa o PDF que fiz para apresentação sobre “O que é o OSM” e “Como funciona”.
Fiquem à vontade para usá-lo, se lhes for útil para alguma apresentação, divulgação, etc.
O uso em PDF é útil por permitir o acesso direto aos links explicativos durante uma apresentação.

PDF: https://wiki.openstreetmap.org/wiki/File:PALESTRA_OSM_2016.pdf

DOCX original: https://www.dropbox.com/s/cot3xd2vq6dnu4h/PALESTRA%20OSM%202016.docx?dl=0

(Livre para usar, fazer download, adaptar, distribuir)

World Map in Dymaxion Projection (print-cut-fold-and-glue)

Posted by smaprs on 5 November 2016 in English (English). Last updated on 12 November 2016.

Hi,

Here there are two OSM based print-cut-fold-and-glue artwork for kids (and not so young), to share and help to spread OSM and geography interest:

World Map in Dymaxion Projection

Composed by OSMuser:smaprs (with QGIS and image editor) and with a little help from Brazilian OSM Comunity and others. - Free for copy and share under CC-BY-SA 2.0

Country names: www.openstreetmap.org © OpenStreetMap contributors

Grid/Country borders at: www.naturalearthdata.com (blank version)

Base Map: OSM Landscape www.thunderforest.com (colour version)

Ocean Floor Relief: Global Map Projector Equirectangular www.giss.nasa.gov

Dymaxion python script at: www.emergentweirdness.blogspot.com.br

To fit in Dymaxion Projection the OSM Base Map had to be firstly converted to a Plate-Carreé projection in 2:1 aspect ratio PNG picture. This was done in QGIS.

English version printable: OSM World Landscape: wiki / Blank Globe for colouring: wiki

OSM Landscape Layer https://wiki.openstreetmap.org/wiki/File:1-Dymaxion-OSM-Land-2970px.jpg

Blank version for colouring https://wiki.openstreetmap.org/wiki/File:1-Dymaxion-Branco-2970px.jpg

Done!

Folding dymaxion schema! All these pictures I did, they are free for copy and share under CC-BY-SA 2.0

Instructions:

-Print and cut at thicker outer lines.

-Firstly do all folds, pressing them for both sides to make paper more ductile, then you can start to glue contiguous tabs.

-Last triangle may be just fit, not glued.

-In larger scales you may do it in thicker paper.

-Also it can be done a small hole in poles, to pass a line to hang the globe. (Tip: with this small hole, you can also carefully pass a folded wire through inner side to press last tabs to glue if you want, then remove the wire…)

Hope you like it. Try to do it.

Location: 0.000, 0.000

TMS layer of Comparative Map of Brazilian Roads (IBGE x OSM)

Posted by smaprs on 3 September 2016 in English (English).

Purpose: to help on easy identification and zooming in undermapped areas, mainly for roads still missing on OSM map, on basis of IBGE data (Brazilian Institute of Geography and Statistics - Data publicly available according to legal statements).

Documented at (in portuguese): “Situação do Mapeamento de Estradas no Brasil”.

Feeling the lack of some data that could easy identify and help to improve on basic mapping in undermapped areas of Brazil, regarding accessibility, I’ve firstly decided to try to do a single georeferenced PNG image showing where there could be these areas, generated with QGis to use in JOSM with Piclayer plugin. Then tried a TMS layer.

Our community keeps doing great efforts on mapping. Mostly metropolitan and urban areas are well mapped for general accesibility. Also are rural and inner country roads linking main urban zones. Many data recently delivered for legal public use by IBGE is helping on the mapping on OSM. These data lead to identify many other roads that area still missing on OSM. Almost no data from GPS layers in the huge areas of inner country, as expected too.
So I’ve started trying to do a map that could help to identify roads from IBGE that are missing in OSM.

These two sources of data were used on this Comparative Map:
* roads from the .shp of IBGE (compiled untill 2015);
* roads from the current state of OSM map (2nd half of 2016), obtained from geofabrik.de (file “roads.shp”).

The methodology adopted was as simple as I could attempt to do in QGIS: just overlaying IBGE ways (in orange and yellow) with OSM ways (in dark blue), so to highlight IBGE roads, no need for overlapping analysis. Just colors:

Zoom 5: Identifying and zooming in to undermapped areas (next example highlighted)
Zoom 5: Identifying and zooming in to undermapped areas (next example highlighted)

I’ve started to generate this map in TMS tiles, with transparent background, using QTiles plugin in QGis, with precious technical help from [user:naoliv] (http://www.openstreetmap.org/user/naoliv). Decided to do it from zoom 3 to 9: it took 5 hours of processing and 110MB to generate 4850 TMS tiles in PNG 256px. [User:wille] (http://www.openstreetmap.org/user/wille) is helping hosting the 110MB tiles on his server, and many others are helping on improvements and using the TMS layer to map. Maybe another day I’ll generate zoom 10, it’s expected it’ll take around 20 hours and 400MB. Further zooms would take additional 4x time and size each zoom, so up to 80 hours and almost 2GB if zoom 11, with only 2x gain in resolution from 10 to 11. The aim was to help on identifying location of official roads still not mapped. It was achieved, so that’s enough for now. From zoom 9 to closer zooms the purpose is, as expected, to trace the identifyied missing roads from hi-res satellite imagery.

Zoom 9: road labels and zoom limit
Zoom 9: road labels and zoom limit

Zoom 11 and 14: road detected in hi-res image to map in closer zooms
Zooms 11 to 14: road detected to map in closer zooms

So now we have another tool to help on improving road mapping in Brazil. We expect to update this TMS layer as the road mapping increases, perhaps once a year.

This TMS layer “Comparative Map of Brazilian Roads (IBGE x OSM)” is available here:
http://tms.openstreetmap.com.br/ibgeXosm/{z}/{x}/{-y}.png

Location: Aquidauana, Microrregião de Aquidauana, Região Geográfica Intermediária de Corumbá, Mato Grosso do Sul, Central-West Region, Brazil

Sharing the experience on import of buildings in Brazil

Posted by smaprs on 31 July 2016 in English (English).

Recently in Brazil the OSM community is getting authorized access to georeferenced building material from city governments (in a registry level of detail) for use in OSM.
Some imports of buildings started, for example, in Porto Alegre, São Paulo and Rio de Janeiro. Many members of brazilian OSM community are helping in many ways with these imports.

There have been found some different peculiarities and procedures between each case, also some similarities, that I would like to share a brief comment, after suggested by fellow mappers.

In Porto Alegre, city government office responsible for cartography also released a layer of geodetic survey marks visible in imagery, so it helps much to adjust imagery offset with precise coordinates, and to adjust previous data in OSM in the area when in conflict with the buidings new data. Convertion of the original SHP to WGS84 and its fields to OSM tags has been done in QGIS.

The main issue in Porto Alegre and Rio de Janeiro (this one still under progress) has been on the internal validation of overlapping vertical layers of building parts, to avoid any sort of conflicts, like “duplicated nodes” or “building inside building”. Previously, it was also checked in QGIS for overlapping between the polygons of new buildings and the existing buildings in OSM, so to filter and remove the new ones where there were already mapped in OSM, and saved the rejected ones in a backup file for further eventual interest in replacing geometry.
Both doccumented here:
Porto Alegre building import
Rio de Janeiro building import

The issue of overlapping building parts:

In Porto Alegre, the original data of vertical building parts was converted to the following OSM tags (translated):
-from original BLOCKS=(1:not tagged),2,3,4… to OSM layer=(0:not tagged),1,2,3,..
In this case it had not shown much overlapping problems (only 0,1% of cases of duplicated nodes to solve), so the validation could run easier. It was done in bunches of around 40.000 objects (around 6.000 building polygons), to keep under the limit of 50.000 objects for uploading in 1 changeset in JOSM.
I’ve called the two steps of validation as “internal”, concerned only on the data of new buildings, and “external”, involving all OSM existing data in the area too.
After some 15 minutes all internal conflicts can be solved. Then some more 30-60 minutes to solve all external conflicts with OSM previous data (like ways crossing buildings), and finally 100% validated and ok to upload.

In Rio de Janeiro, the data of building parts has fields with more precise topographic data, for elevation (ele), height, and top level (we agreed to name it top_ele=*, at least as a provisory tag, to ensure to keep this data in OSM because it helps much to solve overlapping conflicts).
But in this case there are no tags for separation in vertical parts.
Apart of this, some buildings were originally mapped as multipolygons (for the negative building parts), many others weren’t.
So, when validating, the buildings with more than one part originally tagged as building=* in vertical arrangement (around 10% of all) have been detected in the class of “building inside building” conflicts (guess there can be more than a million to validate; so it’s comprehensible that I’ve got deeply annoyed every time I have to read these what.3.words again).
These overlappings need to be solved case by case, comparing, in each building, the top level (top_ele=*) of all its building parts, so to tag these parts as layer=* according to the superior top levels. It’s been working, though it takes a lot of time.

Overlapping example

Another possibility could be arranging those cases in 3D relation of type:building, but in this case, although building:part being kept in the database, it’s not considered for OSM 2D basics.

Don’t know much about the other experiences in other cities around the world.
Perhaps similar sort of difficulties would be find in many other cases of building imports around the world as it’s increasing in OSM.

As a last comment, I was wondering if wouldn’t it be nice if there was a software/plugin that could do it. I’m not a programmer, dont’ know how to do it. Just have experienced the manual procedures to solve these cases. I was thinking that what some software could do in this case is something like returning the data of JOSM validator warnings of overlappings like “building inside building” (or performing a similar evaluation), and comparing the levels of building parts, so to tag it as layer=* (alternatively, perhaps creating a relation of type=building with its respective members for building:part).

Sorry if it’s not in good english.

Location: Saara, Centro, Zona Central do Rio de Janeiro, Rio de Janeiro, Região Geográfica Imediata do Rio de Janeiro, Região Metropolitana do Rio de Janeiro, Região Geográfica Intermediária do Rio de Janeiro, Rio de Janeiro, Southeast Region, 20061-021, Brazil

There's a road out there to be mapped.

Posted by smaprs on 8 December 2015 in English (English).

Location: Casa Poggiolo, Bobbio, Piacenza, Emilia-Romagna, 29022, Italy