02007R0416 — DA — 29.12.2018 — 001.001

Denne tekst tjener udelukkende som dokumentationsværktøj og har ingen retsvirkning. EU's institutioner påtager sig intet ansvar for dens indhold. De autentiske udgaver af de relevante retsakter, inklusive deres betragtninger, er offentliggjort i den Europæiske Unions Tidende og kan findes i EUR-Lex. Disse officielle tekster er tilgængelige direkte via linkene i dette dokument

Ændret ved:









▼B

KOMMISSIONENS FORORDNING (EF) Nr. 416/2007

af 22. marts 2007

om tekniske specifikationer for efterretninger for skippere i henhold til artikel 5 i Europa-Parlamentets og Rådets direktiv 2005/44/EF om harmoniserede flodinformationstjenester (RIS) på de indre vandveje i Fællesskabet







Artikel 1

I denne forordning defineres de tekniske specifikationer for efterretninger for skippere. De tekniske specifikationer er indeholdt i bilaget til nærværende forordning.

Artikel 2

Denne forordning træder i kraft på dagen efter offentliggørelsen i Den Europæiske Unions Tidende.

Denne forordning er bindende i alle enkeltheder og gælder umiddelbart i hver medlemsstat.

▼M1









BILAG

INDHOLDSFORTEGNELSE 1. GENERELLE BESTEMMELSER 1.1. Definitioner 1.2. Primære funktioner og ydelseskrav for efterretninger for skippere (NtS) 2. EFTERRETNINGER FOR SKIPPERE 3. NtS-MEDDELELSESTYPER 4. NtS-STRUKTUR OG KODNING AF NtS-MEDDELELSER 4.1. Generel struktur 4.1.1. Identifikationsafsnit 4.1.2. Farvands- og trafikrelateret meddelelse 4.1.3. Vandstandsrelateret meddelelse 4.1.4. Ismelding 4.1.5. Vejrmelding 4.2. Forklaring af XML-tags og kodeværdier i NtS Reference Tables 4.3. Identifikation af farvandsstrækninger og objekter i NtS- meddelelser 4.4. Regler for kodning af NtS-meddelelser Tillæg A: NtS Encoding Guide for redaktører Tillæg B: NtS Encoding Guide for udviklere af applikationer Tillæg C: NtS XML Schema Definition (XSD) Tillæg D: NtS Web Service-specifikation (WSDL)

1. GENERELLE BESTEMMELSER

1.1. Definitioner

Systemet for farvandsefterretninger (FIS) omfatter geografiske, hydrologiske og administrative oplysninger vedrørende vandvejen (farvandet), som bådførere og flådeledere bruger til at planlægge, gennemføre og overvåge en rejse. Udtrykkene »bådfører« og »skipper« sidestilles i denne standard med udtrykket »kaptajn« i retningslinjerne for flodinformationstjenester (RIS) (Kommissionens forordning (EF) nr. 414/2007 ( 1 )), og udtrykket »flådeleder« er defineret i Kommissionens forordning (EF) nr. 415/2007 ( 2 ).

FIS indeholder både dynamiske oplysninger (f.eks. vandstand, vandstandsprognoser) og statiske oplysninger (f.eks. driftstider for sluser og broer) vedrørende brugen af og status for infrastrukturen på indre vandveje og kan således bruges som grundlag for taktiske og strategiske beslutninger om sejlads.

De traditionelle kilder til FIS omfatter visuelle navigationshjælpemidler og efterretninger for skippere offentliggjort i papirform eller via radiomeddelelser og fastnettelefoner ved sluser. Mobiltelefoner har bidraget med nye muligheder for stemme- og datakommunikation, men mobilnet er ikke tilgængeligt alle steder og på alle tidspunkter. Skræddersyet FIS til vandveje kan leveres ved hjælp af radiotelefontjenester for indre vandveje, internettjenester eller elektroniske søkorttjenester, f.eks. det elektroniske kortvisnings- og informationssystem for indlandssejlads (Inland ECDIS) med elektronisk søkort (ENC).

1.2. Primære funktioner og ydelseskrav for efterretninger for skippere (NtS)

Denne tekniske specifikation for NtS omfatter regler for datatransmission af farvandsoplysninger via internettet.

NtS vil:

a) indeholde oplysninger om farvandsforhold, trafik, vejrforhold, vandstand og is for farvandsefterretninger

b) indeholde automatiske oversættelser af det væsentlige indhold i efterretningerne ved anvendelse af standardsprogbrug baseret på kodelister (NtS Reference Tables som opstillet i tillæg E)

c) indeholde en standardiseret struktur for datasæt for at lette integrationen af efterretninger i rejseplanlægningssystemerne

d) være kompatibelt med datastrukturen i RIS Index og Inland ECDIS for at lette integrationen af NtS i Inland ECDIS som fastsat i direktiv 2005/44/EF af 7. september 2005 om harmoniserede flodinformationstjenester (RIS) på de indre vandveje i Fællesskabet.

De tekniske specifikationer for NtS letter dataudvekslingen mellem NtS-systemerne i forskellige lande og til andre applikationer, der anvender NtS-data, herunder Inland ECDIS.

Nogle oplysninger i NtS-meddelelser kan standardiseres, andre kan ikke.

Den standardiserede del omfatter alle oplysninger, der er:

a) vigtige for sikkerheden ved sejlads på indre vandveje (f.eks. forlist mindre fartøj i højre side af farvandet på Donau, flod-km 2010)

b) nødvendige til rejseplanlægning, herunder lukning af sluser og reduktion af lodret frihøjde.

Yderligere oplysninger, som ikke er relevante for sikkerheden eller rejseplanlægningen, herunder årsagen til lukning af en sluse, kan angives som fritekst uden automatisk oversættelse. Brugen af fritekst begrænses til et minimum.

2. EFTERRETNINGER FOR SKIPPERE

Medlemsstaterne sikrer, at NtS-meddelelser er tilgængelige online og via en standardiseret NtS Web Service i overensstemmelse med de tekniske specifikationer, der er beskrevet i dette bilag og dets tillæg. Den standardiserede NtS Web Service-specifikation er angivet i tillæg D i form af en »Web Service Description Language« (WSDL).

Den standardiserede NtS Web Service giver brugeren mulighed for at udvælge meddelelser, som minimum grundlag af et af følgende kriterier:

a) et bestemt afsnit af en vandvej

b) en bestemt del af en vandvej defineret ved flod-km for start- og slutpunktet

c) meddelelsens gyldighedstidspunkt (startdato og slutdato for gyldighedsperioden)

d) publikationsdato for efterretningen (publikationsdato og -tidspunkt).

NtS-meddelelser, som overholder de standarder, der henvises til i dette bilag, kan bl.a. fremsendes via redskaber såsom:

a) mobile applikationer (apps)

b) e-mailtjenester.

Der kan udveksles oplysninger mellem forskellige landes NtS-systemer. Alle systemer, der anvender de standarder, som er beskrevet i bilaget til denne forordning, kan integrere NtS fra andre systemer i deres egne tjenester, hvis meddelelsens indhold ikke ændres. Brugerne underrettes, hvis tilslutningen til en integreret NtS-kilde afbrydes, eller hvis der ikke er adgang hertil.

3. NtS-MEDDELELSESTYPER

NtS-meddelelser er væsentlige meddelelser, der i videst muligt omfang er blevet standardiseret.

Der er fire NtS-meddelelsestyper:

a) farvands- og trafikrelaterede meddelelser

b) vandstandsrelaterede meddelelser

c) ismeldinger

d) vejrmeldinger.

4. NtS-STRUKTUR OG KODNING AF NtS-MEDDELELSER

I dette kapitel beskrives strukturen og kodningen af standardiserede elektroniske NtS-meddelelser.

En NtS-meddelelse er en struktureret meddelelse med standardiserede elementer, når det er muligt. Brugen af fritekst i dataelementerne begrænses til et minimum.

Den standardiserede NtS Extended Markup Language (XML) Schema Definition), benævnt XSD i denne standard, indeholder de standardiserede kodeværdier, og de mulige formater er opført i tillæg C.

De standardiserede kodeværdier og XML-tags og deres betydning og oversættelse er anført i NtS Reference Tables i tillæg E og er også tilgængelige i elektronisk form i det europæiske system til forvaltning af referencedata (European Reference Data Management System, ERDMS), der forvaltes af Europa-Kommissionen.

4.1. Generel struktur

En NtS-meddelelse består af følgende afsnit:

a) et identifikationsafsnit

b) et afsnit, hvori de relevante objekter eller farvandsstrækninger, som meddelelsen vedrører, defineres

c) et afsnit vedrørende begrænsninger for en farvands- og trafikrelateret meddelelse, målinger for en vandstandsrelateret meddelelse, isforhold for en ismelding eller vejrrapporter for en vejrmelding.

Figur 1

Struktur i meddelelser med efterretninger for skippere

4.1.1. Identifikationsafsnit

Hver meddelelse skal indeholde et identifikationsafsnit. Identifikationsafsnittet indeholder generelle oplysninger om udstederen og meddelelsens publikationsdato.

4.1.2. Farvands- og trafikrelateret meddelelse

Den farvands- og trafikrelaterede meddelelse indeholder oplysninger vedrørende farvandsstrækninger eller objekter og anvendes til at angive begrænsninger til følgende formål:

a) »Advarsel«: sikkerhedsrelevant. Advarslen skal som minimum indeholde en begrænsning, som resulterer i en direkte og konkret fare for personer, fartøjer eller anlæg, f.eks. svejsningsarbejde på en bro, der gnister, inspektionsbur/arbejdere, der hænger fra en bro, hindring i farvandet.

b) »Meddelelse«: relevant for rejseplanlægning eller sikkerhed. Meddelelsen kan indeholde begrænsninger, f.eks. blokering af et slusekammer som følge af vedligeholdelsesarbejder, opmudring af farvandet.

c) »Informationstjeneste«: generelle oplysninger, som ikke er direkte knyttet til rejseplanlægning eller sikkerhed. Informationstjenesten må ikke indeholde specifikke begrænsninger, og den er derfor ikke umiddelbart relevant for rejseplanlægning eller sikkerhed. Sådanne oplysninger kan omfatte generelle oplysninger, f.eks. om lokale trafikregler og Inland ECDIS Update.

4.1.3. Vandstandsrelateret meddelelse

Det vandstandsrelaterede afsnit indeholder værdier eller prognoser for:

a) vandstand

b) mindste loddede dybde

c) lodret frigang

d) dæmningsstatus

e) udtømning

f) vandregime.

Normalt genereres og offentliggøres vandstandsinformation automatisk baseret på oplysninger fra sensorudstyr (f.eks. tidevandsmåler), systemer (f.eks. vandstandsmodel) eller infrastruktur (f.eks. dæmningsstatus). Forskellige mekanismer kan udløse en offentliggørelse, f.eks. periodisk offentliggørelse eller opnåelse af en bestemt værdi.

4.1.4. Ismelding

Ismeldingen indeholder oplysninger om de faktiske eller prognosticerede isforhold for farvandsstrækninger. Isoplysninger genereres normalt af kompetent personale baseret på lokale observationer og faglig vurdering.

4.1.5. Vejrmelding

Vejrmeldingen indeholder oplysninger om (farlige) vejrforhold for indlandssejlads.

Vejrmeldinger kan offentliggøres for at lette formidlingen af hydro-meteorologiske oplysninger fra hydro-meteorologiske netværk til skippere.

4.2. Forklaring af XML-tags og kodeværdier i NtS Reference Tables

Betydningen af de forskellige anvendte elementer i NtS XML Schema Definition (XSD) er beskrevet i de i tillæg E opstillede NtS Reference Tables. Strukturen, formatet og mulige værdier af alle XML-elementer er beskrevet i NtS XSD i tillæg C.

a) Koordinater med bredde- og længdegrader er kodet i overensstemmelse med World Geodetic System 1984 (det verdensomspændende geodætiske system) og angives i grader og minutter med mindst tre, men helst fire decimaler ([d]d mm.mmm[m] N, [d][d]d mm.mmm[m] E).

b) Decimaler i numeriske felter angives med et decimalpunkt (».«). Der bruges ikke tusindadskillere.

c) NtS-meddelelser må kun indeholde følgende enheder for de værdier, der er indeholdt i XML-meddelelsen: cm, m3/s, h, km/h og kW, m/s (vind), mm/h (regn) og grader celsius. Enhederne kan konverteres i nationale applikationer af hensyn til brugervenligheden.

4.3. Identifikation af farvandsstrækninger og objekter i NtS-meddelelser

Med henblik på at opfylde de minimumskrav vedrørende tilvejebringelse af oplysninger om objekter, der er relevante for sejlads på indre vandveje, som omhandlet i artikel 4, stk. 3, litra a), i direktiv 2005/44/EF, skal ISRS Location Code anvendes i afsnittet om objekter. ISRS Location Code anvendes til at identificere objekter og farvandsstrækninger og til at sikre interoperable RIS-systemer og -tjenester (f.eks. til at kombinere oplysninger om infrastruktur fra RIS Index, Inland ECDIS og NtS til brug for rejseplanlægning).

ISRS Location Code er en 20-cifret alfanumerisk kode, der anvendes til at fastlægge en unik og standardiseret forbindelse mellem objekter i flodinformationstjenester. Den består af følgende obligatoriske dataelementer i fire informationsfelter:

a) Felt 1: UN/LOCODE (5 bogstaver, alfanumerisk), bestående af:

— Country Code (2 cifre, alfanumerisk) ( 3 )

— Location Code (3 cifre, alfanumerisk, »XXX«, hvis ikke tilgængelig)

b) Felt 2: Fairway Section Code (5 cifre, alfanumerisk, fastlægges af den nationale myndighed)

c) Felt 3: Object Reference Code (5 cifre, alfanumerisk, »XXXXX«, hvis ikke tilgængelig)

d) Felt 4: Fairway Section Hectometre (5 cifre, alfanumerisk, hektometer i centerområdet eller »00000«, hvis ikke tilgængelig).

ISRS Location Code og referencedataene for objekter ajourføres af medlemsstaterne i RIS Index og indgives til ERDMS, der forvaltes af Europa-Kommissionen i overensstemmelse med vedligeholdelsesprocedurerne for RIS Index, der er offentliggjort på ERDMS-webstedet.

4.4. Regler for kodning af NtS-meddelelser

NtS-meddelelser kodes i overensstemmelse med NtS Encoding Guide for redaktører (tillæg A) og NtS Encoding Guide for udviklere af applikationer (tillæg B).









EFTERRETNINGER FOR SKIPPERE — ENCODING GUIDE FOR REDAKTØRER

INDHOLDSFORTEGNELSE 1. Baggrund, struktur og formål med NtS Encoding Guides 2. Udvælgelse af NtS-meddelelsestypen 3. FTM — grundlæggende betragtninger, skridt i offentliggørelsen af en FTM 4. Forklaring af FTM-koder 5. WRM — grundlæggende betragtninger 6. ICEM — grundlæggende betragtninger, skridt i offentliggørelsen af en ICEM 7. WERM — grundlæggende betragtninger 8. Regler for visse elementer

Forkortelser







Forkortelse Betydning CEVNI Den europæiske kodeks for indre vandveje (http://www.unece.org/trans/main/sc3/sc3res.html) ENC Electronic Navigational Chart (elektronisk søkort) FTM Farvands- og trafikrelateret meddelelse ICEM Ismelding Inland ECDIS Elektronisk kortvisnings- og informationssystem for indlandssejlads ISRS Location Code »International Ship Reporting Standard« lokaliseringskode NtS Efterretninger for skippere RIS Flodinformationstjenester VHF Maritimt mobilt bånd WERM Vejrmelding WRM Vandstandsrelateret meddelelse WSDL Web Services Description Language (et sprog til beskrivelse af webtjenester) XML Extended Markup Language XSD XML Schema Definition

1. Baggrund, struktur og formål med NtS Encoding Guides

NtS-standarden forbedres konstant. Et vigtigt skridt fremad var frigivelsen af NtS Web Service til udveksling af NtS-meddelelser mellem myndigheder samt mellem myndigheder og NtS-brugere.

Der er blevet udarbejdet to dokumenter, som skal lette en harmoniseret kodning af NtS-meddelelser på nationalt og internationalt plan, nemlig NtS Encoding Guide for redaktører og NtS Encoding Guide for udviklere af applikationer. Disse retningslinjer finder anvendelse på NtS XSD 4.0 og NtS Web Service WSDL 2.0.4.0.

I betragtning af den øgede anvendelse af NtS Web Service vil NtS-meddelelserne blive yderligere harmoniseret for at sikre korrekt visning af indhold på tredjepartssystemer. En ensartet kodning af meddelelser er også en forudsætning for brug af meddelelser i rejseplanlægningsapplikationer.

Elementer, der kun indeholder standardværdier, skal udelades, hvis de er betingede, fordi de fører til for mange meddelelser uden merværdi.

NtS Encoding Guide for redaktører er rettet til personale, der redigerer (og offentliggør) NtS-meddelelser, og indeholder trinvise instrukser om generering af de relevante meddelelsestyper og en forklaring af koder. I NtS Encoding Guide redegøres for anvendelsen af de fire NtS-meddelelsestyper, og den indeholder udfyldningsinstruktioner samt koder, der skal anvendes i bestemte situationer. NtS Encoding Guide for redaktører er indeholdt i nærværende tillæg A.

NtS Encoding Guide for udviklere af applikationer indeholder retningslinjer for udvikling og gennemførelse af NtS-applikationer, og der redegøres for logik, processer og automatiske værdier/standardværdier. NtS Encoding Guide for udviklere af applikationer er indeholdt i tillæg B i bilaget til denne forordning.

2. Udvælgelse af NtS-meddelelsestypen

— FTM: Vælg denne type, hvis du ønsker at generere en »farvands- og trafikrelateret meddelelse« for vandveje eller objekter på vandvejen. [gå til kapitel 3]

— WRM: Vælg denne type, hvis du ønsker at generere en »vandstandsrelateret meddelelse« med oplysninger om nuværende og prognosticerede vandstande samt andre oplysninger. Den vandstandsrelaterede meddelelse indeholder oplysninger om et objekt eller en farvandsstrækning. Objektet defineres ved dets ISRS Location Code, og farvandsstrækningen defineres ved dens ISRS Location Codes for start og slut.

— ICEM: Vælg denne type, hvis du ønsker at generere en »ismelding«. Afsnittet med ismeldinger indeholder oplysninger om isforholdene for en farvandsstrækning defineret ved dens ISRS Location Codes for start og slut.

— WERM: Vælg denne type, hvis du ønsker at generere en »vejrmelding« med oplysninger om nuværende og prognosticerede vejrforhold på en vandvejsstrækning defineret ved dens ISRS Location Codes for start og slut.

3. FTM — grundlæggende betragtninger, skridt i offentliggørelsen af en FTM

Detaljerede oplysninger om, hvilke koder der skal anvendes, findes i kapitel 4. De betragtninger, der er anført fra punkt 3.3 og frem, er ikke nødvendigvis inputrækkefølgen i et FTM-redigeringsredskab.

3.1. Er der behov for at offentliggøre oplysninger via NtS FTM i henhold til NtS-standarden? Alle relevante oplysninger vedrørende sikkerhed og rejseplanlægning skal offentliggøres via NtS-meddelelser. Oplysninger, som ikke er relevante for sikkerheden og rejseplanlægningen, kan offentliggøres. Hvert emne og hver hændelse/begivenhed skal offentliggøres i en særskilt meddelelse.

3.2. Findes der allerede en gældende FTM vedrørende den aktuelle situation (både med hensyn til indhold og gyldighedstidspunkt)?

3.2.1. Ja:

Den allerede eksisterende FTM skal ajourføres. Den pågældende offentliggjorte meddelelse skal udvælges og ajourføres i FTM-redigeringsredskabet. En udløbet FTM kan ikke længere ajourføres.

3.2.2. Nej:

Der skal udarbejdes en ny FTM. Hvis en lignende begivenhed allerede er kodet i en eksisterende FTM, kan den pågældende FTM anvendes som udkast ved udarbejdelsen af en ny FTM (hvis denne funktion er tilgængelig), eller der kan anvendes en skabelon (hvis denne funktion er tilgængelig).

3.3. Det geografiske gyldighedsområde skal fastsættes.

3.3.1. Hvis FTM'en vedrører en bestemt del af en vandvej, skal vandvejsstrækningen medtages, defineret ved dens start- og slutpunkter. Hvis indholdet gælder for flere afsnit af samme vandvej eller forskellige vandveje, kan alle afsnit angives i en FTM.

3.3.2. Hvis FTM'en vedrører et bestemt objekt (f.eks. bro, sluse osv.) på vandvejen, skal det pågældende objekt udvælges fra listen over tilgængelige objekter (hvis udvælgelse er tilgængelig). Det er ikke nødvendigt at definere en vandvejsstrækning i meddelelsen. Hvis en FTM vedrører flere objekter, kan alle objekterne medtages i en FTM.

3.3.3. Det er muligt at kombinere objekt- og farvandsrelaterede oplysninger i en meddelelse, så længe oplysningerne vedrører en bestemt årsag/begivenhed (samme emne- og årsagskode).

3.3.4. Selv om koordinaterne er betingede, anføres de for at understøtte visningen på kort (disse koordinater udfyldes ofte automatisk i NtS-applikationen).

3.4. Indholdet af FTM'en skal indtastes.

Alle oplysninger, som kan angives ved hjælp af NtS Reference Tables, skal kodes i de standardiserede meddelelsesområder. Kun supplerende oplysninger (som ikke kan kodes på anden vis), angives i fritekstfeltet.

3.5. Målgruppen/-grupperne vedrørende fartøjstyper og berørte sejlretninger indtastes, hvis relevant.

3.5.1. Hvis meddelelsen gælder for alle fartøjer (alle fartøjstyper) i alle retninger, udelades målgruppen, således at der kun kodes væsentlige oplysninger. Hvis meddelelsen/begrænsningen gælder for en specifik målgruppe eller retning, udvælges de pågældende koder.

3.5.2. Hvis hele meddelelsen gælder for specifikke målgrupper, angives oplysningerne om målgrupperne i den generelle del af FTM'en (og gentages ikke i afsnittet eller afsnittene om begrænsninger).

3.5.3. Hvis forskellige begrænsninger gælder for forskellige målgrupper, angives oplysningerne om målgrupperne i afsnittet om de pågældende begrænsninger (og gentages ikke i den generelle del).

3.5.4. Hvis de kompetente myndigheder undtager enkelte fartøjer eller lokal trafik fra begrænsninger (f.eks. fartøjer, der deltager i en begivenhed, hvor det er indført en generel blokering, lokal færgefart i blokerede områder), er det ikke nødvendigt at tage disse undtagelser i betragtning ved kodning af målgruppen eller målgrupperne. Disse oplysninger kan anføres i fritekstfeltet for supplerende oplysninger.

3.6. Kommunikationsdelen udfyldes, hvis relevant.

Hvis supplerende oplysninger er tilgængelige via en specifik kilde, angives de i dette afsnit. Hvis der er en yderligere pligt til at rapportere via et specifikt medie, angives det i dette afsnit.

3.7. Afsnittet om begrænsning udfyldes, hvis relevant.

Hvis der er begrænsninger, udfyldes afsnittet om begrænsning. Hvis værdierne for begrænsningerne er kendte, skal de angives. Det er obligatorisk at angive værdier for skibsdimensioner, hastighedsgrænsen og den plads, der er til rådighed for sejlads.

Begrænsningsperioder skal anføres for alle begrænsninger, således at der kan foretages korrekte beregninger i rejseplanlægningsapplikationer (for at lette arbejdet kan NtS-applikationen omfatte en funktion til at kopiere begrænsningsperioder eller til at vælge mere end en begrænsning for en begrænsningsperiode).

3.8. Startdatoen for meddelelsens gyldighed skal fastsættes.

Hvis slutdatoen for meddelelsens gyldighed allerede er kendt, fastsættes den ligeledes. Gyldighedsperiodens slutdato må ikke ligge før dags dato.

Bemærk, at oplysningerne om gyldighedsperioden vil blive anvendt af applikationer til at udvælge de meddelelser, som skal vises til brugerne for et ønsket tidspunkt.

Hvis meddelelsen trækkes tilbage:

a) før gyldighedsperiodens indledning, skal startdatoen og slutdatoen fastsættes til datoen for tilbagetrækningen

b) efter gyldighedsperiodens indledning, skal de nye slutdatoer for alle begrænsninger fastsættes til et tidligere tidspunkt, og gyldighedsperiodens slutdato fastsættes til datoen for tilbagetrækningen.

3.9. Meddelelsen kan offentliggøres.

4. Forklaring af FTM-koder

4.1. Subject_code:

Definition af anvendelsen af emnekoder:

— »Advarsel«: sikkerhedsrelevant. Advarslen skal som minimum indeholde en begrænsning, som resulterer i en direkte og konkret fare for personer, fartøjer eller anlæg, f.eks. svejsningsarbejde på en bro, der gnister, inspektionsbur/arbejdere, der hænger fra en bro, hindring i farvandet

— »Meddelelse«: relevant for rejseplanlægning eller sikkerhed. Meddelelsen kan indeholde begrænsninger, f.eks. blokering af et slusekammer som følge af vedligeholdelsesarbejder, opmudring af farvandet, trafikregler ud over national lovgivning,

— »Informationstjeneste«: generelle oplysninger, som ikke er direkte knyttet til rejseplanlægning eller sikkerhed. Informationstjenesten må ikke indeholde specifikke begrænsninger, og den er derfor ikke umiddelbart relevant for rejseplanlægning eller sikkerhed. Sådanne oplysninger kan f.eks. omfatte lokale trafikregler og Inland ECDIS Update. Gyldighedsperioden bruges til at angive det tidspunkt, hvor informationstjenestens meddelelse vises til brugerne, og ikke til at angive de fremlagte oplysningers gyldighedsperiode (f.eks. 1 måned eller som defineret i de nationale procedurer).

— »Efterretning trukket tilbage« — Emnekoden »Efterretning trukket tilbage« anvendes kun, hvis — — dags dato ligger før gyldighedsperiodens startdato. I dette tilfælde er det kun indholdet i feltet »Supplerende tekst på det nationale sprog«, som kan ændres, meddelelsens yderligere indhold må ikke ændres. I dette tilfælde anvendes »Efterretning trukket tilbage« til at trække en efterretning tilbage, før den bliver gældende. »Efterretning trukket tilbage« anvendes således til efterretninger, som trækkes tilbage før gyldighedsperiodens startdato, og/eller i forbindelse med planlagte foranstaltninger, der ikke vil blive gennemført (f.eks. planlagt opmudring, som ikke kan iværksættes på grund af høj vandstand). — gyldighedsperioden allerede er indledt, og de nye slutdatoer for alle begrænsninger fastsættes til et tidligere tidspunkt. Gyldighedsperiodens slutdato skal fastsættes til datoen for tilbagetrækningen. — I dette tilfælde afsluttes foranstaltninger/begivenheder før afslutningen af en oprindeligt fastsat gyldighedsperiode for en allerede eksisterende FTM.

4.2. Reason_code

Årsagskoden bør udfyldes for at give skippere yderligere oplysninger.

Definition af anvendelsen af årsagskoder:







anlægsarbejder Meddelelse om anlægsarbejder nødsituation Advarsel om nødsituation ændring af farvandet Meddelelse om ændring af farvandet ændring af sømærker Meddelelse om ændring af sømærker indsnævring af farvand Meddelelse om en indsnævring af farvandet, hvis der ikke er en anden relevant årsagskode beskadigede sømærker/skilte Meddelelse om beskadigede sømærker/skiltning dykkere i vandet Advarsel om dykkere i vandet opmudring Meddelelse om opmudringsaktiviteter begivenhed Meddelelse om begivenheder, f.eks. svømme- sejl- eller robådskonkurrence øvelser Meddelelse om øvelser, f.eks. rednings- eller militærøvelser rydning af sprængstoffer Meddelelse om rydning af sprængstoffer omfattende slusedrift Meddelelse om højere udledning end sædvanligt gennem overløbsdæmninger eller sluser af vandforvaltningsmæssige årsager faldende materiel Meddelelse om faldende materiel, f.eks. istapper, træstykker falsk radarekko Meddelelse om eventuelle falske radarekkoer fyrværkeri Meddelelse om fyrværkeri flydende materiel Meddelelse om flydende materialer over vandoverfladen (synlige) og under vandoverfladen (usynlige) flow-måling Meddelelse om målinger sundhedsrisiko Advarsel eller meddelelse om f.eks. ege-processionslarven, udsivende gas, osv. højspændingskabler Meddelelse om et krydsende højspændingskabel højvande Meddelelse om højvande før forbud mod sejlads pga. vandstanden is Meddelelse om is — yderligere oplysninger vil blive udsendt i form af isoplysninger (ismelding) Inland ECDIS Update Informationstjeneste om en Inland ECDIS Update inspektion Meddelelse om inspektion — anvendes kun i tilfælde af inspektion, anvendes ikke i forbindelse med (reparations- og anlægs)arbejder. Der kan være begrænsninger på grund af inspektionsbiler/-bure eller stilladser søsætning Meddelelse om et skib, der forlader et værft lokale trafikregler Informationstjeneste vedrørende supplerende eller ændrede bestemmelser i gældende love eller forskrifter uden særlige begrænsninger, datoer for begrænsninger eller gyldighedsdatoer lavvande Meddelelse om lavvande før forbud mod sejlads pga. vandstanden vandstanden sænkes Meddelelse om en kontrolleret sænkning af vandstanden i forbindelse med inspektioner eller anlægsarbejder eller af vandforvaltningsmæssige årsager minimum slusedrift Meddelelse om lavere udledning end sædvanligt gennem overløbsdæmninger eller sluser af vandforvaltningsmæssige årsager nyt objekt Meddelelse om oplysninger om et nyt objekt, f.eks. en bro, kajplads hindring Meddelelse om lavere frigang i højden og/eller indsnævring af farvandet på grund af en hindring over vandlinjen blokering under vandlinjen Meddelelse om lavere vanddybde og/eller indsnævring af farvandet på grund af en hindring under vandlinjen forbud mod sejlads pga. vandstanden Meddelelse om vandstand (højvande eller lavvande), som fører til et forbud mod sejlads radiodækning Meddelelse om radiodækning fjernelse af objekt Meddelelse om fjernelse af objekt reparation Meddelelse om, at noget er brudt sammen eller er ude af drift og skal repareres, f.eks. et slusekontrolsystem — kan også anvendes til planlagte reparationer stigende vandstand Meddelelse om naturligt stigende vandstande, ikke af vandforvaltningsmæssige årsager aflejringer Meddelelse om lavere vanddybde på grund af aflejringer oplodning Meddelelse om oplodning særlig signalering Meddelelse om anvendelse af særlig signalering, f.eks. til blokering fra vandområder eller fiskeriområder særlig transport Meddelelse om særlige transporter strejke Meddelelse om det operationelle personales strejke, der har indvirkning på tilgængeligheden af vandvejsinfrastruktur vandstand, hvor sejlads udføres med særlig agtpågivenhed Meddelelse om vandstand (højvande eller lavvande), som sejlads skal udføres med særlig agtpågivenhed arbejder Meddelelse om generelle arbejder ved objekter, ved vandvejes bredder og/eller lejer (floder eller kanaler) begrænsninger Anvendes kun til angivelse af eksisterende begrænsninger, hvis der ikke er en anden relevant årsagskode andet Anvendes ikke — hvis der ikke er en anden relevant årsagskode, skal årsagskoden ikke udfyldes

4.3. Limitation_code:

Definition af anvendelsen af begrænsningskoder:

— Blokering: — Hvis ingen form for sejlads er mulig: — — gennem et slusekammer — gennem en broåbning — forbi et bestemt punkt i farvandet — i et bestemt afsnit af farvandet.

— Delvis blokering: — Alle dele af infrastrukturen (f.eks. slusekamre, broåbninger) skal have deres egen ISRS Location Code. Hvis disse koder endnu ikke foreligger, kan delvis blokering anvendes, hvis begrænset sejlads er mulig (f.eks. hvis det kun er sluseområdeobjektet, der er tilgængeligt for en sluse med to parallelle kamre). — — gennem et eller flere slusekamre, hvoraf mindst et er åbent — gennem en eller flere broåbninger, hvoraf mindst en er åben

— Ingen betjening: — Anvendes, hvis en bevægelig bro ikke er betjent i en bestemt periode. Denne periode skal ligge inden for normal åbningstid. — Manglende betjening af en bevægelig bro betyder, at det stadig er muligt at passere under broen. Ellers er der tale om en »Blokering«. Manglende betjening af en sluse kodes som en »Blokering«.

— Ændret betjening: — Anvendes, hvis den normale åbningstid for objekter (f.eks. sluser, (bevægelige) broer) ændres, udvides eller indskrænkes.

— Hvis der er begrænsninger for de tilladte dimensioner for fartøjer/konvojer (ikke i direkte forbindelse med infrastruktur), kodes begrænsningen med følgende tekstelementer: — — fartøjets dybgang — fartøjets bredde — konvojbredde — fartøjets længde — konvojlængde — fartøjets højde over vandlinjen. — Hvis tilgængelig, angives en absolut værdi.

— Hvis der er begrænsninger for den tilgængelige størrelse af et objekt eller en vandvejsstrækning, anvendes følgende koder: — — frigang i højden — disponibel længde — frigang, bredde — vanddybde. — Hvis tilgængelig, angives en absolut værdi.

— Mindste loddede dybde: Anvendes, hvis dybde kan give problemer (f.eks. på grund af aflejringer). En værdi for den absolutte dybde (i forhold til en referenceværdi) eller reduktionen af dybde angives. Hvis tilgængelig, angives en absolut værdi.

— Forsinkelse: Anvendes, hvis der opstår en tidsbegrænset blokering eller hændelse ved et objekt eller på et afsnit af vandvejen mellem en bestemt start- og slutdato. — Den anslåede maksimale varighed af blokeringen eller hændelsen bør kodes. Forsinkelse må ikke anvendes, hvis et af flere slusekamre i en sluse er ikke tilgængeligt.

— Hvis særlige manøvrer eller handlinger er forbudt, skal de pågældende begrænsninger kodes. Disse begrænsninger må kun kodes, hvis de ikke allerede er meddelt via navigationsskilte eller bestemmelser, der er kodet i den officielle indlands-ENC: — — minimum kraft — skiftende færdselsretning — vending er ikke tilladt — passage er ikke tilladt — overhaling ikke tilladt — ikke tilladt at lægge til kaj — fortøjning forbudt — opankring ikke tilladt — undgå at lave efterdønninger — hastighedsbegrænsning — ikke tilladt at gå i land. — Hvis tilgængelig, angives en absolut værdi for hastighedsbegrænsning og minimum kraft.

— Særlig agtpågivenhed: Hvis en FTM (eller en del af en FTM) vedrører et farvand/en vandvej, anvendes denne begrænsning til at oplyse, på hvilken position i farvandet/floden/kanalen/søen hændelsen er indtruffet. — Den anvendes desuden, hvis det ikke er muligt at beskrive begrænsningen i detaljer, men det er nyttigt eller nødvendigt at advare eller informere skippere om, at de skal passe på og lytte til radiomeldinger.

— Ingen begrænsning: Bør kun anvendes, hvis det skal angives udtrykkeligt, at der ikke er begrænsninger i en bestemt periode.

4.4. Limitation interval_code: Definition af anvendelsen af intervalkoder:

— »kontinuerligt«: anvendes til begrænsninger, der gælder fra en startdato/tidspunkt indtil slutdato/tidspunkt uden afbrydelse (f.eks. blokering fra 01.01.2016 kl. 00:00 til 31.03.2016 kl. 23:59, men også for blokering den 17.09.2016 fra kl. 08:00 til kl. 18:00).

— »dagligt«: anvendes ved regelmæssigt gentagen anvendelse af en begrænsning (f.eks. undgå at lave efterdønninger i arbejdstiden ved et opmudringssted — fra 07.04.2016 til 11.04.2016, dagligt fra kl. 06:00 til kl. 18:00).

— om dagen (som defineret i CEVNI): Ved »dag« forstås perioden mellem solopgang og solnedgang.

— om natten (som defineret i CEVNI): Ved »nat« forstås perioden mellem solnedgang og solopgang.

— Ugedage: Hvis der er tidsintervaller i relation til forskellige ugedage, skal disse udvælges fra følgende tekstelementer: — — mandag — tirsdag — onsdag — torsdag — fredag — lørdag — søndag — mandag til fredag — lørdag og søndag

— »ved nedsat sigt«: Anvendes, hvis begrænsningen kun gælder ved nedsat sigt på grund af tåge og dis, sne, regn eller andre årsager.

— »med undtagelse af«: Må ikke anvendes. Afbrudte tidsintervaller skal angives som særskilte begrænsningsperioder i den samme begrænsning. Dette skyldes, at rejseplanlægningssoftware ikke kan tolke denne kode korrekt som noget, der ikke finder sted på den bestemte dato eller det bestemte tidspunkt. Det er derfor ikke muligt at beregne forventede ankomsttider (ETA'er) korrekt.

— »Mandag til fredag med undtagelse af helligdage«: Anvendes kun, hvis helligdagene ligger inden for begrænsningens gyldighedsperiode. Som en service over for brugerne kan helligdage anføres i fritekstfeltet i FTM'en. I rejseplanlægningssoftware kan der ikke tages højde for nationale helligdage ved beregningen af ETA'er.

4.5. Indication_code:

Indication_code anvendes til at oplyse om specifikke værdier for visse begrænsninger (f.eks. hastighedsbegrænsning, minimum kraft, vanddybde). For at fastlægge visse dimensioner skal der enten henvises til et eksternt referencesystem (geografisk og hydrologisk) (f.eks. frigang i højden, vanddybde, mindste loddede dybde) eller til kunstige strukturers kendte dimensioner (f.eks. disponibel længde, frigang, bredde).

4.5.1. Hvis absolutte dimensioner eller henvisninger kendes, skal de anvendes. Relative værdier bør kun angives, hvis det ikke er muligt at henvise til et eksternt referencesystem.

4.5.2. reduceret med → dette er en relativ værdi

4.5.3. maksimum → dette er en absolut værdi

4.5.4. minimum → dette er en absolut værdi

4.5.5. Hvis den dimension, der angiver en begrænsning, henviser til en geografisk eller hydrologisk koordinat, skal det pågældende referencesystem angives i NtS-meddelelsen (f.eks. frigang i højden min. 4 m i forhold til højeste farbare vandstand, vanddybde min. 1,7 m i forhold til reguleret lav vandstand)

4.5.6. Hvis den dimension, der angiver en begrænsning, henviser til en kunstig struktur (f.eks. bro, sluse), kan henvisningen angives i forhold til kendte dimensioner (f.eks. frigang i højden reduceret med 1,5 m, disponibel længde reduceret med 27 m).

4.6. Position_code (objekter):

Position_code skal så vidt muligt henvise til den side af farvandet, hvor objektet befinder sig i forhold til sejlløbets retning (venstre/midt/højre), eller til andre almindeligt kendte oplysninger (gammel/ny) eller geografiske retning (nord/syd/øst/vest). Position_code for objekter kan forhåndsudfyldes automatisk med referencedata fra RIS Index. Venstre/højre side af farvandet defineres i nedstrøms retning.

4.7. Position_code (farvande/vandveje):

Der er ikke en position_code for en FTM (eller en del af en FTM) vedrørende farvande eller vandveje. For at oplyse, på hvilken side af farvandet/kanalen/floden/søen en hændelse indtræder, anvendes begrænsningen »særlig agtpågivenhed« sammen med den korrekte position_code for begrænsninger.

4.8. Position_code (begrænsninger):

4.8.1. Position_code skal så vidt muligt henvise til den side af farvandet eller objektet, hvor begrænsningen gælder (venstre/højre). Venstre/højre side af farvandet defineres i nedstrøms retning.

4.8.2. Position_code gør skipperen opmærksomhed på den side af farvandet, hvor der f.eks. er et område af særlig interesse, en fare eller en hindring. Derfor er en omtrentlig angivelse (f.eks. venstre bred — venstre — midt for — højre — højre bred) tilstrækkelig. Det er ikke hensigten, at der skal foretages en nærmere opdeling.

4.8.3. Hvis det er nødvendigt, bør mere præcise positionsoplysninger fortrinsvis gives ved hjælp af kort eller skitser (bilag, se kapitel 3.6)

4.8.4. For afsnit, hvor den sædvanlige positionsangivelse af (venstre/højre) side af farvandet ikke synes hensigtsmæssig (f.eks. havnebassiner, visse kanalafsnit uden særskilt strømningsretning), kan verdenshjørnerne (nord/øst/syd/vest) anvendes.

4.9. Target_group_code (se kapitel 3.5)

4.10. Reporting_code

4.10.1. Reporting_code anvendes som hovedregel kun, hvis der er et særligt behov for kommunikation (f.eks. en særlig pligt til at rapportere til de lokale myndigheder om trafikregulering på stedet), eller hvis der foreligger supplerende oplysninger (f.eks. om VHF-kontaktpunkt såsom kanalnavn eller kaldesignal for opmudringsfartøjs nuværende position) af direkte relevans for FTM'en.

4.10.2. En rutinemæssig gentagelse af offentligt tilgængelige oplysninger (f.eks. lokale myndigheders telefonnumre, VHF-kanaler for sluser osv.) skal undgås, hvis denne kommunikation ikke er direkte begrundet i FTM'en.

4.10.3. Almindeligt anvendte kommunikationsmidler i henhold til offentlig regulering (f.eks. mellem skibe indbyrdes og fra skib til land, VHF-kommunikation som fastsat i CEVNI eller regionale eller nationale regler for sejlads) gentages som hovedregel ikke i Reporting_code, hvis denne kommunikation ikke er direkte begrundet i FTM'en).

4.11. Communication_code

Følgende format anvendes (eksempler):

— VHF »nummer, kaldesignal«: »10, Schifffahrtsaufsicht Wien«

— Telefon- eller faxnummer: »+43123456789, Schifffahrtsaufsicht Wien«

— Internetadresse: »http://eksempel.com«

— Lydsignal: »long blast / langer Ton«

— E-mail: »eksempel@myndighed.eu«

— EDI-mailboksnummer »900012345@edi.bics.nl«

— Teletekst: »ARD, 992 — 995«

4.12. Type_code:

En vandvej er enten en kanal, sø eller flod.

— opankringsområde

— bred

— fast sømærke

— kajplads

— grænsekontrol

— bro

— broåbning

— bøje

— luftledning

— kanal (udtrykket »kanal« anvendes, hvis en meddelelse vedrører hele kanalen (ikke blot farvandet))

— kanalbro akvædukt

— omløbskanal

— farvand (»farvandet« er den del af vandvejen, som rent faktisk kan anvendes til skibsfart).

— færge

— flydedok

— overløbslukke (et overløbslukke anvendes til at beskytte et område ved højvande)

— havn

— havneanlæg

— havnekontor

— sø (udtrykket »sø« anvendes, hvis en meddelelse vedrører hele søen (ikke blot farvandet))

— lys

— slusebassin: individuelt slusekammer

— sluse: hele slusekomplekset

— fortøjningsanlæg

— advarselsmærke

— rørledning

— rørbro

— rampe

— affaldsdeponi

— rapporteringspunkt

— reservoir

— flod (udtrykket »flod« anvendes, hvis en meddelelse vedrører hele floden (ikke blot farvandet))

— skibskran

— skibsværft

— signalstation

— terminal

— tidevandsmåler

— tunnel

— vendebassin

— skibstrafikcenter

— overløbsdæmning (en overløbsdæmning anvendes til at kontrollere vandstanden i floder)

5. WRM — grundlæggende betragtninger

Vandstandsrelaterede meddelelser skal som hovedregel genereres automatisk. Hvis dette ikke er muligt, skal den manuelle generering af WRM følge de procedurer, der er fastsat for automatisk genererede WRM (se NtS Encoding Guide for udviklerne), så tæt som muligt.

6. ICEM — grundlæggende betragtninger, skridt i offentliggørelsen af en ICEM

Ismeldinger er baseret på lokale observationer og vurderinger og genereres normalt af autoriseret personale.

En ICEM udstedes i tilfælde af is. Is indebærer ikke nødvendigvis en begrænsning af sejladsen, men der kan imidlertid oplyses om isforhold, der ikke hindrer sejlads.

6.1. Er der behov for at offentliggøre oplysninger via NtS FTM?

Den første ismelding for en strækning offentliggøres først, når der er is på vandvejen eller bifloder, også hvis der ikke er nogen begrænsninger.

6.2. Er der allerede en gældende ICEM for den berørte strækning af vandvejen?

6.2.1. Ja:

Hvis der (stadig) er en gældende meddelelse vedrørende den berørte strækning, ajourføres den allerede eksisterende meddelelse. Det er muligt at ajourføre eksisterende ismeldinger, selv om anvendelsesområdet er ændret (isen udbredes f.eks., hvilket øger størrelsen af den berørte strækning).

6.2.2. Nej:

Hvis der ikke er nogen gældende ismelding vedrørende den berørte strækning, genereres en ny meddelelse.

6.3. Der kan imidlertid oplyses om isforhold, der ikke hindrer sejlads.

6.4. En ICEM er altid gældende for en enkelt strækning af vandvejen. Det geografiske gyldighedsområde fastsættes ved at definere vandvejen og de respektive start- og slut(hektometer)punkter (eller ved at vælge bestemte på hinanden følgende afsnit, afhængigt af den nationale gennemførelse).

6.5. Tidspunktet for måling skal anføres. De pågældende isforhold indtastes, som minimum ved brug af en af kodelisterne (afhængigt af de nationale 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 (koden for issituation bør altid anføres, således at issituationen kan vises på et kort ved hjælp af »trafiklysfarver«).

6.6. En ICEM kan offentliggøres. Ismeldinger vil automatisk være gældende indtil dagen efter offentliggørelsen eller som defineret i nationale procedurer.

7. WERM — grundlæggende betragtninger

Under hensyntagen til de mange tilgængelige webtjenester og applikationer vedrørende vejrprognoser og vejrvarslinger bør WERM kun anvendes til vejroplysninger af særlig betydning for sejlads, der ikke er dækket af generelle vejrtjenester.

Vejrmeldinger skal som hovedregel genereres automatisk. Hvis dette ikke er muligt, skal den manuelle generering af WERM følge de procedurer, der er fastsat for automatisk genererede WERM, så tæt som muligt (se NtS Encoding Guide for udviklere af applikationer).

8. Regler for visse elementer

8.1. Regler for elementet »name« i forbindelse med objekter

Objektets navn forhåndsudfyldes normalt af NtS-redigeringsredskabet med referencedata fra RIS Index. Navne anføres på det lokale sprog, diakritiske tegn eller kyrilliske bogstaver kan således anvendes (f.eks. Baarlerbrücke, Volkeraksluis eller Mannswörth).

Der skal ikke angives oplysninger om karakteristiske træk, og objekttypen skal ikke gentages i navnet, medmindre der gives yderligere oplysninger om objekttypen.

Eksempel: Slusen »Schleuse Freudenau« må kun benævnes »Freudenau«, og objekttypen »sluse« tilføjes automatisk baseret på type_code.

Eksempel: Objektnavnet for jernbanebroen i Krems (AT) er »Eisenbahnbrücke Krems«. Oplysningen »jernbanebro« indgår i objektets navn, da det tilfører oplysninger ud over type_code »bro«.

Eksempel: Objektnavnet for en bro i Linz (AT) er »Nibelungenbrücke«. Ordet »Brücke« medtages i objektets navn, da det indgår i broens navn.

Eksempel: Vandvejsprofilen »Pegelstelle Wildungsmauer« kaldes »Wildungsmauer«, da oplysningen om, at dette objekt er en profil, allerede er kodet i type_code.

Hvis et afsnit af en vandvej er grænsen mellem to lande med forskellige sprog, kan objektets nationale navn anføres på begge sprog (f.eks. »Staatsgrenze AT-SK/Statna hranica AT-SK«).

8.2. Regler for elementet »name« i forbindelse med farvande

Farvandsnavne forhåndsudfyldes normalt af NtS-redigeringsredskabet med referencedata fra RIS Index. Feltet »name« skal indeholde det lokale navn på den pågældende farvandsstrækning (f.eks. »Rhein«). Afhængigt af nationale processer kan farvandets navn muligvis redigeres, således at det omfatter almindeligt anvendte navne eller tilføjelser (f.eks. »Rhein am Deutschen Eck«).

8.3. Regler for elementerne »value« og »unit« med begrænsninger

Medmindre andet er anført, er det kun muligt at benytte enhederne cm, m3/s, h, km/h og kW, m/s (vind), mm/h (regn) og grader celsius i NtS-meddelelser.









EFTERRETNINGER FOR SKIPPERE — ENCODING GUIDE FOR UDVIKLERE AF APPLIKATIONER

INDHOLDSFORTEGNELSE 1. Baggrund og struktur 1.1. Formålet med NtS Encoding Guide 1.1.1. NtS Encoding Guide for redaktører 1.1.2. NtS Encoding Guide for udviklere af applikationer (dette dokument) 2. NtS-meddelelser og afsnit 3. WRM — grundlæggende betragtninger 3.1. Udfyldning af afsnittet nts_number i WRM 3.2. Udfyldning af WRM, herunder prognoser 4. ICEM-processer 4.1. Ny ICEM 4.2. Ajourføring af en eksisterende ICEM 5. WERM — grundlæggende betragtninger 5.1. Udfyldning af afsnittet nts_number i WERM 5.2. Udfyldning af WERM »weather_category_code« 6. FTM-processer 6.1. Ny FTM 6.2. Ajourføring/tilbagetrækning af en eksisterende FTM 6.3. Vandvejs- og/eller objektrelateret FTM 6.4. Automatisk rangorden af begrænsningskoder 6.5. Håndtering af begrænsningsperioder 7. Almindelige gennemførelsesbestemmelser 7.1. Udfyldning af »number_section« 7.2. Udfyldning af elementerne »from«, »originator«, »organisation« og »source« 7.3. Udeladelse af elementer 7.4. Automatisk udfyldning af date_issue 7.5. Håndtering af tidszoneoplysninger i NtS-meddelelser 7.6. Håndtering af sekunder i NtS-meddelelser 7.7. Decimalformat i NtS-meddelelser 7.8. Enheder, der skal anvendes i NtS-meddelelser 7.9. Regler for elementerne »name«, »position_code« og »type_code« 7.10. Regler for elementet »fairway_name« 7.11. Afklaring vedrørende oversættelser i regnearket »reference_code« 7.12. Anbefaling vedrørende elementet »koordinat« 7.13. Håndtering af målgrupper 7.14. Visning af gældende meddelelser på et bestemt tidspunkt 7.15. Valgfri funktioner, der øger brugervenligheden af NtS-redigeringsredskaber 8. NtS XML-meddelelsesstruktur 9. NtS Web Service 9.1. Mål 9.2. Grundlæggende principper og krav 9.2.1. Webstandarder 9.2.2. Interaktionsmodel og kodningsmetode for NtS WS 9.3. Generelle specifikationer og anbefalinger 9.3.1. Specifikation: Versionsoplysninger 9.3.2. Specifikation: Navneområdestruktur 9.3.3. Anbefaling: Brug af navneområder 9.3.4. Anbefaling: Brug af navneområdepræfikser 9.3.5. Specifikation: Brug af ISRS Location Codes 9.4. NtS-meddelelsestjeneste (gennemførelsesspecifikation) 9.4.1. Anmodning 9.4.2. Svar 9.5. Generering af tjenester og kunder Ordliste

1. Baggrund og struktur

Efterretninger for skippere (NtS) er blevet gennemført i forskellige europæiske lande på grundlag af Kommissionens forordning (EF) nr. 416/2007 om tekniske specifikationer for efterretninger for skippere i henhold til artikel 5 i direktiv 2005/44/EF om harmoniserede flodinformationstjenester (RIS). NtS-standarden forbedres løbende, og et vigtigt skridt fremad var frigivelsen af NtS Web Service til udveksling af NtS-meddelelser mellem myndigheder samt mellem myndigheder og NtS-brugere samt af NtS XSD 4.0, der strømliner kodningen af NtS-meddelelser.

1.1. Formålet med NtS Encoding Guide

I NtS Encoding Guide redegøres for anvendelsen af de fire NtS-meddelelsestyper samt for koder, der skal anvendes i bestemte situationer. Vejledningen indeholder instruktioner til NtS-redaktører vedrørende udfyldning af NtS-meddelelser, hvilket skaber mulighed for en national og international harmoniseret kodning af NtS-meddelelser.

I betragtning af den øgede anvendelse af NtS Web Service vil NtS-meddelelserne blive yderligere harmoniseret for at sikre korrekt visning af indhold på tredjepartssystemer. En ensartet kodning af meddelelser er også en forudsætning for brug af meddelelser i rejseplanlægningsapplikationer. NtS Encoding Guide, version 1.0, finder anvendelse på NtS XSD 4.0 og NtS Web Service WSDL 2.0.4.0.

1.1.1. NtS Encoding Guide for redaktører

NtS Encoding Guide for redaktører er rettet til personale, der redigerer (og offentliggør) NtS-meddelelser, og indeholder trinvise instrukser om udarbejdelsen af de relevante meddelelsestyper og en forklaring af koder. Kodningsvejledningen for redaktører indeholder ligeledes relevante oplysninger til udviklere af applikationer.

1.1.2. NtS Encoding Guide for udviklere af applikationer (dette dokument)

NtS Encoding Guide for udviklere indeholder retningslinjer for gennemførelse af NtS-applikationer, og der redegøres for logik, processer og automatiske værdier/standardværdier.

2. NtS-meddelelser og afsnit

En NtS-meddelelse består af følgende afsnit:

— et identifikationsafsnit

— et afsnit, hvori de relevante objekter eller farvandsstrækninger, som meddelelsen vedrører, defineres

— et eller flere af følgende afsnit, afhængigt af meddelelsestype: — — begrænsninger for den farvands- og trafikrelaterede meddelelse — målinger for den vandstandsrelaterede meddelelse — isforhold for ismeldingen — vejrrapporter for vejrmeldingen.

Figur 2

Visualisering af NtS-meddelelsesstrukturen: obligatorisk element (1), obligatorisk element, der kan forekomme en eller to gange (1…2), obligatorisk element, der skal forekomme to gange (2), obligatoriske elementer, der kan forekomme så ofte som nødvendigt (1-n), obligatorisk element, der kan forekomme så ofte som nødvendigt (0…n)

Identifikationsafsnittet er obligatorisk og indeholder generelle oplysninger om informationskilde, afsender, offentliggørelsesdato, land og originalsprog og er at finde i de enkelte afsnit om de fire forskellige NtS-meddelelsestyper:

— Fairway and traffic related section: En »farvands- og trafikrelateret meddelelse« (FTM) genereres normalt af NtS-redaktører i overensstemmelse med NtS Encoding Guide for redaktører. Den vedrører vandvejsstrækninger defineret ved deres ISRS Location Codes for start og slut og/eller objekter på vandvejen defineret ved deres respektive ISRS Location Code. [gå til kapitel 6]

— Water level related section: En »vandstandsrelateret meddelelse« (WRM) anvendes til at give oplysninger om nuværende og prognosticerede vandstande samt andre oplysninger. En WRM genereres normalt automatisk (og regelmæssigt) baseret på sensormålinger eller infrastrukturstatus, der ikke kræver NtS-redaktørens interaktion. Afsnittet om vandstandsrelaterede meddelelser indeholder oplysninger vedrørende et objekt (f.eks. målestation) eller en farvandsstrækning (f.eks. mindste loddede dybde for en strækning, gældende ordning for et afsnit af en vandvej). Objektet defineres ved dets ISRS Location Code, og farvandsstrækningen defineres ved dens ISRS Location Codes for start og slut. [gå til kapitel 3]

— Ice related section: En »ismelding« (ICEM) indeholder oplysninger om isforholdene for en farvandsstrækning defineret ved dens ISRS Location Codes for start og slut. [gå til kapitel 4]

— Weather related section: En »vejrmelding« (WERM) anvendes til at give oplysninger om nuværende og prognosticerede vejrforhold på en vandvejsstrækning defineret ved dens ISRS Location Codes for start og slut. [gå til kapitel 5]

ISRS Location Code (International Ship Reporting Standard) bruges desuden til at definere den eller de objekter eller farvandsstrækninger, som meddelelsen vedrører.

ISRS Location Code er defineret i punkt 4.3 i bilaget til denne forordning.

3. WRM — grundlæggende betragtninger

Vandstandsinformation har stor betydning for såvel rejseplanlægning som sikkerhed. I øjeblikket findes der ikke nogen fælles standard for referencer til vandstandsinformation. Værdierne for profiler henviser til forskellige havniveauer eller til særlige referencepunkter. For at sikre en korrekt henvisning angives den pågældende »reference_code« altid sammen med værdien. WRM kan benyttes til at give følgende oplysninger:

— Vandstand (herunder prognoser)

— Mindste loddede dybde (herunder prognoser)

— Lodret frigang (herunder prognoser)

— Udledning (herunder prognoser)

— Dæmningsstatus

— Vandregime

Afklaring vedrørende oversættelser i regnearket »reference_code« er indeholdt i kapitel 7.11.

WRM genereres og offentliggøres normalt automatisk på grundlag af oplysninger fra sensorudstyr eller infrastruktur (f.eks. prognoser, dæmningsstatus). Der kan være forskellige mekanismer, der udløser en WRM-offentliggørelse, f.eks. periodisk offentliggørelse eller opnåelse af visse værdier.

3.1. Udfyldning af afsnittet nts_number i WRM

I NtS XSD 4.0 er det ikke obligatorisk at angive NtS-nummeret i WRM-meddelelser. Hvis nummeret angives, skal hvert nummer være unikt (Organisation/Year/Number/Serial) for den enkelte meddelelsestype, og den organisation, der udarbejder WRM, skal sikre, at numrene er unikke (organisationen er ikke forpligtet til at angive fortløbende numre).

3.2. Udfyldning af WRM, herunder prognoser

Som date_start for validity_period anføres dags dato (date_issue) og som date_end for validity_period anføres dagen efter date_issue.

For at oplyse om ændringer i f.eks. vandstand på en brugervenlig måde kan ændringen i forhold til en tidligere komparativ måling anføres i WRM-afsnittet om ændringer. Ud over ændringen af værdien (f.eks. –5 [cm]) skal tidsforskellen i forhold til den komparative måling ligeledes anføres.

I forbindelse med prognoser er »measure_date« den dato/det tidspunkt, som prognosen gælder for.

Vandstandsprognoser er altid forbundet med usikkerhed. Normalt beregnes modeller med forskellige parametre (f.eks. vejrudsigt), hvilket resulterer i forskellige prognosticerede vandstandsværdier. Med henblik på beregning af en minimal og maksimal prognosticeret værdi, f.eks. visualisering af et konfidensinterval for en vandstandsprognose, indeholder WRM-afsnittet om måling to supplerende valgfri datafelter.

Konfidensintervallet for en vandstandsprognose er illustreret i nedenstående figur:

Figur 3

Visualisering af konfidensintervallet for en vandstandsprognose: mest sandsynlig værdi (sort), konfidensintervallets øvre grænse (violet), konfidensintervallets nedre grænse (rød), målt vandstand (blå)

(X-aksen viser tiden, og y-aksen viser vandstanden i cm).

To elementer er tilgængelige i NtS XSD:

<value_min> konfidensintervallets laveste værdi

<value_max> konfidensintervallets højeste værdi

Ud over vandstandsprognoser kan konfidensintervallet også anvendes til at angive usikkerheden forbundet med offentliggjorte oplysninger om mindste loddede dybde og lodret frigang.

Konfidensintervallet value_min og value_max gør det muligt at angive konfidensintervaller for WRM-værdier via en standardiseret NtS WRM-meddelelse og anvende dem i grafer. Rådataene vises ikke til IWT-brugerne (f.eks. i kodeformat).

Measure_code »NOM« må ikke anvendes. Hvis der ikke foreligger nogen måling for en bestemt WRM-type, skal værdielementerne udelades, hvis en meddelelse sendes under alle omstændigheder.

4. ICEM-processer

Ismeldinger er baseret på lokale observationer og vurderinger og genereres normalt manuelt (ved automatisk generering skal reglerne for manuel generering følges, jf. NtS Encoding Guide for redaktører).

En ICEM offentliggøres for en bestemt fairway_section defineret ved dens ISRS Location Codes for start og slut, og den indeholder ice_condition på en bestemt dato for målingen.

En ICEM er gældende fra datoen for offentliggørelse (fastsættes automatisk i NtS-applikationen). For at undgå, at en ICEM, som ikke gælder længere, vises til brugerne, skal gyldighedsperiodens date_end udfyldes automatisk i NtS-applikationen med dagen efter publikationsdatoen (medmindre nationale processer sikrer, at meddelelsernes gyldighedsperiode ophører, så snart oplysningerne i meddelelsen ikke længere er ajourførte).

Der redegøres i NtS Encoding Guide for redaktører for, under hvilke omstændigheder en NtS-redaktør genererer en ny ICEM eller ajourfører en eksisterende ICEM. Processerne er som følger:

4.1. Ny ICEM

1) NtS-applikationer kan give NtS-redaktører mulighed for at:

a) anvende eksisterende meddelelser som udkast ved udarbejdelsen af en ny ICEM (f.eks. hvis isforholdene er de samme som i den eksisterende meddelelse) og/eller

b) anvende meddelelsesskabeloner i visse situationer.

2) Indholdet (f.eks. tidspunkt for måling eller de pågældende isforhold) skal indtastes af redaktøren i overensstemmelse med kapitel 6 i NtS Encoding Guide for redaktører. Datoen og tidspunktet for målingen kan også fastsættes i applikationen i henhold til nationale definitioner.

3) Når en NtS-redaktør eller -udgiver tager initiativ til offentliggørelsen, kontrolleres følgende:

a) alt obligatorisk indhold er angivet i overensstemmelse med NtS XSD (hvis ikke, gå tilbage til 2)),

b) nts_number genereres i NtS-applikationen

i) »organisation« udfyldes med den ansvarlige organisations navn eller kode, afhængigt af den offentliggørende brugers rolle

ii) »year« udfyldes med det indeværende år

iii) det næste tilgængelige »number« tildeles

iv) »serial number« 0 tildeles

c) »date_issue« udfyldes automatisk med den faktiske dato/tidspunktet for offentliggørelse

d) »validity_period« — »date_start« udfyldes automatisk med den faktiske dato for offentliggørelse

e) »validity_period« — »date_end« udfyldes automatisk med dagen efter publikationsdatoen (medmindre nationale processer sikrer, at meddelelsernes gyldighedsperiode ophører, så snart oplysningerne i meddelelsen ikke længere er ajourførte).

4.2. Ajourføring af en eksisterende ICEM

1) Den pågældende offentliggjorte meddelelse skal udvælges og ajourføres i ICEM-redigeringsredskabet. Den oprindelige ICEM skal kopieres eller ændres i DB (afhængigt af de nationale processer). En udløbet ICEM (hvor validity_date_end er overskredet) kan ikke længere ajourføres, og hvis dette er tilfældet, skal NtS-redaktøren generere en ny ICEM.

2) Indholdet (f.eks. tidspunkt for måling eller de pågældende isforhold) skal ændres af redaktøren i overensstemmelse med kapitel 6 i NtS Encoding Guide for redaktører. Datoen og tidspunktet for målingen kan også ændres i applikationen i henhold til nationale definitioner.

3) Når en NtS-redaktør eller -udgiver tager initiativ til offentliggørelsen, kontrolleres følgende:

a) alt obligatorisk indhold er angivet i overensstemmelse med NtS XSD (hvis ikke, gå tilbage til 2))

b) nts_number genereres i NtS-applikationen

i) »organisation« ændres ikke

ii) »year« ændres ikke

iii) »number« ændres ikke

iv) »serial number« forøges (med 1)

c) »date_issue« udfyldes automatisk med den faktiske dato/tidspunktet for offentliggørelse

d) »validity_period« — »date_start« udfyldes automatisk med den faktiske dato for offentliggørelse

e) »validity_period« — »date_end« udfyldes automatisk med dagen efter publikationsdatoen (medmindre nationale processer sikrer, at meddelelsernes gyldighedsperiode ophører, så snart oplysningerne i meddelelsen ikke længere er ajourførte).

5. WERM — grundlæggende betragtninger

WERM genereres og offentliggøres normalt automatisk på grundlag af oplysninger fra sensorudstyr eller infrastruktur. Som date_start for validity_period anføres dags dato (date_issue) og som date_end for validity_period anføres dagen efter date_issue.

Farvandsafsnittet i WERM er angivet som en strækning mellem to punkter i farvandet, dvs. vejrstationens (profilens) anvendelsesområde.

Dato og tidspunkt for måling/prognose skal angives, selv om det ikke er obligatorisk i WERM-meddelelser.

I forbindelse med prognoser er »measure_date« den dato/det tidspunkt, som prognosen gælder for.

5.1. Udfyldning af afsnittet nts_number i WERM

I NtS XSD 4.0 er det ikke obligatorisk at angive NtS-nummeret i WERM-meddelelser. Hvis nummeret angives, skal hvert nummer være unikt (Organisation/Year/Number/Serial) for den enkelte meddelelsestype, og den organisation, der udarbejder WERM, skal sikre, at numrene er unikke (organisationen er ikke forpligtet til at angive fortløbende numre).

5.2. Udfyldning af WERM »weather_category_code«

Vindhastigheden i »weather_category_code« (værdier 0-12) angives i overensstemmelse med Beaufortskalaen offentliggjort af Den Meteorologiske Verdensorganisation i håndbogen »Manual on Marine Meteorological Services«, WMO-No. 558.

Sigtbarheden i »weather_category_code« (værdier 13-22) angives som defineret i følgende tabel:







Værdi, betydning Sigtbarhed Supplerende oplysninger 13, tyk tåge under 50 m 14, tæt tåge under 100 m 15, moderat tåge under 200 m 16, tåge under 1 000 m Tåge i form af vanddråber 17, dis fra 1 km til 4 km Dis i form af vanddråber. Dis anvendes i tilfælde af »tør tåge«, og dette fænomen finder normalt sted før solopgang. 18, tågedis fra 1 km til 4 km Tågedis i form af tørre partikler 19, let tågedis fra 4 km til 10 km 20, klart fra 10 km til 20 km 21, meget klart fuld sigtbarhed 22, ingen tåge »Ingen tåge« bruges til at angive, at der ikke er nogen tåge, afhængigt af de nationale/lokale krav.

6. FTM-processer

Der redegøres i NtS Encoding Guide for redaktører for, under hvilke omstændigheder en NtS-redaktør generer en ny FTM eller ajourfører en eksisterende FTM. Processerne er som følger:

6.1. Ny FTM

1) NtS-applikationer kan give NtS-redaktører mulighed for at:

a) anvende eksisterende meddelelser som udkast ved udarbejdelsen af en ny FTM og/eller

b) anvende meddelelsesskabeloner i visse situationer.

2) Indholdet (f.eks. gyldighedstidspunkt eller begrænsninger) skal indtastes af redaktøren i overensstemmelse med kapitel 3 og 4 i NtS Encoding Guide for redaktører.

3) Når en NtS-redaktør eller -udgiver tager initiativ til offentliggørelsen, kontrolleres følgende:

a) alt obligatorisk indhold er angivet i overensstemmelse med NtS XSD (hvis ikke, gå tilbage til 2)),

b) nts_number genereres i NtS-applikationen

i) »organisation« udfyldes med den ansvarlige organisations navn eller kode, afhængigt af den offentliggørende brugers rolle

ii) »year« udfyldes med det indeværende år

iii) det næste tilgængelige »number« tildeles, og hvis et bestemt nummer blev indtastet af NtS-redaktøren eller en applikation i trin 2, overtages dette nummer (da (Organisation/Year/Number/Serial) er unikt som forklaret i kapitel Error! Reference source not found..

iv) »serial number« 0 tildeles

c) »date_issue« udfyldes automatisk med den faktiske dato/tidspunktet for offentliggørelse

6.2. Ajourføring/tilbagetrækning af en eksisterende FTM

1) Den pågældende offentliggjorte meddelelse skal udvælges og ajourføres i FTM-redigeringsredskabet, og den oprindelige FTM skal kopieres eller ændres i DB (afhængigt af de nationale processer).

a) En udløbet FTM (hvor validity_date_end er overskredet) kan ikke længere ajourføres, og hvis dette er tilfældet, skal NtS-redaktøren generere en ny FTM.

b) Emnekoden »Efterretning trukket tilbage« anvendes kun, hvis

i) dags dato ligger før validity_date_start. Hvis det kun er indholdet i feltet »Supplerende tekst på det nationale sprog«, som kan ændres, må meddelelsens kodede indhold (trin 2) ikke ændres.

ii) gyldighedsperioden allerede er indledt, og den nye slutdato for alle begrænsninger fastsættes til et tidligere tidspunkt. Slutdatoen for begrænsningen skal fastsættes korrekt.

c) Hvis en meddelelse trækkes tilbage, skal gyldighedsperiodens slutdato altid fastsættes til datoen for tilbagetrækning.

2) Indholdet (f.eks. gyldighedstidspunkt eller begrænsninger) skal ændres af redaktøren i overensstemmelse med kapitel 3 og 4 i NtS Encoding Guide for redaktører.

3) Når en NtS-redaktør eller -udgiver tager initiativ til offentliggørelsen, kontrolleres følgende:

a) alt obligatorisk indhold er angivet i overensstemmelse med NtS XSD (hvis ikke, gå tilbage til 2)),

b) nts_number genereres i NtS-applikationen

i) »organisation« ændres ikke

ii) »year« ændres ikke

iii) »number« ændres ikke

iv) »serial number« forøges (med 1)

c) »date_issue« udfyldes automatisk med den faktiske dato/tidspunktet for offentliggørelse

d) FTM med emnekode »Efterretning trukket tilbage« kan ikke (længere) anvendes til rejseplanlægning.

6.3. Vandvejs- og/eller objektrelateret FTM

En vandvejsrelateret FTM indeholder oplysninger om en eller flere vandvejsstrækninger. En vandvejsstrækning er defineret i farvandsafsnittet ved dens ISRS Location Codes for start og slut.

En objektrelateret FTM indeholder oplysninger om en eller flere specifikke objekter på vandvejen. Et objekt er defineret i objektafsnittet ved dets ISRS Location Code.

En FTM skal henvise til:

— en eller flere farvandsstrækninger eller

— en eller flere objekter på en eller flere farvandsstrækninger

6.4. Automatisk rangorden af begrænsningskoder

De forskellige begrænsninger har forskellige indvirkninger på sejladsen. For at gøre det muligt at angive den alvorligste begrænsning, f.eks. i en FTM- liste, tages følgende rangorden i betragtning med udgangspunkt i den alvorligste begrænsning med rangorden 1:







Rangorden Værdi Betydning (EN) 1 OBSTRU blokering 2 PAROBS partial obstruction 3 NOSERV no service 4 SERVIC changed service 5 VESDRA vessel draught 6 VESBRE vessel breadth 7 CONBRE convoy breadth 8 VESLEN vessel length 9 CONLEN convoy length 10 CLEHEI clearance height 11 VESHEI vessel air draught 12 AVALEN available length 13 CLEWID clearance width 14 AVADEP available depth 15 LEADEP least depth sounded 16 DELAY delay 17 ALTER alternate traffic direction 18 TURNIN no turning 19 PASSIN no passing 20 OVRTAK no overtaking 21 NOBERT no berthing 22 NOMOOR no mooring 23 ANCHOR no anchoring 24 SPEED speed limit 25 WAVWAS no wash of waves 26 NOSHORE not allowed to go ashore 27 MINPWR minimum power 28 CAUTIO special caution 29 NOLIM no limitation

6.5. Håndtering af begrænsningsperioder

— Begrænsninger med samme begrænsningsperioder bør grupperes/opføres sammen/kombineres af hensyn til læsevenligheden.

— NtS-redigeringsredskaber bør indeholde en funktion, som redaktører kan anvende for at undgå at genindtaste begrænsningsperioder.

— Begrænsningsperioder skal anføres for alle begrænsninger med en intervalkode, således at der kan foretages korrekte beregninger i rejseplanlægningsapplikationer. For at lette NtS-redaktørernes arbejde kan følgende funktioner gennemføres: — — NtS-redigeringsredskabet kan indeholde en funktion til at kopiere allerede indtastede begrænsninger, således at NtS-redaktøren ikke skal genindtaste begrænsningsperioden. — NtS-redigeringsredskabet kan indeholde en funktion til at vælge mere end en begrænsningskode for en specifik begrænsningsperiode og automatisk generere de nødvendige afsnit om begrænsning på grundlag af NtS-redaktørens indtastede oplysninger.

— »Mandag til fredag med undtagelse af helligdage«: Værdien »helligdage« er meget vanskelig at håndtere i rejseplanlægningsapplikationer. En liste over helligdage for hvert land er nødvendig for at foretage en korrekt beregning. Hvis en sådan liste ikke findes, vil de pågældende begrænsninger ikke desto mindre blive tillagt helligdagene.

— »med undtagelse af«: må ikke anvendes. Afbrudte tidsintervaller skal anføres som særskilte begrænsningsperioder i den samme begrænsning, og denne kode må derfor ikke være synlig/tilgængelig for redaktører af efterretninger.

— Logik og visning af oplysninger i forbindelse med intervalkoden »kontinuerligt«: — <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> — Hvis interval_code er »kontinuerligt«, hører start_time sammen med start_date, og end_time hører sammen med end_date, f.eks. fra 1. april 06:00 til 30. juni kl. 10:00.

— Logik og visning af oplysninger i forbindelse med enhver anden intervalkode end »kontinuerligt«: — <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> — Hvis interval_code har en anden værdi, hører start_time og end_time til denne interval_code, f.eks. fra 1. april til 30. juni, mandag til fredag fra 06:00 til 10:00.

— Begrænsningsperiodens sluttidspunkt skal altid angives i den sidste version af en meddelelse.

7. Almindelige gennemførelsesbestemmelser

Følgende skal tages i betragtning:

— Tabellen »GUI_labels« i NtS Reference Tables skal tages i betragtning i forbindelse med udviklingen af NtS-applikationer (søgemasker, e-mail-abonnementsformular, visning af meddelelser).

— Date_end kan ikke ligge før date_start.

— Koder, som er blevet deaktiveret (ikke anvendes længere) via NtS-ændringsanmodninger (se bemærkningerne i NtS XSD), må ikke være synlige for NtS-redaktører efter generering af nye meddelelser. Koderne er fortsat opført på NtS XSD-listerne med henblik på bagudrettet kompatibilitet.

7.1. Udfyldning af »number_section«

Hvert nummer (Organisation/Year/Number/Serial) skal være unikt for den enkelte meddelelsestype. Det betyder, at meddelelser af forskellige typer kan have samme NtS-nummer.

For brugere er meddelelsesnumrene kun relevante for FTM og ICEM, og for alle andre meddelelsestyper kan visning af meddelelsesnummeret udelades, afhængigt af de nationale krav.

For brugere angives meddelelsesnummeret i følgende format: »Message Type/Country/Organisation/Year/Number/Serial« (det kan afkortes, afhængigt af anvendte filtre, hvis oplysninger ikke går tabt).

7.2. Udfyldning af elementerne »from«, »originator«, »organisation« og »source«

Elementet »from« i identifikationsafsnittet udfyldes med navnet på det nationale system, som genererer meddelelsen (f.eks. ELWIS, DoRIS, SLOVRIS, FLARIS).

Elementet »originator« er den organisation, som indtaster meddelelserne i de nationale systemer.

Elementet »source« er den myndighed, på hvis vegne FTM'en offentliggøres.

Elementet »organisation« i afsnittet nts_number er navnet på den organisation, der tildeler nts_number (NtS-udbyder).

7.3. Udeladelse af elementer

Elementer, der kun indeholder standardværdier, skal udelades. Hvis de er betingede, resulterer de i for mange meddelelser uden merværdi.

Der er tale om følgende elementer:

— Målgruppe: target_group_code ALL med direction_code ALL (hvis der ikke er andre specifikke målgrupper i meddelelsen)

— position_code: AL

— reason_code: OTHER.

7.4. Automatisk udfyldning af date_issue

FTM og ICEM

For FTM og ICEM er elementet date_issue den faktiske dato og tidspunktet for offentliggørelse. For ajourførte meddelelser er date_issue datoen og tidspunktet for offentliggørelse af ajourføringen.

WRM og WERM

For WRM og WERM er værdien af elementet date_issue datoen og tidspunktet for behandling af anmodningen, da der kan være flere målinger med forskellige tidsstempler i en W(E)RM-meddelelse.

7.5. Håndtering af tidszoneoplysninger i NtS-meddelelser

Dato og tidspunkt skal altid angives i lokal tid, herunder tidszoneoplysninger i NtS XML-meddelelser.

De eneste undtagelser fra denne bestemmelse er »time_start« og »time_end« i afsnittet om »limitation_period«. Dette skyldes, at der kan angives et interval i afsnittet om begrænsning. Hvis startdato og slutdato er omfattet af forskellige tidsordninger (f.eks. CEST og CET), vil dette resultere i en ændring af tidszoneoplysningerne for dette interval. Denne ændring kan angives ved hjælp af en enkelt begrænsningsperiode. I stedet for at fastsætte forskellige begrænsningsperioder for hver tidsændring fastsættes blot en enkelt begrænsningsperiode uden tidszoneoplysninger for at lette behandlingen og fremsendelsen af meddelelser.

7.6. Håndtering af sekunder i NtS-meddelelser

Som hovedregel skal sekunder anføres i felter for (dato)/tidspunkt, men de skal ikke være synlige for NtS-brugere. Minutter er en tilstrækkelig detaljeringsgrad for NtS-meddelelser.

7.7. Decimalformat i NtS-meddelelser

Decimaler i numeriske felter angives med et . (punktum). Der bruges ikke tusindadskillere.

Antallet af decimaler for værdier skal begrænses til et realistisk antal for at sikre brugervenlig visning.

7.8. Enheder, der skal anvendes i NtS-meddelelser

Kun enhederne cm, m3/s, h, km/h og kW, m/s (vind), mm/h (regn) og grader celsius må benyttes i NtS-meddelelser, men enhederne kan konverteres i applikationer af hensyn til brugervenligheden.

Hvis inputenhederne afviger fra standardenhederne, skal de indtastede værdier konverteres i applikationen i overensstemmelse hermed.

7.9. Regler for elementerne »name«, »position_code« og »type_code«

Elementet »name« forhåndsudfyldes automatisk med referencedata fra RIS Index »national object name« (NtS-redaktører kan ændre det forhåndsudfyldte navn, hvis dette er et nationalt krav). Navngivningskonventioner for objektnavne er anført i RIS Index Encoding Guide version 2.0 eller højere. Eksempler på korrekte objektnavne er ligeledes anført i NtS Encoding Guide for redaktører.

Typekoden tilføjes objektet i NtS-applikationen foran objektets navn.

Objektets position kodes ved brug af positionskode og tilføjes objektet i NtS-applikationen på grundlag af RIS Index. Redaktører kan ændre forhåndsudfyldte type- og positionskoder. Der angives ikke positionskode for objekter i geo_objects i fairway_section.

Objektets fulde navn består af en positionskode, en typekode og et navn.

For at lette NtS-redaktørernes arbejde kan følgende kortlægning gennemføres i NtS-redigeringsredskaber til støtte for redaktørernes søgning efter og udvælgelse af de korrekte objekter på grundlag af RIS Index function_code eller NtS-type_code:

Tabel 1

Matching »RIS Index function_code« — »NtS type_code«







Function Code Function Code Meaning Type Code Type Code Meaning — — BUAARE E.1.1 Built-Up Areas to be selected by editor BUISGL E.1.2 Building of Navigational Significance to be selected by editor brgare G.1.1 - G.1.6 Bridge Area [C_AGGR()] BRI bridge bridge_5 G.1.1 Bascule Bridge BRO bridge opening bridge_1 G.1.2 Bridges with Bridge Arches BRO bridge opening bridge_1 G.1.3 Fixed Bridge BRO bridge opening bridge_4 G.1.4 Lift Bridge BRO bridge opening bridge_12 G.1.5 Suspension Bridge BRO bridge opening bridge_3 G.1.6 Swing Bridge BRO bridge opening cblohd G.1.8 Overhead Cable CAB cable overhead pipohd G.1.9 Overhead Pipe PPO pipeline overhead bridge_7 G.1.12 Drawbridge BRO bridge opening bunsta G.3.2 Bunker / Fuelling Station BUS Bunker / Fuelling Station cranes G.3.4 Crane to be selected by editor hrbare G.3.9 Harbour Area HAR harbour hrbbsn G.3.10 Harbour Basin HAR harbour ponton G.3.11 Landing Stage, Pontoon to be selected by editor morfac G.3.12 Mooring Facility MOO mooring facility hulkes G.3.14 Permanently Moored Vessel or Facility to be selected by editor prtare G.3.15 Port Area HAR harbour refdmp G.3.17 Refuse Dump REF refuse dump termnl G.3.19 Terminal TER terminal trm01 G.3.19 RORO-terminal TER terminal trm03 G.3.19 Ferry-terminal TER terminal trm07 G.3.19 Tanker-Terminal TER terminal trm08 G.3.19 Passenger Terminal TER terminal trm10 G.3.19 Container Terminal TER terminal trm11 G.3.19 Bulk Terminal TER terminal vehtrf G.3.20 Vehicle Transfer Location BER berth lokbsn G.4.3 Lock Basin LKB lock basin lkbspt G.4.4 Lock Basin Part LKB lock basin lokare G.4.3 / G.4.4 Lock Area [C_AGGR()] LCK lock excnst G.4.8 Exceptional Navigational Structure SLI ship lift TUN tunnel CBR canal bridge gatcon G.4.9 Opening Barrage BAR weir FLO flood gate wtwgag I.3.4 Waterway Gauge GAU tide gauge FERYRT_2 L.2.1 Cable Ferry FER ferry FERYRT_1 L.2.2. Free Moving Ferry FER ferry feryrt_4 L.2.3. Swinging Wire Ferry FER ferry dismar L.3.2 Distance Mark along Waterway Axis RIV river achare M.1.1 Anchorage Area ANC anchoring area achbrt M.1.2 Anchorage Berth BER berth berths_3 M.1.3 Berth / Fleeting Areas BER berth berths_1 M.1.4 Transhipment Berth BER berth trnbsn M.4.5 Turning Basin TUR turning basin CAN canal FWY fairway rdocal Q.2.1 Radio Calling-In Point (notification point) REP reporting point chkpnt R.1.1 Check Point BCO border control sistat_8 R.2.1 Traffic Sistat — Bridge Passage SIG signal station sistat_6 R.2.2 Traffic Sistat — Lock SIG signal station sistat_10 R.2.3 Traffic Sistat — Oncoming Traffic Indicator SIG signal station sistat_2 R.2.4 Traffic Sitat — Port Entry and Departure SIG signal station pas Passage Points to be selected by editor riscen RIS centre VTC vessel traffic centre specon Special Construction to be selected by editor trafp Traffic Points (first reporting points) REP reporting point junction Waterway node / end of waterway / Junction to be selected by editor waypt Waypoint to be selected by editor Legend: green Direct match (1:1 relation) yellow matching example, other TypeCodes possible (1:n relation) blue no direct match / to be selected by editor

7.10. Regler for elementet »fairway_name«

For at undgå applikationslogik/krav til det modtagende system med hensyn til passende referencedata (software, der viser efterretningen til brugeren), skal det valgfri element »fairway_name« altid inkluderes i »geo_object« og forhåndsudfyldes automatisk i NtS-applikationen med »Waterway name« fra RIS Index. NtS-redaktører må ikke ændre indholdet af elementet fairway_name.

7.11. Afklaring vedrørende oversættelser i regnearket »reference_code«

Følgende definition anvendes for reference_code-værdierne i NtS Reference Tables:

— NAP: I Nederlandene anvendes og forstås forkortelsen NAP, NAP oversættes ikke

— KP: »kanalniveau« oversættes således på det nationale sprog

— FZP: kun forkortelsen »FZP« anvendes (i dag næsten ikke længere anvendt)

— ADR: »Adriaterhavet« oversættes således på det nationale sprog

— TAW/DNG: »Tweede algemene waterpassing« (nederlandsk) — »Deuzième Nivellement Général« (fransk) er den referencehøjde, der anvendes i Belgien til at udtrykke højdemålinger. 0 er den gennemsnitlige vandstand ved lavvande i Oostende — — Nederlandsk: TAW — Fransk: DNG — Alle andre sprog: TAW/DNG

— LDC: »lav vandstand defineret af Donau-kommissionen« oversættes således på det nationale sprog

— HDC: »høj vandstand defineret af Donau-kommissionen« oversættes således på det nationale sprog

— ETRS: »European Terrestrial Reference System 1989« — forkortelsen »ETRS89« anvendes på alle sprog

7.12. Anbefaling vedrørende elementet »koordinat«

Selv om elementet koordinat i afsnittet om geografiske objekter er betinget, anføres de geografiske koordinater i WGS84 i formatet [d]d mm.mmm[m] N (latitude) og [d][d]d mm.mmm[m] E (longitude). Formålet er at henvise til NtS-meddelelserne geografisk.

7.13. Håndtering af målgrupper

Afsnittet om målgruppe indeholder koden for målgruppe og koden for sejlretning. Hvis begge har værdien ALL, udelades hele afsnittet, hvis der ikke er andre specifikke målgrupper i meddelelsen. Hvis blot en af disse to angives, skal den anden udfyldes med standardværdien ALL, da begge elementer er obligatoriske.

Yderligere oplysninger om målgrupper kan findes i NtS Encoding Guide for redaktører.

7.14. Visning af gældende meddelelser på et bestemt tidspunkt

validity_period anvendes i applikationer til at udvælge de meddelelser, som skal vises til brugerne for et ønsket tidspunkt.

Hvis subject_code er INFSER (informationstjeneste), bruges gyldighedsperioden til at angive det tidspunkt, hvor informationstjenestens meddelelse vises til brugerne, og ikke til at angive de fremlagte oplysningers gyldighedsperiode (f.eks. 1 måned).

7.15. Valgfri funktioner, der øger brugervenligheden af NtS-redigeringsredskaber

NtS-redaktører kan få adgang til følgende funktioner, afhængigt af de nationale krav:

— NtS-redaktører kan få adgang til at gemme udkast til NtS-meddelelser i NtS-applikationer (uden angivelse af alt obligatorisk indhold for at gemme udkast til meddelelser).

— Forskellige brugerroller kan tildeles forskellige redaktører (redaktører, der kan indtaste/ændre meddelelser, udgivere, der kan offentliggøre meddelelser (som supplement til redigering)

8. NtS XML-meddelelsesstruktur

NtS XML-meddelelsesstrukturen og indholdet af og formålet med dataelementerne er defineret og nærmere forklaret i tillæg C: NtS XML Schema Definition (XSD)

9. NtS Web Service

9.1. Mål

NtS-ekspertgruppen har vurderet, at webtjenesteteknologi er et hensigtsmæssigt middel til tilvejebringelse af efterretningerne for skippere.

Dette kapitel indeholder specifikationer for webtjenesten til tilvejebringelse af efterretninger for skippere, dvs. NtS Web Service. Der er lagt særlig vægt på anvendelsen af almindeligt anerkendte internationale standarder.

Et mål for systemdesignet var at sikre en god balance mellem webtjenestens fleksibilitet og robusthed. Filterparametrene i anmodningerne er hovedsagelig de fastsatte kriterier i NtS-standarden (vandvejsafsnit med valgfri angivelse af flod-km, gyldighedstidspunkt, publikationsdato for efterretningen). Dette synes tilstrækkeligt i betragtning af erfaringerne med webtjenesten og begrænser samtidig gennemførelsens kompleksitet.

Det centrale resultat er en kontrakt vedrørende webtjenesten med specifikationer for anmodninger og svar. Brugere af webtjenesten kan påberåbe sig denne kontrakt, og udbyderne skal overholde den. Denne kontrakt er specificeret ved brug af den internationale standard WSDL.

Hver deltagende medlemsstat implementerer en eller flere webtjenester for de forskellige NtS-meddelelsestyper (FTM, WRM, ICEM, WERM) og stiller dem til rådighed via internettet (»NtS Message Service«).

De tekniske detaljer vedrørende gennemførelsen af NtS WS, f.eks. valg af passende datapuljer, applikationer og platforme, er ikke omfattet af denne specifikation, og ansvaret herfor påhviler de enkelte deltagende medlemsstater.

I forbindelsen med tilvejebringelsen af en sikker kommunikation skal der tages hensyn til forskellige sikkerhedsaspekter og beskyttelsesrelaterede mål. Der skal ikke altid tages hensyn til alle disse aspekter, da det afhænger af omstændighederne. Prioriteringen af de forskellige sikkerhedsaspekter og graden af deres opfyldelse kan variere. Gennemførligheden af en bestemt foranstaltning kan ligeledes være begrænset af den tekniske gennemførelseskapacitet. I forbindelse med NtS er alle oplysninger offentligt tilgængelige. Der er derfor ikke behov for at sikre NtS-dataene i databeskyttelsesmæssig henseende. Den enkelte udbyder skal derfor selv afgøre, i hvor høj grad dette aspekt skal gennemføres i den pågældende tjeneste.

9.2. Grundlæggende principper og krav

9.2.1. Webstandarder

NtS Web Service skal overholde WS-I Basic Profile 1.1. Denne profil »indeholder retningslinjer for interoperabilitet for et sæt centrale generiske webtjenestespecifikationer såsom SOAP, WSDL og UDDI« ( 4 ). De mest relevante standarder heri er:

— XML Schema Definition (XSD),

— Simple Object Access Protocol (SOAP),

— Web Services Description Language (WSDL)

— Universal Description, Discovery and Integration (UDDI).

NtS WS-svarmeddelelsen er en NtS-meddelelse, der er defineret i XML Schema Definition (XSD) i tillæg C til denne forordning fra Kommissionen.

SOAP er en applikationsprotokol for datatransmission mellem IT-systemer og er standardiseret af World Wide Web Consortium (W3C). De specifikke elementer for NtS Web Service er defineret i de tilknyttede WSDL-specifikationer i tillæg D til denne forordning fra Kommissionen. NtS-skemastandarden (XSD) er ledsaget af en vigtig erklæring

UDDI (Universal Description, Discovery and Integration) fremhæves her som et centralt, formodentligt internationalt register for webtjenester, som NtS Web Service kunne blive registreret i. I dette register kan potentielle forbrugere af webtjenesten søge og finde tjenesten. Da antallet af potentielle udbydere af NtS Web Service afhænger af antallet af deltagende medlemsstater, og da WSDL-specifikationen er en integrerende del af standarden, er der imidlertid ikke umiddelbart behov for en uafhængig registrering af NtS Web Service.

9.2.2. Interaktionsmodel og kodningsmetode for NtS WS

Kodningsmetoden »Document-literal wrapped« anvendes i forbindelse med NtS Web Service, da den gør det muligt at foretage en validering på grundlag af et XML-skema, og de operationelle navne, der er defineret i WSDL-specifikationen, anvendes direkte som XML-tagnavne i SOAP-meddelelserne.

9.3. Generelle specifikationer og anbefalinger

9.3.1. Specifikation: Versionsoplysninger

Versionsoplysningerne vedrørende NtS Web Service er opdelt i to afsnit:

— selve webtjenesteversionen

— den version af NtS-skemaet, der anvendes af webtjenesten

Afsnittet om selve webtjenesten er opdelt i to dele:

— den store version af webtjenesten

— den mindre version af webtjenesten

Den store version er angivet som et positivt heltal for den store version af webtjenesten.

Den mindre version er angivet som et ikkenegativt heltal for den mindre version af webtjenesten i den store version.

Afsnittet vedrørende NtS-skemaet indeholder den version af NtS-skemaet, som er defineret af NtS-ekspertgruppen.

Den version af NtS Web Service, der er specificeret her, er således version 2.0.4.0, hvor version 2.0 er selve webtjenesteversionen, og version 4.0 er den anvendte version af NtS-skemaet.

Det er ikke nødvendigt at anføre versionsoplysninger i forespørgsler eller svar fra NtS Web Service. Det forventes kun, at få versioner af tjenesterne vil være online på samme tid. De forskellige versioner skal have forskellige URL-adresser. Hver instans i en NtS Web Service-gennemførelse skal således understøtte en specifik version af NtS Web Service.

9.3.2. Specifikation: Navneområdestruktur

Navneområder i NtS Web Service er baseret på RIS-ekspertgruppernes websted: http://www.ris.eu/.

Navneområderne indeholder en partikel, der angiver den tilknyttede tjeneste og versionsoplysninger. For den specificerede tjeneste anvendes således følgende navneområder:

NtS-meddelelsestjeneste: http://www.ris.eu/nts.ms/2.0.4.0

9.3.3. Anbefaling: Brug af navneområder

For at øge XML-dokumenters gennemsigtighed anbefales det at definere navneområderne i det mest hensigtsmæssige element i skemaerne samt i dokumenter og undlade at anvende lokale definitioner af navneområder i indlejrede elementer.

9.3.4. Anbefaling: Brug af navneområdepræfikser

I anmodninger og svar i NtS Web Service anvendes XML-elementer i kvalificeret form, dvs. med et eksplicit navneområdepræfiks, og XML-attributter i ukvalificeret form, dvs. uden et navneområdepræfiks.

Det anbefales at bruge intuitive navneområdepræfikser såsom »nts« af hensyn til læsbarheden.

9.3.5. Specifikation: Brug af ISRS Location Codes

ISRS Location Code er forklaret i kapitel 2 i NtS Encoding Guide for udviklere af applikationer samt i RIS Index Encoding Guide.

Ved søgning i en NtS Web Service kan kunden søge forskellige objekter, f.eks. farvandsafsnit, profiler eller sluser. Hvis de tilsvarende parametre — ID-elementerne — anvendes, skal de indeholde ISRS Location Codes. Disse parametre angives typisk i ID-elementer, som hver indeholder en eller to ID-elementer.

Ved brug af disse parametre skal følgende generelle konventioner overholdes:

— ISRS Location Codes skal angives med 20 tegn, dvs. uden afkortning med efterstillede nuller.

— Hvis to ID-elementer anvendes i et ID-element, skal begge ISRS Location Codes vedrøre den samme vandvej. Dette betyder, at koderne indeholder en række identiske cifre fra fairway_section-delen i ISRS Location Code. Koden for farvandsstrækning samt farvandshektometeren definerer en vandvejsstrækning angivet som et par ID-elementer.

I forbindelse med vandvejsstrækninger (et par ID-elementer i fairway_section geo_object) i NtS-meddelelser skal følgende tages i betragtning i forhold til ISRS Location Codes:

— 1-2 cifre (Country code): — — skal være identiske i ID-parret — Forskellige landekoder kan imidlertid defineres i et ID-par, hvis tilgrænsende lande benytter samme kode for farvandsstrækning for en bestemt vandvej og det samme system til fastlæggelse af hektometer.

— 3-5 cifre (UN Location code): — — er ikke relevante, indholdet i ID-parret kan være forskelligt.

— 6-10 cifre (Fairway section code): — — skal være identiske i ID-parret, men — [undtagelse]: Hvis de belgiske ISRS-koder anvendes i NtS WS, bør der kun benyttes cifrene 6-8 til at identificere farvandsafsnittet, da NtS-meddelelserne vil blive offentliggjort for forskellige afsnit i et farvand.

— 11-15 cifre (Object Reference Code): — — er ikke relevante, indholdet i ID-parret kan være forskelligt.

— 16-20 cifre (Fairway Hectometre): — — Består af fem cifre, der definerer hektometeren, og indholdet i ID-parret vil således normalt være forskelligt. Eksempel: »00235« for farvand 23,5 km, »00001« for farvand 0,1 km — [undtagelse]: I Nederlandene er der ikke altid en direkte forbindelse mellem farvandshektometeren og farvandets fysiske kilometer på grund af definitionen af farvandsstrækningens start i netværksmodellen og i den virkelige verden. I sådanne tilfælde begynder objektreferencekoden for objekter af typen »dismar« med Kxxxx (xxxx omfatter de fysiske kilometer, f.eks. NLSVG00130K000300191 (3 km)). For andre objekttyper er der imidlertid ingen direkte forbindelse til farvandets fysiske kilometer i ISRS-koderne. Broen Sas van Gent i samme farvand på 2,5 km har f.eks. ISRS-koden NLSVG001300521600186. For Kanaal Gent-Terneuzen beregnes den fysiske 0,0 km fra grænsen mellem Belgien og Nederlandene, og farvandshektometeren 0,0 beregnes fra starten af kanalen i Gent.

Hvis en meddelelse vedrører mere end en vandvejs- eller farvandsstrækning, skal alle farvandsstrækninger defineres ved deres start- og slutpunkter i særskilte XML-elementer i »fairway_section«.

For nogle lande/regioner er det nødvendigt at opbygge filterfunktionalitet. Hvis ISRS Location Code (1-2) er BE, anvendes ISRS Location Code (6-8) som ID for lineær referering med farvandshektometeren (ISRS Location Code 16-20). Eksempler på farvandsstrækninger (gyldige ID-elementpar i fairway_section), der omfatter de ovenfor definerede undtagelser:

— De to NL ISRS Location Codes er en gyldig definition af en vandvejstrækning (NL-undtagelse med hensyn til farvandet i km): NLSVG00130K000300191 (3,0 km, Sas van Gent på Kanaal Gent-Terneuzen) — NLWDP00130K000400200 (4,0 km, Westdorpe på Kanaal Gent-Terneuzen),

— De to BE ISRS Location Codes er en gyldig definition af en vandvejstrækning (BE-undtagelse med hensyn til fairway section code (»020« Albertkanaal)): BEGNK02016L010100414 (Genk-slusen i en afstand af 41,4 km på Albert Canal) — BEOSH02033L010500772 (Ham-slusen i en afstand af 77,2 km på Albert Canal).

Følgende figur viser modeksempler på anvendelsen af ISRS Location Code for de enkelte generelle konventioner (ingen undtagelser fra de generelle konventioner for vandvejsstrækninger i SK):

Ugyldige ISRS Location Code-søgninger

Generel bemærkning: En tjeneste til at søge efter gældende ISRS Location Codes er ikke understøttet af NtS Web Service. ISRS Location Codes er angivet i det europæiske system til forvaltning af referencedata (ERDMS).

Den korrekte anvendelse af ISRS Location Codes i søgninger og fortolkningen heraf fremgår af følgende fem eksempler.

Eksempel 1: Intet ID-element i anmodning

ID-elementet er en valgfri del af anmodningen, og der kan således foretages en søgning uden ID-elementer:

Gyldig søgning uden ID-parameter

Hvis der ikke angives et ID-element, returneres alle meddelelser (naturligvis afhængigt af andre filterkriterier såsom validity_period eller date_issue).

Eksempel 2: Et ID-element i anmodning

Hvert ID-element kan indeholde et enkelt eller to ID-elementer. Et ID-element er vist i følgende figur:

Gyldig søgning med en ID-parameter

Ved modtagelsen af en sådan søgning returnerer serveren alle matchende meddelelser med en starthektometer ≤ den pågældende værdi (240,7 i eksemplet) og en hektometer ≥ denne værdi. Figuren nedenfor viser denne udvælgelse af meddelelser: Den søgte position ligger mellem start- og sluthektometerværdierne for meddelelse 1, 3 og 4, der vil blive returneret. Meddelelse 2, 5 og 6 overlapper ikke den søgte position, og de vil derfor ikke blive returneret.

Hvis den pågældende ISRS Location Code betegner et særligt objekt, f.eks. en profil eller en sluse, bør webtjenesten returnere de meddelelser, som vedrører dette objekt.

Matchende og ikkematchende meddelelser for en ID-parameter

Eksempel 3: To ID-elementer i anmodning

Hvert ID-element kan indeholde et enkelt eller to ID-elementer. Et eksempel med to ID-elementer er vist i følgende figur:

Gyldig søgning med to ID-parametre

Alle søgte hektometerværdier betragtes som gyldige, selv om den tilsvarende farvandsstrækning har forskellige start- eller slutpunkter. Hvis farvandsstrækningen f.eks. starter ved hektometer 100,0 og slutter ved hektometer 300,0 , vil en søgning i intervallet 20,0 -400,0 hektometer være gyldig. Internt er det naturligvis kun den »reelle« udstrækning af farvandsafsnittet, der søges.

Dette gør det også muligt at søge alle meddelelser om et farvand uden at kende den nøjagtige hektometer (ISRS Location Code fremsendes med hektometer sat til henholdsvis »00000« eller »99999«).

Alle matchende meddelelser, der skærer det pågældende hektometerinterval, returneres. Diagrammet nedenfor illustrerer denne situation:

Matchende og ikkematchende meddelelser for to ID-parametre

Ovenstående figur viser, hvordan »skæring« defineres. Selv om omfanget af meddelelse 1-4 overlapper omfanget af det søgte hektometerinterval (helt eller delvist), er dette ikke tilfældet for meddelelse 5 og 6, og meddelelse 1-4 vil således blive returneret, og meddelelse 5 og 6 vil ikke blive returneret.

Den tekniske betingelse for, at en meddelelse skærer et interval [A og B]: Starthektometeren i meddelelsens er ≤ B og sluthektometeren er ≥ A.

Kombinering: Flere ID-elementer i anmodning

Gyldig søgning med flere ID-elementer

Ved at kombinere flere ID-elementer i anmodningen forenes tilsvarende meddelelser. Alle ID-elementerne behandles individuelt, og en meddelelse vil blive returneret, hvis den matcher mindst et af dem. Følgende meddelelser ville derfor blive returneret i det pågældende eksempel:

— Alle meddelelser vedrørende objektet med ISRS Location Code SKXXX0000010000***** med starthektometer =0 og sluthektometer ≥ 0 (se eksempel 2)

— Alle meddelelser vedrørende objektet med ISRS Location Code SKXXX0000500000*****, der skærer hektometerintervallet [11,0 , 15,0 ] (se eksempel 3)

— Alle meddelelser vedrørende objektet med ISRS Location Code SKXXX0000200000***** med starthektometer = 110,5 og sluthektometer ≥ 110,5 (se eksempel 2)

— Alle meddelelser vedrørende objektet med ISRS Location Code SKXXX0000500000*****, der skærer hektometerintervallet [220,0 , 300,0 ] (se eksempel 3)

9.4. NtS-meddelelsestjeneste (gennemførelsesspecifikation)

I dette kapitel redegøres for gennemførelsesspecifikation for NtS-meddelelsestjenesten, udledt af betragtningerne og valgene i de foregående kapitler.

NtS-meddelelsestjenesten tilvejebringer de fire NtS-meddelelsestyper:

1. NtS FTM (farvands- og trafikrelateret meddelelse)

2. NtS WRM (vandstandsrelateret meddelelse)

3. NtS ICEM (ismelding)

4. NtS WERM (vejrmelding)

En gennemførelse af NtS-meddelelsestjenesten kan understøtte alle meddelelsestyper eller et udvalg. En deltagende medlemsstat kan tilvejebringe flere tjenester for en specifik meddelelsestype, der supplerer hinanden.

9.4.1. Anmodning

For at sikre en maksimalt robust tjeneste og samtidig sikre en lav kompleksitet anvendes der ikke yderligere søgesprog i NtS Web Service, idet WSDL anvendes. Alle de specifikke operationer og deres parametre er defineret i WSDL-specifikationen. Der er defineret en enkelt operation for NtS-meddelelsestjenesten.

De emnespecifikke filterkriterier er baseret på NtS-standarden, om end de er blevet udvidet som følge af de mange forskellige parametre:

— meddelelsestype (obligatorisk: »FTM«, »WRM«, »ICEM« eller »WERM«)

— specifikke vandvejsafsnit eller dele deraf eller bestemte objekter (valgfrit — angivet ved enkelte ISRS Location Codes og/eller par af ISRS Location Codes)

— gyldighedstidspunkt (valgfrit — startdato og slutdato)

— publikationsdato for efterretningen (valgfrit — enkelte datoer og/eller datointervaller)

Tjenesten returnerer kun de meddelelser, der opfylder de pågældende kriterier.

Paging-mekanisme

For at kontrollere mængden af data understøttes en paging-mekanisme. Paging-parameteren er defineret med en kompleks type, der indeholder følgende elementer:

— offset: serienummer for den første returnerede meddelelse (integer ≥ 0)

— limit: maks. antal meddelelser (integer ≥ 0)

— total count: flag, hvis samlede antal meddelelser returneres (Booleanværdi)

Den komplekse paging-parameter er valgfri, men hvis den anvendes, skal alle elementerne tages i betragtning. Paging-mekanismen fungerer på følgende måde:

Det samlede antal meddelelser må ikke overstige værdien af parameteren limit, men en værdi på 0 betyder »ingen grænse«. Svaret skipper så mange meddelelser som defineret i parameteren offset. For at tilvejebringe denne mekanisme skal tjenesten observere en midlertidigt stabil (men vilkårlig) sekvens af meddelelserne, f.eks. mellem to ajourføringer af meddelelsesdata om webtjenestens underliggende datasæt. Dette betyder, at to på hinanden følgende identiske anmodninger skal returnere de samme meddelelser i samme rækkefølge. Parameteren total count afgør, om svaret skal indeholde det samlede antal meddelelser, der matcher de emnespecifikke kriterier. Normalt bør det være tilstrækkeligt at anmode om disse oplysninger i forbindelse med det første svar, men at udelade det i alle efterfølgende svar. Dette bør sikre en mere effektiv webtjeneste.

Paging-mekanismen giver mulighed for at anmode om meddelelser iterativt i »sider«. Hvis paging-mekanismen skal fungere korrekt, skal de samme emnespecifikke parametre angives i hver anmodning.

9.4.2. Svar

En anmodning er vellykket, når svaret fra NtS Web Service indeholder de NtS-meddelelser, der matcher parametrene i anmodningen. NtS-meddelelserne skal overholde NtS-skemaet og kan valideres i forhold til dette skema. Da meddelelsestypen er en obligatorisk parameter i anmodningen, kan hvert enkelt svar kun indeholde NtS-meddelelser af samme meddelelsestype, nemlig FTM, WRM, ICEM eller WERM.

Hvis tjenesten opdager fejl under behandlingen af anmodningen, kan den returnere et vilkårligt antal fejlmeddelelser ved brug af de fejlkoder, der er anført i nedenstående underkapitel.

Et svar fra en NtS Web Service kan både indeholde NtS-meddelelser og fejlmeldinger.

Valgfri paging-oplysninger returneres, hvis anmodningen indeholder paging-parametre. I så fald er offset og antal meddelelser obligatorisk, men totaltælling skal kun anføres, hvis der er anmodet herom.

Bemærk: Det antages, at kommunikationen mellem webtjenesten og brugeren er etableret teknisk, således at tjenesten modtager anmodningen og brugeren det tilknyttede svar. Der ses bort fra tekniske fejl, f.eks. brud på internetforbindelsen eller manglende adgang til webtjenesten på grund af vedligeholdelse eller nedbrud. Der er kun fokus på fejlsituationer »bag« webtjenesten ud fra brugernes synspunkt.

Fejlmeddelelser

Fejlkoderne for de forventede fejlsituationer er anført nedenfor ledsaget af en forklaring. Svaret indeholder kun fejlkoden, hvilket er den sædvanlige fremgangsmåde i NtS XML-skemaet.







Fejlkoder for NtS-meddelelsestjenesten Code Description Explanation e010 message type not supported web service does not support the requested message type e030 paging parameters inconsistent with messages parameters for paging mechanism do not fit the available messages, e.g. Offset >= Total Count e100 syntax error in request request violates the schema for requests; can be specified in more detail by further e1xx-Codes e110 incorrect message type given message type is not known e120 incorrect type-specific parameters type-specific parameters are erroneous e130 incorrect paging para