[Talk-br] A importância de não quebrar a hierarquia das vias dentro de cidades.

Fernando Trebien fernando.trebien em gmail.com
Quinta Julho 24 14:34:37 UTC 2014


O OSRM dá uma rota de 3927km, mas é bem possível que esta contagem
esteja ligeiramente imprecisa (tanto no OSRM quanto no Garmin). Tem
como você comparar a rota escolhida pelo Garmin com a rota dada pelo
OSRM pra ver se há diferenças? [1]  Porque, se não houver, significa
que todo o trecho entre Osório e Fortaleza está ok. Resta então o
trecho Chuí-Osório.

Paulo, você está fazendo esses testes também, ou está falando com
alguém da Cocar que tenha um Garmin com a compilação que vocês
preparam? Como maiores interessados na questão, acho que deveriam. ;-)

[1] http://osrm.at/8CV

2014-07-24 8:14 GMT-03:00 Aun Johnsen <lists em gimnechiske.org>:
> Desculpa demorou
>
> To vendo que meus mapas atuais no meu Garmin Nüvi nao tem tudos os ruas no este pesquisa, vou atualizar as mapas logo
>
> Primeira teste do Osorio a Fortaleza deu um rota do 3914km, e 39:53 hh:mm tempo
>
> To vendo que meu GPS tem problemas com rotas este distanca (passando limite do waypoints?), curtando esquinas.
>
> Com novo mapas vou testar com rotas mais curtos, para ver o que distance o GPS tem limite, e para verificar rotamento entre estes cidades
>
> Aun Johnsen
> Sent from my iPhone
>
>> On 20. juli 2014, at 22:01, Fernando Trebien <fernando.trebien em gmail.com> wrote:
>>
>> *Rua Ferreira :P
>>
>> 2014-07-20 22:00 GMT-03:00 Fernando Trebien <fernando.trebien em 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.carvalho em gmail.com>:
>>>> Ok, entendido.  Obrigado pelas sugestões.
>>>>
>>>> []s
>>>>
>>>> Paulo
>>>>
>>>>
>>>> Em 20 de julho de 2014 15:17, Fernando Trebien <fernando.trebien em 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.trebien em 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.carvalho em 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.trebien em 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.carvalho em gmail.com>:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Em 19 de julho de 2014 22:29, Fernando Trebien
>>>>>>>>> <fernando.trebien em 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.carvalho em 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.trebien em 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.carvalho em 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.trebien em 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.carvalho em 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 em openstreetmap.org
>>>>>>>>>>>>>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Fernando Trebien
>>>>>>>>>>>>>> +55 (51) 9962-5409
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> "Nullius in verba."
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> Talk-br mailing list
>>>>>>>>>>>>>> Talk-br em openstreetmap.org
>>>>>>>>>>>>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> Talk-br mailing list
>>>>>>>>>>>>> Talk-br em openstreetmap.org
>>>>>>>>>>>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Fernando Trebien
>>>>>>>>>>>> +55 (51) 9962-5409
>>>>>>>>>>>>
>>>>>>>>>>>> "Nullius in verba."
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Talk-br mailing list
>>>>>>>>>>>> Talk-br em openstreetmap.org
>>>>>>>>>>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Talk-br mailing list
>>>>>>>>>>> Talk-br em openstreetmap.org
>>>>>>>>>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Fernando Trebien
>>>>>>>>>> +55 (51) 9962-5409
>>>>>>>>>>
>>>>>>>>>> "Nullius in verba."
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Talk-br mailing list
>>>>>>>>>> Talk-br em openstreetmap.org
>>>>>>>>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Talk-br mailing list
>>>>>>>>> Talk-br em openstreetmap.org
>>>>>>>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Fernando Trebien
>>>>>>>> +55 (51) 9962-5409
>>>>>>>>
>>>>>>>> "Nullius in verba."
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Talk-br mailing list
>>>>>>>> Talk-br em openstreetmap.org
>>>>>>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Talk-br mailing list
>>>>>>> Talk-br em 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 em openstreetmap.org
>>>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Talk-br mailing list
>>>> Talk-br em 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."



-- 
Fernando Trebien
+55 (51) 9962-5409

"Nullius in verba."



Mais detalhes sobre a lista de discussão Talk-br