Disponible avec une licence Network Analyst.
Pour modéliser un service de transport en commun régulier dans un jeu de données réseau, il faut que le réseau comprenne certaines classes d’entités et tables, utilisant un schéma donné, qui définissent les arrêts et les lignes de transport, ainsi que les dates et heures de disponibilité du service de transport. Ces tables et ces classes d’entités, décrites ci-dessous, contiennent le modèle de données de transport en commun Network Analyst.
Ces tables et classes d’entités peuvent être utilisées dans le jeu de données réseau par des attributs de coût basés sur le temps configurés pour utiliser l’évaluateur Transport en commun, qui calcule le temps de trajet sur les lignes de transport à une heure donnée de la journée, en fonction des horaires de transport en commun définis dans le modèle de données.
Remarque :
Des classes d’entités et des tables de modèle de données valides peuvent être créées automatiquement à partir des données de transport en commun GTFS (General Transit Feed Specification) en exécutant les outils de géotraitement GTFS vers Sources de transport de jeux de données réseau et Connecter des sources de transport de jeux de données réseau aux rues. L’ensemble du workflow de création de ce jeu de données réseau est décrit dans la rubrique Créer et utiliser un jeu de données réseau configuré avec des données de transport en commun.
Le modèle de données de transport en commun Network Analyst comprend quatre classes d’entités qui doivent se trouver dans le jeu de classes d’entités où sera créé le jeu de données réseau, et sept tables qui doivent se trouver dans la géodatabase parent de ce jeu de classes d’entités. Les données doivent se trouver dans une géodatabase fichier ou une géodatabase d’entreprise ; le modèle de données de transport en commun ne prend pas en charge les shapefiles. En outre, étant donné que le modèle de données nécessite des classes d’entités et des tables portant des noms spécifiques, il est impossible d’ajouter plusieurs jeux de classes d’entités et de tables du modèle de données de transport en commun dans la même géodatabase. Vous pouvez ajouter des données de plusieurs agences de transport en commun au même jeu de classes d’entités et de tables, mais la géodatabase ne peut pas contenir plusieurs jeux de classes d’entités et de tables.
Le tableau suivant présente les classes d’entités et les tables du modèle de données, ainsi que les relations entre celles-ci :
Classes d’entités et tables du modèle de données de transport en commun
| Nom | Description | Type | Requis |
|---|---|---|---|
Définit l’emplacement et les caractéristiques des arrêts des transports en commun. La classe d’entités Stops est requise pour que le modèle de données puisse modéliser correctement un réseau de transport en commun ; toutefois, elle n’est pas utilisée directement par l’évaluateur Transport en commun. | Classe d'entités | Y | |
Définit les emplacements où les passagers doivent accéder aux arrêts à partir des rues ou des trottoirs. Cette classe d’entités sert principalement à assurer une connectivité réseau appropriée entre les rues et les lignes de transport en commun. La classe d’entités StopsOnStreets n’est pas requise par le modèle de données et elle n’est pas utilisée par l’évaluateur Transport en commun, mais elle est utile pour établir la connectivité du jeu de données réseau. | Classe d'entités | N | |
Crée une connexion entre un arrêt et son emplacement dans la rue tel que défini par l’entité StopsOnStreets associée. Cette classe d’entités sert principalement à assurer une connectivité réseau appropriée entre les rues et les lignes de transport en commun. La classe d’entités StopConnectors n’est pas requise par le modèle de données et elle n’est pas utilisée par l’évaluateur Transport en commun, mais elle est utile pour établir la connectivité du jeu de données réseau. | Classe d'entités | N | |
Entités polylignes qui définissent les lignes de transport en commun. Chaque entité LineVariantElements est connectée directement à deux arrêts adjacents. Dans le jeu de données réseau, le tronçon en entrée LineVariantElements doit utiliser l’évaluateur Transport en commun dans les attributs de coût pour modéliser le temps de trajet en transport en commun réel en fonction du service régulier. L’évaluateur Transport en commun calcule le temps de trajet sur un élément de variante de ligne à une heure donnée du jour en fonction des horaires de transport en commun, en interrogeant les tables du modèle de données de transport en commun. La longueur et la forme des éléments de variante de ligne ne sont pas utilisées par l’évaluateur Transport en commun, c’est pourquoi la géométrie des entités n’a pas d’importance. | Classe d'entités | Y | |
Définit les caractéristiques générales des lignes ou des itinéraires de transport en commun. | Tableau | Y | |
Définit les variations sur les lignes. Par exemple, une ligne de transport peut avoir deux terminus différents, certains trajets ayant le premier pour destination et les autres, le second. Chacun de ces parcours correspond à une variante de ligne. Chaque variante de ligne est composée de divers éléments. | Tableau | Y | |
Définit des modèles uniques de temps de trajet associés aux variantes de ligne. Par exemple, supposons qu’aux heures de pointe, le bus mette 5 minutes pour aller d’un arrêt à un autre, alors qu’il n’en met que 3 pendant les heures creuses. La table Schedules contient alors une entrée pour la première durée (5 minutes) et une autre entrée pour la seconde (3 minutes). | Tableau | Y | |
Définit les temps de trajet pour un horaire sur chaque élément de variante de ligne qui fait partie de la variante de ligne à laquelle l’horaire est associé. Une séquence d’éléments d’horaire définit les temps de trajet pour une séquence correspondante d’éléments de variante de ligne pour un horaire donné. | Tableau | Y | |
Définit les heures de début d’un déplacement selon le modèle de temps de trajet défini par un horaire donné. | Tableau | Y | |
Définit les jours de la semaine et les plages de dates de fonctionnement du service de transport en commun. La table Calendars est requise, mais elle n’est pas obligatoirement remplie, si vous ne souhaitez pas établir un service de transport régulier. Si cette table est vide, la table CalendarExceptions doit être alimentée. Ces tables peuvent également être utilisées ensemble. | Tableau | Y | |
Définit les exceptions au service régulier, par exemple les dates auxquelles un service de transport est ajouté ou supprimé. La table CalendarExceptions est requise, mais elle n’est pas obligatoirement remplie, si vous ne souhaitez pas définir d’exceptions au service de transport régulier. Si cette table est vide, la table Calendars doit être alimentée. Ces tables peuvent également être utilisées ensemble. | Tableau | Y |
Voir une version plus grande du modèle de données.
Classes d’entités
Les classes d’entités du modèle de données peuvent être utilisées en tant que classes d’entités source du jeu de données réseau. Les classes d’entités Stops et StopsOnStreets sont les sources de jonctions, et les classes d’entités LineVariantElements et StopConnectors sont les tronçons en entrée. Dans le jeu de données réseau, le tronçon en entrée LineVariantElements, qui représente les segments de la ligne de transport, doit utiliser l’évaluateur Transport en commun dans les attributs de coût basés sur le temps pour modéliser le temps de trajet en transport en commun en fonction du service régulier. Des groupes de connectivité peuvent être utilisés pour contrôler le trajet entre les rues et les lignes de transport à l’aide d’arrêts et d’entités de connexion.
Arrêts
La classe d’entités Stops définit l’emplacement et les caractéristiques des arrêts des transports en commun. Elle est requise pour que le modèle de données puisse modéliser correctement un réseau de transport en commun ; toutefois, elle n’est pas utilisée directement par l’évaluateur Transport en commun.
La classe d’entités Stops est l’équivalent du fichier GTFS stops.txt.
Le tableau suivant décrit le schéma de la classe d’entités Stops :
Arrêts
| Nom du champ | Description | Type | Requis | Accepte les valeurs nulles |
|---|---|---|---|---|
ObjectID | ObjectID de la ligne de la table. | ObjectID | Y | N |
Shape | Forme du point qui définit l’emplacement de l’arrêt. | Shape | Y | N |
ID | Identifiant unique de l’arrêt. | Longue | Y | N |
GStopID | stop_id GTFS de l’arrêt. Ce champ est fourni uniquement à titre informatif. | Texte | N | Y |
GStopType | Indique si cet arrêt représente un arrêt du réseau de transport en commun régulier, une station parent comportant un ou plusieurs arrêts réguliers, ou une entrée de station. Les valeurs possibles sont les suivantes :
Si un arrêt se trouve dans une station, le champ ParentID doit contenir la valeur ID d’un autre arrêt qui représente la station parent de cet arrêt. L’entité de la station parent doit avoir la valeur de GStopType 1 et l’arrêt doit avoir la valeur de GStopType 0 (ou Null). Les stations parent ne peuvent pas être les parents d’autres stations parent. Si une entité représente une entrée de station (GStopType 2), le champ ParentID doit être présent et il doit contenir la valeur d’ID d’un autre arrêt qui représente la station parent dont cette entité est une entrée. Une entrée de station ne peut pas avoir un arrêt régulier comme parent. Seules les stations parent peuvent avoir des entrées de station. Si le champ GStopType ne se trouve pas dans la table, tous les arrêts sont considérés comme des arrêts réguliers du réseau de transport en commun (GStopType 0). Dans ce cas, toute valeur éventuellement définie dans le champ ParentID est ignorée. Le champ GStopType équivaut au champ GTFS location_type du fichier stops.txt. | Courte | N | Y |
ParentID | Valeur ID de la station parent de l’arrêt ou de l’entrée de station en cours. L’arrêt ayant la valeur ID référencée doit avoir la valeur GStopType 1. | Longue | N | Y |
GStopParen | stop_id GTFS de la station parent de l’arrêt ou de l’entrée de station. Ce champ est fourni uniquement à titre informatif. | Texte | N | Y |
GWheelchairBoarding | Indique si l’arrêt, la station ou l’entrée de station est accessible aux fauteuils roulants. Les valeurs possibles sont les suivantes :
Si l’entité représente un arrêt (GStopType 0) ou une entrée de station (GStopType 2) et que la valeur de GWheelchairBoarding est 0 ou Null, la valeur GWheelchairBoarding de l’entité provient de la station parent du champ ParentID, si elle est définie. Le champ GWheelchairBoarding équivaut au champ GTFS wheelchair_boarding du fichier stops.txt. | Courte | N | Y |
StopsOnStreets
La classe d’entités StopsOnStreets définit les emplacements où les passagers peuvent accéder aux arrêts à partir des rues ou des trottoirs. Les entités StopsOnStreets peuvent représenter les emplacements des entrées de station ou le point croisant une rue ou un trottoir le plus proche de l’emplacement de l’arrêt pour garantir la connectivité réseau.
La classe d’entités StopsOnStreets n’est pas requise par le modèle de données, mais elle permet d’établir la connectivité du jeu de données réseau, étant donné qu’il est peu probable que les arrêts se trouvent directement en haut des rues. Si vous avez l’intention de modéliser des voyageurs qui marchent dans les rues et utilisent le réseau de transport en commun, il vous faut un moyen de contrôler les connexions entre les lignes de transport et les rues, c’est pourquoi l’utilisation de cette classe d’entités est conseillée.
Aucun schéma n’est requis pour la classe d’entités StopsOnStreets. Si vous créez cette classe d’entités à l’aide de l’outil Connecter des sources de transport de jeux de données réseau aux rues, son schéma sera le même que celui de la classe d’entités Stops. Toutefois, cette classe d’entités n’étant pas utilisée par l’évaluateur Transport en commun, vous pouvez utiliser les champs les plus adaptés à la situation que vous modélisez.
StopConnectors
La classe d’entités StopConnectors définit des entités polylignes pour relier les arrêts aux rues à l’aide d’entités StopsOnStreets correspondantes. Cette classe d’entités sert principalement à assurer une connectivité réseau appropriée entre les rues et les lignes de transport en commun. Un voyageur peut ainsi marcher dans la rue, accéder à un arrêt d’un transport en commun, utiliser le service régulier d’une ligne de transport (une entité LineVariantElements), quitter cette ligne à un autre arrêt, puis regagner la rue pour atteindre sa destination à pied.
La classe d’entités StopConnectors n’est pas requise par le modèle de données et elle n’est pas utilisée par l’évaluateur Transport en commun. Toutefois, étant donné qu’il est peu probable que les arrêts se trouvent directement en haut des rues, la présence d’un connecteur est recommandée pour garantir la connectivité entre les lignes de transport et les rues.
Le tableau suivant décrit le schéma de la classe d’entités StopConnectors :
StopConnectors
| Nom du champ | Description | Type | Requis | Accepte les valeurs nulles |
|---|---|---|---|---|
ObjectID | ObjectID de la ligne de la table. | ObjectID | Y | N |
Shape | Forme polyligne de l’entité. Le sens de numérisation des entités de connecteurs d’arrêts doit aller des arrêts vers les rues. | Shape | Y | N |
StopID | Valeur du champ ID de l’arrêt que cette entité StopConnectors connecte aux rues. | Longue | N | Y |
ConnectorType | Indique le type de connexion que cette entité établit entre l’arrêt et les rues. La valeur ConnectorType indique si cette ligne de connecteur représente une connexion directe entre l’arrêt et la rue, une connexion de l’arrêt vers sa station parent ou une connexion d’une station parent vers une entrée de station. Les valeurs possibles sont les suivantes :
Ce champ n’est pas requis mais il peut être utile pour configurer des évaluateurs pour les attributs de coût ou de restriction. Par exemple, votre attribut de coût peut ajouter plusieurs durées de marche, selon la valeur du champ ConnectorType. | Courte | N | Y |
GWheelchairBoarding | Indique si le trajet entre l’arrêt et la rue représenté par cette ligne de connecteur est accessible aux fauteuils roulants. Les valeurs possibles sont les suivantes :
Ce champ est utile pour créer des attributs de restriction dans le jeu de données réseau afin de modéliser les passagers en fauteuil roulant. | Courte | N | Y |
LineVariantElements
La classe d’entités LineVariantElements définit des polylignes qui représentent les lignes de transport en commun. Chaque élément de variante de ligne représente un trajet sur une ligne entre deux arrêts adjacents.
Dans le jeu de données réseau, le tronçon en entrée LineVariantElements doit utiliser l’évaluateur Transport en commun dans les attributs de coût pour modéliser le temps de trajet en transport en commun en fonction du service régulier. L’évaluateur Transport en commun calcule le temps de trajet sur un élément de variante de ligne à une heure donnée du jour en fonction des horaires de transport en commun, en interrogeant les tables du modèle de données de transport en commun. La longueur et la forme des éléments de variante de ligne ne sont pas utilisées par l’évaluateur Transport en commun, c’est pourquoi la géométrie réelle n’a pas d’importance.
Le tableau suivant décrit le schéma de la classe d’entités LineVariantElements :
LineVariantElements
| Nom du champ | Description | Type | Requis | Accepte les valeurs nulles |
|---|---|---|---|---|
ObjectID | ObjectID de la ligne de la table. | ObjectID | Y | N |
Shape | Forme polyligne du segment de ligne de transport en commun. La longueur et la forme de l’entité linéaire ne sont pas utilisées par l’évaluateur Transport en commun pour calculer le temps de trajet. Celui-ci est basé sur les horaires de transport en commun stockés dans les tables du modèle de données. Par conséquent, bien que les éléments de variante de ligne doivent avoir des formes pour modéliser la connectivité dans le jeu de données réseau, les formes elles-mêmes ne sont pas prises en compte pour le calcul du temps de trajet. Si vous créez vos tables de modèle de données à partir de données GTFS à l’aide de l’outil GTFS vers Sources de transport de jeux de données réseau, les éléments de variante de ligne sont de simples lignes droites qui relient des arrêts adjacents et ne représentent pas les trajets géographiques parcourus par les véhicules du réseau de transport. | Shape | Y | N |
LineVarID | Valeur du champ ID de la variante de ligne dont fait partie cet élément de variante de ligne. Une variante de ligne se compose d’une séquence ordonnée d’éléments de variante de ligne qui relient une séquence spécifique d’arrêts le long d’une ligne de transport. | Longue | Y | N |
SqIdx | Une variante de ligne se compose d’une séquence ordonnée d’éléments de variante de ligne qui relient une séquence spécifique d’arrêts le long d’une ligne de transport. Le champ SqIdx représente la séquence le long de la ligne de transport qui contient cet élément de variante de ligne, en commençant par 1. Par exemple, si une variante de ligne comprend 10 éléments de variante de ligne, le champ SqIdx du premier élément a la valeur 1. Le champ SqIdx du deuxième élément de variante de ligne a la valeur 2 et le champ SqIdx du dernier (dixième) élément a la valeur 10. Les valeurs de champ SqIdx dans la table ScheduleElements doivent correspondre aux valeurs SqIdx définies ici pour les éléments de variante de ligne. | Courte | Y | N |
FromStopID | Un élément de variante de ligne représente un trajet sur une ligne entre deux arrêts adjacents. Le champ FromStopID indique la valeur du champ ID de l’arrêt d’où part le service de transport sur cet élément de variante de ligne. Le service de transport sur cet élément de variante de ligne va du FromStopID au ToStopID. | Longue | N | Y |
ToStopID | Une entité d’élément de variante de ligne représente un trajet sur une ligne entre deux arrêts adjacents. Le champ ToStopID indique la valeur du champ ID de la destination ou de l’arrêt où arrive le service de transport sur cet élément de variante de ligne. Le service de transport sur cet élément de variante de ligne va du FromStopID au ToStopID. | Longue | N | Y |
Tables
Les tables du modèle de données définissent les horaires de transport en commun. Ces tables sont utilisées par l’évaluateur Transport en commun pour déterminer le temps de trajet le long d’une entité LineVariantElements à une heure donnée de la journée, en fonction du service de transport régulier.
Lignes
La table Lines définit les lignes ou les itinéraires de transport et leurs caractéristiques. Une ligne est l’équivalent d’un itinéraire GTFS.
Le tableau suivant décrit le schéma de la table Lines :
Lignes
| Nom du champ | Description | Type | Requis | Accepte les valeurs nulles |
|---|---|---|---|---|
ObjectID | ObjectID de la ligne de la table. | ObjectID | Y | N |
ID | Identifiant unique de la ligne de transport. | Longue | Y | N |
GRouteID | route_id GTFS de la ligne. Ce champ est fourni uniquement à titre informatif. | Texte | N | Y |
GRouteType | Mode de transport en commun que cette ligne représente. Les valeurs possibles sont les suivantes :
Le champ GRouteType équivaut au champ GTFS route_type du fichier routes.txt. | Courte | N | Y |
LineVariants
La LineVariants définit les variations sur les lignes. Par exemple, une ligne de transport peut avoir deux terminus différents, certains trajets ayant le premier pour destination et les autres, le second. Une variante de ligne se compose d’une séquence ordonnée d’éléments de variante de ligne qui relient une séquence spécifique d’arrêts le long d’une ligne de transport.
Le tableau suivant décrit le schéma de la table LineVariants :
LineVariants
| Nom du champ | Description | Type | Requis | Accepte les valeurs nulles |
|---|---|---|---|---|
ObjectID | ObjectID de la ligne de la table. | ObjectID | Y | N |
ID | Identifiant unique de la variante de ligne. | Longue | Y | N |
LineID | Valeur du champ ID de la ligne de Lines dont cette variante fait partie. Plusieurs variantes de ligne peuvent avoir le même LineID, chacune représentant un modèle différent d’éléments de variante de ligne associés à une ligne donnée. | Longue | Y | N |
Schedules
La table Schedules définit des modèles uniques de temps de trajet associés aux variantes de ligne. Par exemple, supposons qu’aux heures de pointe, le bus mette 5 minutes pour aller d’un arrêt à un autre, alors qu’il n’en met que 3 pendant les heures creuses. La table Schedules contient alors une entrée pour la première durée (5 minutes) et une autre entrée pour la seconde (3 minutes). Les composants individuels de l’horaire sont définis dans la table ScheduleElements. Les horaires sont propres aux variantes de ligne.
Le tableau suivant décrit le schéma de la table Schedules :
Schedules
| Nom du champ | Description | Type | Requis | Accepte les valeurs nulles |
|---|---|---|---|---|
ObjectID | ObjectID de la ligne de la table. | ObjectID | Y | N |
ID | Identifiant unique de l’horaire. | Longue | Y | N |
LineVarID | Valeur du champ ID de la ligne de la table LineVariants à laquelle cet horaire est associé. | Longue | Y | N |
ScheduleElements
La table ScheduleElements définit les temps de trajet sur chaque élément de variante de ligne pour un horaire donné. Une séquence ordonnée d’éléments d’horaire définit les temps de trajet pour une séquence correspondante d’éléments de variante de ligne pour un horaire donné. La table ScheduleElements doit contenir une séquence de lignes pour chaque ligne de la table Schedules.
Le tableau suivant décrit le schéma de la table ScheduleElements :
ScheduleElements
| Nom du champ | Description | Type | Requis | Accepte les valeurs nulles |
|---|---|---|---|---|
ObjectID | ObjectID de la ligne de la table. | ObjectID | Y | N |
ScheduleID | Valeur du champ ID de la ligne de la table Schedules à laquelle cet élément d’horaire est associé. Un horaire se compose d’une séquence ordonnée d’éléments d’horaire. | Longue | Y | N |
SqIdx | Un horaire se compose d’une séquence ordonnée d’éléments d’horaire, chacun correspondant à un élément de la variante de ligne référencée par la table Schedules et la classe d’entités LineVariantElements. Le champ SqIdx représente la séquence de l’élément de variante de ligne sur la ligne de transport à laquelle cet élément d’horaire fait référence, en commençant par 1. Par exemple, si une variante de ligne comprend 10 éléments de variante de ligne, le champ SqIdx du premier élément a la valeur 1. Le champ SqIdx du deuxième élément de variante de ligne a la valeur 2 et le champ SqIdx du dernier (dixième) élément a la valeur 10. Les valeurs SqIdx correspondant à chaque élément d’horaire doivent correspondre aux valeurs SqIdx dans la classe d’entités LineVariantElements. Dans l’exemple ci-dessus, supposons que la variante de ligne soit associée à un horaire donné. Le premier élément cet horaire doit avoir la valeur SqIdx 1, le deuxième la valeur 2 et le dernier (dixième) doit avoir la valeur 10, comme les éléments de variante de ligne. Si un autre horaire est associé à la variante de ligne mentionnée précédemment, la table ScheduleElements doit également contenir une séquence de lignes comportant la même séquence de valeurs SqIdx que celle qui définit les temps de trajet associés à l’horaire supplémentaire. | Courte | Y | N |
Departure | Nombre de minutes à partir de 0 au bout duquel le véhicule de transport quitte l’arrêt de départ de l’élément de variante de ligne qui a le même LineVarID que l’horaire et le même SqIdx que cet élément d’horaire. Si le départ intervient 20 minutes après le départ du premier arrêt de la ligne, la valeur du champ Departure est 20. La valeur Departure d’un élément d’horaire dont la valeur SqIdx est 1 doit toujours être 0. | Double | Y | N |
Arrival | Nombre de minutes à partir de 0 au bout duquel le véhicule de transport arrive au dernier arrêt de l’élément de variante de ligne qui a le même LineVarID que l’horaire et le même SqIdx que cet élément d’horaire. Si l’arrivée au dernier arrêt de ce segment a lieu 23 minutes après le départ du premier arrêt de la ligne, la valeur du champ Arrival est 23. | Double | Y | N |
Runs
La table Runs définit les heures de départ spécifiques auxquelles un déplacement commence le long d’une séquence d’éléments de variante de ligne en utilisant les temps de trajet définis par un horaire donné. Un trajet est l’équivalent d’un trajet GTFS. La table Runs définit également si le véhicule qui parcourt l’itinéraire à cette heure de la journée est accessible aux fauteuils roulants et aux vélos.
Le tableau suivant décrit le schéma de la table Runs :
Runs
| Nom du champ | Description | Type | Requis | Accepte les valeurs nulles |
|---|---|---|---|---|
ObjectID | ObjectID de la ligne de la table. | ObjectID | Y | N |
ID | Identifiant unique du trajet. | Longue | Y | N |
ScheduleID | Valeur du champ ID de la ligne de la table Schedules à laquelle ce trajet est associé. Cette valeur définit le modèle de temps de trajet suivi par ce trajet. | Longue | Y | N |
StartRun | Nombre de minutes après minuit au bout duquel le véhicule de transport part du premier arrêt. Par exemple, si le trajet commence à 8:00, la valeur de StartRun doit être 480, étant donné que 8:00 correspond à 8 heures, ou 480 minutes, après minuit. | Double | Y | N |
GTripID | trip_id GTFS auquel ce trajet est associé. Ce champ est fourni uniquement à titre informatif. | Texte | N | Y |
CalendarID | Valeur du champ ID de la ligne de la table Calendars et valeur du champ CalendarID correspondante dans la table CalendarExceptions qui définit les jours de la semaine ou les dates auxquels ce trajet est assuré. | Longue | Y | N |
GWheelchairAccessible | Indique si le trajet est accessible aux fauteuils roulants. Les valeurs possibles sont les suivantes :
Ce champ est facultatif. Si ce champ est omis, l’évaluateur Transport en commun considère tous les trajets comme accessibles aux voyageurs en fauteuil roulant. Le champ GWheelchairAccessible équivaut au champ GTFS wheelchair_accessible du fichier trips.txt. | Courte | N | Y |
GBikesAllowed | Indique si les vélos sont autorisés sur ce trajet. Les valeurs possibles sont les suivantes :
Ce champ est facultatif. Si ce champ est omis, l’évaluateur Transport en commun considère tous les trajets comme accessibles aux voyageurs à vélo. Le champ GBikesAllowed équivaut au champ GTFS bikes_allowed du fichier trips.txt. | Courte | N | Y |
Calendars
La table Calendars définit les jours de la semaine et les plages de dates de fonctionnement du service de transport en commun.
Lors de la résolution d’analyses de réseau avec des dates spécifiques, l’évaluateur Transport en commun tient compte de la plage de dates définies par les champs StartDate et EndDate de la table Calendars. Lors de la résolution d’analyses de réseau avec un jour de la semaine générique, les champs StartDate et EndDate sont ignorés et seuls les champs de jour de la semaine, par exemple Monday, sont utilisés pour définir le service de transport qui fonctionne le jour de l’analyse.
Cette table est requise par le modèle de données, mais elle n’est pas obligatoirement remplie, si vous ne souhaitez pas établir un service de transport régulier. Toutefois, Calendars ou CalendarExceptions doit contenir des lignes. Si Calendars et CalendarExceptions sont alimentées, CalendarExceptions modifie le service régulier défini dans Calendars.
Le tableau suivant décrit le schéma de la table Calendars :
Calendars
| Nom du champ | Description | Type | Requis | Accepte les valeurs nulles |
|---|---|---|---|---|
ObjectID | ObjectID de la ligne de la table. | ObjectID | Y | N |
ID | Identifiant unique du calendrier. | Longue | Y | N |
GServiceID | service_id GTFS auquel ce calendrier est associé. Ce champ est fourni uniquement à titre informatif. | Texte | N | Y |
Monday | Indique si les trajets qui ont cette valeur CalendarID fonctionnent les lundis. Les valeurs possibles sont les suivantes :
| Courte | Y | N |
Tuesday | Indique si les trajets qui ont cette valeur CalendarID fonctionnent les mardis. Les valeurs possibles sont les suivantes :
| Courte | Y | N |
Wednesday | Indique si les trajets qui ont cette valeur CalendarID fonctionnent les mercredis. Les valeurs possibles sont les suivantes :
| Courte | Y | N |
Thursday | Indique si les trajets qui ont cette valeur CalendarID fonctionnent les jeudis. Les valeurs possibles sont les suivantes :
| Courte | Y | N |
Friday | Indique si les trajets qui ont cette valeur CalendarID fonctionnent les vendredis. Les valeurs possibles sont les suivantes :
| Courte | Y | N |
Saturday | Indique si les trajets qui ont cette valeur CalendarID fonctionnent les samedis. Les valeurs possibles sont les suivantes :
| Courte | Y | N |
Sunday | Indique si les trajets qui ont cette valeur CalendarID fonctionnent les dimanches. Les valeurs possibles sont les suivantes :
| Courte | Y | N |
StartDate | Début de la plage de dates à laquelle le service de transport en commun décrit par ce jeu de données fonctionne. Lors de la résolution d’analyses de réseau avec des dates spécifiques, l’évaluateur Transport en commun utilise uniquement les trajets qui ont cette valeur CalendarID si la date d’analyse est comprise dans la plage de dates allant de StartDate à EndDate. La plage de dates allant de StartDate à EndDate est ignorée lors de la résolution d’analyses de réseau avec un jour de la semaine générique ; dans ce cas, seuls les champs de jour de la semaine, tels que Monday, sont utilisés. | Date | N | N |
EndDate | Fin de la plage de dates à laquelle le service de transport en commun décrit par ce jeu de données fonctionne. La date indiquée par EndDate est comprise dans cette plage de dates. Lors de la résolution d’analyses de réseau avec des dates spécifiques, l’évaluateur Transport en commun utilise uniquement les trajets qui ont cette valeur CalendarID si la date d’analyse est comprise dans la plage de dates allant de StartDate à EndDate. La plage de dates allant de StartDate à EndDate est ignorée lors de la résolution d’analyses de réseau avec un jour de la semaine générique ; dans ce cas, seuls les champs de jour de la semaine, tels que Monday, sont utilisés. | Date | N | N |
CalendarExceptions
La table CalendarExceptions définit les exceptions au service de transport en commun régulier, par exemple les dates auxquelles un service de transport est ajouté ou supprimé. L’évaluateur Transport en commun n’utilise les dates d’exception de cette table que si l’analyse de réseau est configurée pour utiliser des dates spécifiques, et non des jours de la semaine génériques.
Cette table est requise par le modèle de données, mais elle n’est pas obligatoirement remplie, si vous ne souhaitez pas définir d’exceptions aux service de transport en commun régulier. Toutefois, Calendars ou CalendarExceptions doit contenir des lignes. Si Calendars et CalendarExceptions sont alimentées, CalendarExceptions modifie le service régulier défini dans Calendars. Si la table Calendars est vide, tout le service de transport en commun est défini dans CalendarExceptions en ajoutant explicitement un service à des dates spécifiques. Le cas échéant, une date spécifique doit être utilisée pour l’analyse du réseau au lieu d’un jour de la semaine générique.
Le tableau suivant décrit le schéma de la table CalendarExceptions :
CalendarExceptions
| Nom du champ | Description | Type | Requis | Accepte les valeurs nulles |
|---|---|---|---|---|
ObjectID | ObjectID de la ligne de la table. | ObjectID | Y | N |
CalendarID | ID de l’exception qui peut correspondre ou pas à une valeur du champ ID dans la table Calendars. Si cette valeur figure dans Calendars, l’exception modifie le service régulier défini ici. Il n’est pas nécessaire que les valeurs de ce champ soient uniques, mais chaque combinaison unique de valeurs CalendarID et ExceptionDate doit apparaître une seule fois. | Longue | Y | N |
GServiceID | service_id GTFS auquel ce champ CalendarException est associé. Ce champ est fourni uniquement à titre informatif. | Texte | N | Y |
ExceptionDate | Date à laquelle le service de transport décrit par cette exception est ajouté ou supprimé. | Date | Y | N |
GExceptionType | Indique si le service de transport est ajouté ou supprimé à la date décrite par le champ ExceptionDate. Les valeurs possibles sont les suivantes :
Le champ GExceptionType équivaut au champ GTFS exception_type du fichier calendar_dates.txt. | Courte | Y | N |
Vous avez un commentaire à formuler concernant cette rubrique ?