Pois é, faz um certo sentido pra eles porque nem todos os países seguem essa regra de numeração baseada na distância do início da via. Pra nós seria mais conveniente que essa regra não existisse. Mas fazer o quê?
Continuo achando que não está errado, mas é bom saber pra incluir um tratamento disso em scripts e conversores. 2013/7/31 Roger C. Soares <rogersoa...@gmail.com>: > E a resolução lá foi rápida :). É o tamanho mesmo, a distância tem que ser > menor que 1000m. Talvez o que dê pra melhorar é o fato de se adicionar um > número no meio e não reindexar. Depois eu coloco uns números no meio dessa e > da independência pra ver se alguma funciona sem ter que quebrar ou recriar a > interpolação... e por enquanto eu vou parar de conectar nros muito longes... > > > Atenciosamente, > Roger. > > -- > Fernando Trebien escreveu: > > 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 > > > > > > > > _______________________________________________ > 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
