[Talk-br] Folheto OpenStreetMap Brasil

[John Packer]

Pessoal, existe algum tipo de cartão ou folheto do OpenStreetMap em
português ou numa versão brasileira?

Percebi que, durante um *survey*, às vezes surgem pessoas curiosas sobre o
que eu estou fazendo, criando oportunidades para dar um folheto informativo
para aumentar o uso do OSM. Também poderia evitar algumas situações
constrangedoras (por exemplo, uns dias atrás eu estava fazendo *survey* de
bicicleta com o Osmtracker(android) e teve até uma velhinha que juro que
estava pronta pra ligar para a polícia quando eu subi numa rua sem saída
pra ver se tinha alguma trilha e marcar o final).

Seria bem interessante se este folheto também mencionasse(ou desse um link)
sobre a funcionalidade de anotações para relatório de erro/bug. Desta
forma, não é necessário as pessoas aprenderem a mapear para dar uma ajuda.
Talvez também mostrasse um link para o MapQuest, já que direções é algo bem
comum de ser procurado, e o MapQuest(um problema possível, embora pequeno,
seria as pessoas começarem a pensar que o mapa É o MapQuest e não o OSM).
Um problema de incentivar as pessoas a relatarem erros e adições é elas
fazerem uso de um outro mapa de forma indevida(com uma licença que não
permite), portanto seria recomendável mencionar isso em algum lugar.

Também, como comentado pelo Fernando Trebien, seria legal explicar no
folheto que não trabalhamos nem pro Google nem pro governo. (acredito que
deixaria as pessoas mais sossegadas)


Descobri que tem algo parecido com o que eu estou procurando aqui:
https://gitorious.org/osmtutorial/osmtutorial/source/master: (que eu saiba,
o Wille que administrou isso, e que acredito participar desta lista também)

Achei bem legal, só a diferença do que eu estou procurando é que este ali
tem mais uma cara de cartaz(que coloca em algum lugar) ao invés de folheto,
e eu estava procurando algo mais para o público geral do que para procurar
possíveis mapeadores.


Abraços,João
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] [SC][Joinville] Lista de email de Joinville

[John Packer]

Amigos, criei uma lista de email para a comunidade de Joinville.

É uma comunidade bem pequena atualmente, e os bairros menores estão
sofrendo com falta de ruas. Quero tentar aproximar mais esta comunidade e
fazer mais propaganda para que pessoas normais possam apontar erros e
adições também.

O link para a lista de email é o seguinte:
https://groups.google.com/forum/#!forum/openstreetmap-joinville-sc

Abs,
João
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Dados de Planaltina e região

[John Packer]

Pelo que entendi, o Nelson está tentando evitar que essa energia para
melhorar o mapa não vá descarga a baixo caso apareça pedidos de remoção de
uma área com uma fonte ilegal.

Para quem não chegou a ver, o Nelson citou um caso brasileiro em que uma
área bem grande foi removida por ter fonte ilegal(junto com as informações
novas legais), e isso +- 5 anos depois de ser incluída! Ou seja, o dano foi
grande.
Em 29/01/2014 23:04, "Paulo Carvalho" 
escreveu:

>
>
>
> Em 29 de janeiro de 2014 20:43,  escreveu:
>
>>   Amigos,
>> confesso que estou viajando nesse debate.
>>
>> Sabemos que existem diversos provedores de imagem satélite e até hoje não
>> identifiquei um provedor sequer que tenha a imagem perfeitamente
>> georeferenciada.
>>
>> Um desenvolvedor que faz um bom trabalho coleta tracks da área que deve
>> desenhar e emprega como pano de fundo uma imagem de melhor qualidade
>> naquela área. Antes de iniciar o desenho do arruamento deve alinhar aquela
>> imagem pelos tracks coletados.
>>
>> Compreendo que não se deve empregar a imagem do Google por força de
>> licença daquele, entretanto se o desenho do arruamento não coincidir com a
>> imagem do Google que prova existirá que foi empregada a imagem do Google?
>>
>> O emprego de dados do mapa do Google, como nome de vias, é outra estória
>> que particularmente nunca empreguei porque existem tantos erros que não
>> confio naqueles dados.
>>
>> Não desejo criticar a preocupação quanto aos dados inseridos em
>> Planaltina, mas na minha opinião no momento existem preocupações maiores a
>> serem debatidas.
>>
>> Venho garimpando novos editores e recentemente um deles comentou comigo o
>> seguinte:
>>
>> *Marcio, também estou fazendo ediçoes no mapa da cidade de Sao Paulo, mas
>> confesso que o mapa está bastante desanimador em termos de roteamento, tudo
>> errado, sem chance de recomenda-lo para usuário comum de gps, por enquanto.
>> O maior problema é a total falta de restriçoes de manobras em vias
>> (normalmente expressas, primárias e secundárias) e consequente erros de
>> roteamento.*
>>
>> Sem duvida alguém poderá mais uma vez comentar que o OSM não é focado tão
>> somente para navegação satelital,
>>
>
> Independentemente de ser de múltiplo propósito, esse tipo de erro é
> crasso.  Também tenho observado isto no Rio.  A Av. das Américas, por
> exemplo, apresenta seus retornos com conexões com as pistas de dentro de
> forma que seria possível manobras proibidas e perigosas.
>
> Concordo que devemos investir mais energia na melhoria dos mapas e menos
> em lançar suspeita sobre usuários que estão tentando fazer justamente 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] Trilhas de GPS coloridas de acordo com a direção do movimento

[John Packer]

Opa, isso me lembra que eu tinha visto uma notícia sobre isso, só que
usando todas os dados das trilhas GPS públicas do OpenStreetMap.

Nunca descobri como usar as trilhas públicas. Essas que você usou são umas
que você mesmo coletou?

Abs, João


2014-01-31 Wille :

> Escrevi no meu diário do OSM uma dica de como visualizar melhor as trilhas
> de GPS no iD e no JOSM: http://www.openstreetmap.org/
> user/wille/diary/20914
>
> até mais,
> wille
>
> ___
> 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] spell check

[John Packer]

Pois é, eu também achei potencialmente perigoso, pois que eu lembre, no
OpenStreetMap, o que está na placa que conta mais.

Mas posso apontar pelo menos um erro que foi corrigido por ele e confirmado
por mim.
Tem uma avenida chamada Juscelino Kubitschek aqui, e estava como Kubitsche
*ck*. O TrevorInserts corrigiu como Kubitsche*k*. Eu verifiquei lá na placa
e realmente é sem o *'c'*. Isso é algo que passou despercebido por um bom
tempo.


Em 3 de fevereiro de 2014 10:05, Marcelo Pereira
escreveu:

> Eu conheço.
>
> Sou eu.
>
> Marcelo Pereira
>
>
> Em 3 de fevereiro de 2014 08:55, Gerald Weber escreveu:
>
>> Oi Pessoal
>>
>> tem um usuário rodando spell check
>> http://www.openstreetmap.org/user/TrevorInserts
>>
>> http://www.openstreetmap.org/changeset/20274327
>>
>> isto é potencialmente perigoso fazer correções automatizadas assim
>>
>> alguém conhece este usuário?
>>
>> abraço
>>
>> Gerald
>>
>> ___
>> Talk-br mailing list
>> Talk-br@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-br
>>
>>
>
>
> --
> -
> TImbuSérieA2013
>
> ___
> 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] spell check

[John Packer]

PS: Acho que vale ressaltar, que nesta avenida Juscelino Kubitschek, só uma
parte da rua teve seu nome corrigido(eu corrigi o resto da rua depois). Tem
que tomar cuidado com isso.


Em 3 de fevereiro de 2014 10:15, John Packer escreveu:

> Pois é, eu também achei potencialmente perigoso, pois que eu lembre, no
> OpenStreetMap, o que está na placa que conta mais.
>
> Mas posso apontar pelo menos um erro que foi corrigido por ele e
> confirmado por mim.
> Tem uma avenida chamada Juscelino Kubitschek aqui, e estava como Kubitsche
> *ck*. O TrevorInserts corrigiu como Kubitsche*k*. Eu verifiquei lá na
> placa e realmente é sem o *'c'*. Isso é algo que passou despercebido por
> um bom tempo.
>
>
> Em 3 de fevereiro de 2014 10:05, Marcelo Pereira 
> escreveu:
>
> Eu conheço.
>>
>> Sou eu.
>>
>> Marcelo Pereira
>>
>>
>> Em 3 de fevereiro de 2014 08:55, Gerald Weber escreveu:
>>
>>> Oi Pessoal
>>>
>>> tem um usuário rodando spell check
>>> http://www.openstreetmap.org/user/TrevorInserts
>>>
>>> http://www.openstreetmap.org/changeset/20274327
>>>
>>> isto é potencialmente perigoso fazer correções automatizadas assim
>>>
>>> alguém conhece este usuário?
>>>
>>> abraço
>>>
>>> Gerald
>>>
>>> ___
>>> Talk-br mailing list
>>> Talk-br@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>
>>>
>>
>>
>> --
>> -
>> TImbuSérieA2013
>>
>> ___
>> 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] spell check

[John Packer]

>
> Mas o que acontece se *de fato* a prefeitura fez as placas com Kubitsche
> *ck*? Na placa vai ter uma coisa e no OSM outra?

Neste caso *específico*, tendo *a placa* com um erro de ortografia, eu
colocaria um deles(provavelmente a versão correta) como name, e o que está
na placa como alt_name.


Em 3 de fevereiro de 2014 10:35, Gerald Weber  escreveu:

> Mas o que acontece se *de fato* a prefeitura fez as placas com Kubitsche
> *ck*? Na placa vai ter uma coisa e no OSM outra?
>
> E se alguém resolveu imitar o Café Kubitsche*ck* aqui no Brasil?
> http://www.das-neue-kubitscheck.de/ (que nada tem a ver com o
> Presidente), vai corrigir também introduzindo um erro?
>
> abraço
>
> Gerald
>
>
> 2014-02-03 John Packer :
>
>> PS: Acho que vale ressaltar, que nesta avenida Juscelino Kubitschek, só
>> uma parte da rua teve seu nome corrigido(eu corrigi o resto da rua depois).
>> Tem que tomar cuidado com isso.
>>
>>
>> Em 3 de fevereiro de 2014 10:15, John Packer 
>> escreveu:
>>
>> Pois é, eu também achei potencialmente perigoso, pois que eu lembre, no
>>> OpenStreetMap, o que está na placa que conta mais.
>>>
>>> Mas posso apontar pelo menos um erro que foi corrigido por ele e
>>> confirmado por mim.
>>> Tem uma avenida chamada Juscelino Kubitschek aqui, e estava como
>>> Kubitsche*ck*. O TrevorInserts corrigiu como Kubitsche*k*. Eu
>>> verifiquei lá na placa e realmente é sem o *'c'*. Isso é algo que
>>> passou despercebido por um bom tempo.
>>>
>>>
>>> Em 3 de fevereiro de 2014 10:05, Marcelo Pereira <
>>> pereirahol...@gmail.com> escreveu:
>>>
>>> Eu conheço.
>>>>
>>>> Sou eu.
>>>>
>>>> Marcelo Pereira
>>>>
>>>>
>>>> Em 3 de fevereiro de 2014 08:55, Gerald Weber escreveu:
>>>>
>>>>> Oi Pessoal
>>>>>
>>>>> tem um usuário rodando spell check
>>>>> http://www.openstreetmap.org/user/TrevorInserts
>>>>>
>>>>> http://www.openstreetmap.org/changeset/20274327
>>>>>
>>>>> isto é potencialmente perigoso fazer correções automatizadas assim
>>>>>
>>>>> alguém conhece este usuário?
>>>>>
>>>>> abraço
>>>>>
>>>>> Gerald
>>>>>
>>>>> ___
>>>>> Talk-br mailing list
>>>>> Talk-br@openstreetmap.org
>>>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> -
>>>> TImbuSérieA2013
>>>>
>>>> ___
>>>> 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
>>
>>
>
>
> --
>
> Dr. Gerald Weber
>
> gwebe...@gmail.com
>
> Personal website <https://sites.google.com/site/geraldweberufmg/>
>
>
>  Departamento de Física/Universidade Federal de Minas Gerais
>
> Department of Physics/Federal University of Minas Gerais
>
> Campus da Pampulha
>
> Av. Antônio Carlos, 6627, 31270-901 Belo Horizonte, MG, Brazil
>
> mobile: +55-(0)31-96462277 (mudou/changed 02/07/2013)
>
> ___
> 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] spell check

[John Packer]

Marcelo, só pra deixar claro, eu não sou contra essas correções.

É verdade que podem ter falsos positivos, mas como no exemplo que eu citei,
ainda ficaria Kubitschek errado por muito tempo aqui, então eu acho que no
final das contas são mudanças bem-vindas.


Em 3 de fevereiro de 2014 10:43, Marcelo Pereira
escreveu:

> Srs,
>
> Eu não estou rodando um spell check automático.
>
> 1. Uso o osmupdate para atualizar um mapa do brasil baixado do Geofabrik.
> 2. Uso o osmosis para extrair pedaços do mapa ( por exemplo, somente os
> highways=primary )
> 3. Rodo o aspell interativamente no arquivo gerado. ( interativamente aqui
> significa trabalho manual )
> 4. Faço o upload do arquivo atualizado usando o upload.py
>
> Gerald,
>
> O usuário trevorinserts foi uma sugestão do Trebien para que ao fazer
> alterações em lote no OSM ficasse mais fácil para identificar.
>
> Na descrição que fiz no fórum sobre o processo que rodei no mapa para
> trocar as abreviações por suas versões por extenso, eu citei a criação
> desas conta.
>
> Esse trabalho de spell check é uma continuidade natural do trabalho acima
> citado, pelo menos entendi assim.
>
> John,
>
>   A palavra "Kubitschek" tem respondido por boa parte das mudanças, dava
> para escrever um livro com as versões encontradas. :)
>
>  Vc encontrou o erro consertado em parte da via, provavelmente porque ela
> mudou de classificação, de primary para secundary, por exemplo, ou parte
> dela é um link, e como estou fazendo o spell check por partes, uma para
> cada tipo, é esperado que isso aconteça.
>
> Estou fazendo isso porque encontrei muitos erros de ortografia, isso é
> comum num projeto onde muitos contribuem, e com ferramentas que não
> fornecem o serviço de correção, ou pelo menos sugestão, de termos inseridos.
>
> Além disso, estou me atendo aos erros mais "danosos", como por exemplo os
> que podem impedir, ou mesmo dificultar, a pesquisa das vias, como por
> exemplo o do Kubitschek citado, ou outro pior, como o "Aveinda".
>
> Não estou dizendo que estou fazendo um trabalho perfeito, e por isso pode,
> e até deve, haver falsos positivos, mas imagino que valha o custo benefício.
>
> Se for a opinião dominante que este é um trabalho que não deva ser feito,
> eu o abandonarei imediatamente, assim como deixo aqui já registrado que
> permito a reversão de QUALQUER um dos changesets que inseri no mapa do OSM,
> se forem verificados erros que os inviabilizem.
>
> Assim como todos os mappers, encontrei um filão de atuação no OSM, e venho
> fazendo o melhor para poder ajudar.
>
> Marcelo Pereira
>
>
>
>
>
> Em 3 de fevereiro de 2014 09:19, John Packer escreveu:
>
> PS: Acho que vale ressaltar, que nesta avenida Juscelino Kubitschek, só
>> uma parte da rua teve seu nome corrigido(eu corrigi o resto da rua depois).
>> Tem que tomar cuidado com isso.
>>
>>
>> Em 3 de fevereiro de 2014 10:15, John Packer 
>> escreveu:
>>
>> Pois é, eu também achei potencialmente perigoso, pois que eu lembre, no
>>> OpenStreetMap, o que está na placa que conta mais.
>>>
>>> Mas posso apontar pelo menos um erro que foi corrigido por ele e
>>> confirmado por mim.
>>> Tem uma avenida chamada Juscelino Kubitschek aqui, e estava como
>>> Kubitsche*ck*. O TrevorInserts corrigiu como Kubitsche*k*. Eu
>>> verifiquei lá na placa e realmente é sem o *'c'*. Isso é algo que
>>> passou despercebido por um bom tempo.
>>>
>>>
>>> Em 3 de fevereiro de 2014 10:05, Marcelo Pereira <
>>> pereirahol...@gmail.com> escreveu:
>>>
>>> Eu conheço.
>>>>
>>>> Sou eu.
>>>>
>>>> Marcelo Pereira
>>>>
>>>>
>>>> Em 3 de fevereiro de 2014 08:55, Gerald Weber escreveu:
>>>>
>>>>> Oi Pessoal
>>>>>
>>>>> tem um usuário rodando spell check
>>>>> http://www.openstreetmap.org/user/TrevorInserts
>>>>>
>>>>> http://www.openstreetmap.org/changeset/20274327
>>>>>
>>>>> isto é potencialmente perigoso fazer correções automatizadas assim
>>>>>
>>>>> alguém conhece este usuário?
>>>>>
>>>>> abraço
>>>>>
>>>>> Gerald
>>>>>
>>>>> ___
>>>>> Talk-br mailing list
>>>>> Talk-br@openstreetmap.org
>>>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> -
>>>> TImbuSérieA2013
>>>>
>>>> ___
>>>> 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
>>
>>
>
>
> --
> -
> TImbuSérieA2013
>
> ___
> 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] Fundador do OpenStreetMap compra empresa de navegação

[John Packer]

Falando nisso, foi lançado um *demo* de um navegador do site oficial do OSM
nessa semana.
http://jsrouting.apis.dev.openstreetmap.org/


Em 3 de fevereiro de 2014 12:05, Marcelo Pereira
escreveu:

> O pior dos cenários, que consigo imaginar, é esse navegador se tornar o
> "oficial" do OSM , e começemos a ter influência dele na composição das tag,
> e etc.
>
> Fora isso, a popularização do OSM por intermédio de um navegador seria
> muito benéfica ao projeto. ( engraçado é que eu dizia isso tb no
> Tracksource )
>
> Marcelo Pereira
>
>
> Em 3 de fevereiro de 2014 10:55, Arlindo Pereira <
> openstreet...@arlindopereira.com> escreveu:
>
> Vitor, é exatamente isso. A Telenav é uma empresa de navegação de vários
>> anos de estrada, que ganhava bastante dinheiro até a popularização do
>> Google Maps, e comprou a skobbler para se manter no mercado com dados do
>> OSM.
>>
>> Conversei hoje com duas pessoas da empresa para conversarmos de que forma
>> poderá se dar a colaboração entre o OSM e a TeleNav. Eles estão
>> interessados em usar dados do OSM - cientes dos seus prós e contras - e,
>> para ter dados de qualidade, fomentar a comunidade na medida do possível.
>> Falamos no Skype por mais de uma hora, e levantamos uma possibilidade
>> bastante interessante, que vou comentar em outra thread para não misturar
>> os assuntos.
>>
>>
>> []s
>> Arlindo
>>
>> 2014-02-02 Vitor George :
>>
>> Acho que na verdade é o contrário. Eles compraram o Skrobbler para ter
>>> acesso a uma tecnologia de rotas madura baseada no OpenStreetMap.
>>> Em 01/02/2014 06:34, "Paulo Carvalho" 
>>> escreveu:
>>>
>>>  Tipo, para podermos importar os dados deles?


 Em 31 de janeiro de 2014 21:50, Igor Lemos escreveu:

> Olá Erick,
>
> Interessante essa notícia, essa empresa tem mapas com copyright?
>
>
> Em 31 de janeiro de 2014 21:45, Erick de Oliveira Leal <
> erickdeoliveiral...@gmail.com> escreveu:
>
>> Quer dizer, a empresa onde ele trabalha que comprou. rs. Interessante
>> que a empresa que comprou, TeleNav, tem escritório em São Paulo, segundo
>> este link: http://www.telenav.com/about/contact.html
>>
>>
>> 2014-01-31 Erick de Oliveira Leal :
>>
>>>
>>> http://stevecoast.com/2014/01/30/its-time-to-make-openstreetmap-your-only-street-map/
>>>
>>
>>
>> ___
>> 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 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 mailing list
>> Talk-br@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-br
>>
>>
>
>
> --
>
> ... Edileuz, eu não tem nada a ver com Creuza,
>É mentira da Ivete, não é meu esse caniveete...
> "Halley, Luiz" - Poeta, Cantor, Compsitor
>
> ___
> 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] Remoção de dados por solicitação de usuário

[John Packer]

Não acho que seja um bom argumento. Pois qualquer um que tenha o endereço
de uma casa pode achá-la facilmente com ou sem o mapa.

Se for uma estrada sem nome que só vai para aquela casa (que inclusive
justifique highway=service service=driveway), então acho que dá pra excluir
sim. Tem que ver se é um bom ponto de referência também, daí seria
aconselhável não excluir.
Creio que colocar access=private já iria ajudar, se fazer sentido no caso.


Em 7 de fevereiro de 2014 00:40, Fernando Trebien <
fernando.treb...@gmail.com> escreveu:

> Pessoal,
>
> Um usuário havia excluído uns caminhos aqui no mapa de PoA, e quando
> eu recuperei a informação, ele me disse que o havia feito para "evitar
> invasões" na propriedade que "é de família".
>
> Naturalmente podemos excluir, mas tenho dúvida se:
> - devemos (creio que sim, embora talvez fosse melhor solicitar que a
> pessoa comprovasse de alguma forma que mora realmente onde diz que
> mora, senão é brecha pra vandalismo)
> - como fazemos para evitar que outra pessoa remapeie a via (uma idéia
> é colocar um polígono com uma anotação e sem tags relacionadas ao
> rendering, mas não sei se ficaria claro pros usuários do iD e do
> Potlatch)
>
> Idéias? Opiniões?
>
> --
> Fernando Trebien
> +55 (51) 9962-5409
>
> "The speed of computer chips doubles every 18 months." (Moore's law)
> "The speed of software halves every 18 months." (Gates' law)
>
> ___
> 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: mkgmap

[John Packer]

Paulo, que eu saiba também dá pra usar uma relação chamada
associatedStreet. Isso funciona para o garmin também?

http://wiki.openstreetmap.org/wiki/Relation:associatedStreet

Abs,
João


Em 8 de fevereiro de 2014 15:25, Paulo Carvalho <
paulo.r.m.carva...@gmail.com> escreveu:

> Pessoal,
>
>  Para que a numeração de porta seja compilada para Garmin, é
> necessário que os nós e polígonos que contêm addr:housenumber também tenham
> a tag addr:street com o nome da rua a que fazem referência.
>  Caso já sigam esta recomendação, ignorem a mensagem.
>
> []s
>
> PC
>
> ___
> 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] [SP] Dúvida sobre geocoding reverso com o Nominatim

[John Packer]

Fernando,

Comparei com uma amostra aleatória de Joinville, SC:
http://nominatim.openstreetmap.org/reverse?format=xml&lat=-26.31966&lon=-48.87447&zoom=18&addressdetails=1&accept-language=pt-BR

Em primeiro lugar, problema confirmado. Em segundo lugar, dá pra ver que no
exemplo da Praça da Sé, tem uma coisa a mais que no exemplo acima, a
marcação . *County* é algo que fica entre uma cidade e um estado na
hierarquia, e neste caso é a Região Metropolitana de São
Paulo.
Como pode ver, o *county* é abreviado no caso da Praça da Sé, logo, podemos
tirar a seguinte conclusão: o Nominatim pega a abreviação da posição acima
da cidade, e como neste caso é o *county*, este que é abreviado, o resto
fica normal. (não sei se é exatamente esse critério ou tem a ver com a
etiqueta admin_level)

Abs,
João


Em 9 de fevereiro de 2014 15:23, Fernando Trebien <
fernando.treb...@gmail.com> escreveu:

> Pessoal,
>
> Me perguntaram se eu sabia por que o geocoding reverso do Nominatim
> retorna a sigla de cada estado na tag "state" do XML em todos os
> estados brasileiros, exceto São Paulo. A pessoa me deu como exemplo a
> praça da Sé:
>
>
> http://nominatim.openstreetmap.org/reverse?format=xml&lat=-23.55052&lon=-46.63331&zoom=18&addressdetails=1&accept-language=pt-BR
>
> Olhando as tags, parece que está tudo igual ao resto do país: o estado
> de São Paulo e o seu nó label ambos têm as tags ref e short_name com o
> valor "SP", e a praça da Sé não tem tags is_in nem addr:*.
>
> Alguém sabe explicar? Ou será que é mesmo um bug no Nominatim?
>
> --
> Fernando Trebien
> +55 (51) 9962-5409
>
> "The speed of computer chips doubles every 18 months." (Moore's law)
> "The speed of software halves every 18 months." (Gates' law)
>
> ___
> 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] Como mapear numeração de ruas?

[John Packer]

Olá pessoal,

Um amigo meu foi para "Jaraguá do Sul, SC" e percebeu que as ruas de lá
tinham um número associado com elas. Ele confirmou isso vendo no mapa da
prefeitura.
Então ele colocou esses números na etiqueta ref. Mas a renderização no
Mapnik ficou bem, digamos,
inadequada
.

Como é tratado esse tipo de coisa?
Por mais que seja errado etiquetar para o renderizador, deixar como está
não parece ser uma boa idéia. Será que podemos colocar como "alt_name=Rua
#numero" ?
Será que deveriamos contactar algum mapeador ativo de Jaraguá do Sul?

Abs,
João
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Como etiquetar Churrascarias no Brasil? (e rodízios?)

[John Packer]

Olá pessoal,

Estamos tendo uma discussão na
wiki,
e decidimos trazer para a lista de emails para ouvir mais opiniões.

Vale a pena ler o que já foi discutido, mas o resumo da discussão é: Como
devemos etiquetar uma Churrascaria no Brasil? (além de amenity=restaurant)
Deveria ser cuisine=gaucho ou cuisine=barbecue? (ou até cuisine=steak_house,
que embora não seja documentado, é mais usado que cuisine=barbecue segundo
o taginfo)

O maior problema é que tanto cuisine=gaucho quanto cuisine=barbecue não são
específicos o suficiente para algo que é consideravelmente normal no
Brasil. Deveriamos padronizar um novo valor mais específico e adicionar na
wiki? (provavelmente cuisine=churrascaria)


Outra questão levantada, que é importante a participação da comunidade é:
Como etiquetar se uma churrascaria(ou pizzaria) possui rodízio ou não?
Pessoalmente acho que isso é algo bem relevante e um tanto quanto
específico ao Brasil.
Claro que isso não seria informado pela etiqueta cuisine. A questão é
qual/como?


Abs,
João
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Como etiquetar Churrascarias no Brasil? (e rodízios?)

[John Packer]

Acho que é válido o seu comentário Paulo, mas saibam que no exterior, as
churrascarias brasileiras são conhecidas como "Brazilian Steak House".


Em 9 de fevereiro de 2014 20:00, Paulo Carvalho <
paulo.r.m.carva...@gmail.com> escreveu:

> Cabe um esclarecimento:
> Steak House se refere a restaurantes do tipo Outback, B52, Stadium,etc.
>  Ou seja, casas especializadas em carnes, pode incluir algum churrasco.
> Agora, churrascaria é um tanto diferente disso.  São casas especializadas
> em churrasco, que inclui carnes preparadas dessa forma, mas abrange também
> tudo aquilo que costuma acompanhar churrascos.  Acho que os gaúchos de
> plantão podem definir melhor churrasco do que eu, mas vejo que churrascaria
> é diferente de steak house.
>
> My two cents.
>
>
> Em 9 de fevereiro de 2014 19:33, John Packer escreveu:
>
>> Olá pessoal,
>>
>> Estamos tendo uma discussão na 
>> wiki<http://wiki.openstreetmap.org/wiki/Talk:Pt-br:How_to_map_a#Churrascaria>,
>> e decidimos trazer para a lista de emails para ouvir mais opiniões.
>>
>> Vale a pena ler o que já foi discutido, mas o resumo da discussão é: Como
>> devemos etiquetar uma Churrascaria no Brasil? (além de amenity=restaurant
>> )
>> Deveria ser cuisine=gaucho ou cuisine=barbecue? (ou até
>> cuisine=steak_house, que embora não seja documentado, é mais usado que
>> cuisine=barbecue segundo o taginfo)
>>
>> O maior problema é que tanto cuisine=gaucho quanto cuisine=barbecue não
>> são específicos o suficiente para algo que é consideravelmente normal no
>> Brasil. Deveriamos padronizar um novo valor mais específico e adicionar na
>> wiki? (provavelmente cuisine=churrascaria)
>>
>>
>> Outra questão levantada, que é importante a participação da comunidade é:
>> Como etiquetar se uma churrascaria(ou pizzaria) possui rodízio ou não?
>> Pessoalmente acho que isso é algo bem relevante e um tanto quanto
>> específico ao Brasil.
>> Claro que isso não seria informado pela etiqueta cuisine. A questão é
>> qual/como?
>>
>>
>> Abs,
>> Joã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
>
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Como etiquetar Churrascarias no Brasil? (e rodízios?)

[John Packer]

É verdade, tem uma etiqueta
self_service=yes/no/only<http://taginfo.openstreetmap.org/keys/self_service#values>,
que é utilizada em postos de
combustível<http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dfuel>
.

Gostei da sugestão, podemos usar self_service=no, mas será que tem alguma
etiqueta buffet ou all_you_can_eat para clarificar que é um rodízio, e não
simplesmente atendimento na mesa?


Em 9 de fevereiro de 2014 20:01, Paulo Carvalho <
paulo.r.m.carva...@gmail.com> escreveu:

> Quanto ao rodízio, não haveria algo como selfservice=true?
>
>
> Em 9 de fevereiro de 2014 19:33, John Packer escreveu:
>
>> Olá pessoal,
>>
>> Estamos tendo uma discussão na 
>> wiki<http://wiki.openstreetmap.org/wiki/Talk:Pt-br:How_to_map_a#Churrascaria>,
>> e decidimos trazer para a lista de emails para ouvir mais opiniões.
>>
>> Vale a pena ler o que já foi discutido, mas o resumo da discussão é: Como
>> devemos etiquetar uma Churrascaria no Brasil? (além de amenity=restaurant
>> )
>> Deveria ser cuisine=gaucho ou cuisine=barbecue? (ou até
>> cuisine=steak_house, que embora não seja documentado, é mais usado que
>> cuisine=barbecue segundo o taginfo)
>>
>> O maior problema é que tanto cuisine=gaucho quanto cuisine=barbecue não
>> são específicos o suficiente para algo que é consideravelmente normal no
>> Brasil. Deveriamos padronizar um novo valor mais específico e adicionar na
>> wiki? (provavelmente cuisine=churrascaria)
>>
>>
>> Outra questão levantada, que é importante a participação da comunidade é:
>> Como etiquetar se uma churrascaria(ou pizzaria) possui rodízio ou não?
>> Pessoalmente acho que isso é algo bem relevante e um tanto quanto
>> específico ao Brasil.
>> Claro que isso não seria informado pela etiqueta cuisine. A questão é
>> qual/como?
>>
>>
>> Abs,
>> Joã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
>
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Como etiquetar Churrascarias no Brasil? (e rodízios?)

[John Packer]

>
> Mas quem define o valor do termo a ser buscado é o serviço que utiliza o
> mapa, não importando o valor da tag em si. A tag é em usada em inglês,
> preferencialmente britânico (pois o OSM nasceu lá).
>


> Acho que poderia ser cuisine=bbq ou cuisine=steak ou
> cuisine=brazilian_steak.
>
Se for pra criar um valor novo(ao invés de usar gaúcho ou barbecue), creio
que cuisine=churrascaria seja o mais apropriado, já que é um termo
reconhecido em alguns países
<https://en.wikipedia.org/wiki/Churrascaria>como uma churrascaria
brasileira. (e como bônus, alguns novatos já
colocam esse valor
mesmo<http://taginfo.openstreetmap.org/tags/cuisine=churrascaria>
)



Em 9 de fevereiro de 2014 20:39, Arlindo Pereira <
openstreet...@arlindopereira.com> escreveu:

> Mas quem define o valor do termo a ser buscado é o serviço que utiliza o
> mapa, não importando o valor da tag em si. A tag é em usada em inglês,
> preferencialmente britânico (pois o OSM nasceu lá).
>
> Acho que deveria ser algo do tipo "all_you_can_eat=yes" ou
> "smorgasbord=yes", para denotar os estabelecimentos que você pode comer o
> quanto quiser por um preço fixo. Dessa forma, uma aplicação poderia fazer
> uma busca especificamente por esse tipo de restaurante.
>
> []s
> Em 09/02/2014 20:10, "Paulo Carvalho" 
> escreveu:
>
>  Bom, acho que devemos pensar nos brasileiros.  Eu procuraria por
>> churrascaria e não steak house se eu quero comer churrasco.
>>
>>
>> Em 9 de fevereiro de 2014 20:02, John Packer 
>> escreveu:
>>
>>> Acho que é válido o seu comentário Paulo, mas saibam que no exterior, as
>>> churrascarias brasileiras são conhecidas como "Brazilian Steak House".
>>>
>>>
>>> Em 9 de fevereiro de 2014 20:00, Paulo Carvalho <
>>> paulo.r.m.carva...@gmail.com> escreveu:
>>>
>>>> Cabe um esclarecimento:
>>>> Steak House se refere a restaurantes do tipo Outback, B52, Stadium,etc.
>>>>  Ou seja, casas especializadas em carnes, pode incluir algum churrasco.
>>>> Agora, churrascaria é um tanto diferente disso.  São casas
>>>> especializadas em churrasco, que inclui carnes preparadas dessa forma, mas
>>>> abrange também tudo aquilo que costuma acompanhar churrascos.  Acho que os
>>>> gaúchos de plantão podem definir melhor churrasco do que eu, mas vejo que
>>>> churrascaria é diferente de steak house.
>>>>
>>>> My two cents.
>>>>
>>>>
>>>> Em 9 de fevereiro de 2014 19:33, John Packer 
>>>> escreveu:
>>>>
>>>>> Olá pessoal,
>>>>>
>>>>> Estamos tendo uma discussão na 
>>>>> wiki<http://wiki.openstreetmap.org/wiki/Talk:Pt-br:How_to_map_a#Churrascaria>,
>>>>> e decidimos trazer para a lista de emails para ouvir mais opiniões.
>>>>>
>>>>> Vale a pena ler o que já foi discutido, mas o resumo da discussão é:
>>>>> Como devemos etiquetar uma Churrascaria no Brasil? (além de
>>>>> amenity=restaurant)
>>>>> Deveria ser cuisine=gaucho ou cuisine=barbecue? (ou até
>>>>> cuisine=steak_house, que embora não seja documentado, é mais usado
>>>>> que cuisine=barbecue segundo o taginfo)
>>>>>
>>>>> O maior problema é que tanto cuisine=gaucho quanto cuisine=barbecuenão 
>>>>> são específicos o suficiente para algo que é consideravelmente normal
>>>>> no Brasil. Deveriamos padronizar um novo valor mais específico e adicionar
>>>>> na wiki? (provavelmente cuisine=churrascaria)
>>>>>
>>>>>
>>>>> Outra questão levantada, que é importante a participação da comunidade
>>>>> é:
>>>>> Como etiquetar se uma churrascaria(ou pizzaria) possui rodízio ou não?
>>>>> Pessoalmente acho que isso é algo bem relevante e um tanto quanto
>>>>> específico ao Brasil.
>>>>> Claro que isso não seria informado pela etiqueta cuisine. A questão é
>>>>> qual/como?
>>>>>
>>>>>
>>>>> Abs,
>>>>> Joã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
>>>>
>>>>
>>>
>>> ___
>>> 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 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] Dúvida formatação

[John Packer]

Acredito que seja highway=service + psv=yes + taxi=yes + bus=yes

Veja psv=* 


Em 9 de fevereiro de 2014 21:38, Paulo Carvalho <
paulo.r.m.carva...@gmail.com> escreveu:

> Pessoal,
>
>Como configurar uma via que permite táxis e ônibus, mas não permite
> veículos particulares?
>
> []s
>
> PC
>
> ___
> 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] [SC][Joinville] Lista de email de Joinville

[John Packer]

Ok, obrigado pelos conselhos.

Segui as suas recomendações e criei uma página na wiki.
Segue link:
https://wiki.openstreetmap.org/wiki/WikiProject_Brazil/SC/Joinville

Exclui a lista de email do Google Groups, vamos continuar por aqui então.

Abs,
João


Em 29 de janeiro de 2014 16:12, Arlindo Pereira <
openstreet...@arlindopereira.com> escreveu:

> Eu prefiro manter uma lista só, usando [SC][Joinville] na frente. O
> tráfego no começo vai ser pequeno, os participantes da lista menor não vão
> perder os posts da lista maior, e se o tráfego ficar muito grande, só quem
> não estiver interessado criar filtros.
>
>
> []s
> Arlindo
>
> 2014-01-29 Fernando Trebien 
>
> John, talvez seja interessante criar um espaço no wiki para Joinville
>> (aqui:
>> https://wiki.openstreetmap.org/wiki/WikiProject_Brazil/SC/Joinville).
>> Não conheço tudo que há por aí, mas sugiro usar como exemplo:
>> -
>> https://wiki.openstreetmap.org/wiki/WikiProject_Brazil/RJ/Rio_de_Janeiro
>> -
>> https://wiki.openstreetmap.org/wiki/WikiProject_Brazil/MG/Belo_Horizonte
>> - https://wiki.openstreetmap.org/wiki/WikiProject_Brazil/ES/Vit%C3%B3ria
>> -
>> https://wiki.openstreetmap.org/wiki/WikiProject_Brazil/SC/Florian%C3%B3polis
>> - https://wiki.openstreetmap.org/wiki/WikiProject_Brazil/RS/Porto_Alegre
>> (atualmente mantida por mim na maior parte do tempo)
>>
>> Acho interessante também buscar inspiração em cidades do exterior
>> (onde a comunidade é mais ativa), por exemplo:
>> - https://wiki.openstreetmap.org/wiki/Berlin
>> - https://wiki.openstreetmap.org/wiki/Wien
>> - https://wiki.openstreetmap.org/wiki/London
>> - https://wiki.openstreetmap.org/wiki/Paris
>> - https://wiki.openstreetmap.org/wiki/Stockholm
>> - https://wiki.openstreetmap.org/wiki/Warsaw
>> - https://wiki.openstreetmap.org/wiki/Praha
>> - https://wiki.openstreetmap.org/wiki/San_Francisco,_California
>>
>> Embora o Google Groups seja mais prático, dá pra fazer praticamente
>> tudo com o wiki também, já que cada artigo tem uma página de discussão
>> própria. Nada impede que você use a lista talk-br pra discutir sobre
>> Joinville também, basta fazer como você fez agora, ainda mais se você
>> fizer como fez agora (colocando [SC][Joinville] no assunto).
>>
>> Outra idéia seria criar um tópico no fórum sobre Joinville, postando
>> links pro seu grupo e para o wiki.
>>
>> Se precisar de ajuda, só avisar.
>>
>> 2014-01-28 John Packer :
>> > Amigos, criei uma lista de email para a comunidade de Joinville.
>> >
>> > É uma comunidade bem pequena atualmente, e os bairros menores estão
>> sofrendo
>> > com falta de ruas. Quero tentar aproximar mais esta comunidade e fazer
>> mais
>> > propaganda para que pessoas normais possam apontar erros e adições
>> também.
>> >
>> > O link para a lista de email é o seguinte:
>> > https://groups.google.com/forum/#!forum/openstreetmap-joinville-sc
>> >
>> > Abs,
>> > João
>> >
>> > ___
>> > Talk-br mailing list
>> > Talk-br@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-br
>> >
>>
>>
>>
>> --
>> Fernando Trebien
>> +55 (51) 9962-5409
>>
>> "The speed of computer chips doubles every 18 months." (Moore's law)
>> "The speed of software halves every 18 months." (Gates' law)
>>
>> ___
>> 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 mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Dados suspeitos sem resposta dos autores

[John Packer]

Eu geralmente não comento nestas questões por não saber muito o que dizer.
Mas acho que é uma preocupação válida, é um perigo real.
Pode ser um pouco desanimador retirar dados do mapa, mas é muito pior se
dados legítimos tem que ser retirados por causa de um início ilegal. O que,
se for o caso, pode acontecer quer queiramos ou não.

Na minha opinião, as situações mais críticas(mais urgentes) são (1) os
conjuntos de alteração que claramente são importações, sem resposta do
autor, e com fonte suspeita(pior ainda se remover dados anteriores) e (2)
as adições/alterações baseadas no Google.

Quanto ao (2), devo confessar que teve um caso que um usuário aqui tinha
como etiqueta source:http://maps.google.com e simplesmente apaguei esta
etiqueta, MAS neste caso como encontrei somente aquela rua com aquela
etiqueta, ficou claro para mim que o usuário conhecia aquela rua e só tinha
colocado aquela etiqueta por confusão e/ou usou para confirmar a informação.

Acho que o Google Maps como fonte é bem problemático, porquê é longe de ser
improvável os erros dele; às vezes tenho a impressão que os dados nele são
adicionados por algumas pessoas usando imagem satélite e um mapa, copiando
manualmente, pois no meu bairro tem vários errinhos e "erros-por-um"(ruas
paralelas com o nome da anterior a ela). Não que seria "ok" ter ele como
fonte se não tivesse esses errinhos.

Abs,
João



Em 9 de fevereiro de 2014 22:30, Nelson A. de Oliveira
escreveu:

> 2014-02-09 22:24 GMT-02:00 Paulo Carvalho :
> > Acho que você tem que relaxar mais, confiar mais nas pessoas.
>
> Geralmente confio, mas não quando fica muito claro para mim que não
> foi a pessoa que fez o trabalho (ou que obteve dados de algum local
> que não pode).
>
> E fico pensando: temos 159 pessoas na lista e só eu me incomodo com
> isso? Tudo o resto não está nem aí?
>
> ___
> 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] Dados suspeitos sem resposta dos autores

[John Packer]

>
> Mas no fim das contas, o que é ilegal em se tratando de mapeamento de
> áreas públicas? As áreas são publicas, as informações sobre elas também,
> estão lá para quem quiser ver. Acho que não é o caso de verificarmos a
> legalidade das fontes, mas a veracidade das informações. Se as informações
> estão corretas e não há mais indícios da suposta importação de dados,
> sempre poderemos alegar que a entrada de dados é original.

O problema é que mapas sempre têm erros. Se um mapa 1 possui um erro e um
mapa 2 tem o mesmo erro, é uma evidência que o segundo mapa que adicionou a
informação foi o que copiou. É até possível que um mapa adicione erros
propositalmente(por exemplo adicionando uma rua que não existe) para pegar
outros mapas que copiem. (embora eu não saiba de um caso assim para mapas,
já vi do Google(serviço de pesquisa) fazendo isso pra pegar o Bing, e de um
dicionário fazer isso para pegar outro)
Como eu citei antes, aqui no meu bairro tem vários errinhos de ruas no
Google Maps.

E eu acho que na maioria das vezes é mais fácil remover e colocar
informações novas e verdadeiras do que verificar dados já existentes.

Remover as etiquetas que indicam ilegalidade e/ou importação não resolve
nada. Elas sempre vão estar lá no histórico de versões anteriores e/ou
conjuntos de alterações anteriores.



Em 9 de fevereiro de 2014 23:01, Márcio Vinícius Pinheiro <
marcioviniciu...@gmail.com> escreveu:

> Não se trata de não estar "nem aí" e concordo com o Paulo Carvalho. Acho
> que em qualquer sistema colaborativo, digital ou não, sempre haverá o risco
> de se "ter o trabalho perdido", é um risco que nunca vai deixar de existir
> por uma série de fatores inerentes ao sistema. É óbvio que aqui temos a
> possibilidade de discutir esse trabalho antes de perdê-lo (muito embora o
> sujeito em questão parece não comparecer aos canais de discussão no último
> mês). O problema é que tais suspeitas, se exageradas e não confirmadas,
> podem também resultar no trabalho perdido de outra pessoa.
>
> Tudo no seu discurso é dúvida, "tags estranhas" (que pela experiência do
> Paulo não são tão estranhas assim), "source=Google" (que pode ou não ser
> confusão), e como você mesmo disse não podemos nem confirmar, nem
> desconfirmar a "legalidade" dessas informações até o suposto autor (ou
> importador) se pronunciar. Enquanto isso não ocorre, o que se pode fazer
> nesse caso é esperar. Você pode ou não fazer o que o Paulo sugeriu, limpar
> traços da suposta ilegalidade e seguir em frente. Se se sente à vontade
> para fazê-lo, ótimo. Se não, pare de contribuir e ótimo também para a sua
> consciência. Mas no fim das contas, o que é ilegal em se tratando de
> mapeamento de áreas públicas? As áreas são publicas, as informações sobre
> elas também, estão lá para quem quiser ver. Acho que não é o caso de
> verificarmos a legalidade das fontes, mas a veracidade das informações. Se
> as informações estão corretas e não há mais indícios da suposta importação
> de dados, sempre poderemos alegar que a entrada de dados é original.
>
> P.S. Sou novo aqui (apesar de registrado desde 2008, nem sei se alguém me
> perguntou algo ao longo desses anos todos), não sei bem se há alguma
> instância no OSM a quem se pode denunciar possíveis vândalos,
> contraventores ou criminosos,
>
> - - - ·
> Atenciosamente,
>
> Márcio Vinícius Pinheiro
> http://about.me/Doideira
> 
>
>
> Em 9 de fevereiro de 2014 22:30, Nelson A. de Oliveira 
> escreveu:
>
> 2014-02-09 22:24 GMT-02:00 Paulo Carvalho :
>> > Acho que você tem que relaxar mais, confiar mais nas pessoas.
>>
>> Geralmente confio, mas não quando fica muito claro para mim que não
>> foi a pessoa que fez o trabalho (ou que obteve dados de algum local
>> que não pode).
>>
>> E fico pensando: temos 159 pessoas na lista e só eu me incomodo com
>> isso? Tudo o resto não está nem aí?
>>
>> ___
>> 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 mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Dados suspeitos sem resposta dos autores

[John Packer]

Marcelo,

Já existe um manual básico, e em português:
http://wiki.openstreetmap.org/wiki/Pt-br:Beginners_Guide
Uma alternativa é o LearnOSM http://learnosm.org/pt/

Pessoalmente eu já acho díficil encontrar pessoas para mapear, o editor web
iD já foi criado com o objetivo de facilitar essa iniciação(não está
perfeito, mas está muito bom), se for pedir para lerem um manual só para
mapear algo rápido, quantos que vão ler e/ou continuar mapeando?

Temos que ver como facilitar aos usuários encontrar essa informação.
Uma sugestão minha seria: Se, nos primeiros conjuntos de alteração de um
usuário, ele adicionar um número elevado de vias (digamos, mais de 20), o
OSM pergunta se ele está ciente sobre as licenças, e aponta para o guia
para iniciantes.
Se concordarem, eu mesmo abro essa questão no repositório de
desenvolvimento do iD (editor web do OSM).

e além disso alguma ferramenta que listasse os novos mappers, para que
> fosse possível enviar uma mensagem de boas vindas, explicando a importância
> de não se mapear copiando de fontes sem licença adequada.
>
Para ver os mapeadores novos e atividade de uma região, tem as fontes
*newestosm* e o WHODIDIT que dá pra conseguir neste site:
http://tyrasd.github.io/osm-qa-feeds/
Como tem relativamente pouca atividade na minha região, eu me dou o
privilégio de dar as boas vindas. Felizmente não cheguei a ver nenhum caso
suspeito até agora.



Em 9 de fevereiro de 2014 23:37, Marcelo Pereira
escreveu:

> Minha intromissão.
>
> Acho que uma parte importante neste tipo de problema é a falta de
> informação ao novato, o OSM faz de tudo para vc se cadastrar e começar
> mapeando, mas não indica listas de discussão e fóruns de usuários para
> contato com outros mappers.
>
> Daí o cara, vê que no OSM não tem uma info que facilmente ele encontra no
> Google, e copia.
>
> Meses depois alguém descobre o erro e vai atrás, tendo como única
> ferramenta a reversão dos dados.
>
> Para mim isso parece ser meio conflitante, para não dizer esquizofrênico.
>
> Talvez fosse mais interessante que existisse um "manual básico" indicando
> o que fazer e o que não fazer logo no início, e além disso alguma
> ferramenta que listasse os novos mappers, para que fosse possível enviar
> uma mensagem de boas vindas, explicando a importância de não se mapear
> copiando de fontes sem licença adequada.
>
>
>
>
> Em 9 de fevereiro de 2014 22:28, Márcio Vinícius Pinheiro <
> marcioviniciu...@gmail.com> escreveu:
>
> Eu como novato, não teria nem me atentado para isso se não tivesse lido
>> essa discussão aqui. Como talvez, não esteja me atentando para outros fatos
>> que podem gerar o mesmo problema. Se eu observasse algo que me causasse
>> dúvida, faria o que você fez, perguntaria alguém mais experiente o que ele
>> acha. Tendo lido tudo isso aqui, acho que as melhores propostas são a do
>> Paulo Carvalho e a do Victor George. Talvez seguisse essas sugestões.
>> Esperaria o possível resultado do questionamento à Data Working Group, e
>> caso não resultasse em nada, faria limparia as tags estranhas, retiraria as
>> fontes duvidosas e seguiria com o trabalho. Mas acho também válido você
>> deixar pra lá se as dúvidas te afligem tanto.
>>
>> Até agora só entrei com dados que eu mesmo criei (baseado em mapeamentos
>> no local e legislação urbanística), não me deparei com problemas assim e
>> também não citei fonte alguma (já que em última instância a fonte sou eu
>> mesmo). Fiz pequenos reparos em coisas já prontas e nem me atentei para a
>> origem dessas coisas e, por ser pouca coisa, não ficaria tão chateado em
>> ter perdido esse tempo.
>>
>> Eu ficaria muito chateado se perdesse o que demorei horas fazendo por
>> causa de um vandalismo qualquer, mas não por uma coisa que eu sabia que
>> tinha chance de ser "censurada". Pensaria mil vezes antes de repetir o
>> mesmo erro, mas teria sido um risco que teria corrido conscientemente.
>>
>> - - - ·
>> Atenciosamente,
>>
>> Márcio Vinícius Pinheiro
>> http://about.me/Doideira
>>  
>>
>>
>> Em 9 de fevereiro de 2014 23:04, Nelson A. de Oliveira 
>> escreveu:
>>
>> Márcio, vou te fazer a mesma pergunta: você colaboraria em cima desses
>>> dados sem nenhum problema então?
>>>
>>> Mas de qualquer forma, boa sorte para quem for colaborar em cima desses
>>> dados.
>>> Não vou mais insistir nesses casos.
>>>
>>> ___
>>> 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
>>
>>
>
>
> --
>
> ... Edileuz, eu não tem nada a ver com Creuza,
>É mentira da Ivete, não é meu esse caniveete...
> "Halley, Luiz" - Poeta, Cantor, Compsitor
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/

Re: [Talk-br] Dados suspeitos sem resposta dos autores

[John Packer]

Concordo com o Roger e o Fernando.


Em 10 de fevereiro de 2014 01:14, Fernando Trebien <
fernando.treb...@gmail.com> escreveu:

> Se a suspeita for grave (ex. cópia de dados com copyright) e a pessoa não
> me responde em 1 semana, eu reverto. Não é tão grave reverter porque a
> própria reversão pode ser revetida posteriormente, caso o usuário acabe
> dando uma explicação válida. Me preocupo continuamente em não ser
> "autoritário" nas minhas decisões e se tivesse algumas dúvidas postaria o
> caso aqui em detalhes antes de reverter.
>
> Faço bastante esforço pra consertar pequenos enganos também, que não são
> motivo pra reversão (qualidade se aprende com a experiência né, e muitos
> desses enganos são culpa das próprias ferramentas de mapeamento que
> induziram a pessoa ao erro; volta e meia penso que devíamos parar pra
> discutir quais erros são comuns e como os editores podem ser melhorados pra
> evitá-los).
>
> Se tiver bastante certeza que está errado ou que é ilegal, eu explico bem
> a razão pra reversão no comentário do changeset, mencionando também o
> silêncio do usuário ao ser questionado. Se a pessoa achar isso autoritário,
> ela sempre pode vir aqui na lista reclamar, e se não o faz é porque
> concorda ou porque não se importa a ponto de querer se envolver com a
> comunidade.
>  On Feb 9, 2014 9:13 PM, "Nelson A. de Oliveira"  wrote:
>
>> O que se faz quando suspeitamos de algumas coisas, perguntamos aos
>> autores, esperamos muito tempo e não obtemos nenhum tipo de resposta?
>> Deixamos os dados do jeito que está, ignoramos, removemos, o que fazemos?
>>
>> ___
>> 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 mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Como mapear numeração de ruas?

[John Packer]

Pedi clarificações para ele. Segue abaixo a resposta:

> Então, desde que eu era pequeno me chamava a atenção isso (não sei por quê
> hahahaha), e em Joinville também era comum essa prática de numerar as ruas,
> mas de repente não se usou mais isso. Mas em Jaraguá as ruas recebem
> números e nomes, as vezes só números. Em tudo o que se refere a ruas, como
> mapas, as placas com nomes das ruas, vai o número, sempre antes do nome.
>
> Enfim, como todas as ruas e servidões têm um número e um nome, acredito
> que seja um código da prefeitura, embora seja popular e bastante utilizado,
> mas não sendo nem nome alternativo, nem nome antigo... não sei dizer qual
> seria a tag mais adequada para essa numeração.
>

Fico em dúvida como proceder.
A minha impressão é que realmente ref é a etiqueta adequada, mas a
visualização do mapa fica bem inadequada...
Pedi para ele contactar algum mapeador ativo de Jaraguá do Sul (espero que
tenha algum mapeador experiente nessa região)

Vou pedir para ele passar o link do mapa que verificou.

Abs,
João


Em 9 de fevereiro de 2014 20:32, Arlindo Pereira <
openstreet...@arlindopereira.com> escreveu:

> Se a numeração for o nome da rua (Rua 1, Rua 2 etc.) coloque "Rua Um" na
> tag name e "Rua 1" na tag alt_name (ou o contrário, se preferir). A tag
> alt_name não aparece na renderização do mapa mas é usada pelos serviços de
> busca, e poderia ser usada por roteadores GPS.
>
> Se for o nome antigo (Rua Fulano de Tal, antiga Rua 1) coloque na tag
> old_name.
>
> []s
> Em 09/02/2014 19:08, "John Packer"  escreveu:
>
>>  Olá pessoal,
>>
>> Um amigo meu foi para "Jaraguá do Sul, SC" e percebeu que as ruas de lá
>> tinham um número associado com elas. Ele confirmou isso vendo no mapa da
>> prefeitura.
>> Então ele colocou esses números na etiqueta ref. Mas a renderização no
>> Mapnik ficou bem, digamos, 
>> inadequada<http://www.openstreetmap.org/#map=16/-26.4559/-49.1055>
>> .
>>
>> Como é tratado esse tipo de coisa?
>> Por mais que seja errado etiquetar para o renderizador, deixar como está
>> não parece ser uma boa idéia. Será que podemos colocar como "alt_name=Rua
>> #numero" ?
>> Será que deveriamos contactar algum mapeador ativo de Jaraguá do Sul?
>>
>> Abs,
>> Joã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
>
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Sobre marcas(tags)

[John Packer]

Concordo com o Fernando.
Esse tipo de coisa é feito em uma base de dados a parte devido a
volatilidade.

Cristiano,

Recomendo usar para o preço, um ponto como separador decimal, ao invés de
uma vírgula.
Pelo menos é assim que é o padrão OSM.
Por exemplo seria fuel:gnc:price=2.77 ao invés de 2,77 .

Para fuel:*type*:currency=*, poderia fazer o seguinte: a moeda padrão é a
do país onde está localizado, senão deve ser especificado utilizando o
padrão ISO 4217 .
Uma alternativa é colocar isso opcionalmente no final do preço.

Mas talvez seja melhor em primeiro lugar dar uma olhada no OSMFuel para ver
se dá pra utilizar.

Abs,
João



Em 10 de fevereiro de 2014 10:17, Fernando Trebien <
fernando.treb...@gmail.com> escreveu:

> Copiei pra lista então.
>
> Complicado não é, o problema é que a volatilidade da informação
> geraria um grande número de changesets e isso seria mais um peso na
> base de dados do OSM, que foi feita pra armazenar informação menos
> mutável. Seriam 4 vezes ao ano se só você estivesse editando, mas no
> futuro teria gente mudando diariamente o preço do combustível. O
> resultado é que o histórico do elemento geométrico ficaria enorme e
> difícil de gerenciar depois.
>
> Nada impede que alguém desenvolva um app baseado no OSM pra fazer isso
> "por fora", só que ninguém fez ainda. O Waze, por ser comercial,
> consegue financiar o desenvolvimento desses recursos; no OSM tudo
> depende de alguém com vontade e tempo pra se dedicar, ou também com
> boas idéias pra ganhar dinheiro com isso.
>
> 2014-02-10 0:48 GMT-02:00 Cristiano Sumariva :
> > Olha acredito que sim.
> > Não me parece ser tão ruim e complicado armazenar isso.
> >
> > Me mostraram algo parecido, acho que no aplicativo waze.
> > Quando o navegador chega próximo a um posto o mesmo solicita se deseja
> > contribuir a lista de preços.
> > Basta digitar os valores e pronto.
> > E um próximo navegante que baixar a atualização da base não será
> convidado a
> > atualizar novamente se dentro de um período de 90 dias por exemplo.
> > Não vejo problemas em responder isso 4 vezes ao ano para alguns postos
> por
> > onde passar.
> >
> >
> > Em 9 de fevereiro de 2014 17:54, Fernando Trebien
> >  escreveu:
> >
> >> Olá Cristiano,
> >>
> >> Eu duvido que alguém aprovaria armazenar os preços dos combustíveis no
> >> próprio mapa do OSM porque essa informação é muito volátil. O ideal
> >> nesses casos é ter uma aplicação à parte (que só usa o OSM para saber
> >> a localização do posto). Parece que é isso que este site tenta fazer:
> >> http://www.osmfuel.org/
> >>
> >> Por alguma razão, ele está lendo só 2 postos de combustível em Porto
> >> Alegre, então talvez não funcione direito ainda, eu teria que
> >> pesquisar mais. Posso repostar sua pergunta pra lista talk-br?
> >>
> >> 2014-02-09 Cristiano Sumariva :
> >> > Eu acrescentei alguns postos de combustível ausentes durante a viagem.
> >> > Como posso colocar os valores dos combustíveis?
> >> >
> >> > Algo como fuel:gnc:price  2,77.
> >> >
> >> > Fica em aberto como colocar a moeda do preço. Ou fica implícito
> conforme
> >> > o
> >> > país onde o nó está localizado?
> >> >
> >> > fuel:gnc:currency: real
> >> >
> >> > Tem a questão dos combustíveis também.
> >> >
> >> > Eu marquei como
> >> > fuel:e85 que quase  igual ao nosso álcool ( 90% e 10% água ).
> >> >
> >> > Achei também a tag fuel:alcohol.
> >> >
> >> > Me interesso por isso para poder tornar capaz o aplicativo OSMAND a me
> >> > guiar
> >> > para os postos de combustíveis com gas que são poucos e a autonomia
> >> > baixa.
> >>
> >>
> >>
> >> --
> >> Fernando Trebien
> >> +55 (51) 9962-5409
> >>
> >> "The speed of computer chips doubles every 18 months." (Moore's law)
> >> "The speed of software halves every 18 months." (Gates' law)
> >
> >
>
>
>
> --
> Fernando Trebien
> +55 (51) 9962-5409
>
> "The speed of computer chips doubles every 18 months." (Moore's law)
> "The speed of software halves every 18 months." (Gates' law)
>
> ___
> 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] Nomeação de trechos de ruas + área ao redor

[John Packer]

Paulo, acredito que essas feiras são amenity=marketplace.
http://wiki.openstreetmap.org/wiki/Marketplace

Se não tiver na página de referência da wiki, já é algo a mais pra
adicionar.

Abs,
João



Em 12 de fevereiro de 2014 08:53, Paulo Carvalho <
paulo.r.m.carva...@gmail.com> escreveu:

> Em Rio das Ostras, RJ, marquei "a feirinha" no local onde acontece (Av.
> Amazonas) com um POI de shopping chamado "Feirinha".  Não sei se cabe
> desenhar um polígono delimitando a área onde as barracas são armadas.
>
>
> Em 12 de fevereiro de 2014 00:58, Nelson A. de Oliveira 
> escreveu:
>
> Como vocês marcam áreas que englobam a rua e possivelmente as
>> edificações ao redor?
>>
>> Exemplos para entender melhor:
>> Esse bulevar: http://goo.gl/maps/6OIok
>> Ele pega um bom trecho dessa rua e é composto, além da rua
>> propriamente dita, das árvores, calçadas, bancos e coisas do gênero ao
>> longo do trecho.
>>
>> Pequenos centros comerciais como esse: http://goo.gl/maps/ARDTP
>> Nesse caso é apenas um quarteirão composto da rua + lojas em ambos os
>> lados, com um determinado nome para toda essa área.
>>
>> ___
>> 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 mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Problema de usabilidade do editor de endereços do iD

[John Packer]

Pessoal,

Eu abri um relatório de bug para o editor iD, e gostaria que se possível
fizessem algum comentário que achem relevante na página do relatório.

O relatório está no Github no seguinte link:
https://github.com/openstreetmap/iD/issues/2124

Abs,
João
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Roteamento para bicicleta

[John Packer]

Talvez seja um pouco fora do tópico, mas alguém aqui coloca algum valor que
não seja yes para a etiqueta incline?
Se sim, vocês calculam pelo "olhômetro", ou usam alguma ferramenta e/ou
procuram pelos dados em algum lugar?


Em 12 de fevereiro de 2014 18:44, Fernando Trebien <
fernando.treb...@gmail.com> escreveu:

> Alguém (acho que foi o Nelson) mencionou um tempo atrás esse serviço:
> http://open.mapquest.com.br/
>
> E eu lembro que eu tinha achado que ele não considera a inclinação do
> terreno ao calcular rotas pra bicicleta. Não é verdade, eu que não
> tinha visto tudo. Ele desconsidera por padrão, mas pra considerar tem
> que:
> - clicar em "Obter Direcções"
> - clicar na bicicleta pra mudar o modo de roteamento
> - clicar em "Opções de Bicicleta"
> - em "Estratégia de Inclinação da Estrada" escolher "Evitar Subida"
> (poderia ser o padrão né)
> - preencher os campos "partida" e "fim" e fazer a busca
>
> Testei, e realmente faz diferença, as rotas passam a evitar subidas.
> Tem também um link "Ver Elevação" no resultado, que não está
> funcionando, mas que provavelmente geraria uma imagem com o perfil de
> altitude ao longo da rota.
>
> O mais legal é que aqui em Porto Alegre o sistema já está usando
> vários caminhos que eu mapeei que passam por dentro de parques e
> praças. Pelo pouco que eu testei, parece haver preferência por
> ciclovia e custos pra atravessar a rua, parece bem completo.
> Inclusive, me motivou a revisar os cruzamentos em grandes avenidas.
> Pena que a frenquência de atualização seja meio longa (pelo menos
> alguns dias, talvez algumas semanas).
>
> Pelo visto ele suporta ciclofaixas também, já que ele me manda na
> contramão da direção principal desta via onde há uma ciclofaixa de mão
> dupla: http://mapq.st/1m8TLY6
>
> --
> Fernando Trebien
> +55 (51) 9962-5409
>
> "The speed of computer chips doubles every 18 months." (Moore's law)
> "The speed of software halves every 18 months." (Gates' law)
>
> ___
> 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] Problema de usabilidade do editor de endereços do iD

[John Packer]

> Eu mudei a tradução de "nome da casa" para "complemento", isso já deve
> ajudar.

Sim, foi uma boa idéia, vai ajudar um pouco.
Falando nisso, estava pensando se não seria melhor no addr:housenumbercolocar "
*Número*" ou "*Nº*" ao invés de "*123*". O que acha?

Eu duvido que eles localizem a interface (com tantas coisas ainda por
> fazer), já que na maioria dos países europeus e na América do Norte essa é
> a ordem dos campos do endereço.

Pois é, eu estava vendo o número gigantesco de coisas que eles têm a fazer.
Vou tentar "colocar a mão na massa" pra fazer isso ir pra frente.
Eu pretendo esperar mais ou menos 1 semana por uma resposta deles. Depois
disso eu vou alterar o código e mandar pra eles corrigirem. Já dei uma
olhada onde tem que alterar, só estou um pouco preocupado que o código não
ficaria muito limpo colocando um caso específico para a linguagem português
brasileiro no meio(isso tenho que ver com eles).

Falando nisso, alguém sabe se os endereços dos outros países da América
Latina são parecidos? E de Portugal?

Alguma aplicação já suporta a tag addr:door? O que iria nessa tag,
> apenas um número ou uma descrição como "Sala 204", "Salas 204 e 205"
> ou "Conjunto 501"?
>
Não sei se tem alguma aplicação que utiliza(não sei nem se o Nominatim
suporta), porém ela está documentada na wiki.
Como valor iria somente "204" do "Sala 204", "204;205" do "Salas 204 e 205".
Quando ao "Conjunto 501", teria que ser addr:unit=501.
Peraí, então o addr:door não funciona pra todos os casos? Exatamente, não
tem nenhuma etiqueta que cubra todos os casos para o "Complemento" de um
endereço(que seria um addr:additional_information=*); creio que o mais
perto é colocar o endereço completo no addr:full.
Eu estou aberto a sugestões, mas vou jogar duas idéias aqui:
1. Retirar o campo para "Complemento". (falando nisso, alguém sabe onde os
usuários atualmente colocam o complemento? Provavelmente no addr:housename,
certo?
2. Ao invés de colocar o campo "Complemento", colocar "Apt/Sala" E
"Conjunto".



Em 12 de fevereiro de 2014 20:36, Fernando Trebien <
fernando.treb...@gmail.com> escreveu:

> Eu mudei a tradução de "nome da casa" para "complemento", isso já deve
> ajudar.
>
> Eu duvido que eles localizem a interface (com tantas coisas ainda por
> fazer), já que na maioria dos países europeus e na América do Norte
> essa é a ordem dos campos do endereço.
>
> Alguma aplicação já suporta a tag addr:door? O que iria nessa tag,
> apenas um número ou uma descrição como "Sala 204", "Salas 204 e 205"
> ou "Conjunto 501"?
>
> 2014-02-12 18:17 GMT-02:00 John Packer :
> > Pessoal,
> >
> > Eu abri um relatório de bug para o editor iD, e gostaria que se possível
> > fizessem algum comentário que achem relevante na página do relatório.
> >
> > O relatório está no Github no seguinte link:
> > https://github.com/openstreetmap/iD/issues/2124
> >
> > Abs,
> > João
> >
> > ___
> > Talk-br mailing list
> > Talk-br@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-br
> >
>
>
>
> --
> Fernando Trebien
> +55 (51) 9962-5409
>
> "The speed of computer chips doubles every 18 months." (Moore's law)
> "The speed of software halves every 18 months." (Gates' law)
>
> ___
> 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] Problema de usabilidade do editor de endereços do iD

[John Packer]

Eu quase traduzi o "123" por "Nº de porta" (um termo que andou circulando
> bastante por aqui). Se quiserem, posso alterar lá.

Acho que se for pra trocar, deveria ser ou "Nº" ou "Número", pois pelo
menos aqui não é chamado de "Nº de porta", mas geralmente de "Nº da casa"
ou o equivalente.

Por tudo isso, acho que addr:housename acaba sendo mais prática, e não se
> perde informação com ela, e não se ganha nada com as outras duas  tags.
>
Ok, estou convencido que addr:housename pode ser utilizado como o
"Complemento" no Brasil.

Devemos então oficializar isso e documentar na wiki.

Creio que seja útil, em adição ao addr:housename, adicionar (manualmente) o
addr:door e addr:unit quando for o caso.
O que acham?


Em 13 de fevereiro de 2014 12:13, Fernando Trebien <
fernando.treb...@gmail.com> escreveu:

> Eu quase traduzi o "123" por "Nº de porta" (um termo que andou
> circulando bastante por aqui). Se quiserem, posso alterar lá. Acho que
> mostrar a informação correta nesses campos já deve resolver mais de
> 95% dos casos em que são usados de forma incorreta. Eu não trocaria
> "Complemento" por "Apt/Sala/Conjunto" porque isso daria a impressão de
> que só esses 3 são complementos válidos.
>
> Addr:door e addr:unit não são interpoláveis (pois podem ter letras),
> logo não afetam o geocoding, logo servem apenas para informação, tal
> como addr:housename. Somadas, essas duas não chegaram a 7 mil usos
> desde que a proposta foi aprovada em 2011, contra 225 mil usos da tag
> addr:housename. Nesse ritmo, é provável que nunca sejam suportadas por
> aplicações, enquanto que addr:housename já é suportada por algumas.
> Ela quase sempre se combina com addr:housenumber, sugerindo a mesma
> função do nosso "complemento" brasileiro:
> http://taginfo.openstreetmap.org/keys/addr%3Ahousename#combinations
>
> A vantagem de se usar addr:housename como complemento é que daria pra
> especificá-lo da mesma forma que se usa em endereços postais, com os
> mesmos termos usados pelo proprietário
> (bloco/conjunto/apartamento/sala/etc.). Pode haver casos em que se tem
> mais de 2 níveis de subdivisão da propriedade, e nesses casos
> addr:door e addr:unit não seriam suficientes, mas addr:housename sim.
> Por tudo isso, acho que addr:housename acaba sendo mais prática, e não
> se perde informação com ela, e não se ganha nada com as outras duas
> tags.
>
> 2014-02-12 23:17 GMT-02:00 John Packer :
> >
> >> Eu mudei a tradução de "nome da casa" para "complemento", isso já deve
> >> ajudar.
> >
> > Sim, foi uma boa idéia, vai ajudar um pouco.
> > Falando nisso, estava pensando se não seria melhor no addr:housenumber
> > colocar "Número" ou "Nº" ao invés de "123". O que acha?
> >
> >> Eu duvido que eles localizem a interface (com tantas coisas ainda por
> >> fazer), já que na maioria dos países europeus e na América do Norte
> essa é a
> >> ordem dos campos do endereço.
> >
> > Pois é, eu estava vendo o número gigantesco de coisas que eles têm a
> fazer.
> > Vou tentar "colocar a mão na massa" pra fazer isso ir pra frente.
> > Eu pretendo esperar mais ou menos 1 semana por uma resposta deles. Depois
> > disso eu vou alterar o código e mandar pra eles corrigirem. Já dei uma
> > olhada onde tem que alterar, só estou um pouco preocupado que o código
> não
> > ficaria muito limpo colocando um caso específico para a linguagem
> português
> > brasileiro no meio(isso tenho que ver com eles).
> >
> > Falando nisso, alguém sabe se os endereços dos outros países da América
> > Latina são parecidos? E de Portugal?
> >
> >
> >> Alguma aplicação já suporta a tag addr:door? O que iria nessa tag,
> >> apenas um número ou uma descrição como "Sala 204", "Salas 204 e 205"
> >> ou "Conjunto 501"?
> >
> > Não sei se tem alguma aplicação que utiliza(não sei nem se o Nominatim
> > suporta), porém ela está documentada na wiki.
> > Como valor iria somente "204" do "Sala 204", "204;205" do "Salas 204 e
> 205".
> > Quando ao "Conjunto 501", teria que ser addr:unit=501.
> > Peraí, então o addr:door não funciona pra todos os casos? Exatamente, não
> > tem nenhuma etiqueta que cubra todos os casos para o "Complemento" de um
> > endereço(que seria um addr:additional_information=*); creio que o mais
> perto
> > é colocar o endereço completo no addr:full.
> > Eu estou aberto a sugestões, mas vou jogar duas idéias aqui:
> > 1. Retirar o

Re: [Talk-br] Problema de usabilidade do editor de endereços do iD

[John Packer]

Obrigado por se manifestarem, mudei minha opinião, tem desvantagens
consideráveis utilizar addr:housename como "Complemento".

Augusto, você confundiu o uso de addr:housename em alguns dos exemplos.
Leia sobre as etiquetas ref e alt_name.

Vejo que ainda não chegamos a um consenso, então vamos voltar a questão
inicial:
Como podemos colocar o campo "Complemento" no editor de endereços do iD?
Vale lembrar, que como solução provisória, a etiqueta addr:housename está
como o campo "Complemento" no editor(para evitar que as pessoas coloquem o
nome da rua ou do lugar ali).

Vi que o Augusto sugeriu utilizar addr:housenumber, eu discordo porquê ela
é renderizada no Mapnik em vários casos.
Neste quesito, a etiqueta addr:door é melhor.



Em 13 de fevereiro de 2014 13:16, Nelson A. de Oliveira
escreveu:

> 2014-02-13 12:51 GMT-02:00 Augusto Stoffel :
> > Outra possibilidade seria usar a tag addr:housename literalmente, para
> > denotar o nome do edifício, e nunca o complemento.
>
> É dessa forma que eu sempre enxerguei essa tag.
>
> ___
> 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] Problema de usabilidade do editor de endereços do iD

[John Packer]

Nelson,

Não é um encaixe perfeito com a definição das tags, mas seria  addr:door
> (apartamento X) + addr:unit (bloco Y)
>
Essa é a principal razão porquê addr:door não foi decidido como
"Complemento" ainda.
Não tenho certeza agora, mas talvez addr:flats também se encaixe.
Outro problema é como fazer a interface de uma forma que as pessoas não
coloquem "apt x" ou "bloco y" na etiqueta? (colocando somente o número)



Em 13 de fevereiro de 2014 13:38, Nelson A. de Oliveira
escreveu:

> 2014-02-13 13:30 GMT-02:00 John Packer :
> > Neste quesito, a etiqueta addr:door é melhor.
>
> Não é um encaixe perfeito com a definição das tags, mas seria
> addr:door (apartamento X) + addr:unit (bloco Y)
>
> ___
> 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] Problema de usabilidade do editor de endereços do iD

[John Packer]

> Eu vinha colocando nomes de edifícios na tag "name" mesmo. Nunca encontrei
> um caso em que o edifício teria um nome e também abrigaria inteiramente 1
> estabelecimento (e somente 1) com um nome diferente. Nesse caso, eu
> provavelmente mapearia a "coisa" como ponto dentro do edifício, mas pela
> descrição no wiki daria pra usar addr:housename.
>
Pelo que eu entendi, o uso legítimo seria somente quando teria mais de um
estabelecimento dentro do edifício. Neste caso, cada um dos
estabelecimentos(talvez como pontos) poderiam ter addr:housename=Nome do
edifício
Se por acaso tivesse um edifício com um nome diferente do único
estabelecimento dentro dele, eu utilizaria alt_name ou official_name ou
outra variação.


> O nosso "complemento" seria sempre um "in addition to".

E a parte "The name of a house" da descrição ?

Posso testar como o Nominatim se comporta, mas acho que ele geraria um
> resultado com name, addr:housename e as demais tags de endereço nesse
> formato: [name], [addr:housename], [addr:housenumber], [addr:street],
> [name com admin_level=10], [name com admin_level=9], etc.
>

Pois é, eu estava pensando nisso, seria bom ver como ele se comporta.
Poderia aproveitar pra ver se tem algum problema colocar o
bairro(admin_level=10) como addr:suburb? (verificar se ele reconhece
corretamente que é a mesma coisa)
E se possível ver para as outras etiquetas: addr:door/unit/flats

Obrigado,
João


Em 13 de fevereiro de 2014 13:38, Fernando Trebien <
fernando.treb...@gmail.com> escreveu:

> Eu vinha colocando nomes de edifícios na tag "name" mesmo. Nunca
> encontrei um caso em que o edifício teria um nome e também abrigaria
> inteiramente 1 estabelecimento (e somente 1) com um nome diferente.
> Nesse caso, eu provavelmente mapearia a "coisa" como ponto dentro do
> edifício, mas pela descrição no wiki daria pra usar addr:housename.
>
> Caso o nome do edifício seja considerado parte do complemento (mas
> nunca vi), eu acabaria replicando o valor de name na tag
> addr:housename do edifício, mas nas coisas que ficam dentro do
> edifício essa tag teria mais informações. Por exemplo, poderia ter
> "Edifício JK, 10º Andar, Sala Sul, Área 2B".
>
> A descrição de housename no wiki: "The name of a house.  This is
> sometimes used in some countries like England instead of (or in
> addition to) a house number."
>
> O nosso "complemento" seria sempre um "in addition to".
>
> Posso testar como o Nominatim se comporta, mas acho que ele geraria um
> resultado com name, addr:housename e as demais tags de endereço nesse
> formato: [name], [addr:housename], [addr:housenumber], [addr:street],
> [name com admin_level=10], [name com admin_level=9], etc.
>
> 2014-02-13 13:16 GMT-02:00 Nelson A. de Oliveira :
> > 2014-02-13 12:51 GMT-02:00 Augusto Stoffel :
> >> Outra possibilidade seria usar a tag addr:housename literalmente, para
> >> denotar o nome do edifício, e nunca o complemento.
> >
> > É dessa forma que eu sempre enxerguei essa tag.
> >
> > ___
> > Talk-br mailing list
> > Talk-br@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-br
>
>
>
> --
> Fernando Trebien
> +55 (51) 9962-5409
>
> "The speed of computer chips doubles every 18 months." (Moore's law)
> "The speed of software halves every 18 months." (Gates' law)
>
> ___
> 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] Mapeando Linhas de ônibus

[John Packer]

Só uma coisa, não sei qual esquema de etiquetas está utilizando, mas
etiquetas como highway=bus_stop estão caindo em desuso.

O novo esquema de etiquetas (public_transport=*) foi aprovado em abril de
2011 e está em amplo
uso
.
Infelizmente este novo esquema atualmente não está traduzido para o
português, por isso que a página em português consta como desatualizada.

Sempre que encontro um highway=bus_stop, adiciono um
public_transport=stop_position, e se conheço pessoalmente a área, substituo.

Não cheguei a fazer uma rota de ônibus ainda, então não posso responder as
suas perguntas.


Em 14 de fevereiro de 2014 17:45, Arlindo Pereira <
openstreet...@arlindopereira.com> escreveu:

> Respondendo inline.
>
> []s
>
> Em 14/02/2014 17:40, "Marcelo Pereira"  escreveu:
>
> >
> > Srs,
> >
> > Resolvi começar a mapear as linhas de ônibus daqui de Recife, usando
> como base o site Empresa de transportes da região Metropolitana.
> >
> > A fonte da informação está como se vê no link (http://goo.gl/NskwIm ) .
> >
> > Até já entrei em contato com o Vitor, que mapeou as linhas em João
> Pessoa, que me deu dicas, mas, gostaria de tornar as perguntas públicas
> para que possa servir para outros na minha situação.
> >
> > Além disso, consultei a página Pt-br:Public transport (
> http://goo.gl/AxuKUB ) , mas a info lá é bem superficial.
> >
> > Perguntas :
> >
> > - É pelo iD mesmo, fatiando e selecionando as seções das vias por onde o
> ônibus passa e incluindo na Relation ?
> >
> > - Tem alguma ferramenta/gambiarra/truque mágico/opção melhor que ajude
> aqui ?
>
> JOSM. É bem superior que o iD para tarefas mais complexas, como esta.
>
> >
> > - É preciso uma Relation para cada linha, uma para cada sentido (
> Cidade/Suburbio e Suburbio/Cidade ) ?
> >
> > - No exemplo do link, pode-se ver que esta linha ( 645 ) tem 2
> itinerários, e cada um 2 sentidos, isso significa 4 Relations ?
>
> Acredito que sim.
>
> >
> > - Preciso agrupar tudo numa Relation maior ?
>
> Boa pergunta.
>
> >
> > - É uma boa ideia criar tags para a tarifa ?
>
> Acho que não.
>
> >
> > - No caso do link, tem 2 empresas responsáveis pela linha, são duas tag
> Operator ? Ou coloco os nomes separados por ';' ?
>
> Isso.
>
> >
> > - Já tenho no mapa várias paradas incluídas, é só juntar nas Relations
> com as vias , ou tem algum processo diferente ?
>
> Isso. Se não me engano é com role=stop, no wiki diz ao certo.
>
> >
> > - Na mesma página dos itinerários, tem info dos horários de partida das
> linhas do terminal, onde coloca isso no OSM e como ?
>
> Isso aí já seria um outro serviço, provido por um servidor GTFS. Procure
> por GTFS no histórico da lista, o Trebien e mais outros usuários têm o
> desejo de que nos tenhamos um servidor GTFS brasileiro unificado.
>
> >
> > - Repito pergunta anterior para o acesso dos cadeirantes.
>
> Aí já seria direto, wheelchair=yes|no|limited
>
> >
> > Desculpem o jornal, mas acho que respondendo essas perguntas, e criando
> um "modelo", podemos publicar e ajudar a quem estiver procurando essa info,
> assim como eu.
> >
> > Marcelo P
> >
> > --
> >
> > ... Edileuz, eu não tem nada a ver com Creuza,
> >É mentira da Ivete, não é meu esse caniveete...
> > "Halley, Luiz" - Poeta, Cantor, Compositor
> >
> > ___
> > 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 mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Como etiquetar Churrascarias no Brasil? (e rodízios?)

[John Packer]

Pessoal, então pelo que vi, o consenso é que:
cuisine=barbecue deve ser utilizado para churrascarias em geral, a não ser
que cuisine=gaucho ou cuisine=mineira seja mais apropriado, ou seja, o
restaurante tenha um foco naquele em comidas daquele tipo.

Alguma objeção?

Sobre como etiquetar rodízios, não achei nenhuma etiqueta apropriada, então
resolvi propor uma: all_you_can_eat=yes/no/only
Segue link do *proposal*:
http://wiki.openstreetmap.org/wiki/Proposed_features/All_you_can_eat



Em 10 de fevereiro de 2014 10:56, Bráulio escreveu:

> Acho que seja melhor utilizar a tag "barbecue" já existente.
>
> Procurem "barbecue" no Google Images que vocês verão que é similar mais do
> que o suficiente ao churrasco brasileiro e a parrilla argentina. E oras...
> pergunte a qualquer um que fale inglês e português o que significa
> "barbecue" em português. 100% deles dirá "churrasco". Creio que seja melhor
> se ater ao básico do preparo: a carne é assada utilizando brasa em vez de
> frigideira ou panela e isso a deixa com sabores e texturas próprias desse
> preparo.
>
> Acho que cuisine=gaucho deve ser utilizada para restaurantes que cobrem
> boa parte da culinária gaúcha, em um ambiente com decoração gaúcha, sem
> necessariamente dar ênfase ao churrasco.
>
> Para deixar a churrascaria mais específica, que parece ser o objetivo de
> todos nessa discussão, poderia ser usado algo como
> *cuisine=barbecue;gaucho* . Não testei, mas creio que as ferramentas já
> estão em sua maioria cientes dessa separação por ponto e vírgula de valores
> múltiplos numa mesma chave. Depois, se alguém estiver disposto, podem ser
> criados termos e renderizações específicos para essa combinação
> ("Churrascaria Gaúcha", "Gaucho steak house", etc) nas ferramentas
> (nominatim, ID, JOSM, renderizadores, etc).
>
> E é bom manter em mente que nem toda churrascaria no Brasil é gaúcha. Na
> verdade, aqui em Natal há muitas churrascarias grandes, mas nunca vi
> nenhuma dizer que faz churrasco gaúcho ou que contratou um churrasqueiro
> gaúcho nem nada do tipo. Se fazem isso, nunca deram muito destaque ao fato.
> No máximo vi algumas falarem que usam cortes argentinos além dos
> brasileiros. Além disso, os acompanhamentos são claramente nordestinos:
> feijão verde, macaxeira, farofa d'água, arroz de leite, manteiga do sertão,
> etc. Não têm nada de gaúcho neles.
>
>
> 2014-02-10 9:02 GMT-03:00 Fernando Trebien :
>
> Bem, se a Wikipédia não traduz e diz que é algo distinto, acho que
>> cuisine=churrasco seria aceitável.
>>
>> Me parece que o modo de preparar a carne e os pratos está mais próxima de
>> barbecue do que de steak house. Então, também daria pra marcar com
>> cuisine=barbecue. A vantagem de fazer assim é evitar um valor novo que
>> talvez poucas aplicações venham a suportar, e o custo de fazer isso seria
>> pequeno, já que no Brasil quase não há restaurantes que servem "barbecue"
>> que não seja churrasco. Ou seja, poderíamos oficialmente igualar as duas
>> coisas, ainda que não sejam exatamente a mesma coisa.
>>
>>
>> 2014-02-09 23:33 GMT-02:00 Wille :
>>
>>  É bom lembrar que churrasco também é tradicional na Argentina e
>>> Uruguai, então não acho que deveria ser usado o valor churrascaria.
>>>
>>> Não como carne, mas minha sugestão é que a decisão seja entre
>>> steak_house e barbecue. Em Buenos Aires, o resultado foi 10 usos de
>>> steak_house e 10 de barbecue. Em Montevideo, retornou 6 steak_house.
>>>
>>>
>>> On 09-02-2014 19:57, John Packer wrote:
>>>
>>>  Mas quem define o valor do termo a ser buscado é o serviço que utiliza
>>>> o mapa, não importando o valor da tag em si. A tag é em usada em inglês,
>>>> preferencialmente britânico (pois o OSM nasceu lá).
>>>>
>>>
>>>
>>>> Acho que poderia ser cuisine=bbq ou cuisine=steak ou
>>>> cuisine=brazilian_steak.
>>>>
>>> Se for pra criar um valor novo(ao invés de usar gaúcho ou barbecue),
>>> creio que cuisine=churrascaria seja o mais apropriado, já que é um
>>> termo reconhecido em alguns 
>>> países<https://en.wikipedia.org/wiki/Churrascaria>como uma churrascaria 
>>> brasileira. (e como bônus, alguns novatos já
>>> colocam esse valor 
>>> mesmo<http://taginfo.openstreetmap.org/tags/cuisine=churrascaria>
>>> )
>>>
>>>
>>>
>>> Em 9 de fevereiro de 2014 20:39, Arlindo Pereira <
>>> openstreet...@arlindopereira.com> escreveu:
>>>
>>>> Mas quem define o valor do termo a ser buscado é o serviço q

Re: [Talk-br] OSM no FISL15

[John Packer]

Wille, (mandando somente para você)

Acredito que eu vá este ano para o FISL via caravana.
Com certeza ficaria feliz em encontrar outros mapeadores e possivelmente
fazer uma Mapping Party.
Se possível, me mantenha atualizado.

Abs,
João


Em 9 de fevereiro de 2014 13:43, Wille  escreveu:

> De 07 a 10 de maio vai acontecer em Porto Alegre o FISL 15, o maior evento
> de software livre da América Latina: http://softwarelivre.org/fisl15
>
> Ano passado substituí o Samuel Vale numa palestra sobre o OSM. E foi numa
> outra edição do FISL que conheci o OSM assistindo uma palestra de Arlindo.
> Considero que é uma boa oportunidade para mais pessoas conhecerem o OSM.
>
> Esse ano, pensei em propormos não só uma, mas várias palestras, abordando
> diferentes aspectos do projeto. Assim, gostaria de saber quem tem interesse
> em apresentar algo no FISL para que possamos articular uma ação em conjunto
> e para que não façamos propostas de palestras repetidas.
>
> Quem não quiser apresentar palestra, mas pretende ir ao FISL, avise também
> para que possamos marcar um bate-papo ou uma mapping party!
>
> O prazo para o envio de propostas de palestras se encerra em 17 de
> fevereiro. Também podemos propor as palestras como parte de um Encontro
> Comunitário e assim ter mais espaço na grade de programação:
> http://softwarelivre.org/fisl15/programacao/encontros-comunitarios
>
> abraços,
> wille
>
> ___
> 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] [OpenStreetMap] Dados estranhos

[John Packer]

Uma etiqueta obscura que pode possivelmente ser utilizada aqui é
building:material=wood.

Um amigo aqui de Joinville gosta de mapear casas do tipo enxaimel, e sempre
usa a etiqueta building:material=timber_framing.


2014-02-17 15:49 GMT-03:00 Fernando Trebien :

> Pessoal,
>
> O Erick me avisou que um estrangeiro inseriu um nó estranho no mapa
> brasileiro (tinha place=isolated_dwelling e name = "Wood dwelling").
> Como também tinha a tag name:de, suspeito que era um alemão. O nome do
> usuário "keepright! er" sugere que ele usa bastante o KeepRight. Eu
> removi o nó e avisei o usuário mandando a seguinte mensagem:
>
> Hello keeprighter,
>
> Thank you for contributing in Brazil. I'd only like to let you know
> that I've removed this change
> (http://www.openstreetmap.org/changeset/20593858) because the dwelling
> itself was already correctly drawn by you and because the name you
> gave it was very generic ("wood dwelling") and redundant (what it
> means was already represented by the place=isolated_dwelling tag). We
> use place=isolated_dwelling for places (such as cities, counties,
> etc.) that are so "remarkable" as to have an "unique name", be it
> official or simply popular.
>
> If "wood" was important and by "wood" you meant "made of wood", you
> may consider changing the tag building=house to building=cabin or
> building=hut. If you mean "in the woods", then I suggest you make it
> implicit (as it actually is) by mapping its surrounding greenery with
> landuse=forest if its artificial/managed or natural=wood if it's
> natural/virgin/not managed.
>
> Cheers!
>
> 2014-02-16 13:24 GMT-03:00 erickdeoliveiraleal
> :
> > Olá Fernando Trebien,
> >
> > erickdeoliveiraleal enviou uma mensagem pelo OpenStreetMap para você com
> o
> > assunto Dados estranhos:
> >
> > ==
> >
> > Trebien. Olha o que esse usuário criou... Um POI com nome genérico...
> > http://www.openstreetmap.org/node/2674644571
> >
> > Esse usuário sempre faz alterações em Brasília, não sei em outros
> estados do
> > Brasil. As vezes faz umas coisas estranhas, outras vezes umas coisas
> > certas...
> >
> > ==
> >
> > Você pode também ler a mensagem em
> > http://www.openstreetmap.org/message/read/411424 e pode responder em
> > http://www.openstreetmap.org/message/reply/411424
>
>
>
> --
> Fernando Trebien
> +55 (51) 9962-5409
>
> "The speed of computer chips doubles every 18 months." (Moore's law)
> "The speed of software halves every 18 months." (Gates' law)
>
> ___
> 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] Criar Layers novos

[John Packer]

Olá Clement,

Dê uma olhada no ITO Maps http://www.itoworld.com/map/main
É uma empresa que mostra o OSM com outros tipos de camadas.

Para camadas personalizadas, ainda não ouvi falar como fazer de uma forma
que não envolva programação.


Em 19 de fevereiro de 2014 15:09, Clément Vialle
escreveu:

> Boa tarde a todos,
>
> Professor de urbanismo, gostaria de envolver meus alunos no processo de
> cadastramento de informações ligadas a urbanismo.
>
> Pelo visto, OSM tem layers predefinidos (parão, rede de ciclovias,..).
>
> Seria interessante ter outros layers, como:
>
> - Uso do solo
> - Gabaritos (alturas dos edificios)
> - Saneamento básico (agregados por zona IBGE)
> - ...
>
> Ja teve uma tentativa de ordenar as informações existentes, por exemplo,
> sobre o tipo de uso dos objetos:
>
> - residencial
> - comercial
> - lazer
> - escritorios
> -...
>
> Não sei como criar outros layers...Alguém teria uma suggestão? Obrigado!
>
> ___
> 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] Importação da Funai

[John Packer]

> Mas o correto é fazer com que o renderizador exiba isso (abrindo um
> ticket para isso) e não o contrário :-)
>
+1

Se alguém julgar necessário mostrar que aquilo são terras indígenas antes
que o Mapnik as implemente, sempre pode criar uma camada para mostrar em um
site específico. Precisaria de uma razão muito boa para etiquetar algo de
forma errada (temporariamente).

O correto mesmo é trazer para o usuário final a informação geográfica que
> outras pessoas têm e que ele precisa. Esse é o propósito final do OSM, não?
>
Os dados do OSM não são usados somente no Mapnik, e não são usados somente
para a renderização de um mapa.



Em 21 de fevereiro de 2014 10:48, Fernando Trebien <
fernando.treb...@gmail.com> escreveu:

> Justamente por isso o argumento de "o correto é fazer o renderizador
> exibir isso" cada vez mais perde força comigo.
>
> Aliás, quem pensa assim deveria estar reforçando essas solicitações
> nos bugtrackers dos renderizadores - mas não o estão fazendo. (Estou
> cansando de fazer isso sozinho.) Enunciar um dogma é fácil, difícil é
> mudar a realidade.
>
> O correto mesmo é trazer para o usuário final a informação geográfica
> que outras pessoas têm e que ele precisa. Esse é o propósito final do
> OSM, não? E de preferência também mapear de uma forma tal que
> "transformar para a forma ideal de mapear" seja algo simples de se
> fazer depois (provavelmente com scripts). Obviamente isso tem limites,
> mas do jeito que o Augusto sugeriu eu acho que está 100% ok: é fácil
> fazer uma query que retorne todas as terras indígenas (e nada mais), e
> daí é fácil mudar as tags depois.
>
> 2014-02-21 10:39 GMT-03:00 Fernando Trebien :
> > 7 meses não, 5 anos: https://trac.openstreetmap.org/ticket/1447
> >
> > 2014-02-21 8:44 GMT-03:00 Paulo Carvalho :
> >> OFF TOPIC: Dei meu voto lá.  7 meses depois e cheio de gente pedindo os
> >> caras ainda não fizeram  E ruim ter que baixar no JOSM, verificar
> >> uma-a-uma, clicando e lendo nas tags.
> >>
> >>
> >> Em 21 de fevereiro de 2014 08:06, Nelson A. de Oliveira <
> nao...@gmail.com>
> >> escreveu:
> >>
> >>> 2014-02-21 8:01 GMT-03:00 Paulo Carvalho  >:
> >>> > Aliás, gostaria de fazer como se faz para abrir um ticket para pedir
> que
> >>> > vias não pavimentadas fossem desenhadas de forma diferente.
> >>>
> >>> O estilo padrão do OSM é o openstreetmap-carto
> >>> (https://github.com/gravitystorm/openstreetmap-carto/issues)
> >>> Já existe um ticket aberto para isso:
> >>> https://github.com/gravitystorm/openstreetmap-carto/issues/110
> >>>
> >>> ___
> >>> 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
> >>
> >
> >
> >
> > --
> > Fernando Trebien
> > +55 (51) 9962-5409
> >
> > "The speed of computer chips doubles every 18 months." (Moore's law)
> > "The speed of software halves every 18 months." (Gates' law)
>
>
>
> --
> Fernando Trebien
> +55 (51) 9962-5409
>
> "The speed of computer chips doubles every 18 months." (Moore's law)
> "The speed of software halves every 18 months." (Gates' law)
>
> ___
> 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] Importação da Funai

[John Packer]

>
> Existe uma razão para o Google ser famoso: é 1 nome só, e está tudo no
> mesmo lugar.
>
Isso está longe de ser a principal razão porquê o Google é famoso.

Se você discorda, por junte-se a mim e abra os tickets relativos a cada
> questão junto aos desenvolvedores dos principais sistemas.

Eu já abri um *ticket* sobre o OSM antes e também vou atrás de outras
questões como a tradução da wiki.
Não é como eu não o fizesse, mas só comecei a contribuir para o OSM mesmo
só mês passado.
Também já vi o Paulo, Arlindo e o Nelson contribuindo discussões nos
*tickets* (ou os adicionando).
Só talvez não no renderizador principal.

Concessões tem que ser dadas só em casos com boas razões.
Este caso dessa importação necessita de uma concessão?



Em 21 de fevereiro de 2014 11:33, Fernando Trebien <
fernando.treb...@gmail.com> escreveu:

> John, todos têm premissas muito similares, e absolutamente nenhum
> renderiza as reservas atualmente quando mapeadas da forma "ideal".
>
> Além disso, qual o percentual de usuários que usa sistemas além do que
> está no site principal? Concorda que quando vendemos por aí a idéia de
> que "o OpenStreetMap é um sistema fantástico", as pessoas COMUNS não
> vão acessar o ITO Map, nem o MapBox, certo? Existe uma razão para o
> Google ser famoso: é 1 nome só, e está tudo no mesmo lugar. O usuário
> comum não quer saber dos detalhes técnicos, 1 nome só e 1 site só é
> mais fácil.
>
> Agora considere isso no contexto de que os desenvolvedores dos
> componentes do OSM têm sido lentos para atender os nossos pedidos. Pra
> mim isso é um ótimo argumento em favor de certas concessões (desde que
> bem analisadas). Um dado no mapa que só serve para quem o colocou lá
> não é um dado útil para o usuário final.
>
> Se você discorda, por junte-se a mim e abra os tickets relativos a
> cada questão junto aos desenvolvedores dos principais sistemas.
>
> Só quero lembrar: abrir o ticket não é garantia de que será feito. Em
> muitos casos já notei que eles esperam que "alguém faça", não
> necessariamente o desenvolvedor do projeto (provavelmente espera-se
> que quem solicita faça).
>
> ___
> 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] Casas de festa

[John Packer]

Veja se encaixa com community_centre
Em 22/02/2014 20:01, "Paulo Carvalho" 
escreveu:

> No Tracksource mapeávamos como clube.
>
>
> Em 22 de fevereiro de 2014 19:53, Bráulio escreveu:
>
>> Também procurei e não achei. Pelo visto o termo em inglês seria banquet
>> hall ou function hall. Mas não NADA com esses termos no Wiki do OSM.
>>
>>
>> 2014-02-22 19:13 GMT-03:00 Paulo Carvalho :
>>
>>>  Pessoal,
>>>
>>>Como mapeamos casas de festa?  Aqueles lugares que se aluga para
>>> realizar festas.  O mais próximo que achei foi leisure=playground.
>>>
>>> PC
>>>
>>> ___
>>> 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 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] Importação da Funai

[John Packer]

> John e Nelson, vocês estão confortáveis com usar boundary=national_park
> para as terras indígenas?  Eu acho que se pode esperar que o renderizador
> seja consertado à medida que o novo esquema protected_area vai tomando
> tração.  Para isso as pessoas tem que começar a usar as tags auxiliares
> protect_class e protection_title, e isso nós estamos fazendo.
>
Eu não estou tendo tempo para analisar corretamente qual é a melhor opção,
mas vou dar minha opinião caso a sugestão do Nelson seja a melhor:

> Como esse é um caso mais concentrado (não é algo que vai ser etiquetado
> por várias pessoas), acho que pode ser feita uma concessão. Só acho que
> devia ser feita alguma nota (talvez como boundary:note nos elementos?)
> referenciando o pedido de renderização e explicando brevemente sobre.
> Talvez isso não seja necessário, a minha única preocupação é que, realmente
> o renderizador pode demorar a mostrar isso, e não se sabe quem entre nós
> ainda vai estar aqui (ou vai lembrar disso). Além do mais, outras pessoas
> podem mudar a etiquetagem independentemente buscando melhorar o mapa se não
> tiver alguma nota sobre.
>
(lembrando que isso é supondo que a sugestão do nelson é a mais apropriada,
o que não estou tendo tempo atualmente de verificar)

Abs, João


Em 23 de fevereiro de 2014 13:57, Augusto Stoffel
escreveu:

> Adicionei mais detalhes e instruções para quem quer ajudar na importação
> aqui:
> https://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Terras_indígenas
>
> John e Nelson, vocês estão confortáveis com usar boundary=national_park
> para as terras indígenas?  Eu acho que se pode esperar que o
> renderizador seja consertado à medida que o novo esquema protected_area
> vai tomando tração.  Para isso as pessoas tem que começar a usar as tags
> auxiliares protect_class e protection_title, e isso nós estamos fazendo.
>
> Também queria adicionar que eu quebrei o dataset em pedaços que, creio,
> podem ser importados em algo entre 1 e 3 horas, dependendo da quantidade
> de refinamentos que se esteja disposto a fazer.  Espero que tenhamos 16
> voluntários... :)
>
> On Fri, 2014-02-21 at 12:36 -0300, John Packer wrote:
> > Existe uma razão para o Google ser famoso: é 1 nome só, e está
> > tudo no mesmo lugar.
> > Isso está longe de ser a principal razão porquê o Google é famoso.
> >
> >
> >
> >
> >
> > Se você discorda, por junte-se a mim e abra os tickets
> > relativos a cada questão junto aos desenvolvedores dos
> > principais sistemas.
> > Eu já abri um ticket sobre o OSM antes e também vou atrás de outras
> > questões como a tradução da wiki.
> > Não é como eu não o fizesse, mas só comecei a contribuir para o OSM
> > mesmo só mês passado.
> >
> > Também já vi o Paulo, Arlindo e o Nelson contribuindo discussões nos
> > tickets (ou os adicionando).
> >
> > Só talvez não no renderizador principal.
> >
> >
> >
> > Concessões tem que ser dadas só em casos com boas razões.
> > Este caso dessa importação necessita de uma concessão?
> >
> >
> >
> >
> >
> > Em 21 de fevereiro de 2014 11:33, Fernando Trebien
> >  escreveu:
> > John, todos têm premissas muito similares, e absolutamente
> > nenhum
> > renderiza as reservas atualmente quando mapeadas da forma
> > "ideal".
> >
> > Além disso, qual o percentual de usuários que usa sistemas
> > além do que
> > está no site principal? Concorda que quando vendemos por aí a
> > idéia de
> > que "o OpenStreetMap é um sistema fantástico", as pessoas
> > COMUNS não
> > vão acessar o ITO Map, nem o MapBox, certo? Existe uma razão
> > para o
> > Google ser famoso: é 1 nome só, e está tudo no mesmo lugar. O
> > usuário
> > comum não quer saber dos detalhes técnicos, 1 nome só e 1 site
> > só é
> > mais fácil.
> >
> > Agora considere isso no contexto de que os desenvolvedores dos
> > componentes do OSM têm sido lentos para atender os nossos
> > pedidos. Pra
> > mim isso é um ótimo argumento em favor de certas concessões
> > (desde que
> > bem analisadas). Um dado no mapa que só serve para quem o
> > colocou lá
> > não é um dado útil para o usuário final.
> >
> > Se você discorda, por junte-se a mim e abra os tickets
> > relativos a
> > cada questão junto aos desenvolvedores dos principais
> > sistem

Re: [Talk-br] Casas de festa

[John Packer]

O mais perto atualmente realmente é amenity=community_centre. Creio que
seja o apropriado.
Na wiki: http://wiki.openstreetmap.org/wiki/Community_centre

Vendo pela descrição estendida, parece não ser exatamente o caso, porém a
seção "*Uses around the world*" diz:

> In Latin America is *salón de fiestas y/o eventos*. It's a place to rent
> for parties/events.
>

Abs,
João


Em 23 de fevereiro de 2014 11:34, Bráulio escreveu:

> Eu achei uma discussão sobre isso na talk-gb que rolou em agosto do ano
> passado:
>
>
> https://lists.openstreetmap.org/pipermail/talk-gb/2013-August/thread.html#15054
>
> Não deu em muita coisa. Infelizmente é mais um caso de tag que não existe
> e sem renderização própria no mapa principal, apesar desse tipo de
> estabelecimento ser tão comum.
>
> Se for pela quantidade de usos, eu usaria *amenity=banquet_hall* (veja
> http://taginfo.openstreetmap.org/search?q=banquet#values). Apesar do nome
> "banquet hall" parecer meio específico para quem serve refeições, nessa
> discussão foi dito que muitos lugares se chamam assim e às vezes nem
> oferecem esse serviço. Aqui em Natal acontece algo parecido: esses salões
> de eventos se dividem em se chamarem de "X Recepções" ou "X Buffet". A
> grande maioria oferece serviço de buffet, mas na maioria esse serviço é
> opcional e o serviço principal é mesmo o aluguel do espaço em si.
>
>
> 2014-02-23 7:20 GMT-03:00 John Packer :
>
> Veja se encaixa com community_centre
>> Em 22/02/2014 20:01, "Paulo Carvalho" 
>> escreveu:
>>
>>  No Tracksource mapeávamos como clube.
>>>
>>>
>>> Em 22 de fevereiro de 2014 19:53, Bráulio 
>>> escreveu:
>>>
>>>> Também procurei e não achei. Pelo visto o termo em inglês seria banquet
>>>> hall ou function hall. Mas não NADA com esses termos no Wiki do OSM.
>>>>
>>>>
>>>> 2014-02-22 19:13 GMT-03:00 Paulo Carvalho >>> >:
>>>>
>>>>>  Pessoal,
>>>>>
>>>>>Como mapeamos casas de festa?  Aqueles lugares que se aluga para
>>>>> realizar festas.  O mais próximo que achei foi leisure=playground.
>>>>>
>>>>> PC
>>>>>
>>>>> ___
>>>>> 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 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 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] POIs de alerta

[John Packer]

Eu mapeei uma lombada aqui como traffic_calming=hump.
Pelo que vi na wiki, a diferença de *hump* e *bump* é que *hump* é mais
largo. Mas ambos parecem estar certos.

Uma coisa que eu vi agora que posso ter feito errado: mapeei algumas
daquelas "tartaruguinhas" ou "conchas" que marcam uma parada para carro
como traffic_calming=bump. Isso está certo? Pelo que vi, é o mais perto.


Em 24 de fevereiro de 2014 18:40, Erick de Oliveira Leal <
erickdeoliveiral...@gmail.com> escreveu:

> Raffaelo muita coisa que você precisa saber para mapear está aí:
> http://wiki.openstreetmap.org/wiki/Pt-br:Map_Features
>
> lá vc pode ver que radar você marca um ponto e marca como
> highway=speed_camera
> e lombada traffic_calming=bump
>
> e aqui tem dicas para mapear outras coisas:
> http://wiki.openstreetmap.org/wiki/Pt-br:How_to_map_a
>
>
> Em 24 de fevereiro de 2014 18:33, Raffaello Bruno Limongi Freire <
> raffaellobr...@hotmail.com> escreveu:
>
>> Oi, gostaria de saber como mapear POIs de alerta pelo iD (lombadas e
>> radares). Aonde é que visualizo esse tipo de POI no mapa OSM? Até agora não
>> vi nenhum.
>>
>> Obrigado.
>> Raffaello Bruno
>>
>> ___
>> 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 mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] POIs de alerta

[John Packer]

Na verdade eu quis dizer aquelas coisas no chão geralmente antes de placas
de "Pare".
Fotos aqui:
https://encrypted.google.com/search?tbm=isch&q=tartaruguinhas%20tr%C3%A2nsito&tbs=imgo
:

A impressão inicial que tive é que é traffic_calming=bump, mas não tenho
certeza


Em 25 de fevereiro de 2014 11:39, Fernando Trebien <
fernando.treb...@gmail.com> escreveu:

> Hm talvez eu precise de uns exemplos com fotos, mas traffic_calming é
> pra estruturas de moderação de tráfego, e o que o John falou parece
> ser algo pra demarcar uma vaga de estacionamento ou algo do tipo.
>
> 2014-02-24 18:47 GMT-03:00 Flavio Bello Fialho :
> > Os que existem no Brasil geralmente são traffic_calming=bump.
> >
> > Em 24/02/2014 18:44, "John Packer"  escreveu:
> >
> >> Eu mapeei uma lombada aqui como traffic_calming=hump.
> >> Pelo que vi na wiki, a diferença de hump e bump é que hump é mais largo.
> >> Mas ambos parecem estar certos.
> >>
> >> Uma coisa que eu vi agora que posso ter feito errado: mapeei algumas
> >> daquelas "tartaruguinhas" ou "conchas" que marcam uma parada para carro
> como
> >> traffic_calming=bump. Isso está certo? Pelo que vi, é o mais perto.
> >>
> >>
> >> Em 24 de fevereiro de 2014 18:40, Erick de Oliveira Leal
> >>  escreveu:
> >>>
> >>> Raffaelo muita coisa que você precisa saber para mapear está aí:
> >>> http://wiki.openstreetmap.org/wiki/Pt-br:Map_Features
> >>>
> >>> lá vc pode ver que radar você marca um ponto e marca como
> >>> highway=speed_camera
> >>> e lombada traffic_calming=bump
> >>>
> >>> e aqui tem dicas para mapear outras coisas:
> >>> http://wiki.openstreetmap.org/wiki/Pt-br:How_to_map_a
> >>>
> >>>
> >>> Em 24 de fevereiro de 2014 18:33, Raffaello Bruno Limongi Freire
> >>>  escreveu:
> >>>>
> >>>> Oi, gostaria de saber como mapear POIs de alerta pelo iD (lombadas e
> >>>> radares). Aonde é que visualizo esse tipo de POI no mapa OSM? Até
> agora não
> >>>> vi nenhum.
> >>>>
> >>>> Obrigado.
> >>>> Raffaello Bruno
> >>>>
> >>>> ___
> >>>> 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 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
> >
>
>
>
> --
> Fernando Trebien
> +55 (51) 9962-5409
>
> "The speed of computer chips doubles every 18 months." (Moore's law)
> "The speed of software halves every 18 months." (Gates' law)
>
> ___
> 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] POIs de alerta

[John Packer]

Eu concordo que, vendo bem, as tartaruguinhas não se encaixam como
traffic_calming=bump. Mas será que não tem outro valor? Eu diria que ainda
é um traffic_calming.
E se for pra não colocar, como eu indico que deve ter uma parada(ou seja,
que tem placa "Pare") ? Lembro de ter lido um tempo atrás que não tem muito
consenso sobre isso. Como é feito no Brasil?

E na minha opinião, a maioria das lombadas de ruas normais são
traffic_calming=hump. Até agora só vi lombadas menores em entradas para
certos lugares.

AH, e falando em lombada, como podemos etiquetar lombadas eletrônicas?
Tem alguma etiqueta para indicar um medidor de velocidade no local? (pra
combinar com a lombada)



Em 25 de fevereiro de 2014 11:59, Fernando Trebien <
fernando.treb...@gmail.com> escreveu:

> +1 Não sabia que o OsmAnd emitia esses alertas, sempre achei que
> seriam muito úteis.
>
> Ele alerta também para traffic_calming=bump? Ou só para
> traffic_calming=hump?
>
> 2014-02-25 11:56 GMT-03:00 Gerald Weber :
> > Eu creio que é meio exagerado colocar traffic_calming=bump nestes casos.
> > Quer dizer, se você passa em uma velocidade maior não há muita
> consequência
> > exceto por um barulho chato nos pneus.
> >
> > Diferente de uma lombada onde você pode até se acidentar se você não a
> vê,
> > ou seja, um alerta emitido em função de traffic_calming=bump pode até
> evitar
> > um acidente.
> >
> > Exemplos são lombadas em rodovias sem sinalização, ou com sinalização
> gasta.
> > Neste caso alguns aplicativos (como o Osmand) emitem alertas de lombada
> que
> > são muito úteis.
> >
> > Agora, se o Osmand começar a dar um alerta para cada "tartaruginha" numa
> rua
> > isto acaba perdendo a função para alertar para situações que envolvem um
> > perigo real.
> >
> > abraço
> >
> > Gerald
> >
> >
> > 2014-02-25 11:43 GMT-03:00 John Packer :
> >
> >> Na verdade eu quis dizer aquelas coisas no chão geralmente antes de
> placas
> >> de "Pare".
> >> Fotos aqui:
> >>
> https://encrypted.google.com/search?tbm=isch&q=tartaruguinhas%20tr%C3%A2nsito&tbs=imgo
> :
> >>
> >> A impressão inicial que tive é que é traffic_calming=bump, mas não tenho
> >> certeza
> >>
> >>
> >> Em 25 de fevereiro de 2014 11:39, Fernando Trebien
> >>  escreveu:
> >>
> >>> Hm talvez eu precise de uns exemplos com fotos, mas traffic_calming é
> >>> pra estruturas de moderação de tráfego, e o que o John falou parece
> >>> ser algo pra demarcar uma vaga de estacionamento ou algo do tipo.
> >>>
> >>> 2014-02-24 18:47 GMT-03:00 Flavio Bello Fialho  >:
> >>> > Os que existem no Brasil geralmente são traffic_calming=bump.
> >>> >
> >>> > Em 24/02/2014 18:44, "John Packer" 
> escreveu:
> >>> >
> >>> >> Eu mapeei uma lombada aqui como traffic_calming=hump.
> >>> >> Pelo que vi na wiki, a diferença de hump e bump é que hump é mais
> >>> >> largo.
> >>> >> Mas ambos parecem estar certos.
> >>> >>
> >>> >> Uma coisa que eu vi agora que posso ter feito errado: mapeei algumas
> >>> >> daquelas "tartaruguinhas" ou "conchas" que marcam uma parada para
> >>> >> carro como
> >>> >> traffic_calming=bump. Isso está certo? Pelo que vi, é o mais perto.
> >>> >>
> >>> >>
> >>> >> Em 24 de fevereiro de 2014 18:40, Erick de Oliveira Leal
> >>> >>  escreveu:
> >>> >>>
> >>> >>> Raffaelo muita coisa que você precisa saber para mapear está aí:
> >>> >>> http://wiki.openstreetmap.org/wiki/Pt-br:Map_Features
> >>> >>>
> >>> >>> lá vc pode ver que radar você marca um ponto e marca como
> >>> >>> highway=speed_camera
> >>> >>> e lombada traffic_calming=bump
> >>> >>>
> >>> >>> e aqui tem dicas para mapear outras coisas:
> >>> >>> http://wiki.openstreetmap.org/wiki/Pt-br:How_to_map_a
> >>> >>>
> >>> >>>
> >>> >>> Em 24 de fevereiro de 2014 18:33, Raffaello Bruno Limongi Freire
> >>> >>>  escreveu:
> >>> >>>>
> >>> >>>> Oi, gostaria de saber como mapear POIs de alerta pelo iD
> (lombadas e
> >>> >>>> radares). Aonde é que visualizo e

Re: [Talk-br] POIs de alerta

[John Packer]

Arlindo,

Quanto às tartaruguinhas, não se encaixam com traffic_calming=rumble_strip.
*Rumble strip* são os "Sonorizadores" que tem em partes de rodovias.

highway=stop é pra ser utilizado um pouco antes da interseção, correto?

Quando eu perguntei sobre o medidor de velocidade, me referi a lombada
eletrônica mesmo.
Creio que highway=speed_camera já cubra as necessidades.



Em 25 de fevereiro de 2014 12:27, Arlindo Pereira <
openstreet...@arlindopereira.com> escreveu:

> O wiki chama essas estruturas de traffic_calming=rumble_strip:
>
> "Multiple very low bumps (few cm at most) spaced few meters apart
> spanning the entire width of the road. Does not limit speeds as such, but
> are very noticeable to the driver as they generate noise and shake the car
> mildly. Not to be confused with the similar device used to alert drivers
> when they drift from their lane. See [image: 
> Wikipedia]<http://en.wikipedia.org/wiki/Rumble_strips>
>  Rumble strips <http://en.wikipedia.org/wiki/Rumble_strips>."
>
> Nesses casos, em que as tartaruguinhas são combinadas com a placa de pare,
> eu mapearia assim:
>
> highway=stop
> traffic_calming=rumble_strip
>
> E, no caso da lombada eletrônica:
>
> highway=speed_camera
> maxspeed=XX
>
> Não conheço tag para demonstrar que há um medidor de velocidade no local.
> Podemos inventar uma e comentar na página de discussão da tag speed_camera
> e/ou na lista tagging.
>
> []s
> Arlindo
>
> 2014-02-25 12:14 GMT-03:00 John Packer :
>
> Eu concordo que, vendo bem, as tartaruguinhas não se encaixam como
>> traffic_calming=bump. Mas será que não tem outro valor? Eu diria que ainda
>> é um traffic_calming.
>> E se for pra não colocar, como eu indico que deve ter uma parada(ou seja,
>> que tem placa "Pare") ? Lembro de ter lido um tempo atrás que não tem muito
>> consenso sobre isso. Como é feito no Brasil?
>>
>> E na minha opinião, a maioria das lombadas de ruas normais são
>> traffic_calming=hump. Até agora só vi lombadas menores em entradas para
>> certos lugares.
>>
>> AH, e falando em lombada, como podemos etiquetar lombadas eletrônicas?
>> Tem alguma etiqueta para indicar um medidor de velocidade no local? (pra
>> combinar com a lombada)
>>
>>
>>
>> Em 25 de fevereiro de 2014 11:59, Fernando Trebien <
>> fernando.treb...@gmail.com> escreveu:
>>
>> +1 Não sabia que o OsmAnd emitia esses alertas, sempre achei que
>>> seriam muito úteis.
>>>
>>> Ele alerta também para traffic_calming=bump? Ou só para
>>> traffic_calming=hump?
>>>
>>> 2014-02-25 11:56 GMT-03:00 Gerald Weber :
>>> > Eu creio que é meio exagerado colocar traffic_calming=bump nestes
>>> casos.
>>> > Quer dizer, se você passa em uma velocidade maior não há muita
>>> consequência
>>> > exceto por um barulho chato nos pneus.
>>> >
>>> > Diferente de uma lombada onde você pode até se acidentar se você não a
>>> vê,
>>> > ou seja, um alerta emitido em função de traffic_calming=bump pode até
>>> evitar
>>> > um acidente.
>>> >
>>> > Exemplos são lombadas em rodovias sem sinalização, ou com sinalização
>>> gasta.
>>> > Neste caso alguns aplicativos (como o Osmand) emitem alertas de
>>> lombada que
>>> > são muito úteis.
>>> >
>>> > Agora, se o Osmand começar a dar um alerta para cada "tartaruginha"
>>> numa rua
>>> > isto acaba perdendo a função para alertar para situações que envolvem
>>> um
>>> > perigo real.
>>> >
>>> > abraço
>>> >
>>> > Gerald
>>> >
>>> >
>>> > 2014-02-25 11:43 GMT-03:00 John Packer :
>>> >
>>> >> Na verdade eu quis dizer aquelas coisas no chão geralmente antes de
>>> placas
>>> >> de "Pare".
>>> >> Fotos aqui:
>>> >>
>>> https://encrypted.google.com/search?tbm=isch&q=tartaruguinhas%20tr%C3%A2nsito&tbs=imgo
>>> :
>>> >>
>>> >> A impressão inicial que tive é que é traffic_calming=bump, mas não
>>> tenho
>>> >> certeza
>>> >>
>>> >>
>>> >> Em 25 de fevereiro de 2014 11:39, Fernando Trebien
>>> >>  escreveu:
>>> >>
>>> >>> Hm talvez eu precise de uns exemplos com fotos, mas traffic_calming é
>>> >>> pra estruturas de moderação de tráfego, e o que o John falou parece
>>> >

Re: [Talk-br] POIs de alerta

[John Packer]

Pessoal, ainda não tenho 100% de certeza, mas pelo que entendi, a diferença
de *speed bump* e *speed hump* é a ilustrada na imagem abaixo:
[image: Imagem inline 1]


Em 25 de fevereiro de 2014 13:23, John Packer escreveu:

> Arlindo,
>
> Quanto às tartaruguinhas, não se encaixam com traffic_calming=rumble_strip
> .
> *Rumble strip* são os "Sonorizadores" que tem em partes de rodovias.
>
> highway=stop é pra ser utilizado um pouco antes da interseção, correto?
>
> Quando eu perguntei sobre o medidor de velocidade, me referi a lombada
> eletrônica mesmo.
> Creio que highway=speed_camera já cubra as necessidades.
>
>
>
> Em 25 de fevereiro de 2014 12:27, Arlindo Pereira <
> openstreet...@arlindopereira.com> escreveu:
>
> O wiki chama essas estruturas de traffic_calming=rumble_strip:
>>
>> "Multiple very low bumps (few cm at most) spaced few meters apart
>> spanning the entire width of the road. Does not limit speeds as such, but
>> are very noticeable to the driver as they generate noise and shake the car
>> mildly. Not to be confused with the similar device used to alert drivers
>> when they drift from their lane. See [image: 
>> Wikipedia]<http://en.wikipedia.org/wiki/Rumble_strips>
>>  Rumble strips <http://en.wikipedia.org/wiki/Rumble_strips>."
>>
>> Nesses casos, em que as tartaruguinhas são combinadas com a placa de
>> pare, eu mapearia assim:
>>
>> highway=stop
>> traffic_calming=rumble_strip
>>
>> E, no caso da lombada eletrônica:
>>
>> highway=speed_camera
>> maxspeed=XX
>>
>> Não conheço tag para demonstrar que há um medidor de velocidade no local.
>> Podemos inventar uma e comentar na página de discussão da tag speed_camera
>> e/ou na lista tagging.
>>
>> []s
>> Arlindo
>>
>> 2014-02-25 12:14 GMT-03:00 John Packer :
>>
>> Eu concordo que, vendo bem, as tartaruguinhas não se encaixam como
>>> traffic_calming=bump. Mas será que não tem outro valor? Eu diria que ainda
>>> é um traffic_calming.
>>> E se for pra não colocar, como eu indico que deve ter uma parada(ou
>>> seja, que tem placa "Pare") ? Lembro de ter lido um tempo atrás que não tem
>>> muito consenso sobre isso. Como é feito no Brasil?
>>>
>>> E na minha opinião, a maioria das lombadas de ruas normais são
>>> traffic_calming=hump. Até agora só vi lombadas menores em entradas para
>>> certos lugares.
>>>
>>> AH, e falando em lombada, como podemos etiquetar lombadas eletrônicas?
>>> Tem alguma etiqueta para indicar um medidor de velocidade no local? (pra
>>> combinar com a lombada)
>>>
>>>
>>>
>>> Em 25 de fevereiro de 2014 11:59, Fernando Trebien <
>>> fernando.treb...@gmail.com> escreveu:
>>>
>>> +1 Não sabia que o OsmAnd emitia esses alertas, sempre achei que
>>>> seriam muito úteis.
>>>>
>>>> Ele alerta também para traffic_calming=bump? Ou só para
>>>> traffic_calming=hump?
>>>>
>>>> 2014-02-25 11:56 GMT-03:00 Gerald Weber :
>>>> > Eu creio que é meio exagerado colocar traffic_calming=bump nestes
>>>> casos.
>>>> > Quer dizer, se você passa em uma velocidade maior não há muita
>>>> consequência
>>>> > exceto por um barulho chato nos pneus.
>>>> >
>>>> > Diferente de uma lombada onde você pode até se acidentar se você não
>>>> a vê,
>>>> > ou seja, um alerta emitido em função de traffic_calming=bump pode até
>>>> evitar
>>>> > um acidente.
>>>> >
>>>> > Exemplos são lombadas em rodovias sem sinalização, ou com sinalização
>>>> gasta.
>>>> > Neste caso alguns aplicativos (como o Osmand) emitem alertas de
>>>> lombada que
>>>> > são muito úteis.
>>>> >
>>>> > Agora, se o Osmand começar a dar um alerta para cada "tartaruginha"
>>>> numa rua
>>>> > isto acaba perdendo a função para alertar para situações que envolvem
>>>> um
>>>> > perigo real.
>>>> >
>>>> > abraço
>>>> >
>>>> > Gerald
>>>> >
>>>> >
>>>> > 2014-02-25 11:43 GMT-03:00 John Packer :
>>>> >
>>>> >> Na verdade eu quis dizer aquelas coisas no chão geralmente antes de
>>>> placas
>>>> >> de "Pare".
>>>> >> Fotos aqui:
>>>> &

[Talk-br] Proposta de padronização de lombadas no Brasil

[John Packer]

Pessoal,
em uma discussão recente aqui na lista, percebi que tem duas formas
diferentes de etiquetar uma lombada: traffic_calming=bump e
traffic_calming=hump.

Vi que não havia uma padronização quanto a isso no Brasil, então levantei
as mangas e comecei a pesquisar.

Em primeiro lugar descobri que tem outros nomes para uma lombada:

   - lomba (que é sinônimo de lombada)
   - quebra-mola (que é utilizado no RS)
   - ondulação transversal (que é um termo mais abrangente)

E descobri que existem sim dois tipos de lombada: *Tipo I* e *Tipo II*.
Como podem ver no seguinte link:
http://www.cliqueautomotivo.com.br/index.php?pg=sobrerodas/lombada-ou-quebra-molas

O tipo 1 é menor que o tipo 2, mas é também mais curto, forçando o usuário
a reduzir mais a velocidade do que no tipo 2.

Nas definições de *Bump* que vi, era assim mesmo, com a única diferença
sendo que *Bump* poderia ter uma altura maior do que *Hump* em alguns casos.

Logo, a minha proposta de padronização é a seguinte:

   - em lombadas Tipo I  => traffic_calming=bump
   - em lombadas Tipo II => traffic_calming=hump
   - se não se encaixar em um desses tipos, deve ser etiquetado o mais
   próximo, de acordo com o *comprimento*

Abs, João
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Proposta de padronização de lombadas no Brasil

[John Packer]

Marcelo,

Concordo que preciso clarificar mais essa proposta.
O tipo 1 tem *1,5m*; e em geral é utilizado em estradas que precisem que a
velocidade seja reduzida para 20km/h ou menos. O termo *bump* é
praticamente a mesma coisa que o tipo 1, tendo como única diferença que ele
pode ter uma altura que maior o *hump*(tipo 2).
O tipo 2 é pra ter *3m* de comprimento, e em geral é para reduzir para
30km/h ou menos.
Estou sob a impressão que o tipo mais comum nas estradas dentro de uma
cidade são o tipo 1 (*bump*).

Creio que um critério simples para diferenciar poderia ser: se tem menos de
2 metros de comprimento, então é *bump*; se tiver mais, então é *hump*. (2
metros é um número que eu escolhi meio que arbitrariamente, se acharem
melhor ser um número maior, podem falar)


> - Já vi muitos casos de lombadas feitas pela própria população, nota-se a
> diferença pela total falta de padrão, mas estas tendem a ser mais altas que
> as "oficiais", já vi até "triangulares" ( exemplo http://goo.gl/RC3ogE ).
> Neste caso, que tag usar ?
>
Esse do exemplo que você mostrou seria *bump*.

- Já vi lombadas de terra, em vias do mesmo tipo, e aí ?
>
Isso não faz parte do critério de escolha, é indiferente.

- Aqui perto de casa, tem uma lombada mais larga, que traz no seu corpo uma
> faixa de pedestres ( exemplo http://goo.gl/16S98g ), como se
> classificaria isso ?
>
Esse é *hump*.

Aproveitando o embalo, não sei se ainda existem, mas cheguei a ver lombadas
> invertidas, ou seja, depressões na pista usadas como lombadas. Isso recebe
> tag ?
>
Nunca vi isso antes, poderia dar um exemplo?

Abs,
João

Em 25 de fevereiro de 2014 16:54, Marcelo Pereira
escreveu:

> Considerações, minhas :
>
> - Aqui pros lados do NE tb é conhecida como quebra-molas.
>
> - Já vi muitos casos de lombadas feitas pela própria população, nota-se a
> diferença pela total falta de padrão, mas estas tendem a ser mais altas que
> as "oficiais", já vi até "triangulares" ( exemplo http://goo.gl/RC3ogE ).
> Neste caso, que tag usar ?
>
> - Já vi lombadas de terra, em vias do mesmo tipo, e aí ?
>
> - Aqui perto de casa, tem uma lombada mais larga, que traz no seu corpo
> uma faixa de pedestres ( exemplo http://goo.gl/16S98g ), como se
> classificaria isso ?
>
> Aproveitando o embalo, não sei se ainda existem, mas cheguei a ver
> lombadas invertidas, ou seja, depressões na pista usadas como lombadas.
> Isso recebe tag ?
>
> Marcelo Pereira
>
>
> Em 25 de fevereiro de 2014 16:06, Fernando Trebien <
> fernando.treb...@gmail.com> escreveu:
>
> Por mim tá perfeito.
>> On Feb 25, 2014 3:38 PM, "John Packer"  wrote:
>>
>>> Pessoal,
>>> em uma discussão recente aqui na lista, percebi que tem duas formas
>>> diferentes de etiquetar uma lombada: traffic_calming=bump e
>>> traffic_calming=hump.
>>>
>>> Vi que não havia uma padronização quanto a isso no Brasil, então
>>> levantei as mangas e comecei a pesquisar.
>>>
>>> Em primeiro lugar descobri que tem outros nomes para uma lombada:
>>>
>>>- lomba (que é sinônimo de lombada)
>>>- quebra-mola (que é utilizado no RS)
>>>- ondulação transversal (que é um termo mais abrangente)
>>>
>>> E descobri que existem sim dois tipos de lombada: *Tipo I* e *Tipo II*.
>>> Como podem ver no seguinte link:
>>> http://www.cliqueautomotivo.com.br/index.php?pg=sobrerodas/lombada-ou-quebra-molas
>>>
>>> O tipo 1 é menor que o tipo 2, mas é também mais curto, forçando o
>>> usuário a reduzir mais a velocidade do que no tipo 2.
>>>
>>> Nas definições de *Bump* que vi, era assim mesmo, com a única diferença
>>> sendo que *Bump* poderia ter uma altura maior do que *Hump* em alguns
>>> casos.
>>>
>>> Logo, a minha proposta de padronização é a seguinte:
>>>
>>>- em lombadas Tipo I  => traffic_calming=bump
>>>- em lombadas Tipo II => traffic_calming=hump
>>>- se não se encaixar em um desses tipos, deve ser etiquetado o mais
>>>próximo, de acordo com o *comprimento*
>>>
>>> Abs, Joã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
>>
>>
>
>
> --
>
> ... Edileuz, eu não tem nada a ver com Creuza,
>É mentira da Ivete, não é meu esse caniveete...
> "Halley, Luiz" - Poeta, Cantor, Compsitor
>
> ___
> 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] Proposta de padronização de lombadas no Brasil

[John Packer]

>
> Lombada tipo II + faixa de segurança = traffic_calming=hump +
> highway=crossing. Ambas no mesmo ponto.

+1

Em 25 de fevereiro de 2014 17:38, Fernando Trebien <
fernando.treb...@gmail.com> escreveu:

> Lombada tipo II + faixa de segurança = traffic_calming=hump +
> highway=crossing. Ambas no mesmo ponto.
>
> 2014-02-25 16:54 GMT-03:00 Marcelo Pereira :
> > Considerações, minhas :
> >
> > - Aqui pros lados do NE tb é conhecida como quebra-molas.
> >
> > - Já vi muitos casos de lombadas feitas pela própria população, nota-se a
> > diferença pela total falta de padrão, mas estas tendem a ser mais altas
> que
> > as "oficiais", já vi até "triangulares" ( exemplo http://goo.gl/RC3ogE).
> > Neste caso, que tag usar ?
> >
> > - Já vi lombadas de terra, em vias do mesmo tipo, e aí ?
> >
> > - Aqui perto de casa, tem uma lombada mais larga, que traz no seu corpo
> uma
> > faixa de pedestres ( exemplo http://goo.gl/16S98g ), como se
> classificaria
> > isso ?
> >
> > Aproveitando o embalo, não sei se ainda existem, mas cheguei a ver
> lombadas
> > invertidas, ou seja, depressões na pista usadas como lombadas. Isso
> recebe
> > tag ?
> >
> > Marcelo Pereira
> >
> >
> > Em 25 de fevereiro de 2014 16:06, Fernando Trebien
> >  escreveu:
> >
> >> Por mim tá perfeito.
> >>
> >> On Feb 25, 2014 3:38 PM, "John Packer"  wrote:
> >>>
> >>> Pessoal,
> >>> em uma discussão recente aqui na lista, percebi que tem duas formas
> >>> diferentes de etiquetar uma lombada: traffic_calming=bump e
> >>> traffic_calming=hump.
> >>>
> >>> Vi que não havia uma padronização quanto a isso no Brasil, então
> levantei
> >>> as mangas e comecei a pesquisar.
> >>>
> >>> Em primeiro lugar descobri que tem outros nomes para uma lombada:
> >>>
> >>> lomba (que é sinônimo de lombada)
> >>> quebra-mola (que é utilizado no RS)
> >>> ondulação transversal (que é um termo mais abrangente)
> >>>
> >>> E descobri que existem sim dois tipos de lombada: Tipo I e Tipo II.
> Como
> >>> podem ver no seguinte link:
> >>>
> http://www.cliqueautomotivo.com.br/index.php?pg=sobrerodas/lombada-ou-quebra-molas
> >>>
> >>> O tipo 1 é menor que o tipo 2, mas é também mais curto, forçando o
> >>> usuário a reduzir mais a velocidade do que no tipo 2.
> >>>
> >>> Nas definições de Bump que vi, era assim mesmo, com a única diferença
> >>> sendo que Bump poderia ter uma altura maior do que Hump em alguns
> casos.
> >>>
> >>> Logo, a minha proposta de padronização é a seguinte:
> >>>
> >>> em lombadas Tipo I  => traffic_calming=bump
> >>> em lombadas Tipo II => traffic_calming=hump
> >>> se não se encaixar em um desses tipos, deve ser etiquetado o mais
> >>> próximo, de acordo com o comprimento
> >>>
> >>> Abs, Joã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
> >>
> >
> >
> >
> > --
> >
> > ... Edileuz, eu não tem nada a ver com Creuza,
> >É mentira da Ivete, não é meu esse caniveete...
> > "Halley, Luiz" - Poeta, Cantor, Compsitor
> >
> > ___
> > Talk-br mailing list
> > Talk-br@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-br
> >
>
>
>
> --
> Fernando Trebien
> +55 (51) 9962-5409
>
> "The speed of computer chips doubles every 18 months." (Moore's law)
> "The speed of software halves every 18 months." (Gates' law)
>
> ___
> 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] Como mapear numeração de ruas?

[John Packer]

Atualização: O meu amigo disse que não conseguiu entrar na lista. (não
entendi muito bem o que aconteceu, mas ele não chegou a tentar novamente).
No final das contas, ele colocou os números das ruas como loc_ref=*.

Acho que ficou apropriado.


Em 10 de fevereiro de 2014 22:27, Wille  escreveu:

>  Já vi em algumas cidades que nas placas com o nome da rua aparece um
> código chamado Logradouro. Porém nunca vi nenhum caso em que esse número
> fosse utilizado pela população ou que aparecesse nos mapas da prefeitura.
>
>
>
> On 10-02-2014 09:29, John Packer wrote:
>
>  Pedi clarificações para ele. Segue abaixo a resposta:
>
>> Então, desde que eu era pequeno me chamava a atenção isso (não sei por
>> quê hahahaha), e em Joinville também era comum essa prática de numerar as
>> ruas, mas de repente não se usou mais isso. Mas em Jaraguá as ruas recebem
>> números e nomes, as vezes só números. Em tudo o que se refere a ruas, como
>> mapas, as placas com nomes das ruas, vai o número, sempre antes do nome.
>>
>> Enfim, como todas as ruas e servidões têm um número e um nome, acredito
>> que seja um código da prefeitura, embora seja popular e bastante utilizado,
>> mas não sendo nem nome alternativo, nem nome antigo... não sei dizer qual
>> seria a tag mais adequada para essa numeração.
>>
>
>  Fico em dúvida como proceder.
> A minha impressão é que realmente ref é a etiqueta adequada, mas a
> visualização do mapa fica bem inadequada...
>  Pedi para ele contactar algum mapeador ativo de Jaraguá do Sul (espero
> que tenha algum mapeador experiente nessa região)
>
>  Vou pedir para ele passar o link do mapa que verificou.
>
>  Abs,
>  João
>
>
> Em 9 de fevereiro de 2014 20:32, Arlindo Pereira <
> openstreet...@arlindopereira.com> escreveu:
>
>> Se a numeração for o nome da rua (Rua 1, Rua 2 etc.) coloque "Rua Um" na
>> tag name e "Rua 1" na tag alt_name (ou o contrário, se preferir). A tag
>> alt_name não aparece na renderização do mapa mas é usada pelos serviços de
>> busca, e poderia ser usada por roteadores GPS.
>>
>> Se for o nome antigo (Rua Fulano de Tal, antiga Rua 1) coloque na tag
>> old_name.
>>
>> []s
>> Em 09/02/2014 19:08, "John Packer"  escreveu:
>>
>>>   Olá pessoal,
>>>
>>> Um amigo meu foi para "Jaraguá do Sul, SC" e percebeu que as ruas de lá
>>> tinham um número associado com elas. Ele confirmou isso vendo no mapa da
>>> prefeitura.
>>> Então ele colocou esses números na etiqueta ref. Mas a renderização no
>>> Mapnik ficou bem, digamos, 
>>> inadequada<http://www.openstreetmap.org/#map=16/-26.4559/-49.1055>
>>> .
>>>
>>>  Como é tratado esse tipo de coisa?
>>> Por mais que seja errado etiquetar para o renderizador, deixar como está
>>> não parece ser uma boa idéia. Será que podemos colocar como "alt_name=Rua
>>> #numero" ?
>>>  Será que deveriamos contactar algum mapeador ativo de Jaraguá do Sul?
>>>
>>>  Abs,
>>> Joã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
>>
>>
>
>
> ___
> Talk-br mailing 
> listTalk-br@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-br
>
>
>
> ___
> 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] Como mapear numeração de ruas?

[John Packer]

Já tinha mandado o link haha.

E tinha pedido para ele quando ele falou que não conseguiu.
Acho que vou pedir de novo mais pra frente.


Em 25 de fevereiro de 2014 21:19, Fernando Trebien <
fernando.treb...@gmail.com> escreveu:

> Manda pra ele o link da conversa:
> https://lists.openstreetmap.org/pipermail/talk-br/2014-February/thread.html
>
> E pede pra ele tentar ingressar de novo na lista. :D
>
> 2014-02-25 19:44 GMT-03:00 John Packer :
> > Atualização: O meu amigo disse que não conseguiu entrar na lista. (não
> > entendi muito bem o que aconteceu, mas ele não chegou a tentar
> novamente).
> > No final das contas, ele colocou os números das ruas como loc_ref=*.
> >
> > Acho que ficou apropriado.
> >
> >
> > Em 10 de fevereiro de 2014 22:27, Wille  escreveu:
> >
> >> Já vi em algumas cidades que nas placas com o nome da rua aparece um
> >> código chamado Logradouro. Porém nunca vi nenhum caso em que esse número
> >> fosse utilizado pela população ou que aparecesse nos mapas da
> prefeitura.
> >>
> >>
> >>
> >> On 10-02-2014 09:29, John Packer wrote:
> >>
> >> Pedi clarificações para ele. Segue abaixo a resposta:
> >>>
> >>> Então, desde que eu era pequeno me chamava a atenção isso (não sei por
> >>> quê hahahaha), e em Joinville também era comum essa prática de numerar
> as
> >>> ruas, mas de repente não se usou mais isso. Mas em Jaraguá as ruas
> recebem
> >>> números e nomes, as vezes só números. Em tudo o que se refere a ruas,
> como
> >>> mapas, as placas com nomes das ruas, vai o número, sempre antes do
> nome.
> >>>
> >>> Enfim, como todas as ruas e servidões têm um número e um nome, acredito
> >>> que seja um código da prefeitura, embora seja popular e bastante
> utilizado,
> >>> mas não sendo nem nome alternativo, nem nome antigo... não sei dizer
> qual
> >>> seria a tag mais adequada para essa numeração.
> >>
> >>
> >> Fico em dúvida como proceder.
> >> A minha impressão é que realmente ref é a etiqueta adequada, mas a
> >> visualização do mapa fica bem inadequada...
> >> Pedi para ele contactar algum mapeador ativo de Jaraguá do Sul (espero
> que
> >> tenha algum mapeador experiente nessa região)
> >>
> >> Vou pedir para ele passar o link do mapa que verificou.
> >>
> >> Abs,
> >> João
> >>
> >>
> >> Em 9 de fevereiro de 2014 20:32, Arlindo Pereira
> >>  escreveu:
> >>>
> >>> Se a numeração for o nome da rua (Rua 1, Rua 2 etc.) coloque "Rua Um"
> na
> >>> tag name e "Rua 1" na tag alt_name (ou o contrário, se preferir). A tag
> >>> alt_name não aparece na renderização do mapa mas é usada pelos
> serviços de
> >>> busca, e poderia ser usada por roteadores GPS.
> >>>
> >>> Se for o nome antigo (Rua Fulano de Tal, antiga Rua 1) coloque na tag
> >>> old_name.
> >>>
> >>> []s
> >>>
> >>> Em 09/02/2014 19:08, "John Packer"  escreveu:
> >>>>
> >>>> Olá pessoal,
> >>>>
> >>>> Um amigo meu foi para "Jaraguá do Sul, SC" e percebeu que as ruas de
> lá
> >>>> tinham um número associado com elas. Ele confirmou isso vendo no mapa
> da
> >>>> prefeitura.
> >>>> Então ele colocou esses números na etiqueta ref. Mas a renderização no
> >>>> Mapnik ficou bem, digamos, inadequada.
> >>>>
> >>>> Como é tratado esse tipo de coisa?
> >>>> Por mais que seja errado etiquetar para o renderizador, deixar como
> está
> >>>> não parece ser uma boa idéia. Será que podemos colocar como
> "alt_name=Rua
> >>>> #numero" ?
> >>>> Será que deveriamos contactar algum mapeador ativo de Jaraguá do Sul?
> >>>>
> >>>> Abs,
> >>>> Joã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
> >>>
> >>
> >>
> >>
> >> ___
> >> 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 mailing list
> > Talk-br@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-br
> >
>
>
>
> --
> Fernando Trebien
> +55 (51) 9962-5409
>
> "The speed of computer chips doubles every 18 months." (Moore's law)
> "The speed of software halves every 18 months." (Gates' law)
>
> ___
> 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] Problema de usabilidade do editor de endereços do iD

[John Packer]

Atualização:
O campo addr:housename foi retirado do iD, agora só pode ser incluído
manualmente usando etiquetas.

Um usuário (não-brasileiro) retirou o campo depois de ver que estava
confundindo usuários em outros países.
O *pull request* se encontra no seguinte link:
https://github.com/openstreetmap/iD/pull/2127

Sugiro agora retirar a tradução de addr:housename como Complemento.

Abs,
João
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Proposta de padronização de lombadas no Brasil

[John Packer]

Olha, vendo essa etiqueta traffic_calming=table, eu vou segurar a minha
proposta por um bom tempo até conseguir investigar melhor essa situação.

A pergunta é: existe alguma lombada de 3+ metros que não seja um
traffic_calming=table? (ou seja, que não tenha o topo achatado).
Sinceramente, nunca vi, e olha que já vi uns 4-5 traffic_calming=table aqui
na minha cidade.

Estou pensando que traffic_calming=bump é menor que 1,5m, mas vou tirar
umas fotos aqui pra montar melhor o meu caso (isso vai demorar umas duas
semanas pelo menos).

Quando às depressões, acho que teria que ser proposto uma nova etiqueta (
traffic_calming=depression ou algo assim).
Alguém tem uma foto dela?

Abs,
João


Em 25 de fevereiro de 2014 18:46, Arlindo Pereira <
openstreet...@arlindopereira.com> escreveu:

> Acho que as depressões poderiam ser bump/hump com depression=yes ou algo
> assim, visto que é a mesma função.
>
> Ou propor um valor traffic_calming=depression. O que vocês acham?
>
> Tenho essa foto aqui, que não mostra a depressão em si mas dá uma ideia,
> hehe.
>
>
>
> Isso foi em Foz do Iguaçu :P
>
> Procurar por "depressão na pista" no Google Imagens retorna resultados
> semelhantes. :P
>
> []s
> Arlindo
>
> 2014-02-25 16:54 GMT-03:00 Marcelo Pereira :
>
>> Considerações, minhas :
>>
>> - Aqui pros lados do NE tb é conhecida como quebra-molas.
>>
>> - Já vi muitos casos de lombadas feitas pela própria população, nota-se a
>> diferença pela total falta de padrão, mas estas tendem a ser mais altas que
>> as "oficiais", já vi até "triangulares" ( exemplo http://goo.gl/RC3ogE). 
>> Neste caso, que tag usar ?
>>
>> - Já vi lombadas de terra, em vias do mesmo tipo, e aí ?
>>
>> - Aqui perto de casa, tem uma lombada mais larga, que traz no seu corpo
>> uma faixa de pedestres ( exemplo http://goo.gl/16S98g ), como se
>> classificaria isso ?
>>
>> Aproveitando o embalo, não sei se ainda existem, mas cheguei a ver
>> lombadas invertidas, ou seja, depressões na pista usadas como lombadas.
>> Isso recebe tag ?
>>
>> Marcelo Pereira
>>
>>
>> Em 25 de fevereiro de 2014 16:06, Fernando Trebien <
>> fernando.treb...@gmail.com> escreveu:
>>
>> Por mim tá perfeito.
>>> On Feb 25, 2014 3:38 PM, "John Packer"  wrote:
>>>
>>>> Pessoal,
>>>> em uma discussão recente aqui na lista, percebi que tem duas formas
>>>> diferentes de etiquetar uma lombada: traffic_calming=bump e
>>>> traffic_calming=hump.
>>>>
>>>> Vi que não havia uma padronização quanto a isso no Brasil, então
>>>> levantei as mangas e comecei a pesquisar.
>>>>
>>>> Em primeiro lugar descobri que tem outros nomes para uma lombada:
>>>>
>>>>- lomba (que é sinônimo de lombada)
>>>>- quebra-mola (que é utilizado no RS)
>>>>- ondulação transversal (que é um termo mais abrangente)
>>>>
>>>> E descobri que existem sim dois tipos de lombada: *Tipo I* e *Tipo II*.
>>>> Como podem ver no seguinte link:
>>>> http://www.cliqueautomotivo.com.br/index.php?pg=sobrerodas/lombada-ou-quebra-molas
>>>>
>>>> O tipo 1 é menor que o tipo 2, mas é também mais curto, forçando o
>>>> usuário a reduzir mais a velocidade do que no tipo 2.
>>>>
>>>> Nas definições de *Bump* que vi, era assim mesmo, com a única
>>>> diferença sendo que *Bump* poderia ter uma altura maior do que *Hump*em 
>>>> alguns casos.
>>>>
>>>> Logo, a minha proposta de padronização é a seguinte:
>>>>
>>>>- em lombadas Tipo I  => traffic_calming=bump
>>>>- em lombadas Tipo II => traffic_calming=hump
>>>>- se não se encaixar em um desses tipos, deve ser etiquetado o mais
>>>>próximo, de acordo com o *comprimento*
>>>>
>>>> Abs, Joã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
>>>
>>>
>>
>>
>> --
>>
>> ... Edileuz, eu não tem nada a ver com Creuza,
>>É mentira da Ivete, não é meu esse caniveete...
>> "Halley, Luiz" - Poeta, Cantor, Compsitor
>>
>> ___
>> 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 mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Proposta de padronização de lombadas no Brasil

[John Packer]

> Não há tag para quebra-molas irregulares/ilegais/menores que o tamanho
> padrão. Podemos propor uma. Mas não acho legal subverter o significado de
> "bump" para isso. Talvez "dangerous_bump" ou "bump" + "irregular=yes" ou
> "illegal=yes" ou algo do tipo.
>
É verdade, não posso negar que *bump* se encaixem bem com lombadas Tipo I.
Seria bom ter como etiquetar lombadas irregulares, tanto porquê não é tão
incomum assim, mas acho que não seja tão fácil fazer isso de forma
objetiva(fora colocar height=* e length=*(respectivamente altura e
comprimento), que exige um bom esforço).

Portanto, "table" seria esse tipo de travessia específica e "bump" e "hump"
> quebra-molas/lombadas, sendo "bump" o quebra-mola tradicional e "hump" um
> tipo de quebra-mola que só seria utilizado em estradas federais ou
> estaduais.
>
Você já viu lombadas Tipo II (que tem 3+ metros de comprimento) em estradas
federais ou estaduais no Brasil?



Em 27 de fevereiro de 2014 11:23, Arlindo Pereira <
openstreet...@arlindopereira.com> escreveu:

> (Acabei mandando antes)
>
> Portanto, "table" seria esse tipo de travessia específica e "bump" e
> "hump" quebra-molas/lombadas, sendo "bump" o quebra-mola tradicional e
> "hump" um tipo de quebra-mola que só seria utilizado em estradas federais
> ou estaduais.
>
> Não há tag para quebra-molas irregulares/ilegais/menores que o tamanho
> padrão. Podemos propor uma. Mas não acho legal subverter o significado de
> "bump" para isso. Talvez "dangerous_bump" ou "bump" + "irregular=yes" ou
> "illegal=yes" ou algo do tipo.
>
>
> []s
> Arlindo
>
> 2014-02-27 11:21 GMT-03:00 Arlindo Pereira <
> openstreet...@arlindopereira.com>:
>
> Não sei. Acho que table é outra coisa.
>>
>> (Importante mencionar que eu não dirijo, ok? Minha impressão é meramente
>> pela observação das ruas.)
>>
>> Pra mim, table é isso:
>> http://www.ite.org/css/online/img/Figure9-17.jpg
>> http://www.cyclestreets.net/location/47587/cyclestreets47587-size640.jpg
>>
>> http://wiki.coe.neu.edu/groups/nl2011transpo/wiki/5e21c/images/__thumbs__/3ffdd.jpg
>>
>> http://2.bp.blogspot.com/-gIoeIhSgaP0/UZu8XGmSnHI/AeU/-c2c-BT2BPs/s1600/Elwick+Road,+Ashford.jpg
>>
>> http://2.bp.blogspot.com/_nqmNLgL2k80/TOV5_AuWSNI/Bao/ptlW4H6I62w/s1600/12457.jpg
>>
>> http://3.bp.blogspot.com/-eZhsiJXAbQA/TdhHhRQKSgI/Aps/DbPwZtSzspw/s1600/San+Telmo+-+Chile.jpg
>>
>> Em resumo, via de regra utilizados em travessias de pedestres aonde não
>> há uma rampa da calçada para o nível do asfalto, mas sim o inverso, uma
>> rampa do asfalto para o nível da calçada.
>>
>>  []s
>> Arlindo
>>
>>
>> 2014-02-27 11:14 GMT-03:00 Fernando Trebien :
>>
>> Acho que a principal diferença entre table e hump é o formato: hump é
>>> suave, table é trapezoidal. Independente da extensão.
>>>
>>> A Wikipédia diz que humps podem ter entre 3m e 4.3m de extensão.
>>>
>>>
>>> 2014-02-26 23:45 GMT-03:00 John Packer :
>>>
>>> Olha, vendo essa etiqueta traffic_calming=table, eu vou segurar a minha
>>>> proposta por um bom tempo até conseguir investigar melhor essa situação.
>>>>
>>>> A pergunta é: existe alguma lombada de 3+ metros que não seja um
>>>> traffic_calming=table? (ou seja, que não tenha o topo achatado).
>>>> Sinceramente, nunca vi, e olha que já vi uns 4-5 traffic_calming=tableaqui 
>>>> na minha cidade.
>>>>
>>>> Estou pensando que traffic_calming=bump é menor que 1,5m, mas vou
>>>> tirar umas fotos aqui pra montar melhor o meu caso (isso vai demorar umas
>>>> duas semanas pelo menos).
>>>>
>>>> Quando às depressões, acho que teria que ser proposto uma nova etiqueta
>>>> (traffic_calming=depression ou algo assim).
>>>> Alguém tem uma foto dela?
>>>>
>>>> Abs,
>>>> João
>>>>
>>>>
>>>> Em 25 de fevereiro de 2014 18:46, Arlindo Pereira <
>>>> openstreet...@arlindopereira.com> escreveu:
>>>>
>>>> Acho que as depressões poderiam ser bump/hump com depression=yes ou
>>>>> algo assim, visto que é a mesma função.
>>>>>
>>>>> Ou propor um valor traffic_calming=depression. O que vocês acham?
>>>>>
>>>>> Tenho essa foto aqui, que não mostra a depressão em si mas dá uma
>>>>> ideia

Re: [Talk-br] Proposta de padronização de lombadas no Brasil

[John Packer]

Amigos,
Descobri qual é o termo brasileiro para traffic_calming=table. É "Travessia
Elevada".

Com isso, acredito que os nós da proposta fecham.
Farei uma página de desambiguação na wiki chamada "Lombada", e redirecionar
os links traffic_calming=bump, traffic_calming=hump e
traffic_calming=tablepara essa página.

Também adicionarei os seguintes termos na página de referência de traduções:

   - *Bump* = Lombada Tipo I
   - *Hump* = Lombada Tipo II
   - *Table (traffic calming)* = Travessia Elevada

E classificarei essas traduções como literais.
(isso tudo assim que tiver tempo)



Em 27 de fevereiro de 2014 11:28, Fernando Trebien <
fernando.treb...@gmail.com> escreveu:

> Elas ocorrem em travessias de pedestre, mas pelo que diz na Wikipédia, não
> só nessa situação.
> http://en.wikipedia.org/wiki/Vertical_deflection_traffic_calming_device#Speed_tables
>
> Talvez no Brasil seja só nessa situação.
>
> Além disso, acho que "tables" não são chamadas de "lombadas" no Brasil.
>
>
> 2014-02-27 11:23 GMT-03:00 Arlindo Pereira <
> openstreet...@arlindopereira.com>:
>
> (Acabei mandando antes)
>>
>> Portanto, "table" seria esse tipo de travessia específica e "bump" e
>> "hump" quebra-molas/lombadas, sendo "bump" o quebra-mola tradicional e
>> "hump" um tipo de quebra-mola que só seria utilizado em estradas federais
>> ou estaduais.
>>
>> Não há tag para quebra-molas irregulares/ilegais/menores que o tamanho
>> padrão. Podemos propor uma. Mas não acho legal subverter o significado de
>> "bump" para isso. Talvez "dangerous_bump" ou "bump" + "irregular=yes" ou
>> "illegal=yes" ou algo do tipo.
>>
>>
>> []s
>> Arlindo
>>
>> 2014-02-27 11:21 GMT-03:00 Arlindo Pereira <
>> openstreet...@arlindopereira.com>:
>>
>> Não sei. Acho que table é outra coisa.
>>>
>>> (Importante mencionar que eu não dirijo, ok? Minha impressão é meramente
>>> pela observação das ruas.)
>>>
>>> Pra mim, table é isso:
>>> http://www.ite.org/css/online/img/Figure9-17.jpg
>>> http://www.cyclestreets.net/location/47587/cyclestreets47587-size640.jpg
>>>
>>> http://wiki.coe.neu.edu/groups/nl2011transpo/wiki/5e21c/images/__thumbs__/3ffdd.jpg
>>>
>>> http://2.bp.blogspot.com/-gIoeIhSgaP0/UZu8XGmSnHI/AeU/-c2c-BT2BPs/s1600/Elwick+Road,+Ashford.jpg
>>>
>>> http://2.bp.blogspot.com/_nqmNLgL2k80/TOV5_AuWSNI/Bao/ptlW4H6I62w/s1600/12457.jpg
>>>
>>> http://3.bp.blogspot.com/-eZhsiJXAbQA/TdhHhRQKSgI/Aps/DbPwZtSzspw/s1600/San+Telmo+-+Chile.jpg
>>>
>>> Em resumo, via de regra utilizados em travessias de pedestres aonde não
>>> há uma rampa da calçada para o nível do asfalto, mas sim o inverso, uma
>>> rampa do asfalto para o nível da calçada.
>>>
>>>  []s
>>> Arlindo
>>>
>>>
>>> 2014-02-27 11:14 GMT-03:00 Fernando Trebien 
>>> :
>>>
>>> Acho que a principal diferença entre table e hump é o formato: hump é
>>>> suave, table é trapezoidal. Independente da extensão.
>>>>
>>>> A Wikipédia diz que humps podem ter entre 3m e 4.3m de extensão.
>>>>
>>>>
>>>> 2014-02-26 23:45 GMT-03:00 John Packer :
>>>>
>>>> Olha, vendo essa etiqueta traffic_calming=table, eu vou segurar a
>>>>> minha proposta por um bom tempo até conseguir investigar melhor essa
>>>>> situação.
>>>>>
>>>>> A pergunta é: existe alguma lombada de 3+ metros que não seja um
>>>>> traffic_calming=table? (ou seja, que não tenha o topo achatado).
>>>>> Sinceramente, nunca vi, e olha que já vi uns 4-5 
>>>>> traffic_calming=tableaqui na minha cidade.
>>>>>
>>>>> Estou pensando que traffic_calming=bump é menor que 1,5m, mas vou
>>>>> tirar umas fotos aqui pra montar melhor o meu caso (isso vai demorar umas
>>>>> duas semanas pelo menos).
>>>>>
>>>>> Quando às depressões, acho que teria que ser proposto uma nova
>>>>> etiqueta (traffic_calming=depression ou algo assim).
>>>>> Alguém tem uma foto dela?
>>>>>
>>>>> Abs,
>>>>> João
>>>>>
>>>>>
>>>>> Em 25 de fevereiro de 2014 18:46, Arlindo Pereira <
>>>>> openstreet...@arlindopereira.com> escreveu:
>>>>>
>>>>> Acho que a

Re: [Talk-br] Proposta de padronização de lombadas no Brasil

[John Packer]

>
> Sugestão: ao colocar as traduções, coloque também a fonte delas. Por
> exemplo, onde você descobriu que table é "travessia elevada", foi alguma
> fonte oficial? Mais adiante, pode ser necessário saber.

Hum, eu não lembro como vi pela primeira vez, mas pesquisei por imagens
usando esse termo, e apareceu placas com esse nome.
Pesquisando no DENATRAN, apareceu um outro termo: "Faixa Elevada para
travessia de pedestres"
[1]<http://www.denatran.gov.br/download/Minuta%20Faixa%20Elevada%2006-05-1.DOC>.


Eu ainda acho que "table" pode existir em lugares que não são travessias.
> Mas se a definição desse termo oficialmente (dada por algum Detran ou pelo
> DNIT ou pelo CTB) permitir essa interpretação, então traduziremos assim.
>
É, parece que segundo a lei, travessias elevadas tem que ter faixa de
pedestre (veja o Art.7°. IV
aqui[1]<http://www.denatran.gov.br/download/Minuta%20Faixa%20Elevada%2006-05-1.DOC>
).
Mas me ajudem aqui: o que é minuta, e por que ela não tem um número nela?

Quando à questão das depressões, não lembro de ter visto uma antes, então
não vou poder ajudar nisso.



Em 27 de fevereiro de 2014 12:52, Fernando Trebien <
fernando.treb...@gmail.com> escreveu:

> Sugestão: ao colocar as traduções, coloque também a fonte delas. Por
> exemplo, onde você descobriu que table é "travessia elevada", foi alguma
> fonte oficial? Mais adiante, pode ser necessário saber.
>
> Eu ainda acho que "table" pode existir em lugares que não são travessias.
> Mas se a definição desse termo oficialmente (dada por algum Detran ou pelo
> DNIT ou pelo CTB) permitir essa interpretação, então traduziremos assim.
>
>
> 2014-02-27 12:28 GMT-03:00 John Packer :
>
> Amigos,
>> Descobri qual é o termo brasileiro para traffic_calming=table. É
>> "Travessia Elevada".
>>
>> Com isso, acredito que os nós da proposta fecham.
>> Farei uma página de desambiguação na wiki chamada "Lombada", e
>> redirecionar os links traffic_calming=bump, traffic_calming=hump e
>> traffic_calming=table para essa página.
>>
>> Também adicionarei os seguintes termos na página de referência de
>> traduções:
>>
>>- *Bump* = Lombada Tipo I
>>- *Hump* = Lombada Tipo II
>>- *Table (traffic calming)* = Travessia Elevada
>>
>> E classificarei essas traduções como literais.
>> (isso tudo assim que tiver tempo)
>>
>>
>>
>> Em 27 de fevereiro de 2014 11:28, Fernando Trebien <
>> fernando.treb...@gmail.com> escreveu:
>>
>> Elas ocorrem em travessias de pedestre, mas pelo que diz na Wikipédia,
>>> não só nessa situação.
>>> http://en.wikipedia.org/wiki/Vertical_deflection_traffic_calming_device#Speed_tables
>>>
>>> Talvez no Brasil seja só nessa situação.
>>>
>>> Além disso, acho que "tables" não são chamadas de "lombadas" no Brasil.
>>>
>>>
>>> 2014-02-27 11:23 GMT-03:00 Arlindo Pereira <
>>> openstreet...@arlindopereira.com>:
>>>
>>> (Acabei mandando antes)
>>>>
>>>> Portanto, "table" seria esse tipo de travessia específica e "bump" e
>>>> "hump" quebra-molas/lombadas, sendo "bump" o quebra-mola tradicional e
>>>> "hump" um tipo de quebra-mola que só seria utilizado em estradas federais
>>>> ou estaduais.
>>>>
>>>> Não há tag para quebra-molas irregulares/ilegais/menores que o tamanho
>>>> padrão. Podemos propor uma. Mas não acho legal subverter o significado de
>>>> "bump" para isso. Talvez "dangerous_bump" ou "bump" + "irregular=yes" ou
>>>> "illegal=yes" ou algo do tipo.
>>>>
>>>>
>>>> []s
>>>> Arlindo
>>>>
>>>> 2014-02-27 11:21 GMT-03:00 Arlindo Pereira <
>>>> openstreet...@arlindopereira.com>:
>>>>
>>>> Não sei. Acho que table é outra coisa.
>>>>>
>>>>> (Importante mencionar que eu não dirijo, ok? Minha impressão é
>>>>> meramente pela observação das ruas.)
>>>>>
>>>>> Pra mim, table é isso:
>>>>> http://www.ite.org/css/online/img/Figure9-17.jpg
>>>>>
>>>>> http://www.cyclestreets.net/location/47587/cyclestreets47587-size640.jpg
>>>>>
>>>>> http://wiki.coe.neu.edu/groups/nl2011transpo/wiki/5e21c/images/__thumbs__/3ffdd.jpg
>>>>>
>>>>> http://2.bp.blogspot.com/-gIoeIhSgaP0/UZu8XGmSnHI/AeU/-c2c-BT2BPs/s160

Re: [Talk-br] Proposta de padronização de lombadas no Brasil

[John Packer]

Marcelo,

Concordo que seria melhor ter só um tipo de lombada, mas já existem essas 3
formas diferentes de etiquetar lombadas no OSM, então é bom ter uma
padronização de como os brasileiros utilizam essas etiquetas.

Felizmente no final das contas não fica muito complicado não.
Basicamente as regrinhas são as seguintes:

   1. Se a lombada tiver menos de 2 metros, é traffic_calming=bump
   2. Se a lombada tiver mais de 2 metros e não tiver uma faixa de
   pedestres em cima (e/ou não tiver um topo reto), é traffic_calming=hump
   3. Se a lombada tiver mais de 2 metros, uma faixa de pedestres em cima
   e/ou topo reto, é traffic_calming=table (e highway=crossing se
   necessário)

Adicione highway=speed_camera se for uma lombada eletrônica.

Ainda por cima, vale notar que a segunda opção(*hump*) não é muito comum.

A diferença que o tipo de lombada faz é quanto a velocidade em que um carro
pode passar por ela, em uma de tipo I (*bump*), tem que passar mais devagar
que nas outras.
Quanto aos sonorizadores, eles também são utilizados em algumas rodovias
(pra alertar sobre uma curva perigosa, por exemplo) e já tem uma etiqueta
própria: traffic_calming=rumble_strip. (*rumble strip* pode ser traduzido
grosseiramente como "faixa de barulho")

Abs,
João
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Parque aquático não renderizado no slippy map do OSM

[John Packer]

Pra mim, se eu ir na camada humanitária, aparece o nome. Senão não aparece
nada.

Gerald, parece que o conjunto de alterações dele foi feito 21 horas atrás.


Em 27 de fevereiro de 2014 18:59, Gerald Weber escreveu:

> Para mim aparece. Há quanto tempo você colocou? Pode ser um problema do
> cache do seu navegador.
>
> abraço
>
> Gerald
>
>
> 2014-02-27 18:54 GMT-03:00 Paulo Carvalho :
>
>>  Pessoal,
>>
>> Recentemente coloquei um parque aquático aqui:
>> http://www.openstreetmap.org/#map=17/-22.98126/-43.48673 , mas o mesmo
>> não está sendo renderizado.  Pesquisei onde reportar o problema, mas
>> aparentemente não existe onde reportar:
>> http://wiki.openstreetmap.org/wiki/Talk:Slippy_Map#Contcact.2C_error_.2B_wishlist_reporting.3F.
>> Parece algum problema da folha de estilo e não do Mapnik.  O parque
>> deveria aparece ao sul do estacionamento e à direita do caminho "acesso Rio
>> Water Planet"
>>
>> []s
>>
>> PC
>>
>> ___
>> 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 mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Nós isolados sem tags

[John Packer]

Encontrei aqui como selecionar:
https://help.openstreetmap.org/questions/18424/josm-search-function-find-orphan-nodes
A resposta é type:node untagged -child


Em 27 de fevereiro de 2014 19:07, Paulo Carvalho <
paulo.r.m.carva...@gmail.com> escreveu:

> Pessoal,
>
>Como selecionar nós soltos e sem tags no JOSM?  Tentei usar os filtors,
> mas não consegui uma forma de separar os nós sem tags que pertencem a
> linhas (esses devem ficar, evidentemente) daqueles que estão soltos (esses
> quero eliminar).
>
> []s
>
> Paulo
>
> ___
> 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] Formatação de trevos e rotatórias

[John Packer]

Olá Raffaelo, estou enviando esta mensagem somente para você.

Só queria avisar que os seus emails de hoje  estão com uma formatação
estranha (com 3 fontes diferentes sendo usadas, e 2 tamanhos de fonte).

Abs,
João


Em 28 de fevereiro de 2014 16:46, Raffaello Bruno Limongi Freire <
raffaellobr...@hotmail.com> escreveu:

> Oi,
>
> gostaria de saber se há alguma orientação disponível sobre a formatação
> de trevos e rotatórias.
>
> Por exemplo, estou analisando aa rotatória representada pela Linha:
> 248097232, onde a formatação está como unclassified. Porém, ela liga BRs
> que têm a classificação primary. Além disso, as vias de acesso estão
> formatadas como secondary_link. Acho que todas essas vias (rotatórias e
> acessos) devem ter a mesma formatação das vias ao quais estão interligadas,
> para que não haja descontinuidades de formatação que poderiam influenciar o
> roteamento.
>
> Obrigado.
> Raffaello Bruno
>
>
> ___
> 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] Formatação de trevos e rotatórias

[John Packer]

D'OH!


2014-02-28 18:14 GMT-03:00 Nelson A. de Oliveira :

> 2014-02-28 18:13 GMT-03:00 John Packer :
> > Olá Raffaelo, estou enviando esta mensagem somente para você.
>
> Veio para todo mundo :-)
>
> ___
> 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] BR-101

[John Packer]

Pessoal, sobre a BR-101,
A relação dela está bem quebrada.
Isso sempre foi assim, ou quebraram com o tempo?

Achei engraçado que uma igreja se adicionou na relação por alguma razão.

Link da relação: http://www.openstreetmap.org/relation/53556

Abs,
João
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Problema de usabilidade do editor de endereços do iD

[John Packer]

Bem, eu acho que o campo addr:housename não pode ser realmente considerado
como "Complemento", justamente devido à existência dos campos addr:door,
addr:unit e outros.

Para mim, a tradução como "Complemento" era só uma solução temporária
devido ao estado do formulário de endereços do editor iD. Pois pelo menos
não colocariam o nome do lugar ou o nome da rua lá.

Veja a descrição de addr:housename:

>
> *The name of a house. This is sometimes used in some countries like
> England instead of (or in addition to) a house number. *

Quando fala "*instead of (or in addition to) a house number*", eu não
acredito que seja o número da casa dentro do mesmo campo, mas dentro do seu
respectivo campo (addr:housenumber).

Eu acho que utilizar addr:housename como "Complemento" é criar trabalho
para outros corrigirem no futuro.

Atenciosamente,
João


Em 27 de fevereiro de 2014 12:09, Fernando Trebien <
fernando.treb...@gmail.com> escreveu:

> Annotation/Addresses (inglês) ou Endereços e Contactos/Endereços
> (português de Portugal) ou Anotação/Endereços (português brasileiro).
>
> 2014-02-27 11:30 GMT-03:00 Nelson A. de Oliveira :
> > 2014-02-27 11:22 GMT-03:00 Fernando Trebien  >:
> >> Os presets de endereço do JOSM ainda incluem esse campo, e não incluem
> >> os outros (addr:door, addr:unit, etc.).
> >
> > Qual preset que cria addr:housename?
> >
> > ___
> > Talk-br mailing list
> > Talk-br@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-br
>
>
>
> --
> Fernando Trebien
> +55 (51) 9962-5409
>
> "The speed of computer chips doubles every 18 months." (Moore's law)
> "The speed of software halves every 18 months." (Gates' law)
>
> ___
> 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] BR-101

[John Packer]

Olá Flávio,
Vi na Wiki que você quem tinha organizado as rodovias estaduais e federais
antes.
Deve ter dado um trabalhão, está de parabéns.

Ela não existe no Paraná e no extremo sul de São Paulo eu não tenho certeza
> do local exato, mas fora isso estava pronta.
>
Não entendi essa parte. Você quer dizer que a BR-101 não existe fisicamente
no Paraná(e parte de SP), ou que não tinha sido mapeada?

Descobri que tem um site que analisa uma relação para ver se está
conectada. ( http://ra.osmsurround.org/ )
Podemos utilizar no futuro para facilmente descobrir quando a relação é
quebrada.

Johnsen,
Concordo que a BR-101 é um exemplo de uma relação que seria bom transformar
em super-relação.
Acho que uma relação por estado é um bom critério por ser fácil de
verificar.

Abs,
João


Em 3 de março de 2014 18:36, Aun Johnsen  escreveu:

> So um sugesao, pensei em fazer isso muito tempo mas nao ha tempo p realizar
>
> Os rodovias grande que passa varios estados pode ser dividido em um
> relacao por cada estado com um superrelacao juntando tudos
>
>
> Este vai reduzir a chanca de erros assim acontecer
>
> Aun Johnsen
> Sent from my iPhone
>
> On 3. mars 2014, at 17:05, Flavio Bello Fialho 
> wrote:
>
> Eu tinha acertado toda a relação da BR-101 no Brasil inteiro. Se está
> quebrada é porque quebraram depois. Ela não existe no Paraná e no extremo
> sul de São Paulo eu não tenho certeza do local exato, mas fora isso estava
> pronta.
> Em 28/02/2014 21:56, "Fernando Trebien" 
> escreveu:
>
>> Tem o plugin public_transport do JOSM que ajuda a mapear rotas de
>> ônibus, mas a sua vantagem principal é reconhecer as paradas e
>> incluí-las na relação da rota. Se você só quer consertar a rota, o
>> editor genérico do JOSM até dá menos trabalho.
>>
>> Os passos são sempre os mesmos: criar uma relação (se não existir) ou
>> baixá-la no JOSM (menu Arquivo/Ficheiro > Descarregar Objeto), e
>> adicionar os membros que faltam. Pra garantir que não sobraram
>> buracos, tem um botão no editor de relações do JOSM que põe em ordem
>> os membros da relação de acordo com a ordem em que se conectam, e daí
>> a terceira coluna (destaque #2 da primeira imagem aqui:
>>
>> http://wiki.openstreetmap.org/wiki/File:Tutorial-restricoes-07-exemplo-05-linha-como-intermediario.png
>> )
>> indica em que trechos a via não está conectada (onde faltam pedaços ou
>> onde há pedaços que se sobrepõem). Use o botão, olhe a coluna, inclua
>> os trechos que faltam, ordene de novo, observe a coluna de novo,
>> repita até não sobrarem falhas. É um trabalho chato, mas não tem jeito
>> melhor de fazer (ainda). E em algumas situações, não há uma correção
>> "óbvia": você tem que parar e descobrir como a rota era originalmente
>> pra descobrir qual membro reincluir na relação.
>>
>> Ah, e o validador do JOSM também avisa sobre relações de rota com
>> trechos desconectados.
>>
>> 2014-02-28 21:36 GMT-03:00 Paulo Carvalho :
>> > Confesso que andei quebrando umas rotas, porém não consegui consertar.
>>  É
>> > muito complicado de fazer no JOSM, ainda mais essas rotas que são muito
>> > extensas.  Há algum plugin ou tutorial que ensine a desenhar essas
>> rotas de
>> > transporte público?
>> >
>> >
>> > Em 28 de fevereiro de 2014 20:20, John Packer 
>> > escreveu:
>> >>
>> >> Pessoal, sobre a BR-101,
>> >> A relação dela está bem quebrada.
>> >> Isso sempre foi assim, ou quebraram com o tempo?
>> >>
>> >> Achei engraçado que uma igreja se adicionou na relação por alguma
>> razão.
>> >>
>> >> Link da relação: http://www.openstreetmap.org/relation/53556
>> >>
>> >> Abs,
>> >> Joã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
>> >
>>
>>
>>
>> --
>> Fernando Trebien
>> +55 (51) 9962-5409
>>
>> "The speed of computer chips doubles every 18 months." (Moore's law)
>> "The speed of software halves every 18 months." (Gates' law)
>>
>> ___
>> 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 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] Pergunta rápida sobre pontos de ônibus

[John Packer]

Se um ponto de ônibus tem uma placa nele com um nome (por exemplo "João
Colin 01").
Esse nome vai na etiqueta name ou ref?

Eu estava colocando em name, pois imagino que o ponto possa ter um número
de referência da empresa(talvez somente interno).
Mas fiquei em dúvida agora..

O que vocês acham?
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Progresso com os mapas do IBGE

[John Packer]

Uma cidade pequena: Campo Alegre - SC

Uma cidade grande (menor prioridade): Joinville - SC


Em 7 de março de 2014 22:08, Erick de Oliveira Leal <
erickdeoliveiral...@gmail.com> escreveu:

> Então deixe o DF por enquanto, rs. São Sebastião do Anta - MG e Cairu - BA
> (onde se situa o Morro de São Paulo)
>
>
> Em 7 de março de 2014 22:04, Thiago Marcos P. Santos 
> escreveu:
>
> Algum lugar específico do DF? A granularidade é código de cidade obtido
>> aqui:
>>
>> http://www.ibge.gov.br/home/geociencias/areaterritorial/area.shtm
>>
>> Ps.: Cidades grandes como Brasília são impraticáveis no momento devido
>> à limitações computacionais. Tou rodando um teste com BH para ter
>> ideia do tamanho do problema.
>>
>> 2014-03-08 2:59 GMT+02:00 Erick de Oliveira Leal
>> :
>> > Distrito federal e Morro de São Paulo, BA
>> >
>> >
>> > Em 7 de março de 2014 21:47, Thiago Marcos P. Santos <
>> tmpsan...@gmail.com>
>> > escreveu:
>> >>
>> >> 2014-03-08 2:36 GMT+02:00 Raffaello Bruno Limongi Freire
>> >> :
>> >> > Oi, Thiago,
>> >> >
>> >> > ficou muito bom.
>> >> >
>> >>
>> >> Valeu!
>> >>
>> >> > Essas imagens do IBGE serão úteis também naqueles lugares onde não há
>> >> > tracks
>> >> > de GPS ou imagens do Bing disponíveis, pois permitirão que se faça um
>> >> > desenho preliminar das vias (no Tracksource chamamos de Draft),
>> >> > inserindo-se
>> >> > a tag fixme para que se corrija o traçado assim que novas fontes de
>> >> > consulta
>> >> > estiverem disponíveis (tracks, Bing, etc.).
>> >>
>> >> Acho que vai ser bom também para pegar nomes de ruas e até mesmo nomes
>> >> de alguns Pontos de Interesse.
>> >>
>> >> BTW, atendendo à pedidos, segue Bom Despacho - MG:
>> >>
>> >> http://tiles.tmpsantos.com.br/31/3107406/
>> >>
>> >> Estou quebrando a cabeça para ver como escalar o processo para muitas
>> >> cidades, pode demorar um tempo. Mas se alguém tiver interesse em
>> >> alguma cidade específica, é só pedir aqui na lista que eu gero o mapa.
>> >>
>> >> []'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
>> >
>>
>> ___
>> 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 mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Pergunta rápida sobre pontos de ônibus

[John Packer]

>
> Em Belo Horizonte, as maiores paradas - ao menos as que dispõem de abrigo
> - todas têm nome oficial.
>
Sim, este é o meu caso.
Não cheguei a responder antes, mas concordo que nesse caso o nome deve ser
colocado na etiqueta name.


Em 11 de março de 2014 16:57, Vítor Rodrigo Dias escreveu:

> Em Belo Horizonte, as maiores paradas - ao menos as que dispõem de abrigo
> - todas têm nome oficial.
> Em 11/03/2014 16:53, "Erick de Oliveira Leal" <
> erickdeoliveiral...@gmail.com> escreveu:
>
>  Acho q isso ta ficando burocrático demais. Paradas não costumam ser
>> nomeadas pelo estado, ou costumam? E mesmo que tivesse esse name seria o
>> temporário. Se um dia alguem tivesse o oficial substituiria, não?
>> Em 11/03/2014 16:48, "Thiago Marcos P. Santos" 
>> escreveu:
>>
>>> 2014-03-11 21:06 GMT+02:00 Nelson A. de Oliveira :
>>> > 2014-03-11 16:04 GMT-03:00 Raffaello Bruno Limongi Freire
>>> > :
>>> >> Ao invés disso, não surtiria o mesmo efeito se a tag name fosse
>>> deixada em
>>> >> branco e o nome não oficial fosse colocado na tag alt_name? Ou a tag
>>> >> alt_name só pode ser utilizada após a utilização da tag name?
>>> >
>>> > alt_name é um nome alternativo
>>> > Não faz sentido ter nome alternativo sem existir um nome propriamente
>>> dito :-)
>>> >
>>>
>>> Concordo. Eu usaria "loc_name" neste caso.
>>>
>>> ___
>>> 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 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] Pergunta rápida sobre pontos de ônibus

[John Packer]

Existem alguns casos em que não tem problema colocar um nome não oficial na
etiqueta name.
Mais precisamente, nos casos em que se alguma pessoa regular olhar aquele
nome no mapa, não reconheceria o lugar.
Neste caso, o nome oficial iria para outras etiquetas como alt_name e
official_name.

Por exemplo, eu faço isso no meu campus. Poucas pessoas iriam reconhecer
"Campus Universitário Prof. Avelino Marcante" ou "Centro de Ciências
Tecnológicas". Coloquei como nome "UDESC Joinville". Os outros nomes foram
em official_name e alt_name, respectivamente.


Em 11 de março de 2014 17:34, Raffaello Bruno Limongi Freire <
raffaellobr...@hotmail.com> escreveu:

> "*todos os *_name são alternativas ao name*"
>
> Realmente.
>
> Mas a impressão que eu tenho (claro que posso estar errado) é que, quando
> se deixa name em branco e se usa *_name, quem verificar o objeto mapeado
> depois, mesmo que não haja observação alguma (tag note ou fixme, por
> exemplo), verá de cara que não se trata de um nome oficial, mas apenas de
> um nome "alternativo" pelo qual o objeto pode ser chamado ou referenciado.
>
> Pode ser até que o objeto não seja conhecido por nome algum, mas o
> mapeador achou interessante colocar alguma coisa que o caracterizasse,
> apenas para não deixar em branco, como por exemplo, "Shopping Center" no
> nome de uma parada (o fato de alguém dizer: "Eu estou na parada do
> Shopping", não faz que o nome dessa parada seja Shopping, mas serve como
> uma boa referência).
>
> Assim, acho que se o objeto realmente tiver algum nome, coloca-se na tag
> name sem necessidade de comentários, mas, se for um nome "alternativo",
> apenas para referência, se colocar na tag name, acho que poderia ser
> preenchido o campo note também, para que não haja dúvidas.
>
> Todavia, como bom senso, se eu for editar um objeto que já tenha na tag
> name um nome não oficial preenchido, caso eu obtenha algum nome oficial, eu
> coloco esse nome novo na tag name e o não oficial na tag alt_name. É melhor
> do que simplesmente substituir (a não ser que eu tenha certeza de que o que
> já estava preenchido esteja errado).
>
> Para ficar mais claro, vou dar um exemplo: editando o mapa de uma cidade,
> percebi uma praça cujo nome estava preenchido como "Praça do Trevo".
> Imaginei que esse não seria seu nome oficial. Procurando nos mapas do IBGE,
> vi que seu nome era "Praça Duque de Caxias". Assim, coloquei name como
> "Praça Duque de Caxias" e alt_name como "Praça do Trevo".
>
> Observação: apesar de o assunto inicial se tratar de pontos de ônibus,
> acho que essa discussão se aplica a qualquer objeto.
>
>
> > Date: Tue, 11 Mar 2014 16:53:50 -0300
> > From: nao...@gmail.com
>
> > To: talk-br@openstreetmap.org
> > Subject: Re: [Talk-br] Pergunta rápida sobre pontos de ônibus
> >
> > 2014-03-11 16:47 GMT-03:00 Thiago Marcos P. Santos  >:
> > > Concordo. Eu usaria "loc_name" neste caso.
> >
> > Mas da mesma forma, faz sentido ter um *_name sem ter name?
> > De forma muito simplista, todos os *_name são alternativas ao name.
> >
> > ___
> > 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 mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Pergunta rápida sobre pontos de ônibus

[John Packer]

Pelo que entendi o meu caso foi solucionado nos primeiros emails, e a
discussão que seguiu foi em volta de outro caso.


Em 12 de março de 2014 07:46, Marcelo Pereira escreveu:

> Srs,
>
> Fiquei agora sem entender pq tanta discussão em torno de um detalhe que já
> está previsto.
>
> Vejam o que está escrito na página de Transporte Público -BR (
> http://goo.gl/AxuKUB), para a identificação de Paradas de Ônibus :
>
> " ...
> Chave ValorDescricãotype site sitetextbus_stop refnumber or textcódigo
> identificador único, veja secão sobre ele abaixo nametext Nome da parada,
> facilmente identificável pelo passageiroAuthority textAutoridade
> responsável pelo local
>
> ... "
>
> A tag name serve exatamente para se colocar um nome "popular" da parada de
> ônibus.
>
> Recentemente inclui paradas em Recife e região e usei o exemplo acima.
>
> No caso específico daqui, a empresa de transporte local usa um código para
> identificar cada parada, que está impresso nas paradas, para esta
> informação usei a tag ref, nos moldes que está definido tb na mesma página.
>
> Alguem poderia me explicar porque não usar este modelo ? Existe algum erro
> que não estou vislumbrando ?
>
> Att,
>
> Marcelo Pereira
>
>
> ___
> 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] Área para circos, eventos, etc

[John Packer]

>
> Qual a diferença disso para landuse=recreation_ground?

Até onde entendi, landuse=events cobre áreas que ficam vagas alguns meses
ou semanas, e não se restrige a recreation_ground.
É comum circos ou parques usarem esse tipo de área, mas pode ser utilizado
por exposições ou alguns tipos de eventos.


Em 12 de março de 2014 16:13, Fernando Trebien
escreveu:

> Qual a diferença disso para landuse=recreation_ground?
>
> On Sun, Mar 9, 2014 at 7:31 PM, Nelson A. de Oliveira 
> wrote:
> > Para quem também tem dificuldade em representar áreas para eventos,
> > circos, festas e similares, é bom apoiar esta proposta:
> > http://wiki.openstreetmap.org/wiki/Proposed_features/leisure%3Devents
> > Está havendo uma discussão agora nessa thread
> > https://lists.openstreetmap.org/pipermail/tagging/2014-March/016768.html
> >
> > A sugestão inicial do meu irmão é landuse=events (que eu também
> > concordo que deva ser)
> > Ver também
> http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/leisure%3Devents
> >
> > ___
> > Talk-br mailing list
> > Talk-br@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-br
>
>
>
> --
> Fernando Trebien
> +55 (51) 9962-5409
>
> "The speed of computer chips doubles every 18 months." (Moore's law)
> "The speed of software halves every 18 months." (Gates' law)
>
> ___
> 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] São Paulo capital, tag reg

[John Packer]

Putz, isso deve ser um erro induzido pelo iD, que tem a tradução
"Referência" para a etiqueta 'ref'ao invés de "Número de referência".

Tinha anotado isso esses dias pra falar quando tivesse tempo, mas já
aproveitei essa oportunidade para comentar
Em 13/03/2014 23:18, "Erick de Oliveira Leal" 
escreveu:

> Opa pessoal, em São Paulo capital, encontrei a tag ref preenchida com
> Radial Leste entre outros, devo deixar? Ela está presente também em
> alt_name, talvez seja redundante.
>
> Abaixo alguns casos:
>
> http://www.openstreetmap.org/browse/way/14048300/history
> http://www.openstreetmap.org/browse/way/95488319/history
> http://www.openstreetmap.org/browse/way/129766403/history
> http://www.openstreetmap.org/browse/way/16973487/history
> http://www.openstreetmap.org/browse/way/136245229/history
>
> E também vias com nomes genéricos, devo deixar?
>
> http://www.openstreetmap.org/browse/way/226165434/history
> http://www.openstreetmap.org/browse/way/233692911/history
> http://www.openstreetmap.org/browse/way/128519868/history
> http://www.openstreetmap.org/browse/way/128519868/history
>
>
> ___
> 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] São Paulo capital, tag reg

[John Packer]

ref é uma etiqueta genérica para "Código de referência" (corrijo o que
disse antes, não é número, é código).

Assim como para a etiqueta name, tem outras etiquetas
relacionadaspara usos
similares, como
loc_ref, old_ref, ref:* e outros.

A etiqueta ref pode ser utilizada para coisas como números de saída de uma
rodovia(junto com motorway_junction=*) e código de identificação de pontos
de ônibus.
Não é algo tão comum assim de usar.

Abs,
João


Em 14 de março de 2014 09:12, Marcelo Pereira escreveu:

> Taí uma tag que eu nunca entendi como preencher, "REF"
>
> Sempre que rodo o validador do JOSM, aparecem críticas relacionadas.
>
> E é tanta coisa colocada lá que fica dificil saber o que é mesmo para
> ficar.
>
> Marcelo
>
>
> 2014-03-13 23:53 GMT-03:00 Nelson A. de Oliveira :
>
> On Thu, Mar 13, 2014 at 11:47 PM, Erick de Oliveira Leal
>>  wrote:
>> > http://www.openstreetmap.org/way/38709823
>> > http://www.openstreetmap.org/way/237689576
>>
>> Parece o CEP
>>
>> > http://www.openstreetmap.org/way/16973487
>> > http://www.openstreetmap.org/way/37396062
>> > http://www.openstreetmap.org/way/154255950
>>
>> Inicial de quem inseriu (pedro vida torta - PVT). Pode apagar (é
>> considerado graffiti)
>> Aproveita e manda mensagem para a pessoa parar com isso.
>>
>> ___
>> Talk-br mailing list
>> Talk-br@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-br
>>
>
>
>
> --
>
> ... Edileuz, eu não tem nada a ver com Creuza,
>É mentira da Ivete, não é meu esse caniveete...
> "Halley, Luiz" - Poeta, Cantor, Compsitor
>
> ___
> 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] São Paulo capital, tag reg

[John Packer]

Alterei a tradução de *"Reference"* no editor
iDpara
"Código de referência".


Em 14 de março de 2014 09:23, Nelson A. de Oliveira escreveu:

> 2014-03-14 9:12 GMT-03:00 Marcelo Pereira :
> > Taí uma tag que eu nunca entendi como preencher, "REF"
>
> De forma bem resumida, no Brasil ref vai ser comumente utilizada nas
> saídas de rodovias (quando na placa tem "Saída 430A" você vai colocar
> "430A" na ref) e nas rodovias (por exemplo, "SP-300" ou "BR-101").
>
> ___
> 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] Dúvidas em Natal

[John Packer]

O ideal é verificar localmente. Se você não é um local e está em dúvida,
pode colocar uma *Nota * lá.


Em 14 de março de 2014 16:35, Erick de Oliveira Leal <
erickdeoliveiral...@gmail.com> escreveu:

> Esta via: http://www.openstreetmap.org/way/42433318
> Está em sentido único, mas nas imagens de satélite parece ser de mão dupla.
>
> Aqui, essas duas estão no mesmo sentido, sendo que nas imagens deviam
> estar em sentidos diferentes:
> http://www.openstreetmap.org/way/205363394
>  http://www.openstreetmap.org/way/205363395
>
> Alguém sabe se está correto?
>
> ___
> 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] Pedidos de geração de mapas

[John Packer]

Show!
Consegui adicionar facilmente como camada TMS no JOSM.
Está com um certo deslocamento aqui em Joinville, mas utilizei da
ferramenta de deslocamente nativo do JOSM, e coloquei o seguinte valor
-33.94; -41.82
Daí ficou certinho.

E o servidor me pareceu bem rápido :-)


Em 17 de março de 2014 22:53, Thiago Marcos P. Santos
escreveu:

> Olá pessoal,
>
> Gerei os mapas da seguintes cidades abaixo, conforme solicitado. Se
> faltou alguma, favor avisar.
>
> 2305803 - Ipu - CE
> 2305001 - Guaraciaba do Norte - CE
> 2500601 - Alhandra - PB
> 2905404 - Cairu - BA
> 3164472 - Sao Sebastiao do Anta - MG
> 4203303 - Campo Alegre - SC
> 4209102 - Joinville - SC
>
> Estas duas eu gerei para testar o script com cidades maiores (IIRC
> alguém comentou sobre Belém faltar nomes de ruas aqui na lista):
>
> 1501402 - Belem - PA
> 5103403 - Cuiaba - MT
>
> Os mapas estao disponíveis via web aqui:
> http://tiles.tmpsantos.com.br/
>
> E para adionar no JOSM como layer TMS:
> http://tiles.tmpsantos.com.br/v2/[CODIGO]/{zoom}/{x}/{y}.png
>
> Exemplo (Belém):
> http://tiles.tmpsantos.com.br/v2/1501402/{zoom}/{x}/{y}.png
>
> Infelizmente estou tendo problemas com cidades do estado de SP. O
> formato dos PDFs lá parace ser diferente do resto do estados que
> testei até então. Estou tentado arrumar.
>
> []'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] Mudança na URL da layer TMS do IBGE

[John Packer]

Pedido: Quando puder, por favor adicione Jaraguá do
Sul(código
4208906, estado SC).


Em 20 de março de 2014 12:33, Erick de Oliveira Leal <
erickdeoliveiral...@gmail.com> escreveu:

> Thiago, parabéns e obrigado. Fiz o desenho de São Sebastião do Anta e
> nomeei com facilidade as ruas graças a seu trabalho:
> http://www.openstreetmap.org/changeset/21211786
>
>
> Em 19 de março de 2014 21:12, Thiago Marcos P. Santos  > escreveu:
>
> 2014-03-19 3:30 GMT+02:00 Fernando Trebien :
>> > Você tem o link pras imagens originais? Às vezes elas se sobrepõem e
>> > pode ter alguma informação na imagem original que acabou oculta.
>>
>> Sim e não. Dá para gerar com o script, mas eu apago depois que gero o
>> .mbtilespara economizar espaço em disco. :)
>>
>> Mas não há informação oculta. Pelo que notei, a engine do IBGE não é
>> sofisticada como a do OSM que renderiza coisas diferentes dependendo
>> do zoom level. Eu cheguei a testar como o Aun sugeriu, colocando o
>> "branco" como cor transparente e ficou muito ruim, cheio de riscos,
>> porque as vezes o overlap é de 80% da imagem e elas não se encaixam
>> perfeitamente porque as coordenadas estão arrendondadas.
>>
>> O fato é que 50% das imagens quando processo uma cidade estão
>> completamente sobrepostas. O script tem um "occlusion culling" (bem
>> tosco) implementado para descartar estas imagens e deixar o
>> processamento mais rápido. Rode com -v que ele te fala no final
>> quantas foram filtradas. Se você rodar com --kml por exemplo, nem
>> todas as imagens vão para o .kml e fica bem mais rápido de usar no
>> JOSM + PicLayer.
>>
>> > (Talvez tenha como amenizar esse problema se tiver como combinar as
>> > imagens fazendo uma média das cores ou escolhendo a mais escura nas
>> > partes em que as imagens se sobrepõem.)
>>
>> Eu acho válido experimentar e tentar melhorar a qualidade dos mapas.
>> Do jeito como está sendo feito, podemos substituir qualquer cidade com
>> um rendering novo/melhor a qualquer momento, sem interferir no resto.
>>
>> ___
>> 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 mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Mudança na URL da layer TMS do IBGE

[John Packer]

Isso, pode usar este mapa para nomear ruas, desde que inclua "ibge" como
fonte (isto é, na etiqueta *source* do seu conjunto de alterações).

Para colocar os mapas do IBGE como uma camada de um editor, fala o seguinte:

Se está usando o editor iD, vá em "Configurações da imagem de fundo (Atalho
b)" -> "Customizado" e entre a url
http://tiles.tmpsantos.com.br/v2/ibge/{zoom}/{x}/{y}.png Agora é só ir até
uma região onde o mapa aparece e mapear. Se você clicar em "Corrigir
alinhamento", pode alinhar melhor o mapa do IBGE com os dados do OSM.

Se está usando o editor JOSM, vá em "Imagens" -> "Imagery Preferences" (vai
abrir uma janela), vai na aba com um ícone com "WMS TMS", clica no botão "+
TMS", entra a url http://tiles.tmpsantos.com.br/v2/ibge/{zoom}/{x}/{y}.png no
primeiro campo e o nome "IBGE" no último(4º) campo, e pressione aceitar e
depois aceitar de novo.
Agora se você ir em "Imagens" -> "IBGE", vai aparecer os mapas do IBGE como
uma camada. Depois de abrir a camada, vá em "Imagens" -> Deslocamento das
Imagens" -> "IBGE" OU "Imagens" -> "Novo Deslocamento" (dependendo de qual
aparecer), pra poder alinhar o mapa.




Em 20 de março de 2014 18:58, Blademir Andrade de Lima <
blademi...@hotmail.com> escreveu:

> Caraca, não estou por dentro de assuntos desse tipo, TMS, etc bicho
> grilo para mim.
> Posso usar esta para nomear ruas, usando como fonte IBGE?
>
> Abraços
> BladeTC
>
> > From: tmpsan...@gmail.com
> > Date: Thu, 20 Mar 2014 23:36:47 +0200
> > To: talk-br@openstreetmap.org
> > Subject: Re: [Talk-br] Mudança na URL da layer TMS do IBGE
>
> >
> > Pessoal, anuncio que MG está completo. Confesso que ficou legal
> > demais de ser ver no mapa web, tem coisa demais para trabalhar. :)
> >
> > Arrumei o problema de algumas cidades não aparecerem nos níveis de
> > zoom mais distantes (se isto ainda acontecer com você na visualização
> > web ou no JOSM, limpe o cache do seu browser e do JOSM). Havia também
> > um problema com conurbações faltarem tiles onde elas se encontram que
> > também foi resolvido.
> >
> > Agora vou processar os estados restantes em ordem alfabética,
> > começando portanto por AC, AL, etc...
> >
> > Claro que a prioridade ainda é processar cidades que alguém queira
> > trabalhar em cima. Podem me mandar uma lista de qualquer tamanho no
> > formato:
> >
> > UF;CODIGO
> >
> > Exemplo:
> >
> > SC;4204806
> > PR;4106902
> > DF;5300108
> > ...
> >
> > Não há mais restrição de tamanho de cidade, o script tá funcionando bem.
> :)
> >
> > []'s
> >
> > 2014-03-19 2:19 GMT+02:00 Thiago Marcos P. Santos :
> > > Olá,
> > >
> > > Agora os tiles de todas as cidades já processadas estão em um lugar só:
> > >
> > > http://tiles.tmpsantos.com.br/v2/ibge/{zoom}/{x}/{y}.png
> > >
> > > Bem mais conveniente já que não precisa ficar adicionando uma nova
> > > layer no JOSM para cada cidade. Porém, em zooms mais distantes, podem
> > > aparecer "buracos" entre cidades próximas (i.e. veja BH, Contagem e
> > > Betim). Quando eu terminar de processar todas as cidades, talvez eu
> > > consiga resolver isso fazendo um merge mais inteligente dos arquivos
> > > .mbtiles.
> > >
> > > Feedback é bem vindo.
> > >
> > > Br,
> >
> > ___
> > 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 mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Mapa multilíngue

[John Packer]

> A princípio, "name:pt" não faz distinção entre português brasileiro e o de
> Portugal. Quando forem diferentes, dá pra usar "name:pt-br". Inclusive, dá
> pra colocar os dois

Realmente, quando vi o mapa noutro dia, percebi que constava em um lugar
Gronelândia ao invés de Groenlândia. Eu ia corrigir, mas preferi dar uma
pesquisada antes, e descobri que é assim que se escreve em Portugal.
Me pergunto se coisas assim são resolvidas na nova ortografia da língua
portuguesa.



Em 20 de março de 2014 16:40, Fernando Trebien
escreveu:

> Acabei de descobrir: http://mlm.jochentopf.com/
>
> Infelizmente o site é um pouco lento, especialmente em zonas
> densamente mapeadas. O melhor é aproximar bastante.
>
> Pra ver nomes em português, é só colocar "pt" no campo ao lado da
> caixa de seleção de idioma. Alguns lugares na Europa já têm algumas
> traduções. Exemplo:
>
> http://mlm.jochentopf.com/?zoom=16&lat=52.51611&lon=13.3779&layers=B0T&lang=pt
>
> Aqui em Porto Alegre funcionou também nos poucos lugares que têm
> traduções (a maioria oficiais ou mencionadas em algum texto em
> inglês):
> http://mlm.jochentopf.com/?zoom=17&lat=-30.0309&lon=-51.2301&layers=B0T&lang=en
>
> A princípio, nada impede que se edite o mapa de outro país para
> adicionar traduções para o português, quando se conhece/se ouviu
> várias vezes a tradução.
>
> A princípio, "name:pt" não faz distinção entre português brasileiro e
> o de Portugal. Quando forem diferentes, dá pra usar "name:pt-br".
> Inclusive, dá pra colocar os dois.
>
> --
> Fernando Trebien
> +55 (51) 9962-5409
>
> "The speed of computer chips doubles every 18 months." (Moore's law)
> "The speed of software halves every 18 months." (Gates' law)
>
> ___
> 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] Problema de usabilidade do editor de endereços do iD

[John Packer]

Entendo os seus argumentos e concordo com grande parte.
Mas se é para recomendarmos addr:housename como "Complemento", devemos nos
assegurar de que este é um significado compatível com o da comunidade
internacional.

Como você mencionou, addr:housename contém vários números lá, mas eu
acredito que isto seja um erro induzido pelo editor iD.
Realmente seria desestimulante consertar isso quando as alternativas não
são suportadas pelas grandes aplicações.
Como isso é um problema que não afeta somente o Brasil, talvez devemos
continuar esta conversa na lista *tagging*.


Abs,
João


Em 10 de março de 2014 09:34, Fernando Trebien
escreveu:

> Desculpa a demora em responder.
>
> Eu concordaria com você se as tags addr:door, addr:unit e addr
> estivessem em uso amplo. Mas apesar da idade, não estão,
> principalmente porque ninguém se preocupou em colocá-las nos presets
> dos editores: nem Potlatch, nem iD, nem JOSM. E elas existem há uns 3
> anos.
>
> O iD meio que corre atrás do JOSM, com poucas "novidades". Ambos, na
> verdade, reagem à adoção das tags de acordo com as estatísticas do
> TagInfo. Mas a equipe do JOSM às vezes dá suporte "adiantado" a uma
> tag. Se você pensar bem sobre essa dinâmica, os editores meio que
> influenciam quais tags são as melhores. Não adotar uma tag nos
> editores é o mesmo que relegá-la ao abandono.
>
> E o Nominatim também não indexa essas tags:
> http://wiki.openstreetmap.org/wiki/Nominatim/Development_overview
>
> Ou seja: criar uma aplicação que suporta uma tag tem um peso enorme na
> aceitação e adoção dessa tag na comunidade. Não criar tal aplicação -
> especialmente depois de muito tempo transcorrido - representa um
> descompasso entre aquilo que foi proposto/aceito e aquilo que é
> necessário (aquilo que é visto como útil para os usuários, útil a
> ponto de justificar o esforço de criar e manter uma aplicação
> funcionando em larga escala).
>
> Eu tenho a impressão de que é exatamente isso que está acontecendo com
> essas tags addr:door e addr:unit. Eu sei que elas são úteis em todos
> os lugares (não só no Brasil), e sabemos que tem pelo menos 3 grandes
> comunidades (Alemanha, Rússia e Inglaterra) que têm muito mais
> colaboradores que a nossa (por enquanto, continuo torcendo :D). Então,
> por que não adotaram essas tags em larga escala?
>
> Uma possível explicação é o problema do ovo e da galinha: as
> aplicações geralmente só adotam algo que já é empregado, e a maioria
> das pessoas só emprega quando já é adotado por aplicações. Se ninguém
> toma a dianteira, nada novo é adotado. Mas tomar a dianteira é
> reconhecer a tag como tão útil que o esforço de adotá-la vale à pena.
>
> Outro aspecto a considerar é que no OSM há muitas coisas que são
> suportadas retroativamente. Talvez o melhor exemplo seja o de
> highway=bus_stop: já existe uma proposta com novas tags para mapear o
> transporte público (há 3 anos), mas mesmo as ferramentas que a
> suportam continuam suportando as tags antigas. Não há razão pra pensar
> que com addr:housename e addr:door e addr:unit seria diferente.
>
> Uma última coisa: a maioria dos valores em addr:housename são valores
> numéricos! Ou alfabéticos. Pra mim, isso sugere que estão usando como
> as outras duas tags (addr:unit e addr:door). E os que não são (tentei
> traduzir alguns) incluem coisas redundantes como "prefeitura"
> (Rathaus, Mairie), "edifício" em espanhol, casa de campo ("cottage"),
> alojamento ("lodge"), reitoria ("pfarrhaus"), e descrições genéricas
> como moradia ("жилой дом").
> http://taginfo.openstreetmap.org/keys/addr%3Ahousename#values
>
> Por que eu fico meio relutante em recomendar as tags addr:unit e
> addr:door: considerando todos esses fatores, eu acho que nunca serão
> adotadas em larga escala (se fossem, já teriam sido). E daí
> convertê-las para addr:housename seria um trabalho difícil/pior já que
> me parece mais provável que com housename o mapeador discriminaria o
> tipo de complemento (sala, conjunto, etc.) enquanto que com addr:door
> e addr:unit é mais provável que a pessoa só coloque o número e esteja
> satisfeita com isso.
>
> 2014-03-04 15:27 GMT-03:00 John Packer :
> > Bem, eu acho que o campo addr:housename não pode ser realmente
> considerado
> > como "Complemento", justamente devido à existência dos campos addr:door,
> > addr:unit e outros.
> >
> > Para mim, a tradução como "Complemento" era só uma solução temporária
> devido
> > ao estado do formulário de endereços do editor iD. Pois pelo menos não
> > colocariam o nome do lugar ou o nome da rua lá.
> >
> > Veja a descrição de addr:housename:
> >>
> >> The name of a hous

Re: [Talk-br] "That Shouldnt Be Possible" com dados do Brasil

[John Packer]

Muito bacana, estava esperando esta aplicação suportar o Brasil.

Pelo que entendi, ela só aceita trilhas GPS públicas que estão no OSM,
correto?
Já testei uma trilha minha, ela ficou tudo certinho (verde) haha


Em 24 de março de 2014 09:10, Paulo Carvalho
escreveu:

> Interessante.  Obrigado por compartilhar.
>
> []s
>
> Paulo
>
>
> Em 24 de março de 2014 08:45, Nelson A. de Oliveira 
> escreveu:
>
> Para quem conhece (ou ainda não conhece) o "That Shouldnt Be Possible"
>> - http://wiki.openstreetmap.org/wiki/That_Shouldnt_Be_Possible, ele
>> agora possui dados do Brasil.
>> É possível analisar tracks GPX e ver se é possível fazer o caminho com
>> os dados existentes no OSM (e inferir se está faltando ruas no OSM ou
>> se algum caminho está deslocado/errado, por exemplo)
>>
>> ___
>> 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 mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] "That Shouldnt Be Possible" com dados do Brasil

[John Packer]

Ah, mas mesmo o gráfico ficou bem bom, com um pico no ínicio e no final só:
http://ris.dev.openstreetmap.org/tsbp-proto/1647037/2/1/


Em 24 de março de 2014 09:44, Nelson A. de Oliveira escreveu:

> 2014-03-24 9:42 GMT-03:00 John Packer :
> > Pelo que entendi, ela só aceita trilhas GPS públicas que estão no OSM,
> > correto?
>
> Isso. Precisa enviar o track para o servidor do OSM (é até uma forma
> de estimular as pessoas a enviarem os seus tracks)
>
> > Já testei uma trilha minha, ela ficou tudo certinho (verde) haha
>
> Você tem que olhar o gráfico que ele gera também (que possui "picos"
> que indicam um possível desvio/deslocamento nas rotas).
>
> ___
> 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] "That Shouldnt Be Possible" com dados do Brasil

[John Packer]

Revisando a mesma trilha, agora apareceu o gráfico certinho.
Acho que antes não tinha carregado completamente (internet lenta onde
estou).
Aparentemente a trilha está certa, não entendi porquê está com um pico
aonde tem lá...


Em 24 de março de 2014 09:46, John Packer  escreveu:

> Ah, mas mesmo o gráfico ficou bem bom, com um pico no ínicio e no final só:
> http://ris.dev.openstreetmap.org/tsbp-proto/1647037/2/1/
>
>
> Em 24 de março de 2014 09:44, Nelson A. de Oliveira 
> escreveu:
>
> 2014-03-24 9:42 GMT-03:00 John Packer :
>> > Pelo que entendi, ela só aceita trilhas GPS públicas que estão no OSM,
>> > correto?
>>
>> Isso. Precisa enviar o track para o servidor do OSM (é até uma forma
>> de estimular as pessoas a enviarem os seus tracks)
>>
>> > Já testei uma trilha minha, ela ficou tudo certinho (verde) haha
>>
>> Você tem que olhar o gráfico que ele gera também (que possui "picos"
>> que indicam um possível desvio/deslocamento nas rotas).
>>
>> ___
>> 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] Lixo na base

[John Packer]

>
> Dá para utilizar regex no overpass para obter ruas que não iniciem com
> Rua|Avenida|etc

Esses dias eu corrigi via JOSM as ruas que não tinham nenhum prefixo na
minha cidade.
O filtro que eu utilizei era algo estilo: possui as etiquetas `highway` e
`name` e não pode começar com: Rua, Avenida, Servidão, Ponte, Estrada.
E talvez precise de Beco (mas não foi o caso na minha cidade).

Creio que seja seguro adicionar o prefixo "Rua " quando for verificado que
não tem nenhum prefixo em uma rua.



2014-03-24 13:06 GMT-03:00 Nelson A. de Oliveira :

> Dá para utilizar regex no overpass para obter ruas que não iniciem com
> Rua|Avenida|etc
>
> ___
> 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: Lixo na base

[John Packer]

A razão porquê eu assumi Rua como padrão aqui na minha cidade é porquê o
mapa da prefeitura, de onde foi pego vários nomes de Ruas, não colocava
"Rua" no nome quando era o caso.
Realmente não sei dizer se este seria o caso pra uma operação em larga
escala.


Em 24 de março de 2014 13:36, Reinaldo Neves escreveu:

> Desculpe mas não se deve colocar todos os logradouros sem tipo como Rua,
> existem mais de 300 tipos de logradouros catalogados no Correio, todos em
> uso e assumir um default para essa informação pode gerar um problema sem
> tamanho.
>
>
>
> Basta lembrar que em determinadas cidades é usual nomes de logradouros
> repetidos, muitas vezes com variação apenas no tipo do logradouro ( PSG,TV,
> R Santo Antonio por exemplo em São Luiz ), as diversas ocorrências de
> Antonio Carlos Magalhães na Bahia e por ai vai.
>
>
>
> Reinaldo
>
>
>
>
>
> *De:* John Packer [mailto:john.pack...@gmail.com]
> *Enviada em:* segunda-feira, 24 de março de 2014 13:23
> *Para:* OpenStreetMap no Brasil
> *Assunto:* Re: [Talk-br] Lixo na base
>
>
>
> Dá para utilizar regex no overpass para obter ruas que não iniciem com
> Rua|Avenida|etc
>
> [image: Imagem removida pelo remetente.]Esses dias eu corrigi via JOSM as
> ruas que não tinham nenhum prefixo na minha cidade.
>
> O filtro que eu utilizei era algo estilo: possui as etiquetas `highway` e
> `name` e não pode começar com: Rua, Avenida, Servidão, Ponte, Estrada.
>
> E talvez precise de Beco (mas não foi o caso na minha cidade).
>
> Creio que seja seguro adicionar o prefixo "Rua " quando for verificado que
> não tem nenhum prefixo em uma rua.
>
>
>
> 2014-03-24 13:06 GMT-03:00 Nelson A. de Oliveira :
>
> Dá para utilizar regex no overpass para obter ruas que não iniciem com
> Rua|Avenida|etc
>
>
> ___
> 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 mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] RES: Lixo na base

[John Packer]

Mas creio que esses 107 tipos não se aplicam somente à vias.

Vi outros para vias, como Alameda, Viela, Passarela, Viaduto, Trevo...


Em 24 de março de 2014 13:57, Fernando Trebien
escreveu:

> Eu já vi a lista completa em algum lugar (mas não consigo achar).
> Então vai uma citação: "Segundo o IBGE, existem 107 tipos de
> logradouros e 256 títulos."
> [
> http://scielo.iec.pa.gov.br/scielo.php?pid=S1679-4974200800016&script=sci_arttext
> ]
>
> Realmente, a criatividade para o nome dessas coisas é quase infindável. :P
>
> 2014-03-24 13:45 GMT-03:00 Nelson A. de Oliveira :
> > 2014-03-24 13:36 GMT-03:00 Reinaldo Neves :
> >>
> >> Desculpe mas não se deve colocar todos os logradouros sem tipo como
> Rua,  existem mais de 300 tipos de logradouros catalogados no Correio,
> todos em uso e assumir um default para essa informação pode gerar um
> problema sem tamanho.
> >
> > 300 tipos? Isso ignorando as abreviações?
> >
> > ___
> > Talk-br mailing list
> > Talk-br@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-br
>
>
>
> --
> Fernando Trebien
> +55 (51) 9962-5409
>
> "The speed of computer chips doubles every 18 months." (Moore's law)
> "The speed of software halves every 18 months." (Gates' law)
>
> ___
> 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] Lixo na base

[John Packer]

Se puderem, mandem os links dos conjuntos de alteração que estão fazendo.
Não acho que vá precisar de alguma correção, é só pra os outros estarem
cientes das mudanças que estão sendo feitas.


Em 25 de março de 2014 13:22, Erick de Oliveira Leal <
erickdeoliveiral...@gmail.com> escreveu:

> Eu retirei o acento circunflexo para que ele ache o ? em qualquer lugar...
> Ainda restam alguns nomes... Deletando agora...
>
>
> Em 25 de março de 2014 12:11, Roger C. Soares escreveu:
>
>  A pedido, a query que eu usei no overpass-turbo foi:
>>
>> 
>> 
>>   
>>   
>>   
>>   
>> 
>>
>>   
>>   
>>   
>> 
>>
>> Na Argentina por enquanto ainda retorna alguns casos.
>>
>> Atenciosamente,
>> Roger.
>>
>> --
>> Em 25-03-2014 01:30, Erick de Oliveira Leal escreveu:
>>
>> Opa que bom então. Valeu Nelson e Roger
>> Em 25/03/2014 00:32, "Roger C. Soares"  escreveu:
>>
>>>  O overpass-turbo que o Nelson mandou realmente é muito bom. A busca
>>> por highway+name com ? no Brasil todo foi bem mais rápida do que eu
>>> esperava. Tinham poucos casos então já removi.
>>>
>>> Atenciosamente,
>>> Roger.
>>>
>>> --
>>> Em 24-03-2014 15:43, Fernando Trebien escreveu:
>>>
>>>  2014-03-24 15:33 GMT-03:00 Erick de Oliveira Leal <
>>> erickdeoliveiral...@gmail.com>:
>>>
>>>> Erros onde o nome só contém caracteres do tipo ? eu tenho certeza q
>>>> sim... rsrsrs.
>>>>
>>>
>>>  Heh, ok, este caso em particular poderia ser considerado um erro. Mas
>>> daí não vale à pena o esforço de fazer um validador para um caso que
>>> acontece só umas poucas vezes né. Melhor fazer um script que liste os IDs
>>> objetos e depois nos permita editá-los manualmente, como você disse.
>>> (Precisamos de scripts assim pra muitas outras coisas parecidas.)
>>>
>>>
>>>>  Mas ainda seria mais interessante um script que nos desse os ids dos
>>>> objetos com erros e fizessemos uma força tarefa para corrigi-los. Mas acho
>>>> que os erros do tipo sem logradouro são muitos, então esses teriam que ser
>>>> postergados. Agora só corrigiriamos esses casos estranhos mesmo. Mas tem
>>>> algum jeito de encontrar isso fácil?
>>>>
>>>>
>>>> Em 24 de março de 2014 15:22, Fernando Trebien <
>>>> fernando.treb...@gmail.com> escreveu:
>>>>
>>>>  Erros são matemáticos. Você tem certeza absoluta de que todos esses
>>>>> casos, sem exceção, presente ou futura, constituem erros?
>>>>>  On Mar 24, 2014 2:29 PM,  wrote:
>>>>>
>>>>>>   Os erros existentes são fatos e requerem correção.
>>>>>> Na minha opinião correção automática até porque são tantos que uma
>>>>>> correção manual, com poucos colaboradores, exigiria muito esforço e 
>>>>>> tempo.
>>>>>> Corrigiríamos os existentes, mas como evitar que novos surjam?
>>>>>> Continuo defendendo a função VALIDADOR (como erro e não aviso) quando
>>>>>> da edição. Pelo menos por meio dele novos erros desse tipo não devem 
>>>>>> voltar
>>>>>> a ocorrer.
>>>>>> []s
>>>>>> Marcio
>>>>>>
>>>>>>
>>>>>>  *From:* Fernando Trebien 
>>>>>> *Sent:* Monday, March 24, 2014 1:52 PM
>>>>>> *To:* OpenStreetMap no Brasil 
>>>>>> *Subject:* Re: [Talk-br] Lixo na base
>>>>>>
>>>>>>  Mas vocês querem fazer isso para todo o Brasil de forma automática
>>>>>> ou deixar para cada um na sua cidade fazer? Nem 1% das cidades 
>>>>>> brasileiras
>>>>>> tem representantes aqui na lista.
>>>>>>
>>>>>>
>>>>>> 2014-03-24 13:23 GMT-03:00 John Packer :
>>>>>>
>>>>>>>  Dá para utilizar regex no overpass para obter ruas que não iniciem
>>>>>>>> com
>>>>>>>> Rua|Avenida|etc
>>>>>>>
>>>>>>>  Esses dias eu corrigi via JOSM as ruas que não tinham nenhum
>>>>>>> prefixo na minha cidade.
>>>>>>>  O filtro que eu utilizei era algo estilo: possui as etiquetas
>>>>>>> `highway` e `name` e não pode começar com: Rua, Avenida, Servidão, 
>&

Re: [Talk-br] Lixo na base

[John Packer]

Putz, daí complica a revisão...
Não quero ser chato, mas o ideal é sempre ter revisores nessas mudanças
remotas.

Achei que você estava procurando via Overpass API e fazendo correções e
upload via JOSM.
O JOSM inclusive permite enviar mudanças para um conjunto de alterações que
você deixa explicitamente como aberto.

No que eu vi, achei uma mudança suspeita:
http://osm.mapki.com/history/way.php?id=239318576
É uma avenida que tem a sua etiqueta "oneway" mudada de "no" para "yes".
Foi um acidente isso? Ou com que base você mudou isso?
O resto das alterações que eu vi estavam Ok, e caramba, como tem nomes com
vírgula no final hahahaha



Em 25 de março de 2014 15:17, Erick de Oliveira Leal <
erickdeoliveiral...@gmail.com> escreveu:

> Ótimo!
>
>
> Em 25 de março de 2014 15:12, Arlindo Pereira <
> openstreet...@arlindopereira.com> escreveu:
>
> O separador oficial é o ponto e vírgula.
>>
>> []s
>>
>>
>> 2014-03-25 15:10 GMT-03:00 Erick de Oliveira Leal <
>> erickdeoliveiral...@gmail.com>:
>>
>> Tranquilo...
>>>
>>> Talvez fosse o caso estipular um separador oficial, né?
>>>
>>>
>>> Em 25 de março de 2014 15:08, Nelson A. de Oliveira 
>>> escreveu:
>>>
>>> 2014-03-25 15:04 GMT-03:00 Erick de Oliveira Leal
 :
 > Em todas posições. Mas estou verificando caso a caso. Só passei o da
 virgula. Ponto virgula ainda apagarei.

 Cuidado com alguns usos de ponto e vírgula (que é utilizado para
 separação de valores).
 Acontece muito das pessoas unirem dois caminhos com nomes distintos e
 criar um novo com os dois nomes, separados por ponto e vírgula.
 Nesses casos tem que analisar se não aconteceu isso (e ver qual o nome
 real do trecho).

 ___
 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 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 mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Lixo na base

[John Packer]

Ei Erick, para facilitar a revisão faça uso do JOSM para corrigir esses
nomes.

Usando o Overpass, você pode baixar a lista de resultados para um arquivo,
corrigir no JOSM, e fazer upload (creio que assim seja até mais fácil).
Outra forma seria deixar o JOSM aberto, permitindo abrir ele remotamente,
daí ir mandando as correções do JOSM em um conjunto de alterações que você
deixou como aberto (onde as mudanças vão sendo adicionadas lá, ao invés de
em conjunto de alterações novos).


Em 25 de março de 2014 15:54, Erick de Oliveira Leal <
erickdeoliveiral...@gmail.com> escreveu:

> Para encontrar mais de um espaço no nome da via:
>
> 
> 
>   
>   
>   
>   
> 
>
>   
>   
>   
> 
>
>
> Em 25 de março de 2014 15:49, Erick de Oliveira Leal <
> erickdeoliveiral...@gmail.com> escreveu:
>
> Não foi acidente. Foi com base nas conexões que vi. Agora estou corrigindo
>> vias com mais de um espaço. Este caso de mais de um espaço poderia ser
>> automatizado pra varrer todas tags do Brasil. Mas existem outros casos
>> também. Tomara que uma hora o Trebien desocupe das atuais tarefas pra fazer
>> esse script pra gente.
>>
>>
>> Em 25 de março de 2014 15:45, John Packer escreveu:
>>
>> Putz, daí complica a revisão...
>>> Não quero ser chato, mas o ideal é sempre ter revisores nessas mudanças
>>> remotas.
>>>
>>> Achei que você estava procurando via Overpass API e fazendo correções e
>>> upload via JOSM.
>>> O JOSM inclusive permite enviar mudanças para um conjunto de alterações
>>> que você deixa explicitamente como aberto.
>>>
>>> No que eu vi, achei uma mudança suspeita:
>>> http://osm.mapki.com/history/way.php?id=239318576
>>> É uma avenida que tem a sua etiqueta "oneway" mudada de "no" para "yes".
>>> Foi um acidente isso? Ou com que base você mudou isso?
>>> O resto das alterações que eu vi estavam Ok, e caramba, como tem nomes
>>> com vírgula no final hahahaha
>>>
>>>
>>>
>>> Em 25 de março de 2014 15:17, Erick de Oliveira Leal <
>>> erickdeoliveiral...@gmail.com> escreveu:
>>>
>>> Ótimo!
>>>>
>>>>
>>>> Em 25 de março de 2014 15:12, Arlindo Pereira <
>>>> openstreet...@arlindopereira.com> escreveu:
>>>>
>>>> O separador oficial é o ponto e vírgula.
>>>>>
>>>>> []s
>>>>>
>>>>>
>>>>> 2014-03-25 15:10 GMT-03:00 Erick de Oliveira Leal <
>>>>> erickdeoliveiral...@gmail.com>:
>>>>>
>>>>> Tranquilo...
>>>>>>
>>>>>> Talvez fosse o caso estipular um separador oficial, né?
>>>>>>
>>>>>>
>>>>>> Em 25 de março de 2014 15:08, Nelson A. de Oliveira >>>>> > escreveu:
>>>>>>
>>>>>> 2014-03-25 15:04 GMT-03:00 Erick de Oliveira Leal
>>>>>>> :
>>>>>>> > Em todas posições. Mas estou verificando caso a caso. Só passei o
>>>>>>> da virgula. Ponto virgula ainda apagarei.
>>>>>>>
>>>>>>> Cuidado com alguns usos de ponto e vírgula (que é utilizado para
>>>>>>> separação de valores).
>>>>>>> Acontece muito das pessoas unirem dois caminhos com nomes distintos e
>>>>>>> criar um novo com os dois nomes, separados por ponto e vírgula.
>>>>>>> Nesses casos tem que analisar se não aconteceu isso (e ver qual o
>>>>>>> nome
>>>>>>> real do trecho).
>>>>>>>
>>>>>>> ___
>>>>>>> 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 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 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 mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Lixo na base

[John Packer]

Coloca *|]* no final ao invés de dentro dos colchetes

[_´`:,|!@#%¨¹²³£¢§¬\^\?\=\*\$\+\[\}\{\~><&\\]|]


É o seguinte, um monte de caracteres entre colchetes quer dizer: qualquer
caractere dentro deste intervalo (que são os caracteres)
o *|]* quer dizer: OU o caractere fecha-colchete




Em 25 de março de 2014 21:39, Erick de Oliveira Leal <
erickdeoliveiral...@gmail.com> escreveu:

> Alguém sabe como escapar o caracter ] ?
>
> Aqui: 
> 
>   
>   
> regv="[_´`:,|!@#%¨¹²³£¢§¬\^\?\=\*\$\+\]\[\}\{\~><&\\]"/>
>   
> 
>   
>   
>   
> 
>
> Se retirar o \] ele encontra os objetos, senão ele retorna nulo.
>
>
> Em 25 de março de 2014 18:44, Erick de Oliveira Leal <
> erickdeoliveiral...@gmail.com> escreveu:
>
> O que fiz nos nomes de vias...
>>
>> Caracteres em todas posições: [ ] { } ´ ` ~ :  ? > < , | \ = + * ! @ # $
>> % ¨ ¹²³£¢§¬
>>
>> Começo e fim em: espaço / -
>>
>> Começo em: ponto final
>>
>> E também espaços duplos
>>
>> Mas sempre fica algo de fora...
>>
>> Não consegui fazer do &
>>
>>
>>
>>
>>
>>
>> Em 25 de março de 2014 17:01, Roger C. Soares 
>> escreveu:
>>
>>  Os meus foram:
>>>
>>> http://www.openstreetmap.org/changeset/21305113
>>> http://www.openstreetmap.org/changeset/21304467
>>> http://www.openstreetmap.org/changeset/21303588
>>> http://www.openstreetmap.org/changeset/21297490
>>> http://www.openstreetmap.org/changeset/21297472
>>> http://www.openstreetmap.org/changeset/21297420
>>> http://www.openstreetmap.org/changeset/21297200
>>>
>>> Atenciosamente,
>>> Roger.
>>>
>>> --
>>> Em 25-03-2014 13:27, John Packer escreveu:
>>>
>>>  Se puderem, mandem os links dos conjuntos de alteração que estão
>>> fazendo.
>>>  Não acho que vá precisar de alguma correção, é só pra os outros
>>> estarem cientes das mudanças que estão sendo feitas.
>>>
>>>
>>> Em 25 de março de 2014 13:22, Erick de Oliveira Leal <
>>> erickdeoliveiral...@gmail.com> escreveu:
>>>
>>>> Eu retirei o acento circunflexo para que ele ache o ? em qualquer
>>>> lugar... Ainda restam alguns nomes... Deletando agora...
>>>>
>>>>
>>>> Em 25 de março de 2014 12:11, Roger C. Soares 
>>>> escreveu:
>>>>
>>>>  A pedido, a query que eu usei no overpass-turbo foi:
>>>>>
>>>>> 
>>>>> 
>>>>>   
>>>>>   
>>>>>   
>>>>>   
>>>>> 
>>>>>
>>>>>   
>>>>>   
>>>>>   
>>>>> 
>>>>>
>>>>>  Na Argentina por enquanto ainda retorna alguns casos.
>>>>>
>>>>> Atenciosamente,
>>>>> Roger.
>>>>>
>>>>> --
>>>>> Em 25-03-2014 01 <25-03-2014%2001>:30, Erick de Oliveira Leal
>>>>> escreveu:
>>>>>
>>>>> Opa que bom então. Valeu Nelson e Roger
>>>>> Em 25/03/2014 00:32, "Roger C. Soares" 
>>>>> escreveu:
>>>>>
>>>>>>  O overpass-turbo que o Nelson mandou realmente é muito bom. A busca
>>>>>> por highway+name com ? no Brasil todo foi bem mais rápida do que eu
>>>>>> esperava. Tinham poucos casos então já removi.
>>>>>>
>>>>>> Atenciosamente,
>>>>>> Roger.
>>>>>>
>>>>>> --
>>>>>> Em 24-03-2014 15:43, Fernando Trebien escreveu:
>>>>>>
>>>>>>  2014-03-24 15:33 GMT-03:00 Erick de Oliveira Leal <
>>>>>> erickdeoliveiral...@gmail.com>:
>>>>>>
>>>>>>> Erros onde o nome só contém caracteres do tipo ? eu tenho certeza q
>>>>>>> sim... rsrsrs.
>>>>>>>
>>>>>>
>>>>>>  Heh, ok, este caso em particular poderia ser considerado um erro.
>>>>>> Mas daí não vale à pena o esforço de fazer um validador para um caso que
>>>>>> acontece só umas poucas vezes né. Melhor fazer um script que liste os IDs
>>>>>> objetos e depois nos permita editá-los manualmente, como você disse.
>>>>>> (Precisamos de scripts assim pra muitas outras coisas parecidas.)
&g

Re: [Talk-br] Lixo na base

[John Packer]

Pessoal, acabei de testar aqui, então para referência futura:
Para modificar resultados de uma consulta no Overpass usando o JOSM, tem
que:
- ter o JOSM aberto, e com a preferência de controle
remoto<http://josm.openstreetmap.de/wiki/Help/Preferences/RemoteControl>habilitada.
- pedir para o resultado vir em XML (  )
- ir em "Export" -> load into JOSM


Em 25 de março de 2014 21:57, Erick de Oliveira Leal <
erickdeoliveiral...@gmail.com> escreveu:

> Eu já tinha enviado um erro no github... vou testar mais tarde sua solução.
>
>
> Em 25 de março de 2014 21:53, John Packer escreveu:
>
> Coloca *|]* no final ao invés de dentro dos colchetes
>>
>> [_´`:,|!@#%¨¹²³£¢§¬\^\?\=\*\$\+\[\}\{\~><&\\]|]
>>
>>
>> É o seguinte, um monte de caracteres entre colchetes quer dizer: qualquer
>> caractere dentro deste intervalo (que são os caracteres)
>> o *|]* quer dizer: OU o caractere fecha-colchete
>>
>>
>>
>>
>> Em 25 de março de 2014 21:39, Erick de Oliveira Leal <
>> erickdeoliveiral...@gmail.com> escreveu:
>>
>> Alguém sabe como escapar o caracter ] ?
>>>
>>> Aqui: 
>>> 
>>>   
>>>   
>>>   >>  regv="[_´`:,|!@#%¨¹²³£¢§¬\^\?\=\*\$\+\]\[\}\{\~><&\\]"/>
>>>   
>>> 
>>>   
>>>   
>>>   
>>> 
>>>
>>> Se retirar o \] ele encontra os objetos, senão ele retorna nulo.
>>>
>>>
>>> Em 25 de março de 2014 18:44, Erick de Oliveira Leal <
>>> erickdeoliveiral...@gmail.com> escreveu:
>>>
>>> O que fiz nos nomes de vias...
>>>>
>>>> Caracteres em todas posições: [ ] { } ´ ` ~ :  ? > < , | \ = + * ! @ #
>>>> $ % ¨ ¹²³£¢§¬
>>>>
>>>> Começo e fim em: espaço / -
>>>>
>>>> Começo em: ponto final
>>>>
>>>> E também espaços duplos
>>>>
>>>> Mas sempre fica algo de fora...
>>>>
>>>> Não consegui fazer do &
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Em 25 de março de 2014 17:01, Roger C. Soares 
>>>> escreveu:
>>>>
>>>>  Os meus foram:
>>>>>
>>>>> http://www.openstreetmap.org/changeset/21305113
>>>>> http://www.openstreetmap.org/changeset/21304467
>>>>> http://www.openstreetmap.org/changeset/21303588
>>>>> http://www.openstreetmap.org/changeset/21297490
>>>>> http://www.openstreetmap.org/changeset/21297472
>>>>> http://www.openstreetmap.org/changeset/21297420
>>>>> http://www.openstreetmap.org/changeset/21297200
>>>>>
>>>>> Atenciosamente,
>>>>> Roger.
>>>>>
>>>>> --
>>>>> Em 25-03-2014 13:27, John Packer escreveu:
>>>>>
>>>>>  Se puderem, mandem os links dos conjuntos de alteração que estão
>>>>> fazendo.
>>>>>  Não acho que vá precisar de alguma correção, é só pra os outros
>>>>> estarem cientes das mudanças que estão sendo feitas.
>>>>>
>>>>>
>>>>> Em 25 de março de 2014 13:22, Erick de Oliveira Leal <
>>>>> erickdeoliveiral...@gmail.com> escreveu:
>>>>>
>>>>>> Eu retirei o acento circunflexo para que ele ache o ? em qualquer
>>>>>> lugar... Ainda restam alguns nomes... Deletando agora...
>>>>>>
>>>>>>
>>>>>> Em 25 de março de 2014 12:11, Roger C. Soares 
>>>>>> escreveu:
>>>>>>
>>>>>>  A pedido, a query que eu usei no overpass-turbo foi:
>>>>>>>
>>>>>>> 
>>>>>>> 
>>>>>>>   
>>>>>>>   
>>>>>>>   
>>>>>>>   
>>>>>>> 
>>>>>>>
>>>>>>>   
>>>>>>>   
>>>>>>>   
>>>>>>> 
>>>>>>>
>>>>>>>  Na Argentina por enquanto ainda retorna alguns casos.
>>>>>>>
>>>>>>> Atenciosamente,
>>>>>>> Roger.
>>>>>>>
>>>>>>> --
>>>>>>> Em 25-03-2014 01 <25-03-2014%2001>:30, Erick de Oliveira Leal
>>>>>>> escreveu:
>>>>

Re: [Talk-br] Caminhos como "via" em restrições

[John Packer]

Sou só eu que penso que o caso de restrição por via pode ser feito como
deveria ser feito, mesmo que tenha a falta de suporte pelas aplicações? (ao
invés de fazer algo que necessite de correção manual no futuro)


Em 26 de março de 2014 20:02, Paulo Carvalho
escreveu:

> Na indústria do petróleo conheço dois provérbios, para pensar, caso não
> conheças:
> "O ótimo é inimigo do bom".
> "É preferível estar vagamente correto do que precisamente errado".
>
>
> Em 26 de março de 2014 19:39, Fernando Trebien  > escreveu:
>
>> Mas você concorda que isso é algo que os desenvolvedores das
>>
>> aplicações têm que fazer, e não os mapeadores - que já fazem a sua
>> parte decidindo quais tags usar e educando as pessoas para usá-las
>> corretamente?
>>
>> E não são nem os desenvolvedors do OSM em si (que é só uma base de
>> dados) e sim os desenvolvedores do mkgmap, do OSRM, etc. que são
>> projetos independentes, e com os quais qualquer um, incluindo você e
>> eu, podemos ajudar.
>>
>> 2014-03-26 19:34 GMT-03:00 Paulo Carvalho :
>> > Eu também acho que os aspectos práticos do uso dos mapas não pode ser
>> > simplesmente ignorado.
>> >
>> >
>> > Em 26 de março de 2014 18:25,  escreveu:
>> >>
>> >> Raffaello,
>> >> quando questionado nos fóruns sobre o melhor mapa respondo que o melhor
>> >> mapa é aquele que contém menos erros na região em que se mais trafega.
>> >>
>> >> Não existe mapa sem erros, existe mapa com menos erros e para correção
>> >> desses o provedor do mapa depende de colaborações.
>> >> Sem utilizadores devido a limitações poucas colaborações surgirão.
>> >>
>> >> Em que pese que um mapa digitalizado serve para inúmeras utilidades não
>> >> podemos e não devemos deixar de prioriza-las em nosso esforço.
>> >>
>> >> Desconsiderando a navegação visual por contato, não consigo, por
>> enquanto,
>> >> avaliar utilidade que não empregue a navegação assistida (GNSS e outros
>> >> sistemas de georreferenciamento). Por essa razão priorizo, por
>> enquanto, o
>> >> esforço em edição do mapa OSM para fins de navegação pelo GNSS.
>> >>
>> >> Visando o nivelamento do conhecimento, aproveito a oportunidade para
>> >> comentar que no Garmin existem duas funções suporte: Lane Assistante
>> (LA) e
>> >> Junction View (JCV).
>> >>
>> >> A função  JCV, comentada incorretamente aqui na lista como LA, pode ser
>> >> vista no vídeo em http://www.youtube.com/watch?v=HElDa-D7tT8
>> >> Essa função depende de arquivo extra e não é inserida no mapa.
>> >>
>> >> A função Lane Assistante (defendida por mim) pode ser vista em
>> >> http://www.youtube.com/watch?v=eT3nyBjsuJ8
>> >> Essa função depende de TAG inserida no mapa, entretanto desconheço se o
>> >> MKGMAP reconhece essa TAG.
>> >>
>> >> []s
>> >> Marcio
>> >>
>> >>
>> >> From: Raffaello Bruno Limongi Freire
>> >> Sent: Wednesday, March 26, 2014 5:23 PM
>> >> To: OpenStreetMap no Brasil
>> >> Subject: Re: [Talk-br] Caminhos como "via" em restrições
>> >>
>> >> Márcio,
>> >>
>> >> é por essas limitações que, apesar de eu já estar contribuindo mais
>> com o
>> >> OSM do que com o Tracksource, não pretendo deixar de usar o TRC nem tão
>> >> cedo, porque a minha prioridade é o roteamento.
>> >>
>> >> Raffaello Bruno
>> >>
>> >> > From: thunder...@gpsinfo.com.br
>> >> > To: talk-br@openstreetmap.org
>> >> > Date: Wed, 26 Mar 2014 13:43:23 -0300
>> >> > Subject: Re: [Talk-br] Caminhos como "via" em restrições
>> >> >
>> >> > Nelson,
>> >> > esse seu ultimo parágrafo nos leva muito a refletir sobre custo x
>> >> > benefício
>> >> > de se contornar alguma limitação atual.
>> >> >
>> >> > Tem uma frase (não sei a autoria) que bem diferencia eficiência de
>> >> > eficácia:
>> >> > "um piloto faz excelentes pousos (eficiente), mas no aeródromo
>> errado"
>> >> > (ineficaz).
>> >> >
>> >> > Me agreguei ao OSM não faz muito tempo e confesso que a cada dia
>> mais me
>> >> > simpatizo com os objetivos dele.
>> >> >
>> >> > Administrando sites de GPS há vários anos já havia lido alguns
>> >> > comentários
>> >> > sobre o OSM, mas muito vagos e inconsistentes. Confesso que nunca
>> havia
>> >> > sido
>> >> > motivado a me aprofundar, naquela época, na pesquisa sobre o OSM.
>> >> >
>> >> > Talvez esteja aí o problema que afeta o OSM de forma geral citado por
>> >> > você.
>> >> > Falta gente para fazer as coisas, para mapear, corrigir problemas
>> e/ou
>> >> > implementar algumas características.
>> >> >
>> >> > Na minha opinião, um produto para ser bem aceito no mercado deve
>> atender
>> >> > as
>> >> > necessidades atuais desse mercado, mesmo que tenha de ser modificado
>> em
>> >> > certas características que farão com que no futuro, quando as
>> aplicações
>> >> > forem aperfeiçoadas, venha gerar trabalho.
>> >> >
>> >> > Confesso que nos sites que administro venho tentando motivar o
>> pessoal
>> >> > para
>> >> > ingresso no OSM, mas está sendo difícil a mim, empregando uma visão
>> >> > futurista, argumentar contra as criticas. Infelizmente o pessoal, em
>> >> > especial o brasileiro

Re: [Talk-br] Catedrais

[John Packer]

> nesse caso é um ponto de referência conhecido, com o name, uma busca por
> "Catedral, Ribeirão Preto" teria resultado.

Até onde eu sei, com "name=Catedral Metropolitana de São Sebastião" viria
como resultado de uma busca por "Catedral, Ribeirão Preto".

Concordo em grande parte com o Trebien.
Embora a etiqueta "name=*" geralmente seja o nome oficial, realmente tem
alguns casos em que é difícil reconhecer o lugar pelo nome oficial, e é
aceitável colocar como valor desta etiqueta um outro tipo de nome.



Em 27 de março de 2014 19:35, Fernando Trebien
escreveu:

> Oops, esquece aquele "old_name" ali. :P
>
> 2014-03-27 19:35 GMT-03:00 Fernando Trebien :
> > É a esta que você se refere, certo?
> >
> http://pt.wikipedia.org/wiki/Catedral_Metropolitana_de_Ribeir%C3%A3o_Preto
> >
> > Sugiro fazer assim (é como tenho feito em Porto Alegre):
> > official_name="Catedral Metropolitana de São Sebastião de Ribeirão Preto"
> > alt_name="Catedral São Sebastião"
> > old_name="
> > name="Catedral Metropolitana"
> >
> > alt_name é citado no próprio artigo da Wikipédia acima.
> >
> > official_name é o nome completo, que eu nesse caso eu deduzi a partir
> > das postagens na página da catedral no Facebook:
> >
> https://www.facebook.com/pages/Catedral-de-S%C3%A3o-Sebasti%C3%A3o-do-Ribeir%C3%A3o-Preto-SP/366093636788145
> )
> >
> > E "name" (sempre o mais complicado) eu penso que é ao mesmo tempo um
> > nome para listagem e para exibição no mapa, por isso sugiro que seja:
> > - curto
> > - não tão curto que não tenha informação útil (só "catedral", por
> > exemplo, é redundante, já que as tags já dizem que é uma catedral) ou
> > que gere nomes repetidos na mesma cidade
> > - tão parecido com o oficial quanto possível, tirando:
> >   * o nome da própria cidade (a maioria dos sistemas indexa os objetos
> > por cidade, e esses nomes só aparecem quando se observa o mapa no
> > nível da cidade ou menos)
> >   * as partes que as pessoas não costumam usar para se referir ao
> > objeto (geralmente coisas como "Ltda." ou, em alguns casos,
> > honoríficos como "Professor", "Doutor", etc., especialmente quando são
> > vários em sequência; mas na dúvida, não tire)
> >
> > No caso, "São Sebastião de Ribeirão Preto" deu nome à capela, depois à
> > vila, e por fim à cidade (suprimindo o nome do santo).
> > (http://pt.wikipedia.org/wiki/Ribeir%C3%A3o_Preto)
> >
> > Na minha experiência, essa receita de bolo pro "name" costuma dar um
> > resultado muito bom (para leitura do mapa, para busca, etc.) e sem
> > perdas de informação. Tem gente que coloca o nome oficial em name, mas
> > às vezes fica realmente muito longo.
> >
> > 2014-03-27 18:52 GMT-03:00 Roger C. Soares :
> >>
> >> amenity place_of_worship
> >> building cathedral
> >> religion christian
> >>
> >> Nesse caso é melhor deixar sem o "name=Catedral" mesmo? Aqui tem placas
> >> indicando "Catedral" ou "Catedral Metropolitana", eu sempre achei que
> fosse
> >> o nome da igreja... nesse caso é um ponto de referência conhecido, com o
> >> name, uma busca por "Catedral, Ribeirão Preto" teria resultado.
> >>
> >> Atenciosamente,
> >> Roger.
> >>
> >>
> >> ___
> >> Talk-br mailing list
> >> Talk-br@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/talk-br
> >
> >
> >
> > --
> > Fernando Trebien
> > +55 (51) 9962-5409
> >
> > "The speed of computer chips doubles every 18 months." (Moore's law)
> > "The speed of software halves every 18 months." (Gates' law)
>
>
>
> --
> Fernando Trebien
> +55 (51) 9962-5409
>
> "The speed of computer chips doubles every 18 months." (Moore's law)
> "The speed of software halves every 18 months." (Gates' law)
>
> ___
> 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] Validador nacional

[John Packer]

Acho que nesse caso, como a via também carrega a etiqueta "source=*", não
tem problema retirar do nó.

Pessoalmente, se eu mexo consideravelmente em um objeto, eu retiro ou
altero a etiqueta do objeto

Geralmente eu deixo a etiqueta "source=*" somente no meu conjunto de
alterações, mas às vezes eu acho apropriado adicionar tal etiqueta em um
objeto (principalmente se eu não cheguei a visitar o lugar, e estou
adicionando o formato ou nome somente por imagem satélite (bing), e/ou por
outro mapa como o ibge)


Em 27 de março de 2014 22:12, Erick de Oliveira Leal <
erickdeoliveiral...@gmail.com> escreveu:

> É pq tem informação demais nesse osm. Isso atrapalha quando vamos abrir no
> josm ne? Entre outros... Por exemplo tenho um estilo q pinta os nos vazios
> d uma forma... E eles deixam de ser estilizados por causas dessas tags q
> nada acrescentam...
> Em 27/03/2014 21:58, "Nelson A. de Oliveira"  escreveu:
>
> 2014-03-27 21:52 GMT-03:00 Erick de Oliveira Leal
>> :
>> > E casos como este https://api.openstreetmap.org/node/353241832, onde o
>> nó de
>> > uma via carrega o source, sendo que ela já traz... Pode ser deletado?
>>
>> De uma maneira simplória até poderia*, mas não precisa.
>>
>> *na verdade está dizendo que esta posição do nó foi obtida através de
>> alguma fonte (IBGE no caso)
>>
>> ___
>> 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 mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Lanes

[John Packer]

Uma alternativa mais popular para a etiqueta lanes:bus=* é
busway
=lane.

Erick, não sei se entendi corretamente o número de pistas, mas a pista de
ônibus deve ser contada no número da etiqueta lanes=*.
Ou seja, se tiver só um acostamento, o número pistas para esta etiqueta é
provavelmente 4.

Abs,
João


Em 28 de março de 2014 15:36, Arlindo Pereira <
openstreet...@arlindopereira.com> escreveu:

> lanes=3
> lanes:bus=1
> shouder[:{left|right}]=yes
>
> http://wiki.openstreetmap.org/wiki/Key:lanes
> http://wiki.openstreetmap.org/wiki/Shoulder
>
>
> []s
> Arlindo
>
> 2014-03-28 15:31 GMT-03:00 Erick de Oliveira Leal <
> erickdeoliveiral...@gmail.com>:
>
>> No DF existe uma rodovia chamada EPTG, nela há 5 faixas, uma destinada a
>> ônibus e outra a acostamento. Sendo 3 livres. Devo colocar lanes igual a
>> quanto?
>>
>> ___
>> 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 mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Mapa brasileiro

[John Packer]

Opa,

Hoje no resumo de notícias semanal do
OpenStreetMap,
anunciaram que foi criado um estilo de mapa específico para a
Suíça(
*Switzerland*).

Eles pegaram o estilo padrão do mapa oficial do OSM, e estão o modificando
(embora tenham feito poucas alterações por
enquanto
).

Isso me lembrou que foi comentado na lista recentemente como seria
interessante ter um estilo de mapa brasileiro, principalmente devido à
demora no desenvolvimento do estilo de mapa padrão do OSM.

Não foi discutido muito sobre, e queria relembrar sobre isso.
Creio que nessas conversas iniciais não precisemos nos preocupar sobre as
questões de *hosting* deste map.

Seria bom vermos algumas das idéias e sugestões que alteraríamos e
adicionaríamos neste mapa brasileiro, para ver se vale a pena o trabalho.
Eu tinha algumas idéias anotadas, que seguem abaixo.

   - Questões de traduções de iniciais (como *E* para Estacionamentos
e *RF*para Reservas Florestais
   - Não mostrar fios de eletricidade no mapa (já que existem em grande
   quantidade pelo Brasil inteiro, e pessoalmente acho que polui um pouco o
   mapa)
   - Sempre mostrar nomes em Português quando disponível (creio que só será
   útil em áreas de fronteiras se nos limitarmos ao Brasil neste mapa)
   - Adicionar certos pedidos da comunidade brasileira, possivelmente
   acelerando a adição no estilo padrão (por exemplo uns recentes como o de
   áreas indígenas e de parques aquáticos)
   - Mostrar lugares que são mais notáveis no Brasil com um ícone diferente
   (como por exemplo um ícone de pizza para Pizzarias)
   - Outras coisas possíveis como indicar quando uma rua tem uma ciclofaixa


Adoraria ouvir as suas sugestões,

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

[Talk-br] Lixo na base (continuação)

[John Packer]

Pessoal, como continuação deste trabalho de corrigir caracteres estranhos
na etiqueta name de ruas, eu utilizei da expressão regular documentada pelo
Erickpara
fazer uma verificação similar na etiqueta
addr:street.

A consulta feita no Overpass foi:


>   
>   
> 
> 
>regv="[_´`:|!@#%¨¹²³£¢§¬\^\?\=\*\$\+\[\}\{\~><&\\]|]"/>
>   
> 
> 
>regv="[_´`:,|!@#%¨¹²³£¢§¬\^\?\=\*\$\+\[\}\{\~><&\\]|]"/>
>   
> 
> 
>regv="[_´`:,|!@#%¨¹²³£¢§¬\^\?\=\*\$\+\[\}\{\~><&\\]|]"/>
>   
> 
>   
>   
>   
>   
>   
> 
>


Rodei esta consulta na região Sul do Brasil e arredores, então com o JOSM
aberto e configurado para controle
remoto,
cliquei no botão "Export", e depois na guia "Data" e no link "load into
JOSM" para abrir os resultados da consulta no JOSM.
Então eu fiz uma busca por objetos com uma etiqueta "street" no JOSM, e
adicionei eles em uma lista do plugin TODO
listpara
não ter problema verificando quais objetos já foram verificados.
Então eu coloquei o Mapnik (estilo de mapa padrão do OpenStreetMap) como
camada para eu poder verificar se existe por perto a rua especificada na
etiqueta addr:street de cada objeto, e/ou se está correta.

Vi que tinham alguns lugares que tinha vírgula no nome da rua da seguinte
forma: "SC 301, km 01". Eu achei tais casos sensatos, e não toquei neles.
Outro caso que eu não toquei foi o seguinte: "Avenida Professor Luciano
Gualberto, Travessa 3"  (e
outros bem parecidos perto deste mesmo objeto).

Segue o link do conjunto de alterações que eu fiz:
http://www.openstreetmap.org/changeset/21385394

Abs,
João
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Lixo na base (continuação)

[John Packer]

Fiz outro conjunto de alterações:
http://www.openstreetmap.org/changeset/21385637
Vou parar por agora, pois tenho outros afazeres hoje.

Segue as minhas conclusões quanto à correções nas etiquetas addr:street=*

   - Teve poucos resultados para essa consulta, sendo a maioria ou uso
   legítimo ou a adição desnecessária do número do edifício e/ou da cidade
   após uma vírgula;
   - Creio que uma busca mais interessante seria verificar se o valor da
   chave addr:street é igual ao valor da chave name de alguma via próxima.
   (não sei como fazer isso, ou se já é feito por algum validador)

O JOSM realmente é um editor poderoso. Este foi um ótimo exercício para me
familiarizar mais com as habilidades deste editor.

Abs, João


Em 29 de março de 2014 13:11, John Packer  escreveu:

> Pessoal, como continuação deste trabalho de corrigir caracteres estranhos
> na etiqueta name de ruas, eu utilizei da expressão regular documentada
> pelo 
> Erick<http://wiki.openstreetmap.org/wiki/User:Erickdeoliveiraleal/overpass-turbo#.C2.B4.60:.2C.7C.21.40.23.25.C2.A8.C2.B9.C2.B2.C2.B3.C2.A3.C2.A2.C2.A7.C2.AC.5E.3F.3D.2A.24.2B.5D.5B.7D.7B.7E.3E.3C.5C_em_qualquer_posi.C3.A7.C3.A3o>para
>  fazer uma verificação similar na etiqueta
> addr:street.
>
> A consulta feita no Overpass foi:
>
> 
>>   
>>   
>> 
>> 
>>   > regv="[_´`:|!@#%¨¹²³£¢§¬\^\?\=\*\$\+\[\}\{\~><&\\]|]"/>
>>   
>> 
>> 
>>   > regv="[_´`:,|!@#%¨¹²³£¢§¬\^\?\=\*\$\+\[\}\{\~><&\\]|]"/>
>>   
>> 
>> 
>>   > regv="[_´`:,|!@#%¨¹²³£¢§¬\^\?\=\*\$\+\[\}\{\~><&\\]|]"/>
>>   
>> 
>>   
>>   
>>   
>>   
>>   
>> 
>>
>
>
> Rodei esta consulta na região Sul do Brasil e arredores, então com o JOSM
> aberto e configurado para controle 
> remoto<http://josm.openstreetmap.de/wiki/Help/Preferences/RemoteControl>,
> cliquei no botão "Export", e depois na guia "Data" e no link "load into
> JOSM" para abrir os resultados da consulta no JOSM.
> Então eu fiz uma busca por objetos com uma etiqueta "street" no JOSM, e
> adicionei eles em uma lista do plugin TODO 
> list<http://wiki.openstreetmap.org/wiki/JOSM/Plugins/TODO_list>para não ter 
> problema verificando quais objetos já foram verificados.
> Então eu coloquei o Mapnik (estilo de mapa padrão do OpenStreetMap) como
> camada para eu poder verificar se existe por perto a rua especificada na
> etiqueta addr:street de cada objeto, e/ou se está correta.
>
> Vi que tinham alguns lugares que tinha vírgula no nome da rua da seguinte
> forma: "SC 301, km 01". Eu achei tais casos sensatos, e não toquei neles.
> Outro caso que eu não toquei foi o seguinte: "Avenida Professor Luciano
> Gualberto, Travessa 3" <http://www.openstreetmap.org/way/158960182> (e
> outros bem parecidos perto deste mesmo objeto).
>
> Segue o link do conjunto de alterações que eu fiz:
> http://www.openstreetmap.org/changeset/21385394
>
> Abs,
> João
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] erro no startup do JOSM

[John Packer]

Eu também tive um problema bem parecido algumas vezes recentemente (onde o
JOSM perguntava se eu estava usando um *proxy*).
Fui testar hoje e não aconteceu.
Agora baixei a última versão só pra garantir.


2014-03-29 13:33 GMT-03:00 Fernando Trebien :

> Eu estava com o mesmo problema e não consegui resolver, então já que
> agora somos dois (e talvez mais), abri um ticket:
> http://josm.openstreetmap.de/ticket/9875
>
> On Sat, Mar 29, 2014 at 9:56 AM, Gerald Weber  wrote:
> > De alguns dias para cá eu comecei a ter esse erro no JOSM:
> >
> > WARNING: Failed to load
> >
> http://github.com/bastik/mapcss-tools/raw/osm/mapnik2mapcss/osm-results/mapnik.zip
> ,
> > use cached file and retry next time: javax.net.ssl.SSLProtocolException:
> > handshake alert:  unrecognized_name
> >
> > daí ele me fala que poderia ser um problema de proxy settings, mas eu não
> > uso proxies.
> >
> > alguma idéia?
> >
> > obrigado
> >
> > Gerald
> >
> > ___
> > Talk-br mailing list
> > Talk-br@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-br
> >
>
>
>
> --
> Fernando Trebien
> +55 (51) 9962-5409
>
> "Nullius in verba."
>
> ___
> 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