Teoria para o problema com as rotas de longa distancia

[gcpeixoto]

Aos amigos Compiladores, DEs e principalmente aos que elaboram os padrões do projeto.
.
Acreditava que, com o Remap, o problema das rotas de longa distancia estaria resolvido
.
No TRC-10.10, a rota de Belo Horizonte-MG a Porto Seguro-BA, como outras longas, continua com o cálculo muito lento e quando consegue rotear por completo, indica, hora, uma volta de 400 Km por Vitória da Conquista-BA ou, outra volta de 260 Km por João Neiva-ES.
.
Procurando entender a lógica deste roteamento, analisei trecho por trecho dos locais onde seria a rota lógica e ambas as voltas. Observei que na rota lógica, (BH- BR116-Teófilo Otoni-Nanuque-BR101-Porto) existem muitos trechos que as BRs (MGs e BAs) cortam as cidades, principalmente um longo trecho em Teófilo Otoni, o que não acontecia nas voltas. Onde estas se transformava em avenidas, formatadas corretamente pelo padrão com os tracks de avenida (linha gossa-negra) o qual tem o valor de classe de roteamento igual a 1, como tambem várias rotatórias e acessos com os seus valores default de RC.
.
Em caráter experimental, solicitei aos meus vizinhos DMs e incluir em todos os meus mapas, na trajetória da rota, um upgrade nos valores de classe de roteamento para o valor = 3 (<rc=3> valor default das rodovias), para estas avenidas, suas rotatórias e todos acessos que influem diretamente na atravessia das cidades.
Como não tenho como fazer o teste com as novas quadrículas, unir o TRCs MG e BA, com as estruturas antigas de mapas por município, pelo GmapToll e, para minha surpresa, a rota foi calculada com extrema rapidez e pelo local lógico.
.
Diante ao exposto, acredito que tenho dados suficientes para, pelo menos, formular uma teoria de que os problemas com as rotas de longa distancia estão diretamente relacionado com estes trechos em que as BRs cortam as cidades, e sua classe de roteamento cai para 2 ou até mesmo 1. Forçando o GPS a procurar novas alternativas. Acontecendo com mais frequencia quando este trecho está no meio da rota e com menos frequencia quando está no início ou final desta. Observem que todas as rotas com problema passa internamente por cidades.
.
Somente procurando o melhor para o projeto e aguardando opiniões contraditórias,

[phninke]

Gilberto,

Acho seus testes bem válidos e constantemente faço isso nos mapas do ES simulando rotas pelo interior dos municípios e verificando se elas passam por onde devem passar, ou seja, pelas estradas principais desses municípios (conforme indicação das placas de trânsito no local).

Porém, conforme o padrão, a formatação dessas avenidas que você cita acho que deveria ser feita com a linha grossa vermelha.
----------------
Avenida, Via Urbana Duplicada ou Estrada Municipal Duplicada = Pista Dupla pavimentada.
----------------

Como o RC desta (2) é maior que o RC da linha grossa preta (Rua Pavimentada Principal no Trackmaker) talvez essa simples mudança de formatação possa resolver o problema na hora do GPS escolher a rota mais rápida, sem precisar alterar os RC's manualmente. Você ainda tem duas versões do TRC-Brasil para testar antes dos turistas começarem a chegar em Porto Seguro em janeiro do próximo ano...

Entretanto em função das simulações feitas, já tive que usar esse artifício (incluir as tags RC ou VEL) para ajustar a rota feita pelo Mapsource/GPS em função das condições reais de trafego. É o caso de uma rodovia estadual duplicada (ES-060) que corta praticamente todo o município de Vila Velha e Vitória. Usando a formatação "normal" nessa via (Rodovia Principal Azul) o caminho (mais rápido) de sul a norte do ES era direcionado para essa via, afinal é uma pista duplicada e teoricamente mais rápida. Mas isso jogaria o pobre coitado do turista no meio de um trânsito urbano complicado e cuja velocidade é infinitamente menor do que se ele fizer todo o trajeto pela BR-101 (pista simples) e que contorna esses dois municípios em área rural.

Plagiando a frase do "chefe"...Tudo é feito para que o "mapa possa refletir a realidade do trafego, o mais fielmente possível"...