[Talk-br] Endereçamento com interpoladores

Terça Julho 30 22:18:38 UTC 2013

Hm olha só, o Nominatim não está gerando os números de 555 a 1855, mas
os outros sim. Já criei um ticket descrevendo essa situação
(https://trac.openstreetmap.org/ticket/4925), então peço pra você não
alterar o interpolador até que eles investiguem. (Da última vez,
demoraram umas 2 semanas para me dar uma resposta.)

2013/7/30 Fernando Trebien <fernando.trebien em gmail.com>:
> Eu já vi alguém descrevendo alguma situação parecida no TRAC do
> Nominatim, acho que é um bug conhecido (e até acho que já aconteceu
> comigo, mas como alterei mais coisas de uma vez só, não tive certeza).
> De qualquer forma, estava tão certo o jeito que você fez antes quanto
> está agora quanto estava quando quebrado em 3 partes (só um pouquinho
> menos eficiente). Era pra funcionar em todas essas situações.
>
> Também já passei por casos em que o Nominatim demorou pra atualizar,
> então eu sugiro que você olhe 1 dia depois da alteração pra confirmar
> que continua funcionando. Se sim, me avisa que eu abro o bug. De
> qualquer forma, sugeriria deixar como está até que eles olhem o
> problema e, se não consertarem, daí quebrar em 3 partes de novo (ruim,
> mas podemos fazer muito pouco, a menos que criemos um serviço
> alternativo ao Nominatim).
>
> 2013/7/30 Roger C. Soares <rogersoares em gmail.com>:
>> Recaptulando, Rua Campos Salles, Ribeirão Preto,
>>
>> No início nenhum nro aparecia nas buscas:
>> 555|------------1855--------------|2089 (1 way)
>>
>> Depois adicionei o nro 2005 na interpolação e continuou não retornando nros
>> nas buscas:
>> 555|------------1855-------2005-----|2089 (1 way)
>>
>> Depois apenas quebrei a interpolação em 3 caminhos, de 1855 a 2089 começou a
>> funcionar:
>> 555|------------|1855|-------|2005|-----|2089 (3 ways)
>>
>> E por último combinei o caminho da interpolação em 1 novamente, e de 1855 a
>> 2089 continuou funcionando:
>> 555|------------1855-------2005-----|2089 (1 way)
>>
>> Eu não vou abrir bug por enquanto, mas se vc quiser abrir manda ver. Capaz
>> que exista alguma limitação de tamanho mesmo, na av independência tem uma
>> interpolação que vai de 1500 a 2514 que tb não funciona. Talvez como ela já
>> foi indexada, se eu colocar outros nros no meio não seja suficiente para
>> reindexar, teria que apagar o caminho e criar um novo...
>>
>> Atenciosamente,
>> Roger.
>>
>> --
>>
>> Fernando Trebien escreveu:
>>
>> Agora entendi. Bem, deixar os terminais vazios não faria muito
>> sentido. Nesse caso o melhor ou é dar um número aproximado ou colocar
>> os terminais com uma tag "fixme" pedindo para alguém avaliar o melhor
>> número. Eu tenho esse costume em Porto Alegre: vou marcando várias
>> coisas com fixme, depois tiro 1 dia pra fazer inspeção e resolver as
>> dúvidas. Tem funcionado muito bem.
>>
>> Agora sinceramente não sei por que os seus interpoladores não
>> funcionam, tudo me parece correto. Uma sugestão: tente quebrá-los em
>> algum ponto (digamos, na metade) e veja se alguma coisa muda (se um
>> dos lados passa a funcionar, ou ambos). Se mudar, sugiro que você
>> desfaça a sua alteração, verifique que parou de funcionar de novo, e
>> daí abra um ticket no TRAC do Nominatim (se você quiser posso fazer
>> isso) relatando o problema: https://trac.openstreetmap.org
>>
>> 2013/7/27 Roger C. Soares <rogersoares em gmail.com>:
>>
>>
>> Nesse meu comentário eu estava pensando nos nós terminais vazios:
>>
>>   []_________[20]_________[40]_________[]
>>  /                                       \
>> []-----------highway---------------------[]
>>
>> Até um tempo atrás eu imaginava que ele pudesse tirar uma média e calcular
>> que o primeiro nó é próximo do 0 e o último próximo do 60. Assim, se alguém
>> buscasse por 10 ou 50 um ponto na rua seria retornado, mesmo a casa 20 sendo
>> a primeira e a 40 a última.
>>
>> Quanto a rejeitar apenas o intervalo que não passou na validação, vc tem
>> razão. Percebi agora que um dos exemplos que eu estava usando tem um nro no
>> meio que está estragando a sequência. Acho que era um prédio em construção,
>> ou eu digitei errado ou eles colocaram um nro estranho, preciso voltar lá.
>>
>> Em Ribeirão Preto, na Quintino Bocaiúva, apesar do segundo intervalo não
>> retornar, o primeiro retorna, realmente boa notícia:
>> Rua Quintino Bocaiúva - de 9 a 275 (266 nros), 220m
>>
>> Já na campos salles, os 2 intervalos não retornam, apesar de terem menos
>> nros por metro que na quintino:
>> Rua Campos Salles - de 555 a 1855 (1300 nros), 1310m
>> Rua Campos Salles - de 1855 a 2089 (234 nros), 230m
>>
>> Talvez pq os nros estão muito distantes um do outro?
>>
>>
>> Atenciosamente,
>> Roger.
>>
>> --
>> Fernando Trebien escreveu:
>>
>> Olha, ele aceita nós sem número sim. Esses nós servem apenas para
>> fazer o interpolador acompanhar melhor as curvas da via principal.
>>
>> Veja este nó por exemplo:
>> http://www.openstreetmap.org/browse/node/2249544793
>>
>> Daí onde diz "Parte de", clique no link para ver o interpolador. Ele é
>> bem longo e cheio de nós, alguns com número, outros sem. Os sem número
>> ficam totalmente sem tags.
>>
>> Outro nó no mesmo interpolador (logo ao lado do anterior), mas com
>> número: http://www.openstreetmap.org/browse/node/2248442311
>>
>> Se você agora buscar por "avenida guaíba 10740 poa" vai encontrar um
>> resultado.
>>
>> Uma coisa interessante sobre esse interpolador (que diz algo sobre
>> como funciona o Nominatim) é que a verificação de sanidade rejeita o
>> primeiro intervalo, de 9894 a 10652, mas não rejeita os demais (boa
>> notícia). Nesse intervalo há uma diferença de 758 números em uma
>> distância de 92 metros.
>>
>> (Esse é o caso mais estranho de numeração em Porto Alegre. A rua foi
>> renumerada algumas vezes mas ninguém forçou a mudança, então há
>> algumas gerações de números intercaladas aí, por isso vários
>> interpoladores simultâneos. A numeração na fonte que eu vou importar
>> acompanha 1 dessas interpolações, acredito que seja a numeração
>> "oficial" - a que vai passar a valer ao longo do tempo. Acho que o
>> ideal nesse caso é usar interpoladores para a numeração oficial e
>> mapear cada casa separadamente, afinal seria uma exceção.)
>>
>> 2013/7/26 Roger C. Soares <rogersoares em gmail.com>:
>>
>>
>> Legal, é exatamente assim que eu tenho mapeado. Qdo o número é de um prédio
>> eu tb coloco o nome no addr:housename, pra quando alguém fizer o contorno
>> ter a informação lá.
>>
>> Eu dei uma olhada em algumas interpolações que eu fiz e qdo as distâncias
>> são próximas realmente estão funcionando legal. Como numeração pra mim não é
>> prioridade no momento eu coloco só algumas que eu fotografo, e as vezes eu
>> ligava um nro numa interpolação que estava funcionando e ela parava de
>> funcionar, ou vice-versa, provavelmente pq o nro coletado estava muito longe
>> dos outros ou eu colocava um nro intermediario que fazia passar na
>> validação. Um trecho que não passe na validação invalida a interpolação
>> toda... isso me confundiu, mas sabendo disso dá pra quebrar estrategicamente
>> algumas e com o tempo, conforme forem entrando mais números, as buscas devem
>> melhorar.
>>
>> O modo que vc usou em Porto Alegre eu tinha achado interessante para ligar o
>> início e talvez o final da interpolação na rua. Assim ficaria a metragem
>> inteira da rua coberta. A princípio eu preferia deixar o nó sem número, mas
>> pelo visto ele não gera um valor intermediário pra nós sem número, então
>> teria que ter um 0 como número do nó, talvez o mesmo nó para os dois lados
>> da rua... O que vocês acham? É útil ou ficaria muito poluído
>>
>>
>> Atenciosamente,
>> Roger.
>>
>> --
>> Fernando Trebien escreveu:
>>
>> 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
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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)