(EU) 2018/2032Prováděcí nařízení Komise (EU) 2018/2032 ze dne 20. listopadu 2018, kterým se mění nařízení (ES) č. 416/2007 o technických specifikacích pro zprávy vůdcům plavidel

A.   PŘÍRUČKA KÓDOVÁNÍ (ENCODING GUIDE) ZPRÁV VŮDCŮM PLAVIDEL PRO EDITORY

OBSAH

Zkratky:

1.   Základní informace, struktura a účel příruček NtS Encoding Guides

Norma pro zprávy vůdcům plavidel (NtS) je neustále zdokonalována. Zásadním krokem vpřed bylo vydání služby NtS Web Service, která usnadňuje výměnu zpráv NtS mezi orgány, jakož i mezi orgány a uživateli zpráv NtS.

Byly vypracovány dva dokumenty, které mají usnadňovat harmonizované kódování zpráv NtS na národní i mezinárodní úrovni: příručka NtS Encoding Guide pro editory a příručka NtS Encoding Guide pro vývojáře aplikací. Tyto příručky se vztahují na definici XSD pro zprávy NtS verze 4.0 a jazyk NtS Web Service WSDL verze 2.0.4.0.

Vzhledem k rostoucí míře využívání služby NtS Web Service budou zprávy NtS dále harmonizovány, aby se zajistilo řádné zobrazování obsahu na systémech třetích stran. Jednotné kódování zpráv je také předpokladem pro zohledňování zpráv v aplikacích pro plánování plavby.

Prvky, které obsahují pouze standardní nebo výchozí hodnoty, se vynechávají, pokud jsou podmíněné, protože vedou ke zvětšení velikosti zprávy bez jakékoli přidané hodnoty.

Příručka NtS Encoding Guide pro editory je určena osobám, které editují (a publikují) zprávy NtS, a obsahuje podrobné pokyny pro vytváření správných typů zpráv a také vysvětlení kódů. Příručka NtS Encoding Guide vysvětluje použitelnost čtyř typů zpráv NtS a poskytuje pokyny pro vyplňování a také kódy, které se mají používat pro určité události. Příručka NtS Encoding Guide pro editory je obsažena v tomto dodatku A.

Příručka NtS Encoding Guide pro vývojáře aplikací obsahuje pokyny pro vyvíjení a implementaci aplikací pro zprávy NtS a vysvětluje jejich logiku, postupy a automatické/výchozí hodnoty. Příručka NtS Encoding Guide pro vývojáře aplikací je obsažena v dodatku B přílohy tohoto nařízení.

2.   Výběr typu zprávy NtS

3.   Zpráva FTM – základní úvahy, kroky ke zveřejnění zprávy FTM

Podrobné informace, které kódy je nutno používat, jsou uvedeny v kapitole 4. Jednotlivé úvahy, počínaje bodem 3.3 nejsou nutně uvedeny v pořadí, v jakém se zadávají do nástroje pro editování zpráv FTM.

4.   Vysvětlení kódů zpráv FTM

4.1.   Subject_code:

Definice použití kódů předmětu zprávy:

4.2.   Reason_code:

Kód důvodu zprávy se vyplňuje za účelem poskytnutí doplňkových informací vůdcům plavidel.

Definice použití kódů důvodu zprávy:

4.3.   Limitation_code:

Definice použití kódů omezení:

4.4.   Limitation interval_code:Vymezení použití kódů intervalů omezení:

4.5.   Indication_code:

Kód Indication_code se má používat pro informace o konkrétních hodnotách určitých omezení (jako jsou např. omezení rychlosti, minimální výkon, využitelná hloubka). Aby bylo možno určit některé rozměry, je nutno vycházet z externího referenčního systému (geografického nebo hydrologického) (např. u podjezdné výšky, dostupné hloubky nebo minimální změřené hloubky), nebo ze známých rozměrů umělých konstrukcí (např. u povolené délky nebo průjezdné šířky).

4.6.   Position_code (u objektů):

Kód polohy (Position_code) musí pokud možno odkazovat na tu stranu plavební dráhy, kde se nachází objekt vzhledem k ose plavební dráhy (vlevo/střed/vpravo), nebo musí odkazovat na jinou obecně známou informaci (starý/nový) nebo zeměpisný směr (sever/jih/východ/západ). Kód Position_code u objektů může být automaticky předvyplněn z referenčních dat rejstříku RIS Index. Levá nebo pravá strana plavební dráhy se určuje při pohledu ve směru po proudu.

4.7.   Position_code (u plavebních drah / vodních cest):

Kód Position_code u zprávy FTM (nebo u části zprávy FTM), který souvisí s plavební dráhou nebo vodní cestou, se neuvádí. Pro vyjádření toho, na které straně plavební dráhy / kanálu / řeky / jezera se vyskytuje nějaký incident, se používá omezení „zvýšená opatrnost“ v kombinaci s příslušným kódem Position_code.

4.8.   Position_code (u omezení):

4.9.   Target_group_code (viz kapitola 3.5)

4.10.   Reporting_code:

4.11.   Communication_code:

používá se následující formát (příklady):

4.12.   Type_code:

Vodní cesta je buď kanál, jezero, nebo řeka.

5.   Zpráva WRM – základní úvahy

Zprávy týkající se vody (WRM) se zpravidla generují automaticky. Pokud to není možné, ruční generování zprávy WRM musí probíhat způsobem, který co nejblíže odpovídá postupům stanoveným pro automaticky generované zprávy WRM (viz příručka NtS Encoding Guide pro vývojáře).

6.   Zpráva ICEM – základní úvahy, kroky ke zveřejnění zprávy ICEM

Zprávy týkající se ledu (ICEM) závisí na místním pozorování a hodnocení a zpravidla je generují oprávnění pracovníci.

Zpráva ICEM se vydává v případě výskytu ledu. Led nutně nepředstavuje omezení plavby, nicméně mohou být poskytovány informace o ledových podmínkách, které nebrání plavbě.

7.   Zpráva WERM – základní úvahy

Vzhledem k velkému množství dostupných webových služeb (web services) a aplikací pro předpověď počasí a meteorologických varování by se zpráva týkající se počasí (WERM) měla používat pouze pro takové informace o počasí, které mají zvláštní význam pro plavbu a které nejsou poskytovány v rámci běžných služeb poskytujících informace o počasí.

Zprávy týkající se počasí se zpravidla generují automaticky. Pokud to není možné, ruční generování zprávy WERM musí probíhat způsobem, který co nejblíže odpovídá postupům stanoveným pro automaticky generované zprávy WERM (viz příručka NtS Encoding Guide pro vývojáře aplikací).

8.   Pravidla pro některé prvky

8.1.   Pravidla používání prvku „name“ (název) v souvislosti s objekty

Názvy objektů zpravidla předvyplňuje nástroj pro editování zpráv NtS na základě referenčních údajů z rejstříku RIS Index. Názvy se zadávají v místním jazyce, takže lze použít například i diakritiku nebo azbuku (např. Baarlerbrücke, Volkeraksluis nebo Mannswörth).

Do názvu nezahrnujte informace o charakteristice daného prvku, typ objektu se v názvu neopakuje, pokud neposkytuje doplňující informaci o typu objektu.

Příklad: Plavební stupeň „Schleuse Freudenau“ se uvede pouze pod názvem „Freudenau“, typ objektu „plavební stupeň“ je přidán automaticky na základě kódu typu (type_code).

Příklad: Název objektu železničního mostu v rakouské Kremži je „Eisenbahnbrücke Krems“. Informace „železniční most“ (německy „Eisenbahnbrücke“) je zahrnuta v názvu objektu, protože uvádí doplňkovou informaci, která rozšiřuje informaci „most“ poskytnutou kódem typu objektu (type_code).

Příklad: Název objektu mostu v rakouském Linci je „Nibelungenbrücke“. Slovo „brücke“ zůstává v názvu objektu, protože je součástí samotného názvu mostu.

Příklad: Vodočet „Pegelstelle Wildungsmauer“ se pojmenuje jen „Wildungsmauer“, protože informace o tom, že se jedná o vodočet, je již poskytnuta kódem typu objektu (type_code).

Pokud úsek vodní cesty tvoří hranici mezi dvěma zeměmi s různými jazyky, lze název objektu uvést v obou jazycích (např. „Staatsgrenze AT-SK / Štátna hranica AT-SK“).

8.2.   Pravidla používání prvku „name“ (název) v souvislosti s plavebními dráhami

Názvy plavebních drah zpravidla předvyplňuje nástroj pro editování zpráv NtS na základě referenčních údajů z rejstříku RIS Index. Pole „name“ musí obsahovat místní název příslušného úseku plavební dráhy (např. „Rhein“). V závislosti na vnitrostátních postupech může být možné upravit název plavební dráhy tak, aby zahrnoval i běžně používané místní názvy nebo doplňky (např. „Rhein am Deutschen Eck“).

8.3.   Pravidla používání prvků „value“ (hodnota) a „unit“ (jednotka) u omezení

Není-li uvedeno jinak, smí se ve zprávách NtS jako jednotky používat pouze cm, m3/s, h, km/h a kW, m/s (vítr), mm/h (déšť) a stupně Celsia.

B.   PŘÍRUČKA KÓDOVÁNÍ (ENCODING GUIDE) ZPRÁV VŮDCŮM PLAVIDEL PRO VÝVOJÁŘE APLIKACÍ

OBSAH

1.   Základní informace a struktura

Zprávy vůdcům plavidel (NtS) se v různých evropských zemích zaváděly na základě nařízení Komise (ES) č. 416/2007 o technických specifikacích pro zprávy vůdcům plavidel podle článku 5 směrnice Evropského parlamentu a Rady 2005/44/ES o harmonizovaných říčních informačních službách (RIS). Norma pro zprávy NtS je průběžně zdokonalována, přičemž zásadním krokem vpřed bylo vydání webové služby pro poskytování zpráv vůdcům plavidel (NtS Web Service), která usnadňuje výměnu zpráv NtS mezi orgány, jakož i mezi orgány a uživateli zpráv NtS, a také definice XSD pro zprávy NtS verze 4.0, která zjednodušuje kódování zpráv NtS.

1.1.   Účel příručky NtS Encoding Guide

Příručka NtS Encoding Guide vysvětluje použitelnost čtyř typů zpráv NtS a kódů, které se mají používat při určitých událostech. Poskytuje editorům zpráv NtS pokyny k vyplňování zpráv, a tím umožňuje harmonizované kódování zpráv NtS na národní i mezinárodní úrovni.

Vzhledem k rostoucí míře využívání služby NtS Web Service budou zprávy NtS dále harmonizovány, aby se zajistilo řádné zobrazování obsahu na systémech třetích stran. Jednotné kódování zpráv je také předpokladem pro zohledňování zpráv v aplikacích pro plánování plavby. Příručka NtS Encoding Guide ve verzi 1.0 se vztahuje na definici XSD pro zprávy NtS verze 4.0 a na NtS Web Service WSDL verze 2.0.4.0.

1.1.1.   Příručka NtS Encoding Guide pro editory

Příručka NtS Encoding Guide pro editory je určena pracovníkům, kteří editují (a publikují) zprávy NtS, a obsahuje podrobné pokyny pro vytváření správných typů zpráv a také vysvětlení kódů. Příručka kódování pro editory obsahuje důležité informace i pro vývojáře aplikací.

1.1.2.   Příručka NtS Encoding Guide pro vývojáře aplikací (tento dokument)

Příručka NtS Encoding Guide pro vývojáře obsahuje pokyny pro implementaci aplikací pro zprávy NtS a vysvětluje jejich logiku, postupy a automatické/výchozí hodnoty.

2.   Zprávy NtS a jejich oddíly

Zpráva NtS má tyto oddíly:

Obrázek 2:

Vizualizace struktury zprávy NtS: povinný prvek (1), povinný prvek, který se může objevit jedenkrát nebo dvakrát (1…2), povinný prvek, který se musí objevit dvakrát (2), povinné prvky, které se mohou objevit tolikrát, kolikrát je nutné (1-n), nepovinný prvek, který se může objevit tolikrát, kolikrát je nutné (0…n)

Identifikační oddíl je povinný, obsahuje všeobecné informace o původci zprávy, odesílateli, datu vydání, zemi a původním jazyce a je poskytován spolu s jedním ze čtyř různých typů oddílů zprávy NtS:

Kromě toho se k vymezení příslušných objektů nebo úseků plavebních drah, kterých se zpráva týká, používá kód ISRS Location Code (kód polohy podle Mezinárodní normy pro hlášení lodí).

Kód ISRS Location Code je definován v bodě 4.3 přílohy tohoto nařízení.

3.   Zpráva WRM – základní úvahy

Informace o vodním stavu jsou velmi důležité pro plánování cesty i pro bezpečnost. V současnosti neexistuje společný standard uvádění informací o vodním stavu. Hodnoty vodočtů se vztahují k odlišným výškám mořské hladiny nebo ke zvláštním referenčním bodům. Aby byl odkaz správný, je nutno spolu s hodnotou vždy uvést příslušný kód vztažného systému (reference_code). Zprávu týkající se vody (WRM) lze použít k poskytnutí těchto informací:

Vysvětlení překladů v tabulce kódů vztažného systému (reference_code) je uvedeno v kapitole 7.11.

Zprávy WRM se obvykle vytvářejí a zveřejňují automaticky na základě údajů získaných ze snímacího zařízení nebo na základě informací získaných z infrastruktury (např. předpovědi, stav vzdutí). Mohou existovat různé faktory, na jejichž základě dochází ke zveřejnění zprávy WRM, zprávy mohou být například zveřejňovány periodicky nebo při dosažení určité hodnoty.

3.1.   Vyplnění oddílu nts_number ve zprávě WRM

Podle definice XSD pro zprávy NtS verze 4.0 se číslo zprávy NtS nemusí ve zprávách WRM uvádět. Pokud se uvádí, musí být každé číslo jedinečné (Organisation/Year/Number/Serial) podle typu zprávy a je na organizaci, která zprávu WRM poskytuje, aby zajistila, že čísla zpráv budou jedinečná (nemusí jít o po sobě jdoucí čísla).

3.2.   Vyplnění zprávy WRM, včetně předpovědí

Jako datum začátku (date_start) doby platnosti (validity_period) je nutno vyplnit aktuální datum (date_issue = datum vydání) a jako datum konce (date_end) doby platnosti (validity_period) je nutno vyplnit datum dne následujícího po datu vydání (date_issue).

Pro uživatelsky přívětivější informování o změnách, například vodního stavu, lze rozdíl oproti předchozímu srovnávacímu údaji uvést ve zprávě WRM v oddílu „difference“ (rozdíl). Kromě změny hodnoty (např. –5 [cm]) se musí u srovnávacího údaje uvést také časový rozdíl.

V případě předpovědí se jako „measure_date“ (datum měření) uvede datum/čas, pro něž je dotyčná předpověď platná.

Předpovědi vodního stavu vždy obsahují faktor nejistoty. Obvykle se vypočítávají modely s různými parametry (např. předpověď počasí), které vedou k různým předpovězeným hodnotám vodního stavu. Aby bylo možno uvést minimální a maximální předpokládanou hodnotu, např. pro vizualizaci intervalu spolehlivosti předpovědi vodního stavu, obsahuje oddíl „measure“ (měření) ve zprávě WRM další dvě volitelná datová pole.

Interval spolehlivosti předpovědi vodního stavu je znázorněn na následujícím obrázku:

Obrázek 3

Vizualizace intervalu spolehlivosti předpovědi vodního stavu: nejpravděpodobnější hodnota (černá), horní mez intervalu spolehlivosti (fialová), dolní mez intervalu spolehlivosti (červená), naměřený vodní stav (modrá).

(Osa x udává čas; osa y udává vodní stav v cm.)

V definici XSD pro zprávy NtS jsou k dispozici dva prvky:

Vedle předpovědí vodního stavu lze interval spolehlivosti použít také k vyjádření míry nejistoty zveřejněných informací o minimální změřené hloubce a podjezdné výšce.

Minimální (value_min) a maximální (value_max) hodnota intervalu spolehlivosti umožňují poskytnout interval spolehlivosti hodnoty obsažené ve zprávě WRM prostřednictvím normalizované zprávy NtS týkající se vody (WRM), který lze používat v grafech. Samotné nezpracované údaje se uživatelům ve vnitrozemské vodní dopravě nebudou zobrazovat (např. ve formátu kódu).

Kód „NOM“ (žádné měření) se v poli measure_code (druh měření) nesmí používat. Pokud pro určitý typ zprávy WRM neexistuje měření, musí se hodnoty vynechat, je-li třeba, aby byla zpráva vyslána.

4.   Postupy související se zprávou ICEM

Zprávy týkající se ledu (ICEM) závisí na místním pozorování a hodnocení a obvykle se vytvářejí ručně (v případě automatického generování je nutno dodržovat pravidla pro manuální vytváření, viz příručka NtS Encoding Guide pro editory).

Zpráva ICEM se zveřejňuje pro určitý úsek plavební dráhy (fairway_section) vymezený kódy ISRS Location Code pro začátek a konec úseku a obsahuje informace o ledových podmínkách (ice_condition) k určitému datu měření.

Platnost zprávy ICEM začíná dnem zveřejnění (automaticky nastaveným aplikací pro zprávy NtS). Aby se uživatelům nezobrazovaly zprávy ICEM, které již nejsou platné, musí aplikace pro zprávy NtS do pole pro datum konce platnosti (date_end) automaticky vyplnit datum dne následujícího po dni zveřejnění (ledaže je vnitrostátními procesy zajištěno, že se do zprávy doplní datum konce doby platnosti, jakmile informace uvedené ve zprávě přestanou být aktuální).

V příručce NtS Encoding Guide pro editory je popsáno, za jakých okolností editor zpráv vůdcům plavidel vytváří novou zprávu ICEM nebo aktualizuje existující zprávu ICEM. Použijí se tyto postupy:

4.1.   Nová zpráva ICEM

4.2.   Aktualizace existující zprávy ICEM

5.   Zpráva WERM – základní úvahy

Zprávy týkající se počasí (WERM) se obvykle vytvářejí a zveřejňují automaticky na základě údajů získaných ze snímacího zařízení nebo na základě informací získaných z infrastruktury. Jako datum začátku (date_start) doby platnosti (validity_period) je nutno vyplnit aktuální datum (date_issue = datum vydání) a jako datum konce (date_end) doby platnosti (validity_period) je nutno vyplnit datum dne následujícího po datu vydání (date_issue).

Úsek plavební dráhy se ve zprávě WERM udává jako úsek mezi dvěma body plavební dráhy, tj. oblast, které se týkají údaje z meteorologické stanice (vodočtu).

Je nutno uvést datum a čas měření nebo předpovědi, ačkoli ve zprávách WERM to není povinné.

V případě předpovědí je datem měření („measure date“) datum/čas, pro které je předpověď platná.

5.1.   Vyplnění oddílu nts_number ve zprávě WERM

Podle definice XSD pro zprávy NtS verze 4.0 se ve zprávách WERM nemusí číslo zprávy NtS uvádět. Pokud se uvádí, musí být každé číslo jedinečné (Organisation/Year/Number/Serial) podle typu zprávy a je na organizaci, která zprávu WERM poskytuje, aby zajistila, že čísla zpráv budou jedinečná (nemusí jít o po sobě jdoucí čísla).

5.2.   Vyplnění kódu kategorie počasí („weather_category_code“) ve zprávě WERM

V poli „weather_category_code“ (kategorie počasí) se uvede rychlost větru (hodnoty 0 až 12) podle Beaufortovy stupnice, kterou zveřejnila Světová meteorologická organizace ve své příručce pro mořské meteorologické služby „WMO-No. 558“.

V poli „weather_category_code“ (kategorie počasí) se uvede viditelnost (hodnoty 13 až 22) podle následující tabulky:

6.   Postupy související se zprávami FTM

V příručce NtS Encoding Guide pro editory je popsáno, za jakých okolností editor zpráv NtS vytváří novou zprávu FTM nebo aktualizuje existující zprávu FTM. Použijí se tyto postupy:

6.1.   Nová zpráva FTM

6.2.   Aktualizace nebo zrušení existující zprávy FTM

6.3.   Zpráva FTM týkající se vodní cesty a/nebo objektu

Zpráva FTM týkající se vodní cesty obsahuje informace o jednom nebo několika úsecích vodní cesty. Úsek vodní cesty je vymezen v části „fairway_section“ (úsek vodní cesty) prostřednictvím kódů ISRS Location Code pro jeho počáteční a koncový bod.

Zpráva FTM týkající se objektu obsahuje informace o jednom nebo několika konkrétních objektech na vodní cestě. Objekt je vymezen v části „object“ pomocí kódu ISRS Location Code.

Jedna zpráva FTM se musí týkat

6.4.   Automatické řazení kódů omezení

Různá omezení mají různý vliv na plavbu. Aby se nejzávažnější omezení zobrazovala např. v seznamu zpráv FTM, platí níže uvedené pořadí zobrazení od nejpřísnějšího omezení s důležitostí 1:

6.5.   Způsob používání doby omezení

7.   Všeobecná pravidla používání

Je nutno brát v úvahu následující aspekty:

7.1.   Vyplnění čísla zprávy („number_section“)

Každé číslo (Organisation/Year/Number/Serial) musí být jedinečné pro daný typ zprávy. To znamená, že zprávy rozdílných typů mohou mít stejné číslo zprávy NtS.

Pro uživatele jsou čísla zpráv důležitá jen u zpráv FTM a ICEM, u všech ostatních typů zpráv lze zobrazení čísla zprávy přeskočit, pokud to povolují příslušné vnitrostátní předpisy.

Uživatelům se číslo zprávy zobrazuje v následujícím formátu: „Message Type/Country/Organisation/Year/Number/Serial“ (v závislosti na použitých filtrech lze číslo zkrátit, pokud nedojde ke ztrátě informací).

7.2.   Vyplnění prvků „from“, „originator“, „organisation“ a „source“

Do prvku „from“ (odesilatel) v identifikačním oddílu zprávy se vepíše název vnitrostátního systému, který zprávu poskytuje (např. ELWIS, DoRIS, SLOVRIS, FLARIS).

V prvku „originator“ (autor zprávy) se uvádí organizace, která zadává zprávy do vnitrostátních systémů.

Prvek „source“ (vydavatel zprávy) udává orgán, jehož jménem se zprávy FTM zveřejňují.

Prvek „organisation“ v oddílu s číslem zprávy (nts_number) udává název organizace, která toto číslo přiděluje (poskytovatel zprávy NtS).

7.3.   Vynechávání prvků

Prvky, které by obsahovaly pouze standardní nebo výchozí hodnoty, se vynechávají, pokud jsou podmíněné, protože vedou ke zvětšení velikosti zprávy bez jakékoli přidané hodnoty.

Týká se to následujících prvků:

7.4.   Automatické vyplnění data vydání zprávy (date_issue)

Zprávy FTM a ICEM

U zpráv FTM a ICEM se jako hodnota prvku date_issue použije skutečné datum a čas zveřejnění zprávy. U aktualizované zprávy se jako hodnota prvku date_issue použije datum a čas zveřejnění aktualizace.

Zprávy WRM a WERM

U zpráv WRM a WERM se jako hodnota prvku date_issue použije datum a čas zpracování požadavku, protože v rámci jedné zprávy WRM nebo WERM může existovat několik měření s rozdílnými časovými razítky vydání.

7.5.   Způsob používání informací o časových pásmech ve zprávách NtS

Ve zprávách NtS kódovaných v jazyce XML se datum a čas musí vždy uvádět jako místní čas včetně časového pásma.

Jedinými výjimkami z tohoto pravidla jsou položky „time_start“ a „time_end“ v oddílu „limitation_period“. Je tomu tak proto, že v oddílu věnovaném omezením lze použít interval. Pokud by datum začátku mělo rozdílný režim časového pásma než datum konce (např. CEST a CET), musela by být změněna informace o časovém pásmu v rámci tohoto intervalu. Tuto změnu nelze vyjádřit prostřednictvím jediné doby omezení. Místo vytvoření různých dob omezení pro každou změnu času se použije jen jedna doba omezení bez informace o časovém pásmu, aby se zkrátila doba potřebná k jejímu zpracování a přenosu.

7.6.   Způsob používání sekund ve zprávách NtS

Obecně platí, že v polích pro (datum)/čas se sekundy uvádět musí, ale uživatelům zpráv NtS se nezobrazují. Pro granularitu dat zpráv NtS postačují minuty.

7.7.   Formát desetinných čísel ve zprávách NtS

Desetinná místa v číselných polích se oddělují . (tečkou). Tisíce se neoddělují žádným znaménkem.

Počet desetinných míst v hodnotách je nutno omezit na rozumnou míru, aby se údaje zobrazovaly uživatelsky přívětivým způsobem.

7.8.   Jednotky, které se mají používat ve zprávách NtS

Ve zprávách NtS se jako jednotky smějí používat pouze cm, m3/s, h, km/h a kW, m/s (vítr), mm/h (déšť) a stupně Celsia, přičemž aplikace mohou jednotky převádět, aby se zobrazovaly uživatelsky přívětivým způsobem.

Pokud se zadávané jednotky liší od normalizovaných jednotek, musí aplikace dané hodnoty příslušným způsobem převést.

7.9.   Pravidla pro prvky „name“, „position_code“a „type_code“

Prvek „name“ (název) se předvyplní automaticky za použití referenčního údaje „national object name“ (název objektu v národním jazyce) z rejstříku RIS (pokud to vyžadují vnitrostátní předpisy, mohou editoři zpráv NtS předvyplněný název upravit). Zásady pojmenování objektů jsou uvedeny v příručce RIS Index Encoding Guide verze 2.0 nebo vyšší. Příklady správných názvů objektů jsou rovněž uvedeny v příručce NtS Encoding Guide pro editory.

Aplikace pro zprávy NtS před název objektu doplní kód typu objektu.

Poloha objektů se vyjadřuje kódem polohy, který aplikace pro zprávy NtS vyhledá v rejstříku RIS Index a doplní jej k objektu ve zprávě. Editoři mohou předvyplněné kódy typu a polohy upravovat. Kód polohy objektu se neuvádí u položek geo_object v oddílu fairway_section.

Úplný název objektu tvoří jeho kód polohy (position code), kód typu (type code) a název (name).

Aby se editorům zpráv NtS usnadnila práce, lze do nástrojů pro editování zpráv NtS implementovat následující mapovací tabulku, která editorům pomůže nalézt/vybrat správné objekty na základě kódu funkce (function_code) nebo typu zprávy NtS (type_code) z rejstříku RIS Index:

Tabulka 1

Párování „RIS Index function_code“ – „NtS type_code“

7.10.   Pravidla pro prvek „fairway_name“

Aby nebyla nutná logika aplikace / přítomnost správných referenčních údajů na straně přijímajícího systému (tzn. softwaru, který zprávu zobrazuje uživateli), v rámci geografického objektu („geo_object“) musí být vždy uveden prvek „fairway_name“ (vodní cesta) a aplikace pro zprávy NtS do něho musí automaticky vyplnit název vodní cesty („Waterway name“) z rejstříku RIS Index. Editoři zpráv NtS nesmějí obsah prvku fairway_name měnit.

7.11.   Vysvětlivky k překladům v tabulce „reference_code“

Pro hodnoty v tabulce Reference_code uvedené v referenčních tabulkách NtS Reference Tables platí následující definice:

7.12.   Doporučení pro prvek „coordinate“

Ačkoli je prvek „coordinate“ (souřadnice) v oddílu geo_object podmíněný, je nutno ve WGS84 uvádět zeměpisné souřadnice ve formátu [d]d mm.mmm[m] N (zeměpisná šířka) a [d][d]d mm.mmm[m] E (zeměpisná délka). Účelem je uvést zprávy NtS do zeměpisných souvislostí.

7.13.   Způsob používání cílových skupin

Oddíl věnovaný cílovým skupinám je tvořen kódem cílové skupiny a kódem směru plavby. Jestliže mají oba tyto kódy hodnotu ALL, celý oddíl se vynechá, pokud zpráva neobsahuje žádné jiné konkrétní cílové skupiny. Pokud je uvedena hodnota jen jednoho z těchto dvou kódů, musí se pro druhý z nich vyplnit výchozí hodnota, protože oba tyto prvky jsou povinné.

Další informace ohledně cílových skupin jsou uvedeny v příručce NtS Encoding Guide pro editory.

7.14.   Zobrazování platných zpráv v určitém okamžiku

Informace o době platnosti (validity_period) budou příslušné aplikace používat k výběru zpráv, které se mají uživatelům zobrazovat po požadovanou dobu.

Pokud je jako předmět (subject_code) uveden INSFER (Informační servis), doba platnosti (např. 1 měsíc) se používá k určení doby, po kterou se uživatelům zpráva informačního servisu zobrazuje, nikoli doby platnosti poskytnutých informací.

7.15.   Volitelné funkce ke zlepšení uživatelské přívětivosti nástrojů pro editování zpráv NtS

V závislosti na vnitrostátních požadavcích je možno editorům zpráv NtS nabídnout níže uvedené funkce.

8.   Struktura zprávy NtS v jazyce XML

Struktura zprávy NtS v jazyce XML a také obsah a účel jednotlivých datových prvků jsou vymezeny a dále vysvětleny v dodatku C: Definice schématu XML pro zprávy NtS (XSD)

9.   NtS Web Service

9.1.   Cíl

Odborná skupina pro zprávy NtS konstatovala, že technologie webové služby (web service) je vhodným prostředkem pro poskytování zpráv vůdcům plavidel.

Tato kapitola obsahuje specifikaci webové služby pro poskytování zpráv vůdcům plavidel (NtS Web Service). Zvláštní důraz byl kladen na používání zavedených mezinárodních norem.

Jedním z cílů návrhu celkového pojetí bylo zajistit vyváženost mezi flexibilitou a robustností výsledné webové služby. Filtrovací parametry poskytnuté v požadavcích jsou v zásadě totožné s kritérii vymezenými v normě pro zprávy NtS (úsek vodní cesty s nepovinným uvedením říčního kilometru, doba platnosti, datum zveřejnění zprávy). Zdá se, že vyjadřovací možnosti těchto parametrů jsou vzhledem k případům použití webové služby dostatečné, a zároveň zjednodušují implementaci.

Základním výsledkem je smlouva o webové službě, ve které jsou vymezeny jednotlivé požadavky a odpovědi. Uživatelé webové služby se mohou na tuto smlouvu spolehnout a poskytovatelé ji musejí dodržovat. Smlouva je vymezena za použití mezinárodní normy WSDL.

Každý zúčastněný členský stát zavede jednu nebo více webových služeb pro jednotlivé typy zpráv NtS (FTM, WRM, ICEM, WERM) a poskytuje je prostřednictvím internetu (dále jen „služba pro zprávy NtS“).

Technické podrobnosti implementace webové služby pro zprávy NtS, např. volba vhodných úložišť dat, aplikací a platforem, nespadají do působnosti této specifikace a zodpovídá za ně každý jednotlivý zúčastněný členský stát.

Aby bylo možné vymezit bezpečnou komunikaci, je nutno zvážit různá bezpečnostní hlediska a cíle ochrany. V závislosti na okolnostech nemusí být brána v úvahu všechna tato hlediska. Důležitost jednotlivých bezpečnostních hledisek a míra jejich splnění se mohou lišit. Rovněž proveditelnost určitého opatření může být omezena možnostmi technické implementace. V kontextu zpráv NtS jsou veškeré informace veřejné. Není tudíž nezbytné údaje zpráv NtS zabezpečovat z hlediska ochrany údajů. Každý poskytovatel se proto musí samostatně rozhodnout, do jaké míry toto hledisko ve své službě uplatní.

9.2.   Základní principy a omezení

9.2.1.   Webové normy

Služba NtS Web Service (NtS WS) musí být v souladu se základním profilem interoperability webových služeb (WS-I Basic Profile) verze 1.1. Tento profil „poskytuje pokyny ohledně interoperability pro základní soubor nechráněných specifikací pro web service, jako například SOAP, WSDL a UDDI“ (1). Nejdůležitějšími normami zde jsou:

Odpovědní zprávou NtS WS je zpráva NtS je definována podle definice schématu XML (XSD) v dodatku C tohoto nařízení Komise.

9.2.2.   Interakční model a metoda kódování pro NtS WS

Pro službu NtS Web Service se používá metoda kódování document/literal wrapped, protože umožňuje validaci porovnáním se schématem XML a názvy operací definované ve specifikaci WSDL se ve zprávách v protokolu SOAP používají přímo jako názvy značek XML.

9.3.   Obecné specifikace a doporučení

9.3.1.   Specifikace: informace o verzi

Informace o verzi služby NtS Web Service má dvě části:

Část týkající se verze samotné webové služby má dvě části:

Hlavní číslo verze webové služby se uvádí jako kladné celé číslo, které vyjadřuje hlavní číslo verze webové služby.

Dílčí číslo verze webové služby se uvádí jako nezáporné celé číslo, které vyjadřuje dílčí číslo verze webové služby v rámci hlavní verze.

Část týkající se verze schématu pro zprávy NtS obsahuje číslo verze schématu pro zprávy NtS definované odbornou skupinou pro zprávy NtS.

Zde uvedená verze služby NtS Web Service specifikovaná je tedy 2.0.4.0, kde 2.0 je verze samotné webové služby a 4.0 je verze použitého schématu pro zprávy NtS.

Explicitní informace o verzi nejsou v požadavcích nebo odpovědích služby NtS Web Service nutné. Předpokládá se, že online bude vždy současně jen několik málo verzí služeb. Různé verze budou mít různé adresy URL. Každá instance implementace služby NtS Web Service tudíž musí podporovat jednu konkrétní verzi služby NtS. Service.

9.3.2.   Specifikace: struktura jmenných prostorů

Jmenné prostory ve službě NtS Web Service jsou založeny na webové doméně odborných skupin RIS, http://www.ris.eu/.

Jmenné prostory obsahují částici, která indikuje příslušné informace o službě a verzi. Zde uvedená služba tudíž používá tento jmenný prostor:

Služba pro zprávy NtS: http://www.ris.eu/nts.ms/2.0.4.0

9.3.3.   Doporučení: používání jmenných prostorů

Pro větší transparentnost dokumentů XML se doporučuje definovat jmenné prostory v nejkrajnějším vhodném prvku ve schématech a dokumentech instance a nepoužívat místní definice jmenných prostorů ve vnořených prvcích.

9.3.4.   Doporučení: používání předpon jmenných prostorů

Požadavky a odpovědi ve službě NtS Web Service musí používat prvky XML v kvalifikované formě, tzn. s výslovně zadanou předponou jmenného prostoru, a atributy XML v nekvalifikované formě, tzn. bez předpony jmenného prostoru.

Za účelem lepší srozumitelnosti pro lidi se doporučuje používat intuitivní předpony jmenných prostorů, např. „nts“.

9.3.5.   Specifikace: používání kódů ISRS Location Code

Kód ISRS Location Code je vysvětlen v kapitole 2 příručky NtS Encoding Guide pro vývojáře aplikací a také v příručce RIS Index Encoding Guide.

Při zadávání dotazů do služby NtS Web Service může klient odkazovat na různé objekty, např. úseky plavební dráhy, vodočty nebo plavební stupně. Pokud se použijí odpovídající parametry, tzv. identifikační prvky (id elements), musí obsahovat kódy ISRS Location Code. Tyto parametry se obvykle uvádějí v identifikačních prvcích (id elements), přičemž každý obsahuje jedno nebo dvě ID.

Při používání těchto parametrů je nutno dodržovat následující obecné konvence:

Při specifikování úseků vodních cest (dvojic identifikačních prvků v rámci geografických informací o objektu v plavební dráze (fairway_section geo_object)) ve zprávách NtS je nutno v souvislosti s kódy ISRS Location Code vzít v úvahu následující:

Pokud se zpráva týká více než jednoho úseku vodní cesty nebo plavební dráhy, musí být všechny úseky plavební dráhy vymezeny svým počátečním a koncovým bodem v samostatných prvcích XML „fairway_section“.

Pro některé země nebo regiony se vyžaduje vytvoření filtrovací funkce. Například pokud kód ISRS Location Code (1-2) je BE, použijte kód ISRS Location Code (6-8) jako ID pro lineární odkazování s hektometrem plavební dráhy (ISRS Location Code 16-20). Příklady pro úseky plavební dráhy (platné dvojice ID prvků v fairway_section), které obsahují výše uvedené výjimky:

Následující obrázek ukazuje protikladné příklady použití kódu ISRS Location Code pro každou z obecných konvencí (na úseky slovenských vodních cest se žádné výjimky z obecných konvencí nevztahují):

Neplatné dotazy pomocí kódů ISRS Location Code

Obecná poznámka: Služba NtS Web Service neumožňuje dotazy na platné kódy ISRS Location Code. Kódy ISRS Location Code jsou uvedeny v Evropském systému pro správu referenčních údajů (ERDMS).

Následujících pět případů uvádí příklady správného použití kódů ISRS Location Code v dotazech a jejich interpretaci.

Případ č. 1: Požadavek neobsahuje žádný prvek ids

Prvek ids je nepovinnou součástí požadavku, takže lze zadat i dotaz bez jakýchkoli prvků ids:

Platný dotaz bez parametru ids

Pokud není zadán prvek ids, vrátí se – samozřejmě v závislosti na dalších filtrovacích kritériích, jako je doba platnosti (validity_period) nebo datum vydání zprávy (date_issue) – všechny zprávy.

Případ č. 2: Požadavek obsahuje jeden prvek id

Každý prvek ids může obsahovat jeden nebo dva prvky id. Následující obrázek ukazuje případ, kdy dotaz obsahuje jeden prvek id:

Platný dotaz s jedním parametrem id

V případě obdržení takového dotazu server vrátí všechny odpovídající zprávy, u kterých hektometr počátečního bodu ≤ zadané hodnotě (v příkladu je to konkrétně 240,7) a hektometr koncového bodu ≥ této hodnotě. Níže uvedený obrázek ukazuje následující výběr zpráv: Poloha, která je předmětem dotazu, leží mezi hektometrem počátečního bodu a hektometrem koncového bodu zpráv č. 1, 3 a 4, takže tyto zprávy by byly vráceny. Zprávy č. 2, 5 a 6 se týkají úseků nebo objektů, jejichž poloha se nepřekrývá s polohou, která je předmětem dotazu, takže tyto zprávy by nebyly vráceny.

Pokud daný kód ISRS Location Code označuje jediný objekt, např. vodočet nebo plavební stupeň, webová služba (web service) by měla vrátit zprávy, které se tohoto objektu týkají.

Odpovídající a neodpovídající zprávy pro jeden parametr id

Případ č. 3: Požadavek obsahuje dva prvky id

Každý prvek ids může obsahovat jeden nebo dva prvky id. Následující obrázek ukazuje případ, kdy dotaz obsahuje dva prvky id:

Platný dotaz se dvěma parametry id

Všechny hodnoty v hektometrech, které jsou předmětem dotazu, budou vyhodnoceny jako platné, ačkoli odpovídající úsek plavební dráhy má odlišné body začátku a konce. Pokud například nějaký úsek plavební dráhy začíná na hektometru 100,0 a končí na hektometru 300,0, byl by dotaz na hektometry 20,0 až 400,0 platný. Interně se samozřejmě vyhledává jen „skutečný“ rozsah úseku plavební dráhy.

To rovněž umožňuje vyhledat všechny zprávy o plavební dráze, aniž by bylo známo přesné rozmezí hektometrů (uživatel by odeslal svůj kód ISRS Location Code s hektometry nastavenými na „00000“ respektive „99999“).

Budou vráceny všechny odpovídající zprávy, které se týkají úseků nebo objektů, jejichž poloha protíná interval v hektometrech, který je předmětem dotazu. Tuto situaci znázorňuje následující graf:

Odpovídající a neodpovídající zprávy pro dva parametry id

Výše uvedený obrázek ukazuje, jak je definováno „protnutí“. Zatímco rozsahy u zpráv č. 1 až 4 se (částečně nebo zcela) překrývají s rozsahem v hektometrech, který je předmětem zadaného dotazu, v případě rozsahů u zpráv č. 5 a 6 tomu tak není, a proto budou vráceny zprávy č. 1 až 4, a zprávy č. 5 a 6 vráceny nebudou.

Technická podmínka pro to, aby se zpráva protnula s intervalem [A, B], je: počáteční bod úseku v hektometrech uvedený ve zprávě je ≤ B a koncový bod v hektometrech je ≥ A.

Kombinace: Požadavek obsahuje více prvků ids

Platný dotaz s více prvky ids

Kombinace několika prvků ids v dotazu vede ke sjednocení odpovídajících zpráv. Každý z prvků ids se zpracovává jednotlivě a zpráva bude vrácena v případě, že odpovídá alespoň jednomu z nich. V uvedeném příkladu by proto byly vráceny tyto zprávy:

9.4.   Služba pro zprávy NtS (implementační specifikace)

Tato kapitola obsahuje implementační specifikaci služby pro zprávy NtS, odvozenou od úvah a možností uvedených v předchozích kapitolách.

Služba pro zprávy NtS poskytuje čtyři typy zpráv NtS:

Implementace služby pro zprávy NtS může podporovat všechny typy zpráv, nebo jen některé z nich. Je povoleno, aby zúčastněný členský stát poskytoval pro konkrétní typ zprávy více služeb, které se navzájem doplňují.

9.4.1.   Požadavek

Aby se dosáhlo maximální robustnosti služby při co nejmenší složitosti, nepoužívá se pro službu NtS Web Service žádný další dotazovací jazyk. Místo toho se používají výrazy poskytované samotným jazykem WSDL. Konkrétní operace spolu s jejich parametry jsou plně vymezeny v rámci specifikace WSDL. V případě služby pro zprávy NtS je definována jedna operace.

Filtrovací kritéria specifická pro daný předmět jsou převzata z normy pro zprávy NtS, ale rozšířena, pokud jde o rozmanitost parametrů:

Služba vrací pouze zprávy, které odpovídají zadaným kritériím.

Mechanismus stránkování

Za účelem regulace objemu dat je podporován mechanismus stránkování. Stránkovací parametr je definován komplexním typem obsahujícím následující prvky:

Komplexní stránkovací parametr je volitelný, ale pokud je přítomen, musí být uvedeny všechny prvky v jeho rámci. Potom mechanismus stránkování funguje takto:

Celkový počet zpráv nepřekročí hodnotu parametru limit, s tou výjimkou, že hodnota 0 znamená „žádný limit“. Odpověď přeskočí tolik zpráv, kolik je definováno v parametru offset. Aby služba tento mechanismus mohla poskytovat, musí dodržovat dočasně stabilní (ale jinak libovolnou) posloupnost zpráv, např. mezi dvěma aktualizacemi dat zpráv vůči výchozímu datovému souboru webové služby (web service). To znamená, že dvě po sobě jdoucí totožná volání musí vrátit stejné zprávy ve stejném pořadí. Parametr total count určuje, zda odpověď poskytne celkový počet zpráv odpovídajících kritériím specifickým pro daný předmět. Obvykle by mělo stačit vyžádat si tuto informaci s první odpovědí, ale vynechat ji ve všech následných odpovědích. Výsledkem by byl lepší výkon webové služby.

Mechanismus stránkování představuje způsob, jak si zprávy vyžádat iterativně, po jednotlivých „stránkách“. Aby mechanismus stránkování správně fungoval, musí být v každém volání poskytnuty stejné parametry specifické pro daný předmět.

9.4.2.   Odpověď

V případě úspěšného požadavku obsahuje odpověď služby NtS Web Service zprávy NtS, které odpovídají parametrům požadavku. Zprávy NtS musí být v souladu se schématem pro zprávy NtS a lze je validovat porovnáním s tímto schématem. Jelikož je typ zprávy povinným parametrem požadavku, každá odpověď může obsahovat pouze zprávy NtS téhož typu, tedy FTM, WRM, ICEM nebo WERM.

Pokud služba zjistí chyby při zpracování požadavku, může vrátit libovolný počet chybových zpráv za použití chybových kódů uvedených v následující podkapitole.

Jedna odpověď služby NtS Web Service může obsahovat zároveň zprávy NtS i chybové zprávy.

Pokud požadavek obsahoval stránkovací parametry, vrátí se nepovinné informace o stránkování. V tomto případě jsou offset a počet obsažených zpráv povinné, celkový počet musí být přítomen pouze v případě, že byl požadován.

Upozornění: Předpokládá se, že komunikace mezi webovou službou (web service) a uživatelem je technicky zřízena, tzn. že služba přijme požadavek a uživatel obdrží odpovídající odpověď. Technické chyby, např. porucha připojení k internetu nebo nedostupnost webové služby v důsledku údržby nebo havárie, zde nejsou uvažovány. Uvažuje se zde pouze o chybových situacích, které se vyskytují „na pozadí“ vrstvy webové služby z pohledu uživatelů.

Chybové zprávy

Níže jsou uvedeny chybové kódy očekávaných chybových situací spolu s příslušným vysvětlením. V odpovědi je obsažen pouze chybový kód, což je obvyklý postup ve schématu XML pro zprávy NtS.

Chybové kódy služby pro zprávy NtS

9.5.   Generování služeb a klientů

Pokud je důsledně dodržován přístup „contract-first“, tj. kdy je jedna nebo více smluv s úplnými popisy rozhraní předložena ve formě dokumentů v jazyce WSDL, lze implementaci služby (služeb) i implementaci odpovídajícího klienta generovat automaticky za použití vhodných softwarových nástrojů. V ideálním případě není ve vygenerovaném zdrojovém kódu nutno provádět žádné manuální změny.

Avšak ve většině případů je zapotřebí několika iterací, dokud specifikace jazyka WSDL nebude splňovat přesné požadavky takového nástroje. Aby nástroj bezproblémově fungoval, je obvykle nutné individualizovat používání standardu WSDL. V důsledku toho mohou být nezbytné změny specifikace WSDL, přestože tato specifikace WSDL byla původně platnou specifikací podle normy WSDL. Pokud dojde ke změně specifikace WSDL webové služby (web service) po vygenerování služby nebo klienta, může být v závislosti na provedených změnách nutné je vygenerovat znovu.

Slovníček

(1)  Popis citován z webové stránky WS-I: http://www.ws-i.org

Dodatek C