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
