Os Garmin fazem sim busca por POIs.
Em 24 de julho de 2014 11:06, Fernando Trebien <fernando.treb...@gmail.com> escreveu: > 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=52&t=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=52&t=214 e >> http://www.cocardl.com.br/viewtopic.php?f=52&t=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=23&t=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 é >>> >> >> 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 >>> 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 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 >>> >> >>> >> >> > >>> >> >>> >> >> > >>> >> >>> >> >> > >>> >> >>> >> >> > _______________________________________________ >>> >> >>> >> >> > 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 >>> >> >>> >> > >>> >> >>> >> > >>> >> >>> >> > >>> >> >>> >> > _______________________________________________ >>> >> >>> >> > 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 >>> >> >>> > >>> >> >>> > >>> >> >>> > >>> >> >>> > _______________________________________________ >>> >> >>> > 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 >>> >> >> >>> >> >> >>> >> >> >>> >> >> _______________________________________________ >>> >> >> Talk-br mailing list >>> >> >> Talk-br@openstreetmap.org >>> >> >> https://lists.openstreetmap.org/listinfo/talk-br >>> >> >> >>> >> > >>> >> > >>> >> > >>> >> > -- >>> >> > Fernando Trebien >>> >> > +55 (51) 9962-5409 >>> >> > >>> >> > "Nullius in verba." >>> >> >>> >> >>> >> >>> >> -- >>> >> Fernando Trebien >>> >> +55 (51) 9962-5409 >>> >> >>> >> "Nullius in verba." >>> >> >>> >> _______________________________________________ >>> >> Talk-br mailing list >>> >> Talk-br@openstreetmap.org >>> >> https://lists.openstreetmap.org/listinfo/talk-br >>> > >>> > >>> > >>> > _______________________________________________ >>> > 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 >>> >> >> >> _______________________________________________ >> Talk-br mailing list >> Talk-br@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-br >> >> > _______________________________________________ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > >
_______________________________________________ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
