LegalizeCommission Implementing Regulation (EU) 2018/2032 of 20 November 2018 amending Commission Regulation (EC) No 416/2007 concerning the technical specifications for Notices to Skippers
This is the act as published. Later amendments are not folded into the text below: each one is a separate act in this repository and an entry in this law's history.
The visibility in ‘weather_category_code’ (values 13 to 22) shall be provided as defined in the following table:
| Value, meaning | Visibility | Additional information |
|---|---|---|
| 13, thick fog | below 50 metres | |
| 14, dense fog | below 100 metres | |
| 15, moderate fog | below 200 metres | |
| 16, fog | below 1 000 metres | Fog consists of water droplets. |
| 17, mist | from 1 km to 4 km | Mist consists of water droplets. Mist is used in case of ‘dry fog’, this phenomenon usually takes place before sunrise. |
| 18, haze | from 1 km to 4 km | Haze consists of dry particles. |
| 19, light haze | from 4 km to 10 km | |
| 20, clear | from 10 km to 20 km | |
| 21, very clear | no limitation of visibility | |
| 22, no fog | ‘no fog’ is used to state that there is no fog depending on national/local requirements. |
6. FTM processes
In the NtS Encoding Guide for editors it is described under which circumstances an NtS editor creates a new FTM or updates an existing FTM. The following processes apply:
6.1. New FTM
- (1) NtS applications may offer NtS editors to:
- (a) use existing notices as draft upon creation of new FTM; and/or
- (b) use notice templates for certain situations.
- (2) The content (e.g. time of validity, limitations) has to be entered by the editor in line with chapters 3 and 4 of the NtS Encoding Guide for editors.
- (3) When an NtS editor/publisher triggers the publish action:
- (a) it is checked if all mandatory content is provided in line with the NtS XSD (if not go back to (2));
- (b) the nts_number is generated by the NtS application:
- (i) the ‘organisation’ is filled with the name or code of the responsible organisation depending on the role of the publishing user:
- (ii) the ‘year’ is filled with the current year;
- (iii) the next available ‘number’ is assigned, in case a dedicated number was entered by the NtS editor or an application process in step 2 it is taken over (given that (Organisation/Year/Number/Serial) is unique as explained in chapter 15.1;
- (iv) the ‘serial number’ 0 is assigned;
- (c) ‘date _issue’ is automatically filled with the actual date/time of publish action
6.2. Update/withdrawal of an existing FTM
- (1) The respective published message has to be selected to be updated in the FTM editor tool, the original FTM has to be copied or altered in the DB (depending on national processes).
- (a) Expired FTM (which passed the validity_date_end) cannot be updated any more, if this is the case NtS editor has to create a new FTM.
- (b) The subject code ‘Notice withdrawn’ is only used if:
- (i) present date is before the validity_date_start. In case only the content of the field ‘additional information in national language’ may be altered, the coded content of the message (step 2) has to stay unchanged;
- (ii) the validity period already started and the new end date for all limitations is in the past. The end date of the limitation has to be set to the correct time.
- (c) If a notice is withdrawn the validity period date end always has to be set to date of withdrawal.
- (2) The content (e.g. time of validity, limitations) has to be altered by the editor in line with chapters 3 and 4 of the NtS Encoding Guide for editors.
- (3) When an NtS editor/publisher triggers the publish action:
- (a) it is checked if all mandatory content is provided in line with the NtS XSD (if not go back to (2));
- (b) the nts_number is generated by the NtS application:
- (i) the ‘organisation’ stays unchanged;
- (ii) the ‘year’ stays unchanged;
- (iii) the ‘number’ stays unchanged;
- (iv) the ‘serial number’ is incremented (increased by 1);
- (c) ‘date_issue’ is automatically filled with the actual date/time of publish action
- (d) FTM with subject code ‘Notice withdrawn’ shall not be considered for voyage planning (any more).
6.3. Waterway and/or object related FTM
A waterway related FTM contains information about one or several stretches of waterway. A waterway stretch is defined in the ‘fairway_section’ part by its begin and end ISRS Location Codes.
An object related FTM contains information about one or several specific objects on the waterway. An object is defined in the ‘object’ part by its ISRS Location Code.
One FTM has to refer
- — to one or several fairway sections, or
- — to one or several objects on one or several fairway sections.
6.4. Automatic ordering of limitation codes
Different limitations have different impact on navigation. In order to allow display of the most severe limitation e.g. in an FTM list overview, the following order shall be considered starting with the most severe limitation having Rank 1:
| Rank | Value | Meaning (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. Handling of limitation period
- — Limitations with the same limitation periods should be grouped/listed together/combined for display to keep it reader-friendly.
- — NtS editor tools should provide a function for editors to avoid re-typing of limitation periods.
- — All limitations have to include a limitation period with an interval code in order to allow proper calculations within voyage planning applications. To ease the work of NtS editors the following functions may be implemented:
- — The NtS editor tool may provide a function to copy already entered limitations to avoid re-typing of the limitation period by the NtS editor.
- — The NtS editor tools may provide a function to select more than one limitation code for a specific limitation period and automatically create the required limitation sections based on the information entered by the NtS editor.
- — ‘Monday to Friday except public holidays’: The value ‘holidays’ is very difficult for voyage planning applications. A list of holidays for each country is needed for proper calculation. If no such list is available the respective limitations will be assigned to the public holidays nevertheless.
- — ‘with the exception of’: must not be used; Interrupted intervals have to be given as separate limitation periods within the same limitation, therefore this code shall not be displayed/available to notice editors.
- — Logic and display of information applicable in case of interval code ‘continuous’:
2015-04-01+01
2015-06-30+02
06:00:00
10:00:00
CON
If the interval_code is continuous the start_time belongs to the start_date and the end_time belongs to the end_date e.g. from 1 April 06:00 to 30 June 10:00
- — Logic and display of information applicable in case of any other interval code than ‘continuous’:
2015-04-01+01
2015-06-30+02
06:00:00
10:00:00
WRK
If the interval_code has another value the start_time and end_time belongs to this interval_code e.g. from 1 April to 30 June Monday to Friday from 06:00 to 10:00
- — The limitation time end always has to be filled in the last version of a message.
7. General implementation rules
The following is to be considered:
- — The table ‘GUI_labels’ provided in the NtS Reference Tables shall be considered when building NtS applications (search masks, e-mail subscription form, display of messages).
- — The date_end cannot be before date_start.
- — Codes that have been disabled (are not to be used any more) via NtS change requests (see comments in the NtS XSD) shall not be displayed to NtS editors upon creation of new messages. The codes are still included in the NtS XSD enumerations for backwards compatibility.
7.1. Filling of the ‘number_section’
Every number (Organisation/Year/Number/Serial) has to be unique per message type. That means that messages of different types can have the same NtS Number.
For users the message numbers are only relevant for FTM and ICEM, for all other message types display of the message number can be skipped depending on national requirements.
To users the message number shall be displayed in the following format ‘Message Type/Country/Organisation/Year/Number/Serial’ (it can be shortened depending on applied filters if no information gets lost).
7.2. Filling of elements ‘from’, ‘originator’, ‘organisation’ and ‘source’
The element ‘from’ in the identification section is filled with the name of the national system that provides the message (e.g. ELWIS, DoRIS, SLOVRIS, FLARIS).
The element ‘originator’ is the organisation which enters the messages into the national systems.
The element ‘source’ is the authority for which the FTM are published.
The element ‘organisation’ within the nts_number section is the name of the organisation assigning the nts_number (NtS Provider).
7.3. Omission of elements
Elements that would contain only standard or default values shall be omitted if they are conditional, they lead to message overhead with no added value.
Following elements are concerned:
- — Target Group: target_group_code ALL with direction_code ALL (if there are no other specific target groups within the message),
- — position_code: AL,
- — reason_code: OTHER.
7.4. Automatic filling of date_issue
FTM and ICEM
For FTM and ICEM the value of date_issue element is the actual date and time of publishing. In case of updated messages date_issue is the date and time when the update was published.
WRM and WERM
For WRM and WERM the value of date_issue element is the date and time of the processing request, because there can be several measurements with different issuing time stamps within one W(E)RM message.
7.5. Handling of time zone information in NtS messages
Date and time shall always be provided in local time including time zone information within the NtS XML messages.
The only exceptions from this provision are the ‘time_start’ and the ‘time_end’ within the ‘limitation_period’ section. This is because in the limitation section an interval can be applied. If date start and date end have different time regimes (e.g. CEST and CET) this would result in a change of the time zone information within this interval. This change cannot be expressed via a single limitation period. Instead of creating different limitation periods for each time change only a single limitation period without time zone information is used to reduce overhead in message processing and transmission.
7.6. Handling of Seconds in NtS messages
As a general rule seconds have to be provided in (date)/time fields but shall not be displayed to NtS users. Minutes are sufficient for NtS granularity.
7.7. Format of decimals in NtS messages
Decimals in numeric fields are indicated with a . (period). No thousand separators are used.
The number of decimals used for values shall be limited to a feasible amount to ensure user-friendly display.
7.8. Units to be used in NtS messages
Only cm, m3/s, h, km/h and kW, m/s (wind), mm/h (rain) and degree Celsius are allowed to be used as units within NtS messages, applications may convert the units for user friendliness.
In case the input units differ from the standardised units the entered values have to be converted by the application accordingly.
7.9. Rules for the elements ‘name’, ‘position_code’ and ‘type_code’
The element ‘name’ shall be prefilled automatically from the RIS Index reference data ‘national object name’ (NtS editors might amend the prefilled name if this is a national requirement). Naming conventions for object names are included in the RIS Index Encoding Guide version 2.0 or higher. Examples for proper object names are also given in the NtS Encoding Guide for editors.
The type code is added to the object by the NtS application in front of the object name.
The position of objects is encoded via position code and added to the object by the NtS application out of the RIS Index. Editors may change prefilled type and position codes. An object position code shall not be provided for geo_objects in the fairway_section.
A full object name is composed of its position code, type code and name.
To ease the work of NtS editors the following mapping may be implemented in NtS editor tools supporting editors in finding / selecting the proper objects based on the RIS Index function_code or the NtS type_code:
Table 1
Matching ‘RIS Index function_code’ — ‘NtS type_code’
| Function Code | Function Code Meaning | Type Code | Type Code Meaning |
|---|---|---|---|
| — | — | ||
| BUAARE | E.1.1 Built-Up Areas | to be selected by editor | |
| BUISGL | E.1.2 Building of Navigational Significance | to be selected by editor | |
| brgare | G.1.1 - G.1.6 Bridge Area [C_AGGR()] | BRI | bridge |
| bridge_5 | G.1.1 Bascule Bridge | BRO | bridge opening |
| bridge_1 | G.1.2 Bridges with Bridge Arches | BRO | bridge opening |
| bridge_1 | G.1.3 Fixed Bridge | BRO | bridge opening |
| bridge_4 | G.1.4 Lift Bridge | BRO | bridge opening |
| bridge_12 | G.1.5 Suspension Bridge | BRO | bridge opening |
| bridge_3 | G.1.6 Swing Bridge | BRO | bridge opening |
| cblohd | G.1.8 Overhead Cable | CAB | cable overhead |
| pipohd | G.1.9 Overhead Pipe | PPO | pipeline overhead |
| bridge_7 | G.1.12 Drawbridge | BRO | bridge opening |
| bunsta | G.3.2 Bunker / Fuelling Station | BUS | Bunker / Fuelling Station |
| cranes | G.3.4 Crane | to be selected by editor | |
| hrbare | G.3.9 Harbour Area | HAR | harbour |
| hrbbsn | G.3.10 Harbour Basin | HAR | harbour |
| ponton | G.3.11 Landing Stage, Pontoon | to be selected by editor | |
| morfac | G.3.12 Mooring Facility | MOO | mooring facility |
| hulkes | G.3.14 Permanently Moored Vessel or Facility | to be selected by editor | |
| prtare | G.3.15 Port Area | HAR | harbour |
| refdmp | G.3.17 Refuse Dump | REF | refuse dump |
| termnl | G.3.19 Terminal | TER | terminal |
| trm01 | G.3.19 RORO-terminal | TER | terminal |
| trm03 | G.3.19 Ferry-terminal | TER | terminal |
| trm07 | G.3.19 Tanker-Terminal | TER | terminal |
| trm08 | G.3.19 Passenger Terminal | TER | terminal |
| trm10 | G.3.19 Container Terminal | TER | terminal |
| trm11 | G.3.19 Bulk Terminal | TER | terminal |
| vehtrf | G.3.20 Vehicle Transfer Location | BER | berth |
| lokbsn | G.4.3 Lock Basin | LKB | lock basin |
| lkbspt | G.4.4 Lock Basin Part | LKB | lock basin |
| lokare | G.4.3 / G.4.4 Lock Area [C_AGGR()] | LCK | lock |
| excnst | G.4.8 Exceptional Navigational Structure | SLI | ship lift |
| TUN | tunnel | ||
| CBR | canal bridge | ||
| gatcon | G.4.9 Opening Barrage | BAR | weir |
| FLO | flood gate | ||
| wtwgag | I.3.4 Waterway Gauge | GAU | tide gauge |
| FERYRT_2 | L.2.1 Cable Ferry | FER | ferry |
| FERYRT_1 | L.2.2. Free Moving Ferry | FER | ferry |
| feryrt_4 | L.2.3. Swinging Wire Ferry | FER | ferry |
| dismar | L.3.2 Distance Mark along Waterway Axis | RIV | river |
| achare | M.1.1 Anchorage Area | ANC | anchoring area |
| achbrt | M.1.2 Anchorage Berth | BER | berth |
| berths_3 | M.1.3 Berth / Fleeting Areas | BER | berth |
| berths_1 | M.1.4 Transhipment Berth | BER | berth |
| trnbsn | M.4.5 Turning Basin | TUR | turning basin |
| CAN | canal | ||
| FWY | fairway | ||
| rdocal | Q.2.1 Radio Calling-In Point (notification point) | REP | reporting point |
| chkpnt | R.1.1 Check Point | BCO | border control |
| sistat_8 | R.2.1 Traffic Sistat — Bridge Passage | SIG | signal station |
| sistat_6 | R.2.2 Traffic Sistat — Lock | SIG | signal station |
| sistat_10 | R.2.3 Traffic Sistat — Oncoming Traffic Indicator | SIG | signal station |
| sistat_2 | R.2.4 Traffic Sitat — Port Entry and Departure | SIG | signal station |
| pas | Passage Points | to be selected by editor | |
| riscen | RIS centre | VTC | vessel traffic centre |
| specon | Special Construction | to be selected by editor | |
| trafp | Traffic Points (first reporting points) | REP | reporting point |
| junction | Waterway node / end of waterway / Junction | to be selected by editor | |
| waypt | Waypoint | to be selected by editor | |
| Legend: | Legend: | Legend: | Legend: |
| green | Direct match (1:1 relation) | Direct match (1:1 relation) | Direct match (1:1 relation) |
| yellow | matching example, other TypeCodes possible (1:n relation) | matching example, other TypeCodes possible (1:n relation) | matching example, other TypeCodes possible (1:n relation) |
| blue | no direct match / to be selected by editor | no direct match / to be selected by editor | no direct match / to be selected by editor |
7.10. Rules for the element ‘fairway_name’
To avoid application logic / necessity of proper reference data at the receiving system (software displaying the notice to the user) the optional element ‘fairway_name’ shall always be included in the ‘geo_object’ and automatically filled by the NtS application with the ‘Waterway name’ from the RIS Index. NtS editors shall not alter the content of the element fairway_name.
7.11. Clarifications for translations in the spreadsheet ‘reference_code’
The following definition shall be used for reference_code values provided in the NtS Reference Tables:
- — NAP: In the Netherlands the abbreviation NAP is used and understood, NAP is not translated
- — KP: ‘channel level’ shall be translated thus provided in national language
- — FZP: only the abbreviation ‘FZP’ shall be used (nowadays hardly used anymore)
- — ADR: ‘Adriatic Sea’ shall be translated thus provided in national language
- — TAW/DNG: ‘Tweede algemene waterpassing’ (Dutch) — ‘Deuzième Nivellement Général’ (French) is the reference height used in Belgium to express height measurements. 0 is the average sea water level at low water in Oostende
- — Dutch: TAW
- — French: DNG
- — All other Languages: TAW/DNG
- — LDC: ‘low navigable water level Danube Commission’ shall be translated thus provided in national language
- — HDC: ‘high navigable water level Danube Commission’ shall be translated thus provided in national language
- — ETRS: ‘European Terrestrial Reference System 1989’ the abbreviation ‘ETRS89’ is used in all languages.
7.12. Recommendation for the element ‘coordinate’
Although the element coordinate within the geo object section is conditional, the geo coordinates shall be given in WGS84 in format [d]d mm.mmm[m] N (latitude) and [d][d]d mm.mmm[m] E (longitude). This is to refer the NtS messages geographically.
7.13. Handling of target groups
The target group section consists of target group code and direction code. If both have the value ALL the whole section shall be omitted if there are no other specific target groups within the message. If just one of these two is given the other must be filled with the default value ALL because both elements are mandatory.
Further information concerning target groups can be found in the NtS Encoding Guide for editors.
7.14. Display of valid messages at a given time
The validity_period shall be used by applications to select the messages, which are to be displayed to users for a requested time.
If subject_code is INFSER (Info service) the validity period is used to specify the time the Info service Message is displayed to the users, not for the period of validity of the provided information (e.g. 1 month).
7.15. Optional functions to increase user friendliness of NtS editor tools
The following functions may be offered to NtS editors depending on national requirements:
- — NtS applications may offer NtS editors to save draft NtS messages (not all mandatory content has to be provided in order to save draft messages)
- — Different user roles may apply to different editors (e.g. editors that are allowed to enter/alter notices, publishers that are allowed to publish notices (in addition to editing)
8. NtS XML Message Structure
The NtS XML Message Structure and the content and purpose of data elements are defined and further explained in Appendix C: NtS XML Schema Definition (XSD).
9. NtS Web Service
9.1. Objective
The NtS Expert Group identified the web service technology as an appropriate means to provide the Notices to Skippers.
This chapter constitutes the specification of the web service for the provision of the Notices to Skippers, short NtS Web Service. Particular emphasis was placed on the use of well-established international standards.
One goal of the conceptual design was to ensure a good balance between flexibility and robustness of the resulting web service. The filter parameters provided in the requests are essentially the criteria specified in the NtS standard (waterway section with optional river km, time of validity, date of publication of the notice). This seems sufficiently expressive considering the use cases of the web service and at the same time limits the complexity of the implementation.
The core result is a contract for the web service, in which the requests and responses are specified. The consumers of the web service can rely on this contract and the providers have to comply with it. This contract is specified using the international standard WSDL.
Every participating Member State shall implement one or more web services for the different message types of the NtS (FTM, WRM, ICEM, WERM) and provide them via the internet (‘NtS Message Service’),
The technical details of the implementation of the NtS WS, e.g. choice of appropriate data pools, applications and platforms, are not in the scope of this specification and are in the responsibility of each individual participating Member State.
In order to define a secure communication one has to consider various security aspects and protection objectives. Depending on the circumstances not all of these aspects have to be considered. The priority of the various security aspects and the degree of their fulfilment can vary. Also the feasibility of a certain measure can be limited by the capabilities of the technical implementation. In the context of NtS all information are public. So there is no need to secure the NtS data themselves in terms of data protection. Therefore every provider has to decide on its own in how far this aspect will be implemented in its service.
9.2. Basic Principles and constraints
9.2.1. Web standards
The NtS Web Service has to comply with the WS-I Basic Profile 1.1. This profile ‘provides interoperability guidance for a core set of non-proprietary web services specifications, such as SOAP, WSDL and UDDI’ 6. The most relevant standards herein are
- — XML Schema Definition (XSD),
- — Simple Object Access Protocol (SOAP),
- — Web Services Description Language (WSDL), and
- — Universal Description, Discovery and Integration (UDDI).
The response message of the NtS WS is an NtS message which is defined in XML Schema Definition (XSD) in Appendix C of this Commission Regulation.
| SOAP | is an application protocol for data transmission among IT-Systems and is standardised by the World Wide Web Consortiums (W3C). The specific elements for the NtS Web Service are defined inline in the corresponding WSDL specifications in Appendix D of this Commission Regulation. The schema of the NtS standard (XSD) is included with an import statement. |
| UDDI | (Universal Description, Discovery and Integration) is noted here as a central, possibly international registry for web services, where the NtS Web Service could be registered. In this registry potential consumers of the web service could search and find the service. But since the potential providers of the NtS Web Service are limited by the participating Member States and the WSDL specification is an integral part of the standard, the need for an independent registration of the NtS Web Service is not apparent. |
9.2.2. Interaction model and encoding method for NtS WS
The encoding method Document-literal wrapped is used for the NtS Web Service, because it allows for validation against an XML schema and the operation names defined in the WSDL specification are used directly as XML tag names in the SOAP messages.
9.3. General specifications and recommendations
9.3.1. Specification: Version information
The version information of the NtS Web Service consists of two sections:
- — version of the web service itself,
- — version of the NtS schema used by the web service.
The section of the web service itself consists of two parts:
- — major version of the web service,
- — minor version of the web service.
The major version is given as a positive integer denoting the major version of the web service.
The minor version is given as a non-negative integer denoting the minor version of the web service within the major version.
The section of the NtS schema contains the version of the NtS schema as defined by the NtS Expert Group.
Hence, the version of the NtS Web Service specified here is 2.0.4.0, where 2.0 is the version of the web service itself and 4.0 is the version of the NtS schema used.
Explicit version information is not necessary in the requests or responses of the NtS Web Service. There are only a few versions of the services expected to be online at the same time. Different versions shall be provided with different URLs. Hence, each instance of an NtS Web Service implementation shall support one specific version of the NtS Web Service.
9.3.2. Specification: Structure of namespaces
The namespaces in the NtS Web Service are based on the web domain of the RIS Expert Groups, http://www.ris.eu/
The namespaces contain a particle indicating the corresponding service and version information. Hence, the service specified here uses the following namespace:
NtS Message Service: http://www.ris.eu/nts.ms/2.0.4.0
9.3.3. Recommendation: Use of namespaces
For higher transparency of XML documents it is recommended to define namespaces in the outmost suitable element in the schemas as well as the instance documents and not to use local namespace definitions in nested elements.
9.3.4. Recommendation: Use of namespace prefixes
Requests and responses in the NtS Web Service shall use XML elements in qualified form, i.e. with an explicit namespace prefix, and XML attributes in unqualified form, i.e. without a namespace prefix.
It is recommended to use intuitive namespace prefixes like ‘nts’ for better human readability.
9.3.5. Specification: Use of ISRS Location Codes
The ISRS Location Code is explained in chapter 2 of the NtS Encoding Guide for application developers as well as the RIS Index Encoding Guide.
Querying an NtS Web Service, the client can reference various objects, e.g. fairway sections, gauges or locks. If the corresponding parameters, the id elements, are used, they must contain ISRS Location Codes. These parameters are typically given in id elements, each containing one or two ids.
When using these parameters, the following general conventions have to be observed:
- — ISRS Location Codes have to be submitted as full-length 20-character codes, i.e. without truncating trailing zeros,
- — If two ids are used within an id element, both ISRS Location Codes have to refer to the same waterway. This means, that the codes include some identical digits located in the fairway_section part of the ISRS Location Code. The fairway section code together with the fairway hectometre defines a waterway stretch provided as pair of id elements.
For the provision of waterway stretches (id element pairs within the fairway_section geo_object) in NtS messages, the following has to be considered with respect to the ISRS Location Codes:
- — digits 1 to 2 (Country code):
- — have to be identical within the id pair, but
- — different country codes may be defined within one id pair in case neighbouring countries are using the same fairway section code for a specific waterway and the same system for defining the hectometres,
- — digits 3 to 5 (UN Location code):
- — are not relevant, may contain different content within the id pair,
- — digits 6 to 10 (Fairway section code):
- — have to be identical within the id pair, but
- — [exception]: in case of using the Belgian ISRS codes within NtS WS, one should use only digits 6 to 8 to identify the fairway section, because NtS messages will be published across different sections within one fairway,
- — digits 11 to 15 (Object Reference Code).
- — are not relevant, may contain different content within the id pair,
- — digits 16 to 20 (Fairway Hectometre):
- — consist of five numerical digits defining the hectometre thus will usually contain different content within the id pair. Example: ‘00235’ for fairway km 23,5; ‘00001’ for fairway km 0,1,
- — [exception]: in case of the Netherlands there is not always a direct connection between the Fairway hectometre and the physical kilometre of the fairway due to the definition of the start of the fairway stretch in the network model and in the real world, in such cases the Object Reference Code for objects of the type ‘dismar’ starts with Kxxxx (xxxx includes the physical kilometre, e.g. NLSVG00130K000300191 (km 3)). But for other types of objects there is no direct relation to the physical fairway km in the ISRS codes, e.g. the bridge of Sas van Gent on the same fairway at km 2,5 has the ISRS code NLSVG001300521600186. For the Kanaal Gent-Terneuzen the physical km 0,0 starts at the border of Belgium and the Netherlands and the Fairway Hectometre 0,0 starts at the beginning of the canal in Gent.
In case a message touches more than one waterway or fairway sections all fairway sections have to be defined by their begin- and end-point in separate ‘fairway_section’ XML elements.
For some countries/regions it is required to build filter functionality. For example if ISRS Location Code (1-2) is BE use ISRS Location Code (6-8) as the ID for linear referencing with the fairway hectometre (ISRS Location Code 16-20). Examples for fairway stretches (valid id element pairs within the fairway_section) that include above defined exceptions:
- — The two NL ISRS Location Codes are a valid definition of a waterway stretch (showing NL exception with respect to the kilometre of the fairway): NLSVG00130K000300191 (km 3,0 at Sas van Gent on the Kanaal Gent-Terneuzen) — NLWDP00130K000400200 (km 4,0 at Westdorpe on the Kanaal Gent-Terneuzen),
- — The two BE ISRS Location Codes are a valid definition of a waterway stretch (showing BE exception with respect to the fairway section code (‘020’ Albertkanaal)): BEGNK02016L010100414 (lock of Genk located at km 41,4 on the Albert Canal) — BEOSH02033L010500772 (lock of Ham located at km 77,2 on the Albert Canal).
The following figure shows counter-examples of ISRS Location Code usage for each of the general conventions (no exceptions to the general conventions apply to SK waterway stretches):
Image omitted; see official source
Invalid ISRS Location Code queries
General remark: A service to query valid ISRS Location Codes is not supported by the NtS Web Service. The ISRS Location Codes are provided within the European Reference Data Management System (ERDMS).
The correct usage of ISRS Location Codes in queries and their interpretation is given in the following five cases.
Case 1: No ids element in request
The ids element is an optional part of the request, i.e. a query without any ids elements is allowed:
Image omitted; see official source
Valid query without ids parameter
If no ids element is given, all messages shall be returned (depending, of course, on other filter criteria like validity_period or dates_issue).
Case 2: One id element in request
Each ids element can contain one or two id elements. The case of one id element is shown in the following figure:
Image omitted; see official source
Valid query with one id parameter
If such a query is received, the server shall return all matching messages with a start hectometre ≤ the given value (240,7 in the example) and an end hectometre ≥ this value. The figure below depicts this selection of messages: The position queried lies between the start and end hectometre values of messages 1, 3 and 4, which would be returned. Messages 2, 5 and 6 do not overlap with the query position, so they would not be returned.
If the given ISRS Location Code denotes a singular object, e.g. a gauge or a lock, the web service should return the messages involving this object.
Image omitted; see official source
Matching and not matching messages for one id parameter
Case 3: Two id elements in request
Each ids element can contain one or two id elements. The case of two id elements is shown in the following figure:
Image omitted; see official source
Valid query with two id parameters
All hectometre values queried shall be treated as valid, even if the corresponding fairway section has different start or end points. For instance, if the fairway section starts at hectometre 100,0 and ends at hectometre 300,0, a request querying hectometres 20,0 up to 400,0 would be valid. Internally, of course, only the ‘real’ extent of the fairway section is searched.
Doing so also enables the search for all messages on a fairway without knowing its exact hectometre range (one would send its ISRS Location Code with hectometres set to ‘00000’ or ‘99999’ respectively).
All matching messages intersecting the given hectometre interval shall be returned. The following diagram illustrates this situation:
Image omitted; see official source
Matching and not matching messages for two id parameters
The figure above shows, how ‘intersecting’ is defined. While the extents of the messages 1 to 4 overlap with the extent of the queried hectometre range (partially or completely), the extents of messages 5 and 6 do not, therefore messages 1 to 4 will be returned, 5 and 6 will not be returned.
The technical condition for a message to intersect with an interval [A, B] is: The start hectometre of the message is ≤ B and its end hectometre is ≥ A.
Combination: Multiple ids elements in request
Image omitted; see official source
Valid query with multiple ids elements
The combination of several ids elements in the request leads to a union of the corresponding messages. All the ids elements are treated individually and a message will be returned, if it matches at least one of them. Therefore, the following messages would be returned for the given example:
- — All messages for the object with the ISRS Location Code SKXXX0000010000* with start hectometre =0 and end hectometre ≥ 0 (see Case 2)
- — All messages for the object with the ISRS Location Code SKXXX0000500000* which intersect the hectometre interval [11,0, 15,0] (see Case 3)
- — All messages for the object with the ISRS Location Code SKXXX0000200000* with start hectometre ≤ 110,5 and end hectometre ≥ 110,5 (see Case 2)
- — All messages for the object with the ISRS Location Code SKXXX0000500000* which intersect the hectometre interval [220,0, 300,0] (see Case 3)
9.4. NtS Message Service (implementation specification)
In this chapter the implementation specification of the NtS message service is given, deduced from the considerations and choices in the preceding chapters.
The NtS message service provides the four types of messages in the NtS:
-
- NtS FTM (fairway and traffic related message)
-
- NtS WRM (water related message)
-
- NtS ICEM (ice message)
-
- NtS WERM (weather related message)
An implementation of the NtS message service can support all message types or just a selection. It is allowed that a participating Member State provides more than one service for a specific message type, that complement each other.
9.4.1. Request
In order to achieve a maximum robustness of the service while keeping the complexity on a low level no additional query language is used for the NtS Web Service. Instead the constructs provided by WSDL itself are applied. The specific operations together with their parameters are specified entirely within the WSDL specification. In the case of the NtS Message Service a single operation is defined.
The subject-specific filter criteria are taken from the NtS standard, but extended concerning multiplicity of the parameters:
- — type of message (compulsory; one of ‘FTM’, ‘WRM’, ‘ICEM’, ‘WERM’),
- — specific waterway sections or parts thereof, or specific objects (optional; described by single ISRS Location Codes and/or pairs of ISRS Location Codes),
- — time of validity (optional; start date and end date),
- — date of publication of the notice (optional; single dates and/or intervals of dates).
Only the messages matching the given criteria are returned by the service.
Paging mechanism
In order to control the amount of data a paging mechanism is supported. The paging parameter is defined with a complex type containing the following elements:
- — offset: serial number of the first returned message (integer ≥ 0),
- — limit: max. number of messages (integer ≥ 0),
- — total count: flag, if total number of messages shall be returned (Boolean value).
The complex paging parameter is optional, but if it is present, all elements within have to be given. Then, the paging mechanism works in the following way:
The total number of messages will not exceed the value of the parameter limit, with the exception that a value of 0 means ‘no limit’. The response skips as many messages as defined in the parameter offset. In order to provide this mechanism, the service has to observe a temporarily stable (but otherwise arbitrary) sequence of the messages, e.g. between two updates of message data on the underlying data set of the web service. This means that two consecutive identical calls must return the same messages in the same order. The parameter total count determines whether the response shall provide the total number of messages matching the subject-specific criteria. Usually it should be sufficient to request this information with the first response, but omit it in all consecutive responses. This should result in a better performance of the web service.
The paging mechanism provides a means to request the messages iteratively in ‘pages’. In order for the paging mechanism to work properly, the same subject-specific parameters have to be provided in each call.
9.4.2. Response
In case of a successful request the NtS Web Service response contains the NtS messages that match the request parameters. The NtS messages have to comply with the NtS schema and can be validated against that schema. Since the message type is a compulsory request parameter, each response can contain only NtS messages of the same message type, FTM, WRM, ICEM or WERM respectively.
If the service detects errors while processing the request it can return an arbitrary number of error messages, using the error codes listed in the following subchapter.
One response of an NtS Web Service can contain NtS messages and error messages at the same time.
Optional paging information is returned if the request contained paging parameters. In this case the offset and number of contained messages are mandatory, the total count needs only be present if it has been requested.
Please note: It is assumed that the communication between the web service and the user is technically established, i.e. the service receives the request and the user receives the corresponding response. Technical errors, e.g. breakdown of the internet connection or inaccessibility of the web service due to maintenance or crash, are not considered here. Only error situations that happen ‘behind’ the web service layer from the users point of view are considered here.
Error messages
The error codes for the expected error situations are given below, together with an explanation. Only the error code is contained in the response, which is the usual procedure in the XML schema of the NtS.
Error codes for the NtS message service
| 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. Generation of services and clients
If the contract-first approach is consequently observed, i.e. one or more contracts with complete descriptions of the interfaces are given in the form of WSDL documents, an implementation of the service(s) as well as an implementation of a corresponding client can be automatically generated using appropriate software tools. In an ideal situation no manual changes have to be made in the generated source code.
However, in most cases several iterations are necessary until the WSDL specification meets the precise requirements of such a tool. Typically the tool makes individual demands on the use of the WSDL standard in order to work smoothly. As a consequence changes to the WSDL specification may be necessary, although the WSDL specification was a valid specification according to the WSDL standard in the first place. If the WSDL specification of the web service is changed after the service or the client have been generated, a new generation process may be necessary, depending on the changes made.
Glossary
| Term | Explanation |
|---|---|
| ID | Identification |
| ISRS Location Code | ‘International Ship Reporting Standard’ Location Code |
| NtS | Notices to Skippers |
| RIS | River Information Services |
| SOAP | Simple Object Access Protocol; network protocol typically used for web services |
| UDDI | Universal Description, Discovery and Integration; Standard for registry services in the context of web services |
| UN | United Nations |
| URL | Uniform Resource Locator; location of a network resource typically used for internet addresses |
| WGS 84 | World Geodetic System 1984 |
| WS | Web Service; service that provides its interfaces in the internet and is used by internet communication |
| WSDL | Web Services Description Language; standard for the specification of web services |
| WS-I | Web Services Interoperability Organisation; industry consortium with the objective to support interoperability of web services |
| XML | Extensible Markup Language; meta language for the structured and platform independent representation of data |
| XSD | XML Schema Definition; standard to specify the structure of XML documents |
Description cited from the WS-I Website: http://www.ws-i.org
Appendix C
| No | Tag (Group headers and closers are boldly printed) | Description | Occ. | Rule |
|---|---|---|---|---|
| xmlns:nts="http://www.ris.eu/nts/4.0.4.0" | ||||
| Notice to Skippers | ||||
| 1s | Identification section | M | 1 | |
| 1.1 | xs:string (64) | Internal ID | C | |
| 1.2 | xs:string (64) | Sender (System) of the message | M | |
| 1.3 | xs:string (64) | Originator (initiator) of the information in this message | M | |
| 1.4 | nts:country_code_enum | Country where message is valid | M | |
| 1.5 | nts:language_code_enum | Original language used in the textual info. (contents) | M | |
| 1.6 | xs:string (64) | District / Region within the specified country, where the message is applicable | C | |
| 1.7 | xs:dateTime | Date and time of publication including time zone (yyyy-mm-ddThh:mm:ss+hh:mm) | M | |
| 1e | ||||
| 2s | Fairway and traffic related section | C | 1 | |
| 2.1 | xs:string (64) | Internal ID | C | |
| 2.2s | NtS Number | M | ||
| 2.2.1 | xs:string (64)</organisation | Name of the publishing organisation (NtS Provider) | M | |
| 2.2.2 | xs:gYear (1900-9999) | Year of first issuing of the notice | M | |
| 2.2.3 | xs:integer (0-99999999) | Number of the notice (per year, starting with: 1, 0 shall not be used for published notices) | M | |
| 2.2.4 | xs:integer (0-99) | Serial number of notice (replacements and withdrawals), original notice: 0 | M | |
| 2.2e | ||||
| 2.3s | Target group information | C | ||
| 2.3.1 | nts:target_group_code_enum | Target group (vessel type) for this message | M | 5 |
| 2.3.2 | nts:direction_code_enum | Upstream or downstream traffic, or both | M | 5 |
| 2.3e | ||||
| 2.4 | nts:subject_code_enum | Subject code | M | |
| 2.5s | Overall period of validity | M | ||
| 2.5.1 | xs:date | Start date of validity period including time zone (yyyy-mm-dd+hh:mm) | M | |
| 2.5.2 | xs:date | End date of validity period including time zone (yyyy-mm-dd+hh:mm) | C | |
| 2.5e | ||||
| 2.6 | xs:string (500) | Additional information in local language | C | |
| 2.7 | xs:string (64) | Notice source (name of authority) | C | |
| 2.8 | nts:reason_code_enum | Reason / justification of notice | C | |
| 2.9s | Communication channel information | C | ||
| 2.9.1 | nts:reporting_code_enum | Reporting regime (information or duty to report) | M | 5 |
| 2.9.2 | nts:communication_code_enum | Communication code (telephone, VHF etc.) | M | 5 |
| 2.9.3 | xs:string (128) | Telephone, VHF number (including callsign), e-mail address, URL or teletext | C | |
| 2.9.4 | xs:string (256) | Name of the attachment or additional information | C | |
| 2.9.5 | xs:string (1024) | Additional remarks concerning the communication | C | |
| 2.9e | ||||
| 2.10s | Fairway section, also available for objects (no 2.11) | C | 2 | |
| 2.10.1s | Geo information of fairway | M | 5 | |
| 2.10.1.1 | nts:isrs_code_type | ISRS Location Code of the fairway section (2x) Pattern=[A-Z]{2}[A-Z]{3}[A-Z0-9]{5}[A-Z0-9]{5}[0-9]{5} | M | 7 |
| 2.10.1.2 | xs:string (256) | Local name of the fairway section (f.e.: Rhine between bridge A and bridge B) | M | |
| 2.10.1.3 | nts:type_code_enum | Type of geographical object (default=FWY) | M | |
| 2.10.1.4 | nts:position_code_enum | Describes the position related to the fairway | C | |
| 2.10.1.5s | Fairway section begin and end coordinates (2x) | C | 7 | |
| 2.10.1.5.1 | xs:string (10-12) | [d]d mm.mmm[m] N | M | 5 |
| 2.10.1.5.2 | xs:string (10-13) | [d][d]d mm.mmm[m] E | M | 5 |
| 2.10.1.5e | ||||
| 2.10.1.6 | xs:string (256) | Waterway name (usefull if no RIS Index is available). | C | |
| 2.10.1e | ||||
| 2.10.2s | Fairway section limitations | C | ||
| 2.10.2.1s | Limitation periods / intervals (All limitations have to include a limitation period with an interval code in order to allow proper calculations within voyage planning applications) | C | ||
| 2.10.2.1.1 | xs:date | Start date of limitation period (overall) INCLUDING time zone format=yyyy-mm-dd+hh:mm | M | 5 |
| 2.10.2.1.2 | xs:date | End date of limitation period INCLUDING time zone format=yyyy-mm-dd+hh:mm | C | |
| 2.10.2.1.3 | xs:time | Start time of limitation period WITHOUT time zone format=hh:mm:ss [whereas ss=00] | C | |
| 2.10.2.1.4 | xs:time | End time of limitation period WITHOUT time zone format=hh:mm:ss [whereas ss=00] | C | |
| 2.10.2.1.5 | nts:interval_code_enum | Interval for limitation (mandatory M(5) but is set to C to be compatible with former XSD version) | C | |
| 2.10.2.1e | ||||
| 2.10.2.2 | nts:limitation_code_enum | Kind of limitation | M | 5 |
| 2.10.2.3 | nts:position_code_enum | Describes the position of the limitation related to the fairway | C | |
| 2.10.2.4 | xs:float | Value of limitation (i.e. max draught) | C | |
| 2.10.2.5 | nts:unit_enum | Unit of the value of the limitation | C | |
| 2.10.2.6 | nts:reference_code_enum | Value reference | C | |
| 2.10.2.7 | nts:indication_code_enum | Minimum or maximum or reduced by | C | |
| 2.10.2.8s | Target group information | C | ||
| 2.10.2.8.1 | nts:target_group_code_enum | Target group (vessel type) for this limitation | M | 5 |
| 2.10.2.8.2 | nts:direction_code_enum | Upstream or downstream traffic, or both | M | 5 |
| 2.10.2.8e | ||||
| 2.10.2e | ||||
| 2.10e | ||||
| 2.11s | Object section | C | 2 | |
| 2.11.1s | Geo Information of object | M | 5 | |
| 2.11.1.1 | nts:isrs_code_type | ISRS Location Code of the object (1x) Pattern=[A-Z]{2}[A-Z]{3}[A-Z0-9]{5}[A-Z0-9]{5}[0-9]{5} | M | 8 |
| 2.11.1.2 | xs:string (256) | Local name of the aggregated object | M | |
| 2.11.1.3 | nts:type_code_enum | Type of geographical object | M | |
| 2.11.1.4 | nts:position_code_enum | Describes the position related to the object | C | |
| 2.11.1.5s | Object coordinates (1x) | C | 8 | |
| 2.11.1.5.1 | xs:string (10-12) | [d]d mm.mmm[m] N | M | 5 |
| 2.11.1.5.2 | xs:string (10-13) | [d][d]d mm.mmm[m] E | M | 5 |
| 2.11.1.5e | ||||
| 2.11.1.6 | xs:string (256) | Waterway name (usefull if no RIS Index is available). | C | |
| 2.11.1e | ||||
| 2.11.2s | Object limitation section | C | ||
| 2.11.2.1s | Limitation periods / intervals (All limitations have to include a limitation period with an interval code in order to allow proper calculations within voyage planning applications) | C | ||
| 2.11.2.1.1 | xs:date | Start date of limitation period (overall) INCLUDING time zone format=yyyy-mm-dd+hh:mm | M | 5 |
| 2.11.2.1.2 | xs:date | End date of limitation period INCLUDING time zone format=yyyy-mm-dd+hh:mm | C | |
| 2.11.2.1.3 | xs:time | Start time of limitation period WITHOUT time zone format=hh:mm:ss [whereas ss=00] | C | |
| 2.11.2.1.4 | xs:time | End time of limitation period WITHOUT time zone format=hh:mm:ss [whereas ss=00] | C | |
| 2.11.2.1.5 | nts:interval_code_enum | Interval for limitation (mandatory M(5) but is set to C to be compatible with former XSD version) | C | |
| 2.11.2.1e | ||||
| 2.11.2.2 | nts:limitation_code_enum | Kind of limitation | M | 5 |
| 2.11.2.3 | nts:position_code_enum | Describes the position of the limitation related to the fairway | C | |
| 2.11.2.4 | xs:float | Value of limitation (i.e. max draught) | C | |
| 2.11.2.5 | nts:unit_enum | Unit of the value of the limitation | C | |
| 2.11.2.6 | nts:reference_code_enum | Value reference | C | |
| 2.11.2.7 | nts:indication_code_enum | Minimum or maximum or reduced by | C | |
| 2.11.2.8s | Target group information | C | ||
| 2.11.2.8.1 | nts:target_group_code_enum | Target group (vessel type) for this limitation | M | 5 |
| 2.11.2.8.2 | nts:direction_code_enum | Upstream or downstream traffic, or both | M | 5 |
| 2.11.2.8e | ||||
| 2.11.2e | ||||
| 2.11e | ||||
| 2e | ||||
| 3s | Water related section | C | 1 | |
| 3.1 | xs:string (64) | Internal ID | C | |
| 3.2s | NtS Number | C | ||
| 3.2.1 | xs:string (64)</organisation | Name of the publishing organisation (NtS Provider) | M | 5 |
| 3.2.2 | xs:gYear (1900-9999) | Current year of the notice | M | 5 |
| 3.2.3 | xs:integer (0-99999999) | Number of the notice (see Developers Guide for WRM-Message Number generation) | M | 5 |
| 3.2.4 | xs:integer (0-99) | Serial number of the notice (see Developers Guide for WRM-Message Serial Number generation) | M | 5 |
| 3.2e | ||||
| 3.3s | Overall period of validity | M | ||
| 3.3.1 | xs:date | Start date of validity period including time zone (yyyy-mm-dd+hh:mm) | M | |
| 3.3.2 | xs:date | End date of validity period including time zone (yyyy-mm-dd+hh:mm) | C | |
| 3.3e | ||||
| 3.4s | Geo Information of measurement location | M | 5 | |
| 3.4.1 | nts:isrs_code_type | ISRS Location Code of the object/fairway (1x or 2x) Pattern=[A-Z]{2}[A-Z]{3}[A-Z0-9]{5}[A-Z0-9]{5}[0-9]{5} | M | 9 |
| 3.4.2 | xs:string (256) | Local name of the object/fairway | M | |
| 3.4.3 | nts:type_code_enum | Type of geographical object/fairway | M | |
| 3.4.4 | nts:position_code_enum | Describes the position related to the object/fairway | C | |
| 3.4.5s | Object/Fairway coordinates (1x or 2x) | C | 9 | |
| 3.4.5.1 | xs:string (10-12) | [d]d mm.mmm[m] N | M | 5 |
| 3.4.5.2 | xs:string (10-13) | [d][d]d mm.mmm[m] E | M | 5 |
| 3.3.5e | ||||
| 3.3.6 | xs:string (256) | Waterway name (usefull if no RIS Index is available). | C | |
| 3.4e | ||||
| 3.5 | nts:reference_code_enum | Value reference (measurement reference) | C | 6 |
| 3.6s | Measurements (normal or predicted values) | M | 5 | |
| 3.6.1 | xs:boolean | Predicted measurement (1 or true) or real measurement (0 or false) | M | |
| 3.6.2 | nts:measure_code_enum | Kind of water related information | M | |
| 3.6.3 | xs:float | Measured or predicted value | C | 10 |
| 3.6.4 | xs:float | Lowest value of confidence interval | C | |
| 3.6.5 | xs:float | Highest value of confidence interval | C | |
| 3.6.6 | nts:unit_enum | Unit of the water related value | C | |
| 3.6.7 | nts:barrage_code_enum | Barrage status | C | 11 |
| 3.6.8 | nts:regime_code_enum | Regime applicable | C | 12 |
| 3.6.9 | xs:dateTime | Date and Time of measurement or predicted value including time zone Format=yyyy-mm-ddThh:mm:ss+hh:mm | M | |
| 3.6.10s | Difference with comparative value | C | ||
| 3.6.10.1 | xs:float | Difference with comparative value | M | 5 |
| 3.6.10.2 | xs:duration | Time difference to measuredate of comparative value | M | 5 |
| 3.6.10e | ||||
| 3.6e | ||||
| 3e | ||||
| 4s | Ice related section | C | 1 | |
| 4.1 | xs:string (64) | Internal ID | C | |
| 4.2s | NtS Number | M | ||
| 4.2.1 | xs:string (64)</organisation | Name of the publishing organisation (NtS Provider) | M | |
| 4.2.2 | xs:gYear (1900-9999) | Current year of the notice | M | |
| 4.2.3 | xs:integer (0-99999999) | Number of the notice (per year, starting with: 1, 0 shall not be used for published notices) | M | |
| 4.2.4 | xs:integer (0-99) | Serial number of notice, original notice: 0 | M | |
| 4.2e | ||||
| 4.3s | Overall period of validity | M | ||
| 4.3.1 | xs:date | Start date of validity period including time zone (yyyy-mm-dd+hh:mm) | M | |
| 4.3.2 | xs:date | End date of validity period including time zone (yyyy-mm-dd+hh:mm) | C | |
| 4.3e | ||||
| 4.4s | Fairway section — the limitation inside the fairway section cannot be used in the ICEM | M | 5 | |
| 4.4.1s | Geo Information of fairway | M | 5 | |
| 4.4.1.1 | nts:isrs_code_type | ISRS Location Code of the fairway section (2x) Pattern=[A-Z]{2}[A-Z]{3}[A-Z0-9]{5}[A-Z0-9]{5}[0-9]{5} | M | |
| 4.4.1.2 | xs:string (256) | Local Name of the fairway section (f.e.: Rhine between bridge A and bridge B) | M | |
| 4.4.1.3 | nts:type_code_enum | Type of geographical object (default=FWY) | M | |
| 4.4.1.4 | nts:position_code_enum | Describes the position related to the fairway | C | |
| 4.4.1.5s | Fairway section begin and end coordinates (2x) | C | 7 | |
| 4.4.1.5.1 | xs:string (10-12) | [d]d mm.mmm[m] N | M | 5 |
| 4.4.1.5.2 | xs:string (10-13) | [d][d]d mm.mmm[m] E | M | 5 |
| 4.4.1.5e | ||||
| 4.4.1.6 | xs:string (256) | Waterway name (usefull if no RIS Index is available). | C | |
| 4.4.1e | ||||
| 4.4e | ||||
| 4.5s | Ice conditions | M | ||
| 4.5.1 | xs:dateTime | Date and Time of measurement or prediction including time zone Format=yyyy-mm-ddThh:mm:ss+hh:mm | M | |
| 4.5.2 | nts:ice_condition_code_enum | Condition code | C | 4 |
| 4.5.3 | nts:ice_accessibility_code_enum | Accessibility code | C | 4 |
| 4.5.4 | nts:ice_classification_code_enum | Classification code | C | 4 |
| 4.5.5 | nts:ice_situation_code_enum | Situation code | C | 4 |
| 4.5e | ||||
| 4e | ||||
| 5s | Weather related section | C | 1 | |
| 5.1 | xs:string (64) | Internal ID | C | |
| 5.2s | NtS Number | C | ||
| 5.2.1 | xs:string (64)</organisation | Name of the publishing organisation (NtS Provider) | M | 5 |
| 5.2.2 | xs:gYear (1900-9999) | Year of issuing of the notice | M | 5 |
| 5.2.3 | xs:integer (0-99999999) | Number of the notice (per year, starting with: 1, 0 shall not be used for published notices) | M | 5 |
| 5.2.4 | xs:integer (0-99) | Serial number of notice, original notice: 0 | M | 5 |
| 5.2e | ||||
| 5.3s | Overall period of validity | M | 13 | |
| 5.3.1 | xs:date | Start date of validity period including time zone (yyyy-mm-dd+hh:mm) | M | |
| 5.3.2 | xs:date | End date of validity period including time zone (yyyy-mm-dd+hh:mm) | C | |
| 5.3e | ||||
| 5.4s | Fairway section | M | ||
| 5.4.1s | Geo Information of fairway | M | ||
| 5.4.1.1 | nts:isrs_code_type | ISRS Location Code of the fairway section (2x) Pattern=[A-Z]{2}[A-Z]{3}[A-Z0-9]{5}[A-Z0-9]{5}[0-9]{5} | M | 7 |
| 5.4.1.2 | xs:string (256) | Local name of the fairway section (f.e.: Rhine between bridge A and bridge B) | M | |
| 5.4.1.3 | nts:type_code_enum | Type of geographical object (default=FWY) | M | |
| 5.4.1.4 | nts:position_code_enum | Describes the position related to the fairway | C | |
| 5.4.1.5s | Fairway section begin and end coordinates (2x) | C | 7 | |
| 5.4.1.5.1 | xs:string (10-12) | [d]d mm.mmm[m] N | M | 5 |
| 5.4.1.5.2 | xs:string (10-13) | [d][d]d mm.mmm[m] E | M | 5 |
| 5.4.1.5e | ||||
| 5.4.1.6 | xs:string (256) | Waterway name (usefull if no RIS Index is available). | C | |
| 5.4.1e | ||||
| 5.4e | ||||
| 5.5s | Weather Report (1x or 2x) | M | ||
| 5.5.1 | xs:dateTime | Date and Time of measurement or predicted value including time zone Format=yyyy-mm-ddThh:mm:ss+hh:mm | C | |
| 5.5.2 | xs:boolean | Forecast (true or 1) OR Actual report (false or 0) | M | |
| 5.5.3 | nts:weather_class_code_enum | Classification of weather report (0..Nx) | M | 3 |
| 5.5.4s | Weather items (0..Nx) | C | ||
| 5.5.4.1 | nts:weather_item_code_enum | Weather item type (Wind, Wave etc) | M | 5 |
| 5.5.4.2 | xs:float | Actual or Minimum value | M | 5 |
| 5.5.4.3 | xs:float | Maximum value | C | |
| 5.5.4.4 | xs:float | Gusts value (Wind) | C | |
| 5.5.4.5 | nts:unit_enum | Unit of the value | C | |
| 5.5.4.6 | nts:weather_category_code_enum | Classification of wind report | C | |
| 5.5.4.7 | nts:weather_direction_code_enum | Direction of wind or wave | C | |
| 5.5.4.8 | nts:weather_direction_code_enum | Direction of wind or wave | C | |
| 5.5.4e | ||||
| 5.5e | ||||
| 5e | ||||
| Legend for Occurrence (Occ.): Mandatory (M) Conditional (C) | Legend for Occurrence (Occ.): Mandatory (M) Conditional (C) | Legend for Occurrence (Occ.): Mandatory (M) Conditional (C) | Legend for Occurrence (Occ.): Mandatory (M) Conditional (C) | Legend for Occurrence (Occ.): Mandatory (M) Conditional (C) |
Rules applicable to table "NtS XSD V.4.0.4.0":
| 1. | In one at least two sections have to be filled in: — the section (1), — one of the following sections: — (fairway and traffic related messages) (2), — (water related message) (3), — (ice message) (4), — (weather related message) (5). |
| 2. | At least one of the Group 2.10 () or Group 2.11 () has to be given within . |
| 3. | A combinations of tags (5.5.3) in section can be given. |
| 4. | In group 4.5 () at least one of the conditional elements 4.5.2 to 4.5.5 have to be given. |
| 5. | If a conditional group contains mandatory subgroups or elements these will only be mandatory if the group on the higher level is applied. |
| 6. | Element is only mandatory for "WAL" (water level) in (3.5). |
| 7. | A in ( 2.10.1 , 4.4.1, 5.4.1) is defined by the begin and end ISRS Location Codes and coordinates (2 ISRS Location Codes and 2 sets of coordinates). |
| 8. | A in section ( 2.11.1) is defined by the ISRS Location Code and coordinates of its center point (1 ISRS Location Code 1 set of coordinates). |
| 9. | A in has 2 ISRS Location Codes and 2 sets of coordinates in case the (3.4.3) is "FWY", "RIV" or "CAN", otherwise only 1 ISRS Location Code and 1 set of coordinates has to be given. |
| 10. | If there is a measurement the elements (3.6.3) or (3.6.4) and (3.6.5) is/are mandatory if (3.6.2) is either "DIS", "VER", "LSD" or "WAL". In case there is no measurement (and a message should be sent anyhow) the value elements shall be omitted. |
| 11. | Element (3.6.7) is mandatory if (3.6.2) is "BAR". |
| 12. | Element (3.6.8) is mandatory if (3.6.2) is "REG". |
| 13. | Predictions for more than one (5.3) require individual messages. |
| 14. | In case of (4.4.2) and a section is not applicable. Limitations shall be provided via FTM notices. |
<!--
===========================================
= definition of main element RIS_Message =
= and corresponding type RIS_Message_Type =
===========================================
-->
River Information Service Message
Identification section
One msg contains one of these sections
Fairway and traffic related section
Water related section
Ice related section
Weather related section
<!--
==========================================
= definition of identification_type, =
= used in definition of RIS_Message_Type =
==========================================
-->
Internal ID
Sender (System) of the message
Originator (initiator) of the information in this message
Country where message is valid
Original language used in the textual info. (contents)
Reading this document does not replace reading the official text published in the Official Journal of the European Union. We assume no responsibility for any inaccuracies arising from the conversion of the original to this format.
This text is published under EUR-Lex's own terms of reuse, not a Legalize or public-domain licence.
EUR-Lex
Creative Commons Attribution 4.0 International (CC BY 4.0)
© European Union, https://eur-lex.europa.eu — Source: EUR-Lex (Publications Office of the European Union). Reused under the Creative Commons Attribution 4.0 International (CC BY 4.0) licence. Only EU legislation published in the printed Official Journal of the European Union is deemed authentic; consolidated texts are reproduced here for documentation purposes and have been reformatted to Markdown.