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

[Pedro vida torta]

Quilômetros de distancia não entendi bem , já que o erro será apenas nas
esquinas e o usuário estará apenas a poucos metros, eu acho aceitável
melhor que não ter nenhuma outra referencia, criticar o trabalho dos outros
e fácil eu não vejo ninguém no OSM inserindo endereços em quantidade
regularmente, porque o trabalho e muito grande, não existem dados para
importação e tudo tem de ser feito manualmente então qualquer melhoria e
bem vinda e não pode ser simplesmente chamada de lixo já que 95% dos dados
serão extremamente úteis, melhor que inserir 100% manualmente que vai
demorar uns 30 anos e ainda ter perto de 2% de erros.

Em qui, 14 de fev de 2019 às 16:20, Fernando Trebien <
fernando.treb...@gmail.com> escreveu:

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

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

[Pedro vida torta]

Não escrevo em inglês uso somente o tradutor para tirar duvidas , claro que
quanto mais informações tiver a etiqueta melhor eu mesmo além da numeração,
CEP e nome da via, coloco ainda cidade, iluminação e tipo de piso, poi não
coloco devido a desconfiança das pessoas para passar os dados , eu me
comprometo a ajudar a arrumar as esquinas para diminuir os erros.

Em ter, 12 de fev de 2019 às 13:24, Peter Krauss 
escreveu:

> Pedro, são mais argumentos a favor e concordo, mas a favor do que não
> seria uma boa prática... A boa prática é já registrar o ponto com o nome de
> rua, mas aí não seria o nome 100% certo, seria inferido por presunção de
> proximidade com a rua...
>
> O que se comentou de saída para o dilema, que requer apoio na comunidade
> geral do OSM, é estabelecer regras claras e consensuais para essa
> presunção, e adicionalmente incluir uma tag de alerta "esse nome foi
> inferido por computador" (tal como já fazemos com número de porta inferido
> por interpolação).
>
> ... Quando  comento "requer apoio na comunidade geral do OSM", é
> fundamental, precisamos comparecer em bando, pois senão quem for atrás só
> vai perder tempo e se queimar, como já ocorreu outras fazes: se a
> comunidade-Brasil não começar a se portar como "autoridade do Brasil", a
> OSMF e pessoal de outros países, que desconhecem nossa realidade, vão
> continuar passando por cima, e nossas demandas continuarão "à margem"...
> Você escreve em inglês?  Alguém aqui poderia apoiar uma discussão  em
> inglês?
>
>
>
> On Tue, Feb 12, 2019 at 12:30 PM Pedro vida torta <
> pedrovidator...@gmail.com> wrote:
>
>> Não vejo grandes problemas e importar sem o nome da via, teremos erros em
>> esquinas que podem ser corrigidos com o tempo, a maioria dos aplicativos
>> mostra a numeração no mapa e mesmo com o erro qualquer usuário pode achar
>> visualmente, no caso em questão somente a numeração esta disponível e eu
>> ficaria extremamente satisfeito com isso , já que colocar depois o nome da
>> via depois e bem mais fácil.
>>
>> Em sex, 8 de fev de 2019 às 09:56, Sérgio V. 
>> escreveu:
>>
>>> 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
>>>
>>
>>
>> --
>> *Pedro Esmerilho*
>> ___
>> 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
>


-- 
*Pedro Esmerilho*
___
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

[Pedro vida torta]

Não vejo grandes problemas e importar sem o nome da via, teremos erros em
esquinas que podem ser corrigidos com o tempo, a maioria dos aplicativos
mostra a numeração no mapa e mesmo com o erro qualquer usuário pode achar
visualmente, no caso em questão somente a numeração esta disponível e eu
ficaria extremamente satisfeito com isso , já que colocar depois o nome da
via depois e bem mais fácil.

Em sex, 8 de fev de 2019 às 09:56, Sérgio V.  escreveu:

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


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

Re: [Talk-br] Como interpretar direction em pontos de alerta?

[Pedro vida torta]

Porque não fazer então , um tutorial para o ID e outro para o josm isso
diminuiria o numero de radares errados.


Livre
de vírus. www.avast.com
.
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Em 1 de abril de 2018 19:10, Nelson A. de Oliveira 
escreveu:

> 2018-04-01 8:56 GMT-03:00 Flavio Bello Fialho :
> > A maioria dos usuários novos tem dificuldades com relações e se pudermos
> > evitar o seu uso a chance de mapeamento incorreto diminui. Uma forma de
> > mapear sem usar relações:
>
> Criar um novo mapeamento incorreto para evitar outro tipo de
> mapeamento incorreto?
>
> Mas vamos para outro exemplo: alguns tipos de restrição de manobra são
> bem complexos e exigem relações, algumas vezes com vários caminhos
> como "via".
> As últimas versões do iD tornaram isso bem mais fácil.
>
> Mas antes disso, ninguém ficava criando rua que não existe ou fazendo
> gambiarra com "oneway" e outras coisas para representar uma restrição
> apenas porque não sabia mapear ou usar uma relação.
>
> > 5. Se a direção da lente da câmera não coincide com a do monitoramento e
> > alguém quiser muito mapear isso, use um tag mais específico, como
> > "direction:lens".
>
> direction:lens não existe.
> A direção já é dada por direction.
>
> Se quer arrumar solução tem que ser solução global, e não gambiarra só
> para o Brasil.
>
> E aliás, já são 55 câmeras possivelmente erradas no Brasil (com direction).
> Parece que conversar sobre isso só aumentou o número de uso incorreto.
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>



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

Re: [Talk-br] Como interpretar direction em pontos de alerta?

[Pedro vida torta]

O maior problema seria manter o cadastro atualizado , já que radares são
desativados com uma frequência grande , então qto mais simples for a
inclusão mais pessoas farão parte ativamente.


Livre
de vírus. www.avast.com
.
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Em 29 de março de 2018 13:28, Fidelis Assis 
escreveu:

>
>
> Em 28 de março de 2018 22:24, Nelson A. de Oliveira 
> escreveu:
>
>> 2018-03-28 20:35 GMT-03:00 Fidelis Assis :
>> > Bem, acho que não fui muito claro. O que eu sugeri antes em outras
>> palavras
>> > foi esquecer essa palava câmera :). E passar a interpretar o mapeamento
>> de
>> > sensor de velocidade em nó de via não como mapeamento de câmera e sua
>> > direção mas do sensor mesmo! Aqueles sensores magnéticos ou de peso que
>> > ficam sob o asfalto na grande maioria dos "radares" fixos de trânsito.
>>
>> Mas aí vai mudar a semântica do speed_camera.
>> Da mesma forma que vai mudar se usar backward/forward como a direção a
>> que ela se aplica.
>>
>> Vai ser outra jabuticaba no Brasil, diferente do resto do mundo :-)
>>
>
> Nelson, o que me preocupa não é se vai mas se já não é e estamos comendo
> jabuticaba achando que é maçã :-) Pelo menos para mim os sinais são claros:
>
> 1- A começar pelo nome, no iD a tradução de 'speed camera' é 'sensor de
> velocidade'. Difícil achar que essa tradução foi feita pensando em câmera;
>
> 2- O mapeamento tem sido feito como um nó na via na grande maioria dos
> casos. Ora, câmera não fica na via mas ao lado (maioria). Tecnica e
> intuitivamente não deveria ser mapeada na via mas ao lado, aí sim sendo
> necessária relação de enforcement para indicar a direção de fiscalização.
> O que de fato fica na via são os sensores de velocidade para os quais a
> ideia de direção concorda naturalmente com a de fiscalização;
>
> 3- Se a gente conferir vamos ver que nos casos em que há direction para
> sensor de velocidade não há relação entre esta e a direção da câmera, para
> onde ela está voltada. A impressão que passa é que a intenção dos
> mapeadores, consciente ou inconscientemente, não foi retratar a direção da
> câmera, mas a de fiscalização. Infelizmente, para speed camera não há uma
> especificação clara na wiki indicando qual poderia ser usada. Como disse
> o bhousel, "na falta usei o mesmo padrão adotado para direção em outros
> casos" - em tradução livre.
>
> Então, a impressão que fica para mim é que a semântica já foi de fato
> alterada na prática, aos poucos, sem percebermos. Estamos falando de câmera
> mas inconscientemente pensando no sensor.
>
> E por que ele sugere explicitamente graus no template? Para mim é porque
> ele estava pensando na câmera mesmo, algo naturalmente fora da via e,
> portanto, sem relação tipo forward/backward com a mesma. Entretanto, na
> prática o mapeamento tem sido feito na via e ele concorda com essa forma
> também.
>
>
>> No dia 31 de janeiro tinha 28 câmeras com backard/forward no Brasil.
>> Hoje já tem 41.
>>
>> Eu tentei pedir para que isso ficasse um pouco mais explícito no iD,
>> mas não consegui.
>> https://github.com/openstreetmap/iD/issues/4757
>
>
> Isso é confuso mesmo, não há uma especificação clara na wiki e por isso
> entendi as razões dele ter feito e mantido assim.
>
> Um outro ponto que também achei estranho no início foi o uso de forward/
> backward em stops com uma noção contrária a do significado geral de
> direction que é para onde "olha" (faces to). Em stops é usado por
> recomendação da wiki e na prática para indicar o sentido do deslocamento
> e não para onde a placa de stop, ou a linha branca, "olha" - vi depois
> conferindo vários casos em outros países. Mas fica estranho você indicar
> forward e o viewfield olhar para trás. Já se você usar graus indicando a
> mesma direção o viewfield olha para frente!
>
> Perguntei sobre mas ficou por isso mesmo e aceitei que a prática
> prevaleceu: https://github.com/openstreetmap/iD/pull/4602#issuecomment
> -367000932
>
>
>>
>> A relação de enforcement é mais complexa, mas já é o modelo válido
>> para se definir para que sentido se aplica ou não o aviso (e existe
>> desde 2009 https://wiki.openstreetmap.org/wiki/Proposed_features/Relati
>> on:enforcement)
>>
>
> Sim, claro, o problema é justamente sua complexidade maior. Poucos
> mapeadores conseguem usá-la corretamente.
> Veja, o mecanismo mais simples para se indicar direção (tag direction)
> está reservado para a câmera, cuja direção pouco interessa nesse contexto.
> Já para a direção mais significativa, que é a de fiscalização, seria
> necessário usar o mais complexo do enforcement. É como estabelecer regra
> para coçar a orelha direita com a mão esquerda, o pessoal acaba ignorando.
>
> Agora, resumindo, o importante no meu ponto de vista é 

Re: [Talk-br] Como mapear Polícia Rodoviária?

[Pedro vida torta]

O ideal seria ter uma etiqueta própria, para policia rodoviária a
diferenciação seria no operador , ja vi algumas delegacias a margem de
rodovias.


Livre
de vírus. www.avast.com
.
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Em 9 de fevereiro de 2018 12:52, Fidelis Assis 
escreveu:

> Fazendo um resumo, interpreto como:
>
> 1- Usar "operator" para caracterizar polícia rodoviária pelo nome do
> operador não teve objeções. Até ensejou generalizações que podem ser úteis
> para outros tipos de extração de dados, como sugeriu santamariense;
>
> 2- Colocar um nome genérico como "Polícia Rodoviária
> Federal|Estadual|Municipal", etc na tag "name" não é uma boa prática;
>
> Se for isso mesmo, seria aceitável alterar todas as tags "name" onde hoje
> estão nomes genéricos para a tag "operator"?
>
> Abraços,
> -- Fidelis
>
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>


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

Re: [Talk-br] Transporte público v2 e highway=bus_stop

[Pedro vida torta]

A ta não conheço a segunda versão ainda , seria bom se colocassem as
etiquetas opcionais também

Em 13 de dezembro de 2017 12:50, Vítor Rodrigo Dias <vitor.d...@gmail.com>
escreveu:

> Sim, é o básico na primeira versão da tag. A segunda versão é bem mais
> elaborada.
>
> Vítor Rodrigo Dias
> Revisor de textos
> Tradutor de inglês e espanhol
> Telefones: 31 99916-1719
>
> Em 13 de dezembro de 2017 10:54, Pedro vida torta <
> pedrovidator...@gmail.com> escreveu:
>
>> Fernando confesso que fiquei boiando , pensei que isso fosse o básico, o
>> mínimo para se etiquetar pontos de parada.
>>
>> Em 9 de dezembro de 2017 00:55, Fernando Trebien <
>> fernando.treb...@gmail.com> escreveu:
>>
>>> Eu entendo que:
>>>
>>>- *public_transport=stop_position* representa o ponto de parada do
>>>ônibus [1] e deve ser um ponto na linha de uma via que é membro da rota 
>>> do
>>>ônibus
>>>- *public_transport=platform* representa a área de espera dos
>>>passageiros [2], que pode ser ponto, linha ou área e deve ficar ao lado 
>>> da
>>>via, separada dela
>>>- *highway=bus_stop* representa o ponto de embarque dos passageiros
>>>[3], e que deve ficar na plataforma; se a plataforma for uma área, deve
>>>ficar dentro dela ou no máximo na sua borda; se for uma linha deve ser um
>>>ponto ao longo da linha ou em um dos seus extremos; se for um ponto, deve
>>>se combinar com a tag public_transport=platform no mesmo ponto
>>>
>>> Também entendo que, ao migrar para a versão 2, não se deve remover
>>> highway=bus_stop, ou pelo menos não ainda [4].
>>>
>>> Vocês concordam/discordam?
>>>
>>> [1] https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Ds
>>> top_position : *to identify the place where a vehicle stops along a
>>> public transport route*
>>> [2] https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dplatform
>>> : *to identify the places where passengers wait for public transport of
>>> any type*
>>> [3] https://wiki.openstreetmap.org/wiki/Tag:highway%3Dbus_stop : *is a
>>> place where passengers can board or alight from a bus*
>>> [4] https://github.com/gravitystorm/openstreetmap-carto/issu
>>> es/311#issuecomment-221728439
>>>
>>> --
>>> Fernando Trebien
>>> +55 (51) 9962-5409 <+55%2051%209962-5409>
>>>
>>> "Nullius in verba."
>>>
>>> ___
>>> Talk-br mailing list
>>> Talk-br@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>
>>>
>>
>>
>> --
>> *Pedro Esmerilho*
>>
>> ___
>> 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
>
>


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

Re: [Talk-br] Transporte público v2 e highway=bus_stop

[Pedro vida torta]

Fernando confesso que fiquei boiando , pensei que isso fosse o básico, o
mínimo para se etiquetar pontos de parada.

Em 9 de dezembro de 2017 00:55, Fernando Trebien  escreveu:

> Eu entendo que:
>
>- *public_transport=stop_position* representa o ponto de parada do
>ônibus [1] e deve ser um ponto na linha de uma via que é membro da rota do
>ônibus
>- *public_transport=platform* representa a área de espera dos
>passageiros [2], que pode ser ponto, linha ou área e deve ficar ao lado da
>via, separada dela
>- *highway=bus_stop* representa o ponto de embarque dos passageiros
>[3], e que deve ficar na plataforma; se a plataforma for uma área, deve
>ficar dentro dela ou no máximo na sua borda; se for uma linha deve ser um
>ponto ao longo da linha ou em um dos seus extremos; se for um ponto, deve
>se combinar com a tag public_transport=platform no mesmo ponto
>
> Também entendo que, ao migrar para a versão 2, não se deve remover
> highway=bus_stop, ou pelo menos não ainda [4].
>
> Vocês concordam/discordam?
>
> [1] https://wiki.openstreetmap.org/wiki/Tag:public_transport%
> 3Dstop_position : *to identify the place where a vehicle stops along a
> public transport route*
> [2] https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dplatform : *to
> identify the places where passengers wait for public transport of any type*
> [3] https://wiki.openstreetmap.org/wiki/Tag:highway%3Dbus_stop : *is a
> place where passengers can board or alight from a bus*
> [4] https://github.com/gravitystorm/openstreetmap-
> carto/issues/311#issuecomment-221728439
>
> --
> Fernando Trebien
> +55 (51) 9962-5409 <+55%2051%209962-5409>
>
> "Nullius in verba."
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>


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

Re: [Talk-br] Numeração da Av paulista em SP - SP

[Pedro vida torta]

O addr tem de ser um para cada numero , por causa das diversas
portas,distancia entre eles, facilidade qdo do uso entrance para cegos , e
ainda em edifícios com duas faces de quarteirões.

Em 18/05/2017 18:42, "Marcos Fedato" <heroij...@hotmail.com> escreveu:

> Se os numeros forem da mesma rua poderia se utilizar o ponto e virgula
> para cada numero.
>
> Segundo a wiki do osm ele serve para ter multiplos valores para uma mesma
> chave.
>
> O alt_name as vezes tem isso a rua pode ter mais de um nome alternativo
> entao eles sao separados por ";".
>
> Ficaria tipo 1;5;11;21 o valor da sua tag.
>
>
>
> Enviado do meu smartphone Samsung Galaxy.
>
>
>  Mensagem original 
> De: Pedro vida torta <pedrovidator...@gmail.com>
> Data: 18/05/17 16:15 (GMT-03:00)
> Para: OpenStreetMap no Brasil <talk-br@openstreetmap.org>
> Assunto: Re: [Talk-br] Numeração da Av paulista em SP - SP
>
> Sim um mesmo edifício chega ter ate 10 números diferentes, por isso não se
> pode numerar a construção toda com apenas 1, a consulta e para ver se aguem
> tem uma solução melhor a minha.
>
> Em 18 de maio de 2017 11:12, Márcio Vinícius Pinheiro <
> marcioviniciu...@gmail.com> escreveu:
>
>> Um mesmo edifício tem vários números ou vários edifícios têm um mesmo
>> número?
>>
>> (Não me oponho a nada, não sou de São Paulo. Só fiquei curioso. =P )
>>
>> - - - ·
>> Atenciosamente,
>>
>> Márcio Vinícius Pinheiro
>> http://bit.ly/MarVinMeP
>> <http://pt.gravatar.com/marciovinicius>
>>
>> Em 18 de maio de 2017 10:15, Pedro vida torta <pedrovidator...@gmail.com>
>> escreveu:
>>
>>> https://www.openstreetmap.org/way/372847188 pretendo numerar a av
>>> paulista isso vai demandar tempo e pesquisa in loco para coletar os locais
>>> corretos e os números dos poi já existente, acontece que a Avenida ja esta
>>> razoavelmente numerada de uma forma errada, edifícios numerado com apenas
>>> um nº qdo na realidade tem vários , então vou usar a numeração oficial do
>>> geosampa mas para isso vou ter de mexer em quase tudo e apagar algumas
>>> numerações já existente , algumas pessoas podem não gostar então antes de
>>> começar gostaria de saber se existe alguém contrario.
>>>
>>> --
>>> *Pedro Esmerilho*
>>>
>>>
>>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>>>  Livre
>>> de vírus. www.avast.com
>>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>.
>>>
>>> <#m_-3478376710966743128_m_-772068151998662654_m_823510486919018625_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>>
>>> ___
>>> 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
>>
>>
>
>
> --
> *Pedro Esmerilho*
>
> ___
> 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] Numeração da Av paulista em SP - SP

[Pedro vida torta]

Sim um mesmo edifício chega ter ate 10 números diferentes, por isso não se
pode numerar a construção toda com apenas 1, a consulta e para ver se aguem
tem uma solução melhor a minha.

Em 18 de maio de 2017 11:12, Márcio Vinícius Pinheiro <
marcioviniciu...@gmail.com> escreveu:

> Um mesmo edifício tem vários números ou vários edifícios têm um mesmo
> número?
>
> (Não me oponho a nada, não sou de São Paulo. Só fiquei curioso. =P )
>
> - - - ·
> Atenciosamente,
>
> Márcio Vinícius Pinheiro
> http://bit.ly/MarVinMeP
> <http://pt.gravatar.com/marciovinicius>
>
> Em 18 de maio de 2017 10:15, Pedro vida torta <pedrovidator...@gmail.com>
> escreveu:
>
>> https://www.openstreetmap.org/way/372847188 pretendo numerar a av
>> paulista isso vai demandar tempo e pesquisa in loco para coletar os locais
>> corretos e os números dos poi já existente, acontece que a Avenida ja esta
>> razoavelmente numerada de uma forma errada, edifícios numerado com apenas
>> um nº qdo na realidade tem vários , então vou usar a numeração oficial do
>> geosampa mas para isso vou ter de mexer em quase tudo e apagar algumas
>> numerações já existente , algumas pessoas podem não gostar então antes de
>> começar gostaria de saber se existe alguém contrario.
>>
>> --
>> *Pedro Esmerilho*
>>
>>
>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>>  Livre
>> de vírus. www.avast.com
>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>.
>>
>> <#m_-772068151998662654_m_823510486919018625_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>> ___
>> 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
>
>


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

[Talk-br] Numeração da Av paulista em SP - SP

[Pedro vida torta]

https://www.openstreetmap.org/way/372847188 pretendo numerar a av paulista
isso vai demandar tempo e pesquisa in loco para coletar os locais corretos
e os números dos poi já existente, acontece que a Avenida ja esta
razoavelmente numerada de uma forma errada, edifícios numerado com apenas
um nº qdo na realidade tem vários , então vou usar a numeração oficial do
geosampa mas para isso vou ter de mexer em quase tudo e apagar algumas
numerações já existente , algumas pessoas podem não gostar então antes de
começar gostaria de saber se existe alguém contrario.

-- 
*Pedro Esmerilho*


Livre
de vírus. www.avast.com
.
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Alturas, mapas3D do OSM

[Pedro vida torta]

Os dados vem do site geosampa , são o resultado das plantas dos imoveis
fotos aéreas e fotos em 3 D recolhidas pela prefeitura no final da década
de noventa , por veículos equipados com  varias câmeras tipo SV.  No site
tem de tudo canos, fiação, esgotos, pontos de ônibus, numeração de porta
etc , são exportados para o OSM por um mapeador de são Paulo

Em 26/12/2016 20:13, "Lucas Ferreira Mation" 
escreveu:

> Pessoal,
>
> em primeiro lugar um feliz natal.
>
> Alguém sabe de onde vem os dados de planta dos prédios e altura que são
> usados para renderizar o mapa em 3D? Esta empresa (f4map) os calcula
> automaticamente de alguma forma (análise de sombras de imagens aérias) ou
> estes dados já estão no OSM?
>
> Fiquei muito surpreso de ver o quão completo isso está para São Paulo
> São Paulo
> http://demo.f4map.com/#lat=-23.5522503=-46.6761298=16
>
> Já para Brasília, os prédios das superquadras parecem mais baixos do que
> realmetne são
>
> http://demo.f4map.com/#lat=-15.8045536=-47.8923768=17
>
> Enfim, apenas queria saber se de fato estes dados estão no OSM, e como são
> inseridos
>
> feliz 2017
> Lucas
>
>
>
> ___
> 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 addr:interpolation - possibilidades

[Pedro vida torta]

Bem eu numero um quarteirão por dia em Sampa colhendo dados in loco, com os
dados da prefeitura acho que da pra numerar uns dois tranquilamente , acho
que vou demorar uns 300 anos pra terminar só a cidade de São Paulo, com a
numeração real de porta.
Lembro bem no final dos anos 60 que um professor de geografia passou um
trabalho de coletar informações de cidades brasileiras; o modo de
conseguirmos os dados foi através de escolas que repassavam para
professores de geografia e estes para alunos , a quantidade de informação
coletada foi impressionante, considerando que tudo foi feito por cartas via
correio, nem telefones usamos raros naquela época, interurbano nem pensar.
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 do que
ficar tentando convencer as pessoa leiga a mapear.

Em 16 de dezembro de 2016 14:07, Sérgio V.  escreveu:

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


-- 
*Pedro Esmerilho*

Re: [Talk-br] Sobre addr:interpolation - possibilidades

[Pedro vida torta]

santamariense em São Paulo a numeração começa sempre da ponta da via mais
próxima ao centro (praça da Sé) , os números ímpares estão sempre do lado
esquerdo da via , creio eu que outras cidades devem usar a mesma regra

Em 15 de dezembro de 2016 12:02, Daniel d'Andrada Tenório de Carvalho <
daniel.dandr...@gmail.com> escreveu:

> O Google faz reconhecimento de imagem das capturas do seu Street View,
> procurando por números em paredes etc, e manda recortes dos mesmos pra
> serem validados por pessoas via reCAPTCHA. Assim, aos poucos, ele vai
> melhorando (ou melhor, substituindo) a intepolação de endereços do Maps.
>
> 2016-12-15 11:02 GMT-02:00 santamariense :
>
>> Muitos dos comentários dos apps Maps.me e OSMAnd que vejo são sobre a
>> falta que faz os números para achar endereços.
>>
>> Eu pessoalmente não gosto de interpolation porque se eu saio para
>> recolher numeração de casas eu recolho de todas as casas (e não só as
>> da esquina, por exemplo), mas claro que vocês devem estar falando de
>> faces de quadras disponíveis por órgãos públicos.
>>
>> Um problema que eu vejo no CNEFE, por exemplo, é que muitos dos
>> setores são formados por várias quadras.
>>
>> Alguém sabe se é possível criar addr:interpolation usando o próprio
>> eixo da via? Aqui em Santa Maria / RS o esquema de numeração é bem
>> simples. A numeração começa ao norte ou ao oeste, dependendo do
>> alinhamento das ruas. Caminhando do início da numeração ao final, a
>> direita se tem as casas ímpares, e a esquerda as pares.
>>
>> Claro que isso é uma generalização, e isto causa muitos erros,
>> principalmente em ruas onde as casas não tem uma numeração lógica. E é
>> exatamente esse lixo que o Google Maps tem, mas que muitas pessoas
>> gostam e acham muito útil. Muitas vezes bate o número com a posição
>> das casas, mas algumas vezes pode deixar você mais perdido ainda.
>>
>> ___
>> 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
>
>


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

Re: [Talk-br] Sobre addr:interpolation - possibilidades

[Pedro vida torta]

Apesar de ter sempre usado interpolation para numerar vias em Sampa , sou
contra o uso indiscriminado pois geraria acomodação , Em São Paulo  isso
não seria necessário visto que temos números de porta disponíveis no site
da prefeitura e só numerar , no rio de janeiro já ouvi algo semelhante, o
mais correto penso eu seria procurar e ver se existem números disponíveis
em todas as grande cidades.

Em 14 de dezembro de 2016 16:26, Sérgio V.  escreveu:

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


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

Re: [Talk-br] Nomes de ruas (era Re: Possível cópia de nomes de ruas do Google)

[Pedro vida torta]

Eu acho que o importante não e a variação de nomes existentes nas fontes de
pesquisa e sim colocar com clareza a fonte de onde veio, seja ibge site das
prefeituras ou mesmo colhida in loco , para falar de diferenças no Bom
Retiro em São Paulo tem uma rua que tem um nome do google , outro no site
da prefeitura e duas placas da mesma via com grafia diferente em cada uma,
portanto o correto e aquela fonte de onde foi tirado o nome.

Em 14 de dezembro de 2016 08:20, santamariense 
escreveu:

> Sobre nome de vias públicas (ruas/estradas/...) gostaria de
> compartilhar a minha experiência.
>
> 1 - Busco sempre saber se existe um nome oficial (pesquisa nas Leis
> Municipais), no caso da minha cidade temos uma excelente fonte única
> que é uma lei que consolidou cerca de 1,5 mil denominações
> (http://www.camara-sm.rs.gov.br/camara/print_pdf/lei-
> ordinaria/2011/555/5558/lei-ordinaria-n-5558-2011-consolida-a-legislacao-
> municipal-sobre-denominacao-de-ruas).
> Claro que depois dessa lei surgiram leis esparsas, daí é só questão de
> acompanhar as novas leis criadas;
>
> 2 - Há casos em que a razão pode ser sim da placa. Existe uma placa
> "Estr. Mun. José Santo Fighera" (provavelmente colocada pelos próprios
> familiares) onde fica a família do Arroz Fighera. Quem criou a lei,
> aportuguesou o nome (Estr. Mun. José Santos Figueira), talvez porque
> ouviu e entendeu que fosse assim, sem tirar dúvidas em um documento
> com mais calma.
>
> 3 - Há casos em que não se pode confiar em placas. Neste caso, cito a
> R. Enesto Beck. Essa pessoa consta em livros de história sobre a
> cidade. Mas existe uma variação muito forte do nome dele, que é
> (Coronel) Ernesto Becker, seja em (algumas) placas, usado pela
> prefeitura, media local e até um ponto de táxi com o nome errado (sem
> falar que isso foi certamente agravado por erro de mapas conhecidos,
> como o GM, porque querendo ou não as pessoas veem o nome errado lá e
> passam a usá-lo - falei disso no diário certa feita:
> http://www.openstreetmap.org/user/santamariense/diary/37275). No OSM,
> é claro, temos os dois nomes. No IBGE tá certo o "Beck", mas tá errado
> o "coronel", porque o título não aparece no nome oficial.
>
> 4 - Até onde eu sei, o IBGE não é totalmente seguro quanto nome de
> ruas. Pode sim conter erros como qualquer outra fonte. Até porque há
> nomes que são capturados verbalmente com moradores.
>
> Se há variações do nome, e são de fontes lícitas, devemos colocar no
> OSM todas elas. Nas mais diferentes tags name, loc_name, alt_name,
> official_name, old_name,... Na tag "name" eu sempre preferia colocar o
> nome oficial, mas hoje eu tenho opinião diferente, nesta tag devemos
> colocar o que se acha in-loco, seja placas ou consenso de moradores.
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>



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

Re: [Talk-br] Correção de alguns postos de combustível no Brasil

[Pedro vida torta]

Puxa legal, passo sempre naquela área, acho que vou aproveitar a internet
grátis

Em 14 de dezembro de 2016 09:52, santamariense 
escreveu:

> Há várias entradas errôneas no OSM de "highway=rest_area" querendo
> representar uma casa/lar. Vejam isso de hoje:
> https://www.openstreetmap.org/node/4553695893 +
> https://www.openstreetmap.org/note/816116, inclusive com acesso a
> internet. Espero que seja de graça :)
>
> Voltando ao assunto, existe eletroposto (amenity=charging_station) no
> Brasil?
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>



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

Re: [Talk-br] Possível cópia de nomes de ruas do Google

[Pedro vida torta]

Creio que o mais correto seria reverter todos infelizmente , impossível
saber o que e correto.

Em 13/12/2016 17:25, "Nelson A. de Oliveira"  escreveu:

> Verificando alguns problemas de locais eu reparei que os nomes de ruas
> daqui são muito similares aos nomes do Google:
>
> https://www.openstreetmap.org/#map=17/-22.72876/-44.84862
>
> Inclusive tendo o nome do local
> https://www.openstreetmap.org/node/4472678103 idêntico ao do Google
> (Chácara São Judas Tadeu),
> como pode ser visto em
> https://www.google.com.br/maps/@-22.7285485,-44.849262,18z
>
> Pela camada do IBGE rural o local talvez poderia ser "São Bom Jesus".
>
> Se alguém clicar no POI da chácara no Google e ir para o website (que
> vai cair numa página do Facebook) verá que ela está localizada no
> "Bairro do Bom Jesus".
>
> Independente do nome ser "São Bom Jesus", "Bairro do Bom Jesus" ou
> alguma outra variação, é certo que "Chácara São Judas Tadeu" não é o
> nome dessa localidade.
> Parece claro que, neste caso, houve também uma cópia incorreta do nome
> do local (que é apenas uma chácara particular).
>
> Um outro exemplo:
> http://mc.bbbike.org/mc/?lon=-67.732649=-10.14355=
> 17=4=mapnik=google-map=bing-map=nokia-map
>
> A "Rua Felício Abraão" só existe no Google (e no OSM)
> Em todo os outros, incluindo o IBGE, é Abrahão (com H).
>
> Muitas ruas nesse lugar batem com o Google, sendo identificáveis nos
> pequenos detalhes de grafia.
>
> Nos changesets vistos rapidamente dá para ver que não foi habilitada a
> camada do IBGE ao inserir o nome das ruas.
>
> No Telegram foi questionado que ele "Talvez conheça o nome das ruas de
> onde mora".
> Saber o nome das ruas de onde a pessoa mora é aceitável. Saber o nome
> das ruas de um lugar distante, coincidindo com o Google, já passa a
> ficar estranho.
>
> Outro ponto é que algumas ruas aparentam estar representadas com nomes
> de conhecidos ou familiares.
>
> Exemplos:
> Estava com nome de "Rua Lécio Rus Tôrres"
> https://www.openstreetmap.org/way/279927998/history e ele retirou hoje
> (não existe nenhuma rua com esse nome na Internet)
>
> Estava com nome de "Rua Júlio Vilela"
> https://www.openstreetmap.org/way/442473942/history e ele retirou hoje
> (repare que o sobrenome é Vilela)
>
> Estava com nome de "Rua Helana Da Silva Vilela"
> https://www.openstreetmap.org/way/279728229/history e ele retirou hoje
> (sobrenome Vilela)
>
> Estava com nome de  "Rua Rosilene Vilela"
> https://www.openstreetmap.org/way/279927994/history (mesma coisa)
>
> Estranhamente essas ruas de cima tiveram os nomes removidos hoje.
>
> Mas ainda é possível ver algumas ruas que não foram modificadas por
> outros usuários, todas contendo "Vilela" em seus nomes:
> http://overpass-turbo.eu/s/kDs
>
> Tem nome que dá para procurar na Internet e ver que é uma pessoa real,
> com endereço, telefone, etc, e que reside em Barra Mansa (onde
> aparentemente o Gabriel reside).
>
> Nessa parte me parece que muitas ruas foram nomeadas, de forma
> incorreta, com nome de familiares ou conhecidos.
>
> Muitas mensagens que foram enviadas ele não respondeu (desde outra
> época, onde alguns dados foram alterados de forma incorreta).
>
> Segundo o Marcio (Thundercel) ele é idoso e tem algumas limitações no
> uso da Internet (e que por isso não recebeu os avisos de mensagens).
> Ele também disse que o Gabriel se sentiu ofendido em um dos comentários.
>
> Por mais bem intencionada que a pessoa esteja, dá para ver que algumas
> coisas foram inseridas de maneira incorreta, com outras possivelmente
> copiadas de onde não possuímos permissão.
>
> O problema é que são quase 10 mil changesets.
> Não dá para verificar um por um, além de ter duas questões
> importantes: quais objetos possuem de fato um nome correto (e não um
> nome fictício ou de conhecido) e quais objetos possuem o nome copiado.
>
> Alguma sugestão?
>
> ___
> 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] Numeração de lotes e marcação das edificações de Joinville

[Pedro vida torta]

Gerald talvez vc tenha elementos com vc para citar apenas uma exclusão
desse tipo que eu tenha feito, qdo me deparo com esses casos incluo uma
entrada principal e não apago nada ,muito pelo contrario tive varias
colaborações colhidas in loco deletadas, apenas dei minha opinião  e tomei
umas pedradas.

Em 9 de dezembro de 2016 09:02, Gerald Weber <gwebe...@gmail.com> escreveu:

>
>
> 2016-12-09 1:47 GMT-02:00 Pedro vida torta <pedrovidator...@gmail.com>:
>
>> GPS inteligente RS, hj mesmo um motoqueiro faleceu no rio vitima de
>> bandidos, causa GPS com mapa deficitário , o mesmo acontecera com mapas
>> gerados pelo OSM se colocarmos um cabresto e não olharmos todas as
>> aplicações se o problema e esse faça dos dois modos , um o numero de porta
>> real e outro numero de edificação virtual, desse modo cada aplicativo pode
>> escolher o melhor, meu foco e GPS e com certeza não irei numerar edifícios
>> qdo disponíveis no mapa , ainda uso aplicações meio burras.
>>
>
> Acredito que caso que você cita o problema de roteamento só aconteceria se
> houvesse apenas addr:housenumber e faltasse addr:street, ou seja o
> aplicativo não tem como determinar a qual rua pertence aquele número. Isto
> é especialmente crítico em esquinas ou construções grandes que ocupam uma
> quadra inteira.
>
> Há literalmente centenas de aplicativos usando o OSM. São as aplicações
> que tem que se adaptar. É impossível do OSM se adaptar a aplicativos com
> exigências conflitantes. Por isto temos de seguir com as regras de
> mapeamento estabelecidas e os desenvolvedores que adaptem seus softwares.
>
> Se você não deseja acrescentar essas informações nos seus mapeamentos você
> tem esta liberdade, afinal aqui somos todos voluntários.
>
> Mas por favor não chegue ao ponto de remover essas informações apenas para
> resolver o mal funcionamento do aplicativo que você usa. Não me entenda
> mal, não estou dizendo que você removeu ou vai remover alguma coisa, mas
> como tem mais gente lendo essas mensagens é preciso deixar claro que isto
> não é o caminho a seguir.
>
> abraço
>
> Gerald
>
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>


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

Re: [Talk-br] Numeração de lotes e marcação das edificações de Joinville

[Pedro vida torta]

Não tem historia , eu uso entrance , e acho totalmente desnecessário fazer
trabalho dobrado endereçando também o edifício, quanto a mapear para um ou
outro fim cada um faz de seu modo, não vamos discutir a toa.

Em 09/12/2016 02:06, "Nelson A. de Oliveira" <nao...@gmail.com> escreveu:

> 2016-12-09 1:47 GMT-02:00 Pedro vida torta <pedrovidator...@gmail.com>:
> > GPS inteligente RS, hj mesmo um motoqueiro faleceu no rio vitima de
> > bandidos, causa GPS com mapa deficitário , o mesmo acontecera com mapas
> > gerados pelo OSM se colocarmos um cabresto e não olharmos todas as
> > aplicações se o problema e esse faça dos dois modos , um o numero de
> porta
> > real e outro numero de edificação virtual, desse modo cada aplicativo
> pode
> > escolher o melhor, meu foco e GPS e com certeza não irei numerar
> edifícios
> > qdo disponíveis no mapa , ainda uso aplicações meio burras.
>
> Sério que vai começar com toda essa história de novo de que a gente
> tem que mapear para o GPS?
> Bem em um assunto sobre importação de dados, que não tem nada a ver 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] Numeração de lotes e marcação das edificações de Joinville

[Pedro vida torta]

GPS inteligente RS, hj mesmo um motoqueiro faleceu no rio vitima de
bandidos, causa GPS com mapa deficitário , o mesmo acontecera com mapas
gerados pelo OSM se colocarmos um cabresto e não olharmos todas as
aplicações se o problema e esse faça dos dois modos , um o numero de porta
real e outro numero de edificação virtual, desse modo cada aplicativo pode
escolher o melhor, meu foco e GPS e com certeza não irei numerar edifícios
qdo disponíveis no mapa , ainda uso aplicações meio burras.

Em 09/12/2016 00:50, "Nelson A. de Oliveira" <nao...@gmail.com> escreveu:

2016-12-09 0:18 GMT-02:00 Pedro vida torta <pedrovidator...@gmail.com>:
> Nós soltos em construções as x e melhor, dependendo do tamanho do prédio o
> GPS pode rotear de uma forma equivocada levando a outra via

Mas isso é outro problema isso, fora do OSM.
Se o prédio inteiro possui um endereço, ele deve ser representado assim.
Não é certo representar algo de forma incompleta apenas para que
funcione melhor com algum tipo de aplicativo.

Pode colocar a entrada no prédio com entrance
https://wiki.openstreetmap.org/wiki/Entrance

Se o GPS for inteligente ele irá utilizá-la.

___
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] Numeração de lotes e marcação das edificações de Joinville

[Pedro vida torta]

Nós soltos em construções as x e melhor, dependendo do tamanho do prédio o
GPS pode rotear de uma forma equivocada levando a outra via

Em 08/12/2016 19:23, "Daniel d'Andrada Tenório de Carvalho" <
daniel.dandr...@gmail.com> escreveu:

> 2016-12-08 16:49 GMT-02:00 Nelson A. de Oliveira :
>
>> 2016-12-08 15:54 GMT-02:00 Daniel d'Andrada Tenório de Carvalho
>> :
>> > Acho que o melhor será converter os polígonos dos lotes em nodes nos
>> > centróides correspondentes.
>>
>> Consegue colocar a numeração no prédio?
>> Fica mais correto do que nós soltos, quando há apenas um prédio no
>> terreno.
>>
>>
> Vou tentar. É, tenho feito assim nas edificações que mapeei manualmente.
>
> ___
> 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