[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

[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

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: [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

[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

[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

[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: [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 

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

[Sérgio V .]

Prezados,

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

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

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

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

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

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

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

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

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

E em verificações por amostragem, não foram encontrados objetos idênticos no 
OSM.

A proposta é também criar relação com cada um dos 6 tipos de estações, e uma 
maior geral, de modo a facilitar eventual manutenção.

As tags "description" também são propostas para identificar os grupos e poder 
recuperar os objetos quando necessário.


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


REDES GEODÉSICAS


Rede Geodésica Planimétrica:
-Rede Brasileira de Monitoramento Contínuo - GNSS Permanente: RBMCPoint.SHP / 4 
KB / OBJECTS: 129
-Estações SAT DOPPLER: BDG_DOPPoint.SHP / 28 KB / OBJECTS: 1006
-Estações SAT GPS: BDG_GPSPoint.SHP / 82 KB / OBJECTS: 2977
-Estações Poligonal: BDG_EPPoint.SHP / 32 KB / OBJECTS: 1133
-Vertices Triangulacao: BDG_VTPoint.SHP / 100 KB / OBJECTS: 3643
SUB-TOTAL Planimétrica:: 7882 OBJECTS

Rede Geodésica Altimétrica:
-Referencias de Nivel: BDG_RNPoint.SHP / 613 MB / OBJECTS: 69887

Eventualmente se pode adicionar as estações das redes Gravimétrica e 
Maregráfica (esta apenas 5 pontos).


Ainda tenho que esquematizar as tags e converter. À medida que fizer, coloco na 
wiki.

Proposta importar a rede planimétrica em 1 pacote só, e somente após toda rede 
convertida.


Quaisquer questões, podem usar também a página de discussões da wiki.


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

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

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

[Sérgio V .]

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

Tá bom assim, ok.


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

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

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

[Sérgio V .]

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

Mas tá lá.

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

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

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

[Sérgio V .]

Ok,

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


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


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

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

[Talk-br] Sobre addr:interpolation - possibilidades

[Sérgio V .]

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

Poderia ser em tópicos nesta wiki:

-metodologia proposta por santamariense;

-metodologia proposta por papibarrígafo;...

-problemas identificados;

-objeções;

-preferências da comunidade;...


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

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

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

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

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

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

Aí se enxerga a coisa.

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


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

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

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


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

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

[Talk-br] Bom Ano Novo

[Sérgio V .]

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

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

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

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

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

surgimento de novas boas ideias,

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

e tudo o mais que for bom.


Um abraço,


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

[Talk-br] PROJETO "MAPEANDO COM ESCOLAS"

[Sérgio V .]

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

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


- - - - -

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

Bom dia Gilmar,

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

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

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

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


LINKS:

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

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

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


Saudações, Sérgio.

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

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

[Talk-br] Sobre addr:interpolation - possibilidades

[Sérgio V .]

@santamariense,

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

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

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

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

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

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

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

Valeu!


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

No nosso caso, talvez primeiramente processar isoladamente o TXT:

I-

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

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

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


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


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


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

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

[Talk-br] Sobre addr:interpolation - possibilidades

[Sérgio V .]

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


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

neste arquivo Layout.zip (XML).

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

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


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


Pois há discrepâncias de fato.

No explicativo do IBGE eles reconhecem problemas de posicionamento:

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

(Ver em:

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


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

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

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


IMAGEM:

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


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

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

[Talk-br] Sobre addr:interpolation - possibilidades

[Sérgio V .]

@Marcos Fedato,

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

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

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


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

Isto talvez já facilitaria um pouco mais.

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

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

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


Valeu!

Vamos experimentando.


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

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

[Talk-br] Sobre addr:interpolation - possibilidades

[Sérgio V .]

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

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

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


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


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


TXT: (não tem coordenadas)

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

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

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

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


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


O que precisaria fazer (automatizar):

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

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

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

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

-atribuir sentido às linhas, em ordem;

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

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


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

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


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


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

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

[Talk-br] Sobre addr:interpolation - possibilidades

[Sérgio V .]

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


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

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

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

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


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

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

[Talk-br] Sobre addr:interpolation - possibilidades

[Sérgio V .]

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

Claro, isso também.

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


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

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

[Talk-br] Sobre addr:interpolation - possibilidades

[Sérgio V .]

Santamariense,

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

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

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

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

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

(parentese:

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

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

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

Variação:  de 0.007155635 a 3966.365747

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

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

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

fecha parentese ).

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

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

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

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

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


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

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

[Talk-br] Sobre addr:interpolation - possibilidades

[Sérgio V .]

Legal pessoal, ótimas ideias.


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

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

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

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

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

Valeu!

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

Vamos pensando em como preparar para implementar.


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

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

[Talk-br] Sobre addr:interpolation - possibilidades

[Sérgio V .]

Pois é, esta seria a ideia:

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


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


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

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

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

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

-evita poluição de ways;

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


Problemas eventuais (a verificar como contornar):

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

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

- - - - - - - - - -

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

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

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


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

addr:interpolation:left:odds=

addr:interpolation:right:evens=

ou

addr:interpolation:left:evens=

addr:interpolation:right:odds=

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

addr:interpolation=


Ou outra ideia melhor se tiver.


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

- - - - - - - - - -


QUANTO ÀS OBJEÇÕES:


1)Uso indiscriminado de addr:interpolation :

Obviamente não é necessário uso indiscriminado.

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


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

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

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

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

O resto é feedback e correção progressiva.


3) Endereçamentos do IBGE:

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

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

Endereços só encontrei na lista TXT em:

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

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

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

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


Mas talvez sirva pra quem pretender extrair os CEPs.


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

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

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

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


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

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

[Talk-br] Sobre addr:interpolation - possibilidades

[Sérgio V .]

#addr:interpolation

Tava pensando:

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

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

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

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

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

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

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

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

Que acham? Útil? Viável?


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

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

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

[Sérgio V .]

Sim, poderia ser.


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

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

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


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


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

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

Se acharem que ajudaria mesmo.

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

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

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

abraços,
wille


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

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

[Talk-br] Avaliar + Planejar = Agir fundamentadamente

[Sérgio V .]

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

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

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

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

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

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


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

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

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

[Sérgio V .]

GRUPOS OSM TELEGRAM: BRASIL e LATINOAMÉRICA:

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

BRASIL:

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

Comunidades regionais:

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

LATINOAMÉRICA:

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

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

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


POR FAVOR, COMPARTILHE!


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

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

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

[Sérgio V .]

Alô Mauro,

Bem vindo, considere-se retornado.

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

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


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

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

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

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

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

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

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

[Talk-br] Apresentação

[Sérgio V .]

Isaac,

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

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

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

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

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

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


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

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

Re: [Talk-br] Apresentação

[Sérgio V .]

Olá Isaac,

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


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


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

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

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


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

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

-A camada de imagem de satélite;

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


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


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


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

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


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

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


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

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

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

[Sérgio V .]

Bom dia pessoal.


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

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


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

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

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

No iD:

- Editar;

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

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


No JOSM:

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


Mais informações no wiki:

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


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


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

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

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

[Sérgio V .]

Bom dia pessoal,

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

Grato.

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

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

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

[Sérgio V .]

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

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

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


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

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

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

[Sérgio V .]

Boa noite pessoal.

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

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

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

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

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

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

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

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

O PROBLEMA QUE SE COLOCA É:

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

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

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

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

Para resolver o conflito de "Building inside building".

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

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

Saudações gerais,

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

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