B. GUIA DE CODIFICAÇÃO (NTS ENCODING GUIDE) DE AVISOS À NAVEGAÇÃO PARA INFORMÁTICOS

ÍNDICE

1. Antecedentes e Estrutura 24

1.1. Objetivo do Guia de Codificação de NtS — NtS Encoding Guide 24

1.1.1. Guia de Codificação de NtS para Editores 24

1.1.2. Guia de Codificação de NtS para Informáticos (presente documento) 24

2. Mensagens NtS e respetivas secções 24

3. Considerações básicas sobre as mensagens WRM 26

3.1. Preenchimento da secção «nts_number» (número do NtS) nas WRM 26

3.2. Redação de mensagens WRM incluindo previsões 26

4. Processos das mensagens ICEM 27

4.1. Mensagem ICEM nova 28

4.2. Atualização de uma mensagem ICEM existente 28

5. Considerações básicas sobre as mensagens WERM 29

5.1. Preenchimento da secção «nts_number» nas mensagens WERM 29

5.2. Preenchimento da secção «weather_category_code» das mensagens WERM 29

6. Processos das mensagens FTM 30

6.1. Nova FTM 30

6.2. Atualização/anulação de uma FTM existente 30

6.3. FTM relativa à via navegável e/ou ao objeto 31

6.4. Ordenação automática dos códigos de restrição 31

6.5. Tratamento do período de restrições 32

7. Regras gerais de execução 33

7.1. Preenchimento da secção relativa ao número («number_section») 33

7.2. Preenchimento dos elementos «from», «originator», «organisation» e «source» 33

7.3. Omissão de elementos 34

7.4. Preenchimento automático da secção «date_issue») 34

7.5. Tratamento das informações relativas ao fuso horário nas mensagens NtS 34

7.6. Tratamento dos segundos nas mensagens NtS 34

7.7. Formato dos separadores decimais nas mensagens NtS 34

7.8. Unidades de medidas a utilizar nas mensagens NtS 34

7.9. Regras aplicáveis aos elementos «name», «position_code» e «type_code» 34

7.10. Regras aplicáveis ao elemento «fairway_name» 38

7.11. Esclarecimentos para as traduções na folha de cálculo «reference_code» (referência) 38

7.12. Recomendação para o elemento «coordenada» 38

7.13. Tratamento dos grupos-alvo 38

7.14. Visualização de mensagens válidas num dado momento 39

7.15. Funções opcionais para aumentar a facilidade de utilização das ferramentas de edição NtS 39

8. Estrutura de mensagem XML dos NTS 39

9. O Serviço Web NTS 39

9.1. Objetivo 39

9.2. Princípios básicos e condicionalismos 40

9.2.1. Normas Web 40

9.2.2. Modelo de interação e método de codificação do WS NtS 40

9.3. Especificações e recomendações gerais 40

9.3.1. Especificação: Informação sobre as versões 40

9.3.2. Especificação: Estrutura dos espaços de nomes 41

9.3.3. Recomendação: Utilização de espaços de nomes 41

9.3.4. Recomendação: Utilização de prefixos de espaços de nomes 41

9.3.5. Especificação: Utilização dos ISRS Location Codes 41

9.4. Serviço de mensagens NtS (especificação da aplicação) 46

9.4.1. Pedido de informação 46

9.4.2. Resposta 47

9.5. Geração de serviços e clientes 48

Glossário 48

1. Antecedentes e Estrutura

Os avisos à navegação (NtS) eram aplicados em diversos países europeus, com base no Regulamento (CE) n.o 416/2007 da Comissão, relativo às especificações técnicas dos avisos à navegação a que se refere o artigo 5.o da Diretiva 2005/44/CE do Parlamento Europeu e do Conselho. A norma NtS é continuamente melhorada e um dos principais progressos foi o lançamento do Serviço Web NtS, que facilitou o intercâmbio de mensagens NtS entre as diversas autoridades, bem como entre estas e os utilizadores de NtS. Outro progresso foi a utilização do XSD 4.0 para NtS, que simplifica a codificação das mensagens NtS.

1.1. Objetivo do Guia de Codificação de NtS — NtS Encoding Guide

O Guia de Codificação de NtS explica como devem ser aplicados os quatro tipos de mensagens NtS e os códigos a utilizar caso se verifiquem determinados acontecimentos. Fornece aos editores de NtS instruções sobre a elaboração das mensagens NtS, permitindo, assim, a sua codificação harmonizada a nível nacional e internacional.

Tendo em conta o aumento da utilização do serviço Web NtS, há que prosseguir a harmonização das mensagens NtS para garantir a correta visualização dos conteúdos nos sistemas de terceiros. A codificação uniforme das mensagens é igualmente indispensável para que estas possam ser tidas em conta nas aplicações de planificação da viagem. A versão 1.0 do Guia de Codificação de NtS é aplicável ao XSD 4.0 para NtS e ao Serviço Web WSDL 2.0.4.0 para NtS.

1.1.1. Guia de Codificação de NtS para Editores

O Guia de Codificação de NtS para Editores destina-se ao pessoal que edita (e publica) mensagens NtS, incluindo instruções pormenorizadas sobre a criação dos tipos de mensagens adequados, bem como uma explicação dos códigos. Inclui igualmente informações relevantes para os informáticos.

1.1.2. Guia de Codificação de NtS para Informáticos (presente documento)

O Guia de Codificação de NtS para Informáticos inclui orientações para a execução de aplicações NtS que explicam a lógica, os processos e os valores automáticos/por defeito.

2. Mensagens NtS e respetivas secções

Uma mensagem NtS é constituída por:

— uma secção «identificação»

— uma secção que define o(s) objeto(s) ou troço(s) de via navegável a que a mensagem diz respeito;

— uma ou mais das secções a seguir enumeradas, em função do tipo de mensagem: — a(s) restrição(ões) no caso das mensagens relativas à via navegável e ao tráfego, — a(s) medições, no caso das mensagens relativas ao nível da água, — as condições do gelo, no caso das mensagens relativas ao gelo, — os boletins meteorológicos no caso das mensagens relativas às condições meteorológicas.

Figura 2

A secção «identificação» é obrigatória e inclui informações de caráter geral sobre a entidade de origem, o remetente, a data de emissão, o país e língua de origem. Acompanha um dos quatro tipos de secções das mensagens NtS:

— Secção relativa à via navegável e ao tráfego: uma «mensagem relativa à via navegável e ao tráfego» (FTM) é geralmente criada pelos editores NtS de acordo com o Guia de Codificação de NtS para Editores. Está relacionada com troços de vias navegáveis (definidos pelos seus códigos ISRS de local de início e de termo) e/ou com objetos presentes na via navegável, definidos pelo respetivo código ISRS de local [ir para capítulo 6].

— Secção relativa ao nível da água: uma «mensagem relativa à água» (WRM) facilita o fornecimento de informações sobre os níveis de água atuais e previstos, bem como outras informações. Normalmente as WRM são criadas automaticamente (e periodicamente) com base nas medições de sensores ou no estado das infraestruturas, não exigindo qualquer interação com o editor de NtS. A secção de mensagens relativas à água contém informações sobre um objeto (por exemplo, estação hidrométrica) ou um troço de via navegável (por exemplo, a profundidade mínima medida ou o regime aplicável num determinado troço). O objeto é identificado pelo seu código ISRS de local e o troço de via navegável pelos códigos ISRS de local dos seus extremos inicial e final [ir para capítulo 3].

— Secção relativa ao gelo: uma «mensagem relativa ao gelo» (ICEM) contém informações sobre o estado do gelo num troço da via navegável definido pelos códigos ISRS de local dos seus extremos inicial e final [ir para capítulo 4].

— Secção relativa às condições meteorológicas: uma «mensagem relativa às condições meteorológicas» (WERM) permite fornecer informações sobre as situações meteorológicas atuais e previstas num troço de via navegável definido pelos códigos ISRS de local dos seus extremos inicial e final. [ir para capítulo 5].

Além disso, o ISRS Location Code (código de local da International Ship Reporting Standard) é utilizado para definir o(s) objeto(s) ou troço(s) de via navegável a que a mensagem é aplicável.

O código ISRS de local é definido no ponto 4.3 do anexo do presente regulamento.

3. Considerações básicas sobre as mensagens WRM

As informações sobre o nível da água têm grande importância para a planificação e a segurança da viagem. Atualmente, não existe qualquer norma comum para a expressão destes dados. A graduação dos fluviómetros é feita por referência a diferentes níveis da água do mar ou a pontos específicos. Para fornecer uma referência adequada, deve indicar-se sempre a respetiva referência (reference_code) juntamente com o valor. As WRM podem ser utilizadas para fornecer as seguintes informações:

— Nível da água (incluindo previsões),

— Profundidade mínima medida (incluindo previsões),

— Altura livre (incluindo previsões),

— Descargas (incluindo previsões),

— Status das barragens,

— Regime.

São fornecidos esclarecimentos para as traduções na folha de cálculo «reference_code» [Esclarecimentos para as traduções na folha de cálculo «reference_code» (referência)] no capítulo 7.11.

Normalmente, as mensagens WRM são automaticamente criadas e publicadas com base nas informações recebidas de sensores ou das infraestruturas (por exemplo, previsões ou status das barragens). A publicação de WRM pode ser desencadeada por diferentes fatores, tais como a periodicidade ou a chegada a determinado valor.

3.1. Preenchimento da secção «nts_number» (número do NtS) nas WRM

No XSD 4.0 para NtS o número do NtS é opcional no caso das mensagens WRM. Se for fornecido, cada número deve ser único (Organização/Ano/Número/Série) para cada tipo de mensagem e compete ao organismo que fornece a WRM garantir que o seu número é único (não é necessário que os números sejam consecutivos).

3.2. Redação de mensagens WRM incluindo previsões

A data de início (date_start) do período de validade (validity_period) deve ser preenchida com a data atual (date_issue) e a data de termo (date_end) do período de validade com a data do dia seguinte à data atual.

Para indicar as alterações, por exemplo do nível da água, de uma forma facilmente compreensível, pode inserir-se a diferença em relação a uma medição comparativa anterior na secção da WRM relativa às diferenças. Para além da alteração do valor (por exemplo, -5 [cm]), também se deve indicar o hiato temporal em relação à medição comparativa.

No caso das previsões, a data da medição («measure_date») é a data/hora para a qual a previsão é válida.

As previsões do nível da água contêm sempre um fator de incerteza. Normalmente, são calculados modelos com parâmetros diferentes (por exemplo, previsões meteorológicas), que conduzem à previsão de diferentes valores do nível da água. Para possibilitar o fornecimento de previsões dos valores mínimos e máximos, por exemplo a visualização de um intervalo de confiança de uma previsão do nível da água, incluem-se mais dois campos de dados opcionais na secção «medida» da WRM.

Na figura seguinte, apresenta-se um exemplo de intervalo de confiança de uma previsão do nível da água:

Figura 3

Visualização do intervalo de confiança de uma previsão do nível da água: valor mais provável (preto), limite superior do intervalo de confiança (roxo), limite inferior do intervalo de confiança (vermelho)

No XSD NtS estão disponíveis dois elementos:

<value_min> valor mínimo do intervalo de confiança

<value_max> valor máximo do intervalo de confiança

Para além dos níveis da água previstos, o intervalo de confiança também pode ser usado para referir a incerteza das informações publicadas sobre a profundidade mínima medida e a altura livre vertical.

Estes elementos «value_min» e «value_max» do intervalo de confiança permitem que o valor do intervalo de confiança seja fornecido através de mensagens NtS WRM normalizadas para ser utilizado nos gráficos. Os dados brutos não devem ser mostrados aos utilizadores da navegação fluvial (por exemplo, em formato codificado).

O tipo de informação relativa à água (measure_code) «NOM» não deve ser utilizado. Caso não exista nenhuma medição para um determinado tipo de WRM, devem omitir-se os elementos relativos ao valor se a mensagem tiver de ser enviada na mesma.

4. Processos das mensagens ICEM

As mensagens relativas ao gelo dependem da observação e avaliação no local e, regra geral, são geradas manualmente (se forem geradas automaticamente, devem seguir as regras aplicáveis à criação manual, ver Guia de Codificação de NtS para Editores).

A ICEM é publicada em relação a um determinado troço da via navegável (fairway_section) definido pelos códigos ISRS de local dos seus extremos inicial e final e indica o estado do gelo (ice_condition) numa determinada data de medição.

A validade da ICEM começa na data de publicação (automaticamente estabelecida pela aplicação NtS). A fim de evitar que a ICEM seja mostrada a utilizadores que já não sejam válidos, a data de termo da validade (date_end) deve ser preenchida automaticamente pela aplicação NtS com o dia seguinte à publicação (exceto se os processos nacionais garantirem a atribuição de uma data de termo da validade às mensagens, assim que a informação nelas incluída deixe de estar atualizada).

No Guia de Codificação de NtS para Editores descreve-se em que circunstâncias um editor de NtS cria uma nova ICEM ou atualiza uma ICEM existente. São aplicáveis os processos a seguir indicados:

4.1. Mensagem ICEM nova

1) As aplicações de NtS podem facultar aos editores de NtS a. A utilização de avisos existentes como rascunhos para a criação de novas ICEM (por exemplo, se as condições do gelo forem semelhantes ao aviso existente) e/ou b. A utilização de modelos de avisos para determinadas situações.

2) O conteúdo (por exemplo, a hora da medição ou as respetivas condições de gelo) deve ser inserido pelo editor em conformidade com o capítulo 6 do Guia de Codificação de NtS para Editores. A data e a hora da medição também podem ser estabelecidas pela aplicação de acordo com as definições nacionais.

3) Quando um editor de NtS desencadeia a ação de publicação, a. É verificado se todos os conteúdos obrigatórios são fornecidos em conformidade com o XSD NtS (caso contrário, volta-se a 2), b. O número do NtS (nts_number) é gerado pela aplicação NtS, i. a «organização» é preenchida com o nome ou o código do organismo responsável, dependendo da função do utilizador que faz a publicação, ii. o «ano» é preenchido com o ano em curso, iii. é atribuído o «número» disponível seguinte, iv. é atribuído o «número de série» 0. c. A secção «date_issue» é automaticamente preenchida com a data/hora da ação de publicação, d. A secção «validity_period» — «date_start» é automaticamente preenchida com a data de publicação efetiva, e. A secção «validity_period» — «date_end» é automaticamente preenchida com o dia seguinte à data de publicação (exceto se os processos nacionais garantirem a atribuição de uma data de termo da validade às mensagens, assim que a informação nelas incluída deixe de estar atualizada).

4.2. Atualização de uma mensagem ICEM existente

1) A mensagem publicada em causa deve ser selecionada para atualização na ferramenta de edição de ICEM. A ICEM original deve ser copiada ou alterada na base de dados [dependendo dos processos nacionais). Uma ICEM expirada (que tenha passado o prazo de validade (validity_date_end)] deixa de poder ser atualizada e, nesse caso, os editores de NtS têm de criar uma nova ICEM.

2) O conteúdo (por exemplo, a hora de medição ou as respetivas condições de gelo) deve ser alterado pelo editor em conformidade com o capítulo 6 do Guia de Codificação de NtS para Editores. A data e a hora de medição também podem ser alteradas pela aplicação de acordo com as definições nacionais.

3) Quando um editor de NtS desencadeia a ação de publicação, a. É verificado se todos os conteúdos obrigatórios são fornecidos em conformidade com o XSD NtS (caso contrário, volta-se a 2), b. O número do NtS (nts_number) é gerado pela aplicação NtS, i. a «organização» mantém-se inalterada, ii. o «ano» mantém-se inalterado, iii. o «número» mantém-se inalterado, iv. o «número de série» é aumentado (aumento de 1) c. A secção «date_issue» é automaticamente preenchida com a data/hora da ação de publicação d. A secção «validity_period» — «date_start» é automaticamente preenchida com a data de publicação efetiva e. A secção «validity_period» — «date_end» é automaticamente preenchida com o dia seguinte à data de publicação (exceto se os processos nacionais garantirem a atribuição de uma data de termo da validade às mensagens, assim que a informação nelas incluída deixe de estar atualizada).

5. Considerações básicas sobre as mensagens WERM

Normalmente, as WERM são criadas e publicadas automaticamente com base nas informações recebidas dos sensores ou das infraestruturas. A data de início (date_start) do período de validade (validity_period) deve ser preenchida com a data atual (date_issue) e a data de termo (date_end) do período de validade com a data do dia seguinte à data atual.

Nas WERM, a secção respeitante à via navegável é indicada como um troço da via navegável entre dois pontos da via, ou seja, o espaço de aplicação da estação meteorológica (fluviómetro).

A data e a hora da medição/previsão devem ser fornecidas, ainda que tal não seja obrigatório nas mensagens WERM.

No caso de previsões, a «data de medição» é a data/hora para a qual a previsão é válida.

5.1. Preenchimento da secção «nts_number» nas mensagens WERM

No XSD 4.0 para NtS o número do NtS é opcional no caso das mensagens WERM. Se for fornecido, cada número deve ser único (Organização/Ano/Número/Série) para cada tipo de mensagem e compete ao organismo que fornece a WRM garantir que o seu número é único (não é necessário que os números sejam consecutivos).

5.2. Preenchimento da secção «weather_category_code» das mensagens WERM

A velocidade do vento indicada nos códigos de categorização das condições meteorológicas («weather_category_code»), com valores de 0 a 12, deve ser fornecida de acordo com a escala de Beaufort publicada pela Organização Meteorológica Mundial, no seu manual sobre serviços meteorológicos marinhos «WMO-No. 558».

A visibilidade deve ser indicada nos códigos de categorização das condições meteorológicas (valores 13 a 22) tal como definido no quadro seguinte:

Valor, significado Visibilidade Informações adicionais 13, nevoeiro cerrado menos de 50 metros 14, nevoeiro denso menos de 100 metros 15, nevoeiro moderado menos de 200 metros 16, nevoeiro menos de 1 000 metros O nevoeiro é constituído por gotículas de água. 17, névoa de 1 km a 4 km A névoa é constituída por gotículas de água. O termo «névoa» é utilizado em caso de «nevoeiro seco»; este fenómeno ocorre normalmente antes do nascer do sol. 18, bruma de 1 km a 4 km A bruma é constituída por partículas secas. 19, bruma leve de 4 km a 10 km 20, céu limpo de 10 km a 20 km 21, muito limpo sem limitações da visibilidade 22, ausência de nevoeiro A expressão «ausência de nevoeiro» é utilizada para indicar que não há nevoeiro de acordo com os requisitos nacionais/locais.

6. Processos das mensagens FTM

No Guia de Codificação de NtS para Editores descreve-se em que circunstâncias um editor de NtS cria uma nova FTM ou atualiza uma FTM existente. São aplicáveis os processos a seguir indicados:

6.1. Nova FTM

1) As aplicações de NtS podem facultar aos editores de NtS a. A utilização de avisos existentes como rascunhos para a criação de novas FTM e/ou b. A utilização de modelos de avisos para determinadas situações.

2) O conteúdo (por exemplo, período de validade ou restrições) tem de ser inscrito pelo editor em conformidade com os capítulos 3 e 4 do Guia de Codificação de NtS para Editores.

3) Quando um editor de NtS desencadeia a ação de publicação, a. É verificado se todos os conteúdos obrigatórios são fornecidos em conformidade com o XSD NtS (caso contrário, volta-se a 2), b. O número do NtS (nts_number) é gerado pela aplicação NtS, i. a «organização» é preenchida com o nome ou o código do organismo responsável, dependendo da função do utilizador que faz a publicação, ii. o «ano» é preenchido com o ano em curso, iii. é atribuído o «número» disponível seguinte, caso um número específico tenha sido introduzido pelo editor de NtS ou seja retomado um processo de aplicação utilizado na etapa 2, (visto dado que cada Organização/Ano/Número/Série) é único, conforme explicado no capítulo 15.1. iv. é atribuído o «número de série» 0 c. A secção «date_issue» é preenchida automaticamente com a data/hora efetiva da ação de publicação

6.2. Atualização/anulação de uma FTM existente

1) A mensagem publicada em causa deve ser selecionada para atualização na ferramenta de edição de FTM. A FTM original deve ser copiada ou alterada na base de dados (dependendo dos processos nacionais). a. Uma FTM expirada [que tenha passado o prazo de validade (validity_date_end)] deixa de poder ser atualizada e, nesse caso, o editor de NtS tem de criar uma nova FTM. b. O código de matéria «aviso anulado» só é utilizado se i. A data atual for anterior ao início do período de validade (validity_date_start). Caso só seja possível alterar o conteúdo do campo «informações adicionais na língua nacional», o conteúdo codificado da mensagem (etapa 2) deve permanecer inalterado. ii. O período de validade já tiver começado e a nova data de termo de todas as restrições já tiver passado. O fim do prazo de prescrição tem de ser indicado na data correta. c. Se um aviso for anulado, a data final do período de validade tem de coincidir com a data da anulação.

2) O conteúdo (por exemplo, período de validade ou restrições) deve ser alterado pelo editor em conformidade com os capítulos 3 e 4 do Guia de Codificação de NtS para Editores.

3) Quando um editor de NtS desencadeia a ação de publicar, a. É verificado se todos os conteúdos obrigatórios são fornecidos em conformidade com o XSD NtS (caso contrário, volta-se a 2), b. O número do NtS (nts_number) é gerado pela aplicação NtS, i. a «organização» mantém-se inalterada, ii. o «ano» mantém-se inalterado, iii. o «número» mantém-se inalterado, iv. o «número de série» é aumentado (aumento de 1) c. A secção «date_issue» é automaticamente preenchida com a data/hora da ação de publicação d. A FTM com o código de matéria «aviso anulado» (já) não deve ser tida em conta para a planificação da viagem.

6.3. FTM relativa à via navegável e/ou ao objeto

Uma FTM relativa à via navegável contém informações sobre um ou vários troços da via. Um troço de via navegável é definido na secção «fairway_section» pelos códigos ISRS de local dos seus extremos inicial e final.

Uma FTM relativa a um objeto contém informações sobre um ou vários objetos específicos presentes na via navegável. Um objeto é definido na parte «objeto» pelo seu código ISRS de local.

Uma FTM deve referir-se

— a um ou vários troços da via navegável ou

— a um ou vários objetos presentes num ou vários troços de via navegável

6.4. Ordenação automática dos códigos de restrição

As diferentes restrições têm impactos diferentes da navegação. A fim de permitir visualizar a restrição mais grave, por exemplo, numa lista de FTM, deve respeitar-se a ordem seguinte, a partir da restrição mais rigorosa com a classificação 1:

Classificação Valor Meaning (EN) 1 OBSTRU obstrução 2 PAROBS obstrução parcial 3 NOSERV interrupção do serviço 4 SERVIC mudança de serviço 5 VESDRA calado da embarcação 6 VESBRE largura do navio 7 CONBRE largura do comboio 8 VESLEN comprimento do navio 9 CONLEN comprimento do comboio 10 CLEHEI altura livre 11 VESHEI altura da embarcação 12 AVALEN comprimento disponível 13 CLEWID largura livre 14 AVADEP profundidade disponível 15 LEADEP profundidade mínima medida 16 DELAY demora 17 ALTER sentido alternado 18 TURNIN proibição de inverter marcha 19 PASSIN proibição de passar 20 OVRTAK proibição de ultrapassar 21 NOBERT proibição de atracar 22 NOMOOR proibição de amarrar 23 ANCHOR proibição de ancorar 24 SPEED limite de velocidade 25 WAVWAS proibição de criar ondulação 26 NOSHORE proibição de ir a terra 27 MINPWR potência mínima 28 CAUTIO precaução especial 29 NOLIM sem restrições

6.5. Tratamento do período de restrições

— As restrições que tenham os mesmos períodos de duração devem ser agrupadas, conjuntamente enumeradas ou combinadas para que a sua visualização seja facilmente compreensível.

— As ferramentas de edição de NtS devem disponibilizar uma função para evitar que os editores tenham de voltar a datilografar os períodos de restrição.

— Todas as restrições devem incluir o respetivo período com um código de intervalo, a fim de permitir a realização dos cálculos adequados nas aplicações de planificação da viagem. Para facilitar o trabalho dos editores de NtS podem implementar-se as funções seguintes: — A ferramenta de edição de NtS pode disponibilizar uma função de cópia das restrições já inscritas para evitar que o editor de NtS tenha de voltar a datilografar o período de restrições. — As ferramentas do editor de NtS podem disponibilizar uma função que permita selecionar mais de um código de restrição para um período específico e criar automaticamente as secções de restrição necessárias com base nas informações introduzidas pelo editor de NtS).

— Na expressão «segunda a sexta exceto feriados»: o valor «feriados» é muito difícil para as aplicações de planificação da viagem. É necessária uma lista de feriados de cada país para se fazerem cálculos corretos. Mesmo que tal lista não esteja disponível as respetivas restrições serão atribuídas aos dias feriados.

— O termo «excetuando»: não deve ser utilizado; os intervalos de interrupção devem ser indicados como períodos de restrição distintos dentro da mesma restrição, pelo que este código não deve ser mostrado/disponibilizado aos editores de avisos.

— Lógica e visualização da informação aplicável no caso do código de intervalo «contínuo»: <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> Se o período de restrições («interval_code») for contínuo a hora de início («start_time») pertence à data de início («start_date») e a hora de termo («end_time») à data de termo («end_date», por exemplo, das 06h00 de 1 de abril até às 10h00 de 30 de junho

— Lógica e visualização da informação aplicável a qualquer outro intervalo que não o «contínuo»: <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> Se o intervalo («interval_code») tiver outro valor, a hora de início («start_time») e a hora de termo («end_time») pertencem a este intervalo, por exemplo, entre 1 de abril e 30 de junho, de segunda a sexta, das 06h00 às 10h00.

— O termo do período de restrições deve ser sempre preenchido na última versão de uma mensagem.

7. Regras gerais de execução

Devem ter-se em conta os seguintes elementos:

— O quadro «GUI_labels» incluído nas Tabelas de Referência dos NtS deve ser tido em conta quando se elaboram as aplicações de NtS (campos de pesquisa, formulário de subscrição de correio eletrónico, visualização de mensagens).

— A data de termo («date_end») não pode ser anterior à data de início («date_start»).

— Os códigos que tiverem sido desativados (que deixarão de ser utilizados) através de pedidos de alteração de NtS (ver observações no XSD NtS) não devem ser mostrados aos editores de NtS aquando da criação de novas mensagens. Os códigos ainda são incluídos nas enumerações do XSD NtS para efeitos de retrocompatibilidade.

7.1. Preenchimento da secção relativa ao número («number_section»)

Cada número (Organização/Ano/Número/Série) tem de ser único para cada tipo de mensagem. Isto significa que mensagens de tipos diferentes podem ter o mesmo número NtS.

Para os utilizadores, os números das mensagens só são relevantes no caso das mensagens FTM e ICEM. No caso de todos os outros tipos de mensagens a visualização do número da mensagem pode ser omitida, dependendo dos requisitos nacionais.

Para os utilizadores, o número da mensagem deve ser mostrado no formato seguinte: «Tipo de mensagem/País/Organização/Ano/Número/Série» (a extensão pode ser encurtada consoante os filtros aplicados, se não se perderem informações).

7.2. Preenchimento dos elementos «from», «originator», «organisation» e «source»

O elemento «from» na secção «identificação» é preenchido com o nome do sistema nacional que fornece a mensagem (por exemplo, ELWIS, DoRIS, SLOVRIS, FLARIS).

O elemento «originator» corresponde ao organismo que introduz as mensagens nos sistemas nacionais.

O elemento «source» é a autoridade para a qual as FTM são publicadas.

O elemento «organisation» na secção «nts_number» é o nome da organização que atribui esse número (emissor de NtS).

7.3. Omissão de elementos

Os elementos que contenham unicamente valores normalizados ou por defeito devem ser omitidos se forem condicionais, uma vez que sobrecarregam a mensagem sem qualquer valor acrescentado.

Estão em causa os seguintes elementos:

— Destinatários: Grupo-alvo (target_group_code) ALL com direção (direction_code) ALL (se não existirem outros grupos-alvo específicos na mensagem),

— position_code: AL,

— reason_code: OTHER.

7.4. Preenchimento automático da secção «date_issue»)

Mensagens FTM e ICEM

Nas mensagens FTM e ICEM, o valor do elemento «date_issue» corresponde à data e hora efetivas da publicação. No caso de mensagens atualizadas, «date_issue» é a data e a hora em que a atualização foi publicada.

Mensagens WRM e WERM

Nas mensagens WRM e WERM o valor do elemento «date_issue» corresponde à data e hora do pedido de tratamento, porque podem existir várias medições com diferentes marcadores horários numa só mensagem W(E)RM.

7.5. Tratamento das informações relativas ao fuso horário nas mensagens NtS

Nas mensagens XML NtS, a data e a hora devem ser sempre indicadas na hora local, incluindo informações sobre o fuso horário.

As únicas exceções a esta disposição são os elementos «time_start» (hora de início) e «time_end» (hora de termo) na secção «limitation_period» (período de restrição). Estas exceções devem-se à possibilidade de aplicar um intervalo na secção relativa às restrições. Se a data de início e a data de termo tiverem regimes horários diferentes (por exemplo, CEST e CET) haverá uma alteração da informação relativa ao fuso horário neste intervalo. Esta alteração não pode ser expressa através de um único período de restrições. Em vez de se criarem períodos de restrição diferentes para cada alteração da hora, utiliza-se apenas um único período de restrições sem informação sobre o fuso horário, a fim de simplificar o tratamento e a transmissão da mensagem.

7.6. Tratamento dos segundos nas mensagens NtS

Regra geral, os segundos devem ser indicados nos campos para a data e a hora, mas não devem ser mostrados aos utilizadores de NtS. Os minutos são suficientes para a granularidade dos NtS.

7.7. Formato dos separadores decimais nas mensagens NtS

Nos campos numéricos, o separador decimal é o ponto (.). Não se utilizam separadores de milhares.

O número de casas decimais utilizadas para os valores deve ser limitado de modo a garantir uma visualização facilmente compreensível.

7.8. Unidades de medidas a utilizar nas mensagens NtS

Nas mensagens NtS só podem ser utilizadas as seguintes unidades de medida: cm, m3/s, h, km/h e kW, m/s (vento), mm/h (chuva) e grau Celsius. As aplicações podem converter as unidades de medida para facilitar a compreensão.

Caso as unidades de medidas introduzidas sejam diferentes das unidades de medida normalizadas, a aplicação deve converter os valores introduzidos em conformidade.

7.9. Regras aplicáveis aos elementos «name», «position_code» e «type_code»

O elemento «name» é automaticamente preenchido a partir dos dados de referência do Índice RIS relativos ao «national object name» (os editores de NtS podem alterar o nome previamente preenchido se algum requisito nacional o exigir). As convenções relativas à designação dos objetos constam da versão 2.0 ou superior do Guia de Codificação do Índice do RIS. No Guia de Codificação de NtS para Editores também se apresentam exemplos de designações de objetos adequadas.

O código de tipo é aditado ao objeto pela aplicação NtS em frente da designação do objeto.

A posição dos objetos é codificada através do código de localização e aditado ao objeto pela aplicação NtS a partir do RIS Index. Os editores podem alterar os códigos de tipo e de localização previamente preenchidos. Não deve ser atribuído um código de localização de objeto aos geo_objects na fairway_section.

Uma designação de objeto completa é composta pelo seu código de localização, o código de tipo e o nome.

Para facilitar o trabalho dos editores de NtS pode implementar-se nas ferramentas de edição NtS uma grelha de correspondências que ajude os editores a encontrar /selecionar os objetos adequados com base no código de função (function_code) do RIS Index ou no código de tipo (type_code) NtS:

Quadro 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. Regras aplicáveis ao elemento «fairway_name»

Para evitar a lógica/necessidade de aplicação de dados de referência adequados no sistema recetor (software que mostra o aviso ao utilizador) o elemento facultativo «fairway_name» (designação do canal navegável) deve ser sempre incluído no elemento «geo_object» (objeto geo-referenciado) e automaticamente preenchido pela aplicação NtS com o «nome da via navegável» do RIS Index. Os editores NtS não devem alterar o conteúdo do elemento «fairway_name».

7.11. Esclarecimentos para as traduções na folha de cálculo «reference_code» (referência)

Deve utilizar-se a seguinte definição para os valores de referência (reference_code) nas Tabelas de Referência NtS:

— NAP: Nos Países Baixos, a abreviatura NAP é utilizada e compreendida, não sendo traduzida

— KP: «nível de canal» deve traduzir-se na língua nacional

— FZP: só a abreviatura «FZP» deve ser utilizada (atualmente está praticamente em desuso)

— ADR: «Mar Adriático», deve traduzir-se na língua nacional

— TAW/DNG: «Tweede algemene Waterpassing» (neerlandês), «Deuzième Nivellement Général» (francês), trata-se da altura de referência utilizada na Bélgica para expressar as medições da altura. 0 é o valor médio do nível de água do mar na maré baixa em Ostende — Neerlandês: TAW — Francês: DNG — Todas as outras línguas: TAW/DNG

— LDC: «nível baixo da água, Comissão do Danúbio», deve traduzir-se na língua nacional,

— HDC: «nível alto da água, Comissão do Danúbio», deve traduzir-se na língua nacional,

— ETRS: «Sistema Europeu de Referência Terrestre de 1989», a abreviatura «ETRS89» é utilizada em todas as línguas

7.12. Recomendação para o elemento «coordenada»

Embora o elemento «coordenada» na secção relativa aos objetos geográficos seja condicional, as coordenadas geográficas devem ser fornecidas no WGS84 no formato [d]d mm.mmm[m] N (latitude) e [d][d]d mm.mmm[m] E (longitude). O objetivo é referenciar as mensagens NtS geograficamente.

7.13. Tratamento dos grupos-alvo

A secção relativa aos grupos-alvo é constituída pelo código dos grupos-a e o código de direção. Se ambos tiverem o valor ALL, toda a secção deve ser omitida se não existirem outros grupos-alvo específicos na mensagem. Se apenas for indicado um destes dois códigos, o outro deve ser preenchido com o valor por defeito ALL porque ambos os elementos são obrigatórios.

Podem encontrar-se mais informações relativas aos grupos-alvo no Guia de Codificação de NtS para Editores.

7.14. Visualização de mensagens válidas num dado momento

O período de validade (validity_period) deve ser utilizado pelas aplicações para selecionar as mensagens que devem ser mostradas aos utilizadores durante um determinado período.

Se o código de matéria (subject_code) for INFSER (serviço de informação), o período de validade é utilizado para indicar o tempo que a mensagem de serviço de informação está disponível para ser visualizada pelos utilizadores e não o período de validade das informações facultadas (por exemplo, 1 mês).

7.15. Funções opcionais para aumentar a facilidade de utilização das ferramentas de edição NtS

As funções a seguir descritas podem ser facultadas aos editores de NtS consoante os requisitos nacionais:

— As aplicações NtS podem facultar aos editores de NtS a possibilidade de guardar os rascunhos de mensagens NtS (não é necessário fornecer todos os conteúdos obrigatórios para esses rascunhos serem guardados)

— Podem aplicar-se perfis de utilizador diferentes aos diferentes editores (por exemplo, editores que são autorizados a introduzir/alterar avisos, editores que são autorizados a publicar avisos (para além da sua edição)

8. Estrutura de mensagem XML dos NTS

A estrutura de uma mensagem XML NtS e o conteúdo e finalidade dos dados nela contidos são definidos e explicados em pormenor no anexo C: Definição do esquema XML (XSD) NtS

9. O Serviço Web NTS

9.1. Objetivo

O Grupo de Peritos NtS identificou a tecnologia de serviço Web como um meio adequado para fornecer os avisos à navegação.

O presente capítulo constitui a especificação do serviço Web para o fornecimento dos avisos à navegação, a seguir denominado Serviço Web Nts. Nesta especificação, foi conferida especial ênfase à utilização de normas internacionais consolidadas.

Um dos objetivos deste projeto era garantir um equilíbrio adequado entre a flexibilidade e a solidez do serviço Web dele resultante. Os parâmetros de filtragem incorporados nos pedidos correspondem essencialmente aos critérios especificados na norma NtS (troço de via navegável com a indicação opcional da baliza quilométrica, período de validade e data de publicação do aviso). Esta opção afigura-se suficientemente expressiva, atendendo aos casos de utilização do serviço Web, ao mesmo tempo que reduz a complexidade da execução.

O resultado principal é um contrato de serviço Web em que se especificam os pedidos e as respostas. O contrato pode ser invocado pelos consumidores do serviço Web e os fornecedores são obrigados a cumpri-lo. O presente contrato é especificado utilizando a norma internacional WSDL.

Cada Estado-Membro participante deve executar um ou mais serviços Web para os diferentes tipos de mensagens NtS (FTM, WRM, ICEM, WERM) e prestá-los através da Internet («NtS Message Service» — Serviço de Mensagens NtS)

Os pormenores técnicos da execução do Serviço Web NtS, por exemplo, a escolha dos conjuntos de dados, aplicações e plataformas adequados, não estão incluídos no âmbito de aplicação da presente especificação e são da responsabilidade de cada Estado-Membro participante.

Para definir uma comunicação segura, devem ter-se em conta vários aspetos de segurança e objetivos de proteção, mas, dependendo das circunstâncias, nem todos estes aspetos têm de ser considerados. A sua prioridade e o seu grau de cumprimento podem variar. Além disso, a viabilidade de uma determinada medida pode ser limitada pela capacidade de execução a nível técnico. No contexto dos NtS, todas as informações são públicas, pelo que não há necessidade de proteger os próprios dados NtS no que à proteção de dados diz respeito. Por conseguinte, cada fornecedor deve decidir até que ponto este aspeto será aplicado no seu serviço.

9.2. Princípios básicos e condicionalismos

9.2.1. Normas Web

O Serviço Web NtS deve respeitar o Perfil Básico 1.1 da WS-I. Este perfil fornece orientações em matéria de interoperabilidade para um conjunto básico de especificações de serviços Web não exclusivos, tais como as especificações SOAP, WSDL e UDDI (1). As normas mais relevantes neste âmbito são:

— XML Schema Definition (XSD),

— Simples Object Access Protocol (SOAP),

— WSDL (Web Services Description Language) e

— Universal Description, Discovery and Integration (UDDI).

A mensagem de resposta do WS NtS é uma mensagem NtS definida na definição do esquema XML (XSD) no apêndice C do presente regulamento da Comissão.

SOAP é um protocolo de aplicação para a transmissão de dados entre sistemas informáticos normalizado pelo World Wide Web Consortium (W3C). Os elementos específicos do Serviço Web NtS são definidos de acordo com as especificações WSDL correspondentes no apêndice D do presente regulamento da Comissão. O esquema da norma NtS (XSD) é incluído com uma instrução de importação. UDDI (Universal Description, Discovery and Integration) é aqui referido como um registo central, eventualmente internacional, de serviços Web, onde o Serviço Web NtS pode ser registado. Os potenciais consumidores do serviço Web podem pesquisá-lo e encontrá-lo neste registo, mas, uma vez que os potenciais fornecedores do serviço Web NtS estão limitados pelos Estados-Membros participantes e a especificação WSDL faz parte integrante da norma, não há uma necessidade manifesta de um registo independente do serviço Web NtS.

9.2.2. Modelo de interação e método de codificação do WS NtS

O método de codificação Document-literal wrapped é utilizado no Serviço Web NtS porque permite a validação com base num esquema XML e os nomes de operações definidos na especificação WSDL são diretamente utilizados como nomes de marcadores XML nas mensagens SOAP.

9.3. Especificações e recomendações gerais

9.3.1. Especificação: Informação sobre as versões

A informação sobre a versão do Serviço Web NtS é composta por duas secções:

— versão do próprio serviço Web

— versão do esquema NtS utilizado pelo serviço Web

A secção do serviço Web propriamente dito é constituída por duas partes:

— a versão principal (MajorVersion) do serviço Web

— a versão secundária (MinorVersion) do serviço Web

O parâmetro MajorVersion é indicado por um número inteiro positivo que designa a versão principal do serviço Web.

O parâmetro MinorVersion é indicado por um número inteiro não negativo que designa a versão secundária do serviço Web dentro da versão principal.

A secção do esquema NtS descreve a versão deste esquema tal como definida pelo Grupo de Peritos NtS.

Assim, a versão do Serviço Web NtS aqui referida é a 2.0.4.0, sendo 2.0 a versão do serviço Web e 4.0 a versão do esquema NtS utilizado.

Não são necessárias informações explícitas sobre a versão nos pedidos ou respostas do Serviço Web NtS. Só um pequeno número de versões dos serviços deverá estar em linha em simultâneo. As diferentes versões devem ser fornecidas com diferentes endereços URL. Assim, cada instância de execução do Serviço Web NtS deve suportar uma versão específica do mesmo.

9.3.2. Especificação: Estrutura dos espaços de nomes

No Serviço Web NtS, os espaços de nomes (namespaces) são baseados no domínio Web dos Grupos de Peritos RIS, http://www.ris.eu/.

Os espaços de nomes contêm uma partícula que indica o serviço e a versão correspondentes. Deste modo, o serviço aqui especificado utiliza os seguintes espaços de nomes:

Serviço de Mensagens NtS: http://www.ris.eu/nts.ms/2.0.4.0

9.3.3. Recomendação: Utilização de espaços de nomes

Para uma maior transparência dos documentos XML, recomenda-se que os espaços de nomes sejam definidos no elemento mais adequado nos esquemas e nos documentos de instância e que não se utilizem definições locais dos espaços de nomes nos elementos encadeados.

9.3.4. Recomendação: Utilização de prefixos de espaços de nomes

Os pedidos e respostas no Serviço Web NtS devem utilizar os elementos XML de forma qualificada, ou seja com um prefixo de espaço de nome explícito, e atributos XML de forma não qualificada, ou seja, sem um prefixo de nome de espaço.

Recomenda-se a utilização de prefixos de espaços de nomes intuitivos como «nts» para uma melhor legibilidade pelo ser humano.

9.3.5. Especificação: Utilização dos ISRS Location Codes

O ISRS Location Code é explicado no capítulo 2 do Guia de Codificação de NtS para Informáticos bem como no Guia de Codificação do RIS Index.

Ao efetuar pesquisas num Serviço Web NtS, o cliente pode referenciar vários objetos, por exemplo, troços de via navegável, fluviómetros ou eclusas. Se os parâmetros correspondentes, os elementos de identificação, forem utilizados, devem incluir ISRS Location Codes. Estes parâmetros são normalmente fornecidos nos elementos de identificação, que contêm, cada um deles, um ou dois identificadores.

Ao utilizar estes parâmetros, devem respeitar-se as seguintes convenções gerais:

— Os códigos ISRS de local devem ser apresentados como códigos completos de 20 carateres, ou seja, sem truncar zeros significativos.

— Se forem utilizados dois identificadores num elemento de identificação, ambos os códigos ISRS de local têm de ser referentes à mesma via navegável. Isto significa que os códigos devem incluir alguns dígitos idênticos localizados na parte «fairway_section» (via navegável ou troço) do código ISRS de local. O código de via navegável em conjunto com o hectómetro do canal navegável define um troço indicado como um par de elementos de identificação.

Para indicar troços de via navegáveis (pares de elementos de identificação no objeto geo-referenciado da via navegável (fairway_section geo_object) nas mensagens NtS, há que ter em conta os seguintes aspetos relativos aos códigos ISRS de local:

— os dígitos 1 a 2 (Country code): — têm de ser idênticos no par de elementos de identificação, mas — num só par podem ser definidos diversos códigos de países, se países vizinhos utilizarem o mesmo código de canal navegável para uma via específica e o mesmo sistema para definir os hectómetros,

— os dígitos 3 a 5 (UN Location code): — não são pertinentes, podem ter diferentes conteúdos no par de elementos de identificação

— os dígitos 6 a 10 (Fairway section code): — devem ser idênticos no par de elementos de identificação, mas — [exceção]: no caso da utilização dos códigos ISRS belgas no âmbito do WS NtS, só se devem utilizar os dígitos 6 a 8 para identificar o troço de via navegável, porque serão publicados mensagens NtS em diferentes troços de uma via navegável,

— os dígitos 11 a 15 (Object Reference Code): — não são pertinentes, podem ter conteúdos diferentes dentro do par de elementos de identificação

— os dígitos 16 a 20 (Fairway Hectometre): — consistem em cinco carateres numéricos que definem o hectómetro, pelo que terão normalmente conteúdos diferentes no par de elementos de identificação. Exemplo: «00235» para o km 23,5 do canal navegável; «00001» para o km 0,1 do canal navegável, — [exceção]: no caso dos Países Baixos, nem sempre existe uma ligação direta entre o hectómetro de canal navegável e o quilómetro físico do canal navegável devido à definição do início do troço da via navegável no modelo da rede e no mundo real. Nesses casos, o código de referência de objeto para os objetos do tipo «dismar» começa com Kxxxx [xxxx inclui o quilómetro físico, por exemplo, NLSVG00130K000300191 (km 3)]. Porém, há outros tipos de objetos em que não existe qualquer relação direta com o quilómetro físico da via navegável nos códigos ISRS. Por exemplo, a ponte de Sas van Gent no km 2,5 da mesma via navegável tem o código ISRS NLSVG001300521600186. No caso do Kanaal Gent-Terneuzen o km físico 0,0 começa na fronteira entre a Bélgica e os Países Baixos e o hectómetro da via navegável 0,0 começa no início do canal em Gent.

Caso uma mensagem afete mais de um troço de via ou canal navegável, todos os troços devem ser definidos pelo seu ponto de início e de termo em elementos XML «fairway_section» separados.

No caso de alguns países/regiões é necessário introduzir uma funcionalidade de filtragem. Por exemplo, se o código ISRS de local (1-2) for BE, deve utilizar-se o código ISRS de local (6-8) como ID para uma referenciação linear com o hectómetro de via navegável (código ISRS de local 16-20). Exemplos de troços de via navegável (pares de elementos de identificação válidos na «fairway_section») que incluem as exceções acima definidas:

— Os dois códigos ISRS de local NL constituem uma definição válida de troço de via navegável (mostrando a exceção dos NL no que diz respeito ao quilómetro da via navegável): NLSVG00130K000300191 (km 3,0 em Sas van Gent no Kanaal Gent-Terneuzen) — NLWDP00130K000400200 (km 4,0 em Westdorpe no Kanaal Gent-Terneuzen),

— Os dois códigos ISRS de local BE constituem uma definição válida de troço de via navegável [mostrando a exceção da BE relativamente ao código de troço de canal navegável («020» Albertkanaal)]: BEGNK02016L010100414 (eclusa de Genk situada no km 41,4 no Canal Albert) — BEOSH02033L010500772 (eclusa de Ham situada no km 77,2 no Canal Albert).

O gráfico seguinte mostra exemplos contrários de utilização do código ISRS de local para cada uma das convenções gerais (não há exceções às convenções aplicáveis nos troços de vias navegáveis da SK):

Pesquisas de códigos ISRS de local inválidos

Observação geral: O Serviço Web Nts não suporta um serviço de pesquisa de códigos ISRS de local válidos. Os códigos ISRS de local são fornecidos no âmbito do Sistema de Gestão de Dados de Referência Europeu (ERDMS).

Nos cinco casos a seguir apresentados indica-se a forma correta de utilizar os códigos ISRS de local nas pesquisas e a sua interpretação.

Caso 1: Nenhum elemento de ID no pedido

O elemento de ID é uma parte opcional do pedido, ou seja, são permitidas pesquisas sem elementos de ID:

Pesquisa válida sem parâmetro de identificação

Se nenhum elemento de identificação for fornecido, todas as mensagens serão devolvidas [dependendo, naturalmente, de outros critérios de filtragem como o período de validade (validity_period) ou a data atual (date_issue)].

Caso 2: Um elemento de ID no pedido de informação

Cada elemento de identificação pode conter um ou dois identificadores. No gráfico seguinte apresenta-se um exemplo com um identificador:

Pesquisa válida com um parâmetro de ID

Se um tal pedido for recebido, o servidor deve devolver todas as mensagens correspondentes com um hectómetro de início ≤ ao valor indicado (240,7, no exemplo) e um hectómetro final igual ou superior a este valor. O gráfico infra ilustra esta seleção de mensagens: A localização pesquisada situa-se entre os valores dos hectómetros de início e de termo das mensagens 1, 3 e 4, que seriam devolvidas. As mensagens 2, 5 e 6 não se sobrepõem com a localização pesquisada, pelo que não seriam devolvidas.

Se o código ISRS de local indicado corresponder a um único objeto, por exemplo um fluviómetro ou uma eclusa, o serviço Web deve devolver as mensagens relativas a este objeto.

Mensagens correspondentes e não correspondentes a um parâmetro de identificação

Caso 3: Dois elementos de ID no pedido de informação

Cada elemento de identificação pode conter um ou dois identificadores. No gráfico seguinte apresenta-se um exemplo com dois identificadores:

Pesquisa válida com dois parâmetros de ID

Todos os valores de hectómetros pesquisados devem ser considerados válidos, mesmo que o troço de via navegável correspondente tenha pontos de início ou de termo diferentes. Por exemplo, se o troço de via navegável começar no hectómetro 100,0 e terminar no hectómetro 300,0, será válido um pedido relativo aos hectómetros 20,0 a 400,0. Internamente, é claro que só a «verdadeira» extensão do troço de via navegável é pesquisada.

Deste modo possibilita-se igualmente a pesquisa de todas as mensagens sobre uma via navegável sem conhecer exatamente a sua extensão em hectómetros (deve enviar-se o código ISRS de local com a indicação dos hectómetros como «00000» ou «99999», respetivamente).

Todas as mensagens correspondentes que intersetem o intervalo de hectómetros em causa serão devolvidas. O diagrama seguinte ilustra esta situação:

Mensagens correspondentes e não correspondentes para dois parâmetros de ID

A figura supra ilustra a definição de «interseção». Enquanto as extensões das mensagens 1 a 4 se sobrepõem à extensão do intervalo de hectómetros pesquisado (parcial ou totalmente), o mesmo não acontece com as mensagens 5 e 6, pelo que as mensagens 1 a 4 serão devolvidas e as 5 e 6 não.

A condição técnica para uma mensagem intersetar um intervalo [A e B] é a seguinte: O hectómetro inicial da mensagem é ≤ B e o seu hectómetro de termo ≥ A.

Combinação: Múltiplos elementos de ID num pedido de informação

Pesquisa válida com múltiplos elementos de identificação

A combinação de vários elementos de identificação no pedido de informação leva a uma união de mensagens correspondentes. Todos os elementos de ID são tratados separadamente e uma mensagem será devolvida se corresponder, pelo menos, a um deles. Por conseguinte, as mensagens a seguir indicadas serão devolvidas no caso do exemplo apresentado:

— Todas as mensagens relativas ao objeto com o código ISRS de local SKXXX0000010000***** com o hectómetro inicial = 0 e o hectómetro final ≥ 0 (ver Caso 2)

— Todas as mensagens relativas ao objeto com o código ISRS de local SKXXX0000500000***** que intersetam o intervalo de hectómetros [11,0 a 15,0] (ver Caso 3)

— Todas as mensagens relativas ao objeto com o código ISRS de local SKXXX0000200000***** com o hectómetro inicial ≤ 110,5 e o hectómetro final ≥ 110,5 (ver Caso 2)

— Todas as mensagens relativas ao objeto com o código ISRS de local SKXXX0000500000***** que intersetam o intervalo de hectómetros [220,0 a 300,0] (ver Caso 3)

9.4. Serviço de mensagens NtS (especificação da aplicação)

No presente capítulo, descreve-se a especificação da aplicação do NtS message service, deduzida das considerações e escolhas feitas nos capítulos precedentes.

O serviço de mensagens NtS disponibiliza quatro tipos de mensagens NtS:

1. NtS FTM (mensagem relativa à via navegável e ao tráfego)

2. NtS WRM (mensagem relativa à água)

3. NtS ICEM (mensagem relativa ao gelo)

4. NtS WERM (mensagem relativa às condições meteorológicas)

A aplicação do serviço de mensagens NtS pode suportar todos os tipos de mensagens ou apenas uma seleção dos mesmos. É permitido que um Estado-Membro participante preste, em relação a um determinado tipo de mensagem, vários serviços que se complementem mutuamente.

9.4.1. Pedido de informação

Para que o serviço Web NtS tenha a maior robustez possível mantendo simultaneamente um baixo nível de complexidade, não se utiliza qualquer linguagem de pesquisa adicional, aplicando-se, em vez disso, as estruturas conceptuais fornecidas pelo próprio WSDL. As operações específicas, em conjunto com os seus parâmetros, são integralmente descritas na especificação WSDL. No caso do Serviço de Mensagens NtS é definida uma única operação.

Os critérios de filtragem relativos a cada matéria são extraídos da norma NtS, mas alargados de modo a abranger a multiplicidade dos parâmetros:

— tipo de mensagem (obrigatório; «FTM», «WRM», «ICEM» ou «WERM»)

— troços de vias navegáveis específicos, ou partes dos mesmos, ou objetos específicos (opcional; descritos por códigos ISRS de local e/ou pares de códigos ISRS de local)

— período de validade (opcional; data de início e de termo)

— data de publicação do aviso (opcional; datas únicas e/ou intervalos de datas)

Só as mensagens que satisfaçam os critérios indicados são devolvidas pelo serviço.

Mecanismo de paginação

O serviço suporta um mecanismo de paginação para controlar a quantidade de dados. O parâmetro de paginação é definido com um tipo complexo que contém os seguintes elementos:

— offset: número de série da primeira mensagem devolvida (número inteiro ≥ 0)

— limite: número máximo de mensagens (número inteiro ≥ 0)

— contagem total: bandeira, se o número total de mensagens for devolvido (valor booleano)

O parâmetro de paginação complexa é opcional, mas se estiver presente, todos os elementos nele contidos devem ser fornecidos. Depois, o mecanismo de paginação funciona do seguinte modo:

O número total de mensagens não excederá o valor do parâmetro limite, com a exceção de que um valor de 0 significa «sem limite». A resposta salta todas as mensagens definidas no parâmetro offset. Para poder disponibilizar este mecanismo, o serviço tem de respeitar uma sequência das mensagens temporariamente estável (mas de outro modo arbitrária), por exemplo entre duas atualizações do conjunto de dados subjacente ao serviço Web com os dados das mensagens. Isto significa que duas chamadas idênticas consecutivas devem devolver as mesmas mensagens segundo a mesma ordem. O parâmetro contagem total determina se a resposta deve fornecer o número total de mensagens correspondentes aos critérios específicos. Normalmente, deverá ser suficiente pedir esta informação juntamente com a primeira resposta, omitindo-a em todas as respostas consecutivas. Deste modo, poderá obter-se um melhor desempenho do serviço Web.

O mecanismo de paginação permite solicitar as mensagens iterativamente em «páginas». Para que o mecanismo de paginação possa funcionar corretamente, devem fornecer-se os mesmos parâmetros específicos em cada chamada.

9.4.2. Resposta

Se um pedido for bem sucedido, a resposta do Serviço Web NtS contém as mensagens NtS correspondentes aos parâmetros do pedido. As mensagens NtS têm de respeitar o esquema NtS e podem ser validadas com base no mesmo. Uma vez que o tipo de mensagem é um parâmetro de pedido obrigatório, cada resposta só pode conter mensagens NtS do mesmo tipo, FTM, WRM, ICEM ou WERM, respetivamente.

Se o serviço detetar erros durante o tratamento do pedido pode devolver um número arbitrário de mensagens de erro, utilizando os códigos de erro indicados no subcapítulo seguinte.

Uma resposta de um serviço Web NtS pode conter mensagens NtS e mensagens de erro ao mesmo tempo.

As informações de paginação opcionais são devolvidas se o pedido contiver parâmetros de paginação. Neste caso, o parâmetro offset e o número de mensagens contidas são obrigatórios, a contagem total só tem de existir se for solicitada.

Nota: Parte-se do princípio de que a comunicação entre o serviço Web e o utilizador é estabelecida tecnicamente, isto é, o serviço recebe o pedido e o utilizador recebe a resposta correspondente. Erros técnicos, por exemplo, a interrupção da ligação à Internet ou a inacessibilidade do serviço Web devido a manutenção ou avaria não são aqui considerados. Só as situações de erro que ocorrem «por detrás» do nível do serviço Web percetível pelos utilizadores são aqui consideradas.

Mensagens de erro

Os códigos de erro utilizados nas situações de erro previstas são a seguir enunciados, juntamente com uma explicação. A resposta só contém o código de erro, que é o procedimento habitual no esquema XML do NtS.

Códigos de erro para o serviço de mensagens NtS

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. Geração de serviços e clientes

Se a abordagem «contrato primeiro» for respeitada de forma consequente, ou seja, se um ou mais contratos com descrições completas das interfaces forem facultados sob a forma de documentos WSDL, pode ser automaticamente gerada uma aplicação do(s) serviço(s), bem como uma aplicação de um cliente correspondente utilizando ferramentas de software adequadas. Numa situação ideal, não é necessário introduzir alterações manualmente no código-fonte gerado.

Contudo, na maior parte dos casos são necessárias várias repetições até a especificação WSDL cumprir os requisitos exatos de tais ferramentas. Normalmente, a ferramenta faz solicitações individuais à utilização da norma WSDL para funcionar bem. Em consequência, pode ser necessário fazer alterações à especificação WSDL, ainda que esta fosse à partida válida à luz da norma WSDL. Se a especificação WSDL do serviço Web for alterada depois de o serviço ou o cliente terem sido gerados, pode ser necessário um novo processo de geração, em função das alterações efetuadas.

Glossário

Termo Explicação ID Identificação ISRS Location Code Código de local da «International Ship Reporting Standard» (norma internacional de notificação de navios) NtS Avisos à navegação RIS Serviços de informação fluvial (River Information Services) SOAP Protocolo simples de acesso a objetos (Simple Object Access Protocol); protocolo de rede normalmente utilizado para serviços Web UDDI Universal Description, Discovery and Integration (descrição, pesquisa e integração universal); Norma para serviços de registo no contexto dos serviços Web ONU Organização das Nações Unidas URL Localizador uniforme de recursos (Uniform Resource Locator); localização de um recurso de rede normalmente utilizado para endereços Internet WGS 84 Sistema Geodésico Mundial 1984 WS Serviço Web; serviço que disponibiliza as suas interfaces na Internet e é utilizado pela comunicação via Internet WSDL Web Services Description Language (linguagem para descrição de serviços Web) norma para a especificação de serviços Web WS-I Web Services Interoperability Organisation; consórcio industrial que tem por objetivo apoiar a interoperabilidade dos serviços Web XML Linguagem de marcação extensível (Extensible Markup Language) Metalinguagem de representação dos dados estruturada e independente de plataformas XSD XML Schema Definition (definição de esquema XML ou modelo de mensagem XML) norma para especificar a estrutura dos documentos XML

(1) Descrição citada do sítio Web da WS-I: http://www.ws-i.org