Sélectionner un trajet avec TripDescriptor

Important : Pendant toute la durée du trajet, ne modifiez pas le TripDescriptor. Vous ne pouvez sélectionner qu'un seul trajet à l'aide du TripDescriptor.

Pour associer un trajet en temps réel à son prototype GTFS (General Transit Feed Specification) statique, le sous-message TripDescriptor est utilisé. Cet article vous explique comment sélectionner un trajet pour schedule_relationship en tant que SCHEDULED (horaire planifié) ou CANCELED (horaire annulé).

Ajouter un trajet ou trouver un trajet correspondant

Pour ajouter un trajet en temps réel au schedule_relationship en tant que ADDED (ajouté), reportez-vous à l'article Ajouter un trajet en temps réel.

Pour mettre en correspondance un trajet en temps réel et un ensemble de données statique, vous devez inclure un tuple dans TripDescriptor :

• trip_id
• start_time
• start_date

Si vous ne disposez pas de trip_id, vous pouvez le remplacer par route_id et direction_id. Pour mettre correctement les données en correspondance, vous devez obligatoirement inclure les valeurs start_time et start_date.

Fournissez le TripDescriptor pour tous les horaires (basés ou non sur la fréquence)

TripDescriptors pour les horaires non basés sur la fréquence

• Les champs trip_id et start_date sont tous deux obligatoires pour pouvoir identifier un trajet à partir de l'horaire statique. Le champ start_time est facultatif. S'il est renseigné, il doit correspondre à l'une des heures de début du trajet indiquées dans le planning statique pour la date de début en question.
• Si vous ne pouvez pas fournir le trip_id, vous devez renseigner les champs <route_id, direction_id, start_date>.
  • Pour que les méthodes de mise en correspondance route_id et direction_id fonctionnent, le flux statique GTFS doit inclure des direction_id. Cette méthode de mise en correspondance n'est pas adaptée, car elle est effectuée en fonction des données disponibles et est sujette à modification.

Exemple de code

trip_update {

    trip {

      trip_id: "non_frequency-expanded-trip"

      start_date: "20160203"

    }

  }

trip_update {

    trip {

      route_id: "route1"

      direction_id: 0

      start_time: "10:10:00"

      start_date: "20160203"

    }

}

TripDescriptors pour les horaires basés sur la fréquence

Les trajets basés sur la fréquence sont modélisés à l'aide du fichier frequencies.txt. Pour ces types de trajets, le champ start_time est obligatoire, car un composant heure spécifique est requis pour identifier un trajet individuel.

• Un tuple trip_id, start_date, start_time est obligatoire pour pouvoir identifier un trajet à partir des horaires statiques. Si certaines informations sont manquantes, nous faisons notre possible pour trouver un trajet correspondant.
• Si vous ne pouvez pas fournir le trip_id, vous devez indiquer route_id, direction_id, start_date, start_time. Pour que les méthodes de mise en correspondance route_id et direction_id fonctionnent, le flux statique GTFS doit inclure des direction_id. Cette méthode de mise en correspondance n'est pas adaptée.

Lorsque vous fournissez une valeur pour start_time, tenez compte des points suivants :

• Le champ start_time doit être identique à l'heure de début planifiée incluse dans l'ensemble de données statique.
• start_time doit être identique dans tous les TripDescriptors représentant le même trajet au niveau des différents groupes de flux.
• Si vous devez indiquer des ajustements pour l'heure du premier départ au premier arrêt, ne le faites pas via start_time. Utilisez plutôt StopTimeUpdates.
• Bien que la valeur start_time doive être proche de l'heure de départ au premier arrêt, elle ne doit pas nécessairement être identique à celle-ci.

Conseil : Lorsque trip_id et start_time sont dans l'intervalle exact_time=1, l'heure start_time doit être postérieure au début de l'intervalle selon un multiple exact de headway_secs.

Exemple

À 10h le 25 mai 2015, nous décidons qu'un trajet avec trip_id=T commencera à start_time=10:10:00. Nous fournissons cette information via un flux en temps réel à 10h01. À 10h05, nous nous rendons compte que le trajet commencera à 10h13 au lieu de 10h10. Dans notre nouveau flux en temps réel, nous pouvons continuer d'identifier ce trajet comme (T, 2015-05-25, 10:10:00) mais fournir un StopTimeUpdate avec une heure de départ au premier arrêt définie sur 10:13:00.

Si le champ start_time est modifié, il est possible qu'il indique un deuxième départ de bus. Dans ce scénario, un départ est à 10h10, et un autre est déclaré à 10h13.

Exemple de code :

trip_update {

    trip {

         trip_id: "T"

         start_date: "20150525"

         start_time: "10:10:00"

    }

    stop_time_update {

      stop_sequence: 1

      departure {

        delay: 180

      }

    }

}