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.