Re: [Talk-br] Discussões Improdutivas
Que algumas discussões andam improdutivas, isso é verdade. Agora que não há necessidade de questionamento, discordo. Tudo que existe no OSM deve ser verificável por outros. O questionamento, então, é válido caso a pessoa cometa erros. O que temos que cuidar é para questionar cordialmente, e a pessoa não pode se apegar demais ao seu trabalho. É difícil porque temos a tendência de ver o nosso trabalho como nossa "propriedade". Discussões devem ser primeiro diretas, e escalonar para a comunidade apenas caso não se chegue a um consenso. Daí a comunidade intervém e gera precedente, que ajuda a resolver outras discussões futuras. Se um mesmo problema é recorrente, a comunidade então tem que agir para evitá-lo. Percebo que tem sido assim nas outras comunidades há quase 1 década já. Haverá discussões (e naturalmente desentendimentos) até que se chegue a um consenso sobre todos os parâmetros do OSM. No Brasil, o projeto está ainda engatinhando, então esse tipo de coisa é esperada. 2015-07-04 18:55 GMT-03:00 Blademir Andrade de Lima : > Amigos Mapeadores, boa noite! > > Perceberam o quanto as discussões ultimamente estão improdutivas, e não > estão contribuindo em nada nossa comunidade? > > Não entrarei em méritos sobre quem fez isso ou aquilo, se fez errado ou não. > > Mas estamos tendo discussões sobre bobagens e coisas mínimas. > > Considero que toda pessoa que mapea age de boa fé, sem necessidade de > questionamento, exceto em casos explícitos de vandalismo. > > Desejo a todos um excelente trabalho! > > Atenciosamente, > Blademir Andrade - BladeTC > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Necessidade de intermediação
Eu não trabalho com isso mas já estudei o assunto a fundo. Mudei de área quando vi que essa já estava muito avançada. O que geralmente se faz é calcular o grafo dual do mapa geográfico: linhas viram nós e pontos de conexão entre elas viram linhas entre esses nós. Uma restrição de conversão se torna a exclusão de uma ou mais das linhas resultantes de um cruzamento. Os nós contém os pesos (tempo, ou velocidade e distância) de trafegar pela linha. O algoritmo então simplesmente explora essa estrutura de dados até chegar no destino. Conforme explora, vai somando os tempos. Quando encontrar a sequência que minimiza o tempo total, termina. Como o grafo geralmente é imenso, usam-se heurísticas para desconsiderar alguns caminhos. É aí que os algoritmos começam a dar resultados diferentes para os mesmos dados. Eu dei uma olhada por altos no projeto do mkgmap pra ver se poderia ajudar, mas achei confusa a sua organização. O projeto não tem um líder e "evolui" com contribuições eventuais. Também acho seu escopo limitado aos usuários de Garmin (eu não tenho um Garmin), e o meu interesse são sistemas open source que cheguem ao grande público. O OSRM é o contrário de tudo isso: algoritmo estado-da-arte, código muito bem escrito, comunidade organizada e responsiva, e utilizável pelo mundo todo sem precisar de ferramentas pagas. As dificuldades relatadas até aqui me fazem supor que o Mapfactor Navigator usa um algoritmo similar ao Garmin. É grátis e tem pra celular. E a comunidade do Mapfactor, embora pequena, me parece maior e mais organizada que a do mkgmap. Talvez o pessoal queira dar uma olhada no aplicativo. On 5 Jul 2015 11:17, "Aun Johnsen" wrote: > Fernando, > > Se eu entendo esse certa o graf de roteamento, alias o produto do > algoritmo, não ha informação geográfico mas tem linhas que representa > tempo e distancia entre nos que representando locações fisico, um no > pode ser um ponto onde 2 vias cruzam, mas pode também ser a rotatório > completo, ou ate um trevo complicado como um ponto so. Um ponto pode > ser um referencia da rota (vira a esquerda no BR-101), ou um ponto do > penalidade (espera 2 segundos no semáforo). Esses linhas e pontos e > abstratos, e não direitamente retirado do mapa física. > > Se voce trabalho com isso, talvez voce posso ajudar identificar os > objetos que pode/deve dar penalidade de roteamento? > > On 7/5/15, Fernando Trebien wrote: > > Aí você que entra na minha área de expertise como se soubesse mais. Sou > > mestre em computação, li várias versões desses algoritmos. > > > > O nó a que me refiro é o do grafo de roteamento. Não é o nó do mapa (com > > coordenadas e tal). O nó do grafo de roteamento sequer tem coordenadas, > > possui apenas propriedades abstratas como o tempo para atravessar uma > linha > > de uma ponta à outra, e a referência a essa linha daí sim no mapa > > geográfico. > > On 5 Jul 2015 05:44, "Marcio - Thundercel" > > wrote: > > > >> Uma coisa é o esperado de acordo com a teoria e outra o observado na > >> pratica em exaustivos testes. > >> > >> A criação do nó em si não interfere, a princípio, com o algoritmo. > >>> Será um nó a mais a ser visitado enquanto o grafo é explorado pelo > >>> algoritmo de roteamento. > >>> > >> > >> O algoritmo, dentre outros, trata os nós e é por eles que ele traça a > >> rota. > >> > >> Já fizemos inúmeros testes de roteamento e identificamos que o > >> roteamento, > >> entre duas vias iguais, ele opta pela que tem menos nós. > >> > >> Faça o teste chegando em um nó onde se abrem duas vias e que se fecham > lá > >> na frente, como um losango. > >> Divida um segmento de reta de uma das vias inserindo um nó nela. > >> Identificará que o roteamento se dá pela via que não tem o nó inserido. > >> Foi assim que nos testes constatamos a influência de partições de via em > >> um roteamento. > >> > >> -Mensagem Original- From: Fernando Trebien > >> Sent: Sunday, July 5, 2015 4:52 AM > >> To: OpenStreetMap no Brasil > >> Subject: Re: [Talk-br] Necessidade de intermediação > >> > >> 2015-07-05 1:40 GMT-03:00 Marcio - Thundercel > >> : > >> > >>> Por outro lado lembro que classificação de vias e de velocidades > >>> interferem > >>> no roteamento e, infelizmente, não dominamos ainda o algoritmo garmin. > O > >>> que > >>> sabemos sobre ele advém de exaustivos testes realizados. > >>> Não estamos debatendo tempo e sim roteamento e tudo que interfere nele. > >>> Como bem deve saber você o roteamento leva em consideração, além de > >>> outros, > >>> a quantidade de nós empregados para unir os segmentos de reta na > >>> retratação > >>> da via. > >>> Ao se reduzir a velocidade de um trecho de via o editor é obrigado a > >>> dividir > >>> a via de forma a poder no trecho dividido estabelecer a velocidade. > Isso > >>> por > >>> si só já afeta o calculo de rota por aquele trecho. > >>> > >> > >> Afeta, mas muito pouco, pelo menos na minha compreensão de algoritmos > >> de roteamento. > >> > >> O que acontece é que ele cria um novo nó
Re: [Talk-br] Necessidade de intermediação
2015-07-05 4:57 GMT-03:00 Marcio - Thundercel : > A partir do momento que um mapeador declara em sua edição GPS;survey > acredito nele e nunca pedirei comprovação do que ele editou. Quem ganha é o > OSM porquemais um colaborador, voluntariamente, atuou no mapa. Só porque é voluntário não quer dizer que qualquer coisa que faça deve ser aceita. Como você disse, "assim age você, mas não pretendo agir assim". >> Da mesma forma, se sua informação viesse de uma prefeitura, você >> colocaria a prefeitura na etiqueta source. Isso informaria os outros >> mapeadores onde procurar a informação para confirmar: >> - sua veracidade; e >> - sua correção > > > Dados obtidos em prefeituras, IBGE, Bing, mapbox, não pode ser comparado com > survey. Em diversos aspectos podem sim. >> Esse é o mesmo princípio pelo qual funciona a Wikipédia: nenhuma >> informação fica lá sem que uma fonte seja citada para verificação. Se >> a fonte não for fornecida, a informação pode ser removida por falta de >> neutralidade. O OSM é a Wikipédia dos mapas - inclusive é assim que se >> apresenta aos novos usuários. Tudo deve ser verificável, não somente >> sob o ponto de vista da idoneidade, mas também do ponto de vista da >> correção. > > > Não tem relação com survey. Tem tudo a ver com survey. O equivalente para Wikipédia é uma pessoa colocar nela uma informação que "simplesmente conhece", que "viu por aí", mas que não tem fonte. Isso tende a ser removido depois de um tempo, quando finalmente os olhos de um "fiscal" passam pela informação. Assim como no OSM, faltam fiscais na Wikipédia pra quantidade de dados nela colocados. > Entendo. Poderia nos copiar a mensagem que ele lhe enviou, mesmo que > seja uma declaração dizendo "tá igual à [fonte X]"? Acho que basta. > > Não. > Minha palavra nesse caso basta. Se você tem a informação solicitada e não quer compartilhar, começo a dar mais razão para a desconfiança do Aun. Talvez você não tenha a informação e quer apenas que acreditemos. As imagens que você apresentou a ele são de uma fonte que não conhecemos, e queremos saber se é lícita (agora me juntei ao coro, quero saber também). É um questionamento válido e importante. Você pode ter feito 4000 contribuições válidas no passado, nada impede que esta seja inválida. Nada impede que a minha próxima contribuição seja inválida também. Às vezes pode ser inválida sem que a própria pessoa perceba que foi inválida. Pode ser inclusive ilícita sem a pessoa perceber. E se pode, pode acometer os experientes também. Você leva isso para o lado da moral (frequentemente), mas eu tenho uma abordagem unicamente pragmática: se tem e é fácil mostrar, mostre, e está solucionado. Fim de papo. Se é fácil mostrar e não mostra, é porque provavelmente há algo a ser escondido. Seria tão fácil dar um Forward nesse e-mail do residente, e no entanto você prefere estender a discussão. Além disso, tracklogs são arquivos pequenos, não seria difícil guardá-los num diretório no seu computador, no Dropbox, ou em qualquer outro meio. Eu tenho praticamente todos os meus tracklogs guardados desde 2012, são centenas. >> Daí o que eu faria é acrescentar uma etiqueta "note" na linha contendo >> o link para a mensagem dele que você encaminhou pra cá. Dessa forma, >> outros mapeadores podem verificar a informação. Note que eu colocaria >> isso em "note" (um comentário informal) e não em "source" (a fonte >> usada para verificar com certeza os dados). É uma diferença sutil, mas >> desse jeito mapeadores locais podem duvidar da correção da informação >> (e têm esse direito) e confirmá-la eles mesmos mais adiante. > > Assim age voce, mas não pretendo agir assim. Gostaria de saber por que foi uma sugestão ruim. Teria sido mais "educado" da sua parte propor colocar essa informação em outra etiqueta. Se a falta dessa informação gera dúvidas, obviamente é necessária no mapa. A etiqueta "note" existe para esclarecer dúvidas em elementos disputados. Ao dizer "não pretendo agir assim" após "minha palavra nesse caso basta", você se coloca em uma posição de superioridade. Ninguém aqui é superior a ninguém. Se quiser exercer essa postura, recomendo que procure outra comunidade que a aceite melhor. Jamais a aceitarei. Não é à toa que minha assinatura em todos os e-mails é "Nullius in verba" - lema da Sociedade Real de Londres, que significa "[não acredite cegamente] nas palavras de ninguém". Confiar cegamente em alguém é colocar-se sob o poder dessa pessoa. As consequẽncias normalmente são ruins, às vezes catastróficas, a história está cheia de exemplos. Não confio cegamente nem em mim mesmo, e penso que o contrário seria prepotente e arrogante. Outra saída para essa situação toda é aceitar que o que foi feito por você é indefensável e portanto é mais seguro que seja revertido, pelo bem da comunidade. Alguém com melhores condições de demonstrar a licitude do método vai corrigir quando chegar a hora. -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba."
Re: [Talk-br] Necessidade de intermediação
Fernando, Se eu entendo esse certa o graf de roteamento, alias o produto do algoritmo, não ha informação geográfico mas tem linhas que representa tempo e distancia entre nos que representando locações fisico, um no pode ser um ponto onde 2 vias cruzam, mas pode também ser a rotatório completo, ou ate um trevo complicado como um ponto so. Um ponto pode ser um referencia da rota (vira a esquerda no BR-101), ou um ponto do penalidade (espera 2 segundos no semáforo). Esses linhas e pontos e abstratos, e não direitamente retirado do mapa física. Se voce trabalho com isso, talvez voce posso ajudar identificar os objetos que pode/deve dar penalidade de roteamento? On 7/5/15, Fernando Trebien wrote: > Aí você que entra na minha área de expertise como se soubesse mais. Sou > mestre em computação, li várias versões desses algoritmos. > > O nó a que me refiro é o do grafo de roteamento. Não é o nó do mapa (com > coordenadas e tal). O nó do grafo de roteamento sequer tem coordenadas, > possui apenas propriedades abstratas como o tempo para atravessar uma linha > de uma ponta à outra, e a referência a essa linha daí sim no mapa > geográfico. > On 5 Jul 2015 05:44, "Marcio - Thundercel" > wrote: > >> Uma coisa é o esperado de acordo com a teoria e outra o observado na >> pratica em exaustivos testes. >> >> A criação do nó em si não interfere, a princípio, com o algoritmo. >>> Será um nó a mais a ser visitado enquanto o grafo é explorado pelo >>> algoritmo de roteamento. >>> >> >> O algoritmo, dentre outros, trata os nós e é por eles que ele traça a >> rota. >> >> Já fizemos inúmeros testes de roteamento e identificamos que o >> roteamento, >> entre duas vias iguais, ele opta pela que tem menos nós. >> >> Faça o teste chegando em um nó onde se abrem duas vias e que se fecham lá >> na frente, como um losango. >> Divida um segmento de reta de uma das vias inserindo um nó nela. >> Identificará que o roteamento se dá pela via que não tem o nó inserido. >> Foi assim que nos testes constatamos a influência de partições de via em >> um roteamento. >> >> -Mensagem Original- From: Fernando Trebien >> Sent: Sunday, July 5, 2015 4:52 AM >> To: OpenStreetMap no Brasil >> Subject: Re: [Talk-br] Necessidade de intermediação >> >> 2015-07-05 1:40 GMT-03:00 Marcio - Thundercel >> : >> >>> Por outro lado lembro que classificação de vias e de velocidades >>> interferem >>> no roteamento e, infelizmente, não dominamos ainda o algoritmo garmin. O >>> que >>> sabemos sobre ele advém de exaustivos testes realizados. >>> Não estamos debatendo tempo e sim roteamento e tudo que interfere nele. >>> Como bem deve saber você o roteamento leva em consideração, além de >>> outros, >>> a quantidade de nós empregados para unir os segmentos de reta na >>> retratação >>> da via. >>> Ao se reduzir a velocidade de um trecho de via o editor é obrigado a >>> dividir >>> a via de forma a poder no trecho dividido estabelecer a velocidade. Isso >>> por >>> si só já afeta o calculo de rota por aquele trecho. >>> >> >> Afeta, mas muito pouco, pelo menos na minha compreensão de algoritmos >> de roteamento. >> >> O que acontece é que ele cria um novo nó no grafo de roteamento para >> representar o trecho. O nó contem o tempo total para percorrer o >> trecho, calculado dividindo distância por velocidade. (há variações em >> que o nó contem ambas velocidade e distância e o cálculo do tempo é >> feito durante o processamento, mas elas são matematicamente >> equivalentes) >> >> A criação do nó em si não interfere, a princípio, com o algoritmo. >> Será um nó a mais a ser visitado enquanto o grafo é explorado pelo >> algoritmo de roteamento. >> >> O que acontece é que algoritmos diferentes usam heurísticas >> diferentes. Algumas dessas heurísticas decidem "descartar" alguns nós >> que eles "acham" que têm pouca chance de conduzir à melhor rota. >> "Heurística" é um método matematicamente impreciso para chegar a uma >> solução sub-ótima mais rapidamente. Se é impreciso, há heurísticas >> melhores e piores. Uma heurística comum é visitar primeiro os nós >> relativos às vias de maior classificação. Nesse caso, como a >> classificação não foi alterada, o nó seria visitado mesmo tendo uma >> velocidade mais baixa. Mas o Garmin pode usar alguma outra heurística >> que eu desconheço. >> >> Outro insight: explorar o gráfico requer somar esses tempos, trecho >> por trecho. São milhares de operação de soma. Se o programa não for >> bem construído, ele pode acumular erros numéricos ao somar milhares de >> números. O OSRM me parece particularmente sensível a esses erros. O >> Garmin geralmente opera num hardware limitado e talvez também seja >> sensível (tratar desses erros numéricos requer usar mais memória). >> >> Mais um insight: classificação interfere com esses algoritmos "mais >> simples" que usam "heurísticas". A classificação das vias não >> interfere em nada com o algoritmo A* (a-estrela) puro, nem com o >> algoritmo do OSRM. Por isso, classificações não devem
Re: [Talk-br] Necessidade de intermediação
Aí você que entra na minha área de expertise como se soubesse mais. Sou mestre em computação, li várias versões desses algoritmos. O nó a que me refiro é o do grafo de roteamento. Não é o nó do mapa (com coordenadas e tal). O nó do grafo de roteamento sequer tem coordenadas, possui apenas propriedades abstratas como o tempo para atravessar uma linha de uma ponta à outra, e a referência a essa linha daí sim no mapa geográfico. On 5 Jul 2015 05:44, "Marcio - Thundercel" wrote: > Uma coisa é o esperado de acordo com a teoria e outra o observado na > pratica em exaustivos testes. > > A criação do nó em si não interfere, a princípio, com o algoritmo. >> Será um nó a mais a ser visitado enquanto o grafo é explorado pelo >> algoritmo de roteamento. >> > > O algoritmo, dentre outros, trata os nós e é por eles que ele traça a rota. > > Já fizemos inúmeros testes de roteamento e identificamos que o roteamento, > entre duas vias iguais, ele opta pela que tem menos nós. > > Faça o teste chegando em um nó onde se abrem duas vias e que se fecham lá > na frente, como um losango. > Divida um segmento de reta de uma das vias inserindo um nó nela. > Identificará que o roteamento se dá pela via que não tem o nó inserido. > Foi assim que nos testes constatamos a influência de partições de via em > um roteamento. > > -Mensagem Original- From: Fernando Trebien > Sent: Sunday, July 5, 2015 4:52 AM > To: OpenStreetMap no Brasil > Subject: Re: [Talk-br] Necessidade de intermediação > > 2015-07-05 1:40 GMT-03:00 Marcio - Thundercel : > >> Por outro lado lembro que classificação de vias e de velocidades >> interferem >> no roteamento e, infelizmente, não dominamos ainda o algoritmo garmin. O >> que >> sabemos sobre ele advém de exaustivos testes realizados. >> Não estamos debatendo tempo e sim roteamento e tudo que interfere nele. >> Como bem deve saber você o roteamento leva em consideração, além de >> outros, >> a quantidade de nós empregados para unir os segmentos de reta na >> retratação >> da via. >> Ao se reduzir a velocidade de um trecho de via o editor é obrigado a >> dividir >> a via de forma a poder no trecho dividido estabelecer a velocidade. Isso >> por >> si só já afeta o calculo de rota por aquele trecho. >> > > Afeta, mas muito pouco, pelo menos na minha compreensão de algoritmos > de roteamento. > > O que acontece é que ele cria um novo nó no grafo de roteamento para > representar o trecho. O nó contem o tempo total para percorrer o > trecho, calculado dividindo distância por velocidade. (há variações em > que o nó contem ambas velocidade e distância e o cálculo do tempo é > feito durante o processamento, mas elas são matematicamente > equivalentes) > > A criação do nó em si não interfere, a princípio, com o algoritmo. > Será um nó a mais a ser visitado enquanto o grafo é explorado pelo > algoritmo de roteamento. > > O que acontece é que algoritmos diferentes usam heurísticas > diferentes. Algumas dessas heurísticas decidem "descartar" alguns nós > que eles "acham" que têm pouca chance de conduzir à melhor rota. > "Heurística" é um método matematicamente impreciso para chegar a uma > solução sub-ótima mais rapidamente. Se é impreciso, há heurísticas > melhores e piores. Uma heurística comum é visitar primeiro os nós > relativos às vias de maior classificação. Nesse caso, como a > classificação não foi alterada, o nó seria visitado mesmo tendo uma > velocidade mais baixa. Mas o Garmin pode usar alguma outra heurística > que eu desconheço. > > Outro insight: explorar o gráfico requer somar esses tempos, trecho > por trecho. São milhares de operação de soma. Se o programa não for > bem construído, ele pode acumular erros numéricos ao somar milhares de > números. O OSRM me parece particularmente sensível a esses erros. O > Garmin geralmente opera num hardware limitado e talvez também seja > sensível (tratar desses erros numéricos requer usar mais memória). > > Mais um insight: classificação interfere com esses algoritmos "mais > simples" que usam "heurísticas". A classificação das vias não > interfere em nada com o algoritmo A* (a-estrela) puro, nem com o > algoritmo do OSRM. Por isso, classificações não devem ser alteradas > com vistas ao roteamento. No entanto, um bom método de classificação > serve bem a praticamente qualquer algoritmo de roteamento, não por ser > o objetivo da classificação, mas por ser efeito colateral dela. > > Se, numa rota com vários quilômetros, a escolha de uma alternativa ou > outra depender de um trecho tão curto quanto o mencionado, é bem > provável que alguma dessas características esteja inteferindo no > resultado. Mas os mapeadores do OSM não podem fazer nada, e talvez nem > os desenvolvedores da aplicação sem ter que reescrevê-la por completo > para resolver algum problema mais profundo. > > O que os roteadores prometem não é encontrar a melhor rota, mas uma > rota sub-ótima. Quanto mais longa a distância, maior o efeito desses > dois fatores (erro numérico e qualidade da heu
Re: [Talk-br] Necessidade de intermediação
Ira dizer também, se fosse em casa quando voce visitando seu amigo no Vila Velha eu ira convidar voce tomar um gelado para conhecer pessoalmente, eu acho que muitos de nossos discussões pode ser diferente se conhecemos pessoalmente, infelizmente semana que vem quando voce vai visitar seu amigo ainda to no sul do Argentina e so vai chegar em casa fim do mês. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Necessidade de intermediação
On 7/5/15, Marcio - Thundercel wrote: > -Mensagem Original- > From: Aun Johnsen > Sent: Sunday, July 5, 2015 12:11 AM > >> So para dar um dica que muito vezes passa no meu trabalho: "se não ha >> evidencia, não existe” > > Não sei se é questão de idioma, mas "evidencie" no inglês é prova que por > sua vez não é "evidência no idioma português. > 'Evidência', em português, significa aquilo que é claro, inequívoco, muito > visível, incontestável. > Apresentei três "evidências", não "evidences", e mesmo assim decidiu você > se valer de sua “evidência” deduzindo o que viu no Strava. O pior, editou se > valendo dele. > Obviamente voce entendi o que tentei dizer com esse frase, não entendo nada do seu resposta, voce tentando corrigir meu erros em falta do assentos, ou voce tentando dizer que uso palavras erradas ou voce tentando dizer que esse frase não valendo aqui? >> To vendo que dados do este fonte que voce citando e mais certa que os >> fontes que eu mostrando, voce comentou que um dos links que eu inseri não >> existe, mas segundo Strava ha muito fluxo nesse link. como esse e meia do >> um trevo onde ha obras eu não posso creditar esse e tao > muitos >> pedestres. Obviamente os dados do Strava não tem valor, porque seu fonte, >> que voce não pode compartilhar, sabe melhor. > > Um dos links não. Você inclui os seguintes trechos que segundo informação > por mim recebida não existem: > - https://www.openstreetmap.org/way/358538171 > - https://www.openstreetmap.org/way/358538169 > - https://www.openstreetmap.org/way/358538166 > > Inclusive esse terceiro já está errado porque é um trecho de sentido duplo > conectando um trecho de sentido único. > Esqueci um tag do oneway, e isso prova que eu tava errado totalmente? Ou que não dupliquei a Avenida Nações Unidos e um prova que eu não mapeando bem? Esses 3 links voce dizendo que não existe fui entrado por (evidencia/prova) Strava, que mostrando ha fluxo grande nesses locais, os 2 pequenos que dar retorno no BR-319 pode ser faixas de pedestre, mas acho esse menus provável que existência do link. Se eles são faixas de pedestre, entra-los como esse, e meu entendimento vai ser diferente, no caso do o link dentro trevo, sim pode ser muito coisas, mas cada outro esplicacao e menus provável que o link que entrei. Se voce me mostrando (evidencia/prova) que não existe, por exemplo foto atual no local, email do morador que passa o trevo frequente, ou outro coisas que pode confiar eu vou mudar opinião. >> Eu tenho mesmo motivos para desconfiar em WAZE e HERE como TS > > Desconfiar do TS também desconfio até porque conheço os inúmeros erros dele, > mas desconfiar da minha edição pautada em informações de residente, do Waze > e Here, quando esses apontam para a mesma situação, é outra estória. Prefere > você desconfiar de todos esses e incluir acessos pautados em sua dedução do > que vê no Strava. Interessante essa ação. > TS, Waze e Here e mesmo disconfiavel, porque e projetos crowdsource que pode empregar as mesmas faltas, que não ha licencia em conforma com nosso, alem outros motivos. Confia em Strava como um fonte do dados crua, junto com OSM-GPX, Mapillary, entre outros. Todos esses fontes tem licencias em conforma com a licencia do OSM, ate eles tem referencia do OSM com um confirmação que eles pode ser utilizado. Mas nenhuma deles tem mais valor que conhecimento no local admito, pelo que saiba voce não fui nesse trevo (eu pode ser errado) e seu informação ainda e do terceiro. Seu fonte pode ser bom ou pode ter faltas, eu não sei, e sem voce espera resposta do seu fonte voce me dizendo que o que eu entrei por provas Strava não existe porque seu fonte não mencionou eles 3 meses atras. >> Bom voce conheço esse trecho pelo seu amigo morando em Vila Velha, que >> voce visitando regularmente, so em caso voce tem duvida, eu moro no >> Guarapari e viaje muito, e por acaso esse trecho e entre meu casa e o >> aeroporto. > > Sim e você sabe disso porque recentemente editei uma Rua em Vila velha que > estava com nomenclatura incorreta e como fiscaliza todas as edições também > no changeset dessa edição comentou e tive a oportunidade de ali informar que > trafeguei pela rua no fim de semana e identifiquei o erro. > >> Se 150 metros de 40km/h vai fazer muito diferencia pelo tempo? Acho que >> não. Se o posto e do PM ou PRE e muito fácil verificar, como esse trecho >> em ambos sentidos e documentado pelo Mapillary > > Lembro ao nobre amigo que não são 150m e sim 500m a sinalização vertical > para redução de velocidade para passagem a frente de posto policial > rodoviário. Grande coisa, o diferencia em tempo se mudar 150m para 500m vai ser ~30s, eu so peguei o numero 150 do cabeça, se lembro certo esse trecho e mapeado com velocide reduzido, e se esquesi mapear esse certo vai corrigir proximo vez que mapeando no local. Eu pode também entra o tag traffic_calming=chicane, mas esse e um estrutura temporário que ser tirado por os policiais quando ha fluxo muito alto no
Re: [Talk-br] Necessidade de intermediação
Uma coisa é o esperado de acordo com a teoria e outra o observado na pratica em exaustivos testes. A criação do nó em si não interfere, a princípio, com o algoritmo. Será um nó a mais a ser visitado enquanto o grafo é explorado pelo algoritmo de roteamento. O algoritmo, dentre outros, trata os nós e é por eles que ele traça a rota. Já fizemos inúmeros testes de roteamento e identificamos que o roteamento, entre duas vias iguais, ele opta pela que tem menos nós. Faça o teste chegando em um nó onde se abrem duas vias e que se fecham lá na frente, como um losango. Divida um segmento de reta de uma das vias inserindo um nó nela. Identificará que o roteamento se dá pela via que não tem o nó inserido. Foi assim que nos testes constatamos a influência de partições de via em um roteamento. -Mensagem Original- From: Fernando Trebien Sent: Sunday, July 5, 2015 4:52 AM To: OpenStreetMap no Brasil Subject: Re: [Talk-br] Necessidade de intermediação 2015-07-05 1:40 GMT-03:00 Marcio - Thundercel : Por outro lado lembro que classificação de vias e de velocidades interferem no roteamento e, infelizmente, não dominamos ainda o algoritmo garmin. O que sabemos sobre ele advém de exaustivos testes realizados. Não estamos debatendo tempo e sim roteamento e tudo que interfere nele. Como bem deve saber você o roteamento leva em consideração, além de outros, a quantidade de nós empregados para unir os segmentos de reta na retratação da via. Ao se reduzir a velocidade de um trecho de via o editor é obrigado a dividir a via de forma a poder no trecho dividido estabelecer a velocidade. Isso por si só já afeta o calculo de rota por aquele trecho. Afeta, mas muito pouco, pelo menos na minha compreensão de algoritmos de roteamento. O que acontece é que ele cria um novo nó no grafo de roteamento para representar o trecho. O nó contem o tempo total para percorrer o trecho, calculado dividindo distância por velocidade. (há variações em que o nó contem ambas velocidade e distância e o cálculo do tempo é feito durante o processamento, mas elas são matematicamente equivalentes) A criação do nó em si não interfere, a princípio, com o algoritmo. Será um nó a mais a ser visitado enquanto o grafo é explorado pelo algoritmo de roteamento. O que acontece é que algoritmos diferentes usam heurísticas diferentes. Algumas dessas heurísticas decidem "descartar" alguns nós que eles "acham" que têm pouca chance de conduzir à melhor rota. "Heurística" é um método matematicamente impreciso para chegar a uma solução sub-ótima mais rapidamente. Se é impreciso, há heurísticas melhores e piores. Uma heurística comum é visitar primeiro os nós relativos às vias de maior classificação. Nesse caso, como a classificação não foi alterada, o nó seria visitado mesmo tendo uma velocidade mais baixa. Mas o Garmin pode usar alguma outra heurística que eu desconheço. Outro insight: explorar o gráfico requer somar esses tempos, trecho por trecho. São milhares de operação de soma. Se o programa não for bem construído, ele pode acumular erros numéricos ao somar milhares de números. O OSRM me parece particularmente sensível a esses erros. O Garmin geralmente opera num hardware limitado e talvez também seja sensível (tratar desses erros numéricos requer usar mais memória). Mais um insight: classificação interfere com esses algoritmos "mais simples" que usam "heurísticas". A classificação das vias não interfere em nada com o algoritmo A* (a-estrela) puro, nem com o algoritmo do OSRM. Por isso, classificações não devem ser alteradas com vistas ao roteamento. No entanto, um bom método de classificação serve bem a praticamente qualquer algoritmo de roteamento, não por ser o objetivo da classificação, mas por ser efeito colateral dela. Se, numa rota com vários quilômetros, a escolha de uma alternativa ou outra depender de um trecho tão curto quanto o mencionado, é bem provável que alguma dessas características esteja inteferindo no resultado. Mas os mapeadores do OSM não podem fazer nada, e talvez nem os desenvolvedores da aplicação sem ter que reescrevê-la por completo para resolver algum problema mais profundo. O que os roteadores prometem não é encontrar a melhor rota, mas uma rota sub-ótima. Quanto mais longa a distância, maior o efeito desses dois fatores (erro numérico e qualidade da heurística). Até mesmo o Waze às vezes faz bobagem na tentativa de encontrar a melhor rota. -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Necessidade de intermediação
From: Fernando Trebien Sent: Sunday, July 5, 2015 4:31 AM Todas não. Apenas as potencialmente polêmicas. A comunidade pode sim julgar e discordar. Não tenho duvida que a comunidade pode julgar e discordar de alguma edição, entretanto essa deve discordar pautada em alguma regra no OSM que foi descumprida pelo editor e não reverter os dados porque o editor deixou de apresentar tracklog de sua edição. Dependendo do que chamas de "análise", talvez não. Elas são, no máximo, fontes de "inspiração" para que se priorize sua verificação através de fontes lícitas. As fontes lícitas são sempre empregadas, mas nada impede que o editor consulte como andam as fontes ilícitas. Quando questionado, precisa. Espera-se isso de todos. Me exclua desse todos, Se isso for padrão OSM paro aqui minhas edições e vou desfrutar da minha aposentadoria e finalizar o projeto Cocar. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Necessidade de intermediação
From: Fernando Trebien Sent: Sunday, July 5, 2015 3:47 AM Sem problemas. Caso você não tenha mais a cópia da trilha, seria possível o residente contribuir essa trilha para o OSM pelo mecanismo padrão de submissão das trilhas? Acho que isso sana todas as dúvidas. Me perdoe, mas a partir do momento que minha edição foi questionada e minha palavra foi posta em duvida, não solicitarei e tampouco apresentarei qualquer tracklog do local. As provas de que fiz o correto virão com as atualizações das imagens satélites. Se desejarem voltar o desenho para o estampado no Bing desatualizado, sem problema. Já me desgastei muito com essa situação e perdi muito tempo justificando uma edição. O mais interessante é que ficam se prendendo a detalhes e deixam de corrigir a ponte sobre o Rio Madeita ( BR-319 ) que se encontrava com etiqueta em construção e esqueceram de verificar que essa ponte já consta das "fontes ilícitas" e que foi inaugurada em 15/09/2014 conforme noticiado em http://g1.globo.com/ro/rondonia/noticia/2014/09/inaugurada-ponte-que-liga-rondonia-ao-amazonas-em-porto-velho.html Corrigido o erro em http://www.openstreetmap.org/way/243298056 e só espero que eu não seja novamente questionado por ter editado e colocado a ponte em operação. Sei que dá mais trabalho, mas para não ter que arquivar, e não ter que se preocupar com as justificativas posteriores, poderia submeter as trilhas ao OSM. Não precisa ser todas, só aquelas que podem esclarecer polêmicas. Acredito que poucas das trilhas coletadas divergem da imagem de satélite atual (as coisas mudam, mas geralmente só perto das vias principais), então seriam poucas trilhas a submeter ao OSM. Se observou atentamente já existe trilha de trecho desse novo trevo arquivada no OSM por alguém, mas de qualquer forma não é do meu feitio ficar arquivando dados para comprovar minha palavra. Poso errar sim, mas erro porque edito. Seria facil passar de editor para fiscal e talvez essa seja a melhor situação no OSM Brasil. Também poderia não submeter, apenas guardá-las, e compartilhá-las em caso de questionamento. Guardo o que me interessa para futuras referencias. Tenho auxiliado ao OSM por prazer e não tenciono começar a guardar provas das minhas edições porque deixa de ser prazer e passa a ser obrigação. As etiquetas dos changesets são, a princípio, apenas informativas. O objetivo da informação é permitir que outros mapeadores verifiquem a informação que foi editada. Se você declara que fez survey, outro mapeador pode lhe solicitar o tracklog ou fotos ou qualquer informação que você tenha levantado, ou pelo menos entender que precisa confirmar a informação em campo (ou seja, entender que ela não veio da imagem de satélite). A partir do momento que um mapeador declara em sua edição GPS;survey acredito nele e nunca pedirei comprovação do que ele editou. Quem ganha é o OSM porquemais um colaborador, voluntariamente, atuou no mapa. Da mesma forma, se sua informação viesse de uma prefeitura, você colocaria a prefeitura na etiqueta source. Isso informaria os outros mapeadores onde procurar a informação para confirmar: - sua veracidade; e - sua correção Dados obtidos em prefeituras, IBGE, Bing, mapbox, não pode ser comparado com survey. Note que nem sempre questionar significa não acreditar em você. Ás vezes o outro mapeador só quer saber se você transcreveu a informação corretamente. Como disse, todos somos passíveis de erro, então o questionamento é válido. Creio que voce não atingiu minha ponderação. Não sou contra questionamento, sou contra questionamento seguido de exp0licação e replicado com solicitação de prova em se tratando de GPS;survey. Esse é o mesmo princípio pelo qual funciona a Wikipédia: nenhuma informação fica lá sem que uma fonte seja citada para verificação. Se a fonte não for fornecida, a informação pode ser removida por falta de neutralidade. O OSM é a Wikipédia dos mapas - inclusive é assim que se apresenta aos novos usuários. Tudo deve ser verificável, não somente sob o ponto de vista da idoneidade, mas também do ponto de vista da correção. Não tem relação com survey. Perfeito. Então o maxspeed no OSM está todo correto, mas o roteamento dá uma rota inadequada. Curiosidade minha: é realmente inadequada, se segue por um caminho mais rápido? (teoricamente, desconsiderando o tráfego) Sim, é inadequada porque transita por área urbana. Gastaram muito dinheiro para fazer a BR-101 Estrada do Contorno. Por ela que o roteamento deve passar. Entendo. Poderia nos copiar a mensagem que ele lhe enviou, mesmo que seja uma declaração dizendo "tá igual à [fonte X]"? Acho que basta. Não. Minha palavra nesse caso basta. Daí o que eu faria é acrescentar uma etiqueta "note" na linha contendo o link para a mensagem dele que você encaminhou pra cá. Dessa forma, outros mapeadores podem verificar a informação. Note que eu colocaria isso em "note" (um comentário informal) e não em "source" (a fonte usada para verificar com
Re: [Talk-br] Necessidade de intermediação
2015-07-05 1:40 GMT-03:00 Marcio - Thundercel : > Por outro lado lembro que classificação de vias e de velocidades interferem > no roteamento e, infelizmente, não dominamos ainda o algoritmo garmin. O que > sabemos sobre ele advém de exaustivos testes realizados. > Não estamos debatendo tempo e sim roteamento e tudo que interfere nele. > Como bem deve saber você o roteamento leva em consideração, além de outros, > a quantidade de nós empregados para unir os segmentos de reta na retratação > da via. > Ao se reduzir a velocidade de um trecho de via o editor é obrigado a dividir > a via de forma a poder no trecho dividido estabelecer a velocidade. Isso por > si só já afeta o calculo de rota por aquele trecho. Afeta, mas muito pouco, pelo menos na minha compreensão de algoritmos de roteamento. O que acontece é que ele cria um novo nó no grafo de roteamento para representar o trecho. O nó contem o tempo total para percorrer o trecho, calculado dividindo distância por velocidade. (há variações em que o nó contem ambas velocidade e distância e o cálculo do tempo é feito durante o processamento, mas elas são matematicamente equivalentes) A criação do nó em si não interfere, a princípio, com o algoritmo. Será um nó a mais a ser visitado enquanto o grafo é explorado pelo algoritmo de roteamento. O que acontece é que algoritmos diferentes usam heurísticas diferentes. Algumas dessas heurísticas decidem "descartar" alguns nós que eles "acham" que têm pouca chance de conduzir à melhor rota. "Heurística" é um método matematicamente impreciso para chegar a uma solução sub-ótima mais rapidamente. Se é impreciso, há heurísticas melhores e piores. Uma heurística comum é visitar primeiro os nós relativos às vias de maior classificação. Nesse caso, como a classificação não foi alterada, o nó seria visitado mesmo tendo uma velocidade mais baixa. Mas o Garmin pode usar alguma outra heurística que eu desconheço. Outro insight: explorar o gráfico requer somar esses tempos, trecho por trecho. São milhares de operação de soma. Se o programa não for bem construído, ele pode acumular erros numéricos ao somar milhares de números. O OSRM me parece particularmente sensível a esses erros. O Garmin geralmente opera num hardware limitado e talvez também seja sensível (tratar desses erros numéricos requer usar mais memória). Mais um insight: classificação interfere com esses algoritmos "mais simples" que usam "heurísticas". A classificação das vias não interfere em nada com o algoritmo A* (a-estrela) puro, nem com o algoritmo do OSRM. Por isso, classificações não devem ser alteradas com vistas ao roteamento. No entanto, um bom método de classificação serve bem a praticamente qualquer algoritmo de roteamento, não por ser o objetivo da classificação, mas por ser efeito colateral dela. Se, numa rota com vários quilômetros, a escolha de uma alternativa ou outra depender de um trecho tão curto quanto o mencionado, é bem provável que alguma dessas características esteja inteferindo no resultado. Mas os mapeadores do OSM não podem fazer nada, e talvez nem os desenvolvedores da aplicação sem ter que reescrevê-la por completo para resolver algum problema mais profundo. O que os roteadores prometem não é encontrar a melhor rota, mas uma rota sub-ótima. Quanto mais longa a distância, maior o efeito desses dois fatores (erro numérico e qualidade da heurística). Até mesmo o Waze às vezes faz bobagem na tentativa de encontrar a melhor rota. -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Necessidade de intermediação
2015-07-04 22:59 GMT-03:00 Marcio - Thundercel : > O OSM não é um tribunal onde devemos nos resguardar com provas todas nossas > edições. Todas não. Apenas as potencialmente polêmicas. A comunidade pode sim julgar e discordar. > Não sei se é a sua dificuldade de idioma, mas ali pode rever você que > apontei as "fontes ilícitas" e comentei que elas não poderiam ser empregadas > no OSM, mas que serviam como fontes de analise. Dependendo do que chamas de "análise", talvez não. Elas são, no máximo, fontes de "inspiração" para que se priorize sua verificação através de fontes lícitas. > Comentei que minha fonte de mapeamento foi um tracklog recebido de um > colaborador que reside em Porto Velho e que infelizmente não o tenho mais e > confesso que mesmo se o tivesse não o apresentaria porque não preciso ficar > insistentemente justificando meus atos. Quando questionado, precisa. Espera-se isso de todos. Quando não há como defender a questão, o comum é o mapeador aceitar que os dados sejam revertidos ao seu estado anterior. Se o mapeador mora no local, é comum ele recoletar os dados para demonstrar. >> Eu mencionou o TrackSource so porque eu sei que o comunidade tem muito >> trabalho identificar edições ilícito copiado do TS, mas não tem >> conhecimento nesses dados. Voce me mostrou 2 imagens desse trevo do >> fontes que eu não conheço, eu não sei se isso poderia ser TS ou não, >> mas sempre pode ter suspeito desse. Eu vai achar muito ruim se vai >> parecer voce copiando dados do TS, o trabalho do verificar seus 5000 >> changesets para identificar qual deles pode ser copiado do TS vai ser >> um tarefa grande demais. Eu acho muito estranho que voce não quer >> compartilhar com o comunidade os dados que te auxiliando resolver >> problemas da mapa, ações muito simples de teu parte poderia resolver >> muitos discussões rapidamente. > > > Mais uma vez identifico que sua dificuldade no idioma português não o > permite ler adequadamente o que citamos. > Lá no debate do changeset informei as fontes WAZE e HERE. Se você diz agora > que não conhece essas fontes "ilícitas" me desculpe, pois a maioria as > conhece e imaginei que você também as conhecesse até porque la comentou você > que o Waze empregou dados do OSM. Acho que ele quis dizer que a comunidade do OSM não conhece os dados do TrackSource para saber identificá-los imediatamente. Em outras palavras, ele quer ter certeza de que você não copiou dados do TrackSource, que as imagens que você mostrou a ele são de uma fonte desconhecida que poderia, talvez, ser o TrackSource. >> eu moro no Guarapari, e frequentemente >> andando esses trechos do BR-101 e ES-060 pra Vitoria, maioria dos >> dados nesses trechos na mapa fui coletado por mim, e provavelmente >> conheço esse trecho melhor que maioria das pessoas nesse lista. > > Desculpe, mas citar que conhece o trecho melhor que a maioria do pessoal da > lista é para mim prepotência. Bem, se ele anda frequentemente pelo trecho, me parece razoável o argumento dele. Se o residente de Porto Velho que lhe mandou os tracklogs estivesse aqui na lista defendendo que o fez, também seria razoável. > Muitos conhecem o trecho, inclusive eu que por sinal estarei trafegando por > ele na próxima semana quando estarei novamente indo a Vila Velha. Faria mais sentido suscitar a dúvida então depois de passar pelo local. Algo pode ter mudado desde a sua última visita - e vice-versa: algo pode ter mudado desde a última visita do Aun. > Conhecendo bem a ES-060 deve ter se esquecido que a velocidade máxima no > trecho da ES-060 onde se encontra o Posto da Policia Rodoviária estadual ( > http://www.openstreetmap.org/way/88221928 ) é de 40 km/h e não 80 km/h. O > operador desse posto (sem etiqueta de operador) é a Policia Militar do > Espírito Santo. Acho que vocês estão entrando em especificidades (que eu desconheço) e que seria melhor tratar disso em outro tópico. Que tal fazer isso no fórum? Geralmente, quando há redução de velocidade numa rodovia, é por um trecho curto. Então, se entendi bem, o trecho de 40 km/h seria apenas no entorno da Polícia Federal, não na rodovia toda. > Não é bem assim. > O roteamento está passando pelas vias urbanas de Vila Velha e pela grande > Vitória. > Sabemos que as vias urbanas por onde ele está passando são congestionadas e > intrafegáveis nas velocidades máximas estabelecidas. > Pela nossa analise corrigimos o problema a nível renderizador excluindo o > trecho da ES-060 onde foi inserida a velocidade de 110 km/h ( > http://www.openstreetmap.org/way/186840962 ) Só um detalhe pra ajudar na clareza do debate: acho que você quis dizer conversor, não renderizador. Um renderizador produz um mapa gráfico, como o visto no site. O Garmin tem um renderizador que desenha o mapa na tela. Um conversor traduz dados de um formato para outro, por exemplo, de OSM para Garmin. O mkgmap é um conversor. Quando esse processo de conversão é muito complexo, às vezes também é chamado de compilador (compilar significa
Re: [Talk-br] Necessidade de intermediação
2015-07-04 21:43 GMT-03:00 Marcio - Thundercel : > Apresentei fotos do local, legislação e tudo mais para poder lhe provar que > o certo era eu. Me lembro que as fotos que você apresentou não estavam atualizadas, e isso é verificável no arquivo do debate. Mas vamos deixar isso de lado. Tenho certeza que ninguém leu aquela nossa discussão, e não farão agora, então não vai levar a nada. De qualquer forma, não tira o mérito de que foi agindo de boa fé. Boa fé não significa que o resultado será correto, apenas que eventuais erros não são mal intencionados. > O caso do Aun é bem semelhante e esse "questiona até a exaustão" e o pior, > põe em duvida a palavra do editor, o que para mim é inaceitável quando, não > tendo eu mais o tracklog recebido, aponto fontes "ilícitas" de consulta. > Ilícitas, ou não, não deixam de ser fontes de consulta que comprovam a > veracidade dos fatos. Na verdade, a gente trabalha sob a premissa de que tudo é questionável. Deixa de ser questionável quando surge consenso. Geralmente, quando está tudo certo (não só o dado como também a sua legalidade), ninguém questiona nada, ou se questiona, se convence rapidamente que não tinha motivo para questionar. > Por fim lembro que estamos aqui para colaborar voluntariamente com o OSM > editando os erros existentes no mapa (que não são poucos) e ninguém gosta de > ficar sendo questionado insistentemente por edições. Ser questionado é > aceitável, mas duvidarem da palavra e das justificativas, não aceito. A justifica tem que ser suficiente para o consenso. Claro, é complicado obter consenso quando são apenas 2 pessoas. Em uma comunidade maior, 3 ou 5 pessoas estariam discutindo e o consenso emergiria democraticamente mais rápido. Eu, por exemplo, não tenho como confirmar a correção de nenhum dos dois lados. Só posso concordar ou discordar com o método usado. > Como tenho realizado muitas edições devido aos inúmeros reportes que recebo > nos sites que administro e também por email, não são poucas as interpelações > que recebo de edições feitas. Me parece até que o OSM Brasil tem mais > fiscais do que editores. Será? Na verdade, mais de 50% das colaborações vêm de mapeadores casuais que acabam nunca se envolvendo com a comunidade, nem têm ideia que a lista talk-br e o wiki existem, muito menos da forma correta de se fazer um tracklog. Numa situação dessas, é bom que o OSM tenha fiscais, já que não existe um mecanismo de moderação. Por exemplo, o residente que lhe passou a informação informalmente poderia estar omitindo algo, mesmo sem perceber. Seria de boa fé, e estaria incorreto. Acredito que o Aun apenas queira ter certeza que estão sendo observados os limites legais. O questionamento feito por ele poderia ser feito, digamos, por quem gerencia uma das fontes ilícitas citadas, alegando (mesmo que falsamente) plágio, apenas para prejudicar o OSM (que é seu competidor de mercado). Se não pudéssemos provar, teríamos que reverter a edição, e com isso perderíamos todas as edições futuras que, juntas, podem representar um trabalho muito maior e mais valiosa do que a informação sendo atualmente questionada. Também acho que o debate esteja escalonando porque falta o material cujo uso foi declarado no changeset. Entendo as condições que levaram à falta, mas espero que vocẽ também entenda por que a falta é problemática para nós. -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
