[{"content":"Avant-propos\nL’harmonisation des pratiques dans l’échange des données relatives aux offres de transport est essentielle :\n  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) ;\n  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 ;\n  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)\n  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\n  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: \u0026ldquo;format de référence pour l\u0026rsquo;échange de données de description des arrêts\u0026rdquo; (issu des travaux NeTEx, Transmodel et IFOPT) qui aujourd’hui fait consensus dans les groupes de normalisation (CN03/GT7 – Transport public / information voyageur).\nCe document a été validé et publié comme suit :\n travaux de révision : 2024-2025 date de validation en CN03 : 19 décembre 2025 date de publication : 6 mars 2026  Introduction\nLe présent document fait partie du profil France de NeTEx.\nNeTEx (CEN/TS 16614 series) propose un format et des services d\u0026rsquo;échange de données de description de l\u0026rsquo;offre de transport planifiée, basé sur Transmodel (EN 12896 series) et l’ancienne norme IFOPT (EN 28701). NeTEx permet non seulement d\u0026rsquo;assurer les échanges pour les systèmes d\u0026rsquo;information voyageur mais traite aussi l’ensemble des concepts nécessaires en entrée et sortie des systèmes de planification de l\u0026rsquo;offre (graphiquage, etc.) et des SAE (Systèmes d’Aide à l’Exploitation).\nNeTEx se décompose en six parties:\n  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)\n  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)\n  Partie 3 : information tarifaire (uniquement à vocation d’information voyageur)\n  Partie 4 : profil européen pour l\u0026rsquo;information voyageur (EPIP)\n  Partie 5 : nouveaux modes (les véhicules partagés en libre service, les courses partagées, etc.)\n  Partie 6 : profil européen pour l\u0026rsquo;information voyageur en lien avec l\u0026rsquo;accessibilité (EPIAP)\n  NeTEx a été développé dans le cadre du CEN/TC278/WG3/SG9 piloté par la France. Les premières publications de NeTEx datent de 2014 et les plus récentes de mars 2026.\nIl faut noter que NeTEx a été l\u0026rsquo;occasion de renforcer les liens du CEN/TC 278/WG 3 avec le secteur ferroviaire, en particulier grâce à la participation de l\u0026rsquo;ERA (Agence Européen du Rail, qui a intégré NeTEx dans la directive Européenne 454/2011 TAP-TSI ) et de l\u0026rsquo;UIC (Union International des Chemins de fer).\nLes 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.\nIl en résulte des normes qui sont relativement volumineuses et dont le périmètre dépasse souvent largement les besoins d\u0026rsquo;une utilisation donnée. Ainsi, à titre d\u0026rsquo;exemple, SIRI propose toute une série d\u0026rsquo;options ou de mécanismes dont la vocation est d\u0026rsquo;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\u0026rsquo;ils sont dès aujourd\u0026rsquo;hui pertinents en Suisse ou en Allemagne, sont pratiquement inexistants en France.\nDe plus, un certain nombre de spécificités locales ou nationales peuvent amener à préciser l\u0026rsquo;usage ou la codification qui sera utilisée pour certaines informations. Par exemple, les Anglais disposant d\u0026rsquo;un référentiel national d\u0026rsquo;identification des points d\u0026rsquo;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.\nEnfin, certains éléments proposés par ces normes sont facultatifs et il convient, lors d\u0026rsquo;une implémentation, de décider si ces éléments seront ou non implémentés.\nL\u0026rsquo;utilisation des normes liées à l\u0026rsquo;implémentation de l\u0026rsquo;interopérabilité pour le transport en commun passe donc systématiquement par la définition d\u0026rsquo;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 :\n  détail des services utilisés,\n  détails des objets utilisés dans un échange,\n  précisions sur les options proposées par la norme,\n  précision sur les éléments facultatifs,\n  précision sur les codifications à utiliser,\n  etc.\n  Ce document présente la partie Éléments communs du profil France de NeTEx, tel que défini par le Groupe de Travail dédié à l\u0026rsquo;information voyageur et à l\u0026rsquo;exploitation des services de mobilité (GT7) au sein de la Commission Nationale de normalisation pour le transport public (CN03).\nD\u0026rsquo;autres parties du profil France de NeTEx sont disponibles (arrêts, réseau, horaire, tarif, accessibilité, parking). Ils sont tous complémentaires les uns des autres (sans recouvrement) et s\u0026rsquo;appuient tous sur cette partie.\nNOTE : Ce document étant un profil d\u0026rsquo;échange de NeTEx, il ne se substitue en aucun cas à NeTEx, et un minimum de connaissance de NeTEx sera nécessaire à sa bonne compréhension.\nNOTE IMPORTANTE : Le profil France est un sous-ensemble de la norme NeTEx et ne possède pas de schéma XML (XSD) dédié. Pour toute validation de fichiers, se référer à la XSD de NeTEx dans sa version v1.3.2 disponible sur GitHub.\nDomaine d\u0026rsquo;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.\nIl 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.).\nRéférences normatives Les documents de référence suivants sont indispensables pour l\u0026rsquo;application du présent document. Pour les références datées, seule l\u0026rsquo;édition citée s\u0026rsquo;applique. Pour les références non datées, la dernière édition du document de référence s\u0026rsquo;applique (y compris les éventuels amendements).\nCEN/ TS 16614-1, Network and Timetable Exchange (NeTEx) — Part 1: Public transport network topology exchange format\nEN 12896, Road transport and traffic telematics - Public transport - Reference data model (Transmodel)\nTermes et définitions Pour les besoins du présent document, les termes et définitions suivants s\u0026rsquo;appliquent. Une grande partie d’entre eux est directement issue de Transmodel, IFOPT et NeTEx.\nNOTE : Les définitions ci-dessus sont des traductions littérales du document normatif.\nAFFECTATION DE NOTE (NOTICE ASSIGNEMENT) (TRANSMODEL)\n Affectation d\u0026rsquo;une NOTE à un objet pour signaler une exception sur une COURSE, un PARCOURS. L\u0026rsquo;AFFECTATION DE NOTE permet de préciser les points ou les sections d\u0026rsquo;un parcours concerné par la NOTE\nAFFECTATION DE RÔLE (RESPONSIBILITY ROLE ASSIGNMENT) (NeTEx)\n Affectation d\u0026rsquo;un ou plusieurs RÔLEs à une INSTITUTION (ou une de ses sous-organisation) vis-à-vis des responsabilités à assurer concernant une donnée spécifique (comme la propriété, la planification, etc.) et de la gestion de cette donnée (diffusion, mise à jour, etc.).\n ALIAS (ALTERNATIVE NAME) (NeTEx)\n Nom alternatif pour un objet.\n ACCESSIBILITÉ (ACCESSIBILITY ASSESSMENT) (IFOPT)\n L\u0026rsquo;ACCESSIBILITÉ représente les caractéristiques d\u0026rsquo;accessibilité, pour les passagers, d\u0026rsquo;un SITE (comme un LIEU D\u0026rsquo;ARRÊT, un COMPOSANT DE LIEU D\u0026rsquo;ARRÊT, etc.). Elle est décrite par des limitations d\u0026rsquo;ACCESSIBILITÉ et/ou un ensemble de prise en compte d\u0026rsquo;exigences d\u0026rsquo;accessibilités.\n CONDITION DE VALIDITÉ (VALIDITY CONDITION) (TRANSMODEL)\n Condition concourant à caractériser une VERSION donnée appartenant à un CADRE DE VERSIONS. Une CONDITION DE VALIDITÉ est constituée d’un paramètre (ex : une certaine date, un certain événement déclencheur, etc.) et de son type d’application (Ex : « pour », « depuis », « jusqu’à », etc.).\n CONTACT (CONTACT DETAILS) (NeTEx)\n Information des contacts permettant au public de joindre une INSTITUTION (téléphone, mail, etc.).\n DÉCLENCHEMENT DE VALIDITÉ (VALIDITY TRIGGER) (TRANSMODEL)\n Un événement extérieur définissant une CONDITION DE VALIDITÉ. Par exemple : crue exceptionnelle, mauvais temps, route barrée pour travaux.\n ENTITÉ (ENTITY) (TRANSMODEL)\n Une occurrence d\u0026rsquo;entité qui est gérée par un système de gestion de versions. Quand des données de sources différentes coexistent dans un système (multimodal ou multi-opérateur), une ENTITÉ doit être associée à un SYSTÈME DE DONNÉES particulier qui l\u0026rsquo;a définie.\n ENTITÉ PAR VERSION (ENTITY IN VERSION) (TRANSMODEL)\n Les ENTITÉs associées à une VERSION spécifique.\n FINALITÉ DE GROUPEMENT (PURPOSE OF GROUPING) (TRANSMODEL)\n Un but fonctionnel pour lequel des GROUPEMENTs d\u0026rsquo;éléments sont définis. La FINALITÉ DE GROUPEMENT peut être limitée à un ou plusieurs types d\u0026rsquo;un objet donné.\n GROUPE D\u0026rsquo;ENTITÉS (GROUP OF ENTITIES) (TRANSMODEL)\n Un regroupement d\u0026rsquo;ENTITÉs, connu souvent des usagers par un nom spécifique ou un numéro.\n INSTITUTION (ORGANISATION) (NeTEx)\n Une instance légale impliquée dans certains aspects du transport public.\n MODE DE TRANSPORT (VEHICLE MODE) (TRANSMODEL)\n Le MODE DE TRANSPORT est une caractérisation du transport public correspondant au moyen (véhicule) de transport (bus, tram, métro, train, ferry, bateau, etc.).\n NOTE (NOTICE) (TRANSMODEL)\n Un texte à vocation informationnelle, en général concernant des exceptions d\u0026rsquo;utilisation (sans que cela ne soit une limitation), et rattaché à une LIGNE, un PARCOURS, etc.\nPOINT (TRANSMODEL)\n Un nœud de dimension 0 servant à la description spatiale du réseau. Les POINTs peuvent être localisés par la LOCALISATION dans un SYSTÈME DE LOCALISATION donné.\n SOURCE DE DONNEES (DATA SOURCE) (TRANSMODEL)\n La SOURCE DE DONNEES identifie le système qui a produit la donnée. La connaissance de la SOURCE DE DONNÉES est particulièrement utile dans le contexte de l\u0026rsquo;interopérabilité des systèmes d\u0026rsquo;information.\n SOUS MODE (SUB-MODE) (NeTEx)\n Le SOUS MODE est un complément d\u0026rsquo;information au MODE DE TRANSPORT, permettant généralement de caractériser le type d\u0026rsquo;exploitation (par exemple \u0026ldquo;bus interurbain\u0026rdquo; dans le cas d\u0026rsquo;un MODE DE TRANSPORT \u0026ldquo;bus\u0026rdquo;).\n SUITE DE TRONÇON (LINK SEQUENCE) (TRANSMODEL)\n Une suite ordonnée de POINTs ou TRONÇONs définissant un chemin à travers le réseau.\n TRONÇON (LINK) (TRANSMODEL)\n Un objet défini dans l\u0026rsquo;espace, orienté et de dimension 1, utilisé pour décrire la structure du réseau, définissant la connexion entre deux POINTs.\n VARIANTE DE DIFFUSION (DELIVERY VARIANT) (TRANSMODEL)\n Variante d\u0026rsquo;une NOTE pour une utilisation sur un média spécifique (texte lu, imprimé, etc.).\nVERSION (VERSION) (TRANSMODEL)\n Un ensemble de données opérationnelles qui sont caractérisées par les mêmes CONDITIONs DE VALIDITÉ. Une version appartient à un seul CADRE DE VERSIONS et est caractérisée par un unique TYPE DE VERSION, par exemple VERSION du réseau pour la ligne 12 à partir du 01-01-2000.\n ZONE (ZONE) (TRANSMODEL)\n Espace de dimension 2 (surface) au sein de la zone de couverture d\u0026rsquo;un opérateur de transport public (zone administrative, zone tarifaire, zone d\u0026rsquo;accès, etc.).\n Symboles et abréviations   AO : Autorité Organisatrice de Transports\n  PMR : Personne à Mobilité Réduite\n  Exigences minimales liées au code des transports et la réglementation européenne La mise à disposition des données, quand elles existent, est obligatoire et se conforme aux exigences :\n Au niveau européen, du règlement délégué (UE) 2017/1926 de la Commission du 31 mai 2017 modifié par le règlement délégué (UE) 2024/490 de la Commission du 29 novembre 2023 (https://eur-lex.europa.eu/eli/reg_del/2017/1926/2024-03-04), dit \u0026ldquo;règlement MMTIS\u0026rdquo; ; Au niveau français, des articles L. 1115-1 à L. 1115-7, D. 1115-1, R. 1115-2 à R. 1115-8 et D. 1115-9 à D. 1115-11 du code du transports, notamment créés ou modifiés par les articles 25 et 27 de loi n° 2019-1428 du 24 décembre 2019 d’orientation des mobilités, dites loi « LOM ». Ces mêmes articles de la LOM précise le calendrier de mise à disposition des données.  Le tableau ci-dessous résulte de l’analyse du code des transports et du règlement MMTIS et fournit la liste des concepts concernés dans le présent profil correspondant aux données mentionnées dans l’annexe du règlement. Il sera donc nécessaire de fournir ces données pour être conforme au cadre réglementaire (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).\nNotez que beaucoup de concepts dépendent des concepts issus de Transmodel/NeTEx et sont liés entre eux, soit par héritage, soit par relation au sens UML des termes. Par ailleurs, certains concepts additionnels peuvent relever d’autres parties du profil France, précisés dans le tableau le cas échéant.\nLa partie \u0026ldquo;Éléments Communs\u0026rdquo; n’est naturellement pas la première concernée par la réglementation. En effet, contrairement aux autres parties du profil France, elle propose essentiellement des éléments de construction (qui seront référencés par héritage ou par relation par les autres parties du profil France). Ces éléments ne sont pas directement liés aux besoins métiers. Toutefois elle 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.\nLes 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.\nPour 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).\nLa 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).\nLes 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).\nConcepts relatifs à la LOM et à la Règlementation Européenne     Niveau Catégorie Détail Concepts à minima Autres\nconcepts\n Commentaire    1 Trip plans Operational Calendar, mapping day types to calendar dates UicOperatingPeriod\nDAY TYPE SERVICE CALENDAR\nOPERATING DAY\nDAY TYPE ASSIGNMENT\nPROPERTY OF DAY\nOPERATING PERIOD    1 Trip plan computation — scheduled modes transport Transport operators OPERATOR ORGANISATION\nGROUP OF OPERATORS\nAUTHORITY    1 Trip plan computation — scheduled modes transport Hours of operation AVAILABILITY CONDITIONS\n(Profil Horaire)\nSERVICE JOURNEY\nTIMETABLE PASSING TIME\n        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\u0026rsquo;ê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.\nLes messages constituant ce profil d\u0026rsquo;é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:\n   Classifi­cation Nom Type Cardin­alité Description      Classification : permet de catégoriser l\u0026rsquo;attribut. Les principales catégories sont:\n  PK (Public Key) que l\u0026rsquo;on peut interpréter comme Identifiant Unique: il permet à lui seul d\u0026rsquo;identifier l\u0026rsquo;objet, de façon unique, pérenne et non ambiguë. C\u0026rsquo;est l\u0026rsquo;identifiant qui sera utilisé pour référencer l\u0026rsquo;objet dans les relations.\n  AK (Alternate Key) est un identifiant secondaire, généralement utilisé pour la communication, mais qui ne sera pas utilisé dans les relations.\n  FK (Foreign Key) indique que l\u0026rsquo;attribut contient l\u0026rsquo;identifiant unique (PK) d\u0026rsquo;un autre objet avec lequel il est en relation.\n  GROUP est un groupe XML nommé (ensemble d\u0026rsquo;attributs utilisables dans différents contextes)\n    Nom : nom de l\u0026rsquo;élément ou attribut XSD\n  Type : type de l\u0026rsquo;élément ou attribut XSD (pour certains d\u0026rsquo;entre eux, il conviendra de se référer à la XSD NeTEx)\n  Cardinalité : cardinalité de l\u0026rsquo;élément ou attribut XSD exprimée sous la forme \u0026ldquo;minimum:maximum\u0026rdquo; (\u0026ldquo;0:1\u0026rdquo; pour au plus une occurrence; \u0026ldquo;1:*\u0026rdquo; au moins une occurrence et sans limites de nombre maximal; \u0026ldquo;1:1\u0026rdquo; une et une seule occurrence; etc.).\n  Description : texte de description de l\u0026rsquo;élément ou attribut XSD.\nSeuls les attributs retenus par le profil ont un texte en français.\nLa description XSD utilisée est strictement celle de NeTEx, sans aucune modification (ceci explique notamment que tous les commentaires soient en anglais).\n  Les textes surlignés en jaune sont ceux présentant une particularité (spécialisation du profil France) par rapport à NeTEx : une codification particulière, une restriction d\u0026rsquo;usage, un changement de cardinalité, etc.\nLes attributs et éléments rendus obligatoires dans le cadre de ce profil restent facultatifs dans l\u0026rsquo;XSD (le contrôle de cardinalité devra donc être réalisé applicativement).\nValeurs 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;\n  Une énumération fixe définie dans le cadre du schéma XSD NeTEx. Le profil impose alors un sous-ensemble des codes NeTEx.\n  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\u0026rsquo;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»).\n  Instances TypeOfFrame: le profil utilise plusieurs TYPES DE FRAME pour spécifier l\u0026rsquo;utilisation de VERSION FRAME dans le profil.\n  Indication des classes abstraites NeTEx, et Transmodel, utilisent largement l\u0026rsquo;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».\nUn inconvénient de l\u0026rsquo;héritage est que si l\u0026rsquo;on veut comprendre les propriétés d\u0026rsquo;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.\n  Les super-classes sont signalées dans les en-têtes par le suffixe «(abstrait)»\n  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.\n  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.\n  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)».\nDataManagedObject 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.\nLe DataManagedObject est l’implémention des EntityInVersion, Version (plus le lien avec les Codespace) directement issus de Transmodel.\nEntity et Version – Modèle conceptuel\nDans 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\u0026rsquo;une ENTITY peuvent être définies ; normalement un ensemble de données donné contiendra une version particulière (mais il est également possible d\u0026rsquo;avoir plusieurs versions présentes dans le même ensemble de données si nécessaire).\nLes données exportées vers un document XML à partir d\u0026rsquo;un référentiel représentent un instantané de l\u0026rsquo;état d\u0026rsquo;une version particulière des données à un moment donné dans le temps. NeTEx s\u0026rsquo;intéresse principalement aux ENTITY IN VERSION de Transmodel. C\u0026rsquo;est-à-dire que les éléments de données d\u0026rsquo;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\u0026rsquo;une unique représentation de l\u0026rsquo;état actuel d\u0026rsquo;une ENTITY (plutôt que de tout son historique de versions), chaque fois qu\u0026rsquo;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\u0026rsquo;est-à-dire à différentes ENTITY IN VERSION.\nL\u0026rsquo;EntityInVersion est spécialisé sous le nom de DataManagedObject qui réunit é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.\nNeTEx utilise les Codespaces pour s\u0026rsquo;assurer que les identifiants des instances d\u0026rsquo;éléments dans un document XML sont uniques, même s\u0026rsquo;ils proviennent de nombreuses sources différentes – voir 7.3 - CODESPACE et codification des identifiants-.\nUne 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\u0026rsquo;objets.\nLe DataManagedObject permet l\u0026rsquo;attribution d\u0026rsquo;une version, des informations de responsabilité (et rôles associés) à une EntityInVersion ainsi qu\u0026rsquo;une ou plusieurs instances de ValidityCondition.\nDataManagedObject – Element (Abstrait)     Classifi­cation Nom Type  Description  :: :: EntityInVersion :: DATA MANAGED OBJECT hérite de ENTITY IN VERSION.  «FK» responsibilitySetRef ResponsibilitySetIdType 1:1 Pointe les roles et responsabilités associés au LIEU D'ARRÊT, à la ZONE D'EMBARQUEMENT ou à l'ACCÈS (généralisable à tous les objets, voir le modèle en 6.18).   KeyList KeyList 0:1 Ensemble de couples clé-valeur utilisé pour décrire les identifiants secondaires de l'objet (LIGNE, LIEU D'ARRÊT, ZONE D'EMBARQUEMENT, POINT D’ARRET PLANIFIÉ, COURSE, etc.): c’est-à-dire tel qu'il peut être identifié dans des systèmes tiers: billettique, information voyageur, etc. La clé permet de nommer l'identifiant (et donc de faire référence au système tiers), la valeur étant l'identifiant lui-même.\nCette identification servira principalement d'identification croisée, permettant au fournisseur de retrouver facilement, dans ses systèmes, l'origine de l'objet. \nLa liste des identifiants secondaires est spécifique à chaque fournisseur.\nVoir aussi PrivateCodedu GroupOfEntitiespour les identifiants alternatifs: les KeyList ne sont à utiliser que s'il y a plusieurs identifiants alternatifs, et si elles sont utilisées, le PrivateCodedoit impérativement être aussi renseigné.\nIl est interdit, dans le profil, d’utiliser le système de clé/valeur pour décrire des informations qui pourraient être fournies avec des attributs NeTEx existants (même s’ils ne sont pas retenus par le profil).\n   BrandingRef BrandingRefStructure 0:1 Référence à une marque (comme par exemple Navigo, Destineo, Oùra, etc.).   alternativeTexts AlternativeText 0:* Additional Translations of text elements.    Entity – Element (Abstrait)     Classifi­cation Nom Type  Description   NameOfClass NameOfClass :: Nom de la classe de l'ENTITÉ.  «PK» id ObjectIdType 1:1 Identifiant unique (et pérenne autant que possible) de l'objet.\nTous les objets métiers \"racine\" (c’est-à-dire les objets situés au niveau membersdes FRAME (voir 7.2) doivent impérativement être identifiés. Par contre les objets inclus (au sens XML) dans un un autre objet ne seront généralement pas identifiés (l'identification n'est toutefois pas interdite).\nCette remarque est valable pour la totalité des attributs du DataManagedObject (version, validité, etc. ne sont nécessaires que pour les objets racines).\n    EntityInVersion – Element (Abstrait)     Classifi­cation Nom Type  Description  :: :: Entity :: ENTITY ON VERSION hérite de ENTITY.  «FK» dataSourceRef DataSourceIdType 0:1 Identifiant de la source des données (voir INSTITUTION pour la description détaillée d'une source).   created xsd:dateTime 0:1 Date et heure de création de l'ENTITÉ   changed xsd:dateTime 0:1 Date et heure de la dernière modification de l'ENTITÉ   modification ModificationEnum 0:1 Nature de la dernière modification:\n• new (création)\n• revise (mise à jour)\n• delete (suppression)\n  «PK» version VersionIdType 0:1 Identifiant de version (généralement un numéro)   status VersionStatusEnum 0:1 Statut de la version:\n• active (objet actif)\n• inactive (objet non actif, de façon à pouvoir \"désactiver\" un objet pendant un certain temps sans pour autant le supprimer, par exemple pour un arrêt qui ne sera plus utilisé pendant quelques mois).\n  «FK» derivedFromObjectRef ObjectIdType 0:1 Identifiant d'une ENTITÉ dont celle-ci est dérivée.\nDans le contexte du profil, ce champ est utilisé uniquementpour lier des objets pour lesquels on a réalisé une variante fonctionnelle. Typiquement, dans le cas d'une ligne de substitution (voir Profil Réseau) on pourra utiliser le derivedFromObjectRef pour la relier à la ligne qu'elle remplace temporairement.\n  «FK» compatibleWith­VersionRef VersionIdType 0:1 Cet attribut est utilisé uniquement pour les CADREs DE VERSION (VERSION FRAME).\nIndique alors la version de l'instance de CADRE DE VERSION avec laquelle cette version d'objet est compatible. Ce CADRE DE VERSION porte le même identifiant que celui du cadre impliqué dans l'échange courant, mais avec un numero de version différent.\n  (choice) validityConditions ValidityCondition 0:* CONDITIONs DE VALIDITÉ de l’ENTITÉ.  ValidBetween ValidBetweenStructure 0:* Optimisation : version simplifiée de CONDITIONs DE VALIDITÉ (simple période entre deux dates)    KeyList – Element (Abstrait)     Classifi­cation Nom Type  Description   typeOfKey xsd:normalizedString 0:1 Type de clé.\nSeule la valeur \"ALTERNATE_IDENTIFIER\" est reconnue dans le cadre du profil. Tout autre type de type de clé devra être ignoré (sans toutefois générer d'erreur).\n   Key xsd:normalizedString 1:1 Nom de la clé .   Value xsd:normalizedString 1:1 Valeur associée à la clé    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.\nGroupOfEntities – Element (Abstrait)     Classifi­cation Nom Type  Description  :: :: DataManagedObject :: GROUP OF ENTITies hérite de DATA MANAGED OBJECT.   Name MultilingualString 0:1\n1:1\n Nom du groupe d'entité (du LIEU D'ARRÊT, de la ZONE D'EMBARQUEMENT, de l'ACCÈS, etc.)\nAttribut rendu obligatoire dans le cadre de ce profil\n   ShortName MultilingualString 0:1 Nom court du groupe d'entité (du LIEU D'ARRÊT, de la ZONE D'EMBARQUEMENT, de l'ACCÈS, etc.)   Description MultilingualString 0:1 Texte libre de description  «FK» PurposeOfGroupingRef PurposeOfGroupingRef 0:1 But fonctionnel pour lequel des GROUPEMENTs d'éléments sont définis. La FINALITÉ DE GROUPEMENT peut être limitée à un ou plusieurs types d'un objet donné.\nLe champ PurposeofGroupingRef devra systématiquement valoir \"groupOfStopPlace\" pour les GROUPEs DE LIEUX D'ARRÊT. \nDans le cas des groupes de lignes (GROUP OF LINES, voir Profil Réseau) le PurposeofGroupingRefpourra être utilisé pour qualifier les lignes administratives en utilisant la valeur \"administrativeLine\"\n  «AK» PrivateCode PrivateCode 0:1 Code \"privé\" permettant de gérer une identification spécifique indépendante de l'identification partagée. Si plusieurs identifiants alternatifs sont nécessaires, on pourra recourir au keyList de DataManagedObject, mais dans cette hypothèse le champ PrivateCode devra impérativement être aussi renseigné (avec l'un des identifiants alternatifs).\nCe champ est utilisé de différente façon suivant le contexte. C'est un simple identifiant alternatif pour les LIEU D'ARRÊT, ZONE D'EMBARQUEMENT, GROUPE DE LIEU et ACCÈS.\nDans le cadre des zones administratives (LIEU TOPOGRAPHIQUE) ce code est utilisé de la façon suivante:\n  Région : code NUTS\n  Département : code NUTS\n  Groupement de communes: code Postal\n  Ville : code INSEE\n  Arrondissement : code INSEE\n  Note: les codes NUTS peuvent être trouvés ici.\n  «ctd» (members) VersionOfObjectRef | GroupMember 0:1\nspécial\n Ce champ est apporté par GeneralGroupOfEntities et n'est utilisé que dans certains cas particuliers :\n Dans le cadre des GROUPEs DE LIEUX D'ARRÊT, et il est alors obligatoire. Il contient la liste des identifiants des membres des GROUPEs DE LIEUX D'ARRÊT (ce sont donc des identifiants de LIEU D'ARRÊT)      Attributs de Zone Zone – Element (Abstrait)     Classifi­cation Nom Type  Description  :: :: GroupOfPoints :: ZONE hérite de GROUP OF POINTs (note : le GroupOfPoint n’apporte pas d’autres ajouts au GroupOfEntities que l’attribut members spécialisé pour ne référencer que des points).\nLe champ members n’est utilisé que dans le cas particulier du transport à la demande, pour permettre d’identifier les arrêts (POINT D’ARRÊT PLANIFIÉs) d’une zone dans le cas de TAD zonal avec arrêt.\n  «cntd» members PointRef 0:* Liste des POINT contenus dans la ZONE.  «cntd» Centroid Point 0:1 Point représentatif de la ZONE (LIEU D'ARRÊT, ZONE D'EMBARQUEMENT, LIEU TOPOGRAPHIQUE, ACCES, POINT D’ARRÊT PLANIFIÉ, etc.).\nCe point n'a pas à être le centre, ou le barycentre, de la zone, mais un point qui la localisera de façon satisfaisante (sur un fond de carte par exemple).\n   Gml:Polygon gml:Polygon 0:* Polygone de contour de la zone.\nC'est une séquence ordonnée de points représentant une surface fermée et permettant de décrire le contour géographique de la ZONE.\n  «cntd» projections Projection 0:* Liste des PROJECTIONs de la ZONE.\nLa PROJECTION n’est utilisée que pour permettre de mettre en lien l’offre de transport en commun et une description de l’infrastructure (route, rail, etc.). On référencera donc typiquement un jeu de données OSM, NavTeQ Here, etc.\n    Attributs de Point Point – Element (Abstrait)     Classifi­cation Nom Type Cardinalité Description  :: :: DataManagedObject :: POINT hérite de DATA MANAGED OBJECT.   Name MultilingualString 0:1 Nom du POINT.   Location Location 0:1 1 :1\n Localisation du POINT (Obligatoire dans le profil France, notamment pour les objets de type QUAY et STOP PLACE. Attention, l'attribut n'est pas attendu dans les SCHEDULED STOP POINT)  «» PointNumber xsd:normalizedString 0:1 Identifiant alternatif du point POINT.\nOn utilisera le champ PointNumber pour ordonner des points (par exemple les POINTs D’ARRÊT PLANIFIÉs d’une ligne que l’on veut ordonner sur une fiche horaire), avec la convention suivante :\n On privilégiera une valeur purement numérique pour ce champ (avec un classement classique du plus petit au plus grand)\n Si ce n’était pas le cas le classement sera réalisé de façon alphanumérique (et non alphabétique), aussi appelé classement naturel, en intégrant donc une reconnaissance de l’éventuelle partie numérique. (voir http://rosettacode.org/wiki/Natural_sortingpar exemple)\n   «cntd» projections Projection 0:* Projections du POINT.\nLa PROJECTION n’est utilisée que pour permettre de mettre en lien l’offre de transport en commun et une description de l’infrastructure (route, rail, etc.). On référencera donc typiquement un jeu de données OSM, NavTeQ Here, etc.\n    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).\nLink – Element (Abstrait)     Classifi­cation Nom Type Cardinalité Description  :: :: DataManagedObject :: LINK hérite de DATA MANAGED OBJECT.   Name MultilingualString 0:1 Nom du TRONÇON.   Distance DistanceType 0:1 Longueur du TRONÇON (unité en cohérence avec l’unité par défaut des frames, en mètre pour la France naturellement).\nIl ne s'agit pas de la simple distance \"à vol d'oiseau\" entre les deux extrémités, mais de la distance opérationnelle que l'on souhaite faire porter au TRONÇON, comme la distance qui sera parcourue par un véhicule sur ce TRONÇON par exemple.\n  «cntd» LineString gmlLineString 0:1 Géométrie du TRONÇON sous forme d’une linestring GML (la géométrie d’un TRONÇON n’est donc pas limitée à un simple couple de point, mais est décrite par une séquence de points).  «cntd» projections   La PROJECTION n’est utilisée que pour permettre de mettre en lien l’offre de transport en commun et une description de l’infrastructure (route, rail, etc.). On référencera donc typiquement un jeu de données OSM, NavTeQ Here, etc.\nDans le cas des TRONÇONs la projection n’est généralement pas simple un TRONÇON ne se projetant généralement pas sur un unique autre TRONÇON (on aura presque systématiquement un TRONÇON TC à cheval sur N tronçon routier, ou encore l’inverse) : il a donc été fait le choix de ne projeter que les point extrémités du TRONÇON (ces point peuvent se projeter sur un autre point, ou sur un segment).\n  «cntd» passingThrough   Le besoin de points intermédiaires est lié soit à une géométrie complexe (on utilisera alors l’attribut LineString) soit au fait que, par exemple, un TRONÇON sur un PARCOURS passe par un arrêt sans s’y arrêter, mais on utilisera dans ce cas les éléments du PARCOURS dédiés à la description de cette situation.  uniquement dans les spécialisations concrètes de Link FromPointRef xxxPoint (spécialisation de Point) 1:1 Point de depart du segment (uniquement dans les spécialisations concrètes de Link)  ToPointRef xxxPoint (spécialisation de Point) 1:1 Point de fin du segment (uniquement dans les spécialisations concrètes de Link)    Attributs des Séquences de Tronçons Les SÉQUENCEs DE TRONÇONS sont des éléments de base pour la construction d\u0026rsquo;objets plus complexes comme les ITINÉRAIREs (voir Profil Réseau).\nLinkSequence – Element (Abstrait)    Classifi­cation Name Type Cardin­ality Description     ::\u0026gt; ::\u0026gt; DataManagedObject ::\u0026gt; LINK SEQUENCE hérite de DataManagedObject.    Name MultilingualString 0:1 Nom de la SÉQUENCE DE TRONÇON.    Distance DistanceType 0:1 Longueur totale (en mètre) de la SÉQUENCE DE TRONÇON.    sectionsInSequence SectionInSequence 0:* Liste ordonnée de TRONÇONs.    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.\nPointInLinkSequence – Element (Abstrait)    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; VersionedChild ::\u0026gt; POINT IN LINK SEQUENCE hérite de VERSIONED CHILD.   «atr» order *xsd:*positiveInteger 1:1 Ordre du POINT au sein de la séquence (la valeur de début est sans importance seules comptent les valeurs relatives entre elles).   «FK» LinkSequenceRef LinkSequenceRef 1:1 Référence de la LINK SEQUENCE contenant le POINT IN LINK SEQUENCE.    Description MultilingualString 0:1 Description du POINT in LINK SEQUENCE. +v1.1    Conditions de validité La validité se définit comme la période pendant laquelle, ou les conditions en fonction desquelles l\u0026rsquo;ENTITÉ peut être utilisée par les voyageurs.\nNOTE : le LIEU D\u0026rsquo;ARRÊT ou l\u0026rsquo;ACCÈS peut aussi être sujet à des heures d\u0026rsquo;ouverture, mais ces plages d\u0026rsquo;ouverture sont potentiellement multiples au sein d\u0026rsquo;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\u0026rsquo;ARRÊT ou à l\u0026rsquo;ACCÈS dans ce cas).\nLa 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.\nValidBetween – Element (objet inclus)     Classifi­cation Nom Type  Description   FromDate xsd:dateTime 0:1 Date et heure de début de validité (inclusif)\nLe FromDateest obligatoire dans le cadre du profil (le ToDatene l’est pas, et s’il n’est pas rempli, la validité débute au FromDatesans limite de fin.   ToDate xsd:dateTime 0:1 Date et heure de fin de validité (inclusif)    ValidityCondition – Element (objet inclus)     Classifi­cation Nom Type Cardinalité Description  :: :: DataManagedObject :: Inherits from DATA MANAGED OBJECT.\nL’héritage reste naturellement valable, mais aucun des attributs qu’il apporte ne sera utilisé.\n   Name MultilingualString 0:1 Nom de la VALIDITY CONDITION   Description MultilingualString 0:1 Description de la VALIDITY CONDITION  «FK» ConditionedObjectRef ObjectRef 0:1 Référence de l’objet sur lequel porte la CONDITION DE VALIDITÉ.\nCet attribut n’est utilisé que si la condition de validité est fournie comme un objet indépendant au sein d’une FRAME (voir 7.2). Dans tous les autre cas (la CONDITION DE VALIDITÉ est dans l’arborescence XML d’un objet) c’est le contexte qui fournit cette information, et ce champ sera ignoré. On n’utilisera les conditions de validité comme un objet indépendant que pour pouvoir les référencer avec un WithConditionRef (champ suivant)\n  «FK» WithConditionRef ValidityConditionRef 0:1 Cet attribut permet de chaîner plusieurs CONDITIONs DE VALIDITÉ qui seront alors logiquement combinées par l’opérateur logique ET.\nOn pourra ainsi gérer une période combinée à des exclusions, combiner des périodes et des évènements déclencheurs, etc.\nPour la gestion des exceptions, on exprimera toujours une CONDITION DE VALIDITÉ « principale » et on y associera des exceptions par WithConditionRefet non l’inverse. Pour toutes les combinaisons on procédera de même si une CONDITION DE VALIDITÉ « principale » peut être identifiée.\n    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.)\nAvailabilityCondition – Element (objet inclus)     Classifi­cation Nom Type Cardinalité Description  :: :: ValidityCondition :: AVAILABILITY CONDITION hérite de VALIDITY CONDITION.   FromDate xsd:dateTime 0:1 Date et heure de début de validité (inclusif)   ToDate xsd:dateTime 0:1 Date et heure de fin de validité (inclusif)   IsAvailable xsd:boolean 1:1 Indique si la CONDITION DE VALIDITÉ correspond à une disponibilité (VRAI) ou une indisponibilité (FAUX).\nCe champ sert principalement à exprimer les exceptions (par exemple : sauf le 1er avril) par combinaison de CONDITIONs DE VALIDITÉ avec WithConditionRef (voir plus haut).\n  «FK» dayTypes DayTypeRef 0:* TYPE DE JOUR pendant lesquels la CONDITIONs DE VALIDITÉ s’applique.\nOn n’utilisera pas simultanément et operatingDaysdans une même CONDITION DE VALIDITÉ.\n  «cntd» timeBands TimeBand 0:* TRANCHEs HORAIREs pendant lesquelles la CONDITIONs DE VALIDITÉ s’applique.\nPermet essentiellement d’exprimer les heures d’ouverture.\n  «cntd» operatingDays OperatingDay 0:* Jours d’exploitation pendant lesquels la CONDITIONs DE VALIDITÉ s’applique.\nOn n’utilisera pas simultanément et operatingDaysdans une même CONDITION DE VALIDITÉ.\n    ValidityTrigger – Element (objet inclus)     Classifi­cation Nom Type Cardinalité Description  :: :: ValidityCondition :: VALIDITY TRIGGER hérite de VALIDITY CONDITION.  «FK» TriggerObjectRef ObjectRef 0:1 Référence (identifiant) de l’objet déclencheur de la validité.\nDe façon pratique, plutôt que de réel identifiant d’objet, on utilisera ici des valeurs codifiées dont les valeurs possibles seront précisées dans les spécifications d’interface du système producteur. Par convention on utilisera autant que possible les codes reason, subreasonet PublicEventproposés par le service SIRI Situation Exchange.\n    Accessibilité Les informations concernant l\u0026rsquo;ACCESSIBILITÉ sont utilisées de la même façon pour les LIEUx D\u0026rsquo;ARRÊT, les LIGNEs, les COURSEs, etc. L’information d’accessibilité présentée correspond à une information minimale lorsque les ÉVALUATIONs D’ACCESSIBILITÉ (ACCESSIBILITY ASSESSMENT) sont utilisées. Pour plus d\u0026rsquo;information sur les éléments retenus dans le profil France, se référer à la partie Accessibilité du profil France de NeTEx. Cette dernière propose, en outre, des éléments de description d\u0026rsquo;accessibilité plus détaillés, ainsi que l\u0026rsquo;identification des attributs obligatoires pour se conformer à la réglementation en vigueur.\nNom alternatif AlternativeName – Element     Classifi­cation Nom Type  Description  «FK» NamedObjectRef VersionOfObjectRef 0:1 Référence de l’objet pour lequel on fourni un nom alternatif.\nCet attribut n’est utilisé que si le nom alternatif est fourni comme un objet indépendant au sein d’une FRAME (voir 7.2). Dans tous les autre cas (le NOM ALTERNATIF est dans l’arborescence XML d’un objet) c’est le contexte qui fournit cette information, et ce champ sera ignoré.\n   Lang Language 0:1 Langue utilisée pour ces alias (codification RFC 1766)   NameType NameTypeEnum 0:1 Type de nom alternatif:\n alias: Alias\n translation: Traduction\n other: Autre\n  Il existe deux autres possibilités qui ne sont pas utilisées dans le cadre du profil: copy et label\n   TypeOfName NormalizedString 0:1 Description de type de nom (ex: \" Libellé de la synthèse vocale \")   Name MultilingualString 1:1 Texte du nom alternatif   ShortName MultilingualString 0:1 Version courte du nom alternatif   Abbreviation MultilingualString 0:1 Abréviation du nom alternatif   QualifierName MultilingualString 0:1 Texte utilisé pour qualifier le nom (\"gare de\", \"mairie de\", etc.)    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\u0026rsquo;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.\nNote: 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).\nDans le profil, AlternativeText sera toujours utilisé comme balise incluse (et non comme élément racine).\n AlternativeText – XML Element      Classification Nom Type  Description  :: :: VersionedChild :: AlternativeText hérite de VERSIONED CHILD.  «PK» attributeName xsd:NCName 0:1 Nom de l'attribut de texte pour lequel il s'agit du texte de remplacement. Doit être un nom d'attribut existant.  «PK» useForLanguage xsd:language 0:1 Langage utilisé pour cette variante\n« fr » n’est pas accepté dans le profil, AlternativeTextétant réservé aux traductions.\n   Text MultilingualString (Language + Text) 1:1 Variante du texte original, dans le langage spécifié    Localisation (Location) Location – Element (abstrait)     Classifi­cation Nom Type  Description  «FK» srsName LocatingSystemNameType 0:1 Référentiel géographique: il s'appliquera aux Latitude et Longitude (permettant ainsi d'utiliser d'autres référentiels géodésiques que WGS84).\nÀ utiliser au format GML (ex urn:ogc:def:crs:EPSG::4326 pour WGS84, voir http://www.epsg.org et http://www.opengeospatial.org/ogcUrnPolicy )\n   Longitude LongitudeType 1:1 Latitude du centroïd (point \"central\" du lieu d'arrêt) – WGS84 par défaut (-180 à +180)   Latitude LatitudeType 1:1 Longitude du centroïd (point \"central\" du lieu d'arrêt) – WGS84 par défaut (-90 à +90)   Altitude AltitudeType 0:1 Altitude du centroïd (mètres au-dessus du niveau de la mer)   Coordinates CoordinateString gml:pos 0:1 Localisation dans un référentiel géographique quelconque (format ISO/OGC) exprimé sous forme d'une chaine de caractère, contenant éventuellement le référentiel de projection (si différent du champ suivant SrsName).\nExemple: -59.478340 -52.226578\n   Precision xsd:decimal 0:1 Précision de localisation (en mètres).    Cas des surfaces Les ZONEs, en plus d\u0026rsquo;être géolocalisés par un point représentatif (centroïd) peuvent être représentées par une surface d\u0026rsquo;emprise. Cette surface s\u0026rsquo;exprime sous la forme d\u0026rsquo;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).\nPolygon – XSD\nSeul le contour extérieur de ce polygone (exterior) est retenu dans le cadre du présent profil.\nEXEMPLE un polygone de contour de LIEU D\u0026rsquo;ARRÊT pourra donc, par exemple, prendre la forme ci-dessous\n\u0026lt;gml:Polygon gml:id=\u0026quot;12323\u0026quot;\u0026gt; \u0026lt;gml:exterior\u0026gt; \u0026lt;gml:LinearRing\u0026gt; \u0026lt;gml:pos\u0026gt;-120.000000 65.588264\u0026lt;/gml:pos\u0026gt; \u0026lt;gml:pos\u0026gt;-120.003571 65.590782\u0026lt;/gml:pos\u0026gt; \u0026lt;gml:pos\u0026gt;-120.011292 65.590965\u0026lt;/gml:pos\u0026gt; \u0026lt;gml:pos\u0026gt;-120.022491 65.595215\u0026lt;/gml:pos\u0026gt; \u0026lt;gml:pos\u0026gt;-120.031212 65.592880\u0026lt;/gml:pos\u0026gt; \u0026lt;gml:pos\u0026gt;-120.019363 65.586121\u0026lt;/gml:pos\u0026gt; \u0026lt;gml:pos\u0026gt;-120.030350 65.585365\u0026lt;/gml:pos\u0026gt; \u0026lt;/gml:LinearRing\u0026gt; \u0026lt;/gml:exterior\u0026gt; \u0026lt;/gml:Polygon\u0026gt; Attributs d\u0026rsquo;Addresse Address – Element (objet inclus)    Classifi­cation Nom Type  Description     «FK» CountryRef CountryEnum 0:1 Code ISO 3166 du pays (deux caractères)    CountryName MultilingualString 0:1 Nom du pays    PostalAddress – Element (objet inclus) L\u0026rsquo;objet PostalAddress de NeTEx contient de nombreux attributs mais le profil France choisit de n\u0026rsquo;en prioriser que certains afin de trouver le juste équilibre entre les 3 axes suivants :\n production des données par ceux n\u0026rsquo;ayant pas nécessairement une donnée structurée (exemple de Open Trip Planner (OTP) lisant des données OpenStreetMap (OSM)), consommation des données de manière uniforme et si possible structurée, besoin de rester cohérent avec les modèles utilisés par les autres pays.  Pour cette raison, les champs HouseNumber, Street et BuildingName ne sont pas priorisés dans le profil France. Ils peuvent être utilisés quand l\u0026rsquo;information existe, elle sera alors considérée comme venant compléter les attributs priorisés. Il est donc recommandé d\u0026rsquo;utiliser en priorité le champ AddressLine1 en n\u0026rsquo;indiquant si possible que les numéros et le nom de la rue, en évitant d\u0026rsquo;inclure les noms ou codes des batiments. Ce champ libre permettra dans certains cas d\u0026rsquo;indiquer les informations nécessaire quand aucune adresse n\u0026rsquo;existe (par exemple un arrêt à un croisement de routes en inter-urbain).\n   Classifi­cation Nom Type  Description     ::\u0026gt; ::\u0026gt; Address ::\u0026gt; POSTAL ADDRESS hérite de ADDRESS.    AddressLine1 xsd:normalizedString 0:1 Numéro et rue de l\u0026rsquo;adresse. Le num du batiment peut également être précisé. Ce champ retenu dans le profil France comme porteur de l\u0026rsquo;information de l\u0026rsquo;adresse (voir explication ci-dessus)     HouseNumber xsd:normalizedString 0:1 Numéro du bâtiment sur la voie. Ce champ vient compléter le champ AddressLine1    Street xsd:normalizedString 0:1 Nom et type de voie. Ce champ vient compléter le champ AddressLine1    BuildingName xsd:normalizedString 0:1 Nom du bâtiment. Ce champ vient compléter le champ AddressLine1    Town MultilingualString 0:1 Nom de la ville    PostCode PostCodeType 0:1 Code Postal    PostCode­Extension xsd:normalizedString 0:1 Extension du code postal (avec éventuel cedex ou boite postale)    PostalRegion MultilingualString 0:1 Code INSEE. NOTE : le code INSEE permet aussi de faire la liaison avec la ville ou l\u0026rsquo;arrondissement (en tant que zone administrative) d\u0026rsquo;appartenance.    Exemple de fourniture d\u0026rsquo;adresse dans le profil France : L\u0026rsquo;adresse postale suivant :\n Bâtiment B\n5 Allée des Pirouettes\n31420 Bouzin\n Peut s\u0026rsquo;exporter de la manière suivante :\n\u0026lt;PostalAddress\u0026gt; \u0026lt;AddressLine1\u0026gt;5 Allée des Pirouettes\u0026lt;/AddressLine1\u0026gt; \u0026lt;PostCode\u0026gt;31420\u0026lt;/PostCode\u0026gt; \u0026lt;Town\u0026gt;Bouzin\u0026lt;/Town\u0026gt; \u0026lt;/PostalAddress\u0026gt; ou dans une version plus complète :\n\u0026lt;PostalAddress\u0026gt; \u0026lt;AddressLine1\u0026gt;Bâtiment B, 5 Allée des Pirouettes\u0026lt;/AddressLine1\u0026gt; \u0026lt;BuildingName\u0026gt;Bâtiment B\u0026lt;/BuildingName\u0026gt; \u0026lt;HouseNumber\u0026gt;5\u0026lt;/HouseNumber\u0026gt; \u0026lt;Street\u0026gt;Allée des Pirouettes\u0026lt;/Street\u0026gt; \u0026lt;PostCode\u0026gt;31420\u0026lt;/PostCode\u0026gt; \u0026lt;Town\u0026gt;Bouzin\u0026lt;/Town\u0026gt; \u0026lt;/PostalAddress\u0026gt; RoadAddress – Element (objet inclus)     Classifi­cation Nom Type  Description  :: :: Address :: ROAD ADDRESS hérite de ADDRESS.   GisFeatureRef normalizedString  Identification de l'objet correspondant à la voie dans une base spatiale (type PostGIS par exemple) ou dans un SIG.\nCet attribut permettra par exemple d'établir le lien avec une base IGN, Open Street Map, NavTeq, Teleatlas, etc.\n   RoadNumber xsd:normalizedString 0:1 Nom de la voie sous forme codifiée (exemple: N20, A1, E11, D75, etc.)   RoadName xsd:normalizedString 0:1 Nom de la voie.   BearingDegrees xsd:integer 0:1 Orientation de la voie, en degrés (au niveau du LIEU d'ARRÊT, de la ZONE D'EMBARQUEMENT ou de l'ACCÈS).   OddNumber­Range xsd:normalizedString 0:1 Plage de numéros impairs dans laquelle se situe le LIEU   EvenNumber­Range xsd:normalizedString 0:1 Plage de numéros pairs dans laquelle se situe le LIEU\nNOTE si la parité, droite-gauche, n'est pas respectée, c'est la zone paire qui sera renseignée.\n    Locale (contexte local du lieu) Si cette information peut être portée par chaque objet, il est généralement plus pertinent de l\u0026rsquo;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\u0026rsquo;objet particulier sera utilisée pour celui-ci.\nLocale – Type (objet inclus)    Classifi­cation Nom Type  Description      TimeZoneOffset TimeZoneOffset 0:1 Décalage horaire (positif ou négatif) par rapport à l\u0026rsquo;heure GMT    TimeZone TimeZoneOffset 0:1 Nom de la zone horaire    SummerTimeZoneOffset TimeZoneOffset 0:1 Décalage horaire (positif ou négatif) par rapport à l\u0026rsquo;heure GMT, pour l\u0026rsquo;heure d\u0026rsquo;été    DefaultLanguage xsd:language 1:1 Langue principale (codification RFC 1766)    languages LanguageUsage 0:* Autres langues utilisées (codification RFC 1766)    Projections Les projections sont exclusivement utilisées pour projeter les objets du transport public sur leur infrastructure (voirie, rail, voies navigables et câbles).\nLes 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.\nSeules 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).\nLes projections, telles qu\u0026rsquo;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.\nLe 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\n\u0026lt;Codespace id=\u0026quot;*osm*\u0026quot;\u0026gt; \u0026lt;Xmlns\u0026gt;*osm*\u0026lt;/Xmlns\u0026gt; \u0026lt;XmlnsUrl\u0026gt;*http://planet.openstreetmap.org/planet/2014/*\u0026lt;/XmlnsUrl\u0026gt; \u0026lt;Description\u0026gt;Open Street Map through Planet OSM\u0026lt;/Description\u0026gt; \u0026lt;/Codespace\u0026gt; Une référence à un objet OSM pourra alors avoir la forme ref=osm:4701234567\nMais cela ne sera souvent pas suffisant et il faudra compléter cette référence par d\u0026rsquo;éventuelles informations de classe, de version et de date proposé par le mécanisme de référence de NeTEx.\nAttributs pour les références externes (objet inclus)     Classifi­cation Nom Type Cardinalité Description   NameOfRefClass NameOfClass 0:1 Nom de la classe de l'objet référencé   created xsd:dateTime 0:1 Date à laquelle la référence a été créée: ATTENTION il ne s'agit pas ici de la date de création de l'objet, mais bien de la date à laquelle la référence a été créée. Cela permettra, en cas d'absence de mécanisme de version, de retrouver la version de l'objet considérée (dernière version à la date du…).  «FK» version VersionRef 0:1 Version de l'objet référencé.\nSi les objets n'ont pas de version, mais que le jeu de donnée en a, on utilisera le CODESPACE en prefixe (ainsi versionRef='TeleAtlas:MapMarker_USA_v04_Data/USA_TPT_2014_09' pourra référer un jeu de données TeleAtlas (en ayant pris soin de créer le CODESPACE TeleAtlas au préalable, sur le principe indiqué ci-dessus).\nLe référencement de la version de l'objet n'est naturellement pas obligatoire: si elle est absente on considère qu'il s'agit de la version courante.\nPour les références externe, on procèdera comme indiqué en 7.5 - Version des objets et références en precisant la version pointée grace à l’attribut versionRef (par exemple versionRef=\"1.01:FR-NETEX_COMMUN-1.0\")\n  «FK» ref ObjectRefObjectIdType 1:1 Identifiant de l'objet référencé précédé de son CODESPACE.    PointProjection – Element     Classifi­cation Nom Type Cardinalité Description  «FK» ProjectedPointRef PointRef 0:1 POINT projeté.\nCet attribut n’est utile que si la projection est fournie comme un objet indépendant au sein d’une FRAME (voir 7.2). Dans tous les autres cas (la PROJECTION est dans l’arborescence XML d’un objet) c’est le contexte qui fournit cette information, et ce champ sera ignoré.\n  «FK» ProjectToPointRef PointRef 0:1 POINT sur lequel on se projette.\nDans le contexte des profils NeTEx, il s'agit là d'une référence vers une donnée externe (OSM, Nokia Here (ex Navteq), Tomtom TeleAtlas, IGN, INSPIRE, etc.).\nLa codification respectera les règles décrites ci-dessus pour les références externes.\n  «FK» ProjectToLinkRef LinkRef 0:1 TRONÇON sur lequel on se projette (un POINT peut être projeté sur un TRONÇON).   Distance LengthType 1:1 Distance entre le POINT projeté et le début du TRONÇON (ce champ n'est renseigné que si le précédent l'est aussi).    ZoneProjection – Element     Classifi­cation Nom Type Cardinalité Description  «FK» ProjectedZoneRef ZoneRef 0:1 ZONE that is being projected.\nCet attribut n’est utile que si la projection est fournie comme un objet indépendant au sein d’une FRAME (voir 7.2). Dans tous les autre cas (la PROJECTION est dans l’arborescence XML d’un objet) c’est le contexte qui fournit cette information, et ce champ sera ignoré.\n  «FK» ProjectedToZoneRef ZoneRef 0:1 ZONE sur lequel on se projette.\nDans le contexte des profils NeTEx, il s'agit là d'une référence vers une donnée externe (OSM, Nokia Here (ex Navteq), Tomtom TeleAtlas, IGN, INSPIRE, etc.).\nLa codification respectera les règles décrites ci-dessus pour les références externes.\n  «FK» ProjectToPoint­Ref LinkRef 0:1 POINT sur lequel on se projette (une ZONE peut être projeté sur un POINT: centroïde de ZONE, pictogramme, etc.).    Enumérations pour les modes et sous-modes Les modes La liste des modes utilisés est la suivante (version anglaise d\u0026rsquo;origine et traduction):\nModes\nLes sous modes Le mode peut de plus être complété d\u0026rsquo;une caractéristique appelée \u0026ldquo;sous mode\u0026rdquo; qui, plus que le type du véhicule, caractérise le type d\u0026rsquo;exploitation qui est mis en place (navette, train régional, etc.). La figure ci-dessous présente l\u0026rsquo;ensemble des modes normalisés.\nSous modes\nPar souci de clarté, les sous-modes ont été classés en relation avec un mode, toutefois le sous-mode \u0026ldquo;tramTrain\u0026rdquo; peut être utilisé indifféremment avec un mode Tram ou un mode Train (Ferré, auquel cas il faut l\u0026rsquo;interprété \u0026ldquo;trainTram\u0026rdquo;).\nBusSubmodeEnum    Nom Description     localBus Bus local   regionalBus Bus régional   expressBus Bus express   nightBus Bus de nuit   specialNeedsBus Bus pour besoins spéciaux   mobilityBus Bus pour handicapé   sightseeingBus Bus panoramique   shuttleBus Bus navette   highFrequencyBus Bus à haute fréquence   dedicatedLaneBus Bus en site propre   schoolBus Bus scolaire   schoolAndPublicServiceBus Bus scolaire et service régulier   railReplacementBus Bus de substitution   demandAndResponseBus Bus transport à la demande   airportLinkBus Bus de terminal aéroportuaire    CoachSubmodeEnum    Nom Description     internationalCoach Car international   nationalCoach Car national   shuttleCoach Navette   regionalCoach Car régional   specialCoach Car spécial   schoolCoach Car scolaire   sightseeingCoach Car touristique avec circuit   touristCoach Car touristique général   commuterCoach Car pour trajets pendulaires    MetroSubmodeEnum    Nom Description     metro Métro    RailSubmodeEnum     Nom Description  local Train local  highSpeedRail Train à grande vitesse\nVoir ERA B.4.7009 - 8 high speed train: Long distance train formed by a unit capable for high speed running on high speed or normal lines most modern train unit.\n  suburbanRailway Train de banlieue\nVoir ERA B.4.7009 - 12 subUrban: Regional train organised by the regional government public transport in and around cities, running on its own freeways underground or overground, operational running with signals.\n  regionalRail Train régional\nSee ERA B.4.7009 - 11 Regional: Regional train organised by the regional government even if formed by a unit capable for high speed running on high speed lines.\n  interregionalRail Train interrégional\nVoir ERA B.4.7009 - 10 Interregional: Regional train running in more than one region.\n  longDistance Train longue distance\nSee ERA B.4.7009 - 9 Intercity: Long distance train formed by a unit capable for high speed or not running on high speed or normal lines modern train unit high quality service restricted stopping pattern.\n  intermational Train international  nightTrain Train de nuit\nVoir ERA B.4.7009 - 13 Night train: Long distance train running overnight offering sleeping facilities (beds and or couchettes).\n  sleeperRailService Service de train couchette  carTransportRailService Service de train de transport de voiture\nVoir ERA B.4.7009 - 14 Motor rail: Service transporting passenger's motor vehicle passengers are admitted either with vehicle only or with or without vehicle. Service mode.\n  touristRailway Train touristique\nVoir ERA B.4.7009 - 16 Historic train.\n  railShuttle Train navette  rackAndPinionRailway Train à crémallière\nVoir ERA B.4.7009 - 15 Mountain train: Local train adapted for running in mountain railway lines.\n    TramSubmodeEnum    Nom Description     cityTram Tram urbain   localTram Tram local   sightseeingTram Tram panoramique   shuttleTram Tram navette   tramTrain TramTrain: Tram pouvant circuler d\u0026rsquo;un réseau de tramway urbain vers des voies de chemin de fer partagées avec des trains conventionnels.    TelecabinSubmodeEnum    Nom Description     telecabin Télécabine   cableCar Téléphérique    FunicularSubmodeEnum    Nom Description     funicular Funiculaire    AirSubmodeEnum    Nom Description     internationalFlight Vol international   domesticFlight Vol national   intercontinentalFlight Vol intercontinental    WaterSubmodeEnum    Nom Description     internationalCarFerry Ferry international   nationalCarFerry Ferry national   regionalCarFerry Ferry régional   localCarFerry Ferry local   internationalPassengerFerry Ferry de transport de passagers international (pas de véhicules)   nationalPassengerFerry Ferry de transport de passagers national (pas de véhicules)   regionalPassengerFerry Ferry de transport de passagers régional (pas de véhicules)   localPassengerFerry Ferry de transport de passagers local   riverBus Bateau-bus sur fleuve ou rivière    Institutions L\u0026rsquo;INSTITUTION (ORGANISATION) représente une entreprise impliquée dans la planification, la collecte ou la fourniture d\u0026rsquo;informations sur les transports en commun. Par exemple, une entreprise fournissant un service d\u0026rsquo;informations sur les transports publics, une autorité, un opérateur ou une entreprise fournissant un service de collecte d\u0026rsquo;informations.\nDans le profil, elle est essentiellement utile en tant que superclass d\u0026rsquo;OPÉRATEUR et d\u0026rsquo;AUTORITÉ.\nORGANISATIONs et responsabilité – Modèle conceptuel\nOrganisation – Element     Classifi­cation Nom Type  Description  :: :: DataManagedObject :: ORGANISATION hérite de DATA MANAGED OBJECT.  «AK» PublicCode xsd:normalizedString 0:1 Identifiant (code) public de l'INSTITUTION (exemples: STIF, SNCF, etc.)  «AK» CompanyNumber xsd:normalizedString 0:1 Numéro d'enregistrement de l'institution (type code transporteur affecté par l'AO, NAO de la norme 99-502 pour les AOT, etc.)   Name xsd:normalizedString 0:1 Nom de l'ORGANISATION   ShortName MultilingualString 0:1 Nom court de l'ORGANISATION   LegalName MultilingualString 0:1 Nom légal de l'ORGANISATION  «cntd» alternativeNames AlternativeName 0:* Nom alternative pour l’ORGANISATION.\nNote: les éventuelles traductions utiliseront AlternativeText et non alternativeNames.\n   Description MultilingualString 0:1 Texte descriptif associé à l'INSTITUTION.   ContactDetails ContactDetails 0:1 Contact details for ORGANISATION for public use.  «FK» OrganisationType TypeOfOrganisationEnum 0:1\n1:1\n Type d'organisation codifié:\n authority : Autorité organisatrice\n operator : Exploitant\n railOperator : Exploitant Ferré\n railFreightOperator : Exploitant fret\n statutoryBody : Collectivité\n facilityOperator : Société de service\n travelAgent : Agence de voyage\n servicedOrganisation : Etablissement de service public\n other : Autre\n   «cntd» parts OrganisationPart 0:* Ensemble des entités constituant ou faisant partie de l'INSTITUTION (UNITÉ ORGANISATIONELLE ou DÉPARTEMENT).\nSeules les UNITÉs ORGANISATIONELLEs seront utilisées dans le cadre des profils NeTEx.\n    ContactDetails – Element (objet inclus)    Classifi­cation Nom Type  Description      ContactPerson xsd:normalizedString 0:1 Nom de la personne de contact.    Email EmailAddressType 0:1 Email de contact au format ISO.    Phone PhoneNumberType 0:1 Numéro de téléphone de contact    Fax PhoneNumberType 0:1 Numéro de fax    Url xsd:anyURI 0:1 Site web de contact et d\u0026rsquo;information    FurtherDetails xsd:string 0:1 Information en texte libre    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.\nOrganisationalUnit – Element    Classifi­cation Name Type Cardin­ality Description     ::\u0026gt; ::\u0026gt; OrganisationPart ::\u0026gt; ORGANISATIONAL UNIT hérite de ORGANISATION PART.    OrganisationPart – Element (abstrait pour le profil)     Classifi­cation Name Type Cardin­ality Description  :: :: DataManagedObject :: ORGANISATION PART hérite de DATA MANAGED OBJECT.   Name MultilingualString 0:1 Nom du SOUS ENSEMBLE ORGANISATIONEL   Description MultilingualString 0:1 Description du SOUS ENSEMBLE ORGANISATIONEL.   ContactDetails ContactDetails 0:1 Informations de contact du SOUS ENSEMBLE ORGANISATIONEL.  «cntd» Location Location 0:1 Localisation du SOUS ENSEMBLE ORGANISATIONEL.  «FK» OrganisationRef OrganisationRef 0:1 INSTITUTION à laquelle appartient le SOUS ENSEMBLE ORGANISATIONEL.  «FK» Typeof­OrganisationPartRef TypeOfOrganisation­PartRef 0:1 Référence le type d'UNITÉ ORGANISATIONNELLE.\nOn utilisera la reference comme type, mais sans obligation de créer le TYPE DE VALEUR correspondant.\n  «cntd» Administrative­Zones   On passera par le ResponsibilityRoleAssignment si une ZONE ADMINISTRATIVE doit être référencée.    Exploitants L\u0026rsquo;OPÉRATEUR hérite de l\u0026rsquo;INSTITUTION, on utilisera un champ OrganisationType instancié avec operator ou railOperator.\nOperator – Element    Classifi­cation Name Type Cardin­ality Description     ::\u0026gt; ::\u0026gt; Organisation ::\u0026gt; OPERATOR hérite ORGANISATION.    CountryRef CountryRef 0:1 Code ISO 3166-1 correspondant à la nationalité de l’exploitant    Address PostalAddress 0:1 Postal ADDRESS of ORGANISATION.    PrimaryMode VehicleModeEnum 0:1 Mode de tranport principal de l\u0026rsquo;opérateur (s\u0026rsquo;il en a un)    CustomerService­ContactDetails   Voir ContactDetails d\u0026rsquo;ORGANISATION.    departments   Voir Parts d\u0026rsquo;ORGANISATION.    Autorités De même pour décrire une AUTORITÉ ORGANISATRICE, on utilisera une INSTITUTION avec un champ OrganisationType instancié avec authority.\nGroupes d\u0026rsquo;operateurs Les GROUPEMENTs D\u0026rsquo;OPÉRATEURS sont aussi des objets à décrire. Toutefois, le GROUPEMENT D\u0026rsquo;OPÉRATEURS n\u0026rsquo;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.\nRôles et affectation de responsabilités Un ensemble de responsabilités peut être spécifié pour un objet DataManagedObject, notamment 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\u0026rsquo;octroi de licence aux données.\nDans 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).\nUn ResponsibilitySet est composé d\u0026rsquo;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\u0026rsquo;organisation, en ce qui concerne la responsabilité qui lui incombe relativement aux objets décrits (propriété, planification, exploitation, etc.) ou la gestion de ces données (distribution, mises à jour, etc.).\nResponsibilitySet – Element    Classifi­cation Name Type Cardin­ality Description     ::\u0026gt; ::\u0026gt; DataManagedObject ::\u0026gt; RESPONSIBILITY SET hérite de DATA MANAGED OBJECT.   «cntd» roles ResponsibilityRoleAssignment 1:* AFFECTATIONs de ROLE constituant l\u0026rsquo;ENSEMBLE DE RESPONSABILITÉ.    ResponsibilityRoleAssignment – Element (objet inclus)     Classifi­cation Nom Type  Description  :: :: VersionedChild  RESPONSIBILITY ROLE hérite de VERSIONED CHILD.\nNon utilisé quand inclus comme roles de ResponsabilitySet(l’inclusion est la solution retenue par le profil)\n   Description MultilingualString 0:1 Description textuelle du rôle  «PK» DataRoleType DataRoleTypeEnum 0:1 Rôle(s) attribué(s) dans la gestion des données. Les valeurs possibles sont :\n• collects\n• validates\n• aggregates\n• distributes\n• redistributes\n• creates\n  «PK» StakeholderRoleType StakeholderRoleTypeEnum 0:1 Rôle(s) opérationel(s) attribué(s). Les valeurs possibles sont :\n• planning\n• operation\n• control\n• reservation\n• entityLegalOwnership\n• fareManagement\n• securityManagement\n• dataRegistrar\n• other\n   TypeOfResponsibilityRoleRef TypeOfResponsibility RoleRef  Référence à un type de responsabilité.\nOn utilisera notamment ce champ pour référencer un type de contrat quand cela est nécessaire.\n  «FK» Responsible­OrganisationRef OrganisationRef 0:1 Référence l'institution concernée  «FK» ResponsibleAreaRef AdministrativeZoneRef 0:1 Référence la zone administrative concernée    Notes (NOTICEs) Notice – Element     Classifi­cation Nom Type Cardinalité Description  :: :: DataManagedObject :: NOTICE hérite de DATA MANAGED OBJECT.   Name MultilingualString 0:1 Nom de la NOTE.   Text MultilingualString 0:1 Texte de la NOTE  «AK» PublicCode xsd:normalizedString 1:1 Code publique de la NOTE (numéro de renvoi sur la fiche horaire par exemple)  «FK» TypeOfNoticeRef TypeOfNoticeRef 1:1 Type de NOTE.\nOn pourra ainsi catégoriser les NOTEs, par exemple:\n Exception de circulation (sauf…)\n Restriction de circulation (ne circule que …..)\n Etc.\n  Ces codes sont ouverts et sont définis par le producteur des données qui en précisera les valeurs possibles dans sa spécification d'interface.\n   CanBeAdvertised   Dans le cadre des profils NeTEx, toutes les notes sont à vocation d'information voyageur et donc publiques.   «cntd» variants DeliveryVariant 0:* VARIANTEs DE DIFFUSION pour la note (rédaction adaptée à différents type de médias).    DeliveryVariant – Element (objet inclus)     Classifi­cation Nom Type Cardinalité Description  :: :: DataManagedObject :: DELIVERY VARIANT hérite de DATA MANAGED OBJECT.  «FK» ParentRef   Les variantes seront toujours exprimées au sein de la NOTE elle-même.   DeliveryVariant­MediaType DeliveryMediaEnum 1:1 Type de média donnant lieu à la VARIANTE DE DIFFUSION de la NOTE. Les valeurs possibles sont:\n printed\n textToSpeech\n web\n mobile\n other\n    VariantText MultilingualString 0:1 Texte de la VARIANTE DE DIFFUSION (qui remplacera donc la NOTE pour les médias indiqués).    Le tableau ci-dessous présente l\u0026rsquo;affectation de NOTE: seuls les deux attributs retenus y sont présentés (l\u0026rsquo;affectation est très paramétrable, mais la grande majorité des attributs ne sont pas retenus dans le profil).\nLes NoticeAssignments doivent être intégré en ligne à l\u0026rsquo;élément annoté et non placé séparément. Ils peuvent faire référence à une NOTICE déjà définie dans un NOTICE ASSIGNMENT antérieur.\nNotice Assignment – Element     Classification Name Type Cardinality Description    :: :: DataManagedObject :: NOTICE ASSIGNMENT inherits from DATA MANAGED OBJECT.  «PK» id TypeOfNotice­AssignmentIdType 1:1 Identifiant du NOTICE ASSIGNMENT.             «FK» a NoticeRef NoticeRef 0:1 Reference à une NOTE   c Notice Notice 0:1 Description de la NOTE elle même.\nOn préférera toujours Noticeà NoticeRef(utilisez uniquement NoticeRefpour les NOTEs partagés).\n  «FK» NoticedObjectRef VersionOfObjectRef 0:1 Objet auquel la NOTE est associée. Si donné par le contexte peut être omis.  «FK» StartPointInPatternRef PointInSequenceRef 0:1 POINT à partir duquel la NOTE devient applicatble (dans un PARCOURS).  «FK» EndPointInPatternRef PointInSequenceRef 0:1 POINT à partir duquel la NOTE n’est plus applicatble (dans un PARCOURS).    Jour d’exploitation OPERATING DAY et DAY TYPE – Model conceptuel\nOperatingDay – Element     Classifi­cation Nom Type Cardinalité Description  :: :: DataManagedObject :: OPERATING DAY hérite de DATA MANAGED OBJECT.   CalendarDate xsd:date 1:1 Date calendaire de la JOURNÉE D'EXPLOITATION.\nIl s'agit ici du jour calendaire où démarre la JOURNÉE D'EXPLOITATION, l'heure de début et la durée de la journée étant précisées par les autres paramètres.\n  «FK» ServiceCalendar­Ref CalendarRef 0:1 CALENDRIER DE SERVICE auquel appartient la JOURNÉE D'EXPLOITATION.\nNote: une même journée calendaire peut être couverte par différentes JOURNÉE D'EXPLOITATION (pour différents exploitants, ou différentes modalités d'exploitation, comme par exemple NOCTILIEN (bus de nuit à Paris) et bus RATP). On recommandera toutefois dans ce cas d'affecter ces jours \"redondants\" à différents CALENDRIERs DE SERVICE.\n   Name MultilingualString 0:1 Nom de la JOURNÉE D'EXPLOITATION   EarliestTime xsd:time 1:1 Heure de début de la JOURNÉE D'EXPLOITATION   DayLength xsd:duration 1:1 Durée de la JOURNÉE D'EXPLOITATION.\nUne JOURNÉE D'EXPLOITATION peut durer plus de 24h (pas de limite supérieure).\n    Type de Jour Note : si le TYPE DE JOUR n\u0026rsquo;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.\nDayType – Model Element     Classifi­cation Nom Type Cardinalité Description  :: :: DataManagedObject :: DAY TYPE hérite de DATA MANAGED OBJECT.\nOn utilisera le ValidBetweenpour une éventuelle limitation de période\n   Name MultilingualString 0:1 Nom du TYPE DE JOUR.   Description MultilingualString 0:1 Description du TYPE DE JOUR.   EarliestTime xsd:time 0:1 Heure de début de validité dans le TYPE DE JOUR.\nExclusif avec timebands\n   DayLength xsd:duration 0:1 Durée du TYPE DE JOUR.\nExclusif avec timebands\n  «cntd» properties PropertyOfDay 0:* PROPRIÉTÉ du TYPE DE JOUR.\nNote: sous un même PropertyOfDay les caractéristiques s'associent par un ET, sinon elles s'associent par un OU.\nAinsi pour désigner l'été et les samedis:\n\u0026lt;netex:PropertyOfDay\u0026gt; \u0026lt;netex:DaysOfWeek\u0026gt;Saturday\u0026lt;/netex:DaysOfWeek\u0026gt; \u0026lt;/netex:PropertyOfDay\u0026gt; \u0026lt;netex:PropertyOfDay\u0026gt; \u0026lt;netex:Seasons\u0026gt;Summer\u0026lt;/netex:Seasons\u0026gt; \u0026lt;/netex:PropertyOfDay\u0026gt; Mais pour désigner les samedis d'été:\n\u0026lt;netex:PropertyOfDay\u0026gt; \u0026lt;netex:DaysOfWeek\u0026gt;Saturday\u0026lt;/netex:DaysOfWeek\u0026gt; \u0026lt;netex:Seasons\u0026gt;Summer\u0026lt;/netex:Seasons\u0026gt; \u0026lt;/netex:PropertyOfDay\u0026gt;   «cntd» timebands Timeband 0:* TRANCHEs HORAIREs du TYPE DE JOUR\nOn utilisera ces TRANCHEs HORAIREs uniquement si elles sont multiples (par exemple \"de 9h à 12h30 et de 14h à 18h30\") sinon on utilisera EarliestTime et DayLength.\nExclusif avec EarliestTime et DayLength\n     PropertyOfDay – Element (objet inclus)     Classifi­cation Nom Type Cardinalité Description   Name MultilingualString 0:1 Nom de la PROPRIÉTÉ DE JOUR.   Description MultilingualString 0:1 Description de la PROPRIÉTÉ DE JOUR.  «FK» DaysOfWeek DayOfWeekEnum 0:7 Jours de la semaine affectés à la PROPRIÉTÉ DE JOUR.\nTous les jours par défaut.\n   WeeksOfMonth WeekOfMonthEnum 0:5 Numéros de semaine dans le mois (1-5) affectés à PROPRIÉTÉ DE JOUR.\nToutes les semaines par défaut.\n  Choice MonthOfYear month 0:1 Mois de la PROPRIÉTÉ DE JOUR.  DayOfYear monthDay 0:1 Jour dans l'année affecté à la PROPRIÉTÉ DE JOUR (par exemple \"tous les 1er avril\")   CountryRef CountryEnum 0:* Pays pour lequel les jours de vacances doivent-être considérés.   HolidayTypes HolidayTypeEnum 0:5 Type de vacance de la PROPRIÉTÉ DE JOUR (voir liste ci-dessous).   Seasons SeasonEnum 0:4 Saison de la PROPRIÉTÉ DE JOUR.   Tides TideEnum 0:4 Type de marée de la PROPRIÉTÉ DE JOUR.\nAttention, cette classification restreint à une partie de la journée (marée haute, etc.).\n   DayEvent DayEventEnumeration 0:1 Événement particulier associé à la PROPRIÉTÉ DE JOUR.   Crowding CrowdingEnumeration 0:1 Niveau de charge pour le jour concerné :\n veryQuiet\n quiet\n normal\n busy\n veryBusy\n     Les énumérations correspondantes sont les suivantes (noter que l\u0026rsquo;on n\u0026rsquo;utilisera pas les valeurs anyXxx ou everyXxx, qui sont les valeurs par défaut quand le champ est absent).\nDayOfWeekEnum – valeurs autorisées    Nom Description     Monday Lundi   Tuesday Mardi   Wednesday Mercredi   Thursday Jeudi   Friday Vendredi   Saturday Samedi   Sunday Dimanche    WeekOfMonthEnum – valeurs autorisées    Nom Description     1 Première semaine du mois   2 Seconde semaine du mois   3 Troisième semaine du mois   4 Quatrième semaine du mois   5 Cinquième semaine du mois    HolidayTypeEnum – valeurs autorisées    Nom Description     SchoolDay Jour d\u0026rsquo;école   NotHoliday Jour hors vacances   AnyHoliday N\u0026rsquo;importe quel type de jour de vancances.   LocalHoliday Jour de vancance local   NationalHoliday Jour de vancance national   RegionalHoliday Jour de vancance régional   HolidayDisplacementDay Jour de départ ou retour en vacances   EveOfHoliday Veille de vacances    SeasonEnum – valeurs autorisées    Nom Description     Spring Printemps   Summer Été   Autumn Automne.   Winter Hiver.    TideEnum – valeurs autorisées    Nom Description     HighTide Marée haute   LowTide Marée basse   NeapTide Grande marée    DayEventEnumeration – valeurs autorisées    Nom Description     marketDay Jour de marché   matchDay Jour de match (ou évènement sportif)   eventDay Jour d\u0026rsquo;évènement (préciser dans la description du type de jour)    Dans un certain nombre de situations, 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\u0026rsquo;EXPLOITATION: on réalise alors une affectation entre le TYPE DE JOUR et les JOURs D\u0026rsquo;EXPLOITATION correspondants.\nDayTypeAssignment – Element     Classifi­cation Nom Type Cardinalité Description  :: :: VersionedChild :: DAY TYPE ASSIGNMENT hérite de VERSIONED CHILD.  «FK» ServiceCalendarRef CalendarRef 0:1 CALENDRIER DE SERVICE auquel l'affectation de TYPE DE JOUR appartient.   «FK» Choice\n(seul un de ces éléments est obligatoire)\n OperatingPeriodRef OperatingDayRef 1:1 Référence à une PÉRIODE D'EXPLOITATION assignée: noter que tous les jours de la période s'applique (de ce fait on l'utilisera le plus souvent pour les exclusions de périodes en combinaison avec le champ isAvailable=false)  «FK» OperatingDayRef OperatingDayRef 1:1 Référence au JOUR D'EXPLOITATION correspondant.   Date xsd:date 1:1 Une date calendaire peut être utilisée à la place du JOUR D'EXPLOITATION correspondant (si l'on n'utilise aucune caractéristique propre au jour d'exploitation)  «FK» DayTypeRef DayTypeRef 1:1 Référence le TYPE DE JOUR concerné   isAvailable boolean 0:1 Vrai (disponible par défaut) : cet attribut permet d'exprimer les exceptions (sauf le 1er avril…).    Le CALENDIER DE SERVICE permet de grouper des JOURs D\u0026rsquo;EXPLOITATION et des AFFECTATIONs DE JOUR d\u0026rsquo;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).\nServiceCalendar – Element    Classifi­cation Nom Type Cardinalité Description     ::\u0026gt; ::\u0026gt; DataManagedObject ::\u0026gt; SERVICE CALENDAR hérite de DATA MANAGED OBJECT.    Name MultilingualString 0:1 Nom du CALENDRIER DE SERVICE.    FromDate xsd:date 0:1 Date (inclusive) du début du CALENDRIER DE SERVICE.    ToDate xsd:date 0:1 Date (inclusive) de fin du CALENDRIER DE SERVICE.   «cntd» dayTypes DayType 0:* TYPEs DE JOURs du CALENDRIER DE SERVICE.   «cntd» operatingDays OperatingDay 0:* JOURs D\u0026rsquo;EXPLOITATION du CALENDRIER DE SERVICE.   «cntd» operatingPeriods OperatingPeriod 0:* AFFECTATIONs des PÉRIODEs D\u0026rsquo;EXPLOITATION du CALENDRIER DE SERVICE.   «cntd» dayTypeAssignments DayTypeAssignment 0:* AFFECTATIONs DE JOUR du CALENDRIER DE SERVICE.    OperatingPeriod – Element    Classifi­cation Nom  Type Cardinalité Description     ::\u0026gt; ::\u0026gt;  DataManagedObject ::\u0026gt; OPERATING PERIOD hérite de DATA MANAGED OBJECT.   «FK» ServiceCalendar­Ref  CalendarRef 0:1 CALENDRIER DE SERVICE auquel la période appartient.    b FromDate dateTime 1:1 Date calendaire de début    b ToDate dateTime 1:1 Date calendaire de fin    Note : UicOperatingPeriodsera 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\u0026rsquo;elle soit valide ou non le jour).\nUicOperatingPeriod – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; OperatingPeriod ::\u0026gt; UIC OPERATING PERIOD inherits from OPERATING PERIOD.    ValidDayBits xsd:normalizedString 1:1 String of bits (built of \u0026ldquo;0\u0026rdquo; and \u0026ldquo;1\u0026rdquo;), one for each day in the period: whether valid or not valid on the day. Normally there will be a bit for every day between start and end date. If bit is missing, assume available.    DaysOfWeek DaysOfWeek 0:1 Days of week to which correspond. (up to first seven) bits    Tranche horaire Timeband – Element (objet inclus)     Classifi­cation Nom Type Cardinalité Description  :: :: DataManagedObject :: TIME BAND hérite de DATA MANAGED OBJECT.   StartTime xsd:time 1:1 heure de début (inclusif).   EndTime xsd:time 1:1 heure de fin (inclusif).   DayOffset xsd:integer 0:* Décalage de jour si l'heure de fin n'est pas le même jour que l'heure de début (1=le lendemain, 2=le surlendemain, etc.)\nValeur par défaut: 0.\n    Type de Valeur Les types de valeur sont utiles pour préciser et personnaliser toutes les codifications ouvertes (TypeOfXxxxx, comme les TypeOfNoticeRef par exemple).\nTypeOfValue – Element (abstrait)    Classifi­cation Nom Type  Description     ::\u0026gt; ::\u0026gt; DataManagedObject ::\u0026gt; TYPE OF VALUE hérite de DATA MANAGED OBJECT.    Name MultilingualString 0:1 Nom du TYPE DE VALEUR.    Description MultilingualString 0:1 Description du TYPE OF VALUE.    Image anyURI 0:1 Image associée au TYPE OF VALUE.    Url anyURI 0:1 URL associée au TYPE OF VALUE.    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.).\nPresentation – Type (objet inclus)    Classifi­cation Name Type Cardin­ality Description      Colour ColourValue 0:1 Couleur (format RVB)    ColourName xsd:normalizedString 0:1 Nom de la couleur    BackGroundColour ColourValueType 0:1 Valeur RVB de la couleur de fond (par exemple la couleur de la ligne de transport)    BackgroundColour­Name xsd:String 0:1 Nom de la couleur de fond dans le ColourSystem.    TextColour ColourValue 0:1 Couleur du texte (format RVB)    TextColourName xsd:normalizedString 0:1 Nom de la couleur du texte    TextFont xsd:normalizedString 0:1 Identifiant de la police de caractère    TextFontName xsd:normalizedString 0:1 Nom de la police de caractère    InfoLink InfoLink 0:1 URL d\u0026rsquo;un élément graphique de représentation (généralement une icône).    Branding Le Branding correspond aux informations permettant la description des marques.\nBranding – Element (objet inclus)    Classifi­cation Nom Type  Description     ::\u0026gt; ::\u0026gt; DataManagedObject ::\u0026gt; BRANDING hérite de TYPE OF VALUE.    Presentation PresentationStructure 0:1 Informations de graphisme et de style de représentation associés à la marque.    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).\nL’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.\nNeTEx 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.\nPublicationDelivery     Classifi­cation Nom Type  Description     version xsd:NMTOKEN  Identifiant de la version de NeTEx utilisée.\nVoir 7.5\n  Public­ation­Header­Group Publication­Timestamp xsd:dateTime 1:1 Date et heure de publication des données  ParticipantRef ParticipantCodeType 1:1 Identifiant du système ayant produit la donnée. De manière générale il sera identique au DATA SOURCE, mais il arrive que plusieurs systèmes soient constitutifs d’une même source de données: il est alors utile de pouvoir les différencier.  Publication­Request PublicationRequestStructure 0:1 Description de la requête ayant donné lieu à la publication. Ce champ ne sera utilisé que dans le cadre d’une réponse dans le contexte d’un appel de web service (voir 8.2).  Publication­RefreshInterval xsd:duration 0:1 Période normale de rafraichissement des données (espace normal entre deux mises à jour) pour les CADREs DE VERSION contenus dans le jeu de données.  Description xsd:normalizedString 0:1 Texte décrivant les données contenues  PayloadGroup dataObjects dataObjects_RelStructure 0:1 Données échangées dans un contexte de CADRE DE VERSION.    Frames (CADRE DE VERSION) Une VersionFrame fournit un conteneur versionnable qui permet d\u0026rsquo;échanger un ensemble cohérent d\u0026rsquo;éléments connexes correspondant, par exemple aux horaires d\u0026rsquo;une ligne, ou aux gares d\u0026rsquo;un pays. La VersionFrame garantit notamment la cohérence des versions des objets en relation les uns avec les autres.\nFRAMEs – Modèle conceptuel\nFormant un ensemble cohérent d\u0026rsquo;éléments connexes (c\u0026rsquo;est-à-dire un ensemble complet d\u0026rsquo;é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\u0026rsquo;il s\u0026rsquo;agit d\u0026rsquo;un DataManagedObject à part entière qui est utilisé pour exprimer la validité du cadre et de son contenu dans son ensemble).\nNotez 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\u0026rsquo;appliquent à plusieurs éléments dans le cadre (conditions 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).\nVersionFrame 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\u0026rsquo;un GeneralFrame qui peut contenir n\u0026rsquo;importe quel type d\u0026rsquo;ENTITY IN VERSION.\nUne VersionFrame peut se voir attribuer une TypeOfFrame; une classification arbitraire définie par l\u0026rsquo;utilisateur (et qui est ici utilisée pour identifier le profil).\nLa 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 chaque partie du profil France (voir plus bas).\nNOTE IMPORTANTE : Pour chaque export, les identifiants des CADREs de VERSION (FRAME) doivent être uniques.\npredefined Frames– XSD\nVersionFrame – Element     Classifi­cation Nom Type  Description    :: :: DataManagedObject :: VERSION FRAME hérite de DATA MANAGED OBJECT.   Name MultilingualString 0:1 Nom du VERSION FRAME.   Description MultilingualString 0:1 Description du VERSION FRAME.  «FK» TypeOfFrameRef TypeOfFrameRef 0:1 Référence au TYPE OF VERSION FRAME utilisé.\nImposé à NETEX_COMMUN, NETEX_ARRET, NETEX_LIGNE, NETEX_RESEAU, NETEX_HORAIRE, NETEX_CALENDRIER, NETEX_TARIF pour les GeneralFrame et pour les CompositeFrame on utilisera NETEX_FRANCE, NETEX_LIGNE ou NETEX_N_LIGNE.   «FK» BaselineVersion­FrameRef VersionRef 0:1 Identifiant du CADRE DE VERSION précédemment échangé et nécessaire pour utiliser celui-ci.\nCet attribut permet de faire des mises à jour d’un cadre de version sans avoir à l’échanger dans son intégralité.\n  «cntd» codespaces Version 0:* CODESPACEs utilisé dans le CADRE DE VERSION. Normalement, il y en a au moins un. Une valeur par défaut peut être précisée par le FrameDefaults.\nNOTE Le codespaceest utilisé par le profil, et il est spécifié par le FrameDefaults.\nVoir ci-dessous\n  «cntd» FrameDefaults FrameDefaults 0:1 Ensemble de valeurs par défaut qu’il sera inutile de répéter pour chaque élément (un élément particulier garde toutefois la possibilité de définir ses propres valeurs, qui sont alors prioritaires sur celles du FrameDefaults).  «cntd» prerequisites VersionFrameRef 0:* Références à d’autre VERSION FRAME dont dépend celle-ci (typiquement contenant des objets référencés par cette FRAME).  «cntd» content­ValidityConditions ValidityCondition 0:* CONDITIONS DE VALIDITE partagées par les différents éléments contenus dans le CADRE.On utilisera uniquement le ValidBetweencomme indiqué en 6.9)    GeneralFrame    Classifi­cation Nom Type Cardinalité Description     ::\u0026gt; ::\u0026gt; VersionFrame ::\u0026gt; GENERAL FRAME hérite de VERSION FRAME    members EntityInFrame 0:* Contenu du GENERAL FRAME    VersionFrameDefaults – Element (objet inclus)    Classifi­cation Nom Type  Description     «FK» Default­CodeSpaceRef CodeSpaceRef 0:1 Codespace par défaut (voir 7.3) qui sera utilisé pour tous les éléments qui ne le précisent pas.   «FK» Default­DataSourceRef DataSourceRef 0:1 Source de données par défaut (pour tous les éléments qui ne le précisent pas)   «FK» Default­ResponsibilitySetRef ResponsibilitySetRef 0:1 RESPONSIBILITY SET par défaut (pour tous les éléments qui ne le précisent pas)    DefaultLocale Locale 0:1 Valeur de LOCALE par défaut (pour tous les éléments qui ne le précisent pas)    Default­LocationSystem xsd:normalizedString 0:1 Système de localisation par défaut (pour tous les éléments qui ne le précisent pas)    Dans le cadre du profil les distances et les longueurs sont par défaut exprimées en mètres (SystemOfUnits ayant une valeur SiMetres) et les sommes d’argent en Euros.\nTypeOfFrame – Élément     Classifi­cation Nom Type  Description    :: :: TypeOfValueDataManagedObject :::: TYPE OF FRAME hérite de TYPE OF VALUE.\nL'Id est imposé à NETEX_RESEAU\n  «cntd» classes ClassInContextRef 0:* Liste des classes pouvant être contenues dans ce TYPE OF FRAME.\n    Chaque partie du profil France décrit les frames associées et la valeur spécifique du type de Frame à utiliser, et le chapitre 7.4 du présent document rappelle les différentes valeurs.\nCODESPACE 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.\nUn 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.\nÀ 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.\nEXEMPLE de définition de CODESPACE\n\u0026lt;CompositeFrame version=\u0026quot;any\u0026quot; id=\u0026quot;mybus:CompositeFrame:CF1\u0026quot;\u0026gt; \u0026lt;!--- ======= CODESPACEs======== --\u0026gt; \u0026lt;codespaces\u0026gt; \u0026lt;Codespace id=\u0026quot; *era* \u0026quot;\u0026gt; \u0026lt;Xmlns\u0026gt;*era*\u0026lt;/Xmlns\u0026gt; \u0026lt;XmlnsUrl\u0026gt;*http://era.org.eu/*\u0026lt;/XmlnsUrl\u0026gt; \u0026lt;Description\u0026gt;European Rail AUthority\u0026lt;/Description\u0026gt; \u0026lt;/Codespace\u0026gt; \u0026lt;/codespaces\u0026gt; EXEMPLE d’utilisation de CODESPACE pour les identifiants id=napt:4701234567\nref=napt:4701234567 id=era:4501234345 Codespace – Element (objet inclus)     Classifi­cation Nom Type  Description    :: :: Entity :: CODESPACE hérite de ENTITY.  «AK» Xmlns xsd:NMTOKEN 1:1 Préfixe du CODESPACE, unique au sein du document XML (exemple : ‘ratp’,’transilien’,’tisseo’, etc.)   XmlnsUrl xsd:anyURI 0:1 URI du CODESPACE.\nPar exemple : http://naptan.org.uk/naptan ou http:/vdv.de/vdv/haltstelle/\n   Description xsd:string 0:1 Description du CODESPACE.    Cette utilisation du CODESPACE est générique pour l\u0026rsquo;ensemble des objets. Certains objets comme les arrêts peuvent disposer d\u0026rsquo;une codification particulière (utilisée en lieu et place de la partie numérique dans les exemples ci-dessus).\nCodification 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éférentiel de données (arrêts, lignes, etc.) propose des identifiants uniques 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).\nNOTE IMPORTANTE : la technique de construction proposée ici a pour vocation d’assurer 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 !\nPour mémoire, le profil SIRI Ile-de-France propose la codification suivante pour tous les identifiants:\n[Fournisseur]:[type d'objet]:[typeObjetDétaillé]:[identifiantTechnique]:LOC\nSi un objet a déjà été identifié dans le cadre d’un échange SIRI, on conservera naturellement son identifiant.  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 :\n  [Fournisseur] : est remplacé par le CODESPACE (et peut être complété par le DataSourceRefde EntityInVersion)\n  [type d'objet] : classe de l\u0026rsquo;objet sous la forme du nom du tag XML qui le porte\n  [identifiantTechnique]: est naturellement conservé\n  LOC : est conservé pour permettre de préciser que l\u0026rsquo;identifiant a été défini de façon locale entre les parties engagées dans l\u0026rsquo;échange, et qu\u0026rsquo;il ne fait donc pas partie du référentiel partagé (régional, national, etc.) L\u0026rsquo;utilisation de ce qualificatif est obligatoire quand l\u0026rsquo;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.\n  La codification retenue est donc: \n[CODESPACE]:[type d'objet]:[identifiantTechnique]:[LOC ou Nom attributaire]\nExemple RATP-I2V:JourneyPattern:2354345:LOC ou IDFM:Line:345:CODIFLIGNE ou STIF-CODIFLIGNE:Line:C00001:\nNote : par convention, on conserve les \u0026ldquo;:\u0026rdquo; de fin même s’il n’y a pas de valeur [NomAttributaire] ou LOC (même si, 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èmes attributaires, pour peu que l’unicité soit conservée au niveau national.\nCodification des identifiants d\u0026rsquo;arrêt Les arrêts sont un cas particulier et donneront lieu à une codification spécifique. La forme actuellement envisagée étant [Code PAYS]:[Code commune INSEE]:[Type d’objet]:[Code arrêt spécifique]:[Code émetteur du code technique ou LOC], on aura donc :\n  [Code PAYS]: Identifiant du Pays en respectant la norme ISO 3166-1 (voir: www.iso.org/iso-3166-country-codes.html, FRpour la France ).\n  [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 caractères pour le département et 2 pour la commune elle-même pour l’outre-mer.\nCe 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.\nEn 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).\n  [Type d’objet]: ZE(ZONE D’EMBARQUEMENT), LMO(LIEU D’ARRET MONOMODAL), PM(POLE MONOMODAL), LMU(LIEU D’ARRET MUTIMODAL), AC(ACCES)\n  [Code arrêt spécifique]: code technique libre\n  [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\n  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(NUTS714pour Isère par exemple)\n  Si c’est une AOT : code NAOde la norme NF-9950 précédé de NAO (NAO17pour Blefort par exemple)\n  Si un attributeur national est national est créé, il prendra le code FR\n  Si le code technique est attribué par le système local: code LOC(comme pour le profil SIRI) . Note : un code LOCest à considérer comme à priori temporaire, en attente de la mise en place d’un système centralisé d’attribution des identifiants \n  Pour le mode ferré, le code sera ERA(pour European Rail Agency) pour les identifiants issus de la STI-TAP (à priori les codes UIC ne seront pas utilisés, mais si c’était le cas, le code serait UIC).\n    Examples :\n Gare ferrée \u0026ldquo;PARIS MONTPARNASSE 1 2\u0026rdquo; : 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.\nTypeOfFrame : types spécifiques Le présent profil utilise des valeurs précises de TypeOfFrame pour spécifier le contenu de chaque fichier :\n accessibility.xml : TypeOfFrame NETEX_ACCESSIBILITY, décrit dans la partie accessibilité du profil network.xml : TypeOfFrame NETEX_RESEAU décrit dans la partie \u0026ldquo;Description du réseau\u0026rdquo; du profil stop.xml : TypeOfFrame NETEX_ARRET, décrit dans la partie \u0026ldquo;Description des arrêts\u0026rdquo; du profil line_xyz.xml : TypeOfFrame NETEX_LIGNE et NETEX_LIGNE_STRUCTURE dans la partie \u0026ldquo;Description des réseaux\u0026rdquo; et NETEX_HORAIRE dans la partie Horaires du profil fare.xml : TypeOfFrame NETEX_TARIF dans la partie Tarifs du profil parking.xml : À venir dans la partie Parking du profil poi.xml : TypeOfFrame NETEX_POI, décrit dans la partie Éléments Communs du profil resource.xml : TypeOfFrame NETEX_FRANCE, NETEX_COMMUN et NETEX_CALENDRIER décrits dans la partie Éléments Communs du profil  Attention : les identifiants sont construits selon les recommandations du présent profil. Par exemple, NETEX_LIGNE sera présent dans un fichier avec la valeur complète FR:TypeOfFrame:NETEX_LIGNE:.\nLe fichier resource.xml contient une CompositeFrame de type NETEX_FRANCE, elle-même composée de :\n Une GeneralFrame de type NETEX_COMMUN Une GeneralFrame de type NETEX_CALENDRIER Les objets de premiers niveaux possibles dans ces frames sont indiqués dans les exemples XML ci-dessous sous forme de commentaires.  Le fichier poi.xml contient une GeneralFrame de type NETEX_POI.\nVoici un exemple de cadre du fichier resource.xml :\n\u0026lt;?xml version=\u0026#34;1.0\u0026#34; encoding=\u0026#34;utf-8\u0026#34;?\u0026gt; \u0026lt;PublicationDelivery xmlns=\u0026#34;http://www.netex.org.uk/netex\u0026#34; version=\u0026#34;2.0:FR-NETEX-2.4\u0026#34;\u0026gt; \u0026lt;PublicationTimestamp\u0026gt;2023-01-01T00:00:00.0Z\u0026lt;/PublicationTimestamp\u0026gt; \u0026lt;ParticipantRef\u0026gt;Exemple\u0026lt;/ParticipantRef\u0026gt; \u0026lt;dataObjects\u0026gt; \u0026lt;CompositeFrame id=\u0026#34;exemple:CompositeFrame:NETEX_FRANCE-1:LOC\u0026#34; version=\u0026#34;2.0:FR-NETEX-2.4\u0026#34;\u0026gt; \u0026lt;TypeOfFrameRef ref=\u0026#34;FR:TypeOfFrame:NETEX_FRANCE:\u0026#34; /\u0026gt; \u0026lt;frames\u0026gt; \u0026lt;GeneralFrame id=\u0026#34;exemple:GeneralFrame:NETEX_COMMUN-1:LOC\u0026#34; version=\u0026#34;2.0:FR-NETEX-2.4\u0026#34;\u0026gt; \u0026lt;TypeOfFrameRef ref=\u0026#34;FR:TypeOfFrame:NETEX_COMMUN:\u0026#34; /\u0026gt; \u0026lt;members\u0026gt; \u0026lt;!-- VALIDITY CONDITION (AVAILABILITY CONDITION et VALIDITY TRIGGER) ALTERNATIVE NAME NOTICE NOTICE ASSIGNMENT RESPONSIBILITY ROLE ASSIGNMENT ORGANISATION POINT PROJECTION ZONE PROJECTION TYPE OF VALUE spécifiques DATA SOURCE SITE CONNECTION VEHICLE TYPE CONNECTION JOURNEY INTERCHANGE DEFAULT CONNECTION BOOKING ARRANGEMENT SERVICE FACILITY SET --\u0026gt; \u0026lt;/members\u0026gt; \u0026lt;/GeneralFrame\u0026gt; \u0026lt;GeneralFrame id=\u0026#34;exemple:GeneralFrame:NETEX_CALENDRIER-1:LOC\u0026#34; version=\u0026#34;2.0:FR-NETEX-2.4\u0026#34;\u0026gt; \u0026lt;TypeOfFrameRef ref=\u0026#34;FR:TypeOfFrame:NETEX_CALENDRIER:\u0026#34; /\u0026gt; \u0026lt;members\u0026gt; \u0026lt;!-- DAY TYPE OPERATING PERIOD SERVICE CALENDAR DAY TYPE ASSIGNMENT --\u0026gt; \u0026lt;/members\u0026gt; \u0026lt;/GeneralFrame\u0026gt; \u0026lt;/frames\u0026gt; \u0026lt;/CompositeFrame\u0026gt; \u0026lt;/dataObjects\u0026gt; \u0026lt;/PublicationDelivery\u0026gt; Voici un exemple de cadre du fichier poi.xml :\n\u0026lt;?xml version=\u0026#34;1.0\u0026#34; encoding=\u0026#34;utf-8\u0026#34;?\u0026gt; \u0026lt;PublicationDelivery xmlns=\u0026#34;http://www.netex.org.uk/netex\u0026#34; version=\u0026#34;2.0:FR-NETEX-2.4\u0026#34;\u0026gt; \u0026lt;PublicationTimestamp\u0026gt;2023-01-01T00:00:00.0Z\u0026lt;/PublicationTimestamp\u0026gt; \u0026lt;ParticipantRef\u0026gt;Exemple\u0026lt;/ParticipantRef\u0026gt; \u0026lt;dataObjects\u0026gt; \u0026lt;GeneralFrame id=\u0026#34;exemple:GeneralFrame:NETEX_POI-1:LOC\u0026#34; version=\u0026#34;2.0:FR-NETEX-2.4\u0026#34;\u0026gt; \u0026lt;TypeOfFrameRef ref=\u0026#34;FR:TypeOfFrame:NETEX_POI:\u0026#34; /\u0026gt; \u0026lt;members\u0026gt; \u0026lt;!-- POINT OF INTEREST POINT OF INTEREST CLASSIFICATION POINT OF INTEREST ENTRANCE --\u0026gt; \u0026lt;/members\u0026gt; \u0026lt;/GeneralFrame\u0026gt; \u0026lt;/dataObjects\u0026gt; \u0026lt;/PublicationDelivery\u0026gt; Version des objets et références NeTEx propose 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\u0026rsquo;unicité des identifiants relativement sophistiqué. Il est basé sur l\u0026rsquo;utilisation de la contrainte xsd:key (https://www.w3schools.com/xml/el_key.asp) qui permettra aussi, par la suite, de gérer les contraintes de référence vers les objets.\nLa contrainte d\u0026rsquo;unicité des identifiants permet de vérifier qu\u0026rsquo;au sein d\u0026rsquo;un jeu de données, on n\u0026rsquo;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\u0026rsquo;unicité impose qu\u0026rsquo;un attribut version soit présent (dans le cas contraire une erreur sera signalée): si l\u0026rsquo;on ne dispose pas de versionnage des objets, il suffira d\u0026rsquo;indiquer version=\u0026ldquo;any\u0026quot;(par convention).\nRappelons que la codification des identifiants est imposée par le profil.\nDe 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\u0026rsquo;utilisation du \u0026ldquo;any\u0026rdquo; 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\u0026rsquo;indication de version dans toutes les références (éventuellement positionné à \u0026ldquo;any\u0026quot;) et ce pour tous les objets figurant dans le même document XML.\nPour 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\u0026rsquo;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\u0026rsquo;exemple ci-dessous:\n\u0026lt;TypeOfFrameRef ref=\u0026quot;FR:TypeOfFrame:NETEX_COMMUN\u0026quot; versionREf=\u0026quot;1.01:FR-NETEX_COMMUN-1.0\u0026quot;/\u0026gt; Toutefois, contrairement aux références internes, la précision du numéro de versionRefn\u0026rsquo;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 \u0026ldquo;any\u0026rdquo; quand elle n\u0026rsquo;est pas connue ou pas utile).\nDe 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 namequand il y en a une) en tant que contenu de la balise référence.\n\u0026lt;StopPlaceRef ref=\u0026quot;FR:78297:LMO:110E8400:LOC\u0026quot; versionRef=\u0026quot;8.3\u0026quot;\u0026gt;Le Corbusier\u0026lt;/StopPlaceRef\u0026gt; Note : l’une des conclusions des point ci-dessus est que toute référence ne portant pas l’attribut versioncorrespond forcément à une référence vers un objet externe.\nVersionOfObjectRef (abstrait)     Classifi­cation Nom Type  Description   NameOfRefClass NameOfClass 0:1 Nom de la classe d’objet référencée.  «FK» ref (ObjectIdType)+ 1:1 Identifiant de l’objet référencé  CHOIX ENTRE DEUX OPTIONS (choice)  «FK» version VersionIdType 0:1 Version de l’objet référencé dans le jeu de données courant.\nDoit systématiquement être instancié pour un objet présent dans le jeu de donnée (mettre « any » si la version n’est pas connue).\n  «FK» versionRef VersionRef 0:1 Version de l’objet référencé dans un jeu de données externe.\nMettre « any » si la version n’est pas connue.\n    Version du profil Dans le temps, il pourra exister plusieurs versions des profils qui s\u0026rsquo;appuieront éventuellement sur différentes versions de NeTEx (en fonction des évolutions à venir).\nUne compatibilité ascendante est assurée entre les versions de NeTEx et devra aussi l’être entre les versions de profils.\nIl n\u0026rsquo;y a par contre aucune garantie de compatibilité \u0026ldquo;descendante\u0026rdquo; : on peut assurer qu\u0026rsquo;un client de version antérieure puisse toujours s\u0026rsquo;adresser à un serveur de version postérieure, mais l\u0026rsquo;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\u0026rsquo;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.\nAfin d’assurer cette compatibilité ascendante, le profil NeTEx intègre un mécanisme de gestion de version qui a plusieurs objectifs:\n  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 ;\n  Permettre à un producteur de données de signaler à un client qu\u0026rsquo;il ne supporte pas la version demandée (plutôt que de lui répondre avec une erreur) ;\n  Permettre à un client de gérer les réponses d\u0026rsquo;un serveur d\u0026rsquo;une version antérieure.\n  Le principe de gestion de version est simple : il s\u0026rsquo;appuie sur les identifiants de version du CADRE DE VERSION spécifique utilisé par le profil.\nLa codification de la version de profil se fait de la façon suivante : .x.y:FR-NETEX_nnnn-a.b-c. Par exemple :\n 1.0:FR-NETEX_ARRET-1.0 1.1:FR-NETEX_ARRET-1.2-4    x.y étant la version de NeTEx (obligatoire): il s\u0026rsquo;agit ici du numero de version XSD (et WSDL) NeTEx\n  : est un délimiteur obligatoire\n  FR le digramme de la France (ISO 3166-1 alpha-2) (obligatoire)\n  NETEX_nnnnn permet d\u0026rsquo;identifier le profil (obligatoire), nnnn valant \u0026ldquo;FRANCE\u0026rdquo;, \u0026ldquo;COMMUN\u0026rdquo;, \u0026ldquo;ARRET\u0026rdquo;, \u0026ldquo;LIGNE\u0026rdquo;, \u0026ldquo;RESEAU\u0026rdquo;, \u0026ldquo;HORAIRE\u0026rdquo;, \u0026ldquo;CALENDRIER\u0026rdquo; ou \u0026ldquo;TARIF\u0026rdquo;.\n  - est un délimiteur obligatoire\n  a.b est la version du profil (obligatoire). a et b sont des chiffres entiers.\n  - est un délimiteur facultatif (doit être omis si c n\u0026rsquo;est pas présents, obligatoire sinon)\n  c est le numéro de version de l\u0026rsquo;implémentation locale. c est constitué de chiffres et de \u0026ldquo;.\u0026rdquo; uniquement\n  Les principales règles d\u0026rsquo;utilisation des versions sont les suivantes. Soit deux versions de profil N et N+ (N+ étant une version postérieure à N).\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 :\n  (solution non recommandée) Indiquer qu\u0026rsquo;il ne supporte pas cette version en utilisant le code d\u0026rsquo;erreur CapabilityNotSupportedError (voir 8.2) en précisant dans le champ CapabilityRef le numéro de version qui a été demandé (donc N ici)\n  adapter sa réponse pour la rendre conforme à la version N\n  Transférer la requête à un serveur en version N (le \u0026ldquo;transfert\u0026rdquo; peut, techniquement, être réalisé de différentes façons, comme l\u0026rsquo;URL Forwarding, mais ceci relève du choix d\u0026rsquo;implémentation technique).\n    Un client N+ ne peut pas s\u0026rsquo;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\u0026rsquo;erreur, il est recommandé de répondre qu\u0026rsquo;il ne supporte pas cette version en utilisant le code d\u0026rsquo;erreur CapabilityNotSupportedError en précisant dans le champ CapabilityRef le numéro de version qui a été demandé (donc N+ ici)\n  Un client N+ peut s\u0026rsquo;adresser à un serveur N en demandant la version N. La réponse lui est alors retournée en version N.\n  NOTE : Cette gestion de version n\u0026rsquo;est en rien incompatible avec l\u0026rsquo;insertion d\u0026rsquo;un numéro de version dans l\u0026rsquo;URL d\u0026rsquo;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\u0026rsquo;échange.\nModalité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.\nRègles générales  Pas de duplication de ressources NeTEx : pas de duplication des données “classe - identifiant - version” ce qui signifie que deux versions différentes d’un même objet peuvent coexister Éviter les sur-informations : Eviter l\u0026rsquo;ajout d\u0026rsquo;informations dont l\u0026rsquo;utilité n\u0026rsquo;est pas clairement identifiée.  Export sous forme de fichier Un export NeTEx au profil France est une archive ZIP respectant plusieurs contraintes :\n le nom du fichier est libre, mais il est recommandé de préciser qu\u0026rsquo;il s\u0026rsquo;agit d\u0026rsquo;un fichier NeTEx ; l\u0026rsquo;archive ne contient pas de dossiers, tous les fichiers sont listés à la racine ; les fichiers binaires, exécutables et sous archives sont interdits ; d\u0026rsquo;autres fichiers de type texte ou json peuvent figurer dans l’archive mais seront ignorés à l’import ; des mesures de sécurité “propres à chaque consommateur” pourront conduire à des exigences complémentaires.  Les noms des fichiers doivent respecter les contraintes suivantes :\n pas de majuscule le séparateur est “_” pas d’accent pas d\u0026rsquo;espace une taille maximale de 250 caractères hors extension  Les fichiers attendus dans l\u0026rsquo;archive sont les suivants :\n   Fichier Description     accessibility.xml Fichier regroupant les équipements et les informations de cheminement, incluant leur caractéristiques d\u0026rsquo;accessibilité   network.xml Fichier regroupant les informations sur les réseaux et les groupes de lignes   stop.xml Fichier regroupant les informations sur les arrêts, les quais, etc.   line_xyz.xml Chaque fichier contient la description complète d\u0026rsquo;une ligne de transport en commun (parcours, courses, horaires, etc.). La partie \u0026ldquo;xyz\u0026rdquo; du nom de fichier est laissée libre, à condition de respecter l\u0026rsquo;unicité et les contraintes associées aux noms de fichiers. Il est conseillé d\u0026rsquo;utiliser des libellés courts comme les codes des lignes par exemple.   fare.xml Fichier regroupant les informations sur les tarifs, que ce soit pour les transports en commun, les parkings ou autres   parking.xml Fichier regroupant les informations sur les parkings   poi.xml Fichier regroupant les points d\u0026rsquo;intérêts et les informations associées   resource.xml Fichier contenant toutes les informations qui ne sont pas collectés dans des fichiers thématiques (correspondances, calendriers, commentaires, etc.)    Chaque fichier ne contiendra qu’un seul élément racine : PublicationDelivery (voir 7.1). Le fichier XSD de plus haut niveau à utiliser est NeTEx_publication.xsd.\nNotes :\n Même dans le cas où l\u0026rsquo;export NeTEx ne contient qu\u0026rsquo;un seul fichier XML, ce fichier doit être fourni dans une archive ZIP en respectant les critères ci-dessus. Pour tout échange de fichier en dehors d\u0026rsquo;un dépôt sur le Point d\u0026rsquo;Accès National, les parties sont libres d\u0026rsquo;éventuellement s\u0026rsquo;accorder sur un autre format d\u0026rsquo;archive et/ou de noms de fichiers.  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.\nDe 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 particulier :\n  la supervision des connexions avec CheckStatus (chapitre - Vérification de la disponibilité des partenaires du profil SIRI version France)\n  la gestion des erreurs (chapitre - Gestion des erreurs du profil SIRI France)\n  la gestion de la sécurité et des communications (voir profil SIRI France)\n  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).\nLa 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.\nWeb service SOAP de NeTEx\nRequê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.\nGetNeTexService - XSD\nSIRI/NeTEx ServiceRequest — Attributes     Classifi­cation Nom  Type Description     ServiceRequestContext 0:1 +Structure Propriétés générales de la requête.  log RequestTimestamp 1:1 xsd:dateTime Datation de la requête  End­point Prop­erties Address 0:1 Endpoint­Address Adresse à laquelle la réponse doit être retournée (retour à RequestorRef si non précisé).  RequestorRef 1:1 Participant­Code Identifiant du demandeur  MessageIdentifier 0:1\n1 :1\n Message­Qualifier Identifiant unique de la requête de souscription (utilisé dans la réponse).\nComme pour le profil SIRI, ce champ est obligatoire dans le cadre du profil NeTEx \n  Payl­oad AbstractFunctionalServiceRequest 1:* +Structure La ou les requête(s) elles-même    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.\nLa structure ServiceRequestContext est strictement compatible avec celle du profil SIRI (la seule différence étant que le mode abonnement n\u0026rsquo;est pas pris en charge).\nServiceRequestContext (issu du profil SIRI)     ServiceRequestContext +Structure Propriétés générales des requêtes.  Server Endpoint Address CheckStatusAddress 0:1 Endpoint­Address Adresse (URL) de destination du CheckStatus.  Client End­point Address StatusResponseAddress 0:1 Endpoint­Address Adresse (URL) de destination des réponses aux CheckStatus.   ConsumerAddress 0:1 Endpoint­Address Adresse (URL) de destination des données.  Location a WgsDecimalDegrees 0:1 EmptyType Les coordonnées géospatiales sont exprimées en latitude et longitude WGS84, en degrés décimaux d'arc.   b GmlCoordinateFormat  srsNameType Nom du référentiel (GML) de localisation utilisé\nLes deux formats (WGS 84 systèmatique et générique GML) sont autorisés. (note: il existe de nombreux outils libres permettant de convertir les coordonnées d’un référentiel à l’autre).\n  Temporal Span DataHorizon 0:1 Positive­Duration­Type Durée maximale de l’horizon de données des requêtes.  RequestTimeout 0:1 Positive­Duration­Type Délai à partir duquel on peut considérer qu’une requête ne sera plus traitée (par défaut 1 minute).  Delivery Method DeliveryMethod 0:1 fetch | direct Delivery pattern\nAbonnement à une phase (voir en début de document) uniquement : donc direct.\n  MultipartDespatch 0:1 xsd:boolean Autorisation de segmentation des messages : Nondans le profil.  ConfirmReceipt 0:1 xsd:boolean Confirmation des réceptions: Non dans le profil.    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).\nDataObjectRequest- XSD\nNetworkFrameTopic – Element     Classifi­cation Nom Type  Description  TopicGroup sources DataSource 0:* Ce filtre permet de limiter la réponse à des données produites par une ou plusieurs sources de données spécifiées.  Object Request Topic Topic Temporal Scope (choice) Current EmptyType 1:1 (inside a choice) Ce filtre permet de ne demander que la version courante des données (excluant donc les anciennes ou futures versions).    ChangedSince dateTime 1:1 (inside a choice) Permet de demander l’ensemble des données qui ont été modifiées depuis une date donnée.    CurrentAt dateTime 1:1 (inside a choice) Ce filtre permet de ne demander que la version des données dans l’état où elles étaient à une date donnée.    TypeOfFrameRef TypeOfFrame­RefStructure 0:1 Permet de ne consulter que les données d’un type de cadre de version spécifique.\nS’il est utilisé, ce champ ne peut valoir que NETEX_COMMUN, NETEX_ARRET, NETEX_RESEAU, NETEX_HORAIRE, NETEX_CALENDRIER, NETEX_TARIF, NETEX_FRANCE (correspondant à tous les types de CADRE définis par les profils)\n  Topic Frame Scope Choice VersionFrameRef VersionFrame­RefStructure 1:* (inside a choice) Permets de ne consulter que les données d’un cadre de version spécifique.  NetworkFilter­ByValue NetworkFilter­ByValueStructure 1:1 (inside a choice) Filtres additionnels pour la sélection (voir plus bas).    NetworkFilterByValue – Element    Classifi­cation Nom Type  Description     Object By Value BoundingBox BoundingBoxStructure 0:* Ce filtre permet de ne demander que les données à l’intérieur d’un périmètre géographique spécifié.    object­References VersionOfObjectRef 0:* Permet de spécifier l’identifiant de l’objet recherché. Si l’identifiant n’est pas précisé, tous les objets de la classe correspondante sont retournés.   Network Filter By Value NetworkRef NetworkRefStructure 0:1 Permets de n’obtenir que les objets d’un réseau (NETWORK) ou d’un groupe de lignes (GROUP OF LINES) spécifique.    FrameRequestPolicy – Element    Classifi­cation Nom Type  Description     AbstractRequestPolicyGroup MaximumNumberOfElements xsd:integer 0:1 Nombre maximal d’objets à retourner dans la réponse.    IncludeDeleted xsd:boolean 0:1 Indique qu’il faut aussi transmettre les indications d’objets supprimés (arrêt qui n’est plus utilisé, etc.) dans la réponse.    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é.\nGetNeTexServiceResponse - XSD\nServiceDelivery (issu du profil SIRI) — Attributes     ServiceDelivery  +Structure Réponse du producteur au consommateur pour fournir les données utiles. Répond à une requête directe ou à un abonnement de manière asynchrone.    Log Response­Timestamp 1:1 xsd:dateTime Date et heure de production de la réponse.  End­­poi­nt prop­ert­ies ResponseMessage­Identifier 0:1 Message­Qualifier Identifiant du message de réponse   RequestMessageRef 0:1\n1:1\n -Message­Qualifier Référence de la requête.\nObligatoire, en cohérence avec le profil SIRI\n  Stat­us Status 0:1\n1:1\n xsd:boolean Indique si la requête a pu être traitée avec succès ou non.  ErrorCondition 0:1 See below Signalement d’erreur (voir le paragraphe sur la gestion des erreurs).\nVoir le profil SIRI pour le détail de la gestion des erreurs. Le détail des erreurs est porté par le DataObjectDelivery décrit plus bas (voir profil SIRI chapitre Gestion des Erreurs).\n  Payload Concrete SIRI Service:      a DataObject­Delivery 0:* +Structure Corps de la réponse (voir DataObjectDelivery ci-dessous).    ServiceDelivery - XSD\nDataObjectDelivery (issu du profil SIRI) — Attributes     DataObjectDelivery +Structure Qualificateur des réponses.  Log ResponseTimestamp 0:1 xsd:dateTime Date de création de ce statut de réponse.  Choice RequestMessageRef 0:1\n1:1\n Message­Qualifier Référence de la requête.  Pay­load Status 0:1\n1:1\n xsd:boolean Indique si la requête a été traitée normalement ou pas.   Error­Condition 0:1 +Structure Signalement d’erreur (voir profil SIRI, chapitre Gestion des Erreurs).  Info ValidUntil 0:1 xsd:dateTime Date de validité maximale de la réponse.   ShortestPossibleCycle 0:1 Positive­Duration­Type Intervalle minimal de mise à jour de la donnée.   dataObjects 0:* VersionFrame Données échangées dans un contexte de CADRE DE VERSION (voir 7.1).    GetNeTexServiceResponse - XSD\n","permalink":"https://deploy-preview-56--transport-normes.netlify.app/normes/netex/elements_communs/","summary":"Avant-propos\nL’harmonisation des pratiques dans l’échange des données relatives aux offres de transport est essentielle :\n  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) ;\n  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.","title":"NeTEx - Profil France v2.4 - Éléments communs"},{"content":"Avant-propos\nL’harmonisation des pratiques dans l’échange des données relatives aux offres de transport est essentielle :\n  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) ;\n  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 ;\n  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)\n  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\n  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 la partie Arrêts du Profil France de NeTEx : \u0026ldquo;format de référence pour l\u0026rsquo;échange de données de description des arrêts\u0026rdquo; (issu des travaux NeTEx, Transmodel) qui aujourd’hui fait consensus dans les groupes de normalisation (CN03/GT7 – Transport public / information voyageur).\nCe document a été validé et publié comme suit :\n travaux de révision : 2024-2025 date de validation en CN03 : 19 décembre 2025 date de publication : 6 mars 2026  Introduction\nLe présent document fait partie du profil France de NeTEx.\nNeTEx (CEN/TS 16614 series) propose un format et des services d\u0026rsquo;échange de données de description de l\u0026rsquo;offre de transport planifiée, basé sur Transmodel (EN 12896 series). NeTEx permet non seulement d\u0026rsquo;assurer les échanges pour les systèmes d\u0026rsquo;information voyageur mais traite aussi l’ensemble des concepts nécessaires en entrée et sortie des systèmes de planification de l\u0026rsquo;offre (graphiquage, etc.) et des SAE (Systèmes d’Aide à l’Exploitation).\nNeTEx se décompose en six parties:\n  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)\n  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)\n  Partie 3 : information tarifaire (uniquement à vocation d’information voyageur)\n  Partie 4 : profil européen pour l\u0026rsquo;information voyageur (EPIP)\n  Partie 5 : nouveaux modes (les véhicules partagés en libre service, les courses partagées, etc.)\n  Partie 6 : profil européen pour l\u0026rsquo;information voyageur en lien avec l\u0026rsquo;accessibilité (EPIAP)\n  NeTEx a été développé dans le cadre du CEN/TC278/WG3/SG9 piloté par la France. Les premières publications de NeTEx datent de 2014 et les plus récentes de mars 2026.\nIl faut noter que NeTEx a été l\u0026rsquo;occasion de renforcer les liens du CEN/TC278/WG3 avec le secteur ferrovaire, en particulier grâce à la participation de l\u0026rsquo;ERA (Agence Européen du Rail, qui a intégré NeTEx dans la directive Européenne 454/2011 TAP-TSI ) et de l\u0026rsquo;UIC (Union International des Chemins de fer).\nLes 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.\nIl en résulte des normes qui sont relativement volumineuses et dont le périmètre dépasse souvent largement les besoins d\u0026rsquo;une utilisation donnée. Ainsi, à titre d\u0026rsquo;exemple, SIRI propose toute une série d\u0026rsquo;options ou de mécanismes dont la vocation est d\u0026rsquo;assurer la compatibilité avec les systèmes développés en Allemagne dans le contexte des VDV453/454. De même, SIRI propose des services dédiés à la gestion des correspondances garanties, services qui, s\u0026rsquo;ils sont dès aujourd\u0026rsquo;hui pertinents en Suisse ou en Allemagne, sont pratiquement inexistants en France.\nDe plus, un certain nombre de spécificités locales ou nationales peuvent amener à préciser l\u0026rsquo;usage ou la codification qui sera utilisée pour certaines informations. Par exemple, les Anglais disposant d\u0026rsquo;un référentiel national d\u0026rsquo;identification des points d\u0026rsquo;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.\nEnfin, certains éléments proposés par ces normes sont facultatifs et il convient, lors d\u0026rsquo;une implémentation, de décider si ces éléments seront ou non implémentés.\nL\u0026rsquo;utilisation des normes liées à l\u0026rsquo;implémentation de l\u0026rsquo;interopérabilité pour le transport en commun passe donc systématiquement par la définition d\u0026rsquo;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 :\n  détail des services utilisés,\n  détails des objets utilisés dans un échange,\n  précisions sur les options proposées par la norme,\n  précision sur les éléments facultatifs,\n  précision sur les codifications à utiliser,\n  etc.\n  Ce document présente la partie Arrêts du profil France de NeTEx, tel que défini par le Groupe de Travail dédié à l\u0026rsquo;information voyageur et à l\u0026rsquo;exploitation des services de mobilité (GT7) au sein de la Commission Nationale de normalisation pour le transport public (CN03).\nD\u0026rsquo;autres parties du profil France de NeTEx sont disponibles (réseau, horaire, tarif, accessibilité, parking). Ils sont tous complémentaires les uns des autres (sans recouvrement) et s\u0026rsquo;appuient tous sur le document: NeTEx - Profil France - Éléments communs. Il conviendra de se référer à ce document pour tous les éléments utilisés dans le présent document, et dont la structure n\u0026rsquo;est pas détaillée.\nCette partie du profil d’échange a pour objectif de décrire et de structurer précisément les éléments nécessaires à une bonne information de description des arrêts de transport public de façon :\n  à pouvoir les présenter d’une manière homogène et compréhensible à l’usager des transports publics sur des supports différents (papier ou Internet),\n  à pouvoir les échanger entre systèmes d’information (systèmes d’information voyageurs et systèmes d’information multimodale, systèmes d’aide à l’exploitation, systèmes de planification, systèmes billettiques, etc.).\n  Les éléments présentés ci-dessous couvrent donc l’ensemble des concepts propres à la description des arrêts.\nNOTE IMPORTANTE : Ce document étant un profil d\u0026rsquo;échange de NeTEx, il ne se substitue en aucun cas à NeTEx, et un minimum de connaissance de NeTEx sera nécessaire à sa bonne compréhension.\nDomaine d\u0026rsquo;application Le présent document constitue la partie du profil France de la CEN/TS 16614 (NeTEx) pour l\u0026rsquo;échange de données de description d\u0026rsquo;arrêt en France. Il permet de décrire les arrêts de transports publics et la manière dont ils pourront être structurés pour des échanges entre systèmes d\u0026rsquo;information ainsi que pour leur présentation aux voyageurs.\nC\u0026rsquo;est la structure de l\u0026rsquo;arrêt lui-même (ses composants, ses attributs et sa géographie) qui est prise en compte dans ce contexte, et non son insertion dans le contexte de l\u0026rsquo;offre de transport (pas de références aux lignes, aux horaires, etc.).\nRéférences normatives Les documents de référence suivants sont indispensables pour l\u0026rsquo;application du présent document. Pour les références datées, seule l\u0026rsquo;édition citée s\u0026rsquo;applique. Pour les références non datées, la dernière édition du document de référence s\u0026rsquo;applique (y compris les éventuels amendements).\nCEN/TS 16614-1, Network and Timetable Exchange (NeTEx) — Part 1: Public transport network topology exchange format\nCEN/TS 16614-2, Network and Timetable Exchange (NeTEx) — Part 2: Public transport scheduled timetables exchange format\nEN 12896, Road transport and traffic telematics - Public transport - Reference data model (Transmodel)\nTermes et définitions Pour les besoins du présent document, les termes et définitions suivants s\u0026rsquo;appliquent. Une grande partie d’entre eux est directement issue de Transmodel et NeTEx.\nNOTE Les termes spécifiquement introduits par le profil d’arrêt sont signalés par le mot (profil), en italique et entre parenthèses. Les définitions ci-dessous sont des traductions littérales du document normatif.\nNOTE Les définitions ci-dessus sont des traductions littérales du document normatif.\nACCÈS DE LIEU D\u0026rsquo;ARRÊT (STOP PLACE ENTRANCE) (Transmodel)\n Un ACCÈS DE LIEU D\u0026rsquo;ARRÊT est un accès physique à un LIEU D’ARRÊT (entrée ou sortie). Il peut comporter une porte, une barrière, un portillon ou tout autre signe distinctif d’un accès.\n ACCÈS DE SITE (ENTRANCE) (Transmodel)\n Un ACCÈS DE SITE est un accès physique à un SITE (entrée ou sortie). Il peut comporter une porte, une barrière, un portillon ou tout autre signe distinctif d’un accès.\n ADRESSE (ADDRESS) (Transmodel)\n Adresse d\u0026rsquo;un lieu (postale et/ou sur voirie)\n ADRESSE POSTALE (POSTAL ADDRESS) (Transmodel)\n Spécification d\u0026rsquo;une ADRESSE sur la base des attributs conventionnellement utilisés par les services postaux. Cela comprend diverses identifications du bâtiment, le nom de la rue, le code postal et d\u0026rsquo;autres descripteurs.\n ADRESSE SUR VOIRIE (ROAD ADDRESS) (Transmodel)\n Spécification d\u0026rsquo;une ADRESSE sur la base des attributs permettant d’identifier sa position sur la voirie, comme les numéros, types et nom de voies, et les éléments de positionnement le long de la voie.\n COMPOSANT DE LIEU D\u0026rsquo;ARRÊT (STOP PLACE COMPONENT) (Transmodel)\n Un COMPOSANT DE LIEU D\u0026rsquo;ARRÊT est un constituant d\u0026rsquo;un LIEU D\u0026rsquo;ARRÊT qui en décrit une partie de la structure. Les COMPOSANTs DE LIEU D\u0026rsquo;ARRÊT partagent avec le LIEU D\u0026rsquo;ARRÊT lui-même un certain nombre de propriétés pour la gestion des données, l\u0026rsquo;accessibilité et diverses autres caractéristiques.\n COMPOSANT DE SITE (SITE COMPONENT) (Transmodel)\n Un COMPOSANT DE LIEU est un constituant d\u0026rsquo;un SITE qui en décrit une partie de la structure. Les COMPOSANTs DE LIEU partagent avec le LIEU lui-même un certain nombre de propriétés pour la gestion des données, l\u0026rsquo;accessibilité et diverses autres caractéristiques.\n ÉLÉMENT DE SITE (SITE ELEMENT) (Transmodel)\n Type de LIEU définissant des propriétés communes pour les SITEs et COMPOSANTs DE SITES auxquels il correspond, incluant l’ACCESSIBILITÉ.\n ESPACE DE LIEU D\u0026rsquo;ARRÊT (STOP PLACE SPACE) (Transmodel)\n Espace (physique) au sein d\u0026rsquo;un LIEU D\u0026rsquo;ARRÊT, par exemple une ZONE D\u0026rsquo;EMBARQUEMENT, un POINT D\u0026rsquo;EMBARQUEMENT, un LIEU D\u0026rsquo;ÉQUIPEMENT, etc.\n GROUPE DE LIEUX D’ARRÊT (GROUP OF STOP PLACE) (Transmodel)\n Il correspond à une spécialisation de la notion normalisée TRANSMODEL de GROUPE D’ENTITÉs (GROUP OF ENTITIES en anglais).\n LIEU (PLACE) (Transmodel)\n Zone géographique d\u0026rsquo;un quelconque type qui peut être utilisé comme point de départ ou d\u0026rsquo;arrivée d\u0026rsquo;un déplacement. Un lieu peut être de dimension 0 (POINT), 1 (comme une route par exemple) ou 2 (ZONE).\n LIEU D’ARRÊT Monomodal (profil)\n Il correspond à une spécialisation de la notion normalisée de LIEU D\u0026rsquo;ARRÊT (STOP PLACE en anglais) dédiant le LIEU et ses COMPOSANT à un unique MODE.\n LIEU D’ARRÊT Multimodal (profil)\n Il correspond aussi à une spécialisation de la notion normalisée de LIEU D\u0026rsquo;ARRÊT (STOP PLACE en anglais) : un LIEU D’ARRÊT Multimodal n’est composé que de LIEUx D’ARRÊT Monomodaux et Pôles Monomodaux de modes différents.\n LIEU D\u0026rsquo;ARRÊT (STOP PLACE) (Transmodel)\n Lieu comprenant un ou plusieurs emplacements où les véhicules peuvent s’arrêter et où les voyageurs peuvent monter à bord ou descendre des véhicules ou préparer leur déplacement.\n LIEU TOPOGRAPHIQUE (TOPOGRAPHICAL PLACE) (Transmodel)\n Espace géographique offrant un contexte topographique lors de la recherche ou de la présentation d\u0026rsquo;itinéraire (par exemple pour l\u0026rsquo;origine ou la destination du déplacement). Cet espace peut être de toute taille (pays, ville, village, etc.) et correspondre à des périmètres très variés (Greater London, London, West End, Westminster, St James s, etc.).\n Un LIEU TOPOGRAPHIQUE doit toujours disposer d\u0026rsquo;un nom officiel. Il peut être utile/nécessaire de définir une relation hiérarchique entre les LIEUx TOPOGRAPHIQUEs de façon à les distinguer de façon non ambigüe, en particulier en cas d\u0026rsquo;identité de nom.\n MODE DE TRANSPORT (VEHICLE MODE) (Transmodel)\n Le MODE DE TRANSPORT est une caractérisation du transport public correspondant au moyen (véhicule) de transport (bus, tram, métro, train, ferry, bateau, etc.).\n Pôle Monomodal (profil)\n Le Pôle Monomodal correspond à une spécialisation de la notion normalisée de LIEU D\u0026rsquo;ARRÊT (STOP PLACE en anglais) : un Pôle Monomodal n’est composé que de LIEUx D’ARRÊT Monomodaux de modes identiques mais de noms différents.\n POSITION D\u0026rsquo;EMBARQUEMENT (BOARDING POSITION) (Transmodel)\n Emplacement au sein d\u0026rsquo;une ZONE D\u0026rsquo;EMBARQUEMENT à partir desquels les passagers peuvent embarquer, ou vers lequel ils peuvent débarquer du VÉHICULE.\n SITE (SITE) (Transmodel)\n Type de LIEU (comme un LIEU D\u0026rsquo;ARRÊT, un POINT D\u0026rsquo;INTÉRÊT, etc.) vers ou à partir duquel un voyageur peut souhaiter vouloir voyager. Un SITE peut avoir des ENTRÉEs qui en constituent les points d\u0026rsquo;accès (correspondant éventuellement à des besoins utilisateurs particuliers: PMR, etc.).\n SUITE DE TRONÇON (LINK SEQUENCE) (Transmodel)\n Une suite ordonnée de POINTs ou TRONÇONs définissant un chemin à travers le réseau.\n ZONE D’EMBARQUEMENT (QUAY) (Transmodel)\n Lieu tel qu’une plateforme, zone, quai ou voie à quai où les voyageurs peuvent accéder aux véhicules de transport public, taxis, cars ou tout autre mode de transport.\n ZONE TARIFAIRE (TARIFF ZONE) (Transmodel)\n Une ZONE utilisée dans un système de tarification zonale.\n Symboles et abréviations AO\nAutorité Organisatrice de Transports\n PMR\nPersonne à Mobilité Réduite\n Rappel sur la structuration des arrêts La structure proposée est représentée par la figure ci-dessous. C\u0026rsquo;est une structure d\u0026rsquo;imbrication hiérarchique forte, qui s\u0026rsquo;appuie sur une base modale.\nStructuration des arrêts\nLe typage proposé de chaque niveau (voir les définitions) est suffisamment fort pour que cette structure soit très systématique dans sa mise en œuvre: l’objectif est de toujours savoir comment réaliser le groupement et la hiérarchisation face à une situation donnée.\nIl est aussi important de noter qu\u0026rsquo;il n\u0026rsquo;y a pas de récurrence des niveaux : chaque élément d\u0026rsquo;un niveau peut contenir des éléments du niveau directement inférieur, mais il ne contiendra jamais des éléments du même niveau, ou des niveaux supérieurs.\nLes différents acteurs pourront naturellement utiliser tout ou partie de cette structure en fonction de leur besoin et des données dont ils disposent. On pourra toutefois, afin de faciliter l\u0026rsquo;interopérabilité et les échanges, envisager d'«imposer» la disponibilité du niveau Lieu d’Arrêt Monomodal (arrêt commercial) : ce niveau (et uniquement celui-là) semble pouvoir en effet être rendu disponible par tous les acteurs.\nQuatre niveaux hiérarchiques d’arrêt sont disponibles :\n  Groupe de Lieux\n  Lieu d’arrêt multimodal\n  Lieu d’arrêt monomodal et pôle monomodal\n  Zone d’embarquement (Quai de train, voie à quai, poteau de Bus, de Tram …. )\n  La figure ci-dessous fournit une vue arborescente de cette structuration, et y fait de plus apparaître la notion d\u0026rsquo;accès.\nStructuration des arrêts: vue hiérarchique complète\nL\u0026rsquo;accès de lieux peut être rattaché uniquement aux Lieux d’arrêt monomodaux ou aux Lieux d’arrêt multimodaux (voir sa définition ci-dessous).\nExigences minimales liées au code des transports et la règlementation européenne La mise à disposition des données, quand elles existent, est obligatoire et se conforme aux exigences :\n Au niveau européen, du règlement délégué (UE) 2017/1926 de la Commission du 31 mai 2017 modifié par le règlement délégué (UE) 2024/490 de la Commission du 29 novembre 2023 (https://eur-lex.europa.eu/eli/reg_del/2017/1926/2024-03-04), dit \u0026ldquo;règlement MMTIS\u0026rdquo; ; Au niveau français, des articles L. 1115-1 à L. 1115-7 , D. 1115-1, R. 1115-2 à R. 1115-8 et D. 1115-9 à D. 1115-11 du code du transports, notamment créés ou modifiés par les articles 25 et 27 de loi n° 2019-1428 du 24 décembre 2019 d’orientation des mobilités, dites loi « LOM ». Ces mêmes articles de la LOM précise le calendrier de mise à disposition des données.  Le tableau ci-dessous résulte de l’analyse du code des transports et du règlement MMTIS et fournit la liste des concepts concernés dans le présent profil correspondant aux données mentionnées dans l’annexe du règlement. Il sera donc nécessaire de fournir ces données pour être conforme au cadre réglementaire (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).\nNotez que beaucoup de concepts dépendent des concepts issus de Transmodel/NeTEx et sont liés entre eux, soit par héritage, soit par relation au sens UML des termes. Par ailleurs, certains concepts additionnels peuvent relever d’autres parties du profil France, précisés dans le tableau le cas échéant.\nDe plus, 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.\nPour 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).\nLa 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).\nLes 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).\nConcepts relatifs à la LOM et à la Règlementation Européenne     Niveau Catégorie Détail Concepts à minima Autres\nconcepts\n Commentaire    1 Location search (origin/ destination) Address identifiers (building number, street name, postcode) Tous les objets héritant d'ADRESSABLE PLACE ENTRANCE\nQUAI\nPOI\nPARKING L’Adresse est incluse dans tous les objets héritant d'ADRESSABLE PLACE\nAu-delà du Profil Arrêt, les informations d’adresse sont donc attendues pour tous les objets susceptible d’en porter.  1 Location search (origin/ destination) Topographic places (city, town, village, suburb, administrative unit) TOPOGRAPHIC PLACE    1 Location search (access nodes) Identified access nodes (all scheduled modes) STOP PLACE QUAY\n\n(partie réseau)\nSCHEDULED STOP POINT\nPASSENGER STOP ASSIGNMENT\n   1 Location search (access nodes) Geometry/map layout structure of access nodes (all scheduled modes) STOP PLACE QUAY   1 Trip plan computation — scheduled modes transport Stop facilities access nodes (including platform information, help desks/information points, ticket booths, lifts/stairs, entrances and exit locations) STOP PLACE's FACILITIES (partie Accessibilité)\nEQUIPMENT\n   1 Trip plan computation — scheduled modes transport Accessibility of access nodes, and paths within an interchange (such as existence of lifts, escalators) STOP PLACE's FACILITIES (partie Accessibilité)\nEQUIPMENT\nNAVIGATION PATH\n\n   1 Trip plan computation — scheduled modes transport Existence of assistance services (such as existence of on-site assistance) STOP PLACE's FACILITIES (partie Accessibilité)\nLOCAL SERVICE\n     Description du profil d’échange Conventions de représentation Tableaux d’attributs NOTE les choix de conventions présentées ici ont pour vocation d\u0026rsquo;être cohérents avec celle réalisée dans le cadre du profil SIRI (STIF et CEREMA). De plus tous les profils NeTEx partagent les mêmes conventions.\nLes messages constituant ce profil d\u0026rsquo;é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:\n            Classification Nom Type Cardinalité Description      Classification : permet de catégoriser l\u0026rsquo;attribut. Les principales catégories sont:\n  PK (Public Key) que l\u0026rsquo;on peut interpréter comme Identifiant Unique: il permet à lui seul d\u0026rsquo;identifier l\u0026rsquo;objet, de façon unique, pérenne et non ambiguë. C\u0026rsquo;est l\u0026rsquo;identifiant qui sera utilisé pour référencer l\u0026rsquo;objet dans les relations.\n  AK (Alternate Key) est un identifiant secondaire, généralement utilisé pour la communication, mais qui ne sera pas utilisé dans les relations.\n  FK (Foreign Key) indique que l\u0026rsquo;attribut contient l\u0026rsquo;identifiant unique (PK) d\u0026rsquo;un autre objet avec lequel il est en relation.\n  GROUP est un groupe XML nommé (ensemble d\u0026rsquo;attributs utilisables dans différents contextes) (voir http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/#AttrGroups )\n    Nom : nom de l\u0026rsquo;élément ou attribut XSD\n  Type : type de l\u0026rsquo;élément ou attribut XSD (pour certains d\u0026rsquo;entre eux, il conviendra de se référer à la XSD NeTEx)\n  Cardinalité : cardinalité de l\u0026rsquo;élément ou attribut XSD exprimée sous la forme \u0026ldquo;minimum:maximum\u0026rdquo; (\u0026ldquo;0:1\u0026rdquo; pour au plus une occurrence; \u0026ldquo;1:*\u0026rdquo; au moins une occurrence et sans limites de nombre maximal; \u0026ldquo;1:1\u0026rdquo; une et une seule occurrence; etc.).\n  Description : texte de description de l\u0026rsquo;é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).\n  Les textes surlignés en jaune sont ceux présentant une particularité (spécialisation) par rapport à NeTEx: une codification particulière, une restriction d\u0026rsquo;usage, etc.\nLa description XSD utilisée est strictement celle de NeTEx, sans aucune modification (ceci explique notamment que tous les commentaires soient en anglais).\nLes attributs et éléments rendus obligatoires dans le cadre de ce profil restent facultatifs dans l\u0026rsquo;XSD (le contrôle de cardinalité devra donc être réalisé applicativement).\nValeurs 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 :\n  des énumérations fixes définies dans le cadre du schéma XSD NeTEx. Le profil impose alors un sous-ensemble des codes NeTEx.\n  des 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\u0026rsquo;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».)\n  des instances TypeOfFrame: le profil utilise plusieurs TYPES DE FRAME pour spécifier l\u0026rsquo;utilisation de VERSION FRAME dans le profil.\n  Indication des classes abstraites NeTEx et Transmodel utilisent largement l\u0026rsquo;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’existe aucune instance concrète; seules les sous-classes terminales sont «concrètes».\nUn inconvénient de l\u0026rsquo;héritage est que si l\u0026rsquo;on veut comprendre les propriétés d\u0026rsquo;une classe concrète unique, il faut également examiner toutes ses super-classes. Pour cette raison, le profil 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.\n  Les super-classes sont signalées dans les en-têtes par le suffixe «(abstrait)»\n  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.\n  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.\n  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)».\nLieux d\u0026rsquo;arrêt (monomodal, multimodal et pôle monomodal) LIEU D’ARRÊT Monomodal Il correspond à une spécialisation de la notion normalisée de LIEU D\u0026rsquo;ARRÊT (STOP PLACE en anglais): Lieu comprenant un ou plusieurs emplacements où les véhicules peuvent s’arrêter et où les voyageurs peuvent monter à bord ou descendre des véhicules ou préparer leur déplacement.\nCe type de lieu ne contiendra que des possibilités d’accès à des véhicules d’une même catégorie de mode (le mode desservi sera donc l’un de ses attributs). Il correspond à ce qui est souvent appelé arrêt commercial (mais les vocabulaires varient…).\nIl peut contenir des ZONEs D’EMBARQUEMENT. S’il en contient, c’est un regroupement des ZONEs D’EMBARQUEMENT dédiées à un même mode. Si toutefois l’information n’est pas disponible, le LIEU D’ARRÊT Monomodal pourra ne pas référencer de ZONE D’EMBARQUEMENT.\nToutes les ZONEs D’EMBARQUEMENT d’un LIEU D’ARRÊT Monomodal doivent être de même type (voir l’attribut Type de ZONE D’EMBARQUEMENT, ou de types « compatibles » cette compatibilité se limitant à permettre un groupement de quais et de poteaux. Le tableau ci-dessous présente les types de ZONE D’EMBARQUEMENT et la façon dont on peut les associer au sein d’un même LIEU D’ARRÊT Monomodal.\nNOTE : le mode d’une ZONE D’EMBARQUEMENT est son mode principal, elle peut donc être desservie par différents modes « compatibles » (colonne de droite du tableau).\nTypes de ZONE D’EMBARQUEMENT et compatibilité des modes     Type de ZONE D’EMBARQUEMENT Autres types de ZONE D’EMBARQUEMENT « compatibles » Mode de transport possible    Quai de gare (ferré) aucun   Ferré (inclus sous mode Tram-Train (inclus sous mode Tram-Train à interpréter Train-Tram dans ce cas-là))    Quai de métro aucun   Métro Funiculaire    Quai de tram Arrêt de tram   Tram (inclus sous mode Tram-Train)    Arrêt de tram (poteau) Quai de tram   Tram    Arrêt de bus, autocar ou trolley (généralement poteau, sans matérialisation de quai) Quai de bus, autocar ou trolley   Bus Car Trolley    Quai de bus, autocar ou trolley Arrêt de bus, autocar ou trolley   Bus Car Trolley    Quai de bateau Accostage de ferry   Maritime ou Fluvial    Accostage de ferry Quai de bateau   Maritime ou Fluvial    Quai de téléphérique aucun   Transport par câble (télécabine, etc.)    Porte d'aéroport aucun   Aérien      Le LIEU D’ARRÊT Monomodal, en plus de la contrainte de catégorie de mode, porte une contrainte de nom: toutes les zones d’embarquement d’un LIEU D’ARRÊT Monomodal portent le même nom (si ce n’est pas le cas, on définit plusieurs LIEU D’ARRÊT Monomodaux que l\u0026rsquo;on regroupe au sein d\u0026rsquo;un Pôle Monomodal). Notez que dans le cas des trains, l’éventuel nom de voie (« A », « 2B », « 2 » , etc.) est précisé par un PublicCode et non par le nom.\nLe LIEU D’ARRÊT Monomodal ne peut pas contenir d’autre LIEU D’ARRÊT.\nLa notion de correspondance est implicite au sein d\u0026rsquo;un LIEU D’ARRÊT Monomodal.\nUne ZONE D’EMBARQUEMENT n’appartient qu’à un seul LIEU D’ARRÊT Monomodal.\nLe LIEU D’ARRÊT Monomodal peut être typé (attribut StopPlaceType). En plus de son mode principal, elle dispose des types présentés en 7.2.10.1. Ces types, quand ils sont utilisés pour un LIEU D’ARRÊT Monomodal ont aussi une portée d\u0026rsquo;information complémentaire :\n  Pour tous les types, autres que les trois ci-dessous (arrêts commerciaux au sens large): le LIEU D’ARRÊT Monomodal contient obligatoirement des ZONEs D’EMBARQUEMENT portant le même nom et correspondant généralement (mais pas obligatoirement) à l’aller et au retour d’une ou plusieurs lignes.\n  Gare: station ferrée (n’a pas l’obligation de référencer de ZONEs D’EMBARQUEMENT)\n  Aéroport: dédié à l’aérien (n’a pas l’obligation de référencer de ZONEs D’EMBARQUEMENT)\n  Port: dédié au maritime ou au fluvial (n’a pas l’obligation de référencer de ZONEs D’EMBARQUEMENT)\n  Pôle Monomodal Il correspond aussi à une spécialisation de la notion normalisée Transmodel de LIEU D\u0026rsquo;ARRÊT (STOP PLACE en anglais).\nDans un certain nombre de cas, on trouve des LIEUx D’ARRÊT Monomodaux de même mode et portant des noms différents, mais que l’on souhaite grouper ensemble (pour des raisons de proximité et de correspondance): on utilise alors un Pôle Monomodal.\nCe type de lieu contiendra au moins deux LIEUx D’ARRÊT Monomodaux.\nIl ne contient pas de ZONE D’EMBARQUEMENT (plus précisément, il contient des LIEUx D’ARRÊT Monomodaux qui eux peuvent contenir des ZONEs D’EMBARQUEMENT).\nLa notion de correspondance est implicite au sein d\u0026rsquo;un Pôle Monomodal. Cela signifie qu\u0026rsquo;une correspondance est possible (en termes de distance) entre n\u0026rsquo;importe quel couple de ZONE D’EMBARQUEMENT des LIEUx D’ARRÊT Monomodaux constituant le Pôle Monomodal. Toutefois cela n\u0026rsquo;implique pas nécessairement la mise en cohérence des horaires de passage des lignes desservant le Pôle.\nLIEU D’ARRÊT Multimodal Il correspond aussi à une spécialisation de la notion normalisée Transmodel de LIEU D\u0026rsquo;ARRÊT (STOP PLACE en anglais).\nCe type de lieu contiendra impérativement des possibilités d’accès à des véhicules de plusieurs modes.\nIl contiendra au moins deux objets fils (de type LIEUx D’ARRÊT Monomodal ou Pôle Monomodal).\nIl ne contient pas de ZONE D’EMBARQUEMENT (plus précisément, il contient des LIEUx D’ARRÊT Monomodaux, éventuellement en passant par des Pôles Monomodaux, qui eux peuvent contenir des ZONEs D’EMBARQUEMENT).\nLa notion de correspondance est implicite au sein d\u0026rsquo;un LIEU D’ARRÊT Multimodal. Là encore cela signifie qu\u0026rsquo;une correspondance est possible (en terme de distance) entre n\u0026rsquo;importe quel couple de ZONE D’EMBARQUEMENT des LIEUx D’ARRÊT Monomodaux contenus dans le LIEU D’ARRÊT Multimodal, et n\u0026rsquo;implique pas nécessairement la mise en cohérence des horaires de passage des lignes desservant le LIEU.\nLe LIEU D’ARRÊT Multimodal dispose d’un attribut indiquant son mode « de plus haut niveau » : la hiérarchisation des modes suivante est proposée\n  Aérien\n  Maritime/Fluvial\n  Ferré\n  Métro\n  Tram\n  Funiculaire/Câble\n  Bus/Car/Trolley\n  Modèle de données STOP PLACE – Modèle conceptuel\nL\u0026rsquo;objet le plus haut dans l\u0026rsquo;arbre d\u0026rsquo;héritage est la ZONE, décrivant un objet générique à deux dimensions. Une ZONE peut être définie par un GROUPE DE POINTS appartenant à la ZONE, et peut également être définie comme une zone géométrique, bordée d\u0026rsquo;un polygone.\nUne ZONE peut contenir d\u0026rsquo;autres ZONEs plus petites. Ceci est exprimé par la relation réflexive sur ZONE (donc une STOP PLACE peut inclure d\u0026rsquo;autres STOP PLACE comme tous les objets qui héritent de la ZONE).\nUne ZONE peut être représentée par un seul POINT (par l\u0026rsquo;attribut *Centroïd) ***qui peut être utilisé comme une référence ponctuelle à la ZONE elle-même. Ceci est utile pour représenter les systèmes de transport flexibles (où un arrêt est souvent un ZONE).\nLe deuxième niveau de la hiérarchie est la PLACE, qui représente n\u0026rsquo;importe quel endroit significatif qu\u0026rsquo;un modèle de transport peut vouloir décrire, et pour lequel la possibilité de voyage peut exister (départ, arrivée ou point de passage). Une PLACE peut être spécialisée de diverses manières, notamment une TOPOGRAPHIC PLACE (une ville, un département ou une région nommée), ou une ADDRESSABLE PLACE spécifique ayant un ADRESS qui est soit un ROAD ADDRESS, soit un POSTAL ADDRESS.\nL’élément de site spécialisé ADDRESSABLE PLACE peut être utilisé pour ajouter l\u0026rsquo;accessibilité (voir ACCESSIBILITY ASSESMENT) et d\u0026rsquo;autres propriétés communes à tout lieu pouvant être parcouru par un passager. Le SITE spécialise l’ELEMENT DE SITE pour fournir une description générale des propriétés communes d\u0026rsquo;un lieu, tel qu\u0026rsquo;une station ou un point d\u0026rsquo;intérêt, y compris ses entrées, niveaux, équipements, cheminements, propriétés d\u0026rsquo;accessibilité, etc. Le SITE est lui-même spécialisé en STOP PLACE, POINT D\u0026rsquo;INTERET, PARKING, etc.\nLa STOP PLACE décrit différents aspects d’un point d’accès physique au transport, comme un arrêt ou une gare. Pour un lieu complexe, tel qu\u0026rsquo;une station, cela inclut toutes les zones composant la station: les entrées, les halls, les plates-formes, les niveaux sur lesquels elles se trouvent, etc.\nil est à noter qu\u0026rsquo;un lieu d\u0026rsquo;arrêt est un concept distinct de la représentation de l\u0026rsquo;arrêt dans une table horaire- SCHEDULED STOP POINT. Les deux peuvent être liés à l\u0026rsquo;aide d\u0026rsquo;un STOP ASSIGNMENT. Physiquement, le SCHEDULED STOP POINT peut correspondre soit à un STOP PLACE entier, soit à un QUAY spécifique\nPuisqu\u0026rsquo;ils héritent aussi d\u0026rsquo;une relation d\u0026rsquo;inclusion de la ZONE, les QUAY peuvent être imbriqués. Cela permet de représenter des plates-formes composites à deux côtés ou plus ou à des sections nommées.\nAttributs du LIEU D’ARRÊT (StopPlace) StopPlace     Classifi­cation Nom Type  Description  :: :: Site :: STOP PLACE hérite de SITE.\nNOTE L'identification du STOP PLACE a pour vocation à être codifiée. Sa codification est décrite le document éléments communs.\n  «AK» PublicCode StopPlaceCodeType 0:1 Code court connu du public pour identifier le LIEU D'ARRÊT (utilisé par exemple pour les services SMS, etc.)  STOP PLACE COMP­ONENT GROUP TransportMode VehicleModeEnum 1:1 Mode de transport principal pour le LIEU. La liste des modes est présentée en 6.17 dans le Profil Éléments Communs.  (Choice) AirSubmode\nBusSubmode\nCoachSubmode\nFunicularSubmode\nMetroSubmode\nTramSubmode\nTelecabinSubmode\nRailSubmode\nWaterSubmode\n 0:1 Sous mode associé au mode (caractérise le type d’exploitation). Les sous modes sont une énumération dont les valeurs sont présentées en 7.2.10.\nIl faut noter le cas particulier du Tram-Train qui, bien qu'étant classé en sous-mode du TRAM, peut aussi être utilisé en sous-mode du Ferré.\n  submode TransportSubmodeEnum 0:1 Sous-Mode associé au mode  OtherTransport­Modes VehicleModeEnum 0:* Liste des autres modes de transport desservant le LIEU D'ARRÊT.  tariffZones FareZoneRef 0:* Identifiant de la zone tarifaire (ou section selon les cas) précisé dans le fichier `fare.xml`.\nSi la zone tarifaire n'est pas précisée (le champ étant facultatif) mais que la StopPlace est inclue dans une autre (LIEU D'ARRÊT MONOMODAL dans une LIEU D'ARRÊT MULTIMODAL par exemple) qui lui a une FareZone, alors la ou les zones tarifaires du StopPlace parent s'appliquent.\nLe profil France fait une restriction de la norme NeTEx en demandant explicitement une FareZoneRef, alors que NeTEx indique TariffZone (dont FareZone est une spécialisation).\n  STOP PLACE PROPERTY GROUP StopPlaceType StopPlaceTypeEnum 1:1 Type du LIEU D'ARRÊT (voir les définitions en 7.2.10.1 ).   BorderCrossing xsd:boolean 0:1 Indique s’il y a un passage de frontière à ce Lieu d’Arrêt.   Weighting InterchangeUseEnum 0:1 Qualification de la possibilité de correspondance au sein du lieu d’arrêt\n noInterchange\n interchangeAllowed (valeur par défaut si le champ n’est pas renseigné)\n preferredInterchange (indique que le Lieu d’Arrêt est spécialement conçu pour faciliter les échanges, avec des chemins de guidage de chemin, un chemin de promenade facile, sécurisé et court, etc.).\n    StopPlaceWeight StopPlaceWeightEnum 0:1 Les lieux d'arrêt peuvent être classés en fonction de leur importance relative (le « rayonnement » de la gare et le type de réseau auquelle elle donne accès).\n international\n national\n regional\n local\n   STOP PLACE PASS­ENGER GROUP quays Quay 0:* Liste des identifiants (le profil fait le choix de définir les ZONEs D’EMBARQUEMENT indépendaemment et de les référencer) des ZONEs D'EMBARQUEMENT contenues dans le LIEU (exclusivement pour les LIEUx D'ARRÊT de type LIEUX D'ARRÊT MONOMODAL).    NOTE IMPORTANTE : Le profil France rend obligatoire l\u0026rsquo;attribut Location du STOP PLACE\nAttributs de Place Place – Element (abstrait)     Classifi­cation Name Type  Description  :: :: Zone :: PLACE hérite de ZONE (voir le document éléments communs).  «cntd» placeTypes TypeOfPlaceRef 0:*\n0:1\nspécial\n Cet attribut n'est utilisé que pour les LIEUx D'ARRÊT et les zones administratives (TOPOGRAPHIC PLACE), et il est alors obligatoire, et sa cardinalité est alors 1:1.\nPour le LIEU D'ARRET Codification permettant de distinguer les:\n  LIEU D'ARRÊT MONOMODAL \nvaleur: monomodalStopPlace\n  PÔLE MONOMODAL\nvaleur: monomodalHub\n  LIEU D'ARRÊT MULTIMODAL\nvaleur: multimodalStopPlace\n  Type de zones administratives françaises (TOPOGRAPHIC PLACE), qui doit être cohérent avec les Topographic-PlaceType (voir ):\n  RÉGION \nvaleur: region\n  DÉPARTEMENT \nvaleur: department\n  GROUPEMENT DE COMMUNES \nvaleur: urbanCommunity\n  VILLE \nvaleur: town\n  ARRONDISSEMENT \nvaleur: district\n     EXEMPLE À titre d\u0026rsquo;exemple, le type de LIEU D\u0026rsquo;ARRÊT peut être décrit de la façon suivante:\n\u0026lt;placeTypes\u0026gt;\u0026lt;TypeOfPlaceRef ref=\u0026ldquo;monomodalStopPlace\u0026rdquo;/\u0026gt;\u0026lt;/placeTypes\u0026gt;\nAttributs du AddressablePlace AddressablePlace – Element (abstrait)    Classifi­cation Nom Type  Description     ::\u0026gt; ::\u0026gt; ADDRESSABLE PLACE ::\u0026gt; ADDRESSABLE PLACE hérite de PLACE.    Url xsd:anyURI 0:1 Url d\u0026rsquo;information associée au lieu    Image xsd:anyURI 0:1 Image et photo du lieu (en ligne)    PostalAddress PostalAddress 0:1 Adresse postale    RoadAddress RoadAddress 0:1 Adresse sur voirie    Attributs du SiteElement SiteElement – Element (abstrait)     Classifi­cation Nom Type  Description  :: :: PLACE :: SITE ÉLÉMENT hérite de ADDRESSABLE PLACE.  «cntd» AccessibilityAssessment AccessibilityAssessment 0:1 Information globale précisant le niveau d'accessibilité du LIEU D'ARRÊT, de la ZONE D'EMBARQUEMENT ou de l'ACCÈS.\nVoir le détail dans l'annexe 9 du profil Accessibilité.\n  «cntd» AccessModes AccessModeEnum 0:* Liste des modes utilisables (il peut donc y en avoir plusieurs) pour accéder à ce LIEU D'ARRÊT (renseigné uniquement pour les LIEUx D'ARRÊT):\n  foot: À pied\n  bicycle : En vélo (il y a un garage à vélo ou une station de vélos partagés)\n  boat : Bateau\n  car : Voiture (il y a un parking, ou une station d'auto partagée)\n  taxi : Taxi (il y a une borne taxi)\n  shuttle : Navette (une navette dessert le lieu)\n  Note: ne pas confondre avec le mode principal du LIEU D'ARRÊT (on qualifie ici les façons possibles de se rendre au LIEU D'ARRÊT, par exemple \"je peux me rendre à la gare en vélo…\" sous-entendu, \"il y a bien un parking à vélo\"…)\n  «cntd» alternativeNames AlternativeName 0:* Nom(s) alternatif(s) (potentiellement multiple) du LIEU D'ARRÊT, de la ZONE D'EMBARQUEMENT ou de l'ACCÈS.\nVoir le détail dans le profil Éléments Communs.\n   CrossRoad MultilingualString 0:1 Identification du croisement (nom des rues de l'intersection) où se situe le LIEU D'ARRÊT, la ZONE D'EMBARQUEMENT ou l'ACCÈS..  Landmark MultilingualString 0:1 Nom d'un repère proche du LIEU D'ARRÊT, de la ZONE D'EMBARQUEMENT ou de l'ACCÈS (par exemple \"en face du café XXX\", \"juste après la bouche d'incendie\", etc.).   SiteElement­PropertiesGroup Element­PropertiesGroup 0:1 Propriétés complémentaires de l’élément, voir ci-dessous..    SiteElementPropertiesGroup – Group (objet inclus)     Classifi­cation Name Type  Description   PublicUse PublicUseEnum 0:1 Indique par quel public le lieu est utilisable:\n  disabledPubicOnly: Personnes handicapées uniquement\n  authorisedPublicOnly: Personnes autorisées uniquement\n  staffOnly: Réservé au personnel\n  publicOnly: Réservé au public\n  all: Tout public\n    Covered CoveredEnum 0:1 Indique si le lieu est couvert\n indoors: Intérieur\n outdoors: Extérieur\n covered: Couvert (extérieur)\n mixed: Mixte\n unknown: Information non connue\n    Gated GatedEnum 0:1 Indique si l'on accède au lieu par des portes :\n openArea: Accès ouvert\n gatedArea: Accès par porte\n unknown: Information non connue\n    Lighting LightingEnum 0:1 Indique si le lieu est éclairé :\n wellLit: Bien éclairé\n poorLit: Faiblement éclairé\n unlit: Non éclairé\n unknown: Information non connue\n     Attributs du Site Site – Element (abstrait)     Classifi­cation Nom Type  Description  :: :: SiteElement :: SITE hérite de SITE ÉLÉMENT.  «FK» TopographicPlaceRef TopographicPlaceRef 0:1 Référence à la zone administrative à laquelle appartient le LIEU D'ARRÊT, la ZONE D'EMBARQUEMENT ou l'ACCÈS (il s'agira ici uniquement d'une zone administrative de type Ville ou Arrondissement: c'est la structure administrative elle-même qui décrira les inclusions dans les zones administratives \"supérieures\").   additionalTopographicPlaces topographicPlaceRefs 0 :* Un LIEU D'ARRÊT peut avoir des composants dans plusieurs communes d’où la cardinalité : ce champ permet de référencer toutes ces zones administratives (la précédente étant la principale).\nCet attribut n'est utilisé que pour les LIEUx D'ARRÊT\n   Locale Locale 0:1 Information locales liées au LIEU D'ARRÊT, ZONE D'EMBARQUEMENT ou ACCÈS comme le fuseau horaire, la langue, etc.\nVoir Profil Éléments Communs.\n  «FK» OrganisationRef OrganisationRef 0:1 Identifiant de l'exploitant du LIEU (référence une INSTITUTION).  «FK» ParentSiteRef SiteRef 0:1 Référence au LIEU D'ARRÊT \"contenant\" le présent LIEU. Cette liaison est contrainte en fonction de la spécialisation du LIEU D'ARRÊT:\n LIEU D'ARRET MONOMODAL : parent= LIEU D'ARRÊT MULTIMODAL ou POLE MONOMODAL\n POLE MONOMODAL : parent= LIEU D'ARRÊT MULTIMODAL\n LIEU D'ARRÊT MULTIMODAL = pas de parent\nCet attribut n'est utilisé que pour les LIEUx D'ARRÊT\n   «cntd» levels Level 0:* Liste des niveaux (étages) du lieu d'arrêt. Ils sont identifiés par leur nom : cela peut être \"1\", \"A\", \"Banlieue\", etc.\nOn aura par exemple:\n\n\nCet attribut n'est utilisé que pour les LIEUx D'ARRÊT\n  «cntd» entrances Entrance 0:* Lien vers les entrées du LIEU (référence des ACCÈS)\nCet attribut n'est utilisé que pour les LIEUx D'ARRÊT\n    Enumérations pour les LIEUx D’ARRÊT Les type de LIEU D\u0026rsquo;ARRÊT types de LIEU D'ARRÊT.    Value Description     onstreetBus Arrêt de bus sur la voirie   busStation Gare routière   coachStation Station d\u0026rsquo;autocars   onstreetTram Arrêt de TRAM sur la voirie   tramStation Station de TRAM   railStation Station ferrée   vehicleRailInterchange Station ferrée d\u0026rsquo;embarquement ou de débarquement de véhicules   metroStation Station de métro   Airport Aéroport   ferryPort Port Ferry   harbourPort Port   ferryStop Arrêt simple de Ferry   liftStation Station de téléphérique   Other Autre    Le tableau ci-dessous présente les types de LIEU D\u0026rsquo;ARRÊT, les types de ZONE D\u0026rsquo;EMBARQUEMENT qu\u0026rsquo;ils peuvent contenir et la liste des modes correspondants.\nTypes de LIEU D'ARRÊT, Types de ZONE D’EMBARQUEMENT et modes     Types de LIEU D'ARRÊT Type de ZONE D’EMBARQUEMENT Mode de transport possible    Station ferrée Quai de gare (ferré)\nou\nzone d'embarquement de véhicules\n  Ferré\n(inclus sous mode Tram-Train à interpréter Train-Tram dans ce cas-là)\n  Station de métro Quai de métro  Métro\nFuniculaire\n  Arrêt de TRAM sur la voirie\nou\nStation de TRAM\n Quai de tram  Tram\n(inclus sous mode Tram-Train)\n  Arrêt de TRAM sur la voirie\nou\nStation de TRAM\n Arrêt de tram (poteau)  Tram\n  Arrêt de bus sur la voirie\nou\nGare routière\n Arrêt de bus, autocar ou trolley (généralement poteau, sans matérialisation de quai)\nou\nQuai de bus, autocar ou trolley\n  Bus\nCar\nTrolley\n  Station d'autocars Arrêt d'autocar\nou\nQuai d'autocar\n  Car\n  Port Quai de bateau  Maritime ou Fluvial\n  Port Ferry\nou\nArrêt simple de Ferry\n Accostage de ferry  Maritime ou Fluvial\n  Station de téléphérique Quai de téléphérique  Transport par câble (télécabine, etc.)\n  Aéroport Porte d'aéroport  Aérien\n    Groupe de lieux GroupOfStopPlaces - Element    Classifi­cation Name Type Cardin­alité Description     ::\u0026gt; ::\u0026gt; GroupOfEntities ::\u0026gt; GroupOfStopPlaces hérite de GroupOfEntities   «PK» id GroupOfStopPlacesIdType 1:1 Identifiant du GROUP of STOP PLACEs.   «cntd» members StopPlaceRef 0:* STOP PLACEs composant le GROUP of STOP PLACEs.   «enum» TransportMode VehicleModeEnum 0:1 Principal MODE de transport pour ce groupe Voir STOP PLACE pour les valeurs.   «enum» TransportSubmode SubmodeEnum 0:1 Principal SOUS MODE de transport pour ce groupe    Note : de façon à assurer la compatibilité avec les travaux d’Île-de-France Mobilité, on conserve temporairement la possibilité de décrire le groupe de lieux, avec un GroupOfEntities dont le champ PurposeofGroupingRefsera instancié avec \u0026ldquo;groupOfStopPlace\u0026rdquo; et dont memberscontient la liste des identifiants des membres des GROUPEs DE LIEUX D\u0026rsquo;ARRÊT (ce sont donc exclusivement des identifiants de LIEU D\u0026rsquo;ARRÊT). Cette possibilité n’est valable que pour les données produite en Île-de-France.\nZone d\u0026rsquo;embarquement La ZONE D\u0026rsquo;EMBARQUEMENT, présenté si dessous, est en partie bâtie sur la base de groupes XSD déjà présentés dans le document: NeTEx - Profil Français de NETEx: éléments communs:\n  DataManagedObject\n  GroupOfEntities\n  Zone\nEt d\u0026rsquo;autres présenté dans les paragraphes précédents\n  Place: 7.2.6\n  SiteElement: 7.2.8\n  Quay (traduit par ZONE D'EMBARQUEMENT en français) – Element     Classifi­cation Nom Type  Description  :: :: StopPlaceSpace :: QUAY hérite de STOP PLACE SPACE et STOP PLACE COMPONENT.\nNOTE Pour les ZONE D'EMBARQUEMENT l'identification a pour vocation à être codifiée: voir Éléments Communs.\n  QUAY IDENTIFIER GROUP PublicCode xsd:normalizedString 0:1 Code court connu du public pour identifier le LIEU D'ARRÊT (utilisé par exemple pour les services SMS, etc.)\nDans le cas des trains, en particulier, le nom des voies (« Voie A », « Voix 2B », « Voix 1 », etc.) est à mettre dans ce PublicCodeet non dans le Name(qui contiendra le nom de l’arrêt, « Versailles Chantier » par exemple, de façon à ce qu’un service d’information voyageur puis indique « descendez à Versailles Chantier » et précise « Voie 2B » et ne se contente pas de dire « descendez voix 2B »…)\n   PlateCode xsd:normalizedString 0:1 Code inscrit sur la plaquette ou le sticker de l'arrêt  QUAY DESCRIPTOR GROUP CompassBearing CompassBearingType 0:1 Orientation de la voie, en degrés (au niveau de la ZONE D'EMBARQUEMENT).   QuayType QuayTypeEnum 0:1 Type codifié de ZONE D'EMBARQUEMENT:\n airlineGate: Porte d'aéroport\n railPlatform: Quai de gare (ferré)\n vehicleLoadingPlace: zone d'embarquement de véhicules (ferré)\n metroPlatform: Quai de métro\n busStop: Arrêt de bus, autocar ou trolley (généralement poteau, sans matérialisation de quai)\n busBay: Quai de bus, autocar ou trolley\n coachStop: peut être utilisé au lieu de busStop si la ZONE D'EMBARQUEMENT est réservée aux autocars\n tramPlatform: Quai de tram\n tramStop: Arrêt de tram (poteau)\n boatQuay: Quai de bateau\n ferryLanding: Accostage de ferry\n telecabinePlatform: Quai de téléphérique\n  NOTE NeTEx propose aussi taxiStand, setDownPlaceet other mais ces valeurs ne sont pas retenues dans le cadre du présent profil.\n  «FK» ParentQuayRef QuayRef 0:1 Référence au parent de QUAY qui le contient entièrement. (permet de subdiviser les quais et de gérer les relations quai-voies à quai par exemple).    NOTE IMPORTANTE : Le profil France rend obligatoire l\u0026rsquo;attribut Location du QUAY\nEspace de Lieu d’Arrêt – Element (abstrait)    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; SiteComponent ::\u0026gt; STOP PLACE SPACE hérite de SITE COMPONENT.    Label xsd:normalizedString 0:1 Label associé à l’espace    Attributs SiteComponent SiteComponent – Element (abstrait)     Classifi­cation Nom Type  Description  :: :: SiteElement :: SITE COMPONENT hérite de SITE ÉLÉMENT.  «FK» SiteRef SiteRef 0:1\n1:1\n Pour une ZONE D'EMBARQUEMENT, il s'agit de l'identifiant du LIEU D'ARRÊT MONOMODAL dont dépend la ZONE D'EMBARQUEMENT.\nPour un ACCÈS il s'agit de l'identifiant du LIEU D'ARRÊT MONOMODAL, POLE MONOMODAL ou LIEU D'ARRÊT MULTIMODAL auquel mène l'ACCÈS.\nCet attribut est obligatoire dans le cadre du profil.\nNote : de plus, notament pour faciliter les conversions vers le profil Européen, on systématisera l’includion XML des SiteComponentsdans les Sites.\n  «FK» LevelRef LevelRef 0:1 Niveau (étages) du lieu d'arrêt auquel se situe la ZONE D'EMBARQUEMENT ou l'ACCÈS. Il est identifié par son nom : cela peut être \"1\", \"A\", \"Banlieue\", etc.    Attributs de StopPlaceComponent StopPlaceComponent – Element (abstrait)     Classifi­cation Nom Type  Description   TransportMode VehicleModeEnum 0:1\n1:1\n Mode de transport principal pour la ZONE D'EMBARQUEMENT. La liste des modes est présentée en 5.15 dans le Profil Éléments Communs.\nCet attribut est obligatoire dans le cadre du profil.\n   (Choice) AirSubmode\nBusSubmode\nCoachSubmode\nFunicularSubmode\nMetroSubmode\nTramSubmode\nTelecabinSubmode\nRailSubmode\nWaterSubmode\n 0:1 Sous mode associé au mode (caractérise le type d’exploitation). Les sous modes sont des énumérés dont les valeurs sont présentées en 7.2.10.\nIl faut noter le cas particulier du Tram-Train qui, bien qu'étant classé en sous-mode du TRAM, peut aussi être utilisé en sous-mode du Ferré.\n   tariffZones FareZoneRef 0:* Identifiant de la zone tarifaire (ou section selon les cas) précisé dans le fichier `fare.xml`. Voir la desciption du champ `tariffZones` de l'objet StopPlace pour les précisions sur l'héritage.     Accès StopPlaceEntrance – Element     Classifi­cation Nom Type  Description  :: :: Entrance :: STOP PLACE ENTRANCE. hérite de SITE ENTRANCE.\nNOTE StopPlaceEntrancen'utilise pas le placeGroupdans le cadre du profil .\n  GROUP StopPlace­ComponenGroup StopPlaceComponent­PropertyGroup 0:1 Propriétés communes avec le COMPOSANT DE LIEU D'ARRÊT (voir 7.4.2-Attributs de StopPlaceComponent plus haut).    Entrance – Element     Classifi­cation Nom Type  Description  :: :: SiteComponent :: ENTRANCE hérite de SITE COMPONENT.  SITE COMP­ONENT GROUP PublicCode xsd:normalizedString 0:1 Code de l'accès connu du public (généralement un numéro ou une lettre)  Label xsd:normalizedString 0:1 Label associé à l’entrée (généralement lettre ou numéro).  EntranceType EntranceTypeEnum 0:1 Type codifié de l'accès :\n opening: Ouvert\n openDoor: Porte Ouverte\n door: Porte\n swingDoor: Porte battante\n revolvingDoor: Porte à tambour\n automaticDoor Porte automatique\n ticketBarrier: Portillon à ticket\n gate: Barrière\n other: autre\n   IsExternal xsd:boolean 0:1 Indique s'il s'agit d'un ACCÈS extérieur ou intérieur (via un centre commercial par exemple)  IsEntry xsd:boolean 0:1 Indique que c'est une entrée  IsExit xsd:boolean 0:1 Indique que c'est une sortie  Width LengthType 0:1 Largeur de l’entrèe.  Height LengthType 0:1 Hauteur de l’entrée.  EXTERNAL ENTRANCE GROUP DroppedKerb­Outside xsd:boolean 0:1 Marche abaissée à l’entrée (à mettre à false pour indiquer une marche)    Zone administrative Aucun champ spécifique utilisé\nTopographicPlace – Element     Classifi­cation Nom Type  Description  :: :: Place :: TOPOGRAPHIC PLACE hérite de PLACE.   IsoCode IsoSubdvisionCodeType 0:1 Code ISO 3166-2 permettant d'identifier un pays et ses subdivisions (voir http://fr.wikipedia.org/wiki/ISO_3166-2:FR )\nPar exemple :\nFR-Q = Haute-Normandie (région)\nFR-15 = Cantal (département)\n   Descriptor Descriptor 1:1 Description de la TOPOGRAPHIC PLACE.\nLe nom de la Zone Administrative est un des attributs de cette structure, ce qui explique son caractère obligatoire.\nNote: le nom peut aussi apparaître dans l'attribut namehérité de GroupOfEntitiesoù il n'est pas obligatoire. Si les deux noms sont renseignés, ils doivent naturellement être identiques (si ce n'était pas le cas, celui obligatoire du Descriptorprévaut)\n   Topographic­PlaceType TopographicTypeEnum 0:1 Classification de la zone administrative:\n  region (RÉGION)\n  area (utilisé pour DÉPARTEMENT en France)\n  conurbation (utilisé pour GROUPEMENT DE COMMUNE)\n  city (VILLE)\n  quarter (niveau ARRONDISSEMENT)\n  suburb (niveau VILLE)\n  town (niveau VILLE)\n  district (niveau ARRONDISSEMENT)\n  village (niveau VILLE)\n  hamlet (niveau VILLE)\n  urbanCenter (niveau ARRONDISSEMENT)\n  placeOfInterest (niveau ARRONDISSEMENT)\n  other\n  unrecorded\n    PostCode xsd:normalizedString 0:1 Code postal associé à la Zone Administrative (peut avoir une valeur spécifique à la zone et différente de celle de la commune d’appartenance).  «FK» CountryRef CountryEnum 0:1 Identifiant du Pays en respectant la norme ISO 3166-1 (voir: www.iso.org/iso/country_codes/iso_3166_code_lists.htm ).\nC'est le code Alpha-2 sur 2 caractères qui est utilisé ici.\n   otherCountries CountryRef 0:* Pour les Zone Administrative à cheval sur plusieurs pays  «FK» ParentTopo­graphic­PlaceRef TopographicPlaceRef 0:1 Référence la zone administrative dans laquelle est incluse celle-ci. Ce champ doit respecter les règles suivantes :\n• une RÉGION n'a pas de parent (voir CountryRef)\n• un DÉPARTEMENT est contenu dans une RÉGION\n• un GROUPEMENT DE COMMUNES est contenu dans un DÉPARTEMENT (ou éventuellement une région s'il est à cheval sur plusieurs DEPARTEMENTs)\n• une VILLE est contenue dans un DÉPARTEMENT (et PAS dans GROUPEMENT DE COMMUNES: voir containedIn plus bas)\n• un ARRONDISSEMENT est contenu dans VILLE\n   containedIn TopographicPlaceRef 0:* Ce champs est utilisé pour les VILLEs uniquement et permet d'indiquer que la VILLE fait aussi partie d'un GROUPEMENT DE COMMUNES).    Une Zone Administrative doit toujours avoir un nom, mais il n’est pas rare qu’il existe plusieurs lieux du même nom dans un pays (par exemple, il existe douze lieux appelées «Hausen» en Allemagne, et huit «Newports» au Royaume-Uni, etc.) ou dans des pays différents (il existe également plusieurs «Hausen» en Suisse et même «Paris, Texas»).\nAfin de distinguer les différentes instances de manière cohérente, un nom de qualificatif peut être spécifié pour une Zone Administrative en utilisant un élément TopographicPlaceDescriptor (par exemple, «Newport, Gwent», «Newport, Salop», etc.).\nTopographicPlaceDescriptor – Element     Classification Name Type Cardinality Description  :: :: VersionedChild :: TOPOGRAPHIC PLACE DESCRIPTOR hérite de VERSIONED CHILD.   Name MultilingualString 1:1 Nom du descripteur   QualifierName MultilingualString 0:1 Nom utilisé pour distinguer le TOPOGRAPHIC PLACE d’autres lieux similaires portant le même nom. Ce texte ne doit pas être inclus dans le nom mais peut être ajouté par les applications en fonction du contexte.\nLe qualificatif doit être dans la même langue que le nom (Français pour le profil)\n    Zone tarifaire TariffZone– Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; Zone ::\u0026gt; ZONE TARIFAIRE.hérite de ZONE.    id TariffZoneIdType 1:1 Identifiand de la ZONE TARIFAIRE.   «cntd» Presentation Presentation 0:1 Informations de présentation associées (couleurs, etc.)    Entêtes NeTEx Note: les entêtes NeTEx sont présentés dans le document éléments communs. Seules les spécificités de la partie \u0026ldquo;description des arrêts\u0026rdquo; sont présentées ici.\nPour rappel, la liste des fichiers d\u0026rsquo;un export NeTEx profil France est décrite dans Éléments Communs.\nUne GeneralFrame de type NETEX_ARRET est utilisée pour échanger la description des arrêts dans le fichier stop.xml.\nTypeOfFrame : type spécifique NETEX_ARRET Lorsqu\u0026rsquo;une FRAME a pour TypeOfFrame la valeur NETEX_ARRET, seuls les objets de premier niveau suivants sont autorisés :\n StopPlace FlexibleStopPlace Quay TopographicPlace StopPlaceEntrance Entrance AccessSpace  Voici un exemple de cadre du fichier stop.xml :\n\u0026lt;?xml version=\u0026#34;1.0\u0026#34; encoding=\u0026#34;utf-8\u0026#34;?\u0026gt; \u0026lt;PublicationDelivery xmlns=\u0026#34;http://www.netex.org.uk/netex\u0026#34; version=\u0026#34;2.0:FR-NETEX-2.4\u0026#34;\u0026gt; \u0026lt;PublicationTimestamp\u0026gt;2023-01-01T00:00:00.0Z\u0026lt;/PublicationTimestamp\u0026gt; \u0026lt;ParticipantRef\u0026gt;Exemple\u0026lt;/ParticipantRef\u0026gt; \u0026lt;dataObjects\u0026gt; \u0026lt;GeneralFrame id=\u0026#34;exemple:GeneralFrame:NETEX_ARRET:\u0026#34; version=\u0026#34;2.0:FR-NETEX-2.4\u0026#34;\u0026gt; \u0026lt;TypeOfFrameRef ref=\u0026#34;FR:TypeOfFrame:NETEX_ARRET:\u0026#34; /\u0026gt; \u0026lt;members\u0026gt; \u0026lt;!-- STOP PLACE FLEXIBLE STOP PLACE QUAY TOPOGRAPHIC PLACE STOP PLACE ENTRANCE ENTRANCE GROUP OF STOP PLACES ACCESS SPACE --\u0026gt; \u0026lt;/members\u0026gt; \u0026lt;/GeneralFrame\u0026gt; \u0026lt;/dataObjects\u0026gt; \u0026lt;/PublicationDelivery\u0026gt; Bibliographie\nAFIMB - groupe de travail Qualité des Données - Modèle d\u0026rsquo;arrêts partagé\n Version 1.5  EN 15531-1, Public transport - Service interface for real-time information relating to public transport operations - Part 1: Context and framework\nEN 15531-2, Public transport - Service interface for real-time information relating to public transport operations - Part 2: Communications infrastructure3\nEN 15531-3, Public transport - Service interface for real-time information relating to public transport operations - Part 3: Functional service interfaces4\nCEN/TS 15531-4, Public transport - Service interface for real-time information relating to public transport operations - Part 4: Functional service interfaces: Facility Monitoring\nCEN/TS 15531-5, Public transport - Service interface for real-time information relating to public transport operations - Part 5: Functional service interfaces - Situation Exchange\n","permalink":"https://deploy-preview-56--transport-normes.netlify.app/normes/netex/arrets/","summary":"Avant-propos\nL’harmonisation des pratiques dans l’échange des données relatives aux offres de transport est essentielle :\n  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) ;\n  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.","title":"NeTEx - Profil France v2.4 - Description des arrêts"},{"content":"Avant-propos\nL’harmonisation des pratiques dans l’échange des données relatives aux offres de transport est essentielle :\n  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) ;\n  pour les AOT, 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ée 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 ;\n  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)\n  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\n  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 le profil d’échange Profil NeTEx Réseaux: \u0026ldquo;format de référence pour l\u0026rsquo;échange de données de description des réseaux de transport en commun\u0026rdquo; (issu des travaux NeTEx, Transmodel et IFOPT) qui aujourd’hui fait consensus dans les groupes de normalisation (CN03/GT7 – Transport public / information voyageur).\nCe document a été validé et publié comme suit :\n travaux de révision : 2024-2025 date de validation en CN03 : 19 décembre 2025 date de publication : 6 mars 2026  Introduction\nLe présent document fait partie du profil France de NeTEx.\nNeTEx (CEN/TS 16614 series) propose un format et des services d\u0026rsquo;échange de données de description de l\u0026rsquo;offre de transport planifiée, basé sur Transmodel (EN 12896 series) et l’ancienne norme IFOPT (EN 28701). NeTEx permet non seulement d\u0026rsquo;assurer les échanges pour les systèmes d\u0026rsquo;information voyageur mais traite aussi de l’ensemble des concepts nécessaires en entrée et sortie des systèmes de planification de l\u0026rsquo;offre (graphiquage, etc.) et des SAE (Systèmes d’Aide à l’Exploitation).\nNeTEx se décompose en six parties:\n  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)\n  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)\n  Partie 3 : information tarifaire (uniquement à vocation d’information voyageur)\n  Partie 4 : profil européen pour l\u0026rsquo;information voyageur (EPIP)\n  Partie 5 : nouveaux modes (les véhicules partagés en libre service, les courses partagées, etc.)\n  Partie 6 : profil européen pour l\u0026rsquo;information voyageur en lien avec l\u0026rsquo;accessibilité (EPIAP)\n  NeTEx a été développé dans le cadre du CEN/TC278/WG3/SG9 piloté par la France. Les premières publications de NeTEx datent de 2014 et les plus récentes de mars 2026.\nIl faut noter que NeTEx a été l\u0026rsquo;occasion de renforcer les liens du CEN/TC278/WG3 avec le secteur ferrovaire, en particulier grâce à la participation de l\u0026rsquo;ERA (Agence Européen du Rail, qui a intégré NeTEx dans la directive Européenne 454/2011 TAP-TSI ) et de l\u0026rsquo;UIC (Union International des Chemins de fer).\nLes 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.\nIl en résulte des normes qui sont relativement volumineuses et dont le périmètre dépasse souvent largement les besoins d\u0026rsquo;une utilisation donnée. Ainsi, à titre d\u0026rsquo;exemple, SIRI propose toute une série d\u0026rsquo;options ou de mécanismes dont la vocation est d\u0026rsquo;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\u0026rsquo;ils sont dès aujourd\u0026rsquo;hui pertinents en Suisse ou en Allemagne, sont pratiquement inexistants en France.\nDe plus, un certain nombre de spécificités locales ou nationales peuvent amener à préciser l\u0026rsquo;usage ou la codification qui sera utilisée pour certaines informations. Par exemple, les Anglais disposant d\u0026rsquo;un référentiel national d\u0026rsquo;identification des points d\u0026rsquo;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.\nEnfin, certains éléments proposés par ces normes sont facultatifs et il convient, lors d\u0026rsquo;une implémentation, de décider si ces éléments seront ou non implémentés.\nL\u0026rsquo;utilisation des normes liées à l\u0026rsquo;implémentation de l\u0026rsquo;interopérabilité pour le transport en commun passe donc systématiquement par la définition d\u0026rsquo;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 :\n  détail des services utilisés,\n  détails des objets utilisés dans un échange,\n  précisions sur les options proposées par la norme,\n  précision sur les éléments facultatifs,\n  précision sur les codifications à utiliser,\n  etc.\n  Ce document présente la partie Réseaux du profil France de NeTEx, tel que défini par le Groupe de Travail dédié à l\u0026rsquo;information voyageur et à l\u0026rsquo;exploitation des services de mobilité (GT7) au sein de la Commission Nationale de normalisation pour le transport public (CN03).\nD\u0026rsquo;autres parties du profil France de NeTEx sont disponibles (arrêts, horaire, tarif, accessibilité, parking). Ils sont tous complémentaires les uns des autres (sans recouvrement) et s\u0026rsquo;appuient tous sur le document: NeTEx - Profil France - Éléments communs. Il conviendra de se référer à ce document pour tous les éléments utilisés dans le présent document, et dont la structure n\u0026rsquo;est pas détaillée.\nCe profil d’échange a pour objectif de décrire et de structurer précisément les éléments nécessaires à une bonne information de description des réseaux de transport public de façon :\n  à pouvoir les présenter d’une manière homogène et compréhensible à l’usager des transports publics sur des supports différents (papier ou Internet),\n  à pouvoir les échanger entre systèmes d’information (systèmes d’information voyageurs et systèmes d’information multimodale, systèmes d’aide à l’exploitation, systèmes de planification, systèmes billettiques, etc.).\n  Les éléments présentés ci-dessous couvrent donc l’ensemble des concepts propres à la description des réseaux.\nNOTE IMPORTANTE Ce document étant un profil d\u0026rsquo;échange de NeTEx, il ne se substitue en aucun cas à NeTEx, et un minimum de connaissance de NeTEx sera nécessaire à sa bonne compréhension.\nDomaine d\u0026rsquo;application Le présent document est un profil de la CEN/TS 16614 (NeTEx) pour l\u0026rsquo;échange de données de description des réseaux en France et permet de décrire les réseaux de transports publics et la manière dont ils pourront être structurés pour des échanges entre systèmes d\u0026rsquo;information ainsi que pour leur présentation aux voyageurs.\nC\u0026rsquo;est la structure du réseau lui-même (sa structure, ses attributs et sa géographie) qui est prise en compte dans ce contexte, et non son insertion dans le contexte des services de transport (pas de références aux horaires, etc.).\nRéférences normatives Les documents de référence suivants sont indispensables pour l\u0026rsquo;application du présent document. Pour les références datées, seule l\u0026rsquo;édition citée s\u0026rsquo;applique. Pour les références non datées, la dernière édition du document de référence s\u0026rsquo;applique (y compris les éventuels amendements).\nCEN/TS 16614-1, Network and Timetable Exchange (NeTEx) — Part 1: Public transport network topology exchange format\nCEN/TS 16614-2, Network and Timetable Exchange (NeTEx) — Part 2: Public transport scheduled timetables exchange format\nEN 12896, Road transport and traffic telematics - Public transport - Reference data model (Transmodel)\nTermes et définitions Pour les besoins du présent document, les termes et définitions suivants s\u0026rsquo;appliquent. Ils sont directement issus de Transmodel et NeTEx. L\u0026rsquo;Error: Reference source not found complète ces définitions par des explication plus détaillées. Pour une information complète, il conviendra toutefois de se référer au document normatif.\nNOTE Les termes spécifiquement introduits par le profil d’arrêt sont signalés par le mot (profil), en italique et entre parenthèses. Les définitions ci-dessous sont des traductions littérales du document normatif.\nNOTE Les définitions ci-dessus sont des traductions littérales du document CEN.\nACCESS MODE (MODE D’ACCÉS) Caractérisation de déplacement d’un passager relatif à son mode de transport en dehors des transports public (piéton, vélo, etc.).\nAUTHORITY (AUTORITÉ ORGANISATRICE) INSTITUTION sous la responsabilité de laquelle l’organisation des transports est placée pour une zone géographique ou administrative donnée.\nBOARDING POSITION (POSITION D’EMBARQUEMENT) Position d’une ZONE D’EMBARQUEMENT à partir de laquelle un passager pourra embarquer, ou vers laquelle il débarquera d’un VÉHICULE\nNote: cet objet n’a pas été retenu dans le Modèle d’Arrêt Partagé, mais il s’y raccroche directement et est donc à considérer comme une extension du Modèle d’Arrêt Partagé)\nBOOKING ARRANGEMENT (CONDITIONS DE RESERVATION) CONDITIONS DE RÉSERVATION pour une LIGNE FLEXIBLE.\nCOMPOUND TRAIN (TRAIN COMPOSÉ) TYPE DE VEHICULE composé d’une séquence d’un ou plusieurs TRAIN.\nCONNECTION (CORRESPONDANCE) Possibilité physique (spatiale) d\u0026rsquo;un passager de passer d\u0026rsquo;un véhicule de transport public vers un autre dans le but de continuer son voyage. Des temps de parcours différents peuvent être nécessaires en fonction du type de passager.\nCONNECTION END (EXTRÉMITÉ DE CORRESPONDANCE) Début ou fin d\u0026rsquo;une CORRESPONDANCE. Il s’agit forcément d’une relation avec un POINT D’ARRÊT PLANIFIÉ.\nCONTACT DETAILS (INFORMATIONS DE CONTACT) Informations permettant au public de contacter une INSTITUTION.\nCONTROL CENTRE (CENTRE DE CONTROL) UNITÉ ORGANISATIONNELLE composée d’une équipe opérationnelle en charge des commandes et du contrôle des services d’exploitation.\nDEAD RUN (HAUT LE PIED) PARCOURS associé à un HAUT LE PIED (sans transport des passagers : retour dépôt, jonction entre ligne, etc.).\nDEFAULT CONNECTION (CORRESPONDACE PAR DEFAUT) Possibilité physique (spatiale) d\u0026rsquo;un passager de passer d\u0026rsquo;un véhicule de transport public vers un autre dans le but de continuer son voyage. Elle définit le temps par défaut à utiliser pour passer d\u0026rsquo;un véhicule de transport à un autre au sein d\u0026rsquo;une zone (SITE, LIEU TOPOGRAPHIQUE, ZONE D\u0026rsquo;ARRÊT). Elle peut être restreinte à des OPERATEURS ou des MODES des transports particuliers, ou ne s\u0026rsquo;applique que dans un sens donné (une correspondance bus vers train peut être différente de train vers bus).\nDESTINATION DISPLAY (DESTINATION AFFICHÉE) Une destination d\u0026rsquo;un PARCOURS (ou ITINÉRAIRE) particulier, affichée au public en général sur une girouette ou sur tout autre afficheur embarqué. Cette information peut évoluer au fur et à mesure de l\u0026rsquo;évolution de la course et, en particulier, être mise à jour lors du franchissement des points VIA.\nDESTINATION DISPLAY VARIANT (VARIANTE DE DESTINATION AFFICHÉE) alternative à la DESTINATION AFFICHÉE, généralement destiné à des média spécifiques (SMS, type d’afficheur particulier, etc.)\nDIRECTION (SENS) Classification de l\u0026rsquo;orientation générale des ITINÉRAIREs.\nFLEXIBLE LINE (LIGNE FLEXIBLE) Spécialisation de la LIGNE pour décrire les services flexibles. Tous les services d\u0026rsquo;une LIGNE peuvent ne pas être flexibles, la flexibilité elle-même étant alors décrite au niveau du PARCOURS (cela signifie aussi qu\u0026rsquo;il faudra définir des parcours spécifiques pour chaque type de flexibilité de la LIGNE).\nFLEXIBLE LINK PROPERTIES (PROPRIÉTÉ DE TRONÇON FLEXIBLE) Ensemble de caractéristiques décrivant les éventuelles flexibilités associées à un lien\nNote: la relation est établie par composition pour limiter le recours à l\u0026rsquo;héritage multiple.\nFLEXIBLE POINT PROPERTIES (PROPRIÉTÉ DE POINT FLEXIBLE) Ensemble de caractéristiques décrivant les éventuelles flexibilités associées à un point\nNote: la relation est établie par composition pour limiter le recours à l\u0026rsquo;héritage multiple.\nFLEXIBLE ROUTE (ITINERAIRE FLEXIBLE) Spécialisation de l\u0026rsquo;ITINÉRAIRE pour décrire les services flexibles. Il peut inclure des POINTs et des ZONEs, et des sections parcourues dans un ordre prédéfini ou non.\nFLEXIBLE STOP PLACE (LIEU D’ARRÊT FLEXIBLE) Spécialisation du LIEU D’ARRÊT décrivant un arrêt d\u0026rsquo;un service flexible. Il peut être composé de zones flexibles ou de zones de type « hail and ride » identifiant les zones de montée ou descente possible des services flexibles (quand ils utilisent des zones ou des quais flexibles). Certains services flexibles utilisent aussi des LIEUx D’ARRÊT classiques pour leurs arrêts. Quand il est assigné à un POINT D\u0026rsquo;ARRÊT PLANIFIÉ, ce POINT D\u0026rsquo;ARRÊT PLANIFIÉ est alors censé être une zone (le centroïd de la ZONE étant alors considéré comme le POINT D\u0026rsquo;ARRÊT PLANIFIÉ).\nGROUP OF LINES (GROUPE DE LIGNES) Regroupement de lignes référencées de manière commune relative à un objectif donné.\nGROUP OF OPERATOR (GROUPE D’EXPLOITANTS) Groupe d’EXPLOITANTs ayant en commun, par exemple, un ensemble de règles tarifaires et d’information voyageur.\nJOURNEY PATTERN (PARCOURS) Liste ordonnée de POINTs D\u0026rsquo;ARRÊT PLANIFIÉs et de POINTs HORAIREs sur un unique ITINÉRAIRE, décrivant le plan de déplacement pour les véhicules de transport public. Un PARCOURS peut passer par le même POINT plus d\u0026rsquo;une fois. Le premier point d\u0026rsquo;un PARCOURS est l\u0026rsquo;origine. Le dernier point est la destination.\nLINE (LIGNE) Groupe d\u0026rsquo;ITINÉRAIREs (voir plus bas) qui est en général connu du public par une appellation commune (nom ou numéro, extrémités de ligne, etc.).\nNETWORK (RÉSEAU) Un GROUPE DE LIGNES disposant d\u0026rsquo;un nom sous lequel un réseau de transport est connu.\nOPERATOR (EXPLOITANT) Entreprise offrant des services de transport public.\nPASSENGER STOP ASSIGNMENT (AFFECTATION D’ARRÊT POUR PASSAGER) Affection d’un POINT D’ARRÊT PLANIFIÉ à un LIEU D’ARRÊT (ou un de ses composant de type ZONE D’EMBARQUEMENT ou POSITION D’EMBARQUEMENT) pour un service passager.\nPOINT IN JOURNEY PATTERN (POINT SUR PARCOURS) Un POINT D\u0026rsquo;ARRÊT PLANIFIÉ ou un POINT HORAIRE dans un PARCOURS indiquant son rang dans ce PARCOURS.\nPOINT IN TIMING PATTERN (POINT SUR PARCOURS HORAIRE) POINT sur PARCOURS qui est un POINT HORAIRE.\nPOINT ON ROUTE (POINT SUR ITINÉRAIRE) POINT D\u0026rsquo;ITINÉRAIRE (accompagné de son rang) qui sert à définir un ITINÉRAIRE.\nROUTE LINK (TRONÇON D\u0026rsquo;ITINÉRAIRE) Tronçon orienté entre deux POINTs D\u0026rsquo;ITINÉRAIRE permettant une définition univoque d\u0026rsquo;un chemin à travers le réseau.\nROUTE POINT (POINT D\u0026rsquo;ITINÉRAIRE) POINT permettant de définir la géométrie d\u0026rsquo;un ITINÉRAIRE à travers le réseau.\nROUTE (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.\nROUTING CONSTRAINT ZONE (ZONE DE CONTRAINTE) ZONE au sein de laquelle une contrainte d\u0026rsquo;acheminement s\u0026rsquo;applique. La ZONE peut être définie soit par un périmètre géographique, soit par la liste des POINTs D\u0026rsquo;ARRÊT PLANIFIÉS qu\u0026rsquo;elle contient.\nSCHEDULED STOP POINT (POINT D\u0026rsquo;ARRÊT PLANIFIÉ) POINT où les passagers peuvent monter à bord ou descendre des véhicules.\nSCHEMATIC MAP (PLAN SCHÉMATIQUE) Carte représentant schématiquement la disposition de la structure topographique des lieux (par exemple, un ensemble de sites) ou le réseau de transports en commun (un ensemble de lignes). Il peut comprendre une projection de pixel ou objet de dessin vectoriel vers un ensemble d\u0026rsquo;objet transport pour permettre les interactions, services et hyperliens.\nSCHEMATIC MAP MEMBER (COMPOSANT DE PLAN SCHÉMATIQUE) Projection d’un objet transport sur un PLAN SCHÉMATIQUE.\nSERVICE JOURNEY PATTERN (PARCOURS COMMERCIAL) PARCOURS associé à une COURSE COMMERCIALE (transportant des passagers).\nSERVICE LINK (TRONÇON COMMERCIAL) TRONÇON entre une paire ordonnée de POINTs D\u0026rsquo;ARRÊT PLANIFIÉS.\nSERVICE PATTERN (MISSION COMMERCIALE) Vue d\u0026rsquo;un PARCOURS définie uniquement par des POINTs D\u0026rsquo;ARRÊT SUR PARCOURS. La MISSION COMMERCIALE se distingue du PARCOURS COMMERCIAL par le fait qu\u0026rsquo;elle n\u0026rsquo;est définie que par une séquence d\u0026rsquo;arrêts, sans point intermédiaire.\nSITE CONNECTION (CORRESPONDANCE ENTRE SITES) La possibilité physique (spatiale) d\u0026rsquo;un passager de continuer son déplacement déterminé par deux localisations comme des SITEs ou leurs ENTRÉEs. Des temps de parcours différents peuvent être nécessaires en fonction du type de passager.\nSTOP ASSIGNMENT (AFFECTATION D’ARRÊT) Affection d’un POINT D’ARRÊT PLANIFIÉ à un LIEU D’ARRÊT.\nSTOP POINT IN JOURNEY PATTERN (POINT D\u0026rsquo;ARRÊT SUR PARCOURS) POINT d\u0026rsquo;un PARCOURS qui est un POINT D\u0026rsquo;ARRÊT\nSUBMODE (SOUS-MODE) Précision sur le MODE, comme \u0026ldquo;international\u0026rdquo; ou \u0026ldquo;longue distance\u0026rdquo; (pour un MODE Rail par exemple). Le SOUS-MODE caractérise très souvent un type d\u0026rsquo;exploitation qui vient donc compléter le MODE.\nTIMING LINK (TRONÇON HORAIRE) Paire ordonnée de POINTs HORAIREs qui peut être utilisée pour l\u0026rsquo;enregistrement des temps de parcours.\nTIMING PATTERN (PARCOURS HORAIRE) Vue d\u0026rsquo;un PARCOURS définie uniquement par des POINTs HORAIRE SUR PARCOURS.\nTIMING POINT (POINT HORAIRE) POINT servant de référence aux données nécessaires à la conception des horaires. Un POINT HORAIRE peut aussi être un POINT D’ARRÊT PLANIFIÉ mais cela n’a rien d’obligatoire ou de systématique.\nTRAIN STOP ASSIGNMENT (AFFECTATION D’ARRÊT DE TRAIN) Affection d’un COMPOSANT DE TRAIN à un LIEU D’ARRÊT (ou un de ses composant de type ZONE D’EMBARQUEMENT ou POSITION D’EMBARQUEMENT) pour un POINT D’ARRÊT PLANIFIÉ donné.\nTRANSFER RESTRICTION (RESTRICTION DE CORRESPONDANCE) Contrainte qui s’applique aux CORRESPONDANCES (ou CORRESPONDANCES ENTRE COURSES) entre deux POINTs D’ARRÊT PLANIFIÉs, en limitant voir interdisant l’usage pour les passagers.\nTYPE OF LINES (TYPE DE LIGNES) Classification pour les lignes\nVEHICLE MODE (MODE DE VÉHICULE) Typologie de l\u0026rsquo;exploitation suivant le moyen de transport (bus, tramway, métro, train, ferry, bateau).\nVIA (VIA) POINT utilisé comme POINT D\u0026rsquo;ITINÉRAIRE et permettant de distinguer deux cheminements (ITINÉRAIREs) entre une origine et une destination. Il est généralement défini à des fins d\u0026rsquo;information voyageur pour par exemple différentier deux itinéraires sur un afficheur du réseau, ou encore sur un système de vente.\nSymboles et abréviations AO\nAutorité Organisatrice de Transports\n PMR\nPersonne à Mobilité Réduite\n Exigences minimales liées au code des transports et la règlementation européenne La mise à disposition des données, quand elles existent, est obligatoire et se conforme aux exigences :\n Au niveau européen, du règlement délégué (UE) 2017/1926 de la Commission du 31 mai 2017 modifié par le règlement délégué (UE) 2024/490 de la Commission du 29 novembre 2023 (https://eur-lex.europa.eu/eli/reg_del/2017/1926/2024-03-04), dit \u0026ldquo;règlement MMTIS\u0026rdquo; ; Au niveau français, des articles L. 1115-1 à L. 1115-7 , D. 1115-1, R. 1115-2 à R. 1115-8 et D. 1115-9 à D. 1115-11 du code du transports, notamment créés ou modifiés par les articles 25 et 27 de loi n° 2019-1428 du 24 décembre 2019 d’orientation des mobilités, dites loi « LOM ». Ces mêmes articles de la LOM précise le calendrier de mise à disposition des données.  Le tableau ci-dessous résulte de l’analyse du code des transports et du règlement MMTIS et fournit la liste des concepts concernés dans le présent profil correspondant aux données mentionnées dans l’annexe du règlement. Il sera donc nécessaire de fournir ces données pour être conforme au cadre réglementaire (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).\nNotez que beaucoup de concepts dépendent des concepts issus de Transmodel/NeTEx et sont liés entre eux, soit par héritage, soit par relation au sens UML des termes. Par ailleurs, certains concepts additionnels peuvent relever d’autres parties du profil France, précisés dans le tableau le cas échéant.\nDe plus, 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.\nPour 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).\nLa 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).\nLes 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).\nConcepts relatifs à la LOM et à la Règlementation Européenne     Niveau Catégorie Détail Concepts à minima Autres\nconcepts\n Commentaire    1 Location search (origin/ destination) Points of interest (related to transport information) to which people may wish to travel POI  Même si le transport en commun n'est probablement pas la meilleure source pour les POI, NeTEx reste néanmoins en mesure de les décrire.  1 Trip plan computation — scheduled modes transport Connection links where interchanges may be made, default transfer times between modes at interchanges DEFAUT CONNECTION CONNECTION\nSITE CONNECTION\n\n(profil horaire)\nINTERCHANGE\n DEFAUT CONNECTION peut être utilisé à la place de CONNECTION quand l'information détaillée n'est pas disponible.\nL’INTERCHANGE décrit la correspondance entre deux courses et est, à ce titre, décrit dans le Profil Horaire.\n  1 Trip plan computation — scheduled modes transport Network topology and routes/lines (topology) LINE\nSERVICE PATERN\nSCHEDULED STOP POINT ROUTE\nROUTE POINT\nROUTE LINK\nSERVICE LINK\nPOINT IN JOURNEY PATTERN\nDESTINATION DISPLAY\n   2 Trip plans, auxiliary information, availability check Basic common standard fares (all scheduled modes): Fare network data (fare zones/stops and fare stages) TARIFF ZONE (profil tarif)\nFARE ZONE\nFARE PRODUCT\nSALES OFFER PACKAGE\nDISTRIBUTION CHANNEL\nACCESS RIGHT PARAMETER ASSIGNMENT\n   3 Trip plans Parameters needed to calculate an environmental factor such as carbon per vehicle type or passenger mile or per distance walked VEHICLE TYPE\nCONNECTION et SITE CONNECTION\n\nROUTE LINK (donc ROUTE) ou SERVICE LINK en alternative\n (partie accessibilité)\nNAVIGATION PATH\n Les SERVICE LINKs ou ROUTE LINKs impliquent naturellement les POINTs (POINT IN JOURNEY PATTERN, ROUTE POINT, POINT ON ROUTE, etc.) correspondant. Ils permettront d’évaluer la distance parcourue par le véhicule.    Description du profil d’échange Conventions de représentation Tableaux d’attributs NOTE les choix de conventions présentées ici ont pour vocation d\u0026rsquo;être cohérents avec ceux réalisés dans le cadre du profil SIRI (IDFM et CEREMA). De plus tous les profils NeTEx partagent les mêmes conventions.\nLes messages constituant ce profil d\u0026rsquo;é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:\n            Classifi­cation Nom Type Cardin­alité Description      Classification : permet de catégoriser l\u0026rsquo;attribut. Les principales catégories sont:\n  PK (Public Key) que l\u0026rsquo;on peut interpréter comme Identifiant Unique: il permet à lui seul d\u0026rsquo;identifier l\u0026rsquo;objet, de façon unique, pérenne et non ambiguë. C\u0026rsquo;est l\u0026rsquo;identifiant qui sera utilisé pour référencer l\u0026rsquo;objet dans les relations.\n  AK (Alternate Key) est un identifiant secondaire, généralement utilisé pour la communication, mais qui ne sera pas utilisé dans les relations.\n  FK (Foreign Key) indique que l\u0026rsquo;attribut contient l\u0026rsquo;identifiant unique (PK) d\u0026rsquo;un autre objet avec lequel il est en relation.\n  GROUP est un groupe XML nommé (ensemble d\u0026rsquo;attributs utilisables dans différents contextes) (cf: http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/#AttrGroups )\n    Nom : nom de l\u0026rsquo;élément ou attribut XSD\n  Type : type de l\u0026rsquo;élément ou attribut XSD (pour certains d\u0026rsquo;entre eux, il conviendra de se référer à la XSD NeTEx)\n  Cardinalité : cardinalité de l\u0026rsquo;élément ou attribut XSD exprimée sous la forme \u0026ldquo;minimum:maximum\u0026rdquo; (\u0026ldquo;0:1\u0026rdquo; pour au plus une occurrence; \u0026ldquo;1:*\u0026rdquo; au moins une occurrence et sans limites de nombre maximal; \u0026ldquo;1:1\u0026rdquo; une et une seule occurrence; etc.).\n  Description : texte de description de l\u0026rsquo;é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).\n  Les textes surlignés en Jaune sont ceux présentant une particularité (spécialisation) par rapport à NeTEx: une codification particulière, une restriction d\u0026rsquo;usage, etc.\nLa description XSD utilisée est strictement celle de NeTEx, sans aucune modification (ceci explique notamment que tous les commentaires soient en anglais).\nLes attributs et éléments rendus obligatoires dans le cadre de ce profil restent facultatifs dans l\u0026rsquo;XSD (le contrôle de cardinalité devra donc être réalisé applicativement).\nValeurs 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 :\n  Des énumérations fixes définies dans le cadre du schéma XSD NeTEx. Le profil impose alors un sous-ensemble des codes NeTEx.\n  Des 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\u0026rsquo;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».\n  Des instances TypeOfFrame: le profil utilise plusieurs TYPES DE FRAME pour spécifier l\u0026rsquo;utilisation de VERSION FRAME dans le profil.\n  Indication des classes abstraites NeTEx, et Transmodel, utilisent largement l\u0026rsquo;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’ existe aucune instance concrète; seules les sous-classes terminales sont «concrètes».\nUn inconvénient de l\u0026rsquo;héritage est que si l\u0026rsquo;on veut comprendre les propriétés d\u0026rsquo;une classe concrète unique, il faut également examiner toutes ses super-classes. Pour cette raison, le profil 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.\n  Les super-classes sont signalées dans les en-têtes par le suffixe «(abstrait)»\n  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.\n  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.\n  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)».\nStructure du réseau La topologie du réseau décrit les lignes et itinéraires permanent du réseau de transport, ainsi que les éléments organisationnels qui y sont rattachés.\nStructure du Réseau – Modèle conceptuel\nTransmodel définit une LIGNE comme un groupe d’ITINERAIREs (ROUTE) qui est généralement connu du public sous un nom ou un numéro similaire. Ces ITINERAIREs sont généralement très similaires d’un point de vue topologique, c’est-à-dire des variantes d’un itinéraire principal avec quelques écarts seulement sur certaines parties. Deux ITINERAIREs utilisant la même d’infrastructure (ou des voies parallèles), mais avec des DIRECTIONS opposées, appartiendront généralement à la même LIGNE.\nUne LIGNE est associée à un MODE DE TRANSPORT principal et à un SOUS-MODE, mais peut également avoir des modes secondaires (par exemple, une ligne de train qui est exploitée par un bus à certaines heures de la journée ou dans certaines circonstances).\nUne LIGNE est également associée à un OPÉRATEUR principal ou à une AUTORITÉ (plusieurs opérateurs secondaires sont également autorisés).\nLes LIGNEs peuvent être regroupées en groupes de lignes à des fins particulières, telles que l\u0026rsquo;harmonisation des tarifs, l\u0026rsquo;attribution de types de jours ou pour regrouper certaines catégories de services (bus de nuit, etc.).\nLes lignes Line – Element     Classifi­cation Name Type Cardin­ality Description  :: :: DataManagedObject :: LINE hérite de DataManagedObject (voir le document Profil NeTEx éléments communs).   Name MultilingualString 1:1 Nom de la LIGNE.   ShortName MultilingualString 0:1 Nom court de la LIGNE.   Description MultilingualString 0:1 Description de la LIGNE.   TransportMode VehicleModeEnum 0:1 MODE DE TRANSPORT principal de la LIGNE.   Transport­Submode SubmodeEnum 0:1 SOUS-MODE associé à la LIGNE.   Url any 0:1 URL d'information voyageur associée à la LIGNE.  «AK» PublicCode xsd:normalizedString 0:1 Identifiant publique de la LIGNE.\nIl s'agit généralement d'un numéro, parfois complété d'une lettre (par exemple 95, ou 27A, etc.). Les Nameet ShortNameporteront généralement une information plus explicite (par exemple la ligne ayant le PublicCode95à Paris s'appelle \"Porte de Vanves / Porte de Montmartre\").\nOn peut considérer que le nom complet de la ligne est une concaténation de son PublicCodeet de son Name.\n  «AK» PrivateCode xsd:normalizedString 0:1 Identifiant secondaire de la LIGNE.\nIl s'agit généralement d'un identifiant propre au fournisseur (transporteur) de l'information.\n  «FK» Choice AuthorityRef TransportOperatorRef 0:1 Réference une AUTORITE  «FK» OperatorRef OperatorRef 0:1 Réference un EXPLOITANT.  «cntd» additional­Operators OperatorRef 0:* Réference un EXPLOITANT additionnel pour la LIGNE (comme pour les RER A et B à Paris, où encore les lignes en \"pool\").   otherModes modeRefs  Réference un MODE de transport additionnel pour la LIGNE (certaine ligne SNCF sont parfois ponctuellement remplacées par des lignes de car par exemple).   TypeOfLineRef TypeOfLineRef 0:1 TYPE DE LIGNE spécifique.\nPermet une classification particulière de la ligne (ligne saisonnière, ligne de substitution, etc.)\nDeux types prédéfinis sont proposé par le profil: SEASONAL_LINE_TYPE et REPLACEMENT_LINE_TYPE Pour ce second type on utilisera, par convention, le derivedFromObjectRef (voir le document Profil NeTEx éléments communs) pour effectuer le lien avec la ligne à remplacer, et on renseignera le ValidityTrigger permettant de décrire dans quelle condition le remplacement est activé.\nÀ ne pas confondre avec une marque commerciale, pour lequel l'attribut Branding est disponible dans le DataManagedObject (voir le document Profil NeTEx éléments communs).\nA définir par un TYPE DE VALEUR spécifique (voir le document Profil NeTEx éléments communs).\n   Monitored xsd:boolean 0:1 Indique si la ligne dispose d'information voyageur temps réel.  «cntd» routes RouteRef 0:* Liste des ITINERAIREs de la LIGNE.  «FK» RepresentBy­GroupRef   Le GROUPE DE LIGNES référence les LIGNES, mais on n'utilise pas la relation inverse dans le profil.  «cntd» Presentation Presentation 0:1 Information concernant la représentation graphique de la ligne (couleur, etc.).   Accessibility­Assessment Accessibility­Assessment 0:1 Information concernant l'accessibilité de la ligne (voir la partie Accessibilité du profil France).  «cntd» allowed­Directions AllowedDirection 0:* Ensemble des DIRECTIONs de la ligne (attention la DIRECTION est une indication d'ordre générale à ne pas confondre avec la DESTINATION qui est un arrêt terminus de la LIGNE).   noticeAssignments noticeAssignments_RelStructure 0:* NOTEs affectées à la LIGNE.\n(voir le document Profil NeTEx éléments communs).\n  «cntd» documentLinks InfoLinks 0:* Document, typiquement PDF, associés à la ligne (généralement plan et horaires).    Directions Direction – Element (objet inclus)    Classifi­cation Name Type Cardin­ality Description     ::\u0026gt; ::\u0026gt; TypeOfValue ::\u0026gt; DIRECTION hérite de TYPE OF VALUE (voir le document Profil NeTEx éléments communs)    DirectionType DirectionTypeEnum 0:1 Valeur fixe parmi : ‘outbound’, ‘inbound’, ‘clockwise’, ‘anticlockwise’ (sortant, entrant, horaire, antihoraire) associée à cette DIRECTION.   «FK» Opposite­DirectionRef DirectionRef 0:1 Référence à la DIRECTION correspondant au sens opposé.    Les groupes de Ligne GroupOfLines – Element     Classifi­cation Name Type Cardin­ality Description  :: :: GroupOfEntities :: GROUP OF LINEs hérite de GROUP OF ENTITies.(voir le document Profil NeTEx éléments communs)\nL'attribut PurposeofGroupingRefpourra être utilisé pour qualifier les lignes administratives en utilisant la valeur \"administrativeLine\".\n  «cntd» members LineRef 0:* Références à l'ensemble des LIGNEs du GROUPE DE LIGNES.  «FK» MainLineRef LineRef 0:1 LIGNE principale du GROUPE DE LIGNES.   TransportMode VehicleModeEnum 0:1 MODE DE TRANSPORT principal du GROUPE DE LIGNES.    Les réseaux La notion de \u0026ldquo;réseau\u0026rdquo; correspond à un regroupement de lignes mis en avant sur le terrain et visible des voyageurs. Par exemple pour des réseaux urbains, le réseau TCL pour Lyon et les alentours, TBM pour le réseau de Bordeaux ou Bibus pour le réseau urbain de Brest.\nCette notion de réseau n\u0026rsquo;est pas obligatoire, mais très fortement recommandée pour des exports de structures de réseau ou d\u0026rsquo;offre horaires. De plus, pour éviter des différences d\u0026rsquo;interprétation et de communication, une ligne ne peut être référencée que par un seul réseau dans un export NeTEx France.\nNetwork – Element    Classifi­cation Name Type Cardin­ality Description     ::\u0026gt; ::\u0026gt; GroupOfLines ::\u0026gt; NETWORK hérite de GROUP OF LINEs    TransportOrganisationRef OrganisationRefStructure 0:1 INSTITUTION (autorité organisatrice ou transporteur) en charge du RÉSEAU    groupsOfLines groupsOfLinesInFrame 0:* GROUPE DE LIGNES faisant partie du RÉSEAU    tariffZones tariffZoneRefs 0:* ZONEs TARIFAIREs faisant partie du RÉSEAU    Afin de permettre une description complète d\u0026rsquo;un réseau de transport, la notion de groupe de lignes peut êgalement être utilisée en complément afin de regrouper par exemple les lignes de nuit du réseau ou les \u0026ldquo;lignes fortes\u0026rdquo;. Dans ce cas, la ligne est référencée par le (ou les) groupe(s) de lignes dont elle fait partie ET par le réseau global. Recommandation : une ligne ne devrait pas être présente dans plus d\u0026rsquo;un groupe de lignes à la fois au sein du réseau sauf situation particulière.\nExemple :\n\u0026lt;Network id=\u0026#34;sample-with-lines\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Mon Réseau\u0026lt;/Name\u0026gt; \u0026lt;members\u0026gt; \u0026lt;LineRef ref=\u0026#34;L1\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;LineRef ref=\u0026#34;L2\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;LineRef ref=\u0026#34;L3\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;/members\u0026gt; \u0026lt;groupsOfLines\u0026gt; \u0026lt;GroupOfLinesRef ref=\u0026#34;G1\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;GroupOfLinesRef ref=\u0026#34;G2\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;/groupsOfLines\u0026gt; \u0026lt;/Network\u0026gt; \u0026lt;!-- avec le groupe de lignes G1 qui contient des références aux lignes L1 et L2, et le groupe de lignes G2 qui contient une référence à la ligne L3. --\u0026gt; Zone tarifaire TariffZone – Element    Classifi­cation Name Type Cardin­ality Description     ::\u0026gt; ::\u0026gt; Zone ::\u0026gt; TARIFF ZONE hérite de ZONE.(voir le document Profil NeTEx éléments communs) sans y apporter de nouveaux attributs.    Les itinéraires Route – Element    Classifi­cation Name Type Cardin­ality Description     ::\u0026gt; ::\u0026gt; LinkSequence ::\u0026gt; ROUTE hérite de LINK SEQUENCE (voir le document Profil NeTEx éléments communs).   «FK» LineRef LineRef 0:1 LIGNE à laquelle l\u0026rsquo;ITINÉRAIRE appartient.    DirectionType TypeOfDirectionEnum 0:1 Type de direction de la ROUTE (outbound, inbound, pour aller Retrour et éventuellement clockwise ou anticlockwise pour les boucles)   «FK» DirectionRef DirectionRef 0:1 Référence la DIRECTION de l\u0026rsquo;ITINÉRAIRE.   «cntd» pointsInSequence PointOnRoute 2:* Liste des points de l\u0026rsquo;ITINÉRAIRE.   «cntd» sectionsInSequence SectionLink 0:* Liste des sections de l\u0026rsquo;ITINÉRAIRE.    InverseRouteRef RouteRef 0:1 Référence l\u0026rsquo;éventuel ITINÉRAIRE en sens opposé.    Les Points d\u0026rsquo;itinéraire RoutePoint – Element    Classifi­cation Name Type Cardin­ality Description     ::\u0026gt; ::\u0026gt; Point ::\u0026gt; ROUTE POINT hérite de POINT (voir le document Profil NeTEx éléments communs).    BorderCrossing xsd:boolean 0:1 Indique que le point est un point situé à la frontière entre deux pays.    Les points sur itinéraire PointOnRoute – Element    Classifi­cation Name  Type Cardin­ality Description     ::\u0026gt; ::\u0026gt;  PointInLinkSequence ::\u0026gt; POINT ON ROUTE hérite de POINT IN LINK SEQUENCE (voir le document Profil NeTEx éléments communs).   Hérité de POINT IN SEQUENCE  RouteRef   Les PointOnRoute seront systématiquement inclus dans les ROUTEs     projections projections 0:1 Projection sur la voirie ou les rails (voir le document Profil NeTEx éléments communs).   «FK» RoutePointRef  RoutePointRef 1:1 Référence au POINT D\u0026rsquo;ITINÉRAIRE correspondant    Point sur séquence de tronçon PointInLinkSequence – Element (objet inclus)    Classifi­cation Name Type Cardin­ality Description     ::\u0026gt; ::\u0026gt; PointInSequence ::\u0026gt; POINT IN LINK SEQUENCE hérite de PointInSequence (voir le document Profil NeTEx éléments communs).    order xsd:positiveInteger 0:1 Numéro d\u0026rsquo;ordre du point dans la séquence.    LinkSequenceRef LinkSequenceRef 0:1 Référence la SÉQUENCE DE TRONÇONs à laquelle appartient le POINT (une spécialisation pourra intervenir via un groupe de substitution).    projections projections 0:1 Projection sur la voirie ou les rails (voir le document Profil NeTEx éléments communs).    Les tronçons d\u0026rsquo;itinéraire RouteLink – Element    Classifi­cation Name Type Cardin­ality Description     ::\u0026gt; ::\u0026gt; Link ::\u0026gt; ROUTE LINK hérite de LINK (voir le document Profil NeTEx éléments communs).    Distance DistanceType 1:1 Longueur du ROUTE LINK. Les unités sont telles que spécifiées pour la FRAME (la valeur par défaut est SI mètres).   «cntd» LineString gmlLineString 0:1 Géométrie du TRONÇON sous forme d’une linestring GML (la géométrie d’un TRONÇON n’est donc pas limitée à un simple couple de point, mais est décrite par une séquence de points).   «FK» FromPointRef RoutePointRef 1:1 POINT D\u0026rsquo;ITINÉRAIRE de début de TRONÇON.   «FK» ToPointRef RoutePointRef 1:1 POINT D\u0026rsquo;ITINÉRAIRE de fin de TRONÇON.           Exemple de LineString pour décrire un tracé :\n\u0026lt;gml:LineString gml:id=\u0026#34;AB2o\u0026#34;\u0026gt; \u0026lt;gml:pos\u0026gt;53.00 1.00\u0026lt;/gml:pos\u0026gt; \u0026lt;gml:pos\u0026gt;53.10 1.10\u0026lt;/gml:pos\u0026gt; \u0026lt;gml:pos\u0026gt;53.20 1.20\u0026lt;/gml:pos\u0026gt; \u0026lt;/gml:LineString\u0026gt; Les affichages de destination DESTINATION DISPLAY – Modèle conceptuel\nDestinationDisplay – Element     Classifi­cation Name Type Cardin­ality Description  :: :: DataManagedObject :: DESTINATION DISPLAY hérite de DataManagedObject (voir le document Profil NeTEx éléments communs).   SideText MultilingualString 0:1 Texte latéral (affiché sur le côté du véhicule) de l'AFFICHAGE DE DESTINATION.   FrontText MultilingualString 0:1\n1:1\n Texte frontal (affiché sur le devant du véhicule) de l'AFFICHAGE DE DESTINATION.\nAu niveau du profil, ce texte est considéré comme étant le texte principal et est rendu obligatoire.\n  «AK» PublicCode xsd:normalizedString 0:1 Code associé à l'AFFICHAGE DE DESTINATION.\nDans un certain nombre de cas l'AFFICHAGE DE DESTINATION n'est pas un texte mais un code (par exemple pour les RER et Transilen en IIe-de-France avec des codes comme PADO, DEFI ou encore PORO). Ce sont ces codes qui seront indiqué dans ce champ (on réservera les champs XxxxTextpour un texte compréhensible par tous).\n  «cntd» vias   Les éventuels vias seront intégrés dans le texte de l'AFFICHAGE DE DESTINATION.  «cntd» variants DeliveryDisplayVariant 0:* Variante de texte AFFICHAGE DE DESTINATION pour s'adapter aux différents types de média.    Les variantes d\u0026rsquo;affichages de destination DestinationDisplayVariant – Element (objet inclus)     Classifi­cation Name Type Cardin­ality Description  :: :: DataManagedObject :: DESTINATION DISPLAY VARIANT hérite de DataManagedObject (voir le document Profil NeTEx éléments communs).   DestinationDisplayVariantMediaType DeliveryVariantTypeEnumeration 1:1 Type (codé) de support auquel est destinée la variante. Les valeurs possibles sont:\n Printed\n textToSpeech\n web\n mobile\n other\n    FrontText MultilingualString 0:1\n1:1\n Texte \"frontal\" de la VARIANTE D'AFFICHAGE DE DESTINATION.\nAu niveau du profil, ce texte est considéré comme étant le texte principal et est rendu obligatoire.\n    La flexibilité des lignes (TAD) Flexible Line – Modèle conceptuel\nLa plupart des objets de bases utilisés pour la description des lignes disposent d\u0026rsquo;une déclinaison dite \u0026ldquo;flexible\u0026rdquo; que l\u0026rsquo;on utilisera en particulier dans le cadre du transport à la demande (TAD), mais aussi dans de nombreux autres contextes de nouveaux services de transport public.\nPour les LIGNEs et les ITINÉRAIREs le mécanisme de groupe de substitution (substitution group) XML utilisé par NeTEx permet d\u0026rsquo;utiliser n\u0026rsquo;importe que objet \u0026ldquo;flexible\u0026rdquo; en lieu et place de la version non flexible correspondante.\nPour les POINTs et le TRONÇON, c\u0026rsquo;est un objet supplémentaire (référençant l\u0026rsquo;objet \u0026ldquo;principal\u0026rdquo;) qui apporte les propriétés de flexibilité.\nLigne flexible FlexibleLine – Element     Classifi­cation Name Type Cardin­ality Description  :: :: Line :: FLEXIBLE LINE hérite de LINE   FlexibleLineType FlexibleLineTypeEnum 1:1 Type de LIGNE FLEXIBLE (voir le document NeTEx pour le détail des différents types de flexibilité):\n corridorService\n mainRouteWithFlexibleEnds\n flexibleAreasOnly\n hailAndRideSections\n fixedStopAreaWide\n freeAreaAreaWide\n mixedFlexible\n mixedFlexibleAndFixed\n fixed\n other\n   «cntd» Booking­Arrangements BookingArrangements 0:1 Information sur les conditions de réservation.    BookingArrangements – Element (objet inclus)     Classifi­cation Name Type Cardin­ality Description  «cntd» BookingContact ContactDetails 0:1 Informations de contact pour la réservation (voir le document Profil NeTEx éléments communs).   BookingMethods BookingMethodEnum 0:* Méthode de réservation à utiliser (plusieurs valeurs possibles):\n callDriver (appeler le conducteur)\n callOffice (appeler un centre d’appel)\n online (via Internet)\n other (autre)\n phoneAtStop (par téléphone à l’arrêt)\n text (envoyer un message SMS pour réserver)\n none\n    BookingAccess BookingAccessEnum 0:1 Précise qui peut faire la réservation:\n public (tout le monde)\n authorisedPublic (personnes autorisée)\n staff (le personnel d’exploitation)\n other\n    BookWhen PurchaseWhenEnumeration 0:1 Précise quand la reservation peut-être faite\n timeOfTravelOnly : au moment de voyage\n dayOfTravelOnly : le jour du voyage\n untilPreviousDay : jusqu'au jour précédent le voyage (avant le jour du voyage)\n advanceAndDayOfTravel: jusqu'au jour du voyage\n    BuyWhen PurchaseMomentListOfEnumerations 0:1 Moment où le paiement doit intervenir :\n onReservation : lors de la réservation\n beforeBoarding : avant l'embarquement\n onBoarding : au moment de l'embarquement\n afterBoarding : après l'embarquement (pendant le voyage)\n onCheckOut; à la descente du véhicule\n    LatestBookingTime MultilingualString 0:1 Heure au plus tard, dans la journée, où la réservation doit se faire.\nA combiner avec BookWhen pour exprimer, par exemple \"avant la veille à 18:00\".\n   MinimumBooking­Period xsd:duration 0:1 Période, avant le départ, en amont de laquelle la réservation doit être faite. (exemple: 2:00 avant l'heure du départ).   BookingUrl   On utilise l'URL de bookingContact   BookingNotes Notice 0:* Note concernant les conditions de réservation.    Itinéraire flexible FlexibleRoute – Element     Classifi­cation Name Type Cardin­ality Description  :: :: Route :: FLEXIBLE ROUTE hérite ROUTE.   FlexibleRoute­Type FlexibleRouteTypeEnum 1:1 Type d'ITINÉRAIRE FLEXIBLE (voir le document NeTEx pour les définitions) :\n flexibleAreasOnly\n hailAndRideSections\n mixed\n fixed\n other\n     Point flexible FlexiblePointProperties doit toujours être intégré au StopPointInPattern qu’il précise.\nFlexiblePointProperties – Element (objet inclus)     Classifi­cation Name Type Cardin­ality Description  :: :: VersionedChild :: FlexiblePointProperties hérite de VersionedChild (voir le document Profil NeTEx éléments communs).  Choice a PointOnRoute­Ref PointOnRouteRef 0:1 POINT SUR ITINÉRAIRE concerné par ces propriétés de flexibilité          MayBeSkipped xsd:boolean 0:1 L'ITINÉRAIRE peut ne pas passer par ce point   OnMainRoute xsd:boolean 0:1 Point sur l'ITINÉRAIRE principal (cas des corridors)   PointStanding­For­AZone xsd:boolean 0:1 Point représentant une ZONE\nLe POINT est alors obligatoirement référencé par une ZONE dont il est le centroïd (voir le document Profil NeTEx éléments communs).\n   ZoneContaining­Stops xsd:boolean 0:1 Dans le cas où PointStandingForAZone est vrai, cet attribut permet d'indiquer que la zone contient des arrêts (pour différentier le TAD zonal à l'adresse et le TAD zonal à l'arrêt). La ZONE référencée a alors obligatoirement un champ members référençant les arrêts qu'elle contient (de type POINT D'ARRÊT PLANIFIÉ).    Tronçon flexible FlexibleLinkProperties – Element (objet inclus)     Classifi­cation Name Type Cardin­ality Description  :: :: VesionedChild :: FlexibleLinkProperties hérite de VesionedChild (voir le document Profil NeTEx éléments communs).   LinkRef LinkRef 0:1 Tronçon concerné par ces propriétés de flexibilité   MayBeSkipped xsd:boolean 0:1 L'ITINÉRAIRE peut ne pas passer par ce TRONÇON   OnMainRoute xsd:boolean 0:1 TRONÇON sur l'ITINÉRAIRE principal (cas des corridors)   UnscheduledPath xsd:boolean 0:1 Indique que le cheminement précis sur l'infrastructure routière n'est pas planifié.   FlexibleLinkType FlexibleLinkTypeEnum 0:1 Type of FLEXIBLE ROUTE LINK:\n hailAndRide\n onDemand\n fixed\n other\n     Parcours Service Pattern – Modèle Conceptuel\nMission commerciale ServiceJourneyPattern – Element     Classifi­cation Name Type Cardin­ality Description  :: :: LinkSequence :: JOURNEY PATTERN hérite de LINK SEQUENCE (voir le document Profil NeTEx éléments communs).  «FK» RouteRef RouteRef 0:1 ITINÉRAIRE utilisé par la MISSION COMMERCIALE.   DirectionType   Les informations de directions seront portées par l'ITINÉRAIRE.  «FK» DirectionRef DirectionRef 0:1 La DIRECTION d’une JOURNEY PATTERN est souvent utilisée pour distinguer des groupes de JOURNEY PATTERN utilisant les mêmes branches (c’est-à-dire des ROUTEs) d’une LIGNE.\nLa DIRECTION est disponible à des fins de filtrage exclusivement (par exemple dans une interface utilisateur de calculateur d’itinéraire ou un système d'information sur les horaires), mais ne devra pas être considérée comme une informations descriptive (ce n’est pas une information présentée « spontanément »).  «FK» Destination­Display­Ref DestinationDisplayRef 0:1 AFFICHAGE DE DESTINATION associée à la MISSION COMMERCIALE (voir le document Profil NeTEx éléments communs).  «cntd» pointsInSequence PointInJourneyPattern 0:* Liste ordonnée des points sur la MISSION COMMERCIALE (POINT D'ARRÊT SUR PARCOURS, POINT HORAIRE ou POINT SUR PARCOURS).  «cntd» linksInSequence ServiceLink 0:*  Liste ordonnée des sections de la MISSION COMMERCIALE (SERVICE LINK). Chaque section décrit la géométrie entre deux points consécutifs (ScheduleStopPoint).  «FK» ServiceJourneyPatternType ServiceJourneyPatternTypeEnumeration 0:1 Type de MISSION COMMERCIALE.\nIl s'agit d'un type \"étendu\" qui permet de typer tout PARCOURS présentant un intérêt pour l'information voyageur. Les valeurs possibles pour ce type sont:\n Passenger : service passager\n garageRunOut : sortie de garage/dépôt\n garageRunIn : retour de garage/dépôt\n turningManoeuvre : manœuvre de retournement (changement de sens en fin de parcours)\n other: autre type sans passager\n     Haut le pied Le profil étant dédié à l\u0026rsquo;information voyageur, on se limitera, pour la description des hauts le pied, à une bonne utilisation du champ ServiceJourneyPatternType présenté dans le tableau ci-dessus (ce champ permet de gérer le haut le pied pour lesquels on souhaite informer les voyageurs, en indiquant les départ et retour dépôt ou encore les manœuvre de retournement).\nPoint sur parcours PointInJourneyPattern – Element     Classifi­cation Name Type Cardinality Description  :: :: PointInLinkSequence :: POINT IN JOURNEY PATTERN hérite de POINT IN LINK SEQUENCE (voir )\nOn n'utilisera pas le LinkSequenceRefde cet héritage car, dans le contexte du profil, cet objet sera toujours \"à l'intérieur\" d'une MISSION COMMERCIALE.\n  «FK» PointRef PointRef 0:1 POINT à placer dans le PARCOURS (il peut s'agir de n'importe quel type de point).  «FK» Destination­DisplayRef DestinationDisplayRef 0:1 DESTINATION DISPLAY associée à ce POINT.\nCette information, qui sert à changer l'AFFICHAGE DE DESTINATION lorsque le véhicule arrive à ce POINT ne sera renseignée que si ChangeOfDestinationDisplayest VRAI\n   FlexiblePointProperties FlexiblePointProperties 0:1 Information sur l'éventuelle flexibilité du POINT (voir )   ChangeOf­DestinationDisplay xsd:boolean 0:1 Indique s'il faut changer l'AFFICHAGE DE DESTINATION en arrivant à ce POINT    Point d\u0026rsquo;arrêt sur parcours StopPointInJourneyPattern – Element (objet inclus)     Classifi­cation Name Type Cardin­ality Description  :: :: TimingPointInJourneyPattern :: STOP POINT IN JOURNEY PATTERN hérite de POINT IN LINK SEQUENCE (voir )\nOn n'utilisera pas le LinkSequenceRefde cet héritage car, dans le contexte du profil, cet objet sera toujours \"à l'intérieur\" d'une MISSION COMMERCIALE.\n  «FK» ScheduledStopPointRef ScheduledStopPointRef 1:1 Reference au POINT D'ARRÊT PLANIFIÉ.   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).  Choice Destination­DisplayRef DestinationDisplayRef 0:1 DESTINATION DISPLAY associée ce POINT.\nCette information, qui sert à changer l'AFFICHAGE DE DESTINATION lorsque le véhicule arrive à ce POINT ne sera renseignée que si ChangeOfDestinationDisplayest VRAI\n   FlexiblePointProperties FlexiblePointProperties 0:1 Information sur l'éventuelle flexibilité du POINT (voir )   ChangeOf­DestinationDisplay xsd:boolean 0:1 Indique s'il faut changer l'AFFICHAGE DE DESTINATION en arrivant à ce POINT.  «cntd» noticeAssignments NoticeAssignmentView 0:* NOTE associée au POINT.   RequestStop xsd:boolean 0:1 Indique que l'arrêt doit être demandé (bouton à l'intérieur du véhicule et faire un signe de la main depuis le quai, ou tout autre dispositif fonctionnellement similaire potentiellement précisé ci-dessous).   RequestMethod RequestMethodTypeEnum 0:1 Méthode de demander l’arrêt\n noneRequired (pas de demande nécessaire)\n handSignal (signe de main)\n turnOnLight (allumage d’une lumière)\n stopButton (bouton stop)\n phoneCall (appel téléphonique)\n mobileApp (application mobile)\n sms\n other\n    StopUse StopUseEnumeration 0:1 Type d'utilisation du POINT D'ARRÊT PLANIFIÉ dans la MISSION COMMERCIALE (access par défaut)\n access : accès au transport (montée et/ou descente)\n interchangeOnly : correspondance seulement\n passthrough : passage sans marquer l'arrêt\n noBoardingOrAlighting : arrêt sans montée ni descente\n    Booking­Arrangements BookingArrangements 0:1 Conditions de réservation pour cet arrêt quand elles sont différentes du SERVICE JOURNEY.    Point d\u0026rsquo;arrêt panifié ScheduledStopPoint – Element     Classifi­cation Name Type Cardin­ality Description  :: :: TimingPoint :: SCHEDULED STOP POINT hérite de TIMING POINT (voir ci-dessous).  «cntd» tariffZones TariffZoneRef 0:* ZONE TARIFAIRE à laquelle appartient le POINT D'ARRÊT PLANIFIÉ.   ShortName MultilingualString 0:1 Nom abrégé du POINT D'ARRÊT PLANIFIÉ.\nInformations à garder cohérente avec le lieu d'arrêt.\n   Description MultilingualString 0:1 Description du POINT D'ARRÊT PLANIFIÉ.  «AK» PublicCode xsd:normalizedString 0:1 Code publique du POINT D'ARRÊT PLANIFIÉ (code identifiant utilisé pour les services, par SMS par exemple).  «AK» PrivateCode xsd:normalizedString 0:1 Identifiant technique alternatif du POINT D'ARRÊT PLANIFIÉ.   StopType StopPlaceTypeEnum 0:1 Type de POINT D'ARRÊT PLANIFIÉ. Ce champ n'est retenu que pour fournir une information quand l'affection au LIEU D'ARRÊT n'est pas fournie (le LIEU D'ARRÊT porte cette information de type). Si StopTypeest fourni et l'affection au LIEU D'ARRÊT aussi, ces informations devront être cohérente (si ça ne l'est pas, c'est le LIEU D'ARRÊT qui sera pris comme référence).\n onstreetBus (bus sur voirie)\n onstreetTram (Tram sur voirie)\n airport (aéroport)\n railStation (Gare)\n metroStation (station de métro)\n busStation (gare routière)\n coachStation (station d’autocars)\n tramStation (station de Tram)\n harbourPort (port)\n ferryPort (port pour ferry)\n ferryStop (arrêt de ferry)\n liftStation (accès ascenseur ou téléphérique)\n vehicleRailInterchange (correspondance rail)\n other\n    Presentation PresentationStructure 0:1 Eléments de représentation associés au POINT D'ARRÊT PLANIFIÉ.   ForAlighting   Voir StopPointInJourneyPattern   ForBoarding   Voir StopPointInJourneyPattern   RequestStop   Voir StopPointInJourneyPattern  «FK» TopographicPlace­Ref   Ces informations seront portées par le lieu d'arrêt.    NOTE IMPORTANTE : Le profil France ne retient pas l\u0026rsquo;attribut Location du SCHEDULED STOP POINT, l\u0026rsquo;information est portée par les objets QUAY ou STOP PLACE.\nParcours horaire Le profil étant dédié à l\u0026rsquo;information voyageur, on se limitera, pour la description des parcours horaires, à utiliser la capacité des ServiceJourneyPattern à intégrer des TimingPointInJourneyPattern dans sa séquence de points, pour les point horaire qui ne sont pas des POINT D\u0026rsquo;ARRÊT PLANIFIÉs, et à instancier aux codes adéquats les champs TimingPointStatus et AllowedForWaitTime des POINT D\u0026rsquo;ARRÊT PLANIFIÉs (les informations plus détaillées de StopPointInJourneyPattern ne sont pas retenues).\nPoint horaire sur parcours TimingPointInJourneyPattern – Element (objet inclus)     Classifi­cation Name Type Cardin­ality Description  :: :: PointInSequence :: TIMING POINT IN JOURNEY PATTERN hérite de POINT IN LINK SEQUENCE (voir )\nOn n'utilisera pas le LinkSequenceRefde cet héritage car, dans le contexte du profil, cet objet sera toujours \"à l'intérieur\" d'une MISSION COMMERCIALE.\n   TimingPointRef ScheduledStopPointRef 1:1 Référence au POINT HORAIRE.               Point horaire TimingPoint – Element     Classifi­cation Name Type Cardin­ality Description  :: :: TimingPoint :: TIMING POINT hérite de POINT(voir le document Profil NeTEx éléments communs).   TimingPointStatus TimingPointStatusEnumeration 0:1 Nature du POINT HORAIRE:\n timingPoint : POINT HORAIRE utilisé pour la régulation\n secondaryTimingPoint : POINT HORAIRE utilisé pour la construction des horaires mais pas pour la régulation\n notTimingPoint\n    AllowedFor­WaitTime xsd:duration 0:1 Temps d'attente autorisé pour la régulation.    Correspondances La plupart des calculateurs d’itinéraires utilisent les temps de transfert pour un changement de véhicule de transport. Il peut éventuellement s’agir d’un temps d\u0026rsquo;échange par défaut à utiliser pour toutes les correspondances d\u0026rsquo;un MODE particulier ou à une station donnée, mais certains calculateurs permettent d\u0026rsquo;indiquer les temps de correspondances entre les quais.\nLe modèle NeTEx permet d\u0026rsquo;échanger un ensemble de correspondance pour la planification de voyage avec des niveaux de précision dépendant du contexte (par défaut, pour une station spécifique, pour un couple d\u0026rsquo;arrêts spécifique), héritant tous du concept TRANSFER.\nCorrespondances – Modèle conceptuel\nCorrespondance entre POINT D\u0026rsquo;ARRÊT PLANIFIÉs Connection – Element    Classifi­cation Name Type Cardin­ality Description     ::\u0026gt; ::\u0026gt; Transfer ::\u0026gt; CONNECTION hérite de TRANSFER.          «cntd» From ConnectionEnd 1:1 Point de départ de la CORRESPONDANCE   «cntd» To ConnectionEnd 1:1 Point de fin de la CORRESPONDANCE           ConnectionEnd – Element (objet inclus)     Classifi­cation Name Type Cardin­ality Description   TransportMode TransportModeEnum 0:1 MODE de transport concerné par cette extrémité de correspondance.\nCet attribut permet de particulariser les correspondances en fonction des modes de transport. Si rien n'est indiqué, tous les modes présents sont concernés. Si le mode est précisé, mais que certain modes présent n'ont pas de correspondance associée, c'est que la correspondance n'est pas possible pour ces modes.\n  «FK» ScheduledStopPointRef ScheduledStopPointRef 0:1 POINT D'ARRÊT PLANIFIÉ auquel se raccorde la CORRESPONDANCE.    Transferts Transfer – Element (abstrait)    Classifi­cation Name Type Cardin­ality Description  :: :: DataManagedObject :: TRANSFER hérite de DataManagedObject (voir le document Profil NeTEx éléments communs).   Name MultilingualString 0:1 Nom du TRANSFERT.  «FK» TypeOfTransfer­Ref TypeOfTransferRef 0:1 Type de TRANSFERT.\nUtilisé uniquement avec le code \"ADVERTISED\" pour signaler que la correspondance doit être affichée sur les média (information à l'arrêt).\n   Description MultilingualString 0:1 Description du TRANSFERT.   Distance DistanceType 0:1 Distance totale du TRANSFERT (en mètres).  «cntd» TransferDuration   Temps de correspondance total (marche plus temps d'attentes): non retenu pour le profil  «cntd» WalkTransfer­Duration TransferDuration 0:1 Temps de marche à la correspondance.   BothWays xsd:boolean 0:1 Indique si le TRANSFERT est bidirectionnel ou non (oui par défaut).  «cntd» (From) TransferEnd 1:1 Origine du TRANSFERT\nLe TRANFERT étant l'objet de correspondance le plus générique, les extrémités ne sont ici pas typées, elles le seront par contre dans les spécialisations du TRANSFERT.\n  «cntd» (To) TransferEnd 1:1 Fin du TRANSFERT    TransferDuration – Element (objet inclus)     Classifi­cation Name Type Cardin­ality Description   DefaultDuration xsd:duration 0:1\n1:1\n Durée par défaut (à pied)\nObligatoire dans le contexte du profil.\n   FrequentTraveller­Duration xsd:duration 0:1 Durée pour un voyageur habitué de ce parcours.   OccasionalTraveller­Duration xsd:duration 0:1 Durée pour un voyageur découvrant ce parcours.\nNote: on attend naturellement FrequentTraveller-DurationDefaultDurationOccasionalTraveller-Duration\n   MobilityRestricted­TravellerDuration xsd:duration 0:1 Durée pour un voyageur en mobilité réduite (bagages, poussette, handicap, etc.).    Informations par défaut sur les correspondances Les correspondances par défaut sont des objets \u0026ldquo;racine\u0026rdquo; (au niveau members du FRAME) et permettent de valoriser les correspondances implicites. Elles peuvent être particularisées par MODE ou par EXPLOITANT ou par LIEU TOPOGRAPHIQUE (ville, arrondissement, etc.). Cette information est particulièrement importante pour les calculateurs d\u0026rsquo;itinéraire.\nPar convention on fournira en général un DefaultConnectionsans contrainte pour le cas général, et on le particularisera par des versions spécifiques par MODE ou par EXPLOITANT qui viendront alors \u0026ldquo;surcharger\u0026rdquo; la version sans contrainte (la priorité est aux versions particularisées).\nDefaultConnection – Element    Classifi­cation Name Type Cardin­ality Description     ::\u0026gt; ::\u0026gt; Transfer ::\u0026gt; DEFAULT TRANSFER hérite de TRANSFER.   «cntd» From DefaultConnectionEnd 0:1 Origine du transfert (MODE / EXPLOITANT).   «cntd» To DefaultConnectionEnd 0:1 Fin du transfert (MODE / EXPLOITANT).   «FK» Topographic­PlaceView TopographicPlaceRef 0:* Zone administrative (typiquement une ville ou un groupement de commune) dans laquelle ces valeurs par défaut s’appliquent.   «FK» SiteElementRef SiteElementRef 0:* Elément de SITE dans lesquels ces valeurs par défaut s’appliquent.    DefaultConnectionEnd – Element (objet inclus)    Classifi­cation Name Type Cardin­ality Description     «FK» Mode TransportModeEnum 0:1 MODE associé à l\u0026rsquo;extrémité du transfert. L’énumération se trouve dans la partie Eléments communs.   «FK» OperatorRef OperatorRef 0:1 EXPLOITANT associé à l\u0026rsquo;extrémité du transfert.    Correspondance entre sites (LIEUx D\u0026rsquo;ARRÊT) Les correspondances entre sites permettent de créer simplement des relations entre LIEUX D\u0026rsquo;ARRÊT et les Points Of Interest (POI) sans avoir à descendre au niveau du NAVIGATION PATH (détail du cheminement piéton, dont on ne fera ici qu\u0026rsquo;une description minimale permettant d\u0026rsquo;indiquer la présence des principaux équipements, comme les ascenseurs, etc.). La structure est la même que pour les CORRESPONDANCEs, avec une spécialisation des extrémités et la possibilité de faire référence à un NAVIGATION PATH.\nCette structure permet aussi de caractériser de façon un peu plus détaillée les cheminements accès (STOP PLACE ENTRANCE) vers ZONE D\u0026rsquo;EMBARQUEMENT (QUAY).\nSiteConnection – Element     Classifi­cation Name Type Cardin­ality Description  :: :: Transfer :: SITE CONNECTION hérite de TRANSFER.  «cntd» From SiteConnectionEnd 0:1 Origine du lien entre sites  «cntd» To SiteConnectionEnd 0:1 Fin du lien entre sites   navigationPaths navigationPaths 0:1 Description du cheminement utilisé pour cette correspondance.\n(voir la partie accessibilité du profil pour plus de détails)\n    SiteConnectionEnd – Element (objet inclus)     Classifi­cation Name Type Cardin­ality Description               ScheduledStopPointRef   On limite dans le profil le SITE CONNECTION aux correspondances entre sites (LIEU D'ARRÊT, PARKING, POI) de façon à simplifier l'analyse des données et éviter toute possible confusion sémantique.  Choice StopPlaceRef StopPlaceRef 0:1 Reference to destination STOP PLACE of SITE CONNECTION.                 Choice QuayRef QuayRef 0:1 Référence à une ZONE D'EMBARGEMENT (voir profil NeTEx Arrêt)   StopPlaceEntranceRef StopPlaceEntranceRef 0:1 Référence à une entrée (entrée à utiliser pour cette correspondance)\n(voir profil NeTEx Arrêt)\n   PointOfInterestEndGroup PointOfInterestEndGroup 0:1 Eléments pour identifier un POI à la l’extrémité d’un SITE CONNECTION.\nOn pourra utilisera PointOfInterestRef avec une référence externe.\nNote: la valeur de ce champ sera précisée quand on disposera d'un profil pour les POIs.\n   ParrkingEndGroup ParkingEndGroup 0:1 Eléments pour identifier un PARKING à l’extrémité d’un SITE CONNECTION.\nOn utilisera PakingRef avec une référence externe.\nNote: la valeur de ce champ sera précisée quand on disposera d'un profil pour les PARKINGs.\n                      EXEMPLE XML\nL\u0026rsquo;exemple suivant illustre l\u0026rsquo;utilisation de références à des POI externes, la première provenant d\u0026rsquo;OSM en France et la seconde d\u0026rsquo;INSPIRE en Slovaquie. Notez que l\u0026rsquo;attribut versionRef est obligatoire pour les objets externes (la valeur peut être \u0026ldquo;any\u0026rdquo; si la version est inconnue ou le numéro de version réel du POI s\u0026rsquo;il est connu).\n \u0026lt;PointOfInterestRef ref=\u0026ldquo;FR_OSM_Poi:node:55711945\u0026rdquo; versionRef=\u0026ldquo;any\u0026rdquo;/\u0026gt;\n\u0026lt;PointOfInterestRef ref=\u0026ldquo;SK_INSPIRE_Poi:SK.SOPSK.SKUEV0319\u0026rdquo; versionRef=\u0026ldquo;any\u0026rdquo;/\u0026gt;\n Point of Interest Un POINT D\u0026rsquo;INTÉRÊT (POI) est un type de LIEU vers ou à partir duquel les passagers peuvent souhaiter se déplacer dans le cadre de leur déplacement (ce sont fréquemment des points de départ ou d’arrivé utilisés pour effectuer une requête à un calculateur d’itinéraire, ils sont aussi utilisés pour interroger la desserte de transport avoisinante, etc.).\nDans de nombreux cas, les POIs seront définis dans des bases de données externes (INSPIRE, OSM, ou jeux de données commerciaux) et simplement référencés par SITE CONNECTIONs. Toutefois la le formalisme NeTEx peut aussi permettre d’enrichir l’information issue d’une autre source (par exemple pour y décrire les service disponible, l’accessibilité, les équipements du lieu, etc.). Dans ces cas d’enrichissement, on prendra soin de bien conserver l’identifiant de l’objet enrichi et on utilisera le codespace adéquat (par exemple \u0026quot;FR_OSM:PointOfInteres:node:55711945\u0026quot;où 55711945 est bien d’identifiant OSM, pour enrichir une POI issu d’Open Street Map et permet nodede qualifier le type d’objet OSM pour garantir l’unicité de l’identifiant)\n PointOfInterest – XML Element      Classification Name Type Cardinality Description  :: :: Site :: POINT OF INTEREST hérite de SITE.  «PK» id PointOfInterestIdType 1:1 Identifier of: POINT OF INTEREST.  «cntd» classifications PointOfInterest­ClassificationRef | PointOfInterestClassificationView 0:* Classification du POINT OF INTEREST.\nSeul l'attribut Name de PointOfInterestClassificationView sera utilisé pour cette classification. Aucune classification standard n'est prédéfinie ni par NeTEx, ni par le profil.\n  «cntd» nearTopographic­Places TopographicPlaceRef 0:* TOPOGRAPHIC PLACEs proche du POINT OF INTEREST.    Cheminement La description du cheminement est ici limitée à ses caractéristiques principales (en particulier pour l\u0026rsquo;accessibilité).\nNote : la partie Accessibilité du profil France fournit une vue beaucoup plus détaillée du NavigationPath.\nNavigationPath – Element     Classifi­cation Name Type Cardin­ality Description  :: :: LinkSequence :: NAVIGATION PATH hérite de LINK SEQUENCE.   AccessFeature­List AccessFeatureEnum 0:* Type d'équipements qui seront rencontrés sur le cheminement (none par défaut).\nLes valeurs possibles sont:\n Lift (ascenseur)\n Escalator (escalier mécanique)\n freightElevator (monte charge)\n travelator (tapus roulant)\n ramp (rampe)\n stairs (escaliers)\n seriesOfStairs (serie d’escaliers)\n shuttle (navette)\n crossing (passage piéton)\n barrier (barrière)\n narrowEntrance (passage étroit)\n hall (hall, couloir)\n concourse (hall, esplanade)\n confinedSpace (espace réduit)\n queueManagement (gestion de queue)\n none (rine)\n unknown (inconnu)\n other (autre)\n openSpace (espace ouvert)\n street (rue)\n pavement (chaussée)\n footpath (chemin piéton)\n passage (couloir)\n    NavigationType NavigationTypeEnum 1:1 Type de cheminement. Les valeurs possibles sont:\n hallToQuay (hall vers quai)\n hallToStreet (hall vers rue)\n quayToHall (quai vers hall)\n quayToQuay (quai vers quai)\n quayToStreet (quai vers rue)\n streetToHall (rue vers hall)\n streetToQuay (rue vers quai)\n streetToSpace (rue vers esplanade)\n spaceToStreet (esplanade vers rue)\n spaceToHall (esplanade vers hall)\n hallToSpace (hall vers esplanade)\n spaceToSpace (esplanade vers esplanade)\n other (autre)\n     Contraintes et restrictions (ITL, etc.) Contraintes et restrictions – Modèle Conceptuel\nContraintes de zone. Les contraintes de zone sont particulièrement bien adaptées à la description des ITL (Interdiction de trafic local).\nRoutingConstraintZone – Element     Classifi­cation Name Type Cardin­ality Description  :: :: Zone :: ROUTING CONSTRAINT ZONE hérite de ZONE (voir le document Profil NeTEx éléments communs).\nNote: on définira généralement la zone par la liste des POINTs D'ARRÊT PLANIFIÉs concernés par la contrainte (une ZONE peut en effet être définie par un ensemble de points, par son attribut members). Si la ZONE n'est pas définie par un ensemble de points (et uniquement dans ce cas-là) c'est son périmètre géographique qui sera utilisé (il devra donc impérativement être défini).\n   ZoneUse ZoneUseTypeEnum 0:1 Contrainte appliquée à la ZONE :\n cannotBoardAndAlightInSameZone : un voyageur ne peut embarquer puis débarquer au sein de cette ZONE (ITL)\n mustAlightInZone: tous les voyageurs présents à l'entrée de la ZONE devront débarquée dans cette ZONE.\n cannotAlightInZone: tous les voyageurs présents à l'entrée de la ZONE ne pourront pas débarquer dans cette ZONE.\n other\n    lines lineRefs 0:* Liste des lignes concernées par la restriction   GroupOfLinesRef GroupOfLinesRef 0:1 Groupe de lignes ou réseau concerné par la restriction   pointsInPattern pointsInPattern  Cette propriété n'est pas retenue dans le profil France. Le champ member est utilisé, comme indiqué ci-dessus dans l'héritage de Zone.    Restriction de correspondance TransferRestriction – Element     Classifi­cation Name Type Cardin­ality Description  :: :: DataManagedObject :: TRANSFER RESTRICTION hérite de DATA MANAGED OBJECT (via ASSIGNMENT) (voir le document Profil NeTEx éléments communs).   Description MultilingualString 0:1 Description de la restriction de correspondance (explication/justification de son utilisation).   BothWays boolean 0:1 Indique si la restriction n'est que pour le sens direct ou pour les deux sens de correspondance.   RestrictionType TransferRestriction­TypeEnum 1:1 Type de restriction:\n cannotTransfer\n  Seule l'interdiction de correspondance est retenue dans le profil.\n  «FK» FromPointRef ScheduledStopPointRef 0:1 PONT D'ARRÊT PLANIFIÉ de départ\nSi seul le départ est indiqué, toutes les correspondances partantes sont interdites (et entrante aussi si BothWays=vrai).\nAu moins l'un des deux attributs FromPointRef ou ToPointRef doir être valorisé.\n  «FK» ToPointRef ScheduledStopPointRef 0:1 PONT D'ARRÊT PLANIFIÉ de destination.\nSi seul la destination est indiquée, toutes les correspondances arrivantes sont interdites (et sortantes aussi si BothWays=vrai).\nAu moins l'un des deux attributs FromPointRef ou ToPointRef doit être valorisé.\n    Affectation d\u0026rsquo;arrêt Cette affection permet de mettre en relation des LIEUx D\u0026rsquo;ARRÊT ou des ZONE D\u0026rsquo;EMBARQUEMENT (voir profil NeTEx Arrêt et modèle d\u0026rsquo;arrêt partagé de du ministère des transport) et les POINTs D\u0026rsquo;ARRÊT PLANIFIÉs.\nPassenger Stop Assignment – Modèle conceptuel\nStopAssignment – Element (abstrait)    Classifi­cation Name Type Cardin­ality Description     ::\u0026gt; ::\u0026gt; DataManagedObject ::\u0026gt; STOP ASSIGNMENT hérite de DATA MANAGED OBJECT (via ASSIGNMENT) (voir le document Profil NeTEx éléments communs).   «FK» ScheduledStop­PointRef ScheduledStopPointRef 0:1 Référence au POINT D\u0026rsquo;ARRÊT PLANIFIÉ.    PassengerStopAssignment – Element     Classifi­cation Name Type Cardin­ality Description  :: :: StopAssignment :: PASSENGER STOP ASSIGNMENT hérite de STOP ASSIGNMENT.  «FK» StopPlaceRef StopPlaceRef 1:1 Référence au LIEU D'ARRÊT associé Référence au POINT D'ARRÊT PLANIFIÉ.  «FK» QuayRef QuayRef 0:1 Eventuelle référence à la ZONE D'EMBARQUEMENT concernée.  «cntd» trainElements TrainStopAssignment 0:* Références à des affectations détaillées des positions de train (alignement des voitures sur les marques à quai).\nOn utilisera ici des objets indépendant (des références et non des inclusions) de façon à permettre une mise à jour de l’affectation de train, sans avoir à modifier l'affectation d'arrêt elle-même. De même on autorise que l'affectation de train référence l'affectation d'arrêt sans que la réciproque ne soit vraie (on pourra donc ne pas remplir le présent élément).\n    Affectation de train à quai TrainStopAssignment – Element     Classifi­cation Name Type Cardin­ality Description  :: :: StopAssignment :: TRAIN STOP ASSIGNMENT hérite de STOP ASSIGNMENT  «FK» PassengerStop­AssignmentRef PasssengerStop­AssignmentRef 0:1 Référence à l'affectation d'arrêt que l'affectation de train précise.  «FK» TrainRef TrainRef 0:1 Identifiant du train concerné.\nOn pourra soit utiliser l'identifiant d'un TRAIN défini par ailleurs, soit directement référencer un numéro de train en utilisant la convention suivante:\n L'attribut nameOfRefClass de la référence est positionné à \"TrainNumberRef\"\n L'attribut refde la référence est instancié avec le numéro de train (ex: \"9050\"pour l'Eurostar Londres-Paris de 19h01)\n   «FK» TrainComponent­Ref TrainComponenRef 0:1 COMPOSANT DE TRAIN (voiture) concerné par l'affectation de train.\nOn pourra soit utiliser l'identifiant d'un COMPOSANT DE TRAIN défini par ailleurs, soit directement référencer un numéro de voiture en utilisant la convention suivante:\n L'attribut nameOfRefClass de la référence est positionné à \"TrainComponentRef\"\n L'attribut refde la référence est instancié avec le numéro de voiture (ex: \"12\")\n   «FK» BoardingPositionRef BoardingPositionRef 0:1 Référence la POSITION D'EMBARQUEMENT avec laquelle le COMPOSANT DE TRAIN s'alignera.\nLa POSITION D'EMBARQUEMENT n'étant pas retenue dans le profil NeTEx Arrêt, on utilisera la convention suivante:\n L'attribut nameOfRefClass de la référence est positionné à \"BoardingPositionRef\"\n L'attribut refde la référence est instancié avec le nom de la marque à quay (ex: \"W\")\n     Affectation dynamique (pour affectation « tardive », mais toujours planifiée) DynamicStopAssignment – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; DynamicStopAssignment ::\u0026gt; DYNAMIC STOP ASSIGNMENT hérite de PASSENGER STOP ASSIGNMENT.   «PK» Id DynamicAssignmentIdType 1:1 Identifiant du DYNAMIC STOP ASSIGNMENT.   «FK» JourneyPatternRef JourneyPatternRef 0:1 JOURNEY PATTERN à laquelle la DYNAMIC STOP ASSIGNMENT s’applique.   «FK» PassengerStop­AssignmentRef PassengerStopAssignment­Ref 0:1 PASSENGER STOP ASSIGNMENT que le DYNAMIC STOP ASSIGNMENT remplace.    Plan schématique SchematicMap – Element     Classifi­cation Name Type Cardin­ality Description  :: :: DataManagedObject :: SCHEMATIC MAP hérite de DATA MANAGED OBJECT (voir le document Profil NeTEx éléments communs).   Name MultilingualString 0:1 Nom de la carte schématique   ImageUri xsd:anyURI 0:1 URL d'accès à la carte schématique\nLa carte schématique peut être aussi bien une image raster classique (.png, .jpg, etc.), qu'une image vectorielle (.svg, .ai, etc.).\n  «FK» DepictsObjectRef ObjectRef 1:1 Référence de l'objet transport représenté par cette carte (typiquement RESEAU, LIGNE, LIEU D'ARRÊT, etc.)  «cntd» members SchematicMapMember 0:* Objets transports représentés sur la carte schématique.    SchematicMapMember – Element (objet inclus)     Classifi­cation Name Type Cardin­ality Description  :: :: GroupMember :: SCHEMATIC MAP MEMBER hérite de GROUP MEMBER (voir le document Profil NeTEx éléments communs).  «FK» VersionOfObjectRef ObjectRef 0:1 Référence de l'objet transport (NeTEx) représenté sur la carte.   InfoLink InfoLink 0:1 URL vers l'objet dans la carte schématique:\nOn utilisera la syntaxe HTML de référencement par ancre (\"anchor\", avec la syntaxe #anchor, par exemple http://www.macarte.com/schma.svg#objectId) pour référencer un objet vectoriel identifié. L'URL de la carte schématique étant fournie par l'attribut ImageUri, on pourra ne fournir que la référence de l'objet (#objectId)\n   x GraphicsUnitsTypeType 1:1 Coordonnée (abscisse) de l'objet dans l'environnement de la carte schématique (pixel ou unité graphique suivant le type de carte schématique)   y GraphicsUnitsTypeType 1:1 Coordonnée (ordonnées) de l'objet dans l'environnement de la carte schématique (pixel ou unité graphique suivant le type de carte schématique)    Entêtes NeTEx Note: les entêtes NeTEx sont présentés dans le document éléments communs. Seules les spécificités de la partie \u0026ldquo;description du réseau\u0026rdquo; sont présentées ici.\nDeux FRAMEs distinctes sont utilisées pour échanger la description des réseaux :\n Une FRAME de type NETEX_RESEAU, utilisée dans le fichier \u0026ldquo;network.xml\u0026rdquo; Une FRAME de type NETEX_LIGNE, utilisée dans le fichier \u0026ldquo;line_xyz.xml\u0026rdquo;  Pour rappel, la liste des fichiers d\u0026rsquo;un export NeTEx profil France est décrite dans Éléments Communs.\nTypeOfFrame : type spécifique NETEX_RESEAU Lorsqu\u0026rsquo;une FRAME a pour TypeOfFrame la valeur NETEX_RESEAU, seuls les objets de premier niveau suivants sont autorisés :\n Network GroupOfLines RoutingContraintZone  Voici un exemple de cadre du fichier network.xml :\n\u0026lt;?xml version=\u0026#34;1.0\u0026#34; encoding=\u0026#34;utf-8\u0026#34;?\u0026gt; \u0026lt;PublicationDelivery xmlns=\u0026#34;http://www.netex.org.uk/netex\u0026#34; version=\u0026#34;2.0:FR-NETEX-2.4\u0026#34;\u0026gt; \u0026lt;PublicationTimestamp\u0026gt;2025-02-27T00:00:00.0Z\u0026lt;/PublicationTimestamp\u0026gt; \u0026lt;ParticipantRef\u0026gt;Exemple\u0026lt;/ParticipantRef\u0026gt; \u0026lt;dataObjects\u0026gt; \u0026lt;GeneralFrame id=\u0026#34;exemple:GeneralFrame:NETEX_RESEAU_1\u0026#34; version=\u0026#34;2.0:FR-NETEX-2.4\u0026#34;\u0026gt; \u0026lt;TypeOfFrameRef ref=\u0026#34;FR:TypeOfFrame:NETEX_RESEAU:\u0026#34; /\u0026gt; \u0026lt;members\u0026gt; \u0026lt;!-- NETWORK GROUP OF LINES ROUTING CONSTRAINT ZONE --\u0026gt; \u0026lt;/members\u0026gt; \u0026lt;/GeneralFrame\u0026gt; \u0026lt;/dataObjects\u0026gt; \u0026lt;/PublicationDelivery\u0026gt; TypeOfFrame : type spécifique NETEX_LINE et NETEX_LIGNE_STRUCTURE Lorsqu\u0026rsquo;une FRAME a pour TypeOfFrame la valeur NETEX_LINE, il s\u0026rsquo;agit un objet CompositeFrame, lui-même composé de :\n Une GeneralFrame de type NETEX_LIGNE_STRUCTURE (voir ci-dessous) Une GeneralFrame de type NETEX_HORAIRE, décrit dans la partie Horaires du profil  La Frame de type NETEX_LIGNE_STRUCTURE ne contient que les objets de premier niveau suivants (et les objets qui en héritent) :\n Pour la partie de description générale des lignes  Line Direction Route RoutePoint PointOnRoute RouteLink FlexibleLine FlexibleRoute Route   Pour la partie plus précise de la ligne :  DestinationDisplay FlexiblePointProperties ServiceJourneyPattern PointInJourneyPattern ScheduledStopPoint TimingPoint TransferRestriction PassengerStopAssignement FlexibleStopAssignment TrainStopAssignment SchematicMap    Voici un exemple de cadre du fichier line_xyz.xml :\n\u0026lt;?xml version=\u0026#34;1.0\u0026#34; encoding=\u0026#34;utf-8\u0026#34;?\u0026gt; \u0026lt;PublicationDelivery xmlns=\u0026#34;http://www.netex.org.uk/netex\u0026#34; version=\u0026#34;2.0:FR-NETEX-2.4\u0026#34;\u0026gt; \u0026lt;PublicationTimestamp\u0026gt;2023-01-01T00:00:00.0Z\u0026lt;/PublicationTimestamp\u0026gt; \u0026lt;ParticipantRef\u0026gt;Exemple\u0026lt;/ParticipantRef\u0026gt; \u0026lt;dataObjects\u0026gt; \u0026lt;CompositeFrame id=\u0026#34;FR:CompositeFrame:NETEX_LIGNE-line_xyz:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;TypeOfFrameRef ref=\u0026#34;FR:TypeOfFrame:NETEX_LIGNE:\u0026#34; /\u0026gt; \u0026lt;frames\u0026gt; \u0026lt;GeneralFrame id=\u0026#34;FR:GeneralFrame:NETEX_RESEAU-line_xyz:LOC\u0026#34; version=\u0026#34;2.0:FR-NETEX-2.4\u0026#34;\u0026gt; \u0026lt;TypeOfFrameRef ref=\u0026#34;FR:TypeOfFrame:NETEX_LIGNE_STRUCTURE:\u0026#34; /\u0026gt; \u0026lt;members\u0026gt; \u0026lt;Line id=\u0026#34;sample\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Ligne d\u0026#39;exemple\u0026lt;/Name\u0026gt; \u0026lt;/Line\u0026gt; \u0026lt;!-- Partie Ligne Peut contenir (chaque objet contiendra ses objets sous-jacents, les éléments listés ici pourront être référencés dans les autres objets) LINE DIRECTION ROUTE ROUTE POINT POINT ON ROUTE ROUTE LINK FLEXIBLE LINE FLEXIBLE ROUTE --\u0026gt; \u0026lt;!-- Partie Reseau DESTINATION DISPLAY FLEXIBLE POINT PROPERTIES FLEXIBLE LINK PROPERTIES SERVICE JOURNEY PATTERN POINT IN JOURNEY PATTERN SCHEDULED STOP POINT TIMING POINT TRANSFER RESTRICTION PASSENGER STOP ASSIGNMENT FLEXIBLE STOP ASSIGNMENT TRAIN STOP ASSIGNMENT SCHEMATIC MAP --\u0026gt; \u0026lt;/members\u0026gt; \u0026lt;/GeneralFrame\u0026gt; \u0026lt;GeneralFrame id=\u0026#34;FR:GeneralFrame:NETEX_HORAIRE-line_xyz:LOC\u0026#34; version=\u0026#34;2.0:FR-NETEX-2.4\u0026#34;\u0026gt; \u0026lt;TypeOfFrameRef ref=\u0026#34;FR:TypeOfFrame:NETEX_HORAIRE:\u0026#34; /\u0026gt; \u0026lt;members\u0026gt; \u0026lt;!-- Peut contenir SERVICE JOURNEY SERVICE LINK FLEXIBLE SERVICE PROPERTIES TEMPLATE SERVICE JOURNEY HEADWAY JOURNEY GROUP RHYTHMICAL JOURNEY GROUP COUPLED JOURNEY JOURNEY PART COUPLE JOURNEY PART TRAIN TRAIN COMPONENT COMPOUND TRAIN TRAIN NUMBER TRAIN COMPONENT LABEL ASSIGNMENT --\u0026gt; \u0026lt;/members\u0026gt; \u0026lt;/GeneralFrame\u0026gt; \u0026lt;/dataObjects\u0026gt; \u0026lt;/PublicationDelivery\u0026gt; Bibliographie\nEN 15531-1, Public transport - Service interface for real-time information relating to public transport operations - Part 1: Context and framework\nEN 15531-2, Public transport - Service interface for real-time information relating to public transport operations - Part 2: Communications infrastructure3\nEN 15531-3, Public transport - Service interface for real-time information relating to public transport operations - Part 3: Functional service interfaces4\nCEN/TS 15531-4, Public transport - Service interface for real-time information relating to public transport operations - Part 4: Functional service interfaces: Facility Monitoring\nCEN/TS 15531-5, Public transport - Service interface for real-time information relating to public transport operations - Part 5: Functional service interfaces - Situation Exchange\n","permalink":"https://deploy-preview-56--transport-normes.netlify.app/normes/netex/reseaux/","summary":"Avant-propos\nL’harmonisation des pratiques dans l’échange des données relatives aux offres de transport est essentielle :\n  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) ;\n  pour les AOT, 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ée par voie contractuelle.","title":"NeTEx - Profil France v2.4 - Description des réseaux"},{"content":"Avant-propos\nL’harmonisation des pratiques dans l’échange des données relatives aux offres de transport est essentielle :\n  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) ;\n  pour les AOT, 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 ;\n  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)\n  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\n  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 le profil d’échange Profil NeTEx Horaires: \u0026ldquo;format de référence pour l\u0026rsquo;échange de données de description des horaires\u0026rdquo; (issu des travaux NeTEx, Transmodel et IFOPT) qui aujourd’hui fait consensus dans les groupes de normalisation (CN03/GT7 – Transport public / information voyageur).\nCe document a été validé et publié comme suit :\n travaux de révision : 2024-2025 date de validation en CN03 : 19 décembre 2025 date de publication : 6 mars 2026  Introduction\nLe présent document fait partie du profil France de NeTEx.\nNeTEx (CEN/TS 16614 series) propose un format et des services d\u0026rsquo;échange de données de description de l\u0026rsquo;offre de transport planifiée, basé sur Transmodel (EN 12896 series) et l’ancienne norme IFOPT (EN 28701). NeTEx permet non seulement d\u0026rsquo;assurer les échanges pour les systèmes d\u0026rsquo;information voyageur mais traite aussi l’ensemble des concepts nécessaires en entrée et sortie des systèmes de planification de l\u0026rsquo;offre (graphiquage, etc.) et des SAE (Systèmes d’Aide à l’Exploitation).\nNeTEx se décompose en six parties:\n  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)\n  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)\n  Partie 3 : information tarifaire (uniquement à vocation d’information voyageur)\n  Partie 4 : profil européen pour l\u0026rsquo;information voyageur (EPIP)\n  Partie 5 : nouveaux modes (les véhicules partagés en libre service, les courses partagées, etc.)\n  Partie 6 : profil européen pour l\u0026rsquo;information voyageur en lien avec l\u0026rsquo;accessibilité (EPIAP)\n  NeTEx a été développé dans le cadre du CEN/TC 278/WG 3/SG 9 piloté par la France. Les premières publications de NeTEx datent de 2014 et les plus récentes de mars 2026.\nIl faut noter que NeTEx a été l\u0026rsquo;occasion de renforcer les liens du CEN/TC278/WG3 avec le secteur ferrovaire, en particulier grâce à la participation de l\u0026rsquo;ERA (Agence Européen du Rail, qui a intégré NeTEx dans la directive Européenne 454/2011 TAP-TSI ) et de l\u0026rsquo;UIC (Union International des Chemins de fer).\nLes 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.\nIl en résulte des normes qui sont relativement volumineuses et dont le périmètre dépasse souvent largement les besoins d\u0026rsquo;une utilisation donnée. Ainsi, à titre d\u0026rsquo;exemple, SIRI propose toute une série d\u0026rsquo;options ou de mécanismes dont la vocation est d\u0026rsquo;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\u0026rsquo;ils sont dès aujourd\u0026rsquo;hui pertinents en Suisse ou en Allemagne, sont pratiquement inexistants en France.\nDe plus, un certain nombre de spécificités locales ou nationales peuvent amener à préciser l\u0026rsquo;usage ou la codification qui sera utilisée pour certaines informations. Par exemple, les Anglais disposant d\u0026rsquo;un référentiel national d\u0026rsquo;identification des points d\u0026rsquo;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.\nEnfin, certains éléments proposés par ces normes sont facultatifs et il convient, lors d\u0026rsquo;une implémentation, de décider si ces éléments seront ou non implémentés.\nL\u0026rsquo;utilisation des normes liées à l\u0026rsquo;implémentation de l\u0026rsquo;interopérabilité pour le transport en commun passe donc systématiquement par la définition d\u0026rsquo;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 :\n  détail des services utilisés,\n  détails des objets utilisés dans un échange,\n  précisions sur les options proposées par la norme,\n  précision sur les éléments facultatifs,\n  précision sur les codifications à utiliser,\n  etc.\n  Ce document présente la partie Horaires du profil France de NeTEx, tel que défini par le Groupe de Travail dédié à l\u0026rsquo;information voyageur et à l\u0026rsquo;exploitation des services de mobilité (GT7) au sein de la Commission Nationale de normalisation pour le transport public (CN03).\nD\u0026rsquo;autres parties du profil France de NeTEx sont disponibles (arrêts, réseau, tarif, accessibilité, parking). Ils sont tous complémentaires les uns des autres (sans recouvrement) et s\u0026rsquo;appuient tous sur le document: NeTEx - Profil France - Éléments communs. Il conviendra de se référer à ce document pour tous les éléments utilisés dans le présent document, et dont la structure n\u0026rsquo;est pas détaillée.\nCe profil d’échange a pour objectif de décrire et de structurer précisément les éléments nécessaires à une bonne information de description des horaires de transport public de façon :\n  à pouvoir les présenter d’une manière homogène et compréhensible à l’usager des transports publics sur des supports différents (papier ou Internet),\n  à pouvoir les échanger entre systèmes d’information (systèmes d’information voyageurs et systèmes d’information multimodale, systèmes d’aide à l’exploitation, systèmes de planification, systèmes billettiques, etc.).\n  Les éléments présentés ci-dessous couvrent donc l’ensemble des concepts propres à la description des horaires.\nNOTE IMPORTANTE Ce document étant un profil d\u0026rsquo;échange de NeTEx, il ne se substitue en aucun cas à NeTEx, et un minimum de connaissance de NeTEx sera nécessaire à sa bonne compréhension.\nDomaine d\u0026rsquo;application Le présent document est le profil de la CEN/TS 16614 (NeTEx) pour l\u0026rsquo;échange de données de description des horaires en France et permet de décrire les horaires de transports publics et la manière dont ils pourront être structurés pour des échanges entre systèmes d\u0026rsquo;information ainsi que pour leur présentation aux voyageurs.\nCe sont les services de transport et leurs horaires au sens large (heures de passage, fréquences, jours d\u0026rsquo;application) qui sont pris en compte dans ce contexte, et non la structure de l\u0026rsquo;offre de transport (voir les profils arrêt et réseau pour cela).\nRéférences normatives Les documents de référence suivants sont indispensables pour l\u0026rsquo;application du présent document. Pour les références datées, seule l\u0026rsquo;édition citée s\u0026rsquo;applique. Pour les références non datées, la dernière édition du document de référence s\u0026rsquo;applique (y compris les éventuels amendements).\nCEN/TS 16614-1, Network and Timetable Exchange (NeTEx) — Part 1: Public transport network topology exchange format\nCEN/TS 16614-2, Network and Timetable Exchange (NeTEx) — Part 2: Public transport scheduled timetables exchange format\nEN 12896, Road transport and traffic telematics - Public transport - Reference data model (Transmodel)\nTermes et définitions Pour les besoins du présent document, les termes et définitions suivants s\u0026rsquo;appliquent. Ils sont directement issus de Transmodel et NeTEx. L\u0026rsquo;Error: Reference source not found complète ces définitions par des explications plus détaillées. Pour une information complète, il conviendra toutefois de se référer au document normatif.\nNOTE Les termes spécifiquement introduits par le profil d’arrêt sont signalés par le mot (profil), en italique et entre parenthèses. Les définitions ci-dessus sont des traductions littérales du document normatif.\nCOUPLED JOURNEY (COURSE COUPLÉE) Un voyage complet opéré par un train couplé, composé de deux COURSES, ou plus, restant couplées tout au long d’un PARCOURS. Une COURSE COUPLÉE peut être considérée comme une simple COURSE.\nDATED PASSING TIME (HEURE DE PASSAGE DATÉE) HEURE DE PASSAGE pour un JOUR D\u0026rsquo;EXPLOITATION donné. Cet objet restera abstrait dans le contexte de ce profil et ne sera utiliséutilisé qu’au travers de sa spécialisation en HEURE DE PASSAGE COMMANDÉE.\nDATED VEHICLE JOURNEY (COURSE DATÉE) Service service particulier d\u0026rsquo;un véhicule sur un jour de fonctionnement particulier, y compris toutes les modifications éventuellement décidées par le personnel de contrôle. Cet objet restera abstrait dans le contexte de ce profil et ne sera utilisé qu’au travers de sa spécialisation en COURSE DATÉE NORMALE.\nDEAD RUN (HAUT LE PIED) Un service voiture haut-le-pied (non commercial).\nDEFAULT INTERCHANGE (CORRESPONDANCE PAR DEFAUT) Paramètre définissant la durée acceptable (maximum autorisée et objectif de durée standard) pour une correspondance entre deux POINTS D\u0026rsquo;ARRÊT.\nFLEXIBLE SERVICE PROPERTIES (PROPRIÉTÉS DE COURSE FLEXIBLE) Propriété supplémentaire d\u0026rsquo;un service permettant de caractériser sa flexibilité. Un service peut n\u0026rsquo;être que partiellement flexible.\nHEADWAY INTERVAL (INTERVAL) Intervalle temporel caractérisant un GROUPE DE COURSE À INTERVALLE (par exemple toutes les 10 minutes ou toutes les 4 à 6 minutes).\nHEADWAY JOURNEY GROUP (GROUPE DE COURSES EN FRÉQUENCE) Groupe de COURSEs suivant le même PARCOURS et dont les départs sont séparés d\u0026rsquo;un intervalle temporel fixe au sein d\u0026rsquo;un créneau horaire donné (par exemple toutes les 10 minutes entre 8h et 10h30). Cette information est particulièrement utile dans le cadre de l\u0026rsquo;information voyageur. Le créneau horaire est exprimé par l\u0026rsquo;objet TIME BAND.\nINTERCHANGE (CORRESPONDANCE DE COURSES) Une possibilité théorique de correspondance entre courses intervenant à un seul POINT D\u0026rsquo;ARRÊT ou entre différents POINTs D\u0026rsquo;ARRÊT.\nJOURNEY FREQUENCY GROUP (GROUPE DE COURSES EN FRÉQUENCE) Définit un groupe de COURSEs afin de leur attribuer un comportement particulier comme un service en fréquence ou un service cadencé (passe toutes les heures ..h10, ..h25 et ..h45 par exemple).\nJOURNEY PART (PARTIE DE COURSE) Une partie d\u0026rsquo;une COURSE créée dans un but fonctionnel spécifique, notamment dans les situations lors de couplage ou de séparation de véhicule.\nJOURNEY PART COUPLE (COUPLE DE PARTIES DE COURSE) Deux PARTIEs DE COURSEs de différentes COURSES effectuées simultanément par un train constitué par le couplage de plusieurs véhicules ou rames.\nNORMAL DATED VEHICLE JOURNEY (COURSE DATÉE NORMALE) Une COURSE DATÉE correspondant à la planification du parcours des véhicules.\nPASSING TIME (HEURE DE PASSAGE) Données temporelles concernant le passage des véhicules de transport public à un POINT particulier (par exemple heure d\u0026rsquo;arrivée, heure de départ, temps d\u0026rsquo;attente).\nRHYTMHICAL JOURNEY GROUP (GROUPE DE COURSES CADENCÉES) Groupe de COURSEs suivant le même PARCOURS et répétant le même rythme de départ toutes les heures (passe toutes les heures ..h10, ..h25 et ..h45 par exemple) et ce dans un créneau horaire donnée. Le créneau horaire est exprimé par l\u0026rsquo;objet TIME BAND sur le schéma.\nSERVICE JOURNEY (COURSE COMMERCIALE) Une COURSE transportant des passagers prévus pour un JOUR TYPE donné. Le déroulement est en principe défini par le PARCOURS COMMERCIAL.\nSERVICE JOURNEY INTERCHANGE (CORRESPONDANCE DE COURSES COMMERCIALES) Une possibilité théorique de correspondance entre COURSEs COMMERCIALEs intervenant à un seul POINT D\u0026rsquo;ARRÊT ou entre différents POINTs D\u0026rsquo;ARRÊT.\nTARGET PASSING TIME (HEURE DE PASSAGE COMMANDÉE) Données temporelles indiquant l\u0026rsquo;objectif à atteindre quant au passage du véhicule à un POINT SUR PARCOURS particulier pour une COURSE DATÉE afin de respecter l\u0026rsquo;horaire en vigueur. Concrètement il s\u0026rsquo;agit de l\u0026rsquo;adaptation des HEUREs DE PASSAGE DATÉEs faite en exploitation pour prendre en compte les changements de condition d\u0026rsquo;exploitation en amont du départ du véhicule (travaux, etc.).\nTEMPLATE SERVICE JOURNEY (MODÈLE DE COURCE COMMERCIALE) COURSE DE RÉFÉRENCE transportant des voyageurs.\nTEMPLATE VEHICLE JOURNEY (COURSE DE RÉFÉRENCE) COURSE modèle dont l\u0026rsquo;occurrence a été spécifiée au sein d\u0026rsquo;un GROUPE DE COURSE À INTERVALLE ou d\u0026rsquo;un GROUPE DE COURSE CADENCÉ; elle peut donc représenter un grand nombre de COURSEs.\nTIMETABLE PASSING TIME (HEURE DE PASSAGE PLANIFIÉE) Donnée temporelle théorique relative au passage d\u0026rsquo;un véhicule de transport public à un POINT SUR PARCOURS donné sur une COURSE et pour un JOUR TYPE. On notera qu\u0026rsquo;il ne s\u0026rsquo;agit pas d\u0026rsquo;une simple heure de franchissement, mais que cette heure de passage est constituée de l’heure de d’arrivée et de départ ainsi que d’informations associées (quai, marges d’erreur, etc.).\nTRAIN (TRAIN) Un véhicule composé d\u0026rsquo;ÉLÉMENTs DE TRAIN dans un certain ordre, c\u0026rsquo;est-à-dire de voitures reliées et tirées par une locomotive ou une des voitures.\nTRAIN COMPONENT (COMPOSANT DE TRAIN) La position d\u0026rsquo;un ÉLÉMENT DE TRAIN dans un TRAIN.\nTRAIN COMPONENT LABEL ASSIGNMENT (AFFECTION DE LABEL DE VOITURE) L\u0026rsquo;affectation d\u0026rsquo;une désignation annoncée pour un véhicule ou un élément de véhicule pour passagers. Concrètement, cela permet de connaître le libellé de la voiture (tel qu’indiqué sur la réservation du voyageur). Ce libellé ne dépend pas que du type de TRAIN mais aussi de la COURSE à laquelle il est affecté.\nTRAIN ELEMENT (ÉLÉMENT DE TRAIN) Une composante élémentaire d\u0026rsquo;un TRAIN (par exemple voiture, locomotive).\nTRAIN IN COMPOUND TRAIN (TRAIN DANS UN TRAIN COMPOSÉ) La position d\u0026rsquo;un TRAIN dans un TRAIN COMPOSÉ.\nTRAIN NUMBER (NUMÉRO DE TRAIN) Spécification spécification des codes attribués à certaines COURSES ou PARTIE DE COURSE, lorsqu\u0026rsquo;elles sont réalisées par des TRAINs ou des TRAINs COMPOSÉs, pour répondre à un objectif fonctionnel (d\u0026rsquo;information des passagers, suivi des opérations, etc).\nTYPE OF FLEXIBLE SERVICE (TYPE DE COURSE FLEXIBLE) Classification classification des services flexibles.\nVEHICLE JOURNEY (COURSE) Le mouvement planifié d\u0026rsquo;un véhicule de transport public effectué un JOUR TYPE donné, depuis un point début à un point fin d\u0026rsquo;un PARCOURS sur un ITINÉRAIRE. La COURSE est donc l\u0026rsquo;instanciation d\u0026rsquo;un PARCOURS donné, auquel on va attribuer des heures de passage aux arrêts et des jours d\u0026rsquo;application.\nVEHICLE MODEL (MODÈLE DE VEHICULE) Une classification des véhicules de transport public d\u0026rsquo;un même TYPE DE VÉHICULE, par exemple suivant les spécifications relatives aux équipements ou à la génération du modèle.\nVEHICLE TYPE (TYPE DE VEHICULE) Une classification des véhicules de transport public résultant des spécifications de la planification des horaires en tenant compte du mode de transport et de la capacité requise (par exemple bus standard, bus à étage, …).\nSymboles et abréviations   AO : Autorité Organisatrice de Transports\n  PMR : Personne à Mobilité Réduite\n  Exigences minimales liées au code des transports et la règlementation européenne La mise à disposition des données, quand elles existent, est obligatoire et se conforme aux exigences :\n Au niveau européen, du règlement délégué (UE) 2017/1926 de la Commission du 31 mai 2017 modifié par le règlement délégué (UE) 2024/490 de la Commission du 29 novembre 2023 (https://eur-lex.europa.eu/eli/reg_del/2017/1926/2024-03-04), dit \u0026ldquo;règlement MMTIS\u0026rdquo; ; Au niveau français, des articles L. 1115-1 à L. 1115-7 , D. 1115-1, R. 1115-2 à R. 1115-8 et D. 1115-9 à D. 1115-11 du code du transports, notamment créés ou modifiés par les articles 25 et 27 de loi n° 2019-1428 du 24 décembre 2019 d’orientation des mobilités, dites loi « LOM ». Ces mêmes articles de la LOM précise le calendrier de mise à disposition des données.  Le tableau ci-dessous résulte de l’analyse du code des transports et du règlement MMTIS et fournit la liste des concepts concernés dans le présent profil correspondant aux données mentionnées dans l’annexe du règlement. Il sera donc nécessaire de fournir ces données pour être conforme au cadre réglementaire (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).\nNotez que beaucoup de concepts dépendent des concepts issus de Transmodel/NeTEx et sont liés entre eux, soit par héritage, soit par relation au sens UML des termes. Par ailleurs, certains concepts additionnels peuvent relever d’autres parties du profil France, précisés dans le tableau le cas échéant.\nDe plus, 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.\nPour 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).\nLa 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).\nLes 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).\nConcepts relatifs à la LOM et à la Règlementation Européenne     Niveau Catégorie Détail Concepts à minima Autres\nconcepts\n Commentaire    2 Trip plans, auxiliary information, availability check Vehicle facilities such as classes of carriage, on-board Wi-Fi VEHICLE TYPE et FACILITIES associées    3 Trip plans Parameters such as fuel consumption needed to calculate cost VEHICLE TYPE  Ne fournit qu'une partie de l'information nécessaire pour un véritable calcul de consomation (à partir du VEHICLE TYPE, dautres sources de données devront être utilisées)  1 Trip plan computation — scheduled modes transport Timetables SERVICE JOURNEY\nTIMETABLE PASSING TIME JOURNEY FREQUENCY GROUP\nHEADWAY JOURNEY GROUP\nTEMPLATE SERVICE JOURNEY Ne pas oublier les calendriers d'application associés (profil éléments communs) et bien sûr tous les éléments cosntitutifs des SERVICE JOURNEY.  1 Trip plan computation — scheduled modes transport Vehicles (low floor; wheelchair accessible.) VEHICLE TYPE et FACILITIES associées (partie Accessibilité)\nEQUIPMENT\n   1 Trip plan computation — scheduled modes transport Hours of operation SERVICE JOURNEY\nTIMETABLE PASSING TIME\nAVAILABILITY CONDITIONS      Description du profil d’échange Conventions de représentation Tableaux d’attributs NOTE les choix de conventions présentées ici ont pour vocation d\u0026rsquo;être cohérents avec ceux réalisés dans le cadre du profil SIRI (Île-de-France Mobilités et CEREMA). De plus tous les profils NeTEx partagent les mêmes conventions.\nLes messages constituant ce profil d\u0026rsquo;é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:\n   Classifi­cation Nom Type Cardin­alité Description      Classification : permet de catégoriser l\u0026rsquo;attribut. Les principales catégories sont:\n  PK (Public Key) que l\u0026rsquo;on peut interpréter comme Identifiant Unique: il permet à lui seul d\u0026rsquo;identifier l\u0026rsquo;objet, de façon unique, pérenne et non ambiguë. C\u0026rsquo;est l\u0026rsquo;identifiant qui sera utilisé pour référencer l\u0026rsquo;objet dans les relations.\n  AK (Alternate Key) est un identifiant secondaire, généralement utilisé pour la communication, mais qui ne sera pas utilisé dans les relations.\n  FK (Foreign Key) indique que l\u0026rsquo;attribut contient l\u0026rsquo;identifiant unique (PK) d\u0026rsquo;un autre objet avec lequel il est en relation.\n  GROUP est un groupe XML nommé (ensemble d\u0026rsquo;attributs utilisables dans différents contextes) Voir ici.\n    Nom : nom de l\u0026rsquo;élément ou attribut XSD\n  Type : type de l\u0026rsquo;élément ou attribut XSD (pour certains d\u0026rsquo;entre eux, il conviendra de se référer à la XSD NeTEx)\n  Cardinalité : cardinalité de l\u0026rsquo;élément ou attribut XSD exprimée sous la forme \u0026ldquo;minimum:maximum\u0026rdquo; (\u0026ldquo;0:1\u0026rdquo; pour au plus une occurrence; \u0026ldquo;1:*\u0026rdquo; au moins une occurrence et sans limites de nombre maximal; \u0026ldquo;1:1\u0026rdquo; une et une seule occurrence; etc.).\n  Description : texte de description de l\u0026rsquo;é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).\n  Les textes surlignés en Jaune sont ceux présentant une particularité (spécialisation) par rapport à NeTEx: une codification particulière, une restriction d\u0026rsquo;usage, etc.\nLa description XSD utilisée est strictement celle de NeTEx, sans aucune modification (ceci explique notamment que tous les commentaires soient en anglais).\nLes attributs et éléments rendus obligatoires dans le cadre de ce profil restent facultatifs dans l\u0026rsquo;XSD (le contrôle de cardinalité devra donc être réalisé applicativement).\nValeurs 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:\n  des énumérations fixes définies dans le cadre du schéma XSD NeTEx. Le profil impose alors un sous-ensemble des codes NeTEx.\n  des 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\u0026rsquo;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».\n  des instances TypeOfFrame: le profil utilise plusieurs TYPES DE FRAME pour spécifier l\u0026rsquo;utilisation de VERSION FRAME dans le profil.\n  Indication des classes abstraites NeTEx, et Transmodel, utilisent largement l\u0026rsquo;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’existe aucune instance concrète; seules les sous-classes terminales sont «concrètes».\nUn inconvénient de l\u0026rsquo;héritage est que si l\u0026rsquo;on veut comprendre les propriétés d\u0026rsquo;une classe concrète unique, il faut également examiner toutes ses super-classes. Pour cette raison, le profil 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.\n  Les super-classes sont signalées dans les en-têtes par le suffixe «(abstrait)»\n  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.\n  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.\n  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) ».\nLes Courses Service Journey – Modèle conceptuel\nUne COURSE (SERVICE JOURNEY) est le mouvement défini d\u0026rsquo;un véhicule utilisant un PARCOURS (JOURNEY PATTERN) spécifiée. Elle défini pour un TYPE DE JOUR donné.\nLe profil ne concerne que les COURSEs dans lequel les passagers seront autorisés à monter à bord ou à descendre du véhicule aux arrêts.\nServiceJourney – Element     Classifi­cation Name Type Cardin­ality Description  :: :: Journey :: SERVICE JOURNEY hérite de JOURNEYet intègre un certain nombre d'éléments de VEHICLE JOURNEY   ServiceAlteration ServiceAlterationEnumeration 0:1 Indique si la course est planifiée (valeur par défaut), si elle est annulée ou si c’est une course additionnelle.\nCe champ n’est à utiliser que pour les mises à jour tardives dans les cas où cette information n’est pas diffusée avec SIRI (service Producion Timetable)\n   DepartureTime xsd:time 0:1 Heure de départ de la COURSE   DepartureDayOffset DayOffsetType 0:1 Décalage de jour si le jour de départ du VEHICLE JOURNEY est différent de l’OPERATING DAY courant (typiquement -1 pour « la veille »)..  «cntd» Frequency   L'information de fréquence est fournie par la COURSE MODÈLE (voir frequencyGroupsde TemplateVehicleJourney)   JourneyDuration xsd:duration 0:1 Durée totale de la course.  «FK» DayTypeRef DayTypeRef 1:* TYPE DE JOUR correspondant aux jours d'application de la course.  «FK» RouteRef   Voir le PARCOURS  «FK» JourneyPattern­Ref JourneyPatternRef 0:1 PARCOURS suivi par la COURSE  «FK» VehicleTypeRef VehicleTypeRef 0:1 TYPE DE VEHICULE utilisé pour la course.   choice OperatorRef OperatorRef 0:1 Référence l'EXPLOITANT opérant cette course.\nIl n'est indiqué que s’il est différent de celui de la ligne.\n  «EV» choice LineRef LineRef 0:1 Référence la LIGNE à laquelle appartient la COURSE (pour simplifier la navigation COURSE-PARCOURS-ITINERAIRE-LIGNE). Il peut naturellement s'agir d'une LIGNE FLEXIBLE.    FlexibleLineView FlexibleLineView 0:1 Permet de décrire les éléments de flexibilité (typiquement TAD - Transport à la Demande) spécifiques à cette course   trainNumbers trainNumberRefs 0:* Référence le numéro de train associé.\nNote: le NUMERO DE TRAIN est un objet indépendant, qui est ici référencé.\n  «cntd» Origin   Voir le PARCOURS.  «cntd» Destination   Voir le PARCOURS.  «cntd» passingTimes TimetabledPassingTime 0:* Heures de passages planifiées aux arrêts (scheduledStopPoint).  «cntd» passengerAtStopTimes passengerAtStopTimes_RelStructure 0:* Heures auxquelles les passagers doivent être présents avant le départ   parts journeyParts 0:* Références à des parties de COURSE (JOURNEY PART) constituant la COURSE.\nUtilisé pour un certain nombre de situations du mode ferré (changement de parité ou de numéro de train) ainsi que pour des situations comme le changement d'exploitant en cours de course sur les RER A et B.\nContrairement à la règle générale dans les profils NeTEx, et afin de pouvoir être réutilisées, les JOURNEY PARTs seront systématiquement définies indépendamment (à la racine de l'élément membersdu FRAME) et simplement référencées ici (et non incluse, même si le modèle l'autorise).\n   calls calls_RelStructure 0:* La notion de Call est une vue agrégée de différentes propriétés lors d'un évènement (souvent le passage à un arrêt)\nCette notion est héritée de SIRI et ne correspond pas à la modélisation des passages aux arrêts. La notion de Call n'est donc pas retenue dans le profil France.\n   facilities serviceFacilitySets_RelStructure 0:* Services disponibles pour cette course (voir la partie accessibilité du profil pour plus de détails).   TrainSize TrainSizeStructure 0:1 Information sur la taille du train (long/court). Peut aussi servir pour identifier les bus articulés ou couplés.   FlexibleServiceProperties FlexibleServiceProperties 0:1 Information de flexibilité de la COURSE.\nLes informations de flexibilité sont fournies ici que si elles ne sont pas globales pour la LIGNE.\n    Pour TrainSize voir 6.10.1-Train.\nJourney – Element (abstrait)     Classifi­cation Name Type Cardin­ality Description  :: :: LinkSequence :: JOURNEY hérite de LINK SEQUENCE (voir le document Profil NeTEx éléments communs).   Description MultilingualString 0:1 Descriptionde JOURNEY.   TransportMode VehicleModeEnum 0:1 Transport MODE de JOURNEY.\nLe mode n'est précisé que s'il est différent de celui de la ligne (exemple: bus de substitution SNCF).\n   TransportSubmode TransportSubmode 0:1 SOUS MODE de transport de JOURNEY.\nLe sous-mode n'est précisé que s'il est différent de celui de la ligne.\n   Monitored   Fourni au niveau LIGNE.  «cntd» journeyAccountings   Le profil étant dédié à l'information voyageur, les notions de comptabilité ne sont pas prises en compte, mais pourraient être nécessaires dans d'autres contextes.   noticeAssignments noticeAssignments 0:* NOTEs associées à la COURSE.    Les heures de passage Vehicle Journey, Passing Times et Interchanges – Modèle conceptuel\nPassingTime – Element (objet inclus)    Classifi­cation Name Type Cardin­ality Description     ::\u0026gt; ::\u0026gt; VersionedChild ::\u0026gt; PASSING TIME hérite de VERSIONED CHILD (non utilisé dans le profil)   «FK» PointInJourney­PatternRef PointInLinkSequenceRef 0:1 Référence les POINT D\u0026rsquo;ARRÊT PLANIFIÉ pour lequel on fournit les heures de passage. Ce point peut aussi, de façon plus exceptionnel être un POINT HORAIRE uniquement.    ArrivalTime xsd:time 0:1 Heure d\u0026rsquo;arrivée.    ArrivalDayOffset xsd:integer 0:1 Nombre de jours de décalage par rapport au jour de début de course (permet de gérer les courses à cheval sur plusieurs jours).    DepartureTime xsd:time 0:1 Heure de départ.    DepartureDayOffset xsd:integer 0:1 Nombre de jours de décalage par rapport au jour de début de course (permet de gérer les courses à cheval sur plusieurs jours).    Headway HeadwayInterval 0:1 Temps d\u0026rsquo;attente moyen avant le prochain passage d\u0026rsquo;une COURSE empruntant le même PARCOURS.    EarliestDeparture­Time xsd:time 0:1 Heure de départ au plus tôt (il s\u0026rsquo;agit là de l\u0026rsquo;engagement de service du transporteur ou de l\u0026rsquo;AOT; il permettra notamment de sécuriser les correspondances; il permet aussi d\u0026rsquo;indiquer la précision de l\u0026rsquo;heure de passage, en particuliers aux points ou l\u0026rsquo;horaire est interpolé).    LatestArrivalTime xsd:time 0:1 Heure de d\u0026rsquo;arrivée au plus tard (il s\u0026rsquo;agit là de l\u0026rsquo;engagement de service du transporteur ou de l\u0026rsquo;AOT; il permettra notamment de sécuriser les correspondances; il permet aussi d\u0026rsquo;indiquer la précision de l\u0026rsquo;heure de passage, en particuliers aux points ou l\u0026rsquo;horaire est interpolé).    Note: pour les courses en fréquence, les nécessaires temps de parcours (pour le calcul d\u0026rsquo;itinéraire) seront calculés à partir des heures de passage de la COURSE MODÈLE (la fourniture explicite des temps de parcours, ou RUN TIME, nécessite la définition des TIMING LINKs, alourdissant sensiblement l\u0026rsquo;échange sans pour autant véritablement apporter une information supplémentaire dans un contexte d\u0026rsquo;information voyageur). Le calcul du temps de parcours sera réalisé par simple différence des heures de départs (DepartureTime) aux différents arrêts.\nPropriétés de course flexible FlexibleServiceProperties – Element (objet inclus)     Classification Name Type cardinality Description  :: :: DataManagedObject :: FLEXIBLE SERVICE PROPERTIES hérite de DATA MANAGED OBJECT (voir le document Profil NeTEx éléments communs).\nNon utilisé ici.\n  «cntd» Booking­Arrangements BookingArrangements 0:1 Informations de contact pour les services flexibles (voir le document Profil NeTEx réseau).   FlexibleService­Type FlexibleServiceTypeEnum 0:1 Type de flexibilité mise en œuvre sur la course\n dynamicPassingTimes: heure de passage fixée dynamiquement (en fonction de la demande)\n fixedHeadwayFrequency: fréquence de passage fixe (par exemple toute les 30 minutes) mais maintenue uniquement s'il y a une demande (réservation)\n fixedPassingTimes: heures de passage aux arrêts fixes (planifiées) mais maintenue uniquement s'il y a une demande (réservation)\n notFlexible: service régulier\n other: autre type de flexibilité (associer une NOTE à la course)\n    Cancellation­Possible xsd:boolean 0:1 Indique si une annulation du service est possible (même après une réservation).   ChangeOfTime­Possible xsd:boolean 0:1 Indique que l'horaire peut être modifié (même après une réservation).    Groupes de courses Un groupement de COURSEs, est particulièrement utile pour organiser des séries de voyages similaires à présenter sous forme de tableau ou dans les systèmes d’information voyageur, par exemple «Tous les services au départ pour la ligne 2 en semaine».\nGroupOfServices – Element     Classification Name Type Cardinality Description  :: :: GroupOfEntities :: GROUP OF SERVICES hérite de GROUP OF ENTITIES.  «PK» id GroupOfServicesIdType 1:1 Identifiant du GROUP OF SERVICEs.   origin EndPoint_DerivedView  Origine des courses du groupe\nPar exemple : ScheduledStopPointRef, Name, StopType, etc   destination EndPoint_DerivedView  Destination des courses du groupe\nPar exemple : ScheduledStopPointRef, Name, StopType, etc  «cntd» destinationDisplays DestinationDisplay 0:* DESTINATION DISPLAYs associés au groupe  «cntd» members VehicleJourneyRef 0:* COURSEs faisant partie du GROUP OF SERVICEs.  «cntd» noticeAssignments NoticeAssignmentView 0:* Note associée au GROUP OF SERVICEs.    Les parties de course Journey Parts et Trains – Modèle conceptuel\nLes PARTIEs DE COURSE seront généralement spécifiques au mode ferré.\nJourneyPart – Element (objet inclus)    Classification Name Type cardinality Description     ::\u0026gt; ::\u0026gt; DataManagedObject ::\u0026gt; JOURNEY PART hérite de DATA MANAGED OBJECT (voir le document Profil NeTEx éléments communs).    Description MultilingualString 0:1 Description de la PARTIE DE COURSE.   «FK» ParentJourneyRef VehicleJourneyRef 0:1 COURSE à laquelle appartient cette PARTIE DE COURSE.   «FK» MainPartRef JourneyPartCoupleRef 1:1 Référence à la PARTIE DE COURSE principale (l\u0026rsquo;une des différentes PARTIE DE COURSE doit être déclarée comme principale).   «FK» JourneyPart­CoupleRef JourneyPartCoupleRef 0:1 Référence à l\u0026rsquo;éventuelle COURSE COUPLÉE à laquelle la PARTIE DE COURSE appartient.   «FK» TrainNumberRef TrainNumberRef 0:1 Référence au NUMÉRO DE TRAIN de la PARTIE DE COURSE.   «FK» FromStopPointRef ScheduledStopPointRef 0:1 Arrêt de départ de la PARTIE DE COURSE.   «FK» ToStopPointRef ScheduledStopPointRef 0:1 Arrêt de fin de la PARTIE DE COURSE.    StartTime xsd:time 1:1 Arrêt de départ de la PARTIE DE COURSE (à l\u0026rsquo;arrêt de départ).    StartTimeDayOffset DayOffsetType 0:1 Nombre de jours de décalage par rapport au jour de départ de la COURSE.    EndTime xsd:time 1:1 Arrêt de fin de la PARTIE DE COURSE (à l\u0026rsquo;arrêt de fin).    EndTimeDayOffset DayOffsetType 0:1 Nombre de jours de décalage par rapport au jour de départ de la COURSE.   «cntd» facilities ServiceFacilitySet 0:* Service spécifique à cette PARTIE DE COURSE.   «cntd» journeyPartPositions JourneyPartPosition 0:* Positions dans la séquence de PARTIE DE COURSE.    JOURNEY PART POSITION décrit la position relative dans le train d\u0026rsquo;un JOURNEY PART à partir d\u0026rsquo;un arrêt donné. Cela peut changer en cours de route car les composants du train sont couplés et découplés.\nJourneyPartPosition – Element (objet inclus)    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; VersionedChild ::\u0026gt; JOURNEY PART POSITION hérite de VERSIONED CHILD.   «PK» id JourneyPartPosition­IdType 1:1 Identifiant de JOURNEY PART POSITION.          «FK» ScheduledStopPoint­Ref ScheduledStopPointRef 0:1 SCHEDULED STOP POINT pour lequel cette position est valide.    PositionInTrain xsd:integer 0:* Position du JOURNEY PART à partir du SCHEDULED STOP POINT.    Numéro de train TrainNumber – Element (objet inclus)     Classifi­cation Name Type Cardin­ality Description  :: :: DataManagedObject :: TRAIN NUMBER hérite de DATA MANAGED OBJECT (voir le document Profil NeTEx éléments communs).\nLe champ Id est naturellement l'identifiant du NUMÉRO DE TRAIN (c'est le numéro de train lui-même).\n   Description MultilingualString 0:1 Texte descriptif associé au NUMÉRO DE TRAIN et à utiliser pour l'information voyageur (devra figurer en complément du numéro de train).   ForAdvertisement xsd:normalizedString 0:1 NUMÉRO DE TRAIN utilisé pour la communication au public (parfois différent du numéro technique: si ce champ est présent il sera systématiquement utilisé pour l'information voyageur).    Les courses en fréquence Course modèle Les courses modèles sont des courses de référence utilisées pour décrire les services en fréquence (on ne décrit alors qu\u0026rsquo;une course qui sera répétée à intervalle régulier) ou en cadences (on décrit alors toutes les courses passant dans un créneau d\u0026rsquo;une heure).\nTemplate Service Journey – Modèle conceptuel\nPour les courses en fréquence le calcul du temps de parcours sera réalisé par simple différence des heures de départs (DepartureTime) aux différents arrêts de la course modèle. Par convention, la course modèle pour les services en fréquence sera, en termes d\u0026rsquo;horaire de passage, la première course de la tranche horaire décrite (avec généralement un calage au premier arrêt sur l\u0026rsquo;heure de début de la tranche horaire).\nPour les courses en cadence on prendra comme convention de n\u0026rsquo;indiquer que les minutes des horaires de passage (l\u0026rsquo;heure sera donc fixe, à 0, un arrêt desservi toutes les heures dix, vingt-cinq et cinquante, aura donc des horaire 0:10, 0:25 et 0:50). Il ne s\u0026rsquo;agit là que d\u0026rsquo;une convention, dans tous les cas, la partie heure de l\u0026rsquo;horaire de passage peut être ignorée dans le cadre des cadences.\nTemplateVehicleJourney – Element     Classifi­cation Name Type Cardin­ality Description  :: :: ServiceJourney :: TEMPLATE SERVICE JOURNEY hérite de SERVICE JOURNEY.   TemplateVehicle­JourneyType TemplateVehicle­JourneyTypeEnum 0:1 Type de COURSE MODÈLE (avec voyageur). Ce type est codifié de la façon suivante:\n Headway : course en fréquence\n   Rhythmic : course cadencée\n  «cntd» frequencyGroups JourneyFrequencyGroup 0:* Référence à la description du service en fréquence ou en cadence que la COURSE MODÈLE décrit.\nSeules les références xxxxRef(HeadwayJourneyGroupRefpour les services en fréquence ou RhythmicalJourneyGroupRefpour les services en cadence) seront utilisées dans le cadre du profil.\n    Course en fréquence HeadwayJourneyGroup – Element    Classifi­cation Name Type Cardin­ality Description     ::\u0026gt; ::\u0026gt; JourneyFrequencyGroup ::\u0026gt; HEADWAY JOURNEY GROUP hérite de JOURNEY FREQUENCY GROUP.    Scheduled­HeadwayInterval xsd:duration 0:1 INTERVAL DE PASSAGE planifié (temps prévu entre deux passages de véhicule).    Description MultilingualString 0:1 Description du service en fréquence    JourneyFrequencyGroup – Element (abstrait)     Classifi­cation Name Type Cardin­ality Description  :: :: GroupOfEntities :: JOURNEY FREQUENCY GROUP hérite de GROUP OF ENTITies (voir le document Profil NeTEx éléments communs).   FirstDeparture­Time xsd:time 1:1 Heure du premier départ dans le GROUPE DE FRÉQUENCE.\nIl s'agit là de l'heure de passage du premier départ au premier arrêt de la course.\nS'il n'y a pas de régulation des heures de premier départ dans les tranches horaires, on indiquera uniquement l'heure de début de tranche horaire (pour un bus toute les 10 minutes de 8h00 à 9h30 on indiquera donc 8h00 même s'il n'y a pas de garantie d'un départ à 8h00).\n   LastDeparture­Time xsd:time 0:1 Heure du dernier départ dans le GROUPE DE FRÉQUENCE.\nIl s'agit là de l'heure de passage du dernier départ au premier arrêt de la course.\nS'il n'y a pas de régulation des heures de dernier départ dans les tranches horaires, on indiquera uniquement l'heure de fin de tranche horaire (pour un bus toute les 10 minutes de 8h00 à 9h30 on indiquera donc 9h30 même s'il n'y a pas de garantie d'un départ à 9h30).\n   DayOffset xsd:integer 0:1 Éventuel décalage de jour pour l'heure de dernier départ (si la plage horaire est à cheval sur plusieurs jours).  «cntd» journeys VehicleJourneyRef 0:* Liste des courses constituant ce GROUPE DE FRÉQUENCE. Cette relation permet d'avoir en même temps une description globale du service en fréquence complété par la liste de toutes les courses (et horaires associées) qui vont effectivement réaliser ce service.\nSeul le ServiceJourneyRef est utilisé par le profil.\n    Course en cadence RhythmicalJourneyGroup – Element    Classifi­cation Name Type Cardin­ality Description     ::\u0026gt; ::\u0026gt; JourneyFrequencyGroup ::\u0026gt; RHYTHMICAL JOURNEY GROUP hérite de JOURNEY FREQUENCY GROUP.   «cntd» timebands   On utilisera uniquement les COURSEs MODÈLEs pour décrire les services en cadencement.    Les Courses couplées Courses coupléed – Modèle conceptuel\nCoupledJourney – Element    Classifi­cation Name Type Cardin­ality Description     ::\u0026gt; ::\u0026gt; DataManagedObject ::\u0026gt; COUPLED JOURNEY hérite de DATA MANAGED OBJECT (voir le document Profil NeTEx éléments communs).    Description MultilingualString 0:1 Description de la COURSE COUPLÉE (texte utilisable pour l\u0026rsquo;information voyageur).   «cntd» journeys VehicleJourney 0:* Référence vers les COURSEs qui sont associées ensemble.    Parties de courses couplées JourneyPartCouple – Element     Classifi­cation Name Type Cardin­ality Description  :: :: DataManagedObject :: JOURNEY PART COUPLE hérite de DATA MANAGED OBJECT (voir le document Profil NeTEx éléments communs).   Description MultilingualString 0:1 Description of JOURNEY PART COUPLE.   StartTime xsd:time 1:1 Heure de début du couplage (heure de départ au point de départ)   StartTimeDayOffset DayOffsetType 0:1 Nombre de jours de décalage par rapport au jour de départ de la COURSE.   EndTime xsd:time 1:1 Heure de fin du couplage.\nIl s'agit de l'heure d'arrivée au point de d'arrivé, ou à défaut de l'heure de premier départ du point d'arrivée (première des courses couplées à quitter le point d'arrivée).\n   EndTimeDayOffset DayOffsetType 0:1 Nombre de jours de décalage par rapport au jour de départ de la COURSE.  «FK» FromPointRef ScheduledStopPointRef 1:1 POINT D'ARRÊT PLANIFIÉ où débute le couplage.  «FK» ToPointRef ScheduledStopPointRef 1:1 POINT D'ARRÊT PLANIFIÉ où se termine le couplage.  «FK» MainPartRef JourneyPartRef 1:1 PARTIE DE COURSE principale (à référencer pour l'information voyageur en particulier).  «cntd» joinedParts JourneyPartRef 0:* PARTIEs DE COURSEs jointes à la PARTIE DE COURSE principale.  «FK» TrainNumberRef TrainNumberRef 0:1 Numéro de train associé à la partie de courses couplées.    Les correspondances entre course ServiceJourneyInterchange – Element    Classifi­cation Name Type Cardin­ality Description     ::\u0026gt; ::\u0026gt; Interchange ::\u0026gt; SERVICE JOURNEY INTERCHANGE hérite de INTERCHANGE.   «FK» FromPointRef ScheduledStopPointRef 1:1 POINT D\u0026rsquo;ARRÊT planifié au départ de la correspondance.    FromVisitNumber   On utilisera les horaires de passage et de correspondance pour distinguer deux passages au même point d\u0026rsquo;arrêt, si nécessaire.   «FK» ToPointRef ScheduledStopPointRef 1:1 POINT D\u0026rsquo;ARRÊT planifié auquel donne accès la correspondance.    ToVisitNumber   On utilisera les horaires de passage et de correspondance pour distinguer deux passages au même point d\u0026rsquo;arrêt, si nécessaire.   «FK» FromJourneyRef ServiceJourneyRef 1:1 COURSE de départ.   «FK» ToJourneyRef ServiceJourneyRef 1:1 COURSE à laquelle donne accès la correspondance.    Interchange – Element (abstrait)     Classifi­cation Name Type Cardin­ality Description  :: :: DataManagedObject :: INTERCHANGE hérite de DATA MANAGED OBJECT (voir le document Profil NeTEx éléments communs).  «FK» ConnectionRef ConnectionRef 0:1 Lien avec la CORRESPONDANCE physique sur laquelle s'opère la CORRESPONDANCE ENTRE COURSEs (voir le document Profil NeTEx Réseau).   StaySeated xsd:boolean 0:1 Permet d'indiquer que la course en correspondance est assurée par le même véhicule que la course amenante et que le passager peut simplement rester dans le véhicule et n'a donc pas besoin de descendre.\nCela sera utile pour les lignes en boucle par exemple, ou encore si l'on décide de modéliser un changement d'exploitant par des courses distinctes (cas des RER A et B en région parisienne par exemple).\n   CrossBorder xsd:boolean 0:1 Indique que l’INTERCHANGE implique le franchissement d’une frontière nationale.  «cntd» Interchange­TimesGroup InterchangeTimesGroup 0:* Information horaire de la correspondance.  «cntd» notice­Assignments NoticeAssignmentView 0:* NOTE associé à la correspondance (voir le document Profil NeTEx éléments communs).    InterchangeTimesGroup – Element (objet inclus)    Classifi­cation Name Type Cardin­ality Description   StandardTransferTime xsd:duration 0:1\n1:1\n Temps de correspondance moyen (entre l'arrivée de l'amenant et le départ du partant)\nObligatoire dans le cadre du profil.\nVoir la CORRESPONDANCE physique pour les détails de temps de parcours de la correspondance (temps de marche, etc.) (voir le document Profil NeTEx Réseau).\n    Position d\u0026rsquo;arrêt pour une course Cette information complète l'Affectation de train à quai (voir le document Profil NeTEx Réseau)dans le cas où l\u0026rsquo;identification des voitures est variable d\u0026rsquo;une course à l\u0026rsquo;autre.\nTrainComponentLabelAssignment – Element    Classifi­cation Name Type Cardin­ality Description     ::\u0026gt; ::\u0026gt; DataManagedObject ::\u0026gt; TRAIN COMPONENT LABEL ASSIGNMENT hérite de DATA MANAGED OBJECT (voir le document Profil NeTEx éléments communs).    Name MultilingualString 0:1 Nom associé au COMPOSANT DE TRAIN (voiture) pour la course (il s\u0026rsquo;agit du nom de la voiture tel qu\u0026rsquo;il figurera sur le billet du voyageur).   «AK» VehicleJourneyRef VehicleJourneyRef 0:1 Référence de la course concernée.   «FK» TrainComponentRef TrainComponentRef 0:1 Référence du COMPOSANT DE TRAIN (voiture) concernée.    Type de véhicule Type de Vehicule et Trains – Modèle Conceptuel\nVehicleType – Element     Classifi­cation Name Type Cardin­ality Description  :: :: DataManagedObject :: VEHICLE TYPE hérite de DATA MANAGED OBJECT (voir le document Profil NeTEx éléments communs).   Name MultilingualString 0:1 Nom du TYPE DE VEHICULE.   Description MultilingualString 0:1 Description du TYPE DE VEHICULE.   SelfPropelled boolean 0:1 Indique si le TYPE DE VEHICULE est autonome, ou s'il nécessite une motrice ou un véhicule tracteur.   TypeOfFuel TypeOfFuelEnum 0:1 Type de carburant du TYPE DE VEHICULE:\n battery : batterie\n biodiesel : biogazole ou diesel bio\n diesel: diesel\n dieselBatteryHybrid : hybride diesel et batterie\n electricContact : contact électrique\n electricity : électrique\n ethanol : éthanol\n hydrogen : hydrogène\n liquidGas : gaz liquide\n tpg (thermochemical power group) : group thermochimique\n methane : méthane\n naturalGas : gaz\n petrol : essence\n petrolBatteryHybrid : hybride essence et batterie\n petrolLeaded : essence au plomb\n petrolUnleaded : essence sans plomb\n none : aucun\n other : autre\n    EuroClass xsd:normalizedString 0:1 Euroclasse du TYPE DE VEHICULE (normes européennes d'émission: http://fr.wikipedia.org/wiki/Normes_europ%C3%A9ennes_d%27%C3%A9mission).   capacities PassengerCapacity 0:* Capacité en passager (par classe tarifaire).\nOn utilisera directement les PassengerCapacity(et non les références) dont on n'utilisera pas les champs issu de l'héritage DATA MANAGED OBJECT.\n   LowFloor xsd:boolean 0:1 Indique un plancher bas (pour l'accessibilité).   HasLiftOrRamp xsd:boolean 0:1 Indique que le TYPE DE VEHICULE est équipé d'une rampe ou d'une palette pour l'accès PMR   HasHoist xsd:boolean 0:1 Indique que le TYPE DE VEHICULE est équipé d'un monte-charge pour l'accès PMR   Length LengthType 0:1 Longueur du TYPE DE VEHICULE.   Width LengthType 0:1 Largeur du TYPE DE VEHICULE.   Height LengthType 0:1 Hauteur du TYPE DE VEHICULE.   Weight WeightType 0:1 Poids du TYPE DE VEHICULE.  «FK» ClassifiedAsRef   On utilise le champ Brand de l'héritage DATA MANAGED OBJECT pour éventuellement indiquer la marque et/ou le modèle du véhicule.    PassengerCapacity – Element (objet inclus)     Classifi­cation Name Type Cardin­ality Description  :: :: DataManagedObject :: PASSENGER CAPACITY hérite de DATA MANAGED OBJECT (voir le document Profil NeTEx éléments communs)\nChamps non utilisés dans le cadre du profil.\n   FareClass FareClassEnum 0:1 Classe pour laquelle on indique la CAPACITÉ EN PASSAGERS:\n firstClass (première classe)\n secondClass (seconde classe)\n premiumClass (classe pemium)\n businessClass\n standardClass (classe normale)\n economyClass (classe économique)\n any (toutes)\n    TotalCapacity NumberOfPassengers 0:1 Capacité totale.   SeatingCapacity NumberOfPassengers 0:1 Nombre de places assises.   StandingCapacity NumberOf­Passengers 0:1 Nombre de places debout.   WheelchairPlace­Capacity NumberOf­Passengers 0:1 Nombre de places PMR    Train Train – Element     Classifi­cation Name Type Cardin­ality Description  :: :: VehicleType :: TRAIN hérite de VEHICLE TYPE   TrainSize TrainSizeStructure 0:1 Taille du train.  «cntd» components TrainComponent 0:* Ensemble des composants du train.\nOn utilisera directement les TrainComponent(et non les références) dont on n'utilisera pas les champs issus de l'héritage de DATA MANAGED OBJECT (à l'exception de l'identifiant, indispensable si l'on souhaite préciser les alignements de voiture sur les quais).\n    TrainSize – Structure (objet inclus)     Classifi­cation Name Type Cardin­ality Description   NumberOfCars xsd:nonNegativeInteger 0:1 Nombre de voitures (voiture ou éventuellement bus couplé; par convention on indiquera 2 pour un véhicule articulé à 2 éléments).   TrainSizeType TrainSizeEnumeration 0:1 Type de taille du véhicule\n Normal\n Short\n Long\n     TrainComponent – Element     Classifi­cation Name Type Cardin­ality Description  :: :: VersionedChild :: TRAIN COMPONENT hérite de VERSIONED CHILD (voir le document Profil NeTEx éléments communs).   Label MultilingualString 0:1 Label du COMPOSANT DE TRAIN (s'il est fixe, on utilisera TrainComponentLabelAssignment sinon).   Description MultilingualString 0:1 Description du COMPOSANT DE TRAIN.  «FK» TrainRef   Non utilisé car implicite du fait de l'imbrication XML, dans le contexte du profil.   b TrainElement TrainElement 1:1 ELEMENT DE TRAIN associé au COMPOSANT DE TRAIN.\nOn utilisera directement les TrainElement(et non les références) dont on n'utilisera pas les champs issus de l'héritage DATA MANAGED OBJECT.\n    TrainElement – Element     Classifi­cation Name Type Cardin­ality Description  :: :: DataManagedObject :: TRAIN ELEMENT hérite de DATA MANAGED OBJECT (voir le document Profil NeTEx éléments communs).\nChamps non utilisés dans le cadre du profil.\n   Name MultilingualString 0:1 Nom du TRAIN ELEMENT.   Description MultilingualString 0:1 Description du TRAIN ELEMENT.  «FK» TrainElement­Type TypeOfTrainElementEnum 1:1 Classification de l'ÉLÉMENT DE TRAIN:\n buffetCar : voiture bar\n carriage : voiture passager\n engine : motrice\n carTransporter : transport de véhicule\n sleeperCarriage : voiture couchette\n luggageVan : voiture/compartiment à bagage\n restaurantCarriage: voiture restaurant\n other: autre\n    FareClasses FareClassEnum 0:* Classe associé à l'ÉLÉMENT DE TRAIN:\n firstClass (première classe)\n secondClass (seconde classe)\n premiumClass (classe pemium)\n businessClass\n standardClass (classe normale)\n economyClass (classe économique)\n any (toutes)\n     Train composé CompoundTrain – Element    Classifi­cation Name Type Cardin­ality Description     ::\u0026gt; ::\u0026gt; VehicleType ::\u0026gt; COMPOUND TRAIN hérite de VEHICLE TYPE    components TRainInCompoundTrain 1:* Références aux TRAINs constituant le TRAIN composé. C\u0026rsquo;est une liste ordonnée (en commençant par la tête de train dans le sens de la marche).    Entêtes NeTEx Note: les entêtes NeTEx sont présentés dans le document éléments communs. Seules les spécificités de la partie \u0026ldquo;horaires\u0026rdquo; sont présentées ici.\nPour rappel, la liste des fichiers d\u0026rsquo;un export NeTEx profil France est décrite dans Éléments Communs.\nUne GeneralFrame de type NETEX_HORAIRE est utilisée pour échanger la description des horaires d\u0026rsquo;une ligne dans le fichier \u0026ldquo;line_xyz.xml\u0026rdquo;.\nTypeOfFrame : type spécifique NETEX_HORAIRE Lorsqu\u0026rsquo;une FRAME a pour TypeOfFrame la valeur NETEX_HORAIRES, seuls les objets de premier niveau suivants sont autorisés :\n SERVICE JOURNEY SERVICE LINK FLEXIBLE SERVICE PROPERTIES TEMPLATE SERVICE JOURNEY HEADWAY JOURNEY GROUP RHYTHMICAL JOURNEY GROUP COUPLED JOURNEY JOURNEY PART COUPLE JOURNEY PART TRAIN TRAIN COMPONENT COMPOUND TRAIN TRAIN NUMBER TRAIN COMPONENT LABEL ASSIGNMENT  Voici un exemple de cadre du fichier line_xyz.xml :\n\u0026lt;?xml version=\u0026#34;1.0\u0026#34; encoding=\u0026#34;utf-8\u0026#34;?\u0026gt; \u0026lt;PublicationDelivery xmlns=\u0026#34;http://www.netex.org.uk/netex\u0026#34; version=\u0026#34;2.0:FR-NETEX-2.4\u0026#34;\u0026gt; \u0026lt;PublicationTimestamp\u0026gt;2023-01-01T00:00:00.0Z\u0026lt;/PublicationTimestamp\u0026gt; \u0026lt;ParticipantRef\u0026gt;Exemple\u0026lt;/ParticipantRef\u0026gt; \u0026lt;dataObjects\u0026gt; \u0026lt;CompositeFrame id=\u0026#34;FR:CompositeFrame:NETEX_LIGNE-line_xyz:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;TypeOfFrameRef ref=\u0026#34;FR:TypeOfFrame:NETEX_LIGNE:\u0026#34; /\u0026gt; \u0026lt;frames\u0026gt; \u0026lt;GeneralFrame id=\u0026#34;FR:GeneralFrame:NETEX_RESEAU-line_xyz:LOC\u0026#34; version=\u0026#34;2.0:FR-NETEX-2.4\u0026#34;\u0026gt; \u0026lt;TypeOfFrameRef ref=\u0026#34;FR:TypeOfFrame:NETEX_LIGNE_STRUCTURE:\u0026#34; /\u0026gt; \u0026lt;members\u0026gt; \u0026lt;Line id=\u0026#34;sample\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Ligne d\u0026#39;exemple\u0026lt;/Name\u0026gt; \u0026lt;/Line\u0026gt; \u0026lt;!-- Partie Ligne Peut contenir (chaque objet contiendra ses objets sous-jacents, les éléments listés ici pourront être référencés dans les autres objets) LINE DIRECTION ROUTE ROUTE POINT POINT ON ROUTE ROUTE LINK FLEXIBLE LINE FLEXIBLE ROUTE --\u0026gt; \u0026lt;!-- Partie Reseau DESTINATION DISPLAY FLEXIBLE POINT PROPERTIES FLEXIBLE LINK PROPERTIES SERVICE JOURNEY PATTERN POINT IN JOURNEY PATTERN SCHEDULED STOP POINT TIMING POINT TRANSFER RESTRICTION PASSENGER STOP ASSIGNMENT FLEXIBLE STOP ASSIGNMENT TRAIN STOP ASSIGNMENT SCHEMATIC MAP --\u0026gt; \u0026lt;/members\u0026gt; \u0026lt;/GeneralFrame\u0026gt; \u0026lt;GeneralFrame id=\u0026#34;FR:GeneralFrame:NETEX_HORAIRE-line_xyz:LOC\u0026#34; version=\u0026#34;2.0:FR-NETEX-2.4\u0026#34;\u0026gt; \u0026lt;TypeOfFrameRef ref=\u0026#34;FR:TypeOfFrame:NETEX_HORAIRE:\u0026#34; /\u0026gt; \u0026lt;members\u0026gt; \u0026lt;!-- Peut contenir SERVICE JOURNEY SERVICE LINK FLEXIBLE SERVICE PROPERTIES TEMPLATE SERVICE JOURNEY HEADWAY JOURNEY GROUP RHYTHMICAL JOURNEY GROUP COUPLED JOURNEY JOURNEY PART COUPLE JOURNEY PART TRAIN TRAIN COMPONENT COMPOUND TRAIN TRAIN NUMBER TRAIN COMPONENT LABEL ASSIGNMENT --\u0026gt; \u0026lt;/members\u0026gt; \u0026lt;/GeneralFrame\u0026gt; \u0026lt;/dataObjects\u0026gt; \u0026lt;/PublicationDelivery\u0026gt; Bibliographie\nEN 15531-1, Public transport - Service interface for real-time information relating to public transport operations - Part 1: Context and framework\nEN 15531-2, Public transport - Service interface for real-time information relating to public transport operations - Part 2: Communications infrastructure3\nEN 15531-3, Public transport - Service interface for real-time information relating to public transport operations - Part 3: Functional service interfaces4\nCEN/TS 15531-4, Public transport - Service interface for real-time information relating to public transport operations - Part 4: Functional service interfaces: Facility Monitoring\nCEN/TS 15531-5, Public transport - Service interface for real-time information relating to public transport operations - Part 5: Functional service interfaces - Situation Exchange\n","permalink":"https://deploy-preview-56--transport-normes.netlify.app/normes/netex/horaires/","summary":"Avant-propos\nL’harmonisation des pratiques dans l’échange des données relatives aux offres de transport est essentielle :\n  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) ;\n  pour les AOT, 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.","title":"NeTEx - Profil France v2.4 - Horaires"},{"content":"Avant-propos\nL’harmonisation des pratiques dans l’échange des données relatives aux offres de transport est essentielle :\n  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) ;\n  pour les AOT, de manière à fédérer des informations homogènes venant de chacun des opérateurs de transports qui travaillent pour elles. L’harmonisation des échanges, et en particulier le présent profil, pourra le cas échéant être imposée 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 ;\n  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) ;\n  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.\n  Ce document est le fruit de la collaboration entre les différents partenaires des autorités organisatrices de transports, opérateurs, industriels, développeurs de solutions et de systèmes informatiques, et associations d\u0026rsquo;usagers ayant pour objet l’aide à l’exploitation du transport public et l’information des voyageurs. Il a pour objet de présenter le profil d’échange Profil NeTEx Accessibilité: \u0026ldquo;format de référence pour l\u0026rsquo;échange de données de description de l\u0026rsquo;accessibilité des réseaux de transport en commun\u0026rdquo; (issu des travaux NeTEx et Transmodel) qui aujourd’hui fait consensus dans les groupes de normalisation (CN03/GT7 – Transport public / information voyageur).\nCe document a été validé et publié comme suit :\n travaux de révision : 2024-2025 date de validation en CN03 : 19 décembre 2025 date de publication : 6 mars 2026  Introduction\nLe présent document fait partie du profil France de NeTEx.\nNeTEx (CEN/TS 16614 series) propose un format et des services d\u0026rsquo;échange de données de description de l\u0026rsquo;offre de transport planifiée, basé sur Transmodel (EN 12896 series) et l’ancienne norme IFOPT (EN 28701). NeTEx permet non seulement d\u0026rsquo;assurer les échanges pour les systèmes d\u0026rsquo;information voyageur mais traite aussi l’ensemble des concepts nécessaires en entrée et sortie des systèmes de planification de l\u0026rsquo;offre (graphiquage, etc.) et des SAE (Systèmes d’Aide à l’Exploitation).\nNeTEx se décompose en six parties:\n  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)\n  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)\n  Partie 3 : information tarifaire (uniquement à vocation d’information voyageur)\n  Partie 4 : profil européen pour l\u0026rsquo;information voyageur (EPIP)\n  Partie 5 : nouveaux modes (les véhicules partagés en libre service, les courses partagées, etc.)\n  Partie 6 : profil européen pour l\u0026rsquo;information voyageur en lien avec l\u0026rsquo;accessibilité (EPIAP)\n  NeTEx a été développé dans le cadre du CEN/TC278/WG3/SG9 piloté par la France. Les premières publications de NeTEx datent de 2014 et les plus récentes de mars 2026.\nIl faut noter que NeTEx a été l\u0026rsquo;occasion de renforcer les liens du CEN/TC278/WG3 avec le secteur ferroviaire, en particulier grâce à la participation de l\u0026rsquo;ERA (Agence Européen du Rail, qui a intégré NeTEx dans la directive Européenne 454/2011 TAP-TSI) et de l\u0026rsquo;UIC (Union International des Chemins de fer).\nLes 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.\nIl en résulte des normes qui sont relativement volumineuses et dont le périmètre dépasse souvent largement les besoins d\u0026rsquo;une utilisation donnée. Ainsi, à titre d\u0026rsquo;exemple, SIRI propose toute une série d\u0026rsquo;options ou de mécanismes dont la vocation est d\u0026rsquo;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\u0026rsquo;ils sont dès aujourd\u0026rsquo;hui pertinents en Suisse ou en Allemagne, sont pratiquement inexistants en France.\nDe plus, un certain nombre de spécificités locales ou nationales peuvent amener à préciser l\u0026rsquo;usage ou la codification qui sera utilisée pour certaines informations. Par exemple, les Anglais disposant d\u0026rsquo;un référentiel national d\u0026rsquo;identification des points d\u0026rsquo;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.\nEnfin, certains éléments proposés par ces normes sont facultatifs et il convient, lors d\u0026rsquo;une implémentation, de décider si ces éléments seront ou non implémentés.\nL\u0026rsquo;utilisation des normes liées à l\u0026rsquo;implémentation de l\u0026rsquo;interopérabilité pour le transport en commun passe donc systématiquement par la définition d\u0026rsquo;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 :\n  détail des services utilisés,\n  détails des objets utilisés dans un échange,\n  précisions sur les options proposées par la norme,\n  précision sur les éléments facultatifs,\n  précision sur les codifications à utiliser,\n  etc.\n  Ce document présente la partie Accessibilité du profil France de NeTEx, tel que défini par le Groupe de Travail dédié à l\u0026rsquo;information voyageur et à l\u0026rsquo;exploitation des services de mobilité (GT7) au sein de la Commission Nationale de normalisation pour le transport public (CN03).\nD\u0026rsquo;autres parties du profil France de NeTEx sont disponibles (arrêts, réseaux, horaire, tarif, parking). Ils sont tous complémentaires les uns des autres (sans recouvrement) et s\u0026rsquo;appuient tous sur le document: NeTEx - Profil France - Éléments communs. Il conviendra de se référer à ce document pour tous les éléments utilisés dans le présent document, et dont la structure n\u0026rsquo;est pas détaillée.\nCe profil d’échange a pour objectif de décrire et de structurer précisément les éléments nécessaires à une bonne information de l\u0026rsquo;accessibilité des services de transport public de façon :\n  à pouvoir les présenter d’une manière homogène et compréhensible à l’usager des transports publics sur des supports différents (papier ou Internet),\n  à pouvoir les échanger entre systèmes d’information (systèmes d’information voyageurs et systèmes d’information multimodale, systèmes d’aide à l’exploitation, systèmes de planification, systèmes billettiques, etc.).\n  Les éléments présentés ci-dessous couvrent donc l’ensemble des concepts propres à la description de l\u0026rsquo;accessibilité.\nNOTE IMPORTANTE Ce document étant un profil d\u0026rsquo;échange de NeTEx, il ne se substitue en aucun cas à NeTEx, et un minimum de connaissance de NeTEx sera nécessaire à sa bonne compréhension.\nDomaine d\u0026rsquo;application Le présent document est un profil de la spécification technique NeTEx CEN/TS 16614 pour l\u0026rsquo;échange de données de description de l\u0026rsquo;accessibilité des réseaux en France. Il permet de décrire et de structurer l\u0026rsquo;information pour des échanges entre systèmes d\u0026rsquo;information ainsi que pour en proposer des présentations aux voyageurs.\nCe document se positionne en complément des profils existants (Éléments Communs, Arrêts, Réseaux et Horaires) qui ont déjà introduit les notions de base de l\u0026rsquo;accessibilité via les concepts d'ACCESSIBILITÉ (ACCESSIBILITY ASSEMENT) et de LIMITATION D\u0026rsquo;ACCESSIBILITÉ (ACCESSIBILITY LIMITATION), détaillées dans le profil Éléments Communs et utilisées par tous les autres. On notera aussi que le profil Réseaux propose une vue très limitée du CHEMINEMENT (NAVIGATION PATH) dont la vocation est de porter les AccessFeatureList (types d\u0026rsquo;équipement rencontrés sur un cheminement) pour les correspondances entre sites.\nCette première approche de l\u0026rsquo;accessibilité se voulait minimale et le présent document l\u0026rsquo;aborde de façon beaucoup plus détaillée.\nCe document a été élaboré sur la base des réflexions et échanges intervenus dans le cadre du GT7 ainsi qu\u0026rsquo;en utilisant les conclusions de l\u0026rsquo;étude CAMERA.\nCe document a également été enrichi à l\u0026rsquo;aide du standard d’échange de données sur l’accessibilité des déplacements pour les personnes en situation de handicap produit par le groupe de travail CNIG sur l\u0026rsquo;Accessibilité. Ce modèle a pour but de décrire l\u0026rsquo;accessibilité des cheminements extérieurs en voirie, typiquement des trottoirs reliant un arrêt de transport en commun à l’entrée d’un ERP.\nDes compléments permettant d\u0026rsquo;assurer la mise en relation avec l\u0026rsquo;ontologie du projet OpenStreetMap ont également été apportés au document. OpenStreetMap (OSM) est un projet collaboratif de cartographie proposant une base de données géographiques libre du monde entier.\nSi la première motivation pour la définition de ce profil est bien l\u0026rsquo;accessibilité, cet objet n\u0026rsquo;est en aucun cas limitatif et les informations contenues (en particulier concernant les équipements et les cheminements) ont été généralisées pour un usage de type information voyageur sans restriction particulière à l\u0026rsquo;accessibilité (ce qui correspond bien à l\u0026rsquo;approche de NeTEx).\nRéférences normatives Les documents de référence suivants sont indispensables pour l\u0026rsquo;application du présent document. Pour les références datées, seule l\u0026rsquo;édition citée s\u0026rsquo;applique. Pour les références non datées, la dernière édition du document de référence s\u0026rsquo;applique (y compris les éventuels amendements).\nTS 16614-1, Network and Timetable Exchange (NeTEx) — Part 1: Public transport network topology exchange format\nTS 16614-2, Network and Timetable Exchange (NeTEx) — Part 2: Public transport scheduled timetables exchange format\nEN 12896, Public transport - Reference data model (Transmodel)\nTermes et définitions NOTE Pour les besoins du présent document, les termes et définitions suivants s\u0026rsquo;appliquent. Ils sont directement issus de la traduction française de Transmodel et NeTEx (on notera que certaines traductions sont un peu « étonnantes », toutefois il a été jugé préférable de rester cohérent avec la traduction officielle). Il conviendra souvent de se référer au corps du document car certaines traductions officielles peuvent amener à une totale incompréhension des concepts.\nPour une information complète, il conviendra toutefois de se référer au document normatif.\nACCESSIBILITY ASSESSMENT (ÉVALUATION D\u0026rsquo;ACCESSIBILITÉ)\nCaractéristiques d\u0026rsquo;accessibilité d\u0026rsquo;une entité utilisée par les passagers, telles qu\u0026rsquo;un LIEU D’ARRET ou un COMPOSANT DE LIEU D’ARRET. Décrites par LIMITES D\u0026rsquo;ACCESSIBILITÉ et / ou un ensemble de d’APTITUDEs (pour l’accessibilité).\nACCESSIBILITY LIMITATION (LIMITE D\u0026rsquo;ACCESSIBILITÉ)\nCatégorisation des caractéristiques d\u0026rsquo;accessibilité d\u0026rsquo;un SITE (p. ex. : LIEU D\u0026rsquo;ARRÊT ou COMPOSANT DE LIEU D\u0026rsquo;ARRÊT) pour indiquer son utilisabilité par les passagers ayant des besoins spécifiques, notamment ceux nécessitant un accès par fauteuil roulant, un accès sans marche ou ceux voulant éviter les espaces confinés tels que les ascenseurs. Quelques catégories bien définies sont utilisées, choisies pour permettre la saisie efficace des données et le calcul efficace d\u0026rsquo;itinéraires pour les différentes classes d\u0026rsquo;usager.\nACCESS (ACCÈS)\nPossibilité matérielle (spatiale) pour un usager d\u0026rsquo;accéder à un système de transports publics ou de le quitter. Ce tronçon peut être utilisé pendant un déplacement pour permettre au voyageur d\u0026rsquo;effectuer : - le trajet à pied d\u0026rsquo;un LIEU (origine du déplacement) vers un POINT D\u0026rsquo;ARRÊT PLANIFIÉ (origine du DÉPLACEMENT SUR RÉSEAU), ou - le trajet à pied depuis un POINT D\u0026rsquo;ARRÊT PLANIFIÉ (destination du DÉPLACEMENT SUR RÉSEAU) vers un LIEU (destination du déplacement).\nACCESS END (FIN D\u0026rsquo;ACCÈS)\nOrigine ou destination d\u0026rsquo;un tronçon d\u0026rsquo;ACCÈS. Peut indiquer un POINT et/ou un LIEU.\nACCESS MODE (MODE D\u0026rsquo;ACCÈS)\nCaractérisation du trajet d\u0026rsquo;un passager lorsqu\u0026rsquo;il emprunte un moyen de transport autre que les transports publics (p. ex : à pied, à vélo, etc.).\nACCOMODATION (HÉBERGEMENT)\nCombinaison de caractéristiques d\u0026rsquo;hébergement disponibles sur un service (p. ex : \u0026ldquo;Couchette première classe douche/2 lits\u0026rdquo;).\nACTUAL VEHICLE EQUIPMENT (ÉQUIPEMENT VÉHICULE RÉEL)\nÉquipement d\u0026rsquo;un type particulier sur un VÉHICULE donné.\nASSISTANCE SERVICE (SERVICE D\u0026rsquo;ASSISTANCE)\nSERVICE LOCAL spécialisé dans l\u0026rsquo;ASSISTANCE, fournissant des informations telles que la langue, le personnel formé à l\u0026rsquo;accessibilité, etc.\nCATERING SERVICE (SERVICE DE RESTAURATION)\nSpécialisation de SERVICE LOCAL dédiée aux services de restauration.\nCOMMUNICATION SERVICE (SERVICE DE COMMUNICATIONS)\nSpécialisation de SERVICE LOCAL dédiée aux services de communications.\nCOMPLAINTS SERVICE (SERVICE DE RÉCLAMATIONS)\nSpécialisation du SERVICE CLIENT pour les RÉCLAMATIONS.\nCROSSING EQUIPMENT (ÉQUIPEMENT DE CROISEMENT)\nÉQUIPEMENT D\u0026rsquo;ACCÈS À LA PLACE spécialisé pour ÉQUIPEMENTS DE FRANCHISSEMENT (passages piétons, éclairage piétons, dispositif acoustique, capteurs, bandes de guidage tactiles, etc.).\nCUSTOMER SERVICE (SERVICE CLIENT)\nSERVICE LOCAL générique spécial pour SERVICE CLIENT (objets perdus, point de rencontre, réclamations, etc.).\nCYCLE STORAGE EQUIPMENT (ÉQUIPEMENT DE STOCKAGE DE CYCLE)\nSpécialisation de l\u0026rsquo;ÉQUIPEMENT DE PLACE décrivant les équipements de parc pour deux-roues.\nENCUMBRANCE NEED (BESOIN DE TRANSPORT DE BAGAGES)\nBESOIN D\u0026rsquo;USAGER spécifique, à savoir une exigence d\u0026rsquo;un passager voyageant avec des bagages, un animal ou tout autre objet, et qui nécessite donc des dispositions particulières pour accéder aux transports publics.\nENTRANCE EQUIPMENT (ÉQUIPEMENT D\u0026rsquo;ENTRÉE)\nSpécialisation d\u0026rsquo;ÉQUIPEMENT D\u0026rsquo;ACCÈS À LA PLACE pour ENTRÉES (portes, barrières, portes tournantes, etc.)\nEQUIPMENT (ÉQUIPEMENT)\nÉquipement installé de manière fixe (ÉQUIPEMENT DE LIEU) ou à bord des véhicules (ÉQUIPEMENT VÉHICULE). Un service (SERVICE LOCAL de type CONSIGNE, SERVICE DE BILLETTERIE) est considéré comme un équipement immatériel.\nEQUIPMENT PLACE (LIEU DES EQUIPEMENTS)\nCOMPOSANT DE SITE comprenant un ÉQUIPEMENT\nEQUIPMENT POSITION (POSITION DES EQUIPEMENTS)\nLa place précise au sein d\u0026rsquo;un LIEU DES ÉQUIPEMENTS d\u0026rsquo;équipements particuliers.\nESCALATOR EQUIPMENT (ÉQUIPEMENT D\u0026rsquo;ESCALIER ROULANT)\nSpécialisation de l\u0026rsquo;ÉQUIPEMENT D\u0026rsquo;ESCALIER pour des ESCALIERS ROULANTS.\nFACILITY (INSTALLATION)\nnote : la traduction SERVICE aurait probablement été plus appropriée\nCommodité nommée mise à la disposition du public sur un SITE ou un SERVICE. Une prestation ne possède pas d\u0026rsquo;autres propriétés qu\u0026rsquo;un nom. Un ÉQUIPEMENT ou SERVICE LOCAL est utilisé pour décrire les autres propriétés fournies dans le cadre d\u0026rsquo;une prestation particulière.\nFACILITY SET (ENSEMBLE D\u0026rsquo;INSTALLATIONS)\nEnsemble d\u0026rsquo;INSTALLATIONS disponibles pour une COURSE COMMERCIALE ou un MORCEAU DE COURSE. L\u0026rsquo;ensemble peut être disponible uniquement pour un TYPE DE VÉHICULE spécifique du SERVICE (p. ex : voiture équipée d\u0026rsquo;un plancher surbaissé).\nGENERAL SIGN (SIGNALISATION GÉNÉRALE)\nSpécialisation d\u0026rsquo;ÉQUIPEMENT DE SIGNALISATION différent des INDICATIONS DE DIRECTION et de LIEU.\nHEADING SIGN (SIGNALISATION DE TITRE)\nnote : GIROUETTE aurait été une traduction plus appropriée\nSpécialisation d\u0026rsquo;ÉQUIPEMENT DE SIGNALISATION indiquant le nom d\u0026rsquo;une direction, d\u0026rsquo;une ligne, etc.\nHIRE SERVICE (SERVICE DE LOCATION)\nSpécialisation de SERVICE LOCAL dédiée aux services de location (cycles, voitures).\nINSTALLED EQUIPMENT (ÉQUIPEMENT INSTALLÉ)\nÉquipement installé de manière fixe (ÉQUIPEMENT DE LIEU) ou embarqué (associé à des véhicules). Cet équipement est matérialisé par opposition à un service (SERVICE LOCAL), considéré comme un équipement immatériel.\nLEFT LUGGAGE SERVICE (SERVICE DE CONSIGNE)\nSpécialisation du SERVICE CLIENTÈLE pour les consignes à bagages (casiers en libre-service, gratuits, etc.).\nLIFT EQUIPMENT (ÉQUIPEMENT D\u0026rsquo;ASCENSEUR)\nSpécialisation d\u0026rsquo;ÉQUIPEMENT D\u0026rsquo;ACCÈS À LA PLACE pour ASCENSEURS (indique des caractéristiques telles que la profondeur, la charge maximale, etc.).\nLOCAL SERVICE (SERVICE LOCAL)\nService identifié en fonction de l\u0026rsquo;utilisation du SITE ou des services de transport à un lieu particulier (p. ex :porteur, assistance aux usagers handicapés, bureaux de réservation). Le service peut posséder une CONDITION DE VALIDITÉ qui lui est associée. Un SERVICE LOCAL est traité comme une forme d\u0026rsquo;ÉQUIPEMENT immatériel.\nLOST PROPERTY SERVICE (SERVICE DES OBJETS TROUVÉS)\nSpécialisation du SERVICE CLIENTÈLE pour les objets trouvés.\nLUGGAGE SERVICE (SERVICE BAGAGES)\nSpécialisation du SERVICE CLIENTÈLE pour les bagages (installations/équipements et caractéristiques telles que les chariots à bagages, l\u0026rsquo;utilisation gratuite, etc.).\nLUGGAGE LOCKER EQUIPMENT (ÉQUIPEMENT DE CONSIGNE À BAGAGES)\nSpécialisation de l\u0026rsquo;ÉQUIPEMENT DE POINT D\u0026rsquo;ARRÊT pour les consignes à bagages.\nMEDICAL NEED (BESOIN MÉDICAL)\nBESOIN D\u0026rsquo;USAGER spécifique, à savoir une exigence d\u0026rsquo;un passager en ce qui concerne une contrainte médicale (p. ex : allergie) pour accéder aux transports publics.\nMEETING POINT SERVICE (SERVICE DE POINT DE RENCONTRE)\nSpécialisation du SERVICE CLIENT pour les points de rencontre (caractéristiques telles que la description, le libellé, etc.).\nMOBILITY NEED (BESOIN DE MOBILITÉ)\nBESOIN D\u0026rsquo;USAGER spécifique, à savoir une contrainte d\u0026rsquo;un passager en ce qui concerne sa mobilité (p. ex : fauteuil roulant, fauteuil roulant motorisé).\nMONEY SERVICE (SERVICE DE CHANGE)\nSpécialisation de SERVICE LOCAL dédiée aux services d\u0026rsquo;argent.\nNAVIGATION PATH (CHEMINEMENT USAGER)\nUn tronçon désigné entre deux endroits. Peut inclure une séquence triée de TRONÇONS DE CHEMINEMENT.\nNAVIGATION PATH ASSIGNMENT (AFFECTATION DE CHEMINEMENT DE NAVIGATION)\nAffectation d\u0026rsquo;un CHEMINEMENT USAGER à une AFFECTATION DE POINT D\u0026rsquo;ARRÊT spécifique, par exemple, pour indiquer le chemin à prendre pour établir une CONNEXION.\nONBOARD STAY (SÉJOUR À BORD)\nPermission d\u0026rsquo;embarquer avant la course ou de rester à bord après la course.\nPASSENGER EQUIPMENT (ÉQUIPEMENT USAGER)\nÉquipement d\u0026rsquo;un type particulier réellement disponible au niveau d\u0026rsquo;un LIEU ou d\u0026rsquo;un VÉHICULE.\nPASSENGER INFORMATION EQUIPMENT (ÉQUIPEMENT D\u0026rsquo;INFORMATIONS AUX PASSAGERS)\nUn équipement destiné à fournir des informations sur les transports en commun, tels que des terminaux (dans la rue, aux guichets ou reliés à un central, etc.) ou des supports papier (affichettes aux points d\u0026rsquo;arrêt, fascicules, etc.).\nPASSENGER SAFETY EQUIPMENT (ÉQUIPEMENT DE SÉCURITÉ DES PASSAGERS)\nSpécialisation ÉQUIPEMENT PASSAGER pour la sécurité des passagers.\nPATH JUNCTION (NŒUD DE CHEMINEMENT)\nUn point précis, à l\u0026rsquo;intérieur ou à l\u0026rsquo;extérieur d\u0026rsquo;un LIEU D\u0026rsquo;ARRÊT ou d\u0026rsquo;un POINT D\u0026rsquo;INTERÊT, au niveau duquel deux TRONÇONS DE CHEMINEMENTS peuvent se connecter\nPATH LINK (TRONÇON DE CHEMINEMENT)\nUn tronçon dans un LIEU ou entre plusieurs LIEUX (par exemple, LIEUX D\u0026rsquo;ARRÊT, ESPACES D\u0026rsquo;ACCÈS ou QUAIS, POINTS D\u0026rsquo;EMBARQUEMENT, POINTS D\u0026rsquo;INTÉRÊT, etc., NŒUDS DE CHEMINEMENT), qui représente une étape d\u0026rsquo;un itinéraire possible pour les piétons, les cyclistes ou les autres passagers non véhiculés au sein d\u0026rsquo;un LIEU ou entre des LIEUX.\nNOTE Il est possible, mais pas obligatoire, qu\u0026rsquo;un TRONÇON DE CHEMINEMENT projette sur un ensemble d\u0026rsquo;infrastructures ou de tronçons de mapping plus détaillés qui tracent l\u0026rsquo;itinéraire dans l\u0026rsquo;espace, ce qui permet de le représenter sur des plans et des systèmes de suivi.\nPATH LINK END (FIN DE TRONÇON DE CHEMINEMENT)\nSITE de départ ou d\u0026rsquo;arrivée d\u0026rsquo;un TRONÇON DE CHEMINEMENT. Il peut être lié à un NIVEAU spécifique du SITE.\nPATH LINK IN SEQUENCE (TRONÇON DE CHEMINEMENT EN SÉQUENCE)\nÉtape d\u0026rsquo;un CHEMINEMENT USAGER indiquant la traversée d\u0026rsquo;un TRONÇON DE CHEMINEMENT particulier au sein d\u0026rsquo;un itinéraire recommandé.\nPLACE ACCESS EQUIPMENT (ÉQUIPEMENT D\u0026rsquo;ACCÈS À LA PLACE)\nSpécialisation d\u0026rsquo;ÉQUIPEMENT DE LIEU dédiée à l\u0026rsquo;accès (ascenseurs, entrées, escaliers, rampes, etc.).\nPLACE EQUIPMENT (ÉQUIPEMENT DE LIEU)\nÉquipement d\u0026rsquo;un type particulier réellement disponible au niveau d\u0026rsquo;un LIEU.\nPLACE IN SEQUENCE (LIEUX ACCESSIBLES EN SEQUENCE)\nPoint traversé par un CHEMINEMENT USAGER en séquence, connecté par un TRONÇON DE CHEMINEMENT jusqu\u0026rsquo;au point suivant. Il peut s\u0026rsquo;agir d\u0026rsquo;un lieu, d\u0026rsquo;un NŒUD ou d\u0026rsquo;un POINT.\nPLACE LIGHTING (ÉCLAIRAGE DE LA PLACE)\nSpécialisation de l\u0026rsquo;ÉQUIPEMENT DE LIEU pour ÉQUIPEMENT D\u0026rsquo;ÉCLAIRAGE (par ex., réverbère).\nPLACE SIGN (SIGNALISATION DE PLACE)\nPanneau portant le nom d\u0026rsquo;un LIEU.\nPOINT OF INTEREST (POINTS D\u0026rsquo;INTÉRÊT)\nType de LIEU vers ou à travers lequel les passagers peuvent souhaiter circuler au cours de leur course et qui est modélisé en détail par les calculateurs d\u0026rsquo;itinéraire.\nPSYCHOSENSORY NEED (BESOIN PSYCHOSENSORIEL)\nBESOIN D\u0026rsquo;USAGER spécifique, à savoir une contrainte d\u0026rsquo;un passager relative à un handicap psychosensoriel (p. ex : troubles visuels ou auditifs, aversion pour les espaces confinés).\nQUEUING EQUIPMENT (ÉQUIPEMENT DE FILE D\u0026rsquo;ATTENTE)\nSpécialisation d\u0026rsquo;ÉQUIPEMENT D\u0026rsquo;ACCÈS AU LIEU dédiée aux files d\u0026rsquo;attente.\nRAMP EQUIPMENT (ÉQUIPEMENT DE RAMPE)\nSpécialisation d\u0026rsquo;ÉQUIPEMENT D\u0026rsquo;ACCÈS AU LIEU pour rampes (indique des caractéristiques telles que la profondeur, la pente, etc.).\nRETAIL SERVICE (SERVICE DE DÉTAIL)\nSpécialisation de SERVICE LOCAL dédiée aux services de distribution.\nROUGH SURFACE (SURFACE RUGUEUSE)\nSpécialisation de l\u0026rsquo;ÉQUIPEMENT DE LIEU pour surfaces rugueuses, qui indique la texture des surfaces, principalement pour informer les personnes handicapées.\nRUBBISH DISPOSAL (ÉLIMINATION DES DÉCHETS)\nSpécialisation des ÉQUIPEMENTS pour évacuation des déchets, indiquant les types de déchets, etc.\nSANITARY EQUIPMENT (ÉQUIPEMENT SANITAIRE)\nSpécialisation ÉQUIPEMENT PASSAGER pour les installations sanitaires.\nSEATING EQUIPMENT (ÉQUIPEMENT DE SIÈGES)\nSpécialisation de l\u0026rsquo;ÉQUIPEMENT DE LIEU décrivant les propriétés des sièges\nSERVICE FACILITY SET (ENSEMBLE D\u0026rsquo;INSTALLATIONS DE SERVICE)\nEnsemble d\u0026rsquo;INSTALLATIONS disponibles pour un TYPE DE VÉHICULE spécifique (p. ex : voiture équipée d\u0026rsquo;un plancher surbaissé), éventuellement pour un service uniquement (ou pour une COURSE ou une COURSE COMMERCIALE).\nSHELTER EQUIPMENT (ÉQUIPEMENT D\u0026rsquo;ABRIS)\nSpécialisation de l\u0026rsquo;ÉQUIPEMENT D\u0026rsquo;ATTENTE pour un abri.\nSIGN EQUIPMENT (ÉQUIPEMENT DE SIGNALISATION)\nSpécialisation de l\u0026rsquo;ÉQUIPEMENT DE LIEU pour la signalisation (directions, etc.).\nSITE EQUIPMENT (ÉQUIPEMENT DE SITE)\nSpécialisation d\u0026rsquo;ÉQUIPEMENT DE LIEU pour SITES (CASIER À BAGAGES, ÉQUIPEMENT D\u0026rsquo;ATTENTE, STAND DE CHARIOTS, etc.)\nSITE FACILITY SET (ENSEMBLE D\u0026rsquo;INSTALLATIONS SUR SITE)\nEnsemble d\u0026rsquo;INSTALLATIONS disponibles pour un ÉLÉMENT DE SITE.\nSTAIR EQUIPMENT (ÉQUIPEMENT D\u0026rsquo;ESCALIER)\nSpecialisation of ACCESS EQUIPMENT for stairs (stair, escalator, staircase, etc.).\nSTAIRCASE EQUIPMENT (ÉQUIPEMENT D\u0026rsquo;ESCALIER)\nSpécialisation d\u0026rsquo;ÉQUIPEMENT D\u0026rsquo;ACCÈS AU LIEU pour escaliers (escalier, escalier mécanique, cage d\u0026rsquo;escalier, etc.).\nSUITABILITY (APPROPRIATION)\nDéclaration stipulant si un BESOIN D\u0026rsquo;USAGER particulier peut être satisfait. Elle peut être utilisée pour indiquer si un SITE est accessible par un passager ayant un BESOIN particulier.\nTICKET VALIDATOR EQUIPMENT (ÉQUIPEMENT DE VALIDATION DE TITRES DE TRANSPORT)\nSpécialisation de l\u0026rsquo;ÉQUIPEMENT PASSAGER (ÉQUIPEMENT DE LIEU) décrivant les contrôleurs de billets.\nTICKETING EQUIPMENT (ÉQUIPEMENT DE DISTRIBUTION DE TITRES DE TRANSPORT)\nSpécialisation de l\u0026rsquo;ÉQUIPEMENT PASSAGER pour la billetterie.\nTICKETING SERVICE (SERVICE DE DISTRIBUTION DE TITRES DE TRANSPORT)\nSpécialisation de SERVICE LOCAL pour billetterie, fournissant des informations sur les guichets de billetterie et les achats en ligne, également associée à la méthode de paiement et au TYPE DE BILLET.\nTRAVELATOR EQUIPMENT (ÉQUIPEMENT DE TAPIS ROULANT)\nSpécialisation d\u0026rsquo;ÉQUIPEMENT D\u0026rsquo;ACCÈS AU LIEU pour tapis roulants (propriétés telles que la vitesse, etc.).\nTROLLEY STAND EQUIPMENT (ÉQUIPEMENT DE STANDS DE CHARIOTS)\nSpécialisation de l\u0026rsquo;ÉQUIPEMENT DE POINT D\u0026rsquo;ARRÊT pour les stands de chariots.\nTYPE OF ACCESSIBILITY TOOLS (TYPE D\u0026rsquo;OUTILS D\u0026rsquo;ACCESSIBILITÉ)\nClassification des OUTILS D\u0026rsquo;ACCESSIBILITÉ utilisés ou mis à disposition par le SERVICE D\u0026rsquo;ASSISTANCE (fauteuils roulants, cannes, navigateurs audio, navigateurs visuels, etc.).\nTYPE OF ASSISTANCE SERVICE (SERVICE DE TYPE D\u0026rsquo;ASSISTANCE)\nClassification de SERVICE D\u0026rsquo;ASSISTANCE (assistance à l\u0026rsquo;embarquement, à bord, portage, langues étrangères, traduction en langage des signes, etc.).\nTYPE OF EMERGENCY SERVICE (SERVICE DE TYPE D\u0026rsquo;URGENCE)\nTypologie des services d\u0026rsquo;urgence (police, premiers secours, borne d\u0026rsquo;appel, vidéosurveillance).\nTYPE OF GENDER LIMITATION (SERVICE DE LIMITATION DE SEXE)\nNote le traducteur officiel aurait peut-être pu se relire ici !!\nClassification des LIMITATIONS SELON LE GENRE (principalement pour ÉQUIPEMENTS SANITAIRES, par ex., réservé aux hommes/femmes, ou les deux).\nTYPE OF HANDRAIL (TYPE DE MAIN COURANTE)\nClassification de MAIN COURANTE (un côté, deux côtés).\nTYPE OF SANITARY FACILITY (SERVICE D\u0026rsquo;INSTALLATION SANITAIRE)\nClassification d\u0026rsquo;ÉQUIPEMENT SANITAIRE (toilettes, toilettes pour handicapés, douches, table à langer, table à langer pour handicapés)\nTYPE OF STAFFING (TYPE DE PERSONNEL)\nClassification de disponibilité du PERSONNEL associé à un SERVICE D\u0026rsquo;ASSISTANCE (plein temps, temps partiel)\nTYPE OF USER NEED (TYPE DE BESOIN D\u0026rsquo;USAGER)\nClassification des BESOINS D\u0026rsquo;USAGERS.\nUSER NEED (BESOIN D\u0026rsquo;USAGER)\nBesoin d\u0026rsquo;un usager exigeant une APPROPRIATION particulière.\nVEHICLE ACCESS EQUIPMENT (ÉQUIPEMENT D\u0026rsquo;ACCÈS AU VÉHICULE)\nSpécialisation de l\u0026rsquo;ÉQUIPEMENT VÉHICULE permettant l\u0026rsquo;accès aux véhicules, qui fournit différentes\ninformations (p. ex : plancher surbaissé, rampe, dimensions de la zone d\u0026rsquo;accès).\nVEHICLE CHARGING EQUIPMENT (ÉQUIPEMENT DE RECHARGE DE VÉHICULE)\nSpécialisation de l\u0026rsquo;ÉQUIPEMENT DE PLACE pour la recharge de véhicule.\nWAITING EQUIPMENT (ÉQUIPEMENT D\u0026rsquo;ATTENTE)\nSpécialisation de l\u0026rsquo;ÉQUIPEMENT DE LIEU D\u0026rsquo;ARRÊT pour ÉQUIPEMENTS D\u0026rsquo;ATTENTE (abri, salle d\u0026rsquo;attente, etc.).\nWAITING ROOM EQUIPMENT (ÉQUIPEMENT DE SALLE D\u0026rsquo;ATTENTE)\nSpécialisation de l\u0026rsquo;ÉQUIPEMENT D\u0026rsquo;ATTENTE pour salle d\u0026rsquo;attente, classée par TYPE DE SALLE D\u0026rsquo;ATTENTE.\nWHEELCHAIR VEHICLE EQUIPMENT (ÉQUIPEMENT VÉHICULE POUR FAUTEUILS ROULANTS)\nSpécialisation de l\u0026rsquo;ÉQUIPEMENT VÉHICULE permettant l\u0026rsquo;accès des fauteuils roulants à bord d\u0026rsquo;un VÉHICULE, qui fournit différentes informations (p. ex : nombre de places pour fauteuils roulants et dimensions de l\u0026rsquo;accès).\nSymboles et abréviations AO\nAutorité Organisatrice de Transports\n CNIG\nConseil National de l\u0026rsquo;Information Géographique\n OSM\nOpenStreetMap\n PMR\nPersonne à Mobilité Réduite\n Exigences minimales liées au code des transports et la règlementation européenne La collecte et la mise à disposition des données « accessibilité » sont obligatoires et se conforment aux exigences :\n Au niveau européen, du règlement délégué (UE) 2017/1926 de la Commission du 31 mai 2017 modifié par le règlement délégué (UE) 2024/490 de la Commission du 29 novembre 2023 (https://eur-lex.europa.eu/eli/reg_del/2017/1926/2024-03-04), dit \u0026ldquo;règlement MMTIS\u0026rdquo; ; Au niveau français, des articles L. 1115-1 à L. 1115-7 , D. 1115-1, R. 1115-2 à R. 1115-8 et D. 1115-9 à D. 1115-11 du code du transports, notamment créés ou modifiés par les articles 25 et 27 de loi n° 2019-1428 du 24 décembre 2019 d’orientation des mobilités, dites loi « LOM ». Ces mêmes articles de la LOM précise le calendrier de mise à disposition des données. Par ailleurs, l’arrêté du 28 mai 2024 relatif aux dispositions de la collecte des données « accessibilité » dans les transports et en voirie pour les déplacements des personnes handicapées ou à mobilité réduite pris en application des articles L. 1115-6, L. 1115-7, D. 1115-9 et D. 1115-10 du code des transports, des articles L. 141-13 et R. 121-24 du code de la voirie routière (https://www.legifrance.gouv.fr/loda/id/JORFTEXT000049642987/) précise les modalités de collecte et de mise à disposition de ces données.  Les exigences techniques en matière d’accessibilité de la voirie, des espaces publics et des équipements associés (arrêts de bus, information voyageur…) à respecter sont listées dans l’arrêté du 15 janvier 2007 (modifié) relatif l\u0026rsquo;accessibilité de la voirie et des espaces publics. Pour les établissements recevant du public et les équipements de type sanitaires, l’arrêté du 20 avril 2017 relatif à l’accessibilité des établissements recevant du public, dits arrêté « ERP », liste l’ensemble des exigences techniques à respecter.\nAinsi, les critères proposés dans le Profil « Accessibilité » sont marqués « oui » uniquement s’ils sont conformes à la réglementation en vigueur. Par exemple, pour que le critère « accessible en fauteuil roulant » soit marqué « oui » pour un arrêt de bus, ce dernier doit impérativement respecter les exigences techniques mentionnées aux trois premiers alinéas du 12° de l’article 1 de l’arrêté du 15 janvier 2007.\nLe profil « Accessibilité » propose 3 niveaux d’information, du plus basique au plus complet et afin de fournir une information détaillée aux usagers, il est recommandé de compléter directement les attributs du niveau 3 du profil « Accessibilité » lorsqu’ils sont disponibles. Ces 3 niveaux d’information sont :\n les informations de base (voir 6.2), fondées sur l’évaluation a minima du respect des exigences d\u0026rsquo;accessibilité définies par la réglementation en vigueur mais pouvant également être déduites par le renseignement du niveau 3 (6.5, 6.6 et Annexes) ; un niveau intermédiaire décrivant les services disponibles (voir 6.4) ; un niveau complet détaillant les cheminements et les équipements (voir 6.5, 6.6 et Annexe), permettant le déploiement de l’information voyageur afin proposer des trajets accessibles selon le profil et les besoins des usagers, respectant ainsi le caractère non discriminatoire des services d’information et les exigences de l’article L. 1115-8 du code des transports en matière d’information sur l’accessibilité.  L’arrêté du 28 mai 2024 définit les éléments a minima obligatoires pour la description de l’accessibilité, soit tous les éléments de base.\nLe tableau ci-dessous résulte de l’analyse du code des transports et du règlement MMTIS et fournit la liste des concepts concernés dans le présent profil correspondant aux données mentionnées dans le dispositif réglementaire. Il est donc nécessaire de fournir les données prévues dans ces concepts pour être conforme au cadre réglementaire. 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.\nNotez que beaucoup de concepts dépendent des concepts issus de Transmodel/NeTEx et sont liés entre eux, soit par héritage, soit par relation au sens UML des termes. De plus, 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.\nPour 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.\nNotez que dans certains cas, ces concepts additionnels peuvent relever d’autres parties du profil France, précisés dans le tableau le cas échéant. Dans le contexte spécifique de l’accessibilité, les concepts eux-mêmes (arrêts, véhicules, lignes, etc.) sont majoritairement définis dans les autres parties du profil France (Arrêt, Horaire, Réseau et Parking) et le profil « Accessibilité » vient compléter ces informations.\nLa première colonne reprend la notion de niveau tel qu’il est décrit et utilisé par le règlement européen.\nConcernant le cas spécifique du rail, la STI PMR (https://eur-lex.europa.eu/legal-content/FR/TXT/PDF/?uri=CELEX:32019R0772\u0026amp;from=FR) exige un « inventaire des actifs » ayant pour objet : « de recenser les obstacles et entraves existants à l’accessibilité », et de « fournir des informations pratiques aux usagers ». Ces données doivent être fournies en utilisant le profil européen de NeTEx dédié à l’accessibilité (NeTEx – EPIAP). En tout état de cause, comme indiqué précédemment, le strict minimum reste de fournir les informations de base décrites en 6.2, et celles rendues obligatoires par l’arrêté du 28 mai 2024 relatif aux dispositions de la collecte des données « accessibilité » dans les transports et en voirie pour les déplacements des personnes handicapées ou à mobilité réduite.\nNote : sur ce point, une synchronisation avec le profil NeTEx accessibilité France est en cours, bien que les deux profils soient déjà très proches.\nLes 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. Notez aussi que, pour l’accessibilité, la LOM impose qu’un certain nombre d’informations soient collectées (Obligation précisée aux articles L. 1115-6 et L. 1115-7 et D. 1115-9 et D. 1115-10 du code des transports ainsi qu’à l’article R. 141-24 du code de la voirie routière pris en application du L. 141-13 du code de la voirie routière),voir le texte lui-même pour plus de détails.\nConcepts relatifs à la LOM et à la Règlementation Européenne     Niveau Catégorie Détail Concepts à minima Autres\nconcepts\n Commentaire    1 Trip plan computation — scheduled modes transport Stop facilities access nodes (including platform information, help desks/information points, ticket booths, lifts/stairs, entrances and exit locations) FACILITIES\n(Profil Arrêt)\nSTOP PLACE\n EQUIPMENT Voir 6.2 et 6.4 pour le minimum à fournir  1 Trip plan computation — scheduled modes transport Accessibility of access nodes, and paths within an interchange (such as existence of lifts, escalators) FACILITIES\n(Profil Arrêt)\nSTOP PLACE\n EQUIPMENT\nNAVIGATION PATH\n Voir 6.2 et 6.4 pour le minimum à fournir  1 Trip plan computation — scheduled modes transport Existence of assistance services (such as existence of on-site assistance) FACILITIES\n(Profil Arrêt)\nSTOP PLACE\n LOCAL SERVICE\n Voir 6.2 et 6.4 pour le minimum à fournir  1 Trip plan computation — scheduled modes transport Vehicles (low floor; wheelchair accessible.) FACILITIES\n(Profil Horaires)\nVEHICLE TYPE\n EQUIPMENT Voir 6.2 et 6.4 pour le minimum à fournir  1 Trip plan computation — road transport (for personal modes) Pedestrian network and accessibility facilities  NAVIGATION PATH\n Le profil Accessibilité peut caractériser l'accessibilité des infrastructures mais pas fournir la topologie nécessaire à un calculateur d'itinéraire\nINSPIRE (en partie seulement), OSM et DGF sont les principales sources potentielles pour ces informations  1 Passing times, trip plans and auxiliary information Status of access node features (including dynamic platform information, operational lifts/escalators, closed entrances and exit locations — all scheduled modes) (Profil SIRI)\nGeneral Message\n (Profil SIRI)\nSituation Exchange\nFacility Monitoring\n   3 Detailed common standard and special fare query (all scheduled modes) Passenger classes (classes of user such as adult, child, student, veteran, impaired access and qualifying conditions and classes of travel such as 1st, 2nd.) (Profil Tarif)\nACCESS RIGHT PARAMETER ASSIGNMENT\n  À associer au FARE PRODUCT en priorité, ou aux FARE OFFER PACKAGEs et FARE STRUCTURE ELEMENTs (nécessite donc une description de l’offre tarifaitre).  Cas\nparticulier\n Parking\nREGULATION (EU) 2015/962 et\nREGULATION (EU) 2017/1926\n Informations sur les parkings (tous modes confondus) (Profil Parking\nà venir)\nPARKING\nPARKING AREA\nPARKING BAY\n EQUIPMENT\nNAVIGATION PATH\n Note : le règlement Européen ne réclame pas explicitement les informations d’accessibilité des parkings, mais la LOM va plus loin que le règlement sur ce point.    Description du profil d’échange Conventions de représentation NOTE les choix de conventions présentés ici ont pour vocation d\u0026rsquo;être cohérents avec ceux réalisés dans le cadre du profil SIRI. De plus tous les profils NeTEx partagent les mêmes conventions.\nLes messages constituant ce profil d\u0026rsquo;é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:\n   Classifi­cation Nom Type Cardin­alité Description      Classification : permet de catégoriser l\u0026rsquo;attribut. Les principales catégories sont:\n  PK (Public Key) que l\u0026rsquo;on peut interpréter comme Identifiant Unique: il permet à lui seul d\u0026rsquo;identifier l\u0026rsquo;objet, de façon unique, pérenne et non ambiguë. C\u0026rsquo;est l\u0026rsquo;identifiant qui sera utilisé pour référencer l\u0026rsquo;objet dans les relations.\n  AK (Alternate Key) est un identifiant secondaire, généralement utilisé pour la communication, mais qui ne sera pas utilisé dans les relations.\n  FK (Foreign Key) indique que l\u0026rsquo;attribut contient l\u0026rsquo;identifiant unique (PK) d\u0026rsquo;un autre objet avec lequel il est en relation.\n  GROUP est un groupe XML nommé (ensemble d\u0026rsquo;attributs utilisables dans différents contextes) (cf: http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/#AttrGroups )\n  «cntd» (contained) indique une structure, un ensemble d\u0026rsquo;éléments, contenus dans l\u0026rsquo;objet décrit: on n\u0026rsquo;en donne alors que l\u0026rsquo;intitulé et non le détail de façon à éviter de surcharger le tableau.\n    Nom : nom de l\u0026rsquo;élément ou attribut XSD\n  Type : type de l\u0026rsquo;élément ou attribut XSD (pour certains d\u0026rsquo;entre eux, il conviendra de se référer à la XSD NeTEx)\n  Cardinalité : cardinalité de l\u0026rsquo;élément ou attribut XSD exprimée sous la forme \u0026ldquo;minimum:maximum\u0026rdquo; (\u0026ldquo;0:1\u0026rdquo; pour au plus une occurrence; \u0026ldquo;1:*\u0026rdquo; au moins une occurrence et sans limites de nombre maximal; \u0026ldquo;1:1\u0026rdquo; une et une seule occurrence; etc.).\n  Description : texte de description de l\u0026rsquo;élément ou attribut XSD (seuls 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).\n  Les textes surlignés en Jaune sont ceux présentant une particularité (spécialisation) par rapport à NeTEx : une codification particulière, une restriction d\u0026rsquo;usage, etc.\nLes attributs et éléments rendus obligatoires dans le cadre de ce profil restent facultatifs dans l\u0026rsquo;XSD (le contrôle de cardinalité devra donc être réalisé applicativement).\nDans les schémas UML, les objets présentés en gris clair (ou crème) correspondent à des objets intermédiaires de la chaine d\u0026rsquo;héritage mais qui ne seront pas utilisés en tant que tel (soit qu\u0026rsquo;ils sont \u0026ldquo;abstraits\u0026rdquo; soit qu\u0026rsquo;ils ne sont pas retenus par le profil). Ils restent toutefois présents dans les schémas car ils sont indispensables à la bonne compréhension des schémas.\n makes the figure autonumbering work. ---  Exemple de classe abstraite ou non retenue\nDe plus les schémas UML conservent les noms des classes en anglais (non traduit) car c\u0026rsquo;est sous cette dénomination que les objets présentés se retrouveront dans le modèle XSD et donc dans les tags XML utilisés dans l\u0026rsquo;implémentation et les échanges.\nÉléments d\u0026rsquo;accessibilité de base partagés par toutes les parties du profil France Tous les objets contenus dans les autres parties du profil France (Éléments Communs, Arrêts, Réseaux, Horaires, Tarifs et Parking) proposent une information de base sur l\u0026rsquo;accessibilité en utilisant les ÉVALUATIONs D’ACCESSIBILITÉ (ACCESSIBILITY ASSESSMENT). Celles retenues dans le profil France sont :\n WheelchairAccess : on peut s’y déplacer en fauteuil roulant StepFreeAccess : on peut s’y déplacer sans franchir de marche ou d\u0026rsquo;escalier EscalatorFreeAccess : on peut s’y déplacer sans utiliser d\u0026rsquo;escalator LiftFreeAccess : on peut s’y déplacer sans utiliser d\u0026rsquo;ascenseur AudibleSignalsAvailable : une information sonore ou une signalétique auditive est disponible VisualSignsAvailable : une information visuelle ou une signalétique visuelle est disponible TactileGuidanceAvailable : il y a des éléments linéaires au sol qui peuvent être détectés et suivis avec une canne, comme par exemple une bande de guidage podotactile  Les valeurs potentiellement portées par chacun de ces indicateurs sont: Oui, Non, Partiel ou Inconnu.\n\u0026ldquo;Oui\u0026rdquo; signifie que les exigences réglementaires sont remplies (principalement l’arrêté du 15 janvier 2007 relatif à l’accessibilité de la voirie et des espaces publics et l’arrêté du 20 avril 2017 relatif à l’accessibilité des ERPs).\n\u0026ldquo;Partiel\u0026rdquo; peut vouloir dire plusieurs choses :\n  partiel au niveau temporel (par exemple : pas toujours accessible UFR si le service d\u0026rsquo;accompagnement est limité aux jours de semaine)\n  partiel au niveau de l\u0026rsquo;objet/géographique (par exemple: pour une gare, accès possibles pour les UFR uniquement sur certains quais)\n  partiel par rapport à l\u0026rsquo;étendu du service (par exemple: signalétique auditive en cas de perturbations mais pas d\u0026rsquo;annonces pour les prochains passages)\n  Dans le cadre du profil France il est convenu, lorsque \u0026ldquo;Partiel\u0026rdquo; est utilisé, de systématiquement remplir le champ \u0026ldquo;ValidityCondition-\u0026gt;Description\u0026rdquo; pour préciser comment l\u0026rsquo;information doit être interprétée. Il est à noter que seul le champ ValidityCondition permet de contenir une description textuelle, sous forme d\u0026rsquo;un texte libre susceptible d\u0026rsquo;être présenté au public en complément des indicateurs ci-dessus.\nAccessibilité dans les autres parties du profil France\nToutefois, cela correspond à une information globale et synthétique, mais qui dans de nombreuses situations manquera de précisions, d\u0026rsquo;une part vis-à-vis des besoins d\u0026rsquo;accessibilité et d\u0026rsquo;autre part en terme de précision sur les équipements et cheminements rencontrés.\nAccessibilityAssessment – Élément (objet inclus)     Classifi­cation Nom Type Cardinalité Description  :: :: DataManagedObject :: ACCESSIBILITY ASSESSMENT hérite de DATA MANAGED OBJECT.   MobilityImpaired­Access Accessibility­Enumeration 1:1 Indication globale d'accessibilité (de la LIGNE ou du LIEU).\nIl peut valoir true (accessible), false (non accessible), partial ou unknown\n  «cntd» limitations AccessibilityLimitation 0:1 Limitations d'accessibilité   Comment MultilingualString 0:1 Commentaire complémentaire sur l'accessibilité.\nCe champ a pour vocation à compléter, en termes d'information voyageur, l'information générale de la structure. Il a donc pour vocation à être affiché avec les informations d'accessibilité.\n    NOTE : L\u0026rsquo;attribut MobilityImpairedAccess n\u0026rsquo;a pas été retenu dans le cadre des travaux sur le modèle d\u0026rsquo;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\u0026rsquo;il peut prendre étant true/false/unknow/partial, il est recommandé (pour des raisons de cohérence) que sa valeur soit:\n  true si tous les champs de AccessibilityLimitation sont à true\n  false si tous les champs de AccessibilityLimitation sont à false\n  partial si seulement certains champs de AccessibilityLimitation sont à true\n  unknow dans tous les autres cas\n  AccessibilityLimitation – Élément (objet inclus)    Classification Nom Type  Description      WheelchairAccess LimitationStatusEnum 1:1 Indique si on peut s’y déplacer en fauteuil roulant.    StepFreeAccess LimitationStatusEnum 0:1 Indique si on peut s’y déplacer sans franchir de marche ou d’escalier.    EscalatorFreeAccess LimitationStatusEnum 0:1 Indique si on peut s’y déplacer sans utiliser d’escalator.    LiftFreeAccess LimitationStatusEnum 0:1 Indique si on peut s’y déplacer sans utiliser d’ascenseur.    AudibleSignsAvailable LimitationStatusEnum 0:1 Indique si une information sonore ou une signalétique auditive est disponible.    VisualSignsAvailable LimitationStatusEnum 0:1 Indique si une information visuelle ou une signalétique visuelle est disponible.    TactileGuidanceAvailable LimitationStatusEnum 0:1 Indique s\u0026rsquo;il y a des éléments linéaires au sol qui peuvent être détectés et suivis avec une canne, comme par exemple une bande de guidage podotactile.    Adéquation aux besoins L\u0026rsquo;adéquation aux besoins n\u0026rsquo;est pas retenue dans le cadre du profill accessibilité.\nLes services disponibles Les SERVICES DISPONIBLES (FACILITY SET) permettent de décrire, pour une COURSE, un TYPE DE VÉHICULE ou un SITE, l\u0026rsquo;ensemble des services disponibles mais sans en préciser les caractéristiques détaillées, ni le nombre, ni la localisation. Il sera ainsi possible d\u0026rsquo;indiquer qu\u0026rsquo;un site dispose de toilettes (toilet), de toilettes accessibles en fauteuil roulant (wheelChairAccessToilet), ou si un véhicule dispose d\u0026rsquo;équipement audio (visualDisplays) et si cet équipement a été conçu pour un handicap visuel (displaysForVisuallyImpaired).\nOn peut voir la liste de ces services comme la façon répondre à la prise en compte des besoins (ADÉQUATION AU BESOIN (SUITABILITY)) présentée ci-dessus. Mais on peut aussi y voir une certaine redondance.\nLa description des services disponibles est retenue dans le cadre du profil pour l\u0026rsquo;accessibilité, mais uniquement avec un sous-ensemble des codes disponibles, et ne devra être utilisée que par les acteurs ne disposant pas de la possibilité de décrire les équipements disponibles.\nSERVICES DISPONIBLES\nSERVICES DISPONIBLES (FACILITY SET) contient une liste de services et peut se spécialiser en SERVICES SUR SITE (SITE FACILITY SET) et SERVICES À BORD (SERVICE FACILITY) qui lui-même se spécialise en SERVICE D\u0026rsquo;INSTALLATION (ACCOMODATION, qui décrit le type de siège, couchette, etc.) et POSSIBILITÉ DE RESTER À BORD (ONBOARD STAY).\nSERVICES DISPONIBLES – détail des énumérations\nFacilitySet – Élément    Classifi­cation Nom Type Cardin­alité Description     ::\u0026gt; ::\u0026gt; DataManagedObject ::\u0026gt; FACILITY SET hérite de DATA MANAGED OBJECT.   «PK» id FacilitySetIdType 1:1 Identifiant du FACILITY SET.    ProvidedByRef OrganisationRef 0:1 ORGANISATION en charge de proposer le FACILITY SET.    Description MultilingualString 0:1 Description du FACILITY SET.   «FK» TypeOfFacilityRef TypeOfFacilityRef 0:1 Classification du FACILITY SET. Non retenu dans le profil France jusqu\u0026rsquo;à son harmonisation.   «cntd» otherFacilities TypeOfEquipment / TypeTypeOfEquipmentRef 0:* Types de FACILITY arbitraires définis par l\u0026rsquo;utilisateur dans FACILITY SET, leur définition renvoie à des TYPES OF EQUIPMENT. Non retenu dans le profil France jusqu\u0026rsquo;à son harmonisation.   «cntd» (CommonFacilityGroup) xxxFacilitList 0:* FACILITIEs sont définies comme des listes de valeurs énumérées de types fixes qui sont communes à tous les FACILITY SETs. Il existe d\u0026rsquo;autres FACILITIEs spécifiques aux SERVICE FACILITY SET et SITE FACILITY SET.    ServiceFacilitySet – Élément    Classifi­cation Nom Type Cardin­alité Description     ::\u0026gt; ::\u0026gt; FacilitySet ::\u0026gt; SERVICE FACILITY SET hérite de FACILITY SET.   «PK» id ServiceFacilitySetIdType 1:1 Identifiant du SERVICE FACILITY SET.   «cntd» ServiceFacility­Group xxxFacilityList 0:* SERVICE FACILITies au sein d’un SERVICE FACILITY SET défini en tant que listes de valeurs énumérées. Il existe des spécificités pour le SERVICE FACILITY SET.   «cntd» accommodations accommodations 0:1 Accommodations (couchette, etc.) disponibles.   «cntd» onboardStays onboardStays 0:1 Autorisations de rester à bord.    SiteFacilitySet – Élément    Classifi­cation Nom  Type Cardin­alité Description     ::\u0026gt; ::\u0026gt;  FacilitySet ::\u0026gt; SITE FACILITY SET hérite de FACILITY SET.   «PK» id SiteFacilitySetIdType  1:1 Identifiant du SITE FACILITY SET.   «cntd» SiteFacility­Group xxxFacilityList  0:* SITE FACILITies dans SITE FACILITY SET défini en tant que listes de valeurs énumérées. Il existe des spécificités pour le SITE FACILITY SET.    Accommodation – Élément    Classifi­cation Nom Type Cardin­alité Description      Name MultilingualString 0:1 Nom de l’accomodation    Accommodation­Facility AccommodationFacility­Enum 0:1 Type d\u0026rsquo;accommodation    ToiletFacility SanitaryFacilityEnum 0:1 Type de toilette pour l’ACCOMMODATION.    PassengerCommsFacilityList PassengerCommsFacilityListOfEnumerations 0:1 Listes des services de communication.    Les SERVICES DISPONIBLES communs à toutes ces spécialisations et retenus dans le cadre du profil sont les suivants :\n-Information d\u0026rsquo;accessibilité\n  audioInformation (information audio)\n  audioForHearingImpaired (information audio adaptée pour le malentendants)\n  visualDisplays (écran d’affichage)\n  displaysForVisuallyImpaired (écran d’affichage adapté pour les mal voyants)\n  largePrintTimetables (grand panneau d’affichage)\n  -Assistance\n  personalAssistance (assistance personnalisée)\n  boardingAssistance (assistance à l’embarquement)\n  wheechairAssistance (assistance pour les fauteuils roulants)\n  unaccompaniedMinorAssistance (assistance pour les mineurs non accompagnés)\n  conductor (chef de train ou de station disponible)\n  information (information disponible)\n  -A disposition pour l\u0026rsquo;accessibilité\n  wheelchair (fauteuils roulants disponibles)\n  walkingstick (cannes disponibles)\n  audioNavigator (navigateurs audios disponibles)\n  visualNavigator (navigateurs visuels disponibles)\n  passengerCart (caddies disponibles)\n  pushchair (poussettes disponibles)\n  umbrella (parapluies disponibles)\n  buggy (voiturettes disponibles)\n  -Famille\n  servicesForChildren (services et activités pour les enfants)\n  nurseryService (service de garderie)\n  -Médical\n  defibrillator (défibrillateur)\n  alcoholTest (test d\u0026rsquo;alcoolémie)\n  -Mobilité/Accessibilité\n  lowFloor (plancher bas)\n  stepFreeAccess (accès sans marches)\n  suitableForWheelchairs (adapté aux fauteuils roulants)\n  suitableForHeavilyDisabled (adapté aux handicaps lourds ; note : prendre contact avec le gestionnaire pour plus de précisions)\n  suitableForPushchairs (adapté aux poussettes)\n  boardingAssistance (assistance à l’embarquement)\n  onboardAssistance (assistance à bord)\n  unaccompaniedMinorAssistance (assistance pour les mineurs non accompagnés)\n  tactilePlatformEdges (marquage podotactile sur le bord des quais)\n  tactileGuidingStrips (bandes de guidage podotactiles)\n  raisedKerb (trottoir surélevé)\n  raisedKerb (quai surélevé) -Loisir\n  freeWifi (Wifi gratuit)\n  publicWifi (Wifi public)\n  internet (accès Internet disponible)\n  powerSupplySockets (prises de courant)\n  -Information Voyageur\n  informationDesk (comptoir d’information voyageur)\n  realTimeDepartures (horaires de départ temps-réel)\n  -Dispositif d\u0026rsquo;information voyageur*\n  nextStopIndicator (indicateur des prochains arrêts)\n  stopAnnouncements (annonce des arrêts)\n  passengerInformationDisplay (affichage pour l’information voyageur)\n  realTimeConnections (information temps-réel sur les correspondances)\n  -Sanitaire\n  None (pas de sanitaires)\n  toilet (toilettes)\n  wheelChairAccessToilet (toilettes accessible pour les fauteuils roulants)\n  shower (douches)\n  washingAndChangeFacilities (espace pour se laver et se changer)\n  babyChange (espace bébé)\n  wheelchairBabyChange (espace bébé accessible en fauteuil roulant)\n  -Billet et Billettique\n  ticketMachines (machine de vente de billet)\n  ticketOffice (guichet de vente de billet)\n  ticketOnDemandMachines (machine d’impression de billet acheté en ligne)\n  mobileTicketing (billettique mobile – sur smartphone)\n  Les SERVICES DISPONIBLES de type Service (sans redondance des catégories précédentes) retenus dans le cadre du profil sont les suivants :\n-Services Réservés\n wheelchairOnlyReservations (service réservé pour fauteuil roulant, sur réservation)  -Accès à la place\n standing (debout)  -Bagages\n  extraLargeLuggageRacks (espace pour les bagages très larges – incluant les fauteuils roulants notamment)\n  cyclesAllowed (vélos autorisés en bagage)\n  Les SERVICES DISPONIBLES spécifiques aux lieux (sans redondance des catégories précédentes) retenus dans le cadre du profil sont les suivants :\n-Urgence\n  police (police)\n  fire (incendie)\n  firstAid (premiers secours)\n  sosPoint (point SOS, appel d’urgence)\n  -Service Bagage\n  porterage (porteur)\n  collectAndDeliverToStation (service de collecte et livraison en station)\n  -Parking\n  carPark (parking auto)\n  cyclePark (parking vélo)\n  -Personnel\n  fullTime (personne présente en permanence)\n  partTime (personne présente à temps partiel)\n  unmanned (sans personnel)\n  Les SERVICES DISPONIBLES disponible au niveau de la place, lors du voyage (sans redondance des catégories précédentes) retenus dans le cadre du profil sont les suivants :\nInstallation\n  specialSleeper (couchettes spéciales/adaptées)\n  specialSeating (sièges spéciaux/adaptés)\n  Les Équipements Un ÉQUIPEMENT est un matériel particulier installé, soit fixe (ÉQUIPEMENT DE LIEU) ou à bord de véhicules (ÉQUIPEMENT DE VÉHICULE). C\u0026rsquo;est une notion qu\u0026rsquo;il faut considérer de façon générale et un service (SERVICE LOCAL tel qu’OBJETS TROUVÉS, BILLETTERIE) est également considéré comme un ÉQUIPEMENT.\nDans le cadre du profil pour l\u0026rsquo;accessibilité, la description des équipements est recommandée à chaque fois que cela est possible (et que l\u0026rsquo;information est disponible). La description des ÉQUIPEMENTs est donc préférée à la description des services disponibles.\nÉquipements localisés Le schéma UML ci-dessous présente la structure des ÉQUIPEMENTs. Il propose deux spécialisations : SERVICE LOCAL (LOCAL SERVICE) et ÉQUIPEMENT INSTALLÉ (INSTALLED EQUIPMENT).\nStructure générique des ÉQUIPEMENT\nL\u0026rsquo;ÉQUIPEMENT INSTALLÉ (INSTALLED EQUIPMENT) peut lui-même être spécialisé en ÉQUIPEMENT DE LIEU (PLACE EQUIPMENT), ÉQUIPEMENT POUR PASSAGER (PASSENGER EQUIPMENT) ou ÉQUIPEMENT DE VÉHICULE (ACTUAL VEHICLE EQUIPMENT). On notera que l\u0026rsquo;ÉQUIPEMENT POUR PASSAGER est particulier car il peut soit être localisé dans un lieu (LIEU D\u0026rsquo;ARRÊT) soit dans un VÉHICULE (par exemple pour des équipements sanitaires comme les toilettes que le trouvera aussi bien en station que dans une rame de TGV).\nEquipment – Élément     Classifi­cation Nom Type Cardin­alité Description  :: :: DataManagedObject :: EQUIPEMENT hérite de DATA MANAGED OBJECT.  «PK» id EquipmentIdType 1:1 Identifiant de l’EQUIPEMENT.   Name MultilingualString 0:1 Nom de l’EQUIPEMENT.  «AK» PrivateCode PrivateCode 0:1 Identifiant alternatif de l’EQUIPEMENT.   PublicCode PublicCode 0:1 Code public de l’équipement, et qui figure généralement sur l’équipement, typiquement sous la forme d’une étiquette.\nPourra contenir des codes comme, par exemple, les codes MIR de la RATP\nNotez que ce code doit être accessible/préhensible sur l'équipement (notament en vue d'utilisation pour du crowd-sourcing et de la signalisation d'anomalie, etc.)\n   Image xsd:anyURI 0:1 Image de l’EQUIPEMENT.\nPourra aussi référencer des documents audio, des pages web, etc\n  «FK» TypeOfEquipment­Ref TypeOfEquipmentRef 0:1 Référence du type l’EQUIPEMENT.   Description MultilingualString 0:1 Description de l’EQUIPEMENT.\nDoit pouvoir être présenté au public   Note MultilingualString 0:1 Note concernat l’EQUIPEMENT.\nDoit pouvoir être présenté au public   OutOfService boolean 0:1 Indique si l’équipement est hors service pour une durée prolongée. Une véritable information de disponibilité en temps réel pourra être fournie avec le service SIRI Facility Monitoring.\nQuand OutOfServiceest utilisé, l'utilisation du ValidityCondition devient obligatoire pour, en particulier, indiquer la période prévue d'indisponibilité (et donc la date prévue de retour en fonctionnement)\n    TypeOfEquipment – Élément             Classifi­cation Nom Type Cardin­alité Description   ::\u0026gt; ::\u0026gt; TypeOfEntity ::\u0026gt; TYPE OF EQUIPMENT hérite de TYPE OF ENTITY.   «PK» id TypeOfEquipmentIdType 1:1 Identifiant du TYPE OF EQUIPMENT.    Functional­Purpose MultilingualString 1:1 Objectif fonctionnel du TYPE OF EQUIPMENT.    PlaceEquipment – Élément             Classifi­cation Nom Type Cardin­alité Description   ::\u0026gt; ::\u0026gt; DataManagedObject ::\u0026gt; PLACE EQUIPMENT hérite de DATA MANAGED OBJECT.    Le LIEUX D\u0026rsquo;ARRÊT contient des espaces dédiés pour positionner les équipements : ce sont les LIEUX D\u0026rsquo;ÉQUIPEMENT (ce sont de COMPOSANTS DE SITE). Un LIEUX D\u0026rsquo;ÉQUIPEMENT peut contenir de nombreux ÉQUIPEMENTs (qui peuvent être de types différents et caractéristiques) : chaque ÉQUIPEMENT aura un POSITION D\u0026rsquo;ÉQUIPEMENT au sein du LIEUX D\u0026rsquo;ÉQUIPEMENT.\nOn aura donc, par exemple, dans une gare, un espace où l\u0026rsquo;on trouvera des équipements de vente de titre grande ligne, des équipements de vente de titre banlieue et un distributeur de boisson. Chaque ÉQUIPEMENT aura sa position et ses caractéristiques propres.\nEquipmentPlace – Élément             Classifi­cation Nom Type Cardin­alité Description   ::\u0026gt; ::\u0026gt; Place ::\u0026gt; EQUIPMENT PLACE hérite de PLACE.   «PK» id EquipmentPlaceId 0:1 Identifiant de l’EQUIPMENT PLACE.   «cntd» equipment­Positions EquipmentPosition 0:* EQUIPMENT POSITIONs au sein EQUIPMENT PLACE (notez que plusieurs équipement peuvent être placés dans un même lieu d’équipement)    placeEquipments Equipment 0:* Liste des EQUIPMENTs au sein de l’EQUIPMENT PLACE.    10 — EquipmentPosition – Élément\n            Classifi­cation Nom Type Cardin­alité Description   ::\u0026gt; ::\u0026gt; DataManagedObject ::\u0026gt; EQUIPMENT POSITION hérite de DATA MANAGED OBJECT.   «PK» id EquipmentPositionIdType 0:1 Identifiant de l’EQUIPMENT POSITION.    EquipmentRef EquipmentRef 1:1 Référence à l’EQUIPMENT dont on fournit la position.    Description MultilingualString 0:1 Description de la postion de l\u0026rsquo;équipement.    Location Location 0:1 Position de l’EQUIPMENT (position géographique).   «FK» ReferencePoint­Ref PointRef 0:1 Point de référence pour un positionnement relatif de l’équipement (réalisé par les 2 attributs suivants : XOffset et YOffset). S’il est absent on utilisera le coin supérieur gauche de l’EQUIPMENT PLACE. S’il est présent, il correspondra à une entrée ou un élément facilement identifiable au sein de l’EQUIPMENT PLACE.    XOffset LengthType 0:1 Position nord/sud ou décalage vertical par rapport au point de référence    YOffset LengthType 0:1 Position est/ouest ou décalage horizontal par rapport au point de référence    La figure ci-dessous regroupe en une seule fois tous les équipements disponibles: il faut la voir comme un panorama, mais le grand nombre d\u0026rsquo;ÉQUIPEMENT rend le résultat très dense. Aussi il est détaillé dans les figures suivantes.\nNOTE : Dans cette figure et celles qui suivent, les objets encadrés en bleu foncé (comme RAMP EQUIPMENT) sont ceux qui ont été spécifiquement retenus par le projet CAMERA avec pour vocation de répondre à la réglementation en terme d\u0026rsquo;information sur l\u0026rsquo;accessibilité. Pour mémoire, l\u0026rsquo;étude CAMERA porte uniquement sur les modes de surface et ne couvre donc pas tous les besoins du profil.\nToutefois, les tableaux d\u0026rsquo;attributs des équipements ne sont fournis qu\u0026rsquo;en annexe pour ne pas trop alourdir le document.\nListe détaillée des ÉQUIPEMENTs\nParmi tous ces équipements, certains sont plus particulièrement dédiés à l\u0026rsquo;accessibilité. Dans le cadre du présent profil pour l\u0026rsquo;accessibilité, le tableau ci-dessous identifie les principaux types d\u0026rsquo;équipement correspondant, mais cette liste n\u0026rsquo;est bien sûr qu\u0026rsquo;indicative et d\u0026rsquo;une part ces équipements peuvent avoir un usage en dehors des contraintes d\u0026rsquo;accessibilité et d\u0026rsquo;autre part d\u0026rsquo;autres équipements peuvent aussi assurer un rôle dans l\u0026rsquo;accessibilité.\nRésumé des principaux équipements dédiés à l'accessibilité    Groupe Sous-groupe Équipement Principaux attributs relatifs à l’accessibilité     Place­Equipment Access­Equipment RoughSurface (surface accidentée) Type de surface     EntranceEquipment (entrée) Dimensions, franchissable en fauteuil roulant, modes d’ouverture, capteur acoustique, automatique.     StairEquipment (escalier) Rampe, hauteur de la rampe, hauteur des marches, nombre de marches.     LiftEquipment (ascenseur) Dimensions, accessible en fauteuil roulant, diamètre de giration (pour fauteuil roulant).     EscalatorEquipment (escalator) Largeur, dénivelé     TravelatorEquipment (tapis roulant) Largeur, longueur.     RampEquipment (rampe) Dimensions, pente, rampe et main courante, bande de guidage/interception.     QueuingEquipment (gestion de queue)      CrossingEquipment (passage piéton et croisement) Bande podotactile, information sonore, capteurs, aide acoustique, bateau.    SignEquipment PlaceSign (signalétique dans un lieu) Information sur le nom de l’arrêt     HeadingSign (girouette de véhicule)      GeneralSign (signalétique générale)     Ticketing TicketingEquipment (équipement billettique) Comptoir abaissé     TicketValidatorEquipment (validateur billettique)     StopPlace LuggageLockerEquipment (consigne et casiers)      ShelterEquipment (abris) Nombre de sièges, dimensions, présence de marches, largeur et profondeur de l’espace pour fauteuil roulant.     TrolleyStandEquipment (emplacement pour chariots et caddies)      WaitingRoomEquipment (salle d’attente) Nombre de sièges, dimensions, présence de marches, largeur et profondeur de l’espace pour fauteuil roulant.    Passenger­Equipment PassengerInfoEquipment (équipement d’information voyageur) Informations d’accessibilité     PassengerSafetyEquipment (équipement pour la sécurité des voyageurs) Caméras, bouton d’urgence, téléphone d’ugence, hauteur des appareils d’urgence, annonces sonores.     SanitaryEquipment (sanitaires) Genre, type de sanitaires, diamètre de giration pour fauteuil roulant.   Local Service Customer AssistanceService (service d’assistance) Aide à l’embarquement et autres aides disponibles.     MeetingpointService (point de rendez-vous)     ÉQUIPEMENTs de lieux\nLes ÉQUIPEMENTs DE LIEU sont les suivants (voir en annexe pour la sélection du profil) :\n  Équipement de gestion de queue (QUEING EQUIPMENT)\n  Passage piéton (CROSSING EQUIPMENT)\n  Équipement d\u0026rsquo;entrée (ENTRANCE EQUIPMENT)\n  Surfaces au sol spéciales (ROUGH EQUIPMENT)\n  Escalier (STAIRCASE EQUIPMENT)\n  Escalator (ESCALATOR EQUIPMENT)\n  Éclairage (PLACE LIGHTING)\n  Rampe d\u0026rsquo;accès (RAMP EQUIPMENT)\n  Ascenseur (LIFT EQUIPMENT)\n  Tapis roulant (TRAVELATOR EQUIPMENT)\n  Quand nécessaire, la description d\u0026rsquo;une rampe (escalier, etc.) peut être associée à l\u0026rsquo;équipement.\nÉQUIPEMENTs pour les passagers, de site et de signalisation\nLes ÉQUIPEMENTs proposés par NeTEx pour les passagers sont les suivants (voir en annexe pour la sélection du profil) :\n  Valideur de billet (TICKET VALIDATOR EQUIPMENT)\n  Équipement billettique (TICKETING EQUIPMENT)\n  Équipement de sécurité (PASSENGER SAFETY EQUIPMENT) comme des caméras vidéo ou des boutons d\u0026rsquo;appel\n  Équipement d\u0026rsquo;information voyageur (PASSENGER INFORMATION EQUIPMENT) comme un afficheur ou un indicateur d\u0026rsquo;arrêt suivent, etc.\n  Poubelle (RUBBISH DISPOSAL)\n  Équipement sanitaire (SANITARY EQUIPMENT)\n  Les ÉQUIPEMENTs sur site sont les suivants (voir en annexe pour la sélection du profil) :\n  Consigne à bagages (LUGGAGE LOCKER EQUIPMENT)\n  Point pour chariots à bagage (TROLLEY STAND EQUIPMENT)\n  Abris (SHELTER EQUIPMENT)\n  Siège (SEATING EQUIPMENT)\n  Salle d\u0026rsquo;attente (WAITING ROOM EQUIPMENT)\n  Les ÉQUIPEMENTs de signalétique sont les suivants (voir en annexe pour la sélection du profil) :\n  Poteau ou indication du nom du lieu (PLACE SIGN)\n  Panneau de guidage (HEADING SIGN)\n  Affichage et indicateurs (GENERAL SIGN)\n  SERVICE LOCAL\nLes SERVICE LOCAUX sont les suivants (voir en annexe pour la sélection du profil) :\n  Service d\u0026rsquo;assistance (ASSISTANCE SERVICE), précisant les équipements mis à disposition (fauteuil roulant, etc.), le personnel d\u0026rsquo;assistance, le type de service et le cas échéant le type de service d\u0026rsquo;urgence\n  Les services de billetterie (TICKETING SERVICE)\n  Les services liés aux bagages (LUGGAGE SERVICE)\n  Les services liés aux bagages perdus (LEFT LUGGAGE SERVICE)\n  Les services de réclamation (COMPLAINTS SERVICE)\n  Les services d\u0026rsquo;objets perdus (LOST PROPERTY SERVICE)\n  Les services de rendez-vous (MEETING POINT SERVICE)\n  Les services de communication (COMMUNICATION SERVICE)\n  Les services de restauration (CATERING SERVICE)\n  Les services de vente de détail (RETAIL SERVICE)\n  Les services financiers (MONEY SERVICE)\n  Les services de location (HIRE SERVICE)\n  Équipements non localisés NeTEx offre la possibilité de décrire des équipements sans les localiser : cela permet de décrire l\u0026rsquo;équipement et ses caractéristiques, et permet d\u0026rsquo;indiquer que cet équipement est disponible en station mais sans en dire plus (voir l\u0026rsquo;élément unlocalisedEquipment dans StopPlace dans le profil Arrêts). N\u0026rsquo;importe lequel des équipements décrit ci-dessus peut être référencé comme non localisé (on ne passera donc plus par les LIEUx D’ÉQUIPEMENT (EQUIPMENT PLACE) et POSITION D’ÉQUIPEMENT (EQUIPMENT LOCATION)). Le reste reste inchangé.\nLes Cheminements Les CHEMINEMENTs (NAVIGATION PATH) décrivent des chemins physiques pour aller d\u0026rsquo;un point à un autre en marchant. Ils peuvent se situer au sein de LIEU D\u0026rsquo;ARRÊT mais aussi à l\u0026rsquo;extérieur en cas de correspondance en particulier (on peut même définir un CHEMINEMENT entre deux lieux dont aucun n\u0026rsquo;est un LIEU D\u0026rsquo;ARRÊT).\nLes constituants de base de CHEMINEMENT sont de TRONÇONs DE CHEMINEMENT. Aux extrémités de ces tronçons (PATH LINK END) on peut associer des éléments de site (zone d\u0026rsquo;embarquement, salle d\u0026rsquo;échange, lieu d\u0026rsquo;équipement, etc.). Les tronçons sont assemblés en SEQUENCES DE TRONÇONS qui elles-mêmes s\u0026rsquo;assemblent en CHEMINEMENTs (la séparation en deux niveaux d\u0026rsquo;assemblage permet d\u0026rsquo;éviter les redéfinitions et de partager des SEQUENCES DE TRONÇONS entre plusieurs CHEMINEMENTs).\nLa figure ci-dessous en donne une illustration.\nvue schématiques des CHEMINEMENTs\nLe schéma UML ci-dessous décrit la structure des cheminements dans NeTEx (et Transmodel).\nStructure générique des CHEMINEMENTs\nOn notera, en plus des concepts introduits plus haut, la notion de JONCTION DE TRONÇON (PATH JUNCTION) qui permet de créer de \u0026ldquo;carrefours\u0026rdquo; où plusieurs TRONÇONs DE CHEMINEMENT se rejoignent. Les EXTRÉMITÉs DE TRONÇON, en plus de pouvoir être associés à un ÉLÉMENT DE SITE peuvent être associés à un niveau (pour notifier un changement d\u0026rsquo;étage par exemple) est aussi plus explicitement à une entrée du SITE ou du LIEU D\u0026rsquo;ARRÊT.\nLiens entre CHEMINEMENTs et ÉQUIPEMENTs\nLe schéma ci-dessus reprend le précédent et se concentre sur la relation entre les CHEMINEMENTs et les ÉQUIPEMENTs : cette relation est en effet cruciale dans le contexte de l\u0026rsquo;accessibilité et permet de bien situer les différents ÉQUIPEMENTs sur le parcours du voyageur. Cette relation passe là aussi par l\u0026rsquo;ÉLÉMÉNT DE SITE.\nCHEMINEMENTs pour les correspondances\nEnfin, le schéma ci-dessus montre comment les CHEMINEMENTs sont affectés aux correspondances : deux solutions sont possibles dans NeTEx, mais le profil pour l\u0026rsquo;accessibilité ne retiendra que la possibilité de lier un TRANSFER et un NAVIGATION PATH (relation traversedWith sur la figure, c\u0026rsquo;est en effet la solution la plus générique), implémentée au travers du champ Transfers du NAVIGATION PATH (voir plus bas).\nIl est important de prendre en compte le fait que les PathLink décrits ci-dessous peuvent être segmentés autant que nécessaire : ainsi si la nature du cheminement évolue et que l\u0026rsquo;on souhaite le renseigner au travers d\u0026rsquo;un changement des attributs portés par le PathLink (par exemple un changement d\u0026rsquo;éclairage, un changement de pente, etc.), il suffit de le \u0026ldquo;couper\u0026rdquo; à partir de l\u0026rsquo;endroit où l\u0026rsquo;on souhaite faire apparaître les nouvelles informations. Il n\u0026rsquo;y a pas de limite minimale à la taille que peut représenter un PathLink, mais il reste toutefois recommandé de ne pas trop les subdiviser (et donc de ne pas les faire trop petits) pour éviter de surcharger l\u0026rsquo;utilisateur en information et aussi pour limiter le volume d\u0026rsquo;information à gérer par les systèmes.\nÀ noter qu’en présence de bandes de guidage, il est obligatoire de créer un ou plusieurs objets SitePathLink pour les modéliser avec l\u0026rsquo;attribut TactileGuidingStrip dûment renseigné. Sa définition détaillée est en Table 11 plus bas. \nSitePathLink – Élément    Classifi­cation Nom Type Cardinalité Description  :: :: Link :: PATH LINK hérite de LINK.  «PK» id PathLinkIdType 1:1 Identifiant du PATH LINK.   Distance DistanceType 0:1\n1:1\n Longueur du tronçon de cheminement.\nL'attribut Distance, hérité de LINK, est rendu obligatoire pour les tronçons de cheminement par le profil pour l'accessibilité. Il s'agit de la distance parcourue le long du tronçon de cheminement et non de la distance à vol d'oiseau entre les points de départ et d'arrivée.\n  «cntd» LineString gmlLineString 0:1\n1:1\n Géométrie du tronçon de cheminement.\nDans le contexte du profil pour l'accessibilité, la géométrie des PATH LINKs sera systématiquement décrite avec l'attribut LineString (GML) hérité de LINK. Il est important de bien noter que cette géométrie peut être différente, notament au niveau des extrémités, des centroïdes des objets référencés par From et To (qui sont généralement des centroïdes de zone, relativement imprécis). De plus les extrémités du LineString devront coïncider avec ceux des autres PATH LINK connectés dans le cadre d'un NAVIGATION PATH.\n  «FK» From PathLinkEnd 1:1 Point ou lieu de départ du PATH LINK. Voir tableau suivant  «FK» To PathLinkEnd 1:1 Point ou lieu de fin du PATH LINK. Voir tableau suivant\nFromet Topeuvent référencer le même espace, mais avec des LineString (voir ci-dessus)différentes. On utilisera notament cette particularité pour traverser des équipements long (comme un tapis roulant) situés dans un EQUIPMENT PLACE (ZONE).\n   Description MultilingualString 0:1 Description du PATH LINK.  «cntd» Accessibility­Assesment AccessibilityAssesment 0:1 ACCESSIBILITY du PATH LINK.\nVoir le détail en Annexe.\n   PublicUse xsd:boolean 0:1 Indique si le cheminement est ouvert au public.\nPublic (true) par défaut (si l'attribut n'est pas fourni)\n   Covered CoveredEnum 0:1 Type de couverture. La valeur mixed est déconseillée dans le cadre du profil pour l'accessibilité : il convient dans ce cas de segmenter en plusieurs SitePathLink avec chacun un type de couverture propre.\n   Gated GatedEnum 0:1 Type de porte ou portillon d’accès   Lighting LightingEnum 0:1 Nature de l’éclairage\n wellLit : adapté pour les déficients visuels\n poorlyLit : éclairé mais non adapté pour les déficients visuels\n unlit : non éclairé\n unknown : information non disponible\n    AllAreasWheelchair xsd:boolean 0:1 Indique si le cheminement est pratiquable en fauteuil roulant.  «cntd» facilities SiteFacilitySet 0:* FACILITIES associées au PATH LINK.   Towards MultilingualString 0:1 Direction indiquée quand le cheminement est effectué dans le sens FROM vers TO (sens direct).   Back MultilingualString 0:1 Direction indiquée quand le cheminement est effectué dans le sens TO vers FROM.   NumberOfSteps xsd:integer 0:1 Nombre de marches rencontrées sur le cheminement. Il s'agit du nombre de marches total de l'escalier si le tronçon de cheminement correspond à un escalier, ou du nombre de ressauts ou marches isolées sinon.\n   MinimumWidth LengthType 0:1 Largeur minimale du cheminement\nLa largeur renseignée doit tenir compte des éventuels obstacles présents le long du tronçon de cheminement.\nCet élément est rendu obligatoire par l'arrêté du 28 mai 2024 pour les ascenseurs et trottoirs.\n  AllowedUse DirectionOfUseEnum 0:1 Indique si le cheminement est empruntable dans les deux sens.   Transition TransitionEnum 0:1 Type de transition du cheminement :\n up (montée)\n down (descente)\n level (pas de changement de niveau)\n Les valeurs upAndDown (montée puis descente) et downAndUp (descente puis montée) sont déconseillées dans le cadre du profil pour l'accessibilité : il convient dans ces cas de segmenter en plusieurs SitePathLink avec chacun un type de transition propre.\n   Gradient xsd:integer 0:1 Pente en degrés (dans le sens direct, from/to, du cheminement)\nCet élément est rendu obligatoire par l'arrêté du 28 mai 2024 pour les trottoirs.\n   TiltAngle xsd:integer 0:1 Dévers (inclinaison latérale) de +20 a -20 degrés (dans le sens direct, from/to, du cheminement)\nCet élément est rendu obligatoire par l'arrêté du 28 mai 2024 pour les trottoirs.\n   TiltType TiltTypeEnum 0:1 Valeur codée du dévers\n strongLeftTilt (dévers fort à gauche)\n mediumLeftTilt (dévers moyen à gauche)\n nearlyFlat (preque plat)\n mediumRightTilt (dévers moyen à droite)\n strongRightTilt (dévers fort à droite)\n    AccessFeatureType AccessFeatureEnum 0:1 Type de caractéristique associée au PATH LINK:\n lift (ascenseur)\n escalator (escalator)\n freightElevator (monte charge)\n travelator (tapis roulant)\n ramp (rampe)\n stairs (escalier)\n seriesOfStairs (série d’escalier)\n shuttle (navette)\n crossing (passge piéton, carrefour)\n barrier (barrière)\n narrowEntrance (passage étroit)\n hall (hall)\n concourse (hall, convergence de couloirs et accès)\n confinedSpace (espace confiné)\n queueManagement (gestion de queue)\n openSpace (espace ouvert)\n street (rue)\n pavement (trottoir)\n footpath (chemin piéton)\n passage (passage)\n    PassageType PassageTypeEnum 0:1 Précision du type de caractéristique associée au PATH LINK:\n:\n pathway (sentier, en surface)\n corridor (couloir)\n overpass (passerelle, pont)\n underpass (passage sous-terrain)\n tunnel (tunnel)\n    FlooringType FlooringTypeEnum 0:1 Type de surface au sol\n Carpet (tapis)\n Concrete (béton)\n Asphalt (asphalte)\n Cork (liège)\n FibreglassGrating (taillebotis en fibre de verre)\n GlazedCeramicTiles (carreaux de céramique émaillés)\n PlasticMatting (matière plastique)\n CeramicTiles (carrelage)\n Rubber (caoutchouc)\n SteelPlate (plaques métalique)\n Vinyl (vinyle)\n Wood (bois)\n Stone (pierre)\n Grass (gazon)\n Earth (terre)\n Gravel (graviers)\n Uneven (inégal)\n Unknown (inconnu)\n Other (autre)\n    RightSideBorder BorderTypeEnum 0:1 Type de bordure sur le côté droit (dans le sens direct, from/to, du cheminement)\n Wall (mur)\n Grass (gazon)\n Dirt (terre)\n Barrier (barière)\n Road (route)\n CyclingLane (piste cyclable)\n Step (marche)\n Rail (rail)\n Plants (plantes)\n Trees (arbres)\n Mud (boue)\n SolidEdge (bord solide)\n Water (eau)\n Gravel (gravier)\n NoPhysicalBorder (pas de bordure matérialisée)\n OtherPhysicalBorder (autre type de bordure)\n Unknown (inconnu)\n    LeftSideBorder BorderTypeEnum 0:1 Type de bordure sur le côté droit (dans le sens direct, from/to, du cheminement)   TactileWarningStrip TactileWarningEnum 0:1 Indique s’il y a des bandes d’interception podotactiles (dans le sens direct, from/to, du cheminement) :\n TactileStripAtBeginning (bande au depart)\n TactileStripAtEnd (bande à l’arrivée)\n TactileStripAtBothEnds (bandes aux deux extrémités)\n noTactileStrip (pas de bandes d’interception)\n unknown (inconnu)\n  Cet élément est rendu obligatoire par l'arrêté du 28 mai 2024 pour les escaliers et passages piétons.\n   TactileGuidingStrip xsd:boolean 0:1 Indique s’il y a des bandes de guidage podotactiles.\nEn cas de présence de bandes de guidage podotactiles, il est obligatoire de renseigner les tronçons de cheminement correspondants.\n  «cntd» TransferDuration TransferDuration 0:1 Temps moyens pour franchir le cheminement (4 valeurs disponibles) :\n DefaultDuration (durée moyenne)\n FrequentTravellerDuration (durée pour un voyageur habitué)\n OccasionalTravellerDuration (durée pour un voyageur occasionel)\n MobilityRestrictedTravellerDuration (durée pour un voyageur à mobilité réduite)\n    placeEquipments Equipment 0:1 Liste des AccessEquipment (équipements d’accès) dont dépend le tronçon de cheminement.    PathLinkEnd – Élément             Classifi­cation Nom Type Cardin­alité Description   «FK» PlaceRef PlaceOrJunctionRef 1:1 Point ou lieu à l’extrémité du PATH LINK.   «FK» LevelRef LevelRef 0:1 Niveau auquel le PATH LINKse connecte.   «FK» EntranceRef EntranceRef 0:1 Entrée (ou sortie) associée à l’extrémité du PATH LINK.    PathJunction (croisement/jonction de cheminement) – Élément     Classifi­cation Nom Type Cardin­alité Description  :: :: Point :: PATH JUNCTION hérite de POINT.  «PK» id PathJunctionIdType 1:1 Identifiant du PATH JUNCTION.   PublicUse PublicUseEnum 0:1 Indique si le PATH JUNCTION est accessible au public   Covered CoveredEnum 0:1 Type de couverture   Gated GatedEnum 0:1 Type de porte ou portillon d’accès   Lighting LightingEnum 0:1 Nature de l’éclairage\n wellLit : adapté pour les déficients visuels\n poorlyLit : éclairé mais non adapté pour les déficients visuels\n unlit : non éclairé\n unknown : information non disponible\n    AllAreasWheelchair xsd:boolean 0:1 Indique si le cheminement est pratiquable en fauteuil roulant.  «cntd» facilities SiteFacilitySet 0:* FACILITIES associées au PATH JUNCTION.   Label MultilingualString 0:1 Label additionel associé au PATH JUNCTION.   SiteComponentRef SiteComponentRef 0:1 Le PATH JUNCTION se situe au sein du SITE COMPONENT référencé.    PathLinkInSequence – Élément             Classifi­cation Nom Type Cardin­alité Description   ::\u0026gt; ::\u0026gt; VersionedChild ::\u0026gt; PATH LINK IN SEQUENCE hérite de VERSIONED CHILD   «PK» id LinkInSequenceIdType 1:1 Identifiant du PATH LINK IN SEQUENCE.   «FK» PathLinkRef PathLinkRef 1:1 Référence à un PATH LINK.           Reverse xsd:boolean 0:1 Indique si, dans le cadre de la séquence, on emprunte le cheminent en sens inverse (de To vers From). La valeur par défault est false (sens direct).                  Instruction MultilingualString 0:1 Instruction de guidage sur le cheminement.    Label MultilingualString 0:1 Label associé au PATH LINK IN SEQUENCE.           NavigationPath – Élément     Classifi­cation Nom Type Cardin­alité Description  :: :: LinkSequence :: NAVIGATION PATH hérite de LINK SEQUENCE.  «PK» id NavigationPathIdType 1:1 Identifiant du NAVIGATION PATH.   From PathLinkEnd 0:1 Point de départ du NAVIGATION PATH. Obligatoire si le détail des PATH LINKs n’est pas fourni.   To PathLinkEnd 0:1 Destination du NAVIGATION PATH. Obligatoire si le détail des PATH LINKs n’est pas fourni.   NavigationType NavigationTypeEnum 0:1 Type de NAVIGATION PATH:\n  hallToQuay (hall vers quai)\n  hallToStreet (hall vers rue)\n  quayToHall (quai vers hall)\n  quayToQuay (quai vers quai)\n  quayToStreet (qui vers rue)\n  streetToHall (rue vers hal)\n  streetToQuay (rue vers quai)\n  streetToSpace (rue vers espace/esplanade)\n  spaceToStreet (vers esplanade vers rue)\n  spaceToHall (vers esplanade vers hall)\n  hallToSpace (hall vers vers esplanade)\n spaceToSpace (esplanade vers esplanade)\n   «cntd» pathLinksIn­Sequence PathLinkInSequence 0:* PATH LINKs faisant partie du NAVIGATION PATH.  «cntd» transfers TransferRef 0:* TRANSFERs (correspondance) et ACCESS LINKs correspondant au NAVIGATION PATH et dont il décrit le cheminement détaillé (voir Profil Réseaux pour les TRANSFERs et ACCESS LINKs).    Entêtes NeTEx Note : les entêtes NeTEx sont présentés dans le document éléments communs. Seules les spécificités de la partie \u0026ldquo;accessibilité\u0026rdquo; du profil sont présentées ici.\nPour rappel, la liste des fichiers d\u0026rsquo;un export NeTEx profil France est décrite dans Éléments Communs.\nUne GeneralFrame de type NETEX_ACCESSIBILITY est utilisée pour échanger la description l\u0026rsquo;accessibilité dans le fichier accessibility.xml.\nTypeOfFrame : type spécifique NETEX_ACCESSIBILITY Lorsqu\u0026rsquo;une FRAME a pour TypeOfFrame la valeur NETEX_ACCESSIBILITY, seuls les objets de premier niveau suivants sont autorisés :\n SitePathLink PathLink PathJunction NavigationPath FacilitySet AccessEquipment, et tous les équipements qui en héritent PlaceEquipment, et tous les équipements qui en héritent SignEquipment, et tous les équipements qui en héritent PassengerEquipment, et tous les équipements qui en héritent SiteEquipment, et tous les équipements qui en héritent LocalService, et tous les équipements qui en héritent  Les équipements sont précisés dans l\u0026rsquo;annexe 8 de ce document.\nVoici un exemple de cadre du fichier accessibility.xml :\n\u0026lt;?xml version=\u0026#34;1.0\u0026#34; encoding=\u0026#34;utf-8\u0026#34;?\u0026gt; \u0026lt;PublicationDelivery xmlns=\u0026#34;http://www.netex.org.uk/netex\u0026#34; version=\u0026#34;2.0:FR-NETEX-2.4\u0026#34;\u0026gt; \u0026lt;PublicationTimestamp\u0026gt;2023-01-01T00:00:00.0Z\u0026lt;/PublicationTimestamp\u0026gt; \u0026lt;ParticipantRef\u0026gt;Exemple\u0026lt;/ParticipantRef\u0026gt; \u0026lt;dataObjects\u0026gt; \u0026lt;GeneralFrame id=\u0026#34;exemple:GeneralFrame:NETEX_ACCESSIBILITY:\u0026#34; version=\u0026#34;2.0:FR-NETEX-2.4\u0026#34;\u0026gt; \u0026lt;TypeOfFrameRef ref=\u0026#34;FR:TypeOfFrame:NETEX_ACCESSIBILITY:\u0026#34; /\u0026gt; \u0026lt;members\u0026gt; \u0026lt;!-- SitePathLink PathLink PathJunction NavigationPath FacilitySet AccessEquipment, et tous les équipements qui en héritent PlaceEquipment, et tous les équipements qui en héritent SignEquipment, et tous les équipements qui en héritent PassengerEquipment, et tous les équipements qui en héritent SiteEquipment, et tous les équipements qui en héritent LocalService, et tous les équipements qui en héritent --\u0026gt; \u0026lt;/members\u0026gt; \u0026lt;/GeneralFrame\u0026gt; \u0026lt;/dataObjects\u0026gt; \u0026lt;/PublicationDelivery\u0026gt; Annexe (normative) - Détail des équipements Les tableaux ci-dessous fournissent les détails des attributs propres à chaque type d\u0026rsquo;équipement.\nDans un certain nombre de cas, des attributs complémentaires ont été demandés pour le profil accessibilité. Pour répondre à cette demande, on utilise le mécanisme d\u0026rsquo;extension par clef-valeur proposé par NeTEx (KeyList, voir le profil Éléments Commun pour plus de détail sur ce mécanisme). Les tableaux contenants ces extensions sont présentées à la suite des descriptions des objets qu\u0026rsquo;ils complètent.\nPassenger Service Equipment PassengerEquipment (équipement pour les passagers) – Élément    Classifi­cation Nom Type Cardin­alité Description     ::\u0026gt; ::\u0026gt; Equipment ::\u0026gt; PASSENGER EQUIPMENT hérite de EQUIPMENT.    Fixed *xsd:*boolean 0:1 Indique si l’EQUIPMENT est fixe au sein d’une PLACE ou s’il est à bord d’un VEHICLE (donc mobile).    PassengerSafetyEquipment (équipement pour la sécurité des passagers)* *–* Élément     Classifi­cation Nom Type Cardin­alité Description  :: :: PassengerEquipment :: PASSENGER SAFETY EQUIPMENT hérite de PASSENGER EQUIPMENT.  «PK» id PassengerSafet­y­FacilityIdType 1:1 Identifiant du PASSENGER SAFETY EQUIPMENT.   PanicButton xsd:boolean 0:1 Indique si un bouton « panic » est disponible   SosPanel xsd:boolean 0:1 Indique si un dispositif d’appel d’urgence est disponible   HeightOfSosPanel LengthType 0:1 Hauteur du dispositif d’appel d’urgence   Lighting LightingEnum 0:1 Type d’éclairage.\n wellLit : adapté pour les déficients visuels\n poorlyLit : éclairé mais non adapté pour les déficients visuels\n unlit : non éclairé\n unknown : information non disponible\n    Acoustic­Announcements xsd:boolean 0:1 Indique s’il y a des annonces acoustiques   Acoustic­AnnouncementsTrigger AcousticAnnouncementsTriggerEnum 0:1 Mode de déclenchement des annonces acoustiques\n onDemand (à la demande)\n automatic (automatique)\n    AnnouncementsTriggeringMethod AnnouncementsTriggeringMethodEnum 0:1 Méthode de déclenchement des annonces acoustiques\n presenceDetector (détecteur de présence)\n app (application sur smartphone)\n internetPage (Page internet via Image-xsd:anyURI hérité de EQUIPMENT)\n specificDevice (télécommande)\n pushButton (bouton poussoir)\n     SanitaryEquipment (sanitaires) – Élément    Classifi­cation Nom Type Cardin­alité Description     ::\u0026gt; ::\u0026gt; PassengerEquipment ::\u0026gt; SANITARY EQUIPMENT hérite de ACCESS EQUIPMENT   «PK» id SanitaryEquipmentIdType 0:1 Identifiant du SANITARY EQUIPMENT.    AccessibilityAssessment AccessibilityAssessment 0:1 Caractéristiques d’accessibilité des sanitaires.\nVoir le détail en Annexe.\n    Gender GenderLimitationEnum 0:1 Limitation de genre (homme/femme) pour l’utilisation des sanitaires.    SanitaryFacilityList SanitaryFacilityEnum 0:* Type de sanitaire\ntoilet (toilettes)\nwheelChairAccessToilet(toilettes accessibles en fauteuil roulant)\nshower (douche)\nwashingAndChangeFacilities (espace pour se nettoyer et se changer)\nbabyChange(espace bébé)\nwheelchairBabyChange (espace bébé accessible en fauteuil roulant)\n    Wheelchair­TurningCircle LengthType 0:1 Diamètre de giration pour les fauteuils roulants    SharpsDisposal xsd:boolean 0:1 Disponibilité d’une poubelle pour objets tranchants    Staffing StaffingEnum 0:1 Présence de personnel    KeyScheme xsd:normalizedString 0:1 Texte libre décrivant les conditions d\u0026rsquo;accessibilité : peut notamment compléter les informations comme\n- Espaces usage, barres de transfert, position du cercle de retournement, lave main (présence, hauteur), position du papier toilette, etc.    CallButtonAvailable xsd:boolean 0:1 Présence d’un bouton d’appel    SupportBarHeigth xsd:decimal 0:1 Hauteur de la barre de support (quand il y en a une)    LockedAccess xsd:boolean 0:1 Indique si les toilettes peuvent être verrouillées et donc une clé (ou un outil équivalent) est nécessaire pour y accéder.    HandWashing xsd:boolean 0:1 Indique s\u0026rsquo;il y a le nécessaire pour se laver les mains avec du savon    DrinkingWater xsd:boolean 0:1 Indique si de l\u0026rsquo;eau potable est disponible    ToiletsType ToiletsTypeEnumeration 0:1 Indique le type de toilettes.seated (position assise sur un siège avec une cuvette)urinal (urinoir utilisable uniquement debout)squat (position accroupie, sans siège ni cuvette)seatedAndUrinal (des sièges avec cuvette et des urinoirs sont disponibles)    RubbishDisposalEquipment (poubelles) – Élément    Classifi­cation Nom Type Cardin­alité Description     ::\u0026gt; ::\u0026gt; PassengerEquipment ::\u0026gt; RUBBISH DISPOSAL EQUIPMENT hérite de PASSENGER EQUIPMENT   «PK» id RubbishDisposal­EquipmentIdType 1:1 Identifiant du RUBBISH DISPOSAL EQUIPMENT.    SharpsDisposal xsd:boolean 0:* Disponibilité d’une poubelle pour objets tranchants    Waiting Equipment LuggageLockerEquipment (casiers à bagages) – Élément     Classifi­cation Nom Type Cardin­alité Description  :: :: SiteEquipment :: LUGGAGE LOCKER EQUIPMENT hérite de SITE EQUIPMENT  «PK» id LockerEquipmentIdType 1:1 Identifiant du LOCKER EQUIPMENT.   NumberOfLockers xsd:integer 0:1 Nombre de casiers   LockerWidth LengthType 0:1 Largeur des casiers   LockerHeight LengthType 0:1 Hauteur des casiers   LockerDepth LengthType 0:1 Profondeur des casiers   LockerType LuggageLockerEnum 0:1 Type de casier à bagages\n leftLuggageOffice (consigne)\n lockers (casier)\n bikeRack (porte vélo)\n bikeCarriage (garage à vélos)\n other (autre)\n    WheelcahairAccepted xsd:boolean 0:1 Signale si le casier/emplacement peut contenir un fauteuil roulant   LockingType LockingTypeEnum 0:1 Type de verrou :\n key (clé)\n keyboard (clavier)\n mechanicalNumbering (numérotation mécanique)\n contactless (sans contact)\n phoneApp (application sur téléphone)\n    BlindAccessible xsd:boolean 0:1 Indique si une personne malvoyante peut utiliser le mécanisme    TrolleyStandEquipment (stand de chariots) – Élément    Classifi­cation Nom Type Cardin­alité Description     ::\u0026gt; ::\u0026gt; SiteEquipment ::\u0026gt; TROLLEY STAND EQUIPMENT hérite de SITE EQUIPMENT.   «PK» id TrolleyEquipmentIdType 1:1 Identifiant du TROLLEY STAND EQUIPMENT.    FreeToUse xsd:boolean 0:1 Indique si le chariot est libre d’accès    WaitingEquipment (espace d’attente) – Élément    Classifi­cation Nom Type Cardin­alité Description     ::\u0026gt; ::\u0026gt; SiteEquipment ::\u0026gt; WAITING EQUIPMENT hérite de SITE EQUIPMENT.    Seats xsd:integer 0:1 Nombre de sièges dans la zone    Width LengthType 0:1 Largeur de l’espace d’attente    Length LengthType 0:1 Largeur de l’espace d’attente    StepFree xsd:boolean 0:1 Signale si l’espace d’attente contient des marches ou non    WheelchairAreaWidth LengthType 0:1 Largeur de l’espace dédié aux fauteuils roulants    WheelchairArea­Length LengthType 0:1 Longueur de l’espace dédié aux fauteuils roulants    SmokingAllowed xsd:boolean 0:1 Signale s’il est autorisé de fumer ou non    Heated xsd:boolean 0:1 Signale si l’espace est chauffé    AirConditioned xsd:boolean 0:1 Signale si l’espace est climatisé    SeatingEquipment (sièges) – Élément    Classification Nom Type Cardinalité Description     ::\u0026gt; ::\u0026gt; WaitingEquipment ::\u0026gt; SEATING EQUIPMENT hérite de WAITING EQUIPMENT   «PK» id SeatingEquipmentIdType 1:1 Identifiant du SEATING EQUIPMENT.    Armrest xsd:boolean 0:1 Signale si le siège dispose d’un accoudoir    Backrest xsd:boolean 0:1 Signale si le siège dispose d’un dossier    SeatingHeight xsd:decimal 0:1 Hauteur de l’assise    ShelterEquipment (abris) – Élément    Classifi­cation Nom Type Cardin­alité Description     ::\u0026gt; ::\u0026gt; WaitingEquipment ::\u0026gt; SHELTER EQUIPMENT hérite de WAITING EQUIPMENT.   «PK» id ShelterEquipmentIdType 1:1 Identifiant du SHELTER EQUIPMENT.    Enclosed xsd:boolean 0:1 Whether shelter is enclosed for protection from weather etc.    DistanceFrom­NearestKerb LengthType 0:1 Distance of shelter from kerb.    WaitingRoomEquipment (salles d’attente) – Élément    Classifi­cation Nom Type Cardin­alité Description     ::\u0026gt; ::\u0026gt; WaitingEquipment ::\u0026gt; WAITING ROOM EQUIPMENT hérite de WAITING EQUIPMENT   «PK» id WaitingRoom­EquipmentIdType 1:1 Identifiant du WAITING ROOM EQUIPMENT.    TypeOfFareClass FareClassEnum 1:1 Classe tarifaire nécessaire pour utilisaer la salle d’attente           Facilities SanitaryEquipment 0:1 Sanitaires disponibles dans la salle           Access Equipment Dans le cas des entrées de gare, l\u0026rsquo;attribut Width est rendu obligatoire par l\u0026rsquo;arrêté du 28 mai 2024. Voir le détail dans la table ci-après.\nAccessEquipment (équipement d’accès) – Élément    Classifi­cation Nom Type Cardin­alité Description     ::\u0026gt; ::\u0026gt; PlaceEquipment ::\u0026gt; ACCESS EQUIPMENT hérite de PLACE EQUIPMENT.   «PK» id PlaceAccessEquipmentIdType 1:1 Identifiant du ACCESS EQUIPMENT.    Width meters 0:1 Largeur de la porte our l’espace d’entrée    DirectionOfUse DirectionOfUseEnum 0:1 Direction dans laquelle on peut emprunter l’accès (les deux par defaut)    SafeForGuideDog xsd:boolean 0:1 Signale si l’accès est sans risqué pour un chien guide.    En cas de présence de bandes d’interception podotactiles, il est obligatoire renseigner l’attribut TactileWarningStrip dans tout CrossingEquipment. Voir la table ci-après pour la description de cet élément.\nCrossingEquipment (croisements et traversées) – Élément     Classifi­cation Nom Type Cardin­alité Description  :: :: PlaceAccessEquipment :: CROSSING hérite de ACCESS EQUIPMENT.  «PK» id CrossingIdType 1:1 Identifiant du CROSSING.  enum CrossingType CrossingTypeEnum 0:1 Type de CROSSING:\n levelCrossing (passage à niveau)\n barrowCrossing (passage à niveau sans barrière)\n roadCrossing (passage piéton, traversée de route)\n roadCrossingWithIsland (passage piéton avec îlot en centre de voirie)\n other (autre)\n    ZebraCrossing xsd:boolean 0:1 Signale la présence de zebras   PedestrianLights xsd:boolean 0:1 Signale la présence de feu pour les piétons   AcousticDeviceSensors xsd:boolean 0:1 Signale la présence de capteurs de signaux   AcousticCrossingAids xsd:boolean 0:1 Signale la présence d’une aide acoustique à la traversée\nCet élément est rendu obligatoire par l'arrêté du 28 mai 2024 pour les passages piétons.\n   TactileGuidanceStrips xsd:boolean 0:1 Signale la présence de bandes de guidage podotactiles   VisualGuidanceBands xsd:boolean 0:1 Signale la présence de bandes de guidage visuel   DroppedKerb xsd:boolean 0:1 Signale la présence de bateaux (abaissement du trottoir) des deux côtés.  enum MarkingStatus MarkingStatusEnumeration 0:1 État du marquage au sol de la traversée piétonne  good (bon état)\n worn (dégradation sans gravité)\n hazardous (dégradation entraînant un problème de sécurité immédiat)\n none (pas de marquage au sol)\n unknown (inconnu)\n     VibratingCrossingAids xsd:boolean 0:1 Signale la présence d'un équipement délivrant des vibrations lorsque la traversée est permise.   BumpCrossing xsd:boolean 0:1 Indique si la traversée est convexe ou bombée (elle monte puis descend).  enum VisualObstacle VisualObstacleEnumeration 0:1  Indique la présence et le type de masque visuel. Il s'agit d'un élément, positionné jusqu'à 5 mètres en amont de la traversée, et qui gêne le piéton pour voir et être vu au moment de traverser  carParking (stationnement voiture)\n vegetation (végétation)\n building (bâti)\n streetFurniture (mobilier urbain)\n other (autre)\n none (aucun)\n    enum TactileWarningStrip TactileWarningEnum 0:1 Signale la présence de bandes d’interception podotactiles (dans le sens du PATHLINK associé) :\n TactileStripAtBeginning (bande d’interception au début)\n TactileStripAtEnd (bande d’interception à la fin)\n TactileStripAtBothEnds (bandes d’interception des deux côtés)\n noTactileStrip (pas de bande d’interception)\n unknown (inconnu)\n  Cet élément est rendu obligatoire par l'arrêté du 28 mai 2024 pour les passages piétons.\n    Il faudra porter une attention toute particulière aux éléments de description des EntranceEquipment (entrées), notamment sur le détail des types de porte et plus particulièrement les attributs RevolvingDoor, AutomaticDoor, NecessaryForceToOpen détaillés dans la table ci-après.\nEntranceEquipment (entrées) – Élément    Classifi­cation Nom Type Cardin­alité Description     ::\u0026gt; ::\u0026gt; PlaceAccessEquipment ::\u0026gt; ENTRANCE EQUIPMENT hérite de ACCESS EQUIPMENT   «PK» id EntranceEquipmentIdType 1:1 Identifiant du ENTRANCE EQUIPMENT    Door xsd:boolean 0:1 Signale la présence d’une porte (false indique qu’il n’y a pas de porte)    KeptOpen xsd:boolean 0:1 Signale si la porte est conservée en position ouverte (pendant les heures d’ouverture)    RevolvingDoor xsd:boolean 0:1 Signale une porte tambour (en complément de Door)    Barrier xsd:boolean 0:1 Signale la présence d’une barrière physique pour le franchissement de la porte    NumberOfGates xsd:integer 0:1 Nombre de portes (ou passages)    Staffing xsd:boolean 0:1 Signale la présence d’agents du personnel à l’entrée    EntranceRequires­Staffing xsd:boolean 0:1 Signale que le passage requiert la présence d’agents du personnel    EntranceRequiresTicket xsd:boolean 0:1 Signale que le passage requiert un ticket    AcousticSensor xsd:boolean 0:1 Signale la présence de capteurs acoustiques    AutomaticDoor xsd:boolean 0:1 Signale que la porte est à ouverture/fermeture automatique\nCet élément est rendu obligatoire par l\u0026rsquo;arrêté du 28 mai 2024 pour les entrées de gare.    DropKerbOutside xsd:boolean 0:1 Signale la présence de bateaux (abaissement du trottoir) au franchissement du passage    GlassDoor xsd:boolean 0:1 Signale la présence d’une porte vitrée    WheelchairPassable xsd:boolean 0:1 Signale la possibilité de franchissement en fauteuil roulant.    WheelchairUnaided xsd:boolean 0:1 Signale la possibilité de franchissement en fauteuil roulant sans aide.    EntranceAttention EntranceAttention­Enum 0:1 Nature de la sonnette ou du signal d’appel doorbell (sonnette)\n helpPoint (point d\u0026rsquo;aide)\nintercom (intercom)\nnone (aucun)\nother (autre)\n    AudioOrVideoIntercom xsd:boolean 0:1 Signale la necessité d’une communication audio ou vidéo pour pouvoir entrer    Airlock xsd:boolean 0:1 Signale la présence d’un sas    DoorstepMark xsd:boolean 0:1 Signale la présente d’une marque de seuil (de franchissement) podotactile.    AudioPassthroughIndicator xsd:boolean 0:1 Signale la présente d’un signal sonore de franchissement.    NecessaryForceToOpen NecessaryForceEnum 0:1 Force nécessaire pour l’ouverture de la porte noForce (aucune force nécessaire)\n lightForce (force légère)\nmediumForce (force moyenne)\nheavyForce (force importante)\nunknown (inconnu)\n\nCet élément est rendu obligatoire par l\u0026rsquo;arrêté du 28 mai 2024 pour les entrées de gare.    DoorHandleOutside DoorTypeEnumeration 0:1 Caractéristiques de la poignée de porte à l\u0026rsquo;extérieur lever (poignée classique)\n button (bouton)\ngrabRail (poignée de tirage)\nwindowLever (levier de fenêtre)\nvertical (bâton de maréchal, barre verticale)\nknob (poignée ronde)\ncrashBar (barre antipanique)\nother (autre type de poignée)\nnone (pas de poignée)\n    DoorHandleInside DoorTypeEnumeration 0:1 Caractéristiques de la poignée de porte à l\u0026rsquo;intérieur lever (poignée classique)\n button (bouton)\ngrabRail (poignée de tirage)\nwindowLever (levier de fenêtre)\nvertical (bâton de maréchal, barre verticale)\nknob (poignée ronde)\ncrashBar (barre antipanique)\nother (autre type de poignée)\nnone (pas de poignée)\n    RampDoorbell xsd:boolean 0:1 Lorsqu\u0026rsquo;il y a une rampe amovible pour accéder à l\u0026rsquo;entrée, indique la présence d’une sonnette au droit de la rampe    Recognizable xsd:boolean 0:1 Indique si l’entrée est facilement repérable dans son environnement en tenant compte de l\u0026rsquo;architecture, de la signalisation et du contraste visuel. On met false lorsque l\u0026rsquo;entrée est difficile à repérer.    TurningSpacePosition EntranceTurningSpacePositionEnumeration 0:1 Indique la présence, à proximité immédiate de la porte, d\u0026rsquo;un espace pour la manœuvrer correctement (au minimum un diamètre d'1,5m). outside (à l\u0026rsquo;extérieur)\n inside (à l\u0026rsquo;intérieur)\ninsideAndOutside (à l\u0026rsquo;intérieur et à l\u0026rsquo;extérieur)\nnone (pas d\u0026rsquo;espace de manœuvre)\n Voir l\u0026rsquo;annexe informative pour plus d\u0026rsquo;informations sur le remplissage de l\u0026rsquo;attribut.    WheelchairTurningCircle LengthType 0:1 Diamètre de giration pour les fauteuils roulants On considèrera le diamètre du plus petit espace de manœuvre (intérieur ou extérieur).    QueueingEquipment (gestion de queue) – Élément    Classifi­cation Nom Type Cardin­alité Description     ::\u0026gt; ::\u0026gt; PlaceAccessEquipment ::\u0026gt; QUEUING EQUIPMENT hérite de ACCESS EQUIPMENT   «PK» id QueuingEqupmentIdType 0:1 Identifiant du QUEUING EQUIPMENT.    RailedQueue xsd:boolean 0:1 Indique que la queue est guidée par une barrière ou une rampe    TicketedQueue xsd:boolean 0:1 Indique que l’ordre dans la queue est géré par un système de tickets    DisabledPriority xsd:boolean 0:1 Indique une priorité d’accès aux personnes handicapées (et généralement femmes enceintes).    QueuingSeatedPossible xsd:boolean 0:1 Indique la possibilité d’être assis en faisant la queue    RampEquipment (rampes) – Élément    Classifi­cation Nom Type Cardin­alité Description     ::\u0026gt; ::\u0026gt; PlaceAccessEquipment ::\u0026gt; RAMP EQUIPMENT hérite de ACCESS EQUIPMENT   «PK» id RampIdType 0:1 Identifiant du RAMP EQUIPMENT    Length LengthType 0:1 Longueur de la rampe    Gradient xsd:integer 0:1 Inclinaison de la rampe   «enum» GradientType GradientType 0:1 Inclinaison de la rampe en valeurs codées : verySteep (très pentu)steep (pentu)medium (pente moyenne)gentle (pente légère)level (plat)    Pedestal LengthType 0:1 Indique si la rampe repose sur un pied central    HandrailHeight xsd:boolean 0:1 Hauteur de la main courante   «enum» HandrailType HandrailEnumeration 0:1 Type de main courante : none (aucune)\noneSide (d’un côté uniquement)\nbothSides (des deux côtés)\n    TactileGuidance­Strips xsd:boolean 0:1 Indique si la rampe dispose d’une bande de guidage podotactile    VisualGuidance­Bands xsd:boolean 0:1 Indique si la rampe dispose de bandes de guidage visuelles    Temporary xsd:boolean 0:1 Signale que la rampe est temporaire    RestStopDistance xsd:boolean 0:1 Distance maximale entre deux paliers de repos Il est recommandé d\u0026rsquo;implanter un palier de repos en bas et en haut de chaque rampe, ainsi que tous les 10 mètres en cas de longue rampe.   «enum» SafetyEdge SafetyEdgeEnum 0:1 Indique la présence d\u0026rsquo;une bordure chasse-roue. Il s\u0026rsquo;agit d\u0026rsquo;une bordure latérale visant à bloquer la roue du fauteuil roulant pour éviter les chutes. oneSide (d’un côté uniquement)bothSides (des deux côtés)none (pas de chasse-roue)   «enum» TurningSpace RampTurningSpacePositionEnum 0:1 Indique la présence d\u0026rsquo;une aire de rotation (ou espace de manœuvre) UFR en bas et/ou en haut de la rampe : bottom (en bas uniquement)top (en haut uniquement)topAndBottom (en haut et en bas)none (pas d\u0026rsquo;aire de rotation)level (plat)    PlaceLighting (éclairage) – Élément     Classifi­cation Nom Type Cardin­alité Description  :: :: PlaceEquipment :: PLACE LIGHTING hérite de PLACE EQUIPMENT  «PK» id PlaceLightingIdType 1:1 Identifiant du PLACE LIGHTING.   Lighting LightingEnum 0:1 Type d’éclairage\n wellLit : adapté pour les déficients visuels\n poorlyLit : éclairé mais non adapté pour les déficients visuels\n unlit : non éclairé\n unknown : information non disponible\n    AlwaysLit xsd:boolean 0:1 Indique si le lieu est éclairé en permanence.   LightingMethod LightingMethodEnum 0:1 Méthode d’activation de l’éclairage :\n movementDetector (détecteur de movements)\n stepingDetector (capteur au sol)\n switchOnTheWall (interrupteur sur le mur)\n atDoorOpening (à l’ouverture de la porte)\n onlyAtNight (seulement la nuit, activation automatique)\n other (autre)\n     RoughSurface (surface irrégulière) – Élément     Classifi­cation Nom Type Cardin­alité Description  :: :: PlaceEquipment :: ROUGH SURFACE hérite de PLACE EQUIPMENT.  «PK» id SurfaceIdType 1:1 Identifiant du ROUGH SURFACE.   SurfaceType SurfaceEnum 1:1 Type of Surface.\n asphalt (asphalte)\n bricks (brique)\n cobbles (pavés)\n earth (terre)\n grass (gazon)\n looseSurface (surface instable)\n pavingStones (pierres)\n roughSurface (surface irrégulière)\n smooth (lisse)\n other (autre)\n     StaircaseEquipment (escalier) – Élément      Classifi­cation Nom Type Cardin­alité Description  :: :: StairEquipment :: STAIRCASE hérite de STAIR EQUIPMENT (qui hérite de ACCESS EQUIPMENT).  «PK» id StaircaseIdType 1:1 Identifiant du STAIRCASE.  StairGroup Depth LengthType 0:1 Hauteur (profondeur) de l’escalier  NumberOfSteps xsd:integer 0:1 Nombre de marches  StepHeight LengthType 0:1 Hauteur des marches (individuellement)  StepLength LengthType 0:1 Profondeur de la marche  StepColourContrast xsd:boolean 0:1 Indique la présence d'une bande visuellement contrastée permettant de bien distinguer le bord des marches.\nLes bandes doivent être présentes sur chaque marche, sur l'intégralité de la largeur des marches et d'une profondeur de 2 cm.\n  StepCondition StepConditionEnumeration 0:1 Indique la régularité des marches\nValeurs possibles :  even (l'escalier dispose de marches régulières, toutes de même hauteur et profondeur)\n uneven (les marches ne sont pas toutes de même taille, certaines peuvent être légèrement en pente)\n rough (les marches sont de taille très différentes, certaines peuvent être manquantes ou fortement en pente)\n    HandrailType HandrailEnum 0:1 Type de main courante\n none (aucun)\n oneSide (d’un côté seulement)\n bothSides (des deux côtés)\n   HandrailHeight LengthType 0:1 Hauteur de la main courante (à partir de la marche)  LowerHandrailHeight LengthType 0:1 Hauteur d’une éventuelle seconde main courante abaissée  TactileWriting xsd:boolean 0:1 Indique si du texte peut être lu de manière tactile sur la main courante de l'escalier  StairRamp StairRampEnumeration 0:1 Indique la présence d'une rampe (à vélo, à bagage, etc) au sein de l'escalier\nValeurs possibles :  bicycle (goulotte ou rampe sur le côté des marches, qui peut être utilisée pour pousser un vélo)\n luggage (rampe à valise, permettant de pousser des bagages)\n stroller (rampe à poussette : une paire de rampes peu larges, avec des petites marches entre les deux)\n other (un autre type de rampe dans l'escalier)\n none (pas de rampe dans l'escalier)\n   TopEnd StairEnd 0:1 Caractérisation de l’extrémité haute de l’escalier\nCet élément est rendu obligatoire par l'arrêté du 28 mai 2024 pour les bandes d'éveil de vigilance en haut des escaliers.\n  BottomEnd StairEnd 0:1 Caractérisation de l’extrémité basse de l’escalier  StaircaseGroup Continuous­Handrail xsd:boolean 0:1 Indique si la main courante est continue et sans rupture sur toute la longueur de l’escalier, y compris entre les volées de marches  WithoutRiser xsd:boolean 0:1 Signale des marches ouvertes (pas de contremarches)  SpiralStair xsd:boolean 0:1 Signale un escalier en spirale  NumberOfFlights xsd:integer 0:1 Nombre de volées de marches  flights StairFlight 0:\\* Description des volées de marches constituant l’escalier    StairEnd (extrémités d’escaliers) – Élément    Classifi­cation Nom Type Cardin­alité Description      Continuing­Handrail xsd:boolean 0:1 Indique si la main courante de l\u0026rsquo;escalier se prolonge au-delà des marches. La prolongation doit être au moins égale à la largeur d\u0026rsquo;une marche.    TexturedSurface xsd:boolean 0:1 Signale une surface au sol texturée. On indiquera ainsi la présence d\u0026rsquo;une bande d\u0026rsquo;éveil à la vigilance (BEV).    VisualContrast xsd:boolean 0:1 Indique un signalement (du début ou de la fin de l’escalier suivant le cas) par contraste de couleur. On indiquera ainsi par exemple la présence de contremarches d\u0026rsquo;une couleur différente du reste de l\u0026rsquo;escalier pour la première et la dernière marche.    StairFlight (volées de marche d’escalier) – Élément    Classifi­cation Nom Type Cardin­alité Description     «PK» id StairFlightIdType 1:1 Identifiant du STAIR FLIGHT.    Continuing­Handrail xsd:boolean 0:1 Signale une main courante continue avec la volée de marches précédente    EscalatorEquipment (escalator) – Élément    Classification Nom Type Cardinalité Description     ::\u0026gt; ::\u0026gt; StairEquipment ::\u0026gt; ESCALATOR hérite de STAIR EQUIPMENT   «PK» id EscalatorIdtype 1:1 Identifiant de l\u0026rsquo;ESCALATOR.    TactileActuators xsd:boolean 0:1 Signale une mise en marche par détecteur (tactile ou autre)    EnergySaving xsd:boolean 0:1 Signale un escalator à économie d’énergie (ralentissement ou arrêt quand il n’est pas utilisé)    DogsMustBeCarried xsd:boolean 0:1 Signale si les chiens doivent être pris dans les bras (ou transportés d’une autre manière) pour pouvoir franchir l’escalator    EscalatorWithLanding xsd:boolean 0:1 Signale un escalator avec une zone plate au début ou à la fin    MonitoringRemoteControl xsd:boolean 0:1 Signale la présence d\u0026rsquo;un système de contrôle à distance du fonctionnement de l\u0026rsquo;équipement    TravelatorEquipment (tapis roulant) – Élément    Classification Nom Type Cardinalité Description     ::\u0026gt; ::\u0026gt; PlaceAccessEquipment ::\u0026gt; TRAVELATOR hérite de ACCESS EQUIPMENT   «PK» id TravelatorIdtype 1:1 Identifiant du TRAVELATOR.    TactileActuators xsd:boolean 0:1 Signale une mise en marche par détecteur (tactile ou autre)    EnergySaving xsd:boolean 0:1 Signale un tapis roulant à économie d’énergie (ralentissement ou arrêt quand il n’est pas utilisé)    Speed SpeedType 0:1 Vitesse du tapis roulant    Length LengthType 0:1 Longueur du tapis roulant    Gradient xsd:Integer 0:1 Pente (en degrés entiers) du tapis roulant    IntegrateAnEscalatorPart xsd:boolean 0:1 Signale la présence d’une partie en escalator    LiftEquipment (ascenseur) – Élément    Classification Nom Type Cardinalité Description     ::\u0026gt; ::\u0026gt; PlaceAccessEquipment ::\u0026gt; LIFT hérite de ACCESS EQUIPMENT   «PK» id LiftIdType 1:1 identifiant du LiftEquipement    Depth LengthType 0:1 Profondeur de l’ascenseur Cet élément est rendu obligatoire par l\u0026rsquo;arrêté du 28 mai 2024 pour les ascenseurs.    MaximumLoad WeightType 0:1 Charge maximale    WheelchairPassable xsd:boolean 0:1 Signale si l’utilisation en fauteuil roulant est possible    WheelchairTurningCircle LengthType 0:1 Diamètre de giration pour les fauteuils roulants dans l’ascenseur    InternalWidth LengthType 0:1 Largeur à l\u0026rsquo;intérieur de la cabine    HandrailType HandrailEnum 0:1 Type de main courante none (aucun)\n oneSide (d’un côté seulement)\nbothSides (des deux côtés)\n    HandrailHeight LengthType 0:1 Hauteur de la main courante    CallButtonHeight LengthType 0:1 Hauteur du bouton d’appel de l’ascenseur (à partir du sol    DirectionButtonHeight LengthType 0:1 Hauteur des boutons d’appel directionels de l’ascenseur (à partir du sol), valeur la plus haute    LowerHandrailHeight LengthType 0:1 Hauteur de la main courante (à partir du sol)    RaisedButtons xsd:boolean 0:1 Signale si les boutons sont en relief    BrailleButtons xsd:boolean 0:1 Signale si les boutons sont marqués en braille. À utiliser aussi pour les marques tactiles (non braille)    MirrorOnOppositeSide xsd:boolean 0:1 Signale la présence d’un miroir en face de l’ascenseur    Attendant xsd:boolean 0:1 Signale s’il y a un préposé à l’ascenseur    Automatic xsd:boolean 0:1 Signale s’il s’agit d’un ascenseur automatique    AlarmButton xsd:boolean 0:1 Signale si l’ascenseur dispose d’un bouton d’alarme    TactileActuators xsd:boolean 0:1 Signale si l\u0026rsquo;ascenseur a des actionneurs tactiles    AudioAnnouncements xsd:boolean 0:1 Signale si l\u0026rsquo;ascenseur dispose d’un mécanisme d’annonces sonores    ReachedFloorAnnouncement xsd:boolean 0:1 Signale si l\u0026rsquo;ascenseur est équipé d\u0026rsquo;un système d\u0026rsquo;annonce sonore et/ou d\u0026rsquo;affichage visuel de l\u0026rsquo;étage atteint (il peut s\u0026rsquo;agir soit d\u0026rsquo;un numéro de niveau, soit de l\u0026rsquo;indication des services à cet étage) visual (affichage visuel)audio (annonce sonore)visualAndAudio (annonce sonore et affichage visuel)none (aucun système)    MagneticInductionLoop xsd:boolean 0:1 Signale la presence d’une boucle d’induction magnétique    SignageToLift xsd:boolean 0:1 Signale si l’accès à l\u0026rsquo;ascenseur est fléché/signalé    TactileGroundFloorButton xsd:boolean 0:1 Signale la presence d’une marque tactile spécifique sur le bouton du rez-de-chaussée    ExternalFloorSelection xsd:boolean 0:1 Signale que la sélection de l’étage de destination se fait à l’extérieur de l’ascenseur    ButtonsHeight LengthType 0:1 Hauteur (taille) des boutons    GroundMarkalignedWithButton xsd:boolean 0:1 Signale la présence de marquage podotactile pour repérer les boutons    Sign Equipment SignEquipment (signalétique) – Élément     Classifi­cation Naom Type Cardin­alité Description  :: :: PlaceEquipment :: SIGN hérite de PLACE EQUIPMENT.  «PK» id SignIdType 1:1 Identifiant du SIGN.   AsBraille xsd:boolean 0:1 Indique la présence d’une inscription en braille   Height LengthType 0:1 Hauteur (dimension) du panneau ou signe.   Width LengthType 0:1 Largeur (dimension) du panneau ou signe.   HeightFromFloor LengthType 0:1 Hauteur à laquelle le panneau ou signe se situe (depuis le sol)   Placement xsd:string 0:1 Description textuelle de la position du panneau ou signe.   BrandGraphic xsd:anyUrl 0:1 URL d’information sur la marque associée au panneau ou au signe.   SignGraphic xsd:anyUrl 0:1 URL associée d’information associée au panneau ou au signe.\nDoit être conforme à l'accessibilité RGAA\n   MachineReadable xsd:boolean 0:1 Signale si la signalétique peut être lue par un machine (smartphone, tablette, etc.)   AudioAnnoucementType AudioAnnoucementTypeEnum _ 0:1 Signale si la signalétique est ou peut être lue par un dispositif audio :\n cyclicReading (lecture automatique à intervalles réguliers)\n whenSomebodyIsDetected (lecture automatique quand une présence est détectée)\n throughAnApp (via une app)\n throughASpecificDevice (via un terminal spécifique)\n    FontSize FontSizeEnum 0:1 Taille de la police de caractères :\n verySmall (très petite)\n Small (petite)\n Meduim (moyenne)\n Big (grande)\n VeryBig (très grande)\n    Contrast PercentageType 0:1 Différence de luminosité entre le fond et les caractères (un ratio d’au moins 3 est attendu)    HeadingSign (panneau de direction) – Élément    Classifi­cation Nom Type Cardin­alité Description     ::\u0026gt; ::\u0026gt; SignEquipment ::\u0026gt; HEADING SIGN hérite de SIGN EQUIPMENT.   «PK» id HeadingSignIdType 1:1 Identifiant du HEADING SIGN.    PlaceName MultilingualString 0:1 Nom du lieu indiqué sur le paneau    LineName MultilingualString 0:1 Nom de la ligne de transport en commun concernée par le panneau    DirectionName MultilingualString 0:1 Direction que le paneau indique (texte)   «FK» DestinationDisplayRef LineRef 0:1 DESTINATION DISPLAY referencée par le HEADING SIGN (référence technique)    GeneralSign (affichage générique) – Élément     Classifi­cation Nom Type Cardin­alité Description  :: :: SignEquipment :: GENERAL SIGN hérite de SIGN EQUIPMENT.  «PK» id GeneralSignIdType 1:1 Identifiant du GENERAL SIGN.   Content MultilingualString 0:1 Contenu textuel de l’affichage   SignContentType SignContentEnum 0:1 Type of contenu :\n Entrance (entrée)\n exit (sortie)\n emergencyExit (sortie de secours)\n transportMode (mode de transport)\n noSmoking (interdiction de fumer)\n tickets (billets)\n assistance (assistance)\n sosPhone (téléphone de secours)\n touchPoint (point de contact)\n meetingPoint (point de rendez-vous)\n TransportModePoint (point associé à une mode de transport)\n Other (autre)\n     PlaceSign (panneau d’indication de lieu) – Élément    Classifi­cation Nom Type Cardin­alité Description     ::\u0026gt; ::\u0026gt; SignEquipment ::\u0026gt; PLACE SIGN hérite de SIGN EQUIPMENT.   «PK» id SignIdType 1:1 Identifiant du PLACE SIGN.    PlaceName MultilingualString 1:1 Nom du lieu indiqué    Ticketing Equipment TicketValidatorEquipment (validateur) – Élément    Classifi­cation Nom Type Cardin­alité Description     ::\u0026gt; ::\u0026gt; PassengerEquipment ::\u0026gt; TICKET VALIDATOR EQUIPMENT hérite de PASSENGER EQUIPMENT   «PK» id TicketValidatorIdType 1:1 Identifiant du TICKET VALIDATOR EQUIPMENT.    ValidatorList TicketValidatorEnum 0:* Type of TICKET VALIDATOR.    AudioValidationFeedback xsd:boolean 0:1 Indique s’il y a une confirmation audio de la validation du titre    VisualValidationFeedback xsd:boolean 0:1 Indique s’il y a une confirmation visuelle de la validation du titre    TactileValidationFeedback xsd:boolean 0:1 Indique s’il y a une confirmation tactile de la validation du titre    ValidationGuidance MultilingualString 0:1 Texte libre décrivant les modalités de validation (comment valider le titre, comment trouver le valideur, etc.).    TicketingEquipment (équipement billettique) – Élément    Classifi­cation Nom Type Cardin­alité Description     ::\u0026gt; ::\u0026gt; PassengerEquipment ::\u0026gt; TICKETING EQUIPMENT hérite de PASSENGER EQUIPMENT.   «PK» id TicketingEquipmentIdType 1:1 Identifiant du TICKETING EQUIPMENT.    TicketMachines xsd:boolean 0:1 Signale la disponibilité de machines de vente de titres de transport    NumberOfMachines xsd:integer 0:1 Nombre de machines    HeightOfMachine­Interface LengthType 0:1 Hauteur a laquelle se trouve l’interface de la machine    TicketCounter xsd:boolean 0:1 Signale la disponibilité d’un guichet    InductionLoops xsd:boolean 0:1 Signale la présence d’un détecteur à boucle d’induction    LowCounterAccess xsd:boolean 0:1 Signale la présence d’un comptoir abaissé pour l’accessibilité    HeightOfLow­Counter LengthType 0:1 Hauteur du comptoir (comptoir abaissé pour l’accessibilité)    TactileInterfaceAvailable xsd:boolean 0:1 Signale la disponibilité d’une interface tactile    AudioInterfaceAvailable xsd:boolean 0:1 Signale la disponibilité d’une interface audio (permettant un usage en aveugle)    DisabledPriority xsd:boolean 0:1 Signale la une priorité handicapés (sans faire la queue)    WheelchairSuitable xsd:boolean 0:1 Signale la possibilité d’être utilise à partir d’un fauteuil roulant    Local Service AssistanceService (service d’assistance) – Élément     Classifi­cation Nom Type Cardin­alité Description  :: :: LocalService :: ASSISTANCE SERVICE hérite de LOCAL SERVICE.  «PK» id AssistanceServiceIdType 1:1 Identifiant du ASSISTANCE SERVICE.   AssistanceFacilityList AssistanceFacilityEnume 0:* Type of assistance fournie :\n personalAssistance (personnel d’assistance)\n boardingAssistance (le champ Description sera utilisé pour préciser l'assistant à l'embarquement/débarquement, notament dans le cas des correspondances multimodales)\n wheechairAssistance (assistance pour les fauteuils roulants)\n unaccompaniedMinorAssistance (assistance pour les mineurs non accompagnés)\n wheelchairUse (utilisation de fauteil roulant)\n conductor (controleur)\n information (information)\n    AssistanceAvailability AssistanceAvailabilityEnum 0:1 Disponibilité du service d’assistance\n none : pas d’assistance disponible\n available : assistance normalement disponible\n availableIfBooked : assistance disponible sur réservation\n availableAtCertainTimes : assistance disponible à certaines heures seulement.\n unknown : inconnu.\n    Staffing StaffingEnum 0:1 Signale si le personnel est disponible\n fullTime (à plein temps)\n partTime (à temps partiel)\n    AccessibilityTools AccessibilityToolEnum 0:* Dispositif et équipement d’accessibilité disponibles\n wheelchair : fauteuil roulant\n walkingstick : canne\n audioNavigator : navigateur audio\n visualNavigator navigateur visuel\n passengerCart : chariot\n pushchair : poussette\n umbrella : parapluie\n buggy : voiturette\n    Accessibility­Trained­Staff xsd:boolean 0:1 Indique que le personnel a été formé à la prise en compte des problèmatiques d’accessibilité   Emergency­Services EmergencyServicesEnum 0:* Services d’urgence disponibles\n police : police\n fire : incendie/pompiers\n firstAid : premiers secours\n sosPoint : point SOS (appel d’urgence)\n other : autre\n    SafetyFacilityList SafetyFacilityList 0:1 Dispositifs de sécurité disponibles\n ccTv : caméras\n mobileCoverage : couverture téléphone portable\n sosPoints : point SOS (appel d’urgence)\n staffed : personel\n     LuggageService (service de bagages) – Élément    Classifi­cation Nom Type Cardin­alité Description     ::\u0026gt; ::\u0026gt; LocalService ::\u0026gt; LUGGAGE SERVICE hérite de LOCAL SERVICE.   «PK» id LuggageServiceIdType 1:1 Identifiant du LUGGAGE SERVICE.    LuggageTrolleys xsd:boolean 0:1 Signale si des chariots à bagage sont disponibles    Wheelchair­LuggageTrolleys xsd:boolean 0:1 Signale si des chariots à bagage adaptés pour les personnes en fauteuil roulant sont disponibles    MaximumBagWidth LengthType 0:1 Largeur maximale des bagages    MaximumBagHeight LengthType 0:1 Hauteur maximale des bagages    MaximumBagDepth LengthType 0:1 Profondeur maximale des bagages    LuggageMaximalWeigth xsd:decimal 0:1 Poid maximal des bagages    CustomerService (service clientèle) – Élément    Classifi­cation Nom Type Cardin­alité Description     ::\u0026gt; ::\u0026gt; LocalService ::\u0026gt; CUSTOMER SERVICE hérite de LOCAL SERVICE    Email EmailAddressType 0:1 Email du service client    Phone PhoneNumberType 0:1 Téléphone du service client    InfoLink InfoLink 0:1 Lien URL pour accèder au service client    LostPropertyService (objets trouvés) – Élément    Classifi­cation Nom Type Cardin­alité Description     ::\u0026gt; ::\u0026gt; LocalService ::\u0026gt; LOST PROPERTY SERVICE hérite de CUSTOMER SERVICE.    id LostPropertyServiceIdType 1:1 Identifiant du LOST PROPERTY SERVICE.    MeetingPoint (point rencontre et rendez-vous) – Élément     Classifi­cation Nom Type Cardin­alité Description  :: :: LocalService :: MEETING POINT SERVICE hérite de CUSTOMER SERVICE  «PK» id MeetingServiceIdType 1:1 Identifiant du MEETING POINT SERVICE.   MeetingPointType MeetingPointEnum 1:1 Type de point de rendez-vous\n meetingPoint : point de rendez-vous\n groupMeeting : point de rendez-vous pour les groupes\n schoolMeetingPoint : point de rendez-vous pour les scolaires\n other : autre\n    Label MultilingualString 0:1 Lable (texte) permettant d’identifier le point de rendez-vous    TicketingService (service de vente de billets) – Élément    Classifi­cation Nom Type Cardin­alité Description     ::\u0026gt; ::\u0026gt; LocalService ::\u0026gt; TICKETING SERVICE hérite de LOCAL SERVICE.   «PK» id TicketingServiceIdType 1:1 Identifiant du TICKETING SERVICE.    TicketCounter­Service xsd:boolean 0:1 Signale la possibilité d’achat de titre de transport au comptoir    OnboardPurchase xsd:boolean 0:1 Signale la possibilité d’achat de titre à bord    MobileDevice­Tickets xsd:boolean 0:1 Signale la possibilité d’achat de titre sur smartphone    Commercial Service HireService (service de location) – Élément     Classifi­cation Nom Type Cardin­alité Description  :: :: LocalService :: HIRE SERVICE hérite de LOCAL SERVICE   TypeOfService HireFacilityEnum 1:* Classifications des services de location:\n Unknown : inconnu\n carHire : location de chariots\n motorCycleHire : location de cycles motorisés\n cycleHire : location de cycles\n taxi : taxi\n recreationDeviceHire : location pour les loisirs\n     Parking Equipment Notez que les parkings automobiles sont décrits en tant que tels et indépendament des équipements.\nCycleStorageEquipment (parcs à vélos) – Élément    Classifi­cation Nom Type Cardin­alité Description     ::\u0026gt; ::\u0026gt; PlaceEquipment ::\u0026gt; CYCLE STORAGE EQUIPMENT hérite de PLACE EQUIPMENT.   «PK» id CycleStorageIdType 1:1 Identifiant du CYCLE STORAGE EQUIPMENT.    NumberOfSpaces xsd:integer 0:1 Nombre maximal de places disponibles    Annexe (informative) - Détail des évaluations d\u0026rsquo;accessibilité (AccessibilityAssessment) Il n’existait pas encore de critères unifiés au niveau national pour les évaluations d’accessibilité. Voici une proposition de définition aidant à choisir entre les valeurs disponibles (oui/non/partiel) dans chaque cas. En cas de doute, se référer systématiquement à la règlementation en vigueur (principalement l’arrêté du 15 janvier 2007 modifié) relatif l\u0026rsquo;accessibilité de la voirie et des espaces publics et l’arrêté du 20 avril 2017 relatif à l’accessibilité des établissements recevant du public (ERP).\nDéfinition des AccessibilityLimitation retenus pour le TRONÇON DE CHEMINEMENT (SITE PATH LINK) WheelchairAccess : le sol est plat, de revêtement lisse et stable ; l’espace est assez large et sans obstacle permanent bloquant.\nEn particulier :\n lisse et stable signifie que le revêtement ne cause pas de secousse ou de risques de s’enfoncer ; on utilisera les valeurs de références suivantes pour la valeur true : dévers de moins de 2%, pente de moins de 5% et largeur d’au moins 1,40m ; si le dévers est de moins de 5%, ou la pente de moins de 8%, ou la largeur d’au moins 90 cm, on pourra utiliser partial ; on pourra également utiliser partial pour qualifier une rampe conforme à la réglementation française mais pas à cette définition ; false sera systématiquement utilisé pour les AccessFeatureType suivants :   stairs seriesOfStairs escalator travelator  AllAreasWheelchairAccessible vaudra true si WheelchairAccess vaut true, et false si WheelchairAccess est false. Pour plus de détails, renseigner aussi :\n TiltAngle, TiltType Gradient, GradientType FlooringType MinimumWidth  On utilisera la définition suivante pour AccessFeatureType valant lift : L’ascenseur dispose d’une profondeur d’au moins 1,25m et de portes coulissantes d’une largeur de passage d’au moins 80cm. LiftEquipment/WheelchairPassable vaudra true si WheelchairAccess vaut true, et false si WheelchairAccess est false. Pour plus de détails, renseigner aussi :\n LiftEquipment/Depth LiftEquipment/InternalWidth LiftEquipment/WheelchairTurningCircle  StepFreeAccess : il n’y a pas de marche infranchissable. En particulier, ça sera\n true s’il n’y a pas de marche ou s’il y a une marche de moins de 2 cm partial s’il y a une marche de moins de 4 cm false s’il y a une marche de plus de 4cm  Pour AccessFeatureType valant crossing, on considèrera les éventuelles marches à toutes les extrémités. StepFreeAccess prendra la valeur false pour les AccessFeatureType suivants :\n stairs seriesOfStairs  StepFreeAccess prendra la valeur true pour les AccessFeatureType suivants :\n escalator travelator lift ramp  NumberOfSteps vaudra 0 si StepFreeAccess vaut true. CrossingEquipment/DroppedKerb vaudra true si StepFreeAccess vaut true, et false si WheelchairAccess est false.\nEscalatorFreeAccess : ce n\u0026rsquo;est pas un escalator. En particulier, EscalatorFreeAccess prendra la valeur false pour AccessFeatureType valant escalator, et la valeur true dans tous les autres cas. En d\u0026rsquo;autres termes, si le SitePathLink est un escalator, la valeur vaut true ; sinon elle vaut false.\nLiftFreeAccess : ce n\u0026rsquo;est pas un ascenseur. En particulier, LiftFreeAccess prendra la valeur false pour AccessFeatureType valant lift, et la valeur true dans tous les autres cas. En d\u0026rsquo;autres termes, si le SitePathLink est un ascenseur, la valeur vaut true ; sinon elle vaut false.\nAudibleSignalsAvailable\n Pour les AccessFeatureType valant hall ou concourse : il existe un système de guidage sonore en bon état de fonctionnement le long de ce cheminement. Pour les AccessFeatureType valant crossing : il y a des feux sonores d’aide à la traversée en bon état en marche Pour les AccessFeatureType valant lift : l’ascenseur est équipé d’un mécanisme d’annonces sonores de l’étage en bon état de marche  CrossingEquipment/AcousticCrossingAids et LiftEquipment/AudioAnnouncements vaudra true si AudibleSignalsAvailable vaut true, et false si AudibleSignalsAvailable est false.\nVisualSignsAvailable\n Pour les AccessFeatureType valant hall ou concourse : il existe des panneaux directionnels le long de ce cheminement Pour les AccessFeatureType valant crossing : il y a un marquage au sol en bon état de type zébra guidant la traversée Pour les AccessFeatureType valant lift : l’ascenseur est équipé d’un panneau d’affichage en cabine indiquant l’étage.  CrossingEquipment/ZebraCrossing vaudra true si VisualSignsAvailable vaut true, et false si VisualSignsAvailable est false.\nTactileGuidanceAvailable : il y a des bandes de guidage, ou il y a un élément linéaire au sol qui peut être détecté et suivi avec une canne (mur, caniveau, etc).\nS\u0026rsquo;il y a des bandes de guidage podotactile, on renseignera également l\u0026rsquo;attribut TactileGuidingStrip.\nDéfinition des AccessibilityLimitation retenus pour les sanitaires (SANITARY EQUIPMENT) WheelchairAccess : un usager en fauteuil roulant peut se positionner sur la cuvette et atteindre et utiliser tous les équipements (lumière, lave-main, etc.) Cela signifie notamment qu’il faut un espace d’au moins 1,50 m à côté de la cuvette, une barre d’appui, un lave-main accessible, etc.\nDéfinition des AccessibilityLimitation retenus pour les zones d\u0026rsquo;embarquement (QUAY) WheelchairAccess : le sol est plat, de revêtement lisse et stable, assez large pour faire demi-tour en fauteuil (1,50m) et sans obstacle permanent bloquant\nEn particulier :\n lisse et stable signifie que le revêtement ne cause pas de secousse ou de risques de s’enfoncer on utilisera les valeurs de références suivantes pour la valeur true : dévers de moins de 2%, pente de moins de 5% si le dévers est de moins de 5%, ou la pente de moins de 8%, ou la largeur d’au moins 90 cm, on pourra utiliser partial  AudibleSignalsAvailable : il y a des annonces sonores, en général des prochains passages, indiquant au moins les lignes desservies ainsi que leur direction.\nVisualSignsAvailable : il y a au moins le nom de l\u0026rsquo;arrêt, les lignes desservies ainsi que leur direction, et un tableau ou écran d\u0026rsquo;affichage (présentant les horaires, le plan du réseau, des lignes desservies ou des abords). Les textes écrits sont conformes aux recommandations en vigueur en terme de taille de caractère, de lisibilité de la police et de contraste visuel par rapport à l\u0026rsquo;arrière plan (voir arrêté du 15 janvier 2007 pour plus de détails).\nTactileGuidanceAvailable : il y a des bandes de guidage podotactile menant à la porte permettant d\u0026rsquo;embarquer dans le véhicule, et elle sont connectées à des éléments linéaires au sol qui peuvent être détectés et suivis avec une canne (mur, bandes de guidage, etc).\nDéfinition des AccessibilityLimitation retenus pour les entrées (ENTRANCE) Ces définitions concernent tous les éléments qui héritent de ENTRANCE : accès de lieu d\u0026rsquo;arrêt (STOP PLACE ENTRANCE), accès piéton d\u0026rsquo;un parking (PARKING PASSENGER ENTRANCE), accès de point d\u0026rsquo;intérêt (POINT OF INTEREST ENTRANCE), etc.\nWheelchairAccess : il y a une largeur de passage d’au moins 80 cm et pas de marche infranchissable. S’il y a une porte, elle s’ouvre sans forcer (moins de 50 Newton).\nOn utilisera les mêmes valeurs de référence pour la hauteur de la marche éventuelle que pour StepFreeAccess (voir ci-après).\nStepFreeAccess : il n’y a pas de marche infranchissable.\nEn particulier, ça sera :\n true s’il n’y a pas de marche ou s’il y a une marche de moins de 2 cm partial s’il y a une marche de moins de 4 cm false s’il y a une marche de plus de 4 cm  TactileGuidanceAvailable : des bandes de guidage podotactile partent de cette entrée.\nDéfinition des AccessibilityLimitation retenus pour les lieux d\u0026rsquo;arrêts (STOP PLACE) WheelchairAccess : chaque quai est pratiquable en fauteuil roulant et il existe un cheminement pratiquable en fauteuil roulant entre chaque zone d\u0026rsquo;embarquement et au moins un accès.\nSe référer aux définitions plus précises de WheelchairAccess pour les zones d\u0026rsquo;embarquement (Quay), les accès de lieu d\u0026rsquo;arrêt (StopPlaceEntrance) et les cheminements (SitePathLink).\nStepFreeAccess : il est possible d’atteindre chaque zone d\u0026rsquo;embarquement depuis au moins un accès sans franchir de marche.\nEn particulier, ça sera :\n true s’il n’y a pas de marche ou s’il y a une marche de moins de 2 cm partial s’il y a une marche de moins de 4 cm false s’il y a une marche de plus de 4 cm  EscalatorFreeAccess : il est possible d’atteindre chaque zone d\u0026rsquo;embarquement depuis au moins un accès sans passer par un escalator.\nLiftFreeAccess : il est possible d’atteindre chaque zone d\u0026rsquo;embarquement depuis au moins un accès sans passer par un ascenseur.\nAudibleSignalsAvailable : il y a des annonces sonores.\nVisualSignsAvailable : il y a au moins le nom du lieu d\u0026rsquo;arrêt, les lignes desservies, et un tableau ou écran d\u0026rsquo;affichage (présentant les horaires, le plan du réseau, des lignes desservies ou des abords). Les textes écrits sont conformes aux recommandations en vigueur en terme de taille de caractère, de lisibilité de la police et de contraste visuel par rapport à l\u0026rsquo;arrière plan (voir arrêté du 15 janvier 2007 pour plus de détails).\nTactileGuidanceAvailable : il y a un réseau de bandes de guidage podotactile qui relient chaque zone d\u0026rsquo;embarquement à au moins un accès.\nDéfinition des AccessibilityLimitation retenus pour les places de stationnement (PARKING BAY) WheelchairAccess : le sol est plat, de revêtement lisse et stable ; la largeur est d\u0026rsquo;au moins 3.30m et on peut rejoindre la place depuis le trottoir sans franchir de marche.\nEn particulier :\n lisse et stable signifie que le revêtement ne cause pas de secousse ou de risques de s’enfoncer ; plat signifie dévers de moins de 2% et pente de moins de 2%  StepFreeAccess : il est possible de rejoindre la place directement depuis le trottoir sans rencontrer de marche infranchissable.\nEn particulier, ça sera :\n true s’il n’y a pas de marche ou s’il y a une marche de moins de 2 cm partial s’il y a une marche de moins de 4 cm false s’il y a une marche de plus de 4cm  VisualSignsAvailable :\n dans le cas général : la place de stationnement est délimitée par un marquage au sol dans le cas d\u0026rsquo;un stationnement réservé aux PMR : un marquage au sol et une signalisation verticale conformes à la réglementation indiquent la place de stationnement  En particulier, ça sera :\n true s\u0026rsquo;il y a un panneau de signalisation (panneaux B6d et M6h) et un pictogramme UFR blanc peint au sol sur les limites ou le long de l\u0026rsquo;emplacement. Voir l\u0026rsquo;arrêté du 7 juin 1977 modifié et l\u0026rsquo;instruction interministérielle sur la signalisation routière pour plus de détails. partial s\u0026rsquo;il y a un panneau ou un pictogramme false si les deux sont absents  TactileGuidanceAvailable : des bandes de guidage podotactile partent de cette place de stationnement.\nEspace de manœuvre pour les entrées (ENTRANCE EQUIPMENT) L\u0026rsquo;espace de manœuvre (ou aire de rotation) désigne à un espace situé juste devant la porte, permettant de la manœuvrer correctement et de faire demi-tour en fauteuil roulant afin de l\u0026rsquo;emprunter. Un diamètre d'1,50 m est attendu et on peut en retrouver de chaque côté de la porte (attribut TurningSpacePosition).\nBibliographie EN 15531-1, Public transport - Service interface for real-time information relating to public transport operations - Part 1: Context and framework\nEN 15531-2, Public transport - Service interface for real-time information relating to public transport operations - Part 2: Communications infrastructure3\nEN 15531-3, Public transport - Service interface for real-time information relating to public transport operations - Part 3: Functional service interfaces4\nCEN/TS 15531-4, Public transport - Service interface for real-time information relating to public transport operations - Part 4: Functional service interfaces: Facility Monitoring\nCEN/TS 15531-5, Public transport - Service interface for real-time information relating to public transport operations - Part 5: Functional service interfaces - Situation Exchange\nEtude CAMERA: http://www.predim.org/IMG/pdf/rapport_etude_camera_2015.pdf (note: cette étude ne porte que sur les modes de surface)\nEN 28701, Intelligent transport systems - Public transport - Identification of Fixed Objects in Public Transport (IFOPT)\nStandard CNIG Accessibilité du cheminement en voirie : http://cnig.gouv.fr/IMG/documents_wordpress/2022/05/220504_Standard_CNIG_Accessibilite_v2022-05.pdf (v2021-10 rev. 2022-05)\nDocumentation collaborative sur la cartographie des cheminements piétons et de l\u0026rsquo;accessibilité dans OpenStreetMap : https://wiki.openstreetmap.org/wiki/FR:Cheminements_pi%C3%A9tons\nRègles de conversion vers le présent profil, depuis OpenStreetMap et depuis le standard CNIG Accessibilité : https://doc.transport.data.gouv.fr/documentation/normes-europeennes/accessibilite\n","permalink":"https://deploy-preview-56--transport-normes.netlify.app/normes/netex/accessibilite/","summary":"Avant-propos\nL’harmonisation des pratiques dans l’échange des données relatives aux offres de transport est essentielle :\n  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) ;\n  pour les AOT, de manière à fédérer des informations homogènes venant de chacun des opérateurs de transports qui travaillent pour elles. L’harmonisation des échanges, et en particulier le présent profil, pourra le cas échéant être imposée par voie contractuelle.","title":"Profil NeTEx accessibilité France - v2.4"},{"content":"Avant-propos\nL’harmonisation des pratiques dans l’échange des données relatives aux offres de transport est essentielle :\n  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) ;\n  pour les AOT, 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 ;\n  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) ;\n  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 ;\n  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 le profil d’échange Profil NeTEx Tarifs : \u0026ldquo;format de référence pour l\u0026rsquo;échange de données de description des offres tarifaires\u0026rdquo; (issu des travaux NeTEx, et Transmodel) qui aujourd’hui fait consensus dans les groupes de normalisation (CN03/GT7 – Transport public / information voyageur).\nCe document a été validé et publié comme suit :\n travaux de révision : 2024-2025 date de validation en CN03 : 19 décembre 2025 date de publication : 6 mars 2026  Introduction\nLe présent document fait partie du profil France de NeTEx.\nNeTEx (CEN/TS 16614 series) propose un format et des services d\u0026rsquo;échange de données de description de l\u0026rsquo;offre de transport planifiée, basé sur Transmodel (EN 12896 series) et l’ancienne norme IFOPT (EN 28701). NeTEx permet non seulement d\u0026rsquo;assurer les échanges pour les systèmes d\u0026rsquo;information voyageur mais traite aussi l’ensemble des concepts nécessaires en entrée et sortie des systèmes de planification de l\u0026rsquo;offre (graphiquage, etc.) et des SAE (Systèmes d’Aide à l’Exploitation).\nNeTEx se décompose en six parties:\n  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)\n  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)\n  Partie 3 : information tarifaire (uniquement à vocation d’information voyageur)\n  Partie 4 : profil européen pour l\u0026rsquo;information voyageur (EPIP)\n  Partie 5 : nouveaux modes (les véhicules partagés en libre service, les courses partagées, etc.)\n  Partie 6 : profil européen pour l\u0026rsquo;information voyageur en lien avec l\u0026rsquo;accessibilité (EPIAP)\n  NeTEx a été développé dans le cadre du CEN/TC 278/WG 3/SG 9 piloté par la France. Les premières publications de NeTEx datent de 2014 et les plus récentes de mars 2026.\nIl faut noter que NeTEx a été l\u0026rsquo;occasion de renforcer les liens du CEN/TC278/WG3 avec le secteur ferrovaire, en particulier grâce à la participation de l\u0026rsquo;ERA (Agence Européen du Rail, qui a intégré NeTEx dans la directive Européenne 454/2011 TAP-TSI ) et de l\u0026rsquo;UIC (Union International des Chemins de fer).\nLes 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.\nIl en résulte des normes qui sont relativement volumineuses et dont le périmètre dépasse souvent largement les besoins d\u0026rsquo;une utilisation donnée. Ainsi, à titre d\u0026rsquo;exemple, SIRI propose toute une série d\u0026rsquo;options ou de mécanismes dont la vocation est d\u0026rsquo;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\u0026rsquo;ils sont dès aujourd\u0026rsquo;hui pertinents en Suisse ou en Allemagne, sont pratiquement inexistants en France.\nDe plus, un certain nombre de spécificités locales ou nationales peuvent amener à préciser l\u0026rsquo;usage ou la codification qui sera utilisée pour certaines informations. Par exemple, les Anglais disposant d\u0026rsquo;un référentiel national d\u0026rsquo;identification des points d\u0026rsquo;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.\nEnfin, certains éléments proposés par ces normes sont facultatifs et il convient, lors d\u0026rsquo;une implémentation, de décider si ces éléments seront ou non implémentés.\nL\u0026rsquo;utilisation des normes liées à l\u0026rsquo;implémentation de l\u0026rsquo;interopérabilité pour le transport en commun passe donc systématiquement par la définition d\u0026rsquo;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 :\n  détail des services utilisés,\n  détail des objets utilisés dans un échange,\n  précisions sur les options proposées par la norme,\n  précision sur les éléments facultatifs,\n  précision sur les codifications à utiliser,\n  etc.\n  Ce document présente la partie Tarifs du profil France de NeTEx, tel que défini par le Groupe de Travail dédié à l\u0026rsquo;information voyageur et à l\u0026rsquo;exploitation des services de mobilité (GT7) au sein de la Commission Nationale de normalisation pour le transport public (CN03).\nD\u0026rsquo;autres parties du profil France de NeTEx sont disponibles (arrêts, réseau, horaire, accessibilité, parking). Ils sont tous complémentaires les uns des autres (sans recouvrement) et s\u0026rsquo;appuient tous sur le document: NeTEx - Profil France - Éléments communs. Il conviendra de se référer à ce document pour tous les éléments utilisés dans le présent document, et dont la structure n\u0026rsquo;est pas détaillée.\nCe profil d’échange a pour objectif de décrire et de structurer précisément les éléments nécessaires à une bonne information de description des tarifs de transport public de façon :\n  à pouvoir les présenter d’une manière homogène et compréhensible à l’usager des transports publics sur des supports différents (papier ou Internet),\n  à pouvoir les échanger entre systèmes d’information (systèmes d’information voyageurs et systèmes d’information multimodale, systèmes d’aide à l’exploitation, systèmes de planification, systèmes billettiques, etc.).\n  Les éléments présentés ci-dessous couvrent donc l’ensemble des concepts propres à la description des offres tarifaires (on notera que le prix n’est que l’un des élément possible de description de l’offre tarifaire, et que le prix n’est pas toujours connu, notamment dans le cas des tarifs dits « yieldés »).\nNOTE IMPORTANTE Ce document étant un profil d\u0026rsquo;échange de NeTEx, il ne se substitue en aucun cas à NeTEx, et un minimum de connaissance de NeTEx sera nécessaire à sa bonne compréhension.\nDomaine d\u0026rsquo;application Le présent document est le profil de la CEN/TS 16614 (NeTEx) pour l\u0026rsquo;échange de données de description de l\u0026rsquo;offre en France et permet de décrire les tarifs des transports publics et la manière dont ils pourront être structurés pour des échanges entre systèmes d\u0026rsquo;information ainsi que pour leur présentation aux voyageurs.\nCe sont les tarifications des services de transport au sens large qui sont pris en compte dans ce contexte, et non la structure de l\u0026rsquo;offre de transport (voir les autres parties du profil pour cela).\nRéférences normatives Les documents de référence suivants sont indispensables pour l\u0026rsquo;application du présent document. Pour les références datées, seule l\u0026rsquo;édition citée s\u0026rsquo;applique. Pour les références non datées, la dernière édition du document de référence s\u0026rsquo;applique (y compris les éventuels amendements).\nCEN/TS 16614-1, Network and Timetable Exchange (NeTEx) — Part 1: Public transport network topology exchange format\nCEN/TS 16614-2, Network and Timetable Exchange (NeTEx) — Part 2: Public transport scheduled timetables exchange format\nCEN/TS 16614-3, Network and Timetable Exchange (NeTEx) — Part 3: Public transport fares exchange format\nEN 12896, Road transport and traffic telematics - Public transport - Reference data model (Transmodel)\nTermes et définitions Pour les besoins du présent document, les termes et définitions suivants s\u0026rsquo;appliquent. Ils sont directement issus de Transmodel et NeTEx. Pour une information complète, il conviendra toutefois de se référer au document normatif.\nNOTE Les définitions ci-dessus sont des traductions littérales du document normatif. Seules les définitions spécifiques du profil tarif sont proposées ici, celles relatives aux autres profils sont disponibles dans les profils correspondants.\nACCESS RIGHT IN PRODUCT (DROIT D’ACCÈS D’UN PRODUIT tarifaire) Un ÉLÉMENT VALIDABLE (VALIDABLE ELEMENT) faisant partie d’un PRODUIT TARIFAIRE PRÉDÉFINI (PRE-ASSIGNED FARE PRODUCT), éventuellement incluant un numéro d’ordre dans un ensemble d’ ÉLÉMENTs VALIDABLEs regroupés pour définir les droits d’accès de ce PRODUIT TARIFAIRE PRÉDÉFINI\nACCESS RIGHT PARAMETER ASSIGNMENT (AFFECTATION DES PARAMÈTRES DES DROITS D\u0026rsquo;ACCÈS) L\u0026rsquo;affectation d\u0026rsquo;un paramètre tarifaire (faisant référence à la géographie, au temps, à la qualité ou à l\u0026rsquo;usage) à un élément d\u0026rsquo;un système tarifaire (droit d\u0026rsquo;accès, accès validé, moyen de contrôle, etc.).\nAMOUNT OF PRICE UNIT (MONTANT D’UNITÉS TARIFAIRE) PRODUIT TARIFAIRE constitué d\u0026rsquo;une valeur stockée d\u0026rsquo;UNITÉS TARIFAIRE : une somme d\u0026rsquo;argent sur un porte-monnaie électronique, une quantité d\u0026rsquo;unités transport sur une carte, etc.\nBORDER POINT (POINT FRONTALIER) Un POINT sur le Réseau marquant une limite pour le calcul tarifaire. Peut ou non être un POINT D\u0026rsquo;ARRÊT PLANIFIÉ.\nCAPPED DISCOUNT RIGHT (REDUCTION PAR PLAFONNEMENT) Spécialisation du DROIT A REDUCTION utilisé pour les tarifications de type « pay-as-you-go », où une fois qu\u0026rsquo;un certain niveau de consommation a été atteint dans un intervalle de temps donné, un plafond (tel que spécifié par une ou plusieurs RÈGLES DE PLAFONNEMENT) est appliqué, par exemple en limitant le coût, pour toute utilisation au cours d’une même journée, au prix d\u0026rsquo;un passe journalier.\nCELL (CELLULE) Une combinaison unique de caractéristique au sein d\u0026rsquo;un GRILLE TARIFAIRE, utilisée pour associer un prix à un élément de tarif.\nCHARGING MOMENT (MOMENT DE PAIMENT) Une classification des PRODUITS TARIFAIRES selon le mode de paiement et le type de compte : pré-paiement à usage unique, pré-paiement avec débit sur carte, pré-paiement sans enregistrement de consommation (pass), post- paiement etc\u0026hellip;\nCHARGING POLICY (POLITIQUE DE PAIEMENT) Paramètre régissant le montant minimum et le crédit autorisé lors de la consommation d\u0026rsquo;un PRODUIT TARIFAIRE.\nCLASS OF USE (CLASSE D’UTILISATION) Une classification des tarifs et autres classes de services par catégorie d\u0026rsquo;utilisateur autorisé à les utiliser.\nCOMMERCIAL PROFILE (PROFIL COMMERCIALE) Catégorisation d\u0026rsquo;utilisateurs en fonction de leurs relations commerciales avec l\u0026rsquo;opérateur (fréquence d\u0026rsquo;utilisation, montant d\u0026rsquo;achat…), souvent utilisée pour les remises.\nCOMPANION PROFILE (PROFIL D’ACCOMPAGNATEUR) Le nombre et les caractéristiques des personnes autorisées à voyager en tant qu’accompagnateur d\u0026rsquo;un autre PROFIL UTILISATEUR.\nDISTANCE MATRIX ELEMENT (ÉLÉMENT DE MATRICE DE DISTANCES) Une cellule d\u0026rsquo;une matrice origine-destination pour les ZONES TARIFAIRES ou POINTS D\u0026rsquo;ARRÊT, exprimant une distance tarifaire pour le trajet correspondant : valeur en km, nombre d\u0026rsquo;unités tarifaires etc.\nDISTRIBUTION ASSIGNMENT (AFFECTATION DE DISTRIBUTION) Une affectation du CANAL DE DISTRIBUTION par lequel un produit peut ou non être distribué.\nDISTRIBUTION CHANNEL (CANAL DE DISTRIBUTION) Un type de point de vente pour la vente d\u0026rsquo;un produit.\nDISTRIBUTION VALIDITY PARAMETERS (PARAMÈTRE DE VALIDITÉ POUER LA DISTRIBUTION) Un type de PARAMÈTRE DE VALIDITÉ lié à la distribution des produits tarifaires.\nELIGIBILITY CHANGE POLICY (POLITIQUE POUR LE CHANGEMENT D’ÉLIGIBILITÉ) La politique à appliquer si l\u0026rsquo;éligibilité d\u0026rsquo;un utilisateur, en tant que PROFIL UTILISATEUR, change.\nENTITLEMENT GIVEN (DROIT OBTENU) Paramètre indiquant si un PRODUIT TARIFAIRE particulier donne le droit d\u0026rsquo;acheter ou d\u0026rsquo;utiliser un droit d\u0026rsquo;accès.\nENTITLEMENT PRODUCT (PRODUIT OUVRANT DES DROITS) Une condition préalable pour accéder à un service ou pour acheter un PRODUIT TARIFAIRE délivré par une organisation qui peut ne pas être un opérateur transport public (par exemple, une carte militaire).\nENTITLEMENT REQUIRED (DROIT REQUIS) Paramètre indiquant si un PRODUIT TARIFAIRE nécessite un droit ou autorisation particulière pour pouvoir l’acheter ou l’utiliser.\nEXCHANGING (ÉCHANGE) Si et comment le droit d\u0026rsquo;accès peut être échangé contre un autre droit d\u0026rsquo;accès.\nFARE DEMAND FACTOR (FACTEUR TARIFAIRE LIÉ À LA DEMENADE) Un ensemble nommé de paramètres définissant une période de déplacement avec un prix donné, par exemple heures creuses, heures pleines, super heures creuses, etc.\nFARE ELEMENT IN SEQUENCE (D’ÉLÉMENT TARIFAIRE EN SÉQUENCE) Un ÉLÉMENT TARIFAIRE faisant partie d\u0026rsquo;un ensemble, y compris son ordre éventuel dans la séquence d\u0026rsquo;ÉLÉMENTS TARIFAIRE.\nFARE POINT IN JOURNEY PATTERN (POINT TARIFAIRE DANS UN PARCOURS) Un POINT SUR PARCOURS qui représente le début ou la fin d\u0026rsquo;une SECTION TARIFAIRE, ou un point utilisé pour définir une CONTRAINTE DE SÉRIE.\nFARE PRICE (PRIX) Caractéristiques de prix définies par défaut caractérisant les différents GROUPES DE PRIX.\nFARE PRODUCT (PRODUIT TARIFAIRE) Un élément commercialisable immatériel (droits d\u0026rsquo;accès, droits de remise, etc.), propre à un MOMENT DE PAIEMENT.\nFARE QUOTA FACTOR (FACTEUR DE QUOTA TARIFAIRE) Un ensemble paramètres définissant un nombre maximal de tarifs disponibles pour une dénomination donnée.\nFARE SCHEDULED STOP POINT (POINT D’ARRÊT TARIFAIRE) Une spécialisation de POINT D\u0026rsquo;ARRÊT PLANIFIÉ décrivant un arrêt avec des caractéristiques tarifaires en lien avec l’itinéraire.\nFARE SECTION (SECTION TARIFAIRE) Subdivision d\u0026rsquo;un PARCOURS constitué de POINTs consécutifs sur ce PARCOURS, utilisée pour définir un élément de la structure tarifaire.\nFARE STRUCTURE ELEMENT (ÉLÉMENT DE STRUCTURE TARIFAIRE) Une séquence ou un ensemble d\u0026rsquo;éléments tarifaires auxquels sont appliquées des règles de limitation des droits d\u0026rsquo;accès et de calcul des prix (structure tarifaire).\nFARE STRUCTURE ELEMENT IN SEQUENCE (ÉLÉMENTS DE STRUCTURE TARIFAIRE EN SÉQUENCE) Un ÉLÉMENT DE STRUCTURE TARIFAIRE faisant partie d\u0026rsquo;un ÉLÉMENT VALIDABLE, y compris son ordre éventuel dans la séquence d\u0026rsquo;ÉLÉMENTS DE STRUCTURE TARIFAIRE formant cet ÉLÉMENT VALIDABLE, et son éventuelle limitation quantitative.\nFARE TABLE (GRILLE TARIFAIRE) Un regroupement de prix pouvant être associé à tout ou partie des éléments suivants : ÉLÉMENT DE MATRICE DE DISTANCE, ÉLÉMENT DE STRUCTURE TARIFAIRE INTERVALLE GÉOGRAPHIQUE, GROUPE DE PARAMÈTRE DE DROIT D\u0026rsquo;ACCÈS, CLASSE D\u0026rsquo;UTILISATION, OPÉRATEUR, MODE VÉHICULE, PRODUIT TARIFAIRE.\nFARE VALIDITY PARAMETERS (PARAMETRES DE VALIDITÉ TARIFAIRE) Un type de PARAMÈTRE DE VALIDITÉ lié aux produits tarifaires et/ou à leur distribution.\nFARE ZONE (ZONE BILLÉTIQUE) Specialisation d’une ZONE TARIFAIRE pour inclure les SECTIONs TARIFAIREs.\nFREQUENCY OF USE (FÉQUENCE D’UTILISATION) Limites de fréquence d\u0026rsquo;utilisation d\u0026rsquo;un PRODUIT TARIFAIRE (ou d\u0026rsquo;un de ses composants) ou d\u0026rsquo;une OFFRE A LA VENTE pendant une PÉRIODE DE VALIDITÉ déterminée. Il peut y avoir des tarifications différentes selon la fréquence de consommation du droit au cours de la période.\nFULFILMENT METHOD (MÉTHODE DE DÉLIVRANCE) Le moyen par lequel le billet est remis au CLIENT, par ex. en ligne, collecte, etc.\nGENERIC PARAMETER ASSIGNMENT (AFFECTATION GÉNÉRIQUE DES PARAMÈTRES) Une AFFECTATION DE PARAMETRES DE VALIDITE spécifiant des droits d\u0026rsquo;accès génériques pour une classe de produits (par exemple une limite de tranche horaire - 7h à 10h - pour les trajets effectués avec un titre étudiant).\nGEOGRAPHICAL INTERVAL (INTERVAL GÉOGRAPHIQUE) Un intervalle géographique précisant les droits d\u0026rsquo;accès pour les ÉLÉMENTS DE STRUCTURE TARIFAIRE dans la plage de cet intervalle : 0-5 km, 4-6 zones etc.\nGEOGRAPHICAL STRUCTURE FACTOR (FACTEUR D’INTERVAL GÉOGRAPHIQUE) La valeur d\u0026rsquo;un INTERVALLE GEOGRAPHIQUE ou d\u0026rsquo;un ELEMENT MATRICE DE DISTANCE exprimée par une UNITÉ GEOGRAPHIQUE.\nGEOGRAPHICAL UNIT (UNITÉ GÉOGAPHIQUE) Une unité de calcul des tarifs géographiques dégressifs.\nGROUP OF DISTANCE MATRIX ELEMENTS (GROUPE D’ÉLÉMENT MATRICES DE DISTANCE) Un regroupement d\u0026rsquo;ÉLÉMENTS DE MATRICE DE DISTANCE. Peut être utilisé pour fournir des paires Origine/Destination réutilisables (et leur associer un PRIX).\nGROUP OF SALES OFFER PACKAGES (GROUPE D’OFFRES À LA VENTE) Un groupement d’OFFREs À LA VENTE\nGROUP TICKET (TICKET DE GROUPE) Le nombre et les caractéristiques des personnes autorisées à voyager en plus du titulaire d\u0026rsquo;un droit d\u0026rsquo;accès.\nLUGGAGE ALLOWANCE (BAGAGES AUTORISÉS) Le nombre et les caractéristiques (poids, volume) des bagages qu\u0026rsquo;un titulaire d\u0026rsquo;un droit d\u0026rsquo;accès est autorisé à transporter.\nMINIMUM STAY (SÉJOUR MINIMUM) Détails de tout séjour minimum à la destination requis pour utiliser le produit.\nNETWORK VALIDITY PARAMETERS (PARAMETRES DE VALIDITÉ DU RESEAU) Un type de PARAMÈTRE DE VALIDITÉ lié à la structure du réseau.\nORGANISATIONAL VALIDITY PARAMETERS (PARAMETRES DE VALIDITÉ ORGANISATIONELS) Un type de PARAMÈTRE DE VALIDITÉ relatifs à l\u0026rsquo;organisation.\nPENALTY POLICY (POLITIQUE D’AMENDE) Politique concernant différents aspects des frais de pénalité, par exemple entrée répétée dans la même gare, ne pas avoir de billet, etc.\nPLACE VALIDITY PARAMETERS (PARAMETRES DE VALIDITÉ DES LIEUX) Un type de PARAMÈTRE DE VALIDITÉ relatifs aux sites du réseau.\nPRE-ASSIGNED FARE PRODUCT (PRODUIT TARIFAIRE PRÉDÉFINI) UN PRODUIT TARIFAIRE composé d\u0026rsquo;un ou plusieurs ÉLÉMENTS VALIDABLES, spécifiques à un MODE DE PAIEMENT.\nPRICEABLE OBJECT (OBJET AVEC PRIX) Un élément qui peut avoir un PRIX.\nPRODUCT VALIDITY PARAMETERS (PARAMETRES DE VALIDITÉ DU PRODUIT) Un type de PARAMÈTRE DE VALIDITÉ lié aux produits tarifaires.\nPURCHASE WINDOW (FENÊTRE D’ACHAT) Période pendant laquelle le produit doit être acheté.\nQUALITY STRUCTURE FACTOR (FACTEUR QUALITATIF) Un facteur influençant la définition des droits d\u0026rsquo;accès ou le calcul des prix, en fonction de la qualité : seuil de congestion du trafic, réservation anticipée/tardive, etc.\nQUALITY STRUCTURE FACTOR PRICE (PRIX DE FACTEUR QUALITATIF) Un ensemble de toutes les caractéristiques de prix possibles d\u0026rsquo;un FACTEUR QUALITATIF, par ex. prix total par défaut, etc.\nREFUNDING (REMBOURSEMENT) Indique si et comment le produit peut être remboursé.\nREPLACING (REMPLACEMENT) Indique si et comment le produit peut être remplacé.\nRESELLING (REVENTE) Conditions de revente (c\u0026rsquo;est-à-dire pour échange ou remboursement) attachées au produit.\nRESERVING (RESERVATION) Indiquer si le droit d\u0026rsquo;accès nécessite une réservation.\nRESIDENTIAL QUALIFICATION (QUALIFICATION RÉSIDENTIELLE) Décrit une exigence de résidence dans une certaine zone géographique.\nROUND TRIP (ALLER RETOUR) Propriétés relatives à l\u0026rsquo;usage pour un aller simple ou un aller-retour d\u0026rsquo;un droit d\u0026rsquo;accès.\nROUTING (ITINÉRAIRE) Limitations d\u0026rsquo;un droit d\u0026rsquo;accès relative à l’itinéraire réalisable.\nROUTING VALIDITY PARAMETERS (PARAMETRE DE VALIDITE DE L’ITINERAIRE) Un type de PARAMÈTRE DE VALIDITÉ lié à un itinéraire spécifique.\nSALE DISCOUNT RIGHT (DROIT A REDUCTION) PRODUIT TARIFAIRE (FARE PRODUCT) qui permet à son porteur de bénéficier d’une déduction lors de l’achat d’OFFREs A LA VENTE (SALES OFFER PACKAGE) particulières.\nSALE OFFER ENTITLEMENT GIVEN (DROIT D’ACCES A UNE OFFRE) DROIT accordé pour utiliser une OFFRE A LA VENTE.\nSALE OFFER ENTITLEMENT REQUIRED (DROIT NÉCESSAIRE POUR ACCEDER A L’OFFRE) DROIT nécessaire pour utiliser une OFFRE A LA VENTE.\nSALES NOTICE ASSIGNMENT (AFFECTATION D’UNE NOTE) Affectation d’une NOTE à un une OFFRE A LA VENTE ou à un GROUPE D’OFFREs A LA VENTE.\nSALES OFFER PACKAGE (OFFRE A LA VENTE) Une offre à la vente dans son ensemble, composé d\u0026rsquo;un ou plusieurs PRODUITS TARIFAIRES matérialisé grâce à un ou plusieurs DOCUMENTS DE VOYAGE. Les PRODUITS TARIFAIRES peuvent être soit directement attachés aux DOCUMENTS DE VOYAGE, soit être rechargeables sur les DOCUMENTS DE VOYAGE.\nSALES OFFER PACKAGE ELEMENT (ÉLÉMENT D’OFFRE A LA VENTE) L\u0026rsquo;affectation d\u0026rsquo;un PRODUIT TARIFAIRE à un TYPE DE DOCUMENT DE VOYAGE afin de définir une OFFRE A LA VENTE, réalisé sous forme d\u0026rsquo;affectation fixe (impression, stockage magnétique etc.) ou par la possibilité de recharger le PRODUIT TARIFAIRE sur le TYPE DU DOCUMENT DE VOYAGE.\nSALES OFFER PACKAGE PRICE (PRIX D’UNE OFFRE A LA VENTE) Un ensemble de toutes les caractéristiques de prix possibles d\u0026rsquo;une OFFRE A LA VENTE : prix total par défaut, etc.\nSCOPING VALIDITY PARAMETERS (CIBLAGE DES PARAMÈTRES DE VALIDITÉ) Regroupement des affectations de PARAMETRE DE VALIDITÉ aux éléments pour les associer à un ensemble de cibles (éléments auxquels ils s’appliquent).\nSEATING VALIDITY PARAMETERS (PARAMÈTRES DE VALIDITÉ DES SIÈGES) Type de PARAMÈTRE DE VALIDITÉ lié aux caractéristiques des sièges (par exemple, siège d\u0026rsquo;autocar ou de passager).\nSERIES CONSTRAINT (CONTRAINTE DE SÉRIE) Extension d\u0026rsquo;un ÉLÉMENT DE MATRICE DE DISTANCE (une cellule d\u0026rsquo;une matrice origine-destination pour les ZONES TARIFAIRES ou les POINTS D\u0026rsquo;ARRÊT PLANIFIÉS) exprimant une distance tarifaire pour le trajet correspondant (valeur en km, nombre d\u0026rsquo;unités tarifaires, etc.), limitée à des itinéraires spécifiques. Les CONTRAINTES DE SÉRIE sont principalement utilisées pour les tarifs ferroviaires.\nSERVICE ACCESS RIGHT (DROIT D’ACCÈS AU SERVICE) Un élément commercialisable immatériel dédié à l\u0026rsquo;accès à certains services.\nSERVICE VALIDITY PARAMETERS (PARAMÈTRE DE VALIDITÉ DU SERVICE) Un type de PARAMÈTRE DE VALIDITÉ lié aux caractéristiques du service (par exemple, la classe).\nSITE VALIDITY PARAMETERS (PARAMÈTRE DE VALIDITÉ DU SITE) Un type de PARAMÈTRE DE VALIDITÉ lié aux caractéristiques du SITE.\nSTART TIME AT STOP POINT (HORAIRE DE DÉBUT AU POINT D’ARRÊT) Heure à laquelle une tranche horaire tarifaire (tranche horaire pointe, heures creuses) commence pour les trajets au départ d\u0026rsquo;une gare particulière.\nSTEP LIMIT (LIMITATION DU NOMBRE D’ÉTAPES) Paramètre géographique limitant les droits d\u0026rsquo;accès par comptage d\u0026rsquo;arrêts, de tronçons ou de zones.\nSUBSCRIBING (SOUSCRIPTION) Paramètres régissant la souscription à un produit permettant un paiement à intervalles réguliers.\nSUPPLEMENT PRODUCT (SUPPLÉMENT) PRODUIT TARIFAIRE PRÉAFFECTÉ qui offrira un droit supplémentaire lorsqu\u0026rsquo;il est utilisé avec (en complément) d\u0026rsquo;un autre (siège réservé, surclassement de deuxième à première classe, etc.). PRODUIT SUPPLÉMENTAIRE signifie aussi généralement prix de supplément.\nSUSPENDING (SUSPENSION) Conditions de suspension d\u0026rsquo;un PRODUIT TARIFAIRE, par ex. forfait période ou abonnement.\nTARIFF (TARIF) Un tarif particulier, décrit par une combinaison de paramètres.\nTARIFF VALIDITY PARAMETERS (PARAMÈTRES DE VALIDITÉ DU TARIF) Un type de PARAMÈTRE DE VALIDITÉ lié aux TARIFs.\nTARIFF ZONE (ZONE TARIFAIRE) Une ZONE utilisée pour définir une structure tarifaire zonale dans un système de comptage de zones ou de matrice de zones.\nTEMPORAL VALIDITY PARAMETERS (PARAMÈTRES DE VALIDITÉ TEMPORELS) Regroupement des paramètres de validité temporelle.\nTHIRD PARTY PRODUCT (PRODUIT TARIFAIRE TIER) PRODUIT TARIFAIRE (non lié au transport public) commercialisé avec un PRODUIT TARIFAIRE de transport public.\nTIME BAND (PLAGE HORAIRE) Une période dans une journée, importante pour certains aspects des transports publics, par ex. conditions de circulation ou catégorie tarifaire similaires.\nTIME DEMAND TYPE (NIVEAU DE SERVICE) Un indicateur des conditions de circulation ou d\u0026rsquo;autres facteurs (heure de pointe, heure creuse, etc.) qui peuvent affecter les temps de parcours ou d\u0026rsquo;attente des véhicules. Elle peut être saisie directement par la planification ou définie par l\u0026rsquo;utilisation de PLAGEs HORAIRES.\nTIME INTERVAL (INTERVAL TEMPOREL) Un intervalle temporel précisant les droits d\u0026rsquo;accès aux ÉLÉMENTS DE STRUCTURE TARIFAIRE dans la plage de cet intervalle : 0-1 heure, 1-3 jours etc.\nTIME STRUCTURE FACTOR (FACTEUR DE STRUCTURE TEMPORELLE) La valeur d\u0026rsquo;un INTERVAL TEMPOREL exprimée par une UNITÉs TEMPORELLE.\nTIME UNIT (UNITÉs TEMPORELLE) Unité temporelle de calcul des tarifs progressifs en fonction du temps.\nTRANSFERABILITY (TRANSFÉRABILITÉ) Le nombre et les caractéristiques des personnes autorisées à utiliser le service de transport public à la place du client d\u0026rsquo;origine.\nTYPE OF CONCESSION (TYPE DE CONCESSION) Une classification du PROFIL D\u0026rsquo;UTILISATEUR par type de personne éligible pour y correspondre.\nTYPE OF FARE PRODUCT (TYPE DE PRODUIT TARIFAIRE) Classification de PRODUIT TARIFAIRE.\nTYPE OF PAYMENT METHOD (TYPE DE MÉTHODE DE PAIEMENT) Une classification du mode de paiement (par exemple, espèces, carte de crédit, carte de débit, carte de voyage, carte de voyage sans contact, téléphone portable, jeton, etc.).\nTYPE OF TRAVEL DOCUMENT (TYPE DE DOCUMENT DE VOYAGE) Une classification des DOCUMENTS DE VOYAGE exprimant leur fonctionnement et les caractéristiques fonctionnelles locales propres à l\u0026rsquo;opérateur. Des TYPEs DE DOCUMENTS DE VOYAGE comme par ex. ticket jetable, bloc ticket jetable, carte de valeur, porte-monnaie électronique permettant l\u0026rsquo;accès, carte de crédit de transport en commun, etc. peuvent être utilisés pour définir ces catégories.\nUSAGE DISCOUNT RIGHT (DROIT À RÉDUCTION LIÉ À L’USAGE) PRODUIT TARIFAIRE permettant à un client de bénéficier de remises lors de la consommation d\u0026rsquo;ÉLÉMENTS VALIDABLES.\nUSAGE PARAMETER (PARAMÈTRE D’UTILISATION) Paramètre utilisé pour spécifier l\u0026rsquo;utilisation d\u0026rsquo;une OFFRE À LA VENTE ou d\u0026rsquo;un PRODUIT TARIFAIRE.\nUSAGE VALIDITY PERIOD (PÉRIODE DE VALIDITÉ D’UTILISATON) Une limitation dans le temps de la validité d\u0026rsquo;un PRODUIT TARIFAIRE ou d\u0026rsquo;une OFFRE À LA VENTE. Il peut être composé d\u0026rsquo;une durée standard (par exemple 3 jours, 1 mois) et/ou de dates et heures de début/fin fixes.\nUSER PROFILE (PROFIL UTILISATEUR) Profil social d\u0026rsquo;un passager, basé sur la tranche d\u0026rsquo;âge, l\u0026rsquo;éducation, la profession, le statut social, le sexe etc., souvent utilisé pour permettre des réductions : 18-40 ans, diplômés, chauffeurs, chômeurs, femmes etc.\nVALIDABLE ELEMENT (ÉLÉMENT VALIDABLE) Une séquence ou un ensemble d\u0026rsquo;ÉLÉMENTS DE STRUCTURE TARIFAIRE, regroupés pour être validés en une seule fois.\nVALIDITY PARAMETER ASSIGNMENT (AFFECTATION DE PARAMÈTRES DE VALIDITÉ) Une AFFECTATION DE PARAMÈTRES DE DROIT D\u0026rsquo;ACCÈS associant un paramètre de perception tarifaire à un PRODUIT TARIFAIRE (ou à l\u0026rsquo;un de ses composants) ou à une OFFRE À LA VENTE.\nSymboles et abréviations AO Autorité Organisatrice de Transports\nPMR Personne à Mobilité Réduite\nExigences minimales liées au code des transports et la règlementation européenne La mise à disposition des données, quand elles existent, est obligatoire et se conforme aux exigences :\n Au niveau européen, du règlement délégué (UE) 2017/1926 de la Commission du 31 mai 2017 modifié par le règlement délégué (UE) 2024/490 de la Commission du 29 novembre 2023 (https://eur-lex.europa.eu/eli/reg_del/2017/1926/2024-03-04), dit \u0026ldquo;règlement MMTIS\u0026rdquo; ; Au niveau français, des articles L. 1115-1 à L. 1115-7 , D. 1115-1, R. 1115-2 à R. 1115-8 et D. 1115-9 à D. 1115-11 du code du transports, notamment créés ou modifiés par les articles 25 et 27 de loi n° 2019-1428 du 24 décembre 2019 d’orientation des mobilités, dites loi « LOM ». Ces mêmes articles de la LOM précise le calendrier de mise à disposition des données.  Le tableau ci-dessous résulte de l’analyse du code des transports et du règlement MMTIS et fournit la liste des concepts concernés dans le présent profil correspondant aux données mentionnées dans l’annexe du règlement. Il sera donc nécessaire de fournir ces données pour être conforme au cadre réglementaire (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).\nNotez que beaucoup de concepts dépendent des concepts issus de Transmodel/NeTEx et sont liés entre eux, soit par héritage, soit par relation au sens UML des termes. Par ailleurs, certains concepts additionnels peuvent relever d’autres parties du profil France précisés dans le tableau le cas échéant.\nDe plus, 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.\nLa 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).\nLes différents concepts retenus 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).\nL’attente du règlement délégué est très vaste et ne permet malheureusement pas de réaliser une sélection de concepts dans ce que propose NeTEx (qui est de plus très vaste).\nSi l’autorité organisatrice des transports décide de sélectionner les titres et les tarifs sur lesquels elle communique de façon exhaustive (description complète même s’ils sont complexes), alors, il y a lieu que cette sélection couvre :\n  Les abonnements et le ou les titres unitaires les plus utilisés, l’ensemble devant représenter au moins 80% des validations.\n  Ainsi que les tarifs sociaux et ceux dédiés aux accompagnateurs de personnes handicapées.\n  Les titres restants pourront être décrits de façon plus succincte, comme indiqué en 6.12, et illustré en B.2 et B.3 en utilisant des « Notices » en lieu et place d’une description structurée et détaillée des droits d’accès et paramètres d’utilisation.\n  Concepts relatifs à la LOM et à la Règlementation Européenne    Niveau Catégorie Détail     2 Information service Where and how to buy tickets for scheduled modes, demand responsive modes and car parking (all scheduled modes and demand-responsive incl. retail channels, fulfilment methods, payment methods)   2 Trip plans, auxiliary information, availability check Basic common standard fares (all scheduled modes): Standard fare structures (point to point including daily and weekly fares, zonal fares, flat fares)   3 Detailed common standard and special fare query (all scheduled modes) Special Fare Products: offers with additional special conditions such as promotional fares, group fares, season passes, aggregated products combining different products and add on products such as parking and travel, minimum stay   3 Detailed common standard and special fare query (all scheduled modes) Basic commercial conditions such as refunding/replacing/exchanging/transferring and basic booking conditions such as purchase windows, validity periods, routing restrictions zonal sequence fares, minimum stay.   3 Information service (all modes) How to book car sharing, taxis, cycle hire etc. (incl. retail channels, fulfilment methods, payment methods)   3 Information service (all modes) Where how to pay for car parking, public charging stations for electric vehicles and refuelling points for CNG/LNG, hydrogen, petrol and diesel powered vehicles (incl. retail channels, fulfilment methods, payment methods)    Description du profil d’échange Conventions de représentation Tableaux d’attributs NOTE les choix de conventions présentées ici ont pour vocation d\u0026rsquo;être cohérents avec ceux réalisés dans le cadre du profil SIRI (Île-de-France Mobilités et CEREMA). De plus tous les profils NeTEx partagent les mêmes conventions.\nLes messages constituant ce profil d\u0026rsquo;é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 :\n   Classification Nom Type Cardinalité Description      Classification : permet de catégoriser l\u0026rsquo;attribut. Les principales catégories sont :\n  PK (Public Key) que l\u0026rsquo;on peut interpréter comme Identifiant Unique : il permet à lui seul d\u0026rsquo;identifier l\u0026rsquo;objet, de façon unique, pérenne et non ambiguë. C\u0026rsquo;est l\u0026rsquo;identifiant qui sera utilisé pour référencer l\u0026rsquo;objet dans les relations.\n  AK (Alternate Key) est un identifiant secondaire, généralement utilisé pour la communication, mais qui ne sera pas utilisé dans les relations.\n  FK (Foreign Key) indique que l\u0026rsquo;attribut contient l\u0026rsquo;identifiant unique (PK) d\u0026rsquo;un autre objet avec lequel il est en relation.\n  GROUP est un groupe XML nommé (ensemble d\u0026rsquo;attributs utilisables dans différents contextes) (cf. http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/#AttrGroups )\n    Nom : nom de l\u0026rsquo;élément ou attribut XSD\n  Type : type de l\u0026rsquo;élément ou attribut XSD (pour certains d\u0026rsquo;entre eux, il conviendra de se référer à la XSD NeTEx)\n  Cardinalité : cardinalité de l\u0026rsquo;élément ou attribut XSD exprimée sous la forme \u0026ldquo;minimum:maximum\u0026rdquo; (\u0026ldquo;0:1\u0026rdquo; pour au plus une occurrence; \u0026ldquo;1:*\u0026rdquo; au moins une occurrence et sans limites de nombre maximal; \u0026ldquo;1:1\u0026rdquo; une et une seule occurrence; etc.).\n  Description : texte de description de l\u0026rsquo;é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).\n  Les textes surlignés en jaune sont ceux présentant une particularité (spécialisation) par rapport à NeTEx : une codification particulière, une restriction d\u0026rsquo;usage, etc.\nLes textes surlignés en bleu correspondent à des éléments de NeTEx non retenus dans le cadre de ce profil (présentés à titre informatif donc). Dans les diagrammes XSD, les éléments et attributs apparaissant sur fond bleu sont ceux qui ne sont pas retenus par le profil (et ce sont donc systématiquement des éléments ou attributs facultatifs de NeTEx).\nLa description XSD utilisée est strictement celle de NeTEx, sans aucune modification (ceci explique notamment que tous les commentaires soient en anglais).\nLes attributs et éléments rendus obligatoires dans le cadre de ce profil restent facultatifs dans l\u0026rsquo;XSD (le contrôle de cardinalité devra donc être réalisé applicativement).\nValeurs 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 :\n  des énumérations fixes définies dans le cadre du schéma XSD NeTEx. Le profil impose alors un sous-ensemble des codes NeTEx.\n  des 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\u0026rsquo;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 ».\n  des instances TypeOfFrame : le profil utilise plusieurs TYPES DE FRAME pour spécifier l\u0026rsquo;utilisation de VERSION FRAME dans le profil.\n  Indication des classes abstraites NeTEx, et Transmodel, utilisent largement l\u0026rsquo;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’existe aucune instance concrète ; seules les sous-classes terminales sont « concrètes ».\nUn inconvénient de l\u0026rsquo;héritage est que si l\u0026rsquo;on veut comprendre les propriétés d\u0026rsquo;une classe concrète unique, il faut également examiner toutes ses super-classes. Pour cette raison, le profil inclut les classes abstraites nécessaires pour comprendre les classes concrètes, même si ces classes abstraites ne sont jamais directement instanciées dans un document NeTEx.\n  Les super-classes sont signalées dans les en-têtes par le suffixe « (abstrait) »\n  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.\n  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.\n  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) ».\nConcepts de base pour la description de l’offre tarifaire Comme pour les autres domaines, NeTEx s’appuie sur le modèle de données Transmodel pour la gestion des offres tarifaires.\nNeTEx fournit un modèle de représentation permettant de décrire les produits tarifaires simples et complexes et les prix associés quand ils sont déterminés à l’avance. Les produits sont assemblés à partir d\u0026rsquo;un ensemble de composants réutilisables de bas niveau, en s\u0026rsquo;appuyant aussi sur d\u0026rsquo;autres ensembles de données communs utilisés pour décrire les arrêts, les lignes et les services planifiés d\u0026rsquo;un réseau de transport ou de réseaux (voir les autres profils NeTEx France).\nLes structures et les produits tarifaires peuvent parfois être complexes et il existe des écarts importants dans la manière de les structurer dans les différents pays européens, mais aussi d’une région à l’autre, ou encore entre les différents opérateurs et les différents modes. Confrontés à ce type de complexité et de diversité, il est nécessaire de séparer soigneusement les concepts de modélisation.\nLe point de départ de la description de ces concepts fondamentaux est la définition des droits d\u0026rsquo;accès, basée sur l\u0026rsquo;utilisation d'éléments de réseau et les éléments temporels. Ceux-ci peuvent être combinés pour former des produits tarifaires, qui sont liés aux documents de voyage afin de constituer des packages de vente aux passagers. Les composants de prix sont liés aux droits d’accès, aux produits tarifaires et aux packages de vente : ils servent à calculer le prix à payer par un client pour une consommation spécifique (vente sur un distributeur automatique, débit d’une carte, post-paiement, par exemple).\nNeTEx, dans sa Partie 3, couvre uniquement la description planifiée de l’offre tarifaire et l’information voyageur qui y est associée (la validation et le contrôle, l’information en temps réel sur les prix de vente quand ils ne sont pas fixes, la disponibilité, ou encore le suivi des ventes, ne font pas partie du périmètre courvert). L’objectif est donc de pouvoir renseigner sur les différents titres disponibles ainsi que leurs variantes, les droits qu’ils ouvrent, les supports utilisés, les conditions d’achat et d’utilisation et le prix, quand il est défini de façon planifiée.\nCouverture de NeTEx pour l’offre tarifaire\nLes principales catégories de données disponibles dans NeTEx sont les suivantes :\n  Description de la structure tarifaire (les éléments de base sur lesquels s’appuie l’offre tarifaire : trajet simple, la durée de voyage autorisée, les origines/destinations, etc.)\n  Description des droits d\u0026rsquo;accès (accès aux réseaux, aux lignes, les possibilités de correspondances, les aller/retour, etc.)\n  Les prix (quand ils sont connus à l’avance, et sinon des informations sur les services pour obtenir les prix variables)\n  Les conditions de vente (possibilités d’échange et remboursement, nécessité d’achat ou réservation à l’avance, etc.)\n  Les modalités de paiement possibles (carte bancaire, liquide, paiement en ligne, etc.)\n  Catégories de donnée gérées (entourée en pointillé bleus) et leur classification\nDifférents droits d\u0026rsquo;accès peuvent être combinés pour former des produits tarifaires (par exemple, un « aller simple » associé à un produit tarifaire appelé « billet simple » ou plusieurs trajets au cours d\u0026rsquo;un mois associés à un produit tarifaire appelé« abonnement mensuel »).\nUn ou plusieurs produits tarifaires peuvent être associés à un « document de voyage » et matérialisés (par exemple, un billet unique en papier permettant uniquement un « aller simple » ou une carte électronique contenant divers produits tarifaires).\nLes combinaisons de produits tarifaires et de documents de voyage sont vendues aux clients en tant que « packages d’offre de vente » (par exemple un carnet de tickets « aller simple »). Chaque package vendu fait partie d\u0026rsquo;un « contrat » individuel avec un client particulier.\nL’offre tarifaire peut être décrite en plusieurs étapes (Figure 9), résumées comme suit :\n  Les éléments pertinents du réseau de transport (arrêts, zones tarifaires, etc.) et les services planifiés (par exemple, des trajets spécifiques avec des restrictions tarifaires, etc.), qui peuvent être utilisés dans un produit sont identifiés (ces informations sont décrites par les profils Arrêts, Réseau et Horaire).\n  Une STRUCTURE TARIFAIRE (FARE STRUCTURE) définie en fonction des éléments spatiaux et temporels utilisés, ainsi que tout autre élément donnant lieu à une tarification particulière (classe d\u0026rsquo;utilisation, types d\u0026rsquo;utilisateurs éligibles, heure de pointe ou non, etc.).\n  Les ensembles de DROITS D\u0026rsquo;ACCÈS (ACCESS RIGHT), comme les droits de déplacement au sein d\u0026rsquo;une zone, les droits de déplacement entre des arrêts, etc. sont définis comme des ÉLÉMENTS VALIDABLEs.\n  Les PRODUITs TARIFAIREs (FARE PRODUCT) combinent des ensembles de droits d\u0026rsquo;accès avec des conditions supplémentaires telles que les conditions commerciales d\u0026rsquo;achat et de remboursement, etc.\n  Les PRODUITs TARIFAIREs sont combinés dans des OFFRES COMMERCIALES (SALES PACKAGE OFFER) décrivant le support sur lequel les produits sont disponibles, ainsi que les éventuelles conditions commerciales et les canaux de vente autorisés.\n  Les PRIX (FARE PRICE) des offres commerciales et éventuelles options sont définies.\n  Un principe fondamental de l’approche NeTEx est que les prix sont séparés des éléments qu’ils tarifent. Un autre principe important consiste à réutiliser les éléments de données existants dans la mesure du possible. Ainsi, par exemple, les mêmes données d\u0026rsquo;arrêt sont utilisées pour les horaires et les tarifs.\nLes éléments non définis dans l’offre des service (réseau et horaires) Même si l’infrastructure et les services sont complètement décrits par les parties 1 et 2 de NeTEx, la description de l’offre tarifaire nécessite de compléter certaines de ces informations avec des attributs propres à la tarification. C’est ce que proposent les spécialisations et compléments d’objet présentés dans ce chapitre.\nNote : en gris, les éléments non instanciés (abstraits) ou issu des autres profils (et donc non décrits dans ce document).\nÉléments du réseau dédié à l’offre tarifaire et billettique – Modèle conceptuel\nNeTEx Partie 1 décrit le concept de ZONE TARIFAIRE, qui peut être utilisé pour définir les zones tarifaires permanentes d\u0026rsquo;un système. Un POINT D\u0026rsquo;ARRÊT PLANIFIÉ donné peut appartenir à une ou plusieurs ZONE TARIFAIREs. Le modèle de ZONE BILLETTIQUE NeTEx Partie 3 les complète des concepts supplémentaires relatifs au réseau qui peuvent être utilisés en plus pour étayer les structures tarifaires.\n  Une ZONE BILLETTIQUE (FARE ZONE) est une spécialisation de ZONE TARIFAIRE qui peut notamment être associée à des SECTION TARIFAIREs.\n  Les SECTION TARIFAIREs permettent à des sections (entre deux arrêts d’une ligne en général) arbitraires du réseau d\u0026rsquo;être associées à une ZONE BILLETTIQUE spécifique.\n  Le POINT D\u0026rsquo;ARRÊT TARIFAIRE (FARE SCHEDULED STOP POINT) spécialise le POINT D\u0026rsquo;ARRÊT PLANIFIÉ avec des attributs supplémentaires liés à la tarification.\n  Un POINT FRONTALIER (BORDER POINT) peut être utilisé pour distinguer certains points (souvent mais pas nécessairement les POINTS D\u0026rsquo;ARRÊT PLANIFIÉs et / ou les POINTS HORAIREs) comme ayant une importance particulière pour le calcul des tarifs internationaux.\n   Une CONSTRAINTE DE SERIE permet de spécifier des contraintes sur des itinéraires spécifiques (pour le domaine ferroviaire), par exemple pour indiquer que les itinéraires peuvent ou doivent passer par des points particuliers. Ils sont principalement utilisés pour le rail et peuvent comprendre un ou plusieurs POINTs TARIFAIRES sur PARCOURS.  FareZone (Zone Billettique) – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; TariffZone ::\u0026gt; FARE ZONE hérite de TARIFF ZONE. Voir profil Réseau.   « PK » id FareZoneIdType 1:1 Identifiant due la FARE ZONE.    ShortName xsd:MultilingualString 0:1 Nom court de la zone visible par les voyageur (par exemple \u0026ldquo;1\u0026rdquo;, \u0026ldquo;2\u0026rdquo;, etc.). Il est recommandé de ne pas inclure le mot \u0026ldquo;Zone\u0026rdquo; (sauf choix de communication).    Name xsd:MultilingualString 1:1 Nom de la zone tarifaire visible par le voyageur. Ce champ est rendu obligatoire dans tous les elements de type GroupOfEntities (cf. partie Elements Communs du profil France). Dans le cas où la zone tarifaire ne dispose que d\u0026rsquo;un nom court, il est recommandé de le diffuser dans les deux champs ShortName et Name.    Description xsd:MultilingualString 0:1 Description textuelle de la zone.   « enum » ZoneTopology ZoneTopologyEnum 0:1 Topologie de la FARE ZONE (en anneaux, tuiles adjacentes, etc.). Voir les valeurs autorisées ci-dessous.   « FK » TransportOranisationRef (TransportOrganisationRef) OperatorRef | AuthorityRef 0:1 Reference à l’OPERATOR associé à la FARE ZONE.   « cntd » fareSections FareSection 0:* FARE SECTIONs de la FARE ZONE.   « cntd » contains TariffZoneRef 0:* Autre zone tarifaire entièrement incluse dans la FARE ZONE.   « cntd » neighbours FareZoneRef 0:* FARE ZONEs adjacentes.    Le tableau suivant fournit les valeurs autorisées pour ZoneTopology (ZoneTopologyEnumeration).\nZoneTopology – Valeurs autorisées    Value Description     overlapping Les zones sont de forme arbitraire et peuvent se chevaucher   honeycomb Les zones sont disposées en nid d\u0026rsquo;abeilles, en mosaïque de polygones réguliers (par exemple, des hexagones, des carrés, etc.) Les zones ne se chevauchent pas.   ring Les zones sont disposées en anneaux. Les zones internes imbriquées sont incluses dans toutes les zones externes contenantes.   annular Les zones sont disposées en anneaux non imbriqués. La zone immédiatement imbriquée est exclue de la zone externe contenante.   nested Les zones sont imbriquées, c\u0026rsquo;est-à-dire que certaines zones sont entièrement contenues dans d\u0026rsquo;autres zones et sont automatiquement incluses si la zone extérieure est sélectionnée. Elles peuvent également chevaucher les zones voisines.   tiled Les zones sont disposées sous forme de tuiles adjacentes ou de formes arbitraires qui ne se chevauchent pas.   sequence Les zones sont disposées en tuiles adjacentes en séquence qui se touchent à l\u0026rsquo;une ou aux deux extrémités. Elles ne se chevauchent pas.   overlappingSequence Les zones sont disposées en tuiles adjacentes en séquence qui se touchent à l\u0026rsquo;une ou aux deux extrémités. Elles peuvent se chevaucher partiellement de sorte que certains arrêts se trouvent dans les deux zones.   other La zone a une topologie autre ou non spécifiée.    Une SECTION TARIFAIRE est subdivision d\u0026rsquo;un PARCOURS composée de POINTs SUR PARCOURS consécutifs, utilisée pour définir un élément de la structure tarifaire.\nFareSection – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; CommonSection ::\u0026gt; FARE SECTION hérite de COMMON SECTION.   « PK » id FareSectionIdType 1:1 Identifiant de la FARE SECTION.    Name MultilingualString 0:1 Nom de la FARE SECTION.   « FK » JourneyPatternRef JourneyPatternRef+ 0:1 Référence au JOURNEY PATTERN sur laquelle cette FARE SECTION s’applique.   « FK » FromFarePointRef FarePointInPatternRef 0:1 Référence au FARE POINT IN PATTERN auquel la FARE SECTION débute.   « FK » ToFarePointRef FarePointInPatternRef 0:1 Référence au FARE POINT IN PATTERN auquel la FARE SECTION se termine.    CommonSection – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; DataManagedObject ::\u0026gt; COMMON SECTION hérite de DATA MANAGED OBJECT.   « PK » id CommonSectionIdType 1:1 Identifiant du la COMMON SECTION.   « cntd » pointsOnSection PointOnSectionr 0:* POINTS de la COMMON SECTION.    Le FareScheduledStopPoint est une spécialisation de POINT D\u0026rsquo;ARRÊT PLANIFIÉ décrivant un arrêt avec des caractéristiques de billettique et de routage. Le POINT D\u0026rsquo;ARRÊT PLANIFIÉ pourra avoir été déjà échangé par ailleurs pour décrire les données d’offre de transport : un jeux de données d’offre tarifaire pourra reprendre l’ensemble des caractéristique de ces POINT D\u0026rsquo;ARRÊT PLANIFIÉs\nFareScheduledStopPoint – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; ScheduledStopPoint ::\u0026gt; FARE SCHEDULED STOP POINT hérite de SCHEDULED STOP POINT.   « PK » id FareStopPointIdType 1:1 Identifiant du FARE SCHEDULED STOP POINT.    SiteFacilitySet SiteFacilitySetRef 0:1 Ensemble des services disponible à ce point    NameOnRouting MultilingualString 0:1 Nom à utiliser pour indiquer la station sur les itinéraires.   « FK » AccountingStopPointRef FareScheduledStopPointRef 0:1 Identifiant d\u0026rsquo;une autre station à utiliser à des fins comptables pour cette station.   « FK » BorderPointRef BorderPointRef 0:1 BORDER POINT associé au FARE SCHEDULED STOP POINT.    Le FarePointInJourneyPattern Un POINT SUR PARCOURS qui représente le début ou la fin d\u0026rsquo;une SECTION TARIFAIRE.\nLes FareStage (dernier attribut), ou point de changement de tarif, sont des points géographiques qui délimitent une frontière de transition pour définir un tarif. Un FareStage peut être à un point d’arrêt ou entre deux arrêts.\nFarePointInPattern – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; PointInJourneyPattern ::\u0026gt; FARE POINT IN PATTERN hérite POINT IN JOURNEY PATTERN. Voir Profil Réseau.   « PK » id FaresPointInPatternIdType 1:1 Identifiant du FARE POINT IN PATTERN.    ScheduledStopPointView ScheduledStopPointView 0:1 Informations dérivées sur le POINT D\u0026rsquo;ARRÊT PLANIFIÉ, telles que son nom – voir Profil Réseau.    IsFareStage xsd:boolean 0:1 Indique si l\u0026rsquo;arrêt est considéré comme une étape de tarification.    Un BorderPoint est un point sur le réseau marquant une limite pour le calcul des tarifs. Peut ou non être un POINT D\u0026rsquo;ARRÊT PLANIFIÉ.\nBorderPoint – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; TimingPoint ::\u0026gt; BORDER POINT hérite de TIMING POINT. Voir Profile Réseau   « PK » id BorderPointIdType 1:1 Identifiant du BORDER POINT.    ShortName MultilingualString 0:1 Nom court du BORDER POINT.    Description MultilingualString 0:1 Description du BORDER POINT.    Une SeriesConstraint est une extension d\u0026rsquo;un ÉLÉMENT DE MATRICE DE DISTANCE, une cellule d\u0026rsquo;une matrice origine-destination pour les ZONE TARIFAIREs ou les POINTs D\u0026rsquo;ARRÊT, exprimant une distance tarifaire pour le trajet correspondant (en tant que valeur en km, nombre d\u0026rsquo;unités tarifaires etc.) et éventuellement une contrainte pour n’autoriser les déplacements que sur des itinéraires spécifiques.\nSeriesConstraint – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; PriceableObject ::\u0026gt; SERIES CONSTRAINT hérite de PRICEABLE OBJECT.  « PK » id SeriesConstraintIdType 1:1 Identifiant de SERIES CONSTRAINT.   PrivateCode PrivateCodeType 0:1 Code privé associé à l'élément.   Itinerary xsd:normalizedString 0:1 Description textuelle schématique de la série (Voir Tap STI 5.1).   SymbolMarkingUsualRoute xsd:normalizedString 0:1 Symbol to use to denote the usual route.  « enum » SeriesType SeriesTypeEnum 0:1 Classification de la SERIES CONSTRAINT. La valeur par défaut est ‘stationToStation’. Voir les valeurs autorisées ci-dessous (voir TAP-TSI pour plus de détail):\n stationToStation (arrêt à arrêt)\n originToBorder (départ à frontière)\n borderToDestination (frontière à destionation)\n border (frontière)\n transit (via)\n   « enum » RoutingType RoutingTypeEnum 0:1 Indique s’il s’agit d'un direct, ou si un changement est requis.  « enum » FareBasis FareBasisEnum 0:1 Base tarifaire utilisée pour établir le prix des séries (itinéraire ou distance)   FirstClassDistance DistanceType 0:1 Distance fictive de la CONTRAINTE DE SÉRIE pour le calcul des tarifs de première classe.   SecondClassDistance DistanceType 0:1 Distance fictive de la CONTRAINTE DE SÉRIE pour le calcul des tarifs de seconde classe.   Discrete xsd:boolean 0:1 Indique si la CONTRAINTE DE SÉRIE ne peut être utilisé que seul ou s'il peut être utilisé dans une chaîne de séries.  « FK » FromConnectionRef ConnectionRef 0:1 Référence à la correspondance associée au départ de la CONTRAINTE DE SÉRIE.  « FK » ToConnectionRef ConnectionRef 0:1 Référence à la correspondance associée à la fin de la CONTRAINTE DE SÉRIE.  « cntd » farePointsInPattern FarePointInPattern 0:* FARE POINTs IN PATTERN faisant partie de la série.  « cntd » journeyPatterns JourneyPatternRef+ 0:* Références aux JOURNEY PATTERN “equivalent” à la SERIES CONSTRAINT.  « cntd » replaces SeriesConstraintRef 0:* Remplace la SERIE spéifiée. (nécessaire pour TAP TSI).    Note : de façon générale, les attributs de prix des différents éléments ne sont pas retenus car le profil fait le choix de systématiser la présentation des prix via des GRILLEs TARIFAIRE (FARE TABLE).\nLa structure tarifaire La définition des éléments de la structure tarifaire repose sur des règles génériques, principalement quantitatives, qui influencent les droits d\u0026rsquo;accès réglementant la consommation des services de transport, et donc le prix qu\u0026rsquo;un passager doit payer pour une consommation spécifique : limitation de la durée ou de la durée des trajets , le nombre de zones traversées, etc.\nCes règles décrivent l\u0026rsquo;utilisation du système de transport et se définissent en termes d\u0026rsquo;espace, de temps et de qualité de service. Ainsi, les paramètres spatiaux, temporels et de qualité seront spécifiés et associés à des ÉLÉMENTS DE STRUCTURE TARIFAIRE.\nLes règles déterminant les droits d\u0026rsquo;accès peuvent être classées en deux grandes catégories :\n  Des règles globales qui permettent de déterminer la validité d\u0026rsquo;une gamme de droits d\u0026rsquo;accès génériques servant de base au calcul du prix de leur consommation. Un tel ensemble de règles est classiquement appelé « structure tarifaire ».\n  Règles de limitation de validité qui consistent à attribuer certains « paramètres de limitation » à des droits d\u0026rsquo;accès spécifiques. Par exemple, un trajet peut être limité par la dernière heure de départ possible, un pass valable uniquement pour les étudiants, etc. Ces limitations sont exprimées par deux catégories de paramètres :\n  « Paramètres de validité », qui affectent les caractéristiques physiques des droits d\u0026rsquo;accès (principalement dans l\u0026rsquo;espace ou dans le temps) ; des exemples de paramètres de limitation de validité sont GROUPE DE LIGNES, TYPE DE JOUR, etc.\n  « CONDITIONS D’UTILISATION », qui affectent l\u0026rsquo;utilisation réelle des droits d\u0026rsquo;accès, tels que PROFIL D\u0026rsquo;UTILISATEUR, FRÉQUENCE D\u0026rsquo;UTILISATION, TRANSFÉRABILITÉ, etc.\n    Une version particulière de la structure tarifaire fixe les valeurs des différents paramètres : cet ensemble de règles avec des valeurs de paramètres bien définies construit un TARIF.\nLa structure tarifaire est composé d\u0026rsquo;un certain nombre de sous-modèles décrits ci-dessous.\n  Le modèle géographique définit des aspects spatiaux de la structure tarifaire.\n  Le modèle temporel définit des aspects temporels de la structure des tarifs.\n  Les FACTEURs DE QUALITÉ définissent d\u0026rsquo;autres aspects qualitatifs de la structure tarifaire.\n  La MATRICE DE DISTANCE montre les origine/destination possibles et leurs caractéristiques.\n  Structure tarifaire – Modèle conceptuel\nElément de structure tarifaire (FareStructureElement) Le FareStructureElement est naturellement l’élément de base de la construction des structures tarifaires.\nFareStructureElement – Element    Classifi­cation Nom Type Cardin­alité Description     ::\u0026gt; ::\u0026gt; PriceableObject ::\u0026gt; FARE STRUCTURE ELEMENT hérite de PRICEABLE OBJECT   « PK » id FareStructureElementIdType 1:1 Identifiant de FARE STRUCTURE ELEMENT   « enum » TariffBasis TariffBasisEnum 0:1 Base tarifaire à utiliser pour cet élément\nFlat (constant)Distance (distance)unitSection (section)zone (zonal)zoneToZone (zone à zone)pointToPoint (point à point)route (itinéraire)tour (tour)group (group)discount (rabais)period (période)free (gratuit)other (autre)\n    TypeOfFareStructureElementRef TypeOfFareStructureElementRef 0:1 Type ouvert associé à l’élément   XGRP FareStructureElementFactorGroup xmlGroup 0:1 FARE STRUCTURE FACTORs associé au FARE STRUCTURE ELEMENT   XGRP FareStructureComponentGroup xmlGroup 0:1 FARE STRUCTURE COMPONENTs associé au FARE STRUCTURE ELEMENT    FareStructureElementFactorGroup – Group    Classifi­cation  Nom Type Cardin­alité Description      Choice       « FK » a GeographicalIntervalRef GeographicalIntervalRef 0:1 Référence au GEOGRAPHICAL INTERVAL associé au FARE STRUCTURE ELEMENT.\nNote : de façon générale on n’utilisera les références que s’il y a effectivement réutilisation (donc ici on préférera geographicalIntervals à GeographicalIntervalRef sauf si les mêmes GeographicalInterval sont utilisés à plusieurs reprises)\n   « cntd » b geographicalIntervals GeographicalInterval / GeographicalIntervalRef 0:* GEOGRAPHICAL INTERVALs associé au FARE STRUCTURE ELEMENT   « cntd » c geographicalStructureFactors GeographicalStructureFactor / GeographicalStructureFactorRef 0:* GEOGRAPHICAL STRUCTURE FACTORs associé au FARE STRUCTURE ELEMENT    Choice       « FK » a TimeIntervalRef TimeIntervalRef 0:1 Référence au TIME INTERVAL associé au FARE STRUCTURE ELEMENT   « cntd » b timeIntervals TimeInterval / TimeIntervalRef 0:* TIME STRUCTURE INTERVALs associé au FARE STRUCTURE ELEMENT.   « cntd » c timeStructureFactors TimeStructureFactor / TimeStructureFactorRef 0:* TIME STRUCTURE FACTORs associé au FARE STRUCTURE ELEMENT    Choice       « FK » a QualityStructureFactorRef QualityStructureFactorRef 0:1 Référence au QUALITY STRUCTURE FACTOR associé au FARE STRUCTURE ELEMENT   « cntd » b qualityStructureFactors QualityStructureFactor / QualityStructureFactor 0:* QUALITY STRUCTURE FACTORs associé au FARE STRUCTURE ELEMENT    Choice       « FK » a DistanceMatrixElementRef DistanceMatrixElementRef 0:1 Référence au DISTANCE MATRIX ELEMENT associé au FARE STRUCTURE ELEMENT   « FK » b distanceMatrixElements DistanceMatrixElement / DistanceMatrixElementRef 0:* DISTANCE MATRIX ELEMENTs associés au FARE STRUCTURE ELEMENT   « FK » c GroupOfDistanceMatrixElementsRef GroupOfDistanceMatrixElementsRef 0:1 Référence au GROUP OF DISTANCE MATRIX ELEMENTs associés au FARE STRUCTURE ELEMENT   « FK » d GroupOfDistanceMatrixElements GroupOfDistanceMatrixElements 0:1 GROUP OF DISTANCE MATRIX ELEMENTs associés au FARE STRUCTURE ELEMENT    FareStructureComponentGroup – Group    Classification Name  Type Cardinality Description     « cntd » fareStructureElementsInSequence  FareStructureElementInSequence 0:* Ensemble de FARE STRUCTURE ELEMENTS IN SEQUENCE constituant FARE STRUCTURE ELEMENT.    Choice Soit plusieurs paramètres enveloppés dans une balise, soit un seul paramètre (une optimisation).      « cntd » a validityParameterAssignments AccessRightParameterAssignment 0:* GENERIC PARAMETER ASSIGNMENTs associés au FARE STRUCTURE ELEMENT.   « cntd » b GenericParameterAssignment GenericParameterAssignment 0:1 GENERIC PARAMETER ASSIGNMENT unique associé au FARE STRUCTURE ELEMENT.   « cntd » c GenericParameterAssignmentInContext GenericParameterAssignment 0:1 GENERIC PARAMETER ASSIGNMENT unique associé au FARE STRUCTURE ELEMENT. Aucun ID ne doit être fourni - sera déduit des valeurs d\u0026rsquo;affectation. (OPTIMISATION).    Les structures tarifaires impliquent souvent la définition de séquences d\u0026rsquo;éléments à utiliser dans un ordre spécifié. Le modèle de structure tarifaire définit un élément abstrait FARE ELEMENT IN SEQUENCE qui est affiné dans d\u0026rsquo;autres sous-modèles pour décrire les aspects séquentiels de la STRUCTURE FARE.\nFareStructureElementInSequence – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; FareElementInSequence ::\u0026gt; FARE STRUCTURE ELEMENT IN SEQUENCE hérite de FARE ELEMENT IN SEQUENCE.   « PK » id FareStructureElementInSequenceIdType 1:1 Identifiant du FARE STRUCTURE ELEMENT IN SEQUENCE.   « FK » FareStructureElementRef FareStructureElementRef 0:1 Référence à unFARE STRUCTURE ELEMENT.    Note : les éventuels ValidityParameterAssignment ne sont pas retenus dans le FareStructureElementInSequence et seront, si nécessaire, placés dans les FareStructureElement « hôte » de la séquence.\nFareElementInSequence – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; VersionedChild ::\u0026gt; FARE ELEMENT IN SEQUENCE hérite de VERSIONED CHILD.   « PK » id FareElementInSequenceIdType 1:1 Identifiant du FARE ELEMENT IN SEQUENCE.   « PK » order xsd:positiveInteger 0:1 Odre de l’élément dans la SEQUENCE.    Name MultilingualString 0:1 Nom du FARE ELEMENT IN SEQUENCE.    Description MultilingualString 0:1 Description du FARE ELEMENT IN SEQUENCE.    IsFirstInSequence xsd:boolean 0:1 Indique si l’élément est le premier de la séquence    IsLastInSequence xsd:boolean 0:1 Indique si l’élément est le dernier de la séquence    AccessNumberIsLimited xsd:boolean 0:1 Indique si le nombre d’accès est limité    AccessNumber xsd:nonNegativeInteger 0:1 Numéro d’accès    Exemples FareStructureElement ne contenant qu’un intervalle temporel\n\u0026lt;FareStructureElement id=\u0026#34;FR-Tarif-Example:FareStructureElement:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;TimeIntervalRef ref=\u0026#34;FR-Tarif-Example:TimeInterval:001:LOC\u0026#34;/\u0026gt; \u0026lt;/FareStructureElement\u0026gt; FareStructureElement contenant des DistanceMatrixElements (origines-destination)\n\u0026lt;FareStructureElement id=\u0026#34;FR-Tarif-Example:FareStructureElement:DM-001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;distanceMatrixElements\u0026gt; \u0026lt;DistanceMatrixElementRef ref=\u0026#34;FR-Tarif-Example:DistanceMatrixElement:AtoB:LOC\u0026#34;/\u0026gt; \u0026lt;DistanceMatrixElementRef ref=\u0026#34;FR-Tarif-Example:DistanceMatrixElement:AtoC:LOC\u0026#34;/\u0026gt; \u0026lt;DistanceMatrixElementRef ref=\u0026#34;FR-Tarif-Example:DistanceMatrixElement:BtoC:LOC\u0026#34;/\u0026gt; \u0026lt;!--etc...--\u0026gt; \u0026lt;/distanceMatrixElements\u0026gt; \u0026lt;/FareStructureElement\u0026gt; FareStructureElement incluant des limitation d’utilisation\n\u0026lt;FareStructureElement id=\u0026#34;LEMAN-EXPRESS:FareStructureElement:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;DistanceMatrixElementRef ref=\u0026#34;FR-Tarif-Example:DistanceMatrixElement:001:LOC\u0026#34;/\u0026gt; \u0026lt;GenericParameterAssignment id=\u0026#34;LEMAN-EXPRESS:GenericParameterAssignment:001:LOC\u0026#34; version=\u0026#34;any\u0026#34; order=\u0026#34;1\u0026#34;\u0026gt; \u0026lt;limitations\u0026gt; \u0026lt;UsageValidityPeriod id=\u0026#34;LEMAN-EXPRESS:UsageValidityPeriod:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;!--Peut être une référence pour mutualiser la définition--\u0026gt; \u0026lt;UsageTrigger\u0026gt;purchase\u0026lt;/UsageTrigger\u0026gt; \u0026lt;!--On a aussi l\u0026#39;option startOutboundRide, etc.--\u0026gt; \u0026lt;StandardDuration\u0026gt;PT180M\u0026lt;/StandardDuration\u0026gt; \u0026lt;/UsageValidityPeriod\u0026gt; \u0026lt;/limitations\u0026gt; \u0026lt;/GenericParameterAssignment\u0026gt; \u0026lt;/FareStructureElement\u0026gt; Règle d’application des caractéristiques (QualityStructureFactor) Les FACTEURs DE QUALITÉ définissent les aspects qualitatifs de la structure tarifaire. Par exemple, le niveau de congestion ou d\u0026rsquo;occupation (par exemple en %) peut influencer le tarif ou une limitation des droits d\u0026rsquo;accès. Certains opérateurs ferroviaires appliquent des tarifs différents si la réservation est effectuée tôt ou tard (par exemple en nombre de jours).\nDeux spécialisations peuvent être utilisées pour des aspects spécifiques : Un FACTEUR DE FREQUENTATION (FARE DEMAND FACTOR) définit une « tranche horaire » pour le voyage, par ex. aux heures de pointe ou aux heures creuses, et un QUOTA TARIFAIRE (FARE QUOTA FACTOR) définit une allocation limitée de sièges disponibles à un prix particulier.\nNote : un QualityStructureFactor peut aussi être référencé par l’AFFECTATION DES PARAMÈTRES DES DROITS D\u0026rsquo;ACCÈS (ACCESS RIGHT PARAMETER ASSIGNMENT, plus précisément par le ValidityParameterAssignment). On n’utilisera le QualityStructureFactor au sein de la structure tarifaire que s’il est véritablement partie intégrante de la structure sur laquelle s’appuie la tarification (par exemple si l’on a systématiquement une prise en compte de la différence heure creuse/heure de pointe). Si par contre il ne s’applique que pour un ou quelques titres ou cartes de réduction (par exemple une carte de réduction valable uniquement en heures creuses), alors le QualityStructureFactor sera référencé par le ValidityParameterAssignment (et en cas d’ambiguïté, c’est cette seconde solution que l’on préférera systèmatiquement)\nQualityStructureFactor – Modèle conceptuel\nQualityStructureFactor – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; FareStructureFactor ::\u0026gt; QUALITY STRUCTURE FACTOR hérite de PRICEABLE OBJECT.   « PK » id QualityStructureFactorIdType 1:1 Identifiant du QUALITY STRUCTURE FACTOR.    Note : dans le cas où les QualityStructureFactor est très spécifique, on en effectuera la description dans une Notice (disponible via l’héritage PriceableObject).\nFareStructureFactor – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; PriceableObject ::\u0026gt; FARE STRUCTURE FACTOR. hérite de PRICEABLE OBJECT***.***   « PK » id FareStructureFactorIdType 1:1 Identifiant du FARE STRUCTURE FACTOR.    PrivateCode PrivateCodeStructure 0:1 Code externe associé au facteur    TypeOfFareStructureFactorRef TypeOfFareStructureFactorRefStructure 0:1 Référence à un TYPE OF FARE STRUCTURE FACTOR.    Note : dans le cas où les FareStructureFactor est très spécifique, on en effectuera la description dans une Notice (disponible via l’héritage PriceableObject).\nFareDemandFactor – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; QualityStructureFactor ::\u0026gt; FARE DEMAND FACTOR hérite de QUALITY STRUCTURE FACTOR.  « PK » id FareDemandFactorIdType 1:1 Identifiant du a FARE DEMAND FACTOR.  « enum » FareDemandType FareDemandTypeEnum 0:1 TIME DEMAND TYPE correspondant au FARE DEMAND FACTOR:\n Peak (heures de pointe)\nMiddle (heures intermédiaires)\noffPeak (heures creuses)\nsuperOffPeak (heures super-creuses)\nnight (nuit)\nspecialEvent (évènement spécial)\n  « FK » TimeDemandTypeRef TimeDemandTypeRef 0:1 TIME DEMAND TYPE correspondant au FARE DEMAND FACTOR  « cntd » startTimesAtStopPoints StartTimeAtStopPoint 0:* Heure de début au SCHEDULED STOP POINTs pour ce FARE DEMAND TYPE.    Le NIVEAU DE SERVICE (TIME DEMAND TYPE) est définie dans la Partie 1 de NeTEx mais n’avait pas été retenu par les profils français jusqu’à maintenant. C’est a la base un indicateur temporel des conditions de circulation (ou taux de remplissage) ou d\u0026rsquo;autres facteurs qui peuvent influer sur la circulation des véhicules, les temps d\u0026rsquo;attente ou la tarification.\nTimeDemandType – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; DataManagedObject ::\u0026gt; TIME DEMAND TYPE hérite de DATA MANAGED OBJECT.\nNote : La période associée au TimeDemandType est définie par sa ValidityCondition (en l’occurrence on utilisera une AvailabilityCondition qui dispose de DayType et TimeBands)\n  « PK » id TimeDemandTypeIdType 1:1 Identifiant du TIME DEMAND TYPE.   Name MultilingualString 0:1 Nom du TIME DEMAND TYPE.   Description MultilingualString 0:1 Description du TIME DEMAND TYPE.  « AK » PrivateCode xsd:normalizedString 0:1 Code alternatif du TIME DEMAND TYPE.    StartTimeAtStopPoint – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; VersionedChild ::\u0026gt; START TIME AT STOP POINT hérite de VERSIONED CHILD.   « PK » id StartTimeAtStopPointIdType 1:1 Identifiant du START TIME AT STOP POINT   « FK » ScheduledStopPointRef ScheduledStopPointRef 1:1 SCHEDULED STOP POINT auquel s’applique l’information.    StartTime xsd:time 0:1 Heure à laquelle la tranche horaire commence à l’arrêt.    EndTime xsd:time 0:1 Heure à laquelle la tranche horaire se termine à l’arrêt.    DayOffset DayOffsetType 0:1 Décalage du jour de l\u0026rsquo;heure de fin par rapport à l\u0026rsquo;heure de début. Zéro indique qu’il n’y a pas de changement de jour.    FareQuotaFactor – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; QualityStructureFactor ::\u0026gt; FARE QUOTA FACTOR hérite de QUALITY STRUCTURE FACTOR.   « PK » id FareQuotaFactorIdType 1:1 Identifiant du FARE QUOTA FACTOR.    NumberOfUnits xsd:integer 0:* Nombre d\u0026rsquo;unités disponibles à un prix donné.    Exemple Le fragment de code suivant montre trois FareDemandFactor pour un trajet à tout moment, en période de pointe et en dehors des heures de pointe. Le trajet en dehors des heures de pointe définit des heures de début distinctes pour certaines zones.\n\u0026lt;qualityStructureFactors\u0026gt; \u0026lt;FareDemandFactor version=\u0026#34;any\u0026#34; id=\u0026#34;tfl:any_time\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Anytimetravel \u0026lt;/Name\u0026gt; \u0026lt;/FareDemandFactor\u0026gt; \u0026lt;FareDemandFactor version=\u0026#34;any\u0026#34; id=\u0026#34;tfl:peak\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Peak time travel \u0026lt;/Name\u0026gt; \u0026lt;validityConditions\u0026gt; \u0026lt;AvailabilityConditionRef ref=\u0026#34;tfl:Peak\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;/validityConditions\u0026gt; \u0026lt;/FareDemandFactor\u0026gt; \u0026lt;FareDemandFactor version=\u0026#34;any\u0026#34; id=\u0026#34;tfl:offPeak\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;off peak time travel\u0026lt;/Name\u0026gt; \u0026lt;Description\u0026gt;Has stop specific overrides\u0026lt;/Description\u0026gt; \u0026lt;!-- If you travel from a station north of Moor Park or Hatch End on a weekday after the times below, your Oyster single fare will count towards the off-peak cap instead of the peak cap. North of Moor Park Station Touch in times Chesham After 09:00 Amersham After 09:10 Chalfont \u0026amp; Latimer After 09:15 Chorleywood After 09:15 Rickmansworth After 09:20 --\u0026gt; \u0026lt;validityConditions\u0026gt; \u0026lt;AvailabilityConditionRef ref=\u0026#34;tfl:OffPeak\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;/validityConditions\u0026gt; \u0026lt;startTimesAtStopPoints\u0026gt; \u0026lt;StartTimeAtStopPoint version=\u0026#34;any\u0026#34; id=\u0026#34;tfl:Chesham\u0026#34;\u0026gt; \u0026lt;ScheduledStopPointRef ref=\u0026#34;tfl:Chesham\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;StartTime\u0026gt;09:00:00\u0026lt;/StartTime\u0026gt; \u0026lt;/StartTimeAtStopPoint\u0026gt; \u0026lt;StartTimeAtStopPoint version=\u0026#34;any\u0026#34; id=\u0026#34;tfl:Amersham\u0026#34;\u0026gt; \u0026lt;ScheduledStopPointRef ref=\u0026#34;tfl:Amersham\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;StartTime\u0026gt;09:10:00\u0026lt;/StartTime\u0026gt; \u0026lt;/StartTimeAtStopPoint\u0026gt; \u0026lt;StartTimeAtStopPoint version=\u0026#34;any\u0026#34; id=\u0026#34;tfl:Chalfont_and_Latimer\u0026#34;\u0026gt; \u0026lt;ScheduledStopPointRef ref=\u0026#34;tfl:Chalfont_and_Latimer\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;StartTime\u0026gt;09:15:00\u0026lt;/StartTime\u0026gt; \u0026lt;/StartTimeAtStopPoint\u0026gt; \u0026lt;StartTimeAtStopPoint version=\u0026#34;any\u0026#34; id=\u0026#34;tfl:Chorleywood\u0026#34;\u0026gt; \u0026lt;ScheduledStopPointRef ref=\u0026#34;tfl:Chorleywood\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;StartTime\u0026gt;09:15:00\u0026lt;/StartTime\u0026gt; \u0026lt;/StartTimeAtStopPoint\u0026gt; \u0026lt;StartTimeAtStopPoint version=\u0026#34;any\u0026#34; id=\u0026#34;tfl:Rickmansworth\u0026#34;\u0026gt; \u0026lt;ScheduledStopPointRef ref=\u0026#34;tfl:Rickmansworth\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;StartTime\u0026gt;09:20:00\u0026lt;/StartTime\u0026gt; \u0026lt;/StartTimeAtStopPoint\u0026gt; \u0026lt;/startTimesAtStopPoints\u0026gt; \u0026lt;/FareDemandFactor\u0026gt; \u0026lt;/qualityStructureFactors\u0026gt; Tarif : version de l’offre Tarifaire (Tariff) Les TARIFs regroupent des ÉLÉMENTs DE STRUCTURE TARIFAIRE soumis à des conditions de validité communes.\nDans la plupart des cas, un seul FACTEUR DE STRUCTURE GEOGRAPHIQUE (resp. TEMPS ou QUALITE) est attaché à chaque ELEMENT DE STRUCTURE TARIFAIRE. Parfois, différents facteurs peuvent s\u0026rsquo;appliquer au même élément, choisis par une règle en fonction de conditions de validité spécifiques. C\u0026rsquo;est le cas par exemple lorsque des tarifs différents sont appliqués en été par rapport aux autres saisons. Plus simplement, la structure tarifaire peut évoluer et une version être remplacée par une autre.\nL\u0026rsquo;entité TARIF décrit une VERSION de tous les paramètres composant une structure tarifaire particulière. Lors de l\u0026rsquo;application des règles tarifaires, un algorithme choisira les paramètres en fonction du TARIF valide au moment spécifié par la demande.\nLe principe est donc très similaire à celui des FRAMEs mais avec, ici, une granularité plus fine (une FRAME pour par exemple contenir plusieurs TARIFs, un pour le bus en période scolaire, un autre pour la période de vacances et un troisième TARIF pour le ferré, etc.).\nTariff – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; DataManagedObject ::\u0026gt; TARIFF hérite de DATA MANAGED OBJECT.   « PK » id TariffIdType 1:1 Identifiant du TARIFF.   XGRP TariffDescriptionGroup xmlGroup 0:1 Éléments descriptifs du TARIFF.    PrivateCode PrivateCodeType 0:1 Identifiant alternatif   XGRP TariffOrganisationGroup xmlGroup 0:1 Éléments descriptifs des ORGANISATIONs opérant TARIFF.   XGRP TariffApplicabilityGroup xmlGroup 0:1 Éléments descriptifs des LINEs opérant TARIFF.   XGRP TariffCalculationGroup xmlGroup 0:1 Éléments descriptifs des paramètre de calcul du TARIFF.   XGRP TariffGeographicalGroup xmlGroup 0:1 Éléments descriptifs des aspects géographiques du TARIFF.   XGRP TariffTimeGroup xmlGroup 0:1 Éléments descriptifs des aspects temporels du TARIFF.   XGRP TariffQualityGroup xmlGroup 0:1 Éléments descriptifs des aspects qualitatifs du TARIFF.   XGRP TariffStructureGroup xmlGroup 0:1 Éléments descriptifs de la structure du TARIFF.   XGRP TariffPricesGroup xmlGroup 0:1 TARIFF PRICE faisant partie du TARIFF.    TariffDescriptionGroup – Group    Classification Name Type Cardinality Description      Name MultilingualString 0:1 Nom du TARIFF.   « cntd » alternativeNames AlternativeName 0:* Nom alternatif TARIFF.    Description MultilingualString 0:1 Description du TARIFF.   « cntd » noticeAssignments NoticeAssignment 0:* NOTICE ASSIGNMENTs associés au TARIFF.   « cntd » documentLinks InfoLink 0:* Liens vers les documents associés au TARIFF.    TariffOrganisationGroup – Group    Classification Name Type Cardinality Description     « FK » OrganisationRef (OrganisationRef) 0:1 ORGANISATION pour laquelle le TARIFF s’applique.   « FK » GroupOfOrganisationsRef GroupOfOrganisationsRef 0:1 GROUP OF ORGANISATIONs auquel le TARIFF s’applique.    TariffApplicabilityGroup – Group    Classification Name Type Cardinality Description     « FK » LineRef LineRef 0:1 LINE à laquelle TARIFF s’applique.   « FK » GroupOfLinesRef GroupOfLinesRef 0:1 GROUP OF LINEs auquel le TARIFF s’applique.    TariffGeographicalGroup – Group    Classification Name Type Cardinality Description     « FK » GeographicalUnitRef GeographicalUnitRef 0:1 Référence au GEOGRAPHICAL UNIT for TARIFF.   « cntd » geographicalIntervals GeographicalInterval 0:* GEOGRAPHICAL INTERVALs associé auTARIFF.   « cntd » geographicalStructureFactors GeographicalStructureFactor 0:* GEOGRAPHICAL STRUCTURE FACTORs associé au TARIFF.    TariffTimeGroup – Group    Classification Name Type Cardinality Description     « FK » TimeUnitRef TimeUnitRef 0:1 Référence au TIME UNIT for TARIFF.   « cntd » timeIntervals TimeInterval 0:* TIME INTERVALs associé au TARIFF.   « cntd » timeStructureFactors TimeStructureFactor 0:* TIME STRUCTURE FACTORs associé au TARIFF.    TariffQualityGroup – Group    Classification Name Type Cardinality Description     « cntd » qualityStructureFactors QualityStructureFactor 0:* QUALITY STRUCTURE FACTORs associé au TARIFF.    TariffStructureGroup – Group    Classification Name Type Cardinality Description     « cntd » fareStructureElements FareStructureElement 0:* FARE STRUCTURE ELEMENTs associé au TARIFF.   « cntd » distanceMatrixElements DistanceMatrixElement 0:* DISTANCE MATRIX ELEMENTs associé au TARIFF.   « cntd » groupsOfDistanceMatrixElements GroupOfDistanceMatrixElements 0:* GROUPs OF DISTANCE MATRIX ELEMENTS associé au TARIFF.    TariffPricesGroup – Group    Classification Name Type Cardinality Description     « cntd » priceGroups PriceGroup 0:* PRICE GROUPs pour ce TARIFF.   « cntd » fareTables FareTable 0:* FARE TABLEs pour ce TARIFF.    Exemple \u0026lt;Tariff id=\u0026#34;tap:NrtProduct@Route@Basic01\u0026#34; version=\u0026#34;01\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Standard route based Fare table 1\u0026lt;/Name\u0026gt; \u0026lt;validityConditions\u0026gt; \u0026lt;AvailabilityCondition id=\u0026#34;tap:Tariff01\u0026#34; version=\u0026#34;01\u0026#34;\u0026gt; \u0026lt;FromDate\u0026gt;2011-01-01T00:00:00Z\u0026lt;/FromDate\u0026gt; \u0026lt;ToDate\u0026gt;2014-01-01T00:00:00Z\u0026lt;/ToDate\u0026gt; \u0026lt;/AvailabilityCondition\u0026gt; \u0026lt;/validityConditions\u0026gt; \u0026lt;OperatorRef ref=\u0026#34;tap:0106\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;TypeOfTariffRef ref=\u0026#34;tap:B.1.1:01\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;TariffBasis\u0026gt;route\u0026lt;/TariffBasis\u0026gt; \u0026lt;ReturnFareTwiceSingle\u0026gt;true\u0026lt;/ReturnFareTwiceSingle\u0026gt; \u0026lt;fareStructureElements\u0026gt; \u0026lt;FareStructureElementRef ref=\u0026#34;tap:NrtProduct@round_trips\u0026#34; version=\u0026#34;01\u0026#34;/\u0026gt; \u0026lt;FareStructureElementRef ref=\u0026#34;tap:NrtProduct@fare_classes\u0026#34; version=\u0026#34;01\u0026#34;/\u0026gt; \u0026lt;FareStructureElementRef ref=\u0026#34;tap:NrtProduct@profiles\u0026#34; version=\u0026#34;01\u0026#34;/\u0026gt; \u0026lt;FareStructureElementRef ref=\u0026#34;tap:NrtProduct@series\u0026#34; version=\u0026#34;01\u0026#34;/\u0026gt; \u0026lt;/fareStructureElements\u0026gt; \u0026lt;groupsOfDistanceMatrixElements\u0026gt; \u0026lt;GroupOfDistanceMatrixElementsRef ref=\u0026#34;tap:NrtProduct@Routes\u0026#34; version=\u0026#34;01\u0026#34;/\u0026gt; \u0026lt;/groupsOfDistanceMatrixElements\u0026gt; \u0026lt;/Tariff\u0026gt; Les éléments de structure de tarification temporelle Il est assez courant d\u0026rsquo;avoir une structure tarifaire basée sur le temps, par exemple:\n  déterminé par l\u0026rsquo;entité INTERVALLE DE TEMPS qui décrit les périodes (0-1 heure, 1-3 heures, etc.) pendant lesquels un certain tarif est appliqué aux ELEMENT DE STRUCTURE TARIFAIRE.\n  une structure temporelle progressive définie à l\u0026rsquo;aide d\u0026rsquo;une UNITÉ DE TEMPS (par ex. Jours, heures ou minutes).\n  les deux types de structures peuvent être combinés en FACTEURS DE STRUCTURE DE TEMPS règles d’application pour les structures temporelles). Cela permet par exemple de spécifier un tarif par heure passée, qui varie en fonction de la durée totale de transport (ou d’utilisation du service).\n  Intervalle de temps (TimeInterval) TimeInterval – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; FareInterval ::\u0026gt; TIME INTERVAL hérite de FARE INTERVAL.  « PK » id TimeIntervalIdType 1:1 Identifiant du TIME INTERVAL.   StartTime xsd:time 0:1\n1 :1 Début du TIME INTERVAL.   EndTime xsd:time 0:1\n1 :1 Fin du TIME INTERVAL.   DayOffset DayOffsetType 0:1 Décalage du jour de l'heure de fin par rapport à l'heure de début. Zéro indique qu’il n’y a pas de changement de jour.   Duration xsd:duration 0:1 Durée   MinimumDuration xsd:duration 0:1 Durée minimale du TIME INTERVAL.    Règles d’application de Structure Temporelle (TimeStructureFactor) TimeStructureFactor – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; FareStructureFactor ::\u0026gt; TIME STRUCTURE FACTOR hérite de FARE STRUCTURE FACTOR.   « PK » id TimeStructureFactorIdType 1:1 Identifiant du TIME STRUCTURE FACTOR.   « FK » TimeIntervalRef TimeIntervalRef 0:1 Référence au TIME INTERVAL associé au facteur.   « FK » TimeUnitRef TimeUnitRef 0:1 Référence au TIME UNIT associé au facteur.   « FK » QualityStructureFactorRef QualityStructureFactorRef 0:* QUALITY FACTOR associé au TIME STRUCTURE FACTOR.    Note : les TimeInterval, TimeUnit et QualityStructureFactor s’appliquent de façon combinée (ET logique) dans le TimeStructureFactor\nUnité Temporelle (TimeUnit ) TimeUnit – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; FareUnit ::\u0026gt; TIME UNIT hérite de FARE UNIT.   « PK » id TimeUnitIdType 1:1 Identifiant du TIME UNIT.    Type xsd:NCName 0:1 Nom de type XML associé à l’unité e.g. gday, gMonth. Cette information est une métadonnée.    Duration xsd:duration 0:1 Durée associée à l’unité, e.g. P1D, PT1S.    Exemple \u0026lt;TimeInterval id=\u0026#34;FR-Tarif-Example:TimeInterval:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Description\u0026gt;1h30 de validit\u0026amp;#xE9; pour bus et TRam\u0026lt;/Description\u0026gt; \u0026lt;Duration\u0026gt;PT90M\u0026lt;/Duration\u0026gt; \u0026lt;timeStructureFactors\u0026gt; \u0026lt;TimeStructureFactor\u0026gt; \u0026lt;Name\u0026gt;Entre premi\u0026amp;#xE8;re et derni\u0026amp;#xE8;re validation\u0026lt;/Name\u0026gt; \u0026lt;!--A présenter pour l\u0026#39;IV--\u0026gt; \u0026lt;Description\u0026gt;Time Structure Factor pour \u0026#34;entre premi\u0026amp;#xE8;re et derni\u0026amp;#xE8;re validation\u0026#34;\u0026lt;/Description\u0026gt; \u0026lt;TypeOfFareStructureFactorRef ref=\u0026#34;BetweenFirstAndLastValidation\u0026#34;/\u0026gt; \u0026lt;/TimeStructureFactor\u0026gt; \u0026lt;/timeStructureFactors\u0026gt; \u0026lt;/TimeInterval\u0026gt; Les éléments de structure de tarification géographique Les règles de structure tarifaire les plus courantes sont basées sur la géographie ou, plus précisément, sur la distance. Les trois types principaux sont respectivement progressifs (proportionnel à une distance), gradués en fonction d\u0026rsquo;une distance, et utilisant des zones. Certains de ces types peuvent être combinés.\nL\u0026rsquo;entité INTERVALLE GÉOGRAPHIQUE décrit une classification des ÉLÉMENTS DE STRUCTURE TARIFAIRE en fonction de leur longueur, par exemple :\n  1 zone (ou section tarifaire) traversée, 2 à 4 zones traversées, plus de 4 zones traversées ;\n  longueur de trajet inférieure à 5 km, entre 5 et 15 km, plus de 15 km ;\n  etc.\n  Les structures tarifaires progressives permettent un calcul des tarifs en fonction de la distance parcourue pendant le voyage. La distance est calculée à partir d\u0026rsquo;une certaine unité, la plus classique étant la distance en kilomètres, le nombre de sections tarifaires (ou zones) ou le nombre de points d\u0026rsquo;arrêt. Une telle unité de graduation est décrite par l\u0026rsquo;entité UNITE GEOGRAPHIQUE. Le tarif d\u0026rsquo;un voyage sera calculé en multipliant la distance par un paramètre de prix attaché à l\u0026rsquo;UNITÉ GEOGRAPHIQUE.\nDe nombreux réseaux utilisent des ZONEs TARIFAIREs (ZONE définie spécifiquement pour le calcul des tarifs). Elle définit notamment un périmètre qui contient des POINTS D\u0026rsquo;ARRÊT PLANIFIÉS. Une ZONE TARIFAIRE peut avoir des points spécifiques sur ses frontières (POINTS TARIFAIRES).\nUne SECTION TARIFAIRE est un autre type de paramètre de structure tarifaire. Il s\u0026rsquo;agit d\u0026rsquo;une subdivision d\u0026rsquo;un PARCOURS, constitué de POINTS D\u0026rsquo;ARRÊT PLANIFIÉS.\nDe nombreuses structures tarifaires progressives utiliseront le nombre de ZONEs TARIFAIREs ou de SECTIONs TARIFAIREs comme UNITÉ GÉOGRAPHIQUE.\nCertains systèmes de structure tarifaire utiliseront des distances arbitraires ou réelles entre l\u0026rsquo;origine et la destination. Ces valeurs de paramètres sont susceptibles de différer d\u0026rsquo;un calcul exact basé sur la distance parcourue. Ces valeurs sont stockées dans l\u0026rsquo;entité DISTANCE MATRIX ELEMENT. Les origines et destination sont généralement des POINTS D\u0026rsquo;ARRÊT PLANIFIÉS, LIEUX D’ARRÊT ou des ZONEs TARIFAIREs (l’origine et la destination peuvent avoir des types différents).\nIntervalle Géographique (GeographicalInterval) GeographicalInterval – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; FareInterval ::\u0026gt; GEOGRAPHICAL INTERVAL hérite de FARE INTERVAL.  « PK » id GeographicalIntervalIdType 1:1 Identifiant du GEOGRAPHICAL INTERVAL.   StartGeographicalValue xsd:decimal 0:1 Valeur de départ du GEOGRAPHICAL INTERVAL.   EndGeographicalValue xsd:decimal 0:1 Valeur de fin du GEOGRAPHICAL INTERVAL.   NumberOfUnits xsd:integer 0:1 Nombre d’unités du GEOGRAPHICAL INTERVAL.  « enum » IntervalType IntervalTypeEnum 0:1 Classification de l’interval:\n Stop (arrêt)\ntariffZone (zone tarifaire)\ndistance (distance)\nsection (section)\ncoupon (coupon)\nother (autre)\n  « FK » GeographicalUnitRef GeographicalUnitRef 0:1 GEOGRAPHICAL UNIT pour l’interval.    Unité Géographique (GeographicUnit) GeographicalUnit – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; FareUnit ::\u0026gt; GEOGRAPHICAL UNIT hérite de FARE UNIT.   « PK » id GeographicalUnitIdType 1:1 Identifiant du GEOGRAPHICAL UNIT.    Distance DistanceType 0:1 Pour les unités de distance, type de l\u0026rsquo;unité.    Règles d’application de Structure Géographique (GeographicalStructureFactor) Les structures tarifaires simples peuvent être combinées dans des structures plus complexes.\nDans la plupart des cas de structures tarifaires utilisant des INTERVALLEs GEOGRAPHIQUEs, le tarif sera fixe dans la plage de chaque intervalle, ce qui signifie que le tarif est le même tout au long de l\u0026rsquo;intervalle. Cependant, les tarifs peuvent varier à l\u0026rsquo;intérieur de chaque intervalle, selon une graduation basée sur une UNITÉ GÉOGRAPHIQUE. Par exemple, les tarifs peuvent être progressifs, le prix au km différant en fonction du nombre de zones traversées (notamment pour permettre des prix plus bas pour les longs trajets).\nDe même, une structure tarifaire progressive peut être influencée par le type de voyage, en ce qui concerne la géographie du réseau. Si le tarif est basé sur le nombre de sections tarifaires traversées, il peut varier, par exemple, selon que le trajet s\u0026rsquo;effectue d\u0026rsquo;une banlieue vers le centre-ville ou entre deux banlieues. Cette structure associera des INTERVALLE GÉOGRAPHIQUE (sections tarifaires) et des ÉLÉMENTS DE MATRICE DE DISTANCE (en utilisant un ensemble de ZONEs TARIFAIREs, par exemple « centre » et « banlieue »).\nL\u0026rsquo;entité GEOGRAPHICAL STRUCTURE FACTOR permet de combiner deux structures simples dans un facteur complexe. Il est identifié par une UNITÉ GEOGRAPHIQUE, décrivant l\u0026rsquo;unité de graduation utilisée, et par un INTERVALLE GÉOGRAPHIQUE ou un ÉLÉMENT DE MATRICE DE DISTANCE.\nGeographicalStructureFactor – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; FareStructureFactor ::\u0026gt; GEOGRAPHICAL STRUCTURE FACTOR hérite de FARE STRUCTURE FACTOR.   « PK » id GeographicalStructureFactorRef 1:1 Identifiant du GEOGRAPHICAL STRUCTURE FACTOR.   « FK » DistanceMatrixElementRef DistanceMatrixElementRef 0:1 Référence à un DISTANCE MATRIX ELEMENT.   « FK » GeographicalIntervalRef GeographicalIntervalIdType 0:1 Référence à un GEOGRAPHICAL INTERVAL.   « FK » GeographicalUnitRef GeographicalUnitRef 0:1 Référence au GEOGRAPHICAL UNIT correspondant.    Exemple \u0026lt;GeographicalUnit version=\u0026#34;any\u0026#34; id=\u0026#34;SNCF:GeographicalUnit:TER-Unit\u0026amp;#xE9;-de-distance:LOC\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Unit\u0026amp;#xE9; de distance arbitraire (peut-\u0026amp;#xEA;tre des kilom\u0026amp;#xE9;tre, ou une unit\u0026amp;#xE9; de distance tarifaire)\u0026lt;/Name\u0026gt; \u0026lt;/GeographicalUnit\u0026gt; \u0026lt;GeographicalInterval version=\u0026#34;001\u0026#34; id=\u0026#34;SNCF:GeographicalInterval:TER-1km:LOC\u0026#34;\u0026gt; \u0026lt;StartGeographicalValue\u0026gt;0.0\u0026lt;/StartGeographicalValue\u0026gt; \u0026lt;EndGeographicalValue\u0026gt;1.0\u0026lt;/EndGeographicalValue\u0026gt; \u0026lt;IntervalType\u0026gt;distance\u0026lt;/IntervalType\u0026gt; \u0026lt;/GeographicalInterval\u0026gt; \u0026lt;!--etc...--\u0026gt; \u0026lt;GeographicalInterval version=\u0026#34;001\u0026#34; id=\u0026#34;SNCF:GeographicalInterval:TER-3km:LOC\u0026#34;\u0026gt; \u0026lt;StartGeographicalValue\u0026gt;1.0\u0026lt;/StartGeographicalValue\u0026gt; \u0026lt;EndGeographicalValue\u0026gt;2.0\u0026lt;/EndGeographicalValue\u0026gt; \u0026lt;IntervalType\u0026gt;distance\u0026lt;/IntervalType\u0026gt; \u0026lt;/GeographicalInterval\u0026gt; \u0026lt;!--etc...--\u0026gt; \u0026lt;!--Association Interval - Unités--\u0026gt; \u0026lt;GeographicalStructureFactor version=\u0026#34;001\u0026#34; id=\u0026#34;SNCF:GeographicalStructureFactor:AtoB:LOC\u0026#34;\u0026gt; \u0026lt;GeographicalIntervalRef version=\u0026#34;001\u0026#34; ref=\u0026#34;SNCF:GeographicalInterval:TER-43km:LOC\u0026#34;/\u0026gt; \u0026lt;GeographicalUnitRef ref=\u0026#34;SNCF:GeographicalUnit:TER-Unit\u0026amp;#xE9;-de-distance:LOC\u0026#34;/\u0026gt; \u0026lt;/GeographicalStructureFactor\u0026gt; Élément de Matrice de Distances (DistanceMatrixElement) La MATRICE DE DISTANCEs permet de décrire les tarifs point à point. Chaque ELEMENT DE MATRICE DE DISTANCE représente le tarif pour un couple d\u0026rsquo;origine-destination. Un GROUPE D\u0026rsquo;ÉLÉMENTS DE MATRICE DE DISTANCE spécifie un ensemble d\u0026rsquo;ÉLÉMENTs DE MATRICE DE DISTANCE, permettant un ensemble commun de prix entre différentes paires origine-destination si nécessaire.\nDans le domaine ferroviaire, il peut y avoir des CONSTRAINTEs SERIEs associées à un DISTANCE MATRIX ELEMENT, chacune représentant une contrainte de routage différente.\nDistanceMatrixElement – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; PriceableObject ::\u0026gt; DISTANCE MATRIX ELEMENT hérite de PRICEABLE OBJECT***.***   « PK » id DistanceMatrixElementIdType 1:1 Identifiant du DISTANCE MATRIX ELEMENT.   XGRP DistanceMatrixElementDetailsGroup xmlGroup 1:1 Propriétés détaillées du DISTANCE MATRIX ELEMENT.   XGRP DistanceMatrixElementODGroup xmlGroup 1:1 Origine et Destination du DISTANCE MATRIX ELEMENT.   XGRP DistanceMatrixElementComponentGroup xmlGroup 1:1 Composants du DISTANCE MATRIX ELEMENT.    DistanceMatrixElementDetailsGroup – Group    Classification Name Type Cardinality Description      Distance DistanceType 0:1 Distance entre l\u0026rsquo;origine et la destination d\u0026rsquo;un DISTANCE MATRIX ELEMENT.    RelativeRanking xsd:integer 0:1 Préférence relative attribuée à cet élément s\u0026rsquo;il y a plusieurs possibilités entre deux points.    IsDirect xsd:boolean 0:1 Indique que le voyage est direct ou nécessite des changements.    InverseAllowed xsd:boolean 0:1 Indique s’il y a un élément dans la direction opposée avec les mêmes prix - optimisation pour réduire les volumes de données.    DistanceMatrixElementODGroup – Group    Classification Name  Type Cardinality Description        Choice 1:1    « FK » a StartStopPointRef ScheduledStopPointRef 0:1 SCHEDULED STOP POINT duquel le DISTANCE MATRIX ELEMENT commence.   « FK » c StartTariffZoneRef TariffZoneRef 0:1 TARIFF ZONE à laquelle DISTANCE MATRIX ELEMENT commence.   « FK » e StartFareSectionRef FareSectionRef 0:1 FARE SECTION à laquelle DISTANCE MATRIX ELEMENT commence.   « FK » f StartFarePointInPatternRef FarePointInPatternRef 0:1 FARE POINT IN PATTERN duquel le DISTANCE MATRIX ELEMENT commence (gère le cas des passages répétés)      Choice 1:1 Destination du DISTANCE MATRIX ELEMENT.   « FK » a EndStopPointRef ScheduledStopPointRef 0:1 SCHEDULED STOP POINT où le DISTANCE MATRIX ELEMENT se termine.   « FK » c EndTariffZoneRef TariffZoneRef 0:1 TARIFF ZONE à laquelle le DISTANCE MATRIX ELEMENT se termine.   « FK » e EndFareSectionRef FareSectionRef 0:1 FARE SECTION à laquelle le DISTANCE MATRIX ELEMENT se termine.   « FK » f EndFarePointInPatternRef FarePointInPatternRef 0:1 FARE POINT IN PATTERN où le DISTANCE MATRIX ELEMENT se termine. (gère le cas des passages répétée)    DistanceMatrixElementComponentGroup – Group    Classification Name Type Cardinality Description     « cntd » seriesConstraints SeriesConstraintRef 0:* SERIES CONSTRAINTs associé au DISTANCE MATRIX ELEMENT.   « cntd » structureFactors GeographicalStructureFactorRef 0:* STRUCTURE FACTORs associé au DISTANCE MATRIX ELEMENT.    Groupe de Matrice d’Éléments de Distances (GroupOfDistanceMatrixElement) GroupOfDistanceMatrixElements – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; GroupOfEntities ::\u0026gt; GROUP of DISTANCE MATRIX ELEMENTs hérite de GROUP OF ENTITies.   « PK » id GroupOfDistanceMatrixElementsIdType 1:1 Identifiant du GROUP of DISTANCE MATRIX ELEMENTS.    UseToExclude xsd:boolean 0:1 Indique si le contenu du groupe doit être utilisé pour exclure (vrai) l’information d\u0026rsquo;une liste plus importante. La valeur par défaut est \u0026ldquo;false\u0026rdquo; (c\u0026rsquo;est-à-dire \u0026ldquo;include\u0026rdquo;)    Distance DistanceType 0:1 Distance entre les origines et les destinations d\u0026rsquo;un GROUP OF DISTANCE MATRIX ELEMENTs.   « cntd » structureFactors GeographicalStructureFactorRef 0:* Référence à un GEOGRAPHICAL STRUCTURE FACTORs.   « cntd » noticeAssignments NoticeAsssignment 0:* NOTICE ASSIGNMENTs pour le GROUP OF DISTANCE MATRIX ELEMENTs.   « cntd » members DistanceMatrixElements 0:* Référence les membres du GROUP OF DISTANCE MATRIX ELEMENTs.    Exemple Exemple 1\n\u0026lt;DistanceMatrixElement id=\u0026#34;FR-Tarif-Example:DistanceMatrixElement:AtoB:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Distance\u0026gt;43\u0026lt;/Distance\u0026gt; \u0026lt;IsDirect\u0026gt;true\u0026lt;/IsDirect\u0026gt; \u0026lt;InverseAllowed\u0026gt;true\u0026lt;/InverseAllowed\u0026gt; \u0026lt;StartStopPointRef versionRef=\u0026#34;any\u0026#34; ref=\u0026#34;SNCF:ScheduledStopPoint:GareA:LOC\u0026#34;/\u0026gt; \u0026lt;EndStopPointRef versionRef=\u0026#34;any\u0026#34; ref=\u0026#34;SNCF:ScheduledStopPoint:GareB:LOC\u0026#34;/\u0026gt; \u0026lt;structureFactors\u0026gt; \u0026lt;GeographicalStructureFactorRef version=\u0026#34;001\u0026#34; ref=\u0026#34;SNCF:GeographicalInterval:TER-43km:LOC\u0026#34;/\u0026gt; \u0026lt;/structureFactors\u0026gt; \u0026lt;/DistanceMatrixElement\u0026gt; Exemple 2\n\u0026lt;DistanceMatrixElement id=\u0026#34;FR-Tarif-Example:DistanceMatrixElement:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;IsDirect\u0026gt;true\u0026lt;/IsDirect\u0026gt; \u0026lt;InverseAllowed\u0026gt;false\u0026lt;/InverseAllowed\u0026gt; \u0026lt;StartStopPointRef versionRef=\u0026#34;any\u0026#34; ref=\u0026#34;SNCF:ScheduledStopPoint:ParisGareduNord-87271007:LOC\u0026#34;/\u0026gt; \u0026lt;EndStopPointRef versionRef=\u0026#34;any\u0026#34; ref=\u0026#34;SNCF:ScheduledStopPoint:LilleFlandre-87 286 005:LOC\u0026#34;/\u0026gt; \u0026lt;!--Note On pourrait insérer ici une CONTRAINTE de SERIE si plusieurs itinéraires étaient concernés--\u0026gt; \u0026lt;!-- \u0026lt;seriesConstraints\u0026gt; \u0026lt;SeriesConstraint id=\u0026#34;SNCF:SeriesConstraint:Paris-Lille\u0026#34; order=\u0026#34;1\u0026#34; version=\u0026#34;1.0\u0026#34;\u0026gt; \u0026lt;Itinerary\u0026gt;Paris * Lille\u0026lt;/Itinerary\u0026gt; \u0026lt;SeriesType\u0026gt;stationToStation\u0026lt;/SeriesType\u0026gt; \u0026lt;FirstClassDistance\u0026gt;19\u0026lt;/FirstClassDistance\u0026gt; --\u0026gt; \u0026lt;!-- et on peut en profiter pour ajouter une distance tarifaire --\u0026gt; \u0026lt;!-- \u0026lt;SecondClassDistance\u0026gt;20\u0026lt;/SecondClassDistance\u0026gt; \u0026lt;journeyPatterns\u0026gt; \u0026lt;JourneyPatternRef ref=\u0026#34;SNCF:JourneyPattern:0001:LOC\u0026#34;\u0026gt;\u0026lt;/JourneyPatternRef\u0026gt; --\u0026gt; \u0026lt;!--Peut passer par des JP, mais ausi par des points ... ou des correspondances--\u0026gt; \u0026lt;!-- \u0026lt;JourneyPatternRef ref=\u0026#34;SNCF:JourneyPattern:0002:LOC\u0026#34;\u0026gt;\u0026lt;/JourneyPatternRef\u0026gt; \u0026lt;/journeyPatterns\u0026gt; \u0026lt;/SeriesConstraint\u0026gt; \u0026lt;/seriesConstraints\u0026gt;--\u0026gt; \u0026lt;/DistanceMatrixElement\u0026gt; Les Éléments Validables (ValidableElement) Le système de contrôle d\u0026rsquo;un organisme de transport public est organisé pour « valider » régulièrement la consommation des droits d\u0026rsquo;accès, c\u0026rsquo;est-à-dire que les passagers disposent du bon billet pour le transport sur lequel ils voyagent. Le processus de validation vise à préciser qu\u0026rsquo;un droit d\u0026rsquo;accès est valide, a été consommé et que cette consommation a été autorisée. Il utilise les résultats d\u0026rsquo;un ou plusieurs contrôles consécutifs.\nUn tel droit d\u0026rsquo;accès validé peut inclure plusieurs éléments pour lesquels la structure tarifaire est différente. Par exemple, un produit tarifaire peut inclure une réduction pour les voyageurs utilisant un parking puis les transports en commun (cas des parcs relais). Si la structure tarifaire de ces deux éléments est différente (par exemple, les tarifs fixes pour les transports publics et le prix basé sur la durée du séjour pour le parking), ils seront décrits par deux ÉLÉMENTS DE STRUCTURE TARIFAIRE différents. La remise n\u0026rsquo;est accordée que lorsque le processus de validation reconnaît que les deux ont été consommés en séquence.\nPar conséquent, un ÉLÉMENT VALIDABLE est défini comme une séquence ou un ensemble d\u0026rsquo;ÉLÉMENTS DE STRUCTURE TARIFAIRE, à consommer dans son ensemble (ou à valider en une seule fois), c\u0026rsquo;est-à-dire qu\u0026rsquo;il n\u0026rsquo;est pas prévu d\u0026rsquo;utiliser les différents éléments de la séquence séparément (si l\u0026rsquo;un des éléments est consommé, l\u0026rsquo;ensemble du droit d\u0026rsquo;accès est considéré comme consommé).\nUn ELEMENT DE STRUCTURE TARIFAIRE, dédié à être consommé tel quel, seul, est identique à un ELEMENT VALIDABLE.\nPar exemple, un abonnement peut donner à l\u0026rsquo;utilisateur le droit d\u0026rsquo;effectuer un trajet entre une gare de banlieue particulière et le centre-ville (pour lequel l\u0026rsquo;ÉLÉMENT VALIDABLE est un « voyage en train » avec départ spécifié) et aussi le droit de circuler en métro dans la zone urbaine (l\u0026rsquo;ÉLÉMENT VALIDABLE est un « trajet en métro » avec une restriction zonale).\nUn ÉLÉMENT VALIDABLE peut être limité à une portée particulière (par exemple, MODE, OPÉRATEUR, LIGNE, etc.) via une ASSIGNATION DE PARAMÈTRES DE VALIDITÉ associée.\nDans certains cas, il est utile de décrire les droits plus en détail, en particulier de les relier au processus de vérification des billets et l\u0026rsquo;ELEMENT CONTRÔLABLE (voir plus loin) permet de le faire.\nÉlément Validable – Modèle conceptuel\nNote : Quand un ValidableElement n’a pas vocation à être réutilisé (uniquement utilisé par un unique FareProduct) alors on le définit directement dans le FareProduct\nValidableElement – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; PriceableObject ::\u0026gt; VALIDABLE ELEMENT hérite de PRICEABLE OBJECT***.***   « PK » id ValidableElementIdType 1:1 Identifiant du VALIDABLE ELEMENT.   XGRP ValidableElementStructureGroup xmlGroup 1:1 Éléments structurels constituant le VALIDABLE ELEMENT.   XGRP ValidableElementProductGroup xmlGroup 1:1 Éléments relatifs au produit constituant le VALIDABLE ELEMENT.    ValidableElementStructureGroup – Group    Classification Name Type Cardinality Description     « cntd » fareStructureElements FareStructureElement 0:* FARE STRUCTURE ELEMENTs constituant le VALIDABLE ELEMENT.   « cntd » elementsInSequence FareStructureElementInSequence 0:* FARE STRUCTURE ELEMENTs IN SEQUENCE constituant le VALIDABLE ELEMENT.    ValidableElementProductGroup – Group   Classification Name Type Cardinality Description    « cntd » discountRights FareProductRef+ 0:* Droits à remise faisant parti du VALIDABLE ELEMENT.\nNote : utilisé uniquement pour consommation simultanée d’un titre ouvrant droit à réduction\n  « cntd » thirdPartyProducts ThirdPartyProductRef 0:* THIRD PARTY PRODUCTs lié au VALIDABLE ELEMENT.  « cntd » validityParameterAssignments ValidityParameterAssignment 0:* VALIDITY PARAMETER ASSIGNMENTs liés au VALIDABLE ELEMENT.    Exemple \u0026lt;ValidableElement id=\u0026#34;FR-Tarif-Example:ValidableElement:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;noticeAssignments\u0026gt; \u0026lt;NoticeAssignment id=\u0026#34;FR-Tarif-Example:NoticeAssignment:001:LOC\u0026#34; version=\u0026#34;any\u0026#34; order=\u0026#34;1\u0026#34;\u0026gt; \u0026lt;NoticeRef ref=\u0026#34;FR-Tarif-Example:Notice:001:LOC\u0026#34;/\u0026gt; \u0026lt;/NoticeAssignment\u0026gt; \u0026lt;/noticeAssignments\u0026gt; \u0026lt;fareStructureElements\u0026gt; \u0026lt;FareStructureElementRef ref=\u0026#34;FR-Tarif-Example:FareStructureElement:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;/fareStructureElements\u0026gt; \u0026lt;/ValidableElement\u0026gt; Les Éléments Contrôlables (ControllableElement) UNIQUEMENT UTILE SI L’ALIMENTATION D’UN SYSTÈME BILLETTIQUE EST ENVISAGEE !\nNote : l’ÉLÉMENT CONTRÔLABLE n’est à utiliser que dans les contexte de l’alimentation d’un système billettique (de façon à lui préciser les élément effectivement à contrôler)\nLa définition d\u0026rsquo;un système tarifaire comprend toujours un niveau de base de droits d\u0026rsquo;accès, pour lequel les paramètres de validité contrôlés restent les mêmes et sont constamment valables. Un ELEMENT CONTROLLABLE est défini comme le plus petit élément de service :\n  dont la consommation réelle peut être contrôlée, au moyen de contrôles réguliers ou occasionnels ;\n  tout au long duquel tout paramètre contrôlé reste valide.\n  Un ÉLÉMENT CONTRÔLABLE est le composant de base de toute combinaison de droits d\u0026rsquo;accès incluse dans un produit tarifaire.\nTrois principaux types d\u0026rsquo;ÉLÉMENTS CONTRÔLABLES se retrouvent dans les transports publics :\n  La montée dans un véhicule, par exemple dans des bus, des tramways ou d\u0026rsquo;autres systèmes « ouverts ». Un trajet d\u0026rsquo;un POINT D\u0026rsquo;ARRÊT PLANIFIÉ à un autre, au cours d\u0026rsquo;une COURSE, peut représenter un tel ÉLÉMENT CONTRÔLABLE ;\n  Les voyages, composés de séquences de segments et de correspondances, par exemple dans des systèmes fermés comme le métro avec des tourniquets d\u0026rsquo;entrée / sortie. Dans un tel cas, les échanges sont autorisés au sein du même ÉLÉMENT CONTRÔLABLE et ne sont pas contrôlés ;\n  L’accès aux services communs (par ex. parking, salon, etc.), le cas échéant.\n  Dans les situations complexes, des ÉLÉMENTS CONTRÔLABLES plus détaillés sont définis. Par exemple, si une ligne de train utilise une voie composée de deux tronçons, chacun exploité par un opérateur différent, un seul trajet sur cette ligne sera composé de deux ÉLÉMENTS CONTRÔLABLES, distingués par le paramètre OPÉRATEUR.\nLes paramètres de validité peuvent être associés à un ÉLÉMENT CONTRÔLABLE, soit :\n  au début de l\u0026rsquo;élément, contrôlé par un contrôle d\u0026rsquo;entrée ; par exemple, la consommation doit commencer à un POINT D\u0026rsquo;ARRÊT PLANIFIÉ donné ;\n  à la fin de l\u0026rsquo;élément, contrôlé par un contrôle de sortie ; par exemple, la consommation ne doit pas se terminer après 16 heures ;\n  tout au long de l\u0026rsquo;élément (paramètre « en route »), éventuellement contrôlé par tout contrôle d\u0026rsquo;entrée, de sortie ou en route ; par exemple, la consommation doit avoir lieu sur la ligne 18.\n  Élément contrôlable – Modèle conceptuel\nNote : l’association avec les ÉLÉMENTS DE STRUCTURE TARIFAIRE se fait via les FareStructureComponentGroup\nControllableElement – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; PriceableObject ::\u0026gt; CONTROLLABLE ELEMENT hérite de PRICEABLE OBJECT***.***   « PK » id ControllableElementIdType 1:1 Identifiant du CONTROLLABLE ELEMENT.   « cntd » accessRightParameterAssignments AccessRightParameter-Assignment+ 0:* ACCESS RIGHT PARAMETER ASSIGNMENTs associé au CONTROLLABLE ELEMENT.   « cntd » controllableElementsInSequence ControllableElementInSequence 0:* CONTROLLABLE ELEMENTs IN SEQUENCE associé au CONTROLLABLE ELEMENT.    Les Produits Tarifaires (FareProduct) Le PRODUIT TARIFAIRE décrit un ensemble de fonctionnalités (droits d\u0026rsquo;accès, droits de remise, etc.), spécifiques à un MOMENT DE PAIMENT (pré-paiement, post-paiement…).\nUn PRODUIT TARIFAIRE est un élément commercialisable immatériel (il donne des droits) mis à la disposition du public. Il peut être acheté et permet au propriétaire d’utiliser les transports en commun ou d\u0026rsquo;autres services à des conditions spécifiques. Il peut s\u0026rsquo;agir de droits d\u0026rsquo;accès spécifiés (PRODUIT TARIFAIRE PRÉDÉFINI) ou d\u0026rsquo;autres produits (remises, montant d\u0026rsquo;unité de prix, etc.).\nUn PRODUIT TARIFARE bien qu’immatériel, peut être matérialisé sur différents DOCUMENTS DE VOYAGE. Par exemple, un PRODUIT TARIFAIRE « passe mensuelle » peut être incorporé de différentes manières sur un billet papier spécifique ou stocké sur une carte électronique.\nLe fait que les PRODUITs TARIFAIREs se distinguent en fonction du MOMENT DE PAIEMENT montre la caractéristique intrinsèque d\u0026rsquo;un PRODUIT TARIFAIRE ; ce sont des droits d\u0026rsquo;accès.\nLes exemples classiques de MOMENT DE PAIMENT sont les suivants :\n  pré-paiement avec annulation (billets jetables );\n  pré-paiement avec débit sur un DOCUMENT DE VOYAGE (carte de valeur) ;\n  pré-paiement sans enregistrement de la consommation (pass illimité) ;\n  post-paiement (carte électronique avec compte central et débit mensuel) ;\n  gratuit.\n  Ces principales catégories peuvent naturellement être subdivisées en fonction des exigences spécifiques de l\u0026rsquo;opérateur.\nLes PRODUITs TARIFAIREs les plus classiques sont des combinaisons de droits d\u0026rsquo;accès spécifiés (ticket unique, ticket hebdomadaire, abonnement mensuel, etc.). Un tel PRODUIT TARIFAIRE PRÉDÉFINI est décrit comme un PRODUIT TARIFAIRE composé d\u0026rsquo;un ou plusieurs ÉLÉMENTS VALIDABLES spécifiques.\nUn même PRODUIT TARIFAIRE peut être utilisé dans une ou plusieurs OFFREs A LA VENTE (voir plus loin) pour décrire un produit commercialisé que l\u0026rsquo;utilisateur peut acheter matérialisé sur un DOCUMENT DE VOYAGE (ticket, carte, mobile, etc.).\nNote : la plupart de spécialisation de : UN PRODUIT TARIFAIRE dispose d’un attribut ProductType. Par convention, dans le cadre du profil si le produit est \u0026ldquo;single trip\u0026rdquo; et qu’il référence plusieurs ValidableElements, alors le PRODUIT ne donne la possibilité que d’utiliser un seul de ces ValidableElement parmi la miste proposée. Cela permet de gérer les cas où un produit donne accès à un droit A ou B ou C \u0026hellip;. On pourra aussi utliser ce mécanisme pour faire un unique produit O-D, contenant de très nombreuses O-D, mais avec une seule tarification comme dans le cas du Yield Management. Pour mémoire, le ValidableElement peut lui-même être constitué d’une séquence de FareStructureElements, ce qui permettra bien de gérer toutes les situations de droits combinés.\nProduits Tarifaires (vue simplifiée) – Modèle conceptuel\nServiceAccessRight – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; PriceableObject ::\u0026gt; SERVICE ACCESS RIGHT hérite de PRICEABLE OBJECT.   « PK » id ServiceAccessRightIdType 1:1 Identifiant du SERVICE ACCESS RIGHT.   « AK » PrivateCode PrivateCodeType 0:1 Identifiant alternatif; peut être utilisé pour s\u0026rsquo;associer à des systèmes existants.    InfoUrl xsd:anyURI 0:1 Lien ver les informations sur le produit.   « cntd » documentLinks InfoLink 0:* InfoLinks pour les documents externes. Pour les PDF, etc.    FareProduct – Element (abstrait)    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; PriceableObject ::\u0026gt; FARE PRODUCT hérite de SERVICE ACCESS RIGHT. Note : cet héritage fournit entre autres un attribut noticeAssignments ; dans le contexte de ce profil, c’est au niveau des SalesOfferPackage et FareProducts que l’on placera les Notices.   « PK » id FareProductIdType 0:1 Identifiant du FARE PRODUCT.   « FK » ChargingMomentRef ChargingMomentRef 0:1 Référence à CHARGING MOMENT associé au produit.   « enum » ChargingMomentType ChargingMomentTypeEnum 0:1 Énumération des valeurs normalisées du moment de paiement.\nbeforeTravel (avant le voyage)onStartOfTravel (au départ du voyage)beforeEndOfTravel (avant la fin du voyage)onStartThenAdjustAtEndOfTravel (au départ avec ajustement à la fin du voyage)onStarThenAdjustAtEndOfFareDay (au départ avec ajustement en fin de journée)onStartThenAdjustAtEndOfChargePeriod (au départ avec ajustement en fin de période tarifaire)atEndOfTravel (à la fin du voyage)atEndOfFareDay (à la fin de la journée tarifaire)atEndOfChargePeriod (à la fin de la période tarifaire)free (gratuit)anyTime (à n’importe quel moment)other (autre)\n   « FK » typesOfFareProductRef TypeOfFareProductRef 0:* Classifications du FARE PRODUCT.   « FK » TransportOrganisationRef (TransportOrganisationRef) OperatorRef / AuthorityRef 0:1 OPERATOR ou AUTHORITY en charge du FARE PRODUCT.   « cntd » ConditionSummary ConditionSummary 0:1 Résumé des conditions associées au FARE PRODUCT.\nNote : dans le cadre du profil, seuls certains attributs des ConditionSummary sont acceptés pour le FareProduct (voir description des ConditionSummary).\n   XGRP FareProductValidityGroup FareProductRef* 0:1 Informations de validité relatives au FARE PRODUCT.    FareProductValidityGroup – Group    Classification Name Type Cardinality Description     « cntd » validityParameterAssignments AccessRightParameterAssignment 0:* VALIDITY PARAMETER ASSIGNMENTs relatifs au FARE PRODUCT.   « cntd » validableElements ValidableElement 0:* VALIDABLE ELEMENTs pour le FARE PRODUCT.   « cntd » accessRightsInProduct AccessRightInProduct 0:* ACCESS RIGHTs contenu par le FARE PRODUCT.    PreassignedFareProduct – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; FareProduct ::\u0026gt; PREASSIGNED FARE PRODUCT hérite de FARE PRODUCT.  « PK » id PreassignedFareProductIdType 1:1 Identifiant du PREASSIGNED FARE PRODUCT.  « enum » ProductType PreassignedFareProductEnum 1:1 Classification du PREASSIGNED FARE PRODUCT.\n singleTrip (trajet unique)\nshortTrip (trajet court)\ntimeLimitedSingleTrip (trajet unique à durée limitée)\ndayReturnTrip (aller-retour dans la journée)\nperiodReturnTrip (aller-retour sur période fixe)\nmultistepTrip (trajet à étapes)\ndayPass (passe journalier)\nperiodPass (abonnement pour une période)\nsupplement (supplément)\nother (autre)\n    ChargingMoment – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; TypeOfValue ::\u0026gt; TYPE OF CHARGING MOMENT hérite de TYPE OF VALUE.   « PK » id ChargingMomentIdType 1:1 Identifiant du TYPE OF CHARGING MOMENT.    Les quatre principaux types de PRODUITS TARIFAIRES sont les suivants :\n  Le PRODUIT TARIFAIRE PRÉDÉFINI est une combinaison commercialisable d\u0026rsquo;ÉLÉMENTS VALIDABLES spécifiés. Il s\u0026rsquo;agit du PRODUIT TARIFAIRE le plus courant dans les transports publics (matérialisé par exemple sous forme de ticket unique, d\u0026rsquo;abonnement mensuel, etc.) ;\n  Le AMOUNT OF PRICE UNIT, qui correspond à une porte-monnaie d’unités transport, est un PRODUIT TARIFAIRE exprimé par un nombre spécifié d\u0026rsquo;UNITÉS DE PRIX (unité monétaire, jeton, trajet, etc.). Il n\u0026rsquo;est généralement pas pré-assigné, ce qui signifie qu\u0026rsquo;il donne le droit de consommer n\u0026rsquo;importe quel ELEMENT VALIDABLE d\u0026rsquo;une liste spécifiée. Dans certains cas, les billets simples doivent être considérés comme « unité transport », lorsqu\u0026rsquo;il est nécessaire de poinçonner un nombre variable de billets en fonction de la nature ou la durée du voyage effectué ;\n  Le DROIT A REMISE est un PRODUIT TARIFAIRE permettant à son titulaire de bénéficier de remises lors de l\u0026rsquo;achat d’OFFRES A LA VENTE spécifiques. Les compagnies de train, par exemple, proposent généralement de telles réductions (par exemple, une carte de réduction de 30%) ;\n  Le DROIT A REMISE A L’USAGE est un PRODUIT TARIFAIRE permettant à son titulaire de bénéficier de remises lors de la consommation des ELEMENT VALIDABLEs spécifiés, et ce en fonction de l’usage qu’il fait des services de transport (c’est typiquement le principe des « Miles », cartes voyageur, etc.).\n  Deux autres types de PRODUITs TARIFAIREs existent également :\n  REMISE PAR PLAFONNEMENT un affinement du droit de remise utilisé pour les tarifs électroniques avancés de paiement à la consommation, où une fois qu\u0026rsquo;un certaine niveau d’usage a été atteint, un plafond (tel que spécifié par une ou plusieurs RÈGLES DE PLAFONNEMENT) est appliqué, par exemple en limitant l\u0026rsquo;utilisation quotidienne a coût d\u0026rsquo;un passe journalier.\n  PRODUIT SUPPLÉMENTAIRE : Un produit accessoire, tel qu\u0026rsquo;un surclassement de siège ou un repas, qui ne peut être acheté qu\u0026rsquo;en complément d\u0026rsquo;un autre produit.\n  En outre, deux autres types de « produits » non liés au voyage peuvent être déclarés et référencés :\n  un PRODUIT OUVRANT DES DROITS peut également être utilisé pour représenter des qualifications non liées au transport telles que des cartes d\u0026rsquo;invalidité, des cartes militaires ou des laissez-passer de retraités qui sont des conditions préalables à l\u0026rsquo;achat ou à la consommation de produits de voyage.\n  un PRODUIT TIERS : UN PRODUIT TARIFAIRE qui est commercialisé avec un PRODUIT TARIFAIRE pour les transports publics mais qui n’y est pas lié (un accès à un salon, un abonnement sportif, etc.).\n  Produits Tarifaires – Modèle conceptuel\nLe DROIT A REDUCTION (SALE DISCOUNT RIGHT) est un PRODUIT TARIFAIRE (FARE PRODUCT) qui permet à son porteur de bénéficier d’une déduction lors de l’achat d’OFFREs A LA VENTE (SALES OFFER PACKAGE) particulières. Une carte de réduction ouvrant droit à une rabais de 25% sur les trajets en train d’une compagnie ferroviaire en est un exemple relativement classique.\nSaleDiscountRight – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; FareProduct ::\u0026gt; SALE DISCOUNT RIGHT hérite de FARE PRODUCT.  « PK » id SaleDiscountRightIdType 1:1 Identifiant du SALE DISCOUNT RIGHT.  « enum » ProductType SaleDiscountRightEnum 1:1 Classification du SALE DISCOUNT RIGHT.\n travelCard (carte voyageur)\npayAsYouGoRight (paiement au fur et à mesure)\nstatutoryRight (droit statutaire)\nother (autre)\n    La REDUCTION PAR PLAFONNEMENT (CAPPED DISCOUNT RIGHT) est un raffinement du DROIT A REDUCTION utilisé pour les tarifications de type « pay-as-you-go », où une fois qu\u0026rsquo;un certain niveau de consommation a été atteint dans un intervalle de temp donné, un plafond (tel que spécifié par une ou plusieurs RÈGLES DE PLAFONNEMENT) est appliqué, par exemple en limitant le coût, pour toute utilisation au cours d’une même journée, au prix d\u0026rsquo;un passe journalier.\nCappedDiscountRight – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; SaleDiscountRight ::\u0026gt; CAPPED DISCOUNT RIGHT hérite de SALE DISCOUNT RIGHT***.***   « PK » id CappedDiscountRightIdType 1:1 Identifiant du CAPPED DISCOUNT RIGHT.   « cntd » cappingRules CappingRule 0:* Un ensemble de paramètres fixant un prix plafond sur un produit.    CappingRule – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; PriceableObject ::\u0026gt; CAPPING RULE hérite de PRICEABLE OBJECT.  « PK » id CappingRuleIdType 1:1 Identifiant du CAPPING RULE.  « cntd » MaximumDistance LengthType 0:* Plafonnement de la distance de si la limite est basée sur la distance.  « enum » CappingPeriod CappingPeriodEnum 0:1 Période pendant laquelle le plafonnement s'applique, par ex. du quotidien. Voir les valeurs autorisées ci-dessous. Une valeur quantitative peut être définie avec une USAGE VALIDITY PERIOD, ainsi qu'une définition plus détaillée des heures de début et de fin.\n Day (jour)\nWeek (semaine)\nMonth (mois)\nNone (rien)\n  « FK » PreassignedFareProductRef PreassignedFareProductRef 0:1 PREASSIGNED FARE PRODUCT dont les prix plafonnent le prix pour ce produit.  « cntd » validityParameterAssignments ValidityParameterAssignment+ 0:* VALIDITY PARAMETER ASSIGNMENTS pour cette règle.    Un SUPPLÉMENT (SUPPLEMENT PRODUCT) et un produit accessoire, tel qu\u0026rsquo;un surclassement de classe de siège ou un repas, qui ne peut être acheté qu\u0026rsquo;en plus d\u0026rsquo;un autre produit.\nSupplementProduct – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; PreassignedFareProduct ::\u0026gt; SUPPLEMENT PRODUCT hérite de PREASSIGNED FARE PRODUCT.  « PK » id SupplementProductIdType 1:1 Identifiant du SUPPLEMENT PRODUCT.  « enum » SupplementProductType SupplementProductTypeEnum 0:1 Classification du SUPPLEMENT PRODUCT.\n seatReservation (réservation de place assise)\nbicycle (vélo)\ndog (chien)\nanimal (animal)\nmeal (repas)\nwifi (wifi)\nextraLuggage (bagage additionnel)\npenalty (amende)\nupgrade (sur classement)\njourneyExtension (extension de trajet)\njourneyAddOn (trajet additionel)\neventAddOn (évènement additionel)\nparking (parking)\ntopUp (rechargement)\nother (autre)\n   Choice   « FK » a SupplementToFareProductRef FareProductRef+ 0:1 Référence au PRE ASSIGNED FARE PRODUCT OFFER pour lequel ceci est un supplément.    La REDUCTION A L’USAGE (USAGE DISCOUNT RIGHT) est un PRODUIT TARIFAIRE permettant à son titulaire de bénéficier de remises basées sur sa consommation de titres de transport. Par exemple, un tel produit peut accorder à son détenteur une réduction pour un parking relai (« park and ride »), alors que le stationnement ou les trajets en transport en commun consommés seuls sont facturés au tarif normal. Le principe des « miles » accumulés, classiquement utilisés dans les transports longue distance, et aussi un exemple classique de REDUCTION A L’USAGE. Ce type de remise est particulièrement utilisé avec les méthodes post-paiement.\nUsageDiscountRight – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; FareProduct ::\u0026gt; USAGE DISCOUNT RIGHT hérite de FARE PRODUCT.  « PK » id UsageDiscounRightIdType 1:1 Identifiant du USAGE DISCOUNT RIGHT.  « enum » ProductType UsageDiscountRightEnum 1:1 Classification du USAGE DISCOUNT RIGHT.\n mileagePoints (miles)\nusageRebate (rabais à l’usage)\nother (autre)\n    Le MONTANT D’UNITÉS TARIFAIRE (AMOUNT OF PRICE UNIT PRODUCT) est un PRODUIT TARIFAIRE constitué d\u0026rsquo;une valeur stockée d\u0026rsquo;UNITÉS TARIFAIRE: une somme d\u0026rsquo;argent sur un porte-monnaie électronique, une quantité d\u0026rsquo;unités transport sur une carte, etc.\nAmountOfPriceUnitProduct – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; FareProduct ::\u0026gt; AMOUNT OF PRICE UNIT hérite de FARE PRODUCT.  « PK » id AmountOfPriceUnitIdType 1:1 Identifiant du AMOUNT OF PRICE UNIT.  « enum » ProductType AmountOfPriceUnitEnum 1:1 Classification du AMOUNT OF PRICE UNIT.\n tripCarnet (carnet)\npassCarnet (carnet de passes)\nunitCoupon (coupon unitaire)\nstoredValue (valeur)\nother (autre)\n  « FK » PriceUnitRef PriceUnitRef 0:1 Référence à un PRICE UNIT.   Amount xsd:decimal 0:1 Nombre d’unités.    Un PRODUIT TIERS (Third Party Product) est un PRODUIT TARIFAIRE commercialisé avec un PRODUIT TARIFAIRE pour les transports publics mais produit par une autre organisation, non liée au transport public. Ce produit ne sera naturellement pas entièrement décrit par les systèmes de transport. On peut, titre d’exemple, citer un titre de transport associé à un évènement (exposition, salon, évènement sportif).\nThirdPartyProduct – Element    Classification Name  Type Cardinality Description     ::\u0026gt; ::\u0026gt;  FareProduct ::\u0026gt; THIRD PARTY PRODUCT hérite de FARE PRODUCT.   « PK » id  ThirdPartyProductIdType 1:1 Identifiant du THIRD PARTY PRODUCT.      CHOICE     « cntd » a GeneralGroupOfEntities GeneralGroupOfEntities 0:1 GENERAL GROUP OF ENTITIES associé au THIRD PARTY PRODUCT.   « cntd » a GeneralGroupOfEntitiesRef GeneralGroupOfEntitiesRef 0:1 Référence à GENERAL GROUP OF ENTITIES associé au Third PARTY product.    Résumé Des Conditions Tarifaires Un RÉSUMÉ DES CONDITIONS TARIFAIRES (CONDITION SUMMARY) peut être utilisé pour fournir une description synthétique d\u0026rsquo;un produit à des fins de comparaison et d\u0026rsquo;information des voyageurs. Le résumé indique généralement simplement l\u0026rsquo;existence d\u0026rsquo;une condition - les conditions réelles elles-mêmes sont décrites plus exactement par les CONDITIONS D’UTILISATION, les AFFECTATIONS DE DROITS D\u0026rsquo;ACCÈS et d\u0026rsquo;autres éléments. Le résumé peut inclure des informations sur :\n  Les exigences concernant les cartes liées au produit.\n  Les conditions commerciales de remboursement, d\u0026rsquo;échange, etc.\n  Conditions limitant les temps de parcours, les itinéraires, etc.\n  Conditions relatives aux droits.\n  Conditions affectant la réservation.\n  La figure suivante montre le modèle physique du RÉSUMÉ DES CONDITIONS TARIFAIRES.\nRésume des conditions – Modèle physique\nNote : les attributs du ConditionSummary sont spécialisés par le profil NeTEx Tarif France. Ainsi certains sont uniquement destinés à être utilisés par les PRODUITs TARIFAIREs (Fare Product) et d’autres sont réservés aux OFFREs À LA VENTE (SalesPackageOffer). Cette restriction et ce systématisme ont pour vocation de simplifier l’usage d’un profil (placer une information donnée à un endroit unique quand cela est possible). Une colonne précisant PT (PRODUITs TARIFAIRE) ou OalV (OFFRE À LA VENTE) a été ajoutée pour préciser cette affectation (s’il n’y a pas de précision, l’attribut reste utilisable dans les deux cas).\nConditionSummary – Element   Classification Name Type Cardinality Description     « enum » FareStructureType FareStructureTypeEnum 1:1 Classification de la structure tarifaire.\n networkFlatFare (constant sur le réseau)\nlineFlatFare (constant par ligne)\nzonalFare (constant par zone)\nzoneToZoneFare (zone à zone)\nzoneSequenceFare (sequence de zones)\ncappedFlatFare (constant plafonné)\ncappedPointToPointFare (point à point plafonné)\ncappedZonalFare (zonal plafoné)\npointToPointFare (point à point)\npointToPointDistanceFare (tarification à la distance)\nstageFare (tarification par étapes)\npenaltyFare (amende)\nother (autre)\n PT  « enum » TariffBasis TariffBasisEnum 0:1 Base pour la tarification.\n Flat (constant)\nDistance (distance)\nunitSection (section)\nzone (zonal)\nzoneToZone (zone à zone)\npointToPoint (point à point)\nroute (itinéraire)\ntour (tour)\ngroup (group)\ndiscount (rabais)\nperiod (période)\nfree (gratuit)\nother (autre)\n PT   HasNotices xsd:boolean 0:1 Indique si une NOTICE est associée au produit.\nNote : la NOTICE doit systématiquement être affichée en contexte d’information voyageur\n   XGRP ConditionSummaryCardGroup xmlGroup 1:1 Éléments relatif aux cartes de paiement dans le CONDITION SUMMARY.   XGRP ConditionSummaryEntitlementGroup xmlGroup 1:1 Éléments relatif aux droits ouverts dans le CONDITION SUMMARY.   XGRP ConditionSummaryTravelGroup xmlGroup 1:1 Éléments relatif aux conditions de voyage dans le CONDITION SUMMARY.   XGRP ConditionSummaryCommercialGroup xmlGroup 1:1 Éléments relatif aux conditions commerciales dans le CONDITION SUMMARY.   XGRP ConditionSummaryReservationGroup xmlGroup 1:1 Éléments relatif aux conditions de réservation dans le CONDITION SUMMARY.   XGRP ConditionSummaryChargingGroup xmlGroup 1:1 Éléments relatif aux conditions de recharge dans le CONDITION SUMMARY.     ConditionSummaryCardGroup – Group    Classification Name Type Cardinality Description       ProvidesCard xsd:boolean 0:1 Indique si une carte est fournie avec le produit. OalV    GoesOnCard xsd:boolean 0:1 Indique si le produit va sur une carte. OalV    IsPersonal xsd:boolean 0:1 Indique si que le produit est vendu de manière anonyme ou à une personne identifiée. OalV    RequiresPhoto xsd:boolean 0:1 Indique si l\u0026rsquo;utilisation du produit nécessite la fourniture d\u0026rsquo;une photo. OalV    MustCarry xsd:boolean 0:1 Indique si la carte, le support, doit être transporté lors du déplacement afin d\u0026rsquo;utiliser le produit. OalV    RequiresAccount xsd:boolean 0:1 Indique si le produit nécessite que l\u0026rsquo;utilisateur crée un compte pour la facturation. OalV    ConditionSummaryEntitlementGroup – Group    Classification Name Type Cardinality Description       IsSupplement xsd:boolean 0:1 Indique si le produit est un complément à un autre produit PT    RequiresEntitlement xsd:boolean 0:1 Indique si le produit nécessite un droit ouvert par d\u0026rsquo;autres produits. PT    GivesEntitlement xsd:boolean 0:1 Indique si le produit ouvre des droits à d\u0026rsquo;autres produits. PT    ConditionSummaryTravelGroup – Group   Classification Name Type Cardinality Description     « enum » HasOperatorRestrictions OperatorRestrictionEnum 0:1 Limitations quant à l'OPÉRATEUR pouvant être utilisé\n anyTrain (n’importe quel train)\nrestricted (limité)\nspecifiedOperatorOnly (opérateurs spéciaux seulement)\n PT   HasTravelTimeRestrictions xsd:boolean 0:1 Indique si des limitations s'appliquent quant au moment où le voyage peut avoir lieu. PT   HasRouteRestrictions xsd:boolean 0:1 Indique si des limitations s'appliquent à l'itinéraire qui peut être utilisé. PT  « enum » HasTrainRestrictions TrainRestrictionEnum 0:1 Limitations quant aux trains pouvant être utilisés.\n anyTrain (n’importe quel train\nrestricted (limité)\nspecifiedTrainOnly (train unique)\nspecifiedTrainsOnly (certains trains)\nspecifiedTrainAndConnections (train unique et correspondances)\n PT   HasZoneRestrictions xsd:boolean 0:1 Indique si des limitations s'appliquent quant à la zone dans laquelle le voyage peut avoir lieu. PT   CanBreakJourney xsd:boolean 0:1 Indique si l'utilisateur est autorisé à interrompre le trajet, c'est-à-dire à quitter le réseau de transport, à un point intermédiaire, puis à reprendre son trajet. PT   ReturnTripsOnly xsd:boolean 0:1 Indique si trajet retour doit impérativement être acheté. PT    ConditionSummaryCommercialGroup – Group    Classification Name Type Cardinality Description       CanChangeClass xsd:boolean 0:1 Indique si l\u0026rsquo;utilisateur peut changer de classe PT    IsRefundable xsd:boolean 0:1 Indique si le billet est remboursable OalV    IsExchangable xsd:boolean 0:1 Indique si le billet est échangeable OalV    HasExchangeFee xsd:boolean 0:1 Indique s\u0026rsquo;il y a des frais pour les échanges. OalV    HasDiscountedFares xsd:boolean 0:1 Indique si les tarifs réduits sont autorisés. PT    AllowAdditionalDiscounts xsd:boolean 0:1 Indique si plusieurs remises peuvent être appliquées, par ex. Enfant + Accompagnateur. PT    AllowCompanionDiscount xsd:boolean 0:1 Indique s\u0026rsquo;il y a une remise pour les accompagnateur. PT    HasMinimumPrice xsd:boolean 0:1 Indique s\u0026rsquo;il y a un prix minimum lors de la combinaison de remises. PT    RequiresPositiveBalance xsd:boolean 0:1 Indique si le produit nécessite un solde positif (généralement sur une carte de transport) pour être utilisé. OalV    ConditionSummaryReservationGroup – Group    Classification Name Type Cardinality Description       PenaltyWIthoutTicket xsd:boolean 0:1 Indique s\u0026rsquo;il y a une pénalité pour voyager sans billet, c\u0026rsquo;est-à-dire que les billets ne peuvent pas être achetés à bord. OalV    AvailableOnSubscription xsd:boolean 0:1 Indique si le produit est disponible sur abonnement. OalV    ConditionSummaryReservationGroup – Group    Classification Name Type Cardinality Description       HasPurchaseConditions xsd:boolean 0:1 Indique si les conditions d\u0026rsquo;achat s\u0026rsquo;appliquent à la vente du produit, par ex. quand doit être acheté ou qui peut acheter. OalV    HasDynamicPricing xsd:boolean 0:1 Indique si le produit a une tarification dynamique. PT    RequiresReservation xsd:boolean 0:1 Indique si le produit nécessite une réservation. OalV    HasReservationFee xsd:boolean 0:1 Indique si la réservation est payante. OalV    HasQuota xsd:boolean 0:1 Indique qu\u0026rsquo;il y a un quota limité pour l\u0026rsquo;offre ou qu\u0026rsquo;elle est vendue en nombre illimité. OalV    Exemple Exemple 1 (simple)\n\u0026lt;!-- LE TITRE --\u0026gt; \u0026lt;PreassignedFareProduct id=\u0026#34;FR-Tarif-Example:PreassignedFareProduct:T+001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Ticket 1h30\u0026lt;/Name\u0026gt; \u0026lt;AuthorityRef ref=\u0026#34;FR-Tarif-Example:Authority:IDFM:\u0026#34;/\u0026gt; \u0026lt;ConditionSummary\u0026gt; \u0026lt;TariffBasis\u0026gt;period\u0026lt;/TariffBasis\u0026gt; \u0026lt;CanBreakJourney\u0026gt;false\u0026lt;/CanBreakJourney\u0026gt; \u0026lt;IsRefundable\u0026gt;false\u0026lt;/IsRefundable\u0026gt; \u0026lt;IsExchangable\u0026gt;false\u0026lt;/IsExchangable\u0026gt; \u0026lt;/ConditionSummary\u0026gt; \u0026lt;validableElements\u0026gt; \u0026lt;ValidableElementRef ref=\u0026#34;FR-Tarif-Example:ValidableElement:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;/validableElements\u0026gt; \u0026lt;ProductType\u0026gt;singleTrip\u0026lt;/ProductType\u0026gt; \u0026lt;/PreassignedFareProduct\u0026gt; Exemple 2\n\u0026lt;PreassignedFareProduct id=\u0026#34;FR-Tarif-Example:PreassignedFareProduct:Paris-Lille-001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Paris-Lille\u0026lt;/Name\u0026gt; \u0026lt;!--NOTE : OU \u0026#34;billet OD TGV\u0026#34; SI ON FAIT DE LA MUTUALISATION--\u0026gt; \u0026lt;noticeAssignments\u0026gt; \u0026lt;NoticeAssignment\u0026gt; \u0026lt;NoticeRef ref=\u0026#34;FR-Tarif-Example:Notice:002:LOC\u0026#34;/\u0026gt; \u0026lt;/NoticeAssignment\u0026gt; \u0026lt;/noticeAssignments\u0026gt; \u0026lt;ChargingMomentType\u0026gt;beforeTravel\u0026lt;/ChargingMomentType\u0026gt; \u0026lt;OperatorRef ref=\u0026#34;FR-Tarif-Example:Authority:SNCF:\u0026#34;/\u0026gt; \u0026lt;ConditionSummary\u0026gt; \u0026lt;FareStructureType\u0026gt;pointToPointFare\u0026lt;/FareStructureType\u0026gt; \u0026lt;TrainRestrictions\u0026gt;specifiedTrainOnly\u0026lt;/TrainRestrictions\u0026gt; \u0026lt;CanBreakJourney\u0026gt;false\u0026lt;/CanBreakJourney\u0026gt; \u0026lt;IsRefundable\u0026gt;false\u0026lt;/IsRefundable\u0026gt; \u0026lt;IsExchangable\u0026gt;false\u0026lt;/IsExchangable\u0026gt; \u0026lt;HasExchangeFee\u0026gt;true\u0026lt;/HasExchangeFee\u0026gt; \u0026lt;HasDynamicPricing\u0026gt;true\u0026lt;/HasDynamicPricing\u0026gt; \u0026lt;!--YIELD MANANGED--\u0026gt; \u0026lt;RequiresReservation\u0026gt;true\u0026lt;/RequiresReservation\u0026gt; \u0026lt;!--inclue dans le titre--\u0026gt; \u0026lt;HasReservationFee\u0026gt;false\u0026lt;/HasReservationFee\u0026gt; \u0026lt;/ConditionSummary\u0026gt; \u0026lt;validityParameterAssignments\u0026gt; \u0026lt;GenericParameterAssignment\u0026gt; \u0026lt;LimitationGroupingType\u0026gt;AND\u0026lt;/LimitationGroupingType\u0026gt; \u0026lt;limitations\u0026gt; \u0026lt;ReservingRef ref=\u0026#34;FR-Tarif-Example:Reserving:001:LOC\u0026#34;/\u0026gt; \u0026lt;ExchangingRef ref=\u0026#34;FR-Tarif-Example:Exchanging:001:LOC\u0026#34;/\u0026gt; \u0026lt;ExchangingRef ref=\u0026#34;FR-Tarif-Example:Exchanging:002:LOC\u0026#34;/\u0026gt; \u0026lt;ExchangingRef ref=\u0026#34;FR-Tarif-Example:Exchanging:003:LOC\u0026#34;/\u0026gt; \u0026lt;ExchangingRef ref=\u0026#34;FR-Tarif-Example:Exchanging:004:LOC\u0026#34;/\u0026gt; \u0026lt;RefundingRef ref=\u0026#34;FR-Tarif-Example:Refunding:001:LOC\u0026#34;/\u0026gt; \u0026lt;RefundingRef ref=\u0026#34;FR-Tarif-Example:Refunding:002:LOC\u0026#34;/\u0026gt; \u0026lt;RefundingRef ref=\u0026#34;FR-Tarif-Example:Refunding:003:LOC\u0026#34;/\u0026gt; \u0026lt;/limitations\u0026gt; \u0026lt;validityParameters\u0026gt; \u0026lt;VehicleModes\u0026gt;rail\u0026lt;/VehicleModes\u0026gt; \u0026lt;/validityParameters\u0026gt; \u0026lt;/GenericParameterAssignment\u0026gt; \u0026lt;/validityParameterAssignments\u0026gt; \u0026lt;validableElements\u0026gt; \u0026lt;ValidableElementRef ref=\u0026#34;FR-Tarif-Example:ValidableElement:002:LOC\u0026#34;/\u0026gt; \u0026lt;!--etc. VOIR NOTE SUR ProductType --\u0026gt; \u0026lt;!--NOTE: On peut aussi définit le VE ici plutôt que de le référencer--\u0026gt; \u0026lt;/validableElements\u0026gt; \u0026lt;ProductType\u0026gt;singleTrip\u0026lt;/ProductType\u0026gt; \u0026lt;!--NOTE IMPORTANTE: si le produit est \u0026#34;single trip\u0026#34; alors un seul de ValidableElement est utilisable, même s\u0026#39;il y a plusieurs VE: cela permet de gérer les cas ou un produit donne accès à une droit A OU B OU C .... On pourra aussi utliser ce mécanisme pour faire un unique produit O-D, contenant de très nombreuses O-D, mais avec une seule tarification comme dans le cas du Yield Management ...--\u0026gt; \u0026lt;/PreassignedFareProduct\u0026gt; Les Offres à la Vente (SalesPackageOffer) Les PRODUITS TARIFAIREs sont associés à des DOCUMENTS DE VOYAGE afin de constituer des packages propices à la vente. Une OFFRE A LA VENTE est définie comme un ensemble, constitué d\u0026rsquo;un ou plusieurs PRODUITS TARIFAIREs matérialisés grâce à un ou plusieurs DOCUMENTS DE VOYAGE.\nLes PRODUITS TARIFAIREs peuvent être soit directement attachés aux DOCUMENTS DE VOYAGE (impression, stockage magnétique, etc.), soit rechargeables sur des DOCUMENTS DE VOYAGE (tels que des porte-monnaies électroniques ou des laissez-passer).\nDans la plupart des cas, une OFFRE A LA VENTE ne comprendra qu\u0026rsquo;un seul PRODUIT TARIFAIRE sur un DOCUMENT DE VOYAGE, mais des combinaisons plus complexes sont possibles. Elles permettent aussi de proposer des packages temporaires (par exemple pendant une semaine de promotion) ou permanents.\nLes OFFRE A LA VENTE sont décrites par des ÉLÉMENTS D\u0026rsquo;OFFRE DE VENTE, chacun associant un PRODUIT TARIFAIRE spécifique à un TYPE DE DOCUMENT DE VOYAGE spécifique.\nUne OFFRE A LA DE VENTE peut parfois être soumise à des limitations : par exemple n’être vendu que dans une certaine ZONE D\u0026rsquo;ARRÊT.\nOffre à la Vente – Modèle conceptuel\nLes tableaux ci-dessous présentent les attributs des OFFRE A LA VENTE retenus dans le cadre du profil.\nSalesOfferPackage – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; PriceableObject ::\u0026gt; SALES OFFER PACKAGE hérite de PRICEABLE OBJECT.\nNote : cet héritage fournit entre autres un attribut noticeAssignments ; dans le contexte de ce profil, c’est au niveau des SalesOfferPackage et FareProducts que l’on placera les Notices.\n  « PK » id SalesOfferPackageIdType 1:1 Identifiant du a SALES OFFER PACKAGE.  « AK » PrivateCode PrivateCodeType 0:1 Identifiant alternatif d'une entité. peut être utilisé pour s'associer à des systèmes existants.  XGRP SalesOfferPackageCommonGroup xmlGroup 0:1 Propriétés communes au SALES OFFER PACKAGE et au GROUP OF SALES OFFER PACKAGEs.    SalesOfferPackageCommonGroup – Element   Classification Name Type Cardinality Description    « FK » TypeOfSalesOfferPackageRef TypeOfSalesOfferPackageRef 0:1 Type of SALES OFFER PACKAGE.  « cntd » ConditionSummary ConditionSummary 0:1 Description synthétique des conditions d'une OFFRE A LA VENTE pouvant être utilisée pour fournir des informations aux passagers.\nNote : dans le cadre du profil, seuls certains attributs des ConditionSummary sont acceptés pour le SalesOfferPackage (voir description des ConditionSummary plus haut).\n  « cntd » validityParameterAssignments GenericAccessRightParameterAssignment 0:* GENERIC PARAMETER ASSIGNMENTs (i.e. ACCESS RIGHT PARAMETER ASSIGNMENTs) associé au SALES OFFER PACKAGE.  « cntd » distributionAssignments DistributionAssignment 0:* DISTRIBUTION ASSIGNMENTs pour le SALES OFFER PACKAGE.  « cntd » salesOfferPackageElements SalesOfferPackageElement 0:* SALES OFFER PACKAGE ELEMENTs associé au SALES OFFER PACKAGE.\nNote : on n’utilisera ici la possibilité de faire des références que s’il y a réutilisation du SalesOfferPackageElement, dans tous les autres cas on inculera directement le SalesOfferPackageElement dans la structure XML.\n    Les OFFRE A LA VENTE sont décrites par des ÉLÉMENTS D\u0026rsquo;OFFRE DE VENTE, chacun associant un PRODUIT TARIFAIRE spécifique à un TYPE DE DOCUMENT DE VOYAGE spécifique.\nSalesOfferPackageElement – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; PriceableObject ::\u0026gt; SALES OFFER PACKAGE ELEMENT hérite de PRICEABLE OBJECT.  « PK » id SalesOfferPackageElementIdType 1:1 Identifiant du SALES OFFER PACKAGE ELEMENT.   RequiresValidation xsd:boolean 0:1 Indique si l'élément nécessite une validation avant de pouvoir être utilisé.  « cntd » ConditionSummary ConditionSummary 0:1 Description synthétique du SALES OFFER PACKAGE.\nNote : dans le cadre du profil, seuls certains attributs des ConditionSummary sont acceptés pour le SalesOfferPackage (voir description des ConditionSummary plus haut).\n  « FK » TypeOfTravelDocumenRef TypeOfTravelDocumentRef 0:1 Référence à un TYPE OF TRAVEL DOCUMENT.\nNote : si un FareProduct est disponible sur plusieurs types de média, il faut créer plusieurs SalesOfferPackageElement\n  « FK » FareProductRef FareProductRef+ 0:1 FARE PRODUCT associé au SALES OFFER PACKAGE.  « cntd » validityParameterAssignments GenericParameterAssignment 0:* GENERIC PARAMETER ASSIGNMENTs associé au SALES OFFER PACKAGE ELEMENT.    GroupOfSalesOfferPackages – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; GroupOfEntities ::\u0026gt; GROUP of SALES OFFER PACKAGEs hérite de GROUP OF ENTITIES. Voir NeTEx Partie 1.   « PK » id GroupOfSalesOffer-PackagesIdType 1:1 Identifiant du GROUP of SALES OFFER PACKAGEs.   « cntd » alternativeNames AlternativeName 0:* ALTERNATIVE NAMEs for GROUP of SALES OFFER PACKAGEs.   XGRP SalesOfferPackageCommonGroup xmlGroup 0:1 Propriétés communes du SALES OFFER PACKAGE et du GROUP OF SALES OFFER PACKAGES.   « cntd » members SalesOfferPackageRef 0:* Références aux constituants du GROUP OF SALES OFFER PACKAGEs.    Exemple \u0026lt;SalesOfferPackageElement id=\u0026#34;FR-Tarif-Example:SalesOfferPackageElement:001:LOC\u0026#34; version=\u0026#34;any\u0026#34; order=\u0026#34;1\u0026#34;\u0026gt; \u0026lt;RequiresValidation\u0026gt;true\u0026lt;/RequiresValidation\u0026gt; \u0026lt;TypeOfTravelDocumentRef ref=\u0026#34;FR-Tarif-Example:TypeOfTravelDocument:001:LOC\u0026#34;/\u0026gt; \u0026lt;PreassignedFareProductRef ref=\u0026#34;FR-Tarif-Example:PreassignedFareProduct:T+001:LOC\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;/SalesOfferPackageElement\u0026gt; \u0026lt;TypeOfTravelDocument id=\u0026#34;FR-Tarif-Example:TypeOfTravelDocument:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Ticket T+ carton a bande magn\u0026amp;#xE9;tique\u0026lt;/Name\u0026gt; \u0026lt;Url\u0026gt;http://www.navigo.fr/wp-content/uploads/2018/11/127099_Ticket-T_carnet-de-10-300x136.png\u0026lt;/Url\u0026gt; \u0026lt;MediaType\u0026gt;paperTicket\u0026lt;/MediaType\u0026gt; \u0026lt;MachineReadable\u0026gt;magneticStrip\u0026lt;/MachineReadable\u0026gt; \u0026lt;/TypeOfTravelDocument\u0026gt; \u0026lt;SalesOfferPackage id=\u0026#34;FR-Tarif-Example:SalesOfferPackage:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Ticket \u0026amp;#xE0; l\u0026#39;unit\u0026amp;#xE9;\u0026lt;/Name\u0026gt; \u0026lt;salesOfferPackageElements\u0026gt; \u0026lt;SalesOfferPackageElementRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackageElement:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;/salesOfferPackageElements\u0026gt; \u0026lt;/SalesOfferPackage\u0026gt; \u0026lt;SalesOfferPackage id=\u0026#34;FR-Tarif-Example:SalesOfferPackage:002:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Carnet de 10 Ticket\u0026lt;/Name\u0026gt; \u0026lt;validityParameterAssignments\u0026gt; \u0026lt;GenericParameterAssignment\u0026gt; \u0026lt;limitations\u0026gt; \u0026lt;UsageValidityPeriod\u0026gt; \u0026lt;ValidityPeriodType\u0026gt;carnet\u0026lt;/ValidityPeriodType\u0026gt; \u0026lt;/UsageValidityPeriod\u0026gt; \u0026lt;/limitations\u0026gt; \u0026lt;/GenericParameterAssignment\u0026gt; \u0026lt;/validityParameterAssignments\u0026gt; \u0026lt;salesOfferPackageElements\u0026gt; \u0026lt;SalesOfferPackageElementRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackageElement:001:LOC\u0026#34;/\u0026gt; \u0026lt;SalesOfferPackageElementRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackageElement:001:LOC\u0026#34;/\u0026gt; \u0026lt;SalesOfferPackageElementRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackageElement:001:LOC\u0026#34;/\u0026gt; \u0026lt;SalesOfferPackageElementRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackageElement:001:LOC\u0026#34;/\u0026gt; \u0026lt;SalesOfferPackageElementRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackageElement:001:LOC\u0026#34;/\u0026gt; \u0026lt;SalesOfferPackageElementRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackageElement:001:LOC\u0026#34;/\u0026gt; \u0026lt;SalesOfferPackageElementRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackageElement:001:LOC\u0026#34;/\u0026gt; \u0026lt;SalesOfferPackageElementRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackageElement:001:LOC\u0026#34;/\u0026gt; \u0026lt;SalesOfferPackageElementRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackageElement:001:LOC\u0026#34;/\u0026gt; \u0026lt;SalesOfferPackageElementRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackageElement:001:LOC\u0026#34;/\u0026gt; \u0026lt;/salesOfferPackageElements\u0026gt; \u0026lt;/SalesOfferPackage\u0026gt; Document de voyage Le TYPE DE DOCUMENT DE VOYAGE indique les matérialisations possibles des produits tarifaires sur un support.\nLes DOCUMENTs DE VOYAGE sont généralement attribués aux clients à l\u0026rsquo;occasion d\u0026rsquo;une TRANSACTION DE VENTE.\nLes DOCUMENTs DE VOYAGE sont gérés individuellement dans une base de données opérateur, s\u0026rsquo;ils appartiennent à des clients identifiés (carte de valeur rechargeable, document de droit de remise, etc.). Ceci est bien sûr obligatoire pour les méthodes de post-paiement.\nLes DOCUMENTs DE VOYAGE sont catégorisés par un TYPE DE DOCUMENT DE VOYAGE, qui exprime :\n  leurs caractéristiques générales (type de support, types de produits tarifaires compatibles, etc.) ;\n  leurs caractéristiques fonctionnelles locales, propres à l\u0026rsquo;opérateur ou à la collectivité (produits tarifaires spécifiques stockés sur ce type, type de revendeur, etc.).\n  Les types le plus classiques de DOCUMENTS DE VOYAGE sont par exemple :\n  billet jetable à usage unique, donnant le droit de consommer un seul ELEMENT VALIDABLE (par exemple un voyage) ;\n  billet jetable, offrant un droit d\u0026rsquo;accès en utilisant un certain nombre d\u0026rsquo;unités (généralement en les poinçonnant ensemble dans un validateur) ;\n  carte, débitée d\u0026rsquo;un certain montant pour chaque consommation d\u0026rsquo;ÉLÉMENTS VALIDABLES ;\n  porte-monnaie électronique rechargeable, permettant l\u0026rsquo;accès au réseau de transport, débité à chaque achat ;\n  Carte de crédit transport, avec post-paiement sur un compte central ;\n  document attestant le droit de bénéficier d\u0026rsquo;une réduction ;\n  etc.\n  TypeOfTravelDocument – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; TypeOfValue ::\u0026gt; TYPE OF TRAVEL DOCUMENT hérite de TYPE OF VALUE. Voir NeTEx Partie 1.  « PK » id TypeOfTravelDocumentIdType 1:1 Identifiant du TYPE OF TRAVEL DOCUMENT.   IsCard xsd:boolean 0:1 Indique si le TRAVEL DOCUMENT est matérialisé sous forme de carte.   IsSmartCard xsd:boolean 0:1 Indique si le TRAVEL DOCUMENT est matérialisé sous forme d’une carte à puce ou d’un appareil mobile.   HasPhoto xsd:boolean 0:1 Indique si le TRAVEL DOCUMENT comporte une photo.  « enum » MediaType MediaTypeEnum 0:1 Classification du TRAVEL DOCUMENT par type de média :\n none (aucun)\npaperTicket (ticket papier)\npaperTicketWithCoupons (ticket papier et coupon)\ncoupon (coupon)\nselfPrintPaperTicket (impression à domicile)\nsmartCard (carte à puce)\nmobileApp (application sur mobile)\ncard (carte)\nmms (MMS)\nsms (SMS)\nother (autre)\n  « enum » MachineReadable MachineReadableEnum 0:* Classification du the TRAVEL DOCUMENT par mécanisme de lecture en machine :\n none (aucun)\nmagneticStrip (bande magnétique)\nchip (puce)\nocr (reconnaissance de caractères)\nbarCode (code barre)\nshotCode (numéro d’émission)\nnfc (NFC)\nother (autre)\n  « cntd » typesOfMachineReadabilities TypeOfMachineReadabilityRef 0:* Classification du TRAVEL DOCUMENT par TYPE OF MACHINE READABILITY.  « cntd » alternativeNames AlternativeName 0:* ALTERNATIVE NAMEs pour l’élément.    Exemples \u0026lt;TypeOfTravelDocument id=\u0026#34;FR-Tarif-Example:TypeOfTravelDocument:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;E-Billet\u0026lt;/Name\u0026gt; \u0026lt;Description\u0026gt;Billet \u0026amp;#xE9;lectronique \u0026amp;#xE0; Flashcode, imprim\u0026amp;#xE9; sur papier ou viualis\u0026amp;#xE9; sur terminal \u0026amp;#xE9;lectronique (smartphone)\u0026lt;/Description\u0026gt; \u0026lt;Url\u0026gt;https://www.oui.sncf/aide/le-e-billet\u0026lt;/Url\u0026gt; \u0026lt;MediaType\u0026gt;other\u0026lt;/MediaType\u0026gt; \u0026lt;!--\u0026#34;Other\u0026#34; car il n\u0026#39;y a pas qu\u0026#39;un unique support physique ... on pourrait aussi ne pas faire figurer cet élément--\u0026gt; \u0026lt;MachineReadable\u0026gt;barCode\u0026lt;/MachineReadable\u0026gt; \u0026lt;/TypeOfTravelDocument\u0026gt; \u0026lt;TypeOfTravelDocument id=\u0026#34;FR-Tarif-Example:TypeOfTravelDocument:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Ticket T+ carton a bande magn\u0026amp;#xE9;tique\u0026lt;/Name\u0026gt; \u0026lt;Url\u0026gt;http://www.navigo.fr/wp-content/uploads/2018/11/127099_Ticket-T_carnet-de-10-300x136.png\u0026lt;/Url\u0026gt; \u0026lt;MediaType\u0026gt;paperTicket\u0026lt;/MediaType\u0026gt; \u0026lt;MachineReadable\u0026gt;magneticStrip\u0026lt;/MachineReadable\u0026gt; \u0026lt;/TypeOfTravelDocument\u0026gt; Canal de distribution (DistributionChannel) Le modèle de distribution des titres de transport spécifie les règles pour savoir où et comment les PRODUITs TARIFAIREs peuvent être achetés, par exemple au comptoir, en ligne, via des distributeurs automatiques de billets en libre-service, etc.\nLe CANAL DE DISTRIBUTION et de la MÉTHODE DE RETRAIT - comment un achat est ensuite livré - sont séparées car ils peuvent être distinctes. Par exemple, un produit acheté en ligne peut être délivré soit par courrier, auto-impression, collecte à partir d\u0026rsquo;une machine ou par ajout automatique à un compte en ligne. Lorsque certaines facilités, telles que les remboursements, sont limitées à certains points de vente, cela peut également être indiqué.\nDistributionChannel – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; TypeOfValue ::\u0026gt; DISTRIBUTION CHANNEL hérite de TYPE OF VALUE. Voir NeTEx Partie 1.  « PK » id DistributionChannelIdType 1:1 Identifiant du DISTRIBUTION CHANNEL.  « cntd » alternativeNames AlternativeName 0:* Nom alternatif du DISTRIBUTION CHANNEL.  « enum » DistributionChannelType DistributionChannelTypeEnum 0:1 Type de DISTRIBUTION CHANNEL.\n atStop (à l’arrêt)\nonBoard (à bord)\nonline (en ligne)\nonlineAccount (sur compte en ligne)\ntelephone(par téléphone)\nelectronicPass (passe électronique)\npostal (postal)\nmobileDevice (sur terminal mobile)\nagency (en agence)\ntourOperator (par agence de voyage)\nother (autre)\n   IsObligatory xsd:boolean 0:1 Indique si l’utilisation du DISTRIBUTION CHANNEL est obligatoire (et donc qu'elle doit être autorisée).   RequiresEmailAddress xsd:boolean 0:1 L'utilisation du canal nécessite une adresse e-mail.  « FK » OrganisationRef (OrganisationRef) 0:1 ORGANISATION associée au channel.  « enum » PaymentMethods PaymentMethodEnum 0:* Méthode de paiement supportée\n cash (liquide)\ncashExactChangeOnly (liquide sans rendu de monaie)\ncashAndCard (liquide et cartes)\ncoin (pièces)\nbanknote (billets)\ncheque (chèque)\ntravellersCheque (traveller chèque)\npostalOrder (mandat postal)\ncompanyCheque (chèque d’entreprise)\ncreditCard (carte de crédit)\ndebitCard (carte de débit)\ncardsOnly (cartes uniquement)\ntravelCard (carte de transport)\ncontactlessPaymentCard (paiement sans contact)\ncontactlessTravelCard (carte de transport sans contact)\ndirectDebit (prélèvement)\nbankTransfer (virement bancaire)\nepayDevice (paiement électronique)\nepayAccount (compte électronique)\nsms (par SMS)\nmobilePhone (par télépohne portable)\nmobileApp (par Application sur téléphone ou ordinateur)\nvoucher (voucher/bon)\ntoken (jeton)\nwarrant (madat)\nmileagePoints (miles)\nother (autre)\n  « cntd » typesOfPaymentMethod TypeOfPaymentMethodRef 0:* Type libre pour la PAYMENT METHOD  « enum » DistributionRights DistributionRightsEnum 0:1 Droit de distribution du DISTRIBUTION CHANNEL.\n None (aucun)\nSell (vente)\nExchange (échange)\nRefund (reboursement)\nInform (information)\nPrivate (privé)\nOther (autre)\n  « cntd » distributionPoints PointRef+ 0:* Points auxquels la distribution est limitée, le cas échéant. Par exemple, qu'un billet ne peut être acheté qu'à une gare spécifique.  « FK » DistributionGroupRef GroupOfEntitiesRef 0:1 GROUPE D'ENTITÉS, par ex. lieux, organisations ou autres entités (par exemple, trajets spécifiques à bord ou lieux de services) auxquels la distribution est restreinte, le cas échéant. Par exemple, qu'un billet ne peut être acheté qu'à une gare spécifique.    DistributionAssignment – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; Assignment ::\u0026gt; DISTRIBUTION ASSIGNMENT hérite de ASSIGNMENT.   « PK » id DistributionAssignmentIdType 1:1 Identifiant du a DISTRIBUTION ASSIGNMENT.   « FK » ServiceAccessRightRef ServiceAccessRightRef 0:1 SERVICE ACCESS RIGHT (FARE PRODUCT) auquel on associe une DISTRIBUTION ASSIGNMENT.   « FK » SalesOfferPackageRef SalesOfferPackageRef 0:1 SALES OFFER PACKAGE auquel on associe une DISTRIBUTION ASSIGNMENT.   « FK » GroupOfSalesOfferPackagesRef GroupOfSalesOfferPackagesRef 0:1 GROUP OF SALES OFFER PACKAGEs auquel on associe une DISTRIBUTION ASSIGNMENT.    DistributionRights xmlGroup 0:1 Droits de distribution associé au DISTRIBUTION ASSIGNMENT.   XGRP DistributionThroughGroup xmlGroup 0:1 Éléments régissant les canaux par lesquels la distribution peut être effectuée.   XGRP DistributionByGroup xmlGroup 0:1 Éléments indiquent qui peut distribuer.   XGRP DistributionDetailsGroup xmlGroup 0:1 Éléments détaillant la distribution.    Table 74 – DistributionThroughGroup – Element\n   Classification Name  Type Cardinality Description        CHOICE  Pays/Région/Ville dans lequel la distribution peut avoir lieu.   « FK » TopographicPlaceRef  TopographicPlaceRef 0:1 TOPOGRAPHIC PLACE associé au DISTRIBUTION ASSIGNMENT.      CHOICE  Canal par lequel la distribution peut être effectuée.    a AllDistributionChannelsRef AllDistributionChannelsRef 0:1 La distribution peut se faire par tous les canaux.   « FK » b DistributionChannelRef DistributionChannelRef 0:1 DISTRIBUTION CHANNEL associé au DISTRIBUTION ASSIGNMENT.   « FK » c GroupOfDistributionChannelsRef GroupOfDistributionChannelsRef 0:1 GROUP OF DISTRIBUTION CHANNELs associé au DISTRIBUTION ASSIGNMENT.    AllowedInChannel  xsd:boolean 0:1 Indique si la distribution est autorisée ou interdite par le DISTRIBUTION CHANNEL spécifié.    RestrictedToChannel  xsd:boolean 0:1 Indique si la distribution est limitée aux seuls DISTRIBUTION CHANNEL spécifiés.    DistributionByGroup– Element    Classification Name  Type Cardinality Description      InitialCarrier  xsd:boolean 0:1 Distribution par transporteur de la première étape du voyage.    FinalCarrier  xsd:boolean 0:1 Distribution par transporteur de la dernière étape du voyage.      Choice  Organisation qui peut effectuer la distribution.   « FK » a AllOrganisationsRef AllOrganisationsRef 0:1 Toutes ORGANISATIONs qui peuvent distribuer.   « FK » b OrganisationRef (OrganisationRef) 0:1 ORGANISATION désignée par ce DISTRIBUTION ASSIGNMENT.   « FK » ResponsibilitySetRef  ResponsibilitySetRef 0:1 RESPONSIBILITY SET associé au DISTRIBUTION ASSIGNMENT.    DistributionDetailsGroup– Element   Classification Name Type Cardinality Description    « enum » TicketingServiceFacility TicketingServiceFacilityEnum 0:* Liste des TICKETING SERVICE FACILITies, par ex. achat, collecte, faire le plein.\n Purchase (achat)\nCollection (collection)\ncardTopUp (recharge de carte)\nreservations (réservations)\nexchange (échange)\nrefund (remboursement)\nrenewal (renouvellement)\nexcessFares (ajustements)\nother (autre)\nall (tous)\n   RequiresRegistration xsd:boolean 0:1 Indique si la distribution nécessite que le client enregistre une identité personnelle en ligne ou autrement.  « FK » FulfilmentMethodRef FulfilmentMethodRef 0:1 FULFILMENT METHOD à utiliser pour cette distribution.    Le MODE DE REMISE (FULFILMENT METHOD) est le moyen par lequel le titre de transport est délivré au client, par exemple en ligne, retrait en station, etc.\nFulfilmentMethod – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; PriceableObject ::\u0026gt; FULFILMENT METHOD hérite de PRICEABLE OBJECT.  « PK » id FulfillmentMethodIdType 1:1 Identifiant du FULFILMENT METHOD.  « enum » FulfilmentMethodType FulfilmentMethodTypeEnum 0:1 Type de FULFILMENT METHOD.\n ticketOffice (guichet)\nticketMachine (machine)\nconductor (conducteur)\nagent (agent)\npost (poste)\ncourier (courrier)\nselfprint (impression à domicile)\nsms (SMS)\nemail (email)\ntopUpDevice (équipement de rechargement)\nvalidator (validateur)\nmobileApp (application mobile)\nother (autre)\n   RequiresCard xsd:boolean 0:1 Indique si la collecte du billet nécessite une carte de crédit utilisée pour l'achat.   RequiresBookingReference xsd:boolean 0:1 Indique si la collecte du billet nécessite une référence d’achat.  « cntd » typesOfDocument TypeOfTravelDocumentRef 0:* TYPEs OF TRAVEL DOCUMENT associé.    Exemples Exemple 1\n\u0026lt;DistributionChannel id=\u0026#34;FR-Tarif-Example:DistributionChannel:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Points de vente RATP\u0026lt;/Name\u0026gt; \u0026lt;Description\u0026gt;Vente de ticket dans tous les points de vente RATP\u0026lt;/Description\u0026gt; \u0026lt;DistributionChannelType\u0026gt;agency\u0026lt;/DistributionChannelType\u0026gt; \u0026lt;OrganisationRef ref=\u0026#34;FR-Tarif-Example:Organisation:RATP:\u0026#34;/\u0026gt; \u0026lt;distributionPoints\u0026gt; \u0026lt;PointRef ref=\u0026#34;etc.\u0026#34;/\u0026gt; \u0026lt;PointRef ref=\u0026#34;etc.\u0026#34;/\u0026gt; \u0026lt;/distributionPoints\u0026gt; \u0026lt;/DistributionChannel\u0026gt; \u0026lt;GroupOfDistributionChannels id=\u0026#34;FR-Tarif-Example:GroupOfDistributionChannels:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Tous les points de vente du Ticket T+\u0026lt;/Name\u0026gt; \u0026lt;members\u0026gt; \u0026lt;DistributionChannelRef ref=\u0026#34;FR-Tarif-Example:DistributionChannel:001:LOC\u0026#34;/\u0026gt; \u0026lt;!--Etc.--\u0026gt; \u0026lt;/members\u0026gt; \u0026lt;/GroupOfDistributionChannels\u0026gt; \u0026lt;DistributionAssignment\u0026gt; \u0026lt;SalesOfferPackageRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackage:001:LOC\u0026#34;/\u0026gt; \u0026lt;!--Ticket T+ plein tarif à l\u0026#39;unité--\u0026gt; \u0026lt;GroupOfDistributionChannelsRef ref=\u0026#34;FR-Tarif-Example:GroupOfDistributionChannels:001:LOC\u0026#34;/\u0026gt; \u0026lt;/DistributionAssignment\u0026gt; Exemple 2\n\u0026lt;DistributionChannel id=\u0026#34;FR-Tarif-Example:DistributionChannel:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Points de vente SNCF\u0026lt;/Name\u0026gt; \u0026lt;Description\u0026gt;Vente de ticket dans tous les points de vente SNCF\u0026lt;/Description\u0026gt; \u0026lt;DistributionChannelType\u0026gt;agency\u0026lt;/DistributionChannelType\u0026gt; \u0026lt;OrganisationRef ref=\u0026#34;FR-Tarif-Example:Organisation:SNCF:\u0026#34;/\u0026gt; \u0026lt;distributionPoints\u0026gt; \u0026lt;PointRef ref=\u0026#34;etc.\u0026#34;/\u0026gt; \u0026lt;PointRef ref=\u0026#34;etc.\u0026#34;/\u0026gt; \u0026lt;/distributionPoints\u0026gt; \u0026lt;/DistributionChannel\u0026gt; \u0026lt;DistributionChannel id=\u0026#34;FR-Tarif-Example:DistributionChannel:002:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Oui SNCF\u0026lt;/Name\u0026gt; \u0026lt;Description\u0026gt;Vente de ticket sur le site officiel SNCF\u0026lt;/Description\u0026gt; \u0026lt;DistributionChannelType\u0026gt;online\u0026lt;/DistributionChannelType\u0026gt; \u0026lt;ContactDetails\u0026gt; \u0026lt;Url\u0026gt;https://www.oui.sncf/\u0026lt;/Url\u0026gt; \u0026lt;/ContactDetails\u0026gt; \u0026lt;OrganisationRef ref=\u0026#34;FR-Tarif-Example:Organisation:Oui-SNCF:\u0026#34;/\u0026gt; \u0026lt;/DistributionChannel\u0026gt; \u0026lt;DistributionChannel id=\u0026#34;FR-Tarif-Example:DistributionChannel:003:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Trainline\u0026lt;/Name\u0026gt; \u0026lt;Description\u0026gt;Vente de billets de 270 compagnies de train et de bus\u0026lt;/Description\u0026gt; \u0026lt;DistributionChannelType\u0026gt;online\u0026lt;/DistributionChannelType\u0026gt; \u0026lt;ContactDetails\u0026gt; \u0026lt;Url\u0026gt;https://www.trainline.fr/\u0026lt;/Url\u0026gt; \u0026lt;/ContactDetails\u0026gt; \u0026lt;OrganisationRef ref=\u0026#34;FR-Tarif-Example:Organisation:TrainLine:\u0026#34;/\u0026gt; \u0026lt;/DistributionChannel\u0026gt; \u0026lt;GroupOfDistributionChannels id=\u0026#34;FR-Tarif-Example:GroupOfDistributionChannels:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Tous les points de vente SNCF en ligne\u0026lt;/Name\u0026gt; \u0026lt;members\u0026gt; \u0026lt;DistributionChannelRef ref=\u0026#34;FR-Tarif-Example:DistributionChannel:002:LOC\u0026#34;/\u0026gt; \u0026lt;DistributionChannelRef ref=\u0026#34;FR-Tarif-Example:DistributionChannel:003:LOC\u0026#34;/\u0026gt; \u0026lt;!--Etc.--\u0026gt; \u0026lt;/members\u0026gt; \u0026lt;/GroupOfDistributionChannels\u0026gt; \u0026lt;DistributionAssignment\u0026gt; \u0026lt;SalesOfferPackageRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackage:001:LOC\u0026#34;/\u0026gt; \u0026lt;GroupOfDistributionChannelsRef ref=\u0026#34;FR-Tarif-Example:GroupOfDistributionChannels:001:LOC\u0026#34;/\u0026gt; \u0026lt;/DistributionAssignment\u0026gt; Les Droits d’accès et Conditions de validité (Validity Parameters) En complément de la structure tarifaire tels que les intervalles de temps et la distance, d\u0026rsquo;autres paramètres peuvent être utilisés par un système tarifaire afin de limiter la validité de droits d\u0026rsquo;accès particuliers.\nCe modèle permet d\u0026rsquo;associer des DROITS D\u0026rsquo;ACCÈS spécifiques à des éléments de la structure tarifaire à l\u0026rsquo;aide de divers paramètres de validité. L\u0026rsquo;élément central est l\u0026rsquo;AFFECTATION DES PARAMÈTRES DE DROITS D\u0026rsquo;ACCÈS (ACCESS RIGHT PARAMETER ASSIGNMENT) qui attribue un ensemble droits et limitation. Il est possible de combiner ces droits en utilisant un opérateur logique (ET, OU ou OU-Exclusif) pour créer des combinaisons complexes de conditions qui peuvent ensuite être associées à de nombreux éléments du modèle tarifaire (ÉLÉMENT DE STRUCTURE TARIFAIRE, ÉLÉMENT DE MATRICE DE DISTANCE, GROUPE D\u0026rsquo;ÉLÉMENTS DE MATRICE DE DISTANCE, PRODUIT TARIFAIRE, PACKAGE D\u0026rsquo;OFFRE DE VENTE, ÉLÉMENT VALIDABLE, ou ÉLÉMENT CONTRÔLABLE)\nUne AFFECTATION DE PARAMÈTRES DE VALIDITÉ permet de spécifier un paramètre limitant un droit d\u0026rsquo;accès théorique, par exemple, une période temporelle après laquelle le titre ne sera plus utilisable.\nUne AFFECTATION DE PARAMÈTRE DE DROIT D\u0026rsquo;ACCÈS compare généralement une valeur de paramètre à une caractéristique de l\u0026rsquo;objet associé. L’attribut « Type d’affectation » permet une telle comparaison. Il existe différents types de comparaisons possibles, spécifiées par le type d’attribution d’attribut, dont les valeurs sont un opérateur de comparaison (« GT », « EQ », « LT », etc.). Ils expriment que la caractéristique comparée, par exemple :\n  « EQ » est strictement égal au paramètre, par exemple : Titre limité à la LIGNE « 27 ».\n  « NE » est différent d’une certaine valeur, par exemple : pour représenter la règle « le droit d’accès est valable sur toutes les LIGNES du réseau de bus à l’exception de la LIGNE 278 et de la LIGNE 66 » ou « le droit d’accès à la zone 4 n’est pas valable entre 2 h 00 et 4 h 00 »\n  « GE » est supérieur ou égal au paramètre, par exemple : le voyage doit se terminer après « 23 heures » ;\n  « LE » est égal ou inférieur au paramètre, par exemple : le voyage doit se terminer avant « 23h00 ».\n  Note : à chaque fois que cela est possible, on préfèrera faire porter les ValidityParameters par le FareProduct… le passage par le SalesOffPackage, ou le ValidableElement (voir le FareStructureElement) ne se fera que si les droits sont véritablement complètement spécifiques à ces concepts.\nA titre d’exemple l’association des ValidityParameters au SalesOffPackage sera justifiée si le fait de porter son titre sur une « carte grand voyageur » donnait accès à une « salon grand voyageur » ce qui ne serait pas le cas pour le même titre sur billet papier ou billet électronique.\nDe plus, seuls les ValidityParameters génériques sur un FareProduct seront affectés « en dur », et toutes les variantes avec impact sur le prix (réduction famille nombreuse, tarifs enfants, etc. pour ce même FareProduct) seront affectées via une FareTable.\nLa figure ci-dessous propose une vue d’ensemble des affectations de droits : on y voit clairement que des droits peuvent apparaitre à tous les niveaux : la note ci-dessus est donc importante pour harmoniser les façons de décrire les tarifs.\nL’AFFECTATION DES PARAMÈTRES DES DROITS D\u0026rsquo;ACCÈS (ACCESS RIGHT PARAMETER ASSIGNMENT) est l’élément central de l’affectation des droits. Toutefois, dans le contexte du profil, il est considéré comme abstrait et on ne l’instanciera pas en tant qu’élément XML, mais uniquement via sa spécialisation en AFFECTATION DES PARAMÈTRES GÉNÉRIQUES (GENERIC PARAMETER ASSIGNMENT).\nL’AFFECTATION DE PARAMÈTRES GÉNÉRIQUES (GENERIC PARAMETER ASSIGNMENT) spécifie donc les droits d\u0026rsquo;accès génériques pour une classe de produits (par exemple, une limite de temps - 7 à 10 heures - pour les voyages effectués avec un passe étudiant).\nLe CIBLAGE DES PARAMÈTRES DE VALIDITÉ (SCOPING VALIDITY PARAMETER) permet de définit la portée de la validité des droits d\u0026rsquo;accès, par exemple sur une partie du réseau, sur certains services, etc. Les PARAMÈTRE D’UTILISATION spécifient les conditions d’utilisation (échange, remboursement, réservation, possibilités d’emporter des bagages, profil utilisateur comme les classes d’âge, etc.). Les PARAMÈTRES DE VALIDITÉ TEMPORELS précise naturellement les aspects temporels (à ne pas confondre avec les ÉLÉMENTS DE STRUCTURE TARIFAIRE décrivant la temporalité : par exemple un ticket de bus permettant de voyager pendant 90 minute relève de la structure tarifaire, par contre si ce même billet doit être utilisé dans l’année suivant la date d’achat, cela relève des PARAMÈTRES DE VALIDITÉ TEMPORELS).\nDroits d’accès et Conditions de validité – Modèle conceptuel\nAccessRightParameterAssignment – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; Assignment ::\u0026gt; ACCESS RIGHT PARAMETER ASSIGNMENT hérite de ASSIGNMENT.   « PK » id AccessRightParameterAssignmentIdType 1:1 Identifiant du ACCESS RIGHT PARAMETER ASSIGNMENT.   XGRP AccessRightParamterAssignmentProperiesGroup xmlGroup 1:1 Propriétés générales du ACCESS RIGHT PARAMETER ASSIGNMENT.   XGRP ParameterAssignmentScopeGroup xmlGroup 1:1 FARE STRUCTURE ELEMENTS concerné par cet ACCESS RIGHT PARAMETER ASSIGNMEN.   XGRP UsageValidityParameterGroup xmlGroup 1:1 USAGE PARAMETERs limitant cet ACCESS RIGHT PARAMETER ASSIGNMENT.   XGRP AccessRightParameterValidityParameterGroup xmlGroup 1:1 Paramètres de validité liés à l’ACCESS RIGHT PARAMETER ASSIGNMENT.    ParameterAssignmentScopeGroup – Group   Classification Name Type Cardinality Description    « FK » ValidableElementRef ValidableElementRef 0:1 VALIDABLE ELEMENT cible de l’affectation.  « FK » ControllableElementRef ControllableElementRef 0:1 CONTROLLABLE ELEMENT cible de l’affectation.  « FK » FareProductRef FareProductRef+ 0:1 FARE PRODUCT cible de l’affectation.\nNote : dans le cadre du profil France, c’est sur le FARE PRODUCT que l’on fera porter l’affectation des droits à chaque fois que cela est possible.\n  « FK » FareStructureElementRef FareStructureElementRef 0:1 FARE STRUCTURE ELEMENT cible de l’affectation.  « FK » FareStructureElementInSequenceRef FareStructure-Element-InSequenceRef 0:1 FARE STRUCTURE ELEMENT IN SEQUENCE cible de l’affectation.  « FK » DistanceMatrixElementRef DistanceMatrixRef 0:1 DISTANCE MATRIX ELEMENT cible de l’affectation.  « FK » DistanceMatrixInverseRef DistanceMatrixRef 0:1 DISTANCE MATRIX ELEMENT cible de l’affectation. La référence est pour le sens inverse de celui de l'élément.  « FK » SalesOfferPackageRef SalesOfferPackageRef 0:1 SALES OFFER PACKAGE cible de l’affectation.  « FK » GroupOfDistanceMatrixElementsRef GroupOfDistanceMatrixElementsRef 0:1 GROUP OF DISTANCE MATRIX ELEMENTs cible de l’affectation.  « FK » GroupOfSalesOfferPackages-Ref GroupOfSalesOffer-PackagesRef 0:1 GROUP OF SALES OFFER PACKAGEs cible de l’affectation.    Les règles de limitation des DROITS D\u0026rsquo;ACCÈS peuvent être complexes et impliquer plusieurs combinaisons de paramètres et de conditions. Ces règles peuvent être exprimées sous forme de propositions logiques avec des opérateurs logiques (et, ou, ou-exclusif). Cela signifie que différents types de combinaisons doivent être pris en compte et que l’AFFECTATION DE DROITS D\u0026rsquo;ACCÈS est une affectation multiple. Pour cela, les attributs xxxGroupingType ci-dessous sont définis avec les valeurs d\u0026rsquo;un opérateur logique (AND, OR, NOT, XOR). Cela permettra d’exprimer des choses comme un droit valable de 6h00 à 8h30 ET de 19h30 à 21h00, par opposition à un droit valable de 6h00 à 8h30 OU (EXCLUSIF) de 19h30 à 21h00.\nUsageValidityParameter – Group   Classification Name Type Cardinality Description    « enum » LimitationGroupingType BooleanOperatorEnum 0:1 Opérateur logique pour combiner les USAGE PARAMETERs. La valeur par défaut est « ET ». « OR » et « XOR » ne doivent être utilisés que si les paramètres sont tous du même type. Voir les valeurs autorisées ci-dessous.\n AND\nOR\nNOT\nXOR\n  « enum » LimitationsSetSelection-Type SetOperatorEnum 0:1 Lorsqu'un ou plusieurs paramètres constituent un groupe contenant plusieurs éléments, (GROUP OF xxx), opérateur d'ensemble pour faire la distinction entre l'ensemble complet et les différentes possibilités de sélection.\n oneOfAnyOneSet (un seul d’entre eux)\noneOfEachSet (un de chaque)\nsomeOfAnySet (plusieurs d’une categorie)\nallOfOneSet (tous ceux d’une categorie)\nallOfAllSets (tous)\n  « FK » limitations UsageParameterRef+ 0:* Réferences des USAGE PARAMETERs définissant des limitations.    AccessRightParameterValidityParameterGroup – Group   Classification Name Type Cardinality Description    « enum » ValidityParameterAssignmentType ComparisonOperatorEnum 0:1 Opérateur de comparaison pour faire correspondre les valeurs des paramètres de validité.\n EQ\nNE\nGE\nGT\nLE\nLT\n  « enum » ValidityParameterGroupingType BooleanOperatorEnum 0:1 Opérateur logique pour combiner les paramètres de validité du réseau, par ex. « ET », « OU », « XOR ».\n AND\nOR\nNOT\nXOR\n  « enum » ValiditySetSelection-Type SetOperatorEnum 0:1 Lorsqu'un ou plusieurs paramètres sont un groupe contenant plusieurs éléments, (GROUP OF xxx), opérateur d'ensemble pour faire la distinction entre l'ensemble complet et les différentes possibilité de sélections.\n oneOfAnyOneSet (un seul d’entre eux)\noneOfEachSet (un de chaque)\nsomeOfAnySet (plusieurs d’une categorie)\nallOfOneSet (tous ceux d’une categorie)\nallOfAllSets (tous)\n  « cntd » temporalValidityParameters TemporalValidityParametersGroup 0:* Validité temporelle associée.  « cntd » validityParameters LimitingValidityParametersGroup 0:* Paramètres de validités associés.    TemporalValidityParametersGroup – Group    Classification Name Type Cardinality Description     « FK » DayTypeRef ValidityConditionRef 0:1 DAY TYPE auquel l’ACCESS RIGHT PARAMETER est affecté.   « FK » GroupOfTimebandsRef GroupOfTimebandsRef 0:1 GROUP OF TIME BANDs auquel l’ACCESS RIGHT PARAMETER est affecté.   « FK » OperatingDayRef OperatingDayRef 0:1 OPERATING DAY auquel l’ACCESS RIGHT PARAMETER est affecté.   « FK » OperatingPeriodRef OperatingPeriod-Ref 0:1 OPERATING PERIOD auquel l’ACCESS RIGHT PARAMETER est affecté.   « FK » ValidityConditionRef ValidityConditionRef 0:1 VALIDITY CONDITION auquel l’ACCESS RIGHT PARAMETER est affecté.    AccessRightParameterAssignmentPropertiesGroup – Group    Classification Name Type Cardinality Description      IsAllowed xsd:boolean 0:1 Indique si les affectations spécifiées sont autorisées (true) ou non (false).   « FK » TypeOfAssignmentRef TypeOAccessRightAssignmentRef 0:1 Classification du ACCESS RIGHT PARAMETER ASSIGNMENT.    ValidityParameterAssignment – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; AccessRightParameterAssignment ::\u0026gt; VALIDITY PARAMETER ASSIGNMENT hérite de ACCESS RIGHT PARAMETER ASSIGNMENT.   « PK » id ValidityParameterAssignmentIdType 1:1 Identifiant du VALIDITY PARAMETER ASSIGNMENT.   « FK » QualityStructureFactorRef QualityStructureFactorRef 0:1 Référence à un QUALITY STRUCTURE FACTOR auquel l’ACCESS RIGHT PARAMETER ASSIGNMENT s’applique.    GenericParameterAssignment – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; ValidityParameterAssignment ::\u0026gt; GENERIC PARAMETER ASSIGNMENT hérite de VALIDITY PARAMETER ASSIGNMENTs   « PK » id GenericParameterAssignmentIdType 1:1 Identifiant du GENERIC PARAMETER ASSIGNMENT.    GenericParameterAssignmentIncludesGroup xmlGroup 1:1 Éléments pour le GENERIC PARAMETER ASSIGNMENT. Ne peut être combiné qu\u0026rsquo;avec des paramètres du même type.    AccessRightParameterAssignmentIncludesGroup – Group   Classification Name Type Cardinality Description    « enum » IncludesGroupingType BooleanOperatorEnum 0:1 Opérateur logique pour combiner les éléments inclus. La valeur par défaut est « OU ».\n AND\nOR\nNOT\nXOR\n  « cntd » includes AccessRightParameterAssignment+ 0:* ACCESS RIGHT PARAMETER ASSIGNMENTs constituant un ACCESS RIGHT PARAMETER ASSIGNMENT composite.    Ciblage des droits d’accès Le ciblage permet de restreindre les droits d\u0026rsquo;accès des éléments de la structure tarifaire à des éléments spécifiques du réseau.\nParamètres liés à l\u0026rsquo;organisation :\n  Quels OPÉRATEURS ou GROUPES D\u0026rsquo;OPÉRATEURS peuvent être utilisés.\n  Quels MODE et sous-modes de VÉHICULE peuvent être utilisés.\n  Paramètres liés au réseau :\n  Quels LIGNES, GROUPES DE LIGNES ou RÉSEAUX et MODE DE VÉHICULE peuvent être utilisés.\n  Quelles ZONE TARIFAIRE, SECTION TARIFAIRE et quels POINTS D\u0026rsquo;ARRÊT PLANIFIÉS peuvent être utilisés. De même, lorsqu\u0026rsquo;un droit est limité à une partie d\u0026rsquo;un emplacement physique, cela peut être spécifié à l\u0026rsquo;aide d\u0026rsquo;un ÉLÉMENT DU SITE.\n  Quels POINTS D\u0026rsquo;INTÉRÊT sont accessibles.\n  Paramètres liés au service :\n  Quelles CONTRAINTES DE SERIES sur les itinéraires doivent être suivies.\n  Le NUMÉRO DE TRAIN, la COURSE, la MISSION COMMERCIALE, le TYPE DE PRODUIT (par exemple ICE, Thalys, etc.) qui peuvent être utilisés.\n  Quelle CLASSE peuvent être utilisées.\n  Paramètres liés au SITE :\n  Le LIEU D\u0026rsquo;ARRÊT, le PARKING ou LE POINT D\u0026rsquo;INTÉRÊT qui est concerné.\n  L\u0026rsquo;ADRESSE à laquelle l\u0026rsquo;affectation s\u0026rsquo;applique.\n  LIEU TOPOGRAPHIQUE auquel l\u0026rsquo;affectation s\u0026rsquo;applique.\n  Paramètres liés au SIÈGE :\n  La COURSE et le NUMÉRO DE TRAIN auxquels l\u0026rsquo;affectation s\u0026rsquo;applique.\n  Les service (FACILITY SET) et le type de place (Siège, couchette, etc.) auxquels s\u0026rsquo;applique l\u0026rsquo;affectation.\n  Le SIÈGE lui-même auquel l\u0026rsquo;affectation s\u0026rsquo;applique.\n  Ciblage des droits d’accès – Modèle conceptuel\nScopingValidityParameters – Element    Classification Name Type Cardinality Description     XGRP OrganisationValidityParametersGroup xmlGroup 1:1 Paramètre de validité concernant l’ORGANISATION cible de l’affecation.   XGRP NetworkValidityParametersGroup xmlGroup 1:1 Paramètre de validité concernant le NETWORK cible de l’affecation.   XGRP RouteValidityParametersGroup xmlGroup 1:1 Paramètre de validité concernant la ROUTE cible de l’affecation.   XGRP ServiceValidityParametersGroup xmlGroup 1:1 Paramètre de validité concernant le SERVICE cible de l’affecation.   XGRP ProductValidityParametersGroup xmlGroup 1:1 Paramètre de validité concernant le PRODUCT cible de l’affecation.    La figure ci-dessous fournit une vue d’ensemble de ce ciblage des droits d’accès (le tableau des attributs lui-même n’est pas fourni car il s’agit simplement d’une longue liste de références à des objets existant – LineRef, SchduledStopPointRef, SiteRef, etc.- et ne présente pas d’intérêt particulier pour ce document).\nCiblage des droits d’accès – vue d’ensemble\nExemples Exemple 1\n\u0026lt;GenericParameterAssignment id=\u0026#34;LEMAN-EXPRESS:GenericParameterAssignment:001:LOC\u0026#34; version=\u0026#34;any\u0026#34; order=\u0026#34;1\u0026#34;\u0026gt; \u0026lt;limitations\u0026gt; \u0026lt;UsageValidityPeriod id=\u0026#34;LEMAN-EXPRESS:UsageValidityPeriod:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;!--Peut être une référence pour mutualiser la définition--\u0026gt; \u0026lt;UsageTrigger\u0026gt;purchase\u0026lt;/UsageTrigger\u0026gt; \u0026lt;!--On a aussi l\u0026#39;option startOutboundRide, etc.--\u0026gt; \u0026lt;StandardDuration\u0026gt;PT180M\u0026lt;/StandardDuration\u0026gt; \u0026lt;/UsageValidityPeriod\u0026gt; \u0026lt;/limitations\u0026gt; \u0026lt;/GenericParameterAssignment\u0026gt; Exemple 2\n\u0026lt;GenericParameterAssignment\u0026gt; \u0026lt;LimitationGroupingType\u0026gt;AND\u0026lt;/LimitationGroupingType\u0026gt; \u0026lt;limitations\u0026gt; \u0026lt;RoundTripRef ref=\u0026#34;FR-Tarif-Example:RoundTrip:001:LOC\u0026#34;/\u0026gt; \u0026lt;ExchangingRef ref=\u0026#34;FR-Tarif-Example:Exchanging:001:LOC\u0026#34;/\u0026gt; \u0026lt;RefundingRef ref=\u0026#34;FR-Tarif-Example:Refunding:001:LOC\u0026#34;/\u0026gt; \u0026lt;/limitations\u0026gt; \u0026lt;validityParameters\u0026gt; \u0026lt;VehicleModes\u0026gt;tram bus\u0026lt;/VehicleModes\u0026gt; \u0026lt;/validityParameters\u0026gt; \u0026lt;IncludesGroupingType\u0026gt;AND\u0026lt;/IncludesGroupingType\u0026gt; \u0026lt;includes\u0026gt; \u0026lt;GenericParameterAssignment\u0026gt; \u0026lt;Description\u0026gt;Voir http://www.navigo.fr/wp-content/uploads/2016/06/lignes_tarifica- tion_speciale_07-2014.pdf pour les lignes \u0026amp;#xE0; tarification sp\u0026amp;#xE9;ciale\u0026lt;/Description\u0026gt; \u0026lt;IsAllowed\u0026gt;false\u0026lt;/IsAllowed\u0026gt; \u0026lt;validityParameters\u0026gt; \u0026lt;LineRef ref=\u0026#34;FR-Tarif-Example:Line:Orlybus:LOC\u0026#34;/\u0026gt; \u0026lt;LineRef ref=\u0026#34;FR-Tarif-Example:Line:Tram11:LOC\u0026#34;/\u0026gt; \u0026lt;LineRef ref=\u0026#34;FR-Tarif-Example:Line:RAPT350:LOC\u0026#34;/\u0026gt; \u0026lt;LineRef ref=\u0026#34;FR-Tarif-Example:Line:RAPT351:LOC\u0026#34;/\u0026gt; \u0026lt;GroupOfLinesRef ref=\u0026#34;FR-Tarif-Example:GroupOfLines:Noctilien:LOC\u0026#34;/\u0026gt; \u0026lt;/validityParameters\u0026gt; \u0026lt;/GenericParameterAssignment\u0026gt; \u0026lt;/includes\u0026gt; \u0026lt;/GenericParameterAssignment\u0026gt; Conditions d’Utilisation (Usage Parameter) La validité d\u0026rsquo;un droit d\u0026rsquo;accès peut être limitée par des paramètres liés à la manière de le consommer (profil de l\u0026rsquo;utilisateur, fréquence d\u0026rsquo;utilisation, transférabilité, etc.). Cela se décrit par des règles complémentaires à celles exprimées par la structure tarifaire et les paramètres de validité. Ces paramètres sont décrits par les CONDITIONS D’UTILISATION.\nLes CONDITIONS D’UTILISATION spécifient divers types de limitations fonctionnelles sur un élément tarifaire, par exemple, quand il peut être acheté (FENÊTRE D\u0026rsquo;ACHAT), qui peut l\u0026rsquo;acheter (PROFIL UTILISATEUR), s\u0026rsquo;il peut être donné à quelqu\u0026rsquo;un d\u0026rsquo;autre (TRANSFÉRABILITÉ), etc. Les paramètres se répartissent en quatre groupes principaux qui sont présentés ci-dessous.\nLes CONDITIONS D’UTILISATION DU VOYAGE spécifient les limites de voyage telles que ALLER-RETOUR, ITINÉRAIRE, FRÉQUENCE D\u0026rsquo;UTILISATION, ÉCHANGE, PÉRIODE DE VALIDITÉ D\u0026rsquo;UTILISATION, SÉJOUR MINIMUM.\n  ALLER-RETOUR exprimant les propriétés relatives à l\u0026rsquo;utilisation d’aller simple ou d’aller-retour d\u0026rsquo;un droit d\u0026rsquo;accès.\n  PÉRIODE DE VALIDITÉ D\u0026rsquo;UTILISATION décrit une limitation dans le temps des droits d\u0026rsquo;accès, en particulier des abonnements. Il peut inclure une « durée standard » de validité (1 jour, 1 mois…), des limites de temps (« date de début » et « date de fin », « heure de début » et « heure de fin »), ou une combinaison des deux ;\n  FRÉQUENCE D\u0026rsquo;UTILISATION décrit la limitation d\u0026rsquo;un droit d\u0026rsquo;accès, en fonction de la fréquence d\u0026rsquo;utilisation pendant une PÉRIODE DE VALIDITÉ. Par exemple, un produit est proposé à un tarif spécial s\u0026rsquo;il est utilisé plus de 50 fois par mois ;\n  CORRESPONDANCE exprimant les limites de correspondances au cours d\u0026rsquo;un voyage ;\n  SÉJOUR MINIMUM, exprimant les détails de tout séjour minimum à destination requis pour utiliser le produit (typiquement une réduction si l’on passe un weekend sur place) ;\n  LIMITE DE SEUIL, paramètre géographique limitant les droits d\u0026rsquo;accès par comptage d\u0026rsquo;arrêts, tronçons ou zones ;\n  ITINERAIRE, expression des limitations lié à l’itinéraire suivi, pour un droit d\u0026rsquo;accès ;\n  SUPENSION, décrivant les conditions applicables pour suspendre temporairement un droit d\u0026rsquo;accès tel qu\u0026rsquo;un abonnement.\n  L’éligibilité spécifie les limites sur les personnes autorisées à utiliser un produit telles que PROFIL D\u0026rsquo;UTILISATEUR, BILLET DE GROUPE, COMPAGNON OU MEMBRE DU GROUPE, PROFIL COMMERCIAL, DROIT DONNÉ et DROIT REQUIS.\n  PROFIL UTILISATEUR, qui décrit le profil social d\u0026rsquo;un client. Il est généralement utilisé pour permettre des réductions en fonction des groupes d\u0026rsquo;âge (par exemple moins de 18 ans), du sexe, de la profession, du statut social (par exemple étudiant, retraité, chômeur), etc. ;\n  PROFIL COMMERCIAL, qui permet de décrire les catégories de clients en fonction de leurs relations commerciales avec l\u0026rsquo;opérateur (grand voyageur, montant des achats par une entreprise, etc.). Il est généralement utilisé pour permettre des remises ;\n  TICKET DE GROUPE décrit le nombre et les caractéristiques des personnes éventuellement habilitées à voyager en plus du titulaire d\u0026rsquo;un droit d\u0026rsquo;accès ;\n  PROFIL D’ACCOMPAGNATEUR, indiquant le nombre et les caractéristiques des personnes habilitées à voyager en groupe ou en tant qu’accompagnateur d\u0026rsquo;un autre PROFIL UTILISATEUR ;\n  QUALIFICATION RÉSIDENTIELLE, catégorisant les utilisateurs en fonction de leur lieu de résidence ;\n  POLITIQUE DE CHANGEMENT D\u0026rsquo;ÉLIGIBILITÉ, spécifiant l\u0026rsquo;action à entreprendre si l\u0026rsquo;éligibilité d\u0026rsquo;un utilisateur pour un profil donné change.\n  Les CONDITIONS D’UTILISATION des droits peuvent préciser les droits préalablement requis pour un produit, ou les droits donnés par un produit.\n  DROIT REQUIS, indiquant si un PRODUIT est requis pour pouvoir utiliser le droit d\u0026rsquo;accès (carte famille nombreuse par exemple) ;\n  DROIT DONNÉ, indiquant si un produit permet d’en utiliser d’autres.\n  Les CONDITIONS D’UTILISATION des bagages spécifient des limitations sur les bagages (quantité, poids maximal, etc.).\n ALLOCATION DE BAGAGES décrit le nombre et les caractéristiques (poids ou volume, vélos, etc.) des bagages que le titulaire d\u0026rsquo;un droit d\u0026rsquo;accès est en droit de transporter.  Les CONDITIONS DE VENTE spécifient les limites des transactions de réservation telles que la FENÊTRE D\u0026rsquo;ACHAT, la TRANSFÉRABILITÉ, les RÉSERVATION, l’ÉCHANGE, le REMBOURSEMENT.\n  FENÊTRE D\u0026rsquo;ACHAT, indiquant la période dans laquelle le produit sera acheté ;\n  TRANSFÉRABILITÉ décrit le droit de céder un droit à d\u0026rsquo;autres personnes que le client d\u0026rsquo;origine ;\n  REVENTE, exprimant les conditions de revente attachées au produit ;\n  ÉCHANGE indiquant si et comment le droit d\u0026rsquo;accès peut être échangé contre un autre droit d\u0026rsquo;accès ;\n  REMBOURSEMENT indiquant si et comment le droit d\u0026rsquo;accès acheté peut être remboursé ;\n  REMPLACEMENT indiquant si et comment le droit d\u0026rsquo;accès peut être remplacé (par exemple si un ticket est perdu ou défectueux) ;\n  RÉSERVATION indiquant si le droit d\u0026rsquo;accès nécessite une réservation.\n  Les CONDITIONS DE FACTURATION spécifient des règles liées à la facturation tels que la POLITIQUE DE FACTURATION et la POLITIQUE DE PÉNALITÉ.\n  Le paramètre la POLITIQUE DE FACTURATION spécifie les limitations sur la façon dont un produit peut être facturé, par exemple pour spécifier un niveau de crédit minimum et maximum.\n  Le paramètre POLITIQUE DE PÉNALITÉ spécifie les règles relatives aux pénalités qui peuvent être encourus en cas d’infraction.\n  Le paramètre POLITIQUE D’ABONNEMENT spécifie les règles relatives aux tarifs achetés dans le cadre d’un abonnement avec des de paiement réguliers.\n  Conditions d’Utilisation – Modèle conceptuel\nUsageParameter – Element (abstrait)    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; PriceableObject ::\u0026gt; USAGE PARAMETER hérite de PRICEABLE OBJECT***.***   « PK » id UsageParameterIdType 1:1 Identifiant du USAGE PARAMETER.    Url xsd:anyUri 0:1 Url associé au parameter.   « FK » TypeOfUsageParameterRef TypeOfUsageParameterRef 0:1 Type de USAGE PARAMETER (TypeofValue).    Les figures ci-dessous présentent les modèles de données pour l’ensemble des conditions d’utilisation. Ces conditions sont à prendre telles quelles et il n’y a pas de véritable intérêt à leur appliquee un travail de profil, les tableaux d’attributs qui leur correspondent ont donc été placés en annexe (en anglais) pour référence (ceci afin de ne pas surcharger inutilement la partie principale de ce document).\nConditions d’Utilisation (Usage Parameter)\nParamètre du voyage (Travel parameters)\nEligibilité (Eligibility)\nOuvertures de droits (Entitlements)\nBagages (Luggage)\nRéservation (Booking)\nAprès-vente (After Sales)\nPaiement (Charging)\nExemples \u0026lt;UserProfile id=\u0026#34;FR-Tarif-Example:UserProfile:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;!--Plein tarif classique--\u0026gt; \u0026lt;Name\u0026gt;Plein tarif\u0026lt;/Name\u0026gt; \u0026lt;Description\u0026gt;Plein tarif adulte sans r\u0026amp;#xE9;duction\u0026lt;/Description\u0026gt; \u0026lt;MinimumAge\u0026gt;10\u0026lt;/MinimumAge\u0026gt; \u0026lt;/UserProfile\u0026gt; \u0026lt;UserProfile id=\u0026#34;FR-Tarif-Example:UserProfile:002:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;!--Gratuit pour les enfants--\u0026gt; \u0026lt;Name\u0026gt;Moins de 4 ans\u0026lt;/Name\u0026gt; \u0026lt;Description\u0026gt;Gratuit pour les enfants de moins de 4 ans\u0026lt;/Description\u0026gt; \u0026lt;MaximumAge\u0026gt;4\u0026lt;/MaximumAge\u0026gt; \u0026lt;DiscountBasis\u0026gt;free\u0026lt;/DiscountBasis\u0026gt; \u0026lt;/UserProfile\u0026gt; \u0026lt;UserProfile id=\u0026#34;FR-Tarif-Example:UserProfile:003:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;!--50% pour les enfants entre 4 et 10 ans --\u0026gt; \u0026lt;Name\u0026gt;Tarif Enfant\u0026lt;/Name\u0026gt; \u0026lt;Description\u0026gt;50%de r\u0026amp;#xE9;duction pour les enfants entre 4 et 10 ans \u0026lt;/Description\u0026gt; \u0026lt;prices\u0026gt; \u0026lt;UsageParameterPrice\u0026gt; \u0026lt;LimitingRule\u0026gt; \u0026lt;DiscountAsPercentage\u0026gt;0.50\u0026lt;/DiscountAsPercentage\u0026gt; \u0026lt;CanBeCumulative\u0026gt;false\u0026lt;/CanBeCumulative\u0026gt; \u0026lt;/LimitingRule\u0026gt; \u0026lt;/UsageParameterPrice\u0026gt; \u0026lt;/prices\u0026gt; \u0026lt;MinimumAge\u0026gt;4\u0026lt;/MinimumAge\u0026gt; \u0026lt;MaximumAge\u0026gt;10\u0026lt;/MaximumAge\u0026gt; \u0026lt;DiscountBasis\u0026gt;discount\u0026lt;/DiscountBasis\u0026gt; \u0026lt;/UserProfile\u0026gt; \u0026lt;UserProfile id=\u0026#34;FR-Tarif-Example:UserProfile:004:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;!-- User Profile pour les titulaire de carter Famille Nombreuse --\u0026gt; \u0026lt;Name\u0026gt;Titulaire de carte famille nombreuse SNCF bleue\u0026lt;/Name\u0026gt; \u0026lt;Description\u0026gt;50%de r\u0026amp;#xE9;duction\u0026lt;/Description\u0026gt; \u0026lt;TypeOfUsageParameterRef ref=\u0026#34;FR-Tarif-Example:EntitlementRequired:004:LOC\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;prices\u0026gt; \u0026lt;UsageParameterPrice\u0026gt; \u0026lt;LimitingRule\u0026gt; \u0026lt;DiscountAsPercentage\u0026gt;0.50\u0026lt;/DiscountAsPercentage\u0026gt; \u0026lt;CanBeCumulative\u0026gt;false\u0026lt;/CanBeCumulative\u0026gt; \u0026lt;/LimitingRule\u0026gt; \u0026lt;/UsageParameterPrice\u0026gt; \u0026lt;/prices\u0026gt; \u0026lt;DiscountBasis\u0026gt;discount\u0026lt;/DiscountBasis\u0026gt; \u0026lt;/UserProfile\u0026gt; \u0026lt;Exchanging id=\u0026#34;FR-Tarif-Example:Exchanging:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Description\u0026gt;Billet \u0026amp;#xE9;changeable gratuitement jusqu\u0026#39;\u0026amp;#xE0; 30 jours avant le d\u0026amp;#xE9;part. S\u0026#39;ajoute l\u0026#39;\u0026amp;#xE9;ventuelle diff\u0026amp;#xE9;rence de prix entre l\u0026#39;ancien et le nouveau billet\u0026lt;/Description\u0026gt; \u0026lt;Allowed\u0026gt;full\u0026lt;/Allowed\u0026gt; \u0026lt;ResellWhen\u0026gt;beforeStartOfValidity\u0026lt;/ResellWhen\u0026gt; \u0026lt;ExchangableUntilDuration\u0026gt;-P30D\u0026lt;/ExchangableUntilDuration\u0026gt; \u0026lt;HasFee\u0026gt;false\u0026lt;/HasFee\u0026gt; \u0026lt;RefundBasis\u0026gt;perPerson\u0026lt;/RefundBasis\u0026gt; \u0026lt;!--A vérifier--\u0026gt; \u0026lt;/Exchanging\u0026gt; \u0026lt;Exchanging id=\u0026#34;FR-Tarif-Example:Exchanging:002:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Description\u0026gt;Billet \u0026amp;#xE9;changeable avec retenue de 5 \u0026amp;#x20AC; \u0026amp;#xE0; compter de 30 jours avant le d\u0026amp;#xE9;part. A la retenue s\u0026#39;ajoute l\u0026#39;\u0026amp;#xE9;ventuelle diff\u0026amp;#xE9;rence de prix entre l\u0026#39;ancien et le nouveau billet\u0026lt;/Description\u0026gt; \u0026lt;prices\u0026gt; \u0026lt;UsageParameterPrice\u0026gt; \u0026lt;Amount\u0026gt;5\u0026lt;/Amount\u0026gt; \u0026lt;Currency\u0026gt;EUR\u0026lt;/Currency\u0026gt; \u0026lt;/UsageParameterPrice\u0026gt; \u0026lt;/prices\u0026gt; \u0026lt;Allowed\u0026gt;full\u0026lt;/Allowed\u0026gt; \u0026lt;ResellWhen\u0026gt;beforeStartOfValidity\u0026lt;/ResellWhen\u0026gt; \u0026lt;ExchangableFromDuration\u0026gt;-P30D\u0026lt;/ExchangableFromDuration\u0026gt; \u0026lt;ExchangableUntilDuration\u0026gt;-P2D\u0026lt;/ExchangableUntilDuration\u0026gt; \u0026lt;HasFee\u0026gt;true\u0026lt;/HasFee\u0026gt; \u0026lt;RefundBasis\u0026gt;perPerson\u0026lt;/RefundBasis\u0026gt; \u0026lt;!--A vérifier--\u0026gt; \u0026lt;/Exchanging\u0026gt; \u0026lt;Refunding id=\u0026#34;FR-Tarif-Example:Refunding:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Description\u0026gt;Billet Remboursable gratuitement jusqu\u0026#39;\u0026amp;#xE0; 30 jours avant le d\u0026amp;#xE9;part.\u0026lt;/Description\u0026gt; \u0026lt;Allowed\u0026gt;full\u0026lt;/Allowed\u0026gt; \u0026lt;ResellWhen\u0026gt;beforeStartOfValidity\u0026lt;/ResellWhen\u0026gt; \u0026lt;ExchangableUntilDuration\u0026gt;-P30D\u0026lt;/ExchangableUntilDuration\u0026gt; \u0026lt;HasFee\u0026gt;false\u0026lt;/HasFee\u0026gt; \u0026lt;RefundBasis\u0026gt;perPerson\u0026lt;/RefundBasis\u0026gt; \u0026lt;!--A vérifier--\u0026gt; \u0026lt;/Refunding\u0026gt; \u0026lt;Refunding id=\u0026#34;FR-Tarif-Example:Refunding:002:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Description\u0026gt;Billet Remboursable avec retenue de 5 \u0026amp;#x20AC; \u0026amp;#xE0; compter de 30 jours avant le d\u0026amp;#xE9;part.\u0026lt;/Description\u0026gt; \u0026lt;prices\u0026gt; \u0026lt;UsageParameterPrice\u0026gt; \u0026lt;Amount\u0026gt;5\u0026lt;/Amount\u0026gt; \u0026lt;Currency\u0026gt;EUR\u0026lt;/Currency\u0026gt; \u0026lt;/UsageParameterPrice\u0026gt; \u0026lt;/prices\u0026gt; \u0026lt;Allowed\u0026gt;full\u0026lt;/Allowed\u0026gt; \u0026lt;ResellWhen\u0026gt;beforeStartOfValidity\u0026lt;/ResellWhen\u0026gt; \u0026lt;ExchangableFromDuration\u0026gt;-P30D\u0026lt;/ExchangableFromDuration\u0026gt; \u0026lt;ExchangableUntilDuration\u0026gt;-P2D\u0026lt;/ExchangableUntilDuration\u0026gt; \u0026lt;HasFee\u0026gt;true\u0026lt;/HasFee\u0026gt; \u0026lt;RefundBasis\u0026gt;perPerson\u0026lt;/RefundBasis\u0026gt; \u0026lt;!--A vérifier--\u0026gt; \u0026lt;/Refunding\u0026gt; Les Grilles Tarifaires (FareTable) Dans tous les tableaux précédents, les attributs fournissant une information de prix n\u0026rsquo;ont pas été retenus dans le cadre du Profil France : cela tient au fait que l’option retenue par le profil est de systématiser la présentation des prix au travers d’une GRILLE TARIFAIRE (FARE TABLE). L’objectif est ici de systématiser la production et l’interprétation des données d’ordre tarifaire, mais aussi d’éviter une trop grande disparité des choix et options de modélisation qui ne manquerait pas de se présenter (surtout dans le domaine tarifaire) s’il elles n’étaient pas un peu contraintes.\nLa présentation des prix sous forme de grille des tarifs reste un grand classique dans le domaine des transports, et ce choix permettra aussi la simplification de la présentation de l’offre aux voyageur (ce qui est cohérent avec l’objectif d’information voyageur du profil).\nIl reste toutefois quelques cas où des prix pourront être fournis en dehors des GRILLEs TARIFAIREs : par exemple si un produit offre une réduction fixe, par exemple de 5€, cela pourra être indiqué explicitement dans la description du produit tarifaire de façon à pouvoir en donner une description complète et pertinente au voyageur.\nNote : dans le cadre du profil, on fait le choix de ne pas prévoir la gestion de réductions cumulatives.\nUne GRILLE TARIFAIRE permet la représentation de groupes de prix pour des combinaisons d\u0026rsquo;éléments tarifaires. Il définit une matrice multidimensionnelle de CELLULES, dont chacune peut indiquer un prix pour une combinaison d\u0026rsquo;un ou plusieurs éléments tarifaires. Par exemple, on peut avoir des références PROFIL UTILISATEUR + ÉLÉMENT DE MATRICE DE DISTANCE + CLASSE D\u0026rsquo;UTILISATION sur chaque cellule afin de définir les tarifs adulte et enfant pour la première et la deuxième classe.\nLes grilles peuvent être imbriqués. Tous les objets héritant de « PRICEABLE OBJECT » (ce qui est le cas de la grande majorité des objets de ce profil) peuvent être utilisés au sein d’un GRILLE TARIFAIRE.\nLa construction en GRILLE TARIFAIRE permet de définir tout un ensemble de composants relativement indépendants et potentiellement réutilisables qui seront assemblés (par référence) au sein de la grille pour fournir un prix correspondant (par exemple : Titre pour zones A et B + billet à l’unité + jeune voyageur (18-25 ans) =\u0026gt; Prix). On conserve donc une construction très modulaire.\nLa GRILLE TARIFAIRE fera des références vers tous les éléments qui la constituent à l’exception des prix eux-mêmes qui, n’étant pas définis par ailleurs, devront être complètement définis au sein de la GRILLE TARIFAIRE.\nGrilles Tarifaires – Modèle conceptuel\nFareTable – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; PriceGroup ::\u0026gt; FARE TABLE hérite de PRICE GROUP***.***   « PK » id FareTableIdType 1:1 Identifiant du FARE TABLE.    StartDate xsd:date 0:1 Date de début de validité du prix.    EndDate xsd:date 0:1 Date de fin de validité du prix.   XGRP FareTableReferencesGroup xmlGroup 0:* Éléments de structure tarifaire pouvant recevoir un prix et donc associés à cette cellule.   XGRP FareTableCommonAssignmentsGroup xmlGroup 0:1 Association d\u0026rsquo;un élément de structure tarifaire pour une cellule.   XGRP FareTableHeadingsGroup xmlGroup 0:1 En-têtes de lignes et de colonnes pour le tableau. Les CELL peuvent y faire référence.    EmbargoUntil xsd:dateTime 0:1 Les prix ne seront communiqués qu\u0026rsquo;à partir de cette date.   « cntd » cells Cell 0:* Un tuple dans une TABLE DES TARIFS qui associe une ou plusieurs entités tarifaires à un prix.   « cntd » noticeAssignments NoticeAssignment 0:* NOTICEs s’appliquant à l’ensemble de la FARE TABLE    FareTableReferencesGroup – Group    Classification Name  Type Cardinality Description     « FK » TypeOfFareTableRef  TypeOfFareTableRef 0:1 Classification de la FARE TABLE.   « cntd » pricesFor  PriceableObjectRef+ 0:* PRICEABLE OBJECT pouvant faire l\u0026rsquo;objet d\u0026rsquo;un prix et donc associé à cette CELL.   « cntd » usedIn  Choice 0:1 Un élément tarifaire associé au FARE TABLE.   « FK » a TariffRef TariffRef 1:* TARIFF auquel le PRICEs of FARE TABLE s’applique.   « FK » b GroupOfDistanceMatrixElementsRef GroupOfDistanceMatrixElementsRef 1:* GROUP OF DISTANCE MATRIX ELEMENTs associé au FARE TABLE.   « FK » c GroupOfSalesOfferPackagesRef GroupOfSalesOfferPackagesRef 1:* GROUP OF SALES OFFER PACKAGEs associé au FARE TABLE.   « FK » OrganisationRef  (OrganisationRef) 0:1 OPERATOR ou AUTHORITY auquel le FARE PRICEs s’applique.    FareTableCommonAssignmentsGroup – Group    Classification Name Type Cardinality Description     « cntd » limitations UsageParameterRef+ 0:* USAGE PARAMETER or PARAMETERs auquel le CELL PRICE s’applique.   XGRP CellSpecificNetworkGroup xmlGroup 0:1 Combinaison d\u0026rsquo;éléments liés au réseau pour lesquels la FARE TABLE ou CELL fournit un prix.   XGRP CellSpecificRoutingGroup xmlGroup 0:1 Combinaison d\u0026rsquo;éléments liés à l’itinéraire pour lesquels la FARE TABLE or CELL fournit un prix.   XGRP CellSpecificServiceGroup xmlGroup 0:1 Combinaison d\u0026rsquo;éléments liés aux services pour lesquels la FARE TABLE ou CELL fournit un prix.   XGRP CellSpecificDistributionGroup xmlGroup 0:1 Combinaison d\u0026rsquo;éléments liés à la distribution pour lesquels la FARE TABLE ou CELL fournit un prix.    FareTableHeadingsGroup – Group    Classification Name Type Cardinality Description     « cntd » columns FareTableColumnHeading 0:* En-têtes de colonnes à utiliser lors de la présentation du tableau.   « cntd » rows FareTableRowHeading 0:* En-têtes de ligne à utiliser lors de la présentation du tableau.   « cntd » includes FareTable 0:* FARE TABLEs imbriqués dans ce tableau. Peut être récursif.    FareTableColumn – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; VersionedChild ::\u0026gt; FARE TABLE COLUMN hérite de VERSIONED CHILD   « PK » id FareTableColumnIdType 1:1 Identifiant du FARE TABLE COLUMN.    Name MultilingualString 0:1 Nom du FARE TABLE COLUMN.    Description MultilingualString 0:1 Description du FARE TABLE COLUMN.   « cntd » noticeAssignments NoticeAssignments 0:* NOTICEs qui s’applique à l’ensemble de la FARE TABLE COLUMN.   « cntd » representing (VersionOfObjectRef) 0:* ENTITIES que la colonne représente.   « cntd » columns FareTableColumnHeading 0:* En-têtes de FARE TABLE COLUMN imbriqués à utiliser lors de la présentation de la table. Récursif.    FareTableRow – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; VersionedChild ::\u0026gt; FARE TABLE ROW hérite de VERSIONED CHILD.   « PK » id FareTableRowIdType 1:1 Identifiant du FARE TABLE ROW.    Name MultilingualString 0:1 Nom du FARE TABLE ROW.    Description MultilingualString 0:1 Description du FARE TABLE ROW.   « cntd » noticeAssignments NoticeAssignments 0:* NOTICEs qui s’applique à l’ensemble de la FARE TABLE ROW.   « cntd » representing (VersionOfObjectRef) 0:* ENTITIES que la colonne représente.   « cntd » rows FareTableRowHeading 0:* En-têtes de FARE TABLE ROW imbriqués à utiliser lors de la présentation de la table. Récursif.    Les Cellules Note : la cellule ayant principalement la capacité de référencer tous les éléments liés à la tarification pour les combiner et leur attribuer un prix, cela en fait un objet très volumineux (de par sa définition, et non son implémentation) mais sa structure est très simple (alignement de références à « potentiellement » combiner).\nCell – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; VersionedChild ::\u0026gt; CELL hérite de VERSIONED CHILD  « PK » id CellIdType 1:1 Identifiant du CELL.   Name MultilingualString 0:1 Nom du CELL.   Description MultilingualString 0:1 Description du CELL.   price Choice 1:1 Prix  « FK » c FarePrice FarePrice+ 1:1 Tout objet héritant de FARE PRICE fournissant le prix pour cette CELL.\nDans le cas du profil France on utilisera de façon très préférentielle (voir exclusivement) un SalesOfferPAckegePrice ici\n  XGRP CellReferencesGroup xmlGroup 0:1 Structure tarifaire qui pouvant avoir un prix et ainsi être associée à cette CELLULE.  XGRP CellHeadingsGroup xmlGroup 0:1 Intitulés de tableaux associés à cette CELL.  « cntd » noticeAssignments NoticeAssignments 0:* NOTICEs qui s’applique à cette CELL.    CellReferencesGroup – Group    Classification Name Type Cardinality Description     « cntd » PriceableObjectRef PriceableObjectRef+ 0:* Éléments de structure tarifaire pouvant être tarifés et donc associés à cette CELL.   « FK » GroupOfDistanceMatrixElementsRef GroupOfDistanceMatrixElementsRef 0:1 Référence à un GROUP OF DISTANCE MATRIX ELEMENTS) associé à la CELL or FARE TABLE.   XGRP CellSpecificRoutingGroup xmlGroup 0:1 Itinéraires pour lesquels CELL fournit un prix.   XGRP CellSpecificNetworkGroup xmlGroup 0:1 Réseaux pour lesquels CELL fournit un prix.   XGRP CellSpecificServiceGroup xmlGroup 0:1 Services pour lesquels CELL fournit un prix.   XGRP CellSpecificDistributionGroup xmlGroup 0:1 Canaux de distribution pour lesquels CELL fournit un prix.    CellSpecificNetworkGroup – Group    Classification Name Type Cardinality Description     « FK » GroupOfLinesRef GroupOfLinesRef 0:1 A GROUP OF LINEs pour leque cette CELL fournit un prix.   « FK » LineRef LineRef 0:1 LIGNE pour laquelle la CELLULE fournit un prix.   « FK » SiteRef SiteRef 0:1 SITE pour laquelle la CELLULE fournit un prix.   « FK » TariffZoneRef TariffZoneRef 0:1 TARIFF ZONE pour laquelle la CELLULE fournit un prix.   « FK » FareSectionRef FareSectionRef 0:1 FARE SECTION pour laquelle la CELLULE fournit un prix.    CellSpecificRoutingGroup – Group   Classification Name Type Cardinality Description    « enum » DirectionType RelativeDirectionEnum 0:1 Pour les tarifs des DISTANCE MATRIX ELEMENTs, DIRECTION dans laquelle le prix s'applique. Voir Part1 pour les valeurs autorisées.\n both (les deux)\nforwards (aller)\nbackwards (retour)\n  « enum » RoutingType RoutingTypeEnum 0:1 Si le tarif est pour un itinéraire direct (c'est-à-dire qu'aucun changement n'est requis pour un tarif point à point) ou pour un itinéraire indirect.\n direct (direct)\nindirect (avec correspondance)\nboth (les deux)\n    CellSpecificServiceGroup – Group    Classification Name Type Cardinality Description     « enum » FareClass FareClassEnum 0:1 FARE CLASS pour laquelle la CELL fournit un prix.   « FK » ClassOfUseRef ClassOfUseRef 0:1 CLASS OF USE (Seat Class) pour laquelle la CELL fournit un prix.   « FK » FacilitySetRef FacilitySetRef 0:1 FACILITY SET pour laquelle la CELL fournit un prix.   « FK » TypeOfProductCategoryRef TypeOfProductCategoryRef 0:1 TYPE OF PRODUCT CATEGORY pour laquel la CELL fournit un prix.   « FK » TypeOfServiceRef TypeOfServiceRef 0:1 TYPE OF SERVICE pour lequel la CELL fournit un prix.   « FK » ServiceJourneyRef ServiceJourneyRef 0:1 SERVICE JOURNEY pour laquelle la CELL fournit un prix.   « FK » TrainNumberRef TrainNumberRef 0:1 TRAIN NUMBER pour lequel la CELL fournit un prix.   « FK » GroupOfServicesRef GroupOfServicesRef 0:1 GROUP OF SERVICEs pour lequel la CELL fournit un prix.    CellReferencesGroup – Group    Classification Name Type Cardinality Description     « FK » TypeOfFareProductRef TypeOfFareProductRef 0:1 TYPE OF FARE PRODUCT pour lequel la CELL fournit un prix.   « FK » DistributionChannelRef DistributionChannelRef 0:1 DISTRIBUTION CHANNEL pour laquelle la CELL fournit un prix.   « FK » GroupOfDistributionChannelsRef GroupOfDistributionChannelsRef 0:1 GROUP OF DISTRIBUTION CHANNELs pour laquelle la CELL fournit un prix.   « enum » PaymentMethods PaymentMethodEnum 0:1 Valeur standard de PaymentMethod pour laquelle la CELL fournit un prix.   « FK » TypeOfPaymentMethodRef TypeOfPaymentMethodRef 0:1 TYPE OF PAYMENT METHOD pour lequel la CELL fournit un prix.    CellHeadingsGroup – Group    Classification Name Type Cardinality Description     « FK » ColumnRef ColumnRef 0:1 Référence à une colonne de la FARE TABLE à laquelle cette CELL est affectée.   « FK » RowRef RowRef 0:1 Référence à une ligne de la FARE TABLE à laquelle cette CELL est affectée.    Exemples Exemple 1\n\u0026lt;!-- Pour chaque cellule: Prix / UserProfile ou Entitlement / SalesOfferPackage (le lien avec les FareProduct est fait par le SalesOfferPackage) --\u0026gt; \u0026lt;FareTable version=\u0026#34;any\u0026#34; id=\u0026#34;lFR-Tarif-Example:TickeT+FareTable:001:LOC\u0026#34;\u0026gt; \u0026lt;Name\u0026gt; Bus Fare Prices - 18+Student \u0026lt;/Name\u0026gt; \u0026lt;cells\u0026gt; \u0026lt;Cell version=\u0026#34;any\u0026#34; id=\u0026#34;FR-Tarif-Example:Cell:001:LOC\u0026#34; order=\u0026#34;1\u0026#34;\u0026gt; \u0026lt;SalesOfferPackagePrice version=\u0026#34;any\u0026#34; id=\u0026#34;lFR-Tarif-Example:SalesOfferPackagePrice:001:LOC\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Ticket 1h30\u0026lt;/Name\u0026gt; \u0026lt;Amount\u0026gt;1.90\u0026lt;/Amount\u0026gt; \u0026lt;/SalesOfferPackagePrice\u0026gt; \u0026lt;SalesOfferPackageRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackage:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;NetworkRef ref=\u0026#34;FR-Tarif-Example:Network:001:\u0026#34;/\u0026gt; \u0026lt;!--Réseau concerné--\u0026gt; \u0026lt;noticeAssignments\u0026gt; \u0026lt;NoticeAssignmentView\u0026gt; \u0026lt;Text\u0026gt;Ticket 1h30 - a l\u0026#39;unit\u0026amp;#xE9; plein tarif - aAller retour interdit, gratuit pour le moins de 4 ans, ticket disponible en agence uniquement\u0026lt;/Text\u0026gt; \u0026lt;CanBeAdvertised\u0026gt;true\u0026lt;/CanBeAdvertised\u0026gt; \u0026lt;/NoticeAssignmentView\u0026gt; \u0026lt;/noticeAssignments\u0026gt; \u0026lt;/Cell\u0026gt; \u0026lt;!-- etc. --\u0026gt; \u0026lt;/cells\u0026gt; \u0026lt;/FareTable\u0026gt; Exemple 2\n\u0026lt;FareTable version=\u0026#34;any\u0026#34; id=\u0026#34;FR-Tarif-Example:TickeT+FareTable:001:LOC\u0026#34;\u0026gt; \u0026lt;Name\u0026gt; Tarif TGV Paris - Lille \u0026lt;/Name\u0026gt; \u0026lt;cells\u0026gt; \u0026lt;Cell version=\u0026#34;any\u0026#34; id=\u0026#34;FR-Tarif-Example:Cell:001:LOC\u0026#34;\u0026gt; \u0026lt;SalesOfferPackagePrice\u0026gt; \u0026lt;Name\u0026gt;Prix dynamique plein taif\u0026lt;/Name\u0026gt; \u0026lt;!--\u0026lt;Amount\u0026gt;xx.00\u0026lt;/Amount\u0026gt; Possibilité de prix de référence même s\u0026#39;il y a un tarif \u0026#34;yieldé\u0026#34;--\u0026gt; \u0026lt;PricingServiceRef ref=\u0026#34;FR-Tarif-Example:PricingService:001:LOC\u0026#34;/\u0026gt; \u0026lt;!-- \u0026lt;LimitingRule\u0026gt; Possibilité de limitation du prix \u0026lt;MinimumPrice\u0026gt;0.1 \u0026lt;/MinimumPrice\u0026gt; \u0026lt;MaximumPrice\u0026gt;10000.00\u0026lt;/MaximumPrice\u0026gt; \u0026lt;/LimitingRule\u0026gt;--\u0026gt; \u0026lt;/SalesOfferPackagePrice\u0026gt; \u0026lt;UserProfileRef version=\u0026#34;any\u0026#34; ref=\u0026#34;FR-Tarif-Example:UserProfile:001:LOC\u0026#34;/\u0026gt; \u0026lt;SalesOfferPackageRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackage:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;/Cell\u0026gt; \u0026lt;Cell version=\u0026#34;any\u0026#34; id=\u0026#34;FR-Tarif-Example:Cell:002:LOC\u0026#34;\u0026gt; \u0026lt;SalesOfferPackagePrice\u0026gt; \u0026lt;Name\u0026gt;Gratuit pour les enfants de moins de 4 ans\u0026lt;/Name\u0026gt; \u0026lt;Amount\u0026gt;0.0\u0026lt;/Amount\u0026gt; \u0026lt;!--GRATUIT POUR LES ENFANT DE MOINS DE 4 ANS \u0026#34;SUR LES GENOUX\u0026#34;--\u0026gt; \u0026lt;/SalesOfferPackagePrice\u0026gt; \u0026lt;UserProfileRef version=\u0026#34;any\u0026#34; ref=\u0026#34;FR-Tarif-Example:UserProfile:002:LOC\u0026#34;/\u0026gt; \u0026lt;SalesOfferPackageRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackage:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;/Cell\u0026gt; \u0026lt;Cell version=\u0026#34;any\u0026#34; id=\u0026#34;FR-Tarif-Example:Cell:002b:LOC\u0026#34;\u0026gt; \u0026lt;SalesOfferPackagePrice\u0026gt; \u0026lt;Name\u0026gt;Tarif pour les enfants de moins de 4 ans sur un si\u0026amp;#xE8;ge\u0026lt;/Name\u0026gt; \u0026lt;Amount\u0026gt;9.0\u0026lt;/Amount\u0026gt; \u0026lt;!--9€ FIXE POUR LES ENFANT DE MOINS DE 4 ANS \u0026#34;SUR UN SIEGE\u0026#34;--\u0026gt; \u0026lt;/SalesOfferPackagePrice\u0026gt; \u0026lt;UserProfileRef version=\u0026#34;any\u0026#34; ref=\u0026#34;FR-Tarif-Example:UserProfile:002b:LOC\u0026#34;/\u0026gt; \u0026lt;SalesOfferPackageRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackage:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;/Cell\u0026gt; \u0026lt;Cell version=\u0026#34;any\u0026#34; id=\u0026#34;FR-Tarif-Example:Cell:003:LOC\u0026#34;\u0026gt; \u0026lt;SalesOfferPackagePrice\u0026gt; \u0026lt;Name\u0026gt;Prix dynamique pour le 4-11 ans\u0026lt;/Name\u0026gt; \u0026lt;PricingServiceRef ref=\u0026#34;FR-Tarif-Example:PricingService:001:LOC\u0026#34;/\u0026gt; \u0026lt;DiscountingRule\u0026gt; \u0026lt;DiscountAsPercentage\u0026gt;0.6\u0026lt;/DiscountAsPercentage\u0026gt; \u0026lt;/DiscountingRule\u0026gt; \u0026lt;/SalesOfferPackagePrice\u0026gt; \u0026lt;UserProfileRef version=\u0026#34;any\u0026#34; ref=\u0026#34;FR-Tarif-Example:UserProfile:003:LOC\u0026#34;/\u0026gt; \u0026lt;!--LES ENFANT DE DE 4 A 11 ANS =\u0026gt; 60% de réduction--\u0026gt; \u0026lt;SalesOfferPackageRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackage:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;/Cell\u0026gt; \u0026lt;!-- etc. --\u0026gt; \u0026lt;/cells\u0026gt; \u0026lt;/FareTable\u0026gt; Les prix Le modèle complète de façon très naturelle le reste de la description de l’offre tarifaire.\nTout élément qui peut avoir un prix (ou auquel on peut faire correspondre un prix ou une variation de prix) est une spécialisation d’un OBJET VALORISABLE (PRICEABLE OBJECT), ce qui est le cas de la majorité des concepts introduits dans ce profil.\nIl existe différents types de PRIX pour chaque OBJET VALORISABLE, par exemple prix d’un ÉLÉMENT DE MATRICE DE DISTANCE, prix d’un PRODUIT TARIFAIRE, etc.\nLes PRIX peuvent être un montant absolu (par exemple 23,00 euros) ou être dérivés en utilisant une RÈGLE DE CALCUL DU PRIX sur un autre prix (par exemple un pourcentage de réduction). Le PRIX peut indiquer le prix et la règle dont il est dérivé ainsi que le montant qui en résulte.\n  Une RÈGLE DE RÉDUCTION spécifie les paramètres relatifs à la remise ; Les remises peuvent être exprimées en pourcentage (par exemple 10%) ou en montant absolu (par exemple 5 euros).\n  Une RÈGLE DE LIMITATION peut être utilisée pour définir une règle définie sur les résultats, par exemple pour fixer un prix minimum et maximum.\n  Il peut être nécessaire de regrouper les prix en GROUPES DE PRIX, par exemple pour définir des catégories auxquelles la même augmentation, en valeur ou en pourcentage, peut être appliquée.\nPrix – Modèle conceptuel\nPriceableObject – Element (abstrait)   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; DataManagedObject ::\u0026gt; PRICEABLE OBJECT hérite de DATA MANAGED OBJECT.  « PK » id PriceableObjectIdType 1:1 Identifiant du PRICEABLE OBJECT.   Name MultilingualString 0:1 Nom du PRICEABLE OBJECT.   Description MultilingualString 0:1 Description du PRICEABLE OBJECT.   Url xsd:AnyURI 0:1 URL d’une page web contenant des information concernant le PRICEABLE OBJECT.  « cntd » infoLinks InfoLink 0:* Hypelien d’information additionel  « cntd » alternativeNames AlternativeName 0:* Nom alternatif  « cntd » noticeAssignments NoticeAssignment 0:* NOTICE ASSIGNMENTs associé à cet élément.\nNote : on n’utilisera cette possibilité de NOTICE que si l’on n’est pas en mesure de la faire figurer dans la GRILLE TAIFAIRE (FARE TABLE)\n    FarePrice – Element (abstrait)    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; VersionedChild ::\u0026gt; FARE PRICE hérite de VERSIONED CHILD   « PK » id FarePriceIdType 1:1 Identifiant du FARE PRICE.    Name MultilingualString 0:1 Nom du PRICE.    Description MultilingualString 0:1 Description du PRICE.    PrivateCode PrivateCode 0:1 Identifiant externe du PRICE.    StartDate xsd:date 0:1 Date de départ pour la validité du PRICE.    EndDate xsd:date 0:1 Date de fin pour la validité du PRICE.    Amount AmountType 0:1 Prix dans l’unité monétaire convenue.    Currency CurrencyType 0:1 Code de devise ISO 4217 (Ceci dans une optimisation permettant d\u0026rsquo;omettre les PRICE UNITs).   « FK » PriceUnitRef PriceUnitRef 0:1 Référence à un PRICE UNIT ; peut-être remplacé par Currency.    Units xsd:decimal 0:1 Nombe d\u0026rsquo;unités désignée.   « FK » PricingServiceRef PricingServiceRef 0:1 Référence à un PRICE SERVICE qui peut fournir le prix (pour la tarification dynamique).   XGRP FarePriceCalculationGroup xmlGroup 0:1 Éléments régissant le calcul des prix.    Ranking xsd:integer 0:1 Classement relatif du prix par rapport aux autres prix.    FarePriceCalculationGroup – Group   Classification Name Type Cardinality Description    « cntd » b PricingRule PricingRule 0:1 PRICING RULE utilisée pour claculer le prix.\nPeut être une\n DiscountingRule\nLimitingRule\nLimitingRuleInContext\nPricingRule\n   CanBeCumulative xsd:boolean 0:1 Si la remise peut être utilisée de manière cumulative en combinaison avec d'autres remises.  « FK » RoundingRef RoundingRef 0:1 Arrondi à utiliser pour le calcul.      PricingService – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; DataManagedObject ::\u0026gt; PRICING SERVICE hérite de DATA MANAGED OBJECT.   « PK » id PricingServiceIdType 1:1 Identifiant du PRICING SERVICE.    Name MultilingualString 0:1 Nom du PRICING SERVICE.    Description MultilingualString 0:1 Description du PRICING SERVICE.    Url xsd:anyURI 0:1 URL à laquelle le service est disponible.   « FK » OrganisationRef (OrganisationRef) 0:1 ORGANISATION qui fournit des services (coordonnées, etc.).    PricingRule – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; DataManagedObject ::\u0026gt; PRICING RULE hérite de DATA MANAGED OBJECT.   « PK » id PricingRuleIdType 1:1 Identifiant du PRICING RULE.    Name MultilingualString 0:1 Nom du PRICING RULE.    Description MultilingualString 0:1 Description du PRICING RULE.    MethodName xsd:NCNAME 0:1 Méthode de calcul associé au PRICING RULE.    Currency CurrencyType 0:1 Devise associé au PRICING RULE.   « FK » PriceUnitRef PriceUnitRef 0:1 PRICE UNIT pour le PRICING RULE.    url xsd:anyURI 0:1 URL associé au PRICING RULE.    DiscountingRule – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; PricingRule ::\u0026gt; DISCOUNTING RULE hérite de PRICING RULE.   « PK » id DiscountingRuleIdType 1:1 Identifiant du DISCOUNTING RULE.    DiscountAsPercentage PercentageType 0:1 Remise du prix en pourcentage.    DiscountAsValue AmountType 0:1 Remise du prix en valeur.    CanBeCumulative xsd:boolean 0:1 Indique si la remise peut être utilisée de manière cumulative en combinaison avec d\u0026rsquo;autres remises.    PriceUnit – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; TypeOfValue ::\u0026gt; PRICE UNIT hérite de TYPE OF VALUE.   « PK » id PriceUnitIdType 1:1 Identifiant du PRICE UNIT.    Precision xsd:integer 0:1 Précision su PRICE UNIT.    PricingParameterSet décrit l\u0026rsquo;Ensemble de paramètres tarifaires globaux commun à tous les éléments de la FRAME.\nPricingParameterSet – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; DataManagedObject ::\u0026gt; PRICING PARAMETER SET hérite de DATA MANAGED OBJECT. Voir NeTEx Partie 1.    id PricingParameterSetIdType 1:1 Identifiant du PRICING PARAMETER SET.    Name MultilingualString 0:1 Nom du PRICING PARAMETER SET.   « cntd » priceUnits PriceUnit 0:* PRICE UNITs disponibles.   « cntd » pricingRules PricingRule 0:1 PRICING RULEs disponibles.    AllowCumulativeDiscounts xsd:boolean 0:1 Indique si les remises cumulatives sont autorisées.   « FK » DayTypeRef DayTypeRef 0:1 FARE DAY par default.   « cntd » monthValidityOffsets MonthValidityOffset 0:12 Décalages de jours pour chaque mois de l\u0026rsquo;année à utiliser pour décider de la date d\u0026rsquo;activation de certains produits.   « cntd » pricingServices PricingService 0:* PRICING SERVICEs disponibles    Le MonthValidityOffset décrit les jours avant (négatif) ou après (positif) le début du mois où un produit, dont l’activation est basée sur une période calendaire, devient valide.\nMonthValidityOffset – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; DataManagedObject ::\u0026gt; MONTH VALIDITY OFFSET hérite de DATA MANAGED OBJECT.    Month month 1:1 Numéro de mois    Name MultilingualString 0:1 Nom du MONTH VALIDITY OFFSET.    DayOffset xsd:integer 1:1 Nombre de jours par rapport au début du mois.    Utilisation des Notices Les notes sont un élément important dans la communication sur la tarification (il suffit de regarder une fiche tarifaire pour voir qu’elle est truffée d’astérisques et de renvois vers tout une série de notes). Il faut de plus noter que, dans le contexte particulier du Profil Tarif France, sa mise en service sera plus délicate que les autres profils de fait qu’il n’existe que très peu d’offre tarifaire déjà décrite de façon structurée et numérique (on a encore, en 2021, majoritairement des pages web et de document PDF pour présenter l’offre tarifaire) : le travail de représentation structuré initial sera donc relativement long et conséquent et il sera utile de procéder par étapes. L’une des solutions pour procéder par étape pourra être de commencer par ne structurer que les éléments clés de produits : on décrit les fondamentaux (FareStructureElement comme une origine-destination ou une validité temporelle d’une heure trente par exemple), le produit tarifaire (PreassignedFareProduct) et l’offre à la vente (SalesOfferPackage) mais avec des droits (ValidityParameter, UsageParameter, etc.) très succincts, et on assemble l’ensemble dans une grille tarifaire (FareTable) dans laquelle on ajoute une note précisant les droits. L’idée ici est typiquement de fournir suffisamment d’éléments pour qu’un système d’information (calculateur d’itinéraire, service en contexte MaaS, etc.) puisse proposer le titre quand il a de grande chance d’être pertinent et que la note associée permette à l’usager de décider si le titre lui convient ou pas.\nLa figure ci-dessous montre un titre TER (Bourgogne-Franche-Compté) que l’on peut décrire en détail avec NeTEx mais qui nécessite de nombreux éléments de profil utilisateur combinés (salarié des entreprises, agent des administrations, autre professionnels…), qui nécessitera aussi un enregistrement du professionnel ou de sa société, etc. Ces éléments de droits d’accès et de profil utilisateur peuvent, en première approche, être insérés dans une note : en réutilisant le titre (PreassignedFareProduct) « standard » on créera une offre à la vente (SalesOfferPackage) dédiée que l’on associera, dans la grille tarifaire (FareTable) à une note (Notice) et à l’information sur la réduction correspondant (via un FarePrice), ici de 30%.\nExemple de tarif particulier pouvant justifier l’usage d’une note pour le simplifier\nAutre élément important dans le cadre de ce profil : les Notices seront exclusivement rattachées aux grilles tarifaires (FareTable), qui permettra en fait de l’associer à une offre à la vente (SalesOfferPackage), ou éventuellement à un produit tarifaire (PreassignedFareProduct). Théoriquement une note peut être attachée à n’importe quel objet mais attacher les note sans règle à de nombreux endroits rendrait l’exploitation de la donnée très délicate.\nIl sera aussi souvent utile de pouvoir proposer des traductions des notes dans différentes langues : on procédera naturellement à ces traduction grâce à l’élément AlternativeText (décrit dans le document NF_Profil NeTEx éléments communs(F) à partir de la version 2).\nExemple minimal L’exemple ci-dessous illustre la description d’un tarif minimal : l’option prise dans cette exemple est d’être le plus simple et compact possible, mais cette simplification a pour conséquence qu’un calculateur d’itinéraire, s’il aura la possibilité de présenter cette offre pour les réseau concernés, ne pourra pas vérifier qu’il est pertinent pour un itinéraire proposé (seul le texte indique que la durée d’utilisation et d’une heure trente au maximum par exemple). Le même exemple est proposé de façon un tout petit peu plus détaillé en B.2-Tarif simple (il ajoute en particulier un élément de structure tarifaire de type TimeInterval qui pourra être utilisé par par le calculateur d’itinéraire).\n\u0026lt;?xml version=\u0026#34;1.0\u0026#34;?\u0026gt; \u0026lt;PublicationDelivery xmlns=\u0026#34;http://www.netex.org.uk/netex\u0026#34; xmlns:xsi=\u0026#34;http://www.w3.org/2001/XMLSchemainstance\u0026#34; xsi:schemaLocation=\u0026#34;http://www.netex.org.uk/netex ./xsd/NeTEx_publication.xsd\u0026#34; version=\u0026#34;1.1\u0026#34;\u0026gt; \u0026lt;!--- =============== ENTETE =========== --\u0026gt; \u0026lt;PublicationTimestamp\u0026gt;2019-06-12T09:30:47.0Z\u0026lt;/PublicationTimestamp\u0026gt; \u0026lt;ParticipantRef\u0026gt;AURIGE001\u0026lt;/ParticipantRef\u0026gt; \u0026lt;!-- ========== DONNEES =========== --\u0026gt; \u0026lt;dataObjects\u0026gt; \u0026lt;!-- =========================================== --\u0026gt; \u0026lt;!-- CompositeFrame.de type NETEX_FRANCE --\u0026gt; \u0026lt;CompositeFrame version=\u0026#34;1\u0026#34; created=\u0026#34;2019-06-12T09:30:47.0Z\u0026#34; id=\u0026#34;FR-Tarif-Example:CompositeFrame:myFrame01:LOC\u0026#34;\u0026gt; \u0026lt;frames\u0026gt; \u0026lt;!-- =========================================== --\u0026gt; \u0026lt;!-- Frame NETEX_TARIF --\u0026gt; \u0026lt;GeneralFrame version=\u0026#34;001\u0026#34; id=\u0026#34;FR-Tarif-Example:TypeOfFrame:NETEX_TARIF-Example1:LOC\u0026#34;\u0026gt; \u0026lt;TypeOfFrameRef ref=\u0026#34;FR:TypeOfFrame:NETEX_TARIF\u0026#34;\u0026gt;version=\u0026#34;1.01:FR-NETEX_TARIF-1.0\u0026#34;\u0026lt;/TypeOfFrameRef\u0026gt; \u0026lt;members modificationSet=\u0026#34;all\u0026#34;\u0026gt; \u0026lt;!-- ======================================================================== --\u0026gt; \u0026lt;!-- LE TITRE --\u0026gt; \u0026lt;PreassignedFareProduct id=\u0026#34;FR-Tarif-Example:PreassignedFareProduct:T+001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Ticket 1h30\u0026lt;/Name\u0026gt; \u0026lt;AuthorityRef ref=\u0026#34;FR-Tarif-Example:Authority:IDFM:\u0026#34;/\u0026gt; \u0026lt;ConditionSummary\u0026gt; \u0026lt;TariffBasis\u0026gt;period\u0026lt;/TariffBasis\u0026gt; \u0026lt;CanBreakJourney\u0026gt;false\u0026lt;/CanBreakJourney\u0026gt; \u0026lt;IsRefundable\u0026gt;false\u0026lt;/IsRefundable\u0026gt; \u0026lt;IsExchangable\u0026gt;false\u0026lt;/IsExchangable\u0026gt; \u0026lt;/ConditionSummary\u0026gt; \u0026lt;ProductType\u0026gt;singleTrip\u0026lt;/ProductType\u0026gt; \u0026lt;/PreassignedFareProduct\u0026gt; \u0026lt;!-- ======================================================================= --\u0026gt; \u0026lt;!-- FARE TABLE avec affectation des prix --\u0026gt; \u0026lt;!-- Version minimaliste sans SalesOfferPackage (le lien direct avec FareProduct) --\u0026gt; \u0026lt;FareTable version=\u0026#34;any\u0026#34; id=\u0026#34;lFR-Tarif-Example:TickeT+FareTable:001:LOC\u0026#34;\u0026gt; \u0026lt;Name\u0026gt; Bus Fare Prices - 18+Student \u0026lt;/Name\u0026gt; \u0026lt;cells\u0026gt; \u0026lt;Cell version=\u0026#34;any\u0026#34; id=\u0026#34;FR-Tarif-Example:Cell:001:LOC\u0026#34; order=\u0026#34;1\u0026#34;\u0026gt; \u0026lt;SalesOfferPackagePrice version=\u0026#34;any\u0026#34; id=\u0026#34;lFR-Tarif-Example:SalesOfferPackagePrice:001:LOC\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Ticket 1h30\u0026lt;/Name\u0026gt; \u0026lt;Amount\u0026gt;1.90\u0026lt;/Amount\u0026gt; \u0026lt;/SalesOfferPackagePrice\u0026gt; \u0026lt;PreassignedFareProductRef ref=\u0026#34;FR-Tarif-Example:PreassignedFareProduct:T+001:LOC\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;NetworkRef ref=\u0026#34;FR-Tarif-Example:Network:001:\u0026#34;/\u0026gt; \u0026lt;!--Réseau concerné--\u0026gt; \u0026lt;noticeAssignments\u0026gt; \u0026lt;NoticeAssignmentView\u0026gt; \u0026lt;Text\u0026gt;Ticket 1h30 - a l\u0026#39;unit\u0026amp;#xE9; plein tarif \u0026amp;#x2013; Aller/retour interdit, gratuit pour le moins de 4 ans, ticket disponible en agence uniquement\u0026lt;/Text\u0026gt; \u0026lt;CanBeAdvertised\u0026gt;true\u0026lt;/CanBeAdvertised\u0026gt; \u0026lt;/NoticeAssignmentView\u0026gt; \u0026lt;/noticeAssignments\u0026gt; \u0026lt;/Cell\u0026gt; \u0026lt;!-- etc. --\u0026gt; \u0026lt;/cells\u0026gt; \u0026lt;/FareTable\u0026gt; \u0026lt;!-- ======================================================================== --\u0026gt; \u0026lt;/members\u0026gt; \u0026lt;/GeneralFrame\u0026gt; \u0026lt;/frames\u0026gt; \u0026lt;/CompositeFrame\u0026gt; \u0026lt;/dataObjects\u0026gt; \u0026lt;/PublicationDelivery\u0026gt; Entêtes NeTEx Note: les entêtes NeTEx sont présentés dans le document éléments communs. Seules les spécificités de la partie \u0026ldquo;Tarifs\u0026rdquo; sont présentées ici.\nPour rappel, la liste des fichiers d\u0026rsquo;un export NeTEx profil France est décrite dans Éléments Communs.\nUne GeneralFrame de type NETEX_TARIF est utilisée pour échanger la description des données tarifaires dans le fichier fare.xml.\nTypeOfFrame : type spécifique NETEX_TARIF Lorsqu\u0026rsquo;une FRAME a pour TypeOfFrame la valeur NETEX_TARIF, seuls les objets de premier niveau suivants sont autorisés :\n StopPlace FareZone (l\u0026rsquo;objet TarifZone doit être spécialisé dans le profil France) FareStructureElement UserProfile DistributionChannel FareProduct qui est un objet abstrait décliné en :  PreassignedFareProduct SaleDiscountRight pour les bons de réduction UsageDiscountRight pour les cartes de réduction AmountOfPriceUnit pour l\u0026rsquo;achat de support, comme la carte Navigo Liberté+   SalesOfferPackageElement SalesOfferPackage TypeOfTravelDocument TypeOfPricingRule (permet de préciser la TVA, mais n\u0026rsquo;est pas requis par le profil France. Voir la FAQ à ce sujet.) DiscountingRule FareTable (les SalesOfferPackagePrice sont inclus dans les Cell de la FareTable) DistanceMatrixElement  Voici un exemple de cadre du fichier fare.xml :\n\u0026lt;?xml version=\u0026#34;1.0\u0026#34; encoding=\u0026#34;utf-8\u0026#34;?\u0026gt; \u0026lt;PublicationDelivery xmlns=\u0026#34;http://www.netex.org.uk/netex\u0026#34; version=\u0026#34;2.0:FR-NETEX-2.4\u0026#34;\u0026gt; \u0026lt;PublicationTimestamp\u0026gt;2023-01-01T00:00:00.0Z\u0026lt;/PublicationTimestamp\u0026gt; \u0026lt;ParticipantRef\u0026gt;Exemple\u0026lt;/ParticipantRef\u0026gt; \u0026lt;dataObjects\u0026gt; \u0026lt;GeneralFrame id=\u0026#34;exemple:GeneralFrame:NETEX_Tarif-sample\u0026#34; version=\u0026#34;2.0:FR-NETEX-2.4\u0026#34;\u0026gt; \u0026lt;TypeOfFrameRef ref=\u0026#34;FR:TypeOfFrame:NETEX_TARIF\u0026#34; /\u0026gt; \u0026lt;members\u0026gt; \u0026lt;!-- FareZone FareStructureElement UserProfile DistributionChannel FareProduct qui est un objet abstrait décliné en : - PreassignedFareProduct - SaleDiscountRight pour les bons de réduction - UsageDiscountRight pour les cartes de réduction - AmountOfPriceUnit pour l\u0026#39;achat de support, comme la carte Navigo Liberté+ SalesOfferPackageElement SalesOfferPackage TypeOfTravelDocument TypeOfPricingRule DiscountingRule FareTable DistanceMatrixElement ParkingTariff --\u0026gt; \u0026lt;/members\u0026gt; \u0026lt;/GeneralFrame\u0026gt; \u0026lt;/dataObjects\u0026gt; \u0026lt;/PublicationDelivery\u0026gt; Usage Parameters Les CONDITIONS D’UTILISATION (USAGE PARAMETER) sont nombreuses, mais il est difficile d’en faire une sélection dans le cadre du profil car la diversité des offres tarifaire est telle qu’il n’est pas possible d’affirmer que telle CONDITION d’UTILISATION n’est (et ne sera) utile nulle part en France. Les tableaux ci-dessous fournissent, pour mémoire, donc l’intégralité des CONDITIONS D’UTILISATION proposées par NeTEx (non traduit en Français, donc en Anglais).\nUsage Parameter: Travel – Attributes RoundTrip – Element Properties relating to single or return trip use of an access right.\nRoundTrip – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; UsageParameter ::\u0026gt; ROUND TRIP hérite de USAGE PARAMETER.  « PK » id RoundTripIdType 1:1 Identifiant du ROUND TRIP.\n single Single trip.\n return Outbound and return trip.\n returnOut Outbound leg of return journey\n returnBack Return leg of return journey.\n returnOnly Return trip only\n multiple Multiple trip.\n    TripType xsd:boolean 0:1 Whether return trip is allowed.   DoubleSingleFare xsd:boolean 0:1 Whether fare for return trip is single fare doubled.   ShortTrip xsd:boolean 0:1 Whether trip is classified as a short trip for fares.   IsRequired xsd:boolean 0:1 Whether return trip is required.    Routing – Element Limitations on routing of an access right.\nRouting – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; UsageParameter ::\u0026gt; ROUTING hérite de USAGE PARAMETER.   « PK » id RoutingIdType 1:1 Identifiant du ROUTING.    ReturnRouteIdentical xsd:boolean 0:1 Whether return route shall be same as outbound route.    ForwardsOnly xsd:boolean 0:1 Whether passenger may only take routes that proceed in a single direction. (They may not use product to achieve a return trip for the cost of a single trip).    IsRestricted xsd:boolean 0:1 Whether only allowed on certain routes or series.    CrossBorder xsd:boolean 0:1 Whether the routing is across a border.    FrequencyOfUse – Element The limits of usage frequency for a FARE PRODUCT (or one of its components) or a SALES OFFER PACKAGE during a specific VALIDITY PERIOD. There may be different tariffs depending on how often the right is consumed during the period.\nFrequencyOfUse – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; UsageParameter ::\u0026gt; FREQUENCY OF USE hérite de USAGE PARAMETER.  « PK » id FrequencyOfUseIdType 1:1 Identifiant du FREQUENCY OF USE.  « enum » FrequencyOfUseType FrequencyOfUseEnum 0:1 Type of Frequency of Use. See allowed values below.\n none No use changes allowed.\n single Single use allowed.\n limited Limited use allowed.\n unlimited Unlimited use allowed.\n twiceADay Can be used twice a day.\n    MinimalFrequency xsd:integer 0:1 Minimum number of times can be used.   MaximalFrequency xsd:integer 0:1 Maximum number of times can be used.   FrequencyInterval xsd:duration 0:1 Interval within which frequency is measured. If absent forever.  « FK » TimeIntervalRef TimeIntervalRef 0:1 Interval within which frequency is measured. - as Référence au arbitrary time interval.  « enum » DiscountBasis DiscountBasisEnum 0:1 Nature of discount for number of journeys. See allowed values below.\n none No companion allowed.\n free Companion allowed for free\n discount Companion allowed at discount\n     Interchanging – Element Limitations on making changes within a trip.\nInterchanging – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; UsageParameter ::\u0026gt; INTERCHANGING hérite de USAGE PARAMETER.  « PK » id InterchangingIdType 1:1 Identifiant du INTERCHANGING.   CanInterchange xsd:boolean 0:1 Whether an interchange can be made.  « enum » FromMode VehicleModeEnum 0:1 TRANSPORT MODE from which user is interchanging. See NeTEx Part1 for allowed values.  « enum » ToMode VehicleModeEnum 0:1 TRANSPORT MODE to which user is interchanging. See NeTEx Part1 for allowed values.   MaximumNumberOfChanges xsd:integer 0:1 Maximum number of transfers that can be made on a trip.   MaximumTimeToMakeATransfer xsd:duration 0:1 Maximum time allowed to make a transfer.   CanBreakJourney xsd:boolean 0:1 Whether the journey can be broken at an interchange point.   CrossBorder xsd:boolean 0:1 Whether the interchange is across a border.  « enum » RegisterBreakOfJourney RegisterBreakOfJourneyEnum 0:* Whether the Journey can be interrupted, i.e. leave stop point and return. See allowed values below.\n none No action needed.\n markByStaff Journey break shall be marked by operator staff.\n markByValidator Journey break shall be marked by validator.\n markByMobileApp Journey break shall be marked using mobile application.\n other Journey break shall be marked by other means.\n     MinimumStay – Element Details of any minimum stay at the destination required to use the product.\nMinimumStay – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; UsageParameter ::\u0026gt; MINIMUM STAY hérite de USAGE PARAMETER.  « PK » id MinimumStayIdType 1:1 Identifiant du MINIMUM STAY parameter.   MinimumStayType MinimumStay 0:1 Nature of Minimum stay requirements. See allowed values below.\n none Starts on purchase.\n specifiedNightsAway Shall spend specified nights away.\n countNightsAway Shall spend the specified number of nights away.\n either Shall spend either the specified number of nights away or the specified nights\n both Shall spend the specified number of nights away which shall be from the specified nights.\n   « enum » RequiredNightsAway DayOfWeekEnum 0:7 Specific nights which shall be spent away. See NeTEx Part1.   MinimumNumberOfNightsAway xsd:integer 0:1 Minimum number of nights that shall be spent away.   MaximumNumberOfNightsAway xsd:integer 0:1 Minimum number of nights that can be spent away.    StepLimit – Element Geographical parameter limiting the access rights by counts of stops, sections or zones.\nStepLimit – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; UsageParameter ::\u0026gt; STEP LIMIT hérite de USAGE PARAMETER.  « PK » id StepLimitIdType 1:1 Identifiant du STEP LIMIT parameter.   Restricted xsd:boolean 0:1 Whether restricted to a number of stops.  « enum » StepUnits StepUnitEnum 0:` Units in which steps are counted. See allowed values below.\n stops Step limit applies to number of stops at which user enters or changes.\n stopsIncludingPassThroughStops Step limit applies to number of stops including stops passed though.\n sections Step limit applies to number of sections passed though.\n zones Step ep limit applies to number of zones passed though.\n networks Step limit applies to number of networks passed though.\n operators Step limit applies to number of operators used.\n countries Step limit applies to number of countries passed though.\n    MinimumNumberOfSteps xsd:integer 0:1 Minimum number of steps allowed.   MaximumNumberOfSteps xsd:integer 0:1 Maximum number of steps allowed.   MaximumNumberOfTrips xsd:integer 0:1 Maximum number of trips allowed.    UsageValidityPeriod – Element A time limitation for validity of a FARE PRODUCT or a SALES OFFER PACKAGE. It may be composed of a standard duration (e.g. 3 days, 1 month) and/or fixed start/end dates and times.\nUsageValidityPeriod – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; UsageParameter ::\u0026gt; USAGE VALIDITY PERIOD hérite de USAGE PARAMETER.  « PK » id UsageValidityPeriodIdType 1:1 Identifiant du USAGE VALIDITY PERIOD.  « enum » ValidityType ValidityTypeEnum 0:* Type of USAGE VALIDITY PERIOD. See allowed values below.\n singleRide A single ride.\n singleTrip A single trip.\n returnTrip A return trip.\n carnet A number of individual trips.\n dayPass Ticket valid for a day.\n weeklyPass Valid for one week.\n weekendPass Valid for one weekend.\n monthlyPass Valid for one month.\n annualPass Valid for one year.\n seasonTicket Ticket valid for specified period of several days, weeks or months.\n profileMembership Ticket valid while member of a COMMERCIAL PROFILE or USER PROFILE.\n subscription Product valid for specified period of subscription.\n openEnded Ticket valid until otherwise notified.\n other Other Validity period\n   « enum » UsageTrigger UsageTriggerEnum 0:1 Trigger event that starts validity period. See allowed values below.\n startOfPeriod Start of period. Beginning time for period in which first use occurs (for Capping products)\n startOutboundRide Start of outbound trip.\n endOutboundRide End of outbound trip.\n startReturnRide Start of return trip\n enrolment Validity period starts when user registers (e.g. creates a customer account).\n reservation Validity period starts when user makes a reservation.\n purchase Starts on purchase.\n activation Validity period starts when user activates a product.\n specifiedStartDate Start date specified at purchase - may be different from purchase date.\n fulfilment Starts on collection.\n dayOffsetBeforeCalendarPeriod Becomes valid a given number days before start of calendar period where number of days is specified by a MONTH VALIDITY OFFSET.\n   « enum » UsageEnd UsageEndEnum 0:1 Classification du when the end of the Usage validity period occurs. May be a specified period (Standard Duration) or an event, e.g. end of trip. See allowed values below.\n standardDuration Period Ticket valid for specified after validation. May be in terms of trip or a specified period.\n endOfCalendarPeriod Ticket valid to end of calendar period.\n endOfRide Ticket valid to end of ride.\n endOfTrip Ticket valid to end of trip - may be several rides.\n endOfFareDay Ticket valid to end of fare day.\n endOfFarePeriod Ticket valid to end of fare period.\n productExpiry Product valid to end of product - for a travel card withe expiry date.\n deregistration Product valid until deregistration.\n profileExpiry Ticket valid while member of a profile. Stops when ends.\n other Other Validity period.\n    StandardDuration xsd:duration 0:1 Duration of VALIDITY PERIOD after departure. or validation  « enum » ActivationMeans ActivationMeansEnum 0:1 Means of activatiing start of period. See allowed values below.\n noneRequired No activation required.\n checkIn Activation occurs automatically on check-in at barrier, etc.\n useOfValidator Activation occurs on use of validator.\n useOfMobileDevice Activation is made by using mobile device.\n automaticByTime Activation occurs automatically at specified time of travel.\n automaticByProximity Activation occurs automatically by proximity to stop and/or vehicle.\n other Other means of activation.\n    StartDate xsd:date 0:1 Start date for VALIDITY PERIOD.   StartTime xsd:time 0:1 Start time for VALIDITY PERIOD.   EndDate xsd:date 0:1 End date for VALIDITY PERIOD.   EndTime xsd:time 0:1 End time for VALIDITY PERIOD.    UsageValidityPeriodStartConstraintGroup – Group Elements relating to the start of the Validity Period.\nUsageValidityPeriodStartConstraintGroup – Group   Classification Name Type Cardinality Description    « enum » UsageStartConstraintType UsageStartConstraintEnum 0:1 Whether start type of trip or pass is variable or fixed. See allowed values below.\n variable Validity start date can be chosen by user.\n fixed Validity start date is constrained. For a pass to certain days of week, month or year. For a trip to a specific train.\n fixedWindow Validity start date for a trip is constrained relative to start of booked service, e.g. may catch previous train as well.\n noTravelWithinTimeband No travel permitted within exclusion time band of a day.\n   « cntd » startOnlyOn DayType 0:* Prices for the USAGE PARAMETER.   MaximumServicesBefore xsd:nonNegativeInteger 0:1 If UsageStartConstraintType is \"fixedWindow\", maximum number of services before the booked train that may also be used.   FlexiblePeriodBefore xsd:duration 0:1 If UsageStartConstraintType is \"fixedWindow\", maximum period before the booked train during which other trains may also be caught.   MaximumServicesAfter xsd:nonNegativeInteger 0:1 If UsageStartConstraintType is \"fixedWindow\", maximum number of services after the booked train that may also be used.   FlexiblePeriodAfter xsd:duration 0:1 If UsageStartConstraintType is \"fixedWindow\", maximum period after the booked train during which other trains may also be caught.    Suspending – Element Conditions governing temporary suspension of a FARE PRODUCT, (i.e. period pass or subscription).\nSuspending – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; UsageParameter ::\u0026gt; SUSPENDING hérite de USAGE PARAMETER.  « PK » id SuspendingIdType 1:1 Identifiant du USAGE VALIDITY PERIOD.  « enum » SuspensionPolicy SuspensionPolicyEnum 0:* Allowed policies for suspending term of product.\n none Suspension not allowed.\n forCertifiedIllness Suspension allowed for illness.\n forParentalLeave Suspension allowed for parental leave.\n forHoliday Suspension allowed for holiday.\n forAnyReason Suspension allowed for any reason\n weeklyPass Valid for one week.\n weekendPass Valid for one weekend.\n monthlyPass Valid for one month.\n seasonTicket Ticket valid for specified period of several days, weeks or months.\n profileMembership Ticket valid while member of a COMMERCIAL PROFILE or USER PROFILE.\n openEnded Ticket valid until otherwise notified.\n other Other Validity period\n    QualificationPeriod duration 0:1 Minimum duration that shall have occurred before a suspension is allowed.   QualificationPercent decimal 0:1 Minimum proportion of term that shall have occurred before a suspension is allowed.   MinimumSuspensionPeriod duration 0:1 Minimum duration allowed for a suspension.   MaximumSuspensionPeriod duration 0:1 Maximum duration allowed for a suspension.   MaximumNumberOfSuspensionsPerTerm nonNegativeInteger 0:1 Maximum duration allowed for a suspension. with the term of the fare product or subscription.    Usage Parameter: Eligibility – Attributes GroupTicket – Element The number and characteristics of persons entitled to travel in addition to the holder of an access right.\nGroupTicket – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; UsageParameter ::\u0026gt; GROUP TICKET hérite de USAGE PARAMETER.  « PK » id GroupTicketIdType 1:1 Identifiant du GROUP TICKET.  « FK » TypeOfConcessionRef TypeOfConcessionRef  Type of concession to which this group applies.  XGRP GroupTicketSizeGroup xmlGroup 0:1 Elements relating to size of group.  XGRP GroupTicketCalculationGroup xmlGroup 0:1 Elements relating to calculation of group discount.  « enum » JointCheckIn GroupCheckInEnum 0:1 Whether joint check in is required. See allowed values below.\n none No group check in.\n required Passengers shall check in together.\n allowed Passengers may check in together.\n   « enum » Ticketing GroupTicketingEnum 0:1 Nature of tickets issued for group. See allowed values\n allOnOneTicket A single ticket is issued for the whole group.\n separateTickets Separate tickets are issued for each member of the group.\n ticketWithCoupons There is a main ticket with coupons for each member.\n other Other ticketing.\n   « enum » GroupBookingFacility GroupBookingEnum 0:1 Type of Group Booking allowed. See NeTEx Part1.    GroupTicketSizeGroup – Group The GroupTicketSizeGroup specifies the number and characteristics of persons entitled to travel in addition to the holder of an access right.\nGroupTicketSizeGroup – Group    Classification Name Type Cardinality Description      MinimumNumberOfPersons NumberOfPersons 0:1 Minimum number of persons overall allowed on GROUP TICKET.    MaximumNumberOfPersons NumberOfPersons 0:1 Maximum number of persons overall allowed on GROUP TICKET.    MinimumNumberOfCardHolders NumberOfPersons 0:1 Minimum number of card holders required to qualify for this GROUP TICKET.   « cntd » companionProfiles CompanionProfile 0:* COMPANION OR GROUP allowed in each USER PROFILE category.    GroupTicketCalculationGroup – Group The GroupTicketCalculationGroup specifies parameters affecting the calculation of the group discount.\nGroupTicketCalculationGroup – Group   Classification Name Type Cardinality Description    « enum » PricingBasis PerBasisEnum 0:1 Basis on which pricing is done - per whole group or per member. See allowed values below.\n none No companion allowed.\n free All members free.\n discountForAll Discount for all members of group.\n discountForFirstMemberOfGroup Discount for first member of group only.\n discountForSecondAndSubsequentMembersOfGroup Discount for second and subsequent member of group.\n stepDiscount Discount depends on number of people in group.\n    MaximumPersonsFree NumberOfPassengers 0:1 Number of persons allowed free on ticket.   MaximumPersonsDiscounted NumberOfPassengers 0:1 Maximum number of persons for which a group discount is allowed.   DiscountOnlyForFirstPerson xsd:boolean 0:1 Whether there is only a discount for the first person in the group.   MinimumNumberOfCardHolders NumberOfPassengers 0:1 Minimum number of persons in the group who shall hold a qualifying railcard for the discount to be granted.   OneForNPersons NumberOfPassengers 0:1 Whether discount is on a one-for-n basis. Intermediate numbers are rounded down.   GroupSizeChanges GroupSizeChangesEnum 0:1 Possibilities for changing the number of people in the group. See allowed values below.\n noCharge Group size cannot be changed\n free No charge to change group size.\n charge Charge for changing group size.\n discountForFirstMemberOfGroup Discount for first member of group only.\n purchaseWindowSteppedCharge Group size can be changed, charges are according to a sliding scale according to the length of time before travel (as specified by several EXCHANGING parameters)\n numberOfPassengersSteppedCharge Group size can be changed, charges are according to a sliding scale according to the number of passengers changed.\n     UserProfile – Element The social profile of a passenger, based on age group, education, profession, social status, sex etc., often used for allowing discounts: 18-40 years old, graduates, drivers, unemployed, women etc.\nUserProfile – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; UsageParameter ::\u0026gt; USER PROFILE hérite de USAGE PARAMETER.  « PK » id UserProfileIdType 1:1 Identifiant du USER PROFILE.  « FK » BaseUserProfileRef UserProfileIdType 0:1 Base USER PROFILE which this profile refines.  « FK » TypeOfConcessionRef TypeOfConcessionRef 0:1 Classification by type of concession.  « enum » UserType UserTypeEnum 0:1 Classification du user type.\n anyone User is any type of person.\n adult User is a human.\n child User is a child.\n infant User is an infant.\n senior User is a senior.\n schoolPupil User is school pupil.\n student User is a student.\n youngPerson User is a young person.\n disabled User is a guide dog.\n disabledCompanion User is a guide dog.\n employee User is an employee of a company.\n military User is a member of the armed forces.\n jobSeeker User is unemployed.\n guideDog User is a guide dog.\n animal User is an animal.\n   XGRP UserProfileQualificationGroup xmlGroup 0:1 Elements describing eligibility conditions for user.  « enum » GenderLimitation GenderLimitationList 0:1 Gender required by USER PROFILE. Relevant for single sex accommodation products.  « enum » ProofRequired ProofOfIdentityEnum 0:* Proof required for type of user. See allowed values below.\n noneRequired No proof required.\n passport Proof is to show a passport.\n drivingLicence Proof is to show a driving licence.\n birthCertificate Proof is to show a birth certificate.\n membershipCard Proof is to show an Identify document. such as a passport or driving licence.\n studentCard Proof is to show a student card.\n identityDocument Proof is to show an Identify document.\n creditCard Proof is to show a credit card.\n medicalDocument Proof is to show a medical document or letter from a medical authority.\n letterWIthAddress Proof is to show a letter or bill from an organisation to the applicant’s address.\n measurement Height or other physical measurement.\n emailAccount Proof is to respond from a valid email account.\n mobileDevice Proof is to respond from a mobile device associé au an account.\n other Other proof.\n   « enum » DiscountBasis DiscountBasisEnum 0:1 Nature of discount for this type of user. See earlier for allowed values.  « cntd » companionProfiles CompanionProfile 0:* COMPANION PROFILEs describing users who may travel with user.    UserProfileQualificationGroup – Group The UserProfileQualificationGroup specifies attributes describing the eligibility of a user to belong to a USER PROFILE.\nUserProfileQualificationGroup – Group    Classification Name Type Cardinality Description      MinimumAge xsd:integer 0:1 Minimum age for membership of USER PROFILE.    MaximumAge xsd:integer 0:1 Maximum age for membership of USER PROFILE.    MonthDayOnWhichAgeApplies xsd:gmonthDay 0:1 Day / Month on which age applies. if any.    MinimumHeight LengthType 0:1 Minimum height for membership of USER PROFILE. For example, to restrict access for health and safety reasons.    MaximumHeight LengthType 0:1 Maximum weight for membership of USER PROFILE. This may be relevant for example for judging large dogs, or a limit on children.    LocalResident xsd:boolean 0:1 Whether user shall be local resident. The default value is ‘true’.   « cntd » resides ResidentialQualification 0:* RESIDENTIAL QUALIFICATIONs for USER PROFILE – if more than one, these will be logically ORed together.    ResidentialQualification – Element The RESIDENTIAL QUALIFICATION element describes a requirement to live in a certain area.\nResidentialQualification – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; VersionedChild ::\u0026gt; RESIDENTIAL QUALIFICATION hérite de VERSIONED CHILD. See NeTEx Part1.  « PK » id ResidentialQualificationIdType 1:1 Identifiant du RESIDENTIAL QUALIFICATION.   Name MultilingualString 0:1 Nom du RESIDENTIAL QUALIFICATION.   Description MultilingualString 0:1 Description du RESIDENTIAL QUALIFICATION.  « FK » ParentRef UsageParameterRef+ 0:1 Parent USER PROFILE for whom this specifies a RESIDENTIAL QUALIFICATION.   MustReside xsd:boolean 0:1 Whether the user shall or shall not reside in specified TOPOGRAPHIC PLACE.  « FK » TopographicalPlaceRef TopographicalPlaceRef 0:1 TOPOGRAPHIC PLACE for which residency rule applies. See NeTEx Part1.  « enum » ResidenceType ResidenceTypeEnum 0:1 Classification du type of residence required, e.g. live, work, study.\n live Shall live in specified area.\n work Shall work in specified area.\n study Shall be in full time education in specified area.\n exchange Shall be on qualifying exchange programme in specified area.\n born Shall have been born in the specified area.\n nonResident Shall not reside in the specified area.\n    MinimumDuration xsd:duration 0:1 Minimum period of residency needed to qualify.    CompanionProfile – Element The COMPANION PROFILE specifies the number and characteristics of persons entitled to travel in addition to the holder of an access right, for example children, wheelchair carer, etc.\nCompanionProfile – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; UsageParameter ::\u0026gt; COMPANION PROFILE hérite de USAGE PARAMETER.  « PK » id GroupTicketUserIdType 1:1 Identifiant du COMPANION PROFILE.   ParentRef UsageParameterRef+ 0:1 Parent USER PROFILE for whom this specifies an allowed companion type.  « FK » UserProfileRef UserProfileRef 0:1 Reference USER PROFILE defining a category of people eligible to be a companion.  « enum » CompanionRelationship CompanionRelationshipEnum 0:1 Required relationship of companion to eligible user. See allowed values below. .\n anyone Anyone\n parent Parent\n grandparent Grandparent\n child Childe\n grandchild Grandchild\n family Family\n spouse Spouse\n partner Partner\n dependent Dependent\n colleague Colleague\n pupil Pupil\n teacher Teacher\n carer Carer\n    MinimumNumberOfPersons xsd:integer 0:1 Minimum number of persons overall allowed of this type.   MaximumNumberOfPersons xsd:integer 0:1 Maximum number of persons overall allowed of this type.  « enum » DiscountBasis DiscountBasisEnum 0:1 Nature of discount for this type of user. See allowed values earlier.    CommercialProfile – Element A category of users depending on their commercial relations with the operator (frequency of use, amount of purchase etc.), often used for allowing discounts.\nCommercialProfile – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; UsageParameter ::\u0026gt; COMMERCIAL PROFILE hérite de USAGE PARAMETER.   « PK » id CommercialProfileIdType 1:1 Identifiant du COMMERCIAL PROFILE.   « FK » TypeOfConcessionRef TypeOfConcessionRef 0:1 Référence à un TYPE OF CONCESSION.    ConsumptionAmount xsd:anyType 0:1 Consumption amount associé au COMMERCIAL PROFILE.    ConsumptionUnits xsd:anyType 0:1 Units for Consumption amount associé au COMMERCIAL PROFILE.    GeneralGroupOfEntitiesRef GeneralGroupOfEntitiesRef 0:1 GROUP OF ORGANISATIONs or other entities associé au the COMMERCIAL PROFILE.    TypeOfConcession – Element A Classification du USER PROFILE by type of person eligible to use it\nTypeOfConcession – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; TypeOfValue ::\u0026gt; TYPE OF CONCESSION hérite de TYPE OF VALUE. See NeTEx Part1.   « PK » id TypeOfConcessionIdType 1:1 Identifiant du TYPE OF CONCESSION.   « cntd » alternativeNames AlternativeName 0:* Alternative names for VALUE.    EligibilityChangePolicy – Element A Classification du USER PROFILE by type of person eligible to use it\nEligibilityChangePolicy – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; UsageParameter ::\u0026gt; ELIGIBILITY CHANGE POLICY hérite de USAGE PARAMETER.  « PK » id EligibilityChangePolicyIdType 1:1 Identifiant du ELIGIBILITY CHANGE POLICY.  « enum » OnBecomingEligiblePolicy OnBecomingEnumeration 0:1 Policy to apply on product holder becoming eligible.\n automatic Automatically enrol or upgrade the user. To reflect status change.\n invite Invite the user to change products.\n noAction Take no action.\n other Other action.\n   « enum » OnCeasingToBeEligiblePolicy OnCeasingEnum 0:1 Policy to apply on product holder ceasing to be eligible. See allowed values below.\n onCeasingEligibility Allowed values for Ceasing to be eligible.\n immediateTermination If user ceases to be eligible, automatically terminate validity of an eligibility dependent product.\n useUntilExpiry If user ceases to be eligible, they may go on using the product until it expires.\n terminateAfterGracePeriod If user ceases to be eligible, termination take place after the end of a grace period\n automaticallySubstituteProduct If user ceases to be eligible, automatically substitute them with an appropriate replacement product.\n noAction If user ceases to be eligible, take no action.\n other Other action.\n     Usage Parameter: Entitlement – Attributes EntitlementRequired – Element Receiving of entitlement from another FARE PRODUCT.\nEntitlementRequired – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; UsageParameter ::\u0026gt; ENTITLEMENT REQUIRED hérite de USAGE PARAMETER.   « PK » id EntitlementRequiredIdType 1:1 Identifiant du ENTITLEMENT REQUIRED.   « FK » ServiceAccessRightRef ServiceAccessRightRef 0:1 Entitlement comes from the referenced FARE PRODUCT.    MinimumQualificationPeriod xsd:duration 0:1 Minimum period that required product shall be held in order to be eligible.    EntitlementConstraint EntitlementConstraint 0:1 Constraints on related product or offer.    EntitlementGiven – Element Granting of entitlement to another FARE PRODUCT.\nEntitlementGiven – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; UsageParameter ::\u0026gt; ENTITLEMENT GIVEN hérite de USAGE PARAMETER.  « PK » id EntitlementGivenIdType 1:1 Identifiant du ENTITLEMENT GIVEN.  « FK » ServiceAccessRightRef ServiceAccessRightRef 0:1 Entitlement comes from the referenced FARE PRODUCT.   MinimumQualificationPeriod xsd:duration 0:1 Minimum period that product shall be held for entitlement to be granted.   EntitlementConstraint EntitlementConstraint 0:1 Constraints on related product or offer.  « enum » EntitlementType EntitlementTypeEnum 0:1 Type of entitlement. See allowed values below.\n use Entitlement is to use product.\n purchase Entitlement is to purchase product.\n none No entitlement.\n     EntitlementConstraint – Element Constraints on choices for an dependent entitled product relative to the required choices for the prerequisite entitling product.\n7.6.1.3.7.3 EntitlementConstraint – Element   Classification Name Type Cardinality Description    « enum » PeriodConstraint SamePeriodEnum 0:1 Constraint on validity period of associated product, e.g. Same time, same day, same period. See allowed values below.\n any No period constraint.\n samePeriod Shall be for same period as related product.\n withinSamePeriod Shall be within period of related product.\n sameDay Shall be for same day as related product.\n sameDayOfReturn Shall be for same day of return of related product.\n sameFareDay Shall be for same FARE DAY as related product.\n nextDay Shall be for next FARE DAY as that of related product.\n equivalentDuration Shall be equivalent to period of related product.\n  different Shall be different from period of related product.\n  « enum » OriginConstraint SameStopEnum 0:1 Constraint on origin SCHEDULED STOP POINT of associated product. E.g. same stop.\n any No constraint.\n same Shall be same as that of related product.\n sameAsOrigin Shall be same as origin of related product.\n sameAsDestination Shall be same as destination of related product.\n sameAsOriginOrDestination Shall be for same origin or destination of related product.\n anyStopOnRoute Shall be within one of the stops on the route of the related product.\n anyStopInZone Shall be within zone of related product.\n different Shall be different from that of related product.\n   « enum » DestinationConstraint SameStopEnum 0:1 Constraint on destination SCHEDULED STOP POINT of product. See allowed values above.  « enum » TariffZoneConstraint SameZoneEnum 0:1 Constraint on TARIFF ZONE of associated product.\n any No constraint.\n same Shall be same as related product.\n sameAsOrigin Shall be same as origin of related product.\n sameAsDestination Shall be same as destination of related product.\n sameAsOriginOrDestination Shall be for same origin or destination of related product.\n within Shall be within zone of related product.\n containing Shall contain zone of related product.\n equivalent Shall be equivalent to access right ZONE of related product.\n different Shall be different from that of related product.\n   « enum » DirectionConstraint SameRouteEnum 0:1 Constraint on DIRECTION of use of associated product.\n any No constraint.\n same Shall be same as that of related product.\n oppositeDirection Shall be opposite to that of related product.\n different Shall be different from that of related product.\n   « enum » RouteConstraint SameRouteEnum 0:1 Constraint on ROUTE of associated product. See allowed values above.  « enum » OperatorConstraint SameOperatorEnum 0:1 Constraint on OPERATOR of associated product. E.g. same operator.\n any No constraint.\n same Shall be same as that of related product.\n participating Shall be participant in interoperating agreement with operator of related product.\n different Shall be different from that of related product.\n   « enum » TypeOfProductCategoryConstraint SameTypeOfProductCategoryEnum 0:1 Constraint on TYPE OF PRODUCT CATEGORY of associated product.\n any No constraint.\n same Shall be same as that of related product.\n sameOrEquivalent Shall be equivalent to that of related product.\n different Shall be different from that of related product.\n   « enum » ClassOfUseConstraint SameClassOfUseEnum 0:1 Constraint SERVICE JOURNEY of associated product.\n any No constraint.\n same Shall be same as that of related product.\n sameOrEquivalent Shall be equivalent to that of related product.\n different Shall be different from that of related product.\n   « enum » TypeOfTravelDocumentConstraint SameTypeOfTravelDocumentEnum 0:1 Constraint on TYPE OF TRAVEL DOCUMENT of associated product.\n any No constraint.\n same Shall be same as that of related product.\n sameMedia Shall use same media as that of related product.\n sameSmartCard Shall be on same smart card ad that of related product.\n sameMobileApp Shall use same mobile app as that of related product.\n different Shall be different from that of related product.\n   « enum » JourneyConstraint SameJourneyEnum 0:1 Constraint on SERVICE JOURNEY of associated product.\n any No constraint.\n same Shall be same as that of related product.\n similar Shall be similar to that of related product.\n different Shall be different from that of related product.\n   « enum » UserConstraint SameUserEnum 0:1 Constraint on CUSTOMER and USER PROFILEs of associated product.\n anyone No constraint on eligibility.\n samePerson Shall be same person as that of associated product.\n differentPerson Shall be diferent person as that of associated product.\n specific Shall be belomg to a given USER PROFILE.\n   « cntd » specificProfiles UserProfileRef 0:* Specific user profiles to which USER PROFILEs to which entitlement applies.    Usage Parameter: Luggage – Attributes LuggageAllowance – Element The number and characteristics (weight, volume) of luggage that a holder of an access right is entitled to carry.\nLuggageAllowance – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; UsageParameter ::\u0026gt; LUGGAGE ALLOWANCE hérite de USAGE PARAMETER.  « PK » id LuggageAllowanceIdType 1:1 Identifiant du LUGGAGE ALLOWANCE.  « enum » BaggageUseType BaggageUseEnum 0:1 Use of baggage covered by the allowance. See allowed values below.\n carryOn Luggage is to carry on.\n checkIn Luggage is to check in.\n oversizeCheckIn Oversize bag check in.\n   « enum » BaggageType LuggageUseEnum 0:1 Type of baggage covered by the allowance. See allowed values below.\n handbag Hand bag.\n handLuggage Hand luggage.\n smallSuitcase Small suitcase.\n suitcase Suitcase.\n trunk Trunk.\n oversizeItem Oversized item.\n bicycle Bicycles.\n sportingEquipment Sporting equipment.\n skis Skis.\n musicalInstrument Musical Instruments.\n pushChair Push chair.\n motorizedWheelchair Motorized Wheelchair.\n largeMotorizedWheelchair Large on street Motorized Wheelchair.\n wheelchair Wheelchair (non-motorized).\n smallAnimal Small animal.\n animal Animal.\n game Dead Game animals.\n motorcycle Motor cycle.\n other Other baggage item.\n   « enum » LuggageAllowanceType LuggageAllowanceEnum 0:1 Classification du allowance type. See allowed values below.\n none Luggage is to carry on.\n unlimited Unlimited baggage allowance.\n single Single bag allowed.\n limited Baggage limited by restriction.\n    MaximumNumberOfItems xsd:nonNegativeInteger 0:1 Number of bags allowed.   MaximumBagHeight LengthType 0:1 Maximum bag height.   MaximumBagWidth LengthType 0:1 Maximum bag width.   MaximumBagDepth LengthType 0:1 Maximum bag depth.   MaximumBagWeight WeightType 0:1 Maximum bag weight.   TotalWeight WeightType 0:1 Total Weight limit of LUGGAGE ALLOWANCE.  « enum » LuggageChargingBasis LuggageChargingBasisEnum 0:1 Basis on which luggage is charged. See allowed values below.\n free Luggage is free.\n chargedByItem Luggage is charged by item (subject to item size and weight restrictions).\n chargedByWeight Luggage is charged by weight.\n other Luggage is charge don a different basis\n     Usage Parameter: Booking – Attributes PurchaseWindow – Element Period in which the product shall be purchased.\nPurchaseWindow – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; UsageParameter ::\u0026gt; PURCHASE WINDOW hérite de USAGE PARAMETER.  « PK » id PurchaseWindowIdType 1:1 Identifiant du PURCHASE WINDOW.  « enum » PurchaseAction PurchaseActionEnum 0:1 Action governed by Purchase Window. The default value is ‘purchase’. See allowed values below.\n purchase Purchase\n orderWithoutPayment Order without payment\n reserve Reserve\n payForPreviousOrder Pay for pervious order\n subscribe Set up subscription.\n payInstallment Pay subscription installment.\n other Other\n   « enum » PurchaseWhen PurchaseWhenEnum 0:1 When purchase may be made. See Part1 for allowed values.\n advanceOnly Purchase may only be made in advance.\n untilPreviousDay Purchase may only be made in advance up until the day previous to travel.\n dayOfTravelOnly Purchase may only be made on day of travel.\n advanceAndDayOfTravel Purchase may be made in advance or on day of travel.\n timeOfTravelOnly Purchase may only be made at time of travel.\n subscriptionChargeMoment Purchase may made at one of the agreed charging moments for a subscription. advance.\n other Other limitation on who may make a booking.\n    LatestTime xsd:duration 0:1 Latest time on specified last day when ticket can be purchased.   MinimumPeriodBeforeDeparture xsd:duration 0:1 Minimum duration before departure that ticket may be purchased.  « FK » MinimumPeriodIntervalRef TimeIntervalRef 0:1 Minimum period before departure that purchase shall be made - as arbitrary interval.   MaximumPeriodBeforeDeparture xsd:duration 0:1 Maximum duration before departure that ticket may be purchased.  « FK » MaximumPeriodIntervalRef TimeIntervalRef 0:1 Maximum period before departure that purchase shall be made - as arbitrary interval.  « enum » PurchaseMoment PurchaseMomentEnum 0:1 Permitted moments of purchase. See Part1 for allowed values.    Reserving – Element Indicating whether the access right requires reservation and any limitations on making and changing reservations.\nReserving – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; UsageParameter ::\u0026gt; RESERVING hérite de USAGE PARAMETER.  « PK » id ReservingIdType 1:1 Identifiant du RESERVING.  « enum » ReservingRequirements ServiceReservationFacilityEnum 0:* Nature of reservations required. See NeTEx Part1 for allowed values.   MinimumNumberToReserve NumberOfPassengers 0:1 Minimum number of persons allowed on a reservation.   MaximumNumberToReserve NumberOfPassengers 0:1 Minimum number of persons allowed on a reservation.   MustReserveWholeCompartment. xsd:boolean 0:1 Whether a whole compartment shall be reserved.  « enum » ReservationChargeType ReservationChargeTypeEnum 0:1 Nature of reservation fee. See allowed values below.\n noFee No reservation fee.\n fee Reservation fee.\n singleFeeForReturnTrip Single reservation fee for return trip.\n feeForEachDirection Separate reservation fee is for each direction of travel.\n feeForEachLeg Separate reservation fee is for each leg.\n   « enum » FeeBasis PerBasisEnum 0:1 Basis on which refund is made. See allowed values below.\n perOffer Refund is per offer.\n perPerson Refund is per person.\n    HasFreeConnectingReservations xsd:boolean 0:1 Whether connecting reservations are all free or not.   NumberOfFreeConnectingReservations xsd:integer 0:1 Number of free connecting reservations allowed.   IsFeeRefundable xsd:boolean 0:1 Whether reservation fees is refundable.  « cntd » BookingArrangements BookingArrangements 0:1 Booking arrangements. See Part1 Service Restrictions Model.  « enum » SeatAllocationMethod SeatAllocationMethodEnum 0:1 Method for allocating seat.\n autoAssignment A seat will be assigned automatically by an algorithm.\n seatMap The passenger may choose a specific seat from the available seats.\n openSeating It is not possible to reserve a specific seat\n    ReservationExpiryPeriod xsd:duration 0:1 Period after which reservation without payment will expire if not paid for.    Cancelling – Element Requirements for cancelling a booking.\nCancelling – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; UsageParameter ::\u0026gt; CANCELLING hérite de USAGE PARAMETER.   « PK » id CancellingIdType 1:1 Identifiant du CANCELLING element.    BookingArrangements BookingArrangements 0:1 Arrangements for cancelling a booking. See Part1 Service restrictions Model    BookingArrangements – Group Information about booking to make a cancellation or other change. See also Part1 for details.\nBookingArrangements Group – Group    Classification Name Type Cardinality Description      BookingContact Contact 0:1 Contact for Booking.   « enum » BookingMethods BookingMethodEnum 0:* Booking method for FLEXIBLE LINE.   « enum » BookingAccess BookingAccessEnum 0:1 Who can make a booking. See Part1.   « enum » BookWhen PurchaseWhenEnum 0:1 When Booking can be made. See Part1   « enum » BuyWhen PurchaseMomentEnum 0:* When purchase can be made. See Part1.    LatestBookingTime xsd:time 0:1 Latest time in day that booking can be made.    MinimumBookingPeriod xsd:duration 0:1 Minimum interval in advance of departure day or time that service may be ordered.    BookingUrl xsd:anyURI 0:1 URL for booking.    BookingNote MultilingualString 0:1 Note about booking the FLEXIBLE LINE.    Usage Parameter: After Sales – Attributes Transferability – Element The number and characteristics of persons entitled to use the public transport service instead of the original customer.\nTransferability – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; UsageParameter ::\u0026gt; TRANSFERABILITY hérite de USAGE PARAMETER.  « PK » id TransferabilityIdType 1:1 Identifiant du TRANSFERABILITY.   CanTransfer xsd:boolean 0:1 Whether ticket can be transferred to someone else.   MaximumNumberOfNamedTransferees NumberOfPassengers 0:1 Where a product can be used by a limited number of named users, maximum number of users allowed.   HasTransferFee xsd:boolean 0:1 Whether there is a charge for making a transfer.  « enum » SharedUsage SharedUsageEnum 0:1 Indicates the nature of the permitted sharing, if any, of products that can be shared, e.g. Trips from a multi-trip carnet. See allowed values\n singleUser Product can only be used by only one person at a time.\n concurrent Users Product can be used by several persons at a time., e.g. carnet.\n concurrentDesignatedUsers Product can be shared at the same time but only with designated types of companions, e.g. children.\n     Reselling – Element Common resale conditions (i.e. for exchange or refund) attaching to the product.\nReselling – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; UsageParameter ::\u0026gt; RESELLING hérite de USAGE PARAMETER.  « PK » id ResellingIdType 1:1 Identifiant du RESELLING.  « enum » Allowed ResellTypeEnum 0:1 Whether exchange or refund is allowed. See allowed values below.\n none Ticket can never be exchanged or refunded.\n partial Partial refund or exchange allowed.\n full Full refund allowed.\n    CanChangeClass xsd:boolean 0:1 Whether user can change class.   UnusedTicketsOnly xsd:boolean 0:1 Whether it is possible to exchange partially used tickets.   OnlyAtCertainDistributionPoints xsd:boolean 0:1 Whether distribution is restricted to certain points.  XGRP ResellingPeriodGroup xmlGroup 0:1 When Period may take place.   HasFee xsd:boolean 0:1 Whether these is a fee for a refund or exchange.  « enum » RefundBasis PerBasisEnum 0:1 Basis on which refund is made. See allowed values below.  « enum » PaymentMethods PaymentMethodEnum 0:* PAYMENT METHODs that may be used for transaction. See Part1 RC service Restriction model.  « ctd » TypeOfPaymentMethod TypeOfPaymentMethod 0:* PAYMENT METHODs that may be used for transaction.    ResellingPeriod – Group The ResellingPeriod group species when a refund or exchange may take place.\n  Classification Name Type Cardinality Description    « enum » ResellWhen ResellWhenEnum 0:1 Event marking when the is exchangeable status of the ticket changes. See allowed values below.\n never No transaction allowed, i.e. Ticket can never be exchanged or refunded.\n withinPurchaseGracePeriod Transaction allowed within purchase cool off period.\n beforeStartOfValidityPeriod Transaction allowed before start of Validity period of ticket.\n afterStartOfValidityPariod Transaction allowed after start of Validity period of ticket.\n afterEndOfValidityPariod Transaction allowed after end of Validity period of ticket.\n beforeFirstUse Transaction allowed before ticket first used.\n afterFirstUse Transaction still allowed after ticket has been partially used.\n beforeValidation Transaction allowed before ticket first validated.\n afterValidation Transaction allowed after ticket first validated.\n withinSpecifiedWindow Transaction allowed within specified window.\n anyTime Transaction allowed at any time.\n other Other condition.\n     CHOICE  From when refund/exchange can be made   a ExchangeableFromAnyTime EmptyType 0:1 Can be exchanged or refunded from any point after purchase.   b ExchangableFromDuration xsd:duration 0:1 Duration to start of period before (negative) or after (positive) the trigger point, (i.e. either Start Of Validity or First Use) after which ticket may be exchanged or refunded.   c ExchangableFromPercentUse xsd:decimal 0:1 Can be exchanged once a certain percentage of duration or use has been achieved.  « FK » ExchangeableFromIntervalRef TimeIntervalRef 0:1 TimeInterval determining period from which exchange can be made relative to trigger point.    CHOICE  Until when refund/exchange can be made   a ExchangeableUntilAnyTime EmptyType 0:1 Can be exchanged or refunded up until any point after purchase.    ExchangableUntilDuration xsd:duration 0:1 Duration to end of period before (negative) or after (positive) the trigger point (i.e. either Start Of Validity or First Use ) after which ticket may be exchanged or refunded.    ExchangableUntilPercentUse xsd:decimal 0:1 Can be exchanged until a certain percentage of duration or use has been achieved.  « FK » ExchangeableUntilIntervalRef TimeIntervalRef 0:1 TimeInterval determining period up until which exchange can be made relative to trigger point.  « enum » EffectiveFrom EffectiveFromEnum  Constraint on when change can be made\n never Cannot be made at any time.\n nextInterval Can take place at end of next product interval.\n nextInstallment Can take place at end of next subscription instalment.\n anyTime Can be made at any time.\n other Other condition\n    NotificationPeriod xsd:duration 0:1 Notice period needed before action is effective.    Exchanging – Element Whether and how access rights may be exchanged for other access rights.\nExchanging – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; Reselling ::\u0026gt; EXCHANGING hérite de RESELLING.  « PK » id ExchangingIdType 1:1 Identifiant du EXCHANGING.   NumberOfExchangesAllowed xsd:integer 0:1 Number of times a ticket may be exchanged.  « enum » ToFareClass FareClassEnum 0:1 Fare class to which can be exchanged. See NeTEx Part1. (From class would be expression as the Seat class on an ACCESS RIGHT PARAMETER ASSIGNMENT.)  « FK » ToClassOfUseRef ClassOfUseRef 0:1 CLASS OF USE class to which can be exchanged.  « enum » ExchangableTo ExchangableToEnum 0:1 Type of exchange allowed. The default is ‘anyProduct’, i.e. to any other fare. See allowed values below.\n anyProduct Can exchange to any other fare.\n sameProductSameDay Can exchange to fares of the same type for travel on the same date.\n sameProductLongerJourney Can exchange to fares of the same type for longer journey.\n sameProductShorterJourney Can exchange to fares of the same type for shorter journey.\n sameProductAnyDay Can exchange to fares of the same type for travel on the any date.\n upgradeToStandardFare Can exchange as upgrade to full standard fare.\n upgradeToSpecifiedFare Can exchange as an upgrade to a specified fare.\n downgradeToSpecifiedFare Can exchange as a downgrade to a specified fare.\n equivalentProduct Can exchange for an equivalent product.\n changeGroupSize Can change group size\n other Other condition.\n     Refunding – Element Whether and how the product may be refunded.\nRefunding – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; Reselling ::\u0026gt; REFUNDING hérite de RESELLING.  « PK » id RefundingIdType 1:1 Identifiant du REFUNDING.  « enum » RefundType RefundTypeEnum 0:1 Classification du REFUNDING. See allowed values below.\n unused Refund is because the product was unused.\n delay Refund is because the passenger’s trip was delayed.\n cancellation Refund is because the passenger‘s journey was cancelled.\n partialJourney Refund is because the product was only party unused.\n earlyTermination Refund is because the product was terminated early.\n changeOfGroupSize Refund is because the group size was changed.\n other Refund is because of some other reason.\n   « enum » RefundPolicy RefundPolicyEnum 0:* Reasons for giving refunds.\n any Any reason\n illness Death\n death Refund of unused ticket.\n maternity Maternity\n redundancy Redundancy\n changeOfEmployment Change of Employment.\n changeOfResidence Change of Residence.\n none No refunds given.\n other Other reason.\n   « enum » PartialRefundBasis PartialRefundBasisEnum 0:* Basis on which partial refunds of period passes etc are calculated.\n unusedDays Refund is for unused days.\n unusedWeeks Refund is for unused whole weeks.\n unusedMonths Refund is for unused whole months.\n unusedSemesters Refund is for unused whole academic terms.\n other Other refund.\n   « enum » PaymentMethod PaymentMethodEnum 0:* DEPRECATED – Use PaymentMethods on RESELLING higher in hierarchy    Replacing – Element Whether and how access rights may be replaced if lost or stolen.\nReplacing – Element    Classification Name Type Cardinality Description     ::\u0026gt; ::\u0026gt; Reselling ::\u0026gt; REPLACING hérite de RESELLING.   « PK » id ReplacingIdType 1:1 Identifiant du REPLACING.    Usage Parameter: Charging – Attributes ChargingPolicy – Element Policy regarding different aspects of charging such as credit limits.\nChargingPolicy – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; UsageParameter ::\u0026gt; CHARGING POLICY hérite de USAGE PARAMETER.  « PK » id ChargingPolicyIdType 1:1 Identifiant du CHARGING POLICY.  « enum » CreditPolicy CreditPolicyEnumeration 0:1 Policy for traveling on credit – See allowed values below.\n allowTravel Can travel even if credit is negative.\n blockPayAsYouGoTravel Block all pay as you go travel but allow prepaid travel.\n blockAllTravel Block all travel, even using other products.\n other Other policy.\n   “ ExpireAfterPeriod xsd:duration 0:1 Any expiry period on collecting a rebate or adjustment.   PaymentGracePeriod xsd:duration 0:1 Period after purchase by which time payment shall be settled.  « enum » BillingPolicy TravelBillingPolicyEnumeration 0:1 Policy for billing frequency – See Allowed values below.\n billAsYouGo Bill for use immediately on incurring travel.\n billOnThreshold Only raise bill when threshold is reached.\n billAtFareDayEnd Bill at end of every fare day.\n billAtPeriodEnd Bill at end of a specified period.\n     PenaltyPolicy – Element Policy regarding different aspects of penalty charges, for example repeated entry at the same station, no ticket etc.\nPenaltyPolicy – Element   Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; UsageParameter ::\u0026gt; PENALTY POLICY hérite de USAGE PARAMETER.  « PK » id PenaltyPolicyIdType 1:1 Identifiant du PENALTY POLICY.  « enum » PenaltyPolicyType PenaltyPolicyEnum 0:1 Classification du Penalty Policy. See below.\n noTicket Penalty is for having no ticket.\n noCheckIn Penalty is incurred if failed to check in\n noCheckOut Penalty is incurred if checked in and failed to check out.\n noValidation Penalty is incurred if have valid ticket but failed to validate it.\n other Other type of penalty.\n   « enum » SameStationEntryPolicy SameStationEntryPolicyEnum 0:1 Policy for allowing re-entry at the same station within a certain time. See below.\n blocked Re-entry not allowed.\n newFare Re-entry allowed and new fare charged.\n maximumFare Charge maximum fare to complete previous journey and start new journey.\n allowed Can re-enter without penalty and resume journey.\n    MinimumTimeBeforeRentry xsd:duration 0:1 Minimum time before can re-enter at the same station before incurring penalty.   MaximumNumberOfFailToCheckOutEvents xsd:duration 0:1 Limit on the number of fail-to-checkout events allowed before suspension.    Subscribing – Element Parameters governing subscription to a product allowing payment at regular intervals.\n  Classification Name Type Cardinality Description    ::\u0026gt; ::\u0026gt; UsageParameter ::\u0026gt; SUBSCRIBING hérite de USAGE PARAMETER.  « PK » id SubscribingIdType 1:1 Identifiant du SUBSCRIBING.  « enum » SubscriptionTermType SubscriptionTermTypeEnum 0:1 Types of subscription term allowed. See allowed values below.\n fixed Subscription shall be for a fixed term.\n variable Subscription can be for an arbitrary term.\n openEnded Subscription can be open-ended.\n    MinimumSubscriptionPeriod duration 0:1 Minimum duration allowed for a subscription.   MaximumSubscriptionPeriod duration 0:1 Maximum duration allowed for a subscription.  « enum » SubscriptionRenewalPolicy SubscriptionRenewalPolicyEnum 0:1 Policy on renewing subscription. See allowed values below.\n automatic Renew automatically at end of term.\n manual Renew on request.\n automaticOnConfirmation Confirm and renew automatically at end of subscription term\n none No renewal allowed.\n other Other.\n   « cntd » possibleInstallmentIntervals TimeIntervalRef 0:* Allowed billing Intervals for payment in installment.r  « enum » InstallmentPaymentMethods PaymentMethodsEnum 0:1 Allowed means of payment of installations as standard value.  « cntd » installmentPaymentMethods TypeOfPaymentMethod 0:* Allowed means of payment of installations as TYPE OF PAYMENT METHOD.    Exemples Inroduction Tarif simple \u0026lt;?xml version=\u0026#34;1.0\u0026#34;?\u0026gt; \u0026lt;PublicationDelivery xmlns=\u0026#34;http://www.netex.org.uk/netex\u0026#34; xmlns:xsi=\u0026#34;http://www.w3.org/2001/XMLSchemainstance\u0026#34; xsi:schemaLocation=\u0026#34;http://www.netex.org.uk/netex ./xsd/NeTEx_publication.xsd\u0026#34; version=\u0026#34;1.1\u0026#34;\u0026gt; \u0026lt;!--- =============== ENTETE =========== --\u0026gt; \u0026lt;PublicationTimestamp\u0026gt;2019-06-12T09:30:47.0Z\u0026lt;/PublicationTimestamp\u0026gt; \u0026lt;ParticipantRef\u0026gt;AURIGE001\u0026lt;/ParticipantRef\u0026gt; \u0026lt;!-- ========== DONNEES =========== --\u0026gt; \u0026lt;dataObjects\u0026gt; \u0026lt;!-- =========================================== --\u0026gt; \u0026lt;!-- CompositeFrame.de type NETEX_FRANCE --\u0026gt; \u0026lt;CompositeFrame version=\u0026#34;1\u0026#34; created=\u0026#34;2019-06-12T09:30:47.0Z\u0026#34; id=\u0026#34;FR-Tarif-Example:CompositeFrame:myFrame01:LOC\u0026#34;\u0026gt; \u0026lt;frames\u0026gt; \u0026lt;!-- =========================================== --\u0026gt; \u0026lt;!-- Frame NETEX_TARIF --\u0026gt; \u0026lt;GeneralFrame version=\u0026#34;001\u0026#34; id=\u0026#34;FR-Tarif-Example:TypeOfFrame:NETEX_TARIF-Example1:LOC\u0026#34;\u0026gt; \u0026lt;TypeOfFrameRef ref=\u0026#34;FR:TypeOfFrame:NETEX_TARIF\u0026#34;\u0026gt;version=\u0026#34;1.01:FR-NETEX_TARIF1.0\u0026#34;\u0026lt;/TypeOfFrameRef\u0026gt; \u0026lt;members modificationSet=\u0026#34;all\u0026#34;\u0026gt; \u0026lt;!-- ======================================================================= --\u0026gt; \u0026lt;!-- STRUCTURE TARIFAIRE ET DROITS DE BASE --\u0026gt; \u0026lt;TimeInterval id=\u0026#34;FR-Tarif-Example:TimeInterval:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Description\u0026gt;1h30 de validit\u0026amp;#xE9;\u0026lt;/Description\u0026gt; \u0026lt;Duration\u0026gt;PT90M\u0026lt;/Duration\u0026gt; \u0026lt;/TimeInterval\u0026gt; \u0026lt;ValidableElement id=\u0026#34;FR-Tarif-Example:ValidableElement:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;noticeAssignments\u0026gt; \u0026lt;NoticeAssignment id=\u0026#34;FR-Tarif-Example:NoticeAssignment:001:LOC\u0026#34; version=\u0026#34;any\u0026#34; order=\u0026#34;1\u0026#34;\u0026gt; \u0026lt;NoticeRef ref=\u0026#34;FR-Tarif-Example:Notice:001:LOC\u0026#34;/\u0026gt; \u0026lt;/NoticeAssignment\u0026gt; \u0026lt;/noticeAssignments\u0026gt; \u0026lt;fareStructureElements\u0026gt; \u0026lt;FareStructureElementRef ref=\u0026#34;FR-Tarif-Example:FareStructureElement:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;/fareStructureElements\u0026gt; \u0026lt;/ValidableElement\u0026gt; \u0026lt;FareStructureElement id=\u0026#34;FR-Tarif-Example:FareStructureElement:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;TimeIntervalRef ref=\u0026#34;FR-Tarif-Example:TimeInterval:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;/FareStructureElement\u0026gt; \u0026lt;!-- ===================================================================== --\u0026gt; \u0026lt;!-- LE TITRE --\u0026gt; \u0026lt;PreassignedFareProduct id=\u0026#34;FR-Tarif-Example:PreassignedFareProduct:T+001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Ticket 1h30\u0026lt;/Name\u0026gt; \u0026lt;AuthorityRef ref=\u0026#34;FR-Tarif-Example:Authority:IDFM:\u0026#34;/\u0026gt; \u0026lt;ConditionSummary\u0026gt; \u0026lt;TariffBasis\u0026gt;period\u0026lt;/TariffBasis\u0026gt; \u0026lt;CanBreakJourney\u0026gt;false\u0026lt;/CanBreakJourney\u0026gt; \u0026lt;IsRefundable\u0026gt;false\u0026lt;/IsRefundable\u0026gt; \u0026lt;IsExchangable\u0026gt;false\u0026lt;/IsExchangable\u0026gt; \u0026lt;/ConditionSummary\u0026gt; \u0026lt;validableElements\u0026gt; \u0026lt;ValidableElementRef ref=\u0026#34;FR-Tarif-Example:ValidableElement:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;/validableElements\u0026gt; \u0026lt;ProductType\u0026gt;singleTrip\u0026lt;/ProductType\u0026gt; \u0026lt;/PreassignedFareProduct\u0026gt; \u0026lt;!-- ======================================================== --\u0026gt; \u0026lt;!-- Offre à la vente --\u0026gt; \u0026lt;SalesOfferPackageElement id=\u0026#34;FR-Tarif-Example:SalesOfferPackageElement:001:LOC\u0026#34; version=\u0026#34;any\u0026#34; order=\u0026#34;1\u0026#34;\u0026gt; \u0026lt;RequiresValidation\u0026gt;true\u0026lt;/RequiresValidation\u0026gt; \u0026lt;TypeOfTravelDocumentRef ref=\u0026#34;FR-Tarif-Example:TypeOfTravelDocument:001:LOC\u0026#34;/\u0026gt; \u0026lt;PreassignedFareProductRef ref=\u0026#34;FR-Tarif-Example:PreassignedFareProduct:T+001:LOC\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;/SalesOfferPackageElement\u0026gt; \u0026lt;TypeOfTravelDocument id=\u0026#34;FR-Tarif-Example:TypeOfTravelDocument:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Ticket T+ carton a bande magn\u0026amp;#xE9;tique\u0026lt;/Name\u0026gt; \u0026lt;Url\u0026gt;http://www.navigo.fr/wp-content/uploads/2018/11/127099_Ticket-T_carnetde-10-300x136.png\u0026lt;/Url\u0026gt; \u0026lt;MediaType\u0026gt;paperTicket\u0026lt;/MediaType\u0026gt; \u0026lt;MachineReadable\u0026gt;magneticStrip\u0026lt;/MachineReadable\u0026gt; \u0026lt;/TypeOfTravelDocument\u0026gt; \u0026lt;SalesOfferPackage id=\u0026#34;FR-Tarif-Example:SalesOfferPackage:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Ticket \u0026amp;#xE0; l\u0026#39;unit\u0026amp;#xE9;\u0026lt;/Name\u0026gt; \u0026lt;salesOfferPackageElements\u0026gt; \u0026lt;SalesOfferPackageElementRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackageElement:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;/salesOfferPackageElements\u0026gt; \u0026lt;/SalesOfferPackage\u0026gt; \u0026lt;!-- ===================================================================== --\u0026gt; \u0026lt;!-- FARE TABLE avec affectation des prix --\u0026gt; \u0026lt;!-- Pour chaque cellule: Prix / UserProfile ou Entitlement / SalesOfferPackage (le lien avec les FareProduct est fait par le SalesOfferPackage) --\u0026gt; \u0026lt;FareTable version=\u0026#34;any\u0026#34; id=\u0026#34;lFR-Tarif-Example:TickeT+FareTable:001:LOC\u0026#34;\u0026gt; \u0026lt;Name\u0026gt; Bus Fare Prices - 18+Student \u0026lt;/Name\u0026gt; \u0026lt;cells\u0026gt; \u0026lt;Cell version=\u0026#34;any\u0026#34; id=\u0026#34;FR-Tarif-Example:Cell:001:LOC\u0026#34; order=\u0026#34;1\u0026#34;\u0026gt; \u0026lt;SalesOfferPackagePrice version=\u0026#34;any\u0026#34; id=\u0026#34;lFR-Tarif-Example:SalesOfferPackagePrice:001:LOC\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Ticket 1h30\u0026lt;/Name\u0026gt; \u0026lt;Amount\u0026gt;1.90\u0026lt;/Amount\u0026gt; \u0026lt;/SalesOfferPackagePrice\u0026gt; \u0026lt;SalesOfferPackageRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackage:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;NetworkRef ref=\u0026#34;FR-Tarif-Example:Network:001:\u0026#34;/\u0026gt; \u0026lt;!--Réseau concerné--\u0026gt; \u0026lt;noticeAssignments\u0026gt; \u0026lt;NoticeAssignmentView\u0026gt; \u0026lt;Text\u0026gt;Ticket 1h30 - a l\u0026#39;unit\u0026amp;#xE9; plein tarif - aAller retour interdit, gratuit pour le moins de 4 ans, ticket disponible en agence uniquement\u0026lt;/Text\u0026gt; \u0026lt;CanBeAdvertised\u0026gt;true\u0026lt;/CanBeAdvertised\u0026gt; \u0026lt;/NoticeAssignmentView\u0026gt; \u0026lt;/noticeAssignments\u0026gt; \u0026lt;/Cell\u0026gt; \u0026lt;!-- etc. --\u0026gt; \u0026lt;/cells\u0026gt; \u0026lt;/FareTable\u0026gt; \u0026lt;!-- ===================================================================== --\u0026gt; \u0026lt;/members\u0026gt; \u0026lt;/GeneralFrame\u0026gt; \u0026lt;/frames\u0026gt; \u0026lt;/CompositeFrame\u0026gt; \u0026lt;/dataObjects\u0026gt; \u0026lt;/PublicationDelivery\u0026gt; Tarif minimal (ultra simplifié) \u0026lt;?xml version=\u0026#34;1.0\u0026#34; encoding=\u0026#34;UTF-8\u0026#34;?\u0026gt; \u0026lt;PublicationDelivery xmlns=\u0026#34;http://www.netex.org.uk/netex\u0026#34; xmlns:xsi=\u0026#34;http://www.w3.org/2001/XMLSchemainstance\u0026#34; xsi:schemaLocation=\u0026#34;http://www.netex.org.uk/netex ./xsd/NeTEx_publication.xsd\u0026#34; version=\u0026#34;1.1\u0026#34;\u0026gt; \u0026lt;!--- =============== ENTETE =========== --\u0026gt; \u0026lt;PublicationTimestamp\u0026gt;2019-06-12T09:30:47.0Z\u0026lt;/PublicationTimestamp\u0026gt; \u0026lt;ParticipantRef\u0026gt;AURIGE001\u0026lt;/ParticipantRef\u0026gt; \u0026lt;!-- ========== DONNEES =========== --\u0026gt; \u0026lt;dataObjects\u0026gt; \u0026lt;!-- =========================================== --\u0026gt; \u0026lt;!-- CompositeFrame.de type NETEX_FRANCE --\u0026gt; \u0026lt;CompositeFrame version=\u0026#34;1\u0026#34; created=\u0026#34;2019-06-12T09:30:47.0Z\u0026#34; id=\u0026#34;FR-Tarif-Example:CompositeFrame:myFrame01:LOC\u0026#34;\u0026gt; \u0026lt;frames\u0026gt; \u0026lt;!-- =========================================== --\u0026gt; \u0026lt;!-- Frame NETEX_TARIF --\u0026gt; \u0026lt;GeneralFrame version=\u0026#34;001\u0026#34; id=\u0026#34;FR-Tarif-Example:TypeOfFrame:NETEX_TARIF-Example1:LOC\u0026#34;\u0026gt; \u0026lt;TypeOfFrameRef ref=\u0026#34;FR:TypeOfFrame:NETEX_TARIF\u0026#34;\u0026gt;version=\u0026#34;1.01:FR-NETEX_TARIF1.0\u0026#34;\u0026lt;/TypeOfFrameRef\u0026gt; \u0026lt;members modificationSet=\u0026#34;all\u0026#34;\u0026gt; \u0026lt;!-- ======================================================================== --\u0026gt; \u0026lt;!-- LE TITRE --\u0026gt; \u0026lt;PreassignedFareProduct id=\u0026#34;FR-Tarif-Example:PreassignedFareProduct:T+001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Ticket 1h30\u0026lt;/Name\u0026gt; \u0026lt;AuthorityRef ref=\u0026#34;FR-Tarif-Example:Authority:IDFM:\u0026#34;/\u0026gt; \u0026lt;ConditionSummary\u0026gt; \u0026lt;TariffBasis\u0026gt;period\u0026lt;/TariffBasis\u0026gt; \u0026lt;CanBreakJourney\u0026gt;false\u0026lt;/CanBreakJourney\u0026gt; \u0026lt;IsRefundable\u0026gt;false\u0026lt;/IsRefundable\u0026gt; \u0026lt;IsExchangable\u0026gt;false\u0026lt;/IsExchangable\u0026gt; \u0026lt;/ConditionSummary\u0026gt; \u0026lt;ProductType\u0026gt;singleTrip\u0026lt;/ProductType\u0026gt; \u0026lt;/PreassignedFareProduct\u0026gt; \u0026lt;!-- ======================================================================= --\u0026gt; \u0026lt;!-- FARE TABLE avec affectation des prix --\u0026gt; \u0026lt;!-- Version minimaliste sans SalesOfferPackage (le lien direct avec FareProduct) --\u0026gt; \u0026lt;FareTable version=\u0026#34;any\u0026#34; id=\u0026#34;lFR-Tarif-Example:TickeT+FareTable:001:LOC\u0026#34;\u0026gt; \u0026lt;Name\u0026gt; Bus Fare Prices - 18+Student \u0026lt;/Name\u0026gt; \u0026lt;cells\u0026gt; \u0026lt;Cell version=\u0026#34;any\u0026#34; id=\u0026#34;FR-Tarif-Example:Cell:001:LOC\u0026#34; order=\u0026#34;1\u0026#34;\u0026gt; \u0026lt;SalesOfferPackagePrice version=\u0026#34;any\u0026#34; id=\u0026#34;lFR-Tarif-Example:SalesOfferPackagePrice:001:LOC\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Ticket 1h30\u0026lt;/Name\u0026gt; \u0026lt;Amount\u0026gt;1.90\u0026lt;/Amount\u0026gt; \u0026lt;/SalesOfferPackagePrice\u0026gt; \u0026lt;PreassignedFareProductRef ref=\u0026#34;FR-Tarif-Example:PreassignedFareProduct:T+001:LOC\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;NetworkRef ref=\u0026#34;FR-Tarif-Example:Network:001:\u0026#34;/\u0026gt; \u0026lt;!--Réseau concerné--\u0026gt; \u0026lt;noticeAssignments\u0026gt; \u0026lt;NoticeAssignmentView\u0026gt; \u0026lt;Text\u0026gt;Ticket 1h30 - a l\u0026#39;unit\u0026amp;#xE9; plein tarif - aAller retour interdit, gratuit pour le moins de 4 ans, ticket disponible en agence uniquement\u0026lt;/Text\u0026gt; \u0026lt;CanBeAdvertised\u0026gt;true\u0026lt;/CanBeAdvertised\u0026gt; \u0026lt;/NoticeAssignmentView\u0026gt; \u0026lt;/noticeAssignments\u0026gt; \u0026lt;/Cell\u0026gt; \u0026lt;!-- etc. --\u0026gt; \u0026lt;/cells\u0026gt; \u0026lt;/FareTable\u0026gt; \u0026lt;!-- ======================================================================== --\u0026gt; \u0026lt;/members\u0026gt; \u0026lt;/GeneralFrame\u0026gt; \u0026lt;/frames\u0026gt; \u0026lt;/CompositeFrame\u0026gt; \u0026lt;/dataObjects\u0026gt; \u0026lt;/PublicationDelivery\u0026gt; BUS Ile de France \u0026lt;?xml version=\u0026#34;1.0\u0026#34;?\u0026gt; \u0026lt;PublicationDelivery xmlns=\u0026#34;http://www.netex.org.uk/netex\u0026#34; xmlns:xsi=\u0026#34;http://www.w3.org/2001/XMLSchemainstance\u0026#34; xsi:schemaLocation=\u0026#34;http://www.netex.org.uk/netex ./NeTEx/xsd/NeTEx_publication-NoConstraint.xsd\u0026#34; version=\u0026#34;1.1\u0026#34;\u0026gt; \u0026lt;!--- =============== ENTETE =========== --\u0026gt; \u0026lt;PublicationTimestamp\u0026gt;2019-06-12T09:30:47.0Z\u0026lt;/PublicationTimestamp\u0026gt; \u0026lt;ParticipantRef\u0026gt;AURIGE001\u0026lt;/ParticipantRef\u0026gt; \u0026lt;!-- ========== DONNEES =========== --\u0026gt; \u0026lt;dataObjects\u0026gt; \u0026lt;!-- =========================================== --\u0026gt; \u0026lt;!-- CompositeFrame.de type NETEX_FRANCE --\u0026gt; \u0026lt;CompositeFrame version=\u0026#34;1\u0026#34; created=\u0026#34;2019-06-12T09:30:47.0Z\u0026#34; id=\u0026#34;AURIGE:CompositeFrame:myFrame01:LOC\u0026#34;\u0026gt; \u0026lt;frames\u0026gt; \u0026lt;!-- =========================================== --\u0026gt; \u0026lt;!-- Frame NETEX_TARIF --\u0026gt; \u0026lt;GeneralFrame version=\u0026#34;001\u0026#34; id=\u0026#34;AURIGE:TypeOfFrame:NETEX_TARIF-Example1:LOC\u0026#34;\u0026gt; \u0026lt;TypeOfFrameRef ref=\u0026#34;FR:TypeOfFrame:NETEX_TARIF\u0026#34;\u0026gt;version=\u0026#34;1.01:FR-NETEX_TARIF-1.0\u0026#34;\u0026lt;/TypeOfFrameRef\u0026gt; \u0026lt;members modificationSet=\u0026#34;all\u0026#34;\u0026gt; \u0026lt;!-- =============================================================================== --\u0026gt; \u0026lt;!-- STRUCTURE TARIFAIRE ET DROITS DE BASE --\u0026gt; \u0026lt;TimeInterval id=\u0026#34;FR-Tarif-Example:TimeInterval:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Description\u0026gt;1h30 de validit\u0026amp;#xE9; pour bus et TRam\u0026lt;/Description\u0026gt; \u0026lt;Duration\u0026gt;PT90M\u0026lt;/Duration\u0026gt; \u0026lt;timeStructureFactors\u0026gt; \u0026lt;TimeStructureFactor\u0026gt; \u0026lt;Name\u0026gt;Entre premi\u0026amp;#xE8;re et derni\u0026amp;#xE8;re validation\u0026lt;/Name\u0026gt; \u0026lt;!--A présenter pour l\u0026#39;IV--\u0026gt; \u0026lt;Description\u0026gt;Time Structure Factor pour \u0026#34;entre premi\u0026amp;#xE8;re et derni\u0026amp;#xE8;re validation\u0026#34;\u0026lt;/Description\u0026gt; \u0026lt;TypeOfFareStructureFactorRef ref=\u0026#34;BetweenFirstAndLastValidation\u0026#34;/\u0026gt; \u0026lt;/TimeStructureFactor\u0026gt; \u0026lt;/timeStructureFactors\u0026gt; \u0026lt;/TimeInterval\u0026gt; \u0026lt;ValidableElement id=\u0026#34;FR-Tarif-Example:ValidableElement:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;noticeAssignments\u0026gt; \u0026lt;NoticeAssignment\u0026gt; \u0026lt;NoticeRef ref=\u0026#34;FR-Tarif-Example:Notice:001:LOC\u0026#34;/\u0026gt; \u0026lt;/NoticeAssignment\u0026gt; \u0026lt;/noticeAssignments\u0026gt; \u0026lt;fareStructureElements\u0026gt; \u0026lt;FareStructureElementRef ref=\u0026#34;FR-Tarif-Example:FareStructureElement:001:LOC\u0026#34;/\u0026gt; \u0026lt;/fareStructureElements\u0026gt; \u0026lt;!-- Moved to Fare Product \u0026lt;validityParameterAssignments\u0026gt; \u0026lt;GenericParameterAssignment\u0026gt; \u0026lt;LimitationGroupingType\u0026gt;AND\u0026lt;/LimitationGroupingType\u0026gt; \u0026lt;limitations\u0026gt; \u0026lt;RoundTripRef ref=\u0026#34;FR-Tarif-Example:RoundTrip:001:LOC\u0026#34;/\u0026gt; \u0026lt;ExchangingRef ref=\u0026#34;FR-Tarif-Example:Exchanging:001:LOC\u0026#34;/\u0026gt; \u0026lt;RefundingRef ref=\u0026#34;FR-Tarif-Example:Refunding:001:LOC\u0026#34;/\u0026gt; \u0026lt;/limitations\u0026gt; \u0026lt;validityParameters\u0026gt; \u0026lt;VehicleModes\u0026gt;tram bus\u0026lt;/VehicleModes\u0026gt; \u0026lt;/validityParameters\u0026gt; \u0026lt;IncludesGroupingType\u0026gt;AND\u0026lt;/IncludesGroupingType\u0026gt; \u0026lt;includes\u0026gt; \u0026lt;GenericParameterAssignment\u0026gt; \u0026lt;Description\u0026gt;Voir http://www.navigo.fr/wp-content/uploads/2016/06/lignes_tarification_speciale_07-2014.pdf pour les lignes à tarification spéciale\u0026lt;/Description\u0026gt; \u0026lt;IsAllowed\u0026gt;false\u0026lt;/IsAllowed\u0026gt; \u0026lt;validityParameters\u0026gt; \u0026lt;LineRef ref=\u0026#34;FR-Tarif-Example:Line:Orlybus:LOC\u0026#34;/\u0026gt; \u0026lt;LineRef ref=\u0026#34;FR-Tarif-Example:Line:Tram11:LOC\u0026#34;/\u0026gt; \u0026lt;LineRef ref=\u0026#34;FR-Tarif-Example:Line:RAPT350:LOC\u0026#34;/\u0026gt; \u0026lt;LineRef ref=\u0026#34;FR-Tarif-Example:Line:RAPT351:LOC\u0026#34;/\u0026gt; \u0026lt;GroupOfLinesRef ref=\u0026#34;FR-Tarif-Example:GroupOfLines:Noctilien:LOC\u0026#34;/\u0026gt; \u0026lt;/validityParameters\u0026gt; \u0026lt;/GenericParameterAssignment\u0026gt; \u0026lt;/includes\u0026gt; \u0026lt;/GenericParameterAssignment\u0026gt; \u0026lt;/validityParameterAssignments\u0026gt;--\u0026gt; \u0026lt;/ValidableElement\u0026gt; \u0026lt;FareStructureElement id=\u0026#34;FR-Tarif-Example:FareStructureElement:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;TimeIntervalRef ref=\u0026#34;FR-Tarif-Example:TimeInterval:001:LOC\u0026#34;/\u0026gt; \u0026lt;!-- \u0026lt;GenericParameterAssignment\u0026gt; \u0026lt;/GenericParameterAssignment\u0026gt; --\u0026gt; \u0026lt;/FareStructureElement\u0026gt; \u0026lt;Notice id=\u0026#34;FR-Tarif-Example:Notice:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Ticket Validation Notice\u0026lt;/Name\u0026gt; \u0026lt;Text\u0026gt;\u0026amp;#xC0; chaque entr\u0026amp;#xE9;e ou changement de bus ou de tramway, vous devez valider \u0026amp;#xE0; nouveau votre ticket T+\u0026lt;/Text\u0026gt; \u0026lt;CanBeAdvertised\u0026gt;true\u0026lt;/CanBeAdvertised\u0026gt; \u0026lt;/Notice\u0026gt; \u0026lt;!-- =============================================================================== --\u0026gt; \u0026lt;!-- LE TITRE --\u0026gt; \u0026lt;PreassignedFareProduct id=\u0026#34;FR-Tarif-Example:PreassignedFareProduct:T+BusTram-001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Ticket T+ Bus-Tram\u0026lt;/Name\u0026gt; \u0026lt;AuthorityRef ref=\u0026#34;FR-Tarif-Example:Authority:IDFM:\u0026#34;/\u0026gt; \u0026lt;ConditionSummary\u0026gt; \u0026lt;TariffBasis\u0026gt;period\u0026lt;/TariffBasis\u0026gt; \u0026lt;CanBreakJourney\u0026gt;false\u0026lt;/CanBreakJourney\u0026gt; \u0026lt;IsRefundable\u0026gt;false\u0026lt;/IsRefundable\u0026gt; \u0026lt;IsExchangable\u0026gt;false\u0026lt;/IsExchangable\u0026gt; \u0026lt;/ConditionSummary\u0026gt; \u0026lt;validityParameterAssignments\u0026gt; \u0026lt;GenericParameterAssignment\u0026gt; \u0026lt;LimitationGroupingType\u0026gt;AND\u0026lt;/LimitationGroupingType\u0026gt; \u0026lt;limitations\u0026gt; \u0026lt;RoundTripRef ref=\u0026#34;FR-Tarif-Example:RoundTrip:001:LOC\u0026#34;/\u0026gt; \u0026lt;ExchangingRef ref=\u0026#34;FR-Tarif-Example:Exchanging:001:LOC\u0026#34;/\u0026gt; \u0026lt;RefundingRef ref=\u0026#34;FR-Tarif-Example:Refunding:001:LOC\u0026#34;/\u0026gt; \u0026lt;/limitations\u0026gt; \u0026lt;validityParameters\u0026gt; \u0026lt;VehicleModes\u0026gt;tram bus\u0026lt;/VehicleModes\u0026gt; \u0026lt;/validityParameters\u0026gt; \u0026lt;IncludesGroupingType\u0026gt;AND\u0026lt;/IncludesGroupingType\u0026gt; \u0026lt;includes\u0026gt; \u0026lt;GenericParameterAssignment\u0026gt; \u0026lt;Description\u0026gt;Voir http://www.navigo.fr/wp-content/uploads/2016/06/lignes_tarification_speciale_07-2014.pdf pour les lignes \u0026amp;#xE0; tarification sp\u0026amp;#xE9;ciale\u0026lt;/Description\u0026gt; \u0026lt;IsAllowed\u0026gt;false\u0026lt;/IsAllowed\u0026gt; \u0026lt;validityParameters\u0026gt; \u0026lt;LineRef ref=\u0026#34;FR-Tarif-Example:Line:Orlybus:LOC\u0026#34;/\u0026gt; \u0026lt;LineRef ref=\u0026#34;FR-Tarif-Example:Line:Tram11:LOC\u0026#34;/\u0026gt; \u0026lt;LineRef ref=\u0026#34;FR-Tarif-Example:Line:RAPT350:LOC\u0026#34;/\u0026gt; \u0026lt;LineRef ref=\u0026#34;FR-Tarif-Example:Line:RAPT351:LOC\u0026#34;/\u0026gt; \u0026lt;GroupOfLinesRef ref=\u0026#34;FR-Tarif-Example:GroupOfLines:Noctilien:LOC\u0026#34;/\u0026gt; \u0026lt;/validityParameters\u0026gt; \u0026lt;/GenericParameterAssignment\u0026gt; \u0026lt;/includes\u0026gt; \u0026lt;/GenericParameterAssignment\u0026gt; \u0026lt;/validityParameterAssignments\u0026gt; \u0026lt;validableElements\u0026gt; \u0026lt;ValidableElementRef ref=\u0026#34;FR-Tarif-Example:ValidableElement:001:LOC\u0026#34;/\u0026gt; \u0026lt;/validableElements\u0026gt; \u0026lt;ProductType\u0026gt;singleTrip\u0026lt;/ProductType\u0026gt; \u0026lt;/PreassignedFareProduct\u0026gt; \u0026lt;RoundTrip id=\u0026#34;FR-Tarif-Example:RoundTrip:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;TripType\u0026gt;single\u0026lt;/TripType\u0026gt; \u0026lt;/RoundTrip\u0026gt; \u0026lt;Exchanging id=\u0026#34;FR-Tarif-Example:Exchanging:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Description\u0026gt;Echang\u0026amp;#xE9; seulement si d\u0026amp;#xE9;fectueux\u0026lt;/Description\u0026gt; \u0026lt;Allowed\u0026gt;none\u0026lt;/Allowed\u0026gt; \u0026lt;/Exchanging\u0026gt; \u0026lt;Refunding id=\u0026#34;FR-Tarif-Example:Refunding:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Allowed\u0026gt;none\u0026lt;/Allowed\u0026gt; \u0026lt;/Refunding\u0026gt; \u0026lt;!-- ======================================================== --\u0026gt; \u0026lt;SalesOfferPackageElement id=\u0026#34;FR-Tarif-Example:SalesOfferPackageElement:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;RequiresValidation\u0026gt;true\u0026lt;/RequiresValidation\u0026gt; \u0026lt;!-- \u0026lt;ConditionSummary\u0026gt; Deplacer vers le FARE PRODUCT (decision du 28/01) \u0026lt;TariffBasis\u0026gt;period\u0026lt;/TariffBasis\u0026gt; \u0026lt;CanBreakJourney\u0026gt;false\u0026lt;/CanBreakJourney\u0026gt; \u0026lt;IsRefundable\u0026gt;false\u0026lt;/IsRefundable\u0026gt; \u0026lt;IsExchangable\u0026gt;false\u0026lt;/IsExchangable\u0026gt; \u0026lt;/ConditionSummary\u0026gt;--\u0026gt; \u0026lt;TypeOfTravelDocumentRef ref=\u0026#34;FR-Tarif-Example:TypeOfTravelDocument:001:LOC\u0026#34;/\u0026gt; \u0026lt;PreassignedFareProductRef ref=\u0026#34;FR-Tarif-Example:PreassignedFareProduct:T+001:LOC\u0026#34;/\u0026gt; \u0026lt;/SalesOfferPackageElement\u0026gt; \u0026lt;TypeOfTravelDocument id=\u0026#34;FR-Tarif-Example:TypeOfTravelDocument:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Ticket T+ carton a bande magn\u0026amp;#xE9;tique\u0026lt;/Name\u0026gt; \u0026lt;Url\u0026gt;http://www.navigo.fr/wp-content/uploads/2018/11/127099_Ticket-T_carnet-de-10300x136.png\u0026lt;/Url\u0026gt; \u0026lt;MediaType\u0026gt;paperTicket\u0026lt;/MediaType\u0026gt; \u0026lt;MachineReadable\u0026gt;magneticStrip\u0026lt;/MachineReadable\u0026gt; \u0026lt;/TypeOfTravelDocument\u0026gt; \u0026lt;SalesOfferPackage id=\u0026#34;FR-Tarif-Example:SalesOfferPackage:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Ticket \u0026amp;#xE0; l\u0026#39;unit\u0026amp;#xE9;\u0026lt;/Name\u0026gt; \u0026lt;prices\u0026gt; \u0026lt;SalesOfferPackagePrice\u0026gt; \u0026lt;Amount\u0026gt;1.90\u0026lt;/Amount\u0026gt; \u0026lt;Currency\u0026gt;EUR\u0026lt;/Currency\u0026gt; \u0026lt;/SalesOfferPackagePrice\u0026gt; \u0026lt;/prices\u0026gt; \u0026lt;salesOfferPackageElements\u0026gt; \u0026lt;SalesOfferPackageElementRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackageElement:001:LOC\u0026#34;/\u0026gt; \u0026lt;/salesOfferPackageElements\u0026gt; \u0026lt;/SalesOfferPackage\u0026gt; \u0026lt;SalesOfferPackage id=\u0026#34;FR-Tarif-Example:SalesOfferPackage:002:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Carnet de 10 Ticket\u0026lt;/Name\u0026gt; \u0026lt;validityParameterAssignments\u0026gt; \u0026lt;GenericParameterAssignment\u0026gt; \u0026lt;limitations\u0026gt; \u0026lt;UsageValidityPeriod\u0026gt; \u0026lt;ValidityPeriodType\u0026gt;carnet\u0026lt;/ValidityPeriodType\u0026gt; \u0026lt;/UsageValidityPeriod\u0026gt; \u0026lt;/limitations\u0026gt; \u0026lt;/GenericParameterAssignment\u0026gt; \u0026lt;/validityParameterAssignments\u0026gt; \u0026lt;prices\u0026gt; \u0026lt;SalesOfferPackagePrice\u0026gt; \u0026lt;Amount\u0026gt;14.90\u0026lt;/Amount\u0026gt; \u0026lt;Currency\u0026gt;EUR\u0026lt;/Currency\u0026gt; \u0026lt;/SalesOfferPackagePrice\u0026gt; \u0026lt;/prices\u0026gt; \u0026lt;salesOfferPackageElements\u0026gt; \u0026lt;SalesOfferPackageElementRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackageElement:001:LOC\u0026#34;/\u0026gt; \u0026lt;SalesOfferPackageElementRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackageElement:001:LOC\u0026#34;/\u0026gt; \u0026lt;SalesOfferPackageElementRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackageElement:001:LOC\u0026#34;/\u0026gt; \u0026lt;SalesOfferPackageElementRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackageElement:001:LOC\u0026#34;/\u0026gt; \u0026lt;SalesOfferPackageElementRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackageElement:001:LOC\u0026#34;/\u0026gt; \u0026lt;SalesOfferPackageElementRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackageElement:001:LOC\u0026#34;/\u0026gt; \u0026lt;SalesOfferPackageElementRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackageElement:001:LOC\u0026#34;/\u0026gt; \u0026lt;SalesOfferPackageElementRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackageElement:001:LOC\u0026#34;/\u0026gt; \u0026lt;SalesOfferPackageElementRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackageElement:001:LOC\u0026#34;/\u0026gt; \u0026lt;SalesOfferPackageElementRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackageElement:001:LOC\u0026#34;/\u0026gt; \u0026lt;/salesOfferPackageElements\u0026gt; \u0026lt;/SalesOfferPackage\u0026gt; \u0026lt;!-- =============================================================================== --\u0026gt; \u0026lt;!-- TARIF REDUIT --\u0026gt; \u0026lt;UserProfile id=\u0026#34;FR-Tarif-Example:UserProfile:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;!--Plein tarif classique--\u0026gt; \u0026lt;Name\u0026gt;Plein tarif\u0026lt;/Name\u0026gt; \u0026lt;Description\u0026gt;Plein tarif adulte sans r\u0026amp;#xE9;duction\u0026lt;/Description\u0026gt; \u0026lt;MinimumAge\u0026gt;10\u0026lt;/MinimumAge\u0026gt; \u0026lt;/UserProfile\u0026gt; \u0026lt;UserProfile id=\u0026#34;FR-Tarif-Example:UserProfile:002:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;!--Gratuit pour les enfants--\u0026gt; \u0026lt;Name\u0026gt;Moins de 4 ans\u0026lt;/Name\u0026gt; \u0026lt;Description\u0026gt;Gratuit pour les enfants de moins de 4 ans\u0026lt;/Description\u0026gt; \u0026lt;MaximumAge\u0026gt;4\u0026lt;/MaximumAge\u0026gt; \u0026lt;DiscountBasis\u0026gt;free\u0026lt;/DiscountBasis\u0026gt; \u0026lt;/UserProfile\u0026gt; \u0026lt;UserProfile id=\u0026#34;FR-Tarif-Example:UserProfile:003:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;!--50% pour les enfants entre 4 et 10 ans --\u0026gt; \u0026lt;Name\u0026gt;Tarif Enfant\u0026lt;/Name\u0026gt; \u0026lt;Description\u0026gt;50%de r\u0026amp;#xE9;duction pour les enfants entre 4 et 10 ans \u0026lt;/Description\u0026gt; \u0026lt;prices\u0026gt; \u0026lt;UsageParameterPrice\u0026gt; \u0026lt;LimitingRule\u0026gt; \u0026lt;DiscountAsPercentage\u0026gt;0.50\u0026lt;/DiscountAsPercentage\u0026gt; \u0026lt;CanBeCumulative\u0026gt;false\u0026lt;/CanBeCumulative\u0026gt; \u0026lt;/LimitingRule\u0026gt; \u0026lt;/UsageParameterPrice\u0026gt; \u0026lt;/prices\u0026gt; \u0026lt;MinimumAge\u0026gt;4\u0026lt;/MinimumAge\u0026gt; \u0026lt;MaximumAge\u0026gt;10\u0026lt;/MaximumAge\u0026gt; \u0026lt;DiscountBasis\u0026gt;discount\u0026lt;/DiscountBasis\u0026gt; \u0026lt;/UserProfile\u0026gt; \u0026lt;EntitlementRequired id=\u0026#34;FR-Tarif-Example:EntitlementRequired:004:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;!--50% carte famille nombreuse --\u0026gt; \u0026lt;Name\u0026gt;Carte Famille Nombreuse SNCF\u0026lt;/Name\u0026gt; \u0026lt;Description\u0026gt;50% de r\u0026amp;#xE9;duction aus titulaires d\u0026amp;#x2019;une carte \u0026#34;Famille nombreuse\u0026#34; de couleur bleue d\u0026amp;#xE9;livr\u0026amp;#xE9;e par la SNCF (enfant de \u0026amp;#x2013; de 18 ans, contrairement \u0026amp;#xE0; la carte rouge \u0026amp;#x2026;) \u0026lt;/Description\u0026gt; \u0026lt;!-- \u0026lt;prices\u0026gt; Déplacé vers le UserProfile correspondant (décision du 28/01/2020 \u0026lt;UsageParameterPrice\u0026gt; \u0026lt;DiscountingRule\u0026gt; \u0026lt;DiscountAsPercentage\u0026gt;0.5\u0026lt;/DiscountAsPercentage\u0026gt; \u0026lt;/DiscountingRule\u0026gt; \u0026lt;/UsageParameterPrice\u0026gt; \u0026lt;/prices\u0026gt;--\u0026gt; \u0026lt;EntitlementProductRef ref=\u0026#34;FR-Tarif-Example:EntitlementProduct:001:LOC\u0026#34;/\u0026gt; \u0026lt;/EntitlementRequired\u0026gt; \u0026lt;EntitlementProduct id=\u0026#34;FR-Tarif-Example:EntitlementProduct:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;carte famille nombreuse SNCF bleue \u0026lt;/Name\u0026gt; \u0026lt;Description\u0026gt;carte \u0026#34;Famille nombreuse\u0026#34; de couleur bleue d\u0026amp;#xE9;livr\u0026amp;#xE9;e par la SNCF (enfant de \u0026amp;#x2013; de 18 ans, contrairement \u0026amp;#xE0; la carte rouge \u0026amp;#x2026;)\u0026lt;/Description\u0026gt; \u0026lt;InfoUrl\u0026gt;https://www.service-public.fr/particuliers/vosdroits/F15292\u0026lt;/InfoUrl\u0026gt; \u0026lt;documentLinks\u0026gt; \u0026lt;InfoLink\u0026gt;https%3A%2F%2Fwww.legifrance.gouv.fr%2Ftelecharger_rtf.do%3FidTexte%3DLEGITEXT000006063361%26dateTexte%3D20190617\u0026lt;/InfoLink\u0026gt; \u0026lt;/documentLinks\u0026gt; \u0026lt;GeneralOrganisationRef ref=\u0026#34;FR-Tarif-Example:OperatorRef:SNCF:\u0026#34;/\u0026gt; \u0026lt;/EntitlementProduct\u0026gt; \u0026lt;UserProfile id=\u0026#34;FR-Tarif-Example:UserProfile:004:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;!-- User Profile pour les titulaire de carter Famille Nombreuse --\u0026gt; \u0026lt;Name\u0026gt;Titulaire de carte famille nombreuse SNCF bleue\u0026lt;/Name\u0026gt; \u0026lt;Description\u0026gt;50%de r\u0026amp;#xE9;duction\u0026lt;/Description\u0026gt; \u0026lt;TypeOfUsageParameterRef ref=\u0026#34;FR-Tarif-Example:EntitlementRequired:004:LOC\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;prices\u0026gt; \u0026lt;UsageParameterPrice\u0026gt; \u0026lt;LimitingRule\u0026gt; \u0026lt;DiscountAsPercentage\u0026gt;0.50\u0026lt;/DiscountAsPercentage\u0026gt; \u0026lt;CanBeCumulative\u0026gt;false\u0026lt;/CanBeCumulative\u0026gt; \u0026lt;/LimitingRule\u0026gt; \u0026lt;/UsageParameterPrice\u0026gt; \u0026lt;/prices\u0026gt; \u0026lt;DiscountBasis\u0026gt;discount\u0026lt;/DiscountBasis\u0026gt; \u0026lt;/UserProfile\u0026gt; \u0026lt;!-- =============================================================================== --\u0026gt; \u0026lt;!-- POINTS DE VENTE --\u0026gt; \u0026lt;DistributionChannel id=\u0026#34;FR-Tarif-Example:DistributionChannel:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Points de vente RATP\u0026lt;/Name\u0026gt; \u0026lt;Description\u0026gt;Vente de ticket dans tous les points de vente RATP\u0026lt;/Description\u0026gt; \u0026lt;DistributionChannelType\u0026gt;agency\u0026lt;/DistributionChannelType\u0026gt; \u0026lt;OrganisationRef ref=\u0026#34;FR-Tarif-Example:Organisation:RATP:\u0026#34;/\u0026gt; \u0026lt;distributionPoints\u0026gt; \u0026lt;PointRef ref=\u0026#34;etc.\u0026#34;/\u0026gt; \u0026lt;PointRef ref=\u0026#34;etc.\u0026#34;/\u0026gt; \u0026lt;/distributionPoints\u0026gt; \u0026lt;/DistributionChannel\u0026gt; \u0026lt;GroupOfDistributionChannels id=\u0026#34;FR-Tarif-Example:GroupOfDistributionChannels:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Tous les points de vente du Ticket T+\u0026lt;/Name\u0026gt; \u0026lt;members\u0026gt; \u0026lt;DistributionChannelRef ref=\u0026#34;FR-Tarif-Example:DistributionChannel:001:LOC\u0026#34;/\u0026gt; \u0026lt;!--Etc.--\u0026gt; \u0026lt;/members\u0026gt; \u0026lt;/GroupOfDistributionChannels\u0026gt; \u0026lt;DistributionAssignment\u0026gt; \u0026lt;SalesOfferPackageRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackage:001:LOC\u0026#34;/\u0026gt; \u0026lt;!--Ticket T+ plein tarif à l\u0026#39;unité--\u0026gt; \u0026lt;GroupOfDistributionChannelsRef ref=\u0026#34;FR-Tarif-Example:GroupOfDistributionChannels:001:LOC\u0026#34;/\u0026gt; \u0026lt;/DistributionAssignment\u0026gt; \u0026lt;!-- =============================================================================== --\u0026gt; \u0026lt;!-- FARE TABLE avec affectation des prix --\u0026gt; \u0026lt;!-- Pour chaque cellule: Prix / UserProfile ou Entitlement / SalesOfferPackage (le lien avec les FareProduct est fait par le SalesOfferPackage) --\u0026gt; \u0026lt;FareTable version=\u0026#34;any\u0026#34; id=\u0026#34;lFR-Tarif-Example:TickeT+FareTable:001:LOC\u0026#34;\u0026gt; \u0026lt;Name\u0026gt; Bus Fare Prices - 18+Student \u0026lt;/Name\u0026gt; \u0026lt;cells\u0026gt; \u0026lt;Cell version=\u0026#34;any\u0026#34; id=\u0026#34;lFR-Tarif-Example:Cell:001:LOC\u0026#34;\u0026gt; \u0026lt;SalesOfferPackagePrice\u0026gt; \u0026lt;Name\u0026gt;Ticket a l\u0026#39;unit\u0026amp;#xE9; plein tarif\u0026lt;/Name\u0026gt; \u0026lt;Amount\u0026gt;1.90\u0026lt;/Amount\u0026gt; \u0026lt;/SalesOfferPackagePrice\u0026gt; \u0026lt;UserProfileRef version=\u0026#34;any\u0026#34; ref=\u0026#34;FR-Tarif-Example:UserProfile:001:LOC\u0026#34;/\u0026gt; \u0026lt;SalesOfferPackageRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackage:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;/Cell\u0026gt; \u0026lt;Cell version=\u0026#34;any\u0026#34; id=\u0026#34;lFR-Tarif-Example:Cell:002:LOC\u0026#34;\u0026gt; \u0026lt;SalesOfferPackagePrice\u0026gt; \u0026lt;Name\u0026gt;Gratuit pour les enfants\u0026lt;/Name\u0026gt; \u0026lt;Amount\u0026gt;0.00\u0026lt;/Amount\u0026gt; \u0026lt;/SalesOfferPackagePrice\u0026gt; \u0026lt;UserProfileRef version=\u0026#34;any\u0026#34; ref=\u0026#34;FR-Tarif-Example:UserProfile:002:LOC\u0026#34;/\u0026gt; \u0026lt;!--Gratuit pour les enfants--\u0026gt; \u0026lt;SalesOfferPackageRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackage:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;/Cell\u0026gt; \u0026lt;Cell version=\u0026#34;any\u0026#34; id=\u0026#34;lFR-Tarif-Example:Cell:003:LOC\u0026#34;\u0026gt; \u0026lt;SalesOfferPackagePrice\u0026gt; \u0026lt;Name\u0026gt;50% pour les enfants entre 4 et 10 ans\u0026lt;/Name\u0026gt; \u0026lt;Amount\u0026gt;0.80\u0026lt;/Amount\u0026gt; \u0026lt;/SalesOfferPackagePrice\u0026gt; \u0026lt;UserProfileRef version=\u0026#34;any\u0026#34; ref=\u0026#34;FR-Tarif-Example:UserProfile:003:LOC\u0026#34;/\u0026gt; \u0026lt;!--50% pour les enfants entre 4 et 10 ans --\u0026gt; \u0026lt;SalesOfferPackageRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackage:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;/Cell\u0026gt; \u0026lt;Cell version=\u0026#34;any\u0026#34; id=\u0026#34;lFR-Tarif-Example:Cell:004:LOC\u0026#34;\u0026gt; \u0026lt;SalesOfferPackagePrice\u0026gt; \u0026lt;Name\u0026gt;Carnet de 10 Tickets plein tarif\u0026lt;/Name\u0026gt; \u0026lt;Amount\u0026gt;14.90\u0026lt;/Amount\u0026gt; \u0026lt;/SalesOfferPackagePrice\u0026gt; \u0026lt;UserProfileRef version=\u0026#34;any\u0026#34; ref=\u0026#34;FR-Tarif-Example:UserProfile:001:LOC\u0026#34;/\u0026gt; \u0026lt;SalesOfferPackageRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackage:002:LOC\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;/Cell\u0026gt; \u0026lt;Cell version=\u0026#34;any\u0026#34; id=\u0026#34;lFR-Tarif-Example:Cell:005:LOC\u0026#34;\u0026gt; \u0026lt;SalesOfferPackagePrice\u0026gt; \u0026lt;Name\u0026gt;Carnet de 10 Tickets plein tarif famille nombreuse\u0026lt;/Name\u0026gt; \u0026lt;Amount\u0026gt;7.45\u0026lt;/Amount\u0026gt; \u0026lt;/SalesOfferPackagePrice\u0026gt; \u0026lt;EntitlementRequiredRef ref=\u0026#34;FR-Tarif-Example:EntitlementRequired:004:LOC\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;!--EntitlementRequired au lieur de UserProfile --\u0026gt; \u0026lt;SalesOfferPackageRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackage:002:LOC\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;/Cell\u0026gt; \u0026lt;!-- etc. --\u0026gt; \u0026lt;/cells\u0026gt; \u0026lt;/FareTable\u0026gt; \u0026lt;!-- =============================================================================== --\u0026gt; \u0026lt;/members\u0026gt; \u0026lt;/GeneralFrame\u0026gt; \u0026lt;/frames\u0026gt; \u0026lt;/CompositeFrame\u0026gt; \u0026lt;/dataObjects\u0026gt; \u0026lt;/PublicationDelivery\u0026gt; TGV Paris-Lille \u0026lt;?xml version=\u0026#34;1.0\u0026#34;?\u0026gt; \u0026lt;PublicationDelivery xmlns=\u0026#34;http://www.netex.org.uk/netex\u0026#34; xmlns:xsi=\u0026#34;http://www.w3.org/2001/XMLSchemainstance\u0026#34; xsi:schemaLocation=\u0026#34;http://www.netex.org.uk/netex ./xsd/NeTEx_publication-NoConstraint.xsd\u0026#34; version=\u0026#34;1.1\u0026#34;\u0026gt; \u0026lt;!--- =============== ENTETE =========== --\u0026gt; \u0026lt;PublicationTimestamp\u0026gt;2019-06-12T09:30:47.0Z\u0026lt;/PublicationTimestamp\u0026gt; \u0026lt;ParticipantRef\u0026gt;AURIGE001\u0026lt;/ParticipantRef\u0026gt; \u0026lt;!-- ========== DONNEES =========== --\u0026gt; \u0026lt;dataObjects\u0026gt; \u0026lt;!-- =========================================== --\u0026gt; \u0026lt;!-- CompositeFrame.de type NETEX_FRANCE --\u0026gt; \u0026lt;CompositeFrame version=\u0026#34;1\u0026#34; created=\u0026#34;2019-06-12T09:30:47.0Z\u0026#34; id=\u0026#34;AURIGE:CompositeFrame:myFrame01:LOC\u0026#34;\u0026gt; \u0026lt;frames\u0026gt; \u0026lt;!-- =========================================== --\u0026gt; \u0026lt;!-- Frame NETEX_TARIF --\u0026gt; \u0026lt;GeneralFrame version=\u0026#34;001\u0026#34; id=\u0026#34;AURIGE:TypeOfFrame:NETEX_TARIF-Example1:LOC\u0026#34;\u0026gt; \u0026lt;TypeOfFrameRef ref=\u0026#34;FR:TypeOfFrame:NETEX_TARIF\u0026#34;\u0026gt;version=\u0026#34;1.01:FR-NETEX_TARIF-1.0\u0026#34;\u0026lt;/TypeOfFrameRef\u0026gt; \u0026lt;members modificationSet=\u0026#34;all\u0026#34;\u0026gt; \u0026lt;!-- =============================================================================== --\u0026gt; \u0026lt;!-- STRUCTURE TARIFAIRE ET DROITS DE BASE --\u0026gt; \u0026lt;DistanceMatrixElement id=\u0026#34;FR-Tarif-Example:DistanceMatrixElement:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;IsDirect\u0026gt;true\u0026lt;/IsDirect\u0026gt; \u0026lt;InverseAllowed\u0026gt;false\u0026lt;/InverseAllowed\u0026gt; \u0026lt;StartStopPointRef versionRef=\u0026#34;any\u0026#34; ref=\u0026#34;SNCF:ScheduledStopPoint:ParisGareduNord87271007:LOC\u0026#34;/\u0026gt; \u0026lt;EndStopPointRef versionRef=\u0026#34;any\u0026#34; ref=\u0026#34;SNCF:ScheduledStopPoint:LilleFlandre-87 286 005:LOC\u0026#34;/\u0026gt; \u0026lt;!--Note On pourrait insérer ici une CONTRAINTE de SERIE si plusieurs itinéraires étaient concernés--\u0026gt; \u0026lt;!-- \u0026lt;seriesConstraints\u0026gt; \u0026lt;SeriesConstraint id=\u0026#34;SNCF:SeriesConstraint:Paris-Lille\u0026#34; order=\u0026#34;1\u0026#34; version=\u0026#34;1.0\u0026#34;\u0026gt; \u0026lt;Itinerary\u0026gt;Paris * Lille\u0026lt;/Itinerary\u0026gt; \u0026lt;SeriesType\u0026gt;stationToStation\u0026lt;/SeriesType\u0026gt; \u0026lt;FirstClassDistance\u0026gt;19\u0026lt;/FirstClassDistance\u0026gt; --\u0026gt; \u0026lt;!-- et on peut en profiter pour ajouter une distance tarifaire --\u0026gt; \u0026lt;!-- \u0026lt;SecondClassDistance\u0026gt;20\u0026lt;/SecondClassDistance\u0026gt; \u0026lt;journeyPatterns\u0026gt; \u0026lt;JourneyPatternRef ref=\u0026#34;SNCF:JourneyPattern:0001:LOC\u0026#34;\u0026gt;\u0026lt;/JourneyPatternRef\u0026gt; --\u0026gt; \u0026lt;!--Peut passer par des JP, mais ausi par des points ... ou des correspondances--\u0026gt; \u0026lt;!-- \u0026lt;JourneyPatternRef ref=\u0026#34;SNCF:JourneyPattern:0002:LOC\u0026#34;\u0026gt;\u0026lt;/JourneyPatternRef\u0026gt; \u0026lt;/journeyPatterns\u0026gt; \u0026lt;/SeriesConstraint\u0026gt; \u0026lt;/seriesConstraints\u0026gt;--\u0026gt; \u0026lt;/DistanceMatrixElement\u0026gt; \u0026lt;FareStructureElement id=\u0026#34;FR-Tarif-Example:FareStructureElement:002:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;DistanceMatrixElementRef ref=\u0026#34;FR-Tarif-Example:DistanceMatrixElement:001:LOC\u0026#34;/\u0026gt; \u0026lt;!-- \u0026lt;GenericParameterAssignment\u0026gt; \u0026lt;/GenericParameterAssignment\u0026gt; --\u0026gt; \u0026lt;/FareStructureElement\u0026gt; \u0026lt;ValidableElement id=\u0026#34;FR-Tarif-Example:ValidableElement:002:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;fareStructureElements\u0026gt; \u0026lt;FareStructureElementRef ref=\u0026#34;FR-Tarif-Example:FareStructureElement:002:LOC\u0026#34;/\u0026gt; \u0026lt;/fareStructureElements\u0026gt; \u0026lt;validityParameterAssignments\u0026gt; \u0026lt;GenericParameterAssignment\u0026gt; \u0026lt;validityParameters\u0026gt; \u0026lt;!-- \u0026lt;ServiceJourneyPatternRef ref=\u0026#34;xxxxx\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; On peut préciser la ServiceJourneyPattern en plus du numéro de Train --\u0026gt; \u0026lt;!-- \u0026lt;TrainNumberRef ref=\u0026#34;7057\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; --\u0026gt; \u0026lt;!--Affectation du numéro de train à l\u0026#39;OD--\u0026gt; \u0026lt;!-- NON car ça limiterais à un horaire et calendrier associé --\u0026gt; \u0026lt;/validityParameters\u0026gt; \u0026lt;/GenericParameterAssignment\u0026gt; \u0026lt;/validityParameterAssignments\u0026gt; \u0026lt;/ValidableElement\u0026gt; \u0026lt;!-- =============================================================================== --\u0026gt; \u0026lt;Notice id=\u0026#34;FR-Tarif-Example:Notice:002:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;!--POUR L\u0026#39;EXEMPLE--\u0026gt; \u0026lt;Name\u0026gt;Conditions de transport\u0026lt;/Name\u0026gt; \u0026lt;Text\u0026gt;Les conditions g\u0026amp;#xE9;n\u0026amp;#xE9;rale de transport sont disponibles en ligne sur https://medias.sncf.com/sncfcom/pdf/tarif-voyageurs/Tarifs-voyageurs_CGV.pdf\u0026lt;/Text\u0026gt; \u0026lt;CanBeAdvertised\u0026gt;true\u0026lt;/CanBeAdvertised\u0026gt; \u0026lt;/Notice\u0026gt; \u0026lt;!--SECONDE Billet échangeable et remboursable avec retenue de 5 € à compter de 30 jours avant le départ, portée à 15 € l\u0026#39;avant-veille jusqu\u0026#39;au jour du départ. À partir de 30 minutes avant départ du train, billet échangeable 2 fois maximum uniquement pour le même jour et le même trajet et non remboursable après échange. A la retenue s\u0026#39;ajoute l\u0026#39;éventuelle différence de prix entre l\u0026#39;ancien et le nouveau billet. Billet non échangeable et non remboursable après le départ.--\u0026gt; \u0026lt;Exchanging id=\u0026#34;FR-Tarif-Example:Exchanging:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Description\u0026gt;Billet \u0026amp;#xE9;changeable gratuitement jusqu\u0026#39;\u0026amp;#xE0; 30 jours avant le d\u0026amp;#xE9;part. S\u0026#39;ajoute l\u0026#39;\u0026amp;#xE9;ventuelle diff\u0026amp;#xE9;rence de prix entre l\u0026#39;ancien et le nouveau billet\u0026lt;/Description\u0026gt; \u0026lt;Allowed\u0026gt;full\u0026lt;/Allowed\u0026gt; \u0026lt;ResellWhen\u0026gt;beforeStartOfValidity\u0026lt;/ResellWhen\u0026gt; \u0026lt;ExchangableUntilDuration\u0026gt;-P30D\u0026lt;/ExchangableUntilDuration\u0026gt; \u0026lt;HasFee\u0026gt;false\u0026lt;/HasFee\u0026gt; \u0026lt;RefundBasis\u0026gt;perPerson\u0026lt;/RefundBasis\u0026gt; \u0026lt;!--A vérifier--\u0026gt; \u0026lt;/Exchanging\u0026gt; \u0026lt;Exchanging id=\u0026#34;FR-Tarif-Example:Exchanging:002:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Description\u0026gt;Billet \u0026amp;#xE9;changeable avec retenue de 5 \u0026amp;#x20AC; \u0026amp;#xE0; compter de 30 jours avant le d\u0026amp;#xE9;part. A la retenue s\u0026#39;ajoute l\u0026#39;\u0026amp;#xE9;ventuelle diff\u0026amp;#xE9;rence de prix entre l\u0026#39;ancien et le nouveau billet\u0026lt;/Description\u0026gt; \u0026lt;prices\u0026gt; \u0026lt;UsageParameterPrice\u0026gt; \u0026lt;Amount\u0026gt;5\u0026lt;/Amount\u0026gt; \u0026lt;Currency\u0026gt;EUR\u0026lt;/Currency\u0026gt; \u0026lt;/UsageParameterPrice\u0026gt; \u0026lt;/prices\u0026gt; \u0026lt;Allowed\u0026gt;full\u0026lt;/Allowed\u0026gt; \u0026lt;ResellWhen\u0026gt;beforeStartOfValidity\u0026lt;/ResellWhen\u0026gt; \u0026lt;ExchangableFromDuration\u0026gt;-P30D\u0026lt;/ExchangableFromDuration\u0026gt; \u0026lt;ExchangableUntilDuration\u0026gt;-P2D\u0026lt;/ExchangableUntilDuration\u0026gt; \u0026lt;HasFee\u0026gt;true\u0026lt;/HasFee\u0026gt; \u0026lt;RefundBasis\u0026gt;perPerson\u0026lt;/RefundBasis\u0026gt; \u0026lt;!--A vérifier--\u0026gt; \u0026lt;/Exchanging\u0026gt; \u0026lt;Exchanging id=\u0026#34;FR-Tarif-Example:Exchanging:003:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Description\u0026gt;Billet \u0026amp;#xE9;changeable avec retenue de 15 \u0026amp;#x20AC; de l\u0026#39;avant-veille jusqu\u0026#39;au jour du d\u0026amp;#xE9;part. A la retenue s\u0026#39;ajoute l\u0026#39;\u0026amp;#xE9;ventuelle diff\u0026amp;#xE9;rence de prix entre l\u0026#39;ancien et le nouveau billet\u0026lt;/Description\u0026gt; \u0026lt;prices\u0026gt; \u0026lt;UsageParameterPrice\u0026gt; \u0026lt;Amount\u0026gt;15\u0026lt;/Amount\u0026gt; \u0026lt;Currency\u0026gt;EUR\u0026lt;/Currency\u0026gt; \u0026lt;/UsageParameterPrice\u0026gt; \u0026lt;/prices\u0026gt; \u0026lt;Allowed\u0026gt;full\u0026lt;/Allowed\u0026gt; \u0026lt;ResellWhen\u0026gt;beforeStartOfValidity\u0026lt;/ResellWhen\u0026gt; \u0026lt;ExchangableFromDuration\u0026gt;-P2D\u0026lt;/ExchangableFromDuration\u0026gt; \u0026lt;ExchangableUntilDuration\u0026gt;-PT30M\u0026lt;/ExchangableUntilDuration\u0026gt; \u0026lt;HasFee\u0026gt;true\u0026lt;/HasFee\u0026gt; \u0026lt;RefundBasis\u0026gt;perPerson\u0026lt;/RefundBasis\u0026gt; \u0026lt;!--A vérifier--\u0026gt; \u0026lt;/Exchanging\u0026gt; \u0026lt;Exchanging id=\u0026#34;FR-Tarif-Example:Exchanging:004:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Description\u0026gt;\u0026amp;#xC0; partir de 30 minutes avant d\u0026amp;#xE9;part du train, billet \u0026amp;#xE9;changeable 2 fois maximum uniquement pour le m\u0026amp;#xEA;me jour et le m\u0026amp;#xEA;me trajet et non remboursable apr\u0026amp;#xE8;s \u0026amp;#xE9;change.A la retenue de 15\u0026amp;#x20AC; s\u0026#39;ajoute l\u0026#39;\u0026amp;#xE9;ventuelle diff\u0026amp;#xE9;rence de prix entre l\u0026#39;ancien et le nouveau billet\u0026lt;/Description\u0026gt; \u0026lt;prices\u0026gt; \u0026lt;UsageParameterPrice\u0026gt; \u0026lt;Amount\u0026gt;15\u0026lt;/Amount\u0026gt; \u0026lt;Currency\u0026gt;EUR\u0026lt;/Currency\u0026gt; \u0026lt;/UsageParameterPrice\u0026gt; \u0026lt;/prices\u0026gt; \u0026lt;Allowed\u0026gt;full\u0026lt;/Allowed\u0026gt; \u0026lt;ResellWhen\u0026gt;beforeStartOfValidity\u0026lt;/ResellWhen\u0026gt; \u0026lt;ExchangableFromDuration\u0026gt;-PT30M\u0026lt;/ExchangableFromDuration\u0026gt; \u0026lt;HasFee\u0026gt;true\u0026lt;/HasFee\u0026gt; \u0026lt;RefundBasis\u0026gt;perPerson\u0026lt;/RefundBasis\u0026gt; \u0026lt;!--A vérifier--\u0026gt; \u0026lt;NumberOfExchangesAllowed\u0026gt;2\u0026lt;/NumberOfExchangesAllowed\u0026gt; \u0026lt;ExchangableTo\u0026gt;sameProductSameDay\u0026lt;/ExchangableTo\u0026gt; \u0026lt;/Exchanging\u0026gt; \u0026lt;!-- ========= Rembouresements --\u0026gt; \u0026lt;Refunding id=\u0026#34;FR-Tarif-Example:Refunding:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Description\u0026gt;Billet Remboursable gratuitement jusqu\u0026#39;\u0026amp;#xE0; 30 jours avant le d\u0026amp;#xE9;part.\u0026lt;/Description\u0026gt; \u0026lt;Allowed\u0026gt;full\u0026lt;/Allowed\u0026gt; \u0026lt;ResellWhen\u0026gt;beforeStartOfValidity\u0026lt;/ResellWhen\u0026gt; \u0026lt;ExchangableUntilDuration\u0026gt;-P30D\u0026lt;/ExchangableUntilDuration\u0026gt; \u0026lt;HasFee\u0026gt;false\u0026lt;/HasFee\u0026gt; \u0026lt;RefundBasis\u0026gt;perPerson\u0026lt;/RefundBasis\u0026gt; \u0026lt;!--A vérifier--\u0026gt; \u0026lt;/Refunding\u0026gt; \u0026lt;Refunding id=\u0026#34;FR-Tarif-Example:Refunding:002:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Description\u0026gt;Billet Remboursable avec retenue de 5 \u0026amp;#x20AC; \u0026amp;#xE0; compter de 30 jours avant le d\u0026amp;#xE9;part.\u0026lt;/Description\u0026gt; \u0026lt;prices\u0026gt; \u0026lt;UsageParameterPrice\u0026gt; \u0026lt;Amount\u0026gt;5\u0026lt;/Amount\u0026gt; \u0026lt;Currency\u0026gt;EUR\u0026lt;/Currency\u0026gt; \u0026lt;/UsageParameterPrice\u0026gt; \u0026lt;/prices\u0026gt; \u0026lt;Allowed\u0026gt;full\u0026lt;/Allowed\u0026gt; \u0026lt;ResellWhen\u0026gt;beforeStartOfValidity\u0026lt;/ResellWhen\u0026gt; \u0026lt;ExchangableFromDuration\u0026gt;-P30D\u0026lt;/ExchangableFromDuration\u0026gt; \u0026lt;ExchangableUntilDuration\u0026gt;-P2D\u0026lt;/ExchangableUntilDuration\u0026gt; \u0026lt;HasFee\u0026gt;true\u0026lt;/HasFee\u0026gt; \u0026lt;RefundBasis\u0026gt;perPerson\u0026lt;/RefundBasis\u0026gt; \u0026lt;!--A vérifier--\u0026gt; \u0026lt;/Refunding\u0026gt; \u0026lt;Refunding id=\u0026#34;FR-Tarif-Example:Refunding:003:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Description\u0026gt;Billet Remboursable avec retenue de 15 \u0026amp;#x20AC; de l\u0026#39;avant-veille jusqu\u0026#39;au jour du d\u0026amp;#xE9;part.\u0026lt;/Description\u0026gt; \u0026lt;prices\u0026gt; \u0026lt;UsageParameterPrice\u0026gt; \u0026lt;Amount\u0026gt;15\u0026lt;/Amount\u0026gt; \u0026lt;Currency\u0026gt;EUR\u0026lt;/Currency\u0026gt; \u0026lt;/UsageParameterPrice\u0026gt; \u0026lt;/prices\u0026gt; \u0026lt;Allowed\u0026gt;full\u0026lt;/Allowed\u0026gt; \u0026lt;ResellWhen\u0026gt;beforeStartOfValidity\u0026lt;/ResellWhen\u0026gt; \u0026lt;ExchangableFromDuration\u0026gt;-P2D\u0026lt;/ExchangableFromDuration\u0026gt; \u0026lt;ExchangableUntilDuration\u0026gt;-PT30M\u0026lt;/ExchangableUntilDuration\u0026gt; \u0026lt;HasFee\u0026gt;true\u0026lt;/HasFee\u0026gt; \u0026lt;RefundBasis\u0026gt;perPerson\u0026lt;/RefundBasis\u0026gt; \u0026lt;!--A vérifier--\u0026gt; \u0026lt;/Refunding\u0026gt; \u0026lt;Reserving id=\u0026#34;FR-Tarif-Example:Reserving:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Description\u0026gt;R\u0026amp;#xE9;servation incluse avec le titre de transport. Possibilit\u0026amp;#xE9; de choix du type de placement\u0026lt;/Description\u0026gt; \u0026lt;ReservingRequirements\u0026gt;reservationsCompulsory\u0026lt;/ReservingRequirements\u0026gt; \u0026lt;SeatAllocationMethod\u0026gt;autoAssigned\u0026lt;/SeatAllocationMethod\u0026gt; \u0026lt;/Reserving\u0026gt; \u0026lt;!-- =============================================================================== --\u0026gt; \u0026lt;!-- LE TITRE --\u0026gt; \u0026lt;PreassignedFareProduct id=\u0026#34;FR-Tarif-Example:PreassignedFareProduct:Paris-Lille-001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Paris-Lille\u0026lt;/Name\u0026gt; \u0026lt;!--NOTE : OU \u0026#34;billet OD TGV\u0026#34; SI ON FAIT DE LA MUTUALISATION--\u0026gt; \u0026lt;noticeAssignments\u0026gt; \u0026lt;NoticeAssignment\u0026gt; \u0026lt;NoticeRef ref=\u0026#34;FR-Tarif-Example:Notice:002:LOC\u0026#34;/\u0026gt; \u0026lt;/NoticeAssignment\u0026gt; \u0026lt;/noticeAssignments\u0026gt; \u0026lt;ChargingMomentType\u0026gt;beforeTravel\u0026lt;/ChargingMomentType\u0026gt; \u0026lt;OperatorRef ref=\u0026#34;FR-Tarif-Example:Authority:SNCF:\u0026#34;/\u0026gt; \u0026lt;ConditionSummary\u0026gt; \u0026lt;FareStructureType\u0026gt;pointToPointFare\u0026lt;/FareStructureType\u0026gt; \u0026lt;!-- \u0026lt;IsPersonal\u0026gt;true\u0026lt;/IsPersonal\u0026gt; déplacé sur le SalesOfferPackageElement =\u0026gt; il faudra dire ce que l\u0026#39;on met sur le FP et ce qui va sur le Package--\u0026gt; \u0026lt;TrainRestrictions\u0026gt;specifiedTrainOnly\u0026lt;/TrainRestrictions\u0026gt; \u0026lt;CanBreakJourney\u0026gt;false\u0026lt;/CanBreakJourney\u0026gt; \u0026lt;IsRefundable\u0026gt;false\u0026lt;/IsRefundable\u0026gt; \u0026lt;IsExchangable\u0026gt;false\u0026lt;/IsExchangable\u0026gt; \u0026lt;HasExchangeFee\u0026gt;true\u0026lt;/HasExchangeFee\u0026gt; \u0026lt;HasDynamicPricing\u0026gt;true\u0026lt;/HasDynamicPricing\u0026gt; \u0026lt;!--YIELD MANANGED--\u0026gt; \u0026lt;RequiresReservation\u0026gt;true\u0026lt;/RequiresReservation\u0026gt; \u0026lt;!--inclue dans le titre--\u0026gt; \u0026lt;HasReservationFee\u0026gt;false\u0026lt;/HasReservationFee\u0026gt; \u0026lt;/ConditionSummary\u0026gt; \u0026lt;validityParameterAssignments\u0026gt; \u0026lt;GenericParameterAssignment\u0026gt; \u0026lt;LimitationGroupingType\u0026gt;AND\u0026lt;/LimitationGroupingType\u0026gt; \u0026lt;limitations\u0026gt; \u0026lt;ReservingRef ref=\u0026#34;FR-Tarif-Example:Reserving:001:LOC\u0026#34;/\u0026gt; \u0026lt;ExchangingRef ref=\u0026#34;FR-Tarif-Example:Exchanging:001:LOC\u0026#34;/\u0026gt; \u0026lt;ExchangingRef ref=\u0026#34;FR-Tarif-Example:Exchanging:002:LOC\u0026#34;/\u0026gt; \u0026lt;ExchangingRef ref=\u0026#34;FR-Tarif-Example:Exchanging:003:LOC\u0026#34;/\u0026gt; \u0026lt;ExchangingRef ref=\u0026#34;FR-Tarif-Example:Exchanging:004:LOC\u0026#34;/\u0026gt; \u0026lt;RefundingRef ref=\u0026#34;FR-Tarif-Example:Refunding:001:LOC\u0026#34;/\u0026gt; \u0026lt;RefundingRef ref=\u0026#34;FR-Tarif-Example:Refunding:002:LOC\u0026#34;/\u0026gt; \u0026lt;RefundingRef ref=\u0026#34;FR-Tarif-Example:Refunding:003:LOC\u0026#34;/\u0026gt; \u0026lt;/limitations\u0026gt; \u0026lt;validityParameters\u0026gt; \u0026lt;VehicleModes\u0026gt;rail\u0026lt;/VehicleModes\u0026gt; \u0026lt;/validityParameters\u0026gt; \u0026lt;/GenericParameterAssignment\u0026gt; \u0026lt;/validityParameterAssignments\u0026gt; \u0026lt;validableElements\u0026gt; \u0026lt;ValidableElementRef ref=\u0026#34;FR-Tarif-Example:ValidableElement:002:LOC\u0026#34;/\u0026gt; \u0026lt;!--etc. VOIR NOTE SUR ProductType --\u0026gt; \u0026lt;!--NOTE: On peut aussi définit le VE ici plutôt que de le référencer--\u0026gt; \u0026lt;/validableElements\u0026gt; \u0026lt;!-- Possible option pour VE1 ou VE2 ... NON RETENU EN PREMIERE APPROCHE ... Voir choix du ProductType --\u0026gt; \u0026lt;!-- \u0026lt;accessRightsInProduct\u0026gt; \u0026lt;AccessRightInProduct\u0026gt; \u0026lt;IsFirstInSequence\u0026gt;true\u0026lt;/IsFirstInSequence\u0026gt; \u0026lt;ValidableElementRef ref=\u0026#34;FR-Tarif-Example:ValidableElement:002:LOC\u0026#34;/\u0026gt; \u0026lt;/AccessRightInProduct\u0026gt; \u0026lt;AccessRightInProduct\u0026gt; \u0026lt;IsFirstInSequence\u0026gt;true\u0026lt;/IsFirstInSequence\u0026gt; \u0026lt;ValidableElementRef ref=\u0026#34;FR-Tarif-Example:ValidableElement:002:LOC\u0026#34;/\u0026gt; \u0026lt;/AccessRightInProduct\u0026gt; --\u0026gt; \u0026lt;!--etc.--\u0026gt; \u0026lt;!-- \u0026lt;/accessRightsInProduct\u0026gt;--\u0026gt; \u0026lt;ProductType\u0026gt;singleTrip\u0026lt;/ProductType\u0026gt; \u0026lt;!--NOTE IMPORTANTE: si le produit est \u0026#34;single trip\u0026#34; alors un seul de ValidableElement est utilisable, même s\u0026#39;il y a plusieurs VE: cela permet de gérer les cas ou un produit donne accès à une droit A OU B OU C .... On pourra aussi utliser ce mécanisme pour faire un unique produit O-D, contenant de très nombreuses O-D, mais avec une seule tarification comme dans le cas du Yield Management ...--\u0026gt; \u0026lt;/PreassignedFareProduct\u0026gt; \u0026lt;!--l\u0026#39;Indication \u0026#34;Espace Famille pourra se faire par un FamilyServices dans les FacilitySet associé à la course ou au Service Pattern--\u0026gt; \u0026lt;!-- =============================================================================== --\u0026gt; \u0026lt;!-- LE PACKAGE ... A FINALISER --\u0026gt; \u0026lt;SalesOfferPackageElement id=\u0026#34;FR-Tarif-Example:SalesOfferPackageElement:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;RequiresValidation\u0026gt;false\u0026lt;/RequiresValidation\u0026gt; \u0026lt;ConditionSummary\u0026gt; \u0026lt;!--A ARTICULER AVEC LA PARTIE DANS LE FARE PRODUCT--\u0026gt; \u0026lt;IsPersonal\u0026gt;true\u0026lt;/IsPersonal\u0026gt; \u0026lt;HasQuota\u0026gt;false\u0026lt;/HasQuota\u0026gt; \u0026lt;!--le \u0026#34;HasQuota\u0026#34; peut être utilisé pour, par exemple proposer un nombre de titre limité à tarif réduit ... pour être aussi restreint par une période d\u0026#39;achat--\u0026gt; \u0026lt;/ConditionSummary\u0026gt; \u0026lt;TypeOfTravelDocumentRef ref=\u0026#34;FR-Tarif-Example:TypeOfTravelDocument:001:LOC\u0026#34;/\u0026gt; \u0026lt;PreassignedFareProductRef ref=\u0026#34;FR-Tarif-Example:PreassignedFareProduct:Paris-Lille001:LOC\u0026#34;/\u0026gt; \u0026lt;/SalesOfferPackageElement\u0026gt; \u0026lt;TypeOfTravelDocument id=\u0026#34;FR-Tarif-Example:TypeOfTravelDocument:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;E-Billet\u0026lt;/Name\u0026gt; \u0026lt;Description\u0026gt;Billet \u0026amp;#xE9;lectronique \u0026amp;#xE0; Flashcode, imprim\u0026amp;#xE9; sur papier ou viualis\u0026amp;#xE9; sur terminal \u0026amp;#xE9;lectronique (smartphone)\u0026lt;/Description\u0026gt; \u0026lt;Url\u0026gt;https://www.oui.sncf/aide/le-e-billet\u0026lt;/Url\u0026gt; \u0026lt;MediaType\u0026gt;other\u0026lt;/MediaType\u0026gt; \u0026lt;!--\u0026#34;Other\u0026#34; car il n\u0026#39;y a pas qu\u0026#39;un unique support physique ... on pourrait aussi ne pas faire figurer cet élément--\u0026gt; \u0026lt;MachineReadable\u0026gt;barCode\u0026lt;/MachineReadable\u0026gt; \u0026lt;/TypeOfTravelDocument\u0026gt; \u0026lt;SalesOfferPackage id=\u0026#34;FR-Tarif-Example:SalesOfferPackage:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Billet Origine-Destination (Paris-Lille) avec r\u0026amp;#xE9;servation\u0026lt;/Name\u0026gt; \u0026lt;salesOfferPackageElements\u0026gt; \u0026lt;SalesOfferPackageElementRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackageElement:001:LOC\u0026#34;/\u0026gt; \u0026lt;/salesOfferPackageElements\u0026gt; \u0026lt;/SalesOfferPackage\u0026gt; \u0026lt;!-- =============================================================================== --\u0026gt; \u0026lt;!-- POINTS DE VENTE A FINALISER pour titre papier au guichet --\u0026gt; \u0026lt;DistributionChannel id=\u0026#34;FR-Tarif-Example:DistributionChannel:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Points de vente SNCF\u0026lt;/Name\u0026gt; \u0026lt;Description\u0026gt;Vente de ticket dans tous les points de vente SNCF\u0026lt;/Description\u0026gt; \u0026lt;DistributionChannelType\u0026gt;agency\u0026lt;/DistributionChannelType\u0026gt; \u0026lt;OrganisationRef ref=\u0026#34;FR-Tarif-Example:Organisation:SNCF:\u0026#34;/\u0026gt; \u0026lt;distributionPoints\u0026gt; \u0026lt;PointRef ref=\u0026#34;etc.\u0026#34;/\u0026gt; \u0026lt;PointRef ref=\u0026#34;etc.\u0026#34;/\u0026gt; \u0026lt;/distributionPoints\u0026gt; \u0026lt;/DistributionChannel\u0026gt; \u0026lt;DistributionChannel id=\u0026#34;FR-Tarif-Example:DistributionChannel:002:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Oui SNCF\u0026lt;/Name\u0026gt; \u0026lt;Description\u0026gt;Vente de ticket sur le site officiel SNCF\u0026lt;/Description\u0026gt; \u0026lt;DistributionChannelType\u0026gt;online\u0026lt;/DistributionChannelType\u0026gt; \u0026lt;ContactDetails\u0026gt; \u0026lt;Url\u0026gt;https://www.oui.sncf/\u0026lt;/Url\u0026gt; \u0026lt;/ContactDetails\u0026gt; \u0026lt;OrganisationRef ref=\u0026#34;FR-Tarif-Example:Organisation:Oui-SNCF:\u0026#34;/\u0026gt; \u0026lt;/DistributionChannel\u0026gt; \u0026lt;DistributionChannel id=\u0026#34;FR-Tarif-Example:DistributionChannel:003:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Trainline\u0026lt;/Name\u0026gt; \u0026lt;Description\u0026gt;Vente de billets de 270 compagnies de train et de bus\u0026lt;/Description\u0026gt; \u0026lt;DistributionChannelType\u0026gt;online\u0026lt;/DistributionChannelType\u0026gt; \u0026lt;ContactDetails\u0026gt; \u0026lt;Url\u0026gt;https://www.trainline.fr/\u0026lt;/Url\u0026gt; \u0026lt;/ContactDetails\u0026gt; \u0026lt;OrganisationRef ref=\u0026#34;FR-Tarif-Example:Organisation:TrainLine:\u0026#34;/\u0026gt; \u0026lt;/DistributionChannel\u0026gt; \u0026lt;GroupOfDistributionChannels id=\u0026#34;FR-Tarif-Example:GroupOfDistributionChannels:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Tous les points de vente SNCF en ligne\u0026lt;/Name\u0026gt; \u0026lt;members\u0026gt; \u0026lt;DistributionChannelRef ref=\u0026#34;FR-Tarif-Example:DistributionChannel:002:LOC\u0026#34;/\u0026gt; \u0026lt;DistributionChannelRef ref=\u0026#34;FR-Tarif-Example:DistributionChannel:003:LOC\u0026#34;/\u0026gt; \u0026lt;!--Etc.--\u0026gt; \u0026lt;/members\u0026gt; \u0026lt;/GroupOfDistributionChannels\u0026gt; \u0026lt;DistributionAssignment\u0026gt; \u0026lt;SalesOfferPackageRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackage:001:LOC\u0026#34;/\u0026gt; \u0026lt;GroupOfDistributionChannelsRef ref=\u0026#34;FR-Tarif-Example:GroupOfDistributionChannels:001:LOC\u0026#34;/\u0026gt; \u0026lt;/DistributionAssignment\u0026gt; \u0026lt;!-- =============================================================================== --\u0026gt; \u0026lt;!-- TARIF REDUIT --\u0026gt; \u0026lt;UserProfile id=\u0026#34;FR-Tarif-Example:UserProfile:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;!--Plein tarif classique--\u0026gt; \u0026lt;Name\u0026gt;Plein tarif\u0026lt;/Name\u0026gt; \u0026lt;Description\u0026gt;Plein tarif adulte sans r\u0026amp;#xE9;duction\u0026lt;/Description\u0026gt; \u0026lt;MinimumAge\u0026gt;11\u0026lt;/MinimumAge\u0026gt; \u0026lt;/UserProfile\u0026gt; \u0026lt;UserProfile id=\u0026#34;FR-Tarif-Example:UserProfile:002:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;!--Gratuit pour les enfants--\u0026gt; \u0026lt;!-- Votre enfant de moins de 4 ans voyage gratuitement avec vous. Pour en bénéficier, cochez la case « place gratuite sur les genoux » lors de votre réservation.--\u0026gt; \u0026lt;Name\u0026gt;Moins de 4 ans\u0026lt;/Name\u0026gt; \u0026lt;Description\u0026gt;Gratuit pour les enfants de moins de 4 ans\u0026lt;/Description\u0026gt; \u0026lt;MaximumAge\u0026gt;4\u0026lt;/MaximumAge\u0026gt; \u0026lt;DiscountBasis\u0026gt;free\u0026lt;/DiscountBasis\u0026gt; \u0026lt;companionProfiles\u0026gt; \u0026lt;CompanionProfile version=\u0026#34;any\u0026#34; id=\u0026#34;FR-Tarif-Example:CompanionProfile:002:LOC\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;L\u0026#39;enfant doit avoir un adulte (payant) avec lui, et il n\u0026#39;a pas de si\u0026amp;#xE8;ge attribu\u0026amp;#xE9; (sur les genoux)\u0026lt;/Name\u0026gt; \u0026lt;UserProfileRef version=\u0026#34;any\u0026#34; ref=\u0026#34;FR-Tarif-Example:UserProfile:001:LOC\u0026#34;/\u0026gt; \u0026lt;MinimumNumberOfPersons\u0026gt;1\u0026lt;/MinimumNumberOfPersons\u0026gt; \u0026lt;/CompanionProfile\u0026gt; \u0026lt;/companionProfiles\u0026gt; \u0026lt;/UserProfile\u0026gt; \u0026lt;UserProfile id=\u0026#34;FR-Tarif-Example:UserProfile:002b:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;!--Gratuit pour les enfants--\u0026gt; \u0026lt;!-- forfait bambin à 9€ : profitez-en pour vos voyages à bord de TGV INOUI, TER et Intercités. Ce tarif réduit vous est proposé par défaut lors de votre réservation --\u0026gt; \u0026lt;Name\u0026gt;Moins de 4 ans\u0026lt;/Name\u0026gt; \u0026lt;Description\u0026gt;Gratuit pour les enfants de moins de 4 ans\u0026lt;/Description\u0026gt; \u0026lt;MaximumAge\u0026gt;4\u0026lt;/MaximumAge\u0026gt; \u0026lt;DiscountBasis\u0026gt;discount\u0026lt;/DiscountBasis\u0026gt; \u0026lt;companionProfiles\u0026gt; \u0026lt;CompanionProfile version=\u0026#34;any\u0026#34; id=\u0026#34;FR-Tarif-Example:CompanionProfile:002b:LOC\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;L\u0026#39;enfant doit avoir un adulte (payant) avec lui, et il dispose d\u0026#39;un si\u0026amp;#xE8;ge\u0026lt;/Name\u0026gt; \u0026lt;UserProfileRef version=\u0026#34;any\u0026#34; ref=\u0026#34;FR-Tarif-Example:UserProfile:001:LOC\u0026#34;/\u0026gt; \u0026lt;MinimumNumberOfPersons\u0026gt;1\u0026lt;/MinimumNumberOfPersons\u0026gt; \u0026lt;/CompanionProfile\u0026gt; \u0026lt;/companionProfiles\u0026gt; \u0026lt;/UserProfile\u0026gt; \u0026lt;UserProfile id=\u0026#34;FR-Tarif-Example:UserProfile:003:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;!-- A FINALISER pour le compagnon --\u0026gt; \u0026lt;!-- -60% pour les enfants de 4 à 11 ans inclus (jusqu’à 3 maximum) pour un voyage aller-retour incluant au moins un jour/une nuit de week-end sur place1 -30% pour un accompagnateur adulte pour un voyage aller-retour incluant au moins un jour/une nuit de week-end sur place1 --\u0026gt; \u0026lt;Name\u0026gt;Tarif Enfant\u0026lt;/Name\u0026gt; \u0026lt;Description\u0026gt;60%de r\u0026amp;#xE9;duction pour les enfants entre 4 et 10 ans \u0026lt;/Description\u0026gt; \u0026lt;prices\u0026gt; \u0026lt;UsageParameterPrice\u0026gt; \u0026lt;LimitingRule\u0026gt; \u0026lt;DiscountAsPercentage\u0026gt;0.40\u0026lt;/DiscountAsPercentage\u0026gt; \u0026lt;CanBeCumulative\u0026gt;false\u0026lt;/CanBeCumulative\u0026gt; \u0026lt;/LimitingRule\u0026gt; \u0026lt;/UsageParameterPrice\u0026gt; \u0026lt;/prices\u0026gt; \u0026lt;MinimumAge\u0026gt;4\u0026lt;/MinimumAge\u0026gt; \u0026lt;MaximumAge\u0026gt;11\u0026lt;/MaximumAge\u0026gt; \u0026lt;DiscountBasis\u0026gt;discount\u0026lt;/DiscountBasis\u0026gt; \u0026lt;/UserProfile\u0026gt; \u0026lt;EntitlementRequired id=\u0026#34;FR-Tarif-Example:EntitlementRequired:004:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;!--carte famille nombreuse 3 enfants=30 % 4 enfants=40 % 5 enfants=50 % 6 enfants ou plus= 75 % A COMPLETER--\u0026gt; \u0026lt;Name\u0026gt;Carte Famille Nombreuse SNCF\u0026lt;/Name\u0026gt; \u0026lt;Description\u0026gt;30% de r\u0026amp;#xE9;duction aus titulaires d\u0026amp;#x2019;une carte \u0026#34;Famille nombreuse\u0026#34;d\u0026amp;#xE9;livr\u0026amp;#xE9;e par la SNCF (3 enfants) \u0026lt;/Description\u0026gt; \u0026lt;EntitlementProductRef ref=\u0026#34;FR-Tarif-Example:EntitlementProduct:001:LOC\u0026#34;/\u0026gt; \u0026lt;/EntitlementRequired\u0026gt; \u0026lt;EntitlementProduct id=\u0026#34;FR-Tarif-Example:EntitlementProduct:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;carte famille nombreuse SNCF 30% \u0026lt;/Name\u0026gt; \u0026lt;Description\u0026gt;carte \u0026#34;Famille nombreuse\u0026#34; d\u0026amp;#xE9;livr\u0026amp;#xE9;e par la SNCF - 3 enfants \u0026lt;/Description\u0026gt; \u0026lt;InfoUrl\u0026gt;https://www.service-public.fr/particuliers/vosdroits/F15292\u0026lt;/InfoUrl\u0026gt; \u0026lt;documentLinks\u0026gt; \u0026lt;InfoLink\u0026gt;https%3A%2F%2Fwww.legifrance.gouv.fr%2Ftelecharger_rtf.do%3FidTexte%3DLEGITEXT000006063361%26dateTexte%3D20190617\u0026lt;/InfoLink\u0026gt; \u0026lt;/documentLinks\u0026gt; \u0026lt;GeneralOrganisationRef ref=\u0026#34;FR-Tarif-Example:OperatorRef:SNCF:\u0026#34;/\u0026gt; \u0026lt;/EntitlementProduct\u0026gt; \u0026lt;UserProfile id=\u0026#34;FR-Tarif-Example:UserProfile:004:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;!-- User Profile pour les titulaire de carter Famille Nombreuse --\u0026gt; \u0026lt;Name\u0026gt;Titulaire de carte famille nombreuse SNCF bleue\u0026lt;/Name\u0026gt; \u0026lt;Description\u0026gt;30%de r\u0026amp;#xE9;duction\u0026lt;/Description\u0026gt; \u0026lt;TypeOfUsageParameterRef ref=\u0026#34;FR-Tarif-Example:EntitlementRequired:004:LOC\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;prices\u0026gt; \u0026lt;UsageParameterPrice\u0026gt; \u0026lt;LimitingRule\u0026gt; \u0026lt;DiscountAsPercentage\u0026gt;0.70\u0026lt;/DiscountAsPercentage\u0026gt; \u0026lt;CanBeCumulative\u0026gt;false\u0026lt;/CanBeCumulative\u0026gt; \u0026lt;/LimitingRule\u0026gt; \u0026lt;/UsageParameterPrice\u0026gt; \u0026lt;/prices\u0026gt; \u0026lt;DiscountBasis\u0026gt;discount\u0026lt;/DiscountBasis\u0026gt; \u0026lt;/UserProfile\u0026gt; \u0026lt;!-- =============================================================================== --\u0026gt; \u0026lt;!-- PRICING SERVICE --\u0026gt; \u0026lt;PricingService version=\u0026#34;any\u0026#34; id=\u0026#34;FR-Tarif-Example:PricingService:001:LOC\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;SNCF online pricing sercice\u0026lt;/Name\u0026gt; \u0026lt;OrganisationRef ref=\u0026#34;FR-Tarif-Example:Organisation:SNCF:\u0026#34;/\u0026gt; \u0026lt;Url\u0026gt;https://www.oui.sncf/tgv-inoui/tarifs\u0026lt;/Url\u0026gt; \u0026lt;!--Voir quel lien mettre ... existe-t-il une API ?--\u0026gt; \u0026lt;/PricingService\u0026gt; \u0026lt;!-- =============================================================================== --\u0026gt; \u0026lt;!-- FARE TABLE avec tarif Yieldés ou fixes --\u0026gt; \u0026lt;!-- Pour chaque cellule: Prix / UserProfile ou Entitlement / SalesOfferPackage (le lien avec les FareProduct est fait par le SalesOfferPackage) --\u0026gt; \u0026lt;FareTable version=\u0026#34;any\u0026#34; id=\u0026#34;FR-Tarif-Example:TickeT+FareTable:001:LOC\u0026#34;\u0026gt; \u0026lt;Name\u0026gt; Tarif TGV Paris - Lille \u0026lt;/Name\u0026gt; \u0026lt;cells\u0026gt; \u0026lt;Cell version=\u0026#34;any\u0026#34; id=\u0026#34;FR-Tarif-Example:Cell:001:LOC\u0026#34;\u0026gt; \u0026lt;SalesOfferPackagePrice\u0026gt; \u0026lt;Name\u0026gt;Prix dynamique plein taif\u0026lt;/Name\u0026gt; \u0026lt;!--\u0026lt;Amount\u0026gt;00.00\u0026lt;/Amount\u0026gt; Possibilité de prix de référence même s\u0026#39;il y a un tarif \u0026#34;yieldé\u0026#34;--\u0026gt; \u0026lt;PricingServiceRef ref=\u0026#34;FR-Tarif-Example:PricingService:001:LOC\u0026#34;/\u0026gt; \u0026lt;!-- \u0026lt;LimitingRule\u0026gt; \u0026lt;MinimumPrice\u0026gt;0.1 \u0026lt;/MinimumPrice\u0026gt; \u0026lt;MaximumPrice\u0026gt;10000.00\u0026lt;/MaximumPrice\u0026gt; \u0026lt;/LimitingRule\u0026gt;--\u0026gt; \u0026lt;/SalesOfferPackagePrice\u0026gt; \u0026lt;UserProfileRef version=\u0026#34;any\u0026#34; ref=\u0026#34;FR-Tarif-Example:UserProfile:001:LOC\u0026#34;/\u0026gt; \u0026lt;SalesOfferPackageRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackage:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;/Cell\u0026gt; \u0026lt;Cell version=\u0026#34;any\u0026#34; id=\u0026#34;FR-Tarif-Example:Cell:002:LOC\u0026#34;\u0026gt; \u0026lt;SalesOfferPackagePrice\u0026gt; \u0026lt;Name\u0026gt;Gratuit pour les enfants de moins de 4 ans\u0026lt;/Name\u0026gt; \u0026lt;Amount\u0026gt;0.0\u0026lt;/Amount\u0026gt; \u0026lt;!--GRATUIT POUR LES ENFANT DE MOINS DE 4 ANS \u0026#34;SUR LES GENOUX\u0026#34;--\u0026gt; \u0026lt;/SalesOfferPackagePrice\u0026gt; \u0026lt;UserProfileRef version=\u0026#34;any\u0026#34; ref=\u0026#34;FR-Tarif-Example:UserProfile:002:LOC\u0026#34;/\u0026gt; \u0026lt;SalesOfferPackageRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackage:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;/Cell\u0026gt; \u0026lt;Cell version=\u0026#34;any\u0026#34; id=\u0026#34;FR-Tarif-Example:Cell:002b:LOC\u0026#34;\u0026gt; \u0026lt;SalesOfferPackagePrice\u0026gt; \u0026lt;Name\u0026gt;Tarif pour les enfants de moins de 4 ans sur un si\u0026amp;#xE8;ge\u0026lt;/Name\u0026gt; \u0026lt;Amount\u0026gt;9.0\u0026lt;/Amount\u0026gt; \u0026lt;!--9€ FIXE POUR LES ENFANT DE MOINS DE 4 ANS \u0026#34;SUR UN SIEGE\u0026#34;--\u0026gt; \u0026lt;/SalesOfferPackagePrice\u0026gt; \u0026lt;UserProfileRef version=\u0026#34;any\u0026#34; ref=\u0026#34;FR-Tarif-Example:UserProfile:002b:LOC\u0026#34;/\u0026gt; \u0026lt;SalesOfferPackageRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackage:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;/Cell\u0026gt; \u0026lt;Cell version=\u0026#34;any\u0026#34; id=\u0026#34;FR-Tarif-Example:Cell:003:LOC\u0026#34;\u0026gt; \u0026lt;SalesOfferPackagePrice\u0026gt; \u0026lt;Name\u0026gt;Prix dynamique pour le 4-11 ans\u0026lt;/Name\u0026gt; \u0026lt;PricingServiceRef ref=\u0026#34;FR-Tarif-Example:PricingService:001:LOC\u0026#34;/\u0026gt; \u0026lt;DiscountingRule\u0026gt; \u0026lt;DiscountAsPercentage\u0026gt;0.6\u0026lt;/DiscountAsPercentage\u0026gt; \u0026lt;/DiscountingRule\u0026gt; \u0026lt;/SalesOfferPackagePrice\u0026gt; \u0026lt;UserProfileRef version=\u0026#34;any\u0026#34; ref=\u0026#34;FR-Tarif-Example:UserProfile:003:LOC\u0026#34;/\u0026gt; \u0026lt;!-- LES ENFANT DE DE 4 A 11 ANS =\u0026gt; 60% de réduction--\u0026gt; \u0026lt;SalesOfferPackageRef ref=\u0026#34;FR-Tarif-Example:SalesOfferPackage:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;/Cell\u0026gt; \u0026lt;!-- etc. --\u0026gt; \u0026lt;!-- NOTE S\u0026#39;il n\u0026#39;y a pas re référence ou de min/max, il est peut intéressant de répéter cette ligne pour chaque OD possible .... On placera alors probablement toutes les OD dans une unique PreassignedFareProduct, typé \u0026#34;singleTrip\u0026#34; --\u0026gt; \u0026lt;/cells\u0026gt; \u0026lt;/FareTable\u0026gt; \u0026lt;!-- =============================================================================== --\u0026gt; \u0026lt;/members\u0026gt; \u0026lt;/GeneralFrame\u0026gt; \u0026lt;/frames\u0026gt; \u0026lt;/CompositeFrame\u0026gt; \u0026lt;/dataObjects\u0026gt; \u0026lt;/PublicationDelivery\u0026gt; Leman Express \u0026lt;?xml version=\u0026#34;1.0\u0026#34;?\u0026gt; \u0026lt;PublicationDelivery xmlns=\u0026#34;http://www.netex.org.uk/netex\u0026#34; xmlns:xsi=\u0026#34;http://www.w3.org/2001/XMLSchemainstance\u0026#34; xsi:schemaLocation=\u0026#34;http://www.netex.org.uk/netex ./xsd/NeTEx_publication.xsd\u0026#34; version=\u0026#34;1.1\u0026#34;\u0026gt; \u0026lt;!--- =============== ENTETE =========== --\u0026gt; \u0026lt;PublicationTimestamp\u0026gt;2019-06-12T09:30:47.0Z\u0026lt;/PublicationTimestamp\u0026gt; \u0026lt;ParticipantRef\u0026gt;AURIGE001\u0026lt;/ParticipantRef\u0026gt; \u0026lt;!-- ========== DONNEES =========== --\u0026gt; \u0026lt;dataObjects\u0026gt; \u0026lt;!-- =========================================== --\u0026gt; \u0026lt;!-- CompositeFrame.de type NETEX_FRANCE --\u0026gt; \u0026lt;CompositeFrame version=\u0026#34;1\u0026#34; created=\u0026#34;2019-06-12T09:30:47.0Z\u0026#34; id=\u0026#34;AURIGE:CompositeFrame:myFrame01:LOC\u0026#34;\u0026gt; \u0026lt;frames\u0026gt; \u0026lt;!-- =========================================== --\u0026gt; \u0026lt;!-- Frame NETEX_TARIF --\u0026gt; \u0026lt;GeneralFrame version=\u0026#34;001\u0026#34; id=\u0026#34;AURIGE:TypeOfFrame:NETEX_TARIF-Example1:LOC\u0026#34;\u0026gt; \u0026lt;TypeOfFrameRef ref=\u0026#34;FR:TypeOfFrame:NETEX_TARIF\u0026#34;\u0026gt;version=\u0026#34;1.01:FR-NETEX_TARIF1.0\u0026#34;\u0026lt;/TypeOfFrameRef\u0026gt; \u0026lt;members modificationSet=\u0026#34;all\u0026#34;\u0026gt; \u0026lt;!-- ============================================================================ --\u0026gt; \u0026lt;!-- STRUCTURE TARIFAIRE ET DROITS DE BASE --\u0026gt; \u0026lt;DistanceMatrixElement id=\u0026#34;LEMAN-EXPRESS:DistanceMatrixElement:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;!--Exemple d\u0026#39;OD Arrêt vers Zone --\u0026gt; \u0026lt;InverseAllowed\u0026gt;true\u0026lt;/InverseAllowed\u0026gt; \u0026lt;StartStopPointRef versionRef=\u0026#34;any\u0026#34; ref=\u0026#34;LEMAN-EXPRESS:ScheduledStopPoint:Chamb\u0026amp;#xE9;si-87271007:LOC\u0026#34;/\u0026gt; \u0026lt;EndTariffZoneRef versionRef=\u0026#34;any\u0026#34; ref=\u0026#34;LEMAN-EXPRES:TariffZone:Zone250:LOC\u0026#34;/\u0026gt; \u0026lt;/DistanceMatrixElement\u0026gt; \u0026lt;FareStructureElement id=\u0026#34;LEMAN-EXPRESS:FareStructureElement:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;DistanceMatrixElementRef ref=\u0026#34;FR-Tarif-Example:DistanceMatrixElement:001:LOC\u0026#34;/\u0026gt; \u0026lt;GenericParameterAssignment id=\u0026#34;LEMAN-EXPRESS:GenericParameterAssignment:001:LOC\u0026#34; version=\u0026#34;any\u0026#34; order=\u0026#34;1\u0026#34;\u0026gt; \u0026lt;limitations\u0026gt; \u0026lt;UsageValidityPeriod id=\u0026#34;LEMAN-EXPRESS:UsageValidityPeriod:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;!--Peut être une référence pour mutualiser la définition--\u0026gt; \u0026lt;UsageTrigger\u0026gt;purchase\u0026lt;/UsageTrigger\u0026gt; \u0026lt;!--On a aussi l\u0026#39;option startOutboundRide, etc.--\u0026gt; \u0026lt;StandardDuration\u0026gt;PT180M\u0026lt;/StandardDuration\u0026gt; \u0026lt;/UsageValidityPeriod\u0026gt; \u0026lt;/limitations\u0026gt; \u0026lt;/GenericParameterAssignment\u0026gt; \u0026lt;/FareStructureElement\u0026gt; \u0026lt;!-- ======================================================================== --\u0026gt; \u0026lt;!-- ETC. --\u0026gt; \u0026lt;/members\u0026gt; \u0026lt;/GeneralFrame\u0026gt; \u0026lt;/frames\u0026gt; \u0026lt;/CompositeFrame\u0026gt; \u0026lt;/dataObjects\u0026gt; \u0026lt;/PublicationDelivery\u0026gt; Tarif Kilométrique Ferré (TER) \u0026lt;?xml version=\u0026#34;1.0\u0026#34;?\u0026gt; \u0026lt;PublicationDelivery xmlns=\u0026#34;http://www.netex.org.uk/netex\u0026#34; xmlns:xsi=\u0026#34;http://www.w3.org/2001/XMLSchemainstance\u0026#34; xsi:schemaLocation=\u0026#34;http://www.netex.org.uk/netex ./NeTEx/xsd/NeTEx_publication-NoConstraint.xsd\u0026#34; version=\u0026#34;1.1\u0026#34;\u0026gt; \u0026lt;!-- Exemple de tarif Kilométrique TER sur la base des données de https://ressources.data.sncf.com/explore/dataset/bareme-de-prix-national-ter/table/?sort=-km ATTENTION: cet exemple explique comment représenter ce tableau Kilométrique, mais ne définit pas les produits tarifaire correspondant, ni les offres à la vente: ces éléments doivent être ajoutés et intégrés à la Fare Table! --\u0026gt; \u0026lt;!--- =============== ENTETE =========== --\u0026gt; \u0026lt;PublicationTimestamp\u0026gt;2019-06-12T09:30:47.0Z\u0026lt;/PublicationTimestamp\u0026gt; \u0026lt;ParticipantRef\u0026gt;AURIGE001\u0026lt;/ParticipantRef\u0026gt; \u0026lt;!-- ========== DONNEES =========== --\u0026gt; \u0026lt;dataObjects\u0026gt; \u0026lt;!-- =========================================== --\u0026gt; \u0026lt;!-- CompositeFrame.de type NETEX_FRANCE --\u0026gt; \u0026lt;CompositeFrame version=\u0026#34;1\u0026#34; created=\u0026#34;2019-06-12T09:30:47.0Z\u0026#34; id=\u0026#34;AURIGE:CompositeFrame:myFrame01:LOC\u0026#34;\u0026gt; \u0026lt;frames\u0026gt; \u0026lt;!-- =========================================== --\u0026gt; \u0026lt;!-- Frame NETEX_TARIF --\u0026gt; \u0026lt;GeneralFrame version=\u0026#34;001\u0026#34; id=\u0026#34;AURIGE:TypeOfFrame:NETEX_TARIF-Example1:LOC\u0026#34;\u0026gt; \u0026lt;TypeOfFrameRef ref=\u0026#34;FR:TypeOfFrame:NETEX_TARIF\u0026#34;\u0026gt;version=\u0026#34;1.01:FR-NETEX_TARIF1.0\u0026#34;\u0026lt;/TypeOfFrameRef\u0026gt; \u0026lt;members modificationSet=\u0026#34;all\u0026#34;\u0026gt; \u0026lt;!-- ======================================================================= --\u0026gt; \u0026lt;!-- STRUCTURE TARIFAIRE ET DROITS DE BASE --\u0026gt; \u0026lt;!-- ======== Représentation des éléments du tableau lui même --\u0026gt; \u0026lt;GeographicalUnit version=\u0026#34;any\u0026#34; id=\u0026#34;SNCF:GeographicalUnit:TER-Unit\u0026amp;#xE9;-de-distance:LOC\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Unit\u0026amp;#xE9; de distance arbitraire (peut-\u0026amp;#xEA;tre des kilom\u0026amp;#xE9;tre, ou une unit\u0026amp;#xE9; de distance tarifaire)\u0026lt;/Name\u0026gt; \u0026lt;/GeographicalUnit\u0026gt; \u0026lt;GeographicalInterval version=\u0026#34;001\u0026#34; id=\u0026#34;SNCF:GeographicalInterval:TER-1km:LOC\u0026#34;\u0026gt; \u0026lt;StartGeographicalValue\u0026gt;0.0\u0026lt;/StartGeographicalValue\u0026gt; \u0026lt;EndGeographicalValue\u0026gt;1.0\u0026lt;/EndGeographicalValue\u0026gt; \u0026lt;IntervalType\u0026gt;distance\u0026lt;/IntervalType\u0026gt; \u0026lt;!-- \u0026lt;GeographicalUnitRef version=\u0026#34;any\u0026#34; ref=\u0026#34;SNCF:GeographicalUnit:TER-Unité-de-distance:LOC\u0026#34;/\u0026gt; Facultatif, aussi fourni via le GeographicalStructureFactor --\u0026gt; \u0026lt;/GeographicalInterval\u0026gt; \u0026lt;!--etc...--\u0026gt; \u0026lt;GeographicalInterval version=\u0026#34;001\u0026#34; id=\u0026#34;SNCF:GeographicalInterval:TER-3km:LOC\u0026#34;\u0026gt; \u0026lt;StartGeographicalValue\u0026gt;1.0\u0026lt;/StartGeographicalValue\u0026gt; \u0026lt;EndGeographicalValue\u0026gt;2.0\u0026lt;/EndGeographicalValue\u0026gt; \u0026lt;IntervalType\u0026gt;distance\u0026lt;/IntervalType\u0026gt; \u0026lt;/GeographicalInterval\u0026gt; \u0026lt;!--etc...--\u0026gt; \u0026lt;!--Association Interval - Unités--\u0026gt; \u0026lt;GeographicalStructureFactor version=\u0026#34;001\u0026#34; id=\u0026#34;SNCF:GeographicalStructureFactor:AtoB:LOC\u0026#34;\u0026gt; \u0026lt;GeographicalIntervalRef version=\u0026#34;001\u0026#34; ref=\u0026#34;SNCF:GeographicalInterval:TER43km:LOC\u0026#34;/\u0026gt; \u0026lt;GeographicalUnitRef ref=\u0026#34;SNCF:GeographicalUnit:TER-Unit\u0026amp;#xE9;-de-distance:LOC\u0026#34;/\u0026gt; \u0026lt;/GeographicalStructureFactor\u0026gt; \u0026lt;!--etc...--\u0026gt; \u0026lt;!-- ========= Et les distances pour les origines / destination --\u0026gt; \u0026lt;DistanceMatrixElement id=\u0026#34;FR-Tarif-Example:DistanceMatrixElement:AtoB:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Distance\u0026gt;43\u0026lt;/Distance\u0026gt; \u0026lt;IsDirect\u0026gt;true\u0026lt;/IsDirect\u0026gt; \u0026lt;InverseAllowed\u0026gt;true\u0026lt;/InverseAllowed\u0026gt; \u0026lt;StartStopPointRef versionRef=\u0026#34;any\u0026#34; ref=\u0026#34;SNCF:ScheduledStopPoint:GareA:LOC\u0026#34;/\u0026gt; \u0026lt;EndStopPointRef versionRef=\u0026#34;any\u0026#34; ref=\u0026#34;SNCF:ScheduledStopPoint:GareB:LOC\u0026#34;/\u0026gt; \u0026lt;!--Note On pourrait insérer ici une CONTRAINTE de SERIE si plusieurs itinéraires étaient concernés si pluisieurs itinéraires sont possible --\u0026gt; \u0026lt;structureFactors\u0026gt; \u0026lt;GeographicalStructureFactorRef version=\u0026#34;001\u0026#34; ref=\u0026#34;SNCF:GeographicalInterval:TER-43km:LOC\u0026#34;/\u0026gt; \u0026lt;/structureFactors\u0026gt; \u0026lt;/DistanceMatrixElement\u0026gt; \u0026lt;!--etc...--\u0026gt; \u0026lt;!--LE FareStructureElement référence tous les DistanceMatrixElement ... Il sera lui même référencé par les PreassignedFareProduct-\u0026gt;ValidableElements--\u0026gt; \u0026lt;FareStructureElement id=\u0026#34;FR-Tarif-Example:FareStructureElement:DM-001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;distanceMatrixElements\u0026gt; \u0026lt;!--... QUESTION RECURENTE DU TRAITEMENT EN \u0026#34;OU\u0026#34; OU EN \u0026#34;ET\u0026#34; DE CES SEQUENCES (ici on cible OU) --\u0026gt; \u0026lt;DistanceMatrixElementRef ref=\u0026#34;FR-Tarif-Example:DistanceMatrixElement:AtoB:LOC\u0026#34;/\u0026gt; \u0026lt;DistanceMatrixElementRef ref=\u0026#34;FR-Tarif-Example:DistanceMatrixElement:AtoC:LOC\u0026#34;/\u0026gt; \u0026lt;DistanceMatrixElementRef ref=\u0026#34;FR-Tarif-Example:DistanceMatrixElement:BtoC:LOC\u0026#34;/\u0026gt; \u0026lt;!--etc...--\u0026gt; \u0026lt;/distanceMatrixElements\u0026gt; \u0026lt;/FareStructureElement\u0026gt; \u0026lt;!-- ======== Tableau tarifaire simplifié, pour l\u0026#39;exemple (sans les FareProduct et SalesOfferPackage) --\u0026gt; \u0026lt;!-- Cette table est purement un exemple ... on peut s\u0026#39;interroger sur le fait de donner le prix des GeographicalIntervalRef, qui implique un calcul ou directement celui du DistanceMatrixElement --\u0026gt; \u0026lt;!--ces limites nous permettent de ne mettre que le prix de la 1ere colonne du tableau (la limite s\u0026#39;appliquera opur les réductions)--\u0026gt; \u0026lt;LimitingRule version=\u0026#34;001\u0026#34; id=\u0026#34;SNCF:LimitingRule:001:LOC\u0026#34;\u0026gt; \u0026lt;MinimumPrice\u0026gt;1.8\u0026lt;/MinimumPrice\u0026gt; \u0026lt;/LimitingRule\u0026gt; \u0026lt;LimitingRule version=\u0026#34;001\u0026#34; id=\u0026#34;SNCF:LimitingRule:002:LOC\u0026#34;\u0026gt; \u0026lt;MinimumPrice\u0026gt;1.2\u0026lt;/MinimumPrice\u0026gt; \u0026lt;/LimitingRule\u0026gt; \u0026lt;FareTable id=\u0026#34;SNCF:StandardFareTable:TER-1km:LOC\u0026#34; version=\u0026#34;1.0\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;TER-Tarification kilom\u0026amp;#xE8;trique \u0026lt;/Name\u0026gt; \u0026lt;pricesFor\u0026gt; \u0026lt;FareStructureElementRef ref=\u0026#34;FR-Tarif-Example:FareStructureElement:DM001:LOC\u0026#34; version=\u0026#34;any\u0026#34;/\u0026gt; \u0026lt;!--a remplace par FareProduct et SalesOfferPackage en final--\u0026gt; \u0026lt;/pricesFor\u0026gt; \u0026lt;cells\u0026gt; \u0026lt;Cell\u0026gt; \u0026lt;CellPrice\u0026gt; \u0026lt;Amount\u0026gt;1.8\u0026lt;/Amount\u0026gt; \u0026lt;LimitingRuleRef ref=\u0026#34;SNCF:LimitingRule:001:LOC\u0026#34;/\u0026gt; \u0026lt;/CellPrice\u0026gt; \u0026lt;GeographicalIntervalRef ref=\u0026#34;SNCF:GeographicalInterval:TER1km:LOC\u0026#34;/\u0026gt; \u0026lt;FareClass\u0026gt;firstClass\u0026lt;/FareClass\u0026gt; \u0026lt;/Cell\u0026gt; \u0026lt;Cell\u0026gt; \u0026lt;CellPrice\u0026gt; \u0026lt;Amount\u0026gt;1.2\u0026lt;/Amount\u0026gt; \u0026lt;LimitingRuleRef ref=\u0026#34;SNCF:LimitingRule:001:LOC\u0026#34;/\u0026gt; \u0026lt;/CellPrice\u0026gt; \u0026lt;GeographicalIntervalRef ref=\u0026#34;SNCF:GeographicalInterval:TER1km:LOC\u0026#34;/\u0026gt; \u0026lt;FareClass\u0026gt;secondClass \u0026lt;/FareClass\u0026gt; \u0026lt;/Cell\u0026gt; \u0026lt;!--etc...--\u0026gt; \u0026lt;Cell\u0026gt; \u0026lt;CellPrice\u0026gt; \u0026lt;Amount\u0026gt;2.1\u0026lt;/Amount\u0026gt; \u0026lt;LimitingRuleRef ref=\u0026#34;SNCF:LimitingRule:001:LOC\u0026#34;/\u0026gt; \u0026lt;/CellPrice\u0026gt; \u0026lt;GeographicalIntervalRef ref=\u0026#34;SNCF:GeographicalInterval:TER3km:LOC\u0026#34;/\u0026gt; \u0026lt;FareClass\u0026gt;firstClass\u0026lt;/FareClass\u0026gt; \u0026lt;/Cell\u0026gt; \u0026lt;Cell\u0026gt; \u0026lt;CellPrice\u0026gt; \u0026lt;Amount\u0026gt;1.4\u0026lt;/Amount\u0026gt; \u0026lt;LimitingRuleRef ref=\u0026#34;SNCF:LimitingRule:001:LOC\u0026#34;/\u0026gt; \u0026lt;/CellPrice\u0026gt; \u0026lt;GeographicalIntervalRef ref=\u0026#34;SNCF:GeographicalInterval:TER3km:LOC\u0026#34;/\u0026gt; \u0026lt;FareClass\u0026gt;secondClass \u0026lt;/FareClass\u0026gt; \u0026lt;/Cell\u0026gt; \u0026lt;/cells\u0026gt; \u0026lt;/FareTable\u0026gt; \u0026lt;!-- ======================================================================= --\u0026gt; \u0026lt;/members\u0026gt; \u0026lt;/GeneralFrame\u0026gt; \u0026lt;/frames\u0026gt; \u0026lt;/CompositeFrame\u0026gt; \u0026lt;/dataObjects\u0026gt; \u0026lt;/PublicationDelivery\u0026gt; Bibliographie EN 15531-1, Public transport - Service interface for real-time information relating to public transport operations - Part 1: Context and framework\nEN 15531-2, Public transport - Service interface for real-time information relating to public transport operations - Part 2: Communications infrastructure3\nEN 15531-3, Public transport - Service interface for real-time information relating to public transport operations - Part 3: Functional service interfaces4\nCEN/TS 15531-4, Public transport - Service interface for real-time information relating to public transport operations - Part 4: Functional service interfaces: Facility Monitoring\nCEN/TS 15531-5, Public transport - Service interface for real-time information relating to public transport operations - Part 5: Functional service interfaces - Situation Exchange\n  .mark { background-color: yellow; } .mark-blue { background-color: cyan; } .red { color: red; } /* Hide terms \u0026 definitions lists in ToC */ .toc.autonumbering .inner  ul  li:nth-of-type(3)  ul { display: none; } .toc.autonumbering .inner  ul  li:nth-of-type(4)  ul { display: none; } /* Renumber annexes in ToC */ .toc.autonumbering { counter-set: lvl1 0; } .toc.autonumbering .inner  ul  li:nth-child(n+8)::before { counter-increment: lvl1; content: 'Annexe 'counter(lvl1, upper-alpha)' – '; } .toc.autonumbering .inner  ul  li:nth-child(n+8)  ul { counter-set: lvl2 0; } .toc.autonumbering .inner  ul  li:nth-child(n+8)  ul ul { counter-set: lvl3 0; } .toc.autonumbering .inner  ul  li:nth-child(n+8)  ul  li::before { counter-increment: lvl2; content: counter(lvl1, upper-alpha)'.' counter(lvl2)'.'; } .toc.autonumbering .inner  ul  li:nth-child(n+8)  ul  li  ul  li::before { counter-increment: lvl3; content: counter(lvl1, upper-alpha)'.' counter(lvl2)'.' counter(lvl3)'.'; } /* But hide numbering for Bibliographie */ .toc.autonumbering .inner  ul  li:last-child::before { content: \"\"; } /* Renumber annexes in body */ .annexes { counter-set: h1 0 h2 0 h3 0; } .annexes h1::before { content: 'Annexe 'counter(h1, upper-alpha)' – '; } .annexes h2::before { counter-increment: h2; content: counter(h1, upper-alpha)'.' counter(h2)'. '; } .annexes h3::before { counter-increment: h3; content: counter(h1, upper-alpha)'.' counter(h2)'.' counter(h3)'. '; } /* But hide numbering for Bibliographie */ .annexes h1:last-of-type::before { content: \"\"; } .post-content img { margin-inline: auto; width: unset; max-width: 100%; }  ","permalink":"https://deploy-preview-56--transport-normes.netlify.app/normes/netex/tarifs/","summary":"Avant-propos\nL’harmonisation des pratiques dans l’échange des données relatives aux offres de transport est essentielle :\n  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) ;\n  pour les AOT, 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.","title":"NeTEx - Profil France v2.4 - Tarifs"},{"content":"Avant-propos\nL’harmonisation des pratiques dans l’échange des données relatives aux offres de transport est essentielle :\n 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 acteurs du domaine des parkings (exploitants, société de services et experts de domaine) 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 le profil d’échange Profil NeTEx Parking : \u0026ldquo;format de référence pour l\u0026rsquo;échange de données de description des Parkings\u0026rdquo; (issu des travaux NeTEx, Transmodel) qui aujourd’hui fait consensus dans les groupes de normalisation (CN03/GT9 – Parking, et CN03/GT7 – Transport public / information voyageur).\nCe document a été validé et publié comme suit :\n travaux de révision : 2024-2025 date de validation en CN03 : 19 décembre 2025 date de publication : 6 mars 2026  Introduction\nLe présent document fait partie du profil France de NeTEx.\nNeTEx (CEN/TS 16614 series) propose un format et des services d\u0026rsquo;échange de données de description de l\u0026rsquo;offre de transport planifiée, basé sur Transmodel (EN 12896 series) et l’ancienne norme IFOPT (EN 28701). NeTEx permet non seulement d\u0026rsquo;assurer les échanges pour les systèmes d\u0026rsquo;information voyageur mais traite aussi l’ensemble des concepts nécessaires en entrée et sortie des systèmes de planification de l\u0026rsquo;offre (graphiquage, etc.) et des SAE (Systèmes d’Aide à l’Exploitation).\nNeTEx se décompose en six parties:\n  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)\n  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)\n  Partie 3 : information tarifaire (uniquement à vocation d’information voyageur)\n  Partie 4 : profil européen pour l\u0026rsquo;information voyageur (EPIP)\n  Partie 5 : nouveaux modes (les véhicules partagés en libre service, les courses partagées, etc.)\n  Partie 6 : profil européen pour l\u0026rsquo;information voyageur en lien avec l\u0026rsquo;accessibilité (EPIAP)\n  NeTEx a été développé dans le cadre du CEN/TC 278/WG 3/SG 9 piloté par la France. Les premières publications de NeTEx datent de 2014 et les plus récentes de mars 2026.\nIl faut noter que NeTEx a été l\u0026rsquo;occasion de renforcer les liens du CEN/TC278/WG3 avec le secteur ferrovaire, en particulier grâce à la participation de l\u0026rsquo;ERA (Agence Européen du Rail, qui a intégré NeTEx dans la directive Européenne 454/2011 TAP-TSI ) et de l\u0026rsquo;UIC (Union International des Chemins de fer).\nLes 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.\nIl en résulte des normes qui sont relativement volumineuses et dont le périmètre dépasse souvent largement les besoins d\u0026rsquo;une utilisation donnée. Ainsi, à titre d\u0026rsquo;exemple, SIRI propose toute une série d\u0026rsquo;options ou de mécanismes dont la vocation est d\u0026rsquo;assurer la compatibilité avec les systèmes développés en Allemagne dans le contexte des VDV453/454. De même, SIRI propose des services dédiés à la gestion des correspondances garanties, services qui, s\u0026rsquo;ils sont dès aujourd\u0026rsquo;hui pertinents en Suisse ou en Allemagne, sont pratiquement inexistants en France.\nDe plus, un certain nombre de spécificités locales ou nationales peuvent amener à préciser l\u0026rsquo;usage ou la codification qui sera utilisée pour certaines informations. Par exemple, les Anglais disposant d\u0026rsquo;un référentiel national d\u0026rsquo;identification des points d\u0026rsquo;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.\nEnfin, certains éléments proposés par ces normes sont facultatifs et il convient, lors d\u0026rsquo;une implémentation, de décider si ces éléments seront ou non implémentés.\nL\u0026rsquo;utilisation des normes liées à l\u0026rsquo;implémentation de l\u0026rsquo;interopérabilité pour le transport en commun passe donc systématiquement par la définition d\u0026rsquo;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 :\n 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.  Le profil présenté dans ce document permet d’échanger les informations relatives aux Parkings qui constitue les plus importants points de transfert modal et sont aussi un des éléments clés des nouveaux modes de transport. Le cadrage fonctionnel permet de plus de répondre aux attentes de la réglementation Europeénne et de la LOM (Lois d’Orientation pour le Mobilités) en France.\nD\u0026rsquo;autre profils de NeTEx sont disponibles (réseau, horaire, tarif). Ils sont tous complémentaires les uns des autres (sans recouvrement) et s\u0026rsquo;appuient tous sur le document : NeTEx - Profil Français de NETEx: éléments communs. Il conviendra de se référer à ce document pour tous les éléments utilisés dans le présent document, et dont la structure n\u0026rsquo;est pas détaillée.\nCe profil d’échange a pour objectif de décrire et de structurer précisément les éléments nécessaires à une bonne information de description des parkings de façon :\n à pouvoir les présenter d’une manière homogène et compréhensible à l’usager sur des supports différents (papier, ordinateur et smartphone, Internet), à pouvoir les échanger entre systèmes d’information (systèmes d’information voyageurs et systèmes d’information multimodale, systèmes d’aide à l’exploitation, systèmes de planification, systèmes billettiques, etc.).  Les éléments présentés ci-dessous couvrent donc l’ensemble des concepts propres à la description des parkings.\nNOTE IMPORTANTE Ce document étant un profil d\u0026rsquo;échange de NeTEx, il ne se substitue en aucun cas à NeTEx, et un minimum de connaissance de NeTEx sera nécessaire à sa bonne compréhension.\nDomaine d\u0026rsquo;application Le présent document constitue le profil de la CEN/TS 16614 (NeTEx) pour l\u0026rsquo;échange de données de description des parkings en France. Il permet de décrire les parkings et la manière dont ils pourront être structurés pour des échanges entre systèmes d\u0026rsquo;information ainsi que pour leur présentation aux voyageurs.\nRéférences normatives Les documents de référence suivants sont indispensables pour l\u0026rsquo;application du présent document. Pour les références datées, seule l\u0026rsquo;édition citée s\u0026rsquo;applique. Pour les références non datées, la dernière édition du document de référence s\u0026rsquo;applique (y compris les éventuels amendements).\nCEN/TS 16614-1, Network and Timetable Exchange (NeTEx) — Part 1: Public transport network topology exchange format\nCEN/TS 16614-2, Network and Timetable Exchange (NeTEx) — Part 2: Public transport scheduled timetables exchange format\nCEN/TS 16614-3, Network and Timetable Exchange (NeTEx) — Part 3: Fare exchange format\nEN 12896, Road transport and traffic telematics - Public transport - Reference data model (Transmodel)\nTermes et définitions Pour les besoins du présent document, les termes et définitions suivants s\u0026rsquo;appliquent. Une grande partie d’entre eux est directement issue de Transmodel et NeTEx.\nNOTE Les termes spécifiquement introduits par le profil d’arrêt sont signalés par le mot (profil), en italique et entre parenthèses. Les définitions ci-dessous sont des traductions littérales du document normatif.\nNOTE Les définitions ci-dessus sont des traductions littérales du document normatif.\nPARKING (parking) (Transmodel)\n Emplacements désignés pour stationner des véhicules tels que des voitures, des motos et des vélos.\nPARKING PROPERTIES (propriété du parking) (Transmodel)\n Propriéte spécifique du PARKING en complément de sa simple capacité d’accueil.\n PARKING CAPACITY (Transmodel)\n Capacités d’accueil du parking.\n PARKING ENTRANCE FOR VEHICLES (entrée du parking pour les véhicules) (Transmodel)\n Entrée (et/ou sortie) du parking destinée aux véhicules\n PARKING PASSENGER ENTRANCE (entrée du parking pour les piétons) (Transmodel)\n Entrée (et/ou sortie) du parking destinée aux piétons et tout conducteur ou passager des véhicule (y-compruis fauteuils roulants).\n PARKING COMPONENT (composant de Parking) (Transmodel)\n Composant générique du parking (par exemple PARKING AREA -zone de parking- ou PARKING BAY -place de stationnement-)\n PARKING AREA (zone de parking) (Transmodel)\n Zone identifiée à l’intérieur d’un parking, et contenant des places de stationnement (PARKING BAYs).\n PARKING BAY (place de stationnement) (Transmodel)\n Emplacement où l’on peut stationner une (unique) véhicule.\nSymboles et abréviations AO Autorité Organisatrice de Transports\nPMR Personne à Mobilité Réduite\nExigences minimales liées au code des transports et la règlementation européenne La mise à disposition des données, quand elles existent, est obligatoire et se conforme aux exigences :\n Au niveau européen, du règlement délégué (UE) 2017/1926 de la Commission du 31 mai 2017 modifié par le règlement délégué (UE) 2024/490 de la Commission du 29 novembre 2023 (https://eur-lex.europa.eu/eli/reg_del/2017/1926/2024-03-04), dit \u0026ldquo;règlement MMTIS\u0026rdquo; ; Au niveau français, des articles L. 1115-1 à L. 1115-7 , D. 1115-1, R. 1115-2 à R. 1115-8 et D. 1115-9 à D. 1115-11 du code du transports, notamment créés ou modifiés par les articles 25 et 27 de loi n° 2019-1428 du 24 décembre 2019 d’orientation des mobilités, dites loi « LOM ». Ces mêmes articles de la LOM précise le calendrier de mise à disposition des données.  Le tableau ci-dessous résulte de l’analyse du code des transports et du règlement MMTIS et fournit la liste des concepts concernés dans le présent profil correspondant aux données mentionnées dans l’annexe du règlement. Il sera donc nécessaire de fournir ces données pour être conforme au cadre réglementaire (il s’agit bien de mettre à disposition toutes les données existantes dans les SI, et non de créer des données qui n’existeraient pas encore sous forme informatique).\nAttention, certaines données considérées comme facultatives dans ce profil peuvent être exigées par le règlement MMTIS si celles-ci sont disponibles dans les SI. Dans ce cas, il est recommandé de les fournir. En cas de doute, se référer au règlement et notamment à son annexe pour connaître les catégories de données à ouvrir.\nNotez que beaucoup de concepts dépendent d’autres concepts (soit par héritage soit par relation, au sens UML des termes). Ces éléments d’héritage et de relations sont présentés dans les autres parties du profil France, mais pas dans ce tableau.\nDe plus, 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.\nPour 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).\nLa 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).\nLes 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).\nNote : en complément du tableau ci-dessous, le tableau en Annexe B-Traçabilité avec les éléments d’entrée fournit une analyse attribut par attribut des éléments attendus.\nConcepts relatifs à la LOM et à la Règlementation Européenne  Niveau Catégorie Détail Concepts à minima pour le profil Autres concepts Commentaire    COMMISSION DELEGATED REGULATION (UE) 2017/1926  2 Location search (origin/ destination) Address identifiers (building number, street name, postcode) ENTRANCE (VEHICLE and PASSENGER)\nPARKING  L’Adresse est incluse dans tous les objets héritant d'ADRESSABLE PLACE\nAu-delà du Profil Arrêt, les informations d’adresse sont donc attendues pour tous les objets susceptibles d’en porter.  2 Location search (demand-responsive modes) Park \u0026amp; Ride stops Bike sharing stations Car-sharing stations Publicly accessible refuelling stations (for petrol, diesel, CNG/LNG, hydrogen powered vehicles, charging stations for electric vehicles) Secure bike parking (such as locked bike garages) PARKING PARKING AREA\nREFUELLING EQUIPMENT\nVEHICLE CHARGING EQUIPMENT\n Voir le profil Accessibilité pour le détail d’utilisation des équipements  2 Information service Where and how to buy tickets for scheduled modes, demand responsive modes and car parking (all scheduled modes and demand-responsive incl. retail channels, fulfilment methods, payment methods) PARKING (attributs relatif à la tarification)    3 Special Fare Products Aggregated products combining different products and add on products such as parking and travel, minimum stay PARKING (fare related attributes) PARKING TARIFF\n(profil Accessibilité)\nFARE TABLE\nUSER PROFILE\n Le Profil NeTEx Tarif propose les éléments nécessaires à une description détaillées des tarifs.  3 Information service Where how to pay for car parking, public charging stations for electric vehicles and refuelling points for CNG/LNG, hydrogen, petrol and diesel powered vehicles (incl. retail channels, fulfilment methods, payment methods) PARKING (fare related attributes) PARKING TARIFF\n(profil Tarif)\nFARE TABLE\nUSER PROFILE\n(profil Accessibilité)\nTICKETING EQUIPMENT\n Le Profil NeTEx Tarif propose les éléments nécessaires à une description détaillées des tarifs.  COMMISSION DELEGATED REGULATION (EU) 2015/962  1 The types of the static road data Location of parking places and service areas PARKING PARKING AREA   1 The types of the static road data Location of charging points for electric vehicles and the conditions for their use REFUELLING EQUIPMENT\nVEHICLE CHARGING EQUIPMENT\n  Voir le profil Accessibilité pour le détail d’utilisation des équipements  1 The types of the static road data Location of compressed natural gas, liquefied natural gas, liquefied petroleum gas stations REFUELLING EQUIPMENT\nVEHICLE CHARGING EQUIPMENT\n  Voir le profil Accessibilité pour le détail d’utilisation des équipements    Extrait des règlements Européens Les extraits des règlements concernant les parkings sont présentés ci-dessous (volontairement laissés en anglais, langue utilisée pour leur rédaction).\nCOMMISSION DELEGATED REGULATION (UE) 2017/1926 Level of service 2\n(a) Location search (demand-responsive modes):\n (i) Park \u0026amp; Ride stops\n(ii) Bike sharing stations\n(iii) Car-sharing stations\n(iv) Publicly accessible refuelling stations for petrol, diesel, CNG/LNG, hydrogen powered vehicles, charging stations for electric vehicles\n(v) Secure bike parking (such as locked bike garages)\n (b) Information service:\nWhere and how to buy tickets for scheduled modes, demand responsive modes and car parking (all scheduled modes and demand-responsive incl. retail channels, fulfilment methods, payment methods)\nLevel of service 3\nSpecial Fare Products: … aggregated products combining different products and add on products such as parking and travel, minimum stay\n(b) Information service (all modes):\n (iii) Where how to pay for car parking, public charging stations for electric vehicles and refuelling points for CNG/LNG, hydrogen, petrol and diesel powered vehicles (incl. retail channels, fulfilment methods, payment methods)\nTypes of the dynamic travel and traffic data\n(iii) Status of access node features (including dynamic platform information, operational lifts/escalators, closed entrances and exit locations — all scheduled modes)\n(b) Information service:\nAvailability of publicly accessible charging stations for electric vehicles and refuelling points for CNG/LNG, hydrogen, petrol and diesel powered vehicles\n(c) Availability check:\n(i) Car-sharing availability, bike sharing availability\n(ii) Car parking spaces available (on and off-street), parking tariffs, road toll tariffs\n  COMMISSION DELEGATED REGULATION (EU) 2015/962 1. The types of the static road data include in particular:\n (i) location of parking places and service areas;\n(j) location of charging points for electric vehicles and the conditions for their use;\n(k) location of compressed natural gas, liquefied natural gas, liquefied petroleum gas stations;\n(l) location of public transport stops and interchange points;\n(m) location of delivery areas.\n 2. The types of the dynamic road status data include in particular:\n (l) availability of parking places;\n(m) availability of delivery areas;\n(n) cost of parking;\n(o) availability of charging points for electric vehicles;\n Description du profil d’échange Conventions de représentation Tableaux d’attributs NOTE Tous les profils NeTEx partagent les mêmes conventions.\nLes messages constituant ce profil d\u0026rsquo;é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 :\n   Classification Nom Type Cardinalité Description      Classification : permet de catégoriser l\u0026rsquo;attribut. Les principales catégories sont:  PK (Public Key) que l\u0026rsquo;on peut interpréter comme Identifiant Unique: il permet à lui seul d\u0026rsquo;identifier l\u0026rsquo;objet, de façon unique, pérenne et non ambiguë. C\u0026rsquo;est l\u0026rsquo;identifiant qui sera utilisé pour référencer l\u0026rsquo;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\u0026rsquo;attribut contient l\u0026rsquo;identifiant unique (PK) d\u0026rsquo;un autre objet avec lequel il est en relation. GROUP est un groupe XML nommé (ensemble d\u0026rsquo;attributs utilisables dans différents contextes) (voir http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/#AttrGroups )   Nom : nom de l\u0026rsquo;élément ou attribut XSD Type : type de l\u0026rsquo;élément ou attribut XSD (pour certains d\u0026rsquo;entre eux, il conviendra de se référer à la XSD NeTEx) Cardinalité : cardinalité de l\u0026rsquo;élément ou attribut XSD exprimée sous la forme \u0026ldquo;minimum:maximum\u0026rdquo; (\u0026ldquo;0:1\u0026rdquo; pour au plus une occurrence; \u0026ldquo;1:*\u0026rdquo; au moins une occurrence et sans limites de nombre maximal; \u0026ldquo;1:1\u0026rdquo; une et une seule occurrence; etc.). Quand le profil modifie la cardinalité NeTEx (champ facultatif rendu obligatoire), cette modification apparait surlignée en Jaune. Description : texte de description de l\u0026rsquo;é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\u0026rsquo;usage, etc.\nLa description XSD utilisée est strictement celle de NeTEx, sans aucune modification (ceci explique notamment que tous les commentaires soient en anglais).\nLes attributs et éléments rendus obligatoires dans le cadre de ce profil restent facultatifs dans l\u0026rsquo;XSD (le contrôle de cardinalité devra donc être réalisé applicativement).\nValeurs 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 :\n des énumérations fixes définies dans le cadre du schéma XSD NeTEx. Le profil impose alors un sous-ensemble des codes NeTEx. des 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\u0026rsquo;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 ». des instances TypeOfFrame: le profil utilise plusieurs TYPES DE FRAME pour spécifier l\u0026rsquo;utilisation de VERSION FRAME dans le profil.  Indication des classes abstraites NeTEx et Transmodel utilisent largement l\u0026rsquo;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’existe aucune instance concrète; seules les sous-classes terminales sont « concrètes ».\nUn inconvénient de l\u0026rsquo;héritage est que si l\u0026rsquo;on veut comprendre les propriétés d\u0026rsquo;une classe concrète unique, il faut également examiner toutes ses super-classes. Pour cette raison, le profil 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.\n 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) ».\nModèle de données PARKING – Modèle conceptuel\nL\u0026rsquo;objet le plus haut dans l\u0026rsquo;arbre d\u0026rsquo;héritage est la ZONE, décrivant un objet générique à deux dimensions. Une ZONE peut être définie par un GROUPE DE POINTS appartenant à la ZONE, et peut également être définie comme une zone géométrique, bordée d\u0026rsquo;un polygone.\nUne ZONE peut contenir d\u0026rsquo;autres ZONEs plus petites. Ceci est exprimé par la relation réflexive sur ZONE et donc un PARKING peut inclure d\u0026rsquo;autres PARKING comme tous les objets qui héritent de la ZONE : dans le contexte du profil Parking , on se limitera à 3 niveaux au maximum (un PARKING de plus haut niveau, pouvant contenir un ou plusieurs Parkings, chacun pouvant à leur tour contenir un ou plusieurs Parkings mais sans pouvoir descendre plus « bas »).\nUne ZONE peut être représentée par un seul POINT (par l\u0026rsquo;attribut *Centroïd) ***qui peut être utilisé comme une référence ponctuelle à la ZONE elle-même. Ceci est utile pour représenter les systèmes de transport flexibles (où un arrêt est souvent un ZONE). Concrètement pour un PARKING, cela signifie que sa géométrie peut être décrite par une surface, un ponctuel ou les deux.\nLe deuxième niveau de la hiérarchie est la PLACE, qui représente n\u0026rsquo;importe quel endroit significatif qu\u0026rsquo;un modèle de transport peut vouloir décrire, et pour lequel la possibilité de voyage peut exister (départ, arrivée ou point de passage). Une PLACE peut être spécialisée de diverses manières, notamment une TOPOGRAPHIC PLACE (une ville, un département ou une région nommée), ou une ADDRESSABLE PLACE spécifique ayant une ADRESSE qui est soit un ROAD ADDRESS, soit un POSTAL ADDRESS.\nL’élément de site spécialisé ADDRESSABLE PLACE peut être utilisé pour ajouter l\u0026rsquo;accessibilité (voir ACCESSIBILITY ASSESMENT dans le Profil Éléments Communs) et d\u0026rsquo;autres propriétés communes à tout lieu pouvant être parcouru par un passager. Le SITE spécialise l’ELEMENT DE SITE pour fournir une description générale des propriétés communes d\u0026rsquo;un lieu, tel qu\u0026rsquo;une station ou un point d\u0026rsquo;intérêt, y compris ses entrées, niveaux, équipements, cheminements, propriétés d\u0026rsquo;accessibilité, etc. Le SITE est lui-même spécialisé en STOP PLACE, POINT D\u0026rsquo;INTERET, PARKING, etc.\nUn PARKING est un type de SITE qui décrit la possibilité du stationnement pour différents types de véhicules, ainsi que les relations avec d\u0026rsquo;autres SITE tels que les gares.\nUn PARKING peut être décrit de façon résumée et de façon détaillée - par exemple, un parking de 50 places, ou encore le même PARKING peut être décomposé en ZONES DE STATIONNEMENT (chacune sur un NIVEAU), chacune contenant des PLACEs DE PARKING individuelles d\u0026rsquo;une taille désignée.\nUn PARKING peut avoir des ENTRÉES DE VÉHICULE ainsi que des ENTRÉEs PIETONNEs.\nPARKING – Vue détaillée incluant les principaux attributs\nParking [Code PAYS]:[Code commune INSEE]:[Parking]:[Code parking spécifique]:[Code émetteur du code technique ou LOC], on aura donc :\n [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]: Parking [Code arrêt spécifique] : code technique libre [Code émetteur du code technique] : Identifiant de l’attributeur de code technique, par exemple EFFIA, QParK, Indigo, Parcub, ou l’identifiant de la collectivité en charge du parking. LOC permet de préciser que l\u0026rsquo;identifiant a été défini de façon locale entre les parties engagées dans l\u0026rsquo;échange, et qu\u0026rsquo;il ne fait donc pas partie du référentiel partagé (local, régional, national, etc.) L\u0026rsquo;utilisation de ce qualificatif est obligatoire quand l\u0026rsquo;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.  Exemple FR:75105:Parking:076:LOC\nPour mémoire, les élément constitutif de cet identifiant n’ont pour vocation que de garantir l’unicité et la pérennité quel que soit le contexte géographique et organisationel: à aucun moment cet identifiant ne doit être utilisé pour en extraire des information sémantique (ces information figure dans les attributs des objets). En corollaire, une fois un identifiant attribué, il ne doit plus être modifié, même si l’un des constitutifs utilisé était amené à changer.\nNote : dans le cas de parkings pour lesquels un identifiant unique aurait été délivré par le Point d’accès national sous la forme INSEE-P-xxx (où INSEE est le code INSEE de la commune et xxx est le numéro d’ordre sur 3 chiffres) le code INSEE sera réutilisé dans la structuration ci-dessus et xxx sera utilisé pour le [Code arrêt spécifique], le [Code émetteur du code technique] sera « NAP ».\nParking – Element  Class. Name Type Card. Description    ::\u0026gt; ::\u0026gt; Site ::\u0026gt; PARKING hérite de SITE.\nVoir A.2-Profil Arrêt pour les détails.\nNote : beaucoups d’éléments important comme la gestion des version, les conditions de validité ou des attibuts classique comme le nom, la description, ou encore la géométrie et la position sont issu de cet héritage.\nNote : dans la chaine d’héritage, Id et Name, AvaliabilityCondition Centroid.Location.Longitude/Latitude sont des attributs obligatoire pour le profi Parking.\n  « PK » id ParkingIdType 1:1 Identifiant du PARKING.\nVoir codification ci-dessus\n  « cntd » (SiteAccessGroup) SiteAccessGroup 0:1 Description des lieux liés au Parking et des cheminement qui y amène (voir SiteConnection et NavigationPath dans le profil Accessibilité).  « AK » PublicCode StopPlaceCodeType 0:1 Code Publique utilisé pour le PARKING.   Label MultilingualString 0:1 Label associé au parking PARKING.   ParkingType ParkingTypeEnum 0:*\n1:1\n Nature du PARKING.\n parkAndRide (P+R)\nliftShareParking (parking pour covoiturage)\nurbanParking (parking urbain)\nairportParking (parking d’aéroport)\ntrainStationParking (parking de gare)\nexhibitionCentreParking (parking de park d’exposition)\nrentalCarParking (parking pour loueur)\nshoppingCentreParking (parking de centre comercial)\nmotorwayParking (parking d’autoroute\nroadside (parking en voirie)\nparkingZone (zone de parking)\nundefined (type non précisé)\ncycleRental (Parking de location de vélo/trotinettes/etc.)\nother (note : devra systématiquement donner lieu au renseignement de TypeOfParkingRef)\n\n   TypeOfParkingRef TypeOfParking 0:1 Reference à un TYPE OF PARKING (valeur libre non précodée uniquement pour les type non proposés par ParkingType)   ParkingVehicleTypes VehicleTypeList 0 :*\n1:*\n Types de Vehicle autorisés dans le PARKING.\n pedalCycle (vélo avec pédales, iclus les vélos électriques)\nmoped (vélomoteur)\nmotorcycle (moto)\nmotorcycleWithSidecar (moto avec sidecar)\nmotorScooter (scooter)\ntwoWheeledVehicle (véhicule à 2 roues)\nthreeWheeledVehicle (véhicules à 3 roues)\ncar (voiture)\nsmallCar (petite voiture)\npassengerCar (de microcar jusqu’à 9 personnes)\nlargeCar (grosse voiture)\nfourWheelDrive (4x4)\ntaxi (taxi)\ncamperCar (campingcar)\ncarWithTrailer (voiture avec remorque)\ncarWithCaravan (voiture avec caravane)\nminibus (minibus)\nbus (bus)\nvan (van, fourgonnette)\nlargeVan (gros van, fourgonnette)\nhighSidedVehicle (véhcule haut, au dela de 2.90 m)\nlightGoodsVehicle (utilitaire léger)\nheavyGoodsVehicle (utilitaire lourd)\nagriculturalVehicle (engin agricole)\ntanker (camion citerne)\ntruck (camion)\ntram (tram)\narticulatedVehicle (vehicule articulé)\nvehicleWithTrailer (camion remoque)\nlightGoodsVehicleWithTrailer (utilitaire léger avec remorque)\nheavyGoodsVehicleWithTrailer (utilitaire lourd avec remorque)\nundefined (non précisé)\nallPassengerVehicles (tous vehicules pour passagers hors fret et utilitaires donc)\nall (tous)\nother (note : devra systématiquement donner lieu au renseignement de vehicleTypes)\n   vehicleTypes TransportTypeRef 0:1 Type de véhicule en complément du champ précédent (valeur libre non précodée uniquement pour les types non proposés par ParkingVehicleTypes)\nNote : les information liées aux types de carburant nécessitent l’utilisation des VehicleType (VehicleType.FuelType, par exemple pour le GPL, voir A.3-Véhicules)   ParkingLayout ParkingLayoutEnum 0:1\n1:1\n Nature du PARKING.\n Covered (couvert)\nopenSpace (espace ouvert)\nmultistorey (à plusieur étages/niveaux)\nunderground (sous terrain)\nroadside (bord de route)\nundefined (non précisé)\nother (autre… renseigner la description dans ce cas)\ncycleHire (location de cycle et trotinettes, inclus les vehicules partagés)\n   NumberOfParkingLevels xsd:nonNegativeInteger 0:1 Nombre total de niveaux   TotalCapacity NumberOfSpaces 0:1\n1:1\n Capacité totale (incluant les places handicapées, réservées, etc.)   OvernightParkingPermitted xsd:boolean 0:1 Signale si les véhicules peuvent rester la nuit.   ProhibitedForHazardousMaterials xsd:boolean 0:1 Parking interdit pour les vehicules transportant des matériaux dangereux.   RechargingAvailable xsd:boolean 0:1 Indique si le parking dispose de bornes de recharge.   Secure xsd:boolean 0:1 Indique si le parking est sécurisé (gardiénage, surveillance, etc.)   RealTimeOccupancyAvailable xsd:boolean 0:1 Indique si le parking dispose d’une information temps réel sur les places disponibles.  Éléments génériques de tarification   ParkingPaymentProcess PaymentProcessEnum 0:*\n1:*\n Modes des paiement disponible\n free (gatuit)\npayAtBay (aux bornes de sortie)\npayAndDisplay (horodateur)\npayAtExitBoothManualCollection (manuel à la sortie)\npayAtMachineOnFootPriorToExit (en machine, à pied, avant de sortir)\npayByPrepaidToken (prépaiement)\npayByMobileDevice (par mobile)\nundefined (non précisé)\nother (autre)\n   PaymentMethods PaymentMethodList 0:*\n1:*\n Méthodes de paiement utilisées dans le PARKING.\n cash (liquide)\ncashExactChangeOnly (miquide sans rendu de monaie)\ncashAndCard (liquide et cartes)\ncoin (pièces)\nbanknote (billets)\ncheque (chèque)\ntravellersCheque (traveller chèque)\npostalOrder (mandat postal)\ncompanyCheque (chèque d’entreprise)\ncreditCard (carte de crédit)\ndebitCard (carte de débit)\ncardsOnly (cartes uniquement)\ntravelCard (carte de transport)\ncontactlessPaymentCard (paiement sans contact)\ncontactlessTravelCard (carte de transport sans contact)\ndirectDebit (prélèvement)\nbankTransfer (virement bancaire)\nepayDevice (paiement électronique)\nepayAccount (compte électronique)\nsms (par SMS)\nmobilePhone (par télépohne portable)\nmobileApp (par Application sur téléphone ou ordinateur)\nvoucher (voucher/bon)\ntoken (jeton)\nwarrant (madat)\nmileagePoints (miles)\nother (autre)\n   typesOfPaymentMethod TypeOfPaymentMethodRef 0 :* Method of Payment (valeur libre non précodée uniquement pour les type non proposés par PaymentMethods)   DefaultCurrency CurrencyType 0:1 Devise par défaut (Euros en France… même si le champs n’est pas rempli)   CurrenciesAccepted CurrencyList 0:1 Devises acceptées.   CardsAccepted xsd:NMTOKENS 0:1 Indique les carte de payment acceptées\nLe Profil prédéfini quelque code de TypeOfPaymentMethod :\n VISA MASTERCARD CB TOTAL (GR) LIBERTE  Plusieurs cartes peuvent naturellement être indiquées (in sépare la noms pas des espaces)\n   ParkingReservations ParkingReservationEnum 0:1 Type de réservation\n reservationRequired (réservation nécessaire) reservationAllowed (réservation possible) noReservations (pas de réservation) registrationRequired (enregistrement nécessaire pour accéder au parking) other (autre)    BookingUrl xsd:anUri 0:1 URL poiur la réservation.  « cntd » PaymentByMobile PaymentByMobile 0:1 Comment payer par téléphone ou via une app.   FreeParkingOutOfHours xsd:boolean 0:1 Indique si le parking est accessible et gratuit en dehors des heures d’ouvertures.  Constituants  « cntd » parkingProperties ParkingProperties 0 :* Proriétés détaillées du PARKING.\nNote : On ne remplira qu’un unique block ParkingProperties global au parking, les propriétés spécifique aux Areas seront directement renseignées dans les bloc Area eux même\n  « cntd » parkingAreas ParkingArea 0 :* PARKING AREAs (zon de parking) faisant partie de ce PARKING.\nNote : Comme dans tous les profile Français de NeTEx on utilisera ici l’inclusion XML et non les références.\n  « cntd » entrances StopPlaceEntrance 0 :* Liste des entrées pour les véhicules et les piértons.    PaymentByMobile – Element  Class. Name Type Card. Description     PhoneNumberToPay PhoneType 0:1 Numéro de téléphone pour le paiement (appel et/ou SMS)   SupportPhoneNumber PhoneType 0:1 Numéro de téléphone pour l’assistance.   PaymentUrl xsd:anyUri 0:1 URL pour le paiement.   PaymentAppDownloadUrl xsd:anyUri 0:1 URL pour télécharger l’application de paiement.\nNote : s’il y a plusieurs application de paiement, ou plus classiquement des accès à l’application différentiés par type de plateforme (IOS, Android, etc.), l’URL fournisra un lien d’accès à une page fournissant l’ensemble de liens de téléchargement.\n    TypeOfPaymentMethod – Element    Class. Name Type Card. Description     ::\u0026gt; ::\u0026gt; TypeOfValue ::\u0026gt; TYPE OF PAYMENT METHOD hérite de TYPE OF VALUE (voir Profil Éléments Communs).   « PK » id TypeOfPaymentMethodIdType 1:1 Identifiant du TYPE OF PAYMENT METHOD.   « enum » PaymentMethod PaymentMethodEnum 0:1 Type de méthode de paiement prédéfinie que l’on peut associée à ce TYPE OF PAYMENT METHOD spécifique.    AutomatedUse xsd:boolean 0:1 Indique si le paiement peut être automatisé (débit direct, etc.).     Exemple \u0026lt;Parking id=\u0026#34;FR:75105:Parking:076:Qpark\u0026#34; version=\u0026#34;2\u0026#34; responsibilitySetRef=\u0026#34;FR:ResponsibilitySet:0123:LOC\u0026#34;\u0026gt; \u0026lt;validityConditions\u0026gt; \u0026lt;AvailabilityCondition id=\u0026#34;FR:AvailabilityCondition:01:Qpark\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;!-- Ouverture semaine et samedi--\u0026gt; \u0026lt;IsAvailable\u0026gt;true\u0026lt;/IsAvailable\u0026gt; \u0026lt;dayTypes\u0026gt; \u0026lt;DayType version=\u0026#34;any\u0026#34; id=\u0026#34;FR:DayType:01:Qpark\u0026#34;\u0026gt; \u0026lt;properties\u0026gt; \u0026lt;PropertyOfDay\u0026gt; \u0026lt;DaysOfWeek\u0026gt;Weekdays Weekend\u0026lt;/DaysOfWeek\u0026gt; \u0026lt;/PropertyOfDay\u0026gt; \u0026lt;/properties\u0026gt; \u0026lt;timebands id=\u0026#34;FR:timebands:01:Qpark\u0026#34;\u0026gt; \u0026lt;Timeband id=\u0026#34;FR:Timeband:01:Qpark\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;StartTime\u0026gt;07:00:00\u0026lt;/StartTime\u0026gt; \u0026lt;EndTime\u0026gt;20:00:00\u0026lt;/EndTime\u0026gt; \u0026lt;/Timeband\u0026gt; \u0026lt;/timebands\u0026gt; \u0026lt;/DayType\u0026gt; \u0026lt;/dayTypes\u0026gt; \u0026lt;/AvailabilityCondition\u0026gt; \u0026lt;/validityConditions\u0026gt; \u0026lt;Name\u0026gt;PATRIARCHES\u0026lt;/Name\u0026gt; \u0026lt;ParkingType\u0026gt;urbanParking\u0026lt;/ParkingType\u0026gt; \u0026lt;ParkingVehicleTypes\u0026gt;car\u0026lt;/ParkingVehicleTypes\u0026gt; \u0026lt;ParkingLayout\u0026gt;underground\u0026lt;/ParkingLayout\u0026gt; \u0026lt;TotalCapacity\u0026gt;334\u0026lt;/TotalCapacity\u0026gt; \u0026lt;ParkingPaymentProcess\u0026gt;payAtMachineOnFootPriorToExit payAtBay\u0026lt;/ParkingPaymentProcess\u0026gt; \u0026lt;PaymentMethods\u0026gt;cashAndCard epayDevice contactlessPaymentCard\u0026lt;/PaymentMethods\u0026gt; \u0026lt;ParkingReservation\u0026gt;noReservations\u0026lt;/ParkingReservation\u0026gt; \u0026lt;parkingProperties\u0026gt; \u0026lt;ParkingProperties id=\u0026#34;FR:ParkingProperties:1:Qpark\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;ParkingUserTypes\u0026gt;allUsers\u0026lt;/ParkingUserTypes\u0026gt; \u0026lt;/ParkingProperties\u0026gt; \u0026lt;/parkingProperties\u0026gt; \u0026lt;!-- … etc. (ParkingAreas, Entrances …) --\u0026gt; \u0026lt;/Parking\u0026gt; Composants des Parkings ParkingArea – Element  Class. Name Type Card. Description    ::\u0026gt; ::\u0026gt; SiteComponentGroup ::\u0026gt; PARKING AREA hérite de PARKING COMPONENT.\nNote : beaucoups d’éléments important comme la gestion des version, les conditions de validité ou des attibuts classique comme le nom, la description, ou encore la géométrie et la position sont issu de cet héritage.\n  « PK » id ParkingAreaIdType 1 :1 Identifiant du PARKING AREA.\nForme :\n[Code fournisseur]:[ParkingArea] :[Code technique]:LOC\n   TotalCapacity NumberOfSpaces 0:1 Capacité totale du PARKING AREA.   NumberOfBaysWithRecharging NumberOfSpaces 0:1 Nombre de places disposant d’une borne de recharge électrique dans le PARKING AREA.  « cntd » ParkingProperties ParkingProperties 0:1 Propriétés détaillée du PARKING AREA.  « cntd » bays ParkingBay 0 :* Détail des place individuelles dans le PARKING AREA.\nNote : Comme dans tous les profile Français de NeTEx on utilisera ici l’inclusion XML et non les références.\nNote : la description détaillée des places de parking est nécessaire en particulier dans le contexte des place PMR.\n  « cntd » entrances SiteEntrance 0 :* ENTRANCEs of PARKING COMPONENT.    ParkingComponent – Element  Class. Name Type Card. Description    ::\u0026gt; ::\u0026gt; SiteComponent ::\u0026gt; PARKING COMPONENT hérite de SITE COMPONENT.  « PK » id ParkingComponentIdType 1:1 Identifiant du PARKING COMPONENT.   ParkingPaymentCode xsd:normalizedString 0:1 Code de paiement associé au PARKING COMPONENT   Label MultilingualString 0:1 Label additionel désignant le PARKING COMPONENT.   MaximumLength LengthType 0:1 Longueur maximale des véhicules dans le PARKING AREA.   MaximumWidth LengthType 0:1 Largeur maximale des véhicules dans le PARKING AREA.   MaximumHeight LengthType 0:1\n1:1\n Hauteur maximale des véhicules dans le PARKING AREA.   MaximumWeight WeightType 0:1 Poids maximal des véhicules dans le PARKING AREA.    La ParkingBay correspond à l’emplacement pour garer un véhicule.\nParkingBay – Élement  Class. Name Type Card. Description    ::\u0026gt; ::\u0026gt; SiteComponent ::\u0026gt; PARKING BAY hérite de SITE COMPONENT.\nNote : beaucoups d’éléments importants comme la gestion des versions, les conditions de validité ou encore la géométrie, la position et l’accessibilité de la place sont issus de cet héritage. Pour les détails sur l'accessibilité, voir l'annexe 9 du profil accessibilité.\n  « PK » id ParkingBayIdType 1:1 Identifiant du PARKING BAY.   ParkingVehicleType ParkingVehicleEnum 0:1 TYPEs of VEHICLE qui peuvent utiliser cette place.   Length LengthType 0:1 Longueur de la place.   Width LengthType 0:1 Largeur de la place.   Height LengthType 0:1 Hauteur de la place.   Weight WeightType 0:1 Poids maximal pour la place.   RechargingAvailable xsd:boolean 0:1 Indique si une borne de recharge est disponible à la place. Voir EQUIPMENT pour plus de détails.    ParkingProperties décrit les propriétés générale du PARKING et de ses constituants, à l’exception des caractéristiques de capacité.\nParkingProperties – Element  Class. Name Type Card. Description    ::\u0026gt; ::\u0026gt; VersionedChild ::\u0026gt; PARKING PROPERTies hérite de VERSIONED CHILD.  « PK » id ParkingPropertiesIdType 1:1 Identifiant du PARKING PROPERTies.   Name MultilingualString 0 :1 Nom associé à ces propiétés (permet de les identifer clairement quand il y a plusieurs groupes de propriétés)   ParkingUserType ParkingUserEnum 0 :* Types d’utilisateurs admis\n allUsers (pas de restriction)\nstaff (personnel du parking)\nvisitors (visiteurs)\nregisteredDisabled (personnes handicapées enregistrèes)\nregistered (personnes enregistrées)\nrental (location… personnes louant la place)\ndoctors (docteurs et personels médicaux)\nresidentsWithPermits (résident avec permis)\nreservationHolders (personnes ayant réservé)\nemergencyServices (services d’urgence)\ntaxi (taxi)\nvehicleSharing (partage de véhicule)\nother (autre)\n   ParkingVehicleTypes VehicleTypeList 0 :*\n1:*\n Types de véhicles autorisés :\n pedalCycle (vélo avec pédales, iclus les vélos électriques)\nmoped (vélomoteur)\nmotorcycle (moto)\nmotorcycleWithSidecar (moto avec sidecar)\nmotorScooter (scooter)\ntwoWheeledVehicle (véhicule à 2 roues)\nthreeWheeledVehicle (véhicules à 3 roues)\ncar (voiture)\nsmallCar (petite voiture)\npassengerCar (de microcar jusqu’à 9 personnes)\nlargeCar (grosse voiture)\nfourWheelDrive (4x4)\ntaxi (taxi)\ncamperCar (campingcar)\ncarWithTrailer (voiture avec remorque)\ncarWithCaravan (voiture avec caravane)\nminibus (minibus)\nbus (bus)\nvan (van, fourgonnette)\nlargeVan (gros van, fourgonnette)\nhighSidedVehicle (véhcule haut, au dela de 2.90 m)\nlightGoodsVehicle (utilitaire léger)\nheavyGoodsVehicle (utilitaire lourd)\nagriculturalVehicle (engin agricole)\ntanker (camion citerne)\ntruck (camion)\ntram (tram)\narticulatedVehicle (vehicule articulé)\nvehicleWithTrailer (camion remoque)\nlightGoodsVehicleWithTrailer (utilitaire léger avec remorque)\nheavyGoodsVehicleWithTrailer (utilitaire lourd avec remorque)\nundefined (non précisé)\nallPassengerVehicles (tous vehicules pour passagers hors fret et utilitaires donc)\nall (tous)\nother (note : devra systématiquement donner lieu au renseignement de vehicleTypes)\n   vehicleTypes TransportTypeRef 0:1 Type de véhicule en complément du champ précédent (valeur libre non précodée uniquement pour les type non proposés par ParkingVehicleTypes)\nNote : les information lées aux types de carburant nécessitent l’utilisation des VehicleType (VehicleType.FuelType, par exemple pour le GPL, voir A.3-Véhicules)   ParkingStayList ParkingStayEnumeration 0 :* Type de durée de stationnement\n shortStay (courte durée)\nmidTerm (moyenne durée)\nlongTerm (longue durée)\ndropoff (déponse minute)\nunlimited (non limité)\nother (autre)\nall (toutes les possibilités)\n   MaximumStay xsd:duration 0 :1 Durée maximale du stationnement   BayGeometry BayGeometryEnumeration  Type de positionnement des véhicule\n Unspecified (non précisé)\northogonal (perpendiculaire)\nangled (en épis)\nparallel (logitudinal)\nfreeFormat (libre)\nother (autre)\n   ParkingVisibility ParkingVisibilityEnumeration  Type de marquage des places\n Unmarked (non marqué)\nsignageOnly (signalisation par panneau ou sinalétique)\ndemarcated (marquage au sol)\ndocks (démarquation physique)\nother (autre)\n  « contents » spaces ParkingCapacity 0 :*\n1:*\n Capacité de cet espace\nNote : Comme dans tous les profile Français de NeTEx on utilisera ici l’inclusion XML et non les références.\n    ParkingCapacity décrit les caractéristiques de capacité du PARKING et de ses constituants.\nParkingCapacity – Element  Class. Name Type Card. Description    ::\u0026gt; ::\u0026gt; VersionedChild ::\u0026gt; PARKING CAPACITY hérite de VERSIONED CHILD.  « PK » id ParkingCapacityIdType 1:1 Identifiant du PARKING CAPACITY.  « enum » ParkingUserType ParkingUserEnum 0:1 Type d’utilisateur concerné par cette capacité  « enum » ParkingVehicleType ParkingVehicleEnum 0:1 Type de véhicule concerné par cette capacité   TransportTypeRef TransportTypeRef 0:1 Type de véhicule en complément du champ précédent (valeur libre non précodée uniquement pour les type non proposés par ParkingVehicleTypes)\nNote : les information lées aux types de carburant nécessitent l’utilisation des VehicleType (VehicleType.FuelType, par exemple pour le GPL, voir A.3-Véhicules)  « enum » ParkingStayType ParkingStayEnum 0:1 Durée de stationnement pour ce PARKING CAPACITY.\n shortStay (courte durée)\nmidTerm (moyenne durée)\nlongTerm (longue durée)\ndropoff (déponse minute)\nunlimited (non limité)\nother (autre)\nall (toutes les possibilités\n   NumberOfSpaces NumberOfVehicles 0:1 Nombre total de places de parking.   NumberOfSpacesWithRechargePoint NumberOfVehicles 0:1 Dont, nombre de places de parking équipé en bornes de recharge.    Exemple \u0026lt;ParkingArea id=\u0026#34;FR:ParkingArea:76-1:Qpark\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Zone PMR\u0026lt;/Name\u0026gt; \u0026lt;AccessibilityAssessment version=\u0026#34;any\u0026#34; id=\u0026#34;FR:AccessibilityAssessment:01:Qpark\u0026#34;\u0026gt; \u0026lt;MobilityImpairedAccess\u0026gt;true\u0026lt;/MobilityImpairedAccess\u0026gt; \u0026lt;/AccessibilityAssessment\u0026gt; \u0026lt;PublicUse\u0026gt;disabledPublicOnly\u0026lt;/PublicUse\u0026gt; \u0026lt;Label\u0026gt;Zone VERTE\u0026lt;/Label\u0026gt; \u0026lt;MaximumHeight\u0026gt;190\u0026lt;/MaximumHeight\u0026gt; \u0026lt;TotalCapacity\u0026gt;7\u0026lt;/TotalCapacity\u0026gt; \u0026lt;/ParkingArea\u0026gt; Entrées des Parkings ParkingEntranceForVehicle décrit une possibilité d’accès au PARKING depuis la voirie.\nParkingEntranceForVehicle – Element  Class. Name Type Card. Description    ::\u0026gt; ::\u0026gt; SiteEntrance ::\u0026gt; PARKING VEHICLE ENTRANCE hérite de ENTRANCE.\nVoir A.2.6-Entrée\nNotez notamment l’élément IsExternal qui permettre de distinguer les entrées extérieures de celles intérieures, entre zones du parking (séparation d’une zone Premium ou d’une zone dédiée à la location ou à l’autopartage, etc.)\nNote : dans la chaine d’héritage Centroid.Location.Longitude / Latitude sont des attributs obligatoire pour le profi Parking.\n  « PK » id VehicleEntranceIdType 1:1 Identifiand du PARKING VEHICLE ENTRANCE.   ModeOfOperationRef ModeOfOperationRef 0 :* Types de services auxquel cette entrèe est dédiée.\nLe ModeOfOperation permettra de spécialiser les entrées : pour l’autopartage, les locations, le covoiturage, etc.\n  « FK » areas ParkingAreaRef 0:1 PARKING AREAs auquel le PARKING VEHICLE ENTRANCE donne accès.    ParkingPassengerEntrance décrit une possibilité d’accès au PARKING pour les piétons (incluant les accès type fauteils roulant, etc.).\nParkingPassengerEntrance – Element  Class. Name Type Card. Description    ::\u0026gt; ::\u0026gt; Entrance ::\u0026gt; PARKING PASSENGER ENTRANCE hérite de ENTRANCE.\nVoir A.2.6-Entrée\nNote : Les caractéristiques d’accessibilité des entrées de parking peuvent être détaillées par les classiques ACCESSIBILITY ASSESMENTs (voir annexe 9 du profil Accessibilité) et il est aussi possible d’y associer des FACILITY SET (services et équipement disponibles)\nNote : dans la chaine d’héritage Centroid.Location.Longitude / Latitude sont des attributs obligatoire pour le profi Parking.\n  « PK » id PassengerEntranceIdType 1:1 identifiant PARKING PASSENGER ENTRANCE.  « FK » areas ParkingAreaRef 0:1 PARKING AREAs auquel le PARKING VEHICLE ENTRANCE donne accès.    Exemple \u0026lt;vehicleEntrances\u0026gt; \u0026lt;ParkingEntranceForVehicles id=\u0026#34;FR:ParkingEntranceForVehicles:1:Qpark\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Entr\u0026amp;#xE9;e/sortie principale pour les v\u0026amp;#xE9;hicules\u0026lt;/Name\u0026gt; \u0026lt;Centroid\u0026gt; \u0026lt;Location\u0026gt; \u0026lt;Longitude\u0026gt;2.3508884\u0026lt;/Longitude\u0026gt; \u0026lt;Latitude\u0026gt;48.8403437\u0026lt;/Latitude\u0026gt; \u0026lt;/Location\u0026gt; \u0026lt;/Centroid\u0026gt; \u0026lt;/ParkingEntranceForVehicles\u0026gt; \u0026lt;/vehicleEntrances\u0026gt; \u0026lt;ParkingPassengerEntrance id=\u0026#34;FR:ParkingPassengerEntrance:1:Qpark\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Entr\u0026amp;#xE9;e pi\u0026amp;#xE9;tone principale\u0026lt;/Name\u0026gt; \u0026lt;Centroid\u0026gt; \u0026lt;Location\u0026gt; \u0026lt;Longitude\u0026gt;2.3508884\u0026lt;/Longitude\u0026gt; \u0026lt;Latitude\u0026gt;48.8403437\u0026lt;/Latitude\u0026gt; \u0026lt;/Location\u0026gt; \u0026lt;/Centroid\u0026gt; \u0026lt;/ParkingPassengerEntrance\u0026gt; Parking – Offre tarifaire détaillée Les éléments ci-dessus n’ont donnés que des informations très générales sur la tarification des parking (mode de paiements acceptés, URL de réservation, etc.) : le modèle ci-dessous permet d’en fournir une description plus détaillée.\nDe plus, le stationnement est souvent au sein d\u0026rsquo;un trajet multimodal en voiture et en transports en commun et certains PRODUITS TARIFAIREs du transport en communs peuvent inclure des éléments de stationnement; par exemple, le stationnement dans une gare peut être inclus dans le prix global d\u0026rsquo;un billet. Le modèle suivant montre comment les TARIFs DE PARKINGs peuvent être décrit avec dans les structures tarifaires de NeTEx.\nTarification des parkings Le modèle de tarif de stationnement propose une vue simplifiée des tarif NeTEx adaptée aux parkings.\nLes tarifs de stationnement peuvent être spécifiés pour un PARKING et/ou sa subdivision PARKING AREA à l’aide d’un élément PARKING PROPERTIES.\nUn tarif de stationnement est composé d’une ou de plusieurs périodes de stationnement (PARKING CHARGE BAND) pour un ensemble donné de TYPE DE VÉHICULE. Chaque période peu naturellement avoir une traification différente.\nCe modèle permettra essentiellement de renseigner les tarifications sur base horaire ; les tarifications par abonnement seront décrites en utilisant les tableaux tarifaires (FareTable) et descriptions des droits tels que définis dans le Profil France Tarif de NeTEx (un exemple typique d’utilisation de tableaux tarifaires et fourni par l’exemple comple en annexe de ce document).\n.\nParking Tariff – Conceptual Model\nParking Tariff – Attributes and XSD Ensemble de frais de stationnement qui décrivent le coût de l’utilisation d’un PARKING ou d’une PARKING AREA.\nParkingTariff – Element  Class. Name Type Card. Description    ::\u0026gt; ::\u0026gt; DataManagedObject ::\u0026gt; PARKING TARIFF hérite de TARIFF.  « PK » id ParkingTariffIdType 1:1 Identifiant du PARKING TARIFF.  XGRP TariffDescriptionGroup xmlGroup 0:1 Voir A.7-Profil Tarif  XGRP TariffOrganisationGroup xmlGroup 0:1 Voir A.7-Profil Tarif  XGRP TariffTimeGroup xmlGroup 0:1 Voir Profil Tarif  XGRP TariffQualityGroup xmlGroup 0:1 Voir Profil Tarif  « enum » ParkingUserType ParkingUserEnumeration 0:1 Type d’utilisateur concerné par ce TARIFF  « enum » ParkingStayType ParkingStayEnum 0:1 Durée de stationnement pour ce TARIFF.\n shortStay (courte durée)\nmidTerm (moyenne durée)\nlongTerm (longue durée)\ndropoff (déponse minute)\nunlimited (non limité)\nother (autre)\nall (toutes les possibilités\n  « enum » ParkingVehicleType ParkingVehicleEnum 0:1 Types de véhicule concerné par ce tarif.   vehicleTypes transportTypeRefs_RelStructure 0:* Type de véhicule en complément du champ précédent (valeur libre non précodée uniquement pour les type non proposés par ParkingVehicleTypes)\nNote : les information lées aux types de carburant nécessitent l’utilisation des VehicleType (VehicleType.FuelType, par exemple pour le GPL, voir A.3-Véhicules)   appliesTo parkingRefs_RelStructure 0:* PARKINGs concernés par ce tarif (cela permet de mutualiser une tarification entre plusieurs parkings)   AdditionalTax xsd:boolean 0:1 Indique si des taxes additionnelles (TVA, taxe locale, etc.) sont à prévoir  « cntd » parkingChargeBands ParkingChargeBand 0:* Tranches horaires du PARKING TARIFF.    Frais de stationnement qui décrivent le coût d’utilisation d’un PARKING ou d’une PARKING AREA pour une période donnée.\nParkingChargeBand – Element  Class. Name Type Card. Description    ::\u0026gt; ::\u0026gt; TimeStructureFactor ::\u0026gt; PARKING CHARGE BAND hérite de TIME STRUCTURE FACTOR (lui-même étant un PRICEABLE OBJECT).  « PK » id ParkingChargeBandIdType 1:1 Identifiant de la tranche horaire PARKING CHARGE BAND.  « enum » ParkingVehicleType ParkingVehicleEnum 0:1 Type de véhicule associé à cette tranche horaire PARKING CHARGE BAND.   MaximumStay xsd:duration 0:1 Durée (maximum, borne supérieur donc) du PARKING CHARGE BAND.\nParkingChargeBand.TimeUnitRef peut spécifier l'unité de temps : sans précision c’est la minute qui sera utilisée par défaut dans le profil.\n  « cntd » prices ParkingPrice 0:1 Prix de la tranche horaire PARKING CHARGE BAND.    Exemple de grille horaire \u0026lt;ParkingTariff id=\u0026#34;FR:75105:ParkingTariff:076:Qpark\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Tarif principal\u0026lt;/Name\u0026gt; \u0026lt;noticeAssignments\u0026gt; \u0026lt;NoticeAssignmentView\u0026gt; \u0026lt;Text\u0026gt;Gratuit pour les personnes \u0026amp;#xE0; mobilit\u0026amp;#xE9; r\u0026amp;#xE9;duite\u0026lt;/Text\u0026gt; \u0026lt;/NoticeAssignmentView\u0026gt; \u0026lt;/noticeAssignments\u0026gt; \u0026lt;ParkingUserType\u0026gt;allUsers\u0026lt;/ParkingUserType\u0026gt; \u0026lt;!--peut prendre des valeurs comme \u0026#34;registered-Disabled\u0026#34;--\u0026gt; \u0026lt;appliesTo\u0026gt; \u0026lt;ParkingRef ref=\u0026#34;FR:75105:Parking:076:Qpark\u0026#34;/\u0026gt; \u0026lt;!--Note: plusieurs Parkings peuvent partager la même tarification--\u0026gt; \u0026lt;/appliesTo\u0026gt; \u0026lt;parkingChargeBands\u0026gt; \u0026lt;ParkingChargeBand\u0026gt; \u0026lt;MaximumStay\u0026gt;PT1H\u0026lt;/MaximumStay\u0026gt; \u0026lt;prices\u0026gt; \u0026lt;TimeIntervalPrice id=\u0026#34;FR:TimeIntervalPrice:01:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Amount\u0026gt;4.4\u0026lt;/Amount\u0026gt; \u0026lt;/TimeIntervalPrice\u0026gt; \u0026lt;/prices\u0026gt; \u0026lt;/ParkingChargeBand\u0026gt; \u0026lt;ParkingChargeBand\u0026gt; \u0026lt;MaximumStay\u0026gt;PT2H\u0026lt;/MaximumStay\u0026gt; \u0026lt;prices\u0026gt; \u0026lt;TimeIntervalPrice id=\u0026#34;FR:TimeIntervalPrice:02:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Amount\u0026gt;7.7\u0026lt;/Amount\u0026gt; \u0026lt;/TimeIntervalPrice\u0026gt; \u0026lt;/prices\u0026gt; \u0026lt;/ParkingChargeBand\u0026gt; \u0026lt;ParkingChargeBand\u0026gt; \u0026lt;MaximumStay\u0026gt;PT3H\u0026lt;/MaximumStay\u0026gt; \u0026lt;prices\u0026gt; \u0026lt;TimeIntervalPrice id=\u0026#34;FR:TimeIntervalPrice:03:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Amount\u0026gt;12.1\u0026lt;/Amount\u0026gt; \u0026lt;/TimeIntervalPrice\u0026gt; \u0026lt;/prices\u0026gt; \u0026lt;/ParkingChargeBand\u0026gt; \u0026lt;ParkingChargeBand\u0026gt; \u0026lt;MaximumStay\u0026gt;PT4H\u0026lt;/MaximumStay\u0026gt; \u0026lt;prices\u0026gt; \u0026lt;TimeIntervalPrice id=\u0026#34;FR:TimeIntervalPrice:04:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Amount\u0026gt;16.5\u0026lt;/Amount\u0026gt; \u0026lt;/TimeIntervalPrice\u0026gt; \u0026lt;/prices\u0026gt; \u0026lt;/ParkingChargeBand\u0026gt; \u0026lt;ParkingChargeBand\u0026gt; \u0026lt;MaximumStay\u0026gt;P1D\u0026lt;/MaximumStay\u0026gt; \u0026lt;prices\u0026gt; \u0026lt;TimeIntervalPrice id=\u0026#34;FR:TimeIntervalPrice:05:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Amount\u0026gt;39.6\u0026lt;/Amount\u0026gt; \u0026lt;/TimeIntervalPrice\u0026gt; \u0026lt;/prices\u0026gt; \u0026lt;/ParkingChargeBand\u0026gt; \u0026lt;/parkingChargeBands\u0026gt; \u0026lt;/ParkingTariff\u0026gt; Exemple d’abonnement (basé sur le profil tarifaire) \u0026lt;ParkingTariff id=\u0026#34;FR:75105:ParkingTariff:077:Qpark\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Tarif abonnement\u0026lt;/Name\u0026gt; \u0026lt;appliesTo\u0026gt; \u0026lt;ParkingRef ref=\u0026#34;FR:75105:Parking:076:Qpark\u0026#34;/\u0026gt; \u0026lt;!-- Note: plusieurs Parkings peuvent partager la même tarification --\u0026gt; \u0026lt;/appliesTo\u0026gt; \u0026lt;/ParkingTariff\u0026gt; \u0026lt;UserProfile id=\u0026#34;FR-Tarif-Example:UserProfile:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;!-- tarif résident --\u0026gt; \u0026lt;Name\u0026gt;R\u0026amp;#xE9;sident\u0026lt;/Name\u0026gt; \u0026lt;Description\u0026gt;Profil r\u0026amp;#xE9;sident pour tarif r\u0026amp;#xE9;duit\u0026lt;/Description\u0026gt; \u0026lt;LocalResident\u0026gt;true\u0026lt;/LocalResident\u0026gt; \u0026lt;/UserProfile\u0026gt; \u0026lt;UserProfile id=\u0026#34;FR-Tarif-Example:UserProfile:002:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;!-- Plein tarif classique --\u0026gt; \u0026lt;Name\u0026gt;Non R\u0026amp;#xE9;sident\u0026lt;/Name\u0026gt; \u0026lt;Description\u0026gt;Profil non r\u0026amp;#xE9;sident\u0026lt;/Description\u0026gt; \u0026lt;LocalResident\u0026gt;false\u0026lt;/LocalResident\u0026gt; \u0026lt;/UserProfile\u0026gt; \u0026lt;UsageValidityPeriod version=\u0026#34;any\u0026#34; id=\u0026#34;FR-Tarif-Example:UsageValidityPeriod:001:LOC\u0026#34;\u0026gt; \u0026lt;ValidityPeriodType\u0026gt;seasonTicket\u0026lt;/ValidityPeriodType\u0026gt; \u0026lt;StandardDuration\u0026gt;P1M\u0026lt;/StandardDuration\u0026gt; \u0026lt;/UsageValidityPeriod\u0026gt; \u0026lt;!-- FARE TABLE --\u0026gt; \u0026lt;!-- Pour chaque cellule: Prix / ParkingTariff-UsageValidityPeriodRef-UserProfile --\u0026gt; \u0026lt;FareTable version=\u0026#34;any\u0026#34; id=\u0026#34;FR-Tarif-Example:FareTable:001:LOC\u0026#34;\u0026gt; \u0026lt;Name\u0026gt; Tarifs particuliers the Parking PATRIARCHES\u0026lt;/Name\u0026gt; \u0026lt;cells\u0026gt; \u0026lt;Cell version=\u0026#34;any\u0026#34; id=\u0026#34;FR-Tarif-Example:Cell:001:LOC\u0026#34; order=\u0026#34;1\u0026#34;\u0026gt; \u0026lt;ParkingPrice id=\u0026#34;lFR-Tarif-Example:ParkingPrice:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Tarif r\u0026amp;#xE9;sident\u0026lt;/Name\u0026gt; \u0026lt;Amount\u0026gt;232\u0026lt;/Amount\u0026gt; \u0026lt;/ParkingPrice\u0026gt; \u0026lt;PriceableObjectRef ref=\u0026#34;FR:75105:ParkingTariff:077:Qpark\u0026#34;/\u0026gt; \u0026lt;!-- Pour faire le lien avec le Parking --\u0026gt; \u0026lt;UserProfileRef version=\u0026#34;any\u0026#34; ref=\u0026#34;FR-Tarif-Example:UserProfile:001:LOC\u0026#34;/\u0026gt; \u0026lt;!-- reference vers \u0026#34;résident\u0026#34; --\u0026gt; \u0026lt;UsageValidityPeriodRef ref=\u0026#34;FR-Tarif-Example:UsageValidityPeriod:001:LOC\u0026#34;/\u0026gt; \u0026lt;/Cell\u0026gt; \u0026lt;Cell version=\u0026#34;any\u0026#34; id=\u0026#34;FR-Tarif-Example:Cell:002:LOC\u0026#34; order=\u0026#34;2\u0026#34;\u0026gt; \u0026lt;ParkingPrice id=\u0026#34;FR-Tarif-Example:Cell:002:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Tarif non r\u0026amp;#xE9;sident\u0026lt;/Name\u0026gt; \u0026lt;Amount\u0026gt;290\u0026lt;/Amount\u0026gt; \u0026lt;/ParkingPrice\u0026gt; \u0026lt;PriceableObjectRef ref=\u0026#34;FR:75105:ParkingTariff:077:Qpark\u0026#34;/\u0026gt; \u0026lt;!-- Pour faire le lien avec le Parking --\u0026gt; \u0026lt;UserProfileRef version=\u0026#34;any\u0026#34; ref=\u0026#34;FR-Tarif-Example:UserProfile:002:LOC\u0026#34;/\u0026gt; \u0026lt;!-- reference vers \u0026#34;non résident\u0026#34; --\u0026gt; \u0026lt;UsageValidityPeriodRef ref=\u0026#34;FR-Tarif-Example:UsageValidityPeriod:001:LOC\u0026#34;/\u0026gt; \u0026lt;/Cell\u0026gt; \u0026lt;!-- etc. --\u0026gt; \u0026lt;/cells\u0026gt; \u0026lt;/FareTable\u0026gt; Equipements de recharge et réapprovisionnement en carburant Les équipements de recharge et réapprovisionnement en carburant étant ciblé par le règlement Européen, ils sont succinctement présentés ici. La façon d’inclure les équipements dans un lieu (en l’occurrence un Parking) et décrite de façon détaillée dans le profil accessibilité.\nRefuellingEquipment – Element    Class. Name Type Card. Description     ::\u0026gt; ::\u0026gt; PlaceEquipment ::\u0026gt; REFUELLING EQUIPMENT hérite de PLACE EQUIPMENT   « PK » Id RefuellingEquipmentIdType 1:1 Identifiant du REFUELLING G EQUIPMENT.    TypeOfFuelAvailable FuelTypeEnum 1:1 Type de carburant disponible (inclus l’électrique).     VehicleChargingEquipment – Element    Class. Name Type Card. Description     ::\u0026gt; ::\u0026gt; PlaceEquipment ::\u0026gt; VEHICLE CHARGING EQUIPMENT hérite de PLACE EQUIPMENT   « PK » id VehicleChargingEquipmentId 1:1 Identifiant du VEHICLE CHARGING EQUIPMENT.    FreeRecharging xsd:boolean 0:1 Indique si la recharge est gratuite.    Reservation xsd:boolean 0:1 Indique si une réservation est nécessaire.    ReservationUrl xsd:anyURI 0:1 URL de réservation.     Note : si l’on souhaite décrire les équipements de recharge de de façon détaillée (types de prise, puissance, voltage, fabriquant, etc.), NeTEx dispose d’un ChargingEquipmentProfile qui n’est pas décrit ici.\nEntêtes NeTEx Note: les FRAMEs et entêtes NeTEx sont présentés dans le document éléments communs. Seules les spécificités de la partie \u0026ldquo;Parkings\u0026rdquo; sont présentées ici.\nPour rappel, la liste des fichiers d\u0026rsquo;un export NeTEx profil France est décrite dans Éléments Communs.\nUne GeneralFrame de type NETEX_PARKING est utilisée pour échanger la description des parkings dans le fichier \u0026ldquo;parking.xml\u0026rdquo;. À noter que la tarification des parkings dépend de le partie \u0026ldquo;Tarifs\u0026rdquo; du profil France et est attendue dans le fichier \u0026ldquo;fare.xml\u0026rdquo;. Les objets partagés du profil (par exemple Branding ou VehicleType) sont regroupés dans le fichier \u0026ldquo;resource.xml\u0026rdquo;.\nTypeOfFrame : type spécifique NETEX_PARKING Lorsqu\u0026rsquo;une FRAME a pour TypeOfFrame la valeur NETEX_PARKING, seuls les objets de premier niveau suivants sont autorisés :\n PARKING (contiendra par inclusion tous les autres objets comme PARKING AREAs, VEHICLE ENTRANCEs, etc.) PARKING BAY  Voici un exemple de cadre du fichier parking.xml :\n\u0026lt;?xml version=\u0026#34;1.0\u0026#34; encoding=\u0026#34;utf-8\u0026#34;?\u0026gt; \u0026lt;PublicationDelivery xmlns=\u0026#34;http://www.netex.org.uk/netex\u0026#34; version=\u0026#34;2.0:FR-NETEX-2.4\u0026#34;\u0026gt; \u0026lt;PublicationTimestamp\u0026gt;2026-02-17T00:00:00.0Z\u0026lt;/PublicationTimestamp\u0026gt; \u0026lt;ParticipantRef\u0026gt;Exemple\u0026lt;/ParticipantRef\u0026gt; \u0026lt;dataObjects\u0026gt; \u0026lt;GeneralFrame id=\u0026#34;exemple:GeneralFrame:NETEX_Parking-sample\u0026#34; version=\u0026#34;2.0:FR-NETEX-2.4\u0026#34;\u0026gt; \u0026lt;TypeOfFrameRef ref=\u0026#34;FR:TypeOfFrame:NETEX_PARKING\u0026#34; /\u0026gt; \u0026lt;members\u0026gt; \u0026lt;!-- Parking (contiendra par inclusion tous les autres objets comme PARKING AREAs, VEHICLE ENTRANCEs, etc.) ParkingBay --\u0026gt; \u0026lt;/members\u0026gt; \u0026lt;/GeneralFrame\u0026gt; \u0026lt;/dataObjects\u0026gt; \u0026lt;/PublicationDelivery\u0026gt; Modalités d’échange Une seule typologies d’échange est envisagées pour les parkings: un échange de fichier (sous quelque forme que ce soit : FTP, mail, etc.). Les mécanismes de sécurité et d’authentification seront gérés par le protocole d’accès au fichier. Par souci de compacités des échanges les fichiers seront compressés au format ZIP classique.\nL’échange par fichier est assez simple : le fichier est un fichier XML classique qui ne contiendra qu’un seul élément racine : PublicationDelivery (voir exemples en annexe).\nBibliographie AFIMB - groupe de travail Qualité des Données - Modèle d\u0026rsquo;arrêts partagé - Version 1.5\nEN 15531-1, Public transport - Service interface for real-time information relating to public transport operations - Part 1: Context and framework\nEN 15531-2, Public transport - Service interface for real-time information relating to public transport operations - Part 2: Communications infrastructure3\nEN 15531-3, Public transport - Service interface for real-time information relating to public transport operations - Part 3: Functional service interfaces4\nCEN/TS 15531-4, Public transport - Service interface for real-time information relating to public transport operations - Part 4: Functional service interfaces: Facility Monitoring\nCEN/TS 15531-5, Public transport - Service interface for real-time information relating to public transport operations - Part 5: Functional service interfaces - Situation Exchange\nRappel sur les objets des autres profils Introduction Le profil Parking n’est que l’un des profils Français de NeTEx : d\u0026rsquo;autre profils de NeTEx sont disponibles (réseau, horaire, tarif). Ils sont tous complémentaires les uns des autres (sans recouvrement) et s\u0026rsquo;appuient tous sur le document : NeTEx - Profil Français de NETEx: éléments communs. Il conviendra de se référer à ce document pour tous les éléments utilisés dans le présent document, et dont la structure n\u0026rsquo;est pas détaillée.\nToutefois, de façon à ce que ce document puisse être lu sans faire d’aller-retour entre les documents, cette annexe fournis les informations utiles au profil Parking, mais issues des autres profils de NeTEx. De nombreux objets présentés dans ce document héritent en effet d’objets présentés dans d’autres profils et il est indispensable de les connaître un minimum pour avoir une vue complète des possibilités offertes par chaque concept.\nLa figure ci-dessous (distribuée sur 3 pages) donne une vue complètement déployée de l’objet Parking et de tous les objets dont il hérite. Cette vue permet de visualiser en une seule fois l’ensemble des possibilités offertes par NeTEX. Elle peut être facilement obtenue à partir de l’XSD NeTEx en utilisant des outils comme Oxygen ou XML-Spy.\nXSD Parking\nProfil Arrêt Note : dans le contexte du profil Parking toutes les références aux LIEUx D’ARRÊT ci-dessous, issues du profil arrêt, sont a généraliséer et à comprendre comme s’adressant aussi aux PARKINGs (tout deux hérites des objets PLACE et SITE et possèdent donc des caractéristiques communes).\nAttributs de Place Place – Element (abstrait)  Class. Name Type Card. Description    ::\u0026gt; ::\u0026gt; Zone ::\u0026gt; PLACE hérite de ZONE (voir le document éléments communs).  « cntd » placeTypes TypeOfPlaceRef 0:*\n0:1\nspécial\n Cet attribut n'est utilisé que pour les LIEUx D'ARRÊT et les zones administratives (TOPOGRAPHIC PLACE), et il est alors obligatoire, et sa cardinalité est alors 1:1.\nPour le LIEU D'ARRET Codification permettant de distinguer les:\n LIEU D'ARRÊT MONOMODAL\nvaleur: monomodalStopPlace PÔLE MONOMODAL\nvaleur: monomodalHub LIEU D'ARRÊT MULTIMODAL\nvaleur: multimodalStopPlace  Type de zones administratives françaises (TOPOGRAPHIC PLACE), qui doit être cohérent avec les Topographic-PlaceType (voir A.2.7):\n RÉGION\nvaleur: region DÉPARTEMENT\nvaleur: department GROUPEMENT DE COMMUNES\nvaleur: urbanCommunity VILLE\nvaleur: town ARRONDISSEMENT\nvaleur: district  Pour le PARKING Codification permettant de préciser :\n Zone « Park\u0026amp;Ride »\nvaleur: parkAndRide (On ne l’utlise que pour qualifier une zone, PARKING AREA, particulière, la qualification globale du parking pouvant se faire par le ParkingType du Parking lui -même)     Attributs du AddressablePlace AddressablePlace – Element (abstrait)    Class. Nom Type Card. Description     ::\u0026gt; ::\u0026gt; ADDRESSABLE PLACE ::\u0026gt; ADDRESSABLE PLACE hérite de PLACE.    Url xsd:anyURI 0:1 Url d\u0026rsquo;information associée au lieu    Image xsd:anyURI 0:1 Image et photo du lieu (en ligne)    PostalAddress PostalAddress 0:1 Adresse postale    RoadAddress RoadAddress 0:1 Adresse sur voirie     Attributs du SiteElement SiteElement – Element (abstrait)  Class. Nom Type Card. Description    ::\u0026gt; ::\u0026gt; PLACE ::\u0026gt; SITE ÉLÉMENT hérite de ADDRESSABLE PLACE.  « cntd » AccessibilityAssessment AccessibilityAssessment 0:1 Information globale précisant le niveau d'accessibilité du LIEU D'ARRÊT, de la ZONE D'EMBARQUEMENT ou de l'ACCÈS.\nVoir le détail ci-dessous.\n  « cntd » AccessModes AccessModeEnum 0:* Liste des modes utilisables (il peut donc y en avoir plusieurs) pour accéder à ce LIEU D'ARRÊT (renseigné uniquement pour les LIEUx D'ARRÊT):\n foot: À pied bicycle : En vélo (il y a un garage à vélo ou une station de vélos partagés) boat : Bateau car : Voiture (il y a un parking, ou une station d'auto partagée) taxi : Taxi (il y a une borne taxi) shuttle : Navette (une navette dessert le lieu)  Note: ne pas confondre avec le mode principal du LIEU D'ARRÊT (on qualifie ici les façons possibles de se rendre au LIEU D'ARRÊT, par exemple \"je peux me rendre à la gare en vélo…\" sous-entendu, \"il y a bien un parking à vélo\"…)\n  « cntd » alternativeNames AlternativeName 0:* Nom(s) alternatif(s) (potentiellement multiple) du LIEU D'ARRÊT, de la ZONE D'EMBARQUEMENT ou de l'ACCÈS.\nVoir le détail dans le profil Éléments Communs.\n   CrossRoad MultilingualString 0:1 Identification du croisement (nom des rues de l'intersection) où se situe le LIEU D'ARRÊT, la ZONE D'EMBARQUEMENT ou l'ACCÈS..  Landmark MultilingualString 0:1 Nom d'un repère proche du LIEU D'ARRÊT, de la ZONE D'EMBARQUEMENT ou de l'ACCÈS (par exemple \"en face du café XXX\", \"juste après la bouche d'incendie\", etc.).   SiteElementPropertiesGroup ElementPropertiesGroup 0:1 Propriétés complémentaires de l’élément, voir ci-dessous..    SiteElementPropertiesGroup – Group (objet inclus)  Class. Name Type Card. Description     PublicUse PublicUseEnum 0:1 Indique par quel public le lieu est utilisable:\n disabledPubicOnly: Personnes handicapées uniquement authorisedPublicOnly: Personnes autorisées uniquement staffOnly: Réservé au personnel publicOnly: Réservé au public all: Tout public    Covered CoveredEnum 0:1 Indique si le lieu est couvert\n indoors: Intérieur outdoors: Extérieur covered: Couvert (extérieur) mixed: Mixte unknown: Information non connue    Gated GatedEnum 0:1 Indique si l'on accède au lieu par des portes :\n openArea: Accès ouvert gatedArea: Accès par porte unknown: Information non connue    Lighting LightingEnum 0:1 Indique si le lieu est éclairé :\n wellLit: Bien éclairé poorLit: Faiblement éclairé unlit: Non éclairé unknown: Information non connue     Attributs du Site Site – Element (abstrait)  Class. Nom Type Card. Description    ::\u0026gt; ::\u0026gt; SiteElement ::\u0026gt; SITE hérite de SITE ÉLÉMENT.  « FK » TopographicPlaceRef TopographicPlaceRef 0:1 Référence à la zone administrative à laquelle appartient le LIEU D'ARRÊT, la ZONE D'EMBARQUEMENT ou l'ACCÈS (il s'agira ici uniquement d'une zone administrative de type Ville ou Arrondissement: c'est la structure administrative elle-même qui décrira les inclusions dans les zones administratives \"supérieures\").   additionalTopographicPlaces topographicPlaceRefs 0 :* Un LIEU D'ARRÊT peut avoir des composants dans plusieurs communes d’où la cardinalité : ce champ permet de référencer toutes ces zones administratives (la précédente étant la principale).\nCet attribut n'est utilisé que pour les LIEUx D'ARRÊT\n   Locale Locale 0:1 Information locales liées au LIEU D'ARRÊT, ZONE D'EMBARQUEMENT ou ACCÈS comme le fuseau horaire, la langue, etc.\nVoir Profil Éléments Communs.\n  « FK » OrganisationRef OrganisationRef 0:1 Identifiant de l'exploitant du LIEU (référence une INSTITUTION).  « FK » ParentSiteRef SiteRef 0:1 Référence au LIEU D'ARRÊT \"contenant\" le présent LIEU. Cette liaison est contrainte en fonction de la spécialisation du LIEU D'ARRÊT:\n LIEU D'ARRET MONOMODAL : parent= LIEU D'ARRÊT MULTIMODAL ou POLE MONOMODAL POLE MONOMODAL : parent= LIEU D'ARRÊT MULTIMODAL LIEU D'ARRÊT MULTIMODAL = pas de parent Cet attribut n'est utilisé que pour les LIEUx D'ARRÊT   « cntd » levels Level 0:* Liste des niveaux (étages) du lieu d'arrêt. Ils sont identifiés par leur nom : cela peut être \"1\", \"A\", \"Banlieue\", etc.\nOn aura par exemple:\n\u0026lt;levels\u0026gt;  \u0026lt;levelRefref=\u0026quot;Banlieue\u0026quot;/\u0026gt;  \u0026lt;levelRefref=\u0026quot;GrandeLigne\u0026quot;/\u0026gt; \u0026lt;/levels\u0026gt; Cet attribut n'est utilisé que pour les LIEUx D'ARRÊT\n  « cntd » entrances Entrance 0:* Lien vers les entrées du LIEU (référence des ACCÈS)\nCet attribut n'est utilisé que pour les LIEUx D'ARRÊT\n    Attributs SiteComponent SiteComponent – Element (abstrait)  Class. Nom Type Card. Description    ::\u0026gt; ::\u0026gt; SiteElement ::\u0026gt; SITE COMPONENT hérite de SITE ÉLÉMENT.  « FK » SiteRef SiteRef 0:1\n1:1\n Pour une ZONE D'EMBARQUEMENT, il s'agit de l'identifiant du LIEU D'ARRÊT MONOMODAL dont dépend la ZONE D'EMBARQUEMENT.\nPour un ACCÈS il s'agit de l'identifiant du LIEU D'ARRÊT MONOMODAL, POLE MONOMODAL ou LIEU D'ARRÊT MULTIMODAL auquel mène l'ACCÈS.\nCet attribut est obligatoire dans le cadre du profil.\nNote : de plus, notament pour faciliter les conversions vers le profil Européen, on systématisera l’includion XML des SiteComponents dans les Sites.\n  « FK » LevelRef LevelRef 0:1 Niveau (étages) du lieu d'arrêt auquel se situe la ZONE D'EMBARQUEMENT ou l'ACCÈS. Il est identifié par son nom : cela peut être \"1\", \"A\", \"Banlieue\", etc.    Entrée Entrance – Element  Class. Nom Type Card. Description    ::\u0026gt; ::\u0026gt; SiteComponent ::\u0026gt; ENTRANCE hérite de SITE COMPONENT.  SITE COMPONENT GROUP PublicCode xsd:normalizedString 0:1 Code de l'accès connu du public (généralement un numéro ou une lettre)  Label xsd:normalizedString 0:1 Label associé à l’entrée (généralement lettre ou numéro).  EntranceType EntranceTypeEnum 0:1 Type codifié de l'accès :\n opening: Ouvert openDoor: Porte Ouverte door: Porte swingDoor: Porte battante revolvingDoor: Porte à tambour automaticDoor Porte automatique ticketBarrier: Portillon à ticket gate: Barrière other: autre   IsExternal xsd:boolean 0:1 Indique s'il s'agit d'un ACCÈS extérieur ou intérieur (via un centre commercial par exemple)  IsEntry xsd:boolean 0:1 Indique que c'est une entrée  IsExit xsd:boolean 0:1 Indique que c'est une sortie  Width LengthType 0:1 Largeur de l’entrèe.  Height LengthType 0:1 Hauteur de l’entrée.  EXTERNAL ENTRANCE GROUP DroppedKerbOutside xsd:boolean 0:1 Marche abaissée à l’entrée (à mettre à false pour indiquer une marche)    Zone administrative TopographicPlace – Element  Class. Nom Type Card. Description    ::\u0026gt; ::\u0026gt; Place ::\u0026gt; TOPOGRAPHIC PLACE hérite de PLACE.   IsoCode IsoSubdvisionCodeType 0:1 Code ISO 3166-2 permettant d'identifier un pays et ses subdivisions (voir http://fr.wikipedia.org/wiki/ISO_3166-2:FR )\nPar exemple :\nFR-Q = Haute-Normandie (région)\nFR-15 = Cantal (département)\n   Descriptor Descriptor 1:1 Description de la TOPOGRAPHIC PLACE.\nLe nom de la Zone Administrative est un des attributs de cette structure, ce qui explique son caractère obligatoire.\nNote: le nom peut aussi apparaître dans l'attribut name hérité de GroupOfEntities où il n'est pas obligatoire. Si les deux noms sont renseignés, ils doivent naturellement être identiques (si ce n'était pas le cas, celui obligatoire du Descriptor prévaut)\n   TopographicPlaceType TopographicTypeEnum 0:1 Classification de la zone administrative:\n region (RÉGION) area (utilisé pour DÉPARTEMENT en France) conurbation (utilisé pour GROUPEMENT DE COMMUNE) city (VILLE) quarter (niveau ARRONDISSEMENT) suburb (niveau VILLE) town (niveau VILLE) district (niveau ARRONDISSEMENT) village (niveau VILLE) hamlet (niveau VILLE) urbanCenter (niveau ARRONDISSEMENT) placeOfInterest (niveau ARRONDISSEMENT) other unrecorded    PostCode xsd:normalizedString 0:1 Code postal associé à la Zone Administrative (peut avoir une valeur spécifique à la zone et différente de celle de la commune d’appartenance).  « FK » CountryRef CountryEnum 0:1 Identifiant du Pays en respectant la norme ISO 3166-1 (voir: www.iso.org/iso/country_codes/iso_3166_code_lists.htm ).\nC'est le code Alpha-2 sur 2 caractères qui est utilisé ici.\n   otherCountries CountryRef 0:* Pour les Zone Administrative à cheval sur plusieurs pays  « FK » ParentTopographicPlaceRef TopographicPlaceRef 0:1 Référence la zone administrative dans laquelle est incluse celle-ci. Ce champ doit respecter les règles suivantes :\n• une RÉGION n'a pas de parent (voir CountryRef)\n• un DÉPARTEMENT est contenu dans une RÉGION\n• un GROUPEMENT DE COMMUNES est contenu dans un DÉPARTEMENT (ou éventuellement une région s'il est à cheval sur plusieurs DEPARTEMENTs)\n• une VILLE est contenue dans un DÉPARTEMENT (et PAS dans GROUPEMENT DE COMMUNES: voir containedIn plus bas)\n• un ARRONDISSEMENT est contenu dans VILLE\n   containedIn TopographicPlaceRef 0:* Ce champs est utilisé pour les VILLEs uniquement et permet d'indiquer que la VILLE fait aussi partie d'un GROUPEMENT DE COMMUNES).    Une Zone Administrative doit toujours avoir un nom, mais il n’est pas rare qu’il existe plusieurs lieux du même nom dans un pays (par exemple, il existe douze lieux appelées « Hausen » en Allemagne, et huit « Newports » au Royaume-Uni, etc.) ou dans des pays différents (il existe également plusieurs « Hausen » en Suisse et même « Paris, Texas »).\nAfin de distinguer les différentes instances de manière cohérente, un nom de qualificatif peut être spécifié pour une Zone Administrative en utilisant un élément TopographicPlaceDescriptor (par exemple, « Newport, Gwent », « Newport, Salop », etc.).\nTopographicPlaceDescriptor – Element  Class. Name Type Card. Description    ::\u0026gt; ::\u0026gt; VersionedChild ::\u0026gt; TOPOGRAPHIC PLACE DESCRIPTOR hérite de VERSIONED CHILD.   Name MultilingualString 1:1 Nom du descripteur   QualifierName MultilingualString 0:1 Nom utilisé pour distinguer le TOPOGRAPHIC PLACE d’autres lieux similaires portant le même nom. Ce texte ne doit pas être inclus dans le nom mais peut être ajouté par les applications en fonction du contexte.\nLe qualificatif doit être dans la même langue que le nom (Français pour le profil)\n    Véhicules Seul le SimpleVehicleType est présenté ici, car il est à priori suffisant pour les besoins du profil Parking (toutefois NeTEx propose aussi un VehicleType plus complet mais dont la vocation est plus orientée vers le transport en commun).\nSimpleVehicleType – Element    Class. Name Type Card. Description     ::\u0026gt; ::\u0026gt; TransportType ::\u0026gt; SimpleVehicleType inherits from TransportType   « PK » id SimpleVehicleTypeIdType 1:1 Identifier of SIMPLE VEHICLE TYPE.   « enum » RequiresLicence LicenceRequirementsEnum 0:1 Whether the means of transport requires a licence to use.    MinimumAge xsd:integer 0:1 Minimum age required to use vehicle.   « enum » VehicleCategory VehicleCategoryEnum 0:1 Category of vehicle.    Portable xsd:boolean 0:1 Whether the vehicle is portable, e.g., a fold up biker or scooter.     TransportType – Element    Class. Name Type Card. Description     ::\u0026gt; ::\u0026gt; DataManagedObject ::\u0026gt; TRANSPORT TYPE inherits from DATA MANAGED OBJECT.   « PK » id TransportTypeIdType 1:1 Identifier of TRANSPORT TYPE.    Name MultilingualString 0:1 Nom du TYPE DE VEHICULE.    Description MultilingualString 0:1 Description of TRANSPORT TYPE.   XGRP TransportTypePropertiesGroup xmlGroup 0:1 Elements describing the properties of a VEHICLE TYPE. See below.   « enum » TransportMode AllVehicleModesEnum 0:1 Mode of transport – see allowed values for MODE.    EuroClass xsd:normalizedString 0:1 Euroclasse du TYPE DE VEHICULE (normes européennes d\u0026rsquo;émission: http://fr.wikipedia.org/wiki/Normes_europ%C3%A9ennes_d%27%C3%A9mission).   « cntd » PassengerCapacity PassengerCapacity 0:1 Total passenger carrying capacity of VEHICLE TYPE.     TransportTypePropertiesGroup – Group  Class. Name Type Card. Description     SelfPropelled xsd:boolean 0:1 Indique si le TYPE DE VEHICULE est autonome, ou s'il nécessite une motrice ou un véhicule tracteur.  « enum » PropulsionType PropulsionTypeEnum 0:1 Type of Propulsion for VEHICLE TYPE. See allowed values below. +v1.2.2\n Combustion electric hybrid human electricAssist other   « enum » FuelType FuelTypeEnum 0:1 Type of Fuel of VEHICLE TYPE. See allowed values below.\n battery biodiesel diesel dieselBatteryHybrid electricContact ethanol hydrogen liquidGas tpg (Thermochemical Power Group) methane petrol petrolBatteryHybrid other none    MaximumRange DistanceType 0:1 Maximum range between refuelling.    Profil Eléments Communs Adresses Address – Element (objet inclus)    Class. Nom Type Card. Description     « FK » CountryRef CountryEnum 0:1 Code ISO 3166 du pays (deux caractères)    CountryName MultilingualString 0:1 Nom du pays     PostalAddress – Element (objet inclus)  Class. Nom Type Card. Description    ::\u0026gt; ::\u0026gt; Address ::\u0026gt; POSTAL ADDRESS hérite de ADDRESS.   HouseNumber xsd:normalizedString 0:1 Numéro du bâtiment sur la voie   BuildingName xsd:normalizedString 0:1 Nom du bâtiment   AddressLine1 xsd:normalizedString 0:1 Complément d'adresse hors numéro, type et nom de voie.   Street xsd:normalizedString 0:1 Nom et type de voie   Town xsd:normalizedString 0:1 Nom de la ville.   PostCode PostCodeType 0:1 Code Postal   PostCodeExtension xsd:normalizedString 0:1 Extension du code postal (avec éventuel cedex ou boite postale)   PostalRegion xsd:normalizedString 0:1 Code INSEE\nNOTE le code INSEE permet aussi de faire la liaison avec la ville ou l'arrondissement (en tant que zone administrative) d'appartenance.\nNOTE si l'on souhaite mieux formaliser la relation à la commune, l'Adresse Postale, la ZONE NeTEx dispose du \"ParentZoneRef\" que l'on peut utiliser à cet effet.\nChamp obligatoire pour les Parking\n    RoadAddress – Element (objet inclus)  Class. Nom Type Card. Description    ::\u0026gt; ::\u0026gt; Address ::\u0026gt; ROAD ADDRESS hérite de ADDRESS.   GisFeatureRef normalizedString  Identification de l'objet correspondant à la voie dans une base spatiale (type PostGIS par exemple) ou dans un SIG.\nCet attribut permettra par exemple d'établir le lien avec une base IGN, Open Street Map, NavTeq, Teleatlas, etc.\n   RoadNumber xsd:normalizedString 0:1 Nom de la voie sous forme codifiée (exemple: N20, A1, E11, D75, etc.)   RoadName xsd:normalizedString 0:1 Nom de la voie.   BearingDegrees xsd:integer 0:1 Orientation de la voie, en degrés (au niveau du LIEU d'ARRÊT, de la ZONE D'EMBARQUEMENT ou de l'ACCÈS).   OddNumberRange xsd:normalizedString 0:1 Plage de numéros impairs dans laquelle se situe le LIEU   EvenNumberRange xsd:normalizedString 0:1 Plage de numéros pairs dans laquelle se situe le LIEU\nNOTE si la parité, droite-gauche, n'est pas respectée, c'est la zone paire qui sera renseignée.\n    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.\nGroupOfEntities – Element (Abstrait)  Class. Nom Type Card. Description    ::\u0026gt; ::\u0026gt; DataManagedObject ::\u0026gt; GROUP OF ENTITies hérite de DATA MANAGED OBJECT.   Name MultilingualString 0:1\n1:1\n Nom du groupe d'entité (du LIEU D'ARRÊT, de la ZONE D'EMBARQUEMENT, de l'ACCÈS, etc.)\nAttribut rendu obligatoire dans le cadre de ce profil\n   ShortName MultilingualString 0:1 Nom court du groupe d'entité (du LIEU D'ARRÊT, de la ZONE D'EMBARQUEMENT, de l'ACCÈS, etc.)   Description MultilingualString 0:1 Texte libre de description  « FK » PurposeOfGroupingRef PurposeOfGroupingRef 0:1 But fonctionnel pour lequel des GROUPEMENTs d'éléments sont définis. La FINALITÉ DE GROUPEMENT peut être limitée à un ou plusieurs types d'un objet donné.\nLe champ PurposeofGroupingRef devra systématiquement valoir \"groupOfStopPlace\" pour les GROUPEs DE LIEUX D'ARRÊT.\nDans le cas des groupes de lignes (GROUP OF LINES, voir Profil Réseau) le PurposeofGroupingRef pourra être utilisé pour qualifier les lignes administratives en utilisant la valeur \"administrativeLine\"\n  « AK » PrivateCode PrivateCode 0:1 Code \"privé\" permettant de gérer une identification spécifique indépendante de l'identification partagée. Si plusieurs identifiants alternatifs sont nécessaires, on pourra recourir au keyList de DataManagedObject, mais dans cette hypothèse le champ PrivateCode devra impérativement être aussi renseigné (avec l'un des identifiants alternatifs).\nCe champ est utilisé de différente façon suivant le contexte. C'est un simple identifiant alternatif pour les LIEU D'ARRÊT, ZONE D'EMBARQUEMENT, GROUPE DE LIEU et ACCÈS.\nDans le cadre des zones administratives (LIEU TOPOGRAPHIQUE) ce code est utilisé de la façon suivante:\n Région : code NUTS Département : code NUTS Groupement de communes: code Postal Ville : code INSEE Arrondissement : code INSEE  Note: les codes NUTS peuvent être trouvés ici: https://eur-lex.europa.eu/eli/reg/2003/1059/2018-01-18\n  « ctd » (members) VersionOfObjectRef | GroupMember 0:1\nspécial\n Ce champ est apporté par GeneralGroupOfEntities et n'est utilisé que dans certains cas particuliers :\n Dans le cadre des GROUPEs DE LIEUX D'ARRÊT, et il est alors obligatoire. Il contient la liste des identifiants des membres des GROUPEs DE LIEUX D'ARRÊT (ce sont donc des identifiants de LIEU D'ARRÊT)     Point Point – Element (Abstrait)  Class. Nom Type Card. Description    ::\u0026gt; ::\u0026gt; DataManagedObject ::\u0026gt; POINT hérite de DATA MANAGED OBJECT.   Name MultilingualString 0:1 Nom du POINT.   Location Location 0:1\n1 :1\n Localisation du POINT (obligatoire dans le profil)  « » PointNumber xsd:normalizedString 0:1 Identifiant alternatif du point POINT.\nOn utilisera le champ PointNumber pour ordonner des points (par exemple les POINTs D’ARRÊT PLANIFIÉs d’une ligne que l’on veut ordonner sur une fiche horaire), avec la convention suivante :\n On privilégiera une valeur purement numérique pour ce champ (avec un classement classique du plus petit au plus grand) Si ce n’était pas le cas le classement sera réalisé de façon alphanumérique (et non alphabétique), aussi appelé classement naturel, en intégrant donc une reconnaissance de l’éventuelle partie numérique. (voir http://rosettacode.org/wiki/Natural_sorting par exemple)   « cntd » projections Projection 0:* Projections du POINT.\nLa PROJECTION n’est utilisée que pour permettre de mettre en lien l’offre de transport en commun et une description de l’infrastructure (route, rail, etc.). On référencera donc typiquement un jeu de données OSM, NavTeQ Here, etc.\n    Location Location – Element (abstrait)  Class. Nom Type Card. Description    « FK » srsName LocatingSystemNameType 0:1 Référentiel géographique: il s'appliquera aux Latitude et Longitude (permettant ainsi d'utiliser d'autres référentiels géodésiques que WGS84).\nÀ utiliser au format GML (ex urn:ogc:def:crs:EPSG::4326 pour WGS84, voir http://www.epsg.org et http://www.opengeospatial.org/ogcUrnPolicy )\n   Longitude LongitudeType 1:1 Latitude du centroïd (point \"central\" du lieu d'arrêt) – WGS84 par défaut (-180 à +180)   Latitude LatitudeType 1:1 Longitude du centroïd (point \"central\" du lieu d'arrêt) – WGS84 par défaut (-90 à +90)   Altitude AltitudeType 0:1 Altitude du centroïd (mètres au-dessus du niveau de la mer)   Coordinates CoordinateString gml:pos 0:1 Localisation dans un référentiel géographique quelconque (format ISO/OGC) exprimé sous forme d'une chaine de caractère, contenant éventuellement le référentiel de projection (si différent du champ suivant SrsName).\nExemple:\n\u0026lt;gml:possrsName=\u0026quot;urn:ogc:def:crs:EPSG::4326\u0026quot;\u0026gt;  -59.478340 -52.226578 \u0026lt;/gml:pos\u0026gt;   Precision xsd:decimal 0:1 Précision de localisation (en mètres).    Zone Zone – Element (Abstrait)  Class. Nom Type Card. Description    ::\u0026gt; ::\u0026gt; GroupOfPoints ::\u0026gt; ZONE hérite de GROUP OF POINTs (note : le GroupOfPoint n’apporte pas d’autres ajouts au GroupOfEntities que l’attribut members spécialisé pour ne référencer que des points).\nLe champ members n’est utilisé que dans le cas particulier du transport à la demande, pour permettre d’identifier les arrêts (POINT D’ARRÊT PLANIFIÉs) d’une zone dans le cas de TAD zonal avec arrêt.\n  « cntd » members PointRef 0:* Liste des POINT contenus dans la ZONE.  « cntd » Centroid Point 0:1 Point représentatif de la ZONE (LIEU D'ARRÊT, ZONE D'EMBARQUEMENT, LIEU TOPOGRAPHIQUE, ACCES, POINT D’ARRÊT PLANIFIÉ, etc.).\nCe point n'a pas à être le centre, ou le barycentre, de la zone, mais un point qui la localisera de façon satisfaisante (sur un fond de carte par exemple).\n   Gml:Polygon gml:Polygon 0:* Polygone de contour de la zone.\nC'est une séquence ordonnée de points représentant une surface fermée et permettant de décrire le contour géographique de la ZONE.\n  « cntd » projections Projection 0:* Liste des PROJECTIONs de la ZONE.\nLa PROJECTION n’est utilisée que pour permettre de mettre en lien l’offre de transport en commun et une description de l’infrastructure (route, rail, etc.). On référencera donc typiquement un jeu de données OSM, NavTeQ Here, etc.\n    DataManagedObject Le DataManagedObject permet l\u0026rsquo;attribution d\u0026rsquo;une version, des informations de responsabilité (et rôles associés) à une EntityInVersion ainsi qu\u0026rsquo;une ou plusieurs instances de ValidityCondition.\nDataManagedObject – Element (Abstrait)  Class. Nom Type Card. Description    ::\u0026gt; ::\u0026gt; EntityInVersion ::\u0026gt; DATA MANAGED OBJECT hérite de ENTITY IN VERSION.  « FK » responsibilitySetRef ResponsibilitySetIdType 1:1 Pointe les roles et responsabilités associés au LIEU D'ARRÊT, à la ZONE D'EMBARQUEMENT ou à l'ACCÈS (généralisable à tous les objets, voir le modèle en A.4.16).   KeyList KeyList 0:1 Ensemble de couples clé-valeur utilisé pour décrire les identifiants secondaires de l'objet (LIGNE, LIEU D'ARRÊT, ZONE D'EMBARQUEMENT, POINT D’ARRET PLANIFIÉ, COURSE, etc.): c’est-à-dire tel qu'il peut être identifié dans des systèmes tiers: billettique, information voyageur, etc. La clé permet de nommer l'identifiant (et donc de faire référence au système tiers), la valeur étant l'identifiant lui-même.\nCette identification servira principalement d'identification croisée, permettant au fournisseur de retrouver facilement, dans ses systèmes, l'origine de l'objet.\nLa liste des identifiants secondaires est spécifique à chaque fournisseur.\nVoir aussi PrivateCode du GroupOfEntities pour les identifiants alternatifs: les KeyList ne sont à utiliser que s'il y a plusieurs identifiants alternatifs, et si elles sont utilisées, le PrivateCode doit impérativement être aussi renseigné.\nIl est interdit, dans le profil, d’utiliser le système de clé/valeur pour décrire des informations qui pourraient être fournies avec des attributs NeTEx existants (même s’ils ne sont pas retenus par le profil).\n   BrandingRef BrandingRefStructure 0:1 Référence à une marque (comme par exemple Navigo, Destineo, OùRA, etc.).   alternativeTexts AlternativeText 0:* Additional Translations of text elements.    Entity – Element (Abstrait)  Class. Nom Type Card. Description     NameOfClass NameOfClass ::\u0026gt; Nom de la classe de l'ENTITÉ.  « PK » id ObjectIdType 1:1 Identifiant unique (et pérenne autant que possible) de l'objet.\nTous les objets métiers \"racine\" (c’est-à-dire les objets situés au niveau members des FRAME: voir Erreur ! Source du renvoi introuvable.) doivent impérativement être identifiés. Par contre les objets inclus (au sens XML) dans un un autre objet ne seront généralement pas identifiés (l'identification n'est toutefois pas interdite).\nCette remarque est valable pour la totalité des attributs du DataManagedObject (version, validité, etc. ne sont nécessaires que pour les objets racines).\n    EntityInVersion – Element (Abstrait)  Class. Nom Type Card. Description    ::\u0026gt; ::\u0026gt; Entity ::\u0026gt; ENTITY ON VERSION hérite de ENTITY.  « FK » dataSourceRef DataSourceIdType 0:1 Identifiant de la source des données (voir INSTITUTION pour la description détaillée d'une source).   created xsd:dateTime 0:1 Date et heure de création de l'ENTITÉ   changed xsd:dateTime 0:1 Date et heure de la dernière modification de l'ENTITÉ   modification ModificationEnum 0:1 Nature de la dernière modification:\n new (création) revise (mise à jour) delete (suppression)   « PK » version VersionIdType 0:1 Identifiant de version (généralement un numéro)   status VersionStatusEnum 0:1 Statut de la version:\n active (objet actif) inactive (objet non actif, de façon à pouvoir \"désactiver\" un objet pendant un certain temps sans pour autant le supprimer, par exemple pour un arrêt qui ne sera plus utilisé pendant quelques mois).   « FK » derivedFromObjectRef ObjectIdType 0:1 Identifiant d'une ENTITÉ dont celle-ci est dérivée.\nDans le contexte du profil, ce champ est utilisé uniquement pour lier des objets pour lesquels on a réalisé une variante fonctionnelle. Typiquement, dans le cas d'une ligne de substitution (voir Profil Réseau) on pourra utiliser le derivedFromObjectRef pour la relier à la ligne qu'elle remplace temporairement.\n  « FK » compatibleWithVersionRef VersionIdType 0:1 Cet attribut est utilisé uniquement pour les CADREs DE VERSION (VERSION FRAME).\nIndique alors la version de l'instance de CADRE DE VERSION avec laquelle cette version d'objet est compatible. Ce CADRE DE VERSION porte le même identifiant que celui du cadre impliqué dans l'échange courant, mais avec un numero de version différent.\n  (choice) validityConditions ValidityCondition 0:* CONDITIONs DE VALIDITÉ de l’ENTITÉ.  ValidBetween ValidBetweenStructure 0:* Optimisation : version simplifiée de CONDITIONs DE VALIDITÉ (simple période entre deux dates)    KeyList – Element (Abstrait)  Class. Nom Type Card. Description     typeOfKey xsd:normalizedString 0:1 Type de clé.\nSeule la valeur \"ALTERNATE_IDENTIFIER\" est reconnue dans le cadre du profil. Tout autre type de type de clé devra être ignoré (sans toutefois générer d'erreur).\n   Key xsd:normalizedString 1:1 Nom de la clé.   Value xsd:normalizedString 1:1 Valeur associée à la clé    ValidityCondition ValidityCondition – Element (objet inclus)  Class. Nom Type Card. Description    ::\u0026gt; ::\u0026gt; DataManagedObject ::\u0026gt; Inherits from DATA MANAGED OBJECT.\nL’héritage reste naturellement valable, mais aucun des attributs qu’il apporte ne sera utilisé.\n  « FK » ConditionedObjectRef ObjectRef 0:1 Référence de l’objet sur lequel porte la CONDITION DE VALIDITÉ.\nCet attribut n’est utilisé que si la condition de validité est fournie comme un objet indépendant au sein d’une FRAME (voir Erreur ! Source du renvoi introuvable.). Dans tous les autre cas (la CONDITION DE VALIDITÉ est dans l’arborescence XML d’un objet) c’est le contexte qui fournit cette information, et ce champ sera ignoré. On n’utilisera les conditions de validité comme un objet indépendant que pour pouvoir les référencer avec un WithConditionRef (champ suivant)\n  « FK » WithConditionRef ValidityConditionRef 0:1 Cet attribut permet de chaîner plusieurs CONDITIONs DE VALIDITÉ qui seront alors logiquement combinées par l’opérateur logique ET.\nOn pourra ainsi gérer une période combinée à des exclusions, combiner des périodes et des évènements déclencheurs, etc.\nPour la gestion des exceptions, on exprimera toujours une CONDITION DE VALIDITÉ « principale » et on y associera des exceptions par WithConditionRef et non l’inverse. Pour toutes les combinaisons on procédera de même si une CONDITION DE VALIDITÉ « principale » peut être identifiée.\n    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.)\nAvailabilityCondition – Element (objet inclus)  Class. Nom Type Card. Description    ::\u0026gt; ::\u0026gt; ValidityCondition ::\u0026gt; AVAILABILITY CONDITION hérite de VALIDITY CONDITION.   FromDate xsd:dateTime 0:1 Date et heure de début de validité (inclusif)   ToDate xsd:dateTime 0:1 Date et heure de fin de validité (inclusif)   IsAvailable xsd:boolean 1:1 Indique si la CONDITION DE VALIDITÉ correspond à une disponibilité (VRAI) ou une indisponibilité (FAUX).\nCe champ sert principalement à exprimer les exceptions (par exemple : sauf le 1er avril) par combinaison de CONDITIONs DE VALIDITÉ avec WithConditionRef (voir plus haut).\n  « FK » dayTypes DayTypeRef 0:* TYPE DE JOUR pendant lesquels la CONDITIONs DE VALIDITÉ s’applique.\nOn n’utilisera pas simultanément dayTypes et operatingDays dans une même CONDITION DE VALIDITÉ.\n  « cntd » timeBands TimeBand 0:* TRANCHEs HORAIREs pendant lesquelles la CONDITIONs DE VALIDITÉ s’applique.\nPermet essentiellement d’exprimer les heures d’ouverture.\n  « cntd » operatingDays OperatingDay 0:* Jours d’exploitation pendant lesquels la CONDITIONs DE VALIDITÉ s’applique.\nOn n’utilisera pas simultanément dayTypes et operatingDays dans une même CONDITION DE VALIDITÉ.\n    ValidityTrigger – Element (objet inclus)  Class. Nom Type Card. Description    ::\u0026gt; ::\u0026gt; ValidityCondition ::\u0026gt; VALIDITY TRIGGER hérite de VALIDITY CONDITION.  « FK » TriggerObjectRef ObjectRef 0:1 Référence (identifiant) de l’objet déclencheur de la validité.\nDe façon pratique, plutôt que de réel identifiant d’objet, on utilisera ici des valeurs codifiées dont les valeurs possibles seront précisées dans les spécifications d’interface du système producteur. Par convention on utilisera autant que possible les codes reason, subreason et PublicEvent proposés par le service SIRI Situation Exchange.\n    ValidBetween – Element (objet inclus)  Class. Nom Type Card. Description     FromDate xsd:dateTime 0:1 Date et heure de début de validité (inclusif)\nLe FromDate est obligatoire dans le cadre du profil (le ToDate ne l’est pas, et s’il n’est pas rempli, la validété débute au FromDate sans limite de fin.   ToDate xsd:dateTime 0:1 Date et heure de fin de validité (inclusif)    ResponsibilitySet ResponsibilitySet – Element    Class. Name Type Card. Description     ::\u0026gt; ::\u0026gt; DataManagedObject ::\u0026gt; RESPONSIBILITY SET hérite de DATA MANAGED OBJECT.   « cntd » roles ResponsibilityRoleAssignment 1:* AFFECTATIONs de ROLE constituant l\u0026rsquo;ENSEMBLE DE RESPONSABILITÉ.     ResponsibilityRoleAssignment – Element (objet inclus)  Class. Nom Type Card. Description    ::\u0026gt; ::\u0026gt; VersionedChild  RESPONSIBILITY ROLE hérite de VERSIONED CHILD.\nNon utilisé quand inclus comme roles de ResponsabilitySet (l’inclusion est la solution retenue par le profil)\n   Description MultilingualString 0:1 Description textuelle du rôle  « PK » DataRoleType DataRoleTypeEnum 0:1 Rôle(s) attribué(s) dans la gestion des données. Les valeurs possibles sont :\n collects validates aggregates distributes redistributes creates   « PK » StakeholderRoleType StakeholderRoleTypeEnum 0:1 Rôle(s) opérationel(s) attribué(s). Les valeurs possibles sont :\n planning operation control reservation entityLegalOwnership fareManagement securityManagement dataRegistrar other    TypeOfResponsibilityRoleRef TypeOfResponsibility RoleRef  Référence à un type de responsabilité.\nOn utilisera notamment ce champ pour référencer un type de contrat quand cela est nécessaire.\n  « FK » ResponsibleOrganisationRef OrganisationRef 0:1 Référence l'institution concernée  « FK » ResponsibleAreaRef AdministrativeZoneRef 0:1 Référence la zone administrative concernée    Notes Notice – Element  Class. Nom Type Card. Description    ::\u0026gt; ::\u0026gt; DataManagedObject ::\u0026gt; NOTICE hérite de DATA MANAGED OBJECT.   Name MultilingualString 0:1 Nom de la NOTE.   Text MultilingualString 0:1 Texte de la NOTE  « AK » PublicCode xsd:normalizedString 1:1 Code publique de la NOTE (numéro de renvoi sur la fiche horaire par exemple)  « FK » TypeOfNoticeRef TypeOfNoticeRef 1:1 Type de NOTE.\nOn pourra ainsi catégoriser les NOTEs, par exemple:\n Exception de circulation (sauf…) Restriction de circulation (ne circule que …..) Etc.  Ces codes sont ouverts et sont définis par le producteur des données qui en précisera les valeurs possibles dans sa spécification d'interface.\n   CanBeAdvertised   Dans le cadre des profils NeTEx, toutes les notes sont à vocation d'information voyageur et donc publiques.  « cntd » variants DeliveryVariant 0:* VARIANTEs DE DIFFUSION pour la note (rédaction adaptée à différents type de médias).    Le tableau ci-dessous présente l\u0026rsquo;affectation de NOTE: seul les deux attributs retenus y sont présentés (l\u0026rsquo;affectation est très paramétrable, mais la grande majorité des attributs ne sont pas retenus dans le profil).\nLes NoticeAssignments doivent être intégré en ligne à l\u0026rsquo;é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.\nNotice Assignment – Element   Class. Name Type Card. Description    ::\u0026gt; ::\u0026gt; DataManagedObject ::\u0026gt; NOTICE ASSIGNMENT inherits from DATA MANAGED OBJECT.  « PK » id TypeOfNoticeAssignmentIdType 1:1 Identifiant du NOTICE ASSIGNMENT.  « FK » a NoticeRef NoticeRef 0:1 Reference à une NOTE   c Notice Notice 0:1 Description de la NOTE elle même.\nOn préférera toujours Notice à NoticeRef (utilisez uniquement NoticeRef pour les NOTEs partagés).\n  « FK » NoticedObjectRef VersionOfObjectRef 0:1 Objet auquel la NOTE est associée. Si donné par le contexte peut être omis.  « FK » StartPointInPatternRef PointInSequenceRef 0:1 POINT à partir duquel la NOTE devient applicatble (dans un PARCOURS).  « FK » EndPointInPatternRef PointInSequenceRef 0:1 POINT à partir duquel la NOTE n’est plus applicatble (dans un PARCOURS).    Accessibilité Les informations concernant l\u0026rsquo;ACCESSIBILITÉ sont utilisées de la même façon pour les PARKINGs, les LIEUx D\u0026rsquo;ARRÊT, les LIGNEs et les COURSEs. L’information d’accessibilité présentée ici 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.). Il s\u0026rsquo;agit d\u0026rsquo;une information générique permettant d\u0026rsquo;indiquer si un SITE permet une accessibilité de type:\n WheelchairAccess: accessible en fauteuil roulant StepFreeAccess: l\u0026rsquo;accès est possible sans franchissement de marche ou d\u0026rsquo;escalier EscalatorFreeAccess: l\u0026rsquo;accès est possible sans utiliser d\u0026rsquo;escalator LiftFreeAccess: l\u0026rsquo;accès est possible sans utiliser d\u0026rsquo;ascenseur AudibleSignalsAvailable: une signalétique auditive est disponible VisualSignsAvailable: une signalétique visuelle est disponible  Cela correspond, dans les grandes lignes aux principaux pictogrammes d\u0026rsquo;accessibilité classiquement rencontrés.\nAccessibilityAssessment – Element (objet inclus)  Class. Nom Type Card. Description    ::\u0026gt; ::\u0026gt; DataManagedObject ::\u0026gt; ACCESSIBILITY ASSESSMENT hérite de DATA MANAGED OBJECT.   MobilityImpairedAccess AccessibilityEnumeration 1:1 Indication globale d'accessibilité (de la LIGNE ou du LIEU).\nIl peut valoir true (accessible), false (non accessible), partial ou unknown\n  « cntd » limitations AccessibilityLimitation 0:1 Limitations d'accessibilité   Comment MultilingualString 0:1 Commentaire complémentaire sur l'accessibilité.\nCe champ a pour vocation à compléter, en termes d'information voyageur, l'information générale de la structure AccessibilityLimitation. Il a donc pour vocation à être affiché avec les informations d'accessibilité.\n    NOTE L\u0026rsquo;attribut MobilityImpairedAccess n\u0026rsquo;a pas été retenu dans le cadre des travaux sur le modèle d\u0026rsquo;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\u0026rsquo;il peut prendre étant true/false/unknow/partial, il est recommandé (pour des raisons de cohérence) que sa valeur soit:\n 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  AccessibilityLimitation – Element (objet inclus)    Class. Nom Type Card. Description      WheelchairAccess LimitationStatusEnum 1:1 Indique si l\u0026rsquo;accès est possible sans fauteuil roulant (codification: true/false/unknow/partial).    StepFreeAccess LimitationStatusEnum 0:1 Indique si l\u0026rsquo;accès est possible sans franchissement de marche ou d\u0026rsquo;escalier (codification: true/false/ unknow/partial).    EscalatorFreeAccess LimitationStatusEnum 0:1 Indique si l\u0026rsquo;accès est possible sans utiliser d\u0026rsquo;escalator (codification: true/false/unknow/ partial).    LiftFreeAccess LimitationStatusEnum 0:1 Indique si l\u0026rsquo;accès est possible sans utiliser d\u0026rsquo;ascenseur (codification: true/false/unknow/ partial).    AudibleSignsAvailable LimitationStatusEnum 0:1 Indique si une signalétique auditive est disponible (codification: true/false/unknow/partial).    VisualSignsAvailable LimitationStatusEnum 0:1 Indique si une signalétique visuelle est disponible (codification: true/false/unknow/partial).     Chaque fois que pour LimitationStatus la valeur \u0026ldquo;partial\u0026rdquo; est utilisée, une \u0026ldquo;ValidityCondition-\u0026gt; Description\u0026rdquo; (dans l’objet AccessibilityAssessment) doit être fournie en conséquence pour expliquer pourquoi l\u0026rsquo;accessibilité n\u0026rsquo;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.\nNom alternatif AlternativeName – Element  Class. Nom Type Card. Description    « FK » NamedObjectRef VersionOfObjectRef 0:1 Référence de l’objet pour lequel on fourni un nom alternatif.\nCet attribut n’est utilisé que si le nom alternatif est fourni comme un objet indépendant au sein d’une FRAME (voir Erreur ! Source du renvoi introuvable.). Dans tous les autre cas (le NOM ALTERNATIF est dans l’arborescence XML d’un objet) c’est le contexte qui fournit cette information, et ce champ sera ignoré.\n   Lang Language 0:1 Langue utilisée pour ces alias (codification RFC 1766)   NameType NameTypeEnum 0:1 Type de nom alternatif:\n alias: Alias translation: Traduction other: Autre  Il existe deux autres possibilités qui ne sont pas utilisées dans le cadre du profil: copy et label\n   TypeOfName NormalizedString 0:1 Description de type de nom (ex: \" Libellé de la synthèse vocale \")   Name MultilingualString 1:1 Texte du nom alternatif   ShortName MultilingualString 0:1 Version courte du nom alternatif   Abbreviation MultilingualString 0:1 Abréviation du nom alternatif   QualifierName MultilingualString 0:1 Texte utilisé pour qualifier le nom (\"gare de\", \"mairie de\", etc.)    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\u0026rsquo;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.\nNote: 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).\nDans le profil, AlternativeText sera toujours utilisé comme balise incluse (et non comme élément racine).\nAlternativeText – XML Element  Class. Nom Type Card. Description    ::\u0026gt; ::\u0026gt; VersionedChild ::\u0026gt; AlternativeText hérite de VERSIONED CHILD.  « PK » attributeName xsd:NCName 0:1 Nom de l'attribut de texte pour lequel il s'agit du texte de remplacement. Doit être un nom d'attribut existant.  « PK » useForLanguage xsd:language 0:1 Langage utilisé pour cette variante\n« fr » n’est pas accepté dans le profil, AlternativeText étant réservé aux traductions.\n   Text MultilingualString (Language + Text) 1:1 Variante du texte original, dans le langage spécifié    Type de Valeur Les types de valeur sont utiles pour préciser et personnaliser toutes les codifications ouvertes (TypeOfXxxxx, comme les TypeOfNoticeRef par exemple).\nTypeOfValue – Element (abstrait)    Class. Nom Type Card. Description     ::\u0026gt; ::\u0026gt; DataManagedObject ::\u0026gt; TYPE OF VALUE hérite de DATA MANAGED OBJECT.    Name MultilingualString 0:1 Nom du TYPE DE VALEUR.    Description MultilingualString 0:1 Description du TYPE OF VALUE.    Image anyURI 0:1 Image associée au TYPE OF VALUE.    Url anyURI 0:1 URL associée au TYPE OF VALUE.     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.).\nPresentation – Type (objet inclus)    Class. Name Type Card. Description      Colour ColourValue 0:1 Couleur (format RVB)    ColourName xsd:normalizedString 0:1 Nom de la couleur    BackGroundColour ColourValueType 0:1 Valeur RVB de la couleur de fond (par exemple la couleur de la ligne de transport)    BackgroundColourName xsd:String 0:1 Nom de la couleur de fond dans le ColourSystem.    TextColour ColourValue 0:1 Couleur du texte (format RVB)    TextColourName xsd:normalizedString 0:1 Nom de la couleur du texte    TextFont xsd:normalizedString 0:1 Identifiant de la police de caractère    TextFontName xsd:normalizedString 0:1 Nom de la police de caractère    InfoLink InfoLink 0:1 URL d\u0026rsquo;un élément graphique de représentation (généralement une icône).    ColourSystem xsd:String 0:1 Nom du système de couleur utilisé pour le nommage: par exemple RAL, https://en.wikipedia.org/wiki/RAL_colour_standard, DIN 6164 http://www.dtpstudio.de/atlas/farbsysteme/DIN%206164_bs00_3.htm, Pantone (attention Pantone est une classification commerciale), etc.     Branding Le Branding corresponf aux informations permettant la descriptrion des marques.\nBranding – Element (objet inclus)    Class. Nom Type Card. Description     ::\u0026gt; ::\u0026gt; DataManagedObject ::\u0026gt; BRANDING hérite de TYPE OF VALUE.    Presentation PresentationStructure 0:1 Iinformations de graphisme et de style de représentation associés à la marque.     Institutions (exploitants) Organisation et GeneralOrganisation – Element  Class. Nom Type Card. Description    ::\u0026gt; ::\u0026gt; DataManagedObject ::\u0026gt; ORGANISATION hérite de DATA MANAGED OBJECT.  « AK » PublicCode xsd:normalizedString 0:1 Identifiant (code) public de l'INSTITUTION (exemples: STIF, SNCF, etc.)  « AK » CompanyNumber xsd:normalizedString 0:1 Numéro d'enregistrement de l'institution(type code transporteur affecté par l'AO, NAO de la norme 99-502 pour les AOT, etc.)\nNuméro SIRET (champ obligatoire) pour les exploitants et propriétaire de parkings.\n   Name xsd:normalizedString 0:1 Nom de l'organisation   ShortName MultilingualString 0:1 Nom court de l'ORGANISATION   LegalName MultilingualString 0:1 Nom légal de l'ORGANISATION  « cntd » alternativeNames AlternativeName 0:* Nom alternative pour l’ORGANISATION.\nNote: les éventuelles traductions utiliseront AlternativeText et non alternativeNames.\n   Description MultilingualString 0:1 Texte descriptif associé à l'INSTITUTION.   ContactDetails ContactDetails 0:1 Contact details for ORGANISATION for public use.  « FK » OrganisationType TypeOfOrganisationEnum 0:1\n1:1\n Type d'organisation codifié:\n authority : Autorité organisatrice operator : Exploitant railOperator : Exploitant Ferré railFreightOperator : Exploitant fret statutoryBody : Collectivité facilityOperator : Société de service travelAgent : Agence de voyage servicedOrganisation : Etablissement de service public other : Autre   « cntd » parts OrganisationPart 0:* Ensemble des entités constituant ou faisant partie de l'INSTITUTION (UNITÉ ORGANISATIONELLE ou DÉPARTEMENT).\nSeules les UNITÉs ORGANISATIONELLEs seront utilisées dans le cadre des profils NeTEx.\n    ContactDetails – Element (objet inclus)    Class. Nom Type Card. Description      ContactPerson xsd:normalizedString 0:1 Nom de la personne de contact.    Email EmailAddressType 0:1 Email de contact au format ISO.    Phone PhoneNumberType 0:1 Numéro de téléphone de contact    Fax PhoneNumberType 0:1 Numéro de fax    Url xsd:anyURI 0:1 Site web de contact et d\u0026rsquo;information    FurtherDetails xsd:string 0:1 Information en texte libre     Responsabilités ResponsibilitySet – Element    Class. Name Type Card. Description     ::\u0026gt; ::\u0026gt; DataManagedObject ::\u0026gt; RESPONSIBILITY SET hérite de DATA MANAGED OBJECT.   « cntd » roles ResponsibilityRoleAssignment 1:* AFFECTATIONs de ROLE constituant l\u0026rsquo;ENSEMBLE DE RESPONSABILITÉ.     ResponsibilityRoleAssignment – Element (objet inclus)  Class. Nom Type Card. Description    ::\u0026gt; ::\u0026gt; VersionedChild  RESPONSIBILITY ROLE hérite de VERSIONED CHILD.\nNon utilisé quand inclus comme roles de ResponsabilitySet (l’inclusion est la solution retenue par le profil)\n   Description MultilingualString 0:1 Description textuelle du rôle  « PK » DataRoleType DataRoleTypeEnum 0:1 Rôle(s) attribué(s) dans la gestion des données. Les valeurs possibles sont :\n collects validates aggregates distributes redistributes creates   « PK » StakeholderRoleType StakeholderRoleTypeEnum 0:1 Rôle(s) opérationel(s) attribué(s). Les valeurs possibles sont :\n planning operation control reservation entityLegalOwnership fareManagement securityManagement dataRegistrar other    TypeOfResponsibilityRoleRef TypeOfResponsibility RoleRef  Référence à un type de responsabilité.\nOn utilisera notamment ce champ pour référencer un type de contrat quand cela est nécessaire.\n  « FK » ResponsibleOrganisationRef OrganisationRef 0:1 Référence l'institution concernée  « FK » ResponsibleAreaRef AdministrativeZoneRef 0:1 Référence la zone administrative concernée    Profil Réseau Site Connection Les correspondances entre sites permettent de créer simplement des relations entre LIEUX D\u0026rsquo;ARRÊT et les Points Of Interest (POI) sans avoir à descendre au niveau du NAVIGATION PATH (détail du cheminement piéton, dont on ne fera ici qu\u0026rsquo;une description minimale permettant d\u0026rsquo;indiquer la présence des principaux équipements, comme les ascenseurs, etc.). La structure est la même que pour les CORRESPONDANCEs, avec une spécialisation des extrémités et la possibilité de faire référence à un NAVIGATION PATH.\nCette structure permet aussi de caractériser de façon un peu plus détaillée les cheminements accès (STOP PLACE ENTRANCE) vers ZONE D\u0026rsquo;EMBARQUEMENT (QUAY).\nSiteConnection – Element  Class. Name Type Card. Description    ::\u0026gt; ::\u0026gt; Transfer ::\u0026gt; SITE CONNECTION hérite de TRANSFER.  « cntd » From SiteConnectionEnd 0:1 Origine du lien entre sites  « cntd » To SiteConnectionEnd 0:1 Fin du lien entre sites   navigationPaths navigationPaths 0:1 Description du cheminement utilisé pour cette correspondance.\nDans le cadre du Profil Réseau, le NAVIGATION PATH n'est utilisé que pour indiquer de façon générale les contraintes d'accessibilité du cheminement (champs AccessFeatureList et NavigationType). La description complète et détaillée du NAVIGATION PATH n'interviendra que dans un profil dédié.\n    SiteConnectionEnd – Element (objet inclus)   Class. Name Type Card. Description     ScheduledStopPointRef   On limite dans le profil le SITE CONNECTION aux correspondances entre sites (LIEU D'ARRÊT, PARKING, POI) de façon à simplifier l'analyse des données et éviter toute possible confusion sémantique.  Choice StopPlaceRef StopPlaceRef 0:1 Reference to destination STOP PLACE of SITE CONNECTION.   Choice QuayRef QuayRef 0:1 Référence à une ZONE D'EMBARGEMENT (voir profil NeTEx Arrêt)   StopPlaceEntranceRef StopPlaceEntranceRef 0:1 Référence à une entrée (entrée à utiliser pour cette correspondance)\n(voir profil NeTEx Arrêt)\n   PointOfInterestEndGroup PointOfInterestEndGroup 0:1 Eléments pour identifier un POI à la l’extrémité d’un SITE CONNECTION.\nOn pourra utilisera PointOfInterestRef avec une référence externe.\nNote: la valeur de ce champ sera précisée quand on disposera d'un profil pour les POIs.\n   ParkingEndGroup ParkingEndGroup 0:1 Eléments pour identifier un PARKING à l’extrémité d’un SITE CONNECTION.\nOn utilisera PakingRef avec une référence externe.\nNote: la valeur de ce champ sera précisée quand on disposera d'un profil pour les PARKINGs.\n    EXEMPLE XML\nL’exemple suivant illustre l’utilisation de références à des POI externes, la première provenant d’OSM en France et la seconde d’INSPIRE en Slovaquie. Notez que l’attribut versionRef est obligatoire pour les objets externes (la valeur peut être “any” si la version est inconnue ou le numéro de version réel du POI s’il est connu).\n\u0026lt;PointOfInterestRef ref=“FR_OSM_Poi:node:55711945” versionRef=“any” /\u0026gt; \u0026lt;PointOfInterestRef ref=“SK_INSPIRE_Poi:SK.SOPSK.SKUEV0319” versionRef=“any” /\u0026gt; Équipements, cheminements et accessibilité Précision pour l’accessibilité des places\n  Localisation de la place Bay.centroid.location pour un ponctuel\nBay.Polygon.exterior pour une surface\n  Type de stationnement\n(longitudinal à droite, longitudinal à gauche, épi, perpendiculaire)\n Par défaut Perpendiculaire en Parking d’ouvrage.\nSi ce n’est pas le cas le préciser dans ParkingArea.BayGeometry\n  Type de sortie ( classique / classique + sortie arrière / classique + sortie latérale / classique + arrière + latérale) Semble plus lié aux véhicules en fonction des dimensions de la place : au niveau du parking lui-même l’ensemble de options sont possibles (donc classique + arrière + latérale)  Dimension A (longueur de la place) Bay.Length  Dimension B (largeur de la place) Bay.Width  Dimension C (largeur trottoir) Non applicable en Parking d’ouvrage (information dans Bay.Description si nécessaire)  Marquage au sol / panneau / commentaire Bay.facilities.AccessibilityAssesment.AccessibilityLimitation.VisualSignsAvailable = true/false\nPour le commentaire\nBay.Description\n  Date de création de l’emplacement Attribut created    Note : Bay.AccessibilityAssesment ou ParkingArea.AccessibilityAssesment peuvent aussi préciser les caractéristiques d’accessibilité de la place ou de la zone, et l’ensemble du Profil Accessibilité est disponible pour un Parking (services, équipements, cheminements, etc.).\nServices disponibles FacilitySets\nEquipement et Cheminenment Profil Tarif FarePrice – Element    Class. Name Type Card. Description     ::\u0026gt; ::\u0026gt; VersionedChild ::\u0026gt; FARE PRICE inherits from VERSIONED CHILD   « PK » id FarePriceIdType 1:1 Identifier of FARE PRICE.    Name MultilingualString 0:1 Name of PRICE.    Description MultilingualString 0:1 Description of PRICE. +v1.1    PrivateCode PrivateCode 0:1 External identifier of PRICE. +v1.1    StartDate xsd:date 0:1 Start date for PRICE validity.    EndDate xsd:date 0:1 End date for PRICE validity.    Amount AmountType 0:1 Price in a specified currency.    Currency CurrencyType 0:1 Currency ISO 4217 code (This in an optimization to allow PRICE UNITs to be omitted).   « FK » PriceUnitRef PriceUnitRef 0:1 Reference to a PRICE UNIT; may be a currency.    Units xsd:decimal 0:1 Amount in designated unit.   « FK » PricingServiceRef PricingServiceRef 0:1 Reference to a PRICE SERVICE which can provide / provided price.   XGRP FarePriceCalculationGroup xmlGroup 0:1 Elements governing the calculation of prices.    Ranking xsd:integer 0:1 Relative ranking of price relative to other prices.     TariffDescriptionGroup – Group    Class. Name Type Card. Description      Name MultilingualString 0:1 Name of TARIFF.   « cntd » alternativeNames AlternativeName 0:* Alternative names for TARIFF.    Description MultilingualString 0:1 Description of TARIFF.   « cntd » noticeAssignments NoticeAssignment 0:* NOTICE ASSIGNMENTs for TARIFF.   « cntd » documentLinks InfoLink 0:* Links for documents associated with TARIFF.    TariffOrganisationGroup – Group    Class. Name Type Card. Description     « FK » OrganisationRef (OrganisationRef) 0:1 ORGANISATION to which TARIFF applies.   « FK » GroupOfOrganisationsRef GroupOfOrganisationsRef 0:1 GROUP OF ORGANISATIONs to which TARIFF applies.     TariffTimeGroup – Group    Class. Name Type Card. Description     « FK » TimeUnitRef TimeUnitRef 0:1 Reference to TIME UNIT for TARIFF.   « cntd » timeIntervals TimeInterval 0:* TIME INTERVALs associated with TARIFF.   « cntd » timeStructureFactors TimeStructureFactor 0:* TIME STRUCTURE FACTORs associated with TARIFF.     TariffQualityGroup – Group    Class. Name Type Card. Description     « cntd » qualityStructureFactors QualityStructureFactor 0:* QUALITY STRUCTURE FACTORs associated with TARIFF.     TimeInterval – Element  Class. Name Type Card. Description    ::\u0026gt; ::\u0026gt; FareInterval ::\u0026gt; TIME INTERVAL inherits from FARE INTERVAL.  « PK » id TimeIntervalIdType 1:1 Identifier of TIME INTERVAL.   StartTime xsd:time 0:1\n1 :1 Start of TIME INTERVAL.   EndTime xsd:time 0:1\n1 :1 End of TIME INTERVAL.   DayOffset DayOffsetType 0:1 Day offset of end time from start time.   Duration xsd:duration 0:1 Interval expressed as duration.   MinimumDuration xsd:duration 0:1 Minimum Duration for TIME INTERVAL. +v1.1    TimeStructureFactor – Element    Class. Name Type Card. Description     ::\u0026gt; ::\u0026gt; FareStructureFactor ::\u0026gt; TIME STRUCTURE FACTOR inherits from FARE STRUCTURE FACTOR.   « PK » id TimeStructureFactorIdType 1:1 Identifier of TIME STRUCTURE FACTOR.   « FK » TimeIntervalRef TimeIntervalRef 0:1 Reference to TIME INTERVAL associated with factor.   « FK » TimeUnitRef TimeUnitRef 0:1 Reference to TIME UNIT associated with factor.   « FK » QualityStructureFactorRef QualityStructureFactorRef 0:* QUALITY FACTOR associated with the TIME STRUCTURE FACTOR.     Traçabilité avec les éléments d’entrée Tableau de correspondance  Nom Type Description Exemple Propriétés Profil NeTEx commentaire    id chaine de caractères L’identifiant unique du parking, délivré par le Point d’accès national. INSEE-P-xxx où INSEE est le code INSEE de la commune et xxx est le numéro d’ordre sur 3 chiffres. 75105-P-076 Valeur obligatoire, Motif : ^([013-9]\\d|2[AB1-9])\\d{3}-P-\\d{3}$ Parking.Id Codification harmonisée\nFR:75105:Parking:076:Qpark  nom chaine de caractères Nom du parking, ou nom donné dans son utilisation quotidienne en majuscules et sans accents. Recommandation : inutile de répéter le mot parking et ne pas dépasser les 64 caractères. PATRIARCHES Valeur obligatoire Parking.Name Héritage DataManagedObject  num_siret_proprietaire chaine de caractères Numéro SIRET de la société ou de la collectivité propriétaire de l’ouvrage (14 chiffres). 21750001600019 Valeur obligatoire, Motif : ^\\d{14}$ Organisation.CompanyNumber\n+ ResponsibilityRoleAssignment avec StakeholderRoleType=entityLegalOwnership Organisation.ResponsibilitySetRef pour pointer l'affectaion de rôle  Propriétaire chaine de caractères Nom du propriétaire du parc de stationnement Ville de Paris Valeur optionnelle Organisation.Name\n+ ResponsibilityRoleAssignment avec StakeholderRoleType=entityLegalOwnership Organisation.ResponsibilitySetRef pour pointer l'affectaion de rôle  num_siret_exploitant chaine de caractères Numéro SIRET de la société ou de la collectivité chargée de la gestion de l’ouvrage (14 chiffres). 50472714000056 Valeur obligatoire, Motif : ^\\d{14}$ Parking.OrganisationRef +\nOrganisation.CompanyNumber (+name, description, contact, etc.)    Exploitant chaine de caractères Nom du gestionnaire qui exploite le parc de stationnement INDIGO INFRA Valeur optionnelle Parking.OrganisationRef +\nOrganisation.Name    Enseigne chaine de caractères Nom de la marque affichée à l'entrée du parc de stationnement INDIGO Valeur optionnelle Parking.BrandingRef +\nBranding.Name    Logo image Logo de l'enseigne  Valeur optionnelle Parking.BrandingRef +\nBranding.Image (URL)    Couleur chaine de caractères   Valeur optionnelle Parking.BrandingRef +\nBranding.TextColour On peut aussi le rendre spécifique au Parking plutôt qu'à la marque  insee chaine de caractères Le code INSEE de la commune où le parking est localisé. 75105 Valeur obligatoire, Motif : ^([013-9]\\d|2[AB1-9])\\d{3}$ Parking.PostalAddress.PostalRegion    adresse chaine de caractères L’adresse de l’entrée principale du parking, suivi du code postal et du nom de la Commune (séparé par des virgules). Nomenclature pour les lieux proches des sorties d’autoroute ou de nationale : A11 Sortie 7 Le Mans Nord. Nomenclature pour les zones rurales sans adresse : “Croisement de route_1 - route_2” ou “Le long de route_X après le passage à niveau”. 42 ter rue Daubenton, 75005, Paris Valeur optionnelle Parking.PostalAddress.*    url chaine de caractères Une adresse URL (Uniform Resource Locator) pointant vers une ressource disponible sur Internet où l’on peut obtenir d’autres informations pertinente relatives aux horaires d’ouverture et fermeture du parc, tarifs appliquées dans le parc, ressource disponible sur Internet où l’on peut réserver en ligne la place de parking. https://fr.parkindigo.com/parking/paris-75005/patriarches-75050300 Valeur optionnelle Parking.infoLinks.infoLink    type_usagers Liste chaine de caractères Liste des types d'usagers autorisés dans le parc tous Valeur obligatoire, Valeurs autorisées : tous, abonnés, amodiataires, clients horaires, parc relais, clients du magasin… Parking.ParkingType\n+TypeOfParkingRef pour ajouter des types hors énumération    type_vehicule  Liste des types de véhicules autorisés dans ce parc de stationnement : voiture, poids lourd, autocar, deux-roues motorisé, vélo, GPL, engin de déplacement personnel, autre. Voiture, GPL, Motos, Vélos Valeur obligatoire Parking.ParkingVehicleTypes\n+vehicleTypes pour ajouter des types hors énumération GPL est à mettre dans un VehicleType: VehicleType.FuelType (on peut en prédéfinir une liste par défaut pour les cas déjà identifiés).  nb_places_voitures nombre entier Nombre total de places pour les voitures tout statut (PMR, covoiturage, autopartage, voitures électriques). 334 Valeur obligatoire ParkingArea.TotalCapacity + ParkingArea.ParkingPropertiesproperties.ParkingVehicleTypes avec le type qui va bien    nb_pr nombre entier Nombre de places avec le tarif P+R. 0 Valeur optionnelle Parking.ParkingType pour l'info P+R Pour l'ensemble du Parking\nParkingArea.TotalCapacity + ParkingArea.placeTypes (avec valeur conventionelle « parkAndRide »)    nb_pmr nombre entier Nombre total de places réservées aux personnes à mobilité réduite. 7 Valeur optionnelle ParkingArea.TotalCapacity + ParkingArea.placeTypes (avec valeur conventionelle) … complété par un AccessibilityAssesment    nb_voitures_electriques nombre entier Nombre total de places réservées aux voitures électriques, disposant d’une infrastructure de recharge opérationnelle. 3 Valeur optionnelle ParkingArea.NumberOfBaysWithRecharging Est-ce que cela veut bien dire : \"place équipée d'une borne de recharge\" ?  nb_velo nombre entier Le nombre de vélos maximum pouvant y être rangés. Pour les appuis-vélos qui permettent d’attacher deux vélos (e.g arceau) : multiplier le nombre d’appuis par 2 (e.g. pour 5 arceaux = une capacité de 10 places). Les râteliers permettent d’attacher 1 vélo. 8 Valeur optionnelle ParkingArea.TotalCapacity + ParkingArea.ParkingVehicleType (pedalCycle, moped, etc.)    nb_2r_el nombre entier Nombre d’emplacements vélos ou deux roues motorisés disposant d’une prise électrique dédiée. 0 Valeur optionnelle ParkingArea.TotalCapacity + ParkingArea.ParkingVehicleType (pedalCycle, moped, etc.) + ParkingArea.NumberOfBaysWithRecharging    nb_autopartage nombre entier Nombre total de places réservées aux voitures en autopartage. 0 Valeur optionnelle VehiclesharingParkingArea (spécialisation de ParkingArea)  Peut aussi être exprimé au niveu de la place (Bay)\n  nb_2_rm nombre entier Nombre total de places réservées aux motos et scooters. 20 Valeur optionnelle ParkingArea.TotalCapacity + ParkingArea.ParkingVehicleType (pedalCycle, moped, etc.) …    nb_covoit nombre entier Nombre total de places réservées au covoiturage. 0 Valeur optionnelle VehiclePoolingParkingArea (spécialisation de ParkingArea)  Peut aussi être exprimé au niveu de la place (Bay)\n  nb_pl nombre entier Nombre total de places réservés aux poids lourds 0 Valeur optionnelle ParkingArea.ParkingVehicleType = truk + TotalCapacity    nb_campingcar nombre entier Nombre total de places réservés aux autocaravanes (camping cars) 0 Valeur optionnelle ParkingArea.ParkingVehicleType = camperCar + TotalCapacity    hauteur_max chaine de caractères Hauteur maximale autorisée à la fois pour l’accès au parking et pour le stationnement du véhicule, en centimètres. S’il n’y a pas de hauteur maximale, il est possible de renseigner ce champs avec la valeur N/A. 190 Valeur obligatoire, Motif : ^(\\d+|N/A)$ ParkingArea,MaximumHeight    Xlong nombre réel La longitude en degrés décimaux (point comme séparateur décimal, avec au moins 4 chiffres après le point décimal) de la localisation de l’entrée principale véhicules du lieu exprimée dans le système de coordonnées WGS84. 2.3508884 Valeur obligatoire, Valeur minimale : -180, Valeur maximale : 180 Parking, ParkingArea and Bay .location.longitude et +    Ylat nombre réel La latitude en degrés décimaux (point comme séparateur décimal, avec au moins 4 chiffres après le point décimal) de la localisation de l’entrée principale véhicules du lieu exprimée dans le système de coordonnées WGS84. 48.8403437 Valeur obligatoire, Valeur minimale : -90, Valeur maximale : 90 Parking, ParkingArea and Bay .location.latitude et +    Xlong Ylat autres entrées véhicules nombre réel   Valeur optionnelle xxxEntrance.location …    Xlong Ylat sorties véhicules nombre réel   Valeur optionnelle xxxEntrance.location …    Xlong Ylat accès piétons nombre réel   Valeur optionnelle xxxEntrance.location …    horair_ouverture_visit Tableau Horaires durant lesquels les visiteurs (clients horaires) peuvent entrer avec leurs véhicules Du lundi au vendredi : 07:00-20:00\nSamedi : 07:00-13:00\nDimanche et jours fériés : Fermé Valeur obligatoire Parking.AvaliabilityCondition Fonctionne aussi sur les Parking area  canaux_paiement Liste chaine de caractères Liste des matériels permettant de payer le stationnement effectué dans ce parc : caisse_manuelle/borne de sortie/automate/internet/mobile/autre caisse_manuelle/borne de sortie/automate Valeur obligatoire Parking.ParkingPaymentProcess    moyens_paiement Liste chaine de caractères pièces/billets/CB/Visa/MasterCard/chèque/chèques parking/carte à décompte (à débit)/cartes privatives/badge de télépéage/autre pièces/CB/Visa/MasterCard/cartes privatives/badge de télépéage Valeur obligatoire Parking.PaymentMethods    réservation booléen Possibilité de réserver une place de stationnement à l'avance oui Valeur optionnelle\nOui / Non Parking.ParkingReservations reservationRequired\nreservationAllowed\nnoReservations\nregistrationRequired  abonnement   non obligatoire, comment s'abonner ?  Supprimé (redondant)      gratuit booléen Indique si le parc est toujours gratuit pour tous les usagers Non Valeur obligatoire \"Parking.ParkingPaymentProcess=\"\"free\"\"\nou encore\nParking.FreeParkingOutOfHours ou Parking.ParkingPaymentProcess=free\"\n    tarif_pmr chaine de caractères Type de tarif horaire pour les PMR. - Valeur optionnelle, Valeurs autorisées : gratuit, normal_payant, tarif_special ParkingTariff.ParkingUserType=\"registeredDisabled\"\nLe type (colonne B) etant \"chaine de caractère\" on peut préciser les choses dans une simple Notice associée au ParkingTariff ParkingTariff doit référencer le ou les Parkings concernés  tarif_1h nombre réel Tarif à payer pour 1h de stationnement, en euros TTC (durée gratuite comprise, le cas échéant). 4,4 Valeur optionnelle, Valeur minimale : 0 ParkingTariff.parkingChargeBands.ParkingChargeBand.MaximumStay = 60 (PT60M ou PT1H en XML)\net\nParkingTariff.parkingChargeBands.ParkingChargeBand.prices.TimeIntervalPrice.Amount = 4,4 Ensemble de ParkingChargeBand dans un ParkingTariff\nUnité monétaire par défaut = Euro  tarif_2h nombre réel Tarif à payer pour 2h de stationnement, en euros TTC (durée gratuite comprise, le cas échéant). 7,7 Valeur optionnelle, Valeur minimale : 0 idem avec MaximumStay = 2h et Amount = 7,7    tarif_3h nombre réel Tarif à payer pour 3h de stationnement, en euros TTC (durée gratuite comprise, le cas échéant). 12,1 Valeur optionnelle, Valeur minimale : 0 idem avec MaximumStay = 3h et Amount = 12,1    tarif_4h nombre réel Tarif à payer pour 4h de stationnement, en euros TTC (durée gratuite comprise, le cas échéant). 16,5 Valeur optionnelle, Valeur minimale : 0 idem avec MaximumStay = 4h et Amount = 16,5    tarif_24h nombre réel Tarif à payer pour 24h de stationnement, en euros TTC (durée gratuite comprise, le cas échéant). 39,6 Valeur optionnelle, Valeur minimale : 0 idem avec MaximumStay = 1j (P1D en XML) et Amount = 39,6    abo_resident nombre réel Abonnement mensuel-type pour un résident de la zone, en euros TTC. En cas de changement de tarif, préciser le tarif moyen sur l’année (prorata temporis). 232 Valeur optionnelle, Valeur minimale : 0 Structure générique profil FR avec Fare table\n(voir exemple)\nUsageValidityPeriod. ValidityPeriodType =SeasonTiket\nUsageValidityPeriod.standardDuration =P1M\net UserProfile .LocalResident= true    abo_non_resident nombre réel Abonnement mensuel-type pour un non-résident de la zone, en euros TTC. En cas de changement de tarif, préciser le tarif moyen sur l’année (prorata temporis). 290 Valeur optionnelle, Valeur minimale : 0 idem    type_ouvrage chaine de caractères Précision sur le type de construction de l’équipement. souterrain Valeur obligatoire, Valeurs autorisées : enclos_en_surface, souterrain seul, silo seul, autre ouvrage Parking.ParkingLayout    info chaine de caractères Faire remonter des informations ou commentaires, utiles pour un usager du parking, si les champs précédents ne correspondent pas. Si plusieurs informations sont renseignées, le séparateur est le point-virgule. Par exemple : gratuité le samedi matin de 9h à 12h, informations relatives aux services mis à disposition des usagers (présence d’agents de sécurité 24h…). Gratuité pour le marché le samedi matin Valeur optionnelle Parking.Description    tarif-complet   Fournit le descriptif complet des tarifs   Valeur optionnelle FareTable … voir profil Tarif      Exemple Exemple minimal \u0026lt;?xml version=\u0026#34;1.0\u0026#34; encoding=\u0026#34;UTF-8\u0026#34;?\u0026gt; \u0026lt;PublicationDelivery xmlns=\u0026#34;http://www.netex.org.uk/netex\u0026#34; xmlns:xsi=\u0026#34;http://www.w3.org/2001/XMLSchema-instance\u0026#34; xsi:schemaLocation=\u0026#34;http://www.netex.org.uk/netex file:///C:/Data/Clients/Ministere/SIRI/NeTEx/New%20Modes/PT%200303/XSD/1.2.2r/xsd/NeTEx_publication.xsd\u0026#34; version=\u0026#34;1.1\u0026#34;\u0026gt; \u0026lt;!--- =============== ENTETE =========== --\u0026gt; \u0026lt;PublicationTimestamp\u0026gt;2019-06-12T09:30:47.0Z\u0026lt;/PublicationTimestamp\u0026gt; \u0026lt;ParticipantRef\u0026gt;AURIGE001\u0026lt;/ParticipantRef\u0026gt; \u0026lt;!-- ========== DONNEES =========== --\u0026gt; \u0026lt;dataObjects\u0026gt; \u0026lt;!-- =========================================== --\u0026gt; \u0026lt;!-- CompositeFrame.de type NETEX_FRANCE --\u0026gt; \u0026lt;CompositeFrame version=\u0026#34;1\u0026#34; created=\u0026#34;2019-06-12T09:30:47.0Z\u0026#34; id=\u0026#34;FR:CompositeFrame:myFrame01:LOC\u0026#34;\u0026gt; \u0026lt;frames\u0026gt; \u0026lt;!-- =========================================== --\u0026gt; \u0026lt;!-- Frame NETEX_TARIF --\u0026gt; \u0026lt;GeneralFrame version=\u0026#34;001\u0026#34; id=\u0026#34;FR:TypeOfFrame:NETEX_PARKING-Example1:LOC\u0026#34;\u0026gt; \u0026lt;TypeOfFrameRef ref=\u0026#34;FR:TypeOfFrame:NETEX_PARKING\u0026#34;\u0026gt;version=\u0026#34;2.01:FR-NETEX_PARKING-1.0\u0026#34;\u0026lt;/TypeOfFrameRef\u0026gt; \u0026lt;members modificationSet=\u0026#34;all\u0026#34;\u0026gt; \u0026lt;!-- ======================================================================================================== --\u0026gt; \u0026lt;Parking id=\u0026#34;FR:75105:Parking:076:Qpark\u0026#34; version=\u0026#34;2\u0026#34; responsibilitySetRef=\u0026#34;FR:ResponsibilitySet:0123:LOC\u0026#34;\u0026gt; \u0026lt;validityConditions\u0026gt; \u0026lt;AvailabilityCondition id=\u0026#34;FR:AvailabilityCondition:01:Qpark\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;!-- Ouverture semaine et samedi--\u0026gt; \u0026lt;IsAvailable\u0026gt;true\u0026lt;/IsAvailable\u0026gt; \u0026lt;dayTypes\u0026gt; \u0026lt;DayType version=\u0026#34;any\u0026#34; id=\u0026#34;FR:DayType:01:Qpark\u0026#34;\u0026gt; \u0026lt;properties\u0026gt; \u0026lt;PropertyOfDay\u0026gt; \u0026lt;DaysOfWeek\u0026gt;Weekdays Weekend\u0026lt;/DaysOfWeek\u0026gt; \u0026lt;/PropertyOfDay\u0026gt; \u0026lt;/properties\u0026gt; \u0026lt;timebands id=\u0026#34;FR:timebands:01:Qpark\u0026#34;\u0026gt; \u0026lt;Timeband id=\u0026#34;FR:Timeband:01:Qpark\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;StartTime\u0026gt;07:00:00\u0026lt;/StartTime\u0026gt; \u0026lt;EndTime\u0026gt;20:00:00\u0026lt;/EndTime\u0026gt; \u0026lt;/Timeband\u0026gt; \u0026lt;/timebands\u0026gt; \u0026lt;/DayType\u0026gt; \u0026lt;/dayTypes\u0026gt; \u0026lt;/AvailabilityCondition\u0026gt; \u0026lt;/validityConditions\u0026gt; \u0026lt;Name\u0026gt;PATRIARCHES\u0026lt;/Name\u0026gt; \u0026lt;ParkingType\u0026gt;urbanParking\u0026lt;/ParkingType\u0026gt; \u0026lt;ParkingVehicleTypes\u0026gt;car\u0026lt;/ParkingVehicleTypes\u0026gt; \u0026lt;ParkingLayout\u0026gt;underground\u0026lt;/ParkingLayout\u0026gt; \u0026lt;TotalCapacity\u0026gt;334\u0026lt;/TotalCapacity\u0026gt; \u0026lt;ParkingPaymentProcess\u0026gt;payAtMachineOnFootPriorToExit payAtBay\u0026lt;/ParkingPaymentProcess\u0026gt; \u0026lt;PaymentMethods\u0026gt;cashAndCard epayDevice contactlessPaymentCard\u0026lt;/PaymentMethods\u0026gt; \u0026lt;ParkingReservation\u0026gt;noReservations\u0026lt;/ParkingReservation\u0026gt; \u0026lt;parkingProperties\u0026gt; \u0026lt;ParkingProperties id=\u0026#34;FR:ParkingProperties:1:Qpark\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;ParkingUserTypes\u0026gt;allUsers\u0026lt;/ParkingUserTypes\u0026gt; \u0026lt;/ParkingProperties\u0026gt; \u0026lt;/parkingProperties\u0026gt; \u0026lt;parkingAreas\u0026gt; \u0026lt;ParkingArea id=\u0026#34;FR:ParkingArea:76-1:Qpark\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;MaximumHeight\u0026gt;190\u0026lt;/MaximumHeight\u0026gt; \u0026lt;TotalCapacity\u0026gt;334\u0026lt;/TotalCapacity\u0026gt; \u0026lt;/ParkingArea\u0026gt; \u0026lt;/parkingAreas\u0026gt; \u0026lt;vehicleEntrances\u0026gt; \u0026lt;ParkingEntranceForVehicles id=\u0026#34;FR:ParkingEntranceForVehicles:1:Qpark\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Centroid\u0026gt; \u0026lt;Location\u0026gt; \u0026lt;Longitude\u0026gt;2.3508884\u0026lt;/Longitude\u0026gt; \u0026lt;Latitude\u0026gt;48.8403437\u0026lt;/Latitude\u0026gt; \u0026lt;/Location\u0026gt; \u0026lt;/Centroid\u0026gt; \u0026lt;/ParkingEntranceForVehicles\u0026gt; \u0026lt;/vehicleEntrances\u0026gt; \u0026lt;/Parking\u0026gt; \u0026lt;!-- ========================================================================== --\u0026gt; \u0026lt;GeneralOrganisation version=\u0026#34;any\u0026#34; id=\u0026#34;FR:Organsation:75:\u0026#34;\u0026gt; \u0026lt;CompanyNumber\u0026gt;21750001600019\u0026lt;/CompanyNumber\u0026gt; \u0026lt;!--Ville de Paris--\u0026gt; \u0026lt;/GeneralOrganisation\u0026gt; \u0026lt;GeneralOrganisation id=\u0026#34;FR:Organsation:AB74:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;CompanyNumber\u0026gt;50472714000056\u0026lt;/CompanyNumber\u0026gt; \u0026lt;!--INDIGO --\u0026gt; \u0026lt;/GeneralOrganisation\u0026gt; \u0026lt;ResponsibilitySet id=\u0026#34;FR:ResponsibilitySet:0123:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;roles\u0026gt; \u0026lt;ResponsibilityRoleAssignment version=\u0026#34;any\u0026#34; id=\u0026#34;FR:ResponsibilityRoleAssignment:01:LOC\u0026#34;\u0026gt; \u0026lt;StakeholderRoleType\u0026gt;EntityLegalOwnership\u0026lt;/StakeholderRoleType\u0026gt; \u0026lt;ResponsibleOrganisationRef ref=\u0026#34;FR:Organsation:75:\u0026#34;/\u0026gt; \u0026lt;/ResponsibilityRoleAssignment\u0026gt; \u0026lt;ResponsibilityRoleAssignment version=\u0026#34;any\u0026#34; id=\u0026#34;FR:ResponsibilityRoleAssignment:02:LOC\u0026#34;\u0026gt; \u0026lt;StakeholderRoleType\u0026gt;Operation\u0026lt;/StakeholderRoleType\u0026gt; \u0026lt;ResponsibleOrganisationRef ref=\u0026#34;FR:Organsation:AB74:LOC\u0026#34;/\u0026gt; \u0026lt;/ResponsibilityRoleAssignment\u0026gt; \u0026lt;/roles\u0026gt; \u0026lt;/ResponsibilitySet\u0026gt; \u0026lt;!-- ========================================================================== --\u0026gt; \u0026lt;/members\u0026gt; \u0026lt;/GeneralFrame\u0026gt; \u0026lt;/frames\u0026gt; \u0026lt;/CompositeFrame\u0026gt; \u0026lt;/dataObjects\u0026gt; \u0026lt;/PublicationDelivery\u0026gt; Exemple complet \u0026lt;?xml version=\u0026#34;1.0\u0026#34; encoding=\u0026#34;UTF-8\u0026#34;?\u0026gt; \u0026lt;PublicationDelivery xmlns=\u0026#34;http://www.netex.org.uk/netex\u0026#34; xmlns:xsi=\u0026#34;http://www.w3.org/2001/XMLSchema-instance\u0026#34; xsi:schemaLocation=\u0026#34;http://www.netex.org.uk/netex file:///C:/Data/Clients/Ministere/SIRI/NeTEx/New%20Modes/PT%200303/XSD/1.2.2r/xsd/NeTEx_publication.xsd\u0026#34; version=\u0026#34;1.1\u0026#34;\u0026gt; \u0026lt;!--- =============== ENTETE =========== --\u0026gt; \u0026lt;PublicationTimestamp\u0026gt;2019-06-12T09:30:47.0Z\u0026lt;/PublicationTimestamp\u0026gt; \u0026lt;ParticipantRef\u0026gt;AURIGE001\u0026lt;/ParticipantRef\u0026gt; \u0026lt;!-- ========== DONNEES =========== --\u0026gt; \u0026lt;dataObjects\u0026gt; \u0026lt;!-- =========================================== --\u0026gt; \u0026lt;!-- CompositeFrame.de type NETEX_FRANCE --\u0026gt; \u0026lt;CompositeFrame version=\u0026#34;1\u0026#34; created=\u0026#34;2019-06-12T09:30:47.0Z\u0026#34; id=\u0026#34;FR:CompositeFrame:myFrame01:LOC\u0026#34;\u0026gt; \u0026lt;frames\u0026gt; \u0026lt;!-- =========================================== --\u0026gt; \u0026lt;!-- Frame NETEX_TARIF --\u0026gt; \u0026lt;GeneralFrame version=\u0026#34;001\u0026#34; id=\u0026#34;FR:TypeOfFrame:NETEX_PARKING-Example1:LOC\u0026#34;\u0026gt; \u0026lt;TypeOfFrameRef ref=\u0026#34;FR:TypeOfFrame:NETEX_PARKING\u0026#34;\u0026gt;version=\u0026#34;2.01:FR-NETEX_PARKING-1.0\u0026#34;\u0026lt;/TypeOfFrameRef\u0026gt; \u0026lt;members modificationSet=\u0026#34;all\u0026#34;\u0026gt; \u0026lt;!-- =========================================================================================================== --\u0026gt; \u0026lt;Parking id=\u0026#34;FR:75105:Parking:076:Qpark\u0026#34; version=\u0026#34;2\u0026#34; responsibilitySetRef=\u0026#34;FR:ResponsibilitySet:0123:LOC\u0026#34;\u0026gt; \u0026lt;validityConditions\u0026gt; \u0026lt;AvailabilityCondition id=\u0026#34;FR:AvailabilityCondition:01:Qpark\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;!-- Ouverture semaine et samedi--\u0026gt; \u0026lt;IsAvailable\u0026gt;true\u0026lt;/IsAvailable\u0026gt; \u0026lt;dayTypes\u0026gt; \u0026lt;DayType version=\u0026#34;any\u0026#34; id=\u0026#34;FR:DayType:01:Qpark\u0026#34;\u0026gt; \u0026lt;properties\u0026gt; \u0026lt;PropertyOfDay\u0026gt; \u0026lt;DaysOfWeek\u0026gt;Weekdays\u0026lt;/DaysOfWeek\u0026gt; \u0026lt;/PropertyOfDay\u0026gt; \u0026lt;/properties\u0026gt; \u0026lt;timebands id=\u0026#34;FR:timebands:01:Qpark\u0026#34;\u0026gt; \u0026lt;Timeband id=\u0026#34;FR:Timeband:01:Qpark\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;StartTime\u0026gt;07:00:00\u0026lt;/StartTime\u0026gt; \u0026lt;EndTime\u0026gt;20:00:00\u0026lt;/EndTime\u0026gt; \u0026lt;/Timeband\u0026gt; \u0026lt;/timebands\u0026gt; \u0026lt;/DayType\u0026gt; \u0026lt;DayType id=\u0026#34;FR:DayType:02:Qpark\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;properties\u0026gt; \u0026lt;PropertyOfDay\u0026gt; \u0026lt;DaysOfWeek\u0026gt;Saturday\u0026lt;/DaysOfWeek\u0026gt; \u0026lt;/PropertyOfDay\u0026gt; \u0026lt;/properties\u0026gt; \u0026lt;timebands id=\u0026#34;FR:timebands:02:Qpark\u0026#34;\u0026gt; \u0026lt;Timeband id=\u0026#34;FR:timebands:02:Qpark\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;StartTime\u0026gt;07:00:00\u0026lt;/StartTime\u0026gt; \u0026lt;EndTime\u0026gt;13:00:00\u0026lt;/EndTime\u0026gt; \u0026lt;/Timeband\u0026gt; \u0026lt;/timebands\u0026gt; \u0026lt;/DayType\u0026gt; \u0026lt;/dayTypes\u0026gt; \u0026lt;/AvailabilityCondition\u0026gt; \u0026lt;AvailabilityCondition id=\u0026#34;FR:AvailabilityCondition:02:Qpark\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;!-- Fermé dimanche et jours fériés --\u0026gt; \u0026lt;IsAvailable\u0026gt;false\u0026lt;/IsAvailable\u0026gt; \u0026lt;dayTypes\u0026gt; \u0026lt;DayType id=\u0026#34;FR:DayType:03:Qpark\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;properties\u0026gt; \u0026lt;PropertyOfDay\u0026gt; \u0026lt;DaysOfWeek\u0026gt;Sunday\u0026lt;/DaysOfWeek\u0026gt; \u0026lt;HolidayTypes\u0026gt;NationalHoliday\u0026lt;/HolidayTypes\u0026gt; \u0026lt;/PropertyOfDay\u0026gt; \u0026lt;/properties\u0026gt; \u0026lt;/DayType\u0026gt; \u0026lt;/dayTypes\u0026gt; \u0026lt;/AvailabilityCondition\u0026gt; \u0026lt;/validityConditions\u0026gt; \u0026lt;BrandingRef ref=\u0026#34;FR:Branding:INDI123:LOC\u0026#34;/\u0026gt; \u0026lt;Name\u0026gt;PATRIARCHES\u0026lt;/Name\u0026gt; \u0026lt;Description\u0026gt;Parking INDIGO PATRIARCHES - Gratuit\u0026amp;#xE9; pour le march\u0026amp;#xE9; le samedi matin\u0026lt;/Description\u0026gt; \u0026lt;infoLinks\u0026gt; \u0026lt;InfoLink\u0026gt;https://fr.parkindigo.com/parking/paris-75005/patriarches-75050300\u0026lt;/InfoLink\u0026gt; \u0026lt;/infoLinks\u0026gt; \u0026lt;Centroid\u0026gt; \u0026lt;Location\u0026gt; \u0026lt;Longitude\u0026gt;2.3508884\u0026lt;/Longitude\u0026gt; \u0026lt;Latitude\u0026gt;48.8403437\u0026lt;/Latitude\u0026gt; \u0026lt;/Location\u0026gt; \u0026lt;/Centroid\u0026gt; \u0026lt;PostalAddress version=\u0026#34;any\u0026#34; id=\u0026#34;FR:PostalAddress:01:Qpark\u0026#34;\u0026gt; \u0026lt;HouseNumber\u0026gt;42 ter\u0026lt;/HouseNumber\u0026gt; \u0026lt;!-- NOTE: il serait aussi possible de renseigner une \u0026#34;AddressLine1\u0026#34; au lieu de champs séparé --\u0026gt; \u0026lt;Street\u0026gt;rue Daubenton\u0026lt;/Street\u0026gt; \u0026lt;Town\u0026gt;Paris\u0026lt;/Town\u0026gt; \u0026lt;PostalRegion\u0026gt;75015\u0026lt;/PostalRegion\u0026gt; \u0026lt;/PostalAddress\u0026gt; \u0026lt;entrances\u0026gt; \u0026lt;!-- On ne mettra ici que les entrès piétonne (les entrée véhicule on un positionnement particulier pour les Parkings --\u0026gt; \u0026lt;ParkingPassengerEntrance id=\u0026#34;FR:ParkingPassengerEntrance:1:Qpark\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;!-- Note: une entrée peut aussi etre spécifique à une ParkingArea si nécessaire --\u0026gt; \u0026lt;Name\u0026gt;Entr\u0026amp;#xE9;e pi\u0026amp;#xE9;tone principale\u0026lt;/Name\u0026gt; \u0026lt;Centroid\u0026gt; \u0026lt;Location\u0026gt; \u0026lt;Longitude\u0026gt;2.3508884\u0026lt;/Longitude\u0026gt; \u0026lt;Latitude\u0026gt;48.8403437\u0026lt;/Latitude\u0026gt; \u0026lt;/Location\u0026gt; \u0026lt;/Centroid\u0026gt; \u0026lt;/ParkingPassengerEntrance\u0026gt; \u0026lt;/entrances\u0026gt; \u0026lt;ParkingType\u0026gt;urbanParking\u0026lt;/ParkingType\u0026gt; \u0026lt;ParkingVehicleTypes\u0026gt;car motorcycle pedalCycle\u0026lt;/ParkingVehicleTypes\u0026gt; \u0026lt;vehicleTypes\u0026gt; \u0026lt;VehicleTypeRef ref=\u0026#34;FR:VehicleType:GPL:\u0026#34;/\u0026gt; \u0026lt;/vehicleTypes\u0026gt; \u0026lt;ParkingLayout\u0026gt;underground\u0026lt;/ParkingLayout\u0026gt; \u0026lt;TotalCapacity\u0026gt;334\u0026lt;/TotalCapacity\u0026gt; \u0026lt;ParkingPaymentProcess\u0026gt;payAtMachineOnFootPriorToExit payAtBay\u0026lt;/ParkingPaymentProcess\u0026gt; \u0026lt;PaymentMethods\u0026gt;cashAndCard epayDevice contactlessPaymentCard\u0026lt;/PaymentMethods\u0026gt; \u0026lt;typesOfPaymentMethod\u0026gt; \u0026lt;TypeOfPaymentMethodRef ref=\u0026#34;VISA\u0026#34;/\u0026gt; \u0026lt;TypeOfPaymentMethodRef ref=\u0026#34;Mastercard\u0026#34;/\u0026gt; \u0026lt;/typesOfPaymentMethod\u0026gt; \u0026lt;CardsAccepted\u0026gt;VISA MASTERCARD CB\u0026lt;/CardsAccepted\u0026gt; \u0026lt;ParkingReservation\u0026gt;registrationRequired\u0026lt;/ParkingReservation\u0026gt; \u0026lt;parkingProperties\u0026gt; \u0026lt;ParkingProperties id=\u0026#34;FR:ParkingProperties:1:Qpark\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;ParkingUserTypes\u0026gt;allUsers\u0026lt;/ParkingUserTypes\u0026gt; \u0026lt;/ParkingProperties\u0026gt; \u0026lt;/parkingProperties\u0026gt; \u0026lt;parkingAreas\u0026gt; \u0026lt;ParkingArea id=\u0026#34;FR:ParkingArea:76-1:Qpark\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;!-- Cette première zone est plus complète que les autres, à vocation d\u0026#39;exemple, mais le même niveau de détail peut s\u0026#39;appliquer à toutes les zones --\u0026gt; \u0026lt;Name\u0026gt;Zone PMR\u0026lt;/Name\u0026gt; \u0026lt;AccessibilityAssessment version=\u0026#34;any\u0026#34; id=\u0026#34;FR:AccessibilityAssessment:01:Qpark\u0026#34;\u0026gt; \u0026lt;MobilityImpairedAccess\u0026gt;true\u0026lt;/MobilityImpairedAccess\u0026gt; \u0026lt;/AccessibilityAssessment\u0026gt; \u0026lt;PublicUse\u0026gt;disabledPublicOnly\u0026lt;/PublicUse\u0026gt; \u0026lt;Label\u0026gt;Zone VERTE\u0026lt;/Label\u0026gt; \u0026lt;MaximumHeight\u0026gt;190\u0026lt;/MaximumHeight\u0026gt; \u0026lt;TotalCapacity\u0026gt;7\u0026lt;/TotalCapacity\u0026gt; \u0026lt;/ParkingArea\u0026gt; \u0026lt;ParkingArea id=\u0026#34;FR:ParkingArea:76-2:Qpark\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Zone P+R\u0026lt;/Name\u0026gt; \u0026lt;placeTypes\u0026gt; \u0026lt;TypeOfPlaceRef ref=\u0026#34;parkAndRide\u0026#34;/\u0026gt; \u0026lt;!-- parkAndRide est une valeur conventionnelle définie par le profil... on pourrait peut être l\u0026#39;intégrer à ParkingUserType --\u0026gt; \u0026lt;/placeTypes\u0026gt; \u0026lt;PublicUse\u0026gt;all\u0026lt;/PublicUse\u0026gt; \u0026lt;TotalCapacity\u0026gt;0\u0026lt;/TotalCapacity\u0026gt; \u0026lt;!-- Valeur 0 pour suivre l\u0026#39;exemple: inutile de décrire une ParkingArea si elle n\u0026#39;a pas de places... --\u0026gt; \u0026lt;/ParkingArea\u0026gt; \u0026lt;ParkingArea id=\u0026#34;FR:ParkingArea:76-4:Qpark\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Zone Parking V\u0026amp;#xE9;lo\u0026lt;/Name\u0026gt; \u0026lt;Description\u0026gt;4 arceaux permettant une capacit\u0026amp;#xE9; de 8 place de v\u0026amp;#xE9;lo\u0026lt;/Description\u0026gt; \u0026lt;PublicUse\u0026gt;all\u0026lt;/PublicUse\u0026gt; \u0026lt;TotalCapacity\u0026gt;20\u0026lt;/TotalCapacity\u0026gt; \u0026lt;NumberOfBaysWithRecharging\u0026gt;0\u0026lt;/NumberOfBaysWithRecharging\u0026gt; \u0026lt;ParkingProperties id=\u0026#34;FR:ParkingProperties:12:Qpark\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;ParkingVehicleTypes\u0026gt;pedalCycle moped motorcycle\u0026lt;/ParkingVehicleTypes\u0026gt; \u0026lt;!-- peut naturellent être scindé en # espaces --\u0026gt; \u0026lt;/ParkingProperties\u0026gt; \u0026lt;/ParkingArea\u0026gt; \u0026lt;VehicleSharingParkingArea id=\u0026#34;FR:ParkingArea:76-5:Qpark\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Zone Autopartage\u0026lt;/Name\u0026gt; \u0026lt;TotalCapacity\u0026gt;10\u0026lt;/TotalCapacity\u0026gt; \u0026lt;/VehicleSharingParkingArea\u0026gt; \u0026lt;VehiclePoolingParkingArea id=\u0026#34;FR:VehiclePoolingParkingArea:76-6:Qpark\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Zone r\u0026amp;#xE9;serv\u0026amp;#xE9;e aux couvoitureurs\u0026lt;/Name\u0026gt; \u0026lt;TotalCapacity\u0026gt;2\u0026lt;/TotalCapacity\u0026gt; \u0026lt;/VehiclePoolingParkingArea\u0026gt; \u0026lt;/parkingAreas\u0026gt; \u0026lt;vehicleEntrances\u0026gt; \u0026lt;ParkingEntranceForVehicles id=\u0026#34;FR:ParkingEntranceForVehicles:1:Qpark\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;!-- Note: une entrée peut aussi etre spécifique à une ParkingArea si nécessaire --\u0026gt; \u0026lt;Name\u0026gt;Entr\u0026amp;#xE9;e/sortie principale pour les v\u0026amp;#xE9;hicules\u0026lt;/Name\u0026gt; \u0026lt;Centroid\u0026gt; \u0026lt;Location\u0026gt; \u0026lt;Longitude\u0026gt;2.3508884\u0026lt;/Longitude\u0026gt; \u0026lt;Latitude\u0026gt;48.8403437\u0026lt;/Latitude\u0026gt; \u0026lt;/Location\u0026gt; \u0026lt;/Centroid\u0026gt; \u0026lt;/ParkingEntranceForVehicles\u0026gt; \u0026lt;/vehicleEntrances\u0026gt; \u0026lt;/Parking\u0026gt; \u0026lt;!-- ========================================================================== --\u0026gt; \u0026lt;GeneralOrganisation version=\u0026#34;any\u0026#34; id=\u0026#34;FR:Organsation:75:\u0026#34;\u0026gt; \u0026lt;CompanyNumber\u0026gt;21750001600019\u0026lt;/CompanyNumber\u0026gt; \u0026lt;Name\u0026gt;Ville de Paris\u0026lt;/Name\u0026gt; \u0026lt;/GeneralOrganisation\u0026gt; \u0026lt;GeneralOrganisation id=\u0026#34;FR:Organsation:AB74:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;CompanyNumber\u0026gt;50472714000056\u0026lt;/CompanyNumber\u0026gt; \u0026lt;Name\u0026gt;INDIGO INFRA\u0026lt;/Name\u0026gt; \u0026lt;/GeneralOrganisation\u0026gt; \u0026lt;ResponsibilitySet id=\u0026#34;FR:ResponsibilitySet:0123:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;roles\u0026gt; \u0026lt;ResponsibilityRoleAssignment version=\u0026#34;any\u0026#34; id=\u0026#34;FR:ResponsibilityRoleAssignment:01:LOC\u0026#34;\u0026gt; \u0026lt;StakeholderRoleType\u0026gt;EntityLegalOwnership\u0026lt;/StakeholderRoleType\u0026gt; \u0026lt;ResponsibleOrganisationRef ref=\u0026#34;FR:Organsation:75:\u0026#34;/\u0026gt; \u0026lt;/ResponsibilityRoleAssignment\u0026gt; \u0026lt;ResponsibilityRoleAssignment version=\u0026#34;any\u0026#34; id=\u0026#34;FR:ResponsibilityRoleAssignment:02:LOC\u0026#34;\u0026gt; \u0026lt;StakeholderRoleType\u0026gt;Operation\u0026lt;/StakeholderRoleType\u0026gt; \u0026lt;ResponsibleOrganisationRef ref=\u0026#34;FR:Organsation:AB74:LOC\u0026#34;/\u0026gt; \u0026lt;/ResponsibilityRoleAssignment\u0026gt; \u0026lt;/roles\u0026gt; \u0026lt;/ResponsibilitySet\u0026gt; \u0026lt;Branding id=\u0026#34;FR:Branding:INDI123:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;INDIGO\u0026lt;/Name\u0026gt; \u0026lt;Image\u0026gt;https://fr.parkindigo.com/assets/img/indigo.svg\u0026lt;/Image\u0026gt; \u0026lt;Presentation\u0026gt; \u0026lt;TextColour\u0026gt;02AEBF\u0026lt;/TextColour\u0026gt; \u0026lt;/Presentation\u0026gt; \u0026lt;/Branding\u0026gt; \u0026lt;VehicleType id=\u0026#34;FR:VehicleType:GPL:\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;V\u0026amp;#xE9;hicule GPL\u0026lt;/Name\u0026gt; \u0026lt;Description\u0026gt;V\u0026amp;#xE9;hicule particulier utilisant le GPL\u0026lt;/Description\u0026gt; \u0026lt;TypeOfFuel\u0026gt;naturalGas\u0026lt;/TypeOfFuel\u0026gt; \u0026lt;/VehicleType\u0026gt; \u0026lt;!-- ===================================================================================================== --\u0026gt; \u0026lt;!-- STRUCTURE TARIFAIRE ET DROITS DE BASE --\u0026gt; \u0026lt;ParkingTariff id=\u0026#34;FR:75105:ParkingTariff:076:Qpark\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Tarif principal\u0026lt;/Name\u0026gt; \u0026lt;noticeAssignments\u0026gt; \u0026lt;NoticeAssignmentView\u0026gt; \u0026lt;Text\u0026gt;Gratuit pour les personnes \u0026amp;#xE0; mobilit\u0026amp;#xE9; r\u0026amp;#xE9;duite\u0026lt;/Text\u0026gt; \u0026lt;/NoticeAssignmentView\u0026gt; \u0026lt;/noticeAssignments\u0026gt; \u0026lt;ParkingUserType\u0026gt;allUsers\u0026lt;/ParkingUserType\u0026gt; \u0026lt;!-- peut prendre des valeurs comme \u0026#34;registeredDisabled\u0026#34; --\u0026gt; \u0026lt;appliesTo\u0026gt; \u0026lt;ParkingRef ref=\u0026#34;FR:75105:Parking:076:Qpark\u0026#34;/\u0026gt; \u0026lt;!-- Note: plusieurs Parkings peuvent partager la même tarification --\u0026gt; \u0026lt;/appliesTo\u0026gt; \u0026lt;parkingChargeBands\u0026gt; \u0026lt;ParkingChargeBand\u0026gt; \u0026lt;MaximumStay\u0026gt;PT1H\u0026lt;/MaximumStay\u0026gt; \u0026lt;prices\u0026gt; \u0026lt;TimeIntervalPrice id=\u0026#34;FR:TimeIntervalPrice:01:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Amount\u0026gt;4.4\u0026lt;/Amount\u0026gt; \u0026lt;/TimeIntervalPrice\u0026gt; \u0026lt;/prices\u0026gt; \u0026lt;/ParkingChargeBand\u0026gt; \u0026lt;ParkingChargeBand\u0026gt; \u0026lt;MaximumStay\u0026gt;PT2H\u0026lt;/MaximumStay\u0026gt; \u0026lt;prices\u0026gt; \u0026lt;TimeIntervalPrice id=\u0026#34;FR:TimeIntervalPrice:02:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Amount\u0026gt;7.7\u0026lt;/Amount\u0026gt; \u0026lt;/TimeIntervalPrice\u0026gt; \u0026lt;/prices\u0026gt; \u0026lt;/ParkingChargeBand\u0026gt; \u0026lt;ParkingChargeBand\u0026gt; \u0026lt;MaximumStay\u0026gt;PT3H\u0026lt;/MaximumStay\u0026gt; \u0026lt;prices\u0026gt; \u0026lt;TimeIntervalPrice id=\u0026#34;FR:TimeIntervalPrice:03:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Amount\u0026gt;12.1\u0026lt;/Amount\u0026gt; \u0026lt;/TimeIntervalPrice\u0026gt; \u0026lt;/prices\u0026gt; \u0026lt;/ParkingChargeBand\u0026gt; \u0026lt;ParkingChargeBand\u0026gt; \u0026lt;MaximumStay\u0026gt;PT4H\u0026lt;/MaximumStay\u0026gt; \u0026lt;prices\u0026gt; \u0026lt;TimeIntervalPrice id=\u0026#34;FR:TimeIntervalPrice:04:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Amount\u0026gt;16.5\u0026lt;/Amount\u0026gt; \u0026lt;/TimeIntervalPrice\u0026gt; \u0026lt;/prices\u0026gt; \u0026lt;/ParkingChargeBand\u0026gt; \u0026lt;ParkingChargeBand\u0026gt; \u0026lt;MaximumStay\u0026gt;P1D\u0026lt;/MaximumStay\u0026gt; \u0026lt;prices\u0026gt; \u0026lt;TimeIntervalPrice id=\u0026#34;FR:TimeIntervalPrice:05:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Amount\u0026gt;39.6\u0026lt;/Amount\u0026gt; \u0026lt;/TimeIntervalPrice\u0026gt; \u0026lt;/prices\u0026gt; \u0026lt;/ParkingChargeBand\u0026gt; \u0026lt;/parkingChargeBands\u0026gt; \u0026lt;/ParkingTariff\u0026gt; \u0026lt;ParkingTariff id=\u0026#34;FR:75105:ParkingTariff:077:Qpark\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Tarif abonnement\u0026lt;/Name\u0026gt; \u0026lt;appliesTo\u0026gt; \u0026lt;ParkingRef ref=\u0026#34;FR:75105:Parking:076:Qpark\u0026#34;/\u0026gt; \u0026lt;!-- Note: plusieurs Parkings peuvent partager la même tarification --\u0026gt; \u0026lt;/appliesTo\u0026gt; \u0026lt;/ParkingTariff\u0026gt; \u0026lt;UserProfile id=\u0026#34;FR-Tarif-Example:UserProfile:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;!-- Plein tarif classique --\u0026gt; \u0026lt;Name\u0026gt;R\u0026amp;#xE9;sident\u0026lt;/Name\u0026gt; \u0026lt;Description\u0026gt;Profil r\u0026amp;#xE9;sident pour tarif r\u0026amp;#xE9;duit\u0026lt;/Description\u0026gt; \u0026lt;LocalResident\u0026gt;true\u0026lt;/LocalResident\u0026gt; \u0026lt;/UserProfile\u0026gt; \u0026lt;UserProfile id=\u0026#34;FR-Tarif-Example:UserProfile:002:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;!-- Plein tarif classique --\u0026gt; \u0026lt;Name\u0026gt;Non R\u0026amp;#xE9;sident\u0026lt;/Name\u0026gt; \u0026lt;Description\u0026gt;Profil non r\u0026amp;#xE9;sident\u0026lt;/Description\u0026gt; \u0026lt;LocalResident\u0026gt;false\u0026lt;/LocalResident\u0026gt; \u0026lt;/UserProfile\u0026gt; \u0026lt;UsageValidityPeriod version=\u0026#34;any\u0026#34; id=\u0026#34;FR-Tarif-Example:UsageValidityPeriod:001:LOC\u0026#34;\u0026gt; \u0026lt;ValidityPeriodType\u0026gt;seasonTicket\u0026lt;/ValidityPeriodType\u0026gt; \u0026lt;StandardDuration\u0026gt;P1M\u0026lt;/StandardDuration\u0026gt; \u0026lt;/UsageValidityPeriod\u0026gt; \u0026lt;!-- FARE TABLE --\u0026gt; \u0026lt;!-- Pour chaque cellule: Prix / ParkingTariff-UsageValidityPeriodRef-UserProfile --\u0026gt; \u0026lt;FareTable version=\u0026#34;any\u0026#34; id=\u0026#34;FR-Tarif-Example:FareTable:001:LOC\u0026#34;\u0026gt; \u0026lt;Name\u0026gt; Tarifs particuliers the Parking PATRIARCHES\u0026lt;/Name\u0026gt; \u0026lt;cells\u0026gt; \u0026lt;Cell version=\u0026#34;any\u0026#34; id=\u0026#34;FR-Tarif-Example:Cell:001:LOC\u0026#34; order=\u0026#34;1\u0026#34;\u0026gt; \u0026lt;ParkingPrice id=\u0026#34;lFR-Tarif-Example:ParkingPrice:001:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Tarif r\u0026amp;#xE9;sident\u0026lt;/Name\u0026gt; \u0026lt;Amount\u0026gt;232\u0026lt;/Amount\u0026gt; \u0026lt;/ParkingPrice\u0026gt; \u0026lt;PriceableObjectRef ref=\u0026#34;FR:75105:ParkingTariff:077:Qpark\u0026#34;/\u0026gt; \u0026lt;!-- Pour faire le lien avec le Parking --\u0026gt; \u0026lt;UserProfileRef version=\u0026#34;any\u0026#34; ref=\u0026#34;FR-Tarif-Example:UserProfile:001:LOC\u0026#34;/\u0026gt; \u0026lt;!-- reference vers \u0026#34;résident\u0026#34; --\u0026gt; \u0026lt;UsageValidityPeriodRef ref=\u0026#34;FR-Tarif-Example:UsageValidityPeriod:001:LOC\u0026#34;/\u0026gt; \u0026lt;/Cell\u0026gt; \u0026lt;Cell version=\u0026#34;any\u0026#34; id=\u0026#34;FR-Tarif-Example:Cell:002:LOC\u0026#34; order=\u0026#34;2\u0026#34;\u0026gt; \u0026lt;ParkingPrice id=\u0026#34;FR-Tarif-Example:Cell:002:LOC\u0026#34; version=\u0026#34;any\u0026#34;\u0026gt; \u0026lt;Name\u0026gt;Tarif non r\u0026amp;#xE9;sident\u0026lt;/Name\u0026gt; \u0026lt;Amount\u0026gt;290\u0026lt;/Amount\u0026gt; \u0026lt;/ParkingPrice\u0026gt; \u0026lt;PriceableObjectRef ref=\u0026#34;FR:75105:ParkingTariff:077:Qpark\u0026#34;/\u0026gt; \u0026lt;!-- Pour faire le lien avec le Parking --\u0026gt; \u0026lt;UserProfileRef version=\u0026#34;any\u0026#34; ref=\u0026#34;FR-Tarif-Example:UserProfile:002:LOC\u0026#34;/\u0026gt; \u0026lt;!-- reference vers \u0026#34;non résident\u0026#34; --\u0026gt; \u0026lt;UsageValidityPeriodRef ref=\u0026#34;FR-Tarif-Example:UsageValidityPeriod:001:LOC\u0026#34;/\u0026gt; \u0026lt;/Cell\u0026gt; \u0026lt;!-- etc. --\u0026gt; \u0026lt;/cells\u0026gt; \u0026lt;/FareTable\u0026gt; \u0026lt;!-- ============================================================================================== --\u0026gt; \u0026lt;/members\u0026gt; \u0026lt;/GeneralFrame\u0026gt; \u0026lt;/frames\u0026gt; \u0026lt;/CompositeFrame\u0026gt; \u0026lt;/dataObjects\u0026gt; \u0026lt;/PublicationDelivery\u0026gt;   .mark { background-color: yellow; } .mark-gray { background-color: lightgray; } .red { color: red; } /* Hide terms \u0026 definitions lists in ToC */ .toc.autonumbering .inner  ul  li:nth-of-type(3)  ul { display: none; } .toc.autonumbering .inner  ul  li:nth-of-type(4)  ul { display: none; } /* Renumber annexes in ToC */ .toc.autonumbering { counter-set: lvl1 0; } .toc.autonumbering .inner  ul  li:nth-child(n+10)::before { counter-increment: lvl1; content: 'Annexe 'counter(lvl1, upper-alpha)' – '; } .toc.autonumbering .inner  ul  li:nth-child(n+10)  ul { counter-set: lvl2 0; } .toc.autonumbering .inner  ul  li:nth-child(n+10)  ul ul { counter-set: lvl3 0; } .toc.autonumbering .inner  ul  li:nth-child(n+10)  ul  li::before { counter-increment: lvl2; content: counter(lvl1, upper-alpha)'.' counter(lvl2)'.'; } .toc.autonumbering .inner  ul  li:nth-child(n+10)  ul  li  ul  li::before { counter-increment: lvl3; content: counter(lvl1, upper-alpha)'.' counter(lvl2)'.' counter(lvl3)'.'; } /* But hide numbering for Bibliographie */ .toc.autonumbering .inner  ul  li:nth-child(9)::before { content: \"\"; } /* Renumber annexes in body */ .annexes { counter-set: h1 0 h2 0 h3 0; } .annexes h1::before { content: 'Annexe 'counter(h1, upper-alpha)' – '; } .annexes h2::before { counter-increment: h2; content: counter(h1, upper-alpha)'.' counter(h2)'. '; } .annexes h3::before { counter-increment: h3; content: counter(h1, upper-alpha)'.' counter(h2)'.' counter(h3)'. '; } /* But hide numbering for Bibliographie */ h1#bibliographie::before { content: \"\"; } .post-content img { margin-inline: auto; width: unset; max-width: 100%; } .post-content img.icon { max-width: unset; margin: 0; height: 2rem; display: inline-block; vertical-align: middle; } #attributes-definition table { width: 100%; display: table; table-layout: fixed; } #attributes-definition table thead th { background-color: #d0cece; text-align: center; } table.concepts thead th { background-color: #ffc000; text-align: center; } table.concepts tbody td:first-of-type { background-color: #c6e0b4; text-align: center; } table.concepts td[colspan=\"6\"]:first-of-type { background-color: #d0cece; } table td[colspan=\"5\"] { text-align: center; } table.mapping { position: relative; } table.mapping tr.header th { background-color: #c00000; color: white; position: sticky; top: 0; } table.mapping tr.header th:nth-child(n+6) { background-color: #0070c0; } table.mapping td.yellow-cell { background-color: yellow; } table.mapping td.salmon-cell { background-color: #fde9d9; } table.mapping del { color: red; background: linear-gradient(to right,red 100%,transparent 0)0/1px 1px repeat-x; } table.mapping th:nth-child(3), table.mapping td:nth-child(3) { min-width: 300px; } table.attributes, div.attributes table { font-size: 12px; display: table; } div.attributes table th:nth-child(1), div.attributes table td:nth-child(1), div.attributes table th:nth-child(4), div.attributes table td:nth-child(4), table.attributes th:nth-child(1), table.attributes td:nth-child(1), table.attributes th:nth-child(4), table.attributes td:nth-child(4) { min-width: unset; } div.attributes table th:nth-child(2), div.attributes table td:nth-child(2), div.attributes table th:nth-child(3), div.attributes table td:nth-child(3), table.attributes th:nth-child(2), table.attributes td:nth-child(2), table.attributes th:nth-child(3), table.attributes td:nth-child(3) { min-width: unset; width: min-content; } table.attributes th:nth-child(5), table.attributes td:nth-child(5), div.attributes table th:nth-child(5), div.attributes table td:nth-child(5) { min-width: 300px; }  ","permalink":"https://deploy-preview-56--transport-normes.netlify.app/normes/netex/parkings/","summary":"Avant-propos\nL’harmonisation des pratiques dans l’échange des données relatives aux offres de transport est essentielle :\n 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.","title":"NeTEx - Profil France v2.4 - Parkings"},{"content":"Profil d\u0026rsquo;échange pour la description des informations temps-réel des réseaux de transport en commun\nSIRI - Profil France v1.8\nAvant-propos\nCe document présente de façon détaillée le profil France de SIRI (également appelé « local agreement SIRI France »), soit la déclinaison de la norme SIRI aux besoins métiers français. Il contient tous les éléments nécessaires à sa compréhension, mais ne propose ni une réécriture ni une traduction de l\u0026rsquo;ensemble des documents normatifs SIRI :\n Le lecteur devra donc se référer à la norme quand cela sera nécessaire, en particulier au niveau technique avant d\u0026rsquo;envisager toute implémentation de SIRI.  /* moved down a bit to ensure top-level preview does not show this */ /* ultimately this will have to move to main.css in transport-normes-site */ mark, .mark { background-color: #d7d7d7; } .m_hub { background-color: #00FF00; } .m_excl { background-color: #55FFFF; } .m_red { color: #FF0000; } .no_h th { font-weight: normal;}  D\u0026rsquo;autre part, l\u0026rsquo;ensemble de la terminologie utilisée dans ce document est celle de SIRI, et par voie de conséquence de TRANSMODEL version 6.0.\n Le lecteur est donc invité à se référer au document TRANSMODEL pour de plus amples précisions sur la terminologie, les concepts ou modèles de données sous-jacents.  Plus généralement, les notions manipulées dans ce document sont décrites par l’ensemble de documents normatifs suivants :\n  SIRI : Service Interface for Real-time Information relating to public transport operations (NF EN 15531- 1 à 3 et CEN/TS 15531-4 et 5)\n  Partie 1: Context and framework\n  Partie 2: Communications infrastructure\n  Partie 3: Functional service interfaces\n  Partie 4: Functional service interfaces - Facility Management\n  Partie 5: Functional service interfaces - Situation Exchange\n  TRANSMODEL : NF EN 12896, Transmodel (version 6.0), Reference Data Model for Public Transport et Transmodel in UML (projet SITP 2,version 0.1 04/09/2003)\n  NeTEx : Network Timetable EXchange (CEN/TS 16614-1 à 6)\n  Dans le document, les règles propres au profil sont présentées sur fond gris. Les autres règles ont plus un rôle d\u0026rsquo;explication, d\u0026rsquo;accompagnement ou de recommandation.\nCe document est structuré en quatre parties :\n  Partie 1 : Contexte\nCette partie présente la démarche de construction du profil SIRIFrance, les cas d’utilisation constatés ou présentés à titre d’exemple, et la liste des services SIRI retenus, en se basant sur ces cas d’utilisation.\n  Partie 2 : Présentation des concepts fondamentaux du Profil\nCette partie présente les particularités et les options du profil SIRI France : concepts fondamentaux, modélisation de cas spécifiques, référentiels de données, et modalités techniques d’échange.\n  Partie 3 : Description du profil d’échange\nCette partie décrit les conventions et les règles utilisées pour la rédaction de ce profil.\n  Partie 4 : Description détaillée des messages\n  Cette partie présente le format des messages SIRI et les choix effectués dans le contexte national français (utilisation ou non des champs, cardinalités, …). Elle constitue à ce titre une description technique et essentiellement un cadre fonctionnel à destination des développeurs et intégrateurs.\nLe lecteur dispose en annexe au présent document d’un glossaire composé des définitions et autres acronymes.\nÀ noter : les extraits de normes figurant dans cet ouvrage sont reproduits avec l’accord de l’AFNOR. Seul le texte original et complet de la norme telle que diffusée par l\u0026rsquo;AFNOR – accessible via le site Internet www.afnor. org – possède une valeur normative.\nCe document a été validé et publié comme suit :\n travaux de révision : 2024-2025 date de validation en CN03 : 19 décembre 2025 date de publication : 16 mars 2026  Introduction\nLa norme SIRI (Service Interface for Real time Information) définit le protocole d’échange de l’information Temps Réel pour les transports collectifs (format XML). SIRI se base sur le modèle de données de référence du transport public : TRANSMODEL. SIRI a été élaborée avec la participation initiale de la France, l’Allemagne, la Norvège et le Royaume-Uni.\nLe groupe de travail français, CN03/GT7 (miroir du groupe européen CEN TC278 / WG3 / SG7) a adopté le format d’échanges NeTEX (CEN/TS 16614-1 à 6) comme base pour les échanges de données de transport en commun. Le standard NeTEx, aborde essentiellement les aspects référentiels des données échangées.\nAfin de fournir aux transporteurs et aux industriels un cadre normalisé pour l’échange de données concernant l’information temps réel, le CEN TC278 / WG3 / SG7 a décidé de lancer le projet SIRI (Service Interface for Realtime Information) dès 2004.\nAujourd’hui, la norme SIRI version 2.1 peut servir de base à toute implémentation des échanges de données temps réel, elle assure une compatibilité ascendante avec la version 1.0 qu\u0026rsquo;elle précise et lui ajoute quelques fonctions et attributs issus des retours d\u0026rsquo;expérience de mise en œuvre de la version 1.0.\nLe présent document contient le profil d’utilisation de cette spécification technique dans un contexte national français.\nIl est complété par un ensemble de documents d’accompagnement : se reporter aux annexes en fin de profil.\nDomaine d’application Le profil, objet du present document, s’applique à la spécification technique SIRI (documents [R5] à [R9] §2). Les objectifs de ce profil sont rappelés dans la suite de ce paragraphe.\nProfils La mise en place d’un profil normatif répond au constat suivant :\n Les normes sont par nature et définition des documents consensuels, en particulier pour les documents de normalisations publiés par le CEN, définis dans un contexte international. Dans le cas des normes du CEN/TC 278/WG03, cela signifie que d\u0026rsquo;une part elles prennent en compte de très nombreux besoins car elles ont été établies à un niveau européen, et d\u0026rsquo;autre part elles n\u0026rsquo;imposent pas une implémentation exhaustive immédiate, mais permettent une implémentation progressive et qui peut être limitée à un besoin bien identifié.  Ces normes prennent en compte des besoins d’implémentation qui vont au-delà des besoins nationaux.\n  La contrepartie de cette ouverture est que l\u0026rsquo;on peut facilement aboutir à des systèmes SIRI incompatibles alors même qu\u0026rsquo;ils respectent la norme : par exemple, pour peu qu\u0026rsquo;ils n\u0026rsquo;implémentent pas les mêmes services.\n  Les documents normatifs sont bien souvent très détaillés et volumineux, rendant leur consultation et lecture difficiles.\n  Des éléments proposés par la norme sont optionnels, lors de l’implémentation d’une application conforme à la norme il doit être décidé s’ils sont ou non utilisés.\n  Les spécifications techniques SIRI sont issues de ces processus de normalisation internationaux et intègrent des mécanismes répondant à des besoins Allemands ou Suisse par exemple y sont aussi intégrés des mécanismes pour faciliter la compatibilité avec le projet de norme française NEPTUNE, britannique TransXChange, NOPTIS suédoise, …\n  La norme SIRI recommande donc l\u0026rsquo;établissement d\u0026rsquo;un « Local Agreement » ou profil SIRI, qui permettra de contraindre et restreindre son implémentation dans le cadre d\u0026rsquo;un échange donné – ici, dans le cas présent, au niveau national français.\nDe plus, la norme SIRI fournit un guide pour l\u0026rsquo;établissement de ce profil.\nQualité et Cohérence des données Un des objectifs du profil est de simplifier et d’améliorer l’interopérabilité. L’interopérabilité ne peut être atteinte uniquement sur la base de la conformité au profil sans s’assurer de la qualité des données véhiculées : cohérence des données, conforme au format et decrivant la réalité.\nEn conséquence le profil doit être accompagné d’un ensemble de règles de cohérence et de qualité spécifiquement conçues pour la mise en œuvre du profil SIRI. Le respect des règles ne garantie cependant pas à 100% la qualité d’un jeu de données mais va permettre de minimiser les problèmes de cohérence.\nRéférences Normatives Les documents de référence suivants sont indispensables pour l\u0026rsquo;application du présent document. Pour les références datées, seule l\u0026rsquo;édition citée s\u0026rsquo;applique. Pour les références non datées, la dernière édition du document de référence s\u0026rsquo;applique (y compris les éventuels amendements).\n[R1] NF EN 12896 Public Transport Reference Data Model Partie 1 à Partie 4\n  Partie 1 : Common Concepts (corresponds to NeTEx Part 1 -Framework)\n  Partie 2: Public Transport Network Topology (corresponds to NeTEx Part 1- Topology)\n  Partie 3 : Timing Information and Vehicle Scheduling (corresponds to NeTEx Part 2)\n  [R2] CEN/TS 16614-1 Network and Timetable Exchange (NeTEx) - Network description\n[R3] CEN/TS 16614-2 Network and Timetable Exchange (NeTEx) - Timing information\n[R4] CEN/TS 16614-3 Network and Timetable Exchange (NeTEx) - Fare description\n[R5] EN 15531-1, Public transport - Service interface for real-time information relating to public transport operations - Part 1: Context and framework\n[R6] EN 15531-2, Public transport - Service interface for real-time information relating to public transport operations - Part 2: Communications infrastructure\n[R7] EN 15531-3, Public transport - Service interface for real-time information relating to public transport operations - Part 3: Functional service interfaces\n[R8] CEN/TS 15531-4, Public transport - Service interface for real-time information relating to public transport operations - Part 4: Functional service interfaces: Facility Monitoring\n[R9] CEN/TS 15531-5, Public transport - Service interface for real-time information relating to public transport operations - Part 5: Functional service interfaces - Situation Exchange\n[R10] XSD SIRI 2.1\nAutres documents [R11] T1 Éléments communs aux profils d\u0026rsquo;échange pour les informations planifiées du transport en commun\n[R11.1] T2 NeTEx - Profil Français de NETEx: éléments communs,\n[R11.2] T2 NeTEx - Profil Français pour les Arrêts,\n[R11.3] T2 NeTEx - Profil Français pour les horaires,\n[R11.4] T2 NeTEx - Profil Français pour les réseaux.\nTermes et définitions Cas général Dans le cadre de ce document, les termes et definitions applicables sont ceux définis dans le document CEN/EN 15531-1:2021 [R5].\nDéfinition d’un point d’arrêt La notion de point d’arrêt utilisée dans le cadre du présent profil fait référence aux concepts Transmodel [R1] suivants :\n  Point d’arrêt logique,\n  Point d’arrêt planifié (SCHEDULE STOP POINT),\n  Point d’arrêt physique,\n  Zone d’embarquement (QUAY),\n  Lieu d’arrêt monomodal (STOP PLACE),\n  Pole Monomodal (STOP PLACE).\n     DEF.1 Chacun de ces points d’arrêt doit disposer d’un identifiant spécifique indépendamment de son type.     Le point d’arrêt physique peut être ou non rattaché à un point d’arrêt logique, selon les implémentations, par l’intermédiaire d’une affectation (STOP ASSIGNMENT). La figure ci-après illustre ces relations (Profil NeTEx France [R11.4]).\nDéfinitions de « Départ » et « Arrivée » D’un point de vue fonctionnel les notions d’arrivée et de départ sont définies ci-dessous. Ces notions osnt utilisés par plusieurs services SIRI (ET, SM) pour échanger des heures d’arrivée et de départ, estimées ou échues.\nArrivée\nUne arrivée correspond à un événement permettant au premier passager d’être en mesure de débarquer à un endroit particulier (par rapport au trajet et à l\u0026rsquo;arrêt donnés). En règle générale, il s\u0026rsquo;agit du moment où les portes du véhicule sont (ou pourraient être) ouvertes pour la première fois après leur deverrouillage. Peu importe que les passagers montent ou descendent effectivement à l\u0026rsquo;arrêt ou que les portes aient été ouvertes en premier lieu.\nDépart\nUn départ correspond à un événement permettant au dernier passager d’être en mesure d\u0026rsquo;embarquer à un endroit particulier (par rapport au trajet et à l\u0026rsquo;arrêt donnés). En règle générale, il s\u0026rsquo;agit du moment où les portes du véhicule sont (ou pourraient être) fermées pour la dernière fois avant l\u0026rsquo;enclenchement de la serrure.\nDans certains cas, la condition d\u0026rsquo;ouverture ou de fermeture d\u0026rsquo;une porte n\u0026rsquo;est pas satisfaite et donc un événement tel que défini ci-dessus ne peut pas être enregistré avec précision :\n• Un véhicule passe par un arrêt sans réellement s\u0026rsquo;arrêter ou ne s\u0026rsquo;arrête que brièvement sans ouvrir ses portes, par exemple, dans le cas où l\u0026rsquo;arrêt était facultatif et que personne ne l\u0026rsquo;a demandé. Dans un tel cas, l\u0026rsquo;événement d\u0026rsquo;arrivée et de départ sont tous deux enregistrés en même temps lorsque le véhicule passe la position d\u0026rsquo;arrêt.\n• Un événement d\u0026rsquo;arrivée à un arrêt où il est interdit de descendre est enregistré soit au moment où la serrure est déverrouillée pour la première fois, lorsque le véhicule s\u0026rsquo;arrête (si la serrure n\u0026rsquo;a jamais été déverrouillée) ou lorsque le véhicule passe la position d\u0026rsquo;arrêt (si le véhicule ne s\u0026rsquo;arrête pas réellement).\n• Un événement de départ à un arrêt où l\u0026rsquo;embarquement est interdit est soit enregistré au moment où la serrure est enclenchée pour la dernière fois, lorsque le véhicule commence à rouler (si la serrure n\u0026rsquo;a jamais été déverrouillée) ou lorsque le véhicule franchit l\u0026rsquo;arrêt position (si le véhicule ne s\u0026rsquo;arrête pas réellement).\nDéfinition de la structure LEADER La description des services SIRI fait référence à une structure LEADER.\n   LEADER ::: 1:1 xxx­Delivery voir xxxDelivery.     Le Leader est (indirectement) défini dans la spécification SIRI [R6] par les attributs suivants :\n   xxxDelivery  +Structure Réponse pour le service xxx.       Log Response­Timestamp 1:1 xsd:dateTime Heure de creation de la response.    End­point prop­erties RequestMessageRef 0:1 ➞ Message­Qualifier Pour les requêtes directes, identifiant de la requête origine de la réponse.   SubscriberRef 0:1 ➞ Participant­Code Obligatoire si la réponse concerne un Abonnement, Identfiant de l’abonné.   Subscription­FilterRef 0:1 ➞ SubcriptionFilterCode Identifiant unique du filtre d'abonnement auquel cet abonnement est affecté. S'il n'y a qu'un seul filtre, alors ce champ peut être omis.   Subscription­Ref 1:1 ➞ Subscript­ion­Qualifier Obligatoire si la réponse concerne un Abonnement.\nIdentifiant de l'Abonnement émis par le Demandeur.\n  Status Status 0:1 xsd:boolean Indique si la demande complète a pu être traitée avec succès ou non. La valeur par défaut est true.\nSi l'une des demandes individuelles de la diffusion a échoué, doit être à \"false\".\n   ErrorCondition 0:1 +Structure Description de toute condition d'erreur ou de warning qui s'applique à la demande ou à la réponse.   ➞ choix -1:1  Un des codes erreurs suivants.   a) Capability­Not­Supported­Error 0:1 + Error Erreur : fonctionnalité non prise en charge.   b) AccessNot­Allowed­Error 0:1 +Error Erreur : le demandeur n'est pas autorisé à accéder au service ou aux données demandés.   c) NoInfoFor­TopicError 0:1 +Error Erreur : une demande valide a été effectuée, mais le service ne contient aucune donnée pour l'expression de rubrique demandée.   d) Allowed­Resource­Usage­Exceeded­Error 0:1 +Error Erreur : une demande valide a été effectuée, mais la demande dépasserait l'utilisation autorisée des ressources du client.   e) OtherError 0:1 +Error Erreur autre   ➞ Description 0:1 ➞ ErrorDescription Description de l’erreur.   ValidUntil 0:1 xsd:dateTime Limite de validité des données.   Shortest­Possible­Cycle 0:1 Positive­Duration­Type Intervalle minimum auquel les mises à jour peuvent être envoyées.   DefaultLanguage 0:1 Xsd:language Langue par défaut des éléments de texte.     Référentiel théorique Le référentiel théorique est l’objet d’un accord entre les parties.\nIl repose sur des échanges :\n  non définis par le présent profil (NeTEx par exemple),\n  ou à base de service Discovery (cf paragraphe 5.6).\n  Description du profil d’échange Règles de gestion du profil Le present profil contient un ensemble de règles de gestion applicables. Ces règles de gestion sont présentées sous forme tabulaire et numérotées.\n   Numéro Intitulé de la règle    Des textes explicatifs viennent compléter les règles d’application du profil FR.\nConventions \u0026amp; Représention des messages Les messages constituant ce profil d\u0026rsquo;échange sont décrits en adoptant un formalisme tabulaire. Les tableaux proposent ces colonnes:\n    Classification Nom de l’élement Min :\nMax Type de données Description    La structure des tableaux présentée ici est exactement la même que celle des tableaux des documents SIRI de référence ceci afin de simplifier le passage d\u0026rsquo;un document à l\u0026rsquo;autre.\nLes tableaux sont simplement complétés et enrichis des informations propres au profil SIRI France.\nUne description détaillée de la structure de ces tableaux est présentée dans le document « SIRI- partie 1 - 4.3-Notation pour les structures de modélisation XML des messages SIRI ».\nPour mémoire les principaux éléments présentés sont les suivants :\n  Dans la documentation SIRI, les structures sont présentées sous forme tabulaire. L\u0026rsquo;en-tête des colonnes est supposé connu et n\u0026rsquo;est donc pas systématiquement répété.\n  Les tableaux utilisent un ensemble de conventions pour les éléments XML et leurs contraintes.\n  Les éléments constitutifs de ces tableaux sont présentés ci-dessous.\nClassification (Organisational Group label) Cette première colonne précise la catégorie de l\u0026rsquo;élément, par exemple ‘Payload’ (qui se traduit littéralement par « charge utile », et correspond à la description de l\u0026rsquo;objet lui-même indépendamment de toute donnée d\u0026rsquo;accompagnement, et autres en-têtes).\nPar exemple :\n  Attributes,\n  Log,\n  Endpoint,\n  Status,\n  Payload.\n  Nom de l\u0026rsquo;élément (Element Name) Cet élément correspond naturellement au nom de l\u0026rsquo;élément présenté. Si l\u0026rsquo;élément appartient à une structure complexe, le nom de l\u0026rsquo;élément père (ou racine) est présenté en haut du tableau.\nLa notation « :: » fait référence à un groupe d\u0026rsquo;éléments défini à un autre endroit du document (la colonne Type de Données permettra de retrouver cette définition).\nDans les cas d\u0026rsquo;éléments composés, une indication « voir ci-dessous » figure dans la colonne type et les sous-éléments sont présentés en dessous avec une indentation (c\u0026rsquo;est le cas de ErrorCondition cf 3.2.5).\nCardinalité et choix (Multiplicity \u0026amp; Choice (Min:Max)) Cette colonne précise la cardinalité de l\u0026rsquo;élément sous la forme :\n  [nombre minimal d\u0026rsquo;occurrences]:[nombre maximal d\u0026rsquo;occurrences],\n  Un nombre d\u0026rsquo;occurrence valant « * » signifie « nombre illimité ».\n  Si cet indicateur est préfixé d\u0026rsquo;un tiret (par exemple « –1:1 ») cela signifie qu\u0026rsquo;il faut choisir un élément (ou plusieurs) parmi une liste indiquée (‘choice’ au niveau XSD).\nSi la cardinalité SIRI est précisée pour le profil SIRI France, cela sera aussi noté, en complément dans cette colonne et surligné en gris.\nLes différentes possibilités d\u0026rsquo;exprimer la cardinalité sont donc les suivantes :\n  En noir sur fond blanc : la cardinalité est celle spécifiée par le document normatif SIRI (en particulier, toutes les notations de type « 1:1 » ou « 1:* » signifient que le champ est obligatoire). Ces champs font partie du profil SIRI France.\n  En noir surligné en gris: la cardinalité du document normatif SIRI est précisée par le profil SIRI France (pour rendre un champ facultatif obligatoire ). C\u0026rsquo;est alors la version surlignée en gris qui s\u0026rsquo;applique.\n  En noir surligné en vert : la cardinalité du document normatif SIRI est précisée par le profil SIRI France pour la mise en place des concentrateurs . En effet, les concentrateurs ont des spécificités, en particulier en terme de volumétrie et de mise en cohérence de données multi-sources qui nécessitent certaines adaptations par rapport au cas général. Les commentaires y attenant seront aussi surlignés en vert.\n  Type de données (Data Type) Cette colonne indique le type de l\u0026rsquo;élément:\n  soit un type simple (SIRI ou XSD) comme Positive­DurationType ou xsd:dateTime\n  soit un type structuré, signalé par +Structure (la définition de la structure porte alors le nom de l\u0026rsquo;élément suffixé par le terme Structure),\n  les références (par identifiant) sont signalées, sous la forme OperatorCodeRef (référence à un opérateur, dont on fournit le code ou identifiant, dans ce cas),\n  dans le cas des énumérations, la liste des valeurs est indiquée (éléments séparés par une barre verticale : « | »),\n  Pour les types les plus classiques, l\u0026rsquo;abréviation est autorisée quand le nom est long (NLString pour NaturalLanguageString ou Error pour ErrorStructure).\nCe type permet de définir les chaines de caractères associées à une langue. La structure est la suivante :\n     NaturalLanguageStringStructure          Name Type Cardinality Description    attribute Xml :lang string 0 :1 La langue doit etre spécifiée sous la forme d’un code de 3 lettre conformément à l’ISO 639-3 ou un code sur 2 caractères conformément à l’ISO 639-1RFC 1766.\nPar défaut interprété comme «FRA». Si la langue n’est pas le francais ce champ DOIT être renseigné.\n  Element (element content) String 1:1 Texte du message.    Description (Description) On trouve dans cette colonne la description textuelle de l\u0026rsquo;élément.\nLe tableau ci-dessous est un exemple de tableau SIRI (non traduit pour celui-ci, étant donné que son contenu n\u0026rsquo;a pas d\u0026rsquo;importance).\n    Classification Nom de l’élement Min :\nMax Type de données Description  MyMessageResponse   +Structure Returns data for a MyMessage Request    Attributes srsName 0:1 xsd:string Default GML coordinate format for any spatial points defined in response by Coordinates parameter.  Log Response­Timestamp 1:1 xsd:dateTime Time individual response element was created.  Endpoint Producer­Ref 0:1 Participant­Code Participant reference that identifies producer of data. May be available from context.   ::: 0:1 MyAdd­Group MyAddress Group elements. See section 101.0.  Status Status 0:1 xsd:boolean Whether the complete request could be processed successfully or not. Default is true.   Error­Condition 0:1 See below Description of any error or warning conditions that apply to the overall request.   ➞ choix -1:1  One of the following error codes.   a) Capability­Not­Supported­Error 0:1 +Error Capability not supported.   b) Other­Error 0:1 +Error Error other than a well defined category.   ➞ Description 0:1 Error­Description Description of Error.  Payload Expected­Life­Time 1:1 Positive­Duration­Type How long I expect to live. Time interval.   MyWay 0:1 foo | bar Which way I did it. Default is ‘foo’.   Xxx­Delivery 0:* +Structure See SIRI Part 3 – Functional Service.    Indentation des données La représentation des données imbriquées est représentée en utilisant les symboles ➞ et ⇉ pour indiquer le niveau d’imbrication.\n   Nom Card Type Description     Donnée Niv 1  +Structure Cette information est constituée des structure « Donnée 1 Niv 2 » et « Donnée 2 Niv 2 »   ➞ Donnée 1 Niv 2 1:* +Structure « Donnée 1 Niv 2 » définie par ailleurs   ➞ Donnée 2 Niv 2 1:* +Structure « Donnée 2 Niv 2 » est une structure constituée de « Donnée 1 Niv 3 » et « Donnée 2 Niv 3 » definies ci-apres   ⇉ Donnée 1 Niv 3 0:1 Type 1 Donnée de « Donnée 2 Niv 2 »   ⇉ Donnée 2 Niv 3 0:1 Type 2 Donnée de « Donnée 2 Niv 2 »    Partie I - Description du cadre Définition des concepts fondamentaux Le présent profil s’appuie sur les concepts définis dans Transmodel [R1].\nCas d’usage Les principaux cas d’usage SIRI, dans un environnement national français, sont synthétisés dans la suite de ce paragraphe. Ils sont détaillés dans le document d’accompagnement [A1].\nCette liste des cas d’usage ne se veut pas exhaustive et peut être complétée localement pour répondre à des besoins spécifiques.\nPour chaque cas d’usage, une préconisation de services SIRI à implémenter est présentée en conclusion du paragraphe. Les préconisations s’appuient sur les ‘bonnes pratiques’ d’implémentation SIRI [A3].\nDans ce cadre, chaque service SIRI d’un cas d’usage est qualifié ‘Indispensable’ ou ‘Facultatif’.\n  Indispensable : indique que, pour le cas d’usage identifié, le respect des bonnes pratiques d’implémentation tend à l’utilisation de ce service. Dans le cas ou un autre service SIRI serait retenu, l’implémentation sortirait du contexte d’utilisation et correspondrait alors un autre cas d’usage.\n  La non-implémentation d’un service ‘Indispensable’ ne veut pas dire que cette implémentation n’est pas conforme au profil SIRI France, seule la conformité aux règles de gestion et aux règles d’implémentation des services le sont.\n  ‘Facultatif’ : indique que le service SIRI peut être utilisé en complément du ou des services SIRI obligatoires mais que le cas d’usage peut être respecté sans son implémentation.\n  Diffusion inter systèmes Ce cas d’usage doit permettre à différents systèmes de transport d’échanger des flux d’information relatifs à l’information voyageur. Ces échanges leur permettent de réaliser des traitements de cette information indépendamment les uns des autres et en parfaite cohérence.\nDans ce cadre, SIRI permet l’échange d’informations multimodales et multi opérateurs. Ces flux ne sont pas à destination directe des usagers.\nLes systèmes concernés peuvent être des SAE, des SIV, des systèmes d’affichage, …\nCet alignement repose sur un échange préalable de données théoriques (topologie et offre de transport) qui sont mises à jour entre les différents systèmes interconnectés via SIRI.\nCes échanges s’appuient sur le protocole de communication SIRI définis dans la partie 2 de la spécification [R6].\nLa description de ce cas d’usage est définie dans le document d’accompagnement [A1].\nDiffusion Terminaux légers Il s\u0026rsquo;agit ici de permettre à un utilisateur d\u0026rsquo;accéder aux informations horaires temps réel (prochains passages avec indications de ligne, de direction, ainsi que les éventuels messages) pour n’importe quel point d’arrêt, indépendamment du transporteur, et ce à partir d\u0026rsquo;un terminal mobile de type téléphone portable.\nCe service pourra ainsi être utilisé sur le réseau (à l\u0026rsquo;arrêt dans le cas où il n\u0026rsquo;y aurait pas d\u0026rsquo;afficheur, permettant ainsi à l\u0026rsquo;exploitant de mettre le service à disposition sans que les coûts ne soient trop importants, autorisant ainsi plus facilement la couverture de ligne ou zones à faible fréquentation) ou hors réseau (pour synchroniser son départ avec l\u0026rsquo;arrivée du train ou du bus par exemple).\nSIRI est ici utilisé pour permettre au système de présentation qui gère le dialogue avec les terminaux mobiles d\u0026rsquo;accéder aux informations horaires temps réel de prochain passage.\nCe cas d\u0026rsquo;utilisation peut être généralisé à un accès avec tout autre type de terminal, en particulier via un accès de type Web, pour diffuser les informations horaires et les informations de perturbation.\nA noter que pour ce cas d’usage les protocoles de communications SIRI lite sont à privilégier.\nLa description de ce cas d’usage est définie dans le document d’accompagnement [A1]\nCentrale de mobilité Les centrales de mobilité prennent en compte les transports en commun sur une échelle relativement large, impliquant ainsi quasi systématiquement plusieurs transporteurs.\nL\u0026rsquo;un des services clés de ce type de centrale de mobilité est souvent le calcul d’itinéraires, qui se limite de moins en moins à la prise en compte des horaires théoriques (pour cause d’indisponibilité des données, et non pour des raisons techniques).\nLa prise en compte des informations temps réel est un besoin qui, dans ce contexte, s\u0026rsquo;exprime à deux niveaux:\n  la prise en compte des perturbations (prévues, c\u0026rsquo;est-à-dire connues plus ou moins longtemps avant le départ, ou inopinées) pour, d\u0026rsquo;une part, les signaler à l\u0026rsquo;usager et, d\u0026rsquo;autre part, lui proposer des solutions alternatives lui permettant de « sécuriser » son trajet,\n  la prise en compte des informations horaires temps réel pour optimiser le déplacement (le train que l\u0026rsquo;on ne pensait pas pouvoir prendre à une correspondance devient disponible suite à un léger retard ou encore un retard trop important impliquant une modification de l\u0026rsquo;itinéraire, etc).\n  L\u0026rsquo;apport de la norme SIRI est ici clairement de permettre aux SAE de diffuser vers la centrale de mobilité l\u0026rsquo;ensemble des informations temps réel nécessaires pour la mise en place des services.\nLa description de ce cas d’usage est définie dans le document d’accompagnement [A1].\nGestion des perturbations La prise en compte des perturbations telle qu\u0026rsquo;elle est souvent mise en oeuvre dans les systèmes actuels se limite souvent à un message textuel libre ou pré-formaté et associé à un arrêt, une ligne, un itinéraire ou une mission. La norme SIRI permet de transmettre la perturbation de manière codifiée ; elle permet :\n  de décrire finement la cause de la perturbation,\n  de lister les conséquences liées à cette perturbation,\n  de permettre une prise en compte par un calculateur d’itinéraires,\n  de générer automatiquement des messages, avec prise en compte du type de périphérique (petits messages pour les SMS, longs messages pour le Web, etc.) ou de générer ces messages en plusieurs langues (il ne s’agit naturellement pas d’une fonction de SIRI mais d’une fonction qui pourra être mise en œuvre par l’émetteur ou par le récepteur sur la base des données structurées),\n  d\u0026rsquo;associer la perturbation à un tronçon de ligne,\n  de gérer des périodes de validité complexes (i.e. : du lundi au vendredi de 8 h à 18 h),\n  de mettre à jour le « fil de perturbation » en ayant la possibilité d’identifier les mises à jour d\u0026rsquo;une perturbation.\n  La description de ce cas d’usage est définie dans le document d’accompagnement [A1].\nInformation PMR Informer les PMR ou toute personne ayant des besoins particuliers (en particulier les handicaps auditifs, visuels, moteurs, etc., mais aussi à tous les besoins particuliers comme « utilisation d\u0026rsquo;une poussette », « lourdement chargé en bagage », « jambe dans le plâtre », etc.) est un besoin avéré.\nCe type de besoin comporte une composante temps réel afin de pouvoir informer sur l\u0026rsquo;état des équipements et des services (i.e. : disponibilité ou non d\u0026rsquo;un ascenseur, d\u0026rsquo;un escalier mécanique, d\u0026rsquo;une palette, d\u0026rsquo;un dispositif visuel, etc.).\nSur la base des services SIRI, des systèmes d\u0026rsquo;acquisition et de supervision ou des systèmes impliquant une saisie par un opérateur (la vérification d\u0026rsquo;état des équipements est aujourd\u0026rsquo;hui réalisée de façon manuelle dans de très nombreux cas) peuvent diffuser leurs informations de perturbation.\nLa description de ce cas d’usage est définie dans le document d’accompagnement [A1].\nConcentrateur Les concentrateurs permettent de rassembler au sein d’un même système un ensemble d’informations voyageur d’origine et de formes diverses dans un format pivot (en principe conforme aux concepts Transmodel) pour les mettre à disposition de systèmes clients.\nLe flux entrant et sortant du concentrateur peuvent s’appuyer sur SIRI. En général les systèmes historiques peuvent fournir aux concentrateurs les informations dans des formats autres, le concentrateur redistribuant les données en utilisant SIRI :\n  les centrales de mobilité,\n  les systèmes pour les agents sur le terrain,\n  les afficheurs,\n  des terminaux dédiés (système prévu spécifiquement pour gérer un type de handicap),\n  etc.\n  Conformité Directive EU La loi n° 2019-1428 du 24 décembre 2019 d\u0026rsquo;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\u0026rsquo;ensemble de l\u0026rsquo;Union, de services d\u0026rsquo;informations sur les déplacements multimodaux) rendent obligatoire la mise à disposition, quand elles existent, de certains types de données.\nLe 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).\nLes concepts présents dans les tableaux sont ceux directement référencés à l’annexe du règlement européen Délégué (UE) 2017/1926 de La Commission du 31 mai 2017 (https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=CELEX:32017R1926\u0026amp;from=FR) qui impliquent d’autres concepts (soit par héritage soit par relation, au 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.\nDe plus, 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.\nPour 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 « Services à minima » correspond alors au minimum à fournir pour répondre à la catégorie en question et les colonnes « Autres services » décrivent des informations complémentaires qui, si elles sont utiles, ne sont pas indispensables pour répondre à cette catégorie.\nIl 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).\nLa 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).\nLes 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).\nTable 1 – Concepts relatifs à la LOM et à la Règlementation Européenne\n  Niveau Catégorie Détail Service à minima Autres\nservices\n Commentaire    1 Passing times, trip plans and auxiliary information Disruptions (all modes) General Message Situation Exchange Note : tout ce qui peut être échangé avec General Message peut aussi l’être avec Situation Exchange: pour anticiper les évolutions à venir il peut donc être préférable de tout de suite porter son choix sur Situation Exchange.  1 Passing times, trip plans and auxiliary information Real-time status information — delays, cancellations, guaranteed connections monitoring (all modes) General Message Situation Exchange Note : tout ce qui peut être échangé avec General Message peut aussi l’être avec Situation Exchange: pour anticiper les évolutions à venir il peut donc être préférable de tout de suite porter son choix sur Situation Exchange.  1 Passing times, trip plans and auxiliary information Status of access node features (including dynamic platform information, operational lifts/escalators, closed entrances and exit locations — all scheduled modes) General Message Situation Exchange\nFacility Monitoring Note : tout ce qui peut être échangé avec General Message peut aussi l’être avec Situation Exchange: pour anticiper les évolutions à venir il peut donc être préférable de tout de suite porter son choix sur Situation Exchange.  2 Passing times, trip plans and auxiliary information (all modes) Estimated departure and arrival times of services Estimated Timetable  Stop Monitoring pour heure de départ ou de passage mais ne permet pas de savoir l’heure d’arrivée.\nEstimated Timetable pour une vue complète départ/arrivée.\nATTENTION: la notion d'heure de départ/arrivée peut donner lieu à débat\n  2 Information service Availability of publicly accessible charging stations for electric vehicles and refuelling points for CNG/LNG, hydrogen, petrol- and diesel-powered vehicles Facility Monitoring    2 Availability check Car-sharing availability, bike sharing availability Facility Monitoring    2 Availability check Car parking spaces available (on and off-street), parking tariffs, road toll tariffs Facility Monitoring      Services SIRI applicables     Service Diffusion Inter Systèmes Diffusion Terminaux Legers Centrale de Mobilité Diffusion dans les vehicules Gestion des perturbations Information PMR Concentrateur Directive EU    Horaires planifiés\nProduction Timetable\n          Horaires calculés\nEstimated Timetable\n Indispensable  Indispensable    Indispensable Indispensable  Horaires planifiés à l’arrêt\nStop Timetable\n          Discovery Line       Facultatif1   Horaires calculés à l’arrêt\nStop Monitoring\n  Indispensable  Facultatif   Facultatif Facultatif  Discovery Stop       Facultatif2   Supervision des véhicules\nVehicle Monitoring\n    Indispensable   Facultatif   Correspondances planifiées\nConnection Timetable\n          Correspondances calculées\nConnection Monitoring\n    Facultatif      Messagerie\nGeneral Messaging\n Facultatif Facultatif Facultatif Indispensable Facultatif Facultatif Indispensable Indispensable (uniquement si SX n’est par retenu)  Gestion des événements\nSituation Exchange\n   Indispensable Facultatif Indispensable Indispensable Facultatif Facultatif  Etat des équipements\nFacility Monitoring\n   Facultatif   Indispensable  Indispensable     En complément du Service ET↩︎\n En complement du Service SM↩︎\n   Règles de gestion\n   CU-1 Si le service SX est disponible, toute information diffusée via GM doit aussi l’être en SX    CU-2 Si le service SIRI SX est implémenté, GM ne devient qu'un service pour compatibilité avec les systèmes ne sachant pas recevoir du SX.\nSX devient la référence pour les informations circonstancielles et doit donc contenir toutes les informations.\n    Protocoles d’échange des données SIRI Les échanges de données SIRI entre Systèmes reposent l’echange de fichiers XML via la mise en œuvre du protocole SOAP. A noter que la mise en œuvre d’une interface SIRI Lite repose sur des échanges de fichiers XML ou JSON via une API REST.\nDans le cadre d’autres usages type OPEN DATA, l’utilisation d’autres mécanismes est possible : message broker type MQTT, XML sans SOAP, API REST, ….\nPartie II - Application du Profil SIRI France Modalités d’application Après avoir retenu les services SIRI pour les cas d’utilisation identifiés (Partie 1), les principales actions à effectuer sont les suivantes:\n Identifier les données de référence, objet de la partie 2 de ce document :    Participants,\n  Identifiants des lignes, des itinéraires et des missions,\n  Identifiants des points d’arrêt (et type de point d’arrêt…),\n  Identifiants des correspondances,\n  Préciser les listes de valeurs supportées (ServiceCategory, ProductCategory, VehicleFeature) .\n  Définir le profil technique lui-même :    Type d’abonnement (1 ou 2 phases),\n  Support de la segmentation des messages,\n  Confirmation ou non des notifications,\n  Filtres simples ou multiples,\n  Supervision de la disponibilité des partenaires,\n  Signification des champs fonctionnels,\n  …\n   Préciser l’utilisation des champs facultatifs dans les messages des services retenus (un champ facultatif dans la norme peut être supprimé, devenir obligatoire ou rester facultatif dans le profil…)\n  Définir éventuellement des extensions (ajout de champs non normalisés) propres à l’implémentation locale.\n  Implémentations locales: éléments à préciser dans les protocoles d’accord Le paragraphe suivant présente les aspects techniques à traiter pour l’implémentation, il est à noter que ces aspects ne font pas partie intégrante du local agreement SIRI France et sont présentés ci-dessous à titre indicatif.\nLe profil ne peut en effet pas définir tous les aspects nécessaires à la mise en place d’un échange. Ces éléments devront donc être définis dans le cadre des protocoles locaux établis entre les différents acteurs des échanges.\n  L\u0026rsquo;identification des infrastructures d’alimentation (et processus correspondant) : à définir spécifiquement pour chaque implémentation (par exemple le mode de connexion de l’interface SIRI au SAE…)\n  Le choix d’utilisation des champs laissés facultatifs par le profil France dans les messages et services retenus (un champ facultatif peut être supprimé, devenir obligatoire ou rester facultatif), sans que la WSDL SIRI France ne soit modifiée.   Des préconisations pour la gestion et l\u0026rsquo;organisation des systèmes (annexe recommandée par la norme SIRI, à traiter dans le contexte de chaque protocole d’accord local) :\n    Contacts et responsables opérationnels,\n  Surveillance des services,\n  Période d’interruption des services,\n  Identification/gestion des anomalies.\n  Référentiels de données Présentation du besoin La mise en place d\u0026rsquo;un échange de données implique que les systèmes mis en relation puissent identifier de façon non ambiguë les objets auxquels ils font référence.\nCela est particulièrement vrai pour SIRI qui, de par sa vocation à échanger des informations temps réel, ne re-décrit pas le référentiel sous-jacent et le suppose donc connu.\nIl sera donc indispensable, pour demander les prochains horaires de passage à un arrêt, de connaître l\u0026rsquo;identifiant de l\u0026rsquo;arrêt en question. Cela concerne tout un ensemble d\u0026rsquo;objets listés ci-dessous.\nIl faut rappeler que l\u0026rsquo;identification de l\u0026rsquo;objet est une chose, mais que le concept sous-jacent en est une autre.\nLa cohérence doit porter sur ces deux aspects. Les principaux concepts utiles ont été évoqués au chapitre précédent. Pour les autres, TRANSMODEL fait référence.\nNote: le nom des objets est donné en français et en anglais, de façon à simplifier une éventuelle recherche complémentaire dans les documents normatifs.\nRéférences utilisées dans le cadre du profil SIRI France     Donnée de référence Référence adoptée pour le profil SIRI France    Date et Heure\n(Date \u0026amp; Time)\n ISO 8601  Langue\n(Language)\n ISO 639-1  Localisation géographique\n(Location)\n WGS84 / gml (GML permettra d'échanger les localisations géographiques dans des référentiels projetés comme Lambert 2 étendu)  Fournisseur d'information\n(Information Provider)\n Voir le paragraphe correspondant (Erreur ! Source du renvoi introuvable.)\nNotion à mettre en relation avec le groupement ou le transporteur qui délivre l’information.\n  Point d'arrêt\n(Stop Point)\n Voir le paragraphe correspondant (5.4.1.1)\nDans l'état actuel des choses, il n'existe aucun référentiel global des points d’arrêt en France.\n  Correspondance\n(Connection)\n Dans l'état actuel des choses, il n'existe aucun référentiel global des correspondances en France.\nDans un premier temps, l'identification des correspondances devra donc être réalisée au cas par cas, et définie entre les acteurs avant de débuter un échange. L'identification devra dans ce cas porter une indication signalant qu'elle est spécifique à un échange local.\nCela concernera uniquement les cas où l'on souhaite gérer une correspondance et où l'on souhaitera être informé du fait qu'elle n'est plus possible (le bus signale qu'il décide de ne pas attendre le train, par exemple).\n  Véhicule supervisé\n(VehicleActivity)\n Dans le cadre du profil SIRI France, cette donnée ne peut être utile que pour permettre d'identifier la position d’un véhicule.\nSi l’on souhaite connaître l'état des services dans le véhicule (état de fonctionnement de la palette par exemple), il sera alors plus simple de passer par l'identification de la course que par celle du véhicule.\n  Course\n(Vehicle Journey)\n L'identification des courses devra donc être réalisée au cas par cas, et définie entre les acteurs avant de débuter un échange. L'identification devra dans ce cas porter une indication signalant qu'elle est spécifique à un échange local.  Numéro de passage à un Point d'arrêt sur une mission\n(Stop Visit In Pattern)\n Parmi les solutions proposées par SIRI, le profil SIRI France retient celle qui consiste à attribuer un numéro d'ordre dans la mission à chacun des arrêts.  Ligne\n(Line )\n A date, il n’existe aucun référentiel global des lignes en France. L'identification des lignes devra donc être réalisée au cas par cas, et définie entre les acteurs avant de débuter un échange. L'identification devra dans ce cas porter une indication signalant qu'elle est spécifique à un échange local.  Itinéraire\n(Route)\n A date, il n’existe aucun référentiel global des itinéraires en France. L'identification des itinéraires devra donc être réalisée au cas par cas, et définie entre les acteurs avant de débuter un échange. L'identification devra dans ce cas porter une indication signalant qu'elle est spécifique à un échange local.  Mission\n(Journey pattern)\n A date, il n’existe aucun référentiel global des missions en France. L'identification des Missions devra donc être réalisée au cas par cas, et définie entre les acteurs avant de débuter un échange. L'identification devra dans ce cas porter une indication signalant qu'elle est spécifique à un échange local.  Direction\n(Direction)\n Cette notion a été introduite par SIRI pour pallier les cas où la notion d’itinéraire n'est pas formalisée.  Destination\n(Destination)\n Cette notion a été introduite par SIRI pour pallier les cas ou la notion de mission n'est pas formalisée.\nDans le cadre du profil SIRI France, les destinations seront systématiquement les extrémités des missions, et donc leur dernier point d'arrêt (dont on utilisera l'identifiant).\n  Version des horaires théoriques\n(Schedule Version)\n Cette notion permet de référencer la version des données horaires théoriques sous-jacente.\nL'identification de version du référentiel devra donc être réalisée au cas par cas, et définie entre les acteurs avant de débuter un échange. L'identification devra dans ce cas porter une indication signalant qu'elle est spécifique à un échange local.\nPour mémoire, son principal usage est de permettre d'identifier une éventuelle désynchronisation entre les référentiels (horaires et réseaux) qui pourrait amener à ce que, par exemple, un point d'arrêt connu par l'une des parties de l'échange ne le soit pas de l'autre.\n  Mode et sous-mode de transport\n(Product Category)\n L'ensemble des valeurs proposées par SIRI est retenu pour le profil SIRI France.\nVoir 3.3.11.3 dans le document SIRI Partie 1\nCette liste est très détaillée mais permet d'être certain de ne pas avoir à la compléter à l'avenir.\n  Identification du véhicule, type de véhicule\n(Vehicle Feature)\n L'ensemble des valeurs proposées par SIRI est retenu pour le profil SIRI France.\nVoir 3.3.13 dans le document SIRI Partie 1 et sa mise à jour pour le service Facility Monitoring\nCette liste est très détaillée mais permet d'être certain de ne pas avoir à la compléter à l'avenir.\n  Type de service\n(Service Feature)\n L'ensemble des valeurs proposées par SIRI est retenu pour le profil SIRI France.\nVoir 3.3.13 dans le document « SIRI Partie 1 » et sa mise à jour pour le service Facility Monitoring\nCette liste est très détaillée mais permet d'être certain de ne pas avoir à la compléter à l'avenir.\n    Note : Il faut rappeler que, d’une façon générale, pour des échanges locaux, il n’est pas indispensable de disposer d’un référentiel complet pour échanger les données temps réel (notamment mission, course, …). Le sous-ensemble d’objets ci-dessus peut en effet suffire, tout dépendra du cas d’utilisation mis en œuvre.\nGestion des Identifiants Structure des identifiants L’objectif d’une codification est de s’assurer de l’unicité (au niveau national) et de la pérennité de l’identifiant. Toute solution, 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 différente de celle proposée par le Profil NeTEx France [R11.1], cela est tout à fait acceptable ;\nIl 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).\nNOTE IMPORTANTE : Un mécanisme de codification des identifiants est proposé par le profil NeTEx France « Eléments commun » [R11.1]. Ce mécanisme de construction a pour vocation d’assurer 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 !\nIdentifiants SIRI Cette liste non exhaustive devra être complétée si nécessaire lors des développements. Ces identifiants pourront aussi évoluer si nécessaire (ex : cas de doublon pour deux identifiants). Des précisions sur ces formats d\u0026rsquo;identifiant pourront être apportées dans les spécifications d\u0026rsquo;interface de chacun des systèmes.\n    Champ SIRI Identifiant SIRI    DataFrameRef [CODESPACE]:DataFrame::[identifiantTechnique]:[LOC]  DatedVehicleJourneyRef [CODESPACE]:VehicleJourney::[identifiantTechnique]:[LOC]\nNote: DatedVehicleJourneyRef est le champ de la structure FramedVehicleJourneyRef contenant la référence à la course datée elle-même.\n  DestinationRef Comme un identifiant d'arrêt  DirectionRef DirectionRef est un code (code ouvert, limité à \"aller\" ou \"retour\" ou vide, sans format particulier donc). Normalement non retenu par le profil SIRI France, mais parfois obligatoire dans SIRI  FormatRef Utilisé pour General Message ; le format est spécifique au contexte France et doit contenir la valeur fixe « France » (valeur sans format particulier)  FramedVehicleJourneyRef FramedVehicleJourneyRef est une structure, la référence elle-même est portée par la référence à la course datée elle-même DatedVehicleJourneyRef décrit plus haut. La course étant spécifique d'un SAE, on complétera autant que possible le code Opérateur de [Fournisseur] par un code permettant d'identifier le SAE producteur.  InfoChannelRef C'est un code technique seul qui est utilisé pour l'InfoChannelRef. Il peut valoir \"Perturbation\", \"Information\" ou \"Commercial\" (valeur sans format particulier).  InfoMessageIdentifier [CODESPACE]:InfoMessage::[identifiantTechnique]:[LOC]  ItemIdentifier [CODESPACE]:Item::[identifiant Unique de l'Information]:[LOC]\nLa partie [identifiant Unique de l'Information] pourra etre construite en s'appuyant sur l'identifiant de véhicule pour Vehicle Monitoring, et sur le InfoMessageIdentifier pour General Message.\nPour les passages à l'arrêt (StopMonitoring en particulier), la forme est la suivante:\n[CODESPACE]:Item::[identifiantTechnique du couple Arrêt – Course]:[LOC]\n  ItemRef [CODESPACE]:Item::[identifiantTechnique]:[LOC]  JourneyPatternRef [CODESPACE]:JourneyPattern::[identifiantTechnique]:[LOC]  LineRef [CODESPACE]:Line::[identifiantTechnique]:  MessageIdentifier [CODESPACE]:Message::[identifiantTechnique]:[LOC]  MonitoringRef Comme pour les arrêts  OperatorRef [CODESPACE]:Operator::[identifiantTechnique]:  OriginRef Comme pour les arrêts  PlaceRef Cet identifiant a la particularité de pouvoir identifier un lieu quelconque, pouvant en particulier être un arrêt (pour mémoire, dans Transmodel, le STOP PLACE hérite bien de PLACE).\nLa forme générale de l'identifiant de place est [CODESPACE]:Place::[identifiantTechnique]:LOC\nMais s'il s'agit d'un arrêt on utilisera la forme spécifique des identifiant d'arrêt (voir 5.4.1.1)\nNote: Si un référentiel national est mis en place, le LOC devrait être supprimé.\n  ProducerRef [CODESPACE]  RequestMessageRef [CODESPACE]:Message::[identifiantTechnique]:[LOC]  RequestorRef [CODESPACE]  ResponseMessageIdentifier [CODESPACE]:ResponseMessage::[identifiantTechnique]:[LOC]  RouteRef [CODESPACE]:Route::[identifiantTechnique]:[LOC]  SituationSimpleRef [CODESPACE]:Situation::[identifiantTechnique]:[LOC]  StopPointRef Comme pour les arrêts  SubscriberRef [CODESPACE]  SubscriptionRef\net\nSubscriptionIdentifier  [CODESPACE]:Subscription::[identifiantTechnique]:[LOC]    Ajout d’identifiants alternatifs Un mécanisme permet optionnellement de typer les identifiants (KeyList). L’implémentation des KeyList s’appuie sur une nouvelle structure de la table extensions de SIRI (Part2) présentée ci-dessous.\nKeyList Une Keylist est un ensemble de couples clé-valeur utilisé pour décrire les identifiants secondaires de l\u0026rsquo;objet (LIGNE, LIEU D\u0026rsquo;ARRÊT, ZONE D\u0026rsquo;EMBARQUEMENT, POINT D’ARRÊT PLANIFIÉ, COURSE, etc.): c’est-à-dire tel qu\u0026rsquo;il peut être identifié dans des systèmes tiers: billettique, information voyageur, etc. La clé permet de nommer l\u0026rsquo;identifiant (et donc de faire référence au système tiers), la valeur étant l\u0026rsquo;identifiant lui même.\nCette identification servira principalement d\u0026rsquo;identification croisée, permettant au fournisseur de retrouver facilement, dans ses systèmes, l\u0026rsquo;origine de l\u0026rsquo;objet.\nLa liste des identifiants secondaires est spécifique à chaque fournisseur. Voir aussi PrivateCode du GroupOfEntities pour les identifiants alternatifs:\n   KL-1 Les KeyList ne sont à utiliser que s\u0026rsquo;il y a plusieurs identifiants alternatifs, et si elles sont utilisées, le PrivateCode doit impérativement être aussi renseigné.     KL-2 Il est interdit, dans le profil, d’utiliser le système de clé/valeur pour décrire des informations qui pourraient être fournies avec des attributs SIRI existants (même s’ils ne sont pas retenus par le profil).     Structure Extension    Extensions  +Structure Placeholder for user extensions.     ➞ KeyList 0:1 +Structure Set of KEY VALUE pairs.   ➞ … 0:* xsd:any* Any user defined content.     Structure KeyList    KeyList  +Structure Ensemble de couples Clef/Valeur arbitraires. Fournis en mecanisme d’extension. Chaque paire de clef /valeur doit être unique.    ➞ KeyValue 1:* +Structure Une paire arbitraire de clé-valeur.  ⇉ TypeOfKey 0:1 xsd:normalizedString Attribut qui spécifie le type / objectif de la paire de clé-valeur.\nType de clé.\nSeule la valeur \"ALTERNATE_IDENTIFIER\" est reconnue dans le cadre du profil. Tout autre type de type de clé devra être ignoré (sans toutefois générer d'erreur).\n  ⇉ Key 1:1 xsd:normalizedString Clé de KEY VALUE.  ⇉ Value 1:1 xsd:normalizedString Valeur de KEY VALUE.    Choix du profil SIRI France Gestion des abonnements La spécification SIRI propose une couche de communication très complète (décrite dans le document « part-2: Communications infrastructure »), mais qui, comme le reste de la spécification, est ouverte et nécessite un certain nombre de précisions dans le cadre du profil France.\nAinsi, la norme SIRI propose deux méthodes pour accéder à l\u0026rsquo;information :\n 1 - Les requêtes directes, générant immédiatement une, et une seule, réponse portant les informations demandées ; 2 - Un mécanisme d\u0026rsquo;abonnement où la même requête est soumise, mais pour laquelle on recevra régulièrement des mises à jour des informations au fur et à mesure de leur évolution. Ce mécanisme d\u0026rsquo;abonnement propose lui-même deux variantes:  a) un mécanisme de notification à deux phases (fetched delivery) : lors d\u0026rsquo;une évolution des données on reçoit une indication de « mise à jour disponible » et on peut alors aller chercher les données en question auprès du serveur, via une nouvelle requête ; b) un mécanisme de notification à une phase (direct delivery) : lors d\u0026rsquo;une évolution des données on reçoit directement les données mises à jour.       R001 Dans le cadre du profil SIRI France, tout système implémentant SIRI devra impérativement, lorsqu’implémenter, utiliser le mécanisme de requête directe.    R005 De même, tout nouveau système (en particulier les concentrateurs) devra proposer un service d’abonnement conformément à la table suivante :\n    Mécanisme\nService SIRI\n Abonnement/Notification Requête/Réponse    SM Facultatif Facultatif  ET Obligatoire Facultatif  VM Obligatoire Facultatif  SX Facultatif Facultatif  GM Facultatif Facultatif  FM Facultatif Facultatif     R010 Ce mécanisme d'abonnement sera mis en oeuvre en implémentant impérativement le mécanisme de notification à une phase (moins consommateur en bande passante réseau, et plus simple à mettre en oeuvre que le mécanisme à deux phases).  R015 De plus, dans le cadre des abonnements, SIRI propose une gestion des confirmations de réception (lorsque l'on reçoit une notification, on répond avec un acquittement pour confirmer au serveur que les données ont bien été reçues) : cette possibilité n'est pas retenue dans le cadre du profil France    En effet les protocoles de transport permettent aujourd’hui de s’assurer qu’une requête a bien été transmise, ce qui supprime tout besoin d’acquittement (il suffit donc de tester le code retour de l’appel fonctionnel SOAP).\nGestion de la segmentation des messages La spécification SIRI offre la possibilité de segmenter les messages (découper un grand message en un ensemble de messages plus petits, qu\u0026rsquo;il faudra ré-assembler).\n   R020 La segmentation des messages peut être intéressante si les échanges sont réalisés sur des réseaux de communication fortement contraints, mais ne présente pas d\u0026rsquo;intérêt dans le cadre du profil France, et n\u0026rsquo;est donc pas retenue.     Vérification de la disponibilité des partenaires Lors d\u0026rsquo;un échange, il est important de savoir si le système avec lequel on « dialogue » est disponible ou non. Cela est particulièrement important si un mécanisme d\u0026rsquo;abonnement est mis en place de façon à pouvoir faire la différence entre le fait de ne pas recevoir de mise à jour parce qu\u0026rsquo;il n\u0026rsquo;y a pas d\u0026rsquo;évolution des données, et le fait de ne pas recevoir de mises à jour parce que le système distant est « en panne » (ou qu\u0026rsquo;il y a un problème réseau -. ou toute autre défaillance).\nPour ce faire, la spécification SIRI propose deux mécanismes afin d’assurer cette surveillance :\n  Le « check Status » (requête de vérification d\u0026rsquo;état) : une requête spécifique permet de demander au système distant, quand on le souhaite, s’il est bien disponible. On déclare le système distant indisponible si l\u0026rsquo;on ne reçoit pas de réponse ou si l\u0026rsquo;on reçoit une erreur en réponse (ce mécanisme est similaire au « ping » classiquement utilisé sur les réseaux IP).\n  Le « heartbeat » (battement de cœur) qui consiste à ce que chacun des systèmes émette régulièrement (à intervalle paramétrable) un message signalant qu\u0026rsquo;il est disponible. Si l\u0026rsquo;on ne reçoit pas ce message pendant une durée supérieure au délai paramétré, c\u0026rsquo;est que la communication avec le système distant n\u0026rsquo;est plus possible.\n     R025 Dans le cadre du profil SIRI France, le mécanisme de requête de vérification d'état (service CheckStatus) est retenu. Tout serveur SIRI devra donc implémenter ce mécanisme.\nPar contre cela n’est pas une obligation pour les clients : cela pourra toutefois être envisagé dans la cadre de la gestion d’abonnement pour vérifier la disponibilité d’un abonné.\n    R030 Les implémentations devront toutefois s'engager à appeler régulièrement la requête de vérification d'état, au moins dès qu'elles n'ont plus eu d’échange avec le système distant depuis un certain temps (fixé par défaut à cinq minutes).    Structure du CheckStatus Dans le cadre du profil SIRI France :\n   R035 Le champ facultatif au niveau SIRI «Status» sera toujours présent, dans le profil France, et égal à « true » si le système est parfaitement opérationnel, et à « false » s’il est en mesure de recevoir les requêtes, mais dans l\u0026rsquo;impossibilité d\u0026rsquo;y apporter une réponse (contact avec le gestionnaire de données perdu, etc.)     R040 Le champ facultatif au niveau «ErrorCondition» reste facultatif, au niveau du profil France, si aucune erreur n’est détectée, mais devra obligatoirement être présent et instancié à chaque fois qu\u0026rsquo;une erreur sera détectée.   R045 Les champs facultatifs de «SuccessInfoGroup» restent facultatifs.   R050 Le champ facultatif au niveau SIRI «ServiceStartedTime» sera toujours présent dans le profil France, et instancié avec l\u0026rsquo;heure du dernier démarrage du système.     Utilisation des WSDL Les WSDL introduites ci-dessus, permettent de décrire complètement l\u0026rsquo;interface des services SIRI dans le contexte de Web Service de type SOAP.\n   R055 Dans le cadre du profil France, seuls les encodages RPC-Literal et Document-Literal-Wrapped sont supportés.     Gestion des filtres multiples Lors de la constitution d\u0026rsquo;une requête, les différents paramètres permettent, entre autres, de définir un filtre pour que le client ne puisse recevoir que les données qui lui sont utiles (« les 3 prochains passages à l\u0026rsquo;arrêt AAA dans la direction DDD», « le prochain passage à l\u0026rsquo;arrêt BBB », « toutes les informations temps réel pour la ligne LLL », etc.).\nLa gestion d’abonnement utilise le même mécanisme. Le cas des abonnements est un peu particulier car on peut, par exemple, souhaiter être abonné avec plusieurs paramètres de filtrage:\n « les 2 prochains passages à l\u0026rsquo;arrêt AAA dans la direction DDD»  et\n « le prochain passage à l\u0026rsquo;arrêt BBB ».  Pour limiter les échanges sur le réseau ainsi que la surcharge de traitement (overhead) pour la gestion de données, la norme SIRI propose un mécanisme de filtres multiples permettant aux clients de recevoir, dans une unique notification, les informations issues de l\u0026rsquo;ensemble des abonnements : c\u0026rsquo;est le mécanisme de filtres multiples sur un abonnement.\n   R060 En cohérence avec le choix des notifications à une phase, le profil SIRI France retient ce mécanisme de filtres multiples qui devra donc être mis en œuvre à chaque fois que les services d\u0026rsquo;abonnement seront retenus (cela permettra de recevoir plusieurs informations dans une même réponse ou notification, et donc limiter le nombre de messages).     Structuration XML La spécification SIRI propose, la possibilité de « déstructurer » l\u0026rsquo;arborescence XML pour la rendre « plate » (« flat XML »), et ce, afin de simplifier la compatibilité avec certains systèmes existants.\n   R065 Cette option de XML à plat (« flat XML ») n\u0026rsquo;est pas retenue dans le cadre du profil SIRI France.     Identification de la version de SIRI    R070 La version de SIRI utilisée dans le cadre du profil SIRI France est la version 2.1.     Réseau et sécurité Cette section du profil France est principalement dédiée à la sécurisation des échanges SIRI entre systèmes, soit les cas d\u0026rsquo;usage identifiés suivants : Diffusion inter Systèmes, Diffusion Terminaux légers, Centrale de mobilité, Gestion des perturbations, Information PMR et Alimentation d\u0026rsquo;un concentrateur.\nLa gestion de la sécurité et du contrôle d\u0026rsquo;accès n\u0026rsquo;est pas à proprement parler du ressort de SIRI, mais repose sur la couche de transport réseau retenue. Elle doit faire l\u0026rsquo;objet d\u0026rsquo;une étude par les reponsables de sécurité du réseau des systèmes échangeant des flux SIRI.\nSIRI étant un protocole inter-systèmes, la sécurité des échanges sont souvent le fruit d\u0026rsquo;un accord entre les deux parties prenantes des échanges.\n\n   R075 A minima, la mise en place de filtres sur les adresses IP (ou des plages d\u0026rsquo;adresses IP), complétés par l\u0026rsquo;utilisation d\u0026rsquo;un canal crypté HTTPS, est recommandée.     Cette solution est peu coûteuse et simple à mettre en oeuvre, car elle ne repose que sur une configuration du serveur HTTP. À noter qu\u0026rsquo;elle n\u0026rsquo;est pas suffisante seule, elle doit s\u0026rsquo;accompagner de la mise en place des autres règles de sécurité standard.\nPour les entêtes HTTP, il est fortement conseillé d\u0026rsquo;utiliser la même structure standard pour tout échange au profil France de type \u0026lsquo;X-Siri-Requestor\u0026rsquo; qui reprend la valeur du \u0026lsquo;RequestorRef\u0026rsquo; (ou celle du \u0026lsquo;ProducerRef\u0026rsquo; dans les notifications), se trouvant dans le contenu XML.\nUne telle identification, avant la lecture du XML, permet de mettre en place toutes les mesures de sécurité nécessaires en amont du serveur SIRI et la lecture des échanges.\nLe profil France recommande un paramétrage comme ci-dessous :\n\ncurl --header \u0026#39;X-Siri-RequestorRef: diffusion-ecran\u0026#39; --header \u0026#39;Content-Type: application/xml\u0026#39; -d@- https://serveur.link/exchange.point/siri \u0026lt;\u0026lt;XML \u0026lt;?xml version=\u0026#39;1.0\u0026#39; encoding=\u0026#39;utf-8\u0026#39;?\u0026gt; \u0026lt;S:Envelope xmlns:S=\u0026#34;http://schemas.xmlsoap.org/soap/envelope/\u0026#34;\u0026gt; \u0026lt;S:Body\u0026gt; \u0026lt;sw:CheckStatus xmlns:siri=\u0026#34;http://www.siri.org.uk/siri\u0026#34; xmlns:sw=\u0026#34;http://wsdl.siri.org.uk\u0026#34;\u0026gt; \u0026lt;Request\u0026gt; \u0026lt;siri:RequestTimestamp\u0026gt;2025-01-27T16:32:13.860+01:00\u0026lt;/siri:RequestTimestamp\u0026gt; \u0026lt;siri:RequestorRef\u0026gt;diffusion-ecran\u0026lt;/siri:RequestorRef\u0026gt; \u0026lt;siri:MessageIdentifier\u0026gt;Test\u0026lt;/siri:MessageIdentifier\u0026gt; \u0026lt;/Request\u0026gt; \u0026lt;RequestExtension/\u0026gt; \u0026lt;/sw:CheckStatus\u0026gt; \u0026lt;/S:Body\u0026gt; \u0026lt;/S:Envelope\u0026gt; XML En outre, il est important de rappeler que les valeurs utilisées pour les éléments tels que \u0026lsquo;RequestorRef\u0026rsquo; ou \u0026lsquo;ProducerRef\u0026rsquo;, etc. doivent être considérées comme des clés d\u0026rsquo;accès par les utilisateurs, appplications, etc. sauf en cas de valeurs publiquement diffusées comme pour l\u0026rsquo;open data alimentant le Point d\u0026rsquo;Accès National aux données de transport (PAN, transport.data.gouv). En tant que clés d\u0026rsquo;accès, elles doivent donc être créées, stockées, diffusées avec les règles de sécurité qui s\u0026rsquo;imposent pour ce genre d\u0026rsquo;objets.\nCes valeurs devraient également contenir des caractères aléatoires et il est conseillé qu'elles soient donc de la forme \"fluxprive-Pu9kaosh2thu3pohs4chaeph\" plutôt que \"fluxprive\".\n En complément de ces éléments, on retrouve tous les éléments de sécurité classique du monde du Web : firewall, architecture avec DMZ, etc. Cependant ces éléments n\u0026rsquo;ont pas d’impact sur les échanges SIRI eux-mêmes et sont du ressort de chaque intervenant (points sur lesquels ils auront une parfaite autonomie).\nSi certains souhaitent privilégier des mécanismes de sécurité plus robustes pour leurs flux privés, ils pourraient s\u0026rsquo;inspirer des recommandations faites par le profil suisse.\n\n   R080 Par contre, dans tous les cas, les services SIRI France seront accessibles à partir d\u0026rsquo;une liaison Web classique et ne nécessiteront donc pas la mise en place de liaisons spécialisées, d\u0026rsquo;abonnement à un gestionnaire de réseau spécifique, ni d\u0026rsquo;utilisation de réseaux point à point (RTC, etc.) sauf accord entre les parties.     Ces recommandations valent de façon générale pour tous les accès SIRI indépendamment des cas d\u0026rsquo;utilisation : il est souhaitable que le mode d\u0026rsquo;accès soit toujours le même, et sans lien avec l\u0026rsquo;usage qui sera fait des données.\nSi certains systèmes disposent déjà de mécanismes de gestion des accès sécurisés et ne correspondent pas à la description ci-dessus (type VPN par exemple), ils pourront être utilisés dans un premier temps de façon à ne pas pénaliser les temps de développement (puisque cela n’entraîne pas d’impact fonctionnel).\nContrôle d\u0026rsquo;accès (niveau applicatif) La norme SIRI impose que tous les messages échangés contiennent l\u0026rsquo;identifiant de celui qui l\u0026rsquo;a émis.\nCet identifiant peut être utilisé pour réaliser un contrôle d\u0026rsquo;accès pour, par exemple, ne permettre à un système distant de n\u0026rsquo;accéder qu\u0026rsquo;à certaines lignes ou certains arrêts.\n     R085 Dans le cadre du profil France, un tel contrôle sera possible, mais ne pourra porter que :\n sur des arrêts identifiés,\n des lignes identifiées,\n des exploitants identifiés (accès à toutes les informations fournies par un exploitant donné pour les cas où le système SIRI propose des informations issues de plusieurs exploitants).\n        Les éventuelles informations de restrictions devront être communiquées aux personnes en charge de la gestion et de l\u0026rsquo;exploitation du système client concerné.\n   R090 Toutefois, cet échange sera réalisé par courrier ou par mail, mais sans utiliser les structures d\u0026rsquo;autorisation (« permission structures ») proposées par SIRI et dont l\u0026rsquo;implémentation ne correspond pas à un besoin exprimé en France (pour mémoire les « permission structures » permettent à un client de demander dynamiquement « quelles sont les informations auxquelles j\u0026rsquo;ai droit » -.).     Gestion des erreurs La gestion des erreurs constitue un point important, auquel SIRI apporte une réponse claire et précise.\n    R095 Toute anomalie détectée par le serveur devra donner lieu à la génération d'un message d’erreur précisant le problème (« service SIRI non implémenté », « accès non autorisé », « service temporairement indisponible », etc.).\nDe façon à être précise, toute réponse à une requête devra indiquer si elle a pu être traitée normalement ou si une quelconque erreur a été rencontrée.\n       Le tableau ci-dessous détaille chacun des codes d\u0026rsquo;erreur proposés par SIRI :\n    Erreur SIRI Description    AccessNotAllowedError Le demandeur n'a pas les droits lui permettant d'accéder à ce service ou à ces données.  AllowedResourceUsage­ExceededError La requête est valide mais nécessite une charge trop importante pour pouvoir être traitée.  BeyondDataHorizon Les données ne sont pas disponibles pour la période demandée.  CapabilityNotSupportedError Le serveur ne supporte pas la fonctionnalité demandée.\nLe champ « CapabilityNotSupportedError » signalera une erreur si un service optionnel non implémenté est sollicité.\n  InvalidDataReferencesError La requête contient des identifiants qui sont inconnus.  NoInfoForTopicError La requête est valide, mais aucune donnée correspondante n'est disponible sur le serveur.  OtherError Erreur autre que celles qui sont prédéfinies.  ParametersIgnoredError La requête contient des paramètres qui ne sont pas supportés par le serveur : une réponse a été fournie, mais les paramètres non supportés n'ont pas été pris en compte.  ServiceNotAvailableError Le service est indisponible (mais toutefois capable de fournir cette réponse …).     UnknownExtensionsError La requête contient des extensions qui ne sont pas supportées par le serveur : une réponse a bien été fournie mais sans tenir compte de ces extensions.  UnknownParticipantError Le destinataire du message (requête) est inconnu.\nNote: cette erreur fait echo à la capacité de relais de requête introduite par SIRI 2.\n    Dans le cadre du profil SIRI France :\n    R100 Pour les services fonctionnels, le champ facultatif « Status » (dans le DeliveryStatusGroup défini par la structure AbstractServiceDeliveryStructure utilisée pour les réponses de chacun des services) sera :\n toujours présent et égal à « true » (valeur par défaut) si la requête a été traitée normalement,\n et à « false » sinon (dans le cas des abonnements, un éventuel problème détecté, comme une indisponibilité temporaire, donnera lieu à l'émission d'une notification sans données, mais signalant le problème).\n        Ce champ signale qu\u0026rsquo;un problème a été rencontré, et non qu\u0026rsquo;il n\u0026rsquo;y a pas de réponse : il peut donc être positionné à « false » alors qu\u0026rsquo;une information est bien retournée.\nPlus particulièrement dans le cas de la réponse à un GetSiri, on obtient un « Status » au niveau de l\u0026rsquo;entête global de la réponse (dans le ServiceDeliveryRequestStatusGroup) et un autre pour chacune des réponses aux requêtes élémentaires (typiquement quand on a utilisé GetSiri pour effectuer une interrogation sur toute une liste d\u0026rsquo;arrêts. Dans ce cas aussi, un « Status » à « false » dans l\u0026rsquo;entête signifie qu\u0026rsquo;il y a une des réponses portant une erreur, et non qu\u0026rsquo;il n\u0026rsquo;y a pas de réponse.\n   R105 Le champ facultatif « ErrorCondition » reste facultatif, mais devra être présent et instancié à chaque fois qu\u0026rsquo;une erreur sera détectée.     R110 La liste des codes erreur à supporter dans le cadre du profil France est détaillée dans le tableau ci-dessous.   R115 S\u0026rsquo;il ne s\u0026rsquo;agit pas d\u0026rsquo;un service optionnel non implémenté, le champ « OtherError » précisera sous forme textuelle la nature de l\u0026rsquo;erreur rencontrée.        R120 Le champ facultatif « Description » reste facultatif et permettra juste de préciser l\u0026rsquo;erreur (les éléments fondamentaux étant précisés dans l\u0026rsquo;un des deux champs précédents). Il devra contenir une description de l’erreur ainsi que le champ incriminé, par exemple : \u0026ldquo;Erreur [nom du champ] : [Raison de l’erreur avec valorisation reçue]\u0026rdquo;.     R130 De façon à systématiser les messages d\u0026rsquo;erreur, le champ « OtherError » sera structuré en débutant par un code prédéfini entre crochets, suivi d\u0026rsquo;un texte explicatif.     La liste des codes prédéfinis est la suivante :\n  [BAD_REQUEST] : impossible de décoder la requête.\n  [BAD_PARAMETER] : la requête contient un paramètre inutilisable (le texte devra alors préciser le paramètre posant problème).\n  [INTERNAL_ERROR] : erreur non identifiée, mais empêchant la fourniture d\u0026rsquo;un résultat.\n     R135 De façon à assurer une homogénéité de comportement dans le traitement des erreurs, il est convenu des comportements suivants :        Erreur Comportement     [BAD_REQUEST] Rejet complet de la requête, réponse erreur uniquement.   InvalidDataReferencesError Rejet de la requête ; en cas de multiples requêtes, rejet de la seule requête en erreur.   [BAD_PARAMETER] Rejet complet de la requête, réponse erreur uniquement.   ParametersIgnoredError Réponse en ignorant le paramètre incriminé.   NoInfoForTopicError Réponse uniquement sur la base des informations effectivement disponibles (pas de réponse autre que l\u0026rsquo;erreur si aucune donnée n\u0026rsquo;est disponible).   ServiceNotAvailableError Rejet complet de la requête, réponse erreur uniquement.   AccessNotAllowedError Rejet complet de la requête, réponse erreur uniquement.   [INTERNAL_ERROR] Réponse erreur uniquement.   AllowedResourceUsageExceededError Réponse erreur uniquement.   BeyondDataHorizon Réponse erreur uniquement.   UnknownExtensionsError Réponse uniquement sur la base des paramètres effectivement reconnus.    Il n\u0026rsquo;y a pas d\u0026rsquo;obligation pour un système d\u0026rsquo;être en mesure de remonter chacune de ces erreurs.\n   R140 Toutefois, en cas d\u0026rsquo;anomalie, les systèmes devront s\u0026rsquo;astreindre à utiliser le code correspondant au problème rencontré pour le signaler (et ce en rapport avec leurs capacités et limitations de détection d\u0026rsquo;anomalie, ce qui signifie qu\u0026rsquo;ils ne sont pas tenus de remonter une erreur qu\u0026rsquo;ils ne savent pas identifier).     R145 Les erreurs rencontrées devront de plus être conservées dans des fichiers (fichier type « log ») tant au niveau des systèmes serveurs que des systèmes clients, de façon à permettre une analyse « post-mortem » et d’envisager d\u0026rsquo;éventuels correctifs ultérieurs.   R150 La durée minimale de conservation des fichiers « log » sera définie dans le cadre des projets ; on peut toutefois considérer que 3 mois est une valeur acceptable et 1 an une valeur maximale.     La remontée d\u0026rsquo;erreur n\u0026rsquo;a en effet d\u0026rsquo;intérêt que si on l’utilise pour comprendre et corriger les causes des anomalies. Cela implique que ces erreurs soient reçues et traitées par les équipes d’exploitation puis dispatchées, après une première analyse, vers les partenaires, les industriels ou tout intervenant susceptible d’y apporter un remède.\n   R155 Dans le cas où une requête ne reçoit pas de réponse, une erreur pourra être déclarée. Cette anomalie sera mentionnée dans le « log » d\u0026rsquo;erreur du client. Le délai d\u0026rsquo;attente (« timeout » avant identification d\u0026rsquo;une panne) est fixé par défaut à une minute (cette valeur « par défaut » pourra être ajustée localement, notamment au regard du délai « normal » de rafraîchissement des données).     R160 ATTENTION : il est tout à fait possible que la réponse arrive finalement, mais après le délai imparti, le système client pourra alors décider de la prendre en compte ou de l\u0026rsquo;ignorer (à définir localement dans l\u0026rsquo;implémentation du système).     Identification des services disponibles La norme SIRI offre la possibilité de demander à un système la liste des services qu\u0026rsquo;il implémente (ceux qu’ils doivent normalement implémenter, indépendamment des éventuelles pannes), ce qui peut s\u0026rsquo;avérer utile du fait du caractère facultif d\u0026rsquo;implémentation de certains services (se référer à la partie 1 pour la liste des services à caractère obligatoire ou facultatif).\nIl peut être utile pour des systèmes concentrateurs de pouvoir demander à un système distant les services qu\u0026rsquo;il implémente et ainsi se configurer automatiquement pour la gestion de l\u0026rsquo;échange.\nToutefois, cela peut aussi être réalisé au travers d\u0026rsquo;un simple mécanisme de configuration du serveur, qui sera de toute façon indispensable pour identifier la liste des serveurs SIRI à contacter (il suffit alors, pour chaque serveur, de préciser la liste des services disponibles).\n   R165 De façon à ne pas alourdir le développement des systèmes la possibilité de « Capability Checking » proposée par SIRI n\u0026rsquo;est pas retenue, au profit d\u0026rsquo;un système non dynamique basé sur des fichiers de configuration (l\u0026rsquo;aspect dynamique et automatique ne présente pas d\u0026rsquo;intérêt particulier dans le cadre France).     Compression     R170 De façon à limiter la taille des messages, une compression de type Gzip (proposée par SIRI) sera utilisée.\nDans le contexte de l'utilisation de SOAP sur le protocole HTTP, elle sera mise en œuvre par les serveurs HTTP généralement par simple configuration.\n       Encodage des caractères    R175 Les différentes chaines de caractères présentent dans les données XML seront encodées exclusivement en UTF-8 (abréviation de l’anglais Universal Character Set Transformation Format - 8 bits sans Bit-Order-Mark (BOM)).     Techniquement cela se traduira, si l\u0026rsquo;on souhaite être explicite, par un \u0026lt;?xml version=\u0026quot;1.0\u0026quot; encoding=\u0026quot;UTF-8\u0026quot;?\u0026gt; en entête du document. Mais cela n\u0026rsquo;est pas indispensable car l\u0026rsquo;UTF-8 est la valeur par défaut quand l\u0026rsquo;encodage n\u0026rsquo;est pas précisé.\nVoir https://fr.wikipedia.org/wiki/UTF-8 pour plus de détail sur UTF-8.\nModalité d\u0026rsquo;utilisation des versions Les principales règles d\u0026rsquo;utilisation des versions sont les suivantes. Soit deux versions de profil N et N+ (N+ étant une version postérieure à N).\n  Un client N peut s\u0026rsquo;adresser à un serveur N+. Le serveur N+ peut alors :\n  (solution non recommandée) Indiquer qu\u0026rsquo;il ne supporte pas cette version en utilisant le code d\u0026rsquo;erreur CapabilityNotSupportedError en précisant dans le champ CapabilityRef le numéro de version qui a été demandé (donc N ici),\n  adapter sa réponse pour la rendre conforme à la version N,\n  Transférer la requête à un serveur en version N (le \u0026ldquo;transfert\u0026rdquo; peut, techniquement, être réalisé de différentes façons, comme l'URL Forwarding, mais ceci relève du choix d\u0026rsquo;implémentation technique),\n  Un client N+ ne peut pas s\u0026rsquo;adresser à un serveur 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\u0026rsquo;erreur, il est recommandé de répondre qu\u0026rsquo;il ne supporte pas cette version en utilisant le code d\u0026rsquo;erreur CapabilityNotSupportedError en précisant dans le champ CapabilityRef le numéro de version qui a été demandé (donc N+ ici),\n  Un client N+ peut s\u0026rsquo;adresser à un serveur N en demandant la version N. La réponse lui est alors retournée en version N.\n  Note: Cette gestion de version n\u0026rsquo;est en rien incompatible avec l\u0026rsquo;insertion d\u0026rsquo;un numéro de version dans l\u0026rsquo;URL d\u0026rsquo;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\u0026rsquo;échange.\nCas des passages échus, à venir L\u0026rsquo;utilisation des « OnwardCall » et « PreviousCall », « recordedCall » mérite d\u0026rsquo;être précisée car elle est légèrement différente suivant qu\u0026rsquo;on les utilise dans le service StopMonitoring ou le service VehicleMonitoring.\n   R180 Le « PreviousCall » n\u0026rsquo;a pas été retenu par le profil France et ne doit donc pas être utilisé.     R185 Le « MonitoredCall» correspond à l\u0026rsquo;arrêt pour lequel on a fait l\u0026rsquo;interrogation (et n\u0026rsquo;est donc en aucun cas lié à la position du véhicule). Les « OnwardCall » correspondent alors à tous les arrêts suivant ce « MonitoredCall» dans le cadre des courses concernées.     Dans le cas du service VehicleMonitoring le « MonitoredCall» correspond au dernier arrêt marqué ou à l\u0026rsquo;arrêt où se trouve le véhicule s\u0026rsquo;il est à l\u0026rsquo;arrêt. Les « OnwardCall » correspondent alors à tous les arrêts suivants pour ce véhicule dans le cadre de sa course.\nService SIRI Discovery SIRI propose des services qui permettent d’effectuer l’échange de données référentielles (Discovery Services). Dans le cadre du profil France de SIRI, il est tout à fait possible de les utiliser pour :\n La conduite de tests sur les flux SIRI en open data, La maintien de la capacité de SIRI d\u0026rsquo;être auto-porteur dans les échanges de données pour l\u0026rsquo;information voyageur, sans avoir recours à d\u0026rsquo;autres interfaces d\u0026rsquo;échange.  Note : Que ce soit dans les échanges pour l\u0026rsquo;open data ou entre systèmes, ces services n\u0026rsquo;ont pas pour vocation de remplacer l\u0026rsquo;utilisation des flux NeTEx qui sont beaucoup plus complets pour la description de l\u0026rsquo;offre planifiée de transport public (topologie du réseau, des arrêts, des lignes, de l\u0026rsquo;accessibilité, des équipements, etc.). Les\nLe tableau ci-dessous présente les services disponibles et ceux qui sont retenus pour le profil France de SIRI :\n    Requête d'identification du référentiel Commentaire    StopPointsRequest Requête retenue pour le profil France. L'utilisation de ce service devra donc reposer sur des informations cohérentes d’identifiant des arrêts.\nCette requête permet d'obtenir la liste de tous les points d'arrêts connus du système (voir la structure retournée, ci-dessous).\n  LinesRequest Requête retenue pour le profil France.\nCette requête permet d'obtenir la liste de toutes les lignes connues du système (voir la structure retournée, ci-dessous).\n  InfoChannelRequest Requête retenue pour le profil France.\nCette requête permet d'obtenir la liste de tous les canaux de messagerie proposés (voir la structure retournée, ci-dessous).\nDans le cadre du profil France, seules les valeurs suivantes seront utilisées pour identifier les canaux:\n1. « Perturbation »,\n2. « Information »,\n3. « Commercial ».\nNB : même il ne s'agit pas ici d'une donnée du référentiel cette information est traitée ici, car elle fait partie du « Discovery Service » proposé par SIRI.\n  FacilityRequest Requête retenue pour le profil France.\nCette requête permet d'obtenir la liste de tous les équipements et services connus du système (voir la structure retournée, ci-dessous).\n    Les services retenus sont donc : StopPointsRequest, LinesRequest, InfoChannelRequest et FacilityRequest. Les identifiants ainsi obtenus pourront être utilisés avec tous les Services SIRI disponibles sur le système les ayant fournis. On utilisera, par exemple, un même identifiant d’arrêt pour consulter les horaires à l’arrêt (avec le service « Stop Monitoring »), ou les informations de perturbation (service « Situation Exchange » et/ou « General Message »).\nLes informations qu\u0026rsquo;ils procurent sont présentées ci-dessous :\nNote : les services de découvertes SIRI permettent de connaître les noms des arrêts et lignes et l\u0026rsquo;appartenance des arrêts aux lignes mais en aucun cas la structure (itinéraire-Route, mission-Journey pattern et à fortiori course-vehicle Journey). Il conviendra donc de se tourner vers les données de référence de l\u0026rsquo;offre et un référentiel d\u0026rsquo;arrêt pour obtenir une information proprement structurée.\nDiscovery StopPoint Requête StopPointsRequest Note: Voir 3.2 pour les explications détaillées de lecture des tableaux qui suivent (codes couleurs, etc.).\n   StopPointsDiscoveryRequest +Structure Requête d\u0026rsquo;accès à la liste des arrêts                Log Request­Timestamp 1:1 xsd:dateTime Date d’émission de la requête.   Endpoint Properties Address 0:1 Endpoint­Address Adresse réseau de destination de la réponse (ici une URL étant donné le choix d’implémentation SOAP).    RequestorRef 1:1 Participant­Code Identifiant du demandeur (reprendre la structure [fournisseur] des identifiants).    Message­Identifier 0:1 Message­Qualifier Identifiant unique de ce message.   Topic BoundingBox 0:1  Filtre permettant de n\u0026rsquo;obtenir que les arrêts situés à l\u0026rsquo;intérieur d\u0026rsquo;un rectangle englobant.    ➞ UpperLeft 0:1 LocationStructure Coin supérieur gauche du rectangle englobant.    ➞ LowerRight 0:1 LocationStructure Coin inférieur droit du rectangle englobant.    OperatorRef 0:1 Operator­Code Filtre permettant de n\u0026rsquo;obtenir que les arrêts utilisés par un opérateur donné.    LineRef 0:1 LineCode Filtre permettant de n\u0026rsquo;obtenir que les arrêts utilisés par une ligne donnée.    Réponses aux StopPointsRequest La structure ci-dessous présente la description d\u0026rsquo;un arrêt tel que retourné par le service (mais sans les entêtes génériques de réponse SIRI).\n   AnnotatedStopPointStructure +Structure Description simplifiée d\u0026rsquo;un arrêt.        Stop Identity Stop­Point­Ref 1:1 StopPoint­Code Identifiant du Point d'arrêt. Cf 5.4.\nIl convient d'utiliser ici un identifiant d'objet de référence.\n   StopName 1:1 NaturalLanguageStringStructure le champ«StopName» sera toujours présent et renseigné conformément au paragraphe 5.4.   Lines 0:*  Liste des lignes passant à l'arrêt.   ➞ LineRef 0:1 LineCode Identifiant d'une ligne (issu du référentiel des lignes).   Location 0:1 LocationStructure Localisation géographique de l'arrêt.    Discovery Line Requête LinesDiscoveryRequest    LinesDiscoveryRequest +Structure Requête d\u0026rsquo;accès à la liste des lignes                Log Request­Timestamp 1:1 xsd:dateTime Date d’émission de la requête.   Endpoint Properties Address 0:1 Endpoint­Address Adresse réseau de destination de la réponse (ici une URL étant donné le choix d’implémentation SOAP).    Requestor­Ref 1:1 Participant­Code Identifiant du demandeur (reprendre la structure [fournisseur] des identifiants).    Message­Identifier 0:1 Message­Qualifier Identifiant unique de ce message.    OperatorRef 0:1 Operator­Code Filtre permettant de n\u0026rsquo;obtenir que les lignes exploitées par un opérateur donné.    Réponses aux LinesRequest    AnnotatedLineStructure +Structure Description simplifiée d\u0026rsquo;une ligne.                Line Identity LineRef 1:1 LineCode Identifiant de la ligne (issu du référentientiel des lignes).    LineName 1:1 NaturalLanguageStringStructure Nom de la ligne (issu du référentientiel des lignes)..    Monitored 0:1 xsd:boolean Le champ obligatoire « Monitored » sera toujours égal à « true » indiquant ainsi que l’on dispose bien d’information temps réel à ce point (inutile de traiter les arrêts et lignes pour lesquels on n’a pas d\u0026rsquo;information temps réel)    Destinations 0:* AnnotatedDestinationStructure Le champ facultatif « Destinations » reste facultatif et permettra d’indiquer, en plus des extrémités de la ligne, si elle est composée de plus de deux itinéraires (aller et retour).    Discovery InfoChannel \u0026amp; Facility Requêtes Les requêtes ont toutes la même forme (l\u0026rsquo;exemple de la StopPointsRequest est fourni ci-dessous).\nDans le cadre du profil France :\n  Le champ facultatif «address» ne sera jamais présent,\n  Le champ facultatif «MessageIdentifier» sera toujours présent et instancié (utilisé en particulier pour la gestion des cas d\u0026rsquo;erreur).\n  Note: l\u0026rsquo;attribut « version » référence la version de SIRI utilisée (afin de permettre une gestion « sereine » des futures versions, voir 5.9).\nLa mise à jour des données de référence devra être réalisée périodiquement de façon à garantir la synchronisation des référentiels des différents systèmes. On pourra envisager différents modes de synchronisation :\n  Des synchronisations à heures fixes (quotidiennement la nuit ou en milieu de journée pour les réseaux nocturnes),\n  Des synchronisations à dates fixes (hebdomadaires, mensuelles, etc.),\n  Des synchronisations manuelles.\n  Il est difficile d’envisager ici tous les cas et modes de synchronisation, car l’objectif traité dans ces paragraphes n’est pas de préconiser « comment faire » mais de s’adapter aux systèmes existants.\nIl faudra donc envisager des adaptations au cas par cas, à formaliser dans le cadre de la contractualisation entre les intervenants. Il est important de rappeler que ces accords particuliers devront traiter de façon explicite et détaillée les différents cas d’erreur qui pourront intervenir :\n  Impossibilité de consulter les référentiels à la date et/ou l’heure prévue,\n  Identification d’une incohérence de référentiel en exploitation, alors que le système est utilisé,\n  Modification tardive du référentiel par l’exploitant,\n  Etc.\n  Un tel mécanisme peut sembler attrayant, et il peut être tentant de le pérenniser. Il faut toutefois bien garder à l\u0026rsquo;esprit que s\u0026rsquo;il est pertinent pour deux systèmes en communication, il est beaucoup plus délicat à mettre en place pour un grand nombre de systèmes du fait de la problématique de mise à jour et de synchronisation qu\u0026rsquo;il implique: on a en effet un nombre d\u0026rsquo;échanges à prévoir égal à N*(N-1) où N est le nombre de systèmes (donc 20 synchronisations quotidiennes pour cinq systèmes).\nEt, même si l’on a qu’un fournisseur et N clients, il est clair que la mise en place d’un référentiel spécifique à l’information temps réel ne permettra pas la mise en place de systèmes d’information complets permettant à l’utilisateur de passer sans difficulté de l’information théorique à l’information temps réel.\nRéponses aux InfoChannelRequest Tous les champs étant obligatoires, il n\u0026rsquo;y a pas d\u0026rsquo;adaptation au cadre du profil France (on définit tout de même les codes possibles : « Perturbation », « Information » ou « Commercial »).\nOn peut toutefois noter que le champ « icon » pourra souvent rester vide.\nNote: voir la description du service de messagerie pour plus de précisions.\nRéponses aux FacilityRequest Dans le cadre du profil France :\n  Le champ facultatif « Monitored » sera toujours présent et égal à « true » (inutile de traiter les équipements pour lesquels on n’a pas d\u0026rsquo;information temps réel ou au moins mis à jour quotidiennement).\n  Le champ facultatif «Facility» sera toujours présent :\n  Le champ facultatif «FacilityRef» ne sera jamais présent (déjà disponible au niveau supérieur),\n  Le champ facultatif «Description» reste facultatif,\n  Le champ facultatif «FacilityClass» reste facultatif,\n  Le champ facultatif «Feature» sera toujours présent et instancié,\n  Le champ facultatif «FacilityLocation» sera toujours présent et instancié,\n  Le champ «AccessibilityAssessment» reste facultatif,\n    Le champ facultatif «Extension» ne sera jamais présent.\n  Les valeurs possibles pour ces différents champs seront celles proposées par SIRI, mais pourront être réduites aux valeurs jugées pertinentes dans le contexte France. Se reporter au profil France NeTEx pour l’interprétation des différents champs contenus dans «AccessibilityAssessment», notamment dans la partie Accessibilité du profil. \nGestion des versions du profil SIRI FR L’évolution des normes et du profil SIRI France dans le temps nécéssite de définir les règles permettant d’identifier la version d’un profil France SIRI.\nUne compatibilité ascendante devra être assurée entre les versions du profil. Il n\u0026rsquo;y a par contre aucune garantie de compatibilité \u0026ldquo;descendante\u0026rdquo; : on peut assurer qu\u0026rsquo;un client de version antérieure puisse toujours s\u0026rsquo;adresser à un serveur de version postérieure, mais l\u0026rsquo;inverse ne peut être réalisé.\nLe profil SIRI France intègre un mécanisme de gestion de version qui a plusieurs objectifs:\n  Permettre à un serveur de savoir suivant quel profil il doit répondre à une requête client (en supportant plusieurs versions ou en redirigeant les requêtes et donc sans contraindre tousles clients à changer de version en même temps que lui) ;\n  Permettre à un serveur de signaler à un client qu\u0026rsquo;il ne supporte pas la version demandée (plutôt que de lui répondre avec une erreur) ;\n  Permettre à un client de gérer les réponses d\u0026rsquo;un serveur d\u0026rsquo;une version antérieure.\n  Le principe de gestion de version est simple : il s\u0026rsquo;appuie sur les identifiants de version proposés par SIRI dans les en-têtes de toutes les requêtes de service (ce champ est disponible pour chacune des xxxxRequestStructure sous la forme d\u0026rsquo;un attribut nommé Version) ainsi que de chacune des réponses correspondantes (ce champs est disponible pour chacune des xxxxDeliveryStructure, là aussi sous la forme d\u0026rsquo;un attribut nommé Version).\nNote : il s\u0026rsquo;agit bien ici de l\u0026rsquo;attribut Version au niveau des services et non de l\u0026rsquo;attribut que l\u0026rsquo;on trouve sur la racine Siri du schéma, cette dernière n\u0026rsquo;étant pas accessible dans le cadre des échanges SOAP.\nLa codification de version proposée par SIRI est de la forme x.y :\n  x constitue le numéro de version majeure, soit en l\u0026rsquo;occurrence la version de la norme (spécification technique (TS) précédemment),\n  y constitue le numéro de version mineure: il est potentiellement suivi d\u0026rsquo;une lettre (facultative) qui précise éventuellement la version de l\u0026rsquo;XSD utilisée, on aura par exemple une version 2.1n pour indiquer la version 2.1 de SIRI et la version n de l\u0026rsquo;XSD correspondant.\n  Par exemple pour SIRI 1, les versions 1.0, 1.2, 1.3 et 1.4, et pour SIRI 2, la version 2.1 est actuellement disponible.\nLa codification de la version de profil se fait de la façon suivante : x.y:FR-a.b-c-d (par exemple \u0026ldquo;2.1:FR-1.0\u0026quot;).\n  x.y étant la version de SIRI (obligatoire): le x est un entier et les y est un entier potentiellement suivi d\u0026rsquo;une lettre.\n  : est un délimiteur obligatoire.\n  FR le digramme de la France (ISO 3166-1 alpha-2) (obligatoire).\n  - est un délimiteur obligatoire\n  a.b est la version du profil (obligatoire). a et b sont des chiffres entiers.\n  - est un délimiteur facultatif (doit être omis si ni c ni d ne sont présents, obligatoire sinon).\n  c est le numéro de version du service concerné (facultatif). Il est constitué d\u0026rsquo;un ou deux caractères numériques. Il permettra d\u0026rsquo;identifier des possibles ajustements futurs spécifiques à ce service.\n  - est un délimiteur facultatif (doit être omis si d n\u0026rsquo;est pas présent, mais est impératif si d est présent).\n  d est le numéro de version le l\u0026rsquo;implémentation locale (numéro de version logicielle du serveur SNCF, Transdev, RATP, Keolis, du relais, etc.). d est constitué de chiffres et de \u0026ldquo;.\u0026rdquo; uniquement.\n  Les exemples ci-dessous sont valides au titre de cette codification :\n  2.1:FR-1.0,\n  2.0:FR-1.0-1.\n  Partie III. Description détaillée des messages Les paragraphes ci-dessous présentent les services retenus dans le cadre du profil SIRI France d’un point de vue « description technique des messages ».\nLe principe de ces services a déjà été présenté en amont dans ce document, ce qui est présenté ici correspond aux tableaux détaillés des services que l\u0026rsquo;on trouve dans le document « SIRI-Partie 3 », traduit en français (seules les descriptions sont traduites, les noms des éléments et leurs types restent en anglais, car c\u0026rsquo;est ainsi qu\u0026rsquo;on les retrouvera dans l\u0026rsquo;échange XML) et précisant l\u0026rsquo;utilisation des différents champs, le maintien ou non de leur caractère facultatif, etc.\n  Les éléments retenus pour le profil sont surlignés en Gris.\n  Les éléments non retenus pour le profil sont en texte masqué surligné bleu\n  Les éléments ne comportant aucune marque font partie du profil conformément aux spécifications de la norme SIRI.\n  L’ensemble des services présentés s’appuie sur la norme SIRI en version 2.1.\nDes mises à jour de version de SIRI pourront être envisagées, au fur et à mesure des évolutions et corrections de SIRI. Toutefois, la prise en compte d’une nouvelle version de SIRI ne pourra être réalisée que si elle a été validée par une mise à jour du présent document.\nEstimated Timetable La norme SIRI ne pose aucune hypothèse ni aucune limite sur la durée exacte des journées d’exploitation (possibilité de passer minuit), les informations pourront donc être remontées indépendamment de la durée de la journée d’exploitation.\nNote : Les mécanismes de datation SIRI sont normalisés ISO. Un changement de jour se traduit par un incrément du jour et l’initialisation des heures, minutes et secondes.\nPar contre si un système s’attend à recevoir des données après minuit et que le fournisseur n’est pas en mesure de les produire, cela peut poser problème : ce point sera donc à qualifier, si nécessaire, dans le cadre des protocoles d’accord entre AOT et OTP.\nRequête d’informations horaires calculées sur la ligne    EstimatedTimetable­Request +Structure Requête d’informations horaires calculées sur la ligne        Attributes Version 1:1 VersionString Version du service “ Estimated Timetable”, intégrant le numéro de version de profil (voir 5.9) par exemple - ‘2.1:FR-1.0’     Endpoint Properties Request­Timestamp 1:1 xsd:dateTime Date d\u0026rsquo;émission de la requête.    Message­Identifier 1:1 MessageQualifier Numéro d\u0026rsquo;identification du message   Topic Preview­Interval 0:1 Positive­DurationType Si ce paramètre est présent, il indique que l\u0026rsquo;on souhaite recevoir des informations sur toute course proposant au moins une arrivée ou un départ intervenant dans la durée indiquée (à partir de l’heure de réception de la requête). S’il n’est pas présent, toutes les informations disponibles sur la journée d\u0026rsquo;exploitation sont remontées.    Timetable­VersionRef 0:1 xsd:string Version du référenciel théorique connue : seuls les écarts par rapport à ce référentiel seront transmis.    Operator­Ref 0:1 ➞ Operator­Code Identifie l’exploitant pour lequel on souhaite obtenir des informations.    Lines 0:* +structure Liste des lignes contenant les courses pour lesquelles on souhaite des informations.    ➞ LineDirection 0:1 ➞ LineDirection­Code Identifie la ligne pour laquelle on souhaite obtenir des informations.          Any Extensions 0:1 +Structure Emplacement pour extension utilisateur (cf 5.4.2.2)     Abonnement aux horaires calculés sur la ligne Les notifications sont gérées de façons très légèrement différentes en EstimatedTimetable et StopMonitoring (du fait des différences structurelles des services).\nLe tableau ci-dessous précise les conditions de notification pour EstimatedTimetable.\n   Notification Commentaire     Changement (incluant une première inscription dans le champ) d\u0026rsquo;une des heures de passage d\u0026rsquo;une valeur supérieure ou égale à ChangeBeforeUpdate par rapport à la précédente notification. Notification différentielle (uniquement des Call concernés par ces changements) similaire à celle de StopMonitoring.   Lorsque le véhicule quitte l\u0026rsquo;arrêt (sauf pour le dernier arrêt) Notification en positionnant le champ DepartureStatus à \u0026ldquo;departed\u0026rdquo;.   A minima pour le dernier arrêt (et si possible pour tous les arrêts), lorsque le véhicule arrive à l\u0026rsquo;arrêt Notification en positionnant le champ VehicleAtStop à ’True’   En cas de changement de quai Notification en positionnant les informations relatives au quai.       EstimatedTimetable­SubscriptionRequest +Structure Requête d’abonnement aux horaires calculés sur la ligne         Identity Subscriber­Ref 1:1 → Participant­Code Identification du système demandeur (voir SIRI Partie 2 Common SubscriptionRequest parameters.)     Subscription­Identifier 1:1 Subscription­Qualifier Identifiant de l'abonnement pour le système demandeur.  Lease Initial­Termination­Time 1:1 xsd:dateTIme Date et heure de fin de l'abonnement : un abonnement a forcément une date et une heure de fin (les partenaires pourront décider de limiter la durée maximale d’un abonnement).  Request Estimated­Timetable­Request 1:1 +Structure Voir EstimatedTimetable­Request.  Policy Change­Before­Update 1:1 Positive­Duration­Type Permet d'indiquer un écart de temps en dessous duquel on ne souhaite pas être notifié (si l'on demande un seuil de 5mn et qu'un horaire de départ change de 2 minutes, on ne sera pas notifié, évitant ainsi des flux d'information inutiles).\nSi ce champ n'est pas présent, une valeur de 5 minutes est prise par défaut. C’est une valeur « par défaut », qui est volontairement haute pour ne pas surcharger les échanges : dans le cas nominal elle devra être précisée avec une valeur plus faible (mais tous les systèmes ne fonctionnent pas à la minute, surtout côté client).\nDans le cadre des échanges avec un concentrateur la valeur par défaut est de 1 minute.\nDe plus il est important de noter que l'abonnement à Estimated Timetable fonctionne exclusivement en mode incrémental : ce service est en effet conçu pour les échanges en volume, et ne pas utiliser le mode incrémental serait complètement contreproductif par rapport à l'objectif de limiter les volumes d'échange.\n     Réponse aux requêtes d’horaires calculés sur la ligne    EstimatedTimetableDelivery +Structure Décrit une Dated Timetable (horaire pour un jour d’application donné).        Attributes version 1:1 Version­String Numéro de version du service Estimated Timetable, intégrant le numéro de version de profil (voir 5.9) (valeur fixe).     LEADER :: 1:1 xxx­Delivery Voir xxxDelivery.   Payload EstimatedJourneyVersionFrame 0:* +Structure Voir EstimatedJourneyVersionFrame element.   any Extensions 0:1 +Structure Emplacement pour extension utilisateur (cf 5.4.2.2)     Structure EstimatedJourneyVersionFrame    EstimatedJourneyVersionFrame +Structure Fournit les horaires attendus pour un itinéraire (ligne+direction) donné.         Log Recorded­AtTime 1:1 xsd:dateTime Date et heure à laquelles ces données ont été produites.    Identity VersionRef 0:1 → VersionCode Contexte d'identification de la course (SAE pour le jour d'exploitation, version du référentiel de données, etc.).\nCe champ permet de qualifier la version des données de référence ie version du référentiel théorique (voir 2.5).\n  Journeys EstimatedVehicleJourney 1:* +Structure Description des courses sur l’itinéraire.\nVoir EstimatedVehicleJourney element.\n  any Extensions 0:1 any Emplacement pour extension utilisateur (cf 5.4.2.2)     Structure EstimatedVehicleJourney    EstimatedVehicleJourney +Structure Description d’une course.         Vehicle Journey Identity LineRef 1:1 → LineCode Identifiant de la ligne.     DirectionRef 1:1 → Direction­Code Identifie la direction (typiquement Aller/Retour).\nLa sélection de ce champ n’est pas dans la logique du reste du profil (plutôt porté sur Destination, voir plus bas) mais est maintenu du fait de la cardinalité imposée par SIRI (le champ est obligatoire dans la description XSD de SIRI et doit donc être maintenu et ne peut être vide.)\n   choix –1:1  Seul le choix a, b ou c est possible …   a) Dated­Vehicle­Journey­Ref 0:1 → DatedVehicle­Journey­Code Identifie la course.\nCette information est obligatoire dans le cadre des échanges avec un concentrateur.\n   b) Estimated­Vehicle­Journey­Code 0:1 Estimated­Vehicle­Journey­Code Permet d’identifier une nouvelle course (course ajoutée par rapport aux horaires théoriques).\nSi ce champ est présent,. ExtraJourney doit être positionné à ‘true’ (et réciproquement…).\nCette information est obligatoire (si une course a été ajoutée) dans le cadre des échanges avec un concentrateur. Dans le cas ou l'adjonction de course ne peut être détectée, la structure Dated­Vehicle­Journey­Ref sera remplie comme pour les autres courses.\n   c) Dated­Vehicle­Journey­Indirect­Ref 0:1 +Structure Si les systèmes en communication n’ont pas de référentiel commun pour identifier les courses, la structure ci-dessous permet de la décrire succinctement.   ➞ Origin­Ref 1:1 → StopPoint­Code Identifiant du premier point d’arrêt de la course.   ➞ Aimed­Departure­Time 1:1 xsd:dateTime Heure de depart (théorique) au premier point d’arrêt.   ➞ Destination­Ref 1:1 → StopPoint­Code Identifiant du dernier point d’arrêt de la course.   ➞ Aimed­Arrival­Time 1:1 xsd:dateTime Heure d’arrivée (théorique) au dernier point d’arrêt.  Change ExtraJourney 0:1 xsd:boolean Signale qu’il s’agit d’une nouvelle course, ajoutée par rapport aux horaires théoriques.\nValeur par défaut : « false »\n   Cancellation 0:1 xsd:boolean Signale la suppression de la course identifiée.\nValeur par défaut : « false »\n  Journey­Pattern Info :: 0:1 Journey­Pattern­Info­Group Voir Journey­Pattern­Info­Group.  JourneyEndNames ::: 0:1 JourneyEndNamesGroup Voir JourneyEndNamesGroup  VehicleJourneyInfo ::: 0:1 VehicleJourneyInfoGroup Voir VehicleJourneyInfoGroup  Service Info ::: 0:1 Service­Info­Group Voir Service­Info­Group.  Journey Info Vehicle­Journey­Name 0:1 NLString Nom commercial de la course.   JourneyNote 0:* NLString Texte complémentaire décrivant la course.  EstimatedInfo Headway­Service 0:1 xsd:boolean Indique si la course est gérée dans un contexte d’exploitation (ou d’information seulement) en fréquence.\nValeur par défaut : « false ».\n   Origin­Aimed­Departure­Time 0:1 xsd:date­Time Heure théorique de départ de la course à son point de départ.   Destination­Aimed­Arrival­Time 0:1 xsd:date­Time Heure théorique d'arrivée de la course à son point de d'arrivée.   FirstOrLastJourney 0:1 FirstOrLastJourneyEnum Indique s'il s'agit de la première ou de la dernière course de la journée d'exploitation sur la ligne, et pour une destination donnée. L'interprétation comme \"première ou dernière course pour une mission donnée\" est acceptable, mais devra être précisée dans les spécifications d'interface du serveur (et le JourneyPatterInfoGroup devra alors être renseigné).\n(firstServiceOfDay | lastServiceOfDay | otherService | unspecified).\n  Disruption­Group ::: 0:1 Disrupt­ion­Group Voir Disruption­Group.  Journey­Progress­Info ::: 0:1 Journey­Progresss­Info­Group voir Journey­Progress­Info­Group.\nDetailLevel: normal.\n  Opera­tional­Info TrainNumber 0:* sequence Séquence de numéro de train (l'utilisation d'une sequence permet notament de gérer les trains couples)   ➞ TrainNumberRef 1:1 ➞ TrainNumber Numéro de train   JourneyParts 0:* sequence Liste des parties de course concernée par les Call ci-dessous.   ➞ JourneyPart­Info 1:1 +Structure Information sur les parties de course   ⇉ Journey­PartRef 0:1 ➞ JourneyPart­Code Dans le cadre du profil France ce champ permettra d'identifier les portions de courses exploitées par des opérateurs différents : les valeurs d'identification des JourneyPart sont des données de référence qui devront être fixées en amont de l'échange.\nExemple de Ile de France : cas du RER, les portions de courses exploitées par la RATP et celles exploitées par la SNCF\n   ⇉ Train­NumberRef 0:1 ➞ TrainNumber n'ont pas été échangés mais que la parité doit tout de même être échangée, le champ précédent (JourneyPartRef, qui est obligatoire) prendra la valeur arbitraire de \"unknown\".  Calls ➞ RecordedCalls 0:1 +Structure Description ordonnée des passages déjà réalisés   ⇉ RecordedCall 1:* +Structure Décrit un arrêt déjà desservi par la course.   ➞ Estimated­Calls 0:1 +Structure La séquence des arrêts déjà desservis dans l'ordre où ils ont été desservis par le VehicleJourney.\nVeuillez noter que tous les arrêts de la séquence doivent être dans l'ordre chronologique. (Sauf si l'enregistrement d'un appel est manqué, cet appel peut être conservé dans la séquence en tant qu'appel estimé correspondant même après avoir été passé.)\n   ⇉ Estimated­Call 1:* +Structure Voir EstimatedCall.   IsComplete­Stop­Sequence 0:1 xsd:boolean Indique si la liste des arrêts est complète ou non.\nDans le cadre du profil France, en mode requête-réponse, elle sera toujours complète - le champ vaudra donc ‘true’ (on remonte l'ensemble des passages non encore échus).\nEn mode abonnement, le mode différentiel étant appliqué, la séquence d'arrêt sera régulièrement incomplète.\nIl faut noter que cette indication ne concerne que les passages à échoir et non les passages déjà échus.\n  Any Extensions 0:1 any Emplacement pour extension utilisateur (cf 5.4.2.2)     Structure RecordedCall Structure permettant de décrire les informations concernant un arrêt déjà desservi par une course.\n   RecordedCall +Structure Décrit un arrêt déjà desservi par la course.      Stop Identity Stop­Point­Ref 1:1 → StopPoint­Code Identifiant du Point d'arrêt (cet identifiant est à rapprocher de l’attribut MonitoringRef de la structure MonitoredStopVisit, mais restreint à ce cas de point d’arrêt là ou le MonitoringRef peut aussi, dans le contexte général de SIRI, , référencer un afficheur, par exemple).     Order 1:1 xsd:positive­Integer Numéro d'ordre de l'arrêt dans la mission.\nVeuillez noter que la séquence doit contenir tous les arrêts décrits (appel), c'est-à-dire que l'ordre doit être une séquence continue de l'appel enregistré enregistré à l'appel estimé à venir.\n   Stop­Point­Name 0:1 NLString Nom du point d'arrêt.  Change ExtraCall 0:1 xsd:boolean Signale si cet arrêt a été ajouté sur la course (par rapport aux horaires théoriques).   Cancellation 0:1 xsd:boolean La valeur « true » signale que, contrairement à ce que prévoyaient les horaires théoriques, cet arrêt n’est plus desservi.\nValeur par défaut : « false ».\n   Occupancy 0:1 full | seats­Available | standing­Available | unknown | empty | manySeatAvailable | fewSeatAvailable | standingRoomOnly | crushStandingRoomOnly | notAcceptingPassengers Indique le niveau d’occupation du vehicule au départ de l’arrêt. Ne permet pas de distinguer le taux d’occupation par voiture.\nOn utilisera les attributs au niveau de la course.\nValeur par défaut « Unknown ».\nValeurs issues du CR17.\n   Platform­Traversal 0:1 xsd:boolean La valeur « true » permet de signaler le passage d'un train sans arrêt (et de demander au voyageur de s'écarter des voies).\nValeur par défaut : « false ».\n  Disruption­Group ::: 0:1 Disrupt­ion­Group Voir Disruption­Group.  Arrival AimedArrival­Time 0:1 xsd:dateTime Heure d'arrivée théorique (ou commandée).   ActualArrivalTime 0:1 xsd:dateTime Heure réalisée. A renseigner sauf pour le terminus départ   Expected­Arrival­Time 0:1 xsd:dateTime Heure d'arrivée estimée par le SAE.\nÀ utiliser uniquement si l’arrêt correspondant a été enregistré avec le statut d'arrivée \"manqué\" et/ou si l'heure d'arrivée réelle de cet arrêt enregistré est inconnue/annulée, car l’arrêt n'a pas été desservi malgré la planification ou les données d'arrivée pour l’arrêt desservi n'ont pas été enregistrées.\n   Arrival­Status 0:1 onTime | missed | arrived | notExpected | | delayed | early | cancelled | noReport Caractérisation de l'horaire d'arrivée attendu (ou mesuré si le véhicule est à quai).\nValeur par défaut : « onTime »\nCf 6.2.2.2.\n   ArrivalProximity­Text 0:* NLString Texte libre à présenter quand le véhicule est proche, par exemple \"à l'approche\".   Arrival­PlatformName 0:1 NLString Identification ou nom du quai d'arrivée (zone d’embarquement).   Arrival­Boarding­Activity 0:1 alighting | noAlighting | passThru On utilisera le Departure­Boarding­Activity dans le profil France.   ArrivalStopAssignment 0:1 +Structure Affectation du point d'arrêt planifié à un quai (zone d’embarquement).   ➞ Aimed­­QuayRef 0:1 ➞ QuayCode­Type Physical QUAY to use according to the planned timetable.   ➞ Aimed­­QuayName 0:1 NLString Indication de la voie d'arrivée (en complément de Platform).   ➞ Expected­­QuayRef 0:1 ➞ QuayCode­Type Physical QUAY to use according to the real-time prediction.  Departure Aimed­Departure­Time 0:1 xsd:dateTime Heure de départ théorique (ou commandée).   Actual­Departure­Time 0:1 xsd:dateTime Heure de départ réalisée. A renseigner sauf pour le terminus d’arrivée.   Expected­Departure­Time 0:1 xsd:dateTime Heure de départ estimée par le SAE.  Departure Status Departure­Status 0:1 onTime | early | delayed | cancelled | arrived |departed | notExpected | noReport Caractérisation de l'horaire de départ attendu (ou mesuré si le véhicule est à quai).\nValeur par défaut : « onTime ».\nCf 6.2.2.2.\n   Departure­Platform­Name 0:1 NLString Identification ou nom du quai de départ (zone d’embarquement)..   Departure­Boarding­Activity 0:1 boarding | noBoarding | passThru Caractérisation de l'horaire de départ attendu (ou mesuré si le véhicule est à quai).\nValeur par défaut : « boarding ».\n   ➞ ExpectedQuayRef 0:1 ➞ QuayCode­Type Physical QUAY (Platform) to use according to the real-time prediction.   ExpectedDepartureOccupancy 0:1 +structure Permet de décrire l’occupation d’un véhicule à un arrêt. Cf § 6.1.3.2.   ExpectedDepartureCapacity 0:1 +structure Permet de décrire les capacités d‘un véhicule selon le type de place cf § 6.1.3.3.  any Extensions 0:1 any Emplacement pour extension utilisateur (cf 5.4.2.2).    Structure EstimatedCall    EstimatedCall +­Structure Description d’un arrêt prévu, avec ses informations horaires.      Stop Identity Stop­Point­Ref 1:1 ➞ StopPoint­Code Identifiant du Point d'arrêt (cet identifiant est à rapprocher de l’attribut MonitoringRef de la structure MonitoredStopVisit, mais restreint à ce cas de point d’arrêt là ou le MonitoringRef peut aussi, dans le contexte général de SIRI, , référencer un afficheur, par exemple).     Order 1:1 xsd:positive­Integer Numéro d'ordre de l'arrêt dans la mission.Obligatoire dans le profil France pour correspondre au choix fait dans RecordedCall.   Stop­Point­Name 0:1 NLString Nom du point d'arrêt.  Change ExtraCall 0:1 xsd:boolean Signale si cet arrêt a été ajouté sur la course (par rapport aux horaires théoriques).   Cancellation 0:1 xsd:boolean La valeur « true » signale que, contrairement à ce que prévoyaient les horaires théoriques, cet arrêt n’est plus desservi.\nValeur par défaut : « false ».\n   Occupancy 0:1 full | seats­Available | standing­Available | unknown | empty | manySeatAvailable | fewSeatAvailable | standingRoomOnly | crushStandingRoomOnly | notAcceptingPassengers Indique le niveau d’occupation du vehicule à l’arrêt. Ne permet pas de distinguer le taux d’occupation par voiture.\nOn utilisera les attributs au niveau de la course.\nValeur par défaut « Unknown ».\nValeurs issues du CR17.\n  Call Rail Group Platform­Traversal 0:1 xsd:boolean La valeur « true » permet de signaler le passage d'un train sans arrêt (et de demander au voyageur de s'écarter des voies).\nValeur par défaut : « false ».\n  Call Property Destination­Display 0:1 NLString Destination telle qu'elle est affichée sur la girouette du véhicule à cet arrêt (ou sur l’afficheur local).  Disruption­Group ::: 0:1 Disrupt­ion­Group Voir Disruption­Group.  Arrival Aimed­Arrival­Time 0:1 xsd:dateTime Heure d'arrivée théorique (ou commandée).   Expected­Arrival­Time 0:1 xsd:dateTime Heure d'arrivée estimée par le SAE.   Arrival­Status 0:1 onTime | missed | delayed | early | cancelled | noReport Caractérisation de l'horaire d'arrivée attendu (ou mesuré si le véhicule est à quai).\nValeur par défaut : « onTime ».\nCf 6.2.2.2.\n   ArrivalProximity­Text 0:* NLString Texte libre à présenter quand le véhicule est proche, par exemple \"à l'approche\".   Arrival­PlatformName 0:1 NLString Identification ou nom du quai d'arrivée (zone d’embarquement).   ArrivalStopAssignment 0:1 +Structure Affectation du point d'arrêt planifié à un quai (zone d’embarquement).   ➞ Aimed­­QuayName 0:1 NLString Indication de la voie d'arrivée (en complément de Platform).   Departure Aimed­Departure­Time 0:1 xsd:dateTime Heure de départ théorique (ou commandée).   Expected­Departure­Time 0:1 xsd:dateTime Heure de départ estimée par le SAE.  Departure Status Departure­Status 0:1 onTime | early | delayed | cancelled | noReport Caractérisation de l'horaire de départ attendu (ou mesuré si le véhicule est à quai).\nValeur par défaut : « onTime ».\nCf 6.2.2.2.\n   Departure­Platform­Name 0:1 NLString Identification ou nom du quai de départ (zone d’embarquement)..   Departure­Boarding­Activity 0:1 boarding | noBoarding | passThru Caractérisation de l'horaire de départ attendu (ou mesuré si le véhicule est à quai).\nValeur par défaut : « boarding ».\n   ExpectedDepartureOccupancy 0:1 +structure Permet de décrire l’occupation d’un véhicule à un arrêt. Cf § 6.1.3.2.   ExpectedDepartureCapacity 0:1 +structure Permet de décrire les capacités d‘un véhicule selon le type de place cf § 6.1.3.3.   Aimed­Headway­Interval 0:1 Positive­Duration Fréquence de passage théorique (ou commandée).   Estimated­Headway­Interval 0:1 Positive­Duration Fréquence de passage estimée par le SAE.  any Extensions 0:1 any Emplacement pour extension utilisateur (cf 5.4.2.2).    Il faut noter que le document SIRI donne des indications nombreuses et précises sur cette structure, en particulier en « partie 3 : 6.6 Handling of Predictions in the Estimated Timetable Service ».\nExpectedDepartureOccupancy  Expected-Departure-Occupancy 0:* +Structure Occupations en temps réel d'un véhicule et réservations au départ d'un arrêt donné.\nIl peut s'agir d'un retour d'information d'un système de comptage automatique des passagers (APC) ou de valeurs estimées à partir de statistiques.\n    Passenger-Category 0:1 NLString Adulte, enfant, fauteuil roulant etc.  Occupancy-Level 0:1 Occupancy-Enumeration Un chiffre approximatif de l'occupation ou du remplissage du VÉHICULE, par ex. ‘manySeatsAvailable’ ou ‘standingRoomOnly’.\nDes données plus précises peuvent être fournies par les occupations ou capacités individuelles ci-dessous.L’énumération ‘occupancy’ est le suivant :\nfull | seats­Available | standing­Available | unknown | empty | manySeatAvailable | fewSeatAvailable | standingRoomOnly | crushStandingRoomOnly | notAcceptingPassengers\n  Occupancy-Percentage 0:1 PercentageType Pourcentage utilisé de la charge utile maximale après le départ du POINT D'ARRÊT PRÉVU.  AlightingCount 0:1 NumberOf-Passengers Nombre total de passagers descendants pour cette course à ce POINT D'ARRÊT PLANIFIE.  Boarding-Count 0:1 NumberOf-Passengers Nombre total de passagers embarquant pour cette course à ce POINT D'ARRÊT PLANIFIE.  OnboardCount 0:1 NumberOf-Passengers Nombre total de passagers à bord après le départ du POINT D'ARRÊT planifié.  Group-Reservation 0:* +Structure Permet de préciser qu'un groupe de voyage a réservé une section du véhicule pour une partie du trajet, et si oui sous quel nom.  ➞ NameOf-Group 1:1 NLString Nom pour lequel le groupe de voyage a effectué la réservation.  ➞ NumberOf-Seats 1:1 NumberOfPassengers Nombre de places réservées par le groupe.    Structure ExpectedDepartureCapacity    Expected-Departure-Capacities 0:* +Structure Capacités en temps réel (nombre de places disponibles) d\u0026rsquo;un VEHICULE après le départ d\u0026rsquo;un arrêt donné. Autre moyen de communiquer les mesures d\u0026rsquo;occupation.        ::: 0:1 TrainFormation-ReferenceGroup Voir SIRI Partie 2 TrainFormationReferenceGroup.     Passenger-Category 0:1 NLString Adulte, enfant, fauteuil roulant etc.   TotalCapacity 0:1 NumberOf-Passengers La capacité totale du véhicule en nombre de passagers.   Seating-Capacity 0:1 NumberOf-Passengers Le nombre de places assises du véhicule en nombre de passagers.   Standing-Capacity 0:1 NumberOf-Passengers La capacité debout du véhicule en nombre de passagers.   Pushchair-Capacity 0:1 NumberOf-Passengers Le nombre de places de poussette du véhicule.   Wheelchair-PlaceCapacity 0:1 NumberOf-Passengers Le nombre de places en fauteuil roulant du véhicule.   PramPlace-Capacity 0:1 xsd:nonnegative-Integer Le nombre de places du véhicule adaptées aux poussettes.   BicycleRack-Capacity 0:1 xsd:nonnegative-Integer Le nombre de porte-vélos du véhicule.     Gestion des passages échus Ce paragraphe a pour objectif de décrire la gestion de la transition entre un passage estimé (EstimatedCall) et un passage échu (RecordedCall).\nLa trame ET permet de transmettre pour chaque course les informations relatives aux prochaines passages (estimatedcall) à réaliser et ceux déjà réalisés (recordedcall).\nLes EstimatedCall contiennent des informations horaires sur les arrivées et/ou départ à un arrêt : théorique (aimed) ou estimée (estimated).\nLes RecordedCall permettent de renseigner les informations horaires sur les arrivées et/ou départ à un arrêt déjà réalisés par une course.\nTout événement ‘Véhicule arrivé’ ou ‘véhicule départ’ déclenche une mise à jour de l’EstimatedVehicleJourney des données réalisées (‘Actual’) du recordedCall.\nLa définition de l’évènement véhicule arrivé ou Véhicule parti n’est pas définie dans le cadre du profil France. A titre d’exemple les implémentations les plus répondues pour la détection :\n  de l’arrivée d’un véhicule sont :\n  Libération du verrouillage des portes après arrêt du véhicule\n  déclenchement d’un evenement de signalisation d’entrée dans une zone d’arrêt ;\n    du départ d’un véhicule sont :\n  Verrouillage des portes d’un véhicule à l’arrêt\n  déclenchement d’un evenement de signalisation de sortie de zone d’arrêt ;\n    Les schémas ci-dessous décrivent pour une course les structures Estimated/Recorded call utilisées en fonction de la localisation du véhicules.\n1, 2, 3 et 4 representent des arrêts.\n(E) indique que les information horaires de la course à un arrêt sont positionnées dans un EstimatedCall.\n(R) indique que les information horaires de la course à un arrêt sont positionnées dans un RecordedCall.\nCas Général Avant le départ de la course\nLes trames ET ne contiennent que des EstimatedCall\nPendant la course\nLes informations relatives aux arrêts déjà désservis sont transmises dans les structures RecordedCall.\nA l’arrêt\nConsidérons un véhicule réalise une séquence d\u0026rsquo;arrêt 1 =\u0026gt; 2 =\u0026gt; 3.\n1. Sur la route ou les rails entre l\u0026rsquo;arrêt 1 et 2 (le véhicule est déjà parti de l\u0026rsquo;arrêt 1 mais n’est pas encore arrivé à l\u0026rsquo;arrêt 2), les EstimatedCalls sont transmis pour tous les arrêts à venir. En particulier, les mises à jour SIRI ET sont transmises pour les ajustements de l\u0026rsquo;heure prévue à l\u0026rsquo;arrêt 2 (voir ci-dessus).\n2. Dès que le véhicule arrive effectivement à l\u0026rsquo;arrêt 2 (le déclencheur est, par exemple, un événement de déverrouillage de porte), une mise à jour RecordedCall est transmise avec l\u0026rsquo;ActualArrivalTime correspondant.\n3. Toujours à l\u0026rsquo;arrêt 2, si le véhicule doit attendre un peu plus longtemps que prévu, une mise à jour SIRI-ET correspondante doit être déclenchée avec un ajustement de la ExpectedDepartureTime du recordedCall pour le départ retardé à l\u0026rsquo;arrêt 2. La mise à jour SIRI-ET correspondant à cet événement doit au moins comprendre l\u0026rsquo;arrêt de référence RecordedCall de l’arrêt 2 (par StopPointRef) ainsi que le ExpectedDepartureTime ajusté de ce recordedcall.\n4. Après le départ effectif du véhicule à l\u0026rsquo;arrêt 2 (le déclencheur est, par exemple, un événement de verrouillage de porte), le RecordedCall enregistré à l’étape 3 pour l\u0026rsquo;arrêt 2 est mis à jour avec ActualDepartureTime.\nComme règles générales dans ce contexte :\n   ET001 L’implémentation des recordedcalls est facultative.     ET010 Un seul type de passage (enregistré ou estimé) est associé à un arrêt à un moment donné dans un cycle de vie EstimatedVehicleJourney ou une séquence de messages de mise à jour.   ET015 Après l\u0026rsquo;enregistrement de l\u0026rsquo;arrivée effective à un arrêt, toutes les mises à jour potentielles se rapportant à cet arrêt doivent être transmises dans les RecordedCall respectifs.   ET020 Si, lors de l’activation d\u0026rsquo;un nouvel abonnement, toutes les courses actives sont transmises, le producteur doit également inclure pour ces courses les RecordedCalls déjà transmis (pour chaque trajet estimé) de ces arrêts qui sont déjà dans le passé ou qui ont été enregistrés.     Cas particulier Passage sans arrêt\nSi un véhicule passe par un arrêt sans réellement s\u0026rsquo;arrêter ou ne s\u0026rsquo;arrête que brièvement sans ouvrir ses portes (en déverrouillant ses portes), le producteur de données définira les propriétés Arrival- et DepartureBoardingActivity sur \u0026lsquo;passThru\u0026rsquo; indépendamment du fait que le passthrough était prévu, attendu ou exceptionnel (inconnu avant la survenance de l\u0026rsquo;événement).\nÀ partir de SIRI 2.1, BoardingActivity peut également être spécifié dans un RecordedCall. Il est donc possible d’enregistrer explicitement un passage exceptionnel par rapport à l\u0026rsquo;interface SIRI-ET. Ainsi, au lieu d\u0026rsquo;une mise à jour du BoardingActivity présent dans l’EstimatedCall en tant qu\u0026rsquo;effet de l\u0026rsquo;événement passthrough, seule la mise à jour RecordedCall suivante est déclenchée avec les informations BoardingActivity requises.\nSi les événements d\u0026rsquo;arrivée et de départ sont déclenchés par des signaux d\u0026rsquo;entrée et de sortie, les événements de passage sont généralement également pris en charge. Cependant, si les événements d\u0026rsquo;arrivée et de départ sont déclenchés par des signaux d\u0026rsquo;ouverture/fermeture de portes, alors un passage sans arrêt n’activera aucun événement permettant un enregistrement de l\u0026rsquo;heure réelle de passage, ni une mise à jour RecordedCall. Ce dernier ne sera généré qu\u0026rsquo;au prochain événement déclencheur de message y compris le prochain événement d\u0026rsquo;arrivée ou de départ à un arrêt ultérieur. Sans mécanismes supplémentaires (par exemple, déclenchés manuellement par le conducteur), cela retarde potentiellement, voire empêche, la suppression des messages des panneaux d\u0026rsquo;affichage (ce qui doit se produire immédiatement après le départ).\nArrêt Optionel\nSi un véhicule ne s\u0026rsquo;arrête pas réellement dans le cas où RequestStop est \u0026ldquo;vrai\u0026rdquo; pour le passage estimé correspondant, alors le producteur doit se comporter comme si le véhicule s\u0026rsquo;était arrêté. En conséquence, non seulement un RecordedCall doit être généré avec des enregistrements des temps réels mais également la course immédiatement supprimée de tous les panneaux d\u0026rsquo;affichage.\nStop Monitoring    SM005 La notion de «niveau de détail » (Detail Level) proposée pour ce service par SIRI n\u0026rsquo;est pas retenue pour le profil SIRI France.     Matrice de capacité    SM010 Cette matrice n\u0026rsquo;est pas échangée dans le cadre du profil France :     Cette,matrice est présentée ici pour indiquer les principales fonctions retenues pour le service (les explications ne sont pas traduites dans ce tableau, mais on retrouve les traductions dans les tableaux qui suivent).\n          TopicFiltering      DefaultPreview­Interval Oui    FilterByMonitoring­Ref Oui    FilterByLineRef Oui    FilterByDestination Oui              RequestPolicy      GmlCoordinateFormat Oui    UseReferences Oui    UseNames Oui    HasMinimum­StopVisits­PerLine Oui    HasNumberOf­OnwardsCalls Oui   SubscriptionPolicy HasIncremental­Updates Oui    HasChangeSensitivity Oui    Requête d\u0026rsquo;information temps réel au point d\u0026rsquo;arrêt Granularité des points d’arrêt Note importante : Il est possible d’effectuer une requête sur un ensemble de points d’arrêt. On constatera, ci-dessous, que le champ « MonitoringRef », qui caractérise le point d’arrêt, a une cardinalité 1:1, cela vient du fait que c’est l’ensemble du bloc « StopMonitoringRequest » qui doit être répété au sein de la structure « ServiceRequest ». Cela se justifie par le fait que, dans un certain nombre de cas, la désignation du simple « MonitoringRef » peut s’avérer insuffisante (s‘il s’agit d’un ‘Lieu d’arrêt (multimodal), on pourra, par exemple, être amené à préciser la ligne et la destination en plus du « MonitoringRef »…).\nNote concernant la granularité des objets interrogés :\nLe « MonitoringRef » peut aussi bien référencer :\n  Un lieu d’arrêt multimodal,\n  Un pôle monomodal,\n  Un lieu d’arrêt monomodal,\n  une Zone d\u0026rsquo;Embarquement.\n     SM015 Toutefois il n\u0026rsquo;y a pas d\u0026rsquo;obligation pour un serveur de supporter tous ces niveaux (sauf pour les concentrateurs pour lesquels le Lieu d’arrêt (multimodal/monomodal est obligatoire): il conviendra donc de s\u0026rsquo;assurer que le serveur sollicité reconnait bien le niveau requis    Statuts de départ \u0026amp; Arrivée Note concernant les heures de passage :\nSIRI propose plusieurs niveaux d\u0026rsquo;information sur les heures de passage:\n  Aimed(Departure/Arrival)Time : Heure d\u0026rsquo;arrivée ou de départ théorique. Il s\u0026rsquo;agit là de l\u0026rsquo;heure planifiée (figurant dans les fichiers horaires). Il peut aussi s\u0026rsquo;agir de l\u0026rsquo;horaire replanifié du matin s’il est disponible (horaire commandé).\n  Actual(Departure/Arrival)Time : Heure d\u0026rsquo;arrivée ou de départ effectivement mesurée (et donc disponible uniquement après le départ ou l’arrivée du véhicule).\n  Expected(Departure/Arrival)Time : Heure d\u0026rsquo;arrivée ou de départ calculée par le SAE sur la base de la progression du véhicule et du commandé (ou modifié en cours d\u0026rsquo;exploitation).\n     SM020 Il n\u0026rsquo;est pas obligatoire de diffuser avant le départ du véhicule l\u0026rsquo;horaire théorique modifié du jour même ou modifié en cours d\u0026rsquo;exploitation suite à une régulation. Cette information peut par contre être renseignée dans l' «Expected(Departure/Arrival)Time», le champ étant par la suite mis à jour en fonction de l\u0026rsquo;avancement du véhicule.     SM025 En mode requête classique, les heures de passage à l\u0026rsquo;arrêt ne sont fournies que tant que le véhicule est en amont de l’arrêt ou à l’arrêt ; dès lors qu’il a quitté l’arrêt, aucune information concernant ce véhicule à cet arrêt n\u0026rsquo;est plus fournie (dans la limite ci-dessous).   SM030 En mode abonnement, une notification est envoyée lorsque le véhicule a quitté l’arrêt, en utilisant la structure « MonitoredStopVisitCancellation ». Ceci permet de signaler aux diffuseurs que le prochain passage en question doit être retiré des medias de diffusion (on utilisera donc pas le champ \u0026ldquo;ActualDepartureTime\u0026rdquo; à cet effet). En complément, une notification est aussi réalisée lors de l\u0026rsquo;arrivée au dernier arrêt (En effet, il n\u0026rsquo;y aura pas de notification de départ dans ce cas: on notifiera alors un « MonitoredStopVisitCancellation » au moment de l\u0026rsquo;arrivée du véhicule à l\u0026rsquo;arrêt).   SM040 En situation perturbée il peut arriver qu\u0026rsquo;une information «Expected(Departure/Arrival)Time» soit antérieure à l’heure courante. Toutefois il est précisé qu\u0026rsquo;en tout état de cause, un temps d’attente inférieur ou égal à 0, induit par une telle information, doit être diffusé comme un temps d’attente égal à 0 (et probablement accompagné d\u0026rsquo;une indication de retard).     SIRI propose des statuts de départ et d\u0026rsquo;arrivée pour qualifier l\u0026rsquo;horaire calculé par rapport à l\u0026rsquo;horaire planifié. Le tableau ci-dessous précise l\u0026rsquo;usage des différentes valeurs de statuts.\n   Statuts ArrivalStatus DepartureStatus     onTime A l’heure ; la notion peut être précisée à la discrétion du producteur selon un seuil à préciser dans les spécifications d’interface à titre informatif. A l’heure ; la notion peut être précisée à la discrétion du producteur selon un seuil à préciser dans les spécifications d’interface à titre informatif.   Early En avance par rapport à l’horaire théorique ; la notion peut être précisée à la discrétion du producteur selon un seuil à préciser dans les spécifications d’interface à titre informatif. En avance par rapport à l’horaire théorique ; la notion peut être précisée à la discrétion du producteur selon un seuil à préciser dans les spécifications d’interface à titre informatif.   Delayed En retard par rapport à l’horaire théorique ; la notion peut être précisée à la discrétion du producteur selon un seuil à préciser dans les spécifications d’interface à titre informatif. En retard par rapport à l’horaire théorique ; la notion peut être précisée à la discrétion du producteur selon un seuil à préciser dans les spécifications d’interface à titre informatif.   Cancelled Passage annulé Passage annulé (note: ce passage annulé reste comptabilisé dans le nombre de passages utilisé dans les filtres de requêtes).   noReport Pas d’information « ExpectedArrivalTime » disponible (par contre le « AimededArrivalTime » peut être fourni) Pas d’information disponible    Derniers arrêts de course Note concernant les derniers arrêts de course:\nIl existe plusieurs façons d\u0026rsquo;identifier le dernier arrêt d\u0026rsquo;une course :\n  La plus fiable consiste à faire la distinction des terminus par constat d\u0026rsquo;égalité dans le VehicleJourneyInfoGroup entre l\u0026rsquo;arrêt courant et l\u0026rsquo;arrêt de destination de la course.\n  Toutefois, cela peut aussi être fait en constatant que l\u0026rsquo;on a un ArrivalTime mais pas de DepartureTime\n  ou encore, quand cela est possible, en demandant des informations sur les arrêts suivants (onwardCall, en demandant au moins un arrêt) et en constatant qu\u0026rsquo;il n\u0026rsquo;y en a pas.\n  Note concernant les cas ou il n\u0026rsquo;y a pas ou plus d\u0026rsquo;information:\n   SM045 S\u0026rsquo;il n\u0026rsquo;y a de réponse à une requête « Stop monitoring » car elle intervient après le dernier passage de la journée, le producteur doit dans la mesure du possible fournir une information via le service « General message ». Il est donc recommandé que le client, s\u0026rsquo;il n\u0026rsquo;obtient pas de réponse au « Stop monitoring », fasse dans la foulée une requête au « General message ».     SM050 Dans le cas des déviations : pour les arrêts non desservis, il conviendra aussi de fournir une information via le service « Situation Exchange » (SX) (la réponse à « Stop monitoring n\u0026rsquo;est toutefois pas forcément vide si la déviation est temporaire ») ou le service « General Message » si le SX n’est pas implémenté.     Note concernant les annulations de passage :\nConcernant les informations permettant d\u0026rsquo;indiquer l\u0026rsquo;annulation d\u0026rsquo;un passage il est précisé que:\n   SM055 Mode requête\n La réponse positionne à « Cancelled » le champ « ArrivalStatus » et/ou « DepartureStatus » dans « MonitoredCall » jusqu’à l’heure d’arrivée théorique\n Puis aucune information n'est plus fournie pour cette course.\n     SM060 Mode abonnement\n Une (unique) notification est faite en positionnant à « Cancelled » le champ « ArrivalStatus » et/ou « DepartureStatus » dans « MonitoredCall ».\n        StopMonitoringRequest +Structure Requête pour obtenir des informations temps réel sur les heures d\u0026rsquo;arrivée et de départ à un point d\u0026rsquo;arrêt.     Attributes Version 1:1 Version­String Version du service “Stop Monitoring”, , intégrant le numéro de version de profil par exemple. ‘2.1:FR-1.0’.  Endpoint Properties Request­Timestamp 1:1 xsd:dateTime Date d'émission de la requête.   Message­Identifier 1:1 Message­Qualifier Numéro d'identification du message.  Topic Preview­Interval 0:1 Positive­Duration­Type Si ce paramètre est présent, il indique que l'on souhaite recevoir des informations sur toute arrivée et tout départ intervenant dans la durée indiquée (comptée à partir de l'heure indiquée par le paramètre suivant: StartTime -. si le paramètre StartTime n'est pas présent, l'heure courante sera utilisée).   StartTime 0:1 xsd:dateTime Heure à partir de laquelle doit être compté le Preview­Interval.   Monitoring­Ref 1:1 Monitoring­Code Identifiant du point d'arrêt concerné par la requête.\nIl convient d'utiliser ici un identifiant d'objets (arrêt) de référence (Zone d'Embarquement, Lieu d’arrêt multi ou mono modal ou Groupe de Lieux), et non d'objet particulier.\n   LineRef 0:1\n0:0\n LineCode Filtre permettant de n'obtenir que les départs et arrivées pour une ligne donnée (dont on fournit l'identifiant).\nFiltre non utilisé entre le relai et ses concentrateurs alimentants (le relai s'informe sur toutes les lignes sans distinction).\n   Destination­Ref 0:1\n0:0\n StopPoint­Code Filtre permettant de n'obtenir que les départs et arrivées ayant une destination donnée (dont on fournit l'identifiant de point d'arrêt).\nFiltre non utilisé entre le relai et ses concentrateurs alimentant (le relai s'informe sur toutes les directions sans distinction).\n   OperatorRef 0:1\n0:0\n Operator­Code Filtre permettant de n'obtenir que les départs et arrivées pour un exploitant donné (dont on fournit l'identifiant).\nFiltre particulièrement utile pour les pôles d'échange.\nFiltre non utilisé entre le relai et ses concentrateurs alimentants (le concentrateur).\n   StopVisit­Types 0:1\n0:0\n all | departures | arrivals Indique si l'on souhaite avoir les départs, les arrivées ou les deux.\nSeule la valeur « departures » est obligatoire (pour tous les arrêts sauf, naturellement, le dernier de la mission) pour le profil FR, les autres sont optionnelles (à préciser pour chaque implémentation).\nSi le champ n’est pas renseigné, la valeur par défaut est « all ».\nQuelques règles de gestion sont précisées :\n  dans le cas du StopVisitTypes = all ou departures, si l’heure de départ n'est pas connue (pour les SAEIV bus notament) alors l'heure de départ sera renseignée égale à l'heure d’arrivée et les 2 champs sont renseignés.\n  Inversement, dans le cas du StopVisitTypes = all ou arrivals, si l’heure d’arrivée n'est pas connue alors l'heure d’arrivée prend la valeur de l'heure de départ et les 2 champs sont renseignés.\n  Il faut noter que, pour la gestion des correspondances, l’heure d’arrivée sera particulièrement utile …\nCe champ est facultatif (sauf dans le cas des échanges avec les concentrateurs: voir ci-dessous), toutefois l'XSD lui définit une valeur par défaut qui est \"all\". S'il n'est pas présent il faut donc le gérer comme s'il était positionné à \"all\".\nDans le cas des échanges avec les concentrateurs, ce filtre ne sera jamais présent et c'est donc avec la valeur par défaut all qu'il faudra l'interpréter.\n  Request Policy Maximum­StopVisits 0:1\n0:0\n xsd:nonNegativeInteger Nombre maximal d'informations de départ ou d'arrivée que l'on souhaite recevoir sur l’arrêt requêté. Si aucune valeur n’est fournie, toutes les informations disponibles seront remontées.\nDe plus « 0 » est une valeur interdite pour ce champ (erreur).\nFiltre non utilisé entre le relai et ses concentrateurs alimentants : pas de limitation du nombre d'informations remontées.\n   Choix -1:1     a) Minimum­StopVisits­PerLine 0:1\n0:0\n xsd:nonNegativeInteger Ce paramètre permet de demander un nombre minimum de réponses par ligne passant à l'arrêt. Cela permet d'éviter que pour un arrêt où passent 2 lignes et pour lesquels on a demandé les quatre prochains passages, on ait bien quatre indications mais sur une seule des deux lignes (les passages sur la seconde ligne intervenant après).\nDans ce cas, si ce paramètre est fixé à 2 on obtiendra les deux prochains passages sur chacune des lignes.\nCes passages doivent toutefois rester dans le Preview­Interval\nIl est recommandé de ne pas utiliser simultanément Maximum­StopVisits et Minimum­StopVisits­PerLine : si toutefois cela arrivait, le Maximum­StopVisits serait dominé par le Minimum­StopVisits­PerLine et la liste des informations disponibles pourrait être plus importante que stipulé par Maximum­StopVisits.\nFiltre non utilisé entre le relai et ses concentrateurs alimentants\n   b) MinimumStop­Visits­PerLine­Via 0:1\n0:0\n xsd:nonNegative­Integer Ce paramètre permet de demander un nombre minimum de réponses (de passage) par couple Ligne+Via (et donc pour chaque itinéraire identifiable). Ce paramètre est très similaire à MinimumStopVisitsPerLine mais propose une granularité plus fine (au niveau itinéraire). La notion d'itinéraire n'étant pas toujours explicitement présente dans les systèmes, on pourra interpréter ce paramètre comme une demande de nombre minimum de réponses par itinéraire possible (et par ligne).\nNote: ce filtre étant à comprendre comme \"nombre de passage pour tous les VIA possibles\", les VIA ne sont naturellement pas à préciser.\nFiltre non utilisé entre le relai et ses concentrateurs alimentants\n   Maximum­Number­Of­Calls 0:1\n0:0\n +Structure Structure permettant de préciser combien d’arrêts suivants ou précédents on souhaite obtenir au maximum (sous réserve de leur disponibilité). Si cette structure facultative n'est pas présente, aucun arrêt suivant ou précédent ne sera retourné.\nFiltre non utilisé entre le relai et ses concentrateurs alimentants : aucune information de type OnwardCall n'est remontée par les concentrateurs.\n   ➞ Onwards 0:1\n0:0\n xsd:nonNegativeInteger Nombre maximal d'arrêts suivants souhaités (pour une course donnée).\nSi le paramètre est présent et vaut 0, tous les arrêts seront retournés.\nS’il n’est pas fourni et que la balise \u0026lt;MaximumNumberOfCalls\u0026gt; est présente, tous les arrêts seront remontés.\nS'il n'y a pas de balise \u0026lt;MaximumNumberOfCalls\u0026gt; aucune information relative aux OnwardCalls n'est remontée.\nPrécisions : ces informations ne sont pas comptabilisées pour le traitement des paramètres Maximum­StopVisits et Minimum­StopVisits­PerLine qui ne concernent que l'arrêt requêté.\nFiltre non utilisé entre le relai et ses concentrateurs alimentants: pas de limitation du nombre d'informations remontées.\n  any Extensions 0:1 +Structure Emplacement disponible pour extension utilisateur (cf 5.4.2.2).    Requête multiple d\u0026rsquo;information temps réel au point d\u0026rsquo;arrêt en utilisant SOAP    SM065 Il existe plusieurs façons de réaliser des requêtes d\u0026rsquo;information temps réel pour plusieurs points d\u0026rsquo;arrêt. Toutefois seule la solution GetSiri (voir ci-dessous) est recommandée par le profil FR, les autres solutions ne pouvant être maintenues que pour compatibilité ascendante.     Le service SOAP GetSiri (introduit par SIRI 2) est celui qui doit être utilisé pour les requêtes multiples d\u0026rsquo;information temps réel au point d\u0026rsquo;arrêt. Ce point d\u0026rsquo;accès fonctionnel est générique et permet de solliciter n\u0026rsquo;importe quel service SIRI avec une cardinalité de requête illimitée.\nAbonnement aux informations temps réel au point d\u0026rsquo;arrêt    StopMonitoringSubscription +Structure Requête d\u0026rsquo;abonnement pour obtenir des informations temps réel sur les heures d\u0026rsquo;arrivée et de départ à un point d\u0026rsquo;arrêt     Identity Subscriber­Ref 1:1 Participant­Code Identification du système demandeur (voir SIRI Part 2 Common SubscriptionRequest parameters.).   Subscription­Identifier 1:1 Subscription­Qualifier Identifiant de l'abonnement pour le système demandeur.  Lease Initial­Termination­Time 1:1 xsd:dateTIme Date et heure de fin de l'abonnement : un abonnement a forcément une date et heure de fin (les partenaires pourront décider de limiter la durée maximale d’un abonnement).  Request Stop­Monitoring­Request 1:1 +Structure voir StopMonitoringRequest (ci-dessus).  Policy Incremental­Updates 0:1 xsd:boolean Indique s’il faut notifier uniquement les changements d'information ou s’il faut systématiquement renvoyer toutes les informations si l'une d'elles change.\nValeur par défaut : « true » (mise à jour incrémentale).\nDans le cadre des échanges avec un concentrateur seul le mode incrémental est supporté.\n   Change­Before­Updates 0:1 Positive­DurationType Permet d'indiquer un écart de temps en dessous duquel on ne souhaite pas être notifié (si l'on demande un seuil de 5mn et qu'un horaire de départ ou d'arrivée change de 2mn, on ne sera pas notifié, évitant ainsi des flux d'information inutiles).\nSi ce champ n'est pas présent, une valeur de 5 minutes est prise par défaut.\nDans le cadre des échanges avec un concentrateur la valeur par défaut est de 1 minute.\nC’est une valeur « par défaut », qui est volontairement haute pour ne pas surcharger les échanges : dans le cas nominal elle devra être précisée avec une valeur plus faible (mais tous les systèmes ne fonctionnent pas à la minute, surtout côté client).\nCe champ est facultatif car son implémentation peut s'avérer délicate pour certains systèmes : s'il n'est pas disponible, les spécifications d'interface du serveur SIRI devront préciser les valeurs et comportements implémentés.\n    Les données sont réputées avoir changé et doivent donc être notifiées dès que :\n  La valeur d\u0026rsquo;une des heures de passage (planifiée, mesurée ou constatée) est modifiée d\u0026rsquo;une valeur supérieure ou égale au seuil demandé (ChangeBeforeUpdates) ;\n  Le véhicule quitte l\u0026rsquo;arrêt (ou arrive au dernier arrêt de la course);\n  Un changement de quai intervient.\n  Résultat de la requête d\u0026rsquo;information temps réel au point d\u0026rsquo;arrêt    ServiceDelivery  +Structure voir SIRI Part 7.2ServiceDelivery                HEADER ::: 1:1 Voir ServiceDelivery    Payload Stop­Monitoring­Delivery 0:* +Structure Voir StopMonitoringDelivery ci- dessous.    Attributs temps réel du point d\u0026rsquo;arrêt    StopMonitoringDelivery +Structure Delivery for Stop Monitoring Service.     Attributes version 1:1 Version­String Numéro de version du service Stop Monitoring, intégrant le numéro de version de profil (voir 5.9).  LEADER ::: ::: xxx­Delivery Voir paragraphe 2.2.  Pay­load MonitoringRef 1:1 Monitoring­Code Identifiant du point d'arrêt concerné par la requête.\nIl convient d'utiliser ici un identifiant d'objets (arrêt) de référence (Zone d'Embarquement, Lieu d'arrêt multimodal, monomodal, Point d’arrêt), et non d'objet particulier.\n   Monitored­Stop­Visit 0:* +Structure Description des passages à l'arrêt.   Monitored­Stop­Visit­Cancellation 0:* +Structure Indication qu'un passage précédemment signalé ne doit plus être affiché (indique généralement que le véhicule a franchi l'arrêt).  any Extensions 0:1 +Structure Emplacement pour extension utilisateur (cf 5.4.2.2).    Description d\u0026rsquo;un arrêt (ou point d\u0026rsquo;arrêt indiqué) sur une course    MonitoredStopVisit +Structure Description du passage d\u0026rsquo;un véhicule à un arrêt (dans le cadre d\u0026rsquo;une course).     Log Recorded­At­Time 1:1 xsd:dateTime Heure à laquelle la donnée a été mise à jour.  Identity Item­Identifier 1:1 ItemIdentifier Identifie cette information : cela correspond en fait à une identification du couple arrêt-course, et permettra par la suite une éventuelle annulation (cas où l’arrêt n’est plus desservi).\nIl doit être unique et pérenne et bien identifier le passage à l'arrêt.\n  Stop­Visit­Reference Monitoring­Ref 1:1 Monitoring­Code Référence du point d'arrêt.  Journey­Info MonitoredVehicleJourney 1:1 Monitored­Vehicle­Journey­Structure Description de la course.  any Extensions 0:1 any Emplacement pour extension utilisateur (cf 5.4.2.2).    Attributs temps réel de la course : Monitored Vehicle Journey | MonitoredVehicleJourney | +Structure | Description de la course. | |\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;- \u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;-|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026ndash;|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;|\n Vehicle Journey Identity LineRef 1:1 LineCode Identifiant de la ligne.   Framed­Vehicle­JourneyRef 0:1\n1:1\n +Framed­Vehicle­JourneyRef­Structure Identification de la course.\nChamp obligatoire pour les échanges avec les concentrateurs : ce champ n'est pas forcément le reflet d'une valeur d'identifiant planifié et peut être construit localement par l'émetteur, mais il sera important pour une bonne gestion des abonnements en mode différentiel (en particulier pour le service Estimated Timetable).\n  Journey­Pattern­Info ::: 0:1 Journey­Pattern­Info­Group Voir Journey­Pattern­Info­Group.  Vehicle­Journey­Info ::: 0:1 Vehicle­JourneyInfo­Group Voir Vehicle­JourneyInfo­Group.  Disruption­Group ::: 0:1 Disruption­Group Voir Disruption­Group.  Journey­Progress­Info ::: 0:1 Journey­Progresss­Info­Group voir Journey­Progress­Info­Group.  Opera­tional­Inf TrainNumber 0:* sequence Séquence de numéro de train (l'utilisation d'une sequence permet notament de gérer les trains couples).   ➞ TrainNumberRef 1:1 ➞ TrainNumber Numéro de train.   JourneyParts 0:* sequence Liste des parties de course concernées par les Call ci-dessous.   ➞ JourneyPart­Info 1:1 +Structure Information sur les parties de course.   ⇉ Journey­PartRef 1:1 ➞ JourneyPart­Code Dans le cadre du profil France ce champ permettra d'identifier, en particulier dans le contexte du RER, les portions de courses exploitées par la RATP et celles exploitées par la SNCF (les valeurs d'identification des JourneyPart sont des données de référence qui devront être fixes en amont de l'échange).   ⇉ Train­NumberRef 0:1 ➞ TrainNumber   Calling Pattern Monitored­Call 0:1 +Structure Informations horaires concernant l'arrêt considéré.   Onward­Calls 0:1 +Structure Informations horaires concernant les arrêts suivants.   ➞ Onward­Call 0:* +Structure Informations horaires pour l'un des arrêts suivants.  any        L\u0026rsquo;arrêt \n   MonitoredCall +Structure Informations horaires pour l\u0026rsquo;arrêt.     Stop Identity Stop­Point­Ref 0:1\n1:1\n StopPoint­Code Identifiant du Point d'arrêt (cet identifiant est à rapprocher de l’attribut MonitoringRef de la structure MonitoredStopVisit, mais restreint à ce cas de point d’arrêt, là ou le MonitoringRef peut aussi, dans le contexte général de SIRI, mais pas celui du profil France, référencer un afficheur, par exemple).\nIl convient d'utiliser ici un identifiant d'objet du referentiel théorique.\n- Si MonitoringRef est un lieu d’arrêt monomodal ou multimodalStopPointRef est une zone d'embarquement, si l'émetteur est capable de la fournir.\n- Sinon, StopPointRef estun lieu d’arrêt (granularité la plus fine possible dans tous les cas).\nChamp obligatoire pour les échanges avec les concentrateurs.\n   Order 0:1 xsd:positive­Integer Numéro d'ordre de l'arrêt dans la mission.   Stop­Point­Name 1:1 NLString Nom du point d'arrêt.\nSi plusieurs noms sont disponibles chez le producteur, le nom le plus détaillé sera utilisé en priorité.\n  Call Real-time Vehicle­At­Stop 0:1 xsd:boolean La Valeur «true » indique que le véhicule est à l'arrêt.\nValeur par défaut : « false ».\n  Call Rail Platform­Traversal 0:1 xsd:boolean La valeur « true » permet de signaler le passage d'un train sans arrêt (et de demander au voyageur de s'écarter des voies).\nValeur par défaut : « false ».\n  Call Property Destination­Display 0:1 NLString Destination telle qu'elle est affichée sur la girouette du véhicule à cet arrêt (ou sur l’afficheur local).  Disruption­Group ::: 0:1 Disruption­Group Voir Disruption­Group.  Arrival times Aimed­Arrival­Time 0:1 xsd:date­Time Heure d'arrivée théorique (ou commandée).   Actual­Arrival­Time 0:1 xsd:date­Time Heure d'arrivée effectivement mesurée.   Expected­Arrival­Time 0:1 xsd:date­Time Heure d'arrivée estimée par le SAE.  Arrival Status Arrival­Status 0:1 onTime | early | delayed | cancelled |\nmissed | arrived | notExpected | noReport\n Caractérisation de l'horaire d'arrivée attendu (ou mesuré si le véhicule est à quai)\nValeur par défaut : « onTime ».\nNote: SIRI 2 ajoute les codes:\n missed : le vehicule n'a pas marqué l'arrêt alors qu'il aurait du, mais la course continue.\n notExpected : départ ou arrivée non planifié(e) (cas de TAD non encore déclenché).\n    ArrivalProximity­Text 0:* NLString Texte libre à présenter quand le véhicule est proche, par exemple \"à l'approche\". Ce texte peut dépendre de règles propres à l'exploitant ou à l'AO, autant par son contenu que par les règles d'affichage qui le concernent (distance à partir de laquelle on l'affiche, etc.). Ces règles peuvent aussi être différentes suivant le lieu d'affichage de l'information (à quai, sur smartphone, dans un hall d'attente, etc.). Ces règles sont échangées en amont de façon contractuelle.   Arrival­Platform­Name 0:1 NLString Identification ou nom du quai d'arrivée.   ➞ Aimed­­QuayName 0:1 NLString Indication de la voie d'arrivée (en complément de Platform).  Departure Aimed­Departure­Time 0:1 xsd:date­Time Heure de départ théorique (ou commandée).   Actual­Departure­Time 0:1 xsd:date­Time Heure de départ effectivement mesurée.   Expected­Departure­Time 0:1 xsd:date­Time Heure de départ estimée par le SAE.  Departure Status Departure­Status 0:1 onTime | early | delayed | cancelled | arrived |departed | notExpected | noReport Caractérisation de l'horaire de départ attendu (ou mesuré si le véhicule est à quai).\nValeur par défaut : « onTime ».\n   Departure­Platform­Name 0:1 NLString Identification ou nom du quai de départ.   Departure­Boarding­Activity 0:1 boarding | noBoarding | passthru Indique si l'on peut monter dans le véhicule ou si c'est un passage sans arrêt ou avec montée interdite.\nValeur par défaut : « boarding».\n  Occupancy ExpectedDepartureOccupancy 0:* +structure Permet de décrire l’occupation d’un véhicule à un arrêt. Cf § 6.1.3.2.  Capacity ExpectedDpeartureCapacity 0:* +structure Permet de décrire les capacités d‘un véhicule selon le type de place cf § 6.1.3.3.  Frequency Aimed­Headway­Interval 0:1 Positive­DurationType Fréquence de passage théorique (ou commandée).   Expected­Headway­Interval 0:1 Positive­DurationType Fréquence de passage estimée par le SAE.  Stop Proximity Group DistanceFrom­Stop 0:1 DistanceType Distance qui sépare le vehicule de l'arrêt. Une valeur positive indique que le véhicule est en amont de l'arrêt.   NumberOf­StopsAway 0:1 nonNegative­Integer Indique le nombre d'arrêts à marquer entre la position courante du vehicule et l'arrêt considéré.  any Extensions 0:1 +Structure Emplacement pour extension utilisateur.    Arrêts suivants\n| OnwardCall | +Structure | Information sur les arrêts suivants de la course. | |\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026ndash; \u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026ndash;|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026ndash;|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;|\n Stop Identity Stop­Point­Ref 1:1 StopPoint­Code Identifiant du point d'arrêt.\nIl convient d'utiliser ici un identifiant d'objet de référence de (zone d'embarquement ou lieu d’arrêt multi/mono modal: granularité la plus fine possible dans tous les cas).\n   Order 0:1 xsd:positive­Integer Numéro d'ordre de l'arrêt dans la mission.   Stop­Point­Name 1:1 NLString Nom du point d'arrêt.  Progress Vehicle­At­Stop 0:1 xsd:boolean La Valeur «true » indique que le véhicule est à l'arrêt.\nValeur par défaut : « false ».\n  Arrival Times Aimed­Arrival­Time 0:1 xsd:dateTime Heure d'arrivée théorique (ou commandée).   Expected­Arrival­Time 0:1 xsd:dateTime Heure d'arrivée estimée par le SAE.  Arrival Status Arrival­Status 0:1 onTime | early | delayed | cancelled | missed | arrived | notExpected | noReport Caractérisation de l'horaire d'arrivée attendu.\nValeur par défaut : « onTime ».\n   ArrivalProximity­Text 0:* NLString Texte libre à présenter quand le véhicule est proche, par exemple \"à l'approche\". Ce texte peut dépendre de règles propres à l'exploitant ou à l'AO, autant par son contenu que par les règles d'affichage qui le concernent (distance à partir de laquelle on l'affiche, etc.). Ces règles peuvent aussi être différentes suivant le lieu d'affichage de l'information (à quai, sur smartphone, dans un hall d'attente, etc.). Ces règles sont échangées en amont de façon contractuelle.   Arrival­Platform­Name 0:1 NLString Identification du quai d'arrivée.  Departure Aimed­Departure­Time 0:1 xsd:dateTime Heure de départ théorique (ou commandée).   Expected­Departure­Time 0:1 xsd:dateTime Heure de départ estimée par le SAE.  Departure Status Departure­Status 0:1 onTime | early | delayed | cancelled | arrived |departed | notExpected | noReport Caractérisation de l'horaire de départ attendu.\nValeur par défaut : « onTime ».\n   Departure­Platform­Name 0:1 NLString Identification du quai de départ.   Departure­Boarding­Activity 0:1 boarding | noBoarding | passthru Indique si l'on peut monter dans le véhicule ou si c'est un passage sans arrêt ou avec montée interdite.\nValeur par défaut : « boarding ».\n  Pro­gress Status Aimed­­Head­Way­Interval 0:1 Positive­DurationType Fréquence de passage théorique (ou commandée).   Expected­Headway­­Interval 0:1 Positive­DurationType Fréquence de passage estimée par le SAE.  Stop Proximity Group DistanceFrom­Stop 0:1 DistanceType Distance qui sépare le vehicule de l'arrêt. Une valeur positive indique que le véhicule est en amont de l'arrêt.   NumberOf­StopsAway 0:1 nonNegative­Integer Indique le nombre d'arrêts à marquer entre la position courante du vehicule et l'arrêt considéré.  any Extensions 0:1 +Structure Emplacement pour extension utilisateur (cf 5.4.2.2).    Annulation d\u0026rsquo;arrêts  MonitoredStopVisit­Cancellation +Structure Indication qu'un passage précédemment signalé ne doit plus être affiché (indique généralement que le véhicule a franchi l'arrêt).\nNote: A ne pas confondre avec une annulation de course.\n     Log Recorded­At­Time 1:1 xsd:dateTime Heure à laquelle l'annulation de passage a été signalée/publiée.  Event­Identity ItemRef 0:1\n1:1\n ItemIdentifier Identifiant de l'arrêt annulé (voir ItemRef plus haut).\nChamp obligatoire pour les échanges avec les concentrateurs (il doit être unique et pérenne, dans le cadre d'une journée d'exploitation, et bien permettre une annulation de passage à l'arrêt).\n   MonitoringRef 1:1 Monitoring­Code Identifiant du point d'arrêt.   LineRef 0:1 LineCode Identifiant de la ligne (celle de la course pour laquelle le passage à l'arrêt est annulé, la course elle-même peut être identifiée par le paramètre FramedVehicleJourneyRef ).   Vehicle­JourneyRef 0:1\n1:1\n +Structure (FramedVehicleJourneyRefStructure) Identification de la course concernée.\nChamp obligatoire pour les échanges avec les concentrateurs\n  Journey­Pattern­Info ::: 0:1 Journey­Pattern­Info­Group Voir Journey­Pattern­Info­Group.  Message Reason 0:1 NLString Message expliquant la cause de l'annulation.  any Extensions 0:1 +Structure Emplacement pour extension utilisateur (cf 5.4.2.2).    FramedVehicleJourneyRef  Framed­Vehicle­JourneyRef  0:1 +Structure Identification d'une course.   ➞ Data­Frame­Ref 1:1 DataFrame­Qualifier Contexte d'identification de la course (SAE pour le jour d'exploitation, version du référentiel de données, etc.).\nCe champ permet de qualifier la version de donnée de référence, si cela est applicable\nUtiliser la valeur \"any\" si ce champ n'est pas applicable.\n   ➞ DatedVehicleJourneyRef 1:1 Dated­Vehicle­Journey­Code Identifiant de la course elle-même.    VehicleJourneyInfoGroup    VehicleJourneyInfo­Group   Description de la course.     Service­Info ::: 0:1 Service­Info­Group Voir Service­Info­Group.  JourneyEndNames ::: 0:1 JourneyEndNamesGroup Voir JourneyEndNamesGroup.  JourneyInfo Vehicle­Journey­Name 0:1 NLString Nom de la course.   Journey­Note 0:1 NLString Texte complémentaire décrivant la course.  End Times Headway­Service 0:1 xsd:boolean La valeur « true » permet de signaler que la course est gérée en fréquence (interval), et que les informations horaires seront fournies en conséquence…\nValeur par défaut : « false ».\n   Origin­Aimed­Departure­Time 0:1 xsd:date­Time Heure théorique de départ de la course à son point de départ.   Destination­Aimed­Arrival­Time 0:1 xsd:date­Time Heure théorique d'arrivée de la course à son point d'arrivée.   FirstOrLastJourney 0:1 FirstOrLast­Journey­Enumeration Indique s'il s'agit de la première ou de la dernière course de la journée d'exploitation sur la ligne, et pour une destination donnée. L'interprétation comme \"première ou dernière course pour une mission donnée\" est acceptable, mais devra être précisée dans les spécifications d'interface du serveur (et le JourneyPatterInfoGroup devra alors être renseigné).\n(firstServiceOfDay | lastServiceOfDay | otherService | unspecified).\n    ServiceInfoGroup  Service Info OperatorRef 0:1 OperatorCode Identifiant de l'exploitant.   Product­Category­Ref 0:1 Product­Category­Code Mode de transport détaillé (voir l’énumération complète dans le XSD SIRI [R10]).   Service­Feature­Ref 0:* Service­Feature­Code Classification du type de service (“bus scolaire”, etc.).   Vehicle­Feature­Ref 0:* Vehicle­Feature­Code Service spécifique disponible dans le véhicule (plancher bas, etc.).\nDans le cadre du profil France deux valeurs sont ajoutées par rapport à la liste recommandée par la norme (voir SIRI 2 Partie 1 paragraphe 3.3.14.1) pour signaler les trains courts et les trains longs. Les codes retenus sont:\n  shortTrain : Train court\n  longTrain : Train long\n     JourneyEndNamesGroup  ServiceEnd Names OriginRef 0:1 Journey­PlaceCode Identifiant de l'arrêt de départ de la course.   Origin­Name 0:1 NLString Nom de l'arrêt de départ (si l'identifiant OriginRef est fourni, le nom doit l'être aussi).   Via 0:1 +Structure Description d'un via sur la course.\nLa cardinalité est limitée à 1 dans le cadre du profil. Ceci permet notament de simplifer la gestion de compatibilité avec les versions antérieures de SIRI\n   ➞ PlaceRef 0:1 Journey­PlaceCode Identifiant de l'arrêt via (ou d'un lieu via).   ➞ PlaceName 0:1 NLString Nom du via (si l'identifiant PlaceRef est fourni, le nom doit l'être aussi, si c'est un arrêt le nom doit naturellement être celui de l'arrêt   DestinationRef 1:1 Journey­PlaceCode Identifiant du dernier arrêt de la course.   Destination­Name 1:1 NLString Nom de l'arrêt de destination (si l'identifiant DestinationRef est fourni, le nom doit l'être aussi).    JourneyPatternInfoGroup | JourneyPatternInfoGroup | | | Groupe d\u0026rsquo;attributs pour la description des missions | |\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;- \u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;-|\u0026mdash;\u0026ndash;|\u0026mdash;\u0026ndash;|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;|\n Journey Pattern Info Journey­PatternRef 0:1 Journey­PatternCode Identifiant de la mission.   JourneyPatternName 0:1 NLString Nom ou numéro de course présenté au public.   Vehicle­Mode 0:1 air | bus | coach | ferry | metro | rail | tram | under­ground Mode de transport pour cette mission (il s’agit ici d’un mode « générique », tous les avions par exemple seront air, et c’est le ProductCategory, dans ServiceInfoGroup, qui donnera plus de précisions, comme : internationalFlight, intercontinentalFlight, domesticScheduledFlight, shuttleFlight …\nValeur par défaut : « bus ».\n   RouteRef 0:1 RouteCode Identifiant de l'itinéraire suivi.   Published­LineName 1:1 NLString Nom de la ligne.   Direction­Name 0:1 NLString Nom de la direction de la mission.\nCe nom peut par exemple contenir des informations comme \"A\" ou \"R\" (Aller ou Retour) pour les lignes qui utilisent ces informations.\n    DisruptionGroup Ce groupe de paramètres fait partie des éléments qui vont être étendus dans le cadre des services « Facility Monitoring » et « Situation Exchange ».\n   SM-14 Seule la référence à un événement sera retenue, les informations complémentaires pour l\u0026rsquo;état des équipements et les perturbations seront déterminées dans le cadre du service « Situation Exchange ».       Situation SituationRef 0:* SituationCode Identifiant (externe) de l\u0026rsquo;événement qui est la cause des modifications horaires indiquées.     JourneyProgressInfoGroup    JourneyProgressInfoGroup Groupe d\u0026rsquo;attributs précisant l’avancement sur la mission.     Status Monitored 0:1 xsd:boolean Indique si le véhicule est toujours localisé (la valeur false indique une délocalisation du bus).\nValeur par défaut : « true ».\n   Monitoring­Error 0:1 GPS | GPRS | Radio Si le bus est délocalisé, ce champ précise la cause de cette délocalisation.  Progress Data Quality In­Congestion 0:1 xsd:boolean Ce champ vaut « true » si le vehicule est pris dans un embouteillage (ou plus généralement un incident d’exploitation).\nValeur par défaut : « false ».\n   InPanic 0:1 xsd:boolean Indique que l'alarme du véhicule est activée.\nValeur par défaut : « false ».\n  Progress Data Vehicle­Location 0:1 Location­Structure Indique la position du véhicule (voir Location­Structure).\nCe champ est obligatoire quand cette structure fait partie d’une réponse à une requête de type « vehicle monitoring » (il reste facultatif dans les autres cas).\n   Bearing 0:1 Absolute­Bearing­Type Indique l’orientation (cap) du véhicule en dégré (0-360). Avec le Nord pour valuer 0 et l’est 90.\n\u0026lt;Bearing\u0026gt;180\u0026lt;/Bearing\u0026gt;\n   Occupancy 0:1 full | seatsAvailable | standingAvailable | unknown | empty | manySeatAvailable | fewSeatAvailable | standingRoomOnly | crushStandingRoomOnly | notAcceptingPassengers Indique le niveau de remplissage du véhicule.\nValeur par défaut : « unknown».\n   Delay 0:1 DurationType Indique le niveau de retard du véhicule (une valeur négative indique une avance).    Connection Monitoring Requête d’information sur les correspondances    Connection­Monitoring­Request +Structure Requête d’information sur les correspondances      Attributes version 1:1 VersionString Version du service “ Connection Monitoring”, intégrant le numéro de version de profil par exemple. ‘2.1:FR-FR-1.0’.    End­point Properties Request­Timestamp 1:1 xsd:dateTime Date d'émission de la requête.   Message­Identifier 0:1 Message­Qualifier   Topic PreviewInterval 0:1 Positive­Duration­Type Si ce paramètre est présent, il indique que l'on souhaite recevoir des informations sur toute arrivée et tout départ intervenant dans la durée indiquée.   ConnectionLink­Ref 1:1 → Connec­tion­Link­Code Identifiant de la correspondance interrogée (à déterminer entre les participants).\nPour mémoire, le « ConnectionLink » référence le cheminement physique, alors que l’objet « Interchange » référence une correspondance entre deux courses identifiées (généralement, un «Interchange » se réalise donc en empruntant un « ConnectionLink »). \n   choix –1:1  Seul l’un des filtres peut être utilisé.   a) Connecting­Time­Filter 0:1 +Structure Filtre temporel, indépendant des courses.   ➞ LineRef 1:1 → Line­Code    ➞ Direction Ref 1:1 → Direction­Code    b) Connecting­Journey­Filter 0:* +Structure Filtre basé sur les courses.  any Extensions 0:1 +Structure Emplacement pour extension utilisateur (cf 5.4.2.2).    Structure ConnectingTimeFilter    Filter Connecting­TimeFilter  +Structure Filtre temporel pour les requêtes.      ➞ LineRef 1:1 → LineCode Identifiant de la ligne amenante.    ➞ DirectionRef 1:1 → Direction­Code Indication de direction (aller/retour).    ➞ Earliest­ArrivalTime 1:1 xsd:dateTime Début de la fenêtre temporelle d’interrogation (basé sur l’heure d’arrivée).    ➞ Latest­ArrivalTime 1:1 xsd:dateTime Fin de la fenêtre temporelle d’interrogation (basé sur l’heure d’arrivée).     Structure ConnectingJourneyFilter    Filter Connecting­JourneyFilter  +Structure Filtre sur les courses.      ➞Dated­Vehicle­JourneyRef 1:1 → Dated­Vehicle­Journey­Code Identifiant de la course.    ➞ Aimed­Arrival­Time 0:1 xsd:dateTime Date et heure d’arrivée prévue au point d’arrêt (départ de correspondance).     Abonnement aux informations sur les correspondances    Connection­Monitoring­Subscription­Request +Structure Abonnement aux informations sur les correspondances.      Identity Subscriber­Ref 1:1 → Participant­Code Identification du système demandeur ( voir SIRI Partie 2 Common SubscriptionRequest parameters).     Subscription­Identifier 1:1 Subscription­Qualifier Identifiant de l'abonnement pour le système demandeur.  Lease Initial­Termination­Time 1:1 xsd:dateTIme Date et heure de fin de l'abonnement : un abonnement a forcément une date et heure de fin (les partenaires pourront décider de limiter la durée maximale d’un abonnement).  Request Connection­Monitoring­Request 1:1 +Structure Voir ConnectionMonitoringRequest.  Policy Change­Before­Updates 0:1 Positive­DurationType Permet d'indiquer un écart de temps en dessous duquel on ne souhaite pas être notifié (si l'on demande un seuil de 5mn et qu'un horaire de départ change de 2 minutes, il n’y aura pas de notification, évitant ainsi des flux d'information inutiles).\nSi ce champ n'est pas présent, une valeur de 5 minutesn est prise par défaut.\nC’est une valeur « par défaut », qui est volontairement haute pour ne pas surcharger les échanges : dans le cas nominal, elle devra être précisée avec une valeur plus faible (mais tous les systèmes ne fonctionnent pas à la minute, surtout côté client).\n  any Extensions 0:1 +Structure Emplacement pour extension utilisateur (cf 5.4.2.2).    Réponse aux requêts d’information sur les correspondances    ServiceDelivery +Structure Réponse aux requêtes d’information sur les correspondances.        HEADER ::: 1:1 See ServiceDelivery      Payload ConnectionMonitoring­FeederDelivery 1:* +Structure voir ConnectionMonitoring­Feeder­Delivery.    ConnectionMonitoring­DistributorDelivery 1:* +Structure voir ConnectionMonitoringDistributor­Delivery.     Connection MonitoringFeeder Delivery    Connection­MonitoringFeeder­Delivery +Structure Réponse aux requêtes d’information sur les correspondances : description des alimentants.      Attributes version 1:1 VersionString Numéro de version du service Connection Monitoring, intégrant le numéro de version de profil (voir 5.9) (valeur fixe).    LEADER ::: 1:1 xxx­Delivery voir xxxDelivery.  Payload Monitored­Feeder­Arrival 0:* +Structure Changement d’heure d’arrivée à la correspondance.\nVoir MonitoredFeederArrival.\n   Monitored­Feeder­Arrival­Cancellation 0:* +Structure Annulation de passage à la correspondance.\nVoir MonitoredFeederArrival.\n  Any Extensions 0:1 +Structure Emplacement pour extension utilisateur (cf 5.4.2.2).    Structure MonitoredFeederArrival    MonitoredFeederArrival +Structure Information sur l’amenant.      Log Recorded­AtTime 1:1 xsd:dateTime Date et heure à laquelles ces données ont été produites.    Identity Item­Identifier 0:1 ItemIdentifier Référence le message d’information.  Feeder Inter­change Identity Interchange­Ref 0:1 → Interchange­Code Identifiant de la correspondance entre course.\nDans le cadre du profil France, si ce paramètre est présent, il sera constitué de la concaténation de l’identifiant de la course arrivant et de celui de la course au départ (séparés par le caractère ‘:’).\n   Connection­Link­Ref 1:1 → Connection­Link­Code Identifiant de la correspondance physique.   Stop­Point­Ref 0:1 → StopPoint­Code Identifiant du point d’arrêt de l’amenant (généralement porté par le ConnectionLink)..\nIl convient d'utiliser ici un identifiant d'objet de référence : zone d'embarquement ou lieu d’arrêt multi ou monomal : granularité la plus fine possible dans tous les cas.\n   Order 0:1 xsd:positive­Integer Numéro d'ordre de l'arrêt dans la mission.   Stop­Point­Name 0:1 NLString Nom du point d'arrêt.   Clear­Down­Ref 0:1 → Cleardown­Code Cleardown : indicateur « véhicule à l’arrêt » ou « à l’approche ».  Journey Info Feeder­Journey 1:1 Connecting­Journey­Structure Description de la course de l’amenant.  Real-time call VehicleAt­Stop 0:1 xsd:boolean Indicateur “Véhicule à l’arrêt”.\nValeur par défaut : « false»\n  Call time AimedArrivalTime 0:1 xsd:dateTime Heure d'arrivée planifiée.   Expected­Arrival­Time 1:1 xsd:dateTime Heure d’arrivée prévue à l’arrêt.   ArrivalPlatformName 0:1 NLString Nom du quai d'arrivée.  any Extensions 0:1 any Emplacement pour extension utilisateur (cf 5.4.2.2).    Structure FeederJourney    FeederJourney +Structure Description de la course de l’amenant.        VehicleJourney­Identity LineRef 1:1 → LineCode Identifiant de la ligne.      DirectionRef 1:1 → Direction­Code Indication de direction (aller/retour).    Framed­Vehicle­JourneyRef 0:1 +Structure Identification de la course.   JourneyPattern­Info ::: 0:1 Journey­Pattern­Info­Group Voir Journey­Pattern­Info­Group.   VehicleJourney­Info ::: 0:1 Vehicle­JourneyInfo­Group Voir Vehicle­JourneyInfo­Group.   DisruptionGroup ::: 0:1 Disruption­Group Voir DisruptionInfo­Group.   Progress Monitored 0:1 xsd:boolean Signale si l’information temps réel est disponible (oui par défaut).   Call Times Aimed­Arrival­Time 0:1 xsd:dateTime Heure d’arrivée prévue à l’arrêt.   any Extensions 0:1 any Emplacement pour extension utilisateur (cf 5.4.2.2).     Structure MonitoredFeederArrivalCancellation    MonitoredFeederArrival­Cancellation +Structure Information d’annulation de course.      Log Recorded­AtTime 1:1 xsd:dateTime Date et heure auxquelles ces données ont été produites/enregistrées.    Identity ItemRef 0:1 ItemIdentifier Identifie l’objet qui est annulé (voir le ItemRef correspondant dans les précédentes notifications d’information de correspondance).  Feeder\nInter­change\nIdentity Interchange­Ref 0:1 → Interchange­Code Identifiant de la correspondance entre courses.\nDans le cadre du profil France, si ce paramètre est présent, il sera constitué de la concaténation de l’identifiant de la course arrivant et de celui de la course au départ (séparés par le caractère ‘:’).\n   ConnectionLink­Ref 1:1 → Connection­Link­Code Identifiant de la correspondance physique.   StopPoint­Ref 0:1 → StopPoint­Code Identifiant du point d’arrêt de l’amenant (généralement porté par le ConnectionLink).\nIl convient d'utiliser ici un identifiant d'objet de référence :zone d'embarquement ou lieu d’arrêt multi ou monomal: granularité la plus fine possible dans tous les cas.\n   Order 0:1 xsd:positive­Integer Numéro d'ordre de l'arrêt dans la mission.   Stop­Point~Name 0:1 NLString Nom du point d'arrêt.  Journey Info LineRef 1:1 → LineCode Identifiant de la ligne.   DirectionRef 1:1 → Destination­Code Identifiant de la direction (aller/retour).   Vehicle­JourneyRef 1:1 +Framed­Vehicle­JourneyRef­Structure Identification de la course.   JourneyPatternRef 0:1 → Journey­PatternCode Identifiant de la mission.   JourneyPatternName 0:1 NLString Nom ou numero de course présenté au public.   VehicleMode 0:1 air | bus | coach | ferry | metro | rail | tram | underground Mode de transport pour cette mission (il s’agit ici d’un mode « générique », tous les avions par exemple seront air, et c’est le ProductCategory, dans ServiceInfoGroup, qui donnera plus de précisions, comme : internationalFlight, intercontinentalFlight, domesticScheduledFlight, shuttleFlight …\nValeur par défaut : « bus »\n   RouteRef 0:1 → RouteCode Identifiant de l'itinéraire suivi.   Published­LineName 0:1 NLString Nom commercial de la ligne.   GroupOfLinesRef 0:1 → GroupOfLinesCode Identifiant du Goupe de Lignes (réseau ou tout autre groupe de ligne auquel la course est rattachée).   DirectionName 0:1 NLString Nom de la destination.\nCe nom peut par exemple contenir des informations comme \"A\" ou \"R\" (Aller ou Retour) pour les lignes qui utilisent ces informations.\n  Info Reason 0:1 NLString Cause de l’annulation.  any Extensions 0:1 any Emplacement pour extension utilisateur (cf 5.4.2.2).    Structure ConnectionMonitoringDistributorDelivery    ConnectionMonitoringDistributor­Delivery +Structure Information concernant le “partant”.        Attributes version 1:1 VersionString Version du service intégrant le numéro de version de profil (voir 5.9) par exemple. ‘2.1:FR-IDF-2.4’.     LEADER ::: 1:1 xxx­Delivery Voir SIRI Partie 2-7.2.1.1 xxxDelivery.   Payload WaitProlonged­Departure 0:* +Structure Description d’une prolongation d’attente*.*    Stopping­Position­Changed­Departure 0:* +Structure Déplacement du point de départ (et donc du trajet de correspondance).    Distributor­Departure­Cancellation 0:* +Structure Annulation de départ.   any Extensions 0:1 +Structure Emplacement pour extension utilisateur (cf 5.4.2.2).     Structure WaitProlongedDeparture    WaitProlongedDeparture +Structure Description d’une prologation d’arrêt pour attente de l’amenant        Log Recorded­AtTime 1:1 xsd:dateTime Date et heure auxquelles ces données ont été produites.     DistributorInfo ::: 1:1 Distributor­Info­Group Voir DistributorInfoGroup (6.3.3.2.4).   Change Expected­Departure­Time 1:1 xsd:dateTime Nouvelle heure de départ prévue.   any Extensions 0:1 any Emplacement pour extension utilisateur (cf 5.4.2.2).     Structure StoppingPositionChangedDeparture    StoppingPosition­ChangedDeparture +Structure Description d’un déplacement (temporaire) de point d’arrêt.        Log Recorded­AtTime 1:1 xsd:dateTime Date et heure auxquelles ces données ont été produites.     Distributor­Info ::: 1:1 Distributor­Info­Group Voir DistributorInfoGroup (6.3.3.2.4).   Change ChangeNote 1:1 NLString Description de la nouvelle position (textuelle).    NewLocation 0:1 → Location Nouvelle position de l’arrêt.     Structure Location    LocationStructure 0:1 +Structure Geospatial Location.      Attributes id 0:1 xsd:NMTOKEN Identifiant du point (pour un éventuel lien avec une base Géospatiale ou un SIG).  srsName 0:1 xsd:string Idenfitiant du référentiel de projection (conforme EPSG, définit par l’OGC, et tel qu’utilisé par GML).    Coordinates choix –1:1  La localisation peut être fournie soit en WGS 84 soit dans un référentiel projeté (Lambert 2 étendu, par exemple).\nCes deux possibilités sont conservées dans le profil SIRI France.\n   a) Lat/long 0:1  Si choix Lat/long permet de renseigner les données.   i) Longitude 0:1 Longitude­Type Longitude à partir du meridien de Greenwich : de.180° (Est) à +180° (Ouest). Degrés décimaux.   ii) Latitude 0:1 Latitude­Type Latitude à partir de l’équateur. de -90° (Sud) à +90° (Nord) en degrés décimaux.   b) Coordi­nates 0:1 xsd:string Coordonnées au format GML en cohérence avec l’attribut srsName.   Precision 0:1 Distance Précision du positionnement (en mètres).    Structure DistributorDepartureCancellation    DistributorDeparture­­Cancellation   +Structure Indication d’annulation de depart.     Log Recorded­AtTime 1:1 xsd:dateTime Date et heure auxquelles ces données ont été produites.   DistributorInfo ::: 1:1 Distributor­Info­Group Voir DistributorInfoGroup(6.3.3.2.4).   Call time Reason 1:1 NLString Raison de l’annulation.   any Extension 0:1 any Emplacement pour extension utilisateur (cf 5.4.2.2).     Structure DistributorInfoGroup  Distributor Inter­change_ Identity Interchange­Ref 0:1 → InterchangeCode Identifiant de la correspondance entre courses.\nDans le cadre du profil France, si ce paramètre est présent, il sera constitué de la concaténation de l’identifiant de la course arrivant et de celui de la course au départ (séparés par le caractère ‘:’).\n     Connection­Link­Ref 1:1 → Connection­Link­Code Identifiant de la correspondance physique.   StopPoint­Ref 0:1 → StopPoint­Code Identifiant du point d’arrêt du partant (généralement porté par le ConnectionLink).\nIl convient d'utiliser ici un identifiant d'objet de référence zone d'embarquement ou lieu d’arrêt multi ou monomal: granularité la plus fine possible dans tous les cas.\n   Distributor­Order 0:1 xsd:positive­Integer Numéro d'ordre de l'arrêt dans la mission.  Journey Info Distributor­Journey 1:1 Connecting­Journey­Structure Description de la course du véhicule au départ.  Feeder Info Feeder­Vehicle­JourneyRef 0:* Framed­Vehicle­Journey­Ref­Structure Information sur la course de l’amenant (identifiant de la ou des courses).    Structure ConnectingJourney  ConnectingJourney Connecting­JourneyStructure Correspondance planifiée : description des courses impliquées : alimentant (“feeder”) ou partant (« distributor”) suivant les cas.    Vehicle­Journey­Identity LineRef 0:1 → LineCode Identifiant de la ligne.   Framed­Vehicle­JourneyRef 0:1 +Structure Identifiant de la course.  Journey­PatternInfo ::: 0:1 JourneyPattern­InfoGroup Voir Journey­Pattern­Info­Group.  Vehicle­Journey­Info ::: 0:1 VehicleJourney­InfoGroup Voir Vehicle­JourneyInfo­Group.  Disruption­Group ::: 0:1 DisruptionGroup Voir Disruption­Group.  Progress Monitored 0:1 xsd:boolean Signale si les données temps réel sont disponibles pour cette course (« false » permet de signaler une délocalisation).\nValeur par défaut : « true».\n   Aimed­Arrival­Time 0:1 xsd:dateTime Heure d’arrivée prévue à la correspondance.  any Extensions 0:1 any Emplacement pour extension utilisateur (cf 5.4.2.2).    Vehicle Monitoring Note: l\u0026rsquo;utilisation des MonitoredCall, OnwardCall et PreviousCall est précisée en 5.7.\nRequête d’information sur les véhicules    VehicleMonitoringRequest +Structure Requête d’information sur les véhicules        Attrib­utes version 1:1 VersionString Version du service “Vehicle Monitoring”, intégrant le numéro de version de profil par exemple. ‘2.1:FR-1.0’.     End­point Properties Request­Timestamp 1:1 xsd:dateTime Date d\u0026rsquo;émission de la requête.    Message­Identifier 0:1 Message­Qualifier Numéro d\u0026rsquo;identification du message.   Topic choix -1:1      a) Vehicle­Ref 0:1 → VehicleCode Identifiant du véhicule.    b) LineRef 0:1 → LineCode Identifiant de la ligne (tous les véhicules de la ligne seront remontés).   any Extensions 0:1 +Structure Emplacement pour extension utilisateur (cf 5.4.2.2)     Abonnement aux informations sur les véhicules    VehicleMonitoring­SubscriptionRequest +Structure Abonnement aux informations sur les véhicules.      Identity SubscriberRef 0:1 → Participant­Code Identification du système demandeur ( voir SIRI Part 2 Common SubscriptionRequest parameters.).     Subscription­Identifier 1:1 Subscription­Qualifier Identifiant de l'abonnement pour le système demandeur.  Lease Initial­Termination­Time 1:1 xsd:dateTIme Date et heure de fin de l'abonnement : un abonnement a forcément une date et heure de fin (les partenaires pourront décider de limiter la durée maximale d’un abonnement).  Request Vehicle­Monitoring­Request 1:1 +Structure Voir VehicleMonitoringRequest.  Policy Incremental­Updates 0:1 xsd:boolean Indique s’il faut notifier uniquement les changements d'information, ou s’il faut systématiquement renvoyer toutes les informations si l'une d'elles change.\nVoir la documentation SIRI: IncrementalUpdates.\n   choix -1:1  Choix   a) Change­Before­Updates 0:1 Positive­DurationType Permet d'indiquer un écart de temps en dessous duquel on ne souhaite pas être notifié (si l'on demande un seuil de 5 minutes et qu'un horaire de départ change de 2 minutes, on ne sera pas notifié, évitant ainsi des flux d'information inutiles).   b) Update­Interval 0:1 Positive­DurationType Permet d’obtenir les positions (ou mise à jour des positions) à intervalle régulier et prédéterminé.    Réponse aux requêtes d’information sur les véhicules    VehicleMonitoringDelivery +Structure Réponse aux requêtes d’information sur les véhicules.        Attributes version 1:1 VersionString Numéro de version du service Vehicle Monitoring, intégrant le numéro de version de profil (voir 5.9) (valeur fixe).     LEADER ::: 1:1 xxx­Delivery Voir xxxDelivery.   Payload VehicleActivity 0:* +Structure Fournit les informations concernant le véhicule.    VehicleActivity­Cancellation 0:* +Structure Signale l’annulation du service du véhicule.   any Extensions 0:1 +Structure Emplacement pour extension utilisateur (cf 5.4.2.2).     Structure VehicleActivity    VehicleActivity +Structure Informations sur le véhicule.      Log Recorded­At­Time 1:1 xsd:dateTime Heure à laquelle la position du véhicule a été mise à jour.    Currency Valid­Until­Time 1:1 xsd:dateTime Heure jusqu'à laquelle l'information est réputée valide.\nCette information obligatoire dans l'XSD SIRI n'est pas considerée indispensable par le profil. Par convention on la remplira avec la même valeur que Recorded­At­Time pour signifier que l'information n'est pas à prendre en compte (on ne peut en efffet pas laisser le champ vide).\n  Identity Item­Identifier 0:1 ItemIdentifier Identifiant, qui permettra par la suite une annulation (par exemple, particulièrement utile si l’on ne dispose pas d’identifant de véhicule).   Vehicle­Monitoring­Ref 0:1 Vehicle­Monitoring­Identifier Identifiant du véhicule.  StopProgressInfo Progress­Between­Stops 0:1 Location­Structure Position du véhicule entre l’arrêt précédent et l’arrêt suivant.   ➞ Link­Distance 0:1 xsd:decimal Distance totale entre les deux arrêts (distance réelle sur le réseau routier).   ➞ Percentage 0.1 xsd:decimal Pourcentage de cette distance déjà couverte par le véhicule.  Journey­Info Monitored­Vehicle­Journey 1:1 Monitored­Vehicle­Journey Structure Décrit la course effectuée par le véhicule 6.2.5.1.1.1.\nC’est au sein de cette structure que l’on trouvera la position du véhicule (vehicleLocation).Voir paragraphe 6.2.5.1.1.1.\n  Message Vehicle­Activity­Note 0:* NLString Information textuelle concernant le véhicule et son état courant (positionnement, etc.).  any Extensions 0:1 any Emplacement pour extension utilisateur (cf 5.4.2.2).    Structure VehicleActivityCancellation    VehicleActivityCancellation +Structure Annulation de l’affectation d’un véhicule à une course.        End­point Recorded­AtTime 1:1 xsd:dateTime Heure à laquelle l\u0026rsquo;annulation a été signalée/publiée.     Event­Identity ItemRef 0:1 ItemIdentifier Identifiant de l’objet annulé (voir ItemRef plus haut).    Vehicle­Monitoring­Ref 0:1 → Vehicle­Monitoring­Code Identifiant du véhicule.    Framed­Vehicle­Journey­Ref 0:1 +Structure Description de la course annulée.    LineRef 0:1 → LineCode Identifiant de la ligne.   Journey­Pattern­Info ::: 0:1 JourneyPattern­InfoGroup Voir SIRI Partie 2 JourneyPatternInfoGroup.   Message Reason 0:* NLString Description textuelle de la cause de l’annulation.   any Extensions 0:1 Any Emplacement pour extension utilisateur (cf 5.4.2.2).     General Message Les lignes qui suivent présentent l’implémentation du service SIRI General Message dans le cadre du profil France.\nCe service est particulier, car la norme SIRI ne détaille pas la structure du message lui-même : ce qui est précisé par la norme SIRI sont les modalités de requête et de réponse pour accéder aux messages, ainsi que quelques informations de base comme les canaux de message (Info Channel).\nLe message lui-même, présenté ci-dessous sous forme de schéma XSD, est donc complètement spécifique au profil France : il est en effet indispensable de le définir précisément pour assurer la compatibilité des différents systèmes.\nLes messages peuvent être rattachés à n’importe quel objet du réseau (ligne, mission, itinéraire, section de ligne et bien sur arrêt). SIRI ne prévoit toutefois pas la possibilité de rattacher un tel message au service Stop Monitoring (pour avoir les deux informations en une seule requête), ce qui se justifie facilement par le fait que, comme cela vient d’être indiqué, le message n’est pas forcément rattaché à un arrêt.\nEnfin, il faut rappeler que ce service n’est pas le service de gestion de perturbation : il était conçu pour pouvoir diffuser les informations non structurées de perturbation, dans un premier temps, en attendant la définition finale du service SIRI Situation Exchange et surtout en attendant que les alimentants soient en mesure de diffuser des informations structurées et non simplement textuelles.\nDans un second temps, l’usage du service General Message se restreint donc aux messages généraux de type communication (i.e.: Pensez à acheter votre coupon mensuel, modification de politique tarifaire ; etc.) ou information ne concernant pas les réseaux (i.e.: match, concert, etc.).\nMatrice de capacité Cette matrice n\u0026rsquo;est pas échangée dans le cadre du profil France: elle présente les principales fonctions retenues pour le service (les explications ne sont pas traduites dans ce tableau, mais on retrouve les traductions dans les tableaux qui suivent).\n Topic TopicFiltering    ➞ DefaultPreview­Interval Non.   ➞ FilterByInfo­Channel Oui.  Request Policy RequestPolicy   ➞ Language Non.\n(si le message est disponible en plusieurs langues, toutes les langues sont systèmatiquement diffusées)\n  Access Control AccessControl   ➞ Request­Checking Non.  ➞ CheckInfo­Channel Oui.  any Extensions Non.    Requête au service « General Message »    GeneralMessageRequest +Structure Requête d\u0026rsquo;accès aux messages.     Attributes version 1:1 VersionString Version du service « General Message », intégrant le numéro de version de profil (voir 4.2.9) (valeur fixe).  Endpoint Properties Request­Timestamp 1:1 xsd:dateTime Date d'émission de la requête (voir SIRI Partie 2 Common properties of SIRI Functional Service Requests).   Message­Identifier 1:1 Message­Qualifier Numéro d'identification du message.  Topic Info­Channel­Ref 0:* InfoChannel­Code Identifie le canal pour lequel on souhaite obtenir les messages. Si ce champ n'est pas présent, la requête concerne tous les canaux.\nDans le cadre du profil FR, seules les valeurs suivantes seront utilisées pour identifier les canaux:\n  «Perturbation»,\n  «Information»,\n  «Commercial».\n  Note: ce sont bien ces libellés texte précis, qui sont utilisés pour instancier l'attribut InfoChannelRef (et non une codification équivalente).\nLes travaux prévus et non prévus sont transmis en messages de type « Perturbation ». Si le service SX est présent, seuls les canaux « Information » et « Commencial »sont valides. Les messages de type « perturbation » sont véhiculés par le service SX (cf § 6.7.1).\n  Request Policy Language 0:1 xml:lang Langue dans laquelle le message est demandé.\nDans le cadre du profil FR, seul le français est obligatoire, mais un système pourra optionnellement proposer d'autres langues.\n  any Extensions 0:1 +Structure Emplacement pour extension utilisateur (cf 5.4.2.2).    Requête d\u0026rsquo;abonnement au service « General Message »    GeneralMessage­SubscriptionRequest +Structure Requête d’abonnement au service SIRI GeneralMessage.                 Identity SubscriberRef 1:1 Participant­Code Identifiant du système demandeur (voir SIRI Partie 2 Common SubscriptionRequest parameter.    Subscription­Identifier 1:1 Subscription­Qualifier Identifiant (externe) du canal d\u0026rsquo;abonnement.   Lease Initial­Termination­Time 1:1 xsd:dateTIme Date et heure prévues pour la fin de l\u0026rsquo;abonnement.   Request General­Message­Request 1:1 +Structure Voir GeneralMessageRequest.    Réponse du service « General Message » (structure générale)    ServiceDelivery +Structure See SIRI Part 2-7.2.1 ServiceDelivery.                HEADER :: 1:1 See ServiceDelivery En-tête générique des réponses.   Payload General­Message­Delivery 1:* +Structure Voir GeneralMessageDelivery.    Réponse du service « General Message » (structure détaillée)    GeneralMessageDelivery +Structure Contenu et modification des messages.                Attributes version 1:1 Version­String Version du service, intégrant le numéro de version de profil (voir 5.9) (valeur fixe).   LEADER ::: 1:1 xxx­Delivery En-tête (voir paragraphe 2.2*.).*   Payload Info­Message 0:* +Structure Le message lui-même (voir InfoMessage ci dessous).    Info­Message­Cancellation 0:* +Structure Structure d\u0026rsquo;annulation d\u0026rsquo;un message précédent (voir ci dessous).    Note: GeneralMessageDelivery doit contenir au moins un InfoMessage ou un InfoMessage­Cancellation (il peut bien sur en contenir plusieurs de chaque).\nDescription du « General Message »    InfoMessage +Structure Message d\u0026rsquo;information.     attribute format­Ref 1:1 FormatCode Identifie le format du contenu (ouvert pour ce service).\nDans le cadre du profil FR, ce champ sera toujours présent et aura une valeur fixe « France » et correspond au transport de la structure spécifique de message décrite plus bas.\n  log RecordedAtTime 1:1 xsd:dateTime Heure d'enregistrement du message.  Identity ItemIdentifier 1:1 ItemIdentifier Identifiant unique du message SIRI, fourni par son émetteur (deux réceptions différentes ne peuvent avoir le même identifiant).\nIl doit être unique et pérenne et bien identifier le message.\n  Identity InfoMessage­Identifier 1:1 Identifier Identifiant InfoMessage (sera utilisé pour les mises à jour et les abandons de message: toutes les mises à jour du message porteront le même InfoMessage­Identifier).   InfoMessage­Version 0:1 xsd:positive­Integer Version du InfoMessage.(considéré comme valant 1 si le champ n'est pas présent).   InfoChannelRef 1:1 InfoChannel Canal auquel appartient le message.\nDans le cadre du profil FR, seules les valeurs suivantes seront utilisées pour identifier les canaux :\n « Perturbation »1,\n « Information »,\n « Commercial ».\n  Note: ce sont bien ces libellés texte précis, qui sont utilisés pour instancier l'attribut InfoChannelRef (et non une codification équivalente).\nLes travaux prévus et non prévus sont transmis en messages de type « Perturbation ».\n  Currency ValidUntilTime 1:1 xsd:dateTime Date et heure jusqu'à laquelle le message est valide.\nSi toutefois l'heure de fin d'incident n'est pas connue, cette heure sera fixée en fin de journée d'exploitation (ou une heure fixe de fin de journée).\nCette heure pourra naturellement être modifiée par une mise à jour ultérieure (pour le même Info­Message­Identifier).\nL'annulation du message est implicite lorsque que l'on atteint cette heure, mais peut aussi être anticipée en utilisant une InfoMessageCancellation (recommandé en mode abonnement).\n  Situation Situation­Ref 0:* SituationCode Référence à un événement externe auquel est rattaché le message.  Message Content 1:1 anyType Le message lui-même (voir ci-dessous)\nNote: il convient de bien noter que le type utilisé ici par SIRI est \"anyType\" (et non \"any\"). Ceci a pour conséquence l'obligation d'encoder (en attribut) le type de la structure utilisé dans pour décrire le message, en l'occurrence sous la forme :\n\u0026lt;Content xsi:type=\"siri: FRGeneralMessageStructure\"\u0026gt;\ndans le cadre du profil France.\n  any Extensions 0:1 Any Emplacement pour extension utilisateur (cf 5.4.2.2).     Cette valeur ne doit être utilisée qu’en l’absence du service SIRI SX (cf 6.7).↩︎\n   Annulation d\u0026rsquo;un « General Message »    InfoMessageCancellation +Structure Annulation d\u0026rsquo;un message émis précédemment.     log Recorded­At­Time 1:1 xsd:dateTime Heure à laquelle le message a été annulé.  Identity ItemRef 1:1 ItemIdentifier Identifiant unique du message SIRI (deux réceptions différentes ne peuvent avoir le même identifiant). Sa valeur doit naturellement être unique et pérenne pour un message.  Identity Info­Message­Identifier 1:1 Identifier Référence InfoMessage du message à annuler.   Info­Channel­Ref 0:1 Info­ChannelCode Canal auquel appartient le message.\nDans le cadre du profil IDF, seules les valeurs suivantes seront utilisées pour identifier les canaux:\n « Perturbation »,\n « Information »,\n « Commercial ».\n  Note: ce sont bien ces libellés texte précis qui sont utilisés pour instancier l'attribut InfoChannelRef (et non une codification équivalente).\nLes travaux prévus et non prévus sont transmis en messages de type « Perturbation ».\n  any Extensions 0:1 Any Emplacement pour extension utilisateur (cf 5.4.2.2).    Structure spécifique des requêtes « General Message » pour le profil FR Cette structure spécifique constitue le mécanisme de filtrage du service « General Message » et s\u0026rsquo;insère au sein de l\u0026rsquo;élément extension de la requête.\n GM-1 Les champs de la structure sont les suivants:\n Le champ «LineRef» permet de n'obtenir que les messages relatifs à la ligne indiquée ;\n Le champ «StopPointRef» permet de n'obtenir que les messages relatifs à l'arrêt indiqué (Il convient d'utiliser ici un identifiant d'objet de référence de zone d'embarquement ou lieu d’arrêt multimodal/monomodal: granularité la plus fine possible dans tous les cas) ;\n Le champ «JourneyPatternRef» permet de n'obtenir que les messages relatifs à la mission commerciale indiquée ;\n Le champ «DestinationRef» permet de n'obtenir que les messages relatifs à la destination indiquée ;\n Le champ «RouteRef» permet de n'obtenir que les messages relatifs à l'itinéraire indiqué ;\n Le champ «GroupOfLinesRef» permet de n'obtenir que les messages relatifs au groupe de lignes indiqué (réseau ou tout groupe de lignes dont le code a été préalablement échangé comme donnée de référence : Noctilien, lignes attachées à un dépôt, etc.)\n     GM-2 Les champs de filtres sont insérés au sein d'une structure \"choice\" et ne peuvent donc être utilisés simultanément.    Structure spécifique des messages pour le profil FR Cette structure correspond au champ Content de la structure Infomessage.\nCette structure est définie de façon spécifique pour le profil FR car la norme SIRI n\u0026rsquo;impose pas de structure de message (et n\u0026rsquo;en propose pas non plus) : il revient donc à chaque profil de décrire ces messages.\n GM-3 Les champs de la structure sont les suivants :\n  Le champ «LineRef» identifie la ou les lignes concernées par le message.\n  Si une ligne est indiquée, le message porte sur toute la ligne sans restriction.\nLes choix de comportement pour générer la liste des messages concernant la ligne (messages spécifiques à la ligne, messages concernant tous les arrêts desservis par la ligne, etc.) restent à l'appréciation du producteur et seront précisés par les spécifications.\n  Le champ «StopPointRef» identifie le ou les points d'arrêt (cf 2.2) concernés par le message.\n  Il convient d'utiliser ici un identifiant d'objet de référence . Zone dembarquement, Lieu d’arrêt monomodal, Lieu d’arrêt multimodal.\nLes choix de comportement pour générer la liste des messages concernant l’arrêt (messages spécifiques à l’arrêt, messages concernant toutes les lignes de l’opérateur desservant l’arrêt, etc.) restent à l'appréciation du producteur et seront précisés par les spécifications.\n  Le champ «JourneyPatternRef» identifie la ou les missions concernées par le message.\n  Si une mission est indiquée, le message porte sur toute la mission sans restriction.\n  Le champ «DestinationRef» identifie la ou les destinations concernées par le message\n  Si une destination est indiquée, le message porte sur toutes les courses ayant cette destination sans restriction.\n  Le champ «RouteRef» identifie le ou les itinéraires concernés par le message.\n  Si un itinéraire est indiqué, le message porte sur tout l'itinéraire sans restriction.\n  Le champ «GroupOfLinesRef» permet d'indiquer que le message est relatifs au groupe de lignes indiqué (réseau ou tout groupe de lignes dont le code a été préalablement échangé comme donnée de référence : Noctilien, lignes attachées à un dépôt, etc.). Toutes les lignes du groupe de lignes sont alors concernées par le message.\n  Le champ «LineSection» identifie la ou les sections de lignes (premier et dernier arrêt ainsi que leur ligne d'appartenance) concernée(s) par le message.\n  Si une section de ligne est indiquée, le message porte sur tous les arrêts de cette section, sans restriction.\nNote: pour être exact il vaudrait mieux parler de section d’itinéraires, mais beaucoup de systèmes ne disposant pas de la notion d’itinéraires, le choix a été de faire porter la section sur la ligne.\n  Le champ « Message » contient le message lui-même :\n  « NumberOfLines » est une information facultative de formatage précisant le nombre de lignes du message ;\n  « NumberOfCharPerLine » est une information facultative de formatage précisant le nombre maximum de caractères par ligne d’affichage dans le message ;\n  « MessageType » permet de donner un type au contenu du message. Les valeurs possibles pour ce type sont :\n  shortMessage : message texte court, par opposition au longMessage ; l'utilisation de ce code suppose que l'on disposera aussi d'une version longue du même message.\n  longMessage : message texte long, par opposition au shortMessage ; l'utilisation de ce code suppose que l'on disposera aussi d'une version courte du même message.\n  textOnly : texte libre sans restriction ni formatage particulier, mais n'utilisant que des caractères textes imprimables sans saut de ligne. Le profil établit depuis sa vesion 2.3 que la fourniture du message sous cette version est obligatoire. Un messageText est évidemment obligatoire quand MessageType est positionné à textOnly.\n  formattedText : texte formaté en nombre de lignes et de caractères (voir les champs précédents). Dans ce cas le retour chariot est \u0026lt;LF\u0026gt; seul (code ascii 10 en décimal) ;\n  HTML : format compatible HTML 4 ;\n  RTF : Rich Text Format ;\n  codedMessage : Ce type permettra par exemple de définir une bibliothèque de messages de n’en communiquer que le type (en laissant alors vide le champ texte).\n  Si une telle bibliothèque est utilisée, elle devra être définie dans le protocole d’accord établi entre les différents intervenants dans l’échange..\n « MessageText » est une chaîne de caractères contenant un libellé de message (la langue du message peut être précisée et plusieurs « Message » peuvent être diffusés en une seule fois ce qui permet de diffuser un message en plusieurs langues ou sous plusieurs formes).\n  Chaque producteur fournit une information sans mise en page (sans retour chariot) : la charge de la mise en page revient aux diffuseurs en fonction de ses capacités d’affichage.\n      Note: Un GeneralMessage peut contenir plusieurs messages (voir la cardinalité sur la figure ci-dessus) formatés différemment ; charge au diffuseur de prendre le format le plus adapté à son usage et ses contraintes.\nLa fin de validitié d\u0026rsquo;un message, en particulier d\u0026rsquo;une perturbation, est gérée de la façon suivante :\n   GM-4 En mode requête, le diffuseur doit considérer une information reçue précédemment comme obsolète quand la réponse qu\u0026rsquo;il reçoit est vide (ou tout du moins quand elle ne retourne plus l\u0026rsquo;information précédemment reçue) ou quand l’heure de fin d’évènement est expirée (champ Valid­Until­Time) ; le producteur n’envoie en effet que les messages actifs au moment de la requête.     GM-5 En mode abonnement, le diffuseur doit considérer une information reçue précédemment comme obsolète quand il reçoit une information de type \u0026ldquo;InfoMessageCancellation\u0026rdquo; ou quand l’heure de fin d’évènement est expirée (champ Valid­Until­Time).     Précision sur l\u0026rsquo;encodage de la structure spécifique France et exemple de message Contrairement aux champs d\u0026rsquo;extension de SIRI, le type utilisé pour décrire le contenu du message de General Message est \u0026ldquo;anyType\u0026rdquo; (et non \u0026ldquo;any\u0026quot;). Ce choix correspond à une volonté de contraindre à partager, entre les acteurs impliqués dans l’échange, une structure pour ce contenu qui correspond au coeur du message, plutôt que de laisser les acteurs le remplir à leur guise (ce qui est en final une contrainte de base d\u0026rsquo;interopérabilité, à laquelle le profil France répond d\u0026rsquo;ailleurs bien avec les structures FrGeneralMessageStructure).\nEn conséquence, il convient donc d\u0026rsquo;encoder (en attribut) le type de la structure utilisée pour décrire le message, en l\u0026rsquo;occurrence sous la forme :\n\u0026lt;Content xsi:type=\u0026#34;siri:FrGeneralMessageStructure\u0026#34;\u0026gt; Les lignes ci-dessous proposent un exemple de Delivery d\u0026rsquo;un General Message dans le cadre du profil France.\n\u0026lt;siri:GeneralMessageDelivery version=\u0026#34;1.3\u0026#34;\u0026gt; \u0026lt;siri:ResponseTimestamp\u0026gt;2013-12-19T11:26:59.677+01:00\u0026lt;/siri:ResponseTimestamp\u0026gt; \u0026lt;siri:RequestMessageRef\u0026gt;SOAP-REQ-12345\u0026lt;/siri:RequestMessageRef\u0026gt; \u0026lt;siri:Status\u0026gt;true\u0026lt;/siri:Status\u0026gt; \u0026lt;siri:ValidUntil\u0026gt;2013-12-19T11:28:59.677+01:00\u0026lt;/siri:ValidUntil\u0026gt; \u0026lt;siri:DefaultLanguage\u0026gt;FR\u0026lt;/siri:DefaultLanguage\u0026gt; \u0026lt;siri:GeneralMessage formatRef=\u0026#34;France\u0026#34;\u0026gt; \u0026lt;siri:RecordedAtTime\u0026gt;2013-12-19T11:26:59.767+01:00\u0026lt;/siri:RecordedAtTime\u0026gt; \u0026lt;siri:ItemIdentifier\u0026gt;ITEM-ID-1234567\u0026lt;/siri:ItemIdentifier\u0026gt; \u0026lt;siri:InfoMessageIdentifier\u0026gt;INFMSG-ID-12345678\u0026lt;/siri:InfoMessageIdentifier\u0026gt; \u0026lt;siri:InfoChannelRef\u0026gt;Information\u0026lt;/siri:InfoChannelRef\u0026gt; \u0026lt;siri:ValidUntilTime\u0026gt;2013-13-19T11:32:59.767+01:00\u0026lt;/siri:ValidUntilTime\u0026gt; \u0026lt;siri:Content xsi:type=\u0026#34;siri:FrGeneralMessageStructure\u0026#34;\u0026gt; \u0026lt;siri:Message\u0026gt; \u0026lt;siri:MessageType\u0026gt;textOnly\u0026lt;/siri:MessageType\u0026gt; \u0026lt;siri:MessageText xml:lang=\u0026#34;FR\u0026#34;\u0026gt;Trafic normal sur l\u0026#39;ensemble du réseau.\u0026lt;/siri:MessageText\u0026gt; \u0026lt;/siri:Message\u0026gt; \u0026lt;/siri:Content\u0026gt; \u0026lt;/siri:GeneralMessage\u0026gt; \u0026lt;/siri:GeneralMessageDelivery\u0026gt; Facility Monitoring Dans le cadre du profil SIRI France le terme ‘Facility’ ne sera pas traduit en français. Aucun terme équivalent pertinent n’ayant été trouvé. Une facility désigne à la fois :\n Un équipement Des services (Banquaires, Commerces, …) Un véhicule Un emplacement de parking Une zone …  A chaque « Facility » peut être associé un mécanisme de comptage et une localisation.\nCe service permet d’échanger :\n La définition d’une « Facility » (vs un identifiant), y compris sa localisation. Dans le cadre du profil France l’utilisation de l’identifiant sera privilégiée. La définition de la « Facility » étant connu au travers d’échanges NetEx (cf Profil NetEx France) L’état d’une ou plusieurs « facilities » (disponibilité) et des actions possibles pour traiter une indisponibilité. Et/ou des informations de comptage (le type, l’unité et la valuer). Et/ou des informations de localisation (identifiants de point d’arrêt, lieu d’arrêt, vehicule, course, exploitant, …) Des impacts des états de la « facility » sur l’accessibilité  Requête d’information sur l’état des équipements « Facility » pour lequel les informations seront retournées    FacilityMonitoringRequest +Structure Requête pour obtenir des informations temps reel sur un ‘Service’    \n Attrib­utes Version 1:1  Version­String\n  Version du service ‘Facility Monitoring’ integrant le numéro de version du profil France ‘2.1:FR-1.0’\n  End­pointProperties Request­Timestamp\n 1:1  xsd:dateTime\n Date d’émission de la requête   Message­Identifier\n 1:1  Message­Qualifier\n Numéro d’identification du message  Topic\n  FacilityRef\n 0:1  FacilityCode\n  Il convient d’utiliser ici un identifiant d’objet de type ‘Facility’ pour lequel les informations seront retournées\n    LineRef\n 0:1 LineCode  Filtre permettant d’obtenir les informations temps reel de tous les « facilities » d’une ligne.\n   StopPoint­Ref 0:1 StopPoint­Code  Filtre permettant d’obtenir les informations temps reel de tous les « Facilities » d’un point d’arrêt.\n   VehicleRef 0:1 Vehicle­Code Filtre permettant d’obtenir les informations temps réel de tous les services d’un véhicule.   StopPlaceRef 0:1 StopPlace­Code Filtre permettant d’obtenir les informations temps réel de tous les services d’un lieu d’arrêt.    StopPlaceComponentRef\n 0:1 StopPlaceComponent­Code Filtre permettant d’obtenir les informations temps réel de tous les services d’un composant de lieu d’arrêt.    SiteRef\n 0:1 Site­Code Reference to a Site.\nUtilisé pour les nouveaux modes et les parkings.\n  Request Policy  Maximum­FacilityStatus\n 0:1 xsd:positive­Integer Nombre maximum de Facility à prendre en compte dans la réponse. Si aucune valeur n’est spécifiée, tous les services disponibles et rentrant dans les filtres spécifiés sont retournés.    Requête d’abonnement sur l’état des Services    VehicleMonitoring­SubscriptionRequest +Structure Requête d’abonnement pour obtenir les informations temps réels sur l’état des services.        Identity SubscriberRef 0:1 Participant­Code Identification du système demandeur (See SIRI Part 2 Common SubscriptionRequest parameters).   Subscription­Identifier 1:1 Subscription­Qualifier Identifiant de l’abonnement pour le système demandeur.  Lease Initial­Termination­Time 1:1 xsd:dateTIme Date et heure de fin de l'abonnement : un abonnement a forcément une date et heure de fin (les partenaires pourront décider de limiter la durée maximale d’un abonnement).  Request Facility­Monitoring­Request 1:1 +Structure Cf 6.6.1.  Policy Incremental­Updates 0:1 xsd:boolean Indique s’il faut notifier uniquement les changements d'information ou s’il faut systématiquement renvoyer toutes les informations si l'une d'elles change.\nValeur par défaut : « true » (mise à jour incrémentale).\n    Structure FacilityMonitoringDelivery La réponse à la requête contient les informations d’état d’un ou plusieurs équipements/services\n   FacilityMonitoringDelivery +Structure Description de l’état des services.                Attributes version 1:1 VersionString Numéro de version du service Facility Monitoring.   LEADER ::: 1:1 xxxService­Delivery    Pay­oad FacilityCondition 0:* +Structure Description de l’état d’un service.   any Extensions 0:1 Any Emplacement pour extension utilisateur (cf 5.4.2.2).    La structure FacilityCondition porte les informations de définition de la facility, son état, les éventuelles informations de comptage associées, les informations de localisation et des informations complémentaires (lien vers la perturbation ou l’action corrective identifiée, …)\nLe profil SIRI France permet de remonter les informations d’état, de comptage et de localisation.\nDescription de la structure ‘FacilityCondition’    FacilityCondition +Structure Description de l’état d’une “Facility ».      Facility\n(choice)\n Facility 1:1 +Structure Description Générale d’une facility (cf Facility).\nLa definition d’une FACILITY sera lorsque possible faite au travers des échanges NeTEx. L’utilisation du service SIRI à cette fin sera à limiter au maximum. Voir FM-1.\n   FacilityRef 1:1 → FacilityCode Identifiant d’une Facility.\nL’utilisation de references aux facility sera privilégiée Voir FM-1.\n  Status FacilityStatus 1:1 +Structure Description de l’état d’un Facility (cf §6.6.3.2).  Counting MonitoredCounting 0:1 +Structure Mise à jour du compteur associé à la « Facility » (cf §6.6.3.3).  Position FacilityUpdatedPosition 0:1 +Structure Mise à jour de la position de la « Facility » (cf §6.6.3.1.1).  Situation SituationRef 0:1 SituationCode Identifiant d’une SITUATION associée à l'état de l'installation.  Timing\ninformation ValidityPeriod 0:*1 +Structure Période de validité (début et durée) de la condition des du jour-type Voir ValidityCondition.  any Extensions 0:1 Any Emplacement pour extension utilisateur (cf 5.4.2.2).       FM001 La définition de la « Facility » sera récupérée via un flux NeTEx. Le service SIRI FM privilégiera l’utilisation du champ FacilityRef.     Description de la structure ‘Facility’    FM002 A renseigner uniquement si non inclue dans les exchanges NeTEx       Facility +Structure Décrit l’état de la « Facility ».         Identify FacilityCode 1:1 FacilityCode Identifiant de la “Facility”.  Description Description 0:1 nLString Description de la f”acility”.  Class FacilityClass 0:1 fixedEquipment\nmobileEquipment\nsiteComponent\nsite\nparkingBay\nvehicle\n Définition de la catégorie de la « Facility ».(cf 6.6.3.1.1.1).   Feature 0:* enumeration Fonctionalités du service.\nCf profil Accessiblité” NeTEx [R1].\n  Temporal ValidityCondition 0:*1 +Structure Période de validité de la « Facility ».  Location FacilityLocation 0:1 +Structure Localisation du service exprimée sous la forme d’un identifiant d’objet parmi les types identifies ci-dessous.   ➞ LineRef 0:1 LineCode Identifant d’une ligne (au sens Transmodel) sur laquelle le service est localisé.   ➞ StopPointRef 0:1 StopPoint­Code Identifiant d’un point d’arrêt planifié (au sens Transmodel) sur lequel le service est localisé.   ➞ VehicleRef 0:1 Vehicle­Code Identifiant d’un véhicule (au sens Transmodel) sur lequel le service est localisé.   ➞ StopPlaceRef 0:1 Stop­Place­Code Identifiant d’un lieu d’arrêt (au sens Transmodel) sur lequel le service est localisé.   ➞ StopPlaceComponentId 0:1 ComponentId Identifiant d’un composant de lieu d’arrêt (au sens Transmodel) sur lequel le service est localisé.   ➞ OperatorRef 0:1 OperatorRef OPERATOR of a VEHICLE JOURNEY. Note : L’opérateur peut changer au cours d'un voyage. Cela permet indiquer l'opérateur au point actuel du trajet.\nIl convient d’utiliser « Journey Parts » pour enregistrer tous les opérateurs de l'ensemble du trajet.\n  Accessibility AccessibilityAssessment 0:1 +Structure Description des informations d’accessibilité liées à l’état du service. (cf 6.6.3.1.1.3).  any Extensions 0:1 Any Emplacement pour extension utilisateur (cf 5.4.2.2).    Description de l’enum FacilityClass Les valeurs retenues par le profil SIRI France sont les suivantes :\n   SIRI-FM Description     fixedEquipment « Facility » est un équipement fixe.   mobileEquipment « Facility » est un équipement mobile (embarqué).   site Facility est un site.   parkingBay Facility est un emplacement de parking.   vehicle Facility est un véhicule.    Description de l’enum ‘Feature’ Se reporter au profil NeTex France Accessibilité [R1].\nDescription de la structure ‘AccessibilityAssessment’ Se reporter au profil NeTex France Accessibilité [R1].\nDescription de l’état d’une \u0026ldquo;Facility\u0026rdquo;    FacilityStatus +Structure Décrit l’état d’une « Facility ».                Status Status 1:1 unknown | available | notAvailable | partiallyAvailable | added | removed Etat d’une “Facility” (cf 6.6.3.2.1).   Description Description 0:1 nlString Description associée à l’état d’une « Facility ».   Special Needs Accessibility­Assessment 0:* +Structure Décrit l\u0026rsquo;état de l\u0026rsquo;accessibilité pour différents types de besoins spéciaux.    Description de l’enum ‘Status’ Les valeurs retenues par le profil SIRI France sont les suivantes :\n    SIRI-FM Description    unknown Etat d’une “Facility” inconnu..\nLe champ description doit être renseigné si valorisé avec unknowm (RG)\n  available “Facility” disponible.  notAvailable “Facility” non disponible.  partiallyAvailable “Facility” partiellement disponible.  added “Facility” ajoutée définitivement.  removed “Facility” supprimée définitivement.    Description de comptage associé à une »Facility » Cette structure permet d’associer un compteur à une Facility, l’utilisation de cette structure est à convenir entre les partenaires de l’échange. Il pourra s’agir par exemple du nombre de personnes dans un véhicule, sur un quai, nombre de place de parking, nombre de bornes libres / occupées pour les aires de staionnement de vehicules partagés, …\n Counting\nType CountingType 1:1 CountingTypeEnumeration Nature de ce qui est compté (cf 6.6.3.3.1).   CountedFeatureUnit 0:1 CountedFeatureUnitEnumeration Unité de comptage (cf 0)   TypeOfCountedFeature 0:1 TypeOfValueStructure Type ouvert ou classification affinée de ce qui est compté (complément aux informations provenant du type de la Facility lui-même)Exemples :\n  Nombre de kilomètres restant pour les vélos en libre service ;\n  Charge batterie disponible ;\n  A prédéfinir.\n   Count Choix -1:1     a) Count 0:1 xsd:integer Valeur comptée.   b) Percentage 0:1 PercentageType Valeur exprimée en pourcentage (0.0 à 100.0) de la valeur maximale possible.  Counting\ndescription Trend 0:1 CountingTrendEnumeration Tendance du comptage (cf 6.6.3.3.3)   Description 0:1 NaturalLanguageStringStructure Description de ce qui est compté.    Description de l’enum ‘CountingType’ Les valeurs retenues par le profil SIRI France sont les suivantes :\n  Value Description    availabilityCount Comptage des véhicules disponibles, des appareils, de l'espace, etc.  reservedCount Comptage du véhicule réservé, des appareils, de l'espace, etc.  outOfOrderCount Comptage des véhicules, appareils, espaces hors service, etc.  presentCount Comptage des personnes pésentes.  currentStateCount Niveau de ressource ou statut de la mesure (carburant, etc.).\nAssocié à un TypeofCOuntedFeature.\n       FM001 L’utilisation de la valeur ‘currentStateCount’ nécessite que le champ ‘TypeOfCountedFeature’ soit présent.     Description de l’enum ‘CountedFeatureUnit’ Les valeurs retenues par le profil SIRI France sont les suivantes :\n   Value Description     bays Emplacement pour garer un véhicule.   seats Place assise.   devices Les appareils divers (comme les casiers, les guides audio, etc.).   vehicles Tout type de véhicule.   persons Personne physique.    Description de l’enum ‘Trend' Les valeurs retenues par le profil SIRI France sont les suivantes :\n   Value Description     decreasing La valeur est actuellement en baisse.   increasing La valeur est actuellement en hausse.   stable La valeur est actuellement stable.   unstable La valeur est actuellement instable sans tendance claire.   unknown La tendance est inconnue.    Remedy Description des actions à entreprendre pour remédier à la non-disponibilité d’une ‘facility’.\nNon retenu dans le profil SIRI France.\nSituation Exchange Ce service permet de définir les perturbations et leurs consequences. Dans le cadre de cette version du profil il a pour objectif de définir une perturbation, ses zones de conséquence et les messages associés à diffuser.\n   SX001 Si ce service est implémenté, le service GM ne doit plus etre utilisé pour la diffusion de message de type perturbation.     Pour la mise à jour des systèmes utilisant le service GM pour le transfert de message de perturbation les règles de traduction sont rappelées dans la suite de ce paragraphe.\nMessages Information Voyageur (IV) associés aux évènements Cas de la compatibilité avec le service General Message du profil SIRI ‘Ile de France’ Le service Situation Exchange peut être utilisé en lieu et place du service General Message tel qu\u0026rsquo;il a été particularisé dans le cadre du profil Île-de-France 2.4. Cela permettra d\u0026rsquo;éviter une utilisation combinée des deux services, tout en permettant aux acteurs qui le souhaitent d\u0026rsquo;utiliser le service en restant sur le périmètre fonctionnel retenu pour General Message.\nSeule la compatibilité concernant les filtres de requête n\u0026rsquo;est pas totale. Ainsi, les filtres DestinationRef, RouteRef et JourneyPatternRef ne sont pas disponibles au niveau de Situation Exchange. Mais l\u0026rsquo;information est disponible dans les réponses.\nOn notera aussi certaines différences de mode de fonctionnement. Ainsi le service Situation Exchange ne dispose pas d'InfoMessageCancellation, mais effectue cette notification en positionnant l\u0026rsquo;attribut Progress à Closed (PtSituationElement).\nNotons aussi que, par nature, le champ SituationRef de General Message n\u0026rsquo;a pas de correspondance car il a pour vocation de permettre de faire le lien avec une Situation de Situation Exchange, ce qui n\u0026rsquo;a guère d\u0026rsquo;intérêt ici….\nOn notera enfin que le champ ValidUntil utilisé dans Situation exchange est celui de l\u0026rsquo;entête du message (AbstractServiceDeliveryStructure).\nLes messages textuels eux même seront traités de la façon suivante :\n  shortMessage : Message dans Summary (dans PtSituationElement)\n  longMessage : Message dans Description (dans PtSituationElement)\n  textOnly : Type MIME text/plain (dans Summary ou Description suivant que le message est court ou long) avec un champ additionnel \u0026quot; Content-Description: SIRI-FR-IDF no line break message\u0026rdquo;.\nNote: il n\u0026rsquo;y a pas de type MIME générique excluant les sauts de ligne, d’où cet usage du champ MIME Content-Description.\n  formattedText : Type MIME text/plain (dans Summary ou Description suivant que le message est court ou long).\nNote: les champs NumberOfLines et NumberOfCharPerLine n\u0026rsquo;ont pas d\u0026rsquo;équivalent dans Situation Exchange, mais peuvent aisément être recalculés à partir du message lui-même.\n  HTML : Type MIME text/html (dans Summary ou Description suivant que le message est court ou long)\n  RTF : Type MIME text/rtf (dans Summary ou Description suivant que le message est court ou long)\n  codedMessage : Message dans ReasonName (dans PtSituationElement)\n  Exemple de message :\nMIME-Version: 1.0 Content-Type: text/plain Content-Description: SIRI-FR-IDF no line break message Ceci est un Message Messages avec Zones de diffusion Les champs ‘summary’ et ‘description’ tels que définis au paragraphe 6.7.1.1 permettent de définir un message général associé à l’évènement et ses conséquences.\nEn complément, le profil SIRI France permet de définir des messages spécifiques à des zones de diffusion (6.7.4.1.7.6.5). La structure PublishingAction permet de definir pour différents canaux de communication un message (prompt) et sa zone de diffusion (Affect). Dans la structure PublishingAction, le profil SIRI France retient uniquement la sous-structure PublishAtScope. La sous-structure PassengerInformationAction n\u0026rsquo;est pas retenue.\nDe ce fait, le profil France fait le choix suivant pour la communication d\u0026rsquo;un message :\n Les messages d\u0026rsquo;informations associées à une perturbation sont échangés via le champ \u0026ldquo;Prompt\u0026rdquo; de la structure \u0026ldquo;ActionData\u0026rdquo;. L\u0026rsquo;accès à ce champ est réalisé en parcourant le chemin suivant : PtSituationElement/PublishingActions/Publish...Action/ActionData/Prompt. Le chemin PtSituationElement/PublishingActions/PublishingAction/PassengerInformationAction/ActionData/Prompt (et plus généralement l\u0026rsquo;ensemble du PassengerInformationAction) n\u0026rsquo;est pas utilisé dans le cadre du profil SIRI France.   Les tableaux de définition du service Situation Exchange, ci-dessous, intègrent les éléments necessaires pour assurer la compatibilité avec l’implémentation du Service GM.\nRequête pour l’obtention d’information relatives à des évènements et leurs conséquences    SituationExchangeRequest +Structure Requête pour obtenir des informations sur une situation     Attributes Version 0:1 VersionString Version du service ‘Situation Exchange’ integrant le numéro de version du profil France ‘2.1:FR-1.0’  Timestamp RequestTimestamp 1:1 xsd:dateTime Date d’émission de la requête  Contextualised\nRequest\nEndpointGroup MessageIdentifier 0:1 MessageQualifier Numéro d’identification du message  TemporalSubscriptionGroup PreviewInterval 0:1 PositiveDurationType Durée pendant laquelle les SITUATIONS doivent être incluses, c'est-à-dire que seules les SITUATIONS qui commencent avant la fin de cette fenêtre seront incluses. Normalement utilisé pour les abonnements afin de conserver une fenêtre glissante d'intérêt.   StartTime 0:1 xsd:dateTime Heure de début initiale pour PreviewInterval. Si absente, l'heure actuelle est prise par défaut. Seules les SITUATIONS ou les mises à jour créées après cette heure seront envoyées. Cela permet un redémarrage sans tout renvoyer.  Temporal\nContent\nFilterGroup ValidityPeriod 0:1 →structure Plage temporelle pour les incidents à inclure tous les incidents actuels seront inclus.   ➞ StartTime 1:1 xsd:dateTime Heure de début des incidents. Les incidents avec une heure de début après cette heure seront inclus.   ➞ EndTime 0:1 xsd:dateTime Heure de fin des incidents. Les incidents avec une heure de fin avant cette heure ou sans heure de fin à cette heure seront inclus.   ➞ EndTimePrecision 0:1 Enum: day | hour| second | millisecond Précision avec laquelle interpréter l'heure de fin. La valeur par défaut est à la seconde.  AffectedModeGroup   →Group Les éléments du groupe MODE.   VehicleMode 0:1 →VehicleModesOfTransportation Enum Mode du véhicule : voir l’énumération complète dans le XSD SIRI [R10].   AccessMode 0:1 Enum {foot|bicycle|car|taxi|shuttle} Les catégories d'accès autorisées au lieu d'arrêt pour lesquelles les situations seront renvoyées. Par défaut “foot”   Severity 0:1 enum Valeur du filtre de gravité à appliquer : seules les SITUATIONS dont la gravité est supérieure ou égale à la valeur spécifiée seront renvoyées. . Par Defaut « undefined ».\nFiltre à appliquer sur la sévérité d’une Situation (cf §6.7.4.1.4)\n  SituationClassifierFilterGroup Keywords 0:1 xsd:NMTOKENS .Dans le cas de l'utilisation en lieu et place de General Message, seules les valeurs suivantes seront utilisées et permettent de gérer la mise en cohérence avec les canaux General Message : «Perturbation»   SituationNetworkFilterGroup 0:1 Group Filtre les résuluats pour n’inclure que les SITUATIONs relatives aux éléments NETWORK (voir ci-dessous).\nNote : Regroupe les filtres operator, Line, StopPoint\n  Request Policy MaximumNumberOfSituationElements 0:1 xsd:positiveInteger Le nombre maximal de SituationElements à inclure dans une diffusion donnée. Les n événements les plus récents dans la fenêtre d'anticipation sont inclus.    Situation Network filter     SituationNetworkFilterGroup OperatorRef 0:1 →OperatorCode\n(xsd:NMToken)\n Filtre les résultats pour n'inclure que les SITUATIONS relatives à l'Opérateur.   NetworkRef 0:1 →NetworkCode Filtre les résultats pour n'inclure que les SITUATIONS relatives au réseau.   choix -1:1  Filtre les résultats pour n'inclure que les SITUATIONS relatives aux LIGNES données   a) LineRef 0:* →LineCode\n(xsd:NMToken)\n Filtre les résultats pour n'inclure que les résultats de la LIGNE donnée. Si aucune LineRef n'est spécifiée comme filtre d'abonnement, cela implique implicitement la transmission de données pour toutes les LIGNES dans le SAE.   b) Lines 0:1 +structure    ➞ LineDirection 1:* +LineDirectionStructure Filtre les résultats pour n'inclure que les SITUATIONS relatives aux Lignes/Direction spécifiées.   StopPointRef 0:* →StopPointCode\n(xsd:NMToken)\n Filtre les résultats pour n'inclure que les SITUATIONS relatives points d’arrêt spécifiés   FacilityRef 0:* →FacilityCode Filtre les résultats pour n'inclure que les SITUATIONS relatives aux « Facilities »..    Abonnement pour l’obtention et la mise à jour d’évènements et leurs conséquences    Situation ExchangeSubscriptionRequest +Structure Demande d\u0026rsquo;abonnement au Service d\u0026rsquo;échange de situation.        SubscriptionIdentityGroup SubscriberRef 0:1 →ParticipantCode Voir SIRI Partie 2 “Common SubscriptionRequest parameters.”   SubscriptionIdentifier 1:1 SubscriptionQualifierStructure Voir SIRI Partie 2 “Common SubscriptionRequest parameters.”  Lease InitialTerminationTime 1:1 xsd:dateTime Voir SIRI Partie 2 “Common SubscriptionRequest parameters.”  Request SituationExchangeRequest 1:1 +Structure   Situation ExchangeSubscriptionPolicy IncrementalUpdates 0:1 xsd:Boolean Indique s’il faut notifier uniquement les changements d'information ou s’il faut systématiquement renvoyer toutes les informations si l'une d'elles change.\nValeur par défaut : « true » (mise à jour incrémentale).\n    Réponses aux demandes d’événements La fourniture du service ‘Situation Exchange’ permet de distribuer des informations relatives à la définition et la mise à jour d’un ou plusieurs événements.\nCe service distingue la définition de la perturbation (PTSituationElement) des messages d’information Voyageur associée (Description + Publishing Actions).\nCes messages ne pas distribués par le service GM si le Service SX est implémenté dans un échange.\n   SituationExchangeDelivery +Structure Définition et mise à jour des informations de perturbation et messages IV associés.                Attributes version 1:1 VersionString Version Identifier d’une perturbation,, par exemple ‘1.1a’.   HEADER ::: 1:1 xxxServiceDelivery Voir SIRI Partie 2 xxxServiceDelivery.   SituationExchangePayloadGroup PtSituationContext 0:1 +Structure Décrit les valeurs communes à toutes les SITUATIONS de la diffusion.    Situations 0:1 +Structure     ➞ PtSituationElement 0:* +Structure Définition des pertrubations et messages IV associés (cf 6.7.4.1).    PtSituationElement    PtSituationElement +Structure Description d’une perturbation        Log CreationTime 1:1 xsd:dateTime Heure de creation de SITUATION  SituationSharedIdentityGroup SituationBasedIdentityGroup  →Group Éléments Référence à une SITUATION ou mise à jour d'une SITUATION. ParticipantRef est facultatif et peut être fourni à partir du contexte.   CountryRef 0:1 →CountryCode Code Pays du participant   ParticipantRef 1:1 →ParticipantCode Identifiant du système participant qui crée la SITUATION. Voir la partie 2.. Identifiant Unique par pays.   SituationNumber 1:1 →SituationNumber Identifiant unique d’une SITUATION pour un Participant.\nDans le cas de l'utilisation en lieu et place de General Message, correspond au InfoMessageIdentifier.\n   SituationUpdateIdentityGroup  →Group Type de référence pour une mise à jour d’une SITUATION. ParticipantRef est facultatif et peut être fourni à partir du contexte.   Version 0:1 →Situation Version Version d’une mise à jour d’un élément de SITUATION.\nDans le cas de l'utilisation en lieu et place de General Message, correspond au InfoMessageVersion.\n  SituationInfoGroup Source 0:1 +SituationSourceStructure Source d’une SITUATION   ➞ SourceType 1:1 Enum Dans le cas de l'utilisation en lieu et place de General Message, seul le champ SourceType de la structure sera utilisé, et positionné à directReport.\nVoir définition Enum : 6.7.4.1.1.1\n  Log VersionedAtTime 0:1 xsd:dateTime   PtSituationBodyGroup\\StatusGroup Verification 0:1 Enum {unknown|unverified|verified} Indique si la SITUATION a été vérifiée. Il s’agit d’un enuméré.\nValeur par défaut : « unknown ».\n   Progress 0:1 Enum Etat de SITUATION. Il s’agit d’un enuméré.\nDans le cas de l'utilisation en lieu et place de General Message, seuls les codes Open et Closed sont utilisés. Le Closed équivaut alors à un InfoMessageCancellation\nDéfinition Enum : 6.7.4.1.2\n   QualityIndex 0:1 Enum {certain|veryReliable|reliable|unreliable|unconfirmed} Évaluation de l'exactitude probable des données. Valeurs d'énumération\nValeur par défaut : unconfirmed\n   Publication 0:* PublicationStatus Cet attribut est déprécié dans SIRI en faveur de Progress (voir plus haut).\nStatut de publication. Un ensemble spécifié de sous-états auxquels une SITUATION peut être attribuée.\n  PtSituationBodyGroup\\TemporalGroup ValidityPeriod 1:* range Une ou plusieurs Période d'application globale inclusive de la SITUATION   ➞ StartTime 1:1 xsd:dateTime L'horodatage de début (inclusif)   ➞ EndTime 0:1 xsd:dateTime L'horodatage de fin (inclusif). Si elle est omise, la fin de la plage est ouverte, c'est-à-dire qu'elle doit être interprétée comme \"pour toujours\".   ➞ EndTimeStatus 0:1 Enum: {undefined | longTerm | shortTerm} Si l'heure de fin n'est pas fournie, s'il faut l'interpréter comme une SITUATION à long terme, à court terme ou d'une durée inconnue. La valeur par défaut est indéfinie   Repetitions 0:1 DayType La situation s'applique uniquement aux types de jours répétés au cours de la ou des périodes de validité globales. Par exemple “dimanche”.   ➞ DayType 1:* enum Jour Type.   PublicationWindow 0:* range Fenêtre de publication pour SITUATION si différente de la période de validité. La période pendant laquelle le public est informé de SITUATION peut commencer avant ou après SITUATION.   ➞ StartTime 1:1 xsd:dateTime L'horodatage de début (inclusif).   ➞ EndTime 0:1 xsd:dateTime L'horodatage de fin (inclusif). Si elle est omise, la fin de la plage est ouverte, c'est-à-dire qu'elle doit être interprétée comme \"pour toujours\".   ➞ EndTimeStatus 0:1 Enum: {undefined | longTerm | shortTerm} Si l'heure de fin n'est pas fournie, s'il faut l'interpréter comme une SITUATION à long terme, à court terme ou d'une durée inconnue.\nLa valeur par défaut est « undefined ».\n  ClassifierGroup ReasonGroup 1:1 enum Dans le profil France, nous retenons uniquement l'énumération portée par AlertCause au sein du TpegReasonGroup, les autres énumérations étant marquées comme dépréciées depuis SIRI v2.1   ReasonName 0:1 string    Severity 0:1 enum Sévérité de SITUATION\nValeur par Defaut : « normal ».\nDéfinition de l’énuméré : voir 6.7.4.1.4).\nDans le cas de l'utilisation en lieu et place de General Message, ce champ sera utilisé pour les messages de type codedMessage (le champ porte alors valeur du MessageText pour les messages de type codedMessage).\n   Priority 0:1 nonNegativeInteger Classement arbitraire de la priorité du message si différent de la gravité 1-Élevée.\nA noter que cela peut être utilisé pour les niveaux d'urgence Datex2.\n1 = extremelyUrgent.\n2 = urgent.\n3 = normal.\n   Sensitivity 0:1 Enum {high|medium|low} Confidentialité de SITUATION.\nValeurpar défaut : medium\n   Audience 0:1 Enum {public|emergencyService|authorities|transportOperators} Audience de SITUATION.   ScopeType 0:1 enum Type de périmètre de SITUATION.\nDéfinition de l’énuméré : voir 6.7.4.1.5.\n   Planned 0:1 boolean Si la SITUATION était planifiée (par exemple, travaux d'ingénierie) ou non planifiée (par exemple, modification du service).\nLa valeur par défaut est « false », c'est-à-dire non planifiée.\n   Keywords 0:1 xsd:NMTOKENS Dans le cas de l'utilisation en lieu et place de General Message, seules les valeurs suivantes seront utilisées et permettent de gérer la mise en cohérence avec les canaux General Message :\n «Perturbation»\n “Information”\n “Commercial”\n   DescriptionGroup Summary 0:* DefaultedText Résumé de la SITUATION. S'il est absent, il doit être généré à partir des éléments de structure et/ou en condensant la Description.\nDans le cas de l'utilisation en lieu et place de General Message, cf 6.7.1.\n   Description 0:* DefaultedText Description de la SITUATION. Ne doit répéter aucune LIGNE incluse dans le résumé..\nDans le cas de l'utilisation en lieu et place de General Message, cf 6.7.1.\n   Detail 0:* DefaultedText Détails descriptifs supplémentaires sur la SITUATION. Pour l'utilisation du texte par défaut.   Advice 0:* DefaultedText Autres conseils aux passagers. Pour l'utilisation du texte par défaut.   Internal 0:1 DefaultedText Description de la SITUATION à usage (interne) de l'entreprise. Pour l'utilisation du texte par défaut.   Images 0:1 Image Ajout d’une ou plusieurs Images.   ➞ Image 1:* +Structure    InfoLinks 0:1 InfoLink Un ou plusieurs InfoLinks pour description.   ➞ InfoLink 1:* +Structure    Affects 1:1 +Structure Liste des objets directement concernés par la SITUATION.\nVoir 6.7.4.1.7.6.\n  PtBodyGroup Consequences 0:1 many One or more consequences.\nDescription des consequences de l’évènement\n   ➞ Consequence 1:* +Structure Voir 6.7.4.1.6   PublishingActions 0:1 →ActionsStructure Conséquence d’une SITUATION.\nDescription d’une consequence de l’évènement cf §6.7.4.1.6\n    Description de la structure ‘Source’    SituationSource +Structure Information relative à la source des données de la SITUATION          Country 0:1 →CountryCode Pays d’origine de la Source. Code IANA.    SourceType 1:1 enum Nature de la source ayant initialisée l’évènement\nDans le cas de l'utilisation en lieu et place de General Message, seul le champ SourceType de la structure sera utilisé, et positionné à directReport.\nDéfinition de l’énuméré : voir 6.7.4.1.1.1.\n  SituationSourceDetailsGroup Email 0:1 string Email du fournisseur   Phone 0:1 phoneNumber Numéro téléphone fournisseur.   Web 0:1 anyURL URL du fournisseur.    Description de l’enum SourceType Les valeurs retenues par le profil SIRI France sont les suivantes :\n   SIRI-SX Description     directReport Rapport remis en direct   email Rapport reçu via email   phone Rapport reçu via téléphone   post Rapport reçu via courrier postal   feed Rapport reçu via alimentation automatique   radio Rapport reçu via radio   tv Rapport reçu via TV   web Rapport reçu via website   text Rapport reçu via message   other Rapport reçu via autres moyens    Decription de l’enum ‘Progress’ Les valeurs retenues par le profil SIRI France sont les suivantes :\n   SIRI SX Description     open Situation en cours   published Situation en cours et publiée   closed Situation terminée       SX-2 Une situation ‘open’ n’est pas communiquée à l’extérieur du système. Dès lors que la situation est échangée avec l’extérieur le status doit passer à ‘published’.     Description de l’enum ‘AlertCause’ Les valeurs retenues par le profil SIRI France au sein de l\u0026rsquo;élément ‘AlertCause’ sont les suivantes :\n   Groupe SIRI-SX Description      unknown Inconnu   sécurité (safety relevant) securityAlert Alerte sécurité   sécurité (safety relevant) emergencyServicesCall Appel des services d\u0026rsquo;urgence   sécurité (safety relevant) policeActivity Activité policière   sécurité (safety relevant) policeOrder Ordre de la police   sécurité (safety relevant) fire Incendie   sécurité (safety relevant) cableFire Incendie sur un câble   sécurité (safety relevant) smokeDetectedOnVehicle Fumée détectée dans un véhicule   sécurité (safety relevant) fireAtStation Incendie en station   sécurité (safety relevant) fireRun Appel incendie   sécurité (safety relevant) fireBrigadeOrder Ordre des pompiers   sécurité (safety relevant) explosion Explosion   sécurité (safety relevant) explosionHazard Risque d\u0026rsquo;explosion   sécurité (safety relevant) bombDisposal Déminage   sécurité (safety relevant) emergencyMedicalServices Urgence médicale   sécurité (safety relevant) emergencyBrake Freinage d\u0026rsquo;urgence   sécurité (safety relevant) vandalism Vandalisme   sécurité (safety relevant) cableTheft Vol de câble   sécurité (safety relevant) signalPassedAtDanger Signal d\u0026rsquo;avertissement   sécurité (safety relevant) stationOverrun Dépassement de station   sécurité (safety relevant) passengersBlockingDoors Passager bloquant les portes   sécurité (safety relevant) defectiveSecuritySystem Système de sécurité défectueux   sécurité (safety relevant) overcrowded Surcharge passagère   sécurité (safety relevant) borderControl Police aux frontières   sécurité (safety relevant) unattendedBag Bagage oublié   sécurité (safety relevant) telephonedThreat Menace téléphonique   sécurité (safety relevant) suspectVehicle Véhicule suspect   sécurité (safety relevant) evacuation Évacuation   sécurité (safety relevant) terroristIncident Incident terroriste   sécurité (safety relevant) publicDisturbance Trouble de l\u0026rsquo;ordre public   problèmes techniques (technical problem) technicalProblem Problème technique   problèmes techniques (technical problem) vehicleFailure Panne du véhicule   problèmes techniques (technical problem) serviceDisruption Interruption de service   problèmes techniques (technical problem) doorFailure Panne d\u0026rsquo;une porte   problèmes techniques (technical problem) lightingFailure Panne d\u0026rsquo;éclairage   problèmes techniques (technical problem) pointsProblem Problème mécanique   problèmes techniques (technical problem) pointsFailure Panne mécanique   problèmes techniques (technical problem) signalProblem Problème de signalisation   problèmes techniques (technical problem) signalFailure Panne de signalisation   problèmes techniques (technical problem) overheadWireFailure Panne de câble aérien   problèmes techniques (technical problem) levelCrossingFailure Panne d\u0026rsquo;un passage à niveau   problèmes techniques (technical problem) trafficManagementSystemFailure Panne du système de gestion du trafic   problèmes techniques (technical problem) engineFailure Panne moteur   problèmes techniques (technical problem) breakdown Incident   problèmes techniques (technical problem) repairWork Travaux de réparation   problèmes techniques (technical problem) constructionWork Travaux de construction   problèmes techniques (technical problem) maintenanceWork Travaux de maintenance   problèmes techniques (technical problem) powerProblem Problème d\u0026rsquo;alimentation   problèmes techniques (technical problem) trackCircuitProblem Problème de circuit   problèmes techniques (technical problem) swingBridgeFailure Panne d\u0026rsquo;un pont tournant   problèmes techniques (technical problem) escalatorFailure Panne d\u0026rsquo;escalator   problèmes techniques (technical problem) liftFailure Panne d\u0026rsquo;ascenseur   problèmes techniques (technical problem) gangwayProblem Problème de passerelle   problèmes techniques (technical problem) defectiveVehicle Véhicule défectueux   problèmes techniques (technical problem) brokenRail Rail défectueux   problèmes techniques (technical problem) poorRailConditions Rail en mauvaise condition   problèmes techniques (technical problem) deicingWork Travaux de dégivrage   problèmes techniques (technical problem) wheelProblem Problème de roue   trafic (traffic) routeBlockage Route bloquée   trafic (traffic) congestion Embouteillage   trafic (traffic) heavyTraffic Trafic dense   trafic (traffic) routeDiversion Route détournée   trafic (traffic) roadworks Travaux   trafic (traffic) unscheduledConstructionWork Travaux non planifiés   trafic (traffic) levelCrossingBlocked Passage à niveau bloqué   trafic (traffic) sewerageMaintenance Maintenance des canalisations   trafic (traffic) roadClosed Route fermée   trafic (traffic) roadwayDamage Route endommagée   trafic (traffic) bridgeDamage Pont endommagé   trafic (traffic) personOnTheLine Personne sur la voie   trafic (traffic) objectOnTheLine Objet sur la voie   trafic (traffic) vehicleOnTheLine Véhicule sur la voie   trafic (traffic) animalOnTheLine Animal sur la voie   trafic (traffic) fallenTreeOnTheLine Arbre tombé sur la voie   trafic (traffic) speedRestrictions Limitation de vitesse   trafic (traffic) precedingVehicle Véhicule précédent   accident (accident) accident Accidents   accident (accident) nearMiss Quasi-collision   accident (accident) personHitByVehicle Collision avec une personne   accident (accident) vehicleStruckObject Collision avec un objet   accident (accident) vehicleStruckAnimal Collision avec un animal   accident (accident) derailment Déraillement   accident (accident) collision Collision   accident (accident) levelCrossingAccident Incident à un passage à niveau   environnement (environmental) poorWeather Mauvais temps   environnement (environmental) fog Brouillard   environnement (environmental) heavySnowfall Fortes chutes de neige   environnement (environmental) heavyRain Fortes pluies   environnement (environmental) strongWinds Vents violents   environnement (environmental) ice Glace   environnement (environmental) hail Grêle   environnement (environmental) highTemperatures Températures élevées   environnement (environmental) flooding Inondation   environnement (environmental) lowWaterLevel Niveau d\u0026rsquo;eau bas   environnement (environmental) riskOfFlooding Risque d\u0026rsquo;inondation   environnement (environmental) highWaterLevel Niveau d\u0026rsquo;eau élevé   environnement (environmental) fallenLeaves Chute de feuilles   environnement (environmental) fallenTree Chute d\u0026rsquo;arbre   environnement (environmental) landslide Glissement de terrain   environnement (environmental) riskOfLandslide Risque de glissement de terrain   environnement (environmental) driftingSnow Neige \u0026amp; Vents   environnement (environmental) blizzardConditions Blizzard   environnement (environmental) stormDamage Dommages causés par une tempête   environnement (environmental) lightningStrike Éclairs   environnement (environmental) roughSea Mer agitée   environnement (environmental) highTide Marée haute   environnement (environmental) lowTide Marée basse   environnement (environmental) iceDrift Glace \u0026amp; Vents   environnement (environmental) avalanches Avalanches   environnement (environmental) riskOfAvalanches Risque d\u0026rsquo;avalanche   environnement (environmental) flashFloods Inondation éclair   environnement (environmental) mudslide Glissement de boue   environnement (environmental) rockfalls Chutes de pierres   environnement (environmental) subsidence Affaissement   environnement (environmental) earthquakeDamage Dommages causés par un séisme   environnement (environmental) grassFire Incendie de prairie   environnement (environmental) wildlandFire Incendie de forêt   environnement (environmental) iceOnRailway Glace sur les rails   environnement (environmental) iceOnCarriages Glace sur les voitures   évènements spéciaux (special events) specialEvent Évènements spéciaux   évènements spéciaux (special events) procession Marche   évènements spéciaux (special events) demonstration Manifestation   personnel (personnel) industrialAction Grève industrielle   personnel (personnel) staffSickness Personnel malade   personnel (personnel) staffAbsence Personnel absent   personnel (personnel) operatorCeasedTrading Droit de retrait   divers (miscellaneous) previousDisturbances Perturbations précédentes   divers (miscellaneous) vehicleBlockingTrack Véhicule bloquant les voies   divers (miscellaneous) foreignDisturbances Perturbations étrangères   divers (miscellaneous) waitingForTransferPassengers Attente de passagers en transit   divers (miscellaneous) changeInCarriages Changement de véhicules   divers (miscellaneous) trainCoupling Attelage de trains   divers (miscellaneous) boardingDelay Retard à l\u0026rsquo;embarquement   divers (miscellaneous) awaitingOncomingVehicle Attente de l\u0026rsquo;arrivée d\u0026rsquo;un véhicule   divers (miscellaneous) overtaking Dépassement   divers (miscellaneous) provisionDelay Retard dans la mise à disposition   divers (miscellaneous) miscellaneous Divers    undefinedAlertCause Cause d\u0026rsquo;alerte non-définie    Description de l’enum ‘Severity’ Les valeurs retenues par le profil SIRI France sont les suivantes :\n   SIRI-SX Description     unknown Inconnu   verySlight Très léger   slight Léger   normal Normal   severe Sévère   verySevere Très sévère   noImpact Pas d’impact   undefined Non défini    Description de l’enum ‘ScopeType’ Les valeurs retenues par le profil SIRI France sont les suivantes :\n   SIRI-SX Description     general La perturbation a un impact global.   operator La perturbation a un impact sur un opérateur spécifique.   network La perturbation a un impact sur tout le réseau.   route La perturbation a un impact sur un itinéraire particulier.   line La perturbation a un impact sur une ligne particulière.   place La perturbation a un impact sur un lieu particulier.   StopPlace La perturbation a un impact sur un lieu d’arrêt particulier.   stopPoint La perturbation a un impact sur un point d’arrêt particulier.   vehicleJourney La perturbation a un impact sur une course spécifique.    Description de la structure ‘Consequences’    PtConsequence +Structure Effet d’une SITUATION sur le service        Classifiers Condition 0:* enum Classification de l'effet sur le service.\nIl peut être remplacé par JourneyCondition dans AffectedVehicleJourney\nQualification de l’événement sur l’offre de transport (cf §6.7.4.1.6.1)\n   Severity 1:1 enum Gravité de la SITUATION. La valeur par défaut est normale (cf 6.7.4.1.4).   Affects Affects 0:1 AffectsScope Liste exhaustive des objets directements concernés par la CONSEQUENCE. Si cette balise n'est pas présente, seuls les objets PtSituationElement\\Affects sont considérés pour cette CONSEQUENCE. Voir 6.7.4.1.7.6.  Advice Advice 0:1 +PtAdviceStructure Conseils aux passangers (cf ci-dessous)   ➞ AdviceRef 0:1 id Identifiant de la norme.\nMessage d'information complémentaire aux passagers\n   ➞ Details 0:* nlString Conseils textuels supplémentaires aux passagers.  Blocking Blocking 0:1 +Structure Comment la perturbation doit être gérée dans les systèmes d'information. Cf ci-après   ➞ JourneyPlanner 0:1 boolean La valeur par défaut est false ; ne pas supprimer.\nIndique si les données de l’évènement doivent être ou non prises en compte par un calculateur d’itinéraire\n  Activity Boarding 0:1 +Structure Public visé par SITUATION. Voir les lignes suivantes.   ➞ ArrivalBoardingActivity 0:1 enum Type d'embarquement et de débarquement autorisé à l'arrêt à l’arrivée. La valeur par défaut est Embarquement.   ➞ DepartureBoardingActivity 0:1 enum Type d'embarquement et de débarquement autorisé à l'arrêt au départ. La valeur par défaut est Embarquement.  Delay Delays 0:1 +Structure Retards prévus .   ➞ Delay 0:1 dPositiveDuration Temps de trajet supplémentaire nécessaire pour surmonter les perturbations.       SX-3 Les délais sont exprimés uniquement sous la forme d’une durée     Description de l’enum ‘Conditions’ Les valeurs retenues par le profil SIRI France sont les suivantes :\n   SIRI-SX Description     unknown inconnu   altered dégradé   cancelled annulé   delayed retardé   diverted Dévié   noService pas de service   disrupted perturbé   additionalService service supplémentaire   specialService service spécial   onTime à l’heure   normalService service normal   intermittentService service intermittant   extendedService service étendu   splittingTrain train fractionné   replacementTransport transport de remplacement   arrivesEarly en avance   shuttleService service navette   replacementService service de remplacement   undefinedServiceInformation service d’information inconnu.    Description de la structure ‘Publishing Actions’    PublishingActions +Structure Indication par type de canal de communication d’actions à réaliser. Permet la diffusion des messages IV complémentaires sur des localisations particulières.                ActionsGroup PublishToWebAction 0:* +Structure Publication sur le web. Cf 6.7.4.1.7.1    PublishToMobileAction 0:* +Structure Publication sur outils mobiles. Cf 6.7.4.1.7.2    PublishToDisplayAction 0:* +Structure Diffusion sur des afficheurs Embarqués / Sol    NotifyByEmailAction 0:* +Structure Publication via email. Cf 6.7.4.1.7.3    NotifyBySmsAction 0:* +Structure Publication via SMS.Cf 6.7.4.1.7.5    Description de la structure “PublishToWebAction”    PublishToWebAction +Structure Paramètres de publication sur le canal Web.                ParameterisedAction ParameterisedAction 0:1 +Structure Hérité de ParameterisedAction.\nParameterisedAction : utilisé pour permettre de définir un message à publier sur le web cf.6.7.4.1.7.6\n    Incidents 0:1 boolean À inclure dans les listes de SITUATION sur le site Web. La valeur par défaut est \u0026lsquo;vrai\u0026rsquo;.    HomePage 0:1 boolean À inclure sur la page d\u0026rsquo;accueil du site Web. La valeur par défaut est \u0026lsquo;faux\u0026rsquo;.    Ticker 0:1 boolean À inclure dans la bande de défilement mobile. La valeur par défaut est \u0026lsquo;faux\u0026rsquo;    SocialNetwork 0:* string À inclure dans le RÉSEAU social indiqué par ce nom. La valeur possible pourrait être \u0026ldquo;facebook.com\u0026rdquo;, \u0026ldquo;linkedin.com\u0026rdquo;, \u0026ldquo;x.com\u0026rdquo; et ainsi de suite.    Description de la structure “PublishToMobileAction”    PublishToMobileAction +Structure Paramètres de publication sur le canal Téléphone Mobile.        ParameterisedAction ParameterisedAction 0:1 +Structure Hérité de ParameterisedAction.\nParameterisedAction : utilisé pour permettre de définir un message à publier sur telephone portable cf 6.7.4.1.7.6\n    Incidents 0:1 boolean Inclure dans les listes de SITUATION sur le site Web mobile. La valeur par défaut est ’true’.    HomePage 0:1 boolean Inclure sur la page d'accueil du site Web mobile. La valeur par défaut est ’false’.    Description de la structure “PublishToDisplayAction”    PublishToDisplayAction +Structure Paramètres pour diffuser sur un afficheur        ParameterisedAction ParameterisedAction 0:1 +Structure Hérité de ParameterisedAction.\nParameterisedAction : Utilisé pour permettre de définir un message à publier sur telephone portable cf 6.7.4.1.7.6\n    OnPlace 0:1 boolean Indique si il s’agit d’un afficheur Sol : Par Défaut 'true'.    Onboard 0:1 boolean Indique si il s’agit d’un afficheur Embarqué :. Par Défaut 'false'.    Description de la structure « NotifyByEmailAction”    NotifyByEmailAction +Structure Paramètres pour diffuser sur le canal Email        ParameterisedAction ParameterisedAction 0:1 +Structure Hérité de ParameterisedAction.\nParameterisedAction : Utilisé pour permettre de définir un message à publier via email cf 6.7.4.1.7.6.\n  PushedActionStructure BeforeNotices 0:1 +Structure Indique si un rappel doit être envoyé, cf lignes ci-dessous.   ➞ Interval 0:* →DurationType Interval avant la date de début auquel envoyer le rappel.   ClearNotice 0:1 Boolean Indique si un avertissement de fin doit être envoyé.    email 0:1 →EmailAddressType Adresse email à laquelle le rappel doit être envoyé.    Description de la structure “NotifyBySmsAction”    NotifyBySmsAction +Structure Paramètres de publication sur le canal SMS       ParameterisedAction ParameterisedAction 0:1 +Structure Hérité de ParameterisedAction.\nParameterisedAction : utilisé pour permettre de définir un message SMS cf 6.7.4.1.7.6.\n  PushedActionStructure BeforeNotices 0:1 +Structure Indique si un rappel doit être envoyé, cf lignes ci-dessous.   ➞ Interval 0:* →DurationType Interval avant la date de début auquel envoyer le rappel.   ClearNotice 0:1 Boolean Indique si un avertissement de fin doit être envoyé.    Phone 0:1 →PhoneType Numéro de téléphone auquel envoyer le rappel.    Premium 0:1 boolean Indique si le contenu est signalé comme soumis à des frais supplémentaires.\nPar défaut 'false'.\n    Description de la structure ‘Affect’    Affects +Structure Périmètre de la SITUATION et de ses consequences.        Level AreaOfInterest 0:1 enum Périmètre géographique  Operators Operators 0:1 +Structure Périmètre niveau OPERATOR   ➞ choix -1:1     a) AllOperators 0:1 empty Tous les OPERATORs sont concernés   b) AffectedOperator 0:* +Structure Annotation pour les opérateurs impactés par la SITUATION (cf 6.7.4.1.7.6.5)  network Networks 0:1 +Structure Identification des réseaux impactés   ➞ AffectedNetwork 1:* +Structure Annotation pour les réseaux impactés par la SITUATION.\nListe des réseaux cibles de l’action de publication (cf 6.7.4.1.7.6.1)\n  Stop StopPoints 0:1 +Structure SCHEDULED STOP POINT (Point d’arrêt planifié) impactés par SITUATION.\nPoints d’arrêt cible de la publication\n   ➞ AffectedStopPoint 1:* +Structure Périmètre des SCHEDULED STOP POINT (Point d’arrêt planifié)\nListe des points d’arrêt cibles de l’action de publication\n  StopPlace StopPlaces 0:1 +Structure STOP PLACEs impactés par SITUATION. Cf lignes ci-dessous.   ➞ AffectedStopPlace 1:* +Structure Annotation pour les STOP PLACE impactés.  Place Places 0:1 +Structure PLACEs impactés par SITUATION. Cf lignes ci-dessous.   ➞ AffectedPlace 1:* +Structure Annotation pour les PLACE.  Journey VehicleJourneys 0:1 +Structure VEHICLE JOURNEYs impactés par une SITUATION. Cf lignes ci-dessous.\nListe des Courses cibles de la publication.\n   ➞ AffectedVehicleJourney 1:* +Structure VEHICLE JOURNEY impacté par SITUATION.\nCourse cible de la publication cf 6.7.4.1.7.6.3\n  Vehicles Vehicles 0:1 +Structure VEHICLEs impactés par une SITUATION. Cf lignes ci-dessous.   ➞ AffectedVehicle 1:* +Structure Annotation pour les VEHICLE impactés.    Exemples d\u0026rsquo;utilisation de la structure \u0026lsquo;Affect\u0026rsquo;\nAssociation avec un ou plusieurs zones d\u0026rsquo;embarquement\n\u0026lt;siri:Affects\u0026gt; \u0026lt;siri:StopPoints\u0026gt; \u0026lt;siri:AffectedStopPoint\u0026gt; \u0026lt;siri:StopPointRef\u0026gt;FR:78197:Quay:3534:LOC\u0026lt;/siri:StopPointRef\u0026gt; \u0026lt;/siri:AffectedStopPoint\u0026gt; \u0026lt;siri:AffectedStopPoint\u0026gt; \u0026lt;siri:StopPointRef\u0026gt;FR:78197:Quay:3535:LOC\u0026lt;/siri:StopPointRef\u0026gt; \u0026lt;/siri:AffectedStopPoint\u0026gt; \u0026lt;/siri:StopPoints\u0026gt; \u0026lt;/siri:Affects\u0026gt; Association avec un ou plusieurs lieux d\u0026rsquo;arrêts\n\u0026lt;siri:Affects\u0026gt; \u0026lt;siri:StopPlaces\u0026gt; \u0026lt;siri:AffectedStopPlace\u0026gt; \u0026lt;siri:StopPlaceRef\u0026gt;FR:78197:StopPlace:3534\u0026lt;:LOC/siri:StopPlaceRef\u0026gt; \u0026lt;/siri:AffectedStopPlace\u0026gt; \u0026lt;siri:AffectedStopPlace\u0026gt; \u0026lt;siri:StopPlaceRef\u0026gt;FR:78197:StopPlace:3535:LOC\u0026lt;/siri:StopPlaceRef\u0026gt; \u0026lt;/siri:AffectedStopPlace\u0026gt; \u0026lt;/siri:StopPoints\u0026gt; \u0026lt;/siri:Affects\u0026gt; Association avec une zone d\u0026rsquo;embarquement mais seulement pour une/des ligne(s) donnée(s)\n\u0026lt;siri:Affects\u0026gt; \u0026lt;siri:StopPoints\u0026gt; \u0026lt;siri:AffectedStopPoint\u0026gt; \u0026lt;siri:StopPointRef\u0026gt;FR:78197:Quay:3534:LOC\u0026lt;/siri:StopPointRef\u0026gt; \u0026lt;siri:Lines\u0026gt; \u0026lt;siri:AffectedLine\u0026gt; \u0026lt;siri:LineRef\u0026gt;FR:78197:Line:00673:LOC\u0026lt;/siri:LineRef\u0026gt; \u0026lt;/siri:AffectedLine\u0026gt; \u0026lt;/siri:Lines\u0026gt; \u0026lt;/siri:AffectedStopPoint\u0026gt; \u0026lt;/siri:StopPoints\u0026gt; \u0026lt;/siri:Affects\u0026gt; Association avec une ou plusieurs lignes\n\u0026lt;/siri:AffectedNetwork\u0026gt; \u0026lt;siri:AffectedLine\u0026gt; \u0026lt;siri:LineRef\u0026gt;FR:78197:Line:00673:LOC\u0026lt;/siri:LineRef\u0026gt; \u0026lt;/siri:AffectedLine\u0026gt; \u0026lt;siri:AffectedLine\u0026gt; \u0026lt;siri:LineRef\u0026gt;FR:78197:Line:89121:LOC\u0026lt;/siri:LineRef\u0026gt; \u0026lt;/siri:AffectedLine\u0026gt; \u0026lt;/siri:AffectedNetwork\u0026gt; Description de la structure AffectedNetwork\n    AffectedNetwork +Structure Périmètre de la perturbation et ses conséquences sur le réseau\nIdentification du/des réseaux sur lesquels publier l’action.\n        Operators AffectedOperator 0:* +Structure Annotation à l’ Operator de services impacté par SITUATION.  Network NetworkRef 0:1 →OperatorCode\n(xsd:NMToken)\n RÉSEAU de la LIGNE concernée. S'il est absent, peut être extrait du contexte\nIdentifiant du réseau (au sens transmodel)\n   NetworkName 0:* nlString Nom du reseau (NETWORK).   RoutesAffected 0:* nlString Description textuelle de l'ensemble des ROUTE affectées.  Mode AffectedModeGroup 0:1 →Group Identification des modes impactés  Lines ➞ choix -1:1  Périmètre de la LINE   a) AllLines 0:1 emptyType Toutes les LINEs du NETWORK sont impactées.   b) SelectedRoutes 0:1 emptyType Sélection des ROUTEs affectées, les informations de niveau LIGNE ne sont pas disponibles.\nCf l'élément RoutesAffected pour la description textuelle.\n   c) AffectedLine 0:* +Structure Lignes du réseau impactées (cf 6.7.4.1.7.6.4).    Description de la structure AffectedStopPoint\n   AffectedStopPoint +Structure Anotation au point d’arrêt topologique impacté par la SITUATION.        Stop StopPointRef 0:1 →StopPointCode\n(xsd:NMTOKEN)\n Points d’arrêt concernés par la publication.\nIdentifiant de SCHEDULED STOP POINT (Point d’arrêt planifié).\nIdentifiant de Point d’arrêt.\n  Modes AffectedModes 0:1  MODE impactés.   ➞ choix -1:1     a) AllModes 0:1 emptyType Tous les modes du SCHEDULED STOP POINT (Point d’arrêt planifié) sont impactés.   b) Mode 0:* →AffectedModeGroup Modes impactés par la SITUATION.  Zone PlaceRef 0:1 →ZoneRefStructure\n(xsd:NMTOKEN)\n Identifiant du Lieu où se situe le SCHEDULED STOP STOP (Point d’arrêt planifié)   PlaceName 0:* nlString Nom du lieu où se situe le SCHEDULED STOP STOP (Point d’arrêt planifié).    AccessibilityAssessment 0:1 +Structure ACCESSIBILITY ACCESSMENT pour le SCHEDULED STOP POINT (Point d’arrêt planifié).    StopCondition 0:* RoutePointTypeEnumeration Etat du SCHEDULED STOP POINT (Point d’arrêt planifié).\nPlusieurs condtions peuvent être valident en même temps.\n    ConnectionLinks 0:1 many CONNECTION links du SCHEDULED STOP POINT (Point d’arrêt planifié) impactés par la SITUATION.   ➞ AffectedConnectionLink 0:* +Structure Annotation au CONNECTION link impactée par la SITUATION.    Description de la structure AffectedVehicleJourney\n    AffectedVehicleJourney +Structure Annotation à la course référencée impactée par la SITUATION.\nCourses cibles de l’action de publication.\n         choix -1:1  Identifiant d’une course impactée   b) VehicleJourneyRef 1:* →VehicleJourneyCode\n(xsd:NMTOKEN) Identifiant de course (au sens Transmodel)    Description de la structure “AffectedLine”\n   AffectedLine +Structure Annotation à la LINE impactée par la SITUATION.        Line LineRef 1:1 →LineCode\n(xsd:NMTOKEN)\n Identifiant de ligne (LINE).  Destination Destinations 0:*  DESTINATIONs impactée.   ➞ AffectedStopPoint 0:1 +Structure Point d’arrêt impacté par SITUATION.  Direction Direction 0:* +Structure DIRECTIONs impactées.   ➞ DirectionRef 0:1 →DirectionCode\n(xsd:NMTOKEN)\n Identifiant de DIRECTION.   ➞ DirectionName 0:* nlString Nom de DIRECTION.    Description de la structure « AffectedOperator”\n    AffectedOperator +Structure Périmètre de la perturbation et ses conséquences sur le réseau\nIdentification du/des opérateurs sur lesquels publier l’action.\n       Operator OperatorRef 0:1 →OperatorCode Identifiant de l’operateur (au sens transmodel).    Description de la structure ParameterisedAction    ParameterisedAction +Structure                  SimpleActionStructure ActionStatus 0:1 enum Status de l’Action. cf 6.7.4.1.7.7.1.     Description 0:1 nlString Description de l’action.     ActionData 0:* +Structure Information associée à l’action, cf lignes ci-dessous.     ➞ Name 0:1 xsd:NMTOKEN Nom de l’action.     ➞ Type 1:1 xsd:NMTOKEN Type de données de l’action.     ➞ Value 0:* any Valeur pour l’action.     ➞Prompt 0:* nlString Libéllé du message associé au publishingAction.     ➞PublishAtScope** 0:1 +Structure Zone de diffusion du message ‘Prompt’.     ⇉ ScopeType 1:1 enum Type de l’action (cf 6.7.4.1.5).     ⇉ Affects 1:1 +Structure Zone de diffusion du message ‘prompt’, cf 6.7.4.1.7.6.     PublicationWindow 0:* →ClosedTimestampRangeStructure Définit un certain nombre de fenêtres temporelles de publication. Lorsqu\u0026rsquo;il n\u0026rsquo;est pas envoyé, les fenêtres temporelles de publication de niveau supérieur sont valides. Peut être remplacé par un niveau inférieur.     ➞StartTime 1:1 xsd:dateTime Le timestamp du début de publication (inclusif)     ➞EndTime 1:1 xsd:dateTime Le timestamp de la fin de publication (inclusif)     Description de l’enum ‘ActionStatus’\nLes valeurs retenues par le profil SIRI France sont les suivantes :\n   Value Description     open Action ouverte non publiée.   published Action publiée.   closed Action close.    Eléments techniques des messages En-têtes des requêtes Structure générale des requêtes    ServiceRequest +Structure Structure générale des requêtes                log Request­Timestamp 1:1 xsd:dateTime Date d’émission de la requête.   Endpoint Properties Address 0:1 Endpoint­Address Adresse réseau de destination de la réponse (ici une URL dans le cadre d’une implémentation SOAP).    Requestor­Ref 1:1 Participant­Code Identifiant du demandeur (reprendre la structure [fournisseur] des identifiants).    Message­Identifier 1:1 Message­Qualifier Identifiant unique de ce message.   Payload Concrete service subscription -1:1 choix Si la suite contient plusieurs réponses, elles doivent toutes être du même type.    a) Production­Timetable­Request 0:1 +Structure Voir SIRI Partie 3 – Production Timetable.    b) Estimated­Timetable­Request 0:1 +Structure Voir SIRI Partie 3 – Estimated Timetable.    d) StopMonitoring­Request 0:1 +Structure Voir SIRI Partie 3 – Stop Monitoring.    f) Vehicle­Monitoring­Request 0:1 +Structure Voir SIRI Part 3 – Vehicle Monitoring.    h) Connection­Monitoring­Request 0:1 +Structure Voir SIRI Partie 3 – Connection Monitoring.    i) General­Message­Request 0:1 +Structure Voir SIRI Partie 3 – General Message.    j) FacilityMonitoring­Request 0:1 +Structure Voir SIRI Partie 4 – Facility Monitoring. SIRI .    k) SituationExchange­Request 0:1 +Structure Voir SIRI Partie 5 – Situation Exchange. SIRI .    Contexte générique des requêtes La structure ci-dessous n’est pas échangée, mais son contenu doit être connu des différents protagonistes (définition par le profil et dans le cadre du protocole d’accord). Cette structure propose une séparation très fine des différentes notions, mais sera généralement utilisée de façon très simplifiée.\n   ServiceRequestContext +Structure Propriétés générales des requêtes.        Server Endpoint Address Check­Status­Address 0:1 Endpoint­Address Adresse (URL) de destination du CheckStatus.   Subscribe­Address 0:1 Endpoint­Address Adresse (URL) de destination des demandes d’abonnement.   Manage­Subscription­Address 0:1 Endpoint­Address Adresse (URL) de destination pour la gestion des abonnements déjà établis (interruption, …).   Get­Data­Address 0:1 Endpoint­Address Adresse (URL) de destination des réponses aux requêtes.  Client End­point Address Status­Response­Address 0:1 Endpoint­Address Adresse (URL) de destination des réponses aux CheckStatus.   Subscriber­Address 0:1 Endpoint­Address Adresse (URL) de destination des réponses aux demandes de notification.   Notify­Address 0:1 Endpoint­Address Adresse (URL) de destination des notifications.   Consumer­Address 0:1 Endpoint­Address Adresse (URL) de destination des données.  Location choix -1:1  Format des coordonnées géographiques   a) Wgs­Decimal­Degrees 0:1 EmptyType Les coordonnées Géospatiales sont données en latitude et longitude WGS84, en degré décimal de l’arc.   b) Gml­Coordinate­Format 0:1 srsName­Type Nom du format de coordonnées GML utilisé dans la réponse pour les points géospatiaux.\nLes deux formats sont autorisés en France (note : il existe de nombreux outils libres permettant de convertir les coordonnées d’un référentiel à l’autre).\n  Temporal Span Data­Horizon 0:1 Positive­Duration­Type Durée maximale de l’horizon de données des requêtes.   Request­Timeout 0:1 Positive­Duration­Type Délai à partir duquel on peut considérer qu’une requête ne sera plus traitée (par défaut 1 minute).  Delivery Method Delivery­Method 0:1 fetch | direct Abonnement à une phase (voir en début de document) uniquement : donc direct.   Multipart­Despatch 0:1 xsd:boolean Autorisation de segmentation des messages : Non dans le profil France.   Confirm­Receipt 0:1 xsd:boolean Confirmation des réceptions: Non dans le profil France.  Resource Use Maximum­Number­Of­Subscriptions 0:1 xsd:positive­Integer Nombre maximal d’abonnements pour un unique abonné (par défaut non limité).  any Extensions 0:1 any Emplacement pour extension utilisateur (cf 5.4.2.2).    En-têtes des réponses Structure générique des réponses Note : Cette structure n\u0026rsquo;est pas utilisée dans le cadre des échanges SOAP (point de départ avec xxxDelivery).\n   ServiceDelivery +Structure Structure générique de réponse aux requêtes.                Attrib­utes srsName 0:1 xsd:string Identifiant du système de projection (pour la localisation spatiale) : probablement Lambert 2 étendu (soit EPSG:27582 -NTF(Paris)/Lambert II étendu).   Log Response­Timestamp 1:1 xsd:dateTime Heure de production de la réponse.   End­­poi­nt proper­ties ProducerRef 0:1 Participant­Code Identifiant du producteur de la réponse (reprendre le code [fournisseur] des identifiants du profil FR)    Response­Message­Identifier 1:1 Message­Qualifier Identifiant unique du message de réponse.    Request­Message­Ref 1:1 Message­Qualifier Identifiant de la requête à laquelle on répond.   Status Status 1:1 xsd:boolean Indique si la requête a pu être traitée avec succès ou non.    Error­Condition 0:1 See below Signalement d’erreur (voir le paragraphe sur la gestion des erreurs).    ➞ choix -1:1      a) Capability­Not­Supported­Error 0:1 +Error Requête non supportée.    b) OtherError 0:1 +Error Autre erreur.    ➞ Description 0:1 ErrorDescription Description de l’erreur .   Payload ➞ choix -1:1  Plusieurs des structures suivantes peuvent se succéder, mais elles doivent être toutes du même type.    a) Production­Timetable­Delivery 0:* +Structure Voir SIRI Partie 3 – Production Timetable.    b) Estimated­Timetable­Delivery 0:* +Structure Voir SIRI Partie 3 – Estimated Timetable.    d) Stop­Monitoring­Delivery 0:* +Structure Voir SIRI Partie 3 – Stop Monitoring.    e) Vehicle­Monitoring­Delivery 0:* +Structure Voir SIRI Partie 3 – Vehicle Monitoring.    g) Connection­Monitoring­Feeder­Delivery 0:* +Structure Voir SIRI Partie 3 – Connection Monitoring.    h) Connection­Monitoring­Distributor­Delivery 0:* +Structure Voir SIRI Partie 3 – Connection Monitoring.    i) General­Message­Delivery 0:* +Structure Voir SIRI Partie 3 – General Message.    j) FacilityMonitoring­Delivery 0:* +Structure Voir SIRI Partie 4 – Facility Monitoring.    k) SituationExchange­ Delivery 0:* +Structure Voir SIRI Partie 5 – Situation Exchange.    Structure des réponses aux services    xxxDelivery +Structure Structure générique des réponses aux services                Log Response­Timestamp 1:1 xsd:dateTime Date et heure de production de la réponse.   Endpoint properties Request­Message­Ref 1:1 Message­Qualifier Référence de la requête.    SubscriberRef 0:1 Participant­Code Identification du souscripteur. Obligatoire en cas d’abonnement.    Subscription­Ref 1:1 Subscription­Qualifier Identification de la souscription. Obligatoire en cas d’abonnement.   Status Status 1:1 xsd:boolean Indique si la requête a pu être traitée avec succès ou non.    ErrorCondition 1:1 xsd:dateTime Date et heure de production de la réponse.    ➞ choix -1:1  Choix parmi les codes d’erreur.    a) ServiceNotAvailableError 0:1  Le service fonctionnel n’est pas disponible (mais il est toujours capable de donner une réponse).    b) Capability­Not­Supported­Error 0:1 +Error Fonction non supportée.    c) Access­Not­Allowed­Error 0:1 +Error Accès refusé.    d) InvalidDataReferencesError 0:1 +Error La requête contient des références à des identifiants qui ne sont pas connus.    e) BeyondDataHorizon 0:1 +Error La période ou la souscription est en dehors de la période couvert par le service.    f) No­Info­For­Topic­Error 0:1 +Error Pas d’information pour cette requête.    g) ParametersIgnoredError 0:1 +Error La requête contient des paramètres qui ne sont pas supportés par le producteur. Une réponse a été fournie mais certains paramètres ont été ignorés.    h) UnknownExtensionsError 0:1 +Error La requête contient des extensions qui ne sont pas supportés par le producteur. Une réponse a été fournie mais certains paramètres ont été ignorés.    i) Allowed­Resource­Usage­Exceeded­Error 0:1 +Error Réponse trop volumineuse.    j) OtherError 0:1 +Error Autre erreur.    ➞ Description 0:1 Error­Description Description de l’erreur.    ValidUntil 0:1 xsd:dateTime Date de validité maximale de la réponse.    Shortest­Possible­Cycle 0:1 Positive­Duration­Type Intervalle minimal de mise à jour de la donnée.   any Extensions 0:1 any Emplacement pour extension utilisateur (cf 5.4.2.2)    Abonnement Structure générale des abonnements    SubscriptionRequest +Structure Structure générale de requêtes d’abonnement                Log Request­Timestamp 1:1 xsd:dateTime Date de la requête d’abonnement.   End­point properties Address 0:1 Endpoint­Address Adresse de destination de la réponse à la demande d’abonnement (accepté ou non).    RequestorRef 1:1 Participant­Code Identifiant du demandeur de la réponse (reprendre le code [fournisseur] des identifiants du profil FR).    Message­Identifier 1:1 Message­Qualifier Identifiant unique de la requête de souscription (utilisé dans la réponse).    Consumer­Address 0:1 Endpoint­Address Adresse (URL) de destination des notifications.    Subscription­Filter­Identifier 0:1 xsd:NMTOKEN Identification d’un canal d’abonnement qui permettra de grouper plusieurs requêtes d’abonnement (canal par défaut, non nommé si le champ n’est pas présent).   Pay­load Concrete service subscription: -1:1 choix Plusieurs des structures suivantes peuvent se succéder, mais elles doivent être toutes du même type.    a) Production­Timetable­Subscription­Request 0:* +Structure Voir SIRI Partie 3 - Production Timetable.    b) Estimated­Timetable­Subscription­Request 0:* +Structure Voir SIRI Partie 3- Estimated Timetable.    d) Stop­Monitoring­Subscription­Request 0:* +Structure Voir SIRI Partie 3 - Stop Monitoring.    e) Vehicle­Monitoring­Subscription­Request 0:* +Structure Voir SIRI Partie 3 - Vehicle Monitoring.    g) Connection­Monitoring­Subscription­Request 0:* +Structure Voir SIRI Part 3 - Connection Monitoring.    h) General­Message­Subscription­Request 0:* +Structure Voir SIRI Partie 3 – General Message.    i) FacilityMonitoring­ Subscription­­Request 0:* +Structure Voir SIRI Partie 4 - Facility Monitoring.    j) SituationExchange­ Subscription­­Request 0:* +Structure Voir SIRI Partie 5 – Situation Exchange.    Réponse aux requêtes d’abonnement    SubscriptionResponse +Structure Réponse à une demande d’abonnement.     Log Response­Timestamp 1:1 xsd:dateTime Date et heure de production de la réponse.  End­point prop­erties Address 0:1 Endpoint­Address Adresse pour la gestion ultérieure de l’abonnement.   Responder­Ref 1:1 Participant­Code Identifiant du système répondant (reprendre le code [fournisseur] des identifiants du profil FR).   Request­Message­Ref 1:1 Message­Qualifier Identifiant unique du message (de cette réponse).  Pay­load Response­Status 1:* +Structure Statut de la réponse (en erreur et donc refusée, ou Ok).   SubscriptionManagerAddress 0:1 Endpoint­Address Adresse du gestionnaire d’abonnement si différent de celle du producteur ou de celle connue par défaut.   Service­Started­Time 0:1 xsd:dateTime Heure à laquelle le service fournissant l’abonnement a été démarré pour la dernière fois. Ce champ peut être utilisé pour détecter un redémarrage. S’il est absent, l’adresse est inconnue.\nDans le cas du profil France, le responsable des abonnements devra les mémoriser et les réactiver automatiquement au redémarrage, ce champ n’est donc pas utile dans le cas classique.\nCe champ sera utilisé dans le cas des échanges avec les concentrateurs pour superviser les connexions d'abonnement.\n  any Extensions 0:1 any Emplacement pour extension utilisateur (cf 5.4.2.2)    Qualificateur (état) de réponse    Response­Status +Structure Qualificateur des réponses.        Log Response­Timestamp 0:1 xsd:dateTime Date de création de ce statut de réponse.  End­point Request­Message­Ref 1:1 Message­Qualifier Référence de la requête.   Subscriber­Ref 1:1 Participant­Code Identification du souscripteur.   Subscription FilterRef 0:1 SubscriptionFilterRef Référence au filtre utilisé dans l'abonnement et auquel la réponse correspond.\nPeut être omis si un seul filtre est associé à l'abonnement.\n   Subscription­Ref 1:1 Subscription­Qualifier Identification de la souscription.  Pay­load Status 1:1 xsd:boolean Indique si la requête a été traitée normalement ou pas.   Error­Condition 0:1 +Structure Signalement d’erreur (voir le paragraphe sur la gestion des erreurs).   ➞ choix –1:1     Capability­Not­Supported­Error\n  0:1 +Error Fonction non supportée.   AccessNot­AllowedError\n  0:1 +Error Accès refusé.   No­Info­For­TopicError\n  0:1 +Error Pas d’information pour cette requête.   d) Allowed­Resource­Usage­Exceeded­Error 0:1 +Error Réponse trop volumineuse.   e) OtherError 0:1 +Error Autre erreur.   ➞ Description 0:1 Error­Description Description de l’erreur.  Info ValidUntil 0:1 xsd:dateTime Date de validité maximale de la réponse.   Shortest­Possible­Cycle 0:1 Positive­Duration­Type Intervalle minimal de mise à jour de la donnée.    Requête de cloture d’abonnement    TerminateSubscriptionRequest +Structure Demande de fin d’abonnement.        Endpoint properties Request­Timestamp 1:1 xsd:dateTime Date de la demande.  End­point prop­erties Address 0:1 EndpointAddress Adresse du souscripteur.   Requestor­Ref 1:1 Participant­Code Identifiant du souscripteur de la réponse (reprendre le code [fournisseur] des identifiants du profil FR).   MessageIdentifier 1:1 Message­Qualifier Identifiant unique du message.  Topic choix –1:1  Au choix:   All\n  0:1 EmptyType Demande de clôture de tous les abonnements.   b) Subscription­Ref 0 :1 Subscription­Qualifier Identifiant de l’abonnement à clôturer.  any Extensions 0:1 any Emplacement pour extension utilisateur (cf 5.4.2.2).    Réponse aux demandes de clôture de souscription    TerminateSubscriptionResponse +Structure Réponse aux demandes de fin de souscription.                Endpoint properties Response­Timestamp 1:1 xsd:dateTime Datation de la réponse.    Responder­Ref 1:1 Participant­Code Identification du système répondant.    Request­Message­Ref 1:1 Message­Qualifier Identification de la requête.   Payload Termination­Response­Status 1:* +Structure Statut de la demande de clôture d’abonnement.    ➞ Response­Timestamp 0:1 xsd:dateTime Heure de réponse (pour l’abonnement ci-dessous).    ➞ Subscriber­Ref 0:1 Participant­Code Identifiant du souscripteur.    ➞ Subscription­Ref 1:1 Subscription­Qualifier Identifiant de la souscription.    ➞ Status 1:1 xsd:boolean Indique si la souscription a bien pu être close    ➞ Error­Condition 0:1 +Structure Signale une éventuelle erreur.    ⇉ choix -1 :1  Au choix :    a) Capability­Not­Supported­Error 0:1 +Error Fonction non supportée.    b) Unknown­Subscriber­Error 0:1 +Error Souscripteur inconnu.    c) Unknown­Subscription­Error 0:1 +Error Souscription inconnue.    d) OtherError 0:1 +Error Autre erreur.    ⇉ Description 0:1 Error­Description Description de l’erreur.   any Extensions 0:1 any Emplacement pour extension utilisateur (cf 5.4.2.2).    Notification de clôture de souscription    SubscriptionTerminatedNotification +Structure Notification permettant au producteur de données de signaller l\u0026rsquo;interruption d\u0026rsquo;un ou plusieurs abonnement en cours      Log Response­Timestamp 1:1 xsd:dateTime Date et Heure de production de la réponse.    End­point ProducerRef 0:1 Participant­Code Identifiant du producteur de la réponse (reprendre le code [fournisseur] des identifiants du profil).   Response­Message­Identifier 1:1 Message­Qualifier Identifiant unique du message de réponse.   Request­Message­Ref 1:1 Message­Qualifier Identifiant de la requête à laquelle on répond.  Sub­scription Subscriber­Ref 0:1 Participant­Code Identification du souscripteur.   SubscriptionFilterRef 0:1 SubscriptionFilterRef Référence au filtre utilisé dans l'abonnement et auquel la réponse correspond.\nPeut être omis si un seul filtre est associé à l'abonnement.\n   Subscription­Ref 1:1 Subscription­Qualifier Identification de la souscription.   Error­Condition 0:1 See below Signalement d’erreur (voir le paragraphe sur la gestion des erreurs).   Choix -1:1     a) OtherError 0:1 +Error Autre erreur.   b) Description 0:1 Error­Description Description de l’erreur.  any Extensions 0:1 xsd:any Emplacement pour extension utilisateur (cf 5.4.2.2)    Vérification de l’état des partenaires (service Check Status) Requête de vérification d\u0026rsquo;état    CheckStatusRequest +Structure Requête de vérification d’état                Log Request­Timestamp 1:1 xsd:dateTime Date et heure de la requête.   Endpoint Address 0:1 Endpoint­Address Adresse (URL) de destination de la requête.    RequestorRef 1:1 Participant­Code. Identifiant du demandeur.   Identity MessageIdentifier 1:1 Message­Qualifier Identifiant de la requête.   any Extensions 0:1 any Emplacement pour extension utilisateur (cf 5.4.2.2)    Réponse aux requêtes de vérification d\u0026rsquo;état    CheckStatusResponse +Structure Réponses aux requêtes de vérification d’état.                Log Response­Timestamp 1:1 xsd:dateTime: Datation de la réponse.   End­point ProducerRef 1:1 Participant­Code Identification du répondant.    Response­Message­Identifier 1:1 Message­Qualifier Identifiant unique du message de réponse.    Request­Message­Ref 1:1 MessageQualifier Identifiant de la requête à laquelle on répond.   Payload Status 1:1 xsd boolean Signale si le système est bien disponible.    Error­Condition 0:1 +Structure Signalement d’erreur.    ➞ Choix –1:1  Au choix :    a) Service­Not­Available­Error 0:1 +Error Service indisponible.    c) OtherError 0:1 +Error Autre erreur.    ➞ Description 0:1 Error­Description Description de l’erreur.    ServiceStarted­Time 0:1 xsd:date­Time: Dernière date et heure de mise en marche du système.   any Extensions 0:1 any Emplacement pour extension utilisateur (cf 5.4.2.2)    Annexe A Termes et définitions     AVMS Automated Vehicle Management System – Système automatisé de gestion de véhicules.  DMZ DeMilitarised Zone - Zone tampon d'un réseau d'entreprise, située entre le réseau local et Internet, derrière le coupe-feu, qui correspond à un réseau intermédiaire regroupant des serveurs publics (HTTP, SMTP, FTP, DNS, etc.), et dont le but est d'éviter toute connexion directe avec le réseau interne et de prévenir celui-ci de toute attaque extérieure depuis le Web.  FIREWALL Porte coupe-feu. Système de sécurité anti-intrusion permettant une protection des réseaux informatiques internes de l’entreprise contre les intrusions du monde extérieur, en particulier les piratages informatiques.  HTML Hyper Text Markup Language - langage de programmation utilisé pour créer des documents hypertexte.  HTTP HyperText Transfer Protocol - Le protocole technique utilisé sur le Web pour transférer des fichiers au cours d'une séance entre le serveur et l'utilisateur.  HTTPS HyperText Transfer Protocol Secured – Protocole Web sécurisé.  PMR Personne à Mobilité Réduite  QUAY Zone d’embarquement. Peut être constituée de positions d’embarquement  RER Réseau Express Régional. Le RER est un réseau de transport en commun urbain propre à la région parisienne.  RTC Réseau Téléphonique Commuté. Désigne le réseau téléphonique actuellement en place, utilisant des autocommutateurs pendant l’établissement des communications.  SERVEUR Processus ayant un ou plusieurs threads et qui reçoit des demandes de processus. Il implémente un ensemble de services et les met à la disposition de clients tournant sur le même ordinateur, ou sur divers ordinateurs dans un réseau distribué.  SAE Système d’Aide à l’Exploitation  SAEIV Système d'Aide à l'Exploitation et d’Information Voyageurs\npour véhicules de transport en commun  SIRI Service Interface for Realtime Information – Norme de diffusion des données temps réel dans le domaine du transport.  SIV Système d’Information Voyageurs  SMS Short Message System- Message de 130 caractères au maximum qui transite entre les pagers ou les téléphones portables.  SOAP Simple Object Access Protocol - Protocole fondé sur XML pour l'échange d'informations en environnement décentralisé.\nCe protocole qui fait l'objet d'une recommandation de la part du W3C, est couramment utilisé pour établir un canal de communication entre services web (invocation à distance via Internet de traitements informatiques). Il détaille 3 parties :\n- l'enveloppe qui dessine les contours du message et en décrit le contenu,\n- les règles d'encodage des données et types de données,\n- les conventions du protocole d’échange qui permettent de définir les procédures d'invocation et de réponse à distance.\nSOAP peut être utilisé au-dessus de nombreux protocoles de transport dont HTTP.\n  TRANSMODEL Norme européenne - Modélisation conceptuelle de l’ensemble des notions utiles au transport en commun (définition des concepts, des objets et de leurs relations)  TRIDENT TRansport Intermodality Data sharing and Exchange. NeTwork – Format d’échanges de données au format XML dans le domaine du transport\nDans le cadre du profil, elle est utilisée essentiellement pour la partie qui concerne l’échange de la description des réseaux, des correspondances et des horaires théoriques.\n  UML Unify Model Language - Langage d'analyse et de conception orienté objet défini par l'OMG (Object Management Group). UML homogénéise les représentations graphiques des objets issues des travaux de Grady Booch chez Rational Software, de Rumbaugh et d'Ivar Jacobson.  URL Uniform Resource Location - Adresse Internet reconnue par les navigateurs, qui leur permet d’appeler n’importe quelle page ou document.  VPN Virtual Private Network. Réseau privé virtuel composé d'ordinateurs qui ne constituent pas un seul et même réseau à la base, mais qui peuvent être distants géographiquement.  WEB \"toile d'araignée\" composée des pages HTML reliées entre elles par un réseau complexe de liens *hypertexte.  WSDL Web Services Definition Language - WSDL est une tentative de normalisation du W3C suite à une proposition d'IBM, Microsoft et Ariba.\nWSDL met en oeuvre XML pour décrire, de manière indépendante de la plate-forme et du langage, la façon dont les applications peuvent accéder à un service web.\n  XML eXtended Markup Language - Langage de description des documents qui utilise des balises, permet l'utilisation de balises personnalisées et permet l'échange des données.    Annexe B (informative) Production TimeTable Requête d’information sur les horaires commandés/théoriques    ProductionTimetable­Request +Structure Requête d’information sur les horaires commandés/théoriques       Attributes Version 1:1 VersionString Version du service “ ProductionTimetable ”, intégrant le numéro de version de profil (voir 5.9)     Endpoint Properties Request­Timestamp 1:1 xsd:dateTime Date d\u0026rsquo;émission de la requête.    Message­Identifier 1:1 Message­Qualifier Numéro d\u0026rsquo;identification du message.   Line Topic Validity­Period 1:1 ClosedDate­Range­Structure Période pour laquelle on souhaite avoir des informations horaires.    ➞ Start 1:1 xsd:dateTime Date et heure de début de période.    ➞ End 1:1 xsd:dateTime Date et heure de fin de période.    Timetable­Version­Ref 0:1 xsd:string Version du référentiel théorique connue : seuls les écarts par rapport à ce référentiel seront transmis (ce champ ne sera utilisable qu’à partir de la mise en œuvre du référentiel régional)    Operator­Ref 0:* → Operator­Code Identifie le ou les exploitants pour lesquel on souhaite obtenir des informations*.*    Lines       ➞ LineDirection       ⮆ LineRef 0:1 → LineCode Identifie la ligne pour laquelle on souhaite obtenir des informations.   Policy Incremental­Updates 0:1 xsd:boolean Indique si l’on souhaite ne disposer que des écarts par rapport aux données théoriques, ou de l’ensemble des informations sur la période.       Emplacement pour extension utilisateur (cf 5.4.2.2).    Note : En fournissant des dates de début et de fin de période, on pourra obtenir en réponse des modifications horaires sur toute la période ; en retour SIRI fournira des « DatedVehicleJourney », c\u0026rsquo;est-à-dire des descriptions de courses valables pour un jour d’application donné (on n’a pas, dans ce cas, de description d’une part des courses et d’autre part des jours d’application). En d’autres termes, si la période demandée couvre deux jours, et qu’une course est active sur ces deux jours, la réponse comportera ces deux courses. La différence s’établit au niveau des heures de départ et d’arrivée indiquées par les éléments « Call » : ces heures sont en effet de type « DateTime » et comportent donc à la fois le jour et l’heure.\nAbonnement aux informations sur les horaires commandés/théoriques    ProductionTimetable­SubscriptionRequest +Structure Requête pour un abonnement au service SIRI Production Timetable Service.        Identity SubscriberRef 0:1 → Participant­Code Identification du système demandeur (voir SIRI Part 2 Common SubscriptionRequest parameters.)      Subscription­Identifier 1:1 Subscription­Qualifier Identifiant de l\u0026rsquo;abonnement pour le système demandeur.   Lease Initial­Termination­Time 1:1 xsd:dateTIme Date et heure de fin de l\u0026rsquo;abonnement : un abonnement a forcément une date et heure de fin (les partenaires pourront décider de limiter la durée maximale d’un abonnement).   Request Production­Timetable­Request 1:1 +Structure Voir ProductionTimetable­Request.     Réponse aux requêtes d’informations sur les horaires commandés/théoriques    Production­Timetable­Delivery +Structure Description des horaires sur la période        Attributes version 1:1 VersionString Numéro de version du service Production Timetable, intégrant le numéro de version de profil (valeur fixe).     LEADER :: 1:1 xxx­Delivery Voir paragraphe 2.2.   Payload Dated­Timetable­Version­Frame 0:* +Structure Voir DatedTimetableVersionFrame element.            Structure DatedTimetableVersionFrame    DatedTimetableVersionFrame +Structure Fournit les courses applicables pour un itinéraire      Log Recorded­AtTime 1:1 xsd:dateTime Date et heure auxquelles ces données ont été produites.    Line LineRef 1:1 LineCode Identifiant de la ligne.   DirectionRef 1:1 Direction­Code Identifie la direction (typiquement Aller/Retour).\nLa sélection de ce champ n’est pas dans la logique du reste du profil (plutôt porté par Destination, voir plus bas) mais est maintenue du fait de la cardinalité imposée par SIRI.\n  Journ­eys Dated­Vehicle­Journey 0:* +Structure Description des horaires de la course.    Structure DatedVehicleJourney    DatedVehicleJourney +Structure Description de la course      Vehicle Journey Identity choix -1:1       Dated­Vehicle­Journey­Code 0:1 → Vehicle­Journey­Code Identifie la course datée.   Framed-Vehicle-JourneyRef 0:1 +Structure Identifie la course datée.\nCette version permet de préciser la version de jeu de données associé et est recommandée à partir de SIRI 2 (et doc du profil 2.4). Le mécanisme de choix placé ici permet d'assurer la compatibilité ascendante.\n   ExtraJourney 0:1 xsd:boolean Signale qu’il s’agit d’une nouvelle course, ajoutée par rapport aux horaires théoriques.\nValeur par défaut : « false»\n   Cancellation 0:1 xsd:boolean Signale la suppression de la course identifiée.\nValeur par défaut : « false»\n  Journey Pattern Info ::: 0:1 Journey­Pattern­Info­Group Voir Journey­Pattern­Info­Group.  Service Info ::: 0:1 Service­Info­Group Voir ServiceInfo­Group.  Journey Info Vehicle­Journey­Name 0:1 NLString Nom commercial de la course.  Notes Destination­Display 0:1 NLString Destination telle qu'elle est affichée sur la girouette du véhicule à cet arrêt (ou sur l’afficheur local).        Timetable­info Headway­Service 0:1 xsd:boolean Indique si la course est gérée dans un contexte d’exploitation (ou d’information seulement) en fréquence.\nValeur par défaut : « false»\n  Real-time Info Monitored 0:1 xsd:boolean Signale si les données temps réel sont disponibles pour cette course (« false » permet de signaler une délocalisation).\nValeur par défaut : « true»\n        Children Dated­Calls 1:1 +Structure Description ordonnée des points d’arrêts et heures de passage.   ➞ Dated­Call 2:* +Structure Voir DatedCall    Structure DatedCall    DatedCall +Structure Information et heures de passage à l’arrêt      Stop Identity StopPoint­Ref 1:1 → StopPoint­Code Il convient d'utiliser ici un identifiant d'objet issu du profil NeTex Fr (Lieu d’arrêt mono ou multimodal, zone d'embarquement): granularité la plus fine possible dans tous les cas.     Order 0:1 xsd:positive­Integer Numéro d'ordre de l'arrêt dans la mission.   StopPoint­Name 0:1 NLString Nom du point d'arrêt (cf 2.2).\nSi plusieurs noms sont disponibles chez le producteur, le nom le plus détaillé sera utilisé en priorité.\n  Service Info Destination­Display 0:1 NLString Destination telle qu'elle est affichée sur la girouette du véhicule à cet arrêt (ou sur l’afficheur local).  Arrival Aimed­Arrival­Time 0:1 xsd:dateTime Date et heure d'arrivée théorique (ou commandée)   Arrival­Platform­Name 0:1 NLString Identification ou nom du quai d'arrivée.   ➞ Aimed­­QuayName 0:1 NLString Indication de la voie d'arrivée (en complément de Platform).   Departure Aimed­Departure­Time 0:1 xsd:dateTime Date et heure de départ théorique (ou commandée).   Departure­Platform­Name 0:1 NLString Identification ou nom du quai de départ.   Departure­Boarding­Activity 0:1 boarding | noBoarding| passthru Caractérisation de l'horaire de départ attendu (ou mesuré si le véhicule est à quai).  Headway Aimed­Headway­Interval 0:1 Positive­DurationType Fréquence de passage théorique (ou commandée).  Interchange Targeted­Interchange 0:* +Structure Permet de signaler une correspondance programmée à ce point arrêt (possibilité d’attendre une course arrivant).\nVoir Structure Targeted­Interchange (cf B.7).\n    Structure TargetedInterchange  \nTargeted­Interchange +Structure Description d’une correspondance programmée (description de l’arrivant).       Identity Interchange­Code 0:1 → Inter­change­Code Identification de la correspondance.\nDans le cadre du profil France, si ce paramètre est présent, il sera constitué de la concaténation de l’identifiant de la course de l’arrivant et de celui de la course au départ (séparés par le caractère ‘:’)\n     Distributor­Vehicle­Journey­Ref 1:1 → Dated­Vehicle­Journey­Code Identifie la course de l’arrivant  Connection Distributor­Connection­Link 1:1 +Structure Description du cheminement physique de correspondance.   ➞ Connection­Code 1:1 Connection­Code Identifiant du cheminement physique de correspondance.\nCe champ est obligatoire dans le XSD SIRI, et l’est donc aussi dans le profil France : toutefois s’il n’était pas disponible au niveau du système alimentant, le champ sera fourni, mais laissé vide.\n   ➞ Stop­Point­Ref 0:1 → StopPoint­Code Identifant du point d’arrêt de départ de la correspondance.\nIl convient d'utiliser ici un identifiant d'objet de référence partagé entre les systèmes communiquants (cf 5.4.1.1).\n   ➞ Interchange­Duration 0:1 Positive­Duration­Type Durée de la correspondance (temps « normal » de marche à pied).   ➞ Frequent­Traveller­Duration 0:1 Positive­Duration­Type Durée de la correspondance pour un voyageur habitué.   ➞ Occasional­Traveller­Duration 0:1 Positive­Duration­Type Durée de la correspondance pour un voyageur lent ou ne connaissant pas la correspondance.   ➞ Impaired­Access­Duration 0:1 Positive­Duration­Type Durée de la correspondance pour une personne à mobilité réduite.  Interchange Properties StaySeated 0:1 xsd:boolean « true » signale que la correspondance s’effectue en restant dans le même véhicule.\nValeur par défaut : « false»\n   Guaranteed 0:1 xsd:boolean « true » signale que la correspondance est garantie ou non.\nValeur par défaut : « false»\n  Interchange Times Maximum­Wait­Time 0:1 Positive­Duration­Type Temps maximum qu’attendra le véhicule au départ si l’amenant est en retard.    Bibliographie  ISO 8601, Data elements and interchange formats – Information interchange – Representation of dates and times ISO 639/IETF 1766, Tags for the Identification of Languages ISO/IEC 19501-1:2002, Unified Modelling Language (UML) – Part 1: Specification Normes nationales, enparticulier NEPTUNE, TransXChange, BISON and VDV 452, et d’autres documents comme NOPTIS ERA TAP-TSI: Commission Regulation (EU) No 454/2011 of 5 May 2011 on the technical specification for interoperability relating to the subsystem ‘telematics applications for passenger services’ of the trans-European rail system. UIC recommendations and leaflets XML, Extensible Mark-up Language (XML) 1.0 W3C Recommendation 04 February 2004, available at http://www.w3.org/TR/2004/REC-xml-20040204. Europe on the Move: Commission takes action for clean, competitive and connected mobility https://ec.europa.eu/transport/modes/road/news/2017-05-31-europe-on-the-move_en Commission Delegated Regulation on the provision of EU-wide multimodal travel information service http://ec.europa.eu/info/law/better-regulation/initiatives/c-2017-3574_en Github SIRI disponible sur le lien http://github.com/siri-cen/siri  Accès aux xsd et wsdl SIRI\nDocuments d’accompagnement\n[A1] Description des Cas d’usage du profil SIRI France\n[A2] Règles de gestion dynamique\n[A3] Bonnes Pratiques Implémentation SIRI\n","permalink":"https://deploy-preview-56--transport-normes.netlify.app/normes/siri/profil-france/","summary":"Profil d\u0026rsquo;échange pour la description des informations temps-réel des réseaux de transport en commun\nSIRI - Profil France v1.8\nAvant-propos\nCe document présente de façon détaillée le profil France de SIRI (également appelé « local agreement SIRI France »), soit la déclinaison de la norme SIRI aux besoins métiers français. Il contient tous les éléments nécessaires à sa compréhension, mais ne propose ni une réécriture ni une traduction de l\u0026rsquo;ensemble des documents normatifs SIRI :","title":"SIRI - Profil France v1.8"}]