[Talk-br] [Cocar] Contribuintes para cidades do RJ no OSM

Quinta Dezembro 19 21:22:19 UTC 2013

Concordo que a imagem está "descontínua", mas não que esteja "mal
georreferenciada". Exatamente onde você apontou (-5.9728 -40.7305) há
3 fotos no Bing: a oeste (vou chamar de imagem A), a nordeste (imagem
B) e a sudeste (imagem C). Se você for para o leste, verá que as vias
da imagem B se conectam quase perfeitamente às vias da imagem C. De
forma similar, indo para o sul, as da imagem A se conectam quase
perfeitamente às da imagem C. Mais ao norte, perto do lago, as vias da
imagem A se conectam às da imagem B com um pouco de defasagem (em
torno de 6m). O que acontece é que entre as imagens A, B e C existe um
buraco sem imagem nenhuma. Ali, em alguns casos, seria aceitável
"interpolar" a via por uma linha reta caso não houvesse tempo/recursos
para se fazer um survey - seria melhor do que não ter via nenhuma
mapeada. Outra sugestão é dar uma olhadinha em outras imagens de
satélite (ex.: Google Maps) para saber se realmente existe uma via
nessa área descontínua - mas sem usar a imagem do Google para traçado.

Sabendo que o Google tem um georreferenciamento mais exato, eu resolvi
fazer um teste: usando a imagem do Bing no JOSM, marquei um ponto bem
no encontro em que uma estrada encontra a descontinuidade, obtive a
coordenada (em Edit > Move node) e verifiquei no Google (pesquisando
pela coordenada) onde ela caía. O que encontrei é que a
correspondência da imagem do Bing com a do Google é quase exata (os
pontos caíram em cima de estradas de terra ou muito próximos a elas),
para as fotos A, B e C. As coordenadas que eu testei foram:
- foto A: -5.9724485 -40.7080431
- foto B: -5.97009 -40.739438
- foto C: -5.973538 -40.7364515

Você pode repetir esse experimento. Crie um ponto no JOSM, vá em Edit
> Move node, e cole uma das coordenadas acima. Pressione "3" para
visualizar onde o ponto foi parar. Daí habilite a imagem em Imagery >
Bing Sat.

Depois, faça uma busca no Google Maps pela mesma coordenada, usando a
imagem de satélite como fundo. O resultado será uma seta verde
apontado para baixo (o ponto exato é na ponta da seta). Em ambos os
casos, o ponto deve cair no centro de uma via ou muito perto. Você vai
notar que no Google Maps a foto A esta ligeiramente deslocada, em
torno de 3m. Poderia ser o Google ligeiramente mal georreferenciado,
ou o Bing, mas é mais provável que seja o Bing.

Você pode usar testes simples como esse quando desconfiar do
georreferenciamento do Bing. Nesse caso está tudo ok, mas em outros
certamente você encontrará diferenças maiores.

2013/12/19 ThUnDeRCeL <thundercel em gpsinfo.com.br>:
> Fernando,
> o erro de georreferenciamento apontado por mim no Bing se inicia no lago e
> vai distorcendo mais ainda até o sul quando as quadriculas vão se abrindo.
>
> Não vou entrar em mais detalhes já citados da curvatura da terra, mas vá
> navegando para o sul, acompanhando a abertura das quadricula que terá noção
> da área dessa quadrícula.
>
> O ponto extremo ao sul onde tem a abertura é
> http://www.openstreetmap.org/edit#map=14/-5.9728/-40.7305
>
> Por fim volto a comentar que esse foi um simples exemplo, mas se desejar
> posso apontar inúmeros outros em área diferente dessa. Como cite há 3 anos
> trabalhamos plotando pontos radar em todo o Brasil e para isso empregamos
> imagens satélite de diferentes provedores, inclusive BING.
>
> Da experiência adquirida até hoje posso afirmar que as imagens satélite para
> o Brasil ainda requerem muitos ajustes. Quem sabe para a Copa e Olimpíadas
> esse pessoal vai focar mais no Brasil.
>
>
> -----Mensagem Original-----
> From: Fernando Trebien
> Sent: Thursday, December 19, 2013 5:55 PM
> To: Cooperativa de Cartografia Digital Livre ; OSM talk-br
> Subject: Re: [Cocar] Contribuintes para cidades do RJ no OSM
>
> "No tocante ao georeferenciamento da imagem do Bing precisamos
> primeiro validar esse georeferenciamento na área que iremos trabalhar
> para depois sim, aplicar tolerância lateral."
>
> Concordo totalmente, e a comunidade recomenda isso também,
> especialmente para mapeamento no interior. Mas mesmo sem validação,
> pode ficar tranquilo que em todas as maiores cidades brasileiras a
> imagem está suficientemente alinhada.
>
> "Tem certeza disso? Onde está escrito? Lembro que estamos nos
> referindo a área de quadriculas empregadas em imagens satélites."
>
> Isso é fruto da minha experiência com o Bing até o momento.
>
> "Não quero criticar o trabalho do pessoal do Bing, Google e outros,
> mas em mensagem anterior já apresentei distorção de quadricula."
>
> Por incrível que pareça, essa quadrícula não está tão mal
> georreferenciada assim. Nesse mesmo caso que você citou, em todos os
> pontos em que uma via se conecta de uma quadrícula para outra (na
> verdade, de uma foto para outra, elas não caem exatamente na borda das
> quadrículas), o erro máximo que eu consegui detectar visualmente foi
> de um pouco mais de 6 metros. Procure pelas conexões entre as vias (a
> maioria estradas de terra) um pouco mais ao norte e um pouco mais ao
> sul do lago.
>
> Então, existe um pouco de erro nessa área? Existe. Quão significativo
> ele é? Não tanto a ponto de se cobrar o georreferenciamento ou um
> survey da área, seria mais importante ter um mapeamento prévio feito o
> quanto antes possível, e a forma mais rápida seria desenhar sobre as
> imagens. Mas dá pra georreferenciar ou mapear em campo? Claro, é o
> ideal! Mas demora mais tempo. E existe distorção? Pouquíssima, e bem
> suave e uniforme ao longo de cada foto. Mas em relação à precisão
> típica de uma carta náutica? Está pior, sem dúvida, mas não é
> descartável. O pior mesmo é quando o Bing não tem uma imagem com
> resolução suficiente para se distinguir onde estão as vias (daí apenas
> uma inspeção em campo resolve, e nesse caso é necessário fazer como
> você indica, mapeando várias vezes), mas não é esse o caso aqui.
>
> O lago parece cortado porque as duas fotos foram tiradas em momentos
> diferentes e porque o lago é sazonal. Veja o mesmo no Google (basta
> procurar no Google Maps por "-5.5505 -40.7334"). Poucas pessoas
> sabem/se preocupam com isso, mas o contorno da separação terra/água
> idealmente deve ser a média de vários contornos obtidos ao longo dos
> últimos 19 anos (li esta "regra" num fórum francês uns tempos atrás).
> No caso de um lago sazonal, a área que às vezes é molhada e às vezes é
> seca pode ser demarcada com a tag natural=wetland. Mas esse nível de
> preociosismo dificilmente poderia ser esperado por um colaborador
> "eventual" do OSM, cujas prioridades/preocupações quase sempre são
> outras. Porém, fontes oficiais como o IBGE podem já ter calculado o
> contorno seguindo alguma regra parecida, e por isso é importantíssimo
> colocar a tag "source" nos elementos importados dessas fontes
> oficiais.
>
> Como rodovias não são sazonais, o mesmo problema não as afeta nesse
> caso, mesmo as fotos tendo idades diferentes e tendo uma grande
> descontinuidade (porém não desalinhada) mais ao sul. Apesar da
> descotinuidade, em vários pontos aqui seria aceitável aproximar o
> contorno real de muitas das vias simplesmente com linhas retas - ao
> menos temporariamente, até que uma foto melhor esteja disponível.
> Claro, se você fizer um survey do local com equipamento especializado,
> alcançará um resultado melhor, mas não "muito" melhor, e essa área
> (por ser afastada) não é tão urgente pro usuário médio, só para uns
> poucos que estariam passando por ela.
>
> 2013/12/19 ThUnDeRCeL <thundercel em gpsinfo.com.br>:
>> Ferramentas de validação de georreferenciamento?
>> Em que pese que estava me referindo a validação da tolerância dos 3m,
>> georeferenciamento de um ponto é validado sim.
>> Não me vem a cabeça a quantidade de pontos aeronáuticos por mim validados
>> em
>> vôo para que pudessem ser empregados nas cartas aeronáuticas. Lembro que
>> antes já citei que fui piloto inspetor do Sistema de Controle do Espaço
>> Aéreo Brasileiro. Para validação das aerovias e Waypoints empregávamos a
>> aeronave laboratório do Geiv equipada com todos os equipamentos necessário
>> as validações das informações no mapa desenvolvidas por cartógrafos do
>> Instituto de Cartografia Aeronáutica.
>> No tocante ao georeferenciamento da imagem do Bing precisamos primeiro
>> validar esse georeferenciamento na área que iremos trabalhar para depois
>> sim, aplicar tolerância lateral.
>>
>> A curvatura da terra é pouquíssimo significativa dentro de uma mesma
>> quadrícula com um nível suficiente de aproximação (por exemplo, num nível
>> em
>> que se visualiza uma cidade inteira). E mesmo assim, o processo de
>> ortorretificação do Bing compensa isso.
>> Tem certeza disso? Onde está escrito? Lembro que estamos nos referindo a
>> área de quadriculas empregadas em imagens satélites.
>>
>> Entre quadrículas adjacentes também não há esse problema: o Bing faz um
>> bom
>> trabalho em fazer as imagens se corresponderem.
>> Não quero criticar o trabalho do pessoal do Bing, Google e outros, mas em
>> mensagem anterior já apresentei distorção de quadricula.
>> Veja novamente em
>> http://www.openstreetmap.org/edit#map=16/-5.5505/-40.7334
>> Nesse local da lagoa vá navegando para sul e vai acompanhar a abertura da
>> quadricula
>> Voltando a citar ter eu encontrado eu muitos erros desse tipo na cobertura
>> do Brasil.
>>
>>
>>
>> From: Fernando Trebien
>> Sent: Thursday, December 19, 2013 3:55 PM
>> To: Cooperativa de Cartografia Digital Livre
>> Subject: Re: [Cocar] Contribuintes para cidades do RJ no OSM
>>
>> "Uma regra eficiente e eficaz deve e pode ser aplicada para todo o Brasil
>> desde que se tenha ferramentas de validação."
>>
>> Ferramentas de validação de georreferenciamento?
>>
>> "Deveria, mas na pratica não é devido a curvatura da terra.
>> Aprendi muito sobre isso quando fui apresentado a conceitos da
>> Aerofotogrametria já que realizei alguns voos em suporte a ela. Também
>> tive
>> de aprender sobre o efeito da curvatura da terra na elaboração de vídeos
>> mapas para emprego em radar de navegação aérea.
>> Além da influencia da curvatura da terra devemos considerar os erros de
>> união das quadriculas na imagem.
>> Decididamente o georeferenciamento não é uniforme."
>>
>> A curvatura da terra é pouquíssimo significativa dentro de uma mesma
>> quadrícula com um nível suficiente de aproximação (por exemplo, num nível
>> em
>> que se visualiza uma cidade inteira). E mesmo assim, o processo de
>> ortorretificação do Bing compensa isso.
>>
>> O que acho mais impressionante é que ela compensa muito bem as distorções
>> do
>> relevo também, mesmo que as fotos sejam tiradas lateralmente, tanto que
>> nunca notei uma distorção significativa (nada que "salte aos olhos").
>> Diria
>> com certeza quase absoluta que, na mesma quadrícula, essa distorção deve
>> ficar dentro de uns poucos centímetros. Ao longo da quadrícula, se houver
>> alguma distorção, ela varia tão suavemente que nunca percebi.
>>
>> Entre quadrículas adjacentes também não há esse problema: o Bing faz um
>> bom
>> trabalho em fazer as imagens se corresponderem. Na borda de duas
>> quadrículas, o erro máximo que eu já encontrei é inferior à largura de uma
>> calçada, e isso é visível claramente na imagem.
>>
>> Sendo assim, uma área tão grande quanto Porto Alegre poderia ser
>> inteiramente mapeada sobre o Bing e por fim receber um único deslocamento
>> uniforme (igual para todos os pontos) para corrigir o erro de
>> georreferenciamento, com possíveis distorções sendo pequenas demais para
>> serem relevantes. Isso foi feito em praticamente todas as grandes avenidas
>> daqui (daquelas que têm as mãos separadas). O resultado (que eu uso
>> diariamente para navegação) é tão bom que nunca meu GPS identificou que eu
>> estava na pista de sentido oposto (e ele me mostra tanto a minha posição
>> projetada na pista quanto a minha posição real). Assim, a prática me
>> garante
>> que essas distorções (que não foram georreferenciadas por mim) estão bem
>> abaixo dos 6m em boa parte da imagem.
>>
>> O Google Maps certamente faz melhor, mas os parâmetros do Bing já são
>> muito
>> bons por si só (novamente, varia por localidade, mas nas grandes cidades
>> está ok). Em relação ao Google, algo que notei no Bing é que muitas
>> imagens
>> são tiradas com um certo ângulo lateral (dá pra ver as paredes dos
>> edifícios). O que quer dizer que, ao mapear um edifício, depois de
>> desenhar
>> sobre o telhado, eu movo o polígono para que este coincida com a base do
>> edifício. Mas nem todos os usuários sabem disso. Contudo, muitos mapeiam a
>> parte superior do edifício sem cuidado com esses detalhes (que nesse caso,
>> seria relativamente óbvio). O que temos são colaboradores com os mais
>> variados graus de compreensão de tecnologia de mapeamento, e é importante
>> ter paciência com eles.
>>
>>
>> 2013/12/19 ThUnDeRCeL <thundercel em gpsinfo.com.br>
>>>
>>> Calma. Os 3m que eu respeito não incluem os erros de georeferenciamento
>>> das imagens. O erro total das coisas que eu mapeio é bem superior a isso
>>> (deve estar em torno de 12m aqui em porto alegre).
>>> Aí está o conceito de eficiência x eficácia que citei anteriormente.
>>> Aplicando tolerância de 3m sobre uma referencia errada, poderemos,
>>> dependendo do lado aplicado, estar agregando mais 3m ao erro existente.
>>> Estaremos sendo eficientes em manter em 3 metros um traçado (eficiente)
>>> tendo como referencia outro traçado errado (ineficaz).
>>> Lembra o exemplo que dei e veja se não é bem similar a isso:
>>> “um piloto faz excelente pouso (eficiente), mas no aeroporto errado
>>> (ineficaz)”
>>>
>>> O erro total das coisas que eu mapeio é bem superior a isso (deve estar
>>> em
>>> torno de 12m aqui em porto alegre).
>>> Nesse aspecto acredito que ganho de você porque aqui no Rio tenho mapeado
>>> com erros bem menores porque a imagem satélite aqui, na minha opinião,
>>> está
>>> perfeita.
>>> Mas não devemos levar esses locais em consideração porque não estamos
>>> mapeando só neles. Devemos ter uma noção geral, de todo o Brasil e isso
>>> lhe
>>> garanto que tenho pelo fato de emprego de posicionamento de pontos de
>>> alerta
>>> para o MapaRadar já citado por mim anteriormente.
>>> Uma regra eficiente e eficaz deve e pode ser aplicada para todo o Brasil
>>> desde que se tenha ferramentas de validação. Em não existindo considero
>>> essa
>>> regra ineficaz.
>>>
>>> Pense que o erro total inclui: erro de georeferenciamento + erro de
>>> mapeamento. Se conseguíssemos eliminar o erro de georeferenciamento, o
>>> ideal
>>> é que erro restante (desvios em relação ao eixo na imagem, desvios
>>> resultantes da simplificação, etc.) ficasse próximo de 3m.
>>> Em se eliminando erro de georeferenciamento eu sou mais perfeccionista e
>>> iria buscar empregar valor inferior a esse dos 3m. Espero estar vivo
>>> ainda
>>> para ver esse dia chegar.
>>>
>>> Isso é porque o erro de georefereciamento geralmente é uniforme
>>> Deveria, mas na pratica não é devido a curvatura da terra.
>>> Aprendi muito sobre isso quando fui apresentado a conceitos da
>>> Aerofotogrametria já que realizei alguns voos em suporte a ela. Também
>>> tive
>>> de aprender sobre o efeito da curvatura da terra na elaboração de vídeos
>>> mapas para emprego em radar de navegação aérea.
>>> Além da influencia da curvatura da terra devemos considerar os erros de
>>> união das quadriculas na imagem.
>>> Decididamente o georeferenciamento não é uniforme.
>>>
>>> Aí entra um detalhe interessante no OSM. Para que os outros saibam que o
>>> que está no mapa foi obtido por essa metodologia, você deve se preocupar
>>> em
>>> colocar a tag "source" nos elementos que você mapear. Se estiver traçando
>>> sobre a imagem do Bing, coloque source=Bing (ou não
>>> coloque nada e todos entenderão que foi usando o Bing ou outra fonte
>>> menos
>>> confiável). Se estiver coletando tracklogs, coloque source=survey. Se a
>>> fonte for outra (digamos, um mapa de uma prefeitura), coloque
>>> source=[nome
>>> da prefeitura]. Essa tag serve tanto como informação como para detectar
>>> plágio (por exemplo, source=Google é proibido).
>>> Gostei dessa informação. Muito util. Eu não sabia.
>>> Geralmente  traço via após coleta de tracks, Não imagine o que já rodei
>>> no
>>> Rio de Janeiro só coletando tracks,
>>> Claro que aprendi a técnica de jogar a imagem satélite como background e
>>> alinha-la pela média dos tracks.
>>> Custei a adquirir essa experiência e no inicio, quando iniciei o
>>> desenvolvimento de mapas, muitos erros de alinhamento cometi.
>>>
>>> Para que tenha i´deia, nesse ultimo final de semana estava eu tão
>>> incomodado com a situação de circulação no centro do Rio devido as obras
>>> para a copa que decidi pegar o carro e ir lá rodar e levantar tracks para
>>> registrar e desenhar as vias inauguradas, interditadas definitivamente e
>>> a
>>> circulação de um modo geral.
>>>
>>> Em chegando em casa revisei tudo que vi e editei a região do centro do
>>> Rio
>>> no OSM mas sem o source= porque não sabia. Depois corrijo lá.
>>>
>>> -----Mensagem Original-----
>>> From: Fernando Trebien
>>> Sent: Thursday, December 19, 2013 2:33 PM
>>> To: Cooperativa de Cartografia Digital Livre
>>> Subject: Re: [Cocar] Contribuintes para cidades do RJ no OSM
>>>
>>> "Se tem você conseguido cumprir essa recomendação dos 3m parabéns! Eu,
>>> mesmo com a experiência que detenho em desenvolvimento de mapa, com as
>>> ferramentas ora disponíveis, não consigo!"
>>>
>>> Calma. Os 3m que eu respeito não incluem os erros de
>>> georeferenciamento das imagens. O erro total das coisas que eu mapeio
>>> é bem superior a isso (deve estar em torno de 12m aqui em porto
>>> alegre).
>>>
>>> Pense que o erro total inclui: erro de georeferenciamento + erro de
>>> mapeamento. Se conseguíssemos eliminar o erro de georeferenciamento, o
>>> ideal é que erro restante (desvios em relação ao eixo na imagem,
>>> desvios resultantes da simplificação, etc.) ficasse próximo de 3m.
>>>
>>> Isso é porque o erro de georefereciamento geralmente é uniforme: mesma
>>> distância e direção para uma área muito grande. Removê-lo consiste em
>>> apenas descobrir o deslocamento a ser aplicado e a qual área. Feito
>>> isso, basta selecionar todos os pontos e aplicar o deslocamento
>>> inverso. Já um erro de mapeamento precisa ser corrigido caso a caso,
>>> ponto por ponto, e é muito mais trabalhoso.
>>>
>>> Se o seu GPS tivesse precisão absoluta, você estaria introduzindo
>>> erros por fazer uma amostragem da sua posição a cada 7m. Esse erro
>>> sempre existe, independente de quão preciso seja o equipamento. Com o
>>> celular que eu uso, o erro fica quase sempre dentro de 8m. O fato de
>>> ter AGPS às vezes prejudica essa métrica (chegando a 20m), mas é algo
>>> que no fim das contas faz pouca diferença porque, antes de fazer o
>>> upload, eu vou invariavelmente ajustar os pontos à imagem ao Bing -
>>> que, se estiver mal georeferenciada, pode ser corrigida depois com um
>>> simples deslocamento.
>>>
>>> Certamente, isso se torna mais preocupante nos lugares onde o
>>> georeferenciamento do Bing está muito mal, como nesses casos que você
>>> cita que chegam a 450 metros. Nesses sim a sua técnica de percorrer
>>> várias vezes e calcular uma média é muito mais eficiente E eficaz. O
>>> pessoal que mapeia rodovias (e não vias em grandes cidades, onde o
>>> Bing é suficiente) usa essa técnica justamente por isso.
>>>
>>> Aí entra um detalhe interessante no OSM. Para que os outros saibam que
>>> o que está no mapa foi obtido por essa metodologia, você deve se
>>> preocupar em colocar a tag "source" nos elementos que você mapear. Se
>>> estiver traçando sobre a imagem do Bing, coloque source=Bing (ou não
>>> coloque nada e todos entenderão que foi usando o Bing ou outra fonte
>>> menos confiável). Se estiver coletando tracklogs, coloque
>>> source=survey. Se a fonte for outra (digamos, um mapa de uma
>>> prefeitura), coloque source=[nome da prefeitura]. Essa tag serve tanto
>>> como informação como para detectar plágio (por exemplo, source=Google
>>> é proibido).
>>>
>>> 2013/12/19 ThUnDeRCeL <thundercel em gpsinfo.com.br>:
>>> > Creio que novamente e em outro assunto eu não consegui me fazer
>>> > entender.
>>> >
>>> > Assim vamos a um exemplo pratico com imagem do BING.
>>> >
>>> > Observe em http://www.openstreetmap.org/edit#map=15/-5.5482/-40.7387
>>> >
>>> > A para uma lagoa onde as quadriculas da imagem do BING estão defasadas.
>>> >
>>> > Com isso acredito que você já possa concluir que uma das quadriculas
>>> > adjacentes não está bem georeferenciada.
>>> >
>>> > Essa situação, por si só, já impede a aplicação de qualquer tolerância
>>> > “lateral”, ainda mais de 3m. Nem vou comentar sobre o traçado da
>>> > estrada
>>> > de
>>> > terra existente a NW dessa lagoa e constante no mapa OSM.
>>> >
>>> > Independente disso volto a lembrar que não tem lógica a aplicação de
>>> > tolerância “lateral” de 3 onde, por enquanto, só existe como referencia
>>> > para
>>> > aplicação imagem satélite que você mesmo já citou que contem erros de
>>> > 6m
>>> > ou
>>> > mais. Lembro que encontrei erro de 450m.
>>> >
>>> > Nem nossos GPS automotivos tem essa precisão de 3m e por essa razão que
>>> > nos
>>> > navegadores gps existem tolerâncias de erros laterais da via desenhada
>>> > no
>>> > mapa. No Garmin e no iGO é de 50m, nos demais não sei ainda porque não
>>> > testei, mas está nos meus planos.
>>> >
>>> > Me perdoe, mas para mim essa orientação de 3m é eficiente, mas de
>>> > impraticável cumprimento em nosso território. Por essa razão que citei
>>> > eficiente, mas ineficaz.
>>> >
>>> > Se tem você conseguido cumprir essa recomendação dos 3m parabéns! Eu,
>>> > mesmo
>>> > com a experiência que detenho em desenvolvimento de mapa, com as
>>> > ferramentas
>>> > ora disponíveis, não consigo!
>>> >
>>> >
>>> >
>>> > -----Mensagem Original-----
>>> > From: Fernando Trebien
>>> > Sent: Thursday, December 19, 2013 1:19 PM
>>> > To: Cooperativa de Cartografia Digital Livre
>>> > Subject: Re: [Cocar] Contribuintes para cidades do RJ no OSM
>>> >
>>> > "Existindo esse objetivo diria que o OSM  está perseguindo a
>>> > eficiência, mas de forma ineficaz."
>>> >
>>> > Por que seria ineficaz? Tem sido muito eficaz no que eu tenho feito,
>>> > no que tem sido feito no Brasil e em vários países do mundo (Alemanha,
>>> > Inglaterra, Rússia, e outros próximos desses 3 grandes pólos).
>>> >
>>> > Se você aproximar a imagem do Bing, você consegue ver as faixas
>>> > separando as pistas. Bem, aqui em Porto Alegre e no Rio dá pra ver, em
>>> > outros lugares varia com a qualidade da imagem disponível. Ainda
>>> > assim, se você mapear ao longo do centro da pista, você sabe que pode
>>> > errar dentro de 3m de distância desse centro aproximado, e que não é
>>> > muito bom errar muito mais do que isso. (Já vi mapeamentos manuais
>>> > muito mal feitos, piores que desenho de criança.)
>>> >
>>> > Como ficar medindo ponto a ponto é trabalhoso e tedioso, o que eu faço
>>> > é o seguinte (onde a via não é simplesmente reta): mapeio a curva com
>>> > muito mais pontos que o necessário (seria bem similar a gerar um
>>> > tracklog com um intervalo bem curto - acredito que os seus 7m são
>>> > suficientes pra grande maioria dos casos), daí aplico o simplificador
>>> > (deixo o JOSM decidir pra mim o que cai dentro desse limiar de 3m e
>>> > descartar o resto), faço uns últimos ajustes onde for necessário
>>> > (evitando inserir novos pontos, apenas movendo os que resultaram da
>>> > simplificação), e daí faço o upload pro mapa oficial. Pra vias de
>>> > veículos, isso funciona muito bem. Onde há um pouco de trabalho a ser
>>> > feito é em vias paralelas (ou vias separadas), onde o melhor é, depois
>>> > da simplificação, fazer com que os pontos que o JOSM escolheu fiquem
>>> > alinhados em ambos os lados da via - assim:
>>> > http://wiki.openstreetmap.org/w/images/d/d7/Paralel_aligned.png
>>> >
>>> > Agora, sei que algumas pessoas nem usam esse simplificador, mas se
>>> > acostumaram com um nível de detalhe similar e o produzem naturalmente
>>> > sem pensar muito. Absolutamente ok fazer assim. Usar o simplificador
>>> > pra mim é um "sanity check" pra não usar nem pontos de menos, nem
>>> > demais. Mas enfim, isso não tem nada a ver com a taxa de coleta ao
>>> > produzir um tracklog, que é ao que você se refere com a medida de 7m
>>> > (alguns sistemas não usam a distância e sim um intervalo de tempo
>>> > entre duas coletas consecutivas).
>>> >
>>> > 2013/12/19 ThUnDeRCeL <thundercel em gpsinfo.com.br>:
>>> >> De certa forma compreendi sua explicação, mas continuo em duvida, em
>>> >> especial quando utiliza como referência faixa de pista.
>>> >> Estou aqui tentando identificar como um desenvolvedor identifica na
>>> >> imagem
>>> >> satélite do BING  uma faixa de pista para obter referencia.
>>> >> Me perdoe, mas continuo em duvida quanto a praticidade dessa
>>> >> tolerância
>>> >> de
>>> >> 3m.
>>> >>
>>> >> Pode ser que em futuro, quando tivermos melhor qualidade e precisão
>>> >> das
>>> >> imagens, possamos atender a esse objetivo de tolerância lateral de 3m,
>>> >> mas
>>> >> por enquanto desconheço ferramenta disponível que permita isso.
>>> >>
>>> >> Existindo esse objetivo diria que o OSM  está perseguindo a
>>> >> eficiência,
>>> >> mas
>>> >> de forma ineficaz.
>>> >>
>>> >> Tenho um jargão sobre isso:
>>> >> "Um piloto fazendo excelente pouso (eficiente), mas no aeroporto
>>> >> errado
>>> >> (ineficaz).
>>> >>
>>> >>
>>> >> -----Mensagem Original----- From: Fernando Trebien
>>> >> Sent: Thursday, December 19, 2013 11:36 AM
>>> >>
>>> >> To: Cooperativa de Cartografia Digital Livre
>>> >> Subject: Re: [Cocar] Contribuintes para cidades do RJ no OSM
>>> >>
>>> >> "Continua você se referindo a precisão dos 3m lateral e ainda não me
>>> >> respondeu como extrair essa tolerância."
>>> >>
>>> >> Na verdade, não existe um "método" oficial. Isso é mais um objetivo a
>>> >> ser seguido. No JOSM, você pode calcular distâncias simplesmente
>>> >> iniciando o traçado de uma linha e observando a distância total da
>>> >> linha na barra de status (na parte de baixo da janela). Mas isso
>>> >> geralmente não é necessário, basta lembrar que uma faixa costuma ter
>>> >> 3m de largura, então você deve se preocupar que o seu traçado não caia
>>> >> a mais de 1 faixa de distância da faixa central. Fora isso, essa
>>> >> medida serve mais para justificar a possibilidade de simplificar a via
>>> >> usando o JOSM.
>>> >>
>>> >> Digamos que alguém se preocupou em detalhar muito uma curva e usou
>>> >> pontos demais. Por causa desse princípio, qualquer outra pessoa
>>> >> poderia simplificar essa curva usando o simplificador do JOSM (ou
>>> >> qualquer outro método), mas não além desse limite de 3m em relação ao
>>> >> que já estava mapeado (o que significaria tirar detalhe relevante e,
>>> >> dependendo de quanto foi retirado, poderia em alguns casos extremos
>>> >> até ser visto como uma espécie de "vandalismo").
>>> >>
>>> >>
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Fernando Trebien
>>> > +55 (51) 9962-5409
>>> >
>>> > "The speed of computer chips doubles every 18 months." (Moore's law)
>>> > "The speed of software halves every 18 months." (Gates' law)
>>>
>>>
>>>
>>> --
>>> Fernando Trebien
>>> +55 (51) 9962-5409
>>>
>>> "The speed of computer chips doubles every 18 months." (Moore's law)
>>> "The speed of software halves every 18 months." (Gates' law)
>>
>>
>>
>>
>> --
>> Fernando Trebien
>> +55 (51) 9962-5409
>>
>> "The speed of computer chips doubles every 18 months." (Moore's law)
>> "The speed of software halves every 18 months." (Gates' law)
>
>
>
> --
> Fernando Trebien
> +55 (51) 9962-5409
>
> "The speed of computer chips doubles every 18 months." (Moore's law)
> "The speed of software halves every 18 months." (Gates' law)

-- 
Fernando Trebien
+55 (51) 9962-5409

"The speed of computer chips doubles every 18 months." (Moore's law)
"The speed of software halves every 18 months." (Gates' law)