A.   A HAJÓSOKNAK SZÓLÓ HIRDETMÉNYEKHEZ KAPCSOLÓDÓ, SZERKESZTŐKNEK SZÓLÓ ENCODING GUIDE

TARTALOMJEGYZÉK

Rövidítések

1.   Az NtS Encoding Guides háttere, struktúrája és célja

Az NtS szabványt folyamatosan fejlesztik. Fontos előrelépés volt az NtS Web Service elindítása, amely szolgáltatás megkönnyíti az NtS üzenetek hatóságok közötti, illetve a hatóságok és az NtS felhasználók közötti cseréjét.

Két dokumentumot dolgoztak ki az NtS üzenetek nemzeti és nemzetközi összehangolt kódolásának elősegítésére: a szerkesztőknek szóló NtS Encoding Guide-ot és az alkalmazásfejlesztőknek szóló NtS Encoding Guide-ot. Ezek az útmutatók az NtS XSD 4.0-ra és az NtS Web Service WSDL 2.0.4.0-ra vonatkoznak.

Tekintettel az NtS webszolgáltatás fokozott használatára, az NtS üzeneteket tovább kell harmonizálni, hogy garantálható legyen a tartalom megfelelő megjelenítése harmadik személyek rendszereiben. Az üzenetek egységes kódolása emellett annak is előfeltétele, hogy figyelembe lehessen venni őket az útitervkészítést szolgáló alkalmazásokban.

A csak szabványos vagy alapértelmezett értékeket tartalmazó elemeket mellőzni kell, ha azok feltételesek, mivel azok a hozzáadott értéket nem képviselő üzenetek elszaporodásához vezetnek.

A szerkesztőknek szóló NtS Encoding Guide címzettjei azok, akik NtS üzenetek állítanak össze (és tesznek közzé). Az útmutató lépésenkénti utasításokat ad a megfelelő üzenettípus összeállítására, továbbá megmagyarázza a kódokat. Az NtS Encoding Guide bemutatja a négy NtS üzenettípus alkalmazhatóságát, kitöltési utasításokat és bizonyos esetekben használandó kódokat ír le. A szerkesztőknek szóló NtS Encoding Guide ebben az A. függelékben szerepel.

Az alkalmazásfejlesztőknek szóló NtS Encoding Guide útmutatásokat fogalmaz meg az NtS alkalmazások fejlesztéséről és megvalósításáról, kifejti azok logikáját, folyamatait és az automatikus/alapértelmezett értékeket. Az alkalmazásfejlesztőknek szóló NtS Encoding Guide-ot e rendelet mellékletének B. függeléke tartalmazza.

2.   Az NtS üzenettípus megválasztása

3.   FTM alapvető megfontolások, az FTM közzétételéhez vezető lépések

A 4. fejezet adja meg a részletes információt arról, hogy melyik kódokat kell használni. A 3.3.-tól kezdődő megfontolások nem feltétlenül az FTM-szerkesztő eszköz beviteli sorrendjében olvashatók.

4.   FTM kódmagyarázat

4.1.   Subject_code:

A tárgykódok használatának meghatározása:

4.2.   Reason_code

Az indokkódot ki kell tölteni, hogy további információt szolgáltassanak a hajósoknak.

Az indokkódok használatának meghatározása:

4.3.   Limitation_code:

A korlátozáskódok használatának meghatározása:

4.4.   Limitation interval_code: Az intervallumkódok használatának meghatározása:

4.5.   Indication_code:

Az Indication_code konkrét értékekkel kapcsolatos tájékoztatásra használható bizonyos korlátozások (pl. sebességkorlátozás, minimális teljesítmény, rendelkezésre álló vízmélység) tekintetében. Bizonyos méretek meghatározásához hivatkozni kell egy külső (földrajzi vagy hidrológiai) vonatkoztatási rendszerre (pl. szabad űrszelvénymagasság, rendelkezésre álló vízmélység, minimális mélység) vagy mesterséges szerkezetek ismert méreteihez kell viszonyítani (pl. rendelkezésre álló hosszúság, rendelkezésre álló szélesség).

4.6.   Position_code (objektum):

Ahol lehetséges, a Position_code a hajóút azon oldalára hivatkozik, ahol az objektum található a hajóút tengelyéhez képest (bal, közép, jobb), vagy más közismert információra (régi/új), vagy földrajzi irányra (észak/dél/kelet/nyugat). Az objektumokra vonatkozó pozíciókód automatikusan kitölthető előre a RIS Index referenciaadatainak felhasználásával. A hajóút bal/jobb oldalát folyásirányba nézve kell megállapítani.

4.7.   Position_code (hajóutak/vízi utak):

A hajóútra vagy a vízi útra vonatkozó FTM-ben (vagy az FTM egy részében) nem tüntetnek fel Position_code-ot. Annak megjelölésére, hogy a hajóút/csatorna/folyó/tó melyik oldalán történt a váratlan esemény, a „kiemelt óvatosság” korlátozást kell használni a korlátozás megfelelő Position_code-jával.

4.8.   Position_code (korlátozások):

4.9.   Target_group_code (lásd a 3.5. fejezetet)

4.10.   Reporting_code

4.11.   Communication_code

a következő formátumot kell használni (példa):

4.12.   Type_code:

A vízi út lehet csatorna, tó vagy folyó.

5.   WRM alapvető megfontolások

A vízállásjelentéseket főszabály szerint automatikusan generálják. Ha erre nincs lehetőség, a WRM manuális kidolgozása során a WRM automatikus generálására megállapított eljárást kell követni a lehető legnagyobb mértékben (lásd a fejlesztőknek szóló NtS Encoding Guide-ot).

6.   ICEM alapvető megfontolások, az ICEM közzétételéhez vezető lépések

A jégjelentések helyi megfigyeléstől és értékeléstől függnek, és azokat általában felhatalmazott személyzet hozza létre.

ICEM-et jég esetén kell kiadni. A jég nem feltétlenül vezet hajózási korlátozáshoz, ugyanakkor a hajózást nem akadályozó jég állapotára vonatkozó információt meg lehet adni.

7.   WERM alapvető megfontolások

Tekintettel az időjárás-előrejelzések és riasztások tekintetében rendelkezésre álló webszolgáltatások és alkalmazások bőségére, a WERM csak akkor használandó, ha a hajózás szempontjából egyedi időjárási információt kell megosztani, amelyre az általános időjárási információs szolgáltatások nem terjednek ki.

Az időjárás-jelentéseket főszabály szerint automatikusan generálják. Ha erre nincs lehetőség, a WERM manuális kidolgozása során a WERM automatikus generálására irányadó eljárásokat kell követni a lehető legnagyobb mértékben (lásd a fejlesztőknek szóló NtS Encoding Guide-ot).

8.   Egyes elemekre vonatkozó szabályok

8.1.   Az objektumok kapcsán a „name” elemre vonatkozó szabályok

Az objektumok nevét az NtS-szerkesztő eszköz általában előre kitölti a RIS Index referenciaadatai alapján. A nevet a helyi nyelven kell megadni, így használhatók pl. hangsúlyjelek vagy cirill betűk (pl. Baarlerbrücke, Volkeraksluis vagy Mannswörth).

Ne adjon meg a tereptárgy jellegzetességével kapcsolatos információt, az objektum típusát ne ismételje meg a névben, hacsak nem ad meg további információt az objektum típusáról.

Például: a „Schleuse Freudenau” zsilip neve csak „Freudenau”, a „zsilipet” mint objektumtípust a rendszer automatikusan adja meg a type_code alapján.

Például: a kremsi vasúti híd (AT) objektumneve „Eisenbahnbrücke Krems”. a „vasúti híd” információ azért szerepel az objektum nevében, mivel a „híd” type_code-hoz további információt ad hozzá.

Például: egy linzi (AT) híd objektumneve „Nibelungenbrücke”. A „brücke” szó az objektumnévben szerepel, mivel a híd nevének részét képezi.

Például: a „Pegelstelle Wildungsmauer” vízmérce neve „Wildungsmauer”, mivel az azzal kapcsolatos információ, hogy az objektum vízmérce, már a type_code-ban szerepel.

Ha a vízi út adott szakasza két különböző nyelvű ország közötti határ is egyben, a nemzeti objektumnév mindkét nyelven megadható (pl. „Staatsgrenze AT-SK/Statna hranica AT-SK”).

8.2.   A hajóutak kapcsán a „name” elemre vonatkozó szabályok

A hajóutak nevét általában az NtS-szerkesztő eszköz előre kitölti a RIS Index referenciaadatai alapján. A „name” mező az adott hajóútszakasz helyi nevét tartalmazza (pl. „Rhein”). A nemzeti eljárások függvényében a hajóút neve szerkeszthető, hogy általánosan használt helyi neveket vagy toldásokat is magában foglaljon (pl. „Rhein am Deutschen Eck”).

8.3.   A korlátozásokon belül a „value” és „unit” elemekre vonatkozó szabályok

Eltérő rendelkezés hiányában az NtS üzenetekben kizárólag cm, m3/s, h, km/h és kW, m/s (szél), mm/h (eső) és Celsius-fok használható mértékegységként.

B.   A HAJÓSOKNAK SZÓLÓ HIRDETMÉNYEKHEZ KAPCSOLÓDÓ, ALKALMAZÁSFEJLESZTŐKNEK SZÓLÓ ENCODING GUIDE

TARTALOMJEGYZÉK

1.   Háttér és struktúra

A hajósoknak szóló hirdetményeket (NtS) a különböző európai országokban a közösségi belvízi közlekedésre vonatkozó harmonizált folyami információs szolgáltatásokról (RIS) szóló 2005/44/EK európai parlamenti és tanácsi irányelv 5. cikkében említett, hajósoknak szóló hirdetményekre vonatkozó műszaki előírásokról szóló 416/2007/EK bizottsági rendelet alapján hajtották végre. Az NtS szabvány megszakítás nélküli javítási folyamat tárgyát képezi, amelyben fontos előrelépés volt az NtS Web Service elindítása, amely szolgáltatás megkönnyíti az NtS üzenetek hatóságok közötti, illetve a hatóságok és az NtS felhasználók közötti cseréjét, továbbá megjelent az NtS XSD 4.0, amely észszerűsíti az NtS üzenetek kódolását.

1.1.   Az NtS Encoding Guide célja

Az NtS Encoding Guide bemutatja a négy NtS üzenettípus alkalmazhatóságát, és bizonyos esetekben használandó kódokat ír le. Kitöltési útmutatót biztosít az NtS szerkesztők számára az NtS üzenetek tekintetében, így lehetővé teszi az NtS üzenetek nemzeti és nemzetközi szinten harmonizált kódolását.

Tekintettel az NtS webszolgáltatás fokozott használatára, az NtS üzeneteket tovább kell harmonizálni, hogy garantálható legyen a tartalom megfelelő megjelenítése harmadik személyek rendszereiben. Az üzenetek egységes kódolása emellett annak is előfeltétele, hogy figyelembe lehessen venni őket az útitervkészítést szolgáló alkalmazásokban. Az NtS Encoding Guide 1.0 verziója az NtS XSD 4.0-ra és az NtS Web Service WSDL 2.0.4.0-ra vonatkozik.

1.1.1.   NtS Encoding Guide szerkesztők számára

A szerkesztőknek szóló NtS Encoding Guide címzettje az NtS üzeneteket szerkesztő (és közzétevő) személyzet. Az útmutató lépésenkénti utasításokat ad a megfelelő üzenettípus összeállítására, továbbá megmagyarázza a kódokat. A szerkesztőknek szóló kódolási útmutató alkalmazásfejlesztők számára releváns információt is tartalmaz.

1.1.2.   NtS Encoding Guide alkalmazásfejlesztők számára (e dokumentum)

A fejlesztőknek szóló NtS Encoding Guide útmutatásokat fogalmaz meg az NtS alkalmazások megvalósításáról, kifejti a logikát, a folyamatokat és az automatikus/alapértelmezett értékeket.

2.   NtS üzenetek és szakaszaik

Az NtS üzenetek a következőkből állnak:

Az üzenet azonosító adatait tartalmazó rész kötelező, és általános információt tartalmaz az üzenet kibocsátójáról, küldőjéről, a kiadás napjáról, az országról, az eredeti nyelvről, és azt az NtS üzenet négy különböző típusú szakaszának egyikével együtt adják meg:

Emellett az ISRS Location Code (nemzetközi hajózási adatszolgáltatási szabvány) használatos azon érintett objektum(ok) vagy hajóútszakasz(ok) meghatározásához, amely(ek)re az üzenet vonatkozik.

AZ ISRS Location Code-ot e rendelet mellékletének 4.3. pontja határozza meg.

3.   WRM alapvető megfontolások

A vízállásra vonatkozó információk mind az útitervkészítés, mind a biztonság szempontjából fontosak. Jelenleg nincsen általános szabvány a vízállással kapcsolatos információ vonatkoztatása tekintetében. A vízmércék értékei különböző tengerszintekre vagy speciális alappontokra vannak vonatkoztatva. A megfelelő vonatkoztatás érdekében az adott reference_code-okat mindig meg kell adni az értékkel együtt. A WRM az alábbi információk megadására használható:

A fordításokra vonatkozó pontosítások a táblázatkezelő „reference_code” részében a 7.11. fejezetben szerepelnek

Szokásosan a WRM létrejötte és közzététele automatikus, és annak alapját a szenzoros műszerek vagy infrastruktúra szolgáltatta adatok (előrejelzések, duzzasztási állapot) képezik. A WRM közzétételét több tényező kiválthatja, például időszakos közzététel vagy bizonyos érték elérése.

3.1.   Az NtS_number szakasz kitöltése a WRM-ben

Az NtS XSD 4.0-ban az NtS száma opcionális a WRM üzenetekben. Ha megadják a számot, annak üzenettípusonként egyedinek kell lennie (szervezet/év/szám/sorozatszám), és a WRM-et kiadó szervezet feladata az egyedi számok biztosítása (nem kötelező egymást követő számokat megadni).

3.2.   A WRM kitöltése, az előrejelzéseket is ideértve

A validity_period tekintetében a date_startnál az aktuális napot kell megadni (date_issue) a date_endnél pedig a date_issue-t követő napot.

Ahhoz, hogy felhasználóbarát legyen a változások közlése pl. a vízállás tekintetében, a korábbi összehasonlító méréstől való eltérést meg lehet adni a WRM eltérésre vonatkozó szakaszában. Az értékben bekövetkezett változás (pl. - 5 [cm]) mellett közölni kell az összehasonlító méréstől való időbeli eltérést is.

Előrejelzések esetén a „measure_date” az a nap/időpont, amelyre az előrejelzés érvényes.

A vízállásra vonatkozó előrejelzésekben mindig van bizonytalansági tényező. Általában különböző paraméterekkel rendelkező modelleket (pl. időjárás-előrejelzés) számítanak, amelyek a vízállás tekintetében eltérő előre jelzett értékeket mutatnak. Ahhoz, hogy meg lehessen adni minimális és maximális előre jelzett értékeket, pl. megjeleníteni a vízállás-előrejelzés konfidenciaintervallumát, két további opcionális adatmező szerepel a WRM „measure” szakaszában.

A vízállás-előrejelzés konfidenciaintervallumát a következő ábra mutatja be:

3. ábra

A vízállás-előrejelzés konfidenciaintervallumának megjelenítése: legvalószínűbb érték (fekete), a konfidenciaintervallum felső korlátja (ibolya), a konfidenciaintervallum alsó korlátja (vörös)

Az NtS XSD-ben két elem érhető el:

Az előre jelzett vízállás mellett a konfidenciaintervallum arra is használható, hogy kifejezzék a közzétett legkisebb vízmélységgel és az űrszelvénymagassággal kapcsolatos információ bizonytalanságát.

A konfidenciaintervallum value_min és value_max szakasza lehetővé teszi, hogy a WRM értékek konfidenciaintervallumát szabványosított NtS WRM üzenetben adják meg, és grafikonban felhasználják. Magukat a nyersadatokat nem jelenítik meg az IWT felhasználói számára (pl. kódformátumban).

A „NOM” measure_code nem használható. Ha egy adott típusú WRM tekintetében nem áll rendelkezésre mérés, az értékelemeket el kell hagyni, ha mindenképpen üzenetet kell küldeni.

4.   ICEM folyamatok

A jégjelentések helyi megfigyeléseken és értékelésen alapulnak, és általában manuálisan hozzák létre őket (automatikus generálás esetén a manuális létrehozás szabályait kell követni, lásd a szerkesztőknek szóló NtS Encoding Guide-ot).

Az ICEM-et egy meghatározott fairway_section tekintetében teszik közzé, amelyet az ISRS Location Code segítségével megadott kezdő- és végponttal határoznak meg, és egy adott mérési napra vonatkozó ice_conditiont tartalmazza.

Az ICEM érvényessége a közzététel napján kezdődik (amelyet az NtS alkalmazás automatikusan ad meg). Annak érdekében, hogy a felhasználók számára ne jelenjenek meg már nem érvényes ICEM-ek az érvényesség date_end értékét az NtS alkalmazásnak automatikusan ki kell töltenie a közzétételt követő napra (hacsak nemzeti folyamatok nem garantálják, hogy az üzenetekhez érvényességi zárónapot rendelnek, mihelyt az üzenetben foglalt információ már nem érvényes).

A szerkesztőknek szóló NtS Encoding Guide meghatározza, hogy az NtS szerkesztője milyen esetekben hoz létre új ICEM-et vagy teszi naprakésszé a meglévőt. A következő eljárást kell alkalmazni:

4.1.   Új ICEM

4.2.   Meglévő ICEM naprakésszé tétele

5.   WERM alapvető megfontolások

Szokásosan a WERM létrejötte és közzététele automatikus, és annak alapját a szenzoros műszerek vagy infrastruktúra szolgáltatta adatok képezik. A validity_period tekintetében a date_startnál az aktuális napot kell megadni (date_issue) a date_endnél pedig a date_issue-t követő napot.

A WERM-ben a hajóútszakasz a hajóút két pontja közötti szakasz, azaz az időjárás-állomás (mérce) alkalmazásának területe.

A mérés/előrejelzés napját és időpontját akkor is meg kell adni, ha az nem kötelező a WERM üzenetben.

Előrejelzések esetén a „measure_date” az a nap/időpont, amelyre az előrejelzés érvényes.

5.1.   Az NtS_number szakasz kitöltése a WERM-ben

Az NtS XSD 4.0-ban az NtS száma opcionális a WERM üzenetekben. Ha megadják a számot, annak üzenettípusonként egyedinek kell lennie (szervezet/év/szám/sorozatszám), és a WERM-et kiadó szervezet feladata az egyedi számok biztosítása (nem kötelező egymást követő számokat megadni).

5.2.   A WERM „weather_category_code” kitöltése

A „weather_category_code” keretében a szélsebességet (0–12 közötti érték) a Meteorológiai Világszervezet Manual on Marine Meteorological Services (Kézikönyv a tengerészeti meteorológiai szolgáltatásokról, „WMO-No. 558”) című dokumentumában közzétett Beaufort-skálával összhangban kell megadni.

A „weather_category_code” keretében a láthatóságot (13–22 közötti érték) a következő táblázat szerint kell meghatározni:

6.   FTM folyamatok

A szerkesztőknek szóló NtS Encoding Guide meghatározza, hogy az NtS szerkesztője milyen esetekben hoz létre új FTM-et vagy teszi naprakésszé a meglévőt. A következő eljárást kell alkalmazni:

6.1.   Új FTM

6.2.   Meglévő FTM naprakésszé tétele/visszavonása

6.3.   A vízi úttal és/vagy objektummal kapcsolatos FTM

A vízi úttal kapcsolatos FTM információt tartalmaz a vízi út egy vagy több szakaszáról. A vízi út szakaszát a „fairway_section” rész határozza meg a kezdő- és végpont ISRS Location Code-jával.

Az objektummal kapcsolatos FTM információt tartalmaz a vízi úton található egy vagy több objektumról. Az objektumot az „object” részben kell meghatározni annak ISRS Location Code-jával.

Egy FTM-nek a következőkre kell hivatkoznia:

6.4.   Korlátozási kódok automatikus rangsorolása

A különböző korlátozások más-más hatást gyakorolnak a hajózásra. Annak érdekében, hogy a legsúlyosabb korlátozást lehessen megjeleníteni pl. egy FTM áttekintő listán, a következő sorrendet kell figyelembe venni, a legsúlyosabbtól kezdve, amelyhez 1-es rangsorszámot rendelnek:

6.5.   A korlátozás időtartamának kezelése

7.   Általános végrehajtási szabályok

A következőket kell figyelembe venni:

7.1.   A „number_section” kitöltése

Minden számnak (Organisation/Year/Number/Serial) üzenettípusonként kell egyedinek lennie. Ez azt jelenti, hogy a különböző típusú üzeneteknek lehet ugyanaz az NtS számuk.

A felhasználók szempontjából az üzenetek száma csak az FTM és az ICEM esetében releváns, az összes többi üzenettípus tekintetében az üzenetszám megjelenítése a nemzeti követelmények függvényében elhagyható.

A felhasználók számára az üzenetszámot a következő formátumban kell megjeleníteni: „Message Type/Country/Organisation/Year/Number/Serial” (ez lerövidíthető az alkalmazott szűrőktől függően, ha nem vész el információ).

7.2.   A „from”, „originator”, „organisation” és „source” elemek kitöltése

Az üzenet azonosító adatait tartalmazó rész „from” elemét azon nemzeti rendszer nevével kell kitölteni, amely az üzenetet továbbítja (pl. ELWIS, DoRIS, SLOVRIS, FLARIS).

Az „originator” elem az a szervezet, amely az üzeneteket beviszi a nemzeti rendszerbe.

A „source” elem az a hatóság, amely tekintetében az FTM-et közzéteszik.

Az nts_number szakaszon belül az „organisation” elem annak a szervezetnek a neve, amely az nts_numbert kiosztja (NtS szolgáltató).

7.3.   Elemek elhagyása

A csak szabványos vagy alapértelmezett értékeket tartalmazó elemeket mellőzni kell, ha azok feltételesek; azok a hozzáadott értéket nem képviselő üzenetek elszaporodásához vezetnek.

Ez a következő elemeket érinti:

7.4.   A date_issue automatikus kitöltése

FTM és ICEM

Az FTM és az ICEM tekintetében a date_issue elem értéke a közzététel tényleges napja és időpontja. Naprakésszé tett üzenetek esetén a date_issue az a nap és időpont, amikor a frissítést közzétették.

WRM és WERM

A WRM és a WERM tekintetében a date_issue elem értéke a kérés feldolgozásának napja és időpontja, mivel több mérés fordulhat elő különböző kibocsátási időbélyegzőkkel egyetlen W(E)RM üzeneten belül.

7.5.   Az időzónákkal kapcsolatos információ kezelése az NtS üzenetekben

A napot és az időpontot mindig a helyi idő szerint kell megadni, az időzónával kapcsolatos információt pedig fel kell tüntetni az NtS XML üzenetben.

E rendelkezés alól az egyedüli kivétel a „time_start” és a „time_end” a „limitation_period” szakaszban. Ez azért van így, mivel a korlátozási szakaszban intervallumot lehet alkalmazni. Ha a kezdő- és a zárónap különböző időszámítási rendszerekbe (pl. CEST és CET) tartozik, ezzel megváltozik az időzónára vonatkozó információ ebben az intervallumban. Ezt a változást egyetlen korlátozási időtartammal nem lehet kifejezni. Ahelyett, hogy különböző korlátozási időtartamokat hoznának létre minden időbeli változáskor, csak egyetlen korlátozási időtartamot kell használni az időzónára vonatkozó információ nélkül, hogy csökkenteni lehessen az üzenetek felesleges feldolgozását és továbbítását.

7.6.   A másodpercek kezelése az NtS üzenetekben

Főszabályként a másodperceket a (nap)/időpont mezőkben kell megadni, de azokat az NtS felhasználói számára nem kell megjeleníteni. Az NtS részletezettségéhez elegendőek a percek.

7.7.   A tizedesjegyek formátuma az NtS üzenetekben

A numerikus mezőkben a tizedestörtekben pontot kell használni: (időszak). Ezreshatároló nem alkalmazandó.

A felhasználóbarát megjelenítés érdekében az értékekhez használt tizedesjegyek számát kezelhető mennyiségűre kell szorítani.

7.8.   Az NtS üzenetekben alkalmazandó mértékegységek

Az NtS üzenetekben kizárólag cm, m3/s, h, km/h és kW, m/s (szél), mm/h (eső) és Celsius-fok használható mértékegységként, az alkalmazások a mértékegységeket átválthatják a felhasználóbarát megjelenítés érdekében.

Ha a bevitt mértékegységek eltérnek a szabványosított mértékegységektől, a bevitt értékeket az alkalmazásnak ennek megfelelően át kell váltania.

7.9.   A „name”, „position_code” és „type_code” elemekre vonatkozó szabályok

A „name” elemet automatikusan kell kitölteni előre a RIS Index „national object name” referenciaadataival (az NtS szerkesztői módosíthatják az előre kitöltött nevet, ha ez nemzeti előírás). Az objektumok elnevezésére vonatkozó szokásokat a RIS Index Encoding Guide 2.0 vagy magasabb verziója tartalmazza. A megfelelő objektumnevekre a szerkesztőknek szóló NtS Encoding Guide is szolgáltat példákat.

Az objektumhoz az NtS alkalmazás rendel típuskódot az objektumnév előtt.

Az objektumok pozícióját pozíciókóddal kell kódolni, és azt az NtS alkalmazás rendeli az objektumhoz a RIS Indexből. A szerkesztők megváltoztathatják az előre kitöltött típus- és pozíciókódokat. Az objektum pozíciókódját nem szabad megadni a geo_objects tekintetében a fairway_sectionben.

A teljes objektumnév pozíciókódból, típuskódból és névből áll.

Az NtS szerkesztők munkájának megkönnyítése érdekében a következő hozzárendelést lehet elvégezni az NtS-szerkesztő eszközökben, amelynek segítségével a szerkesztők megtalálhatják/kiválaszthatják a megfelelő objektumot a RIS Index function_code vagy az NtS type_code alapján:

7.10.   A „fairway_name” elemre vonatkozó szabályok

Annak érdekében, hogy elkerülhető legyen az alkalmazáslogika / ne legyen szükség megfelelő referenciaadatokra a fogadó rendszerben (a hirdetményt a felhasználó számára megjelenítő szoftver), a „fairway_name” opcionális elemet mindig bele kell foglalni a „geo_object”-be, és azt az NtS alkalmazásnak mindig ki kell töltenie a „Waterway name”-mel a RIS Indexből. Az NtS szerkesztői nem változtathatják meg a fairway_name elemet.

7.11.   A fordításokra vonatkozó pontosítások a táblázatkezelő „reference_code” részében

Az NtS Reference Tables-ben megadott reference_code értékekre a következő meghatározásokat kell alkalmazni:

7.12.   Ajánlás a „coordinate” elem tekintetében

Jóllehet a „geo object” szakaszban a koordinátaelem feltételes, a földrajzi koordinátákat a WGS84 formátumban kell megadni, a következőképpen: [d]d mm.mmm[m] N (latitude) és [d][d]d mm.mmm[m] E (longitude). Ez szolgál az NtS üzenetek földrajzi vonatkoztatására.

7.13.   A célcsoportok kezelése

A célcsoport szakasza célcsoportkódból és iránykódból áll. Ha mindkettő értéke ALL, a teljes szakaszt el kell hagyni, ha az üzenetben nincs más konkrét célcsoport. Ha e kettő közül csak az egyiket adják meg, a másikat az ALL alapértelmezett értékkel kell kitölteni, mivel mindként elem kötelező.

A célcsoportokat érintően további információ a szerkesztőknek szóló NtS Encoding Guide-ban olvasható.

7.14.   Érvényes üzenetek megjelenítése adott időpontban

A validity_periodot az alkalmazások azon üzenetek kiválasztására fogják használni, amelyeket a kívánt ideig megjelenítenek a felhasználók számára.

Ha a subject_code INFSER (tájékoztatás), az érvényességi időszakot azon időszak meghatározására használják, ameddig a tájékoztatást megjelenítik a felhasználók számára, nem a szolgáltatott információ érvényességi idejére (pl. 1 hónap).

7.15.   Az NtS-szerkesztő eszköz felhasználóbarátabbá tételét szolgáló választható funkciók

Az NtS szerkesztői számára a következő funkciók kínálhatók fel a nemzeti követelmények függvényében:

8.   Az NtS XML üzenet struktúrája

Az NtS XML üzenet struktúráját, továbbá az adatelemek tartalmát és célját a C. függelék: NtS XML séma (XSD) határozza meg és fejti ki bővebben.

9.   NtS Web Service

9.1.   Célkitűzés

Az NtS szakértői csoport a webszolgáltatás-technológiát megfelelő eszközként azonosította a hajósoknak szóló hirdetmények közzétételéhez.

Ez a fejezet meghatározza a hajósoknak szóló hirdetmények továbbítására szolgáló webszolgáltatás, röviden az NtS Web Service előírásait. Különös hangsúly került a bevált nemzetközi szabványok használatára.

Az elvi tervezés egyik célja az volt, hogy megfelelő egyensúlyt teremtsenek a rugalmasság és a létrejövő webszolgáltatás megbízhatósága között. A kérésekben megadott szűrőparaméterek lényegében az NtS szabványban meghatározott kritériumok (a vízi út szakasza opcionálisan folyamkilométerrel, az érvényesség időpontja, a hirdetmény közzétételének napja). Ez kellően kifejezőnek tűnik, tekintve a webszolgáltatás felhasználói eseteit, ugyanakkor mérsékli a megvalósítás összetettségét.

Az elsődleges eredmény a webszolgáltatásra irányuló szerződés, amelyben a kérések és a válaszok meghatározottak. A webszolgáltatások fogyasztói támaszkodhatnak e szerződésre, a szolgáltatóknak pedig be kell tartaniuk azt. A szerződést a nemzetközi WSDL szabvány alkalmazásával határozzák meg.

Minden részt vevő tagállam egy vagy több webszolgáltatást valósít meg az NtS különböző üzenettípusai tekintetében (FTM, WRM, ICEM, WERM), és azokat az Interneten keresztül biztosítják („NtS üzenetszolgáltatás”).

Az NtS WS megvalósításának műszaki részleteire, pl. a megfelelő adathalmazok, alkalmazások és platformok megválasztására nem terjednek ki ezek az előírások, az az egyes részt vevő tagállamok feladata.

A biztonságos kommunikáció meghatározása érdekében különféle biztonsági szempontokat és védelmi célkitűzéseket kell figyelembe venni. A körülmények függvényében nem feltétlenül kell tekintettel lenni valamennyi szempontra. A különböző biztonsági szempontok prioritása és érvényesítésük mértéke változó lehet. Egy adott intézkedés megvalósíthatóságát korlátozhatja a műszaki megvalósítás kapacitása is. Az NtS keretében minden információ nyilvános. Ezért nincs szükség maguknak az NtS adatoknak adatvédelmi vonatkozású biztosítására. Így minden szolgáltatónak saját magának kell eldöntenie, hogy ezt a szempontot hogyan építi be szolgáltatásába.

9.2.   Alapelvek és megszorítások

9.2.1.   Webszabványok

Az NtS Web Service-nek meg kell felelnie a WS-I alapprofil 1.1-nek. Ez a profil „interoperabilitási útmutatót kínál szabad felhasználású webszolgáltatásokra vonatkozó előírások, pl. SOAP, WSDL és UDDI alapkészletei számára” (1). A legrelevánsabb szabványok a következők:

Az NtS WS válaszüzenete XML sémában (XSD) meghatározott NtS üzenet, amelyet e bizottsági rendelet C. függeléke ír le.

9.2.2.   Interaktivitási modell és az NtS WS kódolási módszere

Az NtS Web Service-hez a document/literal wrapped kódolási módszert kell alkalmazni, mivel lehetővé teszi az XML sémának megfelelő validálást, és a WSDL előírásban meghatározott műveletneveket közvetlenül XML címkenevekként használják a SOAP üzenetekben.

9.3.   Általános előírások és ajánlások

9.3.1.   Előírás: Verzióadatok

Az NtS Web Service-re vonatkozó verzióadatok két szakaszból állnak:

Magának a webszolgáltatásnak a verziója két részt foglal magában:

A főverzió pozitív egész szám, amely a webszolgáltatás főverzióját jelöli.

Az alverzió nemnegatív egész szám, amely a webszolgáltatás főverzión belüli alverzióját jelöli.

Az NtS séma szakasza az NtS séma NtS szakértőcsoport által meghatározott verzióját tartalmazza.

Így az NtS Web Service itt meghatározott verziója 2.0.4.0, ahol a 2.0 magának a webszolgáltatásnak a verziója, a 4.0 pedig az alkalmazott NtS séma verziója.

Az NtS Web Service kéréseiben vagy válaszaiban nem szükséges kifejezett verzióinformációt megadni. A szolgáltatásoknak várhatóan csak néhány verziója áll rendelkezésre egyidejűleg online. A különböző verziókat különböző URL-ekkel látják el. Ezért az NtS Web Service implementációjának minden előfordulása az NtS Web Service egy konkrét verzióját támogatja.

9.3.2.   Előírás: A névtartományok struktúrája

Az NtS Web Service-ben a névtartományok a RIS szakértői csoport webdoménjén alapulnak, http://www.ris.eu/.

A névtartományok a megfelelő szolgáltatásra és a verzióadatokra utaló elemet tartalmaznak. Így az itt meghatározott szolgáltatás a következő névtartományt használja:

NtS üzenetszolgáltatás: http://www.ris.eu/nts.ms/2.0.4.0

9.3.3.   Ajánlás: A névtartományok használata

Az XML dokumentumok nagyobb átláthatósága érdekében ajánlott a névtartományokat a sémák vagy példánydokumentumok legkülső elemeiben meghatározni, és nem használni helyi névtartomány-meghatározásokat a beágyazott elemekben.

9.3.4.   Ajánlás: Névtartomány-előtagok használata

Az NtS Web Service-ben a kérések és válaszok az XML elemeket minősített formában használják, azaz kifejezett névtartomány-előtaggal, az XML attribútumokat pedig nem minősített formában, azaz névtartomány-előtag nélkül.

Ajánlott intuitív névtartomány-előtagokat használni, mint az nts, a jobb emberi olvashatóság érdekében.

9.3.5.   Előírás: ISRS Location Code használata

Az ISRS Location Code-okat az alkalmazásfejlesztőknek szóló NtS Encoding Guide 2. fejezete, valamint a RIS Index Encoding Guide fejti ki.

Az NtS Web Service lekérdezésekor az ügyfél különféle objektumokra hivatkozhat, pl. hajóútszakaszokra, mércékre vagy zsilipekre. Ha a megfelelő paramétereket, „id element”-eket használnak, ezeknek ISRS Location Code-ot kell tartalmazniuk. E paramétereket szokásosan id elementben adják meg, amelyek mindegyike egy vagy két azonosítót tartalmaz.

E paraméterek alkalmazásakor a következő általános szokásokat kell követni:

A víziút-szakaszok NtS üzenetekben történő megadásához (azonosítóelem-párok a fairway_section geo_objectben), a következőt kell szem előtt tartani az ISRS Location Code-ok tekintetében:

Ha az üzenet egynél több víziút- vagy hajóútszakaszt érint, minden hajóútszakaszt a kezdő és végpontja határoz meg különálló „fairway_section” XML elemben.

Egyes országok/régiók tekintetében szűrő funkciót kell kialakítani. Ha például az ISRS Location Code 1–2. jegye BE, az ISRS Location Code 6–8. jegyét a hajóút hektométeréhez (ISRS Location Code, 16–20. jegy) való lineáris vonatkoztatás azonosítójaként kell használni. Példa olyan hajóútszakaszokra (érvényes azonosítóelem-párok a fairway_sectionben), amelyek a fent meghatározott kivételeket tartalmazzák:

Az alábbi ábra az ISRS Location Code használatára mutat ellenpéldákat az általános szokások mindegyike tekintetében (az SK víziút-szakaszok tekintetében nincsenek az általános szokások alóli kivételek):

Érvénytelen ISRS Location Code lekérdezések

Általános megjegyzés: Az érvényes ISRS Location Code-ra történő lekérdezési szolgáltatást az NtS Web Service nem támogatja. Az ISRS Location Code-okat az európai referenciaadat-kezelő rendszer (ERDMS) biztosítja.

Az ISRS Location Code-ok helyes használata a lekérdezésekben és értelmezésük az alábbi öt esetben szerepel.

1. eset: A kérésben nem szerepel azonosítóelem

Az azonosítóelemek a kérés opcionális részei, azaz lehetőség van azonosítóelem nélküli lekérdezésre.

Érvényes lekérdezés azonosítóparaméter nélkül

Ha nincs megadva azonosítóelem, minden üzenetet átküldenek (természetesen más szűrési kritériumok függvényében, mint a validity_period vagy a dates_issue).

2. eset: A kérésben egy azonosítóelem szerepel

Minden azonosítóelem egy vagy több azonosítóelemet tartalmazhat. Az egy azonosítóelemre az alábbi ábra szolgáltat példát:

Érvényes lekérdezés egy azonosítóparaméterrel

Ha ilyen lekérdezés érkezik, a szerver minden ehhez tartozó üzenetet átküld, amelyben a kezdő hektométer ≤ az adott értékhez képest (240,7 a példában) és a záró hektométer ≥ mint ez az érték. Az alábbi ábra jeleníti meg az üzenetek e választékát: A lekérdezett pozíció az 1., 3. és 4. üzenet esetében a kezdő és a záró hektométerérték között van, ezeket átküldik. A 2., 5. és 6. üzenetek nincsenek átfedésben a lekérdezett pozícióval, így azokat nem küldik át.

Ha az adott ISRS Location Code egyetlen objektumot, pl. mércét vagy zsilipet jelöl, a webszolgáltatásnak át kell küldenie az ezen objektumot érintő üzeneteket.

Megfelelő és meg nem felelő üzenetek egy azonosítóparaméter esetén

3. eset: A kérésben két azonosítóelem szerepel

Minden azonosítóelem egy vagy több azonosítóelemet tartalmazhat. A két azonosítóelemre az alábbi ábra szolgáltat példát:

Érvényes lekérdezés két azonosítóparaméterrel

Valamennyi hektométerértéket érvényesként kell kezelni, akkor is, ha a megfelelő hajóútszakasznak más a kezdő- vagy a végpontja. Ha például a hajóútszakasz a 100,0 hektométernél kezdődik és a 300,0 hektométernél ér véget, a 20,0 és a 400,0 közötti hektométereket lekérdező kérések érvényesek. A rendszeren belül természetesen csak a hajóútszakasz „valódi” terjedelmére keresnek.

Ezzel keresni lehet egy adott hajóútra vonatkozó minden üzenet akkor is, ha a pontos hektométer-tartomány nem ismert (ekkor az ISRS Location Code-ot „00000”, illetve „99999” hektométerre beállítva kell megadni).

Valamennyi, az adott hektométer-intervallumot keresztező, megfelelő üzenetet át kell küldeni. A következő ábra mutatja be ezt a helyzetet:

Megfelelő és meg nem felelő üzenetek két azonosítóparaméter esetén

A fenti ábra mutatja, hogy a „keresztező” üzenetet miként határozzák meg. Noha az 1–4. üzenetek tartománya átfedésben van a lekérdezett hektométer-tartománnyal (részben vagy teljesen), az 5. és 6. üzeneté nincs, így az 1–4. üzenetet át kell küldeni, az 5. és 6. üzenetet pedig nem.

Annak gyakorlati feltételei, hogy az üzenet keresztezze [A, B] intervallumot: az üzenet kezdő hektométere ≤ B és záró hektométere ≥ A.

Kombináció: A kérésben több azonosítóelem szerepel

Érvényes lekérdezés több azonosítóelem mellett

Ha a kérésben több azonosítóelem szerepel, az a megfelelő üzenetek egyesítését eredményezi. Minden azonosítóelemet egyenként kezelnek és az üzenetet átküldik, ha az legalább ezek egyikének megfelel. Így az adott példa tekintetében a következő üzeneteket küldik át:

9.4.   NtS üzenetszolgáltatás (megvalósítási előírás)

Ez a fejezet ismerteti az NtS üzenetszolgáltatás megvalósítási előírásait, amelyek az előző fejezetek megfontolásaiból és választásaiból következnek.

Az NtS üzenetszolgáltatás a következő négy üzenettípust kínálja az NtS-ben:

Az NtS üzenetszolgáltatás megvalósítása támogathatja valamennyi üzenettípust, vagy csak azok adott választékát. Lehetőség van arra, hogy a részt vevő tagállam egynél több szolgáltatást kínáljon egy adott üzenettípus vonatkozásában, amely szolgáltatások kiegészítik egymást.

9.4.1.   Kérés

A szolgáltatás maximális megbízhatóságának elérése és a bonyolultság ezzel egyidejű alacsony szinten tartása érdekében az NtS Web Service nem használ további lekérdezési nyelvet. Ehelyett a maga a WSDL által biztosított konstrukciókat alkalmazza. A konkrét műveleteket és paramétereiket teljes egészében a WSDL előíráson belül határozzák meg. Az NtS üzenetszolgáltatás esetében egyetlen műveletet definiálnak.

A tárgyspecifikus szűrési kritériumok az NtS szabványból származnak, de kiterjesztve a paraméterek sokaságára:

A szolgáltatás csak az adott kritériumoknak megfelelő üzeneteket küldi át.

Tördelési mechanizmus

Az adatok mennyiségének kontrollálása érdekében támogatott a tördelési mechanizmus. A tördelési paramétert az alábbi elemeket tartalmazó összetett típussal határozzák meg:

Az összetett tördelési paraméter opcionális, de ha van ilyen, minden benne szereplő elemet meg kell adni. Ekkor a tördelési mechanizmus a következőképpen működik:

Az üzenetek teljes száma nem haladja meg a limit paraméter értékét, azzal a kivétellel, hogy a 0 érték azt jelenti, nincs korlát. A válasz annyi üzenetet ugrik át, amennyit az offset paraméter meghatározott. E mechanizmus biztosításához a szolgáltatásnak az üzenetek ideiglenesen stabil (de egyébként önkényes) szekvenciáját kell figyelembe vennie, pl. a webszolgáltatás mögöttes adatkészletére vonatkozó üzenetadatok két frissítése között. Ez azt jelenti, hogy két egymást követő azonos hívásnak ugyanazon sorrendben kell ugyanazokat az üzeneteket átküldenie. A total count paraméter határozza meg, hogy a válasznak meg kell-e adnia a tárgyspecifikus kritériumoknak megfelelő összes üzenetet. Általában elegendőnek kell lennie, hogy ezt az információt az első válasszal kérjék le, és elhagyják azt minden további válaszban. Ez javítja a webszolgáltatás teljesítményét.

A tördelési mechanizmus eszközt biztosít arra, hogy az üzeneteket ismétlődően „oldalakra” kérjék le. Ahhoz, hogy a tördelési mechanizmus megfelelően működjék, ugyanazokat a tárgyspecifikus paramétereket kell megadni minden hívásban.

9.4.2.   Válasz

Sikeres kérés esetén az NtS Web Service válasza tartalmazza mindazokat az NtS üzeneteket, amelyek megfelelnek a kérési paramétereknek. Az NtS üzeneteknek meg kell felelniük az NtS sémának, és e séma mentén validálhatók. Mivel az üzenettípus kötelező kérési paraméter, az egyes válaszok csak ugyanazon üzenettípusba tartozó NtS üzenetet tartalmaznak (FTM, WRM, ICEM, illetve WERM).

Ha a szolgáltatás hibát tár fel a kérés feldolgozásakor, tetszőleges számú hibaüzenetet visszaküldhet, a következő alfejezetben felsorol hibakódokkal.

Az NtS Web Service válasza tartalmazhat egyidejűleg NtS üzeneteket és hibaüzeneteket is.

Opcionálisan tördelési információ is küldhető, ha a kérés tördelési paramétereket is tartalmazott. Ha az offset és az átküldött üzenetek száma kötelező elem, a teljes számot csak akkor kell megjeleníteni, ha azt kérték.

Figyelem: Vélelmezett, hogy a webszolgáltatás és a felhasználó közötti kommunikáció műszakilag megvalósul, azaz a szolgáltatás fogadja a kérést, a felhasználó pedig megkapja a megfelelő választ. Műszaki hibák, pl. az internetkapcsolat megszakadása vagy a webszolgáltatás el nem érhetősége karbantartás vagy összeomlás miatt itt nem jönnek figyelembe. Itt csak az olyan hibahelyzeteket tekintjük át, amelyek felhasználói szempontból a webszolgáltatás rétege „mögött” következnek be.

Hibaüzenetek

A várható hibahelyzetek hibakódjai és a magyarázatuk alább láthatók. A válaszban csak a hibakód szerepel, ami az NtS XML sémája esetén szokásos eljárásnak tekinthető.

Az NtS üzenetszolgáltatás hibakódjai

9.5.   Szolgáltatás és ügyfelek létrehozása

Ha következetesen betartják „a szerződés az első” megközelítést, azaz, ha a felületek teljes leírását tartalmazó egy vagy több szerződést WSDL dokumentumban adják meg, a szolgáltatás(ok) végrehajtása, valamint a megfelelő ügyfélnek történő teljesítés automatikusan megvalósul a megfelelő szoftvereszközökkel. Ideális esetben a generált forráskódon nem szükséges manuálisan változtatni.

Ugyanakkor a legtöbb esetben ismétlés szükséges, amíg a WSDL előírás nem felel meg ezen eszköz pontos követelményeinek. Jellemzően az eszköz a WSDL szabvány használatához egyedi igényeket támaszt a zökkenőmentes működés érdekében. Ennek következtében esetleg változtatni kell a WSDL előíráson, noha a WSDL előírás eredetileg érvényes előírás volt a WSDL szabvány szerint. Ha a webszolgáltatás WSDL előírása megváltozott a szolgáltatás vagy az ügyfél létrehozása után, akkor a létrehozott változtatásoktól függően új generációs folyamatra lehet szükség.

Glosszárium

(1)  A leírás a WS-I weboldalát idézi: http://www.ws-i.org

C. Függelék