Corrispondenza tra orari, tempo reale e perturbazioni

Descrizione breve

Il matching consiste nell’accorpare i dati dell’orario, i dati in tempo reale e le eventuali perturbazioni provenienti da fonti diverse e dai dati in tempo reale. Poiché nel settore dei trasporti pubblici svizzeri non esiste ancora un riferimento universalmente valido a livello di sistema che supporti l’accorpamento delle due fonti di dati, il matching è un aspetto in parte delicato. Con la Swiss Journey ID questo aspetto migliorerà. Fino ad allora e fino a nuovo avviso per il traffico internazionale il matching è l’unica possibilità.

Descrizione del funzionamento

Vige il principio secondo cui il matching deve essere così solido da continuare a fornire qualcosa di utile per determinati casi d’uso, anche se sono disponibili solo i dati dell’orario o i dati in tempo reale. Per seguire possibilmente questo principio è necessaria una comprensione approfondita della pianificazione e dei dati dell’orario, della disposizione e dei dati in tempo reale.

All’interno di OJP e GTFS-RT, il matching per la Svizzera è già stato eseguito. Poiché il matching deve essere configurato per ogni organizzazione aziendale, viene tenuto un elenco delle imprese di trasporto per le quali sono disponibili informazioni in tempo reale abbinate (identificazione tramite numero organizzazione aziendale).

Di seguito descriviamo come effettuare l’abbinamento nei seguenti casi:

Dati nominali – Dati nominali con HRDF – GTFS: Ciò è rilevante se si utilizza il GTFS-RT in tempo reale, ma gli orari vengono caricati come HRDF.
Dati nominali – Dati nominali in Svizzera/Estero:
Dati nominali – Tempo reale con HRDF – SIRI ET/PT:
Dati nominali – Tempo reale con NeTEX – SIRI ET / PT

Swiss Journey ID – SJYID

In futuro, il matching avverrà sempre tramite sjyid ed eventualmente ancora tramite le relazioni di corsa (vedere VDV 454 Version 3.0 capitolo 5.2.2.6).

È importante sapere che lo sjyid è univoco solo in combinazione con un giorno di circolazione. Questo è il motivo per cui lo sjyid non può essere l’ID di una corsa né in NeTEx né in GTFS (che dovrebbe valere per diversi giorni).

Informazioni di base sull’abbinamento

Ci sono diversi livelli:

Matching con sjyid e relazioni di guida: in futuro ciò che vogliamo ottenere.
Corrispondenza tramite «ID corsa» e relazione di corsa: Gli identificativi delle due parti possono essere convertiti e/o utilizzati senza variazioni. Spesso purtroppo gli ID non corrispondono (ad es. HRDF – GTFS)
Matching tramite numero del treno: Il numero del treno esiste in Svizzera e dovrebbe essere sufficiente per l’abbinamento. Se si osservano le altre regole per l’assegnazione dei numeri del treno (ad es. per i treni ombra), per la ferrovia si arriva abbastanza lontano (vedere ad es. numero del treno – Wikipedia).
Corrispondenza tramite linea/direzione: In alcuni casi, tramite l’ora di partenza, le informazioni su linea, categoria di offerta e direzione è già possibile identificare la corsa corretta.
Corrispondenza tramite «FahrtStartEnde» (Inizio/fine corsa): Luogo di partenza, ora di partenza, luogo d’arrivo, ora d’arrivo, eventualmente IT, categoria di offerta e informazione sulla linea vengono utilizzati per raggruppare le corse delle due parti. Questo non funziona in caso di corse più brevi.
Corrispondenza di parti di itinerario: Le informazioni dalle fermate vengono sovrapposte. La corsa della 2a parte viene attribuita alla partita migliore della 1a parte. È possibile utilizzare orari di arrivo, di partenza, fermate, ma anche informazioni dettagliate. Rimangono insidiosi in quanto casi come una corsa di rinforzo, quando la relazione di corsa non può essere utilizzata.

L’attuazione avviene solitamente con un fallback dall’alto verso il basso. Se una corsa non può essere effettuata, a seconda del caso d’uso viene tralasciata (ad es. informazioni sulle perturbazioni) o gestita come corsa speciale (in tempo reale senza corsa teorica)

Corrispondenza durante i periodi confusi

In Svizzera, i dati dell’orario hanno una precisione solo al minuto. In alcuni casi è possibile che si verifichi un lieve disallineamento degli orari. Tendenzialmente, però, non è una buona idea fare il matching in base agli orari imprecisi. In tempo reale, dovrebbero essere trasmessi anche gli orari teorici originari. Su questi ultimi dovrebbero basarsi.

Fermate e bordi fermata

Più a lungo si producono i dati con bordo fermata preciso. Per il matching può però essere utile tornare alla fermata, poiché potrebbe anche verificarsi un cambio di binario.

Descrizione tecnica

Identificatori rilevanti HRDF

Nell’HRDF sono presenti le informazioni rilevanti:

*Z – Riga con FahrtId, amministrazione e versione
*I RN per AutoPostale. Il codice regione.

Con queste quattro indicazioni una corsa viene definita in modo completo.

In alternativa, anziché nella versione, è possibile cercare anche da *A VE e BITFELD la versione in cui è attivo un tag corrispondente.

La versione viene stabilita da noi solo durante l’esportazione HRDF. Ciò significa che questa NON è una parte stabile dell’identificatore e deve essere ricaricata a ogni input.

Lo sjyid sarà esportato in HRDF come segue:

FPLAN: *I JY <refid>

INFOTEXT: <refid> ch:1:sjyid:<id>

Identificatori rilevanti GTFS

trip_id funge da identificatore.

Nella definizione di GTFS e presso SKI+, le linee (e in parte anche le corse) sono state raggruppate in modo diverso. Per questo motivo, non esiste una corrispondenza diretta delle corse / delle linee in HRDF. Ciò significa che non è possibile convertire gli ID.

Se possibile, route_id vengono mantenuti stabili all’esportazione. Nella maggior parte dei casi le modifiche si verificano solo al cambiamento d’orario.

Il jsyid verrà esportato in GTFS come segue: Ci sarà una nuova colonna sjyid in trips.txt.

! Valutiamo se in GTFS-RT inserire sempre anche lo sjyid.

Identificatori rilevanti NeTEx

Come per GTFS, la rappresentazione interna dell’ID funge da base per il Service Journey generato in NeTEx.

L’attributo ID del ServiceJourney continuerà a essere generato direttamente e non ha alcun riferimento con HRDF.

La validità può essere determinata in base all’analisi dell’elemento AvailabilityCondition.

Lo sjyid sarà memorizzato in un valore di valore chiave:

Attenzione: possono essere presenti più Service Journey con lo stesso SJYID (varianti).

Identificatori rilevanti OJP

In OJP, lo sjid viene emesso in ojp:JourneyRef. Ciò include sempre anche ojp:OperatingDayRef. Entrambi gli elementi sono contenuti nell’elemento ojp:Service:

<ojp:Service>
 <ojp:OperatingDayRef>2024-03-07</ojp:OperatingDayRef>
 <ojp:JourneyRef>ch:1:sjyid:100001:817-003</ojp:JourneyRef>
 <siri:LineRef>ojp:91081:A</siri:LineRef>
 <siri:DirectionRef>H</siri:DirectionRef>

Matching HRDF – GTFS

Questo caso applicativo viene descritto qui.

Corrispondenza con dati internazionali – Orario

Se sulla base dei dati è presente solo la corsa teorica svizzera, la mappatura va effettuata tramite l’ID oppure attraverso le poche fermate disponibili. Un esempio tipico è rappresentato dagli ICE, dove nei dati teorici è presente solo la parte Basilea–Basilea Badischer Bahnhof. Vanno quindi fatte entrambe.

Di norma le corse teoriche vengono programmate sempre alla prima fermata commerciale all’estero. Se ciò viene gestito così anche nel secondo record di dati, almeno due fermate possono essere abbinate correttamente. Soprattutto nel traffico ferroviario internazionale è poco probabile che venga fatto in modo errato.

Il traffico locale è in genere interamente presente in uno o in entrambi i sistemi (poiché la responsabilità è di un solo sistema di gestione).

Spesso è escluso un matching tramite l’ID corsa. Una possibilità è rappresentata, tra l’altro, dal numero del treno. Purtroppo è anche possibile o probabilmente che categoria di offerta e operatore siano diverse. Il matchin nel settore internazionale non dovrebbe basarsi su questo.

Corrispondenza con dati internazionali in tempo reale

Per le corse dirette il CUS genera già una corsa consolidata oltre il confine. Eventualmente mancano fermate all’estero (ad eccezione della fermata di fine corsa).

Di norma le corse teoriche vengono programmate sempre alla prima fermata commerciale all’estero. Ciò significa che devono essere sempre disponibili due fermate.

Matching per l’OJP (attualmente)

Tecnicamente sono possibili diverse forme di corrispondenza. Nella prima fase il riferimento avviene tramite un ID corsa. Ciò è presente ad esempio per le ferrovie a scartamento normale. Se questo ID corsa non è presente, i diversi parametri delle due fonti dei dati devono essere confrontati:

Fermate (v. anche Dati anagrafici e metadati – Panoramica): Ciò non è rilevante in Svizzera, perché in genere viene utilizzato il numero DiDok. Si deve considerare solo la distinzione tra fermata e punto di fermata. Tuttavia, poiché il punto di fermata contiene il numero DiDok, ne viene nuovamente garantita la derivazione.

Imprese di trasporto: Il matching tra le imprese di trasporto avviene indirettamente attraverso la linea Direzione

Linea e direzione: In base a linea e direzione, le corse vengono associate (v. anche Dati dell’orario – Panoramica). Poiché le linee si distinguono in base all’appartenenza a un’impresa di trasporto, indirettamente anche le imprese di trasporto vengono associate.

All’interno della linea/direzione associata, un algoritmo messo a disposizione dal fornitore tenta di cercare le corse identiche e di abbinarle.

TODO

Estensioni in programma a breve per questa pagina:

Identificatori rilevanti SIRI ET / PT
Identificatori rilevanti SIRI SX / VDV 736
Matching NeTEx – SIRI

Indice della materia

Ricerca nella pagina