Sintesi Tecnica: Programmazi Ricorrenti del Trasporto Pubblico: Identificazione Stabile da GTFS e Analisi di Similarità

1. Definizione del Problema

Gli orari del trasporto pubblico esibiscono strutture di servizio ricorrenti in cui molteplici date condividono tabelle identiche per l'utente (ad esempio, i giorni feriali standard), mentre altre differiscono a causa di weekend, festività o eventi speciali. Tuttavia, il General Transit Feed Specification (GTFS), lo standard globale per i dati sul trasporto pubblico, non codifica esplicitamente questi "DayType" (tipi di giorno) ricorrenti. Inveve, il GTFS rappresenta il servizio attraverso tabelle interdipendenti (calendario, corse, tempi di sosta, forme), costringendo i modelli a valle per la programmazione, l'assegnazione dei veicoli e l'analisi della domanda a ricostruire oggetti di offerta ricorrenti da dati frammentati.

La sfida principale è duplice:

1. Identificazione: Come estrarre classi di servizio stabili e ricorrenti (DayType) dal GTFS senza fare affidamento su identificatori amministrativi (ad esempio, shape_id, stop_id) che possono cambiare tra i rilascio dei feed nonostante il servizio fisico rimanga costante.
2. Confronto: Come confrontare questi orari estratti per distinguere tra differenze rigorose di tabella oraria, lievi spostamenti temporali (ad esempio, un ritardo di 1 minuto) e cambiamenti strutturali sostanziali (ad esempio, rimozione o aggiunta di una tratta).

2. Metodologia

2.1. Definizioni Formali

Il documento formalizza due concetti chiave:

• Pattern di Percorso (Route Pattern): Una variante di servizio rivolta al passeggero, definita da una sequenza ordinata di fermate e una direzione di percorrenza. A differenza dello shape_id del GTFS, che è un identificatore amministrativo, un Route Pattern è definito dal percorso fisico e dall'ordine delle fermate.
• Tipo di Giorno (DayType): Una categoria di date che condividono esattamente lo stesso insieme di corse di Route Pattern che operano agli stessi orari. È definito rigorosamente come l'insieme delle specifiche delle corse: $DayType(d) = \{(p, dep_t, arr_t)\}$, dove $p$ è il Route Pattern, e $dep_t/arr_t$ sono la prima partenza e l'ultimo arrivo.

2.2. Estrazione Stabile tramite Indicizzazione H3

Per garantire la stabilità contro la ridenominazione degli identificatori amministrativi, gli autori propongono un metodo di estrazione utilizzando il sistema di indicizzazione geospaziale gerarchico H3 (Uber Technologies, 2018).

• Chiave del Pattern di Percorso: Invece di utilizzare shape_id o stop_id, il metodo converte la sequenza ordinata delle coordinate delle fermate in una sequenza di celle H3 (Risoluzione 15). Questa sequenza funge da chiave deterministica e stabile per il Route Pattern.
• Algoritmo di Estrazione:
  1. Espandere le tabelle del calendario e delle eccezioni GTFS per generare un elenco di corse attive per ogni data.
  2. Per ogni corsa attiva, convertire la sequenza di fermate in una chiave di Route Pattern basata su H3.
  3. Formare una tupla di specifica della corsa: $(H3\_key, first\_departure, last\_arrival)$.
  4. Raggruppare le date che condividono esattamente lo stesso insieme di tuple di specifica della corsa in un singolo DayType.
• Invarianza: Questo approccio garantisce che se due feed GTFS descrivono lo stesso servizio fisico ma utilizzano diversi ID amministrativi, la partizione DayType estratta rimanga identica, a condizione che le coordinate e l'ordine delle fermate rimangano invariati.

2.3. Framework di Confronto degli Orari

Il documento introduce una gerarchia a tre livelli di metriche per confrontare i DayType $A$ e $B$:

1. Metriche Esatte ($d_0$):

   • Utilizza la Distanza di Jaccard sull'insieme delle specifiche delle corse.
   • Tratta qualsiasi differenza nel Route Pattern, nell'orario di partenza o nell'orario di arrivo come un DayType distinto.
   • Funge da segnale di audit rigoroso per la qualità dei dati e gli aggiustamenti intenzionali degli orari.

2. Metriche con Tolleranza Temporale ($d_\epsilon$):

   • Introduce un parametro di tolleranza $\epsilon$ (ad esempio, 1, 3 o 5 minuti).
   • Due corse sono $\epsilon$-equivalenti se condividono la stessa chiave di Route Pattern e i loro orari di partenza/arrivo differiscono di $\le \epsilon$.
   • Calcola la distanza di Jaccard con tolleranza temporale basata sul numero massimo di coppie $\epsilon$-equivalenti.
   • Questo livello determina se le differenze esatte sono solo piccoli spostamenti temporali.

3. Diagnostica di Comparabilità Strutturale:

   • Per evitare di sovra-interpretare piccoli match come somiglianze dell'intero orario, il framework calcola:
     • Quota di Match ($M_\epsilon$): La proporzione di corse che possono essere accoppiate sotto la tolleranza.
     • Squilibrio del Conteggio Corse ($Q$): La differenza relativa nel numero totale di corse tra i due DayType.
     • Conteggio Non Corrispondente ($U_\epsilon$): Il numero di corse che non possono essere accoppiate.
   • Questo distingue tra una "versione con spostamento temporale dello stesso orario" (alto $M_\epsilon$, basso $Q$) e un "cambiamento strutturale del servizio" (basso $M_\epsilon$, alto $Q$).

3. Contributi Chiave

1. Formalizzazione: Definisce i Route Pattern e i DayType come oggetti di offerta ricorrenti, distinti dalla pianificazione amministrativa di veicoli o equipaggi.
2. Estrazione Stabile: Sviluppa una procedura di estrazione GTFS utilizzando chiavi di pattern di percorso H3 che è invariante rispetto alla ridenominazione degli identificatori amministrativi, risolvendo un problema critico di riproducibilità nell'analisi longitudinale dei GTFS.
3. Gerarchia di Confronto: Propone un sistema di metriche che separa l'audit rigoroso (esatto), la sensibilità temporale (con tolleranza temporale) e il cambiamento strutturale (diagnostica), affrontando i limiti dell'uso di una singola metrica di similarità.
4. Utilità a Valle: Fornisce set di orari ricorrenti compatti che possono servire come input per la sincronizzazione degli orari, l'assegnazione dei veicoli, l'assegnazione della domanda e i modelli di diagnosi di mismatch.
5. Validazione Empirica: Valida il framework su feed GTFS di agenzie giapponesi e canadesi, dimostrando un'estrazione efficace attraverso diverse scale di rete e strategie di codifica del calendario.

4. Risultati e Conclusioni

Il framework è stato applicato a 40 agenzie giapponesi e 38 canadesi.

• Successo dell'Estrazione: L'algoritmo ha identificato con successo i DayType ricorrenti per tutte le agenzie senza intervento manuale, recuperando i cicli settimanali standard (giorni feriali/sabato/domenica), le eccezioni delle festività e le anomalie di un singolo giorno.
• Conteggi dei DayType: Il numero mediano di DayType non vuoti per agenzia era 4 in entrambi i paesi. Tuttavia, le agenzie giapponesi hanno mostrato una maggiore variabilità (massimo 39) rispetto alle agenzie canadesi (massimo 17), riflettendo calendari più granulari per festività/stagionalità nel campione giapponese.
• Analisi della Disgiunzione:
  • Disgiunzione Esatta: Una parte significativa delle agenzie presentava coppie di DayType con zero corse condivise (distanza di Jaccard = 1.0). Ciò è stato più comune in Canada (36% delle agenzie) che in Giappone (15%).
  • Impatto della Tolleranza: Applicando una tolleranza temporale (1–5 minuti), molte coppie "esattamente disgiunte" in Canada hanno acquisito alcuni match, suggerendo che si trattava di variazioni temporali di strutture simili. In Giappone, la disgiunzione esatta è stata più persistente, indicando una separazione strutturale più forte tra i regimi di servizio.
  • Realtà Strutturale: Nonostante l'acquisizione di match sotto la tolleranza, la quota mediana di match è rimasta bassa (6,3% in Canada, 0% in Giappone) con elevati squilibri nel conteggio delle corse. Ciò conferma che molti DayType "disgiunti" rappresentano volumi di servizio o set di rotte fondamentalmente diversi, non solo orari spostati.
• Nesting (Annidamento): Il nesting completo (dove un DayType è un sottoinsieme stretto di un altro) è stato osservato nel 69% delle agenzie giapponesi e nel 58% di quelle canadesi, indicando che la riduzione graduata del servizio è una pratica comune in entrambe le regioni.

5. Significato e Rivendicazioni

Il documento posiziona il suo contributo come uno strato di rappresentazione metodologica piuttosto che come un nuovo algoritmo di ottimizzazione. La sua importanza risiede in:

• Colmare il Divario: Collega i dati GTFS grezzi e frammentati agli oggetti di offerta ricorrenti richiesti dai modelli metodologici a valle (ad esempio, analisi della funzione di deficit, pianificazione dei veicoli).
• Stabilità: Decoupling (disaccoppiamento) l'identificazione del servizio dagli ID amministrativi consente un'analisi longitudinale affidabile dell'evoluzione degli orari tra i rilasci dei feed.
• Interpretazione Sfumata: La gerarchia di metriche proposta evita la classificazione errata del rumore temporale minore come cambiamenti strutturali del servizio, pur preservando la capacità di audit delle deviazioni esatte degli orari.
• Rappresentazione Compatta: Trasforma i grandi orari specifici per data in una libreria compatta di DayType ricorrenti, facilitando una gestione più efficiente della programmazione, dell'assegnazione della domanda e dell'analisi dei mismatch.

Gli autori concludono che, sebbene il GTFS non definisca esplicitamente i DayType, essi sono implicitamente codificati e possono essere estratti e confrontati in modo robusto utilizzando questo framework, fornendo una base necessaria per l'analisi e la pianificazione avanzata del trasporto pubblico.