Transporte público em Porto Alegre

Talvez vc queira botar uma lenha na fogeira la:

https://groups.google.com/d/msg/thackday/hQ-LB65xhDY/wC7foijZFm4J

Contar da sua experiencia com o OSM vs. IBGE e tal…

Abc,
-F.

Postei! :smiley:

Só pra constar, se o site da EPTC está mesmo mais atualizado que o do PoaTransporte, então as seguintes mudanças aconteceram:

Linha 4732 (PoaTransporte) substituída pela 4733
Linha 4922 pela 492
Linha 476 pela 4763

Parecem ter sido mudanças da empresa responsável por operar a linha. Vou tentar o contato com uma amiga que já trabalhou na EPTC pra confirmar. Esse delay é bem provável. Tem uma linha (a 173) cuja rota eu conheço bem e que mudou há um certo tempo (por causa das obras na Padre Cacique) e ela ainda está com o traçado antigo (passando pelo trajeto em obras) no PoaTransporte.

Depois de ver o caos que é o registro de nomes de linhas da EPTC, decidi fazer uma revisão do formato do nome das linhas de ônibus. Conversei com algumas pessoas e parece que o formato geral tende a ser este:

partida_aproximada_1 - partida_aproximada_2 (via_1 / via_2 /…) / chegada_aproximada_1 - chegada_aproximada_2 [dias]

Traduzindo:

  • “A - B” significa “linha vai para A, mais especificamente para B perto de A”
  • “A (B / C)” significa “linha vai para A passando por B e C no meio do caminho”
  • “A [domingos, feriados]” significa “linha A aos domingos e feriados”

O registro da EPTC quebra essa regra algumas vezes (marca com “/” lugares que não são destinos finais, muda a ordem das coisas). Isso acontece com mais frequência nas linhas não radiais (A’s, T’s, D’s, etc.). Pra esclarecer mais do que confundir, tentei aproximar o máximo possível desse formato sem mudar a ordem das palavras; é bem provável que a ordem seja a mesma nos letreiros dos ônibus, embora em algumas linhas que eu conheço melhor eu já sei que não é igual. Terminado isso vou pedir pra amigos revisarem. O ideal mesmo seria dar o nome que aparece no letreiro.

Se você quiser acompanhar o status da revisão (comecei ela ontem à noite): https://docs.google.com/spreadsheet/ccc?key=0Aut_CDnmHfE7dDQ2SWc0STdlV29VUW1PWFlfZ0xEY3c#gid=0

Dei permissão para deixar comentários na própria planilha, mas pode fazer aqui também. Ah, e comecei de trás pra frente (foi a ordem com que o JOSM carregou os arquivos :P).

Faltou acrescentar a coluna com as rotas. Vou revisar no final, mas tive a impressão de que esse formato não se aplica tão bem a rotas que são circulares.

Será q vai dar muito trabalho atualizar o OSM qnd a EPTC atualizar o PoaTransporte?

Se você puder listar algumas tarefas atômicas – não no sentido de explosivas, mas de serem auto-contidas. Confesso que atualmente não sei nem por onde começar… Desde coisas mais braçais, do tipo conversão em planilha, até mais complexas, como JSON.

Valeu.
-Felipe.

Praticamente terminei a revisão dos nomes, se você quiser dar uma olhada, questionar, opinar, passar para outras pessoas, fique à vontade (quanto mais gente dando opinião, melhor). Pretendo fazer uma última revisão ainda mais tarde.

O trabalho é bastante complexo. Eu comecei a pensar em como poderia quebrar em operações atômicas (mas não explosivas :P) que eu pudesse delegar (a você ou a outras pessoas também) mas no fim acho bem difícil fazer isso, o processo é todo intrincado. Na tentativa de entender como eu faria isso, eu desenhei um workflow quebrando as tarefas e os produtos intermediários: http://i.imgur.com/bm9Sdw9.png

Hoje eu comecei o balão “quebras manuais”. Praticamente tudo aí até os balões “script” é melhor ficar comigo porque eu já fiz scripts que lêem essas fontes de dados (é só adaptar para cada caso, o mais difícil é interpretar os dados da fonte e isso eles já fazem). Eu já tinha os scripts há alguns meses, só não tinha mergulhado no processo porque ainda não conhecia a conflação.

Eu poderia talvez dividir os arquivos .osm que eu gerei com você ou com mais pessoas, mas mesmo isso não é tão eficiente, o mais rápido é fazer todas as quebras (nas ruas e nas rotas) de uma vez só, visualizando todas as rotas sobrepostas, e daí é melhor que uma pessoa só faça. Eu queria tentar fazer com apenas 3 changesets: um para as quebas das ruas, outro para as relações das rotas, e um último para as paradas. Assim fica muito fácil reverter se for necessário.

Algo que poderia ser visto em paralelo é a configuração do servidor OTP (deve ter bastante configuração para ler). Você poderia tentar instalar ele no seu computador. Teria que ser num sistema Linux porque esse será o ambiente em qualquer web hosting que conseguirmos depois. Eu tinha olhado um serviço dedicado da Bluehost, e o ambiente deles seria um CentOS, então um provável atalho pra fazer testes seria instalar um CentOS numa VM, e daí instalar o OTP no CentOS, e daí jogar no OTP os arquivos que eu estou gerando. Quando chegasse a hora de colocar no ar, bastaria repetir os mesmos passos no web host que contratarmos.

Links pra baixar o CentOS via Torrent:
http://mirror.centos.org/centos/6.4/isos/i386/CentOS-6.4-i386-bin-DVD1to2.torrent
http://mirror.centos.org/centos/6.4/isos/x86_64/CentOS-6.4-x86_64-bin-DVD1to2.torrent

Poderíamos tentar também conseguir um ambiente pro OTP nos servidores de alguma universidade (UFRGS ou PUC ou Unisinos), ou até com a Prefeitura. O único problema é que, quando foge do controle de alguém da comunidade, a comunidade perde o poder de fazer correções e manter o serviço atualizado, que é o principal poder do crowdsourcing.

Ah, lembrei que você mencionou o OSM2GTFS. De repente você podia testar a ferramenta em outra cidade que já tenha as rotas e as paradas mapa, só pra saber como ela funciona e como podemos usá-la.

  • descobri a Open Source Routing Machine (OSRM, <http://wiki.openstreetmap.org/wiki/OSRM>) e confirmei com o pessoal do TransportesPublicos.pt que “o OSRM procura simplesmente o caminho mais curto, o OTP tem em conta a especificidade dos transportes públicos. Isto é, o caminho percorrido por um autocarro não é necessariamente o mais curto entre dois pontos, existem horários que devem ser cumpridos e diversos modos de transporte que só se podem combinar em pontos específicos (paragens/estações) etc.”

  • atualizei a lista de tarefas, adicionando links para as possibilidades de ferramentas para ajudar na automatizacao (osm2gtfs, etc.) tb separei a tarefa de numeracao das vias; tb tentei incorporar as info q estavam no teu diagrama; veja o resultado em <http://wiki.openstreetmap.org/w/index.php?title=Talk%3AWikiProject_Brazil%2FRS%2FPorto_Alegre%2FStatus&diff=927302&oldid=925703>

  • sobre a importacao das rotas, nao ficou claro se vc esta usando o PoaTransporte/JSON ou os itinerarios da EPTC em texto puro – ou ambos?

  • baixei o OTP.

Estou usando ambos PoaTransporte e EPTC. A EPTC fornece os dados em arquivos HTML, eu converto para texto puro para poder trabalhar os dados mais facilmente nos scripts.

Os dados do PoaTransporte não incluem a informação da empresa responsável (que serve para preenche a tag “operator” na relação da rota com, por exemplo, “STS” ou “Carris”) e a informação da direção da rota é indicada num sufixo do código da linha (algo que não existe no registro da EPTC). Por exemplo, a linha 127-2 do PoaTransporte é a linha 127 da EPTC no sentido Bairro > Centro. O problema é que só o “-2” não significa muita coisa, em várias linhas ele significaria Bairro > Terminal ao invés de Bairro > Centro e num caso particular ele significa Sul > Norte, em outras várias linhas ele nem sequer existe (só o “-1”), que pode ser ainda mais coisas (é usado, por exemplo, para as linhas circulares). Acho isso uma complicação desnecessária, mas já que eles decidiram fazer assim, no mínimo podiam ter incorporado a direção textual num campo extra no JSON, mas não fizeram.

Muito interessantes os links que você colocou na lista de tarefas. Vou olhar eles um por um assim que terminar de importar as rotas.

Decidi dar uma olhada se eu estava fazendo tudo segundo os padrões adotados por outros países, e daí acabei fazendo uma última alteração. Eu estava preenchendo os campos “from” e “to” com as direções “centro”, “bairro” ou “terminal” de acordo com a informação no início dos itinerários da EPTC, mas em todos os outros países essa informação sempre é o nome de um terminal ou de uma estação. A EPTC tem essa informação no início e no final de cada itinerário (embora poucas pessoas a usem), então para seguir o padrão decidi usá-la e daí colocar a direção (centro/bairro, bairro/centro, etc.) no campo “description”.

Uma coisa que você pode fazer é criar uma página do wiki específica para o transporte em Porto Alegre (sugiro esta: http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/RS/Porto_Alegre/Transporte)) baseando-se no modelo de outras cidades (http://wiki.openstreetmap.org/wiki/Buses#Buses_by_city). Analisei algumas e me parece que na Suíça eles seguiram bem o padrão do wiki (http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport) enquanto que em outros lugares há variações (algumas ruins, como o uso do caractere Unicode “→” na França e na Itália) e coisas que nunca ganharam popularidade (como a tag “line” na Alemanha). Estou me espelhando mais no modelo Suíço por causa disso. Para o wiki, me parece que tanto a cidade de Zurich (mais organizada) quanto a de Buenos Aires (mais fácil de manter) estão bem estruturadas, seriam bons pontos de partida.

Você pode também já criar uma subpágina (sugiro http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/RS/Porto_Alegre/Transporte/Atualizacoes)) para que eu possa escrever um roteiro de como atualizar esses dados (rotas, paradas, feeds GTFS, etc.) quando a informação na EPTC e no PoaTransporte muda. Se quiser pode preencher alguma coisa como as suas principais dúvidas (coisas do tipo “como detectar alterações”, “o que fazer quando muda o terminal de uma rota”, “o que fazer quando a rota muda de código”, etc.). Se possível, também colocar links para todas essas páginas na página principal (http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/RS/Porto_Alegre).

Brasilia esta usando (parcialmente) o OSM para transporte publico:

<http://www.sistemas.dftrans.df.gov.br/horarios/src/mapas/index>

Parcialmente pq parece q o OSM so serve de pano de fundo.
Pesquisei as relacoes com o JOSM e so encontro linhas de metro:
http://wiki.openstreetmap.org/wiki/Bras%C3%ADlia_Metro

Parece que as linhas de onibus estao em arquivos externos:
http://www.sistemas.dftrans.df.gov.br/horarios/src/extras/mapa.js

-F.

Opa, nao tinha recebido notificacao dessa msg. Vou mexer nisso no final de semana.

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.