Mapas roteáveis para cidades - projeto tracksource

[aktu]

Pessoal, desculpem pela ignorância, mas gostaria de saber o porquê é tão difícil fazer um mapa autoroteável de uma cidade.

Dei uma lida no manual do tracksource e pude vislumbrar a complexidade do desenvolvimento de um mapa completo, com indicação de direção de vias, velocidade máxima, limitações de tipo de meio de locomoção, e Também a encrenca que é o processo de compilação, etc, etc, etc...

Mas e um mapa preliminar, apenas com informações das vias e nós em suas junções, já não seria suficiente? É claro que cada um que estivesse utilizando tal mapa deveria ter o devido bom senso para não pegar uma via na contra-mão, por exemplo. Ao deixar de entrar na via indicada, o GPS recalcularia a rota e assim sucessivamente seria possível chegar ao destino...

Aliás, li em algum lugar que não é possível localizar ruas pelos seus nomes nos mapas municipais do Tracksource. É verdade? Se sim o porquê disso? Uma limitação do próprio software de compilação?

Por favor, não pensem que estou fazendo algum tipo de cobrança, ninguém tem o direito a isso, mesmo porque sei que é um projeto tocado por voluntários e todos possuem um tempo limitado.

Na verdade penso em adquirir um 60csx, mas fico receoso de que demore muito para existir um TM Roteável, por exemplo, para Campinas e São Paulo o que diminuiria um pouco a utilidade do GPS para mim. Aliás, aproveitando, alguém saberia para quando poderíamos esperar os mapas roteáveis para Campinas e São Paulo? 6 meses, 1 ano, 5 anos? Realmente não faço idéia sobre isso.

Pensei Também em começar a criar, no futuro, um mapa da cidade onde resido, mas não estou certo sobre a quantidade de trabalho que isso daria... ou o problema maior é a inexistência de softwares práticos para a criação de mapas para os GPSs Garmin?

Bom, acho que é isso, me desculpem pela mensagem um pouco grande demais, mas acho que ela sintetiza a maior parte de minhas indagações sobre os tão esperados mapas do tracksource.

Valeu pessoal.

[nqnnospam]

Acho que isto já foi discutido em outros tópicos. Um resumo das dificuldades:

1) Exemplo, a cidade de São Paulo está dividida em 4 pedaços. Supondo que todos os desenvolvedores fizessem a conversão para roteamento básica como ligar automaticamente as centenas de ruas e avenidas que passam de um mapa para outro? não é viável fazer este processo manualmente todo mês.

2) Supondo que a questão anterior estevisse resolvida, como fazer para que o roteamento passe de uma cidade para outra, se nem todos os municípios têm mapa/desenvolvedor? Lembre-se que qualquer que seja a solução, ou tem que ser automática, ou tem que ser algo que não precise ser repetido toda compilação.

3) você falou do endereçamento (Find Address->"Encontre o número tal da rua tal"). Ele está diretamente ligado ao roteamento. Hoje não há uma forma simples e permanente que permita aos desenvolvedores entrar esta informação no mapa. Hoje seria possível entrar com estas informações, mas toda vez que houvesse qualquer mudança no mapa toda a informação teria que ser inserida e verificada novamente, manualmente. Inviável. Nenhum desenvolvedor vai querer fazer isso.

4) O roteamento em cidades é mais complicado que o rodoviário, pois obriga o uso de restrições de manobra complexas. Para elas existe a mesma dificuldade do item 3.

[aktu]

É... parece um pouco mais complicado do que eu imaginava...

Em relação ao item 3 comentado, quer dizer que é necessário compilar o mapa para só então entrar com as informações de forma manual? não há um formato de arquivo fonte que suporte todas essas informações e um compilador que as interprete e gere o mapa final diretamente?

Parece que o problema principal é a inexistência de softwares integrados para a criação de tais mapas não?

Existem outras empresas que criam mapas para os GPSs da Garmin? Se sim, essas empresas criam seus próprios softwares para compilação de tais mapas?

Abraços.

[aktu]

Só por curiosidade: a Versão Routable do cGPSMapper, pela bagatela de 2300 euros, consegue facilitar a criação de mapas roteáveis?

então acho que software existe.... mas a preços definitivamente proibitivos...

[nqnnospam]

É... parece um pouco mais complicado do que eu imaginava...

Sim

Em relação ao item 3 comentado, quer dizer que é necessário compilar o mapa para só então entrar com as informações de forma manual? não há um formato de arquivo fonte que suporte todas essas informações e um compilador que as interprete e gere o mapa final diretamente?

+/-

Parece que o problema principal é a inexistência de softwares integrados para a criação de tais mapas não?

+/-

Existem outras empresas que criam mapas para os GPSs da Garmin? Se sim, essas empresas criam seus próprios softwares para compilação de tais mapas?

Sim, mas elas trabalham com (para?) a Garmin.

[nqnnospam]

Só por curiosidade: a Versão Routable do cGPSMapper, pela bagatela de 2300 euros, consegue facilitar a criação de mapas roteáveis?

Sim, mas por outras razões.

Mas o problema atual é nos passos anteriores ao uso do cgpsmapper.

[aktu]

Sim, mas por outras razões.

Mas o problema atual é nos passos anteriores ao uso do cgpsmapper.

Existe algum tutorial em que mostre passo a passo como criar um mapa Roteável para que eu possa evidenciar esses problemas... pode ser que com a construção de um outro software simples o problema seja aliviado... sei lá, só uma suposição.

Valeu

[nqnnospam]

Sim, mas por outras razões.

Mas o problema atual é nos passos anteriores ao uso do cgpsmapper.

Existe algum tutorial em que mostre passo a passo como criar um mapa Roteável para que eu possa evidenciar esses problemas... pode ser que com a construção de um outro software simples o problema seja aliviado... sei lá, só uma suposição.

Valeu

Só o manual em http://tracksourcebrasil.wikispaces.org

[paulocarvalho]

não achei tão complicado assim. Para dizer a verdade achei mais simples do que criar o mapa a partir do zero, pois podemos usar o TM como fonte das posições geográficas corretas. Consultando a fonte certa, fazer mapas roteáveis é trabalhoso, mas não é difícil.

Estou em conversas com o Amílton para começar a fazer o mapa Roteável do Rio, e inclusive mandei um GTM de teste, só para "sentir" o processo de formatação e uma proposta de divisão de trabalho baseada em células ou em "bacias rodoviárias".

[nqnnospam]

Talvez por ter estudado o processo bastante a fundo (para fazer o Conversor), eu tenha uma visão melhor das dificuldades.

O processo básico não é complicado mesmo, mas há vários problemas impossíveis de serem tratados com as ferramentas atuais (GTM, Otimizador, Conversor, compilador MC2):

- em mapas municipais há restrições de roteamento mais complexas do que as que temos atualmente no TRR. O GTM não permite registrar estes informações no mapa. O desenvolvedor teria que mantê-las num arquivo separado, e fazer a manutenção delas seria muito complicado.

- o mesmo problema vale para as informações de endereço

- seria inviável fazer a compilação no MC2 mesmo que de uma parte pequena dos mapas municipais atuais. Seria uma carga enorme, mesmo que tivéssemos vários compiladores. Isto sem consideramos eventuais limitações ou descontinuidades nos serviços do MC2. Seria injusto ter que escolher quais mapas municipais seriam roteáveis ou não, por causa de limitações no MC2.

Para resolver os problemas acima não será suficiente escrever um aplicativo "simples" como o Conversor.

Além disso eu acho que ter os mapas municipais espalhados no MC2 não vai agilizar a solução dos problemas acima, porque mapas espelhados não servem para fazer um mapset, e não há como juntá-los fora do MC2.

não digo que os desenvolvedores municipais não devam ter os seus mapas preparados, mas precisamos ter consciência de que não estamos prontos para ter os mapas municipais roteáveis ainda.

[paulocarvalho]

Talvez por ter estudado o processo bastante a fundo (para fazer o Conversor), eu tenha uma visão melhor das dificuldades.

O processo básico não é complicado mesmo, mas há vários problemas impossíveis de serem tratados com as ferramentas atuais (GTM, Otimizador, Conversor, compilador MC2):

- em mapas municipais há restrições de roteamento mais complexas do que as que temos atualmente no TRR. O GTM não permite registrar estes informações no mapa. O desenvolvedor teria que mantê-las num arquivo separado, e fazer a manutenção delas seria muito complicado.

- o mesmo problema vale para as informações de endereço

- seria inviável fazer a compilação no MC2 mesmo que de uma parte pequena dos mapas municipais atuais. Seria uma carga enorme, mesmo que tivéssemos vários compiladores. Isto sem consideramos eventuais limitações ou descontinuidades nos serviços do MC2. Seria injusto ter que escolher quais mapas municipais seriam roteáveis ou não, por causa de limitações no MC2.

Para resolver os problemas acima não será suficiente escrever um aplicativo "simples" como o Conversor.

Além disso eu acho que ter os mapas municipais espalhados no MC2 não vai agilizar a solução dos problemas acima, porque mapas espelhados não servem para fazer um mapset, e não há como juntá-los fora do MC2.

não digo que os desenvolvedores municipais não devam ter os seus mapas preparados, mas precisamos ter consciência de que não estamos prontos para ter os mapas municipais roteáveis ainda.

Sérgio, convém esclarecer em mais detalhes, com exceção do endereçamento, que problemas São esses, pois o manual de roteamento não os cita. Por exemplo, que "problemas de roteamento mais complexos" São esses nos mapas municipais? até onde entendo a diferença entre o rodoviário e o municipal é tão somente a capilaridade e a velocidade praticada nas vias.

[nqnnospam]

Paulo, veja a figura abaixo, cruzamento das Avenidas Barão de Itapura e Brasil em Campinas-SP:



A seta preta indica o sentido de tráfego permitido na Av Br de Itapura.

As setas azuis indicam os sentidos de tráfego permitidos na Av Brasil (com duas pistas, separadas por canteiro central).

Observe que é permitido, saindo da Av Br de Itapura, entrar na Av Brasil nos dois sentidos (na pista correta, é claro!!!), manobras indicadas pelas setas verdes. Isto obriga a existência de dois nós de roteamento neste cruzamento (latitude , longitude: -22.8911670726492, -47.063064619692 WGS84, está mapeado no Tracksource Municipal), um para cada pista da Av Brasil.

Observe que não é permitido:

- para quem vem do canto esquerdo superior pela Av Brasil, virar à esquerda para pegar a Av Br de Itapura (seta laranja).
- fazer retorno neste cruzamento de uma pista da Av Brasil para a outra, em qualquer sentido

não sei se você já percebeu, mas é impossível, usando somente as TAGs de mão única, ou movendo os nós de um lugar para o outro, implementar as restrições acima. Para fazê-lo é necessário usar restrições de nós e vias, que especificam sequências de vias e nós que rotas não podem seguir (proibido ir do nó X da AV Brasil para o nó Y da Br de Itapura, passando pelo nó Z comum as duas avenidas).

Veja Também que este tipo de restrição complexa é muito comum em mapas municipais (só na citada Av Brasil há uma dezena de restrições deste tipo), logo elas São extremamente necessárias para os mapas municipais.

Com certeza alguém deve estar pensando "Ahh, mas podemos deixar sem estas restrições, afinal o GPS recalcula a rota automaticamente". É verdade, mas não é bem assim. Primeiro que o "recálculo" não é instantâneo. O GPS precisa de um tempo para perceber que o motorista não seguiu a rota sugerida, e mais um outro tempo para recalcular a rota, Após perceber que está fora da rota. Quanto menor o número de opções (isto é, quanto maior o número de restrições definidas) mais rápido é o recálculo, e mais eficiente é o sistema.

Exemplo, se o motorista vem descendo a Av Brasil e precisa pegar a Br de Itapura, ele precisa passar o cruzamento e seguir o caminho amarelo. Se a restrição vermelha não estiver definida, o GPS vai mandar o cidadão fazer a conversão proibida. Supondo que o motorista se toque que a conversão é proibida, o GPS tem exatamente um quarteirão para recalcular a rota e sugerir o caminho amarelo. Dependendo da velocidade do veículo (e do GPS), pode não dar tempo. Observe inclusive que no próximo quarteirão, Também há o mesmo tipo de restrição. Se estas restrições estiverem definidas corretamente, nada disso é necessário, e o sistema de auto-roteamento não corre o risco de ficar sobrecarregado recalculando rotas absurdas.

Num mapa rodoviário isto não faz diferença, principalmente porque "construções viárias" como a descrita acima São raras.

Contudo, num mapa municipal, o correto uso das restrições de nós e vias vai fazer a diferença entre um mapa Roteável utilizável e um onde o GPS só fica "recalculando".

já se cogitou inúmeras maneiras de gravar no mapa .gtm este tipo de restrição, mas como o GTM não identifica os nós de roteamento como entidades independentes do mapa, todas as solução propostas se mostraram por demais complexas de administrar.

Estamos trabalhando numa espécie de plug-in para o GTM, cujo objetivo é permitir a entrada/manipulação/administração deste tipo de informação (restrições e endereços) de forma transparente. Eu, sinceramente, acho importante manter os pés no chão enquanto não temos este plug-in pronto, para evitar decepções ou desperdício de trabalho. Acho que os desenvolvedores municipais devem sim aplicar no seu mapa .gtm a etapa de "Viadutos" descrita no manual, e acertar as tags de vias. Contudo, mais do que isso é especulação, correndo-se o risco de frustação e de ter trabalho perdido.

[Haigh]

Sérgio,

Excelente explicação. Era isso que eu imaginava quando lia "restrições de nós" no manual mas não tinha certeza.

Quem está trabalhando no plugin?

Por um acaso as vias e nós passarão a ser identificados por alguma chave como em um banco de dados?

Pergunto isso porque gostaria de estruturar um mecanismo para facilitar o trabalho colaborativo de levantamento das restrições de nós e detalhes de POIs. Para isto seria necessário que os elementos do mapa, (trilhas, nós e POIs) pudessem ser unicamente identificados mesmo que tivessem nomes e posições editadas.

abração
Robert

[nqnnospam]

Sérgio,

Excelente explicação. Era isso que eu imaginava quando lia "restrições de nós" no manual mas não tinha certeza.

Quem está trabalhando no plugin?

Eu, o Paulo e o Ígor, mas está meio complicado criar um sistema de desenvolvimento colaborativo. O setup inicial é muito complexo (SVN/CVS, definição de interfaces, documentação, etc.).

Por um acaso as vias e nós passarão a ser identificados por alguma chave como em um banco de dados?

Sim, isto é inevitável. Em princípio basta a chave ser única no mapa. Exigir que ela seja única em todos os mapas é mais complicado. O programa compilador usa chaves numéricas inteiras para as vias e nós de roteamento (RoadID e NodeID), e obviamente isto impõe uma restrição no número de valores possíveis.

Pergunto isso porque gostaria de estruturar um mecanismo para facilitar o trabalho colaborativo de levantamento das restrições de nós e detalhes de POIs. Para isto seria necessário que os elementos do mapa, (trilhas, nós e POIs) pudessem ser unicamente identificados mesmo que tivessem nomes e posições editadas.

Seria uma ferramenta interessante, contudo é bem complexo implementar. O problema basicamente é como manter a consistência entre os mapas .gtm e este banco de dados central.

[Haigh]

Sérgio,

Ainda vou elaborar um documento com a especificação da idéia para subsidiar a discussão com o grupo mas o conceito geral é o banco contenha todos os elementos, com suas versões alterações e atualizações e campos adicionais para identificar o autor do elemento, o autor da modificação sugerida, as datas, e a natureza da modificação sugerida (posição, nome, restrições, detalhes do POI, etc.)

Inicialmente os GTMs seriam carregados no banco. sugestões de alteração seriam carregadas no banco via interface WEB ou via carga de um arquivo GTM. Os elementos seriam classificados com o nome do colaborador e o tipo de alteração sugerida. O desenvolvedor poderia baixar um arquivo GTM com as alterações sugeridas. (podemos pensar em filtros). Depois do crivo, o desenvolvedor daria algum tipo de baixa nos status das atualizações. A interface de colaboração pode ser Web ou algum plugin do TrackMaker que trataria as alterações sugeridas como layers no mapa e faria a atualização de status diretamente via GTM.

A idéia nasceu não para complicar mas para permitir a participação no projeto de muitas mãos em um mesmo mapa. Poderiamos incluir processos mais estruturados e automatizados de levantamento de dados e conferência.

Exemplos:
nós sem restrição definida teriam um flag de não visitado. Um colaborador poderia baixar um grupo de waypoints representando os nós a visitar e um formulário padrão de cadastro de restrições para nós. Faria um programa de domingo passeando pela cidade e coletando informações de restrição e enviaria tudo ao desenvolvedor pelo banco de dados. Dessa maneira fica mais fácil gerenciar as contribuições e direcionar os esforços dos colaboradores para as regiões ainda não trabalhadas, sem perder nenhum nó.

Outro caso é o de POIs. Os dados caducam com o tempo e é necessário visitar de novo para ver se o estabelecimento continua lá e funcionando. Eu poderia criar uma lista de POIs a visitar com base na última atualização e enviaria para o banco um check de visita e confirmação dos dados. Outro colaborador não iria gastar tempo na semana seguinte visitando os mesmos pontos e dedicaria seu tempo a outra região. (pensem em São paulo ou outras cidades grandes quando lerem isto)

A idéia é um sistema parrudo de gestão de alterações para elementos geográficos em ambiente colaborativo. Quem sabe o Odilon não se empolga e decide transoformar o TrackMaker em um software GIS de trabalho colaborativo... vai saber...

Gostaria de conhecer mais detalhes das especificações do sistema de roteamento e se possível do plugin para poder montar a especificação conceitual do sistema. Tem alguma leitura que você recomende?

Abraços
Robert

[nqnnospam]

Este de fato seria o sistema ideal.

Que especificações do sistema de roteamento você quer, exatamente? A única documentação que eu tenho feita é aquele .pdf do roteamento. Ele foi escrito tendo como referência informações que estão espalhadas em vários locais (que eu me lembre: documentação do cgpsmapper, mensagens na lista map_authors, mensagens do autor do cgpsmapper, arquivos de exemplo que acompanham a distribuição do cgpsmapper e finalmente resultados de vários testes de compilação).

[Haigh]

Sérgio,

Vou ler este material e tentar compilar uns mapas de teste para entender melhor o processo. Acho que isso vai me ajudar a especificar o sistema que mencionei.

abração
Robert

[paulocarvalho]

Paulo, veja a figura abaixo, cruzamento das Avenidas Barão de Itapura e Brasil em Campinas-SP:



A seta preta indica o sentido de tráfego permitido na Av Br de Itapura.

As setas azuis indicam os sentidos de tráfego permitidos na Av Brasil (com duas pistas, separadas por canteiro central).

Observe que é permitido, saindo da Av Br de Itapura, entrar na Av Brasil nos dois sentidos (na pista correta, é claro!!!), manobras indicadas pelas setas verdes. Isto obriga a existência de dois nós de roteamento neste cruzamento (latitude , longitude: -22.8911670726492, -47.063064619692 WGS84, está mapeado no Tracksource Municipal), um para cada pista da Av Brasil.

Observe que não é permitido:

- para quem vem do canto esquerdo superior pela Av Brasil, virar à esquerda para pegar a Av Br de Itapura (seta laranja).
- fazer retorno neste cruzamento de uma pista da Av Brasil para a outra, em qualquer sentido

não sei se você já percebeu, mas é impossível, usando somente as TAGs de mão única, ou movendo os nós de um lugar para o outro, implementar as restrições acima. Para fazê-lo é necessário usar restrições de nós e vias, que especificam sequências de vias e nós que rotas não podem seguir (proibido ir do nó X da AV Brasil para o nó Y da Br de Itapura, passando pelo nó Z comum as duas avenidas).

Veja Também que este tipo de restrição complexa é muito comum em mapas municipais (só na citada Av Brasil há uma dezena de restrições deste tipo), logo elas São extremamente necessárias para os mapas municipais.

Com certeza alguém deve estar pensando "Ahh, mas podemos deixar sem estas restrições, afinal o GPS recalcula a rota automaticamente". É verdade, mas não é bem assim. Primeiro que o "recálculo" não é instantâneo. O GPS precisa de um tempo para perceber que o motorista não seguiu a rota sugerida, e mais um outro tempo para recalcular a rota, Após perceber que está fora da rota. Quanto menor o número de opções (isto é, quanto maior o número de restrições definidas) mais rápido é o recálculo, e mais eficiente é o sistema.

Exemplo, se o motorista vem descendo a Av Brasil e precisa pegar a Br de Itapura, ele precisa passar o cruzamento e seguir o caminho amarelo. Se a restrição vermelha não estiver definida, o GPS vai mandar o cidadão fazer a conversão proibida. Supondo que o motorista se toque que a conversão é proibida, o GPS tem exatamente um quarteirão para recalcular a rota e sugerir o caminho amarelo. Dependendo da velocidade do veículo (e do GPS), pode não dar tempo. Observe inclusive que no próximo quarteirão, Também há o mesmo tipo de restrição. Se estas restrições estiverem definidas corretamente, nada disso é necessário, e o sistema de auto-roteamento não corre o risco de ficar sobrecarregado recalculando rotas absurdas.

Num mapa rodoviário isto não faz diferença, principalmente porque "construções viárias" como a descrita acima São raras.

Contudo, num mapa municipal, o correto uso das restrições de nós e vias vai fazer a diferença entre um mapa Roteável utilizável e um onde o GPS só fica "recalculando".

já se cogitou inúmeras maneiras de gravar no mapa .gtm este tipo de restrição, mas como o GTM não identifica os nós de roteamento como entidades independentes do mapa, todas as solução propostas se mostraram por demais complexas de administrar.

Estamos trabalhando numa espécie de plug-in para o GTM, cujo objetivo é permitir a entrada/manipulação/administração deste tipo de informação (restrições e endereços) de forma transparente. Eu, sinceramente, acho importante manter os pés no chão enquanto não temos este plug-in pronto, para evitar decepções ou desperdício de trabalho. Acho que os desenvolvedores municipais devem sim aplicar no seu mapa .gtm a etapa de "Viadutos" descrita no manual, e acertar as tags de vias. Contudo, mais do que isso é especulação, correndo-se o risco de frustação e de ter trabalho perdido.

Sérgio, não precisa ser assim. Basta não por nós em comum e usar um pequeno artifício que já estou usando no TRU-Rio:

Veja a interseção entre a Av Pres. Vargas e a Av Passos:



A solução adotada evita os problemas que você citou e mais: evita que o roteador use a Av Passos como retorno, o que não é possível. não é necessário criar plug-ins, tags extra ou qualquer artifício elaborado. As pequenas "válvulas" forçam a única manobra possível. Isto evita Também o uso de tais situações como agulha. E não se preocupe, o mapa está no zoom máximo, em situação normal de uso, os artifícios mal irão aparecer, além do mais, pode-se fazer os artifícios tão pequenos quanto possível, desde que os nós não coincidam.

[nqnnospam]

não sei a mão da Av Passos. Sua solução funciona só se ela for mão única. Se ela for mão dupla, volta o problema das restrições.

É preciso considerar que a sua solução usa três nós a mais, que estão muito próximos de outros nós na mesma via. Isto implica em dois problemas. Primeiro, o programa compilador não aceita distâncias menores que 5,6m entre dois nós de roteamento de uma mesma via. Segundo, dependendo das circunstâncias, o roteamento vai ter que gerar várias (duas no seu caso) instruções de manobra sucessivas, o que novamente pode ser um problema.

Além disso, há outros casos onde as restrições de nós São Também necessárias. Mesmo que os aspectos do parágrafo anterior sejam contornados neste caso particular, o mesmo pode não ser possível em outras situações.

Com as restrições de nós mantemos as modificações necessárias no mapa no mínimo possível. Se temos uma solução "definitiva" (as restrições de nós), não vejo muito sentido em adotar soluções transitórias (ainda que criativas) para depois ter que refazer os mapas, ou ter mapas com problemas de roteamento (como os que eu citei na minha mensagem anterior, lentidão, recálculo contínuo, etc.).

Vale lembrar ainda que há o aspecto do endereçamento, e que a numeração precisa necessariamente ser atribuída aos nós.

Por todas estas razões acho melhor aguardar a solução apropriada, para no final termos algo que possa ser usado por todos os desenvolvedores.

Por fim, uma coisa que aparentemente ninguém se deu conta, é de que o GTM não é única solução para desenvolver mapas roteáveis. Existe, por exemplo, o GPSMapedit. Ele não é free, ainda não tem suporte automático ao endereçamento, nem tem todas as ferramentas de edição do GTM. Contudo, é voltado especificamente para o desenvolvimento de mapas roteáveis, e por isso trata os nós de forma apropriada, permitindo inclusive a definição das restrições de nós de forma gráfica (imagino que seja questão de tempo o autor implementar suporte automático ao roteamento). Do meu ponto de vista, uma solução transitória menos traumática enquanto não temos o plugin GTM, seria desenvolver o mapa em formato .mp no mapedit, e depois voltar para o formato .gtm quando o plugin estiver pronto.

[paulocarvalho]

não sei a mão da Av Passos. Sua solução funciona só se ela for mão única. Se ela for mão dupla, volta o problema das restrições.

não necessariamente. Nada impede de usar outras combinações para cobrir outros casos.

Primeiro, o programa compilador não aceita distâncias menores que 5,6m entre dois nós de roteamento de uma mesma via.

Isto não é um problema, pode-se usar conexões mais longas. Se ficar feio, basta fazer a conexão coincidente a uma das vias de modo que o artifício fique pouco visível.

Segundo, dependendo das circunstâncias, o roteamento vai ter que gerar várias (duas no seu caso) instruções de manobra sucessivas, o que novamente pode ser um problema.

Eu não acho isso.

Além disso, há outros casos onde as restrições de nós São Também necessárias. Mesmo que os aspectos do parágrafo anterior sejam contornados neste caso particular, o mesmo pode não ser possível em outras situações.

você usou a palavra "pode", o que não é definitivo. Carece apontarmos um caso que não funcionaria.

Com as restrições de nós mantemos as modificações necessárias no mapa no mínimo possível. Se temos uma solução "definitiva" (as restrições de nós), não vejo muito sentido em adotar soluções transitórias (ainda que criativas) para depois ter que refazer os mapas, ou ter mapas com problemas de roteamento (como os que eu citei na minha mensagem anterior, lentidão, recálculo contínuo, etc.).

não seria preciso refazer. Primeiro, pode-se muito bem adotar uma nova solução e deixar a antiga, pois os mapas continuariam a funcionar. Segundo, um algoritmo simples poderia colapsar essas conexões, que São objetos de topologia conhecida e restrita, em um único ponto comum às vias.

Vale lembrar ainda que há o aspecto do endereçamento, e que a numeração precisa necessariamente ser atribuída aos nós.

Isso é um outro problema. Mas já pensei no assunto, inclusive mandei um e-mail para o Amílton, sugerindo a geração de enderaçamento usando interpolação linear (se desejar tenho que criar uma thread separada para explicar melhor) a partir de apenas três tags a serem colocadas para a via, bastando conhecer o primeiro e o último números da via e em que extremo da via está o primeiro número. Existem mapas, pelo menos no caso do Rio no sistema Cadlog de domínio público, de onde se poderia obter tais informações. Mas enfim, o endereçamento não é essencial.

Por todas estas razões acho melhor aguardar a solução apropriada, para no final termos algo que possa ser usado por todos os desenvolvedores.

Sérgio, essa é uma solução que não requer reedição do mapa para se adotar outra, conforme as razões explicitadas acima.

Por fim, uma coisa que aparentemente ninguém se deu conta, é de que o GTM não é única solução para desenvolver mapas roteáveis. Existe, por exemplo, o GPSMapedit. Ele não é free, ainda não tem suporte automático ao endereçamento, nem tem todas as ferramentas de edição do GTM. Contudo, é voltado especificamente para o desenvolvimento de mapas roteáveis, e por isso trata os nós de forma apropriada, permitindo inclusive a definição das restrições de nós de forma gráfica (imagino que seja questão de tempo o autor implementar suporte automático ao roteamento). Do meu ponto de vista, uma solução transitória menos traumática enquanto não temos o plugin GTM, seria desenvolver o mapa em formato .mp no mapedit, e depois voltar para o formato .gtm quando o plugin estiver pronto.

Sem dúvida alguma melhores ferramentas e técnicas aparecerão, mas não há porque não fazer o mapa Roteável usando a solução proposta. Pelo menos quero terminar a rede das artérias viárias e mandar para o Amílton a fim de gerar um mapa experimental. Temos que testar. Pode ser que fique ruim, mas Também pode ser que fique bom. E por que não?