Rozporządzenie Komisji (WE) nr 416/2007 z dnia 22 marca 2007 r. dotyczące specyfikacji tec...

Artykuł 1

Niniejsze rozporządzenie określa specyfikacje techniczne komunikatów dla kierowników statków. Specyfikacje te są przedstawione w załączniku do niniejszego rozporządzenia.

Artykuł 2

Niniejsze rozporządzenie wchodzi w życie następnego dnia po jego opublikowaniu w Dzienniku Urzędowym Unii Europejskiej.

Niniejsze rozporządzenie wiąże w całości i jest bezpośrednio stosowane we wszystkich państwach członkowskich.

Załącznik

SPIS TREŚCI

1. PRZEPISY OGÓLNE

1.1.

Definicje

1.2.

Podstawowe funkcje i wymagania użytkowe dotyczące komunikatów dla kierowników statków (ang. Notices to Skippers, NtS)

2. PRZEKAZYWANIE KOMUNIKATÓW DLA KIEROWNIKÓW STATKÓW

3. RODZAJE KOMUNIKATÓW NtS

4. STRUKTURA I KODOWANIE KOMUNIKATÓW NtS

4.1.

Ogólna struktura

4.1.1.

Sekcja identyfikacyjna

4.1.2.

Komunikat dotyczący szlaku żeglownego i ruchu

4.1.3.

Komunikat dotyczący stanu wody

4.1.4.

Komunikat o lodzie

4.1.5.

Komunikat pogodowy

4.2.

Objaśnienie tagów XML i wartości kodów przedstawionych w NtS Reference Tables

4.3.

Identyfikacja odcinka szlaku żeglownego i obiektów w komunikatach NtS

4.4.

Przepisy dotyczące kodowania komunikatów NtS

Dodatek A: NtS Encoding Guide dla edytorów

Dodatek B: NtS Encoding Guide dla deweloperów aplikacji

Dodatek C: Definicja schematu XML dla NtS (XSD)

Dodatek D: Specyfikacja NtS Web Service (WSDL)

1. PRZEPISY OGÓLNE

1.1.

Definicje

Usługi informacji o drogach wodnych (FIS) obejmują dane geograficzne, hydrologiczne i administracyjne dotyczące drogi wodnej (szlaku żeglownego) wykorzystywane przez kapitanów i kierowników floty do planowania, realizacji i monitorowania podróży. Terminy „kapitan” i „kierownik statku” używane w niniejszym załączniku uznaje się za równoważne terminowi „kapitan statku” używanemu w wytycznych dotyczących usług informacji rzecznej (RIS) (rozporządzenie Komisji (WE) nr 414/2007 (

1

)), a termin „kierownicy floty” został zdefiniowany w rozporządzeniu Komisji (WE) nr 415/2007 (

2

).

FIS zapewniają informacje dynamiczne (np. o stanie wody, prognozowanym stanie wody itp.) i statyczne (np. o rozkładzie godzin otwarcia śluz i mostów) na temat warunków użytkowania i stanu infrastruktury dróg wodnych, a zatem stanowią wsparcie dla taktycznych i strategicznych decyzji nawigacyjnych.

Do tradycyjnych środków wykorzystywanych do świadczenia FIS należą wizualne pomoce nawigacyjne oraz komunikaty dla kierowników statków sporządzone na papierze, dostarczane za pomocą radia i aparatów telefonicznych znajdujących się przy śluzach. Telefony komórkowe zwiększyły możliwości w zakresie łączności głosowej i przesyłania danych, ale korzystanie z sieci komórkowych nie jest możliwe we wszystkich miejscach i przez cały czas. Świadczenie dostosowanych do potrzeb FIS na drogach wodnych może być realizowane za pomocą usług radiotelefonicznych na śródlądowych drogach wodnych, serwisu internetowego lub serwisu opartego na elektronicznych mapach nawigacyjnych, takiego jak system obrazowania elektronicznych map i informacji nawigacyjnych (IECDIS) z elektroniczną mapą nawigacyjną (ENC)).

1.2.

Podstawowe funkcje i wymagania użytkowe dotyczące komunikatów dla kierowników statków (NtS)

Niniejsza specyfikacja techniczna dotycząca NtS zawiera przepisy dotyczące transmisji danych w ramach przekazywania informacji o szlakach żeglownych przez internet.

NtS powinny:

a) dostarczać informacje związane z warunkami na szlaku żeglownym, ruchem, pogodą, stanem wody i lodem, na potrzeby usług informacji o drogach wodnych;

b) zapewniać automatyczne tłumaczenie najistotniejszych treści komunikatów, wykorzystując standardowe słownictwo oparte na wykazach kodów (NtS Reference Tables przedstawione w dodatku E);

c) być dostarczane są w postaci znormalizowanej struktury zbiorów danych w celu ułatwienia włączenia komunikatów do systemów planowania podróży;

d) być kompatybilne ze strukturą danych RIS Index oraz IECDIS w celu ułatwienia włączenia NtS do IECDIS, jak określono w dyrektywie 2005/44/WE z dnia 7 września 2005 r. w sprawie zharmonizowanych usług informacji rzecznej (RIS) na śródlądowych drogach wodnych we Wspólnocie.

Specyfikacje techniczne NtS ułatwiają wymianę danych między systemami NtS stosowanymi przez różne państwa oraz do celów innych aplikacji wykorzystujących dane dotyczące NtS, w tym IECDIS.

Pewne informacje zawarte w komunikatach NtS można ustandaryzować, ale nie wszystkie.

Część ustandaryzowana obejmuje wszystkie informacje, które są:

a) ważne dla bezpieczeństwa żeglugi śródlądowej (na przykład: mały statek zatopiony z prawej strony szlaku żeglownego, Dunaj, km biegu rzeki 2010);

b) konieczne do planowania podróży, co obejmuje zamknięte śluzy i zmniejszenie prześwitu pionowego.

Dodatkowe informacje, które nie są istotne dla bezpieczeństwa ani planowania podróży, w tym przyczyny zamknięcia śluzy, mogą zostać podane jako tekst dowolny, bez tłumaczenia automatycznego. Użycie tekstu dowolnego należy ograniczyć do minimum.

2. PRZEKAZYWANIE KOMUNIKATÓW DLA KIEROWNIKÓW STATKÓW

Państwa członkowskie zapewniają dostęp do komunikatów NtS przez internet i za pomocą ustandaryzowanej NtS Web Service zgodnie z specyfikacjami technicznymi opisanymi w niniejszym załączniku i dodatkach do niego. Specyfikację ustandaryzowanej NtS Web Service przedstawiono w dodatku D w postaci Web Service Description Language (WSDL, język definiowania usługi sieciowej).

Ustandaryzowane NtS Web Services zapewniają użytkownikowi możliwość filtrowania komunikatów według co najmniej jednego z następujących kryteriów:

a) określony odcinek drogi wodnej;

b) określona część drogi wodnej, zdefiniowana za pomocą km biegu rzeki w punkcie początkowym i końcowym;

c) okres obowiązywania komunikatu (data rozpoczęcia okresu obowiązywania i data jego zakończenia);

d) data publikacji komunikatu (data i godzina publikacji).

Komunikaty NtS, które są zgodne ze standardami, do których odniesienie zawarto w niniejszym załączniku, mogą być przekazywane między innymi za pomocą:

a) aplikacji mobilnych;

b) usług poczty elektronicznej.

Możliwa jest wymiana danych między systemami NtS wykorzystywanymi w różnych państwach. Wszystkie systemy oparte na standardach opisanych w załączniku do niniejszego rozporządzenia mają możliwość włączenia NtS z innych systemów do swoich usług, pod warunkiem że treść komunikatu nie została zmieniona. Użytkownicy są informowani, jeżeli połączenie z systemem, który stanowi źródło włączonych NtS, zostaje przerwane lub nie jest dostępne.

3. RODZAJE KOMUNIKATÓW NTS

Komunikaty NtS to komunikaty o podstawowym znaczeniu, w których jak największa część komunikatu jest ustandaryzowana.

Istnieją cztery rodzaje komunikatów NtS, a mianowicie:

a) komunikat dotyczący szlaku żeglownego i ruchu;

b) komunikat dotyczący stanu wody;

c) komunikat o lodzie;

d) komunikat pogodowy.

4. STRUKTURA I KODOWANIE KOMUNIKATÓW NTS

W niniejszym rozdziale opisano strukturę i kodowanie ustandaryzowanych komunikatów NtS w postaci elektronicznej.

Komunikat NtS to ustrukturyzowany komunikat, w którym w miarę możliwości stosuje się ustandaryzowane elementy. Użycie tekstu dowolnego w elementach danych należy ograniczyć do minimum.

Ustandaryzowana definicja schematu rozszerzalnego języka znaczników (XML) dla NtS, oznaczana w niniejszym standardzie skrótem XSD, zawiera ustandaryzowane wartości kodów oraz dopuszczalne formaty i została przedstawiona w dodatku C.

Ustandaryzowane wartości kodów i tagi XML, ich znaczenie i tłumaczenie przedstawiono w NtS Reference Tables w dodatku E oraz udostępniono w postaci elektronicznej w European Reference Data Management System (ERDMS) (europejskim systemie zarządzania danymi referencyjnymi), którym zarządza Komisja Europejska.

4.1.

Ogólna struktura

Komunikat NtS składa się z następujących sekcji:

a) sekcja identyfikacyjna;

b) sekcja określająca odpowiednie obiekty lub odcinki szlaku żeglownego, do których odnosi się dany komunikat;

c) ograniczenia w przypadku komunikatu dotyczącego szlaku żeglownego i ruchu, pomiary w przypadku komunikatu dotyczącego stanu wody, stan lodu w przypadku komunikatu o lodzie oraz raporty pogodowe w przypadku komunikatu pogodowego.

Rysunek 1

Struktura komunikatu dla kierowników statków

4.1.1.

Sekcja identyfikacyjna

Każdy komunikat musi zawierać sekcję identyfikacyjną. Sekcja identyfikacyjna zawiera ogólne informacje na temat nadawcy i datę publikacji komunikatu.

4.1.2.

Komunikat dotyczący szlaku żeglownego i ruchu

Komunikat dotyczący szlaku żeglownego i ruchu zawiera informacje na temat odcinków szlaku żeglownego lub obiektów i jest wykorzystywany do wskazania ograniczeń w następujących celach:

a) „Ostrzeżenie”: istotne dla bezpieczeństwa. Ostrzeżenie musi zawierać co najmniej jedno ograniczenie, z którego wynika bezpośrednie i określone zagrożenie dla osób, jednostek pływających lub obiektów infrastruktury, takie jak prowadzone na moście prace spawalnicze z wytwarzaniem iskier, zwieszony z mostu kosz do prowadzenia inspekcji lub zawieszeni pod mostem pracownicy prowadzący inspekcję, przeszkoda na szlaku żeglownym;

b) „Ogłoszenie”: istotne dla planowania podróży lub bezpieczeństwa. Ogłoszenie może zawierać ograniczenia, takie jak blokada komory śluzy wynikająca z prac konserwacyjnych, pogłębianie szlaku żeglownego;

c) „Serwis informacyjny”: ogólne informacje, które nie są bezpośrednio związane z planowaniem podróży ani bezpieczeństwem. Serwis informacyjny nie może zawierać konkretnych ograniczeń i tym samym nie ma bezpośredniego związku z planowaniem podróży ani bezpieczeństwem. Takie informacje mogą obejmować informacje ogólne, np. miejscowe przepisy ruchu statków, aktualizację IECDIS.

4.1.3.

Komunikat dotyczący stanu wody

Sekcja dotycząca stanu wody zawiera wartości lub prognozy dotyczące:

a) stanu wody;

b) głębokości minimalnej;

c) prześwitu pionowego;

d) stanu zapory;

e) spustu;

f) reżimu.

Informacje dotyczące stanu wody są zazwyczaj tworzone i publikowane automatycznie w oparciu o dane otrzymane z czujników (takich jak mareograf), systemów (takich jak model stanu wody) lub infrastruktury (np. stan zapory). Informacje mogą być publikowane z różnych przyczyn, takich jak okresowy rytm publikacji lub osiągnięcie określonej wartości.

4.1.4.

Komunikat o lodzie

Komunikat o występowaniu lodu zawiera informacje o bieżącym lub prognozowanym stanie lodu na danym odcinku/danych odcinkach szlaku żeglownego. Informacje o lodzie generuje zazwyczaj odpowiedni personel w oparciu o lokalną obserwację i fachową ocenę.

4.1.5.

Komunikat pogodowy

Komunikat pogodowy zawiera informacje na temat (niebezpiecznych) warunków pogodowych dla żeglugi śródlądowej.

Aby ułatwić rozpowszechnianie wśród kierowników statków informacji hydrometeorologicznych pochodzących z sieci hydrometeorologicznych, można publikować komunikaty pogodowe.

4.2.

Objaśnienie tagów XML i wartości kodów przedstawionych w NtS Reference Tables

Znaczenie poszczególnych elementów stosowanych w definicji schematu XML (XSD) dla NtS opisano w NtS Reference Tables przedstawionych w dodatku E. Struktura, format i możliwe wartości wszystkich elementów XML opisano w XSD dla NtS w dodatku C.

a) Szerokość geograficzna i długość geograficzna kodowane są zgodnie ze Światowym Systemem Geodezyjnym z 1984 r. i podawane w stopniach i minutach z dokładnością co najmniej do trzech – a najlepiej do czterech – miejsc po przecinku ([d]d mm.mmm[m] N, [d][d]d mm.mmm[m] E).

b) Znak dziesiętny w polach numerycznych jest zaznaczany za pomocą kropki („.”). Nie stosuje się żadnych separatorów oddzielających grupy trzycyfrowe w liczbach od tysiąca wzwyż.

c) W komunikatach NtS wykorzystuje się tylko następujące jednostki w odniesieniu do wartości podanych w wiadomości XML: cm, m3/s, h, km/h i kW, m/s (wiatr), mm/h (opady deszczu) oraz stopnie Celsjusza. Krajowe aplikacje mogą przeliczać te jednostki w celu wyświetlenia ich w sposób przyjazny dla użytkownika.

4.3.

Identyfikacja odcinka szlaku żeglownego i obiektów w komunikatach NtS

Aby spełnić minimalne wymagania w zakresie danych dotyczące dostarczania informacji na temat obiektów istotnych dla żeglugi śródlądowej, o których mowa w art. 4 ust. 3 lit. a) dyrektywy 2005/44/WE, w sekcji dotyczącej obiektu należy zastosować ISRS Location Code. ISRS Location Code stosuje się w celu jednoznacznej identyfikacji obiektów i odcinka szlaku żeglownego oraz zapewnienia interoperacyjności systemów i usług RIS (tak aby połączyć informacje na temat infrastruktury pochodzące z RIS Index, IECDIS i NtS na potrzeby planowania podróży).

ISRS Location Code jest 20-cyfrowym kodem alfanumerycznym stosowanym w celu ustalenia jednoznacznych i znormalizowanych powiązań między obiektami w systemie usług informacji rzecznej. Składa się z następujących obowiązkowych elementów danych tworzących cztery bloki informacyjne:

a) Blok 1: UN/LOCODE (5 znaków alfanumerycznych), składający się z

— Country code (2 znaki alfanumeryczne) (

3

) oraz

— Location code (3 znaki alfanumeryczne; „XXX”, jeżeli dane nie są dostępne)

b) Blok 2: Fairway section code (5 znaków alfanumerycznych, które ustala organ krajowy)

c) Blok 3: Object Reference Code (5 znaków alfanumerycznych; „XXXXX”, jeżeli dane nie są dostępne)

d) Blok 4: Fairway section hectometre (5 cyfr, wartość liczbowa, hektometr w środku obszaru lub „00000”, jeżeli dane nie są dostępne).

Państwa członkowskie utrzymują ISRS Location Code oraz dane referencyjne dotyczące obiektów w indeksie RIS i przekazują je do zarządzanego przez Komisję systemu ERDMS zgodnie z procedurami obsługi RIS Index opublikowanymi na stronie ERDMS.

4.4.

Przepisy dotyczące kodowania komunikatów NtS

Komunikaty NtS koduje się zgodnie z NtS Encoding Guide dla edytorów (dodatek A) oraz zgodnie z NtS Encoding Guide dla deweloperów aplikacji (dodatek B).

NTS ENCODING GUIDE DLA EDYTORÓW

SPIS TREŚCI

1

Kontekst, struktura i cel NtS Encoding Guide

2. Wybór rodzaju komunikatu NtS

3. Podstawowe kwestie związane z FTM, etapy poprzedzające publikację FTM

4. Objaśnienie kodów związanych z FTM

5. Podstawowe kwestie związane z WRM

6. Podstawowe kwestie związane z ICEM, etapy poprzedzające publikację ICEM

7. Podstawowe kwestie związane z WERM

8. Przepisy dotyczące pewnych elementów

Skróty

Skrót

Znaczenie

CEVNI

Europejski kodeks żeglugi po śródlądowych drogach wodnych (http://www.unece.org/trans/main/sc3/sc3res.html)

ENC

Elektroniczna mapa nawigacyjna

FTM

Komunikat dotyczący szlaku żeglownego i ruchu

ICEM

Komunikat o lodzie

IECDIS

System obrazowania elektronicznych map i informacji nawigacyjnych w żegludze śródlądowej

ISRS Location Code

Kod lokalizacji międzynarodowego standardu meldowania statków („International Ship Reporting Standard”)

NtS

Komunikaty dla kierowników statków

RIS

Usługi informacji rzecznej

VHF

Pasmo morskiej łączności ruchomej

WERM

Komunikat pogodowy

WRM

Komunikat dotyczący stanu wody

WSDL

Język definiowania usługi sieciowej (ang. Web Services Description Language)

XML

Rozszerzalny język znaczników

XSD

Definicja schematu XML

1. Kontekst, struktura i cel NtS Encoding Guide

Standard NtS jest stale ulepszany. Znaczący postęp stanowiło uruchomienie NtS Web Service, która ułatwia wymianę komunikatów NtS między poszczególnymi organami, jak również między organami i użytkownikami NtS.

Opracowano dwa dokumenty w celu ułatwienia zharmonizowanego kodowania komunikatów NtS na szczeblu krajowym i międzynarodowym: NtS Encoding Guide dla edytorów i NtS Encoding Guide dla deweloperów aplikacji. Podręczniki te mają zastosowanie do standardu XSD dla NtS w wersji 4.0 oraz NtS Web Service WSDL 2.0.4.0.

Przez wzgląd na zwiększone wykorzystanie NtS Web Service należy w większym stopniu zharmonizować komunikaty NtS, aby zapewnić poprawne wyświetlanie treści w systemach należących do osób trzecich. Jednolite kodowanie komunikatów stanowi również warunek wstępny uwzględnienia komunikatów w aplikacjach służących do planowania podróży.

Jeżeli elementy, które zawierałyby jedynie wartości standardowe lub domyślne, mają charakter warunkowy, pomija się je, ponieważ prowadzą do narzutu danych w komunikacie niemających wartości dodanej.

NtS Encoding Guide dla edytorów jest przeznaczony dla osób, które redagują (i publikują) komunikaty NtS, i zawiera instrukcje tworzenia krok po kroku odpowiednich rodzajów komunikatów, jak również objaśnienie kodów. W NtS Encoding Guide objaśniono cztery rodzaje komunikatów NtS, przedstawiono instrukcje wypełniania ich, jak również kody, których należy użyć w określonych sytuacjach. NtS Encoding Guide dla edytorów znajduje się w niniejszym dodatku A.

NtS Encoding Guide dla deweloperów aplikacji zawiera wytyczne dotyczące tworzenia i wdrażania aplikacji do obsługi NtS oraz objaśnienie ich logiki, procesów i wartości automatycznych/domyślnych. NtS Encoding Guide dla deweloperów aplikacji znajduje się w dodatku B do załącznika do niniejszego rozporządzenia.

2. Wybór rodzaju komunikatu NtS

— FTM: Należy wybrać ten rodzaj, jeżeli celem jest sporządzenie „Komunikatu dotyczącego szlaku żeglownego i ruchu” odnoszącego się do drogi wodnej lub obiektów na drodze wodnej. [przejdź do rozdziału 3]

— WRM: Należy wybrać ten rodzaj, jeżeli celem jest sporządzenie „Komunikatu dotyczącego stanu wody”, który umożliwia przekazanie informacji na temat obecnego i prognozowanego stanu wody, jak również innych informacji. Komunikat dotyczący stanu wody zawiera informacje na temat obiektu lub odcinka szlaku żeglownego. Obiekt identyfikuje się za pomocą ISRS Location Code, odcinek szlaku żeglownego określa się za pomocą ISRS Location Code jego początku i końca.

— ICEM: Należy wybrać ten rodzaj, jeżeli celem jest sporządzenie „Komunikatu o lodzie”. Sekcja komunikatu o lodzie zawiera informacje na temat stanu lodu na odcinku szlaku żeglownego określonym poprzez podanie ISRS Location Code jego początku i końca.

— WERM: Należy wybrać ten rodzaj, jeżeli celem jest sporządzenie „Komunikatu pogodowego”, który umożliwia przekazanie informacji na temat obecnych i prognozowanych warunków pogodowych na danym odcinku drogi wodnej określonym poprzez podanie ISRS Location Code jego początku i końcu.

3. Podstawowe kwestie związane z FTM, etapy poprzedzające publikację FTM

Szczegółowe informacje dotyczące wyboru kodów, których należy użyć, zamieszczone zostały w rozdziale 4. Zagadnienia poruszane od pkt 3.3 niekoniecznie są uszeregowane w kolejności wprowadzania do narzędzia edytorskiego FTM.

3.1. Czy istnieje potrzeba publikacji informacji z zastosowaniem NtS FTM zgodnie ze standardem NtS? Wszystkie istotne informacje dotyczące bezpieczeństwa i planowania podróży muszą być publikowane w formie komunikatów NtS. Można publikować informacje, które nie są istotne pod względem bezpieczeństwa i planowania podróży. Każdy temat/każdy incydent/każde zdarzenie muszą być publikowane w odrębnym komunikacie.

3.2. Czy istnieje już obowiązujący jeszcze FTM związany z bieżącą sytuacją (w odniesieniu do treści, jak i okresu obowiązywania)?

3.2.1. Tak:

istniejący FTM musi zostać zaktualizowany. Należy wybrać i zaktualizować odpowiedni opublikowany komunikat w narzędziu edytorskim FTM. FTM, który wygasł, nie może już zostać zaktualizowany.

3.2.2. Nie:

należy przygotować nowy FTM. Jeżeli podobne zdarzenie zostało już zakodowane w istniejącym FTM, komunikat ten można wykorzystać jako wersję roboczą w celu sporządzenia nowego FTM (jeżeli ta funkcja jest dostępna) lub można skorzystać z odpowiedniego szablonu (jeżeli ta funkcja jest dostępna).

3.3. Należy określić geograficzny zakres obowiązywania.

3.3.1. Jeżeli FTM odnosi się do konkretnego odcinka drogi wodnej, należy podać ten odcinek, określając go za pomocą punktu początkowego i punktu końcowego. Jeżeli treść dotyczy szeregu odcinków tej samej drogi wodnej lub różnych dróg wodnych, można je wszystkie wymienić w jednym FTM.

3.3.2. Jeżeli FTM odnosi się do konkretnego obiektu (np. mostu, śluzy itp.) znajdującego się na drodze wodnej, obiekt ten należy wybrać z wykazu dostępnych obiektów (jeżeli opcja wyboru jest dostępna). Nie ma potrzeby określenia odcinka drogi wodnej w takim komunikacie. Jeżeli FTM odnosi się do szeregu obiektów, można je wszystkie uwzględnić w jednym FTM.

3.3.3. Połączenie informacji na temat obiektu i szlaku żeglownego w jednym komunikacie jest możliwe pod warunkiem, że informacje dotyczą jednej konkretnej przyczyny lub jednego konkretnego zdarzenia (ten sam kod tematu i przyczyny).

3.3.4. Chociaż współrzędne mają charakter warunkowy, podaje się je w celu lepszego zobrazowania sytuacji na mapach (współrzędne te są często automatycznie podawane przez aplikację do obsługi NtS).

3.4. Należy wprowadzić treść FTM

Wszystkie informacje, które można przedstawić stosując NtS Reference Tables, muszą być zakodowane w ustandaryzowanych polach komunikatu. Jedynie dodatkowe informacje (których nie można zakodować w innych sposób) podaje się w polach tekstu dowolnego.

3.5. W stosownych przypadkach należy wprowadzić informacje na temat grupy lub grup odbiorców w odniesieniu do rodzaju statków oraz kierunków ruchu, których to dotyczy.

3.5.1. Jeżeli komunikat obowiązuje w odniesieniu do wszystkich jednostek pływających (wszystkich rodzajów statków) płynących we wszystkich kierunkach, należy pominąć grupę odbiorców w celu zakodowania tylko niezbędnych informacji. Jeżeli komunikat/ograniczenie jest skierowane do konkretnej grupy odbiorców lub dotyczy konkretnego kierunku, należy wybrać odpowiednie kody.

3.5.2. Jeżeli cały komunikat obowiązuje w odniesieniu do konkretnej grupy odbiorców, informacje na temat grupy odbiorców przedstawia się w części ogólnej FTM (i nie powtarza się ich w sekcjach dotyczących ograniczeń).

3.5.3. Jeżeli różne grupy odbiorców podlegają różnym ograniczeniom, informacje dotyczące grupy odbiorców podaje się w sekcjach dotyczących odpowiednich ograniczeń (i nie powtarza się ich w części ogólnej).

3.5.4. Jeżeli właściwe organy wyłączyły pojedyncze jednostki lub ruch miejscowy z zakresu obowiązywania ograniczeń (np. statki biorące udział w zdarzeniu, którego dotyczy generalna blokada, lokalny ruch promowy na zamkniętym obszarze), należy uwzględnić takie wyłączenia podczas kodowania grupy lub grup odbiorców. Takie informacje można przedstawić w polu tekstu dowolnego przeznaczonym na informacje dodatkowe.

3.6. W stosownych przypadkach należy wprowadzić sekcję dotyczącą łączności.

Jeżeli dostępne są dodatkowe informacje z określonego źródła, należy to podać w tej sekcji. Jeżeli istnieje dodatkowy obowiązek meldowania za pośrednictwem określonego środka, należy to podać w tej sekcji.

3.7. W stosownych przypadkach należy wprowadzić sekcję dotyczącą ograniczeń.

Jeżeli mają zastosowanie ograniczenia, należy wypełnić sekcję dotyczącą ograniczeń. Jeżeli znane są wartości przypisane do ograniczeń, należy je podać. Należy obowiązkowo wprowadzić wartości dotyczące rozmiarów statku, ograniczenia prędkości i przestrzeni dostępnej na potrzeby nawigacji.

Przy wszystkich ograniczeniach podaje się okresy obowiązywania ograniczeń w celu umożliwienia przeprowadzenia odpowiednich obliczeń w aplikacjach służących do planowania podróży (w celu ułatwienia tych czynności aplikacja do obsługi NtS może posiadać funkcję kopiowania okresów obowiązywania ograniczeń lub wyboru więcej niż jednego ograniczenia dla danego okresu obowiązywania).

3.8. Należy ustawić datę rozpoczęcia okresu obowiązywania komunikatu.

Jeżeli data zakończenia okresu obowiązywania komunikatu jest już znana, należy ją również ustawić. Data zakończenia okresu obowiązywania nie może być wcześniejsza, niż data bieżąca.

Należy pamiętać, że informacje dotyczące okresu obowiązywania będą wykorzystywane przez aplikacje do wyboru komunikatów, które mają być wyświetlane użytkownikom przez żądany czas.

W przypadku gdy komunikat zostanie odwołany:

a) przed rozpoczęciem okresu obowiązywania, należy ustawić daty rozpoczęcia i zakończenia dla daty odwołania;

b) jeżeli okres obowiązywania już się rozpoczął, nowe daty zakończenia dla wszystkich ograniczeń należy ustawić jako daty minione, a jako datę zakończenia okresu obowiązywania komunikatu należy ustawić datę odwołania.

3.9. Komunikat może zostać opublikowany

4. Objaśnienie kodów związanych z FTM

4.1. Subject_code:

Definicja stosowania kodów tematu:

— „Ostrzeżenie”: istotne dla bezpieczeństwa. Ostrzeżenie musi zawierać co najmniej jedno ograniczenie, z którego wynika bezpośrednie i określone zagrożenie dla osób, jednostek pływających lub obiektów infrastruktury, takie jak prowadzone na moście prace spawalnicze z wytwarzaniem iskier, zwieszony z mostu kosz do prowadzenia inspekcji lub zawieszeni pod mostem pracownicy prowadzący inspekcję, przeszkoda na szlaku żeglownym,

— „Ogłoszenie”: istotne dla planowania podróży lub bezpieczeństwa. Ogłoszenie może zawierać ograniczenia, np. blokada komory śluzy spowodowana pracami konserwacyjnymi, pogłębianie szlaku żeglownego, przepisy dotyczące ruchu nie ujęte w przepisach krajowych,

— „Serwis informacyjny”: ogólne informacje, które nie są bezpośrednio związane z planowaniem podróży ani bezpieczeństwem. Serwis informacyjny nie może zawierać konkretnych ograniczeń i tym samym nie jest bezpośrednio istotny dla planowania podróży lub bezpieczeństwa. Takie informacje mogą obejmować np. miejscowe przepisy ruchu statków, aktualizację IECDIS. Okres obowiązywania wykorzystuje się do określenia czasu wyświetlania użytkownikom komunikatu „Serwis informacyjny”, a nie w odniesieniu do okresu obowiązywania przekazywanych informacji (np. 1 miesiąc lub okres określony w procedurach krajowych).

— „Komunikat odwołany”

— Kod tematu „Komunikat odwołany” stosuje się tylko wtedy, gdy:

— — bieżąca data jest wcześniejsza, niż data rozpoczęcia okresu obowiązywania. W takim przypadku może zostać zmieniona jedynie treść zawarta w polu „dodatkowe informacje w języku narodowym”, a pozostała treść komunikatu musi pozostać niezmieniona. W takim przypadku „komunikat odwołany” wykorzystuje się do wycofania komunikatu zanim zacznie obowiązywać. Oznacza to, że „komunikat odwołany” stosuje się w komunikatach, które nie osiągnęły daty rozpoczęcia obowiązywania lub dotyczyły zaplanowanych działań, które nie zostaną przeprowadzone (np. zaplanowano pogłębianie, ale nie można go było rozpocząć ze względu na wysoki stan wody),

— okres obowiązywania już się rozpoczął i jako nowe daty końcowe dla wszystkich ograniczeń ustawia się datę minioną. Jako datę zakończenia okresu obowiązywania komunikatu należy ustawić datę odwołania.

— W takim przypadku działania/wydarzenia kończą się przed zakończeniem pierwotnie ustawionego okresu obowiązywania już istniejącego FTM.

4.2. Reason_code

Kod przyczyny wypełnia się w celu przekazania kierownikom statków dodatkowych informacji.

Definicja stosowania kodów przyczyny:

Roboty budowlane

Ogłoszenie o prowadzonych robotach budowlanych

Wypadek

Ostrzeżenie o wypadku

Zmiany szlaku żeglownego

Ogłoszenie o zmianie szlaku żeglownego

Zmiana oznakowania

Ogłoszenie o zmianie oznakowania drogi wodnej

Zwężenie szlaku żeglownego

Ogłoszenie o ograniczeniu szerokości szlaku żeglownego, jeżeli żaden inny reason_code nie ma zastosowania.

Uszkodzone znaki/sygnały

Ogłoszenie o uszkodzonych znakach/sygnałach

Nurek pod wodą

Ostrzeżenie o nurku pod wodą

Pogłębianie

Ogłoszenie o pracach związanych z pogłębianiem

Impreza

Ogłoszenie o imprezach, np. zawodach pływackich, żeglarskich lub wioślarskich.

Ćwiczenia

Ogłoszenie o ćwiczeniach np. o ćwiczeniach ratowniczych lub wojskowych

Operacja usuwania materiałów wybuchowych

Ogłoszenie o operacji usuwania materiałów wybuchowych

Intensywne śluzowanie

Ogłoszenie o większym niż zwykle tempie spuszczania wody przez jazy i śluzy z przyczyn związanych z gospodarką wodną

Materiał spadający

Ogłoszenie o materiale spadającym, np. soplach, gałęziach drzew

Fałszywe echa radarowe

Ogłoszenie o możliwości wystąpienia fałszywych ech radarowych

Sztuczne ognie

Ogłoszenie o pokazie sztucznych ogni

Materiał pływający

Ogłoszenie dotyczący materiałów pływających ponad poziomem wody (widocznych) i poniżej poziomu wody (niewidocznych)

Pomiar prądu

Ogłoszenie o pracach pomiarowych

Zagrożenie dla zdrowia

Ostrzeżenie lub Ogłoszenie dotyczące zagrożenia dla zdrowia z powodu np. gąsienicy korowódki dębówki, ulatniającego się gazu itp.

Linia wysokiego napięcia

Ogłoszenie o poprzecznej linii wysokiego napięcia

Wysoki stan wody

Ogłoszenie o wysokim stanie wody przed osiągnięciem stanu wody uniemożliwiającego żeglugę

Lód

Ogłoszenie o lodzie; dalsze informacje wysyłane są w formie informacji o lodzie (komunikatu o lodzie)

Aktualizacja IECDIS

Serwis informacyjny dotyczący aktualizacji IECDIS

Inspekcja

Ogłoszenie o prowadzonej inspekcji; kod stosowany tylko w przypadku inspekcji; nie należy go stosować w odniesieniu do prac (naprawczych/budowlanych). Mogą istnieć ograniczenia wynikające z obecności pojazdów/koszy służących do inspekcji lub rusztowań

Wodowanie

Ogłoszenie o tym, że statek opuszcza dok

Miejscowe przepisy ruchu statków

Serwis informacyjny dotyczący uzupełniających lub zmienionych przepisów obowiązującego prawa lub regulacji bez specjalnych ograniczeń, dat dotyczących ograniczeń ani okresów obowiązywania

Niski stan wody

Ogłoszenie o niskim stanie wody przed osiągnięciem stanu wody uniemożliwiającego żeglugę

Spadek poziomu wody

Ogłoszenie o kontrolowanym spadku poziomu wody ze względu na prowadzone inspekcje lub prace lub z przyczyn związanych z gospodarką wodną.

Minimalne śluzowanie

Ogłoszenie o niższym niż zwykle tempie spuszczania wody przez jazy i śluzy z przyczyn związanych z gospodarką wodną

Nowy obiekt

Ogłoszenie zawierające informacje o nowym dostępnym obiekcie np. moście, stanowisku cumowniczym

Przeszkoda

Ogłoszenie o ograniczonej wysokości w świetle lub o ograniczonej szerokości szlaku żeglownego ze względu na przeszkodę znajdującą się powyżej poziomu wody

Przeszkoda podwodna

Ogłoszenie o ograniczonej głębokości użytkowej lub o ograniczonej szerokości szlaku żeglownego ze względu na przeszkodę znajdującą się pod wodą

Stan wody uniemożliwiający żeglugę

Ogłoszenie o stanie wody (wysokim lub niskim), który uniemożliwia żeglugę

Pokrycie radiowe

Ogłoszenie dotyczące pokrycia radiowego

Usuwanie obiektu

Ogłoszenie o usuwanych obiektach

Prace remontowe

Ogłoszenie w sytuacji, gdy jakiś obiekt jest zepsuty lub źle funkcjonuje i wymaga naprawy np. system kontroli śluzy – można je również wykorzystać w związku z zaplanowanymi naprawami

Wzrost stanu wody

Ogłoszenie o naturalnym wzroście stanu wody, który nie wynika z gospodarki wodnej

Mielizna

Ogłoszenie o ograniczeniu głębokości użytkowej ze względu na mieliznę

Pomiary głębokości

Ogłoszenie o pomiarach głębokości

Znaki specjalne

Ogłoszenie o stosowaniu specjalnych znaków np. w celu odcięcia dostępu do obszarów wodnych lub łowisk

Transport specjalny

Ogłoszenie o transportach specjalnych

Strajk

Ogłoszenie dotyczące strajku pracowników obsługi, który ma wpływ na dostępność infrastruktury na drogach wodnych

Stan wody wymagający ostrzeżenia nawigacyjnego

Ogłoszenie o stanie wody (wysokim lub niskim), który wymaga zachowania szczególnej ostrożności podczas żeglugi

Prace

Ogłoszenie o prowadzeniu ogólnych prac przy obiektach, na brzegu lub na dnie drogi wodnej (na rzekach lub kanałach)

Ograniczenia

Stosuje się wyłącznie w celu wskazania istniejących ograniczeń, jeżeli żaden inny kod przyczyny nie ma zastosowania

Inne

Nie stosuje się – jeżeli żaden kod przyczyny nie odpowiada sytuacji, nie wprowadza się kodu przyczyny

4.3. Limitation_code:

Definicja stosowania kodów ograniczeń:

— Blokada:

— Jeżeli nie jest możliwa żadna forma żeglugi:

— — przez komorę śluzy,

— przez otwarcie mostu,

— przez podany punkt na szlaku żeglownym,

— na podanym odcinku szlaku żeglownego.

— Częściowe zamknięcie:

— Wszystkie elementy infrastruktury (np. komory śluzy, otwarcia mostów) muszą posiadać własne ISRS Location Code. Jeżeli wciąż brak takich kodów, można zastosować kod częściowego zamknięcia w przypadku gdy żegluga jest możliwa w ograniczonym zakresie (np. w przypadku śluzy posiadającej dwie równoległe komory – tylko dostępny obiekt w obszarze śluzy):

— — przez jedną lub większą liczbę komór danej śluzy, przy czym co najmniej jedna komora pozostaje otwarta,

— przez jeden lub większą liczbę otwartych mostów, przy czym co najmniej jeden most jest otwarty.

— Usługa niedostępna:

— stosuje się, jeżeli ruchomy most nie jest obsługiwany w danym okresie. Okres ten powinien przypadać na normalne godziny pracy.

— Brak usługi w przypadku ruchomego mostu oznacza, że przepłynięcie pod mostem jest wciąż możliwe. Inaczej kwalifikuje się jako „Blokada”. W przypadku śluzy brak usługi koduje się jako „Blokada”.

— Usługa ograniczona:

— stosuje się, jeżeli normalny czas pracy obiektów (np. śluz, (ruchomych) mostów) uległ zmianie, został wydłużony lub ograniczony.

— Jeżeli istnieją ograniczenia dotyczące dozwolonych wymiarów statku/zestawu (bez bezpośredniego związku z infrastrukturą), ograniczenie koduje się za pomocą następujących elementów tekstowych:

— — Zanurzenie statku,

— Szerokość statku,

— Szerokość zestawu,

— Długość statku,

— Długość zestawu,

— Wysokość statku nad powierzchnią wody.

— Należy przedstawić wartość bezwzględną, jeżeli jest dostępna.

— Jeżeli istnieją ograniczenia dotyczące wielkości użytkowej obiektu lub odcinka drogi wodnej, stosuje się następujące kody:

— — Wysokość w świetle,

— Długość użytkowa,

— Szerokość w świetle,

— Głębokość użytkowa.

— Należy przedstawić wartość bezwzględną, jeżeli jest dostępna.

— Najmniejsza zmierzona głębokość: stosuje się, jeżeli głębokość wody może powodować problemy (np. w wyniku zamulenia). Należy przedstawić wartość głębokości bezwzględnej (w stosunku do wartości odniesienia) lub ograniczenia głębokości. Należy przedstawić wartość bezwzględną, jeżeli jest dostępna.

— Opóźnienie: stosuje się, jeżeli przy obiekcie lub na odcinku drogi wodnej między określoną datą rozpoczęcia i zakończenia pojawiła się przeszkoda lub miał miejsce incydent o ograniczonym czasie trwania.

— Należy zakodować szacowany maksymalny czas występowania przeszkody/incydentu. Opóźnienia nie należy stosować w przypadkach, kiedy nie ma dostępu do jednej z kilku komór śluzy.

— Jeżeli określone manewry lub działania są zakazane, należy zakodować odpowiadające im ograniczenia. Takie ograniczenia koduje się tylko wówczas, gdy nie zostały jeszcze ogłoszone za pomocą znaków nawigacyjnych lub przepisów, które zakodowano w oficjalnym ENC śródlądowym.

— — Minimalna moc napędu,

— Ruch naprzemienny,

— Zakaz zawracania,

— Zakaz wymijania,

— Zakaz wyprzedzania,

— Zakaz cumowania do nadbrzeża,

— Zakaz cumowania np do dalb,

— Zakaz kotwiczenia,

— Zakaz tworzenia fal,

— Ograniczenie prędkości,

— Brak pozwolenia wejścia na ląd.

— Należy przedstawić wartości bezwzględne ograniczenia prędkości i minimalnej mocy napędu, jeżeli są dostępne.

— Szczególna ostrożność: w przypadkach gdy FTM (lub jego część) odnosi się do szlaku żeglownego / drogi wodnej, ograniczenie to stosuje się w celu wskazania na szlaku żeglownym / rzece / kanale / jeziorze położenia, w którym zdarzył się incydent.

— Ponadto stosuje się je, w przypadkach gdy nie można szczegółowo opisać ograniczenia, ale gdy przydatne lub niezbędne jest ostrzeżenie lub poinformowanie kierowników statków, że muszą zachować ostrożność i zwracać uwagę na informacje nadawane przez radio.

— Koniec ograniczeń: stosuje się tylko w przypadku jednoznacznego stwierdzenia, że w danym okresie nie ma żadnych ograniczeń.

4.4. Interval_code dotyczący ograniczeń:Definicja stosowania kodów przedziałów czasu:

— „Ciągłe”: stosuje się w przypadku ograniczeń, które mają zastosowanie nieprzerwanie od daty/godziny rozpoczęcia do daty/godziny zakończenia (np. blokada od 01.01.2016, godz. 00.00 do 31.03.2016, godz. 23.59, ale również blokada w dniu 17.09.2016 od godz. 08.00 do godz. 18.00).

— „Codziennie”: stosuje się w przypadku regularnie powtarzającego się ograniczenia (np. zakaz tworzenia fal podczas godzin pracy na obszarze, który jest pogłębiany – 07.04.2016–11.04.2016, codziennie w godzinach 06.00–18.00).

— W porze dziennej (zdefiniowanej w CEVNI): Termin „dzień” oznacza okres między wschodem i zachodem słońca.

— W porze nocnej (zdefiniowanej w CEVNI): Termin „noc” oznacza okres między zachodem i wschodem słońca.

— Dni tygodnia: w przypadku przedziałów czasu dotyczących poszczególnych dni tygodnia, wybiera się je spośród następujących elementów tekstowych:

— — poniedziałek,

— wtorek,

— środa,

— czwartek,

— piątek,

— sobota,

— niedziela,

— od poniedziałku do piątku,

— sobota i niedziela.

— „W przypadku ograniczonej widoczności”: stosuje się, jeżeli ograniczenie obowiązuje tylko w warunkach, w których widoczność jest ograniczona z powodu mgły, przymglenia, śniegu, deszczu lub innych przyczyn.

— „Z wyjątkiem”: nie wolno stosować; przerwane przedziały czasu muszą być podane jako oddzielne okresy obowiązywania ograniczenia w ramach jednego ograniczenia. Wynika to stąd, że oprogramowanie służące do planowania podróży nie jest w stanie poprawnie zinterpretować tego kodu jako „nie mające miejsca w danym dniu lub w danym czasie”. Tym samym nie ma możliwości obliczenia poprawnych przewidywanych czasów przybycia.

— „Od poniedziałku do piątku z wyjątkiem świąt”: stosuje się jedynie w przypadku, gdy w okresie obowiązywania ograniczenia występują dni ustawowo wolne od pracy. Dni ustawowo wolne od pracy można w ramach usługi dla użytkowników podać w sekcji tekstu dowolnego FTM. Oprogramowanie służące do planowania podróży nie będzie w stanie uwzględnić dni ustawowo wolnych od pracy w obliczaniu przewidywanych czasów przybycia.

4.5. Indication_code:

Indication_code jest przeznaczony do stosowania w przypadku podawania informacji o określonych wartościach związanych z niektórymi ograniczeniami (np. ograniczeniem prędkości, minimalną mocą napędu, głębokością użytkową). Aby określić niektóre wymiary, konieczne jest odesłanie do zewnętrznego układu odniesienia (geograficznego lub hydrologicznego) (np. wysokość w świetle, głębokość użytkowa, najmniejsza zmierzona głębokość), albo odniesienie względem znanych wymiarów sztucznych struktur (np. długości użytkowej, szerokości w świetle).

4.5.1. Należy podawać wymiary lub odniesienia bezwzględne, jeżeli są znane. Wartości względne można wykorzystać tylko wtedy, gdy nie istnieje możliwość odesłania do zewnętrznego układu odniesienia.

4.5.2.

ograniczenie o (wartość)

→ jest to wartość względna

4.5.3.

maksimum

→ jest to wartość bezwzględna

4.5.4.

minimum

→ jest to wartość bezwzględna

4.5.5. Jeżeli dany wymiar wskazujący ograniczenie zawiera odniesienie do współrzędnej geograficznej lub hydrologicznej, należy wskazać odpowiedni układ odniesienia w komunikacie NtS (np. wysokość w świetle min. 4 m odniesiona do najwyższego stanu wody dopuszczającego żeglugę; głębokość użytkowa min. 1,7 m odniesiona do regulowanego niskiego stanu wody)

4.5.6. Jeżeli dany wymiar wskazujący ograniczenie zawiera odniesienie do sztucznej struktury (np. mostu, śluzy), odniesienie to można podać względem znanych wymiarów (np. wysokość w świetle zmniejszona o 1,5 m, długość użytkowa zmniejszona o 27 m).

4.6. Position_code (obiekty):

W miarę możliwości position_code musi zawierać odniesienie do tej strony szlaku żeglownego, po której obiekt znajduje się względem osi szlaku żeglownego (po lewej / pośrodku / po prawej) lub innych powszechnie znanych informacji (stary/nowy) lub kierunku geograficznego (północ/południe/wschód/zachód). W przypadku obiektów position_code może wcześniej zostać automatycznie wypełniony z zastosowaniem danych referencyjnych z RIS Index. Lewą/prawą stronę szlaku żeglownego określa się patrząc w dół rzeki.

4.7. Position_code (szlaki żeglowne/drogi wodne):

Nie podaje się position_code w przypadku FTM (lub jego części), który odnosi się do szlaku żeglownego lub drogi wodnej. Aby wskazać, po której stronie szlaku żeglownego / kanału / rzeki / jeziora wydarzył się incydent, stosuje się ograniczenie „szczególna ostrożność” w połączeniu z odpowiednim position_code dotyczącym ograniczenia.

4.8. Position_code (ograniczenia):

4.8.1. W miarę możliwości position_code musi zawierać odniesienie do tej strony szlaku żeglownego lub obiektu, po której występuje ograniczenie (po lewej / po prawej). Lewą/prawą stronę szlaku żeglownego określa się patrząc w dół rzeki.

4.8.2. Position_code kieruje uwagę kierownika statku na stronę szlaku żeglownego, po której znajduje się np. obszar szczególnego zainteresowania, niebezpieczeństwo lub przeszkoda. W związku z tym ogólne wskazanie (np. lewy brzeg – po lewej – pośrodku – po prawej – prawy brzeg) jest wystarczające. Stosowanie dokładniejszego podziału nie jest przewidziane.

4.8.3. W razie konieczności bardziej precyzyjne informacje o położeniu najlepiej podawać za pomocą map lub rysunków (załącznik, zob. rozdział 3.6)

4.8.4. W przypadku odcinków, na których zwykłe wskazywanie położenia polegające na podaniu strony szlaku żeglownego (po lewej / po prawej) nie wydaje się być odpowiednie (np. w basenach portowych, na niektórych odcinkach kanałów, gdzie nie ma wyraźnego rozróżnienia kierunku prądu), można wykorzystać punkty kardynalne (północ/wschód/południe/zachód).

4.9. Target_group_code (zob. rozdział 3.5)

4.10. Reporting_code

4.10.1. Reporting_code stosuje się zasadniczo tylko w przypadku wyjątkowych potrzeb komunikacyjnych (np. obowiązek dodatkowego meldowania miejscowym władzom zgodnie z miejscowymi przepisami dotyczącymi ruchu) lub w przypadku gdy dostępne są dodatkowe informacje (np. punkt kontaktowy VHF, taki jak nazwa kanału lub sygnał wywoławczy dotyczący aktualnego położenia pogłębiarki), które są bezpośrednio związane z FTM.

4.10.2. Należy unikać rutynowego powtarzania powszechnie dostępnych danych komunikacyjnych (np. numerów telefonów miejscowych władz, kanałów VHF używanych przez śluzy itp.), jeżeli nie ma bezpośredniego powodu dla takiej komunikacji w odniesieniu do FTM.

4.10.3. Zasadniczo w reporting_code nie powtarza się informacji o środkach komunikacji mających ogólne zastosowanie zgodnie z oficjalnymi przepisami (np. komunikacja VHF w relacji statek–statek lub statek–brzeg, jak określono w CEVI lub regionalnych lub krajowych przepisach żeglugowych), jeżeli nie ma bezpośredniego powodu dla takiej komunikacji w odniesieniu do FTM.

4.11. Communication_code

stosuje się następujący format (przykłady):

— VHF „numer, sygnał wywoławczy”: „10, Schifffahrtsaufsicht Wien”

— Numer telefonu lub faksu: „+43123456789, Schifffahrtsaufsicht Wien”

— Adres strony internetowej: „http://example.com”

— Sygnalizacja dźwiękowa: „długi dźwięk / langer Ton”

— E-mail: „example@authority.eu”

— Numer skrzynki pocztowej EDI: „900012345@edi.bics.nl”

— Teletekst: „ARD, 992 – 995”

4.12. Type_code:

Droga wodna to kanał, jezioro albo rzeka.

— Kotwicowisko

— Brzeg

— Stawa

— Miejsce postoju

— Kontrola graniczna

— Most

— Otwieranie mostu

— Boja

— Kabel napowietrzny

— Kanał (termin „kanał” stosuje się, jeżeli komunikat dotyczy całego kanału, a nie tylko szlaku żeglownego)

— Most kanałowy: akwedukt

— Przepust

— Szlak żeglowny (termin „szlak żeglowny” oznacza tę część drogi wodnej, którą można faktycznie wykorzystać do ruchu statków).

— Prom

— Dok pływający

— Śluza (śluzę wykorzystuje się do ochrony danego obszaru w sytuacjach wysokiego stanu wody)

— Port

— Obiekt portowy

— Kapitanat portu

— Jezioro (termin „jezioro” stosuje się, jeżeli komunikat dotyczy całego jeziora, a nie tylko szlaku żeglownego)

— Światło

— Komora śluzy: pojedyncza komora śluzy

— Śluza: cały kompleks śluzy

— Cumowisko

— Znak informacyjny

— Rurociąg

— Rurociąg napowietrzny

— Pochylnia

— Wysypisko śmieci

— Punkt meldunkowy

— Zbiornik

— Rzeka (termin „rzeka” stosuje się, jeżeli komunikat dotyczy całej rzeki, a nie tylko szlaku żeglownego)

— Podnośnik dokowy

— Stocznia

— Stacja sygnalizacyjna

— Terminal

— Wodowskaz

— Tunel

— Obrotnica

— Centrum ruchu statków

— Jaz (jazy wykorzystuje się do regulowania stanu wody w rzekach)

5. Podstawowe kwestie związane z WRM

Komunikaty dotyczące stanu wody muszą być zasadniczo generowane automatycznie. Jeżeli nie ma takiej możliwości, proces ręcznego generowania WRM przebiega w sposób jak najbardziej zbliżony do ustalonych procesów automatycznego generowania WRM (zob. NtS Encoding Guide dla deweloperów).

6. Podstawowe kwestie związane z ICEM, etapy poprzedzające publikację ICEM

Komunikaty o lodzie są zależne od lokalnej obserwacji i oceny i zazwyczaj są generowane przez uprawniony do tego personel.

ICEM wydaje się w przypadku pojawienia się lodu. Lód niekoniecznie musi powodować ograniczenia żeglugi, można jednak podawać informacje na temat stanu lodu, który nie zakłóca żeglugi.

6.1. Czy istnieje potrzeba publikacji informacji z zastosowaniem NtS ICEM?

Pierwszy komunikat o lodzie dotyczący danego odcinka publikuje się jedynie w przypadku wystąpienia lodu na drodze wodnej lub w dopływie oraz w sytuacji, gdy nie obowiązują żadne ograniczenia.

6.2. Czy istnieje już obowiązujący ICEM dotyczący odcinka drogi wodnej, na którym występuje lód?

6.2.1. Tak:

jeżeli komunikat dotyczący odcinka z lodem (wciąż) obowiązuje, aktualizuje się już istniejący komunikat. Istnieje możliwość aktualizacji istniejącego komunikatu o lodzie, nawet jeżeli odcinek, do którego ma on zastosowanie, ulegnie zmianie (np. lód się rozprzestrzenia, zwiększając rozmiar odcinka, na którym występuje).

6.2.2. Nie:

jeżeli nie ma obowiązującego komunikatu o lodzie dotyczącego odcinka z lodem, należy utworzyć nowy komunikat.

6.3. można jednak podawać informacje na temat stanu lodu, który nie zakłóca żeglugi.

6.4. Jeden ICEM zawsze obowiązuje w odniesieniu do pojedynczego odcinka drogi wodnej. Należy ustalić geograficzny zakres obowiązywania, określając w tym celu drogę wodną i odpowiednie punkty (hektometry) początkowe i końcowe (lub wskazując określone następujące po sobie odcinki, w zależności od krajowego wdrożenia aplikacji).

6.5. Należy wprowadzić czas pomiaru. Odpowiednie informacje na temat stanu lodu należy wprowadzić wykorzystując co najmniej jedną z list kodowych (zależnie od krajowych wymogów).

6.5.1. Ice_condition_code

6.5.2. Ice_accessibility_code

6.5.3. Ice_classification_code

6.5.4. Ice_situation_code (należy zawsze podawać kod sytuacji związanej z lodem, aby umożliwić odtworzenie tej sytuacji na mapie z zastosowaniem kolorów „sygnalizacji świetlnej”).

6.6. ICEM może zostać opublikowany. Komunikaty o lodzie automatycznie obowiązują do następnego dnia po publikacji albo do momentu określonego procedurami krajowymi.

7. Podstawowe kwestie związane z WERM

Z uwagi na ogromną ilość dostępnych usług internetowych i aplikacji dostarczających prognozy pogody i ostrzeżenia pogodowe, WERM należy stosować jedynie w celu przekazania informacji pogodowych, które są szczególnie ważnie dla żeglugi i które nie są uwzględniane w ogólnych usługach informacji pogodowej.

Komunikaty pogodowe muszą być zasadniczo generowane automatycznie. Jeżeli nie ma takiej możliwości, proces ręcznego generowania WERM przebiega w sposób jak najbardziej zbliżony do ustalonych procesów automatycznego generowania komunikatów pogodowych (zob. NtS Encoding Guide dla deweloperów aplikacji).

8. Przepisy dotyczące pewnych elementów

8.1.

Przepisy dotyczące elementu „name” związanego z obiektami

Nazwy obiektów są zazwyczaj automatycznie wprowadzane przez narzędzie edytorskie NtS w oparciu o dane referencyjne z RIS Index. Nazwy należy wprowadzać w języku miejscowym, można więc również używać np. znaków diakrytycznych lub cyrylicy. (np. Baarlerbrücke, Volkeraksluis lub Mannswörth).

Należy pominąć informacje dotyczące cech charakterystycznych obiektu, a rodzaju obiektu nie należy powtarzać w jego nazwie, chyba że dzięki temu podaje się dodatkowe informacje na temat rodzaju obiektu.

Np.: w przypadku śluzy „Schleuse Freudenau” używa się jedynie nazwy „Freudenau”, ponieważ rodzaj obiektu „śluza” dodano automatycznie w oparciu o type_code.

Np.: nazwa obiektu dla mostu kolejowego w Krems (AT) to „Eisenbahnbrücke Krems”. Informację „most kolejowy” dołączono do nazwy obiektu, ponieważ zapewnia dodatkową informację poza informacją „most”, którą zakodowano w type_code.

Np.: nazwa obiektu dla mostu w Linz (AT) to „Nibelungenbrücke”. Słowo „brücke” pozostaje częścią nazwy obiektu, ponieważ jest częścią nazwy samego mostu.

Np.: wodowskaz „Pegelstelle Wildungsmauer” jest nazywany „Wildungsmauer” ponieważ informacja o tym, że obiekt jest wodowskazem, została już zakodowana w type_code.

Jeżeli odcinek drogi wodnej stanowi linię graniczną między dwoma państwami używającymi innych języków, krajową nazwę obiektu można przedstawić w obu językach (np. „Staatsgrenze AT-SK / Statna hranica AT-SK”).

8.2.

Przepisy dotyczące elementu „name” związanego ze szlakami żeglownymi

Nazwy szlaków żeglownych są zazwyczaj automatycznie wprowadzane przez narzędzie edytorskie NtS w oparciu o dane referencyjne z RIS Index. Pole „name” zawiera miejscową nazwę odpowiednich odcinków szlaku żeglownego (np. „Rhein”). W zależności od krajowych procesów może istnieć możliwość edycji nazwy szlaku żeglownego w celu uwzględnienie powszechnie używanych miejscowych nazw lub dodatków (np. „Rhein am Deutschen Eck”).

8.3.

Przepisy dotyczące elementów „value” i „unit” w ramach ograniczeń

O ile nie określono inaczej, jedyne jednostki, które można stosować w komunikatach NtS to: cm, m3/s, h, km/h i kW, m/s (wiatr), mm/h (opady deszczu) oraz stopnie Celsjusza.

NOTICES TO SKIPPERS ENCODING GUIDE DLA DEWELOPERÓW APLIKACJI

SPIS TREŚCI

1. Kontekst i struktura

1.1.

Cel NtS Encoding Guide

1.1.1.

NtS Encoding Guide dla edytorów

1.1.2.

NtS Encoding Guide dla deweloperów aplikacji (niniejszy dokument)

2. Komunikaty NtS i ich sekcje

3. Podstawowe kwestie związane z WRM

3.1.

Wypełnianie sekcji nts_number w WRM

3.2.

Wypełnianie WRM, w tym prognoz

4. Procesy dotyczące ICEM

4.1.

Nowy ICEM

4.2.

Aktualizacja istniejącego ICEM

5. Podstawowe kwestie związane z WERM

5.1.

Wypełnianie sekcji nts_number w WERM

5.2.

Wypełnianie „weather_category_code” w WERM

6. Procesy dotyczące FTM

6.1.

Nowy FTM

6.2.

Aktualizacja/odwołanie istniejącego FTM

6.3.

FTM dotyczący drogi wodnej lub obiektu

6.4.

Automatyczne uszeregowanie kodów ograniczeń

6.5.

Postępowanie z okresami obowiązywania ograniczeń

7. Ogólne przepisy dotyczące wdrożenia

7.1.

Wypełnianie „number_section”

7.2.

Wypełnianie elementów „from”, „originator”, „organisation” i „source”

7.3.

Pomijanie elementów

7.4.

Automatyczne wypełnianie date_issue

7.5.

Postępowanie z informacjami o strefach czasowych w komunikatach NtS

7.6.

Stosowanie sekund w komunikatach NtS

7.7.

Format znaku oddzielającego części dziesiętne w komunikatach NtS

7.8.

Jednostki, które należy stosować w komunikatach NtS

7.9.

Przepisy dotyczące elementów „name”, „position_code” oraz „type_code”

7.10.

Przepisy dotyczące elementu „fairway_name”

7.11.

Wyjaśnienia dotyczące tłumaczeń w arkuszu „reference_code”

7.12.

Zalecenie dotyczące elementu „coordinate”

7.13.

Postępowanie z grupami odbiorców

7.14.

Wyświetlanie obowiązujących komunikatów w danym czasie

7.15.

Funkcje fakultatywne ułatwiające obsługę narzędzi edytorskich NtS

8. Struktura komunikatów NtS w formacie XML

9. NtS Web Service

9.1.

Cel

9.2.

Podstawowe zasady i ograniczenia

9.2.1.

Standardy sieciowe

9.2.2.

Model interakcji i metoda kodowania NtS WS

9.3.

Ogólne specyfikacje i zalecenia

9.3.1.

Specyfikacja: Informacje na temat wersji

9.3.2.

Specyfikacja: Struktura przestrzeni nazw

9.3.3.

Zalecenie: Stosowanie przestrzeni nazw

9.3.4.

Zalecenie: Stosowanie prefiksów przestrzeni nazw

9.3.5.

Specyfikacja: Stosowanie ISRS Location Code

9.4.

Usługa obsługująca komunikaty NtS (specyfikacja wdrażania)

9.4.1.

Zapytanie

9.4.2.

Odpowiedź

9.5.

Generowanie usługi i klientów

Glosariusz

1. Kontekst i struktura

Komunikaty dla kierowników statków (NtS) wdrażano w szeregu państw europejskich w oparciu o rozporządzenie Komisji (WE) nr 416/2007 dotyczące specyfikacji technicznych komunikatów dla kierowników statków, o których mowa w art. 5 dyrektywy 2005/44/WE w sprawie RIS. Standard NtS jest stale ulepszany – istotnym krokiem naprzód było uruchomienie NtS Web Service która ułatwia wymianę komunikatów NtS między poszczególnymi organami, jak również między organami a użytkownikami NtS, a także usprawnienie kodowania komunikatów NtS w oparciu o XSD dla NtS w wersji 4.0.

1.1.

Cel NtS Encoding Guide

W NtS Encoding Guide objaśniono zastosowanie czterech rodzajów komunikatów NtS, jak również kody, których należy użyć w przypadku wystąpienia określonych zdarzeń. Na użytek edytorów NtS przedstawiono w nim instrukcje wypełniania komunikatów NtS, co umożliwia kodowanie komunikatów NtS zharmonizowane na szczeblu krajowym i międzynarodowym.

Przez wzgląd na zwiększone wykorzystanie NtS Web Service należy w większym stopniu zharmonizować komunikaty NtS, aby zapewnić poprawne wyświetlanie treści w systemach należących do osób trzecich. Jednolite kodowanie komunikatów stanowi również warunek wstępny uwzględnienia komunikatów w aplikacjach służących do planowania podróży. NtS Encoding Guide w wersji 1.0 ma zastosowanie do XSD dla NtS w wersji 4.0 oraz NtS Web Service WSDL 2.0.4.0.

1.1.1.

NtS Encoding Guide dla edytorów

NtS Encoding Guide dla edytorów jest przeznaczony dla personelu, który redaguje (i publikuje) komunikaty NtS, i zawiera instrukcje opisujące krok po kroku tworzenie odpowiednich rodzajów komunikatów, jak również objaśnienie kodów. NtS Encoding Guide dla edytorów zawiera również informacje istotne dla deweloperów aplikacji.

1.1.2.

NtS Encoding Guide dla deweloperów aplikacji (niniejszy dokument)

NtS Encoding Guide dla deweloperów zawiera wytyczne dotyczące wdrażania aplikacji do obsługi NtS, a także objaśnienie logiki, procesów oraz wartości automatycznych/domyślnych.

2. Komunikaty NtS i ich sekcje

Komunikat NtS składa się z następujących części:

— sekcja identyfikacyjna,

— sekcja określająca odpowiednie obiekty lub odcinki szlaku żeglownego, do których odnosi się dany komunikat,

— co najmniej jedna z następujących sekcji, w zależności od rodzaju komunikatu:

— — ograniczenie(-a) w przypadku komunikatu dotyczącego szlaku żeglownego i ruchu,

— pomiar(-y) w przypadku komunikatu dotyczącego stanu wody,

— stan lodu w przypadku komunikatu o lodzie,

— raport pogodowy / raporty pogodowe w przypadku komunikatu pogodowego.

Rysunek 2

Wizualizacja struktury wiadomości NtS: element obowiązkowy (1); element obowiązkowy, który może wystąpić raz lub dwa razy (1…2); element obowiązkowy, który musi wystąpić dwa razy (2); element obowiązkowy, który może występować dowolną ilość razy, w zależności od potrzeb (1-n); element fakultatywny, który może występować dowolną ilość razy, w zależności od potrzeb (0…n)

Sekcja identyfikacyjna jest obowiązkowa i zawiera ogólne informacje na temat autora, nadawcy, daty wydania, kraju i języka oryginalnego i jest dostarczana łącznie z jednym z czterech poszczególnych rodzajów sekcji komunikatu NtS:

— Fairway and traffic related section: „Komunikat dotyczący szlaku żeglownego i ruchu” (FTM) przygotowują zazwyczaj edytorzy NtS zgodnie z NtS Encoding Guide dla edytorów. Dotyczy on odcinków dróg wodnych (określonych ISRS Location Code ich początku i końca) lub obiektów znajdujących się na drodze wodnej określonych ich odpowiednim ISRS Location Code. [przejdź do rozdziału 6]

— Water level related section: „Komunikat dotyczący stanu wody” (WRM) umożliwia przekazanie informacji na temat obecnego i prognozowanego stanu wody, jak również innych informacji. WRM zazwyczaj są tworzone automatycznie (i okresowo) w oparciu o pomiary z czujników lub stan infrastruktury i nie wymagają interakcji ze strony edytora NtS. Sekcja komunikatu dotyczącego stanu wody zawiera informacje na temat obiektu (np. stacji pomiarowej) lub odcinka szlaku żeglownego (np. głębokość minimalna na danym odcinku, obowiązujący reżim na danym odcinku drogi wodnej). Obiekt identyfikuje się za pomocą ISRS Location Code, odcinek szlaku żeglownego określa się za pomocą ISRS Location Code jego początku i końca. [przejdź do rozdziału 3]

— Ice related section: „Komunikat o lodzie” (ICEM) zawiera informacje na temat stanu lodu na odcinku szlaku żeglownego określonego poprzez podanie ISRS Location Code jego początku i końca. [przejdź do rozdziału 4]

— Weather related section: „Komunikat pogodowy” (WERM) umożliwia przekazanie informacji na temat obecnych i prognozowanych warunków pogodowych na danym odcinku drogi wodnej określonym poprzez podanie ISRS Location Code jego początku i końca. [przejdź do rozdziału 5]

Ponadto ISRS (ang. International Ship Reporting Standard, międzynarodowy standard meldowania statków) Location Code stosuje się w celu określenia stosownych obiektów lub odcinków szlaku żeglownego, do których odnosi się dany komunikat.

ISRS Location Code określono w pkt 4.3 załącznika do niniejszego rozporządzenia.

3. Podstawowe kwestie związane z WRM

Informacje o stanie wody są bardzo ważne zarówno dla planowania podróży, jak i dla bezpieczeństwa. Obecnie nie ma wspólnego standardu odniesień dla informacji o stanie wody. Wartości wskazywane przez mierniki odnoszą się do różnych poziomów morza albo do specjalnych punktów odniesienia. Aby podać właściwe odniesienie, zawsze podaje się odpowiedni „reference_code” wraz z wartością. WRM można wykorzystać do przekazania następujących informacji:

— Stanu wody (w tym prognoz),

— Głębokości minimalnej (w tym prognoz),

— Prześwitu pionowego (w tym prognoz),

— Spustu (w tym prognoz),

— Stanu zapory,

— Reżimu.

Wyjaśnienia tłumaczeń w akruszu „reference_code” przedstawiono w rozdziale 7.11.

WRM jest zazwyczaj tworzony i publikowany automatycznie w oparciu o informacje otrzymane z czujników lub informacje otrzymane z infrastruktury (np. prognozy, stan zapory). WRM może zostać opublikowany z różnych przyczyn – w ramach publikacji okresowej lub po osiągnięciu określonej wartości.

3.1.

Wypełnianie sekcji nts_number w WRM

W XSD dla NtS w wersji 4.0 wprowadzenie numeru NtS w WRM jest fakultatywne. Jeżeli podaje się numer, musi on być w każdym przypadku niepowtarzalny (Organisation/Year/Number/Serial) dla danego rodzaju komunikatu, a zapewnienie używania niepowtarzalnych numerów leży w gestii organu wydającego WRM(nie jest wymagane stosowanie numerów kolejnych).

3.2.

Wypełnianie WRM, w tym prognoz

Jako date_start w polu validity_period należy wprowadzić datę bieżącą (date_issue), a jako date_end w polu validity_period należy wprowadzić datę następnego dnia po date_issue.

Aby przedstawić zmiany dotyczące np. stanu wody w sposób przyjazny dla użytkownika, można w sekcji dotyczącej różnic w WRM podać różnicę w stosunku do wartości poprzedniego pomiaru porównawczego. Poza zmianą wartości (np. - 5 [cm]) należy również przedstawić różnicę czasu w stosunku do pomiaru porównawczego.

W przypadku prognoz „measure_date” oznacza datę/godzinę, dla których prognoza obowiązuje.

Prognozy stanu wody zawsze zawierają czynnik niepewności. Zazwyczaj przeprowadza się obliczenia na modelach o różnych parametrach (np. prognoza pogody), co prowadzi do różnych prognozowanych wartości stanu wody. W sekcji „pomiar” w WRM zawarto dwa dodatkowe opcjonalne pola danych, aby umożliwić podanie minimalnej i maksymalnej prognozowanej wartości np. wizualizację przedziału ufności prognozy stanu wody.

Na poniższym rysunku zobrazowano przedział ufności prognozy stanu wody:

Rysunek 3

Wizualizacja przedziału ufności prognozy stanu wody: wartość najbardziej prawdopodobna (kolor czarny), górna granica przedziału ufności (kolor fioletowy), dolna granica przedziału ufności (kolor czerwony), zmierzony stan wody (kolor niebieski)

(Oś x obrazuje czas, oś y obrazuje stan wody w cm)

W XSD dla NtS dostępne są dwa elementy:

<value_min> najniższa wartość przedziału ufności

<value_max> najwyższa wartość przedziału ufności

Poza prognozowanym stanem wody przedział ufności można również wykorzystać do przedstawienia niepewności opublikowanych informacji na temat głębokości minimalnej i prześwitu pionowego.

Dzięki value_min i value_max przedziału ufności można przedstawić przedział ufności dotyczący wartości WRM za pośrednictwem ustandaryzowanego komunikatu NtS WRM w celu wykorzystania go w wykresach. Nieprzetworzonych danych nie należy udostępniać osobom korzystającym z transportu wodnego śródlądowego (np. w formacie kodów).

Nie wolno stosować Measure_code „NOM”. Jeżeli brak jest pomiarów na potrzeby określonych rodzajów WRM, a komunikat ma zostać mimo to wysłany, należy pominąć elementy dotyczące wartości.

4. Procesy dotyczące ICEM

Komunikaty o lodzie uzależnione są od lokalnej obserwacji, oceny i zazwyczaj są generowane ręcznie (w przypadku generowania automatycznego należy przestrzegać zasad tworzenia ręcznego, zob. NtS Encoding Guide dla edytorów).

ICEM publikowany jest w odniesieniu do konkretnego fairway_section określonego poprzez podanie ISRS Location Code jego początku i końca oraz zawiera ice_condition w konkretnej dacie pomiaru.

ICEM obowiązuje od daty publikacji (automatycznie ustawianej przez aplikację do obsługi NtS). W celu uniknięcia wyświetlenia użytkownikom ICEM, które już nie obowiązują, aplikacja do obsługi NtS musi automatycznie wprowadzać date_end obowiązywania będącą datą dnia po publikacji (chyba że w procesach krajowych zapewniono, aby komunikaty otrzymywały datę końca obowiązywania z chwilą gdy informacje zawarte w komunikacie przestają być aktualne).

W NtS Encoding Guide dla edytorów opisano okoliczności, w których edytor NtS tworzy nowy ICEM lub aktualizuje już istniejący. Zastosowanie mają następujące procesy:

4.1.

Nowy ICEM

1) Aplikacje do obsługi NtS mogą dawać edytorom NtS możliwość:

a) wykorzystania istniejących komunikatów jako wersji roboczych w momencie tworzenia nowego ICEM (np. jeżeli stan lodu jest zbliżony do opisanego w istniejącym komunikacie) lub

b) wykorzystania szablonów komunikatów dotyczących określonych sytuacji.

2) Edytor wprowadza treść (np. godzinę pomiaru lub odpowiedni stan lodu) zgodnie z rozdziałem 6 NtS Encoding Guide dla edytorów. Data i godzina pomiaru może być również ustawiona przez aplikację zgodnie z definicjami krajowymi.

3) Kiedy edytor / podmioty publikujące uruchomią funkcję publikacji,

a) aplikacja sprawdza, czy podano całą obowiązkową treść zgodnie z XSD dla NtS (jeśli nie, należy wrócić do pkt 2);

b) aplikacja do obsługi NtS generuje nts_number,

(i) w polu „organisation” wprowadzona zostaje nazwa lub kod odpowiedzialnego organu w zależności od roli pełnionej przez użytkownika dokonującego publikacji;

(ii) w polu „year” wprowadzony zostaje bieżący rok;

(iii) przydzielony zostaje kolejny dostępny „number”;

(iv) przydzielony zostaje „numer seryjny” o wartości 0.

c) w polu „date_issue” zostaje automatycznie wprowadzona faktyczna data/godzina uruchomienia funkcji publikacji;

d) w polu „validity_period”’ – „date_start” zostaje automatycznie wprowadzona faktyczna data publikacji;

e) w polu „validity_period” – „date_end” zostaje automatycznie wprowadzona data następnego dnia po publikacji (chyba że procesy krajowe zapewniają, aby komunikaty otrzymywały datę końca obowiązywania z chwilą gdy informacje zawarte w komunikacie przestają być aktualne).

4.2.

Aktualizacja istniejącego ICEM

1) Należy wybrać właściwy opublikowany komunikat w celu aktualizacji w narzędziu edytorskim ICEM. Należy skopiować lub zmodyfikować w bazie danych oryginalny ICEM (w zależności od krajowych procesów). Nie można dokonać aktualizacji ICEM, który wygasł (upłynęła jego validity_date_end) – w takim przypadku edytorzy NtS muszą utworzyć nowy ICEM.

2) Edytor zmienia treść (np. godzinę pomiaru lub odpowiedni stan lodu) zgodnie z rozdziałem 6 NtS Encoding Guide NtS dla edytorów. Data i godzina pomiaru może również zostać zmieniona przez aplikację zgodnie z definicjami krajowymi.

3) Kiedy edytor / podmiot publikujący uruchomi funkcję publikacji,

a) aplikacja sprawdza, czy przedstawiono całą obowiązkową treść zgodnie z XSD dla NtS (jeśli nie, należy wrócić do pkt 2);

b) aplikacja do obsługi NtS generuje nts_number,

(i) „organisation” pozostaje bez zmian;

(ii) „year” pozostaje bez zmian;

(iii) „number” pozostaje bez zmian;

(iv) „serial number” zostaje zwiększony (dodaje się 1);

c) w polu „date_issue” zostaje automatycznie wprowadzona faktyczna data/godzina uruchomienia funkcji publikacji;

d) w polu „validity_period”’ – „date_start” zostaje automatycznie wprowadzona faktyczna data publikacji;

e) w polu „validity_period” – „date_end” zostaje automatycznie wprowadzona data następnego dnia po publikacji (chyba że procesy krajowe zapewniają, aby komunikaty otrzymywały datę końca obowiązywania z chwilą gdy informacje zawarte w komunikacie przestają być aktualne).

5. Podstawowe kwestie związane z WERM

WERM są zazwyczaj tworzone i publikowane automatycznie w oparciu o informacje otrzymane z czujników lub informacje otrzymane z infrastruktury. Jako date_start w polu validity_period należy wprowadzić datę bieżącą (date_issue), a jako date_end w polu validity_period należy wprowadzić datę następnego dnia po date_issue.

Odcinek szlaku żeglownego wskazuje się w WERM jako odcinek między dwoma punktami szlaku żeglownego, tj. obszar, do którego zastosowanie mają pomiary danej stacji pogodowej (wodowskazu).

Należy podać datę i godzinę pomiaru/prognozy, nawet jeżeli nie są to pola obowiązkowe w komunikatach WERM.

W przypadku prognoz „measure date” oznacza datę/godzinę, w odniesieniu do których prognoza obowiązuje.

5.1.

Wypełnianie sekcji nts_number w WERM

W XSD dla NtS w wersji 4.0 wprowadzanie numeru NtS w WERM jest fakultatywne. Jeżeli podaje się numer, musi on być w każdym przypadku niepowtarzalny (Organisation/Year/Number/Serial) dla danego rodzaju komunikatu, a zapewnienie używania niepowtarzalnych numerów leży w gestii organu wydającego WERM (nie jest wymagane stosowanie kolejnych numerów).

5.2.

Wypełnianie „weather_category_code” w WERM

Prędkość wiatru w polu „weather_category_code” (wartości 0–12) podaje się według skali Beauforta opublikowanej przez Światową Organizację Meteorologiczną w Manual on Marine Meteorological Services (Podręcznik morskich służb pogodowych) „WMO-No. 558”.

Widoczność w polu „weather_category_code” (wartości 13–22) podaje się według poniższej tabeli:

Wartość, znaczenie

Widoczność

Informacje dodatkowe

13, gęsta mgła

poniżej 50 metrów

14, bardzo gęsta mgła

poniżej 100 metrów

15, lekka mgła

poniżej 200 metrów

16, mgła

poniżej 1 000 metrów

Mgłę tworzą kropelki wody.

17, mgiełka

1–4 km

Mgiełkę tworzą kropelki wody. Kodu mgiełki używa się w przypadku „suchej mgły”, zjawiska które zazwyczaj ma miejsce przed wschodem słońca.

18, przymglenie

1–4 km

Przymglenie tworzą suche cząsteczki

19, lekkie przymglenie

4–10 km

20, przejrzyście

10–20 km

21, bardzo przejrzyście

brak ograniczeń widoczności

22, brak mgły

„brak mgły” stosuje się w celu stwierdzenia, że nie ma mgły, w zależności krajowych/lokalnych wymogów

6. Procesy dotyczące FTM

W NtS Encoding Guide dla edytorów opisano okoliczności, w których edytor NtS tworzy nowy FTM lub aktualizuje już istniejący. Zastosowanie mają następujące procesy:

6.1.

Nowy FTM

1) Aplikacje do obsługi NtS mogą dawać edytorom NtS możliwość:

a) wykorzystania istniejących komunikatów jako wersji roboczych w momencie tworzenia nowego FTM lub

b) wykorzystania szablonów komunikatów dotyczących określonych sytuacji.

2) Edytor wprowadza treść (np. okres obowiązywania, ograniczenia) zgodnie z rozdziałami 3 i 4 NtS Encoding Guide dla edytorów.

3) Kiedy edytor / podmiot publikujący uruchomi funkcję publikacji,

a) aplikacja sprawdza, czy przedstawiono całą obowiązkową treść zgodnie z XSD dla NtS (jeśli nie, należy wrócić do pkt 2);

b) aplikacja do obsługi NtS generuje nts_number;

(i) w polu „organisation” wprowadzona zostaje nazwa lub kod odpowiedzialnego organu w zależności od roli pełnionej przez użytkownika dokonującego publikacji;

(ii) w polu „year” wprowadzony zostaje bieżący rok;

(iii) przydzielony zostaje kolejny wolny „number”, a jeżeli na etapie 2 edytor NtS lub proces aplikacji wprowadził specjalny numer, przejmuje się ten numer (ponieważ (Organisation/Year/Number/Serial) jest niepowtarzalny, jak wyjaśniono w rozdziale 15.1);

(iv) przydzielony zostaje „numer seryjny” o wartości 0;

c) w polu „date_issue” zostaje automatycznie wprowadzona faktyczna data/godzina uruchomienia funkcji publikacji

6.2.

Aktualizacja/odwołanie istniejącego FTM

1) Odpowiedni opublikowany komunikat należy wybrać w celu aktualizacji w narzędziu edytorskim FTM i skopiować lub zmodyfikować w bazie danych oryginalny FTM (w zależności od krajowych procesów).

a) Nie można dokonać aktualizacji FTM, który wygasł (upłynęła jego validity_date_end) – w takim przypadku edytor NtS musi utworzyć nowy FTM.

b) Kod tematu „Komunikat odwołany” stosuje się tylko wtedy, gdy:

(i) bieżąca data jest wcześniejsza, niż validity_date_start. W takim przypadku może zostać zmieniona jedynie treść zawarta w polu „dodatkowe informacje w języku narodowym”, a zakodowana treść komunikatu (etap 2) musi pozostać niezmieniona;

(ii) okres obowiązywania już się rozpoczął i nowa data końcowa wszystkich ograniczeń jest datą minioną. Data końcowa ograniczenia musi być ustawiona na właściwą godzinę.

c) W przypadku odwołania komunikatu jako datę zakończenia okresu obowiązywania komunikatu należy ustawić datę odwołania.

2) Edytor zmienia treść (np. okres obowiązywania, ograniczenia) zgodnie z rozdziałami 3 i 4 NtS Encoding Guide dla edytorów.

3) Kiedy edytor / podmiot publikujący uruchomi funkcję publikacji,

a) aplikacja sprawdza, czy przedstawiono całą obowiązkową treść zgodnie z XSD dla NtS (jeśli nie, należy wrócić do pkt 2),

b) aplikacja do obsługi NtS generuje nts_number,

(i) „organisation” pozostaje bez zmian;

(ii) „year” pozostaje bez zmian;

(iii) „number” pozostaje bez zmian;

(iv) „serial number” zostaje zwiększony (dodaje się 1)

c) w polu „date_issue” zostaje automatycznie wprowadzona faktyczna data/godzina uruchomienia funkcji publikacji

b) FTM o kodzie tematu „Komunikat odwołany” nie uwzględnia się (już) w planowaniu podróży.

6.3.

FTM dotyczący drogi wodnej lub obiektu

FTM dotyczący drogi wodnej zawiera informacje na temat co najmniej jednego odcinka drogi wodnej. Odcinek drogi wodnej określa się w części „fairway_section” poprzez podanie jego początkowego i końcowego ISRS Location Code.

FTM dotyczący obiektu zawiera informacje na temat co najmniej jednego obiektu na drodze wodnej. Obiekt określa się w części „object” poprzez podanie ISRS Location Code.

Jeden FTM musi się odnosić do:

— co najmniej jednego odcinka szlaku żeglownego; lub

— co najmniej jednego obiektu znajdującego się na co najmniej jednym odcinku szlaku żeglownego

6.4.

Automatyczne uszeregowanie kodów ograniczeń

Różne ograniczenia mają różny wpływ na żeglugę. Aby umożliwić wyświetlanie najpoważniejszych ograniczeń, np. na liście przeglądowej FTM, należy rozważyć stosowanie następującego porządku, w którym najpoważniejsze ograniczenie ma rangę 1:

Ranga

Wartość

Znaczenie (EN)

1

OBSTRU

blockage

2

PAROBS

partial obstruction

3

NOSERV

no service

4

SERVIC

changed service

5

VESDRA

vessel draught

6

VESBRE

vessel breadth

7

CONBRE

convoy breadth

8

VESLEN

vessel length

9

CONLEN

convoy length

10

CLEHEI

clearance height

11

VESHEI

vessel air draught

12

AVALEN

available length

13

CLEWID

clearance width

14

AVADEP

available depth

15

LEADEP

least depth sounded

16

DELAY

delay

17

ALTER

alternate traffic direction

18

TURNIN

no turning

19

PASSIN

no passing

20

OVRTAK

no overtaking

21

NOBERT

no berthing

22

NOMOOR

no mooring

23

ANCHOR

no anchoring

24

SPEED

speed limit

25

WAVWAS

no wash of waves

26

NOSHORE

not allowed to go ashore

27

MINPWR

minimum power

28

CAUTIO

special caution

29

NOLIM

no limitation

6.5.

Postępowanie z okresami obowiązywania ograniczeń

— Ograniczenia o tym samym okresie obowiązywania należy zgrupować / przedstawić na jednej liście / połączyć w celu wyświetlenia informacji w sposób przyjazny dla użytkownika.

— Narzędzia edytorskie NtS powinny posiadać funkcję, dzięki której edytorzy nie będą musieli ponownie wpisywać okresów obowiązywania ograniczeń.

— Wszystkie ograniczenia muszą zawierać okres obowiązywania ograniczenia wraz z interval code w celu umożliwienia przeprowadzenia odpowiednich obliczeń w aplikacjach służących do planowania podróży. Aby ułatwić edytorom NtS pracę, można wdrożyć następujące funkcje:

— — Narzędzie edytorskie NtS może posiadać funkcję kopiowania ograniczeń, które wprowadzono już wcześniej, aby edytorzy nie musieli ponownie wpisywać okresu obowiązywania ograniczenia.

— Narzędzia edytorskie NtS mogą posiadać funkcję wyboru więcej niż jednego kodu ograniczenia dla konkretnego okresu obowiązywania ograniczenia i automatycznego tworzenia niezbędnych sekcji dotyczących ograniczeń w oparciu o informacje wprowadzone przez edytora NtS.

— „Od poniedziałku do piątku z wyjątkiem świąt”: Wartość „święta” jest bardzo problematyczna dla aplikacji służących do planowania podróży. Aby przeprowadzić właściwe obliczenia, potrzebny jest wykaz takich dni wolnych od pracy w poszczególnych krajach. Jeżeli taki wykaz nie jest dostępny, odpowiednie ograniczenia zostaną przypisane również do dni ustawowo wolnych od pracy.

— „Z wyjątkiem”: nie wolno stosować; Przerwane przedziały czasu muszą być podawane jako oddzielne okresy obowiązywania ograniczenia w ramach tego samego ograniczenia, więc kod ten nie może być widoczny/dostępny dla edytorów komunikatów.

— Logika i sposób wyświetlania informacji, które mają zastosowanie w przypadku interval code „Ciągłe”:

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

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

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

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

— <interval_code>CON</interval_code>

— Jeżeli interval_code ma wartość „Ciągłe”, start_time jest przypisany do start_date, a end_time jest przypisany do end_date, np. od 1 kwietnia 06:00 do 30 czerwca 10:00.

— Logika i sposób wyświetlania informacji, które mają zastosowanie w przypadku każdego innego interval code niż „Ciągłe”:

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

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

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

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

— <interval_code>WRK</interval_code>

— Jeżeli interval_code ma inną wartość, start_time i end_time są przypisane do tego interval_code, np. od 1 kwietnia do 30 czerwca, od poniedziałku do piątku, od 06:00 do 10:00.

— Godzinę końca obowiązywania ograniczenia wprowadza się zawsze w ostatniej wersji komunikatu.

7. Ogólne przepisy dotyczące wdrożenia

Należy uwzględnić, co następuje:

— Podczas tworzenia aplikacji NtS należy uwzględnić tabelę „GUI_labels”, zamieszczoną w NtS Reference Tables (maski wyszukiwania, formularz subskrypcji e-mail, wyświetlanie komunikatów).

— Date_end nie może być wcześniejsza niż date_start.

— Kody, które dezaktywowano (których nie należy już używać) w następstwie wniosków o wprowadzenie zmian w NtS (zob. uwagi w XSD dla NtS), nie są wyświetlane edytorom NtS w momencie tworzenia nowych komunikatów. Kody te w dalszym ciągu istnieją w wyliczeniach XSD dla NtS, aby zachować wsteczną kompatybilność.

7.1.

Wypełnianie „number_section”

Wszystkie numery (Organisation/Year/Number/Serial) muszą być niepowtarzalne w obrębie poszczególnych rodzajów komunikatów. Oznacza to, że komunikaty różnych rodzajów mogą mieć taki sam numer NtS.

Dla użytkowników numery komunikatów są istotne jedynie w przypadku FTM i ICEM, w przypadku innych rodzajów komunikatów można, w zależności od krajowych wymogów, pominąć wyświetlanie numeru komunikatu.

Numer komunikatu wyświetla się użytkownikom w następującym formacie: „Message Type/Country/Organisation/Year/Number/Serial” (w zależności od zastosowanych filtrów można go skrócić pod warunkiem, że nie spowoduje to utraty żadnych informacji).

7.2.

Wypełnianie elementów „from”, „originator”, „organisation” i „source”

Do elementu „from” w sekcji identyfikacyjnej wprowadza się nazwę krajowego systemu, który dostarcza dany komunikat (np. ELWIS, DoRIS, SLOVRIS, FLARIS).

Element „originator” to organ, który wprowadza komunikaty do krajowych systemów.

Element „source” to organ, dla którego publikuje się FTM.

Element „organisation” w sekcji nts_number to nazwa organu nadającego nts_number (dostawca NtS).

7.3.

Pomijanie elementów

Jeżeli elementy, które zawierałyby jedynie wartości standardowe lub domyślne, mają charakter warunkowy, pomija się je, ponieważ prowadzą do narzutu danych w komunikacie niemających wartości dodanej.

Dotyczy to następujących elementów:

— Grupa docelowa: target_group_code ALL z direction_code ALL (jeżeli w komunikacie nie określono żadnych innych konkretnych grup odbiorców),

— position_code: AL,

— reason_code: OTHER.

7.4.

Automatyczne wypełnianie date_issue

FTM i ICEM

W przypadku FTM i ICEM wartością elementu date_issue jest faktyczna data i godzina publikacji. W przypadku komunikatów zaktualizowanych date_issue to data i godzina opublikowania aktualizacji.

WRM i WERM

W przypadku WRM i WERM wartością elementu date_issue jest data i godzina żądania przetworzenia danych, ponieważ jeden W(E)RM może obejmować kilka pomiarów z różnymi znacznikami czasu wydania.

7.5.

Postępowanie z informacjami o strefach czasowych w komunikatach NtS

Zawsze podaje się datę i godzinę według czasu miejscowego, uwzględniając informacje o strefie czasowej w komunikatach NtS w formacie XML.

Jedyne wyjątki od tej zasady to „time_start” oraz „time_end” w sekcji „limitation_period”. Wynika to z faktu, że w sekcji dotyczącej ograniczeń można zastosować przedział czasu. Jeżeli data początkowa i data końcowa należą do różnych systemów czasowych (np. CEST i CET), spowodowałoby to zmianę informacji o strefie czasowej w tym przedziale czasu. Nie można tej zmiany wyrazić za pomocą jednego okresu obowiązywania ograniczenia. Zamiast określać oddzielne okresy obowiązywania ograniczeń dla każdej zmiany czasu, w celu zmniejszenia narzutu danych przy przetwarzaniu i przesyłaniu komunikatu stosuje się tylko jeden okres obowiązywania ograniczenia, bez podawania informacji o strefie czasowej.

7.6.

Stosowanie sekund w komunikatach NtS

Sekundy należy zasadniczo podawać w polach (daty)/czasu, ale nie będą one widoczne dla użytkowników NtS. Minuty zapewniają wystarczający stopień szczegółowości NtS.

7.7.

Format znaku oddzielającego części dziesiętne w komunikatach NtS

Znak oddzielający części dziesiętne w polach numerycznych jest zaznaczany za pomocą . (kropki). Nie stosuje się żadnych separatorów oddzielających grupy trzycyfrowe w liczbach od tysiąca wzwyż.

Liczbę miejsc po przecinku wykorzystywanych do podawania wartości ogranicza się do praktycznej, aby zapewnić wyświetlanie wartości liczbowych w sposób przyjazny dla użytkownika.

7.8.

Jednostki, które należy stosować w komunikatach NtS

Jedyne jednostki, które można stosować w komunikatach NtS, to: cm, m3/s, h, km/h i kW, m/s (wiatr), mm/h (opady deszczu) oraz stopnie Celsjusza – aplikacje mogą przeliczać te jednostki w celu wyświetlenia ich w sposób przyjazny dla użytkownika.

Jeżeli wprowadzone jednostki różnią się od ustandaryzowanych jednostek, wprowadzone wartości muszą zostać odpowiednio przeliczone przez aplikację.

7.9.

Przepisy dotyczące elementów „name”, „position_code” oraz „type_code”

Element „name” jest wypełniany automatycznie danymi referencyjnymi „national object name” z RIS Index (edytorzy NtS mogą zmieniać wprowadzaną automatycznie nazwę, jeżeli przepisy krajowe tego wymagają). Zasady nazewnictwa dotyczące nazw obiektów zawarto w Podręczniku kodowania RIS Index w wersji 2.0 lub wyższej. Przykłady poprawnych nazw obiektów przedstawiono również w NtS Encoding Guide dla edytorów.

Aplikacja do obsługi NtS dodaje do obiektu kod rodzaju przed nazwą obiektu.

Położenie obiektów jest kodowane za pomocą kodu położenia, a aplikacja do obsługi NtS dodaje go do obiektu, wykorzystując dane z RIS Index. Edytorzy mogą zmienić wstawione automatycznie kody rodzaju i położenia. Nie wprowadza się kodu położenia obiektu w przypadku geo_objects w fairway_section.

Pełna nazwa obiektu składa się z position code, type code i name.

Aby ułatwić edytorom NtS pracę, w narzędziach edytorskich NtS można zastosować następujące przyporządkowanie, które pomoże edytorom w znalezieniu/wyborze właściwych obiektów w oparciu o RIS Index function_code lub NtS type_code:

Tabela 1

Zestawienie „RIS Index function_code” – „NtS type_code”

Function Code

Function Code Meaning

Type Code

Type Code Meaning

— —

BUAARE

E.1.1 Built-Up Areas

to be selected by editor

BUISGL

E.1.2 Building of Navigational Significance

to be selected by editor

brgare

G.1.1 - G.1.6 Bridge Area [C_AGGR()]

BRI

Most

bridge_5

G.1.1 Bascule Bridge

BRO

bridge opening

bridge_1

G.1.2 Bridges with Bridge Arches

BRO

bridge opening

bridge_1

G.1.3 Fixed Bridge

BRO

bridge opening

bridge_4

G.1.4 Lift Bridge

BRO

bridge opening

bridge_12

G.1.5 Suspension Bridge

BRO

bridge opening

bridge_3

G.1.6 Swing Bridge

BRO

bridge opening

cblohd

G.1.8 Overhead Cable

CAB

cable overhead

pipohd

G.1.9 Overhead Pipe

PPO

pipeline overhead

bridge_7

G.1.12 Drawbridge

BRO

bridge opening

bunsta

G.3.2 Bunker / Fuelling Station

BUS

Bunker / Fuelling Station

cranes

G.3.4 Crane

to be selected by editor

hrbare

G.3.9 Harbour Area

HAR

harbour

hrbbsn

G.3.10 Harbour Basin

HAR

harbour

ponton

G.3.11 Landing Stage, Pontoon

to be selected by editor

morfac

G.3.12 Mooring Facility

MOO

mooring facility

hulkes

G.3.14 Permanently Moored Vessel or Facility

to be selected by editor

prtare

G.3.15 Port Area

HAR

harbour

refdmp

G.3.17 Refuse Dump

REF

refuse dump

termnl

G.3.19 Terminal

TER

terminal

trm01

G.3.19 RORO-terminal

TER

terminal

trm03

G.3.19 Ferry-terminal

TER

terminal

trm07

G.3.19 Tanker-Terminal

TER

terminal

trm08

G.3.19 Passenger Terminal

TER

terminal

trm10

G.3.19 Container Terminal

TER

terminal

trm11

G.3.19 Bulk Terminal

TER

terminal

vehtrf

G.3.20 Vehicle Transfer Location

BER

berth

lokbsn

G.4.3 Lock Basin

LKB

lock basin

lkbspt

G.4.4 Lock Basin Part

LKB

lock basin

lokare

G.4.3 / G.4.4 Lock Area [C_AGGR()]

LCK

lock

excnst

G.4.8 Exceptional Navigational Structure

SLI

ship lift

TUN

tunnel

CBR

canal bridge

gatcon

G.4.9 Opening Barrage

BAR

weir

FLO

flood gate

wtwgag

I.3.4 Waterway Gauge

GAU

tide gauge

FERYRT_2

L.2.1 Cable Ferry

FER

ferry

FERYRT_1

L.2.2. Free Moving Ferry

FER

ferry

feryrt_4

L.2.3. Swinging Wire Ferry

FER

ferry

dismar

L.3.2 Distance Mark along Waterway Axis

RIV

river

achare

M.1.1 Anchorage Area

ANC

anchoring area

achbrt

M.1.2 Anchorage Berth

BER

berth

berths_3

M.1.3 Berth / Fleeting Areas

BER

berth

berths_1

M.1.4 Transhipment Berth

BER

berth

trnbsn

M.4.5 Turning Basin

TUR

turning basin

CAN

canal

FWY

fairway

rdocal

Q.2.1 Radio Calling-In Point (notification point)

REP

reporting point

chkpnt

R.1.1 Check Point

BCO

Kontrola graniczna

sistat_8

R.2.1 Traffic Sistat – Bridge Passage

SIG

signal station

sistat_6

R.2.2 Traffic Sistat – Lock

SIG

signal station

sistat_10

R.2.3 Traffic Sistat – Oncoming Traffic Indicator

SIG

signal station

sistat_2

R.2.4 Traffic Sitat – Port Entry and Departure

SIG

signal station

pas

Passage Points

to be selected by editor

riscen

RIS centre

VTC

vessel traffic centre

specon

Special Construction

to be selected by editor

trafp

Traffic Points (first reporting points)

REP

reporting point

junction

Waterway node / end of waterway / Junction

to be selected by editor

waypt

Waypoint

to be selected by editor

Legend:

green

Direct match (1:1 relation)

yellow

matching example, other TypeCodes possible (1:n relation)

blue

no direct match / to be selected by editor

7.10.

Przepisy dotyczące elementu „fairway_name”

Aby uniknąć problemów związanych z logiką aplikacji / koniecznością prawidłowych danych referencyjnych w systemie odbiorczym (oprogramowanie wyświetlające komunikat użytkownikowi), „geo_object” musi zawsze zawierać fakultatywny element „fairway_name”, który aplikacja do obsługi NtS musi wprowadzić automatycznie, wstawiając „Waterway name” z RIS Index. Edytorom NtS nie wolno zmieniać treści elementu fairway_name.

7.11.

Wyjaśnienia dotyczące tłumaczeń w arkuszu „reference_code”

W odniesieniu do wartości reference_code podanych w NtS Reference Tables stosuje się następujące definicje:

— NAP: w Niderlandach skrótu NAP nie tłumaczy się, gdyż jest on stosowany i zrozumiały,

— KP: „channel level” tłumaczy się, a zatem podaje się w języku narodowym,

— FZP: stosuje się wyłącznie skrót „FZP” (obecnie już rzadko używany),

— ADR: „Adriatic Sea” (pl. Morze Adriatyckie) tłumaczy się, a zatem podaje się w języku narodowym,

— TAW/DNG: „Tweede algemene waterpassing” (niderlandzki) – „Deuzième Nivellement Général” (francuski) to wysokość referencyjna stosowana w Belgii do wyrażenia pomiarów wysokości. 0 oznacza średni stan wody w morzu przy niskim stanie wody w Ostendzie

— — Niderlandzki: TAW

— Francuski: DNG

— Wszelkie pozostałe języki: TAW/DNG.

— LDC: „low navigable water level Danube Commission” (pl. Niska woda żeglowna wg Komisji Dunajskiej) tłumaczy się, a zatem podaje się w języku narodowym,

— HDC: „high navigable water level Danube Commission” (pl. Wysoka woda żeglowna wg Komisji Dunajskiej) tłumaczy się, a zatem podaje się w języku narodowym,

— ETRS: „European Terrestrial Reference System 1989”, we wszystkich językach stosuje się skrót „ETRS89”.

7.12.

Zalecenie dotyczące elementu „coordinate”

Chociaż współrzędne obiektu mają charakter warunkowy, współrzędne geograficzne podaje się w WGS84 w formacie [d]d mm.mmm[m] N (latitude) and [d][d]d mm.mmm[m] E (longitude). W ten sposób podaje się geograficzne odniesienie komunikatów NtS.

7.13.

Postępowanie z grupami odbiorców

Sekcja poświęcona grupie odbiorców składa się z kodu grupy odbiorców i kodu kierunku ruchu. W przypadku gdy oba elementy przyjmują wartość ALL, cała sekcja zostaje pominięta, jeżeli w komunikacie nie określono żadnych innych konkretnych grup odbiorców. Jeżeli tylko jeden z tych dwóch elementów został podany, w drugim należy wpisać wartość domyślną ALL, ponieważ podanie obu elementów jest obowiązkowe.

Więcej informacji dotyczących grup odbiorców można znaleźć w NtS Encoding Guide dla edytorów.

7.14.

Wyświetlanie obowiązujących komunikatów w danym czasie

Aplikacje muszą korzystać z tag validity_period do wyboru komunikatów, które mają być wyświetlane użytkownikom przez wymagany czas.

Jeżeli subject_code ma wartość INFSER (Serwis informacyjny), okres obowiązywania wykorzystuje się do określenia czasu wyświetlania użytkownikom komunikatu „Serwis informacyjny”, a nie w odniesieniu do okresu obowiązywania przekazywanych informacji (np. 1 miesiąc).

7.15.

Funkcje fakultatywne ułatwiające obsługę narzędzi edytorskich NtS

W zależności od wymogów krajowych edytorzy NtS mogą mieć do dyspozycji następujące funkcje:

— aplikacje do obsługi NtS mogą umożliwiać edytorom NtS zapisywanie wersji roboczej komunikatów NtS (aby zapisać wersję roboczą komunikatów, nie trzeba podawać wszystkich obowiązkowych informacji),

— poszczególni edytorzy mogą być użytkownikami pełniącymi różne role (np. edytorów mających dostęp do komunikatów lub mogących wprowadzać zmiany w komunikatach, wydawców mogących publikować komunikaty (oprócz ich edytowania)).

8. Struktura komunikatów NtS w formacie XML

Struktura komunikatów NtS w formacie XML oraz treść i przeznaczenie elementów danych określono i wyjaśniono w dodatku C: Definicja schematu XML (XSD) dla NtS.

9. NtS Web Service

9.1.

Cel

Grupa ekspertów ds. NtS uznała, że komunikaty dla kierowników statków najlepiej dostarczać za pomocą technologii web service.

Niniejszy rozdział zawiera specyfikację web service do przekazywania komunikatów dla kierowników statków, w skrócie – NtS Web Service. Szczególny nacisk położono na stosowanie uznanych norm międzynarodowych.

Jednym z celów projektu koncepcyjnego było zapewnienie właściwej równowagi między elastycznością a stabilnością tworzonej usługi web service. Parametry filtrów dostępne w zapytaniach to zasadniczo kryteria określone w standardzie NtS (odcinek drogi wodnej i opcjonalnie km odcinka rzeki, okres obowiązywania, data publikacji komunikatu). Wydaje się to wystarczające wyraziste, biorąc pod uwagę sposoby korzystania z web service, a zarazem ogranicza złożoność wdrożenia.

Podstawowym rezultatem jest umowa o web service, w której określone są zapytania i odpowiedzi. Osoby korzystające z web service mogą powoływać się na tę umowę, a dostawcy usługi muszą jej przestrzegać. Umowa ta określona jest za pomocą międzynarodowego standardu WSDL.

Każde uczestniczące państwo członkowskie musi wdrożyć co najmniej jedną web service w odniesieniu do różnych rodzajów komunikatów NtS (FTM, WRM, ICEM, WERM) i świadczyć takie usługi przez internet („usługa obsługująca komunikaty NtS”).

Zakres niniejszej specyfikacji nie obejmuje technicznych informacji na temat wdrażania NtS WS, np. wyboru odpowiednich pul danych, aplikacji i platform, za ich zapewnienie odpowiada indywidulanie każde uczestniczące państwo członkowskie.

Zdefiniowanie bezpiecznej komunikacji wymaga uwzględnienia różnych aspektów bezpieczeństwa i celów ochrony. W zależności od okoliczności nie wszystkie takie aspekty muszą być brane pod uwagę. Mogą występować różnice w zakresie priorytetowego traktowania poszczególnych aspektów bezpieczeństwa i stopnia, w jakim są one zapewniane. Ponadto wykonalność określonego środka mogą ograniczać zdolności do jego technicznego wdrożenia. W kontekście NtS wszystkie informacje są publicznie dostępne. Nie zachodzi zatem potrzeba zabezpieczania samych danych NtS pod kątem ochrony danych. W związku z tym każdy dostawca musi sam zdecydować, w jakim stopniu wdroży ten aspekt w swojej usłudze.

9.2.

Podstawowe zasady i ograniczenia

9.2.1.

Standardy sieciowe

NtS Web Service musi być zgodna z WS-I Basic Profile 1.1. Profil ten „zawiera wytyczne dotyczące interoperacyjności w odniesieniu do podstawowego zestawu niezastrzeżonych prawem specyfikacji web service, takich jak SOAP, WSDL i UDDI” (

4

). W tym przypadku najistotniejszymi standardami są:

— XML Schema Definition (XSD),

— Simple Object Access Protocol (SOAP),

— Web Services Description Language (WSDL) oraz

— Universal Description, Discovery and Integration (UDDI).

Komunikat odpowiedzi NtS WS to komunikat NtS zdefiniowany w definicji schematu XML (XSD) w dodatku C do niniejszego rozporządzenia Komisji.

SOAP

to protokół aplikacji do transmisji danych między systemami informatycznymi, ustanowiony jako standard przez World Wide Web Consortiums (W3C).

Poszczególne elementy NtS Web Service zdefiniowano zgodnie z odpowiednimi specyfikacjami WSDL w dodatku D do niniejszego rozporządzenia Komisji. Schemat standardu dla NtS (XSD) został dołączony wraz z instrukcją importu.

UDDI

(Universal Description, Discovery and Integration) figuruje tu jako centralny, potencjalnie międzynarodowy rejestr web services, który może obejmować NtS Web Service. Potencjalni użytkownicy web service mogliby ją w takim rejestrze wyszukać. Ponieważ jednak liczba potencjalnych dostawców NtS Web Service jest ograniczana przez uczestniczące państwa członkowskie, a specyfikacja WSDL stanowi integralną część standardu, nie ma wyraźnej potrzeby niezależnej rejestracji NtS Web Service.

9.2.2.

Model interakcji i metoda kodowania NtS WS

W przypadku NtS Web Service stosuje się metodę kodowania według wzorca Document-literal wrapped, gdyż umożliwia ona na walidację na podstawie schematu XML, a nazwy operacji zdefiniowane w specyfikacji WSDL są używane bezpośrednio jako nazwy tagów XML w wiadomościach SOAP.

9.3.

Ogólne specyfikacje i zalecenia

9.3.1.

Specyfikacja: Informacje na temat wersji

Informacje na temat wersji NtS Web Service składają się z dwóch sekcji:

— sekcja dotycząca wersji samej web service,

— sekcja dotycząca wersji schematu NtS wykorzystywanego przez web service.

Sekcja dotycząca wersji samej web service składa się z dwóch części:

— główna wersja web service,

— drugorzędne wersje web service.

Wersja główna jest oznaczona za pomocą dodatniej liczby całkowitej wskazującej wersję główną web service.

Wersja drugorzędna jest oznaczona za pomocą nieujemnej liczby całkowitej wskazującej wersję drugorzędną web service w ramach wersji głównej.

Sekcja schematu NtS zawiera wersję schematu NtS określoną przez grupę ekspertów ds. NtS.

W związku z powyższym określona w tym dokumencie wersja NtS Web Service to 2.0.4.0, gdzie 2.0 to oznaczenie wersji samej web service, a 4.0 – wersji stosowanego schematu NtS.

Zapytania lub odpowiedzi w NtS Web Service nie muszą zawierać bezpośrednich informacji o wersji. Oczekuje się, że w internecie współistnieć będzie tylko kilka wersji usług jednocześnie. Poszczególne wersje oznacza się osobnymi URL. Dlatego też każda instancja wdrożenia NtS Web Service musi obsługiwać jedną określoną wersję NtS Web Service.

9.3.2.

Specyfikacja: Struktura przestrzeni nazw

Przestrzenie nazw w NtS Web Service opierają się na domenie internetowej grup ekspertów ds. RIS, http://www.ris.eu/.

Przestrzenie nazw zawierają cząstkę wskazującą informacje o odpowiedniej usłudze i wersji. W usłudze będącej przedmiotem niniejszej specyfikacji stosuje się zatem następującą przestrzeń nazw:

Usługa obsługująca komunikaty NtS: http://www.ris.eu/nts.ms/2.0.4.0

9.3.3.

Zalecenie: Stosowanie przestrzeni nazw

Zaleca się, aby w celu uzyskania większej przejrzystości dokumentów XML definiować przestrzenie nazw w najbardziej oddalonym odpowiednim elemencie schematów oraz w dokumentach instancji oraz aby nie stosować lokalnych definicji przestrzeni nazw w elementach zagnieżdżonych.

9.3.4.

Zalecenie: Stosowanie prefiksów przestrzeni nazw

W zapytaniach i odpowiedziach w NtS Web Service stosuje się elementy XML w formie kwalifikowanej, tj. z wyraźnym prefiksem przestrzeni nazw, i atrybuty XML w formie niekwalifikowanej, tj. bez prefiksu przestrzeni nazw.

Zaleca się stosowanie intuicyjnych prefiksów, takich jak „nts”, aby przestrzeń nazw była bardziej czytelna dla człowieka.

9.3.5.

Specyfikacja: Stosowanie ISRS Location Code

Wyjaśnienia dotyczące ISRS Location Code przedstawiono w rozdziale 2 NtS Encoding Guide dla deweloperów aplikacji oraz w RIS Index Encoding Guide.

Wprowadzając zapytanie w NtS Web Service, klient może określać różne obiekty, odcinki szlaku żeglownego, wodowskazy lub śluzy. Jeżeli stosowane są odpowiednie parametry, tj. id elements, muszą one zawierać ISRS Location Code. Parametry te zwykle podawane są w id elements, z których każdy zawiera jeden lub dwa identyfikatory.

Stosując takie parametry, należy przestrzegać następujących ogólnych zasad:

— kody ISRS Location Code należy podawać jako pełne kody składające się z 20 znaków, tj. bez pomijania końcowych zer,

— jeżeli użyto dwóch identyfikatorów w jednym elemencie identyfikacyjnym, oba kody ISRS Location Code muszą odnosić się do tej samej drogi wodnej. Oznacza to, że kody te zawierają pewne identyczne znaki w części fairway_section kodu ISRS Location Code. Kod odcinka szlaku żeglownego wraz z hektometrami szlaku żeglownego określa odcinek drogi wodnej przedstawiony jako para id elements.

Aby przedstawić odcinki drogi wodnej (id elements w fairway_section geo_object) w komunikacie NtS, w odniesieniu do ISRS Location Code należy uwzględnić poniższe uwagi:

— znak 1. i 2. (Country code):

— — muszą być identyczne w parze identyfikacyjnej, ale

— w ramach jednej pary identyfikacyjnej można zdefiniować różne kody krajów, jeżeli sąsiadujące kraje stosują ten sam kod odcinka szlaku żeglownego w odniesieniu do określonej drogi wodnej i ten sam system oznaczania hektometrów,

— znaki od 3. do 5. (UN Location code):

— — nie mają znaczenia, mogą zawierać różną treść w parze identyfikacyjnej,

— znaki od 6. do 10. (Fairway section code):

— — muszą być identyczne w parze identyfikacyjnej, ale

— [wyjątek]: jeżeli w NtS WS stosuje się belgijskie kody ISRS, do identyfikacji odcinka szlaku żeglownego należy użyć jedynie znaków od 6. do 8., gdyż komunikaty NtS będą nadawane na różnych odcinkach tego samego szlaku żeglownego,

— znaki od 11. do 15. (Object Reference Code),

— — nie mają znaczenia, mogą zawierać różną treść w parze identyfikacyjnej,

— znaki od 16. do 20. (Fairway Hectometre):

— — są to znaki numeryczne oznaczające hektometry, w związku z czym zawierają zwykle różną treść w parze identyfikacyjnej, Przykład: „00235” oznacza 23,5 km szlaku żeglownego; „00001” oznacza 0,1 km szlaku żeglownego;

— [wyjątek]: w przypadku Niderlandów nie zawsze istnieje bezpośredni związek między hektometrami szlaku żeglownego a fizycznymi kilometrami szlaku żeglownego ze względu na definicję początku odcinka szlaku żeglownego w modelu sieciowym i w realnym świecie. W takich przypadkach Object Reference Code dla obiektów typu „dismar” zaczyna się znakami Kxxxx (xxxx oznacza kilometry fizyczne, np. NLSVG00130K000300191 (km 3)). W przypadku innych obiektów nie ma jednak w kodach ISRS bezpośredniego odniesienia do fizycznych kilometrów szlaku żeglownego, np. most w Sas van Gent na 2,5 km tego samego szlaku żeglownego ma kod ISRS NLSVG001300521600186. W przypadku Kanaal Gent-Terneuzen fizyczny kilometr 0,0 zaczyna się na granicy Belgii i Niderlandów, natomiast hektometr szlaku żeglownego 0,0 – na początku kanału w Gent.

Jeżeli komunikat dotyczy więcej niż jednego odcinka drogi wodnej lub szlaku żeglownego wszystkie odcinki szlaku żeglownego muszą zostać określone przez podanie ich początkowego i końcowego punktu w odrębnych elementach XML „fairway_section”.

W przypadku niektórych krajów/regionów wymagane jest wbudowanie funkcji filtra. Przykładowo, jeżeli ISRS Location Code (znaki 1–2) to BE, należy zastosować ISRS Location Code (6–8) jako ID do liniowego odniesienia do hektometra szlaku żeglownego (ISRS Location Code 16–20). Przykłady odcinków szlaku żeglownego (obowiązujące pary elementów identyfikacyjnych w fairway_section), które obejmują wyżej wskazane wyjątki:

— oba kody ISRS Location Code NL stanowią obowiązujące określenie odcinka drogi wodnej (przedstawiono wyjątek NL w odniesieniu do kilometra szlaku żeglownego): NLSVG00130K000300191 (3,0 km przy Sas van Gent na Kanaal Gent-Terneuzen) – NLWDP00130K000400200 (4,0 km przy Westdorpe na Kanaal Gent-Terneuzen),

— oba kody ISRS Location Code BE stanowią obowiązujące określenie odcinka drogi wodnej (przedstawiono wyjątek BE w odniesieniu do fairway section code („020” Albertkanaal)): BEGNK02016L010100414 (śluza w Genk znajdująca się na 41,4 km na Albert Canal) – BEOSH02033L010500772 (śluza w Ham znajdująca się na 77,2 km na Albert Canal).

Następujące dane ukazują kontrprzykłady zastosowania ISRS Location Code dla każdej z ogólnych zasad (w odniesieniu do odcinków drogi wodnej SK nie mają zastosowania żadne wyjątki od ogólnych zasad):

Nieprawidłowe zapytania ISRS Location Code

Uwaga ogólna: NtS Web Service nie obsługuje usługi zapytań w oparciu o obowiązujące ISRS Location Codes. ISRS Location Codes są dostarczane z European Reference Data Management System (ERDMS) (europejskiego systemu zarządzania danymi referencyjnymi).

Poniżej przedstawiono pięć przypadków prawidłowego użycia ISRS Location Codes w zapytaniach i ich interpretację:

Przypadek nr 1: Brak elementu identyfikacyjnego w zapytaniu

Element identyfikacyjny stanowi fakultatywną część zapytania, tj. dopuszczalne jest zapytanie niezawierające żadnych elementów identyfikacyjnych:

Prawidłowe zapytanie bez parametrów identyfikacyjnych

Jeżeli nie podano żadnego elementu identyfikacyjnego, w wynikach wyświetla się wszystkie komunikaty (oczywiście w zależności od innych kryteriów filtrowania, takich jak validity_period lub dates_issue).

Przypadek nr 2: Jeden element identyfikacyjny w zapytaniu

Każdy elementy identyfikacyjny może zawierać jeden lub dwa elementy identyfikacyjne. Na poniższym rysunku przedstawiono przykład jednego elementu identyfikacyjnego:

Prawidłowe zapytanie z jednym parametrem identyfikacyjnym

W przypadku otrzymania takiego zapytania serwer odsyła jako wynik wszystkie pasujące komunikaty, w których początkowy hektometr ≤ podanej wartości (w tym przykładzie jest to 240,7 ) a końcowy hektometr ≥ podanej wartości. Na poniższym rysunku przedstawiono taki wybór komunikatów: położenie, którego dotyczy zapytanie, znajduje się między wartościami początkowego i końcowego hektometra w przypadku komunikatów 1, 3 i 4, które zostaną wyświetlone w wynikach. Komunikaty 2, 5 i 6 nie pokrywają się z położeniem, którego dotyczy zapytanie, w związku z czym nie pojawią się w wynikach.

Jeżeli dany ISRS Location Code oznacza pojedynczy obiekt, np. wodowskaz lub śluzę, web service powinna wyświetlić w wynikach komunikaty dotyczące takiego obiektu.

Pasujące i niepasujące komunikaty dla jednego parametru identyfikacyjnego

Przypadek nr 3: Dwa elementy identyfikacyjne w zapytaniu

Każdy elementy identyfikacyjny może zawierać jeden lub dwa elementy identyfikacyjne. Na poniższym rysunku przedstawiono przykład dwóch elementów identyfikacyjnych:

Prawidłowe zapytanie z dwoma parametrami identyfikacyjnymi

Wszystkie wartości hektometrów, których dotyczy zapytanie, należy traktować jako prawidłowe, nawet jeżeli odpowiadający im odcinek szlaku żeglownego ma inny punkt początkowy i końcowy. Przykładowo, jeżeli odcinek szlaku żeglownego zaczyna się na 100,0 hektometrze, a kończy na 300,0 hektometrze, zapytanie, w którym podano zakres hektometrów 20,0 –400,0 , byłoby prawidłowe. Oczywiście wewnętrznie przeszukiwana jest jedynie „faktyczna” długość odcinka szlaku żeglownego.

Umożliwia to wyszukanie wszystkich komunikatów dotyczących danego szlaku żeglownego bez znajomości jego dokładnego zakresu hektometrów (w zapytaniu można by zastosować ISRS Location Code z hektometrami ustawionymi odpowiednio na „00000” lub „99999”).

Na liście wyników wyświetla się wszystkie pasujące komunikaty mieszczące się w danym przedziale hektometrów. Taką sytuację przedstawiono na poniższym diagramie:

Pasujące i niepasujące komunikaty dla dwóch parametrów identyfikacyjnych

Na powyższym rysunku przedstawiono, na czym polega „mieszczenie się w przedziale”. W przeciwieństwie do zakresu komunikatów nr 5 i 6 zakres komunikatów nr 1–4 pokrywa się (całkowicie lub częściowo) z zakresem hektometrów, którego dotyczyło zapytanie, w związku z czym komunikaty nr 1–4 zostaną wyświetlone w wynikach, a komunikaty nr 5 i 6 nie.

Komunikat mieści się w przedziale [A, B], jeżeli spełniony jest następujący warunek techniczny: początkowy hektometr określony w komunikacie jest ≤ B, a końcowy hektometr jest ≥ A.

Łączenie: Wiele elementów identyfikacyjnych w zapytaniu

Prawidłowe zapytanie zawierające wiele elementów identyfikacyjnych

Połączenie kilku elementów identyfikacyjnych w zapytaniu prowadzi do powstania zbioru odpowiednich komunikatów. Wszystkie elementy identyfikacyjne są traktowane indywidualnie, a komunikat znajdzie się w wynikach, jeżeli pasuje przynajmniej jeden jego element. W związku z powyższym w podanym przykładzie w wynikach wyświetlone zostałyby następujące komunikaty:

— wszystkie komunikaty dotyczące obiektu o ISRS Location Code SKXXX0000010000***** z początkowym hektometrem = 0 i końcowym ≥ 0 (zob. przypadek nr 2),

— wszystkie komunikaty dotyczące obiektu o ISRS Location Code SKXXX0000500000*****, które mieszczą się w przedziale hektometrów [11,0 , 15,0 ] (zob. przypadek nr 3),

— wszystkie komunikaty dotyczące obiektu o ISRS Location Code SKXXX0000200000***** z początkowym hektometrem ≤ 110,5 i końcowym ≥ 110,5 (zob. przypadek nr 2),

— wszystkie komunikaty dotyczące obiektu o ISRS Location Code SKXXX0000500000*****, które mieszczą się w przedziale hektometrów [220,0 , 300,0 ] (zob. przypadek nr 3).

9.4.

Usługa obsługująca komunikaty NtS (specyfikacja wdrażania)

Niniejszy rozdział zawiera specyfikację wdrażania usługi obsługującej komunikaty NtS, sporządzoną na podstawie uwag i wyborów przedstawionych w poprzednich rozdziałach.

Usługa obsługująca komunikaty NtS obejmuje cztery rodzaje komunikatów NtS:

1. NtS FTM (komunikat dotyczący szlaku żeglownego i ruchu),

2. NtS WRM (komunikat dotyczący stanu wody),

3. NtS ICEM (komunikat o lodzie),

4. NtS WERM (komunikat pogodowy).

Wdrożenie usługi obsługującej komunikat NtS może obejmować obsługę wszystkich lub wybranych rodzajów komunikatów. Uczestniczące państwo członkowskie może świadczyć jedną lub większą liczbę usług dla danego rodzaju komunikatu, które będą się wzajemnie uzupełniać.

9.4.1.

Zapytanie

Aby osiągnąć jak największą stabilność usługi bez≥ jednoczesnego zwiększania jej złożoności, w NtS Web Service nie stosuje się dodatkowego języka zapytania. Zamiast tego stosuje się konstrukcje przewidziane w ramach samego WSDL. Wszystkie konkretne operacje wraz z ich parametrami są w całości określone w specyfikacji WSDL. W przypadku usługi obsługującej komunikaty NtS zdefiniowano jedną operację.

Kryteria filtrów dotyczące konkretnych tematów pochodzą ze standardu NtS, lecz obejmują również liczne dodatkowe parametry:

— rodzaj komunikatu (obowiązkowo; jeden z następujących: „FTM”, „WRM”, „ICEM”, „WERM”),

— konkretne odcinki drogi wodnej bądź ich części, lub konkretne obiekty (fakultatywnie; opisane za pomocą jednego ISRS Location Code lub par ISRS Location Codes),

— okres obowiązywania (fakultatywnie; data początku i data zakończenia),

— data wydania komunikatu (fakultatywnie; pojedyncze daty lub daty wskazujące przedziały czasowe).

Usługa podaje w wynikach zapytania jedynie komunikaty pasujące do podanych kryteriów.

Mechanizm stronicowania≤

Aby kontrolować ilość danych, zapewniono obsługę mechanizmu stronicowania. Parametr stronicowania zdefiniowano za pomocą typu złożonego zawierającego następujące elementy:

— offset: numer seryjny pierwszego komunikatu podawanego w wynikach (integer ≥ 0)

— limit: maksymalna liczba komunikatów (integer ≥ 0)

— total count: flaga, jeżeli w wynikach wyświetlane są wszystkie komunikaty (wartość boolowska)

Złożony parametr stronicowania jest fakultatywny. Jeżeli jednak został zastosowany, musi zawierać wszystkie elementy. W takim przypadku mechanizm stronicowania działa w następujący sposób:

łączna liczba komunikatów nie będzie przekraczać wartości parametru limit, wyjątek stanowi wartość 0, która oznacza „no limit”. W odpowiedzi pominiętych zostaje tyle komunikatów, ile zdefiniowano w parametrze offset. Aby mechanizm był dostępny, w ramach usługi musi być przestrzegana ta sama, tymczasowo stała (choć w każdym innym względzie arbitralna) kolejność komunikatów, np. między dwoma aktualizacjami danych w komunikatach w źródłowym zbiorze danych web service. Oznacza to, że wynikami dwóch następujących po sobie identycznych wywołań muszą być te same komunikaty w tej samej kolejności. Od parametru total count zależy, czy odpowiedź ma zawierać wszystkie komunikaty odpowiadające kryteriom dotyczącym konkretnego tematu. Zazwyczaj wystarczy zażądać tej informacji w ramach pierwszej odpowiedzi i pominąć ją we wszystkich kolejnych. Powinno to usprawnić działanie web service.

Dzięki takiemu mechanizmowi stronicowania zapytania dotyczące komunikatów są wykonywane na zasadzie iteracji w formie „stron”. Aby mechanizm stronicowania działał prawidłowo, każde wywołanie musi zawierać takie same parametry dotyczące konkretnego tematu.

9.4.2.

Odpowiedź

W przypadku zapytania zakończonego powodzeniem odpowiedź NtS Web Service zawiera komunikaty NtS odpowiadające parametrom zapytania. Komunikaty NtS muszą być zgodne ze schematem NtS i można je walidować na jego podstawie. W związku z tym, że rodzaj komunikatu stanowi obowiązkowy parametr zapytania, każda odpowiedź może zawierać wyłącznie komunikaty NtS tego samego rodzaju – odpowiednio FTM, WRM, ICEM albo WERM.

Jeżeli w trakcie przetwarzania zapytania usługa wykryje błędy, w odpowiedzi może wyświetlić dowolną liczbę komunikatów o błędach, używając kodów błędów wymienionych w następnym podrozdziale.

Jedna odpowiedź NtS Web Service może zawierać jednocześnie komunikaty NtS i komunikaty o błędach.

Jeżeli zapytanie zawierało parametry stronicowania, w wynikach podawane są fakultatywne informacje dotyczące stronicowania. W takim przypadku obowiązkowo należy podać offset i liczbę zawartych komunikatów, natomiast total count podaje się na żądanie.

Uwaga: Zakłada się, że komunikacja między web service a użytkownikiem jest zapewniona od strony technicznej, tzn. usługa otrzymuje zapytanie, a użytkownik – odpowiedź na to zapytanie. Nie uwzględnia się tu błędów technicznych, takich jak zerwanie połączenia z internetem lub brak dostępu do web service ze względu na prace konserwacyjne lub awarię. Brane są tu pod uwagę jedynie sytuacje, do których dochodzi „poza” warstwą web service z punktu widzenia użytkowników.

Komunikaty o błędach

Poniżej podano kody błędów dotyczące sytuacji, w których spodziewać się można błędów, wraz z wyjaśnieniem. Zgodnie z normalną procedurą w schemacie XML dla NtS odpowiedź zawiera jedynie kod błędu.

Kody błędów dotyczące usługi obsługi komunikatów NtS

Code

Description

Explanation

e010

message type not supported

web service does not support the requested message type

e030

paging parameters inconsistent with messages

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

e100

syntax error in request

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

e110

incorrect message type

given message type is not known

e120

incorrect type-specific parameters

type-specific parameters are erroneous

e130

incorrect paging parameters

given parameters for the paging mechanism are erroneous

e200

operation not known

the requested operation is unknown

e300

data source unavailable

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

e310

too many results for request,

server is unable to handle number of results

9.5.

Generowanie usługi i klientów

Jeżeli konsekwentnie przestrzega się podejścia „najpierw umowa”, tj. tworzona jest co najmniej jedna umowa z pełnym opisem interfejsów w formie dokumentów WSDL, wdrożenie usługi (usług), jak również wdrożenie odpowiedniego oprogramowania typu klient może być automatycznie generowane przy użyciu odpowiednich narzędzi oprogramowania. W optymalnym przypadku nie ma potrzeby ręcznego wprowadzania jakichkolwiek zmian w wygenerowanym kodzie źródłowym.

W większości przypadków koniecznych jest jednak kilka iteracji, zanim osiągnie się zgodność specyfikacji WSDL z precyzyjnymi wymogami takiego narzędzia. Zazwyczaj narzędzie wymaga indywidualnego dostosowania w zakresie stosowania standardu WSDL, aby mogło działać bez zakłóceń. W rezultacie konieczne może być wprowadzenie zmian w specyfikacji WSDL, nawet jeżeli specyfikacja WSDL stanowiła już obowiązującą specyfikację zgodnie ze standardem WSDL. Jeżeli specyfikacja WSDL web service zostaje zmieniona po wygenerowaniu usługi lub klienta, konieczne może być rozpoczęcie nowego procesu generowania, w zależności od wprowadzonych zmian.

Glosariusz

Pojęcie

Objaśnienie

ID

Identyfikacja

ISRS Location Code

Kod lokacyjny „International Ship Reporting Standard” („międzynarodowego standardu meldowania statków”)

NtS

Komunikaty dla kierowników statków

RIS

Usługi informacji rzecznej

SOAP

Simple Object Access Protocol, protokół sieciowy zwykle używany na potrzeby usług internetowych

UDDI

Universal Description, Discovery and Integration; standard usług rejestru w kontekście usług sieciowych

ONZ

Organizacja Narodów Zjednoczonych

URL

Ujednolicony format adresowania zasobów; lokalizacja zasobu sieciowego zwykle używana w adresach internetowych

WGS 84

Światowy system geodezyjny z 1984 r.

WS

Usługa sieciowa; usługa, która zapewnia swoje interfejsy za pośrednictwem internetu i jest używana w komunikacji internetowej

WSDL

Język definiowania usługi sieciowej; standard mający zastosowanie do specyfikacji usług sieciowych

WS-I

Web Services Interoperability Organisation; konsorcjum branżowe, którego celem jest wspieranie interoperacyjności usług sieciowych

XML

Rozszerzalny Język Znaczników; metajęzyk umożliwiający przedstawianie danych w ustrukturyzowany sposób niezależnie od platformy

XSD

definicja schematu XML; standard służący do określania struktury dokumentów XML

Appendix C

No

Tag (Group headers and closers are boldly printed)

Description

Occ.

Rule

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

<RIS_Message>

Notice to Skippers

1s

Identification section

M

1

1.1

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

Internal ID

C

1.2

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

Sender (System) of the message

M

1.3

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

Originator (initiator) of the information in this message

M

1.4

<country_code>nts:country_code_enum</country_code>

Country where message is valid

M

1.5

<language_code>nts:language_code_enum</language_code>

Original language used in the textual info. (contents)

M

1.6

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

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

C

1.7

<date_issue>xs:dateTime<date_issue>

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

M

1e

</identification>

2s

<ftm>

Fairway and traffic related section

C

1

2.1

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

Internal ID

C

2.2s

<nts_number>

NtS Number

M

2.2.1

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

Name of the publishing organisation (NtS Provider)

M

2.2.2

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

Year of first issuing of the notice

M

2.2.3

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

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

M

2.2.4

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

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

M

2.2e

</nts_number>

2.3s

<target_group>

Target group information

C

2.3.1

<target_group_code>nts:target_group_code_enum</target_group_code>

Target group (vessel type) for this message

M

5

2.3.2

<direction_code>nts:direction_code_enum</direction_code>

Upstream or downstream traffic, or both

M

5

2.3e

</target_group>

2.4

<subject_code>nts:subject_code_enum</subject_code>

Subject code

M

2.5s

<validity_period>

Overall period of validity

M

2.5.1

<date_start>xs:date</date_start>

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

M

2.5.2

<date_end>xs:date</date_end>

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

C

2.5e

</validity_period>

2.6

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

Additional information in local language

C

2.7

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

Notice source (name of authority)

C

2.8

<reason_code>nts:reason_code_enum</reason_code>

Reason / justification of notice

C

2.9s

Communication channel information

C

2.9.1

<reporting_code>nts:reporting_code_enum</reporting_code>

Reporting regime (information or duty to report)

M

5

2.9.2

<communication_code>nts:communication_code_enum</communication_code>

Communication code (telephone, VHF etc.)

M

5

2.9.3

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

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

C

2.9.4

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

Name of the attachment or additional information

C

2.9.5

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

Additional remarks concerning the communication

C

2.9e

</communication>

2.10s

<fairway_section>

Fairway section, also available for objects (no 2.11)

C

2

2.10.1s

<geo_object>

Geo information of fairway

M

5

2.10.1.1

ISRS Location Code of the fairway section (2x)

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

M

7

2.10.1.2

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

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

M

2.10.1.3

<type_code>nts:type_code_enum</type_code>

Type of geographical object (default=FWY)

M

2.10.1.4

<position_code>nts:position_code_enum</position_code>

Describes the position related to the fairway

C

2.10.1.5s

Fairway section begin and end coordinates (2x)

C

7

2.10.1.5.1

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

[d]d mm.mmm[m] N

M

5

2.10.1.5.2

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

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

M

5

2.10.1.5e

</coordinate>

2.10.1.6

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

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

C

2.10.1e

</geo_object>

2.10.2s

Fairway section limitations

C

2.10.2.1s

<limitation_period>

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

C

2.10.2.1.1

<date_start>xs:date</date_start>

Start date of limitation period (overall) INCLUDING time zone

format=yyyy-mm-dd+hh:mm

M

5

2.10.2.1.2

<date_end>xs:date</date_end>

End date of limitation period INCLUDING time zone

format=yyyy-mm-dd+hh:mm

C

2.10.2.1.3

<time_start>xs:time</time_start>

Start time of limitation period WITHOUT time zone

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

C

2.10.2.1.4

<time_end>xs:time</time_end>

End time of limitation period WITHOUT time zone

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

C

2.10.2.1.5

<interval_code>nts:interval_code_enum</interval_code>

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

C

2.10.2.1e

</limitation_period>

2.10.2.2

<limitation_code>nts:limitation_code_enum</limitation_code>

Kind of limitation

M

5

2.10.2.3

<position_code>nts:position_code_enum</position_code>

Describes the position of the limitation related to the fairway

C

2.10.2.4

<value>xs:float</value>

Value of limitation (i.e. max draught)

C

2.10.2.5

Unit of the value of the limitation

C

2.10.2.6

<reference_code>nts:reference_code_enum</reference_code>

Value reference

C

2.10.2.7

<indication_code>nts:indication_code_enum</indication_code>

Minimum or maximum or reduced by

C

2.10.2.8s

<target_group>

Target group information

C

2.10.2.8.1

<target_group_code>nts:target_group_code_enum</target_group_code>

Target group (vessel type) for this limitation

M

5

2.10.2.8.2

<direction_code>nts:direction_code_enum</direction_code>

Upstream or downstream traffic, or both

M

5

2.10.2.8e

</target_group>

2.10.2e

</limitation>

2.10e

</fairway_section>

2.11s

Object section

C

2

2.11.1s

<geo_object>

Geo Information of object

M

5

2.11.1.1

ISRS Location Code of the object (1x)

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

M

8

2.11.1.2

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

Local name of the aggregated object

M

2.11.1.3

<type_code>nts:type_code_enum</type_code>

Type of geographical object

M

2.11.1.4

<position_code>nts:position_code_enum</position_code>

Describes the position related to the object

C

2.11.1.5s

Object coordinates (1x)

C

8

2.11.1.5.1

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

[d]d mm.mmm[m] N

M

5

2.11.1.5.2

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

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

M

5

2.11.1.5e

</coordinate>

2.11.1.6

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

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

C

2.11.1e

</geo_object>

2.11.2s

Object limitation section

C

2.11.2.1s

<limitation_period>

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

C

2.11.2.1.1

<date_start>xs:date</date_start>

Start date of limitation period (overall) INCLUDING time zone

format=yyyy-mm-dd+hh:mm

M

5

2.11.2.1.2

<date_end>xs:date</date_end>

End date of limitation period INCLUDING time zone

format=yyyy-mm-dd+hh:mm

C

2.11.2.1.3

<time_start>xs:time</time_start>

Start time of limitation period WITHOUT time zone

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

C

2.11.2.1.4

<time_end>xs:time</time_end>

End time of limitation period WITHOUT time zone

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

C

2.11.2.1.5

<interval_code>nts:interval_code_enum</interval_code>

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

C

2.11.2.1e

</limitation_period>

2.11.2.2

<limitation_code>nts:limitation_code_enum</limitation_code>

Kind of limitation

M

5

2.11.2.3

<position_code>nts:position_code_enum</position_code>

Describes the position of the limitation related to the fairway

C

2.11.2.4

<value>xs:float</value>

Value of limitation (i.e. max draught)

C

2.11.2.5

Unit of the value of the limitation

C

2.11.2.6

<reference_code>nts:reference_code_enum</reference_code>

Value reference

C

2.11.2.7

<indication_code>nts:indication_code_enum</indication_code>

Minimum or maximum or reduced by

C

2.11.2.8s

<target_group>

Target group information

C

2.11.2.8.1

<target_group_code>nts:target_group_code_enum</target_group_code>

Target group (vessel type) for this limitation

M

5

2.11.2.8.2

<direction_code>nts:direction_code_enum</direction_code>

Upstream or downstream traffic, or both

M

5

2.11.2.8e

</target_group>

2.11.2e

</limitation>

2.11e

</object>

2e

</ftm>

3s

<wrm>

Water related section

C

1

3.1

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

Internal ID

C

3.2s

<nts_number>

NtS Number

C

3.2.1

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

Name of the publishing organisation (NtS Provider)

M

5

3.2.2

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

Current year of the notice

M

5

3.2.3

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

Number of the notice

(see Developers Guide for WRM-Message Number generation)

M

5

3.2.4

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

Serial number of the notice

(see Developers Guide for WRM-Message Serial Number generation)

M

5

3.2e

</nts_number>

3.3s

<validity_period>

Overall period of validity

M

3.3.1

<date_start>xs:date</date_start>

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

M

3.3.2

<date_end>xs:date</date_end>

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

C

3.3e

</validity_period>

3.4s

<geo_object>

Geo Information of measurement location

M

5

3.4.1

ISRS Location Code of the object/fairway (1x or 2x)

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

M

9

3.4.2

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

Local name of the object/fairway

M

3.4.3

<type_code>nts:type_code_enum</type_code>

Type of geographical object/fairway

M

3.4.4

<position_code>nts:position_code_enum</position_code>

Describes the position related to the object/fairway

C

3.4.5s

Object/Fairway coordinates (1x or 2x)

C

9

3.4.5.1

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

[d]d mm.mmm[m] N

M

5

3.4.5.2

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

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

M

5

3.3.5e

</coordinate>

3.3.6

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

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

C

3.4e

</geo_object>

3.5

<reference_code>nts:reference_code_enum</reference_code>

Value reference (measurement reference)

C

6

3.6s

Measurements (normal or predicted values)

M

5

3.6.1

<predicted>xs:boolean</predicted>

Predicted measurement (1 or true) or real measurement (0 or false)

M

3.6.2

<measure_code>nts:measure_code_enum</measure_code>

Kind of water related information

M

3.6.3

<value>xs:float</value>

Measured or predicted value

C

10

3.6.4

<value_min>xs:float</value_min>

Lowest value of confidence interval

C

3.6.5

<value_max>xs:float</value_max>

Highest value of confidence interval

C

3.6.6

Unit of the water related value

C

3.6.7

<barrage_code>nts:barrage_code_enum</barrage_code>

Barrage status

C

11

3.6.8

<regime_code>nts:regime_code_enum</regime_code>

Regime applicable

C

12

3.6.9

<measuredate>xs:dateTime</measuredate>

Date and Time of measurement or predicted value including time zone

Format=yyyy-mm-ddThh:mm:ss+hh:mm

M

3.6.10s

Difference with comparative value

C

3.6.10.1

<value_difference>xs:float</value_difference>

Difference with comparative value

M

5

3.6.10.2

<time_difference>xs:duration</time_difference>

Time difference to measuredate of comparative value

M

5

3.6.10e

</difference>

3.6e

</measure>

3e

</wrm>

4s

<icem>

Ice related section

C

1

4.1

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

Internal ID

C

4.2s

<nts_number>

NtS Number

M

4.2.1

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

Name of the publishing organisation (NtS Provider)

M

4.2.2

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

Current year of the notice

M

4.2.3

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

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

M

4.2.4

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

Serial number of notice, original notice: 0

M

4.2e

</nts_number>

4.3s

<validity_period>

Overall period of validity

M

4.3.1

<date_start>xs:date</date_start>

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

M

4.3.2

<date_end>xs:date</date_end>

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

C

4.3e

</validity_period>

4.4s

<fairway_section>

Fairway section — the limitation inside the fairway section cannot be used in the ICEM

M

5

4.4.1s

<geo_object>

Geo Information of fairway

M

5

4.4.1.1

ISRS Location Code of the fairway section (2x)

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

M

4.4.1.2

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

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

M

4.4.1.3

<type_code>nts:type_code_enum</type_code>

Type of geographical object (default=FWY)

M

4.4.1.4

<position_code>nts:position_code_enum</position_code>

Describes the position related to the fairway

C

4.4.1.5s

Fairway section begin and end coordinates (2x)

C

7

4.4.1.5.1

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

[d]d mm.mmm[m] N

M

5

4.4.1.5.2

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

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

M

5

4.4.1.5e

</coordinate>

4.4.1.6

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

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

C

4.4.1e

</geo_object>

4.4e

</fairway_section>

4.5s

<ice_condition>

Ice conditions

M

4.5.1

<measuredate>xs:dateTime</measuredate>

Date and Time of measurement or prediction including time zone

Format=yyyy-mm-ddThh:mm:ss+hh:mm

M

4.5.2

<ice_condition_code>nts:ice_condition_code_enum</ice_condition_code>

Condition code

C

4

4.5.3

<ice_accessibility_code>nts:ice_accessibility_code_enum</ice_accessibility_code>

Accessibility code

C

4

4.5.4

<ice_classification_code>nts:ice_classification_code_enum</ice_classification_code>

Classification code

C

4

4.5.5

<ice_situation_code>nts:ice_situation_code_enum</ice_situation_code>

Situation code

C

4

4.5e

</ice_condition>

4e

</icem>

5s

<werm>

Weather related section

C

1

5.1

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

Internal ID

C

5.2s

<nts_number>

NtS Number

C

5.2.1

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

Name of the publishing organisation (NtS Provider)

M

5

5.2.2

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

Year of issuing of the notice

M

5

5.2.3

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

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

M

5

5.2.4

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

Serial number of notice, original notice: 0

M

5

5.2e

</nts_number>

5.3s

<validity_period>

Overall period of validity

M

13

5.3.1

<date_start>xs:date</date_start>

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

M

5.3.2

<date_end>xs:date</date_end>

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

C

5.3e

</validity_period>

5.4s

<fairway_section>

Fairway section

M

5.4.1s

<geo_object>

Geo Information of fairway

M

5.4.1.1

ISRS Location Code of the fairway section (2x)

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

M

7

5.4.1.2

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

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

M

5.4.1.3

<type_code>nts:type_code_enum</type_code>

Type of geographical object (default=FWY)

M

5.4.1.4

<position_code>nts:position_code_enum</position_code>

Describes the position related to the fairway

C

5.4.1.5s

Fairway section begin and end coordinates (2x)

C

7

5.4.1.5.1

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

[d]d mm.mmm[m] N

M

5

5.4.1.5.2

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

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

M

5

5.4.1.5e

</coordinate>

5.4.1.6

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

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

C

5.4.1e

</geo_object>

5.4e

</fairway_section>

5.5s

<weather_report>

Weather Report (1x or 2x)

M

5.5.1

<measuredate>xs:dateTime</measuredate>

Date and Time of measurement or predicted value including time zone

Format=yyyy-mm-ddThh:mm:ss+hh:mm

C

5.5.2

<forecast>xs:boolean</forecast>

Forecast (true or 1) OR Actual report (false or 0)

M

5.5.3

<weather_class_code>nts:weather_class_code_enum</weather_class_code>

Classification of weather report (0..Nx)

M

3

5.5.4s

<weather_item>

Weather items (0..Nx)

C

5.5.4.1

<weather_item_code>nts:weather_item_code_enum</weather_item_code>

Weather item type (Wind, Wave etc)

M

5

5.5.4.2

<value_min>xs:float</value_min>

Actual or Minimum value

M

5

5.5.4.3

<value_max>xs:float</value_max>

Maximum value

C

5.5.4.4

<value_gusts>xs:float</value_gusts>

Gusts value (Wind)

C

5.5.4.5

Unit of the value

C

5.5.4.6

<weather_category_code>nts:weather_category_code_enum</weather_category_code>

Classification of wind report

C

5.5.4.7

<direction_code_min>nts:weather_direction_code_enum</direction_code_min>

Direction of wind or wave

C

5.5.4.8

<direction_code_max>nts:weather_direction_code_enum</direction_code_max>

Direction of wind or wave

C

5.5.4e

</weather_item>

5.5e

</weather_report>

5e

</werm>

Legend for Occurrence (Occ.):

Mandatory (M)

Conditional (C)

Rules applicable to table "NtS XSD V.4.0.4.0":

1. In one <RIS Message> at least two sections have to be filled in:

— the <identification> section (1),

— one of the following sections:

— — <ftm> (fairway and traffic related messages) (2),

— <wrm> (water related message) (3),

— <icem> (ice message) (4),

— <werm> (weather related message) (5).

2. At least one of the Group 2.10 (<fairway section>) or Group 2.11 (<object>) has to be given within <ftm>.

3. A combinations of <weather_class_code> tags (5.5.3) in section <weather_report> can be given.

4. In group 4.5 (<ice condition>) at least one of the conditional elements 4.5.2 to 4.5.5 have to be given.

5. If a conditional group contains mandatory subgroups or elements these will only be mandatory if the group on the higher level is applied.

6. Element <reference_code> is only mandatory for "WAL" (water level) in <wrm> (3.5).

7. A <geo_object> in <fairway section> (<ftm> 2.10.1 , <icem> 4.4.1, <werm> 5.4.1) is defined by the begin and end

ISRS Location Codes and coordinates (2 ISRS Location Codes and 2 sets of coordinates).

8. A <geo_object> in <object> section (<ftm> 2.11.1) is defined by the ISRS Location Code and coordinates of its center point (1 ISRS Location Code 1 set of coordinates).

9. A <geo_object> in <wrm> has 2 ISRS Location Codes and 2 sets of coordinates in case the <type_code> (3.4.3) is "FWY", "RIV" or "CAN", otherwise only 1 ISRS Location Code and 1 set of coordinates has to be given.

10. If there is a measurement the elements <value> (3.6.3) or <value_min> (3.6.4) and <value_max> (3.6.5) is/are mandatory if <measure_code> (3.6.2) is either "DIS", "VER", "LSD" or "WAL".

In case there is no measurement (and a message should be sent anyhow) the value elements shall be omitted.

11. Element <barrage_code> (3.6.7) is mandatory if <measure code> (3.6.2) is "BAR".

12. Element <regime_code> (3.6.8) is mandatory if <measure code> (3.6.2) is "REG".

13. Predictions for more than one <validity_period> (5.3) require individual <werm> messages.

14. In case of <icem> (4.4.2) and <werm> a <limitation> section is not applicable. Limitations shall be provided via FTM notices.

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema xmlns:nts="http://www.ris.eu/nts/4.0.4.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace=">http://www.ris.eu/nts/4.0.4.0" elementFormDefault="qualified" attributeFormDefault="unqualified" version="4.0.4.0">

<!--

===========================================

= definition of main element RIS_Message =

= and corresponding type RIS_Message_Type =

===========================================

-->

<xs:element name="RIS_Message" type="nts:RIS_Message_Type">

<xs:annotation>

<xs:documentation>River Information Service Message</xs:documentation>

</xs:annotation>

</xs:element>

<xs:complexType name="RIS_Message_Type">

<xs:sequence>

<xs:element name="identification" type="nts:identification_type">

<xs:annotation>

<xs:documentation>Identification section</xs:documentation>

</xs:annotation>

</xs:element>

<xs:choice>

<xs:annotation>

<xs:documentation>One msg contains one of these sections</xs:documentation>

</xs:annotation>

<xs:element name="ftm" type="nts:ftm_type" maxOccurs="unbounded">

<xs:annotation>

<xs:documentation>Fairway and traffic related section</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="wrm" type="nts:wrm_type" maxOccurs="unbounded">

<xs:annotation>

<xs:documentation>Water related section</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="icem" type="nts:icem_type" maxOccurs="unbounded">

<xs:annotation>

<xs:documentation>Ice related section</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="werm" type="nts:werm_type" maxOccurs="unbounded">

<xs:annotation>

<xs:documentation>Weather related section</xs:documentation>

</xs:annotation>

</xs:element>

</xs:choice>

</xs:sequence>

</xs:complexType>

<!--

==========================================

= definition of identification_type, =

= used in definition of RIS_Message_Type =

==========================================

-->

<xs:complexType name="identification_type">

<xs:sequence>

<xs:element name="internal_id" type="nts:internal_id_type" minOccurs="0">

<xs:annotation>

<xs:documentation>Internal ID</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="from">

<xs:annotation>

<xs:documentation>Sender (System) of the message</xs:documentation>

</xs:annotation>

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:maxLength value="64"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="originator">

<xs:annotation>

<xs:documentation>Originator (initiator) of the information in this message</xs:documentation>

</xs:annotation>

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:maxLength value="64"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="country_code" type="nts:country_code_enum">

<xs:annotation>

<xs:documentation>Country where message is valid</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="language_code" type="nts:language_code_enum">

<xs:annotation>

<xs:documentation>Original language used in the textual info. (contents)</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="district" minOccurs="0">

<xs:annotation>

<xs:documentation>District / Region within the specified country, where the message is applicable</xs:documentation>

</xs:annotation>

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:maxLength value="64"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="date_issue" type="xs:dateTime">

<xs:annotation>

<xs:documentation>Date and time of publication including time zone</xs:documentation>

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<!--

===================================================

= types used in definition of identification_type =

===================================================

-->

<xs:simpleType name="country_code_enum">

<xs:restriction base="xs:string">

<xs:maxLength value="2"/>

<xs:enumeration value="AT"/>

<xs:enumeration value="BE"/>

<xs:enumeration value="BG"/>

<xs:enumeration value="CH"/>

<xs:enumeration value="CY"/>

<xs:enumeration value="CZ"/>

<xs:enumeration value="DE"/>

<xs:enumeration value="DK"/>

<xs:enumeration value="EE"/>

<xs:enumeration value="ES"/>

<xs:enumeration value="FI"/>

<xs:enumeration value="FR"/>

<xs:enumeration value="GB"/>

<xs:enumeration value="GR"/>

<xs:enumeration value="HR"/>

<xs:enumeration value="HU"/>

<xs:enumeration value="IE"/>

<xs:enumeration value="IT"/>

<xs:enumeration value="LT"/>

<xs:enumeration value="LU"/>

<xs:enumeration value="LV"/>

<xs:enumeration value="MD"/>

<xs:enumeration value="ME"/>

<xs:enumeration value="MT"/>

<xs:enumeration value="NL"/>

<xs:enumeration value="PL"/>

<xs:enumeration value="PT"/>

<xs:enumeration value="RO"/>

<xs:enumeration value="RS"/>

<xs:enumeration value="SE"/>

<xs:enumeration value="SI"/>

<xs:enumeration value="SK"/>

<xs:enumeration value="RU"/>

<xs:enumeration value="UA"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="language_code_enum">

<xs:restriction base="xs:string">

<xs:maxLength value="2"/>

<xs:enumeration value="DE"/>

<xs:enumeration value="EN"/>

<xs:enumeration value="FR"/>

<xs:enumeration value="NL"/>

<xs:enumeration value="SK"/>

<xs:enumeration value="HU"/>

<xs:enumeration value="HR"/>

<xs:enumeration value="SR"/>

<xs:enumeration value="BG"/>

<xs:enumeration value="RO"/>

<xs:enumeration value="RU"/>

<xs:enumeration value="CS"/>

<xs:enumeration value="PL"/>

<xs:enumeration value="PT"/>

<xs:enumeration value="ES"/>

<xs:enumeration value="SV"/>

<xs:enumeration value="FI"/>

<xs:enumeration value="DA"/>

<xs:enumeration value="ET"/>

<xs:enumeration value="LV"/>

<xs:enumeration value="LT"/>

<xs:enumeration value="IT"/>

<xs:enumeration value="MT"/>

<xs:enumeration value="EL"/>

<xs:enumeration value="SL"/>

</xs:restriction>

</xs:simpleType>

<!--

==========================================

= definition of ftm_type, =

= used in definition of RIS_Message_Type =

==========================================

-->

<xs:complexType name="ftm_type">

<xs:sequence>

<xs:element name="internal_id" type="nts:internal_id_type" minOccurs="0">

<xs:annotation>

<xs:documentation>Internal ID</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="nts_number" type="nts:nts_number_type">

<xs:annotation>

<xs:documentation>NtS Number</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="target_group" type="nts:target_group_type" minOccurs="0" maxOccurs="unbounded">

<xs:annotation>

<xs:documentation>Target group information</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="subject_code" type="nts:subject_code_enum">

<xs:annotation>

<xs:documentation>Subject code must contain one of the following: Announcement (ANNOUN), Warning (WARNIN), Notice withdrawn (CANCEL) or Information service (INFSER). More information on the use of codes can be found in the NtS Encoding Guide.</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="validity_period" type="nts:validity_period_type">

<xs:annotation>

<xs:documentation>Overall period of validity</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="contents" minOccurs="0">

<xs:annotation>

<xs:documentation>Additional information in local language</xs:documentation>

</xs:annotation>

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:maxLength value="500"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="source" minOccurs="0">

<xs:annotation>

<xs:documentation>Notice source (name of authority)</xs:documentation>

</xs:annotation>

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:maxLength value="64"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="reason_code" type="nts:reason_code_enum" minOccurs="0">

<xs:annotation>

<xs:documentation>Reason / justification of the notice</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="communication" type="nts:communication_type" minOccurs="0" maxOccurs="unbounded">

<xs:annotation>

<xs:documentation>Communication channel information</xs:documentation>

</xs:annotation>

</xs:element>

<xs:choice maxOccurs="unbounded">

<xs:element name="fairway_section" type="nts:fairway_section_type">

<xs:annotation>

<xs:documentation>Fairway section</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="object" type="nts:object_type">

<xs:annotation>

<xs:documentation>Object section</xs:documentation>

</xs:annotation>

</xs:element>

</xs:choice>

</xs:sequence>

</xs:complexType>

<!--

========================================

= types used in definition of ftm_type =

========================================

-->

<xs:simpleType name="subject_code_enum">

<xs:restriction base="xs:string">

<xs:minLength value="3"/>

<xs:maxLength value="6"/>

<xs:enumeration value="ANNOUN"/>

<xs:enumeration value="WARNIN"/>

<xs:enumeration value="CANCEL"/>

<xs:enumeration value="INFSER"/>

<xs:enumeration value="OBSTRU"/>

<xs:enumeration value="PAROBS"/>

<xs:enumeration value="DELAY"/>

<xs:enumeration value="VESLEN"/>

<xs:enumeration value="VESHEI"/>

<xs:enumeration value="VESBRE"/>

<xs:enumeration value="VESDRA"/>

<xs:enumeration value="AVALEN"/>

<xs:enumeration value="CLEHEI"/>

<xs:enumeration value="CLEWID"/>

<xs:enumeration value="AVADEP"/>

<xs:enumeration value="NOMOOR"/>

<xs:enumeration value="SERVIC"/>

<xs:enumeration value="NOSERV"/>

<xs:enumeration value="SPEED"/>

<xs:enumeration value="WAVWAS"/>

<xs:enumeration value="PASSIN"/>

<xs:enumeration value="ANCHOR"/>

<xs:enumeration value="OVRTAK"/>

<xs:enumeration value="MINPWR"/>

<xs:enumeration value="DREDGE"/>

<xs:enumeration value="WORK"/>

<xs:enumeration value="EVENT"/>

<xs:enumeration value="CHGMAR"/>

<xs:enumeration value="CHGSER"/>

<xs:enumeration value="SPCMAR"/>

<xs:enumeration value="EXERC"/>

<xs:enumeration value="LEADEP"/>

<xs:enumeration value="LEVDEC"/>

<xs:enumeration value="LEVRIS"/>

<xs:enumeration value="LIMITA"/>

<xs:enumeration value="MISECH"/>

<xs:enumeration value="ECDISU"/>

<xs:enumeration value="NEWOBJ"/>

<xs:enumeration value="CHWWY"/>

<xs:enumeration value="CONWWY"/>

<xs:enumeration value="DIVER"/>

<xs:enumeration value="SPECTR"/>

<xs:enumeration value="LOCRUL"/>

<xs:enumeration value="VHFCOV"/>

<xs:enumeration value="HIGVOL"/>

<xs:enumeration value="TURNIN"/>

<xs:enumeration value="CONBRE"/>

<xs:enumeration value="CONLEN"/>

<xs:enumeration value="REMOBJ"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="reason_code_enum">

<xs:restriction base="xs:string">

<xs:minLength value="3"/>

<xs:maxLength value="6"/>

<xs:enumeration value="EVENT"/>

<xs:enumeration value="WORK"/>

<xs:enumeration value="DREDGE"/>

<xs:enumeration value="EXERC"/>

<xs:enumeration value="HIGWAT"/>

<xs:enumeration value="HIWAI"/>

<xs:enumeration value="HIWAII"/>

<xs:enumeration value="LOWWAT"/>

<xs:enumeration value="SHALLO"/>

<xs:enumeration value="CALAMI"/>

<xs:enumeration value="LAUNCH"/>

<xs:enumeration value="DECLEV"/>

<xs:enumeration value="FLOMEA"/>

<xs:enumeration value="BLDWRK"/>

<xs:enumeration value="REPAIR"/>

<xs:enumeration value="INSPEC"/>

<xs:enumeration value="FIRWRK"/>

<xs:enumeration value="LIMITA"/>

<xs:enumeration value="CHGFWY"/>

<xs:enumeration value="CONSTR"/>

<xs:enumeration value="DIVING"/>

<xs:enumeration value="SPECTR"/>

<xs:enumeration value="EXT"/>

<xs:enumeration value="MIN"/>

<xs:enumeration value="SOUND"/>

<xs:enumeration value="OTHER"/>

<xs:enumeration value="STRIKE"/>

<xs:enumeration value="FLOMAT"/>

<xs:enumeration value="EXPLOS"/>

<xs:enumeration value="ICE"/>

<xs:enumeration value="OBSTAC"/>

<xs:enumeration value="CHGMAR"/>

<xs:enumeration value="DAMMAR"/>

<xs:enumeration value="FALMAT"/>

<xs:enumeration value="MISECH"/>

<xs:enumeration value="HEARIS"/>

<xs:enumeration value="HIGVOL"/>

<xs:enumeration value="ECDISU"/>

<xs:enumeration value="LOCRUL"/>

<xs:enumeration value="NEWOBJ"/>

<xs:enumeration value="OBUNWA"/>

<xs:enumeration value="VHFCOV"/>

<xs:enumeration value="REMOBJ"/>

<xs:enumeration value="LEVRIS"/>

<xs:enumeration value="SPCMAR"/>

<xs:enumeration value="WERMCO"/>

<xs:enumeration value="INFSER"/>

</xs:restriction>

</xs:simpleType>

<xs:complexType name="communication_type">

<xs:sequence>

<xs:element name="reporting_code" type="nts:reporting_code_enum">

<xs:annotation>

<xs:documentation>Reporting regime (information, or duty to report)</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="communication_code" type="nts:communication_code_enum">

<xs:annotation>

<xs:documentation>Communication code (telephone, VHF etc.)</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="number" minOccurs="0">

<xs:annotation>

<xs:documentation>Telephone, VHF number (including callsign), e-mail address, URL or teletext</xs:documentation>

</xs:annotation>

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:maxLength value="128"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="label" minOccurs="0">

<xs:annotation>

<xs:documentation>Name of the attachment or additional information</xs:documentation>

</xs:annotation>

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:maxLength value="256"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="remark" minOccurs="0">

<xs:annotation>

<xs:documentation>Additional remarks concerning the communication</xs:documentation>

</xs:annotation>

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:maxLength value="1024"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:simpleType name="reporting_code_enum">

<xs:restriction base="xs:string">

<xs:maxLength value="3"/>

<xs:enumeration value="INF"/>

<xs:enumeration value="ADD"/>

<xs:enumeration value="REG"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="communication_code_enum">

<xs:restriction base="xs:string">

<xs:maxLength value="3"/>

<xs:enumeration value="TE"/>

<xs:enumeration value="AP"/>

<xs:enumeration value="EM"/>

<xs:enumeration value="AH"/>

<xs:enumeration value="TT"/>

<xs:enumeration value="FX"/>

<xs:enumeration value="LS"/>

<xs:enumeration value="FS"/>

<xs:enumeration value="SO"/>

<xs:enumeration value="EI"/>

</xs:restriction>

</xs:simpleType>

<xs:complexType name="object_type">

<xs:sequence>

<xs:element name="geo_object" type="nts:geo_object_type">

<xs:annotation>

<xs:documentation>Geo Information of object</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="limitation" type="nts:limitation_type" minOccurs="0" maxOccurs="unbounded">

<xs:annotation>

<xs:documentation>Object limitation section</xs:documentation>

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<!--

==========================================

= definition of wrm_type, =

= used in definition of RIS_Message_Type =

==========================================

-->

<xs:complexType name="wrm_type">

<xs:sequence>

<xs:element name="internal_id" type="nts:internal_id_type" minOccurs="0">

<xs:annotation>

<xs:documentation>Internal ID</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="nts_number" type="nts:nts_number_type" minOccurs="0">

<xs:annotation>

<xs:documentation>NtS Number</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="validity_period" type="nts:validity_period_type">

<xs:annotation>

<xs:documentation>Overall period of validity</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="geo_object" type="nts:geo_object_type">

<xs:annotation>

<xs:documentation>Object section</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="reference_code" type="nts:reference_code_enum" minOccurs="0">

<xs:annotation>

<xs:documentation>Value reference (measurement reference)</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="measure" type="nts:measure_type" maxOccurs="unbounded">

<xs:annotation>

<xs:documentation>Measurements (normal or predicted values)</xs:documentation>

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<!--

========================================

= types used in definition of wrm_type =

========================================

-->

<xs:complexType name="measure_type">

<xs:sequence>

<xs:element name="predicted" type="xs:boolean">

<xs:annotation>

<xs:documentation>Predicted measurement (1 or true) or real measurement (0 or false)</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="measure_code" type="nts:measure_code_enum">

<xs:annotation>

<xs:documentation>Kind of water related information</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="value" type="xs:float" minOccurs="0">

<xs:annotation>

<xs:documentation>Measured or predicted value</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="value_min" type="xs:float" minOccurs="0">

<xs:annotation>

<xs:documentation>Lowest value of confidence interval</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="value_max" type="xs:float" minOccurs="0">

<xs:annotation>

<xs:documentation>Highest value of confidence interval</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="unit" type="nts:unit_enum" minOccurs="0">

<xs:annotation>

<xs:documentation>Unit of the water related value</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="barrage_code" type="nts:barrage_code_enum" minOccurs="0">

<xs:annotation>

<xs:documentation>Barrage status</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="regime_code" type="nts:regime_code_enum" minOccurs="0">

<xs:annotation>

<xs:documentation>Regime applicable</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="measuredate" type="xs:dateTime">

<xs:annotation>

<xs:documentation>Date and Time of measurement or predicted value including time zone</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="difference" type="nts:difference_type" minOccurs="0">

<xs:annotation>

<xs:documentation>Difference with comparative value</xs:documentation>

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:simpleType name="measure_code_enum">

<xs:restriction base="xs:string">

<xs:maxLength value="3"/>

<xs:enumeration value="DIS"/>

<xs:enumeration value="REG"/>

<xs:enumeration value="BAR"/>

<xs:enumeration value="VER"/>

<xs:enumeration value="LSD"/>

<xs:enumeration value="WAL"/>

<xs:enumeration value="NOM"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="barrage_code_enum">

<xs:restriction base="xs:string">

<xs:maxLength value="3"/>

<xs:enumeration value="CLD"/>

<xs:enumeration value="OPG"/>

<xs:enumeration value="CLG"/>

<xs:enumeration value="OPD"/>

<xs:enumeration value="OPN"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="regime_code_enum">

<xs:restriction base="xs:string">

<xs:maxLength value="2"/>

<xs:enumeration value="NO"/>

<xs:enumeration value="HI"/>

<xs:enumeration value="II"/>

<xs:enumeration value="I"/>

<xs:enumeration value="NN"/>

<xs:enumeration value="LO"/>

</xs:restriction>

</xs:simpleType>

<xs:complexType name="difference_type">

<xs:sequence>

<xs:element name="value_difference" type="xs:float">

<xs:annotation>

<xs:documentation>Difference with comparative value</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="time_difference" type="xs:duration">

<xs:annotation>

<xs:documentation>Time difference with measuredata of comparative measurement</xs:documentation>

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<!--

==========================================

= definition of icem_type, =

= used in definition of RIS_Message_Type =

==========================================

-->

<xs:complexType name="icem_type">

<xs:sequence>

<xs:element name="internal_id" type="nts:internal_id_type" minOccurs="0">

<xs:annotation>

<xs:documentation>Internal ID</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="nts_number" type="nts:nts_number_type">

<xs:annotation>

<xs:documentation>NtS Number</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="validity_period" type="nts:validity_period_type">

<xs:annotation>

<xs:documentation>Overall period of validity</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="fairway_section" type="nts:fairway_section_type">

<xs:annotation>

<xs:documentation>Fairway section — the limitation inside the fairway section cannot be used in the ICEM</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="ice_condition" type="nts:ice_condition_type" maxOccurs="unbounded">

<xs:annotation>

<xs:documentation>Ice conditions</xs:documentation>

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<!--

=========================================

= types used in definition of icem_type =

=========================================

-->

<xs:complexType name="ice_condition_type">

<xs:sequence>

<xs:element name="measuredate" type="xs:dateTime">

<xs:annotation>

<xs:documentation>Date and Time of measurement or prediction including time zone</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="ice_condition_code" type="nts:ice_condition_code_enum" minOccurs="0">

<xs:annotation>

<xs:documentation>Condition code</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="ice_accessibility_code" type="nts:ice_accessibility_code_enum" minOccurs="0">

<xs:annotation>

<xs:documentation>Accessibility code </xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="ice_classification_code" type="nts:ice_classification_code_enum" minOccurs="0">

<xs:annotation>

<xs:documentation>Classification code </xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="ice_situation_code" type="nts:ice_situation_code_enum" minOccurs="0">

<xs:annotation>

<xs:documentation>Situation code </xs:documentation>

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:simpleType name="ice_condition_code_enum">

<xs:restriction base="xs:string">

<xs:maxLength value="1"/>

<xs:enumeration value="A"/>

<xs:enumeration value="B"/>

<xs:enumeration value="C"/>

<xs:enumeration value="D"/>

<xs:enumeration value="E"/>

<xs:enumeration value="F"/>

<xs:enumeration value="G"/>

<xs:enumeration value="H"/>

<xs:enumeration value="K"/>

<xs:enumeration value="L"/>

<xs:enumeration value="M"/>

<xs:enumeration value="P"/>

<xs:enumeration value="R"/>

<xs:enumeration value="S"/>

<xs:enumeration value="U"/>

<xs:enumeration value="O"/>

<xs:enumeration value="V"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="ice_accessibility_code_enum">

<xs:restriction base="xs:string">

<xs:maxLength value="1"/>

<xs:enumeration value="A"/>

<xs:enumeration value="B"/>

<xs:enumeration value="F"/>

<xs:enumeration value="L"/>

<xs:enumeration value="C"/>

<xs:enumeration value="D"/>

<xs:enumeration value="E"/>

<xs:enumeration value="G"/>

<xs:enumeration value="H"/>

<xs:enumeration value="M"/>

<xs:enumeration value="K"/>

<xs:enumeration value="T"/>

<xs:enumeration value="P"/>

<xs:enumeration value="V"/>

<xs:enumeration value="X"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="ice_classification_code_enum">

<xs:restriction base="xs:string">

<xs:maxLength value="1"/>

<xs:enumeration value="A"/>

<xs:enumeration value="B"/>

<xs:enumeration value="C"/>

<xs:enumeration value="D"/>

<xs:enumeration value="E"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="ice_situation_code_enum">

<xs:restriction base="xs:string">

<xs:maxLength value="3"/>

<xs:enumeration value="NOL"/>

<xs:enumeration value="LIM"/>

<xs:enumeration value="NON"/>

</xs:restriction>

</xs:simpleType>

<!--

===========================================

= definition of werm_type, =

= used in definition of RIS_Message_Type =

===========================================

-->

<xs:complexType name="werm_type">

<xs:sequence>

<xs:element name="internal_id" type="nts:internal_id_type" minOccurs="0">

<xs:annotation>

<xs:documentation>Internal ID</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="nts_number" type="nts:nts_number_type" minOccurs="0">

<xs:annotation>

<xs:documentation>NtS Number</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="validity_period" type="nts:validity_period_type">

<xs:annotation>

<xs:documentation>Overall period of validity</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="fairway_section" type="nts:fairway_section_werm_type">

<xs:annotation>

<xs:documentation>Fairway section</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="weather_report" type="nts:weather_report_type" maxOccurs="2">

<xs:annotation>

<xs:documentation>Actual or Forecast report sections</xs:documentation>

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<!--

=========================================

= types used in definition of werm_type =

=========================================

-->

<xs:complexType name="fairway_section_werm_type">

<xs:sequence>

<xs:element name="geo_object" type="nts:geo_object_type">

<xs:annotation>

<xs:documentation>Geo Information of fairway</xs:documentation>

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:complexType name="weather_report_type">

<xs:sequence>

<xs:element name="measuredate" type="xs:dateTime" minOccurs="0">

<xs:annotation>

<xs:documentation>Date and time of measurement or predicted value including time zone</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="forecast" type="xs:boolean">

<xs:annotation>

<xs:documentation>Forecast (true or 1) OR Actual report (false or 0)</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="weather_class_code" type="nts:weather_class_code_enum" maxOccurs="unbounded">

<xs:annotation>

<xs:documentation>Classification of weather report</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="weather_item" type="nts:weather_item_type" minOccurs="0" maxOccurs="unbounded">

<xs:annotation>

<xs:documentation>Weather items</xs:documentation>

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:simpleType name="weather_class_code_enum">

<xs:restriction base="xs:string">

<xs:maxLength value="6"/>

<xs:enumeration value="CLR"/>

<xs:enumeration value="CLDY"/>

<xs:enumeration value="OCST"/>

<xs:enumeration value="DZZL"/>

<xs:enumeration value="RAIN"/>

<xs:enumeration value="LRAIN"/>

<xs:enumeration value="ORAIN"/>

<xs:enumeration value="HRAIN"/>

<xs:enumeration value="SLEET"/>

<xs:enumeration value="SNOW"/>

<xs:enumeration value="SNFALL"/>

<xs:enumeration value="HAIL"/>

<xs:enumeration value="SHWRS"/>

<xs:enumeration value="THSTRM"/>

<xs:enumeration value="HAZY"/>

<xs:enumeration value="FOG"/>

<xs:enumeration value="FOGPAT"/>

<xs:enumeration value="GALE"/>

<xs:enumeration value="STRM"/>

<xs:enumeration value="HURRC"/>

<xs:enumeration value="FZRA"/>

</xs:restriction>

</xs:simpleType>

<xs:complexType name="weather_item_type">

<xs:sequence>

<xs:element name="weather_item_code" type="nts:weather_item_code_enum">

<xs:annotation>

<xs:documentation>Weather item type (Wind, Wave etc)</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="value_min" type="xs:float">

<xs:annotation>

<xs:documentation>Actual or Minimum value</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="value_max" type="xs:float" minOccurs="0">

<xs:annotation>

<xs:documentation>Maximum value</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="value_gusts" type="xs:float" minOccurs="0">

<xs:annotation>

<xs:documentation>Gusts value (Wind)</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="unit" type="nts:unit_enum" minOccurs="0">

<xs:annotation>

<xs:documentation>Unit of the value</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="weather_category_code" type="nts:weather_category_code_enum" minOccurs="0">

<xs:annotation>

<xs:documentation>Classification of wind report</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="direction_code_min" type="nts:weather_direction_code_enum" minOccurs="0">

<xs:annotation>

<xs:documentation>Direction of wind or wave</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="direction_code_max" type="nts:weather_direction_code_enum" minOccurs="0">

<xs:annotation>

<xs:documentation>Direction of wind or wave</xs:documentation>

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:simpleType name="weather_item_code_enum">

<xs:restriction base="xs:string">

<xs:maxLength value="2"/>

<xs:enumeration value="WI"/>

<xs:enumeration value="WA"/>

<xs:enumeration value="FG"/>

<xs:enumeration value="RN"/>

<xs:enumeration value="SN"/>

<xs:enumeration value="AT"/>

<xs:enumeration value="WT"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="weather_category_code_enum">

<xs:restriction base="xs:string">

<xs:maxLength value="2"/>

<xs:enumeration value="0"/>

<xs:enumeration value="1"/>

<xs:enumeration value="2"/>

<xs:enumeration value="3"/>

<xs:enumeration value="4"/>

<xs:enumeration value="5"/>

<xs:enumeration value="6"/>

<xs:enumeration value="7"/>

<xs:enumeration value="8"/>

<xs:enumeration value="9"/>

<xs:enumeration value="10"/>

<xs:enumeration value="11"/>

<xs:enumeration value="12"/>

<xs:enumeration value="13"/>

<xs:enumeration value="14"/>

<xs:enumeration value="15"/>

<xs:enumeration value="16"/>

<xs:enumeration value="17"/>

<xs:enumeration value="18"/>

<xs:enumeration value="19"/>

<xs:enumeration value="20"/>

<xs:enumeration value="21"/>

<xs:enumeration value="22"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="weather_direction_code_enum">

<xs:restriction base="xs:string">

<xs:maxLength value="3"/>

<xs:enumeration value="N"/>

<xs:enumeration value="NE"/>

<xs:enumeration value="E"/>

<xs:enumeration value="SE"/>

<xs:enumeration value="S"/>

<xs:enumeration value="SW"/>

<xs:enumeration value="W"/>

<xs:enumeration value="NW"/>

<xs:enumeration value="WRB"/>

</xs:restriction>

</xs:simpleType>

<!--

=====================================

= types used in several definitions =

=====================================

-->

<xs:simpleType name="internal_id_type">

<xs:annotation>

<xs:documentation>Internal ID — best practice: global unique identifier</xs:documentation>

</xs:annotation>

<xs:restriction base="xs:string">

<xs:maxLength value="64"/>

</xs:restriction>

</xs:simpleType>

<xs:complexType name="nts_number_type">

<xs:sequence>

<xs:element name="organisation">

<xs:annotation>

<xs:documentation>Name of the publishing organisation (NtS Provider)</xs:documentation>

</xs:annotation>

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:maxLength value="64"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="year">

<xs:annotation>

<xs:documentation>Year of first issuing of the notice</xs:documentation>

</xs:annotation>

<xs:simpleType>

<xs:restriction base="xs:gYear">

<xs:minInclusive value="1900"/>

<xs:maxInclusive value="9999"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="number">

<xs:annotation>

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

</xs:annotation>

<xs:simpleType>

<xs:restriction base="xs:integer">

<xs:minInclusive value="00000000"/>

<xs:maxInclusive value="99999999"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="serial_number">

<xs:annotation>

<xs:documentation>Serial number of notice (replacements and withdrawals), original notice: 0</xs:documentation>

</xs:annotation>

<xs:simpleType>

<xs:restriction base="xs:integer">

<xs:minInclusive value="00"/>

<xs:maxInclusive value="99"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:complexType name="validity_period_type">

<xs:sequence>

<xs:element name="date_start" type="xs:date">

<xs:annotation>

<xs:documentation>Start date of validity period including time zone</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="date_end" type="xs:date" minOccurs="0">

<xs:annotation>

<xs:documentation>End date of validity period including time zone</xs:documentation>

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:complexType name="fairway_section_type">

<xs:sequence>

<xs:element name="geo_object" type="nts:geo_object_type">

<xs:annotation>

<xs:documentation>Geo information of fairway</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="limitation" type="nts:limitation_type" minOccurs="0" maxOccurs="unbounded">

<xs:annotation>

<xs:documentation>Fairway section limitations</xs:documentation>

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:complexType name="geo_object_type">

<xs:sequence>

<xs:element name="id" type="nts:isrs_code_type" maxOccurs="2">

<xs:annotation>

<xs:documentation>ISRS Location Code of the fairway/object</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="name">

<xs:annotation>

<xs:documentation>Local name of the fairway section</xs:documentation>

</xs:annotation>

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:maxLength value="256"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="type_code" type="nts:type_code_enum" default="FWY">

<xs:annotation>

<xs:documentation>Type of geographical object</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="position_code" type="nts:position_code_enum" minOccurs="0">

<xs:annotation>

<xs:documentation>Describes the position related to the fairway</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="coordinate" type="nts:coordinate_type" minOccurs="0" maxOccurs="2">

<xs:annotation>

<xs:documentation>Fairway section begin and end coordinates</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="fairway_name" minOccurs="0">

<xs:annotation>

<xs:documentation>Waterway name (usefull if no RIS Index is available)</xs:documentation>

</xs:annotation>

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:maxLength value="256"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:simpleType name="isrs_code_type">

<xs:annotation>

<xs:documentation>ISRS location code, unique identification of the geo object as defined in RIS Index encoding guide</xs:documentation>

</xs:annotation>

<xs:restriction base="xs:string">

<xs:length value="20"/>

<xs:pattern value="[A-Z]{2}[A-Z]{3}[A-Z0-9]{5}[A-Z0-9]{5}[0-9]{5}" />

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="type_code_enum">

<xs:restriction base="xs:string">

<xs:maxLength value="3"/>

<xs:enumeration value="RIV"/>

<xs:enumeration value="CAN"/>

<xs:enumeration value="LAK"/>

<xs:enumeration value="FWY"/>

<xs:enumeration value="LCK"/>

<xs:enumeration value="BRI"/>

<xs:enumeration value="RMP"/>

<xs:enumeration value="BAR"/>

<xs:enumeration value="BNK"/>

<xs:enumeration value="GAU"/>

<xs:enumeration value="BUO"/>

<xs:enumeration value="BEA"/>

<xs:enumeration value="ANC"/>

<xs:enumeration value="BER"/>

<xs:enumeration value="MOO"/>

<xs:enumeration value="TER"/>

<xs:enumeration value="HAR"/>

<xs:enumeration value="FDO"/>

<xs:enumeration value="CAB"/>

<xs:enumeration value="FER"/>

<xs:enumeration value="PIP"/>

<xs:enumeration value="PPO"/>

<xs:enumeration value="HFA"/>

<xs:enumeration value="HMO"/>

<xs:enumeration value="SHY"/>

<xs:enumeration value="REF"/>

<xs:enumeration value="MAR"/>

<xs:enumeration value="LIG"/>

<xs:enumeration value="SIG"/>

<xs:enumeration value="TUR"/>

<xs:enumeration value="CBR"/>

<xs:enumeration value="TUN"/>

<xs:enumeration value="BCO"/>

<xs:enumeration value="REP"/>

<xs:enumeration value="FLO"/>

<xs:enumeration value="SLI"/>

<xs:enumeration value="DUK"/>

<xs:enumeration value="VTC"/>

<xs:enumeration value="RES"/>

<xs:enumeration value="LKB"/>

<xs:enumeration value="BRO"/>

<xs:enumeration value="BNS"/>

</xs:restriction>

</xs:simpleType>

<xs:complexType name="coordinate_type">

<xs:sequence>

<xs:element name="lat">

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:minLength value="10"/>

<xs:maxLength value="12"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="long">

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:minLength value="10"/>

<xs:maxLength value="13"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:complexType name="limitation_type">

<xs:sequence>

<xs:element name="limitation_period" type="nts:limitation_period_type" minOccurs="0" maxOccurs="unbounded">

<xs:annotation>

<xs:documentation>Limitation periods / intervals</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="limitation_code" type="nts:limitation_code_enum">

<xs:annotation>

<xs:documentation>Kind of limitation</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="position_code" type="nts:position_code_enum" minOccurs="0">

<xs:annotation>

<xs:documentation>Describes the position of the limitation related to the fairway</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="value" type="xs:float" minOccurs="0">

<xs:annotation>

<xs:documentation>Value of limitation (i.e. max draught)</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="unit" type="nts:unit_enum" minOccurs="0">

<xs:annotation>

<xs:documentation>Unit of the value of the limitation</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="reference_code" type="nts:reference_code_enum" minOccurs="0">

<xs:annotation>

<xs:documentation>Value reference</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="indication_code" type="nts:indication_code_enum" minOccurs="0">

<xs:annotation>

<xs:documentation>Minimum or maximum or reduced by</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="target_group" type="nts:target_group_type" minOccurs="0" maxOccurs="unbounded">

<xs:annotation>

<xs:documentation>Target group information</xs:documentation>

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:complexType name="limitation_period_type">

<xs:sequence>

<xs:element name="date_start" type="xs:date">

<xs:annotation>

<xs:documentation>Start date of limitation period including time zone</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="date_end" type="xs:date" minOccurs="0">

<xs:annotation>

<xs:documentation>End date of limitation period including time zone</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="time_start" type="xs:time" minOccurs="0">

<xs:annotation>

<xs:documentation>Start time of limitation period without time zone</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="time_end" type="xs:time" minOccurs="0">

<xs:annotation>

<xs:documentation>End time of limitation period without time zone</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="interval_code" type="nts:interval_code_enum" minOccurs="0">

<xs:annotation>

<xs:documentation>Interval for limitation if applicable</xs:documentation>

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:simpleType name="interval_code_enum">

<xs:restriction base="xs:string">

<xs:maxLength value="3"/>

<xs:enumeration value="CON"/>

<xs:enumeration value="DAY"/>

<xs:enumeration value="WRK"/>

<xs:enumeration value="WKN"/>

<xs:enumeration value="SUN"/>

<xs:enumeration value="MON"/>

<xs:enumeration value="TUE"/>

<xs:enumeration value="WED"/>

<xs:enumeration value="THU"/>

<xs:enumeration value="FRI"/>

<xs:enumeration value="SAT"/>

<xs:enumeration value="DTI"/>

<xs:enumeration value="NTI"/>

<xs:enumeration value="RVI"/>

<xs:enumeration value="EXC"/>

<xs:enumeration value="WRD"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="limitation_code_enum">

<xs:restriction base="xs:string">

<xs:maxLength value="6"/>

<xs:enumeration value="OBSTRU"/>

<xs:enumeration value="PAROBS"/>

<xs:enumeration value="DELAY"/>

<xs:enumeration value="VESLEN"/>

<xs:enumeration value="VESHEI"/>

<xs:enumeration value="VESBRE"/>

<xs:enumeration value="VESDRA"/>

<xs:enumeration value="AVALEN"/>

<xs:enumeration value="CLEHEI"/>

<xs:enumeration value="CLEWID"/>

<xs:enumeration value="AVADEP"/>

<xs:enumeration value="NOMOOR"/>

<xs:enumeration value="SERVIC"/>

<xs:enumeration value="NOSERV"/>

<xs:enumeration value="SPEED"/>

<xs:enumeration value="WAVWAS"/>

<xs:enumeration value="PASSIN"/>

<xs:enumeration value="ANCHOR"/>

<xs:enumeration value="OVRTAK"/>

<xs:enumeration value="MINPWR"/>

<xs:enumeration value="ALTER"/>

<xs:enumeration value="CAUTIO"/>

<xs:enumeration value="NOLIM"/>

<xs:enumeration value="TURNIN"/>

<xs:enumeration value="NOSHORE"/>

<xs:enumeration value="CONBRE"/>

<xs:enumeration value="CONLEN"/>

<xs:enumeration value="LEADEP"/>

<xs:enumeration value="NOBERT"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="position_code_enum">

<xs:restriction base="xs:string">

<xs:maxLength value="2"/>

<xs:enumeration value="AL"/>

<xs:enumeration value="LE"/>

<xs:enumeration value="MI"/>

<xs:enumeration value="RI"/>

<xs:enumeration value="LB"/>

<xs:enumeration value="RB"/>

<xs:enumeration value="N"/>

<xs:enumeration value="NE"/>

<xs:enumeration value="E"/>

<xs:enumeration value="SE"/>

<xs:enumeration value="S"/>

<xs:enumeration value="SW"/>

<xs:enumeration value="W"/>

<xs:enumeration value="NW"/>

<xs:enumeration value="BI"/>

<xs:enumeration value="SM"/>

<xs:enumeration value="OL"/>

<xs:enumeration value="EW"/>

<xs:enumeration value="MP"/>

<xs:enumeration value="FP"/>

<xs:enumeration value="VA"/>

<xs:enumeration value="RY"/>

<xs:enumeration value="GY"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="reference_code_enum">

<xs:restriction base="xs:string">

<xs:maxLength value="4"/>

<xs:enumeration value="NAP"/>

<xs:enumeration value="KP"/>

<xs:enumeration value="FZP"/>

<xs:enumeration value="ADR"/>

<xs:enumeration value="TAW"/>

<xs:enumeration value="PUL"/>

<xs:enumeration value="NGM"/>

<xs:enumeration value="ETRS"/>

<xs:enumeration value="POT"/>

<xs:enumeration value="LDC"/>

<xs:enumeration value="HDC"/>

<xs:enumeration value="ZPG"/>

<xs:enumeration value="GLW"/>

<xs:enumeration value="HSW"/>

<xs:enumeration value="LNW"/>

<xs:enumeration value="HNW"/>

<xs:enumeration value="IGN"/>

<xs:enumeration value="WGS"/>

<xs:enumeration value="RN"/>

<xs:enumeration value="HBO"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="indication_code_enum">

<xs:restriction base="xs:string">

<xs:maxLength value="3"/>

<xs:enumeration value="MAX"/>

<xs:enumeration value="MIN"/>

<xs:enumeration value="RED"/>

</xs:restriction>

</xs:simpleType>

<xs:complexType name="target_group_type">

<xs:sequence>

<xs:element name="target_group_code" type="nts:target_group_code_enum" default="ALL">

<xs:annotation>

<xs:documentation>Target group (vessel type)</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="direction_code" type="nts:direction_code_enum" default="ALL">

<xs:annotation>

<xs:documentation>Upstream or downstream traffic, or both</xs:documentation>

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:simpleType name="target_group_code_enum">

<xs:restriction base="xs:string">

<xs:maxLength value="3"/>

<xs:enumeration value="ALL"/>

<xs:enumeration value="CDG"/>

<xs:enumeration value="COM"/>

<xs:enumeration value="PAX"/>

<xs:enumeration value="PLE"/>

<xs:enumeration value="CNV"/>

<xs:enumeration value="PUS"/>

<xs:enumeration value="NNU"/>

<xs:enumeration value="LOA"/>

<xs:enumeration value="SMA"/>

<xs:enumeration value="CND"/>

<xs:enumeration value="WOC"/>

<xs:enumeration value="MOV"/>

<xs:enumeration value="NMV"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="direction_code_enum">

<xs:restriction base="xs:string">

<xs:maxLength value="3"/>

<xs:enumeration value="ALL"/>

<xs:enumeration value="UPS"/>

<xs:enumeration value="DWN"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="unit_enum">

<xs:restriction base="xs:string">

<xs:maxLength value="4"/>

<xs:enumeration value="cm"/>

<xs:enumeration value="m3/s"/>

<xs:enumeration value="h"/>

<xs:enumeration value="km/h"/>

<xs:enumeration value="kW"/>

<xs:enumeration value="m/s"/>

<xs:enumeration value="mm/h"/>

<xs:enumeration value="°C"/>

</xs:restriction>

</xs:simpleType>

</xs:schema>

Appendix D

<?xml version="1.0" encoding="UTF-8"?>

<wsdl:definitions

xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"

xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"

xmlns:http=

"http://schemas.xmlsoap.org/wsdl/http/"

xmlns:xs=

"http://www.w3.org/2001/XMLSchema"

xmlns:soapenc=

"http://schemas.xmlsoap.org/soap/encoding/"

xmlns:mime=

"http://schemas.xmlsoap.org/wsdl/mime/"

xmlns:nts=

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

xmlns:tns=

"http://www.ris.eu/nts.ms/2.0.4.0"

targetNamespace=

"http://www.ris.eu/nts.ms/2.0.4.0"

name="NtS-Message-Service">

<!--

= specification of types =

-->

<wsdl:types>

<!--

= xml-schema for types =

-->

<xs:schema

targetNamespace="http://www.ris.eu/nts.ms/2.0.4.0"

xmlns:xs="http://www.w3.org/2001/XMLSchema"

xmlns:nts=

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

xmlns:nts-ms=

"http://www.ris.eu/nts.ms/2.0.4.0"

elementFormDefault="qualified"

attributeFormDefault="unqualified"

version="2.0.4.0">

<xs:import

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

schemaLocation="http://

www.ris.eu/nts/4.0/NtS_XSD_V.4.0.4.0.xsd"

/>

<xs:element name="get_messages_query">

<xs:complexType>

<xs:sequence>

<xs:element name="message_type" type="nts-ms:message_type_type"/>

<xs:element name="ids" type="nts-ms:id_pair" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="validity_period" type="nts:validity period type"

minOccurs="0"/>

<xs:element name="dates_issue" type="nts-ms:date_pair" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="paging_request" type="nts-ms:paging_request_type" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<!-- result to query — can contain

— "nts:RIS_MessageType", arbitrary number, defined in the NtS-xsd (see www.ris.eu)

— "nts-ms:error_code_type", arbitrary number, defined in this schema

— "nts-ms:paging_result_type", optional, defined in this schema -->

<xs:element name="get_messages_result">

<xs:complexType>

<xs:sequence>

<xs:element name="result_message" type="nts:RIS_Message_Type" minOccurs= "0" maxOccurs="unbounded"/>

<xs:element name="result_error" type="nts-ms:error_code_type" minOccurs= "0" maxOccurs="unbounded"/>

<xs:element name="paging_result" type="nts-ms:paging_result_type" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:simpleType name="message_type_type">

<xs:restriction base="xs:string">

<xs:enumeration value="FTM"/>

<xs:enumeration value="WRM"/>

<xs:enumeration value="ICEM"/>

<xs:enumeration value="WERM"/>

</xs:restriction>

</xs:simpleType>

<xs:complexType name="id_pair">

<xs:sequence>

<xs:element name="id" type="nts:isrs_code_type" minOccurs="1" maxOccurs="2" />

</xs:sequence>

</xs:complexType>

<xs:complexType name="date_pair">

<xs:sequence>

<xs:element name="date_start" type="xs:date"/>

<xs:element name="date_end" type="xs:date" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="paging_request_type">

<xs:sequence>

<xs:element name="offset" type="xs:nonNegativeInteger"/>

<xs:element name="limit" type="xs:nonNegativeInteger"/>

<xs:element name="total_count" type="xs:boolean"/>

</xs:sequence>

</xs:complexType>

<xs:simpleType name="error_code_type">

<xs:restriction base="xs:string">

<xs:enumeration value="e010">

<xs:annotation>

<xs:documentation>Description: message type not supported, Explanation: web service does not support the requested message type</xs:documentation>

</xs:annotation>

</xs:enumeration>

<xs:enumeration value="e030">

<xs:annotation>

<xs:documentation>Description: paging parameters inconsistent with messages, Explanation: parameters for paging mechanism do not fit the available messages, e.g. Offset >= Total Count</xs:documentation>

</xs:annotation>

</xs:enumeration>

<xs:enumeration value="e100">

<xs:annotation>

<xs:documentation>Description: syntax error in request, Explanation: request violates the schema for requests</xs:documentation>

</xs:annotation>

</xs:enumeration>

<xs:enumeration value="e110">

<xs:annotation>

<xs:documentation>Description: incorrect message type, Explanation: given message type is not known</xs:documentation>

</xs:annotation>

</xs:enumeration>

<xs:enumeration value="e120">

<xs:annotation>

<xs:documentation>Description: incorrect type-specific parameters, Explanation: type-specific parameters are erroneous</xs:documentation>

</xs:annotation>

</xs:enumeration>

<xs:enumeration value="e130">

<xs:annotation>

<xs:documentation>Description: incorrect paging parameters, Explanation: given parameters for the paging mechanism are erroneous</xs:documentation>

</xs:annotation>

</xs:enumeration>

<xs:enumeration value="e200">

<xs:annotation>

<xs:documentation>Description: operation not known, Explanation: the requested operation is unknown</xs:documentation>

</xs:annotation>

</xs:enumeration>

<xs:enumeration value="e300">

<xs:annotation>

<xs:documentation>Description: data source unavailable, Explanation: data source of the web service for the NtS data is temporarily unavailable</xs:documentation>

</xs:annotation>

</xs:enumeration>

<xs:enumeration value="e310">

<xs:annotation>

<xs:documentation>Description: too many results for request, Explanation: server is unable to handle number of results</xs:documentation>

</xs:annotation>

</xs:enumeration>

</xs:restriction>

</xs:simpleType>

<xs:complexType name="paging_result_type">

<xs:sequence>

<xs:element name="offset" type="xs:nonNegativeInteger"/>

<xs:element name="count" type="xs:nonNegativeInteger"/>

<xs:element name="total_count" type="xs:nonNegativeInteger" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

</xs:schema>

</wsdl:types>

<!--

= specification of messages =

-->

<wsdl:message name="get_messages_request">

<wsdl:part name="parameters" element="tns:get_messages_query"/>

</wsdl:message>

<wsdl:message name="get_messages_response">

<wsdl:part name="parameters" element="tns:get_messages_result"/>

</wsdl:message>

<!--

= specification of port type =

-->

<wsdl:portType name="NtS_message_service">

<wsdl:operation name="get_messages">

<wsdl:input message="tns:get_messages_request"/>

<wsdl:output message="tns:get_messages_response"/>

</wsdl:operation>

</wsdl:portType>

<!--

= specification of binding =

-->

<wsdl:binding name="NtS_message_service_soap_binding" type="tns:NtS_message_service">

<soap:binding style="document" transport=

"http://schemas.xmlsoap.org/soap/http"

/>

<wsdl:operation name="get_messages">

<soap:operation soapAction=

"http://www.ris.eu/nts.ms/get_messages"

/>

<wsdl:input>

<soap:body use="literal"/>

</wsdl:input>

<wsdl:output>

<soap:body use="literal"/>

</wsdl:output>

</wsdl:operation>

</wsdl:binding>

<!--

= specification of service =

-->

<wsdl:service name="NtS_message_service_service">

<wsdl:port name="NtS_message_service" binding="tns:NtS_message_service_soap_binding">

<soap: address location=

"http://nts-ms.example.org/NtS_message_service"

/>

</wsdl:port>

</wsdl:service>

</wsdl:definitions>

Treść aktu

Artykuł 1

Artykuł 2

Załącznik