| Table of Contents |
|---|
Introduction
Ce document s’inscrit dans le programme de modernisation du Back-Office SIM. Celui-ci vise à mettre en œuvre une nouvelle chaîne de collecte et de distribution des données des données Information Voyageur en Île De France.
...
Pour rappel, le BO Offre Théorique permettra également de saisir directement son offre dans l'interface web du système, via IHM. Le système est basé sur le logiciel Chouette.
Organisation des imports
Deux mécanismes sont proposés pour l'intégration des fichiers dans le BO :
...
Ces mécanismes sont détaillés dans le chapitre : Interface d’import
Règles et restrictions
Tableaux d’attributs
Les tableaux d’attributs dans les chapitres suivants précisent pour chaque objet NeTEx exploité, le traitement attaché à chacun des attributs de l’objet. Les tableaux sont constitués de 4 colonnes :
Donnée | Type | Cardinalité BO Offre Théorique | Description et traitement BO OT |
|---|---|---|---|
Nom NeTEx de la donnée (attribut ou élément de structure) | Type XML de la donnée | Précise le caractère obligatoire ou optionnel et dans le cas d’une occurrence multiple, les valeurs minimales et maximales autorisées (* pour indiquer aucune limite). Si cette cardinalité est différente de celle du Profil IDF, les deux sont indiquées. Ex : 0 :* (IDF) 1 :1 (BO IV) | Rappelle pour les données exploitées leur définition issue du Profil IDF et précise, si nécessaire, comment elles sont interprétées par le BO IV. Dans le cas où aucun traitement n’est précisé, la donnée est importée dans le BO IV sans transformation. |
Pour les attributs ayant une cardinalité commençant par "0:" (attribut non obligatoire), il est possible de ne pas indiquer la balise dans le fichier d’import. En fonction du type de valeur, il peut aussi être accepté d'indiquer la balise avec une valeur vide. Pour les types comme enum, integer, time ou datetime par exemple, une balise "vide" provoquera une erreur XSD. Afin d'éviter les erreurs, si une information n'est pas du tout gérée par le transporteur, Île-de-France Mobilités préconise de ne pas indiquer cette balise.
Règle d’exploitation des informations NeTEx
Les couleurs utilisées dans les tableaux permettent de mettre en valeur les objets et attributs exploités ou non lors de l’import dans le BO IV. Trois cas de figure sont possibles :
Information (donnée ou objet) non exploitée : l’information fait uniquement l’objet de contrôles de conformité au format XML et aux règles définies par NeTEx. En dehors de ces contrôles, l’information est totalement ignorée dans le processus d’import. Si cette information est optionnelle, il est fortement conseillé de ne pas la fournir afin de réduire les volumes et les temps de traitements lors de l’import dans le BO IV.
Information (donnée ou objet) exclue : l’information est rejetée car le BO IV ne peut pas l’importer. La présence de l’information rend alors invalide la ligne contenant cette information ou si l’information est commune au jeu de donnée, celui-ci est globalement invalide. L’exclusion est traduite par un point de contrôle obligatoire spécifique à l’import et la présence d’une information exclue sera restituée en erreur dans le rapport d’import produit par le BO IV.
Donnée ou objet exploité : l’information a une utilité à l’import, toutefois, celle-ci n’est pas obligatoirement restituée à l’identique dans l’offre obtenue à l’issu de l’import dans le BO IV ; pour ces données, la définition issue du profil est rappelée afin de faciliter la lecture et si nécessaire, le traitement réalisé à l’import BO IV; par défaut, l’information est importée dans un attribut de l’objet BO IV correspondant. Pour les données optionnelles, sauf mention contraire dans les tableaux, la donnée est laissée vide dans le BO IV si elle n’est pas renseignée à l’import.
Delivery et Frames
Cadres de version ou frames
Les cadres de version sont de 2 types :
...
Chaque fichier XML respecte les règles de format du Profil IDF ; ils sont donc tous composés d’un objet racine de type ‘PublicationDelivery’. Cet objet contient ensuite les cadres de versions qui sont structurés comme indiqué dans le chapitre Delivery et Frames.
PublicationDelivery
Données caractérisant l’objet PublicationDelivery :
Donnée | Type | Cardinalité BO OT | Version |
|---|---|---|---|
version | xsd:NMTOKEN | 1:1 | Identifiant de la version de NeTEx utilisée. Exploité : doit contenir la version du profil. Le format attendu est : 1.04: FR1-NETEX-2.0-z où :
|
PublicationTimestamp | xsd:dateTime | 1:1 | Non exploité, toutefois comme il est obligatoire, il doit contenir une horodate conforme à la syntaxe W3C. Préconisation de format (heure universelle) : AAAA-MM-JJThh:mm:ssZ |
ParticipantRef | ParticipantCodeType | 1:1 | Non exploité, toutefois, comme il est obligatoire, il doit contenir une valeur qui sera ignorée à l’import. Préconisation : Renseigner ici le code de l’organisation de l’utilisateur qui réalise l’import Les valeurs autorisées sont les lettres, chiffres, “.”, “:”, “-” |
dataObjects | dataObjects_ RelStructure | 0:1 1:1 | CompositeFrame de type :
ou GeneralFrame de type :
|
Entités abstraites et héritage
NeTEx définit une hiérarchie d’objets et certains attributs des objets importés sont issus de ces héritages. Afin de simplifier la lecture des attributs relatifs à chaque objet intervenant dans l’import, les attributs issus d’un héritage ne sont rappelés seulement s’ils sont requis pour l’import de l’objet considéré.
...
Ces deux objets parents sont décrits ci-dessous :
Entity (E)
Donnée | Type | Cardinalité BO OT | Description et traitement BO Offre Théorique |
|---|---|---|---|
id | ObjectIdType | 1:1 | Identifiant unique (et pérenne autant que possible) de l'objet. L'identifiant doit être unique pour un type d'objet dans un fichier. Île-de-France Mobilités préconise qu'il soit aussi unique dans un jeu de données entier (ex : pas d'utilisation du même identifiant pour décrire les itinéraires de deux lignes différentes (chacune dans un fichier)) Usage précisé au cas par cas. Limité à 255 caractères |
Règle de syntaxe des identifiants : Les identifiants des objets, autres que les arrêts, respectent la codification suivante :
...
EntityInVersion (EIV) hérite de Entity :
Donnée | Type | Cardinalité BO OT | Description et traitement BO Offre Théorique |
|---|---|---|---|
changed | xsd:dateTime | 0:1 | Date et heure de la dernière modification de l'entité (= de l’objet). Exploité s’il est renseigné sur un objet dont l’ID est conservé dans le BO IV, non exploité sinon. Préconisation : AAAA-MM-JJThh:mm:ssZ (heure universelle) |
version | VersionIdType | 1:1 | Identifiant de version (généralement un numéro) Une seule version d’un objet (même id) est acceptée dans un jeu de données. La valeur ‘any’ est acceptée. Note : Le BO Offre IV impose ses propres règles de versionnement indépendamment des versions fournies à l’import. Cet attribut n'est donc pas repris tel quel en publication. |
ValidBetween | ValidBetween Structure | 0:* | Périodes de validité de l’objet. |
Si l'attribut hérité n'est pas obligatoire, il n'est pas rappelé dans les tableaux du chapitre Import Offre Théorique.
Règles de syntaxe des références
Pour certains attributs, il est attendu des références à des objets dits ‘internes’ (l’objet référencé doit être défini dans le même fichier XML) ou à des objets ‘externes’ (l’objet référencé est présent dans un autre fichier du jeu de données ou dans une autre source de données comme par exemple dans les Référentiels Arrêts ou Lignes).
...
[ID REF LIGNE] : Identifiant de la ligne commerciale dans le Référentiel Lignes
[ID TRANSPORTEUR] : Identifiant du transporteur dans le Référentiel Lignes
[ID ZDEP] : Identifiant de la Zone d'Embarquement Particulière dans le Référentiel Arrêts
Import Offre Théorique
Organisation des imports
Que ce soit via upload depuis l'IHM ou via API, la fonction d’import du BO Offre Théorique s’attend à recevoir les données d’une offre de transport dans un ensemble de fichiers organisés comme suit :
...
Le lot de fichiers est rassemblé dans un fichier archive au format ZIP (avec l’option deflate standard et non deflate64).
Il contient un ou plusieurs dossiers correspondants chacun dossier correspondant à un jeu de données. L'envoi d'une archive contenant plusieurs jeux de données est uniquement accepté pour les transferts via API.
Fichiers et cadres de version :
Chaque fichier xml du dossier contient des données relatives à un ou plusieurs cadres de version et sera contrôlé par l’application :
...
Dans un fichier XML donné, il ne doit y avoir qu’une seule valeur du CODESPACE.
Règles de nommage :
Le nom des fichiers XML est imposé et contrôlé. Pour offre_[ID REF LIGNE]_[nom ligne].xml :
...
Préfixe : "OFFRE_[ID ORGA]_", avec [ID ORGA] correspondant à l'identifiant de l'organisation gérée dans le Portail Transporteur par Île-de-France Mobilités (notion correspondant à la notion actuelle de "site de saisie")
Le reste du nom doit permettre d'identifier clairement le jeu de données pour le producteur. Il peut s'agir d'un numéro de version, si des versions sont gérées dans son système, ou plus simplement la date de production du fichier (préconisation de format : AAAAMMJJhhmmssZ - heure universelle)
Dans le cas d'une archive ne contenant qu'un seul jeu de données, le nom de l'archive est le même que celui du dossier qu'elle contient. Dans le cas d'une archive contenant plusieurs dossiers (envoi multi-jeux), le nom de l'archive est similaire à ceux des dossiers (voir exemple précédent).
Périmètre du jeu de données
Chaque jeu rassemble un ensemble de données d’offre valide :
...
pour les données ayant les mêmes intervalles de validité (chevauchement) :
celles du nouveau jeu écraseront celles de l’ancien jeu,
pour les données n’ayant pas les mêmes intervalles de validité :
celles de l’ancien jeu resteront valides,
celles du nouveau jeu s’ajouteront à celles de l’ancien jeu.
Modélisation des données métier échangées
Les données sont échangées selon la norme NeTEx et s'appuient sur le Profil d’échange IDF défini par Île-de-France Mobilités. Le schéma suivant présente tous les objets requis lors d’un l’import dans le BO Offre Théorique :
...
Les objets présentés en jaune et vert ne font pas partie des données à fournir à l’import, seule une référence externe (au sens NeTEx) est nécessaire.
Delivery et Frames
Les cadres de version attendus à l’import sont structurés de la manière suivante :
commun.xml | calendriers.xml | offre_[ID REF LIGNE]_[Nom ligne].xml | |
Les données caractérisant chaque cadre de version (illustrés ci-dessus en vert) sont précisées dans les chapitres suivants.
Chaque fichier XML respecte les règles de format du Profil IDF ; ils sont donc composés d'abord d’un objet racine de type ‘PublicationDelivery’ (voir PublicationDelivery).
Cadre de version ‘NETEX_COMMUN’
Organisation et hiérarchie du cadre de version :
Dans celui-ci ne seront traités que des objets de type ‘NOTICE’.
Les autres types autorisés dans ce cadre de version par le Profil IDF sont ignorés (voir ci après).
Description de la General Frame NETEX_COMMUN
Donnée | Type | Cardinalité BO OT | Description et traitement BO Offre Théorique |
|---|---|---|---|
(E) id | ObjectIdType | 1:1 | Non exploité, mais obligatoire |
(EIV) version | VersionIdType | 1:1 | Non exploité, mais obligatoire Préconisation : 'any' |
TypeOfFrameRef | TypeOfFrameRef | 0:1 1:1 | Référence au TYPE OF VERSION FRAME utilisé. Doit être NETEX_COMMUN Préconisation : <TypeOfFrameRef ref="FR1:TypeOfFrame:NETEX_COMMUN:">version="1.04:FR1-NETEX_COMMUN-2.1"</TypeOfFrameRef> |
members | EntityInFrame | 0:* | Contient la liste des objets contenus dans la Frame (Voir ci-après) |
Objets pris en compte par le BO Offre Théorique
NOTICE (Note) : Un texte à vocation informationnelle, en général concernant des exceptions d'utilisation, et rattaché dans le cadre du BO Offre Théorique à des SERVICE JOURNEY (Courses)
Donnée | Type | Cardinalité BO OT | Description et traitement BO Offre Théorique |
|---|---|---|---|
(E) id | ObjectIdType | 1:1 | Identifiant de la note Préconisation : [CODESPACE]:Notice:[id interne]:LOC |
(EIV) version | VersionIdType | 1:1 | Version unique ou ’any’ |
Text | MultilingualString | 0:1 1:1 | Texte de la NOTICE(Note) Exploité : Ce champ doit être explicitement renseigné car il a pour but d'être diffusé en information voyageur. Limité à 255 caractères |
PublicCode | xsd:normalizedString | 1:1 | Code publique de la NOTICE(Note) Exploité : Ce code doit être unique pour les notes d’une ligne de transport. Correspond au numéro du renvoi, diffusé en information voyageur. |
TypeOfNoticeRef | TypeOfNoticeRef | 1:1 | Seules les notes de type ‘ServiceJourneyNotice’ sont exploitées* |
*Le typage des notes indique sur quel type d'objet la note porte. Des notes de type "LineNotice" (portant sur une ligne entière) peuvent également être renseignées, mais celles-ci doivent être saisies dans le Référentiel Lignes (ex : indication de l'obligation de réservation pour une ligne TAD).
...
Les notes peuvent être "partagées" par toutes les lignes d'une offre du jeu de données. Toutefois, dans le BO Offre théorique, ces notes seront dupliquées pour être attribuées à chacune des lignes concernées.
Objets ignorés dans le cadre de version
(La présence d’un objet de l’un de ces types ne perturbe pas l’import si la grammaire XML et XSD NeTEx est respectée ; toute erreur XML ou XSD provoque l’interruption de l’import et le rejet total du jeu de données) :
ALTERNATIVE NAME
NOTICE ASSIGNMENT
ORGANISATION
RESPONSIBILITY ROLE ASSIGNMENT
TYPE OF FRAME
TYPE OF VALUE
VALIDITY CONDITION
Cadre de version ‘NETEX_CALENDRIER’
Organisation et hiérarchie du cadre de version :
Dans celui-ci ne seront exploités que des objets de type ‘DAY TYPE’, ‘OPERATING PERIOD’ et ‘DAY TYPE ASSIGNMENT’.
...
Les courses référencent un ou plusieurs DAY TYPE (Type de Jour), cet objet est donc la référence pour modéliser un calendrier. Dans le BO Offre Théorique, chaque objet DAY TYPE avec ses dépendances est transformé en un objet BO Offre Théorique nommé ‘Calendrier’.
Description de la General Frame NETEX_CALENDRIER
Donnée | Type | Cardinalité BO OT | Description et traitement BO Offre Théorique |
|---|---|---|---|
(E) id | ObjectIdType | 1:1 | Non exploité, mais obligatoire |
(EIV) version | VersionIdType | 1:1 | Non exploité, mais obligatoire. Préconisation :’any’ |
ValidBetween | ValidBetween Structure | 0:* 1 :* | Définit la ou les périodes de validité du jeu de données Format (exemple) :
|
TypeOfFrameRef | TypeOfFrameRef | 0:1 1:1 | Référence au TYPE OF VERSION FRAME utilisé. Doit être NETEX_CALENDRIER Préconisation : <TypeOfFrameRef ref="FR1:TypeOfFrame:NETEX_CALENDRIE R:">version="1.04:FR1-NETEX_CALENDRIER-2.1"</TypeOfFrameRef> |
members | EntityInFrame | 0:* | Contient la liste des objets contenus dans la Frame (Voir ci-dessous) |
*La Frame NETEX_CALENDRIER indique la Période de Validité (ValidBetween) du jeu de données entier. Elle peut se composer
...
Ce fonctionnement est une nouveauté par rapport au Back Office actuel, qui suite à un import écrasait les données sur toute la période gérée dans la base communautaire (1 an 1/2, glissant tous les ans). Il permettra notamment de gérer plus facilement les périodes de transition lors d'une restructuration.
Objets pris en compte par le BO Offre Théorique
DAY TYPE (Type de Jour) : Objet servant de base à la construction du calendrier. Il est référencé par les SERVICE JOURNEY (Courses).
Donnée | Type | Cardinalité BO OT | Description et traitement BO Offre Théorique |
|---|---|---|---|
(E) id | ObjectIdType | 1:1 | Identifiant du DAY TYPE Préconisation : [CODESPACE]:DayType: [id interne]:LOC |
(EIV) version | VersionIdType | 1:1 | Version unique ou ’any’ |
Name | MultilingualString | 0:1 | Nom du DAY TYPE (Type de Jour) Si absent, alors un nom de calendrier sera généré automatiquement à l’import ; ce nom est affiché dans l’IHM du BO Offre Théorique pour la sélection des calendriers. |
properties | PropertyOfDay | 0:* | Liste de type de jours de validité du calendrier d'application. Seuls les types DaysOfWeek (Monday, Tuesday, Wednesday, Thursday, Friday, Saturday et Sunday) sont exploités. Si les DayTypeAssignment référencent uniquement des ’Date’, la liste doit être vide. En présence d’au moins une référence à une période, la liste doit être renseignée avec au moins un des types DaysOfWeek. Ces restrictions ne s'appliquent que sur les périodes, pas sur les dates. |
DAY TYPE ASSIGNMENT : Objet permettant d' "assigner" (ajouter ou retrancher en fonction du critère IsAvailable) des dates ou des OPERATING PERIOD (Périodes d'Exploitation) à un DAY TYPE.
Donnée | Type | Cardinalité BO OT | Description et traitement BO Offre Théorique |
|---|---|---|---|
(E) id | ObjectIdType | 1:1 | Identifiant du DAY TYPE - ASSIGNMENT Préconisation : [CODESPACE]:DayTypeAssignment: [id interne]:LOC |
(EIV) version | VersionIdType | 1:1 | Version unique ou ’any’ |
order | xsd:integer | 1:1 | Ordre : non exploité, mettre la valeur 0 |
OperatingPeriodRef | OperatingPeriod Ref | 0:1 | Référence interne à une OPERATING PERIOD |
Date | xsd:Date | 0:1 | Date calendaire. Format : <Date>2017-08-28</Date> |
DayTypeRef | DayTypeRef | 1:1 | Référence le DAY TYPE (Type de jour) concerné (référence interne). |
isAvailable | boolean | 0:1 | La valeur "False" permet d'exprimer des exceptions (ex : sauf le 1er avril). Si l'attribut n'est pas renseigné, le BO Offre Théorique l’interprète à ‘vrai’ |
Note : Un DAY TYPE doit obligatoirement être référencé dans un DAY TYPE ASSIGNMENT, sinon il ne sera pas pris en compte.
OPERATING PERIOD : Intervalle de temps continu, défini par une date de début et de fin. Rattaché à un ou plusieurs DAY TYPE (Type de Jour) via l'objet DAY TYPE ASSIGNEMENT.
Donnée | Type | Cardinalité BO OT | Description et traitement BO Offre Théorique |
|---|---|---|---|
(E) id | ObjectIdType | 1:1 | Identifiant du DAY TYPE - ASSIGNMENT Préconisation : [CODESPACE]:DayTypeAssignment: [id interne]:LOC |
(EIV) version | VersionIdType | 1:1 | Version unique ou ’any’ |
FromDate | xsd:date | 1:1 | Date calendaire de début* |
ToDate | xsd:date | 1:1 | Date calendaire de fin* La date de fin doit être strictement supérieure à la date de début |
*Format pour les dates de type : <FromDate>2017-06-01T00:00:00</From Date>
...
Ce DAY TYPE "négatif" n'est pas conservé tel quel dans le BO Offre Théorique. Le résultat de la soustraction de ce DAY TYPE à un second DAY TYPE génère un seul calendrier dans le BO.
Règles d'import / Cohérence entre les fichiers
A l’issu de l’import, les calendriers qui ne couvrent aucun jour de la période de validité du jeu de donnée ne sont pas présents,
Les courses qui n’étaient associées qu’à ces calendriers ne sont pas importées,
Par effet cascade, les missions commerciales se retrouvant sans courses ne sont pas importées, ainsi que les itinéraires.
...
Date calendaire déjà présente dans une période
Périodes se chevauchant
Objets ignorés dans le cadre de version
La présence d’un objet de l’un de ces types ne perturbe pas l’import si la grammaire XML et XSD NeTEx est respectée ; toute erreur XML ou XSD provoque l’interruption de l’import et le rejet total du jeu de données :
...
Toute relation entre ces objets et ceux exploités lors d’import sera aussi ignorée
Cadres de version constituant l’offre d’une ligne (NETEX_OFFRE_LIGNE)
Organisation et hiérarchie du cadre de version :
Chaque fichier offre_[ID REF LIGNE]_[Nom ligne].xml contient les informations permettant de décrire l' "offre" pour une ligne commerciale (un fichier .xml par ligne).
...
NETEX_OFFRE_LIGNE est une Composite Frame ; elle contient elle-même deux Frames : NETEX_STRUCTURE (description de la structure de la ligne) et NETEX_HORAIRE (description des courses et horaires).
...
Donnée | Type | Cardinalité BO OT | Description et traitement BO Offre Théorique |
|---|---|---|---|
(E) id | ObjectIdType | 1:1 | Non exploité. Préconisation : [CODESPACE]: CompositeFrame:NETEX_OFFRE_LIGNE-[ID REF Ligne Commerciale]:LOC |
(EIV) version | VersionIdType | 1:1 | Non exploité. Préconisation : ’any’ |
TypeOfFrameRef | TypeOfFrameRef | 0:1 1:1 | Référence au TYPE OF VERSION FRAME utilisé. Doit être NETEX_OFFRE_LIGNE Préconisation : <TypeOfFrameRef ref="FR1:TypeOfFrame:NETEX_OFFRE_LIGNE:">version="1.04:FR1-NETEX_OFFRE_LIGNE-2.1"</TypeOfFrameRef> |
frames | Frame | 0:* | Liste des frames de la frame composite Exploité : contient dans l’ordre les 2 GeneralFrames :
|
Fichier offre_[ID REF LIGNE]_[Nom ligne].xml "vide" :
Si l'attribut modification dans la Frame NETEX_OFFRE_LIGNE est "delete", et que celle-ci ne contient aucune frame NETEX_STRUCTURE ni NETEX_HORAIRE, alors il est considéré que la ligne ne circule pas sur la période de validité du jeu de données (période définie dans la frame NETEX_CALENDRIER). Si une offre sur cette période a déjà été importée précédemment à Ile-de-France Mobilités, elle sera donc "écrasée".
Cadre de version ‘NETEX_STRUCTURE’
Organisation et hiérarchie du cadre de version
...
L’une avec la balise QuayRef:
<PassengerStopAssignment id="enRoute:PassengerStopAssignment:1-2:LOC" version="any" order="0"> <ScheduledStopPointRef ref="enRoute:ScheduledStopPoint:1-2:LOC" version="any"/> <QuayRef ref="FR::Quay:50111663:FR1">version="any"</QuayRef> </PassengerStopAssignment> |
L’autre avec StopPlaceRef:
<PassengerStopAssignment id="enRoute:PassengerStopAssignment:1-1:LOC" version="any" order="0"> <ScheduledStopPointRef ref="enRoute:ScheduledStopPoint:1-1:LOC" version="any"/> <StopPlaceRef ref="FR::monomodalStopPlace:44096:FR1">version="any"</StopPlaceRef> </PassengerStopAssignment> |
Dans les deux cas, la mission et son itinéraire sont associés à l’arrêt désigné par la référence.
...
Description de la Generale Frame NETEX_STRUCTURE
Donnée | Type | Cardinalité BO OT | Description et traitement BO Offre Théorique |
(E) id | ObjectIdType | 1:1 | Non exploité Préconisation : [CODESPACE]: NETEX_STRUCTURE-AAAAMMJJhhmmssZ:LOC , avec AAAAMMJJhhmmssZ = heure de génération fichier (heure universelle) |
(EIV) version | VersionIdType | 1:1 | Non exploité Préconisation :’any’ |
TypeOfFrameRef | TypeOfFrameRef | 0:1 1:1 | Référence au TYPE OF VERSION FRAME utilisé. Doit être NETEX_STRUCTURE Préconisation : <TypeOfFrameRef ref="FR1:TypeOfFrame:NETEX_STRUCTURE:">version="1.04:FR1-NETEX_STRUCTURE-2.1"</TypeOfFrameRef> |
members | EntityInFrame | 0:* | Contient la liste des objets de la Frame |
Objets liés à la définition d'une ROUTE (itinéraire)
ROUTE (Itinéraire) : Liste ordonnée de POINTs définissant un seul chemin à travers le réseau routier (ou ferré). Un Itinéraire peut passer deux fois par un même POINT.
Donnée | Type | Cardinalité BO OT | Description et traitement BO Offre Théorique |
(E) id | ObjectIdType | 1:1 | Identifiant de l’itinéraire Préconisation : [CODESPACE]:Route: [id interne]:LOC |
(EIV) version | VersionIdType | 1:1 | Version unique ou ’any’ |
Name | MultilingualString | 0:1 | Nom de l’itinéraire Nom "technique". Sera présent en publication en sortie du BO Offre Théorique, mais non utilisé pour l'information voyageur Ile-de-France Mobilités. Si non renseigné, la valeur à l’import sera forcée à la concaténation des chaînes DirectionType et le nom du dernier arrêt de l’itinéraire. |
LineRef | LineRef | 0:1 1:1 | Référence externe à la ligne Cette référence doit être connue du Référentiel Lignes. |
DirectionType | TypeOfDirectionEnum | 0:1 | Type de direction de l'itinéraire Seuls les types outbound ou inbound sont acceptés dans le cadre de l'import dans le BO Offre Théorique. Si non renseigné, la valeur à l’import sera forcée à ‘outbound’ (aller) Les DirectionType de 2 itinéraires inverses doivent être différents. Il peut y avoir plusieurs itinéraires aller et/ou retour pour une même ligne. |
DirectionRef | DirectionRef | 0:1 | Référence la DIRECTION de l'itinéraire Voir tableau suivant Si l'itinéraire ne référence pas de direction, un nom de direction sera calculé automatiquement à partir du dernier point d'itinéraire, et sera proposé par le BO Offre Théorique en publication. |
pointsInSequence | PointOnRoute | 0:1 | Liste des points de l'ITINÉRAIRE. |
InverseRouteRef | RouteRef | 0:1 | Référence l'éventuel ITINÉRAIRE en sens opposé Référence interne, l’itinéraire opposé doit être présent dans les données importées. |
| Info |
|---|
Le regroupement d'itinéraire que constituait la sous-ligne n'existe pas dans NETEX. Toutefois, les itinéraires aller et retour peuvent être couplés deux à deux en indiquant la référence à l'itinéraire inverse dans l'attribut " InverseRouteRef". Si un itinéraire (A) référence un itinéraire (B) comme son inverse, l'itinéraire B ne peut pas référencer un 3ème itinéraire (C) comme son propre inverse. De plus, les deux itinéraires opposés doivent se référencer mutuellement, sinon l'association sera invalidée à l'import et une alerte sera communiquée. |
POINT ON ROUTE (Point sur itinéraire) - inclus dans ROUTE : Point de passage de l'itinéraire
Donnée | Type | Cardinalité | Description |
(E) id | ObjectIdType | 1:1 | [CODESPACE]:PointOnRoute: [Id technique]:LOC |
(EIV) version | VersionIdType | 1:1 | Version fixé à “any“ |
order | xsd:positiveInteger | 1:1 | les PointOnRoute sont inclus dans l’objet Route, leur ordre est implicitement celui de la séquence |
RoutePointRef | RoutePointRef | 1:1 | Référence au POINT D'ITINÉRAIRE correspondant Cette référence permet d’établir le lien entre le tracé RouteLink et l’itinéraire (Route) |
ROUTE POINT (Point d'itinéraire) : Point d’itinéraire
Donnée | Type | Cardinalité | Description |
(E) id | ObjectIdType | 1:1 | [CODESPACE]:RoutePoint: [Id technique]:LOC |
(EIV) version | VersionIdType | 1:1 | Version fixé à “any“ |
projections | PointProjection > ProjectToPointRef | 1:1 | Référence au ScheduledStopPoint desservi par l’itinéraire |
DIRECTION (Direction) : Direction de la ROUTE (Itinéraire).
Donnée | Type | Cardinalité BO OT | Description et traitement BO Offre Théorique |
(E) id | ObjectIdType | 1:1 | Identifiant de la direction Préconisation : [CODESPACE]: Direction:[id interne]:LOC |
(EIV) version | VersionIdType | 1:1 | Version unique ou ’any’ |
Name | MultilingualString | 0:1 1:1 | Désignation de la direction Ne pas indiquer les mentions de type "Vers..". |
Le nom de la direction est souvent indiqué sur la fiche horaire en haut des tableaux horaires.
...
SERVICE JOURNEY PATTERN (Mission Commerciale) : Liste ordonnée de Points d'Arrêts Planifiés sur un unique Itinéraire, décrivant le plan de déplacement pour les véhicules de transport public. Une Mission peut passer par le même Point plus d'une fois. Le premier Point d'une Mission est l'origine. Le dernier Point est la destination.
Donnée | Type | Cardinalité BO OT | Description et traitement BO Offre Théorique |
(E) id | ObjectIdType | 1:1 | Identifiant de la Mission Commerciale Préconisation : [CODESPACE]: ServiceJourneyPattern:[id interne]:LOC |
(EIV) version | VersionIdType | 1:1 | Version unique ou ’any’ |
Name | MultilingualString | 0:1 | Nom de la Mission Commerciale Nom "technique". Sera présent en publication en sortie du BO Offre Théorique, mais non utilisé pour l'information voyageur Ile-de-France Mobilités (utilisation de Destination Display) Si non renseigné, la valeur à l’import sera forcée au nom du dernier arrêt de la mission. |
RouteRef | RouteRef | 0:1 1:1 | Itinéraire utilisé par la Mission Commerciale. Référence interne à ROUTE |
DestinationDisplay Ref | DestinationDisplay Ref | 0:1 | Affichage de la destination associé à la Mission Commerciale. Obligatoire pour les lignes Train (code mission indiqué dans Destination Display) Si la mission ne référence pas de destination, un "FrontText" sera calculé automatiquement à partir du dernier point de la mission, et sera proposé par le BO Offre Théorique en publication. Voir tableau suivant |
pointsInSequence | StopPointInJourney Pattern | 0:* 2:* | Liste ordonnée des points sur la Mission Commerciale Ne sont acceptés ici que des STOP POINT IN JOURNEY PATTERN (Points d'Arrêt sur Mission) Voir tableau ci-après |
ServiceJourney PatternType | ServiceJourneyPattern TypeEnumeration | 0:1 1:1 | Type de Mission Commerciale Seul le type « Passenger » est exploité dans l’import. Les autres types de missions seront ignorées après contrôle XSD Seuls les parcours commerciaux correspondants à du transport de voyageurs ont vocation à être stockés dans le BO OFFRE |
DESTINATION DISPLAY : Une destination d'une mission particulière, affichée au public en général sur une girouette ou sur tout autre afficheur embarqué.
Donnée | Type | Cardinalité BO OT | Description et traitement BO Offre Théorique |
(E) idDonnée | ObjectIdType | 1:1 | Identifiant de la destination Non conservé par le BO Offre Théorique qui fusionne les attributs de la destination avec ceux de la mission Préconisation : [CODESPACE]: DestinationDisplay:[id interne]:LOC |
(EIV) version | VersionIdType | 1:1 | Version unique ou ’any’ |
FrontText | MultilingualString | 1:1 | Texte frontal (affiché sur le devant du véhicule) de l'AFFICHAGE DE DESTINATION Ce texte n’est pas forcément le nom du dernier arrêt de la mission, il peut par exemple inclure les via ou l’information ‘service partiel’* |
PublicCode | xsd:normalizedString | 0:1 | Code associé à l'AFFICHAGE DE DESTINATION. |
Le nom de la destination (FrontText) correspond souvent au nom du dernier arrêt de la mission. Dans ce cas, Ile-de-France Mobilités préconise de structurer le nom ainsi :
...
STOP POINT IN JOURNEY PATTERN (Point sur Mission) - inclus dans SERVICE JOURNEY PATTERN : Un SCHEDULED STOP POINT (Point d'Arrêt Planifié) dans un SERVICE JOURNEY PATTERN (Mission Commerciale) indiquant son rang dans cette Mission.
Donnée | Type | Cardinalité BO OT | Description et traitement BO Offre Théorique |
(E) id | ObjectIdType | 1:1 | Identifiant du point d’arrêt sur mission Préconisation : [CODESPACE]: StopPointInJourneyPattern:[id interne]:LOC |
(EIV) version | VersionIdType | 1:1 | Version unique ou ’any’ |
order | xsd:positiveInteger | 1:1 | Ordre du point d'arrêt dans l'itinéraire. Les "order" des Stop Point In Journey Pattern peuvent être discontinus mais ils sont toujours croissants, car les Stop Point In Journey Pattern doivent être ordonnés dans le Service Journey Pattern. |
ScheduledStopPoint Ref | ScheduledStopPoint Ref | 1:1 | Référence au SCHEDULED STOP POINT (Point d'Arrêt Planifié). Référence interne. |
ForAlighting | xsd:boolean | 0:1 | Indique que l'on peut descendre du véhicule à ce point (vrai par défaut)* |
ForBoarding | xsd:boolean | 0:1 | Indique que l'on peut embarquer dans le véhicule à ce point (vrai par défaut)* |
Interdictions de montée/descente : Les informations ForAlighting (Descendre) et ForBoarding (Monter) relatives à la description d’un ITL non zonal seront communes à l’itinéraire. En conséquence, celles-ci ne seront interprétées que si toutes les missions d’un même itinéraire fournissent la même valeur pour l’ensemble de ces attributs. Dans le cas contraire, ces informations sont neutralisées avec un signalement lors de l’import.
...
SCHEDULED STOP POINT (Point d'Arrêt Planifié) : Un POINT où les passagers peuvent monter à bord ou descendre des véhicules. Cet objet est partagé entre les différents SERVICE JOURNEY PATTERN (Missions) d’une même ROUTE (Itinéraire).
Donnée | Type | Cardinalité BO OT | Description et traitement BO Offre Théorique |
(E) id | ObjectIdType | 1:1 | Identifiant du point d’arrêt planifié Préconisation : [CODESPACE]: ScheduledStopPoint:[id interne]: LOC |
(EIV) version | VersionIdType | 1:1 | Version unique ou ’any’ |
PASSENGER STOP ASSIGNMENT : Permet d'associer un point "horaire" : SCHEDULED STOP POINT (Point d'Arrêt Planifié), à un point "physique" : dans le cas de l'import dans le BO Offre Théorique seule l'association à un ZDEP connu du Référentiel Arrêts est acceptée.
Donnée | Type | Cardinalité BO OT | Description et traitement BO Offre Théorique |
(E) id | ObjectIdType | 1:1 | Identifiant de l’affectation d’arrêt Préconisation : [CODESPACE]: PassengerStopAssignment:[id interne]:LOC |
(EIV) version | VersionIdType | 1:1 | Version unique ou ’any’ |
order | xsdinteger | 1:1 | Ordre : non exploité, mettre la valeur 0 |
ScheduledStopPoint Ref | ScheduledStopPointRef | 0:1 1:1 | Référence interne au SCHEDULED STOP POINT (Point d'Arrêt Planifié) |
StopPlaceRef | StopPlaceRef | 0:1 | Référence externe à la Zone de lieu (ZDL) du Référentiel Arrêts |
QuayRef | QuayRef | 0:1 | Référence externe à la Zone d'Embarquement (ZDEP) du Référentiel Arrêts |
Afin de simplifier la construction du fichier et de faciliter la lecture, si le producteur de la donnée ne dispose pas de ces différents concepts dans son SI source, il est possible de générer le même ID Interne pour les objets suivants : SCHEDULED STOP POINT et PASSENGER STOP ASSIGNMENT.
...
ROUTING CONSTRAINT ZONE : ZONE au sein de laquelle une contrainte d'acheminement s'applique. La ZONE est définie par la liste des SCHEDULED STOP POINT (Points d'Arrêt Planifiés) qu'elle contient.
Donnée | Type | Cardinalité BO OT | Description et traitement BO Offre Théorique |
(E) id | ObjectIdType | 1:1 | Identifiant de la contrainte de zone Préconisation : [CODESPACE]: RoutingConstraintZone:[id interne]:LOC |
(EIV) version | VersionIdType | 1:1 | Version unique ou ’any’ |
Name | MultilingualString | 0:1 | Nom de la contrainte de zone Ce nom a usage technique n’a pas à être diffusé aux voyageurs.. |
(members) | Spécifié dans RoutingConstraintZone | 0:1 1:1 | Liste des arrêts planifiés: Contient les ScheduledStopPointRef concernés par l’ITL |
ZoneUse | ZoneUseTypeEnum | 0:1 | Contrainte appliquée à la ZONE Seule la valeur cannotBoardAndAlightInSameZone est acceptée |
Note :Dans le BO Offre théorique, les ITL sont reliées aux itinéraires ; dans le cas où une RoutingConstraintZone contient des références à des ScheduledStopPoint utilisés par plusieurs itinéraires, celle-ci génèrera autant d’ITL que d’itinéraires concernés par au moins 2 ScheduledStopPoint de la RoutingConstraintZone tout en excluant les itinéraires entièrement couverts par celle-ci.
...
CONNECTION
DEFAULT CONNECTION
FLEXIBLE LINE
FLEXIBLE LINK PROPERTIES
FLEXIBLE POINT PROPERTIES
FLEXIBLE ROUTE
GROUPE OF ENTITIES
GROUP OF LINE
LINE
NETWORK
ROUTE LINK
SCHEMATIC MAP
SITE CONNECTION
TARIF ZONE
TIMING POINT
TRANSFER RESTRICTION
Cadre de version ‘NETEX_HORAIRE’
Organisation et hiérarchie du cadre de version :
...
Dans le cas ou au moins un PASSENGER STOP ASSIGNMENT pointent des StopPlace (ZDL) l’import peut utiliser l’objet VEHICLE JOURNEY STOP ASSIGNMENT. Celui-ci peut modifier le passage de la course associée pour définir si besoin des arrêts spécifiques de type ZDEP référencés par la balise QuayRef.
<GeneralFrame id="enRoute:GeneralFrame:NETEX_HORAIRE-20170214090012:LOC" version="any"> <TypeOfFrameRef ref="FR1:TypeOfFrame:NETEX_HORAIRE:"/> <members> <ServiceJourney id="enRoute:ServiceJourney:1-1:LOC" version="any"> <Name>VehicleJourneyStopAssignment example</Name> <!-- ... --> </ServiceJourney> <!-- For this given ServiceJourney, ScheduledStopPoint is associated to a Quay --> <VehicleJourneyStopAssignment id="enRoute:VehicleJourneyStopAssignment:1-1-1:LOC" version="any"> <ScheduledStopPointRef ref="enRoute:ScheduledStopPoint:1-1:LOC" version="any"/> <QuayRef ref="FR::Quay:5001111:FR1">version="any"</QuayRef> <VehicleJourneyRef ref="enRoute:ServiceJourney:1-1:LOC" version="any"/> </VehicleJourneyStopAssignment> </members> </GeneralFrame> |
Si la course référencée par la balise VehicleJourneyRef n’est pas trouvée dans l’offre importée, une erreur est ajoutée à l’import.
...
1 : Ne circule pas le 14 juillet
Description de la Frame NETEX_HORAIRE
Donnée | Type | Cardinalité BO OT | Description et traitement BO Offre Théorique |
(E) id | ObjectIdType | 1:1 | Non exploité Préconisation : [CODESPACE]:NETEX_HORAIRE-AAAAMMJJhhmmssZ:LOC , avec AAAAMMJJhhmmssZ = heure de génération fichier (heure universelle) |
(EIV) version | VersionIdType | 1:1 | Non exploité. Préconisation : 'any' |
TypeOfFrameRef | TypeOfFrameRef | 0:1 1:1 | Référence au TYPE OF VERSION FRAME utilisé. Doit être NETEX_HORAIRE Préconisation : <TypeOfFrameRef ref="FR1:TypeOfFrame:NETEX_HORAIRE:">version="1.04:FR1-NETEX_HORAIRE-2.1"</TypeOfFrameRef> |
members | EntityInFrame | 0:* | Contient la liste des objets de la frame |
Objets pris en compte par le BO Offre Théorique :
SERVICE JOURNEY (Course) : le mouvement planifié d'un véhicule de transport public effectué un DAY TYPE (Type de Jour) donné, depuis un point début à un point fin d'un SERVICE JOURNEY PATTERN (Mission) sur une ROUTE (Itinéraire). Le SERVICE JOURNEY (Course) est donc l'instanciation d'un SERVICE JOURNEY PATTERN (Mission) donné, auquel on va attribuer des heures de passage aux arrêts et des jours d'application.
Donnée | Type | Cardinalité BO OT | Description et traitement BO Offre Théorique |
(E) id | ObjectIdType | 1:1 | Identifiant de la course Préconisation : [CODESPACE]: ServiceJourney:[ID interne]:LOC |
(EIV) version | VersionIdType | 1:1 | Version unique ou ’any’ |
Name | MultilingualString | 0:1 | Nom de la course Ce nom à usage technique n’a pas à être diffusé aux voyageurs |
noticeAssignments | noticeAssignments | 0:* | NOTEs associées à la COURSE Voir tableau ci-dessous |
DayTypeRef | DayTypeRef | 1:* | TYPE DE JOUR correspondant aux jours d'application de la course. Référence externe définie dans le fichier ‘Calendriers.xml’ |
JourneyPatternRef | JourneyPatternRef | 0:1 1:1 | Référence interne à la mission (celle-ci doit être déclarée dans la frame NETEX_STRUCTURE du même fichier) |
OperatorRef | OperatorRef | 0:1 | Référence l'EXPLOITANT opérant cette course. Référence externe (l’opérateur est défini dans le Référentiel Lignes et doit être l’un des opérateurs de la ligne) Renseigné uniquement si différent de l’exploitant principal de la ligne. |
trainNumbers | trainNumbers | 0:* 0:1 | Référence au numéro de train associé. Comme l’objet référencé n’existe pas dans le fichier, cette référence doit être formatée en mode référence externe. Préconisation (exemple) : <TrainNumberRef ref="SNCF:TrainNumber:630002:LOC"/> |
passingTimes | TimetabledPassingTime | 0:* 2:* | Heures de passages planifiées aux arrêts. Voir tableau ci-après |
NOTICE ASSIGNMENT - inclus dans SERVICE JOURNEY : affectation d'une NOTE à un objet (ici pour signaler une exception sur un SERVICE JOURNEY (Course)).
Donnée | Type | Cardinalité BO OT | Description et traitement BO Offre Théorique |
(E) id | ObjectIdType | 1:1 | Identifiant du NOTICE - ASSIGNMENT Préconisation : [CODESPACE]:Notice: [id interne]:LOC |
(EIV) version | VersionIdType | 1:1 | Version unique ou ’any’ |
order | xsd:integer | 1:1 | Ordre : non exploité, mettre la valeur 0 |
NoticeRef | NoticeRef | 1:1 | Référence externe à une notice définie dans le cadre de version NETEX_COMMUN (fichier commun.xml) |
TIMETABLED PASSING TIME - inclus dans SERVICE JOURNEY: Donnée temporelle théorique relative au passage d'un véhicule de transport public à un POINT IN SERVICE JOURNEY PATTERN (Point sur Mission) donné sur un SERVICE JOURNEY (Course) et pour un DAY TYPE (Type de Jour)
Donnée | Type | Cardinalité BO OT | Description et traitement BO Offre Théorique |
(EIV) version | VersionIdType | 1:1 | Non exploité. Préconisation : ‘any’ |
ArrivalDayOffset | xsd:integer | 0:1 | Non exploité, seul le DepartureDayOffset sera exploité. |
ArrivalTime | xsd:time | 0:1 | Heure d'arrivée. Format : hh:mm:00.000 (heure locale*) Note : Même si le format NETEX impose d'indiquer des secondes, celles-ci ne sont pas prises en compte par l'import dans le BO Offre Théorique. Forcé à l’heure du DepartureTime si l’attribut est vide ou absent |
DepartureTime | xsd:time | 0:1 1:1 | Heure de départ. Format : hh:mm:00.000 (heure locale*) Note : Même si le format NETEX impose d'indiquer des secondes, celles-ci ne sont pas prises en compte par l'import dans le BO Offre Théorique. |
DepartureDayOffset | xsd:integer | 0:1 | Nombre de jour de décalage par rapport au jour de début de course (permet de gérer les courser à cheval sur plusieurs jours) Forcé à 0 si absent. Le premier horaire doit avoir un DepartureDayOffset à 0 ou absent. Si les heures d’arrivée et de départ sont sur des jours différents, le DepartureDayOffset s’applique au départ., l’heure d’arrivée peut dans ce cas être supérieure à celle de départ. |
*Dans le cas du changement d'heure, si des courses débutent à l'ancienne heure et s'achèvent après le changement d'heure, tous les ArrivalTime et DepartureTime doivent être sur le système du premier horaire de la course (système pré-changement d'heure).
VEHICLE JOURNEY STOP ASSIGNMENT : Il permet de définir si besoin des arrêts spécifiques de type ZDEP référencés par la balise QuayRef pour une course.
Donnée | Type | Cardinalité BO OT | Description et traitement BO Offre Théorique |
(EIV) version | VersionIdType | 1:1 | Non exploité. Préconisation : ‘any’ |
ScheduledStopPointRef | ScheduledStopPointRef | 1:1 | Référence interne au SCHEDULED STOP POINT (Point d'Arrêt Planifié) |
QuayRef | QuayRef | 1:1 | Référence externe à la Zone d'Embarquement (ZDEP) du Référentiel Arrêts |
VehicleJourneyRef | VehicleJourneyRef | 1:n | Référence interne à la course (celle-ci doit être déclarée dans la frame NETEX_HORAIRE du même fichier) |
Objets ignorés dans le cadre de version
...