Extensions Google Transports en commun de la spécification GTFS

Introduction

L'équipe Google Transports en commun cherche constamment à améliorer la spécification GTFS (General Transit Feed Specification) afin de répondre aux besoins de ses partenaires. Elle a d'ailleurs déjà proposé plusieurs extensions à inclure dans la spécification GTFS, que les partenaires peuvent utiliser dans leur flux envoyé à Google Transports en commun via Google Maps. Vous trouverez ci-dessous la liste complète de ces fonctionnalités.

Si vous avez vos propres propositions d'extensions de la spécification GTFS, consultez le processus officiel de modification de la spécification GTFS.

Nombre maximal de correspondances pour un tarif spécifique

Les extensions suivantes sont en cours d'examen pour que les attributs tarifaires soient acceptés dans un flux couvrant plusieurs agences :

Nom du champ	Présence	Détails
`transfers`	Obligatoire	Utilisez ce champ pour définir le nombre maximal de correspondances autorisé avec ce tarif. Cela n'inclut pas les correspondances groupées (aussi appelées "correspondances sans changement"). Google Transports en commun accepte les valeurs comprises entre `0` et `5`. Si vous ne souhaitez pas limiter le nombre de correspondances pour un tarif, laissez le champ "`transfers`" vide.

Prix des cartes à puce (Japon)

Ce type de carte à puce prépayée rechargeable n'est utilisée qu'au Japon pour régler les trajets en train, métro, bus et monorail. La plupart des cartes à puce, telles que les cartes Pasmo et SUICA (Super Urban Intelligent Card), proposent souvent des réductions aux passagers. L'extension suivante, fonctionnant uniquement sur Google, est compatible avec la modélisation des tarifs des cartes à puce.

fare_attributes.txt

Nom du champ	Obligatoire	Détails
`ic_price`	Facultatif	Si une réduction est proposée à un utilisateur de carte à puce, la valeur correspond au coût du tarif réduit. Si aucune réduction n'est proposée à un utilisateur de carte à puce, définissez la valeur `-1`. Si une carte à puce n'est pas acceptée par une agence de transports en commun, définissez la valeur `-1`.

Types d'itinéraires supplémentaires

Actuellement, la spécification GTFS définit un certain nombre de types d'itinéraires qui peuvent être utilisés pour décrire le type de service fourni sur un itinéraire particulier (par exemple, bus, train ou ferry). Afin d'accroître le nombre de types d'itinéraires acceptés, nous avons proposé d'ajouter le champ route_type comme extension au fichier routes.txt. Pour en savoir plus, consultez Types d'itinéraires GTFS étendus.

Types de véhicules desservant une station

Une extension a été proposée pour permettre de spécifier le type de véhicule desservant un arrêt particulier.

stops.txt

Nom du champ	Obligatoire	Détails
`vehicle_type`	Facultatif	Utilisez ce champ pour décrire le type de moyen de transport desservant l'arrêt. Il accepte une valeur `route_type` valide dans un fichier `routes.txt`, y compris nos propositions de valeurs de types d'itinéraires GTFS étendus.

Déviation de trajet

Il est recommandé d'indiquer les trajets qui se déroulent en dehors de l'horaire habituel, ou qui sont détournés de l'itinéraire normal en raison d'événements spéciaux ou de perturbations planifiées (tels que des travaux sur une voie, etc.). Nous proposons une extension au fichier trips.txt pour indiquer ces services exceptionnels.

trips.txt

Nom du champ	Obligatoire	Détails
`exceptional`	Facultatif	Le champ doit être défini sur `1` pour indiquer une exception de service telle que des services ajoutés en raison d'événements spéciaux ou des services détournés de l'itinéraire habituel en raison de perturbations planifiées (travaux sur la voie). Le champ doit être défini sur `0` si le service est habituel.

Correspondances entre itinéraires et entre trajets

Dans sa version actuelle, la spécification GTFS permet à une agence de définir la signification des correspondances en utilisant le fichier transfers.txt : correspondances à privilégier, correspondances minutées, correspondances limitées. Actuellement, ces correspondances s'appliquent uniquement aux arrêts. Google a reçu des commentaires d'un certain nombre d'agences qui souhaitent pouvoir fournir des informations de correspondance plus détaillées sur un itinéraire ou même un trajet. En collaborant avec ces agences, nous avons présenté une proposition de modélisation des correspondances entre itinéraires et entre trajets, et nous attendons l'avis des membres de la communauté GTFS.

Motivations

Nous souhaitons pouvoir définir des correspondances entre des itinéraires spécifiques ou même entre des trajets spécifiques pour une paire d'arrêts donnée, sans devoir définir la même correspondance pour tous les trajets de cette paire d'arrêts.

Par exemple :

Si deux trajets arrivent au même quai et s'attendent l'un l'autre, nous souhaitons pouvoir définir une correspondance minutée entre ces deux trajets. Cependant, nous ne souhaitons pas pour autant que toutes les correspondances de cette gare soient des correspondances minutées.
Si un train accuse souvent un retard pouvant aller jusqu'à 30 minutes, nous souhaitons empêcher les correspondances entre ce train et un autre si le délai entre l'arrivée prévue du premier et le départ du second est inférieur à 35 minutes.

Détails

Ajoutez quatre champs facultatifs à transfers.txt :

from_route_id
to_route_id
from_trip_id
to_trip_id

Les champs from_route_id et to_route_id peuvent contenir un route_id (défini par routes.txt) afin de réduire le périmètre de la correspondance en question. Si le from_route_id est spécifié, la correspondance ne s'applique qu'au trajet à l'arrivée associé à l'identifiant d'itinéraire concerné, à l'arrêt défini par le from_stop_id. Si le to_route_id est spécifié, la correspondance ne s'applique qu'au trajet au départ associé à l'identifiant d'itinéraire concerné, à l'arrêt défini par le to_stop_id.

Les champs from_trip_id et to_trip_id peuvent contenir un trip_id, défini par trips.txt. Si le from_trip_id est indiqué, le from_route_id est ignoré. De même, si le to_trip_id est spécifié, le to_route_id est ignoré. Si le from_trip_id est spécifié, la correspondance ne s'applique qu'au trajet à l'arrivée associé à l'identifiant de trajet concerné, à l'arrêt défini par le from_stop_id. Si le to_trip_id est spécifié, la correspondance ne s'applique qu'au trajet au départ associé à l'identifiant de trajet concerné, à l'arrêt défini par le to_stop_id.

Spécificité d'une correspondance

Certaines correspondances présentent des spécificités. Nous souhaitons définir un système de classement simple pour déterminer si une correspondance doit être appliquée. Cela nous permet d'établir la "spécificité" d'une correspondance.

La spécificité de la source de la correspondance a pour valeur 0 si seul le from_stop_id est indiqué, 1 si le from_route_id est spécifié et 2 si le from_trip_id est défini. Le même principe s'applique à la cible : 0 si seul le to_stop_id est indiqué, 1 si le to_route_id est spécifié et 2 si le to_trip_id est défini. La somme de ces deux valeurs, comprise entre 0 et 4 inclus, indique la spécificité de la correspondance. Pour chaque paire ordonnée de trajet à l'arrivée et de trajet au départ, la correspondance présentant la valeur de spécificité la plus élevée des deux trajets est sélectionnée. Par conséquent, pour chaque paire de trajets, il ne doit PAS exister deux correspondances possibles présentant une valeur de spécificité maximale.

Exemple de règle ambiguë :

from_stop_id,to_stop_id,from_route_id,to_route_id,transfer_type
stopFrom,stopTo,routeFrom,,0
stopFrom,stopTo,,routeTo,1

La valeur de spécificité de ces deux correspondances est 1. Cependant, pour les correspondances entre un trajet dont l'identifiant d'itinéraire est routeFrom et qui arrive à l'arrêt stopFrom, et un trajet dont l'identifiant d'itinéraire est routeTo et qui arrive à l'arrêt stopTo, l'une ou l'autre de ces deux règles peut s'appliquer.