[Talk-br] Como guardar cache das imagens do Bing no JOSM

[Sérgio V .]

Tava olhando algumas anotações que fiz das experiências de fazer download de 
imagem de satélite com o SASPlanet.

Para salvar imagem de uma área de 10Km x 10Km:

Para Zoom 20 (mapear detalhes), resolução de 4 pixels / metro: dá 40.000x40.000 
pixels,  arquivo imagem PNG de cerca de 1.6GB.

Para Zoom 18 (mapear vias), resolução de 1 pixel / metro: dá 10.000x10.000 
pixels,  arquivo imagem PNG de cerca de 100MB.
- - - - - - - - - - - - - - - -

Sérgio / user:smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Como guardar cache das imagens do Bing no JOSM

[Sérgio V .]

Santamariense, usei uma vez o SAS Planet 
(http://wiki.openstreetmap.org/wiki/SAS_Planet), dá para fazer download das 
imagens.

Dá arquivos muito pesados.  Escolhe a área e a resolução. Tem que fazer só para 
áreas de interesse, para não pesar muito. Depois pode usar como imagem de fundo 
no JOSM, e posiciona com alguma outra referência (coisas já mapeadas). Mas não 
me lembro qual o procedimento. Tens que dar uma olhada no manual (é em 
russo).


SAS Planet - OpenStreetMap Wiki
wiki.openstreetmap.org
>From OpenStreetMap Wiki. Jump to: navigation, search. Help




- - - - - - - - - - - - - - - -

Sérgio / user:smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] mudança de estilo conforme escala

[Sérgio V .]

Kátia, os estilos que se visualiza (render) seguem as tags para highway (e tb. 
surface nos navegadores GPS) .

Não sei se era também esta questão, mas uma base para a classificação de 
estradas você pode encontrar em 
http://wiki.openstreetmap.org/wiki/Pt-br:How_to_map_a .

De todo modo, sobretudo em interior do país, se possível, se há conhecimento do 
local ou dá para ver nas imagens de satélite do OSM, importante adicionar 
"surface" com tag apropriada (unpaved, etc). Os aparelhos de GPS permitem fazer 
exclusão de não pavimentadas em roteamento.



Att.,

- - - - - - - - - - - - - - - -

Sérgio (user:smaprs)
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Legalidade de uso de SRTM da Embrapa

[Sérgio V .]

Oi Santamariense, dá para exportar do QGIS para o JOSM:

-adiciona a tag "ele=*" (e o que mais precisares no procedimento de 
interpolação que propusestes);

-salva como .shp em WGS84;

-abre o .shp no JOSM usando o plugin OpenData e já salva como .osm;

-faz a validação necessária para verificar validade de tags, etc (no QGIS o 
limite de valor para campos/keys é de 8 caracteres se não me engano, então por 
exemplo uma  tag como "description" fica interrompida como "descript": tem que 
selecionar tudo no JOSM e reescrever "description" na key);

-faz download da área, valida e importa. E pronto.


Pelo que entendi, dá para usar o SRTM do OSM. É de uso livre para isto mesmo.


- - - - - - - - - - - - - - - -

Sérgio / user:smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Mapeamento grupo de alunos USFC

[Sérgio V .]

Prezados, boa tarde.



Para comunicar, há um grupo de alunos de geologia da UFSC fazendo um extenso 
mapeamento prévio na região do Parque Estadual da Serra do Tabuleiro onde farão 
trabalhos de campo.  A iniciativa sem dúvida é muito boa.  Segundo conversado 
com alguns deles e o professor, ao longo destes meses irão levantar mais dados 
em campo.



Estão iniciando, então provavelmente haverá coisas que necessitem ir 
aprimorando. Pelo que tenho visto têm tido cuidado com o que já existe mapeado. 
Foi comunicado a eles as informações do Wiki Project Brazil, classificação de 
vias (no caso deles sobretudo rurais), etc, dicas e contatos, e o mais que 
precisarem de informações.


- - - - - - - - - - - - - - - -

Sérgio (user:smaprs)
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Remoção de "Picos" falsos ao entorno de Pouso Alegre

[Sérgio V .]

Acho que seria bom conservar os dados de altitude do layer IBGE.

Por outro lado, de fato vi marcações de altitude do IBGE em regiões de 
coxilhas, com pouco desnível. São dados gerais de planialtimetria.

Eu também marquei muitas como peak, por não encontrar outra tag mais adeaquada.


Ridge não é propriamente cume, mas significa crista, serra, uma linha 
imaginária que une os cumes ou pontos mais altos, que identifica o divisor de 
águas de onde correm rios necessariamente para lados opostos. Sempre há algum 
divisor de águas, mas não se costuma usar ridge para marcar em  terrenos de 
pouco desnível. Todo morro ou colina tem um ponto mais elevado, mas não 
necessariamente é um pico (abrupto). Depende de classificação segundo a 
proeminência topográfica (desnível mínimo), mas aí é mais complicado. Se houver 
indicação oficial ou mesmo popular, creio que é válido. Mas o dado de altitude 
certamente tem valor.


Adiante seria bom que houvesse uma tag mais adequada para dados de topografia, 
muitos podem não necessariamente ter elementos físicos no terreno como um marco 
geodésico, survey_point ou peak, mas apenas marcados em planta. Porém um dado 
efetivo e de valor para constar nos mapas. Aí talvez se poderia apenas 
substituir a tag peak, onde não for condizente, por algo que indique 
levantamento topográfico que não seja marco concreto ou pico.

A tag survey_point, como vem descrita no wiki, não envolve tudo o que pode ser 
dado medido, mas restringe a um marco físico no terreno, como em geral o ponto 
de origem de uma estação de medição.
O bom seria manter de todo modo o dado de altitude (ele, e source:ele).


- - - - - - - - - - - - - - - -

Sérgio (user:smaprs)
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Cedência dos dados de cartografia da Prefeitura de Porto Alegre / Importação Prédios

[Sérgio V .]

Boa tarde pessoal,

consegui autorização formal da Prefeitura de Porto Alegre para cedência dos 
dados de cartografia para o OSM em shapefile/SHP.

Minha idéia é preparar a importação dos Prédios, conforme abaixo.

Vou criar página no wiki (talvez com nome "Importação dos Dados de Cartografia 
da Prefeitura de Porto Alegre-RS: Prédios"), com cópia do processo com a 
autorização.

O responsável pela coordenação de cartografia propôs solicitar ainda ao setor 
de processamento de dados a malha viária que estava sendo atualizada para 
fornecer também. Mas esta de todo modo já está bem completa em Porto Alegre.


Os dados fornecidos pela Prefeitura (PMPA) em SHP contém (2.2GB tudo):

-Altimetria;

-Eixos Urbanos;

-Energia/Comunicações;

-Estrutura Urbana

-Hidrografia

-Mineração

-Sistema de Transportes

-Vegetação


Meu interesse é mapear os prédios.

Minha idéia é ir preparando importação dos prédios cadastrados pela PMPA para o 
mapa.

Pretendo fazer assim:

-abrir no QGIS e verificar os atributos dos objetos para ver o que tem e se 
pode ser convertido e importado para as tags padrão do OSM (como numeração, 
altura, etc);

-converter para o OSM;

-abrir no OSM num layer1 separado e salvar para verificação (sem fazer upload 
ainda no OSM);

-abrir os prédios que já estão no OSM em POA (ways como building=*) em outro 
layer2;

-analisar e comparar com os prédios que já existem mapeados, para ver o que já 
esteja correto e pode manter sem substituir;

(grande parte dos prédios no centro de POA fui eu que mapeei, nestes se for 
melhor deleto e substituo pelos prédios da nova importação;

-se tiver prédios errados no OSM (ex.: 2 prédios mapeados como se fossem 1) 
vejo se precisa corrigir ou substituir, mantendo as tags de informações já 
mapeadas;

-depois que tudo estiver verificado, importar os prédios para o OSM.


Quaisquer questões ou sugestões, comuniquem


- - - - - - - - - - - - - - - -

Sérgio (user:smaprs)
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Cedência dos dados de cartografia da Prefeitura de Porto Alegre / Importação Prédios

[Sérgio V .]

Oi Nelson e Blade,


A minha idéia é não substituir o que já existe de prédios mapeados no OSM.

Importar somente onde não tenha ainda.

Deixar os que já existem.

Já baixei no overpass tudo o que é building=* dentro do município.


Comparar visualmente, 2 layers um em cima do outro, 2 cores.

Se tiver prédio no OSM com forma muito discrepante, penso em duas alternativas:

-ajustar a forma manualmente o que foi mapeado por outros;

-nos prédios que fui eu mesmo que desenhei a primeira versão, e que não há 
alterações posteriores de outros, prefiro deletar e substituir, por 2 motivos: 
é mais rápido e o dado da PMPA é mais confiável do que o desenho sobre o Bing;

-remover do layer a ser importado os prédios que "já tem" no OSM.


Não sei ainda como filtrar consulta espacial no QGIS (intersecção, 
sobreposição), vou ver se descubro, e se isto de fato ajudaria mais, tornaria 
mais rápido.

Se puder, me indique como é.

Mas acho que de todo modo comparar visualmente com 2 layers e 2 cores 
contrastantes resolve.

Se tiverem outra idéia, por favor me avisem. De todo modo creio que vou levar 1 
a 2 semanas para ter pronto.

Obrigado, abs.


- - - - - - - - - - - - - - - -

Sérgio (user:smaprs)
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Cedência dos dados de cartografia da Prefeitura de Porto Alegre / Importação Prédios

[Sérgio V .]

Nelson,

>Você vai apagar os objetos existentes e inserir novos ou apenas
>substituir os atuais? (mantendo histórico dos objetos, portanto)

Tem como substituir um objeto "anterior (existente)" por outro(novo) e copiar 
para o "novo" o histórico do "anterior"?

No JOSM?

Como é que faz?

Obrigado


- - - - - - - - - - - - - - - -

Sérgio (user:smaprs)
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Limite de cidades com distritos

[Sérgio V .]

>Há enormes regiões sem qualquer mapeamento digno de nota, estradas rurais 
>estão completamente ausentes na maioria das regiões, muitos rios importantes 
>faltam, cidades importantes estão sem mapear...

>Então, que tal a gente concentrar nas milhares de coisas que faltam...abraço 
>Gerald


+1

- - - - - - - - - - - - - - - -

Sérgio (user:smaprs)
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Dados de cartografia da Prefeitura de Porto Alegre / Importação Prédios - preparação

[Sérgio V .]

Desculpem, foi com link quebrado.

Link certo:

http://wiki.openstreetmap.org/wiki/Importa%C3%A7%C3%A3o_de_Dados_de_Cartografia_da_Prefeitura_de_Porto_Alegre_(PMPA)_-_RS


- - - - - - - - - - - - - - - -

Sérgio / user:smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Dados de cartografia da Prefeitura de Porto Alegre / Importação Prédios - preparação

[Sérgio V .]

Pessoal, bom dia.

Como conversado anteriormente, estou preparando o material com vistas à 
proposta de importação dos dados de cartografia cedidos pela Prefeitura de 
Porto Alegre (PMPA). Meu foco inicial é na importação dos prédios levantados e 
mapeados pela PMPA.

Novamente agradecimento ao valioso auxílio do Nelson/naoliv na filtragem 
inicial no QGIS.


Estou preparando esta página com descrição do andamento, para informação geral:

http://wiki.openstreetmap.org/wiki/Importa%C3%A7%C3%A3o_de_Dados_de_Cartografia_da_Prefeitura_de_Porto_Alegre_(PMPA)_-_RS


Estou procedendo uma verificação geral do material. Creio que leva algum tempo 
para verificar suficientemente. Possibilidade de importação somente depois 
disto. Desenvolvo nos tempos de disponibilidade. Penso que inicialmente leve 
umas 2 semanas.


Quaisquer questões, só comunicar. Pode ser por aqui também para registro.

Saudações,

- - - - - - - - - - - - - - - -

Sérgio / user:smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Importação PMPA / Prédios : esquema de conversão para o OSM

[Sérgio V .]

Oi Gerald, obrigado, também contado com o valioso auxílio do @naoliv e diversas 
dicas do @nighto e do pessoal sobre tratamento do material.


Sim, bem lembrado, de fato vou criar uma conta dedicada para os restantes 97%. 
Só foram 3% de upload até agora.

A documentação já está documentada ali, em: 
http://wiki.openstreetmap.org/wiki/Porto_Alegre,_Rio_Grande_do_Sul/Importa%C3%A7%C3%A3o_PMPA



O pacote com os próximos 10% dos 500.000 polígonos totais (ways) já está pronto 
para upload (ainda não feito), está 100% validado, sem um único erro ou 
warning, cerca de 50.000 objetos (polígonos) em 50MB.


Estou pensando se vale a pena mandar este upload num changeset só (com 
requisição por pacotes de 100 objetos), ou se ainda precisaria subdividir mais. 
O pessoal falou que o limite do JOSM é 50.000 objetos.


Mas a ver como é de fato esta contabilização de objetos (para o limite de 
50.000)?

-se é por polígonos como no QGIS,

-ou pelo somatório (nodes+ways+relation) como o JOSM mostra.


Pois no caso do pacote de 50MB, a contabilização é:


ARQUIVO:

PMPA-SETOR: 01-12  (de 51 setores)
Arquivo .shp(+dbf+...):51,8MB
Arquivo .osm:  50,4MB


NO QGIS:

TOTAL DE OBJETOS na

tabela de dados d

o .shp: 53.013


NO JOSM:
WAYS no .osm:  54.498
NODES no .osm: 402.211
RELATIONS no .osm: 839
TOTAL DE OBJETOS no .osm:  457.548

Neste caso então, na contagem do JOSM, seriam 457.548 objetos.

Se contar como limite 50.000 objs., teria que dividir o "total" para 10 pacotes 
de 50.000 objetos, com cerca de 5MB cada.

- - - - - - - - - - - - - - - - - - - - - - - -

Por outro lado, o último upload dos prédios PMPA, que foi para 3 bairros (Rio 
Branco a Floresta), contabilizou:

Arquivo .osm:8,6MB

WAYS no .osm:   8.817

NODES no .osm: 64.866 RELATIONS no .osm: 176 TOTAL DE OBJETOS no .osm:

73.859

Então o JOSM ali aceitou automaticamente 73.859 objetos . Que eu lembre demorou 
+/- entre 15 min a 1/2 hora no máximo.


- - - - - - - - - - - - - - - -

Sérgio / user:smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Importação PMPA / Prédios : esquema de conversão para o OSM

[Sérgio V .]

Boa noite pessoal.

Deu certo fazer no QGIS a conversão das tags do SHP-PMPA total de 500MB / 
500.000 objetos, dividir em SHP menores (50MB), e importar estes direto para o 
JOSM.
100% validando no JOSM (ainda não feito o upload).
Obrigado pelos auxílios e dicas.



Compartilhando o procedimento adotado:


No QGIS:

1. Aberto SHP-PMPA original de 500MB / 500.000 objetos (equivalente a 500.000 
ways em .osm);

2. Convertidos CAMPOS e VALORES de uma só vez nos 500.000 (com o Table Manager 
e Field Calculator); adicionados CAMPOS 'note' e 'layer; apagados CAMPOS sem 
uso para o OSM (e porque causam problema de validação por 'tag inválida');

3. Dividido SHP original de 500MB / 500.000 objetos (ways) em 10 arquivos 
menores .SHP de +/- 50MB, conforme os SETORES no original.



No JOSM:

4. Aberto SHP (com plugin OpenData) de 50MB e salvo como .osm:

Por enquanto, testado só com o 1º SHP de 52MB.

(funcionou melhor que ogr2osm, pois veio sem tags 'vazias' ('null'): o ogr2osm 
dá problema de não apagar as tags com valor null, que depois no JOSM acusaram 
50.000 problemas no validador, e teria que apagar de novo tudo no JOSM.)

5. Apagado campo original "SETOR" (só usado para subdividir o SHP);

6. Passado validador no JOSM (com as tags convertidas antes no QGIS):

-Dos 54.498 ways, acusou apenas:

a)ERRORS:   Duplicate ways(36=menos de 1 por 1.000)  - casos em que ways inner 
foram duplicados, fazendo parte de 2 multipol: da base e do corpo.

Resolução: removido multipolígono da base e ways inner, mantidos só way 
(ex-outer) da "base" adicionando building=yes e relação multipolígono do 
"corpo" com respectivos inner.

:OK, CORRIGIDO E VALIDADO

b)WARNIGS:

Building inside building (1)

:OK, CORRIGIDO E VALIDADO

Ways with same position (2)

:OK, CORRIGIDO E VALIDADO

Mixed type duplicated nodes - Duplicated nodes (1)

:OK, CORRIGIDO E VALIDADO

Key 'description' invalid. - Property values contain multiple white spaces (9) 
- casos de campo 'description' com string variável

:OK, CORRIGIDO E VALIDADO



STATS:



PMPA-SETOR: 01-12  (de 51 setores)

Arquivo .shp(+dbf+...):51,8MB

Arquivo .osm:  50,4MB

TOTAL DE OBJETOS no .shp:  53.013

WAYS no .osm:  54.498

NODES no .osm: 402.211

RELATIONS no .osm: 839

TOTAL DE OBJETOS no .osm:  457.548



Desempenho NO JOSM:

MEMÓRIA MÁX. atingida: 2,4GB  (de 3,3GB livres)

CPU MÁX. atingida: 70%

TEMPO ESTIMADO P/UPLOAD:   3 horas (Não feito upload ainda; só comparado com o 
de 9MB que levou 30min)



- - - - - - - - - - - - - - - -

Sérgio / user:smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Importação PMPA / Prédios : esquema de conversão para o OSM

[Sérgio V .]

Ok. Vou deixar só as tags normais para 2D. Como no caso PMPA está validando 
tudo OK assim, sem precisar fixme para 2D, vou adicionar só note (quando são 
casos de multipol building com layer) explicando que para 3D terá que fazer 
survey.

Obrigado Nelson.

- - - - - - - - - - - - - - - -

Sérgio / user:smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Importação PMPA / Prédios : esquema de conversão para o OSM

[Sérgio V .]

>> naoliv

> convenção de key=S3DB:*

>Da onde você achou as tags S3DB:* ?

Inventei, ora pois. Por isto " 'proposta' convenção de key=S3DB:*". Localmente, 
para este caso (eventualmente poderia até para similares, mas inicialmente não 
é a intenção). Adaptada a partir do 
"Simple_3D_buildings, 
S3DB Proposals...). Achei que assim poderia ajudar ao menos neste caso quando 
quiser encontrar os prédios e aproveitar os que já estão em layers, quando 
quiser fazer 3D, com a chave S3DB...  Porque não tem como fazer 3D para todos 
agora. O resto que vem na sequência segue o padrão do S3DB no wiki para: 
relação type=building; role=outline (este na verdade não uma tag, mas 
indicativo do role na relação 3D); building:part=yes,... De todo modo, mesmo 
ordinariamente, quem vai fazer 3D tem que conhecer estas tags e editar em cada 
prédio manualmente, pois não tem substituição automática para colocar height=*, 
building:levels=*, que são quantitativos. Tem que fornecer de fora. Apenas que 
para aproveitar a indicação das tags de preparação para 3D na proposta, basta 
apagar onde diz "S3DB:", e acrescentar o quantitativo de andares, etc, que já 
converte em parte as tags necessárias para isto. De modo ordinário, tem que 
adicionar as tags de 3D e criar a relação. Até a relação 2D de 
type=multipolygon daria para encontrar fácil e aproveitar, basta apagar o S3DB: 
em S3DB:type=building. Gasta menos tecladas do que digitar de novo 
"type=building", etc... e as demais (onde der para aproveitar). Também já vai 
junto indicado qual é o membro outline que define a relação 3D, sem precisar 
procurar. Mas se atrapalhar mais que ajudar, deixo sem nada além das conversões 
necessárias.

- - - - - - - - - - - - - - - -

Sérgio / user:smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Problema de Prédios em Overlapping (Importação PMPA)

[Sérgio V .]

Obrigado a todos pelas ajudas.

Qualquer outra questão, por favor avisem.


Acho que está OK agora, esquematizada a questão dos overlappings em 2D. 
Resolveu usando layer=* (p/ casos de compartilhando ways) ou multipolígono (p/ 
casos de um dentro sem compartilhar ways ou 2 outer grudados no mesmo nível) . 
Uma vez que para a maioria destes de importação, se não houveracesso a mais 
informações, não tem como fazer 3D ( building:levels=*, building:part=*, etc).


Não penso em colocar agora os prédios que seja possível para 3D 
(bulding:levels, etc), depende muita coisa de survey, muitos possivelmente não 
dá pra ver em imagens atuais. Muitos prédios talvez possa com o Mapillary. Mas 
deixar pra outros se divertirem.

A estrutura básica 2D com as formas já fica assim montada, sem overlapping. 
Também ajuda para outros que quiserem adicionar POIs e mais dados, encontrando 
os prédios certos. Quem quiser, adiciona as tags 3D e altera.

Alguns fiz em 3D, para ver se dava certo.  Bem conhecidos como a casa de 
Cultura, ou que dá para ver na imagem (como a Galeria Malcon; pra isto serve a 
distorção lateral de imagens, pra contar número de andares). Testei as tags 
para 3D e tá validando tudo OK no 2D. Ainda tou vendo se fica OK no 3D.

O validador só acusa ainda 1 única coisa: "relation type unknown" (mas na 
verdade tá certo com o type=building).


Sigo preparando a importação de prédios para os outros bairros, com o esquema 
resolvido para casos de overlappings com layer (acho que uns 5% do total, com o 
que tenho visto).

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Paralelamente, pensei numa coisa, se seria possível desenvolver um script 
(programa externo ou plugin para JOSM) para:


-Resolução de overlapping com criação automática de layers, com 2 objetivos:

a)-resolver problema de polígonos de building sobrepostos na mesma área (mesmo 
terreno), adicionando layer nos sobrepostos;

b)-com isto ao mesmo tempo fica esquematizada uma estrutura básica para 
adicionar relação 3D (futuramente só procurando os polígonos com tags layer=* + 
building=* por building:part=* building:levels=*).


Acham que seria útil? Não entendo muito de linguagens de programação, e menos 
ainda das dos últimos 25 anos para cá.


Acho que poderia ser "mais ou menos" assim uma lógica (a testar) para resolver 
overlapping para 2D:

-analisa uma massa de polígonos;

-encontra e retorna os que estão em overlapping (os grudados em um lado não 
acusa, não dá problema);

-destes, encontra e retorna a maior área (o "outline", a base, ou projeção 
total das demais áreas);

-das demais áreas que estão sobre o outline, analisa:

-se estão dentro, então cria multipolígono;

-analisa as áreas destes multipolígonos e dos demais polígonos sobrepostos ao 
outline, então cria "layer=anterior+1" (limite=5) para os sucessivamente 
menores que o outline, a base (supondo comum que se há volumes sobrepostos, os 
de menor área estão sucessivamente mais acima -  a verificar se vale para todos 
os casos). O maior que não tem outra subdivisão grudada é sempre o outline. Se 
tiver outro apenas grudado, é outro prédio, podendo ser no mesmo terreno. Mas 
não analisa junto, não é problema de overlapping.

Não resolve todos os casos. Se tiver mais de 5 layers (só vi o da Galeria 
MAlcon), teria que separar para usar building:levels.


(acho que não serviria para criar building:levels automático, pois tem que 
avaliar o número de pavimentos com imagem, survey ou dados externos)


Se fosse para preparar para 3D (mas o script não pode adivinhar os 
building:levels, teria que fornecer), acho que poderia ser "mais ou menos 
assim" a lógica:

-encontra e retorna os que estão em overlapping (os grudados em um lado não 
acusa, não dá problema);
-cria com estes relação type=building
-para a área maior, adiciona:
role=outline
building=*
-para as demais áreas sucessivamente menores, adiciona:
role=part
building:part=*
building:levels=*
building:min_level=*
heigth=*
min_height=*
(NOTA: o building=* do outline não é usado para o 3D se tiver outros com 
building:part=*; para fazer a base, tem que repetir a do outline como "part", 
sem nós duplicados, e adicionar as tags semelhantes às demais, sem 
building:min_level=*, para que se torne a primeira)
Acho que seria mais ou menos assim.


- - - - - - - - - - - - - - - -

Sérgio / user:smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Problema de Prédios em Overlapping (Importação PMPA)

[Sérgio V .]

Bom dia Nelson,

>São 2 andares do mesmo prédio ou o prédio é apenas o 
>https://www.openstreetmap.org/way/414428800 ?

Sim, são 2 blocos de níveis diferentes:

O https://www.openstreetmap.org/way/414428734 é a base do prédio (térreo + em 
geral sobreloja);

O https://www.openstreetmap.org/way/414428800 é o corpo do prédio (não sei 
quantos pavimentos, uns 10).

Será que adicionando "level" ou coisa parecida sai o aviso de "buiding inside 
buiding " ou overlappings semelhantes?

Se for assim, talvez para os demais eventuais milhares de casos semelhantes 
teria que adicionar genericamente um level=0 para o bloco de térreo, e um 
level=1 para  o bloco do corpo. (E "talvez" adicionar algo como 
"fixme=verificar numero de pavimentos para  building:levels e " - não teria 
como verificar antes um por um. Não vem estes dados junto. Teria que ser só "in 
loco" (tradução livre: coisa de loco). Ou não adicionar: a informação "level" 0 
e 1 seria completa em si. Fica implícito que o resto seria a completar, como 
para tudo no OSM).

Se tiveres uma solução e quiseres testar nestes , fique à vontade. Agora que me 
dei conta disto vou testar no outro também.

Obrigado.

- - - - - - - - - - - - - - - -

Sérgio / user:smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Problema de Prédios em Overlapping (Importação PMPA)

[Sérgio V .]

Obrigado Nelson e Marcio.


O JOSM tá atualizado.

Os casos de prédios vizinhos simples grudados não tão acusando problema mesmo 
(como em https://www.openstreetmap.org/way/414428517).

Os que acusam problema são os compostos de mais de uma área: uma dentro da 
outra, ou em parte por cima, com nós ou ways sobre outros (sem multipolígono).


Sobre:

>Se você adicionar a tag de building=* nos seus prédios você vai ver que o 
>aviso de caminhos sobrepostos some.

>Só vai precisar ver o problema de "prédio dentro de prédio".


Como se resolve o

"building inside building"?

Peguei um exemplo dos importados da PMPA, o caso que o 
Papibaquígrafo me 
mandou do [https://www.openstreetmap.org/way/414428800] dentro do 
[https://www.openstreetmap.org/way/414428734]:

-Selecionei os 2 ways "building=yes" simples (sem multipolígono);

-Passei o validador, acusam só 1 coisa: "building inside building".


1)Testei com o plugin "Merge overlap": não alterou nada, os 2 ways só tem um nó 
em comum no perímetro.

2)Testei com o "Join overlapping areas": mas apaga a de dentro, ficando só o 
contorno de fora. Perde o sentido original (tipo: corpo + cobertura do prédio).

3)Fiz o "create multipolygon": ficou o multipolígono como "building=yes" (saiu 
a tag "building=yes" dos 2 membros).

Não adicionei "building=yes" nos 2 membros.

-Passei o validador (selecionados só os 2 ways):nos 2 membros não dá mais aviso.

-Passei de novoo validador (selecionada a relação multipolígono), acusou só 1 
coisa:

"Intersection between multipoygon ways"


4) Aí adicionei "building=yes" nos 2 membros.

-Passei o validador, selecionados só os 2 ways: nos 2 membros não dá mais aviso.

-Passei de novo o validador (selecionada a relação multipolígono), acusou 3 
coisas:

"Intersection between multipolygon ways";

"Building inside building" (de novo, agora na relação, não mais nos 2 ways);

"Area style on outer way" (acho que por causa do "building=yes" nos membros, 
além do multipolígono em si).


5)Se fizer "unglue" (g) no único nó em overlapping, acusa 5 coisas:

ERRO:

Building duplicated nodes - Duplicated nodes"

warnings:

"Intersection between multipolygon ways";

"Building inside building" (de novo, agora na relação, não mais nos 2 ways);

"Area style on outer way"

"Crossing buildings"


Desfiz.

6)Se remover o "building=yes" só do way "inner", acusa o mesmo que 4).

7)Se remover o "building=yes" só do way "outer", acusa de novo só 1 coisa:

-"Intersection between multipolygon ways"

8)Se fizer "unglue" (g) no único nó em overlapping, acusa 2 coisas:

"Intersection between multipolygon ways"

"Mixed type duplicated nodes - Duplicated nodes"

9)Se fizer "fix" neste nó, cola de novo, e volta ao 7).

Não resolvi. Deixei (por enquanto) como estava.

- - - - - - - - - - - - - - -

PERGUNTA:

Existe alguma destas versões de "overlapping" que seja aceitável? (válida para 
o OSM)

Qual solução?

-Se puderem, podem mostrar em cima deste exemplo mesmo do 
[https://www.openstreetmap.org/way/414428734], que aí eu vejo como ficou para 
entender o que foi alterado.

-Tem também este típico dos casos de "building inside building", com não só 1 
nó, mas todos ways em overlapping (todos os nós do de dentro estão grudados no 
de fora): https://www.openstreetmap.org/way/414743168

PS.:

-Vi que o Validator do JOSM é considerado "obsoleto" ("obsolete, Validates and 
fixes incorrect data. Part of core now.": 
http://wiki.openstreetmap.org/wiki/JOSM/Plugins). É este o caso?


- - - - - - - - - - - - - - - -

Sérgio / user:smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] limites administrativos

[Sérgio V .]

>Somos poucos e ainda há muito por fazer.
>Números de Abril de 2016 do Osmand Live:
>708 contributors in Brazil
>1382 contributors in Argentina
>Comparando esses números ao da população de cada país, não estamos bem na foto
>-- Helio Cesar Tomio / Mapeador Openstreetmap

Legal o Helio trazer estes dados.
Há 2 coisas importantes em questão, parece. Mas talvez não igualmente 
importantes.

-preocupação com o aperfeiçoamento dos dados no OSM: me parece que há boas 
discussões, de alto nível técnico, quanto ao aperfeiçoamento dos dados, e uma 
boa manutenção da qualidade dos dados; nisto parece que estamos bem;

-número, participação da comunidade: neste, como apontado, parece que temos 
ainda uma baixa taxa de mapeadores.

Estava lendo sobre isso num wiki (que parece que é o DWG que vem desenvolvendo, 
talvez os maiores guardiões da perfeição dos dados no OSM):  
http://wiki.openstreetmap.org/wiki/How_We_Map
(agora também em Pt-br: http://wiki.openstreetmap.org/wiki/Pt-br:How_We_Map).

Uma das coisas destacadas ali é:  "OpenStreetMap values community cohesion over 
data perfection."
Livremente traduzido: "O OSM valoriza em grau mais alto a coesão da comunidade 
do que a perfeição de dados".

Não significa que a que esteja abaixo deva ser descurada. Ambas as coisas são 
importantes.
Mas em se tratando de escala de valores, a ordem afeta o resultado.

Faz toda a diferença quando nos damos conta de qual, aparentemente, esteja 
sendo mais atendido e qual carece mais.
E parece que isso pode se manifestar em várias coisas. Desde o modo como 
eventualmente falamos com os demais frente a uma preocupação por um aspecto do 
projeto que deva ser aperfeiçoado, o contato com novos, a difusão, a instrução, 
etc. Enfim, valores da coesão da comunidade.
Atingindo o que vem primeiro em grau de importância, parece que o outro tende a 
ficar mais fácil de atingir também. Este é o sentido de uma escala de valores.
Parece que é assim que tende a funcionar.

- - - - - - - - - - - - - - - -

Sérgio / user:smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Problema de Prédios em Overlapping (Importação PMPA)

[Sérgio V .]

Pessoal, boa noite.
Por favor, se alguém puder apontar uma luz para o seguinte problema, que está 
aparecendo enquanto estudo a importação dos prédios do arquivo .SHP cedido pela 
Prefeitura de Porto Alegre para o OSM:
PROBLEMA DE PRÉDIOS EM OVERLAPPING (WAYS DE CONTATO, DUPLICADOS E SEM RELAÇÃO 
DE MULTIPOLÍGONO):
-Foram examinados os "poucos" (cerca de 4000) prédios que foram importados para 
o OSM, do Centro da Cidade;
-E também examinados, por amostragem, os demais 500.000 da PMPA “ainda não 
importados” (em exame).
- - - - - - - - - - - - - - - - -
O que acontece é o seguinte:
TODOS os polígonos de prédio do .shp da PMPA, que estão na situação de 
“grudados” em outro, estão em “overlapping”: os contatos, ou divisas, estão com 
“2 ways” (um de cada polígono, exatamente sobrepostos).
Todos estes casos o validador do JOSM acusa: “warning” para “overlapping ways”.
Acontece nos casos de:
1- "Um mesmo prédio" com “Vários polígonos” (são uns 5% dos 500mil. O resto é 
polígono único). (Há havendo alguns casos que “já estão em relação de 
multipolígono”. Talvez mapeamentos em épocas distintas. Alguns estão até com “2 
relações multipolígono” para o “mesmo prédio”: para o contorno total; e para as 
reentrâncias)
2- Entre prédios "vizinhos". Este é o pior: são uns 99% em divisas de terrenos, 
dos 500mil. Mesmo os prédios de único polígono, mas grudados no vizinho.
- - - - - - - - - - - - - - - - -
Como neste exemplo da “Casa de Cultura Mário Quintana”, e seus vizinhos, no 
Centro Histórico:
http://wiki.openstreetmap.org/w/images/8/89/Teste-Validacao-JOSM-overlapping-way-CCMQ-1.jpg
-A casa possui vários polígonos grudados, que não estão em MPol: estão em 
“overlapping”;
-Seus vizinhos também possuem polígonos em “overlapping”.
-Ela e os prédios vizinhos estão “grudados”: também estão em “overlapping”.
- - - - - - - - - - - - - - - - -
Então, como teste, transformei os polígonos, de “mesmo prédio”, em 
multipolígono. E seus vizinhos também. Cada um ficou no “seu” multipolígono.
Neste print:
http://wiki.openstreetmap.org/w/images/2/2b/Teste-Validacao-JOSM-intersection_way-CCMQ-2.jpg
Mas continua dando “warning”:
agora não mais de “Overlapping ways”, mas de “Intersection between multipolygon 
ways”.
- - - - - - - - - - - - - - - - -
(PARÊNTESE: alternativa para pesquisar os “overlapping” no “mesmo prédio”: 
Pelos campos "nome" seria possível filtrar e criar multipol. Mas a “Casa de 
Cultura” é um dos poucos casos de prédio que vem com nome no .shp da PMPA. 99% 
não tem nome.//Também seria possível filtrar o que está em “um mesmo prédio” 
pela camada dos “lotes”. Mas continua o problema de “overlapping” com vizinhos.)
- - - - - - - - - - - - - - - - -
O wiki sugere “redesenhar as formas”:
(http://wiki.openstreetmap.org/wiki/Relation:multipolygon#Valid_Multipolygon_conditions)
Mas como fazer para 99% de 500mil objetos?
- - - - - - - - - - - - - - - - -
RESUMO e PERGUNTAS:
-É assim mesmo o problema?
-É possível validar os 500mil ways grudados em overlapping (sejam vizinhos, ou 
no mesmo prédio)? Como?
Possibilidades:
A) Remover todos os ways duplicados nos contatos/divisas?
B) Desgrudar e afastar todos 1cm, depois criar MPol.?
Como? Automático? Ou um por um?
-Seria possível corrigir isto automaticamente (algum script ou ferramenta de 
algum software)? No JOSM? No QGIS? Outro?
-E se "não" for possível ou viável corrigir isto deste modo como exigido a 
princípio pelo OSM? Imagino que seria melhor não importá-los.
-E se fosse “aceitável” deixá-los assim, em estado de "overlapping ways"? 
(possivelmente para sempre...).
Mas mesmo que não fosse “errado” deixar assim, causaria um problema de poluição 
dos resultados do validador: cada vez que alguém passar o validador do JOSM na 
cidade iria encontrar "milhares" de alertas de "overlapping ways". Dificultaria 
quem quisesse encontrar algum outro "overlapping way" especificamente.
- - - - - - - - - - - - - - - - -
Senão, torna-se inviável importar.
- - - - - - - - - - - - - - - - -
Desculpem a extensão.
Sugestões são muito bem-vindas!
Agradeço antecipadamente.
- - - - - - - - - - - - - - - -

Sérgio / user:smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Dados de cartografia da Prefeitura de Porto Alegre / Importação Prédios - preparação

[Sérgio V .]

Obrigado Wille, vou testar esta calculadora no QGIS,

valeu!


- - - - - - - - - - - - - - - -

Sérgio / user:smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Dados de cartografia da Prefeitura de Porto Alegre / Importação Prédios - preparação

[Sérgio V .]

Bom dia e bom começo semana, pessoal.

Uma pergunta:


Sobre a importação dos prédios em PoA, já importei no Centro Histórico (+/- 
3500 construções novas), converti o que havia de tag compatível e com sentido 
para o OSM.


Estou pensando no seguinte para as restantes construções no mapa cadastral da 
PMPA:


São +/-500.000 (mil) construções de todo tipo no cadastro da PMPA;  eles 
mapearam tudo, até construções secundárias de serviço, depósito no pátio, 
casinha de cachorro, etc.


Uma vez que o OSM a princípio não tem o propósito de ser como um mapa cadastral 
tão detalhado quanto de uma prefeitura, estou pensando em separar e remover da 
camada a ser importada toda construção menor que 2x2m (cerca de 4m², ou soma do 
comprimento de linha 8m), ou seja, o que for inabitável. Creio que reduza um 
tanto o pesado volume de dados. Que acham?


1) Sabem se no QGIS há uma maneira de filtrar isto (por área ou por somatório 
de comprimento de linha)?


2) No QGIS fiz a troca na tabela de dados dos "nomes dos campos "para as "KEYS" 
compatíveis com o OSM (ex: de "CLASSE" para "bulding").

Mas quanto aos "valores" dos  atributos ("VALUES"), sabem se há uma maneira 
dentro do QGIS de substituir todos os "valores" idênticos na tabela de dados 
(ex.: tudo que for "ESCOLA" para "school")?

Ou tem que editar o .DBF fora do QGIS, subsituir os "values", e depois acoplar 
novamente (mas e o risco de dar bagunça no SHP)? Se sim, com qual software?


Antecipadamente obrigado,


- - - - - - - - - - - - - - - -

Sérgio / user:smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Problema de Prédios em Overlapping (Importação PMPA)

[Sérgio V .]

Ok Nelson,  vou testar o merge e com validador.  Também imaginei que não fosse 
"errado". E fiquei preocupado também com a questão de se fosse ficar aparecendo 
sempre dezenas de warning no validador para cada quadra, atrapalhando, ou cada 
um que visse iria quere arrumar, bagunçando. Mas creio que talvez o JOSM 
deveria rever isto dos warnings. Obrigado!


- - - - - - - - - - - - - - - -

Sérgio / user:smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Fotos no OSM

[Sérgio V .]

Oi Rossana,
pelo que entendo você fala de upload e geotagging manual de fotos.

O Mapillary faz upload de fotos e abre no iD e no JOSM 
(http://www.mapillary.com/).

Já tentei fazer upload manual no Mapillary mas não deu certo, fazendo o 
georreferenciamento com um programa que não lembro o nome (acho que é problema 
de fazer coincidir com formato exato para o Mapillary).

Só tem aceitado pelo automático direto do smartphone.

Tem também outros programas para geotagging manual (com o que "teoricamente" 
daria para fazer upload no Mapillary):

http://wiki.openstreetmap.org/wiki/Geotagging_Source_Photos#How_to_write_the_location_into_the_photo


Tem um esquema no JOSM, mas não sei se é bem o caso:

http://wiki.openstreetmap.org/wiki/JOSM/Photomapping


- - - - - - - - - - - - - - - -

Sérgio (user:smaprs)
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Fotos no OSM

[Sérgio V .]

Ah, e para encontrar o local com as coordenadas:

no iD: digitar na pesquisa o formato como: -28.01511,-49.59311

no JOSM: Shift+D e -28.01511,-49.59311

(ou outros formatos cf. vai mostrar; vai adicionar um ponto; zoom p/)

- - - - - - - - - - - - - - - -

Sérgio (user:smaprs)
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] osmand subdivide mapa do Brasil por estados

[Sérgio V .]

Sim, Gerald, bom trazer estas informações. Importante pensarmos nestas coisas.

Acho que cada colaborador atual já está contribuindo dentro de seu limite de 
disponibilidade.
Também cada um tem alguma coisa que domina mais, ou se interessa mais, no que 
tem mais segurança em contribuir, tanto em mapeamento propriamente dito quanto 
em difusão de conhecimento, planejamento, etc, demais outra habilidades.
Creio que todos já estão dando o seu melhor no limite que lhes é possível.
Não creio que poderá aumentar muito o volume de mapeamento com o atual número 
de colaboradores.

Então um possível foco para aumentar o mapeamento talvez seria mesmo investir 
em aumentar o número de colaboradores, pensar em como difundir, trazer novos, 
como orientar, assessorar, manter, onde propor projetos a novos, material 
didático bem acessível a oferecer, fácil de acessar, etc.
Creio que seria importante pensarmos o quê e como poderíamos fazer neste 
sentido.


- - - - - - - - - - - - - - - -

Sérgio / user:smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Rio Olympics – Tutorial para Importação de Edificações

[Sérgio V .]

Bom dia pessoal,

Já é difícil manter assuntos como projetos de mapeamento ou importações na 
pauta, e cativar interessados.
Peço a gentileza de tratarem de outros assuntos paralelos, quando for o caso, 
como sobre direitos autorais, em outro thread, para não desvirtuar o foco dos 
threads próprios.

Grato.

- - - - - - - - - - - - - - - -

Sérgio / user:smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Rio Olympics – Tutorial para Importação de Edificações

[Sérgio V .]

Claro Márcio, fiquem à vontade, é para usar mesmo.

Tá na wiki, tá pra uso.

Obrigado,

abraço


- - - - - - - - - - - - - - - -

Sérgio / user:smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] #RioOlympicsMapping: problemas a pensar solução viável

[Sérgio V .]

Boa noite pessoal.

Sobretudo para os que entendem mais de análise e programação e que 
quiserem/puderem colaborar em encontrar uma solução, mas para todos envolvidos 
ou interessados também:

No andamento da importação de prédios no Rio 
(https://wiki.openstreetmap.org/wiki/Rio_de_Janeiro_(city)/Import_IPP_Buildings),
 foi observado o seguinte problema.

Em diferentes áreas da cidade o material tem apresentado diferentes tipos de 
conflitos.

No trecho Leblon-Ipanema, em que a maioria dos prédios do SHP da prefeitura já 
entra convertido com o OpenData no JOSM como multipolígonos,  apenas poucos 
casos de sobreposição ("self-intersecting" e "building inside building"), de 
todo modo tendo que resolver individualmente, mas mais fáceis pela menor 
quantidade.

Porém em áreas em que a maioria dos prédios (tendo sido convertidos do SHP em 
WGS84 para importação no JOSM com o plugin Opendata), entram como ways em 
polígonos simples ("não multipolígonos"), surge aí o problema de centenas de 
casos de "Building inside building", necessitando todos verificação individual.

Eventualmente a solução possível poderia ser a criação de relação type=building 
(mais detalhes em Relation:building : 
http://wiki.openstreetmap.org/wiki/Relation:building#For_3D_modelling).

Parêntese: seria bom se alguém pudesse testar um pequeno trecho (talvez 
baixando o SHP da prefeitura dos dois lados da Ponta de Copacabana, onde foram 
observadas estas diferenças e conflitos) também com outro sistema de conversão 
(talvez ogr2osm) para ver se eventualmente os polígonos ao serem convertidos do 
SHP para importação no JOSM possam entrar com este conflito mais resolvido.

Com este tipo de caso em que aparecem centenas de Building inside building na 
validação.

O PROBLEMA QUE SE COLOCA É:

Existiria algum modo de converter mais ou menos automaticamente as diversas 
partes do mesmo prédio para relação "type=building"?
Ou para separar em layer=1,2,3,etc...?

Isto é, os ways polígonos do "mesmo prédio" (multiplicado por centenas de 
prédios) que seriam colocados em uma mesma relação de type=building. Tendo em 
vista a grande quantidade de prédios que se pretende importar.

O problema é distinguir e selecionar os polígonos em mesma situação 
(basicamente "role=outline" x "role=part") em grande quantidade de objetos.

Um caminho possível neste sentido seria talvez através de algum tipo de 
"análise simultânea ou sequencial" de "overlapping" e "valores de área" (talvez 
no QGIS? ou outro?), para se distinguir o maior polígono externo (ou talvez 
através de "cálculo dos valores" de ele=* eheight=*, pois em geral a maior área 
está no menor nível) e sua respectiva "seleção", para que a área externa maior 
possa receber as tags role=outline ebuilding=yes, devendo os demais ways 
restantes (invertendo a seleção) etiquetados como role=part e 
building:part=yes), e sendo criada entre estes e o membro com role=outline uma 
relação de type=building.

Para resolver o conflito de "Building inside building".

A mesma coisa seria no caso de se optar por separação em layer=1,2,3,etc...

Ou se alguém tiver outra solução.

Saudações gerais,

- - - - - - - - - - - - - - - -

Sérgio / user:smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] wiki: PROJETO "MAPEANDO COM ESCOLAS"

[Sérgio V .]

Sempre há 2 possibilidades: ou eu não entendi, ou não me foi bem explicado, 
rsrs.

Mas tá lá.

- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] wiki: PROJETO "MAPEANDO COM ESCOLAS"

[Sérgio V .]

Ok,

incluída página wiki com proposta e materiais básicos, como sugestão:


https://wiki.openstreetmap.org/wiki/Projeto_Mapeando_com_Escolas


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] wiki: PROJETO "MAPEANDO COM ESCOLAS"

[Sérgio V .]

Acho que tá ok a proposta de poder fazer exercícios mais indoor, se não for 
viável ou conveniente sair à rua com alunos.

Tá bom assim, ok.


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Imagem TMS: Mapa comparativo IBGE x OSM para regiões sub-mapeadas (estradas em geral)

[Sérgio V .]

Bom dia pessoal.


Está disponível (online) a imagem de fundo TMS do "Mapa comparativo IBGE x OSM 
(2016) - Estradas em geral"

Propósito: para ajudar a localizar com facilidade estradas que faltam ser 
mapeadas no Brasil, e mapeá-las.


LINK TMS (visível somente dentro do iD ou JOSM):

http://tms.openstreetmap.com.br/ibgeXosm/{z}/{x}/{-y}.png

[http://tms.openstreetmap.com.br/ibgeXosm/%7Bz%7D/%7Bx%7D/%7B-y%7D.png]

No iD:

- Editar;

- Menu lateral: selecionar "Configurações da imagem de fundo" (ou Atalho: B);

- Selecionar "Customizado": inserir o link completo TMS acima.


No JOSM:

-Menu "Configurações da imagem": +TMS; inserir o link completo TMS acima.


Mais informações no wiki:

"Situação do Mapeamento de Estradas no Brasil no OSM -  Mapa comparativo IBGE x 
OSM (2016)"


https://wiki.openstreetmap.org/wiki/Situa%C3%A7%C3%A3o_do_Mapeamento_de_Estradas_no_Brasil_no_OSM


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Apresentação

[Sérgio V .]

Olá Isaac,

pelo que entendi do que você falou, de que os habitantes locais mais precisam 
um mapa básico para colocar os pontos de interesse, você pode fazer um 
mapeamento básico do local no OSM, só com as imagens de satélite. Eu em geral 
faço isto quando vou a algum lugar que não tem nada mapeado. Ou se precisar nos 
mande a área que dê para identificar melhor o local, que a gente pode fazer um 
pré-mapeamento básico, depois complementam e tornam mais preciso.


O melhor é não importar para o JOSM como GPX para servir como linha 
propriamente (way), mas sim fazer upload das trilhas para o OSM, para servir de 
"camada de referência" ao novo traçado. Porque sempre há imprecisões no traçado 
GPX, curvas abruptas, etc. Então é melhor traçar as vias pelo traçado aparente 
nas imagens de satélite, usando o GPX como referencia para alinhá-las.


Você pode gravar as trilhas em GPX (caso esteja fazendo separadamente em 
relação ao Mapillary) e fazer upload delas para o OSM para mapear depois (ou 
para qualquer outro mapeador poder ter acesso também), em:

http://www.openstreetmap.org/trace/create

(recomendação: etiquetar como identifiable ou public).


No JOSM então se abrem 3 camadas (ao menos):

-A camada dos dados existentes no OSM (em linhas, pontos, polígonos);

-A camada de imagem de satélite;

-E a camada dos traçados GPS, que servirá para aferir as 2 anteriores.


Neste exemplo que você enviou, aparentemente indica, a princípio, que a via 
existente poderia ser um pouco realinhada conforme o traçado GPX, mais nas 
curvas. Porém melhor ainda se esta trilha GPS estiver na camada geral dos GPS, 
junto a eventuais outros traçados, onde então é possível se fazer uma média 
estimada se houver mais de um traçado de GPS. Isto ajuda a minimizar os erros 
de um traçado só (o GPS pode ter erros de até 30m, dependendo do terreno mais 
ou menos acidentado, morros, etc, que atrapalhem o sinal). Mas não precisa 
fazer vários traçados do mesmo lugar, em geral basta traçar ida e volta, se for 
o caso, para ter uma média melhor. Ou mesmo um só, p.ex. na ida, já ajuda 
muito, se for para não consumir muita bateria. Digo isto mais para o caso de 
haver vários traçados em rodovias principais.


Quanto às demandas para mapear, de modo geral quanto a:


-Vias, acessibilidade geral: tipos de vias (estrada vicinal comum, terciária, 
trilha para 4x4, etc), superfície (pavimentada ou não)

ver em:  
http://wiki.openstreetmap.org/wiki/Pt-br:How_to_map_a


-Pontos de Interesse (POIs), que pode ser feito também com ajuda dos habitantes 
locais, o que é muito útil e participativo: habitações, cachoeiras, locais 
públicos próximos e/ou na viagem até o local, mercado, etc.

ver em: http://wiki.openstreetmap.org/wiki/Pt-br:Map_Features


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Apresentação

[Sérgio V .]

Isaac,

> Ainda sobre o JOSM, tem como usar um layer diferente dos que ele tem?

Os layers são ou de dados vetoriais (como do OSM: ways, points, poligonos e 
tags), ou auxiliares TMS (imagens e mapas-base).

Quanto aos tipos de arquivos que você pode abrir para trabalhar: gpx, geojson, 
kml, shp, e outros.

Mas a estrutura dele é de fato é mais apropriada para preparar dados para o 
OSM, e respectivas etiquetas.

Você pode também criar mapas personalizados, uma vez que tenha os elementos na 
base de dados do OSM, por exemplo com Leaflet ou Umap, QGIS, ou outros.

Como você cita o interesse em mapear POIS/pins offline, além do uso do GPS, 
pode também imprimir a camada de satélite do OSM/Bing na área, também fazer 
mapas em papel para o pessoal ir anotando, para que depois coloquem diretamente 
no site do OSM. E como estes dados fazer mapas personalizados. Bom sucesso no 
mapeamento.


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Porto Alegre, Querendo retornar.

[Sérgio V .]

Alô Mauro,

Bem vindo, considere-se retornado.

Em Porto Alegre atualmente tem eu mapeando (completando vias em vilas: 
https://wiki.openstreetmap.org/wiki/Porto_Alegre_/_Importa%C3%A7%C3%A3o_das_vias_em_vilas),
 também

Alexandre Menezes, Portal Aventura, Ftrebien, e alguns outros. Pode dar uma 
olhada pelo histórico do OSM no iD.


Os prédios já foram todos importados com material da prefeitura.  Isso facilita 
inserir POIs (Pontos de Interesse): mercados, farmácias, lojas, restaurantes, 
serviços, etc.

Uma coisa muito interessante seria mapeamento de POIs, com numeração de 
endereço. Por exemplo começando pelas vias principais da cidade.

O Mapillary ajuda muito nisso também. Tem camada no OSM pra facilitar.

Talvez dar uma olhada no mapa de PoA no OSM com a camada  Mapillary pra ver 
onde já tem fotos, e onde mais falta, se você quiser tomar fotos de percursos e 
mapeá-los.  Ou mapear onde já tem fotos, mas ainda não mapeados todos os POIs 
que são visíveis nas fotos.

Qualquer coisa, estamos aí pra o que precisar ajudar.

- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] GRUPOS OSM TELEGRAM: BRASIL e LATINOAMÉRICA

[Sérgio V .]

GRUPOS OSM TELEGRAM: BRASIL e LATINOAMÉRICA:

APLICATIVO DE MENSAGENS EM: https://telegram.org

BRASIL:

@OSMBrasil_Comunidade - assuntos gerais (110 participantes)
@OSMBrasil_Suporte - dúvidas e suporte (99 participantes)
@OSMBrasil_Importacoes - discussão sobre importações (recém aberto)

Comunidades regionais:

@osmbsb - Brasília
@osmrj - Rio de Janeiro
https://telegram.me/joinchat/BWADywm2ejOFWtQQUpbAzg - Minas Gerais

LATINOAMÉRICA:

América Latina: @OSMLatam
Argentina: @OSM_ar
Brasil: @OSMBrasil_Comunidade
Bolivia: @OSMBolivia
Colombia: @osmco
Cuba: @OSM_Cuba
Ecuador: @MappingEcuador
Nicaragua: @MapaNica
Paraguay: @osm_py
Peru: @osmpe

TEMÁTICOS:
Usuários do Mapillary no Brasil: @MapillaryBrasil

Encaminhado de telegram@OSMBrasil_Comunidade:  Vitor George, [29.11.16 17:43]


POR FAVOR, COMPARTILHE!


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Sobre addr:interpolation - possibilidades

[Sérgio V .]

Legal pessoal, ótimas ideias.


Talvez de fato seja mais viável (no contexto do OSM) continuar a usar linhas 
paralelas ao eixo mesmo, com as 2 linhas de face do IBGE (sem criar novo modo 
de taggeamento na própria via).

E talvez seria mais fácil de cruzar nos dados do IBGE, já que eles já vem 
estruturados assim: pelo código da quadra nas 2 linhas opostas ao eixo.

Mas questão aí ainda seria conseguir separar impar/par (eliminando o oposto?) 
conforme respectivo lado (em Porto Alegre, por exemplo, vem misturados 
impar/par nas 2 faces de cada lado).

Acho que, dadas as possibilidades do benefício, mas também do grande volume de 
dados, considerando ainda o trabalho para fazer isso (mesmo assim ainda muito 
mais ágil que se for esperar por conseguir numeração individual), seria 
importante que pudéssemos documentar numa wiki, quem conseguir ter alguns 
resultados de testes. Para então propor como importação ou edição automática 
com base nos dados do IBGE.

Talvez gerar algum script para uso no Brasil, para distribuir o trabalho com 
quem tiver interesse, os demais interessados possam fazer nas suas cidades.

Valeu!

Se o resto da comunidade estiver de acordo, não tiver algum problema grave que 
impeça um processo assim.

Vamos pensando em como preparar para implementar.


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Sobre addr:interpolation - possibilidades

[Sérgio V .]

Pois é, esta seria a ideia:

se der pra usar addr:interpolation "no próprio eixo da via", contendo numeração 
impar/par (início cf. sentido da via ou critério local).


Creio que pode ajudar mais do que o sistema que tem sido usado atualmente, de 
adicionar 2 ways paralelos, resultando em 3 ways: eixo; lado esquerdo; lado 
direito.


A primeira questão é: teria que ser proposto no talk-tagging mundial.
Só antes poderíamos tentar testar separadamente pra ver como poderia funcionar 
e adicionar os dados que prefeituras tenham disponíveis.

Vantagens:
-para tentar agilizar o andamento das numerações de enderço
(coisa que é cada vez mais necessária para popularizar o OSM);

-evita ter que usar 3 ways para a mesma via e sobrecarregar de dados 
triplicados;

-evita ter que "arrumar" 3 ways se tiver que realinhar alguma via;

-evita poluição de ways;

-evita problemas de outros mexerem (alterar, arrastar, etc) no way errado ao 
editar;


Problemas eventuais (a verificar como contornar):

-se alguém posteriormente fundir ways que estavam numerados em sequência, 
bagunça a numeração.

-talvez uma tag adicional para receber feedback ou correções (pode ser o 
próprio "fixme": "=confirmar interpolação")

- - - - - - - - - -

-Da questão de lado e sentido de vias:

Não serve colocar um padrão fixo, cada área tem o seu (ou nem tem):

de todo modo teria que ser para verificar cada cidade/região a interpolar e se 
necessário inverter no ato de taggear:


1)Pensando melhor, pra adaptar a todos os casos, talvez tipo assim, 4 opções de 
namespace:

addr:interpolation:left:odds=

addr:interpolation:right:evens=

ou

addr:interpolation:left:evens=

addr:interpolation:right:odds=

2)Se não tem lado bem definido, continua a usar apenas a tag básica:

addr:interpolation=


Ou outra ideia melhor se tiver.


Sim, seria algo mais especializado. A princípio não é coisa simples para 
principiante fazer (mas a atual addr:interpolation, também não o é de todo modo)

- - - - - - - - - -


QUANTO ÀS OBJEÇÕES:


1)Uso indiscriminado de addr:interpolation :

Obviamente não é necessário uso indiscriminado.

Mas acho que temos que avançar na numeração e eventualmente com automatização 
e/ou aproximação para isso se necessário. Ou vamos esperar uns 20 anos pra ter 
numeração exata, ficando para trás na popularização, só nós mesmos usando.


2) O fato de eventualmente errar em numeração (lado da via, extensão da 
numeração (range)) não me parece grave.

Mesmo que errar algo, já ajuda p.ex. ter número na área mesmo que só aproximada.

Google libera assim, e faz bem. Alguns podem reclamar, porque ajuda de fato, já 
aproxima. Não é lixo inútil. As pessoas usam porque de fato ajuda. Em geral as 
pessoas não se perdem por causa de erro de posição da numeração no GPS. Se 
perde se não olhar os números nas portas também na realidade.

Não dá para esperar perfeição. Tem que liberar pra uso. Ou então: não se 
populariza, não terá mais gente contribuindo, e não se avança.

O resto é feedback e correção progressiva.


3) Endereçamentos do IBGE:

No que vi no SHP face de logradouros (ways), não traz numeração de endereços:

ftp://geoftp.ibge.gov.br/recortes_para_fins_estatisticos/malha_de_setores_censitarios/censo_2010/base_de_faces_de_logradouros

Endereços só encontrei na lista TXT em:

ftp://ftp.ibge.gov.br/Censos/Censo_Demografico_2010/Cadastro_Nacional_de_Enderecos_Fins_Estatisticos/

vem listado o numero da rua, quadra, CEP, etc. Por estados/cidades (código).

Teria que processar a lista (no QGIS ou script), ver como poderia passar para 
os ways do OSM para adicionar.

Acho que talvez teria primeiro que cruzar com o SHP das faces, pra só depois 
tentar ver como passar pras highways do OSM. Meio complicado, acho. Talvez 
alguém pense jeito mais fácil.


Mas talvez sirva pra quem pretender extrair os CEPs.


De todo modo ainda vi que do IBGE tem que confirmar o ajuste da camada:

entrou em CRS SIRGAS2000, mas nem sempre fecha bem com o que já está correto no 
OSM com GPS, etc.

No Centro de Porto alegre vi a diferença em torno de -40,-20m (x,y). Em Viamão 
diferença não homogênea.

Creio que seja problema de resolução e imagem usada no Censo 2010.


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Sobre addr:interpolation - possibilidades

[Sérgio V .]

#addr:interpolation

Tava pensando:

Poderia talvez ter uma maneira de adicionar automaticamente um 
addr:interpolation no OSM direto sobre o que já existe.
E sem depender de montar sobre SHP de "faces de quarteirão" do IBGE.
Pois isso é coisa que acho que vai levar mais tempo do que já levou para traçar 
vias no OSM todo. A não ser que se consiga numeração de outras fontes mais 
fáceis.
Numeração é super importante pra navegação.
Senão vai levar décadas para se conseguir numerar, ficaria um entrave à 
popularização da navegação via OSM.

Talvez poderia ser desenvolvida uma tag para "o(s) mesmo(s) way(s)" da via, sem 
necessitar mais de adicionar 2 ways paralelos.
No meu ver este método atual de criar ways paralelos causa poluição.
Creio que em um futuro bem próximo vai gerar excesso de ways paralelos e 
sobrecarga, e é mais fácil de dar problemas de alguém se enganar e arrastar).
Isso talvez ajudaria o OSM em todo o mundo.

CONDIÇÕES:
Precisaria primeiro selecionar as vias que:
1-sigam um padrão fixo como: esquerda=ímpar; direita=par (ou estejam em 
áreas/cidades/localidades que sigam este padrão fixo);
2-já tenham sentido confirmado (início-fim, para onde cresce a numeração).
Ou se for padrão da cidade par/ímpar em lados inversos, inverter o padrão no 
processo.

Poderia ser +/- assim, adicionar 2 tags pro mesmo way da via:
addr:interpolation:odds=
addr:interpolation:evens=

Exemplo:
addr:interpolation:odds=1-1001
addr:interpolation:evens=2-1002

Creio que se poderia obter "automaticamente" estes valores com um processo de 
script (mesmo se não souber os valores exatos de início e fim):
1-indicar ao menos "1" way como o sentido correto (início-fim) para ser 
atribuído a todos os ways da sequência;
2-se conhece ao menos "um" número inicial "ou" final (ímpar "ou" par), 
indicá-los (serão atribuídos ao final do processo);
se não conhece, serão atribuídos "1" ao ímpar inicial, e "2" ao par inicial; o 
resto será dado pelo comprimento dos ways;
3-processar os ways de vias em continuidade, isto é: highways=; "E" 
com nós conectados; "E" tag 'name=*' igual;
4-somar seus comprimentos para obter o comprimento total da via para o "range" 
de numeração;
5-nestes casos eventualmente "subdividindo" os valores das tags 
addr:interpolation:  conforme cada way da sequência;
6-por fim aplicando estas tags e valores subdivididos aos respectivos segmentos 
de ways da mesma via ("sem" fundir os ways em um só).

Verificadas aquelas CONDIÇÕES citadas acima, poderia ser em "automated edition".
Mesmo se der coisa errada, acerta-se em grande parte. A aproximação deve dar 
bem boa.
(OBS.: o Google tá cheio destes problemas de range de numeração, mesmo assim 
vai liberando informação para uso, e recebendo retorno onde corrigir; talvez 
executem assim também em muitos casos; não parece dar em erro grave)
Poderia-se também adicionar algo como "fixme=automated edition:confirmar 
interpolação com outra fonte", para promover feed-back.

Creio que são coisas que talvez possam facilitar para agilizar a popularização 
do OSM pra navegação.
Certamente se poderia rever muita coisa nesta possibilidade para tornar viável 
implementar de fato.

Que acham? Útil? Viável?


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Sobre addr:interpolation - possibilidades

[Sérgio V .]

<*Pedro Esmerilho*: ...o modo de conseguirmos os dados foi através de escolas 
que repassavam para professores de geografia e estes para alunos...Acho que se 
focássemos em convencer professores com e-mail e vídeos tutoriais explicativos, 
o resultado para o OSM em geral seria melhor>

Claro, isso também.

Acho que mês passado comentei que investir em propor atividades de mapeamento 
de POIs com colégios seria ótimo. Depende só de contato com os colégios, 
professores, diretores. Já venho preparando material para isto, roteiros para 
trabalhos com alunos. Quem quiser, trocamos figurinhas e tocamos em frente. É 
bom gente da área da educação também.


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Sobre addr:interpolation - possibilidades

[Sérgio V .]

Legal Augusto, melhor ainda essa ideia de colocar base de endereços em 
separado.  Não polui o OSM, evita alguém estragar inadvertidamente. E se der 
pra fazer manutenção separadamente sem mexer no OSM, também.


Neste caso, acho que ainda se precisaria passar a numeração,

do TXT (ou se tiverem organizados em outro formato; não encontrei):

ftp://ftp.ibge.gov.br/Censos/Censo_Demografico_2010/Cadastro_Nacional_de_Enderecos_Fins_Estatisticos/

Para os SHPs das faces em cada um do 5500 municípios:
ftp://geoftp.ibge.gov.br/recortes_para_fins_estatisticos/malha_de_setores_censitarios/censo_2010/base_de_faces_de_logradouros
Ou se alguém tiver outro jeito mais fácil.


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Avaliar + Planejar = Agir fundamentadamente

[Sérgio V .]

Sim, poderia ser.


-No Pascal Neis se consegue os "daily active members".

Manualmente (copiando), só o que consegui extrair foi deste mês:

Novembro (01 a 28)-daily active members: média=72.18 / desvio padrão=13.35


Teria que ver se dá pra conseguir os dados brutos pelo período que ele tem, de 
5 anos (talvez em planilha?);


-Também para o "nº de objetos editados";
Ou se der pra conseguir coletar isto com o 
http://naoliv.iq.unesp.br/osm/stats/, ele vai ver o que dá pra fazer.

-O "nº de changsets" (por dia, para as médias por mês, como medidas por ano), 
não sei de onde daria pra conseguir os dados brutos.

Se acharem que ajudaria mesmo.

- - - - - - - - - - - - - - - -

[Talk-br] Avaliar + Planejar = Agir fundamentadamente
Wille wille em wille.blog.br
Quarta Novembro 30 17:00:23 UTC 2016
Estas estatísticas são interessantes, apesar de que a forma que elas
foram apresentadas não é a melhor:
http://osmstats.neis-one.org/?item=countries=Brazil

Acho que a quantidade de usuários ativos, a média de edições por usuário
e a quantidade de objetos editados por usuário são as melhores métricas
que precisamos.

abraços,
wille


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Avaliar + Planejar = Agir fundamentadamente

[Sérgio V .]

Sobre a questão tangenciada no telegram, se devemos fazer alguma coisa para 
avaliar mais objetivamente o andamento do OSM no Brasil (pelo que entendi):

Acho que o caminho lógico é:
1°) Avaliar (ver objetivamente (tanto qto. possível) as coisas com são);
2°) Planejar (abertamente, transparentemente);
3°) Agir (fundamentadamente).
Nesta ordem.
O caminho inverso gera ações aleatórias, vai no acaso (i.e., se agimos mais por 
ímpeto, mesmo que com ótimas intenções, sem iniciar por ver mais objetivamente 
como as coisas estão e tem ido; o acaso, de modo geral, é pouco produtivo).

Uma coisa que acho que poderia ajudar é tentar enxergar melhor a evolução, se 
tivermos dados estatísticos no tempo.

Os dados originais que acho que precisaria (a princípio, ou se alguém tiver 
ideia melhor) são:
Por mês, desde o 1º nó editado no Brasil (em 02/25/2006), preferencialmente se 
possível (ou por trimestre já ajuda):
1) Total geral de usuários;
2) Total geral de objetos editados;
((3)) Desvio Padrão de objetos editados em relação à média geral por user (acho 
que dá para derivar dos 2 anteriores; a questão é avaliar o andamento geral 
médio, por épocas, evitando desvios pontuais, para evitar interpretação 
inadequada).

Também se poderia verificar a média de usuários ativos e participativos, o 
número de ingressados nos canais de comunicação, etc. É outra coisa, mas seria 
interessante.

Com isso acho que já dá pra começar.
Na página de stats do naoliv, que tá ótima, consigo ver os dados totais, mas só 
do presente.
Se tivermos acesso àqueles dados totais do período do OSM no BR (talvez desde o 
início em 2006), tento fazer uma estatística da evolução e tendência, talvez em 
gráficos, para tentar nos ajudar a ver como as coisas estão e tem ido.


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Sobre addr:interpolation - possibilidades

[Sérgio V .]

Penso que seria útil se os que já tem uma metodologia em andamento,  se pudesse 
ir começando uma wiki comum (tipo "Proposta de importação de endereços no 
Brasil - CNEFE 2010 ") e descrevendo ali a metodologia pensada (mesmo que 
certamente vá sendo mudada e aprimorada no andar dos estudos e experimentos; e 
por experimentos entendo inicialmente "fora" do OSM, para que todos possam ver 
antes se tá funcionando suficientemente bem, e aprovar o uso no Brasil todo).

Poderia ser em tópicos nesta wiki:

-metodologia proposta por santamariense;

-metodologia proposta por papibarrígafo;...

-problemas identificados;

-objeções;

-preferências da comunidade;...


Por exemplo, pode-se colocar na wiki também imagens dos resultados para que 
mesmo quem não entende de programação possa acompanhar.

E em passo-a-passo, para mesmo quem não entende muito de programação ou 
processamentoem QGIS.

Eu pessoalmente sou muito limitado em entender de programação.

Assim todos podem enxergar melhor o que uns e outros estão propondo.

Por exemplo, talvez seria útil colocar figuras do QGIS das tags com "labels", 
nas faces, tal como ficaria para importar.

(pensei nisto na questão do Augusto sobre se  <>).

Aí se enxerga a coisa.

Mas acho que tá indo bem a coisa, estamos próximos de chegar lá.


Parabéns aos que tão metendo a mão no bagulho.

Eu percebo minhas limitações em programação e processamento.

Mas assim que entender o método, pego e executo.


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Bom Ano Novo

[Sérgio V .]

Votos de bom ano para a comunidade OpenStreetMap no Brasil, para todos e para 
cada um,

de consolidação, popularização e prosperidade do projeto OSM,

ao qual cada um de nós estima e dedica muito de seu tempo de atividade física e 
mental,

união e crescimento da comunidade como um projeto comum,
crescimento pessoal e prosperidade de cada um,

implementação e aprimoramento das boas ideias e possibilidades já levantadas,

surgimento de novas boas ideias,

difusão do OSM e de suas utilidades para a população em geral,

e tudo o mais que for bom.


Um abraço,


Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Sobre addr:interpolation - possibilidades

[Sérgio V .]

Sim, de fato, tava vendo melhor agora, o lado já viria certo (problema é 
atribuir o sentido do menor/maior):

-o TXT traz a numeração do endereço, com número do setor,  quadra e face (mas 
não traz coordenadas);

-que correspondem no SHP ao valor de "CD_GEO" (as linhas das faces já 
georreferenciadas).


Assim, sejam ímpares ou pares ou misturados, já correspondem ao código do lado 
certo da rua (face).


EXEMPLO:
PORTO ALEGRE - FACE DE QUADRA DO MUSEU JULIO DE CASTILHOS: RUA DUQUE DE CAXIAS 
1205
(MAS PODERIA SER QUALQUER CIDADE)


TXT: (não tem coordenadas)

-Posição Inicial 1 (Códigos UF, município, distrito, subdistrito, setor)= 
43149020562

-Posição Inicial 67 (Nome do logradouro)=DE CAXIAS

-Posição Inicial 127(NÚMERO NO LOGRADOURO)=1205

-Posição Inicial 545 (Quadra e Face)= 001004


SHP:  "CD_GEO"=43149020562001004 (=aos valores de [1...;545...] do TXT)


O que precisaria fazer (automatizar):

-(no TXT) selecionar todas as "faces de quadras" da "mesma rua" (Nome do 
logradouro + distrito, subdistrito...);

-destas, selecionar todos os "números  no logradouro" de cada face de quadra e 
destacar "o maior e o menor";

-(no SHP) copiar os valores  de maior e menor número do TXT para cada linha de 
face no SHP;

-ordenar as faces segundo os  "números  no logradouro";

-atribuir sentido às linhas, em ordem;

-atribuir a cada face do SHP, em sequencia, 2 novos campos com os valores para 
 e  

(ou já adicionar direto um campo (addr_inter) com os valores para 
-).


Depois só trocar o nome no JOSM para addr:interpolation.

Ficaria pronto para examinar no JOSM com o existente, validar e importar.


Mas não sei como automatizar aquilo ali  :-P


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Sobre addr:interpolation - possibilidades

[Sérgio V .]

@santamariense,

Ótimo ter contatado este pessoal! O colaborador Antonio Guarda mostra 
exatamente aquilo que vínhamos pensando.

E cita aquele deslocamento referido antes (que terá que ser reposicionado 
manualmente, mas nada que seja muito complicado).

E o mais importante: ele aponta que já conseguiu algum bom resultado fazendo 
associação dos códigos de quadra/face do TXT (CNEFE) para o SHP (Faces de 
logradouro), de modo a passar para o SHP os valores da "numeração de endereço".

(Infelizmente não foi mantido no TXT o código concatenado único para cada face 
como está no SHP:

"CD_GEO" = Concatenação dos campos Município/Quadra/Face/Setor etc

Mas nada muito complicado também: será apenas necessário "remontar" a 
concatenação com os valores que no TXT estão separados por campos.).

Então o caminho parece ser por aí mesmo.

Valeu!


Talvez isto terá que ser feito previamente com um script.

No nosso caso, talvez primeiramente processar isoladamente o TXT:

I-

1) concatenar os valores dos campos do TXT para acrescentar a cada face um 
campo com código idêntico ao "CD_GEO" do SHP;

2) comparar as faces por "nome de logradouro" (mesma rua) quanto aos valores de 
"numero no logradouro" (=endereço), para ver o máximo/mínimo (excluindo as que 
possuem valores diferentes no campo "localidade" (bairro, etc) para evitar 
homônimos);

3) adicionar 2 campos para os valores máximo e mínimo de "numero no logradouro" 
em cada face;


II-repassar estes valores às linhas de face no SHP, por associação com o campo 
"CD_GEO" (= Concatenação dos campos Município/Quadra/Face/Setor etc...)


III-fazer as análises de sentido do crescimento (com as faces de quadras 
adjacentes) para identificar os nós das extremidades das linhas de face para 
atribuir máximo / mínimo.


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] PROJETO "MAPEANDO COM ESCOLAS"

[Sérgio V .]

Só trocando o link para o PROJETO, para docx (sem problemas de caracteres):

https://www.dropbox.com/s/mpy765pbsgteyps/PROJETO%20DE%20MAPEAMENTO%20COM%20ESCOLAS%20-%20ROTEIRO.docx?dl=0


- - - - -

Compartilho aqui ideias sobre projeto de mapeamento com escolas, também após 
conversa com o Gilmar Ferreira que trouxe ótima ideia de projeto neste sentido:

Bom dia Gilmar,

Penso que ideias sobre como conduzir experiências junto a escolas podem ser 
implementadas sem problemas, a depender de cada região se necessitar ajustes em 
projeto.

A primeira questão penso que é iniciar um contato diretamente com professores e 
diretores de escolas, para mostrar um projeto, o que é o OSM, etc. Depois, se 
aceita a proposta, apresentar e preparar com os alunos.
Ter um projeto básico e material visual a apresentar é importante.

Tenho estado preparando algum material de projeto para isto. Mas poderia também 
ser útil adaptar conforme a necessidade em cada local/colégio, ou conforme 
preferir.

Fiquem à vontade para copiar, adaptar, etc. Podendo, toquem adiante, ótima 
iniciativa. E compartilhem os resultados.


LINKS:

PROJETO PRELIMINAR - SUGESTÃO:
https://www.dropbox.com/s/k5p8ox20wvxuqpc/PROJETO%20DE%20MAPEAMENTO%20COM%20ESCOLAS%20-%20ROTEIRO.txt?dl=0

APRESENTAÇÃO INFORMATIVA "O QUE É O OSM" (A RESUMIR E SIMPLIFICAR PARA 
COLÉGIOS):
https://www.dropbox.com/s/cot3xd2vq6dnu4h/PALESTRA%20OSM%202016.docx?dl=0

Neste último tem roteiros de práticas de mapeamento no final (oficina 1), e 
explicações breves sobre as tags mais usadas, etc.


Saudações, Sérgio.

- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Sobre addr:interpolation - possibilidades

[Sérgio V .]

@Marcos Fedato,

Beleza, vamos tentando ver o que se consegue. Conseguir o sentido da rua e das 
linhas de face será outra mão na roda.

>(eu nao lembro se tem algum codigo unico por logradouro ou se seria possivel 
>só pelo nome da rua pois podemos ter problemas com homonimos).

Essa é a questão também, procurei mas não encontrei no CNEFE algum arquivo que 
tenha um código único de rua. Complica um pouco mais ter que filtrar por "nome 
de logradouro" + os códigos da cidade/setor/etc...


Mas considerando o código completo do setor onde está a linha de face (ex. no 
shp CD_SETOR=43149020562 // equivalente àquela compilação dos atributos do 
TXT, e menor e mais restrito que o código da cidade=4314902), não deve haver 2 
ruas com mesmo nome no mesmo CD_SETOR.

Isto talvez já facilitaria um pouco mais.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
LAYOUT DOS TXT DO CNEFE (Layout.xls):

Variável Posição Inicial Tamanho EXEMPLO(#=NULL)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Código da UF 1 2 43
Código do município 3 5 14902
Código do distrito 8 2 #5
Código do subdistrito 10 2 #0
Código do setor 12 4 ##62 [= compilação CD_SETOR: 43149020562 (*1*)]
Situação do setor 16 1 1
Tipo do logradouro 17 20 RUA
Título do logradouro 37 30 DUQUE
Nome do logradouro 67 60 DE CAXIAS
Número no logradouro 127 8 1205   [= NÚMEROS A SELECIONAR NA QUADRA PARA SHP 
(*1*)]
Modificador do número 135 7 #
Complemento
Elemento 1 142 20 #
Valor 1 162 10 #
Elemento 2 172 20 #
Valor 2 192 10 #
Elemento 3 202 20 #
Valor 3 222 10 #
Elemento 4 232 20 #
Valor 4 252 10 #
Elemento 5 262 20 #
Valor 5 282 10 #
Elemento 6 292 20 #
Valor 6 312 10 #
Latitude 322 15 #
Longitude 337 15 #
Localidade 352 60 CENTRO
Nulo 412 60 #
Espécie de endereço 472 2 06
Identificação estabelecimento 474 40 MUSEU JULIO DE CASTILHOS
Indicador de endereço 514 1 1
identificação domicílio coletivo515 30 #
Número da quadra (*) 545 3 001
Número da face 548 3 004 [= CD_GEO: 43149020562001004 (*1*)]
CEP 551 8 90010283

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -


Valeu!

Vamos experimentando.


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Sobre addr:interpolation - possibilidades

[Sérgio V .]

@Marcos Fedato, traquilo, vai-se vendo quando der; o "Número no logradouro" 127 
8 1205" ("no" logradouro) é o próprio addr:housenumber a extrair.


@santamariense, o layout geral tá no 
ftp://ftp.ibge.gov.br/Censos/Censo_Demografico_2010/Cadastro_Nacional_de_Enderecos_Fins_Estatisticos/

neste arquivo Layout.zip (XML).

>Tendo os alinhamentos das faces, por cálculos se poderia distribuir a 
>numeração ao longo do caminho.

Também poderia ser. Pelo que entendi, criar nós com addr:housenumber já na 
posição certa.


De todo modo (seja para nós ou se for usar nas linhas de face), dependerá 
sempre antes de verificar necessidade de re-posicionamento manual prévio das 
quadras no SHP do IBGE (pode fazer no JOSM antes de validar).


Pois há discrepâncias de fato.

No explicativo do IBGE eles reconhecem problemas de posicionamento:

"Apesar de esta base ter sido georreferenciada utilizando imagens orbitais 
disponíveis, podem haver discrepâncias posicionais em relação ao mundo real em 
algumas áreas do território. "

(Ver em:

ftp://geoftp.ibge.gov.br/recortes_para_fins_estatisticos/malha_de_setores_censitarios/censo_2010/base_de_faces_de_logradouros/1_Leia_me/)


Realinhar manual vai ser inevitável. Mas acho que nem tão demorado; dá pra 
controlar bem.

Deve dar pra realinhar várias quadras ou bairro inteiro numa tacada. (+/-)

O deslocamento é meio homogêneo por várias quadras. Só tem que conferir.


IMAGEM:

Exemplo do problema de desalinhamentos originais (comparado com Porto Alegre 
que já tá bem alinhada no OSM) - Desalinhamentos do IBGE em linhas vermelhas: 
http://i.imgur.com/FaBqQdx.jp


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Sobre addr:interpolation - possibilidades

[Sérgio V .]

Santamariense,

Bom saber, não sabia deste site que mostraste.

Até agora só encontrei a lista completa dos endereços (que citei que precisa 
cruzar com os SHP), aqui:

ftp://ftp.ibge.gov.br/Censos/Censo_Demografico_2010/Cadastro_Nacional_de_Enderecos_Fins_Estatisticos/

Pelo que entendi do que o Vítor Rodrigo Dias falou, seria possívelcruzar com as 
geometrias das faces, que tem o código das quadras, e daí puxar os números de 
endereços.

Claro, como falei antes, não elimina a possibilidade de numeração manual, mais 
exata. Para onde for viável fazer, em tempo viável, como você cita no seu caso 
local. Mas nos casos em que não seja viável cobrir tudo manualmente (o que 
acredito seja o mais geral) em um futuro razoável (tipo se for levar mais 10 
anos para conseguir dobrar o numero de editores com gente local para isto), me 
parece que valeria pensar seriamente em investir em automatização, ainda que 
com resultados de numeração +/- aproximada.

(parentese:

Breve estatística neste mês no Brasil a partir do 
http://naoliv.iq.unesp.br/osm/stats/:

Número de usuários que editaram nos últimos 30 dias (última edição entre 15/nov 
a 15/dez/2016): 883

Características do volume de edições dos usuários (cf. "média de edições/dia" 
(avg edits/day)):

Variação:  de 0.007155635 a 3966.365747

Média= 59,50 / Desvio Padrão= 236.42 / Linha de DP= 295.92 (em edições/dia)

Número de Usuários acima da Média: 142

Número de Usuários acima da Linha de Desvio Padrão: 51

fecha parentese ).

Devem ser portanto +/- uns 150 usuários mensalmente ativos no Brasil. Para 
5.570 municípios... Daria uma média de 37 municípios por editor.  Se for fazer 
"numeração manual", se conseguir fazer 1 município por mês (não sei o tempo que 
você levou para numerar sua cidade) nas horas disponíveis, e se só fizer isso 
até terminar a numeração de endereços no Brasil, levaria 3 anos. Sem férias. 
Mas usuários que editam bastante  mensalmente (acima do desvio padrão de 295.92 
edições/dia) são apenas uns 50. Então passaria para uns 9 anos até terminar 
tudo.

Não sei se seria sempre o caso como você falou <"JAMAIS apenas importe, faça 
uma inspeção de cada objeto...">.  Talvez se possa assumir certos erros 
possíveis num processo. Para resolver mais tarde se necessário. Não quer dizer 
fazer algo impensado. Se for bem discutido e planejado.  Sem muito medo de 
eventuais imperfeições. E se não causar mal no que já existe.

O OSM tem também a prática: a perfeição não é mais importante que a coesão da 
comunidade (https://wiki.openstreetmap.org/wiki/Pt:How_We_Map). Isso quer dizer 
algo.

Ter algo concretamente útil a oferecer às pessoas , como numeração, ainda que 
imperfeita, me parece também uma boa maneira de fomentar comunidade, e manter o 
OSM. Talvez tentar arrebanhar gente sem ter a oferecer algo de utilidade 
prática ao menos ao nível do que oferecem concorrentes (nem precisa ser melhor) 
pode também queimar a foto frustrando expectativas. Somos 150 editores 
mensalmente ativos no Brasil. 150 que conhecem e (imagina-se) usam o OSM. De 
uma população urbana de uns 100milhões. Das pessoas no Brasil que usam GPS para 
localização no dia-a-dia, quantas já "ouviram" falar de OSM?  Quantas usam o 
OSM?  Quantas trocaram o serviço de localização do Google pelo do OSM?

Como observei antes, creio que primeiro momento é de fazer teste das 
possibilidades e documentar, discutir como daria pra importar/automatizar. 
Executar é apenas o último passo, se  primeiro for viável e aceito.


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] TUTORIAL: Como usar as camadas WMS do IBGE (conforme descritas no INDE)

[Sérgio V .]

Daniel, tem sim.

Tem o OSM Imagery Index, que o Aun tá vendo pra colocar.


Luis,

valeu pelo aviso. Mas pelo que o Cássio falou não tem problema, não influi no 
WMS. A URL que vem nos metadados também indica assim. Testei também com o SHP, 
e o WMS casa exato com as coordenadas originais dos pontos. E bem razoável com 
as imagens Bing e Mapbox, e com o que existe no OSM  (descontadas as distorções 
destes; ex. ~5m de deslocamento do Bing p/Oeste em Porto Alegre, Estação GPS 
91850 :  http://www.bdg.ibge.gov.br/bdg/pdf/relatorio.asp?L1=91850 - Pra 
comparar no JOSM: Shift+D = 30 ° 04 ' 26,5528 " S 51 ° 07 ' 11,1532 "W; esta, 
com 4 casas decimais)


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs



De: Luis Bahiana <luis.bahi...@gmail.com>
Enviado: quarta-feira, 22 de março de 2017 12:39
Para: talk-br@openstreetmap.org
Assunto: Re: [Talk-br] Digest Talk-br, volume 102, assunto 33

Não tomem como certeza mas me lembro que as requisições GET Map vindas do Arc 
GIS usavam REST... tem que ver aí abcs Bahiana

- - - - - - - - - - - - - - - -

De: Daniel d'Andrada Tenório de Carvalho <daniel.dandr...@gmail.com>
Enviado: quarta-feira, 22 de março de 2017 11:04
Para: OpenStreetMap no Brasil
Assunto: Re: [Talk-br] TUTORIAL: Como usar as camadas WMS do IBGE (conforme 
descritas no INDE)

Legal!

Não tem como fazer aparecer direto na lista de "imagery providers" do JOSM?

On Wed, Mar 22, 2017 at 10:08 AM, Sérgio V. 
<svo...@hotmail.com<mailto:svo...@hotmail.com>> wrote:

Como usar as camadas WMS do IBGE (conforme descritas no INDE), como camadas de 
fundo no JOSM:

1) Abrir o Visualizador do INDE (http://www.visualizador.inde.gov.br/):
-Selecionar no menu esquerdo a camada de interesse (exemplo: "Redes Geodésicas 
> Rede Geodésica Altimétrica > Referências de Nível");
-Com o botão direito, visualizar "URL WMS" e copiá-la (Ctrl+C);

2) NO JOSM: Abrir menu "Preferências de Imagem" > "+WMS":
-Entrar com uma das URL (qualquer), tal como citada no INDE;
-Adicionar o "nome" da camada, tal como está nos metadados;
-Editar o campo "URL":  colar a URL tal como está abaixo  (Ctrl+V);
-OK. Fica gravado pra sempre no JOSM. Abrir camada. E pronto. Só usar quando 
quiser, já vai estar lá no JOSM.

(Ao salvar changeset, o JOSM já deve salvar automaticamente a URL da camada WMS 
como source de imagem; senão, adicionar a URL)

Licença: camadas do IBGE já aprovada a licença. (Demais, dentro da Lei de 
Acesso à Informação, Federal; a confirmar).

Para consultar relatórios de cada ponto do WMS:
-copiar a URL básica no navegador: 
http://www.bdg.ibge.gov.br/bdg/pdf/relatorio.asp?L1=
-acrescentar "ao final" da URL o "nome" da estação geodésica, tal como aparece 
no WMS (em zoom próximo); exemplo: estação "90128" (Monte Roraima):
http://www.bdg.ibge.gov.br/bdg/pdf/relatorio.asp?L1=90128
Pronto. Visualizar dados (fotos, coordenadas, altitude, etc).

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
- - - - - - - - - - - - - - - -
LISTA WMS - IBGE - Redes Geodésicas (INDE):
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
IBGE-Rede Geodésica Gravimétrica
+WMS:
-ENTRAR COM ESTA URL:
http://www.geoservicos.ibge.gov.br/geoserver/wms?service=WMS=1.1.0=GetMap=CGED:BDG_EG
-Colocar o "nome" para o WMS; dar "OK";
-Substituir ("COLAR") no campo da URL:
wms:http://www.geoservicos.ibge.gov.br/geoserver/wms?service=WMS=1.1.0=GetMap=CGED:BDG_EG==EPSG:3857={width}={height}={bbox}=image%2Fpng=TRUE<http://www.geoservicos.ibge.gov.br/geoserver/wms?service=WMS=1.1.0=GetMap=CGED:BDG_EG==EPSG:3857=%7Bwidth%7D=%7Bheight%7D=%7Bbbox%7D=image%2Fpng=TRUE>
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
IBGE-Rede Geodésica Planimétrica-Vértices de Triangulação
+WMS:
-ENTRAR COM ESTA URL:
http://www.geoservicos.ibge.gov.br/geoserver/wms?service=WMS=1.1.0=GetMap=CGED:BDG_VT
-Colocar o "nome" para o WMS; dar "OK";
-Substituir ("COLAR") no campo da URL:
wms:http://www.geoservicos.ibge.gov.br/geoserver/wms?service=WMS=1.1.0=GetMap=CGED:BDG_VT==EPSG:3857={width}={height}={bbox}=image%2Fpng=TRUE<http://www.geoservicos.ibge.gov.br/geoserver/wms?service=WMS=1.1.0=GetMap=CGED:BDG_VT==EPSG:3857=%7Bwidth%7D=%7Bheight%7D=%7Bbbox%7D=image%2Fpng=TRUE>
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
IBGE-Rede Geodésica Planimétrica-Rede GNSS Permanente - RBMC
+WMS:
-ENTRAR COM ESTA URL:
http://www.geoservicos.ibge.gov.br/geoserver/wms?service=WMS=1.1.0=GetMap=CGED:RBMC
-Colocar o "nome" para o WMS; dar "OK";
-Substituir ("COLAR") no campo da URL:
wms:http://www.geoservicos.ibge.gov.br/geoserver/wms?service=WMS=1.1.0=GetMap=CGED:RBMC==EPSG:3857={width}={height}={bbox}=image%2Fpng=TRUE<http://www.geoservicos.ibge.gov.b

Re: [Talk-br] Digest Talk-br, volume 102, assunto 36

[Sérgio V .]

Ótima sugestão, Luis!

Vamos de todo modo poder manter o uso dos WMS das diversas camadas disponíveis 
no INDE.

Só ir trocando a que se quiser usar, na URL adaptada pro JOSM. E/ou no 
Indexador.

Valeu pela dica, fundamental!


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs



De: Luis Bahiana <luis.bahi...@gmail.com>
Enviado: quarta-feira, 22 de março de 2017 15:14
Para: talk-br@openstreetmap.org
Assunto: Re: [Talk-br] Digest Talk-br, volume 102, assunto 36

Foi apenas uma sugestão..pensando na importância e a praticidade de 
trabalharmos com padrões da OGC como o WMS em favor da interoperabilidade..


Em 22 de março de 2017 15:00, 
<talk-br-requ...@openstreetmap.org<mailto:talk-br-requ...@openstreetmap.org>> 
escreveu:
Enviar submissões para a lista de discussão Talk-br para
talk-br@openstreetmap.org<mailto:talk-br@openstreetmap.org>

Para se cadastrar ou descadastrar via WWW, visite o endereço
https://lists.openstreetmap.org/listinfo/talk-br
ou, via email, envie uma mensagem com a palavra 'help' no assunto ou
corpo da mensagem para

talk-br-requ...@openstreetmap.org<mailto:talk-br-requ...@openstreetmap.org>

Você poderá entrar em contato com a pessoa que gerencia a lista pelo
endereço
talk-br-ow...@openstreetmap.org<mailto:talk-br-ow...@openstreetmap.org>

Quando responder, por favor edite sua linha Assunto assim ela será
mais específica que "Re: Contents of Talk-br digest..."


Tópicos de Hoje:

   1. Re: Proposal of import: Brazilian Geodetic Network -
  Alternativa WMS / IBGE (Sérgio V.)


--

Message: 1
Date: Wed, 22 Mar 2017 17:59:47 +
From: Sérgio V. <svo...@hotmail.com<mailto:svo...@hotmail.com>>
To: "talk-br@openstreetmap.org<mailto:talk-br@openstreetmap.org>" 
<talk-br@openstreetmap.org<mailto:talk-br@openstreetmap.org>>
Subject: Re: [Talk-br] Proposal of import: Brazilian Geodetic Network
- Alternativa WMS / IBGE
Message-ID:

<fr1p152mb0807ffb71b7e802d48075e3290...@fr1p152mb0807.lamp152.prod.outlook.com<mailto:fr1p152mb0807ffb71b7e802d48075e3290...@fr1p152mb0807.lamp152.prod.outlook.com>>

Content-Type: text/plain; charset="iso-8859-1"

Falou pessoal, pensei mais porque o WMS me pareceu prático.

Podemos ir mantendo a proposta de importar direto os pontos, então, valeu.


Só tem também ainda as questões que foram aparecendo:

-como fazer conflação (não sei se é o termo mais correto), isto é, passar os 
re-ajustes dos dados para os pontos existentes no histórico (os revertidos) e 
fazer upload (re-reversão com alteração)? Como fazer um merge geral? Ou se 
desse pra baixar o .osm direto no QGIS, como "se" tivesse um DBF que pudesse 
editar e juntar novos campos. Aí seria fácil. Senão acho mais viável inserir 
como novos pontos mesmos (45622 novos nós também não é tanto assim... são +/- 
os nºs de nodes de vias de 01 município bem mapeado de 500.000 hab. ,  como 
Caixas do Sul).

-há pontos de medições mais antigas com não muita precisão nos relatórios, em 
1" de arco = ~30m, como para Referência de Nível (muitos outros, como Estação 
GPS, estão bem mais precisos, com 4 casas decimais de segundo= ~3mm); se 
aqueles forem medidos novamente no futuro, tem que alterar pra melhorar.  
Talvez teria que adicionar uma tag indicando a precisão para se saber os mais 
confiáveis? Tipo "GMS:precision=4" para 4 casas decimais de segundos, p . ex . ?

-como fazer a manutenção no futuro se tiverem novas medições...? Dá pra fazer, 
aí é buscar pelas "ref=*".


Por outro lado, os SHP originais tem a vantagem ainda de que dá pra ter dados 
de altitude, "ele" (WGS84) e "ele:orto"(Ortométrica), o que pode ajudar 
bastante onde os SRTM de curvas de nível do OSM (Thunderforest/OpenCycleMap) 
não tão bons, como na Amazônia.


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs



De: Gerald Weber <gwebe...@gmail.com<mailto:gwebe...@gmail.com>>
Enviado: quarta-feira, 22 de março de 2017 14:09
Para: OpenStreetMap no Brasil
Assunto: Re: [Talk-br] Proposal of import: Brazilian Geodetic Network - 
Alternativa WMS / IBGE

Concordo integralmente com o Cassio.

abraço

Gerald

2017-03-22 13:15 GMT-03:00 Cassio Eskelsen 
<cas...@3geo.com.br<mailto:cas...@3geo.com.br><mailto:cas...@3geo.com.br<mailto:cas...@3geo.com.br>>>:
Discordo totalmente de suspender a importação.

Já discutimos várias vezes a utilidade desses marcos. Se formos começar a 
pendurar camadas WMS no OSM perderemos o sentido de existir o OSM.

Vocês estão criando uma dependência grande de um WMS que possui uma 
disponibilidade baixíssima e que de uma hora para a outra pode nem existir mais.

Vários países da Euro

Re: [Talk-br] TUTORIAL: Como usar as camadas WMS do IBGE (conforme descritas no INDE) * ESTRADAS *

[Sérgio V .]

Vai abaixo também a URL pra usar com * ESTRADAS *.


FONTE: IBGE - BC250_Trecho_Rodoviario ( 
http://visualizador.inde.gov.br/VisualizaCamada/913 )

URL ORIGINAL (usar ao abrir no JOSM > Imagery > +WMS):
http://geoservicos.ibge.gov.br/geoserver/wms?service=WMS=1.1.0=GetMap=CCAR:BC250_Trecho_Rodoviario_L

URL ADAPTADA PRO JOSM (Editar em Imagery > +WMS ; colar todo abaixo):
wms:http://geoservicos.ibge.gov.br/geoserver/wms?service=WMS=1.1.0=GetMap=CCAR:BC250_Trecho_Rodoviario_L==EPSG:3857={width}={height}={bbox}=image%2Fpng=TRUE

Só colar e sair usando no JOSM. Não tem etiquetas com nomes na camada.
Linhas pretas = vias não pavimentadas.
- - - - - - - - - - - - - - - - - - - -
Se quiser etiquetas com nomes, usar a camada TMS "comparativo IBGE x OSM 
(2016)" que o Wille hospeda:
https://wiki.openstreetmap.org/wiki/Situa%C3%A7%C3%A3o_do_Mapeamento_de_Estradas_no_Brasil_no_OSM
- - - - - - - - - - - - - - - - - - - -
Se alguém tem contato com o DNIT, talvez se podia ver se conseguia as estradas 
deles, é o único que não tem no INDE...


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs



De: Daniel d'Andrada Tenório de Carvalho <daniel.dandr...@gmail.com>
Enviado: quarta-feira, 22 de março de 2017 11:04
Para: OpenStreetMap no Brasil
Assunto: Re: [Talk-br] TUTORIAL: Como usar as camadas WMS do IBGE (conforme 
descritas no INDE)

Legal!

Não tem como fazer aparecer direto na lista de "imagery providers" do JOSM?

On Wed, Mar 22, 2017 at 10:08 AM, Sérgio V. 
<svo...@hotmail.com<mailto:svo...@hotmail.com>> wrote:

Como usar as camadas WMS do IBGE (conforme descritas no INDE), como camadas de 
fundo no JOSM:

1) Abrir o Visualizador do INDE (http://www.visualizador.inde.gov.br/):
-Selecionar no menu esquerdo a camada de interesse (exemplo: "Redes Geodésicas 
> Rede Geodésica Altimétrica > Referências de Nível");
-Com o botão direito, visualizar "URL WMS" e copiá-la (Ctrl+C);

2) NO JOSM: Abrir menu "Preferências de Imagem" > "+WMS":
-Entrar com uma das URL (qualquer), tal como citada no INDE;
-Adicionar o "nome" da camada, tal como está nos metadados;
-Editar o campo "URL":  colar a URL tal como está abaixo  (Ctrl+V);
-OK. Fica gravado pra sempre no JOSM. Abrir camada. E pronto. Só usar quando 
quiser, já vai estar lá no JOSM.

(Ao salvar changeset, o JOSM já deve salvar automaticamente a URL da camada WMS 
como source de imagem; senão, adicionar a URL)

Licença: camadas do IBGE já aprovada a licença. (Demais, dentro da Lei de 
Acesso à Informação, Federal; a confirmar).

Para consultar relatórios de cada ponto do WMS:
-copiar a URL básica no navegador: 
http://www.bdg.ibge.gov.br/bdg/pdf/relatorio.asp?L1=
-acrescentar "ao final" da URL o "nome" da estação geodésica, tal como aparece 
no WMS (em zoom próximo); exemplo: estação "90128" (Monte Roraima):
http://www.bdg.ibge.gov.br/bdg/pdf/relatorio.asp?L1=90128
Pronto. Visualizar dados (fotos, coordenadas, altitude, etc).

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
- - - - - - - - - - - - - - - -
LISTA WMS - IBGE - Redes Geodésicas (INDE):
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
IBGE-Rede Geodésica Gravimétrica
+WMS:
-ENTRAR COM ESTA URL:
http://www.geoservicos.ibge.gov.br/geoserver/wms?service=WMS=1.1.0=GetMap=CGED:BDG_EG
-Colocar o "nome" para o WMS; dar "OK";
-Substituir ("COLAR") no campo da URL:
wms:http://www.geoservicos.ibge.gov.br/geoserver/wms?service=WMS=1.1.0=GetMap=CGED:BDG_EG==EPSG:3857={width}={height}={bbox}=image%2Fpng=TRUE<http://www.geoservicos.ibge.gov.br/geoserver/wms?service=WMS=1.1.0=GetMap=CGED:BDG_EG==EPSG:3857=%7Bwidth%7D=%7Bheight%7D=%7Bbbox%7D=image%2Fpng=TRUE>
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
IBGE-Rede Geodésica Planimétrica-Vértices de Triangulação
+WMS:
-ENTRAR COM ESTA URL:
http://www.geoservicos.ibge.gov.br/geoserver/wms?service=WMS=1.1.0=GetMap=CGED:BDG_VT
-Colocar o "nome" para o WMS; dar "OK";
-Substituir ("COLAR") no campo da URL:
wms:http://www.geoservicos.ibge.gov.br/geoserver/wms?service=WMS=1.1.0=GetMap=CGED:BDG_VT==EPSG:3857={width}={height}={bbox}=image%2Fpng=TRUE<http://www.geoservicos.ibge.gov.br/geoserver/wms?service=WMS=1.1.0=GetMap=CGED:BDG_VT==EPSG:3857=%7Bwidth%7D=%7Bheight%7D=%7Bbbox%7D=image%2Fpng=TRUE>
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
IBGE-Rede Geodésica Planimétrica-Rede GNSS Permanente - RBMC
+WMS:
-ENTRAR COM ESTA URL:
http://www.geoservicos.ibge.gov.br/geoserver/wms?service=WMS=1.1.0=GetMap=CGED:RBMC
-Colocar o "nome" para o WMS; dar "OK";
-Substituir ("COLAR") no campo da URL:
wms:http://www.geoservicos.ibge.gov.br/geoserver/wms?service=WMS=1.1.0=GetMap=CGED:RBMC==EPSG:3857={width}={height}={bbox}=image%

Re: [Talk-br] Digest Talk-br, volume 102, assunto 24

[Sérgio V .]

Obrigado Luis, grande aporte seria.


Se ver qualquer coisa que precise melhorar na proposta em Inglês, fique à 
vontade pra corrigir. Pode mandar por aqui mesmo. Como preferir.


E se acharem que precisa fazer uma versão da wiki em inglês (:en)", também, à 
vontade.


Vi que você é do IBGE. Ótimo ter a presença, o interesse e conhecimento de 
vocês aqui também.

Pensei em focar na relevância das estações planialtimétricas (deixando de lado 
as estações gravimétricas e maregráficas, poucas).

Para as Referências de Nível, fiz a geração de Altitude Geométrica (h) a partir 
dos dados de Altitude Ortométrica (H),  e (N) conforme o MAPGEO2015_v1_0.exe .

Qualquer coisa que acharem que mereça melhorar ou corrigir na proposta em 
geral, por favor, sintam-se à vontade para mandar seus aportes.

Obrigado


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs



De: Luis Bahiana <luis.bahi...@gmail.com>
Enviado: sexta-feira, 17 de março de 2017 13:49
Para: talk-br@openstreetmap.org
Assunto: Re: [Talk-br] Digest Talk-br, volume 102, assunto 24

Se precisarem de ajuda para tradução ou versão coloco-me a disposição

2017-03-14 13:23 GMT-03:00 
<talk-br-requ...@openstreetmap.org<mailto:talk-br-requ...@openstreetmap.org>>:
Enviar submissões para a lista de discussão Talk-br para
talk-br@openstreetmap.org<mailto:talk-br@openstreetmap.org>

Para se cadastrar ou descadastrar via WWW, visite o endereço
https://lists.openstreetmap.org/listinfo/talk-br
ou, via email, envie uma mensagem com a palavra 'help' no assunto ou
corpo da mensagem para

talk-br-requ...@openstreetmap.org<mailto:talk-br-requ...@openstreetmap.org>

Você poderá entrar em contato com a pessoa que gerencia a lista pelo
endereço
talk-br-ow...@openstreetmap.org<mailto:talk-br-ow...@openstreetmap.org>

Quando responder, por favor edite sua linha Assunto assim ela será
mais específica que "Re: Contents of Talk-br digest..."


Tópicos de Hoje:

   1. Proposal of import: Brazilian Geodetic Network
  (man_made=survey_points) (Sérgio V.)


--

Message: 1
Date: Tue, 14 Mar 2017 16:22:41 +
From: Sérgio V. <svo...@hotmail.com<mailto:svo...@hotmail.com>>
To: "talk-br@openstreetmap.org<mailto:talk-br@openstreetmap.org>" 
<talk-br@openstreetmap.org<mailto:talk-br@openstreetmap.org>>
Subject: [Talk-br] Proposal of import: Brazilian Geodetic Network
(man_made=survey_points)
Message-ID:

<ro1p152mb0810a9f1942bd6c60818e9fd90...@ro1p152mb0810.lamp152.prod.outlook.com<mailto:ro1p152mb0810a9f1942bd6c60818e9fd90...@ro1p152mb0810.lamp152.prod.outlook.com>>

Content-Type: text/plain; charset="utf-8"

Bom dia pessoal, estou preparando a proposta abaixo para o 
https://lists.openstreetmap.org/pipermail/imports/.

Por favor sintam-se livres para examinar.

Antecipadamente obrigado.

- - - - - - - - - - - - - - - -

Hello.
I'm member of brazilian OSM users community.
I present here for discussion, and asking approval for, the proposal for the 
import of brazilian geodetic network of survey points (SGB - Sistema Geodésico 
Brasileiro).
Firstly, sorry if not good english. Also sorry for the technical problems that 
arose due to the size of elements in previously ill imported relation.

This proposal was previously formally informed in brazilian talk list in 
https://lists.openstreetmap.org/pipermail/talk-br/2017-March/012063.html .
(Also this post here will be copied to brazilian talk list.)

The discussions in Brazilian community: actually started in 6th march in 
Telegram channel of the brazilian community, where it has been carried on, and 
where we generally use to talk most (159 members, around some 80 users 
connecting daily and some 20 activelly communicating). Many members made 
remarks and suggestions about it and, after all arrangements, general aprovals 
for procedures and utility purpose.

The purpose of this proposal: is to import the survey points published by the 
brazilian government agency for geographical data (called IBGE - 
(http://www.ibge.gov.br/home/geociencias/geodesia/default_sgb_int.shtm).

The source data: is all produced and published by IBGE.
The government also publishes these data through the more general portal for 
brazilian spatial data (INDE: 
http://www.visualizador.inde.gov.br<http://www.visualizador.inde.gov.br/> - 
Menu: Redes Geodesicas), from where it was dowloaded.

About the licenses for the data: as said in previous exchange of messages of 
other brazilian OSM member with IBGE officials [1], and as stated by the 
brazilian national law for access to information (known as "LAI"), all the 
government data, including IBGE, is free for access, not even requiring to say 
what for it is intended [2] (the exceptions quoted in the law mus

Re: [Talk-br] Digest Talk-br, volume 102, assunto 24

[Sérgio V .]

Obrigado Tomio. De fato o Telegram não fica amplamente acessível.

Colocando por aqui como canal oficial do OSM é mais certo mesmo.


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs



De: Helio Cesar Tomio <hcto...@gmail.com>
Enviado: sexta-feira, 17 de março de 2017 17:30
Para: OpenStreetMap no Brasil
Assunto: Re: [Talk-br] Digest Talk-br, volume 102, assunto 24

Texto muito bom Sérgio.
Toda a história a limpo, desmentindo aquela alegação que não houve discussão 
anteriormente.

Em 17/03/2017 13:50, "Luis Bahiana" 
<luis.bahi...@gmail.com<mailto:luis.bahi...@gmail.com>> escreveu:
Se precisarem de ajuda para tradução ou versão coloco-me a disposição

2017-03-14 13:23 GMT-03:00 
<talk-br-requ...@openstreetmap.org<mailto:talk-br-requ...@openstreetmap.org>>:
Enviar submissões para a lista de discussão Talk-br para
talk-br@openstreetmap.org<mailto:talk-br@openstreetmap.org>

Para se cadastrar ou descadastrar via WWW, visite o endereço
https://lists.openstreetmap.org/listinfo/talk-br
ou, via email, envie uma mensagem com a palavra 'help' no assunto ou
corpo da mensagem para

talk-br-requ...@openstreetmap.org<mailto:talk-br-requ...@openstreetmap.org>

Você poderá entrar em contato com a pessoa que gerencia a lista pelo
endereço
talk-br-ow...@openstreetmap.org<mailto:talk-br-ow...@openstreetmap.org>

Quando responder, por favor edite sua linha Assunto assim ela será
mais específica que "Re: Contents of Talk-br digest..."


Tópicos de Hoje:

   1. Proposal of import: Brazilian Geodetic Network
  (man_made=survey_points) (Sérgio V.)


----------

Message: 1
Date: Tue, 14 Mar 2017 16:22:41 +
From: Sérgio V. <svo...@hotmail.com<mailto:svo...@hotmail.com>>
To: "talk-br@openstreetmap.org<mailto:talk-br@openstreetmap.org>" 
<talk-br@openstreetmap.org<mailto:talk-br@openstreetmap.org>>
Subject: [Talk-br] Proposal of import: Brazilian Geodetic Network
(man_made=survey_points)
Message-ID:

<ro1p152mb0810a9f1942bd6c60818e9fd90...@ro1p152mb0810.lamp152.prod.outlook.com<mailto:ro1p152mb0810a9f1942bd6c60818e9fd90...@ro1p152mb0810.lamp152.prod.outlook.com>>

Content-Type: text/plain; charset="utf-8"

Bom dia pessoal, estou preparando a proposta abaixo para o 
https://lists.openstreetmap.org/pipermail/imports/.

Por favor sintam-se livres para examinar.

Antecipadamente obrigado.

- - - - - - - - - - - - - - - -

Hello.
I'm member of brazilian OSM users community.
I present here for discussion, and asking approval for, the proposal for the 
import of brazilian geodetic network of survey points (SGB - Sistema Geodésico 
Brasileiro).
Firstly, sorry if not good english. Also sorry for the technical problems that 
arose due to the size of elements in previously ill imported relation.

This proposal was previously formally informed in brazilian talk list in 
https://lists.openstreetmap.org/pipermail/talk-br/2017-March/012063.html .
(Also this post here will be copied to brazilian talk list.)

The discussions in Brazilian community: actually started in 6th march in 
Telegram channel of the brazilian community, where it has been carried on, and 
where we generally use to talk most (159 members, around some 80 users 
connecting daily and some 20 activelly communicating). Many members made 
remarks and suggestions about it and, after all arrangements, general aprovals 
for procedures and utility purpose.

The purpose of this proposal: is to import the survey points published by the 
brazilian government agency for geographical data (called IBGE - 
(http://www.ibge.gov.br/home/geociencias/geodesia/default_sgb_int.shtm).

The source data: is all produced and published by IBGE.
The government also publishes these data through the more general portal for 
brazilian spatial data (INDE: 
http://www.visualizador.inde.gov.br<http://www.visualizador.inde.gov.br/> - 
Menu: Redes Geodesicas), from where it was dowloaded.

About the licenses for the data: as said in previous exchange of messages of 
other brazilian OSM member with IBGE officials [1], and as stated by the 
brazilian national law for access to information (known as "LAI"), all the 
government data, including IBGE, is free for access, not even requiring to say 
what for it is intended [2] (the exceptions quoted in the law must not even be 
published by the government). IBGE officials explicitly stated, as in previous 
quoted messages, it's free for OSM purposes, for copy, sharing and changes, 
since quoting the source, and not requiring further back communication.

The aim of the import: is to have all these points with their precise 
coordinates provided by the government, placed in OSM brazilian map to help on 
aligning imagery, fixing borders, found places i

Re: [Talk-br] Proposal of import: Brazilian Geodetic Network (man_made=survey_points)

[Sérgio V .]

Tentando acertar também os cabeçalhos do tópico em re:, espero que agora vá 
certo.

Objeções (numeradas) da parte do DWG (em inglês em: 
http://www.openstreetmap.org/changeset/46795156 )
e fundamentação/soluções abaixo:

1) Relação:
- a relação muito grande envolvendo todos os nós de "survey_point" causou 
problemas em sistemas (problema técnico do osm2pgsql);
- não se deve usar relação para agrupar elementos que não os citados na wiki 
própria (problema não técnico, mais de convenção).
Este aparentemente foi o maior problema, o técnico. Também conforme comentários 
no https://github.com/openstreetmap/osm2pgsql/issues/713
Solução: Relação removida; (problema no osm2pgsql também resolvido pelos 
desenvolvedores).

2) Não foi discutido nas listas talk-br (esta) e talk-import 
(https://lists.openstreetmap.org/pipermail/imports/);
-Proposta inicial em 
https://lists.openstreetmap.org/pipermail/talk-br/2017-March/012063.html ;
-depois seguiu no Telegram;
-no canal Telegram não é suficiente;
-o canal correto é a talk-list;
Solução: Trazido para cá novamente.

3) Contém "note=Não alterar: coordenadas originais do IBGE"
3.1) "Que uso pode ter um objeto que não se pode alterar no OSM?"
Argumentação:
A princípio, não se deve alterar nada já mapeado no OSM sem um motivo maior. 
Não se deve tirar as ruas de lugar.
Pontos com coordenadas precisas, mais ainda. Não garante nada, mas não custa 
colocar um aviso.
Há notas idênticas em importação oficialmente aprovada:
https://wiki.openstreetmap.org/wiki/WikiProject_France/Rep%C3%A8res_G%C3%A9od%C3%A9siques#Permanence_des_rep.C3.A8res)
"note=Ne pas déplacer ce point, cf. - Do not move this node, see..."
Solução explicativa:
Acrescentada explicação do que não deve ser alterado:
"note=Não deslocar o ponto (coordenadas originais do IBGE)"
"note:en=Please: do not displace the point (official coordinates)"
Foi o único comentário negativo neste ponto.

3.2) "Que uso pode ter ...? Qualquer um interessado em fazer qualquer coisa com 
survey_points pode apenas usar o shape file..."
Foi o único comentário negativo sobre utilidade de importar  "survey_point" 
(que vi).

Não tem solução no momento:
Nada que tiver um shapefile precisaria estar no OSM. Nem estradas, nem rios. 
(Nem talvez fire_hydrants).
O OSM não valida utilidade: "Qualquer um pode contribuir com o que quiser"  ( 
https://wiki.openstreetmap.org/wiki/Pt:Boas_pr%C3%A1ticas ).

Mas sim, tem proposta de uso [1]:
"Ter no OSM pontos com coordenadas e altitude precisas, para aferição de 
imagens, limites de fronteiras, localidades não mapeadas, etc."
Limite de fronteira a revisar, p.ex., já foi encontrado com uma das estações: 
http://www.bdg.ibge.gov.br/bdg/pdf/relatorio.asp?L1=90128

4) Observador não conseguiu encontrar elemento físico no terreno, ao qual 
refere o ponto:
Não tem solução no momento:
-Grande parte dos dados do osm não são visíveis na imagem de satélite (número 
de porta; nome de loja; etc)
-Uma ainda muito maior parte não tem coordenadas precisas (somente aproximada, 
pelas imagens; ou de importação de vetores em baixa resolução);
-Survey points originais de órgãos oficiais são pontos com coordenadas precisas 
(eventualmente também altitude);
-As imagens de satélite melhoram ano após ano; os pontos estando lá, podem ser 
usados.
Também foi o único comentário negativo quanto a visibilidade de "survey_point".

A relação parece ter sido o maior problema. Não imaginava que tinha problemas 
técnicos.
Sim, de todo modo foi péssima ideia.
Removida.

A tag survey_point (marcos topográficos, geodésicos, de fronteira, etc) só tem 
sentido de existir pra que sejam mapeados no OSM.
Survey_point é pra ter coordenadas oficiais e precisas, em princípio (é 
diferente de estradas e rios, que podem ser mapeados só manualmente e 
aproximadamente).
Em vários locais do mundo já estão mapeados:
-ou manualmente (aproximadamente, com utilidade bem mais limitada);
-ou importados com coordenadas originais precisas, bem mais úteis (quando é 
liberado acesso a eles, como no Brasil).

A descrição completa da proposta em português tá na wiki:
https://wiki.openstreetmap.org/wiki/Importa%C3%A7%C3%A3o_das_Redes_Geod%C3%A9sicas_do_IBGE
 [1]


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs


>gorila em openmailbox.org gorila em openmailbox.org
>Sexta Março 17 22:29:24 UTC 2017
>Mensagem anterior: [Talk-br] Digest Talk-br, volume 102, assunto 24

>Por aqui, fica melhor registrado.
>Também seria importante redirecionar as eventuais objeções para a lista
>email. E, eu acho que o autor deveria fundamentá-las em português, para
>a comunidade local avaliar e decidir se procedem.


___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Proposal of import: Brazilian Geodetic Network (man_made=survey_points)

[Sérgio V .]

Ok, pode ser. Ótimo se der pra aproveitar os mesmo nós.

Estou fazendo mais umas coisas:

Colocando as urls dos relatórios de todos os 45.662 (tem descrições que ajudam 
a identificar no terreno, etc, muitos tem fotos). Só que tavam em outra fonte 
do IBGE .

(p. ex. ao invés do  
ftp://geoftp.ibge.gov.br/RBMC/relatorio/Descritivo_MSAQ.pdf ...  , estava no 
http://www.bdg.ibge.gov.br/bdg/pdf/relatorio.asp?L1=99614, sendo  
http://www.bdg.ibge.gov.br/bdg/pdf/relatorio.asp?L1= * , onde * é o código da 
estação - o ref=* )

Assim que terminar a conflação nos DBF dos SHP e converter pra .osm de novo 
envio pra um dropbox.  Dá uns 30MB.

Obrigado


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs



De: Nelson A. de Oliveira 
Enviado: sábado, 18 de março de 2017 13:38
Para: OpenStreetMap no Brasil
Assunto: Re: [Talk-br] Proposal of import: Brazilian Geodetic Network 
(man_made=survey_points)

Parece bom depois das correções.

O que eu faria (e falaria ao enviar para a lista imports) é
reaproveitar¹ os dados que já foram inseridos anteriormente (e depois
revertidos).
Tomando o cuidado apenas para ajustar o que precisa e não recriar as relações.

Assim se torna desnecessário criar novos objetos no mapa.

Sérgio, só pra ter mais garantia e também fornecer os dados para
análise (acho que vão querer ver na imports), tem como fazer os
ajustes e disponibilizar o arquivo .osm em algum lugar para verificar?

¹ é uma reversão da reversão: reverte, remove as relações, ajusta note
e outras informações, verifica 10 vezes

___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Proposal of import: Brazilian Geodetic Network (man_made=survey_points)

[Sérgio V .]

Simplificando a mensagem anterior,

a proposta completa referida está em português, documentada na wiki, em:


https://wiki.openstreetmap.org/wiki/Importa%C3%A7%C3%A3o_das_Redes_Geod%C3%A9sicas_do_IBGE


Att.,


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Proposal of import: Brazilian Geodetic Network (man_made=survey_points)

[Sérgio V .]

Envio o link para download do arquivo.


Após convertidos para .OSM os SHP das redes geodésicas (é isolado do OSM; não é 
conflação sobre o revertido).

Revisei e coloquei mais todos os dados de "ele" (Altitude Geométrica) das 
demais redes (não só RN). E para onde não tinha A.Geométrica para "ele=*", mas 
tinha Altitude Ortométrica, converti "ele=*" a partir desta com o software 
"mapgeo" do IBGE.

E conservei os dados de Altitude Ortométrica como "ele:orto=*".

Se bem que o mais importante são as coordenadas mesmo. Mas as altitudes também 
são dados úteis. Já que tão lá, se pode colocar o que tem. Já que teve que 
revisar mesmo a importação, aproveitar pra colocar mais o que tem.


Link no dropbox:


https://www.dropbox.com/s/d3y9nvg5y806i93/Redes%20Geod%C3%A9sicas-convertidos%20para%20osm-validacao.rar?dl=0

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Contém:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

1)ARQUIVO: "1REDES GEODESICAS - TOTAL - 06 redes - 45622 objects.osm"

O total das 6 redes: convertidas dos SHP primeiro isoladamente; depois 
juntadas, tudo em 1 só .osm. (Para separar, selecionar por "description=*" , 
conforme os 06 tipos). (é isolado do OSM; não é conflação sobre o revertido).

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

2) ARQUIVO: "1Validacao interna -1519 warnings nodes same pos -3114 objects.osm"

Validação nos 45622 nós (sem baixar survey_points existentes no OSM).

"warning = nodes at same position" : 3114 nós. Entram com as coordenadas assim, 
vindos dos SHP originais. São pontos no mesmo marco físico, mas de redes 
diferentes. Isoladas, cada rede não tem sobreposição (só 3 casos nos RN). Só 
quando junta as 6 redes todas.


"Warning" não é erro...

Mas se precisar, dá pra fundir, fazer "merge", mas aí muda o número de objetos 
(se for pra re-reverter).

E se fizer "merge", como manter as diferentes "ref=*"  e "url=*" de cada um 
deles ? Concatenar com ";" as tags diferentes?  "ref=X;Y;Z... /  url=X;Y;Z...?  
Tem algum meio de fazer isso automaticamente? Através do JOSM?

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

3) ARQUIVO: "1Validação externa -OSM overpass -warnings nodes same pos -17 
objects "

O resultado da validação após baixados via overpass os survey_points existentes 
no OSM no Brasil: "warning = nodes at same position" :  17 objetos


Importações isoladas de survey_points, de outras épocas (nem todos tem 
source=IBGE... ou coisa parecida.).

Dá pra fazer "replace geometry" nestes 17 (mantendo o histórico), para eliminar 
os "warnings ".

Mas aí a examinar individualmente como ficam as tags ref=*, etc,  em comparação 
com o a ser importado.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Acho que era isso por enquanto. A ver se daria mesmo pra fazer isto em cima dos 
 revertidos. Teve 01 nó que vi que não sei se eles esqueceram de fora quando 
reverteram: http://www.openstreetmap.org/node/4731118821 . Não sei se não dá 
problema no número total a repor, se fosse re-reverter.  Vou tentando testar 
como ficaria.
Senão se propõe mesmo uma re-reversão "simples" (se é que isto pode ser chamado 
de simples) sem adicionar mais dados para os mesmos pontos. Ficando só como 
tavam (sem as relações claro).

Valeu.


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs



De: Nelson A. de Oliveira 
Enviado: sábado, 18 de março de 2017 13:38
Para: OpenStreetMap no Brasil
Assunto: Re: [Talk-br] Proposal of import: Brazilian Geodetic Network 
(man_made=survey_points)

Parece bom depois das correções.

O que eu faria (e falaria ao enviar para a lista imports) é
reaproveitar¹ os dados que já foram inseridos anteriormente (e depois
revertidos).
Tomando o cuidado apenas para ajustar o que precisa e não recriar as relações.

Assim se torna desnecessário criar novos objetos no mapa.

Sérgio, só pra ter mais garantia e também fornecer os dados para
análise (acho que vão querer ver na imports), tem como fazer os
ajustes e disponibilizar o arquivo .osm em algum lugar para verificar?

¹ é uma reversão da reversão: reverte, remove as relações, ajusta note
e outras informações, verifica 10 vezes

___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Proposal of import: Brazilian Geodetic Network - Alternativa WMS / IBGE

[Sérgio V .]

Bom dia pessoal,

após sugestão do Luis Bahiana (email abaixo), deu certo colocar todos os WMS 
das Redes Geodésicas do IBGE no JOSM.

Pensei então que, para o propósito de auxiliar no alinhamento de imagens (que 
era o principal do meu ponto de vista), não é necessário importar os SHP dos 
marcos geodésicos (estações de medição da rede geodésica). Basta ter como 
camada auxiliar WMS no JOSM ou iD.

As medições geodésicas podem ir melhorando com o tempo. No SHP ficariam 
desatualizadas. Teria que saber toda vez que muda para alterar. No WMS, já 
ficam atualizadas automaticamente.


Além disso, com o link dos relatórios como auxiliar, se pode consultar 
facilmente os demais dados, como: localidade, altitude, coordenadas, etc. Para 
isto, basta copiar a URL básica dos relatórios e substituir no final pelo nome 
(ref) da estação que aparece nos WMS (em zoom próximo).


Por exemplo, URL básica:

http://www.bdg.ibge.gov.br/bdg/pdf/relatorio.asp?L1=




Adaptada para a estação "90128" (Monte Roraima):

http://www.bdg.ibge.gov.br/bdg/pdf/relatorio.asp?L1=90128


Além disto, há um problema de precisão, se importar direto as coordenadas 
conforme estão no SHP:


Muitas estações possuem grande precisão, p.ex 4 casas decimais em segundos 
(~3mm; como a "90128" do Monte Roraima, acima).

Mas muitas outras estações ainda estão em graus/minutos/segundos, com precisão 
de segundo inteiro (sem decimal) .

Ex.: http://www.bdg.ibge.gov.br/bdg/pdf/relatorio.asp?L1=3018T (23 ° 24 ' 02 " 
S, 45 ° 37 ' 02 " W)

Ou seja, uma precisão de 1 segundo (inteiro, sem decimal) de arco na linha do 
equador dá uma margem de erro de ~30m.

O que não ajudaria muito a alinhar imagem no OSM, dados, etc, pois fica até 
acima da margem de erro do GPS comum (10-20m).


"Por mim", suspendo a proposta de importação dos marcos em SHP, e se pode usar 
os WMS, sempre atualizados.

A princípio, dá pra usar todas as camadas WMS citadas nos metadados no INDE 
direto no JOSM.


Vou trocar de tópico a seguir, onde descreverei como usar os WMS do IBGE (e do 
INDE em geral, para as demais camadas de interesse, só que aí tem que ainda 
testar os parâmetros ESRI de GetMap.)

Dá também pra fazer uma wiki tutorial pra estes WMS.


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs


>On 2017-03-22 00:48:25 UTC Luis Bahiana wrote:
>Sérgio Uma coisa que esqueci de mencionar. Voce deve ter notado que no 
>Visualizador da INDE em cada tema,clicando com a tecla direita abre um 
>menuzinho de download. Então, uma das opções é WMS que é o acronimo de Web Map 
>Services. Com isso voce pode servir a sua camada como um geoserviço web. Ao 
>invés de baixar um SHP que pode se desatualizar, com o serviço web você tem a 
>garantia que tem a versão mais atual. Nunca tentei mas acho que é possivel 
>consumir no JOSM não? Abs Bahiana

___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] TUTORIAL: Como usar as camadas WMS do IBGE (conforme descritas no INDE)

[Sérgio V .]

Como usar as camadas WMS do IBGE (conforme descritas no INDE), como camadas de 
fundo no JOSM:

1) Abrir o Visualizador do INDE (http://www.visualizador.inde.gov.br/):
-Selecionar no menu esquerdo a camada de interesse (exemplo: "Redes Geodésicas 
> Rede Geodésica Altimétrica > Referências de Nível");
-Com o botão direito, visualizar "URL WMS" e copiá-la (Ctrl+C);

2) NO JOSM: Abrir menu "Preferências de Imagem" > "+WMS":
-Entrar com uma das URL (qualquer), tal como citada no INDE;
-Adicionar o "nome" da camada, tal como está nos metadados;
-Editar o campo "URL":  colar a URL tal como está abaixo  (Ctrl+V);
-OK. Fica gravado pra sempre no JOSM. Abrir camada. E pronto. Só usar quando 
quiser, já vai estar lá no JOSM.

(Ao salvar changeset, o JOSM já deve salvar automaticamente a URL da camada WMS 
como source de imagem; senão, adicionar a URL)

Licença: camadas do IBGE já aprovada a licença. (Demais, dentro da Lei de 
Acesso à Informação, Federal; a confirmar).

Para consultar relatórios de cada ponto do WMS:
-copiar a URL básica no navegador: 
http://www.bdg.ibge.gov.br/bdg/pdf/relatorio.asp?L1=
-acrescentar "ao final" da URL o "nome" da estação geodésica, tal como aparece 
no WMS (em zoom próximo); exemplo: estação "90128" (Monte Roraima):
http://www.bdg.ibge.gov.br/bdg/pdf/relatorio.asp?L1=90128
Pronto. Visualizar dados (fotos, coordenadas, altitude, etc).

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
- - - - - - - - - - - - - - - -
LISTA WMS - IBGE - Redes Geodésicas (INDE):
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
IBGE-Rede Geodésica Gravimétrica
+WMS:
-ENTRAR COM ESTA URL:
http://www.geoservicos.ibge.gov.br/geoserver/wms?service=WMS=1.1.0=GetMap=CGED:BDG_EG
-Colocar o "nome" para o WMS; dar "OK";
-Substituir ("COLAR") no campo da URL:
wms:http://www.geoservicos.ibge.gov.br/geoserver/wms?service=WMS=1.1.0=GetMap=CGED:BDG_EG==EPSG:3857={width}={height}={bbox}=image%2Fpng=TRUE
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
IBGE-Rede Geodésica Planimétrica-Vértices de Triangulação
+WMS:
-ENTRAR COM ESTA URL:
http://www.geoservicos.ibge.gov.br/geoserver/wms?service=WMS=1.1.0=GetMap=CGED:BDG_VT
-Colocar o "nome" para o WMS; dar "OK";
-Substituir ("COLAR") no campo da URL:
wms:http://www.geoservicos.ibge.gov.br/geoserver/wms?service=WMS=1.1.0=GetMap=CGED:BDG_VT==EPSG:3857={width}={height}={bbox}=image%2Fpng=TRUE
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
IBGE-Rede Geodésica Planimétrica-Rede GNSS Permanente - RBMC
+WMS:
-ENTRAR COM ESTA URL:
http://www.geoservicos.ibge.gov.br/geoserver/wms?service=WMS=1.1.0=GetMap=CGED:RBMC
-Colocar o "nome" para o WMS; dar "OK";
-Substituir ("COLAR") no campo da URL:
wms:http://www.geoservicos.ibge.gov.br/geoserver/wms?service=WMS=1.1.0=GetMap=CGED:RBMC==EPSG:3857={width}={height}={bbox}=image%2Fpng=TRUE
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
IBGE-Rede Geodésica Planimétrica-Estações SAT GPS
+WMS:
-ENTRAR COM ESTA URL:
http://www.geoservicos.ibge.gov.br/geoserver/wms?service=WMS=1.1.0=GetMap=CGED:BDG_GPS
-Colocar o "nome" para o WMS; dar "OK";
-Substituir ("COLAR") no campo da URL:
wms:http://www.geoservicos.ibge.gov.br/geoserver/wms?service=WMS=1.1.0=GetMap=CGED:BDG_GPS==EPSG:3857={width}={height}={bbox}=image%2Fpng=TRUE
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
IBGE-Rede Geodésica Planimétrica-Estações SAT DOPPLER
+WMS:
-ENTRAR COM ESTA URL:
http://www.geoservicos.ibge.gov.br/geoserver/wms?service=WMS=1.1.0=GetMap=CGED:BDG_DOP
-Colocar o "nome" para o WMS; dar "OK";
"COLAR" no campo da URL:
wms:http://www.geoservicos.ibge.gov.br/geoserver/wms?service=WMS=1.1.0=GetMap=CGED:BDG_DOP==EPSG:3857={width}={height}={bbox}=image%2Fpng=TRUE
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
IBGE-Rede Geodésica Planimétrica-Estações de Poligonal
+WMS:
-ENTRAR COM ESTA URL:
http://www.geoservicos.ibge.gov.br/geoserver/wms?service=WMS=1.1.0=GetMap=CGED:BDG_EP
-Colocar o "nome" para o WMS; dar "OK";
-Substituir ("COLAR") no campo da URL:
wms:http://www.geoservicos.ibge.gov.br/geoserver/wms?service=WMS=1.1.0=GetMap=CGED:BDG_EP==EPSG:3857={width}={height}={bbox}=image%2Fpng=TRUE
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
IBGE-Rede Geodésica Altimétrica-Referência de Nível
+WMS:
-ENTRAR COM ESTA URL:
http://www.geoservicos.ibge.gov.br/geoserver/wms?service=WMS=1.1.0=GetMap=CGED:BDG_RN
-Colocar o "nome" para o WMS; dar "OK";
-Substituir ("COLAR") no campo da URL:
wms:http://www.geoservicos.ibge.gov.br/geoserver/wms?service=WMS=1.1.0=GetMap=CGED:BDG_RN==EPSG:3857={width}={height}={bbox}=image%2Fpng=TRUE
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
- - - - - - - - - - - - - - - -

Todas estas WMS testei, funcionando OK.


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org

Re: [Talk-br] Proposal of import: Brazilian Geodetic Network (man_made=survey_points)

[Sérgio V .]

É, tive que fazer uma grande cagada pra descobrirem a falha no sistema.

A relação causou vários problemas.

Com o acréscimo de não ter sido discutida aqui no talk-br.

Mais no telegram. Mesmo assim não suficiente. Teve que ser revertida.

A relação não foi uma boa ideia. Foi removida.

O resto da proposta parece boa.



- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs



De: Alexandre Magno Brito de Medeiros <alexandre@gmail.com>
Enviado: quinta-feira, 16 de março de 2017 18:44
Para: OpenStreetMap no Brasil
Assunto: Re: [Talk-br] Proposal of import: Brazilian Geodetic Network 
(man_made=survey_points)

Uma "relação monstruosa" de uma importação não discutida no 
Brasil<https://www.openstreetmap.org/changeset/46795156> com mais de 32.767 
membros foi grande 
demais<https://github.com/openstreetmap/osm2pgsql/issues/713> para o osm2pgsql, 
o que provavelmente causou problemas em muitos servidores.

Fonte: semanárioOSM 347<http://www.weeklyosm.eu/pb/archives/8867>

2017-03-14 13:22 GMT-03:00 Sérgio V. 
<svo...@hotmail.com<mailto:svo...@hotmail.com>>:

Bom dia pessoal, estou preparando a proposta abaixo para o 
https://lists.openstreetmap.org/pipermail/imports/.

Por favor sintam-se livres para examinar.

Antecipadamente obrigado.

- - - - - - - - - - - - - - - -

Hello.
I'm member of brazilian OSM users community.
I present here for discussion, and asking approval for, the proposal for the 
import of brazilian geodetic network of survey points (SGB - Sistema Geodésico 
Brasileiro).
Firstly, sorry if not good english. Also sorry for the technical problems that 
arose due to the size of elements in previously ill imported relation.

This proposal was previously formally informed in brazilian talk list in 
https://lists.openstreetmap.org/pipermail/talk-br/2017-March/012063.html .
(Also this post here will be copied to brazilian talk list.)

The discussions in Brazilian community: actually started in 6th march in 
Telegram channel of the brazilian community, where it has been carried on, and 
where we generally use to talk most (159 members, around some 80 users 
connecting daily and some 20 activelly communicating). Many members made 
remarks and suggestions about it and, after all arrangements, general aprovals 
for procedures and utility purpose.

The purpose of this proposal: is to import the survey points published by the 
brazilian government agency for geographical data (called IBGE - 
(http://www.ibge.gov.br/home/geociencias/geodesia/default_sgb_int.shtm).

The source data: is all produced and published by IBGE.
The government also publishes these data through the more general portal for 
brazilian spatial data (INDE: 
http://www.visualizador.inde.gov.br<http://www.visualizador.inde.gov.br/> - 
Menu: Redes Geodesicas), from where it was dowloaded.

About the licenses for the data: as said in previous exchange of messages of 
other brazilian OSM member with IBGE officials [1], and as stated by the 
brazilian national law for access to information (known as "LAI"), all the 
government data, including IBGE, is free for access, not even requiring to say 
what for it is intended [2] (the exceptions quoted in the law must not even be 
published by the government). IBGE officials explicitly stated, as in previous 
quoted messages, it's free for OSM purposes, for copy, sharing and changes, 
since quoting the source, and not requiring further back communication.

The aim of the import: is to have all these points with their precise 
coordinates provided by the government, placed in OSM brazilian map to help on 
aligning imagery, fixing borders, found places in remote regions, etc.

It can be objected: found no survey point in imagery on the ground.
That's true. Many things pedestrians have mapped can't be seen on sattelite 
imagery now, like door numbers, shop names, highway signals, and many other 
small things, perhaps also fire_hidrants, etc. It usually resides all on local 
mapper's word.
Also imagery resolution is improving constantly, so perhaps not too later we 
all can see many more things on sattelite imagery.
Anyway, the government, through its data itself and its official reports of 
survey points, states they are there on the ground.

As a single example: there's a survey point (a small plate) over a 
boundary_stone in the Brazil-Venezuela-Guyana triple border, reported in [3]. 
It seems not visible in imagery, nor the boundary_stone. At least I still 
haven't found it (but I'm looking for). But just seeing this officialy reported 
point in JOSM (5.2018977222<tel:(201)%20897-7222>, -60.737554)[4] indicates 
this triple border in OSM is currently more than 1km far from that official 
measurement, thus deserving some revision.

Other general informations:
-All the objects proposed to import came previously converted by IBGE in WGS84 
format in the original downlo

Re: [Talk-br] divulgação dos dados

[Sérgio V .]

Bem-vindo Vinicius,

Isso, também acho que basta o coordenador do projeto enviar um email simples 
para esta lista aqui autorizando a importação.


Quanto às tags utilizadas, talvez seja bom dar uma verificada nas mais 
adequadas, por exemplo em:

 http://www.openstreetmap.org/changeset/47337726

*name=Salgado da Dona Tereza
*shop=kitchen  >> (https://wiki.openstreetmap.org/wiki/Pt:Tag:shop%3Dkitchen) é 
para loja que vende mobiliário de cozinha;
mas, pelo nome do estabelecimento, me parece, seria uma lancheria ou similar?
Neste caso talvez:  
https://wiki.openstreetmap.org/wiki/Pt:Tag:amenity%3Dfast_food#Fast-food ?
Mais: cuisine=... (https://wiki.openstreetmap.org/wiki/Pt:Key:cuisine)

http://www.openstreetmap.org/node/4762959049
*name=Associação de moradores do bairro Engenharia
*office=association >> pelo nome do estabelecimento, me parece, seria adequado 
amenity=community_centre ? 
(https://wiki.openstreetmap.org/wiki/Pt:Tag:amenity%3Dcommunity_centre)
*suburb=Engenharia  >>  se for para bairro se usa "addr:suburb=" 
(https://wiki.openstreetmap.org/wiki/Key:place#Values)

Já que você tem vários objetos,  seria bom ajustar de início pra depois não 
precisar ficar voltando a cada um.
Veja quais tags lhe servem melhor para os objetos mapeados, você pode procurar 
pelas "chaves" (key): 
https://wiki.openstreetmap.org/wiki/Pt-br:Elementos_de_Mapa

Ótima contribuição.


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Proposta de Importação - Redes Geodésicas / IBGE

[Sérgio V .]

Prezados,

conforme conversado no Telegram, compartilho link da wiki com a Proposta de 
Importação das "Redes Geodésicas do IBGE" (em desenvolvimento).

Tratam-se de marcos físicos, com coordenadas exatas, podendo ser identificados 
em imagem (nem sempre).

Alguns estão em pilares, outros em prédios, telhados, etc.

Proposta é somente importar os catalogados em boa situação (campo 
"SITUACAO"=BOM).

Servem como auxiliares na verificação de alinhamento de imagens e objetos, 
identificação de prédios, localidades remotas, etc.

Para manutenção dos dados, quando necessário podem ser alterados em bloco:

isto é, quando houver significativa alteração de coordenadas (pela deriva 
continental, cerca de 20cm/cada 10 anos), se pode fazer uma reposição geral.

(Daqui uns 25 anos talvez atinja o deslocamento de 1 pixel na imagem...)

Como se tratam de nós (pontos), não parece haver problemas de conflitos com 
objetos existentes, uma vez que não há importação anterior semelhante, ao menos 
registrada.

E em verificações por amostragem, não foram encontrados objetos idênticos no 
OSM.

A proposta é também criar relação com cada um dos 6 tipos de estações, e uma 
maior geral, de modo a facilitar eventual manutenção.

As tags "description" também são propostas para identificar os grupos e poder 
recuperar os objetos quando necessário.


https://wiki.openstreetmap.org/wiki/Importa%C3%A7%C3%A3o_das_Redes_Geod%C3%A9sicas_do_IBGE


REDES GEODÉSICAS


Rede Geodésica Planimétrica:
-Rede Brasileira de Monitoramento Contínuo - GNSS Permanente: RBMCPoint.SHP / 4 
KB / OBJECTS: 129
-Estações SAT DOPPLER: BDG_DOPPoint.SHP / 28 KB / OBJECTS: 1006
-Estações SAT GPS: BDG_GPSPoint.SHP / 82 KB / OBJECTS: 2977
-Estações Poligonal: BDG_EPPoint.SHP / 32 KB / OBJECTS: 1133
-Vertices Triangulacao: BDG_VTPoint.SHP / 100 KB / OBJECTS: 3643
SUB-TOTAL Planimétrica:: 7882 OBJECTS

Rede Geodésica Altimétrica:
-Referencias de Nivel: BDG_RNPoint.SHP / 613 MB / OBJECTS: 69887

Eventualmente se pode adicionar as estações das redes Gravimétrica e 
Maregráfica (esta apenas 5 pontos).


Ainda tenho que esquematizar as tags e converter. À medida que fizer, coloco na 
wiki.

Proposta importar a rede planimétrica em 1 pacote só, e somente após toda rede 
convertida.


Quaisquer questões, podem usar também a página de discussões da wiki.


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Proposal of import: Brazilian Geodetic Network (man_made=survey_points)

[Sérgio V .]

Bom dia pessoal, estou preparando a proposta abaixo para o 
https://lists.openstreetmap.org/pipermail/imports/.

Por favor sintam-se livres para examinar.

Antecipadamente obrigado.

- - - - - - - - - - - - - - - -

Hello.
I'm member of brazilian OSM users community.
I present here for discussion, and asking approval for, the proposal for the 
import of brazilian geodetic network of survey points (SGB - Sistema Geodésico 
Brasileiro).
Firstly, sorry if not good english. Also sorry for the technical problems that 
arose due to the size of elements in previously ill imported relation.

This proposal was previously formally informed in brazilian talk list in 
https://lists.openstreetmap.org/pipermail/talk-br/2017-March/012063.html .
(Also this post here will be copied to brazilian talk list.)

The discussions in Brazilian community: actually started in 6th march in 
Telegram channel of the brazilian community, where it has been carried on, and 
where we generally use to talk most (159 members, around some 80 users 
connecting daily and some 20 activelly communicating). Many members made 
remarks and suggestions about it and, after all arrangements, general aprovals 
for procedures and utility purpose.

The purpose of this proposal: is to import the survey points published by the 
brazilian government agency for geographical data (called IBGE - 
(http://www.ibge.gov.br/home/geociencias/geodesia/default_sgb_int.shtm).

The source data: is all produced and published by IBGE.
The government also publishes these data through the more general portal for 
brazilian spatial data (INDE: 
http://www.visualizador.inde.gov.br - 
Menu: Redes Geodesicas), from where it was dowloaded.

About the licenses for the data: as said in previous exchange of messages of 
other brazilian OSM member with IBGE officials [1], and as stated by the 
brazilian national law for access to information (known as "LAI"), all the 
government data, including IBGE, is free for access, not even requiring to say 
what for it is intended [2] (the exceptions quoted in the law must not even be 
published by the government). IBGE officials explicitly stated, as in previous 
quoted messages, it's free for OSM purposes, for copy, sharing and changes, 
since quoting the source, and not requiring further back communication.

The aim of the import: is to have all these points with their precise 
coordinates provided by the government, placed in OSM brazilian map to help on 
aligning imagery, fixing borders, found places in remote regions, etc.

It can be objected: found no survey point in imagery on the ground.
That's true. Many things pedestrians have mapped can't be seen on sattelite 
imagery now, like door numbers, shop names, highway signals, and many other 
small things, perhaps also fire_hidrants, etc. It usually resides all on local 
mapper's word.
Also imagery resolution is improving constantly, so perhaps not too later we 
all can see many more things on sattelite imagery.
Anyway, the government, through its data itself and its official reports of 
survey points, states they are there on the ground.

As a single example: there's a survey point (a small plate) over a 
boundary_stone in the Brazil-Venezuela-Guyana triple border, reported in [3]. 
It seems not visible in imagery, nor the boundary_stone. At least I still 
haven't found it (but I'm looking for). But just seeing this officialy reported 
point in JOSM (5.2018977222, -60.737554)[4] indicates 
this triple border in OSM is currently more than 1km far from that official 
measurement, thus deserving some revision.

Other general informations:
-All the objects proposed to import came previously converted by IBGE in WGS84 
format in the original downloaded shape file.
-There will be no relation (in OSM peculiar concept for relation) to be 
stablished between these individual points.
-Only are meant to be imported the portion of the stations classified as in 
good conditions, leaving aside the ones destructed or not found as quoted in 
the official reports. So the final total number of points to be imported is 
smaller than in the original shp.

The proposed tags are these (english translation or meaning below in 
parenthesis):

description=Rede Geodésica do IBGE - Estação SAT DOPPLER
(=IBGE Geodetic Network - <6 types of station, for: SAT DOPPLER; SAT GPS; 
Polygonal; Triangulation; Elevation Reference; Permanent GNSS>); by these 6 
types of description= station...*... the data is aimed to be also accessible 
for recalling and maintence.
ele=* (when geometric height available)
man_made=survey_point
note:en=Please: do not displace the point (official coordinates)
note=Não deslocar o ponto (coordenadas originais do IBGE)
(almost the same as note:en, with local exortation tone)
ref:loc=São Félix do Xingu
(the locality where the point is, perhaps even not mapped itself)
ref=90970
(the particular and unique name or number 

Re: [Talk-br] Nova divisão territorial substitui mesorregiões e microrregiões

[Sérgio V .]

Puxa, ótimo ter colocado isto Leonardo.
Pelo que entendi, então, quanto às MESO e MICRO regiões, colocadas no OSM como 
"admin_level", não faz o menor sentido tê-las no OSM.

Segundo as respostas do IBGE, isto não estaria certo, nem do ponto de vista 
legal, nem do prático:
-Do ponto de vista legal: elas não possuem caráter administrativo. Não são 
"admin".
-Do ponto de vista prático: não existe nada que obrigue atividade prática entre 
os membros das regiões, e se há atividade prática, não depende diretamente do 
estatuto das regiões.

Melhor então seria remover do OSM (somente) todas estas relações de meso e 
micro (sem mexer nos ways).
E sobretudo não mapear mais as novas "Regiões Geográficas Imediatas e 
Intermediárias".
Isto acaba com a trabalheira inútil de tê-las (e mais ainda de mantê-las) no 
OSM.
Ajuda a focar no que realmente interessa para estar no OSM.

- - - - -

--- Resposta do IBGE ---

..."Criadas pelo IBGE, as Microrregiões e Mesorregiões são utilizadas apenas 
para fins estatísticos. Não se constituem em entidades político-administrativas 
autônomas, não possuem qualquer instituição administrativa e nem previsão 
constitucional."...
..."Os "agrupamentos" dos estados são regionalizações que visam a organização, 
o planejamento e a execução de funções públicas. Não podendo ser definidos como 
regiões político-administrativas."...


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] OSM LatAm - Mapatona para "Assentamentos Informais" na América Latina

[Sérgio V .]

OSM LatAm está preparando uma Mapatona para "Assentamentos Informais" (vilas, 
favelas, irregulares, etc).
Abrangência proposta: toda a América Latina.

O objetivo é sobretudo mapear elementos básicos, como construções e vias dentro 
destas áreas.
A proposta vai documentada na wiki (e em sua página de discussão):
https://wiki.openstreetmap.org/wiki/OSM_Latam/AniversarioXIII_OSM

E vem em discussão e elaboração também no canal de telegram LatAm:
https://web.telegram.org/#/im?p=@OSMLatam


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] QUESTÕES SOBRE ESTATÍSTICA DE NÓS OSM NO BRASIL

[Sérgio V .]

Obrigado pelo comentário Marcos.

E desculpem pelo Caps+Lock, tava fazendo em tabela, continuei a escrever e 
colei.


É que tem alguns pontos a considerar:

-o objetivo do levantamento, iniciei pensando assim, é avaliar o mapeamento 
geral no todo, não somente de rede viária;

-e no território todo, não somente áreas urbanas;

Para ver como está a distribuição de mapeamento geral: áreas urbanas, rurais, 
território desocupado, dispersão, etc.

Sem dúvida, mapeamento de vias é importante e básico.


Outro detalhe, mais operacional:

-só do total atual no Brasil deu +/- 62 milhões nós. O que já pesou muito no 
processamento (com 4GB-RAM eu não consegui abrir o pacote  SHP, pra fazer a 
contagem de nós para os polígonos dos 316.574 setores do IBGE; o naoliv 
conseguiu, com 20GB de RAM).  Em função do que já foi pesado de processar, se 
for medir kilometragem em ways  tem que fazer mais alguns processos e 
cruzamentos prévios, o que pesa ainda mais, acredito: selecionar vias; 
selecionar em meio urbano; medir o comprimento.


Ao computar Nós/População , dá o significado de nós por pessoa.

Se computar Nós/Área(km2), dá outro significado: pode ter área de mato super 
bem mapeada, mas nenhuma pessoa lá.


Com nós fica viável de computar e me parece dá um panorama geral bom.

Indica a densidade de mapeamento, isto é, cada nó é um click de um usuário no 
mouse.

Tem o site do tyrasd, só baseado em densidade de nós:

https://tyrasd.github.io/osm-node-density/#4/-16.34/-50.54/latest,places


Os nós são o elemento fundamental de todo objeto OSM: a) nó solto; b) way 
aberto; c) way fechado; d) relação entre estes.


Também varia, se pode escolher o tipo de representação melhor para avaliar cada 
caso:

-no meio urbano: onde mais falta; onde já tem bastante e se poderia sugerir 
mapear outros lugares onde falta;

-no meio rural: idem;

-as tendências no Brasil em geral: mais mapeamento urbano, ou mais rural, 
linhas de tendência para dentro do território; etc.


À medida que eu tiver tempo vou colocar na wiki uns mapas de resultados de 
densidade de nós no Brasil (DNHab e DNKm2), pra gente ir vendo qual o mais 
representativo. Densidade populacional pura do IBGE já coloquei lá. Pretendo 
conseguir fazer alguns mapas estatísticos de nós, tipo evidenciar acima e 
abaixo do desvio padrão, etc. Tou subindo para um dropbox o SHP básico da 
contagem atual de nós-OSM em 316.574 setores-IBGE, se alguém mais tiver 
interesse em mexer nisso também, pra baixar.


O objetivo é ter uma visão geral do estado do mapeamento, e eventuais 
conclusões e propostas a nível de sugestão. O mais importante penso é apenas 
ver onde mais falta. Nunca se vai propor remover dados onde eventualmente 
esteja super mapeado. Cada um é livre pra mapear onde e o que quiser, mesmo que 
já esteja super mapeado.


Valeu, vamos pensando.


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs



De: Marcos Fedato <heroij...@hotmail.com>
Enviado: quarta-feira, 4 de outubro de 2017 18:21
Para: OpenStreetMap no Brasil
Assunto: Re: [Talk-br] QUESTÕES SOBRE ESTATÍSTICA DE NÓS OSM NO BRASIL

Eu sempre pensei em calcular extensao de ruas nas areas urbanas.

Nós variam em quantidade dependendo se alguem fez a curva mais ou menos 
detalhada vai ter mais pontos.

Eu cruzaria as manchas urbanas e as ruas e veria a densidade de m de rua por m 
quadrado de area urbana.

Daria para saber qual cidade tem mais e menos arruamento por espaço urbano e 
ver as com os menores índices nelas deve faltar ruas (será?).

Atenciosamente,
Marcos Fedato



Enviado do meu smartphone Samsung Galaxy.


 Mensagem original 
De: "Sérgio V." <svo...@hotmail.com>
Data: 04/10/17 18:09 (GMT-03:00)
Para: talk-br@openstreetmap.org
Assunto: [Talk-br] QUESTÕES SOBRE ESTATÍSTICA DE NÓS OSM NO BRASIL


Pessoal, pergunta:

QUESTÕES SOBRE ESTATÍSTICA DE NÓS OSM NO BRASIL:

Créditos à grande ajuda do naoliv extraindo e contabilizando nós por setores, e 
dicas, ideias e tentativas de vários da comunidade e do grupo QGIS.

--
EXAMES DE QUANTIDADE DE NÓS OSM (NOS SETORES CENSITÁRIOS):

Sendo:
DNH = Densidade de Nós-OSM / Habitante
DNK = Densidade de Nós-OSM / Km2
DP  = Densidade Populacional (Demográfica: Hab. / Km2)
LOCAL CD = CD_GEOCODI (setor cf. IBGE)

AMOSTRAS DE VALORES MÁXIMOS E MÍNIMOS:
(Sendo: VALORES MAIS BAIXOS DIFERENTES DE ZERO)
--
DNH MÍN.:   0.00049628 / DNK=8.12799313 / DP= 16377.90616394  / LOCAL 
CD: 230550605000146 / URBANO: Bastiana
DNH MÁX.:   22935. / DNK=   13.47933983 / DP= 0.00058772  / LOCAL 
CD: 51065050525 / RURAL

DNK MÍN.:   0.00079655 / DNH=0.02061856 / DP= 0.03863270  / LOCAL 
CD: 130270205

[Talk-br] Mapeamento hidrológico

[Sérgio V .]

Outra coisa tava me lembrando:
os rios onde dá mais problemas de cheias no Brasil são nas Bacias do Atlântico.
São 4 fatores que contribuem (em comparação com as demais bacias):
-rios mais estreitos,
-área de chuvas mais torrenciais, tempestades e ventos (proximidade com o mar),
-margens mais povoadas (urbanização intensa e sem planejamento),
-relevo mais abrupto e calhas de rios mais afuniladas (Serra do Mar).

IBGE - Bacias Hidrográficas do Brasil (2000):
https://www.google.com/url?q=http://mapas.ibge.gov.br/images/pdf/mapas/mappag99.pdf=U=0ahUKEwiP36HB95XWAhXhKcAKHSYNAzsQFggGMAE=internal-uds-cse=AFQjCNGrBZp-wo7wdgcnYAcsHqqgNhCzqQ

IBGE - População total segundo bacia hidrográfica (2000):
https://www.google.com/url?q=https://www.ibge.gov.br/home/estatistica/populacao/atlas_saneamento/pdfs/mappag100.pdf=U=0ahUKEwiP36HB95XWAhXhKcAKHSYNAzsQFggKMAM=internal-uds-cse=AFQjCNEE-ubvY9hgRcW-VL81mE5vbwEz_A


[Talk-br] Mapeamento hidrológico

Sérgio V. svolk2 em hotmail.com
Quarta Setembro 6 23:39:17 UTC 2017
Próxima mensagem: [Talk-br] Mapeamento hidrológico
Mensagens classificadas por: [ date ] [ thread ] [ subject ] [ author ]
Mais um motivo para mapear rios.

Imagino que o verão que chega vá ser extremamente chuvoso e de tempestades:
https://www.theguardian.com/world/2017/sep/06/twin-megastorms-irma-harvey-scientists-fear-new-normal

O mapeamento básico de rios ( waterways=* como eixos), pontes e correlatos, 
ainda é o mais importante.  É o mais simples, rápido, e mais útil como 
informação. Sobretudo necessário em regiões já normalmente críticas.

A precisão do riverbank (como área), serve mais para tornar bonito o mapa, como 
disse o Cássio em outro momento. Traz pouco ganho de informação. Além de ser 
uma informação secundária, gasta 10x mais tempo para cobrir a mesma área do que 
se for traçar eixos, que são muito mais importantes: para 2 nós com que se 
possa cobrir uma determinada extensão de eixo de rio com suficiente precisão, o 
mesmo trecho se for desenhado como área precisa de uns 20 nós.
Riverbank em escala meso-regional de estados (+/-acima de 1:1.000.000, ou zoom 
9 no OSM) nem aparece, se torna irrelevante. Só faz diferença para rios mega 
largos, com mais de 1km de largura. Mesmo assim não é fundamental para 
estimativas de de contribuição hídrica, pois informações importantes como 
largura, área da seção transversal, vazão, etc, podem bem ser aplicadas como 
média por trechos de eixos.

A base mais importante de tudo é o simples traçado de eixos, que tranquilamente 
pode ser feita remotamente (e é o que mais necessita). Os outros dados podem 
ser agregados posteriormente. Mesmo eventuais possíveis importações de rios a 
partir de bases de dados de órgãos públicos sempre necessitarão de muito ajuste 
manual, pois nenhuma se compara em resolução aos traçados manuais que já 
existem no OSM, por piores que sejam. Some-se a isto que importações são cada 
vez mais complicadas e menos viáveis, pelos conflitos que dá, uma vez que já 
existem muitas geometrias no OSM.

Na ordem de importância, o traçado manual de eixos é 10x mais importante do que 
riverbank, e é algo simples de fazer (e prazeiroso, na minha opinião).



- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs




- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Mapeamento hidrológico

[Sérgio V .]

Não sei.

Destas 2 que apontaste, são sugestões? Tens alguma ideia de preferência, prós e 
contras?


A princípio imagino que deveria poder ser mapeada do mesmo modo como é 
convencionalmente mapeada uma bacia no papel: rio principal, rios tributários, 
áreas, micro-bacias,...


Por enquanto só tenho a ideia de que seria bom que a bacia constasse de algum 
modo em algum tipo de relação com o seu waterway principal (mainstream). Tipo, 
"Rio Uruguai" /  "Bacia Hidrográfica do Rio Uruguai".


Atualmente funciona só pra relação de "Rios": 
https://wiki.openstreetmap.org/wiki/Relation:waterway

(Inicialmente penso que deveria ser propriamente uma relação de "bacia", não 
criar mais um tipo de relação paralela)


Relação "Rio Uruguai ": http://www.openstreetmap.org/relation/380835

Membros:

1) main_stream: trecho1,trecho2,trecho3,(do Rio Uruguay)...

2) side_stream : 1,2,3,(do Rio Uruguay)...

(side_stream não serve pra tributários, apenas para desvios e retornos: "a 
branch of main stream that returns to it".)


Tinha que ter algo que pudesse colocar ainda na mesma relação:


3) todos os tributários: ex. , desde o Rio Pelotas, Rio Canoas, até o Rio 
Quaraí, etc:

http://www.openstreetmap.org/way/40834616
Juntos, formando uma "rede", tipo network, ou sei lá.

Como existe a "Key:network", mas esta (infelizmente, atualmente) é só para 
"rotas terrestres", highway: https://wiki.openstreetmap.org/wiki/Key:network.

Por sinal, ao inventarem esta tag, deste modo, me parece que criaram um 
problema de conceito, como se "rede" fosse só de vias terrestres (mas o OSM não 
é só pra carros).

A rede que forma a reunião de todos os tributários + o Rio Uruguay, constitui a 
bacia.

Não entendo muito da relação de rede de Strahler, mas parece que poderia ser 
por aí, o esquema surgiu justamente na hidrologia para isso.


Assim, ainda teria que fazer parte da mesma relação:

4) a bacia mesma, ex. "Bacia Hidrográfica do Rio Uruguai": uma área, portanto 
(365.000 km²:  https://pt.wikipedia.org/wiki/Bacia_do_rio_Uruguai)

Os limites poderiam ser mapeados de modo semelhante a limites administrativos, 
podendo envolver trechos de "ridge" (divisor de águas), p.ex.


Tudo numa única relação. A relação, penso, deveria mesmo levar o nome de "bacia 
tal" (não se restringir a uma relação de waterways, o curso); não Relação "Rio 
Uruguai",  mas "Bacia do Rio Uruguai" (ou "Bacia Hidrográfica do Rio Uruguai").


Imagino que deveria ser mais ou menos assim, tal como é o mapeamento 
convencional em geografia, hidrologia...

https://en.wikipedia.org/wiki/Drainage_basin

https://en.wikipedia.org/wiki/Main_stem

https://en.wikipedia.org/wiki/Strahler_number#River_networks


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs



De: santamariense 
Enviado: quarta-feira, 30 de agosto de 2017 10:00
Para: talk-br@openstreetmap.org
Assunto: Re: [Talk-br] Mapeamento hidrológico

Qual a ideia de como mapear Bacias Hidrográficas? Criando relação e
adicionando os respectivos waterways? Ou adicionando tags do tipo
estánabacia="Bacia Hidrográfica do Aa" em cada waterway?

___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Mapeamento hidrológico

[Sérgio V .]

Levantamento de áreas críticas com uma base mais acertada, claro, seria ótimo.
O que tenho feito é simplesmente ir mapeando onde acho que falta mais 
(colocando a camada da SNIRH/ANA por cima do OSM), ou locais que sei que já 
ouvi falar que são importantes  ou críticos, ou onde dá na telha. Não tenho um 
tempo muito organizado, mapeio quando dá, mas a ideia é boa sem dúvida.


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs


- - - - -
santamariense imagens.sm em gmail.com
Quinta Setembro 7 12:40:56 UTC 2017
Mensagem anterior: [Talk-br] Mapeamento hidrológico
Mensagens classificadas por: [ date ] [ thread ] [ subject ] [ author ]
@smaprs,

A gente poderia montar maratonas de mapeamento neste sentido. Teria
alguma ideia? Fazer um levantamento de áreas criticas?

.


___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Mapeamento hidrológico

[Sérgio V .]

Mais um motivo para mapear rios.

Imagino que o verão que chega vá ser extremamente chuvoso e de tempestades:
https://www.theguardian.com/world/2017/sep/06/twin-megastorms-irma-harvey-scientists-fear-new-normal

O mapeamento básico de rios ( waterways=* como eixos), pontes e correlatos, 
ainda é o mais importante.  É o mais simples, rápido, e mais útil como 
informação. Sobretudo necessário em regiões já normalmente críticas.

A precisão do riverbank (como área), serve mais para tornar bonito o mapa, como 
disse o Cássio em outro momento. Traz pouco ganho de informação. Além de ser 
uma informação secundária, gasta 10x mais tempo para cobrir a mesma área do que 
se for traçar eixos, que são muito mais importantes: para 2 nós com que se 
possa cobrir uma determinada extensão de eixo de rio com suficiente precisão, o 
mesmo trecho se for desenhado como área precisa de uns 20 nós.
Riverbank em escala meso-regional de estados (+/-acima de 1:1.000.000, ou zoom 
9 no OSM) nem aparece, se torna irrelevante. Só faz diferença para rios mega 
largos, com mais de 1km de largura. Mesmo assim não é fundamental para 
estimativas de de contribuição hídrica, pois informações importantes como 
largura, área da seção transversal, vazão, etc, podem bem ser aplicadas como 
média por trechos de eixos.

A base mais importante de tudo é o simples traçado de eixos, que tranquilamente 
pode ser feita remotamente (e é o que mais necessita). Os outros dados podem 
ser agregados posteriormente. Mesmo eventuais possíveis importações de rios a 
partir de bases de dados de órgãos públicos sempre necessitarão de muito ajuste 
manual, pois nenhuma se compara em resolução aos traçados manuais que já 
existem no OSM, por piores que sejam. Some-se a isto que importações são cada 
vez mais complicadas e menos viáveis, pelos conflitos que dá, uma vez que já 
existem muitas geometrias no OSM.

Na ordem de importância, o traçado manual de eixos é 10x mais importante do que 
riverbank, e é algo simples de fazer (e prazeiroso, na minha opinião).



- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs



De: Cassio Eskelsen 
Enviado: quinta-feira, 31 de agosto de 2017 10:44
Para: OpenStreetMap no Brasil
Assunto: Re: [Talk-br] Mapeamento hidrológico

2. Sempre que for traçado um "waterway=river" deve-se traçar também uma área 
com tag "waterway=riverbank"?

Obrigatório não e a maioria não tem mapeado mas desejável é já que, fora rios 
retificados/canalizados, dificilmente a calha do rio será regular.

Cássio Rogério Eskelsen
3Geo

___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Como ser um nó de banco de dados do OSM?

[Sérgio V .]

Bom  dia Rodrigo,

parece muito interessante a proposta.


Não entendo muito da parte de informática,

mas talvez você possa encontrar mais informações sobre o que deseja nestes 
links sobre a base de dados do OSM:

https://wiki.openstreetmap.org/wiki/Category:OSM_API

https://wiki.openstreetmap.org/wiki/Databases_and_data_access_APIs

https://wiki.openstreetmap.org/wiki/Planet.osm

https://wiki.openstreetmap.org/wiki/Frameworks

Imagino que deve ter mais dados que outros possam lhe informar.
E que para ser um servidor oficial necessitaria algum contato com a 
"OpenStreetMap Foundation"

http://wiki.osmfoundation.org/wiki/Main_Page

https://wiki.openstreetmap.org/wiki/Open_Database_License


Seria importante você criar uma página na wiki em português para documentar sua 
proposta, para ficar registrado e a comunidade poder acompanhar:

https://wiki.openstreetmap.org/wiki/Main_Page


De minha parte, acho ótima proposta.


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs



De: Rodrigo M. Mariano 
Enviado: terça-feira, 26 de setembro de 2017 15:28
Para: talk-br@openstreetmap.org
Assunto: [Talk-br] Como ser um nó de banco de dados do OSM?


Olá a todos, boa tarde,



Eu tinha lido em algum lugar, sobre instituições poderem criar um nó de

banco de dados do OSM, mas não estou encontrando mais sobre isso.



Isto é realmente possível? Se sim, alguém poderia me passar, por favor,

as instruções de como podermos ser um nó de BD do OSM?



Nós aqui do INPE estamos pensando em criar um servidor que seja nó do OSM, que

terão os dados de um projeto nosso, por isso gostaria de avaliar a 
possibilidade.



Atenciosamente,

--


Rodrigo M. Mariano

Departamento de Tecnologia da Informação do Laboratório Associado de Computação 
e Matemática Aplicada - LAC
Instituto Nacional de Pesquisas Espaciais - INPE
Av. dos Astronautas, 1.758 - Jardim da Granja
CEP: 12227-010 - São José dos Campos/SP.
Tel.: (12) 3208-6544
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Mapeamento hidrológico

[Sérgio V .]

Alô Pessoal, só levantando umas ideias.

tenho pensado que como uma das questões atuais mais cruciais na urbanização é a 
questão hídrica/hidrológica,

seria legal ter como mapear bacias de corpos d'água:

-área de contribuição hídrica;

-relação de waterway com os  tributários e mainstream;

-zonas "comprovadamente" 'alagadas'  (wetland=* etc...) ou 'alagadiças' 
(+seasonal=yes).

Só tava pensando alto, se tiver mais gente com interesse na área, é coisa a 
mapear.

Será importante pro futuro próximo. Acho que muitos municípios não tem o menor 
plano hidrológico.

Ou se tem, não é coisa muito informada, ninguém conhece a hidrologia.


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Mapeamento hidrológico

[Sérgio V .]

Jóia pessoal, bom ver que a temática hídrica encontra interesse geral.


Vamos vendo como padronizar.

A ideia do Cassio de mapear micro-bacias é importante também, e encontra 
respaldo nestas propostas que o Nelson mostrou que vem sendo levantadas no OSM 
mundial recentemente.

Imagino que possa vir a ser uma taggeamento relativamente simples.

A área de cada micro-bacia deve cobrir  relacionar-se com cada curso d'água 
(calha / rincão) até seu entroncamento com os seguintes cursos na ordem do 
fluxo (de montante a jusante), e terminar justamente no ponto de entroncamento 
com outros, seguindo a topografia dos divisores de água (pontos mais elevados / 
espigão).


E a soma de todas as micro-bacias tem que ser necessariamente igual à área da 
bacia mais ampla na qual se inserem.

Semelhante às áreas das divisões administrativas de estados e seus municípios 
(admin_level=*), onde a área do conjunto é  exatamente igual à soma das áreas 
dos membros.


Tendo associados dados de contribuição hídrica (que podem ser externos ao OSM 
ou não), permitiria facilmente levantar a contribuição de cada um isoladamente 
e de todos os membros em conjunto, fazer prognósticos, etc.


Agregando-se a área de prédios e vias (cuja área pode ser calculada 
estimadamente), permite calcular a taxa de pavimentação /  impermeabilização, 
por exemplo, e o potencial de acúmulo de água superficial.


A tag seasonal (ou outra que venha a se mostrar necessária) pode conter dados 
de recorrência.


A base de tudo é sempre o mapeamento básico de eixos de cursos d'água, e das 
áreas de bacias, sendo que esta necessita ainda de um taggeamento próprio, e 
todas em relação de waterway (talvez seja necessário ver como agregar as bacias 
nestas relações de waterway para que sejam completas).

Tendo este mapeamento básico, é relativamente simples obter ou agregar outros 
dados e fazer análises.

Obrigado pelas contribuições, vamos tocando o mapeamento básico e acompanhando 
as discussões internacionais e aqui.


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs



De: Nelson A. de Oliveira 
Enviado: quarta-feira, 30 de agosto de 2017 08:20
Para: OpenStreetMap no Brasil
Assunto: Re: [Talk-br] Mapeamento hidrológico

Dá uma olhada nessas propostas (que são recentes e estão sendo
discutidas na tagging):

https://wiki.openstreetmap.org/wiki/Proposed_features/Waterways_classification
https://wiki.openstreetmap.org/wiki/Proposed_features/Rivers_Classification

___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] "Clientes" de usuários OSM que fornecem dados de fontes duvidosas

[Sérgio V .]

Pessoal, para divulgar a informação, e se ajudar a cuidar o mapeamento, tem uns 
casos problemáticos acontecendo:
vários casos de "Clientes" de usuários OSM que fornecem dados de fontes 
duvidosas
(como dados iguais aos do Google, Bing, Here, etc).

Quando perguntado ao(s) usuário(s) "qual é a fonte?",
em "todos" os caso abaixo a resposta é a mesma:
"foi um cliente que repassou a informação".

O caso mais antigo é de 19/05/2016. Mas continua até 03 dias atrás, 06/10/2017.

-

19/05/2016:
https://www.openstreetmap.org/changeset/39426366

"Clientes me repassar que o nome da rua estava incorreto"

Kewen
https://www.openstreetmap.org/user/Kewen
-

12/09/2017
https://www.openstreetmap.org/changeset/51968533

"foi de clientes meus que me forneceram o mapa"

Paulo André Jannke
https://www.openstreetmap.org/user/Paulo%20Andr%C3%A9%20Jannke
-

06/10/2017:
https://www.openstreetmap.org/changeset/52687236

"um mapa que um cliente me mandou por foto"

Gabriel iTer
https://www.openstreetmap.org/user/Gabriel%20iTer
-

Os 2 primeiros casos já foram revertidos pelo Data Working Group e em vias de 
Redact.
Mas a coisa continua no último.
Se alguém contatar o(s) usuário(s), pedir para mandar cópia dos tais mapas 
fornecidos pelos clientes.


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] QUESTÕES SOBRE ESTATÍSTICA DE NÓS OSM NO BRASIL

[Sérgio V .]

Pessoal, pergunta:

QUESTÕES SOBRE ESTATÍSTICA DE NÓS OSM NO BRASIL:

Créditos à grande ajuda do naoliv extraindo e contabilizando nós por setores, e 
dicas, ideias e tentativas de vários da comunidade e do grupo QGIS.

--
EXAMES DE QUANTIDADE DE NÓS OSM (NOS SETORES CENSITÁRIOS):

Sendo:
DNH = Densidade de Nós-OSM / Habitante
DNK = Densidade de Nós-OSM / Km2
DP  = Densidade Populacional (Demográfica: Hab. / Km2)
LOCAL CD = CD_GEOCODI (setor cf. IBGE)

AMOSTRAS DE VALORES MÁXIMOS E MÍNIMOS:
(Sendo: VALORES MAIS BAIXOS DIFERENTES DE ZERO)
--
DNH MÍN.:   0.00049628 / DNK=8.12799313 / DP= 16377.90616394  / LOCAL 
CD: 230550605000146 / URBANO: Bastiana
DNH MÁX.:   22935. / DNK=   13.47933983 / DP= 0.00058772  / LOCAL 
CD: 51065050525 / RURAL

DNK MÍN.:   0.00079655 / DNH=0.02061856 / DP= 0.03863270  / LOCAL 
CD: 13027020546 / RURAL
DNK MÁX.:   74086.39791390 / DNH=1.39514066 / DP= 53103.17430676  / LOCAL 
CD: 261160605180093 / URBANO: Santo Amaro
--
DP  MÍN.:   0.00054130 / DNH= 6041. / DNK=3.27019121  / LOCAL 
CD: 15036060575 / RURAL
DP  MÁX.: 7389598.88649880 / DNH=0. / DNK=0.  / LOCAL 
CD: 354780905000653 / URBANO: Cidade São Jorge
--
(Sendo que: DP=14406779.66101695 = ANOMALIA; REMOVIDO DA AMOSTRA : CD 
354780905000653)
--

PROCURO O(S) ÍNDICE(S) QUE MELHOR INDIQUE(M):
-ONDE "MAIS FALTAM" NÓS-OSM (relativamente);
-ONDE HÁ NÓS-OSM "EM EXCESSO" (relativamente);

ATUALMENTE ESTOU PENSANDO QUE O MELHOR ÍNDICE É O "DNH" ("Densidade de Nós-OSM 
/ Habitante");
cf. mapa que postei na comunidade no telegram.

QUE ACHAM?

OBRIGADO SE TIVEREM QUALQUER OPINIÃO SOBRE ISTO. O NEGÓCIO É TENTAR ENCONTRAR O 
MELHOR INDICADOR.
COLOCAREI MAIS MAPAS COM DADOS NA WIKI:
https://wiki.openstreetmap.org/wiki/Demografia_do_Brasil_como_auxiliar_no_OSM



- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Associação, Capítulo OSM, etc

[Sérgio V .]

Passando pra cá algumas observações sobre possibilidade de uma "associação OSM 
brasileira" que vem sendo discutida.

Uma associação OSM local (nacional) precisa ser obviamente expressão da própria 
comunidade OSM nacional, espontânea e diversa. E em última análise,  do próprio 
universo OSM, apenas que no contexto nacional.

É fundamental que nós -  a comunidade brasileira pensando em associar-se em uma 
entidade e representar localmente o OSM -  tenhamos o necessário conhecimento 
dos aspectos básicos que envolvem isto.
Como "capítulo OSM" e "associação OSM".

Do que entendo:

1) Um capítulo OSM é uma entidade local "representante formal" do "próprio OSM" 
e da "OSMF", no ambiente local:
"Capítulo local OSM" (nacional) é uma proposta de entidade legalmente 
estabelecida sem fins lucrativos, que pode atuar como representante oficial 
local da OSMF, no trato com instituições governamentais, corporações privadas e 
mídia em geral. Com relação contratual formal com a OSMF."

OSMF (OpenStreetMap Foundation):
É a entidade internacional que representa oficialmente o projeto OSM, detém 
todas as prerrogativas de licenças sobre o projeto OSM, detentora dos direitos 
sobre o nome OpenStreetMap e as marcas diretamente ligadas a este projeto.
Todo uso do nome OpenStreetMap, assim como toda associação local que se 
denomine OSM, deve referir sua licença em última análise à OSMF.

VER:
https://wiki.openstreetmap.org/wiki/Foundation/Local_Chapters (precisa que 
alguém traduza tb e colocar numa wiki-Pt)
http://osmfoundation.org)

Do que entendo, então, tem um capítulo formalizada de princípio a autorização 
para usar o nome OSM e representá-lo.
Ainda assim, a OSMF reserva-se o direito último sobre a marca e demais 
licenças, podendo sempre revogá-las se necessário.

Não existem ainda no mundo capítulos locais formalmente estabelecidos nestes 
moldes.
O que existe até o momento são capítulos propostos em entidades locais, 
reconhecidas pela OSMF.


2) Uma "associação local" pode ser representativa da "vasta e genérica 
comunidade OSM local" (nacional), isto é , representativa das pessoas.
Não necessariamente ser representante do OSM.
Não necessariamente de princípio tem o direito de conter ou usar o nome ou as 
marcas "OSM", ou ter um website com nome OSM, ou representar o OSM localmente 
junto aos demais setores da sociedade local.
Para usar o nome OSM e representá-lo, etc, depende de estar nos moldes 
previstos de uma entidade focada no OSM, e das licenças gerais do OSM.
Necessita para isto "permissão da OSMF", detentora da marca OSM.

(VER: https://wiki.openstreetmap.org/wiki/Trademark_Policy_Pt
sobretudo item 4 - Usos especiais que requerem permissão: do uso do nome e 
marcas OSM, domínio de internet, e captação de recursos)

- - -

Obviamente não é exigência ter ou participar de uma associação nacional:
assim como existe "a comunidade OSM mundial" (formada por todos nós), "e" 
existe a OSMF como entidade oficial do OSM.
Nem todos da vasta comunidade mundial OSM são membros da entidade OSMF.

De todo modo, ter uma "associação" nacional é base para ser "capítulo".
(Por exemplo, o capítulo local francês, cuja entidade legal é a "Association 
OpenStreetMap France".)

No meu entender, é portanto fundamental que uma proposta de associação nacional 
da comunidade OSM, e seu estatuto, tenham já de partida explícitos:
-foco central no OSM (não impede atividades compatíveis; impede as 
incompatíveis);
-ser voltado a ser um capítulo OSM, isto é, um representante oficial do OSM.

Sugestão: estudarmos bem as condições para uma associação local ser capítulo 
OSM. Contatar mais a OSMF para orientações neste sentido.

Depende de:
a comunidade de fato desejá-lo, estar suficientemente madura para tal 
empreitada (conciência de tudo o que envolve, envolvimento a fundo profundo com 
o OSM),
e se engajar (isto é, bastante gente).

Pensando de modo bem prático como me parece que é a realidade das comunidades 
locais OSM ao redor do mundo:

É mais viável se há bastante gente com envolvimento de um modo ou de outro mais 
"a fundo" com o OSM (é normal que nem todos tem sempre), das diversas áreas o 
universo OSM
(mapeamento, desenvolvimento, instrução, contatos, comunidade OSM - que é a 
base do OSM - etc) .

Do contrário, se o geral é ainda um envolvimento mais superficial, esporádico 
(não há nenhum mal nisso, é parte do processo de caminhada), fica bem menos 
viável.
Por causa justamente de todas coisas do universo OSM que envolve estarmos bem 
por dentro.
Isso é, ser representantes do OSM supõe um bom número de gente com uma boa dose 
de envolvimento e conhecimento do universo OSM, ou intenção de.

Pode ser natural se uma comunidade precisar desenvolver mais isso até formar 
uma associação ou capítulo OSM.
Por exemplo, creio que quase ninguém tinha conhecimento bem destas coisas de 
Capítulo etc (de todo modo não foram levantadas mais a fundo; obviamente eu 
incluído, fui ler mais a fundo agora).

- - -

Outro aspecto,
um capítulo 

[Talk-br] Nota copyright OpenStreetMap (@cuidando.vc)

[Sérgio V .]

Olá,

sou membro da comunidade OpenStreetMap Brasil,

(http://wiki.openstreetmap.org/wiki/WikiProject_Brazil)


Vemos com muita satisfação que seu site usa os dados do OpenStreetMap no mapa 
base exibido.


Pedimos apenas o seguinte:


Como estabelece o copyright do OpenStreetMap,

(https://www.openstreetmap.org/copyright/pt-BR

e

https://wiki.openstreetmap.org/wiki/Trademark_Policy_Pt

Ítem 2. Como usar as marcas OSM)


e se tratando de página web normal (não versão exclusivamente mobile)



os créditos devem constar por extenso no pé do mapa, da seguinte forma:

“© contribuidores do OpenStreetMap”


contendo link para a página:

https://www.openstreetmap.org/copyright/pt-BR



Aguardamos confirmação do recebimento desta comunicação ,
bem como destas necessárias adequações.

Obrigado, e estamos à disposição para quaisquer outras dúvidas,

nosso canais de contatos em:

https://wiki.openstreetmap.org/wiki/Pt:Contact



- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Fundar Associação OpenStreetMap Brasil

[Sérgio V .]

Acho que o foco da proposta presente, assim como da discussão na talk
(https://lists.openstreetmap.org/pipermail/talk/2018-February/080161.html)
não estão muito centrados em questão específica de governança, que é mais 
contingente. Também não me parece que seja tão geral uma preocupação 
internacional no OSM quanto a governança.
É importante ter claro a diferença entre finalidades do OSM, melhorias, 
organização, etc; e governança.
Esta última pode eventualmente ser no máximo um meio contingente para os fins 
do OSM.

Pessoalmente não me parece bom muito acento em questão de governança, como se 
essa fosse a preocupação fundamental. Seria tomar o meio como se fosse fim.
O fundamento do OSM, valores fundamentais em si, são a colaboratividade e a 
comunidade.
E claro, o crescimento do mapeamento e melhoria, cobertura, dos dados. Não 
existe uso de dados se não houverem dados.
Dados podem existir em si, mesmo sem uso (falando unicamente do ponto de vista 
físico); mas uso nunca pode existir sem dados.

O que vem sendo discutido no talk internacional são os pontos em que o OSM 
precisa melhorar, crescer, difundir, e sugestões de algumas formas de 
evetnualmente se organizar mais, como meios para implementar seus objetivos 
(isto é, da comunidade).
De modo geral, o OSM vem funcionando, se difundindo; comunidades vem se 
consolidando. Mas pode melhorar e avançar em muitos aspectos.

A proposta de, de alguma forma, se organizar (qualquer figura jurídica que 
atenda às necessidades) do que entendo pretende ser prática.  Um meio para 
alcançar os objetivos em propósitos bem práticos, como possuir ferramentas e 
serviços próprios no OSM-BR, divulgação, integração da comunidade. O resto são 
meios para fins.

Tendo em vista os fins do OSM, a princípio qualquer proposta que ajude a 
implementá-los, e por outro lado não esteja em contradição com o próprio 
espírito do OSM e não venha a dificultá-los, no meu ver é válida. A que seja 
mais fácil e simples.


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs



De: Peter Krauss 
Enviado: domingo, 25 de fevereiro de 2018 06:36
Para: OpenStreetMap no Brasil
Assunto: Re: [Talk-br] Fundar Associação OpenStreetMap Brasil

Oi gente, parece uma ótima iniciativa (!), que tal agendar reuniões temáticas?  
(por voz, teleconferência Appear.in, Hangouts, etc. na Web)
Temos anos de discussão e relativo consenso, acho que é o caso apenas de ir 
fechando cada tópico, começando pelas decisões mais simples e consensuais.

Obrigado SergioAJV e Santamariense por estarem apresentando a proposta na 
Wiki !

Quanto ao processo de discussão atual (fev/2018), seria interessante ter uma 
amostrinha na Wiki, mesmo que uma copia/cola sem formatação.
Seria uma "ata" do que aconteceu no Telegram... Lembrando que não são todos que 
podem instalar ou querem ter o Telegram no celular.

Quanto a uma vaquinha e montagem de infraestrutura-teste, ajuda a mostrar onde 
queremos chegar, acho que é viável ir tocando em paralelo,
visto que todo o resto pode demorar mais e requer discussões não-técnicas.  
Talvez desde já criar um "grupo da infraestrutura-BR" ajude
a ir modelando o patrimônio digital que se quer defender com o CNPJ.

PS: por coincidência eu havia passado recentemente por esse artigo,
 https://blog.emacsen.net/blog/2018/02/16/osm-is-in-trouble/
onde se destaca que a preocupação da comunidade OSM em formalizar a governança 
é geral, internacional.




2018-02-24 21:11 GMT-03:00 santamariense 
>:
Olá caros colegas,

Surgiu o assunto sobre criarmos um Tasking Manager brasileiro, e a
partir das discussões sobre a falta de um, sobressaiu também a
discussão sobre termos algo mais abrangente e concreto, como uma
Associação/Organização.

Sabemos que isso já vem sendo pensado há um bom tempo, e estamos
querendo pôr em prática, por diversos motivos e objetivos. Tudo está
sendo documentado em
https://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Associação

Ajude a preencher os seguintes tópicos. Sempre baseado no que já
estiver na wiki.

* Objetivos

* Lista de necessidades, possibilidades, meios e custos

* Propostas de organização interna

* Apoio financeiro

[em caso de pessoal física, se você tiver pré-interesse em ajudar
financeiramente, adicione seu nome (de usuário) na wiki, ou, peça para
adicionarem]

Sua participação é muito importante e fundamental

___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Doações para a futura associação, favor declarar

[Sérgio V .]

Acho bom tocar nesta questão, Peter.

Esta questão do domínio atualmente registrado como 
"http://www.openstreetmap.com.br; me parece precisaria ser regularizada.
Chegamos brevemente a abordar o assunto no telegram-associação 
(https://t.me/AssociacaoOsmBrasil).
O fato de necessitar regularizar a situação do domínio e o fato de haver uma 
associação OSM-BR ou não, são duas questões independentes.

O nome "openstreetmap" é uma marca registrada. Há normas para usar esta marca:

https://wiki.osmfoundation.org/wiki/Trademark_Policy#4._Special_uses_that_require_permission
4.1. Domain names:
"You need a trademark licence to register or use a domain name that contains an 
OSM mark."

O uso do nome da marca é condicionado a aprovação da OSMF 
(https://wiki.osmfoundation.org).

(É semelhante ao caso de se alguém resolvesse registrar um domínio chamado 
"NIKE_do_Brasil. com . br", porque somos simpatizantes da NIKE)

Não vi esta questão de criar este domínio tratada na comunidade OSM brasileira. 
Talvez não estivesse presente na época.
Atualmente o domínio está sob propriedade de "Telenav do Brasil Serv de Loc 
Ltda", com contato em nome do Thierry Jean
(https://registro.br/2/whois#lresp : openstreetmap.com.br).

Por melhor que possa ter sido a intenção de registrar estes domínio, não me 
parece nada adequado que permaneça em nome de empresa particular.
O nome "OSM...BR" deveria ficar sob uma entidade jurídica que represente a 
comunidade openstreetmap local.
A maior expressão do que seria uma tal entidade jurídica, seria um capítulo 
local.
E que também deve ser uma entidade "não lucrativa".
(Rules for local chapters:be non-profit. - 
https://wiki.openstreetmap.org/wiki/Foundation/Local_Chapters).
Não temos uma tal entidade, ou um capítulo.

Mas ainda assim, como uma empresa particular, por mais bem intencionada que 
seja, que "não é" uma entidade "não lucrativa", permanecerá de representante da 
comunidade OSM no Brasil em domínio de internet?
Só ela pode mexer, decidir o que vai publicado, etc, em tal página de internet.

Em último caso, em não havendo possibilidade de transferir o domínio para 
alguma entidade representativa do OSM no Brasil,
imaginaria como aceitável até que o registro fosse passado para propriedade da 
OSMFoundation,
que em última análise é a única legítima detentora irrevogável do direito de 
ser representante do nome OSM
(https://wiki.openstreetmap.org/wiki/Foundation).



- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs



De: Peter Krauss 
Enviado: sexta-feira, 10 de agosto de 2018 15:39
Para: OpenStreetMap no Brasil
Assunto: [Talk-br] Doações para a futura associação, favor declarar

Prezados colaboradores e colaboradoras empenhados na  futura Associação OSM 
Brasil,


Abrindo tópico aqui no Talk-BR para deixarmos registrado qualquer tipo de 
patrimônio ou hora-trabalho a ser contabilizado como doação para a Associação.

O dia que ela passar a existir (registro de ata de fundação no cartório) e/ou o 
dia que ela estiver operando com um CNPJ.

O mais importante por hora, antes da fundação, é registrar aqui publicamente o 
compromisso de transferência de direitos de propriedade...
Por exemplo o domínio OPENSTREETMAP.COM.BR ,
já que a ata de fundação ou mesmo o anexo do Estatuto precisarão citar esse 
tipo de patrimônio inicial.


Peter
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Projeto escolar de mapeamento da comunidade de Curupaiti Viseu, Pará

[Sérgio V .]

Bom dia Esau, ótima iniciativa, sempre penso que atividades em escolas são uma 
das maneiras mais importantes de difundir o OSM, ensinar novas habilidades a 
estudantes e agregar dados de conhecimento da população local.


Quanto às imagens, vi que a camada "DigitalGlobe Standard Imagery" parece ser a 
mais recente aí, é a única que aparece construções mais novas. Em geral tenho 
observado o mesmo no resto do Brasil.


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs



De: Esau Lopes 
Enviado: sábado, 31 de março de 2018 10:27
Para: OpenStreetMap no Brasil
Assunto: Re: [Talk-br] Projeto escolar de mapeamento da comunidade de Curupaiti 
Viseu, Pará

Obrigado por responder. Sim e essa região, mais nos últimos anos a região mudou 
mas a imagens do satélite ainda n acompanhou essas mudancas



Enviado do meu smartphone Samsung Galaxy.


 Mensagem original 
De : Gerald Weber 
Data:2018/03/31 09:35 (GMT-03:00)
Para: OpenStreetMap no Brasil 
Cc:
Assunto: Re: [Talk-br] Projeto escolar de mapeamento da comunidade de Curupaiti 
Viseu, Pará

distração minha, tava no subject da mensagem :P

é essa?
https://www.openstreetmap.org/?mlat=-1.4300=-46.4738#map=15/-1.4300/-46.4738

2018-03-31 8:17 GMT-03:00 Gerald Weber 
>:
Oi Esau

bem vindo ao projeto,

qual é a cidade/região?

abraço

Gerald

2018-03-30 18:18 GMT-03:00 Esau Lopes 
>:

Boa tarde amigos, sou professor de História de uma comunidade do interior do 
Pará que ainda não está devidamente mapeada, fiz um projeto com alguns 
professores para fazermos isso para que os alunos conheçam um pouco mais sobre 
a comunidade em seu espaço geográfico, por isso peço ajuda, pois a imagem que 
tivesse acesso e desatualizada e não apresenta mudanças recentes do lugar, quer 
puder ajudar estaria profundamente grato.
Abraço a todos


Enviado do meu smartphone Samsung Galaxy.

___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br







___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Projeto escolar de mapeamento da comunidade de Curupaiti Viseu, Pará

[Sérgio V .]

Que me lembre sim, acho que já abri geotiff no JOSM, baixando do 
glovis.usgs.gov ou worldview.earthdata.nasa.gov


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs



De: Marcos Fedato 
Enviado: segunda-feira, 2 de abril de 2018 17:39
Para: OpenStreetMap no Brasil; Talk-br@openstreetmap.org
Assunto: Re: [Talk-br] Projeto escolar de mapeamento da comunidade de Curupaiti 
Viseu, Pará

Tem o cbers que tem imagem pb com 5m de tamanho de pixel (gsd) no conjunto 
chines de senrores.

O grande problema é usar isso no osm. Para usar no iD vc precisaria subir um 
servidor de tiles (geoserver /arcgis server).

Ou teria que ter um software desktop como o qgis ou arcgis para visualizar a 
imagem e desenhar por cima.

Depois teria que submeter as alteracoes que no arcgis é meio chato usar a tool 
do osm dele.

Existe uma maneira mais pratica para quem nao é GISeiro utilizar imagens 
baixadas?

O JOSM aceita abrir um geotif?

Enviado do meu smartphone Samsung Galaxy.


 Mensagem original 
De: Smaran Rneu 
Data: 02/04/18 13:23 (GMT-03:00)
Para: Talk-br@openstreetmap.org
Assunto: [Talk-br] Projeto escolar de mapeamento da comunidade de Curupaiti 
Viseu, Pará

Quando precisarem de fotos atualizadas de satélite, procurem o projeto europeu 
Sentinel.
Eles têm fotos públicas diárias.
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Atalhos de teclado: para editor iD e JOSM

[Sérgio V .]

Bom dia pessoal,

para o editor iD, tem uma folha com atalhos de teclado em Português em:

https://wiki.openstreetmap.org/wiki/File:Atalhos-iD-pt-br.png

pode imprimir em papel A4.


Tem também uma folha para JOSM com atalhos,

dá pra imprimir (tb recortar e colar no teclado se desejar...):

https://wiki.openstreetmap.org/wiki/File:JOSM_Keyboard_shortcuts_cheat_sheet.png

https://wiki.openstreetmap.org/wiki/JOSM/Basic_editing


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Cedência dos dados de cartografia da IPPUC de Curitiba / Importação de numeração predial

[Sérgio V .]

Também concordo que está ok, o cedente finaliza com a confirmação, pra 
esclarecer qualquer dúvida, de que os dados são disponibilizados sob os termos 
da Open Database Licence. Parabéns a todos envolvidos!


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs


De: santamariense 
Enviado: sexta-feira, 26 de outubro de 2018 22:32
Para: talk-br
Assunto: [Talk-br] Cedência dos dados de cartografia da IPPUC de Curitiba / 
Importação de numeração predial

Olá pessoal,

Conseguiu-se autorização formal do Instituto de Pesquisa e
Planejamento Urbano de Curitiba quanto a cedência dos dados de
cartografia para o OSM disponibilizados em
http://ippuc.org.br/geodownloads/geo.htm e a declaração está
disponível em 
https://wiki.openstreetmap.org/wiki/File:Declara%C3%A7%C3%A3o_de_Ced%C3%AAncia_de_dados_IPPUC.pdf

Gostaria que analisassem a declaração e dessem um feedback, caso
alguém discorde que sim, está suficientemente claro que os dados podem
ser importados para o OSM.

A ideia principal, e para isso estou sendo incumbido, é importar a
numeração predial da cidade que está disponível em "Lotes -
(julho/2018)". Não é disponível o shapefile de prédios, mas sim dos
lotes. A proposta é transformar a área do lote em ponto no centroide
do seu respectivo lote, e realocar cada um dos pontos gerados para a
proximidade da rua onde o endereço está localizado, ou seja, dentro do
prédio, porém, mais próximo de onde provavelmente esteja a porta de
entrada dele.

Conforme as boas práticas, será mantido o histórico dos endereços já
mapeados no OSM, inclusive suas coordenadas, sem haver duplicação de
objetos na base de dados do OSM.

A documentação está sendo feita em
https://wiki.openstreetmap.org/wiki/Curitiba/Importa%C3%A7%C3%A3o_IPPUC

___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Cedência dos dados de cartografia da IPPUC de Curitiba / Importação de numeração predial

[Sérgio V .]

Bom dia santamariense,
acho que está tudo OK, dominas bem o processo.
Única observação:
acho que basta colocar source="Prefeitura de Curitiba"
no source do changeset, que já fica registrado na "Versão #1" de cada objeto 
"novo" que ele veio desta fonte;
sem precisar colocar individualmente em cada nó novo; isto também conforme me 
tinha sido orientado fazer na importação de prédios em PoA.
Exemplo:
Objeto: https://www.openstreetmap.org/way/427152434
Changeset: https://www.openstreetmap.org/changeset/40274949
Isto economiza dados que não precisariam ficar repetidos.
Os objetos com endereços eventualmente previamente existentes, por possuírem 
versão diferente, "#n+1", permanecerão com suas respectivas fontes distintas 
dos novos, que sempre pode ser filtrada e recuperada distintamente se 
necessário.
Avante, bom trabalho!


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs


De: santamariense 
Enviado: quinta-feira, 1 de novembro de 2018 21:48
Para: talk-br
Assunto: Re: [Talk-br] Cedência dos dados de cartografia da IPPUC de Curitiba / 
Importação de numeração predial

Então pessoal, dando sequência apresento um detalhamento de qual
arquivo será usado, quais campos ("tags") ele tem, e quais desses
campos parecem ser úteis. O detalhamento está documentado em
https://wiki.openstreetmap.org/w/index.php?title=Curitiba/Importa%C3%A7%C3%A3o_IPPUC=1688307

Caso alguém tenha alguma sugestão de mudança de metodologia apresente
o mais breve possível, para que a comunidade possa analisar e de comum
acordo implementar.

[]'s

___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Road network improvements in Brazil

[Sérgio V .]

Hi,
If you want to find unmapped roads, you might look at this map, made with data 
from density of nodes and demographic density.

PNG image map:
https://www.dropbox.com/s/d8zld6cgwm6i5yg/JOSM-Backgr-DensNosOSMporHAB-R01.zip?dl=0

KML map of less mapped districts:
https://www.dropbox.com/s/ms70wy6iwaaexkq/DNH-zero-BR.zip?dl=0

Wiki (need Google translation from portuguese):
https://wiki.openstreetmap.org/wiki/Demografia_do_Brasil_como_auxiliar_no_OSM

This map of densities may be a bit outdated since 2017. But everytime I use 
this map I still found unmapped roads to map

- - - - - - - - - - - - - - - -
Sérgio - http://www.openstreetmap.org/user/smaprs

De: Andrew Wiseman 
Enviado: sexta-feira, 9 de novembro de 2018 14:37:39
Para: talk-br@openstreetmap.org
Assunto: [Talk-br] Road network improvements in Brazil

Hello OSM Brazil,

My name is Andrew Wiseman, I work for Apple on the Maps team. My team is 
interested in doing some work on the road network in Brazil on OpenStreetMap, 
things like adding missing roads, making sure roads connect properly, fixing 
incorrect alignments with GPS traces, ensuring road classifications are 
consistent, and other similar issues.

Are there places you know of that need improvement or types of problems you see 
frequently? Also I saw these guidelines about road classifications, are they 
the most recent classifications used by the community, or are there any others 
we should be aware of? https://wiki.openstreetmap.org/wiki/Pt:How_to_map_a

We have a Github page here about the project: 
https://github.com/osmlab/appledata/issues/126

Please let me know if you have any suggestions or feedback.

Thank you,
Andrew
Apple, Inc.


Andrew Wiseman |  Maps | 
andrew_wise...@apple.com
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Cedência dos dados de cartografia da IPPUC de Curitiba / Importação de numeração predial

[Sérgio V .]

A princípio não acho bom mapear lotes, sobretudo urbanos.
O que recebe uma numeração da prefeitura é a construção, pelo menos em PoA, 
onde a numeração depende de projeto de edificação para aprovação.
Pode haver mais de um número por lote, conforme quantos tipos de 
estabelecimento com matrículas individualizadas houver no lote: residencias, 
comerciais...
O santamariense registrou na wiki que o centróide é pra gerar o nó para a 
numeração, e que este nó será movido para próximo da face do terreno junto ao 
logradouro, que é a "testada".
E pelo mesmo motivo da numeração ser dada ao prédio correspondendo à distância 
em metros medida aproximadamente na intersecção da projeção na testada até o 
início da rua, indica que o ponto de medição não é pelo centro do prédio 
(centróide), mas pelo centro da projeção na testada.
Se colocar numeração no polígono de prédio ou lote, acabaria sendo sempre 
considerado pelo centróide. Aí dá problema em polígonos, lotes e/ou prédios, 
que atravessam quadras e tem frente para 2 ou mais logradouros.
Seria conveniente colocar numeração sempre em um nó, que marca o local 
aproximado do centro da testada no respectivo logradouro, não em polígono de 
prédio ou lote. Assim como a prefeitura dá o número e proprietário coloca a 
tabuleta num lugar +/- próximo da entrada, dificilmente exatamente na medida 
exata.


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs


De: Fernando Trebien 
Enviado: segunda-feira, 5 de novembro de 2018 21:31
Para: OSM talk-br
Assunto: Re: [Talk-br] Cedência dos dados de cartografia da IPPUC de Curitiba / 
Importação de numeração predial

On Mon, Nov 5, 2018 at 8:36 PM santamariense  wrote:
> > 2. Atribuir o endereço à entrada do lote, do lado de dentro. É feito
> > assim em Berlim, Amsterdã, Paris, Madri e partes de Londres e Nova
> > Iorque.
>
> É essa que está sendo proposta.

Por ora eu acho ok. Mas gostaria de desdobrar esse ponto para o longo
prazo, não só em Curitiba mas também em outras cidades.

O centróide do lote é diferente da entrada. Colocar o endereço na
entrada reduz o número de erros de projeção do endereço na via (mais
comuns nas esquinas), que é a primeira etapa do roteamento. Ainda
sobram casos particulares, mas menos.

A minha questão, então, é se seria preferível no OSM, no longo prazo,
mover os pontos do centróide para a entrada, ou até mesmo eliminar o
ponto do centróide e transferir o endereço para o edifício ou lote
quando estiver mapeado.

--
Fernando Trebien

___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] OSM Foundation e comunidade latina

[Sérgio V .]

Vocês sabem se, e onde, há uma lista dos concorrentes/candidatos ao OSMF board 
deste ano?
Outros anos tinha uma wiki com os nomes e suas propostas, se não me  engano.
Obrigado.


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs


De: Wille 
Enviado: terça-feira, 6 de novembro de 2018 11:27
Para: OSM talk-br
Assunto: [Talk-br] OSM Foundation e comunidade latina


A próxima eleição para o board da OSM Foundation será em 15 de Dezembro. Quem 
deseja participar da votação, deve se registrar como membro da Fundação até o 
dia 15 de novembro: https://join.osmfoundation.org/


Consegui articular uma conversa entre membros do atual board da OSM Foundation 
e a comunidade OSM Latam. O chat será realizado na próxima terça, às 13:00, de 
Brasília, no canal telegram OpenStreetMap Latam - https://t.me/OSMLatam . Será 
uma oportunidade de expressarmos nossa opinião em relação ao OpenStreetMap e à 
OSM Foundation e conhecer melhor a visão do atual board.

--
Wille Marcel
http://wille.blog.br/
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Autorização de uso de camadas de informações do Exército Brasileiro

[Sérgio V .]

Ótima notícia!! Valeu Érico!
Agradecimento especial à gentileza do Exército Brasileiro, em especial à 
Diretoria de Serviço Geográfico, em responder e esclarecer nossas necessidades 
de informações.

De minha parte, entendo que o ponto principal que a comunicação do Exército 
está dizendo é o seguinte:

O OSM está formalmente autorizado a usar como imagem de background as cartas 
topográficas matriciais do BDGEx e mapear sobre elas.
Eventualmente a autorização de uso pode ser revogada da parte do Exército por 
quaisquer razões (nesse caso, não seria mais permitido visualizar e mapear 
sobre os referidos materiais.)
No entanto, o que já tiver sido mapeado no OSM sobre estes materiais fica para 
sempre garantido para o OSM sob CCO, como afirmado da parte do Exército.

Por mim, entendo que:
-podemos adicionar à wiki a documentação;
-e o link para uso das imagens das cartas nos editores.

Obrigado Nelson.


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs


De: Nelson A. de Oliveira 
Enviado: terça-feira, 2 de outubro de 2018 19:53
Para: OSM talk-br
Assunto: [Talk-br] Autorização de uso de camadas de informações do Exército 
Brasileiro

O Erico conseguiu autorização do Exército Brasileiro para uso de
alguns serviços disponíveis em
http://www.geoportal.eb.mil.br/portal/bdgex-1/servicos-ogc

Basicamente foi concedido o uso dessas camadas sob CC0 (compatível com
a ODbL https://wiki.openstreetmap.org/wiki/Import/ODbL_Compatibility)

Partes importantes abaixo, documento completo em anexo.
Alguém tem alguma dúvida ou algo a acrescentar com relação a isso ou
podemos adicionar essa documentação na wiki do OSM
(https://wiki.openstreetmap.org/wiki/Contributors#Countrywide + link
pro PDF) e adicionar as camadas aos editores?

=
Protocolo: 60502001705201852
Data de Abertura: 13/09/2018 09:53
Orgão Superior: Destinatário MD – Ministério da Defesa
Orgão Vinculado: Destinatário CEX – Comando do Exército
Situação: Respondido
Status da Situação: Acesso Concedido (Resposta solicitada inserida no e-SIC)
Resumo: Autorização para uso de tiles da DSG

(...)
Levando em consideração o exposto até o momento, e que os
“tiles” do BDGEx ou as imagens geradas a cada requisição WMS
não possuem, ainda, um licenciamento próprio, parece razoável
considerar que seu uso pode ser regido pela licença CC0
(https://creativecommons.org/publicdomain/zero/1.0/legalcode), a
qual é compatível com a licença CC-BY-SA adotada no OSM.

Entretanto, convém salientar que esse licenciamento pode ser
alterado a qualquer momento, e que a comunidade OSM será
avisada, caso ocorra alguma alteração.
(...)
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Cedência dos dados de cartografia da IPPUC de Curitiba / Importação de numeração predial

[Sérgio V .]

Ótimo exercício de geometria aplicada.
Valeria depois, quando tiver tempo, registrar uma breve seção da mesma wiki (ou 
sub-página) com prints de tela exemplificando este processo geométrico.
Imagino que terão muitos casos semelhantes num futuro breve, seria um bom 
tutorial.
Belo trabalho!


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs


De: santamariense 
Enviado: sábado, 1 de dezembro de 2018 03:17
Para: talk-br
Assunto: Re: [Talk-br] Cedência dos dados de cartografia da IPPUC de Curitiba / 
Importação de numeração predial

Muitos dias de processamentos e erros devido a quantidade de dados
depois, consegui automatizar o alinhamento dos centroides junto a
frente dos lotes. Para tal tive que dividir em várias partes o arquivo
dos lotes para que o QGIS pudesse dar vencimento, e depois unir
novamente os resultados parciais. Enfim, vamos aos passos:

1 - Dar dissolve no arquivo dos lotes. Lotes dissolvidos nos dá as quadras;
2 - Dar buffer de -5m (menos cinco metros) no arquivo das quadras;
3 - Fazer a diferença Lotes menos Quadras. Isso nos dá como resultado
polígonos da frente dos lotes. Polígonos que mantém a medida original
da testada, porém, agora com apenas 5 metros de comprimento em direção
ao fundo dos lotes;
4 - Feito isso é só gerar os centroides, que agora ficam alinhados ao
eixo da rua, numa distância de 2,5m adentro do terreno *.

* Alguns cuidados e considerações precisam ser tomados:
a - Ao fazer a diferença, alguns lotes podem ficar totalmente sem
geometria (0,2% do total). Para saber quais ficaram sem geometrias, é
calculada a área deles. Lotes sem geometria nos dá área nula. Para
contornar esse problema, abre-se o arquivo de lotes originais e se faz
um join de tabelas com a tabela dos lotes cortados. Então, na tabela
de atributos é selecionadas todas as geometrias com área nula. A
seleção é salva como nova camada de shapefile. Do arquivo de lotes
cortados, é excluída as geometrias de área nula e adicionada suas
geometrias originais (lotes inteiros) - esses não tem jeito, é
necessário o alinhamento manual.
b - Todos os lotes de esquina cortados tendem a ficar em formato de
"L", fazendo com que seja quase sempre necessário fazer o
realinhamento manual.
c - Muitos lotes cortados ficam com várias partes descontinuadas (~5%
do total), de qualquer maneira, é gerado apenas um centroide que fica
a meio caminho entre as partes, mais ou menos, ou exatamente, no
centroide do lote original. Esses também não tem jeito, se faz
necessário o alinhamento manual.

É importante destacar que apesar de muitos pontos já saírem na sua
posição final, ainda assim é preciso que todos sejam verificados
porque podem não existir mais (percebi muitos lotes que agora são
ruas, por exemplo), ou mesmo porque exista já o endereço mapeado, ou
ainda que precisa ser movido o endereço do ponto para a área
(building, ou outra), caso ela já estiver sido mapeada.

Por fim, optei por dividir os pontos gerados por bairro, de modo que
para fins de importação no OSM, fique prático e fácil manipular
pequenos arquivos, principalmente neste caso que não só insere novos
dados no OSM, como também modifica existentes, e arquivos grandes
deixam mais tempo exposto a conflito de edições durante a importação.

Assim que começar a importação (de fato) compartilho aqui os
problemas, soluções e/ou dúvidas que possam surgir. Nova conta
exclusiva para importação foi criada. Nessa conta farei esta
importação e outras que possam vir futuramente, em Curitiba ou em
qualquer outro lugar. Quanto ao nome das changesets, o nome das
changesets será " #Import Curitiba: Endereços - IPPUC. Bairro
nomeDObairro " e a source da chageset será "Prefeitura de
Curitiba:IPPUC:Lotes_2018-07", lembrando que a source apenas será
posta na changeset, não em todos os endereços importados. Nos
endereços importados só terá as tags addr:street e addr:housenumber.

___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Vetorização de matas no OSM com Sentinel-2

[Sérgio V .]

Prezados(as),

venho aqui expor e submeter à apreciação da comunidade OSM no Brasil uma 
proposta de método de mapeamento de matas para o OSM (natural=wood e 
landuse=forest) , baseado em vetorização semi-automatizada de imagens do 
satélite Sentinel-2, para o que peço autorização para uso em mapeamento no OSM 
no Brasil.

A proposta detalhada passo-a-passo encontra-se documentada na página wiki 
"Vetorização de matas com Sentinel-2":
https://wiki.openstreetmap.org/wiki/Vetoriza%C3%A7%C3%A3o_de_matas_com_Sentinel-2

Os testes já realizados (sem upload) encontram-se na página:
https://wiki.openstreetmap.org/wiki/User:SergioAJV/Sentinel-2_vectorizing_tests

O objetivo desta proposta, resumidamente, é contribuir com uma ferramenta para 
o mapeamento no OSM de grandes coberturas de matas.

A justificativa consiste, basicamente, em que o método possibilita mapear 
grandes áreas de mata, de municípios ou regiões de interesse, adequadamente, 
mais rapidamente, e com melhor precisão geométrica do que o que comumente pode 
ser encontrado ou realizado em mapeamento exclusivamente manual e com as 
imagens disponíveis nem sempre atualizadas e que, de todo modo, não permitem 
escolha, como de épocas do ano mais propícias à identificação de vegetação.

O método se destina a matas. Não se destina ao mapeamento de objetos pequenos. 
A resolução das imagens disponíveis é de 10 e 20m/pixel, e as geometrias 
resultantes da ordem de ~1nó/10m em curvas. Ainda assim maior do que se pode 
encontrar muitas vezes em mapeamento manual de "landcover", como matas. O 
processo pode gerar cerca de 100 a 150 nós por km2, em áreas com muita 
variedade de tipos de matas. O que significa cerca de 1.000.000 de nós a partir 
de 1 imagem Sentinel de 100x100km. Menos que isso em áreas mais homogêneas.

O método exige o controle ativo dos parâmetros de distinção de classes de 
vegetação e demais elementos geográficos a partir das imagens de satélite, em 
todo o andamento do processo, até o resultado final na geração de vetores .osm.
Exige certo tempo na aplicação dos passos, e sobretudo atenção, como na medição 
de valores de pixels para as classes de objetos, escolha de objetos para 
amostragem, bem como na verificação do resultado final. Não é um processo 
imediato. Ainda assim, permite grande ganho de tempo no mapeamento.

Mais detalhes podem ser encontrados nas citadas páginas de documentação.

Agradeço sua atenção e apreciação, acolhendo questões ou comentários no que 
desejarem e/ou julgarem necessário.



- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Vetorização de matas no OSM com Sentinel-2

[Sérgio V .]

Bom dia Paulo, pessoal.

Fiz upscaling pra ver crossplot/scatterplot, com 549x549 px =   301.401 pixels 
(pontos);
 - Imagem original tava com 10.980x10.980 px = 120.560.400 pixels : 120.560.400 
pontos, inviável, processador e RAM assobiaram.
E abri os histogramas.

Obtive os seguintes gráficos (em jpg no Imgur):

Histograma B11 : https://i.imgur.com/jsvnFjj.jpg
Histograma NDVI : https://i.imgur.com/FrEZGOO.jpg
Histograma (1-NDVI)*4000 : https://i.imgur.com/TUPi3Tl.jpg

Scatterplot B11 x NDVI : https://i.imgur.com/z4yPjtY.jpg
Scatterplot B11 x (1-NDVI)*4000 : https://i.imgur.com/j4WuO7C.jpg
(c/ reescale para abranger próximo da área plotada.)

Anomalias de pixels acho que não tem muito.
Nuvem já remove na escolha de imagem, por cloud=0. E verifica com B10 se ainda 
tem alguma mínima.

A questão acho que centraria em encontrar uma referência de base universal 
(imagem original básica; ou algoritmo) para wood e forest, ou wood sozinho:
B11 sozinho ?
NDVI; ou EVI2; sozinhoS ?
Fórmula empírica (podem chamar gambiarra tb) tipo B11 * (1-NDVI)*4000 ?
Algum algoritmo mais pato (depois ainda vou estudar os algoritmos de 
classificação multivariados que vc indicou).
De todo modo, a base da classificação, e possibilidade de mapeamento, parte de 
imagem original e/ou índices mais aptos.

O objetivo a princípio é prático, para o OSM, não tanto científico: distinguir 
2 classes, wood e forest, com precisão adequada, bastaria.

NDVI e EVI2 exibem imagens muito parecidas; EVI2 indicam que é melhor pra mata 
densa.
Mas comecei usando o NDVI, só pra eliminar o que não é vegetação; não pra fazer 
classe de vegetação, pois não encontrei valores limite aptos a separar classes.

O que o o (1-NDVI) faz é tornar NDVI tudo número positivo, pra poder depois 
multiplicar(potencializar) o B11.

Vi que O NDVI possibilita destacar tudo o que não é vegetação, e remover 
objetos que poderiam ainda ficar misturado no B11; por ter o foco em mapear 
matas.
O B11 foi que observei de imediato que mais destaca "wood" e "forest" entre si. 
Mas wood é o que mais tem no Brasil. Forest, menos.

Aí no B11, filtrado pelo x (1-NDVI)*4000, era só ver o range, só entre as 2, 
porque o resto já fica separado pelo NDVI.
(se focar só nas 2, wood e forest; no resto do Brasil quase só wood, natural; 
mas se quiser todo o resto de landcover, mais classes, aí fica mais elementos a 
considerar; também dá, mas de preferência não abordaria isso agora):
-forest (vegetaçao mais nova; mais escura; valores mais baixos)
-wood (vegetação mais velha, mais clara, valores mais altos)
E as anomalias (amplificação de anomalias), filtrando manual com "sieve" e 
"neighbors".
O fato é que o resultado, filtrando, mesmo perdendo informação, aproximou da 
real grupo de wood e forest no terreno.

Este que seria o objetivo: pegar wood e forest, quando há as 2 co-existindo; 
separadas entre si, e de todo o resto que não é.
Quando "não" tem as 2 co-existindo numa região (florestas plantadas é mais na 
região Sul-Sudeste do BR), pegar só mata nativa (wood).
Alcançando isto, tá feito para o objetivo inicial e prático!
Claro, ainda se poderia ir tentando encontrar uma formulação que possa ser mais 
abrangente, pegar mais objetos de landcover.

Bom, a ver o que acham.
Em investigação. Parcialmente já estou satisfeito com os resultados. O modo 
ainda pode ser meio empírico, ou não muito científico, artístico digamos, de ir 
lapidando até fechar os polígonos de classes iguais, mas funcionou. Claro, se 
pudermos facilitar e universalizar, melhor.

Obrigado pelos aportes já dados!



- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs



De: Paulo Carvalho 
Enviado: quinta-feira, 13 de setembro de 2018 14:05
Para: OSM talk-br
Assunto: Re: [Talk-br] Vetorização de matas no OSM com Sentinel-2



Em qui, 13 de set de 2018 às 13:08, Sérgio V. 
mailto:svo...@hotmail.com>> escreveu:

Bom dia pessoal, Paulo e Gerald, obrigado pelos aportes!
Tenho muito interesse em que se possa aprimorar o processo, e/ou facilitar, 
onde possível e necessário.
-Gerald, baixei o artigo, vou olhar mais a fundo, exigirá mais tempo.
-Paulo, infelizmente não apareceu a imagem exemplo que vc enviou, o talk-list 
não exibe imagem, só link. Se puder mandar em link (tipo 
imgur.com<http://imgur.com>:  https://i.imgur.com/n3LV9qJ.jpg), seria ótimo.

Sem figuras?  Precisamos sair da década de 1990!  Aqui, é a figura 11 desse 
artigo: 
https://www.researchgate.net/publication/249553119_Optimizing_4D_fluid_imaging


Estou tomando muito em consideração as suas colocações técnicas.

Claro, quando cruzei B11+((1-NDVI)*4000), o objetivo foi arrastar pra fora tudo 
que não é mata, na Mata Altlâtica.Serviu ali.

Ok.

Não serviu nos outros biomas. Foquei só em forest e wood. Que já me pareceu bem 
identificável pelo B11, só que no B11 mistura perto de valores de água, e é 
mais afetado por sombra. Por is

Re: [Talk-br] Vetorização de matas no OSM com Sentinel-2

[Sérgio V .]

Ok, ainda vou ver como fazer pra "definir a marca do crossplot para um único 
pixel"


A coisa que me intriga ainda é que estava reexaminando as imagens e 
histogramas, nos pontos onde há certeza das 2 classes, wood e forest, que pode 
ser confirmada na alta resolução do Bing.

E os histogramas me parecem ainda indicar que apontam para a confirmação da 
formulação empírica / gambiarra B11 x ((1-NDVI)*4000), nos valores de classes e 
diferenciação de:

1)wood (mais velha, pouco menos úmida, menos ativa em clorofila)

2)forest  (mais jovem, mais úmida, mais ativa em clorofila)

3)o que não é nenhum dos 2 e pode ser retirado de vetorização (para "null").


Imagens junto com histogramas correspondentes do caso B11 x ((1-NDVI)*4000):

https://i.imgur.com/4uKNw1r.jpg


É a mesma área que peguei como exemplo desde o início, porque tem todos os 
tipos que poderiam interferir, e dá pra examinar se o resultado distingue bem 
wood e forest do resto:

wood; forest; river; pond; campos ralos; farmland; estradas; ...


Nos histogramas, no NDVI, as forest ocupam sempre os níveis mais altos, de 
vegetação crescendo ativamente; como próprio do NDVI; enquanto as wood variam 
mais no espectro: há área velhas e algumas em crescimento. Então há mistura das 
2 classes.

Já no B11 se destacam bem claramente entre si: uma não invade a margem de 
valores da outra.


Se não fosse a água no B11 (~50a300) se misturar com forest(~150a1200), daria 
pra usar só B11.


-No Cerrado, por exemplo, bastou usar só B11, não tem mata jovem/forest, nem 
mais úmida, deu pra usar só B11:

água no B11 (~50a600) ;  wood(~1000a1300).

É que também os tipos são de vegetação do Cerrado são diferentes, matas mais 
secas, mais castigadas, do que as matas mais úmidas da Mata Atlântica. Acho 
sempre vão apresentar valores um tanto diferentes tendendo pro mais seco.

https://wiki.openstreetmap.org/wiki/User:SergioAJV/Sentinel-2_vectorizing_tests#Cerrado_.28vetorizado_e_100.25_validado_para_OSM.29


-Já na Amazônia, úmida mas também com áreas de mata velha, a ponderação teve 
que ser não x4000, mas x500, para B11 + ((1- NDVI ) * 500 ):

https://wiki.openstreetmap.org/wiki/User:SergioAJV/Sentinel-2_vectorizing_tests#Amaz.C3.B4nia_.28vetorizado_e_100.25_validado_para_OSM.29


Claro, se tivesse um índice ou fórmula única pra usar em todos biomas 
igualmente, seria melhor sem dúvida.

Não sei se é possível.


No scatterplot ainda vou ver como identificar os grupos ali dentro da mancha.

Ainda vou ver o que vc indicou mais.

Obrigado!



- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs



De: Paulo Carvalho 
Enviado: sexta-feira, 14 de setembro de 2018 13:45
Para: OSM talk-br
Assunto: Re: [Talk-br] Vetorização de matas no OSM com Sentinel-2

Oi, Sérgio, vamos lá...

Em sex, 14 de set de 2018 às 12:25, Sérgio V. 
mailto:svo...@hotmail.com>> escreveu:

Bom dia Paulo, pessoal.

Fiz upscaling pra ver crossplot/scatterplot, com 549x549 px =   301.401 pixels 
(pontos);
 - Imagem original tava com 10.980x10.980 px = 120.560.400 pixels : 120.560.400 
pontos, inviável, processador e RAM assobiaram.

Perfeito. Não se faz análise exploratória dos dados com tantos pontos. 120M de 
amostras é impossível mesmo.  E mesmo se fosse viável, daria para ver pouco.

E abri os histogramas.

Obtive os seguintes gráficos (em jpg no Imgur):

Histograma B11 : https://i.imgur.com/jsvnFjj.jpg

Só B11 parece dizer que há duas classes (as duas modas em 1200 e 2000 
aproximadamente).  Não obstante um tanto misturadas.  Mas outra variável pode 
ajudar a desempatar.

Histograma NDVI : https://i.imgur.com/FrEZGOO.jpg
NDVI parece dizer que há três classes (as modas em 0,2; 0,6 e 0,7).  A classe 
em centrada em 0,2 parece bem separada.

Histograma (1-NDVI)*4000 : https://i.imgur.com/TUPi3Tl.jpg

Não percas tempo com isso.  Apenas mudou a escala.  Ela continuia informando a 
mesma coisa: que parece haver três classes.


Scatterplot B11 x NDVI : https://i.imgur.com/z4yPjtY.jpg
Scatterplot B11 x (1-NDVI)*4000 : https://i.imgur.com/j4WuO7C.jpg

Parece interessante, porém só aparece uma mancha negra.  Seria importante 
vermos onde os pontos estão concentrados.  Pontos concentrados são indícios de 
que há uma classe ali.  Há como definir a marca do crossplot para um único 
pixel?  Se não for possível, tenta reduzir a quantidade de amostras de ~100k 
para ~5k.

abcs,

PC

(c/ reescale para abranger próximo da área plotada.)

Anomalias de pixels acho que não tem muito.
Nuvem já remove na escolha de imagem, por cloud=0. E verifica com B10 se ainda 
tem alguma mínima.

A questão acho que centraria em encontrar uma referência de base universal 
(imagem original básica; ou algoritmo) para wood e forest, ou wood sozinho:
B11 sozinho ?
NDVI; ou EVI2; sozinhoS ?
Fórmula empírica (podem chamar gambiarra tb) tipo B11 * (1-NDVI)*4000 ?
Algum algoritmo mais pato (depois ainda vou estudar os algoritmos de 
classificação mu

Re: [Talk-br] Vetorização de matas no OSM com Sentinel-2

[Sérgio V .]

Valeu, vou pesquisar.

Tamo chegando lá.


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs



De: Paulo Carvalho 
Enviado: sábado, 15 de setembro de 2018 19:53
Para: OSM talk-br
Assunto: Re: [Talk-br] Vetorização de matas no OSM com Sentinel-2

MDS (multi dimensional scaling) também ajuda na análise multidimensional.  Veja 
se o QGis tem MDS.

Em sáb, 15 de set de 2018 às 19:51, Paulo Carvalho 
mailto:paulo.r.m.carva...@gmail.com>> escreveu:
Oi, Sérgio, o caminho é esse mesmo.  Mas estás usando três variáveis: B11, NDVI 
e EVI2.  Em rigor seria necessário um crossplot 3D, mas aí a análise visual 
começa a complicar.  Nesse ponto eu usaria um dendrograma para analisar as 
classes.  O QGis tem dendrograma?

Em sáb, 15 de set de 2018 às 12:29, Sérgio V. 
mailto:svo...@hotmail.com>> escreveu:

Ok, agora entendi esse negócio de manter as variáveis disponíveis sem fundir em 
uma. Valeu!
-O NDVI distingue bem vegetal do que não é, e as classes de vegetal em 
diferentes graus de clorofila nas folhas, isto é crescimento, atividade 
vegetal. Mas nas matas densas tem mata nativa + mata plantada (pinus 
principalmente no RS). Mata plantada tem sempre atividade mais alta e valores 
mais altos de NDVI. Mata nativa já mistura: tem áreas e indivíduos com ambos 
estados, em crescimento e em estagnação/maturidade, mas tende a menor atividade 
de crescimento.

Assim NDVI não distingue estas 2 dentro da mata ou em contato de bordas. Mas em 
imagem hi-res do Bing já é fácil distinguir uma da outra. Existe esta distinção 
de área de mata nativa separada de área de mata plantada.

-O B11 distingue muito bem uma da outra, aproximadamente por volta do valor 
1000: ~200 a 1000 (mais escuro) mata planta; ~1000 a 1600 (mais claro) mata 
nativa. Porém não distingue bem água/rio/sombra que fica entre ~0 a 300. Afeta 
um tanto pelas sombras em encostas, onde baixa o valor.

Do que entendi, assim, usando ao mesmo tempo as 2 variáveis, uma poderia fazer 
o recorte onde a outra ainda mistura alguma coisa, uma apara as arestas da 
outra.


Abaixo segue crossplot e mapa, coloridos na mesma base, as cores de NDVI para 
12 classes. EVI2 é quase igual a EVI e a NDVI. Mas dizem que EVI e EVI2 são 
melhores para matas densas. NDVI pra vegetação em geral.


"EVI (Enhanced Vegetation Index) - In areas of dense canopy where the leaf area 
index (LAI) is high, the NDVI values can be improved by leveraging information 
in the blue wavelength. " 
(https://www.sentinel-hub.com/develop/documentation/eo_products/Sentinel2EOproducts)


"...contrary to that notion the Amazon forest does exhibit distinct growth 
during the dry season..." 
(https://en.wikipedia.org/wiki/Enhanced_vegetation_index - # Application of 
EVI...)


A ver o que acham.

https://i.imgur.com/9dBhNjC.jpg


Obrigado!

- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs



De: Paulo Carvalho 
mailto:paulo.r.m.carva...@gmail.com>>
Enviado: sexta-feira, 14 de setembro de 2018 18:14
Para: OSM talk-br
Assunto: Re: [Talk-br] Vetorização de matas no OSM com Sentinel-2

O problema, Sérgio, quando se usa uma fórmula, efetivamente estás resumindo 
duas variáveis a uma variável só.  Pela forma da mancha no crossplot B11 versus 
NDVI, a correlação entre elas não é linear, ou seja, elas não informam a mesma 
coisa.  Pelo contrário, temos que aumentar a dimensionalidade.  Seria 
importante vermos como os pontos se agrupam.  Talvez haja até bem mais do que 
duas classes.

Em sex, 14 de set de 2018 às 17:10, Sérgio V. 
mailto:svo...@hotmail.com>> escreveu:

Ok, ainda vou ver como fazer pra "definir a marca do crossplot para um único 
pixel"


A coisa que me intriga ainda é que estava reexaminando as imagens e 
histogramas, nos pontos onde há certeza das 2 classes, wood e forest, que pode 
ser confirmada na alta resolução do Bing.

E os histogramas me parecem ainda indicar que apontam para a confirmação da 
formulação empírica / gambiarra B11 x ((1-NDVI)*4000), nos valores de classes e 
diferenciação de:

1)wood (mais velha, pouco menos úmida, menos ativa em clorofila)

2)forest  (mais jovem, mais úmida, mais ativa em clorofila)

3)o que não é nenhum dos 2 e pode ser retirado de vetorização (para "null").


Imagens junto com histogramas correspondentes do caso B11 x ((1-NDVI)*4000):

https://i.imgur.com/4uKNw1r.jpg


É a mesma área que peguei como exemplo desde o início, porque tem todos os 
tipos que poderiam interferir, e dá pra examinar se o resultado distingue bem 
wood e forest do resto:

wood; forest; river; pond; campos ralos; farmland; estradas; ...


Nos histogramas, no NDVI, as forest ocupam sempre os níveis mais altos, de 
vegetação crescendo ativamente; como próprio do NDVI; enquanto as wood variam 
mais no espectro: há área velhas e algumas em crescimento. Então há mistura das 
2 classes.

Já no B11

Re: [Talk-br] Vetorização de matas no OSM com Sentinel-2

[Sérgio V .]

Ok, agora entendi esse negócio de manter as variáveis disponíveis sem fundir em 
uma. Valeu!
-O NDVI distingue bem vegetal do que não é, e as classes de vegetal em 
diferentes graus de clorofila nas folhas, isto é crescimento, atividade 
vegetal. Mas nas matas densas tem mata nativa + mata plantada (pinus 
principalmente no RS). Mata plantada tem sempre atividade mais alta e valores 
mais altos de NDVI. Mata nativa já mistura: tem áreas e indivíduos com ambos 
estados, em crescimento e em estagnação/maturidade, mas tende a menor atividade 
de crescimento.

Assim NDVI não distingue estas 2 dentro da mata ou em contato de bordas. Mas em 
imagem hi-res do Bing já é fácil distinguir uma da outra. Existe esta distinção 
de área de mata nativa separada de área de mata plantada.

-O B11 distingue muito bem uma da outra, aproximadamente por volta do valor 
1000: ~200 a 1000 (mais escuro) mata planta; ~1000 a 1600 (mais claro) mata 
nativa. Porém não distingue bem água/rio/sombra que fica entre ~0 a 300. Afeta 
um tanto pelas sombras em encostas, onde baixa o valor.

Do que entendi, assim, usando ao mesmo tempo as 2 variáveis, uma poderia fazer 
o recorte onde a outra ainda mistura alguma coisa, uma apara as arestas da 
outra.


Abaixo segue crossplot e mapa, coloridos na mesma base, as cores de NDVI para 
12 classes. EVI2 é quase igual a EVI e a NDVI. Mas dizem que EVI e EVI2 são 
melhores para matas densas. NDVI pra vegetação em geral.


"EVI (Enhanced Vegetation Index) - In areas of dense canopy where the leaf area 
index (LAI) is high, the NDVI values can be improved by leveraging information 
in the blue wavelength. " 
(https://www.sentinel-hub.com/develop/documentation/eo_products/Sentinel2EOproducts)


"...contrary to that notion the Amazon forest does exhibit distinct growth 
during the dry season..." 
(https://en.wikipedia.org/wiki/Enhanced_vegetation_index - # Application of 
EVI...)


A ver o que acham.

https://i.imgur.com/9dBhNjC.jpg


Obrigado!

- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs



De: Paulo Carvalho 
Enviado: sexta-feira, 14 de setembro de 2018 18:14
Para: OSM talk-br
Assunto: Re: [Talk-br] Vetorização de matas no OSM com Sentinel-2

O problema, Sérgio, quando se usa uma fórmula, efetivamente estás resumindo 
duas variáveis a uma variável só.  Pela forma da mancha no crossplot B11 versus 
NDVI, a correlação entre elas não é linear, ou seja, elas não informam a mesma 
coisa.  Pelo contrário, temos que aumentar a dimensionalidade.  Seria 
importante vermos como os pontos se agrupam.  Talvez haja até bem mais do que 
duas classes.

Em sex, 14 de set de 2018 às 17:10, Sérgio V. 
mailto:svo...@hotmail.com>> escreveu:

Ok, ainda vou ver como fazer pra "definir a marca do crossplot para um único 
pixel"


A coisa que me intriga ainda é que estava reexaminando as imagens e 
histogramas, nos pontos onde há certeza das 2 classes, wood e forest, que pode 
ser confirmada na alta resolução do Bing.

E os histogramas me parecem ainda indicar que apontam para a confirmação da 
formulação empírica / gambiarra B11 x ((1-NDVI)*4000), nos valores de classes e 
diferenciação de:

1)wood (mais velha, pouco menos úmida, menos ativa em clorofila)

2)forest  (mais jovem, mais úmida, mais ativa em clorofila)

3)o que não é nenhum dos 2 e pode ser retirado de vetorização (para "null").


Imagens junto com histogramas correspondentes do caso B11 x ((1-NDVI)*4000):

https://i.imgur.com/4uKNw1r.jpg


É a mesma área que peguei como exemplo desde o início, porque tem todos os 
tipos que poderiam interferir, e dá pra examinar se o resultado distingue bem 
wood e forest do resto:

wood; forest; river; pond; campos ralos; farmland; estradas; ...


Nos histogramas, no NDVI, as forest ocupam sempre os níveis mais altos, de 
vegetação crescendo ativamente; como próprio do NDVI; enquanto as wood variam 
mais no espectro: há área velhas e algumas em crescimento. Então há mistura das 
2 classes.

Já no B11 se destacam bem claramente entre si: uma não invade a margem de 
valores da outra.


Se não fosse a água no B11 (~50a300) se misturar com forest(~150a1200), daria 
pra usar só B11.


-No Cerrado, por exemplo, bastou usar só B11, não tem mata jovem/forest, nem 
mais úmida, deu pra usar só B11:

água no B11 (~50a600) ;  wood(~1000a1300).

É que também os tipos são de vegetação do Cerrado são diferentes, matas mais 
secas, mais castigadas, do que as matas mais úmidas da Mata Atlântica. Acho 
sempre vão apresentar valores um tanto diferentes tendendo pro mais seco.

https://wiki.openstreetmap.org/wiki/User:SergioAJV/Sentinel-2_vectorizing_tests#Cerrado_.28vetorizado_e_100.25_validado_para_OSM.29


-Já na Amazônia, úmida mas também com áreas de mata velha, a ponderação teve 
que ser não x4000, mas x500, para B11 + ((1- NDVI ) * 500 ):

https://wiki.openstreetmap.org/wiki/User:SergioA

Re: [Talk-br] Vetorização de matas no OSM com Sentinel-2

[Sérgio V .]

Ok, vou testar.
A curva do arco de parábola ali é o crossplot de EVI2 x NDVI.
Na verdade fiz 4 crossplot
B11xNDVI, B11xEVI2; EVI2xNDVI,
e o 3V B11xNDVIxEVI2. B11 no eixo x. 
O que exibe ali na figura é estes 2 últimos.
Só coloquei B11 com NDVI e EVI2 pra ver qual melhor, sendo base de informação 
já a B11. Pois NDVI e EVI2 tendo basicamente o mesmo propósito e mostrando 
histograma semelhante, tendo o mesmo comportamento para os mesmos objetos na 
imagem, pensei que basta uma.
Assim penso usar EVI2 com B11, só estas 2 basicamente. O B11 quase já 
classifica tudo que eu precisava.
Vou ver como testar o que você indicou agora, obrigado!

- - - - - - - - - - - - - - - -
Sérgio - http://www.openstreetmap.org/user/smaprs

De: Paulo Carvalho 
Enviado: domingo, 16 de setembro de 2018 11:13:03
Para: OSM talk-br
Assunto: Re: [Talk-br] Vetorização de matas no OSM com Sentinel-2

Sérgio, vi um arco de parábola no teu último gráfico.  Acredito que tenhas 
feito isso para poder usar três variáveis (combinando duas) no crossplot 2D.  
Para combinar múltiplas variáveis em duas coordenadas para ver um crossplot, 
use MDS: https://en.wikipedia.org/wiki/Multidimensional_scaling

Acredito que com alguns passos de cálculo seja possível criar as coordenadas 
MDS, que nada mais são de que outras variáveis, e plotá-las no crossplot 2D 
para ver os grupos.

Resumindo o método:
1) Calcular as dessemelhanças entre as amostras por uma fórmula de distância 
qualquer, por exemplo, a distância Euclideana: 
https://wikimedia.org/api/rest_v1/media/math/render/svg/c015e86e5cd0ed7a45f5c4c5107647b4d4970b14
 onde x e y são duas variáveis qualquer (ex.: B11 e NDVI), mas poderia ser 
três, quatro, etc. nessa soma de quadrados dentro da raíz;  i e j são os 
índices das amostras.  No exemplo, dij é a distância entre a i-ésima e a 
j-ésima amostra.  Tu podes usar outras fórmulas de distância, por exemplo, a 
distância de Manhattan.

2) Depois de calcular todas as dessemelhanças entre todas as amostras, os 
resultados são colocados em uma matriz: 
https://wikimedia.org/api/rest_v1/media/math/render/svg/ac5a364c06c41eede6a8689a417c79b0b984046d
Se houver 1.000 amostras, a matriz terá 1.000.000 de elementos.  A matriz de 
dessemelhança é como se fosse aquelas tabelas de distâncias entre cidades que 
havia nos mapas rodoviários de antigamente.

Seguindo a analogia das cidades, temos suas distâncias, mas não suas posições 
(x, y).  O problema consiste em encontrar a posição relativa (x, y)i de uma 
cidade i tal que, IDEALMENTE, a separação até uma cidade j seja igual à 
distância entre elas computadas no passo 2).  Ou seja, que o comprimento do 
vetor ||(xi - xj), (yi - yj)|| seja igual a dij.  Isso acontece se o número de 
variáveis de entrada for dois.  Como teremos 3 ou mais, o que estamos tentando 
fazer na prática é planificar algo que tem 3 ou mais dimensões, então o 
problema passa a ser de minimização porque as distâncias dij são calculadas em 
função das variáveis de entrada.  Assim o valor ||(xi - xj), (yi - yj)|| - dij 
deve ser o mínimo.

3) Computar a matriz B, cujos elementos bij = 1/2 * ( dij^2 - di.^2 - d.j^2 + 
d..^2 ), onde
bij = elemento da matriz B
dij = elemento da matriz de dessemelhanças
di. = i-ésimo vetor-linha (linha de uma matriz) da matriz de dessemelhanças
d.j = j-ésimo vetor-coluna (coluna de uma matriz) da matriz de dessemelhanças
d.. = toda a matriz de dessemelhanças (notação com dois pontos)
A notação de um vetor ou matriz "ao quadrado" (ex.: di.^2) quer dizer "pegue 
todos os elementos, eleve cada um ao quadrado e some tudo."

4) Decompor B em seus autovalores e autovetores (rever Álgebra Linear).  Essa 
decomposição resulta em duas matrizes: D = matriz com os autovalores em sua 
diagonal principal (os outros elementos são zero).  V = matriz cujas colunas 
são os autovetores.

5) Para um crossplot 2D, pegue os dois maiores autovalores de D e monte D1.  
Pegue os autovetores (colunas) de V correspondentes aos maiores autovalores e 
monte V1.  D1 será uma matriz 2 x 2 com os dois maiores autovalores e V1 terá 
uma linha para cada amostra (ex. 1000) e duas colunas.

6) Para cada elemento não zero de D1, inverta (se o elemento for 5, deve ser 
1/5) e tire a raíz quadrada.

7) A solução X será o produto das matrizes V1 e D1 X = V1 * D1.  X terá o 
número de linhas igual ao de amostras (ex. 1000) e 2 colunas.  A primeira 
coluna será a coordenada x e a segunda, y.  Essas coordenadas são usadas no 
crossplot.

Se quiseres um crossplot 3D, refaça os passos 5, 6 e 7, mas selecionado os três 
maiores autovalores e X terá três coordenadas (x, y, z).

Só isso!




Em sáb, 15 de set de 2018 às 20:12, Sérgio V. 
mailto:svo...@hotmail.com>> escreveu:
Valeu, vou pesquisar.
Tamo chegando lá.

- - - - - - - - - - - - - - - -
Sérgio - http://www.openstreetmap.org/user/smaprs



De: Paulo Carvalho 
mailto:paulo.r.m.carva...@gmail.com>>
Enviado