Die Kommission der Europäischen Gemeinschaften -

gestützt auf den Vertrag zur Gründung der Europäischen Gemeinschaft,

gestützt auf die Richtlinie 2005/44/EG des Europäischen Parlaments und des Rates vom 7. September 2005 über harmonisierte Binnenschifffahrtsinformationsdienste (RIS) auf den Binnenwasserstraßen der Gemeinschaft ¹, insbesondere auf Artikel 5,

in Erwägung nachstehender Gründe:

(1) Gemäß Artikel 1 der Richtlinie 2005/44/EG soll eine harmonisierte, interoperable und offene Entwicklung und Einrichtung der Binnenschifffahrtsinformationsdienste (RIS) gewährleistet werden.

(2) Gemäß Artikel 5 der Richtlinie 2005/44/EG sind technische Spezifikationen für die Nachrichten für die Binnenschifffahrt festzulegen.

(3) Diese technischen Spezifikationen müssen sich auf die technischen Vorgaben des Anhangs II der Richtlinie stützen.

(4) Gemäß Artikel 1 Absatz 2 der Richtlinie 2005/44/EG sind bei den technischen Spezifikationen die Arbeiten anerkannter internationaler Organisationen gebührend zu berücksichtigen.

(5) Zu berücksichtigen sind ferner die Arbeiten der Expertengruppe "Nachrichten für die Binnenschifffahrt", der Vertreter der zuständigen Behörden für die Umsetzung der Nachrichten für die Binnenschifffahrt und offizielle Mitglieder anderer Regierungsstellen sowie Beobachter aus der Industrie angehören.

(6) Die technischen Spezifikationen, die Gegenstand dieser Verordnung sind, entsprechen dem derzeitigen Stand der Technik. Erfahrungen bei der Anwendung der Richtlinie 2005/44/EG sowie künftige Fortschritte der Technik können es notwendig machen, die technischen Spezifikationen gemäß Artikel 5 Absatz 2 der Richtlinie 2005/44/EG anzupassen. Bei Änderungen der technischen Spezifikationen sind die Arbeiten der Expertengruppe "Nachrichten für die Binnenschifffahrt" angemessen zu berücksichtigen.

(7) Der Entwurf der technischen Spezifikationen wurde von dem durch Artikel 11 der Richtlinie 2005/44/EG eingerichteten Ausschuss geprüft.

(8) Die in dieser Entscheidung vorgesehenen Maßnahmen entsprechen der Stellungnahme des in Artikel 11 der Richtlinie 2005/44/EG genannten Ausschusses.

- hat folgende Verordnung erlassen:

Artikel 1

In dieser Verordnung werden die technischen Spezifikationen für Nachrichten für die Binnenschifffahrt festgelegt. Die technischen Spezifikationen sind im Anhang zu dieser Verordnung aufgeführt.

Artikel 2

Diese Verordnung tritt am Tag nach ihrer Veröffentlichung im Amtsblatt der Europäischen Union in Kraft.

Diese Verordnung ist in allen ihren Teilen verbindlich und gilt unmittelbar in jedem Mitgliedstaat.

Brüssel, den 22. März 2007

.

1. Allgemeine Bestimmungen

1.1. Begriffsbestimmungen

Unter Wasserstraßeninformationsdiensten sind geografische, hydrologische und administrative Angaben zu verstehen, die von den Schiffsführern und Flottenmanagern benötigt werden, um eine Reise zu planen, auszuführen und zu überwachen. Die im vorliegenden Standard verwendeten Begriffe "Schiffsführer" (boatmaster) und "Schiffsführer" (skipper) sind gleichbedeutend mit dem in der Verordnung (EG) Nr. 414/2007 der Kommission ¹ über Leitlinien für Binnenschifffahrtsinformationsdienste verwendeten Begriff "Schiffsführer" (ship master); der Begriff "Flottenmanager" (fleet manager) ist in der Verordnung (EG) Nr. 415/2007 der Kommission ² definiert.

FIS liefern dynamische Informationen (wie Wasserstände, Wasserstandsvorhersagen) sowie statische Informationen (wie die Betriebszeiten von Schleusen und Brücken) zu Nutzung und Status der Binnenwasserstraßen-Infrastruktur und unterstützen damit taktische und strategische Navigationsentscheidungen.

Zu den traditionellen Mitteln der Bereitstellung von FIS zählen visuelle Schifffahrtszeichen, Nachrichten für die Schifffahrt auf Papier sowie über Rundfunk und feste Telefone auf Schleusen. Das Mobiltelefon hat neue Möglichkeiten der Sprach- und Datenkommunikation geschaffen; Mobilfunknetze sind jedoch nicht überall und jederzeit verfügbar. Maßgeschneiderte FIS für Wasserstraßen können durch Sprechfunk auf Binnenschifffahrtsstraßen, Internetdienste oder elektronische Navigationskartendienste wie das Elektronischen Kartendarstellungs- und Informationssystem für die Binnenschifffahrt (Inland Electronic Chart Display and Information System - Inland ECDIS) mit der elektronischen Navigationskarte (Electronic Navigational Chart - ENC) bereitgestellt werden.

1.2 Hauptfunktionen und Leistungsmerkmale der Nachrichten für die Binnenschifffahrt (Notices to Skippers - NtS)

Die vorliegende technische Spezifikation für NtS enthält Vorschriften für die Datenübertragung von Wasserstraßeninformationen über das Internet.

NtS sollen:

1. Informationen über den Wasserstraßenzustand, den Verkehr, das Wetter, die Wasserstände und das Eis für die Wasserstraßeninformationsdienste liefern;
2. eine automatische Übersetzung der wichtigsten Inhalte der Nachrichten unter Verwendung eines auf Codelisten basierenden Standardvokabulars liefern (siehe die NtS Reference Tables in Anlage E);
3. in einer standardisierten Struktur von Datensätzen bereitgestellt werden, um die Integration der Nachrichten in Reiseplanungssysteme zu erleichtern;
4. mit der Datenstruktur des RIS Index und des Inland ECDIS kompatibel sein, um die Einbindung der NtS in das Inland ECDIS gemäß der Richtlinie 2005/44/EG des Europäischen Parlaments und des Rates vom 7. September 2005 über harmonisierte Binnenschifffahrtsinformationsdienste (RIS) auf den Binnenwasserstraßen der Gemeinschaft zu erleichtern.

Die technischen Spezifikationen für NtS erleichtern den Datenaustausch zwischen den NtS-Systemen verschiedener Länder ebenso wie den Austausch mit anderen Anwendungen, die NtS-Daten nutzen, darunter auch dem Inland ECDIS.

Einige der in NtS-Nachrichten enthaltenen Informationen lassen sich standardisieren, andere nicht.

Der standardisierte Teil sollte alle Informationen abdecken, die

1. für die Sicherheit der Binnenschifffahrt wichtig sind (z.B.: gesunkenes Sportboot auf der rechten Fahrwasserseite der Donau, Strom-km 2010);
2. für die Reiseplanung benötigt werden, unter anderem die Sperrung von Schleusen und verringerte Durchfahrtshöhen.

Ergänzende Informationen, die weder für die Sicherheit noch für die Reiseplanung relevant sind, unter anderem die Ursache für eine Schleusensperrung, können als freier Text ohne automatische Übersetzung angegeben werden. Die Verwendung von freiem Text ist auf ein Minimum zu beschränken.

2. Übermittlung von Nachrichten für die Binnenschifffahrt

Die Mitgliedstaaten haben sicherzustellen, dass die NtS-Nachrichten gemäß den technischen Spezifikationen im vorliegenden Anhang und dessen Anlagen online und über einen standardisierten NtS Web Service zugänglich sind. Die Spezifikation für den standardisierten NtS Web Service ist in Anlage D in Form einer "Web Service Description Language" (WSDL) enthalten.

Die standardisierten NtS Web Services ermöglichen dem Nutzer die Auswahl von Nachrichten auf der Grundlage mindestens eines der folgenden Kriterien:

3. spezifischer Wasserstraßenabschnitt;
4. spezifischer durch die Strom-km des Anfangs- und Endpunkts definierten Teil einer Wasserstraße;
5. Gültigkeitsdauer der Nachricht (Anfangs- und Enddatum des Zeitraums der Gültigkeit);
6. Herausgabedatum der Nachricht (Tag und Uhrzeit der Herausgabe).

NtS-Nachrichten, die den in diesem Anhang genannten Normen entsprechen, können unter anderem durch folgende Instrumente übermittelt werden:

1. mobile Anwendungen (Apps);
2. E-Mail-Dienste.

Der Datenaustausch zwischen den in verschiedenen Ländern betriebenen NtS-Systemen ist möglich. Alle Systeme, die mit den im Anhang zu dieser Verordnung beschriebenen Normen arbeiten, können NtS aus anderen Systemen in ihre eigenen Dienste einbinden, sofern der Inhalt der Nachricht nicht verändert wird. Die Nutzer müssen informiert werden, wenn die Verbindung zur Quelle integrierter NtS unterbrochen ist oder nicht zur Verfügung steht.

3. NTS-Nachrichtentypen

NtS-Nachrichten sind unentbehrliche Nachrichten, die möglichst weitgehend standardisiert sind.

Es gibt vier NtS-Nachrichtentypen, nämlich:

1. wasserstraßen- und verkehrsbezogene Nachrichten;
2. Wasserstandsmeldungen;
3. Eismeldungen;
4. Wettermeldungen.

4. NTS-Struktur und Codierung von NTS-Nachrichten

In diesem Kapitel werden die Struktur und Codierung von standardisierten elektronischen NtS-Nachrichten beschrieben.

Eine NtS-Nachricht ist eine strukturierte Nachricht, in der möglichst weitgehend standardisierte Elemente genutzt werden. Die Verwendung von freiem Text in den Datenelementen ist auf ein Minimum zu beschränken.

Die Definition des Schemas für die standardisierte erweiterte Auszeichnungssprache (XML) für NtS, die im vorliegenden Standard als XSD bezeichnet wird, enthält die standardisierten Codewerte; die möglichen Formate sind Anlage C zu entnehmen.

Die standardisierten Codewerte und die XML-Tags, ihre Bedeutung und ihre Übersetzung sind den NtS Reference Tables in Anlage E zu entnehmen; sie stehen außerdem in elektronischer Form in dem von der Europäischen Kommission verwalteten Europäischen Referenzdatenverwaltungssystem (European Reference Data Management System - ERDMS) zur Verfügung.

4.1. Allgemeine Struktur

Eine NtS-Nachricht setzt sich aus den folgenden Abschnitten zusammen:

1. Identifikationsabschnitt;
2. Definition des/der jeweiligen Objekts/Objekte oder Wasserstraßenabschnitts/-abschnitte, auf den oder die sich die Nachricht bezieht;
3. Einschränkung(en) für eine wasserstraßen- und verkehrsbezogene Nachricht, Messung(en) für eine Wasserstandsmeldung, Eisverhältnisse für eine Eismeldung oder Wetterbericht(e) für eine Wettermeldung.

Abbildung 1 Struktur der NtS-Nachricht

4.1.1. Identifikationsabschnitt

Jede Nachricht muss einen Identifikationsabschnitt enthalten. Der Identifikationsabschnitt enthält allgemeine Angaben zum Herausgeber und zum Datum der Herausgabe der Nachricht.

4.1.2. Wasserstraßen- und verkehrsbezogene Nachricht

Wasserstraßen- und verkehrsbezogene Nachrichten enthalten Informationen über einen oder mehrere Wasserstraßenabschnitt(e) oder ein bzw. mehrere Objekt(e) und dienen zur Angabe von Einschränkungen zu folgenden Zwecken:

1. "Achtung!": sicherheitsrelevant. Die Warnmeldung muss mindestens eine Einschränkung enthalten, die eine unmittelbare, konkrete Gefährdung von Personen, Wasserfahrzeugen oder Einrichtungen mit sich bringt, beispielsweise Schweißarbeiten auf einer Brücke mit Funkenflug, von einer Brücke herunterhängender Kontroll- bzw. Arbeitskäfig, Hindernis im Fahrwasser;
2. "Mitteilung": relevant für die Reiseplanung bzw. die Sicherheit. Eine Mitteilung kann Einschränkungen beinhalten, beispielsweise die Sperrung einer Schleusenkammer wegen Wartungsarbeiten, Baggerarbeiten im Fahrwasser;
3. "Informationsservice": allgemeine Informationen, die nicht in einem unmittelbaren Zusammenhang mit der Reiseplanung oder der Sicherheit stehen. Der Informationsservice darf keine besonderen Einschränkungen beinhalten und hat folglich keine unmittelbare Relevanz für die Reiseplanung oder die Sicherheit. Informationen dieser Art könnten allgemeine Angaben wie örtliche Verkehrsregeln oder ein Update des Inland ECDIS umfassen.

4.1.3. Wasserstandsmeldung

Der wasserstandsbezogene Abschnitt enthält Werte oder Vorhersagen für:

1. den Wasserstand,
2. die minimale Tiefe,
3. die Durchfahrtshöhe,
4. die Wehrstellung,
5. den Abfluss,
6. das Regime.

Üblicherweise werden Wasserstandsinformationen automatisch auf der Grundlage von Daten, die von Sensoren (wie Pegeln), Systemen (wie Wasserstandsmodellen) oder der Infrastruktur (z.B. Wehrstellung) übermittelt wurden, erstellt und herausgegeben. Es kann unterschiedliche Auslöser für die Herausgabe geben, beispielsweise eine Herausgabe in regelmäßigen Abständen oder bei Erreichen eines bestimmten Werts.

4.1.4. Eismeldung

Eine Eismeldung enthält Informationen über die tatsächlichen oder vorhergesagten Eisverhältnisse in einem oder mehreren Wasserstraßenabschnitt(en). Eismeldungen werden gewöhnlich vom zuständigen Personal auf der Grundlage von örtlichen Beobachtungen und fachlicher Bewertung erzeugt.

4.1.5. Wettermeldung

Eine Wettermeldung enthält Informationen über (gefährliche) Witterungsbedingungen für die Binnenschifffahrt.

Zur Erleichterung der Weiterleitung von hydrologischen und meteorologischen Informationen aus Hydro-Meteo-Netzen an Schiffsführer können Wettermeldungen herausgegeben werden.

4.2. Erklärung von XML-Tags und Codewerten in den NtS Reference Tables

Die Bedeutung der verschiedenen Elemente in der Definition des XML-Schemas für NtS (XSD) wird in den NtS Reference Tables in Anlage E beschrieben. Struktur, Format und die möglichen Werte aller XML-Elemente werden in der NtS XSD in Anlage C beschrieben.

7. Breiten- und Längenkoordinaten werden nach dem World Geodetic System (weltweites geodätisches System von 1984) codiert und in Grad und Minuten mit zumindest drei, vorzugsweise aber vier Dezimalstellen angegeben ([d]d mm.mmm[m] N, [d][d]d mm.mmm[m] E).
8. Dezimalzahlen in numerischen Feldern werden mit einem "." (Dezimalpunkt) angegeben. Es wird kein Tausender-Trennzeichen benutzt.
9. In NtS-Nachrichten dürfen für die in der XML-Nachricht enthaltenen Werte nur die folgenden Maßeinheiten benutzt werden: cm, m3/s, h, km/h und kW, m/s (Wind), mm/h (Regen) und Grad Celsius. Nationale Anwendungen können die Maßeinheiten für eine benutzerfreundliche Anzeige umrechnen.

4.3. Identifikation von Wasserstraßenabschnitten und Objekten in NtS-Nachrichten

Zur Erfüllung der in Artikel 4 Absatz 3 Buchstabe a der Richtlinie 2005/44/EG genannten Mindestanforderungen an Daten für die Übermittlung von Informationen über Objekte mit Relevanz für die Binnenschifffahrt muss im Objektabschnitt der ISRS Location Code benutzt werden. Der ISRS Location Code dient zur eindeutigen Identifikation von Objekten und Wasserstraßenabschnitten; darüber hinaus wird er zur Sicherstellung dialogfähiger RIS-Systeme und -Dienste genutzt (beispielsweise zur Kombination von Informationen über die Infrastruktur aus dem RIS Index, dem Inland ECDIS und NtS zum Zweck der Reiseplanung).

Bei dem ISRS Location Code handelt es sich um einen 20-stelligen alphanumerischen Code, der zur Festlegung einer eindeutigen, standardisierten Beziehung zwischen Objekten in Binnenschifffahrtsinformationsdiensten dient. Er besteht aus folgenden obligatorischen Datenelementen, die in vier Informationsblöcken angeordnet sind:

1. Block 1: UN/LOCODE (fünf Buchstaben, alphanumerisch), mit
   • Country code (zweistellig, alphanumerisch) ³ und
   • Location code (dreistellig, alphanumerisch, "XXX", wenn nicht verfügbar)
2. Block 2: Fairway section code (fünfstellig, alphanumerisch, von der nationalen Behörde festzulegen)
3. Block 3: Object Reference Code (fünfstellig, alphanumerisch, "XXXXX", wenn nicht verfügbar)
4. Block 4: Fairway section hectometre (fünfstellig, numerisch, Hektometer am Mittelpunkt des Gebiets oder "00000", wenn nicht verfügbar).

Die ISRS Location Codes und die Referenzdaten von Objekten werden von den Mitgliedstaaten im RIS Index gepflegt und im Einklang mit den auf der ERDMS-Website veröffentlichten Datenpflegeverfahren für den RIS Index an das von der Europäischen Kommission verwaltete ERDMS übermittelt.

4.4. Regeln für die Codierung von NtS-Nachrichten

NtS-Nachrichten sind im Einklang mit dem NtS Encoding Guide für Editoren ( Anlage A) und dem NtS Encoding Guide für Anwendungsentwickler ( Anlage B) zu codieren.

.

Abkürzungen

1. Hintergrund, Aufbau und Zweck von NtS Encoding Guides

Der NtS-Standard wird fortlaufend verbessert. Die Freigabe des NtS Web Service bedeutete durch die Erleichterung des Austausches von NtS-Nachrichten zwischen Behörden einerseits und Behörden und NtS-Nutzern andererseits einen großen Schritt nach vorn.

Zur Erleichterung der harmonisierten Codierung von NtS-Nachrichten auf nationaler und internationaler Ebene wurden zwei Unterlagen erstellt, nämlich der NtS Encoding Guide für Editoren und der NtS Encoding Guide für Anwendungsentwickler. Diese Leitfäden gelten für die NtS XSD 4.0 und den NtS Web Service WSDL 2.0.4.0.

In Anbetracht der zunehmenden Nutzung des NtS Web Service sollen 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.

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.

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. Im Leitfaden wird erläutert, wann die vier Typen der NtS-Nachrichten anzuwenden sind; außerdem enthält er Ausfüllanweisungen und Codes, die bei bestimmten Ereignissen zu verwenden sind. Der NtS Encoding Guide für Editoren ist Bestandteil der vorliegenden Anlage A.

Der NtS Encoding Guide für Anwendungsentwickler enthält Leitlinien für die Entwicklung und Implementierung von NtS-Anwendungen und erläutert deren Logik, Prozesse und automatische bzw. vorgegebene Werte. Der NtS Encoding Guide für Anwendungsentwickler ist Bestandteil der Anlage B zu dieser Verordnung.

2. Auswahl des NtS-Nachrichtentyps

• FTM: Wählen Sie diesen Typ, wenn Sie eine "wasserstraßen- und verkehrsbezogene Nachricht" für Wasserstraßen oder Objekte im Fahrwasser erstellen möchten. [Gehe zu Kapitel 3]
• WRM: Wählen Sie diesen Typ, wenn Sie eine "Wasserstandsmeldung" erstellen möchten, mit der die Übermittlung von Informationen über aktuelle und vorhergesagte Wasserstände sowie anderer Angaben ermöglicht wird. Die Wasserstandsmeldung enthält Informationen für ein Objekt oder einen 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.
• ICEM: Wählen Sie diesen Typ, wenn Sie eine "Eismeldung" erstellen möchten. Die Eismeldung enthält Informationen über die Eisverhältnisse in einem Wasserstraßenabschnitt, der durch die ISRS Location Codes für seinen Anfang und Ende definiert wird.
• WERM: Wählen Sie diesen Typ, wenn Sie eine "Wettermeldung" erstellen möchten, mit der die Übermittlung von Informationen über aktuelle und vorhergesagte Wetterlagen auf einem durch die ISRS Location Codes für seinen Anfang und Ende definierten Wasserstraßenabschnitt ermöglicht wird.

3. Grundüberlegungen zu FTM, Schritte zur Herausgabe einer FTM

Genaue Angaben zu den zu verwendenden Codes sind Kapitel 4 zu entnehmen. Die ab Punkt 3.3 aufgeführten Überlegungen folgen nicht unbedingt der Eingabereihenfolge eines FTM-Editionstools.

3.1. Besteht Bedarf, mittels einer NtS-FTM nach dem NtS-Standard Informationen herauszugeben? Alle für die Sicherheit und die Reiseplanung relevanten Informationen müssen mittels NtS-Nachrichten herausgegeben werden. Informationen ohne Relevanz für die Sicherheit und die Reiseplanung können herausgegeben werden. Jedes Thema, jedes Ereignis und jede Veranstaltung muss in einer eigenen Nachricht veröffentlicht werden.

3.2. Besteht bereits eine gültige FTM im Zusammenhang mit der aktuellen Lage (hinsichtlich des Inhalts sowie des Gültigkeitszeitraums)?

3.2.1. Ja:

Die bereits bestehende FTM muss aktualisiert werden. Die entsprechende, bereits herausgegebene Nachricht wird ausgewählt und im FTM-Editionstool aktualisiert. Eine abgelaufene FTM kann nicht mehr aktualisiert werden.

3.2.2. Nein:

Es muss eine neue FTM zusammengestellt werden. Falls ein ähnliches Ereignis bereits in einer bestehenden FTM codiert wurde, kann diese als Entwurf für die Erstellung einer neuen FTM verwendet werden (sofern diese Funktion zur Verfügung steht), oder es kann eine Vorlage benutzt werden (sofern diese Funktion zur Verfügung steht).

3.3. Die geografische Reichweite der Geltung muss festgelegt werden.

3.3.1. Bezieht sich die FTM auf einen bestimmten Abschnitt einer Wasserstraße, ist der durch seinen Anfangs- und Endpunkt definierte Abschnitt in die Nachricht aufzunehmen. Gilt der Inhalt der Nachricht für mehrere Abschnitte derselben Wasserstraße oder für verschiedene Wasserstraßen, können alle in einer FTM aufgeführt werden.

3.3.2. Bezieht sich die FTM auf ein bestimmtes Objekt (z.B. eine Brücke, eine Schleuse usw.) in der Wasserstraße, ist das entsprechende Objekt aus der Liste verfügbarer Objekte auszuwählen (sofern eine Auswahloption zur Verfügung steht). Die Definition eines Wasserstraßenabschnitts in der Nachricht ist nicht notwendig. Falls die FTM für mehre Objekte gilt, können sie alle in eine FTM aufgenommen werden.

3.3.3. Die Kombination von objekt- und wasserstraßenbezogenen Informationen innerhalb einer Nachricht ist möglich, solange sich die Informationen auf eine bestimmte Ursache bzw. ein bestimmtes Ereignis beziehen (gleicher Code für Betreff und Grund).

3.3.4. Die Koordinaten unterliegen zwar Bedingungen, sind aber zur Unterstützung der Darstellung auf Karten zu übermitteln (häufig werden die Koordinaten automatisch von der NtS-Anwendung bereitgestellt).

3.4. Der Inhalt der FTM ist einzugeben.

Alle Informationen, die sich mithilfe der NtS Reference Tables ausdrücken lassen, müssen in den standardisierten Nachrichtenfeldern codiert werden. Nur ergänzende Informationen (die sich nicht anders codieren lassen) sind in den Feldern für freien Text zu nennen.

3.5. Sofern zutreffend ist/sind hinsichtlich der Schiffstypen und betroffenen Richtungen die Zielgruppe(n) einzugeben.

3.5.1. Gilt die Nachricht für alle Wasserfahrzeuge (alle Schiffstypen) in allen Richtungen, wird die Zielgruppe ausgelassen, damit nur wesentliche Informationen codiert werden. Richtet sich die Nachricht/Einschränkung an eine bestimmte Zielgruppe oder Fahrtrichtung, sind die entsprechenden Codes zu wählen.

3.5.2. Gilt die gesamte Nachricht für bestimmte Zielgruppen, sind die Angaben zur Zielgruppe im allgemeinen Teil der FTM zu übermitteln (und nicht in dem/den Abschnitt(en) mit der oder den Einschränkung(en) zu wiederholen).

3.5.3. Falls für unterschiedliche Einschränkungen unterschiedliche Zielgruppen zutreffen, sind die Angaben zur Zielgruppe bei den jeweiligen Einschränkungen zu nennen (und sind nicht im allgemeinen Teil zu wiederholen).

3.5.4. Gewähren die zuständigen Behörden einzelnen Schiffen oder dem örtlichen Verkehr eine Befreiung von Einschränkungen (z.B. an einer Veranstaltung teilnehmende Schiffe, für die eine allgemeine Sperrung gilt, örtlicher Fährverkehr in gesperrten Gebieten), müssen diese Befreiungen bei der Codierung der Zielgruppe(n) nicht berücksichtigt werden. Derartige Informationen können im Freitextfeld für ergänzende Informationen eingegeben werden.

3.6. Gegebenenfalls ist der Kommunikationsabschnitt auszufüllen.

Stehen über eine besondere Quelle ergänzende Informationen zur Verfügung, sollten sie in diesem Abschnitt angegeben werden. Besteht eine zusätzliche Verpflichtung zur Berichterstattung über ein bestimmtes Medium, ist dies in diesem Abschnitt anzugeben.

3.7. Gegebenenfalls ist der Abschnitt für Einschränkungen auszufüllen.

Falls Einschränkungen gelten, muss der Abschnitt für Einschränkungen ausgefüllt werden. Sind mit Einschränkungen verbundene Werte bekannt, müssen sie genannt werden. Die Übermittlung von Werten für Schiffsabmessungen, Geschwindigkeitsbegrenzungen und für den verfügbaren Manövrierraum ist obligatorisch.

Bei allen Einschränkungen sind die Zeiträume für die Einschränkungen einzugeben, damit in Reiseplanungsanwendungen korrekte Berechnungen ermöglicht werden (zur Vereinfachung der Arbeit ist in der NtS-Anwendung eventuell eine Funktion vorgesehen, mit der Einschränkungszeiträume kopiert werden können oder in der für einen Einschränkungszeitraum mehrere Einschränkungen ausgewählt werden können).

3.8. Das Anfangsdatum der Gültigkeit der Nachricht muss festgelegt werden.

Falls das Enddatum der Gültigkeit einer Nachricht bereits bekannt ist, wird es ebenfalls festgelegt. Das Enddatum der Gültigkeit darf nicht vor dem aktuellen Datum liegen.

Bitte beachten Sie, dass Anwendungen die Angaben zum Gültigkeitszeitraum für die Auswahl der Nachrichten, die Nutzern für einen gewünschten Zeitraum angezeigt werden sollen, nutzen.

Wird die Nachricht aufgehoben

1. und hat der Gültigkeitszeitraum noch nicht begonnen, müssen das Anfangs- und das Enddatum auf das Datum der Aufhebung festgelegt werden.
2. und hat der Gültigkeitszeitraum bereits begonnen, sind die neuen Enddaten für alle Einschränkungen auf einen Tag in der Vergangenheit zu setzen und das Ende der Gültigkeit ist auf das Datum der Aufhebung festzulegen.

3.9. Die Nachricht kann herausgegeben werden.

4. Erklärung der Codes für FTM

4.1. Subject_code:

Festlegung der Verwendung von Betreff-Codes:

• "Achtung!": Sicherheitsrelevant. Die Warnmeldung muss mindestens eine Einschränkung enthalten, die eine unmittelbare, konkrete Gefährdung von Personen, Wasserfahrzeugen oder Einrichtungen mit sich bringt, beispielsweise Schweißarbeiten auf einer Brücke mit Funkenflug, von einer Brücke herunterhängender Kontroll- bzw. Arbeitskäfig, Hindernis im Fahrwasser;
• "Mitteilung": relevant für die Reiseplanung bzw. die Sicherheit. Die Mitteilung kann Einschränkungen beinhalten, beispielsweise die Sperrung einer Schleusenkammer wegen Wartungsarbeiten, Baggerarbeiten im Fahrwasser, zusätzlich zu den nationalen Rechtsvorschriften geltende Verkehrsregeln;
• "Informationsservice": allgemeine Informationen, die nicht in einem unmittelbaren Zusammenhang mit der Reiseplanung oder der Sicherheit stehen. Der Informationsservice darf keine besonderen Einschränkungen beinhalten und hat folglich keine unmittelbare Relevanz für die Reiseplanung oder die Sicherheit. Informationen dieser Art könnten allgemeine Angaben wie örtliche Verkehrsregeln oder ein Update des Inland ECDIS umfassen. Der Gültigkeitszeitraum wird zur Angabe des Zeitraums verwendet, in dem die Nachricht des Informationsservice den Nutzern angezeigt wird, nicht für den Gültigkeitszeitraum der übermittelten Informationen (z.B. einen Monat oder entsprechend der Festlegung in nationalen Verfahrensanweisungen).
• "Nachricht aufgehoben"

  Der Betreff-Code "Nachricht aufgehoben" wird nur verwendet, wenn:

  • das aktuelle Datum vor dem Datum des Beginns der Gültigkeit liegt. In diesem Fall kann nur der Inhalt des Feldes "Ergänzender Text in Originalsprache" geändert werden, der weitere Inhalt der Nachricht muss unverändert stehen bleiben. In diesem Fall wird "Nachricht aufgehoben" dazu genutzt, eine Nachricht zurückzunehmen, bevor sie gültig wird. Das bedeutet, dass "Nachricht aufgehoben" einerseits für Nachrichten verwendet wird, die das Datum für den Beginn ihrer Gültigkeit noch nicht erreicht haben, und andererseits für geplante Maßnahmen, die nicht durchgeführt werden (z.B. waren Ausbaggerungsarbeiten geplant, die aufgrund eines hohen Wasserstandes nicht beginnen können).
  • der Gültigkeitszeitraum bereits begonnen hat und die neuen Enddaten für alle Einschränkungen auf einen Tag in der Vergangenheit gesetzt werden. Das Ende der Gültigkeit ist auf das Datum der Aufhebung festzulegen.

  In diesem Fall enden Maßnahmen/Ereignisse, bevor der anfänglich festgelegte Gültigkeitszeitraum einer bereits bestehenden FTM endet.

4.2. Reason_code

Der Code für den Grund der Nachricht ist einzutragen, um den Schiffsführern ergänzende Informationen mitzuteilen.

Festlegung der Verwendung von Codes für den Grund der Nachricht:

4.3. Limitation_code:

Definition der Codes für Einschränkungen:

• Sperrung:

  Wenn jede Form der Schifffahrt unmöglich ist:

  • durch eine Schleusenkammer,
  • durch eine Brückenöffnung,
  • durch einen bestimmten Punkt der Wasserstraße,
  • auf einem bestimmten Abschnitt der Wasserstraße.
• Teilweise Sperre:

  Alle Teile der Infrastruktur (z.B. Schleusenkammern, Brückenöffnungen) sind mit eigenen ISRS Location Codes zu versehen. Falls solche Codes noch fehlen, können teilweise Sperren verwendet werden, wenn eine eingeschränkte Schifffahrt möglich ist (z.B. bei einer Schleuse mit zwei parallelen Kammern "einziges verfügbares Objekt im Schleusenbereich")

  • durch eine oder mehrere Schleusenkammern einer Schleuse, wobei jedoch mindestens eine Kammer benutzbar bleibt,
  • durch eine oder mehrere Brückenöffnungen, wobei jedoch mindestens eine Öffnung offen bleibt.
• Betriebssperre:

  ist zu verwenden, wenn eine bewegliche Brücke während einer bestimmten Zeitspanne nicht in Betrieb ist. Diese Zeitspanne sollte innerhalb der normalen Betriebszeit liegen.

  Bei einer Betriebssperre einer beweglichen Brücke ist eine Durchfahrt unter der Brücke möglich. Andernfalls handelt es sich um eine "Sperrung". Eine Betriebssperre einer Schleuse ist als "Sperrung" zu codieren.

• Betrieb geändert:

  Ist zu verwenden, wenn die normalen Betriebszeiten von Objekten (z.B. Schleusen (beweglichen) Brücken) geändert, verlängert oder verkürzt werden.

• Bestehen Einschränkungen bezüglich der zulässigen Abmessungen von Schiffen/Verbänden (die nicht in unmittelbarem Zusammenhang mit der Infrastruktur stehen), ist die Einschränkung mit den folgenden Textelementen zu codieren:
  • Schiffstiefgang,
  • Schiffsbreite,
  • Breite des Verbands,
  • Schiffslänge,
  • Länge des Verbands,
  • Schiffshöhe.

  Sofern verfügbar, ist ein absoluter Wert zu übermitteln.

• Bestehen Einschränkungen bezüglich der verfügbaren Größe eines Objekts oder Wasserstraßenabschnitts, werden die folgende Codes verwendet:
  • Durchfahrtshöhe,
  • verfügbare Länge,
  • verfügbare Breite,
  • verfügbare Tiefe.

  Sofern verfügbar, ist ein absoluter Wert zu übermitteln.

• minimale Tiefe: ist einzusetzen, falls die Tiefe Probleme verursachen könnte (z.B. aufgrund von Versandung). Es ist ein Wert für die absolute Tiefe (bezogen auf einen Referenzwert) oder die Verminderung der Tiefe zu übermitteln. Sofern verfügbar, ist ein absoluter Wert zu übermitteln.
• Verzögerung: ist zu verwenden, wenn an einem Objekt oder einem Wasserstraßenabschnitt zwischen einem bestimmten Anfangs- und einem bestimmten Enddatum eine Behinderung bzw. ein Ereignis von begrenzter Dauer eintritt.

  Die geschätzte Höchstdauer der Behinderung bzw. des Vorfalls ist zu codieren. Das Element "Verzögerung" darf nicht in Fällen verwendet werden, in denen eine von mehreren Schleusenkammern nicht zur Verfügung steht.

• Sind bestimmte Manöver oder Handlungen verboten, sind die jeweiligen Einschränkungen zu codieren. Die folgenden Einschränkungen sind nur zu codieren, wenn sie nicht bereits mittels Navigationszeichen oder Verordnungen, die in der amtlichen Inland ENC codiert sind, angekündigt wurden:
  • Mindestantriebsleistung,
  • Einbahnverkehr,
  • Wendeverbot,
  • Begegnungsverbot,
  • Überholverbot,
  • Anlegeverbot,
  • Festmachverbot,
  • Ankerverbot,
  • Wellenschlag vermeiden,
  • Geschwindigkeitsbegrenzungen,
  • Landgangverbot.

  Sofern verfügbar sind für Geschwindigkeitsbegrenzungen und Mindestantriebsleistungen absolute Werte zu übermitteln.

• besondere Vorsicht: Bezieht sich die FTM (oder ein Teil einer FTM) auf eine Wasserstraße, ist diese Einschränkung zu verwenden, um anzugeben, an welcher Position der Wasserstraße/des Flusses/Kanals/Sees ein Ereignis eintritt.

  Des Weiteren ist diese Angabe in Fällen zu verwenden, in denen eine genaue Beschreibung der Einschränkung nicht möglich ist, sie aber hilfreich oder notwendig ist, um Schiffsführer darauf hinzuweisen, dass sie aufmerksam sein und auf per Funk übermittelte Informationen achten müssen.

• keine Einschränkung: ist nur zu verwenden, wenn ausdrücklich angegeben werden soll, dass in einem bestimmten Zeitraum keine Einschränkungen bestehen.

4.4. Limitation interval_code: Festlegung der Verwendung von interval codes:

• "durchgehend": ist für Einschränkungen zu verwenden, die ohne Unterbrechung ab einem Anfangsdatum/einer Anfangsuhrzeit bis zu einem Enddatum/einer Enduhrzeit gelten (z.B. Sperrung vom 01.01.2016 00:00 Uhr bis zum 31.3.2016, 23:59 Uhr, aber auch eine Sperrung am 17.9.2016 von 08:00 Uhr bis 18:00 Uhr).
• "täglich": ist für die regelmäßig wiederholte Anwendung einer Einschränkung zu verwenden (z.B. Wellenschlag vermeiden an einer Stelle, an der Ausbaggerungsarbeiten durchgeführt werden - 7.4.2016 bis 11.4.2016 täglich von 06:00 Uhr bis 18:00 Uhr).
• bei Tag (laut Definition in der CEVNI): Unter dem Begriff "Tag" ist der Zeitraum zwischen Sonnenaufgang und Sonnenuntergang zu verstehen.
• bei Nacht (laut Definition in der CEVNI): Unter dem Begriff "Nacht" ist der Zeitraum zwischen Sonnenuntergang und Sonnenaufgang zu verstehen.
• Wochentage: Bestehen auf verschiedene Wochentage bezogene Zeiten der Einschränkung, sind diese aus den folgenden Textelementen auszuwählen:
  • Montag,
  • Dienstag,
  • Mittwoch,
  • Donnerstag,
  • Freitag,
  • Samstag,
  • Sonntag,
  • Montag bis Freitag,
  • Samstag und Sonntag.
• "bei eingeschränkten Sichtverhältnissen": ist zu verwenden, wenn die Einschränkung nur gilt, wenn aufgrund von Nebel, Diesigkeit, Schnee, Regen oder aufgrund anderer Ursachen eingeschränkte Sichtverhältnisse herrschen.
• "mit Ausnahme von": Darf nicht verwendet werden. Unterbrochene Intervalle müssen als getrennte Einschränkungszeiträume innerhalb ein- und derselben Einschränkung angegeben werden. Dies ist darauf zurückzuführen, dass Reiseplanungssoftwares nicht in der Lage sind, diesen Code korrekt als etwas interpretieren, das an dem angegebenen Tag bzw. der angegebenen Uhrzeit nicht stattfindet. Daher ist es nicht möglich, ordnungsgemäße ETAs zu berechnen.
• "Montags bis freitags außer an gesetzlichen Feiertagen": ist nur zu verwenden, wenn im Gültigkeitszeitraum der Einschränkung gesetzliche Feiertage liegen. Als Service für die Nutzer können im Freitextabschnitt der FTM gesetzliche Feiertage angegeben werden. Reiseplanungssoftwares sind nicht in der Lage, nationale gesetzliche Feiertage für die Berechnung von ETA zu berücksichtigen.

4.5. Indication_code:

Der Indication_code soll für Informationen über spezifische Werte im Hinblick auf bestimmte Einschränkungen (z.B. Geschwindigkeitsbegrenzungen, Mindestantriebsleistung, verfügbare Tiefe) verwendet werden. Zur Berechnung bestimmter Abmessungen ist ein Bezug auf ein externes (geografisches oder hydrologisches) Referenzsystem (z.B. Durchfahrtshöhe, verfügbare Tiefe, minimale Tiefe) erforderlich oder die Berechnung erfolgt in Relation zu bekannten Abmessungen von Bauwerken (z.B. verfügbare Länge, verfügbare Breite).

4.5.1. Sind absolute Abmessungen oder Referenzwerte bekannt, sind diese zu verwenden. Nur wenn eine Bezugnahme auf ein externes Referenzsystem nicht möglich ist, sind relative Werte zu verwenden.

4.5.2. Verringert um → dies ist ein relativer Wert

4.5.3. Maximum → dies ist ein absoluter Wert

4.5.4. Minimum → dies ist ein absoluter Wert

4.5.5. Bezieht sich das Maß, mit dem eine Einschränkung angegeben wird, auf eine geografische oder hydrologische Koordinate, muss in der NtS-Nachricht das betreffende Referenzsystem genannt werden (z.B. Durchfahrtshöhe mindestens 4 m bezogen auf den höchsten Schifffahrtswasserstand; verfügbare Tiefe mindestens 1,7 m bezogen auf den regulierten Niedrigwasserstand)

4.5.6. Bezieht sich das Maß, mit dem eine Einschränkung angegeben wird, auf ein Bauwerk (z.B. eine Brücke oder Schleuse), kann der Referenzwert relativ zu bekannten Maßen angegeben werden (z.B. Durchfahrtshöhe vermindert um 1,5 m, verfügbare Länge vermindert um 27 m).

4.6. Position_code (Objekte):

Nach Möglichkeit sollte sich der Position_code auf die Seite der Wasserstraße beziehen, auf der sich das Objekt relativ zur Fahrwasserachse (links/Mitte/rechts), relativ zu anderen allgemein bekannten Informationen (alt/neu) oder zur geografischen Richtung (Nord/Süd/Ost/West) befindet. Der Position_code für Objekte kann automatisch vorab aus den Referenzdaten des RIS Index eingetragen werden. Die linke/rechte Seite der Wasserstraße ist stromabwärts definiert.

4.7. Position_code (Fahrwasser/Wasserstraße):

Ein Position_code für eine auf eine Wasserstraße bezogene FTM (oder Teil einer solchen FTM) ist nicht vorgesehen. Um anzugeben, auf welcher Seite des Fahrwassers/Kanals/Flusses/Sees ein Ereignis eintritt, wird die Einschränkung "besondere Vorsicht" verbunden mit dem korrekten Position_code der Einschränkung verwendet.

4.8. Position_code (Einschränkungen):

4.8.1. Nach Möglichkeit sollte der Position_code auf die Seite der Wasserstraße oder Objekts Bezug nehmen, an der die Einschränkung eintritt (links/rechts). Die linke/rechte Seite der Wasserstraße ist stromabwärts definiert.

4.8.2. Der Position_code soll die Aufmerksamkeit des Schiffsführers auf die Seite der Wasserstraße lenken, an der sich ein Gebiet von besonderem Interesse, eine Gefahr oder eine Behinderung befindet. Daher genügt eine ungefähre Angabe (z.B. linkes Ufer - links - Mitte - rechts - rechtes Ufer). Eine feinere Unterteilung ist nicht beabsichtigt.

4.8.3. Bei Bedarf sind genauere Angaben zur Position vorzugsweise mittels Karten oder Skizzen zu übermitteln (Anlage, siehe Kapitel 3.6).

4.8.4. Bei Abschnitten, in denen die übliche Positionsangabe nach der Seite der Wassenstraße (links/rechts) nicht geeignet erscheint (z.B. Hafenbecken, bestimmte Kanalabschnitte ohne eindeutige Strömungsrichtung), können die Himmelsrichtungen (Norden/Osten/Süden/Westen) verwendet werden.

4.9. Target_group_code (siehe Kapitel 3.5)

4.10. Reporting_code

4.10.1. Der Reporting_code ist generell nur dann zu verwenden, wenn besonderer Kommunikationsbedarf besteht (z.B. zusätzliche Pflicht, sich bezüglich einer Verkehrsregelung vor Ort bei einer örtlichen Behörde zu melden) oder wenn ergänzende Informationen zur Verfügung stehen (z.B. VHF-Kontaktpunkt wie Bezeichnung des Kanals oder Rufzeichen für die aktuelle Position eines Baggers), die von unmittelbarer Relevanz für die FTM sind.

4.10.2. Eine routinemäßige Wiederholung öffentlich zugänglicher Kommunikationsdaten (z.B. Telefonnummern örtlicher Behörden, VHF-Kanäle von Schleusen usw.) ist zu vermeiden, sofern in Bezug auf die FTM kein unmittelbarer Grund für eine solche Kommunikation besteht.

4.10.3. Nach amtlichen Regelungen allgemein anwendbare Kommunikationsmittel (z.B. VHF-Kommunikation von Schiff zu Schiff und vom Schiff zum Ufer gemäß Festlegung in der CEVNI oder in regionalen bzw. nationalen Vorschriften für die Schifffahrt) sind generell nicht durch den Reporting_code zu wiederholen, sofern in Bezug auf die FTM kein unmittelbarer Grund für eine solche Kommunikation besteht.

4.11. Communication_code

es ist das folgende Format zu nutzen (Beispiele):

• VHF "Nummer, Rufzeichen": "10, Schifffahrtsaufsicht Wien"
• Telefon- oder Faxnummer: "+43123456789, Schifffahrtsaufsicht Wien"
• Internetadresse: "http://example.com"
• Tonsignal: "long blast / langer Ton"
• E-Mail: "example@authority.eu"
• EDI-Postfachnummer: "900012345@edi.bics.nl"
• Teletext: "ARD, 992 - 995"

4.12. Type_code:

Eine Wasserstraße ist entweder ein Kanal, ein See oder ein Fluss.

• Ankerplatz
• Ufer
• Leuchtfeuer
• Liegeplatz
• Grenzstation
• Brücke
• Brückenöffnung
• Tonne
• Überspannung
• Kanal (Der Begriff "Kanal" wird benutzt, wenn sich eine Nachricht auf den gesamten Kanal (nicht nur das Fahrwasser) bezieht)
• Kanalbrücke: Aquädukt
• Düker
• Fahrwasser (Der Begriff "Fahrwasser" bezeichnet den Teil der Wasserstraße, der tatsächlich von der Schifffahrt genutzt werden kann)
• Fähre
• Schwimmdock
• Sperrtor (Ein Sperrtor wird zum Schutz eines Gebiets bei Hochwasser genutzt)
• Hafen
• Hafeneinrichtung
• Hafenmeisterbüro
• See (Der Begriff "See" wird benutzt, wenn sich eine Nachricht auf den gesamten See (nicht nur das Fahrwasser) bezieht)
• leicht
• Schleusenbecken: einzelne Schleusenkammer
• Schleuse: der gesamte Schleusenkomplex
• Festmacheinrichtung
• Schifffahrtszeichen
• Rohrleitungen
• Rohrbrücke
• Rampe
• Abfallsammelstelle
• Meldepunkt
• Sammelbecken
• Fluss (Der Begriff "Fluss" wird benutzt, wenn sich eine Nachricht auf den gesamten Fluss (nicht nur das Fahrwasser) bezieht)
• Schiffslift
• Schiffswerft
• Signalstation
• Umschlagstelle
• Pegel
• Tunnel
• Wendeplatz
• Schiffsverkehrszentrale
• Wehr (ein Wehr wird zur Regelung des Wasserstands in Flüssen benutzt)

5. Grundüberlegungen zu WRM

Wasserstandsmeldungen sind generell automatisch zu erstellen. Ist dies nicht möglich, muss die manuelle Erstellung von WRM möglichst eng an die für automatisch erstellte WRM festgelegten Prozesse angelehnt sein (siehe NtS Encoding Guide für Anwendungsentwickler).

6. Grundüberlegungen zu ICEM, Schritte zur Herausgabe einer ICEM

Eismeldungen sind von örtlicher Beobachtung und Bewertung abhängig und werden gewöhnlich von entsprechend bevollmächtigtem Personal erstellt.

Eine ICEM ist herauszugeben, wenn Eis vorliegt. Eis verursacht nicht unbedingt Einschränkungen für die Schifffahrt, es können aber Informationen über die Schifffahrt nicht behindernde Eisverhältnisse bereitgestellt werden.

6.1. Besteht die Notwendigkeit, Informationen im Wege einer NtS ICEM?

Die erste Eismeldung für einen Abschnitt ist nur herauszugeben, wenn Eis auf der Wasserstraße oder deren Zuflüssen vorhanden ist, auch wenn keine Einschränkungen bestehen.

6.2. Besteht bereits eine gültige ICEM für den betroffenen Abschnitt der Wasserstraße?

6.2.1. Ja:

Gilt für den betroffenen Abschnitt eine Meldung (noch), wird die bereits bestehende Meldung aktualisiert. Bestehende Eismeldungen können auch dann aktualisiert werden, wenn sich der Geltungsbereich ändert (z.B. dehnt sich das Eis aus und erhöht damit die Größe des betroffenen Abschnitts).

6.2.2. Nein:

Steht keine gültige Eismeldung für den betroffenen Abschnitt zur Verfügung, muss eine neue Meldung erstellt werden.

6.3. Es können jedoch Informationen über die Schifffahrt nicht behindernde Eisverhältnisse bereitgestellt werden.

6.4. Eine ICEM gilt stets für einen einzelnen Abschnitt der Wasserstraße. Die geografische Reichweite der Gültigkeit ist mittels Definition der Wasserstraße und der jeweiligen Anfangs- und Endpunkte (Hektometerpunkte) (oder, je nach nationaler Umsetzung, mittels Wahl bestimmter, aufeinanderfolgender Abschnitte) festzulegen.

6.5. Die Zeit der Messung ist einzutragen. Die jeweiligen Eisverhältnisse sind mit Hilfe mindestens einer der Codelisten (je nach nationalen Anforderungen) einzutragen.

6.5.1. Ice_condition_code

6.5.2. Ice_accessibility_code

6.5.3. Ice_classification_code

6.5.4. Ice_situation_code (der Code für die Eissituation ist immer bereitzustellen, damit die Eissituation auf einer Karte unter Verwendung von "Ampelfarben" dargestellt werden kann).

6.6. Die ICEM kann nun herausgegeben werden. Eismeldungen gelten automatisch bis zum Tag nach der Herausgabe oder bis zu dem in nationalen Verfahrensanweisungen festgelegten Zeitpunkt.

7. Grundüberlegungen zu WERM

In Anbetracht der Fülle verfügbarer Webdienste und Apps für Wettervorhersagen und Unwetterwarnungen sollten WERM nur für Wetterinformationen von besonderer Wichtigkeit für die Schifffahrt verwendet werden, die von allgemeinen Wetterinformationsdiensten nicht erfasst werden.

Wettermeldungen sind generell automatisch zu erstellen. Ist dies nicht möglich, muss die manuelle Erstellung von WERM möglichst eng an die für automatisch erstellte WERM festgelegten Prozesse angelehnt sein (siehe NtS Encoding Guide für Anwendungsentwickler).

8. Regeln für bestimmte Elemente

8.1. Regeln für das Element "name" in Bezug auf Objekte

Objektbezeichnungen (Namen) werden gewöhnlich vom NtS-Editionstool anhand von RIS Index-Referenzdaten vorab eingetragen. Namen sind in der Landessprache einzutragen, d. h., es können auch Umlaute oder kyrillische Buchstaben verwendet werden. (z.B. Baarlerbrücke, Volkeraksluis oder Mannswörth).

Keine Informationen über Merkmale des Objekts aufnehmen; der Objekttyp ist im Namen nicht zu wiederholen, sofern damit keine ergänzenden Informationen zum Objekttyp übermittelt werden.

Beispiel: Die Schleuse "Schleuse Freudenau" ist nur als "Freudenau" zu bezeichnen, der Objekttyp "Schleuse" wird automatisch auf der Grundlage des type_code hinzugefügt.

Beispiel: Die Objektbezeichnung für die Eisenbahnbrücke in Krems (AT) lautet "Eisenbahnbrücke Krems". Die Information "Eisenbahnbrücke" wird in die Objektbezeichnung aufgenommen, weil sie ergänzende Informationen zum type_code "Brücke" übermittelt.

Beispiel: Die Objektbezeichnung für eine Brücke in Linz (AT) lautet "Nibelungenbrücke". Das Wort "Brücke" bleibt in der Objektbezeichnung stehen, weil es Bestandteil der Brückenbezeichnung an sich ist.

Beispiel: Der Wasserstraßenpegel "Pegelstelle Wildungsmauer" wird als "Wildungsmauer" bezeichnet, weil die Information, dass es sich bei dem Objekt um eine Pegelstelle handelt, bereits im type_code codiert ist.

Bildet ein Wasserstraßenabschnitt die Grenze zwischen zwei Ländern mit unterschiedlichen Sprachen, kann die nationale Objektbezeichnung in beiden Sprachen bereitgestellt werden (z.B."Staatsgrenze AT-SK/Statna hranica AT-SK").

8.2. Regeln für das Element "name" in Bezug auf Wasserstraßen

Bezeichnungen von Wasserstraßen (Namen) werden gewöhnlich vom NtS-Editionstool anhand von RIS Index-Referenzdaten vorab eingetragen. Das Feld "name" enthält die örtliche Bezeichnung des betreffenden Wasserstraßenabschnitts (z.B."Rhein"). Je nach nationalen Verfahren kann die Möglichkeit bestehen, die Bezeichnung der Wasserstraße zu editieren und übliche örtliche Bezeichnungen oder Ergänzungen aufzunehmen (z.B."Rhein am Deutschen Eck").

8.3. Regeln für die Elemente "value" und "unit" bei Einschränkungen

Wenn nicht anders angegeben, dürfen in NtS-Nachrichten nur cm, m3/s, h, km/h und kW, m/s (Wind), mm/h (Regen) und Grad Celsius als Maßeinheiten (units) benutzt werden.

.

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 Schrittfü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:
   1. 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
   2. 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,
   1. wird kontrolliert, ob alle obligatorischen Inhalte der NtS XSD entsprechend bereitgestellt wurden (wenn nicht, zurück zu Schritt (2)),
   2. wird die nts_number von der NtS-Anwendung erzeugt,
      1. wird in "organisation" je nach Funktion des herausgebenden Nutzers der Name oder Code der verantwortlichen Organisation eingetragen,
      2. wird in "year" das aktuelle Jahr eingetragen,
      3. wird die nächst verfügbare "number" zugewiesen,
      4. wird die "serial number" 0 zugewiesen.
   3. wird in "date_issue" automatisch das tatsächliche Datum/die tatsächliche Uhrzeit der Herausgabe eingetragen,
   4. wird in "validity_period" - "date_start" automatisch das tatsächliche Datum der Herausgabe eingetragen,
   5. 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,
   1. wird kontrolliert, ob alle obligatorischen Inhalte der NtS XSD entsprechend bereitgestellt wurden (wenn nicht, zurück zu Schritt (2)),
   2. wird die nts_number von der Anwendung erzeugt,
      1. bleibt "organisation" unverändert,
      2. bleibt "year" unverändert,
      3. bleibt "number" unverändert,
      4. wird die "serial number" erhöht (um 1 erhöht),
   3. wird in "date_issue" automatisch das tatsächliche Datum/die tatsächliche Uhrzeit der Herausgabe eingetragen,
   4. wird in "validity_period" - "date_start" automatisch das tatsächliche Datum der Herausgabe eingetragen,
   5. 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.

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:
   1. die Nutzung bestehender Nachrichten als Entwurf für die Erstellung neuer FTM und/oder
   2. 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,
   1. wird kontrolliert, ob alle obligatorischen Inhalte der NtS XSD entsprechend bereitgestellt wurden (wenn nicht, zurück zu Schritt (2)),
   2. wird die nts_number von der Anwendung erzeugt,
      1. wird in "organisation" je nach Funktion des herausgebenden Nutzers der Name oder Code der verantwortlichen Organisation eingetragen,
      2. wird in "year" das aktuelle Jahr eingetragen,
      3. 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).
      4. wird die "serial number" 0 zugewiesen,
   3. 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).
   1. 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.
   2. Der Betreff-Code "Nachricht aufgehoben" wird nur verwendet, wenn
      1. 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.
      2. 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.
   3. 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,
   1. wird kontrolliert, ob alle obligatorischen Inhalte der NtS XSD entsprechend bereitgestellt wurden (wenn nicht, zurück zu Schritt (2)),
   2. wird die nts_number von der Anwendung erzeugt,
      5. bleibt "organisation" unverändert,
      6. bleibt "year" unverändert,
      7. bleibt "number" unverändert,
      8. wird die "serial number" erhöht (um 1 erhöht),
   3. wird in "date_issue" automatisch das tatsächliche Datum/die tatsächliche Uhrzeit der Herausgabe eingetragen,
   2. 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:

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:

  

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

  

  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"

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.

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 e 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 d 110,5 und dem End-Hektometer e 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 betreffspezifischen 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 betreffspezifischen 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

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

.

=> zur ^PDF

.

=> zur ^PDF

ENDE