Appendix A. NOTICES TO SKIPPERS ENCODING GUIDE FOR EDITORS

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.

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

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.

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.

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

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.

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

The geographical range of validity is to be set

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.

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.

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

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

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.

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

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.

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

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

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.

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.

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

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:

1. (a)

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

2. (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.

The message can be published

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.

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

Definition of use of Reason codes:

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.

• ‘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.

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.

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.

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)

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

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.

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.

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.

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.

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

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.

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.

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.

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

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: ‘[email protected]’

• EDI mailbox number: ‘[email protected]’

• Teletext: ‘ARD, 992 — 995’

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

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.

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.

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.

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

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

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

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

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

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

Ice_condition_code

Ice_accessibility_code

Ice_classification_code

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

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

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

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

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

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.