Re: [Talk-br] Prioridades em rodovias com mais de uma ref=

2015-02-15 Por tôpico Flavio Bello Fialho
Bom, se existe a possibilidade de uma BR-XXX ter um trajeto diferente de
 uma RSC-XXX então é essencial que nos trechos em que de fato coincidam
 tenhamos ambos as referências no trecho.


 Por favor, me mostre um caso em que isso ocorre.



 Veja as mensagens anteriores. Este é o argumento do Claiton, eu mesmo não
 conheço nenhum caso. Mas não vou ficar surpreso se isto existir.


Se existir, eu mesmo mudo todas as RSC para RSC;BR. Não existe.


 Ter ambas as referências não polui o mapa, e eu como usuário, acho
 extremamente útil.


 Se todas as RSC coincidem com BR, é completamente inútil


 De modo algum. Você está esquecendo que *nós aqui da lista* conhecemos
 esses códigos de rodovia e sabemos o que significa.

 Já o usuário comum não tem obrigação de saber que RSC-XXX e BR-XXX são a
 mesma coisa, então para o usuário comum esta informação é valiosa.

 Não estou convencido de que isso não é redundante (por favor me convença,
 me mostrando um contra-exemplo).


 Considere o exemplo de um turista estrangeiro que tem como endereço uma
 pousada na BR-262 em Sabará. Mas a única coisa que ele encontra é a
 MGC-262. E agora? Para complicar ainda existe a MG-262 na região (que nada
 tem a ver com a BR-262/MGC-262).


Eu quis dizer um contra-exemplo onde uma RSC não segue o trajeto planejado
de uma BR.


 Hoje (se ninguém apagar) ele vai encontrar isto no OSM:
 http://www.openstreetmap.org/#map=15/-19.8747/-43.8459

 a BR-262 marcada junto com a MGC-262, aí vai entender de que se trata da
 mesma rodovia. Pronto, problema resolvido e a informação redundante  teve
 sua utilidade.

 Antes de conhecer esses códigos de rodovia eu já passei por situação
 semelhante, por isto eu sei que este exemplo é válido.

 Nas placas em Sabará aparece ora MGC-262 ora BR-262, mas a população local
 so fala na BR (vamos alí na BR). Ninguém vai passar um endereço na
 MGC-262, todo mundo só fala na BR-262.


O tag ref é para informações oficiais. O tag para nomes alternativos pelos
quais a população local conhece uma via é alt_name, loc_name ou reg_name,
dependendo do caso. Existe ainda a possibilidade de nat_ref, reg_ref ou
loc_ref. Se a preocupação é essa, talvez esse caso possa ter dois tags:
ref=MGC-262 e nat_ref=BR-262. Se for possível, é melhor evitar valores
múltiplos para o mesmo tag.

No Rio Grande do Sul (onde estou mapeando e organizando as relações de
todas as rodovias), vou colocar apenas RSC no tag ref. Seria bom que se
usasse o mesmo padrão em todo o país, mas se a comunidade de Minas Gerais
decidir fazer diferente, fiquem à vontade.

-- 
Flávio Bello Fialho
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br


Re: [Talk-br] Prioridades em rodovias com mais de uma ref=

2015-02-15 Por tôpico Arlindo Pereira
Algo que me passou na cabeça: sei que não é nossa responsabilidade
enquanto mapeadores, mas podemos investigar se quem reintroduz name=*
nessas rodovias o faz porque seu cliente de mapas (GPS veicular) não
suporta a tag ref para buscas ou algo do tipo.

[]s
Arlindo
Em 15/02/2015 11:25, Gerald Weber gwebe...@gmail.com escreveu:



 no exempo do Gerald podemos coloque “ref=BR-367;MGC-367” +
 “nat_ref=BR-367” + “ref_ref=MGC-367”. No verdade este e duplificacao das
 dados, mas acho necessário porque tanto aplicativos não vai conhecer os
 valores nat_ref e reg_ref


 É uma boa estratégia. Aumentando o número de nat_ref e reg_ref (6000
 comparado com 1.2 milhão de ref) quem sabe com o tempo os renderizadores
 passam a usar isto também. O único dilema é que na verdade a nat_ref=BR-367
 é que é conhecida regionalmente.



 Em tanto, ainda vendo muitos rodovias que tem um copia do ref no nome,
 este não e certo. Eu não copiando refs como MGC-xxx para o ref, mas
 provavelmente deve, mas onde ver que ref= e name= e mesmo, apagando o valor
 da name=


 Em vez de apagar eu tenho feito assim: troco name=MGC-262  por
 incorrect:name=MGC-262. Eu tenho percebido que quando apago
 name=MGC-262 com o tempo alguém acaba reintroduzindo. Minha frágil
 esperança é que incorrect:name=MGC-262 evite isto. :P

 Gerald


 ___
 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] Prioridades em rodovias com mais de uma ref=

2015-02-15 Por tôpico Gerald Weber
2015-02-15 8:48 GMT-02:00 Flavio Bello Fialho bello.fla...@gmail.com:



 Bom, se existe a possibilidade de uma BR-XXX ter um trajeto diferente de
 uma RSC-XXX então é essencial que nos trechos em que de fato coincidam
 tenhamos ambos as referências no trecho.


 Por favor, me mostre um caso em que isso ocorre.



 Veja as mensagens anteriores. Este é o argumento do Claiton, eu mesmo não
 conheço nenhum caso. Mas não vou ficar surpreso se isto existir.


 Se existir, eu mesmo mudo todas as RSC para RSC;BR. Não existe.


Eu acho que você deve manter RSC;BR, em respeito ao usuário do mapa,
existindo ou não traçados diversificados.


 O tag ref é para informações oficiais. O tag para nomes alternativos pelos
 quais a população local conhece uma via é alt_name, loc_name ou reg_name,
 dependendo do caso. Existe ainda a possibilidade de nat_ref, reg_ref ou
 loc_ref. Se a preocupação é essa, talvez esse caso possa ter dois tags:
 ref=MGC-262 e nat_ref=BR-262. Se for possível, é melhor evitar valores
 múltiplos para o mesmo tag.


Hum, é uma mudança importante de opinião. Agora há pouco você considerava
redundante (ou seja idêntico), agora BR nem sequer é oficial para você.

BR continua sendo tão oficial quanto RSC ou MGC. Os documentos do DER-MG
trazem ambos os códigos. Eu agora estou revisando a MGC-367;BR-367 por onde
passei. Ela é administrada em todo o trecho pelo DER-MG. Ora há placas com
MGC ora com BR. Já as placas de direção sempre aparecem como BR-367 a 10
km.



 No Rio Grande do Sul (onde estou mapeando e organizando as relações de
 todas as rodovias), vou colocar apenas RSC no tag ref. Seria bom que se
 usasse o mesmo padrão em todo o país, mas se a comunidade de Minas Gerais
 decidir fazer diferente, fiquem à vontade.


Não se trata de transformar isto numa discussão bairrista, em RS fazemos
assim, em MG fazemos assado. Além do mais do mais eu entendo que há
mapeadores do RS que tem opinião diferente da sua.

Trata-se de *priorizar* o usuário do mapa e passar da melhor maneira
possível todas as informações relevantes e de modo acessível, quer que a
gente goste ou não da informação. Essa discussão é para achar o melhor
jeito de se fazer isto.

Neste momento o melhor jeito de fazer isto é colocando ambas as ref.

Podemos resumir os argumentos contra que até agora apareceram  da
seguinte maneira:

*Não colocar* ref=RSC;BR ou ref=MGC;BR porque

1) é redundante

Resp.: Não é redundante, como exemplificado no exemplo do visitante
estrangeiro.

2) porque BR não é designação oficial

Resp.: continua sendo designação oficial e costuma ser mais usada pela
população (pelo menos em MG)

3) porque 2 ou mais ref polui o mapa

Resp.: não se deve omitir informações por razões estésticas, pela mesma
razão que não abreviamos Rua,  Avenida ou Desembargador

Argumentos *a favor de colocar *ref=RSC;BR ou ref=MGC;BR

1) É uma informação importante.

Posso atestar isto por experiência pessoal.

2) Torna a informação imediatamente acessível em quase todas as
visualizações de mapa

Confirmo que aparece no Mapnik, no OSRM, Mapfactor, Oruxmaps e no Osmand
que são os aplicativos que usei recentemente.

Detalhe: no Osmand a rederização fica defeituosa, mas isto acontece com
todas as referências que tem mais de 2 letras como LMG-677, mas a listagem
está OK.

No skobbler mostra apenas a primeira ref.

3) Porque não custa absolutamente nada colocar duas referências na mesma
tag.

Então como mapeador e (principalmente) como usuário do mapa eu voto por
manter ambas as referências na mesma tag.

abraço

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


Re: [Talk-br] Prioridades em rodovias com mais de uma ref=

2015-02-15 Por tôpico Gerald Weber



 no exempo do Gerald podemos coloque “ref=BR-367;MGC-367” +
 “nat_ref=BR-367” + “ref_ref=MGC-367”. No verdade este e duplificacao das
 dados, mas acho necessário porque tanto aplicativos não vai conhecer os
 valores nat_ref e reg_ref


É uma boa estratégia. Aumentando o número de nat_ref e reg_ref (6000
comparado com 1.2 milhão de ref) quem sabe com o tempo os renderizadores
passam a usar isto também. O único dilema é que na verdade a nat_ref=BR-367
é que é conhecida regionalmente.



 Em tanto, ainda vendo muitos rodovias que tem um copia do ref no nome,
 este não e certo. Eu não copiando refs como MGC-xxx para o ref, mas
 provavelmente deve, mas onde ver que ref= e name= e mesmo, apagando o valor
 da name=


Em vez de apagar eu tenho feito assim: troco name=MGC-262  por
incorrect:name=MGC-262. Eu tenho percebido que quando apago
name=MGC-262 com o tempo alguém acaba reintroduzindo. Minha frágil
esperança é que incorrect:name=MGC-262 evite isto. :P

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


Re: [Talk-br] Situação das traduções

2015-02-15 Por tôpico Alexandre Magno Brito de Medeiros
Aquele período de 48 horas, que abri para votação de possível nova licença,
acabou ontem às 7 horas da manhã. *Sem votos.* Então fica tudo como está!

Por via das dúvidas, fui verificar a adequação de CCO 1.0
https://creativecommons.org/publicdomain/zero/1.0/deed.pt_BR para
software. Pude descobrir
http://opensource.com/law/11/4/creative-commons-plaintext-licenses-and-using-cc0-software
que é a única licença Creative Commons que a Free Software Foundation
recomenda https://www.gnu.org/licenses/license-list.en.html#CC0 para
software. É compatível com GNU GPL.

Depois, quando o projeto estiver mais organizado
https://github.com/OSMBrasil/OSMBtranstats/issues/4, vou colocar
cabeçalhos
https://wiki.creativecommons.org/CC0_FAQ#May_I_apply_CC0_to_computer_software.3F_If_so.2C_is_there_a_recommended_implementation.3F
nos arquivos. Eles não são obrigatórios mas são convenientes.

Alexandre Magno

Em 12 de fevereiro de 2015 07:09, Alexandre Magno Brito de Medeiros 
alexandre@gmail.com escreveu:

 O resultado
 https://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Tradu%C3%A7%C3%B5es/Situa%C3%A7%C3%A3o
 do script https://github.com/OSMBrasil/OSMBtranstats já está à frente
 do resultado manual, com algumas modificações
 https://wiki.openstreetmap.org/w/index.php?title=WikiProject_Brazil%2FTradu%C3%A7%C3%B5es%2FSitua%C3%A7%C3%A3odiff=1138065oldid=1135839.
 Apenas as coletas de situação das traduções do GraphHopper e do
 CheckAutopista não estão automatizadas
 https://github.com/OSMBrasil/OSMBtranstats/issues/3. O primeiro é uma 
 planilha
 tabulada
 https://docs.google.com/spreadsheet/pub?key=0AmukcXek0JP6dGM4R1VTV2d3TkRSUFVQakhVeVBQRHcsingle=truegid=0output=txt
 no Google Docs e o outro é um arquivo de variáveis Javascript
 https://github.com/k1wiosm/checkautopista/blob/master/lang/translations.js#L191-L227.
 Quem quiser fazer os dois coletores, ou um deles, fique à vontade. Mas os
 julguei uma perda de tempo e por isso não os fiz eu mesmo. Há muito com o
 que contribuir para o projeto
 https://github.com/OSMBrasil/OSMBtranstats/issues, ainda que atualmente
 ele não apresente bugs. Dica (olhe as aspas, não é tão motivação assim; 
 *Homi...
 deixe isso quieto...*): existem parsers de Javascript... já usei
 brevemente um em Python.

 Eu não tenho experiência de dia-a-dia com Ruby, assim como com qualquer
 outra linguagem de programação também não tenho. Eu apenas quis
 experimentar e aprender um pouco. Fiz o que sabia ou o que consegui
 aprender rapidamente. Tive condições de escolher Ruby entre algumas
 linguagens, mas isso não quer dizer que as domine. Então, quem tiver
 condições, fique muito à vontade para fazer até melhorias drásticas no
 código. Afinal, estamos versionando-o. Prefira começar com novos branches,
 nesses casos. Se eu enxergar algo estranho, que pareça retrocesso, vou
 indagar. Mas o colaborador poderá facilmente acabar por me ensinar.

 Prefiro não ser o usuário padrão desse software. Quero apenas estar por
 perto para fazer correções, melhorias, e impedir que ele desande,
 deteriore. Se alguém quiser atualizar a wiki semanal ou quinzenalmente,
 DIGA AÍ, POR FAVOR. Estou aqui para dar o suporte de instalação e execução
 que for necessário. Roda em Windows... e muito provavelmente também em Mac
 e GNU/Linux.

 Evidentemente, hoje, quem está visivelmente à frente do projeto,
 conduzindo-o, sou eu. Mas ele não é um projeto de Alexandre. *É da
 comunidade.* Já está em domínio público por CCO 1.0
 https://creativecommons.org/publicdomain/zero/1.0/deed.pt_BR*. Está lá
 na OSMBrasil https://github.com/OSMBrasil. Qualquer pessoa do time
 Owners https://github.com/orgs/OSMBrasil/teams/owners -- Muito obrigado
 por me incluírem nele! -- comita diretamente e tem poderes de administração
 no repositório, até onde eu saiba. Então, mais uma vez: fiquem à vontade!

 ** Podemos mudar a licença. Eu sei que CCO 1.0
 https://creativecommons.org/publicdomain/zero/1.0/deed.pt_BR nem é
 praticada para software. Se alguém quiser que isso mude, conversemos. Ou
 simplesmente se apoderem :) pois agora já foi! Se aparecerem ao menos três
 opiniões ganhadoras a favor de uma licença específica entre GPLv2, GPLv3,
 Apache License 2.0 e Expat/MIT License, numa votação de 48 horas contando
 de agora, eu já faço o favor de mudar lá no repositório, para seguirmos em
 frente com a nova licença. Eu acho que é melhor assim, partilhado. A quem
 interessar: Licenças de software
 http://forum.openstreetmap.org/viewtopic.php?id=30065.*

 Alexandre Magno

 Em 5 de fevereiro de 2015 18:58, Vitor George vitor.geo...@gmail.com
 escreveu:

 Pessoal,

 Há algum tempo
 http://article.gmane.org/gmane.comp.gis.openstreetmap.region.br/1595/match=tradu%C3%A7%C3%B5es
  comecei
 a mandar na lista de discussão talk-br
 https://lists.openstreetmap.org/listinfo/talk-br informes sobre a
 situação da tradução ao português brasileiro das ferramentas do
 OpenStreetMap.

 Agora não consigo mais mandar estes informes com frequência, e coloquei-o
 no wiki