[Talk-br] Endereçamento em Brasília

[Fernando Trebien]

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 <fernando.trebien em gmail.com>:
> 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 <erickdeoliveiraleal em 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.trebien em 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 em openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-br
>>
>>
>> _______________________________________________
>> Talk-br mailing list
>> Talk-br em 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)