A.   NTS ENCODING GUIDE DESTINÉ AUX ÉDITEURS

TABLE DES MATIÈRES

Abréviations

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

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.

4.   Explication des codes d’un FTM

4.1.   Subject_code:

Définition de l’utilisation des codes sujet:

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:

4.3.   Limitation_code:

Définition de l’utilisation des codes de limitation:

4.4.   Limitation interval_code:Définition de l’utilisation des interval codes:

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.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.9.   Target_group_code (voir le chapitre 3.5)

4.10.   Reporting_code

4.11.   Communication_code

Le format suivant est utilisé (exemples):

4.12.   Type_code:

Une voie navigable est soit un canal, soit un bassin, soit une rivière.

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.

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

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:

Figure 2

Visualisation de la structure des NtS: élément obligatoire (1), élément obligatoire pouvant apparaître une ou deux fois (1…2), élément obligatoire devant apparaître deux fois (2), élément obligatoire pouvant apparaître autant de fois que nécessaire (1-n), élément facultatif pouvant apparaître autant de fois que nécessaire (0…n)

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

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:

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

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

3.1.   Remplissage de la section nts_number du WRM

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

3.2.   Remplissage du WRM, y compris prévisions

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

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

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

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

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

Figure 3

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

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

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

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

4.2.   Mise à jour d’un ICEM existant

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:

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

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

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

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:

6.5.   Traitement des périodes de limitation

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

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

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:

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»

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:

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:

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:

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.

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 section relative au web service est elle-même composée de deux parties:

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:

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:

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:

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

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:

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:

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.

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:

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:

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

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:

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:

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:

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:

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

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

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

Appendice C