EditorDeNos

[casaretto]

Espaço para discussão da ferramenta EditorDeNos.

Vou editar as mensagens, apagando algumas repetidas ou já resolvidas, tentando tornar o tópico, o mais objetivo possível.
Peço que não se ofendam ao ver suas mensagens eliminadas.

Última observação:

-O manual.pdf existe no mesmo diretório onde foi instalado o EditorDeNos. não era criado um link para ele.
-Disponibilizei a Versão 0.1.2.1 onde Também é criado um link para o manual.

[elderluis]

Acho que enquanto não for mudado o conversor e o servidor para envio dos dados, não surgirão grandes dúvidas. O manual é bastante elucidativo.

[paulocarvalho]

já mandei DOC para o Sérgio sobre como ler o XML e fazer o cruzamento de dados entre o .GTM e o .GTI.

[elderluis]

Existe alguma previsão de quando o sistema será alterado para que possamos enviar/atualizar as informações? Tenho mais de 70 restrições de manobras prontas para meu mapa (São Bernardo do Campo/SP) e assim que for possível já enviarei. Creio que o comportamento do mapa e roteamento sofrerão alterações significativas.

[casaretto]

Uma notícia boa e uma ruim.

O sistema, desde ontem, está pronto para receber os arquivos gti.
O que não está pronto ainda, é o conversor. Temos de aguardar o Sergio liberar uma nova Versão que leia os gti.

Paulo

[paulocarvalho]

Uma notícia boa e uma ruim.

O sistema, desde ontem, está pronto para receber os arquivos gti.
O que não está pronto ainda, é o conversor. Temos de aguardar o Sergio liberar uma nova Versão que leia os gti.

Paulo

Se depender de mim, não precisa apressar o Sérgio, pois eu ainda tenho que acertar os bugs reportados pelos usuários e expandir sua funcionalidade.

[elderluis]

Quais os tipos de bug reportados? Usei exaustivamente o programa e não tive qualquer tipo de problema(como eu disse, mais de 70 resitrições de manobras até o momento, e, certamente aumentará esse número).

A única sugestão que eu daria é de poder mexer o mapa na tela com as setas do teclado e não apenas e tão somente com o botão direito do mouse pressionado. Acho que tb ajudaria, mas não considero um bug propriamente dito.

[paulocarvalho]

Quais os tipos de bug reportados? Usei exaustivamente o programa e não tive qualquer tipo de problema(como eu disse, mais de 70 resitrições de manobras até o momento, e, certamente aumentará esse número).

-Bugs mencionados no manual do programa.
-Bug causado pela abertura de um arquivo do tipo do 55300100.txt -Rodrigo
-Validar o conteúdo do TXT antes de parseá-lo (caso da receita do bolo de fubá)

A única sugestão que eu daria é de poder mexer o mapa na tela com as setas do teclado e não apenas e tão somente com o botão direito do mouse pressionado. Acho que tb ajudaria, mas não considero um bug propriamente dito.

Excelente idéia, Élder! já foi para a lista de desejos!

[paulocarvalho]

Bugs corrigidos na Versão 0.1.3, assim como inclusão de algumas sugestões.

[Wallace]

Esta uma bagunça no site.
Se baixar o .jar fica com a Versão 0.1.2
Se baixar a instalação com a Versão 0.1.3

[paulocarvalho]

Esta uma bagunça no site.
Se baixar o .jar fica com a Versão 0.1.2
Se baixar a instalação com a Versão 0.1.3

já avisei o Casaretto por e-mail.

[elderluis]

Acabo de mandar uma super atualização do meu mapa e no site já abriu a possibilidade de enviar o arquivo GTI, e foi exatamente o que eu fiz. GTI enviado com dezenas de restrições de manobras.

Agora vêm algumas dúvidas:

- Na proxima atualização/publicação do meu mapa, as restrições já estarão embutidas nele, ou ainda está em teste?

- Toda vez que eu for mandar um GTM, necessariamente terei que mandar junto tb no mesmo momento o GTI? Ou no caso de não haver atualizações no GTI eu mando só o GTM?

- Posso atualizar e mandar somente o GTI, ou toda vez terei que mandar o GTM tb?

- Se eu não mandar um novo GTI, o sistema não colocará as restrições na próxima publicação do mapa ou ele utilizará o último GTI enviado?

Obrigado!

[Wallace]

Oi Pessoal,

O editor de nós simplesmente não abre o SP-ZS.
Mas se eu apagar as praças ele abre.
O que eu faço agora?
Crio o .gti sem as praças?
Vai dar algum rolo?

[casaretto]

Wallace

É erro mesmo.
Mande o gtm em PVT para o "Paulo Carvalho" <paulo.r.m.carvalho@gmail.com> para ele poder rodar o programa localmente e verificar o que é isso.

Paulo

[Wallace]

Ok, estou enviando.

[Wallace]

Esta uma bagunça no site.
Se baixar o .jar fica com a Versão 0.1.2
Se baixar a instalação com a Versão 0.1.3

já avisei o Casaretto por e-mail.

Continua como descrevi antes.

[elderluis]

Acabo de mandar uma super atualização do meu mapa e no site já abriu a possibilidade de enviar o arquivo GTI, e foi exatamente o que eu fiz. GTI enviado com dezenas de restrições de manobras.

Agora vêm algumas dúvidas:

- Na proxima atualização/publicação do meu mapa, as restrições já estarão embutidas nele, ou ainda está em teste?

- Toda vez que eu for mandar um GTM, necessariamente terei que mandar junto tb no mesmo momento o GTI? Ou no caso de não haver atualizações no GTI eu mando só o GTM?

- Posso atualizar e mandar somente o GTI, ou toda vez terei que mandar o GTM tb?

- Se eu não mandar um novo GTI, o sistema não colocará as restrições na próxima publicação do mapa ou ele utilizará o último GTI enviado?

Obrigado!

Ainda não há definição a respeito?

Paulo, tenho outra sugestão: seria interessante poder visualizar as restrições de manobras sem ter que visualizar os vértices e em qualquer zoom, ficaria uma tela muito mais limpa e mais fácil para visualizar os pontos onde ainda faltam colocar as manobras.

Da maneira atual, só é possível visualizar as manobras junto com os vértices e num determinado nível de zoom, as vezes fica tanto vértice e informação na tela que fica poluído e dificulta um pouco.

Valeu!

[paulocarvalho]

Wallace

É erro mesmo.
Mande o gtm em PVT para o "Paulo Carvalho" <paulo.r.m.carvalho@gmail.com> para ele poder rodar o programa localmente e verificar o que é isso.

Paulo

Paulo, concordo que o Editor não pode se comportar mal quando encontra o erro. Isso vou acertar, ou seja, o Editor vai mostrar uma bela mensagem de erro "Erro de sintaxe na linha 12345." e vai rejeitar o mapa, pois o mapa de SP tinha três tracks com nome truncado, ou seja, duas vírgulas juntas. Eu não queria colocar fechamento Kleene para tratar isso, pois deixa muito aberto, assim, a princípio só vou mostrar a mensagem de erro e vou abortar a carga do mapa.

[paulocarvalho]

- Na proxima atualização/publicação do meu mapa, as restrições já estarão embutidas nele, ou ainda está em teste?

Precisa do suporte do Conversor para coloca endereços e restrições no MP a partir do GTI.

- Toda vez que eu for mandar um GTM, necessariamente terei que mandar junto tb no mesmo momento o GTI? Ou no caso de não haver atualizações no GTI eu mando só o GTM?

É provável que o Sérgio programe o Conversor para rejeitar GTIs mais velhos que os GTM-pais, pois pode haver inconsistências que poderão gerar problemas para o Conversor, mesmo que seja só para abrir o mapa, dar CTRL+S e sair para deixar a data do GTI mais recente.

Posso atualizar e mandar somente o GTI, ou toda vez terei que mandar o GTM tb?

Isso será aceito, GTI mais novo que o GTM é garantia de não haver inconsistência.

Se eu não mandar um novo GTI, o sistema não colocará as restrições na próxima publicação do mapa ou ele utilizará o último GTI enviado?

Se o GTI for mais velho que o GTM correspondente é provável que o Conversor recuse.

Código: Selecionar todos

Paulo, tenho outra sugestão: seria interessante poder visualizar as restrições de manobras sem ter que visualizar os vértices e em qualquer zoom, ficaria uma tela muito mais limpa e mais fácil para visualizar os pontos onde ainda faltam colocar as manobras.

Da maneira atual, só é possível visualizar as manobras junto com os vértices e num determinado nível de zoom, as vezes fica tanto vértice e informação na tela que fica poluído e dificulta um pouco.

Your wish is my command!

[elderluis]

E aí, Paulão, muitas correções/alterações no editor de nós até o momento? qdo sairá uma nova Versão?

PS: O que é seu avatar?

[paulocarvalho]

E aí, Paulão, muitas correções/alterações no editor de nós até o momento? qdo sairá uma nova Versão?

Liberei a Versão 0.2.0 com vários bugfixes e a ferramenta de busca de problemas (trilhas com mais de 60 nós, trilhas que fazem loops e proximidade de nós de roteamento). Depende agora de alguém da coordenação atualizar os arquivos no website.

PS: O que é seu avatar?

http://exquisitelyboredinnacogdoches.bl ... angus.html .

[casaretto]

Versão Beta 2.0 já disponível para download.

Paulo

[elderluis]

Paulo, parabéns pelas correções/atualizações, já dá para notar boas diferenças na ferramenta, a questão de visualizar as restrições em qualquer nivel de zoom sem ter que visualizar os nós ficou show! Facilitou e muito!! Quem fará (ou está fazendo) as adaptações do conversor?

[paulocarvalho]

Paulo, parabéns pelas correções/atualizações, já dá para notar boas diferenças na ferramenta, a questão de visualizar as restrições em qualquer nivel de zoom sem ter que visualizar os nós ficou show! Facilitou e muito!! Quem fará (ou está fazendo) as adaptações do conversor?

Jóia, mas a evolução da ferramenta só acontece enquanto houver feedback de usuários como você, sem isso eu vou jogando algumas coisas crendo serem úteis, mas nem sempre acerto.

Quem mantém o Conversor é o Sérgio Barroso e ele parece-me ocupado devido a um curso que ele tem que ministrar (aliás às vezes o SENAC me chama para dar aulas Também). não se preocupe, o trabalho que você fez até agora não será desperdiçado.

[elderluis]

não se preocupe, o trabalho que você fez até agora não será desperdiçado.

Como eu disse anteriormente, estou ansioso para ver o mapa rodando com as restrições de manobras, creio que o compartamento do mapa vai mudar de certa forma, sem falar no roteamento propriamente dito. Qto às sugestões, espero não terem sido ofensivas ou impertinentes, mas acho que algumas coisas devem ter facilitado a vida de muuita gente aqui.

[paulocarvalho]

não se preocupe, o trabalho que você fez até agora não será desperdiçado.

Como eu disse anteriormente, estou ansioso para ver o mapa rodando com as restrições de manobras, creio que o compartamento do mapa vai mudar de certa forma, sem falar no roteamento propriamente dito. Qto às sugestões, espero não terem sido ofensivas ou impertinentes, mas acho que algumas coisas devem ter facilitado a vida de muuita gente aqui.

não foram impertinentes e sim sugestões de algém que realmente está usando a ferramenta, assim sua opinião é muito respeitada por mim.

Quantos às restrições, elas estão dando um pouco de trabalho para o roteamento dentro do Editor (espero permitir que os usuários possam testar rotas sem precisar compilar).

[elderluis]

O manual foi sendo alterado/atualizando conforme foram sendo implementadas as sugestões do pessoal???

[paulocarvalho]

O manual foi sendo alterado/atualizando conforme foram sendo implementadas as sugestões do pessoal???

Sim. Pelo menos as versões que tenho no meu HD e no repositório SVN do Projeto estão atualizadas.

[nqnnospam]

Emprego novo, e agora mal tenho tempo de ler o fórum (este ano nem tive férias).

A leitura do GTI exige muitas mudanças no Conversor. Vamos ver se esse mês consigo avançar nas modificações.

[elderluis]

Sergio, o pessoal tá parecendo carro de F1 na largada esperando o sinal verde! Muitos desenvolvedores, inclusive eu, já têm a maior parte das restrições já definidas e inseridas... e aguardam ansiosamente as modificações no conversor para ver em prática o resultado das restrições. Vamos aguardar para ver o resultado!

[paulocarvalho]

Sergio, o pessoal tá parecendo carro de F1 na largada esperando o sinal verde! Muitos desenvolvedores, inclusive eu, já têm a maior parte das restrições já definidas e inseridas... e aguardam ansiosamente as modificações no conversor para ver em prática o resultado das restrições. Vamos aguardar para ver o resultado!

Bom, enquanto o Conversor não vem, vocês poderão traçar rotas no Editor e ver o efeito das restrições com a beta 0.3.0 do Editor. Veja uma rota ser recalculada depois da colocação de uma restrição bem em cima dela!

O Dijkstra não gerou boas rotas com as restrições, assim tive que criar um algoritmo novo, já que o pessoal da pgRouting não liberou a descrição de seu Shooting Star. Nosso algoritmo Também é capaz de gerar rotas que passam mais de uma vez pelo mesmo lugar sem entrar em loop infinito. Isso é necessário, pois frequentemente temos que fazer "balões" (contornar um quarteirão, por exemplo) para respeitar uma restrição de manobra.

Divirtam-se.

[elderluis]

Paulo

Fiz alguns testes de roteamento no Editor de nós e ficou excelente! Acho que era um dos poucos detalhes que faltava no programa!! Especialmente para teste em confluÊncia de várias vias em um único ponto, ficava tanta restrição sobreposta que era complicado de visualizar alguma eventual restrição inserida indevidamente, agora com o teste dá para checar via por via se está em condições, muito bom, parabéns!

[paulocarvalho]

Emprego novo, e agora mal tenho tempo de ler o fórum (este ano nem tive férias).

A leitura do GTI exige muitas mudanças no Conversor. Vamos ver se esse mês consigo avançar nas modificações.

Sérgio, saiba que adotei o formato XML justamente para facilitar, já que ele só exige uma passada só, ao contrário do GTM que exige duas passadas (uma para ler o arquivo e outra para associar nós e tracks).

[paulocarvalho]

Paulo

Fiz alguns testes de roteamento no Editor de nós e ficou excelente! Acho que era um dos poucos detalhes que faltava no programa!! Especialmente para teste em confluÊncia de várias vias em um único ponto, ficava tanta restrição sobreposta que era complicado de visualizar alguma eventual restrição inserida indevidamente, agora com o teste dá para checar via por via se está em condições, muito bom, parabéns!

Obrigado. Mas o quão séria é a poluição visual? Manda uma captura de tela para eu ver. Nunca pensei que haveria tantas assim como você disse no mesmo lugar.

[Wallace]

não sei se tenho restrições tão complicadas, mas pode gerar alguma confusão visual sim.
O que me incomoda mais é que é criado um icone ed_nos_config.xml que é criado na area de trabalho.

[zatlima]

A minha sugestão é para que a ferramenta de teste da rota trace a rota com uma cor mais forte, pois quando se está exibindo as mãos de direção, por exemplo, fica difícil de identificar o traçado da rota no mapa.
Veja no mapa abaixo como é difícil achar a rota:

[paulocarvalho]

não sei se tenho restrições tão complicadas, mas pode gerar alguma confusão visual sim.

Nossa Senhora!

Acho que minha prioridade agora é pensar numa forma visualmente agradável de exibir as restrições. Estou aberto a sugestões.

O que me incomoda mais é que é criado um icone ed_nos_config.xml que é criado na area de trabalho.

Tem que falar com o Casaretto, pois o atalho que instalador cria não está colocando o diretório de instalação como o diretório de trabalho. O arquivo de configuração do programa é gravado sempre no diretório de trabalho. Se você quiser pode mudá-lo manualmente, editando as propriedades do atalho, a partir daí, esse arquivo passará a ser mantido no diretório especificado e não mais no Desktop.

Pessoal, tenham em mente a filosofia universalista do programa. O instalador é uma facilidade para usuários da plataforma Windows da louvável iniciativa do Casaretto. Eu ainda não parei para estudar o Inno Setup, mas tenho coisas mais prioritárias para trabalhar como a poluição visual do acúmulo de restrições no mesmo lugar.

[Wallace]

Obrigado, acertei o caminho e não gera mais o icone.

[paulocarvalho]

A minha sugestão é para que a ferramenta de teste da rota trace a rota com uma cor mais forte, pois quando se está exibindo as mãos de direção, por exemplo, fica difícil de identificar o traçado da rota no mapa.
Veja no mapa abaixo como é difícil achar a rota:

você já é o segundo a reclamar. Vou colocar uma cor mais contrastante para a rota na próxima Versão.

Na verdade cores, fontes, transparências, etc. serão opções a serem configuradas pelo usuário para seu maior conforto visual. Pretendo colocar personalização nas versões mais futuras. Por hora estou concentrando os esforços nas funcionalidades primárias do Editor.

[elderluis]

Mas o quão séria é a poluição visual? Manda uma captura de tela para eu ver. Nunca pensei que haveria tantas assim como você disse no mesmo lugar.

Veja só esse ponto circulado em azul, diga-se de passagem é o centro de São Bernardo do Campo, ao lado da prefeitura, lugar onde de grande probabilidade de se transitar ou do roteamento passar por lá.

Se vc me perguntar quantas restrições tem no meio daquela "massaroca", eu não vou te saber informar, só sei que no dia que eu inseri, respirei fundo, prendi a respiração e fiz td de uma vez, pq é cheio de acesso, conversão, etc, etc, e se eu parasse, não conseguiria continuar depois.

Outra coisa, vc consegue visualisar de onde pra onde é cada restrição? Tb não dá, talvez nesse caso de sobreposição de alguuns trechos da restrição, elas poderiam ficar em cores diferentes para não se misturares, ou sei lá, no vértice de onde começa ou termina a restrição, colocar um "número" que pode ser sequencial de acordo com o número de restrições colocadas no mapa.

[zatlima]

Oi Paulo

Acho que sua cabeça deve estar fervendo com tantas sugestões e críticas, mas pode ter certeza que só queremos contribuir.
Acho que uma boa alternativa é usar o processo do MapEdit: quando se clica sobre um nó Roteável, ele abre todas as possibilidades de conersões e você vai marcando e desmarcando as restrições.
Veja a figura:

[casaretto]

Eu acho que o formato que o Paulo desenvolveu, é "confuso" como toda coisa nova a qual não estamos acostumados.
Em pouco tempo acostumei e percebi as vantagens, como o teste de roteamento extremamente fácil, a seleção da restrição pela seleção de um arco, etc.

A grande vantagem em relação ao Mapedit que eu vejo, é fazer tudo na mesma janela, sem abrir mais nada, tanto a manutenção como os testes.

Fico com este formato.

Paulo

[elderluis]

Paulo

Em meio a essa saraivada de sugestões, críticas e comentários, tenho mais uma consideração a ser feita. Diz respeito à situação em que eu postei aquela imagem do mapa onde várias restrições se sobrepõe.

não é razoável, lógico ou msm inteligente dimensionar algo de acordo com a exceção e não com a regra, portanto, acho que devemos nos preocupar com as situações rotineiras e não com aquela que é caso único. Dentro dessa consideração eu daria a sugestão de qdo acontecer de 2 ou mais restições ficarem sobrepostas, os segmentos de track que tiverem restrições sobrepostas poderiam mudar de cor, por exemplo ficarem azul. Acho que seria o mais racional a ser feito. Andei olhando meus outros mapas e nenhum outro tem algo parecido com o da imagem que eu mandei, portanto, vamos olhar a regra e não a exceção.

[paulocarvalho]

Mas o quão séria é a poluição visual? Manda uma captura de tela para eu ver. Nunca pensei que haveria tantas assim como você disse no mesmo lugar.

Veja só esse ponto circulado em azul, diga-se de passagem é o centro de São Bernardo do Campo, ao lado da prefeitura, lugar onde de grande probabilidade de se transitar ou do roteamento passar por lá.

Se vc me perguntar quantas restrições tem no meio daquela "massaroca", eu não vou te saber informar, só sei que no dia que eu inseri, respirei fundo, prendi a respiração e fiz td de uma vez, pq é cheio de acesso, conversão, etc, etc, e se eu parasse, não conseguiria continuar depois.

Outra coisa, vc consegue visualisar de onde pra onde é cada restrição? Tb não dá, talvez nesse caso de sobreposição de alguuns trechos da restrição, elas poderiam ficar em cores diferentes para não se misturares, ou sei lá, no vértice de onde começa ou termina a restrição, colocar um "número" que pode ser sequencial de acordo com o número de restrições colocadas no mapa.

está horrível. Definitivamente vou ter que mudar. já anotei suas idéias.

[paulocarvalho]

Oi Paulo

Acho que sua cabeça deve estar fervendo com tantas sugestões e críticas, mas pode ter certeza que só queremos contribuir.
Acho que uma boa alternativa é usar o processo do MapEdit: quando se clica sobre um nó Roteável, ele abre todas as possibilidades de conersões e você vai marcando e desmarcando as restrições.
Veja a figura:

já cogitamos isso. O Rodrigo Severo já havia pedido isso antes. Mas a minha preocupação é a conferência do mapa só olhando e arrastando o mapa. Além disso, tenho que pensar na compatibilidade com o sistema de busca automática de locais suspeitos de terem que receber restrições.

[paulocarvalho]

Eu acho que o formato que o Paulo desenvolveu, é "confuso" como toda coisa nova a qual não estamos acostumados.
Em pouco tempo acostumei e percebi as vantagens, como o teste de roteamento extremamente fácil, a seleção da restrição pela seleção de um arco, etc.

A grande vantagem em relação ao Mapedit que eu vejo, é fazer tudo na mesma janela, sem abrir mais nada, tanto a manutenção como os testes.

Fico com este formato.

Paulo

Sim, mas tenho que melhorar a aparência das restrições de forma a não haver confusão visual.

[paulocarvalho]

Paulo

Em meio a essa saraivada de sugestões, críticas e comentários, tenho mais uma consideração a ser feita. Diz respeito à situação em que eu postei aquela imagem do mapa onde várias restrições se sobrepõe.

não é razoável, lógico ou msm inteligente dimensionar algo de acordo com a exceção e não com a regra, portanto, acho que devemos nos preocupar com as situações rotineiras e não com aquela que é caso único. Dentro dessa consideração eu daria a sugestão de qdo acontecer de 2 ou mais restições ficarem sobrepostas, os segmentos de track que tiverem restrições sobrepostas poderiam mudar de cor, por exemplo ficarem azul. Acho que seria o mais racional a ser feito. Andei olhando meus outros mapas e nenhum outro tem algo parecido com o da imagem que eu mandei, portanto, vamos olhar a regra e não a exceção.

O mapa do Wallace parece estar bem poluído Também, com muitas restrições encadeadas, fica difícil saber onde uma começa e onde outra termina, tem que ficar fazendo rotas de teste no lugar para descobrir. Eu gostaria de que a conferência fosse meramente visual, com um mínimo de cliques do mouse. O objetivo do Editor é justamente facilitar ao máximo uma tarefa inerentemente laboriosa.

[Wallace]

Bem no meu mapa eu sei o que faz o que rs rs
Acho que bastaria quando selecionar algum segmento ele destacar de alguma forma os segmentos relacionados na restrição de manobra especifica.

[elderluis]

Bem no meu mapa eu sei o que faz o que rs rs
Acho que bastaria quando selecionar algum segmento ele destacar de alguma forma os segmentos relacionados na restrição de manobra especifica.

Eu tb sei o que faz o que, mas depois que passa um tempo, vc acaba esquecendo de algum detalhe... é claro que se vc observar o sentido das vias tb dá para saber o que tem ali no meio, mas se houvesse uma forma visual mais rápida, seria bem melhor. Como eu disse anteriormente, esses momentos de "ninho de cobra" São raros, acho que uma simples mudança de mudar de cor qdo houver 2 ou mais restrições em um msm arco já ajudaria e muito.

[paulocarvalho]

Bem no meu mapa eu sei o que faz o que rs rs
Acho que bastaria quando selecionar algum segmento ele destacar de alguma forma os segmentos relacionados na restrição de manobra especifica.

Se você evocar a ferramenta de restrições (CTRL+Q) e clicar em um segmento, todas as restrições que passam pelo segmento mudam de cor.

[Hélcio Assis]

- Bom dia a todos, estou com uma dúvida e gostaria se possível de alguma dica com relação ao que pode estar acontecendo!

Após gravar o .TXT passo o mesmo pelo validador e esta ok, passo pelo conversor e esta tudo ok, porém quando submeto este arquivo ao Editor de nós e executo a opção de localizar problemas (+ de 60 nós) o mesmo me apresenta a informação que possuo algumas vias assim!

A dúvida é que o conversor Também executa esta opção de verificar vias com mais de 60 nós e não me apresenta nenhuma notificação, já o Editor me mostra estas vias informando que elas possuem mais de 60 nós!

Alguém tem alguma idéia do que pode estar acontecendo?

[elderluis]

Tive um problema nesse sentido tb, a solução que eu encontrei foi de identificar qual trilha que está com mais de 60 nós e dividir ela no meio, fazendo outro track de msm nome e continuação no outro, na hora da navegação não se nota a diferença, porém, em termos técnicos vc passa a ter 2 tracks de 30 nós para o sistema, o que é bastante tranqüilo.

[paulocarvalho]

Após gravar o .TXT passo o mesmo pelo validador e esta ok, passo pelo conversor e esta tudo ok, porém quando submeto este arquivo ao Editor de nós e executo a opção de localizar problemas (+ de 60 nós) o mesmo me apresenta a informação que possuo algumas vias assim!

A dúvida é que o conversor Também executa esta opção de verificar vias com mais de 60 nós e não me apresenta nenhuma notificação, já o Editor me mostra estas vias informando que elas possuem mais de 60 nós!

Alguém tem alguma idéia do que pode estar acontecendo?

Hélcio, não me lembro agora se o Sérgio já corrigiu o bug da rotina de quebra automática. É que a rotina quebrava o track em partes com menos de 60 nós, mas elas não ficavam encadeadas no mapa, impedindo rotas de passar ali. O Validador só verifica a formatação das TAGs, nomes, estilos, cores etc, ele não vai contar o número de nós. Nos meus mapas, eu preventivamente cortei manualmente esses tracks, depois disso o TRU-Rio não teve mais problemas de descontinuidade de vias longas. Assim, coloquei essa busca para que outros desenvolvedores possam fazer o mesmo. No dia em que o Conversor não tiver mais esse bug, essa busca não terá mais sentido.

[Hélcio Assis]

- Ok Paulo, só que você se referiu ao validador na sua mensagem e eu disse que quem verifica o número de nós é o Conversor!

Acho que ter me referido na mensagem Também ao Validador pode ter causado confusão!

[elderluis]

Nos meus mapas as vias com mais de 60 nós eram rodovias ou então as grandas avenidas urbanas, as quais eu tb separei manualmente conforme eu havia explicado anteriormente.

[Hélcio Assis]

- Exatamemente Elder, é o mesmo caso meu!

[nqnnospam]

Helcio, não sei se entendi corretamente sua mensagem, mas é preciso verificar o mapa manualmente, para contar o número de nós na via, e verificar porque a discrepância entre a informação do Conversor e a do Editor de nós. Pode haver bug num dos programas, ou até em ambos.

Observe que o Conversor ainda não considera vias com mais de 60 nós um erro no mapa, e por isso não apaga os arquivos de saída. você tem certeza de que o Conversor não está apontando vias com mais de 60 nós? Pergunto porque o cgpsmapper (o programa de compilação) se recusa a compilar mapas que contenham vias com mais de 60 nós, e até agora desconheço qualquer problema neste sentido, o que é uma indicação de que a função do Conversor está funcionando corretamente na identificação das vias com mais de 60 nós, apesar de falhar na correção automática do problema (como corretamente relatou o Paulo Carvalho).

[elderluis]

Sérgio

Talvez realmente tenha algum tipo de problema nesses aplicativos, recentemente estive ajudando na adaptação dos mapas municipais para Roteável e tive(mos) algumas surpresas:

- otmizador não acusava (ou ignorava) o cruzamento entre vias que não existe um nó em comum entre elas, aliás, sem nenhum nó em ambas as vias;

- Otimizador e conversor não tiveram constância na indicação de erros, ao submeter o mapa para avaliação, indicava um determinado número de erros, fechando o aplicativo, abrindo denovo e fazendo nova checagem no msm arquivo sem fazer alteração, mostrava outra quantidade de erro ou as vezes não acusava erro como se o mapa estivesse pronto;

- cheguei a fazer todas as etapas de conversão de um mapa (Laranjal Paulista), os 3 aplicativos (conversor, otimizador e validador) ao término não indicavam qualquer erro e convertiam o mapa para .mp, porém, ao devolver para o desenvolvedor cadastrado no site ao refazer as checagens no mapa, mas desta vez na máquina dele, com os aplicativos dele, chegava a acusar mais de uma centena de erros, o que é um discrepância extrema.

Conversamos sobre o comportamento totalmente diferenciado entre os aplicativos, e todos da última Versão publicada no site, e não conseguimos chegar a conclusão do motivo dessa diferença.

Repito e observo que tanto eu quanto o outro desenvolvedor utilizamos exatamente o mesmo aplicativo e a mesma Versão baixadas inclusive no msm dia.

[Hélcio Assis]

- Bom dia Sérgio, verifiquei manualmente a quantidade de nós das vias que São me apontadas como tendo mais de 60 nós e os mesmos São bem menores que 60!
Pelo que entendo mesmo o conversor não considerando vias com mais de 60 nós um erro no mapa o mesmo me relata se esta via existir, estou certo?

Tenho certeza absoluta que o conversor não esta apontando vias com mais de 60 nós pois como você disse se isto estivesse acontecendo o mapa que sou desenvolvedor não estaria sendo compilado pelo Cgpsmapper.

será Sérgio que pode haver um bug no editor que esteja fazendo ele entender pontos como nós?

[paulocarvalho]

- Bom dia Sérgio, verifiquei manualmente a quantidade de nós das vias que São me apontadas como tendo mais de 60 nós e os mesmos São bem menores que 60!
Pelo que entendo mesmo o conversor não considerando vias com mais de 60 nós um erro no mapa o mesmo me relata se esta via existir, estou certo?

Tenho certeza absoluta que o conversor não esta apontando vias com mais de 60 nós pois como você disse se isto estivesse acontecendo o mapa que sou desenvolvedor não estaria sendo compilado pelo Cgpsmapper.

será Sérgio que pode haver um bug no editor que esteja fazendo ele entender pontos como nós?

Hélcio, não há a menor chance de ser bug no Editor. Veja o código que faz essa verificação:

Código: Selecionar todos

            if((t.getArcos().size()+1) > 60){
                modelo.addElement(t);
                foi_encontrado = true;
            }

Eu simplesmente conto o número de arcos de um track e somo mais 1 para ver a quantidade de nós. não tem erro.

[nqnnospam]

elderluis, o Otimizador só identifica cruzamentos entre vias que usam formatação incluída no padrão antigo. "Grande Rio" e "Curva de nível secundária", por exemplo, não São verificadas. Trocar de computador não altera o funcionamento dos aplicativos. Só poderei fazer uma análise da situação com informações mais detalhadas: mapa onde ocorreu o problema, detalhes das discrepâncias encontradas (O quê? Onde? Qual aplicativo?)

Helcio, para que eu possa fazer uma verificação no Conversor, peço que você envie para mim o mapa onde existe esta discrepância entre o Conversor e o Editor de nós, nomeando as vias onde existe a discrepância. Obrigado.

[nqnnospam]

Eu simplesmente conto o número de arcos de um track e somo mais 1 para ver a quantidade de nós. não tem erro.

Paulo, no Conversor a verificação é feita de forma semelhante, logo é muito difícil (mas não impossível ) haver um bug :

Código: Selecionar todos

      
  trkRouteNodes:=ptrgtmTrack(Tracks[i])^.GetRouteNodes;
  if trkRouteNodes^.Count > 60 then begin

Vale ressaltar que o problema relacionado conhecido no Conversor é na correção automática das vias com mais de 60 nós (feita Após a identificação, claro), e não na identificação das mesmas.

[elderluis]

o Otimizador só identifica cruzamentos entre vias que usam formatação incluída no padrão antigo. "Grande Rio" e "Curva de nível secundária", por exemplo, não São verificadas. Trocar de computador não altera o funcionamento dos aplicativos. Só poderei fazer uma análise da situação com informações mais detalhadas: mapa onde ocorreu o problema, detalhes das discrepâncias encontradas (O quê? Onde? Qual aplicativo?)

Sérgio, enviarei para vc o arquivo que deu esse problema, no caso, o GTM da cidade de Laranjal Paulista.

Testando na prática, vc vai ver extamente do que estou falando...

[Hélcio Assis]

- Boa tarde Sérgio, assim que puder te envio o arquivo pois aqui do meu trabalho eles bloqueiam o envio de certos arquivos e o .GTM é um deles.

[paulocarvalho]

Eu simplesmente conto o número de arcos de um track e somo mais 1 para ver a quantidade de nós. não tem erro.

Paulo, no Conversor a verificação é feita de forma semelhante, logo é muito difícil (mas não impossível ) haver um bug :

Código: Selecionar todos

      
  trkRouteNodes:=ptrgtmTrack(Tracks[i])^.GetRouteNodes;
  if trkRouteNodes^.Count > 60 then begin

Vale ressaltar que o problema relacionado conhecido no Conversor é na correção automática das vias com mais de 60 nós (feita Após a identificação, claro), e não na identificação das mesmas.

Sérgio, seu objeto Track tem um método chamado de GetRouteNodes. Pelo nome ele retorna só nós de roteamento, certo?

O Editor conta TODOS os nós do track, sejam eles de roteamento ou não. É essa a causa da inconsistência?

[nqnnospam]

Paulo, é isso mesmo.

O limite de 60 é para o número de nós de roteamento (é isso que o Conversor conta, como você bem observou), e não para o número de nós.

Se o Editor conta o número de nós, então está explicada a inconsistência.

[Hélcio Assis]

- Ok Sérgio e Paulo, parece que o assunto esta explicado e resolvido!
Sérgio devido a solução da dúvida estou cancelando o envio do mapa que iria te enviar para a análise do problema!

[paulocarvalho]

Coloquei a Versão 0.3.3 no repositório do Projeto. Agora vamos aguardar o Casaretto dispô-la no site.

[Hélcio Assis]

- Bom dia Paulo e Sérgio, Editor funcionando perfeitamente, coerente com o Conversor.

[paulocarvalho]

- Bom dia Paulo e Sérgio, Editor funcionando perfeitamente, coerente com o Conversor.

Excelente!

[elderluis]

Paulo

Gostaria de dar outra sugestão com referência ao Editor de nós.

Hj estive testando algumas rotas no editor e notei que as rotas São traçadas nas vias principais (venidas, rodovias, etc), creio que o aplicativo deva estar como default a opção de "vias mais rápidas" e notei que o roteamento dá uma volta no mundo para chegar em lugar próximo, exatamente por priorizar as vias de maior fluxo.

não seria interessante ter uma opção de "caminho mais curto" assim como tem no MapEdit? A opção de vias mais rápidas é excelente para checar as restrições nessas vias, mas para outros testes, como por exemplo, mão de direção, tem que traçar rota em trechos pequenos, se quiser traçar um caminho um pouco maior, já complica um pouco, impedindo de fazer um teste mais detalhado e aprofundado nas vias de bairros.

Valeu!

[paulocarvalho]

Paulo

Gostaria de dar outra sugestão com referência ao Editor de nós.

Hj estive testando algumas rotas no editor e notei que as rotas São traçadas nas vias principais (venidas, rodovias, etc), creio que o aplicativo deva estar como default a opção de "vias mais rápidas" e notei que o roteamento dá uma volta no mundo para chegar em lugar próximo, exatamente por priorizar as vias de maior fluxo.

não seria interessante ter uma opção de "caminho mais curto" assim como tem no MapEdit? A opção de vias mais rápidas é excelente para checar as restrições nessas vias, mas para outros testes, como por exemplo, mão de direção, tem que traçar rota em trechos pequenos, se quiser traçar um caminho um pouco maior, já complica um pouco, impedindo de fazer um teste mais detalhado e aprofundado nas vias de bairros.

Valeu!

O nosso algoritmo (temos que dar um nome para ele!) garante o caminho de menor custo. Hoje o cálculo do custo é feito conforme você bem observou: distância / velocidade. Para fazer pelo caminho mais curto, basta fazer o custo igual à distância, é uma alteração bem pequena que já foi para a lista de desejos.

Engraçado que ele não deveria dar "votas ao mundo", mesmo usando o caminho mais rápido. De repente é uma questão de afinar o algoritmo. Talvez eu inclua uma tela de configuração para que o usuário especifique as velocidades nos diversos tipos de via.

[elderluis]

Talvez eu inclua uma tela de configuração para que o usuário especifique as velocidades nos diversos tipos de via.

não sei se essa seria a melhor alternativa, será um enorme trabalho para refazer algo que implicitamente já está feito. Basta fazer uma tabela base de referência de velocidade de acordo com a formatação da via (já especificada no GTM) que já está ótimo. Por exemplo, via pavimentada secundária = 2; estrada de terra = 1; pista pavimentada principal = 3; rodovia simples = 4; e assim por diante.

Depois, lá no menu Ferramentas, "R" ficaria para rota de maior velocidade (tendo a tabela base de velocidade como referência) e sei lá, "K" ficaria para rota mais curta, tendo referência o menor trajeto possível, independente de velocidade.

não sei se fui muito claro na sugestão, mas vamos lá... hehehe

Se tiver que especificar manualmente as vias, será o caos, só em um dos meus mapas tenho mais de 5 mil vias.... fora dos outros!

[paulocarvalho]

Depois, lá no menu Ferramentas, "R" ficaria para rota de maior velocidade (tendo a tabela base de velocidade como referência) e sei lá, "K" ficaria para rota mais curta, tendo referência o menor trajeto possível, independente de velocidade.

Gostei.

Em tempo: mandei para o repositório a Versão 0.3.4 com essa funcionalidade. Aguardar a publicação no site.

[elderluis]

Gostei.

Em tempo: mandei para o repositório a Versão 0.3.4 com essa funcionalidade. Aguardar a publicação no site.

Obrigado primeiramente pela atenção e consideração às sugestões e depois pela velocidade que São feitas as alterações e disponibilidade no projeto!

Estive testando agora há pouco a nova Versão com a rota mais Rápida e com a mais "Kurta" e a diferença é bastante grande! Ficou muito bom e mais completo para quem (como eu) gosta de fazer testes bastante detalhados e específicos.

Com o tempo daria até para implementar mais alguns atributos a essas rotas feitas pelo sistema, como por exemplo, distância de um ponto a outro, etc... mas isso aí já querer demais... hehehe

Mais uma vez obrigado!
Valeu!

[paulocarvalho]

Obrigado primeiramente pela atenção e consideração às sugestões e depois pela velocidade que São feitas as alterações e disponibilidade no projeto!

Projeto open é isso! não existe uma hierarquia ou burocracia a ser percorrida. O contato direto entre desenvolvedores e usuários acelera bastante o processo.

Com o tempo daria até para implementar mais alguns atributos a essas rotas feitas pelo sistema, como por exemplo, distância de um ponto a outro, etc... mas isso aí já querer demais... hehehe

De repente eu informo a distância percorrida na barra de status.

[elderluis]

De maneira geral, acho que o Editor já está bastante completo. A maioria das ferramentas necessárias para testes de roteamento já está implementada e funcionando perfeitamente.

Creio que boa parte das sugestões que virão, serão apenas acertos de "sintonia fina". O que eu acho mais importante é a questão de ter um ferramenta autônoma e independente para testa e cruzar informações, garantindo assim, maior confiabilidade e conseqüente qualidade no produto final. Muito bom isso.

Agora falta apenas a leitura e compilação do GTI para o ciclo finalmente se completar.

[elderluis]

Paulo

Tendo em vista eu já ter feito toda a parte mãos de direção (no (GTM) e de restrições de manobras no Editor, agora comecei a inserção de númeração de via no mapa da cidade de São Caetano do Sul, uma cidade bem pequena aqui no ABC Paulista.

Comecei a numeração pelas vias principais, inicialmente estou colocando a numeração de 500 em 500 (aproximadamente), sendo que idéia é detalhar o máximo possível posteriormente, colocando numeração em cada cruzamento. Vai ser um trabalho muito extenso, mas vai ficar um negócio de primeira.

Agora vem uma pergunta e uma sugestão (mais uma, daqui a pouco vc vai me xingar! heheeh):

-Os cruzamentos que eu não coloquei numeração e que estão entre aqueles já numerados como ficam? O próprio sistema ou GPS já faz um cáculo (linear) da numeração naqueles pontos onde não há indicação tendo base as numerações mais próximas?? Se o sistema assim fizer automaticamente, creio que esse método de colocar numeração de 500 em 500 já ajude muito. não é o ideal, mas já dá pra ter uma boa referência.

-Sugestão: algumas vias aparecem no Editor de "cabeça para baixo", não seria possível deixá-las sempre na posição normal? Eu sei que é frescura, mas depois que vc está há horas editando, colocando numeração, lendo, já começa embaralhar td na tela.. hehehe

[paulocarvalho]

-Os cruzamentos que eu não coloquei numeração e que estão entre aqueles já numerados como ficam?

No GTI ficam em branco mesmo, depois de compilado não sei como a busca de endereços vai funcionar.

O próprio sistema ou GPS já faz um cáculo (linear) da numeração naqueles pontos onde não há indicação tendo base as numerações mais próximas??

não sei. Mas você pode preencher as faltantes com a ferramenta de interpolação linear do Editor, a qual está devidamente explicada no manual do programa.

Código: Selecionar todos

Se o sistema assim fizer automaticamente, creio que esse método de colocar numeração de 500 em 500 já ajude muito. não é o ideal, mas já dá pra ter uma boa referência.

Seria interessante ver com alguém de dentro dos Correios que possa dar essa informação ou usar o Google Maps.

-Sugestão: algumas vias aparecem no Editor de "cabeça para baixo", não seria possível deixá-las sempre na posição normal? Eu sei que é frescura, mas depois que vc está há horas editando, colocando numeração, lendo, já começa embaralhar td na tela.. hehehe

Quem faz isso é um componente do pacote OpenMap. Posso editar o fonte e fazer essa alteração. Tem a ver com orientação de vetores, basta colocar um if e inverter sempre que o vetor-direção da via apontar da direita para esquerda.

[alvaroaze]

A numeração é a distância em metros do inicio da rua. então no caso acho que só o primeiro e último número da rua São necessários, não?

[Fernando Lopes]

Na minha cidade (Maringá) obtive a informação que a numeração obedece a metragem do tamanho de cada lote de terras.

[Wallace]

Em muitas cidade e vias a numeração é por metragem, mas mesmo assim o ideal (mas provavelmente inviavel de implementar) acho que seria ter a numeração em cada esquina, pois pode ter variações.

[nqnnospam]

O padrão Garmin só permite colocar numeração nos nós de roteamento, ou seja, no cruzamento de duas vias trafegáveis. Por isso o Conversor, por enquanto, está simplesmente desconsiderando informações de endereço que não estejam em nós de roteamento.

Outra coisa, a numeração deve ser colocada em todos os nós de roteamento de uma via, senão o sistema Também não funciona. Isto é uma imposição do padrão Garmin.

[elderluis]

Outra coisa, a numeração deve ser colocada em todos os nós de roteamento de uma via, senão o sistema Também não funciona. Isto é uma imposição do padrão Garmin.

Acho que não entendi muito bem, vamos imaginar 5 nós seqüênciais, somente o primeiro e o último nó têm numeração, então essa via será desconsiderada por não estar completa??

Bom, tendo o primeiro e último nó numerados, dá para usar o método de interpolação ou metragem para completar os centrais...

[nqnnospam]

Primeiro, não confundir nó com nó de roteamento.

Todo nó de roteamento é um nó, mas o contrário não é verdade.

A informação de endereçamento vale entre o nó de roteamento com informação e o próximo nó de roteamento. Se, entre dois nós de roteamento com informações de endereço, houver um nó de roteamento intermediário sem informação de endereço, a informação do último nó é perdida, e o trecho entre o nó intermediário e o último fica sem endereçamento.

Usando o exemplo do Stan:

Vamos dizer que temos uma rua simples onde a numeração muda duas vezes. Esta rua tem 20 nós (0,1,2,3,...,19), e 2 dois de roteamento (0 e 10). Para o endereçamento funcionar, temos que por informações de endereçamento nos dois nós:

RoadID | NodID | LeftStart| LeftEnd
1003 | 0 | 12 | 24
1003 | 10 | 36 | 42

então, do nó 0 ao 10 a numeração vai do 12 ao 24, e do 10 ao 19 vai do 26 ao 42

Agora, vamos supor que uma modificação foi feita no mapa e um nó de roteamento aparece no nó 5 da nossa via. Se forem mantidas as definições anteriores, não haverá endereçamento entre os nós 5 e 10. Para haver endereçamento, é necessário colocar informação de endereço no nó 5:

RoadID | NodID | LeftStart | LeftEnd
1003 | 0 | 12 | 18
1003 | 5 | 20 | 24
1003 | 10 | 36 | 42

[elderluis]

Ok Sérgio, muito boa explicação e diga-se de passagem veio no momento certo para que eu possa arrumar as vias que eu já coloquei numeração pois acho que boa parte delas não iria funcionar adequadamente.

Creio que não São muitos os desenvolvedores que começaram a inserir numeração nos mapas, motivo pelo qual acho essas duvidas não apareceram antes, aliás, muito importante essa explicação e até sugiro que seja integrada aos manuais do projeto e principalmente no manual do Editor de nós, caso ainda não conste lá (não me recordo agora se tem algo tão técnico e específico assim).

Muita gente que participa voluntariamente do projeto, principalmente como desenvolvedor, conhece o básico necessário para boa edição dos mapas (me incluo nessa lista) e essa parte extremamente técnica, detalhada e específica, como arquitetura de funciomanto do GPS acaba passando batido e alguns erros acabam acontecendo em função dor desconhecimento tão aprofundado assim, especialmente por quem não tem formação nessa área (eu por exemplo tenho formação na área de humanas).Manuais e explicações assim São sempre bem vindas!

[paulocarvalho]

A numeração é a distância em metros do inicio da rua. então no caso acho que só o primeiro e último número da rua São necessários, não?

Para esses casos o Editor tem uma ferramenta para determinar automaticamente a numeração da via. De fato você informa apenas o primeiro número e em que ponta da via começa a numeração.

[paulocarvalho]

Ok Sérgio, muito boa explicação e diga-se de passagem veio no momento certo para que eu possa arrumar as vias que eu já coloquei numeração pois acho que boa parte delas não iria funcionar adequadamente.

Creio que não São muitos os desenvolvedores que começaram a inserir numeração nos mapas, motivo pelo qual acho essas duvidas não apareceram antes, aliás, muito importante essa explicação e até sugiro que seja integrada aos manuais do projeto e principalmente no manual do Editor de nós, caso ainda não conste lá (não me recordo agora se tem algo tão técnico e específico assim).

Muita gente que participa voluntariamente do projeto, principalmente como desenvolvedor, conhece o básico necessário para boa edição dos mapas (me incluo nessa lista) e essa parte extremamente técnica, detalhada e específica, como arquitetura de funciomanto do GPS acaba passando batido e alguns erros acabam acontecendo em função dor desconhecimento tão aprofundado assim, especialmente por quem não tem formação nessa área (eu por exemplo tenho formação na área de humanas).Manuais e explicações assim São sempre bem vindas!

Élder, acho que você pode continuar a colocar a numeração nos nós verdes sem problemas, apenas o Conversor irá ignorar, é só não esquecer dos nós vermelhos e os verdes que ficam em pontas. Eu pretendo usar todos os nós num sistema que pretendo criar para celulares e PDAs que usuário um formato aberto (provavelmente uma forma eficiente do PFM), diferente do da Garmin.

[elderluis]

Élder, acho que você pode continuar a colocar a numeração nos nós verdes sem problemas, apenas o Conversor irá ignorar, é só não esquecer dos nós vermelhos e os verdes que ficam em pontas. Eu pretendo usar todos os nós num sistema que pretendo criar para celulares e PDAs que usuário um formato aberto (provavelmente uma forma eficiente do PFM), diferente do da Garmin.

Coincidentemente, coloquei numeração apenas em nós vermelhos, como eu disse, coloquei de 500 em 500, então as numerações foram caindo ao longo da via. Por sinal, ainda não consegui usar a ferramenta de interpolação pq não coloquei nº nas extremidades, apenas no início e ao longo da via, falta colocar no último nó para poder interpolar td. Hj ainda pretendo acertar as vias que eu já inicei a numeração para que possa começar a fazer as outras dentro dos conformes.

[paulocarvalho]

Élder, acho que você pode continuar a colocar a numeração nos nós verdes sem problemas, apenas o Conversor irá ignorar, é só não esquecer dos nós vermelhos e os verdes que ficam em pontas. Eu pretendo usar todos os nós num sistema que pretendo criar para celulares e PDAs que usuário um formato aberto (provavelmente uma forma eficiente do PFM), diferente do da Garmin.

Coincidentemente, coloquei numeração apenas em nós vermelhos, como eu disse, coloquei de 500 em 500, então as numerações foram caindo ao longo da via. Por sinal, ainda não consegui usar a ferramenta de interpolação pq não coloquei nº nas extremidades, apenas no início e ao longo da via, falta colocar no último nó para poder interpolar td. Hj ainda pretendo acertar as vias que eu já inicei a numeração para que possa começar a fazer as outras dentro dos conformes.

não esqueça Também das restrições que seguem a mesma idéia. Nas restrições de 3 nós o segundo nó deve ser de roteamento e nas de 4 nós o segundo e o terceiro nós devem ser de roteamento.

[elderluis]

não esqueça Também das restrições que seguem a mesma idéia. Nas restrições de 3 nós o segundo nó deve ser de roteamento e nas de 4 nós o segundo e o terceiro nós devem ser de roteamento.

Tive pouquíssima restrições de 4 nós até o momento, normalmente as conversões proibidas se consegue resolver com os de 3 nós...

Acho que o maior problema será na numeração msm, principalmente em saber qual método usar corretamente, metragem ou interpolação.... algumas cidades usam por default a metragem, mas outras é quase que aleatório...

[paulocarvalho]

Senhores,

está disponível a Versão 0.4.0 do Editor o qual gera um GTI contendo informações adicionais essenciais para o Conversor. Essa Versão Também impõe as regras de estruturação do endereçamento e das restrições em conformidade com o padrão Garmin. Essas regras forçam a colocação de números de porta somente nos nós de roteamento (vermelhos) e o segundo nó e o terceiro nó das restrições de 4 nós devem ser obrigatoriamente nós de roteamento.

Peço, portanto, aos desenvolvedores que têm GTIs contrariando essas regras, que utilizem o Editor 0.3.4 para adequar o índice a essa regras. A Versão 0.4.0 pode carregar esses GTIs sem problemas, entretanto numerações e restrições que contrariam essas regras São ignoradas e serão perdidas na próxima salva com a Versão nova.

[claudiomaracaja]

Pelo que entendo o gti , que por sinal ja estou usando para restricoes e numeracao sera convertido junto com o txt no novo conversor, minha pergunta: quando teremos esse novo conversor, é interessante porque durante o desenvolvimento costumo converter os mapas para o garmin utilizando os assim na pratica para verificar erros de roteamento. Obrigado.

[paulocarvalho]

O Sérgio, desenvolvedor do Conversor, está acertando os últimos detalhes para suporte à numeração de porta. nós disponibilizamos o Editor antes para que os desenvolvedores que mantêm esses dados possam adequar seus GTIs para a nova Versão do Conversor, já que o GTI salvo pela Versão 0.4.0 contém informações essenciais para o endereçamento que as versões anteriores não tinham. você pode testar o roteamento no próprio Editor, assim você pode se certificar de que seu mapa está certo.

Editado pela Moderação
não faz sentido fazer o quote da mensagem imediatamente acima.
Isso até atrapalha a leitura.
Quote apagado.
Agradeçemos a colaboração.

[elderluis]

Recentemente estive pesquisando sobre como é feita ou atribuida numeração às vias e cheguei à "brilhante conclusão" de que não existe um padrão definido. Mesmo nas cidades que atribuem metragem como referência, não é 100% garantido, afinal, existem bairros e regiões mais novos e mais velhos, construídos em diferentes épocas sob diferentes administrações que não necessariamente seguiram um padrão. Aliás, muito provavelmente não seguiram padrão algum.

Acho que a orientação mais adequada a ser passada aos desenvolvedores que estão colocando numeração nas vias, é utilizar o método da INTERPOLAÇÃO, talvez seja o método mais garantido de retratar a realidade.

Acho que a única via que escapa dessa minha teoria São as rodovias, essas sim seguem universalmente o padrão da metragem e pode ser, tranqüilamente, atribuida metragem a elas para se estabelecer a numeração.

[paulocarvalho]

Lembrar que no Editor é possível digitar os números manualmente.

[Wallace]

Como apago uma restrição ou modifico ?

[claudiomaracaja]

Ctrl+3 ou Ctrl+4 clica na restricao e tecla delete (del).

[Wallace]

Nada feito aqui, não funcionou na 4.0

[elderluis]

Aqui funcionou normalmente... tente a opção de restrição de 4 nós (Ctrl 4) e selecione a restrição a ser deletada. Aqui funfou normal com a Versão 4.0!

[Wallace]

Agora funcionou, mas da seguinte forma.
Crtl+3 e ai teclo e mantenho selecionado a tecla "Delete" e ai seleciono o primeiro ponto da restrição duas vezes seguidas.
Obrigado.

[paulocarvalho]

Wallace, você tinha que clicar num segmento da restrição e não nos pontos, tal como está explicado no manual. Aí você seleciona a restrição de primeira.

[elderluis]

Paulo

não entendi exatamente o motivo da nova diferenciação entre
comandos para inserção de restrições de 3 e 4 nós. Essa divisão foi feita para que o sistema trie e "autorize" o tipo de nós a ser restringido os nós no caso de restrição de 4 nós?

Acho que a forma que estava antes era suficiente, claro, a não ser se foi pelo motivo que eu citei acima.

Outra coisa que eu achei que ficou muito bom é a questão do editor abrir e ler arquivos GTM diretamente, isso além de mais prático, elimina uma etapa no processo, o que conseqüentemente elimina possibilidades erros ou bugs! Agora só falta o conversor ler arquivos GTM!

[paulocarvalho]

comandos para inserção de restrições de 3 e 4 nós. Essa divisão foi feita para que o sistema trie e "autorize" o tipo de nós a ser restringido os nós no caso de restrição de 4 nós?

É.

Acho que a forma que estava antes era suficiente, claro, a não ser se foi pelo motivo que eu citei acima.

Era suficiente, mas agora creio que ter um atalho para cada tipo dispensa o usuário de pressionar ESC na maioria das vezes já que a maioria das restrições é de 3 nós.

Outra coisa que eu achei que ficou muito bom é a questão do editor abrir e ler arquivos GTM diretamente, isso além de mais prático, elimina uma etapa no processo, o que conseqüentemente elimina possibilidades erros ou bugs! Agora só falta o conversor ler arquivos GTM!

Isso já está no prelo. Outra coisa que está em desenvolvimento é o Otimizador II, dessa vez gráfico e com mapas para trabalhar os viadutos e o tratamento de quase-conexões. Aguardem.

[nqnnospam]

O Conversor já lê .gtm, e a numeração.

já lê as restrições Também, mas estou corrigindo uns bugs.

Falta implementar a gravação da numeração e restruções em formato ESRI.

[elderluis]

Outra coisa que está em desenvolvimento é o Otimizador II, dessa vez gráfico e com mapas para trabalhar os viadutos e o tratamento de quase-conexões. Aguardem.

Por falar em Otimizador, o que aconteceu com o atual?? Ao checar os viadutos, sempre dá "0" em td.... qual foi o problema que aconteceu de uma hora para outra? Lembro que fiz uns mapas que funcionaram normalmente, depois, sempre dava zero.... mudei de micro, windows, etc, etc e continuou o problema, sem falar que vi email na lista do yahoo do pessoal reclamando da msm coisa....

[Ruy Lerac]

O Otimizador atual só trabalha com txt. A última Versão do GTM alterou um pouco a estrutura do txt gerado pelo GTM. Com isso o Otimizador não mais funciona. Isso já foi alertado na lista. Aguardem o novo Otimizador que está em fase final de testes. está muuuuito mais completo, inclusive permitindo que o desenvolvedor crie um arquivo com os viadutos reais, os quais não serão mais apontados, dispensando a verificação destes pontos toda vez que se rodava o Otimizador. Para se ter uma idéia, o TRR-SP tem mais de 1000 viadutos reais.

[paulocarvalho]

Atenção desenvolvedores! A Versão 0.4.1 traz na sua ferramenta de busca de problemas o botão "Duplicação" que faz a procura por segmentos duplicados os quais trouxeram à tona problemas de compilação por causa das restrições de manobra. Peço que usem essa ferramenta para localizar e eliminar [no Trackmaker] essas duplicações para que seus mapas possam ser compilados com suporte ao endereçamento e às restrições de manobra.

[elderluis]

Ok Paulo, já aplicado e corrigo o problema nos meus mapas. Só achei estranho a lista de arcos duplicados aparecer em "duplicidade"... hehe, parece até um trocadilho, mas não é.... mas sem stress... já corrigido.

Vc que tem tido contato mais direto com o pessoal da coordenação, alguma previsão do novo otimizador e conversor???

[paulocarvalho]

Só achei estranho a lista de arcos duplicados aparecer em "duplicidade"... hehe, parece até um trocadilho, mas não é.... mas sem stress... já corrigido.

Vou colocar uma flag de visitação para evitar essas duplicidades.

Vc que tem tido contato mais direto com o pessoal da coordenação, alguma previsão do novo otimizador e conversor???

Justamente por causa dessas duplicações é que temos tido problemas em compilar os mapas, foi o que fomentou a inclusão dessa ferramenta em caráter de urgência. Agora que descobrimos pelo menos uma grande parte dos problemas creio que agora a coisa vá andar mais rápido, mas isso vai depender Também dos desenvolvedores eliminarem essas duplicidades de seus mapas.

[elderluis]

Particularmente já eliminei de todos meus mapas, não eram muitas mas estavam lá... Pq será que acontece esse tipo de fenômeno de duplicidade?

Estranho não ter dado outros erros de conflito ou roteamento anteriormente, principalmente pelo fato de existir mais de 1 track absolutamente igual e sobreposto.

[paulocarvalho]

As duplicidades acontecem pelo uso de copiar/colar e merge. Às vezes copiamos e colamos pedaços de tracks inadvertidamente por sobre tracks que já está lá no destino. Às vezes juntamos mapas que contêm objetos em comum, gerando duplicidades. E por aí vai.

Antes não trabalhávamos com restrições. Agora quando definimos restrições e numa das pernas das restrições há dois ou mais segmentos, por exemplo, o Conversor não tem como saber em qual deles a restrição passa e pega a primeiro segmento que vem, ele então era passado para o cGPSmapper, que então reportava um erro do tipo "Unknown RoadID" ou coisa assim quando dávamos o azar de o Conversor pegar justamente o segmento errado dos possíveis.

[elderluis]

Parte desses erros podem ser atribuída ao TrackMaker? As vezes, ao editamos um novo nó de roteamento entre vias novas que se cruzam (o famoso "Ctrl B" com os tracks selecionados) por vezes aparece um segmento minúsculo ali, ou seja, aparece um outro nó além, que não é o ponto comum entre as vias. À olho nú, é absolutamente imperceptível, porém, ao aplicarmos o conversor, ele detecta um track ou segmento minúsculo e indica como uma espécie de erro. A pergunta é: pq esse segundo nó é gerado??

Dentro desses "aparecimentos" de nós aleatórios, aos quais vou nominar de "erro", é possível que aparaçam outros fatores adversos que impliquem diretamente no roteamento assim como os tracks duplos?? até agora não consegui entender o comportamento do TrackMaker nessas situações.

[Wallace]

Eu ainda não consegui baixar o novo Editor, mas não uso o copiar colar.
Os segmentos pequenos entendo que São resultado da fragmentação dos Tracks.

[paulocarvalho]

Parte desses erros podem ser atribuída ao TrackMaker?

não, pelo menos a probabilidade disso é infinitesimal dado que o Trackmaker tem 10 anos e é, portanto, uma ferramenta madura. O mais provável é erro operacional mesmo.

As vezes, ao editamos um novo nó de roteamento entre vias novas que se cruzam (o famoso "Ctrl B" com os tracks selecionados) por vezes aparece um segmento minúsculo ali, ou seja, aparece um outro nó além, que não é o ponto comum entre as vias. À olho nú, é absolutamente imperceptível, porém, ao aplicarmos o conversor, ele detecta um track ou segmento minúsculo e indica como uma espécie de erro. A pergunta é: pq esse segundo nó é gerado??

Isso não é duplicidade. Isso acontece porque raramente o extremo está exatamente sobre a linha. A rigor, matematicamente falando, a probabilidade de você acertar o extremo na linha é zero.

Dentro desses "aparecimentos" de nós aleatórios, aos quais vou nominar de "erro", é possível que aparaçam outros fatores adversos que impliquem diretamente no roteamento assim como os tracks duplos?? até agora não consegui entender o comportamento do TrackMaker nessas situações.

É possível, mas eles, caso existam, darão problemas na compilação e a partir das investigações do problema, acharemos a causa tal como foi com a descoberta dos tracks e segmentos duplicados.

[paulocarvalho]

Eu ainda não consegui baixar o novo Editor, mas não uso o copiar colar.
Os segmentos pequenos entendo que São resultado da fragmentação dos Tracks.

Mesmo assim, Wallace, a recomendação é que nós todos passemos a ferramenta. Eu, como você, tinha certeza de que não havia tracks duplicados no meu mapa até passar a ferramenta e descobrir, para minha surpresa, uns 20 segmentos duplicados. Num universo de uns 100.000 segmentos é quase nada, mas mesmo um segmento duplicado dentre 1 milhão já é o bastante para prejudicar a compilação.

[Hélcio Assis]

- Boa tarde pessoal, estou com uma dúvida e com certeza alguém aqui ira esclarecer!
Existe na página do projeto na área de desenvolvimento a opção para se baixar o OTIMIZADOR DE TRILHAS VERSÃO 3.11 DE 11/02/2008, porém quando clicarmos para fazer o download somos remetidos novamente para a página do projeto!

Este Otimizador Versão 3.11 é o antigo porém a data de atualização é mais recente, este é o novo Otimizador?
Sabem me explicar qual o motivo do erro?
Trabalho com o Trackmaker Pro Versão 4.2, sou então agora devido as mudanças obrigado a atualizar a minha Versão para a 4.3?

[Wallace]

Mesmo assim, Wallace, a recomendação é que nós todos passemos a ferramenta. Eu, como você, tinha certeza de que não havia tracks duplicados no meu mapa até passar a ferramenta e descobrir, para minha surpresa, uns 20 segmentos duplicados. Num universo de uns 100.000 segmentos é quase nada, mas mesmo um segmento duplicado dentre 1 milhão já é o bastante para prejudicar a compilação.

Eu não tinha conseguido baixar porque o site estava fora do ar.
já baixei e logo mais vou testar.

[Wallace]

Alguem modificou a formatação para algo que não existe:
Via de Acesso não existe como formatação no Trackmaker.
então meus mapas não estão passando pelo Validador.
Ou seja, sem novos desenvolvimentos, sem poder incluir mais colaborações, sem novas atualizações do meus mais de 60 mapas que desenvolvo e certamente para todos os outros.
não entendo como podem fazer algo assim.

[Wallace]

Outra coisa que reparei, no conversor não existe a opção de se minimizar o mesmo.
Algo que para mim faz falta.

[nqnnospam]

Alguem modificou a formatação para algo que não existe:
Via de Acesso não existe como formatação no Trackmaker.
então meus mapas não estão passando pelo Validador.
Ou seja, sem novos desenvolvimentos, sem poder incluir mais colaborações, sem novas atualizações do meus mais de 60 mapas que desenvolvo e certamente para todos os outros.
não entendo como podem fazer algo assim.

Wallace, ocorreu um erro no sistema de envio mensagens, e as ferramentas foram colocadas no site antes de sair a mensagem que informava sobre as mudanças.

A nosso pedido, o Odilon implementou novos formatos na nova Versão do GPSTrackMaker. Para usar o novo formato, você precisa da última Versão do GPSTrackMaker, e do programa Reformatador2, que está disponível no site.

Eu repostei a mensagem de aviso que deveria ter sido enviada aos desenvolvedores aqui no fórum.

[nqnnospam]

Outra coisa que reparei, no conversor não existe a opção de se minimizar o mesmo.
Algo que para mim faz falta.

Vou ver como implementar isso.

[elderluis]

Apliquei o novo conversor no mapa de São Caetano do Sul e ao ler o arquivo GTI com numeração das vias, recebi uma saraivada de exatos 195 avisos e o conversor criou um arquivo com 195 diamantes vermelhos sobre tais avisos. até aí sem problemas... o detalhe é que o problema (ou avisos) apareceram qdo da leitura da numeração das vias do arquivo GTI. Em outras palavras, o mapa ou GTM em si está ok, o problema está na numeração, alguns avisos São de inconsistência e outros não São especificados. Vou "colar" os últimos avisos para se ter uma idéia exata do que aparece.

*** AVISO 192 no ponto -23.61438400, -46.57369100).
*** ArquivoMP.WriteRGN40: Inconsistência nas informações de endereço LEFT, nó 20 da via AV SEN ROBERTO SIMONSEN<MU>.
*** AVISO 193 no ponto -23.61438400, -46.57369100).
*** ArquivoMP.WriteRGN40: Inconsistência nas informações de endereço LEFT, nó 21 da via AV SEN ROBERTO SIMONSEN<MU>.
*** AVISO 194 no ponto -23.61374400, -46.57356000).
*** ArquivoMP.WriteRGN40: Inconsistência nas informações de endereço LEFT, nó 21 da via AV SEN ROBERTO SIMONSEN<MU>.
*** AVISO 195 no ponto -23.61374400, -46.57356000).

Ao converter o mesmo mapa sem o GTI junto, a conversão passa 100%, o problema só acontece qdo da leitura da numeração. será que eu fiz as numerações erradas? Alguém tem alguma orientação de como tentar salvar esse trabalho td de inserção de numeração??

[elderluis]

Esqueci de citar no post anterior:

1-já apliquei o Reformatador2 no mapa de Caetano (por uma única vez, conforme orientação);
2-já apliquei o novo Validador;
3-já conferi e acertei a duplicidade de arcos no Editor de nós;

Todos os procedimentos e aplicativos atuais já foram aplicados e reaplicados no mapa ficando o conversor como última manobra de aplicação e, em todas as outroas, nenhum problema foi constatado.

[nqnnospam]

você está usando a última Versão do Editor, 0.4.1 ou 0.4.2?

[nqnnospam]

Esta mensagem, que é um AVISO, e portanto não impede (por enquanto ) a compilação do mapa, indica que o nó de roteamento em questão não possui todas as informações de endereço necessárias. não sei qual o efeito disso na compilação (aparentemente nenhum) ou no funcionamento do mapa.

Conforme explicado anteriormente, a cada nó de roteamento deve-se associar os números de endereço inicial e final do segmento que nele (no nó) começa, para cada lado onde há numeração.

[elderluis]

Estou usando a Versão 4.2. do Editor.

Bom, salvo engano, tem um tópico ou post aqui no forum, não me recordo qual exatamete, tratanto dos tais "avisos" do conversor, que apesar de ser chamado de aviso, na verdade é tratado e encarado como um erro, se não estiver enganado. Qto a numeração, usei o método da interpolação, indiquei a numeração inicial e final da trilha e o sistema inseriu automaticamente a numeração em tds os nós entre o 1º e o último nó de uma mesma via. Pode ser que esteja solicitando numeração das vias que cruzam, mas acho que não tem nada a ver, pois a numeração é de uma e não de outra... sei lá...

[elderluis]

Achei o tópico que fala de erros e avisos do conversor:

http://www.portalgps.com.br/forum/viewt ... sor#p15683

[paulocarvalho]

Este Otimizador Versão 3.11 é o antigo porém a data de atualização é mais recente, este é o novo Otimizador?

Deve ter havido um engando. O Otimizador II ainda está em fase alfa, ou seja, não está aberto ao público para testes beta.

Trabalho com o Trackmaker Pro Versão 4.2, sou então agora devido as mudanças obrigado a atualizar a minha Versão para a 4.3?

Exato.

[elderluis]

Paulo

Mais uma sugestão para o Editor de nós. Por favor, queira analisar se é útil, interessante, viável ou válida.

Na opção de "Procurar problemas", poderia ser aberto mais um campo de pesquisa: "MANOBRAS INEXISTENTES" ou "MANOBRAS" simplesmente.

não raras vezes abro um mapa no editor e no "susto" ou na "trombada" reparo algum trecho em branco no mapa, ao aproximar com o zoom, observo que tem alguma manobra "INEXISTENTE", e confesso que tenho achado esses erros na sorte. Colocando essa opção, será possível fazer uma triagem total, não só do mapa mas das restrições com problemas tb.

Abusando um pouco da vossa boa vontade e voluntariado, fica uma "sub-sugestão" agora: esse sistema poderia usar o mesmo engine do procura normal, ou seja, uma janela com a lista das manobras inválidas e ao clicar no nome da manobra, teria a aproximação automática para identificação e demonstração de irregularidade. Nessa mesma janela já poderia ser colocado um botão de delete para agilizar a correção, assim não precisa abrir o campo de procura uma vez para cada manobra, deletar manualmente, etc...

O que vc acha?? Válido?

[paulocarvalho]

Alguem modificou a formatação para algo que não existe:
Via de Acesso não existe como formatação no Trackmaker.
então meus mapas não estão passando pelo Validador.
Ou seja, sem novos desenvolvimentos, sem poder incluir mais colaborações, sem novas atualizações do meus mais de 60 mapas que desenvolvo e certamente para todos os outros.
não entendo como podem fazer algo assim.

Wallace, estamos fazendo a introdução de um padrão ainda mais intuitivo do que o que estamos usando agora. Neste novo padrão não há improvizações como por exemplo usar "Grande Rio" para representar uma via expressa urbana. Haverá um pouco de turbulência por hora, mas havá um software chamado de Reformatador para fazer a mudança automática do formato, mas os novos mapas só poderão ser abertos nas versões mais recentes do Trackmaker (13.3 na Free ou 4.3 na Pro).

[paulocarvalho]

Outra coisa que reparei, no conversor não existe a opção de se minimizar o mesmo.
Algo que para mim faz falta.

Acho que ele nunca teve isso. Ou teve?

[Wallace]

Wallace, ocorreu um erro no sistema de envio mensagens, e as ferramentas foram colocadas no site antes de sair a mensagem que informava sobre as mudanças.

A nosso pedido, o Odilon implementou novos formatos na nova Versão do GPSTrackMaker. Para usar o novo formato, você precisa da última Versão do GPSTrackMaker, e do programa Reformatador2, que está disponível no site.

Eu repostei a mensagem de aviso que deveria ter sido enviada aos desenvolvedores aqui no fórum.

Ok, obrigado.
Vou baixar a atualizações do TrackMaker.
Só que ficou um baita trabalho em virtude da quantidade de mapas que desenvolvo e dos computadores que uso rs rs

[Ruy Lerac]

não existe grande trabalho. O reformatador disponibilizado irá reformatar os mapas automaticamente. Testei com mais de 100 mapas que eu tinha aqui comigo, resultado da primeira reformatação feita pela coordenação, colocados num mesmo diretório, e a reformatação de todos eles não levou 1 minuto.

[nqnnospam]

Achei o tópico que fala de erros e avisos do conversor:

http://www.portalgps.com.br/forum/viewt ... sor#p15683

O tópico citado trata de ERROS que estavam sendo tratados incorretamente como AVISOS. Este problema foi corrigido já faz algum tempo.

Os problemas na numeração São AVISOS realmente, e a luz da informações que temos até agora, não impedem a compilação.

Com relação à interpolação. Nos meus testes não usei esta função. Talvez ela esteja "esquecendo" informações. Como eu disse, atualmente o processamento feito pelo Conversor demanda que para cada segmento de via com numeração, toda a informação de numeração esteja no nó de roteamento inicial do segmento. Se isso não corre, ele emite o AVISO de inconsistência.

Preciso fazer testes para ver o que acontece.

[paulocarvalho]

Paulo

Mais uma sugestão para o Editor de nós. Por favor, queira analisar se é útil, interessante, viável ou válida.

Na opção de "Procurar problemas", poderia ser aberto mais um campo de pesquisa: "MANOBRAS INEXISTENTES" ou "MANOBRAS" simplesmente.

não raras vezes abro um mapa no editor e no "susto" ou na "trombada" reparo algum trecho em branco no mapa, ao aproximar com o zoom, observo que tem alguma manobra "INEXISTENTE", e confesso que tenho achado esses erros na sorte. Colocando essa opção, será possível fazer uma triagem total, não só do mapa mas das restrições com problemas tb.

Abusando um pouco da vossa boa vontade e voluntariado, fica uma "sub-sugestão" agora: esse sistema poderia usar o mesmo engine do procura normal, ou seja, uma janela com a lista das manobras inválidas e ao clicar no nome da manobra, teria a aproximação automática para identificação e demonstração de irregularidade. Nessa mesma janela já poderia ser colocado um botão de delete para agilizar a correção, assim não precisa abrir o campo de procura uma vez para cada manobra, deletar manualmente, etc...

O que vc acha?? Válido?

Coloquei na wishlist.

[Wallace]

não existe grande trabalho. O reformatador disponibilizado irá reformatar os mapas automaticamente. Testei com mais de 100 mapas que eu tinha aqui comigo, resultado da primeira reformatação feita pela coordenação, colocados num mesmo diretório, e a reformatação de todos eles não levou 1 minuto.

Para mim com os 60 mapas que desenvolvo tem um bom trabalho braçal sim.
Um trabalho que toma tempo é enviar um mapa por vez.
Outro que gera trabalho é o editor de nós onde tenho que abrir um mapa por vez e fazer os 5 testes.
Para quem tem poucos mapa mesmo que grande não gera um trabalho tão grande quanto quem tem mais mapas.
Outra coisa que gera trabalho e acertar os erros de duplicidade do Editor, mas isso é um trabalho necessário.

[Ruy Lerac]

Vc sabe muito bem que eu estava me referindo ao trabalho de reformatação.

O restante é comum a todos os desenvolvedores, mais acentuado para quem desenvolve muitos municípios.

[Wallace]

Se eu fosse adivinho já teria ganho a sena na mega sena rs rs
É o que eu sempre falo, achar algo é no minimo 50% de chances de errar.

[paulocarvalho]

Outro que gera trabalho é o editor de nós onde tenho que abrir um mapa por vez e fazer os 5 testes.

Só lembrando que o Editor de nós não fora projetado para ser uma ferramenta para corrigir mapas em lote.

[Wallace]

Sim, mas ajuda a achar alguns problemas nos mapas.

Uma sugestão que talvez seja facil de implementar é uma opção de visualizar os nós com cores diferentes por numero de tracks que chegam no nó como no MapEdit.
Veja bem acho que a configuração atual deve ser mantida Também.
Ou pode simplemente colocar um numero nos nós junto com as cores atuais, mas acho que o esquema de cores tipo o MapEdit é mais pratico.
Isso para não precisar usar o MapEdit, pois pode se usar ele para isso.

[paulocarvalho]

Isso é fácil de fazer sim. não tenho o Mapedit, por isso peço por favor que coloque aqui a relação número de tracks-cores, lembrando que azul-escuro está reservado para nós selecionados. A colocação do número seria mais fácil ainda, pois o processo de pintura do mapa que adotei no Editor é parecido com o de uma gráfica: há um processamento separado para cada cor/estilo diferente.

[elderluis]

Salvo engano, no MapEdit é assim:

Azul escuro (aquele já reservado): vértice na ponta de um segmento, não liga a outros;
Branco: liga 2 segmentos
Amarelo: liga 3 segmentos
Verde: liga 4 segmentos
Lilás: liga 5 segmentos

[Wallace]

Para mim pode ser qualquer cor, não precisa ser o esquema do MapEdit, só ter cor diferente já ajuda.
Mas se os numeros São mais facil acho que vale tentar primeiro com eles com opção para ligar e desligar estes numeros.
Quem sabe já fica legal.

[paulocarvalho]

Acho que vou combinar os dois: mostrar o número com cores diferentes. O que acham? Acho que vou deixar a cor do nó para expressar a função dele (nós comuns/nós de roteamento).

[nqnnospam]

Paulo,

não sei se passou batido, mas acho importante você dar uma olhada na função que gera os endereços por interpolação:

http://www.portalgps.com.br/forum/viewt ... 017#p17017

Eu não testei ainda, mas parece que ela não está colocando as informações todas no mesmo nó de roteamento (o inicial, como requer o cgpsmapper).

O Elder não mencionou mais nada, mas caso se confirme o problema, e se for muito complicado de corrigir, eu posso tentar algum mecanismo de correção no Conversor.

[paulocarvalho]

Sérgio, há erro somente se a numeração estiver inconsistente, o que pode ser detectado na ferramenta de busca de problemas e devidamente corrigido pelo usuário. Caso a busca não acuse inconsistência na numeração, o GTI está correto e ela poderá ser convertida e compilada no que depender do Editor. Agora, pelo que sei a numeração está OK agora, o que deve ser testado ainda São as restrições. É isso?

[nqnnospam]

Paulo,

Em todos os testes de numeração que fiz, eu as inseri no mapa usando o modo manual. Nunca usei a interpolação.

Para numeração inserida no modo manual, está funcionando muito bem.

já no caso das restrições, realmente preciso rever o código do Conversor, por causa daqueles casos de "ambiguidade".

[paulocarvalho]

Mais uma sugestão para o Editor de nós. Por favor, queira analisar se é útil, interessante, viável ou válida.

Na opção de "Procurar problemas", poderia ser aberto mais um campo de pesquisa: "MANOBRAS INEXISTENTES" ou "MANOBRAS" simplesmente.

não raras vezes abro um mapa no editor e no "susto" ou na "trombada" reparo algum trecho em branco no mapa, ao aproximar com o zoom, observo que tem alguma manobra "INEXISTENTE", e confesso que tenho achado esses erros na sorte. Colocando essa opção, será possível fazer uma triagem total, não só do mapa mas das restrições com problemas tb.

Abusando um pouco da vossa boa vontade e voluntariado, fica uma "sub-sugestão" agora: esse sistema poderia usar o mesmo engine do procura normal, ou seja, uma janela com a lista das manobras inválidas e ao clicar no nome da manobra, teria a aproximação automática para identificação e demonstração de irregularidade. Nessa mesma janela já poderia ser colocado um botão de delete para agilizar a correção, assim não precisa abrir o campo de procura uma vez para cada manobra, deletar manualmente, etc...

O que vc acha?? Válido?

Élder, na verdade você pode procurar por eles indo na busca por vias (CTRL+F) e digitar "INEXISTENTE" que o sistema vai listar todas as inconsistências para você.

[paulocarvalho]

Paulo,

Em todos os testes de numeração que fiz, eu as inseri no mapa usando o modo manual. Nunca usei a interpolação.

Para numeração inserida no modo manual, está funcionando muito bem.

já no caso das restrições, realmente preciso rever o código do Conversor, por causa daqueles casos de "ambiguidade".

Sérgio, a interpolação apenas calcula os números, não mexe nos valores de LSTART, LEND, RSTART, REND, RTYPE e LTYPE.

[paulocarvalho]

Para mim pode ser qualquer cor, não precisa ser o esquema do MapEdit, só ter cor diferente já ajuda.
Mas se os numeros São mais facil acho que vale tentar primeiro com eles com opção para ligar e desligar estes numeros.
Quem sabe já fica legal.

Olha, não botei muita fé nessa funcionalidade a princípio, mas depois que testei e vi a quantidade de conexões mal feitas no meu mapa vi que é muito útil, quase imprescindível. Foi uma excelente sugestão. Muito obrigado.

[elderluis]

O Elder não mencionou mais nada, mas caso se confirme o problema, e se for muito complicado de corrigir, eu posso tentar algum mecanismo de correção no Conversor.

Desculpem a demora para o retorno, mas estou extremamente atarefado no trabalho e fiquei uns dias fora de combate...

O mapa foi convertido sem problemas, porém, mais de uma centena de avisos nos nós onde foram inderidas numerações por interpolação, os nós que foram editados manualmente não houve qualquer tipo de aviso ou problema.

[elderluis]

Élder, na verdade você pode procurar por eles indo na busca por vias (CTRL+F) e digitar "INEXISTENTE" que o sistema vai listar todas as inconsistências para você.

Legal, não havia atentado para esta possibilidade.

De qualquer forma, a médio prazo, não seria interessante pensar em uma espécie de "validador interno" do Editor de nós? Um simples comando que chacaria inconsistências e avisaria o usuário. Foram tantas as implementações e possibilidades de edição/alteração agredadas a uma única ferramenta que já abre um leque de possbilidade de erro, que teoricamente, podem interferir na compilação final do mapa.

[paulocarvalho]

mais de uma centena de avisos nos nós onde foram inderidas numerações por interpolação, os nós que foram editados manualmente não houve qualquer tipo de aviso ou problema.

Caramba, isso não faz o menor sentido. A interpolação apenas calcula os números automaticamente. não há uma flag especial dizendo "estes números foram calculados por interpolação". Para o Conversor/Compilador é como se fossem inseridos manualmente.

[paulocarvalho]

Elder, tente o seguinte:

1) Pegue uma rua relativamente curta cuja numeração fora calculada por interpolação e deu erros e corrija manualmente a numeração de forma que nenhum número fique igual ao outro na mesma via e se certificando de que os números sempre crescem/decrescem. Converta e reporte aqui.

2)Pegue uma rua curta sem numeração e coloque manualmente uma numeração aleatória em todos os seus nós, sem respeitar ordem. Converta e reporte.

3)Pegue uma rua curta mais uma vez e coloque manualmente em todos os nós uma numeração crescente, mas colocando em um dos nós o mesmo número de cada lado. Converta e reporte.

[elderluis]

Ok Paulo, vou fazer os testes e depois reporto aqui exatamente o que aconteceu.

Realmente é muito estranho, tenho 1 mapa (Bernardo) que coloquei alguns números manualmente e nada aconteceu, zero erros, zero avisos. O mapa de Caetano feito 100% por interpolação deu muitos avisos.

Vou testar, logo posto o que aconteceu.

[elderluis]

Paulo,

Feitos os testes conforme sua orientação. O relatório de avisos teve a mais absoluta constância em todas as situações, não houve qualquer tipo de diferenciação ou comportamento. Segue em anexo um arquivo txt (tosquera) com copy/paste dos resultados dos testes.

O curioso é que com o mapa de São Bernardo não aconteceu o mesmo qdo fiz a conversão, e no mapa de Bernardo coloque alguns números manualmente e de um lado só do nó. A conversão foi tranqüila.

A constância dos avisos é sempre:

"Inconsistência nas informações de endereço LEFT, nó 0 da via R ENG ARMANDO DE ARRUDA PEREIRA"

Anote meu msn, se quiser falar online diretamente, acho que é mais fácil/rápido:

elder_b@hotmail.com

[paulocarvalho]

Élder, se mesmo colocando os números manualmente o erro persiste então essa bola é do Sérgio, já que não há influência da lógica seqüencial dos números no resultado da conversão.

Sérgio, vai que é sua...

[paulocarvalho]

Élder, antes de incomodar o Sérgio, tente ver se o problema tem a ver com os tipos de numeração (as marcações coloridas nos retângulos dos números). Tente fazer com que fique o mesmo do mapa de Bernardo, converta e reporte aqui.

[elderluis]

Xiiii

Teste feito e nada feito. Aliás, fiz diversos outros testes como atribuir a opção de lado direito par/impar, etc, e os avisos só se multiplicaram... os testes não foram frutíferos...

[nqnnospam]

Eu confesso que não entendi muito bem os testes.

Afinal

a) Ocorre erro na numeração interpolada em todos os mapas ou não?

b) Ocorre erro na numeração manual em todos os mapas ou não?

[paulocarvalho]

Sérgio, segundo o que relatou o Élder, os erros acontecem independentemente dos números. Ainda, guardam uma certa relação com a definição do tipo de numeração. Logo, pode ignorar o fato de como os números foram gerados (metrificação, interpolação ou manual), isso não teve relevância no resultado da conversão.

Especulo que seja alguma situação imprevista no algoritmo do Conversor peculiar ao mapa em questão. Talvez seja interessante o Élder te mandar o GTM e o GTI causadores do problema para seu e-mail para você dar uma olhada com calma, passar o debug, etc.

[nqnnospam]

Paulo,

Tenho os arquivos aqui comigo. Vou fazer uns testes.

[nqnnospam]

Elder, você poder enviar para o site o arquivo .gtm e o .gti de São Bernardo do Campo, para que eu possa testar?

O .gti que eu tenho aqui está sem numeração, só tem restrições.

Obrigado.

[paulocarvalho]

Sérgio, o de São Bernardo está OK, segundo o Élder, é um outro mapa que está com problemas. não é isso, Élder?

[elderluis]

Elder, você poder enviar para o site o arquivo .gtm e o .gti de São Bernardo do Campo, para que eu possa testar?

Enviado. Só para deixar claro, deixei apenas numeração em um nó a qual inseri manualmente. O conversor não acusa erro qdo submeto o arquivo à conversão com essa única numeração. Caso eu coloque outras numerações por interpolação, começam os inúmeros avisos.

[elderluis]

Sérgio, o de São Bernardo está OK, segundo o Élder, é um outro mapa que está com problemas. não é isso, Élder?

Isso, é o mapa de Caetano que dá inúmeros avisos, 100% da numeração foi feita usando a interpolação. Obviamente o primeiro e o último número foram inseridos manualmente, requisito básico para utilização da interpolação.

[elderluis]

Em tempo:

Sérgio,
mandei o mapa de Bernardo e Caetano com os respectivos .gti para sua análise.

Casaretto,
não precisa fazer a compilação desses dois últimos mapas que enviei (05abr por volta das 21:40), tendo em vista que reenviei para que o Sérgio faça os testes, tais mapas não tem nenhuma atualização em relação a última compilação dos mesmos e foram enviados apenas para fins de testes, conforme solicitação do Sérgio.

[paulocarvalho]

Elder, você poder enviar para o site o arquivo .gtm e o .gti de São Bernardo do Campo, para que eu possa testar?

Enviado. Só para deixar claro, deixei apenas numeração em um nó a qual inseri manualmente. O conversor não acusa erro qdo submeto o arquivo à conversão com essa única numeração. Caso eu coloque outras numerações por interpolação, começam os inúmeros avisos.

Ué, devia justamente ter dado erro com numeração em apenas um nó, já que qualquer via tem necessariamente pelo menos dois nós de roteamento. você usou a ferramenta de busca de numeração inconsistente do Editor? você não pode converter GTIs contendo inconsistências na numeração.

[elderluis]

não usei essa ferramenta de inconsistência de numeração, aliás, qdo entro na opção em "Localizar problemas..." e depois "numeração", aparece uma lista de vias, mas nenhuma orientação ou esclarecimento mais detalhado é prestado, somente aparece a lista de vias.

Conforme eu expliquei anteriormente, aparecem AVISOS no conversor, o que não impede, necessariamente, de se converter e compilar o mapa. Acredito que o ideal a ser alcançado é uma conversão sem qualquer tipo de erro ou aviso.

[paulocarvalho]

Élder, esses erros têm de ser eliminados. Em relação aos esclarecimentos há exemplos de fontes de inconsistências no manual do Editor. Depois de acusados os erros, clique nos nomes que o mapa será centralizado na via em questão, mande habilitar a exibição dos nós e dos números e veja as inconsistências. Para poupar-te do trabalho de ler o manual vou te passar o que é considerado uma numeração correta:

1) Todos os nós de rotemento de uma via têm que ter numeração diferente de zero dos dois lados (com exceção dos nós nas extremidades é claro).

2) O tipo de numeração deve ser constante ao longo da via.

A não observância dessas regras acarreta em inconsistência e a conseqüente falha ou na conversão ou na compilação.

Isto posto, elimine as inconsistências acusadas pelo Editor e tente novamente. Se, e somente se, mesmo depois de eliminadas as inconsistências acusáveis pelo Editor o problema persistir, a gente volta a incomodar o Sérgio.

[nqnnospam]

Estive olhando o mapa de São Caetano do Sul e analisando as mensagens do Conversor.

1) Exemplo do problema:

*** ArquivoMP.WriteRGN40: Inconsistência nas informações de endereço LEFT, nó 3 da via AV GOIAS.
*** AVISO 0 no ponto: ( -23.61519500, -46.57385700).
*** ArquivoMP.WriteRGN40: Inconsistência nas informações de endereço LEFT, nó 3 da via AV GOIAS.
*** AVISO 1 no ponto: ( -23.61519500, -46.57385700).

A segunda mensagem do Conversor está incorreta, deveria dizer RIGHT em lugar de LEFT, mas o problema existe, porque todas as numerações (LSTART, LEND, RSTART e REND) do segmento que se inicia nesse nó de roteamento estão em branco:

Código: Selecionar todos

<NO LAT="-23.615195" LON="-46.573857">
	<SEGMENTO SENTIDO_CRIACAO="SAINDO" LAT="-23.615147" LON="-46.575397">
		<NUMERO_INTERNO VALOR="500"/>
		<LTYPE VALOR="0"/>
		<RTYPE VALOR="0"/>
		<LSTART VALOR=""/>
		<LEND VALOR=""/>
		<RSTART VALOR=""/>
		<REND VALOR=""/>
	</SEGMENTO>
	<SEGMENTO SENTIDO_CRIACAO="CHEGANDO" LAT="-23.616071" LON="-46.574112">
		<NUMERO_INTERNO VALOR="258"/>
		<LTYPE VALOR="0"/>
		<RTYPE VALOR="0"/>
		<LSTART VALOR=""/>
		<LEND VALOR=""/>
		<RSTART VALOR=""/>
		<REND VALOR=""/>
	</SEGMENTO>
	<SEGMENTO SENTIDO_CRIACAO="CHEGANDO" LAT="-23.615198" LON="-46.573776">
		<NUMERO_INTERNO VALOR="501"/>
		<LTYPE VALOR="0"/>
		<RTYPE VALOR="0"/>
		<LSTART VALOR=""/>
		<LEND VALOR=""/>
		<RSTART VALOR=""/>
		<REND VALOR=""/>
	</SEGMENTO>
	<SEGMENTO SENTIDO_CRIACAO="SAINDO" LAT="-23.614384" LON="-46.573691">
		<NUMERO_INTERNO VALOR="258"/>
		<LTYPE VALOR="0"/>
		<RTYPE VALOR="0"/>
		<LSTART VALOR=""/>
		<LEND VALOR=""/>
		<RSTART VALOR=""/>
		<REND VALOR=""/>
	</SEGMENTO>
</NO>

e isto naturalmente não procede, já que o nó de roteamento em questão (NO LAT="-23.615195" LON="-46.573857") deveria conter a numeração inicial e final do segmento que nele começa. Se esse nó de roteamento não inicia um segmento com numeração, então não deveria aparecer no arquivo.

não analisei todas as mensagens (São muitas, mais de 100), mas todas que analisei apresentam o mesmo problema, todas as informações (LSTART, LEND, RSTART e REND) estão em branco.

2) (Meu) Diagnóstico:

Abrindo o mapa no Editor de nós, a ferramenta de encontrar problemas na numeração aponta erro na rua Goiás, mas não diz qual é o erro. Analisando visualmente, notei que em parte da via a numeração estava como par e ímpar dos dois lados, e em outra parte como desativada dos dois lados, apesar de aparecer o "Número interno". Isto, obviamente, é inconsistente. Imagino que, se essa numeração foi gerada por interpolação, o mecanismo deveria cuidar para evitar essa situação (?).

Corrigi o problema (selecionei a via e coloquei par e ímpar nos dois lados, o que de certa forma Também é inconsistente, acho), e a informação no .gti apareceu (para os segmentos da rua Goiás):

Código: Selecionar todos

<NO LAT="-23.615195" LON="-46.573857">
	<SEGMENTO SENTIDO_CRIACAO="SAINDO" LAT="-23.615147" LON="-46.575397">
		<NUMERO_INTERNO VALOR="500"/>
		<LTYPE VALOR="3"/>
		<RTYPE VALOR="3"/>
		<LSTART VALOR="500"/>
		<LEND VALOR=""/>
		<RSTART VALOR="500"/>
		<REND VALOR=""/>
	</SEGMENTO>
	<SEGMENTO SENTIDO_CRIACAO="CHEGANDO" LAT="-23.616071" LON="-46.574112">
		<NUMERO_INTERNO VALOR="258"/>
		<LTYPE VALOR="0"/>
		<RTYPE VALOR="0"/>
		<LSTART VALOR=""/>
		<LEND VALOR=""/>
		<RSTART VALOR=""/>
		<REND VALOR=""/>
	</SEGMENTO>
	<SEGMENTO SENTIDO_CRIACAO="CHEGANDO" LAT="-23.615198" LON="-46.573776">
		<NUMERO_INTERNO VALOR="501"/>
		<LTYPE VALOR="3"/>
		<RTYPE VALOR="3"/>
		<LSTART VALOR=""/>
		<LEND VALOR="501"/>
		<RSTART VALOR=""/>
		<REND VALOR="501"/>
	</SEGMENTO>
	<SEGMENTO SENTIDO_CRIACAO="SAINDO" LAT="-23.614384" LON="-46.573691">
		<NUMERO_INTERNO VALOR="258"/>
		<LTYPE VALOR="0"/>
		<RTYPE VALOR="0"/>
		<LSTART VALOR=""/>
		<LEND VALOR=""/>
		<RSTART VALOR=""/>
		<REND VALOR=""/>
	</SEGMENTO>
</NO>

Mas, ainda sim, a informação continua inconsistente, porque o Conversor interpreta isso como se a numeração do segmento que começa no nó <NO LAT="-23.615195" LON="-46.573857"> fosse de 500 a 501, o que não é verdade, pois visualmente observa-se que vai de 397 a 500, logo RSTART e LSTART deveriam ser 397 (500?) e REND e LEND deveriam ser 500 (397?). A numeração corre no sentido contrário ao de criação da via.

Vejam a figura anexada. O nó <NO LAT="-23.615195" LON="-46.573857"> é o primeiro da direita para a esquerda, entre o 500 e o 501. A R. Goiás está selecionada.

[casaretto]

Pessoal

Tenho recebido muitos mapas com restrições que não São aceitas pelo compilador e porisso impedem que sejam utilizadas.

É preciso que todos tenham bem claro o entendimento de como alimentar as restrições.

Para alimentar uma restrições precisamos indicar 3 ou 4 nós a depender da situação.

Na figura anexada, coloquei duas situações.

Na primeira, uma restrição que impede o retorno, São necessários obrigatoriamente indicar 4 nós. São eles:

1 - nó imediatamente anterior à conversão
2 - primeiro nó da conversão. Este nó sempre é o cruzamento das vias a ser restrito.
3 - segundo nó de conversão.
4 - nó da via final. É o primeiro nó da via Após a conversão a ser restringida.

A segunda, representa uma conversão à esquerda, mais simples, chamada de Restrição em L


1 - nó imediatamente anterior à conversão
2 - primeiro nó da conversão. Este nó sempre é o cruzamento das vias a ser restrito.
3 - É o primeiro nó da via Após a conversão a ser restringida.

não existem outras opções com 2 nós ou com 5 nós. Sempre tem de ser assim. Nenhum nó intermediario pode ser esquecido ou "pulado".

Paulo

[elderluis]

Casaretto

Acho interessante mandar essa explicação naquele mailing list dos desenvolvedores. Certamente nem todos lerão esta mensagem postada aqui, sendo que é de extrema importância.

[paulocarvalho]

e isto naturalmente não procede, já que o nó de roteamento em questão (NO LAT="-23.615195" LON="-46.573857") deveria conter a numeração inicial e final do segmento que nele começa. Se esse nó de roteamento não inicia um segmento com numeração, então não deveria aparecer no arquivo.

Sérgio, o usuário não especificou o tipo de numeração, assim só o número-base é salvo no GTI, já que o Editor não sabe como preencher os valores *START e *END.

não analisei todas as mensagens (São muitas, mais de 100), mas todas que analisei apresentam o mesmo problema, todas as informações (LSTART, LEND, RSTART e REND) estão em branco.

Veja os valores de *TYPE, todas estão com zero, ou seja, o tipo não foi especificado e o Editor não tem como determinar o que colocar nesses campos.

Abrindo o mapa no Editor de nós, a ferramenta de encontrar problemas na numeração aponta erro na rua Goiás, mas não diz qual é o erro.

Faço uma pelo à boa vontade de vocês, pois a natureza do erro é facilmente observável no mapa.

Analisando visualmente, notei que em parte da via a numeração estava como par e ímpar dos dois lados, e em outra parte como desativada dos dois lados, apesar de aparecer o "Número interno". Isto, obviamente, é inconsistente. Imagino que, se essa numeração foi gerada por interpolação, o mecanismo deveria cuidar para evitar essa situação (?).

O sistema de cálculo somente lida com os números. A tipificação do enderaçamento é um julgamento exclusivamente humano, de observar a fonte e fazer a marcação de acordo. O Editor não tem como julgar se um tipo de numeração está correto ou não a não ser apontar a inconsistência conforme já faz na ferramente de localização de problemas.

Corrigi o problema (selecionei a via e coloquei par e ímpar nos dois lados, o que de certa forma Também é inconsistente, acho)

não sabemos se existem cidades no Brasil que colocam par e ímpar nos dois lados das vias.

Mas, ainda sim, a informação continua inconsistente, porque o Conversor interpreta isso como se a numeração do segmento que começa no nó <NO LAT="-23.615195" LON="-46.573857"> fosse de 500 a 501, o que não é verdade, pois visualmente observa-se que vai de 397 a 500, logo RSTART e LSTART deveriam ser 397 (500?) e REND e LEND deveriam ser 500 (397?). A numeração corre no sentido contrário ao de criação da via.

Vejam a figura anexada. O nó <NO LAT="-23.615195" LON="-46.573857"> é o primeiro da direita para a esquerda, entre o 500 e o 501. A R. Goiás está selecionada.

Se você observar a figura, ainda existe numeração sem tipo definido, logo o mapa não vai converter direito.

[nqnnospam]

Sérgio, o usuário não especificou o tipo de numeração, assim só o número-base é salvo no GTI, já que o Editor não sabe como preencher os valores *START e *END.

Sim, entendi isso. Agora, se o tipo de numeração é definido para a via inteira (eu pelo menos só consigo fazer assim ), como o usuário conseguiu definir o tipo de numeração parcialmente?

Veja os valores de *TYPE, todas estão com zero, ou seja, o tipo não foi especificado e o Editor não tem como determinar o que colocar nesses campos.

Sim, correto, entendo isso. não seria possível a numeração ficar vermelha, indicando a existência de inconsistência?

Vou mudar a mensagem do Conversor, para dar algum tipo de indicação do problema ao usuário.

Faço uma pelo à boa vontade de vocês, pois a natureza do erro é facilmente observável no mapa.

Concordo, foi só bater os olhos que notei o problema...

O sistema de cálculo somente lida com os números. A tipificação do enderaçamento é um julgamento exclusivamente humano, de observar a fonte e fazer a marcação de acordo. O Editor não tem como julgar se um tipo de numeração está correto ou não a não ser apontar a inconsistência conforme já faz na ferramente de localização de problemas.

Concordo, mas, para evitar problemas, o Editor poderia ter um tipo default de numeração. Pares e ímpares do lado esquerdo, ou par do lado esquerdo e ímpar no direito, enfim, o que fosse mais simples. Isso eliminaria este tipo de problema.

não sabemos se existem cidades no Brasil que colocam par e ímpar nos dois lados das vias.

Realmente não sei se pares e ímpares de ambos os lados é realmente uma inconsistência.

Se você observar a figura, ainda existe numeração sem tipo definido, logo o mapa não vai converter direito.

Onde? Nas vias transversais? Desculpe, mas como isso influencia a numeração da Rua Goiás?

[nqnnospam]

Sim, entendi isso. Agora, se o tipo de numeração é definido para a via inteira (eu pelo menos só consigo fazer assim ), como o usuário conseguiu definir o tipo de numeração parcialmente?

Onde? Nas vias transversais? Desculpe, mas como isso influencia a numeração da Rua Goiás?

Acho que já percebi o erro. A via é formada de vários tracks, e o usuário não especificou a numeração em todos...

[nqnnospam]

não ...

Coloquei numeração na via inteira, indicando o tipo de numeração na via inteira, mas ainda assim continuou:

Código: Selecionar todos

<NO LAT="-23.615195" LON="-46.573857">
	<SEGMENTO SENTIDO_CRIACAO="SAINDO" LAT="-23.615147" LON="-46.575397">
		<NUMERO_INTERNO VALOR="500"/>
		<LTYPE VALOR="3"/>
		<RTYPE VALOR="3"/>
		<LSTART VALOR="500"/>
		<LEND VALOR=""/>
		<RSTART VALOR="500"/>
		<REND VALOR=""/>
	</SEGMENTO>
	<SEGMENTO SENTIDO_CRIACAO="CHEGANDO" LAT="-23.616071" LON="-46.574112">
		<NUMERO_INTERNO VALOR="258"/>
		<LTYPE VALOR="0"/>
		<RTYPE VALOR="0"/>
		<LSTART VALOR=""/>
		<LEND VALOR=""/>
		<RSTART VALOR=""/>
		<REND VALOR=""/>
	</SEGMENTO>
	<SEGMENTO SENTIDO_CRIACAO="CHEGANDO" LAT="-23.615198" LON="-46.573776">
		<NUMERO_INTERNO VALOR="501"/>
		<LTYPE VALOR="3"/>
		<RTYPE VALOR="3"/>
		<LSTART VALOR=""/>
		<LEND VALOR="501"/>
		<RSTART VALOR=""/>
		<REND VALOR="501"/>
	</SEGMENTO>
	<SEGMENTO SENTIDO_CRIACAO="SAINDO" LAT="-23.614384" LON="-46.573691">
		<NUMERO_INTERNO VALOR="258"/>
		<LTYPE VALOR="0"/>
		<RTYPE VALOR="0"/>
		<LSTART VALOR=""/>
		<LEND VALOR=""/>
		<RSTART VALOR=""/>
		<REND VALOR=""/>
	</SEGMENTO>
</NO>

Vou fazer um teste num arquivo separado.

[elderluis]

Nossa, não achei que viraria essa discussão tão técnica e detalhada. Se me permitem um comentário, farei-o. Notei que parte da discussão se concentra no detalhe de atribuir numeração par/ímpar a determinado lado da rua. Acho que isso é absolutamente desnecessário e só abre ainda mais o leque de possibilidade de erros.

Partindo para o lado prático da coisa, ao indicar um endereço completo e o GPS me guiar até lá, qual diferença faz - desde que eu chege ao destino - se é lado esquerdo ou direto?

Essa questão faz me recordar dos radares em cruzamentos. não é possível (em tese) especificar ou determinar em qual rua ele pertence e, ao se aproximar dele, seja qual via vc estiver, o GPS vai "avisar" caso vc tenha configurado para isso. Aplico a mesma teoria à numeração da via. Em termos práticos não faz a mínima diferença determinar se o lado esquerdo é par ou ímpar.

[nqnnospam]

A especificação do tipo da numeração, par ou ímpar, de cada lado da via, é uma exigência do formato Garmin.

[paulocarvalho]

como o usuário conseguiu definir o tipo de numeração parcialmente?

É possível adicionar slots de numeração em tempos diferentes, mas isso não é muito óbvio de fazer. você manda adicionar numeração à via, depois você edita o slot que você quer apagar entrando texto em branco. Depois você define o tipo de numeração para os slots remanescentes. Depois você manda adicionar numeração novamente à via que novos slots com tipo default (par e ímpar/preto) onde eles foram apagados São criados. Voilà: inconsistência. Outra forma é estender a via no Trackmaker e mandar adicionar numeração depois para os novos nós.

Sim, correto, entendo isso. não seria possível a numeração ficar vermelha, indicando a existência de inconsistência?

já existe indicação visual da inexistência de tipo. É quando o slot da numeração não tem os dois traços grossos pintados nas laterais, sendo apenas um retângulo desenhado com linha fina e cinza.

Concordo, mas, para evitar problemas, o Editor poderia ter um tipo default de numeração. Pares e ímpares do lado esquerdo, ou par do lado esquerdo e ímpar no direito, enfim, o que fosse mais simples. Isso eliminaria este tipo de problema.

O default para a via é par e ímpar dos dois lados, logo não deveria dar problema. já o default para adicionar a um nó é branco, aí sim pode dar problema. É como pisar no acelerador e no freio ao mesmo tempo, não é porque o carro não impede que você vai fazer, não é? Acho que vocês não lêem o manual. Esses detalhes estão todos lá.

Onde? Nas vias transversais? Desculpe, mas como isso influencia a numeração da Rua Goiás?

O mapa é convertido como um todo. Repare na última transversal que há dois slots de numeração com tipo indefinido.

[paulocarvalho]

Código: Selecionar todos

....

	<SEGMENTO SENTIDO_CRIACAO="CHEGANDO" LAT="-23.616071" LON="-46.574112">
		<NUMERO_INTERNO VALOR="258"/>
		<LTYPE VALOR="0"/>
		<RTYPE VALOR="0"/>
		<LSTART VALOR=""/>
		<LEND VALOR=""/>
		<RSTART VALOR=""/>
		<REND VALOR=""/>
	</SEGMENTO>
...
	<SEGMENTO SENTIDO_CRIACAO="SAINDO" LAT="-23.614384" LON="-46.573691">
		<NUMERO_INTERNO VALOR="258"/>
		<LTYPE VALOR="0"/>
		<RTYPE VALOR="0"/>
		<LSTART VALOR=""/>
		<LEND VALOR=""/>
		<RSTART VALOR=""/>
		<REND VALOR=""/>
	</SEGMENTO>
...

Tem que consertar esses dois aí. Lembre-se de salvar (CTRL+S) o índice depois de fazer a alteração e antes de abrir o GTI no bloco de notas. Essa parte é das mais maduras no Editor e com certeza ele salva certo.

[paulocarvalho]

Em termos práticos não faz a mínima diferença determinar se o lado esquerdo é par ou ímpar.

não é bem assim, veja o exemplo tirado do manual, onde o tipo de numeração fará diferença no roteamento. Aliás penso seriamente em deixar de manter o manual, pois a julgar pelo tipo de dúvida que as pessoas têm postado aqui elas não têm lido, logo o trabalho extra não compensa.

[paulocarvalho]

Sérgio, se quiser eu posso colocar nos atributos *START e *END o mesmo valor do número-base quando o *TYPE for zero. O que acha? Mas lebre-se de que zero deveria ser visto como sem numeração e o Conversor deveria ignorar os atributos *START e *END.

[elderluis]

Paulo, neste caso é óbvio que faz diferença, mas qtos % das vias São assim, com uma via para cada sentido?

não acho razoável dimensionar ou direcionar algo, seja ele qual for, pela exceção e não pela regra.

[paulocarvalho]

Élder, a análise não é linear. Podem ser estatisticamente irrelevantes, mas São elas que receberão grande parte das rotas de média/longa distância. As grandes artérias viárias das grandes capitais têm vias com múltiplas pistas onde um lado é par e outro é impar e as pistas do meio não têm endereço. O simples fato de você digitar um número par ou ímpar no endereço pode significar uma variação na rota de alguns quilômetros.

[nqnnospam]

Sérgio, se quiser eu posso colocar nos atributos *START e *END o mesmo valor do número-base quando o *TYPE for zero. O que acha?

não precisa, vou mudar o Conversor para ignorar sem aviso quando os TYPES forem ambos zero.

[paulocarvalho]

Pelo menos, Élder, eu como usuário ficaria irritado se eu digitasse um endereço com o número certo e a rota me colocasse do lado errado de uma avenida importante, para depois fazer uma outra rota para passar para o outro lado, o que pode significar inclusive o pagamento de pedágio sem necessidade (sim, no Rio por exemplo a Av Governador Carlos Lacerda (Linha Amarela) tem um pedágio nos dois sentidos dentro da cidade).

[nqnnospam]

O default para a via é par e ímpar dos dois lados, logo não deveria dar problema. já o default para adicionar a um nó é branco, aí sim pode dar problema. É como pisar no acelerador e no freio ao mesmo tempo, não é porque o carro não impede que você vai fazer, não é? Acho que vocês não lêem o manual. Esses detalhes estão todos lá.

Na realidade, eu estou tentando entender o que o Elder fez para gerar o problema (isso não tem no manual , desculpe a brincadeira...). A indicação dos tipos de numeração (os traços pretos), eu já havia entendido, mesmo sem ler o manual.

Nos testes que eu fiz, a numeração sempre foi gerada de forma consistente (nenhum aviso no Conversor), talvez porque eu entenda melhor como funciona a numeração no padrão Garmin. Mas não usei a interpolação. Como eu disse, preciso fazer um teste usando a interpolação para ver o que acontece.

[paulocarvalho]

não precisa, vou mudar o Conversor para ignorar sem aviso quando os TYPES foram ambos zero.

Exato, pois conforme visto acima existem casos em que você poderá desligar a numeração em apenas um dos lados da via, mas nunca dos dois lados.

[nqnnospam]

Pelo menos, Élder, eu como usuário ficaria irritado se eu digitasse um endereço com o número certo e a rota me colocasse do lado errado de uma avenida importante, para depois fazer uma outra rota para passar para o outro lado, o que pode significar inclusive o pagamento de pedágio sem necessidade (sim, no Rio por exemplo a Av Governador Carlos Lacerda (Linha Amarela) tem um pedágio nos dois sentidos dentro da cidade).

Sim, informar corretamente o tipo de numeração é fundamental para o bom funcionamento do roteamento.

[paulocarvalho]

(isso não tem no manual , desculpe a brincadeira...).

Tem sim, na página 18, fala sobre inconsistência.

[elderluis]

[Hélcio Assis]

- Boa tarde a todos, Paulo só uma dúvida, toda mudança que acontece no Editor de nós é retratada no manual?

[paulocarvalho]

Sim, Hélcio, se é relevante para o usuário é sim. É claro que se for uma alteração para corrigir um bug ou erro de ortografia em algum texto ou qualquer outra coisa que não interfira no modus operandi não vai para o manual. Por falar nisso estou devendo a cardinalidade para ser colocada no manual.

[Hélcio Assis]

- Boa tarde e obrigado Paulo!
parabéns pelo Editor de nós e um abração.

[Simmonds]

Qual a função da Cardinalidade dos nós (opção do Editor de nós para visualizar) uma vez que no Manual do Editor não tem referencia.

[paulocarvalho]

Qual a função da Cardinalidade dos nós (opção do Editor de nós para visualizar) uma vez que no Manual do Editor não tem referencia.

É... dessa vez falhei mesmo , mas já mandei hoje para o repositório a nova Versão do manual.

A idéia é evidenciar conexões falsas entre as vias. Vide os exemplos abaixo. No primeiro caso as duas ruas não estão conectadas, apesar da aparência. Isso é apontado pela cardinalidade 1 indicando que o nó só pertence a uma via. já no segundo caso a cardinalidade 2 indica que o nó pertence às duas vias.

[elderluis]

Essa função de cardinalidade é muito melhor do que a função de nós coloridos em funções do número de vias que está conectado. É mais rápido e direto, sem chances de confundir o cérebro com tanta cor...

[elderluis]

Paulo, a mim me parece que no exemplo que vc citou lá em cima (extraído do manual), sobre numeração par/ímpar atribuída ao lado da via, acho que o exemplo é um caso muito específico onde notoriamente somente um dos lados da via possui imóveis ou locais que tenham numeração. Neste caso, é obviamente necessário definir se é par ou se é ímpar, e claro, determinar que existe numeração apenas em um dos lados.

Qto à numeração em vias simples de mão dupla, como uma rua normal em um bairro residencial, CREIO que não seja tão problemática qto uma avenida de 2 pistas. Veja bem, eu entendo dessa forma e não necessariamente defendo que esteja certa, mesmo porque, não sou engenheiro, programador ou técnico na área. Aliás, minha formação não é em exatas, é na área jurídica entre outras...

[Wallace]

A idéia é evidenciar conexões falsas entre as vias. Vide os exemplos abaixo. No primeiro caso as duas ruas não estão conectadas, apesar da aparência. Isso é apontado pela cardinalidade 1 indicando que o nó só pertence a uma via. já no segundo caso a cardinalidade 2 indica que o nó pertence às duas vias.

Oi Paulo, tenho achando que a forma que voce fez ficou pior que a do MapEdit.
Voce fez por vias e o MapEdit faz por segmentos o que para mim é mais claro.
Imagina no seu exemplo se temos 3 vias diferentes.
No seu primeiro exemplo ficaria com o numero 2 e no segundo com 3, ai precisamos conferir se onde tem o numero 2 temos duas ou 3 vias no nó.
No caso do Mapedit teriamos o numero 2 e 3, sendo que fica claro que de 3 segmentos só temos dois conectados no nó.
não quer rever a forma que fez?

[nqnnospam]

Elder,

O fato é que algum tipo de numeração tem que ser definida, senão permanece a inconsistência, e o Editor de nós não vai gerar a informação que o Conversor precisa.

Se você não sabe o tipo de numeração, coloque qualquer um que inclua os pares e ímpares, isto é, use um desses:

par e ímpar do lado esquerdo
par e ímpar do lado direito
par do lado direito (esquerdo) e ímpar do lado esquerdo (direito)

Ainda não fiz o testes com a interpolação, mas todos os testes que eu fiz com numeração manual passaram pelo Conversor sem avisos. Agora estou fazendo testes mais detalhados, verificando a consistência no Mapsource e no GPS.

Ajustando a numeração de São Caetano do Sul para que não haja avisos no Conversor, você poderá testar, no TRU-SP, a consistência do que está sendo gerado, pois a Versão do Conversor que processa a numeração já está sendo usada na compilação.

[paulocarvalho]

Oi Paulo, tenho achando que a forma que voce fez ficou pior que a do MapEdit.
Voce fez por vias e o MapEdit faz por segmentos o que para mim é mais claro.

Vamos lá, Wallace, recordar é viver. Lá ná página 5 você disse:

Sim, mas ajuda a achar alguns problemas nos mapas.

Uma sugestão que talvez seja facil de implementar é uma opção de visualizar os nós com cores diferentes por numero de tracks que chegam no nó como no MapEdit.
Veja bem acho que a configuração atual deve ser mantida Também.
Ou pode simplemente colocar um numero nos nós junto com as cores atuais, mas acho que o esquema de cores tipo o MapEdit é mais pratico.
Isso para não precisar usar o MapEdit, pois pode se usar ele para isso.

(ênfase adicionada)
Fiz exatamente conforme você sugeriu.

não quer rever a forma que fez?

Sim, quando tiver tempo.

[paulocarvalho]

Paulo, a mim me parece que no exemplo que vc citou lá em cima (extraído do manual), sobre numeração par/ímpar atribuída ao lado da via, acho que o exemplo é um caso muito específico onde notoriamente somente um dos lados da via possui imóveis ou locais que tenham numeração. Neste caso, é obviamente necessário definir se é par ou se é ímpar, e claro, determinar que existe numeração apenas em um dos lados.

É específico, mas não pode ser ignorado sob pena de fazer roteamentos incorretos para quem faz busca por endereços.

Qto à numeração em vias simples de mão dupla, como uma rua normal em um bairro residencial, CREIO que não seja tão problemática qto uma avenida de 2 pistas. Veja bem, eu entendo dessa forma e não necessariamente defendo que esteja certa, mesmo porque, não sou engenheiro, programador ou técnico na área. Aliás, minha formação não é em exatas, é na área jurídica entre outras...

Sim, para essas ruas simples ou até vias importantes de pista simples use o tipo default. Aliás o tipo default é justamente aquele que poderá ser usado em cerca de 80% das vias (par/ímpar dos dois lados ou preto-preto na representação gráfica).

[paulocarvalho]

Excelente, Sérgio, acho que vou mandar um TRU com uma numeração de teste para ver como fica.

[paulocarvalho]

A Versão 3.0.2 faz a cardinalidade tal como faz o Mapedit.

não precisam agradecer...

[Wallace]

Bem na realidade eu não consegui explicar o que o mapedit fazia rs rs
Mas era só ver lá rs rs
Bem de toda forma obrigado e vamos ver se ficou melhor assim para todos.

[elderluis]

Muito bom hein.... cada vez melhor.

[paulocarvalho]

[Simmonds]

Vamos ver se a pagina vira para 8 ....

Vou aproveitar e dar o meu PITACO tambem.......

Realmente a necessidade da Numeração nas Ruas é importantissimo, mesmo porque sem a Numeração, o GPS vai sempre lhe conduzir para o inicio da Rua, seja onde for este inicio, mesmo que ela não tenha restrição de Mão de Direção, pois vai considerar o sentido em que a Trilha foi Criada

Assim, muitas vezes, mas muitas mesmo, o usuário poderá estar a 100 metros do local desejado e ao fazer o Roteamento, vai lhe levar para o inicio da Rua, 3, 4, 5 ou mais Kms de distancia.

Com a Numeração, o Roteamento vai procurar o acesso mais proximo do Numero escolhido.

Isso só não ira ocorrer quando a Rua for realmente de MU e do inicio dela até o final, não existir ruas transversais , ai voce terá que ir ao inicio mesmo.

não sei se através de programação seria permitido colocar Numeração ao longo de uma Rua , seja a direita ou a esquerda, mas em posições diferentes, uma mais perto ou mais longe da outra.

Da Seguinte forma:

Numa Rua de mão unica (exemplo), existem casas e/ou predios dos dois lados, porem, de uma lado os terrenos São de tamanhos diferentes das do outro lado da Rua.


Veja imagem

[elderluis]

Acho complicado colocar uma numeração tão exata e precisa assim tendo em vista a variação constante e quase aleatória nas numerações. Talvez, não sei muito bem, o mais interessante é colocar uma numeração aproximada nas esquinas de tal modo que se diminua ou minimize as chances de erros, uma vez que o usuário será guiado pela aproximação e não pela numeração tão específica assim.

[paulocarvalho]

Simmonds, sua dúvida é pertinente, mas normalmente a numeração "pula" mais números conforme a largura dos terrenos, de forme que seu exemplo na verdade ficaria conforme o anexo.

[paulocarvalho]

É claro que até podem existir ruas do jeito que você falou, mas acho que não compensa complicar a interface para esses casos específicos. Além disso, não é possível especificar a numeração no meio dos segmentos das vias segundo o formato da Garmin, que só admite numeração nos nós de roteamento.

[elderluis]

Paulo, além disso, acho que a numeração aproximada já é de grande valia (inicialmente) nos mapas. Tb acho muito complicado e demorado fazer o mapa, colocar e acompanhar a numeração das vias, principalmente pelo fato do mapa ter um único desenvolvedor responsável por 100% da feitura de tudo que se diz respeito do mapa. Em uma situação mais utópica e teórica, se existissem dois desenvolvedores paralelos, um para trato na construção do GTM em si e outro especificamente para restrições e numerações, talvez ficaria mais preciso, MAS isso está absolutamente descartado. Se sozinho já é complicado fazer td, imamgina em 2...

[paulocarvalho]

Élder, devo colocar no Editor uma busca por endereços, e vocês vão ver que a busca vai apontar para um local muito próximo do real na grande maioria dos casos. Nenhum sistema de busca de endereços que eu conheço dá o local exato onde fica a porta do imóvel, a não ser onde estão os nós. A idéia desse sistema é justamente deixar o usuário num local bem próximo do seu destino, mas os últimos metros a busca sempre dependerá do fator humano.

Tome o exemplo do ILS, o sistema que pousa o avião automaticamente. Na verdade é o piloto que faz a aproximação nos últimos metros antes de tocar a pista. O sistema deixa o avião pronto para pousar, mas é o ser humano que deverá terminar o procedimento no momento em que se precisa do máximo de percepção, e isso nenhuma máquina irá fazer com a mesma eficiência.

[Ruy Lerac]

Exatamente!!!

Somente agora estamos COMEÇANDO a entender os aspectos relacionados com a numeração e as restrições. O bem senso determina que, nestas horas, a atenção seja concentrada nas regras, deixando as excessões para quando as regras estiverem bem compreendidas.

Como sempre diz o Casaretto, o ótimo é inimigo do bom.

[dresser]

Pessoal boa noite.
Eu tenho o mapa City Navigator da Garmin e ele me dá mais de 300 metros de erro da minha casa. Eu usava um número irreal para que ele fisesse a marcação em cima do meu prédio.

Logo.....

[paulocarvalho]

Will, não respondemos pela qualidade dos mapas do City Navigator, mas erros na numeração sempre vai haver pelo menos em uma parcela pequena de casos. Existem erros que São toleráveis, contudo, pois conforme eu havia explanado mais acima, o objetivo da busca de endereços é deixar o usuário o mais próximo possível de seu destino de forma que ele não se perca e não deixar o usuário exatamente à porta do seu destino.

[elderluis]

Senhores, duas dúvidas:

1- Foi desativado o mailing list que avisa as atualizações nas ferramentas? Notei que o Editor de nós foi atualizado no sistema e não foi enviado email, na data de hj, 15abr08, foi atualizado o conversor e tb não foi avisado. Confesso que encontrei as atualizações na "trombada"...

2-O conversor tem a opção de processar as restrições, esse aspecto ainda está em testes ou as compilações dos mapas já estão considerando as restrições?

Obrigado.

[nqnnospam]

Sobre o mailing list não tenho informações.

Sobre o Conversor, o processamento de restrições está bugado ainda.

[paulocarvalho]

1- Foi desativado o mailing list que avisa as atualizações nas ferramentas? Notei que o Editor de nós foi atualizado no sistema e não foi enviado email, na data de hj, 15abr08, foi atualizado o conversor e tb não foi avisado. Confesso que encontrei as atualizações na "trombada"...

Estas foram atualizações no instalador, que é mantida pelo Casaretto.

[Nelson A. da Costa]

Olá pessoal !!

Não estou conseguindo abrir arquivos *.gtm ou *.txt com o Editor de Nós. O sistema dá a seguinte mensagem de erro:
"Erro de E/S:
Invalid byte 2 of 4-byte UTF-8 sequence."

Alguém tem a solução ??

___________________
Nelson

[sorocab]

Nelson, bom dia!

Aparentemente tem alguma via que está retornando à ela mesma, também denominada "arcos circulares" - habitualmente ocorrendo quando não se seguimenta uma rotatória.

Muitas vezes comigo também apareceu tal mensagem, quando em um determinado nó havia uma pequena trilha, quase que somente um ponto.

Reparei que isso habitualmente ocorreu quando inseri uma nova via no mapa e ao fragmentar as que a cruzam, apareceu tal trecho curto - tão pequeno que mais parecia um ponto do que um trecho.

Baixe o novo editor de nós, que parece que neste nova versão ele deverá indicar a localização do erro.

Caso contrário terá que localizar o erro na "unha" - pelo menos era isso que fiz.

Obs.: quando se passa pelo conversor, no relatório elaborado, dá para verificar onde ele acusa erro de nó - mesmo que ele descarte.

O que tenho feito é inserir um ponto no mapa e depois inserir nesse mapa, as coordenadas acusadas no conversor.

Não sou muito experiente e até acredito que os veteranos possam lhe dar uma forma mais fácil, mas essa é a que encontrei de "ir me virando", até que tem aprenda outra forma mais fácil, é o que tem dado resultado.

Espero ter ajudado, bem como não ter falado muita besteira

[Wallace]

Antes de usar o Editor de Nós use o Conversor pois ele vai achar erros ainda não arrumados que impedem abrir no editor ou que não vai achar fácil por lá.

[paulocarvalho]

Olá pessoal !!

Não estou conseguindo abrir arquivos *.gtm ou *.txt com o Editor de Nós. O sistema dá a seguinte mensagem de erro:
"Erro de E/S:
Invalid byte 2 of 4-byte UTF-8 sequence."

Alguém tem a solução ??

___________________
Nelson

Nelson, por favor mande os GTMs e TXTs com problemas para paulo.r.m.carvalho@rio.rj.gov.br .

[Nelson A. da Costa]

Peço desculpas, pessoal !!!
O problema relatado acima não existe mais.
Foi uma falha na peça que fica entre a cadeira e o teclado do notebook, ou seja, simplesmente eu não estava salvando as restrições inseridas nos arquivos.

______________
Nelson