Aller au contenu

Migration dupliquée

Guide de migration- Transition des trajets ADDED vers NEW ou DUPLICATED

La relation GTFS en temps rĂ©el trip.schedule_relationship de NEW reprĂ©sente un nouveau trajet qui s’exĂ©cute selon un horaire indĂ©pendant de tout trajet planifiĂ© existant.

La trip.schedule_relationship en temps rĂ©el GTFS de DUPLICATED reprĂ©sente un nouveau trajet qui est identique Ă  un trajet programmĂ© existant, Ă  l’exception de la date et de l’heure de dĂ©but du service.

Ce guide de migration dĂ©finit comment les producteurs et les consommateurs existants qui utilisaient l’énumĂ©ration ADDED doivent passer Ă  l’énumĂ©ration NEW ou DUPLICATED. L’objectif est de minimiser les perturbations pour les producteurs et les consommateurs pendant la transition.

Si vous ĂȘtes un producteur ou un consommateur qui n’a pas utilisĂ© l’énumĂ©ration ADDED, aucune action n’est requise- vous pouvez produire/consommer des trajets NEW et/ou DUPLICATED sans produire/consommer d’entitĂ©s ADDED .

Pour un historique complet de l’énumĂ©ration NEW, consultez la proposition NEW et REPLACEMENT sur GitHub.

Pour un historique complet de l’énumĂ©ration DUPLICATED, voir la proposition DUPLICATED sur GitHub.

Vers lequel migrer

Les Ă©numĂ©rations NEW et DUPLICATED sont toutes deux utilisĂ©es pour spĂ©cifier un trajet qui n’était pas initialement prĂ©vu pour s’exĂ©cuter dans le GTFS statique.

Utilisez NEW si votre trajet ne peut pas ĂȘtre dĂ©crit en utilisant comme modĂšle des trajets planifiĂ©s. Par exemple, si le trajet s’arrĂȘte Ă  des arrĂȘts diffĂ©rents de ceux des trajets rĂ©guliers de l’itinĂ©raire, ou si le trajet supplĂ©mentaire permet uniquement la prise en charge au dĂ©but de l’itinĂ©raire malgrĂ© le fait que les trajets rĂ©guliers permettent Ă  la fois la prise en charge et la dĂ©pose Ă  tous les arrĂȘts.

Utilisez DUPLICATED si votre trajet est une copie d’un trajet planifiĂ©, qui peut avoir lieu au mĂȘme moment ou Ă  des heures diffĂ©rentes du trajet initialement prĂ©vu.

Utilisation des entitĂ©s ADDED et NEW dans le mĂȘme flux

Si vous ĂȘtes un producteur qui a utilisĂ© l’énumĂ©ration ADDED pour spĂ©cifier des trajets qui ne sont pas liĂ©s Ă  l’horaire, pour Ă©viter de perturber les consommateurs existants, il est recommandĂ© de continuer Ă  produire des entitĂ©s ADDED pour ces trajets, mais Ă©galement d’ajouter des entitĂ©s NEW pour le mĂȘme trajet.

Cependant, pour empĂȘcher les consommateurs d’ajouter accidentellement le mĂȘme trajet deux fois, les entitĂ©s rĂ©fĂ©rençant le mĂȘme trajetdoiventĂȘtre liĂ©es en utilisant les mĂȘmes trip_id, route_id et start_date. De plus, le contenu de stop_time_update doit Ă©galement ĂȘtre le mĂȘme.

Producteurs

entity {
 id: "ei0"
 trip_update {
    trip: {
       trip_id: "1"//<-- un trip_id non trouvé dans le GTFS statique
       route_id: "A"
      schedule_relationship: ADDED
      start_date: "20200821"//<-- Nouvelle date de trajet 
      start_time: "11:30:00"//<-- Nouvelle heure de trajet
    }
    stop_time_update {
...//La liste complùte des points d’appel du trajet
    }
 }
}

entity {
 id: "ei10"
 trip_update {
    trip: {
       trip_id: "1"//<-- Le mĂȘme trip_id que ci-dessus
       route_id: "A"//<-- Le mĂȘme route_id que ci-dessus
      schedule_relationship: NEW
      start_date: "20200821"//<-- La mĂȘme date que ci-dessus
      start_time: "11:30:00"//<-- La mĂȘme heure que ci-dessus
    }
    stop_time_update {
...//<-- Le mĂȘme contenu que ci-dessus
    }
 }
}

Il est suggĂ©rĂ© d’informer les consommateurs existants (par exemple, via une liste de diffusion pour dĂ©veloppeurs) que l’utilisation de ADDED est en cours. Les clients devraient dĂ©sormais utiliser les trajets « NEW ». La stratĂ©gie ci-dessus, utilisĂ©e pour associer les entitĂ©s de voyage « ADDED » et « NEW », doit Ă©galement ĂȘtre mentionnĂ©e, et un lien vers ce guide de migration doit ĂȘtre inclus. Une fois le dĂ©lai Ă©coulĂ©, vous pouvez supprimer les entitĂ©s « ADDED » de votre flux et publier uniquement les entitĂ©s « NEW » pour les voyages nouvellement ajoutĂ©s.

Consommateurs

Comme mentionnĂ© ci-dessus, les producteurs passeront des Ă©numĂ©rations « ADDED » Ă  « NEW » en publiant initialement deux entitĂ©s pour chaque nouveau trajet utilisant le mĂȘme « trip_id ».

Par consĂ©quent, lorsqu’un consommateur implĂ©mente la prise en charge des trajets « NEW », il est important que les consommateurs ignorent tous les trajets « ADDED » qui ont le mĂȘme « trip_id » trip_id trajet « NEW ».

Utilisation des entitĂ©s ADDED et DUPLICATED dans le mĂȘme flux

Producteurs

Si vous ĂȘtes un producteur qui a utilisĂ© l’énumĂ©ration ADDED pour des trajets en double, pour Ă©viter toute interruption de consommateurs existants, il est recommandĂ© de continuer Ă  produire des entitĂ©s ADDED pour ces trajets mais Ă©galement d’ajouter des entitĂ©s DUPLICATED pour le mĂȘme trajet.

Cependant, pour Ă©viter que les consommateurs ajoutent accidentellement deux fois le mĂȘme trajet, les entitĂ©s faisant rĂ©fĂ©rence au mĂȘme trajet doivent ĂȘtre liĂ©es en utilisant le mĂȘme trip_id. Vous pouvez relier les deux entitĂ©s de l’une des deux maniĂšres suivantes :

  1. trip.trip_id des deux entitĂ©s doit ĂȘtre le mĂȘme, OU
  2. trip.trip_id du trajet ADDED doit ĂȘtre le mĂȘme que le trajet DUPLICATED trip_properties.trip_id

Voici un exemple de la premiÚre option (1) pour dupliquer GTFS trip_id 1, avec le trip.trip_id correspondant dans les entités ADDED et DUPLICATED:

entity {
  id: "ei0"
  trip_update {
    trip: {
      trip_id: "1" // <-- trip_id from static GTFS to copy
      schedule_relationship: ADDED
      start_date: "20200821" // <-- New trip date
      start_time: "11:30:00" // <-- New trip time
    }
    stop_time_update {
    ...
    }
  }
}

entity {
  id: "ei10"
  trip_update {
    trip: {
      trip_id: "1" // <-- trip_id from static GTFS to copy
      schedule_relationship: DUPLICATED
    }
    trip_properties {
      trip_id: "NewTripId987" // <-- New trip_id unique to this trip
      start_date: "20200821"  // <-- New trip date
      start_time: "11:30:00"  // <-- New trip time
    }
    stop_time_update {
    ...
    }
  }
}

Voici un exemple de la deuxiÚme option (2) pour dupliquer GTFS trip_id 1, avec le trip.trip_id du trajet ADDED correspondant au trajet DUPLICATED trip_properties.trip_id :

entity {
  id: "ei0"
  trip_update {
    trip: {
      trip_id: "NewTripId987" // <-- New trip_id unique to this trip
      schedule_relationship: ADDED
      start_date: "20200821" // <-- New trip date
      start_time: "11:30:00" // <-- New trip time
    }
    stop_time_update {
    ...
    }
  }
}

entity {
  id: "ei10"
  trip_update {
    trip: {
      trip_id: "1" // <-- trip_id from static GTFS to copy
      schedule_relationship: DUPLICATED
    }
    trip_properties {
      trip_id: "NewTripId987" // <-- Matches the ADDED trip.trip_id
      start_date: "20200821"  // <-- New trip date
      start_time: "11:30:00"  // <-- New trip time
    }
    stop_time_update {
    ...
    }
  }
}

Il est suggĂ©rĂ© d’informer les consommateurs existants (par exemple, via une liste de diffusion pour dĂ©veloppeurs) que l’utilisation de ADDED est obsolĂšte avant une date limite dĂ©finie et que les consommateurs doivent commencer Ă  consommer les trajets DUPLICATED Ă  la place. La stratĂ©gie ci-dessus utilisĂ©e pour faire correspondre les entitĂ©s de trajet « ADDED » et « DUPLICATED » doit Ă©galement ĂȘtre mentionnĂ©e et un lien vers ce guide de migration doit ĂȘtre inclus. Une fois le dĂ©lai passĂ©, vous pouvez supprimer les entitĂ©s « ADDED » de votre flux et publier uniquement les entitĂ©s « DUPLICATED » pour les trajets dupliquĂ©s.

Consommateurs

Comme mentionnĂ© ci-dessus, les producteurs passeront des Ă©numĂ©rations ADDED Ă  DUPLICATED en publiant initialement deux entitĂ©s pour chaque trajet dupliquĂ©, en utilisant l’une des deux options ci-dessus pour faire correspondre les identifiants entre les entitĂ©s.

Par consĂ©quent, lorsqu’un application rĂ©utilisatrice implĂ©mente la prise en charge des trajets DUPLICATED, il est important que les consommateurs :

  1. Ignorent tous les trajets ADDED qui ont le mĂȘme trip.trip_id en tant que trajet DUPLICATED trip.trip_id
  2. Ignorez tous les trajets ADDED qui ont le mĂȘme trip.trip_id en tant que trajet DUPLICATED trip_properties.trip_id