|
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 |
_______________________________________________ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
