02007R0416 — PL — 29.12.2018 — 001.001

Dokument ten służy wyłącznie do celów informacyjnych i nie ma mocy prawnej. Unijne instytucje nie ponoszą żadnej odpowiedzialności za jego treść. Autentyczne wersje odpowiednich aktów prawnych, włącznie z ich preambułami, zostały opublikowane w Dzienniku Urzędowym Unii Europejskiej i są dostępne na stronie EUR-Lex. Bezpośredni dostęp do tekstów urzędowych można uzyskać za pośrednictwem linków zawartych w dokumencie

zmienione przez:

▼B

ROZPORZĄDZENIE KOMISJI (WE) nr 416/2007

z dnia 22 marca 2007 r.

dotyczące specyfikacji technicznych komunikatów dla kierowników statków, o których mowa w art. 5 dyrektywy 2005/44/WE Parlamentu Europejskiego i Rady w sprawie zharmonizowanych usług informacji rzecznej (RIS) na śródlądowych drogach wodnych we Wspólnocie

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.

▼M1

ZAŁĄCZNIK

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:

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

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:

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

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:

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:

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:

4.1.3.    Komunikat dotyczący stanu wody

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

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.

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:

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

Skróty

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

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.

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.

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

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.

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.

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

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:

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

4.1.   Subject_code:

Definicja stosowania kodów tematu:

4.2.   Reason_code

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

Definicja stosowania kodów przyczyny:

4.3.   Limitation_code:

Definicja stosowania kodów ograniczeń:

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

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.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.9.   Target_group_code (zob. rozdział 3.5)

4.10.   Reporting_code

4.11.   Communication_code

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

4.12.   Type_code:

Droga wodna to kanał, jezioro albo rzeka.

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.

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.

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

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

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

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:

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:

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:

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:

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

4.2.    Aktualizacja istniejącego ICEM

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:

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

6.2.    Aktualizacja/odwołanie istniejącego FTM

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:

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:

6.5.    Postępowanie z okresami obowiązywania ograniczeń

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

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

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:

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”

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:

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:

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

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

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 składa się z dwóch części:

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:

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:

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:

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:

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:

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:

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:

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.

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

Appendix C

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

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