Il GTFS statico
Il formato GTFS "statico" descrive la struttura della rete del trasporto pubblico: le linee, le corse programmate, le fermate ecc.
A Roma, prima ancora dell'avvento del GTFS, la vecchia Atac (quando Atac fungeva da Agenzia della mobilità) aveva costruito un formato interno per rappresentare la rete. Nel 2010 buona parte della vecchia Atac è stata trasformata in Roma servizi per la mobilità (RSM), e il formato della rete è stato ereditato da RSM. I sistemi tradizionali di Atac/RSM, come Atac mobile e muovi.roma.it, sono stati costruiti sulla base di questo formato, la cui struttura essenzialmente è la seguente:
- Gestori (Atac, Roma TPL, Trenitalia)
- Ogni gestore esercisce una o più linee
- Ogni linea ha uno o più percorsi (andata, ritorno, andata scolastica, ritorno prolungato ecc.) - ogni aggettivo che concorre a qualificare un percorso è chiamato, in gergo, carteggio
- Le paline di fermata presenti sul territorio
- Ogni percorso è descritto tramite una sequenza di fermate, ognuna presso una palina di fermata
- Per ogni percorso sono programmate diverse corse, ciascuna con un orario (data ed ora) di partenza e un orario di arrivo - il formato tradizionale RSM non descrive gli orari di passaggio alle fermate intermedie.
Il formato GTFS ha una struttura in qualche modo simile, ma che differisce dal formato RSM per alcuni dettagli significativi. Troviamo infatti le seguenti tabelle:
- agencies, corrispondenti ai gestori (nonostante il nome)
- routes, corrispondenti alle linee (nonostante il nome)
- trips, corrispondenti alle corse
- stops, corrispondenti alle paline sul territorio (nonstante il nome)
- stop_times e shapes, di cui parleremo tra un attimo.
Che cosa manca? Il concetto di percorso, ahimé! Infatti il GTFS, in modo brusco, passa dalle linee alle corse. Mancano completamente:
- la suddivisione di una linea in percorsi
- l'enumerazione delle fermate di ogni route (cosa che d'altronde non sarebbe possibile in assenza del concetto di percorso, in quanto ogni corsa svolge un percorso potenzialmente diverso: corse di andata, di ritorno, deviate ecc. fanno capo tutte alla stessa linea)
Il GTFS sopperisce a questo brusco salto linea --> corsa tramite la tabella stop_times, in cui elenca le fermate di ogni singola corsa! Il GTFS considera dunque ogni corsa un caso a sé: ne elenca una ad una le fermate, specificando anche l'orario di passaggio alla fermata.
Chiunque abbia studiato Basi di dati arriccerà il naso, osservando che il formato GTFS non è normalizzato. Ciò causa una certa ridondanza, perché il GTFS richiede di ripetere la sequenza delle fermate per ogni corsa (quando sarebbe stato sufficiente indicare il percorso della corsa, e aggiungere solo gli orari di passaggio alle fermate). Cosa ancor più grave, i percorsi non hanno un'identità propria, e quindi non hanno un nome, né un identificatore, né i carteggi. Perché per il GTFS, i percorsi non esistono.
Possiamo "ricostruire" il concetto di percorso? Certamente, tramite una di queste due tecniche:
- analizzando le fermate di ogni corsa, e mettendo "a fattor comune" tutte le corse che fanno la medesima sequenza di fermate; oppure
- tramite lo
shape_id di ogni corsa.
Veniamo quindi alla tabella shapes. La finalità originaria di questa tabella è mostrare le corse su mappa. Ogni corsa è legata dunque a una "forma geometrica" (in gergo chiamata polilinea o linestring), descritta nella tabella shapes e denotata da un identificatore shape_id. Poiché tutte le corse che fanno lo stesso percorso hanno la stessa mappa, se il GTFS è costruito bene avranno anche lo stesso valore per lo shape_id. Possiamo quindi considerare ogni shape_id come l'identificatore di un percorso!
I punti deboli dello shape_id sono però i seguenti:
- gli
shape_id non hanno degli aggettivi che li caratterizzano. Non potremo mai distinguere un percorso "normale" da uno scolastico
- gli
shape_id non hanno neanche una linea... per determinare la linea, dobbiamo cercare una corsa che lo percorre, e vedere a quale linea tale corsa è associata.
Il GTFS realtime
Le peculiarità del GTFS statico si riflettono anche sul formato GTFS realtime, che descrive l'andamento delle corse in tempo reale. Uno dei modi per analizzare i dati in tempo reale è considerare i messaggi di VeiclePosition, che indicano la posizione dei veicoli. La posizione di ogni veicolo è descritta relativamente alla corsa che il veicolo sta effettuando, identificata tramite l'attributo trip_id. Per comprendere su quale percorso il veicolo si trovi, è necessario aver analizzato il GTFS statico, e aver mappato ogni trip_id nel relativo percorso compiuto (ad esempio tramite lo shape_id associato alla corsa).
Nei prossimi post mostreremo come Roma mobile effettua queste operazioni.
