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) -- 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