02007R0416 — FR — 29.12.2018 — 001.001

Ce texte constitue seulement un outil de documentation et n’a aucun effet juridique. Les institutions de l'Union déclinent toute responsabilité quant à son contenu. Les versions faisant foi des actes concernés, y compris leurs préambules, sont celles qui ont été publiées au Journal officiel de l’Union européenne et sont disponibles sur EUR-Lex. Ces textes officiels peuvent être consultés directement en cliquant sur les liens qui figurent dans ce document

Modifié par:









▼B

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







Article premier

Le présent règlement définit les spécifications techniques des avis à la batellerie. Celles-ci sont présentées dans 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.

▼M1









ANNEXE

TABLE DES MATIÈRES 1. DISPOSITIONS GÉNÉRALES 1.1. Définitions 1.2. Fonctions principales et performances requises pour les avis à la batellerie (NtS) 2. FOURNITURE D’AVIS À LA BATELLERIE 3. TYPES DE NtS 4. STRUCTURE ET CODAGE DES NTS 4.1. Structure générale 4.1.1. Section «Identification» 4.1.2. Message relatif à la voie navigable et au trafic 4.1.3. Message relatif aux hauteurs d’eau 4.1.4. Message relatif à la glace 4.1.5. Avis météorologique 4.2. Explication des champs XML et des valeurs figurant dans les NtS Reference Tables 4.3. Identification des secteurs du chenal navigable et des objets dans les NtS 4.4. Règles pour le codage des NtS Appendice A: NtS Encoding Guide destiné aux éditeurs Appendice B: NtS Encoding Guide destiné aux développeurs d’applications Appendice C: Description du schéma XML pour les NtS (XSD) Appendice D: Spécification du NtS Web Service (WSDL)

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

— Country code (2 chiffres, alphanumérique) ( 3 ), et

— Location code (3 chiffres, alphanumérique, «XXX» si indisponible).

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









NTS ENCODING GUIDE DESTINÉ AUX ÉDITEURS

TABLE DES MATIÈRES 1. Contexte, structure et objet des NtS Encoding Guides 11 2. Sélection du type de NtS 3. Considérations de base relatives au FTM et étapes de la publication d’un FTM 4. Explication des codes d’un FTM 5. Considérations de base relatives au WRM 6. Considérations de base relatives à l’ICEM et étapes de la publication d’un ICEM 7. Considérations de base relatives au WERM 8. Règles relatives à certains éléments

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:

a) si sa période de validité n’a pas encore débuté, les dates de début et de fin doivent être définies à la date d'annulation.

b) si sa période de validité a déjà débuté, les nouvelles dates de fin de toutes les limitations doivent être définies à un temps révolu et la date de fin de validité doit être définie à la date d'annulation.

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 — — la date actuelle est antérieure à la date de début de validité. Dans ce cas, seul le contenu du champ «Informations supplémentaires dans la langue nationale» peut être modifié; le reste du contenu du message doit rester inchangé. Dans ce cas, «Avis annulé» est utilisé pour retirer une information avant qu’elle ne devienne valide. «Avis annulé» est donc utilisé pour les informations qui n’ont pas atteint leur date de début de validité et/ou pour les mesures planifiées qui ne seront pas exécutées (par exemple, un dragage était prévu, mais ne peut être entamé en raison d’une hauteur d’eau élevée); — la période de validité a déjà débuté et les nouvelles dates de fin de toutes les limitations sont définies pour une période révolue. La date de fin de validité doit être définie à la date d'annulation. — 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: — — via un sas; — via une passe de pont; — via un point précis du chenal navigable; — sur un secteur précis du chenal navigable.

— 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) — — par la fermeture d’un sas ou de plusieurs sas d’une écluse, dont un sas au moins reste ouvert, — par la fermeture d’une ou plusieurs passes de pont, dont une passe au moins reste ouverte.

— 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: — — tirant d’eau du bateau, — largeur du bateau, — largeur du convoi, — longueur du bateau, — longueur du convoi, — tirant d'air du bateau. — 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: — — hauteur libre, — longueur disponible, — largeur disponible, — mouillage disponible. — 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: — — Puissance minimum, — Navigation alternée, — Interdiction de virer, — Interdiction de croiser, — Dépassement interdit, — Interdiction de stationner, — Interdiction d'amarrage, — Ancrage interdit, — Remous interdits, — Limite de vitesse, — Interdiction de débarquer. — 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: — — Lundi, — Mardi, — Mercredi, — Jeudi, — Vendredi, — Samedi, — Dimanche, — Lundi au vendredi, — Samedi et dimanche.

— «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. réduit par → ceci est une valeur relative

4.5.3. maximum → ceci est une valeur absolue

4.5.4. minimum → ceci est une valeur absolue

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.









NTS ENCODING GUIDE DESTINÉ AUX DÉVELOPPEURS D’APPLICATIONS

TABLE DES MATIÈRES 1. Contexte et structure 1.1. Purpose of NtS Encoding Guide 1.1.1. NtS Encoding Guide for editors 1.1.2. NtS Encoding Guide for application developers (this document) 2. NtS messages and sections 3. WRM basic considerations 3.1. Filling of nts_number section in the WRM 3.2. Filling of WRM including predictions 4. ICEM processes 4.1. New ICEM 4.2. Update of an existing ICEM 5. WERM basic considerations 5.1. Filling of nts_number section in the WERM 5.2. Filling of WERM «weather_category_code» 6. FTM processes 6.1. New FTM 6.2. Update/withdrawal of an existing FTM 6.3. Waterway and/or object related FTM 6.4. Automatic ordering of limitation codes 6.5. Handling of limitation period 7. General implementation rules 7.1. Filling of the «number_section» 7.2. Filling of elements «from», «originator», «organisation» and «source» 7.3. Omission of elements 7.4. Automatic filling of date_issue 7.5. Handling of time zone information in NtS messages 7.6. Handling of Seconds in NtS messages 7.7. Format of decimals in NtS messages 7.8. Units to be used in NtS messages 7.9. Rules for the elements «name», «position_code» and «type_code» 7.10. Rules for the element «fairway_name» 7.11. Clarifications for translations in the spreadsheet «reference_code» 7.12. Recommendation for the element «coordinate» 7.13. Handling of target groups 7.14. Display of valid messages at a given time 7.15. Optional functions to increase user friendliness of NtS editor tools 8. NtS XML Message Structure 9. NtS Web Service 9.1. Objective 9.2. Basic Principles and constraints 9.2.1. Web standards 9.2.2. Interaction model and encoding method for NtS WS 9.3. General specifications and recommendations 9.3.1. Specification: Version information 9.3.2. Specification: Structure of namespaces 9.3.3. Recommendation: Use of namespaces 9.3.4. Recommendation: Use of namespace prefixes 9.3.5. Specification: Use of ISRS Location Codes 9.4. NtS Message Service (implementation specification) 9.4.1. Request 9.4.2. Response 9.5. Generation of services and clients Glossary

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. NtS Encoding Guide destiné aux éditeurs

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. NtS Encoding Guide destiné aux développeurs d’applications (le présent document)

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: — — limitation(s) pour les messages relatifs à la voie navigable et au trafic, — mesure(s) pour les messages relatifs aux hauteurs d’eau, — condition(s) de glace pour les messages relatifs à la glace, — bulletin(s) météorologique(s) pour les avis météorologiques.

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)

La section «Identification» est obligatoire et comprend des informations générales sur l’émissaire, l’expéditeur, la date d’émission, le pays et la langue d’origine du message. Elle s’accompagne de l’un des quatre différents types de sections d’un message NtS:

— Fairway and traffic related section: les «messages relatifs à la voie navigable et au trafic» (FTM) sont généralement créés par les éditeurs de NtS sur la base du NtS Encoding Guide destiné aux éditeurs. Ils se rapportent à des secteurs de voie navigable (définis par leurs ISRS Location Codes de début et de fin et/ou par les objets présents sur la voie navigable, définis par leur ISRS Location Code respectif). [aller au chapitre 6]

— Water level related section: un «message relatif aux hauteurs d’eau» (WRM) facilite la fourniture d’informations sur les niveaux d’eau actuels et prévus, ainsi que d’autres informations. En général, les WRM sont créés automatiquement (et périodiquement) sur la base de mesures effectuées par des capteurs ou de l’état de l’infrastructure et ne nécessitent donc pas d’interaction des éditeurs de NtS. La section du message relatif aux hauteurs d’eau contient des informations relatives à un objet (par exemple une station de jaugeage) ou à un secteur de chenal navigable (par exemple, la profondeur minimale pour une partie du chenal, ou le régime applicable sur un secteur de voie 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. [aller au chapitre 3]

— Ice related section: un «message relatif à la glace» (ICEM) contient 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. [aller au chapitre 4]

— Weather related section: un «avis météorologique» (WERM) permet la fourniture de relevés et de prévisions météorologiques relatifs à une portion de voie navigable définie par ses ISRS Location Codes de début et de fin. [aller au chapitre 5]

En outre, l’ISRS Location Code (International Ship Reporting Standard) est utilisé pour définir le ou les objets ou secteurs de chenal navigable sur lesquels porte le message.

L’ISRS Location Code est défini au point 4.3 de l’annexe du présent règlement.

3. Considérations de base relatives au WRM

Les informations relatives aux hauteurs d’eau sont importantes à la fois pour la planification du voyage et pour la sécurité. Actuellement, il n’existe pas de standard commun pour le référencement des informations relatives aux hauteurs d’eau. Les valeurs des échelles sont basées sur différents niveaux de la mer ou sur des valeurs spécifiques aux échelles pour le niveau zéro. Pour formuler une référence adéquate, il y a lieu de toujours fournir le «reference_code» pertinent avec la valeur. Les WRM peuvent être utilisés pour fournir les informations suivantes:

— les hauteurs d’eau (y compris les prévisions),

— la profondeur minimale (y compris les prévisions),

— le tirant d’air (y compris les prévisions),

— les débits (y compris les prévisions),

— les statuts des barrages,

— le régime.

Des précisions pour les traductions dans la feuille de calcul «reference_code»Clarifications for translations in the spreadsheet «reference_code» sont fournies au chapitre 7.11.

En général, les WRM sont créés et publiés automatiquement sur la base des informations reçues d’un appareil de détection ou d’une infrastructure (par exemple des prévisions ou les statuts d’un barrage). Divers facteurs peuvent déclencher la publication d’un WRM; celle-ci peut intervenir périodiquement ou lorsque certaines valeurs sont atteintes.

3.1. Remplissage de la section nts_number du WRM

Dans la NtS XSD 4.0, le numéro de NtS est facultatif dans les messages WRM. S’il est indiqué, chaque numéro doit être unique (Organisation/Year/Number/Serial) à chaque type de message et il incombe à l’organisation qui fournit le WRM de garantir le caractère unique des numéros (il n’est pas obligatoire d’utiliser des numéros consécutifs).

3.2. Remplissage du WRM, y compris prévisions

La date_start de la validity_period doit être remplie en indiquant la date actuelle (date_issue) et la date_end de la validity_period doit être remplie en indiquant le lendemain de la date_issue.

Pour indiquer les changements, par exemple des hauteurs d’eau, d’une manière qui soit facilement compréhensible pour l’utilisateur, la différence par rapport à une précédente mesure comparative peut être indiquée dans la section «différence» du WRM. En plus de la variation de la valeur (par exemple - 5 [cm]), il convient également d’indiquer le temps écoulé depuis la mesure comparative.

Pour les prévisions, la «measure_date» est la date/l’heure pour laquelle la prévision est valable.

Les prévisions des hauteurs d’eau comportent toujours un facteur d'incertitude. En général, des modèles incluant différents paramètres (par exemple un bulletin météorologique) sont calculés et donnent différentes prévisions des valeurs de hauteurs d’eau. Afin de permettre la fourniture d’une valeur prévue minimale et maximale, par exemple une visualisation d’un intervalle de confiance concernant les prévisions des hauteurs d’eau, deux champs de données supplémentaires facultatifs sont inclus dans la section «mesure» du WRM.

Une illustration d’un intervalle de confiance concernant les prévisions des hauteurs d’eau est proposée dans la figure suivante:

Figure 3

Visualisation de l’intervalle de confiance concernant les prévisions des hauteurs d’eau: valeur la plus probable (noir), bande supérieure de l’intervalle de confiance (violet), bande inférieure de l’intervalle de confiance (rouge), hauteurs d’eau mesurées (bleu)

(L’axe des abscisses indique le temps; l’axe des ordonnées indique les hauteurs d’eau en cm.)

Deux éléments sont disponibles dans la NtS XSD:

<value_min> valeur la plus basse de l’intervalle de confiance

<value_max> valeur la plus élevée de l’intervalle de confiance

En plus d’être utilisé pour les prévisions des hauteurs d’eau, l’intervalle de confiance peut également servir à indiquer l’incertitude d’informations publiées sur la profondeur minimale et le tirant d’air.

Les value_min et value_max de l’intervalle de confiance permettent de fournir un intervalle de confiance concernant la valeur du WRM via un message NtS WRM standardisé, qui peut être utilisé dans des graphiques. Les données brutes elles-mêmes ne sont pas visibles aux utilisateurs du transport par voies navigables (par exemple en format code).

Le measure_code «NOM» ne peut pas être utilisé. En l’absence de mesure pour un certain type de WRM, les éléments de valeur doivent rester non remplis si un message doit tout de même être envoyé.

4. Processus ICEM

Les messages relatifs à la glace dépendent des observations et évaluations locales. Ils sont habituellement générés manuellement (lorsqu’ils sont générés automatiquement, il convient de suivre les règles établies pour la création manuelle; voir le NtS Encoding Guide destiné aux éditeurs).

L’ICEM est publié pour un fairway_section donné, défini par ses ISRS Location Codes de début et de fin, et contient la ice_condition valable à une date de mesure donnée.

La validité de l’ICEM débute à sa date de publication (définie automatiquement par l’application NtS). Afin d’éviter que des ICEM qui ne sont plus valides soient visibles aux utilisateurs, la date_end de validité doit être automatiquement remplie par l’application NtS, en indiquant le lendemain de la publication (à moins que des processus nationaux ne garantissent que les messages obtiendront une date de fin de validité dès que les informations qui y figurent deviendront obsolètes).

Le NtS Encoding Guide destiné aux éditeurs décrit les circonstances dans lesquelles un éditeur de NtS doit créer un nouvel ICEM ou mettre à jour un ICEM existant. Les processus suivants doivent être appliqués:

4.1. Nouvel ICEM

1) Les applications NtS peuvent proposer aux éditeurs de NtS

a) d’utiliser des avis existants comme ébauche pour créer un nouvel ICEM (par exemple, si les conditions de glace sont similaires à celles indiquées dans l’avis existant), et/ou

b) d’utiliser des modèles d’avis pour certaines situations.

2) Le contenu (par exemple l’heure de mesure ou les conditions de glace pertinentes) doit être encodé par l’éditeur conformément au chapitre 6 du NtS Encoding Guide destiné aux éditeurs. La date et l’heure de la mesure peuvent également être définies par l’application sur la base de définitions nationales.

3) Lorsqu’un éditeur/publicateur de NtS déclenche l’action «publication»,

a) il est vérifié si l’ensemble du contenu obligatoire est fourni conformément à la NtS XSD [si ce n’est pas le cas, revenir au point 2)];

b) le nts_number est généré par l’application NtS;

i. «organisation» est rempli en indiquant le nom ou le code de l’organisation responsable, en fonction du rôle de l’utilisateur effectuant la publication;

ii. «year» est rempli en indiquant l’année en cours;

iii. le «number» suivant disponible est assigné;

iv. le «serial number» 0 est assigné.

c) «date_issue» est automatiquement rempli avec la date/l’heure effectives de l’action de publication;

d) «validity_period» — «date_start» est automatiquement rempli avec la date effective de publication;

e) «validity_period» — «date_end» est automatiquement rempli avec le jour suivant la date de publication (à moins que des processus nationaux ne garantissent que les messages obtiendront une date de fin de validité dès que les informations qui y figurent deviendront obsolètes).

4.2. Mise à jour d’un ICEM existant

1) Le message publié concerné doit être sélectionné afin d’être mis à jour dans l’outil d’édition des ICEM. L’ICEM original doit être copié ou modifié dans la base de données (en fonction des processus nationaux). Les ICEM expirés (qui ont dépassé la validity_date_end) ne peuvent plus être mis à jour; dans ce cas, l’éditeur de NtS doit créer un nouvel ICEM.

2) Le contenu (par exemple l’heure de mesure ou les conditions de glace pertinentes) doit être modifié par l’éditeur conformément au chapitre 6 du NtS Encoding Guide destiné aux éditeurs. La date et l’heure de la mesure peuvent également être modifiées par l’application sur la base de définitions nationales.

3) Lorsqu’un éditeur/publicateur de NtS déclenche l’action «publication»,

a) il est vérifié si l’ensemble du contenu obligatoire est fourni conformément à la NtS XSD [si ce n’est pas le cas, revenir au point 2)];

b) le nts_number est généré par l’application NtS;

i. «organisation» demeure inchangé;

ii. «year» demeure inchangé;

iii. «number» demeure inchangé;

iv. le «serial number» est augmenté (de 1);

c) «date_issue» est automatiquement rempli avec la date/l’heure effectives de l’action de publication;

d) «validity_period» — «date_start» est automatiquement rempli avec la date effective de publication;

e) «validity_period» — «date_end» est automatiquement rempli avec le jour suivant la date de publication (à moins que des processus nationaux ne garantissent que les messages obtiendront une date de fin de validité dès que les informations qui y figurent deviendront obsolètes).

5. Considérations de base relatives au WERM

En général, les WERM sont créés et publiés automatiquement sur la base des informations reçues d’un appareil de détection ou d’une infrastructure. La date_start de la validity_period doit être remplie en indiquant la date actuelle (date_issue) et la date_end de la validity_period doit être remplie en indiquant le lendemain de la date_issue.

Dans un WERM, le secteur de chenal navigable est indiqué comme étant un segment entre deux points du chenal, c’est-à-dire une zone d’applicabilité de la station météorologique (échelle).

La date et l’heure de la mesure/de la prévision doivent être fournies même si elles ne sont pas obligatoires dans les messages WERM.

Pour les prévisions, la «measure_date» est la date/l’heure pour laquelle la prévision est valable.

5.1. Remplissage de la section nts_number du WERM

Dans la NtS XSD 4.0, le numéro de NtS est facultatif dans les messages WERM. S’il est indiqué, chaque numéro doit être unique (Organisation/Year/Number/Serial) à chaque type de message et il incombe à l’organisation qui fournit le WERM de garantir le caractère unique des numéros (il n’est pas obligatoire d’utiliser des numéros consécutifs).

5.2. Remplissage du champ «weather_category_code» du WERM

La vitesse du vent dans le champ «weather_category_code» (valeurs de 0 à 12) est indiquée conformément à l’échelle de Beaufort publiée par l’Organisation météorologique mondiale dans son Manuel de l’assistance météorologique aux activités maritimes (OMM-No 558).

La visibilité dans le champ «weather_category_code» (valeurs 13 à 22) est indiquée comme défini dans le tableau suivant:







Valeur, signification Visibilité Informations supplémentaires 13, brouillard épais à moins de 50 mètres 14, brouillard dense à moins de 100 mètres 15, brouillard modéré à moins de 200 mètres 16, brouillard à moins de 1 000 mètres Brouillard consistant en gouttelettes d’eau. 17, brouillard léger Entre 1 km et 4 km Brouillard léger consistant en gouttelettes d’eau. Le terme «brouillard léger» est utilisé en cas de «brouillard sec», un phénomène qui se produit généralement avant le lever du soleil. 18, brume Entre 1 km et 4 km Brume constituée de particules sèches 19, brume légère Entre 4 km et 10 km 20, clair Entre 10 km et 20 km 21, très clair pas de limitation de la visibilité 22, pas de brouillard «pas de brouillard» est utilisé pour indiquer qu’il n’y a pas de brouillard, en fonction des exigences nationales/locales.

6. Processus FTM

Le NtS Encoding Guide destiné aux éditeurs décrit les circonstances dans lesquelles un éditeur de NtS crée un nouveau FTM ou mettre à jour un FTM existant. Les processus suivants doivent être appliqués:

6.1. Nouveau FTM

1) Les applications NtS peuvent proposer aux éditeurs de NtS

a) d’utiliser des avis existants comme ébauches pour créer un nouveau FTM et/ou

b) d’utiliser des modèles d’avis pour certaines situations.

2) Le contenu (par exemple la durée de validité ou les limitations) doit être encodé par l’éditeur conformément aux chapitres 3 et 4 du NtS Encoding Guide destiné aux éditeurs.

3) Lorsqu’un éditeur/publicateur de NtS déclenche l’action «publication»,

a) il est vérifié si l’ensemble du contenu obligatoire est fourni conformément à la NtS XSD [si ce n’est pas le cas, revenir au point 2)];

b) le nts_number est généré par l’application NtS;

i. «organisation» est rempli en indiquant le nom ou le code de l’organisation responsable, en fonction du rôle de l’utilisateur effectuant la publication;

ii. «year» est rempli en indiquant l’année en cours;

iii. le «number» suivant disponible est assigné; si un numéro spécial a été encodé par l’éditeur de NtS ou un processus de l’application à l’étape 2, il est remplacé (étant donné que le numéro Organisation/Year/Number/Serial est unique, comme expliqué au chapitre 15.1);

iv. le «serial number» 0 est assigné;

c) «date_issue» est automatiquement rempli avec la date/l’heure effectives de l’action de publication.

6.2. Mise à jour/annulation d’un FTM existant

1) Le message publié concerné doit être sélectionné afin d’être mis à jour dans l’outil d’édition des FTM. Le FTM original doit être copié ou modifié dans la base de données (en fonction des processus nationaux).

a) Les FTM expirés (qui ont dépassé la validity_date_end) ne peuvent plus être mis à jour; dans ce cas, l’éditeur de NtS doit créer un nouveau FTM.

b) Le code sujet «Avis annulé» n’est utilisé que si

i. la date actuelle est antérieure à la validity_date_start. Lorsque seul le contenu du champ «Informations supplémentaires dans la langue nationale» peut être modifié, le contenu codé du message (étape 2) doit rester inchangé;

ii. la période de validité a déjà débuté et les nouvelles dates de fin de toutes les limitations sont définies pour une période révolue. La date de fin de la limitation doit être définie à l’heure correcte.

c) Lorsqu’un avis est annulé, la date de fin de la période de validité doit toujours être définie à la date d'annulation.

2) Le contenu (par exemple la durée de validité ou les limitations) doit être modifié par l’éditeur conformément aux chapitres 3 et 4 du NtS Encoding Guide destiné aux éditeurs.

3) Lorsqu’un éditeur/publicateur de NtS déclenche l’action «publication»,

a) il est vérifié si l’ensemble du contenu obligatoire est fourni conformément à la NtS XSD [si ce n’est pas le cas, revenir au point 2)];

b) le nts_number est généré par l’application NtS;

i. «organisation» demeure inchangé;

ii. «year» demeure inchangé;

iii. «number» demeure inchangé;

iv. le «serial number» est augmenté (de 1);

c) «date_issue» est automatiquement rempli avec la date/l’heure effectives de l’action de publication;

d) Les FTM dont le code sujet est «Avis annulé» ne sont pas (plus) pris en considération pour la planification des voyages.

6.3. FTM relatifs aux voies navigables et/ou aux objets

Un FTM relatif à une voie navigable contient des informations sur un ou plusieurs secteurs de voie navigable. Un secteur de voie navigable est défini dans la partie «fairway_section» par ses ISRS Location Codes de début et de fin.

Un FTM relatif à un objet contient des informations sur un ou plusieurs objets spécifiques présents sur la voie navigable. Un objet est défini dans la partie «objet» par son ISRS Location Code.

Un FTM doit faire référence

— à un ou plusieurs secteurs de chenal navigable, ou

— à un ou plusieurs objets présents sur un ou plusieurs secteurs de chenal navigable.

6.4. Ordonnancement automatique des codes de limitation

Différentes limitations ont différentes incidences sur la navigation. Afin de permettre l’affichage de la limitation la plus stricte, par exemple dans un aperçu des FTM sous forme de liste, l’ordre suivant est pris en considération, la limitation la plus stricte étant classée no 1:







Classement Valeur Signification (EN) 1 OBSTRU blockage 2 PAROBS partial obstruction 3 NOSERV no service 4 SERVIC changed service 5 VESDRA vessel draught 6 VESBRE vessel breadth 7 CONBRE convoy breadth 8 VESLEN vessel length 9 CONLEN convoy length 10 CLEHEI clearance height 11 VESHEI vessel air draught 12 AVALEN available length 13 CLEWID clearance width 14 AVADEP available depth 15 LEADEP least depth sounded 16 DELAY delay 17 ALTER alternate traffic direction 18 TURNIN no turning 19 PASSIN no passing 20 OVRTAK no overtaking 21 NOBERT no berthing 22 NOMOOR no mooring 23 ANCHOR no anchoring 24 SPEED speed limit 25 WAVWAS no wash of waves 26 NOSHORE not allowed to go ashore 27 MINPWR minimum power 28 CAUTIO special caution 29 NOLIM no limitation

6.5. Traitement des périodes de limitation

— Les limitations portant sur les mêmes périodes devraient être regroupées/répertoriées ensemble/combinées en vue de leur affichage, afin d’en faciliter la lecture.

— Les outils d’édition des NtS devraient prévoir une fonction permettant aux éditeurs d’éviter de devoir recoder les périodes de limitation.

— Toutes les limitations doivent inclure une période de limitation comprenant un code d’intervalle afin de permettre aux applications de planification des voyages d’effectuer des calculs corrects. Afin de faciliter le travail des éditeurs de NtS, les fonctions suivantes peuvent être mises en œuvre:

— L’outil d’édition des NtS peut prévoir une fonction permettant de copier les limitations déjà codées, afin d’éviter à l'éditeur de NtS de devoir recoder la période de limitation.

— Les outils d’édition des NtS peuvent prévoir une fonction permettant de sélectionner plusieurs codes de limitation pour une période de limitation donnée et de créer automatiquement les sections «Limitations» nécessaires sur la base des informations codées par l’éditeur de NtS.

—« Lundi au vendredi excepté jours fériés»: la valeur «jours fériés» pose beaucoup de problèmes aux applications de planification des voyages. Une liste des jours fériés de chaque pays est nécessaire pour permettre des calculs corrects. Si aucune liste de ce genre n’est disponible, les limitations pertinentes seront tout de même assignées aux jours fériés.

—« à l’exception de»: ne doit pas être utilisé. 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; dès lors, ce code ne sera pas visible/disponible pour les éditeurs d’avis.

— Logique et affichage des informations applicables en cas de code d’intervalle «permanent»:

<date_start>2015-04-01+01</date_start>

<date_end>2015-06-30+02</date_end>

<time_start>06:00:00</time_start>

<time_end>10:00:00</time_end>

<interval_code>CON</interval_code>

Si l’interval_code est permanent, le start_time appartient à la start_date et le end_time appartient à la end_date: par exemple, du 1er avril 06 h 00 au 30 juin 10 h 00.

— Logique et affichage des informations applicables en cas de code d’intervalle autre que «permanent»:

<date_start>2015-04-01+01</date_start>

<date_end>2015-06-30+02</date_end>

<time_start>06:00:00</time_start>

<time_end>10:00:00</time_end>

<interval_code>WRK</interval_code>

Si l’interval_code affiche une autre valeur, le start_time et le end_time appartiennent à cet interval_code: par exemple, du 1er avril au 30 juin, Lundi au vendredi, de 06 h 00 à 10 h 00.

— La fin de la période de limitation doit toujours être indiquée dans la dernière version d’un message.

7. Règles générales d’application

Il doit être tenu compte des éléments suivants:

— Le tableau «GUI_labels» fourni dans les NtS Reference Tables doit être pris en considération lors du développement des applications NtS (masques de recherche, formulaire d’abonnement aux e-mails, affichage des messages).

— La date_end ne peut être antérieure à la date_start.

— Les codes qui ont été désactivés (et ne peuvent plus être utilisés) via des demandes de modification de NtS (voir les commentaires dans la NtS XSD) ne sont pas visibles pour les éditeurs de NtS lors de la création de nouveaux messages. Les codes sont toujours inclus dans les énumérations NtS XSD pour des raisons de rétrocompatibilité.

7.1. Remplissage de «number_section»

Chaque numéro (Organisation/Year/Number/Serial) doit être unique à chaque type de message. Cela signifie que différents types de messages peuvent avoir le même numéro de NtS.

Pour les utilisateurs, les numéros des messages n’ont d’importance que pour les FTM et les ICEM; pour tous les autres types de messages, l’affichage du numéro du message peut être sauté, en fonction des exigences nationales.

Pour les utilisateurs, le numéro du message est affiché au format suivant: «Message Type/Country/Organisation/Year/Number/Serial» (il peut être raccourci en fonction des filtres appliqués si aucune information n’est perdue).

7.2. Remplissage des éléments «from», «originator», «organisation» et «source»

L’élément «from» de la section «Identification» est rempli en indiquant le nom du système national fournissant le message (par exemple ELWIS, DoRIS, SLOVRIS, FLARIS).

L’élément «originator» est l’organisation qui encode le message dans les systèmes nationaux.

L’élément «source» est l’autorité pour laquelle le FTM est publié.

L’élément «organisation» de la section nts_number est le nom de l’organisation assignant le nts_number (fournisseur du NtS).

7.3. Omission d’éléments

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.

Les éléments suivants sont concernés:

— Groupe cible: target_group_code ALL avec direction_code ALL (s’il n’y a aucun autre groupe cible spécifique dans le message),

— position_code: AL,

— reason_code: OTHER.

7.4. Remplissage automatique de l’élément date_issue

FTM et ICEM

Pour les FTM et les ICEM, la valeur de l’élément date_issue est la date et l’heure effectives de publication. Pour les messages mis à jour, date_issue est la date et l’heure à laquelle la mise à jour a été publiée.

WRM et WERM

Pour les WRM et les WERM, la valeur de l’élément date_issue est la date et l’heure de la demande de traitement; en effet, un même message W(E)RM peut inclure plusieurs mesures avec différents horodatages d’émission.

7.5. Traitement des informations sur les fuseaux horaires dans les messages NtS

La date et l’heure sont toujours indiquées en heure locale, y compris les informations sur les fuseaux horaires incluses dans les messages NtS XML.

Les seules exceptions à cette disposition sont les éléments «time_start» et «time_end» de la section «limitation_period». En effet, dans la section «Limitations», un intervalle peut être appliqué. Si la date de début et la date de fin relèvent de fuseaux horaires différents (par exemple CEST et CET), cela entraîne une modification des informations relatives aux fuseaux horaires à l’intérieur de cet intervalle. Cette modification ne peut être exprimée dans le cadre d’une seule période de limitation. Au lieu de créer différentes périodes de limitation pour chaque changement d'heure, on utilise une seule période de limitation sans informations sur les fuseaux horaires, afin de réduire la charge de travail relative au traitement et à la transmission des messages.

7.6. Traitement des secondes dans les messages NtS

En règle générale, les secondes doivent être indiquées dans des champs (date)/heure, mais elles ne sont pas visibles pour les utilisateurs des NtS. Les minutes sont suffisantes pour le niveau de granularité d’un NtS.

7.7. Format des décimales dans les messages NtS

Le séparateur décimal utilisé dans les champs numériques est le point (.). Les nombres sont indiqués sans séparateur de milliers.

Le nombre de décimales utilisées pour les valeurs est limité à la quantité raisonnable pour assurer un affichage clair pour l’utilisateur.

7.8. Unités à utiliser dans les messages NtS

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; pour plus de facilité pour l’utilisateur, les applications peuvent convertir les unités.

En cas de différence entre les unités encodées et les unités standardisées, les valeurs encodées doivent être converties en conséquence par l’application.

7.9. Règles pour les éléments «name», «position_code» et «type_code»

L’élément «name» est automatiquement pré-rempli à partir des données de référence «national object name» du RIS Index (les éditeurs de NtS peuvent modifier le nom pré-rempli s’il s’agit d’une exigence nationale). Les conventions de dénomination des noms d’objet sont incluses dans la version 2.0 du RIS Index Encoding Guide ainsi que dans les versions supérieures. Des exemples de noms d’objets adéquats sont également proposés dans le NtS Encoding Guide destiné aux éditeurs.

Le code de type est ajouté à l’objet par l’application NtS devant le nom de l’objet.

La position des objets est codée sur la base du code de position et est ajoutée à l’objet par l’application NtS sur la base du RIS Index. Les éditeurs peuvent modifier les codes de type et de position pré-remplis. Aucun code de position d’objet n’est fourni pour les geo_objects de la fairway_section.

Un nom d’objet complet se compose de son code de position, de son code de type et de son nom.

Pour faciliter le travail des éditeurs de NtS, la cartographie suivante peut être appliquée dans les outils d’édition des NtS afin d’aider les éditeurs à trouver/sélectionner les bons objets sur la base du function_code du RIS Index ou du type_code du NtS:

Tableau 1

Correspondances «RIS Index function_code» — «NtS type_code»







Function Code Function Code Meaning Type Code Type Code Meaning — — BUAARE E.1.1 Built-Up Areas to be selected by editor BUISGL E.1.2 Building of Navigational Significance to be selected by editor brgare G.1.1 - G.1.6 Bridge Area [C_AGGR()] BRI bridge bridge_5 G.1.1 Bascule Bridge BRO bridge opening bridge_1 G.1.2 Bridges with Bridge Arches BRO bridge opening bridge_1 G.1.3 Fixed Bridge BRO bridge opening bridge_4 G.1.4 Lift Bridge BRO bridge opening bridge_12 G.1.5 Suspension Bridge BRO bridge opening bridge_3 G.1.6 Swing Bridge BRO bridge opening cblohd G.1.8 Overhead Cable CAB cable overhead pipohd G.1.9 Overhead Pipe PPO pipeline overhead bridge_7 G.1.12 Drawbridge BRO bridge opening bunsta G.3.2 Bunker / Fuelling Station BUS Bunker / Fuelling Station cranes G.3.4 Crane to be selected by editor hrbare G.3.9 Harbour Area HAR harbour hrbbsn G.3.10 Harbour Basin HAR harbour ponton G.3.11 Landing Stage, Pontoon to be selected by editor morfac G.3.12 Mooring Facility MOO mooring facility hulkes G.3.14 Permanently Moored Vessel or Facility to be selected by editor prtare G.3.15 Port Area HAR port refdmp G.3.17 Refuse Dump REF refuse dump termnl G.3.19 Terminal TER terminal trm01 G.3.19 RORO-terminal TER terminal trm03 G.3.19 Ferry-terminal TER terminal trm07 G.3.19 Tanker-Terminal TER terminal trm08 G.3.19 Passenger Terminal TER terminal trm10 G.3.19 Container Terminal TER terminal trm11 G.3.19 Bulk Terminal TER terminal vehtrf G.3.20 Vehicle Transfer Location BER berth lokbsn G.4.3 Lock Basin LKB lock basin lkbspt G.4.4 Lock Basin Part LKB lock basin lokare G.4.3 / G.4.4 Lock Area [C_AGGR()] LCK lock excnst G.4.8 Exceptional Navigational Structure SLI ship lift TUN tunnel CBR canal bridge gatcon G.4.9 Opening Barrage BAR weir FLO flood gate wtwgag I.3.4 Waterway Gauge GAU tide gauge FERYRT_2 L.2.1 Cable Ferry FER ferry FERYRT_1 L.2.2 Free Moving Ferry FER ferry feryrt_4 L.2.3 Swinging Wire Ferry FER ferry dismar L.3.2 Distance Mark along Waterway Axis RIV river achare M.1.1 Anchorage Area ANC anchoring area achbrt M.1.2 Anchorage Berth BER berth berths_3 M.1.3 Berth / Fleeting Areas BER berth berths_1 M.1.4 Transhipment Berth BER berth trnbsn M.4.5 Turning Basin TUR turning basin CAN canal FWY fairway rdocal Q.2.1 Radio Calling-In Point (notification point) REP reporting point chkpnt R.1.1 Check Point BCO border control sistat_8 R.2.1 Traffic Sistat — Bridge Passage SIG signal station sistat_6 R.2.2 Traffic Sistat — Lock SIG signal station sistat_10 R.2.3 Traffic Sistat — Oncoming Traffic Indicator SIG signal station sistat_2 R.2.4 Traffic Sitat — Port Entry and Departure SIG signal station pas Passage Points to be selected by editor riscen RIS centre VTC vessel traffic centre specon Special Construction to be selected by editor trafp Traffic Points (first reporting points) REP reporting point junction Waterway node / end of waterway / Junction to be selected by editor waypt Waypoint to be selected by editor Legend: green Direct match (1:1 relation) yellow matching example, other TypeCodes possible (1:n relation) blue no direct match / to be selected by editor

7.10. Règles pour l’élément «fairway_name»

Pour éviter la logique applicative/la nécessité de données de référence adéquates dans le système récepteur (le logiciel affichant l’avis à l’utilisateur), l’élément facultatif «fairway_name» est toujours inclus dans l’élément «geo_object» et automatiquement rempli par l’application NtS avec le «Waterway name» du RIS Index. Les éditeurs de NtS ne modifient pas le contenu de l’élément fairway_name.

7.11. Précisions pour les traductions dans la feuille de calcul «reference_code»

La définition suivante est utilisée pour les valeurs des reference_code fournies dans les NtS Reference Tables:

— NAP: aux Pays-Bas, l’abréviation NAP est utilisée et comprise, NAP n’est pas traduit

— KP: «channel level» est traduit et donc fourni dans la langue nationale

— FZP: seule l’abréviation «FZP» est utilisée (actuellement, elle n’est presque plus utilisée)

— ADR: «Adriatic Sea» est traduit et donc fourni dans la langue nationale

— TAW/DNG: «Tweede algemene waterpassing» (néerlandais) — «Deuxième Nivellement Général» (français) est la hauteur de référence utilisée en Belgique pour exprimer les mesures de la hauteur. 0 est le niveau moyen de la mer à marée basse à Ostende — — Néerlandais: TAW — Français: DNG — Toutes les autres langues: TAW/DNG

— LDC: «low navigable water level Danube Commission» est traduit et donc fourni dans la langue nationale

— HDC: «high navigable water level Danube Commission» est traduit et donc fourni dans la langue nationale

— ETRS: «European Terrestrial Reference System 1989»; l’abréviation «ETRS89» est utilisée dans toutes les langues

7.12. Recommandation pour l’élément «coordonnée»

Bien que l’élément «coordonnée» de la section géo-objet soit facultatif, les coordonnées géographiques sont données selon le système WGS84 au format [d]d mm.mmm[m] N (latitude) et [d][d]d mm.mmm[m] E (longitude), et ce, afin de faire référence aux messages NtS géographiquement.

7.13. Traitement des groupes cibles

La section «groupe cible» se compose du code de groupe cible et du code de direction. Si les deux affichent la valeur ALL, la section est entièrement sautée, en l’absence d’autres groupes cibles spécifiques dans le message. Si une seule des deux valeurs est indiquée, l’autre doit être remplie en indiquant la valeur par défaut ALL, car les deux éléments sont obligatoires.

De plus amples informations sur les groupes cibles se trouvent dans le NtS Encoding Guide destiné aux éditeurs.

7.14. Affichage des messages valides à un moment donné

Les applications utilisent l’élément validity_period pour sélectionner les messages à montrer aux utilisateurs pendant une période requise.

Si le subject_code est INFSER (service d’information), 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).

7.15. Fonctions facultatives pour augmenter la convivialité des outils d’édition des NtS

Les fonctions suivantes peuvent être proposées aux éditeurs de NtS selon les exigences nationales:

— Les applications NtS peuvent proposer aux éditeurs de NtS de sauvegarder les brouillons de messages NtS (il n’est pas nécessaire que le contenu obligatoire soit entièrement renseigné pour sauvegarder un brouillon de message).

— Différents rôles d’utilisateur peuvent être assignés à différents éditeurs [par exemple, les éditeurs autorisés à encoder/modifier un avis ou les publicateurs autorisés à publier des avis (en plus de l’édition)].

8. Structure des messages NtS XML

La structure des messages NtS XML, ainsi que le contenu et la finalité des éléments de données, sont définis et expliqués plus en détail à l’appendice C: Définition du schéma XML pour les NtS (XSD).

9. NtS Web Service

9.1. Objectif

Le groupe d’experts sur les NtS a considéré que la technologie de web service constituait un moyen approprié pour émettre les avis à la batellerie.

Le présent chapitre spécifie le web service destiné à l’émission des avis à la batellerie, dont le nom abrégé est le NtS Web Service. Une importance particulière a été accordée à l’utilisation de normes internationales bien établies.

L’un des objectifs de l’élaboration conceptuelle a été de garantir un équilibre adéquat entre la flexibilité et la solidité du web service obtenu. Les paramètres de filtrage fournis dans les demandes constituent en substance les critères définis dans la norme NtS (secteur de voie navigable avec, facultativement, les points kilométriques de début et de fin, période de validité, date de publication de l’avis). Ces critères semblent suffisamment expressifs, compte tenu des cas de figure du web service, tout en limitant la complexité de leur application.

Le résultat fondamental est un contrat pour le web service, dans lequel les demandes et les réponses sont spécifiées. Les consommateurs du web service peuvent se baser sur ce contrat et les fournisseurs doivent le respecter. Ce contrat est spécifié à l’aide de la norme internationale WSDL.

Chaque État membre participant met en œuvre un ou plusieurs web services pour les différents types de messages des NtS (FTM, WRM, ICEM, WERM) et les propose sur l’internet («service de messages NtS»).

Les modalités techniques de la mise en œuvre du NtS WS, tels que le choix des bases de données, des applications et des plateformes adéquates, ne relèvent pas de la présente spécification, mais de la responsabilité de chaque État membre participant.

Pour établir une communication sécurisée, il convient de tenir compte de différents aspects de sécurité et objectifs de protection. Selon les circonstances, ces aspects ne doivent pas tous être pris en considération. Les priorités établies en ce qui concerne les différents aspects de sécurité, ainsi que le niveau de prise en compte de ceux-ci, peuvent varier. En outre, la faisabilité d’une mesure donnée peut être limitée par les capacités de mise en œuvre technique. Dans le contexte des NtS, toutes les informations sont publiques. Il n’est donc pas nécessaire de sécuriser les données des NtS elles-mêmes pour garantir leur protection. Chaque fournisseur doit donc décider lui-même de la mesure dans laquelle son service appliquera cet aspect.

9.2. Principes fondamentaux et contraintes

9.2.1. Normes Internet

Le NtS Web Service doit être conforme à la norme WS-I Basic Profile 1.1. Ce profil «fournit des orientations en matière d’interopérabilité pour un ensemble essentiel de spécifications de services web non propriétaires, telles que SOAP, WSDL et UDDI» ( 4 ). Les normes les plus pertinentes dans le présent contexte sont:

— XML Schema Definition (XSD),

— Simple Object Access Protocol (SOAP),

— Web Services Description Language (WSDL) et

— Universal Description, Discovery and Integration (UDDI).

Le message de réponse du NtS WS est un message NtS défini selon la norme XML Schema Definition (XSD) à l’appendice C du présent règlement de la Commission.

SOAP est un protocole d’application pour la transmission de données entre systèmes informatiques; il est standardisé par le World Wide Web Consortium (W3C). Les éléments spécifiques du NtS Web Service sont définis conformément aux spécifications WSDL correspondantes à l’appendice D du présent règlement de la Commission. Le schéma de la norme NtS (XSD) est accompagné d’une déclaration d’importation.

UDDI (Universal Description, Discovery and Integration) est ici indiqué en tant que répertoire central, potentiellement international, de services web, dans lequel le NtS Web Service pourrait être enregistré. Dans ce répertoire, les consommateurs potentiels du web service pourraient rechercher et trouver le service. Toutefois, étant donné que les fournisseurs potentiels du NtS Web Service sont limités par les États membres participants et que la spécification WSDL fait partie intégrante de la norme, il n’apparaît pas nécessaire d’effectuer un enregistrement indépendant du NtS Web Service.

9.2.2. Modèle d’interaction et méthode de codage pour le NtS WS

La méthode de codage «Document Literal Wrapped» est utilisée pour le NtS Web Service car elle permet une validation par rapport à un schéma XML et que les noms d’opérations définis dans la spécification WSDL sont directement utilisés en tant que noms de balises XML dans les messages SOAP.

9.3. Spécifications générales et recommandations

9.3.1. Spécification: informations de version

Les informations de version relatives au NtS Web Service se composent de deux sections:

— la version du web service lui-même,

— la version du schéma NtS utilisé par le web service.

La section relative au web service est elle-même composée de deux parties:

— la version majeure du web service,

— la version mineure du web service.

La version majeure est fournie sous la forme d’un nombre entier positif désignant la version majeure du web service.

La version mineure est fournie sous la forme d’un nombre entier non négatif désignant la version mineure du web service incluse dans la version majeure.

La section du schéma NtS contient la version du schéma NtS telle que définie par le groupe d’experts sur les NtS.

Dès lors, la version du NtS Web Service ici spécifiée est la version 2.0.4.0, 2.0 étant la version du web service lui-même et 4.0 étant la version du schéma NtS utilisé.

Des informations explicites sur la version ne sont pas nécessaires dans les demandes ou les réponses du NtS Web Service. Seules quelques versions des services devraient être en ligne en même temps. Les différentes versions sont fournies via différentes URL. Par conséquent, chaque itération d’une mise en œuvre du NtS Web Service appuie une version spécifique du NtS Web Service.

9.3.2. Spécification: structure des espaces de noms

Dans le NtS Web Service, les espaces de noms sont basés sur le domaine web des groupes d’experts du RIS, http://www.ris.eu/

Les espaces de noms comportent une particule indiquant le service correspondant et les informations de version. Le service ici spécifié utilise ainsi l’espace de noms suivant:

Service de messages NtS: http://www.ris.eu/nts.ms/2.0.4.0

9.3.3. Recommandation: utilisation des espaces de noms

Pour une plus grande transparence des documents XML, il est recommandé de définir les espaces de noms dans l’élément le plus indiqué à cet effet des schémas, ainsi que dans les documents types, et de ne pas utiliser de définitions d’espaces de noms locales dans les éléments imbriqués.

9.3.4. Recommandation: utilisation de préfixes d’espaces de noms

Les demandes et les réponses du NtS Web Service utilisent des éléments XML au format qualifié, c’est-à-dire comportant un préfixe d’espace de noms explicite, et des attributs XML au format non qualifié, c’est-à-dire sans préfixe d’espace de noms.

Il est recommandé d’utiliser des préfixes d’espace de noms intuitifs, tels que «nts», pour faciliter la lisibilité humaine.

9.3.5. Spécification: utilisation des ISRS Location Codes

L’ISRS Location Code est expliqué au chapitre 2 du NtS Encoding Guide destiné aux développeurs d’applications ainsi que dans le RIS Index Encoding Guide.

Lorsqu’il interroge un NtS Web Service, le client peut faire référence à divers objets, tels que des secteurs de chenal navigable, des échelles ou des écluses. Si les paramètres correspondants (les éléments identificateurs) sont utilisés, ceux-ci doivent inclure les ISRS Location Codes. Ces paramètres sont habituellement fournis dans les éléments identificateurs, qui contiennent chacun un ou deux identificateurs.

Lors de l’utilisation de ces paramètres, les conventions générales suivantes doivent être respectées:

— Les ISRS Location Codes doivent être fournis sous la forme de codes de 20 caractères complets, c’est-à-dire incluant les zéros de la fin.

— Si deux identificateurs sont fournis dans un même élément identificateur, les deux ISRS Location Codes doivent porter sur la même voie navigable. Autrement dit, les codes doivent inclure certains c