Quando un passeggero cerca come arrivare da un punto A a un punto B, nella maggior parte dei casi non apre l'app dell'operatore. Apre Google Maps, oppure Moovit. Se il tuo servizio non compare in quei calcolatori, per una parte consistente dell'utenza il servizio non esiste, anche se l'autobus passa puntuale ogni dodici minuti.
Pubblicare i propri dati verso i calcolatori di percorso generalisti è una delle attività con il miglior rapporto tra sforzo e risultato per un'azienda di TPL. È anche una delle meno documentate in italiano. Questa guida descrive il percorso operativo, passo per passo.
I due livelli: statico e tempo reale
La distinzione da fissare subito, perché determina l'ordine dei lavori.
Il livello statico descrive il servizio programmato: linee, fermate con coordinate, orari, calendario di esercizio. Il formato è il GTFS, un insieme di file di testo compressi in un archivio. È il requisito di ingresso: senza GTFS valido non si pubblica nulla, né su Google Maps né su Moovit.
Il livello in tempo reale descrive cosa sta accadendo adesso: posizione dei veicoli, ritardi previsti, avvisi di servizio. Il formato più diffuso verso i calcolatori generalisti è il GTFS-RT, che si aggiunge al GTFS statico e vi fa riferimento.
Un errore frequente è cercare di partire dal tempo reale. Non funziona: il GTFS-RT identifica corse e fermate usando gli identificativi del GTFS statico. Se il livello statico non è pulito, il tempo reale non è interpretabile.
Passo 1: preparare un GTFS valido
Questo è il passo che richiede più tempo e che viene sistematicamente sottovalutato. I file essenziali sono pochi:
- agency.txt, i dati dell'azienda
- stops.txt, le fermate con coordinate geografiche
- routes.txt, le linee
- trips.txt, le corse
- stop_times.txt, gli orari di ogni corsa a ogni fermata
- calendar.txt e calendar_dates.txt, i giorni di esercizio e le eccezioni
I problemi che emergono quasi sempre alla prima produzione sono cinque: coordinate delle fermate imprecise o invertite, fermate duplicate con nomi diversi, identificativi che cambiano tra un aggiornamento e il successivo, calendario che non modella correttamente festivi e periodi scolastici, e assenza di shapes.txt, che rende i percorsi disegnati sulla mappa delle linee rette tra fermate.
Gli identificativi stabili meritano un'attenzione particolare. Se stop_id e trip_id cambiano a ogni pubblicazione, il tempo reale si aggancia al vuoto e le statistiche storiche diventano inconfrontabili. Fissare una convenzione prima di produrre il primo file costa un'ora, cambiarla dopo costa una ricostruzione.
Passo 2: validare prima di inviare
Esistono validatori GTFS pubblici, e il più usato è quello mantenuto dalla comunità MobilityData. Va usato prima di qualunque contatto con i calcolatori, per un motivo pratico: un feed con errori bloccanti viene rifiutato, e ogni ciclo di rifiuto e ripresentazione aggiunge settimane.
La distinzione utile è tra errori e avvisi. Gli errori vanno risolti, sono bloccanti. Gli avvisi indicano qualità del dato, non validità formale, e alcuni si possono accettare consapevolmente. Vale la pena documentare quali si sono accettati e perché, così la prossima persona che tocca il feed non li tratta come regressioni.
Passo 3: pubblicare il GTFS a un URL stabile
I calcolatori non vogliono un file inviato per email. Vogliono un indirizzo web pubblico da cui scaricare il feed periodicamente, in autonomia.
Tre requisiti:
- URL fisso, che non cambia a ogni aggiornamento
- Aggiornamento automatico, non una pubblicazione manuale che qualcuno dimentica
- Disponibilità continua, perché un feed non raggiungibile per giorni viene progressivamente deprioritizzato
Se il servizio cambia con il calendario scolastico o stagionale, l'aggiornamento va programmato con anticipo rispetto all'entrata in vigore. I calcolatori hanno bisogno di tempo per ingerire il feed, e un orario nuovo pubblicato il giorno prima non sarà visibile il giorno dopo.
Passo 4: registrarsi presso i calcolatori
Google Maps. La pubblicazione avviene attraverso il programma per i partner del trasporto pubblico di Google, che prevede una registrazione dell'ente o dell'azienda e la dichiarazione dell'URL del feed. Google verifica il feed, chiede correzioni se necessario, e dopo l'approvazione ingerisce il dato periodicamente. Il primo ciclo richiede tipicamente alcune settimane, in gran parte dipendenti dalla velocità con cui si risolvono le richieste di correzione.
Moovit. Moovit dispone di un percorso analogo per gli operatori e le autorità che vogliono fornire dati ufficiali. La logica è la stessa: feed valido, URL stabile, verifica, ingestione. Vale la pena procedere in parallelo e non in sequenza, perché la preparazione del dato è comune ai due.
Un punto che genera confusione: in molti casi il servizio compare già su Moovit o su Google Maps prima di qualsiasi registrazione, ricostruito da fonti di terze parti o da contributi degli utenti. Quel dato è spesso incompleto o obsoleto. Registrare un feed ufficiale serve anche a sostituirlo, non solo ad aggiungere qualcosa che non c'era.
Passo 5: aggiungere il tempo reale con GTFS-RT
Il GTFS-RT si compone di tre tipi di flusso, indipendenti tra loro:
- Trip updates, i ritardi e le previsioni di passaggio corsa per corsa. È il flusso che produce l'effetto più visibile per il passeggero.
- Vehicle positions, la posizione dei veicoli in circolazione. Alimenta la visualizzazione sulla mappa.
- Service alerts, gli avvisi testuali su deviazioni, soppressioni e interruzioni.
Si possono pubblicare separatamente e in tempi diversi. Se si deve scegliere da dove iniziare, i trip updates hanno l'impatto maggiore, perché cambiano il numero che il passeggero legge.
Due condizioni tecniche non negoziabili. La prima: i riferimenti nel GTFS-RT devono corrispondere esattamente agli identificativi del GTFS statico pubblicato. La seconda: il flusso deve aggiornarsi con una frequenza compatibile con l'uso, tipicamente nell'ordine delle decine di secondi. Un flusso in tempo reale aggiornato ogni cinque minuti è tecnicamente valido e praticamente inutile.
GTFS-RT o SIRI: quale serve
La risposta breve è che in Italia servono entrambi, per destinatari diversi.
GTFS-RT è il formato che i calcolatori generalisti consumano. Se l'obiettivo è comparire su Google Maps e Moovit, è questo.
SIRI è lo standard europeo per l'interscambio in tempo reale tra sistemi, ed è quello che tipicamente richiedono le committenze pubbliche, le agenzie regionali e i nodi di accesso ai dati. I profili più usati sono il monitoraggio delle fermate, il monitoraggio dei veicoli e lo scambio delle situazioni di perturbazione.
In pratica un'azienda di TPL italiana finisce per esporre GTFS-RT verso il mondo consumer e SIRI verso la committenza. I due flussi devono derivare dallo stesso dato di esercizio, altrimenti il ritardo dichiarato all'agenzia e quello mostrato al passeggero divergono, ed è una discussione che nessuno vuole avere.
Gli errori che fanno perdere più tempo
- Coordinate delle fermate approssimative. Su Google Maps una fermata spostata di cinquanta metri manda il passeggero dall'altra parte della strada.
- Identificativi instabili tra un aggiornamento e l'altro. Rompe il tempo reale in modo silenzioso.
- Calendario di esercizio non modellato. Produce corse fantasma nei giorni festivi e nei periodi di sospensione scolastica.
- Pubblicare il tempo reale prima di aver stabilizzato lo statico. È l'inversione dell'ordine, e comporta rifare il lavoro.
- Nessun monitoraggio del feed. Se il feed cade e nessuno se ne accorge, il servizio scompare dai calcolatori e la segnalazione arriva dai passeggeri.
Domande frequenti
Quanto tempo serve per comparire su Google Maps?
A dato pulito, l'ordine di grandezza è di alcune settimane tra registrazione, verifica e ingestione. Quando i tempi si allungano, la causa è quasi sempre la qualità del GTFS, non la lentezza del calcolatore.
Serve un'app dell'operatore se si pubblica su Google Maps e Moovit?
Non come primo passo. Per la maggior parte delle reti la pubblicazione verso i calcolatori generalisti raggiunge molti più passeggeri, con un costo di gestione molto inferiore. Un'app propria ha senso quando serve un canale controllato, per esempio su servizi scolastici o in abbonamento.
Si può pubblicare solo il GTFS statico, senza tempo reale?
Sì, ed è il punto di partenza corretto. Il servizio diventa visibile e pianificabile. Il tempo reale si aggiunge dopo, sullo stesso impianto.
Chi mantiene il feed nel tempo?
È la domanda più importante e la meno posta. Un feed è un impegno continuo, non una consegna. Va assegnato a un ruolo, con un aggiornamento automatico e un controllo di disponibilità, altrimenti si degrada entro un anno.
Da dove partire
Se oggi non pubblichi nulla, la sequenza è questa: produrre un GTFS statico corretto, validarlo, esporlo a un URL stabile con aggiornamento automatico, registrarsi presso Google e Moovit in parallelo, e solo dopo aggiungere il GTFS-RT partendo dai trip updates.
Se vuoi confrontarti su un caso concreto di pubblicazione di dati in tempo reale verso i calcolatori di percorso, incluso il connettore SIRI verso la committenza, il team di Pysae è disponibile per una sessione tecnica sui dati della tua rete.