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.

Dans le cadre de la phase 1 de ce programme, Île-de-France Mobilités assure un portage iso-fonctionnel des objets actuellement transmis par les Transporteurs vers la base DUALE. Contrairement à la base DUALE actuelle, qui concentre l’ensemble des données IV fournies par le Transporteur dans une unique base de données, le futur Back-Office Offre Théorique modernisé prévoit de s’appuyer sur les Référentiels Arrêts et Lignes pour isoler les concepts relatifs aux arrêts et aux correspondances d’une part et aux lignes commerciales d’autre part.

Ce document présente le format et les interfaces de publication (récupération en sortie des systèmes Île-de-France Mobilités) des données d’offre de transport en commun. Afin de proposer des exports relativement autoporteurs, certains formats proposés reprennent en propre des données issues du Référentiel Lignes et du Référentiel Arrêts.

Note : La gestion des données correspondances étant encore en cours d'élaboration, certains éléments seront précisés dans une prochaine version de ce document. 

Types de publications

La publication des fichiers depuis le BO s’effectuera par API (protocole RESTful). Les mécanismes sont détaillés dans le chapitre Interface de publication.

La publication des données permet de disposer au choix des données suivantes :

Export Offre IDF : Cet export contient l’offre théorique sur l’ensemble de la région Ile de France (toutes les lignes), mais pour une période de temps réduite.

Cette période sera fixée par Île-de-France Mobilités. Elle correspondra à la garantie d'exhaustivité et de qualité fixée dans les contrats (actuellement 3/4 semaines).

Une production quotidienne est prévue pour ce fichier. Cette période sera donc glissante et commencera le jour de la production de cet export par le BO Offre Théorique.

L'export contient aussi des fichiers reprenant les données des Référentiels..

Export par Ligne : Cet export contient l’offre théorique pour une ligne sur la plus grande période fournie par le transporteur responsable de celle-ci. 

Cette période reste limitée à une année maximum. Les périodes "passées" (antérieures à la date du jour) sont retirées lors de la production de chaque export, c'est-à-dire lors des mises à jour de l’offre de la ligne par le transporteur.

Contrairement à l'Export Offre IDF, cet Export ne contient qu'un fichier reprenant les données du Référentiel Lignes.

Règles et restrictions

Tableaux d’attributs

Les tableaux d’attributs dans les chapitres suivants précisent pour chaque objet NeTEx publié, la description et 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), la balise ne sera présente en publication que si la valeur est renseignée.

Règle d’exploitation des informations NeTEx 

Les couleurs utilisées dans les tableaux permettent de mettre en valeur les objets et attributs renseignés ou non lors de la publication par le BO Offre Théorique. 

Deux cas de figure sont possibles :

• Information (donnée ou objet) non publiée : l’information est citée et si nécessaire, une interprétation de son absence est proposée.

• Donnée ou objet publié : l’information est publiée ; toutefois, si elle est optionnelle, elle n’est présente que si elle est valorisée. Sauf mention contraire, les valeurs par défaut proposées par NeTEx ou le Profil seront toujours renseignées.

Delivery et Frames

Cadres de version ou frames

Les cadres de version sont de 2 types :

• GeneralFrame : Contient uniquement des objets métiers. La liste des objets présents dépend de l’attribut ‘TypeOfFrameRef’ du cadre et est définie par le Profil IDF

• CompositeFrame : Contient uniquement d’autres cadres de versions, la liste des cadres de version présents  dépend de l’attribut ‘TypeOfFrameRef’ du cadre et est définie par le Profil IDF.

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 ‘PublicationDelivery’.

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 publiés sont issus de ces héritages. Afin de simplifier la lecture des attributs relatifs à chaque objet intervenant dans la publication, les attributs issus d’un héritage ne sont rappelés seulement s’ils sont présents dans la publication de l’objet considéré.

Dans le cas de l’utilisation  d’un attribut hérité dans un objet publié, une nomenclature  est utilisée dans les tableaux d’attributs pour les repérer : le nom de l’attribut en question est précédé d’une abréviation entre parenthèses. Cette abréviation correspond au nom de l’objet qui fournit l’attribut en héritage. :

• (E) pour l’objet ENTITY

• (EIV) pour l’objet EntityInVersion

Entity (E)

Règle de syntaxe des identifiants :

Les identifiants des objets, autres que les arrêts, respectent la codification suivante : 

[CODESPACE]:[type d'objet]:[identifiant technique]:LOC

Avec :

[CODESPACE] : Indication sur le fournisseur de la donnée. Il prend la valeur du code organisation qui a produit (import ou saisie) la donnée. Dans le Back Office Offre, les objets résultant d'une fusion entre deux objets provenant d'organisations différentes (action automatique lors de l'agrégation) prennent un code propre au BO. 

Note : Les frames indiquent comme CODESPACE le code du BO qui les a produites.

[type d'objet] : Classe de l'objet sous la forme du nom du tag XML qui le porte

[identifiant technique] : Identifiant unique composé de caractères numériques, alphabétiques majuscules et minuscules sans accentuation, de ‘tiret’(-) et de ‘souligné’ (_). Pour les données importées dans le BO Offre, l'identifiant technique indiqué dans le fichier est préfixé par l'identifiant de la ligne issu du Référentiel Lignes (sauf pour les objets calendriers). En cas de fusion, l'identifiant de l'objet résultant correspond à celui de l'objet le plus récent (cf Différences entre les données importées/saisies dans le BO Offre et celles exportées).

LOC : permet de préciser que l'identifiant a été défini de façon locale entre les parties engagées dans l'échange, et qu'il ne fait donc pas partie du référentiel partagé (régional, national, etc.). L'utilisation de ce qualificatif est obligatoire quand l'identifiant est local (hors identifiants du Référentiel Arrêts ou du Référentiel Lignes).

EntityInVersion (EIV) hérite de Entity :

Si l'attribut hérité n'est pas obligatoire, il n'est pas rappelé dans les tableaux suivants.

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 le Référentiel Arrêts).

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="any" />

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

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

Avec : 

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

Exemple :

Référence au sein d'un fichier offre_[ID Ligne C]_[Nom Ligne C].xml :

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

Référence d'un fichier offre_[ID Ligne C]_[Nom Ligne C].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 (ou ligne(s).xml) ou dans le Référentiel Arrêts (ou arrets.xml) : 

<LineRef ref="FR1:Line:[ID LIGNE C]:">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 LIGNE C] : 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

Organisation des publications

FICHIERS OFFRE : Les exports Offre sont au format NETEX et se présentent sous la forme d’un ensemble de fichiers réunis au sein d’une archive ZIP.

Export Offre IDF : 

Open

Où :

[AAAAMMJJ_AAAAMMJJ] : dates de début et de fin de la période de publication (dates inclues)

[ID Transporteur]_[Nom Transporteur] : identifiant et nom du transporteur principal de la ligne, indiqué dans le Référentiel Lignes.

[ID Ligne C]_[Nom Ligne C] : identifiant et nom court de la ligne commerciale, issu du Référentiel Lignes.

Le regroupement par transporteur principal et non par organisation, permet, si l'offre est transmise dans le Back Office Offre par deux organisations différentes, d'obtenir les deux offres agrégées dans un même fichier en publication.

Note : Ce cas de deux fournisseurs doit rester exceptionnel. En effet, pour les lignes en pool par exemple, un seul fournisseur pour l'offre théorique sera désigné (principe identique au fonctionnement actuel). 

Ce système permettra notamment de gérer les changements d'exploitant pour une ligne à une date t. 

Export Offre Ligne :

Open

Où :

[AAAAMMJJThhmmsZs] : date de production du fichier d'export (=date et heure UTC de dernière mise à jour de l'offre pour la ligne)

[ID Ligne C]_[Nom Ligne C] : identifiant et nom court de la ligne commercial, issu du Référentiel Lignes.

Note : Pour les deux types d'export, les noms extraits du Référentiel Lignes sont transformés si nécessaire pour ne contenir que des caractères valides comme nom de fichier et de dossier, les caractères autres que : 

• les lettres alphabétiques latines majuscules et minuscules non diacritiques,

•  les chiffres,

•  le ‘tiret’ et le ‘souligné’ 

sont remplacés par des ‘souligné’.

Contenu des publications

Chaque fichier xml contient des données relatives à un ou plusieurs cadres de version :

• commun.xml : Contient les objets du cadre de version NETEX_COMMUN. Ce fichier est optionnel ; il n’est présent que si la ligne ou au moins une ligne du transporteur contient des notes sur ses courses (NOTICE au sens NeTEx).

• calendriers.xml : Contient les objets du cadre de version NETEX_CALENDRIER. Il définit la validité de l'export (ValidBetween) et le calendrier d'application des courses (stockées dans le fichier offre_[ID Ligne C]_[Nom Ligne C].xml)

• offre_[ID Ligne C]_[Nom Ligne C].xml : Chaque fichier contient les données d’offre pour une ligne réparties dans les cadres de version NETEX_STRUCTURE et NETEX_HORAIRE. Ceux-ci sont regroupés au sein d’un cadre de version de type NETEX_OFFRE_LIGNE. 

• ligne(s).xml : Contient la définition des lignes, des réseaux et transporteurs selon le format de publication du Référentiel Lignes. Pour l'export complet, l’ensemble des objets du Référentiel Lignes actifs, ou connus du BO Offre, est publié. Pour l'export par ligne, seule la ligne concernée est décrite.

• arrets.xml : Contient la définition des "arrêts" selon le format de publication du Référentiel Arrêts. L’ensemble des objets du Référentiel Arrêts déclarés actifs ou encore référencés par une offre est publié.

 Ce fichier est publié uniquement dans l'Export Offre IDF. 

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. Les schémas suivant présentent les objets publiés par BO Offre Théorique.

Les objets représentés sont regroupés dans des cadres de version (ou ‘Frames’) qui servent de conteneurs pour transporter les objets. 

Chaque cadre de version est identifié par une couleur distincte : 

• NETEX_LIGNE (raccourci de FR1:TypeOfFrame:NETEX_OFFRE_LIGNE:)

• NETEX_STRUCTURE (raccourci de FR1:TypeOfFrame:NETEX_STRUCTURE:)

• NETEX_HORAIRE (raccourci de FR1:TypeOfFrame:NETEX_HORAIRE:)

• NETEX_CALENDRIER (raccourci de FR1:TypeOfFrame:NETEX_CALENDRIER:)

• NETEX_COMMUN (raccourci de FR1:TypeOfFrame:NETEX_COMMUN:) 

Pour les données Référentiel Ligne et Référentiel Arrêts, seuls les cadres de versions sont indiqués dans la suite de ce document. Leur contenu sera similaire aux sorties des web-services des Référentiels. Cela concerne les cadres suivants : 

• NETEX_ARRET_IDF (raccourci de FR1:TypeOfFrame:NETEX_ARRET_IDF:) 

• NETEX_IDF (raccourci de FR1:TypeOfFrame:NETEX_IDF:)

Données NeTEx publiées

Les données caractérisant les cadres de version de chaque fichier (illustrés en vert et en orange dans les schémas Contenu des publications) sont précisées dans les chapitres suivants.

Données d’offre

Les frames suivantes sont publiées aussi bien pour l’offre complète que pour une offre par ligne. 

Fichier commun.xml

Organisation et hiérarchie du cadre de version

Dans celui-ci ne seront traités que des objets de type ‘NOTICE’ et ‘ORGANISATIONAL_UNIT’. 

Seules les notes portant sur les courses sont inclues dans le fichier commun.xml (notes produites dans le BO Offre Théorique). Les notes portant sur une ligne entière (produites depuis les IHM du Référentiel Ligne) sont dans le cadre NETEX_COMMUN du fichier ligne(s).xml

Description de la General Frame :  NETEX_COMMUN

Objet : NOTICE (Note) : Un texte à vocation informationnelle, en général concernant des exceptions d'utilisation, et rattaché dans le cadre du fichier commun.xml à SERVICE JOURNEY (Courses)

Exemple de restitution de l’objet "NOTICE" au niveau d’un média IV (fiche horaire) :

La référence à la note ("NoticeAssignement") se trouve au niveau de l'objet SERVICE JOURNEY (Course), présent dans le(s) fichier(s) offre_[ID Ligne C]_[Nom Ligne C].xml publiés dans le même dossier. 

Objet : ORGANISATIONAL_UNIT (Unité organisationnelle) : Entité productrice de données, son identifiant correspond aux références DatasourceRef des objets publiés

Fichier calendriers.xml

Organisation et hiérarchie du cadre de version :

Dans celui-ci ne seront traités que des objets de type ‘DAY TYPE’, ‘OPERATING PERIOD’ et ‘DAY TYPE ASSIGNMENT’.

La relation entre les objets est la suivante :

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 d'un Import Offre avec ses dépendances est donc transformé en un objet nommé ‘Calendrier’.

Description de la General Frame :  NETEX_CALENDRIER

La Frame NETEX_CALENDRIER indique la Période de Validité (ValidBetween) globale des données publiées dans l'Export Offre. 

• Export Offre IDF : La Période de Validité  se limite à un intervalle fixé par Île-de-France Mobilités et commençant le jour de la publication. 

• Export Ligne Offre : La Période de Validité  peut se composer de plusieurs intervalles selon la disponibilité des données au jour de la publication. 

Les calendriers publiés peuvent déborder de ces périodes mais l’offre n’est garantie complète que sur les intervalles de validité publiés. Un calendrier intégralement hors intervalle de publication ne sera pas publié.

Objets publiés 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

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.

En combinant ces 3 objets, il est possible de modéliser les calendriers de différentes façons.

Exemple : Courses circulant du 1 juillet au 31 juillet, tous les jours sauf les dimanches et le 14 juillet :

Note : Dans les fichiers publiés, un calendrier (DAYTYPE) ne peut être entièrement une "exception" (que des dates avec IsAvailable=False). Si un tel calendrier est fourni en entrée du BO Offre, alors le système combine ce calendrier "exceptions" avec un autre calendrier pour n'en produire qu'un seul.

Fichier offre_[ID Ligne C]_[Nom Ligne C].xml

Organisation et hiérarchie du cadre de version

Chaque fichier offre_[ID Ligne C]_[Nom Ligne C].xml contient les informations permettant de décrire l' "offre" pour une ligne commerciale (un fichier .xml par ligne).

Il contient une Frame Composite "NETEX_OFFRE_LIGNE", qui indique dans son identifiant le code de la ligne commerciale issu du Référentiel Lignes. 

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

Description de la Composite Frame : NETEX_OFFRE_LIGNE

Fichier offre_[ID Ligne C]_[Nom Ligne C].xml vide :

Si la Frame NETEX_OFFRE_LIGNE 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é publiée (période définie dans la frame NETEX_CALENDRIER). 

Cadre de version ‘NETEX_STRUCTURE’

Organisation et hiérarchie du cadre de version :

NETEX_STRUCTURE ne contient que des objets relatifs à l’aspect topologie d'une ligne. 

Les deux objets centraux sont : 

• La ROUTE (Itinéraire) : Premier niveau de subdivision de la ligne commerciale. Il correspond à une suite ordonnée de points définissant un seul chemin à travers le réseau routier (ou ferré). Il est orienté : la suite de ces mêmes points ordonnée dans le sens contraire constitue un autre itinéraire.

• Le SERVICE JOURNEY PATTERN (Mission Commerciale) : il décrit la façon dont "circulent" les véhicules : tous les points d'une mission (STOP POINT IN JOURNEY PATTERN) sont desservis. Une mission est associée à un unique itinéraire.

Dans le format défini pour le BO Offre Théorique, les points sur mission ne peuvent être associés qu'à des points de montée ou de descente des passagers dans le véhicule, c'est à dire qu'à des SCHEDULED STOP POINT (Points d'arrêts planifiés) et non à des points de passage, de régulation, etc.

L'affectation de ces points d'arrêts planifiés à une description physique se fait au travers de l'objet PASSENGER STOP ASSIGNMENT. Seule l'affectation à un ZDEP (référence à l'objet arrêt le plus fin dans le Référentiel Arrêts) est définie ici.  

Enfin, la Frame peut aussi contenir l'objet ROUTING CONSTRAINT ZONE (Zone de contrainte), qui peut permettre de décrire des ITL.

Description de la General Frame : NETEX_STRUCTURE

Objets pris en compte par le BO Offre Théorique :

• Objets liés à la définition d'une ROUTE (itinéraire)

ROUTE (Itinéraire) : Une 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

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

• Objets liés à la définition d'un tracé d'itinéraire

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

• Objets liés à la définition d'un SERVICE JOURNEY PATTERN (Mission commerciale)

Un même itinéraire peut être utilisé par de nombreuses missions commerciales (soit qu'elle l'utilise complètement ("omnibus"),  partiellement (ex : mission "express"), soit qu'elle fasse varier la liste des arrêts effectivement desservis. 

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

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.

• Objets permettant le lien vers les ZDEP du Référentiel Arrêts

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

Note : l’identifiant technique de cet objet sera composé de l’identifiant technique de la ZDEp desservie suivi du numéro d’ordre de passage dans l’itinéraire (format : [ID_ZDEp]-[order]) 

PASSENGER STOP ASSIGNMENT : Permet d'associer un point "horaire" : SCHEDULED STOP POINT (Point d'Arrêt Planifié), à un point "physique" : il s’agit ici de la référence à une  ZDEP connue du Référentiel Arrêts.

• Objets liés à la définition des ITL :

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.

Cadre de version ‘NETEX_HORAIRE’

Organisation  et hiérarchie du cadre de version :

Dans celui-ci ne seront publiés que des objets relatifs à l’aspect horaires des objets d’une ligne.

L'objet principal est le SERVICE JOURNEY (Course) qui liste des horaires: TIMETABLED PASSING TIME. L'objet NOTICE ASSIGNMENT permet également d'affecter des notes contenues dans le fichier commun.xml à des Courses.

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.

Description de la Frame : 

General Frame : NETEX_HORAIRE :

Objets publiés 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.

Fichier ligne(s).xml

Note : Le Référentiel Lignes propose déjà une sortie Web-services actuellement. Celle-ci va évoluer dans le cadre du projet de Refonte Back Office. Le document DINT-LIGNE_publication_1.7.2.docx décrit ces évolutions (nouveaux objets et nouvelle structuration). 

Le cadre de version NETEX_IDF est définit par les attributs :

Les frames présentes dans ce fichier, dans le cadre de version NETEX_IDF, correspondront à la structuration du web-service Référentiel Lignes (version évoluée). Elles ne sont pas décrites dans ce document.

Fichier arrets.xml

Note : Le Référentiel Arrêts propose déjà une sortie Web-services actuellement. Celle-ci va évoluer dans le cadre du projet de Refonte Back Office. Le document présentant cette nouvelle version des web-services Référentiel Arrêts est en cours de rédaction.

Le cadre de version NETEX _IDF est définit par les attributs :

Les frames présentes dans ce fichier, dans le cadre de version NETEX_IDF,  correspondront à la structuration qui sera reprise dans l'évolution des web-services du Référentiel Arrêts (version évoluée). Elles ne sont pas décrites dans ce document.

Les entités restituées sont celles déclarées actives. A la marge, des entités inactives encore référencées dans les données d'offre peuvent aussi être indiquées dans ce fichier. Toutefois des contrôles seront mis en place dans le Référentiel Arrêts pour ne permettre la désactivation d'un arrêt (ZDEP) que si celui-ci n'est plus référencé dans l'offre publié. Cela permettra de limiter ce genre de cas.

Annexes 

Workflow du Back Office Offre Théorique

Le BO Offre Théorique a vocation à assembler les données d’offre théorique provenant de plusieurs sources. Lors des processus de traitement des données entre leur arrivée dans le BO Offre (par import ou par création directe) et leur publication, le système est amené à réaliser certaines modifications :

1 - Les données entrent dans le BO Offre (import ou saisie directe dans le système) :

Chaque organisation dispose d'un espace de travail propre, où chacun de ses utilisateurs peut gérer (importer, saisir, modifier, valider) des "fragments d'offre", aussi appelés "jeux de données". Chaque jeu de données porte sur un périmètre de lignes et une période de validité (temps) donné. Un import d'un fichier dans le BO Offre va produire un nouveau jeu de données dans l'espace de travail. 

2- Les données sont consolidées pour une organisation : constitution d'une offre complète pour une organisation

Quand il est prêt, l'utilisateur peut pousser un jeu de données dans son "Offre Consolidée". Cela signifie que l'offre du jeu de données va alors être insérée, par rapport à son périmètre de ligne et sa période de validité, dans une seule et même "base" pour l'organisation. Celle-ci comprend alors l'ensemble de l'offre pour toutes les lignes de l'organisation sur une temporalité qui peut être composite. Elle n'est que consultable et ne peut être modifiée qu'en poussant un nouveau jeu de données dans celle-ci.

3- Les données sont agrégées pour toutes les organisations : constitution de l'Offre IDF

Toutes les nuits, un automate agrège dans une seule et même base les offres consolidées de chaque organisation. Puis il va produire à partir de cet ensemble des fichiers pour la publication.   

Note : Il est prévu également un sytème de publication "urgente" où certains utilisateurs habilités pourront demander une publication "immédiate" (dans la journée).

Différences entre les données importées/saisies dans le BO Offre et celles exportées

Fichier -> Jeu de données

Les données affichées dans l'espace de travail (au sein d'un jeu de données) sont très peu transformées par rapport à la description de l'offre faite dans les fichiers importés ( cf document d ‘import pour plus de détail) .

Toute donnée créée par import est associée à un DataSourceRef correspondant à l’organisation ayant réalisé l’import. Toute donnée créée ou modifiée interactivement dans le BO Offre (via ses IHM) est associée à un DataSourceRef « FR1-OFFRE_EDITION».

Jeu de données -> Agrégat Organisation

Avant d'être insérés, les calendriers inclus dans le jeu de données poussé dans l'agrégat sont réduits à la période de validité de celui-ci.

Lors l'insertion, le système regarde si des données "identiques", c'est à dire portant les mêmes caractéristiques, existent déjà dans l'offre agrégée. Si c'est le cas, il les fusionne :

• Les itinéraires d’une même ligne partageant les mêmes attributs et les mêmes arrêts sont regroupés au sein d’un seul ; celui-ci est alors réidentifié.

• Les missions d’un même itinéraire partageant les mêmes attributs et les mêmes arrêts desservis sont regroupées au sein d’une seule ; celle-ci est alors réidentifiée.

• Les courses d’une même mission partageant les mêmes attributs et les mêmes horaires sont regroupées au sein d’une seule ; celle-ci est alors réidentifiée. 

• Les calendriers correspondants à la même liste de dates de circulation sont regroupés au sein d’un seul, celui-ci est alors réidentifié.

Ce système permet d'aboutir à une offre agrégée plus compacte.

Note : Il a été choisi d'utiliser des critères fonctionnels plutôt que les identifiants des objets pour décider de la fusion des objets, car tous les partenaires ne gèrent pas de référentiel propre pour ses objets offre. Cela induit par contre que, dans certains cas, la traçabilité des identifiants entre les données importées dans le BO Île-de-France Mobilités et les données récupérées en sortie ne sera pas garantie.

Agrégat Organisation -> Agrégat IDF

Lors de l'agrégation des différents Offre Organisation Consolidée,  le système va également regarder si des données "identiques", c'est à dire portant les mêmes caractéristiques, existent entre les organisations. Si c'est le cas, il les fusionne. Ces nouvelles données crées sont alors réidentifiée et associée à un DataSourceRef « FR1-OFFRE_AUTO».

En règle générale, une ligne étant affectée à une seule et même organisation, ces fusions seront limitées principalement aux objets calendriers.