Avant-propos

L’harmonisation des pratiques dans l’échange des données relatives aux offres de transport est essentielle :

• pour l’usager, aux fins d’une présentation homogène et compréhensible de l’offre de transport et de l’engagement sous-jacent des organisateurs (autorités organisatrices et opérateurs de transports) ;

• pour les AO, de manière à fédérer des informations homogènes venant de chacun des opérateurs de transports qui travaillent pour elle. L’harmonisation des échanges, et en particulier le présent profil, pourra le cas échéant être imposé par voie contractuelle. Cette homogénéité des formats d’information permet d’envisager la mise en place de systèmes d’information multimodaux, produisant une information globale de l’offre de transports sur un secteur donné, et garantir le fonctionnement des services d’information, en particulier des calculateurs d’itinéraires, et la cohérence des résultats, que ces services soient directement intégrés dans ces systèmes d’information multimodaux ou qu’ils puisent leurs informations sur des bases de données réparties ;

• pour les opérateurs, qui pourront utiliser ce format d’échange pour leurs systèmes de planification, les systèmes d’aide à l’exploitation, leurs systèmes billettiques et leurs systèmes d’information voyageur (information planifiée et information temps réel)

• pour les industriels et développeurs pour pérenniser et fiabiliser leurs investissements sur les formats d’échanges implémentés par les systèmes qu’ils réalisent, tout en limitant fortement l’effort de spécification lié aux formats d’échange

Ce document est le fruit de la collaboration entre les différents partenaires des autorités organisatrices de transports, opérateurs, industriels et développeurs de solutions et de systèmes informatiques ayant pour objet l’aide à l’exploitation du transport public et l’information des voyageurs. Il a pour objet de présenter les éléments communs aux différents Profil de NeTEx: “format de référence pour l’échange de données de description des arrêts” (issu des travaux NeTEx, Transmodel et IFOPT) qui aujourd’hui fait consensus dans les groupes de normalisation (CN03/GT7 – Transport public / information voyageur).

Introduction

Le présent format d’échange est un profil de NeTEx.

NeTEx (CEN/TS 16614-1, 16614-2 et 16614-3) propose un format et des services d’échange de données de description de l’offre de transport planifiée, basé sur Transmodel (EN 12896) et l’ancienne normeIFOPT (EN 28701). NeTEx permet non seulement d’assurer les échanges pour les systèmes d’information voyageur mais traite aussi l’ensemble des concepts nécessaires en entrée et sortie des systèmes de planification de l’offre (graphiquage, etc.) et des SAE (Systèmes d’Aide à l’Exploitation).

NeTEx se décompose en trois parties:

• Partie 1 : topologie des réseaux (les réseaux, les lignes, les parcours commerciaux les missions commerciales, les arrêts et lieux d’arrêts, les correspondances et les éléments géographiques en se limitant au strict minimum pour l’information voyageur)

• Partie 2 : horaires théoriques (les courses commerciales, les heures de passage graphiquées, les jours types associés ainsi que les versions des horaires)

• Partie 3 : information tarifaire (uniquement à vocation d’information voyageur)

NeTEx a été développé dans le cadre du CEN/TC 278/WG 3/SG 9 piloté par la France. Les parties 1 et 2 ont été publiées en tant que spécification technique début 2014. Les travaux pour la partie 3, quant à eux, se sont terminés en 2016.

Il faut noter que NeTEx a été l’occasion de renforcer les liens du CEN/TC 278/WG 3 avec le secteur ferrovaire, en particulier grâce à la participation de l’ERA (Agence Européen du Rail, qui a intégré NeTEx dans la directive Européenne 454/2011 TAP-TSI ) et de l’UIC (Union International des Chemins de fer).

Les normes, dans leur définition même, sont des « documents établis par consensus ». Celles du CEN/TC278 sont de plus établies à un niveau européen, en prenant donc en compte des exigences qui dépassent souvent le périmètre national.

Il en résulte des normes qui sont relativement volumineuses et dont le périmètre dépasse souvent largement les besoins d’une utilisation donnée. Ainsi, à titre d’exemple, SIRI propose toute une série d’options ou de mécanismes dont la vocation est d’assurer la compatibilité avec les systèmes développés en Allemagne dans le contexte des VDV 453/454. De même, SIRI propose des services dédiés à la gestion des correspondances garanties, services qui, s’ils sont dès aujourd’hui pertinents en Suisse ou en Allemagne, sont pratiquement inexistants en France.

De plus, un certain nombre de spécificités locales ou nationales peuvent amener à préciser l’usage ou la codification qui sera utilisée pour certaines informations. Par exemple, les Anglais disposant d’un référentiel national d’identification des points d’arrêts (NaPTAN), ils imposeront naturellement que cette codification soit utilisée dans les échanges SIRI, ce que ne feront pas les autres pays européens.

Enfin, certains éléments proposés par ces normes sont facultatifs et il convient, lors d’une implémentation, de décider si ces éléments seront ou non implémentés.

L’utilisation des normes liées à l’implémentation de l’interopérabilité pour le transport en commun passe donc systématiquement par la définition d’un profil (local agreement, en anglais). Concrètement, le profil est un document complémentaire à la norme et qui en précise les règles de mise en œuvre dans un contexte donné. Le profil contient donc des informations comme :

• détail des services utilisés,

• détails des objets utilisés dans un échange,

• précisions sur les options proposées par la norme,

• précision sur les éléments facultatifs,

• précision sur les codifications à utiliser,

• etc.

Les principaux profils actuellement utilisés en France sont NEPTUNE (profil de TRIDENT) et le profil de SIRI défini par le CEREMA et le STIF. Ces deux profils ont une vocation nationale.

Il est envisagé de produire différents profils de NeTEx avec des objectif métiers et fonctionnels spécialisés. Il est en particulier prévu :

• un profil pour les arrêts,

• un profil pour les réseaux et leur topologie,

• un profil pour les horaire (distinguant horaires et calendriers),

• un profil pour les tarifs,

• un profil complémentaire pour les arrêts (parking, cheminements, équipements, détail de l’accessibilité),

Tous ces profils utiliseront toutefois tous certains concepts génériques mis à disposition par NeTEx (ENTITÉ, VERSION, etc.). Ce document a pour vocation de regrouper tous ces éléments communs afin d’en éviter de multiples descriptions.

Ce document sera donc naturellement référencé par tous les autres profils.

NOTE : Ce document étant un profil d’échange de NeTEx, il ne se substitue en aucun cas à NeTEx, et un minumm de connaissance de NeTEx sera nécessaire à sa bonne compréhension.

Domaine d’application

Le profil français de la CEN/ TS 16614 (NeTEx) pour les éléments communs à l’ensemble des profils décrit les concepts génériques mis à disposition par NeTEx dont il est fait usage dans plusieurs des profils spécialisés.

Il contient essentiellement des objets techniques (ENTITÉ, VERSION, etc.) mais aussi quelques objets fonctionnels utilisés par plusieurs profils (MODE DE TRANSPORT, INSTITUTION, information de CONTACT, etc.).

Références normatives

Les documents de référence suivants sont indispensables pour l’application du présent document. Pour les références datées, seule l’édition citée s’applique. Pour les références non datées, la dernière édition du document de référence s’applique (y compris les éventuels amendements).

CEN/ TS 16614-1, Network and Timetable Exchange (NeTEx) — Part 1: Public transport network topology exchange format

EN 12896, Road transport and traffic telematics - Public transport - Reference data model (Transmodel)

Termes et définitions

Pour les besoins du présent document, les termes et définitions suivants s’appliquent. Une grande partie d’entre eux est directement issue de Transmodel, IFOPT et NeTEx.

NOTE Les définitions ci-dessus sont des traductions littérales du document normatif.

AFFECTATION DE NOTE (NOTICE ASSIGNEMENT)

Affectation d’une NOTE à un objet pour signaler une exception sur une COURSE, un PARCOURS. L’AFFECTATION DE NOTE permet de préciser les points ou les sections d’un parcours concerné par la NOTE

AFFECTATION DE RÔLE (RESPONSIBILITY ROLE ASSIGNMENT)

ALIAS (ALTERNATIVE NAME)

ACCESSIBILITÉ (ACCESSIBILITY ASSESSMENT)

CONDITION DE VALIDITÉ (VALIDITY CONDITION)

CONTACT (CONTACT DETAILS)

DÉCLENCHEMENT DE VALIDITÉ (VALIDITY TRIGGER)

ENTITE (ENTITY)

ENTITÉ PAR VERSION (ENTITY IN VERSION)

FINALITÉ DE GROUPEMENT (PURPOSE OF GROUPING)

GROUPE D’ENTITES (GROUP OF ENTITIES)

INSTITUTION (ORGANISATION)

MODE DE TRANSPORT (VEHICLE MODE)

NOTE (NOTICE)

Un texte à vocation informationnelle, en général concernant des exceptions d’utilisation (sans que cela ne soit une limitation), et rattaché à une LIGNE, un PARCOURS, etc*.*

POINT

SOURCE DE DONNEES (DATA SOURCE)

SOUS MODE (SUB-MODE)

SUITE DE TRONÇON (LINK SEQUENCE)

TRONÇON (LINK)

VARIANTE DE DIFFUSION (DELIVERY VARIANT)

Variante d’une NOTE pour une utilisation sur un média spécifique (texte lu, imprimé, etc.).

VERSION (VERSION)

ZONE (ZONE)

Symboles et abréviations

• AO : Autorité Organisatrice de Transports

• PMR : Personne à Mobilité Réduite

Exigences minimum liées à la LOM et la réglementation Européenne

La LOI n° 2019-1428 du 24 décembre 2019 d’orientation des mobilités (LOM : https://www.legifrance.gouv.fr/dossierlegislatif/JORFDOLE000037646678) et, au niveau Européen, le Règlement Délégué (UE) 2017/1926 De La Commission du 31 mai 2017 (complétant la directive 2010/40/UE du Parlement européen et du Conseil en ce qui concerne la mise à disposition, dans l’ensemble de l’Union, de services d’informations sur les déplacements multimodaux) rendent obligatoire la mise à disposition, quand elles existent, de certains types de données.

Le tableau ci-dessous résulte de l’analyse de la LOM et du règlement délégué et fournit la liste des concepts concernés dans le présent profil. Il sera donc nécessaire de fournir ces données pour être conforme à la législation (il s’agit bien de mettre à disposition toutes les données existantes dans les SI transport, et non de créer des données qui n’existeraient pas encore sous forme informatique).

Notez que les concepts présents dans les tableaux sont les ceux qui sont directement référencés par l’annexe du règlement européen (https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=CELEX:32017R1926&from=FR), mais que pour beaucoup d’entre eux, cela impliquera d’autres concepts (soit par héritage soit par relation, au s sens UML des termes). Ces éléments d’héritage et de relations sont présentés dans les profils, mais pas dans ce tableau.

Le profil Élément Commun n’est naturellement pas le premier concerné par la réglementation, car, contrairement aux autres profils qui sont plus métier, il propose essentiellement des éléments de construction (qui seront référencés par héritage ou par relation par les autres profils). Toutefois il décrit certains éléments réutilisables directement visés par la réglementation : ce sont ces éléments qui présentés dans le tableau ci-dessous.

Les noms des catégories (colonnes Catégorie et Détail) ont été conservés dans la langue originale du document (l’anglais) pour éviter tout risque de confusion. Pour la même raison, les noms des concepts concernés sont ceux de la version originale de Transmodel.

Pour certaines catégories de données, il peut arriver que les concepts correspondants soient multiples, mais aussi qu’ils soient différents suivant le niveau de précision porté par la donnée. La colonne « Concepts à minima » correspond alors au minimum à fournir pour répondre à la catégorie en question et les colonnes « Autres concepts » décrit des informations complémentaires qui, si elles sont utiles, ne sont pas indispensables pour répondre à cette catégorie (notez que dans certains cas, ces concepts additionnels peuvent relever d’autres profils : ceci est précisé dans le tableau quand c’est le cas). Il faut toutefois garder à l’esprit que toute information existante est supposée être mise à disposition (que cela relève de la première ou de la seconde colonne).

La première colonne reprend la notion de niveau tel qu’il est décrit et utilisé par le règlement européen et a notamment une incidence sur le calendrier de mise à disposition de la donnée (voir le règlement pour plus de détails).

Les différents concepts présentés ne sont bien sûr pas détaillés dans ce tableau, mais dans le profil lui-même. C’est aussi dans la description du profil que l’on trouvera les détails concernant les attributs (obligatoire/facultatif, règles de remplissage, codification, etc.). Pour ce qui est des attributs facultatifs, la règle reste que, pour les objets ci-dessous, toute information disponible est supposée être fournie (mais on ne crée pas d’information si elle n’est pas disponible).

Description des éléments communs des profils d’échange

Conventions de représentation

Tableaux d’attributs

NOTE les choix de conventions présentées ici ont pour vocation d’être cohérents avec celles réalisées dans le cadre du profil SIRI (STIF et CEREMA). De plus tous les profils NeTEx partagent les mêmes conventions.

Les messages constituant ce profil d’échange sont décrits ci-dessous selon un double formalisme: une description sous forme de diagrammes XSD (leur compréhension nécessite une connaissance préalable de XSD: XML Schema Definition) et une description sous forme tabulaire. Les tableaux proposent ces colonnes:

• Classification : permet de catégoriser l’attribut. Les principales catégories sont:

  • PK (Public Key) que l’on peut interpréter comme Identifiant Unique: il permet à lui seul d’identifier l’objet, de façon unique, pérenne et non ambiguë. C’est l’identifiant qui sera utilisé pour référencer l’objet dans les relations.

  • AK (Alternate Key) est un identifiant secondaire, généralement utilisé pour la communication, mais qui ne sera pas utilisé dans les relations.

  • FK (Foreign Key) indique que l’attribut contient l’identifiant unique (PK) d’un autre objet avec lequel il est en relation.

  • GROUP est un groupe XML nommé (ensemble d’attributs utilisables dans différents contextes) (cf: )##

• Nom : nom de l’élément ou attribut XSD

• Type : type de l’élément ou attribut XSD (pour certains d’entre eux, il conviendra de se référer à la XSD NeTEx)

• Cardinalité : cardinalité de l’élément ou attribut XSD exprimée sous la forme “minimum:maximum” (“0:1” pour au plus une occurrence; “1:*” au moins une occurrence et sans limites de nombre maximal; “1:1” une et une seule occurrence; etc.).

• Description : texte de description de l’élément ou attribut XSD (seul les attributs retenus par le profil ont un texte en français; les textes surlignés en jaune indiquent une spécificité du profil par rapport à NeTEx).

Les textes surlignés en Jaune sont ceux présentant une particularité (spécialisation) par rapport à NeTEx: une codification particulière, une restriction d’usage, etc.

La description XSD utilisée est strictement celle de NeTEx, sans aucune modification (ceci explique notamment que tous les commentaires soient en anglais).

Les attributs et éléments rendus obligatoires dans le cadre de ce profil restent facultatifs dans l’XSD (le contrôle de cardinalité devra donc être réalisé applicativement). Valeurs de code de profil

Dans la mesure du possible, le profil sélectionne les valeurs de code à utiliser pour caractériser des éléments et les limite à un ensemble de valeurs documentées. NETEX propose plusieurs mécanismes différents pour spécifier les valeurs de code autorisées;

• Une énumérations fixes définies dans le cadre du schéma XSD NeTEx. Le profil impose alors un sous-ensemble des codes NeTEx.

• Spécialisations de TYPE OF VALUE, utilisées pour définir des ensembles de codes ouverts pouvant être ajoutés au fil du temps sans modifier le schéma, par exemple, pour enregistrer des classifications d’entités héritées. Le profil lui-même utilise le mécanisme TYPE OF VALUE dans quelques cas pour spécifier des codes normalisés supplémentaires : ceux-ci sont affectés à un CODESPACE «FR_IV_metadata» (https://netex-cen.eu/FR_IV) indiqué par un préfixe «FR_IV». (par exemple, «FR_IV: monomodal».

• Instances TypeOfFrame: le profil utilise plusieurs TYPES DE FRAME pour spécifier l’utilisation de VERSION FRAME dans le profil.

Indication des classes abstraites

NeTEx, et Transmodel, utilisent largement l’héritage de classe; cela simplifie considérablement la spécification en évitant les répétitions puisque les attributs partagés sont déclarés par une superclasse et que des sous-classes viennent ensuite les spécialiser sans avoir à répéter ces attributs et en n’ajoutant que ceux qui lui sont spécifiques. La plupart des superclasses sont «abstraites» - c’est-à-dire qu’il n’en existe aucune instance concrète; seules les sous-classes terminales sont «concrètes».

Un inconvénient de l’héritage est que si l’on veut comprendre les propriétés d’une classe concrète unique, il faut également examiner toutes ses super-classes. Pour cette raison, le profil EPIP inclut les classes abstraites nécessaires pour comprendre les classes concrètes, même si ces classes concrètes ne sont jamais directement instanciées dans un document NeTEx.

• Les super-classes sont signalées dans les en-têtes par le suffixe «(abstrait)»

• Dans les diagrammes UML (comme pour NeTEx et Transmodel), les noms des classes abstraites sont indiqués en italique et les classes abstraites sont de couleur gris clair.

• Certaines super-classes ne sont techniquement pas abstraites dans NeTEx, mais ne sont pas utilisées comme classes concrètes dans le profil : elles sont signalées avec la même convention que les classes abstraites.

Classes de sous-composants

Un certain nombre de classes ont des sous-composants qui constituent leur définition. Celles-ci fournissent des détails auxiliaires (par exemple, AlternativeText, AlternativeName, TrainComponent) et sont signalées dans les en-têtes par le suffixe «(objet inclus)».

DataManagedObject

DataManagedObject est le type d’objet générique de NeTEx, dont tous les autres objets héritent : il est défini par un type XSD abstrait, et ne peut être instancié que dans un contexte d’héritage.

Le DataManagedObject est l’implémention des EntityInVersion, Version (plus le lien avec les Codespace) directement issus de Transmodel.

Entity et Version – Modèle conceptuel

Dans Transmodel, une ENTITY représente un objet réel dont une instance est présente dans un ensemble de données échangées. Plusieurs versions, généralement successives, d’une ENTITY peuvent être définies ; normalement un ensemble de données donné contiendra une version particulière (mais il est également possible d’avoir plusieurs versions présentes dans le même ensemble de données si nécessaire).

Les données exportées vers un document XML à partir d’un référentiel représentent un instantané de l’état d’une version particulière des données à un moment donné dans le temps. NeTEx s’intéresse principalement aux ENTITY IN VERSION de Transmodel. C’est-à-dire que les éléments de données d’un document XML NeTEx représentent une version particulière de chaque ENTITY. Même si une base de données ne contient généralement qu’une unique représentation de l’état actuel d’une ENTITY (plutôt que de tout son historique de versions), chaque fois qu’elle effectue un export, elle crée en fait une ENTITY IN VERSION correspondant à l’état courant : si la version est modifiée, deux exports successifs donneront lieu à des états différents, c’est-à-dire à différentes ENTITY IN VERSION.

L’EntityInVersion est spécialisé sous le nom de DataManagedObject qui reunit également certains autres concepts Transmodel distincts en une seule classe abstraite XML. Il fournit un moyen pratique de réunir les caractéristiques communes de version, de responsabilité et de condition de validité de Transmodel, uniforme pour tous les objets NeTEx et est donc plus simple à mettre en œuvre.

NeTEx utilise les Codespaces pour s’assurer que les identifiants des instances d’éléments dans un document XML sont uniques, même s’ils proviennent de nombreuses sources différentes – voir 7.3 - CODESPACE et codification des identifiants-.

Une condition de validité est utilisée pour indiquer la période ou les circonstances dans lesquelles un objet peut être utilisé (par exemple « En hiver » ou entre deux dates spécifiées). Par le biais des VERSION FRAMEs (voir plus loin), les conditions de validité peuvent être associées à des ensembles d’objets.

Le DataManagedObject permet l’attribution d’une version, des informations de responsabilité (et rôles associés) à une EntityInVersion ainsi qu’une ou plusieurs instances de ValidityCondition.

Attributs de GroupOfEntities

GroupOfEntities est défini par un type XSD abstrait, et ne peut être instancié que dans un contexte d’héritage. Il existe toutefois une version concrète du GroupOfEntities : le GeneralGroupOfEntities qui a pour vocation de permettre la formation de groupe avec n’importe quels types d’objets, en particulier ceux pour lesquels des spécialisations n’ont pas été prévues.

Attributs de Zone

Attributs de Point

Attributs de Tronçon

Link est défini par un type XSD abstrait, et ne peut être instancié que dans un contexte d’héritage. De plus, les spécialisations concrètes de Link ajoutent systématiquement les attributs FromPointRef et ToPointRef (avec des types de point spécialisés et adaptés : par exemple des RoutePoints pour les RouteLink).

Attributs des Séquences de Tronçons

Les SÉQUENCEs DE TRONÇONS sont des éléments de base pour la construction d’objets plus complexes comme les ITINÉRAIREs (voir Profil Réseau).

Attributs des Points d’une Séquence de Tronçons

Les POINTs DE SÉQUENCE DE TRONÇONS (POINT IN LINK SEQUENCE) permettent essentiellement d’indiquer les numéros d’ordre des POINTs au sein d’une SÉQUENCE DE TRONÇONS.

Conditions de validité

La validité se définit comme la période pendant laquelle, ou les conditions en fonction desquelles l’ENTITÉ peut être utilisée par les voyageurs.

NOTE : le LIEU D’ARRÊT ou l’ACCÈS peut aussi être sujet à des heures d’ouverture, mais ces plages d’ouverture sont potentiellement multiples au sein d’une journée, et variable selon le type de jour : même si les AVAILABILITY CONDITIONs (voir plus bas) permettent de modéliser cette information, il a été décidé de ne pas retenir ce niveau de finesse dans ce profil (on ne conserve donc que de simples date de début et fin de validité). Une NOTE pourra éventuellement être utilisée pour ce type de situation (associée au LIEU D’ARRÊT ou à l’ACCÈS dans ce cas).

La figure ci-dessous montre que les conditions de validité peuvent être exprimées de façon simplifiée au travers du ValidBetween ou de façon détaillée : c’est, autant que possible, la version simplifiée du ValidBetween qui sera préférée.

Deux spécialisations des conditions de validité sont utilisées dans le cadre des profils NeTEx : les conditions de disponibilité qui sont les conditions temporelles, et les déclencheurs de validité qui sont des événements rendant l’ENTITÉ disponibles (pour, par exemple, les itinéraires en cas de crue, la modification de service ou d’ouverture en cas de match ou d’évènement sportif autour d’un lieu comme un stade, etc.)

Accessibilité

Les informations concernant l’ACCESSIBILITÉ sont utilisées de la même façon pour les LIEUx D’ARRÊT, les LIGNEs et les COURSEs. L’information d’accessibilité présentée correspond à une information minimale : le profil NeTEx pour l’accessibilité propose une version beaucoup plus détaillée de cette information (incluant les cheminements, les équipements, etc.).

NOTE L’attribut MobilityImpairedAccess n’a pas été retenu dans le cadre des travaux sur le modèle d’arrêt partagé (car considéré comme trop générique). Toutefois, ce champ étant obligatoire dans NeTEx, il devra être présent dans les échanges. Les valeurs qu’il peut prendre étant true/false/unknow/partial, il est recommandé (pour des raisons de cohérence) que sa valeur soit:

• true si tous les champs de AccessibilityLimitation sont à true

• false si tous les champs de AccessibilityLimitation sont à false

• partial si seulement certains champs de AccessibilityLimitation sont à true

• unknow dans tous les autres cas

Chaque fois que pour LimitationStatus la valeur “partial” est utilisée, une “ValidityCondition-> Description” (dans l’objet AccessibilityAssessment) doit être fournie en conséquence pour expliquer pourquoi l’accessibilité n’est que partielle (notez que seule la Description de la ValidityCondition peut être remplie). Les informations textuelles contenues doivent pouvoir être présentées au public sans autre modification.

Nom alternatif

Texte Alternatif (AlternativeText)

Il est parfois nécessaire de fournir plusieurs variantes d’un nom ou un autre texte descriptif, en particulier si les informations sont requises dans plusieurs langues. AlternativeText est un moyen générique de fournir de telles variantes pour tout attribut textuel d’un DataManagedObject. Il peut être considéré comme un complément au mécanisme AlternativeName (décrit plus ci-dessus) et peut être utilisé pour n’importe quel nom, description ou autre texte.

Note: l’élément ***AlternativeName (***en comparaison à AlternativeText) sera préféré pour les alias de nom propre (par exemple “Bercy”; POPB”, ”AccorHotels Arena”, ”Palais omnisports de Paris-Bercy”), alors qu’AlternativeText servira essentiellement pour les traductions (par exemple. “en.London”, “fr.Londres”, “it.Londra”, “cn.倫敦”, “ge.ლონდონი”, etc).

Dans le profil, AlternativeText sera toujours utilisé comme balise incluse (et non comme élément racine).

1. AlternativeText – XML Element

Localisation (Location)

Cas des surfaces

Les ZONEs, en plus d’être géolocalisés par un point représentatif (centroïd) peuvent être représentées par une surface d’emprise. Cette surface s’exprime sous la forme d’un polygone dont la structure est décrite ci-dessous (il s’agit de la structure GML permettant de décrire les polygones gml :PolygonType).

Polygon – XSD

Seul le contour extérieur de ce polygone (exterior) est retenu dans le cadre du présent profil.

EXEMPLE un polygone de contour de LIEU D’ARRÊT pourra donc, par exemple, prendre la forme ci-dessous

<gml:Polygon gml:id="12323">
<gml:exterior>
<gml:LinearRing>
<gml:pos>-120.000000 65.588264\</gml:pos>
<gml:pos>-120.003571 65.590782\</gml:pos>
<gml:pos>-120.011292 65.590965\</gml:pos>
<gml:pos>-120.022491 65.595215\</gml:pos>
<gml:pos>-120.031212 65.592880\</gml:pos>
<gml:pos>-120.019363 65.586121\</gml:pos>
<gml:pos>-120.030350 65.585365\</gml:pos>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>

Attributs d’Addresse

Locale (contexte local du lieu)

Si cette information peut être portée par chaque objet, il est généralement plus pertinent de l’utiliser de façon générique au niveau Frame (voir FrameDefaults en 7-Entêtes NeTEx) ce qui en évite la répétition. Si elle est présente au niveau Frame et sur un objet particulier, la version de l’objet particulier sera utilisée pour celui-ci.

Projections

Les projections sont exclusivement utilisées pour projeter les objets du transport public sur leur infrastructure (voirie, rail, voies navigables et câbles).

Les attributs de la structure abstraite de projection (présentés par la figure ci-dessous), ne sont pas retenus dans les profils NeTEx : seuls certains attributs proposés par les spécialisations (voir ci-dessous) seront utilisés.

Seules les PointProjection (projection d’un Point sur un point ou un tronçon) et les ZoneProjection (projection de zone sur une zone ou un point) sont retenues. La projection de tronçon n’est pas retenue, car difficile à mettre en œuvre opérationnellement (on doit généralement faire face à des projections 1-N ou N-1, et la gestion de plusieurs tronçons peut induire des difficultés de reconstruction topologique ; en particulier dans le cas de cible disposant de structure non topologique ou spaghetti : http://www.gitta.info/DigitModel/fr/html/Topologies_learningObject1.html). Pour projeter un tronçon on se cantonnera donc à en projeter les points extrémités (qui eux peuvent être projetés sur des tronçons).

Les projections, telles qu’utilisées dans le contexte du profil, feront des références vers des données externes (OSM, Nokia Here (ex Navteq), Tomtom TeleAtlas, IGN, INSPIRE, etc.). Pour réaliser ces références de façon non ambiguë, on utilisera conjointement deux mécanismes proposés par NeTEx: les CODESPACE (voir 7.3) et les attributs associés aux références.

Le CODESPACE permettra de référencer le jeu de données, par exemple en décrivant un jeu de données OSM comme ci-dessous

<Codespace id="*osm*">
<Xmlns>*osm*\</Xmlns>
<XmlnsUrl> *http://planet.openstreetmap.org/planet/2014/*\</XmlnsUrl>
<Description>Open Street Map through Planet OSM\</Description>
</Codespace>

Une référence à un objet OSM pourra alors avoir la forme ref=osm:4701234567

Mais cela ne sera souvent pas suffisant et il faudra compléter cette référence par d’éventuelles informations de classe, de version et de date proposé par le mécanisme de référence de NeTEx.

Enumérations pour les modes et sous-modes

Les modes

La liste des modes utilisés est la suivante (version anglaise d’origine et traduction):

Modes

Les sous modes

Le mode peut de plus être complété d’une caractéristique appelée “sous mode” qui, plus que le type du véhicule, caractérise le type d’exploitation qui est mis en place (navette, train régional, etc.). La figure ci-dessous présente l’ensemble des modes normalisés.

Sous modes

Par souci de clarté, les sous-modes ont été classés en relation avec un mode, toutefois le sous-mode “tramTrain” peut être utilisé indifféremment avec un mode Tram ou un mode Train (Ferré, auquel cas il faut l’interprété “trainTram”).

Institutions

L’INSTITUTION (ORGANISATION) représente une entreprise impliquée dans la planification, la collecte ou la fourniture d’informations sur les transporet en commun. Par exemple, une entreprise fournissant un service d’informations sur les transports publics, une autorité, un opérateur ou une entreprise fournissant un service de collecte d’informations.

Dans le profil elle est essentiellment utile en tant que superclass d’OPÉRATEUR et d’AUTORITÉ.

ORGANISATIONs et responsabilité – Modèle conceptuel

Unités organisationnelles

Une unité organisationnelle est un sous ensemble d’une Institution à laquelle est attribué un ensemble de responsabilités de planification et de contrôle.

Exploitants

L’OPÉRATEUR hérite de l’INSTITUTION, on utilisera un champ OrganisationType instancié avec operator ou railOperator.

Autorités

De même pour décrire une AUTORITÉ ORGANISATRICE, on utilisera une INSTITUTION avec un champ OrganisationType instancié avec authority.

Groupes d’operateurs

Les GROUPEMENTs D’OPÉRATEURS sont aussi des objets à décrire. Toutefois, le GROUPEMENT D’OPÉRATEURS n’apporte aucun attribut spécifique par rapport au GROUP OF ENTITIES, on se réfèrera donc à ce dernier pour le détail des attributs.

Rôles et affectation de responsabilités

Un ensemble de responsabilités peut être spécifié pour un objet DataManagedObject, notament afin de spécifier les institutions responsables de différents rôles de gestion des données, telles que la création, la maintenance, la distribution ou l’octroi de licence aux données.

Dans le profil, un ResponsibilitySet est normalement utilisé au niveau VERSION FRAME pour s’appliquer à tous les éléments du cadre, plutôt qu’à des objets individuels (bien que cela reste possible).

Un ResponsibilitySet est composé d’une ou de plusieurs instances de ResponsibilityRoleAssignment. Chaque attribution de rôle de responsabilité attribue un ou plusieurs rôles à une organisation ou à une partie d’organisation, en ce qui concerne la responsabilité qui lui incombe relativement aux objjets décrits (propriété, planification, exploitation, etc.) ou la gestion de ces données (distribution, mises à jour, etc.).

Notes (NOTICEs)

Le tableau ci-dessous présente l’affectation de NOTE: seul les deux attributs retenus y sont présentés (l’affectation est très paramétrable, mais la grande majorité des attributs ne sont pas retenus dans le profil).

Les NoticeAssignments doivent être intégré en ligne à l’élément annoté et non placé séparément. Ils peuvent faire référence à une NOTICE déjà défini dans un NOTICE ASSIGNMENT antérieur.

Jour d’exploitation

OPERATING DAY et DAY TYPE – Model conceptuel

Type de Jour

Note: si le TYPE DE JOUR n’est valable que pour une période de temps limitée, on le précisera grâce au ValidBetween (FromDate, ToDate) disponible au travers de son héritage de DataManagedObject.

Les énumérations correspondantes sont les suivante (noter que l’on n’utilisera pas les valeurs anyXxx ou everyXxx, qui sont les valeurs par défaut quand le champ est absent).

Dans un certain nombre de situation, les PROPRIÉTÉ DE JOUR ne permettent pas de décrire précisément un TYPE DE JOUR, qui en final ne sera défini que par un ensemble de JOURs D’EXPLOITATION: on réalise alors une affectation entre le TYPE DE JOUR et les JOURs D’EXPLOITATION correspondants.

Le CALENDIER DE SERVICE permet de grouper des JOURs D’EXPLOITATION et des AFFECTATIONs DE JOUR d’exploitation. On pourra ainsi, en conservant le même TYPE DE JOUR, faire des mises à jour de calendrier en transmettant uniquement une mise à jour du CALENDRIER DE SERVICE (ou un nouveau CALENDRIER DE SERVICE).

Note : UicOperatingPeriod sera toujours utilisé dans le contexte du profil, afin de rendre le ValidDayBits obligatoire (chaîne de bits, une pour chaque jour de la période: qu’elle soit valide ou non le jour).

Tranche horaire

Type de Valeur

Les types de valeur sont utiles pour préciser et personnaliser toutes les codifications ouvertes (TypeOfXxxxx, comme les TypeOfNoticeRef par exemple).

Presentation

La Présentation fournit des informations de graphisme et de style de représentation associés à un objet (couleurs, police de caractère, etc.).

## Branding

Le Branding corresponf aux informations permettant la descriptrion des marques.

Entêtes NeTEx

PublicationDelivery

Les données échangées avec NeTEx sont systématiquement accompagnées d’un entête qui permet de décrire le contenu du jeu de données et précise le contexte de leur publication (on peut parler de « métadonnées » à ce niveau).

L’entête lui-même (PublicationDelivery présenté ci-dessous) est directement suivi des données (payload), ces données étant généralement regroupées dans un CADRE DE VERSION (VERSION FRAME). Ce CADRE DE VERSION permet de grouper un ensemble de versions des données : on n’échange en effet pas la donnée (ENTITY) elle-même, mais une version particulière de ces données (ENTITY IN VERSION). Il convient donc, lors d’un échange, de fournir des données dans des versions cohérentes les unes avec les autres. Ce CADRE DE VERSION peut naturellement être soumis à des CONDITIONs de VALIDITÉ. On pourra par la suite effectuer des mises à jour mineures de versions d’objets individuelles (ne remettant pas en question la cohérence globale de l’ensemble) ou fournir une nouvelle version de ce CADRE DE VERSION, en particulier quand les relations entre les objets sont impactées par les modifications apportées.

NeTEx fournit un certain nombre de CADREs DE VERSION prédéfinis, mais permet aussi de définir des CADREs DE VERSION spécifiques. C’est cette seconde option qui est retenue pour le présent profil. Ces CADREs spécifiques sont décrits dans les lignes ci-dessous.

Frames (CADRE DE VERSION)

Une VersionFrame fournit un conteneur versionnable qui permet d’échanger un ensemble cohérent d’éléments connexes correspondant, par exemple aux horaires d’une ligne, ou aux gares d’un pays. La VersionFrame garantit notament la coherence des versions des objets en relation les uns avec les autres.

FRAMEs – Modèle conceptuel

Formant un ensemble cohérent d’éléments connexes (c’est-à-dire un ensemble complet d’éléments tous de version compatible), les FRAMEs sont fortement liés à la gestion des versions. Chaque instance VERSION FRAME a également une ou plusieurs VALIDITY CONDITION qui lui sont attachées (puisqu’il s’agit d’un DataManagedObject à part entière*)* qui est utilisé pour exprimer la validité du cadre et de son contenu dans son ensemble.

Notez que ces conditions de validité du VERSION FRAME ne doivent pas être confondues avec contentValidityConditions qui sont des conditions de validité plus spécifiques qui s’appliquent à plusieurs éléments dans le cadre (condition de validité partagées qui seront référencées par les objets eux même). Dans le cadre du profil, les conditions de validité du VERSION FRAME viennent limiter la validité des objets (un objet n’est plus considéré comme valide avant ou après la période de la FRAME qui le contient).

VersionFrame lui-même est abstrait : NeTEx fournit un ensemble de cadres « spécifiques » spécialisés à des fins spécifiques (ServiceFrame, SiteFrame, etc.) couvrant chacun un sous-ensemble fonctionnel des éléments de données NeTEx; ainsi qu’un GeneralFrame qui peut contenir n’importe quel type d’ENTITY IN VERSION.

Une VersionFrame peut se voir attribuer une TypeOfFrame; une classification arbitraire définie par l’utilisateur (et qui est ici utilisée pour identifier le profil).

La figure ci-dessous présente l’ensemble des CADREs DE VERSION prédéfini dans NeTEx ainsi que le GeneralFrame qui est utilisé ici avec un type de CADRE spécifique pour les profils NeTEx utilisés en France: NeTEx COMMUN, NeTEx ARRET, NeTEx LIGNE, NeTEx RESEAU, NeTEx HORAIRE, NeTEx CALENDRIER et NeTEx TARIF.

predefined Frames– XSD

Dans le cadre du profil les distance sont par défaut exprimées en système métrique et les sommes d’argent en Euros.

CODESPACE et codification des identifiants

NeTEx propose un mécanisme de CODESPACE (à mettre en parallèle avec les Namespace XML) qui permet de qualifier les identifiants et d’en assurer ainsi l’unicité même si plusieurs sources de données non coordonnées sont mises à contributions. En général, un CODESPACE est associé à un fournisseur de données.

Un CODESPACE est défini comme une expression de chemin d’accès conforme à la description d’un domaine internet, suivant la recommandation du IANA (Internet Assigned Numbers Authority) qui permet d’assurer un enregistrement de domaine garantissant l’unicité. À titre d’exemple, on peut citer: tfl.gov.uk, bahn.de, ratp.fr, foo.com, ou sbb.de.

À chaque CODESPACE est attribué un identifiant qui sera utilisé dans le document XML après avoir été déclaré dans les CODESPACEs du CADRE DE VERSION.

EXEMPLE de définition de CODESPACE

<CompositeFrame version="any" id="mybus:CompositeFrame:CF1">
<!--- ======= CODESPACEs======== -->
<codespaces>
<Codespace id=" *era* ">
<Xmlns>*era*\</Xmlns>
<XmlnsUrl>*http://era.org.eu/*\</XmlnsUrl>
<Description>European Rail AUthority\</Description>
</Codespace>
</codespaces>

EXEMPLEd’utilisation de CODESPACE pour les identifiants id=napt:4701234567

ref=napt:4701234567
id=era:4501234345

Cette utilisation du CODESPACE est générique pour l’ensemble des objets. Certains objets comme les arrêts peuvent disposer d’une codification particulière (utilisée en lieu et place de la partie numérique dans les exemples ci-dessus).

Codification des identifiants

L’objectif d’une codification étant de s’assurer de l’unicité (au niveau national) et de la pérennité de l’identifiant. Toute solution autre, permettant d’assurer une unicité et une pérennité de l’identifiant est valable. En particulier, si un réfentiel de données (arrêts, lignes, etc.) propose des identifiants uiques et pérennes mais avec une structure très différente, cela est tout à fait acceptable ! Il est par contre impératif que l’identifiant d’un objet soit strictement le même quel que soit le flux de données utilisé (SIRI, NeTEx, tous profils confondus, et même GTFS ou tout autre format qui pourrait être utilisé pour l’échange de données).

NOTE IMPORTANTE : la technique de construction proposée ici à pour vocation d’assurer la l’unicité de l’identifiant, mais en aucun cas l’identifiant ne peut être considéré comme porteur de sémantique. En conséquence toute analyse (segmentation, parsing, extraction d’information, etc.) de l’identifiant est à proscrire !

Pour mémoire, le profil SIRI Ile-de-France propose la codification suivante pour tous les identifiants:

[Fournisseur]:[type d'objet]:\[typeObjetDétaillé]:[identifiantTechnique]:LOC

Si l’objet n’a encore jamais été échangé, dans le contexte des profils NeTEx, en dehors des arrêt (présenté ci-dessous) la codification suivante est proposée :

• [Fournisseur] : est remplacé par le CODESPACE (et peut être complété par le DataSourceRef de EntityInVersion)

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

• [identifiantTechnique]: est naturellement conservé

• LOC : est conservé pour permettre 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. Pour les objets faisant partie de référentiels partagés on peut le remplacer par un [NomAttributaire] qui le nom (ou code) du système référentiel utilisé pour attribuer l’identifiant.

La codification retenue est donc:

[CODESPACE]:[type d'objet]:[identifiantTechnique]:[LOC ou Nom attributaire]

Exemple RATP-I2V:JourneyPattern:2354345:LOC ou IDFM:Line:345:CODIFLIGNE ou STIF-CODIFLIGNE:Line:C00001:

Note : par convention, on conserve les “:” de fin même s’il n’y a pas de valeur [NomAttributaire] ou LOC (même encore une fois, l’analyse du contenu d’un identifiant est plus que fortement déconseillée, et d’autres structures peuvent être utilisée, en fonction des système attributaire, pour peut que l’unicité soit conservée au niveau national.

Codification des identifiants d’arrêt

Les arrêts sont un cas particulier et donneront lieu à une codification spécifique. La forme actuellement envisagéee étant [Code PAYS]:[Code commune INSEE]:[Type d’objet]:[Code arrêt spécifique]:[Code émetteur du code technique ou LOC], on aura donc :

• [Code PAYS]: Identifiant du Pays en respectant la norme ISO 3166-1 (voir: www.iso.org/iso/country_codes/iso_3166_code_lists.htm, FR pour la France ).

• [Code commune INSEE]: 5 caractères (exemple : 78297 pour Guyancourt), 2 caractères pour le département et 3 pour la commune elle-même en France métropolitaine et 3 2 caractères pour le département et 2 pour la commune elle-même pour l’outre-mer.
  Ce code commune pourra, de façon optionnelle, être complété par le numéro d’arrondissement de commune précédé d’un «-» (tiret, ASCII code 45) codé sur un ou deux caractères numériques.
  En cas de mise à jour du code commune par l’INSEE, par souci de pérennité de l’identifiant, on conservera le code attribué initialement (pas de suivi d’un éventuel changement de codification INSEE donc).

• [Type d’objet]: ZE (ZONE D’EMBARQUEMENT), LMO(LIEU D’ARRET MONOMODAL), PM (POLE MONOMODAL), LMU(LIEU D’ARRET MUTIMODAL), AC (ACCES)

• [Code arrêt spécifique]: code technique libre

• [Code émetteur du code technique ou LOC] : Identifiant de l’attributeur de code technique centralisé s’il y en a un et LOC sinon. Ci-dessous quelques pistes pour identifier l’attributaire

  • Si c’est une région : code NUTS (https://eur-lex.europa.eu/eli/reg/2003/1059/2018-01-18) sans le FR, précédé de NUTS (NUTS714 pour Isère par exemple)

  • Si c’est une AOT : code NAO de la norme NF-9950 précédé de NAO (NAO17 pour Blefort par exemple)

  • Si un attributeur national est national est créé, il prendra le code FR

  • si le code technique est attribué par le système local : code LOC (comme pour le profil SIRI) . Note : une code LOC est a considérer comme à priori temporaire, en attente de la mise en place d’un système centralisé d’attribution des identifiants

  • pour le mode ferré, le code sera ERA (pour European Rail Agency) pour les identifiant issue de la STI-TAP (à priori les codes UIC ne seront pas utilisés, mais si c’était le cas, le code serait UIC).

Examples :

• Gare ferré “PARIS MONTPARNASSE 1 2” : FR:75114:LMO:39100:ERA
• Arrêt de bus sur la commune de Guyancourt, attribué par un système transporteur : FR:78297:ZE:110E8400-E29B-11D4-A716-446655440000:LOC
• Station de métro parisienne, avec identifiant STIF (REFLEX) : FR:75105:LMO:43289:NUTS10

Encore une fois si l’arrêt a déjà été identifié dans le cadre d’un échange et que l’identifiant utilisé et unique au niveau national et pérenne, on conservera naturellement son identifiant et la codification ci-dessus ne s’applique plus.

TypeOfFrame : types spécifiques

Le présent profil utilise un TypeOfFrame spécifique, identifié NETEX_COMMUN, NETEX_ARRET, NETEX_RESEAU, NETEX_HORAIRE, NETEX_CALENDRIER, NETEX_TARIF. Il apparaitra systématiquement et explicitement dans les éléments members du GeneralFrame.

Le présent document ne présente que les TypeOfFrame NETEX_COMMUN et NETEX_CALENDRIER. Les autres seront présentés par les documents spécifiques de chacun des profils.

Dans la majorité des cas on aura besoin de plusieurs CADREs DE VERSION pour un échange complet (par exemple NETEX_COMMUN et NETEX_ARRET): on utilisera donc un CompositeFrame pour les grouper au sein d’un unique échange.

Trois types spécifiques sont attribués à ces CompositeFrame:

• NETEX_FRANCE peut contenir n’importe quelle autres Frames et n’importe quel jeu de données

• NETEX_LIGNE contient des GeneralFrame de type *NETEX_COMMUN, NETEX_RESEAU, NETEX_HORAIRE et **NETEX_CALENDRIER ***permettant la description complète d’une unique ligne (une et une seule, avec toutes les informations nécessaires à l’information voyageur). Le champ Name des CompositeFrame de type NETEX_LIGNE contient le nom de la ligne.

• NETEX_N_LIGNES contient des GeneralFrame de type *NETEX_COMMUN, NETEX_RESEAU, NETEX_HORAIRE et **NETEX_CALENDRIER ***permettant la description complète d’un ensemble de lignes (toutes les informations nécessaires à l’information voyageur pour les lignes concernées). Le champ Name des CompositeFrame de type NETEX_N_LIGNE contient le nom des lignes concernées, séparés par des virgules.

Version des objets et références

NeTEx porpose naturellement une possibilité de gestion des versions des objets (voir EntityInVersion et tous les attributs associés) et met aussi met en place un mécanisme de contrôle d’unicité des identifiants relativement sophistiqué. Il est basé sur l’utilisation de la contrainte xsd:key (http://www.w3schools.com/schema/el_key.asp) qui permettra aussi, par la suite, de gérer les contraintes de référence vers les objets.

La contrainte d’unicité des identifiants permet de vérifier qu’au sein d’un jeu de données, on n’a pas deux objets portant le même identifiant ET la même version (pour deux objets de même type ou de types différents). Cette vérification d’unicité impose qu’un attribut version soit présent (dans le cas contraire une erreur sera signalée): si l’on ne dispose pas de versionnage des objets, il suffira d’indiquer version=“any"(par convention).

Rappelons que la codification des identifiants est imposée par le profil.

De façon à systématiquement activer ce contrôle de cohérence, le profil rend obligatoire de toujours mettre une version associée aux identifiants, en offrant toutefois la convention d’utilisation du “any” si la version est indéfinie ou indifférente. De même, dans un souci de qualité des données, il est obligatoire de faire figurer l’indication de version dans toutes les références (éventuellement positionné à “any") et ce pour tous les objets figurant dans le même document XML.

Pour les objets externes (c’est-à-dire ne figurant pas dans le même document XML, ou étant définis dans un référentiel), il reste utile de préciser le numéro de version. Si l’on précise un attribut de version, la vérification produit une erreur car, par définition, un objet externe ne sera pas présent dans le jeu de données. Pour pallier cette difficulté, NeTEx permet de précise le numéro de version en utilisant l’attribut versionRef (et non plus version) comme indiqué dans l’exemple ci-dessous:

<TypeOfFrameRef ref="FR:TypeOfFrame:NETEX_COMMUN" versionREf="1.01:FR-NETEX_COMMUN-1.0"/>

Toutefois, contrairement aux références internes, la précision du numéro de versionRef n’est pas obligatoire pour les références externes (on pourra cependant considérer comme une bonne pratique de systématiquement la fournir en indiquant “any” quand elle n’est pas connue ou pas utile).

De plus, pour simplifier l’utilisation de données et ne pas imposer de systèmatiquement rechercher et charger l’objet référencé, le profil recommande, pour les objets externes uniquement, de faire figurer le nom (l’information portée par sa balise name quand il y en a une) en tant que contenu de la balise référence.

<StopPlaceRef ref="FR:78297:LMO:110E8400:LOC" versionRef="8.3">Le Corbusier</StopPlaceRef>

Note : l’une des conclusions des point ci-dessus est que toute référence ne portant pas l’attribut version correspond forcément à une référence vers un objet externe.

Version du profil

Dans le temps, il pourra exister plusieurs versions des profils qui s’appuieront éventuellement sur différentes versions de NeTEx (en fonction des évolutions à venir).

Une compatibilité ascendante est assurée entre les versions de NeTEx et devra aussi l’être entre les versions de profils.

Il n’y a par contre aucune garantie de compatibilité “descendante” : on peut assurer qu’un client de version antérieure puisse toujours s’adresser à un serveur de version postérieure, mais l’inverse ne peut être réalisé. En effet, un producteur de donnée compatible avec la version 1.0 (par exemple) du profil ne peut pas avoir été développé en prenant en compte les évolutions d’une future version 2.0 (ou plus), puisque chaque nouvelle version s’accompagne généralement de fonctionnalités additionnelles. Si un producteur peut tenir compte des versions passées, il ne peut anticiper les versions à venir.

Afin d’assurer cette compatibilité ascendante, le profil NeTEx intègre un mécanisme de gestion de version qui a plusieurs objectifs:

• Permettre à un producteur de données de savoir suivant quel profil il doit répondre à une requête client (cas d’appel par Web service) en supportant plusieurs versions ou en redirigeant les requêtes et donc sans contraindre tous les clients à changer de version en même temps que lui ;

• Permettre à un producteur de données de signaler à un client qu’il ne supporte pas la version demandée (plutôt que de lui répondre avec une erreur) ;

• Permettre à un client de gérer les réponses d’un serveur d’une version antérieure.

Le principe de gestion de version est simple : il s’appuie sur les identifiants de version du CADRE DE VERSION spécifique utilisé par le profil.

La codification de la version de profil se fait de la façon suivante : .x.y:FR-NETEX_nnnn-a.b-c. Par exemple :

• 1.0:FR-NETEX_ARRET-1.0
• 1.1:FR-NETEX_ARRET-1.2-4

1. x.y étant la version de NeTEx (obligatoire): il s’agit ici du numero de version XSD (et WSDL) NeTEx

2. : est un délimiteur obligatoire

3. FR le digramme de la France (ISO 3166-1 alpha-2) (obligatoire)

4. NETEX_nnnnn permet d’identifier le profil (obligatoire), nnnn valant “FRANCE”, “COMMUN”, “ARRET”, “LIGNE”, “RESEAU”, “HORAIRE”, “CALENDRIER” ou “TARIF”.

5. - est un délimiteur obligatoire

6. a.b est la version du profil (obligatoire). a et b sont des chiffres entiers.

7. - est un délimiteur facultatif (doit être omis si ni c ni d ne sont présents, obligatoire sinon)

8. c est le numéro de version de l’implémentation locale. c est constitué de chiffres et de “.” uniquement

Les principales règles d’utilisation des versions sont les suivantes. Soit deux versions de profil N et N+ (N+ étant une version postérieure à N).

• Un client en version N ne peut recevoir des données que d’un producteur version N+ (N ou supérieur). Le serveur N+ peut alors :

  • (solution non recommandée) Indiquer qu’il ne supporte pas cette version en utilisant le code d’erreur CapabilityNotSupportedError (voir 8.2) en précisant dans le champ CapabilityRef le numéro de version qui a été demandé (donc N ici)

  • adapter sa réponse pour la rendre conforme à la version N

  • Transférer la requête à un serveur en version N (le “transfert” peut, techniquement, être réalisé de différentes façons, comme l’URL Forwarding, mais ceci relève du choix d’implémentation technique).

• Un client N+ ne peut pas s’adresser à un producteur version N en demandant la version N+ (le serveur ne supportant pas cette version N+). Si toutefois cela se produisait et que le serveur soit en mesure de décoder la requête sans générer d’erreur, il est recommandé de répondre qu’il ne supporte pas cette version en utilisant le code d’erreur CapabilityNotSupportedError en précisant dans le champ CapabilityRef le numéro de version qui a été demandé (donc N+ ici)

• Un client N+ peut s’adresser à un serveur N en demandant la version N. La réponse lui est alors retournée en version N.

NOTE Cette gestion de version n’est en rien incompatible avec l’insertion d’un numéro de version dans l’URL d’accès au service (avec éventuellement plusieurs URL si plusieurs versions sont disponibles). Ce type de gestion des versions à travers les URL est à négocier entre les partenaires impliqués dans l’échange.

Modalités d’échange

Deux grandes typologies d’échange peuvent être envisagées : par échange de fichier (sous quelque forme que ce soit : FTP, mail, etc.) ou au travers de web service.

Fichier

L’échange par fichier est assez simple : le fichier est un fichier XML classique qui ne contiendra qu’un seul élément racine : PublicationDelivery (voir 7.1).

Le fichier XSD de plus haut niveau à utiliser est NeTEx_publication.xsd.

Web service

Partage des principes avec SIRI

L’accès au travers de Web Service est proposé par NeTEx. La structure de ce Web Service est identique à celle proposée par la norme SIRI. Il conviendra donc de se référer à la documentation SIRI (partie 2) pour disposer d’une description détaillée de ce mode d’accès : le présent chapitre ne traite que des éléments spécifiques à NeTEx et leur personnalisation dans le cadre des profils de NeTEx.

De plus SIRI dispose déjà d’un profil (élaboré à l’origine par le STIF et devenu profil national). Sauf précision contraire, l’ensemble des éléments techniques du profil SIRI sont repris dans les profils NeTEx, en particuler :

• la supervision des connexions avec CheckStatus (chapitre - Vérification de la disponibilité des partenaires du profil SIRI version France)

• la gestion des erreurs (chapitre - Gestion des erreurs du profil SIRI France)

• la gestion de la sécurité et des communications (voir profil SIRI France)

Toutefois l’utilisation du mécanisme d’abonnement n’est pas retenue dans le cadre des profils NeTEx (ce mécanisme ne prend tout son intérêt que dans un contexte de forte variabilité de l’information, ce qui n’est pas le cas pour les arrêts, le réseau et les horaires planifiés).

La figure ci-dessous présente le Web Service SOAP de NeTEx. Seuls les points d’accès GetNetex et CheckStatus sont retenus dans la cadre des profils NeTEx.

Web service SOAP de NeTEx

Requête

La figure ci-dessous présente le point d’accès GetNetexService qui permet de solliciter n’importe quel service NeTEx (à ce titre il permet aussi la sollicitation du CheckStatus, mais dans le cadre des profils NeTEx et afin d’être cohérent avec le profil SIRI, le CheckStatus sera sollicité à partir de l’accès direct proposé dans la WSDL. Seule la partie ServiceRequest est donc retenue pour le profil.

GetNeTexService - XSD

La partie Payload est de type AbstractFunctionalServiceRequest : dans le cas de NeTEx et du présent profil, un mécanisme XML de “substitution group” permettra d’utiliser un DataObjectRequestStructure (décrit plus bas) en tant que Payload.

La structure ServiceRequestContext est strictement compatible avec celle du profil SIRI (la seule différence étant que le mode abonnement n’est pas pris en charge).

La requête à proprement parler est décrite ci-dessous. Elle est essentiellement constituée d’un NetworkFrameTopic (la requête) et d’une Policy (règles à appliquer pour la contraction de la réponse).

DataObjectRequest- XSD

Réponse

La réponse retournée est très simple : naturellement, en cohérence avec la requête, seul le ServiceDelivery de la réponse sera utilisé.

GetNeTexServiceResponse - XSD

ServiceDelivery - XSD

GetNeTexServiceResponse - XSD