Table of Contents

Glossaire

Note : La réalisation du nouveau système Back Office étant en cours, merci de noter que la terminologie utilisée dans ce document pour décrire les applications, les différentes étapes du workflow ou les productions/fichiers, n'est pas définitive.

APPLICATIONS :

...

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 et Transporteurs) aux applications Île-de-France Mobilités de gestion des données "transport" (notamment de type Back Office SIM).

Référentiel Arrêts : Système permettant la collecte et la gestion des données arrêts, groupe d'arrêts et accès pour l'Île-de-France. Application actuellement nommée REFLEX, demain ICAR. ICAR comportera la gestion des correspondances.

Référentiel Lignes : Système permettant la collecte et la gestion des données de description des lignes (comprenant aussi les concepts liés à la ligne : transporteurs, réseaux, modes, etc.) pour l'Île-de-France. Application anciennement nommée CODIFLIGNE, désormais ILICO.

Back Office Offre Théorique (IBOO) : Système permettant la collecte et la gestion des données d'offre théorique pour l'Île-de-France.

Back Office SIM : Ensemble des applications : Référentiel Arrêts, Référentiel Lignes, Back Office Offre Théorique.

DUALE : Base de donnée au cœur du système actuel de collecte des données d' "offre théorique". Elle concentre l'ensemble des données arrêts, lignes, offre et correspondances d'Île-de-France, et permet l'alimentation des front office d'Île-de-France Mobilités et de ses partenaires. Sera remplacée à terme par le nouveau Back Office SIM.

Note : Le terme "Back Office" est fréquemment abrégé "BO" dans la suite de ce document

FICHIERS :

Fichiers d'import : Fichiers acceptés pour l'alimentation des Back Office Île-de-France Mobilités (au format NETEX)

Fichiers publiés : Fichiers produits en sortie des Back Office Île-de-France Mobilités (en général au format NETEX)

Import Offre : Type de jeu de fichiers accepté en entrée du Back Office Offre. Les fichiers qu'il contient sont au format NETEX. Le jeu décrit les données d'offre pour un ensemble cohérent : pour une liste de lignes et sur une période donnée.

Export Offre IDF : Type de jeu de fichiers publié par le Back Office Offre. Les fichiers qu'il contient sont au format NETEX. Le jeu décrit l'offre théorique pour toutes les lignes de transport d'Île-de-France sur une période limitée.

Export Ligne Offre : Type de jeu de fichiers publié par le Back Office Offre. Les fichiers qu'il contient sont au format NETEX. Le jeu décrit l'offre théorique pour une seule ligne de transport sur toute la période fournie par le transporteur référent.

Export Correspondances : Fichier au format NETEX. Il contient toutes les correspondances entre les "arrêts" d'Île-de-France. (format non défini pour l’instant)

Organisation : Entité d'appartenance pour les utilisateurs listés dans le Portail. Concept utilisé pour définir sur un périmètre fonctionnel les droits dans les systèmes Back Office Île-de-France Mobilités. Il correspond en général à un groupe de transporteur, transporteur, "réseau" transporteur, etc.

SOUS-ENSEMBLES BACK OFFICE OFFRE :

Espace de travail : Espace propre à chaque organisation permettant d'importer/modifier/gérer des données d'offre théorique.

Jeu de données : Au sein de l'espace de travail, unité cohérente définie par un périmètre de ligne et une période de validité ; elle correspond à un "fragment d'offre". Un "Import Offre" alimenté dans le Back Office Offre produit un jeu de données.

Offre Consolidée Organisation : Ensemble existant pour chaque organisation et comprenant l'ensemble des données d'offre théorique pour celle-ci. Elle est produite à partir de la consolidation des jeux de données poussés par le transporteur.

Offre Agrégée IDF : Ensemble unique comprenant l'offre théorique pour toutes les lignes d'Ile de France. Elle est produite à partir de l'agrégation de toutes les Offre Consolidée Organisation.

WORKFLOW BACK OFFICE OFFRE :

Importation Offre : Alimentation d'un ou plusieurs Import Offre dans l'Espace de Travail. Chaque "Import Offre" produit un jeu de données.

Consolidation Offre : Dans le Back Office Offre, mise à jour d'une Offre Consolidée Organisation avec l'insertion d'un ou plusieurs jeux de données poussés par un utilisateur.

Agrégation Offre : Dans le Back Office Offre, mise à jour de l'Offre Agrégée IDF à partir des Offre Consolidée Organisation qui ont été mises à jour.

Publication : Production des "Exports" depuis l'Offre agrégée IDF.

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 correspondances d’une part, et aux lignes commerciales d’autre part.

Ce document présente le format et les interfaces d’import des données d’offre de transport en commun dans le sous-système BO Offre Théorique Ces systèmes seront mis à disposition des transporteurs sous contrat avec Île-de-France Mobilités.

Pour rappel, le BO Offre Théorique permettra également de saisir directement son offre dans l'interface web 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 correspondances d’une part, et aux lignes commerciales d’autre part.

Ce document présente le format et les interfaces d’import des données d’offre de transport en commun dans le sous-système BO Offre Théorique Ces systèmes seront mis à disposition des transporteurs sous contrat avec Île-de-France Mobilités.

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 B 3 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ù :

1.04 : version xsd NETEX
2.0 : version du profil Ile de France NETEX (général) utilisé pour l'ouverture du Back Office IV
z : version du système fournisseur du transporteur (optionnel et ignoré à l’import). Constitués de chiffres et de "." uniquement.

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

, “.”, “:”, “-”

PublicationRequest

structure

0:1

Non exploité

PublicationRefresh Interval

xsd:duration

0:1

Non exploité

Description

xsd:normalizedString

0:1

Non exploité

, “.”, “:”, “-”

dataObjects

dataObjects_

RelStructure

0:1

1:1

CompositeFrame de type :

FR1:TypeOfFrame:NETEX_OFFRE_LIGNE:

ou GeneralFrame de type :

FR1:TypeOfFrame:NETEX_COMMUN:
FR1:TypeOfFrame:NETEX_CALENDRIER:
FR1:TypeOfFrame:NETEX_STRUCTURE:
FR1:TypeOfFrame:NETEX_HORAIRE:

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 :

...

[identifiant Technique] : identifiant interne unique composé de caractères ‘0-9’, ‘A-Z’, ‘a-z’, ‘-‘ et ‘ _’. Les caractères accentués (‘é’, ‘ô’, …) et les autres caractères spéciaux (‘ç’, …) sont à remplacer systématiquement par ‘_’.

Note : Île-de-France Mobilités préconise de privilégier l'utilisation de caractères numériques ou simples (par exemple : "-")

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

EntityInVersion (EIV) hérite de Entity :

...

Donnée

...

Type

...

Cardinalité BO OT

...

Description et traitement BO Offre Théorique

...

dataSourceRef

...

DataSourceId

Type

...

0:1

...

Identifiant de la source des données.

Non exploité, car renseigné automatiquement par le BO IV en fonction de l'organisation du compte utilisateur utilisé pour réaliser l’action d’import.

...

created

...

xsd:dateTime

...

0:1

...

Date et heure de création de l'entité.

Non exploité

...

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)

...

modification

...

Modification

Enum

...

0:1

Nature de la dernière modification:

new (création)

revise (mise à jour)

delete (suppression)

Pour le BO Offre Théorique :

Si l'attribut est renseigné, seuls 'new' et 'revise' sont acceptés (sans distinction). L'indication 'delete' est exclue (provoque un rejet du fichier/objet).

Pour supprimer un objet, il suffit d'importer un nouveau jeu de données (sur le même périmètre que le jeu précédent) ne contenant pas cet objet.

...

. Les caractères accentués (‘é’, ‘ô’, …) et les autres caractères spéciaux (‘ç’, …) sont à remplacer systématiquement par ‘_’.

Note : Île-de-France Mobilités préconise de privilégier l'utilisation de caractères numériques ou simples (par exemple : "-")

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

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

.

status

VersionStatus

Enum

0:1

Statut de la version:

active (objet actif)
inactive (objet non actif)

Seuls les objets indiqués 'active' ou dont le status n'est pas renseigné sont importés.

Les objets 'inactive' ne sont pas pris en compte

.

compatibleWith VersionRef

VersionIdType

0:1

Non exploité

derivedFrom ObjectRef

ObjectIdType

0:1

Non exploité

validityConditions

ValidityCondition

0:*

Exclu, voir ValidBetween

ValidBetween

ValidBetween

Structure

0:*

Périodes de validité de l’objet.
Exploité uniquement dans le cadre de l'import Offre Théorique, au niveau de la GeneralFrame NETEX_CALENDRIER.

Si l'attribut hérité n'est pas obligatoire, il n'est pas rappelé dans les tableaux du chapitre B- 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) :

Code Block
<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)

Code Block
<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 :

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

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

Code Block
<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) :

Code Block
<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 :

...

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

Les objets présentés en gris 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

Donnée

Type

Cardinalité BO OT

Description et traitement BO Offre Théorique

(E) id

ObjectIdType

1:1

Non exploité, mais obligatoire
Préconisation : [CODESPACE]: GeneralFrame:NETEX_COMMUN-AAAAMMJJhhmmssZ:LOC , avec AAAAMMJJhhmmssZ : heure de génération fichier (heure universelle)

(EIV) version

VersionIdType

1:1

Non exploité, mais obligatoire

Préconisation : 'any'

Name

MultilingualString

0:1

Non exploité

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>

VersionRef

VersionRef

0:1

Non exploité

codespaces

Version

0:*

Non exploité

FrameDefaults

FrameDefaults

0:*

Non exploité

contentValidityConditions

ValidityCondition

0:*

Exclu

ValidBetween

ValidBetween

Structure

0:*

Exclu. La période de validité est définie dans la frame NETEX_CALENDRIER


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’

Name

MultilingualString

0:1

Non exploité

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

*

variants

DeliveryVariant

0:

*

Non exploité

*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
Préconisation : [CODESPACE]: GeneralFrame:NETEX_CALENDRIER-AAAAMMJJhhmmssZ:LOC , avec AAAAMMJJhhmmssZ = heure de génération fichier (heure universelle)

(EIV) version

VersionIdType

1:1

Non exploité, mais obligatoire.

Préconisation :’any’

Name

MultilingualString

0:1

Non exploité

ValidBetween

ValidBetween

Structure

0:*

1 :*

Définit la ou les périodes de validité du jeu de données
Les périodes ne doivent pas se chevaucher*

Format (exemple) :

<ValidBetween>

<From Date>2017-06-25T00:00:00</FromDate><ToDate>2017-12-31T00:00:00</ToDate>

</ValidBetween>

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>

VersionRef

VersionRef

0:1

Non exploité

codespaces

Version

0:*

Non exploité

FrameDefaults

FrameDefaults

0:*

Non exploité

contentValidityConditions

ValidityCondition

0:*

Exclu


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.

Description

MultilingualString

0:1

Non exploité

EarliestTime

xsd:time

0:1

Non exploité

DayLength

xsd:duration

0:1

Non exploité

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.

Dans le cas où

Si les DayTypeAssignment référencent uniquement des

’Date’

’Date’, la liste

peut être vide ; elle peut aussi être renseignée avec d'autres types non exploités par le BO OFFRE (par exemple 'NationalHoliday' =jour férié)

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

alors

que sur les périodes, pas sur les dates

.

timebands

structure

0:*

Non exploité

.

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

ServiceCalendarRef

CalendarRef

0:1

Non exploité

OperatingPeriodRef

OperatingPeriod

Ref

0:1

Référence interne à une OPERATING PERIOD

OperatingDayRef

OperatingDayRef

0:1

Exclu, voir Date ci-dessous


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’ L’emploi de ce booléen est autorisé uniquement pour les assignements sur des dates et non sur périodes.

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’

ServiceCalendarRef

0:1

Non exploité

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’

(EIV) modification

Modification0:

Enum

1

Nature de la dernière modification:

delete (suppression)
Note : A n’utiliser que pour un fichier offre "vide"

Name

MultilingualString

0:1

Non exploité.

Préconisation : Renseigner cet attribut avec le nom de la ligne pour la lisibilité du fichier (dans le cas du debug). Attention, celui-ci ne sera pas pris en compte car le nom de la ligne doit être saisi et stocké dans le Référentiel Lignes.

: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>

VersionRef

0:1

Non exploité

codespaces

Version

0:*

Non exploité

FrameDefaults

FrameDefaults

0:*

Non exploité

contentValidity

Conditions

ValidityCondition

0:*

Exclu

ValidBetween

ValidBetweenStructure

0:*

Exclu

frames

Frame

0:*

Liste des frames de la frame composite

Exploité : contient dans l’ordre les 2 GeneralFrames :

NETEX_STRUCTURE
NETEX_HORAIRE

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

...

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 èzqpoints points d'arrêts planifiés à une description physique se fait au travers de l'objet PASSENGER STOP ASSIGNMENT. L’import NeTEx IDFM supporte deux syntaxes pour associer un PassengerStopAssignmentà un arrêt:

L’une avec la balise QuayRef:

<QuayRef ref="FR::Quay:50111663:FR1">version="any"</QuayRef>

</PassengerStopAssignment>

L’autre avec StopPlaceRef:

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

...

Pour une mission, les numéros d'ordre indiqués sur les STOP POINT IN JOURNEY PATTERN peuvent donc être discontinus car ils doivent correspondre à l'ordre sur l'itinéraire global.

Note : si lors dans un jeu de données, un arrêt n’est présent dans aucune des missions importées, alors l’itinéraire résultant ne sera pas le même que pour un jeu de données où une mission dessert cet arrêt.

...

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’

Name

MultilingualString

0:1

Non exploité

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>

VersionRef

VersionRef

0:1

Non exploité

codespaces

Version

0:*

Non exploité

FrameDefaults

FrameDefaults

0:*

Non exploité

ContentValidity

Conditions

ValidityCondition

0:*

Exclu

ValidBetween

ValidBetweenStructure

0:*

Exclu, la période de validité est définie dans la frame NETEX_CALENDRIER

">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

BO Offre Théorique, mais non utilisé pour l'information voyageur Ile-de-France Mobilités

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 à

la concaténation des chaînes DirectionType et le nom du dernier arrêt de l’itinéraire.

Distance

DistanceType

0:1

Non exploité

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

1:*

0:*

Liste des points de l'ITINÉRAIRE.

Non exploité

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.

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

...

‘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..".

DirectionType

TypeOfDirectionEnum

0:1

Exclu : pourrait être en conflit avec la définition de la Route

OppositeDirectionRef

DirectionRef

0:1

Exclu : pourrait être en conflit avec la définition de la Route

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.

Distance

DistanceType

0:1

Non exploité

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

ServiceJourneyPatternType

PatternType

ServiceJourneyPattern

TypeEnumeration

0:1

1:1

Type de Mission Commerciale

Seul le type «

Passenger

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’

SideText

MultilingualString

0:1

Non exploité

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.
Dans un certain nombre de cas l'AFFICHAGE DE DESTINATION n'est pas un texte mais un code (par exemple pour les RER et avec des codes comme PADO, DEFI ou encore PORO).

variants

DeliveryDisplayVariant

0:*

Non exploité

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

.

LinkSequenceRef

MultilingualString

0:1

Non exploité

.

StopPointInJourneyPattern est inclus dans la LinkSequence ServiceJourneyPattern


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)

*

DestinationDisplayRef

DestinationDisplayRef

0:1

Non exploité

FlexiblePointProperties

FlexiblePointProperties

0:1

Non exploité

ChangeOfDestination

Display

xsd:boolean

0:1

Non exploité

noticeAssignments

NoticeAssignmentView

0:*

Non exploité

RequestStop

xsd:boolean

0:1

Non exploité

StopUse

StopUseEnumeration

0:1

Non exploité

...

*

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’

Name

MultilingualString

0:1

Non exploité

Location

Location

0:1

Non exploité

PointNumber

xsd:normalizedString

0:1

Non exploité

TimingPointStatus

TimingPointStatus

Enumeration

0:1

Non exploité

AllowedForWaitTime

xsd:duration

0:1

Non exploité

tarrifZones

TariffZoneRef

0:*

Non exploité

ShortName

MultilingualString

0:1

Non exploité

Description

MultilingualString

0:1

Non exploité

PublicCode

xsd:normalizedString

0:1

Non exploité

PrivateCode

xsd:normalizedString

0:1

Non exploité

StopType

StopPlaceTypeEnum

0:1

Non exploité

Presentation

PresentationStructure

0:1

Non exploité

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

trainElements

TrainStopAssignment

0:*

Non exploité

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

ShortName

MultilingualString

0:1

Non exploité

Description

MultilingualString

0:1

Non exploité

PurposeOfGroupingRef

PurposeOfGroupingRef

0:1

Non exploité

PrivateCode

PrivateCode

0:1

Non exploité


(members)	Spécifié dans RoutingConstraintZone

0:1

1:1

Liste des arrêts planifiés: Contient les ScheduledStopPointRef concernés par l’ITL

Centroid

Point

0:1

Non exploité

Gml:Polygon

gml:Polygon

0:

1

Non exploité

ZoneUse

ZoneUseTypeEnum

0:1

Contrainte appliquée à la ZONE

Seule la valeur cannotBoardAndAlightInSameZone est acceptée

lines

lineRefs

0:*

Non exploité

L’objet Routing Constraint Zone sera toujours rapporté à une seule ligne. Pas la peine donc de repréciser la ligne concernée.

GroupOfLinesRef

GroupOfLinesRef

0:1

Non exploité

: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 LINKROUTE POINT
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.

<Name>VehicleJourneyStopAssignment example</Name>

</ServiceJourney>

<QuayRef ref="FR::Quay:5001111:FR1">version="any"</QuayRef>

</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'

Name

MultilingualString

0:1

Non exploité

Préconisation :

<TypeOfFrameRef ref="FR1:TypeOfFrame:NETEX_HORAIRE:">version="1.04:FR1-

TypeOfFrameRef

TypeOfFrameRef

0:1

1:1

Référence au TYPE OF VERSION FRAME utilisé.

Doit être

NETEX_HORAIRE

-2.1"</TypeOfFrameRef>

VersionRef

VersionRef

0:1

Non exploité

codespaces

Version

0:*

Non exploité

FrameDefaults

FrameDefaults

0:*

Non exploité

contentValidity

Conditions

ValidityCondition

0:*

Exclu

ValidBetween

ValidBetweenStructure

0:*

Exclu, la période de validité est définie dans la frame NETEX_CALENDRIER

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

Distance

DistanceType

0:1

Non exploité

Description

MultilingualString

0:1

Non exploité

TransportMode

VehicleModeEnum

0:1

Mode de transport de la course.

Non exploité. Toutes les courses ont le même mode que la ligne commerciale (défini dans le Référentiel Lignes). Les lignes de substitution sont des lignes commerciales à part entière.

TransportSubmode

TransportSubmode


(EIV) version	VersionIdType	1:1	Version unique ou ’any’
Name	MultilingualString	0:1

Sous-mode

Nom de

transport de

la course

. Non exploité. Toutes les courses ont le même sous-mode que la ligne commerciale (défini dans le Référentiel Lignes)

Ce nom à usage technique n’a pas à être diffusé aux voyageurs

noticeAssignments

noticeAssignments

0:*

NOTEs associées à la COURSE

Voir tableau ci-dessous

DepartureTime

xsd:time

0:1

Non exploité

JourneyDuration

xsd:duration

0:1

Non exploité

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)

VehicleTypeRef

VehicleTypeRef

0:1

Non exploité

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.

LineRef

LineRef

0:1

Non exploité. La référence à la ligne est faite uniquement au niveau de la ROUTE (Itinéraire)

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

passingTimes

TimetabledPassingTime

0:*

2:*

Heures de passages planifiées aux arrêts. Voir tableau ci-après

parts

journeyParts

0:*

Non exploité

TrainSize

TrainSizeStructure

0:1

Non exploité

FlexibleService

Properties

FlexibleService

Properties

0:1

Non exploité

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)

NoticedObjectRef

VersionOfObjectRef

0:1

Exclu, l’objet étant inclus dans la 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)

Donnée	Type	Cardinalité BO OT	Description et traitement BO Offre Théorique
(EIV) version	VersionIdType	1:1	Non exploité. Préconisation : ‘any’

PointInJourneyPatternRef

PointInLink SequenceRef

0:1

Exclu : l’ordre des horaires dans la course doit être identique à celui des arrêts de la mission (StopPointInJourneyPattern)


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.

Headway

HeadwayInterval

0:1

Non exploité

EarliestDepartureTime

xsd:time

0:1

Non exploité

LatestArrivalTime

xsd:time

0:1

Non exploité

*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

...

Page Comparison

Versions Compared

Old Version 9

New Version Current

Key

Glossaire

APPLICATIONS :

Introduction

FICHIERS :

SOUS-ENSEMBLES BACK OFFICE OFFRE :

WORKFLOW BACK OFFICE OFFRE :

Introduction

Organisation des imports

Règles et restrictions

Tableaux d’attributs

Règle d’exploitation des informations

NeTEx

Delivery et Frames

Cadres de version ou frames

PublicationDelivery

Entités abstraites et héritage

Règles de syntaxe des références

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

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

Import Offre Théorique

Organisation des imports

Fichiers et cadres de version :

Règles de nommage :

Périmètre du jeu de données

Modélisation des données métier échangées

Delivery et Frames

Cadre de version ‘NETEX_COMMUN’

Organisation et hiérarchie du cadre de version :

Description de la General Frame NETEX_COMMUN

Objets pris en compte par le BO Offre Théorique

Objets ignorés dans le cadre de version

Cadre de version ‘NETEX_CALENDRIER’

Organisation et hiérarchie du cadre de version :

Description de la General Frame NETEX_CALENDRIER

Objets pris en compte par le BO Offre Théorique

Règles d'import / Cohérence entre les fichiers

Objets ignorés dans le cadre de version

Cadres de version constituant l’offre d’une ligne (NETEX_OFFRE_LIGNE)

Organisation et hiérarchie du cadre de version :

Cadre de version ‘NETEX_STRUCTURE’

Organisation et hiérarchie du cadre de version

Description de la Generale Frame NETEX_STRUCTURE

Cadre de version ‘NETEX_HORAIRE’

Organisation et hiérarchie du cadre de version :

Objets ignorés dans le cadre de version