Come è noto, Roma mobile è un fork della versione originale di Muoversi a Roma (muovi.roma.it, per brevità muoviroma), progetto open source dell'agenzia Roma servizi per la mobilità (RSM).
Per funzionare, muoviroma riceve i dati in tempo reale dai gestori del trasporto pubblico: Atac e Roma TPL. La descrizione della rete del trasporto pubblico è invece aggiornata dai tecnici della stessa RSM, con grande cura e dedizione, anche più volte al giorno.
D'altra parte Roma mobile non ha rapporti diretti con i gestori. Riceve sia la descrizione della rete, sia i dati realtime, dalle fonti open data di RSM.
In origine Roma mobile si affidava completamente alle API di muoviroma per alimentarsi. Questo comporta però due problemi:
- i dati realtime di muoviroma provenienti dai gestori, specie Atac, hanno una qualità mediocre
- RSM ha deprecato le API di muoviroma, che presto potrebbero diventare inaccessibili.
Il nuovo formato scelto da RSM per gli open data è il GTFS, formato proposto da Google e utilizzato dalle agenzie di trasporto in tutto il mondo. Passare dalle API di muoviroma al GTFS è meno banale di quanto possa sembrare, perché la filosofia dei due formati differisce significativamente. Prima di proseguire, ti raccomando di leggere la descrizione dei due formati e delle differenze di approccio.
Roma mobile ha scelto di passare al GTFS in modo incrementale.
Fase 1: API statiche, GTFS realtime
Come accennato, la criticità delle vecchie API di muoviroma è legata ai dati realtime dei gestori, specie di Atac: veicoli indicati in ritardo di 4-5 fermate, veicoli non individuati, e qualche veicolo "fantasma" indicato su un percorso ma non realmente in esercizio. I dati del GTFS realtime hanno una qualità nettamente superiore.
D'altronde, la descrizione statica della rete su muoviroma è estremamente curata, e non trova un riscontro adeguato nel GTFS statico. Abbiamo pensato, in una fase di transizione, di prendere "il meglio dei due mondi":
- la rete prodotta dai tecnici RSM, tramite le API di muoviroma
- i veicoli in tempo reale dal GTFS.
Purtroppo i due formati non si parlano affatto: gli identificatori non corrispondono, e nel GTFS manca completamente il concetto di "percorso".
Analisi statica
Abbiamo quindi realizzato un algoritmo che, analizzando il GTFS statico, lo fa corrispondere alla rete RSM:
- Ricostruisce il concetto di "percorso" usando lo
shape_id delle corse del GTFS statico
- Associa ogni
shape_id ad un percorso RSM, analizzando la sequenza delle fermate di una delle corse associate allo shape_id.
Sostanzialmente, tentiamo di mappare ogni percorso del GTFS (ricostruito) in un percorso RSM (effettivo e dotato di nome e carteggio). Idealmente due percorsi sono uguali se hanno la stessa sequenza di fermate.
La corrispondenza però non è sempre perfetta: abbiamo riscontrato numerosi disallineamenti tra le sequenze di fermate. A volte cambia il codice di una fermata, a volte c'è una fermata in più o in meno, magari perché i due file sono stati aggiornati in momenti diversi. Ecco che il nostro algoritmo di matching, per ogni shape_id, si fa via via più tollerante, fino a trovare il percorso di RSM che più gli assomiglia (entro certi limiti). La corrispondenza è stabilita!
Gestione dei veicoli in tempo reale
Come si alimenta Roma mobile dal GTFS realtime? Tramite i messaggi di VeiclePosition, rileva la posizione dei veicoli. Per ogni veicolo utilizza:
- La corsa
trip_id che sta effettuando, a cui fa corrispondere uno shape_id, e quindi il percorso RSM su cui si trova, tramite le tabelle di corrispondenza costruite con l'analisi statica
- Le coordinate geografiche del veicolo
- Il numero di fermate effettuate dal veicolo
Il numero di fermate fornisce un'informazione poco accurata, sia perché non determina l'esatta posizione del veicolo tra due fermate consecutive, sia perché, come abbiamo visto, il percorso RSM può differire lievemente dal percorso GTFS. Usiamo quindi le coordinate geografiche del veicolo per determinarne l'esatta posizione, proiettandola sul punto più vicino del percorso RSM che il veicolo sta percorrendo. Il numero di fermate effettuate è utile per disambiguare alcuni casi complessi, come quello di percorsi che si auto-intersecano o linee pseudo-circolari in cui il bus torna indietro sui suoi passi in un unico percorso: in tali casi una mera istantanea delle coordinate geografiche non consente di capire in quale verso il veicolo si stia muovendo.
Roma mobile quindi calcola tutte le informazioni esposte al pubblico, quali i tempi di attesa presso le fermate successive, i calcoli di percorso ecc., a partire dalla posizione dei veicoli, tramite i collaudati algoritmi ereditati da muoviroma. Questo spiega il motivo per cui le previsioni di attesa di Roma mobile possano differire leggermente rispetto a quelle di altre app, basate sui tempi di attesa esposti nel GTFS realtime (Roma mobilità), oppure calcolate dai sistemi Atac (Viaggia con Atac, paline elettroniche), oppure ancora forniti dalle API di muoviroma.
Piccola osservazione aggiuntiva. Anche i dati del GTFS realtime presentano un ritardo, sebbene non pronunciato come quello delle vecchie API. Abbiamo riscontrato che i bus appaiono indietro di 1-2 fermate rispetto alla posizione reale. Il ritardo è dovuto a due fattori: i campioni presenti nel GTFS sono "vecchi" di alcuni minuti (solitamente 1-2 minuti, a seconda del veicolo); inoltre la cadenza di aggiornamento del GTFS realtime è di circa 30 secondi, ma in alcune circostanze si supera il minuto. Fortunatamente ogni campione dispone della marca temporale (timestamp) che specifica a quale istante di tempo si riferisce la posizione del veicolo. In questo modo abbiamo la possibilità di applicare un algoritmo correttivo che "sposta in avanti" il veicolo, utilizzando la stima della velocità nel tratto che sta percorrendo e il ritardo del campione.
Fase 2: GTFS statico, GTFS realtime
Nel prossimo futuro, Roma mobile dovrà necessariamente usare il GTFS anche per la parte statica, cioè per descrivere la rete del trasporto pubblico.
Stiamo studiando il modo migliore per mostrare i diversi percorsi di una linea, anche se questi purtroppo non dispongono di un nome "ufficiale" nel GTFS.
Inevitabilmente perderemo qualcosa in termini di completezza nella descrizione dei percorsi, a meno che RSM non fornisca queste informazioni in modo alternativo. D'altra parte, minimizzeremo la possibilità di errori perché le informazioni del GTFS realtime faranno pienamente "scopa" con la rete del GTFS statico.
