1.

Hintergrund und Aufbau

Nachrichten für die Binnenschifffahrt (NtS) wurden auf der Grundlage der Verordnung (EG) Nr. 416/2007 der Kommission über die technischen Spezifikationen für Nachrichten für die Binnenschifffahrt gemäß Artikel 5 der Richtlinie 2005/44/EG des Europäischen Parlaments und des Rates über harmonisierte Binnenschifffahrtsinformationsdienste (RIS) auf den Binnenwasserstraßen der Gemeinschaft in verschiedenen europäischen Ländern eingerichtet. Der NtS-Standard wird fortlaufend weiterentwickelt; die Freigabe des NtS Web Service bedeutete durch die Erleichterung des Austausches von NtS-Nachrichten zwischen Behörden einerseits und Behörden und Nutzern dieser Nachrichten andererseits einen großen Schritt nach vorn; ein weiterer Fortschritt war die NtS XSD 4.0, mit der die Codierung von NtS-Nachrichten gestrafft wurde.

1.1.

Zweck des NtS Encoding Guide

Im NtS Encoding Guide wird erläutert, wann die vier Typen der NtS-Nachrichten anzuwenden sind; außerdem enthält er Codes, die bei bestimmten Ereignissen zu verwenden sind. Der Leitfaden gibt den NtS-Editoren Ausfüllanweisungen an die Hand und ermöglicht so eine auf nationaler und internationaler Ebene harmonisierte Codierung von NtS-Nachrichten. In Anbetracht der zunehmenden Nutzung des NtS Web Service sollten die NtS-Nachrichten weiter harmonisiert werden, damit eine korrekte Anzeige der Inhalte auf Drittsystemen gewährleistet ist. Eine einheitliche Codierung von Nachrichten ist zudem eine Voraussetzung für die Berücksichtigung der Nachrichten in Reiseplanungsanwendungen. Die Version 1.0 des NtS Encoding Guide gilt für NtS XSD 4.0 und den NtS Web Service WSDL 2.0.4.0.

1.1.1.

NtS Encoding Guide für Editoren

Der NtS Encoding Guide für Editoren wendet sich an den Personenkreis, der NtS-Nachrichten editiert (und herausgibt); der Leitfaden enthält eine Schritt-für-Schritt-Anleitung für die Erstellung der korrekten Nachrichtentypen sowie eine Erklärung der Codes. Der NtS Encoding Guide für Editoren enthält auch für Anwendungsentwickler relevante Informationen.

1.1.2.

NtS Encoding Guide für Anwendungsentwickler

Der NtS Encoding Guide für Anwendungsentwickler enthält Leitlinien für die Implementierung von NtS-Anwendungen und erläutert deren Logik, Prozesse und automatische bzw. vorgegebene Werte.

2.

NtS-Nachrichten und Abschnitte

Eine Nachricht für die Binnenschifffahrt setzt sich wie folgt zusammen:

—

Identifikationsabschnitt

—

Definition des/der jeweiligen Objekts/Objekte oder Wasserstraßenabschnitts/-abschnitte, auf den oder die sich die Nachricht bezieht;

—

je nach Nachrichtentyp einer oder mehrere der folgenden Abschnitte:

—

Einschränkung(en) für wasserstraßen- und verkehrsbezogene Nachrichten,

—

Messung(en) für Wasserstandsmeldungen,

—

Eisverhältnisse für Eismeldungen,

—

Wetterbericht(e) für Wettermeldungen.

Abbildung 2

Bildliche Darstellung der Struktur der NtS-Nachricht: obligatorisches Element (1), obligatorisches Element, das einmal oder zweimal erscheinen kann (1…2), obligatorisches Element, das zweimal erscheinen muss (2), obligatorisches Element, das so oft erscheinen kann wie erforderlich (1-n), fakultatives Element, das so oft erscheinen kann wie erforderlich (0…n)

Der Identifikationsabschnitt ist obligatorisch und enthält allgemeine Angaben zum Urheber der Nachricht, dem Absender, dem Herausgabedatum, dem Land und der Ausgangssprache; er wird zusammen mit einem der vier verschiedenen Abschnittsarten der NtS-Nachricht übermittelt:

—

Fairway and traffic related section: eine „Wasserstraßen- und verkehrsbezogene Nachricht” (FTM) wird gewöhnlich von NtS-Editoren gemäß dem NtS Encoding Guide für Editoren erstellt. Bezug genommen wird auf Wasserstraßenabschnitte (definiert durch die ISRS Location Codes für ihren Anfang und ihr Ende) und/oder auf Objekte an der Wasserstraße (definiert durch den jeweiligen ISRS Location Code). [Gehe zu Kapitel 6]

—

Water level related section: eine „Wasserstandsmeldung” (WRM) erleichtert die Übermittlung von Informationen über aktuelle und vorhergesagte Wasserstände sowie anderer Informationen. Gewöhnlich werden WRM automatisch (und regelmäßig) auf der Grundlage von Sensormessungen oder des Infrastrukturstatus erstellt und erfordern kein Eingreifen des NtS-Editors. Der die Wasserstandsmeldung betreffende Abschnitt enthält Informationen über ein Objekt (z. B. eine Pegelstelle) oder einen Wasserstraßenabschnitt (z. B. die minimale Tiefe für einen Abschnitt oder das geltende Schifffahrtsregime auf einem Wasserstraßenabschnitt). Das Objekt wird mittels seines ISRS Location Code identifiziert, der Wasserstraßenabschnitt wird durch die ISRS Location Codes für seinen Anfang und sein Ende definiert. [Gehe zu Kapitel 3]

—

Ice related section: Eine „Eismeldung” (ICEM) enthält Informationen über die Eisverhältnisse in einem Wasserstraßenabschnitt, der durch die ISRS Location Codes für seinen Anfang und sein Ende definiert wird. [Gehe zu Kapitel 4]

—

Weather related section: Eine „Wettermeldung” (WERM) ermöglicht die Übermittlung von Informationen über aktuelle und vorhergesagte Wetterlagen in einem Wasserstraßenabschnitt, der durch die ISRS Location Codes für seinen Anfang und sein Ende definiert wird. [Gehe zu Kapitel 5]

Darüber hinaus wird der ISRS (International Ship Reporting Standard) Location Code zur Definition des Objekts oder des Wassserstraßenabschnitts verwendet, auf das bzw. den sich die Nachricht bezieht. Der ISRS Location Code ist in Nummer 4.3 des Anhangs dieser Verordnung definiert.

3.

Grundüberlegungen WRM

Wasserstandsinformationen sind sowohl für die Reiseplanung als auch für die Sicherheit von Bedeutung. Derzeit gibt es keinen gemeinsamen Standard als Referenz für Wasserstandsinformationen. Die Pegelwerte beziehen sich auf unterschiedliche Meeresniveaus oder spezielle Pegelnullpunkte. Für eine angemessene Bezugnahme ist mit dem Wert stets der jeweilige „reference_code” bereitzustellen. WRM können zur Übermittlung folgender Informationen genutzt werden:

—

Wasserstand (einschließlich Vorhersagen),

—

Minimale Tiefe (einschließlich Vorhersagen),

—

Durchfahrtshöhe (einschließlich Vorhersagen),

—

Abfluss (einschließlich Vorhersagen),

—

Wehrstellung,

—

Regime.

Erläuterungen zu Übersetzungen in der Kalkulationstabelle „reference code” sind Kapitel 7.11 zu entnehmen. Üblicherweise werden WRM automatisch auf der Grundlage von Informationen, die von Sensoren oder der Infrastruktur (z. B. Vorhersagen, Staustand) übermittelt werden, erstellt und herausgegeben. Für die Herausgabe von WRM kann es unterschiedliche Auslöser geben, beispielsweise werden sie in regelmäßigen Abständen oder beim Erreichen bestimmter Werte herausgegeben.

3.1.

Ausfüllen des Abschnitts nts_number in der WRM

In der NtS XSD 4.0 ist die NtS-Nummer in WRM optional. Wird sie übermittelt, muss die Nummer für jeden Nachrichtentyp einmalig sein (Organisation/Year/Number/Serial) und es obliegt der die WRM bereitstellenden Organisation, einmalige Nummern zu gewährleisten (aufeinanderfolgende Nummern sind nicht erforderlich).

3.2.

Ausfüllen der WRM einschließlich der Vorhersagen

In „date_start” von „validity_period” ist das heutige Datum (date_issue) einzutragen; in „date_end” von „validity_period” muss der Tag nach dem „date_issue” eingetragen werden. Um Veränderungen, beispielsweise beim Wasserstand, benutzerfreundlich zu übermitteln, kann die Differenz zu einer früheren Vergleichsmessung im Abschnitt „difference” der WRM eingetragen werden. Neben der Veränderung beim Wert (z. B. - 5 [cm]) ist auch der Zeitunterschied zur Vergleichsmessung einzutragen. Bei Vorhersagen ist „measure_date” das Datum und die Uhrzeit, für das bzw. die die Vorhersage gilt. Wasserstandsvorhersagen beinhalten immer einen Unsicherheitsfaktor. Gewöhnlich werden Modelle mit unterschiedlichen Parametern (z. B. Wettervorhersagen) berechnet, die zu unterschiedlichen Vorhersagewerten für den Wasserstand führen. Um die Übermittlung eines vorhergesagten Mindest- und Höchstwerts zu ermöglichen, beispielsweise die visuelle Darstellung eines Vertrauensintervalls für die Wasserstandsvorhersage, enthält der Abschnitt „measure” der WRM zwei zusätzliche, optionale Datenfelder. Die folgende Abbildung enthält eine Darstellung des Vertrauensintervalls für Wasserstandsvorhersagen.

Abbildung 3

Bildliche Darstellung des Vertrauensintervalls für die Wasserstandsvorhersage: wahrscheinlichster Wert (schwarz), obere Grenze des Vertrauensintervalls (violett), untere Grenze des Vertrauensintervalls (rot), gemessener Wasserstand (blau).

(Die x-Achse gibt die Zeit an, die y-Achse den Wasserstand (in cm))

In der NtS XSD stehen zwei Elemente zur Verfügung:

<value_min>

niedrigster Wert des Vertrauensintervalls

<value_max>

höchster Wert des Vertrauensintervalls

Neben den vorhergesagten Wasserständen kann das Vertrauensintervall auch zur Angabe der Unsicherheit der veröffentlichten Informationen über die minimale Tiefe und die Durchfahrtshöhe genutzt werden. Die Werte value_min und value_max des Vertrauensintervalls ermöglichen, über die standardisierte NtS-WRM das Vertrausensintervall für WRM-Werte zu übermitteln, um es in grafischen Darstellungen zu verwenden. Die eigentlichen Rohdaten werden den IWT-Nutzern nicht angezeigt (z. B. im Codeformat). Der measure_code „NOM” darf nicht verwendet werden. Falls für einen bestimmten Typ von WRM keine Messung vorliegt, sind die entsprechenden Wertelemente freizulassen, wenn trotzdem eine Meldung gesendet werden soll.

4.

Prozesse für ICEM

Eismeldungen sind von örtlicher Beobachtung und Bewertung abhängig und werden gewöhnlich von Hand erstellt (bei einer automatischen Erstellung müssen die Regeln für die manuelle Erstellung befolgt werden, siehe den NtS Encoding Guide für Editoren). Eine ICEM wird für einen bestimmten fairway_section, der durch die ISRS Location codes für seinen Anfang und sein Ende definiert wird, herausgegeben und enthält die Eisverhältnisse (ice_condition) an einem bestimmten Messdatum. Die Gültigkeit der ICEM beginnt am Tag der Herausgabe (wird von der NtS-Anwendung automatisch eingesetzt). Um zu vermeiden, dass Nutzern ICEM angezeigt werden, die nicht mehr gültig sind, muss als date_end der Gültigkeit von der NtS-Anwendung automatisch der Tag nach der Herausgabe eingetragen werden (außer wenn durch nationale Prozesse sichergestellt wird, dass Meldungen ein Enddatum der Gültigkeit zugewiesen wird, sobald die in der Meldung enthaltene Information nicht mehr aktuell ist). Im NtS Encoding Guide für Editoren wird beschrieben, unter welchen Umständen ein NtS-Editor eine neue ICEM erstellt oder eine ICEM aktualisiert. Es gelten die folgenden Prozesse:

4.1.

Neue ICEM

1)

NtS-Anwendungen können NtS-Editoren folgende Möglichkeiten bieten:

a)

die Verwendung bestehender Nachrichten als Entwurf für die Erstellung neuer ICEM (z. B. wenn die Eisverhältnisse denen in der bestehenden Nachricht ähnlich sind) und/oder

b)

die Nutzung von Nachrichtenvorlagen für bestimmte Situationen.

2)

Der Inhalt (z. B. der Zeitpunkt der Messung oder die jeweiligen Eisverhältnisse) muss vom Editor im Einklang mit Kapitel 6 des NtS Encoding Guide für Editoren eingegeben werden. Auch das Datum und die Uhrzeit der Messung können von der Anwendung den jeweiligen nationalen Definitionen entsprechend festgelegt werden.

3)

Löst ein NtS-Editor/-Herausgeber die Herausgabe aus,

a)

wird kontrolliert, ob alle obligatorischen Inhalte der NtS XSD entsprechend bereitgestellt wurden (wenn nicht, zurück zu Schritt (2)),

b)

wird die nts_number von der NtS-Anwendung erzeugt,

i)

wird in „organisation” je nach Funktion des herausgebenden Nutzers der Name oder Code der verantwortlichen Organisation eingetragen,

ii)

wird in „year” das aktuelle Jahr eingetragen,

iii)

wird die nächst verfügbare „number” zugewiesen,

iv)

wird die „serial number” 0 zugewiesen.

c)

wird in „date_issue” automatisch das tatsächliche Datum/die tatsächliche Uhrzeit der Herausgabe eingetragen,

d)

wird in „validity_period”  — „date_start” automatisch das tatsächliche Datum der Herausgabe eingetragen,

e)

wird in „validity_period”  — „date_end” automatisch der Tag nach dem Herausgabedatum eingetragen (außer wenn durch nationale Prozesse sichergestellt wird, dass Meldungen ein Enddatum der Gültigkeit zugewiesen wird, sobald die in der Meldung enthaltene Information nicht mehr aktuell ist).

4.2.

Aktualisierung einer bestehenden ICEM

1)

Die entsprechende, bereits herausgegebene Meldung wird ausgewählt und im Editionstool für ICEM aktualisiert. Die ursprüngliche ICEM muss kopiert oder in der Datenbank geändert werden (je nach nationalen Prozessen). Abgelaufene ICEM (die das validity_date_end überschritten haben) können nicht mehr aktualisiert werden; ist dies der Fall, müssen die NtS-Editoren eine neue ICEM erstellen.

2)

Der Inhalt (z. B. der Zeitpunkt der Messung oder die jeweiligen Eisverhältnisse) muss vom Editor im Einklang mit Kapitel 6 des NtS Encoding Guide für Editoren geändert werden. Datum und Uhrzeit der Messung könnten ebenfalls von dere Anwendung den jeweiligen nationalen Definitionen entsprechend geändert werden.

3)

Löst ein NtS-Editor/-Herausgeber die Herausgabe aus,

a)

wird kontrolliert, ob alle obligatorischen Inhalte der NtS XSD entsprechend bereitgestellt wurden (wenn nicht, zurück zu Schritt (2)),

b)

wird die nts_number von der Anwendung erzeugt,

i)

bleibt „organisation” unverändert,

ii)

bleibt „year” unverändert,

iii)

bleibt „number” unverändert,

iv)

wird die „serial number” erhöht (um 1 erhöht),

c)

wird in „date_issue” automatisch das tatsächliche Datum/die tatsächliche Uhrzeit der Herausgabe eingetragen,

d)

wird in „validity_period”  — „date_start” automatisch das tatsächliche Datum der Herausgabe eingetragen,

e)

wird in „validity_period”  — „date_end” automatisch der Tag nach dem Herausgabedatum eingetragen (außer wenn durch nationale Prozesse sichergestellt wird, dass Meldungen ein Enddatum der Gültigkeit zugewiesen wird, sobald die in der Meldung enthaltene Information nicht mehr aktuell ist).

5.

Grundüberlegungen zu WERM

Üblicherweise werden WERM automatisch auf der Grundlage von Informationen, die von Sensoren oder der Infrastruktur übermittelt werden, erstellt und herausgegeben. In „date_start” von „validity_period” ist das heutige Datum (date_issue) einzutragen; in „date_end” von „validity_period” muss der Tag nach dem „date_issue” eingetragen werden. In WERM wird der Wasserstraßenabschnitt als eine Strecke zwischen zwei Punkten des Wasserstraßenabschnitts, also als Geltungsbereich der Wetterstation (Pegel), angegeben. Datum und Uhrzeit der Messung/Vorhersage müssen übermittelt werden, auch wenn dies in WERM nicht obligatorisch ist. Bei Vorhersagen ist unter dem „Messdatum” (measure date) das Datum und die Uhrzeit zu verstehen, für das/die die Vorhersage gilt.

5.1.

Ausfüllen des Abschnitts nts_number in der WERM

In der NtS XSD 4.0 ist die NtS-Nummer in WERM optional. Wird sie übermittelt, muss die Nummer für jeden Nachrichtentyp einmalig sein (Organisation/Year/Number/Serial) und es obliegt der die WERM bereitstellenden Organisation, einmalige Nummern zu gewährleisten (aufeinanderfolgende Nummern sind nicht erforderlich).

5.2.

Ausfüllen des Abschnitts „weather_category_code” in der WERM

Die Windgeschwindigkeit im „weather_category_code” (Werte 0 bis 12) ist entsprechend der von der Weltorganisation für Meteorologie in ihrem Handbuch für Seewetterdienste (Manual on Marine Meteorological Services) WMO-Nr. 558 veröffentlichten Beaufort-Skala zu übermitteln. Die Sichtverhältnisse im „weather_category_code” (Werte 13 bis 22) sind entsprechend der Definition in der folgenden Tabelle anzugeben.

Wert, Bedeutung	Sichtweite	Ergänzende Information
13, dicker Nebel	unter 50 m
14, dichter Nebel	unter 100 m
15, mäßiger Nebel	unter 200 m
16, Nebel	unter 1000 m	Nebel besteht aus Wassertröpfchen.
17, Dunst	zwischen 1 km und 4 km	Dunst besteht aus Wassertröpfchen. Der Begriff „Dunst” wird bei „trockenem Nebel” verwendet; dieses Phänomen tritt gewöhnlich vor dem Sonnenaufgang ein.
18, diesig	zwischen 1 km und 4 km	Diesige Sichtverhältnisse entstehen durch trockene Partikel.
19, leicht diesig	zwischen 4 km und 10 km
20, klar	zwischen 10 km und 20 km
21, sehr klar	keine Einschränkung der Sichtweite
22, kein Nebel		„No fog” wird verwendet, um je nach nationalen oder lokalen Anforderungen anzugeben, dass kein Nebel vorhanden ist.

6.

Prozesse für FTM

Im NtS Encoding Guide für Editoren wird beschrieben, unter welchen Umständen ein NtS-Editor eine neue FTM erstellt oder eine bestehende FTM aktualisiert. Es gelten die folgenden Prozesse:

6.1.

Neue FTM

1)

NtS-Anwendungen können NtS-Editoren folgende Möglichkeiten bieten:

a)

die Nutzung bestehender Nachrichten als Entwurf für die Erstellung neuer FTM und/oder

b)

die Nutzung von Nachrichtenvorlagen für bestimmte Situationen.

2)

Die Eingabe des Inhalts (z. B. Gültigkeitszeitraum, Einschränkungen) muss der Editor gemäß den Kapiteln 3 und 4 des NtS Encoding Guide für Editoren vornehmen.

3)

Löst ein NtS-Editor/-Herausgeber die Herausgabe aus,

a)

wird kontrolliert, ob alle obligatorischen Inhalte der NtS XSD entsprechend bereitgestellt wurden (wenn nicht, zurück zu Schritt (2)),

b)

wird die nts_number von der Anwendung erzeugt,

i)

wird in „organisation” je nach Funktion des herausgebenden Nutzers der Name oder Code der verantwortlichen Organisation eingetragen,

ii)

wird in „year” das aktuelle Jahr eingetragen,

iii)

die nächste verfügbare „number” wird zugewiesen, sofern der NtS-Editor eine hierzu bestimmte Nummer eingegeben hat oder wenn ein Anwendungsprozess in Schritt 2 übernommen wird (vorausgesetzt, dass (Organisation/Year/Number/Serial) wie in Kapitel 15.1 erläutert einmalig vergeben worden sind).

iv)

wird die „serial number” 0 zugewiesen,

c)

in „date_issue” wird automatisch das aktuelle Datum/die aktuelle Uhrzeit des Herausgabevorgangs eingetragen.

6.2.

Aktualisierung/Aufhebung einer bestehenden FTM

1)

Die betreffende, bereits herausgegebene Nachricht muss zur Aktualisierung in das Editionstool für FTM kopiert oder in der Datenbank geändert werden (je nach nationalen Prozessen).

a)

Abgelaufene FTM (die das validity_date_end überschritten haben) können nicht mehr aktualisiert werden; ist dies der Fall, müssen die NtS-Editoren eine neue FTM erstellen.

b)

Der Betreff-Code „Nachricht aufgehoben” wird nur verwendet, wenn

i)

das aktuelle Datum vor dem validity_date_start liegt. Falls nur der Inhalt des Feldes „ergänzender Text in Originalsprache” geändert werden darf, muss der weitere Inhalt der Nachricht (Schritt 2) unverändert stehen bleiben.

ii)

der Gültigkeitszeitraum bereits begonnen hat und das neue Enddatum für alle Einschränkungen in der Vergangenheit liegt. Das Enddatum der Einschränkung muss auf die korrekte Zeit gesetzt werden.

c)

Wird eine Nachricht aufgehoben, muss das Enddatum des Gültigkeitszeitraums stets auf das Datum der Aufhebung festgelegt werden.

2)

Die Änderung des Inhalts (z. B. Gültigkeitszeitraum, Einschränkungen) muss der Editor gemäß den Kapiteln 3 und 4 des NtS Encoding Guide für Editoren vornehmen.

3)

Löst ein NtS-Editor/-Herausgeber die Herausgabe aus,

a)

wird kontrolliert, ob alle obligatorischen Inhalte der NtS XSD entsprechend bereitgestellt wurden (wenn nicht, zurück zu Schritt (2)),

b)

wird die nts_number von der Anwendung erzeugt,

v)

bleibt „organisation” unverändert,

vi)

bleibt „year” unverändert,

vii)

bleibt „number” unverändert,

viii)

wird die „serial number” erhöht (um 1 erhöht),

c)

wird in „date_issue” automatisch das tatsächliche Datum/die tatsächliche Uhrzeit der Herausgabe eingetragen,

b.

FTM mit dem Betreff-Code „Nachricht aufgehoben” werden nicht (mehr) für die Reiseplanung berücksichtigt.

6.3.

FTM in Bezug auf Wasserstraßen und Objekte

Eine FTM in Bezug auf Wasserstraßen enthält Informationen über einen oder mehrere Wasserstraßenabschnitt(e). Ein Wasserstraßenabschnitt wird im Teil „fairway_section” durch die ISRS Location Codes für seinen Anfang und sein Ende definiert. Eine FTM in Bezug auf Objekte enthält Informationen über ein oder mehrere besondere(s) Objekt(e) an der Wasserstraße. Ein Objekt wird im Teil „object” durch seinen ISRS Location Code definiert. Eine FTM muss sich auf Folgendes beziehen:

—

einen oder mehrere Wasserstraßenabschnitt(e) oder

—

ein oder mehrere Objekt(e) in einem oder mehreren Wasserstraßenabschnitt(en).

6.4.

Automatische Rangfolge von Einschränkungscodes

Unterschiedliche Einschränkungen haben unterschiedliche Auswirkungen auf die Schifffahrt. Um die Anzeige der schwerwiegendsten Einschränkungen — etwa in einer FTM-Übersichtsliste — zu ermöglichen, sollte die folgende Rangfolge berücksichtigt werden, beginnend mit der schwerwiegendsten Einschränkung auf Rang 1:

Rang	Kennwert	Bedeutung (DE)
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.

Handhabung des Einschränkungszeitraums

—

Zwecks Nutzerfreundlichkeit sollten Einschränkungen mit den gleichen Einschränkungszeiträumen in der Anzeige zu Gruppen oder Listen zusammengefasst werden.

—

Die NtS-Editionstools sollten eine Funktion bieten, mit der Editoren das erneute Eingeben von Einschränkungszeiträumen vermeiden können.

—

Alle Einschränkungen müssen einen Einschränkungszeitraum mit einem Intervall-Code enthalten, um in Reiseplanungsprorammen eine korrekte Berechnung zu ermöglichen. Zur Arbeitserleichterung für NtS-Editoren können folgende Funktionen eingerichtet werden:

—

Das NtS-Editionstool kann eine Funktion zum Kopieren bereits eingegebener Einschränkungen bieten, damit der Editor den Einschränkungszeitraum nicht erneut eingeben muss.

—

Das NtS-Editionstool kann eine Funktion zur Auswahl mehrerer Einschränkungscodes für einen bestimmen Einschränkungszeitraum bieten und auf der Basis der vom Editor eingegebenen Informationen automatisch die erforderlichen Einschränkungsabschnitte erzeugen.

—

„Montags bis freitags außer an gesetzlichen Feiertagen” : Der Wert „Feiertag” stellt für Reiseplanungsanwendungen eine große Schwierigkeit dar. Für eine korrekte Berechnung ist eine Aufstellung der Feiertage für jedes Land erforderlich. Steht eine solche Liste nicht zur Verfügung, werden den gesetzlichen Feiertagen trotzdem die jeweiligen Einschränkungen zugewiesen.

—

„mit Ausnahme von” : darf nicht verwendet werden. Unterbrochene Intervalle müssen als getrennte Einschränkungszeiträume innerhalb ein- und derselben Einschränkung angegeben werden; aus diesem Grund sollte dieser Code den Editoren nicht angezeigt werden/zur Verfügung stehen.

—

Logik und Anzeige von Informationen, die im Fall des Intervall-Codes „continuous” gelten:

<date_start>2015-04-01+01

<date_end>2015-06-30+02

<time_start>06:00:00

<time_end>10:00:00

<interval_code>CON

Lautet der interval_code „continuous” (fortlaufend), gehört start_time zum start_date und end_time zum end_date, z. B. vom 1. April 06:00 Uhr bis zum 30. Juni 10:00 Uhr.

—

Logik und Anzeige von Informationen bei anderen Intervall-Codes als „continuous” :

<date_start>2015-04-01+01

<date_end>2015-06-30+02

<time_start>06:00:00

<time_end>10:00:00

<interval_code>WRK

Hat der interval_code einen anderen Wert, gehören start_time und end_time zu diesem interval_code, z. B. vom 1. April bis zum 30. Juni, Montag bis Freitag von 06:00 bis 10:00.

—

Das Ende des Einschränkungszeitraums muss immer in der letzten Fassung einer Nachricht eingetragen werden.

7.

Allgemeine Regeln für die Umsetzung

Es ist Folgendes zu berücksichtigen:

—

Die in den NtS Reference Tables bereitgestellte Tabelle „GUI_labels” ist beim Aufbau von NtS-Anwendungen (Suchmasken, Anmeldeformular für E-Mails, Anzeige von Nachrichten) zu berücksichtigen.

—

Das date_end kann nicht vor dem date_start liegen.

—

Mittels NtS-Änderungsanträgen (siehe Kommentare in der NtS XSD) außer Betrieb gesetzte Codes (die nicht mehr benutzt werden sollen) sind NtS-Editoren bei der Erstellung neuer Nachrichten nicht anzuzeigen. Zur Wahrung der Rückwärtskompatibilität sind diese Codes aber noch in den den NtS XSD-Enumerationen enthalten.

7.1.

Ausfüllen des Abschnitts „number_section”

Jede Nummer (Organisation/Year/Number/Serial) muss für jeden Nachrichtentyp einmalig vergeben sein. Das bedeutet, dass Nachrichten unterschiedlicher Typen die gleiche NtS-Nummer haben können. Für Nutzer sind die Nachrichtennummern nur für FTM und ICEM relevant; bei allen anderen Nachrichtentypen kann die Anzeige der Nachrichtennummer je nach nationalen Anforderungen unterbleiben. Den Nutzern ist die Nachrichtennummer im folgenden Format anzuzeigen: „Message Type/Country/Organisation/Year/Number/Serial” (je nach verwendeten Filtern und sofern dabei keine Informationen verloren gehen, kann sie verkürzt werden).

7.2.

Ausfüllen der Elemente „from” , „originator” , „organisation” und „source”

In das Element „from” im Identifikationsabschnitt wird der Name des nationalen Systems, das die Nachricht bereitstellt, eingetragen (z. B. ELWIS, DoRIS, SLOVRIS, FLARIS). Das Element „originator” bezeichnet die Organisation, die Nachrichten in nationale Systeme eingibt. Das Element „source” bezeichnet die Behörde, für die die wasserstraßen- und verkehrsbezogenen Nachrichten herausgegeben werden. Das Element „organisation” im Abschnitt nts_number ist der Name der die nts_number zuweisenden Organisation (NtS-Anbieter).

7.3.

Weglassen von Elementen

Elemente, die nur Standardwerte oder vorgegebene Werte enthalten würden, werden weggelassen, sofern sie an Bedingungen geknüpft sind, denn sie führen nur zu allgemeinen Nachrichten ohne Mehrwert. Dies betrifft die folgenden Elemente:

—

Zielgruppe: target_group_code ALL mit direction_code ALL (wenn keine anderen, besonderen Zielgruppen in der Nachricht bestehen);

—

position_code: AL,

—

reason_code: OTHER.

7.4.

Automatische Eintragung von date_issue

FTM und ICEM Bei FTM und ICEM entspricht der Wert des Elements date_issue dem aktuellen Datum und der aktuellen Uhrzeit der Herausgabe. Bei aktualisierten Nachrichten entspricht date_issue dem Datum und der Uhrzeit der Herausgabe der Aktualisierung. WRM und WERM Bei WRM und WERM entspricht der Wert des Elements date_issue dem Datum und der Uhrzeit der Verarbeitungsaufforderung, denn innerhalb einer WRM oder WERM können mehrere Messungen mit unterschiedlichen Herausgabe-Zeitstempeln vorliegen.

7.5.

Handhabung von Angaben über Zeitzonen in NtS-Nachrichten

In NtS-XML-Nachrichten sind Datum und Uhrzeit immer als Ortszeit unter Einschluss von Angaben zur Zeitzone zu übermitteln. Die einzigen Ausnahmen zu dieser Bestimmung sind „time_start” und „time_end” im Abschnitt „limitation_period” . Der Grund hierfür ist, dass im Abschnitt für die Einschränkung ein Intervall verwendet werden kann. Bestehen für das Start- und das Enddatum unterschiedliche Zeitregelungen (z. B. CEST und CET), führt dies zu einer Änderung der Zeitzonenangabe innerhalb dieses Intervalls. Diese Änderung kann nicht mit Hilfe eines einzigen Einschränkungszeitraums ausgedrückt werden. Anstatt für jede Zeitänderung andere Einschränkungszeiträume anzulegen, wird ein einziger Einschränkungszeitraum ohne Zeitzoneninformation verwendet, um den allgemeinen Aufwand in der Verarbeitung und Übertragung von Nachrichten zu verringern.

7.6.

Handhabung von Sekunden in NtS-Nachrichten

Als allgemeine Regel gilt, dass Sekunden in Feldern für (Datum/)Uhrzeit angegeben werden müssen, aber den NtS-Nutzern nicht angezeigt werden. Minuten genügen für NtS-Granularität.

7.7.

Format der Dezimalzahlen in NtS-Nachrichten

Dezimalzahlen in numerischen Feldern werden mit einem „.” (Punkt) angegeben. Es wird kein Tausender-Trennzeichen benutzt. Zur Gewährleistung einer nutzerfreundlichen Anzeige ist die Anzahl der für die Angabe von Werten verwendeten Dezimalstellen auf eine praktikable Anzahl zu begrenzen.

7.8.

In NtS-Nachrichten zu verwendende Maßeinheiten

In NtS-Nachrichten dürfen nur cm, m3/s, h, km/h und kW, m/s (Wind), mm/h (Regen) und Grad Celsius als Maßeinheiten benutzt werden; zwecks Nutzerfreundlichkeit können die Maßeinheiten in Anwendungen umgerechnet werden. Unterscheiden sich die Eingabeeinheiten von den standardisierten Einheiten, müssen die eingegebenen Werte von der Anwendung entsprechend umgerechnet werden.

7.9.

Regeln für die Elemente „name” , „position_code” und „type_code”

Das Element „name” wird automatisch aus den Referenzdaten des RIS Index ( „national object name” ) eingetragen (NtS-Editoren können die vorausgefüllten Namen ändern, wenn dies eine nationale Vorschrift ist). Benennungskonventionen für Objektbezeichnungen sind dem RIS Index Encoding Guide, Fassung 2.0 oder höher, zu entnehmen. Auch im NtS Encoding Guide für Editoren werden Beispiele für ordnungsgemäße Objektnamen aufgeführt. Der Typcode (type_code) wird dem Objektnamen von der NtS-Anwendung vorangestellt. Die Position von Objekten wird mittels des Positionscodes (position_code) codiert und dem Objekt von der NtS-Anwendung aus dem RIS Index hinzugefügt. Editoren können vorausgefüllte Typ- und Positionscodes ändern. Für geo_objects im fairway_section wird kein Objektpositionscode übermittelt. Ein vollständiger Objektname besteht aus dem „position_code” , dem „typ_code” und dem „name” . Zur Arbeitserleichterung für NtS-Editoren können in NtS-Editionstools, die Editoren bei der Suche bzw. Auswahl der zutreffenden Objekte auf der Basis des RIS Index function_code oder dem NtS-type_code unterstützen, folgende Zuordnungen eingerichtet werden:

Tabelle 1

Entsprechung „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	harbour
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.

Regeln für das Element „fairway_name”

Zur Vermeidung der Anwendungslogik bzw. der Notwendigkeit korrekter Referenzdaten im Empfangssystem (der Software, mit der dem Nutzer die Nachricht angezeigt wird) muss das optionale Element „fairway_name” immer in das „geo_object” aufgenommen und von der NtS-Anwendung automatisch mit dem „waterway name” aus dem RIS Index ausgefüllt werden. Editoren dürfen den Inhalt des Elements „fairway_name” nicht ändern.

7.11.

Erläuterungen zu Übersetzungen in der Kalkulationstabelle „reference_code”

Für die Werte des reference_code in den NtS Reference Tables sind folgende Definitionen zu verwenden:

—

NAP: In den Niederlanden wird die Abkürzung NAP benutzt und verstanden, NAP wird nicht übersetzt.

—

KP: „channel level” ist zu übersetzen, also in der Landessprache zu übermitteln.

—

FZP: Nur die Abkürzung „FZP” ist zu verwenden (wird heute kaum noch verwendet).

—

ADR: „Adria” ist zu übersetzen, also in der Landessprache zu übermitteln.

—

TAW/DNG: „Tweede algemene waterpassing” (Niederländisch) — „Deuzième Nivellement Général” (Französisch) ist die in Belgien verwendete Referenzhöhe, mit der Höhenmessungen ausgedrückt werden. 0 ist der mittlere Meeresspiegel bei Niedrigwasser in Oostende

—

Niederländisch: TAW

—

Französisch: DNG

—

Alle anderen Sprachen: TAW/DNG

—

LDC: „RNW gemäß Donaukommission” ist zu übersetzen, also in der Landessprache zu übermitteln

—

HDC: „HSW gemäß Donaukommission” ist zu übersetzen, also in der Landessprache zu übermitteln

—

ETRS: „European Terrestrial Reference System 1989” ; die Abkürzung „ETRS89” wird in allen Sprachen benutzt.

7.12.

Empfehlung für das Element „coordinate”

Obgleich das Element „Koordinate” im Abschnitt Geo-Objekt optional ist, sind die geografischen Koordinaten in WGS84 im Format [d]d mm.mmm[m] N (latitude) und [d][d]d mm.mmm[m] E (longitude) anzugeben. Dies dient zur Herstellung eines geografischen Bezugs der NtS-Mitteilungen.

7.13.

Handhabung von Zielgruppen

Der Abschnitt Zielgruppe besteht aus dem Code für die Zielgruppe und dem Code für die Richtung. Wenn beide den Wert ALL haben, ist der gesamte Abschnitt auszulassen, sofern in der Nachricht keinen anderen, besonderen Zielgruppen enthalten sind. Wird nur einer der beiden Codes angegeben, muss der andere mit dem vorgegebenen Wert ALL ausgefüllt werden, weil beide Elemente obligatorisch sind. Weitere Informationen zu Zielgruppen sind dem NtS Encoding Guide für Editoren zu entnehmen.

7.14.

Anzeige der zu einem bestimmten Zeitpunkt gültigen Nachrichten

Das Element „validity_period” ist von den Anwendungen zur Auswahl derjenigen Nachrichten zu nutzen, die Nutzern über einen angeforderten Zeitraum angezeigt werden sollen. Lautet der „subject_code” INFSER (Informationsservice), wird der Gültigkeitszeitraum zur Angabe des Zeitraums verwendet, in dem die Nachricht des Informationsservice für die Nutzer angezeigt wird, nicht für den Zeitraum, in dem die übermittelte Information gültig ist (z. B. ein Monat).

7.15.

Optionale Funktionen zur Erhöhung der Nutzerfreundlichkeit des NtS-Editionstools

Je nach nationalen Anforderungen können NtS-Editoren die folgenden Funktionen angeboten werden:

—

NtS-Anwendungen können NtS-Editoren die Möglichkeit bieten, Entwürfe von NtS-Nachrichten zu speichern (zum Speichern von Entwürfen müssen nicht alle obligatorischen Inhalte eingetragen sein);

—

Für unterschiedliche Editoren können unterschiedliche Nutzerfunktionen gelten (z. B. Editoren, die Nachrichten eingeben oder ändern können; Herausgeber, die Nachrichten (zusätzlich zur Edition) herausgeben dürfen).

8.

Struktur der NtS-XML-Nachrichten

Die Struktur der NtS-XML-Nachrichten sowie Inhalt und Zweck der Datenelemente werden in Anlage C „Definition des NtS-XML-Schemas (XSD)” definiert und näher erläutert.

9.

NtS Web Service

9.1.

Zielsetzung

Die NtS-Expertengruppe hat festgestellt, dass die Technologie des web service ein angemessenes Mittel zur Übermittlung der Nachrichten für die Binnenschifffahrt ist. Dieses Kapitel stellt die Spezifikation des web service für die Übermittlung von Nachrichten für die Binnenschifffahrt, kurz den NtS Web Service, dar. Besonderes Gewicht wurde auf die Verwendung bewährter internationaler Standards gelegt. Ein Ziel der konzeptionellen Gestaltung bestand darin, zwischen Flexibilität und Robustheit des entstehenden web service ein ausgewogenes Verhältnis zu gewährleisten. Die in den Anfragen vorgesehenen Filterparameter entsprechen im Wesentlichen den im NtS-Standard festgelegten Kriterien (Wasserstraßenabschnitt mit optionalem Fluss-km, zeitliche Gültigkeit, Datum der Herausgabe der Nachricht). In Anbetracht der Anwendungsfälle des web service erscheint dies als hinreichend aussagekräftig, begrenzt aber zugleich die Komplexität der Umsetzung. Hauptergebnis ist ein Vertrag über den web service, in dem die Anfragen und die Antworten festgelegt werden. Die Nutzer des web service können sich auf diesen Vertrag verlassen und die Provider müssen ihn einhalten. Dieser Vertrag wurde mittels des internationalen Standards WSDL festgelegt. Jeder teilnehmende Mitgliedstaat richtet einen oder mehrere web services für die verschiedenen NtS-Nachrichtentypen (FTM, WRM, ICEM, WERM) ein und stellt sie über das Internet bereit (NtS Message Service). Die technischen Einzelheiten für die Umsetzung des NtS Web Service, z. B. Auswahl geeigneter Datenpools, Anwendungen und Plattformen, fallen nicht unter diese Spezifikation und liegen in der Verantwortung jedes einzelnen teilnehmenden Mitgliedstaates. Um eine sichere Kommunikation festlegen zu können, müssen verschiedene Sicherheitsaspekte und Schutzziele berücksichtigt werden. Abhängig von den jeweiligen Umständen müssen nicht alle Aspekte in die Überlegungen einbezogen werden. Die Rangfolge der verschiedenen Sicherheitsaspekte und der Grad ihrer Umsetzung kann unterschiedlich sein. Die Möglichkeiten der technischen Umsetzungen können zudem die Realisierbarkeit einer bestimmten Maßnahme begrenzen. Alle Informationen im NtS-Kontext sind öffentlich. Es besteht also keine Notwendigkeit, die NtS-Daten an sich im Hinblick auf den Datenschutz zu sichern. Aus diesem Grund muss jeder Provider selbst entscheiden, in welchem Grad dieser Aspekt in seinem Dienst umgesetzt wird.

9.2.

Grundprinzipien und grundlegende Sachzwänge

9.2.1.

Web-Standards

Der NtS Web Service muss das WS-I-Grundprofil 1.1 erfüllen. Dieses Profil „bietet eine Orientierungshilfe für die Kompatibilität einer Grundmenge an Spezifikationen für nicht geschützte web services wie SOAP, WSDL und UDDI” ^(*). Die hier verwendeten, relevantesten Standards sind:

—

XML Schema Definition (XSD),

—

Simple Object Access Protocol (SOAP),

—

Web Services Description Language (WSDL) und

—

Universal Description, Discovery and Integration (UDDI).

Die Antwortnachricht des NtS Web Service ist eine NtS-Nachricht, die in der Definition des XML-Schemas (XSD) in Anlage C zur vorliegenden Verordnung der Kommission festgelegt ist.

SOAP

ist ein Anwendungsprotokoll für die Datenübertragung zwischen IT-Systemen; seine Standardisierung erfolgt durch die World Wide Web Consortiums (W3C).

Die besonderen Elemente für den NtS Web Service werden im Einklang mit den entsprechenden WSDL-Spezifikationen in Anlage D zur vorliegenden Verordnung der Kommission definiert. Das Schema des NtS-Standards (XSD) ist mit einer Importanweisung aufgenommen worden.

UDDI

(Universal Description, Discovery and Integration) wird hier als zentrales, möglicherweise internationales Register für web services, bei dem der NtS Web Service angemeldet werden könnte, aufgeführt. In diesem Register könnten potenzielle Nutzer des web service den Dienst suchen und finden. Da die potenziellen Provider des NtS Web Service jedoch durch die Mitgliedstaaten eingegrenzt werden und die WSDL-Spezifikation Bestandteil des Standards ist, erscheint eine unabhängige Anmeldung des NtS Web Service nicht erforderlich zu sein.

9.2.2.

Interaktionsmodell und Codierungsmethode für den NtS Web Service

Für den NtS Web Service wird die Codierungsmethode Document-Literal Wrapped genutzt, weil sie eine Validierung anhand eines XML-Schemas erlaubt und weil die in der WSDL-Spezifikation definierten Operationsbezeichnungen in den SOAP-Nachrichten unmittelbar als XML-Tag-Bezeichnungen verwendet werden.

9.3.

Allgemeine Spezifikationen und Empfehlungen

9.3.1.

Spezifikation: Angaben zur Version (Fassung)

Die Angaben zur Version des NtS Web Service bestehen aus zwei Abschnitten:

—

Version des web service an sich

—

Version des vom web service genutzten MtS-Schemas

Der Abschnitt des web service an sich besteht aus zwei Teilen:

—

übergeordnete Version des web service

—

untergeordnete Version des web service

Die übergeordnete Version wird als positive Ganzzahl angegeben und bezeichnet die Hauptversion des web service. Die untergeordnete Version wird als nicht negative Ganzzahl angegeben und bezeichnet die Nebenversion des web service innerhalb der Hauptversion. Der Abschnitt des NtS-Schemas enthält die Version des NtS-Schemas gemäß Definition durch die NtS-Expertengruppe. Die Version des hier spezifizierten NtS Web Service ist also 2.0.4.0, wobei 2.0 die Version des web service an sich bezeichnet und 4.0 die Version des genutzten NtS-Schemas. Ausdrückliche Angaben zur Version sind in den Anfragen oder Antworten des NtS Web Service nicht erforderlich. Es wird erwartet, dass nur jeweils wenige Versionen der Dienste gleichzeitig online sein werden. Unterschiedliche Versionen werden mit unterschiedlichen URL versehen. Folglich wird jede Implementierung eines NtS Web Service eine bestimmte Version des NtS Web Service unterstützen

9.3.2.

Spezifikation: Struktur von Namensräumen

Die Namensräume (namespaces) im NtS Web Service basieren auf der Web-Domäne der RIS-Expertengruppen, http://www.ris.eu/. Die Namensräume enthalten eine Komponente, die den entsprechenden Dienst sowie Informationen zur Version anzeigt. Der hier spezifizierte Dienst nutzt also den folgenden Namensraum: NtS Message Service: http://www.ris.eu/nts.ms/2.0.4.0

9.3.3.

Empfehlung: Nutzung von Namensräumen

Es wird empfohlen, zur Erzielung einer höheren Transparenz von XML-Dokumenten in dem am besten geeigneten Element der Schemata sowie den Dokumenten für den jeweiligen Fall Namensräume zu definieren und keine lokalen Namensraumdefinitionen in verschachtelten Elementen zu verwenden.

9.3.4.

Empfehlung: Verwendung von Vorsilben für Namensräume

Anfragen und Antworten im NtS Web Service nutzen XML-Elemente in qualifizierter Form, d. h. mit einer Vorsilbe für den Namensraum, und XML-Attribute in unqualifizierter Form, d. h. ohne Vorsilbe für den Namensraum. Um eine bessere Lesbarkeit für Menschen zu erreichen, wird empfohlen, intuitive Namensraumvorsilben wie beispielsweise „nts” zu verwenden.

9.3.5.

Spezifikation: Verwendung von ISRS Location Codes

Der ISRS Location Code wird in Kapitel 2 des NtS Encoding Guide für Anwendungsentwickler sowie im RIS Index Encoding Guide erläutert. Bei einer Abfrage eines NtS Web Service kann der Kunde auf verschiedene Objekte, z. B. Wasserstraßenabschnitte, Pegel oder Schleusen, Bezug nehmen. Werden die entsprechenden Parameter, die ID-Elemente, verwendet, müssen sie ISRS Location Codes enthalten. Diese Parameter werden üblicherweise in ID-Elementen angegeben, wobei jeder ein oder zwei IDs enthält. Bei der Verwendung dieser Parameter müssen die folgenden allgemeinen Konventionen eingehalten werden:

—

ISRS Location Codes müssen als Codes in voller Länge mit 20 Zeichen übermittelt werden, d. h. ohne Kürzung nachgestellter Nullen.

—

Werden innerhalb eines ID-Elements zwei IDs verwendet, müssen sich beide ISRS Location Codes auf dieselbe Wasserstraße beziehen. Dies bedeutet, dass die Codes im Teil „fairway_section” des ISRS Location Code einige identische Ziffern enthalten. Der Code für den Wasserstraßenabschnitt definiert zusammen mit dem Wasserstraßen-Hektometer einen als Paar von ID-Elementen übermittelten Wasserstraßenabschnitt.

Zur Übermittlung von Wasserstraßenabschnitten (ID-Elementpaaare innerhalb von „fairway_section geo_object” ) in NtS-Mitteilungen ist hinsichtlich der ISRS Location Codes Folgendes zu berücksichtigen:

—

Stellen 1 bis 2 (Country code):

—

müssen innerhalb des ID-Paars identisch sein, aber

—

innerhalb eines ID-Paars können verschiedene Ländercodes festgelegt werden, wenn benachbarte Länder für eine bestimmte Wasserstraße den gleichen Code für Wasserstraßenabschnitte und das gleiche System zur Definition der Hektometer nutzen.

—

Stellen 3 bis 5 (UN Location code):

—

sind nicht relevant, können innerhalb des ID-Paars unterschiedliche Inhalte enthalten;

—

Stellen 6 bis 10 (Fairway section code):

—

müssen innerhalb des ID-Paars identisch sein, aber

—

[Ausnahme]: werden im NtS Web Service die belgischen ISRS Location Codes verwendet, sollten zur Identifizierung des Wasserstraßenabschnitts nur die Stellen 6 bis 8 genutzt werden, weil die NtS-Nachrichten für verschiedene Abschnitte innerhalb einer Wasserstraße herausgegeben werden;

—

Stellen 11 bis 15 (Object Reference Code)

—

sind nicht relevant, können innerhalb des ID-Paars unterschiedliche Inhalte enthalten;

—

Stellen 16 bis 20 (Fairway Hectometre):

—

bestehen aus fünf numerischen Stellen zur Definition des Hektometers und enthalten daher gewöhnlich innerhalb des ID-Paars unterschiedliche Inhalte. Beispiel: „00235” für Wasserstraßen-km 23,5, „00001” für Wasserstraßen-km 0,1;

—

[Ausnahme]: In den Niederlanden besteht nicht immer eine unmittelbare Verbindung zwischen dem Wasserstraßen-Hektometer und dem physischen Kilometer der Wasserstraße; dies ist auf die Definition des Beginns des Wasserstraßenabschnitts im Netzwerkmodell einerseits und der realen Welt andererseits zurückzuführen; in derartigen Fällen beginnt der Objektreferenzcode für Objekte des Typs „dismar” mit Kxxxx (xxxx enthält den physischen Kilometer, z. B. NLSVG00130K000300191 (km 3)). Bei anderen Objekttypen besteht keine unmittelbare Beziehung zum physischen Wasserstraßenkilometer im ISRS-Code, z. B. hat die Brücke von Sas van Gent bei km 2,5 auf der gleichen Wasserstraße den ISRS-Code NLSVG001300521600186. Beim Kanaal Gent-Terneuzen beginnt der physische Kilometer 0,0 an der Grenze zwischen Belgien und den Niederlanden und der Wasserstraßen-Hektometer 0,0 beginnt am Anfang des Kanals in Gent.

Berührt eine Nachricht mehrere Wasserstraßenabschnitte, müssen alle Wasserstraßenabschnitte in getrennten „fairway_section” -XML-Elementen durch ihren Anfangs- und Endpunkt definiert werden. Für einige Länder/Regionen ist es erforderlich, Filterfunktionen einzurichten. Lautet der ISRS Location Code (1-2) beispielsweise BE, verwenden Sie den ISRS Location Code (6-8) als ID zur Herstellung eines linearen Bezugs zum Wasserstraßen-Hektometer (ISRS Location Code 16-20). Beispiele für Wasserstraßenabschnitte (gültige ID-Elementpaare im „fairway_section” ), die die oben definierten Ausnahmen enthalten:

—

Die beiden NL-ISRS Location Codes sind eine gültige Definition eines Wasserstraßenabschnitts (der hinsichtlich des Wasserstraßenkilometers die Ausnahme für die Niederlande (NL) aufweist): NLSVG00130K000300191 (km 3,0 bei Sas van Gent am Kanaal Gent-Terneuzen) — NLWDP00130K000400200 (km 4,0 bei Westdorpe am Kanaal Gent-Terneuzen),

—

Die beiden BE-ISRS Location Codes sind eine gültige Definition eines Wasserstraßenabschnitts (der hinsichtlich des faiway section code die Ausnahme für Belgien (BE) aufweist ( „020” Albertkanaal)): BEGNK02016L010100414 (Schleuse in Genk, gelegen an km 41,4 am Albert Canal) — BEOSH02033L010500772 (Schleuse in Ham, gelegen am km 77,2 am Albert Canal).

Die folgende Abbildung zeigt für jede der allgemeinen Konventionen Gegenbeispiele für die Nutzung des ISRS Location Code (für Wasserstraßenabschnitte in der Slowakischen Republik (SK) gelten keine Ausnahmen von den allgemeinen Konventionen):

Ungültige Suchanfrage nach ISRS Location Codes

Allgemeine Bemerkung: Ein Abfragedienst für gültige ISRS Location Codes wird vom NtS Web Service nicht geboten. Die ISRS Location Codes werden im Europäischen Referenzdatenverwaltungssystem (European Reference Data Management System — ERDMS) bereitgestellt. Die korrekte Verwendung der ISRS Location Codes in Suchanfragen und die Auslegung dieser Codes wird in den folgenden fünf Fallbeispielen gezeigt.

Fallbeispiel 1: Kein IDS-Element in der Anfrage

Das IDS-Element ist ein optionaler Teil der Anfrage, d. h. eine Suchanfrage ohne jegliche IDs-Elemente ist zulässig:

Gültige Suchanfrage ohne IDS-Parameter

Wird kein IDS-Element angegeben, sind alle Nachrichten als Antwort zu senden (selbstverständlich abhängig von anderen Filterkriterien wie validity_period oder dates_issue).

Fallbeispiel 2: Ein ID-Element in der Anfrage

Jedes IDS-Element kann ein oder zwei ID-Elemente enthalten. In der folgenden Abbildung wird ein Fall mit einem ID-Element gezeigt:

Gültige Suchanfrage mit einem ID-Parameter

Geht eine solche Suchanfrage ein, sendet der Server alle übereinstimmenden Nachrichten mit einem Anfangs-Hektometer ≤ „angegebener Wert” (in diesem Beispiel 240,7) und einem End-Hektometer ≥ „dieser Wert” als Antwort. In der folgenden Abbildung wird diese Auswahl von Nachrichten gezeigt: Die abgefragte Position liegt zwischen den Werten für die Start- und End-Hektometer der Nachrichten 1, 3 und 4, die als Antwort geschickt würden. Die Nachrichten 2, 5 und 6 überschneiden sich nicht mit der abgefragten Position, daher würden sie nicht geschickt werden. Bezeichnet der angegebene ISRS Location Code ein einmaliges Objekt, z. B. einen Pegel oder eine Schleuse, sollte der web service die Nachrichten, in denen es um dieses Objekt geht, als Antwort schicken.

Übereinstimmende und nicht übereinstimmende Nachrichten für einen ID-Parameter

Fallbeispiel 3: Zwei ID-Elemente in der Anfrage

Jedes IDs-Element kann ein oder zwei ID-Elemente enthalten. In der folgenden Abbildung wird ein Fall mit zwei ID-Elementen gezeigt:

Gültige Suchanfrage mit zwei ID-Parametern

Alle abgefragten Hektometer-Werte werden auch dann als gültig behandelt, wenn der entsprechende Wasserstraßenabschnitt andere Anfangs- oder Endpunkte hat. Beginnt beispielsweise ein Wasserstraßenabschnitt an Hektometer 100,0 und endet er an Hektometer 300,0, wäre eine Anfrage, in der Hektometer 20,0 bis 400,0 abgefragt wird, gültig. Intern wird natürlich nur der „reale” Umfang des Wasserstraßenabschnitts durchsucht. Auf diese Weise wird die Suche nach sämtlichen Nachrichten über eine Wasserstraße ermöglicht, ohne dass der genaue Hektometer-Bereich bekannt ist (man würde dessen ISRS Location Code mit den Hektometerangaben „00000” bzw. „99999” einsenden). Es werden alle passenden Nachrichten, die das angegebene Hektometer-Intervall schneiden, als Antwort gesendet. Diese Situation wird in dem folgenden Diagramm dargestellt:

Übereinstimmende und nicht übereinstimmende Nachrichten für zwei ID-Parameter

Die vorstehende Abbildung zeigt, wie „schneiden” definiert ist. Während sich die Reichweite der Nachrichten 1 bis 4 mit dem Umfang des abgefragten Hektometer-Bereichs (teilweise oder vollständig) überschneidet, trifft dies für die Reichweite der Nachrichten 5 und 6 nicht zu; daher werden die Nachrichten 1 bis 4 als Antwort übermittelt, 5 und 6 jedoch nicht. Die technische Voraussetzung dafür, dass sich eine Nachricht mit einem Intervall [A, B] schneidet, lautet: Der Anfangs-Hektometer der Nachricht ist ≤ B und ihr End-Hektometer ist ≥ A.

Kombination: Mehrere IDs-Elemente in Anfragen

Gültige Suchanfrage mit mehreren IDs-Elementen

Werden in einer Anfrage mehrere IDs-Elemente kombiniert, werden die entsprechenden Nachrichten zusammengeschlossen. Sämtliche IDs-Elemente werden einzeln behandelt und eine Nachricht wird wiedergegeben, wenn sie mindestens einem dieser Elemente entspricht. Daher würden in dem gezeigten Beispiel folgende Nachrichten wiedergegeben

—

alle Nachrichten für das Objekt mit dem ISRS Location Code SKXXX0000010000^***** mit dem Anfangs-Hektometer =0 und dem End-Hektometer ≥ 0 (siehe Fallbeispiel 2);

—

alle Nachrichten für das Objekt mit dem ISRS Location Code SKXXX0000500000^*****, die das Hektometer-Intervall schneiden [11,0, 15,0] (Siehe Fallbeispiel 3);

—

alle Nachrichten für das Objekt mit dem ISRS Location Code SKXXX0000200000^***** mit dem Anfangs-Hektometer ≤ 110,5 und dem End-Hektometer ≥ 110,5 (siehe Fallbeispiel 2);

—

alle Nachrichten für das Objekt mit dem ISRS Location Code SKXXX0000500000^*****, die das Hektometer-Intervall schneiden [220,0, 300,0] (Siehe Fallbeispiel 3).

9.4.

NtS-Nachrichtenservice (Spezifikation für die Umsetzung)

Dieses Kapitel enthält die Spezifikation für die Umsetzung des NtS-Nachrichtenservice, sie leitet sich aus den Überlegungen und Auswahlmöglichkeiten der vorhergehenden Kapitel ab. Der NtS-Nachrichtenservice stellt in den NtS vier Nachrichtentypen bereit:

1.

NtS FTM (wasserstraßen- und verkehrsbezogene Nachricht)

2.

NtS WRM (Wasserstandsmeldung)

3.

NtS ICEM (Eismeldung)

4.

NtS WERM (Wettermeldung)

Mit der Umsetzung des NtS-Nachrichtenservice können alle Nachrichtentypen oder nur eine Auswahl daraus unterstützt werden. Die Bereitstellung mehrerer, einander ergänzender Dienste für einen bestimmten Nachrichtentyp durch einen teilnehmenden Mitgliedstaat ist zulässig.

9.4.1.

Anfrage

Zur Erzielung maximaler Robustheit des Dienstes bei möglichst geringer Komplexität wird für den NtS Web Service keine zusätzliche Sprache für Anfragen verwendet. Stattdessen werden die von WSDL bereitgestellten Konstrukte angewendet. Die Spezifikation der jeweiligen Operationen mit ihren Parametern erfolgt vollständig in der WSDL-Spezifikation. Im Fall des NtS-Nachrichtenservice wird eine einzige Operation definiert. Die für den Betreff spezifischen Filterkriterien werden dem NtS-Standard entnommen, aber hinsichtlich der Multiplizität der Parameter erweitert.

—

Nachrichtentyp (obligatorisch; eine von „FTM” , „WRM” , „ICEM” , „WERM” )

—

besondere Wasserstraßenabschnitte oder Teile derselben, oder besondere Objekte (optional; Beschreibung durch einzelne ISRS Location Codes und/oder Paare von ISRS Location Codes)

—

Gültigkeitszeitraum (optional; Anfangs- und Enddatum)

—

Datum der Herausgabe der Nachricht (optional; einzelne Daten und/oder Datumsintervalle)

Der Dienst gibt als Antwort nur Nachrichten wieder, die den angegebenen Kriterien entsprechen. Seitenabrufmechanismus Zur Steuerung der Datenmenge unterstützt die Anwendung einen Seitenabrufmechanismus Der Parameter für Seitenabrufe wird durch einen komplexen Parametertyp mit folgenden Elementen definiert:

—

offset: laufende Nummer der ersten wiedergegebenen Nachricht (integer ≥ 0)

—

limit: Nachrichtenhöchstzahl (integer ≥ 0)

—

total count: Flag, wenn die Gesamtzahl der Nachrichten wiedergegeben werden soll (Wert Boolean)

Der komplexe Seitenabrufparameter ist optional; ist er jedoch vorhanden, müssen alle enthaltenen Elemente angegeben werden. Der Seitenabrufmechanismus funktioniert dann wie folgt: Die Gesamtzahl der Nachrichten überschreitet den Wert des Parameters limit nicht, mit der Ausnahme, dass der Wert „0” „kein Limit” bedeutet. In der Antwort werden so viele Nachrichten übersprungen, wie im Parameter offset definiert wurden. Zur Bereitstellung dieses Mechanismus muss der Dienst eine vorübergehend stabile (ansonsten aber beliebige) Sequenz der Nachrichten beobachten, z. B. zwischen zwei Aktualisierungen von Nachrichtendaten zum Basisdatensatz des web service. Das heißt, dass zwei aufeinanderfolgende, identische Abrufe die gleichen Nachrichten in der gleichen Reihenfolge ergeben müssen. Der Parameter totalcCount bestimmt, ob in der Antwort die Gesamtzahl der den betreff-spezifischen Kriterien entsprechenden Nachrichten übermittelt werden soll. Gewöhnlich sollte es ausreichen, diese Information mit der ersten Antwort anzufordern, sie aber in allen folgenden Antworten wegzulassen. Dies sollte zu einer besseren Leistung des web service führen. Der Seitenabrufmechanismus bietet ein Mittel, Nachrichten „seitenweise” nacheinander abzufragen. Damit der Seitenabrufmechanismus ordnungsgemäß funktionieren kann, müssen in jedem Abruf die gleichen betreff-spezifischen Parameter übermittelt werden.

9.4.2.

Antwort

Bei einer erfolgreichen Anfrage enthält die Antwort des NtS Web Service diejenigen NtS-Nachrichten, die den Anfrageparametern entsprechen. Die NtS-Nachrichten müssen mit dem NtS-Schema konform sein und können anhand dieses Schemas validiert werden. Da der Nachrichtentyp ein obligatorischer Parameter für Anfragen ist, kann jede Antwort nur NtS-Nachrichten enthalten, die dem angegebenen Nachrichtentyp entsprechen; also FTM, WRM, ICEM bzw. WERM. Entdeckt der Webdienst bei der Verarbeitung der Anfrage Fehler, kann er als Antwort eine beliebige Anzahl an Fehlermeldungen senden, wobei er die im folgenden Unterkapitel aufgeführten Fehlercodes verwendet. Eine Antwort eines NtS Web Service kann gleichzeitig NtS-Nachrichten und Fehlermeldungen enthalten. Optionale Seitenabrufinformationen werden nur wiedergegeben, wenn die Anfrage Seitenabrufparameter enthielt. In einem solchen Fall sind der Versatz (Offset) und die Zahl der enthaltenen Nachrichten obligatorisch, während die Gesamtzahl (total count) nur vorhanden sein muss, wenn sie angefragt wurde. Hinweis: Es wird davon ausgegangen, dass die Kommunikation zwischen dem web service und dem Nutzer technisch stabil eingerichtet ist, d. h., der Webdienst empfängt die Anfrage und der Nutzer die entsprechende Antwort. Technische Fehler wie der Ausfall der Internetverbindung oder die Unzugänglichkeit des web service aufgrund von Wartungsarbeiten oder Zusammenbruch werden hier nicht berücksichtigt. An dieser Stelle werden nur Fehlersituationen berücksichtigt, die aus dem Blickwinkel des Nutzers „hinter” der Ebene des web service eintreten. Fehlermeldungen Die Fehlercodes für erwartete Fehlersituationen sowie die Erklärungen dazu sind der folgenden Tabelle zu entnehmen. Die Antworten enthalten nur den Fehlercode, dies ist das übliche Verfahren im XML-Schema der NtS.

Fehlercodes für den NtS-Nachrichtenservice

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.

Erstellung von Diensten und Kunden

Wird der Ansatz „der Vertrag zuerst” konsequent beachtet, d. h., werden ein Vertrag oder mehrere Verträge mit vollständigen Beschreibungen der Schnittstellen in Form von WSDL-Dokumenten angegeben, kann die Umsetzung des Dienstes bzw. der Dienste sowie die Implementierung eines entsprechenden Kunden mittels geeigneter Software-Tools automatisch erfolgen. Im Idealfall müssen am erzeugten Quellcode keine manuellen Änderungen vorgenommen werden. In den meisten Fällen sind jedoch mehrere Durchläufe erforderlich, bis die WSDL-Spezifikation die genauen Anforderungen eines solchen Tools erfüllt. Gewöhnlich stellt das Tool individuelle Anforderungen an die Verwendung des WSDL-Standards, damit es reibungslos funktionieren kann. Daraus folgt, dass Änderungen an der WSDL-Spezifikation erforderlich sein können, obgleich die WSDL-Spezifikation zunächst eine nach dem WSDL-Standard gültige Spezifikation war. Wird die WSDL-Spezifikation des web service nach der Generierung des Dienstes oder Kunden geändert, kann je nach den vorgenommenen Änderungen ein neuer Generierungsvorgang erforderlich sein.

Glossar

Begriff	Bedeutung
ID	Identifikation
ISRS Location Code	Ortscode des internationalen Schiffsmeldestandards (International Ship Reporting Standard)
NtS	Nachrichten für die Binnenschifffahrt (Notices to Skippers)
RIS	Binnenschifffahrtsinformationsdienste (River Information Services)
SOAP	Simple Object Access Protocol; üblicherweise für Webdienste verwendetes Netzprotokoll
UDDI	Universal Description, Discovery and Integration; Standard für Registerdienste im Kontext von Webdiensten
UN	Vereinte Nationen
URL	Uniform Resource Locator; Ort einer Netzressource, üblicherweise für Internetadressen verwendet
WGS 84	Weltweites geodätisches System von 1984
WS	Web Service; Dienst, der seine Schnittstellen im Internet zur Verfügung stellt und durch die Internetkommunikation genutzt wird
WSDL	Web Services Description Language; Standard für die Spezifikation von Webdiensten
WS-I	Web Services Interoperability Organisation; industrielles Konsortium mit der Zielsetzung, die Kompatibilität von Webdiensten zu fördern
XML	EXtensible Markup Language (Erweiterbare Auszeichnungssprache); Metasprache für die strukturierte, plattformunabhängige Darstellung von Daten
XSD	XML Schema Definition (Definition des XML-Schemas); Standard zur Spezifizierung der Struktur von XML-Dokumenten