Avant-propos

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

• pour l’usager, aux fins d’une présentation homogène et compréhensible de l’offre de transport et de l’engagement sous-jacent des organisateurs (autorités organisatrices et opérateurs de transports) ;
• pour les AO, de manière à fédérer des informations homogènes venant de chacun des opérateurs de transports qui travaillent pour elle. L’harmonisation des échanges, et en particulier le présent profil, pourra le cas échéant être imposé par voie contractuelle. Cette homogénéité des formats d’information permet d’envisager la mise en place de systèmes d’information multimodaux, produisant une information globale de l’offre de transports sur un secteur donné, et garantir le fonctionnement des services d’information, en particulier des calculateurs d’itinéraires, et la cohérence des résultats, que ces services soient directement intégrés dans ces systèmes d’information multimodaux ou qu’ils puisent leurs informations sur des bases de données réparties ;
• pour les opérateurs, qui pourront utiliser ce format d’échange pour leurs systèmes de planification, les systèmes d’aide à l’exploitation, leurs systèmes billettiques et leurs systèmes d’information voyageur (information planifiée et information temps réel)
• pour les industriels et développeurs pour pérenniser et fiabiliser leurs investissements sur les formats d’échanges implémentés par les systèmes qu’ils réalisent, tout en limitant fortement l’effort de spécification lié aux formats d’échange

Ce document est le fruit de la collaboration entre les différents partenaires des 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 : “format de référence pour l’échange de données de description des Parkings” (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).

Introduction

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

NeTEx (CEN TS 16614-1, 16614-2 et 16614-3) propose un format et des services d’échange de données de description de l’offre de transport planifiée, basé sur Transmodel (EN 12896). NeTEx permet non seulement d’assurer les échanges pour les systèmes d’information voyageur mais traite aussi l’ensemble des concepts nécessaires en entrée et sortie des systèmes de planification de l’offre (graphiquage, etc.) et des SAE (Systèmes d’Aide à l’Exploitation). NeTEx traite aussi l’ensemble des concepts constituant un point de départ, d’arrivé ou une étape au sein d’un déplacement (POI, Parkings, etc.). Enfin la récente Partie 5 de NeTEx traite des Nouveaux modes de transport (Autopartage, Vélopartage, Covoiturage, VTC, etc.).

NeTEx se décompose en 5 parties:

• Partie 1 : topologie des réseaux (les réseaux, les lignes, les parcours commerciaux les missions commerciales, les arrêts et lieux d’arrêts, les correspondances et les éléments géographiques en se limitant au strict minimum pour l’information voyageur)
• Partie 2 : horaires théoriques (les courses commerciales, les heures de passage graphiquées, les jours types associés ainsi que les versions des horaires)
• Partie 3 : information tarifaire (uniquement à vocation d’information voyageur)
• Partie 4 : profil Européen pour l’information voyageur (EPIP)
• Partie 5 : nouveaux modes de transport (Autopartage, Vélopartage, Covoiturage, VTC, etc.).

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

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

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

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

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

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

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

• détail des services utilisés,
• détails des objets utilisés dans un échange,
• précisions sur les options proposées par la norme,
• précision sur les éléments facultatifs,
• précision sur les codifications à utiliser,
• etc.

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.

D’autre profils de NeTEx sont disponibles (réseau, horaire, tarif). Ils sont tous complémentaires les uns des autres (sans recouvrement) et s’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’est pas détaillée.

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

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

NOTE IMPORTANTE Ce document étant un profil d’é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.

Domaine d’application

Le présent document constitue le profil de la CEN/TS 16614 (NeTEx) pour l’échange de données de description d’arrêt 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’information ainsi que pour leur présentation aux voyageurs.

Références normatives

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

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

CEN/TS 16614-2, Network and Timetable Exchange (NeTEx) — Part 2: Public transport scheduled timetables exchange format

CEN/TS 16614-3, Network and Timetable Exchange (NeTEx) — Part 3: Fare exchange format

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

Termes et définitions

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

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

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

PARKING (parking)

Emplacements désignés pour stationner des véhicules tels que des voitures, des motos et des vélos.

PARKING PROPERTIES (propriété du parking)

PARKING CAPACITY

PARKING ENTRANCE FOR VEHICLES (entrée du parking pour les véhicules)

PARKING PASSENGER ENTRANCE (entrée du parking pour les piétons)

PARKING COMPONENT (composant de Parking)

PARKING AREA (zone de parking)

PARKING BAY (place de stationnement)

Emplacement où l’on peut stationner une (unique) véhicule.

Symboles et abréviations

AO

Autorité Organisatrice de Transports

PMR

Personne à Mobilité Réduite

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

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

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

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

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.

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

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

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

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

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

COMMISSION DELEGATED REGULATION (UE) 2017/1926

Level of service 2

(a) Location search (demand-responsive modes):

(i) Park & Ride stops

(ii) Bike sharing stations

(iii) Car-sharing stations

(iv) Publicly accessible refuelling stations for petrol, diesel, CNG/LNG, hydrogen powered vehicles, charging stations for electric vehicles

(v) Secure bike parking (such as locked bike garages)

(b) 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)

Level of service 3

Special Fare Products: … aggregated products combining different products and add on products such as parking and travel, minimum stay

(b) Information service (all modes):

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

Types of the dynamic travel and traffic data

(iii) Status of access node features (including dynamic platform information, operational lifts/escalators, closed entrances and exit locations — all scheduled modes)

(b) Information service:

Availability of publicly accessible charging stations for electric vehicles and refuelling points for CNG/LNG, hydrogen, petrol and diesel powered vehicles

(c) Availability check:

(i) Car-sharing availability, bike sharing availability

(ii) Car parking spaces available (on and off-street), parking tariffs, road toll tariffs

COMMISSION DELEGATED REGULATION (EU) 2015/962

1. The types of the static road data include in particular:

(i) location of parking places and service areas;

(j) location of charging points for electric vehicles and the conditions for their use;

(k) location of compressed natural gas, liquefied natural gas, liquefied petroleum gas stations;

(l) location of public transport stops and interchange points;

(m) location of delivery areas.

2. The types of the dynamic road status data include in particular:

(l) availability of parking places;

(m) availability of delivery areas;

(n) cost of parking;

(o) availability of charging points for electric vehicles;

Description du profil d’échange

Conventions de représentation

Tableaux d’attributs

NOTE Tous les profils NeTEx partagent les mêmes conventions.

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

• Classification : permet de catégoriser l’attribut. Les principales catégories sont:
  • PK (Public Key) que l’on peut interpréter comme Identifiant Unique: il permet à lui seul d’identifier l’objet, de façon unique, pérenne et non ambiguë. C’est l’identifiant qui sera utilisé pour référencer l’objet dans les relations.
  • AK (Alternate Key) est un identifiant secondaire, généralement utilisé pour la communication, mais qui ne sera pas utilisé dans les relations.
  • FK (Foreign Key) indique que l’attribut contient l’identifiant unique (PK) d’un autre objet avec lequel il est en relation.
  • GROUP est un groupe XML nommé (ensemble d’attributs utilisables dans différents contextes) (voir http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/#AttrGroups )
• Nom : nom de l’élément ou attribut XSD
• Type : type de l’élément ou attribut XSD (pour certains d’entre eux, il conviendra de se référer à la XSD NeTEx)
• Cardinalité : cardinalité de l’élément ou attribut XSD exprimée sous la forme “minimum:maximum” (“0:1” pour au plus une occurrence; “1:*” au moins une occurrence et sans limites de nombre maximal; “1:1” une et une seule occurrence; etc.). Quand le profil modifie la cardinalité NeTEx (champ facultatif rendu obligatoire), cette modification apparait surlignée en Jaune.
• Description : texte de description de l’élément ou attribut XSD (seul les attributs retenus par le profil ont un texte en français; les textes surlignés en jaune indiquent une spécificité du profil par rapport à NeTEx).

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

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

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

Valeurs de code de profil

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

• 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’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’utilisation de VERSION FRAME dans le profil.

Indication des classes abstraites

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

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

• Les super-classes sont signalées dans les en-têtes par le suffixe « (abstrait) »
• Dans les diagrammes UML (comme pour NeTEx et Transmodel), les noms des classes abstraites sont indiqués en italique et les classes abstraites sont de couleur gris clair.
• Certaines super-classes ne sont techniquement pas abstraites dans NeTEx, mais ne sont pas utilisées comme classes concrètes dans le profil : elles sont signalées avec la même convention que les classes abstraites.

Classes de sous-composants

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

Modèle de données

PARKING – Modèle conceptuel

L’objet le plus haut dans l’arbre d’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’un polygone.

Une ZONE peut contenir d’autres ZONEs plus petites. Ceci est exprimé par la relation réflexive sur ZONE et donc un PARKING peut inclure d’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 »).

Une ZONE peut être représentée par un seul POINT (par l’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.

Le deuxième niveau de la hiérarchie est la PLACE, qui représente n’importe quel endroit significatif qu’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.

L’élément de site spécialisé ADDRESSABLE PLACE peut être utilisé pour ajouter l’accessibilité (voir ACCESSIBILITY ASSESMENT dans le Profil Éléments Communs) et d’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’un lieu, tel qu’une station ou un point d’intérêt, y compris ses entrées, niveaux, équipements, cheminements, propriétés d’accessibilité, etc. Le SITE est lui-même spécialisé en STOP PLACE, POINT D’INTERET, PARKING, etc.

Un 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’autres SITE tels que les gares.

Un 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’une taille désignée.

Un PARKING peut avoir des ENTRÉES DE VÉHICULE ainsi que des ENTRÉEs PIETONNEs.

PARKING – Vue détaillée incluant les principaux attributs

Parking

[Code PAYS]:[Code commune INSEE]:[Parking]:[Code parking spécifique]:[Code émetteur du code technique ou LOC], on aura donc :

• [Code PAYS]: Identifiant du Pays en respectant la norme ISO 3166-1 (voir: www.iso.org/iso/country_codes/iso_3166_code_lists.htm, FR pour la France ).
• [Code commune INSEE]: 5 caractères (exemple : 78297 pour Guyancourt), 2 caractères pour le département et 3 pour la commune elle-même en France métropolitaine et 3 2 caractères pour le département et 2 pour la commune elle-même pour l’outre-mer. Ce code commune pourra, de façon optionnelle, être complété par le numéro d’arrondissement de commune précédé d’un « - » (tiret, ASCII code 45) codé sur un ou deux caractères numériques. En cas de mise à jour du code commune par l’INSEE, par souci de pérennité de l’identifiant, on conservera le code attribué initialement (pas de suivi d’un éventuel changement de codification INSEE donc).
• [Type d’objet]: 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’identifiant a été défini de façon locale entre les parties engagées dans l’échange, et qu’il ne fait donc pas partie du référentiel partagé (local, régional, national, etc.) L’utilisation de ce qualificatif est obligatoire quand l’identifiant est local. Pour les objets faisant partie de référentiels partagés on peut le remplacer par un [NomAttributaire] qui le nom (ou code) du système référentiel utilisé pour attribuer l’identifiant.

Exemple FR:75105:Parking:076:LOC

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

Note : 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 ».

Exemple

<Parking id="FR:75105:Parking:076:Qpark" version="2" responsibilitySetRef="FR:ResponsibilitySet:0123:LOC">
  <validityConditions>
    <AvailabilityCondition id="FR:AvailabilityCondition:01:Qpark" version="any">
      <!-- Ouverture semaine et samedi-->
      <IsAvailable>true</IsAvailable>
      <dayTypes>
        <DayType version="any" id="FR:DayType:01:Qpark">
          <properties>
            <PropertyOfDay>
              <DaysOfWeek>Weekdays Weekend</DaysOfWeek>
            </PropertyOfDay>
          </properties>
          <timebands id="FR:timebands:01:Qpark">
            <Timeband id="FR:Timeband:01:Qpark" version="any">
              <StartTime>07:00:00</StartTime>
              <EndTime>20:00:00</EndTime>
            </Timeband>
          </timebands>
        </DayType>
      </dayTypes>
    </AvailabilityCondition>
  </validityConditions>
  <Name>PATRIARCHES</Name>
  <ParkingType>urbanParking</ParkingType>
  <ParkingVehicleTypes>car</ParkingVehicleTypes>
  <ParkingLayout>underground</ParkingLayout>
  <TotalCapacity>334</TotalCapacity>
  <ParkingPaymentProcess>payAtMachineOnFootPriorToExit payAtBay</ParkingPaymentProcess>
  <PaymentMethods>cashAndCard epayDevice contactlessPaymentCard</PaymentMethods>
  <ParkingReservation>noReservations</ParkingReservation>
  <parkingProperties>
    <ParkingProperties id="FR:ParkingProperties:1:Qpark" version="any">
      <ParkingUserTypes>allUsers</ParkingUserTypes>
    </ParkingProperties>
  </parkingProperties>
  <!-- … etc. (ParkingAreas, Entrances …) -->
</Parking>

Composants des Parkings

La ParkingBay correspond à l’emplacement pour garer un véhicule.

ParkingProperties décrit les propriétés générale du PARKING et de ses constituants, à l’exception des caractéristiques de capacité.

ParkingCapacity décrit les caractéristiques de capacité du PARKING et de ses constituants.

Exemple

<ParkingArea id="FR:ParkingArea:76-1:Qpark" version="any">
  <Name>Zone PMR</Name>
  <AccessibilityAssessment version="any" id="FR:AccessibilityAssessment:01:Qpark">
    <MobilityImpairedAccess>true</MobilityImpairedAccess>
  </AccessibilityAssessment>
  <PublicUse>disabledPublicOnly</PublicUse>
  <Label>Zone VERTE</Label>
  <MaximumHeight>190</MaximumHeight>
  <TotalCapacity>7</TotalCapacity>
</ParkingArea>

Entrées des Parkings

ParkingEntranceForVehicle décrit une possibilité d’accès au PARKING depuis la voirie.

ParkingPassengerEntrance décrit une possibilité d’accès au PARKING pour les piétons (incluant les accès type fauteils roulant, etc.).

Exemple

<vehicleEntrances>
  <ParkingEntranceForVehicles id="FR:ParkingEntranceForVehicles:1:Qpark" version="any">
    <Name>Entr&#xE9;e/sortie principale pour les v&#xE9;hicules</Name>
    <Centroid>
      <Location>
        <Longitude>2.3508884</Longitude>
        <Latitude>48.8403437</Latitude>
      </Location>
    </Centroid>
  </ParkingEntranceForVehicles>
</vehicleEntrances>

<ParkingPassengerEntrance id="FR:ParkingPassengerEntrance:1:Qpark" version="any">
  <Name>Entr&#xE9;e pi&#xE9;tone principale</Name>
  <Centroid>
    <Location>
      <Longitude>2.3508884</Longitude>
      <Latitude>48.8403437</Latitude>
    </Location>
  </Centroid>
</ParkingPassengerEntrance>

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.

De plus, le stationnement est souvent au sein d’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’un billet. Le modèle suivant montre comment les TARIFs DE PARKINGs peuvent être décrit avec dans les structures tarifaires de NeTEx.

Tarification des parkings

Le modèle de tarif de stationnement propose une vue simplifiée des tarif NeTEx adaptée aux parkings.

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

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

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

.

Parking Tariff – Conceptual Model

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

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.

Exemple de grille horaire

<ParkingTariff id="FR:75105:ParkingTariff:076:Qpark" version="any">
  <Name>Tarif principal</Name>
  <noticeAssignments>
    <NoticeAssignmentView>
      <Text>Gratuit pour les personnes &#xE0; mobilit&#xE9; r&#xE9;duite</Text>
    </NoticeAssignmentView>
  </noticeAssignments>
  <ParkingUserType>allUsers</ParkingUserType>
  <!--peut prendre des valeurs comme "registered-Disabled"-->
  <appliesTo>
    <ParkingRef ref="FR:75105:Parking:076:Qpark"/>
    <!--Note: plusieurs Parkings peuvent partager la même tarification-->
  </appliesTo>
  <parkingChargeBands>
    <ParkingChargeBand>
      <MaximumStay>PT1H</MaximumStay>
      <prices>
        <TimeIntervalPrice id="FR:TimeIntervalPrice:01:LOC" version="any">
          <Amount>4.4</Amount>
        </TimeIntervalPrice>
      </prices>
    </ParkingChargeBand>
    <ParkingChargeBand>
      <MaximumStay>PT2H</MaximumStay>
      <prices>
        <TimeIntervalPrice id="FR:TimeIntervalPrice:02:LOC" version="any">
          <Amount>7.7</Amount>
        </TimeIntervalPrice>
      </prices>
    </ParkingChargeBand>
    <ParkingChargeBand>
      <MaximumStay>PT3H</MaximumStay>
      <prices>
        <TimeIntervalPrice id="FR:TimeIntervalPrice:03:LOC" version="any">
          <Amount>12.1</Amount>
        </TimeIntervalPrice>
      </prices>
    </ParkingChargeBand>
    <ParkingChargeBand>
      <MaximumStay>PT4H</MaximumStay>
      <prices>
        <TimeIntervalPrice id="FR:TimeIntervalPrice:04:LOC" version="any">
          <Amount>16.5</Amount>
        </TimeIntervalPrice>
      </prices>
    </ParkingChargeBand>
    <ParkingChargeBand>
      <MaximumStay>P1D</MaximumStay>
      <prices>
        <TimeIntervalPrice id="FR:TimeIntervalPrice:05:LOC" version="any">
          <Amount>39.6</Amount>
        </TimeIntervalPrice>
      </prices>
    </ParkingChargeBand>
  </parkingChargeBands>
</ParkingTariff>

Exemple d’abonnement (basé sur le profil tarifaire)

<ParkingTariff id="FR:75105:ParkingTariff:077:Qpark" version="any">
  <Name>Tarif abonnement</Name>
  <appliesTo>
    <ParkingRef ref="FR:75105:Parking:076:Qpark"/>
    <!-- Note: plusieurs Parkings peuvent partager la même tarification -->
  </appliesTo>
</ParkingTariff>
<UserProfile id="FR-Tarif-Example:UserProfile:001:LOC" version="any">
  <!-- tarif résident -->
  <Name>R&#xE9;sident</Name>
  <Description>Profil r&#xE9;sident pour tarif r&#xE9;duit</Description>
  <LocalResident>true</LocalResident>
</UserProfile>
<UserProfile id="FR-Tarif-Example:UserProfile:002:LOC" version="any">
  <!-- Plein tarif classique -->
  <Name>Non R&#xE9;sident</Name>
  <Description>Profil non r&#xE9;sident</Description>
  <LocalResident>false</LocalResident>
</UserProfile>
<UsageValidityPeriod version="any" id="FR-Tarif-Example:UsageValidityPeriod:001:LOC">
  <ValidityPeriodType>seasonTicket</ValidityPeriodType>
  <StandardDuration>P1M</StandardDuration>
</UsageValidityPeriod>
<!-- FARE TABLE -->
<!-- Pour chaque cellule: Prix / ParkingTariff-UsageValidityPeriodRef-UserProfile -->
<FareTable version="any" id="FR-Tarif-Example:FareTable:001:LOC">
  <Name> Tarifs particuliers the Parking PATRIARCHES</Name>
  <cells>
    <Cell version="any" id="FR-Tarif-Example:Cell:001:LOC" order="1">
      <ParkingPrice id="lFR-Tarif-Example:ParkingPrice:001:LOC" version="any">
        <Name>Tarif r&#xE9;sident</Name>
        <Amount>232</Amount>
      </ParkingPrice>
      <PriceableObjectRef ref="FR:75105:ParkingTariff:077:Qpark"/>
      <!-- Pour faire le lien avec le Parking -->
      <UserProfileRef version="any" ref="FR-Tarif-Example:UserProfile:001:LOC"/>
      <!-- reference vers "résident" -->
      <UsageValidityPeriodRef ref="FR-Tarif-Example:UsageValidityPeriod:001:LOC"/>
    </Cell>
    <Cell version="any" id="FR-Tarif-Example:Cell:002:LOC" order="2">
      <ParkingPrice id="FR-Tarif-Example:Cell:002:LOC" version="any">
        <Name>Tarif non r&#xE9;sident</Name>
        <Amount>290</Amount>
      </ParkingPrice>
      <PriceableObjectRef ref="FR:75105:ParkingTariff:077:Qpark"/>
      <!-- Pour faire le lien avec le Parking -->
      <UserProfileRef version="any" ref="FR-Tarif-Example:UserProfile:002:LOC"/>
      <!-- reference vers "non résident" -->
      <UsageValidityPeriodRef ref="FR-Tarif-Example:UsageValidityPeriod:001:LOC"/>
    </Cell>
    <!-- etc. -->
  </cells>
</FareTable>

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

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.

Entêtes NeTEx

Note: les FRAMEs et entêtes NeTEx sont présentés dans le document éléments communs. Seules les spécificités du profil NETEX_PARKING sont présentées ici.

TypeOfFrame : type spécifique NETEX_PARKING

Le présent profil utilise un TypeOfFrame spécifique, identifié NETEX_PARKING . Il apparaitra systématiquement et explicitement dans les éléments members du GeneralFrame.

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.

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

Bibliographie

AFIMB - groupe de travail Qualité des Données - Modèle d’arrêts partagé - Version 1.5

EN 15531-1, Public transport - Service interface for real-time information relating to public transport operations - Part 1: Context and framework

EN 15531-2, Public transport - Service interface for real-time information relating to public transport operations - Part 2: Communications infrastructure3

EN 15531-3, Public transport - Service interface for real-time information relating to public transport operations - Part 3: Functional service interfaces4

CEN/TS 15531-4, Public transport - Service interface for real-time information relating to public transport operations - Part 4: Functional service interfaces: Facility Monitoring

CEN/TS 15531-5, Public transport - Service interface for real-time information relating to public transport operations - Part 5: Functional service interfaces - Situation Exchange

<levels>
  <levelRef ref="Banlieue"/>
  <levelRef ref="GrandeLigne"/>
</levels>

<gml:pos srsName="urn:ogc:def:crs:EPSG::4326">
  -59.478340 -52.226578
</gml:pos>

<PointOfInterestRef ref=“FR_OSM_Poi:node:55711945” versionRef=“any” />

<PointOfInterestRef ref=“SK_INSPIRE_Poi:SK.SOPSK.SKUEV0319” versionRef=“any” />

Traçabilité avec les éléments d’entrée

Tableau de correspondance

Exemple

Exemple minimal

<?xml version="1.0" encoding="UTF-8"?>
<PublicationDelivery xmlns="http://www.netex.org.uk/netex" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="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" version="1.1">
  <!--- =============== ENTETE =========== -->
  <PublicationTimestamp>2019-06-12T09:30:47.0Z</PublicationTimestamp>
  <ParticipantRef>AURIGE001</ParticipantRef>
  <!-- ========== DONNEES =========== -->
  <dataObjects>
    <!-- =========================================== -->
    <!-- CompositeFrame.de type NETEX_FRANCE -->
    <CompositeFrame version="1" created="2019-06-12T09:30:47.0Z" id="FR:CompositeFrame:myFrame01:LOC">
      <frames>
        <!-- =========================================== -->
        <!-- Frame NETEX_TARIF -->
        <GeneralFrame version="001" id="FR:TypeOfFrame:NETEX_PARKING-Example1:LOC">
          <TypeOfFrameRef ref="FR:TypeOfFrame:NETEX_PARKING">version="2.01:FR-NETEX_PARKING-1.0"</TypeOfFrameRef>
          <members modificationSet="all">
            <!-- ======================================================================================================== -->
            <Parking id="FR:75105:Parking:076:Qpark" version="2" responsibilitySetRef="FR:ResponsibilitySet:0123:LOC">
              <validityConditions>
                <AvailabilityCondition id="FR:AvailabilityCondition:01:Qpark" version="any">
                  <!-- Ouverture semaine et samedi-->
                  <IsAvailable>true</IsAvailable>
                  <dayTypes>
                    <DayType version="any" id="FR:DayType:01:Qpark">
                      <properties>
                        <PropertyOfDay>
                          <DaysOfWeek>Weekdays Weekend</DaysOfWeek>
                        </PropertyOfDay>
                      </properties>
                      <timebands id="FR:timebands:01:Qpark">
                        <Timeband id="FR:Timeband:01:Qpark" version="any">
                          <StartTime>07:00:00</StartTime>
                          <EndTime>20:00:00</EndTime>
                        </Timeband>
                      </timebands>
                    </DayType>
                  </dayTypes>
                </AvailabilityCondition>
              </validityConditions>
              <Name>PATRIARCHES</Name>
              <ParkingType>urbanParking</ParkingType>
              <ParkingVehicleTypes>car</ParkingVehicleTypes>
              <ParkingLayout>underground</ParkingLayout>
              <TotalCapacity>334</TotalCapacity>
              <ParkingPaymentProcess>payAtMachineOnFootPriorToExit payAtBay</ParkingPaymentProcess>
              <PaymentMethods>cashAndCard epayDevice contactlessPaymentCard</PaymentMethods>
              <ParkingReservation>noReservations</ParkingReservation>
              <parkingProperties>
                <ParkingProperties id="FR:ParkingProperties:1:Qpark" version="any">
                  <ParkingUserTypes>allUsers</ParkingUserTypes>
                </ParkingProperties>
              </parkingProperties>
              <parkingAreas>
                <ParkingArea id="FR:ParkingArea:76-1:Qpark" version="any">
                  <MaximumHeight>190</MaximumHeight>
                  <TotalCapacity>334</TotalCapacity>
                </ParkingArea>
              </parkingAreas>
              <vehicleEntrances>
                <ParkingEntranceForVehicles id="FR:ParkingEntranceForVehicles:1:Qpark" version="any">
                  <Centroid>
                    <Location>
                      <Longitude>2.3508884</Longitude>
                      <Latitude>48.8403437</Latitude>
                    </Location>
                  </Centroid>
                </ParkingEntranceForVehicles>
              </vehicleEntrances>
            </Parking>
            <!-- ========================================================================== -->
            <GeneralOrganisation version="any" id="FR:Organsation:75:">
              <CompanyNumber>21750001600019</CompanyNumber>
              <!--Ville de Paris-->
            </GeneralOrganisation>
            <GeneralOrganisation id="FR:Organsation:AB74:LOC" version="any">
              <CompanyNumber>50472714000056</CompanyNumber>
              <!--INDIGO -->
            </GeneralOrganisation>
            <ResponsibilitySet id="FR:ResponsibilitySet:0123:LOC" version="any">
              <roles>
                <ResponsibilityRoleAssignment version="any" id="FR:ResponsibilityRoleAssignment:01:LOC">
                  <StakeholderRoleType>EntityLegalOwnership</StakeholderRoleType>
                  <ResponsibleOrganisationRef ref="FR:Organsation:75:"/>
                </ResponsibilityRoleAssignment>
                <ResponsibilityRoleAssignment version="any" id="FR:ResponsibilityRoleAssignment:02:LOC">
                  <StakeholderRoleType>Operation</StakeholderRoleType>
                  <ResponsibleOrganisationRef ref="FR:Organsation:AB74:LOC"/>
                </ResponsibilityRoleAssignment>
              </roles>
            </ResponsibilitySet>
            <!-- ========================================================================== -->
          </members>
        </GeneralFrame>
      </frames>
    </CompositeFrame>
  </dataObjects>
</PublicationDelivery>