Numeraça£o de ruas

[BDG]

Estou colaborando com o projeto no desenvolvimento do mapa de Araraquara/SP. A cidade está praticamente toda mapeada, então agora estou partindo prá fase do roteamento.
Passei a trabalhar apenas com o Mapedit, editando diretamente o arquivo .MP. Pelo que pude notar, as versões mais novas do Mapedit não tem muitos dos problemas relatados aqui no forum, e estou conseguindo mexer no mapa com relativa facilidade.
Grande parte das ruas já está com a mão de direção correta, e com as restrições. então parti prá entender como funciona a numeração das ruas. Notei que alterar a numeração no Mapedit seria um processo extremamente trabalhoso e sujeito a erros, pois é necessário colocar a numeração inicial e final em cada nó. Bom, aqui entra o motivo real do meu post:
Como "dou minhas cacetadas" em programação, fiz um programa que faz a numeração automaticamente, precisando apenas do ponto de início da via. Como a numeração das ruas é feita em metros a partir da origem, fica fácil construir automaticamente a numeração, convertendo as coordenadas em metros. O programa ainda mostra no Google Maps como estava a numeração, e como vai ficar. Após converter o mapa e passar pro GPS, e a busca por endereços funciona certinho, com uma precisão mais que razoável, com menos de 10m de erro para encontrar um endereço, em média. O programa ainda mostra as vias em ordem alfabética e permite que você altere os nomes das vias, o que facilita bastante encontrar "pedaços" de vias com nomes diferentes, e até a colocar nomes nas vias que ainda não tem, pois você pode visualizá-las no Google Maps, e ter a referência exata de onde está a via sem nome. Se der sorte, o Google Maps pode te mostrar o nome da via, aí é só alterar.
Estou enviando uma imagem do programa nesse post, prá vocês terem uma idéia. Se alguém quiser, posso enviar o programa, ou colocá-lo em algum site prá download.
Qualquer crítica sobre o procedimento que descrevi acima, Também é benvinda.

Abraços,
Bento Carlos do Amaral

[nqnnospam]

Muito interessante o seu programa.

Contudo, considere a seguinte situação:

1) O mapa fonte está no formato GTM
2) Usa-se o Conversor para converter para PFM
3) Usa-se o seu programa para colocar endereços no PFM
4) É feita alguma modificação no mapa no formato GTM
5) É necessário usar o Conversor novamente

Como aproveitar todas as informações de endereçamento inseridas no passo 3, na nova conversão feita no passo 5, para que não seja necessário digitar tudo novamente?

Sobre a numeração por distância, ela não é válida em todas as cidades. Sem dúvida é melhor que informação nenhuma, mas pode não servir em vários casos.

[BDG]

Contudo, considere a seguinte situação:

1) O mapa fonte está no formato GTM
2) Usa-se o Conversor para converter para PFM
3) Usa-se o seu programa para colocar endereços no PFM
4) É feita alguma modificação no mapa no formato GTM
5) É necessário usar o Conversor novamente

então, como eu te disse, o município de Araraquara está com o traçado de ruas praticamente completo, e não vejo razão para retornar ao arquivo GTM, já que o projeto vai compilar Também os mapas do TM com o cGPSMapper. Caso recebamos contribuições, podemos adicioná-las diretamente no arquivo PFM, já que o Mapedit lê arquivos GPX. Outras alterações menores podem ser feitas diretamente no PFM. É claro que o Trackmaker é muito mais amigável e tem mais recursos, mas perder todas as informações de roteamento a cada alteração que se precisa fazer no mapa, é um preço muito alto a pagar, na minha opinião.

Como aproveitar todas as informações de endereçamento inseridas no passo 3, na nova conversão feita no passo 5, para que não seja necessário digitar tudo novamente?

Claro que a situação que descrevi acima se aplica ao município de Araraquara, onde o pequeno número de contribuições em termos de traçados de vias justifica esse procedimento, na minha opinião. Mas creio que muitas cidades ainda estejam com o mapa bastante incompleto, isso quando o mapa existe...
O que imagino que possa ser feito nessa situação que você propõe, é o seguinte, lembrando que ainda não pesquisei a fundo a estrutura dos arquivos, e posso estar falando besteira:

1 ) Salva-se o arquivo GTM no formato TXT;
2 ) através do desenvolvimento de um utilitário simples, pode-se ler o arquivo TXT, e incluir no nome da rua (que não se perde), um TAG com um índice. Prá ficar claro: Esse utilitário abre o arquivo TXT, lê as ruas e altera o nome delas, inserindo um tag com um índice sequencial. Exemplo:
Nome de rua no arquivo txt antes da alteração:n,R Jose da Silva<z=0>,0,1
Nome de rua no arquivo txt depois da alteração:n,R Jose da Silva[IDdaVia=NNNN]<z=0>,0,1
Onde NNNN é um número que o próprio utilitário irá atribuir, sequencialmente. Esse procedimento é feito apenas uma vez no mapa todo, e cada vez que uma rua é adicionada.
3 ) Converte-se o arquivo TXT para o formato PFM, usando o conversor.
4 ) Usando o mesmo utilitário do item 2, abre-se o arquivo PFM, e troca-se os RoadID gerados pelo conversor, pelos IDdaVia embutidos no nome.
5 ) Inclui-se as restrições, numeração, etc, e salva-se o PFM
6 ) O mesmo utilitário super ninja mega power abre o PFM, e salva as restrições, endereços, e demais detalhes que só fazem sentido no arquivo PFM, num arquivo à parte.
7 ) Caso seja necessário editar o GTM, é só editá-lo normalmente, salvá-lo como txt, e retornar ao passo 3, só que a partir daí, no passo 4 o utilitário além de trocar os RoadID, irá abrir o arquivo salvo à parte e incluir as restrições, numeração, etc que foram anteriormente salvas.
8 ) Chegando o momento de enviar o arquivo para compilação, salva-se um backup, que é o "fonte". Pega-se a cópia, que será enviada, e usando o utilitário, remove-se as tags [IDdaVia=NNNN] dos nomes das ruas.

Pode parecer complexo, mas é a única forma que vejo para preservar as restrições no momento. Se o pessoal achar a idéia interessante, posso me comprometer a desenvolver o utilitário.

Sobre a numeração por distância, ela não é válida em todas as cidades. Sem dúvida é melhor que informação nenhuma, mas pode não servir em vários casos.

Eu não sabia disso, achei que a numeração em metros fosse a regra. Mas posso alterar o programa para usar uma unidade métrica diferente, ou simplesmente aceitar a numeração inicial e final da via, e interpolar os pontos intermediários.

Se alguém tiver alguma outra idéia ou crítica, estamos aí.

Abraços,
Bento

[nqnnospam]

O seu aplicativo está em que linguagem?

A sua idéia de um outro aplicativo é interessante, e eu penso de forma semelhante. Só acho que:

- o Conversor é que deveria ser adaptado para ler este arquivo auxiliar e aproveitar as informações de restrições e endereço

- O arquivo auxiliar seria o próprio arquivo PFM

- O programa para inserir restrições seria o Mapedit mesmo, ou então o GTM, com um plugin específico (na forma de uma DLL) para o Projeto, com estas funções.

O problema básico agora é que escrevi o Conversor em Delphi(Argh), o para escrever o plugin seria melhor usar C++. A não ser que alguém saiba como criar uma DLL com o Delphi que possa conversar com um programa escrito em C++ (TrackMaker), sem ter que "reinventar a roda" (como parece ser necessário no Delphi toda vez que se quer fazer algo um pouquinho mais avançado).

[BDG]

O programa está em VB 6.
É, com certeza se o conversor fosse adaptado, ficaria mais fácil, seriam menos passos entre a conversão do GTM pro PFM, e o processo ficaria mais simples.
Também acho uma boa idéia o arquivo auxiliar ser o próprio PFM. O conversor, ou o programa auxiliar, deve então alterar os IDs das vias do PFM recem convertido baseado no PFM auxiliar, e adicionar automaticamente tags e ID's nas ruas que não tenham as tags de ID no nome, tanto no recém convertido, como no auxiliar.
Quanto à adicionar as restrições, acho que por enquanto o melhor meio é usando o Mapedit mesmo, por falta de coisa melhor. Mas se fosse criado um componente prá inserir restrições direto no GTM, todos os problemas seriam resolvidos, pois seria extremamente simples a partir daí fazer com que o GTM exportasse o arquivo no formato PFM, e fim da gambiarra...
Ah, e o Trackmaker não é feito em C++ não, é feito em VB. Se fizer uma dll ou ocx no VB, teoricamente fica absurdamente fácil pro programador do GTM adicionar a função. Isso, se o GTM não tiver que passar por alterações muito radicais na forma como ele manipulas as vias e nós, prá poder exportar. O ideal seria entrar em contato com o programador, pois nem faço idéia de que parâmetros essa dll ou ocx deveria receber e quais deveria retornar, para se adaptar ao GTM.

Abraços,
Bento

[Wallace]

não esquecer que temos Também os mapas do projeto para o Trackmaker.

[BDG]

Bem lembrado, Wallace...

Mas acho que isso dá prá resolver...É só fazer outro programinha ninja prá converter o PFM prá TXT do Trackmaker. Usando o próprio arquivo "tabela_conversao.csv" do Conversor, creio que dê prá reverter sem grandes problemas, mas o Sérgio pode dizer melhor do que eu. De qualquer forma vou fazer meus testes aqui e mantenho todo mundo informado.

Abraços,
Bento

[nqnnospam]

Sobre o VB, foi o Odilon (autor do TrackMaker) mesmo que sugeriu fazer o plugin em C++.

Uma coisa que não deve ser esquecida é que o formato oficial do Projeto ainda é .gtm. Os arquivos fora desse formato não serão compilados.

[BDG]

Sobre o VB, foi o Odilon (autor do TrackMaker) mesmo que sugeriu fazer o plugin em C++.

Entendi. Bom, pena que aí não posso ajudar, C++ prá mim é Aramaico...

Uma coisa que não deve ser esquecida é que o formato oficial do Projeto ainda é .gtm. Os arquivos fora desse formato não serão compilados.

Sim, mas e as restrições e endereços ?
O que eu pensei em mandar pro responsável pelo desenvolvimento de Araraquara, (que checaria a contribuição e enviaria ao compilador) seria:

1 ) O arquivo GTM, com todas as tags, tudo certinho, prá ser usado nos mapas do Trackmaker, e nos mapas municipais não roteáveis, se for o caso;
2 ) O arquivo PFM, com os mesmos dados do GTM mais as restrições e endereços, pro mapa municipal rotável.

Se o Ary, que é o responsável por Araraquara, enviar isso, o compilador simplesmente vai ignorar o arquivo PFM ?

Abraços,
Bento

[casaretto]

Bento.

Como vc sabe, estamos atrás de soluções para implemantar os endereços e retrições e o seu trabalho pode ajudar.

Gostaria de conhecer seu programa e bater um papo com você sobre o desenvolvimento, porque temos algumas premissas que tem de ser respeitadas, como a manutenção das informações, compatibilidade com o modelo GTM, etc.

Fico no aguardo.
Paulo

casaretto@gmail.com

[BDG]

Casaretto, acabei de te enviar um email.

Estou trabalhando agora num programa prá converter o arquivo .MP em TXT do Trackmaker, (usando o próprio arquivo tabela_conversao.csv usado pelo Conversor) prá manter a compatibilidade com o projeto. Percebi que vai ser relativamente simples, imagino que até amanhã ou no máximo quarta eu já tenha uma Versão beta.
Acho que quem sofreu mesmo foi o Sérgio, prá converter do GTM prá .MP, que parece ser bem mais complexo...

Abraços,
Bento

[casaretto]

Bento


Lembre que estamos mudando o padrão.
Tudo bem, fazendo com base na tabela, em princípio não haverá problema, porque basicamente seria substituir a tabela.

Temos grande interesse em que voce, com toda essa vontade de trabalhar, nos ajude no desenvolvimento de ferramentas.
O "Desconversor" é uma das nossas necessidades.

Mande o outro aplicativo para mim.

paulo

[BDG]

Mande o outro aplicativo para mim.

Te mandei uma MP, acho que o email você não chegou a ver.

Lembre que estamos mudando o padrão.
Tudo bem, fazendo com base na tabela, em princípio não haverá problema, porque basicamente seria substituir a tabela.

É, mas eu já encontrei uns probleminhas. Alguns tipos de POI mais específicos (e que melhor descrevem o tipo de POI, para busca no GPS) do Mapedit não existem na tabela de conversão. Por enquanto estou convertendo esses específicos prá tipos genéricos, de mesma categoria, usados no Trackmaker. Depois a gente estuda e vê o que faz, se deixamos assim, ou se incrementamos a tabela de conversão adicionando esses tipos de POI.

Abraços,
Bento

[nqnnospam]

É, mas eu já encontrei uns probleminhas. Alguns tipos de POI mais específicos (e que melhor descrevem o tipo de POI, para busca no GPS) do Mapedit não existem na tabela de conversão. Por enquanto estou convertendo esses específicos prá tipos genéricos, de mesma categoria, usados no Trackmaker. Depois a gente estuda e vê o que faz, se deixamos assim, ou se incrementamos a tabela de conversão adicionando esses tipos de POI.

Sim, o Padrão atual Tracksource não explora todos os tipos de POIs existentes no padrão Garmin. Por isso o Padrão está sendo ampliado.

A minha idéia é usar na nova Versão do Conversor (que deve ser compatível com o novo padrão), a mesma tabela .mdb do Validador, para diminuir o número de tabelas. Ainda preciso conversar sobre isso com o Paulo (que está fazendo a manutenção do Validador).

O código do Conversor está pronto para receber a parte de "desconversão", pois já tem prontas todas as funções para gravar arquivos .gtm. É mesmo uma pena os aplicativos serem desenvolvidos em linguagens diferentes, e ver perdido todo este trabalho. Se tivéssemos tudo num único código, teríamos muito mais possibilidades.

[nqnnospam]

BDG, complementando, além da parte de gravação de arquivos .gtm, o Conversor já tem prontas estruturas de dados (classes) para tratar POIs, trilhas e (mais importante) os nós de roteamento.

Adicionado o código necessário para ler arquivos pfm (como você mesmo disse é bem simples de fazer), e com modificação mínimas na estrutura de dados que armazena os nós de roteamento (para incluir espaço para os endereços), o Conversor já estaria pronto para reaproveitar os endereços. Por outro lado, começando um novo aplicativo, toda a parte de tratamento de nós teria que ser refeita. Por isso eu digo que seria muito interessante se você pudesse trabalhar sobre o código atual do Conversor, em vez de criar um novo aplicativo separado, que não vai poder ser aproveitado no Conversor (e vice-versa). Seria muito interessante para o Projeto.

já as restrições não São assim tão simples de tratar, mas não é impossível de fazer. Inclusive, tenho até algumas dicas do Odilon de como armazenar no formato .gtm algumas informações que ajudariam nesta tarefa, sem ter que mudar o formato.

Se você estiver disposto, podemos conversar via Skype uma hora dessas sobre isso.

[BDG]

Por isso eu digo que seria muito interessante se você pudesse trabalhar sobre o código atual do Conversor, em vez de criar um novo aplicativo separado, que não vai poder ser aproveitado no Conversor (e vice-versa). Seria muito interessante para o Projeto.

Claro, sem problemas. Posso apanhar um pouco prá entender o código em Delphi, mas com certeza é melhor assim, do que partir do zero. Se quiser, posso te mandar o código que lê o PFM, ou até fazer um ActiveX que te retorna as vias e POIs no formato Trackmaker, para que você possa lê-lo em Delphi e fazer as alterações (aplicar o padrão) que precisa. Vou instalar o Skype aqui, e arranjar um microfone, então a gente se fala melhor.

Acho que uma das coisas que faltam, é a definição completa do novo padrão. Com um padrão abrangente, construir um conversor de qualquer formato prá qualquer outro, fica simples.
Li que o novo padrão vai abolir as tags, então tudo o que venho fazendo está se direcionando nesse sentido, mas como ainda nada é definitivo, corro o risco de fazer algo prá ter que refazer depois.

Se quiser baixar uma Versão proto-pré-alpha do desconversor que estou trabalhando, prá dar uma olhada, eis o link: http://www.gatekeeper.com.br/mp2gtm.zip.

Agora, de pato prá ganso, e sempre com todo o respeito à todos que participam do desenvolvimento, tem uma coisa que sinceramente eu não entendo no projeto: Porque ainda fazer todo o desenvolvimento baseado no GTM ? O Mapedit tem todas as funções de roteamento, restrições e numeração, se aproxima muito mais do padrão da Garmin, e ainda gera o arquivo no mesmo formato que é usado pelo cGPSMapper...
Eu vejo isso (se basear no GTM) como uma complicação, pois é necessário criar vários aplicativos intermediários, tabelas, estabelecer padrões entre dois aplicativos completamente diferentes, e torna o processo todo mais complicado. Se o desenvolvimento se baseasse no Mapedit (ou algum outro software equivalente), a única coisa que precisaríamos, seria do conversor PFM->GTM, prá poder gerar o mapa pro Trackmaker, e mesmo assim, sem tags, informações de roteamento, numeração, etc, apenas o mapa com os nomes e categorias das vias e POI's.
Os desenvolvedores trabalhariam diretamente no arquivo PFM, e iriam inserindo gradativamente as mãos de direção, restrições e endereços, de forma bem mais intuitiva, e enviariam o PFM ao compilador, que compilaria diretamente o mapa usando o cGPSMapper, e usando o conversor PFM->GTM geraria o mapa GTM.

Existe alguma razão prá isso não ser feito ?

Abraços,
Bento

[Igor]

Trabalhar no Mapedit foca o trabalho no formato Garmin e nas suas limitações.

Trabalhando no Trackmaker temos muito mais opções de estilos e pontos, conseguimos diferenciar mais e melhor as informações nos mapas.

Hoje temos os mapas para Mapsource e para Trackmaker, mas nada impede de termos mapas para Magellan Também!
Se o trabalho do grupo fosse exclusivo para Garmin, até teria sentido.

[BDG]

Entendi Igor, agora ficou claro.

Abraços,
Bento

[BDG]

Pessoal, fiz melhorias no conversor PFM->GTM.
O txt que ele gera está passando pelo validador e pelo conversor, sem problemas (pelo menos com o mapa que eu tenho aqui).
A URL é mesma:
http://www.gatekeeper.com.br/mp2gtm.zip

Qualquer problema ou sugestões, entrem em contato.

Abraços,
Bento

[casaretto]

Bento

Parece que está funcionando. Muito bom.
O Oceano está vindo como trilha de trem.


não tenho seu email nem recebi o programa de endereçamento.
Entre em contato.

Paulo
casaretto@gmail.com