Ah, se forem testar isso, reparem que a interface nova do OSM não está mostrando endereços interpolados direito (sempre joga pra um dos extremos). Testem com o OSRM, que está pegando a posição certa.
2013/12/1 Fernando Trebien <[email protected]>: > 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 <[email protected]>: >> Ó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" <[email protected]> >> 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 >>> [email protected] >>> https://lists.openstreetmap.org/listinfo/talk-br >> >> >> _______________________________________________ >> Talk-br mailing list >> [email protected] >> 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 [email protected] https://lists.openstreetmap.org/listinfo/talk-br
