Re: [Talk-br] A importância de não quebrar a hierarquia das vias dentro de cidades.
Eu não tenho um Garmin, e a informação que eu tinha é que ele não faz busca por ponto de interesse (que seria uma opção mais fácil pra esse teste do que buscar por cruzamentos). On 24 Jul 2014 08:44, Paulo Carvalho paulo.r.m.carva...@gmail.com wrote: Sò uma observação quando tu disseste (requisito do geocoding do Garmin): Isso não é limitação da Garmin, mas sim dos mapas ou da compilação. Meu bairro está 100% numerado e o mapa Garmin dele no Cocar tem a numeração toda. Quem quiser estão aqui: http://www.cocardl.com.br/viewtopic.php?f=52t=139 A compilação deles é cortesia do Wesley Martins (não sei se ele participa desta lista). Há também os mapas do Brasil e América do Sul, cortesia do Márcio Thundercel: http://www.cocardl.com.br/viewtopic.php?f=52t=214 e http://www.cocardl.com.br/viewtopic.php?f=52t=215 Há ainda também o mapa diário de São Paulo, cortesia do Nelson (não sei que toolset ele usa): http://naoliv.iq.unesp.br/mapas/gmapsupp.img E ainda quem quiser, baixe os kits de compilação e compile seu próprio mapa Garmin: http://www.cocardl.com.br/viewtopic.php?f=23t=114 Em 20 de julho de 2014 22:00, Fernando Trebien fernando.treb...@gmail.com escreveu: Pessoal, O Aun se ofereceu pra ajudar testando com a compilação da garmin.openstreetmap.nl e pediu pra eu passar alguns endereços (pra ficar fácil de testar). Vou postar alguém aqui também caso queiram testar com outras compilações. Cruzamentos (requisito do geocoding do Garmin): 1. Chuí, RS: Rua Chile X Rua Palestina 2. Osório, RS: Rua Garibaldi X Rua Melvin Jones 3. Joinville, SC: Rua Nazareno X Rua Benjamin Constant 4. Atibaia, SP: Rua Belvedere X Rua Presidente Dutra 5. Belo Horizonte, MG: Rua Tom Jobim X Fua Ferreira 6. Teófilo Otoni, MG: Rua Coronel Ramos X Rua Dom Felipe 7. Vitória da Conquista, BA: Rua Nova X Rua Deusdete Amaral 8. Feira de Santana, BA: Rua Brumado X Rua Juazeiro 9. Brejo Santo, CE: Rua Marcelino Costa X Rua Joaquim Nicodemos 10. Fortaleza, CE: Rua Pentecoste X Rua Costa Barros Procedimento sugerido pra economizar trabalho testando: - testar rota de [1] a [10]; se funcionar é porque há algum problema com a compilação do mapa que não há na compilação do osm.nl - testar [1] a [6]; se não funcionar, testar [1] a [2], [2] a [3], etc. - se funcionar, testar [6] a [10]; se não funcionar, testar [6] a [7], [7] a [8], etc. Se identificarem o trecho em que o roteamento falha, me avisem que eu mando o próximo conjunto de pontos (que então deve nos levar ao ponto exato do problema). Não mandei agora porque senão teria que sugerir 100 pontos. 2014-07-20 20:05 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Ok, entendido. Obrigado pelas sugestões. []s Paulo Em 20 de julho de 2014 15:17, Fernando Trebien fernando.treb...@gmail.com escreveu: Acho razoável se basear na rota do OSRM pra elencar um ponto mais ou menos mais ou menos no meio 2014-07-20 15:16 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Uma sugestão para diminuir o espaço de busca: dividir para conquistar. Ao invés de calcular uma rota tão longa, tente calcular a rota até metade do caminho, e depois da metade até o destino. (Não precisa ser exatamente a metade, qualquer ponto mais ou menos no meio serve.) O problema vai estar no trecho em que esse teste falhar. Daí você pega o trecho problemático e repete: testa a primeira metade dele, depois a segunda metade. Cada vez que você repete você diminui o espaço de busca. São 3000km, dividindo por 2 a cada vez você provavelmente vai chegar à raiz exata do problema em menos de 20 tentativas. Como saber onde fica a metade? Acho razoável se basear na rota do OSRM pra elencar um ponto mais ou menos: http://osrm.at/8yC Um complicador é que pode ter mais de um problema ao longo de toda essa rota. Se os dois trechos falharem, você vai ter que testar os dois trechos separadamente, ao invés de eliminar um deles. E se forem muitos os problemas, pode precisar de papel e caneta pra lembrar de quais trechos você já testou. É bem provável que isso seja de fato um erro de classificação que precisa ser corrigido no OSM - não com o objetivo específico de fazer o Garmin funcionar, mas sim com o objetivo de deixar a classificação correta. Sim, aplicações mais simples podem ser usadas (e normalmente são uma forma excelente) para detectar problemas com os dados que não interferem tanto com as aplicações mais modernas. E nesse caso específico tanto a comunidade do OSM (agnóstica aos dispositivos) quanto os usuários de Garmin saem ganhando. 2014-07-20 12:47 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Temos um exemplo de um mapa Garmin que não está calculando uma rota entre o extremo sul do Brasil e um ponto no Ceará. A rota é calculada normalmente no Mapsource (computador) mas não no GPS (dipositivo móvel). O problema é
Re: [Talk-br] A importância de não quebrar a hierarquia das vias dentro de cidades.
Bem, não vamos fugir do assunto original, eu só mencionei a limitação do Garmin porque achei que usar um POI ao invés de um nome de rua facilitaria o teste que eu sugeri. Não era uma crítica ao Garmin, mas eu realmente acho estranho que não se possa fazer com ele algo que eu fazia/faço com todos os outros GPSs que eu já usei: buscar por POIs dentro de uma cidade sem estar fisicamente próximo dela. 2014-07-24 11:41 GMT-03:00 Aun Johnsen li...@gimnechiske.org: Fernando Concegui busca por POI, mas alem do ~85 km (tenque verificar) somente pelo nome, e se ha mais que um com mesma nome so retorna o mais perto (pelo menus no meu Nüvi 50), ele nao busco pelo nome proximente, alas Guanabara nao vai retornar Windsor Guanabara, mas Windsor G pode da certo Aun Johnsen Sent from my iPhone On 24. juli 2014, at 11:06, Fernando Trebien fernando.treb...@gmail.com wrote: Eu não tenho um Garmin, e a informação que eu tinha é que ele não faz busca por ponto de interesse (que seria uma opção mais fácil pra esse teste do que buscar por cruzamentos). On 24 Jul 2014 08:44, Paulo Carvalho paulo.r.m.carva...@gmail.com wrote: Sò uma observação quando tu disseste (requisito do geocoding do Garmin): Isso não é limitação da Garmin, mas sim dos mapas ou da compilação. Meu bairro está 100% numerado e o mapa Garmin dele no Cocar tem a numeração toda. Quem quiser estão aqui: http://www.cocardl.com.br/viewtopic.php?f=52t=139 A compilação deles é cortesia do Wesley Martins (não sei se ele participa desta lista). Há também os mapas do Brasil e América do Sul, cortesia do Márcio Thundercel: http://www.cocardl.com.br/viewtopic.php?f=52t=214 e http://www.cocardl.com.br/viewtopic.php?f=52t=215 Há ainda também o mapa diário de São Paulo, cortesia do Nelson (não sei que toolset ele usa): http://naoliv.iq.unesp.br/mapas/gmapsupp.img E ainda quem quiser, baixe os kits de compilação e compile seu próprio mapa Garmin: http://www.cocardl.com.br/viewtopic.php?f=23t=114 Em 20 de julho de 2014 22:00, Fernando Trebien fernando.treb...@gmail.com escreveu: Pessoal, O Aun se ofereceu pra ajudar testando com a compilação da garmin.openstreetmap.nl e pediu pra eu passar alguns endereços (pra ficar fácil de testar). Vou postar alguém aqui também caso queiram testar com outras compilações. Cruzamentos (requisito do geocoding do Garmin): 1. Chuí, RS: Rua Chile X Rua Palestina 2. Osório, RS: Rua Garibaldi X Rua Melvin Jones 3. Joinville, SC: Rua Nazareno X Rua Benjamin Constant 4. Atibaia, SP: Rua Belvedere X Rua Presidente Dutra 5. Belo Horizonte, MG: Rua Tom Jobim X Fua Ferreira 6. Teófilo Otoni, MG: Rua Coronel Ramos X Rua Dom Felipe 7. Vitória da Conquista, BA: Rua Nova X Rua Deusdete Amaral 8. Feira de Santana, BA: Rua Brumado X Rua Juazeiro 9. Brejo Santo, CE: Rua Marcelino Costa X Rua Joaquim Nicodemos 10. Fortaleza, CE: Rua Pentecoste X Rua Costa Barros Procedimento sugerido pra economizar trabalho testando: - testar rota de [1] a [10]; se funcionar é porque há algum problema com a compilação do mapa que não há na compilação do osm.nl - testar [1] a [6]; se não funcionar, testar [1] a [2], [2] a [3], etc. - se funcionar, testar [6] a [10]; se não funcionar, testar [6] a [7], [7] a [8], etc. Se identificarem o trecho em que o roteamento falha, me avisem que eu mando o próximo conjunto de pontos (que então deve nos levar ao ponto exato do problema). Não mandei agora porque senão teria que sugerir 100 pontos. 2014-07-20 20:05 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Ok, entendido. Obrigado pelas sugestões. []s Paulo Em 20 de julho de 2014 15:17, Fernando Trebien fernando.treb...@gmail.com escreveu: Acho razoável se basear na rota do OSRM pra elencar um ponto mais ou menos mais ou menos no meio 2014-07-20 15:16 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Uma sugestão para diminuir o espaço de busca: dividir para conquistar. Ao invés de calcular uma rota tão longa, tente calcular a rota até metade do caminho, e depois da metade até o destino. (Não precisa ser exatamente a metade, qualquer ponto mais ou menos no meio serve.) O problema vai estar no trecho em que esse teste falhar. Daí você pega o trecho problemático e repete: testa a primeira metade dele, depois a segunda metade. Cada vez que você repete você diminui o espaço de busca. São 3000km, dividindo por 2 a cada vez você provavelmente vai chegar à raiz exata do problema em menos de 20 tentativas. Como saber onde fica a metade? Acho razoável se basear na rota do OSRM pra elencar um ponto mais ou menos: http://osrm.at/8yC Um complicador é que pode ter mais de um problema ao longo de toda essa rota. Se os dois trechos falharem, você vai ter que testar os dois trechos separadamente, ao invés de eliminar um deles. E se forem muitos os problemas, pode precisar de papel e caneta pra lembrar de
Re: [Talk-br] A importância de não quebrar a hierarquia das vias dentro de cidades.
Fernando, bem Nuvi 50 e um modelo antiga, nao tem modelo mais recente, ver que Garmin Nüvi 53 vender por 399 no Lojas Americanas Aun Johnsen Sent from my iPhone On 24. juli 2014, at 12:28, Fernando Trebien fernando.treb...@gmail.com wrote: Bem, não vamos fugir do assunto original, eu só mencionei a limitação do Garmin porque achei que usar um POI ao invés de um nome de rua facilitaria o teste que eu sugeri. Não era uma crítica ao Garmin, mas eu realmente acho estranho que não se possa fazer com ele algo que eu fazia/faço com todos os outros GPSs que eu já usei: buscar por POIs dentro de uma cidade sem estar fisicamente próximo dela. 2014-07-24 11:41 GMT-03:00 Aun Johnsen li...@gimnechiske.org: Fernando Concegui busca por POI, mas alem do ~85 km (tenque verificar) somente pelo nome, e se ha mais que um com mesma nome so retorna o mais perto (pelo menus no meu Nüvi 50), ele nao busco pelo nome proximente, alas Guanabara nao vai retornar Windsor Guanabara, mas Windsor G pode da certo Aun Johnsen Sent from my iPhone On 24. juli 2014, at 11:06, Fernando Trebien fernando.treb...@gmail.com wrote: Eu não tenho um Garmin, e a informação que eu tinha é que ele não faz busca por ponto de interesse (que seria uma opção mais fácil pra esse teste do que buscar por cruzamentos). On 24 Jul 2014 08:44, Paulo Carvalho paulo.r.m.carva...@gmail.com wrote: Sò uma observação quando tu disseste (requisito do geocoding do Garmin): Isso não é limitação da Garmin, mas sim dos mapas ou da compilação. Meu bairro está 100% numerado e o mapa Garmin dele no Cocar tem a numeração toda. Quem quiser estão aqui: http://www.cocardl.com.br/viewtopic.php?f=52t=139 A compilação deles é cortesia do Wesley Martins (não sei se ele participa desta lista). Há também os mapas do Brasil e América do Sul, cortesia do Márcio Thundercel: http://www.cocardl.com.br/viewtopic.php?f=52t=214 e http://www.cocardl.com.br/viewtopic.php?f=52t=215 Há ainda também o mapa diário de São Paulo, cortesia do Nelson (não sei que toolset ele usa): http://naoliv.iq.unesp.br/mapas/gmapsupp.img E ainda quem quiser, baixe os kits de compilação e compile seu próprio mapa Garmin: http://www.cocardl.com.br/viewtopic.php?f=23t=114 Em 20 de julho de 2014 22:00, Fernando Trebien fernando.treb...@gmail.com escreveu: Pessoal, O Aun se ofereceu pra ajudar testando com a compilação da garmin.openstreetmap.nl e pediu pra eu passar alguns endereços (pra ficar fácil de testar). Vou postar alguém aqui também caso queiram testar com outras compilações. Cruzamentos (requisito do geocoding do Garmin): 1. Chuí, RS: Rua Chile X Rua Palestina 2. Osório, RS: Rua Garibaldi X Rua Melvin Jones 3. Joinville, SC: Rua Nazareno X Rua Benjamin Constant 4. Atibaia, SP: Rua Belvedere X Rua Presidente Dutra 5. Belo Horizonte, MG: Rua Tom Jobim X Fua Ferreira 6. Teófilo Otoni, MG: Rua Coronel Ramos X Rua Dom Felipe 7. Vitória da Conquista, BA: Rua Nova X Rua Deusdete Amaral 8. Feira de Santana, BA: Rua Brumado X Rua Juazeiro 9. Brejo Santo, CE: Rua Marcelino Costa X Rua Joaquim Nicodemos 10. Fortaleza, CE: Rua Pentecoste X Rua Costa Barros Procedimento sugerido pra economizar trabalho testando: - testar rota de [1] a [10]; se funcionar é porque há algum problema com a compilação do mapa que não há na compilação do osm.nl - testar [1] a [6]; se não funcionar, testar [1] a [2], [2] a [3], etc. - se funcionar, testar [6] a [10]; se não funcionar, testar [6] a [7], [7] a [8], etc. Se identificarem o trecho em que o roteamento falha, me avisem que eu mando o próximo conjunto de pontos (que então deve nos levar ao ponto exato do problema). Não mandei agora porque senão teria que sugerir 100 pontos. 2014-07-20 20:05 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Ok, entendido. Obrigado pelas sugestões. []s Paulo Em 20 de julho de 2014 15:17, Fernando Trebien fernando.treb...@gmail.com escreveu: Acho razoável se basear na rota do OSRM pra elencar um ponto mais ou menos mais ou menos no meio 2014-07-20 15:16 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Uma sugestão para diminuir o espaço de busca: dividir para conquistar. Ao invés de calcular uma rota tão longa, tente calcular a rota até metade do caminho, e depois da metade até o destino. (Não precisa ser exatamente a metade, qualquer ponto mais ou menos no meio serve.) O problema vai estar no trecho em que esse teste falhar. Daí você pega o trecho problemático e repete: testa a primeira metade dele, depois a segunda metade. Cada vez que você repete você diminui o espaço de busca. São 3000km, dividindo por 2 a cada vez você provavelmente vai chegar à raiz exata do problema em menos de 20 tentativas. Como saber onde fica a metade? Acho razoável se basear na rota do OSRM pra elencar um ponto mais ou menos: http://osrm.at/8yC Um complicador é que pode ter mais de um problema ao longo de
Re: [Talk-br] A importância de não quebrar a hierarquia das vias dentro de cidades.
Temos um exemplo de um mapa Garmin que não está calculando uma rota entre o extremo sul do Brasil e um ponto no Ceará. A rota é calculada normalmente no Mapsource (computador) mas não no GPS (dipositivo móvel). O problema é justamente localizar onde está a interrupção ou alternância de classificação de vias nos mais de 3000km da rota. Em 20 de julho de 2014 12:05, Fernando Trebien fernando.treb...@gmail.com escreveu: Contraction hierarquies permite usar Dijkstra bidirecional + alguma heurística otimista em ambientes com restrições de memória e capacidade computacional sem remover qualquer via do cálculo. Isso tá lá nos papers referenciados no final daquele artigo da Wikipédia que você apontou. Era a isso que eu me referia ao julgar a inteligência do algoritmo, e por ser um fato (o algoritmo foi publicado e nada impede que seja implementado), não tem como ser arrogante. É uma escolha simples (bem, não tão simples) que o desenvolvedor da aplicação tem que fazer. E é uma escolha que é independente do mapa (que, novamente, serve a vários propósitos, não só ao roteamento, não só ao roteamento em ambientes com capacidades limitadas). Mas interromper uma motorway com um trecho de residential vai quebrar o roteamento em muitas aplicações. Pode dar um exemplo de aplicação e local? Apesar de solicitar esse exemplo, não conheço nenhum caso em que uma motorway/trunk precisaria ter um trecho classificado como residencial. Na pior das hipóteses, teria um trecho classificado como terciária por estar não-pavimentada - mas acho que nem no Brasil essa situação ocorre. Recentemente eu achei um exemplo em que uma trunk se intercala com uma primária [1], mas isso também não deve afetar esses sistemas que descartam vias a que você se refere. E claro, no caso particular, raro, e bizarro de uma classificação fiel produzir uma situação assim, podemos pensar em discutir com a comunidade sobre o que fazer. A idéia de não alternar demais a classificação da via poderia ser aplicada ser for só um trecho curto com características diferentes, e o motivo não seria só o roteamento. [1] http://www.openstreetmap.org/#map=12/-29.5385/-51.8998 2014-07-20 10:47 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Em 19 de julho de 2014 22:29, Fernando Trebien fernando.treb...@gmail.com escreveu: Sabendo que há trabalhos cientificos publicados descrevendo bons algoritmos para esses ambientes e que não descartam quaisquer vias (mesmo as de classe bem inferior), acho que não devemos fazer adaptações no mapa em favor de algoritmos menos inteligentes. (Isso seria mapear para a aplicação.) Menos inteligentes Desculpa, Fernando, esse seu comentário foi um tanto arrogante. Quando você tem restrição de recursos de hardware em dispositivos móveis você TEM que fazer otimização. Isso para mim é sinal de extrema inteligência. E só uma palavra sobre artigos científicos: poucas vezes tratam-se de ideias praticáveis. O algoritmo Dijkstra é um exemplo. Ninguém usa a forma tal como publicada pelo Dijkstra originalmente. A indústria sempre faz várias melhorias para o mundo real. Sei disso porque trabalho nos dois mundos e também porque estou escrevendo um artigo e não estou pensando em problemas de ordem prática. A teoria já dá trabalho suficiente. Isso não é pecado, é como o progresso funciona: cada especialista em sua área. Mas, ao mesmo tempo, acho que são muito raros os casos em que adaptações seriam necessárias para evitar problemas com esses algoritmos que descartam vias. A menos que eles estejam descartando até as vias primárias (arteriais urbanas), daí não tem como resolver mesmo. Não são raros não. Você tem que pensar em para que a maioria dos usuários precisa de um mapa de ruas (Street Map): a) Encontrar um lugar (geocoding); b) Navegar até um lugar (roteamento); c) Quase sempre em trânsito, com dispositivos móveis. Se essas coisas não estão funcionando bem, elas procurarão alternativas e aí seu mapa será o mais puro do mundo mas vazio de propósito. Se queres que o mapa se torne popular, TEM que pensar nas questões de ordem prática. Acho que dá para conciliar os princípios do OSM com as questões práticas. Mas interromper uma motorway com um trecho de residential vai quebrar o roteamento em muitas aplicações. Não digo colocar tudo igual, mas não deixar as classes tão contrastantes conforme já exemplificado. []s Paulo 2014-07-19 17:56 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com : E qual sua opinião sobre o descarte de vias de baixa prioridade nos roteamentos de longa distância em ambientes com baixa memória e processamento mais lento? Em 19 de julho de 2014 12:58, Fernando Trebien fernando.treb...@gmail.com escreveu: Li sim, há bastante tempo. Mas acho que estás confundindo as hierarquias do OSM com a hierarquia de atalhos emergente
Re: [Talk-br] A importância de não quebrar a hierarquia das vias dentro de cidades.
Eu poder testar no meu Nüvi, usando mapas do garmin.openstreetmap.nl Aun Johnsen Sent from my iPhone On 20. juli 2014, at 12:47, Paulo Carvalho paulo.r.m.carva...@gmail.com wrote: Temos um exemplo de um mapa Garmin que não está calculando uma rota entre o extremo sul do Brasil e um ponto no Ceará. A rota é calculada normalmente no Mapsource (computador) mas não no GPS (dipositivo móvel). O problema é justamente localizar onde está a interrupção ou alternância de classificação de vias nos mais de 3000km da rota. Em 20 de julho de 2014 12:05, Fernando Trebien fernando.treb...@gmail.com escreveu: Contraction hierarquies permite usar Dijkstra bidirecional + alguma heurística otimista em ambientes com restrições de memória e capacidade computacional sem remover qualquer via do cálculo. Isso tá lá nos papers referenciados no final daquele artigo da Wikipédia que você apontou. Era a isso que eu me referia ao julgar a inteligência do algoritmo, e por ser um fato (o algoritmo foi publicado e nada impede que seja implementado), não tem como ser arrogante. É uma escolha simples (bem, não tão simples) que o desenvolvedor da aplicação tem que fazer. E é uma escolha que é independente do mapa (que, novamente, serve a vários propósitos, não só ao roteamento, não só ao roteamento em ambientes com capacidades limitadas). Mas interromper uma motorway com um trecho de residential vai quebrar o roteamento em muitas aplicações. Pode dar um exemplo de aplicação e local? Apesar de solicitar esse exemplo, não conheço nenhum caso em que uma motorway/trunk precisaria ter um trecho classificado como residencial. Na pior das hipóteses, teria um trecho classificado como terciária por estar não-pavimentada - mas acho que nem no Brasil essa situação ocorre. Recentemente eu achei um exemplo em que uma trunk se intercala com uma primária [1], mas isso também não deve afetar esses sistemas que descartam vias a que você se refere. E claro, no caso particular, raro, e bizarro de uma classificação fiel produzir uma situação assim, podemos pensar em discutir com a comunidade sobre o que fazer. A idéia de não alternar demais a classificação da via poderia ser aplicada ser for só um trecho curto com características diferentes, e o motivo não seria só o roteamento. [1] http://www.openstreetmap.org/#map=12/-29.5385/-51.8998 2014-07-20 10:47 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Em 19 de julho de 2014 22:29, Fernando Trebien fernando.treb...@gmail.com escreveu: Sabendo que há trabalhos cientificos publicados descrevendo bons algoritmos para esses ambientes e que não descartam quaisquer vias (mesmo as de classe bem inferior), acho que não devemos fazer adaptações no mapa em favor de algoritmos menos inteligentes. (Isso seria mapear para a aplicação.) Menos inteligentes Desculpa, Fernando, esse seu comentário foi um tanto arrogante. Quando você tem restrição de recursos de hardware em dispositivos móveis você TEM que fazer otimização. Isso para mim é sinal de extrema inteligência. E só uma palavra sobre artigos científicos: poucas vezes tratam-se de ideias praticáveis. O algoritmo Dijkstra é um exemplo. Ninguém usa a forma tal como publicada pelo Dijkstra originalmente. A indústria sempre faz várias melhorias para o mundo real. Sei disso porque trabalho nos dois mundos e também porque estou escrevendo um artigo e não estou pensando em problemas de ordem prática. A teoria já dá trabalho suficiente. Isso não é pecado, é como o progresso funciona: cada especialista em sua área. Mas, ao mesmo tempo, acho que são muito raros os casos em que adaptações seriam necessárias para evitar problemas com esses algoritmos que descartam vias. A menos que eles estejam descartando até as vias primárias (arteriais urbanas), daí não tem como resolver mesmo. Não são raros não. Você tem que pensar em para que a maioria dos usuários precisa de um mapa de ruas (Street Map): a) Encontrar um lugar (geocoding); b) Navegar até um lugar (roteamento); c) Quase sempre em trânsito, com dispositivos móveis. Se essas coisas não estão funcionando bem, elas procurarão alternativas e aí seu mapa será o mais puro do mundo mas vazio de propósito. Se queres que o mapa se torne popular, TEM que pensar nas questões de ordem prática. Acho que dá para conciliar os princípios do OSM com as questões práticas. Mas interromper uma motorway com um trecho de residential vai quebrar o roteamento em muitas aplicações. Não digo colocar tudo igual, mas não deixar as classes tão contrastantes conforme já exemplificado. []s Paulo 2014-07-19 17:56 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: E qual sua opinião sobre o descarte de vias de baixa prioridade nos roteamentos de longa distância em ambientes com baixa memória e processamento mais lento? Em 19 de julho de
Re: [Talk-br] A importância de não quebrar a hierarquia das vias dentro de cidades.
Acho razoável se basear na rota do OSRM pra elencar um ponto mais ou menos mais ou menos no meio 2014-07-20 15:16 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Uma sugestão para diminuir o espaço de busca: dividir para conquistar. Ao invés de calcular uma rota tão longa, tente calcular a rota até metade do caminho, e depois da metade até o destino. (Não precisa ser exatamente a metade, qualquer ponto mais ou menos no meio serve.) O problema vai estar no trecho em que esse teste falhar. Daí você pega o trecho problemático e repete: testa a primeira metade dele, depois a segunda metade. Cada vez que você repete você diminui o espaço de busca. São 3000km, dividindo por 2 a cada vez você provavelmente vai chegar à raiz exata do problema em menos de 20 tentativas. Como saber onde fica a metade? Acho razoável se basear na rota do OSRM pra elencar um ponto mais ou menos: http://osrm.at/8yC Um complicador é que pode ter mais de um problema ao longo de toda essa rota. Se os dois trechos falharem, você vai ter que testar os dois trechos separadamente, ao invés de eliminar um deles. E se forem muitos os problemas, pode precisar de papel e caneta pra lembrar de quais trechos você já testou. É bem provável que isso seja de fato um erro de classificação que precisa ser corrigido no OSM - não com o objetivo específico de fazer o Garmin funcionar, mas sim com o objetivo de deixar a classificação correta. Sim, aplicações mais simples podem ser usadas (e normalmente são uma forma excelente) para detectar problemas com os dados que não interferem tanto com as aplicações mais modernas. E nesse caso específico tanto a comunidade do OSM (agnóstica aos dispositivos) quanto os usuários de Garmin saem ganhando. 2014-07-20 12:47 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Temos um exemplo de um mapa Garmin que não está calculando uma rota entre o extremo sul do Brasil e um ponto no Ceará. A rota é calculada normalmente no Mapsource (computador) mas não no GPS (dipositivo móvel). O problema é justamente localizar onde está a interrupção ou alternância de classificação de vias nos mais de 3000km da rota. Em 20 de julho de 2014 12:05, Fernando Trebien fernando.treb...@gmail.com escreveu: Contraction hierarquies permite usar Dijkstra bidirecional + alguma heurística otimista em ambientes com restrições de memória e capacidade computacional sem remover qualquer via do cálculo. Isso tá lá nos papers referenciados no final daquele artigo da Wikipédia que você apontou. Era a isso que eu me referia ao julgar a inteligência do algoritmo, e por ser um fato (o algoritmo foi publicado e nada impede que seja implementado), não tem como ser arrogante. É uma escolha simples (bem, não tão simples) que o desenvolvedor da aplicação tem que fazer. E é uma escolha que é independente do mapa (que, novamente, serve a vários propósitos, não só ao roteamento, não só ao roteamento em ambientes com capacidades limitadas). Mas interromper uma motorway com um trecho de residential vai quebrar o roteamento em muitas aplicações. Pode dar um exemplo de aplicação e local? Apesar de solicitar esse exemplo, não conheço nenhum caso em que uma motorway/trunk precisaria ter um trecho classificado como residencial. Na pior das hipóteses, teria um trecho classificado como terciária por estar não-pavimentada - mas acho que nem no Brasil essa situação ocorre. Recentemente eu achei um exemplo em que uma trunk se intercala com uma primária [1], mas isso também não deve afetar esses sistemas que descartam vias a que você se refere. E claro, no caso particular, raro, e bizarro de uma classificação fiel produzir uma situação assim, podemos pensar em discutir com a comunidade sobre o que fazer. A idéia de não alternar demais a classificação da via poderia ser aplicada ser for só um trecho curto com características diferentes, e o motivo não seria só o roteamento. [1] http://www.openstreetmap.org/#map=12/-29.5385/-51.8998 2014-07-20 10:47 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Em 19 de julho de 2014 22:29, Fernando Trebien fernando.treb...@gmail.com escreveu: Sabendo que há trabalhos cientificos publicados descrevendo bons algoritmos para esses ambientes e que não descartam quaisquer vias (mesmo as de classe bem inferior), acho que não devemos fazer adaptações no mapa em favor de algoritmos menos inteligentes. (Isso seria mapear para a aplicação.) Menos inteligentes Desculpa, Fernando, esse seu comentário foi um tanto arrogante. Quando você tem restrição de recursos de hardware em dispositivos móveis você TEM que fazer otimização. Isso para mim é sinal de extrema inteligência. E só uma palavra sobre artigos científicos: poucas vezes tratam-se de ideias praticáveis. O algoritmo Dijkstra é um exemplo. Ninguém usa a forma tal como publicada pelo Dijkstra originalmente. A indústria sempre faz várias melhorias
Re: [Talk-br] A importância de não quebrar a hierarquia das vias dentro de cidades.
Pessoal, O Aun se ofereceu pra ajudar testando com a compilação da garmin.openstreetmap.nl e pediu pra eu passar alguns endereços (pra ficar fácil de testar). Vou postar alguém aqui também caso queiram testar com outras compilações. Cruzamentos (requisito do geocoding do Garmin): 1. Chuí, RS: Rua Chile X Rua Palestina 2. Osório, RS: Rua Garibaldi X Rua Melvin Jones 3. Joinville, SC: Rua Nazareno X Rua Benjamin Constant 4. Atibaia, SP: Rua Belvedere X Rua Presidente Dutra 5. Belo Horizonte, MG: Rua Tom Jobim X Fua Ferreira 6. Teófilo Otoni, MG: Rua Coronel Ramos X Rua Dom Felipe 7. Vitória da Conquista, BA: Rua Nova X Rua Deusdete Amaral 8. Feira de Santana, BA: Rua Brumado X Rua Juazeiro 9. Brejo Santo, CE: Rua Marcelino Costa X Rua Joaquim Nicodemos 10. Fortaleza, CE: Rua Pentecoste X Rua Costa Barros Procedimento sugerido pra economizar trabalho testando: - testar rota de [1] a [10]; se funcionar é porque há algum problema com a compilação do mapa que não há na compilação do osm.nl - testar [1] a [6]; se não funcionar, testar [1] a [2], [2] a [3], etc. - se funcionar, testar [6] a [10]; se não funcionar, testar [6] a [7], [7] a [8], etc. Se identificarem o trecho em que o roteamento falha, me avisem que eu mando o próximo conjunto de pontos (que então deve nos levar ao ponto exato do problema). Não mandei agora porque senão teria que sugerir 100 pontos. 2014-07-20 20:05 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Ok, entendido. Obrigado pelas sugestões. []s Paulo Em 20 de julho de 2014 15:17, Fernando Trebien fernando.treb...@gmail.com escreveu: Acho razoável se basear na rota do OSRM pra elencar um ponto mais ou menos mais ou menos no meio 2014-07-20 15:16 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Uma sugestão para diminuir o espaço de busca: dividir para conquistar. Ao invés de calcular uma rota tão longa, tente calcular a rota até metade do caminho, e depois da metade até o destino. (Não precisa ser exatamente a metade, qualquer ponto mais ou menos no meio serve.) O problema vai estar no trecho em que esse teste falhar. Daí você pega o trecho problemático e repete: testa a primeira metade dele, depois a segunda metade. Cada vez que você repete você diminui o espaço de busca. São 3000km, dividindo por 2 a cada vez você provavelmente vai chegar à raiz exata do problema em menos de 20 tentativas. Como saber onde fica a metade? Acho razoável se basear na rota do OSRM pra elencar um ponto mais ou menos: http://osrm.at/8yC Um complicador é que pode ter mais de um problema ao longo de toda essa rota. Se os dois trechos falharem, você vai ter que testar os dois trechos separadamente, ao invés de eliminar um deles. E se forem muitos os problemas, pode precisar de papel e caneta pra lembrar de quais trechos você já testou. É bem provável que isso seja de fato um erro de classificação que precisa ser corrigido no OSM - não com o objetivo específico de fazer o Garmin funcionar, mas sim com o objetivo de deixar a classificação correta. Sim, aplicações mais simples podem ser usadas (e normalmente são uma forma excelente) para detectar problemas com os dados que não interferem tanto com as aplicações mais modernas. E nesse caso específico tanto a comunidade do OSM (agnóstica aos dispositivos) quanto os usuários de Garmin saem ganhando. 2014-07-20 12:47 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Temos um exemplo de um mapa Garmin que não está calculando uma rota entre o extremo sul do Brasil e um ponto no Ceará. A rota é calculada normalmente no Mapsource (computador) mas não no GPS (dipositivo móvel). O problema é justamente localizar onde está a interrupção ou alternância de classificação de vias nos mais de 3000km da rota. Em 20 de julho de 2014 12:05, Fernando Trebien fernando.treb...@gmail.com escreveu: Contraction hierarquies permite usar Dijkstra bidirecional + alguma heurística otimista em ambientes com restrições de memória e capacidade computacional sem remover qualquer via do cálculo. Isso tá lá nos papers referenciados no final daquele artigo da Wikipédia que você apontou. Era a isso que eu me referia ao julgar a inteligência do algoritmo, e por ser um fato (o algoritmo foi publicado e nada impede que seja implementado), não tem como ser arrogante. É uma escolha simples (bem, não tão simples) que o desenvolvedor da aplicação tem que fazer. E é uma escolha que é independente do mapa (que, novamente, serve a vários propósitos, não só ao roteamento, não só ao roteamento em ambientes com capacidades limitadas). Mas interromper uma motorway com um trecho de residential vai quebrar o roteamento em muitas aplicações. Pode dar um exemplo de aplicação e local? Apesar de solicitar esse exemplo, não conheço nenhum caso em que uma motorway/trunk precisaria ter um trecho classificado como residencial. Na pior das hipóteses,
Re: [Talk-br] A importância de não quebrar a hierarquia das vias dentro de cidades.
*Rua Ferreira :P 2014-07-20 22:00 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Pessoal, O Aun se ofereceu pra ajudar testando com a compilação da garmin.openstreetmap.nl e pediu pra eu passar alguns endereços (pra ficar fácil de testar). Vou postar alguém aqui também caso queiram testar com outras compilações. Cruzamentos (requisito do geocoding do Garmin): 1. Chuí, RS: Rua Chile X Rua Palestina 2. Osório, RS: Rua Garibaldi X Rua Melvin Jones 3. Joinville, SC: Rua Nazareno X Rua Benjamin Constant 4. Atibaia, SP: Rua Belvedere X Rua Presidente Dutra 5. Belo Horizonte, MG: Rua Tom Jobim X Fua Ferreira 6. Teófilo Otoni, MG: Rua Coronel Ramos X Rua Dom Felipe 7. Vitória da Conquista, BA: Rua Nova X Rua Deusdete Amaral 8. Feira de Santana, BA: Rua Brumado X Rua Juazeiro 9. Brejo Santo, CE: Rua Marcelino Costa X Rua Joaquim Nicodemos 10. Fortaleza, CE: Rua Pentecoste X Rua Costa Barros Procedimento sugerido pra economizar trabalho testando: - testar rota de [1] a [10]; se funcionar é porque há algum problema com a compilação do mapa que não há na compilação do osm.nl - testar [1] a [6]; se não funcionar, testar [1] a [2], [2] a [3], etc. - se funcionar, testar [6] a [10]; se não funcionar, testar [6] a [7], [7] a [8], etc. Se identificarem o trecho em que o roteamento falha, me avisem que eu mando o próximo conjunto de pontos (que então deve nos levar ao ponto exato do problema). Não mandei agora porque senão teria que sugerir 100 pontos. 2014-07-20 20:05 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Ok, entendido. Obrigado pelas sugestões. []s Paulo Em 20 de julho de 2014 15:17, Fernando Trebien fernando.treb...@gmail.com escreveu: Acho razoável se basear na rota do OSRM pra elencar um ponto mais ou menos mais ou menos no meio 2014-07-20 15:16 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Uma sugestão para diminuir o espaço de busca: dividir para conquistar. Ao invés de calcular uma rota tão longa, tente calcular a rota até metade do caminho, e depois da metade até o destino. (Não precisa ser exatamente a metade, qualquer ponto mais ou menos no meio serve.) O problema vai estar no trecho em que esse teste falhar. Daí você pega o trecho problemático e repete: testa a primeira metade dele, depois a segunda metade. Cada vez que você repete você diminui o espaço de busca. São 3000km, dividindo por 2 a cada vez você provavelmente vai chegar à raiz exata do problema em menos de 20 tentativas. Como saber onde fica a metade? Acho razoável se basear na rota do OSRM pra elencar um ponto mais ou menos: http://osrm.at/8yC Um complicador é que pode ter mais de um problema ao longo de toda essa rota. Se os dois trechos falharem, você vai ter que testar os dois trechos separadamente, ao invés de eliminar um deles. E se forem muitos os problemas, pode precisar de papel e caneta pra lembrar de quais trechos você já testou. É bem provável que isso seja de fato um erro de classificação que precisa ser corrigido no OSM - não com o objetivo específico de fazer o Garmin funcionar, mas sim com o objetivo de deixar a classificação correta. Sim, aplicações mais simples podem ser usadas (e normalmente são uma forma excelente) para detectar problemas com os dados que não interferem tanto com as aplicações mais modernas. E nesse caso específico tanto a comunidade do OSM (agnóstica aos dispositivos) quanto os usuários de Garmin saem ganhando. 2014-07-20 12:47 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Temos um exemplo de um mapa Garmin que não está calculando uma rota entre o extremo sul do Brasil e um ponto no Ceará. A rota é calculada normalmente no Mapsource (computador) mas não no GPS (dipositivo móvel). O problema é justamente localizar onde está a interrupção ou alternância de classificação de vias nos mais de 3000km da rota. Em 20 de julho de 2014 12:05, Fernando Trebien fernando.treb...@gmail.com escreveu: Contraction hierarquies permite usar Dijkstra bidirecional + alguma heurística otimista em ambientes com restrições de memória e capacidade computacional sem remover qualquer via do cálculo. Isso tá lá nos papers referenciados no final daquele artigo da Wikipédia que você apontou. Era a isso que eu me referia ao julgar a inteligência do algoritmo, e por ser um fato (o algoritmo foi publicado e nada impede que seja implementado), não tem como ser arrogante. É uma escolha simples (bem, não tão simples) que o desenvolvedor da aplicação tem que fazer. E é uma escolha que é independente do mapa (que, novamente, serve a vários propósitos, não só ao roteamento, não só ao roteamento em ambientes com capacidades limitadas). Mas interromper uma motorway com um trecho de residential vai quebrar o roteamento em muitas aplicações. Pode dar um exemplo de aplicação e local? Apesar de solicitar esse exemplo, não conheço nenhum
Re: [Talk-br] A importância de não quebrar a hierarquia das vias dentro de cidades.
Só acrescentando uns detalhes. Um resumo da ópera: em alguns sistemas, a classificação pode ter um efeito no roteamento, mas fundamentalmente o mais importante é mapear as características da via (velocidade máxima, superfície, etc.). Pra esse algoritmo só importa a velocidade atribuída a cada trecho das vias (e a atribuição pode não ter relação direta com aquilo que foi mapeado, só indireta). Se não for mapeada a velocidade máxima das vias, então a maioria dos roteadores tenta adivinhar a velocidade a partir da classificação. Como exemplo, eis aqui [1] como o OSRM faz essa adivinhação (lembrando que é um serviço mais voltado às características do trânsito na Europa). Então, sim, a classificação é importante para o roteamento caso não seja mapeada a velocidade máxima. Mas, fundamentalmente, o mais importante para o roteamento é a velocidade atribuída à via. Existem casos em que uma primária urbana tem velocidade reduzida num trecho curto e isso faz diferença pro roteamento decidir mandar o usuário por ali ou não. Só seria mapear para a aplicação se alguém mudasse a classificação naquele trecho por causa da velocidade, para forçar um roteador a evitar o trecho. (Um problema é que muita gente faz isso.) Especificamente para o Garmin/mkgmap, parece que ainda existe o conceito de classe de velocidade, que não é nem a classificação da via (que se reflete no desenho), nem a velocidade máxima (que produz os alertas de velocidade). Essa é uma velocidade estimada de trânsito que no mkgmap [2] pode ter regras até bem complexas de derivação (nos exemplos que eu vi por aí o pessoal estava derivando esse campo a partir de uma combinação da classe da via e da velocidade máxima). Até daria pra mapear no OSM uma velocidade esperada pra via (que então se traduziria diretamente nessa velocidade do Garmin), mas isso é complicado de padronizar e por isso pode gerar divergências (e guerras de edição) e até pode acabar não sendo usado. [3] Algumas abordagens melhores são coletar a velocidade média [4] e monitorar o tráfego [5]. Com essas duas abordagens, a classificação se torna irrelevante pro roteamento (por exemplo, no caso de uma primária estar sempre congestionada e uma secundária paralela estar sempre livre). [1] https://github.com/DennisOSRM/Project-OSRM/blob/master/profiles/car.lua [2] http://www.mkgmap.org.uk/doc/pdf/style-manual.pdf seção 4.6.5 [3] http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/traffic_speed#Practicality_of_Using_Info_in_Router [4] http://wiki.openstreetmap.org/wiki/Average_speed_per_way [5] https://lists.openstreetmap.org/pipermail/talk/2012-August/063985.html 2014-07-15 8:30 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Amigos, Para compreender a razão de não quebrar a hierarquia de vias nos pequenos trechos que rodovias passam por cidades, recomendo esta leitura: http://en.wikipedia.org/wiki/Contraction_hierarchies Aos que já estão com o argumento isso é mapear para aplicação na ponta da língua rogo um momento para parar e pensar: For routing software to work well, the underlying map data must be of good quality. Essentially this means that ways that should be connected are in fact connected, one-way roads are tagged, turn restrictions are mapped, and so on. You should be familiar with the Map Features used, in particular see OSM tags for routing to understand the tags specific to routing. (grifo meu) Palavras da própria comunidade OSM. Fonte: http://wiki.openstreetmap.org/wiki/Routing [ ]s Paulo ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 Nullius in verba. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] A importância de não quebrar a hierarquia das vias dentro de cidades.
Li sim, há bastante tempo. Mas acho que estás confundindo as hierarquias do OSM com a hierarquia de atalhos emergente que o algoritmo de contraction hierarchies produz (que inclusive pode ter muito mais níveis do que os poucos que existem no OSM). Os atalhos servem apenas para acelerar outro algoritmo de roteamento qualquer (geralmente se adota uma variação do Dijkstra, e nesse caso as heurísticas acabam preferindo usar os atalhos). E a hierarquia do OSM não se converte em atalhos automaticamente. A sequẽncia das coisas é assim: - cada arco original representa a ligação de duas interseções no mapa - o peso dos arcos originais é atribuído por velocidade X distância, onde velocidade é uma estimativa feita de forma diferente por cada aplicação (algumas usam a classificação da via, outras não) - (contraction hierarchies) os arcos de atalho são gerados eliminando sequências de arcos cujo peso total é muito alto - (contraction hierarchies) um grafo é formado combinando os arcos originais com os atalhos - um algoritmo de busca em grafos é aplicado sobre o grafo resultante ( ou seja, esse algoritmo vai usar tanto atalhos quanto arcos originais, possivelmente se intercalando entre os dois) Por exemplo, se você tiver dois caminhos de A a B com quase a mesma distância total, um deles é uma primária com velocidade de 10km/h, e outro é uma terciária intercalada com trechos de living_street que, na média, fica em torno de 80km/h, vai ser a primária que vai ser removida na geração dos atalhos e o segundo caminho (mais rápido, embora envolva vias de classificação inferior) que vai virar um atalho. O fato de ser primária, secundária, living street, não faz diferença alguma a princípio - a menos que exista um programa antes (como o mkgmap) que associa a classificação ao peso do arco (mais especificamente à velocidade, já que a distância é exata sempre). O OSRM, por exemplo, não associa quando a velocidade máxima é definida (ou seja, o segundo caso pode acontecer). Enfim, isso é um detalhe, a classificação tem que estar bem feita por diversos motivos, mas (se formos pensar genericamente, para vários sistemas) não se pode ignorar o mapeamento da velocidade máxima das vias. 2014-07-19 12:10 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Pra esse algoritmo só importa a velocidade atribuída a cada trecho das vias (e a atribuição pode não ter relação direta com aquilo que foi mapeado, só indireta). Não é bem assim. Na graduação se ensina o Djkstra que leva a maioria das pessoas focar apenas no custo de percurso. Mas uma aplicação real é mais complexa. O tamanho do grafo é um fator de extrema relevância. Acho que tu não leste o artigo sobre Hierarchy Contraction. Existe uma otimização que é feita nos dispositivos móveis. Enfim, vou resumir: para rotas de longa distância, em que analisar o grafo todo seria muito custoso tanto em termos de desempenho quanto de memória, é feito um descarte de vias de baixa hierarquia. As vias de menor hierarquia só passam a ser computadas nas proximidades dos pontos de origem e de destino. Por causa desse descarte, o cálculo de rotas longas pode falhar em smartphones, tablets e GPSs para mapas mal desenhados. Em 19 de julho de 2014 11:56, Fernando Trebien fernando.treb...@gmail.com escreveu: Só acrescentando uns detalhes. Um resumo da ópera: em alguns sistemas, a classificação pode ter um efeito no roteamento, mas fundamentalmente o mais importante é mapear as características da via (velocidade máxima, superfície, etc.). Pra esse algoritmo só importa a velocidade atribuída a cada trecho das vias (e a atribuição pode não ter relação direta com aquilo que foi mapeado, só indireta). Se não for mapeada a velocidade máxima das vias, então a maioria dos roteadores tenta adivinhar a velocidade a partir da classificação. Como exemplo, eis aqui [1] como o OSRM faz essa adivinhação (lembrando que é um serviço mais voltado às características do trânsito na Europa). Então, sim, a classificação é importante para o roteamento caso não seja mapeada a velocidade máxima. Mas, fundamentalmente, o mais importante para o roteamento é a velocidade atribuída à via. Existem casos em que uma primária urbana tem velocidade reduzida num trecho curto e isso faz diferença pro roteamento decidir mandar o usuário por ali ou não. Só seria mapear para a aplicação se alguém mudasse a classificação naquele trecho por causa da velocidade, para forçar um roteador a evitar o trecho. (Um problema é que muita gente faz isso.) Especificamente para o Garmin/mkgmap, parece que ainda existe o conceito de classe de velocidade, que não é nem a classificação da via (que se reflete no desenho), nem a velocidade máxima (que produz os alertas de velocidade). Essa é uma velocidade estimada de trânsito que no mkgmap [2] pode ter regras até bem complexas de derivação (nos exemplos que eu vi por aí o pessoal estava derivando esse campo a partir de uma combinação da classe da via e
[Talk-br] A importância de não quebrar a hierarquia das vias dentro de cidades.
Amigos, Para compreender a razão de não quebrar a hierarquia de vias nos pequenos trechos que rodovias passam por cidades, recomendo esta leitura: http://en.wikipedia.org/wiki/Contraction_hierarchies Aos que já estão com o argumento isso é mapear para aplicação na ponta da língua rogo um momento para parar e pensar: For routing software to work well, the *underlying map data must be of good quality*. Essentially this means that ways that should be connected are in fact connected, one-way roads are tagged, turn restrictions are mapped, and so on. You should be familiar with the Map Features http://wiki.openstreetmap.org/wiki/Map_Features used, in particular see OSM tags for routing http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing to *understand the tags specific to routing*. (grifo meu) Palavras da própria comunidade OSM. Fonte: http://wiki.openstreetmap.org/wiki/Routing [ ]s Paulo ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
