Transporte público em Porto Alegre

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

Alguns detalhes:

Frequencies are used when a line does not have set arrival and departure times, but instead services run with a set interval. Frequencies are defined in the file frequencies.txt, and are associated with a Trip definition. https://support.google.com/transitpartners/answer/1106431?hl=en

When trips are defined in frequencies.txt, the trip planner ignores the absolute values of the arrival_time and departure_time fields for those trips in stop_times.txt. Instead, the stop_times table defines the sequence of stops and the time difference between each stop. https://developers.google.com/transit/gtfs/reference#frequencies_fields

Detalhei a lista de tarefas, desmembrando a informacao temporal entre frequencia de viagens e diferenca de tempo entre paradas; coloquei tb uma proposta de como obter cada uma dessas informacoes:
http://wiki.openstreetmap.org/wiki/Talk:WikiProject_Brazil/RS/Porto_Alegre/Status#TO-DO

Imploro que a proposta trivial seja adotada antes da mais rigorosa…

Na verdade eu queria chamar atencao pra essa iniciativa de 2010. Quem sabe convidar aquele desenvolvedor pro esforco atual. E tb ressaltar o risco de inviabilidade financeira da manutencao do projeto, depois que os desafios tecnicos tiverem sido superados na implementacao…

Acho que o nosso maior obstáculo vai ser o valor utilidade que as pessoas vão atribuir a um sistema que nem tem números de casas. É possível/provável que falhe por causa disso. Talvez a PROCEMPA tenha esses dados, nunca tentei um contato com eles. Se não tiver, uma coisa que certamente temos que fazer antes de colocar no ar pro grande público é escrever um tutorial fácil sobre como cadastrar esses números corretamente e deixar um link bem visível na página principal.

Eh verdade, nao tinha me dado conta da falta da numeracao das ruas. Isso vai exigir que o usuario clique no mapa (ou use o GPS do celular) para indicar o ponto de partida/chegada. Eh uma limitacao severa – vou ter que reconsiderar…

Pessoal,

Se ajudar vocês, posso fazer uma ponte com um amigo meu, portoalegrense, que certamente tem muitos dados sobre as rotas de ônibus em Porto Alegre. Inclusive acho que ele tentou fazer algo aqui pelo OSM e desistiu por alguma razão, não me lembro qual, talvez seja ele quem tenha começado esse trabalho e deixado pela metade.

Qualquer coisa é só me contactar por mensagem!

Algumas informacoes:

http://www.nctr.usf.edu/wp-content/uploads/2011/06/77926.pdf:
ADDRESS RANGE AND LOCATION FILE: OSM users document address ranges for roads [10, pp. 86‐87] by recording an address at each end of a road segment and then indicating that address values between the endpoints are to be interpolated along the road. Tags used for addressing begin with the prefix addr:, as in
addr:housenumber=
.*

E isso tambem:
http://www.ecologia.ufrgs.br/labgeo/arquivos/downloads/dados/Diagnostico_Ambiental_POA/cd/Conteudo_do_Cd.pdf
Eixos de ruas do município de Porto Alegre, contendo os logradouros registrados nos mapas 1:15.000, 1: 10.000, 1:5.000 ou 1:1.000 e/ou cadastrados no CDL - Cadastro de Denominação de Logradouro.

http://www.ecologia.ufrgs.br/labgeo/arquivos/downloads/dados/Diagnostico_Ambiental_POA/cd/Base_cartografica_UTM_SAD69/eixos_ruas__UTM_SAD.zip
*Shape file eixos_ruas.shp (eixos de ruas do município de Porto Alegre, fornecidos pela prefeitura)

  • Smf_i_i: campo numérico contendo a numeração inicial do lado ímpar de cada segmento de eixo de rua
  • Smf_i_f: campo numérico contendo a numeraçào final do lado ímpar de cada segmento de eixo de rua
  • Smf_p_i: campo numérico contendo a numeração inicial do lado par de cada segmento de eixo de rua
  • Smf_p_f: campo numérico contendo a numeração final do lado par de cada segmento de eixo de rua
  • Categoria: campo do tipo texto (string) contendo a categoria de cada eixo de rua
  • Preposicao: campo do tipo texto (string) contendo a preposição que fica entre a categoria e o nome de cada eixo de rua
  • Nome: campo do tipo texto (string) contendo o nome de cada eixo de rua
  • Avreviat: campo do tipo texto (string) contendo uma abreviatura de cada eixo de rua
  • Cep: campo numérico contendo o CEP de cada trecho de eixo de rua
  • Grupo_cep: campo numérico contendo o grupo de CEP de cada trecho de eixo de rua*

Dava para comecar a usar essa versao para testar, e depois pedir uma versao atualizada para a Procempa, para so entao fazer a importacao.

Como sera que esses dados alteram a lista de tarefas?

Exato. Infelizmente aqui não se tem o mesmo costume na Argentina (que também tem mapas com números de casa faltando ou errados). Lá eles geralmente se referem ao cruzamento de duas ruas, não ao endereço. (Se for pensar a fundo, é bem mais fácil e rápido lembrar de um lugar assim do que com número de endereço.)

Eu já coloquei a numeração em três lugares: Avenida Guaíba (é um caso excepcional, com numeração maluca), a Avenida Otto Niemeyer (meu primeiro laboratório) e a Avenida Bastian. Nessa última, fiz com inspeção (caminhando) registrando os números e a posição com o GPS do celular. Não é difícil. Estou pra fazer o upload das 2 ruas paralelas, que eu coletei numa caminhada de menos de 1 hora. Acho que pode-se fazer 1 bairro inteiro em 4 horas. Eu faria, se não estivesse agora envolvido com essa questão do transporte. Indo de carro e de dupla (um motorista e um anotando os números), dá pra fazer até mais (só é necessário parar em cada esquina e gastar com a gasolina).

Mas pode ser que tudo isso seja em vão e que a PROCEMPA ou a Prefeitura já tenha essa informação, fácil ou razoavelmente fácil de importar. Talvez eles tenham de forma textual (por exemplo, entre as ruas A e B na rua C a numeração vai de X a Y do lado esquerdo e de W a Z do lado direito). Se conseguirmos um contato por lá, poderíamos pensar numa importação disso também e o problema estaria resolvido.

Cara, que fantástico isso! Estou num conflito agora: importo primeiro as rotas e as paradas ou os números das casas? Ambos demandam um certo tempo, mas o da numeração das casas pode ser automatizado.

Mandei um e-mail pro Instituto de Geologia perguntando se esses dados têm licença de uso ou copyright e, se tiverem, se podemos conseguir uma autorização para publicá-los através do OSM. Acredito que temos sim, mas é bom verificar.

Na UFRGS so tem Inst. Geociencias, Depto. de Geologia. Mas aquele trabalho foi feito no Inst. Biociencias, Centro de Ecologia, Laboratorio de Geoprocessamento. Veja contatos em http://www.ecologia.ufrgs.br/labgeo/index.php?option=com_content&view=article&id=9&Itemid=12. Nao adianta contatar burocratas na secretaria ou diretoria, melhor falar com alguem que entende do assunto, como o Hasenack ou o Weber.

Mas no PDF de documentacao dos dados esta dito que: Eixos de ruas: Material original cedido em meio digital pela Prefeitura Municipal de Porto Alegre, através da Procempa. Entao a UFRGS nao pode responder pelos dados produzidos pela PMPA.

Sugiro a gente se preocupar com a parte tecnica em paralelo a essa questao juridica, pois ela pode demorar. Supondo conseguirmos copia atualizada desses dados de eixo numerados das vias atraves da Lei de Acesso a Informacao, nao sei se essa lei poe restricoes no uso ou repasse das informacoes acessadas. Teria que perguntar em grupos de discussao especificos. P.ex., as bases do IBGE vem sendo importadas no OSM, veja esforcos semelhantes em http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Importa%C3%A7%C3%B5es e http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Importa%C3%A7%C3%B5es/Prefeituras.