Skip to content

Utilizzo dei programmi HRDF insieme a GTFS-RT

L’uso di GTFS-RT presuppone l’utilizzo di un file GTFS statico come base.

La Open Data Platform fornisce una piattaforma di questo tipo.

Tuttavia, molti giocatori preferiscono il formato HRDF (più potente).

Nell’HRDF, i seguenti campi di un viaggio formano una chiave unica:

  • „Numero corsa“
  • „Amministrazione“
  • „Variante“

Si trova nella “riga *Z” del file “FPLAN”.

In GTFS (e GTFS-RT) questo è il “Trip_ID” nel file “trips.txt”. I percorsi (in “routes.txt”) e i viaggi sono numerati automaticamente. Ciò significa che non sono stabili nemmeno tra le varie versioni di GTFS.

Se l’orario effettivo proviene da HRDF e i vostri algoritmi sono progettati per questo, dovete comunque importare il GTFS Static nel vostro database e generare una corrispondenza.

Si raccomanda la seguente procedura.

 

Importare la statica GTFS corrente nel database

Importare la statica GTFS corrente in un database (ad esempio con https://github.com/cbick/gtfs_SQL_importer). Un semplice script SQL come esempio

È necessaria una comprensione della struttura di GTFS: https://developers.google.com/transit/gtfs/reference/

Importare i dati necessari dall’HRDF in un database.

È necessario importare i dati da diversi file HRDF. La struttura è descritta qui: https://opentransportdata.swiss/wp-content/uploads/2016/10/hrdf.pdf

Da „FPLAN“:

Anche i periodi di traffico devono essere integrati (file “BITFELD”). Sono necessari per determinare i giorni di traffico.

Il file “INFOTEXT” è necessario per identificare il numero di treno corretto in caso di cancellazione. Se il numero del treno cambia (in caso di cancellazione), il numero del treno originale viene memorizzato nel campo “INFOTEXT” nel campo “Infotext”. Ciò significa che il valore di “Z0” nell’HRDF deve essere ancora riferito correttamente.

Anche le interconnessioni devono essere importate. I collegamenti passanti sono due viaggi effettuati con lo stesso treno. Le interconnessioni sono contenute nel file “DURCHBI”:

Nel GTFS, le interconnessioni sono già collegate per formare il viaggio. Quindi il viaggio A e il viaggio B, che sono collegati nell’HRDF tramite DURCHBI, sono già presenti nel GTFS come A->B.
Come minimo, il registro deve contenere:

  • Numero corsa
  • Amministrazione
  • Variante
  • Luogo di inizio
  • Luogo di destinazione
  • Ora di partenza
  • Tempo target
  • Organizzazione gerarchica
  • allineamento
  • Periodo di circolazione
  • Z0
  • ZN (impianto per l’annuncio dei numeri treno)

Corrispondenza dei dati

Ora è possibile abbinare i record tramite:

  • Luogo di inizio
  • Ora di partenza
  • Luogo di destinazione
  • Tempo target
  • Allineamento
  • Giorno di circolazione

 

È possibile anche la corrispondenza tramite l’itinerario, nel qual caso il giorno di trasporto può essere omesso. Quando si esegue la corrispondenza tramite il percorso, si esegue la corrispondenza con il percorso esatto.

Attenzione:

  • Ci sono più viaggi in GTFS che viaggi in HRDF.
  • I treni transfrontalieri vengono troncati alla stazione di confine sul binario di Opendata. Se gli orari provengono da un’altra fonte, potrebbero essere diversi.
  • È anche possibile determinare il punto di partenza/destinazione dal percorso “FPLAN”.

 

La corrispondenza può essere statica o dinamica, a seconda delle esigenze dell’applicazione, ma è sempre necessario includere il tag pertinente, poiché questo è l’unico modo per identificare in modo univoco il viaggio corrispondente e la voce HRDF-FPLAN corrispondente. Ad esempio:

  • È possibile farlo, ad esempio, con la funzione getTripfromHRDF (ID viaggio, amministrazione, versione, giorno di esercizio).
  • È possibile creare una funzione getHRDFfromTrip(trip_id, operating day).
  • Si crea una vista/tabella degli spostamenti e della loro mappatura nell’HRDF per ogni giorno operativo (nota: nel caso peggiore 130.000 spostamenti x 400 giorni)