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 :