Os passageiros não querem saber da sua arquitetura de dados. Querem saber uma coisa: o autocarro vem mesmo, e quando? O GTFS-RT (a extensão em tempo real da norma GTFS) é o que transforma a posição GPS dos seus autocarros nessa resposta: na app, no painel da paragem, no Google Maps. Mas entre o veículo na estrada e o ecrã do passageiro há muita coisa que tem de correr bem. Eis como funciona na prática, e onde costuma falhar.
Do sinal GPS ao ecrã do passageiro
Cada autocarro equipado com o Pysae envia a sua posição a intervalos regulares. Essa posição em bruto é apenas um ponto no mapa. Para se tornar informação útil em tempo real, tem de ser associada ao serviço planeado: que linha, que viagem, que paragem vem a seguir e como isso se compara com o horário. É nesta associação que está a inteligência. Uma posição sem contexto não diz nada ao passageiro; uma posição ligada a «Linha 3, 4 minutos de atraso, chega à sua paragem dentro de 6 minutos» muda toda a sua experiência.
Os três tipos de fluxo GTFS-RT
O GTFS-RT não é uma coisa só: são três fluxos relacionados, e a maioria das redes precisa dos três:
- Trip Updates: horas previstas de chegada e partida por paragem. É isto que alimenta o «próximo autocarro em 4 min».
- Vehicle Positions: a localização em direto de cada veículo, para o acompanhamento no mapa.
- Service Alerts: perturbações, desvios e supressões, em texto que o passageiro lê.
Um erro comum é publicar apenas Vehicle Positions (o mais fácil) e ignorar Trip Updates. Mas as previsões são o que os passageiros realmente querem: um ponto em movimento sem hora de chegada é um brinquedo, não um serviço.
Porque são rejeitados os fluxos (e como evitá-lo)
O problema mais frequente na prática não é gerar o fluxo, é a plataforma recetora (um planeador de viagens regional, a Google, uma app de terceiros) rejeitá-lo. Quase sempre pelas mesmas razões:
- O fluxo em tempo real refere identificadores de paragens ou de viagens que não existem no GTFS estático. Os dois têm de se manter sincronizados: quando o horário muda, ambos são atualizados em conjunto.
- Os carimbos temporais estão desatualizados ou no fuso horário errado, pelo que as previsões parecem congeladas ou absurdas.
- O fluxo é tecnicamente válido, mas as previsões são muito imprecisas, o que destrói a confiança mais depressa do que a ausência de dados.
A solução é disciplina: o plano estático e o fluxo em tempo real têm de vir da mesma fonte de verdade. Quando o planeamento da rede e a exploração em tempo real estão na mesma plataforma, esta sincronização é automática em vez de uma frágil conciliação manual.
Normas para além do GTFS-RT
Na Europa, o GTFS-RT coexiste frequentemente com o SIRI (a norma europeia de tempo real) e com os requisitos dos pontos de acesso nacionais e das autoridades de transportes. Uma rede pode ter de publicar a mesma informação de base em vários formatos ao mesmo tempo. A implicação prática: escolha ferramentas que exportem para todas as normas exigidas pelo seu mercado a partir de um único motor de tempo real, em vez de manter um processo separado por formato.
Um ponto em direto sem uma hora de chegada precisa não é informação em tempo real: é decoração.
Em resumo
O GTFS-RT na prática tem menos a ver com a norma em si e mais com manter o serviço planeado e a exploração em direto perfeitamente alinhados, exportando depois de forma limpa para todos os canais que os passageiros usam. Acerte nessa sincronização e o resto é canalização. É exatamente por isso que o Pysae, com o módulo Operations, gera os fluxos GTFS-RT e SIRI diretamente a partir da mesma plataforma que gere a sua exploração, e é compatível com ITxPT a bordo: uma única fonte de verdade, todos os ecrãs alimentados automaticamente.
Perguntas frequentes
Quais são os três fluxos GTFS-RT?
O Trip Updates fornece as horas previstas de chegada e partida por paragem, o Vehicle Positions a localização em direto de cada veículo e o Service Alerts as perturbações, desvios e supressões em texto. A maioria das redes precisa dos três, e o Trip Updates é o fluxo que os passageiros mais valorizam.
Porque é que um planeador de viagens ou a Google rejeita um fluxo GTFS-RT?
Na maior parte dos casos, porque o fluxo em tempo real refere identificadores de paragens ou de viagens que não existem no GTFS estático. Carimbos temporais desatualizados ou no fuso horário errado são a outra causa habitual. Um fluxo também pode ser tecnicamente válido com previsões muito imprecisas, o que destrói a confiança.
Como se mantêm sincronizados o GTFS estático e o GTFS-RT?
Ambos têm de vir da mesma fonte de verdade e ser atualizados em conjunto sempre que o horário muda. Quando o planeamento da rede e a exploração em tempo real estão na mesma plataforma, esta sincronização é automática em vez de uma frágil conciliação manual.
As redes europeias precisam do SIRI além do GTFS-RT?
Muitas vezes, sim. Na Europa, o GTFS-RT coexiste frequentemente com o SIRI e com os requisitos dos pontos de acesso nacionais e das autoridades de transportes, pelo que a mesma informação pode ter de ser publicada em vários formatos. O Pysae gera os fluxos GTFS-RT e SIRI a partir da mesma plataforma que gere a exploração.