Ändring av förordning (EG) nr 416/2007 om tekniska specifikationer för meddelanden till befälhavare

EUROPEISKA KOMMISSIONEN HAR ANTAGIT DENNA FÖRORDNING

med beaktande av fördraget om Europeiska unionens funktionssätt,

med beaktande av Europaparlamentets och rådets direktiv 2005/44/EG av den 7 september 2005 om harmoniserade flodinformationstjänster (RIS) på inre vattenvägar i gemenskapen, särskilt artikel 5.1 c, och

(1) Kommissionens förordning (EG) nr 416/2007 bör uppdateras, förfinas ytterligare och förtydligas med beaktande av de tekniska framstegen och erfarenheterna av tillämpning av förordning (EG) nr 416/2007.

(2) De tekniska specifikationerna för ”meddelanden till befälhavare” bör baseras på de tekniska principer som anges i bilaga II till direktiv 2005/44/EG.

(3) I syfte att förbättra säkerheten för sjöfarten bör ”meddelanden till befälhavare” utvidgas till att omfatta en ny typ av meddelanden om väder.

(4) Referenstabellerna med vattenståndsmätare bör tas bort från bilagan till förordning (EG) nr 416/2007, eftersom värdena, t.ex. referensvärden för låg och hög vattennivå, är dynamiska. Sådana data bör inkluderas och underhållas i ERDMS (European Reference Data Management System) som förvaltas av kommissionen.

(5) Det finns ett behov av att förbättra samstämmigheten mellan redigering och utveckling av tillämpningsprogram för att skapa tjänster med högre driftskompatibilitet. Av den anledningen bör riktlinjer för kodning för redaktörer och tillämpningsutvecklare inkluderas i de tekniska specifikationerna som tillägg A och B till bilagan.

(6) Datautbyte mellan myndigheterna rekommenderas enligt förordning (EG) nr 416/2007. För att förbättra datautbytet bör specifikationer kopplade till datautbyte anges i tillägg D till bilagan för att ge medlemsstaterna möjlighet att göra sina system driftskompatibla.

(7) För att säkerställa att medlemsstaterna ska kunna koda ”meddelanden till befälhavare” på ett konsekvent och driftskompatibelt sätt bör referenstabellerna i tillägg E förbättras. För detta syfte bör nya koder definieras i en ny referenstabell som innehåller harmoniserade gränssnittsetiketter för sökning i det grafiska användargränssnittet. Vidare bör nya taggar, värden och koder läggas till i befintliga referenstabeller och överflödiga objekt bör tas bort.

(8) De reviderade tekniska specifikationerna bör säkerställa att referenstabellerna i tillägg E även tillgängliggörs elektroniskt i ERDMS (European Reference Data Management System) som förvaltas av Europeiska kommissionen.

(9) Enligt artikel 12.2 i direktiv 2005/44/EG bör medlemsstaterna, för att efterleva bestämmelserna i artikel 4 i samma direktiv, vidta nödvändiga åtgärder för att genomföra kraven i denna förordning senast 30 månader efter dess ikraftträdande.

(10) Förordning (EG) nr 416/2007 bör därför ändras i enlighet med detta.

(11) De åtgärder som föreskrivs i denna förordning är förenliga med yttrandet från den kommitté som anges i artikel 11 i direktiv 2005/44/EG.

HÄRIGENOM FÖRESKRIVS FÖLJANDE.

Artikel1¶

Bilagan till förordning (EG) nr 416/2007 ska ersättas med bilagan till den här förordningen.

Artikel2¶

Denna förordning träder i kraft dagen efter det att den har offentliggjorts i Europeiska unionens officiella tidning.

1 EUT L 255, 30.9.2005, s. 152.

2 Kommissionens förordning (EG) nr 416/2007 av den 22 mars 2007 om tekniska specifikationer för de ”meddelanden till befälhavare” som avses i artikel 5 i Europaparlamentets och rådets direktiv 2005/44/EG om harmoniserade flodinformationstjänster (RIS) på inre vattenvägar i gemenskapen (EUT L 105, 23.4.2007 s. 88).

BILAGA

1. ALLMÄNNA BESTÄMMELSER

1.1. Definitioner

Informationstjänster för farleder (FIS) avser geografisk, hydrologisk och administrativ information om vattenvägar (farleder) som används av befälhavare och ansvariga för fartygsflottor för att planera, genomföra och övervaka resor. Termerna båtförare och skeppare som används i den befintliga standarden ska anses vara likvärdig termen befälhavare som används i Flodinformationstjänsternas (RIS) riktlinjer (kommissionens förordning (EG) nr 414/2007) medan termen ansvarig för fartygsflottan definieras i kommissionens förordning (EG) nr 415/2007.

FIS tillhandahåller dels dynamisk information (t.ex. vattennivåer, vattennivåprognoser etc.), dels statisk information (t.ex. slussars och broars ordinarie öppettider) som rör utnyttjandet av infrastrukturen på inre vattenvägar och dess status och ligger därmed till grund för taktiska och strategiska navigeringsbeslut.

Traditionella metoder att förmedla FIS är bland annat visuella navigeringshjälpmedel, ”meddelanden till befälhavare” förmedlade på papper, via radioutsändningar och fasta telefoner vid slussar. Mobiltelefoner har skapat nya möjligheter när det gäller tal- och datakommunikation, men mobilnätet är fortfarande inte tillgängligt överallt och när som helst. Skräddarsydda informationstjänster för vattenvägar kan tillhandahållas genom radiotelefoni på inre vattenvägar, internet eller ett elektroniskt sjökort, t.ex. Inland Electronic Chart Display and Information System (Inland ECDIS) med Electronic Navigational Chart (ENC).

1.2 Primära funktioner och prestandakrav för ”meddelanden till befälhavare”

I följande tekniska specifikationer för ”meddelanden till befälhavare” fastställs regler för dataöverföringen av farledsinformation via internet.

”Meddelanden till befälhavare” ska:

a) tillhandahålla information om förhållanden på farleder, trafikläget, väder, vattennivåer och is för Informationstjänster för farleder (FIS),

b) tillhandahålla automatisk översättning av det viktigaste innehållet i meddelandena med standardvokabulär som baseras på kodlistor (referenstabellerna för ”meddelanden till befälhavare” i Tillägg E),

c) tillhandahållas i en standardiserad struktur av datauppsättningar som underlättar meddelandenas integrering i system för ruttplanering,

d) vara kompatibla med datastrukturen hos RIS Index och Inland ECDIS för att underlätta integrering av meddelandena i Inland ECDIS såsom föreskrivs av Europaparlamentets och rådets direktiv 2005/44/EG av den 7 september 2005 om harmoniserade flodinformationstjänster (RIS) på inre vattenvägar i gemenskapen.

De tekniska specifikationerna för ”meddelanden för befälhavare” underlättar datautbyte mellan meddelandesystem i olika länder och mellan andra tillämpningar som använder informationen i meddelandena, inklusive Inland ECDIS.

Viss information i meddelandena kan standardiseras, men inte all information.

Den standardiserade delen ska omfatta all information som är

a) viktig för säker inlandssjöfart (t.ex. små skeppsvrak på höger sida av farleden i Donau, flodkilometer 2010),

b) nödvändig för ruttplanering (t.ex. stängda slussar, reducerad frihöjd …),

Annan information som inte är relevant för säkerhet eller ruttplanering (t.ex. orsaker till stängda slussar) kan lämnas som fritext utan automatisk översättning. Användningen av fritext ska begränsas till ett minimum.

2. TILLHANDAHÅLLANDE AV ”MEDDELANDEN TILL BEFÄLHAVARE”

Medlemsstater ska se till att ”meddelanden till befälhavare” är tillgängliga online och via en standardiserad webbtjänst i enlighet med de tekniska specifikationer som anges i denna bilaga och dess tillägg. Specifikationer för denna standardiserade webbtjänst anges i tillägg D i form av WSDL, Web Service Description Language.

De standardiserade webbtjänsterna ska ge användarna möjlighet att välja meddelanden baserat på minst ett av följande kriterier:

a) ett visst avsnitt av en vattenväg

b) en viss del av en vattenväg, definierad genom flodkilometer vid start- respektive slutpunkt,

c) meddelandets giltighetstid (start- och slutdatum för giltighetsperiod),

d) och ett datum för publicering av meddelandet (datum för publicering).

Meddelanden som uppfyller de standarder som beskrivs i denna bilaga kan lämnas via olika verktyg, bland annat:

a) mobilapplikationer (appar),

b) e-post.

Datautbyte mellan meddelandesystemen i olika länder är möjligt. Alla system som använder de standarder som beskrivs i bilagan till denna förordning kan integrera ”meddelanden till befälhavare” från andra system i sina tjänster, förutsatt att innehållet i meddelandet inte ändras. Användare ska informeras om anslutningen till en tjänst som tillhandahåller meddelanden avbryts eller inte är tillgänglig.

3. TYPER AV ”MEDDELANDEN TILL BEFÄLHAVARE”

”Meddelanden till befälhavare” är viktiga meddelanden som standardiseras i allra möjligaste mån.

Det finns fyra typer av meddelanden:

a) meddelande om farled och trafik,

b) meddelande om vatten,

c) meddelande om is,

d) meddelande om väder.

4. MEDDELANDENAS UPPSTÄLLNING OCH KODNING

I detta kapitel beskrivs hur de standardiserade elektroniska ”meddelandena till befälhavare” ska vara uppställda och kodade.

Ett ”meddelande till befälhavare” är ett strukturerat meddelande som så långt det är möjligt består av standardiserade element. Användningen av fritext i dataelementen ska begränsas till ett minimum.

Definitionen för XML-schemat för standardiserade ”meddelanden till befälhavare”, som i denna standard kallas XSD, innehåller de standardiserade kodvärdena och möjliga format som beskrivs i tillägg C.

De standardiserade kodvärdena och XML-taggarna och dessas betydelser och översättningar tillhandahålls i referenstabellerna för ”meddelanden till befälhavare” i tillägg E och finns även tillgängliga elektroniskt i EDMS (European Reference Data Management System) som förvaltas av Europeiska kommissionen.

4.1. Allmän uppställning

Ett ”meddelande till befälhavare” består av följande avsnitt:

a) Identifieringsavsnitt.

b) Avsnitt som definierar de aktuella objekt eller farledsavsnitt som meddelandet avser.

c) Begränsning(ar) för ett meddelande farled och trafik, mätning(ar) för ett meddelande om vatten, isförhållanden för ett meddelande om is eller väderleksrapport(er) för ett meddelande om väder.

Figur 1 Struktur för ”meddelanden till befälhavare”

4.1.1. Identifieringsavsnitt

Varje meddelande måste innehålla ett identifieringsavsnitt. Identifieringsavsnittet innehåller allmän information om avsändare och datum för publicering av meddelandet.

4.1.2. Meddelanden om farled och trafik

Meddelanden om farled och trafik innehåller information om farledsavsnitt eller om objekt i farleder och används för att indikera begränsningar i följande syften:

a) ”Varning”: relevant för säkerhet. Varningen måste innehålla minst en begränsning som leder till direkt och konkret fara för personer, fartyg eller anläggningar, som t.ex. svetsarbeten på en bro som sprider gnistor, inspektionsbur/arbetare som hänger från en bro eller hinder i farleden.

b) ”Meddelande”: relevant för ruttplanering eller säkerhet. Meddelandet kan innehålla begränsningar, som t.ex. blockering av slusskammare på grund av underhållsarbete, muddring i farleden.

c) ”Informationstjänst”: allmän information som inte är direkt kopplad till ruttplanering eller säkerhet. Informationstjänsten måste inte innehålla några särskilda begränsningar och är därför inte relevant för ruttplanering eller säkerhet. Meddelandena kan innehålla allmän information, som t.ex. lokala trafikregler eller uppdatering av Inland ECDIS.

4.1.3. Meddelanden om vatten

Avsnittet om vatten innehåller värden eller prognoser för

a) vattennivå,

b) minsta lodade djup,

c) frihöjd,

d) fördämningsstatus,

e) utsläpp,

f) ordning.

Information som rör vatten skapas och publiceras vanligtvis automatiskt, baserat på data från sensorutrustning (som t.ex. tidvattenmätare), system (modell för vattennivåer) eller på infrastrukturdata (som t.ex. fördämningsstatus). Meddelanden kan publiceras av olika anledningar: det kan handla om periodiska publiceringar eller att ett visst värde nås.

4.1.4. Meddelanden om is

Meddelanden om is innehåller information om aktuella eller prognostiserade isförhållanden för farledsavsnitt. Information om isförhållanden genereras vanligtvis av kompetent personal som gjort observationer lokalt och genomfört en yrkesmässig utvärdering.

4.1.5. Meddelanden om väder

Meddelanden om väder innehåller information om (farliga) väderförhållanden för inlandssjöfart.

För att underlätta spridningen av hydrologisk och meteorologisk information från hydrologiska och meteorologiska nätverk till befälhavare kan meddelanden om väder publiceras.

4.2. Förklaring av XML-taggar och kodvärden i referenstabellerna för ”meddelanden till befälhavare”

Betydelsen av de olika element som används i definitionen för XML Schema Definition (XSD) för meddelanden beskrivs i referenstabellerna för ”meddelanden till befälhavare” i tillägg E. Strukturen, formatet och möjliga värden för alla XML-element beskrivs i XSD-avsnittet för meddelanden i tillägg C.

a) Latitud- och longitudkoordinater kodas enligt World Geodetic System 1984 (WGS 1984) och presenteras i grader och minuter med minst tre, men helst fyra, decimaler ([d]d mm.mmm[m] N, [d][d]d mm.mmm[m] E).

b) Decimaler i numeriska fält anges med decimalpunkt (.). Inga tusentalsavgränsare används.

c) ”Meddelande till befälhavare” ska endast använda följande enheter för värden i XML-meddelanden: cm, m3/s, h, km/tim och kW, m/s (vind), mm/h (regn) och grader Celsius. Enheterna kan konverteras i nationella tillämpningar för att öka användarvänligheten.

4.3. Identifiering av farledsavsnitt och objekt i ”meddelanden för befälhavare”

För att uppfylla kraven på minsta mängd data för tillhandahållande av information om relevanta objekt för inlandssjöfart enligt vad som avses i artikel 4.3 a i direktiv 2005/44/EG måste ISRS-identifieringskoder (ISRS Location Code) användas i avsnittet om objektet. Identifieringskoden är ett unikt identifieringsnummer för objekt och farledsavsnitt. Koden används för att säkra driftskompatibilitet mellan RIS-system och-tjänster (för att kombinera information om infrastruktur från RIS Index, Inland ECDIS och ”meddelanden till befälhavare” för ruttplanering).

Identifieringskoden består av 20 alfanumeriska tecken. Den används för att upprätta en unik och standardiserad relation mellan objekt i RIS, River Information Services (Flodinformationstjänster). Den består av följande obligatoriska dataelement som arrangeras i fyra informationsblock:

a) Block 1: FN:s landskod/LOCODE (5 alfanumeriska tecken), bestående av

landskod (2 alfanumeriska tecken) och

lokaliseringskod (3 alfanumeriska tecken, ”XXX” om ej tillgängligt).

b) Block 2: Kod för farledsavsnitt (5 tecken, alfanumeriska, bestäms av nationell myndighet).

c) Block 3: Referenskod för objekt (5 alfanumeriska tecken, ”XXXXX” om ej tillgängligt).

d) Block 4: Hektometer för farledsavsnitt (5 numeriska tecken, hektometer i områdets mittpunkt eller ”00000” om ej tillgängligt).

ISRS-identifieringskoder och objektreferensdata underhålls av medlemsstaterna i RIS Index och kommuniceras till ERDMS som förvaltas av Europeiska kommissionen i enlighet med underhållsprocedurerna för RIS Index som finns publicerade på ERMDS webbplats.

4.4. Regler för kodning av ”meddelanden till befälhavare”

”Meddelanden till befälhavare” ska kodas enligt vägledningen Kodning av meddelanden till befälhavare – vägledning för redaktörer (tillägg A) och enligt Kodning av meddelanden till befälhavare – vägledning för tillämpningsutvecklare (tillägg B).

1 Kommissionens förordning (EG) nr 414/2007 av den 13 mars 2007 om de tekniska riktlinjer för planering, genomförande och drift av flodinformationstjänster (RIS) som avses i artikel 5 i Europaparlamentets och rådets direktiv 2005/44/EG om harmoniserade flodinformationstjänster (RIS) på inre vattenvägar i gemenskapen (EUT L 105, 23.4.2007, s. 1).

2 Kommissionens förordning (EG) nr 415/2007 av den 13 mars 2007 om tekniska specifikationer för de spårningssystem för fartyg som avses i artikel 5 i Europaparlamentets och rådets direktiv 2005/44/EG om harmoniserade flodinformationstjänster (RIS) på inre vattenvägar i gemenskapen (EUT L 105, 23.4.2007, s. 35).

3 FN:s landskoder definieras enligt punkt 2.4.2.12 i bilagan till kommissionens förordning (EU) nr 164/2010 (EUT L 57, 6.3.2010, s. 1). FN:s landskoder är identiska med ISO 3166-1 Alpha-2-landskoderna.

A. KODNING AV MEDDELANDEN TILL BEFÄLHAVARE – VÄGLEDNING FÖR REDAKTÖRER

Förkortningar

1. Bakgrund, struktur och syfte för vägledning för kodning av ”meddelanden till befälhavare”

Standarderna för ”meddelanden till befälhavare” förbättras fortlöpande. Utrullningen av webbtjänsten för meddelanden var ett stort steg framåt. Tjänsten underlättar utbyte av ”meddelanden till befälhavare” mellan olika myndigheter och mellan myndigheter och mottagare av ”meddelanden till befälhavare”.

Två dokument har utvecklats för att underlätta harmoniserad kodning av ”meddelanden till befälhavare” nationellt och internationellt: Kodning av meddelanden till befälhavare – vägledning för redaktörer och Kodning av meddelanden till befälhavare – vägledning för tillämpningsutvecklare. Dessa vägledningar gäller för XSD 4.0 för meddelanden för befälhavare och webbtjänsten för meddelanden WSDL 2.0.4.0.

Med beaktande av den ökade användningen av webbtjänsten för meddelanden ska meddelandena harmoniseras ytterligare för att säkra korrekt visning av innehållet i tredje parts system. Enhetlig kodning av meddelanden är också en förutsättning för användning av meddelande i tillämpningar för ruttplanering.

Element som endast innehåller standardvärden ska utelämnas om de är villkorliga eftersom de leder till ökad administration av betydelselös information.

Vägledningen för kodning av ”meddelanden till befälhavare” för redaktörer är avsedd för personer som redigerar och publicerar ”meddelanden till befälhavare” och omfattar stegvisa instruktioner för hur man skapar rätt typ av meddelande och en förklaring av koderna. Vägledningen för kodning av ”meddelanden till befälhavare” förklarar hur de fyra olika typerna av ”meddelanden till befälhavare” ska användas och innehåller utförliga instruktioner samt koder som ska användas i vissa situationer. Vägledningen för kodning av ”meddelanden till befälhavare” för redaktörer finns i tillägg A till detta dokument.

Vägledningen för kodning av ”meddelanden till befälhavare” för tillämpningsutvecklare omfattar riktlinjer för utveckling och implementering av tillämpningar för ”meddelanden till befälhavare” och förklarar bakomliggande logik, processer och automatiska värden/standardvärden. Vägledningen för kodning av ”meddelanden till befälhavare” för tillämpningsutvecklare finns med i tillägg B till bilagan till denna förordning.

2. Val av meddelandetyp

FTM: Välj denna typ om du vill skapa ett meddelande om farleds och trafik för vattenvägar eller objekt på vattenvägen. [gå till kapitel 3]

WRM: Välj denna typ om du vill skapa ett meddelande om vatten för att förmedla information om aktuella och prognostiserade vattennivåer samt annan information. Meddelandet om vatten innehåller information om ett objekt eller ett farledsavsnitt. Objektet definieras med dess ISRS-identifieringskod och farledsavsnittet definieras med ISRS-identifieringskoder för avsnittets början och slut.

ICEM: Välj denna typ om du vill skapa ett meddelande om is. Avsnittet om is innehåller information om isförhållanden för en sträcka på en farled som definieras med ISRS-identifieringskoder för dess början och slut.

WERM: Välj denna typ om du vill skapa ett meddelande om väder för att förmedla information om aktuellt och prognostiserat väder för en sträcka på en vattenväg som definieras med ISRS-identifieringskoder för dess början och slut.

3. Grundläggande överväganden för meddelande om farled och trafik (FTM, Fairway and Traffic related Message), steg för publicering av ett FTM

Detaljerad information om vilka koder som måste användas finns i kapitel 4. Övervägandena från och med punkt 3.3 är inte nödvändiga för inmatningsordningen vid användning av ett FTM-redigeringsverktyg.

3.1. Måste information publiceras via FTM till befälhavare i enlighet med standarden för ”meddelanden till befälhavare”? All relevant information som rör säkerhet och ruttplanering måste publiceras via ”meddelanden till befälhavare”. Information som inte är relevant för säkerhet och ruttplanering kan publiceras. Varje ämne/tillbud/händelse måste publiceras i ett separat meddelande.

3.2. Finns det redan ett FTM om den aktuella situationen (med koppling till innehållet och giltighetstiden)?

3.2.1. Ja: Det befintliga FTM-meddelandet måste uppdateras. Respektive publicerat meddelande måste väljas och uppdateras i FTM-redigeringsverktyget. Det går inte att uppdatera ett FTM vars giltighetstid har löpt ut.

3.2.2. Nej: Ett nytt FTM måste skapas. Om en liknande händelse redan finns kodad i ett befintligt FTM kan det aktuella FTM-meddelandet användas som utkast till ett nytt FTM (om denna funktion är tillgänglig) eller så kan en mall användas (om denna funktion är tillgänglig).

3.3. Geografiskt område måste anges

3.3.1. Om FTM-meddelandet är kopplat till en specifik sträcka på en vattenväg måste denna sträcka anges i form av dess start- och slutpunkter. Om innehållet gäller för flera avsnitt av samma vattenväg eller olika vattenvägar kan alla avsnitt listas i ett FTM.

3.3.2. Om FTM-meddelandet gäller ett specifikt objekt (t.ex. en bro, en sluss etc.) på vattenvägen ska respektive objekt väljas från listan över tillgängliga objekt (om det är möjligt att välja). En sträcka på en vattenväg behöver inte definieras i meddelandet. Om ett FTM gäller flera objekt kan alla objekt inkluderas i ett och samma FTM.

3.3.3. Det går att kombinera information om objekt och farleder i ett och samma meddelande så länge information gäller en specifik händelse/har en specifik orsak (samma kod för ämne och anledning).

3.3.4. Även om koordinaterna är villkorade ska de tillhandahållas för att stödja visningen på kartor (dessa koordinater tillhandahålls ofta automatiskt av tillämpningen för meddelandena).

3.4. Ange innehållet i FTM-meddelandet All information som kan förmedlas via referenstabellerna för ”meddelanden till befälhavare” måste kodas i de standardiserade meddelandefälten. Endast annan information (som annars inte kodas) ska anges i de fria textfälten.

3.5. Målgruppen/målgrupperna för fartygstyp och aktuella riktningar ska anges om tillämpligt.

3.5.1. Om meddelandet är giltigt för alla båtar (alla slags fartyg) i alla riktningar ska målgruppen utelämnas så att endast nödvändig information kodas. Om meddelandet/begränsningen är riktade till en specifik målgrupp eller en specifik riktning ska respektive koder väljas.

3.5.2. Om hela meddelandet är riktat till specifika målgrupper ska informationen om målgrupp tillhandahållas i den allmänna delen av FTM-meddelandet (och inte upprepas i avsnitten om begränsningar).

3.5.3. Om flera olika begränsningar gäller för flera olika målgrupper ska informationen om målgrupp tillhandahållas inom de respektive begränsningarna (och inte upprepas i avsnitten om begränsningar).

3.5.4. Om behöriga myndigheter gör undantag från begränsningar för individuella fartyg eller lokal trafik (t.ex. fartyg som deltar i ett evenemang för vilket en allmän blockering är tillämplig, lokal färjetrafik i blockerade områden) behöver undantagen inte beaktas i kodningen av målgruppen/målgrupperna. Sådan information kan anges i fritextfältet för ytterligare information.

3.6. Kommunikationsavsnittet ska finnas med, om tillämpligt Om ytterligare information är tillgänglig via en specifik källa bör det anges i detta avsnitt. Om det finns ytterligare krav på rapportering via ett specifikt medium ska det anges i detta avsnitt.

3.7. Avsnittet om begränsningar ska finnas med, om tillämpligt Om begränsningar är tillämpliga ska avsnittet om begränsningar fyllas i. Om värden kopplade till begränsningar är kända måste de anges. Det är obligatoriskt att ange värden för fartygens dimensioner, hastighetsbegränsning och tillgängligt navigeringsutrymme. Alla begränsningar måste innefatta begränsningsperioder för att korrekta beräkningar i ruttplaneringstillämpningar ska kunna göras (för att underlätta arbetet kan det finnas en funktion i tillämpningen för ”meddelanden till befälhavare” för kopiering av begränsningsperioder eller val av mer än en begränsning för en begränsningsperiod).

3.8. Startdatum för meddelandets giltighet ska anges Om slutdatum för giltighet redan är känt ska även det anges. Giltighetstidens slutdatum får inte vara tidigare än aktuellt datum. Observera att informationen om giltighetsperioden kommer att användas av tillämpningar för att välja meddelanden som ska visas för användare som begär information om en viss tidsperiod. Om meddelandet dras tillbaka:

a) Innan giltighetsperioden har börjat: start- och slutdatum måste sättas till det datum då meddelandet dras tillbaka.

b) Giltighetsperioden har redan har börjat: de nya slutdatumen för alla begränsningar ska sättas till ett passerat datum och slutdatum för giltighetsperioden ska sättas till det datum då meddelandet dras tillbaka.

3.9. Meddelandet kan publiceras

4. Förklaring av koder i FTM

4.1. Subject_code:

Definitioner för användningen av ämneskoder (Subject_code):

”Varning”: relevant för säkerhet. Varningen måste innehålla minst en begränsning som leder till direkt och konkret fara för personer, fartyg eller anläggningar, som t.ex. svetsarbeten på en bro som sprider gnistor, inspektionsbur/arbetare som hänger från en bro eller hinder i farleden.

”Meddelande”: relevant för ruttplanering eller säkerhet. Meddelandet kan innehålla begränsningar, som t.ex. blockering av slusskammare på grund av underhållsarbete, muddring i farleden eller trafikregler utöver nationell lagstiftning.

”Informationstjänst”: allmän information som inte är direkt kopplad till ruttplanering eller säkerhet. Informationstjänsten måste inte innehålla några särskilda begränsningar och är därför inte relevant för ruttplanering eller säkerhet. Sådan information kan t.ex. omfatta lokala trafikregler eller uppdateringar från Inland ECDIS. Giltighetsperioden används för att specificera tiden som informationstjänstmeddelandet visas för användarna, inte giltighetsperioden för informationen (t.ex. 1 månad eller enligt vad som definieras i nationella procedurer).

”Indraget meddelande” Ämneskoden ”Indraget meddelande” används endast i följande fall: I detta fall avslutas åtgärder/evenemang innan den initialt angivna giltighetsperioden för ett befintligt FTM har löpt ut.

Aktuellt datum är tidigare än giltighetsperiodens startdatum. I sådant fall kan innehållet i fältet ”annan information på nationellt språk” ändras. Övrigt innehåll i meddelandet får inte ändras. I sådant fall används ”Indraget meddelande” för att dra tillbaka ett meddelande innan det börjar gälla. Det innebär att ”Indraget meddelande” används för meddelanden som inte börjat gälla och/eller för planerade åtgärder som inte kommer att genomföras (t.ex. om muddring planerats men inte går att påbörja på grund av höga vattennivåer).

Giltighetsperioden har redan börjat och de nya slutdatumen för alla begränsningar är satta till ett datum som passerats. Slutdatum för giltighetsperiod måste sättas till det datum då meddelandet dras tillbaka.

4.2. Reason_code

Orsakskoden (Reason_code) bör anges för att tillhandahålla ytterligare information till befälhavarna.

Definitioner för användningen av orsakskoder:

4.3. Limitation_code:

Definitioner för användningen av begränsningskoder (Limitation_code):

blockering: Om ingen form av sjöfart är möjlig

genom en slusskammare,

genom en broöppning,

genom en bestämd punkt i farleden,

på en bestämd sträcka av farleden.

delvis obstruktion: Alla delar av infrastrukturen (t.ex. slusskammare, broöppningar) ska ha en individuell identifieringskod (ISRS Location Code). Om sådana koder fortfarande saknas kan delvis obstruktion användas om begränsad sjöfart är möjlig (t.ex. om endast objekt vid slussområde är tillgängligt för en sluss med två parallella slusskammare)

genom en eller flera slusskammare i en sluss, vilket innebär att åtminstone en är öppen,

genom en eller flera broöppningar, vilket innebär att åtminstone en är öppen.

ingen service: ska användas om en rörlig bro inte öppnas under en angiven period. Denna period ska infalla under normala öppettider. Ingen service när det gäller rörliga broar innebär att det fortfarande är möjligt att passera under bron. I annat fall är det detsamma som ”Blockering”. Ingen service när det gäller slussar ska kodas som ”Blockering”.

ändrad service: ska användas om normala öppettider för objekt (t.ex. slussar, (rörliga) broar) ändras, förlängs eller reduceras.

Om det finns begränsningar för tillåtna dimensioner för fartyg/konvojer (ej med direkt koppling till infrastruktur) ska begränsningen kodas med följande textelement: Om ett absolut värde är tillgängligt ska det tillhandahållas.

Fartygets djupgående.

Fartygsbredd.

Konvojbredd.

Fartygslängd.

Konvojlängd.

Fartygets höjd över vattenytan.

Om det finns begränsningar för tillgänglig storlek för ett objekt eller ett avsnitt av en vattenväg används följande koder: Om ett absolut värde är tillgängligt ska det tillhandahållas.

Frihöjd.

Tillgänglig längd.

Farledsbredd.

Tillgängligt djup.

minsta lodade djup: ska användas om djupet kan orsaka problem (t.ex. på grund av slamavsättning). Ett värde för det absoluta eller reducerade djupet (hänvisning till ett referensvärde) ska tillhandahållas. Om ett absolut värde är tillgängligt ska det tillhandahållas.

försening: ska användas om det föreligger en tidsbegränsad obstruktion eller ett tillbud vid ett objekt eller på en sträcka mellan angivna start- och slutdatum. Beräknad maximal varaktighet för obstruktionen/tillbudet ska kodas. Försening ska inte användas när en av flera slusskammare i en sluss inte är tillgänglig.

Om specifika manövrar eller åtgärder är förbjudna ska respektive begränsningar kodas. Dessa begränsningar ska endast kodas om de inte redan meddelats via skyltar eller föreskrifter som är kodade i det officiella sjökortet för inre vattenvägar Om ett absolut värde för hastighetsbegränsning och minsta motoreffekt är tillgängligt ska det tillhandahållas.

minsta motoreffekt,

alternerande farledsriktning,

vändning förbjuden,

passering förbjuden,

omkörning förbjuden,

tilläggning förbjuden,

förtöjning förbjuden,

ankring förbjuden,

undvik svall,

hastighetsbegränsning,

ej tillåtelse att gå i land.

särskild försiktighet: Om ett FTM (eller del av ett FTM) gäller en farled/vattenväg ska denna begränsning användas för att indikera positionen på farleden/floden/kanalen/sjön där ett tillbud inträffar. Vidare ska det användas i fall där det inte är möjligt att beskriva begränsningen detaljerat, men där det är till hjälp eller nödvändigt att varna eller informera befälhavare om att de behöver vara vaksamma och lyssna på information på radion.

ingen begränsning: ska endast användas om det uttryckligen anges att det inte finns några begränsningar under en viss tidsperiod.

4.4. Begränsning för interval_code:Definitioner för användningen av intervallkoder (interval_code):

fortlöpande: ska användas för begränsningar som gäller från ett startdatum/en starttid till ett slutdatum/en sluttid utan avbrott (t.ex. blockering från 2016-01-01, kl. 00.00, till 2016-03-31, kl. 23.59, men även blockering 2016-09-17 från kl. 08.00 till 18.00).

dagligen: ska användas för regelbundet upprepad tillämpning av en begränsning (t.ex. inga svallvågor under arbetstid vid muddringsarbete – 2016-04-07 till 2016-04-11, dagligen från kl. 06.00 till 18.00.)

dagtid (enligt definition i CEVNI): Termen dag avser perioden mellan soluppgång och solnedgång.

nattetid (enligt definition i CEVNI): Termen natt avser perioden mellan solnedgång och soluppgång.

Veckans dagar: om det finns intervall för olika dagar i veckan måste dessa väljas från följande textelement:

Måndag.

Tisdag.

Onsdag.

Torsdag.

Fredag.

Lördag.

Söndag.

Måndag till fredag.

Lördag och söndag.

vid begränsad sikt: ska användas om begränsningen endast gäller vid förhållanden där det är begränsad sikt på grund av dimma, dis, snö, regn eller andra orsaker.

med undantag av: ska ej användas: avbrutna intervall måste anges som separata begränsningsperioder inom samma begränsning. Detta beror på att programvara för ruttplanering inte kan tolka koden korrekt och uttyda att den inte gäller för det givna datumet eller den givna tiden. Därför är det inte möjligt att beräkna korrekta ankomsttider.

måndag till fredag, utom allmänna helgdagar: ska endast användas om helgdagar är inom begränsningens giltighetsperiod. Som en tjänst till användarna kan information om helgdagar anges i FTM-meddelandets fritextfält. Programvara för ruttplanering kommer inte att kunna ta hänsyn till nationella helgdagar för beräkning av ankomsttider.

4.5. Indication_code:

Indication_code är avsedd att användas för information om specifika värden med avseende på vissa begränsningar (t.ex. hastighetsgräns, minsta effekt, tillgängligt djup). För att fastställa vissa dimensioner krävs en referens till antingen ett externt referenssystem (geografiskt eller hydrologiskt) (t.ex. frihöjd, tillgängligt djup, minsta lodade djup) eller information som relaterar till kända dimensioner för konstruktioner (t.ex. tillgänglig längd, farledsbredd).

4.5.1. Om absoluta dimensioner eller referenser är kända måste de användas. Relativa värden ska endast användas om det inte är möjligt att hänvisa till ett externt referenssystem.

4.5.2.

Reducerat med: → detta är ett relativt värde

4.5.3.

Maximum: → detta är ett absolut värde

4.5.4.

Minimum: → detta är ett absolut värde

4.5.5. Om dimensionen som indikerar en begränsning hänvisar till en geografisk eller hydrologisk koordinat måste respektive referenssystem indikeras i meddelandet till befälhavare (t.ex. frihöjd min. 4 m med hänvisning till högsta farbara vattennivå; tillgängligt djup min. 1,7 m med hänvisning till reglerad låg vattennivå)

4.5.6. Om dimensionen som indikerar en begränsning hänvisar till en dimension för en konstruktion (t.ex. en bro, en sluss) kan hänvisningen anges i relation till kända dimensioner (t.ex. frihöjd minskad med 1,5 m, tillgänglig längd minskad med 27 m).

4.6. Position_code (objekt):

Där så är möjligt ska Position_code hänvisa till sidan av farleden där objektet är lokaliserat i relation till farledens axel (vänster/mitten/höger) eller annan allmänt känd information (gammal/ny) eller geografisk riktning (nord/syd/öst/väst). Position_code för objekt kan fyllas i automatiskt i förväg från referensdata i RIS Index. Vänster/höger sida av farleden definieras i nedströms riktning.

4.7. Position_code (farleder/vattenvägar):

En Position_code för ett FTM (eller del av ett FTM) som är relaterat till en farled eller vattenväg tillhandahålls inte. För att indikera på vilken sida av farleden/kanalen/floden/sjön ett tillbud inträffar används begränsningen ”Varning” i kombination med korrekt Position_code för begränsningen.

4.8. Position_code (begränsningar):

4.8.1. Där så är möjligt ska Position_code hänvisa till den sida av farleden där begränsningen är lokaliserad (vänster/höger). Vänster/höger sida av farleden definieras i nedströms riktning.

4.8.2. Position_code ska rikta befälhavarens uppmärksamhet mot den sida av farleden där t.ex. ett särskilt intressant område, en fara eller ett hinder är lokaliserat. Därför räcker en grov indikation (till exempel vänstra banken – vänster – mitten – höger – högra banken). En mer specificerad indelning är inte avsedd.

4.8.3. Om nödvändigt bör mer exakt positionsinformation anges, föredragsvis i form av kartor eller skisser (bilaga, se kapitel 3.6).

4.8.4. För avsnitt där den vanliga positionsindikeringen av farledssidan (vänster/höger) inte verkar lämplig (t.ex. hamnbassänger, vissa delar av kanaler utan distinkt flödesriktning) kan väderstreck användas (norr/öst/syd/väst).

4.9. Target_group_code (se kapitel 3.5)

4.10. Reporting_code

4.10.1. Reporting_code ska, som regel, endast användas om det finns ett särskilt behov av kommunikation (t.ex. extra rapporteringsskyldighet till kommunen med avseende på trafikreglering på plats) eller där ytterligare information finns tillgänglig (t.ex. VHF-kontaktpunkt som t.ex. kanalnamn eller anropssignal för nuvarande position för mudderverk) med direkt relevans för FTM-meddelandet.

4.10.2. En rutinmässig upprepning av offentligt tillgängliga kommunikationsdata (t.ex. telefonnummer till lokala myndigheter, VHF-kanaler för slussar etc.) ska undvikas om det inte finns någon direkt orsak till sådan kommunikation med avseende på FTM-meddelandet.

4.10.3. Generellt tillämpliga kommunikationssätt i enlighet med officiella förordningar (t.ex. VHF mellan fartyg och VHF mellan fartyg och land enligt vad som fastställts i CEVNI eller enligt regionala eller nationella regler för sjöfart) ska som regel inte upprepas av Reporting_code om det inte finns någon direkt orsak till sådan kommunikation med avseende på FTM-meddelandet).

4.11. Communication_code

Följande format ska användas (exempel):

VHF ”nummer, anropssignal”: ”10, Schifffahrtsaufsicht Wien”

Telefonnummer eller faxnummer: ”+43123456789, Schifffahrtsaufsicht Wien”

Webbadress: ”http://example.com”

Ljudsignalering: ”lång ljudsignal/langer Ton”

E-post: ”example@authority.eu”

EDI-postlådenummer: ”900012345@edi.bics.nl”

Teletext: ”ARD, 992 – 995”

4.12. Type_code:

En vattenväg är antingen en kanal, sjö eller flod.

ankringsområde

bank

signalboj

kaj

gränskontroll

bro

broöppning

boj

luftledning

kanal (termen kanal används om ett meddelande gäller för hela kanalen (inte bara farleden))

kanalbro: akvedukt

kulvert

farled (termen farled avser den del av vattenvägen som kan användas för sjöfart)

färja

flytdocka

dammlucka (dammluckor används för att skydda ett område vid högvatten)

hamn

hamnanläggning

hamnkaptenens kontor

sjö (termen sjö används om ett meddelande gäller för hela sjön (inte bara farleden))

ljus

slusskammare: individuell slussbassäng

sluss: hela slussanordningen

förtöjningsanläggning

trafikmärke

pipeline

luftpipeline

ramp

sopinsamlingspunkt

rapporteringspunkt

vattenmagasin

flod (termen flod används om ett meddelande gäller för hela floden (inte bara farleden))

fartygshiss

varv

signalstation

terminal

tidvattenmätare

tunnel

vändplats

center för fartygstrafik

damm (en damm används för att kontrollera vattennivån i floder)

5. Grundläggande överväganden för meddelande om vatten (WRM, Water Related Message)

Meddelanden om vatten ska som regel genereras automatiskt. När detta inte är möjligt ska manuell generering av WRM följa de angivna processerna för automatiskt genererade WRM (se Kodning av meddelanden till befälhavare – vägledning för utvecklare) så noggrant som möjligt.

6. Grundläggande överväganden för meddelande om is (ICEM, ICE related Message), steg för publicering av ett ICEM

Meddelanden om isförhållanden är beroende av lokala observationer och utvärderingar och genereras vanligtvis av behörig personal.

Ett ICEM ska utfärdas vid förekomst av is. Förekomst av is begränsar inte nödvändigtvis sjöfarten, men information om isförhållanden som inte hindrar sjöfart kan tillhandahållas.

6.1. Måste information publiceras via ICEM till befälhavare? Det första ICEM-meddelandet för en sträcka ska endast publiceras vid förekomst av is på vattenvägen eller dess bifloder, även i fall där begränsningar saknas.

6.2. Finns det redan ett giltigt ICEM för den aktuella sträckan på vattenvägen?

6.2.1. Ja: Om ett meddelande för den aktuella sträckan (fortfarande) är giltigt ska det befintliga meddelandet uppdateras. Det är möjligt att uppdatera befintliga meddelanden om isförhållanden även om det aktuella området förändras (t.ex. om isen expanderar och det aktuella området blir större).

6.2.2. Nej: Om det inte finns något tillgängligt giltigt ICEM-meddelande för den aktuella sträckan ska ett nytt meddelande skapas.

6.3. Information om isförhållanden som inte hindrar sjöfart kan också tillhandahållas.

6.4. Ett ICEM är alltid giltigt för en enda sträcka på vattenvägen. Geografiskt giltighetsområde måste anges genom definition av vattenväg och respektive start- och slut(hektometer)punkt (eller genom val av vissa på varandra följande delar, beroende på nationell implementering).

6.5. Tiden för mätningen ska anges. Respektive isförhållanden ska anges genom användning av minst en av kodlistorna (beroende på nationella krav).

6.5.1. Ice_condition_code

6.5.2. Ice_accessibility_code

6.5.3. Ice_classification_code

6.5.4. Ice_situation_code (ska alltid anges för att möjliggöra visning av isförhållandena på en karta med ”trafikljus”-färger).

6.6. ICEM-meddelandet kan publiceras. Meddelanden om isförhållanden blir automatiskt giltiga fram till nästa dag efter publicering eller så bestäms giltighetstiden enligt nationella förfaranden.

7. Grundläggande överväganden för meddelande om väder (WERM, Weather Related Message)

Med tanke på överflödet av tillgängliga webbtjänster och appar för väderprognoser och vädervarningar bör WERM endast användas för väderinformation av särskild betydelse för sjöfart som inte omfattas av allmänna väderinformationstjänster.

Meddelanden om väder ska som regel genereras automatiskt. När detta inte är möjligt ska manuell generering av WERM-meddelanden följa de angivna processerna för automatiskt genererade meddelanden (se Kodning av meddelanden till befälhavare – vägledning för tillämpningsutvecklare) så noggrant som möjligt.

8. Regler för särskilda element

8.1. Regler för elementet ”name” för objekt

Objektnamn fylls vanligtvis i på förhand av redigeringsverktyget för ”meddelanden till befälhavare” baserat på referensdata i RIS Index. Namn ska anges på lokala språk, dvs. även diakritiska tecken eller kyrilliska bokstäver kan användas (t.ex. Baarlerbrücke, Volkeraksluis, Mannswörth).

Information om objektets egenskaper ska inte tas med. Typen av objekt ska inte upprepas i namnet såvida inte ytterligare information om objekttypen anges.

Ex.: Slussen ”Schleuse Freudenau” ska endast kallas ”Freudenau”, objekttypen ”sluss” läggs till automatiskt baserat på type_code.

Ex.: Objektnamnet för järnvägsbron i Krems (AT) är ”Eisenbahnbrücke Krems”. Informationen ”järnvägsbro” är inkluderad i objektnamnet eftersom den lägger till information utöver type_code ”bro”.

Ex.: Objektnamnet för en bro i Linz (AT) är ”Nibelungenbrücke”. Ordet ”brücke” förblir inom objektnamnet eftersom det är en del av själva bronamnet.

Ex.: Vattenståndsmätaren ”Pegelstelle Wildungsmauer” kallas ”Wildungsmauer” eftersom informationen som anger att objektet är en mätare redan är kodad i Type_code.

Om ett vattenvägsavsnitt utgör gränsen mellan två länder med olika språk kan det nationella objektnamnet anges på båda språk (t.ex. ”Staatsgrenze AT-SK/Statna hranica AT-SK”).

8.2. Regler för elementet ”name” för farleder

Namn på farleder fylls vanligtvis i på förhand av redigeringsverktyget för ”meddelanden till befälhavare” baserat på referensdata i RIS Index. Fältet ”name” ska innehålla det lokala namnet för respektive farledsavsnitt (t.ex. ”Rhein”). Beroende på nationella processer kan det vara möjligt att redigera namnet på farleden för att inkludera vanliga lokala namn eller tillägg (t.ex. ”Rhein am Deutschen Eck”).

8.3. Regler för elementen ”value” och ”unit” inom gränserna

Om inget annat anges får endast enheterna cm, m3/s, h, km/tim, kW, m/s (vind), mm/h (regn) och grader Celsius användas som enheter inom ”meddelanden till befälhavare”.

B. KODNING AV MEDDELANDEN TILL BEFÄLHAVARE – VÄGLEDNING FÖR TILLÄMPNINGSUTVECKLARE

1. Bakgrund och struktur

”Meddelanden till befälhavare” implementerades i flera europeiska länder baserat på kommissionens förordning (EG) nr 416/2007 om tekniska specifikationer för de ”meddelanden till befälhavare” som avses i artikel 5 i Europaparlamentets och rådets direktiv 2005/44/EG om harmoniserade flodinformationstjänster (RIS) på inre vattenvägar i gemenskapen. Standarden för ”meddelanden till befälhavare” utvecklas fortlöpande, och utrullningen av webbtjänsten för meddelanden, såväl som XSD 4.0 för meddelanden för befälhavare, var ett stort steg framåt. Tjänsten underlättar utbyte av ”meddelanden till befälhavare” mellan olika myndigheter och mellan myndigheter och mottagare av ”meddelanden till befälhavare”.

1.1. Syfte för vägledning för kodning av ”meddelanden till befälhavare”

Vägledningen för kodning av ”meddelanden till befälhavare” förklarar hur de fyra olika typerna av ”meddelanden till befälhavare” ska användas och förklarar koderna som ska användas i vissa situationer. Den tillhandahåller utförliga instruktioner till redaktörer och möjliggör nationellt och internationellt harmoniserade koder för ”meddelanden till befälhavare”.

Med beaktande av den ökade användningen av webbtjänsten för meddelanden ska meddelandena harmoniseras ytterligare för att säkra korrekt visning av innehållet i tredje parts system. Enhetlig kodning av meddelanden är också en förutsättning för användning av meddelande i tillämpningar för ruttplanering. Vägledningen för kodning av ”meddelanden till befälhavare” version 1.0 gäller för XSD 4.0 och webbtjänsten WSDL 2.0.4.0.

1.1.1. Kodning av meddelanden till befälhavare – vägledning för redaktörer

Denna vägledning är avsedd för personer som redigerar och publicerar ”meddelanden till befälhavare” och omfattar stegvisa instruktioner för hur man skapar rätt typ av meddelande och förklaring av koderna. Vägledningen för kodning av ”meddelanden till befälhavare” för redaktörer innehåller även relevant information för tillämpningsutvecklare.

1.1.2. Kodning av meddelanden till befälhavare – vägledning för tillämpningsutvecklare (detta dokument)

Denna vägledning omfattar riktlinjer för utveckling och implementering av tillämpningar för ”meddelanden till befälhavare” och förklarar bakomliggande logik, processer och automatiska värden/standardvärden.

2. ”Meddelanden till befälhavare” och avsnitt

Ett ”meddelande till befälhavare” består av följande:

Identifieringsavsnitt.

Avsnitt som definierar de aktuella objekt eller farledsavsnitt som meddelandet avser.

Ett eller fler av följande avsnitt enligt meddelandetyp:

Begränsning(ar) för meddelande om farled och trafik.

Mätning(ar) för meddelande om vatten.

Isförhållande(n) för meddelande om is.

Väderleksrapport(er) för meddelande om väder.

Figur 2 Visualisering av strukturen för ”meddelanden till befälhavare”: obligatoriskt element (1); obligatoriskt element som kan förekomma en eller två gånger (1…2); obligatoriskt element måste förekomma två gånger (2); obligatoriskt element som kan förekomma så mycket som behövs (1-n); frivilligt element som kan förekomma så mycket som behövs (0…n)

Identifieringsavsnittet är obligatoriskt och innefattar allmän information om meddelandets uppgiftslämnare, avsändare, datum för utfärdande, land och originalspråk och tillhandahålls tillsammans med ett av de fyra olika avsnittstyperna för ”meddelanden till befälhavare”:

Avsnitt om farled och trafik: ett meddelande om farled och trafik (FTM) skapas vanligtvis av redaktörer av ”meddelanden till befälhavare” som följer Kodning av meddelanden till befälhavare – vägledning för redaktörer. Avsnittet är kopplat till sträckor på vattenvägar definierade av ISRS-identifieringskoder för början och slut och/eller objekt på vattenvägen definierade av deras respektive identifieringskoder. [gå till kapitel 6]

Avsnitt om vattennivå: ett meddelande om vatten (WRM) underlättar förmedling om information om aktuella och prognostiserade vattennivåer samt annan information. Vanligtvis skapas WRM automatiskt (och periodiskt) baserat på sensormätningar av infrastrukturstatus som inte kräver åtgärd av en redaktör. Avsnittet om vatten innehåller information om ett objekt (t.ex. en mätstation) eller ett farledsavsnitt (t.ex. det minsta lodade djupet för en sträcka eller tillämpliga bestämmelser för ett vattenvägsavsnitt). Objektet definieras med dess ISRS-identifieringskod och farledsavsnittet definieras med ISRS-identifieringskoder för avsnittets början och slut. [gå till kapitel 3]

Avsnitt om is: ett meddelande om is (ICEM) innehåller information om isförhållanden för en sträcka på en farled som definieras med ISRS-identifieringskoder för dess början och slut. [gå till kapitel 4]

Avsnitt om väder: ett meddelande om väder (WERM) förmedlar information om aktuellt och prognostiserat väder för en sträcka på en vattenväg som definieras med ISRS-identifieringskoder för dess början och slut. [gå till kapitel 5]

ISRS-identifieringskoden (International Ship Reporting Standard) används dessutom för att definiera aktuella objekt eller farledsavsnitt som meddelandet avser.

Identifieringskoden definieras i punkt 4.3 av bilagan till denna förordning.

3. Grundläggande överväganden för meddelande om vatten (WRM, Water Related Message)

Information om vattennivå är mycket viktig för såväl ruttplanering som säkerhet. Det finns för närvarande ingen gemensam standard för hänvisningar till vattennivå. Värden för vattennivå anges med hänvisning till olika havsnivåer eller särskilda referenspunkter. För att tillhandahålla en korrekt referens ska respektive Reference_code alltid tillhandahållas tillsammans med värdet. WRM kan användas för följande information:

Vattennivå (inklusive prognoser).

Minsta lodade djup (inklusive prognoser).

Frihöjd (inklusive prognoser).

Utsläpp (inklusive prognoser).

Fördämningsstatus.

Ordning.

Clarifications for translations in the spreadsheet ”reference_code” tillhandahålls i kapitel 7.11.

WRM skapas och publiceras vanligen automatiskt baserat på information från sensorutrustning, eller information från infrastruktur (t.ex. prognoser, fördämningsstatus). WRM-meddelanden kan publiceras av olika anledningar. Det kan handla om periodiska publiceringar eller att ett visst värde nås.

3.1. Angivelse av avsnittet nts_number i WRM

I XSD 4.0 för ”meddelanden till befälhavare” är meddelandenumret inte obligatoriskt för WRM. Om meddelandenumret anges måste varje nummer vara unikt (organisation/år/nummer/serie) för meddelandetypen, och det är upp till organisationen som skickar ut WRM-meddelandet att se till att numret är unikt (på varandra följande nummer krävs inte).

3.2. Innehåll i WRM inklusive prognoser

Startdatum för giltighetsperiod (date_start resp. validity_period) måste anges med aktuellt datum (date_issue) och slutdatum (date_end) för giltighetsperiod ska anges som dagen efter datumet i date_issue.

För förmedling av t.ex. information om vattennivåer på ett användarvänligt sätt kan skillnaden i förhållande till en tidigare jämförande mätning anges i WRM-meddelandets avsnitt ”Skillnad”. Utöver värdeskillnaden (t.ex. - 5 [cm]) måste även tidsskillnaden i förhållande till den jämförande mätningen anges.

När det gäller prognoser är ”measure_date” det datum/den tid prognosen gäller för.

Prognoser om vattennivåer är aldrig helt säkra. Vanligtvis används modeller med olika parametrar (t.ex. väderprognoser) för att göra beräkningar vilket leder till varierande prognoser för vattennivåvärden. För tillhandahållande av minsta och största prognostiserade värde, t.ex. visualisering av konfidensintervall för vattennivåprognoser, finns två ytterligare datafält i WRM-meddelandets avsnitt om mätningar.

Följande figur är en illustration av konfidensintervall för vattennivåprognoser:

Figur 3 Visualisering av konfidensintervall för vattennivåprognoser: mest sannolika värde (svart); övre gräns för konfidensintervall (lila); nedre gräns för konfidensintervall (röd) (x-axeln visar tid, y-axeln visar vattennivå i cm)

I XSD-schemat för ”meddelanden till befälhavare” finns två element:

<value_min>) Lägsta värde för konfidensintervall.

<value_max>) Högsta värde för konfidensintervall.

Utöver prognostiserade vattennivåer kan konfidensintervallet också användas för att ange osäkerheten för ett publicerat minsta lodade djup och information om frihöjd.

Med konfidensintervallets value_min och value_max kan värdekonfidensintervall för WRM-värden anges via standardiserade WRM till befälhavare för användning i diagram Själva rådatan ska inte visas för IWT-användare (t.ex. i kodformat).

Mätkoden (measure_code) ”NOM” får inte användas. Om det inte finns några mätningar för en viss typ av WRM, men ett meddelande ändå ska skickas, ska värdeelementen utelämnas.

4. ICEM-processer

Meddelanden om isförhållanden är beroende av lokala observationer och utvärderingar och skapas vanligtvis manuellt (för automatiskt genererade meddelanden måste reglerna för manuellt skapade meddelanden följas, se Kodning av meddelanden till befälhavare – vägledning för redaktörer).

ICEM publiceras för ett visst farledsavsnitt (fairway_section) vars start- och slutpunkt definieras av ISRS-identifieringskoder och innehåller information om isförhållanden (ice_condition) från ett visst mätningsdatum.

Giltighetsperioden för ICEM-meddelandet startar vid publiceringsdatumet (anges automatiskt av tillämpningen för ”meddelanden till befälhavare”). För att undvika att ICEM som inte längre är giltiga visas för användare måste slutdatumet för giltighetsperioden (date_end) anges automatiskt som dagen efter publiceringen av tillämpningen för ”meddelanden till befälhavare” (om det inte finns nationella processer som säkrar att meddelanden får ett slutdatum för giltighet så snart informationen i meddelandet inte längre är aktuell).

I vägledningen för kodning av ”meddelanden till befälhavare” för redaktörer beskrivs under vilka förhållanden en redaktör skapar ett nytt ICEM eller uppdaterar ett befintligt ICEM. Följande processer ska användas:

4.1. Nytt ICEM

1) Tillämpningar för ”meddelanden till befälhavare” kan erbjuda redaktörer att använda

a) befintliga meddelanden som utkast för att skapa ett nytt ICEM (t.ex. om isförhållandena liknar dem i det befintliga meddelandet) och/eller

b) meddelandemallar för vissa situationer.

2) Innehållet (t.ex. tiden för mätningen eller respektive isförhållanden) måste anges av redaktören i enlighet med kapitel 6 i Kodning av meddelanden till befälhavare – vägledning för redaktörer. Datum och tid för mätningen kan också anges av tillämpningen enligt nationella definitioner.

3) När en redaktör/utgivare av ”meddelanden till befälhavare” startar publiceringsprocessen

a) kontrolleras det om allt obligatoriskt innehåll tillhandahålls i enlighet med XSD-schemat för ”meddelanden till befälhavare” (om inte, gå tillbaka till (2)),

b) genereras nts_number av tillämpningen för ”meddelanden till befälhavare”,

i) ”organisation” fylls i med namn eller kod för den ansvariga organisationen beroende på avsändarens roll,

ii) ”year” fylls i med aktuellt år,

iii) nästa tillgängliga ”number” tilldelas,

iv) ”serial number” 0 tilldelas.

c) fylls ”date_issue” automatiskt i med aktuellt datum för publiceringen,

d) fylls ”validity_period” – ”date_start” automatiskt i med aktuellt datum för publiceringen,

e) fylls ”validity_period” – ”date_end” automatiskt i som dagen efter publiceringen av meddelandet (om det inte finns nationella processer som säkrar att meddelanden får ett slutdatum för giltighet så snart informationen i meddelandet inte längre är aktuellt).

4.2. Uppdatering av ett befintligt ICEM

1) Respektive publicerat meddelande måste väljas för uppdatering i ICEM-redigeringsverktyget. Det ursprungliga ICEM-meddelandet måste kopieras eller ändras i databasen (beroende på nationella processer). Utgångna ICEM (som passerat datumet i validity_date_end) går inte att uppdatera. Om meddelandena är ogiltiga måste redaktörer av ”meddelanden till befälhavare” skapa ett nytt ICEM.

2) Innehållet (t.ex. tiden för mätningen eller respektive isförhållanden) måste ändras av redaktören i enlighet med kapitel 6 i Kodning av meddelanden till befälhavare – vägledning för redaktörer. Datum och tid för mätningen kan också ändras av tillämpningen enligt nationella definitioner.

3) När en redaktör/utgivare av ”meddelanden till befälhavare” startar publiceringsprocessen

a) kontrolleras det om allt obligatoriskt innehåll tillhandahålls i enlighet med XSD-schemat för ”meddelanden till befälhavare” (om något saknas, gå tillbaka till (2)),

b) genereras nts_number av tillämpningen för ”meddelanden till befälhavare”,

i) ”organisation” ändras inte,

ii) ”year” ändras inte,

iii) ”number” ändras inte,

iv) ”serial number” ökas (med 1),

c) fylls ”date issue” automatiskt i med aktuellt datum för publiceringen,

d) fylls ”validity_period” – ”date_start” automatiskt i med aktuellt datum för publiceringen,

e) fylls ”validity_period” – ”date_end” automatiskt i som dagen efter publiceringen av meddelandet (om det inte finns nationella processer som säkrar att meddelanden får ett slutdatum för giltighet så snart informationen i meddelandet inte längre är aktuellt).

5. Grundläggande överväganden för meddelande om väder (WERM, Weather Related Message)

WERM skapas och publiceras vanligen automatiskt baserat på information från sensorutrustning, eller information från infrastruktur. Startdatum för giltighetsperiod (date_start resp. validity_period) måste anges med aktuellt datum (date_issue) och slutdatum (date_end) för giltighetsperiod ska anges som dagen efter datumet i date_issue.

Farledsavsnittet i WERM-meddelandet indikeras som en sträcka mellan två punkter på farleden, dvs. mätområdet för väderstationen (mätaren).

Datum och tid för mätningen/prognosen måste anges även om det inte är obligatoriskt i WERM.

När det gäller prognoser är ”measure date” det datum/den tid prognosen gäller för.

5.1. Angivelse av avsnittet nts_number i WERM

I XSD 4.0 för ”meddelanden till befälhavare” är meddelandenumret inte obligatoriskt för WERM. Om meddelandenumret anges måste varje nummer vara unikt (organisation/år/nummer/serie) för meddelandetypen, och det är upp till organisationen som skickar ut WERM att se till att numret är unikt (på varandra följande nummer krävs inte).

5.2. Angivelse av ”weather_category_code” i WERM

Vindhastigheten i ”weather_category_code” (värde mellan 0 och 12) ska anges i enlighet med Beaufort-skalan som beskrivs av World Meteorological Organization i Manual on Marine Meteorological Services ”WMO-No. 558”.

Siktvärdet i ”weather_category_code” (värde mellan 13 och 22) ska anges enligt definitionen i följande tabell:

6. FTM-processer

I Kodning av meddelanden till befälhavare – vägledning för redaktörer beskrivs under vilka förhållanden en redaktör skapar ett nytt FTM eller uppdaterar ett befintligt FTM. Följande processer ska användas:

6.1. Nytt FTM

1) Tillämpningar för ”meddelanden till befälhavare” kan erbjuda redaktörer att använda

a) befintliga meddelanden som utkast för att skapa ett nytt FTM och/eller

b) meddelandemallar för vissa situationer.

2) Innehållet (t.ex. giltighetstid, begränsningar) måste anges av redaktören i enlighet med kapitel 3 och 4 i Kodning av meddelanden till befälhavare – vägledning för redaktörer.

3) När en redaktör/utgivare av ”meddelanden till befälhavare” startar publiceringsprocessen

a) kontrolleras det om allt obligatoriskt innehåll tillhandahålls i enlighet med XSD-schemat för ”meddelanden till befälhavare” (om något saknas, gå tillbaka till (2)),

b) genereras nts_number av tillämpningen för ”meddelanden till befälhavare”,

i) ”organisation” fylls i med namn eller kod för den ansvariga organisationen beroende på avsändarens roll,

ii) ”year” fylls i med aktuellt år,

iii) nästa tillgängliga ”number” tilldelas, om ett dedikerat nummer angivits av redaktören eller om en tillämpningsprocess i steg 2 tas över (givet att informationen i Organisation/Year/Number/Serial är unik i enlighet med kapitel 15.1),

iv) ”serial number” 0 tilldelas.

c) fylls ”date issue” automatiskt i med aktuellt datum för publiceringen.

6.2. Uppdatering/indragande av ett befintligt FTM

1) Respektive publicerat meddelande måste väljas för uppdatering i FTM-redigeringsverktyget. Det ursprungliga FTM-meddelandet måste kopieras eller ändras i databasen (beroende på nationella processer).

a) Utgångna FTM (som passerat datumet i validity_date_end) går inte att uppdatera. Om meddelandena är ogiltiga måste redaktörer av ”meddelanden till befälhavare” skapa ett nytt FTM.

b) Ämneskoden ”Indraget meddelande” används endast i följande fall:

i) Aktuellt datum är tidigare än giltighetsperiodens startdatum (validity_date_start). I sådant fall kan innehållet i fältet ”annan information på nationellt språk” ändras, men kodat innehåll i meddelandet (steg 2) får inte ändras.

ii) Giltighetsperioden har redan börjat och de nya slutdatumen för alla begränsningar är satta till ett datum som passerats. Slutdatum för giltighetsperioden måste sättas till ett korrekt datum.

c) Om ett meddelande dras tillbaka måste slutdatum för giltighetsperioden sättas till det datum då meddelandet dras tillbaka.

2) Innehållet (t.ex. giltighetstid, begränsningar) måste ändras av redaktören i enlighet med kapitel 3 och 4 i Kodning av meddelanden till befälhavare – vägledning för redaktörer.

3) När en redaktör/utgivare av ”meddelanden till befälhavare” startar publiceringsprocessen

a) kontrolleras det om allt obligatoriskt innehåll tillhandahålls i enlighet med XSD-schemat för ”meddelanden till befälhavare” (om något saknas, gå tillbaka till (2)),

b) genereras nts_number av tillämpningen för ”meddelanden till befälhavare”,

i) ”organisation” ändras inte,

ii) ”year” ändras inte,

iii) ”number” ändras inte,

iv) ”serial number” ökas (med 1),

c) fylls ”date issue” automatiskt i med aktuellt datum för publiceringen,

d) FTM med ämneskod ”Indraget meddelande” ska inte (längre) beaktas för ruttplanering.

6.3. FTM för vattenväg och/eller objekt

Ett FTM för vattenväg innehåller information om en eller flera sträckor på en vattenväg. En sträcka på en vattenväg definieras i avsnittet ”fairway_section” med dess ISRS-identifieringskoder för start- och slutpunkt.

Ett FTM för objekt innehåller information om ett eller flera specifika objekt på en vattenväg. Ett objekt definieras i ”object” med dess identifieringskod.

Ett FTM måste hänvisa till

en eller flera farledsavsnitt, eller

en eller flera objekt eller en eller flera farledsavsnitt.

6.4. Automatisk sortering av begränsningskoder

Olika begränsningar har olika påverkan på sjöfarten. För att möjliggöra visning av den viktigaste begränsningen, t.ex. i en översikt i en FTM-lista, ska följande ordning beaktas. Den viktigaste begränsningen, ”Grad 1”, inleder listan.

6.5. Hantering av begränsningsperiod

Begränsningar med samma begränsningsperioder bör grupperas tillsammans/listas tillsammans/kombineras för visning för att öka användarvänligheten.

Redigeringsverktyg för ”meddelanden till befälhavare” bör ha en funktion som gör att redaktörer inte behöver ange begränsningsperioder flera gånger.

Alla begränsningar måste inkludera en begränsningsperiod med en intervallkod för att möjliggöra korrekta beräkningar i tillämpningar för ruttplanering. För att underlätta arbetet för redaktörerna kan följande funktioner implementeras:

Redigeringsverktyget för ”meddelanden till befälhavare” kan ha en funktion för att kopiera redan angivna begränsningar, så att redaktörerna inte behöver ange begränsningsperioder flera gånger.

Redigeringsverktygen för ”meddelanden till befälhavare” kan ha en funktion för val av mer än en begränsningskod för en specifik begränsningsperiod och automatiskt skapa de begränsningsavsnitt som krävs, baserat på informationen som anges i redigeringsverktyget.

”Måndag till fredag, utom allmänna helgdagar”: Värdet ”helgdagar” är svårhanterligt för ruttplaneringstillämpningar. En lista med helgdagar för varje enskilt land behövs för korrekta beräkningar. Om ingen sådan lista är tillgänglig kommer de respektive begränsningarna ändå att tilldelas helgdagar.

”Med undantag av” ska ej användas: avbrutna intervall måste anges som separata begränsningsperioder inom samma begränsning, därför ska denna kod inte visas/vara tillgänglig för redaktörer.

Logisk struktur och visning av tillämplig information för intervallkoden ”Fortlöpande”: <date_start>2015-04-01+01</date_start> <date_end>2015-06-30+02</date_end> <time_start>06:00:00</time_start> <time_end>10:00:00</time_end> <interval_code>CON</interval_code> Om interval_code är satt till ”Fortlöpande” hör start_time till start_date och end_time hör till end_date, t.ex. från 1 april kl. 06.00 till 30 juni kl. 10.00.

Logisk struktur och visning av tillämplig information för någon annan interval_code än ”Fortlöpande”: <date_start>2015-04-01+01</date_start> <date_end>2015-06-30+02</date_end> <time_start>06:00:00</time_start> <time_end>10:00:00</time_end> <interval_code>WRK</interval_code> Om interval_code har ett annat värde så tillhör start_time och end_time denna interval_code, t.ex. från 1 april till 30 juni måndag till fredag från kl. 06.00 till 10.00.

Begränsningstidens slutpunkt måste anges i den senaste versionen av aktuellt meddelande.

7. Allmänna regler för implementering

Följande ska beaktas:

Tabellen ”GUI_labels” i referenstabellerna för ”meddelanden till befälhavare” ska beaktas i utvecklingen av tillämpningar för ”meddelanden till befälhavare” (sökmasker, formulär för e-postprenumeration, visning av meddelanden).

date_end kan inte sättas till ett tidigare datum än date_start.

Koder som inaktiverats (som inte längre ska användas) via förfrågan om ändring av ”meddelanden till befälhavare” (se kommentarer i XSD-schemat för ”meddelanden till befälhavare”) ska inte visas för redaktörer vid skapande av nya meddelanden. Koderna är fortfarande en del av uppräkningarna i XSD-schemat för ”meddelanden till befälhavare”, för att uppnå bakåtkompatibilitet.

7.1. Angivelse av ”number_section”

Varje nummer (organisation/år/nummer/serie) måste vara unikt för meddelandetypen. Det betyder att olika meddelandetyper kan ha samma nummer.

För användare är meddelandenas nummer endast relevanta för FTM och ICEM. För alla andra meddelandetyper går det att hoppa över visningen av meddelandets nummer, beroende på nationella krav.

För användare ska meddelandenumret visas i följande format ”Meddelandetyp/Land/Organisation/År/Nummer/Serie” (kan förkortas beroende på använda filter om ingen information förloras).

7.2. Inmatning av element ”from”, ”originator”, ”organisation” och ”source”

Elementet ”from” i identifieringsavsnittet ska bestå av namnet på det nationella system som tillhandahåller meddelandet (t.ex. ELWIS, DoRIS, SLOVRIS, FLARIS).

Elementet ”originator” är den uppgiftslämnande organisation som för in meddelandena i nationella system.

Elementet ”source” är myndigheten (källan) för vars räkning FTM-meddelandet publiceras.

Elementet ”organisation” i avsnittet nts_number är namnet på den organisation som anger meddelandets nummer (nts_number) (leverantör av ”meddelanden till befälhavare”).

7.3. Utelämning av element

Element som endast innehåller standardvärden ska utelämnas om de är villkorliga eftersom de leder till ökad administration av betydelselös information.

Det gäller följande element:

Målgrupp: target_group_code ALL med direction_code ALL (om det inte finns några andra specifika målgrupper i meddelandet).

Position_code: AL.

Reason_code: OTHER.

7.4. Automatisk inmatning av date_issue

FTM och ICEM

För FTM och ICEM är värdet för elementet date_issue aktuellt datum och tid för publiceringen. När det gäller uppdaterade meddelanden är date_issue datum och tid när uppdateringen publicerades.

WRM och WERM

För WRM och WERM är värdet för elementet date_issue datum och tid för begäran om hantering eftersom det kan finnas flera mätningar med olika tidsstämplar för utfärdande i ett och samma WRM/WERM.

7.5. Hantering av information om tidszoner i ”meddelanden till befälhavare”

Datum och tid ska alltid anges i lokal tid, inklusive information om tidszon i XML-meddelandena till befälhavare.

De enda undantagen från denna regel är ”time_start” och ”time_end” i avsnittet ”limitation_period”. Det beror på att ett intervall kan appliceras i begränsningsavsnittet. Om start- och slutdatum anges i olika tidszoner (t.ex. CEST och CET) leder det till en ändring av information om tidszoner inom detta intervall. Denna ändring kan inte uttryckas med en enda begränsningsperiod. Istället för att skapa olika begränsningsperioder för varje tidsförändring, kan endast en enda begränsningsperiod utan information om tidszoner användas för att minska administreringstiden för hantering och publicering av meddelanden.

7.6. Hantering av sekunder i ”meddelanden till befälhavare”

I regel måste sekunder anges i fälten för (datum)/tid men de ska inte visas för användare av ”meddelanden till befälhavare”. För ”meddelanden till befälhavare” är det tillräckligt specifikt att ange minuter.

7.7. Format för decimaler i ”meddelanden till befälhavare”

Decimaler i numeriska fält anges med punkt (.). Inga tusentalsavgränsare används.

Antalet decimaler som används för värden ska begränsas till ett lämpligt antal för att visningen ska vara användarvänlig.

7.8. Enheter som ska användas i ”meddelanden till befälhavare”

Om inget annat anges får endast enheterna cm, m3/s, h, km/tim, kW, m/s (vind), mm/h (regn) och grader Celsius användas som enheter i ”meddelanden till befälhavare”. I tillämpningar kan enheterna konverteras för att öka användarvänligheten.

Om de använda enheterna skiljer sig från de standardiserade enheterna måste de angivna värdena konverteras av tillämpningen i enlighet med detta.

7.9. Regler för elementen ”name”, ”position_code” och ”type_code”

Elementet ”name” ska matas in automatiskt från referensdata ”national object name” i RIS Index, (redaktörer kan redigera det automatiskt inmatade elementet om detta är ett nationellt krav). Namnkonventioner för objektnamn inkluderas i RIS Index Encoding Guide version 2.0 eller högre. Exempel på korrekta objektnamn anges också i Kodning av meddelanden till befälhavare – vägledning för redaktörer.

Typkoden läggs till objektet framför objektnamnet av tillämpningen för ”meddelanden till befälhavare”.

Objektens position kodas via positionskod och läggs till objektet av tillämpningen för ”meddelanden till befälhavare” från RIS Index. Redaktörer kan ändra den automatiskt inmatade typ- och positionskoden. En positionskod för objekt ska inte tillhandahållas för geo_objects i avsnittet fairway_section.

Ett komplett objektnamn består av positionskod, typkod och namn.

För att underlätta arbetet för redaktörerna kan följande kartläggningsfunktioner implementeras i redigeringsverktyg för ”meddelanden till befälhavare” för att hjälpa redaktörer att hitta/välja rätt objekt baserat på function_code i RIS Index eller type_code för ”meddelanden till befälhavare”:

Tabell 1 Matchning av ”function_code” i RIS Index och ”type_code” för meddelande till befälhavare

7.10. Regler för elementet ”fairway_name”

För att undvika behov av tillämpningslogik/korrekta referensdata i det mottagande systemet (programvaran som visar meddelandet för användaren) ska alltid det valfria elementet ”fairway_name” inkluderas i ”geo_object” och fyllas i automatiskt av tillämpningen för ”meddelanden till befälhavare” med ”Waterway name” från RIS Index. Redaktörer av ”meddelanden till befälhavare” ska inte ändra innehållet i elementet fairway_name.

7.11. Förtydligande för översättningar i kalkylbladet ”reference_code”

Följande definition ska användas för reference_code-värden i referenstabellerna för ”meddelanden till befälhavare”:

NAP: I Nederländerna används och förstås förkortningen NAP, NAP översätts inte

KP: ”channel level” ska översättas och visas på nationella språk

FZP: endast förkortningen ”FZP” ska användas (används numera sällan)

ADR: ”Adriatic Sea” (Adriatiska havet) ska översättas och visas på nationella språk

TAW/DNG: ”Tweede algemene waterpassing” (nederländska) – ”Deuzième Nivellement Général” (franska) är referenshöjden som används i Belgien för att uttrycka höjdmått. 0 är den genomsnittliga havsnivån vid lågvatten i Oostende

Nederländska: TAW

Franska: DNG

Alla övriga språk: TAW/DNG

LDC: ”Lågvattennivå enligt Donau-kommissionen” ska översättas och visas på nationella språk

HDC: ”Högvattennivå enligt Donau-kommissionen” ska översättas och visas på nationella språk

ETRS: ”European Terrestrial Reference System 1989” förkortningen ”ETRS89” används på alla språk

7.12. Rekommendation för elementet ”coordinate”

Elementkoordinaten i avsnittet för geografiska objekt är villkorlig, men geografiska koordinater ska anges i WGS84 i formatet [d]d mm.mmm[m] N (latitud) och [d][d]d mm.mmm[m] E (longitud). Detta görs för att ge ”meddelanden till befälhavare” en geografisk referens.

7.13. Hantering av målgrupper

Målgruppsavsnittet består av målgruppskoden (Target_group_code) och riktningskoden (Direction_code). Om båda koder har värdet ALL ska hela avsnittet utelämnas om det inte finns några andra specifika målgrupper inom meddelandet. Om bara en av dessa två koder anges måste standardvärdet ALL anges för den andra koden eftersom båda element är obligatoriska.

Ytterligare information om målgrupper kan hittas i Kodning av meddelanden till befälhavare – vägledning för redaktörer.

7.14. Visning av giltiga meddelande vid en given tid

Validity_period ska användas av tillämpningar för att välja meddelanden som ska visas för användare som begär information om en viss tidsperiod.

Om subject_code är INFSER (Informationstjänst) används giltighetsperioden för att specificera tiden som informationstjänstmeddelandet visas för användarna, inte giltighetsperioden för informationen (t.ex. 1 månad).

7.15. Tillvalsfunktioner för att underlätta användningen av redigeringsverktyg för ”meddelanden till befälhavare”

Följande funktioner kan vara tillgängliga för redaktörer av ”meddelanden till befälhavare” beroende på nationella krav:

Tillämpningar för ”meddelanden till befälhavare” kan ha funktioner för att spara utkast till meddelanden (allt obligatoriskt innehåll måste inte tillhandahållas för att det ska gå att spara utkast till meddelanden).

Redaktörerna kan ha olika användarroller (t.ex. redaktörer som har behörighet att skriva/ändra meddelanden, utgivare som har behörighet att publicera meddelanden (utöver redigering)).

8. XML-struktur i ”meddelanden till befälhavare”

XML-strukturen i ”meddelanden till befälhavare” samt innehållet och dataelementens syfte definieras och förklaras ytterligare i tillägg C: XML Schema Definition (XSD) för meddelanden.

9. Webbtjänst för meddelanden

9.1. Mål

Expertgruppen som arbetar med ”meddelanden till befälhavare” identifierade webbtjänsttekniken som ett lämpligt sätt att förmedla ”meddelanden till befälhavare”.

Detta kapitel utgör specifikationen för webbtjänsten för förmedling av ”meddelanden till befälhavare” som förkortas webbtjänst för meddelanden. Särskild vikt läggs vid användningen av väletablerade internationella standarder.

Ett av målen med designen av konceptet var att säkra en god balans mellan flexibilitet och pålitlighet för webbtjänsten. Filterparametrarna i förfrågningarna är i huvudsak de kriterier som specificeras i standarden för ”meddelanden till befälhavare” (vattenvägsavsnitt med valfri angivelse av flodsträcka i km, giltighetstid, publiceringsdatum för meddelandet). Detta verkar tillräckligt specifikt, med tanke på hur webbtjänsten ska användas, och samtidigt begränsar det tillämpningens komplexitet.

Det viktigaste resultatet är ett avtal för webbtjänsten, i vilket förfrågningar om information och svar specificeras. Webbtjänstkonsumenterna kan förlita sig på detta avtal och leverantörerna måste följa det. Avtalet specificeras med den internationella standarden WSDL.

Alla deltagande medlemsstater ska införa en eller flera webbtjänster för de olika meddelandetyperna (FTM, WRM, ICEM, WERM) och förmedla dem via internet (”Tjänst för meddelanden till befälhavare”).

De tekniska detaljerna för implementeringen av WS för ”meddelanden till befälhavare”, t.ex. valet av lämpliga datapooler, tillämpningar och plattformar, omfattas inte av denna specifikation. Varje enskild deltagande medlemsstat ansvarar för dessa detaljer.

För att definiera en säker kommunikation måste man beakta olika säkerhetsaspekter och syftet som ligger bakom. Beroende på omständigheterna måste inte alla dessa aspekter beaktas. Prioriteringen av de olika säkerhetsaspekterna och i vilken mån alla säkerhetskrav uppfylls kan variera. Genomförbarheten för en viss åtgärd kan begränsas av möjligheterna till det tekniska genomförandet. När det gäller ”meddelanden till befälhavare” är all information offentlig. Så det finns inget behov av dataskydd när det gäller ”meddelanden till befälhavare”. Därför måste varje leverantör själv bestämma hur långt denna aspekt ska genomföras i respektive tjänst.

9.2. Grundläggande principer och begränsningar

9.2.1. Webbstandarder

Webbtjänsten för meddelanden måste följa WS-I Basic Profile 1.1. Denna profil ”tillhandahåller vägledning för driftskompatibilitet för en grundläggande uppsättning generiska webbtjänstspecifikationer, såsom SOAP, WSDL och UDDI”. De mest relevanta standarderna häri är

XML Schema Definition (XSD),

Simple Object Access Protocol (SOAP),

Web Services Description Language (WSDL) och

Universal Description, Discovery and Integration (UDDI).

Svarsmeddelandet för webbtjänsten för meddelanden är ett ”meddelande till befälhavare” som definieras i XML Schema Definition (XSD) i tillägg C i denna förordning från kommissionen.

SOAP: är ett tillämpningsprotokoll för dataöverföring mellan IT-system som standardiseras av World Wide Web Consortiums (W3C). De specifika elementen för webbtjänsten för meddelanden definieras i motsvarande WSDL-specifikationer i tillägg D till denna förordning från kommissionen. Standardschemat för ”meddelanden till befälhavare” (XSD) medföljer med ett importmeddelande.

UDDI: (Universal Description, Discovery and Integration) beskrivs här som ett centralt, möjligtvis internationellt register över webbtjänster där webbtjänsten för meddelanden kan registreras. I detta register kan potentiella användare av webbtjänsten söka och hitta tjänsten. Men eftersom de potentiella leverantörerna av webbtjänsten för meddelanden begränsas av de deltagande medlemsstaterna och WSDL-specifikationen är en integrerad del av standarden är behovet av en oberoende registrering av webbtjänsten inte uppenbar.

9.2.2. Interaktionsmodell och kodningsmetod för webbtjänsten för meddelanden

Kodningsmetoden ”Document-literal wrapped” används för webbtjänsten för meddelanden eftersom den möjliggör validering mot ett XML-schema och namn på operationer som definieras i WSDL-specifikationen används direkt som namn på XML-taggar i SOAP-meddelandena.

9.3. Allmänna specifikationer och rekommendationer

9.3.1. Specifikation: versionsinformation

Versionsinformationen för webbtjänsten består av två avsnitt:

Versionen av själva webbtjänsten.

Versionen av schemat för meddelandena som används av webbtjänsten.

Avsnittet som handlar om webbtjänsten består av två delar:

(Ny) version med större ändringar av webbtjänsten.

(Ny) version med mindre ändringar av webbtjänsten.

En (ny) version med större ändringar anges som ett positivt heltalsvärde.

En (ny) version med mindre ändringar anges som ett icke-negativt heltalsvärde som visar att det är en mindre uppdatering inom den aktuella grundversionen.

Avsnittet för meddelandeschemat innehåller versionen av meddelandeschemat såsom detta definieras av expertgruppen för ”meddelanden till befälhavare”.

Versionen av webbtjänsten för meddelanden som specificeras här är 2.0.4.0, där 2.0 är versionen av själva webbtjänsten och 4.0 är versionen av det schema som används för meddelandena.

Utförlig versionsinformation behövs inte i förfrågningar och svar i webbtjänsten för meddelanden. Det finns bara ett fåtal versioner av tjänsterna som förväntas vara online samtidigt. Olika versioner ska anges med olika URL-adresser. Därför ska varje instans av en webbtjänst för meddelanden stödja en specifik version av webbtjänsten för meddelanden.

9.3.2. Specifikation: struktur för namnfält

Namnfälten i webbtjänsten för meddelanden är baserade på RIS-expertgruppernas webbdomän http://www.ris.eu/.

Namnfälten innehåller en partikel som indikerar motsvarande tjänst och versionsinformation. Tjänsten som specificeras här använder följande namnfält:

Webbtjänst för meddelanden: http://www.ris.eu/nts.ms/2.0.4.0

9.3.3. Rekommendation: användning av namnfält

För högre transparens i XML-dokument rekommenderas det att namnfält definieras i det lämpligaste elementet i schemana såväl som exempeldokumenten och att definitioner för lokala namnfält inte används i nästlade element.

9.3.4. Rekommendation: användning av namnfältsprefix

Förfrågningar och svar i webbtjänsten för meddelanden ska använda kvalificerade XML-element, dvs. element med ett tydligt namnfältsprefix, och okvalificerade XML-attribut, dvs. utan ett namnfältsprefix.

Det rekommenderas att intuitiva namnfältsprefix som ”nts” används för att öka läsbarheten.

9.3.5. Specifikation: användning av ISRS-identifieringskoder

ISRS-identifieringskoden samt kodningsguiden för RIS Index förklaras i kapitel 2 i Kodning av meddelanden till befälhavare – vägledning för tillämpningsutvecklare.

I förfrågningar till en webbtjänst för meddelanden kan användaren hänvisa till ett antal objekt, t.ex. farledsavsnitt, vattenståndsmätare och slussar. Om motsvarande parametrar (ID-element) används måste de innehålla identifieringskoder. Dessa parametrar ges vanligtvis i ID-element där varje parameter innehåller ett eller två ID:n.

Vid användning av dessa parametrar måste följande allmänna konventioner iakttas:

Identifieringskoder måste anges med hela koden, dvs. 20 tecken, och inga nollor får utelämnas.

Om två ID:n används i ett ID-element måste båda identifieringskoderna hänvisa till samma vattenväg. Det betyder att koderna innehåller vissa identiska siffror i avsnittet fairway_section i identifieringskoden. Koden för farledsavsnittet i kombination med farledshektometern definierar en sträcka på en vattenväg som tillhandahålls som två ID-element.

För sträckor på vattenvägar (ID-elementpar i avsnittet fairway_section geo_object) i ”meddelanden till befälhavare” måste följande beaktas med avseende på identifieringskoder:

Siffrorna 1–2 (landskod):

måste vara identiska inom ID- paret, men

olika landskoder kan definieras inom ett ID-par om angränsande länder använder samma kod för farledsavsnittet för en specifik vattenväg och samma system för definition av hektometrar.

Siffrorna 3–5 (FN:s lokaliseringskod):

är inte relevanta, kan ha innehåll som skiljer sig åt inom ID-paret.

Siffrorna 6–10 (kod för farledsavsnitt):

måste vara identiska inom ID-paret, men

[undantag]: vid användning av de belgiska identifieringskoderna i webbtjänsten för meddelanden ska man bara använda siffrorna 6–8 för att identifiera farledsavsnittet, eftersom ”meddelanden till befälhavare” kommer att publiceras i olika avsnitt i en farled.

Siffrorna 11 till 15 (referenskod för objekt):

är inte relevanta, kan ha innehåll som skiljer sig åt inom ID-paret.

Siffrorna 16–20 (farledshektometer):

består av fem olika siffror som definierar hektometern och kommer därför i normala fall att ha ett innehåll som skiljer sig inom ID-paret (exempel: ”00235” för farled km 23,5; ”00001” för farled km 0,1), men

[undantag]: för Nederländerna finns det inte alltid en direkt koppling mellan farledshektometern och den fysiska kilometern på farleden på grund av definitionen för början av sträckan på farleden i nätverksmodellen och i den fysiska världen. I sådana fall börjar objektreferenskoden för objekt av typen ”dismar” med Kxxxx (xxxx inkluderar den fysiska kilometern, t.ex. NLSVG00130K000300191 (km 3)). För andra typer av objekt finns ingen direkt relation till den fysiska farledens km i identifieringskoderna, t.ex. har Sas van Gent-bron på samma farled vid km 2,5 identifieringskod NLSVG001300521600186. För Gent-Terneuzenkanalen börjar den fysiska km 0.0 vid gränsen mellan Belgien och Nederländerna och farledshektometern 0.0 börjar vid kanalens början i Gent.

Om ett meddelande berör mer än ett vattenvägs- eller farledsavsnitt måste alla farledsavsnitt definieras med start- och slutpunkt i separata XML-element för ”fairway_section”.

För vissa länder/regioner krävs detta för att filtren ska fungera. Om t.ex. identifieringskod (1–2) är BE ska identifieringskod (6–8) användas som ID för linjär referens med farledshektometern (identifieringskod 16–20). Exempel för sträckor på farleder (giltiga ID-elementpar i avsnittet fairway_section) som inkluderar de undantag som definieras ovan:

De två identifieringskoderna är en giltig definition för en sträcka på en vattenväg (NL-undantag visas med hänsyn till farledskilometern): NLSVG00130K000300191 (km 3,0 vid Sas van Gent på Gent-Terneuzenkanalen) – NLWDP00130K000400200 (km 4,0 vid Westdorpe på Gent-Terneuzenkanalen).

De två BE-identifieringskoderna är en giltig definition för en sträcka på en vattenväg (BE-undantag visas med hänsyn till koden för farledsavsnittet (”020” Albertkanaal)): BEGNK02016L010100414 (slussen vid Genk är lokaliserad vid km 41,4 på Albertkanaal) – BEOSH02033L010500772 (slussen vid Ham är lokaliserad vid km 77,2 på Albertkanaal).

Följande figur visar motexempel på identifieringskod som används för varje allmän konvention (inga undantag för de allmänna konventioner som gäller för SK-sträckor på vattenvägar):

Ogiltiga förfrågningar om ISRS-identifieringskoder

Allmän anmärkning: En tjänst för förfrågningar om giltiga identifieringskoder stöds inte av webbtjänsten för meddelanden. Identifieringskoder tillhandahålls inom ERDMS (European Reference Data Management System).

Den korrekta användningen av identifieringskoder i förfrågningarna och deras tolkning ges i följande fem fall.

Fall 1: Inga ID-element i förfrågan

ID-element är en valfri del av förfrågan, dvs. att en förfrågan utan några ID-element är tillåten:

Giltig förfrågan utan ID-parameter

Om inga ID-element ges ska alla meddelanden returneras (naturligtvis beroende på andra filterkriterier som validity_period eller dates_issue).

Fall 2: Ett ID-element i förfrågan

Varje ID-element kan innehålla ett eller två ID-element. Ett fall med ett ID-element visas i följande figur:

Giltig förfrågan med en ID-parameter

Om en sådan förfrågan tas emot ska servern returnera alla matchande meddelanden med starthektometer ≤ det givna värdet (240,7 i exemplet) och sluthektometer ≥ detta värde. Figuren nedan visar detta urval av meddelanden: Den begärda positionen är placerad mellan start- och sluthektometervärdena för meddelandena 1, 3 och 4 som skulle returneras. Meddelandena 2, 5 och 6 överlappar inte den begärda positionen, så de skulle inte returneras.

Om den angivna identifieringskoden gäller ett enskilt objekt, t.ex. en vattenståndsmätare eller en sluss, ska webbtjänsten returnera meddelandena som innehåller detta objekt.

Matchande och icke matchande meddelanden för en ID-parameter Fall 3: Två ID-element i förfrågan

Varje ID-element kan innehålla ett eller två ID-element. Ett fall med två ID-element visas i följande figur:

Giltig förfrågan med två ID-parametrar

Alla begärda hektometervärden ska behandlas som att de är giltiga, även om det motsvarande farledsavsnittet har olika start- och slutpunkter. Om farledsavsnittet t.ex. börjar vid hektometer 100,0 och slutar vid hektometer 300,0 skulle en förfrågan för hektometrar 20,0 till 400,0 vara giltig. Internt görs förstås en sökning av farledsavsnittets ”verkliga” omfattning.

Detta gör det möjligt att söka efter alla meddelanden om en farled utan att dess exakta hektometersträcka är känd (användaren skulle söka identifieringskod med hektometervärden satta till ”00000” respektive ”99999”).

Alla matchande meddelanden som faller inom det givna hektometerintervallet ska returneras. Följande diagram illustrerar denna situation:

Matchande och icke matchande meddelanden för två ID-parametrar

Figuren ovan visar hur ”faller inom intervallet” definieras. Medan meddelandena 1 till 4 överlappar varandra med rätt grad av det önskade hektometerintervallet (delvis eller helt), gör meddelandena 5 och 6 inte det, därför returneras meddelandena 1 till 4, och 5 och 6 kommer inte att returneras.

Det tekniska villkoret för att ett meddelande ska falla inom ett intervall [A, B] är: Starthektometern för meddelandet är ≤ B och dess sluthektometer är ≥ A.

Kombination: Flera ID-element i förfrågan

Giltig förfrågan med flera ID-element

Kombinationen av flera ID-element i förfrågan leder till att motsvarande meddelanden samordnas. Alla ID-element behandlas individuellt och ett meddelande kommer att returneras, om det matchar minst ett av elementen. Därför returneras följande meddelanden för det givna exemplet:

Alla meddelanden för objektet med identifieringskod SKXXX0000010000***** med starthektometer = 0 och sluthektometer ≥ 0 (se fall 2).

Alla meddelanden för objektet med identifieringskod SKXXX0000500000***** som faller inom hektometerintervallet [11,0, 15,0] (se fall 3).

Alla meddelanden för objektet med identifieringskod SKXXX0000200000***** med starthektometer ≤ 110,5 och sluthektometer ≥ 110,5 (se fall 2).

Alla meddelanden för objektet med identifieringskod SKXXX0000500000***** som faller inom hektometerintervallet [220,0, 300,0] (se fall 3).

9.4. Tjänst för ”meddelanden till befälhavare” (specifikation för implementering)

I detta kapitel beskrivs specifikationen för implementering av tjänsten för ”meddelanden till befälhavare” som är ett resultat av övervägandena och valen i de föregående kapitlen.

Tjänsten för ”meddelanden till befälhavare” tillhandahåller de fyra typerna av ”meddelanden till befälhavare”:

1) FTM – meddelande om farled och trafik.

2) WRM – meddelande om vatten.

3) ICEM – meddelande om is.

4) WERM – meddelande om väder.

En implementering av tjänsten för ”meddelanden till befälhavare” kan stödja alla meddelandetyper eller endast ett urval. En deltagande medlemsstat kan erbjuda flera tjänster för en specifik meddelandetyp, om dessa är kompletterande tjänster.

9.4.1. Förfrågan

För att tjänsten ska vara så driftsäker och okomplicerad som möjligt används inget ytterligare frågespråk i webbtjänsten för meddelanden. Istället används konstruktionerna som tillhandahålls av WDSL. De specifika operationerna i kombination med operationernas parametrar specificeras inom WSDL-specifikationen. När det gäller tjänsten för ”meddelanden till befälhavare” definieras en enskild operation.

Det ämnesspecifika filterkriteriet hämtas från standarden för ”meddelanden till befälhavare”, men kriteriet utvidgas för multipla parametrar:

Typ av meddelande (obligatoriskt: antingen ”FTM”, ”WRM”, ”ICEM” eller ”WERM”).

Specifika avsnitt av vattenvägar eller delar av dessa avsnitt, eller specifika objekt (valfritt: beskrivning med en identifieringskod och/eller par av identifieringskoder).

Giltighetstid (valfritt: startdatum och slutdatum för giltighetsperiod).

Datum för publicering av meddelandet (valfritt: enskilda datum och/eller datumintervall).

Endast meddelanden som matchar de angivna kriterierna returneras av tjänsten.

Funktion för sidvisning

För att kontrollera datamängden stöds en funktion för sidvisning. Sidvisningsparametern definieras med en komplex uppsättning kriterier som innehåller följande element:

Offset: serienummer för det första returnerade meddelandet (heltal ≥ 0).

Limit: max. antal meddelanden (heltal ≥ 0).

Total count: flagga, om totalt antal meddelanden ska returneras (booleskt värde).

Den komplexa sidvisningsparametern är valfri, men om den används ska alla element i parametern anges. Sedan fungerar sidvisningsfunktionen på följande sätt:

Det totala antalet meddelanden överskrider inte värdet för parametern limit, med undantaget att värdet 0 betyder ”obegränsat”. Svaret hoppar över det antal meddelanden som definierats i parametern offset. För att denna funktion ska gå att använda måste tjänsten observera en temporärt stabil (men annars godtycklig) sekvens av meddelanden, t.ex. mellan två uppdateringar av meddelandedata på den underliggande datauppsättningen för webbtjänsten. Det betyder att två på varandra efterföljande anrop måste returnera samma meddelanden i samma ordning. Parametern total count bestämmer om svaret ska innehålla det totala antalet meddelanden som matchar de ämnesspecifika kriterierna. Vanligtvis bör det vara tillräckligt att begära denna information med det första svaret och utelämna informationen i alla efterföljande svar. Det bör leda till att webbtjänsten fungerar optimalt.

Med sidvisningsfunktionen kan meddelanden begäras iterativt i ”sidor”. För att sidvisningsfunktionen ska fungera korrekt måste samma ämnesspecifika parametrar tillhandahållas i varje anrop.

9.4.2. Svar

Om processen för en förfrågan fungerar som den ska innehåller svaret från webbtjänsten för meddelanden de meddelanden som matchar parametrarna i förfrågan. Meddelandena måste följa schemat för ”meddelanden till befälhavare” och kan valideras mot detta schema. Eftersom meddelandetyp är en obligatorisk parameter i förfrågan kan varje svar endast innehålla meddelanden av samma typ: FTM, WRM, ICEM eller WERM.

Om tjänsten detekterar fel under bearbetningen av förfrågan kan tjänsten returnera ett godtyckligt antal felmeddelanden med de felkoder som listas i följande underkapitel.

Ett svar från en webbtjänst för meddelanden kan innehålla både ”meddelanden till befälhavare” och felmeddelanden samtidigt.

Ytterligare sidvisningsinformation returneras om förfrågan innehöll parametrar för sidvisning. I förekommande fall är förskjutningen (offset) och antalet meddelanden däri obligatoriska. Det totala antalet (total count) behöver bara finnas med om detta begärts.

Observera: Det antas att kommunikationen mellan webbtjänsten och användaren fungerar ur teknisk synpunkt, dvs. att tjänsten tar emot förfrågningen och att användaren tar emot svaret. Tekniska fel, t.ex. fel på internetuppkopplingen eller att webbtjänsten inte är tillgänglig på grund av underhåll eller krasch beaktas inte här. Här beaktas endast fel som inträffar ”bakom kulisserna” i webbtjänsten, dvs. fel som påverkar användaren.

Felmeddelanden

Felkoderna för de förväntade felsituationerna anges nedan tillsammans med en förklaring. Svaret innehåller endast felkoden, vilket är den vanliga proceduren enligt XML-schemat för ”meddelanden till befälhavare”.

9.5. Generering av tjänster och klienter

Om tillvägagångssättet där man utgår från avtal följs konsekvent, det vill säga att ett eller flera avtal med fullständiga beskrivningar av gränssnittet ges i form av WSDL-dokument, kan en implementering av tjänsten/tjänsterna samt en implementering av en motsvarande klient genereras automatiskt med hjälp av lämpliga programvaruverktyg. I en idealisk situation behöver inga manuella ändringar göras i den genererade källkoden.

I de flesta fall behövs flera försök innan WSDL-specifikationen uppfyller verktygets exakta krav. Verktyget har vanligtvis individuella krav på användningen av WSDL-standarden för att fungera korrekt. Därför kan WSDL-specifikationen behöva ändras, även om WSDL-specifikationen från början var giltig enligt WSDL-standarden. Om webbtjänstens WSDL-specifikation ändras efter att tjänsten eller klienten har genererats kan en ny genereringsprocess krävas, beroende på aktuella förändringar.

Ordlista

1 Beskrivning hämtad från WS-I:s webbplats: http://www.ws-i.org

Tillägg 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">

<!--

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

= definition of main element RIS_Message =

= and corresponding type RIS_Message_Type =

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

-->

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

<xs:complexType name="RIS_Message_Type">

<xs:sequence>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

<xs:choice>

<xs:annotation>

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

</xs:annotation>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

</xs:choice>

</xs:sequence>

</xs:complexType>

<!--

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

= definition of identification_type, =

= used in definition of RIS_Message_Type =

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

-->

<xs:complexType name="identification_type">

<xs:sequence>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

<xs:element name="from">

<xs:annotation>

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

</xs:annotation>

<xs:simpleType>

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

<xs:maxLength value="64"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="originator">

<xs:annotation>

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

</xs:annotation>

<xs:simpleType>

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

<xs:maxLength value="64"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

<xs:simpleType>

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

<xs:maxLength value="64"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<!--

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

= types used in definition of identification_type =

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

-->

<xs:simpleType name="country_code_enum">

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

<xs:maxLength value="2"/>

<xs:enumeration value="AT"/>

<xs:enumeration value="BE"/>

<xs:enumeration value="BG"/>

<xs:enumeration value="CH"/>

<xs:enumeration value="CY"/>

<xs:enumeration value="CZ"/>

<xs:enumeration value="DE"/>

<xs:enumeration value="DK"/>

<xs:enumeration value="EE"/>

<xs:enumeration value="ES"/>

<xs:enumeration value="FI"/>

<xs:enumeration value="FR"/>

<xs:enumeration value="GB"/>

<xs:enumeration value="GR"/>

<xs:enumeration value="HR"/>

<xs:enumeration value="HU"/>

<xs:enumeration value="IE"/>

<xs:enumeration value="IT"/>

<xs:enumeration value="LT"/>

<xs:enumeration value="LU"/>

<xs:enumeration value="LV"/>

<xs:enumeration value="MD"/>

<xs:enumeration value="ME"/>

<xs:enumeration value="MT"/>

<xs:enumeration value="NL"/>

<xs:enumeration value="PL"/>

<xs:enumeration value="PT"/>

<xs:enumeration value="RO"/>

<xs:enumeration value="RS"/>

<xs:enumeration value="SE"/>

<xs:enumeration value="SI"/>

<xs:enumeration value="SK"/>

<xs:enumeration value="RU"/>

<xs:enumeration value="UA"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="language_code_enum">

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

<xs:maxLength value="2"/>

<xs:enumeration value="DE"/>

<xs:enumeration value="EN"/>

<xs:enumeration value="FR"/>

<xs:enumeration value="NL"/>

<xs:enumeration value="SK"/>

<xs:enumeration value="HU"/>

<xs:enumeration value="HR"/>

<xs:enumeration value="SR"/>

<xs:enumeration value="BG"/>

<xs:enumeration value="RO"/>

<xs:enumeration value="RU"/>

<xs:enumeration value="CS"/>

<xs:enumeration value="PL"/>

<xs:enumeration value="PT"/>

<xs:enumeration value="ES"/>

<xs:enumeration value="SV"/>

<xs:enumeration value="FI"/>

<xs:enumeration value="DA"/>

<xs:enumeration value="ET"/>

<xs:enumeration value="LV"/>

<xs:enumeration value="LT"/>

<xs:enumeration value="IT"/>

<xs:enumeration value="MT"/>

<xs:enumeration value="EL"/>

<xs:enumeration value="SL"/>

</xs:restriction>

</xs:simpleType>

<!--

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

= definition of ftm_type, =

= used in definition of RIS_Message_Type =

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

-->

<xs:complexType name="ftm_type">

<xs:sequence>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

<xs:simpleType>

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

<xs:maxLength value="500"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

<xs:simpleType>

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

<xs:maxLength value="64"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

<xs:choice maxOccurs="unbounded">

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

</xs:choice>

</xs:sequence>

</xs:complexType>

<!--

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

= types used in definition of ftm_type =

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

-->

<xs:simpleType name="subject_code_enum">

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

<xs:minLength value="3"/>

<xs:maxLength value="6"/>

<xs:enumeration value="ANNOUN"/>

<xs:enumeration value="WARNIN"/>

<xs:enumeration value="CANCEL"/>

<!-- the following values are added due to CR 128 -->

<xs:enumeration value="INFSER"/>

<!-- obsolete values due to CR 128 but still valid for backwards compatibility -->

<xs:enumeration value="OBSTRU"/>

<xs:enumeration value="PAROBS"/>

<xs:enumeration value="DELAY"/>

<xs:enumeration value="VESLEN"/>

<xs:enumeration value="VESHEI"/>

<xs:enumeration value="VESBRE"/>

<xs:enumeration value="VESDRA"/>

<xs:enumeration value="AVALEN"/>

<xs:enumeration value="CLEHEI"/>

<xs:enumeration value="CLEWID"/>

<xs:enumeration value="AVADEP"/>

<xs:enumeration value="NOMOOR"/>

<xs:enumeration value="SERVIC"/>

<xs:enumeration value="NOSERV"/>

<xs:enumeration value="SPEED"/>

<xs:enumeration value="WAVWAS"/>

<xs:enumeration value="PASSIN"/>

<xs:enumeration value="ANCHOR"/>

<xs:enumeration value="OVRTAK"/>

<xs:enumeration value="MINPWR"/>

<xs:enumeration value="DREDGE"/>

<xs:enumeration value="WORK"/>

<xs:enumeration value="EVENT"/>

<xs:enumeration value="CHGMAR"/>

<xs:enumeration value="CHGSER"/>

<xs:enumeration value="SPCMAR"/>

<xs:enumeration value="EXERC"/>

<xs:enumeration value="LEADEP"/>

<xs:enumeration value="LEVDEC"/>

<xs:enumeration value="LEVRIS"/>

<xs:enumeration value="LIMITA"/>

<xs:enumeration value="MISECH"/>

<xs:enumeration value="ECDISU"/>

<xs:enumeration value="NEWOBJ"/>

<xs:enumeration value="CHWWY"/>

<xs:enumeration value="CONWWY"/>

<xs:enumeration value="DIVER"/>

<xs:enumeration value="SPECTR"/>

<xs:enumeration value="LOCRUL"/>

<xs:enumeration value="VHFCOV"/>

<xs:enumeration value="HIGVOL"/>

<xs:enumeration value="TURNIN"/>

<xs:enumeration value="CONBRE"/>

<xs:enumeration value="CONLEN"/>

<xs:enumeration value="REMOBJ"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="reason_code_enum">

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

<xs:minLength value="3"/>

<xs:maxLength value="6"/>

<xs:enumeration value="EVENT"/>

<xs:enumeration value="WORK"/>

<xs:enumeration value="DREDGE"/>

<xs:enumeration value="EXERC"/>

<xs:enumeration value="HIGWAT"/>

<xs:enumeration value="HIWAI"/>

<xs:enumeration value="HIWAII"/>

<xs:enumeration value="LOWWAT"/>

<xs:enumeration value="SHALLO"/>

<xs:enumeration value="CALAMI"/>

<xs:enumeration value="LAUNCH"/>

<xs:enumeration value="DECLEV"/>

<xs:enumeration value="FLOMEA"/>

<xs:enumeration value="BLDWRK"/>

<xs:enumeration value="REPAIR"/>

<xs:enumeration value="INSPEC"/>

<xs:enumeration value="FIRWRK"/>

<xs:enumeration value="LIMITA"/>

<xs:enumeration value="CHGFWY"/>

<xs:enumeration value="CONSTR"/>

<xs:enumeration value="DIVING"/>

<xs:enumeration value="SPECTR"/>

<xs:enumeration value="EXT"/>

<xs:enumeration value="MIN"/>

<xs:enumeration value="SOUND"/>

<xs:enumeration value="OTHER"/>

<xs:enumeration value="STRIKE"/>

<xs:enumeration value="FLOMAT"/>

<xs:enumeration value="EXPLOS"/>

<xs:enumeration value="ICE"/>

<xs:enumeration value="OBSTAC"/>

<!--the following values are added due to CR 128-->

<xs:enumeration value="CHGMAR"/>

<xs:enumeration value="DAMMAR"/>

<xs:enumeration value="FALMAT"/>

<xs:enumeration value="MISECH"/>

<xs:enumeration value="HEARIS"/>

<xs:enumeration value="HIGVOL"/>

<xs:enumeration value="ECDISU"/>

<xs:enumeration value="LOCRUL"/>

<xs:enumeration value="NEWOBJ"/>

<xs:enumeration value="OBUNWA"/>

<xs:enumeration value="VHFCOV"/>

<xs:enumeration value="REMOBJ"/>

<xs:enumeration value="LEVRIS"/>

<xs:enumeration value="SPCMAR"/>

<!--the following value is added due to CR 155-->

<xs:enumeration value="WERMCO"/>

<!--obsolete values due to CR 128 but still valid for backwards compatibility -->

<xs:enumeration value="INFSER"/>

</xs:restriction>

</xs:simpleType>

<xs:complexType name="communication_type">

<xs:sequence>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

<xs:simpleType>

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

<xs:maxLength value="128"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

<xs:simpleType>

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

<xs:maxLength value="256"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

<xs:simpleType>

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

<xs:maxLength value="1024"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:simpleType name="reporting_code_enum">

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

<xs:maxLength value="3"/>

<xs:enumeration value="INF"/>

<xs:enumeration value="ADD"/>

<xs:enumeration value="REG"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="communication_code_enum">

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

<xs:maxLength value="3"/>

<xs:enumeration value="TE"/>

<xs:enumeration value="AP"/>

<xs:enumeration value="EM"/>

<xs:enumeration value="AH"/>

<xs:enumeration value="TT"/>

<xs:enumeration value="FX"/>

<xs:enumeration value="LS"/>

<xs:enumeration value="FS"/>

<xs:enumeration value="SO"/>

<xs:enumeration value="EI"/>

</xs:restriction>

</xs:simpleType>

<xs:complexType name="object_type">

<xs:sequence>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<!--

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

= definition of wrm_type, =

= used in definition of RIS_Message_Type =

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

-->

<xs:complexType name="wrm_type">

<xs:sequence>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<!--

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

= types used in definition of wrm_type =

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

-->

<xs:complexType name="measure_type">

<xs:sequence>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:simpleType name="measure_code_enum">

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

<xs:maxLength value="3"/>

<xs:enumeration value="DIS"/>

<xs:enumeration value="REG"/>

<xs:enumeration value="BAR"/>

<xs:enumeration value="VER"/>

<xs:enumeration value="LSD"/>

<xs:enumeration value="WAL"/>

<!-- obsolete values due to CR 151 but still valid for backwards compatibility -->

<xs:enumeration value="NOM"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="barrage_code_enum">

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

<xs:maxLength value="3"/>

<xs:enumeration value="CLD"/>

<xs:enumeration value="OPG"/>

<xs:enumeration value="CLG"/>

<xs:enumeration value="OPD"/>

<xs:enumeration value="OPN"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="regime_code_enum">

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

<xs:maxLength value="2"/>

<xs:enumeration value="NO"/>

<xs:enumeration value="HI"/>

<xs:enumeration value="II"/>

<xs:enumeration value="I"/>

<xs:enumeration value="NN"/>

<xs:enumeration value="LO"/>

</xs:restriction>

</xs:simpleType>

<xs:complexType name="difference_type">

<xs:sequence>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<!--

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

= definition of icem_type, =

= used in definition of RIS_Message_Type =

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

-->

<xs:complexType name="icem_type">

<xs:sequence>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<!--

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

= types used in definition of icem_type =

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

-->

<xs:complexType name="ice_condition_type">

<xs:sequence>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

<xs:documentation>Condition code</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="ice_accessibility_code" type="nts:ice_accessibility_code_enum" minOccurs="0">

<xs:annotation>

<xs:documentation>Accessibility code </xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="ice_classification_code" type="nts:ice_classification_code_enum" minOccurs="0">

<xs:annotation>

<xs:documentation>Classification code </xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="ice_situation_code" type="nts:ice_situation_code_enum" minOccurs="0">

<xs:annotation>

<xs:documentation>Situation code </xs:documentation>

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:simpleType name="ice_condition_code_enum">

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

<xs:maxLength value="1"/>

<xs:enumeration value="A"/>

<xs:enumeration value="B"/>

<xs:enumeration value="C"/>

<xs:enumeration value="D"/>

<xs:enumeration value="E"/>

<xs:enumeration value="F"/>

<xs:enumeration value="G"/>

<xs:enumeration value="H"/>

<xs:enumeration value="K"/>

<xs:enumeration value="L"/>

<xs:enumeration value="M"/>

<xs:enumeration value="P"/>

<xs:enumeration value="R"/>

<xs:enumeration value="S"/>

<xs:enumeration value="U"/>

<xs:enumeration value="O"/>

<xs:enumeration value="V"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="ice_accessibility_code_enum">

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

<xs:maxLength value="1"/>

<xs:enumeration value="A"/>

<xs:enumeration value="B"/>

<xs:enumeration value="F"/>

<xs:enumeration value="L"/>

<xs:enumeration value="C"/>

<xs:enumeration value="D"/>

<xs:enumeration value="E"/>

<xs:enumeration value="G"/>

<xs:enumeration value="H"/>

<xs:enumeration value="M"/>

<xs:enumeration value="K"/>

<xs:enumeration value="T"/>

<xs:enumeration value="P"/>

<xs:enumeration value="V"/>

<xs:enumeration value="X"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="ice_classification_code_enum">

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

<xs:maxLength value="1"/>

<xs:enumeration value="A"/>

<xs:enumeration value="B"/>

<xs:enumeration value="C"/>

<xs:enumeration value="D"/>

<xs:enumeration value="E"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="ice_situation_code_enum">

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

<xs:maxLength value="3"/>

<xs:enumeration value="NOL"/>

<xs:enumeration value="LIM"/>

<xs:enumeration value="NON"/>

</xs:restriction>

</xs:simpleType>

<!--

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

= definition of werm_type, =

= used in definition of RIS_Message_Type =

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

-->

<xs:complexType name="werm_type">

<xs:sequence>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

<xs:element name="weather_report" type="nts:weather_report_type" maxOccurs="2">

<xs:annotation>

<xs:documentation>Actual or Forecast report sections</xs:documentation>

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<!--

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

= types used in definition of werm_type =

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

-->

<xs:complexType name="fairway_section_werm_type">

<xs:sequence>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:complexType name="weather_report_type">

<xs:sequence>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

<xs:documentation>Forecast (true or 1) OR Actual report (false or 0)</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="weather_class_code" type="nts:weather_class_code_enum" maxOccurs="unbounded">

<xs:annotation>

<xs:documentation>Classification of weather report</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="weather_item" type="nts:weather_item_type" minOccurs="0" maxOccurs="unbounded">

<xs:annotation>

<xs:documentation>Weather items</xs:documentation>

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:simpleType name="weather_class_code_enum">

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

<xs:maxLength value="6"/>

<xs:enumeration value="CLR"/>

<xs:enumeration value="CLDY"/>

<xs:enumeration value="OCST"/>

<xs:enumeration value="DZZL"/>

<xs:enumeration value="RAIN"/>

<xs:enumeration value="LRAIN"/>

<xs:enumeration value="ORAIN"/>

<xs:enumeration value="HRAIN"/>

<xs:enumeration value="SLEET"/>

<xs:enumeration value="SNOW"/>

<xs:enumeration value="SNFALL"/>

<xs:enumeration value="HAIL"/>

<xs:enumeration value="SHWRS"/>

<xs:enumeration value="THSTRM"/>

<xs:enumeration value="HAZY"/>

<xs:enumeration value="FOG"/>

<xs:enumeration value="FOGPAT"/>

<xs:enumeration value="GALE"/>

<xs:enumeration value="STRM"/>

<xs:enumeration value="HURRC"/>

<xs:enumeration value="FZRA"/>

</xs:restriction>

</xs:simpleType>

<xs:complexType name="weather_item_type">

<xs:sequence>

<xs:element name="weather_item_code" type="nts:weather_item_code_enum">

<xs:annotation>

<xs:documentation>Weather item type (Wind, Wave etc)</xs:documentation>

</xs:annotation>

</xs:element>

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

<xs:annotation>

<xs:documentation>Actual or Minimum value</xs:documentation>

</xs:annotation>

</xs:element>

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

<xs:annotation>

<xs:documentation>Maximum value</xs:documentation>

</xs:annotation>

</xs:element>

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

<xs:annotation>

<xs:documentation>Gusts value (Wind)</xs:documentation>

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

<xs:element name="weather_category_code" type="nts:weather_category_code_enum" minOccurs="0">

<xs:annotation>

<xs:documentation>Classification of wind report</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="direction_code_min" type="nts:weather_direction_code_enum" minOccurs="0">

<xs:annotation>

<xs:documentation>Direction of wind or wave</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="direction_code_max" type="nts:weather_direction_code_enum" minOccurs="0">

<xs:annotation>

<xs:documentation>Direction of wind or wave</xs:documentation>

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:simpleType name="weather_item_code_enum">

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

<xs:maxLength value="2"/>

<xs:enumeration value="WI"/>

<xs:enumeration value="WA"/>

<xs:enumeration value="FG"/>

<xs:enumeration value="RN"/>

<xs:enumeration value="SN"/>

<xs:enumeration value="AT"/>

<xs:enumeration value="WT"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="weather_category_code_enum">

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

<xs:maxLength value="2"/>

<xs:enumeration value="0"/>

<xs:enumeration value="1"/>

<xs:enumeration value="2"/>

<xs:enumeration value="3"/>

<xs:enumeration value="4"/>

<xs:enumeration value="5"/>

<xs:enumeration value="6"/>

<xs:enumeration value="7"/>

<xs:enumeration value="8"/>

<xs:enumeration value="9"/>

<xs:enumeration value="10"/>

<xs:enumeration value="11"/>

<xs:enumeration value="12"/>

<xs:enumeration value="13"/>

<xs:enumeration value="14"/>

<xs:enumeration value="15"/>

<xs:enumeration value="16"/>

<xs:enumeration value="17"/>

<xs:enumeration value="18"/>

<xs:enumeration value="19"/>

<xs:enumeration value="20"/>

<xs:enumeration value="21"/>

<xs:enumeration value="22"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="weather_direction_code_enum">

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

<xs:maxLength value="3"/>

<xs:enumeration value="N"/>

<xs:enumeration value="NE"/>

<xs:enumeration value="E"/>

<xs:enumeration value="SE"/>

<xs:enumeration value="S"/>

<xs:enumeration value="SW"/>

<xs:enumeration value="W"/>

<xs:enumeration value="NW"/>

<xs:enumeration value="WRB"/>

</xs:restriction>

</xs:simpleType>

<!--

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

= types used in several definitions =

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

-->

<xs:simpleType name="internal_id_type">

<xs:annotation>

<xs:documentation>Internal ID — best practice: global unique identifier</xs:documentation>

</xs:annotation>

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

<xs:maxLength value="64"/>

</xs:restriction>

</xs:simpleType>

<xs:complexType name="nts_number_type">

<xs:sequence>

<xs:element name="organisation">

<xs:annotation>

<xs:documentation>Name of the publishing organisation (NtS Provider)</xs:documentation>

</xs:annotation>

<xs:simpleType>

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

<xs:maxLength value="64"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="year">

<xs:annotation>

<xs:documentation>Year of first issuing of the notice</xs:documentation>

</xs:annotation>

<xs:simpleType>

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

<xs:minInclusive value="1900"/>

<xs:maxInclusive value="9999"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="number">

<xs:annotation>

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

</xs:annotation>

<xs:simpleType>

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

<xs:minInclusive value="00000000"/>

<xs:maxInclusive value="99999999"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="serial_number">

<xs:annotation>

<xs:documentation>Serial number of notice (replacements and withdrawals), original notice: 0</xs:documentation>

</xs:annotation>

<xs:simpleType>

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

<xs:minInclusive value="00"/>

<xs:maxInclusive value="99"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:complexType name="validity_period_type">

<xs:sequence>

<xs:element name="date_start" type="xs:date">

<xs:annotation>

<xs:documentation>Start date of validity period including time zone</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="date_end" type="xs:date" minOccurs="0">

<xs:annotation>

<xs:documentation>End date of validity period including time zone</xs:documentation>

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:complexType name="fairway_section_type">

<xs:sequence>

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

<xs:annotation>

<xs:documentation>Geo information of fairway</xs:documentation>

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:complexType name="geo_object_type">

<xs:sequence>

<xs:element name="id" type="nts:isrs_code_type" maxOccurs="2">

<xs:annotation>

<xs:documentation>ISRS Location Code of the fairway/object</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="name">

<xs:annotation>

<xs:documentation>Local name of the fairway section</xs:documentation>

</xs:annotation>

<xs:simpleType>

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

<xs:maxLength value="256"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="type_code" type="nts:type_code_enum" default="FWY">

<xs:annotation>

<xs:documentation>Type of geographical object</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="position_code" type="nts:position_code_enum" minOccurs="0">

<xs:annotation>

<xs:documentation>Describes the position related to the fairway</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="coordinate" type="nts:coordinate_type" minOccurs="0" maxOccurs="2">

<xs:annotation>

<xs:documentation>Fairway section begin and end coordinates</xs:documentation>

</xs:annotation>

</xs:element>

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

<xs:annotation>

<xs:documentation>Waterway name (usefull if no RIS Index is available)</xs:documentation>

</xs:annotation>

<xs:simpleType>

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

<xs:maxLength value="256"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:simpleType name="isrs_code_type">

<xs:annotation>

<xs:documentation>ISRS location code, unique identification of the geo object as defined in RIS Index encoding guide</xs:documentation>

</xs:annotation>

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

<xs:length value="20"/>

<xs:pattern value="[A-Z]{2}[A-Z]{3}[A-Z0-9]{5}[A-Z0-9]{5}[0-9]{5}" />

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="type_code_enum">

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

<xs:maxLength value="3"/>

<xs:enumeration value="RIV"/>

<xs:enumeration value="CAN"/>

<xs:enumeration value="LAK"/>

<xs:enumeration value="FWY"/>

<xs:enumeration value="LCK"/>

<xs:enumeration value="BRI"/>

<xs:enumeration value="RMP"/>

<xs:enumeration value="BAR"/>

<xs:enumeration value="BNK"/>

<xs:enumeration value="GAU"/>

<xs:enumeration value="BUO"/>

<xs:enumeration value="BEA"/>

<xs:enumeration value="ANC"/>

<xs:enumeration value="BER"/>

<xs:enumeration value="MOO"/>

<xs:enumeration value="TER"/>

<xs:enumeration value="HAR"/>

<xs:enumeration value="FDO"/>

<xs:enumeration value="CAB"/>

<xs:enumeration value="FER"/>

<xs:enumeration value="PIP"/>

<xs:enumeration value="PPO"/>

<xs:enumeration value="HFA"/>

<xs:enumeration value="HMO"/>

<xs:enumeration value="SHY"/>

<xs:enumeration value="REF"/>

<xs:enumeration value="MAR"/>

<xs:enumeration value="LIG"/>

<xs:enumeration value="SIG"/>

<xs:enumeration value="TUR"/>

<xs:enumeration value="CBR"/>

<xs:enumeration value="TUN"/>

<xs:enumeration value="BCO"/>

<xs:enumeration value="REP"/>

<xs:enumeration value="FLO"/>

<xs:enumeration value="SLI"/>

<xs:enumeration value="DUK"/>

<xs:enumeration value="VTC"/>

<xs:enumeration value="RES"/>

<xs:enumeration value="LKB"/>

<xs:enumeration value="BRO"/>

<!--the following value is added due to CR 157-->

<xs:enumeration value="BNS"/>

</xs:restriction>

</xs:simpleType>

<xs:complexType name="coordinate_type">

<xs:sequence>

<xs:element name="lat">

<xs:simpleType>

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

<xs:minLength value="10"/>

<xs:maxLength value="12"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="long">

<xs:simpleType>

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

<xs:minLength value="10"/>

<xs:maxLength value="13"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:complexType name="limitation_type">

<xs:sequence>

<xs:element name="limitation_period" type="nts:limitation_period_type" minOccurs="0" maxOccurs="unbounded">

<xs:annotation>

<xs:documentation>Limitation periods / intervals</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="limitation_code" type="nts:limitation_code_enum">

<xs:annotation>

<xs:documentation>Kind of limitation</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="position_code" type="nts:position_code_enum" minOccurs="0">

<xs:annotation>

<xs:documentation>Describes the position of the limitation related to the fairway</xs:documentation>

</xs:annotation>

</xs:element>

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

<xs:annotation>

<xs:documentation>Value of limitation (i.e. max draught)</xs:documentation>

</xs:annotation>

</xs:element>

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

<xs:annotation>

<xs:documentation>Unit of the value of the limitation</xs:documentation>

</xs:annotation>

</xs:element>

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

<xs:annotation>

<xs:documentation>Value reference</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="indication_code" type="nts:indication_code_enum" minOccurs="0">

<xs:annotation>

<xs:documentation>Minimum or maximum or reduced by</xs:documentation>

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:complexType name="limitation_period_type">

<xs:sequence>

<xs:element name="date_start" type="xs:date">

<xs:annotation>

<xs:documentation>Start date of limitation period including time zone</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="date_end" type="xs:date" minOccurs="0">

<xs:annotation>

<xs:documentation>End date of limitation period including time zone</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="time_start" type="xs:time" minOccurs="0">

<xs:annotation>

<xs:documentation>Start time of limitation period without time zone</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="time_end" type="xs:time" minOccurs="0">

<xs:annotation>

<xs:documentation>End time of limitation period without time zone</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="interval_code" type="nts:interval_code_enum" minOccurs="0">

<xs:annotation>

<xs:documentation>Interval for limitation if applicable</xs:documentation>

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:simpleType name="interval_code_enum">

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

<xs:maxLength value="3"/>

<xs:enumeration value="CON"/>

<xs:enumeration value="DAY"/>

<xs:enumeration value="WRK"/>

<xs:enumeration value="WKN"/>

<xs:enumeration value="SUN"/>

<xs:enumeration value="MON"/>

<xs:enumeration value="TUE"/>

<xs:enumeration value="WED"/>

<xs:enumeration value="THU"/>

<xs:enumeration value="FRI"/>

<xs:enumeration value="SAT"/>

<xs:enumeration value="DTI"/>

<xs:enumeration value="NTI"/>

<xs:enumeration value="RVI"/>

<xs:enumeration value="EXC"/>

<xs:enumeration value="WRD"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="limitation_code_enum">

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

<xs:maxLength value="6"/>

<xs:enumeration value="OBSTRU"/>

<xs:enumeration value="PAROBS"/>

<xs:enumeration value="DELAY"/>

<xs:enumeration value="VESLEN"/>

<xs:enumeration value="VESHEI"/>

<xs:enumeration value="VESBRE"/>

<xs:enumeration value="VESDRA"/>

<xs:enumeration value="AVALEN"/>

<xs:enumeration value="CLEHEI"/>

<xs:enumeration value="CLEWID"/>

<xs:enumeration value="AVADEP"/>

<xs:enumeration value="NOMOOR"/>

<xs:enumeration value="SERVIC"/>

<xs:enumeration value="NOSERV"/>

<xs:enumeration value="SPEED"/>

<xs:enumeration value="WAVWAS"/>

<xs:enumeration value="PASSIN"/>

<xs:enumeration value="ANCHOR"/>

<xs:enumeration value="OVRTAK"/>

<xs:enumeration value="MINPWR"/>

<xs:enumeration value="ALTER"/>

<xs:enumeration value="CAUTIO"/>

<xs:enumeration value="NOLIM"/>

<xs:enumeration value="TURNIN"/>

<xs:enumeration value="NOSHORE"/>

<xs:enumeration value="CONBRE"/>

<xs:enumeration value="CONLEN"/>

<!-- the following value is added due to CR 128 -->

<xs:enumeration value="LEADEP"/>

<!-- the following value is added due to CR 148 -->

<xs:enumeration value="NOBERT"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="position_code_enum">

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

<xs:maxLength value="2"/>

<xs:enumeration value="AL"/>

<xs:enumeration value="LE"/>

<xs:enumeration value="MI"/>

<xs:enumeration value="RI"/>

<xs:enumeration value="LB"/>

<xs:enumeration value="RB"/>

<xs:enumeration value="N"/>

<xs:enumeration value="NE"/>

<xs:enumeration value="E"/>

<xs:enumeration value="SE"/>

<xs:enumeration value="S"/>

<xs:enumeration value="SW"/>

<xs:enumeration value="W"/>

<xs:enumeration value="NW"/>

<xs:enumeration value="BI"/>

<xs:enumeration value="SM"/>

<xs:enumeration value="OL"/>

<xs:enumeration value="EW"/>

<xs:enumeration value="MP"/>

<xs:enumeration value="FP"/>

<xs:enumeration value="VA"/>

<xs:enumeration value="RY"/>

<xs:enumeration value="GY"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="reference_code_enum">

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

<xs:maxLength value="4"/>

<xs:enumeration value="NAP"/>

<xs:enumeration value="KP"/>

<xs:enumeration value="FZP"/>

<xs:enumeration value="ADR"/>

<xs:enumeration value="TAW"/>

<xs:enumeration value="PUL"/>

<xs:enumeration value="NGM"/>

<xs:enumeration value="ETRS"/>

<xs:enumeration value="POT"/>

<xs:enumeration value="LDC"/>

<xs:enumeration value="HDC"/>

<xs:enumeration value="ZPG"/>

<xs:enumeration value="GLW"/>

<xs:enumeration value="HSW"/>

<xs:enumeration value="LNW"/>

<xs:enumeration value="HNW"/>

<xs:enumeration value="IGN"/>

<xs:enumeration value="WGS"/>

<xs:enumeration value="RN"/>

<xs:enumeration value="HBO"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="indication_code_enum">

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

<xs:maxLength value="3"/>

<xs:enumeration value="MAX"/>

<xs:enumeration value="MIN"/>

<xs:enumeration value="RED"/>

</xs:restriction>

</xs:simpleType>

<xs:complexType name="target_group_type">

<xs:sequence>

<xs:element name="target_group_code" type="nts:target_group_code_enum" default="ALL">

<xs:annotation>

<xs:documentation>Target group (vessel type)</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="direction_code" type="nts:direction_code_enum" default="ALL">

<xs:annotation>

<xs:documentation>Upstream or downstream traffic, or both</xs:documentation>

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:simpleType name="target_group_code_enum">

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

<xs:maxLength value="3"/>

<xs:enumeration value="ALL"/>

<xs:enumeration value="CDG"/>

<xs:enumeration value="COM"/>

<xs:enumeration value="PAX"/>

<xs:enumeration value="PLE"/>

<xs:enumeration value="CNV"/>

<xs:enumeration value="PUS"/>

<xs:enumeration value="NNU"/>

<xs:enumeration value="LOA"/>

<xs:enumeration value="SMA"/>

<xs:enumeration value="CND"/>

<xs:enumeration value="WOC"/>

<xs:enumeration value="MOV"/>

<xs:enumeration value="NMV"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="direction_code_enum">

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

<xs:maxLength value="3"/>

<xs:enumeration value="ALL"/>

<xs:enumeration value="UPS"/>

<xs:enumeration value="DWN"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="unit_enum">

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

<xs:maxLength value="4"/>

<xs:enumeration value="cm"/>

<xs:enumeration value="m3/s"/>

<xs:enumeration value="h"/>

<xs:enumeration value="km/h"/>

<xs:enumeration value="kW"/>

<xs:enumeration value="m/s"/>

<xs:enumeration value="mm/h"/>

<xs:enumeration value="°C"/>

</xs:restriction>

</xs:simpleType>

</xs:schema>

Tillägg D]

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

<wsdl:definitions

xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"

xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"

xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"

xmlns:xs="http://www.w3.org/2001/XMLSchema"

xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"

xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"

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

xmlns:tns="http://www.ris.eu/nts.ms/2.0.4.0"

targetNamespace="http://www.ris.eu/nts.ms/2.0.4.0"

name="NtS-Message-Service">

<!--

= specification of types =

-->

<wsdl:types>

<!--

= xml-schema for types =

-->

<xs:schema

targetNamespace="http://www.ris.eu/nts.ms/2.0.4.0"

xmlns:xs="http://www.w3.org/2001/XMLSchema"

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

xmlns:nts-ms="http://www.ris.eu/nts.ms/2.0.4.0"

elementFormDefault="qualified"

attributeFormDefault="unqualified"

version="2.0.4.0">

<!-- import NtS schema -->

<xs:import

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

schemaLocation="http://www.ris.eu/nts/4.0/NtS_XSD_V.4.0.4.0.xsd"/>

<!-- query with filters, parameters according to the NtS standard -->

<xs:element name="get_messages_query">

<xs:complexType>

<xs:sequence>

<!-- type of message (FTM, WRM, ICEM, WERM) -->

<xs:element name="message_type" type="nts-ms:message_type_type"/>

<!-- ISRS codes for fairway sections or objects -->

<xs:element name="ids" type="nts-ms:id_pair" minOccurs="0" maxOccurs="unbounded"/>

<!-- time of validity -->

<xs:element name="validity_period" type="nts:validity period type"

minOccurs="0"/>

<!-- date of publication of the notice -->

<xs:element name="dates_issue" type="nts-ms:date_pair" minOccurs="0" maxOccurs="unbounded"/>

<!-- optional parameter for paging mechanism -->

<xs:element name="paging_request" type="nts-ms:paging_request_type" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<!-- result to query — can contain

"nts:RIS_MessageType", arbitrary number, defined in the NtS-xsd (see www.ris.eu)

"nts-ms:error_code_type", arbitrary number, defined in this schema

"nts-ms:paging_result_type", optional, defined in this schema -->

<xs:element name="get_messages_result">

<xs:complexType>

<xs:sequence>

<xs:element name="result_message" type="nts:RIS_Message_Type" minOccurs= "0" maxOccurs="unbounded"/>

<xs:element name="result_error" type="nts-ms:error_code_type" minOccurs= "0" maxOccurs="unbounded"/>

<xs:element name="paging_result" type="nts-ms:paging_result_type" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<!-- type definitions used in request -->

<xs:simpleType name="message_type_type">

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

<xs:enumeration value="FTM"/>

<xs:enumeration value="WRM"/>

<xs:enumeration value="ICEM"/>

<xs:enumeration value="WERM"/>

</xs:restriction>

</xs:simpleType>

<xs:complexType name="id_pair">

<xs:sequence>

<xs:element name="id" type="nts:isrs_code_type" minOccurs="1" maxOccurs="2" />

</xs:sequence>

</xs:complexType>

<xs:complexType name="date_pair">

<xs:sequence>

<xs:element name="date_start" type="xs:date"/>

<xs:element name="date_end" type="xs:date" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="paging_request_type">

<xs:sequence>

<xs:element name="offset" type="xs:nonNegativeInteger"/>

<xs:element name="limit" type="xs:nonNegativeInteger"/>

<xs:element name="total_count" type="xs:boolean"/>

</xs:sequence>

</xs:complexType>

<!-- type definitions used in response -->

<xs:simpleType name="error_code_type">

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

<xs:enumeration value="e010">

<xs:annotation>

<xs:documentation>Description: message type not supported, Explanation: web service does not support the requested message type</xs:documentation>

</xs:annotation>

</xs:enumeration>

<xs:enumeration value="e030">

<xs:annotation>

<xs:documentation>Description: paging parameters inconsistent with messages, Explanation: parameters for paging mechanism do not fit the available messages, e.g. Offset >= Total Count</xs:documentation>

</xs:annotation>

</xs:enumeration>

<xs:enumeration value="e100">

<xs:annotation>

<xs:documentation>Description: syntax error in request, Explanation: request violates the schema for requests</xs:documentation>

</xs:annotation>

</xs:enumeration>

<xs:enumeration value="e110">

<xs:annotation>

<xs:documentation>Description: incorrect message type, Explanation: given message type is not known</xs:documentation>

</xs:annotation>

</xs:enumeration>

<xs:enumeration value="e120">

<xs:annotation>

<xs:documentation>Description: incorrect type-specific parameters, Explanation: type-specific parameters are erroneous</xs:documentation>

</xs:annotation>

</xs:enumeration>

<xs:enumeration value="e130">

<xs:annotation>

<xs:documentation>Description: incorrect paging parameters, Explanation: given parameters for the paging mechanism are erroneous</xs:documentation>

</xs:annotation>

</xs:enumeration>

<xs:enumeration value="e200">

<xs:annotation>

<xs:documentation>Description: operation not known, Explanation: the requested operation is unknown</xs:documentation>

</xs:annotation>

</xs:enumeration>

<xs:enumeration value="e300">

<xs:annotation>

<xs:documentation>Description: data source unavailable, Explanation: data source of the web service for the NtS data is temporarily unavailable</xs:documentation>

</xs:annotation>

</xs:enumeration>

<xs:enumeration value="e310">

<xs:annotation>

<xs:documentation>Description: too many results for request, Explanation: server is unable to handle number of results</xs:documentation>

</xs:annotation>

</xs:enumeration>

</xs:restriction>

</xs:simpleType>

<xs:complexType name="paging_result_type">

<xs:sequence>

<xs:element name="offset" type="xs:nonNegativeInteger"/>

<xs:element name="count" type="xs:nonNegativeInteger"/>

<xs:element name="total_count" type="xs:nonNegativeInteger" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

</xs:schema>

</wsdl:types>

<!--

= specification of messages =

-->

<wsdl:message name="get_messages_request">

<wsdl:part name="parameters" element="tns:get_messages_query"/>

</wsdl:message>

<wsdl:message name="get_messages_response">

<wsdl:part name="parameters" element="tns:get_messages_result"/>

</wsdl:message>

<!--

= specification of port type =

-->

<wsdl:portType name="NtS_message_service">

<wsdl:operation name="get_messages">

<wsdl:input message="tns:get_messages_request"/>

<wsdl:output message="tns:get_messages_response"/>

</wsdl:operation>

</wsdl:portType>

<!--

= specification of binding =

-->

<wsdl:binding name="NtS_message_service_soap_binding" type="tns:NtS_message_service">

<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>

<wsdl:operation name="get_messages">

<soap:operation soapAction="http://www.ris.eu/nts.ms/get_messages"/>

<wsdl:input>

<soap:body use="literal"/>

</wsdl:input>

<wsdl:output>

<soap:body use="literal"/>

</wsdl:output>

</wsdl:operation>

</wsdl:binding>

<!--

= specification of service =

-->

<wsdl:service name="NtS_message_service_service">

<wsdl:port name="NtS_message_service" binding="tns:NtS_message_service_soap_binding">

<soap: address location="http://nts-ms.example.org/NtS_message_service"/>

</wsdl:port>

</wsdl:service>

</wsdl:definitions>

Bilaga