[Talk-br] Lacuna no mapa - SC

Domingo Dezembro 27 21:32:21 UTC 2015

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 <
openstreetmap em 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 <gweberbh em 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.carvalho em 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 em openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-br
>>
>>
>
> _______________________________________________
> Talk-br mailing list
> Talk-br em openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.openstreetmap.org/pipermail/talk-br/attachments/20151227/bc984614/attachment-0001.html>