EUR-Lex Access to European Union law

Back to EUR-Lex homepage

This document is an excerpt from the EUR-Lex website

Document 32018R2032

Règlement d’exécution (UE) 2018/2032 de la Commission du 20 novembre 2018 modifiant le règlement (CE) n° 416/2007 concernant les spécifications techniques des avis à la batellerie

C/2018/7581

OJ L 332, 28.12.2018, p. 1–181 (BG, ES, CS, DA, DE, ET, EL, EN, FR, HR, IT, LV, LT, HU, MT, NL, PL, PT, RO, SK, SL, FI, SV)

In force

ELI: http://data.europa.eu/eli/reg_impl/2018/2032/oj

28.12.2018   

FR EN

Journal officiel de l'Union européenne

L 332/1


RÈGLEMENT D’EXÉCUTION (UE) 2018/2032 DE LA COMMISSION

du 20 novembre 2018

modifiant le règlement (CE) no 416/2007 concernant les spécifications techniques des avis à la batellerie

LA COMMISSION EUROPÉENNE,

vu le traité sur le fonctionnement de l’Union européenne,

vu la directive 2005/44/CE du Parlement européen et du Conseil du 7 septembre 2005 relative à des services d’information fluviale (SIF) harmonisés sur les voies navigables communautaires (1), et notamment son article 5, paragraphe 1, point c),

considérant ce qui suit:

(1)

Le règlement (CE) no 416/2007 (2) de la Commission devrait être mis à jour, précisé et clarifié en tenant compte des progrès technologiques et de l’expérience acquise dans le cadre de l’application du règlement (CE) no 416/2007.

(2)

Les spécifications techniques des avis à la batellerie devraient être fondées sur les principes techniques exposés à l’annexe II de la directive 2005/44/CE.

(3)

Afin d’améliorer la sécurité de la navigation, les avis à la batellerie devraient être élargis de manière à inclure un nouveau type d’information concernant les avis météorologiques.

(4)

Les tableaux de référence relatifs aux échelles devraient être supprimés de l’annexe du règlement (CE) no 416/2007, étant donné que les données de référence qui y figurent, telles que les valeurs de référence relatives aux hauteurs d’eau élevées et aux basses eaux, sont dynamiques. Ces données devraient être incluses et maintenues dans le système européen de gestion des données de référence géré par la Commission.

(5)

Il est nécessaire d’améliorer la cohérence de l’édition et du développement des applications afin de créer des services dotés d’un niveau plus élevé d’interopérabilité. Dès lors, les guides de codage destinés aux éditeurs et aux développeurs d’applications devraient être inclus dans les spécifications techniques en tant qu’appendices A et B à l’annexe.

(6)

L’échange de données entre les autorités est recommandé par le règlement (CE) no 416/2007. Afin d’améliorer cet échange de données, les spécifications qui s’y rapportent devraient être énoncées à l’appendice D à l’annexe de manière à permettre aux États membres de rendre leurs systèmes interopérables.

(7)

Afin de faire en sorte que les États membres puissent coder leurs avis à la batellerie de manière cohérente et interopérable, les tableaux de référence inclus à l’appendice E devraient être améliorés. À cet effet, de nouveaux codes devraient être définis dans un nouveau tableau de référence contenant des étiquettes harmonisées d’interface de recherche pour l’interface utilisateur graphique. Par ailleurs, de nouveaux champs, valeurs et codes devraient être ajoutés aux tableaux de référence existants et les éléments redondants devraient être supprimés.

(8)

Les spécifications techniques révisées devraient faire en sorte que les tableaux de référence de l’appendice E soient également disponibles par voie électronique dans le système européen de gestion des données de référence géré par la Commission européenne.

(9)

Conformément à l’article 12, paragraphe 2, de la directive 2005/44/CE, afin de respecter l’article 4 de ladite directive, les États membres devraient prendre les mesures nécessaires pour satisfaire aux exigences définies dans le présent règlement au plus tard trente mois après son entrée en vigueur.

(10)

Il y a donc lieu de modifier le règlement (CE) no 416/2007 en conséquence.

(11)

Les mesures prévues dans le présent règlement sont conformes à l’avis du comité visé à l’article 11 de la directive 2005/44/CE,

A ADOPTÉ LE PRÉSENT RÈGLEMENT:

Article premier

L’annexe du règlement (CE) no 416/2007 est remplacée par le texte figurant à l’annexe du présent règlement.

Article 2

Le présent règlement entre en vigueur le jour suivant celui de sa publication au Journal officiel de l’Union européenne.

Le présent règlement est obligatoire dans tous ses éléments et directement applicable dans tout État membre.

Fait à Bruxelles, le 20 novembre 2018.

Par la Commission

Le président

Jean-Claude JUNCKER


(1)  JO L 255 du 30.9.2005, p. 152.

(2)  Règlement (CE) no 416/2007 de la Commission du 22 mars 2007 concernant les spécifications techniques des avis à la batellerie visées à l’article 5 de la directive 2005/44/CE du Parlement européen et du Conseil relative à des services d’information fluviale (SIF) harmonisés sur les voies navigables communautaires (JO L 105 du 23.4.2007, p. 88).


ANNEXE

TABLE DES MATIÈRES

1.

DISPOSITIONS GÉNÉRALES 4

1.1.

Définitions 4

1.2.

Fonctions principales et performances requises pour les avis à la batellerie (NtS) 4

2.

FOURNITURE D’AVIS À LA BATELLERIE 5

3.

TYPES DE NtS 5

4.

STRUCTURE ET CODAGE DES NTS 5

4.1.

Structure générale 5

4.1.1.

Section «Identification» 6

4.1.2.

Message relatif à la voie navigable et au trafic 6

4.1.3.

Message relatif aux hauteurs d’eau 6

4.1.4.

Message relatif à la glace 7

4.1.5.

Avis météorologique 7

4.2.

Explication des champs XML et des valeurs figurant dans les NtS Reference Tables 7

4.3.

Identification des secteurs du chenal navigable et des objets dans les NtS 7

4.4.

Règles pour le codage des NtS 8
Appendice A: NtS Encoding Guide destiné aux éditeurs 9
Appendice B: NtS Encoding Guide destiné aux développeurs d’applications 22
Appendice C: Description du schéma XML pour les NtS (XSD) 50
Appendice D: Spécification du NtS Web Service (WSDL) 87

1.   DISPOSITIONS GÉNÉRALES

1.1.   Définitions

On entend par «services d’information sur les voies navigables (FIS)» les données géographiques, hydrologiques et administratives relatives à la voie navigable (ou chenal navigable) qui sont utilisées par les bateliers et les gestionnaires de flotte pour planifier, effectuer et superviser un voyage. Le terme «batelier» utilisé dans la présente norme est réputé équivalent au terme «conducteur de bateau» utilisé dans les lignes directrices relatives aux services d’information fluviale (RIS) [règlement (CE) no 414/2007 de la Commission (1)], tandis que le terme «gestionnaire de la flotte» est défini dans le règlement (CE) no 415/2007 de la Commission (2).

Les FIS fournissent des informations dynamiques (par exemple niveaux d’eau, prévisions des niveaux d’eau) et statiques (par exemple heures de fonctionnement des écluses et des ponts) sur l’utilisation et l’état de l’infrastructure des voies navigables, et facilitent donc les décisions tactiques et stratégiques de navigation.

Les moyens habituellement utilisés pour ces services sont notamment les aides visuelles à la navigation, les avis à la batellerie (aux capitaines) publiés par écrit, radiodiffusés, et transmis par les téléphones fixes aux écluses. Le téléphone mobile apporte de nouvelles possibilités pour la transmission de messages vocaux et de données, mais le réseau cellulaire n’est pas disponible en tout temps et en tout lieu. Des FIS personnalisés peuvent être assurés par des services de radiotéléphonie sur les voies navigables intérieures, par l’internet, ou par un service de carte électronique de navigation, tel que le système de visualisation des cartes électroniques et d’informations pour la navigation intérieure (Inland ECDIS) avec une carte électronique de navigation (ENC).

1.2   Fonctions principales et performances requises pour les avis à la batellerie (NtS)

La présente spécification technique pour les NtS énonce les règles à appliquer pour la transmission des informations sur les chenaux navigables via l’internet.

Les NtS:

a)

fournissent des informations sur l’état des chenaux, le trafic, la météo, les niveaux de l’eau et la glace pour les services d’information sur les chenaux;

b)

assurent la traduction automatique des principales indications contenues dans les informations, en utilisant un vocabulaire standard basé sur des listes de codes (les NtS Reference Tables fournis à l’appendice E);

c)

sont transmis selon une structure standardisée des données, afin de faciliter l’intégration des informations dans les systèmes de planification des voyages;

d)

sont compatibles avec la structure de données du RIS Index et de l’Inland ECDIS afin de faciliter leur intégration dans ce dernier, conformément à la directive 2005/44/CE du 7 septembre 2005 relative à des services d’information fluviale (SIF) harmonisés sur les voies navigables communautaires.

Les spécifications techniques des NtS facilitent l’échange de données entre les systèmes NtS de différents pays et vers d’autres applications utilisant les données NtS, dont l’Inland ECDIS.

Certaines informations incluses dans les NtS peuvent être standardisées tandis que d’autres ne peuvent l’être.

La partie standardisée couvre toutes les informations qui sont:

a)

importantes pour la sécurité de la navigation intérieure (par exemple: naufrage d’une petite embarcation sur le côté droit du chenal navigable du Danube, p.k. 2 010);

b)

nécessaires à la planification des voyages (par exemple fermeture d’écluses et diminution du tirant d’air).

D’autres informations non pertinentes aux fins de la sécurité ou de la planification des voyages, telles que le motif de l’interruption du fonctionnement d’une écluse, peuvent être communiquées sous la forme de textes non standardisés, sans traduction automatique. L’utilisation de texte non standardisé est limitée autant que possible.

2.   FOURNITURE D’AVIS À LA BATELLERIE

Les États membres veillent à ce que les NtS soient accessibles en ligne et via le NtS web service standardisé, conformément aux spécifications techniques décrites dans la présente annexe et dans ses appendices. La spécification relative au NtS web service standardisé est incluse à l’appendice D sous la forme d’un langage WSDL (Web Service Description Language).

Les NtS web services standardisés donnent à l’utilisateur la possibilité de sélectionner des avis sur la base d’au moins un des critères suivants:

a)

un secteur spécifique de la voie navigable;

b)

un secteur spécifique de la voie navigable défini par les points kilométriques de début et de fin;

c)

la période de validité de l’avis (date de début et date de fin de la période de validité);

d)

la date de publication de l’avis (date et heure de publication).

Les NtS qui satisfont aux normes énoncées dans la présente annexe peuvent notamment être transmis par les instruments suivants:

a)

applications mobiles (apps);

b)

services de courrier électronique.

Un échange de données entre des systèmes NtS exploités dans différents pays peut avoir lieu. Tous les systèmes utilisant les normes décrites dans l’annexe du présent règlement peuvent intégrer dans leurs propres services les NtS provenant d’autres systèmes, pour autant que le contenu de l’avis ne soit pas modifié. Les utilisateurs sont informés de l’interruption ou de l’indisponibilité de la connexion à une source de NtS intégrés.

3.   TYPES DE NTS

Les NtS constituent des messages essentiels qui sont standardisés autant que possible.

On distingue quatre types de NtS:

a)

les messages relatifs à la voie navigable et au trafic;

b)

les messages relatifs aux hauteurs d’eau;

c)

les messages relatifs à la glace;

d)

les avis météorologiques.

4.   STRUCTURE ET CODAGE DES NTS

On trouvera sous ce point une description de la structure et du codage des NtS électroniques standardisés.

Un NtS est un message structuré utilisant dans la mesure du possible des éléments standardisés. L’utilisation de texte non standardisé dans les éléments d’information est limitée autant que possible.

La description de schéma standardisée en langage de balisage extensible (XML) utilisée pour les NtS, appelée «XSD» dans la présente norme, contient les valeurs standardisées; les formats possibles sont inclus à l’appendice C.

Les valeurs standardisées et les champs XML, leur signification et leur traduction sont fournis dans les NtS Reference Tables inclus à l’appendice E et sont également disponibles par voie électronique dans le système européen de gestion des données de référence (ERDMS) exploité par la Commission européenne.

4.1.   Structure générale

Un NtS est constitué des sections suivantes:

a)

une section «Identification»;

b)

une section définissant le ou les objets ou secteurs du chenal navigable auxquels se rapporte l’avis;

c)

une ou plusieurs limitations (pour les messages relatifs à la voie navigable et au trafic), une ou plusieurs mesures (pour les messages relatifs aux hauteurs d’eau), des informations sur les conditions de glace (pour les messages relatifs à la glace), ou un ou plusieurs bulletins météorologiques (pour les avis météorologiques).

Figure 1

Structure des avis à la batellerie

Image

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


(1)  Règlement (CE) No 414/2007 de la Commission du 13 mars 2007 concernant les lignes directrices techniques pour la planification, la mise en œuvre et le fonctionnement opérationnel des services d’information fluviale (SIF) visés à l’article 5 de la directive 2005/44/CE du Parlement européen et du Conseil relative à des services d’information fluviale (SIF) harmonisés sur les voies navigables communautaires (JO L 105 du 23.4.2007, p. 1).

(2)  Règlement de la Commission (CE) No 415/2007 du 13 mars 2007 concernant les spécifications techniques applicables aux systèmes de suivi et de localisation des bateaux visés à l’article 5 de la directive 2005/44/CE du Parlement européen et du Conseil relative à des services d’information fluviale (SIF) harmonisés sur les voies navigables communautaires (JO L 105 du 23.4.2007, p. 35).

(3)  Les country codes des Nations unies sont définis conformément au point 2.4.2.12 de l’annexe du règlement (UE) no 164/2010 de la Commission (JO L 57 du 6.3.2010, p. 1). Les country codes des Nations unies sont identiques aux country codes de norme ISO 3166-1 alpha 2.

A.   NTS ENCODING GUIDE DESTINÉ AUX ÉDITEURS

TABLE DES MATIÈRES

1.

Contexte, structure et objet des NtS Encoding Guides 11 10

2.

Sélection du type de NtS 10

3.

Considérations de base relatives au FTM et étapes de la publication d’un FTM 10

4.

Explication des codes d’un FTM 12

5.

Considérations de base relatives au WRM 20

6.

Considérations de base relatives à l’ICEM et étapes de la publication d’un ICEM 20

7.

Considérations de base relatives au WERM 20

8.

Règles relatives à certains éléments 21

Abréviations

Abréviation

Signification

CEVNI

Code européen de voies de la navigation intérieure (http://www.unece.org/trans/main/sc3/sc3res.html)

CEN

Carte électronique de navigation

FTM

Message relatif à la voie navigable et au trafic

ICEM

Message relatif à la glace

Inland ECDIS

Système de visualisation des cartes électroniques et d’informations pour la navigation intérieure

ISRS Location Code

Code de localisation «International Ship Reporting Standard»

NtS

Avis à la batellerie

RIS

Services d’information fluviale

VHF

Bande mobile maritime

WERM

Avis météorologique

WRM

Message relatif aux hauteurs d’eau

WSDL

Langage de description de services web

XML

Langage de balisage extensible

XSD

Définition de schéma XML

1.   Contexte, structure et objet des NtS Encoding Guides

La norme NtS est améliorée en permanence. Une avancée majeure a été la publication du NtS web service, qui facilite les échanges de NtS entre les autorités ainsi qu’entre les autorités et les utilisateurs de NtS.

Deux documents ont été élaborés en vue de faciliter le codage harmonisé des NtS au niveau national et international: le NtS Encoding Guide destiné aux éditeurs et le NtS Encoding Guide destiné aux développeurs d’applications. Ces guides appliquent la NtS XSD 4.0 et le NtS Web Service WSDL 2.0.4.0.

Compte tenu de l’utilisation accrue du NtS Web Service, les NtS sont davantage harmonisés afin d’assurer un affichage adéquat de leur contenu sur les systèmes de tierces parties. Un codage uniforme des messages est également essentiel à la prise en compte des messages dans les applications de planification des voyages.

Les éléments contenant uniquement des valeurs standard ou par défaut sont omis s’ils sont facultatifs, car ils entraînent un surdébit de messages sans valeur ajoutée.

Le NtS Encoding Guide destiné aux éditeurs s’adresse aux personnes qui rédigent (et publient) les NtS. Il inclut des instructions étape par étape en vue de créer des types de messages adéquats, ainsi qu’une explication des codes. Le NtS Encoding Guide explique l’applicabilité des quatre types de NtS, fournit des instructions pour remplir les messages et inclut également des codes à utiliser dans certaines circonstances. Le NtS Encoding Guide destiné aux éditeurs est inclus à l’appendice A du présent règlement.

Le NtS Encoding Guide destiné aux développeurs d’applications contient des lignes directrices pour le développement et l’exécution d’applications pour les NtS, en expliquant leur logique, leurs processus et leurs valeurs automatiques/par défaut. Le NtS Encoding Guide destiné aux développeurs d’applications est inclus à l’appendice B du présent règlement.

2.   Sélection du type de NtS

FTM: choisissez ce type si vous voulez créer un «message relatif à la voie navigable et au trafic» pour des voies navigables ou des objets sur une voie navigable. [aller au chapitre 3].

WRM: choisissez ce type si vous voulez créer un «message relatif aux hauteurs d’eau», qui permet de fournir des informations sur les niveaux d’eau actuels et prévus, ainsi que d’autres informations. Le message relatif aux hauteurs d’eau contient des informations relatives à un objet ou un secteur de chenal navigable. L’objet est défini par son ISRS Location Code, tandis que le secteur de chenal navigable est défini par ses ISRS Location Codes de début et de fin.

ICEM: choisissez ce type si vous voulez créer un «message relatif à la glace». La section Informations relatives à la glace comporte des informations relatives aux conditions de glace sur une partie de chenal navigable définie par ses ISRS Location Codes de début et de fin.

WERM: choisissez ce type si vous voulez créer un «avis météorologique», qui permet de fournir des relevés et des prévisions météorologiques relatifs à une portion de voie navigable définie par ses ISRS Location Codes de début et de fin.

3.   Considérations de base relatives au FTM et étapes de la publication d’un FTM

Le chapitre 4 présente des informations détaillées sur les codes qui doivent être utilisés. Les considérations formulées à partir de la section 3.3 ne correspondent pas nécessairement à l’ordre d’entrée suivi par un outil d’édition des FTM.

3.1.

Est-il nécessaire de publier des informations au moyen d’un NtS FTM conformément à la norme NtS? Toutes les informations pertinentes sur la sécurité et la planification des voyages doivent être publiées au moyen de NtS. Des informations n’ayant pas d’utilité pour la sécurité et la planification des voyages peuvent être publiées. Chaque sujet/incident/événement doit être publié dans un message séparé.

3.2.

Existe-t-il déjà un FTM valide pour la situation actuelle (en rapport avec le contenu ainsi que la période de validité)?

3.2.1.

Oui:

le FTM existant doit être mis à jour. Le message publié concerné doit être sélectionné et mis à jour dans l’outil d’édition des FTM. Un FTM expiré ne peut plus être mis à jour.

3.2.2.

Non:

un nouveau FTM doit être établi. Lorsqu’un événement similaire a déjà été codé dans un FTM existant, celui-ci peut être utilisé comme ébauche pour la création d’un nouveau FTM (si cette fonction est disponible), ou un modèle peut également être utilisé (si cette fonction est disponible).

3.3.

Le champ géographique de validité doit être défini

3.3.1.

Lorsque le FTM est lié à une partie spécifique d’une voie navigable, cette partie doit être incluse, en étant définie par sa coordonnée de début et sa coordonnée de fin. Si le contenu s’applique à plusieurs secteurs d’une même voie navigable ou de différentes voies navigables, ceux-ci peuvent tous être repris dans un seul FTM.

3.3.2.

Lorsque le FTM porte sur un objet spécifique (par exemple un pont, une écluse, etc.) présent sur la voie navigable, il doit être sélectionné dans la liste des objets disponibles (si la fonction de sélection est disponible). Il n’est pas nécessaire de définir une partie de voie navigable dans le message. Lorsqu’un FTM porte sur plusieurs objets, ceux-ci peuvent tous être repris dans un seul FTM.

3.3.3.

Il est possible de combiner des informations relatives à des objets et à des chenaux navigables dans un seul message, pour autant que les informations portent sur une cause/un événement spécifique (même sujet et même code de motif).

3.3.4.

Bien que les coordonnées soient facultatives, elles sont fournies en soutien de la visualisation sur carte (ces coordonnées sont souvent fournies automatiquement par l’application NtS).

3.4.

Le contenu du FTM doit être encodé

Toutes les informations pouvant être exprimées au moyen des NtS Reference Tables doivent être codées dans les champs de message standardisés. Seules les informations supplémentaires (qui ne sont pas codables autrement) sont indiquées dans les champs de texte libre.

3.5.

Le ou les groupes cibles relatifs au type de bateau et les sens de navigation concernés doivent être indiqués le cas échéant.

3.5.1.

Lorsque le message est valable pour tous les bateaux (quel que soit leur type) dans tous les sens de navigation, le groupe cible n’est pas précisé et seules les informations essentielles sont codées. Si le message/la limitation concerne un groupe cible ou un sens de navigation spécifique, les codes pertinents doivent être sélectionnés.

3.5.2.

Lorsque la totalité du message s’adresse à des groupes cibles spécifiques, les informations relatives au groupe cible sont fournies dans la partie générale du FTM (et ne sont pas répétées dans la ou les sections «Limitations»).

3.5.3.

Lorsque différentes limitations s’appliquent à différents groupes cibles, les informations relatives au groupe cible sont fournies dans les sections «Limitations» respectives (et ne sont pas répétées dans la partie générale).

3.5.4.

Lorsque des dérogations aux limitations sont accordées à certains bateaux ou au trafic local par les autorités compétentes (par exemple, aux bateaux participant à un événement concerné par une restriction générale ou au trafic local de ferries dans des zones visées par une interruption), ces dérogations ne doivent pas être prises en compte pour le codage du ou des groupes cibles. Ces informations peuvent être indiquées dans le champ de texte libre réservé aux informations supplémentaires.

3.6.

La section «Communication» est remplie le cas échéant.

Si des informations supplémentaires sont disponibles via une source spécifique, il convient de le mentionner dans cette section. En cas d’obligation d’annonce supplémentaire via un canal spécifique, il convient de le mentionner dans cette section.

3.7.

La section «Limitations» est remplie le cas échéant

La section «Limitations» doit être remplie lorsque des limitations s’appliquent. Les valeurs liées à des limitations qui sont connues doivent être indiquées. Il est obligatoire de fournir des valeurs pour les dimensions des bateaux, les limites de vitesse et l’espace de navigation disponible.

Les périodes de limitation doivent être indiquées à chaque fois, afin de permettre aux applications de planification des voyages d’effectuer des calculs corrects (pour faciliter la tâche, l’application NtS peut prévoir une fonction permettant de copier les périodes de limitation ou de sélectionner plusieurs limitations pour une même période).

3.8.

La date de début de la validité du message doit être indiquée

La date de fin de la validité du message doit également être indiquée si elle est déjà connue. La date de fin de la validité ne peut pas être antérieure à la date actuelle.

Il est à noter que les applications utiliseront les informations relatives à la période de validité pour sélectionner les messages à montrer aux utilisateurs pendant une période requise.

En cas d'annulation du message:

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.

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

TABLE DES MATIÈRES

1.

Contexte et structure 24

1.1.

Purpose of NtS Encoding Guide 24

1.1.1.

NtS Encoding Guide for editors 24

1.1.2.

NtS Encoding Guide for application developers (this document) 24

2.

NtS messages and sections 24

3.

WRM basic considerations 26

3.1.

Filling of nts_number section in the WRM 26

3.2.

Filling of WRM including predictions 26

4.

ICEM processes 27

4.1.

New ICEM 28

4.2.

Update of an existing ICEM 28

5.

WERM basic considerations 29

5.1.

Filling of nts_number section in the WERM 29

5.2.

Filling of WERM «weather_category_code» 29

6.

FTM processes 30

6.1.

New FTM 30

6.2.

Update/withdrawal of an existing FTM 30

6.3.

Waterway and/or object related FTM 31

6.4.

Automatic ordering of limitation codes 31

6.5.

Handling of limitation period 32

7.

General implementation rules 33

7.1.

Filling of the «number_section» 33

7.2.

Filling of elements «from», «originator», «organisation» and «source» 33

7.3.

Omission of elements 34

7.4.

Automatic filling of date_issue 34

7.5.

Handling of time zone information in NtS messages 34

7.6.

Handling of Seconds in NtS messages 34

7.7.

Format of decimals in NtS messages 34

7.8.

Units to be used in NtS messages 34

7.9.

Rules for the elements «name», «position_code» and «type_code» 34

7.10.

Rules for the element «fairway_name» 38

7.11.

Clarifications for translations in the spreadsheet «reference_code» 38

7.12.

Recommendation for the element «coordinate» 38

7.13.

Handling of target groups 38

7.14.

Display of valid messages at a given time 39

7.15.

Optional functions to increase user friendliness of NtS editor tools 39

8.

NtS XML Message Structure 39

9.

NtS Web Service 39

9.1.

Objective 39

9.2.

Basic Principles and constraints 40

9.2.1.

Web standards 40

9.2.2.

Interaction model and encoding method for NtS WS 40

9.3.

General specifications and recommendations 40

9.3.1.

Specification: Version information 40

9.3.2.

Specification: Structure of namespaces 41

9.3.3.

Recommendation: Use of namespaces 41

9.3.4.

Recommendation: Use of namespace prefixes 41

9.3.5.

Specification: Use of ISRS Location Codes 41

9.4.

NtS Message Service (implementation specification) 46

9.4.1.

Request 46

9.4.2.

Response 47

9.5.

Generation of services and clients 48
Glossary 48

1.   Contexte et structure

Les avis à la batellerie (NtS) étaient mis en œuvre dans plusieurs pays européens au titre du règlement (CE) no 416/2007 de la Commission concernant les spécifications techniques des avis à la batellerie visées à l’article 5 de la directive 2005/44/CE du Parlement européen et du Conseil relative à des services d’information fluviale (SIF). La norme NtS fait l’objet d’un processus d’amélioration continu. Une avancée majeure a été la publication du NtS Web Service, qui facilite les échanges de messages NtS entre les autorités et entre les autorités et les utilisateurs de NtS, ainsi que la rationalisation du codage des messages NtS sur la base de la NtS XSD 4.0.

1.1.   Objet du NtS Encoding Guide

Le NtS Encoding Guide explique l’applicabilité des quatre types de NtS, ainsi que les codes à utiliser pour certains événements. Il fournit aux éditeurs de NtS des instructions pour remplir les messages NtS et permet ainsi l’harmonisation du codage de ces derniers sur le plan national et international.

Compte tenu de l’utilisation accrue du NtS Web Service, les NtS sont davantage harmonisés afin d’assurer un affichage adéquat de leur contenu sur les systèmes de tierces parties. Un codage uniforme des messages est également essentiel à la prise en compte des messages dans les applications de planification des voyages. La version 1.0 du NtS Encoding Guide applique la NtS XSD 4.0 et le NtS Web Service WSDL 2.0.4.0.

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

Image

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

Image

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» (1). 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 chiffres identiques dans la partie fairway_section de l’ISRS Location Code. Le code relatif au secteur de chenal navigable, ainsi que l’hectomètre du chenal navigable, définissent un secteur de voie navigable indiqué sous la forme d’une paire d’éléments identificateurs.

Pour indiquer des secteurs de voies navigables (paires d’éléments identificateurs dans l’élément fairway_section geo_object) dans les messages NtS, il y a lieu de tenir compte des aspects suivants concernant les ISRS Location Codes:

chiffres 1 à 2 (Country code):

doivent être identiques au sein de la paire d’identificateurs, mais

des codes de pays différents peuvent être définis à l’intérieur d’une paire d’identificateurs lorsque des pays voisins utilisent le même code de secteur de chenal navigable pour une voie navigable donnée et le même système pour définir les hectomètres;

chiffres 3 à 5 (UN Location code):

dénués de pertinence, peuvent regrouper des contenus différents dans une même paire d’identificateurs;

chiffres 6 à 10 (Fairway section code):

doivent être identiques au sein de la paire d’identificateurs, mais

[exception]: en cas d’utilisation de codes ISRS belges dans le NtS WS, il convient d’utiliser uniquement les chiffres 6 à 8 pour identifier le secteur de chenal navigable, car les messages NtS seront publiés pour plusieurs secteurs d’un même chenal;

chiffres 11 à 15 (Object Reference Code):

dénués de pertinence, peuvent regrouper des contenus différents dans une même paire d’identificateurs;

chiffres 16 à 20 (Fairway Hectometre):

consistent en cinq caractères numériques définissant l’hectomètre; dès lors, la paire d’identificateurs comportera généralement différents contenus. Exemple: «00235» pour le km 23,5 du chenal navigable; «00001» pour le km 0,1 du chenal navigable;

[exception]: pour les Pays-Bas, il n’y a pas toujours de lien direct entre l’hectomètre du chenal navigable et le kilomètre physique du chenal navigable, en raison de la définition du début de la partie du chenal dans le modèle du réseau et dans le monde réel; dans ce genre de cas, le code de référence à l’objet pour les objets de type «dismar» débute par Kxxxx [xxxx inclut le kilomètre physique, par exemple NLSVG00130K000300191 (km 3)]. En revanche, pour les autres types d’objets, les ISRS codes ne contiennent aucun lien direct avec le kilomètre physique du chenal navigable; ainsi, le pont de Sas-de-Gand, sur le même chenal navigable, au km 2,5, a pour ISRS code NLSVG001300521600186. Pour le canal Gand-Terneuse, le kilomètre physique 0,0 débute à la frontière entre la Belgique et les Pays-Bas et l’hectomètre du chenal navigable 0,0 débute au commencement du canal à Gand.

Lorsqu’un message porte sur plusieurs secteurs de voie ou de chenal navigable, tous les secteurs doivent être définis par leurs points de début et de fin dans des éléments XML «fairway_section» distincts.

Pour certains pays/certaines régions, il est obligatoire de développer une fonctionnalité de filtrage. Par exemple, si l’ISRS Location Code (1-2) est BE, il faut utiliser l’ISRS Location Code (6-8) comme ID pour établir une référence linéaire avec l’hectomètre de chenal navigable (ISRS Location Code 16-20). Voici quelques exemples de secteurs de chenal navigable (paires d’éléments identificateurs dans l’élément fairway_section) qui incluent les exceptions susmentionnées:

Les deux ISRS Location Codes des Pays-Bas constituent une définition valable d’un secteur de voie navigable (et montrent l’exception établie pour les Pays-Bas au sujet du kilomètre du chenal navigable): NLSVG00130K000300191 (km 3,0 à Sas van Gent sur le Kanaal Gent-Terneuzen) — NLWDP00130K000400200 (km 4,0 à Westdorpe sur le Kanaal Gent-Terneuzen),

Les deux ISRS Location Codes de la Belgique constituent une définition valable d’un secteur de voie navigable [et montrent l’exception établie pour la Belgique au sujet du fairway section code («020» Albertkanaal)]: BEGNK02016L010100414 (écluse de Genk située au km 41,4 sur le Canal Albert) — BEOSH02033L010500772 (écluse de Ham située au km 77,2 sur le Canal Albert).

La figure ci-dessous présente des contre-exemples d’utilisation de ISRS Location Codes pour chaque convention générale (aucune exception aux conventions générales ne s’applique aux secteurs de voies navigables de la Slovaquie):

Image

Requêtes d’ISRS Location Codes invalides

Remarque générale: le NtS Web Service ne propose pas de service permettant d'interroger les ISRS Location Codes valides. Les ISRS Location Codes sont fournis dans le cadre du système européen de gestion des données de référence (ERDMS).

Les cinq cas présentés ci-après proposent des exemples d’utilisation correcte des ISRS Location Codes dans les requêtes et leur interprétation.

Cas 1: aucun élément identificateur dans la demande

L’inclusion d’éléments identificateurs dans la demande est facultative; autrement dit, une requête n’incluant aucun élément identificateur est autorisée:

Image

Requête valide sans paramètres d’identification

Si aucun élément identificateur n’est fourni, tous les messages sont renvoyés (en fonction, bien entendu, d’autres critères de filtrage tels que validity_period ou dates_issue).

Cas 2: un élément identificateur dans la demande

Chaque élément identificateur peut contenir un ou deux éléments identificateurs. Le cas d’un seul élément identificateur est présenté dans la figure ci-dessous:

Image

Requête valide avec un paramètre d’identification

Lorsqu’il reçoit une telle requête, le serveur renvoie tous les messages correspondants dont l’hectomètre de début est ≤ à la valeur donnée (240,7 dans l’exemple) et l’hectomètre de fin est ≥ à cette valeur. La figure ci-dessous illustre cette sélection de messages: la position interrogée se situe entre les valeurs de l’hectomètre de début et de l’hectomètre de fin des messages 1, 3 et 4, qui seront renvoyés. Les messages 2, 5 et 6 ne correspondent pas à la position interrogée et ne seront donc pas renvoyés.

Si l'ISRS Location Code donné porte sur un objet particulier, tel qu’une échelle ou une écluse, le web service renvoie les messages qui y font référence.

Image

Messages correspondants et non correspondants pour un paramètre d’identification

Cas 3: deux éléments identificateurs dans la demande

Chaque élément identificateur peut contenir un ou deux éléments identificateurs. Le cas de deux éléments identificateurs est présenté dans la figure ci-dessous:

Image

Requête valide avec deux paramètres d’identification

Toutes les valeurs d’hectomètre interrogées sont traitées comme étant valides, même si le secteur de chenal navigable correspondant a des points de début ou de fin différents. Par exemple, si le secteur de chenal navigable commence à l’hectomètre 100,0 et se termine à l’hectomètre 300,0, une requête portant sur les hectomètres 20,0 à 400,0 serait valide. Au niveau interne, bien entendu, seule la «véritable» étendue du secteur de chenal navigable est recherchée.

Cela permet également de rechercher tous les messages relatifs à un chenal navigable sans connaître son étendue hectométrique exacte (en envoyant un ISRS Location Code avec des hectomètres définis respectivement à «00000» ou «99999»).

Tous les messages correspondant à l’intervalle hectométrique donné sont renvoyés. Le schéma suivant illustre cette situation:

Image

Messages correspondants et non correspondants pour deux paramètres d’identification

La figure ci-dessus montre ce que l’on entend par «correspondre à un intervalle». Si l’étendue des messages 1 à 4 correspond (totalement ou partiellement) à l’étendue hectométrique interrogée, ce n’est pas le cas de celle des messages 5 et 6; par conséquent, les messages 1 à 4 seront renvoyés, mais pas les messages 5 et 6.

La condition technique pour qu’un message corresponde à un intervalle [A, B] est la suivante: l’hectomètre de début du message est ≤ à B et son hectomètre de fin est ≥ A.

Combinaison: plus de deux éléments identificateurs dans la demande

Image

Requête valide avec plus de deux éléments identificateurs

La combinaison de plusieurs éléments identificateurs dans la demande entraîne l’association des messages correspondants. Tous les éléments identificateurs sont traités de manière individuelle et un message sera renvoyé s’il correspond à au moins l’un d’entre eux. Ainsi, pour l’exemple donné, les messages suivants seraient renvoyés:

Tous les messages pour l’objet dont l’ISRS Location Code est SKXXX0000010000*****, dont l’hectomètre de début = 0 et l’hectomètre de fin est ≥ 0 (voir le cas 2)

Tous les messages pour l’objet dont l’ISRS Location Code est SKXXX0000500000***** et qui correspond à l’intervalle hectométrique [11,0, 15,0] (voir le cas 3)

Tous les messages pour l’objet dont l’ISRS Location Code est SKXXX0000200000*****, dont l’hectomètre de début est ≤ 110,5 et l’hectomètre de fin est ≥ 110,5 (voir le cas 2)

Tous les messages pour l’objet dont l’ISRS Location Code est SKXXX0000500000***** et qui correspond à l’intervalle hectométrique [220,0, 300,0] (voir le cas 3)

9.4.   Service de messages NtS (spécification de mise en œuvre)

Ce chapitre décrit la spécification de mise en œuvre du service de messages NtS, élaborée à partir des considérations et des choix présentés dans les précédents chapitres.

Le service de messages NtS fournit les quatre types de messages NtS:

1.

NtS FTM (message relatif à la voie navigable et au trafic)

2.

NtS WRM (message relatif aux hauteurs d’eau)

3.

NtS ICEM (message relatif à la glace)

4.

NtS WERM (avis météorologique)

Une mise en œuvre du service de messages NtS peut couvrir tous les types de messages ou uniquement certains d’entre eux. Il est permis aux États membres participants de fournir, pour un type de message donné, plusieurs services qui se complètent.

9.4.1.   Demande

Afin d’assurer une solidité maximale du service tout en limitant sa complexité, aucun langage de requête supplémentaire n’est utilisé pour le NtS Web Service. En lieu et place, les concepts fournis par la spécification WSDL elle-même sont appliqués. Les opérations spécifiques, ainsi que leurs paramètres, sont entièrement décrites dans la spécification WSDL. Dans le cas du service de messages NtS, une seule opération est définie.

Les critères de filtrage propres à un sujet proviennent de la norme NtS, mais ont été élargis compte tenu de la multiplicité des paramètres:

type de message (obligatoire; choisir entre «FTM», «WRM», «ICEM», «WERM»)

secteurs de voie navigable spécifiques ou parties de ceux-ci, ou objets spécifiques (facultatif; décrits par des ISRS Location Codes uniques et/ou par des paires d’ISRS Location Codes)

période de validité (facultatif; date de début et date de fin)

date de publication de l’avis (facultatif; dates uniques et/ou intervalles de dates)

Le service ne renvoie que les messages qui correspondent aux critères donnés.

Mécanisme de pagination

Afin de contrôler le volume de données, un mécanisme de pagination est prévu. Le paramètre de pagination est défini sur la base d’un type complexe comportant les éléments suivants:

offset: numéro séquentiel du premier message renvoyé (integer ≥ 0)

limit: nombre maximum de messages (integer ≥ 0)

total count: signal, si le nombre total de messages doit être renvoyé (valeur Boolean)

Le paramètre complexe de pagination est facultatif, mais s’il est disponible, tous les éléments exigés doivent être fournis. Le mécanisme de pagination fonctionne alors comme suit:

Le nombre total de messages ne dépassera pas la valeur du paramètre limit, à l’exception qu’une valeur de 0 signifie «aucune limite». La réponse saute autant de messages que défini par le paramètre offset. Afin de fournir ce mécanisme, le service doit respecter une séquence de messages temporairement stable (mais arbitraire le reste du temps), par exemple entre deux mises à jour des données de messages sur l’ensemble de données sous-jacent du web service. Cela signifie que deux appels identiques et consécutifs doivent renvoyer les mêmes messages, dans le même ordre. Le paramètre total count détermine si la réponse affiche le nombre total de messages correspondant aux critères propres au sujet. Il devrait en général suffire d'interroger ces informations pour la première réponse, puis de les omettre pour toutes les réponses suivantes. Ainsi, le web service devrait être plus performant.

Le mécanisme de pagination fournit un moyen de demander les messages de manière itérative sous forme de «pages». Pour que le mécanisme de pagination fonctionne de manière adéquate, les mêmes paramètres propres au sujet doivent être fournis à chaque appel.

9.4.2.   Réponse

Lorsqu’une demande est acceptée, la réponse du NtS Web Service contient les messages NtS qui correspondent aux paramètres de la demande. Les messages NtS doivent respecter le schéma NtS et peuvent être validés par rapport à celui-ci. Le type de message étant un paramètre de demande obligatoire, chaque réponse ne peut contenir que des messages NtS d’un même type de message, à savoir, respectivement, FTM, WRM, ICEM ou WERM.

Lorsque le service détecte des erreurs lors du traitement de la demande, il peut renvoyer un nombre arbitraire de messages d’erreur, en utilisant les codes d’erreur énumérés au sous-chapitre suivant.

Une réponse d’un NtS Web Service peut contenir à la fois des messages NtS et des messages d’erreur.

Des informations de pagination facultatives sont renvoyées si la demande comportait des paramètres de pagination. Dans ce cas, le nombre de messages à sauter et le nombre de messages à afficher sont obligatoires; le nombre total de message n’est nécessaire que s’il a été demandé.

Remarque: il est supposé que la communication entre le web service et l’utilisateur est techniquement établie, c’est-à-dire que le service reçoit la demande et que l’utilisateur reçoit la réponse qui s’y rapporte. Les erreurs techniques, telles qu’une interruption de la connexion internet ou une impossibilité d’accéder au web service en raison d’une maintenance ou d’une panne, ne sont pas prises en compte ici. Le présent document ne s’intéresse qu’aux situations d’erreur qui se produisent «derrière» la couche du web service, du point de vue des utilisateurs.

Messages d’erreur

Les codes d’erreur relatifs aux situations d’erreur attendues sont présentés ci-dessous, accompagnés d’une explication. Seul le code d’erreur figure dans la réponse, conformément à la procédure habituelle dans le schéma XML des NtS.

Codes d’erreur pour le service de messages NtS

Code

Description

Explanation

e010

message type not supported

web service does not support the requested message type

e030

paging parameters inconsistent with messages

parameters for paging mechanism do not fit the available messages, e.g. Offset >= Total Count

e100

syntax error in request

request violates the schema for requests; can be specified in more detail by further e1xx-Codes

e110

incorrect message type

given message type is not known

e120

incorrect type-specific parameters

type-specific parameters are erroneous

e130

incorrect paging parameters

given parameters for the paging mechanism are erroneous

e200

operation not known

the requested operation is unknown

e300

data source unavailable

data source of the web service for the NtS data is temporarily unavailable (technical problem)

e310

too many results for request,

server is unable to handle number of results

9.5.   Génération des services et des clients

Si l’approche «le contrat d’abord» est par la suite suivie, c’est-à-dire qu’un ou plusieurs contrats contenant une description complète des interfaces sont fournis sous la forme de documents WSDL, une mise en œuvre du ou des services, ainsi que d’un client correspondant, peut être automatiquement générée à l’aide des outils logiciels adéquats. Idéalement, aucune modification manuelle ne devrait être apportée au code source généré.

Toutefois, dans la plupart des cas, plusieurs itérations sont nécessaires pour que la spécification WSDL réponde aux exigences précises d’un tel outil. En général, pour fonctionner de manière optimale, l’outil formule des demandes individuelles au sujet de l’utilisation de la norme WSDL. Il peut donc être nécessaire d’apporter des modifications à la spécification WSDL, même si celle-ci était déjà valide conformément à la norme WSDL. Si la spécification WSDL du web service est modifiée après la génération du service ou du client, un nouveau processus de génération peut être nécessaire, en fonction des modifications apportées.

Glossaire

Terme

Explication

ID

Identification

ISRS Location Code

Code de localisation «International Ship Reporting Standard»

NtS

Avis à la batellerie

RIS

Services d’information fluviale

SOAP

Simple Object Access Protocol; protocole réseau habituellement utilisé pour les services web

UDDI

Universal Description, Discovery and Integration; norme appliquée pour les services de répertoire dans le contexte de services web

UN

Nations unies

URL

Uniform Resource Locator; localisation d’une ressource réseau, habituellement utilisée pour les adresses internet

WGS84

Système géodésique mondial de 1984

WS

Service web; service fournissant ses interfaces sur l’internet et utilisé par les communications internet

WSDL

Web Services Description Language; norme pour la spécification des services web

WS-I

Web Services Interoperability Organisation; consortium industriel dont l’objectif est de soutenir l’interopérabilité des services web

XML

Extensible Markup Language; métalangage utilisé pour la représentation structurée et indépendante de toute plateforme des données

XSD

XML Schema Definition ou définition de schéma XML; norme utilisée pour spécifier la structure des documents XML


(1)  Description provenant du site web WS-I: http://www.ws-i.org

Appendice C

No

Tag (Group headers and closers are boldly printed)

Description

Occ.

Rule

 

xmlns:nts="http://www.ris.eu/nts/4.0.4.0"

 

 

 

 

<RIS_Message>

Notice to Skippers

 

 

1s

<identification>

Identification section

M

1

1.1

 

<internal_id>xs:string (64)</internal_id>

Internal ID

C

 

1.2

 

<from>xs:string (64)</from>

Sender (System) of the message

M

 

1.3

 

<originator>xs:string (64)</originator>

Originator (initiator) of the information in this message

M

 

1.4

 

<country_code>nts:country_code_enum</country_code>

Country where message is valid

M

 

1.5

 

<language_code>nts:language_code_enum</language_code>

Original language used in the textual info. (contents)

M

 

1.6

 

<district>xs:string (64)</district>

District / Region within the specified country, where the message is applicable

C

 

1.7

 

<date_issue>xs:dateTime<date_issue>

Date and time of publication including time zone (yyyy-mm-ddThh:mm:ss+hh:mm)

M

 

1e

</identification>

 

 

 

 

 

 

 

 

2s

<ftm>

Fairway and traffic related section

C

1

2.1

 

<internal_id>xs:string (64)</internal_id>

Internal ID

C

 

2.2s

 

<nts_number>

NtS Number

M

 

2.2.1

 

 

<organisation>xs:string (64)</organisation

Name of the publishing organisation (NtS Provider)

M

 

2.2.2

 

 

<year>xs:gYear (1900-9999)</year>

Year of first issuing of the notice

M

 

2.2.3

 

 

<number>xs:integer (0-99999999)</number>

Number of the notice (per year, starting with: 1, 0 shall not be used for published notices)

M

 

2.2.4

 

 

<serial_number>xs:integer (0-99)</serial_number>

Serial number of notice (replacements and withdrawals), original notice: 0

M

 

2.2e

 

</nts_number>

 

 

 

2.3s

 

<target_group>

Target group information

C

 

2.3.1

 

 

<target_group_code>nts:target_group_code_enum</target_group_code>

Target group (vessel type) for this message

M

5

2.3.2

 

 

<direction_code>nts:direction_code_enum</direction_code>

Upstream or downstream traffic, or both

M

5

2.3e

 

</target_group>

 

 

 

2.4

 

<subject_code>nts:subject_code_enum</subject_code>

Subject code

M

 

2.5s

 

<validity_period>

Overall period of validity

M

 

2.5.1

 

 

<date_start>xs:date</date_start>

Start date of validity period including time zone (yyyy-mm-dd+hh:mm)

M

 

2.5.2

 

 

<date_end>xs:date</date_end>

End date of validity period including time zone (yyyy-mm-dd+hh:mm)

C

 

2.5e

 

</validity_period>

 

 

 

2.6

 

<contents>xs:string (500)</contents>

Additional information in local language

C

 

2.7

 

<source>xs:string (64)</source>

Notice source (name of authority)

C

 

2.8

 

<reason_code>nts:reason_code_enum</reason_code>

Reason / justification of notice

C

 

2.9s

 

<communication>

Communication channel information

C

 

2.9.1

 

 

<reporting_code>nts:reporting_code_enum</reporting_code>

Reporting regime (information or duty to report)

M

5

2.9.2

 

 

<communication_code>nts:communication_code_enum</communication_code>

Communication code (telephone, VHF etc.)

M

5

2.9.3

 

 

<number>xs:string (128)</number>

Telephone, VHF number (including callsign), e-mail address, URL or teletext

C

 

2.9.4

 

 

<label>xs:string (256)</label>

Name of the attachment or additional information

C

 

2.9.5

 

 

<remark>xs:string (1024)</remark>

Additional remarks concerning the communication

C

 

2.9e

 

</communication>

 

 

 

2.10s

 

<fairway_section>

Fairway section, also available for objects (no 2.11)

C

2

2.10.1s

 

 

<geo_object>

Geo information of fairway

M

5

2.10.1.1

 

 

 

<id>nts:isrs_code_type</id>

ISRS Location Code of the fairway section (2x)

Pattern=[A-Z]{2}[A-Z]{3}[A-Z0-9]{5}[A-Z0-9]{5}[0-9]{5}

M

7

2.10.1.2

 

 

 

<name>xs:string (256)</name>

Local name of the fairway section (f.e.: Rhine between bridge A and bridge B)

M

 

2.10.1.3

 

 

 

<type_code>nts:type_code_enum</type_code>

Type of geographical object (default=FWY)

M

 

2.10.1.4

 

 

 

<position_code>nts:position_code_enum</position_code>

Describes the position related to the fairway

C

 

2.10.1.5s

 

 

 

<coordinate>

Fairway section begin and end coordinates (2x)

C

7

2.10.1.5.1

 

 

 

 

<lat>xs:string (10-12)</lat>

[d]d mm.mmm[m] N

M

5

2.10.1.5.2

 

 

 

 

<long>xs:string (10-13)</long>

[d][d]d mm.mmm[m] E

M

5

2.10.1.5e

 

 

 

</coordinate>

 

 

 

2.10.1.6

 

 

 

<fairway_name>xs:string (256)</fairway_name>

Waterway name (usefull if no RIS Index is available).

C

 

2.10.1e

 

 

</geo_object>

 

 

 

2.10.2s

 

 

<limitation>

Fairway section limitations

C

 

2.10.2.1s

 

 

 

<limitation_period>

Limitation periods / intervals (All limitations have to include a limitation period with an interval code in order to allow proper calculations within voyage planning applications)

C

 

2.10.2.1.1

 

 

 

 

<date_start>xs:date</date_start>

Start date of limitation period (overall) INCLUDING time zone

format=yyyy-mm-dd+hh:mm

M

5

2.10.2.1.2

 

 

 

 

<date_end>xs:date</date_end>

End date of limitation period INCLUDING time zone

format=yyyy-mm-dd+hh:mm

C

 

2.10.2.1.3

 

 

 

 

<time_start>xs:time</time_start>

Start time of limitation period WITHOUT time zone

format=hh:mm:ss [whereas ss=00]

C

 

2.10.2.1.4

 

 

 

 

<time_end>xs:time</time_end>

End time of limitation period WITHOUT time zone

format=hh:mm:ss [whereas ss=00]

C

 

2.10.2.1.5

 

 

 

 

<interval_code>nts:interval_code_enum</interval_code>

Interval for limitation (mandatory M(5) but is set to C to be compatible with former XSD version)

C

 

2.10.2.1e

 

 

 

</limitation_period>

 

 

 

2.10.2.2

 

 

 

<limitation_code>nts:limitation_code_enum</limitation_code>

Kind of limitation

M

5

2.10.2.3

 

 

 

<position_code>nts:position_code_enum</position_code>

Describes the position of the limitation related to the fairway

C

 

2.10.2.4

 

 

 

<value>xs:float</value>

Value of limitation (i.e. max draught)

C

 

2.10.2.5

 

 

 

<unit>nts:unit_enum</unit>

Unit of the value of the limitation

C

 

2.10.2.6

 

 

 

<reference_code>nts:reference_code_enum</reference_code>

Value reference

C

 

2.10.2.7

 

 

 

<indication_code>nts:indication_code_enum</indication_code>

Minimum or maximum or reduced by

C

 

2.10.2.8s

 

 

 

<target_group>

Target group information

C

 

2.10.2.8.1

 

 

 

 

<target_group_code>nts:target_group_code_enum</target_group_code>

Target group (vessel type) for this limitation

M

5

2.10.2.8.2

 

 

 

 

<direction_code>nts:direction_code_enum</direction_code>

Upstream or downstream traffic, or both

M

5

2.10.2.8e

 

 

 

</target_group>

 

 

 

2.10.2e

 

 

</limitation>

 

 

 

2.10e

 

</fairway_section>

 

 

 

2.11s

 

<object>

Object section

C

2

2.11.1s

 

 

<geo_object>

Geo Information of object

M

5

2.11.1.1

 

 

 

<id>nts:isrs_code_type</id>

ISRS Location Code of the object (1x)

Pattern=[A-Z]{2}[A-Z]{3}[A-Z0-9]{5}[A-Z0-9]{5}[0-9]{5}

M

8

2.11.1.2

 

 

 

<name>xs:string (256)</name>

Local name of the aggregated object

M

 

2.11.1.3

 

 

 

<type_code>nts:type_code_enum</type_code>

Type of geographical object

M

 

2.11.1.4

 

 

 

<position_code>nts:position_code_enum</position_code>

Describes the position related to the object

C

 

2.11.1.5s

 

 

 

<coordinate>

Object coordinates (1x)

C

8

2.11.1.5.1

 

 

 

 

<lat>xs:string (10-12)</lat>

[d]d mm.mmm[m] N

M

5

2.11.1.5.2

 

 

 

 

<long>xs:string (10-13)</long>

[d][d]d mm.mmm[m] E

M

5

2.11.1.5e

 

 

 

</coordinate>

 

 

 

2.11.1.6

 

 

 

<fairway_name>xs:string (256)</fairway_name>

Waterway name (usefull if no RIS Index is available).

C

 

2.11.1e

 

 

</geo_object>

 

 

 

2.11.2s

 

 

<limitation>

Object limitation section

C

 

2.11.2.1s

 

 

 

<limitation_period>

Limitation periods / intervals (All limitations have to include a limitation period with an interval code in order to allow proper calculations within voyage planning applications)

C

 

2.11.2.1.1

 

 

 

 

<date_start>xs:date</date_start>

Start date of limitation period (overall) INCLUDING time zone

format=yyyy-mm-dd+hh:mm

M

5

2.11.2.1.2

 

 

 

 

<date_end>xs:date</date_end>

End date of limitation period INCLUDING time zone

format=yyyy-mm-dd+hh:mm

C

 

2.11.2.1.3

 

 

 

 

<time_start>xs:time</time_start>

Start time of limitation period WITHOUT time zone

format=hh:mm:ss [whereas ss=00]

C

 

2.11.2.1.4

 

 

 

 

<time_end>xs:time</time_end>

End time of limitation period WITHOUT time zone

format=hh:mm:ss [whereas ss=00]

C

 

2.11.2.1.5

 

 

 

 

<interval_code>nts:interval_code_enum</interval_code>

Interval for limitation (mandatory M(5) but is set to C to be compatible with former XSD version)

C

 

2.11.2.1e

 

 

 

</limitation_period>

 

 

 

2.11.2.2

 

 

 

<limitation_code>nts:limitation_code_enum</limitation_code>

Kind of limitation

M

5

2.11.2.3

 

 

 

<position_code>nts:position_code_enum</position_code>

Describes the position of the limitation related to the fairway

C

 

2.11.2.4

 

 

 

<value>xs:float</value>

Value of limitation (i.e. max draught)

C

 

2.11.2.5

 

 

 

<unit>nts:unit_enum</unit>

Unit of the value of the limitation

C

 

2.11.2.6

 

 

 

<reference_code>nts:reference_code_enum</reference_code>

Value reference

C

 

2.11.2.7

 

 

 

<indication_code>nts:indication_code_enum</indication_code>

Minimum or maximum or reduced by

C

 

2.11.2.8s

 

 

 

<target_group>

Target group information

C

 

2.11.2.8.1

 

 

 

 

<target_group_code>nts:target_group_code_enum</target_group_code>

Target group (vessel type) for this limitation

M

5

2.11.2.8.2

 

 

 

 

<direction_code>nts:direction_code_enum</direction_code>

Upstream or downstream traffic, or both

M

5

2.11.2.8e

 

 

 

</target_group>

 

 

 

2.11.2e

 

 

</limitation>

 

 

 

2.11e

 

</object>