[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 15:28:19 UTC 2014


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 <lists em 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.trebien em 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.carvalho em 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.trebien em 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.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."
>>>
>>> _______________________________________________
>>> 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
>>
> _______________________________________________
> 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."



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