[Talk-br] Necessidade de intermediação

[Marcio - Thundercel]

nas entrelinhas...

-----Mensagem Original----- 
From: Fernando Trebien 
Sent: Saturday, July 4, 2015 8:37 PM 
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br] Necessidade de intermediação 

Peguei o bonde andando e só queria comentar alguns detalhes que
entendi por altos (TL;DR), me corrijam se os interpretei mal.

Primeiro, se a imagem de satélite está desatualizada, de fato o que
deve valer é o que foi coletado com tracklogs. Um passeio com o Google
Street View na área sugere que a via atualmente mapeada estava em
construção há pouco tempo, então acho que o seu traçado está "correto"
também.

Esse Trevo do Roque está em construção desde 2005 e ainda não está concluído.

Segundo, se a informação do traçado não foi obtida presencialmente ou
por fonte lícita (Google Maps/Satellite, TrackSource, Waze e Here.com
não são lícitos), o mapeamento feito infrigiu direitos autorais. Uma
espiadinha no Google Street View não é infração quando é para
relembrar algo de um lugar por onde você já passou (não vale para
mapeamento remoto). Mesmo assim, essa minha espiadinha aí acima não
seria justificativa para que eu, à distância, alterasse o mapa. Apenas
se eu tivesse passado por lá.

Não se comentou que o o traçado foi obtido por algumas das fontes ilícitas citadas, se comentou que essas fontes foram empregadas para consulta do traçado recebido e extraído por GPS.
“Espiadinha” pode ser feita pelo editor em qualquer fonte ilícita desde que não empregue aquela fonte como referencia para o desenho.

O próprio maparadar.com só é fonte lícita se seus colaboradores (não
apenas seu administrador) declararem que renunciam o direito autoral
sobre os dados que contribuíram. Caso não declarem, o administrador
pode vir a ser processado, e por consequência, o OSM. O mesmo motivo
já nos fez barrar a importação de dados de algumas prefeituras, e é o
motivo pelo qual não podemos usar dados do TrackSource, nem que sejam
doados por boa vontade. Caso qualquer desses sites passe a exigir tal
declaração, apenas os dados contribuídos após essa declaração podem
ser aproveitados por nós, os anteriores não, a menos que se obtenha
uma declaração retroativa de cada colaborador.

Perdoe, mas como administrador do Maparadar discordo.
Elaboramos no Maparadar os “termos de uso” dos seus dados e nele estabelecemos que somente o administrador tem a competência de autorizar o emprego deles.
A partir do momento que os colaboradores informam pontos de alerta ao maparadar estes estão tornando publica essa informação e com isso perdem os direitos autorais sobre ela.
Apesar de ser bacharel em direito contratamos no Maparadar, em 2012, assessoria jurídica sobre o assunto porque tínhamos duvidas a respeito. 

Se um morador local lhe mostrou um tracklog, é lícito copiar o que
você lembra que viu (inclusive se estiver olhando no monitor ao lado
do seu). Se usou o trackog diretamente (abriu e copiou a geometria de
forma não-manual, com copiar+colar), apenas com autorização de quem o
gerou.

O residente me enviou o tracklog a apontou as fontes “ilícitas” como corretas e analisando-as identifiquei que o tracklog por ele enviado estava conforme aquelas fontes. Assim desenhei o Trevo baseado no Tracklog e não pelas fontes “ilícitas” apontadas e consultadas. 

Terceiro, já fui questionado várias vezes em meus mapeamentos, em
todos me dispus a coletar a informação para defender o que fiz. Por
isso uso várias tags auxiliares, como source:name, source:maxspeed e
source:highway por exemplo, que pouca gente usa. Faz parte do processo
de colaboração ser questionado. Então, se existe um risco de ser
questionado (e o risco é grande quando a imagem que temos não está
atualizada), é bom guardar um tracklog pra comprovar. De preferência,
tirar fotos também. Sei que é trabalhoso, mas todos queremos que o
mapa seja confiável, e todos somos passíveis de erro, portanto todos
somos questionáveis. Se um dia alguma empresa grande abrir processo
contra o OSM alegando que dados foram obtidos ilegalmente, o tracklog
é evidência do contrário. Caso um colega cobre o tracklog, não é por
desconfiar da idoneidade do outro e sim por precaução, pelo bem da
comunidade do OSM. Devemos então encarar o questionamento dos colegas
não como uma afronta à idoneidade e sim como um simples "sanity check"
(e todos precisamos, ninguém é onisciente e infalível).

Quando editei o novo trevo incluí a etiqueta source:GPS;survey no entendimento que isso, por si só, já estampava que o desenho não coincidia com a imagem satélite desatualizada.
Ser questionado de alguma edição até concordo, mas não acreditar nas justificativas e respostas do editor, não concordo. Pedir a esse que mostre a prova, mesmo depois de apontado fontes “ilícitas” de consulta? Se você aceita questionamentos a sua palavra e não aceita suas justificativas, é um atributo seu.
Não costumo arquivar todos os tracklogs que recebo até porque administrando sites de GPS recebo inúmeros. Frequentemente solicito tracklog a colaborador que aponta via desalinhada no mapa ou quando extrai ponto de alerta com coordenadas distantes da via estampada na imagem satélite.


Quarto, é muito fácil quebrar relações sem querer (estou brigando com
o pessoal do iD pra minimizar esse problema). Questionador e
questionado têm que ter isso em mente para não se desentenderem à toa.

Apesar de ter eu corrigido a relação rota da BR-364 no trevo não foi eu quem a quebrou e tampouco me preocupei em saber quem foi para questionar. Editei e corrigi a relação.

Quinto, sobre este trecho: "Compreenda também que estamos tratando de
vias automotivas e não vias para bicicletas e tampouco tracklogs
desatualizados extraídos por bicicletas podem valer de referência para
se desenhar vias ou links automotivos."

Se o tracklog está desatualizado, ele certamente tem que ser encarado
com cuidado. Independente se foi extraído por bicicleta ou carro.

E com muito cuidado porque a área está em constante transformação devido as obras. Tracklogs levantados antes podem não ser mais referencia para desenho.

A linha da via no OSM expressa o seu eixo e representa o conjunto das
suas partes (pista, calçadas, ciclofaixas, faixas de ônibus, etc.). É,
portanto, uma via automotiva, mas não só automotiva. Valem tracklogs
para bicicleta porque a legislação permite a circulação de bicicletas
na pista junto com os carros (exceto em alguns casos especiais, como
rodovias sem acostamento).

Sim, mas sabemos que desenhar acessos se valendo tão somente de tracks de bicicleta pode nos induzir a erros. Bicicleta compartilha via, mas no Brasil também trafegam por trilhas por elas mesmo criadas em canteiros onde não se pode trafegar com elas.
Por isso é muito importante que ao analisarmos trilhas identifiquemos a frequência delas.

Não se pode mapear com foco em uma modalidade de tráfego só, no
sentido de ignorar a utilização dos dados para as demais modalidades.
Sei que muitos pensam mais em carro, mas o OSM é democrático.

Ninguém comentou ao contrário

Sexto, eu não entendi bem a questão de "dropar" o "maxspeed" da ES-060
para resolver algum problema com o mkgmap. Mas: nenhuma informação
deve ser retirada do mapa para contornar problemas com aplicações
específicas. A gente reiteradamente abomina qualquer mapeamento feito
para aplicações específicas (seja renderizador ou roteador ou outra).
Se entendi bem que é isso que foi feito, tem que ser desfeito.

Esse é um debate antigo que daqui a pouco vai ganhar um bolo de aniversário por não ter sido ainda solucionado a nível OSM.
O roteamento pela BR-101 passando pelo Espírito Santo está interrompido em Guarapari e Serra, abandonando a BR-101 e entrando na grande Vitória e Vila Velha.
Pela analise e testes que fizemos isso está ocorrendo pela max_speed inserida na ES-080, muito superior a da BR-101.
Como não chegamos a uma solução aceitável a nível OSM decidimos corrigir o problema a nível renderizador (Mkgmap) inserindo nele drop para a max_speed da BR-060 nos dados OSM.
Assim, não retiramos a informação do mapa OSM, simplesmente as desconsideramos a nível Mkgmap.


Sétimo e último, de fato o Waze traiu o OSM incorporando os dados que
a comunidade havia produzido, sem dar o devido crédito, nem
compartilhar os benefícios.

P.S.: Se a questão é apenas mostrar que os dados foram de fato
coletados em campo, talvez baste perguntar pro colega residente que
gerou o tracklog que o compartilhe com a comunidade. Acho que isso
teria economizado toda essa discussão. E não, só a palavra não basta.

Isso desejaria eu, mas infelizmente o brasileiro é acomodado e todos sabem aqui que preferem criticar do que colaborar. Ainda bem que esse residente em Porto Velho colaborou me informando o erro no trevo e me enviando, por solicitação minha, o tracklog do local.

Desconheço a experiência de vocês em extração de tracklogs, mas para os que não sabem existem técnicas de extração de tracklogs para fins de mapeamento. Nem todos os colaboradores conhecem essas técnicas e muitos me enviam “registros de viagem” que na verdade não são adequados a mapeamento até porque não gravam os segmentos com espaçamento de 1 seg.



2015-07-04 19:35 GMT-03:00 Aun Johnsen <lists em gimnechiske.org>:
> On 7/4/15, Marcio - Thundercel <thundercel em gpsinfo.com.br> wrote:
>> Conforme já citei a você anteriormente e somente a titulo de ilustração
>> porque as fontes não podem ser empregadas no OSM:
>>
>> Tracklogs atualizados no trevo:
>>
>> http://gpsinfo.com.br/images/portovelho2.jpg
>>
> Vejo que spread e muito grande nesses tracklogs, mas pode ser por
> ferramenta do visualização, esses tracklogs pode ser compartilhadas
> para o OSM? do onde eles são disponíveis?
>> Mapa Waze atualizado segundo informação do residente local:
>>
>> http://gpsinfo.com.br/images/portovelho.jpg
>>
> Nao conheco esse feramenta do visualisazao, os dados não e do OSM,
> isso e do TrackSource? Acho que e do um projeto ou  outro de mapas
> crowdsource com licença não compatível com OSM, não confia muito isso
> porque pode ha mesmo erros de falta do levantamento. Que a link não
> existe no TS ou outros fontes similares não significa que não existe.
>> Mapa Here atualizado no trevo também segundo informação desse mesmo
>> residente:
>>
>> https://www.here.com/?map=-8.77122,-63.88256,18,normal&x=ep
> Mapas Here também tem mesmo problema, mapas crowdsource sobre licença
> não compativel mesmo não confiável
>>
>> Compreenda que esse Trevo vem sofrendo inúmeras alterações devido as obras e
>> um histórico que se arrasta por anos. O DNIT assumiu as obras desse trevo
>> depois que a Prefeitura não foi capaz de conduzi-las. Veja histórico disso
>> em
>> http://blogdocarloscaldeira.blogspot.com.br/2015/01/conheca-toda-historia-dos-viadutos-de.html
>>
> Isso e informação novo para mim, porque voce não divulgou isso
> primeira vez? Blog do um politico aparentemente do Porto Velho, que
> quer usar o problemas de terminar obras nesse trevo para fim deles,
> esse pode dar mais luz sobre situação admito.
>> Compreenda também que estamos tratando de vias automotivas e não vias para
>> bicicletas e tampouco tracklogs desatualizados extraídos por bicicletas
>> podem valer de referência para se desenhar vias ou links automotivos.
>>
>> O desenho que havia eu feito refletia as informações recebidas por mim de um
>> residente local e você as está alterando por deduções e não vejo isso como
>> correto.
>>
>> Agora mesmo solicitei ao colaborador que lá reside o tracklog do acesso
>> passando por baixo do viaduto que foi aberto ao tráfego na semana passada.
>> Estou aguardando ele me retornar.
>>
> Espero retorna dele, e se for posivel compartilhar os tracklogs dele
> com o comunidade, vai ser muito util em disputas como esse, e talvez
> podemos descobrir mais problemas do roteamento com isso?
>> Se você cita que faço edições que não concorda também não concordo com
>> muitas que você faz e nem por isso vou a você questionar a fonte de
>> referencia empregada e mesmo informando eu replicar que não é verdade.
>>
>> Creio que essas discussões também não levam a nada e como você citou, se
>> pararmos para ficar debatendo essas pequenas situações deixaremos de
>> corrigir os inúmeros erros ainda existentes no mapa. Como você também não
>> vou questionar seus erros, vou corrigi-los diretamente, mas continuo
>> aguardando a correção do roteamento incorreto pela ES-060 que você se
>> prontificou a corrigir. Creio que pelo visto serei obrigado a corrigir as
>> velocidades incorretamente incluídas em trecho da rodovia.
>>
> Pelo roteamento do ES-060 e BR-101 entre Guarapari e Vitoria eu ja
> coletei horas de trilhas, compartilhadas no OSM-GPS e no Mapillary,
> voce pode entra e ver cada placa de velocidade, para, de a
> preferencia, semaforo e mais nesses trechos, e voce pode ver que se a
> mapa nao e 100% certo e bem proximo. Eu ainda esperando ferramentas
> para JOSM que vai me ajudar editar isso, que e previsto melhorar os
> proximo meses, e tempo a anilisar esses dados. Eu ainda tem algum
> ligares ao ir gravar mesmos dados para Mapillary, para identificar
> porque voce fui roteado ao sair BR-101 onde o GPS falou. Ja entrei
> muitos maxspeed nesse região para melhorar o roteamento, mandei uns
> 5-6 issues para OSRM para melhorar o penalidade por roteamento urbana,
> e procurei para entender que tipo tags pode dar penalidade similar no
> GPS como Garmin.
>
> Voce dize no um comentario que ha muitos radares do 60km/h nesse
> trecho ES-060, se voce olhando meu Mapillary e a mapa voce pode ver
> que quase tudo deles ja e no mapa e que o velocidade desses radares
> não e 60km/h mas e 80km/h
>
> Espero se voce começar editar esses trechos que voce mesmo procurando
> que tem nesses imagens Mapillary, se voce não quer esperar ate eu
> terminar meu levantamento e analisa dos dados, para não totalmente
> gasta meu tempo levantando esses dados.
>>
>
> _______________________________________________
> Talk-br mailing list
> Talk-br em openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br



-- 
Fernando Trebien
+55 (51) 9962-5409

"Nullius in verba."

_______________________________________________
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/20150704/462a589f/attachment-0001.html>