[Talk-br] Endereçamento com interpoladores

Fernando Trebien fernando.trebien em gmail.com
Sexta Julho 26 15:43:10 UTC 2013


Arlindo, para otimização da base de dados, acho melhor mesmo ter uma
via só. Mas daí usaríamos a tag "addr:inclusion=potential" ? Ou tanto
faz? (Sugeri isso só pra indicar que os números no interior do
cruzamento podem não existir, pro usuário faz pouca diferença.)

Adaptei os interpoladores que eu tinha colocado no mapa:
http://openstreetmap.org/?lat=-30.050652&lon=-51.225083&zoom=18&layers=M

O que você acha? Adicionamos aquela tag addr:inclusion, ou deixamos sem?

Roger, se você quiser olhar como eu fiz o interpolador para tentar
replicar a estrutura no seu, as linhas ficaram assim:
http://www.openstreetmap.org/browse/way/229632046
http://www.openstreetmap.org/browse/way/229632047

Clique em qualquer nó nessas listas para ver como ficaram os nós.
Repare especialmente nas tags que vão na linha e nas que vão nos nós.

Se você pesquisar por "701 rua general caldwell poa" ele retorna um
resultado interpolado como se esperaria.

("poa" = "porto alegre" porque eu adicionei esse valor na tag
"loc_name" no nó que representa a cidade. De fato, muitas pessoas aqui
se referem à cidade dessa forma, e vários nomes de produtos - como o
BikePoa - o usam também. Só a imprensa que não usa.)

Por causa dessa limitação do Nominatim (aquela validação de
"sanidade"), pode ser uma "boa idéia" (mas não é obrigatório) quebrar
os interpoladores nos trechos em que há uma variação muito brusca na
numeração.

2013/7/26 Arlindo Pereira <openstreetmap em arlindopereira.com>:
> Hm, mas aí isso envolveria ter de quebrar as vias em muitos pedaços. Nesse
> caso, não seria melhor ter uma só via? Dessa forma, os números das esquinas
> seriam corretos, e os interpolados entre os cruzamentos se localizariam
> nestes.
>
> []s
>
>
> 2013/7/26 Fernando Trebien <fernando.trebien em gmail.com>
>>
>> Acho que é isso sim. Só pra não ter dúvidas: o número 80 não seria um
>> nó, seria o número interpolado, certo? Os únicos nós seriam o 72 e o
>> 88, um de cada lado da via transversal, ambos próximos do cruzamento,
>> e o tracejado (-------) seria o interpolador conectando os dois, com a
>> tag addr:inclusion=potential.
>>
>> 2013/7/26 Arlindo Pereira <openstreetmap em arlindopereira.com>:
>> > Só para ver se eu entendi direito, teríamos então uma via com os números
>> > reais de endereçamento na ponta dos quarteirões e, entre eles, isto é,
>> > "embaixo" da rua transversal teríamos a média entre esses números?
>> >
>> > Por exemplo: 72-----|80|-----88
>> >
>> > Se for isso mesmo, com uma tag específica para esses casos, acho que
>> > estou
>> > de acordo.
>> >
>> > []s
>> >
>> > Em 26/07/2013 10:38, "Fernando Trebien" <fernando.trebien em gmail.com>
>> > escreveu:
>> >
>> >> Eu sabia que deveria ter feito a rua 4 e a rua 5 no exemplo. :P
>> >>
>> >> Não tenho dúvidas de que é estritamente errado. Aliás, estritamente,
>> >> os interpoladores são errados, pois produzem vários números
>> >> interpolados que não existem na realidade. Tomando como exemplo as
>> >> quadras de Buenos Aires de 100m de comprimento e com intervalo de
>> >> numeração de 100 números: se houver 20 prédios em cada quadra (10 de
>> >> cada lado da via), 80% dos números interpolados não existirão.
>> >>
>> >> Se são errados, por que são usados? Porque são úteis. A minha questão
>> >> é se é útil ao usuário final saber que existe o "buraco" na numeração
>> >> ou se é mais útil obter uma aproximação sempre que possível. Todos os
>> >> outros mapas que eu conheço (particularmente os dois melhores, Google
>> >> Maps e Nokia HERE Maps) não têm esses buracos. O meu receio é que um
>> >> usuário, ao se deparar com um buraco desses, considere o OSM como um
>> >> sistema inferior.
>> >>
>> >> Mas então, a rua 4 e a rua 5 seriam variações da rua 2, com uma
>> >> modificação: estenderíamos a linha interpoladora através do
>> >> cruzamento, passando pela via transversal. Na rua 4 a ligação entre os
>> >> números de cada lado seria simplesmente uma linha reta. A rua 5 é o
>> >> exemplo de como eu fiz em Porto Alegre, onde essa extensão passaria
>> >> necessariamente pelo nó central do cruzamento. Acho que a rua 4 seria
>> >> o melhor equilíbrio entre o útil e o estritamente correto.
>> >>
>> >> A rua 4 então modificaria a rua 2 acrecentando interpoladores (linhas
>> >> retas) entre os números: 18 e 24, 15 e 27, 52 e 64, 69 e 63.
>> >>
>> >> O resultado: os números exatos são renderizados, e posições
>> >> aproximadas são obtidas para todo o intervalo da numeração.
>> >>
>> >> Para completar, essas extensões que passam pelo cruzamento poderiam
>> >> receber a tag "addr:inclusion=potential". Que tal?
>> >>
>> >> 2013/7/25 Arlindo Pereira <openstreetmap em arlindopereira.com>:
>> >> > O método 3 me parece estritamente errado. Os endereços não existem,
>> >> > ponto.
>> >> > Adicioná-los me parece, usando uma gíria carioca, "forçação de barra"
>> >> > para
>> >> > evitar uma falha/bug/feature do buscador. Uma espécie de "tag for the
>> >> > renderer".
>> >> >
>> >> > []s
>> >> >
>> >> >
>> >> > 2013/7/25 Fernando Trebien <fernando.trebien em gmail.com>
>> >> >>
>> >> >> Uma imagem vale mais do que mil palavras, então só pra explicar
>> >> >> melhor: http://i.imgur.com/uwNSCWA.png
>> >> >>
>> >> >> Ignorem os pontos e as cruzes amarelas (não me aventurei a descobrir
>> >> >> uma forma de escondê-las).
>> >> >>
>> >> >> A rua 1 está feita com o método mais simples. Serve bem para as ruas
>> >> >> onde a numeração obedeceu a regra da distância desde o início da
>> >> >> rua.
>> >> >> Tem a eventual desvantagem de, em alguns casos, gerar coordenadas
>> >> >> que
>> >> >> são mais próximas de uma das vias transversais do que da via
>> >> >> principal.
>> >> >>
>> >> >> A rua 2 está feita da forma que eu observei no RJ. É a mais
>> >> >> estritamente correta, mas se alguém procurar por um número que
>> >> >> cairia
>> >> >> dentro do cruzamento, nenhum resultado é encontrado.
>> >> >>
>> >> >> A rua 3 está feita da forma que eu observei em Buenos Aires. Notem
>> >> >> que
>> >> >> na rua mais à direita a numeração original foi preservada por causa
>> >> >> da
>> >> >> grande diferença de numeração entre os dois lados. Não é tão
>> >> >> correta,
>> >> >> mas a interpolação (por ser uma aproximação) também não é, e teria a
>> >> >> vantagem de sempre chegar a uma posição aproximada (mesmo que o
>> >> >> endereço não exista, ou seja um endereço novo ainda não mapeado,
>> >> >> etc.). Penso que seja a melhor para conversores e importações
>> >> >> automáticas, a menos que se tenha certeza do cuidado que tiveram com
>> >> >> a
>> >> >> numeração.
>> >> >>
>> >> >> Claro que todas esses métodos também servem para 1 único
>> >> >> interpolador
>> >> >> ao invés de 2 (um para cada lado).
>> >> >>
>> >> >> Se alguém quiser o arquivo original para modificar e fazer seus
>> >> >> próprios exemplos: http://db.tt/vtIIhLjG
>> >> >>
>> >> >> O que eu fiz em Porto Alegre não é nenhum desses 3 métodos :P Seria
>> >> >> basicamente um misto da rua 2 com a rua 1 passando a linha do
>> >> >> interpolador pelo meio do cruzamento sempre. Mas estou tendendo mais
>> >> >> ao método da rua 3 agora.
>> >> >>
>> >> >> 2013/7/25 Fernando Trebien <fernando.trebien em gmail.com>:
>> >> >> > Acho que não foi ainda bem estabelecida a forma mais "correta" de
>> >> >> > usar
>> >> >> > os interpoladores. Para o Nominatim e para o meu GPS (MapFactor
>> >> >> > Navigator) basta:
>> >> >> > - addr:interpolation na linha (o interpolador) que acompanha via
>> >> >> > principal pela lateral
>> >> >> > - addr:housenumber em alguns dos nós ao longo dessa linha, sempre
>> >> >> > acompanhado de addr:street com o valor correto (os nós sem número
>> >> >> > servem apenas para definir o contorno do interpolador e gerar
>> >> >> > coordenadas nos lugares certos, algo importante em curvas)
>> >> >> >
>> >> >> > Colocar addr:street na linha me pareceu o jeito mais natural desde
>> >> >> > o
>> >> >> > começo, mas acabei descobrindo que não é necessário. Por outro
>> >> >> > lado,
>> >> >> > repetir esse mesmo valor em cada nó com numeração me parece uma
>> >> >> > tremenda redundância de informação... não faço idéia do que a
>> >> >> > comunidade tinha em mente quando decidiram fazer assim.
>> >> >> >
>> >> >> > 2013/7/25 Arlindo Pereira <openstreetmap em arlindopereira.com>:
>> >> >> >> O que eu tenho feito é mapear vias com addr:street=[nome da rua]
>> >> >> >> e
>> >> >> >> addr:interpolation:[odd|even], com seus nós tendo
>> >> >> >> addr:street=[nome
>> >> >> >> da
>> >> >> >> rua]
>> >> >> >> (de novo) e addr:housenumber=[numero], uma para cada quarteirão.
>> >> >> >>
>> >> >> >> Por exemplo: Procurem por Rua Bento Lisboa, 60.
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> http://openstreetmap.org/?lat=-22.926233&lon=-43.179654&zoom=18&layers=M
>> >> >> >>
>> >> >> >> Nesse exemplo, os números dos prédios na Rua Bento Lisboa antes e
>> >> >> >> depois da
>> >> >> >> Rua Tavares Bastos são 72 e 96. Dessa forma, procurando antes ou
>> >> >> >> depois
>> >> >> >> de
>> >> >> >> qualquer um desses números a interpolação funciona, mas entre os
>> >> >> >> dois
>> >> >> >> não,
>> >> >> >> pois de fato não há casas com este endereço.
>> >> >> >>
>> >> >> >> Não sei se é a forma mais correta, mas funciona. =)
>> >> >> >>
>> >> >> >> []s
>> >> >> >> Arlindo "Nighto" Pereira
>> >> >> >>
>> >> >> >> 2013/7/25 Roger C. Soares <rogersoares em gmail.com>
>> >> >> >>>
>> >> >> >>> Deveria. Na minha opinião não seria necessário nem um way com
>> >> >> >>> addr:interpolation, o engine deveria saber pegar os nros com o
>> >> >> >>> mesmo
>> >> >> >>> addr:street e interpolar segundo as regras de uma área que
>> >> >> >>> contém a
>> >> >> >>> rua, o
>> >> >> >>> país por exemplo.
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> Mas o wiki define que interpolação tem que ter um way e talvez
>> >> >> >>> seja
>> >> >> >>> até pq
>> >> >> >>> a minha idéia não funcione para o mundo todo. A minha dúvida é:
>> >> >> >>> Como
>> >> >> >>> se
>> >> >> >>> mapeia a interpolação de forma contínua para a rua toda?
>> >> >> >>>
>> >> >> >>> Eu tenho colocado os nros conforme eu vou encontrando e ligando
>> >> >> >>> com
>> >> >> >>> addr:interpolation, me parece lógico. Segundo o comportamento do
>> >> >> >>> Nominatim
>> >> >> >>> descrito pelo Fernando, o que eu estou fazendo não funciona, e
>> >> >> >>> na
>> >> >> >>> prática
>> >> >> >>> realmente não funciona (sempre). Agora, isso é bug ou feature do
>> >> >> >>> Nominatim?
>> >> >> >>> Quem decide? Tem outro jeito correto para mapear? É correto
>> >> >> >>> manter
>> >> >> >>> a
>> >> >> >>> interpolação e tb numerar o contorno da construção? Muitas
>> >> >> >>> perguntas?
>> >> >> >>> :)
>> >> >> >>>
>> >> >> >>> Atenciosamente,
>> >> >> >>> Roger.
>> >> >> >>>
>> >> >> >>> --
>> >> >> >>> Gerald Weber escreveu:
>> >> >> >>>
>> >> >> >>> Oi Pessoal
>> >> >> >>>
>> >> >> >>> Ao pensar nesta idéia de interpolação: isto não deveria ser
>> >> >> >>> tarefa
>> >> >> >>> do
>> >> >> >>> renderizador?
>> >> >> >>>
>> >> >> >>> Quer dizer, faz sentido popular a base de dados com informações
>> >> >> >>> hipotéticas?
>> >> >> >>>
>> >> >> >>> Abraços
>> >> >> >>>
>> >> >> >>> Gerald
>> >> >> >>>
>> >> >> >>> ________________________________
>> >> >> >>> _______________________________________________
>> >> >> >>> Talk-br mailing list
>> >> >> >>> Talk-br em openstreetmap.org
>> >> >> >>> http://lists.openstreetmap.org/listinfo/talk-br
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> _______________________________________________
>> >> >> >>> Talk-br mailing list
>> >> >> >>> Talk-br em openstreetmap.org
>> >> >> >>> http://lists.openstreetmap.org/listinfo/talk-br
>> >> >> >>>
>> >> >> >>
>> >> >> >>
>> >> >> >> _______________________________________________
>> >> >> >> Talk-br mailing list
>> >> >> >> Talk-br em 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)
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> 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
>> >> >> http://lists.openstreetmap.org/listinfo/talk-br
>> >> >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > Talk-br mailing list
>> >> > Talk-br em 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 em openstreetmap.org
>> >> http://lists.openstreetmap.org/listinfo/talk-br
>> >
>> >
>> > _______________________________________________
>> > Talk-br mailing list
>> > Talk-br em 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 em openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-br
>
>
>
> _______________________________________________
> Talk-br mailing list
> Talk-br em 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)



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