Avant-propos
L’harmonisation des pratiques dans l’échange des données relatives aux offres de transport est essentielle :
pour l’usager, aux fins d’une présentation homogène et compréhensible de l’offre de transport et de l’engagement sous-jacent des organisateurs (autorités organisatrices et opérateurs de transports) ;
pour les AOT, de manière à fédérer des informations homogènes venant de chacun des opérateurs de transports qui travaillent pour elle. L’harmonisation des échanges, et en particulier le présent profil, pourra le cas échéant être imposé par voie contractuelle. Cette homogénéité des formats d’information permet d’envisager la mise en place de systèmes d’information multimodaux, produisant une information globale de l’offre de transports sur un secteur donné, et garantir le fonctionnement des services d’information, en particulier des calculateurs d’itinéraires, et la cohérence des résultats, que ces services soient directement intégrés dans ces systèmes d’information multimodaux ou qu’ils puisent leurs informations sur des bases de données réparties ;
pour les opérateurs, qui pourront utiliser ce format d’échange pour leurs systèmes de planification, les systèmes d’aide à l’exploitation, leurs systèmes billettiques et leurs systèmes d’information voyageur (information planifiée et information temps réel)
pour les industriels et développeurs pour pérenniser et fiabiliser leurs investissements sur les formats d’échanges implémentés par les systèmes qu’ils réalisent, tout en limitant fortement l’effort de spécification lié aux formats d’échange
Ce document est le fruit de la collaboration entre les différents partenaires des autorités organisatrices de transports, opérateurs, industriels et développeurs de solutions et de systèmes informatiques ayant pour objet l’aide à l’exploitation du transport public et l’information des voyageurs. Il a pour objet de présenter le profil d’échange Profil NeTEx Horaires: “format de référence pour l’échange de données de description des horaires” (issu des travaux NeTEx, Transmodel et IFOPT) qui aujourd’hui fait consensus dans les groupes de normalisation (CN03/GT7 – Transport public / information voyageur).
Introduction
Le présent format d’échange est un profil de NeTEx.
NeTEx (CEN TS 16614-1, 16614-2 et 16614-3) propose un format et des services d’échange de données de description de l’offre de transport planifiée, basé sur Transmodel (EN 12896) et l’ancienne norme IFOPT (EN 28701). NeTEx permet non seulement d’assurer les échanges pour les systèmes d’information voyageur mais traite aussi l’ensemble des concepts nécessaires en entrée et sortie des systèmes de planification de l’offre (graphiquage, etc.) et des SAE (Systèmes d’Aide à l’Exploitation).
NeTEx se décompose en trois parties:
Partie 1 : topologie des réseaux (les réseaux, les lignes, les parcours commerciaux les missions commerciales, les arrêts et lieux d’arrêts, les correspondances et les éléments géographiques en se limitant au strict minimum pour l’information voyageur)
Partie 2 : horaires théoriques (les courses commerciales, les heures de passage graphiquées, les jours types associés ainsi que les versions des horaires)
Partie 3 : information tarifaire (uniquement à vocation d’information voyageur)
NeTEx a été développé dans le cadre du CEN/TC 278/WG 3/SG 9 piloté par la France. Les parties 1 et 2 ont été publiées en tant que spécification technique début 2014. Les travaux pour la partie 3, quant à eux, se termineront courant 2014sont terminés en 2016.
Il faut noter que NeTEx a été l’occasion de renforcer les liens du CEN/TC278/WG3 avec le secteur ferrovaire, en particulier grâce à la participation de l’ERA (Agence Européen du Rail, qui a intégré NeTEx dans la directive Européenne 454/2011 TAP-TSI ) et de l’UIC (Union International des Chemins de fer).
Les normes, dans leur définition même, sont des « documents établis par consensus ». Celles du CEN/TC278 sont de plus établies à un niveau européen, en prenant donc en compte des exigences qui dépassent souvent le périmètre national.
Il en résulte des normes qui sont relativement volumineuses et dont le périmètre dépasse souvent largement les besoins d’une utilisation donnée. Ainsi, à titre d’exemple, SIRI propose toute une série d’options ou de mécanismes dont la vocation est d’assurer la compatibilité avec les systèmes développés en Allemagne dans le contexte des VDV 453/454. De même, SIRI propose des services dédiés à la gestion des correspondances garanties, services qui, s’ils sont dès aujourd’hui pertinents en Suisse ou en Allemagne, sont pratiquement inexistants en France.
De plus, un certain nombre de spécificités locales ou nationales peuvent amener à préciser l’usage ou la codification qui sera utilisée pour certaines informations. Par exemple, les Anglais disposant d’un référentiel national d’identification des points d’arrêts (NaPTAN), ils imposeront naturellement que cette codification soit utilisée dans les échanges SIRI, ce que ne feront pas les autres pays européens.
Enfin, certains éléments proposés par ces normes sont facultatifs et il convient, lors d’une implémentation, de décider si ces éléments seront ou non implémentés.
L’utilisation des normes liées à l’implémentation de l’interopérabilité pour le transport en commun passe donc systématiquement par la définition d’un profil (local agreement, en anglais). Concrètement, le profil est un document complémentaire à la norme et qui en précise les règles de mise en œuvre dans un contexte donné. Le profil contient donc des informations comme :
détail des services utilisés,
détails des objets utilisés dans un échange,
précisions sur les options proposées par la norme,
précision sur les éléments facultatifs,
précision sur les codifications à utiliser,
etc.
Les principaux profils actuellement utilisés en France sont NEPTUNE (profil de TRIDENT) et le profil de SIRI défini par le CEREMA et Île-de-France Mobilités. Ces deux profils ont une vocation nationale. Le groupe de travail GT7 (AFNOR BNTRA/CN 03/GT 7) a élaboré une sélection des concepts Transmodel nécessaire à la description des horaires en France (à vocation d’information voyageur essentiellement). C’est sur la base de cette sélection qu’est élaboré le présent profil.
D’autre profils de NeTEx sont disponibles (arrêt, réseau, tarif). Ils sont tous complémentaires les uns des autres (sans recouvrement) et s’appuient tous sur un document partagé: NeTEx - Profil Français de NETEx: éléments communs. Il conviendra de se référer à ce document pour tous les éléments utilisés dans le présent document, et dont la structure n’est pas détaillée.
Ce profil d’échange a pour objectif de décrire et de structurer précisément les éléments nécessaires à une bonne information de description des horaires de transport public de façon :
à pouvoir les présenter d’une manière homogène et compréhensible à l’usager des transports publics sur des supports différents (papier ou Internet),
à pouvoir les échanger entre systèmes d’information (systèmes d’information voyageurs et systèmes d’information multimodale, systèmes d’aide à l’exploitation, systèmes de planification, systèmes billettiques, etc.).
Les éléments présentés ci-dessous couvrent donc l’ensemble des concepts propres à la description des horaires.
NOTE IMPORTANTE Ce document étant un profil d’échange de NeTEx, il ne se substitue en aucun cas à NeTEx, et un minimum de connaissance de NeTEx sera nécessaire à sa bonne compréhension.
Domaine d’application
Le présent document est le profil de la CEN/TS 6614 (NeTEx) pour l’échange de données de description des horaires en France et permet de décrire les horaires de transports publics et la manière dont ils pourront être structurés pour des échanges entre systèmes d’information ainsi que pour leur présentation aux voyageurs.
Ce sont les services de transport et leurs horaires au sens large (heures de passage, fréquences, jours d’application) qui sont pris en compte dans ce contexte, et non la structure de l’offre de transport (voir les profils arrêt et réseau pour cela).
Références normatives
Les documents de référence suivants sont indispensables pour l’application du présent document. Pour les références datées, seule l’édition citée s’applique. Pour les références non datées, la dernière édition du document de référence s’applique (y compris les éventuels amendements).
CEN/TS 16614-1, Network and Timetable Exchange (NeTEx) — Part 1: Public transport network topology exchange format
CEN/TS 16614-2, Network and Timetable Exchange (NeTEx) — Part 2: Public transport scheduled timetables exchange format
EN 12896, Road transport and traffic telematics - Public transport - Reference data model (Transmodel)
Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s’appliquent. Ils sont directement issus de Transmodel et NeTEx. L’Error: Reference source not found complète ces définitions par des explications plus détaillées. Pour une information complète, il conviendra toutefois de se référer au document normatif.
NOTE Les termes spécifiquement introduits par le profil d’arrêt sont signalés par le mot (profil), en italique et entre parenthèses. Les définitions ci-dessus sont des traductions littérales du document normatif.
COUPLED JOURNEY (COURSE COUPLÉE)
Un voyage complet opéré par un train couplé, composé de deux COURSES, ou plus, restant couplées tout au long d’un PARCOURS. Une COURSE COUPLÉE peut être considérée comme une simple COURSE.
DATED PASSING TIME (HEURE DE PASSAGE DATÉE)
HEURE DE PASSAGE pour un JOUR D’EXPLOITATION donné. Cet objet restera abstrait dans le contexte de ce profil et ne sera utiliséutilisé qu’au travers de sa spécialisation en HEURE DE PASSAGE COMMANDÉE.
DATED VEHICLE JOURNEY (COURSE DATÉE)
Service service particulier d’un véhicule sur un jour de fonctionnement particulier, y compris toutes les modifications éventuellement décidées par le personnel de contrôle. Cet objet restera abstrait dans le contexte de ce profil et ne sera utilisé qu’au travers de sa spécialisation en COURSE DATÉE NORMALE.
DEAD RUN (HAUT LE PIED)
Un service voiture haut-le-pied (non commercial).
DEFAULT INTERCHANGE (CORRESPONDANCE PAR DEFAUT)
Paramètre définissant la durée acceptable (maximum autorisée et objectif de durée standard) pour une correspondance entre deux POINTS D’ARRÊT.
FLEXIBLE SERVICE PROPERTIES (PROPRIÉTÉS DE COURSE FLEXIBLE)
Propriété supplémentaire d’un service permettant de caractériser sa flexibilité. Un service peut n’être que partiellement flexible.
HEADWAY INTERVAL (INTERVAL)
Intervalle temporel caractérisant un GROUPE DE COURSE À INTERVALLE (par exemple toutes les 10 minutes ou toutes les 4 à 6 minutes).
HEADWAY JOURNEY GROUP (GROUPE DE COURSES EN FRÉQUENCE)
Groupe de COURSEs suivant le même PARCOURS et dont les départs sont séparés d’un intervalle temporel fixe au sein d’un créneau horaire donné (par exemple toutes les 10 minutes entre 8h et 10h30). Cette information est particulièrement utile dans le cadre de l’information voyageur. Le créneau horaire est exprimé par l’objet TIME BAND.
INTERCHANGE (CORRESPONDANCE DE COURSES)
Une possibilité théorique de correspondance entre courses intervenant à un seul POINT D’ARRÊT ou entre différents POINTs D’ARRÊT.
JOURNEY FREQUENCY GROUP (GROUPE DE COURSES EN FRÉQUENCE)
Définit un groupe de COURSEs afin de leur attribuer un comportement particulier comme un service en fréquence ou un service cadencé (passe toutes les heures ..h10, ..h25 et ..h45 par exemple).
JOURNEY PART (PARTIE DE COURSE)
Une partie d’une COURSE créée dans un but fonctionnel spécifique, notamment dans les situations lors de couplage ou de séparation de véhicule.
JOURNEY PART COUPLE (COUPLE DE PARTIES DE COURSE)
Deux PARTIEs DE COURSEs de différentes COURSES effectuées simultanément par un train constitué par le couplage de plusieurs véhicules ou rames.
NORMAL DATED VEHICLE JOURNEY (COURSE DATÉE NORMALE)
Une COURSE DATÉE correspondant à la planification du parcours des véhicules.
PASSING TIME (HEURE DE PASSAGE)
Données temporelles concernant le passage des véhicules de transport public à un POINT particulier (par exemple heure d’arrivée, heure de départ, temps d’attente).
RHYTMHICAL JOURNEY GROUP (GROUPE DE COURSES CADENCÉES)
Groupe de COURSEs suivant le même PARCOURS et répétant le même rythme de départ toutes les heures (passe toutes les heures ..h10, ..h25 et ..h45 par exemple) et ce dans un créneau horaire donnée. Le créneau horaire est exprimé par l’objet TIME BAND sur le schéma.
SERVICE JOURNEY (COURSE COMMERCIALE)
Une COURSE transportant des passagers prévus pour un JOUR TYPE donné. Le déroulement est en principe défini par le PARCOURS COMMERCIAL.
SERVICE JOURNEY INTERCHANGE (CORRESPONDANCE DE COURSES COMMERCIALES)
Une possibilité théorique de correspondance entre COURSEs COMMERCIALEs intervenant à un seul POINT D’ARRÊT ou entre différents POINTs D’ARRÊT.
TARGET PASSING TIME (HEURE DE PASSAGE COMMANDÉE)
Données temporelles indiquant l’objectif à atteindre quant au passage du véhicule à un POINT SUR PARCOURS particulier pour une COURSE DATÉE afin de respecter l’horaire en vigueur. Concrètement il s’agit de l’adaptation des HEUREs DE PASSAGE DATÉEs faite en exploitation pour prendre en compte les changements de condition d’exploitation en amont du départ du véhicule (travaux, etc.).
TEMPLATE SERVICE JOURNEY (MODÈLE DE COURCE COMMERCIALE)
COURSE DE RÉFÉRENCE transportant des voyageurs.
TEMPLATE VEHICLE JOURNEY (COURSE DE RÉFÉRENCE)
COURSE modèle dont l’occurrence a été spécifiée au sein d’un GROUPE DE COURSE À INTERVALLE ou d’un GROUPE DE COURSE CADENCÉ; elle peut donc représenter un grand nombre de COURSEs.
TIMETABLE PASSING TIME (HEURE DE PASSAGE PLANIFIÉE)
Donnée temporelle théorique relative au passage d’un véhicule de transport public à un POINT SUR PARCOURS donné sur une COURSE et pour un JOUR TYPE. On notera qu’il ne s’agit pas d’une simple heure de franchissement, mais que cette heure de passage est constituée de l’heure de d’arrivée et de départ ainsi que d’informations associées (quai, marges d’erreur, etc.).
TRAIN (TRAIN)
Un véhicule composé d’ÉLÉMENTs DE TRAIN dans un certain ordre, c’est-à-dire de voitures reliées et tirées par une locomotive ou une des voitures.
TRAIN COMPONENT (COMPOSANT DE TRAIN)
La position d’un ÉLÉMENT DE TRAIN dans un TRAIN.
TRAIN COMPONENT LABEL ASSIGNMENT (AFFECTION DE LABEL DE VOITURE)
L’affectation d’une désignation annoncée pour un véhicule ou un élément de véhicule pour passagers. Concrètement, cela permet de connaître le libellé de la voiture (tel qu’indiqué sur la réservation du voyageur). Ce libellé ne dépend pas que du type de TRAIN mais aussi de la COURSE à laquelle il est affecté.
TRAIN ELEMENT (ÉLÉMENT DE TRAIN)
Une composante élémentaire d’un TRAIN (par exemple voiture, locomotive).
TRAIN IN COMPOUND TRAIN (TRAIN DANS UN TRAIN COMPOSÉ)
La position d’un TRAIN dans un TRAIN COMPOSÉ.
TRAIN NUMBER (NUMÉRO DE TRAIN)
Spécification spécification des codes attribués à certaines COURSES ou PARTIE DE COURSE, lorsqu’elles sont réalisées par des TRAINs ou des TRAINs COMPOSÉs, pour répondre à un objectif fonctionnel (d’information des passagers, suivi des opérations, etc).
TYPE OF FLEXIBLE SERVICE (TYPE DE COURSE FLEXIBLE)
Classification classification des services flexibles.
VEHICLE JOURNEY (COURSE)
Le mouvement planifié d’un véhicule de transport public effectué un JOUR TYPE donné, depuis un point début à un point fin d’un PARCOURS sur un ITINÉRAIRE. La COURSE est donc l’instanciation d’un PARCOURS donné, auquel on va attribuer des heures de passage aux arrêts et des jours d’application.
VEHICLE MODEL (MODÈLE DE VEHICULE)
Une classification des véhicules de transport public d’un même TYPE DE VÉHICULE, par exemple suivant les spécifications relatives aux équipements ou à la génération du modèle.
VEHICLE TYPE (TYPE DE VEHICULE)
Une classification des véhicules de transport public résultant des spécifications de la planification des horaires en tenant compte du mode de transport et de la capacité requise (par exemple bus standard, bus à étage, …).
Symboles et abréviations
AO : Autorité Organisatrice de Transports
PMR : Personne à Mobilité Réduite
Exigences minimum liées à la LOM et la règlementation Européenne
La LOI n° 2019-1428 du 24 décembre 2019 d’orientation des mobilités (LOM : https://www.legifrance.gouv.fr/dossierlegislatif/JORFDOLE000037646678) et, au niveau Européen, le Règlement Délégué (UE) 2017/1926 De La Commission du 31 mai 2017 (complétant la directive 2010/40/UE du Parlement européen et du Conseil en ce qui concerne la mise à disposition, dans l’ensemble de l’Union, de services d’informations sur les déplacements multimodaux) rendent obligatoire la mise à disposition, quand elles existent, de certains types de données.
Le tableau ci-dessous résulte de l’analyse de la LOM et du règlement délégué et fournit la liste des concepts concernés dans le présent profil. Il sera donc nécessaire de fournir ces données pour être conforme à la législation (il s’agit bien de mettre à disposition toutes les données existantes dans les SI transport, et non de créer des données qui n’existeraient pas encore sous forme informatique).
Notez que les concepts présents dans les tableaux sont les ceux qui sont directement référencés par l’annexe du règlement européen (https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=CELEX:32017R1926&from=FR), mais que pour beaucoup d’entre eux, cela impliquera d’autres concepts (soit par héritage soit par relation, au s sens UML des termes). Ces éléments d’héritage et de relations sont présentés dans les profils, mais pas dans ce tableau.
De plus, les noms des catégories (colonnes Catégorie et Détail) ont été conservés dans la langue originale du document (l’anglais) pour éviter tout risque de confusion. Pour la même raison, les noms des concepts concernés sont ceux de la version originale de Transmodel.
Pour certaines catégories de données, il peut arriver que les concepts correspondants soient multiples, mais aussi qu’ils soient différents suivant le niveau de précision porté par la donnée. La colonne « Concepts à minima » correspond alors au minimum à fournir pour répondre à la catégorie en question et les colonnes « Autres concepts » décrit des informations complémentaires qui, si elles sont utiles, ne sont pas indispensables pour répondre à cette catégorie (notez que dans certains cas, ces concepts additionnels peuvent relever d’autres profils : ceci est précisé dans le tableau quand c’est le cas). Il faut toutefois garder à l’esprit que toute information existante est supposée être mise à disposition (que cela relève de la première ou de la seconde colonne).
La première colonne reprend la notion de niveau tel qu’il est décrit et utilisé par le règlement européen et a notamment une incidence sur le calendrier de mise à disposition de la donnée (voir le règlement pour plus de détails).
Les différents concepts présentés ne sont bien sûr pas détaillés dans ce tableau, mais dans le profil lui-même. C’est aussi dans la description du profil que l’on trouvera les détails concernant les attributs (obligatoire/facultatif, règles de remplissage, codification, etc.). Pour ce qui est des attributs facultatifs, la règle reste que, pour les objets ci-dessous, toute information disponible est supposée être fournie (mais on ne crée pas d’information si elle n’est pas disponible).
| Niveau | Catégorie | Détail | Concepts à minima | Autres concepts | Commentaire |
|---|---|---|---|---|---|
| 2 | Trip plans, auxiliary information, availability check | Vehicle facilities such as classes of carriage, on-board Wi-Fi | VEHICLE TYPE et FACILITIES associées | ||
| 3 | Trip plans | Parameters such as fuel consumption needed to calculate cost | VEHICLE TYPE | Ne fournit qu'une partie de l'information nécessaire pour un véritable calcul de consomation (à partir du VEHICLE TYPE, dautres sources de données devront être utilisées) | |
| 1 | Trip plan computation — scheduled modes transport | Timetables | SERVICE JOURNEY TIMETABLE PASSING TIME | JOURNEY FREQUENCY GROUP HEADWAY JOURNEY GROUP TEMPLATE SERVICE JOURNEY | Ne pas oublier les calendriers d'application associés (profil éléments communs) et bien sûr tous les éléments cosntitutifs des SERVICE JOURNEY. |
| 1 | Trip plan computation — scheduled modes transport | Vehicles (low floor; wheelchair accessible.) | VEHICLE TYPE et FACILITIES associées | (profil Accessibilité) EQUIPMENT | |
| 1 | Trip plan computation — scheduled modes transport | Hours of operation | SERVICE JOURNEY TIMETABLE PASSING TIME AVAILABILITY CONDITIONS |
Description du profil d’échange
Conventions de représentation
Tableaux d’attributs
NOTE les choix de conventions présentées ici ont pour vocation d’être cohérents avec ceux réalisés dans le cadre du profil SIRI (Île-de-France Mobilités et CEREMA). De plus tous les profils NeTEx partagent les mêmes conventions.
Les messages constituant ce profil d’échange sont décrits ci-dessous selon un double formalisme: une description sous forme de diagrammes XSD (leur compréhension nécessite une connaissance préalable de XSD: XML Schema Definition) et une description sous forme tabulaire. Les tableaux proposent ces colonnes:
| Classification | Nom | Type | Cardinalité | Description |
|---|
Classification : permet de catégoriser l’attribut. Les principales catégories sont:
PK (Public Key) que l’on peut interpréter comme Identifiant Unique: il permet à lui seul d’identifier l’objet, de façon unique, pérenne et non ambiguë. C’est l’identifiant qui sera utilisé pour référencer l’objet dans les relations.
AK (Alternate Key) est un identifiant secondaire, généralement utilisé pour la communication, mais qui ne sera pas utilisé dans les relations.
FK (Foreign Key) indique que l’attribut contient l’identifiant unique (PK) d’un autre objet avec lequel il est en relation.
GROUP est un groupe XML nommé (ensemble d’attributs utilisables dans différents contextes) Voir ici.
Nom : nom de l’élément ou attribut XSD
Type : type de l’élément ou attribut XSD (pour certains d’entre eux, il conviendra de se référer à la XSD NeTEx)
Cardinalité : cardinalité de l’élément ou attribut XSD exprimée sous la forme “minimum:maximum” (“0:1” pour au plus une occurrence; “1:*” au moins une occurrence et sans limites de nombre maximal; “1:1” une et une seule occurrence; etc.).
Description : texte de description de l’élément ou attribut XSD (seul les attributs retenus par le profil ont un texte en français; les textes surlignés en jaune indiquent une spécificité du profil par rapport à NeTEx).
Les textes surlignés en Jaune sont ceux présentant une particularité (spécialisation) par rapport à NeTEx: une codification particulière, une restriction d’usage, etc.
La description XSD utilisée est strictement celle de NeTEx, sans aucune modification (ceci explique notamment que tous les commentaires soient en anglais).
Les attributs et éléments rendus obligatoires dans le cadre de ce profil restent facultatifs dans l’XSD (le contrôle de cardinalité devra donc être réalisé applicativement).
Valeurs de code de profil
Dans la mesure du possible, le profil sélectionne les valeurs de code à utiliser pour caractériser des éléments et les limite à un ensemble de valeurs documentées. NETEX propose plusieurs mécanismes différents pour spécifier les valeurs de code autorisées:
des énumérations fixes définies dans le cadre du schéma XSD NeTEx. Le profil impose alors un sous-ensemble des codes NeTEx.
des spécialisations de TYPE OF VALUE, utilisées pour définir des ensembles de codes ouverts pouvant être ajoutés au fil du temps sans modifier le schéma, par exemple, pour enregistrer des classifications d’entités héritées. Le profil lui-même utilise le mécanisme TYPE OF VALUE dans quelques cas pour spécifier des codes normalisés supplémentaires : ceux-ci sont affectés à un CODESPACE «FR_IV_metadata» (https://netex-cen.eu/FR_IV) indiqué par un préfixe «FR_IV». (par exemple, «FR_IV: monomodal».
des instances TypeOfFrame: le profil utilise plusieurs TYPES DE FRAME pour spécifier l’utilisation de VERSION FRAME dans le profil.
Indication des classes abstraites
NeTEx, et Transmodel, utilisent largement l’héritage de classe; cela simplifie considérablement la spécification en évitant les répétitions puisque les attributs partagés sont déclarés par une superclasse et que des sous-classes viennent ensuite les spécialiser sans avoir à répéter ces attributs et en n’ajoutant que ceux qui lui sont spécifiques. La plupart des superclasses sont «abstraites» - c’est-à-dire qu’il n’existe aucune instance concrète; seules les sous-classes terminales sont «concrètes».
Un inconvénient de l’héritage est que si l’on veut comprendre les propriétés d’une classe concrète unique, il faut également examiner toutes ses super-classes. Pour cette raison, le profil inclut les classes abstraites nécessaires pour comprendre les classes concrètes, même si ces classes concrètes ne sont jamais directement instanciées dans un document NeTEx.
Les super-classes sont signalées dans les en-têtes par le suffixe «(abstrait)»
Dans les diagrammes UML (comme pour NeTEx et Transmodel), les noms des classes abstraites sont indiqués en italique et les classes abstraites sont de couleur gris clair.
Certaines super-classes ne sont techniquement pas abstraites dans NeTEx, mais ne sont pas utilisées comme classes concrètes dans le profil : elles sont signalées avec la même convention que les classes abstraites.
Classes de sous-composants
Un certain nombre de classes ont des sous-composants qui constituent leur définition. Celles-ci fournissent des détails auxiliaires (par exemple, AlternativeText, AlternativeName, TrainComponent) et sont signalées dans les en-têtes par le suffixe « (objet inclus) ».
Les Courses
Service Journey – Modèle conceptuel
Une COURSE (SERVICE JOURNEY) est le mouvement défini d’un véhicule utilisant un PARCOURS (JOURNEY PATTERN) spécifiée. Elle défini pour un TYPE DE JOUR donné.
Le profil ne concerne que les COURSEs dans lequel les passagers seront autorisés à monter à bord ou à descendre du véhicule aux arrêts.
| Classification | Name | Type | Cardinality | Description | |
| ::> | ::> | Journey | ::> | SERVICE JOURNEY hérite de JOURNEYet intègre un certain nombre d'éléments de VEHICLE JOURNEY | |
| ServiceAlteration | ServiceAlterationEnumeration | 0:1 | Indique si la course est planifiée (valeur par défaut), si elle est annulée ou si c’est une course additionnelle. Ce champ n’est à utiliser que pour les mises à jour tardives dans les cas où cette information n’est pas diffusée avec SIRI (service Producion Timetable) | ||
| DepartureTime | xsd:time | 0:1 | Heure de départ de la COURSE | ||
| DepartureDayOffset | DayOffsetType | 0:1 | Décalage de jour si le jour de départ du VEHICLE JOURNEY est différent de l’OPERATING DAY courant (typiquement -1 pour « la veille »).. | ||
| «cntd» | L'information de fréquence est fournie par la COURSE MODÈLE (voir frequencyGroups de TemplateVehicleJourney) | ||||
| JourneyDuration | xsd:duration | 0:1 | Durée totale de la course. | ||
| «FK» | DayTypeRef | DayTypeRef | 1:* | TYPE DE JOUR correspondant aux jours d'application de la course. | |
| «FK» | Voir le PARCOURS | ||||
| «FK» | JourneyPatternRef | JourneyPatternRef | 0:1 | PARCOURS suivi par la COURSE | |
| «FK» | VehicleTypeRef | VehicleTypeRef | 0:1 | TYPE DE VEHICULE utilisé pour la course. | |
| choice | OperatorRef | OperatorRef | 0:1 | Référence l'EXPLOITANT opérant cette course. Il n'est indiqué que s’il est différent de celui de la ligne. | |
| «EV» | choice | LineRef | LineRef | 0:1 | Référence la LIGNE à laquelle appartient la COURSE (pour simplifier la navigation COURSE->PARCOURS->ITINERAIRE->LIGNE). Il peut naturellement s'agir d'une LIGNE FLEXIBLE. |
| FlexibleLineView | FlexibleLineView | 0:1 | Permet de décrire les éléments de flexibilité (typiquement TAD - Transport à la Demande) spécifiques à cette course | ||
| trainNumbers | trainNumberRefs | 0:* | Référence le numéro de train associé. Note: le NUMERO DE TRAIN est un objet indépendant, qui est ici référencé. | ||
| «cntd» | Origin | Voir le PARCOURS. | |||
| «cntd» | Destination | Voir le PARCOURS. | |||
| «cntd» | passingTimes | TimetabledPassingTime | 0:* | Heures de passages planifiées aux arrêts (scheduledStopPoint). | |
| parts | journeyParts | 0:* | Références à des parties de COURSE (JOURNEY PART) constituant la COURSE. Utilisé pour un certain nombre de situations du mode ferré (changement de parité ou de numéro de train) ainsi que pour des situations comme le changement d'exploitant en cours de course sur les RER A et B. Contrairement à la règle générale dans les profils NeTEx, et afin de pouvoir être réutilisées, les JOURNEY PARTs seront systématiquement définies indépendamment (à la racine de l'élément members du FRAME) et simplement référencées ici (et non incluse, même si le modèle l'autorise). | ||
| facilities | serviceFacilitySets_RelStructure | 0:* | Services disponibles pour cette course (voir le profil accessibilité pour plus de détails). | ||
| TrainSize | TrainSizeStructure | 0:1 | Information sur la taille du train (long/court). Peut aussi servir pour identifier les bus articulés ou couplés. | ||
| FlexibleServiceProperties | FlexibleServiceProperties | 0:1 | Information de flexibilité de la COURSE. Les informations de flexibilité sont fournies ici que si elles ne sont pas globales pour la LIGNE. | ||
Pour TrainSize voir 6.10.1-Train.
| Classification | Name | Type | Cardinality | Description | |
| ::> | ::> | LinkSequence | ::> | JOURNEY hérite de LINK SEQUENCE (voir le document Profil NeTEx éléments communs). | |
| Description | MultilingualString | 0:1 | Descriptionde JOURNEY. | ||
| TransportMode | VehicleModeEnum | 0:1 | Transport MODE de JOURNEY. Le mode n'est précisé que s'il est différent de celui de la ligne (exemple: bus de substitution SNCF). | ||
| TransportSubmode | TransportSubmode | 0:1 | SOUS MODE de transport de JOURNEY. Le sous-mode n'est précisé que s'il est différent de celui de la ligne. | ||
| Fourni au niveau LIGNE. | |||||
| «cntd» | Le profil étant dédié à l'information voyageur, les notions de comptabilité ne sont pas prises en compte, mais pourraient être nécessaires dans d'autres contextes. | ||||
| noticeAssignments | noticeAssignments | 0:* | NOTEs associées à la COURSE. | ||
Les heures de passage
Vehicle Journey, Passing Times et Interchanges – Modèle conceptuel
| Classification | Name | Type | Cardinality | Description |
| ::> | ::> | VersionedChild | ::> | PASSING TIME hérite de VERSIONED CHILD (non utilisé dans le profil) |
| «FK» | PointInJourneyPatternRef | PointInLinkSequenceRef | 0:1 | Référence les POINT D’ARRÊT PLANIFIÉ pour lequel on fournit les heures de passage. Ce point peut aussi, de façon plus exceptionnel être un POINT HORAIRE uniquement. |
| DayOffset | xsd:integer | 0:1 | Nombre de jour de décalage par rapport au jour de début de course (permet de gérer les courses à cheval sur plusieurs jours). | |
| ArrivalTime | xsd:time | 0:1 | Heure d’arrivée. | |
| DepartureTime | xsd:time | 0:1 | Heure de départ. | |
| Headway | HeadwayInterval | 0:1 | Temps d’attente moyen avant le prochain passage d’une COURSE empruntant le même PARCOURS. | |
| EarliestDepartureTime | xsd:time | 0:1 | Heure de départ au plus tôt (il s’agit là de l’engagement de service du transporteur ou de l’AOT; il permettra notamment de sécuriser les correspondances; il permet aussi d’indiquer la précision de l’heure de passage, en particuliers aux points ou l’horaire est interpolé). | |
| LatestArrivalTime | xsd:time | 0:1 | Heure de d’arrivée au plus tard (il s’agit là de l’engagement de service du transporteur ou de l’AOT; il permettra notamment de sécuriser les correspondances; il permet aussi d’indiquer la précision de l’heure de passage, en particuliers aux points ou l’horaire est interpolé). |
Note: pour les courses en fréquence, les nécessaires temps de parcours (pour le calcul d’itinéraire) seront calculés à partir des heures de passage de la COURSE MODÈLE (la fourniture explicite des temps de parcours, ou RUN TIME, nécessite la définition des TIMING LINKs, alourdissant sensiblement l’échange sans pour autant véritablement apporter une information supplémentaire dans un contexte d’information voyageur). Le calcul du temps de parcours sera réalisé par simple différence des heures de départs (DepartureTime) aux différents arrêts.
Propriétés de course flexible
| Classification | Name | Type | cardinality | Description |
| ::> | ::> | DataManagedObject | ::> | FLEXIBLE SERVICE PROPERTIES hérite de DATA MANAGED OBJECT (voir le document Profil NeTEx éléments communs). Non utilisé ici. |
| «cntd» | BookingArrangements | BookingArrangements | 0:1 | Informations de contact pour les services flexibles (voir le document Profil NeTEx réseau). |
| FlexibleServiceType | FlexibleServiceTypeEnum | 0:1 | Type de flexibilité mise en œuvre sur la course
| |
| CancellationPossible | xsd:boolean | 0:1 | Indique si une annulation du service est possible (même après une réservation). | |
| ChangeOfTimePossible | xsd:boolean | 0:1 | Indique que l'horaire peut être modifié (même après une réservation). |
Groupes de courses
Un groupement de COURSEs, est particulièrement utile pour organiser des séries de voyages similaires à présenter sous forme de tableau ou dans les systèmes d’information voyageur, par exemple «Tous les services au départ pour la ligne 2 en semaine».
| Classification | Name | Type | Cardinality | Description |
| ::> | ::> | GroupOfEntities | ::> | GROUP OF SERVICES hérite de GROUP OF ENTITIES. |
| «PK» | id | GroupOfServicesIdType | 1:1 | Identifiant du GROUP OF SERVICEs. |
| origin | EndPoint_DerivedView | Origine des courses du groupe Par exemple : ScheduledStopPointRef, Name, StopType, etc | ||
| destination | EndPoint_DerivedView | Destination des courses du groupe Par exemple : ScheduledStopPointRef, Name, StopType, etc | ||
| «cntd» | destinationDisplays | DestinationDisplay | 0:* | DESTINATION DISPLAYs associés au groupe |
| «cntd» | members | VehicleJourneyRef | 0:* | COURSEs faisant partie du GROUP OF SERVICEs. |
| «cntd» | noticeAssignments | NoticeAssignmentView | 0:* | Note associée au GROUP OF SERVICEs. |
Les parties de course
Journey Parts et Trains – Modèle conceptuel
Les PARTIEs DE COURSE seront généralement spécifiques au mode ferré.
| Classification | Name | Type | cardinality | Description |
|---|---|---|---|---|
| ::> | ::> | DataManagedObject | ::> | JOURNEY PART hérite de DATA MANAGED OBJECT (voir le document Profil NeTEx éléments communs). |
| Description | MultilingualString | 0:1 | Description de la PARTIE DE COURSE. | |
| «FK» | ParentJourneyRef | VehicleJourneyRef | 0:1 | COURSE à laquelle appartient cette PARTIE DE COURSE. |
| «FK» | MainPartRef | JourneyPartCoupleRef | 1:1 | Référence à la PARTIE DE COURSE principale (l’une des différentes PARTIE DE COURSE doit être déclarée comme principale). |
| «FK» | JourneyPartCoupleRef | JourneyPartCoupleRef | 0:1 | Référence à l’éventuelle COURSE COUPLÉE à laquelle la PARTIE DE COURSE appartient. |
| «FK» | TrainNumberRef | TrainNumberRef | 0:1 | Référence au NUMÉRO DE TRAIN de la PARTIE DE COURSE. |
| «FK» | FromStopPointRef | ScheduledStopPointRef | 0:1 | Arrêt de départ de la PARTIE DE COURSE. |
| «FK» | ToStopPointRef | ScheduledStopPointRef | 0:1 | Arrêt de fin de la PARTIE DE COURSE. |
| StartTime | xsd:time | 1:1 | Arrêt de départ de la PARTIE DE COURSE (à l’arrêt de départ). | |
| StartTimeDayOffset | DayOffsetType | 0:1 | Nombre de jours de décalage par rapport au jour de départ de la COURSE. | |
| EndTime | xsd:time | 1:1 | Arrêt de fin de la PARTIE DE COURSE (à l’arrêt de fin). | |
| EndTimeDayOffset | DayOffsetType | 0:1 | Nombre de jours de décalage par rapport au jour de départ de la COURSE. | |
| «cntd» | facilities | ServiceFacilitySet | 0:* | Service spécifique à cette PARTIE DE COURSE. |
| «cntd» | journeyPartPositions | JourneyPartPosition | 0:* | Positions dans la séquence de PARTIE DE COURSE. |
JOURNEY PART POSITION décrit la position relative dans le train d’un JOURNEY PART à partir d’un arrêt donné. Cela peut changer en cours de route car les composants du train sont couplés et découplés.
| Classification | Name | Type | Cardinality | Description |
|---|---|---|---|---|
| ::> | ::> | VersionedChild | ::> | JOURNEY PART POSITION hérite de VERSIONED CHILD. |
| «PK» | id | JourneyPartPositionIdType | 1:1 | Identifiant de JOURNEY PART POSITION. |
| «FK» | ScheduledStopPointRef | ScheduledStopPointRef | 0:1 | SCHEDULED STOP POINT pour lequel cette position est valide. |
| PositionInTrain | xsd:integer | 0:* | Position du JOURNEY PART à partir du SCHEDULED STOP POINT. |
Numéro de train
| Classification | Name | Type | Cardinality | Description |
| ::> | ::> | DataManagedObject | ::> | TRAIN NUMBER hérite de DATA MANAGED OBJECT (voir le document Profil NeTEx éléments communs). Le champ Id est naturellement l'identifiant du NUMÉRO DE TRAIN (c'est le numéro de train lui-même). |
| Description | MultilingualString | 0:1 | Texte descriptif associé au NUMÉRO DE TRAIN et à utiliser pour l'information voyageur (devra figurer en complément du numéro de train). | |
| ForAdvertisement | xsd:normalizedString | 0:1 | NUMÉRO DE TRAIN utilisé pour la communication au public (parfois différent du numéro technique: si ce champ est présent il sera systématiquement utilisé pour l'information voyageur). |
Les courses en fréquence
Course modèle
Les courses modèles sont des courses de référence utilisées pour décrire les services en fréquence (on ne décrit alors qu’une course qui sera répétée à intervalle régulier) ou en cadences (on décrit alors toutes les courses passant dans un créneau d’une heure).
Template Service Journey – Modèle conceptuel
Pour les courses en fréquence le calcul du temps de parcours sera réalisé par simple différence des heures de départs (DepartureTime) aux différents arrêts de la course modèle. Par convention, la course modèle pour les services en fréquence sera, en termes d’horaire de passage, la première course de la tranche horaire décrite (avec généralement un calage au premier arrêt sur l’heure de début de la tranche horaire).
Pour les courses en cadence on prendra comme convention de n’indiquer que les minutes des horaires de passage (l’heure sera donc fixe, à 0, un arrêt desservi toutes les heures dix, vingt-cinq et cinquante, aura donc des horaire 0:10, 0:25 et 0:50). Il ne s’agit là que d’une convention, dans tous les cas, la partie heure de l’horaire de passage peut être ignorée dans le cadre des cadences.
| Classification | Name | Type | Cardinality | Description |
| ::> | ::> | ServiceJourney | ::> | TEMPLATE SERVICE JOURNEY hérite de SERVICE JOURNEY. |
| TemplateVehicleJourneyType | TemplateVehicleJourneyTypeEnum | 0:1 | Type de COURSE MODÈLE (avec voyageur). Ce type est codifié de la façon suivante:
| |
| «cntd» | frequencyGroups | JourneyFrequencyGroup | 0:* | Référence à la description du service en fréquence ou en cadence que la COURSE MODÈLE décrit. Seules les références xxxxRef (HeadwayJourneyGroupRef pour les services en fréquence ou RhythmicalJourneyGroupRef pour les services en cadence) seront utilisées dans le cadre du profil. |
Course en fréquence
| Classification | Name | Type | Cardinality | Description |
|---|---|---|---|---|
| ::> | ::> | JourneyFrequencyGroup | ::> | HEADWAY JOURNEY GROUP hérite de JOURNEY FREQUENCY GROUP. |
| ScheduledHeadwayInterval | xsd:duration | 0:1 | INTERVAL DE PASSAGE planifié (temps prévu entre deux passages de véhicule). | |
| Description | MultilingualString | 0:1 | Description du service en fréquence |
| Classification | Name | Type | Cardinality | Description |
| ::> | ::> | GroupOfEntities | ::> | JOURNEY FREQUENCY GROUP hérite de GROUP OF ENTITies (voir le document Profil NeTEx éléments communs). |
| FirstDepartureTime | xsd:time | 1:1 | Heure du premier départ dans le GROUPE DE FRÉQUENCE. Il s'agit là de l'heure de passage du premier départ au premier arrêt de la course. S'il n'y a pas de régulation des heures de premier départ dans les tranches horaires, on indiquera uniquement l'heure de début de tranche horaire (pour un bus toute les 10 minutes de 8h00 à 9h30 on indiquera donc 8h00 même s'il n'y a pas de garantie d'un départ à 8h00). | |
| LastDepartureTime | xsd:time | 0:1 | Heure du dernier départ dans le GROUPE DE FRÉQUENCE. Il s'agit là de l'heure de passage du dernier départ au premier arrêt de la course. S'il n'y a pas de régulation des heures de dernier départ dans les tranches horaires, on indiquera uniquement l'heure de fin de tranche horaire (pour un bus toute les 10 minutes de 8h00 à 9h30 on indiquera donc 9h30 même s'il n'y a pas de garantie d'un départ à 9h30). | |
| DayOffset | xsd:integer | 0:1 | Éventuel décalage de jour pour l'heure de dernier départ (si la plage horaire est à cheval sur plusieurs jours). | |
| «cntd» | journeys | VehicleJourneyRef | 0:* | Liste des courses constituant ce GROUPE DE FRÉQUENCE. Cette relation permet d'avoir en même temps une description globale du service en fréquence complété par la liste de toutes les courses (et horaires associées) qui vont effectivement réaliser ce service. Seul le ServiceJourneyRef est utilisé par le profil. |
Course en cadence
| Classification | Name | Type | Cardinality | Description |
|---|---|---|---|---|
| ::> | ::> | JourneyFrequencyGroup | ::> | RHYTHMICAL JOURNEY GROUP hérite de JOURNEY FREQUENCY GROUP. |
| «cntd» | timebands | On utilisera uniquement les COURSEs MODÈLEs pour décrire les services en cadencement. |
Les Courses couplées
Courses coupléed – Modèle conceptuel
| Classification | Name | Type | Cardinality | Description |
|---|---|---|---|---|
| ::> | ::> | DataManagedObject | ::> | COUPLED JOURNEY hérite de DATA MANAGED OBJECT (voir le document Profil NeTEx éléments communs). |
| Description | MultilingualString | 0:1 | Description de la COURSE COUPLÉE (texte utilisable pour l’information voyageur). | |
| «cntd» | journeys | VehicleJourney | 0:* | Référence vers les COURSEs qui sont associées ensemble. |
Parties de courses couplées
| Classification | Name | Type | Cardinality | Description |
| ::> | ::> | DataManagedObject | ::> | JOURNEY PART COUPLE hérite de DATA MANAGED OBJECT (voir le document Profil NeTEx éléments communs). |
| Description | MultilingualString | 0:1 | Description of JOURNEY PART COUPLE. | |
| StartTime | xsd:time | 1:1 | Heure de début du couplage (heure de départ au point de départ) | |
| StartTimeDayOffset | DayOffsetType | 0:1 | Nombre de jours de décalage par rapport au jour de départ de la COURSE. | |
| EndTime | xsd:time | 1:1 | Heure de fin du couplage. Il s'agit de l'heure d'arrivée au point de d'arrivé, ou à défaut de l'heure de premier départ du point d'arrivée (première des courses couplées à quitter le point d'arrivée). | |
| EndTimeDayOffset | DayOffsetType | 0:1 | Nombre de jours de décalage par rapport au jour de départ de la COURSE. | |
| «FK» | FromPointRef | ScheduledStopPointRef | 1:1 | POINT D'ARRÊT PLANIFIÉ où débute le couplage. |
| «FK» | ToPointRef | ScheduledStopPointRef | 1:1 | POINT D'ARRÊT PLANIFIÉ où se termine le couplage. |
| «FK» | MainPartRef | JourneyPartRef | 1:1 | PARTIE DE COURSE principale (à référencer pour l'information voyageur en particulier). |
| «cntd» | joinedParts | JourneyPartRef | 0:* | PARTIEs DE COURSEs jointes à la PARTIE DE COURSE principale. |
| «FK» | TrainNumberRef | TrainNumberRef | 0:1 | Numéro de train associé à la partie de courses couplées. |
Les correspondances entre course
| Classification | Name | Type | Cardinality | Description |
|---|---|---|---|---|
| ::> | ::> | Interchange | ::> | SERVICE JOURNEY INTERCHANGE hérite de INTERCHANGE. |
| «FK» | FromPointRef | ScheduledStopPointRef | 1:1 | POINT D’ARRÊT planifié au départ de la correspondance. |
| On utilisera les horaires de passage et de correspondance pour distinguer deux passages au même point d’arrêt, si nécessaire. | ||||
| «FK» | ToPointRef | ScheduledStopPointRef | 1:1 | POINT D’ARRÊT planifié auquel donne accès la correspondance. |
| On utilisera les horaires de passage et de correspondance pour distinguer deux passages au même point d’arrêt, si nécessaire. | ||||
| «FK» | FromJourneyRef | ServiceJourneyRef | 1:1 | COURSE de départ. |
| «FK» | ToJourneyRef | ServiceJourneyRef | 1:1 | COURSE à laquelle donne accès la correspondance. |
| Classification | Name | Type | Cardinality | Description |
| ::> | ::> | DataManagedObject | ::> | INTERCHANGE hérite de DATA MANAGED OBJECT (voir le document Profil NeTEx éléments communs). |
| «FK» | ConnectionRef | ConnectionRef | 0:1 | Lien avec la CORRESPONDANCE physique sur laquelle s'opère la CORRESPONDANCE ENTRE COURSEs (voir le document Profil NeTEx Réseau). |
| StaySeated | xsd:boolean | 0:1 | Permet d'indiquer que la course en correspondance est assurée par le même véhicule que la course amenante et que le passager peut simplement rester dans le véhicule et n'a donc pas besoin de descendre. Cela sera utile pour les lignes en boucle par exemple, ou encore si l'on décide de modéliser un changement d'exploitant par des courses distinctes (cas des RER A et B en région parisienne par exemple). | |
| CrossBorder | xsd:boolean | 0:1 | Indique que l’INTERCHANGE implique le franchissement d’une frontière nationale. | |
| «cntd» | InterchangeTimesGroup | InterchangeTimesGroup | 0:* | Information horaire de la correspondance. |
| «cntd» | noticeAssignments | NoticeAssignmentView | 0:* | NOTE associé à la correspondance (voir le document Profil NeTEx éléments communs). |
| Classification | Name | Type | Cardinality | Description |
| StandardTransferTime | xsd:duration | 0:1 1:1 | Temps de correspondance moyen (entre l'arrivée de l'amenant et le départ du partant) Obligatoire dans le cadre du profil. Voir la CORRESPONDANCE physique pour les détails de temps de parcours de la correspondance (temps de marche, etc.) (voir le document Profil NeTEx Réseau). |
Position d’arrêt pour une course
Cette information complète l'Affectation de train à quai (voir le document Profil NeTEx Réseau) dans le cas où l’identification des voitures est variable d’une course à l’autre.
| Classification | Name | Type | Cardinality | Description |
|---|---|---|---|---|
| ::> | ::> | DataManagedObject | ::> | TRAIN COMPONENT LABEL ASSIGNMENT hérite de DATA MANAGED OBJECT (voir le document Profil NeTEx éléments communs). |
| Name | MultilingualString | 0:1 | Nom associé au COMPOSANT DE TRAIN (voiture) pour la course (il s’agit du nom de la voiture tel qu’il figurera sur le billet du voyageur). | |
| «AK» | VehicleJourneyRef | VehicleJourneyRef | 0:1 | Référence de la course concernée. |
| «FK» | TrainComponentRef | TrainComponentRef | 0:1 | Référence du COMPOSANT DE TRAIN (voiture) concernée. |
Type de véhicule
Type de Vehicule et Trains – Modèle Conceptuel
| Classification | Name | Type | Cardinality | Description |
| ::> | ::> | DataManagedObject | ::> | VEHICLE TYPE hérite de DATA MANAGED OBJECT (voir le document Profil NeTEx éléments communs). |
| Name | MultilingualString | 0:1 | Nom du TYPE DE VEHICULE. | |
| Description | MultilingualString | 0:1 | Description du TYPE DE VEHICULE. | |
| SelfPropelled | boolean | 0:1 | Indique si le TYPE DE VEHICULE est autonome, ou s'il nécessite une motrice ou un véhicule tracteur. | |
| TypeOfFuel | TypeOfFuelEnum | 0:1 | Type de carburant du TYPE DE VEHICULE:
| |
| EuroClass | xsd:normalizedString | 0:1 | Euroclasse du TYPE DE VEHICULE (normes européennes d'émission: http://fr.wikipedia.org/wiki/Normes_europ%C3%A9ennes_d%27%C3%A9mission). | |
| capacities | PassengerCapacity | 0:* | Capacité en passager (par classe tarifaire). On utilisera directement les PassengerCapacity (et non les références) dont on n'utilisera pas les champs issu de l'héritage DATA MANAGED OBJECT. | |
| LowFloor | xsd:boolean | 0:1 | Indique un plancher bas (pour l'accessibilité). | |
| HasLiftOrRamp | xsd:boolean | 0:1 | Indique que le TYPE DE VEHICULE est équipé d'une rampe ou d'une palette pour l'accès PMR | |
| HasHoist | xsd:boolean | 0:1 | Indique que le TYPE DE VEHICULE est équipé d'un monte-charge pour l'accès PMR | |
| Length | LengthType | 0:1 | Longueur du TYPE DE VEHICULE. | |
| Width | LengthType | 0:1 | Largeur du TYPE DE VEHICULE. | |
| Height | LengthType | 0:1 | Hauteur du TYPE DE VEHICULE. | |
| Weight | WeightType | 0:1 | Poids du TYPE DE VEHICULE. | |
| «FK» | On utilise le champ Brand de l'héritage DATA MANAGED OBJECT pour éventuellement indiquer la marque et/ou le modèle du véhicule. |
| Classification | Name | Type | Cardinality | Description |
| ::> | ::> | DataManagedObject | ::> | PASSENGER CAPACITY hérite de DATA MANAGED OBJECT (voir le document Profil NeTEx éléments communs) Champs non utilisés dans le cadre du profil. |
| FareClass | FareClassEnum | 0:1 | Classe pour laquelle on indique la CAPACITÉ EN PASSAGERS:
| |
| TotalCapacity | NumberOfPassengers | 0:1 | Capacité totale. | |
| SeatingCapacity | NumberOfPassengers | 0:1 | Nombre de places assises. | |
| StandingCapacity | NumberOfPassengers | 0:1 | Nombre de places debout. | |
| WheelchairPlaceCapacity | NumberOfPassengers | 0:1 | Nombre de places PMR |
Train
| Classification | Name | Type | Cardinality | Description |
| ::> | ::> | VehicleType | ::> | TRAIN hérite de VEHICLE TYPE |
| TrainSize | TrainSizeStructure | 0:1 | Taille du train. | |
| «cntd» | components | TrainComponent | 0:* | Ensemble des composants du train. On utilisera directement les TrainComponent (et non les références) dont on n'utilisera pas les champs issus de l'héritage de DATA MANAGED OBJECT (à l'exception de l'identifiant, indispensable si l'on souhaite préciser les alignements de voiture sur les quais). |
| Classification | Name | Type | Cardinality | Description |
| NumberOfCars | xsd:nonNegativeInteger | 0:1 | Nombre de voitures (voiture ou éventuellement bus couplé; par convention on indiquera 2 pour un véhicule articulé à 2 éléments). | |
| TrainSizeType | TrainSizeEnumeration | 0:1 | Type de taille du véhicule
|
| Classification | Name | Type | Cardinality | Description | |
| ::> | ::> | VersionedChild | ::> | TRAIN COMPONENT hérite de VERSIONED CHILD (voir le document Profil NeTEx éléments communs). | |
| Label | MultilingualString | 0:1 | Label du COMPOSANT DE TRAIN (s'il est fixe, on utilisera TrainComponentLabelAssignment sinon). | ||
| Description | MultilingualString | 0:1 | Description du COMPOSANT DE TRAIN. | ||
| «FK» | Non utilisé car implicite du fait de l'imbrication XML, dans le contexte du profil. | ||||
| b | TrainElement | TrainElement | 1:1 | ELEMENT DE TRAIN associé au COMPOSANT DE TRAIN. On utilisera directement les TrainElement (et non les références) dont on n'utilisera pas les champs issus de l'héritage DATA MANAGED OBJECT. | |
| Classification | Name | Type | Cardinality | Description |
| ::> | ::> | DataManagedObject | ::> | TRAIN ELEMENT hérite de DATA MANAGED OBJECT (voir le document Profil NeTEx éléments communs). Champs non utilisés dans le cadre du profil. |
| Name | MultilingualString | 0:1 | Nom du TRAIN ELEMENT. | |
| Description | MultilingualString | 0:1 | Description du TRAIN ELEMENT. | |
| «FK» | TrainElementType | TypeOfTrainElementEnum | 1:1 | Classification de l'ÉLÉMENT DE TRAIN:
|
| FareClasses | FareClassEnum | 0:* | Classe associé à l'ÉLÉMENT DE TRAIN:
|
Train composé
| Classification | Name | Type | Cardinality | Description |
|---|---|---|---|---|
| ::> | ::> | VehicleType | ::> | COMPOUND TRAIN hérite de VEHICLE TYPE |
| components | TRainInCompoundTrain | 1:* | Références aux TRAINs constituant le TRAIN composé. C’est une liste ordonnée (en commençant par la tête de train dans le sens de la marche). |
Entêtes NeTEx
Note: les entêtes NeTEx sont présentés dans le document éléments communs. Seules les spécificités du profil NETEX_HORAIRE sont présentées ici.
TypeOfFrame : type spécifique NETEX_HORAIRE
Le présent profil utilise un TypeOfFrame spécifique, identifié NETEX_HORAIRE. Il apparaitra systématiquement et explicitement dans les éléments members du GeneralFrame.
| Classification | Nom | Type | Description | |
|---|---|---|---|---|
| ::> | ::> | TypeOfValueDataManagedObject | ::>::> | TYPE OF FRAME hérite de TYPE OF VALUE. L'Id est imposé à NETEX_HORAIRE |
| «cntd» | classes | ClassInContextRef | 0:* | Liste des classes pouvant être contenu dans ce TYPE OF FRAME. La liste est fixe pour NETEX_ HORAIRE:
|
| Classification | Name | Type | Description | ||
|---|---|---|---|---|---|
| ::> | ::> | DataManagedObject | ::> | TYPE OF VALUE hérite de DATA MANAGED OBJECT. L’attribut version portera la version du profil. L'Identifiant du TYPE OF VALUE est imposé à NETEX_ HORAIRE. | |
| Name | MultilingualString | 1:1 | Nom du TYPE OF VALUE. Imposé à « NETEX HORAIRE». | ||
| Description | MultilingualString | 1:1 | Description du TYPE OF VALUE. Imposé à « Profil d’échange français NETEX HORAIRE». |
Bibliographie
EN 15531-1, Public transport - Service interface for real-time information relating to public transport operations - Part 1: Context and framework
EN 15531-2, Public transport - Service interface for real-time information relating to public transport operations - Part 2: Communications infrastructure3
EN 15531-3, Public transport - Service interface for real-time information relating to public transport operations - Part 3: Functional service interfaces4
CEN/TS 15531-4, Public transport - Service interface for real-time information relating to public transport operations - Part 4: Functional service interfaces: Facility Monitoring
CEN/TS 15531-5, Public transport - Service interface for real-time information relating to public transport operations - Part 5: Functional service interfaces - Situation Exchange