Transporte público em Porto Alegre

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?

OK, atualizei a lista de tarefas para refletir a impossibilidade da conexao direta OSM-OTP, sem o intermedio do GTFS:
http://wiki.openstreetmap.org/wiki/Talk:WikiProject_Brazil/RS/Porto_Alegre/Status#TO-DO