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 : 

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 :

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)

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 :

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).

Ces références comportent 2 champs obligatoires : l’identifiant de l’objet référencé et sa version.

Syntaxe pour les références à un objet du jeu de données:

• Référence interne (objet dans le même fichier) : 

<ObjetRef ref="[ID de l'objet]" version="[VERSION de l'objet]" />

• Référence externe (objet dans un fichier différent du même jeu de données)

<ObjetRef ref="[ID de l'objet]"> version="[VERSION de l'objet]"</ObjetRef >

Avec : 

• [ID de l'objet] : l’attribut respecte la syntaxe des identifiants (voir Entités abstraites et héritage) 

• [VERSION de l'objet] : l’attribut correspond au même numéro de version que celui indiqué pour l'objet dans le jeu de données.

Exemple :

Référence au sein d'un fichier offre_[ID REF LIGNE]_[Nom ligne].xml :

<RouteRef  ref="TRANDEV:Route:1234:LOC" version="any"/>

Référence d'un fichier offre_[ID REF LIGNE]_[Nom ligne].xml à calendriers.xml :

<DayTypeRef  ref="TRANDEV:DayType:64:LOC"> version="any"</DayTypeRef>

Syntaxe pour les références à un objet stocké dans le Référentiel Lignes (Ligne commerciale ou Transporteur) ou dans le Référentiel Arrêts (ZDEP) : 

<LineRef ref="FR1:Line:[ID REF LIGNE]:">version="any"</LineRef>

...

<OperatorRef ref="FR1:Operator:[ID TRANSPORTEUR]:LOC ">version="any" </OperatorRef>

...

<QuayRef ref="FR::Quay:[ID ZDEP]:FR1">version="any"</QuayRef>

Avec : 

• [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
Image Modified

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

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)

*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

*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).

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.

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.

*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).

...

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:

L’autre avec StopPlaceRef:

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

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.

POINT ON ROUTE (Point sur itinéraire) - inclus dans ROUTE : Point de passage de l'itinéraire

ROUTE POINT (Point d'itinéraire) : Point d’itinéraire

DIRECTION (Direction) : Direction de la ROUTE (Itinéraire). 

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.

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é. 

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.

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).

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.

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.

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.

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

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.

NOTICE ASSIGNMENT - inclus dans SERVICE JOURNEY : affectation d'une NOTE à un objet (ici pour signaler une exception sur un SERVICE JOURNEY (Course)). 

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)

*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.

Objets ignorés dans le cadre de version 

...