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 à la spécification GTFS, consultez le processus officiel de modification de la spécification GTFS.
Nombre maximal de correspondances pour un tarif spécifique
Pour pouvoir accepter les attributs tarifaires figurant dans les flux couvrant plusieurs agences, les extensions suivantes ont été proposées :
| Nom du champ | Obligatoire | Détails |
|---|---|---|
transfers |
Facultatif | Google Transports en commun accepte les valeurs comprises entre 0 et 5, alors que la spécification GTFS prend uniquement en compte les valeurs comprises entre 0 et 2. Utilisez ce champ pour définir le nombre maximal de correspondances (hors correspondances au sein d'un segment) autorisé avec ce tarif. |
Prix des cartes à circuit intégré (Japon)
Une carte à circuit intégré est une carte à puce prépayée rechargeable qui 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 la page 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 |
Ce champ permet de décrire le type de moyen de transport desservant l'arrêt. Il accepte une
valeur |
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 aimeraient être en mesure de 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 en retard pouvant aller jusqu'à 30 minutes, nous souhaitons empêcher les correspondances entre ce train et un autre train 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
Quatre champs facultatifs sont ajoutés au fichier transfers.txt :
from_route_idto_route_idfrom_trip_idto_trip_id
Les champs from_route_id et to_route_id peuvent contenir un identifiant d'itinéraire (défini
par le fichier routes.txt) afin de réduire le périmètre de la correspondance en question. Si la valeur from_route_id est définie, 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 champ from_stop_id. Si la valeur to_route_id est définie, 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 champ to_stop_id.
Les champs from_trip_id et to_trip_id peuvent contenir un identifiant de trajet trip_id, défini dans le fichier trips.txt. Si la valeur from_trip_id est indiquée, la valeur from_route_id est ignorée. De même, si la valeur to_trip_id est spécifiée, la valeur to_route_id est ignorée. Si la valeur from_trip_id est définie, la correspondance ne s'applique qu'au trajet à l'arrivée associé à l'identifiant de trajet concerné, à l'arrêt défini par le champ from_stop_id. Si la valeur to_trip_id est définie, la correspondance ne s'applique qu'au trajet au départ associé à l'identifiant de trajet concerné, à l'arrêt défini par le champ 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 afin de déterminer si une correspondance doit être appliquée. Nous définissons ainsi la "spécificité" d'une correspondance.
La valeur de spécificité de la source de la correspondance est 0 si seule la valeur from_stop_id est définie, 1 si la valeur from_route_id est définie et 2 si la valeur from_trip_id est définie. Le même principe s'applique à la cible de la correspondance : 0 si seule la valeur to_stop_id est définie, 1 si la valeur to_route_id est définie et 2 si la valeur to_trip_id est définie. La somme de ces deux valeurs, comprise entre 0 et 4 inclus, correspond à 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.