02007R0416 — ES — 29.12.2018 — 001.001

Este texto es exclusivamente un instrumento de documentación y no surte efecto jurídico. Las instituciones de la UE no asumen responsabilidad alguna por su contenido. Las versiones auténticas de los actos pertinentes, incluidos sus preámbulos, son las publicadas en el Diario Oficial de la Unión Europea, que pueden consultarse a través de EUR-Lex. Los textos oficiales son accesibles directamente mediante los enlaces integrados en este documento

Modificado por:

▼B

REGLAMENTO (CE) No 416/2007 DE LA COMISIÓN

de 22 de marzo de 2007

relativo a las especificaciones técnicas de los avisos a los navegantes mencionadas en el artículo 5 de la Directiva 2005/44/CE del Parlamento Europeo y del Consejo relativa a los servicios de información fluvial (SIF) armonizados en las vías navegables interiores de la Comunidad

Artículo 1

En el presente Reglamento se definen las especificaciones técnicas de los avisos a los navegantes. Dichas especificaciones se indican en el anexo del presente Reglamento.

Artículo 2

El presente Reglamento entrará en vigor el día siguiente al de su publicación en el Diario Oficial de la Unión Europea.

El presente Reglamento será obligatorio en todos sus elementos y directamente aplicable en cada Estado miembro.

▼M1

ANEXO

1.   DISPOSICIONES GENERALES

1.1.    Definiciones

Los servicios de información sobre los canales navegables (FIS) incluyen los datos geográficos, hidrológicos y administrativos relativos a las vías navegables que usan los capitanes y gestores de flota para planificar, ejecutar y efectuar el seguimiento de un viaje. Los términos «capitán» y «navegante» que se usan en la presente norma se considerarán equivalentes al término «patrón» usado en las directrices de los servicios de información fluvial (SIF; RIS, por sus siglas en inglés) (Reglamento (UE) n.o 414/2007 de la Comisión ( 1 )), mientras que el término «gestor de flota» está definido en el Reglamento n.o 415/2007 de la Comisión ( 2 ).

Los FIS proporcionan información tanto dinámica (niveles de agua, predicciones de niveles de agua, etc.) como estática (horarios de funcionamiento de esclusas y puentes, etc.) sobre el uso y la situación de la infraestructura de vías navegables, ayudando así a la toma de decisiones tácticas y estratégicas de navegación.

Los medios tradicionales de suministro de esta información incluyen las ayudas visuales a la navegación, los avisos impresos destinados a los navegantes, la radio y los teléfonos fijos de las esclusas. El teléfono móvil ha añadido nuevas posibilidades de comunicación vocal y transmisión de datos, pero la red móvil no está garantizada en todo lugar ni en todo momento. Existen sistemas que ofrecen información específica sobre vías navegables por radioteléfono, por Internet o por carta náutica electrónica, como por ejemplo el sistema de información y visualización de las cartas electrónicas para la navegación interior, ECDIS Fluvial (Inland ECDIS), con cartas náuticas electrónicas (ENC).

1.2.    Funciones principales y requisitos de funcionamiento de los avisos a los navegantes (NtS)

Las presentes especificaciones técnicas de los avisos a los navegantes crean normas para la transmisión de información sobre los canales navegables a través de Internet.

Los avisos a los navegantes (NtS):

Las especificaciones técnicas de los avisos a los navegantes facilitan el intercambio de datos entre los sistemas de NtS de distintos países y con otras aplicaciones que usen información de estos mensajes, incluido el ECDIS Fluvial.

Parte de la información incluida en los mensajes a los navegantes se puede normalizar, y parte, no.

La parte normalizada debe englobar toda la información que resulte:

El contenido adicional que no sea relevante para la seguridad o para la planificación de viajes, incluyendo el motivo de cierre de una esclusa, se puede proporcionar como texto libre, sin traducción automática. El uso de texto libre debe restringirse al mínimo.

2.   ENVÍO DE AVISOS A LOS NAVEGANTES

Los Estados miembros se asegurarán de que los avisos a los navegantes (NtS) sean accesibles en línea y a través del servicio web normalizado de avisos a los navegantes, de acuerdo con las especificaciones técnicas descritas en el presente anexo y sus apéndices. Las especificaciones del servicio web normalizado de avisos a los navegantes están incluidas en el apéndice D en forma de lenguaje de descripción de servicios web (WSDL).

Los servicios web normalizados de avisos a los navegantes proporcionarán al usuario la posibilidad de seleccionar mensajes basándose en, al menos, uno de los siguientes criterios:

Los mensajes a los navegantes que cumplan con las normas establecidas en el presente anexo se pueden enviar, entre otros métodos, mediante:

Se puede llevar a cabo un intercambio de datos entre los sistemas de avisos a los navegantes utilizados en diferentes países. Todos los sistemas que utilicen las normas previstas en el anexo del presente Reglamento pueden incorporar avisos a los navegantes procedentes de otros sistemas a sus propios servicios, siempre que el contenido del mensaje no se modifique. En el caso de que la conexión a una fuente de avisos integrados se interrumpa o no esté disponible, se informará a los usuarios.

3.   TIPOS DE AVISOS A LOS NAVEGANTES (NTS)

Los avisos a los navegantes son mensajes esenciales que se han normalizado en la mayor medida posible.

Existen cuatro tipos de avisos a los navegantes, a saber:

4.   ESTRUCTURA Y CODIFICACIÓN DE LOS AVISOS A LOS NAVEGANTES (NTS)

En el presente apartado se describe la estructura y la codificación de los avisos electrónicos normalizados destinados a los navegantes.

Un aviso a un navegante es un mensaje estructurado que usa elementos normalizados, siempre que esto sea posible. El uso de texto libre en los elementos de datos debe restringirse al mínimo.

La definición del esquema de lenguaje extensible de marcado (XML) de los avisos normalizados a los navegantes, también denominado «XSD(L)» en el presente documento, contiene los valores de códigos normalizados y posibles formatos y se incluye en el apéndice C.

Los valores de códigos normalizados y las etiquetas XML, su significado y traducción se recogen en las tablas de referencia de los avisos a navegantes en el apéndice E y también están disponibles por vía electrónica en el sistema europeo de gestión de datos de referencia (ERDMS) operado por la Comisión Europea.

4.1.    Estructura general

Los avisos a los navegantes constan de las siguientes secciones:

Imagen 1

Estructura de los avisos a los navegantes

4.1.1.    Sección de identificación

Cada mensaje debe contener una sección de identificación. La sección de identificación contiene información general sobre el emisor del mensaje y su fecha de publicación.

4.1.2.    Mensajes referidos a los canales navegables y el tráfico

Los mensajes referidos a los canales navegables y el tráfico contienen información acerca del tramo o tramos o del objeto u objetos de los canales navegables, y se usan para indicar la limitación o limitaciones en los siguientes casos:

4.1.3.    Mensaje relativo al agua

La sección relativa al agua contiene valores o predicciones acerca de:

Normalmente, la información relativa al agua se crea y se publica automáticamente en base a los datos recibidos de equipos sensores (como mareógrafos), sistemas (como el modelo de nivel del agua) o infraestructuras (como el estado de la presa). La publicación puede deberse a distintos motivos, como que se trate de una publicación periódica o que haya alcanzado un valor determinado.

4.1.4.    Mensaje sobre hielos

Los mensajes sobre hielos contienen información sobre las condiciones de hielo reales o previstas en un tramo o tramos de un canal navegable. La información sobre hielos suele ser generada por personal competente sobre la base de la observación local y a una valoración profesional.

4.1.5.    Mensaje relativo a las condiciones meteorológicas

Los mensajes relativos a las condiciones meteorológicas contienen información sobre condiciones meteorológicas (peligrosas) para la navegación interior.

Con el objeto de facilitar la distribución de información hidrometeorológica proveniente de redes hidrometeorológicas a navegantes, se pueden publicar mensajes relativos a las condiciones meteorológicas.

4.2.    Explicación de las etiquetas XML y de los valores de códigos de las tablas de referencia de los avisos a los navegantes (NtS Reference Tables)

El significado de los distintos elementos usados en la definición del esquema XML (XSD) de los avisos a los navegantes se describen en las tablas de referencia de dichos avisos que figuran en el apéndice E. La estructura, formato y posibles valores de todos los elementos XML se describen en la XSD en el apéndice C.

4.3.    Identificación de los tramos y objetos de la vía navegable en los avisos a navegantes

A fin de satisfacer los requisitos mínimos en materia de datos para el suministro de información sobre objetos relevante para la navegación interior según lo dispuesto en el artículo 4, apartado 3, letra a) de la Directiva 2005/44/CE, debe usarse el código de posición ISRS (ISRS Location Code) en la sección correspondiente a los objetos. El código de posición ISRS se usa únicamente para identificar objetos y tramos de canales navegables y asegurar la interoperabilidad de los servicios y sistemas de información fluvial (SIF; RIS, en inglés), (por ejemplo, combinando información sobre infraestructuras del Índice SIF —RIS Index—, el ECDIS Fluvial —Inland ECDIS— y los avisos a los navegantes —NtS—para la planificación de viajes).

El código de posición ISRS es un código alfanumérico de veinte dígitos que se usa para establecer una relación única y normalizada entre objetos en los servicios de información fluvial. Consiste en los siguientes elementos obligatorios, ordenados en cuatro bloques de información:

Los Estados miembros mantienen los códigos de posición ISRS y los datos de referencia de objetos en el Índice SIF que, a continuación, se envían al ERDMS operado por la Comisión Europea de acuerdo con los procedimientos de mantenimiento del Índice SIF publicados en el sitio web del ERDMS.

4.4.    Normas para la codificación de avisos a los navegantes

Los avisos a los navegantes se codificarán de acuerdo con la Guía de codificación de avisos a los navegantes (NtS Encoding Guide) para editores (apéndice A) y la Guía de codificación de avisos a los navegantes (NtS Encoding Guide) para desarrolladores de aplicaciones (apéndice B).

GUÍA DE CODIFICACIÓN DE AVISOS A LOS NAVEGANTES (NTS ENCODING GUIDE) PARA EDITORES

Abreviaturas:

1.    Antecedentes, estructura y objetivo de las guías de codificación de avisos a los navegantes

La normativa de los avisos a los navegantes se mejora de forma continuada. La puesta en marcha del servicio web de avisos a los navegantes para facilitar el intercambio de mensajes entre las autoridades y entre las autoridades y los usuarios de los avisos fue un gran avance.

Para facilitar la codificación armonizada de los avisos a los navegantes a escala nacional e internacional se han elaborado dos documentos: La Guía de codificación de avisos a los navegantes para editores y la Guía de codificación de avisos a los navegantes para desarrolladores de aplicaciones. Estas guías son acordes al lenguaje XSD 4.0 de los avisos a los navegantes (NtS) y el WSDL 2.0.4.0 de los servicios web.

Dado el incremento del uso del servicio web (web service) de avisos a los navegantes (NtS), se procederá a una mayor armonización de los mensajes para asegurar la correcta presentación del contenido en sistemas de terceros. La codificación uniforme de mensajes también es un requisito previo para la consideración de los mensajes en aplicaciones de planificación de viajes.

Los elementos que contengan solo valores normalizados o valores por defecto se omitirán si no son obligatorios, ya que generan mensajes suplementarios sin valor añadido.

La Guía de codificación de avisos a los navegantes para editores está destinada a aquellos que editan (y publican) estos mensajes, e incluye instrucciones paso a paso para crear el tipo adecuado de mensaje, además de la explicación de los códigos. La Guía de codificación de avisos a los navegantes explica la aplicabilidad de los cuatro tipos de mensajes, proporciona instrucciones de cumplimentación y los códigos que se deben usar en ciertos casos. La Guía de codificación de avisos a los navegantes para editores está incluida en el apéndice A del presente documento.

La Guía de codificación de avisos a los navegantes para desarrolladores de aplicaciones incluye pautas para el desarrollo e implementación de aplicaciones y la explicación de su lógica, procesos y valores automáticos o predeterminados. La Guía de codificación de avisos a los navegantes para desarrolladores de aplicaciones está incluida en el apéndice B del anexo del presente Reglamento.

2.    Selección del tipo de aviso a los navegantes (NtS)

3.    Consideraciones principales sobre los FTM, pasos hacia la publicación de un FTM

Se proporciona información detallada acerca de qué códigos deben usarse en el capítulo 4. Las consideraciones a partir del apartado 3.3 no están necesariamente en el orden de entrada de una herramienta de edición FTM.

el FTM existente tiene que actualizarse. El mensaje publicado correspondiente tiene que seleccionarse y actualizarse en la herramienta de edición de mensajes referidos a los canales navegables y el tráfico (FTM). No es posible seguir actualizando un FTM que haya expirado.

se tiene que elaborar un nuevo FTM. En caso de que un evento similar ya esté codificado en un FTM, este último puede usarse como borrador para la creación de un nuevo FTM (si está función está disponible), o se puede usar una plantilla (si esta función está disponible).

Toda información que se pueda expresar usando las tablas de referencia de los avisos a los navegantes (NtS Reference Tables) se tiene que codificar en los campos de mensaje normalizados. En los campos de texto libre solo deberá constar la información adicional que no pueda ser codificada de otra manera.

Si existe información adicional disponible a través de una fuente específica deberá indicarse en esta sección. Si existe una obligación adicional de informar a través de un medio específico deberá indicarse en esta sección.

Si existen limitaciones que resulten de aplicación, se cumplimentará la sección correspondiente. Si se conocen los valores vinculados a las limitaciones, estos deben indicarse. Es obligatorio facilitar los valores correspondientes a las dimensiones de las embarcaciones, el límite de velocidad y el espacio disponible para la navegación.

Todas las limitaciones deben incluir los periodos de limitación a fin de permitir cálculos adecuados en las aplicaciones de planificación de viajes (para facilitar el trabajo, la aplicación de avisos a los navegantes puede incluir una función que permita copiar los periodos de limitación o seleccionar más de una limitación en un periodo).

Cuando se conozca la fecha en que expira la validez de un mensaje, esta también se debe establecer. La fecha de finalización de la validez no debe ser anterior a la fecha actual.

Tenga en cuenta que la información sobre el período de validez será usada por las aplicaciones para seleccionar los mensajes que se mostrarán a los usuarios con relación al momento solicitado.

En caso de que se retire el mensaje:

4.    Explicación de los códigos del FTM

4.1.   Código de asunto (Subject_code)

Explicación de los códigos de asunto:

4.2.   Código de motivo (Reason_code)

El código de motivo debe cumplimentarse para aportar información adicional a los navegantes.

Explicación de uso de los códigos de motivo:

4.3.   Código de limitación (Limitation_code)

Explicación de uso de los códigos de limitación:

4.4.   Código de intervalo de la limitación (Limitation interval_code). Explicación de uso de los códigos de intervalo (interval codes):

4.5.   Código de indicación (Indication_code)

El código de indicación está previsto para informar sobre valores específicos relativos a ciertas limitaciones (por ejemplo límite de velocidad, potencia mínima, profundidad disponible). Para establecer ciertas dimensiones, se requiere una referencia bien a un sistema de referencia externo (geográfico o hidrológico) (por ejemplo, gálibo vertical, profundidad disponible, profundidad mínima medida), bien a dimensiones conocidas de estructuras artificiales (por ejemplo, eslora disponible, gálibo horizontal).

4.6.   Código de posición (Position_code) (objetos):

Siempre que sea posible, el código de posición hará referencia a la margen de la vía navegable en la que esté situado el objeto con relación al eje de la vía navegable (izquierda/centro/derecha), a otra información conocida comúnmente (antiguo/nuevo) o a la dirección geográfica (norte/sur/este/oeste). El código de posición de los objetos se puede completar previamente de manera automática partiendo de los datos de referencia del Índice SIF (SIF Index). Para definir la margen izquierda y derecha de la vía navegable hay que mirar corriente abajo.

4.7.   Código de posición (Position_code) (vías/canales navegables):

El código de posición de un FTM (o de parte de un FTM) relativo a una vía o canal navegable no se proporciona. Para indicar en qué margen de la vía navegable/canal/río/lago hay un incidente, se usa el código de limitación «precaución especial» junto con el código de posición adecuado.

4.8.   Código de posición (Position_code) (limitaciones):

4.9.   Código de grupo destinatário (Target_group_code) (véase capítulo 3.5)

4.10.   Código de notificación (Reporting_code)

4.11.   Código de comunicación (Communication_code)

Se usará el siguiente formato (ejemplos):

4.12.   Código de tipo (Type_code)

Una vía navegable puede ser un canal, un lago o un río:

5.    Consideraciones básicas sobre los WRM

Como norma general, los mensajes sobre el agua se generarán automáticamente. Cuando esto no sea posible, la generación manual de WRM seguirá los procesos establecidos para los WRM generados automáticamente en la mayor medida posible (véase la Guía de codificación de avisos a los navegantes —NtS Encoding Guide— para desarrolladores de aplicaciones).

6.    Consideraciones principales sobre los ICEM, pasos para la publicación de un ICEM

Los mensajes sobre hielos dependen de la observación y la evaluación del entorno, y normalmente los generará personal autorizado.

Se deberá emitir un ICEM en caso de hielo. El hielo no causa necesariamente limitaciones para navegar, pero se puede proporcionar información sobre el estado del hielo aunque no impida la navegación.

El primer mensaje sobre hielos correspondiente a un tramo solo se publicará en caso de que haya hielo en la vía navegable o sus afluentes, incluso cuando no haya limitaciones.

Si un mensaje correspondiente al tramo afectado (todavía) es válido, se actualizará dicho mensaje. Se pueden actualizar los mensajes sobre hielos ya publicados incluso si el área de aplicación cambia (por ejemplo, el hielo se expande incrementando el tamaño del tramo afectado).

En caso de que no exista un mensaje sobre hielos válido para el tramo afectado, se creará un nuevo mensaje.

7.    Consideraciones básicas sobre los WERM

Teniendo en cuenta la abundancia de servicios web (web services) y aplicaciones de predicción meteorológica y avisos sobre el clima, los WERM solo se deben usar para ofrecer información meteorológica de importancia específica para la navegación y que faciliten los servicios de información meteorológica generales.

Los mensajes sobre condiciones meteorológicas se generarán, como norma general, automáticamente. Cuando esto no pueda ser así, la generación manual de WERM seguirá los procesos establecidos para los WERM generados automáticamente en la mayor medida posible (véase la Guía de codificación de avisos a los navegantes —NtS Encoding Guide— para desarrolladores de aplicaciones).

8.    Normas correspondientes a determinados elementos

8.1.    Normas para el elemento «nombre» (name) relativo a los objetos.

Los nombres de los objetos normalmente los introduce previamente la herramienta de edición de avisos a los navegantes (NtS) basándose en los datos de referencia del Índice SIF (RIS Index). Los nombres se introducirán en la lengua local, por lo tanto también podrán usarse, entre otros, signos diacríticos o caracteres cirílicos (por ejemplo, Baarlerbrücke, Volkeraksluis o Mannswörth).

No debe introducirse información sobre características particulares, el tipo de objeto no se repetirá en el nombre a no ser que se aporte información adicional al tipo de objeto.

Ejemplo: A la esclusa «Schleuse Freudenau» se la llamará únicamente «Freudenau», el tipo de objeto «esclusa» se añadirá automáticamente en función del código de tipo (type_code).

Ejemplo: El nombre de objeto del puente de ferrocarril en Krems (AT) es «Eisenbahnbrücke Krems». La información «puente de ferrocarril» se incluye en el nombre de objeto ya que añade información adicional respecto al código de tipo (type_code) «puente».

Ejemplo: El nombre de objeto de un puente en Linz (AT) es «Nibelungenbrücke». El término «brücke» se mantiene junto al nombre de objeto ya que es parte del propio nombre del puente.

Ejemplo: La medición (gauge) de la vía navegable «Pegelstelle Wildungsmauer» recibe el nombre de «Wildungsmauer» ya que la información sobre su carácter ya está codificada en el código de tipo (type_code).

Si un tramo de la vía navegable es la frontera entre dos países con diferentes lenguas, el nombre nacional del objeto se puede incluir en ambas lenguas (por ejemplo, «Staatsgrenze AT-SK/Statna hranica AT-SK»).

8.2.    Normas para el elemento «nombre» referido a las vías navegables

Los nombres de las vías navegables normalmente los introduce previamente la herramienta de edición de avisos a los navegantes (NtS) basándose en los datos de referencia del Índice SIF (RIS Index). El campo «nombre» (name) incluirá la denominación local del tramo correspondiente de la vía navegable (por ejemplo, «Rhein»). Dependiendo de los procesos nacionales puede que sea posible editar el nombre de la vía navegable para incluir denominaciones locales comúnmente usados o añadir otros detalles (por ejemplo, «Rhein am Deutschen Eck»).

8.3.    Normas correspondientes a los elementos «valor» (value) y «unidad» (unit) dentro de las limitaciones.

Salvo que se indique lo contrario, solo se pueden usar las siguientes unidades: cm, m3/s, h, km/h y kW, m/s (viento), mm/h (lluvia) y grados Celsius en los mensajes de aviso a los navegantes (NtS).

GUÍA DE CODIFICACIÓN (ENCODING GUIDE) DE AVISOS A LOS NAVEGANTES PARA DESARROLLADORES DE APLICACIONES

1.    Antecedentes y estructura

Los avisos a los navegantes (NtS) se han estado aplicando en varios países europeos en virtud del Reglamento (CE) n.o 416/2007/CE de la Comisión, relativo a las especificaciones técnicas de los avisos a los navegantes mencionadas en el artículo 5 de la Directiva 2005/44/CE, relativa a los servicios de información fluvial (SIF; RIS, por sus siglas en inglés). La normativa sobre los avisos a los navegantes (NtS) está en proceso continuo de mejora. Un gran avance lo constituyó el lanzamiento del servicio web (web service) que facilita el intercambio de avisos (NtS) entre autoridades y entre autoridades y usuarios de los mensajes, así como del XSD 4.0 de los avisos a los navegantes (NtS) que racionaliza la codificación de estos mensajes.

1.1.    Objetivos de la Guía de codificación de avisos a los navegantes (NtS Encoding Guide)

La Guía de codificación de avisos a los navegantes explica la aplicabilidad de los cuatro tipos de mensajes y los códigos que se deben usar en determinados eventos. Facilita a los editores de avisos a los navegantes (NtS) instrucciones de cumplimentación de los mensajes, con lo que permite la codificación armonizada a nivel nacional e internacional.

Dado el incremento del uso del servicio web (web service) de avisos a los navegantes, se procederá a una mayor armonización de los mensajes para asegurar la correcta presentación del contenido en sistemas de terceros. La codificación uniforme de mensajes también es un requisito previo para la consideración de los mensajes en aplicaciones de planificación de viajes. La Guía de codificación de avisos a los navegantes (NtS Encoding Guide) versión 1.0 es acorde al XSD 4.0 de los avisos a los navegantes y WSDL 2.0.4.0 de los servicios web de avisos a los navegantes.

1.1.1.    Guía de codificación de avisos a los navegantes (NtS Encoding Guide) para editores

La Guía de codificación de avisos a los navegantes para editores está destinada a aquellos que editan (y publican) estos mensajes, e incluye instrucciones paso a paso para crear el tipo adecuado de mensaje, además de la explicación de los códigos. La Guía de codificación para editores también incluye información relevante para los desarrolladores de aplicaciones.

1.1.2.    Guía de codificación de avisos a los navegantes (NtS Encoding Guide) para desarrolladores de aplicaciones (este documento)

La Guía de codificación de avisos a los navegantes para desarrolladores incluye pautas para la implementación de la aplicación de avisos a los navegantes y la explicación de la lógica, los procesos y los valores automáticos o predeterminados.

2.    Avisos a los navegantes (NtS) y secciones

Los avisos a los navegantes constan de las siguientes secciones:

Imagen 2

Esquema de la estructura de los avisos a los navegantes: elemento obligatorio (1), elemento obligatorio que puede figurar una o dos veces (1…2), elemento obligatorio que tiene que figurar dos veces (2), elemento obligatorio que puede figurar tantas veces como sea necesario (1-n), elemento opcional que puede figurar tantas veces como sea necesario (0…n)

La sección de identificación es obligatoria e incluye información general sobre el origen del mensaje, el remitente, la fecha de emisión, el país y la lengua original, y figura junto con otro de los cuatro tipos de secciones de los mensajes:

Además, el código de posición ISRS (norma internacional de información sobre embarcaciones) se utiliza para definir el objeto u objetos o el tramo o tramos de vías navegables a los que es aplicable el mensaje.

El código de posición ISRS (ISRS Location Code) se define en el punto 4.3 del anexo del presente Reglamento.

3.    Consideraciones básicas sobre los WRM

La información sobre el nivel del agua es muy importante tanto para la planificación de viajes como para la seguridad. Por el momento, no existe una norma común para registrar la información sobre el nivel del agua. Los valores de medición remiten a diferentes niveles del mar o puntos de referencia especiales. Para facilitar una referencia adecuada, siempre se facilitará el código de referencia (reference_code) correspondiente junto con el valor de que se trate. Los WRM pueden utilizarse para facilitar la siguiente información:

Los detalles de traducción de los códigos de referencia (reference_code) se facilitan en el capítulo 7.11.

Por lo general, los WRM se crean y publican automáticamente basándose en la información recibida de los sensores o procedente de la infraestructura (por ejemplo, previsiones, estado de la presa). Puede haber diferentes razones para la publicación de un WRM, por ejemplo la publicación periódica o cuando se alcanzan determinados valores.

3.1.    Cumplimentación de la sección correspondiente al número de aviso a los navegantes (nts_number) del WRM

En XSD 4.0 de avisos a los navegantes (NtS), el número es opcional dentro de los mensajes WRM. Si se facilita, cada número debe ser único (organización/año/número/serie) por tipo de mensaje. Corresponde a la organización que emite el WRM garantizar los números únicos (no es necesario que sean consecutivos).

3.2.    Cumplimentación de los WRM incluyendo las previsiones

La fecha de inicio (date_start) del período de validez (validity_period) debe completarse con la fecha de emisión (date_issue), y la fecha de fin (date_end) del período de validez (validity_period), con la del día siguiente a la fecha de emisión (date_issue).

Para introducir los cambios en, por ejemplo, el nivel del agua de una manera sencilla, la diferencia con una medición comparativa previa puede facilitarse en la sección de diferencias del WRM. Además del cambio en el valor (por ejemplo, - 5 [cm]), también debe incluirse la diferente hora de la medida comparativa.

En el caso de las previsiones, la fecha de la medición (measure_date) corresponde a la fecha/hora en la que la previsión es válida.

Las previsiones del nivel de agua siempre incluyen un factor de incertidumbre. Los modelos con diferentes parámetros (por ejemplo, la previsión meteorológica) suelen dar lugar a diferentes previsiones de valores de nivel del agua cuando se calculan. Para permitir aportar un valor mínimo y un valor máximo previsto, por ejemplo la visualización de un intervalo de confianza de previsión del nivel de agua, se incluyen dos campos de datos opcionales adicionales en la sección «medida» del WRM.

En la siguiente imagen se observa un gráfico del intervalo de confianza de previsión del nivel de agua:

Imagen 3

Visualización del intervalo de confianza de previsión del nivel del agua: valor más probable (negro), intervalo de confianza límite superior (violeta), intervalo de confianza límite inferior (rojo), nivel del agua medido (azul)

(El eje x muestra el tiempo; el eje y muestra el nivel del agua en centímetros)

Existen dos elementos disponibles en el XSD de los avisos a los navegantes (NtS):

Aparte de usarse con relación a los niveles de agua previstos, el intervalo de confianza se puede utilizar para expresar la incertidumbre de los datos de profundidad mínima medida y gálibo libre.

Los valores mínimo (value_min) y máximo (value_max) del intervalo de confianza permiten proporcionar el valor del intervalo de confianza del WRM a través de los WRM de aviso a los navegantes normalizados para utilizarlos en gráficos. Los datos brutos no se mostrarán a los usuarios del transporte por vías navegables interiores (por ejemplo, en forma de código).

El código de medida (measure_code) «NOM» no debe utilizarse. En caso de que no haya mediciones para un determinado tipo de WRM, los elementos de valor deben omitirse si de cualquier manera debe enviarse el mensaje.

4.    Procesos relativos a los ICEM

Los mensajes sobre hielos dependen de la observación y evaluación local y, por lo general, se generarán manualmente (en caso de generación automática, deberán seguirse las mismas normas que para la creación manual; véase la Guía de codificación de avisos a los navegantes —NtS Enconding Guide— para editores).

Los ICEM se publican con relación a un determinado tramo de la vía navegable (fairway_section), definido por sus códigos de posición ISRS (ISRS Location Codes) de inicio y fin, y contienen el estado del hielo (ice_condition) en una determinada fecha de medición.

El período de validez de los ICEM empieza en la fecha de publicación (que se establece automáticamente mediante la aplicación de avisos a los navegantes). Para evitar que los ICEM se muestren a usuarios cuando ya no son válidos, la aplicación de avisos a los navegantes (NtS) incluirá automáticamente como fecha de fin (date_end) de la validez el día siguiente al de su publicación (a menos que los procesos nacionales garanticen que los mensajes tendrán una fecha de fin de la validez equivalente al momento en que la información incluida en el mensaje deje de estar actualizada).

En la Guía de codificación de avisos a los navegantes para editores, se describe en qué circunstancias el editor de avisos (NtS) crea un nuevo ICEM o actualiza un ICEM existente. Son aplicables los siguientes procesos:

4.1.    Nuevo ICEM

4.2.    Actualización de un ICEM existente

5.    Consideraciones básicas sobre los WERM

Por lo general, los WERM se crean y publican automáticamente a partir de la información recibida del equipo sensor o de la infraestructura. La fecha de inicio (date_start) del período de validez (validity_period) debe completarse con la fecha de emisión (date_issue), y la fecha de fin (date_end) del período de validez (validity_period), con la del día siguiente a la fecha de emisión (date_issue).

En los WERM, el tramo de vía navegable se indica como un tramo comprendido entre dos puntos concretos, es decir, el área de aplicabilidad de la estación meteorológica (estación de medición).

Debe facilitarse la fecha y la hora de la medición/previsión, aun si no es obligatorio en los mensajes sobre condiciones metereológicas (WERM).

En caso de las previsiones, la fecha de medición (measure_date) es la fecha/hora en la que la previsión es válida.

5.1.    Cumplimentación de la sección de número de aviso a los navegantes (nts_number) de un WERM

En XSD 4.0 de avisos a los navegantes (NtS), el número de aviso es opcional dentro de los mensajes WERM. Si se facilita, cada número debe ser único (organización/año/número/serie) por tipo de mensaje. Corresponde a la organización que emite el WERM garantizar los números únicos (no es necesario que sean consecutivos).

5.2.    Cumplimentación del «código de categoría meteorológica» (weather_category_code) del WERM

La velocidad del viento del «código de categoría meteorológica» (weather_category_code) (valores de 0 a 12) se registrará de acuerdo con la escala de Beaufort, publicada por la Organización Meteorológica Mundial en su Manual de Servicios Meteorológicos Marinos, «OMM- n.o 558».

La visibilidad del «código de categoría meteorológica» (weather_category_code) (valores de 13 a 22) se registrará tal como se indica en la siguiente tabla:

6.    Procesos de los FTM

En la Guía de codificación de avisos a los navegantes (NtS Enconding Guide) para editores, se describe en qué circunstancias el editor de avisos crea un nuevo FTM o actualiza un FTM existente. Son aplicables los siguientes procesos:

6.1.    Nuevo FTM

6.2.    Actualización o anulación de un FTM

6.3.    FTM referido a las vías navegables y/o a objetos

Un FTM referido a la vía navegable contiene información sobre uno o varios tramos de la misma. Un tramo de vía navegable se define en el apartado relativo al tramo de vía navegable (fairway_section) mediante sus códigos de posición ISRS (ISRS Location Codes) de inicio y fin.

Un FTM referido a un objeto contiene información sobre uno o varios objetos específicos del canal. Un objeto se define en el apartado «objeto» mediante su código de posición ISRS (ISRS Location Code).

Un FTM debe referirse:

6.4.    Orden automático de los códigos de limitación

Las diferentes limitaciones tienen distinto impacto en la navegación. Para poder ver la limitación más grave, por ejemplo en una la lista de FTM, debe tenerse en cuenta el siguiente orden, que empieza con la limitación más grave con el primer puesto (Rank 1):

6.5.    Manejo de los períodos de limitación

7.    Normas generales de ejecución

Se tendrán en cuenta los siguientes aspectos:

7.1.    Cumplimentación de la sección correspondiente al número (number_section)

Cada número (organización/año/número/serie) debe ser único por cada tipo de mensaje. Esto significa que los mensajes de diferentes tipos pueden tener el mismo número de aviso a los navegantes (NtS).

Para los usuarios, los números de mensaje solo son relevantes en el caso de los FTM y los ICEM; en todos los demás tipos de mensaje, la visualización del número de mensaje se puede omitir dependiendo de los requisitos nacionales.

A los usuarios, el número de mensaje se les mostrará en el siguiente formato «tipo de mensaje/país/organización/año/número/serie» (Message Type/Country/Organisation/Year/Number/Serial). Se puede acortar dependiendo de los filtros que se apliquen si no se pierde información.

7.2.    Cumplimentación de los elementos «de» (from), «origen de la información» (originator), «organización» (organisation) y «fuente del aviso» (source)

El elemento «de» (from) de la sección de identificación se completa con el nombre del sistema nacional que facilita el mensaje (por ejemplo, ELWIS, DoRIS, SLOVRIS, FLARIS).

El elemento «origen de la información» (originator) corresponde a la organización que introduce los mensajes en los sistemas nacionales.

El elemento «fuente del aviso» (source) corresponde a la autoridad para la que se publican los FTM.

El elemento «organización» (organisation) de la sección correspondiente al número de aviso (nts_number) es el nombre de la organización que asigna el número de aviso a los navegantes (proveedor del aviso).

7.3.    Omisión de elementos

Los elementos que contengan solo valores normalizados o valores por defecto se omitirán si son condicionales, ya que generan mensajes suplementarios sin valor añadido.

Los siguientes elementos se refieren a:

7.4.    Cumplimentación automática de la fecha de emisión (date_issue)

FTM e ICEM

En el caso de los FTM y los ICEM, el valor del elemento «fecha de emisión» (date_issue) corresponde a la fecha y la hora reales de publicación. En el caso de los mensajes actualizados, la fecha de emisión (date_issue) corresponde a la fecha y la hora en que se publicó la actualización.

WRM y WERM

En el caso de los WRM y los WERM, el valor del elemento «fecha de emisión» (date_issue) corresponde a la fecha y la hora de la solicitud de procesamiento, ya que puede haber varias mediciones con diferentes horas de emisión registradas dentro de un mismo mensaje WRM o WERM.

7.5.    Manejo de la información sobre la zona horaria en los avisos a los navegantes (NtS)

En los mensajes XML de los avisos a los navegantes (NtS), la fecha y la hora se facilitarán siempre en la hora local, incluyendo la información relativa a la zona horaria.

Las únicas excepciones a esta disposición son la hora de inicio (time_start) y de fin (time_end) de la sección correspondiente al período de la limitación (limit_period). Esto se debe a que, en la sección correspondiente a la limitación, puede aplicarse un intervalo. Si la fecha de inicio y la fecha de fin corresponden a distintos husos (por ejemplo, CEST y CET), ello resultaría en un cambio en la información sobre la zona horaria dentro de dicho intervalo. Este cambio no puede expresarse mediante un único período de limitación. En lugar de crear diferentes períodos de limitación para cada cambio horario, se utilizará un único período de limitación sin información sobre la zona horaria para reducir la sobrecarga en el procesamiento y la transmisión de mensajes.

7.6.    Manejo de los segundos en los avisos a los navegantes (NtS)

Como regla general, deben introducirse los segundos en los campos de (fecha)/hora, pero no se mostrarán a los usuarios de los avisos. Los minutos son suficientes en lo que se refiere al nivel de detalle de los avisos a los navegantes.

7.7.    Formato de los decimales en los avisos a los navegantes (NtS)

Los decimales de los campos numéricos se indican con un «.» (un punto). No se utilizan separadores para indicar los miles.

El número de decimales utilizados en los valores se limitará a una cantidad factible para garantizar una visualización cómoda.

7.8.    Unidades permitidas en los avisos a los navegantes

En los avisos a los navegantes (NtS), solo están permitidas las siguientes unidades: cm, m3/s, h, km/h y kW, m/s (viento), mm/h (lluvia) y grados Celsius. Las aplicaciones pueden convertir las unidades para una mayor facilidad de uso.

En caso de que las unidades de entrada difieran de las unidades normalizadas, la aplicación debe convertir los valores introducidos como corresponda.

7.9.    Normas relativas a los elementos nombre (name), código de posición (position_code) y código de tipo (type code)

El elemento «nombre» (name) se completará automáticamente con los datos de referencia del Índice SIF (RIS Index) correspondientes al nombre del objeto nacional (national object name). Los editores de avisos a los navegantes pueden modificar este nombre si así lo exigen los requisitos nacionales. Las convenciones de nomenclatura de los nombres de objetos se incluyen en la Guía de codificación del Índice SIF (RIS Index Encoding Guide) versión 2.0 o superior. También se facilitan ejemplos de nombres adecuados para los objetos en la Guía de codificación de avisos a los navegantes (NtS Enconding Guide) para editores.

El código de tipo se añade delante del nombre del objeto mediante la aplicación de avisos a los navegantes.

La posición de los objetos se codifica a través del código de posición y se agrega al objeto procedente del Índice SIF (RIS Index) mediante la aplicación de avisos a los navegantes. Los editores pueden cambiar los códigos de posición y de tipo cumplimentados previamente. No se facilitará un código de posición en el caso de los objetos geográficos (geo_objects) del tramo de vía navegable (fairway_section).

El nombre completo del objeto se compone de código de posición (position code), código de tipo (type code) y nombre (name).

Para facilitar la labor de los editores de avisos a los navegantes (NtS), es posible aplicar el siguiente esquema en las herramientas de edición de avisos para simplificar la búsqueda y selección de los objetos pertinentes a partir del código de función (function_code) del Índice SIF o del código de tipo (type_code) del aviso al navegante:

Tabla 1

Correspondencias código de función del Índice SIF (RIS Index function_code) — código de tipo de los avisos a navegantes (NtS type_code)

7.10.    Normas correspondientes al elemento nombre de la vía navegable (fairway_name)

Para evitar la lógica de las aplicaciones y la necesidad de datos de referencia adecuados en el sistema receptor (software muestra aviso al usuario), en el «objeto geográfico» (geo_object) se incluirá siempre el elemento opcional «nombre de la vía navegable» (fairway_name), que la aplicación NtS completará automáticamente con el nombre del Índice SIF (RIS Index). Los editores de avisos a los navegantes (NtS) no alterarán el contenido del elemento nombre de la vía navegable (fairway_name).

7.11.    Explicaciones de las traducciones recogidas en la ficha «código de referencia» (reference_code)

Se utilizarán las siguientes definiciones para los valores de los códigos de referencia (reference_code) que se facilitan en las tablas de referencia de avisos a los navegantes:

7.12.    Recomendaciones relativas al elemento «coordenada» (coordinate)

Aunque el elemento «coordenada» (coordinate) de la sección correspondiente al objeto geográfico no es obligatorio, las coordenadas geográficas se darán en el sistema WGS84 en formato [d]d mm.mmm[m] N (latitud) y [d][d]d mm.mmm[m] E(longitud). De esta manera, se referencian los avisos a los navegantes geográficamente.

7.13.    Manejo de los grupos destinatarios

La sección correspondiente al grupo destinatario la componen el código del grupo destinatario y el código de dirección. Si ambos tienen el valor «ALL» («todos») y no hay otros grupos destinatarios específicos en el mensaje, se omitirá la sección completa. Si solo se facilita uno de los dos valores, el otro debe completarse con el valor predeterminado «ALL», puesto que ambos elementos son obligatorios.

Para más información sobre los grupos destinatarios, véase la Guía de codificación de avisos a los navegantes (NtS Encoding Guide) para editores.

7.14.    Visualización de mensajes válidos en un momento determinado

Las aplicaciones utilizarán el período de validez (validity_period)» para seleccionar los mensajes que se muestran a los usuarios en un momento dado.

Si el código de asunto (subject_code) es INFSER (servicio de información), el período de validez se utilizará para especificar en qué momento debe mostrarse el mensaje sobre el servicio de información a los usuarios, no el período de validez de la información facilitada (por ejemplo, 1 mes).

7.15.    Funciones opcionales para una mayor facilidad de uso de las herramientas de edición de avisos a los navegantes (NtS)

Se pueden ofrecer las siguientes funciones a los editores en función de los requisitos nacionales:

8.    Estructura de los mensajes XML de los avisos a los navegantes (NtS)

La estructura de los mensajes XML de los avisos, así como el contenido y el propósito de los elementos de datos se definen y explican más detalladamente en el apéndice C: Definición del esquema XML (XSD) de NtS.

9.    Servicio web de avisos a los navegantes (NtS)

9.1.    Objetivos

El Grupo de expertos de avisos a los navegantes consideró que la tecnología del servicio web constituía un medio adecuado para envíar avisos a los navegantes.

Este capítulo recoge las especificaciones del servicio web para el envío de avisos a los navegantes (NtS), servicio web de avisos cortos. Se hizo especial hincapié en el uso de normas internacionales bien establecidas.

Uno de los objetivos del diseño conceptual era garantizar un buen equilibrio entre la flexibilidad y la solidez del servicio web resultante. Los parámetros de filtro de las solicitudes son fundamentalmente los criterios establecidos en las normas relativas a los avisos a los navegantes (tramo de vía navegable con km fluvial opcional, tiempo de validez, fecha de publicación del aviso). Ello parece suficientemente significativo si se tienen en cuenta los casos de uso del servicio web y, a la vez, limita la complejidad de la ejecución.

El resultado principal es un contrato de servicio web, en el que se detallan las solicitudes y las respuestas. Los usuarios del servicio web pueden confiar en este contrato y los proveedores deben cumplirlo. Este contrato se detalla siguiendo la norma internacional WSDL.

Cada Estado miembro participante ejecutará uno o más servicios web con relación a los diferentes tipos de avisos a los navegantes (FTM, WRM, ICEM, WERM) y los prestará a través de Internet (servicio de avisos a los navegantes).

Las especificaciones técnicas para la ejecución del servicio web de avisos a los navegantes, como la selección de los repositorios de datos, aplicaciones y plataformas adecuados, no forman parte del ámbito de aplicación de estas especificaciones y son responsabilidad de cada uno de los Estados miembros participantes.

Con el fin de crear una comunicación segura, se deben tener en cuenta diversos aspectos de seguridad y objetivos de protección. Dependiendo de las circunstancias, no será necesario tener en cuenta todos estos aspectos. La prioridad de los diferentes aspectos de seguridad y su nivel de exigencia pueden variar. También la viabilidad de una determinada medida puede verse limitada por las capacidades de ejecución técnica. En el contexto de los avisos a los navegantes (NtS), toda la información es pública, así que no es necesario proteger los datos de los avisos en términos de protección de datos. Por lo tanto, cada proveedor debe decidir por sí mismo en qué medida se incluirá este elemento en su servicio.

9.2.    Principios y restricciones fundamentales

9.2.1.    Normas con relación a los servicios web

El servicio web de avisos a los navegantes debe cumplir con las especificaciones de WS-I Basic Profile versión1.1. Este perfil ofrece pautas de interoperabilidad a un conjunto de especificaciones de servicios web no propietarios, tales como SOAP, WSDL y UDDI ( 4 ). Las normas más relevantes al respecto son:

El mensaje de respuesta de los servicios web de los avisos a los navegantes es un mensaje definido mediante la definición del esquema XML (XSD) en el apéndice C del presente Reglamento de la Comisión.

9.2.2.    Modelo de interacción y método de codificación de los servicios web de aviso a los navegantes

En los servicios web de aviso a los navegantes (NtS Web Service), se utiliza el método de codificación documento/recorte literal, ya que permite la validación con relación a un esquema XML y los nombres de operación definidos en las especificaciones WSDL se utilizan directamente como nombres de etiqueta XML en los mensajes SOAP.

9.3.    Especificaciones y recomendaciones generales

9.3.1.    Especificaciones: información sobre la versión

La información de la versión del servicio web de aviso a los navegantes (NtS Web Service) consta de dos secciones:

La versión del propio servicio web consta de dos partes:

La versión principal del servicio web se presenta como un número entero positivo que indica la versión principal del servicio web.

La versión secundaria del servicio web se presenta como un número entero no negativo que indica la versión secundaria del servicio web dentro de la versión principal.

La sección del esquema de los avisos (NtS) contiene la versión del esquema de los NtS tal como lo define el Grupo de expertos de avisos a los navegantes.

Por lo tanto, la versión del servicio web de avisos a los navegantes que se detalla aquí es la 2.0.4.0, donde 2.0 es la versión del propio servicio web y 4.0 es la versión del esquema de avisos a los navegantes que se utiliza.

En las solicitudes o respuestas del servicio web de avisos a los navegantes, no se necesita información explícita sobre la versión. Se prevé que solo algunas versiones de los servicios estén en línea al mismo tiempo. Cada versión tendrá una URL distinta. Por lo tanto, cada instancia de ejecución del servicio web de NtS contemplará una versión concreta del servicio web de NtS.

9.3.2.    Especificaciones: estructura de los espacios nominales

Los espacios de nombres del servicio web de avisos a los navegantes (NtS Web Service) se basan en el dominio web de los grupos de expertos del SIF (RIS), http://www.ris.eu/.

Los espacios de nombres contienen una partícula que indica el servicio y la información del servicio correspondiente. Por lo tanto, el servicio en cuestión utiliza el siguiente espacio de nombres:

Servicio de avisos a los navegantes: http://www.ris.eu/nts.ms/2.0.4.0

9.3.3.    Recomendación: utilización de los espacios de nombres

Para una mayor transparencia de los documentos XML, se recomienda definir espacios de nombres en el mínimo elemento adecuado de los esquemas, así como en los documentos de instancia, y no utilizar las definiciones de espacios de nombres locales en elementos anidados.

9.3.4.    Recomendación: utilización de prefijos de espacios de nombres

Las solicitudes y respuestas del servicio web de avisos a los navegantes (NtS Web Service) utilizarán elementos XML calificados, es decir, con un prefijo de espacio de nombres explícito y atributos de XML sin calificar, o sea, sin un prefijo de espacio de nombres.

Se recomienda utilizar prefijos de espacio de nombres intuitivos, tales como «nts», para facilitar su lectura.

9.3.5.    Especificaciones: utilización de los códigos de posición ISRS (ISRS Location Codes)

Los códigos de posición ISRS (ISRS Location Codes) se explican en el capítulo 2 de la Guía de codificación de avisos a los navegantes (NtS Encoding Guide) para desarrolladores de aplicaciones y en la Guía de codificación del Índice SIF (RIS Index Encoding Guide).

En su consulta a un servicio web de aviso a los navegantes (NtS Web Service), el usuario puede enumerar diversos objetos, por ejemplo, tramos de vías navegables, elementos de medición o presas. Si se utilizan los parámetros correspondientes, los elementos de identificación (id elements), deben contener códigos de posición ISRS. Estos parámetros se presentan normalmente como elementos de identificación, y cada uno contiene uno o dos identificadores.

Cuando se usen estos parámetros, se deben observar las siguientes convenciones generales:

Para incluir los tramos de vías navegables (pares de elementos de identificación en el apartado correspondiente al objeto geográfico —geo_object— del tramo de vía —fairway_section—) en los avisos a los navegantes, se deben tener en cuenta los siguientes aspectos con relación a los códigos de posición ISRS (ISRS Location Codes):

En caso de que un mensaje afecte a más de una vía navegable o tramos de vías navegables, todos los tramos deben definirse mediante sus puntos de inicio y fin en elementos XML separados del apartado correspondiente al tramo de vía navegable (fairway_section).

En cuanto a algunos países o regiones, es necesario crear una función de filtro. Por ejemplo, si el código de posición ISRS (1-2) es «BE» se usará el código de posición ISRS (6-8) como elemento de identificación para la referenciación lineal con el hectómetro de la vía navegable (código de posición ISRS 16-20). Ejemplos de tramos de vías navegables (pares válidos de elementos de identificación dentro del tramo de vía navegable) que incluyen las excepciones definidas anteriormente:

La siguiente imagen muestra ejemplos negativos de la utilización de los códigos de posición ISRS en el caso de cada una de las convenciones generales (no hay excepciones a las convenciones generales en los tramos de vías navegables de SK):

Consultas sobre códigos de posición ISRS (ISRS Location Codes) nulos

Observaciones generales: El servicio web de avisos a los navegantes (NtS Web Service) no es compatible con un servicio para consultar los códigos de posición ISRS válidos. Los códigos de posición ISRS se facilitan en el marco del sistema europeo de gestión de datos de referencia (ERDMS).

En los siguientes cinco casos se presenta el uso correcto de los códigos de posición ISRS en las consultas y su interpretación.

Caso 1: Sin elemento de identificación en la solicitud

El elemento de identificación es una parte opcional de la solicitud, es decir, es posible realizar una consulta sin ningún elemento de identificación:

Consulta válida sin parámetros de identificación

Si no se facilita ningún elemento de identificación, se devolverán todos los mensajes, dependiendo, por supuesto, de otros criterios de filtro como el período de validez (validity_period) o las fechas de emisión (dates_issue).

Caso 2: Un solo elemento de identificación en la solicitud

Cada elemento de identificación puede contener uno o dos identificadores. En la siguiente imagen se muestra el caso de un solo elemento de identificación:

Consulta válida con un parámetro de identificación

Si se recibe dicha consulta, el servidor devolverá todos los mensajes que coincidan con un hectómetro de inicio ≤ el valor dado (240,7 en el ejemplo) y un hectómetro de fin ≥ este valor. La siguiente imagen muestra la selección de mensajes: la posición consultada se encuentra entre los valores de los hectómetros de inicio y fin de los mensajes 1, 3 y 4, que serían devueltos; los mensajes 2, 5 y 6 no se superponen con la posición consultada, por lo que no se devolverían.

Si el código de posición ISRS (ISRS Location Code) en cuestión señala un objeto particular, por ejemplo una estación de medición o una esclusa, el servicio web debe devolver los mensajes referidos a este objeto.

Mensajes coincidentes y no coincidentes con un mismo parámetro de identificación

Caso 3: Dos elementos de identificación en la solicitud

Cada elemento de identificación puede contener uno o dos identificadores. En la siguiente imagen se muestra el caso de dos elementos de identificación:

Consulta válida con dos parámetros de identificación

Todos los valores del hectómetro consultados se tratarán como válidos, incluso si el tramo de vía navegable correspondiente tiene diferentes puntos de inicio o fin. Por ejemplo, si el tramo de vía navegable empieza en el hectómetro 100,0 y termina en el hectómetro 300,0 , una solicitud de consulta de los hectómetros 20,0 a 400,0 sería válida. Internamente solo se busca la extensión «real» de la sección del canal navegable.

Esto también permite la búsqueda de todos los mensajes relativos a una vía navegable sin conocer el rango exacto de hectómetros (se enviaría el código de posición ISRS con hectómetros establecidos en «00000» o «99999» respectivamente).

Se devolverán todos los mensajes coincidentes que se crucen con el intervalo de hectómetro. El siguiente diagrama ilustra esta situación:

Mensajes coincidentes y no coincidentes con dos parámetros de identificación

La figura anterior muestra cómo se define el «cruce». Mientras que las extensiones de los mensajes 1 a 4 se superponen con la extensión del rango de hectómetros consultado (parcial o completamente), las extensiones de los mensajes 5 y 6 no lo hacen, por lo tanto, se devolverán los mensajes 1 a 4, y no se devolverán los mensajes 5 y 6.

La condición técnica para que un mensaje se cruce con un intervalo [A, B] es: el hectómetro de inicio del mensaje es ≤ B y el hectómetro de fin es ≥ A.

Combinación: Múltiples elementos de identificación en la solicitud

Consulta válida con múltiples elementos de identificación

La combinación de varios elementos de identificación en la solicitud supone la unión de los mensajes correspondientes. Todos los elementos de identificación se tratan de forma individual y se devolverán los mensajes que coincidan con al menos uno de ellos. Por lo tanto, en el caso del ejemplo presentado, se devolverían los siguientes mensajes:

9.4.    Servicio de avisos a los navegantes (especificaciones de ejecución)

En el presente capítulo se presentan las especificaciones de ejecución del servicio de avisos a los navegantes, que se extraen de las consideraciones y decisiones de los capítulos anteriores.

El servicio de avisos a los navegantes (NtS) ofrece cuatro tipos de mensajes en los avisos:

La ejecución del servicio de avisos a los navegantes (NtS) es compatible con todos los tipos de mensajes o solo con una parte. Un Estado miembro participante puede ofrecer más de un servicio correspondiente a un tipo de mensaje concreto, que sean complementarios entre sí.

9.4.1.    Solicitud

Con el fin de lograr la máxima robustez del servicio y mantener al mismo tiempo un nivel reducido de complejidad, en el servicio web de avisos a los navegantes (NtS Web Service) no se utiliza un lenguaje de consulta adicional. En su lugar, se aplican las construcciones que ofrece el propio WSDL. Las operaciones concretas y sus parámetros se detallan por completo en las especificaciones del WSDL. En el caso del servicio de mensajes de avisos a los navegantes, se define una sola operación.

Los criterios de filtro por asunto se toman de la norma sobre los avisos a los navegantes, pero se amplían con respecto a los múltiples parámetros:

El servicio solo devuelve los mensajes que coinciden con los criterios establecidos.

Mecanismo de paginación

Se admite un mecanismo de paginación que permita controlar la cantidad de datos. El parámetro de paginación se define mediante un tipo complejo que contiene los siguientes elementos:

El parámetro de paginación complejo es opcional, pero en caso de que exista, debe incluir todos los elementos. El mecanismo de paginación funciona de la siguiente manera:

El número total de mensajes no excederá el valor del parámetro «límite» (limit), salvo un valor 0 que significa «sin límite». La respuesta omite tantos mensajes como se defina en el parámetro «dirección relativa» (offset). Con el fin de ofrecer este mecanismo, el servicio debe observar una secuencia temporal estable (aunque arbitraria) de mensajes, por ejemplo entre dos actualizaciones de datos de mensajes en el conjunto de datos subyacente al servicio web. Esto significa que dos llamadas consecutivas idénticas deben devolver los mismos mensajes en el mismo orden. El parámetro «recuento total» (total count) determina si la respuesta enviará la totalidad de los mensajes que coincidan con los criterios propios del asunto. Normalmente, debe ser suficiente solicitar esta información con la primera respuesta, y omitirla en todas las respuestas siguientes. Ello supondría un mejor rendimiento del servicio web.

El mecanismo de paginación ofrece los medios para solicitar los mensajes de forma reiterada en «páginas». Para que el mecanismo de paginación funcione correctamente, es necesario facilitar los mismos parámetros de asunto en cada solicitud.

9.4.2.    Respuesta

En caso de una solicitud realizada correctamente, la respuesta del servicio web de aviso a los navegantes contiene los mensajes de aviso que coinciden con los parámetros de la solicitud. Los avisos a los navegantes deben ser acordes al esquema de avisos a los navegantes y pueden validarse constrastándolos con este último. Dado que el tipo de mensaje es un parámetro obligatorio de la solicitud, cada respuesta puede contener solo avisos a los navegantes del mismo tipo; FTM, WRM, ICEM o WERM, respectivamente.

Si el servicio detecta errores al procesar la solicitud, puede devolver un número arbitrario de mensajes de error, utilizando los códigos de error enumerados en el siguiente apartado.

Una respuesta de un servicio web de aviso a los navegantes puede contener mensajes de aviso y mensajes de error al mismo tiempo.

La información opcional sobre la paginación se devolverá si la solicitud contiene parámetros de paginación. En este caso, el balance y el número de mensajes que contiene son obligatorios; el recuento total, solo si se solicita.

Nota: Se entiende que la comunicación entre el servicio web y el usuario ha quedado técnicamente establecida; es decir, el servicio recibe la solicitud y el usuario recibe la respuesta correspondiente. Aquí no se tienen en cuenta los errores técnicos, como los fallos de conexión a Internet o la inaccesibilidad del servicio web debido a labores de mantenimiento o una caída Solo se consideran los errores ocurridos más allá del nivel del servicio web desde el punto de vista de los usuarios.

Mensajes de error

A continuación se presentan los códigos de error correspondientes a los errores previstos, junto con una explicación. En la respuesta solo figura el código de error, que es el procedimiento habitual en el esquema XML de los avisos a los navegantes.

9.5.    Generación de servicios y clientes

Si el enfoque del contrato como prioridad se respeta consecuentemente, es decir, se ofrecen uno o más contratos con descripciones completas de las interfaces en forma de documentos WSDL, es posible generar de forma automática la ejecución del servicio o servicios así como del cliente correspondiente utilizando las herramientas de software adecuadas. Idealmente, no es necesario realizar cambios manuales en el código fuente generado.

Sin embargo, en la mayoría de los casos, suelen requerirse operaciones reiteradas hasta que las especificaciones de WSDL son compatibles con los requisitos precisos de dicha herramienta. Normalmente, la herramienta realiza solicitudes particulares sobre el uso de la norma WSDL para funcionar correctamente. Como consecuencia, puede que se requieran cambios en las especificaciones WSDL, aunque las especificaciones WSDL sean especificaciones válidas de conformidad con la norma WSDL inicial. Si las especificaciones de WSDL del servicio web (web service) se modifican después de que se haya generado el servicio o el cliente, puede que sea necesario un nuevo proceso de generación, dependiendo de los cambios realizados.

Glosario

Apéndice C

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

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