[Talk-br] uma defesa do uso generalizado tag source

Fernando Trebien fernando.trebien em gmail.com
Segunda Outubro 28 23:15:43 UTC 2013


A API do OSM não parece ser feita para que se baixe o histórico de
cada objeto ao baixar uma área do mapa - note quão lento é o plugin
Reverter do JOSM e o número de requisições HTTP que ele faz só para
conseguir obter a última versão de cada objeto (nem é o histórico
completo). Para implementar o que você sugere, é necessário solicitar
diretamente aos desenvolvedores da API. Eu acredito que algo parecido
já esteja no roadmap deles (é absolutamente necessário quando a
comunidade cresce), mas pode demorar para ser implementado.

Acho interessante essa discussão porque ninguém, absolutamente ninguém
jamais reclamou da ausência de tag source nos objetos novos que eu
criei ou nos changesets que eu submeti (já foram mais de mil
changesets e alguns deles tinham quase 10000 objetos). Nem mesmo nas
importações, que eu tenho certeza que foram conferidas (pelo menos por
altos) por alguém na OSMF (me contataram algumas vezes). Por isso,
acho que todos assumem que a ausência da tag significa source=Bing.

A tag source pode ser modificada no futuro caso você obtenha uma boa
fonte, mas ela continua aparecendo no histórico do objeto. É quase tão
difícil/custoso recuperar o histórico inteiro quanto descobrir qual
changeset recebeu a tag source originalmente - com a tecnologia atual.

Para monitorar edições numa área, eu uso o OWL e o WhoDidIt. O OWL é
relativamente fácil de usar e é bem leve, mas ainda é alpha e tem bugs
(nem todas as edições aparecem). Já o WhoDidIt é mais chato de usar;
especialmente para changesets grandes, uso o OSM History Viewer para
cada changeset individual. Se for pequeno, a própria visualização do
changeset na interface web do OSM já basta pra entender o que foi
feito (raramente os problemas envolvem "geometria mal feita" e sim
vias excluídas ou incluídas erroneamente ou mal etiquetadas).

2013/10/28 Augusto Stoffel <arstoffel em yahoo.com.br>:
> Quando uma via com tag source é modificada, todas as chances são de que
> a tag source permaneça a mesma; eu certamente já modifiquei vias com
> source=IBGE sem mexer na tag.  Portanto, na prática a única forma
> confiável de determinar que tal via não corresponde mais ao dado
> original do IBGE é a (ausência de) tag source nos meus changesets.
>
> Outro ponto, relevante para questões de atribuição, é que nada garante
> que a tag source não vá ser modificada ou removida no futuro.  Eu
> entendo que é por isso que a comunidade insiste em adicionar a tag
> source no changeset e não nos nós e vias quando se faz uma importação.
>
> Pode ser verdade que nenhuma ferramenta disponível atualmente permita
> fazer um uso muito prático do source de changesets.  Essa dificuldade
> com JOSM poderia ser resolvida facilmente: ao baixar a história de uma
> via, o JOSM poderia exibir as tags dos changesets correspondentes;
> visualizar os respectivos comentários também seria útil.  (A propósito,
> qual aplicativo vocês usam para visulizar o histórico de edições em uma
> dada área?)
>
> Talvez os editores pudessem insistir que uma tag source seja dada a cada
> changeset, assim como insistem em que se forneça um comentário.  Isso
> provavelmente teria mais valor didático que a mera presença de tags
> sources em diversos elementos.  (Aliás, notei também que o iD adiciona
> uma tag imagery_used em cada changeset, que na prática é similar a dizer
> source=Bing).
>
>
> On 10/28/2013 04:01 PM, Gerald Weber wrote:
>> Olá pessoal
>>
>> eu vou fazer aqui uma defesa da tag source nas vias (ways) e nós
>> (nodes), onde for apropriado, é claro.
>>
>> Porque? A minha motivação é um comentário feito por um colega (em
>> privado) de que era muito comum colocar o source no changeset ao invés
>> de colocar nos nodes e ways.
>>
>> Para um projeto que tem tanta preocupação com a origem dos dados eu acho
>> estranho a atitude tão relaxada em relação à presença da tag source. De
>> fato acho isto um desastre.
>>
>> Bom, qual é o ponto? É que muitos mapeadores, ao invés de incluir a tag
>> source em cada via, simplesmente a adicionam ao changeset. Por exemplo,
>> você faz uma grande edição de novas vias no JOSM usando as imagens do
>> Bing, ao invés de colocar em CADA via a tag source=Bing, você coloca UMA
>> SÒ no changeset. Claramente, parece bem conveninente e deve poupar
>> bastante trabalho.
>>
>> Como se coloca source=Bing no changeset? Na hora de devolver os dados ao
>> OSM, clique em "Tags of new chageset"  e adicione source=Bing (ou o que
>> for que você tenha usado).
>>
>> Isto é válido? Sim, é perfeitamente válido, mas acho que é tremendamente
>> infeliz.
>>
>> Para começar, ao colocar o source no changeset você efetivamente esconde
>> ele das vistas dos usuários. Imagina um objeto que já tenha 15 versões,
>> você teria de abrir 15 changesets um a um para achar qual foi o source
>> dos dados. Isto é demorado pois o JOSM abre uma aba de navegador para
>> cada uma delas.
>>
>> Mas isto não é o pior. O pior é que *desincentiva* a declaração de
>> origem dos dados. E isto eu acho desastroso.
>>
>> Veja o exemplo de um novato no OSM que começa a usar o iD ou o Potlatch.
>> Ele não vai ver a tag source em lugar nenhum (pois ela está enterrada em
>> algum changeset, isto quando existe).
>>
>> Que mensagem estamos passando? Estamos dizendo que a origem dos dados
>> não importa, pois se importasse todo mundo colocaria a tag source, não é
>> isto?
>>
>> Por isto eu acho ima idéia infeliz de colocar o source SOMENTE no
>> changeset.
>>
>> Eu tenho a impressão que boa uma parte dos nossos problemas (usuários
>> copiando dados de onde não devem) é que nós mesmos não estamos nos
>> disciplinando para deixar claro de que a origem de todos os dados
>> *precisa* ser declarada.
>>
>> Agora, se o novato abre uma região no iD e encontra a tag source em
>> TODAS as vias o que vai pensar? Aqui a mensagem que a gente passa é
>> outra: "Declarar a origem dos dados é importante". Em particular, se ele
>> vê muitas tags do tipo "source=Bing"  ou "source=IBGE", mas NUNCA uma
>> "source=Google" deve ao menos desconfiar de alguma coisa, não é mesmo?
>>
>> Veja que os novos usuários tendem a imitar aquilo que eles veem. Se
>> ninguém coloca source, eles também não vão colocar, e isto é péssimo.
>>
>> Da minha parte, eu gosto de colocar o source o mais detalhado possível.
>> Por exemplo, se eu desenhei uma via pelo Bing, peguei o nome pelo IBGE e
>> sei que é asfaltado porque eu passei por lá eu coloco 3 source:
>> source=Bing
>> source:name=IBGE
>> source:surface=survey
>>
>> Eu acho sempre muito útil quando encontro a tag source. Por exemplo,
>> outro dia eu olhei uma via que tinha a imagem no Bing mas tinha
>> source=GPS. Isto deixava claro para mim que o mapeamento foi feito  pelo
>> GPS antes de ter imagens do Bing da região e por isto a via não
>> coincidia muito bem com o Bing. Depois eu realinhei as vias e coloquei
>> source=Bing;GPS, isto deixa claro para quem vem depois que AMBAS as
>> informações foram usadas.
>>
>> Vejam que eu não tenho nada contra colocar o source no changeset, desde
>> que seja EM CONJUNTO com o source nos seus devidos lugares.
>>
>> Do jeito que está agora me parece uma atitude que só tende a gerar dor
>> de cabeça para todos nós.
>>
>> Então gente, eu faço um apelo: coloquem source em tudo o que for
>> necessário!
>>
>> Com bom senso, claro! Se um rio tem 300 nós, não tem sentido colocar 300
>> vezes source=Bing em cada nó, basta colocar source=Bing só no rio mesmo. OK?
>>
>> abraço
>>
>> Gerald
>>
>> source=Minha experiência pessoal
>>
>>
>>
>>
>> _______________________________________________
>> 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



-- 
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)



Mais detalhes sobre a lista de discussão Talk-br