Ai passeggeri non importa nulla della tua architettura dati. Importa una cosa sola: l'autobus sta davvero arrivando, e quando? GTFS-RT (l'estensione in tempo reale dello standard GTFS) è ciò che trasforma la posizione GPS dei tuoi autobus in quella risposta — sull'app, sul display alla fermata, su Google Maps. Ma tra il veicolo su strada e lo schermo del passeggero devono accadere correttamente molte cose. Ecco come funziona nella pratica, e dove tende a rompersi.
Dal ping GPS allo schermo del passeggero
Ogni autobus dotato di Pysae invia la propria posizione regolarmente — di norma ogni 30 secondi. Quella posizione grezza è solo un punto su una mappa. Per diventare un'informazione utile in tempo reale deve essere associata al servizio pianificato: quale linea, quale corsa, quale fermata viene dopo e come si confronta con l'orario. Questo passaggio di associazione è dove risiede l'intelligenza. Una posizione senza contesto non dice nulla al passeggero; una posizione legata a «Linea 3, 4 minuti di ritardo, arriva alla tua fermata tra 6 minuti» ne cambia l'intera esperienza.
I tre tipi di flusso GTFS-RT
GTFS-RT non è una cosa sola — sono tre flussi correlati, e la maggior parte delle reti ha bisogno di tutti e tre:
- Trip Updates: orari di arrivo e partenza previsti per fermata. È ciò che alimenta il «prossimo bus tra 4 min».
- Vehicle Positions: la posizione in tempo reale di ogni veicolo, per il tracciamento sulla mappa.
- Service Alerts: interruzioni, deviazioni e cancellazioni, in un testo che il passeggero legge.
Un errore frequente è pubblicare solo Vehicle Positions (quello facile) e tralasciare Trip Updates. Ma le previsioni sono ciò che i passeggeri vogliono davvero — un punto in movimento senza orario di arrivo è un giocattolo, non un servizio.
Perché i flussi vengono rifiutati (e come evitarlo)
Il problema più frequente nella pratica non è generare il flusso, ma il fatto che la piattaforma ricevente (un planner di viaggio regionale, Google, un'app di terze parti) lo rifiuti. Quasi sempre per le stesse ragioni:
- Il flusso in tempo reale fa riferimento a ID di fermata o di corsa che non esistono nel GTFS statico. I due devono restare sincronizzati — quando cambia l'orario, entrambi si aggiornano insieme.
- Le marche temporali sono obsolete o nel fuso orario sbagliato, così le previsioni sembrano congelate o senza senso.
- Il flusso si convalida tecnicamente ma le previsioni sono enormemente imprecise, il che erode la fiducia più in fretta dell'assenza di dati.
La soluzione è disciplina: il piano statico e il flusso in tempo reale devono provenire dalla stessa fonte di verità. Quando la pianificazione della rete e le operazioni in tempo reale vivono sulla stessa piattaforma, questa sincronizzazione è automatica anziché una fragile riconciliazione manuale.
Standard oltre GTFS-RT
In Europa, GTFS-RT convive spesso con SIRI (lo standard europeo in tempo reale) e, in Francia, con i requisiti regionali dell'AOM. Una rete può aver bisogno di pubblicare la stessa verità di fondo in più formati contemporaneamente. L'implicazione pratica: scegli strumenti che esportino verso tutti gli standard richiesti dal tuo mercato da un unico motore in tempo reale, anziché mantenere un processo separato per ogni formato.
Un punto in tempo reale senza un orario di arrivo preciso non è informazione in tempo reale
In sintesi
GTFS-RT nella pratica riguarda meno lo standard in sé e più il mantenere il servizio pianificato e le operazioni in tempo reale perfettamente allineati, per poi esportare in modo pulito verso tutti i canali che i passeggeri usano. Se azzecchi quella sincronizzazione, il resto è idraulica. È esattamente per questo che Pysae genera i flussi GTFS-RT, SIRI e ITxPT direttamente dalla stessa piattaforma che gestisce le tue operazioni — un'unica fonte di verità, ogni schermo alimentato automaticamente.