Homogénéité de l’«id» au sein des services GTFS

GTFS part du principe que les «id» au sein des différents services GTFS Static, GTFS-RT et GTFS-SA sont cohérents. Lors de la création de GTFS-SA, nous avons été quelque peu prédéfinis:

  • stopId est la valeur SLOID de l’arrêt ou de la voie
  • tripId est le SJYID (donc le nouvel ID officiel de la course).

Malheureusement, cela ne correspond pas à ce que contient GTFS Static:

  • Le stop_id est un identifiant généré artificiellement, car il nous permet de représenter les plates-formes (p. ex. 41/42) et les groupes de secteurs (p. ex. 12A-D, 12A) lorsqu’ils apparaissent tels quels dans l’horaire.
  • Le trip_id est également créé de manière artificielle et dépend de lignes et de variantes de lignes.

Nous ne pouvons pas non plus simplement utiliser les valeurs SLOID et SJYID, car le format GTFS requiert l’unicité, ce qui n’est pas le cas pour le moment:

  • Une valeur SLOID peut être utilisée aussi bien pour la plate-forme que pour la voie ou le groupe de secteurs (p. ex. ch:1:sloid:7000:0:41 s’appliquerait également aux catégories 41/42, 41A, 41E-H). Plusieurs lignes auraient alors la même valeur SLOID.
  • Un SJYID n’est univoque qu’associé au jour d’exploitation. Dans GTFS, il doit être univoque global.

Amorces de solutions

  • Dans trips.txt, le SJYID est déjà ajouté dans une nouvelle colonne «original_trip_id». Cela permet au moins de mapper les GTFS SA de manière indirecte.
  • Dans le fichier stops.txt, nous sommes en train d’ajouter également la SLOID dans une colonne supplémentaire («original_stop_id»). Pour les quais (bordures d’arrêt), la SLOID est ajoutée si elle existe. Si elle n’est pas disponible, le champ reste vide. La SLOID est ajoutée pour les arrêts, et parfois le numéro UIC pour les arrêts étrangers.
  • Dans GTFS-SA, nous sommes en train d’étendre l’«informed_entity» afin que tous les stopId concernés soient transmis (Service Alerts – General Transit Feed Specification).

À gauche

#AutoTranslate