Pessoas de Brasília, me corrijam se eu estiver errado, e preparem-se para um e-mail longo, provavelmente um esboço do que irá pro wiki.
Após experimentar bastante nas SQN 707 e 708 (http://www.openstreetmap.org/relation/3353968, http://www.openstreetmap.org/relation/3353967), constatei que praticamente todas as decisões de roteamento em Brasília se resumem a encontrar "blocos" com precisão. Tanto é que se apenas mapearmos os endereços até o nível dos blocos, acredito que já teremos suprido 99,9% das necessidades de geocoding de Brasília. Uma vez encontrado o bloco de destino, o trecho final (localizar uma loja/lote no bloco) quase sempre é fácil e requer uma caminhada curta de menos de 30m. Isso é ótimo! Significa que dá muito menos trabalho fazer um geocoding aceitável em Brasília do que em outras cidades. Mas, o ideal é nos prepararmos para permitir mais detalhes usando interpoladores ou mapeando casa a casa futuramente. Então, em Brasília o desafio é encontrar um esquema que permita localizar blocos facilmente, tanto com o Nominatim quanto com aparelhos de GPS convencionais, e que ainda fique bem no mapa renderizado, e que não burle as definições rigorosas das tags do OSM. Há basicamente 2 tipos de blocos em Brasília: verticais (ex.: apartamentos) e horizontais (ex.: lojas). Pra entender por que isso é relevante pro mapeamento, primeiro é necessário entender o formato dos endereços em Brasília. Um endereço brasiliense tem as seguintes partes: (1) {tipo de setor} [Quadra] {número da quadra} Bloco {designação do bloco} + (2) Loja/Apartamento {número} + (3) [complemento] tipo de setor = SHS, SCLRN, SCRN, etc. [quadra] é opcional; às vezes se usa, às vezes não - varia um pouco por tipo de setor. designação do bloco = A, B, K, H, etc. [complemento] é opcional e varia bastante, como em qualquer outra cidade Exemplos fictícios: SHS Quadra 3 Bloco A Loja 20 2º andar Ala Sul SCLRN 708 Bloco I Apartamento 203 O que acontece então nos blocos: - verticais: a parte (2) funciona como "complemento" (addr:housename) e não interessa pra geocoding/roteamento - horizontais: a parte (2) funciona como "complemento" (addr:housename) se cada unidade (cada loja, cada lote, etc.) for mapeada individualmente; senão, como as unidades são contíguas e identificadas por números sequenciais, essa parte funciona mais como numeração de casa (addr:housenumber), que pode ser interpolada se ignorarmos palavras como "loja" ou "lote" Detalhe importante: o costume local é usar sim essas palavras no endereço. O problema é que, para a interpolação funcionar, não tem jeito senão deixar essas palavras de fora, o campo addr:housenumber precisa necessariamente ser um número (sem letras, vírgula, etc.). Então, vejo que Brasília terá 3 estágios de mapeamento de endereços: Fase 1: mapear os blocos Fase 2: refinar introduzindo interpoladores para cada bloco Fase 3: refinar convertendo interpoladores em lotes individuais As palavras "lote" ou "loja" poderiam ser mantidas como comentário na tag "note" e reintroduzidas na addr:housename ao ir para a fase 3. Enquanto estivermos na fase 2, as pessoas teriam que se acostumar a buscar sem essas palavras (não tem outro jeito). Mas lembrem: a fase 1 já atende 99,9% das necessidades, então isso não é um problema importante. OBS: na minha opinião, acho que nunca deveríamos abandonar a fase 2 completamente. Casas novas aparecem, casas antigas deixam de existir. Não ficamos sabendo dessas coisas (seria muita informação pra processarmos), então, ao usar interpoladores, tornamos o mapa resiliente a essas mudanças comuns. Para a interpolação funcionar nos blocos horizontais, a parte (1) deve ir no campo addr:street e o número da parte (2) no campo addr:housenumber. Além disso, deve haver uma via (primária, secundária, terciária, etc.) cuja tag "name" seja igual à tag "addr:street" do interpolador. Ou seja, as vias de trânsito passam a ter nomes em Brasília. É exatamente a mesma solução adotada pela NavTEQ (vejam o here.com em Brasília). Isso tem um efeito colateral interessante: fazendo assim, o mapa se torna compatível com quaisquer aparelhos de GPS. A lista de nomes de ruas fica bem mais longa, mas se o navegador tiver uma busca decente (quase todos têm), isso também não é um problema. A única diferença é que a pessoa não precisaria informar o número de casa; na maioria dos navegadores, basta deixar essa parte em branco, deve funcionar suficientemente bem. Mas para funcionar excepcionalmente bem, devemos nos certificar de nomear as vias com o nome do bloco em apenas 1 dos lados do bloco (o lado do acesso principal). Exemplo: http://www.openstreetmap.org/way/142488962 Um problema é quando a mesma via serve de acesso a dois ou mais blocos. Aqui a solução é "criativa": quebrar a via em um ponto e atribui o nome de um bloco a um pedaço e do outro bloco a outro pedaço. O here.com faz exatamente assim. Adotei a convenção inversa à deles: ao transitar pela via, o primeiro trecho recebe o nome do prédio à direita de quem transita. Faz pouca diferença, mas num GPS bom (que dê preferência por dobrar à direita) o usuário ficaria sabendo que chegou ao destino um pouco antes e com isso teria mais tempo pra escolher um lugar pra parar. Exemplos: http://www.openstreetmap.org/way/142489220, http://www.openstreetmap.org/way/249408906 Finalizando, obviamente tudo que vem na parte (3) também iria na tag addr:housename, independente do caso, já que essa tag é mais informativa do que útil para render/roteamento. Tudo quase resolvido, não fosse um detalhe: pra que o Nominatim encontre a área do bloco, não basta acrescentar a tag "addr:street" ao bloco. Então, excepcionalmente pros blocos, eu estou usando a tag "reg_name" com esse conteúdo (sem a tag addr:street). Por que "reg_name"? Pra evitar colisões com outras tags de nome, que são muito mais comuns. Na tag "name" coloquei um "nome de exibição" que achei razoável/útil, e acho que seria interessante discutir isso. Exemplo: http://www.openstreetmap.org/way/249408898 Exemplos de buscas que funcionam com esse esquema: "shcgn 707 bloco i" : 2 resultados inexatos: 1 pra via, 1 pro bloco; essa seria a busca feita num GPS comum "scrn 708/709 bloco b 50" : 1 resultado aproximado; possível num GPS comum "scrn 708/709 bloco b loja 50" : 1 resultado inexato (a via); resultado exato impossível num GPS comum "sclrn 708 bloco i 20" : 1 resultado aproximado; possível num GPS comum "sclrn 708 bloco i loja 20" : 1 resultado inexato (a via), 1 resultado absolutamente exato (lote mapeado individualmente); resultado exato impossível num GPS comum Além dos endereços, eu também mapeei as 2 superquadras que eu citei no começo e alguns setores dentro e fora delas (exemplos: http://www.openstreetmap.org/relation/3351334, http://www.openstreetmap.org/relation/3351331, http://www.openstreetmap.org/relation/3351332). Estou adotando os seguintes significados pra admin_level no DF: - admin_level=4 (similar a estado) + place=state: Distrito Federal - admin_level=8 (similar a município) + place=city/town/village/hamlet: regiões administrativas (porque Brasília geralmente é tratada como cidade, e as demais regiões eram/ainda são frequentemente chamadas de cidades-satélite) - admin_level=9 (similar a distrito) + place=suburb: bairros e partes do plano piloto (ex.: Asa Norte) - admin_level=10 (similar a bairro) + place=neighbourhood: superquadras - admin_level=11 (similar a vizinhança) + place=neighbourhood: setores Acho que a única coisa que eu pensaria em mudar é a tag place das superquadras, com a finalidade específica de fazer o nome delas aparecer no Mapnik. Seria mapear para o renderer, mas como Brasília é um caso muito atípico, acho que devemos nos guiar pelo valor-utilidade de cada decisão, e não por definições estritas que foram feitas para outro tipo de cidade. 2013/11/29 Erick de Oliveira Leal <erickdeoliveiral...@gmail.com>: > Ótimo. Obrigado Trebien pela pesquisa. Estou ocupado no trabalho e to parado > no osm. Mas isso tem q ser colocado na wiki pra ajudados próximos > mapeadores. Valeu. > > Em 29/11/2013 21:42, "Fernando Trebien" <fernando.treb...@gmail.com> > escreveu: >> >> Pessoal de Brasília, >> >> Vou visitar a cidade entre 9 e 12 de dezembro e, organizando a minha >> viagem, resolvi (1) contribuir meus POIs e (2) marcar os POIs que vou >> visitar. Daí descobri que onde pretendo ficar (o Hostel 7 - >> http://www.openstreetmap.org/?node=2417231176) estava marcado num >> outro lugar. Daí resolvi consertar, e acabei fazendo um teste em >> Brasília para ver como seria melhor mapear as superquadras e os >> setores. Eu de fato não entendia muito sobre a cidade até fazer isso. >> >> Os setores que eu mapeei foram estes: >> http://www.openstreetmap.org/browse/relation/3351332 >> http://www.openstreetmap.org/browse/relation/3351331 >> http://www.openstreetmap.org/browse/relation/3351334 >> http://www.openstreetmap.org/browse/relation/3351330 >> http://www.openstreetmap.org/browse/relation/3351333 >> >> Resolvi mapear os "blocos" desses setores como edifícios (já que são >> construções contíguas e planejadas), mas nada impede que sejam >> convertidas em áreas de varejo (landuse=retail) com cada loja mapeada >> como um edifício separadamente. Por causa do formato do endereçamento >> usado em Brasília, resolvi atribuir o nome do setor à tag addr:street >> e o bloco a addr:housenumber. Lojas seriam especificadas então na tag >> addr:housename. Exemplo: >> http://www.openstreetmap.org/browse/way/249118664 >> >> Por uns poucos minutos, a busca do Nominatim funcionou como eu queria >> - busquei algumas vezes por coisas do tipo "sclrn 708 bloco f >> brasília" (mesmo formato de endereçamento usado por vários >> estabelecimentos em Brasília) e o Nominatim encontrava o bloco >> correto. Mas depois de um tempo parou de funcionar. Agora ele está >> reportando que encontrou esse lugar (inclusive com esse endereço >> exato), mas aponta para a geometria do "scrn 708 bloco f" (notem que >> falta o "L" na sigla). Isso deve ser um bug do Nominatim, pretendo >> reportar depois. Enquanto isso, vou fazer uns testes. >> >> -- >> 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 > -- 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