Em junho de 2026, a STCP passou a mostrar no Google Maps a posição dos autocarros e a hora estimada de chegada às 2 517 paragens da rede, segundo a própria STCP e a agência Lusa. Para um operador, o que o passageiro vê no telemóvel é a ponta de uma cadeia de dados: o Sistema de Apoio à Exploração (SAE) tem de associar cada autocarro à viagem certa, calcular previsões e publicá-las num formato que a aplicação consiga ler. Este artigo explica o que essa cadeia exige e o que um operador deve verificar antes de publicar.
O que anunciou a STCP em junho de 2026?
A STCP indicou que a informação em tempo real da sua exploração ficou disponível no Google Maps. O passageiro introduz a origem e o destino, escolhe um itinerário que inclua a STCP e vê quantos minutos faltam para a chegada do autocarro. Segundo a STCP, a cobertura abrange as 2 517 paragens e mais de 5 000 viagens num dia útil. A empresa refere ainda mais de 60 ecrãs de tinta eletrónica (e-papers) no Porto, a que se juntam e-papers em Vila Nova de Gaia, e apresenta a novidade como um complemento aos canais que já existiam, como o sítio da empresa.
Há uma nuance de datas: a página da STCP tem data de 5 de junho de 2026, enquanto a Lusa, publicada pelo Observador, fala em disponibilização a partir de terça-feira, 9 de junho de 2026. Nos textos consultados não é indicado o formato dos dados enviados ao Google. Tudo o que se segue sobre formatos é, por isso, explicação geral sobre como este tipo de integração funciona, e não uma descrição da arquitetura da STCP.
Segundo a Lusa, a STCP tinha apontado o final de 2024 para esta informação chegar ao Google Maps, o que não veio a acontecer.
Que dados precisa uma aplicação de mapas para mostrar um autocarro?
Uma aplicação de mapas combina duas camadas. A primeira é o horário planeado: paragens, linhas, viagens e calendários, normalmente em GTFS. A segunda é o tempo real, normalmente em GTFS-RT (GTFS Realtime), que descreve o que está a acontecer em cada viagem.
A especificação GTFS-RT define três tipos de informação, descritos na documentação do Google:
- Trip updates: atrasos, cancelamentos e alterações de percurso;
- Service alerts: paragens deslocadas e acontecimentos imprevistos;
- Vehicle positions: posição dos veículos e, quando existe, o nível de lotação.
Segundo a documentação do Google sobre atualizações de trânsito em tempo real (Live Transit Updates), o feed tem de estar num local onde o Google o possa recolher periodicamente e tem de ser atualizado com regularidade. A mesma página indica que a atualização ideal acompanha a chegada de novos dados do sistema de localização de veículos. O Google não fixa, nessa página, uma frequência mínima.
Porque é que a ligação entre viagem planeada e viagem real é o ponto crítico?
Num feed de trip updates, o essencial é dizer a que viagem planeada cada previsão se refere. Segundo a documentação do GTFS, na maioria dos casos deve fornecer-se o trip_id da viagem planeada no GTFS a que a atualização diz respeito. Para viagens baseadas em frequência, o trip_id sozinho não chega: é preciso também a hora de início e a data de início.
A mesma documentação indica que deve existir, no máximo, uma atualização por viagem planeada e que as atualizações de paragens devem estar ordenadas por stop_sequence. Cada atualização de paragem liga-se a uma paragem por stop_sequence ou por stop_id.
Na prática, isto significa que o tempo real é tão bom quanto a coerência com o GTFS estático. Se o horário publicado ao público tem um identificador de viagem e o SAE trabalha com outro, a previsão não consegue ser ligada à viagem certa. O mesmo acontece quando a paragem do GTFS e a paragem do SAE não coincidem.
O que deve um operador verificar antes de publicar em tempo real?
Esta lista de verificação resulta das exigências acima e do bom senso de exploração. Não é uma lista oficial.
- Identificadores coerentes. O trip_id e o stop_id do feed em tempo real têm de existir no GTFS estático em vigor.
- Calendário atualizado. Alterações de horário, épocas escolares e exceções devem estar no GTFS antes de entrarem em serviço, para que as previsões não apontem para viagens que já não existem.
- Associação de cada autocarro à viagem. Quando o motorista inicia o serviço, o SAE tem de saber que viagem está a ser feita. Sem essa associação, o SAE não consegue ligar a posição à viagem planeada.
- Tratamento de cancelamentos e desvios. Uma viagem que não circula deve ser sinalizada como tal, e um desvio deve gerar um aviso de serviço, em vez de deixar o passageiro à espera de um autocarro que não vem.
- Atualização regular. O feed deve acompanhar os dados do sistema de localização, tal como pede a documentação do Google.
- Comparação entre canais. A hora mostrada no e-paper, na aplicação do operador e no Google Maps deve ser a mesma. Quando diferem, o passageiro deixa de confiar nos três.
- Responsável pela qualidade. Alguém na exploração deve acompanhar regularmente se as previsões batem com a realidade.
Como é que isto se aplica quando há vários operadores na mesma área?
Numa área metropolitana, o passageiro não pensa em operadores: pensa em origem e destino. Se um operador publica tempo real e outro não, ou se o fazem com níveis de qualidade diferentes, o mapa fica desigual. Por isso, a coerência de identificadores e de calendários entre operadores é tão importante como a tecnologia de cada um.
Como se liga isto ao SAE e à plataforma Pysae?
O módulo Pysae Operations assenta na supervisão em tempo real: um mapa em direto com atrasos, avanços e regularidade das linhas, alertas e incidentes, e GTFS-RT para o Google Maps e plataformas MaaS. É este o tipo de função que corresponde à camada de tempo real descrita acima.
Do lado do horário planeado, o módulo Pysae Network permite editar paragens, horários e linhas diretamente no mapa e exportar GTFS e NeTEx certificados, com calendários e exceções para épocas escolares, horários de verão e feriados.
Para compreender os três fluxos GTFS-RT em detalhe, leia também GTFS-RT na prática: do GPS ao ecrã do passageiro. Esse artigo explica o mecanismo geral; o presente texto parte de um caso português recente e de uma lista de verificação para operadores.
Quando faz sentido pedir uma demonstração?
Se o seu operador já publica tempo real, mas as previsões diferem da realidade, ou se ainda não publica e quer saber o que preparar, uma demonstração permite ver como o planeamento, a supervisão e as exportações se ligam. Pode pedi-la através do botão de pedido de demonstração do sítio.
Perguntas frequentes
Que dados a STCP disponibiliza no Google Maps?
Segundo a STCP, a posição dos autocarros e a hora estimada de chegada às 2 517 paragens da rede, com cobertura de mais de 5 000 viagens num dia útil. A STCP e a Lusa dão datas ligeiramente diferentes para o início (5 e 9 de junho de 2026).
O Google Maps usa GTFS-RT?
A documentação do Google sobre atualizações de trânsito em tempo real descreve o uso de feeds GTFS Realtime, com horários de partida em tempo real e alertas de serviço. Os textos consultados sobre a STCP não indicam o formato usado por esta empresa.
Porque é que o trip_id é tão importante?
Porque liga a previsão em tempo real à viagem planeada no GTFS. Segundo a documentação do GTFS, na maioria dos casos deve indicar-se o trip_id da viagem a que a atualização diz respeito. Se os identificadores não coincidem, a previsão não chega ao passageiro.
É preciso GTFS estático para ter tempo real?
Sim, na prática. O tempo real descreve desvios em relação a um horário planeado, por isso o horário planeado tem de estar publicado e coerente.
Um operador pequeno pode fazer o mesmo?
A lógica é a mesma para qualquer dimensão: horário planeado coerente, associação do autocarro à viagem, feed atualizado e verificação regular da qualidade. O que muda é o volume de viagens e de paragens a gerir.
Fontes: STCP, «STCP's message arrives on Google Maps in real time» (stcp.pt, 5 de junho de 2026); Lusa/Observador, «STCP disponibiliza horários dos autocarros em tempo real no Google Maps a partir desta terça-feira» (9 de junho de 2026); Google for Developers, documentação GTFS Realtime e Live Transit Updates; gtfs.org, documentação de trip updates.