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