EUR-Lex Access to European Union law

Back to EUR-Lex homepage

This document is an excerpt from the EUR-Lex website

Document 02007R0416-20181229

Consolidated text: Commission Regulation (EC) No 416/2007 of 22 March 2007 concerning the technical specifications for Notices to Skippers as referred to in Article 5 of Directive 2005/44/EC of the European Parliament and of the Council on harmonised river information services (RIS) on inland waterways in the Community

ELI: http://data.europa.eu/eli/reg/2007/416/2018-12-29

02007R0416 — EN — 29.12.2018 — 001.001


This text is meant purely as a documentation tool and has no legal effect. The Union's institutions do not assume any liability for its contents. The authentic versions of the relevant acts, including their preambles, are those published in the Official Journal of the European Union and available in EUR-Lex. Those official texts are directly accessible through the links embedded in this document

►B

COMMISSION REGULATION (EC) No 416/2007

of 22 March 2007

concerning the technical specifications for Notices to Skippers as referred to in Article 5 of Directive 2005/44/EC of the European Parliament and of the Council on harmonised river information services (RIS) on inland waterways in the Community

(OJ L 105 23.4.2007, p. 88)

Amended by:

 

 

Official Journal

  No

page

date

►M1

COMMISSION IMPLEMENTING REGULATION (EU) 2018/2032 of 20 November 2018

  L 332

1

28.12.2018




▼B

COMMISSION REGULATION (EC) No 416/2007

of 22 March 2007

concerning the technical specifications for Notices to Skippers as referred to in Article 5 of Directive 2005/44/EC of the European Parliament and of the Council on harmonised river information services (RIS) on inland waterways in the Community



Article 1

This Regulation defines the technical specifications for Notices to Skippers. The technical specifications are set out in the Annex to this Regulation.

Article 2

This Regulation shall enter into force on the day following its publication in the Official Journal of the European Union.

This Regulation shall be binding in its entirety and directly applicable in all Member States.

▼M1




ANNEX

TABLE OF CONTENTS

1.

GENERAL PROVISIONS

1.1.

Definitions

1.2.

Primary functions and performance requirements for Notices to Skippers (NtS)

2.

PROVISION OF NOTICES TO SKIPPERS

3.

NtS MESSAGE TYPES

4.

STRUCTURE OF NtS AND ENCODING of NtS MESSAGES

4.1.

General structure

4.1.1.

Identification section

4.1.2.

Fairway and traffic related message

4.1.3.

Water related message

4.1.4.

Ice related message

4.1.5.

Weather related message

4.2.

Explanation of XML tags and code values in the NtS Reference Tables

4.3.

Identification of fairway sections and objects in NtS messages

4.4.

Rules for encoding of NtS messages

Appendix A: NtS Encoding Guide for editors

Appendix B: NtS Encoding Guide for application developers

Appendix C: NtS XML Schema Definition (XSD)

Appendix D: NtS Web Service Specification (WSDL)

1.   GENERAL PROVISIONS

1.1.    Definitions

Fairway Information Services (FIS) mean geographical, hydrological and administrative information regarding the waterway (fairway) that are used by boatmasters and fleet managers to plan, execute and monitor a voyage. The terms ‘boatmaster’ and ‘skipper’ used in the present standard shall be deemed to be equivalent with the term ‘ship master’ used in the River Information Services (RIS) Guidelines (Commission Regulation (EC) No 414/2007 ( 1 )), while the term ‘fleet managers’ is defined in Commission Regulation (EC) No 415/2007 ( 2 ).

FIS provide dynamic information (such as water levels, water level predictions) as well as static information (such as operating times of locks and bridges) regarding the use and status of the inland waterway infrastructure, and thereby support tactical and strategic navigation decisions.

Traditional means to supply FIS include visual aids to navigation, notices to skippers published on paper, provided by broadcast and by fixed telephone on locks. The mobile phone has added new possibilities of voice and data communication, but cellular network is not available in all places and at all times. Tailor-made FIS for the waterways can be supplied by radiotelephone service on inland waterways, Internet service or electronic navigational chart service, such as the Inland Electronic Chart Display and Information System (Inland ECDIS) with Electronic Navigational Chart (ENC).

1.2.    Primary functions and performance requirements for Notices to Skippers (NtS)

This technical specification for NtS provides rules for the data transmission of fairway information via Internet.

NtS shall:

(a) provide information related to fairway conditions, traffic, weather, water levels and ice for Fairway Information Services;

(b) provide automatic translation of the most important content of notices, using standard vocabulary based on code lists (the NtS Reference Tables as provided in Appendix E);

(c) be provided in a standardised structure of data-sets to facilitate the integration of notices in voyage planning systems;

(d) be compatible with the data-structure of the RIS Index and Inland ECDIS to facilitate integration of NtS into Inland ECDIS as stipulated by Directive 2005/44/EC of 7 September 2005 on harmonised RIS on inland waterways in the Community.

The technical specifications for NtS facilitate the data-exchange among NtS systems of different countries and towards other applications making use of NtS data, including Inland ECDIS.

Some information contained within NtS messages can be standardised, some cannot.

The standardised part shall cover all the information which is:

(a) important for the safety of inland navigation (for example: sunken small craft on the right side of the fairway at the Danube, river-km 2010);

(b) needed for voyage planning including closure of locks and reduction of vertical clearance.

Additional information that is not relevant for safety or voyage planning, including the cause of the closure of a lock, may be given as free text, without automatic translation. The use of free text shall be restricted to a minimum.

2.   PROVISION OF NOTICES TO SKIPPERS

Member States shall ensure that NtS messages are accessible online and via standardised NtS web service, in accordance with the technical specifications described in this Annex and its Appendices. The standardised NtS web service specification is included in Appendix D in the form of a ‘Web Service Description Language’ (WSDL).

The standardised NtS web services shall provide the user with the possibility to select messages on the grounds of at least one of the following criteria:

(c) a specific waterway section;

(d) a specific part of a waterway, defined by the river-km of the starting and the end point;

(e) time of validity of the notice (start date and end date of validity period);

(f) date of publication of the notice (date and time of publication).

NtS messages that comply with the standards referred to in this Annex can be provided, among other tools, by:

(a) mobile applications (apps);

(b) E-mail services.

Data exchange among the NtS systems operated in different countries may be carried out. All systems using the standards described in the Annex of this Regulation may integrate NtS of other systems in their own services, provided the content of the message is not modified. Users shall be informed in case the connection to a source of integrated NtS is interrupted or not available.

3.   NTS MESSAGE TYPES

NtS messages are essential messages that are standardised to the highest part possible.

There are four NtS message types, namely:

(a) fairway and traffic related message;

(b) water related message;

(c) ice related message;

(d) weather related message.

4.   STRUCTURE OF NTS AND ENCODING OF NTS MESSAGES

This chapter describes the structure and encoding of standardised electronic NtS messages.

An NtS message is a structured message using standardised elements, wherever possible. The use of free text in the data elements shall be restricted to a minimum.

The standardised NtS extended markup language (XML) schema definition, referred to as XSD in this standard, contains the standardised code values and possible formats is included in Appendix C.

The standardised code values and the XML tags, their meaning and translation are provided in the NtS Reference Tables in Appendix E and are also available electronically in the European Reference Data Management System (ERDMS) operated by the European Commission.

4.1.    General structure

An NtS message consists of the following sections:

(a) identification section;

(b) section defining the applicable object(s) or fairway section(s) the message is related to;

(c) limitation(s) for a fairway and traffic related message, measurement(s) for a water related message, ice condition(s) for an ice related message or weather report(s) for a weather related message.

Figure 1

Notice to Skippers message structure

image

4.1.1.    Identification section

Each message must contain an identification section. The identification section contains general information about the issuer and date of publication of the message.

4.1.2.    Fairway and traffic related message

The fairway and traffic related message contains information for fairway section(s) or object(s), and it is used to indicate limitation(s) for the following purposes:

(a)  ‘Warning’: relevant for safety. The warning must contain at least one limitation that results in direct and concrete endangerment of persons, crafts or facilities, such as welding works on a bridge producing sparks, inspection cage/workers hanging from a bridge, obstacle in the fairway,

(b)  ‘Announcement’: relevant for voyage planning or safety. The announcement may contain limitations, such as blockage of a lock chamber due to maintenance works, dredging on the fairway,

(c)  ‘Info service’: general information that is not directly linked to voyage planning or safety. The info service must not contain specific limitations, therefore it is not directly relevant to voyage planning or safety. Such information might include general information such as local rules of traffic, Inland ECDIS Update.

4.1.3.    Water related message

The water related section contains values or predictions for:

(a) water level;

(b) least sounded depth;

(c) vertical clearance;

(d) barrage status;

(e) discharge;

(f) regime.

Usually, water related information is created and published automatically based on data received from sensor equipment (such as tide gauge), systems (such as water level model) or infrastructure (such as barrage status). There may be different triggers for publication, such as periodical publication or reaching certain value.

4.1.4.    Ice related message

The ice related message contains information about the actual or predicted ice conditions for fairway section(s). Ice related information is usually generated by competent personnel based on local observation and professional assessment.

4.1.5.    Weather related message

The weather related message contains information about (dangerous) weather conditions for inland navigation.

In order to facilitate the distribution of hydro-meteo information from hydro-meteo networks to skippers, weather related messages may be published.

4.2.    Explanation of XML tags and code values in the NtS Reference Tables

The meaning of the different elements used in the NtS XML schema definition (XSD) is described in the NtS Reference Tables provided in Appendix E. The structure, format and possible values of all XML elements are described in the NtS XSD in Appendix C.

(a) Latitude and longitude coordinates are encoded according to the World Geodetic System 1984 and are presented in degrees and minutes with at least three, but preferable four decimals ([d]d mm.mmm[m] N, [d][d]d mm.mmm[m] E).

(b) Decimals in numeric fields are indicated with a decimal point (‘.’). No separators for thousand are used.

(c) NtS messages shall only use the following units for the values included in the XML message: cm, m3/s, h, km/h and kW, m/s (wind), mm/h (rain) and degree Celsius. National applications may convert the units for user-friendly display.

4.3.    Identification of fairway sections and objects in NtS messages

To fulfil the minimum data requirements for provision of information about objects relevant for Inland navigation as referred to in Article 4(3)(a) of Directive 2005/44/EC, the ISRS Location Code has to be used in the object section. The ISRS Location Code is used to uniquely identify objects and fairway sections and to ensure interoperable RIS Systems and Services (such as to combine information about infrastructure from the RIS Index, Inland ECDIS and NtS for voyage planning).

The ISRS Location Code is a 20-digit alphanumerical code used to establish a unique and standardized relation between objects in River Information Services. It consists of the following mandatory data elements, arranged in four information blocks:

(a) Block 1: UN/LOCODE (5 letters, alphanumerical), comprising

 Country code (2 digits, alphanumerical) ( 3 ), and

 Location code (3 digits, alphanumerical, ‘XXX’ if not available)

(b) Block 2: Fairway section code (5 digits, alphanumerical, to be determined by the national authority)

(c) Block 3: Object Reference Code (5 digits, alphanumerical, ‘XXXXX’ if not available)

(d) Block 4: Fairway section hectometre (5 digits, numerical, hectometre at the centre of the area or ‘00000’ if not available).

The ISRS Location Codes and the reference data of objects are maintained by the Member States in the RIS Index and submitted to the ERDMS operated by the European Commission according to the Maintenance procedures for the RIS Index published on the ERDMS website.

4.4.    Rules for encoding of NtS messages

NtS messages shall be encoded in line with the NtS Encoding Guide for editors (Appendix A) and in line with the NtS Encoding Guide for application developers (Appendix B).




NOTICES TO SKIPPERS ENCODING GUIDE FOR EDITORS

CONTENTS

1.

Background, structure and purpose of NtS Encoding Guides

2.

Selection of the NtS message type

3.

FTM basic considerations, steps towards publication of an FTM

4.

FTM explanation of codes

5.

WRM basic considerations

6.

ICEM basic considerations, steps towards publication of an ICEM

7.

WERM basic considerations

8.

Rules for certain elements

Abbreviations:



Abbreviation

Meaning

CEVNI

European Code for Inland Waterways (http://www.unece.org/trans/main/sc3/sc3res.html)

ENC

Electronic Navigational Chart

FTM

Fairway and Traffic related Message

ICEM

ICE Message

Inland ECDIS

Inland Electronic Chart Display and Information System

ISRS Location Code

‘International Ship Reporting Standard’ Location Code

NtS

Notices to Skippers

RIS

River Information Services

VHF

maritime mobile band

WERM

Weather Related Message

WRM

Water Related Message

WSDL

Web Services Description Language

XML

Extended Markup Language

XSD

XML Schema Definition

1.    Background, structure and purpose of NtS Encoding Guides

The NtS Standard is continuously being improved. A major step forward was the release of the NtS web service facilitating exchange of NtS messages between authorities as well as between authorities and NtS users.

Two documents have been developed to facilitate the harmonised encoding of NtS messages nationally and internationally: the NtS Encoding Guide for editors and the NtS Encoding Guide for application developers. These Guides apply to NtS XSD 4.0 and the NtS Web Service WSDL 2.0.4.0.

Considering increased use of the NtS web service, NtS messages shall be further harmonised to ensure proper display of content on third party systems. Uniform encoding of messages is also a prerequisite for consideration of messages in voyage planning applications.

Elements that would contain only standard or default values shall be omitted if they are conditional, because they lead to message overhead with no added value.

The NtS Encoding Guide for editors is intended for those editing (and publishing) of NtS messages, including step-by-step instructions to create the proper message types as well as an explanation of codes. The NtS Encoding Guide explains the applicability of the four NtS message types, provides filling instructions as well as codes to be used in certain events. The NtS Encoding Guide for editors is included in the present Appendix A.

The NtS Encoding Guide for application developers includes guidelines for NtS application development and implementation, explaining its logic, processes and auto/default values. The NtS Encoding Guide for application developers is included in Appendix B of the Annex to this Regulation.

2.    Selection of the NtS message type

 FTM: Choose this type if you want to create a ‘Fairway and traffic related message’ for waterways or objects on the waterway. [go to chapter 3]

 WRM: Choose this type if you want to create a ‘Water related message’, which enables provision of information on current and predicted water levels as well as other information. The water related message contains information for an object or a fairway section. The object is identified by its ISRS Location Code, the fairway section is defined by its begin- and end-ISRS Location Codes.

 ICEM: Choose this type if you want to create an ‘Ice related message’. The Ice message section contains information about the ice conditions for a fairway stretch defined by its begin- and end-ISRS Location Codes.

 WERM: Choose this type if you want to create a ‘Weather related message’, which enables provision of information on current as well as forecasted weather situations on a waterway stretch defined by its begin- and end-ISRS Location Codes.

3.    FTM basic considerations, steps towards publication of an FTM

Detailed information which codes have to be used is given in chapter 4. The considerations beginning from 3.3 are not necessarily in the input order of an FTM editor tool.

3.1. Is there a need to publish information via NtS FTM according to NtS Standard? All relevant information concerning safety and voyage planning has to be published via NtS messages. Information that is not relevant in terms of safety and voyage planning may be published. Each topic/incident/event has to be published in a separate message.

3.2. Does a valid FTM already exist related to the current situation (related to the content as well as to the time of validity)?

3.2.1. Yes:

The already existing FTM has to be updated. The respective published message has to be selected and updated in the FTM editor tool. An expired FTM cannot be updated any more.

3.2.2. No:

A new FTM has to be compiled. In case a similar event is already coded in an existing FTM the respective FTM can be used as draft for the creation of a new FTM (if this function is available), or a template may be used (if this function is available).

3.3. The geographical range of validity is to be set

3.3.1. In case the FTM is related to a specific stretch of a waterway, the waterway stretch has to be included, defined by its begin- and end points. If the content applies to several sections of the same waterway or different waterways they can all be listed in one FTM.

3.3.2. In case the FTM is related to a specific object (e.g. bridge, lock etc.) on the waterway the respective object is to be selected out of the list of available objects (if selection is available). There is no need to define a waterway stretch within the message. In case an FTM applies to several objects they can all be included in one FTM.

3.3.3. Combination of object- and fairway-related information is possible within one message as long as the information relates to one specific cause/event (same subject and reason code).

3.3.4. Although the coordinates are conditional they shall be provided to support the display on maps (often these coordinates are automatically provided by the NtS application).

3.4. Content of the FTM is to be entered

All information that can be expressed using the NtS Reference Tables has to be coded in the standardised message fields. Only additional information (which is not encodable otherwise) shall be stated in free text fields.

3.5. The target group(s) concerning the type of vessels and affected directions is/are to be entered if applicable.

3.5.1. In case the message is valid for all crafts (all types of vessels) in all directions the target group shall be left out in order to only code essential information. If the message/limitation is addressed to a specific target group or direction the respective codes are to be selected.

3.5.2. In case the whole message is valid for specific target groups, the target group information is to be provided in the general part of the FTM (and not repeated in the limitation section(s)).

3.5.3. In case there are different target groups applicable to different limitations the target group information is to be provided within the respective limitations (and not repeated in the general part).

3.5.4. In case exemptions from limitations are granted to individual vessels or local traffic by the competent authorities (e.g. vessels participating in an event for which a general blockage is applicable, local ferry traffic in blocked areas) such exemptions need not be taken into account for coding of the target group(s). Such information may be stated in the free text field for additional information.

3.6. The communication section is to be entered if applicable

If additional information is available via a specific source it should be stated in this section. If there is an additional obligation to report via a specific medium it is to be stated in this section.

3.7. The limitation section is to be entered if applicable

If limitations are applicable the limitation section is to be filled. If values bound to limitations are known they have to be stated. It is mandatory to provide values for ship dimensions, the speed limit and the available space for navigation.

All limitations have to include the limitation periods in order to allow proper calculations within voyage planning applications (to ease the work there might be a function provided by the NtS application to copy limitation periods or to select more than one limitation for a limitation period).

3.8. The start date of the validity of the message is to be set

In case the end date of the validity of a message is already known it shall be set as well. The validity end date must not be before the present date.

Note that the validity period information will be used by applications to select the messages, which are to be displayed to users for a requested time.

In case the message is withdrawn:

(a) before its validity period has begun the start date and end date have to be set to the date of withdrawal;

(b) and the validity period has already started, the new end dates for all limitations are to be set to the past, the validity date end has to be set to the date of withdrawal.

3.9. The message can be published

4.    FTM explanation of codes

4.1.   Subject_code:

Definition of use of Subject Codes:

 ‘‘Warning’: relevant for safety. The warning must contain at least one limitation that results in direct and concrete endangerment of persons, crafts or facilities, e.g. welding works on a bridge producing sparks, inspection cage/workers hanging from a bridge, obstacle in the fairway,

 Announcement’: relevant for voyage planning or safety. The announcement may contain limitations, e.g. blockage of a lock chamber due to maintenance works, dredging on the fairway, rules of traffic in addition to national legislation,

  ‘Info service’: general information that is not directly linked to voyage planning or safety. The info service must not contain specific limitations, therefore it is not directly relevant to voyage planning or safety. Such information might include e.g. local rules of traffic, Inland ECDIS Update. 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 or as defined in the national procedures).

  ‘Notice withdrawn’

 The subject code ‘Notice withdrawn’ is only used if

 

 present date is before the start date of validity. In this case only the content of the field ‘additional information in national language’ may be altered, the further content of the message has to stay unchanged. In this case ‘Notice withdrawn’ is used to pull back a notice before it gets valid. This means that ‘Notice withdrawn’ is used for notices that did not reach the start date of the validity and/or for planned measures that will not be carried out (e.g. dredging was planned but cannot be started due to high water level),

 the validity period has already started and the new end dates for all limitations are set to the past. The validity date end has to be set to the date of withdrawal.

 In this case measures/events end before the initially set validity period of an already existing FTM has finished.

4.2.   Reason_code

The Reason code should be filled to give additional information to the skippers.

Definition of use of Reason codes:



building work

Announcement of construction works

calamity

Warning of a calamity

changes of the fairway

Announcement of changes of the fairway

change marks

Announcement of changes of waterway marks

constriction of fairway

Announcement of a reduced width of the fairway if no other reason_code is applicable

damaged marks/signs

Announcement about damaged marks/signs

diver under the water

Warning about diver under water

dredging

Announcement of dredging works

event

Announcement of events e.g. swimming-, sailing- or rowing competition

exercises

Announcement of exercises e.g. rescue- or military exercises

explosives clearing operation

Announcement of explosives clearing operation

extensive sluicing

Announcement of higher discharge rate as usual through weirs or locks for water management reasons

falling material

Announcement of falling material e.g. icicles, limbs of trees

false radar echos

Announcement of the possibility of false radar echoes

fireworks

Announcement of fireworks

floating material

Announcement regarding floating materials above the water level (visible) and below the water level (invisible)

flow measurement

Announcement of measurement works

health risk

Warning or announcement regarding e.g. through oak processionary caterpillar, leaking gas, etc.

high voltage cable

Announcement of an intersecting high voltage cable

high water

Announcement of a high water situation before the prohibitory water level is reached

ice

Announcement of ice; further information will be sent out via ice-information (Ice-related Message)

Inland ECDIS update

Info service regarding an Inland ECDIS update

inspection

Announcement of inspection works; only used in case of inspection; not used for (repair/building) works. There may be limitations because of inspection cars/cages or scaffolds

launching

Announcement of a vessel leaving a dockyard

local rules of traffic

Info service regarding supplementary or changed rules of valid law or regulation without special limitations, dates of limitations or dates of validity

low water

Announcement of low water situation before the prohibitory water level is reached

lowering water level

Announcement of a controlled lowering of the water level for inspections or works or water management reasons

minimum sluicing

Announcement of lower discharge rate as usual through weirs or locks for water management reasons

new object

Announcement of information regarding a new available object e.g. bridge, berth

obstacle

Announcement of a reduced clearance height and/or reduced width of the fairway because of an obstacle above water level

obstruction under water

Announcement of a reduced available depth and/or for a reduced width of the fairway because of an obstacle under water

prohibitory water level

Announcement of a water level (high water or low water) which causes prohibited navigation

radio coverage

Announcement regarding radio coverage

removal of object

Announcement of removed objects

repair

Announcement in case something is broken or out of order and must be repaired e.g. a lock control system, it can also be used for planned repairs

rising water level

Announcement of natural rising water levels, not because of water management

siltation

Announcement of a reduced available depth because of siltation

sounding works

Announcement of sounding works

special marks

Announcement of the use of special marks e.g. for the blocking from water areas or fishing areas

special transport

Announcement of special transports

strike

Announcement regarding strike of the operating personnel having impact on availability of waterway infrastructure

water level of cautious navigation

Announcement of a water level (high water or low water) by which particular caution for navigation is needed

work

Announcement of general works at objects, at the banks and/or beds of waterways (rivers- or canals)

limitations

Shall only be used as indication for existing limitations if no other reason code is applicable

others

Shall not be used, in case no other reason code fits, the reason code shall not be filled

4.3.   Limitation_code:

Definition of use of Limitation codes:

 blockage:

 In case no form of navigation is possible:

 

 through a lock chamber,

 through a bridge opening,

 through a specified point on the fairway,

 on a specified section of the fairway.

 partial obstruction:

 All parts of infrastructure (e.g. lock chambers, bridge openings) shall have an own ISRS Location Code. In case such codes are still missing partial obstruction may be used in case limited navigation is possible (e.g. only lock area object available for a lock having two parallel chambers)

 

 through one or more lock chambers of a lock, leaving at least one open,

 through one or more bridge openings, leaving at least one open.

 no service:

 shall be used in case a movable bridge is not operated during a specified period. This period should be within the normal operating hours.

 No service of a movable bridge means that passing under the bridge is still possible. Otherwise it is a ‘Blockage’. No service of a lock is to be encoded as ‘Blockage’.

 changed service:

 shall be used in case the normal operating hours of objects (e.g. locks, (moveable) bridges) change, are extended or reduced.

 If there are limitations related to allowed vessel/convoy dimensions (not in direct relation with infrastructure), the limitation is to be encoded with the following text elements:

 

 vessel draught,

 vessel breadth,

 convoy breadth,

 vessel length,

 convoy length,

 vessel air draught.

 If available an absolute value shall be provided.

 If there are limitations related to available size of an object or a waterway section, the following codes are used:

 

 clearance height,

 available length,

 clearance width,

 available depth.

 If available an absolute value shall be provided.

 least depth sounded: shall be used in case depth may cause problems (e.g. due to siltation). A value for the absolute depth (referred to a reference value) or the reduction of depth shall be provided. If available an absolute value shall be provided.

 delay: shall be used in case an obstruction/incident with a limited duration occurs at an object or on a waterway section between a specified start and end date.

 The estimated maximum duration of the obstruction/incident should be encoded. Delay shall not be used in cases when one of several lock chambers of a lock is not available.

 If specific manoeuvres or actions are prohibited, the respective limitations are to be encoded. These limitations shall only be encoded if they are not already announced via navigational signs or regulations that are encoded in the official Inland ENC:

 

 minimum power,

 alternate traffic direction,

 no turning,

 no passing,

 no overtaking,

 no berthing,

 no mooring,

 no anchoring,

 no wash of waves,

 speed limit,

 not allowed to go ashore.

 If available an absolute value shall be provided for speed limit and minimum power.

 special caution: In cases the FTM (or a part of an FTM) is related to a fairway/waterway this limitation shall be used to indicate on which position of the fairway/river/canal/lake an incident occurs.

 Furthermore it shall be used in cases if it is not possible to describe the limitation in detail but it is helpful or necessary to warn or inform skippers that they have to watch out and pay attention to radio information.

 no limitation: should only be used in case it shall be explicitly stated that there are no limitations in a certain time period.

4.4.   Limitation interval_code: Definition of use of interval codes:

 ‘continuous’: shall be used for limitations that are applicable from a start date/time until an end date/time without interruption (e.g. blockage from 01.01.2016, 00:00 hrs, until 31.03.2016, 23:59 hrs, but also blockage on 17.09.2016 from 08:00 hrs until 18:00 hrs).

 ‘daily’: shall be used for regularly repeated application of a limitation (e.g. no wash of waves during working hours at a dredging site — 07.04.2016 until 11.04.2016, daily from 06:00 hrs until 18:00 hrs).

 day-time (as it is defined in CEVNI): The term ‘day’ means the period between sunrise and sunset.

 night-time (as it is defined in CEVNI): The term ‘night’ means the period between sunset and sunrise.

 Days of the week: If there are intervals related to different days of the week these have to be selected from the following text elements:

 

 Monday,

 Tuesday,

 Wednesday,

 Thursday,

 Friday,

 Saturday,

 Sunday,

 Monday to Friday,

 Saturday and Sunday.

 ‘in case of restricted visibility’: shall be used if the limitation is only in force in case of conditions in which visibility is reduced owing to fog, haze, snow, rain or other reasons.

 ‘with the exception of’: It must not be used; Interrupted intervals have to be given as separate limitation periods within the same limitation. This is due to the fact that voyage planning software is not able to interpret this code correctly as not taking place at the given date or time. Thus it is not possible to calculate proper ETAs.

 ‘Monday to Friday except public holidays’: is only to be used if public holidays are within the validity period of the limitation. As a service for the users public holiday may be stated in the free text section of the FTM. Voyage planning software will not be able to take national public holidays into account for the calculation of ETAs.

4.5.   Indication_code:

The Indication_code is intended to be used for information about specific values with regard to certain limitations (e.g. speed limit, minimum power, available depth). In order to determine certain dimensions a reference to either an external reference system (geographical or hydrological) (e.g. clearance height, available depth, least depth sounded) or relative to known dimensions of artificial structures (e.g. available length, clearance width) is necessary.

4.5.1. If absolute dimensions or references are known they have to be used. Only if it is not possible to refer to an external reference system relative values should be used.

4.5.2.

 

reduced by

→ this is a relative value

4.5.3.

 

maximum

→ this is an absolute value

4.5.4.

 

minimum

→ this is an absolute value

4.5.5. If the dimension indicating a limitation refers to a geographical or hydrological co-ordinate, the respective reference system has to be indicated in the NtS message (e.g. clearance height min. 4 m referred to highest navigable water level; available depth min. 1,7  m referred to regulated low water level)

4.5.6. If the dimension indicating a limitation refers to a dimension of an artificial structure (e.g. bridge, lock), the reference may be given relative to known dimensions (e.g. clearance height reduced by 1,5  m, available length reduced by 27 m).

4.6.   Position_code (objects):

Wherever possible the Position_code shall refer to the side of the fairway where the object is located relative to the fairway axis (left/middle/right) or other commonly known information (old/new) or geographic direction (north/south/east/west). The position_code for objects may be prefilled automatically from the RIS Index reference data. The left/right side of the fairway is defined looking downstream direction.

4.7.   Position_code (fairways/waterways):

A Position_code for an FTM (or a part of an FTM) that is related to a fairway or waterway is not provided. To indicate on which side of the fairway/canal/river/lake an incident occurs the limitation ‘special caution’ in combination with the proper limitation Position_code is used.

4.8.   Position_code (limitations):

4.8.1. Wherever possible the Position_code shall refer to the side of the fairway or object where the limitation occurs (left/right). The left/right side of the fairway is defined looking downstream direction.

4.8.2. The Position_code shall direct the attention of the skipper to the side of the fairway where e.g. an area of special interest, a danger or an obstacle is located. Therefore a rough indication (e.g. left bank — left — middle — right — right bank) is sufficient. A finer subdivision is not intended.

4.8.3. If necessary, more precise position information should preferably be given by way of maps or sketches (attachment, see chapter 3.6)

4.8.4. For sections where the usual position indication by fairway side (left/right) does not seem appropriate (e.g. harbour basins, certain canal sections without distinct direction of flow) the cardinal points (north/east/south/west) may be used.

4.9.   Target_group_code (see chapter 3.5)

4.10.   Reporting_code

4.10.1. The Reporting_code shall, as a general rule, only be used in case there is a special need for communication (e.g. additional duty to report to local authority with regard to on-site traffic regulation) or where additional information is available (e.g. VHF contact point like channel name or call-sign for current position of dredger) with direct relevance for the FTM.

4.10.2. A routine reiteration of publicly available communication data (e.g. telephone numbers of local authorities, VHF channels of locks, etc.) shall be avoided if there is no direct cause for such communication with reference to the FTM.

4.10.3. Generally applicable means of communication according to official regulation (e.g. ship-to-ship and ship-to-shore VHF communication as laid down by CEVNI or regional or national rules for navigation) shall, as a general rule, not be repeated by the Reporting_code if there is no direct cause for such communication with reference to the FTM).

4.11.   Communication_code

The following format shall be used (examples):

 VHF ‘number, call sign’: ‘10, Schifffahrtsaufsicht Wien’

 Phone or Fax number: ‘+43123456789, Schifffahrtsaufsicht Wien’

 Internet address: ‘http://example.com’

 Sound signalling: ‘long blast / langer Ton’

 E-mail: ‘example@authority.eu’

 EDI mailbox number: ‘900012345@edi.bics.nl’

 Teletext: ‘ARD, 992 — 995’

4.12.   Type_code:

A waterway is either a canal, lake or river.

 anchoring area

 bank

 beacon

 berth

 border control

 bridge

 bridge opening

 buoy

 cable overhead

 canal (The term ‘canal’ is used if a message is relating to the whole canal (not just the fairway))

 canal bridge: aqueduct

 culvert

 fairway (The term ‘fairway’ means that part of the waterway that can actually be used by shipping).

 ferry

 floating dock

 flood gate (A flood gate is used to protect an area in high water situations)

 harbour

 harbour facility

 harbour master's office

 lake (The term ‘lake’ is used if a message is relating to the whole lake (not just the fairway))

 light

 lock basin: individual lock chamber

 lock: whole lock complex

 mooring facility

 notice mark

 pipeline

 pipeline overhead

 ramp

 refuse dump

 reporting point

 reservoir

 river (The term ‘river’ is used if a message is relating to the whole river (not just the fairway))

 ship lift

 shipyard

 signal station

 terminal

 tide gauge

 tunnel

 turning basin

 vessel traffic centre

 weir (A weir is used to control the water level in rivers).

5.    WRM basic considerations

Water related messages shall, as a general rule, be generated automatically. Where this is not possible the manual generation of WRM shall follow the processes set out for automatically generated WRM (see NtS Encoding Guide for Developers) as closely as possible.

6.    ICEM basic considerations, steps towards publication of an ICEM

Ice Messages depend on local observation and assessment and will usually be generated by authorised staff.

An ICEM shall be issued in case of ice. Ice does not necessarily cause limitation for navigation however information about ice condition not hindering navigation may be provided.

6.1. Is there a need to publish information via NtS ICEM?

The first ice message for a stretch shall only be published in case of ice at the waterway or tributaries, also in case there are no limitations.

6.2. Does a valid ICEM already exist for the affected stretch of the waterway?

6.2.1. Yes:

If a message for the affected stretch is (still) valid the already existing message shall be updated. It is possible to update existing ice messages even if the area of applicability changes (e.g. ice is expanding increasing the size of affected stretch).

6.2.2. No:

In case there is no valid ice message available for the affected stretch, a new message is to be created.

6.3. However information about ice condition not hindering navigation may be provided.

6.4. One ICEM is always valid for one single stretch of the waterway. The geographical range of validity is to be set by defining the waterway and the respective begin- and end-(hectometre)points (or choosing certain consecutive sections, depending on national implementation).

6.5. Measurement time is to be entered. The respective ice conditions are to be entered by using at least one of the code lists (depending on national requirements).

6.5.1. Ice_condition_code

6.5.2. Ice_accessibility_code

6.5.3. Ice_classification_code

6.5.4. Ice_situation_code (the ice situation code should always be provided to allow presentation of ice situation on a map using ‘traffic light’ colours).

6.6. The ICEM can be published. Ice messages will be valid automatically until the next day after publication or until as defined in national procedures.

7.    WERM basic considerations

Taking into account the abundance of available Web Services and apps for weather forecasts and weather warnings WERM should only be used for weather information of specific importance for navigation which is not covered by general weather information services.

Weather related messages shall, as a general rule, be generated automatically. Where this is not possible the manual generation of WERM shall follow the processes set out for automatically generated WERM as closely as possible (see NtS Encoding Guide for application developers).

8.    Rules for certain elements

8.1.    Rules for the element ‘name’ related to objects

Object names are usually prefilled by the NtS editor tool based on RIS Index reference data. Names shall be entered in local language, thus also e.g. diacritics or Cyrillic letters may be used. (e.g. Baarlerbrücke, Volkeraksluis or Mannswörth).

Do not include information on characteristics of feature, the type of object shall not be repeated in the name unless additional information to the object type is given.

E.g.: The lock ‘Schleuse Freudenau’ shall only be named ‘Freudenau’, the object type ‘lock’ is added automatically based on the type_code.

E:g.: The object name for the Railway bridge in Krems (AT) is ‘Eisenbahnbrücke Krems’. The information ‘railway bridge’ is included in the object name as it adds information in addition to the type_code ‘bridge’.

E.g.: The object name for a bridge in Linz (AT) is ‘Nibelungenbrücke’. The word ‘brücke’ stays within the object name as it is part of the bridge name itself.

E.g.: The waterway gauge ‘Pegelstelle Wildungsmauer’ is named ‘Wildungsmauer’ as the information that this object is a gauge is already coded in the type_code.

If a waterway section is the borderline between two countries with different languages, the national object name can be provided in both languages (e.g. ‘Staatsgrenze AT-SK/Statna hranica AT-SK’).

8.2.    Rules for the element ‘name’ related to fairways

Fairway names are usually prefilled by the NtS editor tool based on RIS Index reference data. The field ‘name’ shall contain the local name of the respective fairway section (e.g. ‘Rhein’) Depending on national processes it may be possible to edit the fairway name to include commonly used local names or additions (e.g. ‘Rhein am Deutschen Eck’).

8.3.    Rules for the elements ‘value’ and ‘unit’ within limitations

Unless stated otherwise 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.




NOTICES TO SKIPPERS ENCODING GUIDE FOR APPLICATION DEVELOPERS

CONTENTS

1.

Background & Structure

1.1.

Purpose of NtS Encoding Guide

1.1.1.

NtS Encoding Guide for editors

1.1.2.

NtS Encoding Guide for application developers (this document)

2.

NtS messages and sections

3.

WRM basic considerations

3.1.

Filling of nts_number section in the WRM

3.2.

Filling of WRM including predictions

4.

ICEM processes

4.1.

New ICEM

4.2.

Update of an existing ICEM

5.

WERM basic considerations

5.1.

Filling of nts_number section in the WERM

5.2.

Filling of WERM ‘weather_category_code’

6.

FTM processes

6.1.

New FTM

6.2.

Update/withdrawal of an existing FTM

6.3.

Waterway and/or object related FTM

6.4.

Automatic ordering of limitation codes

6.5.

Handling of limitation period

7.

General implementation rules

7.1.

Filling of the ‘number_section’

7.2.

Filling of elements ‘from’, ‘originator’, ‘organisation’ and ‘source’

7.3.

Omission of elements

7.4.

Automatic filling of date_issue

7.5.

Handling of time zone information in NtS messages

7.6.

Handling of Seconds in NtS messages

7.7.

Format of decimals in NtS messages

7.8.

Units to be used in NtS messages

7.9.

Rules for the elements ‘name’, ‘position_code’ and ‘type_code’

7.10.

Rules for the element ‘fairway_name’

7.11.

Clarifications for translations in the spreadsheet ‘reference_code’

7.12.

Recommendation for the element ‘coordinate’

7.13.

Handling of target groups

7.14.

Display of valid messages at a given time

7.15.

Optional functions to increase user friendliness of NtS editor tools

8.

NtS XML Message Structure

9.

NtS Web Service

9.1.

Objective

9.2.

Basic Principles and constraints

9.2.1.

Web standards

9.2.2.

Interaction model and encoding method for NtS WS

9.3.

General specifications and recommendations

9.3.1.

Specification: Version information

9.3.2.

Specification: Structure of namespaces

9.3.3.

Recommendation: Use of namespaces

9.3.4.

Recommendation: Use of namespace prefixes

9.3.5.

Specification: Use of ISRS Location Codes

9.4.

NtS Message Service (implementation specification)

9.4.1.

Request

9.4.2.

Response

9.5.

Generation of services and clients

Glossary

1.    Background & Structure

Notices to Skippers (NtS) were being implemented in various European countries based on Commission Regulation 416/2007/EC of the European Parliament and of the Council concerning the technical specifications for Notices to Skippers as referred to in Article 5 of RIS directive 2005/44/EC. The NtS standard is in the continuous process of enhancement, a major step forward was the release of the NtS Web Service facilitating exchange of NtS messages between authorities as well as between authorities and NtS users as well as NtS XSD 4.0 streamlining the encoding of NtS messages.

1.1.    Purpose of NtS Encoding Guide

The NtS Encoding Guide explains the applicability of the four NtS message types as well as codes to be used in case of certain events. It provides NtS editors with NtS message filling instructions, thus allows nationally and internationally harmonised encoding of NtS messages.

Considering increased use of the NtS web service, NtS messages shall be further harmonised to ensure proper display of content on third party systems. Uniform encoding of messages is also a prerequisite for consideration of messages in voyage planning applications. The NtS Encoding Guide version 1.0 applies to NtS XSD 4.0 and the NtS Web Service WSDL 2.0.4.0.

1.1.1.    NtS Encoding Guide for editors

The NtS Encoding Guide for editors is intended for personnel editing (and publishing) NtS messages including step-by-step creation instructions for the proper message types as well as explanation of codes. The encoding guide for editors also includes relevant information for application developers.

1.1.2.    NtS Encoding Guide for application developers (this document)

The NtS Encoding Guide for developers includes guidelines for NtS application implementation explaining logic, processes and auto/default values.

2.    NtS messages and sections

An NtS message consists of the following:

 the identification section,

 section defining the applicable object(s) or fairway section(s) the message is related to,

 one or more of the following sections according to the message type:

 

 limitation(s) for the Fairway and traffic related message,

 measurement(s) for the Water level related message,

 ice condition(s) for the Ice related message,

 weather report(s) for the Weather related message.

Figure 2

Visualisation of the NtS message structure: mandatory element (1), mandatory element that may occur one or two times (1…2), mandatory element that has to occur two times (2), mandatory elements that may occur as often as necessary (1-n), optional element that may occur as often as necessary (0…n)

image

The identification section is mandatory and includes general information about the message originator, sender, date issue, country and original language and is provided together with one of the four different NtS message section types:

 Fairway and traffic related section: a ‘Fairway and Traffic related Message’ (FTM) is usually created by NtS editors following the NtS Encoding Guide for editors. It is related to stretches of waterways (defined by its begin and end ISRS Location Codes and/or objects on the waterway defined by their respective ISRS Location Code. [go to chapter 6]

 Water level related section: a ‘Water Related Message’ (WRM) facilitates provision of information on current and predicted water levels as well as other information. Usually WRM are created automatically (and periodically) based on sensor measurements or infrastructure status not requiring NtS editor interaction. The water related message section contains information for an object (e.g. gauge station) or a fairway section (e.g. least sounded depth for a stretch, applicable regime at a waterway section). The object is identified by its ISRS Location Code, the fairway section is defined by its begin- and end-ISRS Location Codes. [go to chapter 3]

 Ice related section: an ‘ICE Message’ (ICEM) contains information about the ice conditions for a fairway stretch defined by its begin- and end-ISRS Location Codes. [go to chapter 4]

 Weather related section: a ‘WEather Related Message’ (WERM) enables provision of information on current as well as forecasted weather situations on a waterway stretch defined by its begin- and end-ISRS Location Codes. [go to chapter 5]

In addition, the ISRS Location Code (International Ship Reporting Standard) is used to define the applicable object(s) or fairway section(s) the message is related to.

The ISRS location code is defined in point 4.3 of the Annex to this Regulation.

3.    WRM basic considerations

Water level information is very important for voyage planning as well as safety. At the moment there is no common standard of referencing water level information. The values of gauges are referring to different sea-levels or to special reference points. To provide a proper reference, the respective ‘reference_code’ shall always be provided together with the value. WRM may be used to provide the following information:

 Water level (including predictions),

 Least sounded depth (including predictions),

 Vertical clearance (including predictions),

 Discharge (including predictions),

 Barrage status,

 Regime.

Clarifications for translations in the spreadsheet ‘reference_code’ are provided in chapter 7.11.

Usually WRM are created and published automatically based on information received from sensor equipment or information received from infrastructure (e.g. predictions, barrage status). There may be different triggers for WRM publication, e.g. periodically or when certain values are reached.

3.1.    Filling of nts_number section in the WRM

In NtS XSD 4.0 the NtS number is optional within WRM messages. If it is provided every number has to be unique (Organisation/Year/Number/Serial) per message type and it is up to the organisation providing the WRM to ensure unique numbers (it is not required to have consecutive numbers).

3.2.    Filling of WRM including predictions

The date_start of validity_period has to be filled with present date (date_issue) and the date_end of validity_period has to be filled with the next day after date_issue.

To provide changes in e.g. water level in a user-friendly way the difference to a previous comparative measurement may be provided in the WRM difference section. Besides the change in the value (e.g. - 5 [cm]) also the time difference to the comparative measurement has to be provided.

In case of predictions the ‘measure_date’ is the date/time the prediction is valid for.

Water level predictions always include a factor of uncertainty. Usually models with different parameters (e.g. weather forecast) are calculated leading to different predicted water level values. To enable provision of a minimum and maximum predicted value e.g. visualisation of a water level prediction confidence interval, two additional optional data fields are included in the WRM ‘measure’ section.

An illustration of water level prediction confidence interval is given in the following figure:

Figure 3

Visualisation of water level prediction confidence interval: most probable value (black), confidence interval upper boarder (violet), confidence interval lower boarder (red), measured water level (blue)

(The x-axis shows the time; the y-axis shows the water level in cm)

image

Two elements are available in the NtS XSD:

<value_min> lowest value of confidence interval

<value_max> highest value of confidence interval

Besides predicted water levels the confidence interval may also be used to state the uncertainty of published least sounded depth and vertical clearance information.

The confidence interval value_min and value_max enable provision of WRM value confidence interval via standardised NtS WRM Message to use it in graphs. The raw data itself shall not be displayed to IWT users (e.g. in code format).

The measure_code ‘NOM’ must not be used. In case there is no measurement for a certain type of WRM the value elements have to be omitted if a message should be sent anyhow.

4.    ICEM processes

Ice Messages depend on local observation and assessment and will usually be generated manually (in case of automatic generation the rules for manual creation have to be followed, see NtS Encoding Guide for editors).

The ICEM is published for a certain fairway_section defined by its begin and end ISRS Location Codes and contains the ice_condition at a certain measurement date.

The validity of the ICEM starts at the date of publication (automatically set by the NtS application). In order to avoid ICEM being displayed to users that are not valid any more, the validity date_end has to be filled automatically by the NtS application with the day after publication (unless it is ensured by national processes that messages will get a validity date end as soon as the information included in the message is not up-to-date any more).

In the NtS Encoding Guide for editors it is described under which circumstances an NtS editor creates a new ICEM or updates an existing ICEM. The following processes apply:

4.1.    New ICEM

(1) NtS applications may offer NtS editors:

(a) to use existing notices as draft upon creation of new ICEM (e.g. if ice conditions are similar to the existing notice); and/or

(b) to use notice templates for certain situations.

(2) The content (e.g. time of measurement or respective ice conditions) has to be entered by the editor in line with chapter 6 of the NtS Encoding Guide for editors. The date and time of measurement could also be set by the application according to national definitions.

(3) When an NtS editor/publishers 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;

(iv) the ‘serial number’ 0 is assigned;

(c) ‘date_issue’ is automatically filled with the actual date/time of publish action;

(d) ‘validity_period’ — ‘date_start’ is automatically filled with the actual date of publication;

(e) ‘validity_period’ — ‘date_end’ is automatically filled with the next day after the date of publication (unless it is ensured by national processes that messages will get a validity date end as soon as the information included in the message is not up-to-date any more).

4.2.    Update of an existing ICEM

(1) The respective published message has to be selected to be updated in the ICEM editor tool. The original ICEM has to be copied or altered in the DB (depending on national processes). Expired ICEM (which passed the validity_date_end) cannot be updated any more, if this is the case NtS editors have to create a new ICEM.

(2) The content (e.g. time of measurement or respective ice conditions) has to be altered by the editor in line with chapter 6 of the NtS Encoding Guide for editors. The date and time of measurement could also be altered by the application according to national definitions.

(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) ‘validity_period’ — ‘date_start’ is automatically filled with the actual date of publication;

(e) ‘validity_period’ — ‘date_end’ is automatically filled with the next day after the date of publication (unless it is ensured by national processes that messages will get a validity date end as soon as the information included in the message is not up-to-date any more).

5.    WERM basic considerations

Usually WERM are created and published automatically based on information received from sensor equipment or information received from infrastructure. The date_start of validity_period has to be filled with present date (date_issue) and the date_end of validity_period has to be filled with the next day after date_issue.

The fairway section in WERM is indicated as a stretch between two points on the fairway, i.e. area of applicability of the weather station (gauge).

Date and time of measurement/forecast have to be provided even if it is not mandatory in WERM messages.

In case of forecasts the ‘measure date’ is the date/time the forecast is valid for.

5.1.    Filling of nts_number section in the WERM

In NtS XSD 4.0 the NtS number is optional within WERM messages. If it is provided every number has to be unique (Organisation/Year/Number/Serial) per message type and it is up to the organisation providing the WERM to ensure unique numbers (it is not required to have consecutive numbers).

5.2.    Filling of WERM ‘weather_category_code’

The wind speed in ‘weather_category_code’ (values 0 to 12) shall be provided in line with the Beaufort scale published by the World Meteorological Organization in its Manual on Marine Meteorological Services ‘WMO-No 558’.

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’:

 <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>

 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’:

 <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>

 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:

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.    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’ ( 4 ). 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

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

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

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

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

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

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

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:

1. NtS FTM (fairway and traffic related message)

2. NtS WRM (water related message)

3. NtS ICEM (ice message)

4. 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




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"

 

 

 

 

<RIS_Message>

Notice to Skippers

 

 

1s

<identification>

Identification section

M

1

1.1

<internal_id>xs:string (64)</internal_id>

Internal ID

C

 

1.2

<from>xs:string (64)</from>

Sender (System) of the message

M

 

1.3

<originator>xs:string (64)</originator>

Originator (initiator) of the information in this message

M

 

1.4

<country_code>nts:country_code_enum</country_code>

Country where message is valid

M

 

1.5

<language_code>nts:language_code_enum</language_code>

Original language used in the textual info. (contents)

M

 

1.6

<district>xs:string (64)</district>

District / Region within the specified country, where the message is applicable

C

 

1.7

<date_issue>xs:dateTime<date_issue>

Date and time of publication including time zone (yyyy-mm-ddThh:mm:ss+hh:mm)

M

 

1e

</identification>

 

 

 

 

 

 

 

 

2s

<ftm>

Fairway and traffic related section

C

1

2.1

<internal_id>xs:string (64)</internal_id>

Internal ID

C

 

2.2s

<nts_number>

NtS Number

M

 

2.2.1

<organisation>xs:string (64)</organisation

Name of the publishing organisation (NtS Provider)

M

 

2.2.2

<year>xs:gYear (1900-9999)</year>

Year of first issuing of the notice

M

 

2.2.3

<number>xs:integer (0-99999999)</number>

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

M

 

2.2.4

<serial_number>xs:integer (0-99)</serial_number>

Serial number of notice (replacements and withdrawals), original notice: 0

M

 

2.2e

</nts_number>

 

 

 

2.3s

<target_group>

Target group information

C

 

2.3.1

<target_group_code>nts:target_group_code_enum</target_group_code>

Target group (vessel type) for this message

M

5

2.3.2

<direction_code>nts:direction_code_enum</direction_code>

Upstream or downstream traffic, or both

M

5

2.3e

</target_group>

 

 

 

2.4

<subject_code>nts:subject_code_enum</subject_code>

Subject code

M

 

2.5s

<validity_period>

Overall period of validity

M

 

2.5.1

<date_start>xs:date</date_start>

Start date of validity period including time zone (yyyy-mm-dd+hh:mm)

M

 

2.5.2

<date_end>xs:date</date_end>

End date of validity period including time zone (yyyy-mm-dd+hh:mm)

C

 

2.5e

</validity_period>

 

 

 

2.6

<contents>xs:string (500)</contents>

Additional information in local language

C

 

2.7

<source>xs:string (64)</source>

Notice source (name of authority)

C

 

2.8

<reason_code>nts:reason_code_enum</reason_code>

Reason / justification of notice

C

 

2.9s

<communication>

Communication channel information

C

 

2.9.1

<reporting_code>nts:reporting_code_enum</reporting_code>

Reporting regime (information or duty to report)

M

5

2.9.2

<communication_code>nts:communication_code_enum</communication_code>

Communication code (telephone, VHF etc.)

M

5

2.9.3

<number>xs:string (128)</number>

Telephone, VHF number (including callsign), e-mail address, URL or teletext

C

 

2.9.4

<label>xs:string (256)</label>

Name of the attachment or additional information

C

 

2.9.5

<remark>xs:string (1024)</remark>

Additional remarks concerning the communication

C

 

2.9e

</communication>

 

 

 

2.10s

<fairway_section>

Fairway section, also available for objects (no 2.11)

C

2

2.10.1s

<geo_object>

Geo information of fairway

M

5

2.10.1.1

<id>nts:isrs_code_type</id>

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

<name>xs:string (256)</name>

Local name of the fairway section (f.e.: Rhine between bridge A and bridge B)

M

 

2.10.1.3

<type_code>nts:type_code_enum</type_code>

Type of geographical object (default=FWY)

M

 

2.10.1.4

<position_code>nts:position_code_enum</position_code>

Describes the position related to the fairway

C

 

2.10.1.5s

<coordinate>

Fairway section begin and end coordinates (2x)

C

7

2.10.1.5.1

<lat>xs:string (10-12)</lat>

[d]d mm.mmm[m] N

M

5

2.10.1.5.2

<long>xs:string (10-13)</long>

[d][d]d mm.mmm[m] E

M

5

2.10.1.5e

</coordinate>

 

 

 

2.10.1.6

<fairway_name>xs:string (256)</fairway_name>

Waterway name (usefull if no RIS Index is available).

C

 

2.10.1e

</geo_object>

 

 

 

2.10.2s

<limitation>

Fairway section limitations

C

 

2.10.2.1s

<limitation_period>

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

<date_start>xs:date</date_start>

Start date of limitation period (overall) INCLUDING time zone

format=yyyy-mm-dd+hh:mm

M

5

2.10.2.1.2

<date_end>xs:date</date_end>

End date of limitation period INCLUDING time zone

format=yyyy-mm-dd+hh:mm

C

 

2.10.2.1.3

<time_start>xs:time</time_start>

Start time of limitation period WITHOUT time zone

format=hh:mm:ss [whereas ss=00]

C

 

2.10.2.1.4

<time_end>xs:time</time_end>

End time of limitation period WITHOUT time zone

format=hh:mm:ss [whereas ss=00]

C

 

2.10.2.1.5

<interval_code>nts:interval_code_enum</interval_code>

Interval for limitation (mandatory M(5) but is set to C to be compatible with former XSD version)

C

 

2.10.2.1e

</limitation_period>

 

 

 

2.10.2.2

<limitation_code>nts:limitation_code_enum</limitation_code>

Kind of limitation

M

5

2.10.2.3

<position_code>nts:position_code_enum</position_code>

Describes the position of the limitation related to the fairway

C

 

2.10.2.4

<value>xs:float</value>

Value of limitation (i.e. max draught)

C

 

2.10.2.5

<unit>nts:unit_enum</unit>

Unit of the value of the limitation

C

 

2.10.2.6

<reference_code>nts:reference_code_enum</reference_code>

Value reference

C

 

2.10.2.7

<indication_code>nts:indication_code_enum</indication_code>

Minimum or maximum or reduced by

C

 

2.10.2.8s

<target_group>

Target group information

C

 

2.10.2.8.1

<target_group_code>nts:target_group_code_enum</target_group_code>

Target group (vessel type) for this limitation

M

5

2.10.2.8.2

<direction_code>nts:direction_code_enum</direction_code>

Upstream or downstream traffic, or both

M

5

2.10.2.8e

</target_group>

 

 

 

2.10.2e

</limitation>

 

 

 

2.10e

</fairway_section>

 

 

 

2.11s

<object>

Object section

C

2

2.11.1s

<geo_object>

Geo Information of object

M

5

2.11.1.1

<id>nts:isrs_code_type</id>

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

<name>xs:string (256)</name>

Local name of the aggregated object

M

 

2.11.1.3

<type_code>nts:type_code_enum</type_code>

Type of geographical object

M

 

2.11.1.4

<position_code>nts:position_code_enum</position_code>

Describes the position related to the object

C

 

2.11.1.5s

<coordinate>

Object coordinates (1x)

C

8

2.11.1.5.1

<lat>xs:string (10-12)</lat>

[d]d mm.mmm[m] N

M

5

2.11.1.5.2

<long>xs:string (10-13)</long>

[d][d]d mm.mmm[m] E

M

5

2.11.1.5e

</coordinate>

 

 

 

2.11.1.6

<fairway_name>xs:string (256)</fairway_name>

Waterway name (usefull if no RIS Index is available).

C

 

2.11.1e

</geo_object>

 

 

 

2.11.2s

<limitation>

Object limitation section

C

 

2.11.2.1s

<limitation_period>

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

<date_start>xs:date</date_start>

Start date of limitation period (overall) INCLUDING time zone

format=yyyy-mm-dd+hh:mm

M

5

2.11.2.1.2

<date_end>xs:date</date_end>

End date of limitation period INCLUDING time zone

format=yyyy-mm-dd+hh:mm

C

 

2.11.2.1.3

<time_start>xs:time</time_start>

Start time of limitation period WITHOUT time zone

format=hh:mm:ss [whereas ss=00]

C

 

2.11.2.1.4

<time_end>xs:time</time_end>

End time of limitation period WITHOUT time zone

format=hh:mm:ss [whereas ss=00]

C

 

2.11.2.1.5

<interval_code>nts:interval_code_enum</interval_code>

Interval for limitation (mandatory M(5) but is set to C to be compatible with former XSD version)

C

 

2.11.2.1e

</limitation_period>

 

 

 

2.11.2.2

<limitation_code>nts:limitation_code_enum</limitation_code>

Kind of limitation

M

5

2.11.2.3

<position_code>nts:position_code_enum</position_code>

Describes the position of the limitation related to the fairway

C

 

2.11.2.4

<value>xs:float</value>

Value of limitation (i.e. max draught)

C

 

2.11.2.5

<unit>nts:unit_enum</unit>

Unit of the value of the limitation

C

 

2.11.2.6

<reference_code>nts:reference_code_enum</reference_code>

Value reference

C

 

2.11.2.7

<indication_code>nts:indication_code_enum</indication_code>

Minimum or maximum or reduced by

C

 

2.11.2.8s

<target_group>

Target group information

C

 

2.11.2.8.1

<target_group_code>nts:target_group_code_enum</target_group_code>

Target group (vessel type) for this limitation

M

5

2.11.2.8.2

<direction_code>nts:direction_code_enum</direction_code>

Upstream or downstream traffic, or both

M

5

2.11.2.8e

</target_group>

 

 

 

2.11.2e

</limitation>

 

 

 

2.11e

</object>

 

 

 

2e

</ftm>

 

 

 

 

 

 

 

 

3s

<wrm>

Water related section

C

1

3.1

<internal_id>xs:string (64)</internal_id>

Internal ID

C

 

3.2s

<nts_number>

NtS Number

C

 

3.2.1

<organisation>xs:string (64)</organisation

Name of the publishing organisation (NtS Provider)

M

5

3.2.2

<year>xs:gYear (1900-9999)</year>

Current year of the notice

M

5

3.2.3

<number>xs:integer (0-99999999)</number>

Number of the notice

(see Developers Guide for WRM-Message Number generation)

M

5

3.2.4

<serial_number>xs:integer (0-99)</serial_number>

Serial number of the notice

(see Developers Guide for WRM-Message Serial Number generation)

M

5

3.2e

</nts_number>

 

 

 

3.3s

<validity_period>

Overall period of validity

M

 

3.3.1

<date_start>xs:date</date_start>

Start date of validity period including time zone (yyyy-mm-dd+hh:mm)

M

 

3.3.2

<date_end>xs:date</date_end>

End date of validity period including time zone (yyyy-mm-dd+hh:mm)

C

 

3.3e

</validity_period>

 

 

 

3.4s

<geo_object>

Geo Information of measurement location

M

5

3.4.1

<id>nts:isrs_code_type</id>

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

<name>xs:string (256)</name>

Local name of the object/fairway

M

 

3.4.3

<type_code>nts:type_code_enum</type_code>

Type of geographical object/fairway

M

 

3.4.4

<position_code>nts:position_code_enum</position_code>

Describes the position related to the object/fairway

C

 

3.4.5s

<coordinate>

Object/Fairway coordinates (1x or 2x)

C

9

3.4.5.1

<lat>xs:string (10-12)</lat>

[d]d mm.mmm[m] N

M

5

3.4.5.2

<long>xs:string (10-13)</long>

[d][d]d mm.mmm[m] E

M

5

3.3.5e

</coordinate>

 

 

 

3.3.6

<fairway_name>xs:string (256)</fairway_name>

Waterway name (usefull if no RIS Index is available).

C

 

3.4e

</geo_object>

 

 

 

3.5

<reference_code>nts:reference_code_enum</reference_code>

Value reference (measurement reference)

C

6

3.6s

<measure>

Measurements (normal or predicted values)

M

5

3.6.1

<predicted>xs:boolean</predicted>

Predicted measurement (1 or true) or real measurement (0 or false)

M

 

3.6.2

<measure_code>nts:measure_code_enum</measure_code>

Kind of water related information

M

 

3.6.3

<value>xs:float</value>

Measured or predicted value

C

10

3.6.4

<value_min>xs:float</value_min>

Lowest value of confidence interval

C

 

3.6.5

<value_max>xs:float</value_max>

Highest value of confidence interval

C

 

3.6.6

<unit>nts:unit_enum</unit>

Unit of the water related value

C

 

3.6.7

<barrage_code>nts:barrage_code_enum</barrage_code>

Barrage status

C

11

3.6.8

<regime_code>nts:regime_code_enum</regime_code>

Regime applicable

C

12

3.6.9

<measuredate>xs:dateTime</measuredate>

Date and Time of measurement or predicted value including time zone

Format=yyyy-mm-ddThh:mm:ss+hh:mm

M

 

3.6.10s

<difference>

Difference with comparative value

C

 

3.6.10.1

<value_difference>xs:float</value_difference>

Difference with comparative value

M

5

3.6.10.2

<time_difference>xs:duration</time_difference>

Time difference to measuredate of comparative value

M

5

3.6.10e

</difference>

 

 

 

3.6e

</measure>

 

 

 

3e

</wrm>

 

 

 

 

 

 

 

 

4s

<icem>

Ice related section

C

1

4.1

<internal_id>xs:string (64)</internal_id>

Internal ID

C

 

4.2s

<nts_number>

NtS Number

M

 

4.2.1

<organisation>xs:string (64)</organisation

Name of the publishing organisation (NtS Provider)

M

 

4.2.2

<year>xs:gYear (1900-9999)</year>

Current year of the notice

M

 

4.2.3

<number>xs:integer (0-99999999)</number>

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

M

 

4.2.4

<serial_number>xs:integer (0-99)</serial_number>

Serial number of notice, original notice: 0

M

 

4.2e

</nts_number>

 

 

 

4.3s

<validity_period>

Overall period of validity

M

 

4.3.1

<date_start>xs:date</date_start>

Start date of validity period including time zone (yyyy-mm-dd+hh:mm)

M

 

4.3.2

<date_end>xs:date</date_end>

End date of validity period including time zone (yyyy-mm-dd+hh:mm)

C

 

4.3e

</validity_period>

 

 

 

4.4s

<fairway_section>

Fairway section — the limitation inside the fairway section cannot be used in the ICEM

M

5

4.4.1s

<geo_object>

Geo Information of fairway

M

5

4.4.1.1

<id>nts:isrs_code_type</id>

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

<name>xs:string (256)</name>

Local Name of the fairway section (f.e.: Rhine between bridge A and bridge B)

M

 

4.4.1.3

<type_code>nts:type_code_enum</type_code>

Type of geographical object (default=FWY)

M

 

4.4.1.4

<position_code>nts:position_code_enum</position_code>

Describes the position related to the fairway

C

 

4.4.1.5s

<coordinate>

Fairway section begin and end coordinates (2x)

C

7

4.4.1.5.1

<lat>xs:string (10-12)</lat>

[d]d mm.mmm[m] N

M

5

4.4.1.5.2

<long>xs:string (10-13)</long>

[d][d]d mm.mmm[m] E

M

5

4.4.1.5e

</coordinate>

 

 

 

4.4.1.6

<fairway_name>xs:string (256)</fairway_name>

Waterway name (usefull if no RIS Index is available).

C

 

4.4.1e

</geo_object>

 

 

 

4.4e

</fairway_section>

 

 

 

4.5s

<ice_condition>

Ice conditions

M

 

4.5.1

<measuredate>xs:dateTime</measuredate>

Date and Time of measurement or prediction including time zone

Format=yyyy-mm-ddThh:mm:ss+hh:mm

M

 

4.5.2

<ice_condition_code>nts:ice_condition_code_enum</ice_condition_code>

Condition code

C

4

4.5.3

<ice_accessibility_code>nts:ice_accessibility_code_enum</ice_accessibility_code>

Accessibility code

C

4

4.5.4

<ice_classification_code>nts:ice_classification_code_enum</ice_classification_code>

Classification code

C

4

4.5.5

<ice_situation_code>nts:ice_situation_code_enum</ice_situation_code>

Situation code

C

4

4.5e

</ice_condition>

 

 

 

4e

</icem>

 

 

 

 

 

 

 

 

5s

<werm>

Weather related section

C

1

5.1

<internal_id>xs:string (64)</internal_id>

Internal ID

C

 

5.2s

<nts_number>

NtS Number

C

 

5.2.1

<organisation>xs:string (64)</organisation

Name of the publishing organisation (NtS Provider)

M

5

5.2.2

<year>xs:gYear (1900-9999)</year>

Year of issuing of the notice

M

5

5.2.3

<number>xs:integer (0-99999999)</number>

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

M

5

5.2.4

<serial_number>xs:integer (0-99)</serial_number>

Serial number of notice, original notice: 0

M

5

5.2e

</nts_number>

 

 

 

5.3s

<validity_period>

Overall period of validity

M

13

5.3.1

<date_start>xs:date</date_start>

Start date of validity period including time zone (yyyy-mm-dd+hh:mm)

M

 

5.3.2

<date_end>xs:date</date_end>

End date of validity period including time zone (yyyy-mm-dd+hh:mm)

C

 

5.3e

</validity_period>

 

 

 

5.4s

<fairway_section>

Fairway section

M

 

5.4.1s

<geo_object>

Geo Information of fairway

M

 

5.4.1.1

<id>nts:isrs_code_type</id>

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

<name>xs:string (256)</name>

Local name of the fairway section (f.e.: Rhine between bridge A and bridge B)

M

 

5.4.1.3

<type_code>nts:type_code_enum</type_code>

Type of geographical object (default=FWY)

M

 

5.4.1.4

<position_code>nts:position_code_enum</position_code>

Describes the position related to the fairway

C

 

5.4.1.5s

<coordinate>

Fairway section begin and end coordinates (2x)

C

7

5.4.1.5.1

<lat>xs:string (10-12)</lat>

[d]d mm.mmm[m] N

M

5

5.4.1.5.2

<long>xs:string (10-13)</long>

[d][d]d mm.mmm[m] E

M

5

5.4.1.5e

</coordinate>

 

 

 

5.4.1.6

<fairway_name>xs:string (256)</fairway_name>

Waterway name (usefull if no RIS Index is available).

C

 

5.4.1e

</geo_object>

 

 

 

5.4e

</fairway_section>

 

 

 

5.5s

<weather_report>

Weather Report (1x or 2x)

M

 

5.5.1

<measuredate>xs:dateTime</measuredate>

Date and Time of measurement or predicted value including time zone

Format=yyyy-mm-ddThh:mm:ss+hh:mm

C

 

5.5.2

<forecast>xs:boolean</forecast>

Forecast (true or 1) OR Actual report (false or 0)

M

 

5.5.3

<weather_class_code>nts:weather_class_code_enum</weather_class_code>

Classification of weather report (0..Nx)

M

3

5.5.4s

<weather_item>

Weather items (0..Nx)

C

 

5.5.4.1

<weather_item_code>nts:weather_item_code_enum</weather_item_code>

Weather item type (Wind, Wave etc)

M

5

5.5.4.2

<value_min>xs:float</value_min>

Actual or Minimum value

M

5

5.5.4.3

<value_max>xs:float</value_max>

Maximum value

C

 

5.5.4.4

<value_gusts>xs:float</value_gusts>

Gusts value (Wind)

C

 

5.5.4.5

<unit>nts:unit_enum</unit>

Unit of the value

C

 

5.5.4.6

<weather_category_code>nts:weather_category_code_enum</weather_category_code>

Classification of wind report

C

 

5.5.4.7

<direction_code_min>nts:weather_direction_code_enum</direction_code_min>

Direction of wind or wave

C

 

5.5.4.8

<direction_code_max>nts:weather_direction_code_enum</direction_code_max>

Direction of wind or wave

C

 

5.5.4e

</weather_item>

 

 

 

5.5e

</weather_report>

 

 

 

5e

</werm>

 

 

 

Legend for Occurrence (Occ.):

Mandatory (M)

Conditional (C)

Rules applicable to table "NtS XSD V.4.0.4.0":



1.

In one <RIS Message> at least two sections have to be filled in:

— the <identification> section (1),

— one of the following sections:

— 

— <ftm> (fairway and traffic related messages) (2),

— <wrm> (water related message) (3),

— <icem> (ice message) (4),

— <werm> (weather related message) (5).

2.

At least one of the Group 2.10 (<fairway section>) or Group 2.11 (<object>) has to be given within <ftm>.

3.

A combinations of <weather_class_code> tags (5.5.3) in section <weather_report> can be given.

4.

In group 4.5 (<ice condition>) 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 <reference_code> is only mandatory for "WAL" (water level) in <wrm> (3.5).

7.

A <geo_object> in <fairway section> (<ftm> 2.10.1 , <icem> 4.4.1, <werm> 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 <geo_object> in <object> section (<ftm> 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 <geo_object> in <wrm> has 2 ISRS Location Codes and 2 sets of coordinates in case the <type_code> (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 <value> (3.6.3) or <value_min> (3.6.4) and <value_max> (3.6.5) is/are mandatory if <measure_code> (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 <barrage_code> (3.6.7) is mandatory if <measure code> (3.6.2) is "BAR".

12.

Element <regime_code> (3.6.8) is mandatory if <measure code> (3.6.2) is "REG".

13.

Predictions for more than one <validity_period> (5.3) require individual <werm> messages.

14.

In case of <icem> (4.4.2) and <werm> a <limitation> section is not applicable. Limitations shall be provided via FTM notices.

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

<xs:schema xmlns:nts="http://www.ris.eu/nts/4.0.4.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace=">http://www.ris.eu/nts/4.0.4.0" elementFormDefault="qualified" attributeFormDefault="unqualified" version="4.0.4.0">

<!--

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

= definition of main element RIS_Message =

= and corresponding type RIS_Message_Type =

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

-->

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

<xs:complexType name="RIS_Message_Type">

<xs:sequence>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

<xs:choice>

<xs:annotation>

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

</xs:annotation>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

</xs:choice>

</xs:sequence>

</xs:complexType>

<!--

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

= definition of identification_type, =

= used in definition of RIS_Message_Type =

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

-->

<xs:complexType name="identification_type">

<xs:sequence>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

<xs:element name="from">

<xs:annotation>

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

</xs:annotation>

<xs:simpleType>

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

<xs:maxLength value="64"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="originator">

<xs:annotation>

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

</xs:annotation>

<xs:simpleType>

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

<xs:maxLength value="64"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

<xs:simpleType>

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

<xs:maxLength value="64"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<!--

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

= types used in definition of identification_type =

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

-->

<xs:simpleType name="country_code_enum">

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

<xs:maxLength value="2"/>

<xs:enumeration value="AT"/>

<xs:enumeration value="BE"/>

<xs:enumeration value="BG"/>

<xs:enumeration value="CH"/>

<xs:enumeration value="CY"/>

<xs:enumeration value="CZ"/>

<xs:enumeration value="DE"/>

<xs:enumeration value="DK"/>

<xs:enumeration value="EE"/>

<xs:enumeration value="ES"/>

<xs:enumeration value="FI"/>

<xs:enumeration value="FR"/>

<xs:enumeration value="GB"/>

<xs:enumeration value="GR"/>

<xs:enumeration value="HR"/>

<xs:enumeration value="HU"/>

<xs:enumeration value="IE"/>

<xs:enumeration value="IT"/>

<xs:enumeration value="LT"/>

<xs:enumeration value="LU"/>

<xs:enumeration value="LV"/>

<xs:enumeration value="MD"/>

<xs:enumeration value="ME"/>

<xs:enumeration value="MT"/>

<xs:enumeration value="NL"/>

<xs:enumeration value="PL"/>

<xs:enumeration value="PT"/>

<xs:enumeration value="RO"/>

<xs:enumeration value="RS"/>

<xs:enumeration value="SE"/>

<xs:enumeration value="SI"/>

<xs:enumeration value="SK"/>

<xs:enumeration value="RU"/>

<xs:enumeration value="UA"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="language_code_enum">

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

<xs:maxLength value="2"/>

<xs:enumeration value="DE"/>

<xs:enumeration value="EN"/>

<xs:enumeration value="FR"/>

<xs:enumeration value="NL"/>

<xs:enumeration value="SK"/>

<xs:enumeration value="HU"/>

<xs:enumeration value="HR"/>

<xs:enumeration value="SR"/>

<xs:enumeration value="BG"/>

<xs:enumeration value="RO"/>

<xs:enumeration value="RU"/>

<xs:enumeration value="CS"/>

<xs:enumeration value="PL"/>

<xs:enumeration value="PT"/>

<xs:enumeration value="ES"/>

<xs:enumeration value="SV"/>

<xs:enumeration value="FI"/>

<xs:enumeration value="DA"/>

<xs:enumeration value="ET"/>

<xs:enumeration value="LV"/>

<xs:enumeration value="LT"/>

<xs:enumeration value="IT"/>

<xs:enumeration value="MT"/>

<xs:enumeration value="EL"/>

<xs:enumeration value="SL"/>

</xs:restriction>

</xs:simpleType>

<!--

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

= definition of ftm_type, =

= used in definition of RIS_Message_Type =

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

-->

<xs:complexType name="ftm_type">

<xs:sequence>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

<xs:simpleType>

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

<xs:maxLength value="500"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

<xs:simpleType>

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

<xs:maxLength value="64"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

<xs:choice maxOccurs="unbounded">

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

</xs:choice>

</xs:sequence>

</xs:complexType>

<!--

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

= types used in definition of ftm_type =

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

-->

<xs:simpleType name="subject_code_enum">

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

<xs:minLength value="3"/>

<xs:maxLength value="6"/>

<xs:enumeration value="ANNOUN"/>

<xs:enumeration value="WARNIN"/>

<xs:enumeration value="CANCEL"/>

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

<xs:enumeration value="INFSER"/>

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

<xs:enumeration value="OBSTRU"/>

<xs:enumeration value="PAROBS"/>

<xs:enumeration value="DELAY"/>

<xs:enumeration value="VESLEN"/>

<xs:enumeration value="VESHEI"/>

<xs:enumeration value="VESBRE"/>

<xs:enumeration value="VESDRA"/>

<xs:enumeration value="AVALEN"/>

<xs:enumeration value="CLEHEI"/>

<xs:enumeration value="CLEWID"/>

<xs:enumeration value="AVADEP"/>

<xs:enumeration value="NOMOOR"/>

<xs:enumeration value="SERVIC"/>

<xs:enumeration value="NOSERV"/>

<xs:enumeration value="SPEED"/>

<xs:enumeration value="WAVWAS"/>

<xs:enumeration value="PASSIN"/>

<xs:enumeration value="ANCHOR"/>

<xs:enumeration value="OVRTAK"/>

<xs:enumeration value="MINPWR"/>

<xs:enumeration value="DREDGE"/>

<xs:enumeration value="WORK"/>

<xs:enumeration value="EVENT"/>

<xs:enumeration value="CHGMAR"/>

<xs:enumeration value="CHGSER"/>

<xs:enumeration value="SPCMAR"/>

<xs:enumeration value="EXERC"/>

<xs:enumeration value="LEADEP"/>

<xs:enumeration value="LEVDEC"/>

<xs:enumeration value="LEVRIS"/>

<xs:enumeration value="LIMITA"/>

<xs:enumeration value="MISECH"/>

<xs:enumeration value="ECDISU"/>

<xs:enumeration value="NEWOBJ"/>

<xs:enumeration value="CHWWY"/>

<xs:enumeration value="CONWWY"/>

<xs:enumeration value="DIVER"/>

<xs:enumeration value="SPECTR"/>

<xs:enumeration value="LOCRUL"/>

<xs:enumeration value="VHFCOV"/>

<xs:enumeration value="HIGVOL"/>

<xs:enumeration value="TURNIN"/>

<xs:enumeration value="CONBRE"/>

<xs:enumeration value="CONLEN"/>

<xs:enumeration value="REMOBJ"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="reason_code_enum">

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

<xs:minLength value="3"/>

<xs:maxLength value="6"/>

<xs:enumeration value="EVENT"/>

<xs:enumeration value="WORK"/>

<xs:enumeration value="DREDGE"/>

<xs:enumeration value="EXERC"/>

<xs:enumeration value="HIGWAT"/>

<xs:enumeration value="HIWAI"/>

<xs:enumeration value="HIWAII"/>

<xs:enumeration value="LOWWAT"/>

<xs:enumeration value="SHALLO"/>

<xs:enumeration value="CALAMI"/>

<xs:enumeration value="LAUNCH"/>

<xs:enumeration value="DECLEV"/>

<xs:enumeration value="FLOMEA"/>

<xs:enumeration value="BLDWRK"/>

<xs:enumeration value="REPAIR"/>

<xs:enumeration value="INSPEC"/>

<xs:enumeration value="FIRWRK"/>

<xs:enumeration value="LIMITA"/>

<xs:enumeration value="CHGFWY"/>

<xs:enumeration value="CONSTR"/>

<xs:enumeration value="DIVING"/>

<xs:enumeration value="SPECTR"/>

<xs:enumeration value="EXT"/>

<xs:enumeration value="MIN"/>

<xs:enumeration value="SOUND"/>

<xs:enumeration value="OTHER"/>

<xs:enumeration value="STRIKE"/>

<xs:enumeration value="FLOMAT"/>

<xs:enumeration value="EXPLOS"/>

<xs:enumeration value="ICE"/>

<xs:enumeration value="OBSTAC"/>

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

<xs:enumeration value="CHGMAR"/>

<xs:enumeration value="DAMMAR"/>

<xs:enumeration value="FALMAT"/>

<xs:enumeration value="MISECH"/>

<xs:enumeration value="HEARIS"/>

<xs:enumeration value="HIGVOL"/>

<xs:enumeration value="ECDISU"/>

<xs:enumeration value="LOCRUL"/>

<xs:enumeration value="NEWOBJ"/>

<xs:enumeration value="OBUNWA"/>

<xs:enumeration value="VHFCOV"/>

<xs:enumeration value="REMOBJ"/>

<xs:enumeration value="LEVRIS"/>

<xs:enumeration value="SPCMAR"/>

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

<xs:enumeration value="WERMCO"/>

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

<xs:enumeration value="INFSER"/>

</xs:restriction>

</xs:simpleType>

<xs:complexType name="communication_type">

<xs:sequence>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

<xs:simpleType>

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

<xs:maxLength value="128"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

<xs:simpleType>

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

<xs:maxLength value="256"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

<xs:simpleType>

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

<xs:maxLength value="1024"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:simpleType name="reporting_code_enum">

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

<xs:maxLength value="3"/>

<xs:enumeration value="INF"/>

<xs:enumeration value="ADD"/>

<xs:enumeration value="REG"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="communication_code_enum">

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

<xs:maxLength value="3"/>

<xs:enumeration value="TE"/>

<xs:enumeration value="AP"/>

<xs:enumeration value="EM"/>

<xs:enumeration value="AH"/>

<xs:enumeration value="TT"/>

<xs:enumeration value="FX"/>

<xs:enumeration value="LS"/>

<xs:enumeration value="FS"/>

<xs:enumeration value="SO"/>

<xs:enumeration value="EI"/>

</xs:restriction>

</xs:simpleType>

<xs:complexType name="object_type">

<xs:sequence>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<!--

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

= definition of wrm_type, =

= used in definition of RIS_Message_Type =

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

-->

<xs:complexType name="wrm_type">

<xs:sequence>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<!--

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

= types used in definition of wrm_type =

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

-->

<xs:complexType name="measure_type">

<xs:sequence>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:simpleType name="measure_code_enum">

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

<xs:maxLength value="3"/>

<xs:enumeration value="DIS"/>

<xs:enumeration value="REG"/>

<xs:enumeration value="BAR"/>

<xs:enumeration value="VER"/>

<xs:enumeration value="LSD"/>

<xs:enumeration value="WAL"/>

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

<xs:enumeration value="NOM"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="barrage_code_enum">

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

<xs:maxLength value="3"/>

<xs:enumeration value="CLD"/>

<xs:enumeration value="OPG"/>

<xs:enumeration value="CLG"/>

<xs:enumeration value="OPD"/>

<xs:enumeration value="OPN"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="regime_code_enum">

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

<xs:maxLength value="2"/>

<xs:enumeration value="NO"/>

<xs:enumeration value="HI"/>

<xs:enumeration value="II"/>

<xs:enumeration value="I"/>

<xs:enumeration value="NN"/>

<xs:enumeration value="LO"/>

</xs:restriction>

</xs:simpleType>

<xs:complexType name="difference_type">

<xs:sequence>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<!--

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

= definition of icem_type, =

= used in definition of RIS_Message_Type =

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

-->

<xs:complexType name="icem_type">

<xs:sequence>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<!--

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

= types used in definition of icem_type =

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

-->

<xs:complexType name="ice_condition_type">

<xs:sequence>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:simpleType name="ice_condition_code_enum">

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

<xs:maxLength value="1"/>

<xs:enumeration value="A"/>

<xs:enumeration value="B"/>

<xs:enumeration value="C"/>

<xs:enumeration value="D"/>

<xs:enumeration value="E"/>

<xs:enumeration value="F"/>

<xs:enumeration value="G"/>

<xs:enumeration value="H"/>

<xs:enumeration value="K"/>

<xs:enumeration value="L"/>

<xs:enumeration value="M"/>

<xs:enumeration value="P"/>

<xs:enumeration value="R"/>

<xs:enumeration value="S"/>

<xs:enumeration value="U"/>

<xs:enumeration value="O"/>

<xs:enumeration value="V"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="ice_accessibility_code_enum">

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

<xs:maxLength value="1"/>

<xs:enumeration value="A"/>

<xs:enumeration value="B"/>

<xs:enumeration value="F"/>

<xs:enumeration value="L"/>

<xs:enumeration value="C"/>

<xs:enumeration value="D"/>

<xs:enumeration value="E"/>

<xs:enumeration value="G"/>

<xs:enumeration value="H"/>

<xs:enumeration value="M"/>

<xs:enumeration value="K"/>

<xs:enumeration value="T"/>

<xs:enumeration value="P"/>

<xs:enumeration value="V"/>

<xs:enumeration value="X"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="ice_classification_code_enum">

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

<xs:maxLength value="1"/>

<xs:enumeration value="A"/>

<xs:enumeration value="B"/>

<xs:enumeration value="C"/>

<xs:enumeration value="D"/>

<xs:enumeration value="E"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="ice_situation_code_enum">

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

<xs:maxLength value="3"/>

<xs:enumeration value="NOL"/>

<xs:enumeration value="LIM"/>

<xs:enumeration value="NON"/>

</xs:restriction>

</xs:simpleType>

<!--

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

= definition of werm_type, =

= used in definition of RIS_Message_Type =

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

-->

<xs:complexType name="werm_type">

<xs:sequence>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<!--

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

= types used in definition of werm_type =

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

-->

<xs:complexType name="fairway_section_werm_type">

<xs:sequence>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:complexType name="weather_report_type">

<xs:sequence>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:simpleType name="weather_class_code_enum">

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

<xs:maxLength value="6"/>

<xs:enumeration value="CLR"/>

<xs:enumeration value="CLDY"/>

<xs:enumeration value="OCST"/>

<xs:enumeration value="DZZL"/>

<xs:enumeration value="RAIN"/>

<xs:enumeration value="LRAIN"/>

<xs:enumeration value="ORAIN"/>

<xs:enumeration value="HRAIN"/>

<xs:enumeration value="SLEET"/>

<xs:enumeration value="SNOW"/>

<xs:enumeration value="SNFALL"/>

<xs:enumeration value="HAIL"/>

<xs:enumeration value="SHWRS"/>

<xs:enumeration value="THSTRM"/>

<xs:enumeration value="HAZY"/>

<xs:enumeration value="FOG"/>

<xs:enumeration value="FOGPAT"/>

<xs:enumeration value="GALE"/>

<xs:enumeration value="STRM"/>

<xs:enumeration value="HURRC"/>

<xs:enumeration value="FZRA"/>

</xs:restriction>

</xs:simpleType>

<xs:complexType name="weather_item_type">

<xs:sequence>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:simpleType name="weather_item_code_enum">

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

<xs:maxLength value="2"/>

<xs:enumeration value="WI"/>

<xs:enumeration value="WA"/>

<xs:enumeration value="FG"/>

<xs:enumeration value="RN"/>

<xs:enumeration value="SN"/>

<xs:enumeration value="AT"/>

<xs:enumeration value="WT"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="weather_category_code_enum">

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

<xs:maxLength value="2"/>

<xs:enumeration value="0"/>

<xs:enumeration value="1"/>

<xs:enumeration value="2"/>

<xs:enumeration value="3"/>

<xs:enumeration value="4"/>

<xs:enumeration value="5"/>

<xs:enumeration value="6"/>

<xs:enumeration value="7"/>

<xs:enumeration value="8"/>

<xs:enumeration value="9"/>

<xs:enumeration value="10"/>

<xs:enumeration value="11"/>

<xs:enumeration value="12"/>

<xs:enumeration value="13"/>

<xs:enumeration value="14"/>

<xs:enumeration value="15"/>

<xs:enumeration value="16"/>

<xs:enumeration value="17"/>

<xs:enumeration value="18"/>

<xs:enumeration value="19"/>

<xs:enumeration value="20"/>

<xs:enumeration value="21"/>

<xs:enumeration value="22"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="weather_direction_code_enum">

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

<xs:maxLength value="3"/>

<xs:enumeration value="N"/>

<xs:enumeration value="NE"/>

<xs:enumeration value="E"/>

<xs:enumeration value="SE"/>

<xs:enumeration value="S"/>

<xs:enumeration value="SW"/>

<xs:enumeration value="W"/>

<xs:enumeration value="NW"/>

<xs:enumeration value="WRB"/>

</xs:restriction>

</xs:simpleType>

<!--

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

= types used in several definitions =

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

-->

<xs:simpleType name="internal_id_type">

<xs:annotation>

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

</xs:annotation>

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

<xs:maxLength value="64"/>

</xs:restriction>

</xs:simpleType>

<xs:complexType name="nts_number_type">

<xs:sequence>

<xs:element name="organisation">

<xs:annotation>

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

</xs:annotation>

<xs:simpleType>

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

<xs:maxLength value="64"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="year">

<xs:annotation>

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

</xs:annotation>

<xs:simpleType>

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

<xs:minInclusive value="1900"/>

<xs:maxInclusive value="9999"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="number">

<xs:annotation>

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

</xs:annotation>

<xs:simpleType>

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

<xs:minInclusive value="00000000"/>

<xs:maxInclusive value="99999999"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="serial_number">

<xs:annotation>

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

</xs:annotation>

<xs:simpleType>

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

<xs:minInclusive value="00"/>

<xs:maxInclusive value="99"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:complexType name="validity_period_type">

<xs:sequence>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:complexType name="fairway_section_type">

<xs:sequence>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:complexType name="geo_object_type">

<xs:sequence>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

<xs:element name="name">

<xs:annotation>

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

</xs:annotation>

<xs:simpleType>

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

<xs:maxLength value="256"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

<xs:simpleType>

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

<xs:maxLength value="256"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:simpleType name="isrs_code_type">

<xs:annotation>

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

</xs:annotation>

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

<xs:length value="20"/>

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

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="type_code_enum">

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

<xs:maxLength value="3"/>

<xs:enumeration value="RIV"/>

<xs:enumeration value="CAN"/>

<xs:enumeration value="LAK"/>

<xs:enumeration value="FWY"/>

<xs:enumeration value="LCK"/>

<xs:enumeration value="BRI"/>

<xs:enumeration value="RMP"/>

<xs:enumeration value="BAR"/>

<xs:enumeration value="BNK"/>

<xs:enumeration value="GAU"/>

<xs:enumeration value="BUO"/>

<xs:enumeration value="BEA"/>

<xs:enumeration value="ANC"/>

<xs:enumeration value="BER"/>

<xs:enumeration value="MOO"/>

<xs:enumeration value="TER"/>

<xs:enumeration value="HAR"/>

<xs:enumeration value="FDO"/>

<xs:enumeration value="CAB"/>

<xs:enumeration value="FER"/>

<xs:enumeration value="PIP"/>

<xs:enumeration value="PPO"/>

<xs:enumeration value="HFA"/>

<xs:enumeration value="HMO"/>

<xs:enumeration value="SHY"/>

<xs:enumeration value="REF"/>

<xs:enumeration value="MAR"/>

<xs:enumeration value="LIG"/>

<xs:enumeration value="SIG"/>

<xs:enumeration value="TUR"/>

<xs:enumeration value="CBR"/>

<xs:enumeration value="TUN"/>

<xs:enumeration value="BCO"/>

<xs:enumeration value="REP"/>

<xs:enumeration value="FLO"/>

<xs:enumeration value="SLI"/>

<xs:enumeration value="DUK"/>

<xs:enumeration value="VTC"/>

<xs:enumeration value="RES"/>

<xs:enumeration value="LKB"/>

<xs:enumeration value="BRO"/>

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

<xs:enumeration value="BNS"/>

</xs:restriction>

</xs:simpleType>

<xs:complexType name="coordinate_type">

<xs:sequence>

<xs:element name="lat">

<xs:simpleType>

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

<xs:minLength value="10"/>

<xs:maxLength value="12"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="long">

<xs:simpleType>

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

<xs:minLength value="10"/>

<xs:maxLength value="13"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:complexType name="limitation_type">

<xs:sequence>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:complexType name="limitation_period_type">

<xs:sequence>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:simpleType name="interval_code_enum">

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

<xs:maxLength value="3"/>

<xs:enumeration value="CON"/>

<xs:enumeration value="DAY"/>

<xs:enumeration value="WRK"/>

<xs:enumeration value="WKN"/>

<xs:enumeration value="SUN"/>

<xs:enumeration value="MON"/>

<xs:enumeration value="TUE"/>

<xs:enumeration value="WED"/>

<xs:enumeration value="THU"/>

<xs:enumeration value="FRI"/>

<xs:enumeration value="SAT"/>

<xs:enumeration value="DTI"/>

<xs:enumeration value="NTI"/>

<xs:enumeration value="RVI"/>

<xs:enumeration value="EXC"/>

<xs:enumeration value="WRD"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="limitation_code_enum">

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

<xs:maxLength value="6"/>

<xs:enumeration value="OBSTRU"/>

<xs:enumeration value="PAROBS"/>

<xs:enumeration value="DELAY"/>

<xs:enumeration value="VESLEN"/>

<xs:enumeration value="VESHEI"/>

<xs:enumeration value="VESBRE"/>

<xs:enumeration value="VESDRA"/>

<xs:enumeration value="AVALEN"/>

<xs:enumeration value="CLEHEI"/>

<xs:enumeration value="CLEWID"/>

<xs:enumeration value="AVADEP"/>

<xs:enumeration value="NOMOOR"/>

<xs:enumeration value="SERVIC"/>

<xs:enumeration value="NOSERV"/>

<xs:enumeration value="SPEED"/>

<xs:enumeration value="WAVWAS"/>

<xs:enumeration value="PASSIN"/>

<xs:enumeration value="ANCHOR"/>

<xs:enumeration value="OVRTAK"/>

<xs:enumeration value="MINPWR"/>

<xs:enumeration value="ALTER"/>

<xs:enumeration value="CAUTIO"/>

<xs:enumeration value="NOLIM"/>

<xs:enumeration value="TURNIN"/>

<xs:enumeration value="NOSHORE"/>

<xs:enumeration value="CONBRE"/>

<xs:enumeration value="CONLEN"/>

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

<xs:enumeration value="LEADEP"/>

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

<xs:enumeration value="NOBERT"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="position_code_enum">

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

<xs:maxLength value="2"/>

<xs:enumeration value="AL"/>

<xs:enumeration value="LE"/>

<xs:enumeration value="MI"/>

<xs:enumeration value="RI"/>

<xs:enumeration value="LB"/>

<xs:enumeration value="RB"/>

<xs:enumeration value="N"/>

<xs:enumeration value="NE"/>

<xs:enumeration value="E"/>

<xs:enumeration value="SE"/>

<xs:enumeration value="S"/>

<xs:enumeration value="SW"/>

<xs:enumeration value="W"/>

<xs:enumeration value="NW"/>

<xs:enumeration value="BI"/>

<xs:enumeration value="SM"/>

<xs:enumeration value="OL"/>

<xs:enumeration value="EW"/>

<xs:enumeration value="MP"/>

<xs:enumeration value="FP"/>

<xs:enumeration value="VA"/>

<xs:enumeration value="RY"/>

<xs:enumeration value="GY"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="reference_code_enum">

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

<xs:maxLength value="4"/>

<xs:enumeration value="NAP"/>

<xs:enumeration value="KP"/>

<xs:enumeration value="FZP"/>

<xs:enumeration value="ADR"/>

<xs:enumeration value="TAW"/>

<xs:enumeration value="PUL"/>

<xs:enumeration value="NGM"/>

<xs:enumeration value="ETRS"/>

<xs:enumeration value="POT"/>

<xs:enumeration value="LDC"/>

<xs:enumeration value="HDC"/>

<xs:enumeration value="ZPG"/>

<xs:enumeration value="GLW"/>

<xs:enumeration value="HSW"/>

<xs:enumeration value="LNW"/>

<xs:enumeration value="HNW"/>

<xs:enumeration value="IGN"/>

<xs:enumeration value="WGS"/>

<xs:enumeration value="RN"/>

<xs:enumeration value="HBO"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="indication_code_enum">

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

<xs:maxLength value="3"/>

<xs:enumeration value="MAX"/>

<xs:enumeration value="MIN"/>

<xs:enumeration value="RED"/>

</xs:restriction>

</xs:simpleType>

<xs:complexType name="target_group_type">

<xs:sequence>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

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

<xs:annotation>

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

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:simpleType name="target_group_code_enum">

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

<xs:maxLength value="3"/>

<xs:enumeration value="ALL"/>

<xs:enumeration value="CDG"/>

<xs:enumeration value="COM"/>

<xs:enumeration value="PAX"/>

<xs:enumeration value="PLE"/>

<xs:enumeration value="CNV"/>

<xs:enumeration value="PUS"/>

<xs:enumeration value="NNU"/>

<xs:enumeration value="LOA"/>

<xs:enumeration value="SMA"/>

<xs:enumeration value="CND"/>

<xs:enumeration value="WOC"/>

<xs:enumeration value="MOV"/>

<xs:enumeration value="NMV"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="direction_code_enum">

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

<xs:maxLength value="3"/>

<xs:enumeration value="ALL"/>

<xs:enumeration value="UPS"/>

<xs:enumeration value="DWN"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="unit_enum">

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

<xs:maxLength value="4"/>

<xs:enumeration value="cm"/>

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

<xs:enumeration value="h"/>

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

<xs:enumeration value="kW"/>

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

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

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

</xs:restriction>

</xs:simpleType>

</xs:schema>




Appendix D

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

<wsdl:definitions

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

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

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

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

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

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

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

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

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

name="NtS-Message-Service">

<!--

= specification of types =

-->

<wsdl:types>

<!--

= xml-schema for types =

-->

<xs:schema

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

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

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

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

elementFormDefault="qualified"

attributeFormDefault="unqualified"

version="2.0.4.0">

<!-- import NtS schema -->

<xs:import

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

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

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

<xs:element name="get_messages_query">

<xs:complexType>

<xs:sequence>

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

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

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

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

<!-- time of validity -->

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

minOccurs="0"/>

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

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

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

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

</xs:sequence>

</xs:complexType>

</xs:element>

<!-- result to query — can contain

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

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

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

<xs:element name="get_messages_result">

<xs:complexType>

<xs:sequence>

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

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

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

</xs:sequence>

</xs:complexType>

</xs:element>

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

<xs:simpleType name="message_type_type">

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

<xs:enumeration value="FTM"/>

<xs:enumeration value="WRM"/>

<xs:enumeration value="ICEM"/>

<xs:enumeration value="WERM"/>

</xs:restriction>

</xs:simpleType>

<xs:complexType name="id_pair">

<xs:sequence>

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

</xs:sequence>

</xs:complexType>

<xs:complexType name="date_pair">

<xs:sequence>

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

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

</xs:sequence>

</xs:complexType>

<xs:complexType name="paging_request_type">

<xs:sequence>

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

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

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

</xs:sequence>

</xs:complexType>

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

<xs:simpleType name="error_code_type">

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

<xs:enumeration value="e010">

<xs:annotation>

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

</xs:annotation>

</xs:enumeration>

<xs:enumeration value="e030">

<xs:annotation>

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

</xs:annotation>

</xs:enumeration>

<xs:enumeration value="e100">

<xs:annotation>

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

</xs:annotation>

</xs:enumeration>

<xs:enumeration value="e110">

<xs:annotation>

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

</xs:annotation>

</xs:enumeration>

<xs:enumeration value="e120">

<xs:annotation>

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

</xs:annotation>

</xs:enumeration>

<xs:enumeration value="e130">

<xs:annotation>

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

</xs:annotation>

</xs:enumeration>

<xs:enumeration value="e200">

<xs:annotation>

<xs:documentation>Description: operation not known, Explanation: the requested operation is unknown</xs:documentation>

</xs:annotation>

</xs:enumeration>

<xs:enumeration value="e300">

<xs:annotation>

<xs:documentation>Description: data source unavailable, Explanation: data source of the web service for the NtS data is temporarily unavailable</xs:documentation>

</xs:annotation>

</xs:enumeration>

<xs:enumeration value="e310">

<xs:annotation>

<xs:documentation>Description: too many results for request, Explanation: server is unable to handle number of results</xs:documentation>

</xs:annotation>

</xs:enumeration>

</xs:restriction>

</xs:simpleType>

<xs:complexType name="paging_result_type">

<xs:sequence>

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

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

<xs:element name="total_count" type="xs:nonNegativeInteger" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

</xs:schema>

</wsdl:types>

<!--

= specification of messages =

-->

<wsdl:message name="get_messages_request">

<wsdl:part name="parameters" element="tns:get_messages_query"/>

</wsdl:message>

<wsdl:message name="get_messages_response">

<wsdl:part name="parameters" element="tns:get_messages_result"/>

</wsdl:message>

<!--

= specification of port type =

-->

<wsdl:portType name="NtS_message_service">

<wsdl:operation name="get_messages">

<wsdl:input message="tns:get_messages_request"/>

<wsdl:output message="tns:get_messages_response"/>

</wsdl:operation>

</wsdl:portType>

<!--

= specification of binding =

-->

<wsdl:binding name="NtS_message_service_soap_binding" type="tns:NtS_message_service">

<soap:binding style="document" transport= "http://schemas.xmlsoap.org/soap/http" />

<wsdl:operation name="get_messages">

<soap:operation soapAction= "http://www.ris.eu/nts.ms/get_messages" />

<wsdl:input>

<soap:body use="literal"/>

</wsdl:input>

<wsdl:output>

<soap:body use="literal"/>

</wsdl:output>

</wsdl:operation>

</wsdl:binding>

<!--

= specification of service =

-->

<wsdl:service name="NtS_message_service_service">

<wsdl:port name="NtS_message_service" binding="tns:NtS_message_service_soap_binding">

<soap: address location= "http://nts-ms.example.org/NtS_message_service" />

</wsdl:port>

</wsdl:service>

</wsdl:definitions>






TAGS

XML Tag

EN

BG

ES

CS

DA

DE

ET

EL

FR

HR

IT

LV

LT

RIS_message

NtS message

NtS съобщение

Mensaje NtS

Zpráva NtS

NtS-meddelelse

NtS Nachricht

NtS teade

Mήνυμα NtS (Σύστ. Πληρ. Εσ. Ναυσ.)

Message NtS

NtS poruka

messaggio NtS

NtS ziņojums

NtS pranešimas

Identification

Identification section

Идентификационен раздел

Sección de identificación

Identifikační úsek

Identifikationsrubrik

Identifikationsabschnitt

Identifitseerimise jaotis

Τμήμα αναγνώρισης

Identification

Identifikacijski dio

identificazione del tratto

Identifikācija

Identifikavimas

From

Sender of the message

Подател

Remitente

Odesilatel

Afsender

Absender

Teate saatja

Αποστολέας του μηνύματος

Expéditeur du message

Pošiljatelj

mittente del messaggio

Nosūtītājs

Pranešimo siuntėjas

Originator

Originator of the information

Автор на информацията

Origen de la información

Autor zprávy

Informationskilde

Urheber der Nachricht

Teavitaja

Προέλευση των πληροφοριών

Origine de l’information

Izvor informacija

origine dell'informazione

Informācijas autors

Informacijos pateikėjas

Country_code

Country where message is valid

Държава, в която е валидно съобщението

País en que el mensaje es válido

Dotčená země

Berørt land

Betroffenes Land

Riik, kus teade kehtib

Χώρα ισχύος του μηνύματος

Pays où le message est valide

Država gdje poruka vrijedi

Stato interessato

Ziņojuma valsts

Šalis, kurioje galioja pranešimas

Language_code

Original language

Оригинален език

Lengua original

Originální jazyk

Originalsprog

Originalsprache

Algkeel

Πρωτότυπη γλώσσα

Langue d'origine

Originalni jezik

lingua originale

Ziņojuma valoda

Originalo kalba

District

District/region within country

Регион от държавата

Región del país

Dotčená oblast v zemi

Berørt region/område

Betroffenes Gebiet im Land

Riigi piirkond

Περιοχή/περιφέρεια χώρας

Région

Područje unutar države

area/regione interessata

Rajons/ valsts reģions

Rajonas / regionas šalyje

Date_issue

Date of issue

Дата на издаване

Fecha de emisión

Datum vydání

Offentliggørelsesdato

Herausgabedatum

Väljaandmise kuupäev

Ημερομηνία έκδοσης

Date de publication

Datum izdavanja

data di emissione

Sastādīšanas datums

Išdavimo data

Time_issue

Time of issue

Час на издаване

Hora de emisión

Čas vydání

Offentliggørelsestidspunkt

Herausgabezeit

Väljaandmise kellaaeg

Ώρα έκδοσης

Heure de publication

Vrijeme izdavanja

orario di emissione

Sastādīšanas laiks

Išdavimo laikas

Ftm

Fairway and traffic related message

Известие до корабоводителите

Mensaje sobre vía navegable y tráfico

Zpráva týkající se vodních cest a provozu

Farvands- og trafikrelaterede meddelelser

Wasserstraßen- und verkehrsbezogene Nachricht

Teated faaravaatri ja liikluse kohta

Μήνυμα σχετικά με δίαυλο και κυκλοφορία

Message lié à la voie d’eau et au trafic

Priopćenje brodarstvu

messaggio relativo a canale navigabile e traffico

Ziņojums par kuģu ceļu un satiksmi

Su farvateriu ir laivų eismu susijęs pranešimas

NtS_number

Number section

Номер на секция

Número de la sección

Číslo sekce

Nummerrubrik

Nummerierungsabschnitt

Numbri osa

Tμήμα αρίθμησης

Numéro

Odjeljak za broj poruke

numero del tratto

Numuru sadaļa

Numeris

Organisation

Publishing organisation

Издаваща организация

Organización que publica el mensaje

Vydávající organizace

Offentliggørende organisation

Herausgebende Organisation

Väljaandev organisatsioon

Οργανισμός έκδοσης

Entité émettrice

Organizacija

organizzazione emittente

Publicējošā organizācija

Skelbianti organizacija

Year

Year

Година

Año

Rok

År

Jahr

Aasta

Έτος

Année

Godina

anno

Gads

Metai

Number

Number (of the notice)

Номер

Número (del aviso)

Číslo zprávy

(Meddelelsens) nr.

Nummer (der Nachricht)

(Teatise) number

Αριθμός (μηνύματος)

Numéro (de l'avis)

Broj (poruke)

numero (dell'avviso)

(Ziņojuma) numurs

Numeris (pranešimo)

Serial_number

Serialnumber

Сериен номер

Número de serie

Číslo verze

Serienummer

Versionsnummer

Seerianumber

Αύξων αριθμός

Numéro de série

Serijski broj

numero progressivo

Sērijas numurs

Serijos numeris

Target_group

Information about target group

Информация за група получатели

Información sobre el usuario destinatario

Cílová skupina

Målgruppe — strækning

Information zur Zielgruppe

Sihtrühma jaotis

Τμήμα στοχευόμενης ομάδας

Type d'usagers concernés

Ciljana skupina

gruppo destinatario

Mērķgrupa

Tikslinė grupė

Target_group_code

Target group

Код на групата получатели

Código usuario destinatario

Kód cílové skupiny

Kode for målgruppe

Zielgruppe

Sihtrühma kood

Κωδικός στοχευόμενης ομάδας

Code usagers concernés

Oznaka ciljane skupine

codice gruppo destinatario

Mērķgrupas kods

Tikslinės grupės kodas

Direction_code

Affected direction

Код за направление

Dirección tráfico

Směr

Kode for sejlretning

Betroffene Richtung

Sõidusuuna kood

Κωδικός κατεύθυνσης κυκλοφορίας

Sens de parcours

Oznaka smjera prometa

codice direzione traffico

Satiksmes virziena kods

Eismo krypties kodas

Subject_code

Subject

Тема

Asunto

Předmět

Emne

Betrifft

Teema

Θέμα

Sujets de l'avis

Predmet

codice oggetto

Ziņojuma temats

Tema

Validity_period

Period of validity

Срок на валидност

Período de validez

Doba platnosti

Gyldighedsperiode

Gültigkeitszeitraum

Kehtivusaeg

Περίοδος ισχύος

Période de validité

Rok valjanosti

periodo di validità

Derīguma termiņš

Galiojimo laikas

Date_start

From

От дата

De

Od

Startdato

Ab

Alates

Από

Date de début

Od

da (aaaammgg)

No

Nuo

Date_end

Until

До дата

Α

Do

Slutdato

Bis

Kuni

Έως

Date de fin

Do

fino a (aaaammgg)

Līdz

Iki

Contents

Additional information

Съдържание

Contenido

Text

Indhold

Ergänzende Informationen

Sisu

Περιεχόμενα

Contenu

Sadržaj

testo

Saturs

Turinys

Source

Notice source (authority)

Официален източник на известието

Fuente del aviso (autoridad)

Vydavatel zprávy

Infokilde (myndighed)

Herausgeber der Nachricht

Teatise allikas (ametiasutus)

Προέλευση μηνύματος (Αρχή)

Source

Izvor priopćenja

fonte dell'avviso (autorità)

Informācijas avots (iestāde)

Pranešimo šaltinis (institucija)

Reason_code

Reason of notice

Причина за известието

Motivo del aviso

Důvod zprávy

Årsag til meddelelse

Grund der Nachricht

Teatise põhjus

Αιτία μηνύματος

Evènement

Razlog priopćenja

motivazione

Ziņojuma iemesls

Pranešimo paskirtis

Communication

Communication information

Информация за комуникация

Sección comunicación

Informace o komunikačním kanále

Kommunikationsdel

Information zu Kommunikationswegen

Teabevahetuse jaotis

Τμήμα επικοινωνίας

Canal d'information

Informacije o komunikacijskom kanalu

comunicazione

Paziņojums

Ryšio kanalas

Reporting_code

Reporting regime

Режим за известяване

Régimen de notificación

Režim hlášení

Rapporteringskanal

Meldungsart

Aruandluse kord

Καθεστώς αναφοράς

Obligation de s'annoncer

Režim javljanja

regime di segnalazione

Paziņojuma veids

Pranešimo režimas

Communication_code

Means of communication

Средство за свръзка

Medio de comunicación

Prostředky komunikace

Kommunikationsmiddel

Kommunikationsweg

Sidevahendid

Μέσο επικοινωνίας

Moyen de communication

Sredstvo komunikacije

mezzo di comunicazione

Saziņas līdzekļi

Ryšio priemonės

Number (Communication section)

Number or address

Номер или адрес

Número o dirección

Číslo nebo adresa

Nr. eller adresse

Nummer oder Adresse

Number või aadress

Αριθμός ή διεύθυνση

Numéro ou adresse

Broj ili adresa

numero o indirizzo

Numurs vai adrese

Numeris arba adresas

Fairway_section

Waterway or waterway section

Плавателен воден път или негов участък

Vía navegable o tramo

Úsek vodní cesty

Vandvejs- eller farvandsstrækning

Wasserstraße oder -abschnitt

Veetee või faarvaatri jaotis

Τμήμα πλωτής οδού ή διαύλου

Voie ou section de voie

Dionica vodnog ili plovnog puta

tratto idrovia o canale navigabile

Ūdensceļš vai kuģu ceļš

Vandens kelias arba vandens kelio ruožas

Geo_object

Location

Географска информация за водния път или обекта

Ubicación

Geografické informace o vodní cestě nebo objektu

Position

Geoinformation

Geo-teave veetee või objekti kohta

Γεωγραφικές πληροφορίες πλωτής οδού ή αντικειμένου

Objet géo-référencé

Geografske informacije o vodnom putu ili objektu

definizione geografica dell'idrovia o dell'oggetto

Ģeogrāfiskā informācija par ūdensceļu vai objektu

Geografinė informacija apie vandens kelią arba objektą

Id (Geo_Object section)

ISRS Location Code

Идентификация (на географския обект)

Código de posición ISRS

Identifikace

ISRS Location Code

ISRS Location Code

Identifitseerimine

Στοιχεία αναγνώρισης

Identifiant

Identifikacija

identificativo oggetto geografico

Identifikācija

Identifikavimo kodas

Name (Geo_Object section)

Name of object

Наименование на географския обект

Denominación de objeto geográfico

Název geografického objektu

Navn på objekt

Name

Geo-objekti nimi

Ονομασία γεωγραφικού αντικειμένου

Toponyme

Ime geo objekta

denominazione dell'oggetto geografico

Ģeogrāfiskā objekta nosaukums

Geografinio objekto pavadinimas

Type_code (Geo_Object section)

Type

Тип на географския обект

Tipo de vía navegable

Typ objektu

Type

Objekttyp

Veetee tüüp

Τύπος πλωτής οδού

Type

Vrsta objekta

tipo di idrovia

Ūdensceļa veids

Vandens kelio tipas

Coordinate

Coordinates

Координати на началото и края на участъка от фарватера

Coordenadas

Souřadnice počátečních a koncových bodů

Koordinater

Koordinaten

Faarvaatri algus- ja lõppkoordinaadid

Γεωγραφικές συντεταγμένες αρχής και τέλους διαύλου

Coordonnées

Koordinate početka i kraja plovnog puta

coordinate dei punti di delimitazione del tratto navigabile

Kuģu ceļa sākuma un beigu koordinātas

Farvaterio pradžios ir pabaigos koordinatės

Lat (Coordinate)

Latitude

Географска ширина (в десетична стойност)

Latitud

Zeměpisná šířka (desetinné číslo)

Breddegrad

Breitengrad

Laiuskraad (kümnendmurd)

Γεωγραφικό πλάτος (δεκαδικά)

Latitude (décimale)

Geografska širina (decimalno)

latitudine (decimali)

Platums (decimāldaļskaitlis)

Platuma (dešimtųjų tikslumu)

Long (Coordinate)

Longitude

Географска дължина (в десетична стойност)

Longitud

Zeměpisná délka (desetinné číslo)

Længdegrad

Längengrad

Pikkuskraad (kümnendmurd)

Γεωγραφικό μήκος (δεκαδικά)

Longitude (décimale)

Geografska dužina (decimalno)

longitudine (decimali)

Garums (decimāldaļskaitlis)

Ilguma (dešimtųjų tikslumu)

Limitation

Limitation

Раздел за ограничения

Limitación

Druh omezení

Begrænsning

Einschränkung

Piirangu jaotis

Τμήμα περιορισμών

Restriction

Ograničenja

limitazione

Ierobežojums

Apribojimo būdas

Limitation_period

(Limitation) periods/intervals