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

Aun Johnsen lists em gimnechiske.org
Quinta Julho 24 15:40:38 UTC 2014


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.trebien at 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 <lists at 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 at 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 at 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 at 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 at gmail.com>:
>>>>> Ok, entendido.  Obrigado pelas sugestões.
>>>>> 
>>>>> []s
>>>>> 
>>>>> Paulo
>>>>> 
>>>>> 
>>>>> Em 20 de julho de 2014 15:17, Fernando Trebien
>>>>> <fernando.trebien at 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 at 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 at 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 at 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
>>>>>>>>>>>>>>>>>> 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 at gmail.com>:
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Em 19 de julho de 2014 22:29, Fernando Trebien
>>>>>>>>>> <fernando.trebien at 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 at 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 at 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 at 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 at 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 at 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 at openstreetmap.org
>>>>>>>>>>>>>>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Fernando Trebien
>>>>>>>>>>>>>>> +55 (51) 9962-5409
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> "Nullius in verba."
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> Talk-br mailing list
>>>>>>>>>>>>>>> Talk-br at openstreetmap.org
>>>>>>>>>>>>>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> Talk-br mailing list
>>>>>>>>>>>>>> Talk-br at openstreetmap.org
>>>>>>>>>>>>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Fernando Trebien
>>>>>>>>>>>>> +55 (51) 9962-5409
>>>>>>>>>>>>> 
>>>>>>>>>>>>> "Nullius in verba."
>>>>>>>>>>>>> 
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> Talk-br mailing list
>>>>>>>>>>>>> Talk-br at openstreetmap.org
>>>>>>>>>>>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Talk-br mailing list
>>>>>>>>>>>> Talk-br at openstreetmap.org
>>>>>>>>>>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> Fernando Trebien
>>>>>>>>>>> +55 (51) 9962-5409
>>>>>>>>>>> 
>>>>>>>>>>> "Nullius in verba."
>>>>>>>>>>> 
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Talk-br mailing list
>>>>>>>>>>> Talk-br at openstreetmap.org
>>>>>>>>>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Talk-br mailing list
>>>>>>>>>> Talk-br at openstreetmap.org
>>>>>>>>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> Fernando Trebien
>>>>>>>>> +55 (51) 9962-5409
>>>>>>>>> 
>>>>>>>>> "Nullius in verba."
>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> Talk-br mailing list
>>>>>>>>> Talk-br at openstreetmap.org
>>>>>>>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> Talk-br mailing list
>>>>>>>> Talk-br at 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 at openstreetmap.org
>>>>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Talk-br mailing list
>>>>> Talk-br at openstreetmap.org
>>>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Fernando Trebien
>>>> +55 (51) 9962-5409
>>>> 
>>>> "Nullius in verba."
>>>> 
>>>> _______________________________________________
>>>> Talk-br mailing list
>>>> Talk-br at openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/talk-br
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Talk-br mailing list
>>> Talk-br at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-br
>> _______________________________________________
>> Talk-br mailing list
>> Talk-br at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-br
>> 
>> 
>> _______________________________________________
>> Talk-br mailing list
>> Talk-br at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-br
> 
> 
> 
> -- 
> Fernando Trebien
> +55 (51) 9962-5409
> 
> "Nullius in verba."
> 
> _______________________________________________
> Talk-br mailing list
> Talk-br at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br



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