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 <[email protected]>: > 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 <[email protected]>: >> 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 <[email protected]> >>> >>> 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 <[email protected]>: >>> > 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 <[email protected]>: >>> >> 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) _______________________________________________ Talk-br mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-br
