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

Fernando Trebien fernando.trebien em gmail.com
Domingo Dezembro 1 22:13:44 UTC 2013


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)



Mais detalhes sobre a lista de discussão Talk-br