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.