Postei essa informação lá. Começo a desconfiar que é por causa do tamanho do intervalo (mais de 1000 números), mas vamos aguardar a resposta deles.
2013/7/30 Roger C. Soares <rogersoa...@gmail.com>: > Ok, sem problema. > Só pra ser mais preciso, o intervalo de 555 a 1855 pra mim não funcionou em > nenhuma situação, qdo eu quebrei em 3 caminhos ficou exatamente como está > agora.. só retornava para o intervalo de 1855 a 2089. > > > Atenciosamente, > Roger. > > -- > Fernando Trebien escreveu: > > 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.treb...@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 <rogersoa...@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 <rogersoa...@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 <rogersoa...@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 <openstreet...@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.treb...@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 <openstreet...@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.treb...@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 <openstreet...@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.treb...@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.treb...@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 <openstreet...@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 <rogersoa...@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@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-br > > > > > _______________________________________________ > Talk-br mailing list > Talk-br@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-br > > > > _______________________________________________ > Talk-br mailing list > Talk-br@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@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-br > > > _______________________________________________ > Talk-br mailing list > Talk-br@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@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-br > > > _______________________________________________ > Talk-br mailing list > Talk-br@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@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-br > > > _______________________________________________ > Talk-br mailing list > Talk-br@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-br > > > > > > > > _______________________________________________ > Talk-br mailing list > Talk-br@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-br > > > > > > > > _______________________________________________ > Talk-br mailing list > Talk-br@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-br > > > > > > > > _______________________________________________ > Talk-br mailing list > Talk-br@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@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@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br