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 :
trip.trip_id
des deux entitĂ©s doit ĂȘtre le mĂȘme, OUtrip.trip_id
du trajetADDED
doit ĂȘtre le mĂȘme que le trajetDUPLICATED
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 :
- Ignorent tous les trajets
ADDED
qui ont le mĂȘmetrip.trip_id
en tant que trajetDUPLICATED
trip.trip_id
- Ignorez tous les trajets
ADDED
qui ont le mĂȘmetrip.trip_id
en tant que trajetDUPLICATED
trip_properties.trip_id