[OSM-talk] Facebook acquires crowdsourced mapping company Mapillary

[Sérgio V .]

https://uk.reuters.com/article/us-facebook-deals-mapillary/facebook-acquires-crowdsourced-mapping-company-mapillary-idUKKBN23P3N6



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

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

[Talk-br] Facebook acquires crowdsourced mapping company Mapillary

[Sérgio V .]

https://uk.reuters.com/article/us-facebook-deals-mapillary/facebook-acquires-crowdsourced-mapping-company-mapillary-idUKKBN23P3N6



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

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] Mapatona "Mapeando Rio Branco com o OpenStreetMap"

[Sérgio V .]

Bom dia Lívia, achei que ficou muito bacana o tutorial e bem completo.
Se vocês desejarem podem também fazer upload do PDF à wiki e colar na página do 
projeto.
Boa mapatona!



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

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


De: Lívia Degrossi 
Enviado: segunda-feira, 11 de maio de 2020 09:24
Para: Sérgio V. 
Cc: OpenStreetMap no Brasil 
Assunto: Re: [Talk-br] Mapatona "Mapeando Rio Branco com o OpenStreetMap"

Esqueci de anexar o tutorial.

-
Dr. Lívia Castro Degrossi
Postdoctoral researcher | National Centre for Disaster Monitoring and 
Early-Warning (Cemaden)




On Mon, May 11, 2020 at 9:23 AM Lívia Degrossi 
mailto:liviadegro...@gmail.com>> wrote:
Olá, pessoal.

Eu faço parte de um projeto internacional chamado Dados à Prova D'água e amanhã 
(terça-feira, dia 12/05) realizaremos uma capacitação sobre mapeamento usando 
OpenStreetMap, como parte da chamada "Mapeando Rio Branco com o OpenStreetMap"  
(https://twitter.com/waterproof_data/status/1255963265244553216).  Para a 
capacitação, os organizadores do evento elaboraram um tutorial sobre o 
OpenStreetMap, o qual eu compartilho em anexo.

Nas três terças-feiras subsequentes, isto é, dias 19/05, 26/05 e 02/06, nós 
realizaremos mutirões de mapeamento da cidade de Rio Branco. Como integrante da 
organização, eu gostaria de convidar a comunidade OSM Brasil a nos ajudar na 
validação do mapeamento realizado. Infelizmente, nós contamos com poucos 
mapeadores experientes para realizar essa tarefa.

Seguindo a orientação do Sérgio, vocês poderão encontrar todas as informações 
sobre o mapeamento nos seguintes links:

https://wiki.openstreetmap.org/wiki/Organised_Editing/Activities/Rio_Branco

https://tasks.hotosm.org/projects/6124

Muito obrigada.
Lívia
<https://twitter.com/waterproof_data/status/1255963265244553216>
-
Dr. Lívia Castro Degrossi
Postdoctoral researcher | National Centre for Disaster Monitoring and 
Early-Warning (Cemaden)




On Mon, May 4, 2020 at 11:57 AM Lívia Degrossi 
mailto:liviadegro...@gmail.com>> wrote:
Muito obrigada pelas informações detalhadas, Sérgio.

A organização do evento realizará todo o procedimento até o final dessa semana. 
Eu entrarei em contato novamente por meio da lista para divulgar a mapatona.

At.te,
Lívia
-
Dr. Lívia Castro Degrossi
Postdoctoral researcher | National Centre for Disaster Monitoring and 
Early-Warning (Cemaden)




On Mon, May 4, 2020 at 11:54 AM Sérgio V. 
mailto:svo...@hotmail.com>> wrote:
Olá Lívia, obrigado por responder.
Sim, pode escrever em privado, mas não terei nada especial a explicar, o 
procedimento todo já está nos links que coloquei abaixo, tem em várias línguas:
https://wiki.openstreetmap.org/wiki/Organised_Editing_Guidelines
https://wiki.osmfoundation.org/wiki/Organised_Editing_Guidelines#Process
Basicamente criar uma wiki e registar as informações ali, e publicar o link 
aqui mesmo nesta lista de e-mail que é o canal oficial do OSM-Brasil.
A wiki contento o básico para informar:
-onde serão as áreas a ser mapeadas (municípios, bairros, o que for);
-o que se pretende mapear em tags próprias do OSM (waterways, highways, 
buildings, POIs, etc);
-como será o controle de qualidade de novas edições feitas;
-Contato dos organizadores responsáveis, suas contas no OSM, para eventuais 
contatos;
-se houver, eventuais fontes de dados externos que seriam usadas e sua licença 
própria ao OSM.

Ali também tem um exemplo de wiki para registro de mapatona:
https://wiki.openstreetmap.org/wiki/Organised_Editing/Activities/Example_City_Lamppost_Mapping
Qualquer dúvida, volte a contatar. Parabéns pela inciativa.
Att.,
- - - - - - - - - - - - - - - -

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


De: Lívia Degrossi mailto:liviadegro...@gmail.com>>
Enviado: segunda-feira, 4 de maio de 2020 09:49
Para: OpenStreetMap no Brasil 
mailto:talk-br@openstreetmap.org>>
Assunto: Re: [Talk-br] Mapatona "Mapeando Rio Branco com o OpenStreetMap"

Olá, Sérgio.

Eu estou participando da organização e posso te passar mais informações.

Primeiramente, eu peço desculpas por não termos adicionado a mapatona na wiki 
do OSM, nós não tínhamos conhecimento sobre isso. Eu poderia escrever para você 
em privado para que você me explique os procedimentos corretos?

At.te,
Lívia
-
Dr. Lívia Castro Degrossi
Postdoctoral researcher | National Centre for Disaster Monitoring and 
Early-Warning (Cemaden)




On Fri, May 1, 2020 at 10:47 PM Sérgio V. 
mailto:svo...@hotmail.com>> wrote:
Olá pessoal, saudações covídicas,
achei muito interessante o projeto
"Mapeando Rio Branco com o OpenStreetMap"

https://twitter.com/waterproof_data/status/1255963265244553216

https://docs.google.com/forms/d/e/1FAIp

Re: [Talk-br] Mapatona "Mapeando Rio Branco com o OpenStreetMap"

[Sérgio V .]

Olá Lívia, obrigado por responder.
Sim, pode escrever em privado, mas não terei nada especial a explicar, o 
procedimento todo já está nos links que coloquei abaixo, tem em várias línguas:
https://wiki.openstreetmap.org/wiki/Organised_Editing_Guidelines
https://wiki.osmfoundation.org/wiki/Organised_Editing_Guidelines#Process
Basicamente criar uma wiki e registar as informações ali, e publicar o link 
aqui mesmo nesta lista de e-mail que é o canal oficial do OSM-Brasil.
A wiki contento o básico para informar:
-onde serão as áreas a ser mapeadas (municípios, bairros, o que for);
-o que se pretende mapear em tags próprias do OSM (waterways, highways, 
buildings, POIs, etc);
-como será o controle de qualidade de novas edições feitas;
-Contato dos organizadores responsáveis, suas contas no OSM, para eventuais 
contatos;
-se houver, eventuais fontes de dados externos que seriam usadas e sua licença 
própria ao OSM.

Ali também tem um exemplo de wiki para registro de mapatona:
https://wiki.openstreetmap.org/wiki/Organised_Editing/Activities/Example_City_Lamppost_Mapping
Qualquer dúvida, volte a contatar. Parabéns pela inciativa.
Att.,
- - - - - - - - - - - - - - - -

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


De: Lívia Degrossi 
Enviado: segunda-feira, 4 de maio de 2020 09:49
Para: OpenStreetMap no Brasil 
Assunto: Re: [Talk-br] Mapatona "Mapeando Rio Branco com o OpenStreetMap"

Olá, Sérgio.

Eu estou participando da organização e posso te passar mais informações.

Primeiramente, eu peço desculpas por não termos adicionado a mapatona na wiki 
do OSM, nós não tínhamos conhecimento sobre isso. Eu poderia escrever para você 
em privado para que você me explique os procedimentos corretos?

At.te,
Lívia
-
Dr. Lívia Castro Degrossi
Postdoctoral researcher | National Centre for Disaster Monitoring and 
Early-Warning (Cemaden)




On Fri, May 1, 2020 at 10:47 PM Sérgio V. 
mailto:svo...@hotmail.com>> wrote:
Olá pessoal, saudações covídicas,
achei muito interessante o projeto
"Mapeando Rio Branco com o OpenStreetMap"

https://twitter.com/waterproof_data/status/1255963265244553216

https://docs.google.com/forms/d/e/1FAIpQLSc3CthaGEMMhaObJKfjYRHvUp899BtpKedNDAwzB1BRJ-KdiQ/viewform

Pedi informações aos organizadores mas não obtive resposta ainda.
Vi a mensagem no tuiter do OpenStreetMapBR
https://twitter.com/OpenStreetMapBR/status/1256189877055639552?s=20

Queria saber antecipadamente o que será mapeado, e de que forma poderia 
colaborar, se fecha com minhas disponibilidades e interesses.
Procurei mais informações mas não encontrei.
Nem no talk-br.
Só fornecem se se cadastrar, no link:
"...A organização enviará o material de apoio para o e-mail dos inscritos..."

Conforme as diretrizes do OSM,
para mapatonas e atividades de edições organizadas em grupos:
https://wiki.openstreetmap.org/wiki/Organised_Editing_Guidelines
e
https://wiki.osmfoundation.org/wiki/Organised_Editing_Guidelines ,
a documentação da (proposta de) atividade tem que ser acessível:
-documentado na wiki
-comunicado à comunidade

Eu tenho interesse em saber mais sobre o referido projeto.
Foi publicada wiki do assunto?

Se não foi, o pessoal que gerencia o https://twitter.com/OpenStreetMapBR, pelo 
que entendi conhecem os organizadores, poderiam pedir a eles para 
disponibilizarem o material na wiki, pra gente poder saber mais?

Obrigado,

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

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

___
Talk-br mailing list
Talk-br@openstreetmap.org<mailto: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] Mapatona "Mapeando Rio Branco com o OpenStreetMap"

[Sérgio V .]

Olá pessoal, saudações covídicas,
achei muito interessante o projeto
"Mapeando Rio Branco com o OpenStreetMap"

https://twitter.com/waterproof_data/status/1255963265244553216

https://docs.google.com/forms/d/e/1FAIpQLSc3CthaGEMMhaObJKfjYRHvUp899BtpKedNDAwzB1BRJ-KdiQ/viewform

Pedi informações aos organizadores mas não obtive resposta ainda.
Vi a mensagem no tuiter do OpenStreetMapBR
https://twitter.com/OpenStreetMapBR/status/1256189877055639552?s=20

Queria saber antecipadamente o que será mapeado, e de que forma poderia 
colaborar, se fecha com minhas disponibilidades e interesses.
Procurei mais informações mas não encontrei.
Nem no talk-br.
Só fornecem se se cadastrar, no link:
"...A organização enviará o material de apoio para o e-mail dos inscritos..."

Conforme as diretrizes do OSM,
para mapatonas e atividades de edições organizadas em grupos:
https://wiki.openstreetmap.org/wiki/Organised_Editing_Guidelines
e
https://wiki.osmfoundation.org/wiki/Organised_Editing_Guidelines ,
a documentação da (proposta de) atividade tem que ser acessível:
-documentado na wiki
-comunicado à comunidade

Eu tenho interesse em saber mais sobre o referido projeto.
Foi publicada wiki do assunto?

Se não foi, o pessoal que gerencia o https://twitter.com/OpenStreetMapBR, pelo 
que entendi conhecem os organizadores, poderiam pedir a eles para 
disponibilizarem o material na wiki, pra gente poder saber mais?

Obrigado,

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

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] Sentinel Hub Script Contest

[Sérgio V .]

Programadores:

"Take part in the Sentinel Hub Custom Script Contest! "

https://twitter.com/sentinel_hub/status/1184016270066409472?s=20

https://www.sentinel-hub.com/contest

https://www.sentinel-hub.com/develop/documentation/custom-processing-scripts

https://custom-scripts.sentinel-hub.com/



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

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] Local community chats by continent / country

[Sérgio V .]

https://wiki.openstreetmap.org/wiki/List_of_OSM_centric_Telegram_accounts#America

OMG!



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

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] Alunos Turismo Ecológico

[Sérgio V .]

Bom dia comunidade OSM BR.
Para comunicação, estou assessorando mini-curso de Mapeamento Digital com os 
alunos do Curso de Turismo Ecológico, Projeto Jovem Aprendiz, do Polo Marista 
de Formação Tecnológica, Ilha da Pintada, Porto Alegre.
Irão começar a gravar trilhas GPS, anotar POIs, verificar no OSM e mapear, foco 
do trabalho na região das ilhas.


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

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

Re: [OSM-talk] Facebook mapping highways using AI in collaboration with OpenStreetMap

[Sérgio V .]

In a paralell thought, we could use more of Sentinel satellite weekly updated 
images 10m resolution in OSM for this kind of land covers.

>Arun Ganesh
>And yes, those glaciers have probably melted away and theres
>no practical way to ground truth them

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

Re: [OSM-talk] Facebook mapping highways using AI in collaboration with OpenStreetMap

[Sérgio V .]

That's also why I've always emphasized that the link for OSMF-talk email list
SHOULD be accessible for everyone to know it and read it (even if not signed to 
that mail list)
to be aware of what's going inside OSMF talks.
Not some hidden link in one in a thousand of wiki pages (I forgot it again).
It SHOULD be listed in the official LISTINFO, publicly:
https://lists.openstreetmap.org/listinfo
While not, OSMF looks not much transparent for the simple collaborator.

>Whoever reads this and does not have deeper insights into the workings of
>the OSMF must get into the impression that HOT is an official part of the
>OSMF / OpenStreetMap, i.e. OSM is collaborating with FB.
>I am not sure if being a "corporate Gold member" already counts as being in
>collaboration with OSMF (likely not, because "collaboration" means
>"working" (labor) together, not just providing funds)
>Cheers,Martin


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

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

Re: [OSM-talk] Facebook mapping highways using AI in collaboration with OpenStreetMap

[Sérgio V .]

Just adding my R$0,02 (Brazilian Real).
I guess soon the AI assisted Human mapping will happen, it may be a very good 
help.
But I can't evaluate what's been publicized July 23, 2019 by
https://ai.facebook.com/blog/mapping-roads-through-deep-learning-and-weakly-supervised-training
"To browse our machine learning road predictions or start mapping with RapiD, 
please visit mapwith.ai."
So at "Map faster, Map better" https://mapwith.ai/#14/6.13864/6.7698 ,
I actually can't evaluate any result for roads at max zoom level 14, to see if 
it's really better. I can just believe it can be.


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

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

[Talk-br] Spam nos diários

[Sérgio V .]

Spam nos diários:

https://www.openstreetmap.org/user/Sandrexx/diary/390304
(Usuário com diário e zero edições)
"Descubra Por que o mundo precisa do OpenStreetMap":
"...A resposta é bem simples:
<*link: Na sociedade Sardinha Evolution>
funciona, nenhuma empresa deve ter o monopólio dos lugares..."
*link: 
https://www.comoganhardinheirointernet.com/sardinha-evolution-pdf-gratis-download/

(deve ser PDF envenenado)

Não deixa de ser criativo o bot gerador de dissertação.


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

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

[OSM-talk] Ordnance Survey OpenData

[Sérgio V .]

Just to share news,
Ordnance Survey OpenData - OS Open Names etc
https://twitter.com/OrdnanceSurvey/status/1153593110129270784?s=20
https://www.ordnancesurvey.co.uk/business-and-government/products/opendata.html
Regards


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

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

Re: [OSM-talk] Map of Population Density vs. OpenStreetMap density

[Sérgio V .]

Excelent and inteligent initiative Darafei.
Measuring "density of OSM data" per "Population density" is a powerful metric 
to analyse where is it lacking more mapping in OSM.
It's a nice effort to minimize "inequality" in OSM map.
(for more info, see "World Inequality Database" at https://wid.world/world)

I've did that metric for Brazil in 2017, "Demography in Brazil to help mapping 
in OSM", at:
https://wiki.openstreetmap.org/wiki/Demografia_do_Brasil_como_auxiliar_no_OSM
It helped me much to find places lacking mapping.
Everytime I just take a fast look at the highlighted places int that map, I've 
actualy found undermapped places, lacking roads mostly.

These metrics lead to view two aspects:
a) By one hand, the world is in a fast urbanizing process. People more and more 
migrate to bigger cities, looking for better jobs, services, better life.
According to United Nations report, "68% (2/3) of the world population 
projected to live in urban areas by 2050" (UN 2018-05-16 - 
https://www.un.org/development/desa/en/news/population/2018-revision-of-world-urbanization-prospects.html).
So, it's generally expected to have a lot of irregular setlements to map in 
broader urban areas. Even benig irregular, millions of people live in such 
places.
b) By the other hand, people remaining in country sides become more alone (many 
times old people), living far away from good public services and enough 
incomes, broadly unassisted. So also important to map their accessibility.

Don't matter with objections for too much fine precision on demography.
That metric anyway gives much more reasonable focus than usual 
over mapping done in OSM.
Nice, keep going, publish it.
Regards



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

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

Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[Sérgio V .]

Bah, uma verdadeira "Bagunça".
Nossa. Espirrou perto.

Mas de fato, se fosse feito hoje poderia ter sido muitas coisas diferente.
O cuidado com os dados é muito importante. Isso é uma parte da coisa.
Agora, com a verdade da circunstância completa, são outros quinhentos.

Então, bom lembrar também que a proposta foi publicada na época.
Mais conversas e auxílios no telegram, por parte da "comunidade que mostrou 
interesse".
Quem não opinou, não se importou com "bagunça" possível na ocasião, seria 
minimamente honesto incluir no report que aceitou assim.
Mas já se conhece o funcionamento da coisa: seleção dos fatos que interessam.
E "bagunça" é coisa séria. Nossa, o mapa de Porto Alegre terminou imprestável 
pra qualquer um usar.

Publicação da proposta no Talk-br: 2016-04-25
Início da Wiki: 2016-04-26
Início da importação: changeset="38980822" timestamp="2016-04-29
Encerramento da importação: changeset="40442780" timestamp="2016-07-02

Dois meses de processo.
Tempo para qualquer um (interessado) em se manifestar ao menos antes do fim 
daquela importação.

Os russos recentemente introduziram uma moda de andar jogando veneno.
Vou aproveitar pra tomar uma vacina, ou um antídoto, me esconder. A coisa tá se 
espalhando.


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

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




De: Fernando Trebien 
Enviado: quinta-feira, 14 de fevereiro de 2019 16:19
Para: OpenStreetMap no Brasil
Assunto: Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em 
importação de addr:housenumber

...Por exemplo, na importação dos edifícios em Porto Alegre, uma informação
foi colocada na etiqueta description, foi solicitado aos mapeadores
que fosse convertida em etiquetas consumíveis (geralmente amenity=*),
mas esse trabalho nunca foi feito por ninguém. A informação está lá no
OSM, parada há anos, sem usufruto pelas aplicações. Como diz o wiki
[2] num texto proveniente do original em inglês, "nunca suponha que
essas pessoas vão alegremente arrumar a bagunça que você fez."...


--
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] RES: Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[Sérgio V .]

>...não vejo o mínimo sentido acochambrar as coisas...
Alguém falou em acochambrar algo?
O discutido deste tópico, como no título, é para ver se uma necessidade 
apontada é real ou não.
Sendo argumentado que ela é mesmo real, já foi concordado aqui que ela é uma 
"necessidade necessária".

> A verdade é uma só, os aplicativos de roteirização são “cobrados” pelos seus 
> usuários pelas imprecisões que apresentem, então quem os implementa quer tudo 
> perfeito saindo do mapa, mas por a mão na massa para fazer ou arcar com os 
> custos são outros quinhentos.

Sim, lembro com isso de aproveitar para divulgar o projeto abaixo em andamento, 
pedindo igualmente se puder divulgar, e/ou colaborar. Se já colaborou, obrigado.
https://apoie.me/osmbrasilcuritiba


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

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


De: Reinaldo Neves 
Enviado: sexta-feira, 8 de fevereiro de 2019 17:43
Para: 'OpenStreetMap no Brasil'
Assunto: [Talk-br] RES: Sobre a necessidade (ou não) de ter addr:street em 
importação de addr:housenumber

A verdade é uma só, os aplicativos de roteirização são “cobrados” pelos seus 
usuários pelas imprecisões que apresentem, então quem os implementa quer tudo 
perfeito saindo do mapa, mas por a mão na massa para fazer ou arcar com os 
custos são outros quinhentos.

Alias é justamente para sair dos custos de licença de Google e here que alguns 
utilizam OSM.

Quanto ao uso apenas de número e posição geográfica para gerar uma rota, por 
mais que funcione na maioria dos casos pode gerar vultas enormes em casos de 
áreas com logradouros tendo mão e contramão ou que cruzem linha férrea, 
viadutos, etc...

Por último, endereço por definição é um conjunto de dados (nome de rua, número 
de casa, prédio ou terreno etc.) que tornam possível a localização de um imóvel 
e/ou designam o próprio imóvel, sendo assim não vejo o mínimo sentido 
acochambrar as coisas para importar dados parciais apenas porque são úteis para 
um ou outro.

___

Reinaldo Neves
Equação Informática
☎: (11) 3221-3722
✉: rne...@equacao.com.br
http://br.linkedin.com/in/rrneves
https://medium.com/Reinaldo_Neves

De: Sérgio V. [mailto:svo...@hotmail.com]
Enviada em: sexta-feira, 8 de fevereiro de 2019 15:17
Para: Fernando Trebien; OpenStreetMap no Brasil
Assunto: Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em 
importação de addr:housenumber



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


De: Fernando Trebien 
Enviado: sexta-feira, 8 de fevereiro de 2019 14:47
Para: OpenStreetMap no Brasil
Assunto: Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em 
importação de addr:housenumber

On Fri, Feb 8, 2019 at 11:49 AM Sérgio V.  wrote:
>
> De: Nelson A. de Oliveira 
> Enviado: sexta-feira, 8 de fevereiro de 2019 10:38
>
> >É o que também indicam...
>
> Hum...São definições contraditórias:
> -uma diz que "um programa pode" assumir o nome da rua mais próxima;
> -outra que "deve" estar em "associatedStreet relation".

Poder pode, mas nem sempre dá certo. Com frequência falha nas esquinas
por causa da distância entre o ponto e as ruas. Como constam nas
referências do Nelson, as aplicações esperam que esta seja a exceção e
não a regra.

> Afinal, qual diz o que efetivamente é necessário?
>
> Aí nestes casos surge a dúvida evidente: quem definiu assim, diferente? E por 
> quê?
> Me parece que a definição parte mais de quem tem interesse no benefício do 
> uso do resultado do trabalho todo feito,
> do que de quem tem que realizar o trabalho.

Nesse momento nós estamos limitados pela capacidade das nossas
ferramentas. Dependemos do ecossistema feito fora do Brasil.

> Até agora, do que entendo, é o aplicativo, este sim, que vai se beneficiar 
> "sem esforço" nesta parte,
> ganhar dados a mais de graça, como "mágica", para fazer a navegação de modo 
> mais "fácil" e "rápido"...
> ...e ainda ganhar dinheiro com isso.

A licença dos dados do OSM permite que qualquer consumidor ganhe
dinheiro com o nosso trabalho, contanto que atribua ao OSM o crédito
pelos dados.

// Sim, isso eu sei. Não é isso que tá questionado ali. Pode ganhar dinheiro.
O questionamento todo é que, "além" de ganhar dinheiro coo o uso dos dados,
ganha recebendo um trabalho "extra" mastigado que o aplicativo mesmo pode fazer.


--
Fernando Trebien

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


---
Este e-mail foi verificado quanto a vírus pelo AVG.
http://www.avg.com


___
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] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[Sérgio V .]

E ao que me parece, mesmo errando, são erros muito pequenos.

Não erra do outro lado da cidade ou do bairro. Erra o lado da esquina apenas.
Se for só lado de esquina, desce do carro e bate na porta. Se não for esta, 
bate na do lado.

Precisa-se que o aplicativo mostre a porta certa na esquina, na rua do lado 
certo?
Mesmo que tenha isto devidamente escrito em "addr:housenumber + addr:street",
com os erros de 10 a 20m de GPS (mais ainda em centros, cânion urbano),
não vai ter a precisão desejada, pode errar a indicação de todo modo.

Quais outros erros pode haver?

Um trabalho gigantesco esperado, de complementar 200.000 endereços,
(mais o que houver mundo afora),
- por um "possível" erro que pode acontecer só em esquinas (10%);
- e que, ainda que corrigido, "não" vai fazer diferença, pois o sinal de GPS 
erra mais.

É isso mesmo?

Custo x benefício:
Beneficia a quem?
Custa pra quem?

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

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

________
De: Sérgio V. 
Enviado: sexta-feira, 8 de fevereiro de 2019 15:39
Para: santamariense; OpenStreetMap no Brasil
Assunto: RE: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em 
importação de addr:housenumber

Aliá, como que um aplicativo roteia o endereço?

Não é o usuário escrevendo na busca?:
Rua = Rua X
Nº= 10

Como vai errar a rua, se já escreveu ela

Ok, pode ter outro Nº10 na rua Y ao lado, bem na esquina com a Rua X.
Então são "dois Nº= 10", um em cada lado da esquina X com Y.

Ainda assim o roteamento vai chegar na mesma esquina.
Mesmo que erre em qual lado da esquina estiver.
Não é?

Mas se quiser mais precisão, acertar
"qual dos dois Nº= 10 é o da Rua X"?

Ora, aquele que estiver próximo de um número qualquer na sequência da rua X:

---  (RUA Y)
15   |
--   |
10   |
---   - - - - - - - - - - - - - -  (RUA X)
(ESQ.) | 10 | 40 |
  ^ ^







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

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


De: santamariense 
Enviado: sexta-feira, 8 de fevereiro de 2019 14:31
Para: talk-br@openstreetmap.org
Assunto: Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em 
importação de addr:housenumber

> As ruas da prefeitura tão no conjunto separado, EIXOS, da SMURB, que também 
> não interessa porque não é igual ao OSM.
> O que vale são os nomes que tão no OSM.

O ideal é que o nome dos logradouros bata 100% com o nome dos
logradouros nos housenumbers, mas isso não interfere em nada o
funcionamento de aplicativos. Ao meu ver poderia ser importado com os
nomes conforme estão na base da prefeitura se fosse o caso.

> Para o OSM, então, ok, terão que ser adicionados estes campos, quando 
> faltantes, a milhares de objetos.

Provavelmente quase todo housenumber que chegou ao OSM sem addr:street
ou relação veio por meio de importações. Naturalmente, "qualquer"
mapeador que for adicionar um endereço no mapa já vai assim fazer com
com o nome da rua junto.

89% dos addr:housenumber tem addr:street -
https://taginfo.openstreetmap.org/keys/addr%3Ahousenumber#combinations

Podemos dar uma sondada, em um primeiro momento, para ver se achamos
uma solução >automatizada< de com o ponto e seu ângulo, e a com uma
geometria de ruas extraídas do OSM conseguir obter o nome das ruas.

___
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] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[Sérgio V .]

Aliá, como que um aplicativo roteia o endereço?

Não é o usuário escrevendo na busca?:
Rua = Rua X
Nº= 10

Como vai errar a rua, se já escreveu ela

Ok, pode ter outro Nº10 na rua Y ao lado, bem na esquina com a Rua X.
Então são "dois Nº= 10", um em cada lado da esquina X com Y.

Ainda assim o roteamento vai chegar na mesma esquina.
Mesmo que erre em qual lado da esquina estiver.
Não é?

Mas se quiser mais precisão, acertar
"qual dos dois Nº= 10 é o da Rua X"?

Ora, aquele que estiver próximo de um número qualquer na sequência da rua X:

---  (RUA Y)
15   |
--   |
10   |
---   - - - - - - - - - - - - - -  (RUA X)
(ESQ.) | 10 | 40 |
  ^ ^







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

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


De: santamariense 
Enviado: sexta-feira, 8 de fevereiro de 2019 14:31
Para: talk-br@openstreetmap.org
Assunto: Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em 
importação de addr:housenumber

> As ruas da prefeitura tão no conjunto separado, EIXOS, da SMURB, que também 
> não interessa porque não é igual ao OSM.
> O que vale são os nomes que tão no OSM.

O ideal é que o nome dos logradouros bata 100% com o nome dos
logradouros nos housenumbers, mas isso não interfere em nada o
funcionamento de aplicativos. Ao meu ver poderia ser importado com os
nomes conforme estão na base da prefeitura se fosse o caso.

> Para o OSM, então, ok, terão que ser adicionados estes campos, quando 
> faltantes, a milhares de objetos.

Provavelmente quase todo housenumber que chegou ao OSM sem addr:street
ou relação veio por meio de importações. Naturalmente, "qualquer"
mapeador que for adicionar um endereço no mapa já vai assim fazer com
com o nome da rua junto.

89% dos addr:housenumber tem addr:street -
https://taginfo.openstreetmap.org/keys/addr%3Ahousenumber#combinations

Podemos dar uma sondada, em um primeiro momento, para ver se achamos
uma solução >automatizada< de com o ponto e seu ângulo, e a com uma
geometria de ruas extraídas do OSM conseguir obter o nome das ruas.

___
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] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[Sérgio V .]

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

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


De: Fernando Trebien 
Enviado: sexta-feira, 8 de fevereiro de 2019 14:47
Para: OpenStreetMap no Brasil
Assunto: Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em 
importação de addr:housenumber

On Fri, Feb 8, 2019 at 11:49 AM Sérgio V.  wrote:
>
> De: Nelson A. de Oliveira 
> Enviado: sexta-feira, 8 de fevereiro de 2019 10:38
>
> >É o que também indicam...
>
> Hum...São definições contraditórias:
> -uma diz que "um programa pode" assumir o nome da rua mais próxima;
> -outra que "deve" estar em "associatedStreet relation".

Poder pode, mas nem sempre dá certo. Com frequência falha nas esquinas
por causa da distância entre o ponto e as ruas. Como constam nas
referências do Nelson, as aplicações esperam que esta seja a exceção e
não a regra.

> Afinal, qual diz o que efetivamente é necessário?
>
> Aí nestes casos surge a dúvida evidente: quem definiu assim, diferente? E por 
> quê?
> Me parece que a definição parte mais de quem tem interesse no benefício do 
> uso do resultado do trabalho todo feito,
> do que de quem tem que realizar o trabalho.

Nesse momento nós estamos limitados pela capacidade das nossas
ferramentas. Dependemos do ecossistema feito fora do Brasil.

> Até agora, do que entendo, é o aplicativo, este sim, que vai se beneficiar 
> "sem esforço" nesta parte,
> ganhar dados a mais de graça, como "mágica", para fazer a navegação de modo 
> mais "fácil" e "rápido"...
> ...e ainda ganhar dinheiro com isso.

A licença dos dados do OSM permite que qualquer consumidor ganhe
dinheiro com o nosso trabalho, contanto que atribua ao OSM o crédito
pelos dados.

// Sim, isso eu sei. Não é isso que tá questionado ali. Pode ganhar dinheiro.
O questionamento todo é que, "além" de ganhar dinheiro coo o uso dos dados,
ganha recebendo um trabalho "extra" mastigado que o aplicativo mesmo pode fazer.


--
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] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[Sérgio V .]

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

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


De: santamariense 
Enviado: sexta-feira, 8 de fevereiro de 2019 14:31
Para: talk-br@openstreetmap.org
Assunto: Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em 
importação de addr:housenumber

>> As ruas da prefeitura tão no conjunto separado, EIXOS, da SMURB, que também 
>> não interessa porque não é igual ao OSM.
>> O que vale são os nomes que tão no OSM.

>O ideal é que o nome dos logradouros bata 100% com o nome dos
>logradouros nos housenumbers, mas isso não interfere em nada o
>funcionamento de aplicativos. Ao meu ver poderia ser importado com os
>nomes conforme estão na base da prefeitura se fosse o caso.

Neste caso não ajuda nada os nomes de rua da PMPA nos vetores linha do 
EIXOS_TMPOA.SHP.
O trabalho é mais simples (se isso for simples) com os próprios vetores do OSM,
pois são os do OSM os de interesse, já tá tudo correto, são os mais 
compatíveis, alinhados, e nomes adequados.

>> Para o OSM, então, ok, terão que ser adicionados estes campos, quando 
>> faltantes, a milhares de objetos.

>Provavelmente quase todo housenumber que chegou ao OSM sem addr:street
>ou relação veio por meio de importações. Naturalmente, "qualquer"
>mapeador que for adicionar um endereço no mapa já vai assim fazer com
>com o nome da rua junto.

Eu poucas vezes adicionava addr:street. Só addr:housenumber.
Não sabia da obrigação. Ainda mais que a rua já tá escrita no vetor que tá ao 
lado do mesmo endereço. Sempre achava redundante, preciosismo. Sempre achei que 
era ilógico duplicar a mesma informação que já consta na rua nomeada. (não sei 
se o Google faça isso, duplicar as informações... e se o faz deve ser 
automatizado)
E sempre achei que os endereço eram encontrados  simplesmente por:
nome no "vetor da rua" +  número no "outro objeto" (polígono de prédio; 
ponto...) próximo à rua
Isso resolveria uns 90% dos casos.
Os casos de esquina, ambíguos, devem ser uns 10%.

Ainda assim, mesmo que erre a rua,
"qual das duas ruas da esquina que contém o número tal"
o que pode errar é só a rua, não o ponto.
Ainda assim, o roteamento chega lá. Não é verdade?
Não consigo entender onde tá o problema para roteamento.

>89% dos addr:housenumber tem addr:street -
>https://taginfo.openstreetmap.org/keys/addr%3Ahousenumber#combinations

>Podemos dar uma sondada, em um primeiro momento, para ver se achamos
>uma solução >automatizada< de com o ponto e seu ângulo, e a com uma
>geometria de ruas extraídas do OSM conseguir obter o nome das ruas.

Ainda assim não penso só no caso de PoA.
Penso pra todas as importações que possam ser assim.

Supõe um tempo disponível enorme, que não é algo viável em sistema 
"colaborativo".

___
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] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[Sérgio V .]

Ok. Se dados completos no OSM é aquela definição, então é.
O que não deixa de ser arbitrária: ela tem que ser assim devido à situação; 
porque não se tem capacidade de resolver de outro modo.
Neste material da prefeitura não tem addr:street direto. Possivelmente em 
muitas outras ao redor do mundo também não.
Tem número e coordenadas, e se viram com isto.
As ruas da prefeitura tão no conjunto separado, EIXOS, da SMURB, que também não 
interessa porque não é igual ao OSM.
O que vale são os nomes que tão no OSM.
Para o OSM, então, ok, terão que ser adicionados estes campos, quando 
faltantes, a milhares de objetos.
Possivelmente em diversas importações. Isto irá se repetir sempre.
Mesmo automatizadamente, exigirá muito tempo.
Precisará ter gente e tempo suficiente pra executar todo este exigido. Sempre.

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

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


De: Nelson A. de Oliveira 
Enviado: sexta-feira, 8 de fevereiro de 2019 12:51
Para: OSM talk-br
Assunto: Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em 
importação de addr:housenumber

On Fri, Feb 8, 2019 at 12:18 PM Sérgio V.  wrote:
> Quer dizer, o "deve" serve pra nós só?
> Tou vendo que a coisa toda tá como nós tendo o dever de preparar tudo 
> mastigado pra aplicativos.

O objetivo é ter os dados completos no OSM, independente de outros
implementarem ou não características desejáveis.

Pode ver pelo ponto de vista de um usuário qualquer, que quer pegar os
endereços do OSM: "ué, só tem número? o que eu faço com isso?"

___
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] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[Sérgio V .]

>Os programas "podem" calcular, mas acho que nenhum faz isso.
>"Podem" (sugestão) é diferente de "devem" (obrigação).

Quer dizer, o "deve" serve pra nós só?
Tou vendo que a coisa toda tá como nós tendo o dever de preparar tudo mastigado 
pra aplicativos.
Me incluam fora desta.

E já disse: prevejo que não vai ter gente pra atender, sob estas atuais 
condições, para importações de endereços.
Mal se tem pra mapeamento básico.
Só pagando grupos pra fazer (é por isso que já tão acontecendo estes grupos.)


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

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


De: Nelson A. de Oliveira 
Enviado: sexta-feira, 8 de fevereiro de 2019 12:03
Para: OSM talk-br
Assunto: Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em 
importação de addr:housenumber

On Fri, Feb 8, 2019 at 11:49 AM Sérgio V.  wrote:
> Hum...São definições contraditórias:
> -uma diz que "um programa pode" assumir o nome da rua mais próxima;
> -outra que "deve" estar em "associatedStreet relation".

Os programas "podem" calcular, mas acho que nenhum faz isso.
"Podem" (sugestão) é diferente de "devem" (obrigação).

O endereço pode estar associado com "addr:street" (que praticamente
tudo entende) ou relação street/associatedStreet (quem poucos
entendem).

> Quer dizer: em "muitos outros casos" seria "fácil" para o aplicativo fazer? 
> Deduz-se que sim.

Depende de como você vê isso: é mais fácil ter 100 implementações
fazendo a mesma coisa (calculando endereço) ou fazer isso apenas uma
vez? (nos dados do OSM)
Se existem 100 programas que usam os endereços e 50 não implementam
isso, metade dos usuários dos dados vão ficar sem a informação?
Como que se convence todos os programadores a fazer isso?
A responsabilidade é dos programadores em desenvolver algo que é
apenas desejável ou é do OSM, em ter os dados incompletos?

___
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] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[Sérgio V .]

Claro, pode haver mais de 1 "número tal" (ex.Nº10) "perto" da rua, e dar 
ambiguidade.
Como numa esquina onde iniciam 02 ruas. As 02 podem ter 02 "Nº10" perto.

Neste caso, pode-se desempatar com os números próximos daquele primeiro, que 
estiverem na sequência com os demais "perto" da mesma rua.
-Em um caso, o próximo número da sequência vai necessariamente se afastar; o 
que exclui.
-No outro, o próximo número da sequência vai permanecer perto da rua em questão.

-- 20 --
--(15)--http://www.openstreetmap.org/user/smaprs

________
De: Sérgio V. 
Enviado: sexta-feira, 8 de fevereiro de 2019 11:57
Para: santamariense; OpenStreetMap no Brasil
Assunto: RE: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em 
importação de addr:housenumber

>Notou se algum campo destes pontos teria algum código que
referenciasse um logradouro ao invés de diretamente o nome do
logradouro?

Ora:
-Cada "número" tem as suas "coordenadas";
-E no OSM tem as "ruas" já mapeadas, na frente (perto) destas coordenadas.
Isto não basta pra localizar "rua"e "número"?
Consigo pensar numa lógica simples:
1) abre-se o o aplicativo;
2) escreve a procura por: "rua tal", "numero tal";
3) ele localiza a rua;
4) ele procura dentre os nós mais próximos dela (na ordem dos mais próximos), 
aquele que tem o "numero tal".
Feito.
Os aplicativos não fazem isto? Ou querem a coisa mastigada e de graça?


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

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


De: santamariense 
Enviado: sexta-feira, 8 de fevereiro de 2019 11:34
Para: talk-br@openstreetmap.org
Assunto: Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em 
importação de addr:housenumber

Notou se algum campo destes pontos teria algum código que
referenciasse um logradouro ao invés de diretamente o nome do
logradouro?

> -Levantada a questão de que: "para um endereço ser localizado no OSM, precisa 
> ter ainda addr:street=*".

Eu diria que seria a melhor situação, a qual não geraria erros. Pontos
sem addr:street são associados ao logradouro mais próximo, ou seja,
nem sempre ao logradouro ao qual está registrado (como você comentou).
Em Paris por exemplo foi importado assim ( ex.:
https://www.openstreetmap.org/node/1916243227 ) com relação
type=associatedStreet. Creio que o nominatim não encontra pela
associatedStreet.

Não entendo muito. Mas não seria possível associar um logradouro
automaticamente pelo "angle" do ponto? No QGIS? Algum código? Talvez a
solução para esta questão esteja nele.

Se ninguém se dispuser a fazer esse trabalho manual, que se importe
assim mesmo. Estando no OSM a comunidade naturalmente pode ir
adicionado os dados faltantes como addr:(street/postalcode)

___
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] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[Sérgio V .]

>Notou se algum campo destes pontos teria algum código que
referenciasse um logradouro ao invés de diretamente o nome do
logradouro?

Ora:
-Cada "número" tem as suas "coordenadas";
-E no OSM tem as "ruas" já mapeadas, na frente (perto) destas coordenadas.
Isto não basta pra localizar "rua"e "número"?
Consigo pensar numa lógica simples:
1) abre-se o o aplicativo;
2) escreve a procura por: "rua tal", "numero tal";
3) ele localiza a rua;
4) ele procura dentre os nós mais próximos dela (na ordem dos mais próximos), 
aquele que tem o "numero tal".
Feito.
Os aplicativos não fazem isto? Ou querem a coisa mastigada e de graça?


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

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


De: santamariense 
Enviado: sexta-feira, 8 de fevereiro de 2019 11:34
Para: talk-br@openstreetmap.org
Assunto: Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em 
importação de addr:housenumber

Notou se algum campo destes pontos teria algum código que
referenciasse um logradouro ao invés de diretamente o nome do
logradouro?

> -Levantada a questão de que: "para um endereço ser localizado no OSM, precisa 
> ter ainda addr:street=*".

Eu diria que seria a melhor situação, a qual não geraria erros. Pontos
sem addr:street são associados ao logradouro mais próximo, ou seja,
nem sempre ao logradouro ao qual está registrado (como você comentou).
Em Paris por exemplo foi importado assim ( ex.:
https://www.openstreetmap.org/node/1916243227 ) com relação
type=associatedStreet. Creio que o nominatim não encontra pela
associatedStreet.

Não entendo muito. Mas não seria possível associar um logradouro
automaticamente pelo "angle" do ponto? No QGIS? Algum código? Talvez a
solução para esta questão esteja nele.

Se ninguém se dispuser a fazer esse trabalho manual, que se importe
assim mesmo. Estando no OSM a comunidade naturalmente pode ir
adicionado os dados faltantes como addr:(street/postalcode)

___
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] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[Sérgio V .]

De: Nelson A. de Oliveira 
Enviado: sexta-feira, 8 de fevereiro de 2019 10:38

>É o que também indicam...

Hum...São definições contraditórias:
-uma diz que "um programa pode" assumir o nome da rua mais próxima;
-outra que "deve" estar em "associatedStreet relation".

Afinal, qual diz o que efetivamente é necessário?

Aí nestes casos surge a dúvida evidente: quem definiu assim, diferente? E por 
quê?
Me parece que a definição parte mais de quem tem interesse no benefício do uso 
do resultado do trabalho todo feito,
do que de quem tem que realizar o trabalho.

>* a proposta original de endereçamento...
>...If not given a program may assume the name of the nearest street it can 
>find,
>but this is **not easy or fast to do** in all cases 

..."Nem todos os casos" é fácil para o aplicativo fazer
Quer dizer: em "muitos outros casos" seria "fácil" para o aplicativo fazer? 
Deduz-se que sim.
E ainda, seja fácil ou difícil, sempre seria "possível" de o aplicativo fazê-lo.
Ora, se pode, e não o faz, está transferindo aquilo que considera que "não é 
fácil" para que "nós" o façamos.


>Importação quase nunca é algo mágico, rápido e que sai sem esforço

Não considero o que tem-se até agora como feito "ainda sem esforço".
Já tem umas 60h de trabalho.

Me parece é que há um esforço "adicional", que depende de a quem caberá.

Até agora, do que entendo, é o aplicativo, este sim, que vai se beneficiar "sem 
esforço" nesta parte,
ganhar dados a mais de graça, como "mágica", para fazer a navegação de modo 
mais "fácil" e "rápido"...
...e ainda ganhar dinheiro com isso.



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

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 a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[Sérgio V .]

Trago aqui questão levantada,
da necessidade (ou não) de ter addr:street:
https://wiki.openstreetmap.org/wiki/Talk:Pt:Import/Catalogue/Brazil_PMPA_Addresses_Import

(esta questão é muito importante para esta e quaisquer outras importações do 
tipo de "endereços")

-Levantada a questão de que:
"para um endereço ser localizado no OSM, precisa ter ainda addr:street=*".

-Problema:
Nos dados originais não tem registrado nome da rua.
O que pode ser obtido do original é: addr:housenumber=* + coordenadas.

Necessidade (teórica ou real?): teria que complementar (adicionar) 
addr:street=* para todos os 200.000 nós. (?!?)

Dúvidas: Isso vale para qualquer endereço, para que possa ser localizado?

Possibilidades de executar:
a) automatizado: gerando e adicionando valores de "nome de rua" por análise de 
proximidade aos pontos: pode gerar erros;
b) manualmente: adicionando valores de "nome de rua" (preciso).

Objeções:

-É possível "retornar" o "nome de rua" por busca? Como com análise de 
proximidade? Os aplicativos podem operar assim? Isso não pode deixar para ser 
feito pelos aplicativos de localização/navegação, sob demanda? Se isso for 
possível, não necessitaria adicionar valor de "nome de rua", nem manualmente, 
nem automatizadamente. Simplesmente não adicionar addr:street.

-Se for real a "necessidade indispensável" de ter que constar ou "adicionar" 
addr:street=* a cada nó importado de addr:housenumber=* (mesmo onde não haja no 
original), então vai certamente inviabilizar inúmeras possibilidades de 
importações de endereços.

-Se tiver que adicionar, sobretudo "manualmente": trabalho gigantesco - 
esqueça-se, eu não faço; outros se quiserem peguem os dados ali 
disponibilizados e continuem.
De todo modo, certamente inviabiliza maior parte de futuras importações em 
outros locais.


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

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 de endereços SMF/PMPA

[Sérgio V .]

Prezados/as,

Envio aqui para avaliação da comunidade a documentação formalizada da
Proposta de "Importação da camada de numeração de endereços da PMPA",
conforme dados disponibilizados pela SMF/PMPA (Secretaria da Fazenda/Prefeitura 
Municipal de Porto Alegre).

A proposta integral está documentada na seguinte página wiki, para avaliação:
https://wiki.openstreetmap.org/wiki/Pt:Import/Catalogue/Brazil_PMPA_Addresses_Import

Contém:
-descrição da proposta;
-documentação legal;
-descrição dos procedimentos de exame, conversão, separação de conflitos 
encontrados, validação do material para importação;
-listagem do material finalizado, preparado para importação;
-links (ao final da página), para baixar os arquivos, para exames:
1) ZIP com os arquivos dos resultados finais em .osm 
(SMF-RESULTADOS-FINAIS-OSM.zip 4,6MB), contendo:
-OBJETOS VALIDADOS, preparados para importação:
   05 arquivos .osm  =  199.614 objetos (nós)
-OBJETOS REMOVIDOS, com quaisquer conflitos, separados para avaliação 
caso-a-caso:
   03 arquivos .osm  = 6.444  objetos (nós)
Total de objetos em .osm = 206.058
2) ZIP com os arquivos dos dados integrais originais (SMF-XLSX-ORIGINAIS.zip 
55MB) ;  total original = 206.061 objetos
(03 objetos destes 206.061 originais foram excluídos de início, cf. 
documentado na wiki: 01 objeto não importado por coordenada inválida, e 02 
objetos removidos de início por campos nulo e inválido.)

Apresento para avaliação da comunidade. A proposta pode ser alterada se 
necessário.

(comentários podem ser na página de discussão da mesma wiki:
https://wiki.openstreetmap.org/wiki/Talk:Pt:Import/Catalogue/Brazil_PMPA_Addresses_Import
 )

Creio que a importação pode suceder em cerca de 05 changesets para os 
validados. Ao menos estes 199.614 objetos validados (em 05 arquivos .osm) estão 
a princípio prontos para importação imediata ao OSM, em sendo aprovada a 
proposta.
Os demais 6.444 separados por não validação necessitam de avaliação 
caso-a-caso, por conflitos diversos entre si e com o existente no OSM.

Peço considerar um prazo inicial proposto de 2 semanas a partir da presente 
data para avaliações e considerações.
Após o que, se não houver outras considerações ou alterações necessárias, 
propõe-se considerar apto à importação o material indicado como validado.

Atenciosamente e à disposição,


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

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] Obtida numeração predial da Prefeitura de Porto Alegre

[Sérgio V .]

De: Fernando Trebien 
Enviado: quinta-feira, 31 de janeiro de 2019 11:51
Para: OpenStreetMap no Brasil
Assunto: Re: [Talk-br] Obtida numeração predial da Prefeitura de Porto Alegre

Legal. O DataPoa já disponibilizava o endereço inicial e final de cada
quadra, com o qual poderíamos importar os endereços na forma de
interpoladores. Com este conjunto, talvez possamos importar cada
endereço individual. Uma pena os dados estarem num formato
proprietário (MDB), mas acho que podemos contornar isso. Eu gostaria
de olhar esses dados para ver que qualidade têm e se têm problemas,
onde podem ser baixados? É interessante saber ao menos como estão
posicionados os endereços em relação aos lotes. Das discussões sobre a
importação dos endereços em Curitiba [1] me parece comum que sejam
colocados no centróide dos lotes, embora o consenso é de que devem ser
movidos para a face deles [2].

**O link não tá publico, foi disponibilizado ao email cadastrado no processo.

A maioria dos conjuntos de dados de endereços que vi até hoje costumam
ter problemas de precisão, ou de cadastro (nomes de ruas erradas ou
nomes antigos). No segundo caso, uma importação pelo JOSM deve
apresentar erros de validação. Acho que faria sentido sanar esses
problemas antes de inserir os dados no mapa.

**Calma, não vai pro OSM ainda. Tou examinando, como falei.
Todo mundo vai poder ver antes de ir pro OSM.

Esses sistemas de coordenadas obscuros (nacionais, que não estão
disponíveis nas ferramentas livres) também merecem ser melhor
documentados para que qualquer um possa verificar a conversão para um
sistema amplamente usado internacionalmente. Acho que o que você chama
de CRS TMPOA deve ser o mesmo que a lei chama de SCR-POA [3].

**Isso, a lei chama assim. Mas não quer dizer que eu chamo errado, rsrs.
A prefeitura usa, englobando nisso a Projeção "Transversa de Mercator para 
Porto Alegre (TM-POA)":
Ítem 4.3 em https://drive.google.com/file/d/0B_23OQou8LVVS1d6SG5tY2xiems/view
(de http://www2.portoalegre.rs.gov.br/spm/default.php?p_secao=345)
"a partir da publicação do Decreto n° 18.315 a PMPA passa a adotar o Sistema 
Cartográfico de Referência definido pelo sistema geodésico de referência 
SIRGAS2000 e projeção cartográfica TM-POA"
Justamente para adaptar melhor ao sistema amplamente usado internacionalmente, 
como o SIRGAS2000 o é em relação a WGS84, apenas usando um projeção TM adequada 
a PoA.
Também como no material em Shapefile da PMPA: EDIFICACOES_TM-POA.shp.
Já vem assim pra configurar CRS completa, como no QGIS. Por isso CRS=TMPOA. Por 
praticidade.
(fecho minha sessão pedantismo, rsrs)

[1] https://lists.openstreetmap.org/pipermail/talk-br/2018-November/012460.html
[2] https://wiki.openstreetmap.org/wiki/Pt:Curitiba/Importa%C3%A7%C3%A3o_IPPUC
[3] 
https://leismunicipais.com.br/a/rs/p/porto-alegre/decreto/2013/1831/18315/decreto-n-18315-2013-institui-o-sistema-cartografico-de-referencia-de-porto-alegre-scr-poa





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

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




On Wed, Jan 30, 2019 at 11:47 AM Sérgio V.  wrote:
>
> Prezados/as,
>
> Agradecendo inicialmente sobretudo ao Thierry Jean, que pelos contatos em 
> eventos conseguiu indicar as pessoas responsáveis nos órgãos públicos, aqui 
> no caso no setor de Coordenação de Geoprocessamento, da Secretaria Municipal 
> da Fazenda / Prefeitura Municipal de Porto Alegre.
> Ajudam muito estes contatos para auxiliar aos respectivos organismos 
> conhecerem a utilidade e importância de disponibilizarem os dados ao OSM, bem 
> como auxiliar a nós demais membros da comunidade no caminho dos processos 
> para obtê-los efetivamente, nas variadas dimensões de colaboração ao OSM.
>
> Sendo assim, conforme indicado, protocolei em 09/01/2019 abertura de Processo 
> Administrativo comum, como pessoa física, na Prefeitura Municipal de Porto 
> Alegre.
> Em despacho final hoje 30/01/2019 (20 dias ao todo), a Prefeitura autorizou o 
> uso do material nas condições requeridas do OSM, e liberou o material para 
> download com link temporário no processo.
> Baixado o material. Veio compactado em .7z 88,0MB.
> Descompactado, são 515 MB em 01 arquivo .mdb, contendo 16 planilhas.
> Pelo que vi inicialmente, georreferenciadas em coordenadas UTM metros (deve 
> estar em CRS TMPOA, padrão da Prefeitura de Porto Alegre dentro do sistema 
> SIRGAS2000).
> A examinar mais.
>
> Próximos passos são, a princípio:
> -examinar e organizar o material, preparando em proposta de importação 
> segundo padrões do OSM;
> -realizar os testes necessários e examinar compatibilização com o existente 
> no OSM;
> -abrir uma página wiki própria (sugestão de nome e indexação?) contendo a 
> documentação com comprovação de liberação da Prefeitura, e demais descrições 
> técnicas do material e da proposta de importação, pubicando assim para 
> apreciação da comunidade OSM no Brasil;
&

[Talk-br] Obtida numeração predial da Prefeitura de Porto Alegre

[Sérgio V .]

Prezados/as,

Agradecendo inicialmente sobretudo ao Thierry Jean, que pelos contatos em 
eventos conseguiu indicar as pessoas responsáveis nos órgãos públicos, aqui no 
caso no setor de Coordenação de Geoprocessamento, da Secretaria Municipal da 
Fazenda / Prefeitura Municipal de Porto Alegre.
Ajudam muito estes contatos para auxiliar aos respectivos organismos conhecerem 
a utilidade e importância de disponibilizarem os dados ao OSM, bem como 
auxiliar a nós demais membros da comunidade no caminho dos processos para 
obtê-los efetivamente, nas variadas dimensões de colaboração ao OSM.

Sendo assim, conforme indicado, protocolei em 09/01/2019 abertura de Processo 
Administrativo comum, como pessoa física, na Prefeitura Municipal de Porto 
Alegre.
Em despacho final hoje 30/01/2019 (20 dias ao todo), a Prefeitura autorizou o 
uso do material nas condições requeridas do OSM, e liberou o material para 
download com link temporário no processo.
Baixado o material. Veio compactado em .7z 88,0MB.
Descompactado, são 515 MB em 01 arquivo .mdb, contendo 16 planilhas.
Pelo que vi inicialmente, georreferenciadas em coordenadas UTM metros (deve 
estar em CRS TMPOA, padrão da Prefeitura de Porto Alegre dentro do sistema 
SIRGAS2000).
A examinar mais.

Próximos passos são, a princípio:
-examinar e organizar o material, preparando em proposta de importação segundo 
padrões do OSM;
-realizar os testes necessários e examinar compatibilização com o existente no 
OSM;
-abrir uma página wiki própria (sugestão de nome e indexação?) contendo a 
documentação com comprovação de liberação da Prefeitura, e demais descrições 
técnicas do material e da proposta de importação, pubicando assim para 
apreciação da comunidade OSM no Brasil;
-obter aprovação formal da comunidade OSM no Brasil;
-proceder à execução da importação;
-eventuais outras etapas que se mostrarem necessárias.


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

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] Importação de shapefiles da PBH

[Sérgio V .]

Bom dia Alexandre.
Algumas considerações que creio podem ajudar:
1- nas fotos seria útil manter a escala gráfica do JOSM, para poder avaliar o 
quanto é a diferença; não me pareceu muito mais desalinhadas do que o comumente 
observado em outros materiais de OSM e prefeituras; sempre existe algum 
desalinhamento entre materiais de fontes diversas, feitos sobre imagens 
diversas;
2-o fato de ser WGS84 no OSM e SIRGAS2000 na prefeitura não deve ser em si 
causa de alguma diferença, pois ambos são praticamente idênticos, o SIRGAS2000 
foi uma padronização para ajustar ao padrão WGS84; a causa principal de 
diferenças costuma ser o fato de que o que é mapeado no OSM é sobretudo sobre 
imagens (como BING principalmente), estas sim podem ter desalinhamentos, 
sobretudo no passado;
3-para saber qual dos 2 está mais alinhado, a melhor forma é comparar com 
traçados de GPS, ou com elementos de coordenadas exatas, como marcos geodésicos 
que possam ser visíveis em imagens. Com os GPS do OSM pode fazer no JOSM mesmo.
4-como exemplo, em Porto Alegre quando importei os prédios da prefeitura em 
2016, verifiquei um deslocamento médio de 6m para NE, um pouco variável em 
regiões diversas do município; confirmou comparando com os marcos geodésicos 
visíveis de coordenadas exatas oficiais; aí procedi com um realinhamento manual 
da cidade, rua por rua, onde mais necessário; sem ainda importar os prédios; 
deslocamentos menores que 50% da largura da rua não são muito significativos 
(se a rua tem 8m, 4m de deslocamento do eixo permanece dentro);
5-importante é não ter vias cortando outras coisas, como prédios.
Att.,


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

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


De: Alexandre Oliveira 
Enviado: quarta-feira, 30 de janeiro de 2019 02:31
Para: talk-br
Assunto: [Talk-br] Importação de shapefiles da PBH

Bom dia (ou boa noite?),

Estava fuçando o site da prefeitura de Belo Horizonte procurando mapas
e outras coisas que poderiam auxiliar no mapeamento da cidade e
descobri que existem camadas georreferenciadas disponíveis no site
deles.

Baixei as camadas e abri no JOSM. Percebi, comparando a região do
bairro Pampulha, que há um desalinhamento entre os dados do OSM e da
PBH, conforme escrito na wiki[1].

Procurei e achei um link[2] de uma discussão na lista em inglês do OSM
de alguém com o mesmo problema de desalinhamento, e o que o pessoal
recomendou pra ele foi uma linha de código para ser passada ao ogr2osm
para fazer a correção necessária.

Porém, ao consultar a wiki[3], descobri que o formato utilizado pelo
OSM (WGS84) é praticamente o mesmo utilizado nas camadas da PBH, que
são SIRGAS2000. Só que não é o que eu vi ao importar as camadas no
JOSM([4] e [5]).

Alguém tem alguma ideia do que pode ser feito? Até agora percebi que
tem algumas delimitações de bairros desalinhadas e as vias estão
desalinhadas também.

[1] 
https://wiki.openstreetmap.org/wiki/Importa%C3%A7%C3%A3o_de_endere%C3%A7os_do_Brasil
[2] https://lists.openstreetmap.org/pipermail/talk/2010-May/050065.html
[3] 
https://wiki.openstreetmap.org/wiki/Importa%C3%A7%C3%A3o_das_Redes_Geod%C3%A9sicas_do_IBGE
"Sobre as referências (CRS) dos dados do IBGE"
[4] https://i.imgur.com/XoSqalT.png
[5] https://i.imgur.com/bOYGN8G.png (o traço cinza é o da camada da PBH)

___
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: [OSM-talk] Can we use PLOS materials?

[Sérgio V .]

>Please see https://blog.openstreetmap.org/2017/03/17/use-of-cc-by-data/
>...
>Simon

Ok, so not compatible, clarified, thanks


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

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

[OSM-talk] Can we use PLOS materials?

[Sérgio V .]

Hi, please, just to confirm if yes or no:
The Scientific journal PLOS is told Open Access, as they say:
"REPRODUCTION OF ARTICLES - Articles and **accompanying materials** published 
by PLOS on the PLOS Sites, unless otherwise indicated, are licensed by the 
respective authors of such articles for use and distribution by you subject to 
citation of the original source in accordance with the Creative Commons 
Attribution (CC BY) license" (https://www.plos.org/terms-of-use).
According to
https://wiki.openstreetmap.org/wiki/Category:Licenses_compatible_for_OSM_data_imports
CC BY is compatible with OSM requirements.
So, if following those quoted conditions, can we use those **accompanying 
materials** (like some SHP of interesting places) to import to OSM according to 
their licence?
Thanks for more info.


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

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

Re: [OSM-talk] OSM Alexa Traffic Rank

[Sérgio V .]

Ah ok, thank you for both tips. Fortunately I was not phished to install 
anything from that site.
Anyway, even if it could be an aleatory coincidence, it seems there's actually 
some decrease in editons in recent months,
according to https://wiki.openstreetmap.org/wiki/Stats
Active new and old contributors per year: 
https://wiki.openstreetmap.org/wiki/File:Active_contributors_year.png
mostly about new contributors.
So guess the same might be fairly expected for general counting of site 
visitors.


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

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

[OSM-talk] OSM Alexa Traffic Rank

[Sérgio V .]

According to "Alexa Traffic Rank":
"The rank [of openstreetmap.org] declined 517 positions versus the previous 3 
months".
Global Rank: 7,069
https://www.alexa.com/siteinfo/openstreetmap.org
("The rank is calculated using a combination of average daily visitors to this 
site and pageviews on this site over the past 3 months".)
Use OSM.
Spread OSM.


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

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

Re: [OSM-talk] Licence for Sentinel Satellite images

[Sérgio V .]

>This has been discussed before, see:
>https://wiki.openstreetmap.org/wiki/Contributors#EU_Copernicus_.28GMES.29_data
>...
>Christoph Hormann

Thanks Christoph,
So I should understand this as Copernicus Sentinel Data confirmed for use in 
OSM, since it is officially in the list of data contributors.
(BTW, sorry for typo in title, "License")


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

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

[OSM-talk] Licence for Sentinel Satellite images

[Sérgio V .]

Hi,
please, could the OSM Data or License Working Group confirm if:

it's ok to use Sentinel Satellite data 
(https://wiki.openstreetmap.org/wiki/Sentinel-2) "as background for tracing or 
any other purpose for OSM"?

As it is refered in
https://wiki.openstreetmap.org/wiki/Sentinel-2#Usage
to https://wiki.openstreetmap.org/wiki/User:Ff5722/Using_Sentinel-2_imagery
"Sentinel-2 satellite data is licenced suitably to be used as background for 
tracing or any other purpose for OSM"
that refers to:
https://sentinel.esa.int/documents/247904/690755/Sentinel_Data_Legal_Notice

If ok, would it be enough referencing it's use in the source of the changeset 
comment?
Like "source:image=Sentinel..."

It would be usefull for tracing updated landcover, large areas or large roads. 
It's almost daily updated.
Not usefull for small scale detailed mapping, since it's limited to 10m/px.

Thank you in advance,


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

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

[OSM-talk] sentinel-hub playground

[Sérgio V .]

Hi, just for sharing:
Sentinel has a nice online resource that may help in many situations to find 
very recent images, for roads, dams, landcover, etc (max resolution 10m/px):
https://apps.sentinel-hub.com/sentinel-playground/
We can select by date and cloud coverage for natural color image (and other 
composites).

As quoted from links below, 
"Sentinel-2 satellite data is licenced 
suitably to be used as background for tracing or any other purpose for OSM..."
https://wiki.openstreetmap.org/wiki/Sentinel-2
https://wiki.openstreetmap.org/wiki/User:Ff5722/Using_Sentinel-2_imagery


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

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

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

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] 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] 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] 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] 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] Vetorização de matas no OSM com Sentinel-2

[Sérgio V .]

Ok, vou 1o. listar e traduzir os passos do método pra ver como fazer no QGIS 
como vc indicou. Vou procurar focar em 2 variáveis, B11 x NDVI (ou B11 e EVI2), 
acho que simplifica e basta por EVI e NDVI serem muito parecidos.

Esta semana vai me apertar o trabalho, então acho que só vou poder executar na 
semana que vem. Vou demorar um pouco pra trazer mais resultados.

Obrigado por enquanto, ótimas orientações suas! Acho que podemos chegar a um 
método viável pra aplicar em matas em qualquer lugar, potencializar o 
mapeamento de matas no Brasil todo.


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

De: Paulo Carvalho 
Enviado: domingo, 16 de setembro de 2018 18:39:30
Para: OSM talk-br
Assunto: Re: [Talk-br] Vetorização de matas no OSM com Sentinel-2

Oi, tinha um erro na minha descrição do procedimento MDS:

3) Computar a matriz B, cujos elementos bij = -1/2 * ( dij^2 - di.^2 - d.j^2 + 
d..^2 ), onde (esqueci do sinal de menos antes do 1/2)
bij = elemento da matriz B
dij = elemento da matriz de dessemelhanças
di.^2 = média dos elementos do i-ésimo vetor-linha (linha de uma matriz) da 
matriz de dessemelhanças multiplicada por ela mesma (D^2 = D*D).
d.j^2 = média dos elementos do j-ésimo vetor-coluna (coluna de uma matriz) da 
matriz de dessemelhanças multiplicada por ela mesma
d..^2 = média de todos os elementos da matriz de dessemelhanças multiplicada 
por ela mesma

Caso queiras conferir, ver toda a teoria de MDS aqui: 
http://polisci.msu.edu/jacoby/research/scaling/intromds/Jacoby-Ciuk,%20MDS,%20V2,%2010-29-14.pdf

Em dom, 16 de set de 2018 às 17:53, Paulo Carvalho 
mailto:paulo.r.m.carva...@gmail.com>> escreveu:
Oi, o método MDS pode ser implementado como um script em Python (acedito que o 
QGis tenha um console Python) caso o QGis não tenha MDS diretamente.  Se 
tiveres o SciPy e o NumPy disponíveis no console do QGis, é viável fazer no 
Python (teste com os comandos import scipy e import numpy).  Quanto aos 
múltiplos crossplots com os possíveis pares de variáveis, muita gente faz isso 
mesmo, mas não é a mesma coisa do que uma análise conjunta.

Em dom, 16 de set de 2018 às 14:45, Sérgio V. 
mailto:svo...@hotmail.com>> escreveu:
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 
mailto:paulo.r.m.carva...@gmail.com>>
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)

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

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, 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 .]

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, obrigado, agora vendo o gráfico comecei a entender, vou testar, valeu!


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

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 isso a de filtra pelo NDVI o que não é matas. Usei 
só B11 e NDV( (B04 e B08). Não cruzei com a imagem RGB (TCI). Só usei ela pra 
observar.

Quando teu problema começa a "pedir um monte de IF's" trata-se de um problema 
de tomada de decisão de múltiplas variáveis.  Neste caso, a decisão é 
classificar cada pixel da imagem.  Se tu tentares escrever IF's dentro de IF's 
para 6 variáveis, vai complicar.  Na prática é um problema intratável 
diretamente.  Para esse tipo de problema deve-se usar um algoritmo de 
classificação desses já sugeridos.  Comece pelo crossplot B11 versus NDVI.  O 
que ele mostra?  Não tentemos abordar tudo isso de uma vez.  Baby steps...

Tinha testado o "SemiAutomaticClassificationPlugin (SCP)" 
https://github.com/semiautomaticgit/SemiAutomaticClassificationPlugin
Mas achei muito difícil, 200 páginas de manual. Não sou especialista nisto. O 
que obtive foi lendo um tanto, catando métodos, e adaptando ou inventando 
filtro conforme o necessário, como naquelas equações de ponderação, baseado em 
teste e observação dos resultados.

Do ponto de vista prático, pensava ainda no seguinte: não tenho, a princípio, a 
pretensão de mapear todo tipo de landcover. Mas quem quiser, e a comunidade 
concordar, claro. Pensei nas matas, por serem os agregados de vegetação mais 
densos, como um obstáculo geográfico; e pouco são mapeadas, ou razoavelmente 
bem, até pelo trabalho que dá, e dependendo de conhecimento nem sempre muito 
preciso. Apesar de gostar de matas, acho que são elementos acessórios no OSM. 
Ainda assim importantes de constar, como base de localização, referência 
cartográfica. Não necessitam de enorme resolução. Talvez ainda se pudesse 
baixar a resolução resultante. A ver o que vocês acham, e a comunidade. Enfim, 
tenho uma preferência pessoal por matas. Mas nada impede que um método permita 
mapear o resto. O objetivo é prático, cartografar o que seja de interesse e 
conveniente para o OSM.

Acredito sim que seria ótimo em termos de obtenção geral de informações poder 
até ampliar as classes possíveis de detectar, ou usar mais adequadamente se 
possível. É muito bem-vinda sua ideia de: "tem um ótimo potencial para criar um 
classificador automático ou supervisionado robusto e válido em qualquer lugar, 
o que reduziria MUITO a
quantidade de trabalho manual." Seria ótimo! Não entendi todos os passos que vc 
sugeriu, sou um tanto leigo no assunto quando passa para nível mais profundo. 
Vou pesquisar ainda com mais tempo o que vc falou. Se tiver uma formulação para 
indicar, os índices e métodos melhores, etc,  para possibilidades de mapeamento 
assistido, será muito bem-vinda, ótima contribuição! Penso num método que seja 
relativamente fácil. Que quem desejar se aprofundar um pouco possa fazer no OSM.

Seria bom se podermos encontrar meio para isso. Se quiser sugerir, podemos usar 
a mesma wiki para isso. Sobretudo afinamentos técnicos. O método tem objetivo 
de poder ser usado por qualquer um que tenha o interesse em se aprofundar pra 
mapear. Podemos usar a seção talk da mesma wiki, quem desejar contribuir, e ir 
afinando para imlplementar.
https://wiki.openstreetmap.org/wiki/Talk:Vetoriza%C3%A7%C3%A3o_de_matas_com_Sentinel-2
Obrigado antecipadamente pelas contribuições! Já registradas ali.

Por outro lado, a pergunta que ainda faço é: acham que o que tem ali já 
apresentaria resultado mapeável para upload ao OSM? Ainda que se possa afinar 
mais coisas.
Penso sobretudo para Mata Atlântica.
Baixar mais da atual resoluç

Re: [Talk-br] Vetorização de matas no OSM com Sentinel-2

[Sérgio V .]

Agora que li!
"The ground truth for the images was created from OpenStreetMap (OSM). The 
classes considered
in our work are (a) water, (b) farmland, (c) forest and (d) urban area."
. . .
"Utilizing OpenStreetMap, we were also able to apply these
networks for the semantic classification of Sentinel-1 and Sentinel-2 satellite 
images."
. . .
"For Sentinel images, we plan to collect a large number of images and 
corresponding
ground truth from OpenStreetMap and then train the framework with random 
initialization."

( ! ! )


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

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



De: Gerald Weber 
Enviado: quinta-feira, 13 de setembro de 2018 10:06
Para: OpenStreetMap no Brasil
Assunto: Re: [Talk-br] Vetorização de matas no OSM com Sentinel-2

Oi Sérgio

iniciativa fantástica, por acaso vi este artigo hoje:
Supervised Classification of Multisensor Remotely Sensed Images Using a Deep 
Learning Framework
http://www.mdpi.com/2072-4292/10/9/1429

talvez seja de interesse

abraço

Gerald

Obs: cirei um alerta no Google Acadêmico para me avisar sobre artigos 
científicos onde aparece a palavra "OpenStreetMap"

2018-09-12 20:40 GMT-03:00 Sérgio V. 
mailto:svo...@hotmail.com>>:

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<mailto: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] 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

[OSM-talk] Render the names of the seas

[Sérgio V .]

Ah ok, I read it, thank you


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

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


W dniu 31.07.2018 o 13:31, Sérgio V. pisze:
>..
> Why the names of the seas are not rendered? Would it be nice to have
> them rendered?

Hi,

This is probably an OSM Carto question. We have a special ticket for
this, please see the discussion there:

https://github.com/gravitystorm/openstreetmap-carto/issues/2278

In  a nutshell: one problem is with nodes vs areas, the second one is
what language should be used to display them.

--
"My method is uncertain/ It's a mess but it's working" [F. Apple]



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

[OSM-talk] Render the names of the seas

[Sérgio V .]

Hi, I realized that none of the usual OSM tile providers renders the names of 
the seas.

I was tryingh to find it out in the map, because I allways mistake e.g. Caspian 
for Black Sea and vice-versa.

Also oceans has dozens of seas.

Why the names of the seas are not rendered? Would it be nice to have them 
rendered?
Thanks,


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

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

[Diversity-talk] Diversity and Inequality, two concepts, different and related

[Sérgio V .]

Hi, just sharing few toughts,
since we talk here on "diversity", this might also bring the issue of 
"inequality".
These are similar terms, somehow conected to each other, but different concepts.
Both terms refer to the idea of "difference", "not equal". Both terms bring the 
idea of "inclusion."

"Diversity" usually refers to "the political and social policy of encouraging 
tolerance for people of different backgrounds"
(https://en.wikipedia.org/wiki/Diversity#Sociology,_politics_and_law).

Essentially, people are diverse, in any scale of groups: familiar, local, 
professional, national, global. And that's essentially good.
There's a diversity of knowledges people can contribute to the community where 
they are included.

The meaning of "inequality" takes a slightly different aproach. Usually it 
refers nowadays to economic aspects.

"Economic inequality is the difference found in various measures of economic 
well-being among individuals in a group, among groups in a population, or among 
countries." (https://en.wikipedia.org/wiki/Economic_inequality).

We realize that people are very different, not in terms of their essence, but 
in terms of their existences, that is, the material conditions for their 
existences, and that's not good.
Inequality has been increasing world around in recent years. It may be a 
barrier against a healty diversity.
Great levels of economic inequality bring many pernicious efects, such as 
ignorance, radicalism, hostilities to differents, many sorts of political 
tensions.

We can see recent reports and statistics made even by liberal organizations, 
such as Oxfam, Credite Suisse, pointing out that there is a growing gap due to 
economic inequality, showing all the negative consequences of that, and that 
there should be an active effort to mitigate such great inequality:

(2016) 
https://www.oxfam.org/sites/www.oxfam.org/files/file_attachments/bp210-economy-one-percent-tax-havens-180116-en_0.pdf

(2017) 
https://www.oxfam.org/sites/www.oxfam.org/files/file_attachments/bp-economy-for-99-percent-160117-en.pdf

(2017)  
https://www.credit-suisse.com/corporate/en/research/research-institute/global-wealth-report.html

- - - - -
(Sorry, not native english; portuguese) .
Just few thoughts. Sure there could be much more to deepen in these issues.

-Do we see any implication of the related aspects of diversity and inequality 
inside our own OSM ecosystem? Could the OSM community deal with it? How?
-Would there be something that the OSM community could do to help our world to 
achieve more diversity and less inequality?



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

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Diversity-talk mailing list
Code of Conduct: 
https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
Contact the mods (private): diversity-talk-ow...@openstreetmap.org

[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

[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 

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

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: [OSM-talk] OSM based mobile app that allows additional vector data to be loaded

[Sérgio V .]

Hi, in both Osmand and Maps.me you can load your own GPX or KML files as lines 
or points:


http://osmand.net/blog?id=osmand-1-8-released

https://wiki.openstreetmap.org/wiki/MAPS.ME


https://support.maps.me/hc/en-us/articles/207895029-How-can-I-import-bookmarks-


>I am looking for an OSM based mobile app which would allow me to load

>additional vector data (shape files, KML, geojson, etc) into it...


Regards,

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

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

Re: [OSM-talk] Strava Cycling and Running Heatmap not working

[Sérgio V .]

Perhaps due to this update?

"...we are eager to introduce new ways we are protecting that data and the 
athletes who provide it:..."

"...Roads and trails with very little activity will not show “heat” until 
several different athletes upload activities in that area..."

"The heatmap remains available to the public, but only registered Strava 
athletes may zoom in to street-level details of activity on the heatmap."

https://blog.strava.com/press/heatmap-updates/



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

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

[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] 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: [OSM-talk] The diversity-talk@ list is back! [WAS: Re: diversity-talk: No such list]

[Sérgio V .]

Hi, glad to know this, this is an important topic in OSM ecosystem, as well as 
in the world, mainly nowadays. Signed, thanks! From Brazil,

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

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



De: Rory McCann <r...@technomancy.org>
Enviado: quinta-feira, 22 de fevereiro de 2018 05:36
Para: Sérgio V.; talk@openstreetmap.org
Assunto: The diversity-talk@ list is back! [WAS: Re: diversity-talk: No such 
list]

Hello all,

I've volunteered to do the admin/modding of the diversity-talk list, so
it has been set up again.

You need to sign up again for now. Maybe it's possible to import an old
membership list, but for now, please re-sign up.

 https://lists.openstreetmap.org/listinfo/diversity-talk

Rory

On 17/02/18 20:56, Sérgio V. wrote:
> Hi, I've just realized that in the
>
> https://wiki.openstreetmap.org/wiki/Diversity
> at the bottom, /Resources,
>
> there's no such link to
>
> https://lists.openstreetmap.org/listinfo/diversity-talk
>
> If you click there , or search for it, it returns "No such list
> diversity-talk".
>
> Is it still alive?
>
>
> - - - - - - - - - - - - - - - -
>
> Sérgio - http://www.openstreetmap.org/user/smaprs
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>

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

Re: [OSM-talk] diversity-talk: No such list

[Sérgio V .]

Thanks.

What looks weirdest is that it seems it was not a "no nactive list".

The last posts were 3 months ago, 2017, not much, nor 2015.

It seems people were talking and answering each other recently there:

<https://lists.openstreetmap.org/pipermail/diversity-talk/>https://lists.openstreetmap.org/pipermail/diversity-talk/2017-October/date.html

but being the list out of

https://lists.openstreetmap.org/listinfo/diversity-talk
sadly this way it's sure other people couldn't have known.
- - - - - - - - - - - - - - - -

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



De: Martin Koppenhoefer <dieterdre...@gmail.com>
Enviado: segunda-feira, 19 de fevereiro de 2018 19:53
Para: Rory McCann
Cc: Sérgio V. ; talk@openstreetmap.org
Assunto: Re: [OSM-talk] diversity-talk: No such list



sent from a phone

> On 19. Feb 2018, at 10:47, Rory McCann <r...@technomancy.org> wrote:
>
> Shame that it's gone. It's nice to be able to contact people in OSM who
> are interested in diversity.


yes, it’s a shame.

Btw, the archive is still there, but it isn’t linked from the listinfo page 
anymore because there’s no active list. Maybe there’s a way it can be linked 
anyway? After all, it is documentation about previous activities.


Cheers,
Martin
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] diversity-talk: No such list

[Sérgio V .]

Hi, I've just realized that in the

https://wiki.openstreetmap.org/wiki/Diversity
at the bottom, /Resources,

there's no such link to

https://lists.openstreetmap.org/listinfo/diversity-talk

If you click there , or search for it, it returns "No such list diversity-talk".

Is it still alive?


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

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

[OSM-talk] Spam-bot friends

[Sérgio V .]

Thank you for cc'ing it. I didn't know of that topic.


> FYI:  https://wiki.openstreetmap.org/wiki/Spam#User_description_and_diary_spam
> I'll cc the dev list in
> Regards, Maarten

Regards.

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

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

[OSM-talk] Spam-bot friends

[Sérgio V .]

What a weird new zero edditting user added me as OSM friend. Specially 
considering this morning.

http://www.openstreetmap.org/user/StonefireArms

Don't want firearms as Christmas gift. Not much to do with OSM. I hope.

In Brazil we call such marketing advert "a shot in the foot" (sorry for the 
play with words), for its reverse efect.

Happy Christmas for those who celebrate it, happy holidays for everybody,
"on earth peace to people..."
- - - - - - - - - - - - - - - -

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

Re: [OSM-talk] no osmf-talk link at listinfo

[Sérgio V .]

Of course I understand, and support, that sending emails to OSMF-talk  is only 
to OSMF members, a non-member should not have the right to send emails to that 
list.
But readable it is; as usual in democratic institutions, where discussions can 
be listen.
So the easier it could be to find OSMF-talk to be read, by any OSMer, the 
better, the more democratic it is.
Of course, hope it keeps openly readable.
The discussions there are relevant for the rest of the OSM world. Thanks.

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

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



De: Tom Hughes <t...@compton.nu>
Enviado: terça-feira, 19 de dezembro de 2017 21:54
Para: Sérgio V.; talk@openstreetmap.org
Assunto: Re: no osmf-talk link at listinfo

On 19/12/17 22:51, Sérgio V. wrote:
>>> but I can't find the link to osmf-talk in the listinfo.
>>  I'm not sure why it wasn't listed on that page, but there is a link to
> the OSMF-talk archives from the Wiki
>
> Ok, thank you both. I've found it, as I've quoted it.
> But it's actually not easy to find like the others are, just
> by the listinfo.
> Long time it took to me to realise OSMF-talk exists. Ok, perhaps I'm not
> that wiki expert.
> But would it be nice to have it listed in listinfo? Like all the other
> mailing lists are? Easy to find, for everyone.
> Then probably more OSMers could read it; also perhaps considering join it.
> Or, at least, why isn't it listed in listinfo?

As I explained yesterday it is a private list open only to OSMF members.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] no osmf-talk link at listinfo

[Sérgio V .]

>> but I can't find the link to osmf-talk in the listinfo.
>  I'm not sure why it wasn't listed on that page, but there is a link to
the OSMF-talk archives from the Wiki

Ok, thank you both. I've found it, as I've quoted it.
But it's actually not easy to find like the others are, just by the listinfo.
Long time it took to me to realise OSMF-talk exists. Ok, perhaps I'm not that 
wiki expert.
But would it be nice to have it listed in listinfo? Like all the other mailing 
lists are? Easy to find, for everyone.
Then probably more OSMers could read it; also perhaps considering join it.
Or, at least, why isn't it listed in listinfo?

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

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

[OSM-talk] no osmf-talk link at listinfo

[Sérgio V .]

Hello,

please, one question:

Why is the link to

https://lists.openstreetmap.org/pipermail/osmf-talk/

not directly accessible by the

https://lists.openstreetmap.org/listinfo?

I've read  in http://www.weeklyosm.eu about some 
interesting discussions there,

but I can't find the link to osmf-talk in the listinfo.

I'm not questioning necessarily for subscribing it, if it's for members only, 
but I thought it was public to read since as reported to follow it, and the 
significance of the OSMF talks for the whole OSM community, including to 
consider joining as associated member, etc.

Sorry if not good english.

Thanks in advance.

>From Brazil,


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

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

[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

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] 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

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 .]

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 .]

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] 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 .]

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] 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

[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: [OSM-talk] Mystery structure on a South China Sea reef

[Sérgio V .]

It's also there with Digital Globe Premium at:
http://www.openstreetmap.org/edit#map=18/8.35838/115.23794
I bet (a beer) it's a single family's private resort:
What you see is a small bungalow with a wooden deck, a small boat 5m to 
Northeast, and two big beach umbrellas (one for the couple, the other for the 
children), like these:
The blue one:

http://www.ebay.co.uk/itm/Blue-Jumbrella-Giant-Umbrella-Parasol-5x5M-Crank-Handle-Commercial-Quality/272772644331

And the white one:

https://www.aliexpress.com/item/7-meter-Deluxe-big-patio-umbrellas/1870364994.html


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

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

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

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

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 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)

[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

[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

[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

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

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 .]

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] 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] 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] 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] 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

[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