02007R0416 — NL — 29.12.2018 — 001.001

Onderstaande tekst dient louter ter informatie en is juridisch niet bindend. De EU-instellingen zijn niet aansprakelijk voor de inhoud. Alleen de besluiten die zijn gepubliceerd in het Publicatieblad van de Europese Unie (te raadplegen in EUR-Lex) zijn authentiek. Deze officiële versies zijn rechtstreeks toegankelijk via de links in dit document

Gewijzigd bij:









▼B

VERORDENING (EG) Nr. 416/2007 VAN DE COMMISSIE

van 22 maart 2007

betreffende de technische specificaties voor berichten aan de scheepvaart als bedoeld in artikel 5 van Richtlijn 2005/44/EG van het Europees Parlement en de Raad betreffende geharmoniseerde River Information Services (RIS) op de binnenwateren in de Gemeenschap







Artikel 1

Deze verordening definieert de technische specificaties voor berichten aan de scheepvaart. Deze technische specificaties staan beschreven in de bijlage bij deze verordening.

Artikel 2

Deze verordening treedt in werking op de dag volgende op die van haar bekendmaking in het Publicatieblad van de Europese Unie.

Deze verordening is verbindend in al haar onderdelen en is rechtstreeks toepasselijk in elke lidstaat.

▼M1









BIJLAGE

INHOUDSOPGAVE 1. ALGEMENE BEPALINGEN 1.1. Definities 1.2. Basisfuncties en prestatie-eisen voor berichten aan de scheepvaart (NtS) 2. VERSTREKKEN VAN BERICHTEN AAN DE SCHEEPVAART 3. NtS-BERICHTTYPES 4. STRUCTUUR VAN NtS EN CODERING VAN NtS-BERICHTEN 4.1. Algemene structuur 4.1.1. Identificatiesectie 4.1.2. Bericht met betrekking tot vaarwegen en verkeer 4.1.3. Bericht met betrekking tot de waterstand 4.1.4. IJsbericht 4.1.5. Bericht met betrekking tot het weer 4.2. Verklaring van XML-tags en codewaarden in de NtS Reference Tables 4.3. Identificatie van vaarwegsecties en objecten in NtS- berichten 4.4. Regels voor de codering van NtS-berichten Aanhangsel A: NtS Encoding Guide voor redacteuren Aanhangsel B: NtS Encoding Guide voor applicatieontwikkelaars Aanhangsel C: NtS XML-schemadefinitie (XSD) Aanhangsel D: NtS Web Service-specificatie (WSDL)

1. ALGEMENE BEPALINGEN

1.1. Definities

Met Fairway Information Services (FIS, vaarweginformatiediensten) wordt geografische, hydrologische en administratieve informatie over de waterweg (vaarweg) bedoeld die door schippers en vlootmanagers wordt gebruikt voor het plannen, uitvoeren en volgen van een reis. De termen „schipper” en „kapitein” die in de huidige norm worden gebruikt, worden gelijkgesteld met de term „kapitein” in de richtsnoeren voor River Information Services (RIS) (Verordening (EG) nr. 414/2007 van de Commissie ( 1 )), terwijl de term „vlootmanager” is gedefinieerd in Verordening (EG) nr. 415/2007 van de Commissie ( 2 ).

FIS verschaffen dynamische informatie (zoals waterstanden en waterstandsvoorspellingen) en statische informatie (zoals bedieningstijden van sluizen en bruggen) over het gebruik en de status van de binnenvaartinfrastructuur, en ondersteunen op die manier tactische en strategische navigatiebeslissingen.

Traditionele middelen om FIS te verlenen zijn onder meer visuele navigatiehulpmiddelen, schriftelijke berichten aan de scheepvaart, radio-uitzendingen en vaste telefoons bij sluizen. De mobiele telefoon heeft gezorgd voor nieuwe communicatiemogelijkheden voor spraak en data, maar het netwerk is niet altijd en overal beschikbaar. Op maat gemaakte FIS voor de vaarwegen kunnen worden verleend via marifoonverkeer in de binnenvaart, internet of elektronische navigatiekaarten, zoals het systeem voor de elektronische weergave van binnenvaartkaarten en -informatie (Inland ECDIS) met elektronische navigatiekaart (ENC).

1.2 Basisfuncties en prestatie-eisen voor berichten aan de scheepvaart (NtS)

In deze technische specificatie voor NtS zijn regels opgenomen voor de datatransmissie van vaarweginformatie via internet.

NtS:

(a) verstrekken informatie over de toestand, het verkeer, het weer, de waterstanden en ijs op de vaarweg voor Fairway Information Services;

(b) vertalen automatisch de kerninhoud van de berichten door een op codelijsten gebaseerde standaardwoordenlijst te gebruiken (de NtS Reference Tables in aanhangsel E);

(c) worden verstrekt in een geharmoniseerde structuur van gegevens zodat de berichten gemakkelijk in de reisplanningssystemen kunnen worden verwerkt;

(d) zijn compatibel met de gegevensstructuur van de RIS Index en Inland ECDIS, zodat NtS gemakkelijk in Inland ECDIS kunnen worden opgenomen, zoals bepaald in Richtlijn 2005/44/EG van 7 september 2005 betreffende geharmoniseerde RIS op de binnenwateren in de Gemeenschap.

De technische specificaties voor NtS vergemakkelijken de uitwisseling van gegevens tussen NtS-systemen van verschillende landen en met andere toepassingen die NtS-gegevens gebruiken, waaronder Inland ECDIS.

Sommige informatie in NtS-berichten kan worden gestandaardiseerd, andere niet.

Het gestandaardiseerde deel moet alle informatie omvatten die:

(a) belangrijk is voor de veiligheid van de binnenvaart (bijvoorbeeld: gezonken klein vaartuig aan de rechterzijde van de vaarweg van de Donau, rivier-km 2010);

(b) nodig is voor reisplanning, onder meer de sluiting van sluizen en de vermindering van de doorvaarthoogte.

Aanvullende informatie die niet essentieel is voor de veiligheid of de reisplanning, zoals de oorzaak van de sluiting van een sluis, mag als vrije tekst zonder automatische vertaling worden geleverd. Het gebruik van vrije tekst moet tot een minimum worden beperkt.

2. VERSTREKKEN VAN BERICHTEN AAN DE SCHEEPVAART

De lidstaten waarborgen dat NtS-berichten toegankelijk zijn via internet en een gestandaardiseerde NtS web service, volgens de technische specificaties in deze bijlage en de bijbehorende aanhangsels. De specificatie voor de gestandaardiseerde NtS web service is opgenomen in aanhangsel D in de vorm van een „web service description language” (WSDL).

Dankzij een gestandaardiseerde NtS web service kan de gebruiker berichten selecteren op grond van ten minste één van de volgende criteria:

(c) een bepaalde waterwegsectie;

(d) een bepaald deel van een waterweg, gedefinieerd door de rivier-km van het begin- en eindpunt;

(e) de geldigheidsperiode van het bericht (begin- en einddatum van de geldigheidsperiode);

(f) de publicatiedatum van het bericht (datum en tijdstip van publicatie).

NtS-berichten die aan de standaard van deze bijlage voldoen, kunnen onder meer worden verstrekt via:

(a) mobiele applicaties („apps”);

(b) e-maildiensten.

Ook kunnen gegevens worden uitgewisseld tussen de NtS-systemen van verschillende landen. Alle systemen die de standaard in de bijlage bij deze verordening gebruiken, kunnen NtS van andere systemen integreren in hun eigen diensten, mits de inhoud van het bericht niet wordt gewijzigd. Gebruikers worden verwittigd als de verbinding met een bron van geïntegreerde NtS onderbroken of niet beschikbaar is.

3. NTS-BERICHTTYPES

NtS-berichten zijn zeer belangrijke berichten die zoveel mogelijk gestandaardiseerd worden.

Er zijn vier NtS-berichttypes:

(a) bericht met betrekking tot vaarwegen en verkeer;

(b) bericht met betrekking tot de waterstand;

(c) ijsbericht;

(d) bericht met betrekking tot het weer.

4. STRUCTUUR VAN NTS EN CODERING VAN NTS-BERICHTEN

In dit hoofdstuk worden de structuur en de codering van gestandaardiseerde elektronische NtS-berichten beschreven.

Een NtS-bericht is een gestructureerd bericht met zoveel mogelijk gestandaardiseerde elementen. Het gebruik van vrije tekst in de data-elementen moet tot een minimum worden beperkt.

De gestandaardiseerde XML-schemadefinitie voor NtS, die in deze norm XSD wordt genoemd en de gestandaardiseerde codewaarden en mogelijke formaten bevat, is opgenomen in aanhangsel C.

De gestandaardiseerde codewaarden en XML-tags en de betekenis en vertaling ervan zijn opgenomen in de NtS Reference Tables in aanhangsel E en zijn ook elektronisch beschikbaar in het European Reference Data Management System (ERDMS) dat door de Europese Commissie wordt beheerd.

4.1. Algemene structuur

Een NtS-bericht bestaat uit de volgende secties:

(a) identificatiesectie;

(b) sectie waarin de toepasselijke objecten of vaarwegsecties worden gedefinieerd waarop het bericht betrekking heeft;

(c) beperking(en) in een bericht met betrekking tot vaarwegen en verkeer, meetwaarde(n) in een bericht met betrekking tot de waterstand, toestand van het ijs in een ijsbericht en weerbericht(en) in een bericht met betrekking tot het weer.

Figuur 1

Berichtstructuur van berichten aan de scheepvaart

4.1.1. Identificatiesectie

Elk bericht moet een identificatiesectie bevatten. De identificatiesectie bevat algemene informatie over de uitgever en de publicatiedatum van het bericht.

4.1.2. Bericht met betrekking tot vaarwegen en verkeer

Het bericht met betrekking tot vaarwegen en verkeer bevat informatie over vaarwegsecties of objecten en wordt gebruikt om beperkingen aan te geven voor de volgende doeleinden:

(a) „Waarschuwing”: essentieel voor de veiligheid. Een waarschuwing moet ten minste één beperking bevatten die een rechtstreeks en concreet gevaar voor personen, vaartuigen of voorzieningen tot gevolg heeft, zoals vonken van laswerken aan een brug, een inspectiekooi of arbeiders onder een brug, een obstakel op de vaarweg;

(b) „Mededeling”: essentieel voor de reisplanning of de veiligheid. Een mededeling kan beperkingen bevatten, zoals een geblokkeerde sluiskolk door onderhoudswerken of baggerwerken op de vaarweg;

(c) „Informatieservice”: algemene informatie die niet direct verband houdt met de reisplanning of de veiligheid. Een informatieservice mag geen specifieke beperkingen bevatten en is daarom niet rechtstreeks relevant voor de reisplanning of de veiligheid. Het kan onder meer om algemene informatie gaan zoals lokale scheepvaartvoorschriften of een update van Inland ECDIS.

4.1.3. Bericht met betrekking tot de waterstand

De sectie met betrekking tot de waterstand bevat waarden of voorspellingen voor:

(a) de waterstand,

(b) de minst gepeilde diepte,

(c) de doorvaarthoogte,

(d) de stuwstand,

(e) de afvoer,

(f) het afvoerregime.

Gewoonlijk wordt informatie met betrekking tot de waterstand automatisch geproduceerd en gepubliceerd op grond van gegevens van sensoren (bv. een peilmeter), systemen (bv. een waterstandmodel) of infrastructuur (bv. een stuwstand). Er kunnen verschillende aanleidingen voor publicatie zijn, zoals periodieke publicatie of het bereiken van een bepaalde waarde.

4.1.4. IJsbericht

Een ijsbericht bevat informatie over de feitelijke of verwachte toestand van het ijs op een vaarwegsectie. IJsinformatie wordt gewoonlijk gegenereerd door bevoegd personeel op grond van waarnemingen ter plaatse en een professionele beoordeling.

4.1.5. Bericht met betrekking tot het weer

Een bericht met betrekking tot het weer bevat informatie over (gevaarlijke) weersomstandigheden voor de binnenvaart.

Berichten met betrekking tot het weer kunnen worden gepubliceerd om de verspreiding van hydro-meteo-informatie van hydro-meteo-netwerken naar kapiteins te vergemakkelijken.

4.2. Verklaring van XML-tags en codewaarden in de NtS Reference Tables

De betekenis van de verschillende elementen die worden gebruikt in de XML-schemadefinitie (XSD) van NtS wordt beschreven in de NtS Reference Tables in aanhangsel E. De structuur, het formaat en de mogelijke waarden van alle XML-elementen worden beschreven in de XSD van NtS in aanhangsel C.

(a) Breedte- en lengtecoördinaten worden gecodeerd volgens het World Geodetic System 1984 en weergegeven in graden en minuten met ten minste drie, maar bij voorkeur vier decimalen ([d]d mm.mmm[m] N, [d][d]d mm.mmm[m] E).

(b) Decimalen in numerieke velden worden aangegeven met een punt („.”). Voor duizendtallen worden geen scheidingstekens gebruikt.

(c) In NtS-berichten mogen voor de waarden in het XML-bericht alleen de volgende eenheden worden gebruikt: cm, m3/s, h, km/h en kW, m/s (wind), mm/h (regen) en graden Celsius. In nationale applicaties kunnen de eenheden worden omgezet voor een gebruikersvriendelijke weergave.

4.3. Identificatie van vaarwegsecties en objecten in NtS-berichten

Om te voldoen aan de minimale gegevenseisen voor het verstrekken van informatie over objecten die relevant zijn voor de binnenscheepvaart als bedoeld in artikel 4, lid 3, onder a), van Richtlijn 2005/44/EG, moet de ISRS Location Code in de objectsectie worden gebruikt. De ISRS Location Code wordt gebruikt voor de unieke identificatie van objecten en vaarwegsecties en om de interoperabiliteit van RIS-systemen en -diensten te verzekeren (bv. voor het combineren van informatie over infrastructuur uit de RIS Index, Inland ECDIS en NtS voor de reisplanning).

De ISRS Location Code is een 20-cijferige alfanumerieke code die wordt gebruikt om een unieke en gestandaardiseerde relatie tussen objecten in River Information Services (RIS) tot stand te brengen. Ze bestaat uit de volgende verplichte gegevenselementen, onderverdeeld in vier informatieblokken:

(a) Blok 1: UN/LOCODE (5 tekens, alfanumeriek), bestaande uit

— Country code (2 tekens, alfanumeriek) ( 3 ) en

— Location code (3 tekens, alfanumeriek, „XXX” indien niet beschikbaar)

(b) Blok 2: Fairway section code (5 tekens, alfanumeriek, vast te stellen door de nationale instantie)

(c) Blok 3: Object reference code (5 tekens, alfanumeriek, „XXXXX” indien niet beschikbaar)

(d) Blok 4: Fairway section hectometre (5 tekens, numeriek, hectometer in het midden van het gebied of „00000” indien niet beschikbaar).

De ISRS Location Codes en de referentiegegevens van objecten worden door de lidstaten bijgehouden in de RIS Index en ingediend bij de ERDMS van de Europese Commissie overeenkomstig de onderhoudsprocedures voor de RIS Index die zijn gepubliceerd op de ERDMS-website.

4.4. Regels voor de codering van NtS-berichten

NtS-berichten worden gecodeerd overeenkomstig de NtS Encoding Guide voor redacteuren (aanhangsel A) en de NtS Encoding Guide voor applicatieontwikkelaars (bijlage B).









NTS ENCODING GUIDE VOOR REDACTEUREN

INHOUD 1 Achtergrond, structuur en doel van NtS Encoding Guides 2. Selectie van het NtS-berichttype 3. Basisoverwegingen voor een FTM, stappen voor de publicatie van een FTM 4. Verklaring van codes in een FTM 5. Basisoverwegingen voor een WRM 6. Basisoverwegingen voor een ICEM, stappen voor de publicatie van een ICEM 7. Basisoverwegingen voor een WERM 8. Regels voor bepaalde elementen

Afkortingen:







Afkorting Betekenis CEVNI Europese Code voor de binnenvaart (http://www.unece.org/trans/main/sc3/sc3res.html) ENC Elektronische navigatiekaart FTM Bericht met betrekking tot vaarwegen en verkeer ICEM IJsbericht Inland ECDIS Systeem voor elektronische weergave van kaarten en de daaraan verbonden informatie ISRS Location Code „International Ship Reporting Standard” Location Code NtS Berichten aan de scheepvaart RIS River Information Services VHF Marifoonkanaal WERM Bericht met betrekking tot het weer WRM Bericht met betrekking tot de waterstand WSDL Web Services Description Language XML Extended Markup Language XSD XML-schemadefinitie

1. Achtergrond, structuur en doel van NtS Encoding Guides

De NtS-standaard wordt voortdurend verbeterd. Het uitbrengen van een NtS web service die de uitwisseling van NtS-berichten tussen instanties onderling en instanties en NtS-gebruikers vergemakkelijkte, was een grote stap voorwaarts.

Er zijn twee documenten opgesteld om de geharmoniseerde codering van NtS-berichten op nationaal en internationaal niveau te vergemakkelijken: de NtS Encoding Guide voor redacteuren en de NtS Encoding Guide voor applicatieontwikkelaars. Die handleidingen zijn van toepassing op NtS XSD 4.0 en de NtS web service WSDL 2.0.4.0.

Gezien het toenemende gebruik van de NtS web service zullen NtS-berichten verder worden gestandaardiseerd zodat de inhoud ervan correct wordt weergegeven op de systemen van derden. De eenduidige codering van berichten is ook een vereiste voor het opnemen ervan in applicaties voor reisplanning.

Elementen die alleen standaardwaarden bevatten, worden weggelaten als zij niet verplicht zijn omdat zij leiden tot extra data zonder toegevoegde waarde.

De NtS Encoding Guide voor redacteuren is bestemd voor diegenen die NtS-berichten opstellen (en publiceren), en bevat stap-voor-stap instructies voor het opstellen van de correcte berichttypes en een verklaring van de codes. De NtS Encoding Guide verklaart de toepasselijkheid van de vier NtS-berichttypes en bevat instructies voor het invullen, evenals de codes die in bepaalde gevallen moeten worden gebruikt. De NtS Encoding Guide voor redacteuren is opgenomen in aanhangsel A.

De NtS Encoding Guide voor applicatieontwikkelaars bevat richtsnoeren voor de ontwikkeling en toepassing van NtS-applicaties en verklaart de logica, de processen en de automatische en standaardwaarden ervan. De NtS Encoding Guide voor applicatieontwikkelaars is opgenomen in aanhangsel B van de bijlage bij deze verordening.

2. Selectie van het NtS-berichttype

— FTM: Kies dit type als u een „bericht met betrekking tot vaarwegen en verkeer” wilt opstellen voor waterwegen of objecten op de waterweg. [ga naar hoofdstuk 3]

— WRM: Kies dit type als u een „bericht met betrekking tot de waterstand” wilt opstellen, waardoor informatie over de actuele en de verwachte waterstanden en andere gegevens kunnen worden verstrekt. Het bericht met betrekking tot de waterstand bevat informatie over een object of een vaarwegsectie. Het object wordt geïdentificeerd aan de hand van zijn ISRS Location Code, de vaarwegsectie wordt gedefinieerd door de begin- en eind-ISRS Location Codes.

— ICEM: Kies dit type als u een „ijsbericht” wilt opstellen. Het ijsbericht bevat informatie over de toestand van het ijs op een vaarwegtraject dat wordt gedefinieerd door de begin- en eind-ISRS Location Codes.

— WERM: Kies dit type als u een „bericht met betrekking tot het weer” wilt opstellen, waardoor informatie over de actuele en de voorspelde weersomstandigheden kan worden verstrekt op een vaarwegtraject dat wordt gedefinieerd door de begin- en eind-ISRS Location Codes.

3. Basisoverwegingen voor een FTM, stappen voor de publicatie van een FTM

Gedetailleerde informatie over de te gebruiken codes vindt u in hoofdstuk 4. De overwegingen vanaf 3.3 zijn niet noodzakelijk in de inputvolgorde van een FTM-editor.

3.1. Is er behoefte om informatie te publiceren via NtS FTM volgens de NtS-standaard? Alle relevante informatie over de veiligheid en de reisplanning moet worden gepubliceerd via NtS-berichten. Er mag ook informatie worden gepubliceerd die niet relevant is voor de veiligheid en de reisplanning. Elk onderwerp/incident/voorval moet in een afzonderlijk bericht worden gepubliceerd.

3.2. Bestaat er al een geldig FTM met betrekking tot de actuele situatie (zowel wat betreft de inhoud als de geldigheidsduur)?

3.2.1. Ja:

het bestaande FTM moet worden bijgewerkt. Het gepubliceerde bericht in kwestie moet worden geselecteerd en bijgewerkt in de FTM-editor. Een vervallen FTM kan niet meer worden bijgewerkt.

3.2.2. Nee:

er moet een nieuw FTM worden opgesteld. Als een soortgelijk voorval reeds is gecodeerd in een bestaand FTM, kan dat FTM worden gebruikt als ontwerp voor de aanmaak van een nieuw FTM (als die functie beschikbaar is) of kan er een sjabloon worden gebruikt (als die functie beschikbaar is).

3.3. Het geografische bereik van de geldigheid moet worden vastgesteld.

3.3.1. Als het FTM betrekking heeft op een specifiek traject van een waterweg, moet dat traject worden opgenomen en bepaald aan de hand van de begin- en eindpunten. Als de inhoud van toepassing is op verschillende secties van dezelfde waterweg of verschillende waterwegen, kunnen die allemaal worden opgenomen in één FTM.

3.3.2. Als het FTM betrekking heeft op een specifiek object (bv. een brug of sluis) op de waterweg, moet het object in kwestie worden geselecteerd uit een lijst van beschikbare objecten (als de selectiefunctie beschikbaar is). In het bericht moet geen waterwegtraject worden gedefinieerd. Als een FTM van toepassing is op verschillende objecten, kunnen die allemaal worden opgenomen in één FTM.

3.3.3. Informatie over objecten en vaarwegen kan worden gecombineerd in één bericht op voorwaarde dat de informatie betrekking heeft op één bepaalde oorzaak/bepaald voorval (zelfde code voor onderwerp en reden).

3.3.4. Hoewel de coördinaten niet verplicht zijn, worden ze toegevoegd om de weergave op kaarten te ondersteunen (vaak worden die coördinaten automatisch door de NtS-applicatie verstrekt).

3.4. Inhoud van het FTM moet worden ingevuld.

Alle informatie die kan worden uitgedrukt aan de hand van de NtS Reference Tables, moet worden gecodeerd in de gestandaardiseerde berichtvelden. In de vrije tekstvelden wordt alleen aanvullende informatie (die niet op een andere manier kan worden gecodeerd) vermeld.

3.5. De doelgroep voor het type vaartuig en de betrokken richting moet worden ingevuld, indien van toepassing.

3.5.1. Als het bericht voor alle schepen (alle soorten vaartuigen) in alle richtingen geldt, wordt de doelgroep weggelaten zodat alleen essentiële informatie wordt gecodeerd. Als het bericht/de beperking gericht is tot een specifieke doelgroep of richting, moeten de desbetreffende codes worden geselecteerd.

3.5.2. Als het volledige bericht voor specifieke doelgroepen geldt, moet de informatie over de doelgroep worden verstrekt in het algemene deel van het FTM (en niet worden herhaald in de sectie(s) voor beperkingen).

3.5.3. Als er verschillende doelgroepen zijn voor verschillende beperkingen, moet de informatie over de doelgroep worden verstrekt in de desbetreffende beperkingen (en niet worden herhaald in het algemene deel).

3.5.4. Als de bevoegde instanties vrijstelling van beperkingen verlenen aan afzonderlijke vaartuigen of lokaal verkeer (bv. vaartuigen die deelnemen aan een evenement waarvoor een algemene blokkering van toepassing is, lokaal ferryverkeer in geblokkeerde gebieden), moet met dergelijke vrijstellingen geen rekening worden gehouden bij de codering van de doelgroep(en). Dergelijke informatie mag worden vermeld in het vrije tekstveld voor aanvullende informatie.

3.6. Indien van toepassing moet de communicatiesectie worden ingevuld.

Als via een specifieke bron aanvullende informatie beschikbaar is, moet die in deze sectie worden vermeld. Als er een extra meldplicht is via een specifiek communicatiemiddel, moet dat in deze sectie worden vermeld.

3.7. Indien van toepassing moet de beperkingensectie worden ingevuld.

Als er beperkingen van toepassing zijn, moet de beperkingensectie worden ingevuld. Als de aan beperkingen verbonden waarden bekend zijn, moeten die worden vermeld. Het is verplicht om waarden te verstrekken voor de afmetingen van schepen, de snelheidsbeperking en de beschikbare afmetingen voor de scheepvaart.

In alle beperkingen moet de duur van de beperking worden opgegeven, zodat applicaties voor reisplanning correcte berekeningen kunnen maken (om het werk te vergemakkelijken kan de NtS-applicatie een functie bieden om de duur van de beperkingen te kopiëren of meer dan één beperking te selecteren bij de duur van een beperking).

3.8. De begindatum van de geldigheid van het bericht moet worden ingesteld.

Als de einddatum van de geldigheid van een bericht al bekend is, moet ook die worden ingesteld. De einddatum van de geldigheid mag niet vóór de huidige datum vallen.

Let op: de informatie over de geldigheidsperiode zal door applicaties worden gebruikt om de berichten te selecteren die gedurende een gevraagde periode beschikbaar zijn voor de gebruikers.

Als het bericht wordt ingetrokken:

a) vóór de geldigheidsperiode van start gaat, moeten de begin- en einddatum worden ingesteld op de datum van intrekking;

b) als de geldigheidsperiode al is ingegaan, moeten de nieuwe einddatums voor alle beperkingen worden ingesteld in het verleden, het einde van de geldigheidsperiode moet worden ingesteld op de datum van de intrekking.

3.9. Het bericht kan worden gepubliceerd.

4. Verklaring van codes in een FTM

4.1. Subject_code:

Definitie van het gebruik van onderwerpen:

— „Waarschuwing”: essentieel voor de veiligheid. Een waarschuwing moet ten minste één beperking bevatten die een rechtstreeks en concreet gevaar voor personen, vaartuigen of voorzieningen tot gevolg heeft, zoals vonken van laswerken aan een brug, een inspectiekooi of arbeiders onder een brug, een obstakel op de vaarweg.

— „Mededeling”: essentieel voor de reisplanning of de veiligheid. Een mededeling kan beperkingen bevatten, bv. stremming van een sluiskolk vanwege onderhoudswerkzaamheden, baggeren van de vaarweg, scheepvaartvoorschriften als aanvulling op de nationale wetgeving.

— „Informatieservice”: algemene informatie die niet rechtstreeks verband houdt met de reisplanning of de veiligheid. De informatieservice mag geen specifieke beperkingen bevatten en is daarom niet rechtstreeks relevant voor de reisplanning of de veiligheid. Dergelijke informatie kan bijvoorbeeld lokale scheepvaartvoorschriften of een update van Inland ECDIS bevatten. De geldigheidsperiode wordt gebruikt om de periode te specificeren waarin het informatieservicebericht aan de gebruikers wordt getoond, niet voor de geldigheidsperiode van de meegedeelde informatie (bv. één maand of zoals vastgelegd in de nationale procedures).

— „Bericht ingetrokken”: — Het onderwerp „bericht ingetrokken” wordt alleen gebruikt als: — — de huidige datum vóór de begindatum van de geldigheid valt. In dat geval mag alleen de inhoud van het veld „aanvullende informatie in de nationale taal” worden veranderd, de verdere inhoud van het bericht moet ongewijzigd blijven. In dat geval wordt „bericht ingetrokken” gebruikt om een bericht in te trekken vóór het geldig wordt. Dat betekent dat „bericht ingetrokken” wordt gebruikt voor berichten die de begindatum van de geldigheid niet haalden en/of voor geplande maatregelen die niet zullen worden uitgevoerd (bv. geplande baggerwerken die niet van start kunnen gaan door een hoge waterstand); — de geldigheidsperiode is reeds van start gegaan en de nieuwe einddatums voor alle beperkingen worden ingesteld in het verleden. De einddatum van de geldigheid moet worden ingesteld op de datum van intrekking. — In dat geval eindigen de maatregelen/voorvallen vóór de aanvankelijk vastgestelde geldigheidsperiode van een al bestaand FTM is afgelopen.

4.2. Reason_code

De reden moet worden ingevuld om extra informatie te verstrekken aan kapiteins.

Definitie van het gebruik van redenen:







bouwwerkzaamheden Aankondiging van bouwwerken calamiteit Waarschuwing voor een calamiteit/ramp veranderingen in de vaarweg Aankondiging van een gewijzigde vaarweg gewijzigde markering Aankondiging van gewijzigde markering beperking van de vaarweg Aankondiging van een beperkte breedte van de vaarweg als geen andere reden van toepassing is beschadigde tekens/seinen Aankondiging van beschadigde tekens/seinen duikwerkzaamheden Waarschuwing voor duiker onder water baggerwerkzaamheden Aankondiging van baggerwerkzaamheden evenement Aankondiging van evenementen, bv. een zwem-, zeil- of roeiwedstrijd oefeningen Aankondiging van reddings- of militaire oefeningen opruimen explosieven Aankondiging van opruiming van explosieven uitgebreid schutbedrijf Aankondiging van een hoger dan gebruikelijke waterafvoer door stuwen of sluizen om redenen van waterbeheer vallend materiaal Aankondiging van vallend materiaal, bv. ijspegels, takken of bomen valse echo's Aankondiging van mogelijk valse radarecho's vuurwerk Aankondiging van vuurwerk drijvend materiaal Aankondiging van drijvend materiaal boven het waterniveau (zichtbaar) en onder het waterniveau (onzichtbaar) stroomsnelheidsmeting Aankondiging van stroomsnelheidsmetingen gezondheidsgevaar Waarschuwing voor of aankondiging van bv. eikenprocessierups, lekkend gas enz. hoogspanning Aankondiging van een kruisende hoogspanningskabel hoogwater Aankondiging van een hoog waterpeil vóór een vaarverbod van kracht wordt ijs Aankondiging van ijs; meer informatie zal worden verstuurd via een ijsbericht Inland ECDIS-update Informatieservice over een Inland ECDIS-update inspectiewerkzaamheden Aankondiging van inspectiewerkzaamheden; alleen in geval van inspectie; niet voor herstel- of bouwwerkzaamheden. Er kunnen beperkingen gelden door inspectiewagens, -kooien of -steigers tewaterlating Aankondiging van een schip dat een werf verlaat lokale scheepvaartvoorschriften Informatieservice over aanvullende of gewijzigde regels van geldend recht of reglementering zonder bijzondere beperkingen, beperkingsdata of geldigheidsdata laagwater Aankondiging van een laag waterpeil vóór een vaarverbod van kracht wordt waterstandsverlaging Aankondiging van een gecontroleerde verlaging van het waterpeil voor inspecties, werkzaamheden of waterbeheer minimale waterafvoer Aankondiging van een lager dan gebruikelijk debiet doorheen dammen of sluizen om redenen van waterbeheer nieuw object Aankondiging van informatie over een nieuw beschikbaar object, bv. een brug, aanlegplaats hindernis Aankondiging van een beperkte doorvaarthoogte en/of beperkte breedte van de vaarweg door een obstakel boven het waterniveau hindernis onder water Aankondiging van een beperkte diepgang en/of beperkte breedte van de vaarweg door een obstakel onder water waterstand met vaarverbod (Marke II) Aankondiging van een waterstand (hoog of laag water) die een vaarverbod veroorzaakt radiobereik Aankondiging betreffende radiobereik bergingswerkzaamheden Aankondiging van verwijderde objecten herstelwerkzaamheden Aankondiging van schade of een defect dat moet worden hersteld, b.v. in een sluiscontrolesysteem; kan ook worden gebruikt voor geplande herstellingen wassend water Aankondiging van een natuurlijk stijgend waterpeil, dus niet door waterbeheer verondieping Aankondiging van een beperkte beschikbare diepgang door verzanding peilwerkzaamheden Aankondiging van peilwerkzaamheden bijzondere markering Aankondiging van het gebruik van bijzondere markeringen, bv. voor het blokkeren van watergebieden of visgronden bijzonder transport Aankondiging van bijzonder vervoer staking Aankondiging van een staking van het personeel met gevolgen voor de beschikbaarheid van de waterweginfrastructuur waterstand met beperkte scheepvaart (Marke I) Aankondiging van een waterstand (hoog of laag water) die tot bijzonder behoedzaam varen noopt werkzaamheden Aankondiging van algemene werkzaamheden aan objecten, oevers en/of beddingen van waterwegen (rivieren of kanalen) beperkingen Mag alleen worden gebruikt voor geldende beperkingen waarop geen andere reason_code van toepassing is overige Mag niet worden gebruikt; als geen andere reason_code van toepassing is, wordt dit veld niet ingevuld

4.3. Limitation_code:

Definitie van het gebruik van beperkingen:

— stremming: — als geen enkele vorm van scheepvaart mogelijk is: — — door een sluiskolk, — door een brugopening, — langs een bepaald punt van de vaarweg, — op een bepaald gedeelte van de vaarweg.

— gedeeltelijke stremming: — alle infrastructuuronderdelen (bv. sluiskolken, brugopeningen) moeten een eigen ISRS Location Code hebben. Als die codes er nog niet zijn, kan een gedeeltelijke stremming worden gebruikt als scheepvaart in beperkte mate mogelijk is (bv. enige beschikbare object in een sluis met twee evenwijdige kolken) — — door een of meer sluiskolken, waarbij er ten minste één open blijft, — door een of meer brugopeningen, waarbij er ten minste één open blijft.

— geen bediening: — wordt gebruikt als een beweegbare brug gedurende een bepaalde periode niet wordt bediend. Die periode moet binnen de normale bedieningstijden liggen. — Geen bediening van een beweegbare brug betekent dat het nog mogelijk is om onder de brug door te varen. Anders is er sprake van een „stremming”. Als een sluis niet wordt bediend, moet de code „stremming” worden gebruikt.

— gewijzigde bedieningstijden: — wordt gebruikt als de normale bedieningstijden van objecten (bv. sluizen, (beweegbare) bruggen) worden gewijzigd, verlengd of beperkt.

— Als de beperkingen verband houden met de toegelaten afmetingen van vaartuigen/duwstellen (niet in direct verband met de infrastructuur), moet de codering van de beperking de volgende tekstelementen bevatten: — — scheepsdiepgang, — scheepsbreedte, — breedte samenstel, — scheepslengte, — lengte samenstel, — scheepshoogte. — Indien beschikbaar moet een absolute waarde worden ingevoerd.

— Als er beperkingen gelden voor de beschikbare afmeting van een object of een deel van een waterweg, worden de volgende codes gebruikt: — — doorvaarthoogte, — doorvaartlengte, — doorvaartbreedte, — beschikbare waterdiepte. — Indien beschikbaar moet een absolute waarde worden ingevoerd.

— minst gepeilde diepten: moet worden gebruikt als de diepte problemen kan veroorzaken (bv. door verzanding). Er moet een waarde voor de absolute diepte (ten opzichte van een referentiewaarde) of de verminderde diepte worden ingevoerd. Indien beschikbaar moet een absolute waarde worden ingevoerd.

— oponthoud: wordt gebruikt als zich een belemmering/incident van beperkte duur voordoet op een object of een deel van een waterweg tussen een specifieke begin- en einddatum. — De geraamde maximale duur van de belemmering/het incident moet worden gecodeerd. „Oponthoud” mag niet worden gebruikt als een van de sluiskolken niet beschikbaar is.

— Als specifieke bewegingen of handelingen verboden zijn, moeten de desbetreffende beperkingen worden gecodeerd. Die beperkingen mogen alleen worden gecodeerd als ze nog niet zijn aangekondigd via scheepvaartbewegwijzering of reglementen in de officiële Inland ENC's: — — minimaal vermogen, — beurtelings verkeer, — verboden te keren, — ontmoeten verboden, — voorbijlopen verboden, — verboden ligplaats te nemen, — afmeerverbod, — ankeren verboden, — hinderlijke waterbeweging vermijden, — snelheidsbeperking, — verboden aan land te gaan. — Indien beschikbaar moet een absolute waarde voor de snelheidsbeperking of het minimale vermogen worden ingevoerd.

— bijzondere voorzichtigheid: Als het FTM (of een deel van een FTM) betrekking heeft op een vaarweg/waterweg, wordt deze code gebruikt om aan te geven op welke plek op de vaarweg/rivier of het kanaal/meer zich een incident heeft voorgedaan. — Voorts wordt deze code gebruikt als de beperking niet in detail kan worden beschreven, maar het wel nuttig of noodzakelijk is om schippers te waarschuwen of hen te informeren dat zij moeten opletten en luisteren naar marifoonberichten.

— geen beperking: mag alleen worden gebruikt als expliciet wordt vermeld dat er gedurende een bepaalde periode geen beperkingen zijn.

4.4. Limitation interval_code: Definitie van het gebruik van interval codes:

— „onafgebroken”: moet worden gebruikt voor beperkingen die onafgebroken van toepassing zijn vanaf een begindatum/-tijd tot een einddatum/-tijd (bv. „stremming van 01.01.2016, 00:00 h tot 31.03.2016, 23:59 h”, maar ook „stremming op 17.09.2016 van 08:00 h tot 18:00 h”).

— „dagelijks”: moet worden gebruikt voor een regelmatig herhaalde toepassing van een beperking (bv. hinderlijke waterbeweging vermijden op een baggerplaats tijdens de werkuren — 07.04.2016 tot en met 11.04.2016, dagelijks van 06:00 h tot 18:00 h).

— „overdag” (zoals gedefinieerd in de CEVNI): De term „overdag” betekent de periode tussen zonsopgang en zonsondergang.

— „'s nachts” (zoals gedefinieerd in de CEVNI): De term „'s nachts” betekent de periode tussen zonsondergang en zonsopgang.

— dagen van de week: als er intervallen zijn betreffende verschillende dagen van de week, moeten die worden gekozen uit de volgende tekstelementen: — — maandag, — dinsdag, — woensdag, — donderdag, — vrijdag, — zaterdag, — zondag, — maandag tot en met vrijdag, — zaterdag en zondag.

— „bij beperkt zicht”: wordt gebruikt als de beperking alleen geldt bij verminderde zichtbaarheid door mist, nevel, sneeuw, regen of andere oorzaken.

— „met uitzondering van”: mag niet gebruikt worden; onderbroken periodes moeten als afzonderlijke periodes binnen dezelfde beperking worden opgegeven. Reisplanningssoftware kan deze code immers niet correct interpreteren als „niet plaatsvindend op de opgegeven datum of tijd”, waardoor het onmogelijk is om een correcte ETA te berekenen.

— „maandag tot en met vrijdag, uitgezonderd feestdagen”: mag alleen worden gebruikt als er feestdagen vallen binnen de geldigheidsduur van de beperking. Als hulp aan de gebruikers mag een feestdag worden vermeld in de vrije tekst van het FTM. Reisplanningssoftware kan geen nationale feestdagen opnemen in de berekening van ETA's.

4.5. Indication_code:

een indication_code is bedoeld als extra informatie over specifieke waarden betreffende bepaalde beperkingen (bv. snelheidsbeperking, minimaal vermogen, beschikbare diepte). Het vaststellen van bepaalde afmetingen moet gebeuren aan de hand van een extern referentiesysteem (geografisch of hydrologisch) (bv. vrije doorvaarthoogte, beschikbare diepte, minste gepeilde diepte) of bekende afmetingen van kunstwerken (bv. beschikbare lengte, vrije doorvaartbreedte).

4.5.1. Er moeten absolute afmetingen of referentiewaarden worden gebruikt, in zoverre die bekend zijn. Relatieve waarden mogen alleen worden gebruikt als niet naar een extern referentiesysteem kan worden verwezen.

4.5.2. verminderd met → dit is een relatieve waarde

4.5.3. maximaal → dit is een absolute waarde

4.5.4. minimaal → dit is een absolute waarde

4.5.5. Als de waarde van een beperking wordt bepaald ten opzichte van geografische of hydrologische coördinaten, moet in het NtS-bericht het referentiesysteem in kwestie worden vermeld (bv. vrije doorvaarthoogte min. 4 m ten opzichte van het hoogst bevaarbare waterpeil; beschikbare diepte min. 1,7 m ten opzichte van het genormaliseerde laagwaterpeil).

4.5.6. Als de waarde van een beperking wordt bepaald ten opzichte van de afmetingen van een kunstwerk (bv. een brug of sluis), mag worden verwezen naar de bekende afmetingen (bv. vrije doorvaarthoogte verlaagd met 1,5 m, beschikbare lengte verminderd met 27 m).

4.6. Position_code (objecten):

Indien mogelijk moet de Position_code verwijzen naar de zijde van de vaarweg waar het object zich bevindt ten opzichte van de as van de vaarweg (links/midden/rechts) of andere algemeen bekende informatie (oud/nieuw) of een geografische richting (noord/zuid/oost/west). De position_code voor objecten kan automatisch van te voren worden ingevuld vanuit de referentiegegevens van de RIS Index. De linker- en rechterzijde van de vaarweg worden bepaald in stroomafwaartse richting.

4.7. Position_code (vaarwegen/waterwegen):

Een position_code voor een FTM (of een deel van een FTM) dat betrekking heeft op een vaarweg of waterweg, wordt niet gegeven. Om aan te geven aan welke kant van de vaarweg/rivier of het kanaal/meer zich een incident heeft voorgedaan, wordt de beperking „bijzondere voorzichtigheid” in combinatie met de correcte position_code van de beperking gebruikt.

4.8. Position_code (beperkingen):

4.8.1. Indien mogelijk verwijst de position_code naar de zijde van de vaarweg of het object waar de beperking zich voordoet (links/rechts). De linker- en rechterzijde van de vaarweg worden bepaald in stroomafwaartse richting.

4.8.2. Door de position_code wordt de aandacht van de kapitein gevestigd op de kant van de vaarweg waar zich bijvoorbeeld een gebied van bijzonder belang, een gevaar of een obstakel bevindt. Een ruwe indicatie volstaat (bv. linkeroever — links — midden — rechts — rechteroever); het is niet de bedoeling een nauwkeuriger onderverdeling te maken.

4.8.3. Als er behoefte zou zijn aan een nauwkeuriger plaatsbepaling, wordt die bij voorkeur gegeven aan de hand van kaarten of schetsen (bijlage, zie hoofdstuk 3.6).

4.8.4. Als op bepaalde secties de gebruikelijke positie-aanduiding (linker-/rechterzijde van de vaarweg) minder geschikt lijkt (bv. havendokken, bepaalde delen van een kanaal zonder merkbare stroming), kunnen de hoofdwindstreken worden opgegeven (noord/oost/zuid/west).

4.9. Target_group_code (zie hoofdstuk 3.5)

4.10. Reporting_code

4.10.1. In de regel wordt een reporting_code alleen gebruikt voor speciale communicatiebehoeften (bv. als men zich met betrekking tot eenrichtingsverkeer extra moet melden bij de lokale overheid) of wanneer er extra informatie beschikbaar is (bv. een VHF-kanaal of de roepnaam voor de actuele positie van een baggerboot) met rechtstreeks belang voor het FTM.

4.10.2. Een herhaling van bekende communicatiegegevens (bv. telefoonnummers van lokale overheden, VHF-kanalen van sluizen enz.) moet worden vermeden als daarvoor in verband met het FTM geen rechtstreekse aanleiding is.

4.10.3. Algemene communicatiemiddelen die volgens de officiële regelgeving worden toegepast (bv. VHF-communicatie tussen schepen onderling of tussen schip en wal zoals vastgelegd in de CEVNI of de nationale scheepvaartregels) worden in de regel niet in een reporting_code herhaald als daarvoor in verband met het FTM geen rechtstreekse aanleiding is.

4.11. Communication_code

wordt in het volgende formaat opgegeven (voorbeelden):

— VHF „nummer, roepnaam”: „10, Schifffahrtsaufsicht Wien”

— Telefoon- of faxnummer: „+43123456789, Schifffahrtsaufsicht Wien”

— Internetadres: „>http://voorbeeld.com”

— Geluidssein: „lange stoot / langer Ton”

— E-mail: „voorbeeld@overheid.eu”

— EDI-mailboxnummer: „900012345@edi.bics.nl”

— Teletekst: „ARD, 992 — 995”

4.12. Type_code:

Met een waterweg wordt een kanaal, meer of rivier bedoeld.

— ankerplaats

— oever

— baken

— ligplaats

— grensstation

— brug

— brugopening

— boei

— overhangende kabel

— kanaal (de term „kanaal” wordt gebruikt als een bericht betrekking heeft op het volledige kanaal (niet alleen op de vaargeul))

— kanaalbrug: aquaduct

— duiker

— vaarweg (de term „vaarweg” is dat deel van de waterweg dat daadwerkelijk kan worden gebruikt voor de scheepvaart)

— veerpont

— drijvend dok

— keersluis (wordt gebruikt om een gebied te beschermen bij hoogwater)

— haven

— havenfaciliteit

— havenkantoor

— meer (de term „meer” wordt gebruikt als een bericht betrekking heeft op het volledige meer (niet alleen op de vaarweg))

— licht

— sluiskolk: afzonderlijke sluiskolk

— sluis: volledig sluiscomplex

— afmeerfaciliteit

— verkeersteken

— pijpleiding

— overhangende pijpleiding

— helling

— afvalafgiftepunt

— meldpunt

— reservoir

— rivier (de term „rivier” wordt gebruikt als een bericht betrekking heeft op de volledige rivier (niet alleen op de vaargeul))

— scheepslift

— werf

— seinstation

— terminal

— peilschaal

— tunnel

— zwaaikom

— verkeerscentrale

— stuw (wordt gebruikt om het waterniveau van een rivier te regelen)

5. Basisoverwegingen voor een WRM

Berichten met betrekking tot de waterstand worden in de regel automatisch gegenereerd. Als dat onmogelijk is, worden voor de manuele opstelling van een WRM de procedures voor automatisch gegenereerde WRM's (zie NtS Encoding Guide voor ontwikkelaars) zo goed mogelijk gevolgd.

6. Basisoverwegingen voor een ICEM, stappen voor de publicatie van een ICEM

IJsberichten zijn afhankelijk van waarneming en beoordeling ter plaatse en worden opgesteld door bevoegd personeel.

Een ICEM wordt gepubliceerd bij ijsvorming. IJs zorgt niet noodzakelijk voor een beperking van het scheepvaartverkeer, maar er kan ook informatie worden verstrekt over een toestand van het ijs waardoor de scheepvaart niet wordt gehinderd.

6.1. Is er behoefte om via NtS ICEM informatie te publiceren?

Het eerste ijsbericht voor een traject wordt alleen gepubliceerd als er zich ijs op de waterweg of de zijrivieren heeft gevormd, ook als er geen beperkingen zijn.

6.2. Geldt er reeds een ICEM voor het betrokken traject van de waterweg?

6.2.1. Ja:

Als het bericht voor het betrokken traject (nog steeds) geldig is, wordt het bestaande bericht bijgewerkt. Zelfs als het betrokken gebied is gewijzigd (bv. als het ijs uitbreidt en het gebied groter wordt), kunnen bestaande ijsberichten worden bijgewerkt.

6.2.2. Nee:

Als er voor het betrokken traject geen geldig ijsbericht bestaat, moet een nieuw bericht worden gemaakt.

6.3. Er kan echter informatie worden verstrekt over een toestand van het ijs waardoor de scheepvaart niet wordt gehinderd.

6.4. Een ICEM geldt altijd voor één enkel traject van de waterweg. Het geografisch geldigheidsbereik moet worden ingesteld door de vaststelling van de waterweg en de respectieve begin- en eindpunten (hectometerpunten) (of door bepaalde opeenvolgende secties te kiezen, afhankelijk van de nationale invulling).

6.5. Het meettijdstip moet worden ingevoerd. De desbetreffende toestand van het ijs moet worden ingevoerd door tenminste één van de codelijsten te gebruiken (afhankelijk van de nationale voorschriften).

6.5.1. Ice_condition_code

6.5.2. Ice_accessibility_code

6.5.3. Ice_classification_code

6.5.4. Ice_situation_code (de ice situation code moet altijd worden opgegeven om de situatie op een kaart te kunnen weergeven aan de hand van de kleuren van verkeerslichten).

6.6. Het ICEM kan worden gepubliceerd. IJsberichten gelden automatisch tot de dag na de publicatie ervan of zoals bepaald in de nationale procedures.

7. Basisoverwegingen voor een WERM

Door de ruime beschikbaarheid van webdiensten en applicaties voor weerberichten en -waarschuwingen mag een WERM alleen worden gebruikt voor weersinformatie die van specifiek belang is voor de scheepvaart en die niet is opgenomen in de algemene weerberichten.

Berichten met betrekking tot het weer worden in de regel automatisch gegenereerd. Als dat onmogelijk is, moeten bij de manuele opstelling van een WERM de processen voor automatisch gegenereerde WERM's zo goed mogelijk worden gevolgd (zie de NtS Encoding Guide voor applicatieontwikkelaars).

8. Regels voor bepaalde elementen

8.1. Regels voor het element „name” met betrekking tot objecten

Objectnamen worden gewoonlijk door de NtS-editor ingevuld op basis van referentiegegevens uit de RIS Index. Namen worden ingevuld in de streektaal; er kunnen dus ook diakritische of Cyrillische tekens worden gebruikt (bv. Baarlerbrücke, Volkeraksluis of Mannswörth).

Informatie over de kenmerken mag niet worden opgenomen; het soort object wordt niet in de naam herhaald, tenzij extra informatie over het soort object wordt verstrekt.

Bv.: de sluis „Schleuse Freudenau” wordt alleen „Freudenau” genoemd; het objecttype „sluis” wordt automatisch toegevoegd op grond van de type_code.

Bv.: de objectnaam voor de spoorwegbrug in Krems (AT) is „Eisenbahnbrücke Krems”. „Spoorwegbrug” wordt wel in de objectnaam opgenomen, omdat het extra informatie betreft bij de type_code „brug”.

Bv.: de objectnaam voor een brug in Linz (AT) is „Nibelungenbrücke”. Het woord „brücke” wordt in de objectnaam behouden omdat het deel uitmaakt van de eigennaam van de brug.

Bv.: de peilschaal „Pegelstelle Wildungsmauer” wordt „Wildungsmauer” genoemd, omdat de informatie dat het hier om een peilschaal gaat al is gecodeerd in de type_code.

Als een deel van een waterweg de grens tussen twee landen met verschillende talen vormt, mag de naam van het object in beide talen worden opgegeven (bv. „Saatsgrenze AT-SK/Statna hranica AT-SK”).

8.2. Regels voor het element „name” met betrekking tot vaarwegen

Namen van vaarwegen worden gewoonlijk door de NtS-editor ingevuld op basis van referentiegegevens uit de RIS Index. Het veld „name” moet de lokale naam van de betrokken vaarwegsectie bevatten (bv. „Rhein”). Afhankelijk van de nationale procedures kan de naam van de vaarweg worden aangepast en kunnen de gebruikelijke lokale namen of aanvullingen worden ingevoerd (bv. „Rhein am Deutschen Eck”).

8.3. Regels voor de elementen „value” en „unit” in beperkingen

Tenzij anders vermeld, mogen in NtS-berichten alleen de eenheden cm, m3/s, h, km/h en kW, m/s (voor wind), mm/h (voor regen) en graden Celsius worden gebruikt.









NTS ENCODING GUIDE VOOR APPLICATIEONTWIKKELAARS

INHOUD 1. Achtergrond en structuur 1.1. Doel van de NtS Encoding Guide 1.1.1. NtS Encoding Guide voor redacteuren 1.1.2. NtS Encoding Guide voor applicatieontwikkelaars (dit document) 2. NtS-berichten en -secties 3. Basisoverwegingen voor een WRM 3.1. Invullen van de sectie NtS_number in een WRM 3.2. Invullen van verwachtingen in een WRM 4. ICEM-processen 4.1. Nieuw ICEM 4.2. Bijwerking van een bestaand ICEM 5. Basisoverwegingen voor een WERM 5.1. Invullen van de sectie NtS_number in een WERM 5.2. Invullen van de „weather_category_code” in een WERM 6. FTM-processen 6.1. Nieuw FTM 6.2. Bijwerking/intrekking van een bestaand FTM 6.3. FTM met betrekking tot waterwegen en/of objecten 6.4. Automatische ordening van limitation codes 6.5. Bewerking van de duur van een beperking 7. Algemene toepassingsregels 7.1. Invullen van de „number_section” 7.2. Invullen van de elementen „from”, „originator”, „organisation” en „source” 7.3. Weglaten van elementen 7.4. Automatisch invullen van date_issue 7.5. Omgang met informatie over de tijdzone in NtS-berichten 7.6. Bewerking van seconden in NtS-berichten 7.7. Formaat van decimalen in NtS-berichten 7.8. Te gebruiken eenheden in NtS-berichten 7.9. Regels voor de elementen „name”, „position_code” en „type_code” 7.10. Regels voor het element „fairway_name” 7.11. Toelichting bij de vertalingen in de spreadsheet „reference_code” 7.12. Aanbeveling voor het element „coordinate” 7.13. Omgang met doelgroepen 7.14. Weergave van op een bepaald tijdstip geldige berichten 7.15. Niet verplichte functies die de gebruikersvriendelijkheid van NtS-editors vergroten 8. NtS XML-berichtstructuur 9. NtS Web Service 9.1. Doelstelling 9.2. Grondbeginselen en beperkingen 9.2.1. Webnormen 9.2.2. Interactiemodel en codeermethode voor NtS WS 9.3. Algemene specificaties en aanbevelingen 9.3.1. Specificatie: versiegegevens 9.3.2. Specificatie: structuur van namespaces 9.3.3. Aanbeveling: gebruik van namespaces 9.3.4. Aanbeveling: gebruik van namespace-voorvoegsels 9.3.5. Specificatie: gebruik van ISRS Location Codes 9.4. NtS-berichtendienst (implementatiespecificatie) 9.4.1. Verzoek 9.4.2. Antwoord 9.5. Gegenereerde diensten en klanten Woordenlijst

1. Achtergrond en structuur

Berichten aan de scheepvaart (NtS) worden in verschillende Europese landen toegepast op grond van Verordening (EG) nr. 416/2007 van de Commissie betreffende de technische specificaties voor berichten aan de scheepvaart als bedoeld in artikel 5 van Richtlijn 2005/44/EG van het Europees Parlement en de Raad betreffende RIS. De NtS-standaard wordt voortdurend verbeterd. Grote stappen voorwaarts waren het uitbrengen van een NtS web service die de uitwisseling van NtS-berichten tussen instanties onderling en instanties en NtS-gebruikers vergemakkelijkte, en van NtS XSD 4.0, waardoor de codering van NtS-berichten werd gestroomlijnd.

1.1. Doel van de NtS Encoding Guide

De NtS Encoding Guide verklaart de toepasselijkheid van de vier NtS-berichttypes en de codes die in bepaalde gevallen moeten worden gebruikt. NtS-redacteuren vinden er instructies voor het invullen van een NtS-bericht, zodat die berichten op nationaal en internationaal gestandaardiseerde wijze worden gecodeerd.

Gezien het toenemende gebruik van de NtS web service zullen NtS-berichten verder worden gestandaardiseerd, zodat de inhoud ervan correct wordt weergegeven op de systemen van derden. De eenduidige codering van berichten is ook een vereiste voor de verwerking van berichten in applicaties voor reisplanning. De NtS Encoding Guide versie 1.0 is van toepassing op NtS XSD 4.0 en NtS Web Service WSDL 2.0.4.0.

1.1.1. NtS Encoding Guide voor redacteuren

De NtS Encoding Guide voor redacteuren is bestemd voor diegenen die NtS-berichten opstellen (en publiceren) en bevat stap-voor-stap instructies voor het opstellen van de juiste berichttypes en een verklaring van de codes. De Encoding Guide voor redacteuren bevat ook relevante informatie voor applicatieontwikkelaars.

1.1.2. NtS Encoding Guide voor applicatieontwikkelaars (dit document)

De NtS Encoding Guide voor ontwikkelaars bevat richtsnoeren voor de ontwikkeling van NtS-applicaties en verklaart de logica, de processen en de standaardwaarden ervan.

2. NtS-berichten en -secties

Een NtS bericht bestaat uit de volgende secties:

— de identificatiesectie

— een sectie waarin de desbetreffende objecten of vaarwegsecties worden gedefinieerd waarop het bericht betrekking heeft;

— een of meer van de volgende secties volgens het berichttype: — — beperkingen, als het een bericht met betrekking tot vaarwegen en verkeer betreft, — metingen, als het een bericht met betrekking tot de waterstand betreft, — toestand van het ijs, als het een ijsbericht betreft, — weerberichten, als het een bericht met betrekking tot het weer betreft.

Figuur 2

Voorstelling van de structuur van een NtS-bericht: verplicht element (1), verplicht element dat éénmaal of tweemaal mag voorkomen (1…2), verplicht element dat tweemaal moet voorkomen (2), verplichte elementen die zo vaak als nodig mogen voorkomen (1-n), facultatief element dat zo vaak als nodig mag voorkomen (0…n)

De identificatiesectie is verplicht; ze bevat algemene informatie over de auteur, de afzender, de publicatiedatum, het land en de originele taal en wordt verstrekt samen met een van de vier verschillende secties volgens het NtS-berichttype:

— sectie met betrekking tot vaarwegen en verkeer: een „bericht met betrekking tot vaarwegen en verkeer” (FTM) wordt gewoonlijk door NtS-redacteuren opgesteld aan de hand van de NtS Encoding Guide voor redacteuren. Het heeft betrekking op gedeelten van waterwegen (gedefinieerd aan de hand van begin- en eind-ISRS Location Codes en/of objecten op de waterweg die zijn omschreven met hun respectieve ISRS Location Code). [ga naar hoofdstuk 6]

— sectie met betrekking tot de waterstand: een „bericht met betrekking tot de waterstand” (WRM) maakt het verstrekken van informatie over de actuele en verwachte waterstanden en andere gegevens mogelijk. Een WRM wordt gewoonlijk automatisch (en periodiek) aangemaakt op basis van sensormetingen of de status van infrastructuur; de tussenkomst van een NtS-redacteur is niet vereist. De sectie met betrekking tot de waterstand bevat informatie over een object (bv. een peilstation) of een deel van een vaarweg (bv. de minst gepeilde diepte of het geldende regime op een deel van een waterweg). Het object wordt geïdentificeerd aan de hand van zijn ISRS Location Code, de vaarwegsectie wordt afgebakend door de begin- en eind-ISRS Location Codes. [ga naar hoofdstuk 3]

— ijsbericht: een „ijsbericht” (ICEM) bevat informatie over de toestand van het ijs op een deel van een vaarweg dat wordt afgebakend door de begin- en eind-ISRS Location Codes. [ga naar hoofdstuk 4]

— bericht met betrekking tot het weer: via een „bericht met betrekking tot het weer” (WERM) kan informatie worden verstrekt over de actuele en verwachte weersomstandigheden op een gedeelte van een waterweg dat wordt afgebakend door de begin- en eind-ISRS Location Codes. [ga naar hoofdstuk 5]

Bovendien wordt de ISRS Location Code (International Ship Reporting Standard) gebruikt om de objecten of vaarwegsecties te definiëren waarop het bericht betrekking heeft.

De ISRS Location Code is gedefinieerd in punt 4.3 van de bijlage bij deze verordening.

3. Basisoverwegingen voor een WRM

Informatie over de waterstand is van groot belang voor de reisplanning en de veiligheid. Op dit moment is er geen algemene referentiestandaard voor informatie over de waterstand. De peilwaarden worden opgegeven ten opzichte van verschillende zeespiegelniveaus of speciale referentiepunten. Om voor een correcte referentie te zorgen, wordt de betrokken „reference_code” altijd de bij waarde verstrekt. Een WRM kan worden gebruikt om de volgende informatie te verstrekken:

— waterstand (met verwachtingen),

— minst gepeilde diepte (met verwachtingen),

— doorvaarthoogte (met verwachtingen),

— afvoer (met verwachtingen),

— stuwstand,

— regime.

Toelichting bij de vertalingen in de spreadsheet „reference_code” wordt verstrekt in hoofdstuk 7.11.

Een WRM wordt gewoonlijk automatisch gegenereerd en gepubliceerd op basis van gegevens van sensoren of infrastructuur (bv. verwachtingen, stuwstand). Er zijn verschillende factoren die aanleiding kunnen geven tot de publicatie van een WRM, bv. op periodieke basis of wanneer bepaalde waarden worden bereikt.

3.1. Invullen van de sectie NtS_number in een WRM

In NtS XSD 4.0 is het NtS_number in WRM-berichten niet verplicht. Elk opgegeven nummer moet uniek zijn (Organisation/Year/Number/Serial) voor elk berichttype; de organisatie die het WRM aanlevert moet voor die unieke nummers zorgen (ze hoeven elkaar niet op te volgen).

3.2. Invullen van verwachtingen in een WRM

In de date_start van de validity_period moet de actuele datum (date_issue) worden ingevuld en in de date_end van de validity_period moet de dag na de date_issue worden ingevuld.

Om bijvoorbeeld wijzigingen in een waterstand op een gebruikersvriendelijke manier te verstrekken, mag het verschil ten opzichte van een vorige vergelijkende meting worden opgenomen in de sectie „difference” van een WRM. Niet alleen het verschil in waarde (bv. - 5 [cm]) moet worden opgegeven, maar ook het tijdsverschil ten opzichte van de vergelijkende meting.

Bij verwachtingen wordt als „measure_date” de datum/tijd opgegeven waarvoor de verwachting geldt.

Verwachtingen van de waterstand bevatten altijd enige mate van onzekerheid. Gewoonlijk leiden modellen met verschillende parameters (bv. de weersverwachting) tot verschillende waarden voor de verwachte waterstand. Om een minimale en maximale verwachte waarde mogelijk te maken, bv. de visualisering van de betrouwbaarheidsinterval van de verwachte waterstand, zijn in de sectie „measure” van het WRM twee extra facultatieve gegevensvelden opgenomen.

De volgende figuur illustreert een betrouwbaarheidsinterval van de verwachte waterstand:

Figuur 3

Voorstelling van een betrouwbaarheidsinterval van de verwachte waterstand: meest waarschijnlijke waarde (zwart), bovengrens van de betrouwbaarheidsinterval (violet), ondergrens van de betrouwbaarheidsinterval (rood), gemeten waterstand (blauw).

De X-as is de tijd; de Y-as is de waterstand in cm.

In de NtS XSD zijn twee elementen beschikbaar:

<value_min> laagste waarde van de betrouwbaarheidsinterval

<value_max> hoogste waarde van de betrouwbaarheidsinterval

Behalve voor de verwachte waterstanden kan de betrouwbaarheidsinterval ook worden gebruikt om de onzekerheid aan te geven over de gepubliceerde minst gepeilde diepte en doorvaarthoogte.

De value_min en value_max van de betrouwbaarheidsinterval maken het mogelijk om de betrouwbaarheidsinterval van de WRM-waarde te verstrekken via een gestandaardiseerd NtS WRM-bericht voor gebruik in grafieken. IWT-gebruikers krijgen de ruwe gegevens niet te zien (bv. in codeformaat).

De measure_code „NOM” mag niet worden gebruikt. Als er voor een bepaald type WRM geen metingen zijn maar er toch een bericht wordt verstuurd, moet de waarde leeg worden gelaten.

4. ICEM-processen

IJsberichten zijn gebaseerd op waarnemingen en beoordelingen ter plaatse en worden doorgaans handmatig opgesteld (in het geval van automatische opstelling moeten de regels voor handmatige opstelling worden gevolgd, zie de NtS Encoding Guide voor redacteuren).

Een ICEM wordt gepubliceerd voor een bepaalde fairway_section die wordt gedefinieerd aan de hand van de begin- en eind-ISRS Location Codes, en bevat de ice_condition op een bepaalde metingsdatum.

Het ICEM geldt vanaf de datum van publicatie (die automatisch wordt ingesteld door de NtS-applicatie). Om te voorkomen dat gebruikers een ICEM te zien krijgen dat niet langer geldig is, moet de NtS-applicatie automatisch de dag na de publicatie invullen als de date_end van de geldigheid (tenzij door nationale processen wordt gewaarborgd dat de geldigheid van het bericht een date_end krijgt zodra de informatie in het bericht niet langer actueel is).

In de NtS Encoding Guide voor redacteuren is beschreven onder welke omstandigheden een NtS-editor een nieuw ICEM creëert of een bestaand ICEM bijwerkt. De volgende processen zijn van toepassing:

4.1. Nieuw ICEM

1) NtS-applicaties kunnen NtS-redacteuren de volgende mogelijkheden bieden:

a. bestaande berichten als ontwerp gebruiken voor het aanmaken van een nieuw ICEM (bv. als de toestand van het ijs vergelijkbaar is met die van het bestaande bericht) en/of

b. berichtmodellen voor bepaalde situaties gebruiken.

2) De inhoud (bv. tijdstip van de meting of toestand van het ijs) moet door de redacteur worden ingevoerd overeenkomstig hoofdstuk 6 van de NtS Encoding Guide voor redacteuren. De datum en het tijdstip van de meting kunnen ook door de applicatie worden ingesteld volgens nationale definities.

3) Wanneer een redacteur/uitgever van NtS de actie „publiceren” op gang brengt,

a. wordt gecontroleerd of alle verplichte inhoud overeenkomstig NtS XSD wordt geleverd (zo niet, ga terug naar 2)),

b. wordt het nts_number aangemaakt door de NtS-applicatie,

i. wordt onder „organisation” de naam of code van de verantwoordelijke organisatie ingevuld, afhankelijk van de rol van de publicerende gebruiker,

ii. wordt onder „year” het lopende jaar ingevuld,

iii. wordt het volgende beschikbare „number” toegewezen,

iv. wordt het „serial number” 0 toegewezen.

c. wordt onder „date_issue” automatisch de actuele datum/tijd van de publicate-actie ingevuld,

d. wordt onder „validity_period” –„date_start” automatisch de actuele datum van de publicatie ingevuld,

e. wordt onder „validity_period” — „date_end” automatisch de dag na de datum van publicatie ingevuld (tenzij door nationale processen wordt gewaarborgd dat de geldigheid van het bericht een date_end krijgt zodra de informatie in het bericht niet langer actueel is).

4.2. Bijwerking van een bestaand ICEM

1) Het gepubliceerde bericht moet worden geselecteerd en bijgewerkt in de ICEM-editor. Het originele ICEM moet worden gekopieerd of gewijzigd in de DB (afhankelijk van de nationale processen). Een vervallen ICEM (waarvan validity_date_end is verstreken) kan niet meer worden bijgewerkt; in dat geval moet de NtS-redacteur een nieuw ICEM aanmaken.

2) De inhoud (bv. tijdstip van de meting of toestand van het ijs) moet door de redacteur worden gewijzigd overeenkomstig hoofdstuk 6 van de NtS Encoding Guide voor redacteuren. De datum en het tijdstip van de meting kunnen ook door de applicatie worden gewijzigd overeenkomstig de nationale definities.

3) Wanneer een redacteur/uitgever van NtS de actie „publiceren” op gang brengt,

a. wordt gecontroleerd of alle verplichte inhoud overeenkomstig NtS XSD wordt geleverd (zo niet, ga terug naar 2)),

b. wordt het nts_number aangemaakt door de NtS-applicatie,

i. blijft „organisation” ongewijzigd,

ii. blijft „year” ongewijzigd,

iii. blijft „number” ongewijzigd,

iv. wordt „serial number” verhoogd (met 1),

c. wordt onder „date_issue” automatisch de actuele datum/tijd van de publicatie-actie ingevuld,

d. wordt onder „validity_period” –„date_start” automatisch de actuele datum van de publicatie ingevuld,

e. wordt onder „validity_period” — „date_end” automatisch de dag na de datum van publicatie ingevuld (tenzij door nationale processen wordt gewaarborgd dat de geldigheid van het bericht een date_end krijgt zodra de informatie in het bericht niet langer actueel is).

5. Basisoverwegingen voor een WERM

Een WERM wordt doorgaans automatisch opgesteld en gepubliceerd op basis van gegevens van sensoren of infrastructuur. Onder date_start van de validity_period moet de actuele datum (date_issue) worden ingevuld en onder date_end van de validity_period de dag na de date_issue.

In een WERM wordt de vaarwegsectie aangegeven als een traject tussen twee punten op de vaarweg, d.w.z. het toepassingsgebied van het weerstation (meetinstrument).

Datum en tijdstip van de meting/voorspelling moeten worden vermeld, ook al is dat in WERM-berichten niet verplicht.

Bij verwachtingen is de „measure_date” de datum/tijd waarvoor de verwachting geldt.

5.1. Invullen van de sectie NtS_number in een WERM

In NtS XSD 4.0 is het NtS_number in WERM-berichten niet verplicht. Elk opgegeven nummer moet het uniek zijn (Organisation/Year/Number/Serial) voor elk soort bericht; de organisatie die het WERM aanlevert moet voor die unieke nummers zorgen (ze hoeven elkaar niet op te volgen).

5.2. Invullen van de „weather_category_code” in een WERM

De windsnelheid in „weather_category_code” (waarde 0 tot en met 12) wordt opgegeven volgens de Beaufortschaal in het handboek inzake mariene meteorologische diensten van de Wereld Meteorologische Organisatie (WMO-Nr. 558).

De zichtbaarheid in „weather_category_code” (waarde 13 tot en met 22) wordt opgegeven overeenkomstig de volgende tabel:







Waarde, betekenis Zichtbaarheid Aanvullende informatie 13, dikke nevel minder dan 50 meter 14, dichte nevel minder dan 100 meter 15, gemiddelde nevel minder dan 200 meter 16, nevel minder dan 1 000 meter De nevel bestaat uit waterdruppels. 17, mist van 1 tot 4 km De mist bestaat uit waterdruppels. Mist wordt gebruikt in het geval van „droge mist”, een fenomeen dat zich gewoonlijk bij zonsopgang voordoet. 18, waas van 1 tot 4 km De waas bestaat uit droge deeltjes. 19, lichte waas van 4 tot 10 km 20, open van 10 tot 20 km 21, zeer open zichtbaarheid onbelemmerd 22, geen mist „geen mist” wordt gebruikt om aan te geven dat er volgens de nationale/lokale voorschriften geen sprake is van mist.

6. FTM-processen

In de NtS Encoding Guide voor redacteuren wordt beschreven onder welke omstandigheden een NtS-editor een nieuw FTM aanmaakt of een bestaand FTM bijwerkt. De volgende processen zijn van toepassing:

6.1. Nieuw FTM

1) NtS-applicaties kunnen NtS-redacteuren de volgende mogelijkheden bieden:

a. bestaande berichten gebruiken als ontwerp voor de aanmaak van een nieuw FTM, en/of

b. berichtmodellen voor bepaalde situaties gebruiken.

2) De inhoud (bv. geldigheidsperiode, beperkingen) moet door de redacteur worden ingevuld overeenkomstig de hoofdstukken 3 en 4 van de NtS Encoding Guide voor redacteuren.

3) Wanneer een redacteur/uitgever van NtS de actie „publiceren” op gang brengt,

a. wordt gecontroleerd of alle verplichte inhoud overeenkomstig NtS XSD wordt geleverd (zo niet, ga terug naar 2)),

b. wordt het nts_number aangemaakt door de NtS-applicatie,

i. wordt onder „organisation” de naam of code van de publicerende organisatie ingevuld,

ii. wordt onder „year” het lopende jaar ingevuld,

iii. wordt het volgende beschikbare „number” toegewezen; als in stap 2 een toegewezen nummer werd ingevuld door de NtS-redacteur of een applicatieproces, wordt dat overgenomen (aangezien (Organisation/Year/Number/Serial) uniek is, zoals toegelicht in hoofdstuk Error! Reference source not found.),

iv. wordt het „serial number” 0 toegewezen,

c. wordt onder „date_issue” automatisch de actuele datum/tijd van de publicatie-actie ingevuld.

6.2. Bijwerking/intrekking van een bestaand FTM

1) Het desbetreffende gepubliceerde bericht moet voor bijwerking worden geselecteerd in de FTM-editor; het originele FTM moet worden gekopieerd of gewijzigd in de DB (afhankelijk van de nationale processen).

a. Een vervallen FTM (waarvan de validity_date_end is verstreken) kan niet meer worden bijgewerkt; in dat geval moet de NtS-redacteur een nieuw FTM aanmaken.

b. De subject_code „bericht ingetrokken” wordt alleen gebruikt als:

i. de huidige datum vóór de validity_date_start valt. In dat geval mag alleen de inhoud van het veld „aanvullende informatie in de nationale taal” worden gewijzigd, de gecodeerde inhoud van het bericht (stap 2) moet ongewijzigd blijven;

ii. de geldigheidsperiode reeds van start gegaan is en de nieuwe einddatum voor alle beperkingen in het verleden ligt. De einddatum van de beperking moet worden ingesteld op het correcte tijdstip.

c. Als een bericht wordt ingetrokken, moet de einddatum van de geldigheidsperiode altijd worden ingesteld op de datum van intrekking.

2) De inhoud (bv. geldigheidsperiode, beperkingen) moet door de redacteur worden gewijzigd overeenkomstig de hoofdstukken 3 en 4 van de NtS Encoding Guide voor redacteuren.

3) Wanneer een redacteur/uitgever van NtS de actie „publiceren” op gang brengt,

a. wordt gecontroleerd of alle verplichte inhoud overeenkomstig NtS XSD wordt geleverd (zo niet, ga terug naar 2)),

b. wordt het nts_number aangemaakt door de NtS-applicatie,

i. blijft „organisation” ongewijzigd,

ii. blijft „year” ongewijzigd,

iii. blijft „number” ongewijzigd,

iv. wordt „serial number” verhoogd (met 1),

c. wordt onder „date_issue” automatisch de actuele datum/tijd van de publicatie-actie ingevuld.

b. Een FTM met subject_code „bericht ingetrokken” wordt niet (meer) in aanmerking genomen bij de reisplanning.

6.3. FTM met betrekking tot waterwegen en/of objecten

Een FTM met betrekking tot waterwegen bevat informatie over een of meer gedeelten van een waterweg. Een gedeelte van een waterweg wordt in het deel „fairway_section” gedefinieerd door zijn begin- en eind-ISRS Location Codes.

Een FTM met betrekking tot objecten bevat informatie over een of meer objecten op de waterweg. Een object wordt in het deel „object” gedefinieerd aan de hand van zijn ISRS Location Code.

Een FTM moet verwijzen naar

— een of meer gedeelten van een vaarweg of

— een of meer objecten op een of meer gedeelten van een vaarweg.

6.4. Automatische ordening van limitation codes

De gevolgen voor de scheepvaart variëren naar gelang van de beperking. Om de ernstigste beperking te kunnen weergeven, bijvoorbeeld in een overzichtslijst van FTM-berichten, wordt de onderstaande volgorde in acht genomen, te beginnen met de ernstigste beperking (rang 1):







Rangschikking Waarde Betekenis (EN) 1 OBSTRU blockage 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. Bewerking van de duur van een beperking

— Beperkingen met dezelfde geldigheidsperiode moeten gegroepeerd/gecombineerd/samen vermeld worden om het overzicht lezersvriendelijk te houden.

— NtS-editors moeten over een functie beschikken waardoor redacteuren de duur van beperkingen niet telkens opnieuw hoeven in te tikken.

— Alle beperkingen moeten een geldigheidsperiode met een intervalcode omvatten, zodat applicaties voor reisplanning correcte berekeningen kunnen uitvoeren. Om het werk van NtS-redacteuren te vergemakkelijken, kunnen de volgende functies worden aangeboden: — — de NtS-editor kan een functie bieden om reeds ingevoerde beperkingen te kopiëren, zodat een NtS-redacteur de geldigheidsperiode niet opnieuw hoeft in te tikken; — de NtS-editor kan een functie bieden om meer dan één limitation code voor de specifieke geldigheidsperiode van een beperking te selecteren en automatisch de vereiste limitation sections aan te maken op grond van de door de NtS-redacteur ingevoerde gegevens.

— „Maandag tot en met vrijdag, uitgezonderd feestdagen”: „feestdagen” is een heel moeilijke waarde voor applicaties voor reisplanning. Om een correcte berekening te kunnen uitvoeren, is voor elk land een lijst van feestdagen nodig. Als een dergelijke lijst niet beschikbaar is, zullen de respectieve beperkingen toch aan feestdagen worden toegekend.

— „met uitzondering van”: mag niet gebruikt worden; onderbroken periodes moeten als afzonderlijke beperkingsperiodes binnen dezelfde beperking worden opgegeven; daarom is deze code niet zichtbaar/beschikbaar voor redacteuren.

— Logica en weergave van toepasbare informatie voor de interval_code „continuous”: — <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> — Als de interval_code „continuous” is, hoort de start_time bij de start_date en de end_time bij de end_date, bv. van 1 april 06:00 tot 30 juni 10:00.

— Logica en weergave van toepasbare informatie voor een andere interval_code dan „continuous”: — <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> — Als de interval_code een andere waarde heeft, horen start_time en end_time bij die interval_code, bv. van 1 april tot en met 30 juni Maandag tot en met vrijdag van 06:00 tot 10:00

— De time_end van de beperking moet altijd worden ingevuld in de laatste versie van een bericht.

7. Algemene toepassingsregels

Er moet rekening worden gehouden met het volgende:

— Bij de bouw van NtS-applicaties (zoekfilters, elektronisch inschrijvingsformulier, weergave van berichten) wordt rekening gehouden met de tabel „GUI_labels” in de NtS Reference Tables.

— De date_end kan niet vóór de date_start liggen.

— Codes die zijn uitgeschakeld (die niet meer gebruikt mogen worden) via wijzigingsverzoeken voor NtS (zie opmerkingen in de NtS XSD) zijn bij het aanmaken van nieuwe berichten niet zichtbaar voor NtS-redacteuren. De codes zijn wel nog opgenomen in de NtS XSD-opsommingen met het oog op achterwaartse compatibiliteit.

7.1. Invullen van de „number_section”

Elk nummer (Organisation/Year/Number/Serial) moet voor elk berichttype uniek zijn. Dat betekent dat verschillende berichttypes wel hetzelfde NtS-nummer kunnen hebben.

Voor gebruikers zijn de berichtnummers alleen relevant in het geval van een FTM en ICEM; voor alle andere berichttypes kan de weergave van het berichtnummer worden overgeslagen, afhankelijk van de nationale voorschriften.

Gebruikers krijgen het berichtnummer in het volgende formaat te zien: „Message Type/Country/Organisation/Year/Number/Serial” (afhankelijk van de toegepaste filters kan dit worden ingekort, op voorwaarde dat geen informatie verloren gaat).

7.2. Invullen van de elementen „from”, „originator”, „organisation” en „source”

Onder het element „from” in de identificatiesectie wordt de naam ingevuld van het nationaal systeem dat het bericht verstrekt (bv. ELWIS, DoRIS, SLOVRIS, FLARIS).

Het element „originator” is de organisatie die de berichten in de nationale systemen invoert.

Het element „source” is de bron/autoriteit waarvoor het FTM wordt gepubliceerd.

Het element „organisation” in de sectie „nts_number” is de naam van de organisatie die het nts_number toewijst (NtS-provider).

7.3. Weglaten van elementen

Elementen die alleen standaardwaarden bevatten worden weggelaten als zij niet verplicht zijn, omdat ze leiden tot extra data zonder toegevoegde waarde.

Het gaat om de volgende elementen:

— Target group: target_group_code ALL met direction_code ALL (als er in het bericht geen andere specifieke doelgroepen zijn),

— position_code: AL,

— reason_code: OTHER.

7.4. Automatisch invullen van date_issue

FTM en ICEM

Voor FTM en ICEM is de waarde van het element „date_issue” de actuele datum en tijd van publicatie. In het geval van bijgewerkte berichten is „date_issue” de datum en tijd waarop de bijwerking werd gepubliceerd.

WRM en WERM

Voor WRM en WERM is de waarde van het element „date_issue” de datum en tijd van het verzoek tot verwerking, omdat één W(E)RM-bericht verschillende metingen met verschillende tijdstempels van uitgave kan bevatten.

7.5. Omgang met informatie over de tijdzone in NtS-berichten

De datum en de tijd worden altijd in lokale tijd weergegeven, met inbegrip van informatie over de tijdzone in NtS XML-berichten.

De enige uitzonderingen daarop zijn „time_start” en „time_end” in de sectie „limitation_period”, omdat in de sectie „limitation” intervallen kunnen worden opgenomen. Als „date_start” en „date_end” in verschillende tijdzones vallen (bv. CEST en CET) zou de informatie over de tijdzone daardoor binnen die interval worden gewijzigd. Die wijziging kan niet door middel van één enkele „limitation period” worden uitgedrukt. In plaats van verschillende „limitation periods” te creëren voor elke tijdswijziging, wordt slechts één „limitation period” zonder informatie over de tijdzone gebruikt om extra data bij de verwerking en de verzending van het bericht te beperken.

7.6. Bewerking van seconden in NtS-berichten

In de regel moeten in (datum-)/tijdvelden seconden worden opgegeven, maar die zijn niet zichtbaar voor NtS-gebruikers. Voor NtS-detailniveau volstaan minuten.

7.7. Formaat van decimalen in NtS-berichten

Decimalen in numerieke velden worden aangegeven met een . (punt). Voor duizendtallen worden geen scheidingstekens gebruikt.

In waarden wordt het aantal decimalen beperkt om een gebruikersvriendelijke weergave te waarborgen.

7.8. Te gebruiken eenheden in NtS-berichten

In NtS-berichten mogen alleen de eenheden cm, m3/s, h, km/h en kW, m/s (voor wind), mm/h (voor regen) en graden Celsius worden gebruikt; in toepassingen mogen die eenheden worden omgezet met het oog op gebruikersvriendelijkheid.

Als de invoer afwijkt van de standaardeenheden, moeten de ingevoerde waarden dienovereenkomstig door de applicatie worden omgezet.

7.9. Regels voor de elementen „name”, „position_code” en „type_code”

Het element „name” wordt vooraf automatisch ingevuld op basis van de „national object name”-referentiegegevens van de RIS Index (als het om een nationaal voorschrift gaat, mogen NtS-redacteuren de vooraf ingevulde naam aanpassen). De naamgevingsconventies voor objectnamen zijn opgenomen in versie 2.0 of hoger van de RIS Index Encoding Guide. Voorbeelden van correcte objectnamen zijn ook te vinden in de NtS Encoding Guide voor redacteuren.

De „type code” wordt door de NtS-applicatie aan het object toegevoegd vóór de objectnaam.

De positie van objecten wordt gecodeerd aan de hand van de „position code” en door de NtS-applicatie aan het object toegevoegd vanuit de RIS Index. Redacteuren kunnen de vooraf ingevulde „type” en „position codes” wijzigen. Voor „geo_objects” wordt de „position code” van een object niet in de „fairway_section” opgegeven.

De volledige naam van een object bestaat uit de „position code”, de „type code” en de naam.

Om het werk van NtS-redacteuren te vergemakkelijken, kan de volgende koppeltabel in de NtS-editor worden opgenomen, zodat redacteuren de juiste objecten kunnen vinden en selecteren op basis van de „function_code” van de RIS Index of de „type_code” van NtS:

Tabel 1

Overeenkomstige „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. Regels voor het element „fairway_name”

Om applicatielogica / noodzaak van juiste referentiegegevens in het ontvangende systeem (software voor weergave van het bericht aan de gebruiker) te vermijden, moet het niet verplichte element „fairway_name” altijd worden opgenomen in het „geo_object” en moet de „waterway name” uit de RIS Index automatisch door de NtS-applicatie worden ingevuld. NtS-redacteuren mogen de inhoud van het element „fairway_name” niet wijzigen.

7.11. Toelichting bij de vertalingen in de spreadsheet „reference_code”

Voor de waarden van de reference_code in de NtS Reference Tables wordt de volgende definitie toegepast:

— NAP: In Nederland wordt de afkorting NAP gebruikt en begrepen; NAP wordt niet vertaald

— KP: „channel level” wordt in de nationale taal vertaald

— FZP: alleen de afkorting „FZP” wordt gebruikt (wordt tegenwoordig nog nauwelijks gebruikt)

— ADR: „Adriatische Zee” wordt in de nationale taal vertaald

— TAW/DNG: „Tweede algemene waterpassing” (Nederlands) — „Deuzième Nivellement Général” (Frans) is de in België gebruikte referentiehoogte om hoogtemetingen uit te drukken. 0 is het gemiddelde zeeniveau bij laag water in Oostende. — — Nederlands: TAW — Frans: DNG — Alle andere talen: TAW/DNG

— LDC: „low navigable water level Danube Commission” wordt in de nationale taal vertaald

— HDC: „high navigable water level Danube Commission” wordt in de nationale taal vertaald

— ETRS: „European Terrestrial Reference System 1989”. De afkorting „ETRS89” wordt in alle talen gebruikt

7.12. Aanbeveling voor het element „coordinate”

Hoewel het element „coordinate” in de sectie „geo_object” niet verplicht is, worden de geo-coördinaten opgegeven in WGS84-formaat [d]d mm.mmm[m] N (breedte) en [d][d]d mm.mmm[m] E (lengte) als geografische referentie voor NtS-berichten.

7.13. Omgang met doelgroepen

De sectie „target group” bestaat uit de „traget group code” en de „direction code”. Als beide de waarde ALL hebben, wordt de volledige sectie weggelaten indien het bericht geen andere specifieke doelgroepen heeft. Als slechts een van de twee wordt opgegeven, moet in de andere de standaardwaarde ALL worden ingevuld omdat beide elementen verplicht zijn.

Meer informatie over doelgroepen is te vinden in de NtS Encoding Guide voor redacteuren.

7.14. Weergave van op een bepaald tijdstip geldige berichten

De validity_period word door applicaties gebruikt om berichten te selecteren die zichtbaar moeten zijn voor gebruikers voor een gevraagde periode.

Als de subject_code INFSER (informatieservice) is, wordt validity period gebruikt om de periode te specificeren waarin het informatieservicebericht zichtbaar is voor gebruikers, niet om de geldigheidsperiode van de meegedeelde informatie aan te geven (bv. één maand).

7.15. Niet verplichte functies die de gebruikersvriendelijkheid van NtS-editors vergroten

Afhankelijk van de nationale voorschriften kunnen de volgende functies in NtS-editors worden opgenomen:

— NtS-applicaties kunnen NtS-redacteuren de mogelijkheid bieden om concepten van NtS-berichten op te slaan (concepten kunnen worden opgeslagen zonder dat alle verplichte inhoud is ingevuld)

— Voor redacteuren kunnen verschillende gebruikersprofielen gelden (bv. redacteuren die berichten mogen invoeren of wijzigen, uitgevers die berichten mogen publiceren (en ook redigeren)).

8. NtS XML-berichtstructuur

De NtS XML-berichtstructuur en de inhoud en het doel van gegevenselementen worden gedefinieerd en verder toegelicht in aanhangsel C: NtS XML-schemadefinitie (XSD).

9. NtS Web Service

9.1. Doelstelling

Volgens de groep van NtS-expertengroep is web service-technologie een geschikte manier om berichten aan de scheepvaart te verstrekken.

In dit hoofdstuk zijn de specificaties opgenomen van de web service voor het verstrekken van berichten aan de scheepvaart, kortweg de NtS web service. Er is bijzondere aandacht besteed aan het gebruik van algemeen bekende internationale normen.

Eén doelstelling van het conceptuele ontwerp was een goed evenwicht te verzekeren tussen flexibiliteit en robuustheid. De filterparameters zijn in wezen de criteria van de NtS-norm (waterweggedeelte met niet-verplichte rivier-km, geldigheidsperiode, publicatiedatum van het bericht). Gezien de gevallen waarin de web service wordt gebruikt, lijkt dit duidelijk genoeg en wordt tegelijk de complexiteit van de uitvoering beperkt.

Het belangrijkste resultaat is een contract voor de web service, waarin de verzoeken en antwoorden zijn gespecificeerd. De gebruikers van de web service kunnen op dat contract vertrouwen, de aanbieders moeten het naleven. Het contract is gespecificeerd aan de hand van de internationale WSDL-norm.

Elke deelnemende lidstaat voert één of meer web services in voor de verschillende NtS-berichttypes (FTM, WRM, ICEM en WERM) en biedt die aan via internet („NtS message service”).

De technische bijzonderheden voor de invoering van de NtS Web Service, bv. de keuze van de passende datagehelen, applicaties en platformen, vallen niet onder deze specificatie en zijn de verantwoordelijkheid van elke deelnemende lidstaat afzonderlijk.

Met het oog op een veilige communicatie moeten verschillende beveiligingsaspecten en beschermingsdoelstellingen in overweging worden genomen. Afhankelijk van de omstandigheden hoeven niet alle aspecten in overweging te worden genomen. Er kunnen verschillende prioriteiten worden gesteld op het vlak van beveiligingsaspecten en de mate waarin ze worden uitgevoerd. De technische uitvoeringscapaciteit kan een beperking vormen voor de haalbaarheid van een bepaalde maatregel. Alle informatie in het kader van NtS is openbaar. In termen van gegevensbescherming moeten de NtS-gegevens zelf dus niet worden beveiligd. Iedere aanbieder moet voor zichzelf besluiten in welke mate hij dat aspect aan bod laat komen in zijn dienst.

9.2. Grondbeginselen en beperkingen

9.2.1. Webnormen

De NtS Web Service moet voldoen aan het WS-I Basic Profile 1.1. Dat profiel „biedt interoperabiliteitsrichtsnoeren voor een basisreeks van web service-specificaties zonder eigendomsrechten, zoals SOAP, WSDL en UDDI” ( 4 ). De meest relevante standaarden zijn:

— XML-schemadefinitie (XSD),

— Simple Object Access Protocol (SOAP),

— Web Services Description Language (WSDL) en

— Universal Description, Discovery and Integration (UDDI).

Het antwoordbericht van de NtS Web Service is een NtS-bericht dat is gedefinieerd in de XML-schemadefinitie (XSD) in aanhangsel C van deze verordening van de Commissie.

SOAP is een applicatieprotocol voor datatransmissie tussen IT-systemen en is genormeerd door de World Wide Web Consortiums (W3C). De specifieke elementen van de NtS Web Service zijn gedefinieerd volgens de overeenkomstige WSDL-specificaties in aanhangsel D van deze verordening van de Commissie. Het schema van de NtS-norm (XSD) is opgenomen met een importeursverklaring.

UDDI (Universal Description, Discovery and Integration) wordt hier vermeld als een centraal, mogelijk internationaal register voor web services, waarin de NtS Web Service geregistreerd zou kunnen worden. Potentiële klanten van de web service zouden de dienst in dat register kunnen opzoeken. Maar omdat de deelnemende lidstaten het aantal potentiële aanbieders van de NtS Web Service beperken en de WSDL-specificatie integraal deel uitmaakt van de standaard, lijkt er geen uitgesproken behoefte te bestaan om de NtS Web Service op onafhankelijke wijze te registreren.

9.2.2. Interactiemodel en codeermethode voor NtS WS

Voor de NtS Web Service wordt de document/literal wrapped-codeermethode gebruikt, omdat validatie tegenover een XML-schema mogelijk is en de in WSDL-specificatie gedefinieerde „operation names” rechtstreeks als XML-tagnamen worden gebruikt in de SOAP-berichten.

9.3. Algemene specificaties en aanbevelingen

9.3.1. Specificatie: versiegegevens

De versiegegevens van de NtS Web Service bestaan uit twee delen:

— de versie van de web service zelf,

— de versie van het door de web service gebruikte NtS-schema.

Het deel met de web service zelf bestaat uit twee delen:

— de hoofdversie van de web service,

— de onderversie van de web service.

De hoofdversie wordt opgegeven als een positief geheel getal dat de hoofdversie van de web service aangeeft.

De onderversie wordt opgegeven als een niet-negatief geheel getal dat de onderversie van de web service aangeeft.

Het deel met het NtS-schema bevat de versie van het NtS-schema als gedefinieerd door de NtS-expertengroep.

De hier gespecificeerde versie van de NtS Web Service is bijgevolg 2.0.4.0, waarbij de versie van de web service zelf 2.0 is en de versie van het gebruikte NtS-schema 4.0.

Voor verzoeken of antwoorden van de NtS Web Service is uitdrukkelijke informatie over de versie niet noodzakelijk. Wellicht zullen slechts enkele versies van de web services tegelijk online zijn. Verschillende versies krijgen verschillende url's. Elke instantie met een NtS Web Service zal derhalve één specifieke versie van de NtS Web Service ondersteunen.

9.3.2. Specificatie: structuur van namespaces

De namespaces in de NtS Web Service zijn gebaseerd op het domein van de RIS-expertengroep, http://www.ris.eu/.

De namespaces bevatten een gedeelte waarin de overeenkomstige service- en versiegegevens worden vermeld. De hier gespecificeerde service gebruikt derhalve de volgende namespace:

NtS Message Service: http://www.ris.eu/nts.ms/2.0.4.0

9.3.3. Aanbeveling: gebruik van namespaces

Om de transparantie van XML-documenten te vergroten, wordt aanbevolen om namespaces te definiëren in het buitenste passende element van de schema's en de instancedocumenten, en geen gebruik te maken van lokale namespace-definities in ingebedde elementen.

9.3.4. Aanbeveling: gebruik van namespace-voorvoegsels

Verzoeken en antwoorden in de NtS Web Service gebruiken XML-elementen in gekwalificeerde vorm, d.w.z. met een expliciet namespace-voorvoegsel, en XML-attributen in ongekwalificeerde vorm, d.w.z. zonder namespace-voorvoegsel.

Om de leesbaarheid voor de mens te verbeteren wordt aanbevolen om intuïtieve namespace-voorvoegsels als „nts” te gebruiken.

9.3.5. Specificatie: gebruik van ISRS Location Codes

De ISRS Location Code wordt toegelicht in hoofdstuk 2 van de NtS Encoding Guide voor applicatieontwikkelaars en in de RIS Index Encoding Guide.

Als een klant een zoekopdracht invoert in een NtS Web Service, kan hij verschillende objecten invoeren, bv. vaarwegsecties, peilschalen of sluizen. Als de corresponderende parameters (ID-elementen) worden gebruikt, moeten zij ISRS Location Codes bevatten. Die parameters worden gewoonlijk als ID-elementen opgegeven, elk met één of twee ID's.

Voor het gebruik van die parameters moeten de volgende algemene afspraken in acht worden genomen:

— ISRS Location Codes moeten worden ingevoerd als volledige codes van 20 tekens, d.w.z. zonder achterliggende nullen weg te laten.

— Als in een ID-element twee ID's worden gebruikt, moeten beide ISRS Location Codes naar dezelfde waterweg verwijzen. Dat betekent dat de codes enkele identieke cijfers bevatten in het deel „fairway_section” van de ISRS Location Code. De code „fairway_section” definieert samen met de vaarweghectometer een waterwegtraject dat wordt opgegeven als een paar ID-elementen.

Voor het opgeven van waterwegtrajecten (paren van ID-elementen in het „geo_object” van de „fairway_section”) in NtS-berichten moet in verband met ISRS Location Codes het volgende in acht worden genomen:

— cijfers 1 tot en met 2 (country code): — — moeten binnen het ID-paar identiek zijn, maar — als buurlanden dezelfde „fairway_section”-code voor een specifieke waterweg gebruiken en hetzelfde systeem toepassen om hectometers te bepalen, kunnen verschillende „country codes” binnen één ID-paar worden gedefinieerd;

— cijfers 3 tot en met 5 (UN Location Code): — — zijn niet relevant, kunnen binnen het ID-paar verschillende inhoud bevatten;

— cijfers 6 tot en met 10 (fairway section code): — — moeten binnen het ID-paar identiek zijn, maar — [uitzondering]: als in de NtS WS Belgische ISRS-codes worden gebruikt, mogen alleen de cijfers 6 tot en met 8 worden gebruikt om de „fairway section” te identificeren, omdat NtS-berichten zullen worden gepubliceerd over verschillende secties van één vaarweg;

— cijfers 11 tot en met 15 (object reference code): — — zijn niet relevant, kunnen binnen het ID-paar verschillende inhoud bevatten;

— cijfers 16 tot en met 20 (fairway hectometre): — — bestaat uit vijf numerieke tekens die de hectometer bepalen, en zal bijgevolg binnen het ID-paar doorgaans verschillende inhoud bevatten. Voorbeeld: „00235” voor vaarwegkilometer 23,5 ; „00001” voor vaarwegkilometer 0,1 , — [uitzondering]: in Nederland is er niet altijd een rechtstreeks verband tussen de vaarweghectometer en de fysieke kilometer van de vaarweg, omdat de bepaling van het begin van het vaarwegtraject in het netwerkmodel afwijkt van de werkelijkheid; in dergelijke gevallen begint de object reference code voor objecten van het type „dismar” met Kxxxx (xxxx geeft de fysieke kilometer aan, bv. NLSVG00130K000300191 (km 3)). Voor andere objecttypes is er echter geen rechtstreeks verband met de fysieke vaarwegkilometer in de ISRS-codes, bv. de brug van Sas van Gent ter hoogte van km 2,5 op dezelfde vaarweg heeft als ISRS-code NLSVG001300521600186. Voor het Kanaal Gent-Terneuzen bevindt fysieke km 0,0 zich op de grens tussen België en Nederland, maar vaarweghectormeter 0,0 bevindt zich aan het begin van het kanaal in Gent.

Als een bericht betrekking heeft op meer dan één waterweg of vaarwegsectie, moeten alle vaarwegsecties worden bepaald door middel van hun begin- en eindpunt in afzonderlijke XML-elementen voor de „fairway_section”.

Voor sommige landen/regio's moet verplicht een filterfunctie worden ingebouwd. Bijvoorbeeld: als ISRS Location Code (1-2) BE is, gebruik dan ISRS Location Code (6-8) als ID voor lineaire referentie naar de vaarweghectometer (ISRS Location Code 16-20). Voorbeelden van vaarwegtrajecten (geldige paren van ID-elementen binnen de fairway_section) die de hierboven beschreven uitzonderingen bevatten:

— de twee Nederlandse ISRS Location Codes vormen een geldige definitie van een waterwegtraject (illustreert de uitzondering in Nederland in verband met de vaarwegkilometer). NLSVG00130K000300191 (km 3,0 ter hoogte van Sas van Gent op het Kanaal Gent-Terneuzen) — NLWDP00130K000400200 (km 4,0 ter hoogte van Westdorpe op het Kanaal Gent-Terneuzen);

— de twee Belgische ISRS Location Codes vormen een geldige definitie van een waterwegtraject (illustreert de uitzondering in België in verband met de fairway section code („020” Albertkanaal)): BEGNK02016L010100414 (sluis van Genk ter hoogte van km 41,4 op het Albertkanaal) — BEOSH02033L010500772 (sluis van Ham ter hoogte van km 77,2 op het Albertkanaal).

In de volgende figuur zijn tegenvoorbeelden opgenomen van het gebruik van ISRS Location Codes voor elk van de algemene overeenkomsten (er gelden geen uitzonderingen op de algemene overeenkomsten voor waterwegtrajecten in Slowakije):

Ongeldige zoekopdrachten voor ISRS Location Codes

Algemene opmerking: de NtS Web Service ondersteunt geen zoekopdrachten naar geldige ISRS Location Codes. De ISRS Location Codes worden bepaald binnen het European Reference Data Management System (ERDMS).

De volgende vijf gevallen illustreren het correcte gebruik van ISRS Location Codes in zoekopdrachten en de interpretatie daarvan.

Geval 1: geen IDS-element in de zoekopdracht

Het IDS-element is een facultatief deel van de zoekopdracht, d.w.z. een zoekopdracht zonder IDS-elementen is toegestaan:

Geldige zoekopdracht zonder IDS-parameter

Als geen IDS-element wordt opgegeven, worden alle berichten teruggezonden (uiteraard afhankelijk van andere filtercriteria zoals validity_period of dates_issue).

Geval 2: één ID-element in de zoekopdracht

Elk IDS-element kan één of twee ID-elementen bevatten. De volgende figuur bevat een geval met één ID-element:

Geldige zoekopdracht met één ID-parameter

Als een dergelijke zoekopdracht wordt ontvangen, zal de server alle overeenkomstige berichten terugzenden met een beginhectometer ≤ de opgegeven waarde (240,7 in het voorbeeld) en een eindhectometer ≥ die waarde. De onderstaande figuur stelt die selectie van berichten voor: de gevraagde positie ligt tussen de begin- en eindhectometerwaarden van de berichten 1, 3 en 4, die worden teruggezonden. De berichten 2, 5 en 6 overlappen de positie in de zoekopdracht niet en worden dus niet teruggestuurd.

Als de opgegeven ISRS Location Code naar een enkelvoudig object verwijst, bv. een peilschaal of sluis, moet de web service de berichten terugzenden die op dat object betrekking hebben.

Matchende en niet matchende berichten voor één ID-parameter

Geval 3: twee ID-elementen in de zoekopdracht

Elk IDS-element kan één of twee ID-elementen bevatten. De volgende figuur toont een geval met twee ID-elementen:

Geldige zoekopdracht met twee ID-parameters

Alle opgevraagde hectometerwaarden worden als geldig beschouwd, zelfs als de overeenkomstige vaarwegsectie verschillende begin- en eindpunten heeft. Een voorbeeld: als de vaarwegsectie begint bij hectometer 100,0 en eindigt bij hectometer 300,0 , is een zoekopdracht naar hectometer 20,0 tot en met 400,0 een geldige zoekopdracht. Intern wordt uiteraard alleen de „werkelijke” lengte van de vaarwegsectie onderzocht.

Daardoor kunnen ook alle berichten over een vaarweg worden opgezocht zonder het exacte hectometerbereik te kennen (iemand kan de ISRS Location Code van de vaarweg doorsturen waarbij de hectometers respectievelijk zijn ingesteld op „00000” of „99999”).

Alle berichten die overeenkomen met de opgegeven hectometerafstand, zullen worden teruggezonden. Die situatie wordt geïllustreerd in het volgende diagram:

Matchende en niet matchende berichten voor twee ID-parameters

In de bovenstaande figuur wordt getoond hoe „overlappen” wordt bepaald. Omdat het bereik van de berichten 1 tot en