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

Paulo Carvalho paulo.r.m.carvalho em gmail.com
Quinta Julho 24 17:52:46 UTC 2014


Em 24 de julho de 2014 11:34, Fernando Trebien <fernando.trebien em gmail.com>
escreveu:

> 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. ;-)
>

Sim, temos pleno interesse nisso.  Aliás estou ponderando acerca de um
método para trazer o conceito de testes automatizados do mundo do
desenvolvimento de software ao mundo dos mapas.  Eu só poderei testar essas
rotas com calma no final de semana, sem ser esse agora porque terei que ir
à UFRGS na próxima semana.


>
> [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."
>
> _______________________________________________
> Talk-br mailing list
> Talk-br em openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.openstreetmap.org/pipermail/talk-br/attachments/20140724/0f0f91c9/attachment-0001.html>


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