Olá a todos, Gostaria de aproveitar as colocações do Gerald... antes lembrar que o assunto aqui era a "lacuna no mapa", percebida pelo Adriano: alguém conseguiu reverter ou resgatar os dados perdidos? PS: e quanto ao uso desse recurso da Wiki <https://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Revers%C3%B5es/Avalia%C3%A7%C3%A3o>, faz sentido entrar com uma descrição do caso?
- - - - Em resposta ao Gerald, eu gostaria de apresentar o modelo de trabalho do Stackoverflow, que contempla o nosso perfil de comunidade e atividades, é baseado num algoritmo de distribuição de revisões aos experts (*fellow members*): http://stackoverflow.com/review ele pode ser adaptado a ambientes como OSM, e pode ser usado apenas um contexto específico como OSM-BR. O algoritmo de distribuição de revisões garante também um maior acolhimento aos novatos. Os tais *fellow members* são justamente os usuários com qualificação minimamente comprovada, que o Alexandre tentava descrever em termos de pontos de participação no outro *thread* aqui da Lista. Alias, entendo que já existe coisa semelhante no OSM, só que mais passiva, http://learnosm.org/en/coordination/tasking-manager/ Acredito que que possamos chegar a um "algoritmo ideal"... Que tal começarmos a consolidar essas discussões na Wiki <https://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Comunidade_e_governan%C3%A7a>? Alguém poderia ajudar? Essas discussões todas são esclarecedoras e podem convergir em decisões sábias e promissoras, é um desperdício perdermos elas todos os anos aqui na Lista... Falta dar o passo seguinte, que é resumir/consolidar os consensos e (quando fizer sentido) consultar o resto da comunidade. Em 27 de dezembro de 2015 12:05, Arlindo Pereira < openstreet...@arlindopereira.com> escreveu: > Mais que isso: o OSM parte do princípio que ninguém melhor que um mapeador > local para verificar se as edições locais são, de fato, válidas. Um editor > remoto poderia verificar se uma determinada edição é maliciosa, mas apenas > até certo limite, apenas se o "mal" feito for bastante óbvio (deleção de > vias etc). > > Por outro lado, outros tipos de edições (digamos, adição de POIs como > bares, restaurantes, farmácias etc.) totalmente fictícias poderiam ser > verificadas só por editores locais. > > Precisamos, essencialmente de mais braços. *Precisamos de muitos fazendo > o suficiente, não de poucos fazendo muito.* Por isso a "chatice" de > alguns membros, porque o malfeito de um ou outro pode colocar em risco > todas as demais contribuições (seguindo regras internacionais do projeto, > nada que definimos por aqui, e que quem quiser contribuir tem > necessariamente de seguir). > > []s > Arlindo > > 2015-12-25 20:14 GMT-02:00 Gerald Weber <gwebe...@gmail.com>: > >> Oi Paulo, >> >> interessantes as suas colocações, mas tenho algumas observações a fazer >> >> 2015-12-25 14:37 GMT-02:00 Paulo Carvalho <paulo.r.m.carva...@gmail.com>: >> >>> A coisa é muito simples e funciona. Darei dois exemplos de sucesso já >>> comprovado: software open-source e publicações científicas. >>> >> >> Nenhum dos dois modelos involve leigos, mas pessoas altamente >> especializadas. Ninguém contribui num projeto de software sem ao menos um >> domínio básico das linguagens envolvidas. Ninguém publica em revistas >> científicas sem muitos anos de especialização. Outro ponto é que o número >> de pessoas envolvido num projeto de software é bastante restrito, assim >> como o número de pessoas que estão envolvidas numa publicação caberiam numa >> sala (exceto nas colaborações de física de partículas, exemplo LHC). >> >> Já o modelo do OSM envolve uma variedade de pessoas muito grandes, desde >> especialistas em GIS até leigos totais em cartografia (como eu por >> exemplo). Também o número de pessoas envolvido aqui é bem maior do que em >> qualquer projeto de software típico. >> >> >>> Ambos os processos são pautados no princípio do terceiro confiável. O >>> OSM não aplica esse princípio, ou seja assume que uma das partes (no caso >>> os usuários) é confiável, e o resultado são as frustrações e as >>> consequentes perdas de tempo consertando que vemos com frequência. >>> Conclusão: o modelo de colaboração do OSM é ineficiente. A solução para >>> essa ineficiência está aí. Não fazem porque não querem. >>> >> >> Não sei como se poderia operacionalizar um modelo de validação eficiente >> no OSM diante de um público tão heterogêneo. Qualquer que seja a solução >> ela envolve gente para operacionalizar isto. A lógica dominante no OSM é >> que tendo uma massa grande de mapeadores qualquer problema seja rapidamente >> solucionado. O nosso problema aqui na América do Sul é que não temos essa >> massa de gente e por isto a lógica que funciona na Europa não funciona para >> nós. >> >> >>> >>> Os mapas do OSM existem em forma de XML, o que seria perfeito de se >>> sujeitar a um sistema de versionamento moderno como o Git e o Mercurial. >>> >>> O ser humano é falho, seja por má intenção ou por descuido. O peer >>> review e o merge request são mecanismos criados para justamente impedir >>> tais falhas de contaminem os respectivos produtos de forma que o reparo >>> seja muito custoso ou que traga consequências ruins. >>> >>> >> Bom, eu trabalho com peer review diariamente e posso te contar cada >> história, mas isto é outra conversa ;) >> >> Agora, como o atual sistema funciona bem na Europa, eu percebo uma >> resistência muito grande em introduzir qualquer mecanismo que possa ser >> visto como uma barreira. A recente tentativa do Arlindo de solicitar um >> simples aviso no Id é bem emblemático disto, os desenvolvedores do Id nem >> deram papo e fecharam a requisição horas depois. >> >> Mas uma idéia que eu acho que podemos emprestar da área de software é >> trabalhar com versões beta e versões estáveis da base. Por exemplo, fazemos >> uma cópia local da base do OSM (digamos só do Brasil) da qual temos >> razoável confiança de não ter nenhum problema maior e declaramos ela como >> versão estável. A partir desta versão poderíamos produzir um índice de >> qualidade calculado a partir de validações e testes. A versão estável só >> seria substituída periódicamente por uma versão com índice de qualidade >> maior, ou algo do gênero. A gente só usaria a versão estável para gerar >> mapas para dispositivos ou quaisquer outros fins. A gente poderia até >> eliminar localmente os changesets duvidoso da base estável, da mesma >> maneira como bugs são corrigidos em versões estáveis de software. Bom, é só >> uma idéia que precisa de amadurecer, mas se a gente conseguir por algo >> assim para funcionar eu acho que a gente poderia conseguir a aceitação >> disto de muita gente por aí que depende de maneira crítica da base. >> >> abraço >> >> Gerald >> >> >> >> >> _______________________________________________ >> 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 > >
_______________________________________________ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br