Description rapide
L’appariement consiste à regrouper les données d’horaire, les données en temps réel et, le cas échéant, les perturbations provenant de différentes sources et des données en temps réel. Comme il n’existe pas encore de référence universelle et intersystèmes pour regrouper les deux sources de données dans les transports publics suisses, l’appariement est parfois délicat. Le Swiss Journey ID permettra d’améliorer cette situation. D’ici là, et jusqu’à nouvel ordre, l’appariement reste la seule possibilité pour le trafic international.
Description spécifique
Il existe un principe selon lequel l’appariement doit être suffisamment robuste pour continuer à produire quelque chose d’utile pour certains cas d’usage, même si seules des données d’horaire ou en temps réel sont disponibles. Le respect de ce principe dans la mesure du possible nécessite une compréhension approfondie de la planification de l’horaire et des données d’horaire, ou de la disposition et des données en temps réel.
Au sein d’OJP et GTFS-RT, l’appariement est déjà effectué pour la Suisse. Comme l’appariement doit être configuré pour chaque organisation commerciale, une liste est gérée pour les entreprises de transport (identification à l’aide du numéro d’organisation commerciale) pour lesquelles des informations en temps réel sont mises en correspondance.
Nous décrivons ci-dessous comment l’appariement peut être effectué dans les cas suivants:
- Données théoriques – Données théoriques avec HRDF – GTFS: Ceci est pertinent lorsque GTFS-RT est utilisé pour le temps réel, mais que les horaires sont chargés au format HRDF.
- Données théoriques – Données théoriques Suisse/étranger:
- Données théoriques – temps réel avec HRDF – SIRI ET/PT:
- Données théoriques – temps réel avec NeTEX – SIRI ET/PT
Swiss Journey ID – SJYID
À l’avenir, l’appariement se fera toujours via sjyid et éventuellement encore via des relations de voyage (voir VDV 454, version 3,0 , chapitre 5.2.2.6).
Il est important de noter que sjyid n’est univoque qu’en association avec un jour d’exploitation. C’est la raison pour laquelle sjyid ne peut être l’identifiant d’un trajet ni dans NeTEx ni dans GTFS (ils devraient être valables pour plusieurs jours).
Informations fondamentales sur l’appariement
Il existe plusieurs niveaux:
- Matching avec sjyid et les relations de voyage: ce que nous voulons atteindre à l’avenir.
- Matching via «Fahrt-Id» (Id parcours) et «Fahrtbehung» (Relation de parcours): Les identifiants des deux parties peuvent être convertis et/ou utilisés tels quels. Souvent, l’ID ne convient malheureusement pas (p. ex. HRDF – GTFS).
- Appariement via numéro de train: Le numéro de train en Suisse est connu et devrait suffire pour l’appariement. Si l’on tient compte des autres règles d’attribution des numéros de train (p. ex. pour les trains ombres), on peut aller assez loin pour le chemin de fer (voir p. ex. numéro de train – Wikipédia).
- Appariement par ligne/direction: Dans certains cas, il est déjà possible d’identifier la course correcte à l’aide de l’heure de début, des informations sur la ligne, la catégorie d’offre et la direction.
- Appariement via FahrtStartEnde: Lieu de départ, heure de départ, lieu d’arrivée, heure d’arrivée, le cas échéant ET, catégorie d’offre, information sur la ligne sont utilisés pour relier les courses des deux parties. Cela ne fonctionne pas pour les courses raccourcies.
- Appariement de parties de parcours: Les informations issues d’arrêts sont superposées. Le trajet de la 2e partie est attribué à la meilleure correspondance de la 1re partie. Il est possible d’utiliser pour cela l’heure d’arrivée, l’heure de départ, les arrêts ou d’autres informations détaillées. Les cas comme une course avec amplificateur restent délicats lorsque la relation de trajet ne peut pas être utilisée.
Appariement sur des heures imprécises
En Suisse, les données d’horaire ne sont indiquées qu’à la minute près. Dans certains cas, il peut y avoir une légère disparité entre les temps. Toutefois, en général, ce n’est pas une bonne idée de faire la correspondance sur la base d’heures imprécises. En temps réel, les heures théoriques initiales devraient également être transmises. Il convient de s’y référer.
Arrêts et bordures d’arrêt
Plus le temps est long, plus les données sont émises avec précision à l’arrêt. Pour l’appariement, il peut toutefois être judicieux de revenir à l’arrêt, car un changement de voie pouvait tout à fait avoir lieu.
Description technique
Identifiants pertinents HRDF
HRDF contient les informations importantes suivantes:
- *Z – Ligne avec ID parcours, gestion et version
- *I RN pour CarPostal. Le code de la région.
Avec ces quatre indications, une course est entièrement définie.
Au lieu de la version, il est également possible de rechercher dans *A VE et BITFELD la version pour laquelle un jour correspondant est actif.
Chez nous, la version n’est définie que lors de l’exportation HRDF. Cela signifie qu’il ne s’agit PAS d’une partie stable de l’identifiant et qu’elle doit être rechargée à chaque entrée.
Le sjyid sera exporté vers HRDF comme suit:
- FPLAN: *I JY <refid>
- INFOTEXT: <refid> ch:1:sjyid:<id>
Identifiants pertinents GTFS
L’identifiant est trip_id.
Dans la définition de GTFS et dans la représentation interne de SKI+, les lignes (et parfois aussi les courses) ont été regroupées différemment. Il n’y a donc pas de correspondance directe avec les courses/lignes dans HRDF. Il n’est donc pas possible de convertir l’ID.
Dans la mesure du possible, les route_id sont maintenus stables lors de l’exportation. La plupart du temps, les modifications n’apparaissent plus qu’au changement d’horaire.
Le jsyid sera exporté vers GTFS comme suit: Il y aura une nouvelle colonne sjyid dans trips.txt.
| ! Nous réfléchissons à la possibilité de toujours partager le sjyid dans GTFS-RT. |
Identifiants pertinents NeTEx
Comme pour GTFS, la représentation interne de l’ID sert de base au ServiceJourney généré dans NeTEx.
L’attribut ID du ServiceJourney sera toujours généré directement et n’a aucun lien avec HRDF.
La validité peut être déterminée à l’aide de l’évaluation de l’élément AvailabilityCondition.
Le sjyid sera enregistré dans une valeur clé:

Attention: Il peut y avoir plusieurs ServiceJourney avec le même SJYID (variantes).
Identifiants OJP pertinents
Dans OJP, le sjyid est émis dans ojp:JourneyRef. ojp:OperatingDayRef en fait toujours partie. Les deux parties sont comprises dans l’élément 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>Appariement HRDF – GTFS
Ce cas d’usage est décrit ici.
Matching avec des données internationales – horaire
Si, en raison de l’état des données, seule la course théorique suisse est présente, le mappage doit être effectué soit via l’ID, soit sur les quelques arrêts disponibles. Un exemple typique est l’ICE, dont les données théoriques ne contiennent que la partie Bâle–Basel Bad Bf. Ces deux éléments doivent donc être réalisés.
Par défaut, les courses théoriques sont toujours programmées au premier arrêt commercial à l’étranger. Si cette procédure est également appliquée dans le deuxième bloc de données, au moins deux arrêts peuvent être correctement appariés. En trafic ferroviaire international, en particulier, il est peu probable que cette erreur soit commise.
Le trafic de proximité est généralement intégré dans l’un ou les deux systèmes (car un seul système de conduite est responsable).
L’appariement via l’ID du trajet est souvent exclu. Le numéro de train est une possibilité, entre autres. Il est également possible, voire probable, que la catégorie d’offre et l’exploitant soient différents. L’appariement à l’international ne devrait pas privilégier ce point.
Correspondance avec les données internationales – temps réel
CUS génère déjà un parcours consolidé au-delà de la frontière pour les parcours directs. Il peut manquer des arrêts à l’étranger (à l’exception du terminus).
Si, en raison de l’état des données, seule la course théorique suisse est présente, le mappage doit être effectué soit via l’ID, soit sur les quelques arrêts disponibles. Un exemple typique est l’ICE, dont les données théoriques ne contiennent que la partie Bâle–Basel Bad Bf. Ces deux éléments doivent donc être réalisés.
Par défaut, les courses théoriques sont toujours programmées au premier arrêt commercial à l’étranger. Autrement dit, deux arrêts devraient toujours être disponibles.
Matching pour l’OJP (actuel)
D’un point de vue technique, différentes formes d’appariement peuvent être effectuées. La première étape est réalisée via un «FahrtID». C’est par exemple le cas pour le chemin de fer à voie normale. Si ce «FahrtID» n’est pas indiqué, il convient de faire correspondre différents paramètres issus des deux sources de données:
- Arrêts (voir aussi Données de base et métadonnées – vue d’ensemble): Ce n’est pas pertinent en Suisse, car le numéro DiDok est généralement utilisé. Seule la distinction entre arrêt et point d’arrêt doit être prise en compte. Toutefois, comme le point d’arrêt contient le numéro DiDok, le calcul est à nouveau garanti.
- Entreprises de transport: L’appariement des entreprises de transport s’effectue indirectement via la ligne Direction
- Ligne et direction: Les courses sont mises en correspondance sur la base de la ligne et de la direction (voir aussi Données d’horaire – Vue d’ensemble). Comme les lignes sont différenciées en fonction de l’entreprise de transport rattachée, les entreprises de transport sont mises en correspondance indirectement.
Un algorithme mis à disposition par le fournisseur tente de rechercher les courses identiques dans une ligne/direction attribuée les unes aux autres.
TODO
Prochainement extensions prévues sur cette page:
- Identifiants pertinents SIRI ET/PT
- Identifiants pertinents SIRI SX/VDV 736
- Matching NeTEx – SIRI
