Transporte público em Porto Alegre

Ah mas, esse site só mostra os itinerários e não faz cálculos de rotas, certo? Daí é igual ao PoaTransporte, só muda o plano de fundo. Em Brasília eu sei que contrataram cartógrafos para fazer o traçado das linhas (o que era muito necessário por lá de qualquer forma). Aqui em Porto Alegre, não podemos usar o traçado do PoaTransporte porque ele inclui informações cartográficas do Google (com copyright). Do jeito que estamos fazendo, no fim do processo vamos ter duas coisas a mais que são interessantes:

Hehe ok. Eu espero terminar a importação até o final de semana também. Essa questão dos terminais se arrastou mais do que eu tinha planejado (não esperava que a EPTC tivesse 20 variações de nomes para o mesmo terminal). Mas no fim o resultado vai ficar muito bom.

Como você está deduzindo a geométria a partir da descrição textual – das rotas (linhas) e paradas (pontos)?
Talvez voce queira responder aqui: http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/RS/Porto_Alegre/Transporte/Atualizacoes

O processo é como eu descrevi nesse workflow: http://i.imgur.com/bm9Sdw9.png

  1. Baixar os arquivos JSON do PoaTransporte que contêm a geometria das rotas
  2. Baixar os itinerários textuais e as tabelas de horários da EPTC
  3. Consertar os nomes de linhas e de terminais contidos nos itinerários da EPTC
  4. Transformar a geometria dos arquivos JSON em arquivos OSM via script; o arquivo contém geometria do PoaTransprote e tags baseadas em nos nomes consertados das linhas e dos terminais
  5. Quebrar a geometria das rotas (agora arquivos OSM) e das ruas no mapa do OSM aproximadamente nos mesmos pontos
  6. Aplicar a conflação

Esse último passo serve apenas para encontrar a correspondência entre a geometria do OSM e a geometria do PoaTransporte, que é informação do Google e não pode ser importada diretamente. Além de encontrar a correspondência, a conflação automaticamente atribui a relação (montada pelo script sobre a geometria do PoaTransporte) às linhas certas no OSM (o que facilita enormemente o trabalho). A geometria final é idêntica à original do OSM e não inclui nenhuma informação do Google. Não se pode afirmar que inclui informação do PoaTransporte também já que praticamente tudo (tags, geometria, estrutura dos dados, etc.) está diferente. Legalmente, seria o equivalente a copiar de outro mapa à olho. Usar a geometria do PoaTransporte como entrada na conflação é apenas um atalho para não eu não ter que ler cada itinerário individualmente; provavelmente é isso que a EPTC faz quando atualizam as rotas no PoaTransporte, tanto que ontem achei um erro no terminal de uma das rotas (que não parece ter mudado recentemente).

O plano de atualização é comparar a versão atual dos itinerários com a última versão revisada e aplicar as diferenças manualmente. Geralmente são poucas diferenças. Fazer isso via script seria OU tão trabalhoso quanto o trabalho manual de ler cada itinerário (porque seria necessário encontrar uma correspondência entre o registro de nomes de ruas da EPTC e o do OSM) OU perigoso, considerando a má qualidade dos dados da EPTC.

Deixa eu verificar meu entendimento. Então você se baseia nas tabelas textuais de itinerários da EPTC e no traçado geométrico do PoaTransporte para encontrar as vias correspondentes no OSM. Tanto as geometrias do PoaTransporte quanto os nomes de logradouros da EPTC são descartados, pois ambos já estão cadastrados nas vias do OSM. A quebra das vias do OSM serve para facilitar a busca da correspondências.

(Talvez você queira renomear no diagrama “rotas importadas” para “rotas definidas”, refletindo a interpretação que é você que detem os direitos de autor das rotas no OSM, podendo assim ceder o seu uso. Desculpa a chatice mas é preciso deixar isso documentado por proteção em caso de auditoria no futuro.)

Segundo essa interpretação, não vamos poder importar as paradas de ônibus, correto?

OK, entendo que é melhor que a atualização seja feita manualmente. Será que pelo menos a detecção de alteração poderia ser automatizada?

Abc,
-Felipe.

Sim, acredito que dê para detectar automaticamente as alterações e inclusive indicar onde ocorreram. Idéias de como fazer isso não me faltam, vamos ver qual delas dá menos trabalho.

Acho que podemos importar as paradas sim porque as suas coordenadas não são provenientes do Google (apenas as coordenadas do traçado das rotas são) e porque elas serão ajustadas à geometria do OSM: todas elas serão ligeiramente diferentes das do PoaTransporte (provavelmente tão diferentes quanto as vias do OSM forem diferentes das do Google).

Em qualquer outro caso isso poderia ser entendido talvez como “obra derivada”, mas o PoaTransporte é mantido pela Prefeitura, pela EPTC (empresa pública) e pela Procempa, então a lei de acesso à informação nos dá amparo. A única coisa que essa lei não nos dá é a garantia de nos disponibilizarem os dados em um tempo razoável, mas isso nós já conseguimos.

Concordo que não é uma mera reprodução (cópia) exata, discordo que não é obra derivada – acho que é obra derivada, sim – e discordo que a LAI diz qualquer coisa a respeito do uso e redistribuição dos dados públicos que ela dá acesso. Concordo também que a licença de obras derivadas do Google é clara: é proibitória.

Agora se há normalmente restrições a respeito do uso e redistribuições de dados públicos, a minha interpretação é que não há nada bem definido, com relação a p.ex.:

  • permite remixar (geracao de trabalhos derivados)?
  • permite compartilhamento (redistribuicao)?
  • permite uso comercial?
  • dispensa atribuicao?
  • dispensa renomeacao em caso de modificacao?

Já a Corregedoria Geral da União discorda enfaticamente, veja:
https://groups.google.com/d/msg/lista-inda-gt1/DEYnioFJ5ao/3qcg4G8VG-oJ

Aqui temos cinco casos de uso dos dados da PMPA:

  • rotas (por conflação): uso aceitável (fair use);
  • paradas (adaptação): obra derivada;
  • numeração das vias (por cópia): reprodução?
  • geometria das vias (por cópia): reprodução.
  • geometria das rotas (por cópia): reprodução (originalmente é derivação da obra da Google por parte da PMPA)

Abc,
-F.

Me corrija se eu estiver errado.

  • paradas: obra derivada do PoaTransporte (entende-se EPTC/PMPA)
  • numeração das vias: obra derivada (não vem no mesmo formato) do GEOLAB/UFRGS (e ninguém ainda respondeu aquele meu e-mail…)
  • geometria das vias: não será importada, já existe no OSM
  • geometria das rotas: não será importada diretamente, será usada para atribuir às vias do OSM os pedaços de cada rota; esse trabalho à princípio é obra do PoaTransporte (EPTC/PMPA) implementada com o sistema do Google, não é obra do Google, a obra do Google são as vias, os seus nomes e as coordenadas dos seus traçados (nada disso será importado)

Pense assim: se eu tivesse ao meu lado um mapa impresso pela EPTC com as rotas de ônibus (esse mapa inclusive existe: http://lproweb.procempa.com.br/pmpa/prefpoa/eptc/usu_doc/mapa_linhas.pdf)) e fosse olhando as rotas e construindo as relações no OSM à mão, seria obra derivada? A reprodução não é exata, e é praticamente equivalente a ler os itinerários da EPTC e fazer a mesma coisa.

Agora, ao invés do mapa, eu tenho os contornos do PoaTransporte. Eu vou rodar um programa sobre esses dados que encontra as vias correspondentes a cada pedaço dentro do mapa do OSM. Os dados do PoaTransporte serão usados apenas para construir as relações de rota, não para traçar vias. Isso é obra derivada? Isso não é equivalente a transcrever olhando pro mapa anterior? E se ao invés de olhar pro mapa da EPTC eu estivesse olhando pro site do PoaTransporte, não é igual?

Onde fica o limiar que define que algo é derivado ou não? Por exemplo, se eu pegar uma música, transpor, inver, mudar os acordes de maior pra menor, no meio do caminho mudar algumas notas, e ainda dar nomes diferentes aos compassos, isso é obra derivada ou obra própria? Essencialmente é isso que eu estou fazendo aqui: transpondo (de uma geometria para outra), invertendo (os segmentos conforme necessário), mudando os acordes (de uma representação lógica baseada em linhas individuais para outra baseada em relações), mudando algumas notas (as pequenas adaptações em conexões que existem num mapa e não existem no outro, todas manuais) e dando nomes diferentes aos compassos (mudando os nomes das linhas e dos terminais). Se nesse processo eu ainda corrigir erros (como nomes e posições de terminais), fica ainda mais difícil de argumentar que é uma obra derivada. O OSM tem nomes de ruas errados, então mesmo extrair um itinerário do OSM produziria um resultado diferente dos itinerários da EPTC.

Sobre a Corregedoria, eu entendo que, se a legislação nesse momento não prevê impedimentos ao uso da informação, uma lei futura não pode revogar o direito sobre o que foi feito com a informação (não pode exigir que seja tirada do ar). Em uma disputa legal, a lei que vale é a lei que valia no momento do ato, não no momento da disputa. Se eles mudarem algo na LAI, vai valer para as informações obtidas e usadas a partir do momento da mudança, mas não para o que veio antes (a menos que se instaure uma ditadura com censura).

Vou estudar um pouco sobre obras derivadas.

Se me permite insistir no ponto da CGU, acho que está havendo um mal entendido.
A LAI só diz respeito ao acesso – não diz nada a respeito se eu posso vender os dados, ou importar no OSM, etc.
Ainda que a LAI não restrinja o uso e repasse da informação, ela também não permite nada disso explicitamente.
Portanto o uso e redistribuição de dados públicos está num limbo legal.
Cada órgão/instituição/programa pode definir o que quiser.
De fato, um levantamento preliminar:
https://docs.google.com/spreadsheet/ccc?key=0AuI95wETyqQidF95QUhNZlQ4c0FTcGxnZFBaUEwzYnc&usp=sharing
indica que há várias políticas de licenciamento de dados públicos em uso no governo brasileiro,
com variações muito grandes na sua maturidade de abertura legal.
Pior ainda do que a adoção de licenças restritivas, são os caso em que
não há orientação nenhuma, pois não podemos supor nada.

-F.

Em dados, como o OSM, licenciados sob a ODbL:

  • obra é diferente de banco de dados (BD)
  • a ODbL não define obra derivada apenas BD derivado e obra produzida
  • obras produzidas sempre constituem um BD coletivo
  • compartilhamento-identico (share-alike) see aplica apenas a BD derivados, nao a BD coletivos
  • exemplos:
    • obras produzidas: PNG, JPG, mapa impresso.
    • BD derivados: Planet OSM
    • incertos (dependem se constituem substanciais ou nao): KML, resultado de geocodificacao, etc.

Para outros dados, nao sob a ODbL: preciso pesquisar.

-F.

Meus dois centavos: importem / produzam os dados de endereçamento primeiro, pois é mais útil para mais contextos (embora isso seja muito subjetivo), além de ser renderizado no mapa.

[]s

Concordo, porém infelizmente esta importação está suspensa, pendente esclarecimento dos termos de licenciamento, veja no wiki: [http://wiki.openstreetmap.org/w/index.php?title=WikiProject_Brazil/RS/Porto_Alegre/Status#Importação_automatizável].
-F.

Oops, por mim ela nao estah suspensa nao :P. Soh nao fiz porque pretendo fazer depois de concluir as rotas dos onibus (e nao conclui porque meu HD principal falhou no meio da semana, estou recuperando o meu sistema).

Se houver algum problema legal, eh muito facil reverter a importacao depois. Considerando que ninguem correu pra responder a minha mensagem e que a pagina nao tem avisos de copyright, suspeito (fortemente) que nao havera problema nenhum.

Se houver problemas, entao podemos usar a regra da distancia para gerar uma numeracao aproximada e ir consertando aos pouquinhos. :smiley: Claro que dai podemos usar esse mapa do LABGEO para saber quao rigidamente essa regra eh respeitada e tambem para obter algumas “boas indicacoes” sobre onde faz mais diferenca consertar manualmente. :stuck_out_tongue:

Mas nao quero misturar as tarefas. A do transporte publico jah esta muito alem dos 80% feita, entao prefiro conclui-la antes.

Falha de hd dá medo só de pensar…

Então quando há incerteza na licença de um dado governamental vamos supor que estão em domínio público?
Isso é uma interpretação ousada – não que eu discorde, dado a inércia do governo, mas há um risco do pessoal do osm-bulk-imports recusar…

Ótima notícia.

Abc,
-F.

Mais uma iniciativa similar:
http://trafeguebem.com.br/
http://portoimagem.wordpress.com/2012/04/09/lancado-novo-site-do-transporte-em-porto-alegre-trafegue-bem/

Eu arrisco dizer que, considerando a inércia do nosso governo, é provável que algo melhor que o OSM já tenha surgido quando finalmente se derem conta de que os dados foram copiados. :stuck_out_tongue:

Mas eu concordo e sempre me preocupei com a legalidade do meus atos. O único problema é a falta de cooperação. É tão ruim isso que eu acho menos arriscado importar “com a possibilidade de voltar atrás sem perder muito trabalho” (no caso, os endereços tendem a sofrer pouca alteração) do que ficar esperando que as instituições resolvam o nosso impasse tendo a boa vontade de responder às nossas perguntas. No fundo, acho que a tarefa de importação deveria ser responsabilidade do governo, já que é tudo informação pública em algum nível, e mais: informação essa gerada por órgãos do próprio governo na forma de placas, estradas, faixas de trânsito, certamente registradas na forma de projetos e cadastros de estabelecimentos, etc. Enfim.

Por outro lado também entendo que o governo não tem interesse em ser o único provedor da informação, nem tem interesse comercial sobre ela, e talvez até prefira que o trabalho de obter e manter a informação seja “terceirizado” para a população. É um custo e uma responsabilidade a menos. Eu certamente vejo vantagens pro governo em todos os cenários que eu consigo imaginar.

Procurei por rotas de onibus de Curitiba no OSM e nao encontrei… usei até o JOSM com o plugin Public Transport – pode me dar uma dica?

Valeu,
-F.

O pessoal de Curitiba não fez da mesma forma, só geraram o feed GTFS (mas não sei como). Fazendo assim, o feed fica no servidor OTP, e não no mapa do OSM (ou seja, a informação do feed não fica pública, nem editável). Isso na verdade é um problema a longo prazo (que deveria ser solucionado, e não deve ser difícil fazer uma interface web para editar o feed, podemos fazer ao final). Dentro da proposta do OTP nacional, seria melhor ainda porque atenderia não só a nós mas ao país inteiro.

Estou tomando como exemplo cidades como Buenos Aires e Zurique, onde a importação foi completa, com as rotas importadas também no mapa do OSM.

Por sorte, acho que vamos ganhar ajuda de um aluno de graduação em computação da UFRGS, e talvez consigamos implantar um servidor OTP para prova de conceito lá também. Se for esse o caso, Felipe, te chamo um dia para ir olhar o resultado lá. A idéia daí é replicar a prova de conceito num servidor aberto como tínhamos planejado inicialmente. (Mas quem sabe, se tivermos sorte, a própria UFRGS pode fornecer o serviço? Vou tentar negociar.)