A.   GUIDA ALLA CODIFICA DEGLI AVVISI AI NAVIGANTI PER I COMPILATORI

INDICE

Abbreviazioni

1.   Contesto, struttura e obiettivo delle guide alla codifica degli NtS

Lo standard NtS viene costantemente migliorato. Un passo in avanti decisivo si è registrato con l'introduzione del servizio web NtS che agevola lo scambio di messaggi NtS tra le autorità nonché tra autorità e utenti NtS.

Per agevolare la codifica armonizzata dei messaggi NtS a livello nazionale e internazionale sono stati elaborati due documenti: la guida alla codifica degli NtS per i compilatori e la guida alla codifica degli NtS per gli sviluppatori di applicazioni. Tali guide si applicano all'NtS XSD 4.0 e al servizio web NtS WSDL 2.0.4.0.

In considerazione del crescente utilizzo del servizio web NtS, i messaggi NtS devono essere ulteriormente armonizzati per garantire la corretta visualizzazione del contenuto su sistemi di terzi. La codifica uniforme dei messaggi costituisce inoltre un prerequisito per la presa in considerazione dei messaggi nelle applicazioni di pianificazione dei viaggi.

Gli elementi contenenti unicamente valori standard o preimpostati devono essere omessi qualora siano facoltativi, poiché provocano una produzione eccessiva di messaggi privi di valore aggiunto.

La Guida alla codifica degli NtS per i compilatori è destinata a coloro che compilano (e pubblicano) i messaggi NtS e comprende istruzioni passo a passo per la creazione degli tipi di messaggi corretti nonché una spiegazione dei codici. La guida alla codifica degli NtS illustra l'applicabilità dei quattro tipi di messaggi NtS e fornisce le istruzioni per la compilazione e i codici da utilizzare in determinati eventi. La guida alla codifica degli NtS per i compilatori è contenuta nella presente appendice A.

La guida alla codifica degli NtS per gli sviluppatori di applicazioni contiene orientamenti per lo sviluppo e l'implementazione dell'applicazione NtS che ne spiegano la logica, i processi e i valori automatici/preimpostati. La guida alla codifica degli NtS per gli sviluppatori di applicazioni è contenuta nell'appendice B dell'allegato del presente regolamento.

2.   Selezione del tipo di messaggio NtS

3.   Considerazioni fondamentali in merito agli FTM, fasi per la pubblicazione di un FTM

Informazioni dettagliate sui codici da utilizzare sono contenute nel capitolo 4. Le considerazioni formulate dal punto 3.3 in poi non compaiono necessariamente nell'ordine di inserimento di uno strumento di compilazione degli FTM.

4.   Spiegazione dei codici FTM

4.1.   Subject_code

Definizione di uso dei codici oggetto:

4.2.   Reason_code

Il codice motivazione dovrebbe essere compilato per fornire informazioni supplementari agli ufficiali in comando.

Definizione di uso dei codici motivazione

4.3.   Limitation_code

Definizione di uso dei codici restrizione

4.4.   Limitation interval_code Definizione di uso dei codici intervallo

4.5.   Indication_code

L'indication_code è inteso a fornire informazioni su valori specifici concernenti determinate restrizioni (ad es. limite di velocità, potenza minima, tirante d'acqua). Per determinare talune dimensioni è necessario un riferimento a un sistema di riferimento esterno, geografico o idrologico (ad es. tirante d'aria, tirante d'acqua, profondità minima rilevata), oppure a dimensioni note di strutture artificiali (ad es. lunghezza disponibile, larghezza massima della via navigabile).

4.6.   Position_code (oggetti)

Ove possibile il Position_code deve riferirsi al lato del canale navigabile in cui è situato l'oggetto rispetto all'asse del canale navigabile (sinistro/centrale/destro) o ad altre informazioni comunemente note (vecchio/nuovo) o alla direzione geografica (nord/sud/est/ovest). Il position_code per gli oggetti può essere precompilato automaticamente con i dati di riferimento dell'indice RIS. Il lato sinistro/destro del canale navigabile si definisce guardando a valle.

4.7.   Position_code (canali navigabili/vie navigabili)

Non viene fornito un Position_code per un FTM (o parte di un FTM) riguardante un canale navigabile o una via navigabile. Per indicare il lato del canale navigabile/canale/fiume/lago in cui si è verificato un incidente, viene usata la restrizione «particolare cautela» in combinazione con il Position_code della restrizione pertinente.

4.8.   Position_code (restrizioni)

4.9.   Target_group_code (cfr. capitolo 3.5)

4.10.   Reporting_code

4.11.   Communication_code

Occorre utilizzare il formato seguente (esempi):

4.12.   Type_code

Una via navigabile è un canale, un lago oppure un fiume:

5.   Considerazioni fondamentali in merito ai WRM

In linea generale i messaggi riguardanti le acque sono generati automaticamente. Ove ciò non sia possibile i WRM sono generati manualmente seguendo, con la maggiore precisione possibile, i processi fissati per i WRM generati automaticamente (cfr. guida alla codifica degli NtS per gli sviluppatori).

6.   Considerazioni fondamentali in merito agli ICEM, fasi per la pubblicazione di un ICEM

I messaggi relativi al ghiaccio dipendono da osservazioni e valutazioni locali e saranno di norma generati da personale autorizzato.

Un ICEM è emesso in caso di ghiaccio. Il ghiaccio non causa necessariamente restrizioni alla navigazione, ma è possibile comunicare informazioni sulle condizioni del ghiaccio che non ostacolano la navigazione.

7.   Considerazioni fondamentali in merito ai WERM

Tenendo conto dell'abbondanza di applicazioni e servizi web disponibili per previsioni e allerte meteorologiche, i WERM dovrebbero essere usati solo per informazioni meteorologiche di importanza specifica per la navigazione, non comunicate dai servizi generali di informazioni meteorologiche.

In linea generale i messaggi di tipo meteorologico sono generati automaticamente. Ove ciò non sia possibile i WERM sono generati manualmente seguendo, con la maggiore precisione possibile, i processi fissati per i WERM generati automaticamente (cfr. guida alla codifica degli NtS per gli sviluppatori di applicazioni).

8.   Norme per determinati elementi

8.1.   Norme per l'elemento «denominazione» relativo agli oggetti

Le denominazioni degli oggetti sono di norma precompilate dallo strumento di compilazione NtS sulla base dei dati di riferimento dell'indice RIS. Le denominazioni sono inserite nella lingua locale; possono quindi essere utilizzati anche segni diacritici o lettere cirilliche (ad esempio Baarlerbrücke, Volkeraksluis o Mannswörth).

Non inserire informazioni sulle caratteristiche dell'oggetto; il tipo dell'oggetto non va ripetuto nella denominazione a meno che non fornisca informazioni supplementari sul tipo di oggetto.

Esempio: la conca «Schleuse Freudenau» è denominata solo «Freudenau»; il tipo di oggetto «conca» è aggiunto automaticamente sulla base del type_code.

Esempio: la denominazione dell'oggetto per il ponte ferroviario di Krems (AT) è «Eisenbahnbrücke Krems». L'informazione «ponte ferroviario» è inclusa nella denominazione dell'oggetto in quanto aggiunge informazioni supplementari al type_code «ponte».

Esempio: la denominazione dell'oggetto per un ponte di Linz (AT) è «Nibelungenbrücke». La parola «Brücke» rimane nella denominazione dell'oggetto in quanto fa parte del nome del ponte.

Esempio: l'idrometro sulla via navigabile «Pegelstelle Wildungsmauer» è denominato «Wildungsmauer» poiché l'informazione secondo cui quest'oggetto è un idrometro è già codificata nel type_code.

Se una sezione di via navigabile costituisce la linea di frontiera tra due paesi di lingua diversa, la denominazione dell'oggetto può essere fornita nelle lingue di entrambi i paesi (ad es. «Staatsgrenze AT-SK/Statna hranica AT-SK»).

8.2.   Norme per l'elemento «denominazione» relativo ai canali navigabili

Le denominazioni dei canali navigabili sono di norma precompilate dallo strumento di compilazione NtS sulla base dei dati di riferimento dell'indice RIS. Il campo «denominazione» deve contenere la denominazione locale della rispettiva sezione di canale navigabile (ad es. «Rhein»). A seconda dei processi nazionali può essere consentito compilare la denominazione del canale navigabile inserendovi denominazioni o aggiunte locali di uso comune (ad es. «Rhein am Deutschen Eck»).

8.3.   Norme per gli elementi «valore» e «unità» nell'ambito delle restrizioni

Salvo diversamente specificato, nei messaggi NtS le uniche unità di misura consentite sono cm, m3/s, h, km/h e kW, m/s (vento), mm/h (pioggia) e gradi Celsius.

B.   GUIDA ALLA CODIFICA DEGLI AVVISI AI NAVIGANTI PER GLI SVILUPPATORI DI APPLICAZIONI

INDICE

1.   Contesto e struttura

Gli avvisi ai naviganti (NtS) sono in corso di attuazione in vari paesi europei sulla base del regolamento (CE) n. 416/2007 della Commissione concernente le specifiche tecniche relative agli avvisi ai naviganti di cui all'articolo 5 della direttiva 2005/44/CE del Parlamento europeo e del Consiglio, relativa ai servizi armonizzati d'informazione fluviale (RIS) sulle vie navigabili interne della Comunità. Lo standard NtS viene costantemente migliorato: un passo in avanti decisivo si è registrato con l'introduzione del servizio web NtS che agevola lo scambio di messaggi NtS tra le autorità nonché tra autorità e utenti NtS, come pure con l'NtS XSD 4.0, che razionalizza la codifica dei messaggi NtS.

1.1.   Obiettivi della guida alla codifica degli NtS

La guida alla codifica degli NtS illustra l'applicabilità dei quattro tipi di messaggio NtS e fornisce i codici da utilizzare in taluni eventi. Offre ai compilatori NtS istruzioni per redigere i messaggi NtS, permettendo così di codificare tali messaggi in maniera armonizzata a livello nazionale e internazionale.

In considerazione del crescente utilizzo del servizio web NtS, i messaggi NtS devono essere ulteriormente armonizzati per garantire la corretta visualizzazione del contenuto su sistemi di terzi. La codifica uniforme dei messaggi costituisce inoltre un prerequisito per la presa in considerazione dei messaggi nelle applicazioni di pianificazione del viaggio. L'NtS Encoding Guide (guida alla codifica degli NtS) versione 1.0 si applica all'NtS XSD 4.0 e al servizio web NtS WSDL 2.0.4.0.

1.1.1.   Guida alla codifica degli NtS per i compilatori

La Guida alla codifica degli NtS per i compilatori è destinata al personale che compila (e pubblica) i messaggi NtS e comprende istruzioni passo a passo per la creazione dei tipi di messaggi corretti nonché una spiegazione dei codici. La guida alla codifica per i compilatori contiene informazioni importanti anche per gli sviluppatori di applicazioni.

1.1.2.   Guida alla codifica NtS per gli sviluppatori di applicazioni (il presente documento)

La guida alla codifica degli NtS per gli sviluppatori contiene orientamenti per l'implementazione dell'applicazione NtS che ne spiegano la logica, i processi e i valori automatici/preimpostati.

2.   Messaggi NtS e loro sezioni

Un messaggio NtS consiste nelle seguenti sezioni:

Figura 2

Visualizzazione della struttura del messaggio NtS: elemento obbligatorio (1), elemento obbligatorio che può verificarsi una o più volte (1…2), elemento obbligatorio che deve verificarsi due volte (2), elementi obbligatori che possono verificarsi tutte le volte necessarie (1-n), elemento facoltativo che può verificarsi tutte le volte necessarie (0…n)

La sezione di identificazione è obbligatoria e contiene informazioni generali sull'origine, sul mittente, sulla data di emissione, sullo Stato interessato e sulla lingua originale del messaggio e viene fornita insieme a uno dei quattro diversi tipi di sezione di messaggio NtS.

Inoltre il codice di localizzazione ISRS (International Ship Reporting Standard — Standard internazionale di segnalazione navale) è usato per definire l'oggetto/gli oggetti o la sezione/le sezioni di canale navigabile applicabili cui fa riferimento il messaggio.

Il codice di localizzazione ISRS è definito al punto 4.3 dell'allegato del presente regolamento.

3.   Considerazioni fondamentali in merito ai WRM

Le informazioni sul livello idrometrico sono estremamente importanti per la pianificazione del viaggio oltre che per la sicurezza. Attualmente non esiste uno standard comune di riferimento per le informazioni sul livello idrometrico. I dati idrometrici si basano su livelli sopra il mare variabili o su punti di riferimento particolari. Per offrire un riferimento valido, occorre sempre fornire il rispettivo «reference_code» insieme al valore. Un WRM può essere usato per comunicare le seguenti informazioni:

Clarifications for translations in the spreadsheet «reference_code» Chiarimenti in merito alle traduzioni del foglio elettronico «reference_code» sono contenuti nel capitolo 7.11.

Di norma i WRM vengono creati e pubblicati automaticamente sulla base di informazioni ricevute da sensori o da infrastrutture (ad esempio previsioni, stato dello sbarramento). La pubblicazione dei WRM può dipendere da diverse cause: ad esempio può essere periodica oppure può scattare al raggiungimento di determinati valori.

3.1.   Compilazione della sezione nts_number nel WRM

Nell'NtS XSD 4.0 il numero dell'NtS è facoltativo all'interno dei messaggi WRM. Se comunicato, ogni numero deve essere unico (Organizzazione/Anno/Numero/Numero progressivo) per tipo di messaggio ed è compito dell'organizzazione che comunica i WRM garantire l'unicità dei numeri (non è necessario che i numeri siano consecutivi).

3.2.   Compilazione dei WRM contenenti previsioni

Nella date_start of validity_period si deve inserire la data di compilazione (date_issue) e nella date_end of validity_period si deve inserire la data del giorno seguente alla date_issue.

Per comunicare i cambiamenti (ad es. del livello idrometrico) in maniera facilmente leggibile, nella sezione differenza del WRM si può inserire la differenza rispetto a una precedente rilevazione comparativa. Oltre al cambiamento di valore (ad es. — 5 [cm]) è necessario indicare anche il periodo di tempo trascorso rispetto alla rilevazione comparativa.

In caso di previsioni la «measure_date» è la data/l'ora per cui è valida la previsione.

Le previsioni relative al livello idrometrico comportano sempre un fattore di incertezza. Di norma si calcolano modelli contenenti parametri diversi (ad es. previsioni meteorologiche), che producono differenze nei valori previsti per il livello idrometrico. Per consentire la segnalazione di un valore di previsione minimo e massimo (ad es. la visualizzazione dell'intervallo di confidenza di un livello idrometrico previsto, nella sezione «measure» del WRM sono inseriti due campi di dati facoltativi supplementari.

La figura seguente illustra l'intervallo di confidenza di un livello idrometrico previsto:

Figura 3

Visualizzazione dell'intervallo di confidenza di un livello idrometrico previsto: valore altamente probabile (nero), intervallo di confidenza nella fascia superiore (viola), intervallo di confidenza nella fascia inferiore (rosso), livello idrometrico misurato (azzurro).

(L'asse delle ascisse esprime l'ora; l'asse delle ordinate esprime il livello idrometrico in cm)

Nell'NtS XSD sono disponibili due elementi:

Oltre che per prevedere i livelli idrometrici, l'intervallo di confidenza può anche essere usato per segnalare l'incertezza delle informazioni pubblicate in merito alla profondità minima rilevata e al tirante d'aria.

Il value_min e il value_max dell'intervallo di confidenza consentono di comunicare l'intervallo di confidenza del valore WRM tramite un messaggio NtS WRM standardizzato da utilizzare poi in grafici. I dati grezzi non devono essere visualizzabili dagli utenti IWT (ad es. in formato codice).

Il measure_code «NOM» non deve essere usato. Qualora non esistano rilevazioni per un determinato tipo di WRM, se si vuole comunque spedire il messaggio occorre omettere gli elementi di valore.

4.   Processi ICEM

I messaggi relativi al ghiaccio dipendono da osservazioni e valutazioni locali e saranno di norma generati manualmente (se sono generati automaticamente si devono seguire le regole della creazione manuale, cfr. guida alla codifica degli NtS per i compilatori).

L'ICEM è pubblicato per una determinata fairway_section definita dai propri codici di localizzazione ISRS di inizio e fine e contiene l'ice_condition a una determinata data di rilevazione.

La validità dell'ICEM ha inizio alla data di pubblicazione (fissata automaticamente dall'applicazione NtS). Per evitare che gli utenti visualizzino ICEM non più validi, la date_end di validità deve essere compilata automaticamente dall'applicazione NtS indicando il giorno successivo alla pubblicazione (a meno che i processi nazionali non garantiscano che i messaggi riceveranno una data di fine validità non appena le informazioni contenute nel messaggio non sono più aggiornate).

La guida alla codifica degli NtS per i compilatori descrive le circostanze in cui un compilatore NtS crea un nuovo ICEM o aggiorna un ICEM esistente. Si applicano i processi descritti di seguito.

4.1.   Nuovo ICEM

4.2.   Aggiornamento di un ICEM esistente

5.   Considerazioni fondamentali in merito ai WERM

Di norma i WERM vengono creati e pubblicati automaticamente sulla base di informazioni ricevute da sensori o da infrastrutture. Nella date_start of validity_period si deve inserire la data di compilazione (date_issue) e nella date_end of validity_period si deve inserire la data del giorno seguente alla date_issue.

Nei WERM la sezione di canale navigabile è indicata come un tratto tra due punti del canale navigabile, ossia l'area di applicabilità della stazione meteorologica (idrometro).

È necessario indicare data e ora della rilevazione/previsione, anche se ciò non è obbligatorio nei messaggi WERM.

In caso di previsioni la «measure date» è la data/l'ora per cui è valida la previsione.

5.1.   Compilazione della sezione nts_number nel WERM

Nell'NtS XSD 4.0 il numero dell'NtS è facoltativo all'interno dei messaggi WERM. Se comunicato, ogni numero deve essere unico (Organizzazione/Anno/Numero/Numero progressivo) per tipo di messaggio ed è compito dell'organizzazione che comunica i WERM garantire l'unicità dei numeri (non è necessario che i numeri siano consecutivi).

5.2.   Compilazione del «weather_category_code» WERM

Nel «weather_category_code» la velocità del vento (valori da 0 a 12) deve essere comunicata conformemente alla scala Beaufort pubblicata dall'Organizzazione meteorologica mondiale nel suo Manual on Marine Meteorological Services (Manuale dei servizi meteorologici marini) «WMO n. 558».

Nel «weather_category_code» la visibilità (valori da 13 a 22) deve essere comunicata sulla base della tabella riportata di seguito.

6.   Processi FTM

La guida alla codifica degli NtS per i compilatori descrive le circostanze in cui un compilatore NtS crea un nuovo FTM o aggiorna un FTM esistente. Si applicano i processi descritti di seguito.

6.1.   Nuovo FTM

6.2.   Aggiornamento/revoca di un FTM esistente

6.3.   FTM riguardanti vie navigabili e/o oggetti

Un FTM riguardante una via navigabile contiene informazioni su uno o più tratti di via navigabile. Un tratto di via navigabile è definito nella parte «fairway_section» in base ai codici di localizzazione ISRS di inizio e di fine del tratto.

Un FTM riguardante un oggetto contiene informazioni su uno o più oggetti specifici presenti sulla via navigabile. Un oggetto è definito nella parte «object» dal suo codice di localizzazione ISRS.

Un FTM deve riferirsi

6.4.   Ordine automatico dei codici di restrizione

Restrizioni diverse hanno conseguenze diverse sulla navigazione. Per consentire la visualizzazione delle restrizioni più rigorose (ad es. in una panoramica concernente un elenco di FTM), occorre seguire l'ordine seguente, che inizia con la restrizione più rigorosa collocata al primo posto:

6.5.   Gestione del periodo di restrizione

7.   Norme generali di attuazione

Si deve tenere conto dei seguenti fattori:

7.1.   Compilazione della «number_section»

Ogni numero (Organizzazione/Anno/Numero/Numero progressivo) deve essere unico per tipo di messaggio. Ciò significa che messaggi di tipi diversi possono avere lo stesso numero NtS.

Per gli utenti i numeri dei messaggi sono pertinenti solo per gli FTM e gli ICEM; per tutti gli altri tipi di messaggio la visualizzazione del numero del messaggio può essere omessa, a seconda delle prescrizioni nazionali.

Il numero del messaggio deve essere visualizzabile dagli utenti nel formato seguente «Message Type/Country/Organisation/Year/Number/Serial» (può essere abbreviato in funzione dei filtri applicati se non va persa nessuna informazione).

7.2.   Compilazione degli elementi «from», «originator», «organisation» e «source»

L'elemento «from» nella sezione identificazione è compilato con il nome del sistema nazionale che comunica il messaggio (ad es. ELWIS, DoRIS, SLOVRIS, FLARIS).

L'elemento «originator» è l'organizzazione che inserisce i messaggi nei sistemi nazionali.

L'elemento «source» è l'autorità per cui sono pubblicati gli FTM.

L'elemento «organisation» nella sezione nts_number è il nome dell'organizzazione che assegna l'nts_number (Fornitore NtS).

7.3.   Omissione di elementi

Gli elementi contenenti unicamente valori standard o preimpostati devono essere omessi se sono facoltativi, poiché provocano una produzione eccessiva di messaggi privi di valore aggiunto.

Sono interessati i seguenti elementi:

7.4.   Compilazione automatica di date_issue

FTM e ICEM

Per FTM e ICEM il valore dell'elemento date_issue è rappresentato dalla data e dall'ora effettive di pubblicazione. Nel caso di messaggi aggiornati, date_issue corrisponde alla data e all'ora della pubblicazione dell'aggiornamento.

WRM e WERM

Per WRM e WERM il valore dell'elemento date_issue è rappresentato dalla data e dall'ora della richiesta di trattamento, poiché possono esistere numerose rilevazioni con indicazioni temporali diverse all'interno di un messaggio W(E)RM.

7.5.   Gestione delle informazioni sul fuso orario nei messaggi NtS

Nei messaggi NtS XML, data e ora devono sempre essere espresse in ora locale, specificando il fuso orario.

Le uniche eccezioni a questa disposizione sono il «time_start» e il «time_end» nella sezione «limitation_period». Ciò dipende dal fatto che nella sezione restrizioni può essere introdotto un intervallo. Se la data d'inizio e la data di fine hanno fusi orari diversi (ad es. CEST e CET), ciò comporta una modifica dell'informazione sul fuso orario entro tale intervallo. Tale modifica non può essere espressa per mezzo di un unico periodo di restrizione. Anziché creare periodi di restrizione diversi per ciascun cambio dell'ora, si applica un unico periodo di restrizione senza l'informazione sul fuso orario per evitare un eccesso di informazioni nel trattamento e nella trasmissione dei messaggi.

7.6.   Gestione dei secondi nei messaggi NtS

In linea generale i campi (data)/ora devono indicare i secondi, che però non devono essere visualizzabili dagli utenti NtS. Per la granularità degli NtS sono sufficienti i minuti.

7.7.   Formato dei decimali nei messaggi NtS

Nei campi numerici, i decimali sono indicati con un . (punto). Non si usano separatori per le migliaia.

Il numero di decimali usato per i valori è limitato a una quantità ragionevole per assicurare una visualizzazione agevole.

7.8.   Unità di misura da impiegare nei messaggi NtS

Nei messaggi NtS le uniche unità di misura consentite sono cm, m3/s, h, km/h e kW, m/s (vento), mm/h (pioggia) e gradi Celsius; le applicazioni possono convertire le unità di misura per comodità dell'utente.

Qualora le unità immesse differiscano dalle unità standardizzate, l'applicazione dovrà opportunamente convertire i valori inseriti.

7.9.   Norme per gli elementi «name», «position_code» e «type_code»

L'elemento «name» deve essere precompilato automaticamente in base ai dati di riferimento dell'indice RIS «national object name» (i compilatori NtS potrebbero modificare il nome predefinito se ciò costituisce una prescrizione nazionale). Le convenzioni per la denominazione degli oggetti sono inserite nella guida alla codifica dell'indice RIS versione 2.0 o superiore. Anche la guida alla codifica degli NtS per i compilatori contiene esempi di denominazioni adeguate per gli oggetti.

Il type code viene aggiunto all'oggetto dall'applicazione NtS davanti alla denominazione dell'oggetto.

La posizione degli oggetti è codificata tramite il position code e aggiunta all'oggetto dall'applicazione NtS, che la ricava dall'indice RIS. I compilatori possono modificare i codici tipo e posizione predefiniti. Per i geo_objects nella fairway_section non occorre fornire un codice posizione per l'oggetto.

La denominazione completa dell'oggetto è composta da position code, type code e name.

Per facilitare il lavoro dei compilatori NtS, negli strumenti di compilazione NtS si può introdurre la seguente mappatura, che aiuterà i compilatori a trovare/selezionare gli oggetti adatti sulla base del function_code dell'indice RIS o del type_code NtS:

Tabella 1

Corrispondenza «function_code dell'indice RIS» — «type_code NtS»

7.10.   Norme per l'elemento «fairway_name»

Per evitare la logica applicativa / la necessità di dati di riferimento appropriati al sistema ricevente (software che visualizzi l'avviso all'utente), l'elemento facoltativo «fairway_name» deve essere sempre incluso nel «geo_object» e automaticamente compilato dall'applicazione NtS con il «Waterway name» tratto dall'indice RIS. I compilatori NtS non devono modificare il contenuto dell'elemento fairway_name.

7.11.   Chiarimenti in merito alle traduzioni del foglio elettronico «reference_code»

Per i valori del reference_code forniti nelle tavole di riferimento NtS si usano le seguenti definizioni:

7.12.   Raccomandazione per l'elemento «coordinate»

Benché l'elemento coordinate nella sezione geo object sia facoltativo, le coordinate geografiche sono fornite nel WGS84 in formato [d]d mm.mmm[m] N (latitudine) e [d][d]d mm.mmm[m] E (longitudine). Ciò serve per il riferimento geografico dei messaggi NtS.

7.13.   Gestione dei gruppi di destinatari

La sezione gruppo di destinatari consiste nel codice gruppo di destinatari e nel codice direzione. Se entrambi hanno il valore ALL, occorre omettere l'intera sezione qualora il messaggio non contenga altri gruppi di destinatari specifici. Se uno solo dei due è comunicato, l'altro deve essere compilato con il valore di default ALL poiché entrambi gli elementi sono obbligatori.

Ulteriori informazioni sui gruppi di destinatari sono reperibili nella guida alla codifica degli NtS per i compilatori.

7.14.   Visualizzazione di messaggi validi in un momento determinato

Il validity_period deve essere utilizzato dalle applicazioni per selezionare i messaggi, che devono essere visualizzabili dagli utenti per il periodo di tempo richiesto.

Se il subject_code è INFSER (servizio informazioni), il periodo di validità è usato per specificare il tempo durante il quale il messaggio del servizio informazioni è visualizzabile dagli utenti, non per indicare il periodo di validità delle informazioni comunicate (ad es. 1 mese).

7.15.   Funzioni facoltative per agevolare l'utilizzo di strumenti di compilazione NtS

A seconda delle prescrizioni nazionali, ai compilatori NtS possono essere offerte le seguenti funzioni:

8.   Struttura del messaggio NtS XML

La struttura del messaggio NtS XML, insieme al contenuto e all'obiettivo degli elementi di dati, sono definiti e ulteriormente illustrati nell'appendice C: definizione dello schema NtS XML (XSD).

9.   Servizio web NtS

9.1.   Obiettivo

Il gruppo di esperti NtS ha individuato nella tecnologia del servizio web un mezzo appropriato per comunicare gli avvisi ai naviganti.

Il presente capitolo rappresenta la specifica del servizio web per la comunicazione degli avvisi ai naviganti (abbreviato in Servizio web NtS). È stata posta particolare enfasi sull'uso di norme internazionali ben consolidate.

Uno degli obiettivi del progetto concettuale era quello di assicurare il corretto equilibrio tra flessibilità e solidità del servizio web risultante. I parametri di filtro forniti nelle richieste sono essenzialmente i criteri specificati nello standard NtS (sezione di via navigabile, eventualmente con punti chilometrici del fiume, periodo di validità, data di pubblicazione dell'avviso). Ciò sembra sufficientemente eloquente, considerando i casi di utilizzo del servizio web, e al tempo stesso rende l'attuazione meno complessa.

Il risultato essenziale è un contratto per il servizio web, in cui sono specificate le richieste e le risposte. I consumatori del servizio web possono fare affidamento su questo contratto e i fornitori sono tenuti a rispettarlo. Il contratto è specificato utilizzando lo standard internazionale WSDL.

Ciascuno Stato membro partecipante attua uno o più servizi web per i differenti tipi di messaggio NtS (FTM, WRM, ICEM, WERM) e li fornisce via Internet («Servizio Messaggi NtS»).

I dettagli tecnici per l'implementazione del servizio web NtS (ad es. la scelta degli insiemi di dati, delle applicazioni e delle piattaforme appropriati) esulano dalla portata di questa specifica e sono di responsabilità di ciascuno Stato membro partecipante.

Per definire una comunicazione sicura occorre considerare vari aspetti legati alla sicurezza e alla protezione degli obiettivi. A seconda delle circostanze, non è necessario tenere conto di tutti questi aspetti. La priorità dei vari aspetti legati alla sicurezza e la misura in cui devono essere completati possono variare. Anche la fattibilità di un determinato provvedimento può essere limitata dalle capacità di implementazione tecnica. Nel contesto degli NtS tutte le informazioni sono pubbliche. Non occorre quindi garantire i dati NtS in sé, in termini di protezione dei dati. Pertanto ogni fornitore deve decidere autonomamente in che misura tale aspetto debba essere attuato nel suo servizio.

9.2.   Principi e vincoli fondamentali

9.2.1.   Standard Web

Il servizio web NtS deve rispettare il WS-I Basic Profile 1.1. Tale profilo «fornisce orientamenti in materia di interoperabilità per un nucleo fondamentale di specifiche di servizi web non depositate, come SOAP, WSDL e UDDI» (1). Gli standard più pertinenti in questo contesto sono:

Il messaggio di risposta del servizio web NtS è un messaggio NtS specificato nella definizione dello schema XML (XSD) di cui all'appendice C del presente regolamento della Commissione.

9.2.2.   Modello di interazione e metodo di codifica per l'NtS WS

Per il servizio web NtS si usa il metodo di codifica Document-literal wrapped, poiché consente la convalida rispetto a uno schema XML; inoltre i nomi operazione definiti nella specifica WSDL sono usati direttamente come nomi tag XML nei messaggi SOAP.

9.3.   Specifiche e raccomandazioni generali

9.3.1.   Specifica: informazioni sulla versione

Le informazioni sulla versione del servizio web NtS sono composte da due sezioni:

La sezione del servizio web consta a sua volta di due parti:

La versione estesa è fornita con un numero intero positivo che indica la versione estesa del servizio web.

La versione ridotta è fornita con un numero intero non negativo che indica la versione ridotta del servizio web all'interno della versione estesa.

La sezione dello schema NtS contiene la versione dello schema NtS come definita dal gruppo di esperti NtS.

Di conseguenza la versione del servizio web NtS qui specificata è la 2.0.4.0, dove 2.0 è la versione del servizio web e 4.0 è la versione dello schema NtS usato.

Nelle richieste o nelle risposte del servizio web NtS non sono necessarie informazioni esplicite sulla versione. Si prevede che solo poche versioni dei servizi saranno online nello stesso momento. Versioni diverse devono essere dotate di URL diversi. Ciascuna istanza di un'implementazione del servizio web NtS deve pertanto supportare una versione specifica del servizio web NtS.

9.3.2.   Specifica: struttura degli spazi dei nomi

Gli spazi dei nomi nel servizio web NtS si basano sul dominio web dei gruppi di esperti RIS, http://www.ris.eu/

Gli spazi dei nomi contengono una particella che indica il servizio e le informazioni corrispondenti sulla versione. Il servizio qui specificato usa pertanto il seguente spazio dei nomi:

Servizio messaggi NtS http://www.ris.eu/nts.ms/2.0.4.0

9.3.3.   Raccomandazione: uso degli spazi dei nomi

Per migliorare la trasparenza dei documenti XML si raccomanda di definire gli spazi dei nomi nell'elemento adatto più esterno dello schema, come pure i documenti istanza, e di non usare definizioni locali di spazi dei nomi negli elementi nidificati.

9.3.4.   Raccomandazione: uso di prefissi di spazi dei nomi

Le richieste e le risposte del servizio web NtS usano elementi XML in forma qualificata, ossia con un prefisso esplicito di spazio del nome, e attributi XML in forma non qualificata, ossia senza un prefisso di spazio del nome.

Si raccomanda di usare prefissi di spazio del nome intuitivi, come «nts», allo scopo di migliorare la leggibilità umana.

9.3.5.   Specifica: uso dei codici di localizzazione ISRS

Il codice di localizzazione ISRS è illustrato nel capitolo 2 della guida alla codifica degli NtS per gli sviluppatori di applicazione, nonché nella guida alla codifica dell'indice RIS.

Quando effettua una ricerca nel Servizio web NtS, il cliente può fare riferimento a vari oggetti, ad es. sezioni di canali navigabili, idrometri o conche. Se si usano i parametri corrispondenti, vale a dire gli elementi id, questi devono contenere codici di localizzazione ISRS. Tali parametri sono di norma indicati negli elementi id, ciascuno dei quali contiene uno o due ids.

Quando si usano questi parametri occorre osservare le seguenti convenzioni generali:

Per indicare tratti di vie navigabili (coppie di elementi id nella fairway_section geo_object) nei messaggi NtS occorre prendere in considerazione i seguenti aspetti relativi ai codici di localizzazione ISRS:

Qualora un messaggio riguardi più di una sezione di via navigabile o canale navigabile, tutte le sezioni di canale navigabile devono essere definite tramite i rispettivi punti di inizio e di fine in elementi XML «fairway_section» separati.

Per alcuni/e paesi/regioni è necessario attivare la funzionalità filtro. Ad esempio se il codice di localizzazione ISRS (1-2) è BE, occorre usare il codice di localizzazione ISRS (6-8) come ID per la referenziazione lineare all'ettometro del canale navigabile (codice di localizzazione ISRS 16-20). Esempi di tratti di canale navigabile (coppie di elementi id validi nella fairway_section) che contengono le eccezioni succitate:

La figura seguente mostra controesempi dell'uso di un codice di localizzazione ISRS per ciascuna delle convenzioni generali (ai tratti di vie navigabili SK non si applicano eccezioni alle convenzioni generali):

Ricerche di codici di localizzazione ISRS non validi

Osservazione generale: il servizio web NtS non supporta un servizio per la ricerca di codici di localizzazione ISRS validi. I codici di localizzazione ISRS sono forniti nell'ambito del sistema europeo di gestione dei dati di riferimento (ERDMS).

L'utilizzo corretto dei codici di localizzazione ISRS nelle ricerche e la loro interpretazione sono illustrati nei cinque casi seguenti.

Caso 1: la richiesta non contiene elementi ids

L'elemento ids è una parte facoltativa della richiesta; una richiesta senza elementi ids è quindi consentita.

Ricerca valida senza parametro ids

Se non sono forniti elementi ids, tutti i messaggi devono essere rinviati (in funzione, naturalmente, di altri criteri di filtro come validity_period o dates_issue).

Caso 2: la richiesta contiene un elemento id

Ciascun elemento ids può contenere uno o due elementi id. La figura seguente mostra il caso di un elemento id:

Ricerca valida con un parametro id

Se riceve questa ricerca, il server rinvia tutti i messaggi corrispondenti con un ettometro d'inizio ≤ al valore dato (240,7 nell'esempio) e un ettometro di fine ≥ a tale valore. La figura seguente illustra questa selezione di messaggi: la posizione ricercata si trova tra i valori di ettometro d'inizio e di fine dei messaggi 1, 3 e 4, che verrebbero rinviati. I messaggi 2, 5 e 6 non si sovrappongono alla posizione della ricerca, e quindi non verrebbero rinviati.

Se un determinato codice di localizzazione ISRS denota un singolo oggetto, ad es. un idrometro o una conca, il servizio web dovrebbe rinviare i messaggi riguardanti tale oggetto.

Messaggi corrispondenti e non corrispondenti per un parametro id

Caso 3: la richiesta contiene due elementi id

Ciascun elemento ids può contenere uno o due elementi id. La figura seguente mostra il caso di due elementi id:

Ricerca valida con due parametri id

Tutti i valori ettometro ricercati devono essere trattati come validi, anche qualora la sezione di canale navigabile corrispondente abbia punti di inizio o di fine differenti. Ad esempio se la sezione di canale navigabile inizia all'ettometro 100,0 e finisce all'ettometro 300,0, una richiesta di ricerca per gli ettometri da 20,0 a 400,0 sarebbe valida. All'interno, naturalmente, la ricerca riguarderebbe solo l'estensione «reale» della sezione di canale navigabile.

In tal modo è anche possibile effettuare la ricerca per tutti i messaggi riguardanti un canale navigabile, senza conoscerne l'esatta progressiva ettometrica (in tal caso si invierebbe il suo codice di localizzazione ISRS con gli ettometri fissati rispettivamente a «00000» o a «99999»).

Tutti i messaggi corrispondenti che intersecano l'intervallo di ettometri indicato devono essere rinviati. Il diagramma seguente illustra questa situazione:

Messaggi corrispondenti e non corrispondenti per due parametri id

La figura precedente mostra come si definisce l'«intersezione». Mentre l'estensione dei messaggi da 1 a 4 si sovrappone (parzialmente o completamente) al segnale di progressiva ettometrica ricercato, ciò non avviene per l'estensione dei messaggi 5 e 6: i messaggi da 1 a 4 verranno pertanto rinviati, mentre non saranno rinviati i messaggi 5 e 6.

La condizione tecnica perché un messaggio intersechi un intervallo [A, B] è la seguente: l'ettometro d'inizio del messaggio è ≤ B e l'ettometro di fine è ≥ A.

Combinazione: la richiesta contiene molteplici elementi ids

Richiesta valida con molteplici elementi ids

La combinazione di più elementi ids nella richiesta comporta l'unione dei messaggi corrispondenti. Tutti gli elementi ids sono trattati individualmente e un messaggio sarà rinviato se corrisponde almeno a uno degli elementi. Per l'esempio indicato sarebbero pertanto rinviati i messaggi seguenti:

9.4.   Servizio messaggi NtS (specifica di implementazione)

Nel presente capitolo si illustra la specifica di implementazione del Servizio messaggi NtS, deducendola dalle considerazioni e dalle scelte dei capitoli precedenti.

Il Servizio messaggi NtS fornisce i quattro tipi di messaggio NtS:

L'implementazione del servizio messaggi NtS può supportare tutti i tipi di messaggi o solo una selezione. È consentito che uno Stato membro partecipante offra, per uno specifico tipo di messaggio, più servizi che si integrano a vicenda.

9.4.1.   Richiesta

Per potenziare al massimo il servizio, limitandone al tempo stesso la complessità, per il servizio web NtS non sono utilizzate lingue di ricerca supplementari. Si applicano invece i concetti forniti dal WSDL. Le operazioni specifiche, insieme ai loro parametri, sono interamente definite nell'ambito della specifica WSDL. Nel caso del servizio messaggi NtS è definita una singola operazione.

I criteri di filtro specifici per soggetto derivano dallo standard NtS, ma sono estesi per quanto riguarda la molteplicità dei parametri:

Il servizio rinvia solo i messaggi che corrispondono ai criteri indicati.

Meccanismo di avviso di chiamata

Per controllare la quantità di dati il servizio supporta un meccanismo di avviso di chiamata. Il parametro dell'avviso di chiamata è definito tramite un tipo complesso che contiene i seguenti elementi:

Il parametro complesso di avviso di chiamata è facoltativo, ma se è presente occorre indicare tutti gli elementi previsti. Il meccanismo di avviso di chiamata funziona poi nel modo seguente:

il numero totale dei messaggi non supererà il valore del parametro limit, ad eccezione del fatto che il valore 0 significa «assenza di limite». La risposta omette il numero massimo di messaggi definito nel parametro offset. Per fornire questo meccanismo, il servizio deve osservare una sequenza di messaggi temporaneamente stabile (ma altrimenti arbitraria), ad es. tra due aggiornamenti dei dati dei messaggi sulla serie sottostante di dati del servizio web. Ciò significa che due chiamate consecutive identiche devono rinviare gli stessi messaggi nel medesimo ordine. Il parametro total count determina se la risposta fornisce il numero totale di messaggi che corrispondono ai criteri specifici del soggetto. Di norma dovrebbe essere sufficiente chiedere quest'informazione con la prima risposta, omettendola però in tutte le risposte consecutive. In tal modo il servizio web dovrebbe garantire prestazioni migliori.

Il meccanismo di avviso di chiamata offre un mezzo per richiedere i messaggi in maniera iterativa in «pagine». Per un corretto funzionamento del meccanismo di avviso di chiamata, è necessario indicare in ciascuna chiamata gli stessi parametri specifici del soggetto.

9.4.2.   Risposta

In caso di esito positivo della richiesta, la risposta del servizio web NtS contiene i messaggi NtS che corrispondono ai parametri della richiesta. I messaggi NtS devono rispettare lo schema NtS e possono essere convalidati rispetto a tale schema. Dal momento che il tipo di messaggio è un parametro obbligatorio della richiesta, ciascuna risposta può contenere solo messaggi NtS dello stesso tipo di messaggio, rispettivamente FTM, WRM, ICEM o WERM.

Se individua errori durante il trattamento della richiesta, il servizio può rinviare un numero arbitrario di messaggi di errore usando i codici errore elencati nel sottocapitolo seguente.

Una risposta di un servizio web NtS può contenere contemporaneamente messaggi NtS e messaggi di errore.

Vengono rinviate informazioni facoltative di avviso di chiamata se la richiesta conteneva parametri di avviso di chiamata. In tal caso l'offset e il numero di messaggi contenuti sono obbligatori; il conteggio totale deve essere presente solo se è stato richiesto.

NB: si presuppone che la comunicazione tra il servizio web e l'utente sia stabilita tecnicamente, ossia che il servizio riceva la richiesta e l'utente riceva la risposta corrispondente. In questa sede non si prendono in considerazione errori tecnici quali ad esempio interruzioni della connessione Internet o inaccessibilità del servizio web dovuta a manutenzione o crash. Si tiene conto soltanto delle situazioni di errore che si verificano «oltre» il livello del servizio web, dal punto di vista degli utenti.

Messaggi di errore

Segue un elenco dei codici di errore per le situazioni di errore previste, corredati di una spiegazione. La risposta contiene solo il codice di errore, che è la procedura consueta nello schema XML degli NtS.

Codici di errore per il servizio messaggi NtS

9.5.   Generazione di servizi e clienti

Se l'approccio «il contratto innanzi tutto» viene di conseguenza osservato (ossia uno o più contratti con le descrizioni complete delle interfacce sono forniti sotto forma di documenti WSDL) è possibile generare automaticamente, impiegando gli opportuni strumenti software, l'attivazione del servizio o dei servizi, nonché l'attivazione di un cliente corrispondente. In una situazione ideale non è necessario effettuare modifiche manuali al codice sorgente generato.

Nella maggior parte dei casi occorrono però diverse interazioni prima che la specifica WSDL soddisfi i requisiti precisi di un tale strumento. Per operare correttamente, lo strumento pone di norma esigenze individuali sull'uso dello standard WSDL. Di conseguenza possono rendersi necessarie modifiche alla specifica WSDL, anche se questa era originariamente valida secondo lo standard WSDL. Se la specifica WSDL del servizio web viene modificata dopo che il servizio o il cliente sono stati generati, può essere necessario un nuovo processo di generazione, a seconda delle modifiche apportate.

Glossario

(1)  Descrizione citata dal sito web WS-I: http://www.ws-i.org

Appendice C