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