Transporte público em Porto Alegre

Resolvi abrir esse post porque um usuário me procurou no wiki interessado no assunto. Então, aos interessados de Porto Alegre e região (e também aos visitantes :D).

É possível baixar as paradas de ônibus de Porto Alegre e as descrições das rotas a partir do site do PoaTransporte em formato JSON. Descobri isso analisando as requisições HTTP com o Firebug. As URLs seguem abaixo.

Lista de linhas de ônibus (com IDs):
http://www.poatransporte.com.br/php/facades/process.php?a=nc&p=%&t=o

Lista de linhas de lotação (com IDs):
http://www.poatransporte.com.br/php/facades/process.php?a=nc&p=%&t=l

Rota (somente o traçado) de uma linha de ônibus ou lotação (a partir de um ID obtido da lista):
http://www.poatransporte.com.br/php/facades/process.php?a=il&p=[ID]

Lista e posição dos pontos de táxi:
http://www.poatransporte.com.br/php/facades/process.php?a=tx&p=[AREA]

Lista e posição das paradas de ônibus e as linhas que passam por cada parada:
http://www.poatransporte.com.br/php/facades/process.php?a=tp&p=[AREA]

A área para a cidade completa é “((-30.27,-51.30),(-29.92,-50.97))” (sem aspas). Não deve ser usado com frequência para não saturar os servidores deles. Os IDs mudam de tempos em tempos, mas não sei se mudam todos juntos (não faria sentido guardar os IDs) ou se mudam só as linhas que sofreram alteração de percurso (faria algum sentido). Talvez seja mais interessante uma correspondência por valores em outras tags (número da linha e sentido, por exemplo).

O primeiro problema com os dados do PoaTransporte/EPTC é que as paradas foram posicionadas sobre o traçado das ruas no Google, que é menos preciso que o do OSM. Se as paradas forem importadas sem qualquer tratamento adicional, muitas das paradas vão acabar parando do lado errado da rua. Assim, não fugimos de primeiro importar as rotas. Tendo as rotas, um script simples poderia reposicionar as paradas facilmente no lado certo e também já criar as relações das rotas incluindo não só os trechos percorridos como também as paradas em que cada ônibus pára. Isso nos daria não apenas as paradas como também a camada de transporte estaria completa incluindo os números das linhas (exemplo perto de onde eu moro na zona sul: http://www.openstreetmap.org/?lat=-30.10769&lon=-51.24203&zoom=16&layers=T)). Mas esbarramos na necessidade de primeiro importar as rotas (são cerca de 450 se contarmos ida, volta e cada variação como rotas diferentes).

Eu fiz um script que tenta criar as relações a partir das descrições textuais das rotas no site da EPTC, mas ainda assim sobra muito trabalho manual. Andei pensando em explorar o uso da ferramenta de conflação do JOSM para tentar importar as rotas mais rapidamente.

Mas tem duas coisas que precisam ser feitas antes das rotas: o mapeamento dos corredores de ônibus e o remapeamento de ruas simples que deveriam ser vias separadas (segundo os critérios para “dual carriageway” da comunidade do OSM). Ou fazemos isso antes, ou teremos bastante retrabalho depois. Prefiro fazer isso antes porque sei que iniciantes têm dificuldades com relações (frequentemente excluem membros de alguma relação sem saber, o Potlatch não avisa quando o objeto é membro de uma relação ao deletar). Senão, pode acontecer o que já aconteceu aqui no centro, rotas quebradas: http://www.openstreetmap.org/?lat=-30.10769&lon=-51.24203&zoom=16&layers=T

Então, a sequência de tarefas seria esta:

  • mapear os corredores de ônibus (usados por dezenas de linhas)
  • remapear as ruas que deveriam ser vias separadas (as que têm divisor físico ou legal (= faixa contínua) entre os dois sentidos)
  • importar as relações das rotas (manualmente, ou com o auxílio parcial de um script que eu já vinha desenvolvendo)
  • importar as paradas de ônibus (corrigindo automaticamente o lado da rua por script) + completar as relações das rotas incluindo as paradas associadas (fácil de fazer no mesmo script)

Por fim, alguém tentou mapear alguns corredores segundo o “novo esquema” de transporte público do OSM (http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport). Mas fez o trabalho pela metade e abandonou no meio do caminho. Como penso que os dados do OSM seriam primariamente usados pelo OpenTripPlanner, investiguei o suporte que eles têm aos dois formatos e me pareceu que o formato antigo (com um nó simples highway=bus_stop) é o mais bem suportado. Essencialmente, o novo modelo permite diferenciar entre o ponto de parada do ônibus e a plataforma (que poderia incluir não só ônibus como também outros meios de transporte na mesma parada - bondes, por exemplo). Faz sentido em outros países onde há “hubs” multimodais. Aqui à princípio não teria vantagens e teria a complexidade de exigir uma relação associando a plataforma e a parada. Assim, acho que faz mais sentido mapear tudo no modelo “antigo” (que é mais fácil de manter) e migrar o necessário para o novo à medida que for necessário e que formos testando essas ferramentas.

Aceito idéias e ajudadores. :smiley:

Oi Fernando. Obrigado pela resposta detalhada. As solicitações JSON foram geniais.

O meu interesse principal eh na roteirizacao, nem tanto no mapeamento. Me corrija se estiver errado, mas nesse caso a topologia eh mais importante do que a geometria da rede. Entao se uma parada estiver conectada na ordem certa ao longo de uma linha de onibus, nao teria problema a posicao dela estar do lado errado da rua.

Tenho a intencao de preparar a roteirizacao no formato GTFS, e depois usar no OSM/OTP atraves do gtfs-osm-sync. Essa ferramenta inclusive ajudaria na resolucao de conflitos geometricos durante a fusao dos dois mapas. Veja em <https://code.google.com/p/gtfs-osm-sync/>.

Se for realmente necessario corrigir as informacao geometrica das rotas, gostaria antes de confirmar essa afirmacao sobre a precisao do Google vs. OSM. Usei a estacao de rastreio GPS do IBGE em POA, cujas coordenadas estao disponiveis em <ftp://geoftp.ibge.gov.br/RBMC/relatorio/Descritivo_POAL.pdf> e cuja posicao eu conheco no campo. Comparando OSM e GMaps, os dois parecem igualmente bons:

<http://www.openstreetmap.org/?mlat=-30.0740424488844&mlon=-51.1197647812323&zoom=20&layers=T&layer=transportmap>

<https://maps.google.com/maps?q=±30.0740424488844,±51.1197647812323&hl=en&ll=-30.073886,-51.119654&spn=0.000704,0.001106&sll=-21.962459,-51.353596&sspn=0.773094,1.132965&t=h&z=20>

Abc,
-F.

Olá Felipe,

Peço que você não as importe ainda porque o OpenStreetMap serve a vários públicos simultâneos (não somente aos interessados em roteamento, embora esse seja o meu interesse principal). Se uma parada estiver do lado errado da rua, é muito provável que algum novato a acabe excluindo simplesmente por não ter o discernimento necessário (isso significa mais trabalho manual pra nós depois). Note que o OSM e o OTP são projetos independentes (embora muito próximos um do outro). O feed GTFS pode acabar sendo bem diferente das relações de rota no OSM (a única coisa sincronizada é as paradas de ônibus, pelo que lembro de ter lido).

O que eu fiz: depois de baixar o JSON com as coordenadas, fiz um script em Python que as converteu para um arquivo .osm, abri como camada no JOSM junto com a camada do mapa de Porto Alegre, e com isso percebi que várias paradas estavam do lado errado da rua, mesmo na região central da cidade.

Compare os dois mapas sobrepostos usando este site: http://sautter.com/map/?zoom=17&lat=-30.03248&lon=-51.23032&layers=B000TFFFFTTF

Você já tem algum lugar para hospedar o servidor OTP?

Outra coisa: eu teria interesse em ajudar se o serviço for oferecido sem fins lucrativos. Qual o seu interesse?

Pretendo replicar o formato do transportespublicos.pt – inclusive fiz uma doacao para o financiamento coletivo deles.

Detalhando mais: a minha ideia eh construir um prototipo inicial com apenas dez linhas de onibus, demonstrando o conceito de roterizacao por transporte publico. Para a implantacao completa, eu nao teria tempo de realizar, realisticamente falando. Tambem nao acho justo ficar explorando voluntarios como voce. Entao talvez o mais viavel seja um financiamento coletivo para pagar a terceirizacao desse servico. Para a posterior manutencao continua dos dados assim como hospedagem do servidor e aluguel de banda, talvez anuncios sejam suficientes para pagar as contas. Mas tudo isso ainda eh especulacao. O prototipo seria o proximo passo.

Parece que ha um deslocamento uniforme na direcao norte-sul. Teria que obter as coordenadas GPS de alguns pontos de controle notaveis no mapa e comparar. Veja p.ex. http://wiki.openstreetmap.org/wiki/Quality_assurance#External_compares.

Ok, se for para pagar a hospedagem, concordo com os anúncios. Acho que seria justo ser bem transparente, publicando os custos da hospedagem e o valor arrecadado com propagandas e/ou doações.

Você me dá 1 dia para investigar isso? Eu penso que vale à pena o esforço de fazer a importação completa (inclusive a geração do feed GTFS), e acho que com o processo de conflação (que eu aprendi há pouco tempo) é possível. Temos que pensar como esses dados serão atualizados sem esforço: se os IDs do PoaTransporte mudam, o sincronizador que você indicou funcionaria? Ou será que substituiria todo o conjunto de dados a cada vez? (o que seria péssimo para o OSM e certamente levaria à suspensão da nossa conta de usuário)

Ainda estou investigando o sincronizador. Esse relatorio aqui eh bem completo: <http://www.nctr.usf.edu/wp-content/uploads/2011/06/77926.pdf>. Algumas licoes pertinentes:

Fiz um teste agora. Acho que funcionará do jeito que eu estou pensando: o trabalho manual é quebrar tanto as ruas do OSM quanto os trajetos da EPTC nos pontos certos para que a conflação encontre as correspondências certas. Outra coisa que eu confirmei é que a conflação combina membros de relações, que era o que eu mais precisava (economiza muito tempo). Vou importar algumas rotas completas hoje à noite e ver quanto tempo levo com esse novo método. Suspeito que dá pra fazer em menos de 1 semana.

Justamente, eu achava que a sincronização do traçado das rotas seria perigoso se não usasse uma inteligência muito avançada. Pelo que lembro, em Israel, eles importaram só as paradas de ônibus, a rota ficou armazenada no próprio feed. Aqui, a idéia de importar as rotas é:

  • poder desenhá-las na camada de transporte (para quem vai usar o mapa offline)
  • poder corrigir a localização das paradas de ônibus, colocando do lado certo da rua

O que podemos extrair do PoaTransporte é uma linha contínua (sem quebras e sem conexões com as ruas existentes) e o que o OSM armazena são relações agrupando trechos de ruas. Se houvesse uma maneira simples de sincronizar a linha com as relações, nem teríamos essa discussão, o trabalho já estaria feito. :smiley: Mas uma vez importadas, é fácil fazer alterações manualmente, e também é fácil identificar as alterações nos dados do PoaTransporte. Um teste geométrico razoavelmente simples poderia detectar uma variação significativa entre a rota no OSM e a linha extraída do PoaTransporte, e isso já serviria para nos avisar de 99,9% das alterações.

Na verdade, o caminho contrário (do OSM para o GTFS) é o mais fácil. Se a EPTC atualizasse o OSM ao invés dos seus sistemas antiquados, o feed GTFS poderia ser gerado a partir do OSM automaticamente. Seria muito menos trabalho, pra própria EPTC, e para nós. Eles também poderiam gerar facilmente o itinerário textual das linhas.

Uma questão: a EPTC não tem os horários dos ônibus por parada, e isso parece ser um requisito num feed GTFS:

https://developers.google.com/transit/gtfs/reference#stop_times_fields

Poderíamos gerar horários fictícios por simulação (talvez usando o OSRM para calcular os tempos) assumindo uma velocidade média em torno de 40km/h.

Falando em GTFS, achei no meio das minhas anotações uma referência pra esta ferramenta que converte dados do OSM em feeds GTFS: OSM2GTFS (https://github.com/sakarp/osm2gtfs)

Dependendo de como montarmos o nosso workflow, deve ser muito mais fácil atualizar o OSM e gerar o feed GTFS a partir dele do que atualizar o feed na mão ou mesmo a partir dos dados da EPTC. Podemos investigar.

OK, apesar da minha relutancia inicial, voce me convenceu a respeito de arrumar as vias do OSM antes de importar as rotas/paradas da EPTC. Copiei e expandi a sua lista de tarefas: http://wiki.openstreetmap.org/wiki/Talk:WikiProject_Brazil/RS/Porto_Alegre/Status#TO-DO.

Parece entao que seria mais facil integrar OSM e OTP via GTFS?
Isso envolveria adotar o novo modelo de dados para transporte publico do OSM.

Essa biblioteca Java tb parece uma boa para nao sujar as maos com o formato GTFS:
http://developer.onebusaway.org/modules/onebusaway-gtfs-modules/current/

Alias, encontrei isso agora:
http://www.vakinha.com.br/Vaquinha.aspx?e=34277
http://wp.clicrbs.com.br/vanessanunes/tag/poabus-com-br/?topo=69,1,1,40

Na verdade o OTP só funciona se for fornecido um feed GTFS completo (incluindo os horários, pelo que li). Podemos usar esse validador pra saber se estamos montando o feed do jeito certo: https://code.google.com/p/googletransitdatafeed/wiki/FeedValidator

Que interessante essa biblioteca. Vou tentar usá-la. Você programa em alguma linguagem? Eu me sinto um pouco mais confortável em Python (menos requisitos pra que as coisas saiam funcionando) mas se precisar fazer em Java eu me viro. :smiley:

Hahaha achei ótimo o sistema da vaquinha, por mim podemos adotar sim. :smiley:

Que bom, assim fico um pouco mais tranquilo. Atualizando, consegui converter todas as rotas para o formato OSM com os IDs e fiz a conflação de uma delas para saber quais seriam os requisitos da parte manual, que são:

  • abrir todas as rotas de mesmo sentido (centro > bairro ou vice-versa) juntas
  • fazer as quebras nas ruas e nas rotas (todas de uma vez só em cada operação)
  • fazer a conflação (funcionou super bem)
  • rodar o plug-in do transporte público para corrigir a direção dos membros (algumas precisam ser mudadas de forward pra backward quando a rua tem oneway=-1)

Eu peguei uma rota que mudou recentemente e ela ainda não está atualizada no PoaTransporte. Daí eu fui conferir os nomes das rotas na EPTC e parece que as tabelas deles são um pouco diferentes das do PoaTransporte (tem linhas em um que não tem no outro e vice-versa), não sei qual dos registros está mais atualizado. Sugiro então que, no final de tudo isso, a gente compare os itinerários da EPTC com os itinerários do OSM (serão listas de nomes de ruas) para ver onde estão as diferenças. É possível que o PoaTransporte esteja desatualizado.

Na verdade, para monitorar alterações de percurso e para aplicar alterações manuais, é mais fácil monitorar alterações dos itinerários no site da EPTC (que são texto puro) do que fazer aquele teste geométrico nas rotas do PoaTransporte. Se descobrirmos que a EPTC tem essa informação mais atualizada que o PoaTransporte, vale à pena. Um tempo atrás eu fiz um script que extrai os itinerários textuais deles automaticamente, então já tenho 95% de tudo que preciso pra fazer essa monitoração. Um dos problemas com o cadastro da EPTC é que as descrições das ruas está meio caótica… Mas como a manutenção seria manual, não teria problema. :stuck_out_tongue:

Como eu fiquei fazendo essas conversões e análises, no fim só consegui operar em cima de 1 rota (só pra testar o processo). Hoje à noite eu faço um conjunto maior, daí submeto pra te mostrar como está ficando, ok?