Eu gostei. Se o que está na placa é com nros, então pra mim faz sentido deixar no name ao invés do short_name... e usar outra tag para o nome por extenso.

Atenciosamente,
Roger.

--
Fernando Trebien escreveu:

Eu tenho o costume (não oficial) de colocar o nome com algarismos na tag "name" e o nome por extenso na tag "official_name" (mas poderia ser "alt_name" também). Assim fica compacto no renderizador, fica bem também numa listagem de nomes de ruas e atende buscas pelos dois nomes. (Isso significaria entender a tag "name" como sendo "display name".)

Mas o ideal seria discutir essa abordagem primeiro. A principio o nome com algarismos deveria mesmo ir na tag "short_name", mas poucos parecem estar suportando ela (renderizadores e GPSs) em nomes de ruas.

On Aug 9, 2013 11:46 AM, "Roger C. Soares" <rogersoa...@gmail.com> wrote:
Em Goiânia tem bastante ruas com o nome sendo um número. Qual seria o mais correto?

Rua C Duzentos e Trinta e Seis
Rua C-Duzentos e Trinta e Seis
Rua C - Duzentos e Trinta e Seis
Rua C 236
Rua C-236
Rua C - 236

E mesmo aqui, algumas tem número, por exemplo
Rua 7 de Setembro ou Rua Sete de Setembro?

Outra coisa pra lembrar qdo se mudar o nome da rua é olhar se não tem nós de numeração com addr:street..

Atenciosamente,
Roger.

--
Leandro Motta Barros escreveu:
2013/8/8 Fernando Trebien <fernando.treb...@gmail.com>:
  
Quanto às abreviações, eis uma lista bem completa:
http://wiki.openstreetmap.org/wiki/Name_finder:Abbreviations#Portugu.C3.AAs_-_Portuguese

O nome dos acessos realmente é um inferno. Até sugeri traduzir "link"
como "acesso" nas interfaces (ex.: "primary link" > "acesso primário")
pra não deixar o usuário tão tentado a fazer isso (o que acham, boa
idéia ou não?).
    
Acho nomes como "acesso primário" e "acesso secundário" podem passar a
ideia errada. Seguidamente vejo em rodovias sinalização dizendo coisas
como "Cidadópolis - Acesso Secundário", e aquilo que não é um
secondary_link.

Acho que um secondary_link está mais para "acesso a via secundária" do
que para "acesso secundário".

LMB




  
Quanto às ruas que se cruzam, vale lembrar que nem todos os
cruzamentos de linhas devem ter um ponto em comum (exemplos: viadutos,
pontes sobre hidrovias). O ponto representa uma conexão entre as vias,
no caso de uma diferença de nível não é necessário (nem muito correto)
ter ponto. (O validador do JOSM implementa exatamente essa lógica.)

2013/8/8 Leandro Motta Barros <l...@stackedboxes.org>:
    
Alguns dos problemas que eu mais encontrava eram:

1) Abreviações

2) Nomes que não são nomes ("Escola", "Retorno", "Praça", "Acesso ao
supermercado"). Isso é um inferno, porque esconde o problema nos
KeepRight da vida. Se não sabe o nome, deixe em branco! (É igualmente
errado, mas é mais fácil de encontrar o erro.)

3) Ruas que se cruzam sem um ponto em comum para indicar que estão
efeticamente ligadas.

4) Informações copiadas. Isso é difícil de identificar simplesmente
olhando para o que está mapeado, mas muitas vezes fico com suspeitas
quando comparo coisas no OSM com o Google Maps ou outro. Nunca é
demais alertar sobre isso.

Fora isso, tem coisas que nem são erros propriamente ditos, mas sim
uma questão de "julgamento duvidoso". Muita coisa que fazemos ao
mapear envolve julgamento ("é melhor fazer deste ou daquele jeito?"),
e talvez valha a pena tentar identificar os "julgamentos duvidosos
mais comuns" e dar algum subsídio para os novatos tomarem decisões
mais acertadas.

Lembro de um caso relativo a isso: vejo que é comum ver pessoas usando
"pontos demais" (entre aspas porque é questão de julgamento, como eu
disse). Por exemplo: ao mapear uma curva, colocam pontos a cada meio
metro (OK, talvez eu esteja exagerando :-P) para gerar uma curva ultra
suave. Ou incluem vários pontos intermediários no que é uma linha reta
de poucos metros de extensão [1] (pô!, dois pontos definem uma reta,
né?!).

Acho que esses pontos (sobretudo aqueles primeiros quatro) são os principais.

Abraço,

LMB

[1] Lembro de ler em algum lugar que em caso de retas muito longas,
recomendava-se colocar pontos intermediários "desnecessários". O
objetivo era evitar que uma consulta a um determinado retângulo
acabasse por não pegar alguma feature importante (estrada,
oleoduto...) que passe bem pelo meio dele porque nenhum ponto foi
amostrado. Não é disso que estou falando. Me refiro a coisas como
colocar pontos intermediários entre duas esquinas.



2013/8/8 Vitor George <vitor.geo...@gmail.com>:
      
Ótimo!

No video-tutorial eu queria ensinar coisas bem simples, para usuários
iniciantes. Quais problemas, além da abreviação, vcs acham que eu poderia
falar?

Vitor


2013/8/8 Leandro Motta Barros <l...@stackedboxes.org>
        
Legal!

Há coisa de um ano atrás eu fazia mensalmente uma edição de correção
de erros aqui nas redondezas, incluindo eliminação de abreviações.
Recentemente vi que algumas abreviações andaram voltando a aparecer.

Vou tentar participar, nem que seja simbolicamente, corrigindo algumas
apenas :-)

LMB




2013/8/7 Vitor George <vitor.geo...@gmail.com>:
          
Oi pessoal,

O que acham de fazer uma maratona de mapeamento para celebrar o
aniversário
do OpenStreetMap, na sexta-feira?

Minha proposta é, a partir das 16h, nos reunirmos virtualmente (ou
pessoalmente se possível) para acabarmos com um grande problema, as
abreviações do mapa.

As abreviações são nocivas porque confundem algoritmos de busca, mas
podem
ser exterminadas por colaboradores de qualquer nível de experiência.

Neste horário vou abrir um streaming/hangout para explicar as maneiras
possíveis de resolver este problema, e aí podemos ir coordenando os
trabalhos.

O que acham?

Vitor

_______________________________________________
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br

            
_______________________________________________
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br
          
_______________________________________________
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br

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

  


_______________________________________________
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br


_______________________________________________ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br

_______________________________________________
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br

Responder a