B. NTS ENCODING GUIDE VOOR APPLICATIEONTWIKKELAARS

INHOUD

1. Achtergrond en structuur 24

1.1. Doel van de NtS Encoding Guide 24

1.1.1. NtS Encoding Guide voor redacteuren 24

1.1.2. NtS Encoding Guide voor applicatieontwikkelaars (dit document) 24

2. NtS-berichten en -secties 24

3. Basisoverwegingen voor een WRM 26

3.1. Invullen van de sectie NtS_number in een WRM 26

3.2. Invullen van verwachtingen in een WRM 26

4. ICEM-processen 27

4.1. Nieuw ICEM 28

4.2. Bijwerking van een bestaand ICEM 28

5. Basisoverwegingen voor een WERM 29

5.1. Invullen van de sectie NtS_number in een WERM 29

5.2. Invullen van de „weather_category_code” in een WERM 29

6. FTM-processen 30

6.1. Nieuw FTM 30

6.2. Bijwerking/intrekking van een bestaand FTM 30

6.3. FTM met betrekking tot waterwegen en/of objecten 31

6.4. Automatische ordening van limitation codes 31

6.5. Bewerking van de duur van een beperking 32

7. Algemene toepassingsregels 33

7.1. Invullen van de „number_section” 33

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

7.3. Weglaten van elementen 34

7.4. Automatisch invullen van date_issue 34

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

7.6. Bewerking van seconden in NtS-berichten 34

7.7. Formaat van decimalen in NtS-berichten 34

7.8. Te gebruiken eenheden in NtS-berichten 34

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

7.10. Regels voor het element „fairway_name” 38

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

7.12. Aanbeveling voor het element „coordinate” 38

7.13. Omgang met doelgroepen 38

7.14. Weergave van op een bepaald tijdstip geldige berichten 39

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

8. NtS XML-berichtstructuur 39

9. NtS Web Service 39

9.1. Doelstelling 39

9.2. Grondbeginselen en beperkingen 40

9.2.1. Webnormen 40

9.2.2. Interactiemodel en codeermethode voor NtS WS 40

9.3. Algemene specificaties en aanbevelingen 40

9.3.1. Specificatie: versiegegevens 40

9.3.2. Specificatie: structuur van namespaces 41

9.3.3. Aanbeveling: gebruik van namespaces 41

9.3.4. Aanbeveling: gebruik van namespace-voorvoegsels 41

9.3.5. Specificatie: gebruik van ISRS Location Codes 41

9.4. NtS-berichtendienst (implementatiespecificatie) 46

9.4.1. Verzoek 46

9.4.2. Antwoord 47

9.5. Gegenereerde diensten en klanten 48

Woordenlijst 48

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” (1). 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 met 4 (geheel of gedeeltelijk) overlapt met het bereik van het opgevraagde hectometerbereik en het bereik van de boodschappen 5 en 6 niet, zullen de berichten 1 tot en met 4 worden teruggezonden, 5 en 6 zullen niet worden teruggezonden.

De technische voorwaarde om een bericht te laten overlappen met een interval [A, B] is: de beginhectometer van het bericht is ≤ B en de eindhectometer is ≥ A.

Combinatie: meerdere IDS-elementen in de zoekopdracht

Geldige zoekopdracht met meerdere IDS-elementen

De combinatie van een aantal IDS-elementen in de zoekopdracht leidt tot een koppeling van de overeenkomstige berichten Alle IDS-elementen worden afzonderlijk behandeld en er zal een bericht worden teruggezonden als dat met minstens één van die elementen overeenkomt. In het geval van onderstaand voorbeeld zullen daarom de volgende berichten worden teruggezonden:

— Alle berichten voor het object met ISRS Location Code SKXXX0000010000***** met beginhectometer = 0 en eindhectometer ≥ 0 (zie geval 2)

— Alle berichten voor het object met ISRS Location Code SKXXX0000500000***** die overlappen met hectometerinterval [11,0, 15,0] (zie geval 3)

— Alle berichten voor het object met ISRS Location Code SKXXX0000200000***** met beginhectometer ≤ 110,5 en eindhectometer ≥ 110,5 (zie geval 2)

— Alle berichten voor het object met ISRS Location Code SKXXX0000500000***** die overlappen met hectometerinterval [220,0, 300,0] (zie geval 3)

9.4. NtS-berichtendienst (implementatiespecificatie)

In dit hoofdstuk wordt de implementatiespecificatie van de NtS-berichtendienst opgegeven, afgeleid van de overwegingen en keuzes in de vorige hoofdstukken.

De NtS-berichtendienst levert de vier berichttypes van NtS:

1. NtS FTM (berichten met betrekking tot vaarwegen en verkeer)

2. NtS WRM (berichten met betrekking tot de waterstand)

3. NtS ICEM (ijsbericht)

4. NtS WERM (berichten met betrekking tot het weer)

Een implementatie van de NtS-berichtenservice kan alle berichttypes ondersteunen of alleen een selectie. Een deelnemende lidstaat kan in meer dan één dienst voor een specifiek berichttype voorzien, die elkaar aanvullen.

9.4.1. Verzoek

Om de dienst zo robuust mogelijk te maken en tegelijk de complexiteit te beperken, wordt in de NtS Web Service geen extra taal voor zoekopdrachten gebruikt, maar worden de concepten van WSDL zelf toegepast. De specifieke handelingen zijn samen met de parameters ervan volledig gespecificeerd binnen de WSDL-specificatie. In het geval van de NtS-berichtendienst is één enkele handeling gedefinieerd.

De onderwerpspecifieke filtercriteria zijn ontleend aan de NtS-norm, maar uitgebreid wat betreft de veelsoortigheid van de parameters:

— berichttype (verplicht; „FTM”, „WRM”, „ICEM”, of „WERM”)

— specifieke waterwegsecties of delen daarvan, of specifieke objecten (niet verplicht; omschreven met enkelvoudige ISRS Locaton Codes en/of paren van ISRS Location Codes)

— geldigheidsduur (niet verplicht; begin- en einddatum)

— publicatiedatum van het bericht (niet verplicht; enkelvoudige datums en/of datumintervallen)

Alleen de berichten die aan de opgegeven criteria voldoen, worden door de dienst teruggezonden.

Paging mechanism

Om de hoeveelheid gegevens onder controle te houden, wordt een paging mechanism ondersteund. De paging-parameter is gedefinieerd aan de hand van een complex type dat de volgende elementen bevat:

— offset: serienummer van het eerste teruggezonden bericht (integer ≥ 0),

— limit: maximaal aantal berichten (integer ≥ 0),

— total count: vlag, als het volledige aantal berichten zal worden teruggezonden (Booleaanse waarde).

De complexe paging-parameter is niet verplicht, maar als hij wordt opgegeven, moet hij alle waarden bevatten. Dan werkt het paging mechanism op de volgende wijze:

het totaal aantal berichten mag de waarde van de parameter limit niet overschrijden, met als uitzondering dat de waarde 0 „no limit” betekent. Het antwoord slaat zoveel berichten over als gedefinieerd in de parameter offset. Om in dit mechanisme te voorzien, moet de dienst een tijdelijk stabiele (maar verder willekeurige) sequentie van de berichten in acht nemen, bv. tussen twee updates van berichtgegevens over de onderliggende datareeks van de webservice. Dat betekent dat twee opeenvolgende identieke oproepen dezelfde berichten in dezelfde volgorde terug moeten zenden. De parameter total count bepaalt of in het antwoord het totaal aantal berichten zal worden verstrekt dat aan de onderwerpspecifieke criteria voldoet. Gewoonlijk volstaat het om die informatie in het eerste antwoord op te vragen, maar het in alle daaropvolgende antwoorden weg te laten. Daardoor moet de web service beter presteren.

Het paging mechanism voorziet in een middel om de berichten op iteratieve wijze in „pagina's” op te vragen. Opdat het paging mechnism naar behoren zou functioneren, moeten in elk verzoek dezelfde onderwerpspecifieke parameters worden opgegeven.

9.4.2. Antwoord

In geval van een succesvol verzoek bevat het antwoord van de NtS Web Service de NtS-berichten die overeenstemmen met de parameters van het verzoek. De NtS-berichten moeten voldoen aan het NtS-schema en kunnen aan de hand van dat schema worden gevalideerd. Aangezien het berichttype een verplichte verzoekparameter is, kan een antwoord alleen NtS-berichten van datzelfde berichttype bevatten, respectievelijk FTM, WRM, ICEM of WERM.

Als de dienst tijdens de verwerking van het verzoek fouten vaststelt, kan hij een willekeurig aantal foutberichten terugzenden aan de hand van de foutcodes in het volgende subhoofdstuk.

Eén antwoord van een NtS Web Service kan tegelijk NtS-berichten en foutmeldingen bevatten.

Facultatieve paging-informatie wordt teruggezonden als het verzoek paging-parameters bevatte. In dat geval zijn „offset” en „number” van de ingesloten berichten verplicht, „total” moet alleen worden gebruikt als daarom is verzocht.

Let op: er wordt verondersteld dat de communicatie tussen de web service en de gebruiker technisch tot stand is gebracht, d.w.z. de web service ontvangt het verzoek en de gebruiker ontvangt het overeenkomstige antwoord. Technische fouten, zoals het uitvallen van de internetverbinding of de ontoegankelijkheid van de web service door onderhoud of een crash, worden hier niet behandeld. Alleen fouten die zich vanuit het standpunt van de gebruikers „achter” de laag van de web service voordoen, worden hier in aanmerking genomen.

Foutmeldingen

Hieronder volgen de codes van mogelijke fouten, samen met een toelichting. In het antwoord wordt alleen de foutcode gegeven, zoals gebruikelijk in het XML-schema van NtS.

Foutcodes van de NtS-berichtendienst

Code Description Explanation e010 message type not supported web service does not support the requested message type e030 paging parameters inconsistent with messages parameters for paging mechanism do not fit the available messages, e.g. Offset >= Total Count e100 syntax error in request request violates the schema for requests; can be specified in more detail by further e1xx-Codes e110 incorrect message type given message type is not known e120 incorrect type-specific parameters type-specific parameters are erroneous e130 incorrect paging parameters given parameters for the paging mechanism are erroneous e200 operation not known the requested operation is unknown e300 data source unavailable data source of the web service for the NtS data is temporarily unavailable (technical problem) e310 too many results for request, server is unable to handle number of results

9.5. Gegenereerde diensten en klanten

Als de „contract first”-benadering consequent wordt toegepast, d.w.z. als één of meer contracten met volledige beschrijving van de interfaces in de vorm van WSDL-documenten worden opgegeven, kunnen met de geschikte software de implementatie van de dienst(en) en een implementatie van een overeenkomstige klant automatisch worden gegenereerd. In het ideale geval hoeft de gegenereerde broncode niet manueel te worden gewijzigd.

In de meeste gevallen zijn echter verschillende herhalingen nodig alvorens de WSDL-specificatie aan de exacte vereisten van een dergelijk instrument voldoet. Om probleemloos te kunnen werken stelt dat instrument doorgaans individuele eisen inzake het gebruik van de WSDL-standaard. Bijgevolg kan het noodzakelijk zijn om de WSDL-specificatie te wijzigen, hoewel die volgens de WSDL-standaard in eerste instantie een geldige specificatie was. Als de WSDL-specificatie van de web service wordt gewijzigd nadat de dienst of de klant zijn gegenereerd, kan het, afhankelijk van de wijzigingen, nodig blijken om een nieuw generatieproces te starten.

Woordenlijst

Term Verklaring ID Identificatie ISRS Location Code „International Ship Reporting Standard” Location Code NtS Berichten aan de scheepvaart RIS River Information Services SOAP Simple Object Access Protocol; netwerkprotocol dat gewoonlijk wordt gebruikt voor web services UDDI Universal Description, Discovery and Integration; standaard voor registratiediensten in het kader van web services UN Verenigde Naties. URL Uniform Resource Locator; locatie van een netwerkbron, gewoonlijk gebruikt voor internetadressen WGS 84 World Geodetic System 1984 WS Web Service; dienst met interfaces op het internet, die wordt gebruikt voor communicatie via het internet WSDL Web Services Description Language; standaard voor de specificatie van web services WS-I Web Services Interoperability Organisation; consortium voor de ondersteuning van de interoperabiliteit van web services XML Extensible Markup Language; metataal voor de gestructureerde en platformonafhankelijke weergave van gegevens XSD XML-schemadefinitie; standaard voor de specificatie van de structuur van XML-documenten

(1) Aangehaald van de WS-I-website: http://www.ws-i.org.