Skip to content

Utilisation des horaires HRDF avec GTFS-RT

L’utilisation de GTFS-RT part du principe qu’un fichier GTFS statique est utilisé comme base.

La plateforme Open Data en met un à disposition.

De nombreux acteurs préfèrent toutefois le format HRDF (plus puissant).

Dans le HRDF, les champs suivants d’un trajet constituent une clé univoque:

  • „Numéro de trajet“
  • „Gestion“
  • „Variante “

Celle-ci se trouve dans la “*Z-line” du fichier „FPLAN“.

Dans GTFS (et GTFS-RT), il s’agit du “Trip_ID” dans le fichier “trips.txt”. Les itinéraires (dans “routes.txt”) et les trips sont automatiquement numérotés. C’est-à-dire qu’ils ne sont pas stables non plus entre les versions de GTFS.

Si l’horaire réel doit provenir de HRDF et que leurs algorithmes sont conçus pour cela, ils doivent néanmoins importer le GTFS Static dans leur base de données et créer une correspondance.

Il est recommandé de procéder comme suit.

 

Importez le GTFS Static actuel dans votre base de données

Importez le GTFS Static actuel dans une base de données (par ex. avec https://github.com/cbick/gtfs_SQL_importer). A titre d’exemple, voici un script SQL simple.

Une compréhension de la structure de GTFS est nécessaire: https://developers.google.com/transit/gtfs/reference/

Importez les données nécessaires du HRDF dans une base de données

Vous devez importer des données à partir de différents fichiers du HRDF. La structure est décrite ici: https://opentransportdata.swiss/wp-content/uploads/2016/10/hrdf.pdf

De „FPLAN“:

Les périodes de trafic doivent également être intégrées (fichier “BITFELD”). Ils en ont besoin pour déterminer les jours de circulation.

Du fichier “INFOTEXT” est nécessaire pour identifier le numéro de train correct en cas de panne. Si le numéro de train change (en cas de panne), le numéro de train initial est enregistré dans “INFOTEXT” dans le champ “Infotext”. C’est-à-dire que la valeur de “Z0” dans le HRDF doit encore être correctement référencée.

Les reliures doivent également être importées. Les liaisons directes sont deux trajets effectués par le même train. Les reliures sont contenues dans le fichier “DURCHBI”:

Dans le GTFS, les liaisons sont déjà accrochées ensemble pour former le trip. Ainsi, le trip A et le trip B, qui sont reliés par DURCHBI dans le HRDF, sont déjà présents dans le GTFS en tant que A->B.
Au minimum, le dossier devrait contenir:

  • Numéro de trajet
  • Administration
  • Variante
  • Point de départ
  • Lieu de destination
  • Heure de départ
  • Période cible
  • Hiérarchie
  • Ripage
  • Période de circulation
  • Z0
  • ZN

Mise en correspondance des données

Vous pouvez maintenant faire correspondre les enregistrements en cliquant sur:

  • Point de départ
  • Heure de départ
  • Lieu de destination
  • Période cible
  • Ripage
  • Jour de circulation

 

Il est également possible de procéder à une concordance via le parcours, auquel cas il est possible de renoncer au jour de circulation. Lors de la mise en correspondance par le biais du parcours, le parcours exact est mis en correspondance.

Important:

  • Il y a plus de voyages dans GTFS que de voyages dans HRDF.
  • Les trains transfrontaliers sont tronqués à la gare frontière sur la plateforme Opendata. Si vous avez les horaires d’une autre source, cela peut être différent.
  • Vous pouvez également déterminer le lieu de départ/d’arrivée à partir du parcours de “FPLAN”.

 

La correspondance peut être statique ou dynamique, selon les besoins de votre application, mais vous devez en tout cas inclure le tag pertinent, car c’est la seule façon d’identifier clairement le trajet et l’entrée HRDF-FPLAN correspondants. Par exemple:

  • Vous pouvez le faire par exemple avec une fonction getTripfromHRDF (ID trajet, gestion, version , jour de fonctionnement).
  • Vous pouvez créer une fonction getHRDFfromTrip(trip_id, jour de fonctionnement).
  • Vous créez pour chaque jour d’exploitation une vue/tableau des trajets et de leur mapping avec le HRDF (attention : dans le pire des cas, 130’000 trajets x 400 jours).