Como contribuir - região de Campinas (SP)

[Shadow600]

Olá Pessoal,

Enquanto não tenho o meu GPS definitivo (60CSx), emprestei um eTrex Legend do meu amigo....

Fiz alguns registros (track) e marquei alguns pontos (POI) que ainda não estão na Versão do Tracksource Municipal que eu abaixei essa semana.

Também passei por algumas ruas que não estão no TM.

Como faço para contribuir?

[nqnnospam]

você deve entrar em contato com o desenvolvedor do mapa.

Para descobrir o nome/email do desenvolvedor, você deve acessar a página http://www.tracksource.org.br/desenv, e usar a função "Consultar emails dos desenvolvedores", Após selecionar o município/estado desejado.

No caso de Campinas, o desenvolvedor sou eu. você pode enviar o material para o meu email de desenvolvedor nqnnospam arroba terra ponto com ponto br. Obrigado.

[Shadow600]

Sergio,

O que exatamente eu preciso te enviar?

[nqnnospam]

1- Para contribuições de vias:

O tracklog, sem ter gravado como trilha. Se a via tiver curvas, o ideal é que o tracklog seja registrado com a resolução máxima permitida pelo GPS (não sei qual é a do Legend), para refletir corretamente o traçado da via. Se a Via for reta, não existe este problema.

É preciso informar o nome da rua, o tipo de pavimentação, e se possível o(s) sentido(s) de trânsito permitidos.

2- Para POIs:

O waypoint indicando a posição do POI, informando se o waypoint foi coletado sobre uma via ou se já está deslocado para refletir a posição correta do POI. A natureza do POI, o nome e o endereço (rua, número, telefone, bairro e CEP).

Com respeito a natureza, alguns POIs possuem particularidades, como por exemplo:

posto de combustível-> informar a bandeira e se tem GNV
restaurante-> informar tipo (churrascaria, asiático, francês, carnes, etc.)
loja -> informar tipo (informática, roupas, materiais de construção, etc.)

[Wallace]

1- Para contribuições de vias:

O tracklog, sem ter gravado como trilha. Se a via tiver curvas, o ideal é que o tracklog seja registrado com a resolução máxima permitida pelo GPS (não sei qual é a do Legend), para refletir corretamente o traçado da via. Se a Via for reta, não existe este problema.

Isso de gravar com a resolução máxima é algo complatamente sem sentido.
Uma boa configuração no GPS é mais inteligente é dá o mesmo resultado na pratica no mapa final.
O metodo automatico mais preciso normalmente já basta e atende bem.
A maior limitação normalmente é a falta de uma antena externa e uma melhor recepção do Legend (assim como alguns outros).
Depois ele já gravou os track.

[Forster]

E começa de novo a eterna discussão de como gerar os tracks... rsrsrs

Como disse em algum post no passado, acho que seria interessante que houvesse uma padronização sobre a recomendação para geração de tracks. Eu acho que, particularmente, como temos o otimizador de trilhas, o ideal seria a gravação com maior precisão possível e passar pelo otimizador, o track fica com número reduzido de pontos, sem perder a qualidade ou sem chanfrar os cantos. Se podemos fazer desta forma, não vejo porque não fazer, afinal de contas, a grande maioria dos GPSs tem memória suficiente pra isso.

Acho que a ferramenta foi desenvolvida justamente para isso.. e funciona muito bem.

Abraços.

[Shadow600]

Eu já gravei os tracklogs... porém nada me empede de gravá-los novamente na resolução máxima (no stress)

O problema é que eu não sei fazer isso... o aparelho (eTrex Legend) é emprestado de um amigo e não estou com o manual.

Alguém sabem se dá para fazer isso nesse modelo?

Abs,

[nqnnospam]

Shadow600, primeiro leia este tópico:

http://www.portalgps.com.br/forum/viewt ... =10&t=1491

Para evitar confusão, eu costumo dizer que o tracklog é registrado pelo GPS, e depois pode ser gravado como trilha.

Quando eu vou levantar uma via, ativo o registro de tracklog, mas nunca o gravo como trilha. Lendo o tópico acima você vai entender porque.

Se você já gravou como trilha, então não há como reverter, só registrando o tracklog da via novamente. Contudo, dependendo do número de pontos no tracklog, talvez a operação de gravação não tenha distorcido o tracklog (veja o tópico mencionado acima). Mande os dados para mim para que eu possa analisar.

Editado: Corrigido link.

[nqnnospam]

Isso de gravar com a resolução máxima é algo complatamente sem sentido.
Uma boa configuração no GPS é mais inteligente é dá o mesmo resultado na pratica no mapa final.
O metodo automatico mais preciso normalmente já basta e atende bem.

Se a pessoa tem um GPS com limite de memória, então você tem razão. Se a pessoa tem um 60CSx com memória virtualmente ilimitada, então o melhor é registrar na precisão máxima, para que o desenvolvedor possa depois otimizar com o aplicativo Otimizador.

Contudo, mesmo quando eu tinha um 60CS (com memória limitada), preferia levantar trechos curtos com precisão alta, do que levantar trechos longos com precisão baixa.

Eu já notei inúmeras vezes, principalmente fazendo o levantamento de trevos (em geral trechos muito sinuosos), que mesmo o método auto-most often introduz distorções apreciáveis. Estas distorções afetam a qualidade do mapa, principalmente para o auto-roteamento.

Isto depende muito de bom senso (para levantar um trecho reto não precisa gravar com resolução de 1s, mas para um trevo não adianta usar auto-most often). E como é sempre mais fácil simplificar um track detalhado, do que descobrir os detalhes de um track simplificado, é melhor recomendar à pessoa inexperiente que grave com a maior resolução possível, do que correr o risco de perder uma boa contribuição porque não foi usada resolução adequada.

[Wallace]

Os GPS que gravam maior quantidade de pontos tem no maximo 10 mil pontos no tracklog ativo, correto.
Se gravar 1 ponto por segundo vai ter menos de 2 horas e 47 minutos de tempo de gravação.
Obiviamente algo que não atende a muitos.
Gravar a cada 1 segundo é no maximo 1 ponto a cada pouco mais de 33 metros se consideramos a velocidade maxima de 120 km/h.
Mas pode ser 100 pontos no mesmo local se fica parado no farol por cerca de 1 minuto e meio.
Se ficar 10 minutos parado num posto de abastecimento São 600 pontos no mesmo local.
Se anda a menos de 18 km/h vai ter pontos a menos de 5 metros um do outro (quando grava a cada segundo), o que não pode pelo compilador.
Se consideramos os uma precisão media que o GPS consegue marcar e boa para o projeto de 10 metros vamos ver que só faz sentido marcar a cada segundo quando se esta acima dos 36 km/h.
Mais dados não significam melhores mapas.
Se algo ficar ruim num trevo ou em qualquer lugar é facil para o desenvolvedor acertar.
E distorções não afetam o roteamento, não tem nada a ver (distorção não erro).
Eu tenho gravado e recebido com gravação automatica no modo mais detalhado sem problema quando o GPS tem boa recepção, mas o bom mesmo é o 276C que permiter colocar o valor do erro, que eu coloco 9 metros quando de carro.
É um caso comum em vairos casos as pessoas acharem que ter mais dados e menor intervalo vão ter dados menores.
A estatistica mostra que isso não é verdade e é desnecessário, sendo um trabalho a mais.
E a engenharia, controle de qualidade, etc mostra que não adianta ficar querendo ter dados no limite da precisão que consegue levantar.
Gostaria de ver argumentos numericos como os que fiz, para contrariar meus argumentos e justificar o de voces.

[nqnnospam]

Os GPS que gravam maior quantidade de pontos tem no maximo 10 mil pontos no tracklog ativo, correto.
Se gravar 1 ponto por segundo vai ter menos de 2 horas e 47 minutos de tempo de gravação.
Obiviamente algo que não atende a muitos.

Isto depende do que está sendo levantado.

2horas e 47 minutos e tempo suficiente para levantar toda a Rodovia Anhanguera entre Campinas e São Paulo, por exemplo, o que é bastante coisa.

É tempo mais que suficiente para levantar vários trevos, outro exemplo.

Gravar a cada 1 segundo é no maximo 1 ponto a cada pouco mais de 33 metros se consideramos a velocidade maxima de 120 km/h.

Como eu disse, as pessoas precisam usar de bom senso. A 120Km/h não tem sentido usar registro por tempo com intervalo de um segundo.

O objetivo de se usar registro por tempo com intervalo de um segundo seria levantar trechos sinuosos, como os vários acessos de um trevo, e nestes casos deve-se andar devagar, justamente para melhorar a resolução (não misturar com precisão, porque as duas coisas não tem relação direta).

Eu já joguei fora levantamentos feitos com antena externa no modo "Auto->Most Often" em trechos sinuosos, e tive que refazer com registro por tempo com intervalo de um segundo.

Mas pode ser 100 pontos no mesmo local se fica parado no farol por cerca de 1 minuto e meio.
Se ficar 10 minutos parado num posto de abastecimento São 600 pontos no mesmo local.
Se anda a menos de 18 km/h vai ter pontos a menos de 5 metros um do outro (quando grava a cada segundo), o que não pode pelo compilador.

Por isso o desenvolvedor deve trabalhar os dados antes de incluir no mapa.

O mesmo ocorreria se os tracks tivessem sido levantados em qualquer outro modo de registro.

O desenvolvedor sempre deve analisar os dados antes de incluí-los no mapa.

Se consideramos os uma precisão media que o GPS consegue marcar e boa para o projeto de 10 metros vamos ver que só faz sentido marcar a cada segundo quando se esta acima dos 36 km/h.

você está confundindo precisão, acurácia e resolução.

Esta sua estimativa de 36Km/h teria que ser feita com base na combinação da acurácia com a precisão, o que é muito complicado, já que o GPS não fornece todos os dados necessários para isso quando registra o tracklog ou um waypoint.

Se algo ficar ruim num trevo ou em qualquer lugar é facil para o desenvolvedor acertar.

não é fácil não, pois é muito difícil inferir informação com falta de dados.

E distorções não afetam o roteamento, não tem nada a ver (distorção não erro).

Afetam sim, e muito.

O modo "Auto-Most Often", não sabe "o que vem pela frente", e pode introduzir (e em geral introduz) dezenas de metros de erro nas posições de saídas de trevos e pistas marginais.

Vou apresentar um exemplo, nas situações onde temos que passar de uma pista expressa para outra marginal paralela. Vamos supor que o desenvolvedor fez o levantamento usando o algoritmo de registro "Auto-Most Often". Este algoritmo demora para "perceber" a mudança de pista, e conecta o último ponto gravado na pista expressa com o primeiro ponto registrado na pista marginal, introduzindo uma distorção significativa no traçado da pista marginal e um erro Também significativo (dezenas de metros) na posição do acesso à pista marginal.

Isto afeta o auto-roteamento sim, de duas formas:

- Primeiro, como a posição do acesso à pista marginal tem dezenas de metros de erro, o tempo e a distância estimados pelo GPS para executar a manobra vão apresentar erros que atrapalharão a navegação.

- Se, em função dos erros nas estimativas de tempo e distância do item anterior, o usuário continuar na pista expressa em lugar de acessar a pista marginal, devido à distorção nos traçados, o sistema de auto-roteamento demora para perceber o erro (ele pressupõe que a pessoa está no caminho correto), e portanto demora a recalcular a rota. Isto pode levar o usuário a perder um retorno ou uma próxima saída.

E este caso não é hipotético. Acontece, por exemplo, na Dutra, na chegada em São Paulo, justamente porque as várias pistas e acessos entre pistas da Dutra foram registradas com muita distorção no local.

Eu tenho gravado e recebido com gravação automatica no modo mais detalhado sem problema quando o GPS tem boa recepção, mas o bom mesmo é o 276C que permiter colocar o valor do erro, que eu coloco 9 metros quando de carro.
É um caso comum em vairos casos as pessoas acharem que ter mais dados e menor intervalo vão ter dados menores.
A estatistica mostra que isso não é verdade e é desnecessário, sendo um trabalho a mais.
E a engenharia, controle de qualidade, etc mostra que não adianta ficar querendo ter dados no limite da precisão que consegue levantar.

Sim, não adianta querer gravar um ponto por metro, mas Também não é aceitável um erro de dezenas de metros (como relatei acima), quando o sistema permite algo melhor.

[cpandora]

Caramba... eh muita informacao. Entao pelo que entendi pra diminuir a margem de erro em trechos sinuosos eh melhor o registro por tempo (isso naturalmente em gps com grande capacidade de armazenamento). O problema acaba sendo o registro dentro da cidade com as constantes paradas do transito, entao aih seria melhor gravar no modo auto... mas neste teriamos problemas com registro em trevos... Concordo com o Foster sobre a padronizacao pois isso ajudaria muito quem entende pouco de computador (como eu...). FELIPPO MONTENEGRO

[Forster]

Felippo,

O otimizador corrige (leia-se: retira) automaticamente os vários pontos sobrepostos causandos por paradas no trânsito, semáforos e etc., assim como pontos em excesso em uma via reta que se ande devagar. Desta forma, o track, por mais pontos que tenha, vai ficar "limpo" e leve, depois de uma passada pelo aplicativo. Vale lembrar que um track já otiminizado não deve ser passado pelo otimizador de novo.

Abraços.

[Wallace]

Isto depende do que está sendo levantado.

2horas e 47 minutos e tempo suficiente para levantar toda a Rodovia Anhanguera entre Campinas e São Paulo, por exemplo, o que é bastante coisa.

É tempo mais que suficiente para levantar vários trevos, outro exemplo.

Acho que você esta assumindo que alguem vai sair especificamente para fazer um levantamento para incluir nos mapas.
Acho que não pode e não deve ser assim.
A sugestão de configuração deve ser feita para um uso normal do GPS onde se vai aproveitar os dados gravado normalmente poir alguem.
Se não for assim se vai ter muito pouco novos dados no projeto.

Como eu disse, as pessoas precisam usar de bom senso. A 120Km/h não tem sentido usar registro por tempo com intervalo de um segundo.

O objetivo de se usar registro por tempo com intervalo de um segundo seria levantar trechos sinuosos, como os vários acessos de um trevo, e nestes casos deve-se andar devagar, justamente para melhorar a resolução (não misturar com precisão, porque as duas coisas não tem relação direta).

Eu já joguei fora levantamentos feitos com antena externa no modo "Auto->Most Often" em trechos sinuosos, e tive que refazer com registro por tempo com intervalo de um segundo.

O bom senso para mim é exigir ou solicitar isso de quem faz uma contribuição.
Isso vai dificultar e inibir a contribuição e pode ser até perigoso solicitar alguem andar devagar em um trevo ou em outros locias movimentados.
não sei qual o problema voce tem, mas o tracks que eu gravo ficam muito bons e o erro do proprio GPS é mais significativo que qualquer outra variavel.

Mas pode ser 100 pontos no mesmo local se fica parado no farol por cerca de 1 minuto e meio.
Se ficar 10 minutos parado num posto de abastecimento São 600 pontos no mesmo local.
Se anda a menos de 18 km/h vai ter pontos a menos de 5 metros um do outro (quando grava a cada segundo), o que não pode pelo compilador.

Por isso o desenvolvedor deve trabalhar os dados antes de incluir no mapa.

O mesmo ocorreria se os tracks tivessem sido levantados em qualquer outro modo de registro.

O desenvolvedor sempre deve analisar os dados antes de incluí-los no mapa.

Negativo, com o 276C com erro de 9 metros não tem como ele criar nenhum segmento com menos de 9 metros.
E se o 60Cx ou similar gravar um segmento menor com 5 metros é a prova final que não precisa chutar o balde configurando para gravar a cada segundo, pois claramente ele vai detalhar mais onde for necessario.

Se consideramos os uma precisão media que o GPS consegue marcar e boa para o projeto de 10 metros vamos ver que só faz sentido marcar a cada segundo quando se esta acima dos 36 km/h.

você está confundindo precisão, acurácia e resolução.

Esta sua estimativa de 36Km/h teria que ser feita com base na combinação da acurácia com a precisão, o que é muito complicado, já que o GPS não fornece todos os dados necessários para isso quando registra o tracklog ou um waypoint.

não estou confundindo nada, estou sendo realista.
Qual o erro que voce considera aceitavel para os mapas do projeto?
Lembrando que não pode ser igual ou inferior a 5 metros já que este é o limite do compilador atual.
Eu considero os 10 metros, mais preciso para mim não faz sentido, e pode ter um erro muito maior sem problema dependendo do dado.

Se algo ficar ruim num trevo ou em qualquer lugar é facil para o desenvolvedor acertar.

não é fácil não, pois é muito difícil inferir informação com falta de dados.

Bem então eu devo ser muito esperto, pois sei alterar qualquer traçado quando não faz sentido ou não esta bom.

E distorções não afetam o roteamento, não tem nada a ver (distorção não erro).

Afetam sim, e muito.

O modo "Auto-Most Often", não sabe "o que vem pela frente", e pode introduzir (e em geral introduz) dezenas de metros de erro nas posições de saídas de trevos e pistas marginais.

Claro que sabe, já que ele só vai gravar o ponto que faz sentido, não gravando o que é retundante.
O para frente dele é a posição atual com referencia aos dados do passado.
Os dados atuais e mais recentes ficam em uma memoria transitoria até se ter o dado que vai ser efetivamente gravado no track.

Vou apresentar um exemplo, nas situações onde temos que passar de uma pista expressa para outra marginal paralela. Vamos supor que o desenvolvedor fez o levantamento usando o algoritmo de registro "Auto-Most Often". Este algoritmo demora para "perceber" a mudança de pista, e conecta o último ponto gravado na pista expressa com o primeiro ponto registrado na pista marginal, introduzindo uma distorção significativa no traçado da pista marginal e um erro Também significativo (dezenas de metros) na posição do acesso à pista marginal.

Voce esta assumindo algo que para mim na pratica nem na teoria é assim.

E este caso não é hipotético. Acontece, por exemplo, na Dutra, na chegada em São Paulo, justamente porque as várias pistas e acessos entre pistas da Dutra foram registradas com muita distorção no local.

Eu não tenho nenhuma distorção desta no que gravo.

Sim, não adianta querer gravar um ponto por metro, mas Também não é aceitável um erro de dezenas de metros (como relatei acima), quando o sistema permite algo melhor.

Voce diz ser melhor, mas não vejo nada real ou teorico demonstrado.
Ao contrario no que eu tenho levantando tem sido muito preciso e teoricamente faz sentido como já demonstrei.
E o que voce propoem pode não ser ser viavel e pratico alem de poder ser algo para inibir as contribuições.
O que eu recomendo é pratico e funcional, tanto que muitas vezes fico enviando tracks de correção a outros desenvolvedores.
Ter mais dados não significa ter melhores dados.
O CEP (controle estatisco da produção) deixa isso bem claro assim como outras feramentas estatisticas e de manipulação de dados.

[Wallace]

Felippo,

O otimizador corrige (leia-se: retira) automaticamente os vários pontos sobrepostos causandos por paradas no trânsito, semáforos e etc., assim como pontos em excesso em uma via reta que se ande devagar. Desta forma, o track, por mais pontos que tenha, vai ficar "limpo" e leve, depois de uma passada pelo aplicativo. Vale lembrar que um track já otiminizado não deve ser passado pelo otimizador de novo.

Abraços.

Pelo que voce fala vamos ter tracks com pontos desnecesarios ao gravamos com 1s, pois mesmo em alta velocidade o maximo que vamos ter é pontos a cada 33 metros; se o otimizador não eliminar estes pontos numa longa reta ou mesmo em curvar de grande raio vamos ficar com dados pesados no mapa sem necessidade, pois em muitos casos um ponto a cada 300 metros ou mais é mais que necessário.
Um ponto que acho que voces não atentaram é que em caso de pior qualidade de sinal no GPS na gravação a cada segundo fica mais dificil se notar que no metodo auto.
E vai se ter mais pontos errados para forçar o otimizador a traçar o caminho distorcido.

[Wallace]

Caramba... eh muita informacao. Entao pelo que entendi pra diminuir a margem de erro em trechos sinuosos eh melhor o registro por tempo (isso naturalmente em gps com grande capacidade de armazenamento). O problema acaba sendo o registro dentro da cidade com as constantes paradas do transito, entao aih seria melhor gravar no modo auto... mas neste teriamos problemas com registro em trevos... Concordo com o Foster sobre a padronizacao pois isso ajudaria muito quem entende pouco de computador (como eu...). FELIPPO MONTENEGRO

Negativo.
Voce esta partindo do conceito errado que gravar por tempo é mais preciso que usar o metodo auto.
Ambos os metodos tem a mesma precisão, só que o metodo auto não grava pontos desnecessarios.
No 276C acho que não tem muito o que discutir pois se pode configurar em metros o desvio cordal que se usa para descartar estes pontos desnecessário.
Acho que a grande questão é em outros GPS qual é o valor deste desvio cordal (se é que é fixo) quando se coloca no metodo auto mais detalhado.
Eu nunca tive nenhum problema e os mapas que desenvolvo e estão no projeto para conferencia e criticas (sempre bem vindas).
A padronização que eu saiba a tempos sempre foi o metodo auto mais detalhado (ou com erro de 9 metros ou similar no 276C no carro ou similar).
Isso esta nas mensagens da lista do yahoo, não sei como esta no manual do projeto, mas deveria ser isso.
O que esta fugindo da padronização é justamente a recomendação de configurar para gravar a cada segundo.

[nqnnospam]

Wallace, sugiro que você pegue o TRR-SP, crie uma rota que vai pela pista expressa da Dutra, e pegue a pista marginal. Observe quanto tempo o GPS leva para descobrir que você errou o caminho. Se este não é um exemplo prático, que vale na prática, não sei o que mais pode ser.

Mais um exemplo. Vá a Campinas, e, saindo da Unicamp em direção ao centro, mande o GPS registrar o tracklog em modo Auto-Most Often. Saia da Unicamp pela Av Dr Romeu Tórtima. No final dela, existe um balão (rotatória), onde há um sinal de trânsito. Para ir em direção ao centro, é necessário pegar o balão à esquerda em direção à Av Albino J B de Oliveira. Se você tiver que parar no sinal, que demora vários minutos para abrir, vai ver que o tracklog registrado no modo Auto-Most Often não vai registrar o balão. Tentei várias vezes registrar o balão no modo Auto-Most Often, mas não consegui.

O tracklog ficava sempre esquisito, uma linha reta ligando o final da Av Albino J B de Oliveira a um ponto bem depois do balão (o tracklog passava por cima do balão). Cheguei a ir no local num domingo, e fiquei passando várias vezes no local em várias velocidades diferentes, para ver se era problema de velocidade. No final, para levantar aquele balão, tive que usar gravação por tempo. Cheguei até a postar uma mensagem na lista sobre isso. Se quiser testar você mesmo, as coordenas do balão São:

S22 50.036 W47 04.739

Vá até lá e verifique você mesmo o que acontece. Vale notar que não há prédios em volta nem nada que bloqueie os satélites, e eu estava usando antena externa.

[nqnnospam]

Pelo que voce fala vamos ter tracks com pontos desnecesarios ao gravamos com 1s, pois mesmo em alta velocidade o maximo que vamos ter é pontos a cada 33 metros; se o otimizador não eliminar estes pontos numa longa reta ou mesmo em curvar de grande raio vamos ficar com dados pesados no mapa sem necessidade, pois em muitos casos um ponto a cada 300 metros ou mais é mais que necessário.
Um ponto que acho que voces não atentaram é que em caso de pior qualidade de sinal no GPS na gravação a cada segundo fica mais dificil se notar que no metodo auto.
E vai se ter mais pontos errados para forçar o otimizador a traçar o caminho distorcido.

não. O Otimizador utiliza o algoritmo de simplificação de traços Douglas-Peucker[1]. Este algoritmo é muito mais poderoso que o do GPS (mesmo o do 276C), pois ele vai calculando o que você chama de desvio cordal, e se o desvio estiver dentro do limite especificado, ele elimina todos os pontos intermediários. Como ele trabalha sobre o track inteiro (ao contrário do GPS, que não sabe o que vem pela frente), ele consegue um grau de simplificação muito maior.

[1]David Douglas & Thomas Peucker, "Algorithms for the reduction of the number of points required to represent a digitized line or its caricature", The Canadian Cartographer 10(2), 112-122 (1973)

http://www.tecgraf.puc-rio.br/~mvera/geomcomp/indx.html
http://129.187.175.5/publications/meng/ ... on1997.pdf
http://www.simdesign.nl/components/douglaspeucker.html

[Wallace]

Wallace, sugiro que você pegue o TRR-SP, crie uma rota que vai pela pista expressa da Dutra, e pegue a pista marginal. Observe quanto tempo o GPS leva para descobrir que você errou o caminho. Se este não é um exemplo prático, que vale na prática, não sei o que mais pode ser.

Mais um exemplo. Vá a Campinas, e, saindo da Unicamp em direção ao centro, mande o GPS registrar o tracklog em modo Auto-Most Often. Saia da Unicamp pela Av Dr Romeu Tórtima. No final dela, existe um balão (rotatória), onde há um sinal de trânsito. Para ir em direção ao centro, é necessário pegar o balão à esquerda em direção à Av Albino J B de Oliveira. Se você tiver que parar no sinal, que demora vários minutos para abrir, vai ver que o tracklog registrado no modo Auto-Most Often não vai registrar o balão. Tentei várias vezes registrar o balão no modo Auto-Most Often, mas não consegui.

O tracklog ficava sempre esquisito, uma linha reta ligando o final da Av Albino J B de Oliveira a um ponto bem depois do balão (o tracklog passava por cima do balão). Cheguei a ir no local num domingo, e fiquei passando várias vezes no local em várias velocidades diferentes, para ver se era problema de velocidade. No final, para levantar aquele balão, tive que usar gravação por tempo. Cheguei até a postar uma mensagem na lista sobre isso. Se quiser testar você mesmo, as coordenas do balão São:

S22 50.036 W47 04.739

Vá até lá e verifique você mesmo o que acontece. Vale notar que não há prédios em volta nem nada que bloqueie os satélites, e eu estava usando antena externa.

Bem suas sugestões para mim São exemplos do coisas sem sentido para alguem fazer.
não faz sentido alguem sair de casa para fazer isso.
Mas acho que tenho varios exemplos de troca de pistas nas marginais aqui entre as pistas locais e expressas e pelo que sei estão perfeitas sem estes atrazos que voce acha que deveria ter com o metodo automático.
Em anexo tem uns tracks meus gravados ai em campinas, para voce e outros verificarem.
Tem alguns pedaços faltando pois já tinha começado a limpar o que estava bom para enviar como contribuição.
Tenho varios outros ainda em estado bruto se quiser; e é claro, sempre gravado com auto.

[Wallace]

não. O Otimizador utiliza o algoritmo de simplificação de traços Douglas-Peucker[1]. Este algoritmo é muito mais poderoso que o do GPS (mesmo o do 276C), pois ele vai calculando o que você chama de desvio cordal, e se o desvio estiver dentro do limite especificado, ele elimina todos os pontos intermediários. Como ele trabalha sobre o track inteiro (ao contrário do GPS, que não sabe o que vem pela frente), ele consegue um grau de simplificação muito maior.

[1]David Douglas & Thomas Peucker, "Algorithms for the reduction of the number of points required to represent a digitized line or its caricature", The Canadian Cartographer 10(2), 112-122 (1973)

http://www.tecgraf.puc-rio.br/~mvera/geomcomp/indx.html
http://129.187.175.5/publications/meng/ ... on1997.pdf
http://www.simdesign.nl/components/douglaspeucker.html

já falei que o GPS sabe o que esta pela frente sim, só que faz de outra forma, ou não eliminaria ponto nenhum.
Conheço alguma coisa destes algoritimos além de alguns mais sofisticados que São segredo industrial, pois trabalho com o software de CAM (manufatura auxiliada por computador) lider de mercado mundial, onde normalmente São gerados caminhos em 3D com segmentos de reta (onde uma ferramenta como uma fresa vai seguir este caminho no espaço).
Ai temos ferramentas de otimização tanto em retas como em curvas (e isso no espaço em 3D se precisar) que não é simplesmente eliminar pontos que estão dentro do desvio cordal, mas pode mudar de posição os pontos inclusive em curvas.
Isso é feito com algoritimos mais parecidos com a suavisação de linha usando curvas de Bezier, mas mais sofisticados.
É basicamente o processo de pegar os pontos e seus pontos medios e deles criar uma curva (que pode ser uma curva reta rs rs).
Ai sobre a curva criada (que é um algoritimo matematico) São usadas formulas, mas ainda é levado em conta os pontos originais.
Isso permite otimizar com eficiencia os pontos, tantos os alinhados numa reta como os "alinhados" numa curva.
Inclusive São algorimimos que permitem serem usados varias vezes mesmo em pontos já otimizados sem causar distorções.
não duvido que a garmin tenha algoritos assim no GPS, mesmo porque ele até faz uma otimização quando se salva um track.

[nqnnospam]

Isso é feito com algoritimos mais parecidos com a suavisação de linha usando curvas de Bezier, mas mais sofisticados.

Spline cúbica, Curva de Bezier? Nesses casos não dá nem para falar em aumento do número de pontos, porque estamos lidando com funções, onde o número de pontos é "infinito"... Um GPS da Garmin não tem processador para fazer essas coisas. não trabalho com CAM, mas fui à faculdade...

[nqnnospam]

Bem suas sugestões para mim São exemplos do coisas sem sentido para alguem fazer.
não faz sentido alguem sair de casa para fazer isso.

Como assim não faz sentido? Estamos falando de levantamento de tracks, não? Como eu vou levantar o track do balão se eu não for lá? não conheço nenhuma forma de fazer isso sem ir no local ... Talvez pedir para alguém, mas esse alguém vai ter que ir até o local do mesmo jeito...

Como você acha que eu fiz todo o mapa do distrito de Barão Geraldo em Campinas? Os tracks não "caíram do céu" no HD do meu PC . O Uirauna me mandou o bairro Cidade Universitária, mas todos o restante tive que levantar dirigindo pelas ruas com o GPS ligado.

Mas acho que tenho varios exemplos de troca de pistas nas marginais aqui entre as pistas locais e expressas e pelo que sei estão perfeitas sem estes atrazos que voce acha que deveria ter com o metodo automático.

não acho, tenho 100% de certeza absoluta. Quem quiser pode ir no local testar. Vai ficar impressionado com os resultados.

[cpandora]

Mais um exemplo. Vá a Campinas, e, saindo da Unicamp em direção ao centro, mande o GPS registrar o tracklog em modo Auto-Most Often. Saia da Unicamp pela Av Dr Romeu Tórtima. No final dela, existe um balão (rotatória), onde há um sinal de trânsito. Para ir em direção ao centro, é necessário pegar o balão à esquerda em direção à Av Albino J B de Oliveira. Se você tiver que parar no sinal, que demora vários minutos para abrir, vai ver que o tracklog registrado no modo Auto-Most Often não vai registrar o balão. Tentei várias vezes registrar o balão no modo Auto-Most Often, mas não consegui.

O tracklog ficava sempre esquisito, uma linha reta ligando o final da Av Albino J B de Oliveira a um ponto bem depois do balão (o tracklog passava por cima do balão). Cheguei a ir no local num domingo, e fiquei passando várias vezes no local em várias velocidades diferentes, para ver se era problema de velocidade. No final, para levantar aquele balão, tive que usar gravação por tempo."

Hoje mandei duas tracks para o Igor que passam pela serra velha de Petropolis-RJ (bastante sinuosa) gravadas no modo auto, vendo no computador notei imprecisoes em algumas curvas (tanto que perguntei se ele precisava que eu fizesse um novo registro); na verdade mandei as tracks pois notei uma falha de roteamento na BR101 voltando da regiao dos lagos justamente em um viaduto com retorno (o gps inssistia que eu estava fora de rota). Talvez esse seja um exemplo do que esta sendo debatido por aqui... FELIPPO MONTENEGRO

[nqnnospam]

Hoje mandei duas tracks para o Igor que passam pela serra velha de Petropolis-RJ (bastante
...
Talvez esse seja um exemplo do que esta sendo debatido por aqui... FELIPPO MONTENEGRO

Bom, eu preciso saber as coordenadas do problema, mas pode ser isso mesmo. O GPS diz que está fora de rota, porque o traçado está muito simplificado, e há outras vias próximas.

[Shadow600]

Sergio,

Como vc prefere que eu te passe as informações?
Posso te passar um arquivo .gdb (Garmin GPS Database Version 3) com as vias (tracks) e os POI (Waypoints) ?

Outra coisa... qual a melhor maneira de te passar as informações das vias e dos POI?
Para Estava pensando em colocar numa planillha do Excel, as informações que vc mencionou numas das mensagens acima. Porém para as vias não sei como te passar as informações de onde começa e onde termina, pois eu tenho o tracklog que tem mais de uma via.

Abs,

[nqnnospam]

Shadow600,

você pode me passar as informações em qualquer formato (gpx, gdb, gtm, etc.), contudo eu acho que fica mais simples para você e para mim se você usar gtm, porque o GPSTrackMaker permite entrar as informações diretamente nas trilhas e waypoints, de forma bem mais simples do que no Mapsource.

Sobre os waypoints, você pode colocar as informações diretamente no comentário do próprio waypoint (comentário, e não nome). Basta separar as informações com ";". Exemplo:

Padaria Belo Pao;555;Av Orozimbo Maia;13000-000 Cambui;19-32371111

Deixe em branco os campos que você desconhece. Se você, por exemplo, não sabe o CEP e o bairro:

Padaria Belo Pao;555;Av Orozimbo Maia;;19-32371111

No caso dos tracks, você pode quebrá-los (cada pedaço corresponde a uma rua), e colocar o nome da rua no nome do track, informando Também se é mão única (coloque <MU> quando for mão única) ou não. Exemplo:

Av Orozimbo Maia<MU>

Para informar o sentido, caso seja mão única, coloque o sentido do track igual ao da rua.

Para quebrar o track, apague um segmento dele no local onde você quer quebrar, depois desenhe este segmento novamente (do final/começo de um pedaço até o começo/final do outro), e responda "não" quando o TrackMaker perguntar se você deseja unir os tracks.

você pode ver o sentido do track "parando" o mouse sobre o track, com a ferramenta "Selecionar dados" (flecha branca) ativada. você pode inverter o sentido do track usando a ferramenta "Inverter Trilhas e Rotas" (Letra "T" cortada por duas flechas paralelas em sentidos opostos).

[Wallace]

Como falei, a padronização do grupo é o metodo Auto.

Segundo o manual do grupo em:
http://tracksourcebrasil.wikispaces.com ... 5ed0455bec

Temos: "Se o seu gps permitir, ajuste o método de gravação de tracklog para AUTO e o intervalo para NORMAL."

então a recomendação que eu tinha feito de usar a opção mais detalhada do metodo Auto é mais detalhada que o recomendado como padrão pelo grupo.

[cpandora]

Show Walace... eu nao tinha lido essa determinacao do manual(usar auto/normal ou tempo/2seg), a track que mandei para o Igor eu gravei em Auto/Normal. Final de semana vou tentar gravar novamente em 1seg (ida) e 2seg(volta) para dar uma comparada. Segunda ou terca digo como ficou. FELIPPO MONTENEGRO

[Forster]

Como falei, a padronização do grupo é o metodo Auto.

Segundo o manual do grupo em:
http://tracksourcebrasil.wikispaces.com ... 5ed0455bec

Temos: "Se o seu gps permitir, ajuste o método de gravação de tracklog para AUTO e o intervalo para NORMAL."

então a recomendação que eu tinha feito de usar a opção mais detalhada do metodo Auto é mais detalhada que o recomendado como padrão pelo grupo.

Wallace, entendo que qualquer discussão é válida e construtiva, mas acho que devemos trabalhar com informações completas. O trecho que vc cita no seu post diz:

"Ao registrar um percurso, se for dentro de cidade ou tiver muitas curvas, use períodos de 2s, senão, pode deixar em 4s. Se o seu gps permitir, ajuste o método de gravação de tracklog para AUTO e o intervalo para NORMAL."

Em minhas experiencias ao usar o Auto, mesmo que most often, fui obrigado a descartar os tracks ou ficar corrigindo as curvas no Google Earth, pois ele cortou os os cantos. Auto-Normal então, nem se fala.. fica péssimo na cidade. A partir dai deixei de usa-lo e voltei a registrar por tempo em conjunto com o otimizador. Ainda, o grupo desenvolveu o otimizador, portanto, acho que o grupo recomenda que o mesmo seja utilizado, não? E não tem muito sentido usar o otimizador em um track gerado pelo auto-most often, mas todo o sentido num track gerado por tempo (que a qualidade fica ótima). Voce ja tentou e comparou? Eu já, e sinceramente, não abro mão de gerar meus tracks por tempo e usar o otimizador depois.

Sinceramente, acho que esta discussão esta se tornando sem sentido. De novo..

Abraços.

[Wallace]

Caro Forster,
Uma das questões principais levantadas é a padronização.
Falaram até que não se tinha padronização.
então como já tinha falado pelo que lembrava das mensagens da lista do Yahoo e pelo que esta escrito no manual a padronização é o formato Auto.
não endenti o que você reclama da informação ser incompleta nas frases:
"Ao registrar um percurso, se for dentro de cidade ou tiver muitas curvas, use períodos de 2s, senão, pode deixar em 4s. Se o seu gps permitir, ajuste o método de gravação de tracklog para AUTO e o intervalo para NORMAL"
Elas São bem claras, se o GPS permitir deve se usar o metodo Auto e não o por tempo.
Acho que esta bem claro mesmo para quem como voce que como advogado gosta das enrolações da palavra rs rs.
Como já falei, uso o metodo Auto sem problemas nos tracks que levanto, claro que eventualmente alguma coisa pode ficar ruim, mas imputo estes erros a problemas na recepção do GPS (mesmo com antena externa).
Assim como já provei aqui teoricamente por numeros e pratica pelos tracks enviados que o metodo Auto, que é o padrão do grupo, atente perfeitamente a construções dos mapas do grupo.
Assim como já provei teoricamente a inviabilidade pratica de se gravar pontos a cada segundo para a maioria.
não vejo nada de discução sem sentido, pelo menos as minhas colocações tem todo o sentido; prático e teorico, tanto que São o padrão do grupo.
Eu posso não concordar que o padrão não devia ser auto Normal, mas sim o auto mais detalhado, mas isso é outra coisa.
Mas voces não podem afirmar que não esta padronizado e nem que o auto é o padrão.
Assim como não podem falar nada de gravar em 1 segundo, pois o manual nunca cita isso.
até fala em 2 ou 4 segundos quando não se tem a opção auto, mas nunca 1 segundo.
Acho que voce ficam na ilusão que quem vai colaborar vai sair na rua com este unico intuito.
Eu entendo que as colaborações devem vir basicamente de quem tem o GPS e eventualmente passa em algum lugar não levantado e ai aproveita seu track como contribuição.
Eventualmente pode fazer como eu já fiz, que é preferir uma via não levantada a uma levantada para aproveitar e ajudar o grupo.
Mas mesmo desta forma a configuração do GPS deve permitir um uso normal do GPS e não algo que obrige a alguem a parar a cada 2 horas e meia para baixar o track do gps para um note ou similar. Isso só inibe as contribuições.
Eu normalmente só baixo meus tracks a cada semana ou depois de um final de semana em que vou passear.

[Forster]

Wallace,

Em primeiro lugar, nao sou advogado.. sou engenheiro. Em segundo lugar, tenho colocado meus pontos de forma clara e objetiva, sem atacar ninguem, e acho um tanto quanto tosco (no mínimo) de sua parte a forma com que vc coloca seus comentários.. Algo como "Acho que esta bem claro mesmo para quem como voce que como advogado gosta das enrolações da palavra rs rs." passa um poucos dos limites. Por várias vezes ja vi vc colocando comentários deste tipo a outros usúarios, e acho que voce exagera as vezes. Vc deveria abaixar um pouquinho a bola, para não entrar mais em situações constrangedoras para voce mesmo, como aquela em que vc ameaçou deixar o projeto pois não concordava com o desenvolvimento de alguns mapas roteaveis, e depois fingiu que nada ocorreu quando foi voto vencido. Como disse, no mínimo, constrangedor. Eu teria cumprido o que disse.

Ninguem está aqui tentando enrolar ninguem, mas sim contribuir com o projeto, de forma prática e construtiva, com mapas de qualidade. Qual é o seu problema quanto a gerar tracks detalhados e usar o otimizador depois? Isto é MUITO mais simples do que ficar corrigindo os tracks na mão, imaginando como era o traçado correto. Explique de forma objetiva, sem fugas ou ataques.

Mas vamos lá... quanto a sua citação, foi incompleta e distorce a verdade para quem não conhece o manual. Da forma que voce colocou da a impressão de que o manual simplesmente fala que é para gerar como Auto e pronto, que não é verdade. Ele dá as opções... Concordo que para aqueles que tem um GPS com 32MB de memória, é sim mais complicado gerar um track longo, mas vc se refere a eles como maioria. Voce tem dados para saber se esses GPSs São a maioria?

O que inibe contribuições São atitudes como esta, e como uma que vc teve comigo, quando enviei um track detalhado, e bem coletado por sinal, e vc reclamou pacas, disse que não dava pra aceitar porque iria demorar muito para incluir pois estaria simplificando ele na mão, pois tinha sido gerado em 1s. Eu enviei o track detalhado, e sem alterações, para que o desenvolvedor pudesse utiliza-los da melhor forma.. Qualquer desenvolvedor com um pouco de bom senso estaria agradecendo um track bem feito e otimizando ele com a ferramenta, mas vc preferiu ser do contra, dizendo que não dava pra usar. Sabe o que eu fiz? Pedi o mapa da cidade para eu desenvolver. E digo hoje, que ele está bem completo, e com sua Versão roteavel cobrindo praticamente a cidade inteira.

Ao inves de ficar atacando as pessoas, e sempre sendo do contra e empacando o projeto (como nesta discussão e na outra sobre o tamanho dos mapas), acho que tem várias outras formas de se ajudar o projeto... Voce conhece bastante do assunto, e poderia contribuir muito mais com uma postura mais positiva e construtiva.

E como disse antes, discussão essa sem sentido, principalmente quando é com vc. Responda o que quiser, ou nao.. não me darei ao trabalho de responder a outros posts seus sobre o assunto. Perda de tempo.

[nqnnospam]

Pessoal, e isto vale para todos, não vamos levar a coisa para o lado pessoal, ok? É muito chato para a moderação ter que ficar apagando mensagens.

Wallace, você diz que não, mas eu Também mostrei em teoria e prática como a gravação no modo auto->most often pode gerar problemas, inclusive no track que você postou.

você diz que as pessoas não saem de casa para fazer levantamentos para o Tracksource. Eu digo que as pessoas saem sim. Todos os levantamentos que fiz em Campinas foram dessa forma, isto é, sai de casa exclusivamente para levantar os trechos.

E já recebi várias mensagens de pessoas, a maior parte através de email, informando que querem contribuir fazendo o levantamento deste ou daquele trecho do mapa. Perguntam qual a forma ideal de fazer levantamento, e eu passo a minha opinião.

não vejo problema nenhuma em passar o Otimizador nos track coletados, não leva mais que alguns minutos. É muito mais complicado receber um track muito simplificado e ter que ficar inventando formas de corrigir.

E, novamente, não estou falando de situações hipotéticas. Estou com este problema no mapa Bahia. Boa parte das contribuições foram/São enviadas por pessoas que fazem viagens longas, e por isso acabam reduzindo demais a resolução do registro (para não estourar a memória), o que gera distorções de centenas de metros nos tracks. Claro, não estou criticando as contribuições enviadas no passado. Era a única coisa que as pessoas podiam fazer, pois as memórias de tracklog eram limitadas. Daí rotatórias viram uma retas, ruas desaparecem, retornos São extintos, acessos somem, etc., etc., e eu, desenvolvedor, tenho que adivinhar estas coisas (e obviamente não consigo, não sem ir até o local, o que nem sempre é possível).

Concordo que a 2, 3, 10 anos atrás tinha que ser assim, mas hoje até mesmo os modelos simples da linha eTrex da Garmin já estão saindo com cartão de memória, e permitem registrar o tracklog em cartão. Logo não há razão para manter hoje uma recomendação que só fazia sentido 5 anos atrás.

É preciso evoluir, para que nosso Projeto fique cada vez melhor. Se a pessoa tem um GPS que registra o tracklog em cartão, ou está disposta a fazer levantamento numa área limitada, não vejo porque não recomendar a essa pessoa que faça o levantamento por tempo com 1 ou 2 segundos de intervalo.

[Wallace]

Wallace,

Em primeiro lugar, nao sou advogado.. sou engenheiro.

Minhas desculpas quanto a isso, mas tinha lembrança que você era advogado. Devo confundido com outro.

Em segundo lugar, tenho colocado meus pontos de forma clara e objetiva, sem atacar ninguem, e acho um tanto quanto tosco (no mínimo) de sua parte a forma com que vc coloca seus comentários.. Algo como "Acho que esta bem claro mesmo para quem como voce que como advogado gosta das enrolações da palavra rs rs." passa um poucos dos limites.

Bem acho que voce deve se informar, pois rs rs mostra "risadas" algo usado quando se esta brincando, normalmente feito para descontrair.

Por várias vezes ja vi vc colocando comentários deste tipo a outros usúarios, e acho que voce exagera as vezes. Vc deveria abaixar um pouquinho a bola, para não entrar mais em situações constrangedoras para voce mesmo, como aquela em que vc ameaçou deixar o projeto pois não concordava com o desenvolvimento de alguns mapas roteaveis, e depois fingiu que nada ocorreu quando foi voto vencido. Como disse, no mínimo, constrangedor. Eu teria cumprido o que disse.

Pode reler o topico que voce cita que eu não fui voto vencido não, ao contrario.
Só não posso, nem quero, obrigar ninguem a seguir coretamente os padrões do grupo. Isso é tarefa para outros.

Ninguem está aqui tentando enrolar ninguem, mas sim contribuir com o projeto, de forma prática e construtiva, com mapas de qualidade. Qual é o seu problema quanto a gerar tracks detalhados e usar o otimizador depois? Isto é MUITO mais simples do que ficar corrigindo os tracks na mão, imaginando como era o traçado correto. Explique de forma objetiva, sem fugas ou ataques.

já expliquei, primeiro não é o padrão do grupo, depois não é algo viavel para a grande maiores independe do GPS que tenha.

Mas vamos lá... quanto a sua citação, foi incompleta e distorce a verdade para quem não conhece o manual. Da forma que voce colocou da a impressão de que o manual simplesmente fala que é para gerar como Auto e pronto, que não é verdade. Ele dá as opções... Concordo que para aqueles que tem um GPS com 32MB de memória, é sim mais complicado gerar um track longo, mas vc se refere a eles como maioria. Voce tem dados para saber se esses GPSs São a maioria?

não distorci nada, coloquei exatamente como esta no manual, voces é que estão querendo distorcer e colocar algo que não existe no manual (como gravar a cada 1 segundo).

O que inibe contribuições São atitudes como esta, e como uma que vc teve comigo, quando enviei um track detalhado, e bem coletado por sinal, e vc reclamou pacas, disse que não dava pra aceitar porque iria demorar muito para incluir pois estaria simplificando ele na mão, pois tinha sido gerado em 1s. Eu enviei o track detalhado, e sem alterações, para que o desenvolvedor pudesse utiliza-los da melhor forma.. Qualquer desenvolvedor com um pouco de bom senso estaria agradecendo um track bem feito e otimizando ele com a ferramenta, mas vc preferiu ser do contra, dizendo que não dava pra usar. Sabe o que eu fiz? Pedi o mapa da cidade para eu desenvolver. E digo hoje, que ele está bem completo, e com sua Versão roteavel cobrindo praticamente a cidade inteira.

não lembro disso, mas acho dificil eu ter dito que não poderia usar, mas posso ter dito sim que poderia demorar para incluir.

Ao inves de ficar atacando as pessoas, e sempre sendo do contra e empacando o projeto (como nesta discussão e na outra sobre o tamanho dos mapas), acho que tem várias outras formas de se ajudar o projeto... Voce conhece bastante do assunto, e poderia contribuir muito mais com uma postura mais positiva e construtiva.

E como disse antes, discussão essa sem sentido, principalmente quando é com vc. Responda o que quiser, ou nao.. não me darei ao trabalho de responder a outros posts seus sobre o assunto. Perda de tempo.

Em ambos os casos eu estou simplesmente atentando para coisas fora do padrão que se esta fazendo. E isso é uma forma de ajudar o projeto. E elas São positivas e construtivas, mas para quem não concorda comigo ou com o padrão ou o que esta no manual pode achar o contrario.

[Wallace]

Vou verificar o topico, pois não vi seu comentario do meu track, mas eu acabei passando pela dutra ao ir num cliente, depois vou baixar o track do GPS.
Legal voce ter tempo, meios para estas saidas para levantamento, mas isso não deve ser o padrão do pessoal.
Bem se algo tem que evoluir então é o manual se isso for considerado viavel.
Antes disso eu não acho bom pedir para alguem gravar com intervalo de 1 segundo, principalmente pela baixa autonomia para quem não tem maior experiencia em levantar, desenvolver, etc.
Mas de toda forma acho um trabalho a mais ter que fazer alguma redução que não precisaria ser feita com o metodo Auto.

[Wallace]

Sergio não tem comentario seu sobre track que postei.

[thobryan]

Sergio, gostaria de contribuir para o mapa roteavel de Campinas. Os passos São diferentes para a contribuição dos mapas não roteaveis? Aonde eu encontro os documentos para ler a respeito ?


abraços

[nqnnospam]

thobryan, desculpe a demora em responder. Estou com dificuldades para acompanhar o fórum (aqui de casa o acesso é muito lento, e no trabalho não tenho tempo nem para piscar ).

As instruções gerais estão em http://tracksourcebrasil.wikispaces.com. você Também pode entrar em contato comigo diretamente:

nqnnospam @ terra ponto com ponto br.

Obrigado pelo interesse em colaborar.

[Simmonds]

E, novamente, não estou falando de situações hipotéticas. Estou com este problema no mapa Bahia. Boa parte das contribuições foram/São enviadas por pessoas que fazem viagens longas, e por isso acabam reduzindo demais a resolução do registro (para não estourar a memória), .

Se me permitem a interferencia?

Sou novo no Portal, Sou novo no uso do GPS, moro em Salvador e faço essas viajens longas como voce diz.

Mas a pergunta é:

Existe uma forma de fazer a coleta dos dados por partes ?
Exemplo:
Saindo de Feira de Santana-BA em direção a Barreiras-BA
Quando chegar a ARGOIM finaliza o trecho e salva (passa para o Notebook) começa outro em Argoim e vai ate Itaberaba, encerra, salva no Notebook, começa outro e vai ate Seabra, sempre usando trechos de 100 a 200Km .
Isso é possível ?

Se eu estiver falando uma besteira me perdoem, como disse sou novo na área.

[Wallace]

Sim claro, sem problemas.

[Simmonds]

Ok,

Neste caso, como eu faria para juntar todos os trechos num so arquivo ?

[moraes19]

No GPS Trackmaker.

Arquivo -> Unir Arquivos -> Em Abrir Arquivo: Escolha o arquivo -> Abrir;

Repita o processo;

No final:

Arquivo -> Salvar Arquivo Como -> Em Salvar Arquivo: Escolha onde Salvar;
Em Nome: Dê um nome diferente dos arquivos que uniu, se for o caso;
Em Tipo: Escolha .gtm, ou .txt, etc. -> Salvar.

[Simmonds]

Moraes, me desculpe, esqueci de dizer que no momento estou usando o mapsource para receber e enviar os waypoints , tracks etc para o GPS.

não sei se o GPS TRackmaker vai reconhecer os arquivos gerados pelo mapsource

Vou testar e depois e edito .

Editando

Ok, consegui extrair os waypoints do GPS pelo mapsource e salvei cada um no formato GPX, no GPS TrackMaker, uniu todos e criei um outro com todos.

Blz.


Grato

[Wallace]

Quero aqui parabenizar ao Sérgio Barroso e quem mais contribui pelo recente lançamento da versão do TRU deste importante mapa de SP.
Agora vou pertubar outros com outros mapas importantes que ainda não estão no TRU rs rs

[nqnnospam]

Agora é acertar o sentido de tráfego em todas as vias de mão única (parte já foi feito), e aumentar o número de POIs, que por enquanto é muito baixo.