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

2019-02-14 Por tôpico Fernando Trebien 
On Thu, Feb 14, 2019 at 6:03 PM Peter Krauss  wrote:
> Resumindo o que talvez seja um posicionamento pessoal, convém conferir se 
> alguém concorda:
>
> *  a métrica de erros para fazer sentido nas nossas discussões precisa ser da 
> metodologia assistida, não do algoritmo sozinho.

Sim sim. A métrica eu levantei com o objetivo de determinar quanto
trabalho manual temos pela frente, não é um critério de
aceitação/rejeição.

> * não se pode afirmar que "importação é coisa ruim", o que se pode afirmar é 
> que "a metodologia X com o algoritmo Y para os dados Z é ruim".. Até que se 
> prove o contrário.

Com certeza, nunca afirmei que importação é algo ruim.

Quanto à metodologia, eu aceito que sejam importados dados que contêm
algum problema contanto que exista um plano para tratar do problema na
sequência. O que não deve acontecer é importar dados sabendo do
problema e simplesmente ignorar o problema depois, deixando pros
outros o problema sem que os outros tenham aceito, daí acho falta de
consideração com os colegas.

-- 
Fernando Trebien

___
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

2019-02-14 Por tôpico Fernando Trebien 
É verdade, não participei desse processo e por isso nunca afirmei que
foi um erro, o que não quer dizer que não é uma "bagunça" (o termo é o
usado no wiki, até então eu estive chamando isso de "pendência"). É um
problema que ninguém abraçou, nem eu, nem você, um exemplo do que
acontece ao importar um monte de dados e deixar algo pra fazer depois
sem ter um plano de quem/quando/como resolver.

On Thu, Feb 14, 2019 at 6:06 PM Sérgio V.  wrote:
>
> 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



-- 
Fernando Trebien

___
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

2019-02-14 Por tôpico 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] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

2019-02-14 Por tôpico Peter Krauss 
(*oops* desculpem dei Enter ... pronto agora no computador tela grande)

O nó da questão, que invalidada ou não seus argumentos, e nos forçaria a
recomeçar do zero a discussão,
está na sua afirmação incompleta de que
*   "(...) constatamos que a projeção dos endereços nas ruas cerca de 5% de
endereços errados (...)"*

Exagerando, é como usar algoritmo de Bubble Sort
 para afirmar que a ordenação
por computador é coisa ruim,
ou *pegar dados sem filtrar e dizer que os dados estão ruins*...

Todo algoritmo de importação bem feitinho tem critério objetivo de
filtragem, tem um "nível de descarte" que fica meio informal na receita
complementar que chamamos de *metodologia*,  já que em geral o computador
não pode avaliar sozinho, precisa do parecer final do humano em vários
passos...
Alias podemos dizer que a *metodologia assistida é a única válida*, o
acompanhamento humano é uma é uma obrigação (*pelas normas OSM
).  *

Resumindo o que talvez seja um posicionamento pessoal, convém conferir se
alguém concorda:

*  a métrica de erros para fazer sentido nas nossas discussões precisa ser
da metodologia assistida, não do algoritmo sozinho.

* não se pode afirmar que "importação é coisa ruim", o que se pode afirmar
é que "a metodologia X com o algoritmo Y para os dados Z é ruim".. Até que
se prove o contrário.





On Thu, Feb 14, 2019 at 4:20 PM Fernando Trebien 
wrote:

> On Thu, Feb 14, 2019 at 7:55 AM Peter Krauss  wrote:
> > 2.2. Ponto oficial incompleto: pode ser importando?  Essa é a discussão.
> As fontes de informação na verdade existem, só que não é uma fonte única,
> pode estar misturando verdade de campo, norma oficial (por exemplo leis de
> nomenclatura de rua), dado oficial (ex. os pontos fornecidos pela
> prefeitura), etc. O algorítomo mesmo sendo aberto é complexo e poucas
> pessoas do OSM terão tempo e capacidade de avaliar.  ESTÁ EM DISCUSSÃO, mas
> precisamos primeiro arrumar a casa, chegar a uma descrição satisfatória no
> "ponto oficial completo" (2.1 acima).  Mesmo depois de discutir e chegar a
> um consenso aqui precisaremos verificar com restante da comunidade OSM.
> >
> > 2.2.1. Com  numeração (addr:housenumber) obtida por
> interpolação/proximidade.
>
> Acho que depende das características do dado original. Se o que ele
> tem é o endereço inicial e final de cada quadra, ou um endereço no
> meio de cada quadra, ele pode ser importado sem problema algum usando
> linhas interpoladoras, tal como se faz sem Buenos Aires e em alguns
> outras cidades do mundo, contanto que os pontos de endereço contenham
> o nome da rua. Seria indesejável interpolar o endereço gerando cada
> ponto intermediário.
>
> > 2.2.2. Com  nome de rua (addr:street) obtido por proximidade.
>
> Entre poder/não poder eu prefiro responder isso com as consequências
> pro OSM de importar com ou sem um tratamento dos problemas dessa
> abordagem.
>
> Em Porto Alegre já constatamos que a projeção dos endereços nas ruas
> para obter o nome da rua produz cerca de 5% de endereços errados, ou
> seja, 1 erro em cada 20 endereços. Um dado com tantos erros não possui
> qualidade suficiente para suportar satisfatoriamente um serviço de
> geocodificação. Se, por exemplo, alguém quiser usar o  mapa para
> oferecer um serviço de entregas ou de transporte individual, muitos
> endereços estarão a quilômetros de distância do local correto, o que
> obviamente seria bem ruim pra confiabilidade do serviço. Nesse caso,
> eu esperaria que o usuário simplesmente descartaria o OSM e adotaria
> um concorrente, como o Google Maps. Pior do que isso, se alguém quiser
> usar os endereços existentes para inserir pontos de interesse a partir
> de uma listagem local, os erros serão propagados e a correção exigirá
> mais esforço (talvez o dobro) do que se tivesse sido feita antes.
>
> Mesmo numa cidade do tamanho de Porto Alegre, a solução manual desses
> problemas exigiria um trabalho contínuo de ~2 semanas eu acho. Vale a
> pena considerando o benefício. Na maioria dos municípios (em geral
> pequenos) um trabalho desse tipo poderia ser feito completamente em
> poucas horas.
>
> Onde não houver mão-de-obra disposta a realizar a correção, acho que é
> fundamental no mínimo documentar (de preferência no wiki) que ficou
> pendente de correção, do contrário ninguém vai saber onde procurar os
> erros. Idealmente seria aberta também uma tarefa em algum sistema de
> gestão de tarefas para orientar e monitorar esse trabalho. Agora que
> temos o Kaart interessado em nos ajudar, podemos também tentar um
> contato com eles para que realizem as correções manualmente. Se este
> caso surgir com frequência em municípios diferentes, acho que vale a
> pena organizar um grupo de trabalho para fazer as correções manuais.
> Um grupo especializado assim estaria familiarizado com o tipo de erro
> desse processo e poderia trabalhar rápido e com menos erros humanos.
>
> Caso a etapa de documentar a

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

2019-02-14 Por tôpico Peter Krauss 
O nó da questão, que invalidada ou não seus argumentos, e nos forçaria a
recomeçar do zero a discussão,
está na sua falsa afirmação de que *"Em Porto Alegre já constatamos que a
projeção dos endereços nas ruas*
*para obter o nome da rua produz cerca de 5% de endereços errados"*

On Thu, Feb 14, 2019 at 4:20 PM Fernando Trebien 
wrote:

> On Thu, Feb 14, 2019 at 7:55 AM Peter Krauss  wrote:
> > 2.2. Ponto oficial incompleto: pode ser importando?  Essa é a discussão.
> As fontes de informação na verdade existem, só que não é uma fonte única,
> pode estar misturando verdade de campo, norma oficial (por exemplo leis de
> nomenclatura de rua), dado oficial (ex. os pontos fornecidos pela
> prefeitura), etc. O algorítomo mesmo sendo aberto é complexo e poucas
> pessoas do OSM terão tempo e capacidade de avaliar.  ESTÁ EM DISCUSSÃO, mas
> precisamos primeiro arrumar a casa, chegar a uma descrição satisfatória no
> "ponto oficial completo" (2.1 acima).  Mesmo depois de discutir e chegar a
> um consenso aqui precisaremos verificar com restante da comunidade OSM.
> >
> > 2.2.1. Com  numeração (addr:housenumber) obtida por
> interpolação/proximidade.
>
> Acho que depende das características do dado original. Se o que ele
> tem é o endereço inicial e final de cada quadra, ou um endereço no
> meio de cada quadra, ele pode ser importado sem problema algum usando
> linhas interpoladoras, tal como se faz sem Buenos Aires e em alguns
> outras cidades do mundo, contanto que os pontos de endereço contenham
> o nome da rua. Seria indesejável interpolar o endereço gerando cada
> ponto intermediário.
>
> > 2.2.2. Com  nome de rua (addr:street) obtido por proximidade.
>
> Entre poder/não poder eu prefiro responder isso com as consequências
> pro OSM de importar com ou sem um tratamento dos problemas dessa
> abordagem.
>
> Em Porto Alegre já constatamos que a projeção dos endereços nas ruas
> para obter o nome da rua produz cerca de 5% de endereços errados, ou
> seja, 1 erro em cada 20 endereços. Um dado com tantos erros não possui
> qualidade suficiente para suportar satisfatoriamente um serviço de
> geocodificação. Se, por exemplo, alguém quiser usar o  mapa para
> oferecer um serviço de entregas ou de transporte individual, muitos
> endereços estarão a quilômetros de distância do local correto, o que
> obviamente seria bem ruim pra confiabilidade do serviço. Nesse caso,
> eu esperaria que o usuário simplesmente descartaria o OSM e adotaria
> um concorrente, como o Google Maps. Pior do que isso, se alguém quiser
> usar os endereços existentes para inserir pontos de interesse a partir
> de uma listagem local, os erros serão propagados e a correção exigirá
> mais esforço (talvez o dobro) do que se tivesse sido feita antes.
>
> Mesmo numa cidade do tamanho de Porto Alegre, a solução manual desses
> problemas exigiria um trabalho contínuo de ~2 semanas eu acho. Vale a
> pena considerando o benefício. Na maioria dos municípios (em geral
> pequenos) um trabalho desse tipo poderia ser feito completamente em
> poucas horas.
>
> Onde não houver mão-de-obra disposta a realizar a correção, acho que é
> fundamental no mínimo documentar (de preferência no wiki) que ficou
> pendente de correção, do contrário ninguém vai saber onde procurar os
> erros. Idealmente seria aberta também uma tarefa em algum sistema de
> gestão de tarefas para orientar e monitorar esse trabalho. Agora que
> temos o Kaart interessado em nos ajudar, podemos também tentar um
> contato com eles para que realizem as correções manualmente. Se este
> caso surgir com frequência em municípios diferentes, acho que vale a
> pena organizar um grupo de trabalho para fazer as correções manuais.
> Um grupo especializado assim estaria familiarizado com o tipo de erro
> desse processo e poderia trabalhar rápido e com menos erros humanos.
>
> Caso a etapa de documentar a correção não for feita, o resultado mais
> provável é que os erros permanecerão no mapa por um bom tempo e que
> serão esquecidos, prejudicando a confiabilidade dos dados. 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."
>
> Não estou dizendo que é obrigação de quem importa fazer a correção
> manual. O importante é traçar um plano de correção e engajar as
> pessoas que o executarão, e havendo interessados em fazer isso antes
> mesmo da importação, melhor ainda. Como você pode ver lá na discussão
> de Porto Alegre, há também questões relativas à limpeza de dados
> existentes.
>
> > O que acha?  Podemos seguir com essa terminologia? importação de "ponto
> invalido" (obviamente

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

2019-02-14 Por tôpico Fernando Trebien 
On Thu, Feb 14, 2019 at 7:55 AM Peter Krauss  wrote:
> 2.2. Ponto oficial incompleto: pode ser importando?  Essa é a discussão. As 
> fontes de informação na verdade existem, só que não é uma fonte única, pode 
> estar misturando verdade de campo, norma oficial (por exemplo leis de 
> nomenclatura de rua), dado oficial (ex. os pontos fornecidos pela 
> prefeitura), etc. O algorítomo mesmo sendo aberto é complexo e poucas pessoas 
> do OSM terão tempo e capacidade de avaliar.  ESTÁ EM DISCUSSÃO, mas 
> precisamos primeiro arrumar a casa, chegar a uma descrição satisfatória no 
> "ponto oficial completo" (2.1 acima).  Mesmo depois de discutir e chegar a um 
> consenso aqui precisaremos verificar com restante da comunidade OSM.
>
> 2.2.1. Com  numeração (addr:housenumber) obtida por interpolação/proximidade.

Acho que depende das características do dado original. Se o que ele
tem é o endereço inicial e final de cada quadra, ou um endereço no
meio de cada quadra, ele pode ser importado sem problema algum usando
linhas interpoladoras, tal como se faz sem Buenos Aires e em alguns
outras cidades do mundo, contanto que os pontos de endereço contenham
o nome da rua. Seria indesejável interpolar o endereço gerando cada
ponto intermediário.

> 2.2.2. Com  nome de rua (addr:street) obtido por proximidade.

Entre poder/não poder eu prefiro responder isso com as consequências
pro OSM de importar com ou sem um tratamento dos problemas dessa
abordagem.

Em Porto Alegre já constatamos que a projeção dos endereços nas ruas
para obter o nome da rua produz cerca de 5% de endereços errados, ou
seja, 1 erro em cada 20 endereços. Um dado com tantos erros não possui
qualidade suficiente para suportar satisfatoriamente um serviço de
geocodificação. Se, por exemplo, alguém quiser usar o  mapa para
oferecer um serviço de entregas ou de transporte individual, muitos
endereços estarão a quilômetros de distância do local correto, o que
obviamente seria bem ruim pra confiabilidade do serviço. Nesse caso,
eu esperaria que o usuário simplesmente descartaria o OSM e adotaria
um concorrente, como o Google Maps. Pior do que isso, se alguém quiser
usar os endereços existentes para inserir pontos de interesse a partir
de uma listagem local, os erros serão propagados e a correção exigirá
mais esforço (talvez o dobro) do que se tivesse sido feita antes.

Mesmo numa cidade do tamanho de Porto Alegre, a solução manual desses
problemas exigiria um trabalho contínuo de ~2 semanas eu acho. Vale a
pena considerando o benefício. Na maioria dos municípios (em geral
pequenos) um trabalho desse tipo poderia ser feito completamente em
poucas horas.

Onde não houver mão-de-obra disposta a realizar a correção, acho que é
fundamental no mínimo documentar (de preferência no wiki) que ficou
pendente de correção, do contrário ninguém vai saber onde procurar os
erros. Idealmente seria aberta também uma tarefa em algum sistema de
gestão de tarefas para orientar e monitorar esse trabalho. Agora que
temos o Kaart interessado em nos ajudar, podemos também tentar um
contato com eles para que realizem as correções manualmente. Se este
caso surgir com frequência em municípios diferentes, acho que vale a
pena organizar um grupo de trabalho para fazer as correções manuais.
Um grupo especializado assim estaria familiarizado com o tipo de erro
desse processo e poderia trabalhar rápido e com menos erros humanos.

Caso a etapa de documentar a correção não for feita, o resultado mais
provável é que os erros permanecerão no mapa por um bom tempo e que
serão esquecidos, prejudicando a confiabilidade dos dados. 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."

Não estou dizendo que é obrigação de quem importa fazer a correção
manual. O importante é traçar um plano de correção e engajar as
pessoas que o executarão, e havendo interessados em fazer isso antes
mesmo da importação, melhor ainda. Como você pode ver lá na discussão
de Porto Alegre, há também questões relativas à limpeza de dados
existentes.

> O que acha?  Podemos seguir com essa terminologia? importação de "ponto 
> invalido" (obviamente invalida), de "ponto oficial completo" e de "ponto 
> oficial incompleto".

Eu chamaria isso de um endereço incompleto/insuficiente, não de
inválido. O que realmente é inválido (em ~5% dos casos) é a heurística
de projetar o endereço sobre a rua mais próxima, seja ela feita antes
da importação ou feita pelo geocodificador caso a addr:street esteja
faltando no endereço.

-- 
Fernando Trebien

___
Talk-br mailing list

[Talk-br] Parceria com PRODABEL / Prefeitura de Belo Horizonte

2019-02-14 Por tôpico Thierry Jean 
Caros,

Vejam a excelente resposta que recebemos da prefeitura de BH. Vou organizar um 
call para depois do dia 25, via Zoom. Quem quiser participar, pode falar.
===//==
Bom dia,

   Prezado Thierry, respondo este e-mail, direcionado à Presidência da 
PRODABEL, já alinhado com o Presidente Leandro Garcia.

   Primeiramente gostaríamos de agradecer a oportunidade de nossa participação 
no enriquecimento da plataforma OpenStreetMap e segundo dizer que será um 
enorme prazer para a PRODABEL fazer parte deste trabalho junto a esta Fundação.

   Modéstia parte, realmente a estrutura de dados da Prefeitura de Belo 
Horizonte atualmente disponível é extensa e muito rica de detalhes em suas 
diversas camadas geográficas, desta forma combinar estes dados com o poder da 
plataforma OpenStreetMap trará inúmeros ganhos para a comunidade.

   Bem, como é possível perceber acima, ficamos muito satisfeitos em poder 
colaborar, desta forma nos coloco a disposição para fazermos uma call a fim de 
nortear o trabalho de nossas equipes no melhor modelo de trabalho para esta 
frente, instituindo assim o fluxo das informações e como estas estarão 
disponíveis. Além disso, no mundo público temos algumas etapas a vencer no 
âmbito jurídico e formal que precisam ser observadas, nesta mesma pauta para 
estabelecermos o melhor modelo, que respalde a Gestão Municipal, caso este for 
necessário.

   Peço apenas que realizemos esta call a partir da semana de 25/02/2019, OK!!??

Desde já agradecemos e estamos a disposição para conversarmos.

Atenciosamente,

Bruno Vieira da Costa
Diretor de Sistemas de Informação - DSI
PRODABEL | Av. Presidente Carlos Luz, 1275 | Caiçaras | BH-MG
CEP: 31230-000 | +55 (31) 3277-8498  |  
www.pbh.gov.br


Em qua, 6 de fev de 2019 às 18:04, Thierry Jean 
mailto:thie...@openstreetmap.com.br>> escreveu:
Prezado Senhor,

Soubemos, em diferentes eventos, da qualidade dos dados geográficos produzidos 
pela Prefeitura de Belo Horizonte e gostaríamos de contar com o envolvimento da 
Prefeitura para a melhoria da base do OpenStreetMap.

OSM é o projeto que começou com um estudante em física em Londres em 2004 e que 
atraiu a colaboração e apoio de grandes corporações como os Governos do mundo 
inteiro, Facebook, Microsoft, Amazon etc...

A audiência do OpenStreetMap está crescendo e é um dos raros contra-pesos à 
hegemonia do Google na área. É uma grande oportunidade para as empresas e os 
governos brasileiros.

Gostaríamos de termos a confirmação que podemos carregar os dados 
disponibilizados pela Prefeitura no site e, melhor ainda, gostaríamos de contar 
com o fato que a própria prefeitura possa envolver-se diretamente na melhoria 
do OpenStreetMap.

Estamos a disposição para reuniões de explicação.


Aqui está uma apresentação PDF:
https://www.dropbox.com/s/geuoobbd19j0jca/OpenStreetMap_Apresentacao_20180502.pdf?dl=0


Vídeo de 1:40 mn mostrando como se edita o mapa:
https://www.youtube.com/watch?v=zv9erJ4IhhAfeature=youtu.be

Artigo de 2014 que explica bem o potencial e a importância do OSM para a 
sociedade:
http://gizmodo.uol.com.br/analise-openstreetmap/

Video com reportagem da TV Vanguarda (Globo) sobre o mapeamento de Monteiro 
Lobato - SP feito com alunos da rede municipal.
http://g1.globo.com/sp/vale-do-paraiba-regiao/jornal-vanguarda/videos/v/estudantes-fazem-mapa-de-mon...

Cordialmente,

PS estou copiando alguns membros da comunidade envolvidos neste esforço em BH.


Thierry Jean
Colaborador e Membro Fundador do OpenStreetMap Brasil
Cel.: +55 11 9 9607 1319
www.openstreetmap.com.br

Re: [Talk-br] 2019 HOT Microgrants

2019-02-14 Por tôpico Jessica Bergmann 
Hello,

A friendly reminder that the deadline to apply for a 2019 HOT
Microgrant is just
two weeks away! Communities are invited to apply for a Microgrant that will
help them to scale their mapping activities and their local and global
impact. Applications are due by February 28 at 12midnight EST. Please see
the HOT blog

for the application review criteria and the link to the application.

If you have any questions, please do not hesitate to contact us at
microgra...@hotosm.org. A member of our team will reply within 24-48 hours.


Cheers!


Jessica

On Wed, Feb 6, 2019 at 1:04 PM Jessica Bergmann 
wrote:

> Hi Everyone,
>
> HOT is excited to announce the launch of the 2019 HOT Microgrants program!
> This year, we will be awarding Microgrants between $2,000-$5,000 for 8-10
> communities throughout the world to reduce barriers and scale their mapping
> activities and impact. Applications for the 2019 Microgrants program are
> due by February 28 at 12midnight EST and can be found using this link.
> 
>
>
> We especially encourage communities from the Caribbean, Middle East, North
> Africa, and Asia to apply, as well as those communities looking to
> diversify their mappers (gender balance, age, socioeconomic status, etc.),
> in order to continue expanding the global mapping community. Before
> submitting your application, ensure that you coordinate with other mapping
> communities in your country/region, finding opportunities for collaboration
> where possible and minimizing the number of applications that propose the
> same mapping project. For more information about the HOT Microgrants
> program and to see the application review criteria, please check the HOT
> blog
> 
> .
>
> Please forward this information along to any other individuals and
> communities you believe would make excellent candidates for this
> opportunity. Any questions can be sent to microgra...@hotosm.org or
> directly to me at this email address. Please allow 24-48 hours for a
> member of our team to reply.
>
>
> Best,
>
>
> Jessica
>
>
> --
> *Jessica Bergmann*
> Partnerships & Community Programs Associate
> Humanitarian OpenStreetMap Team 
> Uganda: +256 754 672 750 | WhatsApp: +1 630 267 3307
> Skype: jessica.bergmann91
>


-- 
*Jessica Bergmann*
Partnerships & Community Programs Associate
Humanitarian OpenStreetMap Team 
Uganda: +256 754 672 750 | WhatsApp: +1 630 267 3307
Skype: jessica.bergmann91
___
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

2019-02-14 Por tôpico Peter Krauss 
Oi gente, respondendo primeiro ao Fernando depois ao Pedro,

Fernando, a sua colocação é consistente, mas a discussão evoluiu em duas
frentes (2.1 e 2.2 abaixo), e devemos tomar o cuidado de separar com
clareza,
sugiro dar nomes sempre que referir:

1. *Ponto inválido*: não pode existir no mapa OSM um *node* de
endereçamento sem ambos, nome de rua (*addr:street*) e numeração (
*addr:housenumber*).
É "a lei", "o grande consenso" e a boa prática. Evita-se inserir e
pode-se deletar um ponto inválido.
Por favor, *NAO ESTÁ EM DISCUSSÃO*, já foi discutido e é consenso
universal (na comunidade BR e na comunidade internacional)*.*

*2. MÉTODO DE EDIÇÃO E/OU IMPORTAÇÃO DE PONTOS OFICIAIS: *a diferença entre
um dado oficial e um dado empírico é que o dado oficial não tem confirmação
em campo, mas em contrapartida tem um documento ou *declaração oficial do
governo*. Ver https://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Oficial


2.1. *Ponto oficial completo*: pode ser importando pois todos os dados
estão presentes (posição, nome e numeração)  e é uma "verdade oficial",
dispensando maiores (precisa de *consistência* naturalmente!) preocupações
com a verdade de campo homologada por usuários OSM potnto a ponto, *basta
amostragem*.
É consenso, estão todos de acordo em fazer importação automática,
queremos apenas UNIFORMIZAR PROCESSOS e a SIMPLIFICAR/PADRONIZAR um pouco
as os relatórios de importação, para que mais pessoas possam ver e
entender,  *auditar sem perder tempo*.

2.2. *Ponto oficial incompleto*: pode ser importando?  Essa é a discussão.
As fontes de informação na verdade existem, só que não é uma fonte única,
pode estar misturando verdade de campo, norma oficial (por exemplo leis de
nomenclatura de rua), dado oficial (ex. os pontos fornecidos pela
prefeitura), etc. O algorítomo mesmo sendo aberto é complexo e poucas
pessoas do OSM terão tempo e capacidade de avaliar.  *ESTÁ EM DISCUSSÃO*,
mas precisamos *primeiro arrumar a casa*, chegar a uma descrição
satisfatória no "ponto oficial completo" (*2.1* acima).  Mesmo depois de
discutir e chegar a um consenso aqui precisaremos verificar com restante da
comunidade OSM

.

2.2.1. Com  numeração (addr:housenumber) obtida por
interpolação/proximidade.
2.2.2. Com  nome de rua (addr:street) obtido por proximidade.

O que acha?  *Podemos seguir com essa terminologia? *importação de "ponto
invalido" (obviamente invalida), de "ponto oficial completo" e de "ponto
oficial incompleto".

- - -

Pedro, quanto ao uso do inglês, a grande maioria não se sente a vontade
para entrar num debate com os gringos da comunidade OSM internacional,
damos a cara para bater sozinhos e em geral saímos de olho roxo por falta
de mais gente apoiando nossa opinião ou escrevendo em melhor inglês o nosso
posicionamento (em geral trazido/traduzido da comunidade local)... Claro,
quem não se importa ou já se sente a vontade deve continuar,
mas a maioria precisa de apoio, e um apoio seu, mesmo usando tradutor,
seria bem-vindo (!)... Se surgir alguma discussão relevante aviso aqui.





On Wed, Feb 13, 2019 at 3:35 PM Fernando Trebien 
wrote:

> Não acho certo importar dados em que addr:street tenha sido inferida
> por qualquer método sem que tenha sido feita uma conferência antes de
> fazer a importação. Daí se está importando sujeira no mapa que tende a
> ser esquecida e a prejudicar a qualidade final dos dados. O certo é
> definir uma forma de tratar as incorreções, seja aprimorando o método,
> usando métodos suplementares, ou fazendo uma revisão manual antes. É
> que estamos fazendo em PoA e em Curitiba, e não acho que devam ser
> abertas exceções.
>
> É justamente pra evitar que sejam importadas grandes quantidades de
> dados incorretos que existe todo esse protocolo de elaborar uma
> proposta e aprovar pela comunidade. Senão, qualquer um podia importar
> qualquer coisa (legalizada) de qualquer jeito. Inclusive, isso consta
> nos guidelines de importação. [1][2]
>
> [1]
> https://wiki.openstreetmap.org/wiki/Import/Guidelines#Take_great_care_to_avoid_damaging_the_database
> [2]
> https://wiki.openstreetmap.org/wiki/Pt:Import/Guidelines#N.C3.A3o_estrague_os_dados.21
>
> On Tue, Feb 12, 2019 at 5:09 PM Peter Krauss  wrote:
> >
> > Otima dica Adriano (!), que  tal então a seguinte regra para os
> algoritmos de inferência de street:
> >
> > * quando a inferência for altamente confiável, aplicar apenas tag note,
> https://wiki.openstreetmap.org/wiki/Key:note
> > com um valor padronizado, algo como "addr:street:inferred".
> >
> > * quando a inferência for mais fraca ou carecer de avaliação estatística
> de confiabilidade, usar a tag fixme,
> > https://wiki.openstreetmap.org/wiki/Key:fixme
> >para relatar a mesma coisa,  algo padronizado como
> "addr:street:inferred_low_reliability".
> >
> > É esperado que quem for editar, na maior parte dos casos, precisa apenas
>