Règlement32018R2032
Règlement d’exécution (UE) 2018/2032 de la Commission du 20 novembre 2018 modifiant le règlement (CE) n° 416/2007 concernant les spécifications techniques des avis à la batellerie
| CELEX | 32018R2032 |
| Type | Règlement |
| Date | mardi 20 novembre 2018 |
Résumé IA
Ce règlement d'exécution modifie les spécifications techniques des avis à la batellerie (Notices to Skippers) prévues par le règlement (CE) n° 416/2007. Il vise à harmoniser et moderniser le format et le contenu des informations diffusées aux bateliers sur les conditions de navigation, les restrictions et les dangers sur les voies navigables intérieures de l'UE. Pour un professionnel du droit français, ce texte actualise les obligations techniques des autorités compétentes en matière de signalisation et d'information fluviale, impactant directement la sécurité et la régulation du transport par voie d'eau.
Texte intégral
| 28.12.2018 | FR EN | Journal officiel de l'Union européenne | L 332/1 |
RÈGLEMENT D’EXÉCUTION (UE) 2018/2032 DE LA COMMISSION
du 20 novembre 2018
modifiant le règlement (CE) no 416/2007 concernant les spécifications techniques des avis à la batellerie
LA COMMISSION EUROPÉENNE,
vu le traité sur le fonctionnement de l’Union européenne,
vu la directive 2005/44/CE du Parlement européen et du Conseil du 7 septembre 2005 relative à des services d’information fluviale (SIF) harmonisés sur les voies navigables communautaires (1), et notamment son article 5, paragraphe 1, point c),
considérant ce qui suit:
| (1) | Le règlement (CE) no 416/2007 (2) de la Commission devrait être mis à jour, précisé et clarifié en tenant compte des progrès technologiques et de l’expérience acquise dans le cadre de l’application du règlement (CE) no 416/2007. |
| (2) | Les spécifications techniques des avis à la batellerie devraient être fondées sur les principes techniques exposés à l’annexe II de la directive 2005/44/CE. |
| (3) | Afin d’améliorer la sécurité de la navigation, les avis à la batellerie devraient être élargis de manière à inclure un nouveau type d’information concernant les avis météorologiques. |
| (4) | Les tableaux de référence relatifs aux échelles devraient être supprimés de l’annexe du règlement (CE) no 416/2007, étant donné que les données de référence qui y figurent, telles que les valeurs de référence relatives aux hauteurs d’eau élevées et aux basses eaux, sont dynamiques. Ces données devraient être incluses et maintenues dans le système européen de gestion des données de référence géré par la Commission. |
| (5) | Il est nécessaire d’améliorer la cohérence de l’édition et du développement des applications afin de créer des services dotés d’un niveau plus élevé d’interopérabilité. Dès lors, les guides de codage destinés aux éditeurs et aux développeurs d’applications devraient être inclus dans les spécifications techniques en tant qu’appendices A et B à l’annexe. |
| (6) | L’échange de données entre les autorités est recommandé par le règlement (CE) no 416/2007. Afin d’améliorer cet échange de données, les spécifications qui s’y rapportent devraient être énoncées à l’appendice D à l’annexe de manière à permettre aux États membres de rendre leurs systèmes interopérables. |
| (7) | Afin de faire en sorte que les États membres puissent coder leurs avis à la batellerie de manière cohérente et interopérable, les tableaux de référence inclus à l’appendice E devraient être améliorés. À cet effet, de nouveaux codes devraient être définis dans un nouveau tableau de référence contenant des étiquettes harmonisées d’interface de recherche pour l’interface utilisateur graphique. Par ailleurs, de nouveaux champs, valeurs et codes devraient être ajoutés aux tableaux de référence existants et les éléments redondants devraient être supprimés. |
| (8) | Les spécifications techniques révisées devraient faire en sorte que les tableaux de référence de l’appendice E soient également disponibles par voie électronique dans le système européen de gestion des données de référence géré par la Commission européenne. |
| (9) | Conformément à l’article 12, paragraphe 2, de la directive 2005/44/CE, afin de respecter l’article 4 de ladite directive, les États membres devraient prendre les mesures nécessaires pour satisfaire aux exigences définies dans le présent règlement au plus tard trente mois après son entrée en vigueur. |
| (10) | Il y a donc lieu de modifier le règlement (CE) no 416/2007 en conséquence. |
| (11) | Les mesures prévues dans le présent règlement sont conformes à l’avis du comité visé à l’article 11 de la directive 2005/44/CE, |
A ADOPTÉ LE PRÉSENT RÈGLEMENT:
Article premier
L’annexe du règlement (CE) no 416/2007 est remplacée par le texte figurant à l’annexe du présent règlement.
Article 2
Le présent règlement entre en vigueur le jour suivant celui de sa publication au Journal officiel de l’Union européenne.
Le présent règlement est obligatoire dans tous ses éléments et directement applicable dans tout État membre.
Fait à Bruxelles, le 20 novembre 2018.
Par la Commission
Le président
Jean-Claude JUNCKER
(1) JO L 255 du 30.9.2005, p. 152.
(2) Règlement (CE) no 416/2007 de la Commission du 22 mars 2007 concernant les spécifications techniques des avis à la batellerie visées à l’article 5 de la directive 2005/44/CE du Parlement européen et du Conseil relative à des services d’information fluviale (SIF) harmonisés sur les voies navigables communautaires (JO L 105 du 23.4.2007, p. 88).
ANNEXE
TABLE DES MATIÈRES
| 1. | DISPOSITIONS GÉNÉRALES | 4 |
| 1.1. | Définitions | 4 |
| 1.2. | Fonctions principales et performances requises pour les avis à la batellerie (NtS) | 4 |
| 2. | FOURNITURE D’AVIS À LA BATELLERIE | 5 |
| 3. | TYPES DE NtS | 5 |
| 4. | STRUCTURE ET CODAGE DES NTS | 5 |
| 4.1. | Structure générale | 5 |
| 4.1.1. | Section «Identification» | 6 |
| 4.1.2. | Message relatif à la voie navigable et au trafic | 6 |
| 4.1.3. | Message relatif aux hauteurs d’eau | 6 |
| 4.1.4. | Message relatif à la glace | 7 |
| 4.1.5. | Avis météorologique | 7 |
| 4.2. | Explication des champs XML et des valeurs figurant dans les NtS Reference Tables | 7 |
| 4.3. | Identification des secteurs du chenal navigable et des objets dans les NtS | 7 |
| 4.4. | Règles pour le codage des NtS | 8 |
| Appendice A: NtS Encoding Guide destiné aux éditeurs | 9 |
| Appendice B: NtS Encoding Guide destiné aux développeurs d’applications | 22 |
| Appendice C: Description du schéma XML pour les NtS (XSD) | 50 |
| Appendice D: Spécification du NtS Web Service (WSDL) | 87 |
1. DISPOSITIONS GÉNÉRALES
1.1. Définitions
On entend par «services d’information sur les voies navigables (FIS)» les données géographiques, hydrologiques et administratives relatives à la voie navigable (ou chenal navigable) qui sont utilisées par les bateliers et les gestionnaires de flotte pour planifier, effectuer et superviser un voyage. Le terme «batelier» utilisé dans la présente norme est réputé équivalent au terme «conducteur de bateau» utilisé dans les lignes directrices relatives aux services d’information fluviale (RIS) [règlement (CE) no 414/2007 de la Commission (1)], tandis que le terme «gestionnaire de la flotte» est défini dans le règlement (CE) no 415/2007 de la Commission (2).
Les FIS fournissent des informations dynamiques (par exemple niveaux d’eau, prévisions des niveaux d’eau) et statiques (par exemple heures de fonctionnement des écluses et des ponts) sur l’utilisation et l’état de l’infrastructure des voies navigables, et facilitent donc les décisions tactiques et stratégiques de navigation.
Les moyens habituellement utilisés pour ces services sont notamment les aides visuelles à la navigation, les avis à la batellerie (aux capitaines) publiés par écrit, radiodiffusés, et transmis par les téléphones fixes aux écluses. Le téléphone mobile apporte de nouvelles possibilités pour la transmission de messages vocaux et de données, mais le réseau cellulaire n’est pas disponible en tout temps et en tout lieu. Des FIS personnalisés peuvent être assurés par des services de radiotéléphonie sur les voies navigables intérieures, par l’internet, ou par un service de carte électronique de navigation, tel que le système de visualisation des cartes électroniques et d’informations pour la navigation intérieure (Inland ECDIS) avec une carte électronique de navigation (ENC).
1.2 Fonctions principales et performances requises pour les avis à la batellerie (NtS)
La présente spécification technique pour les NtS énonce les règles à appliquer pour la transmission des informations sur les chenaux navigables via l’internet.
Les NtS:
| a) | fournissent des informations sur l’état des chenaux, le trafic, la météo, les niveaux de l’eau et la glace pour les services d’information sur les chenaux; |
| b) | assurent la traduction automatique des principales indications contenues dans les informations, en utilisant un vocabulaire standard basé sur des listes de codes (les NtS Reference Tables fournis à l’appendice E); |
| c) | sont transmis selon une structure standardisée des données, afin de faciliter l’intégration des informations dans les systèmes de planification des voyages; |
| d) | sont compatibles avec la structure de données du RIS Index et de l’Inland ECDIS afin de faciliter leur intégration dans ce dernier, conformément à la directive 2005/44/CE du 7 septembre 2005 relative à des services d’information fluviale (SIF) harmonisés sur les voies navigables communautaires. |
Les spécifications techniques des NtS facilitent l’échange de données entre les systèmes NtS de différents pays et vers d’autres applications utilisant les données NtS, dont l’Inland ECDIS.
Certaines informations incluses dans les NtS peuvent être standardisées tandis que d’autres ne peuvent l’être.
La partie standardisée couvre toutes les informations qui sont:
| a) | importantes pour la sécurité de la navigation intérieure (par exemple: naufrage d’une petite embarcation sur le côté droit du chenal navigable du Danube, p.k. 2 010); |
| b) | nécessaires à la planification des voyages (par exemple fermeture d’écluses et diminution du tirant d’air). |
D’autres informations non pertinentes aux fins de la sécurité ou de la planification des voyages, telles que le motif de l’interruption du fonctionnement d’une écluse, peuvent être communiquées sous la forme de textes non standardisés, sans traduction automatique. L’utilisation de texte non standardisé est limitée autant que possible.
2. FOURNITURE D’AVIS À LA BATELLERIE
Les États membres veillent à ce que les NtS soient accessibles en ligne et via le NtS web service standardisé, conformément aux spécifications techniques décrites dans la présente annexe et dans ses appendices. La spécification relative au NtS web service standardisé est incluse à l’appendice D sous la forme d’un langage WSDL (Web Service Description Language).
Les NtS web services standardisés donnent à l’utilisateur la possibilité de sélectionner des avis sur la base d’au moins un des critères suivants:
| a) | un secteur spécifique de la voie navigable; |
| b) | un secteur spécifique de la voie navigable défini par les points kilométriques de début et de fin; |
| c) | la période de validité de l’avis (date de début et date de fin de la période de validité); |
| d) | la date de publication de l’avis (date et heure de publication). |
Les NtS qui satisfont aux normes énoncées dans la présente annexe peuvent notamment être transmis par les instruments suivants:
| a) | applications mobiles (apps); |
| b) | services de courrier électronique. |
Un échange de données entre des systèmes NtS exploités dans différents pays peut avoir lieu. Tous les systèmes utilisant les normes décrites dans l’annexe du présent règlement peuvent intégrer dans leurs propres services les NtS provenant d’autres systèmes, pour autant que le contenu de l’avis ne soit pas modifié. Les utilisateurs sont informés de l’interruption ou de l’indisponibilité de la connexion à une source de NtS intégrés.
3. TYPES DE NTS
Les NtS constituent des messages essentiels qui sont standardisés autant que possible.
On distingue quatre types de NtS:
| a) | les messages relatifs à la voie navigable et au trafic; |
| b) | les messages relatifs aux hauteurs d’eau; |
| c) | les messages relatifs à la glace; |
| d) | les avis météorologiques. |
4. STRUCTURE ET CODAGE DES NTS
On trouvera sous ce point une description de la structure et du codage des NtS électroniques standardisés.
Un NtS est un message structuré utilisant dans la mesure du possible des éléments standardisés. L’utilisation de texte non standardisé dans les éléments d’information est limitée autant que possible.
La description de schéma standardisée en langage de balisage extensible (XML) utilisée pour les NtS, appelée «XSD» dans la présente norme, contient les valeurs standardisées; les formats possibles sont inclus à l’appendice C.
Les valeurs standardisées et les champs XML, leur signification et leur traduction sont fournis dans les NtS Reference Tables inclus à l’appendice E et sont également disponibles par voie électronique dans le système européen de gestion des données de référence (ERDMS) exploité par la Commission européenne.
4.1. Structure générale
Un NtS est constitué des sections suivantes:
| a) | une section «Identification»; |
| b) | une section définissant le ou les objets ou secteurs du chenal navigable auxquels se rapporte l’avis; |
| c) | une ou plusieurs limitations (pour les messages relatifs à la voie navigable et au trafic), une ou plusieurs mesures (pour les messages relatifs aux hauteurs d’eau), des informations sur les conditions de glace (pour les messages relatifs à la glace), ou un ou plusieurs bulletins météorologiques (pour les avis météorologiques). |
Figure 1
Structure des avis à la batellerie
4.1.1. Section «Identification»
Chaque message doit comporter une section «Identification». Celle-ci contient des informations générales sur l’émetteur et la date de publication de l’avis.
4.1.2. Message relatif à la voie navigable et au trafic
Un message relatif à la voie navigable et au trafic contient des informations relatives à un ou plusieurs secteurs du chenal navigable ou à un ou plusieurs objets; il sert à indiquer des limitations pour les besoins suivants:
| a) | des «avertissements» : pertinents pour la sécurité. Un avertissement doit contenir au moins une limitation entraînant la mise en danger directe et concrète de personnes, de bateaux ou d’installations, par exemple un avis concernant des travaux de soudure sur un pont produisant des étincelles, une cage d’inspection ou des ouvriers suspendus à un pont, ou un obstacle dans le chenal; |
| b) | des «informations» : pertinentes pour la planification ou la sécurité du voyage. L’information peut contenir des limitations, par exemple la restriction d’un sas en raison de travaux d’entretien ou un dragage sur le chenal; |
| c) | un service d’information: informations générales qui ne sont pas directement liées à la planification ou la sécurité du voyage. Ce service d’information ne peut pas comporter de limitations spécifiques et n’est donc pas directement pertinent pour la planification ou la sécurité du voyage. Il peut s’agir d’informations générales telles que les règlements particuliers de police ou les mises à jour des données Inland ECDIS. |
4.1.3. Message relatif aux hauteurs d’eau
Dans la section relative aux hauteurs d’eau figurent des valeurs ou des prévisions concernant:
| a) | le niveau de l’eau; |
| b) | la profondeur minimale; |
| c) | le tirant d’air; |
| d) | les statuts des barrages; |
| e) | le débit; |
| f) | le régime. |
Habituellement, les informations relatives aux hauteurs d’eau sont créées et transmises automatiquement en fonction des données reçues d’un appareil de détection (par exemple une échelle), d’un système (par exemple un modèle de niveau de l’eau) ou d’une infrastructure (par exemple les statuts d’un barrage). Divers facteurs peuvent déclencher la transmission d’une information; celle-ci peut intervenir périodiquement ou lorsqu’une certaine valeur est atteinte.
4.1.4. Message relatif à la glace
Une information relative à la glace contient des informations au sujet des conditions de glace effectives ou prévues sur un ou plusieurs secteurs de chenal navigable. Ce message est habituellement émis par le personnel compétent sur la base d’observations locales et d’évaluations professionnelles.
4.1.5. Avis météorologique
Un avis météorologique comporte des informations concernant des conditions météorologiques (dangereuses) pour la navigation intérieure.
Pour aider les réseaux hydrométéorologiques à communiquer les informations hydrométéorologiques aux bateliers, des avis météorologiques peuvent être publiés.
4.2. Explication des champs XML et des valeurs figurant dans les NtS Reference Tables
La signification des différents éléments utilisés dans la description du schéma XML pour les NtS (XSD) est donnée dans les NtS Reference Tables fournis à l’appendice E. La structure, le format et les valeurs possibles pour tous les éléments XML sont décrits dans le schéma XML pour les NtS (XSD) à l’appendice C.
| a) | Les coordonnées (longitude et latitude) sont codées sur la base du système géodésique mondial de 1984 et sont indiquées en degrés et minutes, avec au moins trois décimales, mais de préférence quatre ([d]d mm.mmm[m] N, [d][d]d mm.mmm[m] E). |
| b) | Le séparateur décimal utilisé dans les champs numériques est le point décimal («.»). Les nombres sont indiqués sans séparateur de milliers. |
| c) | Les NtS utilisent exclusivement les unités suivantes pour les valeurs figurant dans le message XML: cm, m3/s, h, km/h et kW, m/s (vent), mm/h (pluie) et degré Celsius. Les applications nationales peuvent convertir les unités pour un affichage adapté à leurs utilisateurs. |
4.3. Identification des secteurs du chenal navigable et des objets dans les NtS
Pour répondre aux exigences minimales concernant les données applicables à la fourniture d’informations sur les objets pertinents pour la navigation intérieure tel qu’établi à l’article 4, paragraphe 3, point a), de la directive 2005/44/CE, il y a lieu d’utiliser l’ISRS Location Code dans la section relative aux objets. L’ISRS Location Code est utilisé pour identifier de manière distincte les objets et les secteurs du chenal navigable, ainsi que pour assurer l’interopérabilité des systèmes et services RIS (afin, notamment, de combiner les informations sur l’infrastructure émanant du RIS Index, de l’Inland ECDIS et des NtS pour planifier les voyages).
L’ISRS Location Code est un code alphanumérique à 20 chiffres utilisé pour établir un lien unique et normalisé entre les objets dans les services d’information fluviale. Il se compose des éléments d’information obligatoires suivants, disposés en quatre blocs d’information:
| a) | Bloc 1: UN/LOCODE (5 lettres, alphanumérique), comprenant
|
| b) | Bloc 2: Fairway section code (5 chiffres, alphanumérique, à déterminer par l’autorité nationale) |
| c) | Bloc 3: Object Reference Code (5 chiffres, alphanumérique, «XXXXX» si indisponible). |
| d) | Bloc 4: Fairway section hectometre (5 chiffres, numérique, hectomètre au centre de la zone ou «00000» si indisponible). |
Les ISRS Location Codes et les données de référence des objets sont maintenus par les États membres dans le RIS Index et soumis à l’ERDMS exploité par la Commission européenne conformément aux procédures de maintenance pour le RIS Index publiées sur le site web de l’ERDMS.
4.4. Règles pour le codage des NtS
Les NtS sont codés conformément au NtS Encoding Guide destiné aux éditeurs (appendice A) et au NtS Encoding Guide destiné aux développeurs d’applications (appendice B).
(1) Règlement (CE) No 414/2007 de la Commission du 13 mars 2007 concernant les lignes directrices techniques pour la planification, la mise en œuvre et le fonctionnement opérationnel des services d’information fluviale (SIF) visés à l’article 5 de la directive 2005/44/CE du Parlement européen et du Conseil relative à des services d’information fluviale (SIF) harmonisés sur les voies navigables communautaires (JO L 105 du 23.4.2007, p. 1).
(2) Règlement de la Commission (CE) No 415/2007 du 13 mars 2007 concernant les spécifications techniques applicables aux systèmes de suivi et de localisation des bateaux visés à l’article 5 de la directive 2005/44/CE du Parlement européen et du Conseil relative à des services d’information fluviale (SIF) harmonisés sur les voies navigables communautaires (JO L 105 du 23.4.2007, p. 35).
(3) Les country codes des Nations unies sont définis conformément au point 2.4.2.12 de l’annexe du règlement (UE) no 164/2010 de la Commission (JO L 57 du 6.3.2010, p. 1). Les country codes des Nations unies sont identiques aux country codes de norme ISO 3166-1 alpha 2.
A. NTS ENCODING GUIDE DESTINÉ AUX ÉDITEURS
TABLE DES MATIÈRES
| 1. | Contexte, structure et objet des NtS Encoding Guides 11 | 10 |
| 2. | Sélection du type de NtS | 10 |
| 3. | Considérations de base relatives au FTM et étapes de la publication d’un FTM | 10 |
| 4. | Explication des codes d’un FTM | 12 |
| 5. | Considérations de base relatives au WRM | 20 |
| 6. | Considérations de base relatives à l’ICEM et étapes de la publication d’un ICEM | 20 |
| 7. | Considérations de base relatives au WERM | 20 |
| 8. | Règles relatives à certains éléments | 21 |
Abréviations
| Abréviation | Signification |
| CEVNI | Code européen de voies de la navigation intérieure (http://www.unece.org/trans/main/sc3/sc3res.html) |
| CEN | Carte électronique de navigation |
| FTM | Message relatif à la voie navigable et au trafic |
| ICEM | Message relatif à la glace |
| Inland ECDIS | Système de visualisation des cartes électroniques et d’informations pour la navigation intérieure |
| ISRS Location Code | Code de localisation «International Ship Reporting Standard» |
| NtS | Avis à la batellerie |
| RIS | Services d’information fluviale |
| VHF | Bande mobile maritime |
| WERM | Avis météorologique |
| WRM | Message relatif aux hauteurs d’eau |
| WSDL | Langage de description de services web |
| XML | Langage de balisage extensible |
| XSD | Définition de schéma XML |
1. Contexte, structure et objet des NtS Encoding Guides
La norme NtS est améliorée en permanence. Une avancée majeure a été la publication du NtS web service, qui facilite les échanges de NtS entre les autorités ainsi qu’entre les autorités et les utilisateurs de NtS.
Deux documents ont été élaborés en vue de faciliter le codage harmonisé des NtS au niveau national et international: le NtS Encoding Guide destiné aux éditeurs et le NtS Encoding Guide destiné aux développeurs d’applications. Ces guides appliquent la NtS XSD 4.0 et le NtS Web Service WSDL 2.0.4.0.
Compte tenu de l’utilisation accrue du NtS Web Service, les NtS sont davantage harmonisés afin d’assurer un affichage adéquat de leur contenu sur les systèmes de tierces parties. Un codage uniforme des messages est également essentiel à la prise en compte des messages dans les applications de planification des voyages.
Les éléments contenant uniquement des valeurs standard ou par défaut sont omis s’ils sont facultatifs, car ils entraînent un surdébit de messages sans valeur ajoutée.
Le NtS Encoding Guide destiné aux éditeurs s’adresse aux personnes qui rédigent (et publient) les NtS. Il inclut des instructions étape par étape en vue de créer des types de messages adéquats, ainsi qu’une explication des codes. Le NtS Encoding Guide explique l’applicabilité des quatre types de NtS, fournit des instructions pour remplir les messages et inclut également des codes à utiliser dans certaines circonstances. Le NtS Encoding Guide destiné aux éditeurs est inclus à l’appendice A du présent règlement.
Le NtS Encoding Guide destiné aux développeurs d’applications contient des lignes directrices pour le développement et l’exécution d’applications pour les NtS, en expliquant leur logique, leurs processus et leurs valeurs automatiques/par défaut. Le NtS Encoding Guide destiné aux développeurs d’applications est inclus à l’appendice B du présent règlement.
2. Sélection du type de NtS
| — | FTM: choisissez ce type si vous voulez créer un «message relatif à la voie navigable et au trafic» pour des voies navigables ou des objets sur une voie navigable. [aller au chapitre 3]. |
| — | WRM: choisissez ce type si vous voulez créer un «message relatif aux hauteurs d’eau», qui permet de fournir des informations sur les niveaux d’eau actuels et prévus, ainsi que d’autres informations. Le message relatif aux hauteurs d’eau contient des informations relatives à un objet ou un secteur de chenal navigable. L’objet est défini par son ISRS Location Code, tandis que le secteur de chenal navigable est défini par ses ISRS Location Codes de début et de fin. |
| — | ICEM: choisissez ce type si vous voulez créer un «message relatif à la glace». La section Informations relatives à la glace comporte des informations relatives aux conditions de glace sur une partie de chenal navigable définie par ses ISRS Location Codes de début et de fin. |
| — | WERM: choisissez ce type si vous voulez créer un «avis météorologique», qui permet de fournir des relevés et des prévisions météorologiques relatifs à une portion de voie navigable définie par ses ISRS Location Codes de début et de fin. |
3. Considérations de base relatives au FTM et étapes de la publication d’un FTM
Le chapitre 4 présente des informations détaillées sur les codes qui doivent être utilisés. Les considérations formulées à partir de la section 3.3 ne correspondent pas nécessairement à l’ordre d’entrée suivi par un outil d’édition des FTM.
| 3.1. | Est-il nécessaire de publier des informations au moyen d’un NtS FTM conformément à la norme NtS? Toutes les informations pertinentes sur la sécurité et la planification des voyages doivent être publiées au moyen de NtS. Des informations n’ayant pas d’utilité pour la sécurité et la planification des voyages peuvent être publiées. Chaque sujet/incident/événement doit être publié dans un message séparé. |
| 3.2. | Existe-t-il déjà un FTM valide pour la situation actuelle (en rapport avec le contenu ainsi que la période de validité)? |
| 3.2.1. | Oui: le FTM existant doit être mis à jour. Le message publié concerné doit être sélectionné et mis à jour dans l’outil d’édition des FTM. Un FTM expiré ne peut plus être mis à jour. |
| 3.2.2. | Non: un nouveau FTM doit être établi. Lorsqu’un événement similaire a déjà été codé dans un FTM existant, celui-ci peut être utilisé comme ébauche pour la création d’un nouveau FTM (si cette fonction est disponible), ou un modèle peut également être utilisé (si cette fonction est disponible). |
| 3.3. | Le champ géographique de validité doit être défini |
| 3.3.1. | Lorsque le FTM est lié à une partie spécifique d’une voie navigable, cette partie doit être incluse, en étant définie par sa coordonnée de début et sa coordonnée de fin. Si le contenu s’applique à plusieurs secteurs d’une même voie navigable ou de différentes voies navigables, ceux-ci peuvent tous être repris dans un seul FTM. |
| 3.3.2. | Lorsque le FTM porte sur un objet spécifique (par exemple un pont, une écluse, etc.) présent sur la voie navigable, il doit être sélectionné dans la liste des objets disponibles (si la fonction de sélection est disponible). Il n’est pas nécessaire de définir une partie de voie navigable dans le message. Lorsqu’un FTM porte sur plusieurs objets, ceux-ci peuvent tous être repris dans un seul FTM. |
| 3.3.3. | Il est possible de combiner des informations relatives à des objets et à des chenaux navigables dans un seul message, pour autant que les informations portent sur une cause/un événement spécifique (même sujet et même code de motif). |
| 3.3.4. | Bien que les coordonnées soient facultatives, elles sont fournies en soutien de la visualisation sur carte (ces coordonnées sont souvent fournies automatiquement par l’application NtS). |
| 3.4. | Le contenu du FTM doit être encodé Toutes les informations pouvant être exprimées au moyen des NtS Reference Tables doivent être codées dans les champs de message standardisés. Seules les informations supplémentaires (qui ne sont pas codables autrement) sont indiquées dans les champs de texte libre. |
| 3.5. | Le ou les groupes cibles relatifs au type de bateau et les sens de navigation concernés doivent être indiqués le cas échéant. |
| 3.5.1. | Lorsque le message est valable pour tous les bateaux (quel que soit leur type) dans tous les sens de navigation, le groupe cible n’est pas précisé et seules les informations essentielles sont codées. Si le message/la limitation concerne un groupe cible ou un sens de navigation spécifique, les codes pertinents doivent être sélectionnés. |
| 3.5.2. | Lorsque la totalité du message s’adresse à des groupes cibles spécifiques, les informations relatives au groupe cible sont fournies dans la partie générale du FTM (et ne sont pas répétées dans la ou les sections «Limitations»). |
| 3.5.3. | Lorsque différentes limitations s’appliquent à différents groupes cibles, les informations relatives au groupe cible sont fournies dans les sections «Limitations» respectives (et ne sont pas répétées dans la partie générale). |
| 3.5.4. | Lorsque des dérogations aux limitations sont accordées à certains bateaux ou au trafic local par les autorités compétentes (par exemple, aux bateaux participant à un événement concerné par une restriction générale ou au trafic local de ferries dans des zones visées par une interruption), ces dérogations ne doivent pas être prises en compte pour le codage du ou des groupes cibles. Ces informations peuvent être indiquées dans le champ de texte libre réservé aux informations supplémentaires. |
| 3.6. | La section «Communication» est remplie le cas échéant. Si des informations supplémentaires sont disponibles via une source spécifique, il convient de le mentionner dans cette section. En cas d’obligation d’annonce supplémentaire via un canal spécifique, il convient de le mentionner dans cette section. |
| 3.7. | La section «Limitations» est remplie le cas échéant La section «Limitations» doit être remplie lorsque des limitations s’appliquent. Les valeurs liées à des limitations qui sont connues doivent être indiquées. Il est obligatoire de fournir des valeurs pour les dimensions des bateaux, les limites de vitesse et l’espace de navigation disponible. Les périodes de limitation doivent être indiquées à chaque fois, afin de permettre aux applications de planification des voyages d’effectuer des calculs corrects (pour faciliter la tâche, l’application NtS peut prévoir une fonction permettant de copier les périodes de limitation ou de sélectionner plusieurs limitations pour une même période). |
| 3.8. | La date de début de la validité du message doit être indiquée La date de fin de la validité du message doit également être indiquée si elle est déjà connue. La date de fin de la validité ne peut pas être antérieure à la date actuelle. Il est à noter que les applications utiliseront les informations relatives à la période de validité pour sélectionner les messages à montrer aux utilisateurs pendant une période requise. En cas d'annulation du message:
|
| 3.9. | Le message peut être publié |
4. Explication des codes d’un FTM
4.1. Subject_code:
Définition de l’utilisation des codes sujet:
| — | « Avertissement »: pertinent pour la sécurité. Un avertissement doit contenir au moins une limitation entraînant la mise en danger directe et concrète de personnes, de bateaux ou d’installations, par exemple un avis concernant des travaux de soudure sur un pont produisant des étincelles, une cage d’inspection ou des ouvriers suspendus à un pont, ou un obstacle dans le chenal; |
| — | «Annonce» : pertinente pour la planification du voyage ou la sécurité. L’annonce peut contenir des limitations, par exemple la restriction d’un sas en raison de travaux d’entretien, un dragage sur le chenal ou les règles de circulation qui s’ajoutent à la législation nationale; |
| — | « Service d’information »: informations générales qui ne sont pas directement liées à la planification du voyage ou à la sécurité. Le service d’information ne peut pas comporter de limitations spécifiques et n’est donc pas directement pertinent pour la planification ou la sécurité du voyage. Il peut s’agir d’informations telles que les règlements particuliers de police ou les mises à jour des données Inland ECDIS. La période de validité est utilisée pour préciser le temps durant lequel le message du service d’information est visible pour les utilisateurs, et non pour indiquer la période de validité des informations fournies (par exemple un mois ou tel que défini dans les procédures nationales). |
| — | «Avis annulé» Le code sujet «Avis annulé» n’est utilisé que si
Dans ce cas, les mesures/événements se terminent avant la fin de la période de validité définie initialement pour un FTM existant. |
4.2. Reason_code
Le code de motif doit être rempli afin de fournir davantage d’informations aux bateliers.
Définition de l’utilisation des codes de motif:
| travaux de construction | Annonce de travaux de construction |
| accident | Avertissement d’un accident |
| modifications du chenal navigable | Annonce de modifications du chenal navigable |
| signalisation modifiée | Annonce de modifications de la signalisation de la voie navigable |
| rétrécissement du chenal navigable | Annonce d’une réduction de la largeur du chenal navigable si aucun autre code de motif n’est applicable |
| panneaux de signalisation endommagés | Annonce d’un endommagement de la signalisation/de signaux |
| plongeurs au travail | Avertissement sur un plongeur qui se trouve sous l’eau |
| dragage | Annonce de travaux de dragage |
| événement | Annonce d’événements, par exemple compétitions de natation, de navigation ou d’aviron |
| exercices | Annonce d’exercices, par exemple exercices de sauvetage ou exercices militaires |
| opération de déminage | Annonce d’une opération de déminage |
| Service étendu | Annonce d’un débit de déchargement plus important que d’habitude, à cause d’un barrage ou d’une écluse pour raison de gestion de l’eau |
| chutes d’objets | Annonce d’une chute d’objets, par exemple stalactites ou branches d’arbres |
| Faux échos radar | Annonce de la possibilité d’échos radar parasites |
| Feux d’artifice | Annonce de feux d’artifice |
| Embâcle | Annonce de la présence d’embâcles au-dessus du niveau de l’eau (visibles) et en dessous du niveau de l’eau (invisibles) |
| Opération de mesure de débit | Annonce de travaux de mesure du débit |
| risques pour la santé | Avertissement ou annonce concernant par exemple la présence de processionnaires du chêne, une fuite de gaz, etc. |
| Ligne haute tension | Annonce d’une ligne haute tension traversant la voie navigable |
| Crue | Annonce d’un cas de crue avant l’atteinte du niveau d'eau d'interdiction |
| glace | Annonce de la présence de glace; des informations supplémentaires seront envoyées via une information relative à la glace (message relatif à la glace). |
| mise à jour des données Inland ECDIS | Service d’information sur une mise à jour des données Inland ECDIS |
| Inspection | Annonce de travaux d’inspection; uniquement utilisée en cas d’inspection, et non pour les travaux (de réparation/construction). Possibilité de limitations en raison de voitures/cages d’inspection ou d’échafaudages |
| Mise à l'eau | Annonce du départ d’un navire d’un chantier naval |
| règlements particuliers de police | Service d’information sur l’ajout ou la modification des règles législatives ou réglementaires applicables sans limitations spécifiques, dates de limitation ou dates de validité |
| Étiage | Annonce d’un cas d'étiage avant l’atteinte du niveau d'eau d'interdiction |
| Abaissement du niveau d’eau | Annonce d’un abaissement contrôlé du niveau de l’eau pour les besoins d’une inspection, de travaux ou de gestion de l’eau |
| Service minimum | Annonce d’un débit de déchargement moins important que d’habitude, à cause d’un barrage ou d’une écluse pour raison de gestion de l’eau |
| nouvel objet | Annonce d'un nouvel objet disponible, par exemple un pont ou un point de stationnement |
| obstacle à la navigation | Annonce d’une réduction de la hauteur libre et/ou de la largeur du chenal navigable en raison d’un obstacle au-dessus de la surface de l’eau |
| objet immergé | Annonce d’une réduction du mouillage disponible et/ou de la largeur du chenal navigable en raison d’un objet immergé |
| Niveau d’eau d'interdiction | Annonce d’un niveau de l’eau (élevé ou faible) entraînant une interdiction de la navigation |
| couverture radio | Annonce relative à la couverture radio |
| enlèvement d’objet | Annonce de l'enlèvement d’un objet |
| Travaux de réparation | Annonce effectuée lorsqu’un élément est cassé ou en panne et doit être réparé (par exemple un élément du système de commande d'une écluse); elle peut également être utilisée pour les réparations planifiées |
| Eaux montantes | Annonce d’une augmentation de la hauteur d’eau d’origine naturelle, non due à la gestion de l’eau |
| Atterrissement | Annonce d’une réduction du mouillage disponible en raison d’un atterrissement |
| Travaux de sondage | Annonce de travaux de sondage |
| Signalisation spéciale | Annonce de l’utilisation d’une signalisation spéciale, par exemple pour le blocage d’étendues d’eau ou de zones de pêche |
| transport spécial | Annonce de transports spéciaux |
| Grève | Annonce relative à une grève du personnel d’exploitation ayant une incidence sur la disponibilité de l’infrastructure des voies navigables |
| niveau d’eau nécessitant une navigation prudente | Annonce d’un niveau d’eau (élevé ou faible) nécessitant une prudence particulière lors de la navigation |
| travaux | Annonce de travaux généraux sur des objets, sur les rives et/ou dans les lits des voies navigables (rivières ou canaux) |
| restriction de la navigation | Sert uniquement d’indication des limitations existantes si aucun autre code de motif n’est applicable |
| autres | à ne pas utiliser; lorsqu’aucun autre code de motif n’est applicable, le code de motif n’est pas rempli |
4.3. Limitation_code:
Définition de l’utilisation des codes de limitation:
| — | Restriction: lorsqu’aucune forme de navigation n’est possible:
|
| — | Restriction partielle: chaque élément d’une infrastructure (par exemple un sas ou une passe de pont) possède son propre ISRS Location Code. Dans le cas où ce code serait toujours manquant, une restriction partielle peut être utilisée si une navigation limitée est possible (par exemple, lorsqu’une seule zone d’une écluse possédant deux sas parallèles est disponible)
|
| — | Navigation interrompue utilisée lorsqu’un pont mobile n’est pas en service pendant un laps de temps donné. Ce laps de temps doit se situer à l’intérieur des heures normales de fonctionnement. En cas d’interruption de service d’un pont mobile, le passage sous le pont reste possible. Dans le cas contraire, il s’agit d’une «Restriction». L’interruption de service d’une écluse est codée en tant que «Restriction». |
| — | Exploitation limitée: utilisé en cas de modification, de prolongation ou de réduction des horaires de service habituels d’un objet [par exemple une écluse ou un pont (mobile)]. |
| — | En cas de limitation relative aux dimensions autorisées des bateaux/convois (non directement liée à l’infrastructure), la restriction est codée avec les éléments de texte suivants:
Si elle est disponible, une valeur absolue est indiquée. |
| — | En cas de limitation relative à la dimension disponible d’un objet ou d’un secteur de la voie navigable, les codes suivants sont utilisés:
Si elle est disponible, une valeur absolue est indiquée. |
| — | Profondeur minimale: utilisée en cas de risque de problème lié à la profondeur (par exemple en raison d’un atterrissement). Une valeur est fournie pour la profondeur absolue (sur la base d’une valeur de référence) ou la réduction de la profondeur. Si elle est disponible, une valeur absolue est indiquée. |
| — | délai: utilisé en cas d’interruption/d’incident de durée limitée concernant un objet ou un secteur de voie navigable entre une date de début et une date de fin spécifiées. La durée maximale estimée de l’interruption/de l’incident devrait être codée. Le délai n’est pas utilisé en cas d’indisponibilité d’un ou plusieurs sas d’une écluse. |
| — | Lorsque des manœuvres ou des actions spécifiques sont interdites, les limitations pertinentes doivent être codées. Ces limitations ne sont codées que si elles ne sont pas déjà annoncées par des signaux ou des règlements de navigation codés dans l’ENC intérieur officiel:
Si elle est disponible, une valeur absolue est fournie pour la limite de vitesse et la puissance minimum. |
| — | attention spéciale: lorsque le FTM (ou une partie de celui-ci) se rapporte à une voie/un chenal navigable, cette limitation est utilisée pour indiquer à quel endroit du chenal/de la rivière/du canal/du bassin un incident s’est produit. Elle est par ailleurs utilisée lorsqu’il est impossible de décrire en détail la limitation, mais qu’il est utile ou nécessaire d’avertir ou d’informer les bateliers de l’importance d’être prudents et de faire attention aux informations radio. |
| — | pas de limitation: à n’utiliser que pour indiquer expressément qu’il n’y a pas de limitation au cours d’une période donnée. |
4.4. Limitation interval_code:Définition de l’utilisation des interval codes:
| — | «permanent»: utilisé pour les limitations applicables à partir d’une date/heure de début jusqu’à une date/heure de fin sans interruption (par exemple restriction du 01.01.2016 à 00 h 00 au 31.03.2016 à 23 h 59, mais aussi restriction le 17.09.2016 de 8 h 00 à 18 h 00), |
| — | «journalier»: utilisé pour l’application régulièrement répétée d’une limitation (par exemple, pas de remous pendant les heures de travail sur un site de dragage — du 07.04.2016 au 11.04.2016, quotidiennement de 6 h 00 à 18 h 00), |
| — | en journée (au sens du CEVNI): le terme «journée» désigne la période comprise entre le lever et le coucher du soleil, |
| — | de nuit (au sens du CEVNI): le terme «nuit» désigne la période comprise entre le coucher et le lever du soleil, |
| — | Jours de la semaine: en cas d’intervalles liés à différents jours de la semaine, ceux-ci doivent être sélectionnés parmi les éléments de texte suivants:
|
| — | «par mauvaise visibilité»: à n’utiliser que lorsque la limitation ne s’applique qu’en cas de conditions de visibilité réduite en raison de brouillard, de brume, de neige, de pluie ou autre, |
| — | «à l’exception de»: à ne pas utiliser; les intervalles interrompus doivent être indiqués en tant que périodes de limitation séparées à l’intérieur d’une même limitation. En effet, les logiciels de planification des voyages ne sont pas en mesure de comprendre que ce code ne s’applique pas à la date ou à l’heure donnée. Il est donc impossible de calculer correctement les ETA, |
| — | «Lundi au vendredi excepté jours fériés»: à n’utiliser que si les jours fériés sont compris dans la période de validité de la limitation. À titre de service pour les utilisateurs, les jours fériés peuvent être indiqués dans la section de texte libre du FTM. Les logiciels de planification des voyages ne seront pas en mesure de tenir compte des jours fériés dans le calcul des ETA. |
4.5. Indication_code:
L’indication_code est censé servir d’information sur les valeurs spécifiques relatives à certaines limitations (par exemple limite de vitesse, puissance minimum, mouillage disponible). Pour déterminer certaines dimensions, une référence à un système de référence externe (géographique ou hydrologique) (par exemple hauteur libre, mouillage disponible, profondeur minimale) ou en rapport avec les dimensions connues de structures artificielles (par exemple longueur disponible, largeur disponible) est nécessaire.
| 4.5.1. | Si des dimensions ou références absolues sont connues, elles doivent être utilisées. Des valeurs relatives ne doivent être utilisées qu’en cas d’impossibilité de faire référence à un système de référence externe. |
| 4.5.2. |
|
| 4.5.3. |
|
| 4.5.4. |
|
| 4.5.5. | Si la dimension indiquant une limitation fait référence à une coordonnée géographique ou hydrologique, le système de référence concerné doit être indiqué dans le message NtS (par exemple, une hauteur libre de 4 m minimum fait référence à la plus grande hauteur d’eau navigable; un mouillage disponible de 1,7 m minimum fait référence au plus bas niveau d’eau réglementé). |
| 4.5.6. | Si la dimension indiquant une limitation fait référence à une dimension d’une structure artificielle (par exemple un pont ou une écluse), la référence peut être donnée par rapport aux dimensions connues (par exemple réduction de la hauteur libre de 1,5 m, réduction de la longueur disponible de 27 m). |
4.6. Position_code (objets):
Dans la mesure du possible, le position_code fait référence au côté du chenal navigable où l’objet est situé par rapport à l’axe du chenal (gauche/milieu/droite) ou à une autre information notoirement connue (nouveau/vieux) ou à une direction géographique (nord/sud/est/ouest). Le position_code relatif aux objets peut être pré-rempli automatiquement à partir des données de référence du RIS Index. La rive gauche/droite du chenal est déterminée en regardant vers l’aval.
4.7. Position_code (chenaux/voies navigables):
Aucun position_code n’est indiqué pour un FTM (ou une partie de celui-ci) qui se rapporte à une voie/un chenal navigable. Pour indiquer le côté du chenal/du canal/de la rivière/du bassin où s’est produit un incident, la limitation «attention spéciale», associée au position_code de limitation adéquat, est utilisée.
4.8. Position_code (limitations):
| 4.8.1. | Dans la mesure du possible, le position_code fait référence au côté du chenal ou de l’objet où se produit la limitation (gauche/droite). La rive gauche/droite du chenal est déterminée en regardant vers l’aval. |
| 4.8.2. | Le position_code attire l’attention du batelier sur le côté du chenal où se trouve, par exemple, une zone d’intérêt particulier, un danger ou un obstacle. Une indication approximative (par exemple rive gauche — gauche — milieu — droite — rive droite) est donc suffisante. Une subdivision plus détaillée n’est pas prévue. |
| 4.8.3. | Au besoin, des informations plus précises sur la position sont fournies de préférence au moyen de cartes ou de croquis (en pièce jointe; voir le chapitre 3.6). |
| 4.8.4. | Pour les secteurs où l’indication de position habituelle, basée sur la rive du chenal navigable (gauche/droite) ne paraît pas appropriée (par exemple les bassins portuaires, certains secteurs de canaux où la direction du débit n’est pas distincte), les points cardinaux (nord/est/sud/ouest) peuvent être utilisés. |
4.9. Target_group_code (voir le chapitre 3.5)
4.10. Reporting_code
| 4.10.1. | En règle générale, le reporting_code n’est utilisé qu’en cas de besoin spécial de communication (par exemple obligation complémentaire d'annonce à l’autorité locale au sujet de la régulation du trafic sur le site) ou lorsque des informations supplémentaires directement pertinentes pour le FTM sont disponibles (par exemple un point de contact VHF tel qu’un nom de canal ou un indicatif d’appel pour la position actuelle de la drague). |
| 4.10.2. | Il convient d’éviter de répéter de manière habituelle les données de communication accessibles au public (par exemple les numéros de téléphone des autorités locales, les canaux VHF des écluses, etc.) en l’absence d’une raison directe liée au FTM. |
| 4.10.3. | En règle générale, les moyens de communication généralement applicables au sens de la réglementation officielle (par exemple les communications VHF navire-à-navire ou navire-à-station terrestre telles que définies par le CEVNI ou les règles de navigation nationales ou régionales) ne sont pas répétés par le reporting_code en l’absence d’une raison directe liée au FTM. |
4.11. Communication_code
Le format suivant est utilisé (exemples):
| — | VHF «numéro, indicatif d’appel»: «10, Schifffahrtsaufsicht Wien» |
| — | Numéro de téléphone ou de télécopieur: «+43123456789, Schifffahrtsaufsicht Wien» |
| — | Adresse internet: «http://example.com» |
| — | Signalisation sonore: «longue sirène/langer Ton» |
| — | E-mail: «example@authority.eu» |
| — | Adresse de courrier électronique EDI: «900012345@edi.bics.nl» |
| — | Télétexte: «ARD, 992 — 995» |
4.12. Type_code:
Une voie navigable est soit un canal, soit un bassin, soit une rivière.
| — | zone de stationnement |
| — | rive |
| — | balise |
| — | point de stationnement |
| — | poste de douane |
| — | pont |
| — | passe de pont |
| — | bouée |
| — | Câble suspendu (Chemin de câbles, lignes électriques) |
| — | canal [le terme «canal» est utilisé si un message porte sur l’entièreté du canal (et non pas uniquement sur le chenal navigable)] |
| — | Pont Canal: aqueduc |
| — | caniveau |
| — | chenal (le terme «chenal» désigne la partie de la voie navigable qui peut effectivement être utilisée pour le transport maritime). |
| — | bac |
| — | pontons |
| — | porte de garde (une porte de garde est utilisée pour protéger une zone en crue) |
| — | port |
| — | installation portuaire |
| — | capitainerie |
| — | bassin [le terme «bassin» est utilisé si un message porte sur l’entièreté du bassin (et non pas uniquement sur le chenal navigable)] |
| — | feux |
| — | sas d’écluse: sas individuel |
| — | écluse: le complexe éclusier tout entier |
| — | aménagement d'amarrage |
| — | panneau de signalisation |
| — | oléoduc |
| — | oléoduc aérien |
| — | plan incliné |
| — | station de collecte de déchets |
| — | poste de contrôle |
| — | bassin réservoir |
| — | rivière [le terme «rivière» est utilisé si un message porte sur l’entièreté de la rivière (et non pas uniquement sur le chenal navigable)] |
| — | ascenseur à bateaux |
| — | chantier naval |
| — | station de signalisation |
| — | terminal |
| — | échelle/marégraphe |
| — | tunnel |
| — | bassin de virage |
| — | centre de gestion de trafic |
| — | barrage (un barrage sert à contrôler le niveau de l’eau dans les rivières) |
5. Considérations de base relatives au WRM
En règle générale, les messages relatifs aux hauteurs d’eau sont générés automatiquement. Lorsque cela n’est pas possible, la génération manuelle de WRM suit le plus étroitement possible les procédures établies pour les WRM générés automatiquement (voir le NtS Encoding Guide destiné aux développeurs).
6. Considérations de base relatives à l’ICEM et étapes de la publication d’un ICEM
Les messages relatifs à la glace dépendent des observations et évaluations locales et sont habituellement générés par le personnel autorisé.
Un ICEM est émis en cas de présence de glace. La présence de glace n’entraîne pas nécessairement une limitation de la navigation; toutefois, des informations sur les conditions de glace n’entravant pas la navigation peuvent être fournies.
| 6.1. | Est-il nécessaire de publier des informations au moyen d’un NtS ICEM? Le premier message relatif à la glace relatif à un secteur n’est publié qu’en cas de présence de glace sur la voie navigable et ou sur ses affluents, et ce, également s’il n’y a pas de limitations. |
| 6.2. | Un ICEM valide existe-t-il déjà pour le secteur de la voie navigable concerné? |
| 6.2.1. | Oui: Si un message relatif au secteur concerné est (toujours) valide, le message existant est mis à jour. Il est possible de mettre à jour des messages relatifs à la glace existants même si la zone d’applicabilité n’est plus la même (par exemple si la glace s’étend et augmente ainsi la dimension du secteur concerné). |
| 6.2.2. | Non: En l’absence d’un message relatif à la glace valide pour le secteur concerné, un nouveau message doit être créé. |
| 6.3. | Toutefois, des informations sur la condition de glace n’entravant pas la navigation peuvent être fournies. |
| 6.4. | Un ICEM est toujours valide pour un seul secteur de la voie navigable. Le champ géographique de validité doit être déterminé en définissant la voie navigable et les points de début et de fin (hectomètres) pertinents (ou en sélectionnant des secteurs qui se suivent, en fonction de l’application nationale de la réglementation). |
| 6.5. | La durée de la mesure doit être indiquée. Les conditions de glace en question doivent être indiquées en utilisant au moins l’une des listes de codes (en fonction des exigences nationales). |
| 6.5.1. | Ice_condition_code |
| 6.5.2. | Ice_accessibility_code |
| 6.5.3. | Ice_classification_code |
| 6.5.4. | Ice_situation_code (le code relatif à la présence de glace doit toujours être fourni afin de permettre la présentation de la présence de glace sur une carte à l’aide de couleurs de «feux de signalisation»). |
| 6.6. | L’ICEM peut être publié. Les messages relatifs à la glace sont automatiquement valides jusqu’au lendemain de leur publication ou jusqu’au moment déterminé par les procédures nationales. |
7. Considérations de base relatives au WERM
Compte tenu de l’abondance de services web et d’applications disponibles pour effectuer des prévisions et des avertissements météorologiques, le WERM ne devrait être utilisé que pour communiquer des informations météorologiques d’importance particulière pour la navigation qui ne sont pas couvertes par les services généraux d’information météorologique.
En règle générale, les avis météorologiques sont générés automatiquement. Lorsque cela n’est pas possible, la génération manuelle de WERM suit le plus étroitement possible les procédures établies pour les WERM générés automatiquement (voir le NtS Encoding Guide destiné aux développeurs d’applications).
8. Règles relatives à certains éléments
8.1. Règles pour l’élément «name» relatif aux objets
Les noms d’objets sont généralement pré-remplis par l’outil d’édition NtS sur la base des données de référence du RIS Index. Les noms sont indiqués dans la langue locale; par conséquent, des signes diacritiques ou des caractères cyrilliques peuvent également être utilisés (par exemple Baarlerbrücke, Volkeraksluis ou Mannswörth).
Ne pas inclure d’informations sur les caractéristiques de l’élément; le type d’objet n’est pas répété dans le nom, à moins que des informations supplémentaires à ce sujet ne soient fournies.
Par exemple: l’écluse «Schleuse Freudenau» est uniquement appelée «Freudenau», le type d’objet «écluse» est automatiquement ajouté sur la base du type_code.
Par exemple: le nom d’objet du pont ferroviaire de Krems (AT) est «Eisenbahnbrücke Krems». L’information «pont ferroviaire» est incluse dans le nom d’objet, puisqu’il apporte des informations supplémentaires par rapport au type_code «pont».
Par exemple: le nom d’objet d’un pont situé à Linz (AT) est «Nibelungenbrücke». Le mot «brücke» est conservé dans le nom d’objet, puisqu’il fait partie du nom du pont lui-même.
Par exemple: l’échelle de voie navigable «Pegelstelle Wildungsmauer» est appelée «Wildungsmauer» puisque l’information selon laquelle cet objet est une échelle est déjà codée dans le type_code.
Lorsqu’un secteur de voie navigable est la frontière entre deux pays parlant des langues différentes, le nom d’objet national peut être indiqué dans les deux langues (par exemple «Staatsgrenze AT-SK/Statna hranica AT-SK»).
8.2. Règles pour l’élément «name» relatif aux chenaux navigables
Les noms de chenaux navigables sont généralement pré-remplis par l’outil d’édition NtS sur la base des données de référence du RIS Index. Le champ «name» contient le nom local du secteur de chenal navigable concerné (par exemple «Rhein»). En fonction des procédures nationales, il peut être possible de modifier le nom du chenal afin d’y inclure les noms ou ajouts locaux communément utilisés (par exemple «Rhein am Deutschen Eck»).
8.3. Règles pour les éléments «value» et «unit» des limitations
Sauf indication contraire, les seules unités pouvant être utilisées dans les messages NtS sont: cm, m3/s, h, km/h et kW, m/s (vent), mm/h (pluie) et degré Celsius.
B. NTS ENCODING GUIDE DESTINÉ AUX DÉVELOPPEURS D’APPLICATIONS
TABLE DES MATIÈRES
| 1. | Contexte et structure | 24 |
| 1.1. | Purpose of NtS Encoding Guide | 24 |
| 1.1.1. | NtS Encoding Guide for editors | 24 |
| 1.1.2. | NtS Encoding Guide for application developers (this document) | 24 |
| 2. | NtS messages and sections | 24 |
| 3. | WRM basic considerations | 26 |
| 3.1. | Filling of nts_number section in the WRM | 26 |
| 3.2. | Filling of WRM including predictions | 26 |
| 4. | ICEM processes | 27 |
| 4.1. | New ICEM | 28 |
| 4.2. | Update of an existing ICEM | 28 |
| 5. | WERM basic considerations | 29 |
| 5.1. | Filling of nts_number section in the WERM | 29 |
| 5.2. | Filling of WERM «weather_category_code» | 29 |
| 6. | FTM processes | 30 |
| 6.1. | New FTM | 30 |
| 6.2. | Update/withdrawal of an existing FTM | 30 |
| 6.3. | Waterway and/or object related FTM | 31 |
| 6.4. | Automatic ordering of limitation codes | 31 |
| 6.5. | Handling of limitation period | 32 |
| 7. | General implementation rules | 33 |
| 7.1. | Filling of the «number_section» | 33 |
| 7.2. | Filling of elements «from», «originator», «organisation» and «source» | 33 |
| 7.3. | Omission of elements | 34 |
| 7.4. | Automatic filling of date_issue | 34 |
| 7.5. | Handling of time zone information in NtS messages | 34 |
| 7.6. | Handling of Seconds in NtS messages | 34 |
| 7.7. | Format of decimals in NtS messages | 34 |
| 7.8. | Units to be used in NtS messages | 34 |
| 7.9. | Rules for the elements «name», «position_code» and «type_code» | 34 |
| 7.10. | Rules for the element «fairway_name» | 38 |
| 7.11. | Clarifications for translations in the spreadsheet «reference_code» | 38 |
| 7.12. | Recommendation for the element «coordinate» | 38 |
| 7.13. | Handling of target groups | 38 |
| 7.14. | Display of valid messages at a given time | 39 |
| 7.15. | Optional functions to increase user friendliness of NtS editor tools | 39 |
| 8. | NtS XML Message Structure | 39 |
| 9. | NtS Web Service | 39 |
| 9.1. | Objective | 39 |
| 9.2. | Basic Principles and constraints | 40 |
| 9.2.1. | Web standards | 40 |
| 9.2.2. | Interaction model and encoding method for NtS WS | 40 |
| 9.3. | General specifications and recommendations | 40 |
| 9.3.1. | Specification: Version information | 40 |
| 9.3.2. | Specification: Structure of namespaces | 41 |
| 9.3.3. | Recommendation: Use of namespaces | 41 |
| 9.3.4. | Recommendation: Use of namespace prefixes | 41 |
| 9.3.5. | Specification: Use of ISRS Location Codes | 41 |
| 9.4. | NtS Message Service (implementation specification) | 46 |
| 9.4.1. | Request | 46 |
| 9.4.2. | Response | 47 |
| 9.5. | Generation of services and clients | 48 |
| Glossary | 48 |
1. Contexte et structure
Les avis à la batellerie (NtS) étaient mis en œuvre dans plusieurs pays européens au titre du règlement (CE) no 416/2007 de la Commission concernant les spécifications techniques des avis à la batellerie visées à l’article 5 de la directive 2005/44/CE du Parlement européen et du Conseil relative à des services d’information fluviale (SIF). La norme NtS fait l’objet d’un processus d’amélioration continu. Une avancée majeure a été la publication du NtS Web Service, qui facilite les échanges de messages NtS entre les autorités et entre les autorités et les utilisateurs de NtS, ainsi que la rationalisation du codage des messages NtS sur la base de la NtS XSD 4.0.
1.1. Objet du NtS Encoding Guide
Le NtS Encoding Guide explique l’applicabilité des quatre types de NtS, ainsi que les codes à utiliser pour certains événements. Il fournit aux éditeurs de NtS des instructions pour remplir les messages NtS et permet ainsi l’harmonisation du codage de ces derniers sur le plan national et international.
Compte tenu de l’utilisation accrue du NtS Web Service, les NtS sont davantage harmonisés afin d’assurer un affichage adéquat de leur contenu sur les systèmes de tierces parties. Un codage uniforme des messages est également essentiel à la prise en compte des messages dans les applications de planification des voyages. La version 1.0 du NtS Encoding Guide applique la NtS XSD 4.0 et le NtS Web Service WSDL 2.0.4.0.
1.1.1.
Le NtS Encoding Guide destiné aux éditeurs s’adresse au personnel qui rédige (et publie) les NtS. Il inclut des instructions étape par étape pour la création des types de messages adéquats, ainsi qu’une explication des codes. Le NtS Encoding Guide destiné aux éditeurs comprend également des informations pertinentes pour les développeurs d’applications.
1.1.2.
Le NtS Encoding Guide destiné aux développeurs contient des lignes directrices pour l’exécution d’applications pour les NtS, en expliquant leur logique, leurs processus et leurs valeurs automatiques/par défaut.
2. Messages et sections des NtS
Un message NtS est constitué des éléments suivants:
| — | la section «Identification» |
| — | une section définissant le ou les objets ou secteurs du chenal navigable auxquels se rapporte l’avis |
| — | une ou plusieurs des sections suivantes, en fonction du type de message:
|
Figure 2
Visualisation de la structure des NtS: élément obligatoire (1), élément obligatoire pouvant apparaître une ou deux fois (1…2), élément obligatoire devant apparaître deux fois (2), élément obligatoire pouvant apparaître autant de fois que nécessaire (1-n), élément facultatif pouvant apparaître autant de fois que nécessaire (0…n)
Règlement (UE) 2014/517 21/12/2018 Règlement d'exécution (UE) 2018/2053 du Conseil du 21 décembre 2018 mettant en œuvre le règlement (UE) n° 401/2013 concernant des mesures restrictives instituées à l'encontre du Myanmar/de la Birmanie 21/12/2018 Règlement (UE) 2004/725 20/12/2018 Règlement (UE) 2017/1469 20/12/2018
Documents similaires
Règlement32014R0517R(09)Règlement32018R2053Règlement32004R0725R(02)Règlement32017R1469R(02)