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

INDICE

1. Contesto e struttura 24

1.1. Obiettivi della guida alla codifica degli NtS 24

1.1.1. Guida alla codifica degli NtS per i compilatori 24

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

2. Messaggi NtS e loro sezioni 24

3. Considerazioni fondamentali in merito ai WRM 26

3.1. Compilazione della sezione nts_number nel WRM 26

3.2. Compilazione dei WRM contenenti previsioni 26

4. Processi ICEM 27

4.1. Nuovo ICEM 28

4.2. Aggiornamento di un ICEM esistente 28

5. Considerazioni fondamentali in merito ai WERM 29

5.1. Compilazione della sezione nts_number nel WERM 29

5.2. Compilazione del «weather_category_code» WERM 29

6. Processi FTM 30

6.1. Nuovo FTM 30

6.2. Aggiornamento/revoca di un FTM esistente 30

6.3. FTM riguardanti vie navigabili e/o oggetti 31

6.4. Ordine automatico dei codici di restrizione 31

6.5. Gestione del periodo di restrizione 32

7. Norme generali di attuazione 33

7.1. Compilazione della «[ “]number_section[” ]» 33

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

7.3. Omissione di elementi 34

7.4. Compilazione automatica di date_issue 34

7.5. Gestione delle informazioni sul fuso orario nei messaggi NtS 34

7.6. Gestione dei secondi nei messaggi NtS 34

7.7. Formato dei decimali nei messaggi NtS 34

7.8. Unità di misura da impiegare nei messaggi NtS 34

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

7.10. Norme per l'elemento «fairway_name» 38

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

7.12. Raccomandazione per l'elemento «coordinate» 38

7.13. Gestione dei gruppi di destinatari 38

7.14. Visualizzazione di messaggi validi in un momento determinato 39

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

8. Struttura del messaggio NtS XML 39

9. Servizio web NtS 39

9.1. Obiettivo 39

9.2. Principi e vincoli fondamentali 40

9.2.1. Standard Web 40

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

9.3. Specifiche e raccomandazioni generali 40

9.3.1. Specifica: informazioni sulla versione 40

9.3.2. Specifica: struttura degli spazi dei nomi 41

9.3.3. Raccomandazione: uso degli spazi dei nomi 41

9.3.4. Raccomandazione: uso di prefissi di spazi dei nomi 41

9.3.5. Specifica: uso dei codici di localizzazione ISRS 41

9.4. Servizio messaggi NtS (specifica di implementazione) 46

9.4.1. Richiesta 46

9.4.2. Risposta 47

9.5. Generazione di servizi e clienti 48

Glossario 48

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:

— sezione di identificazione;

— sezione che definisce l'oggetto/gli oggetti o la sezione/le sezioni di canale navigabile applicabili cui fa riferimento il messaggio;

— una o più delle seguenti sezioni, a seconda del tipo di messaggio: — restrizione/i per il messaggio relativo al canale navigabile e al traffico, — rilevazione/i per il messaggio relativo al livello idrometrico, — condizione/i del ghiaccio per il messaggio relativo al ghiaccio, — bollettino/i meteorologico/i per il messaggio di tipo meteorologico.

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.

— Sezione relativa al canale navigabile e al traffico: un «messaggio relativo al canale navigabile e al traffico» (FTM) è creato di solito dai compilatori NtS seguendo la Guida alla codifica degli NtS per i compilatori. Riguarda tratti di vie navigabili (definiti dai rispettivi codici di localizzazione ISRS di inizio e di fine) e/o oggetti sulla via navigabile definiti dal rispettivo codice di localizzazione ISRS [si rimanda al capitolo 6].

— Sezione di tipo idrometrico: un «messaggio riguardante le acque» (WRM) favorisce l'invio di informazioni sui livelli idrometrici effettivi e previsti, nonché di altre informazioni. Di norma i WRM sono creati automaticamente (e periodicamente) sulla base di rilevazioni di sensori o dello stato di infrastrutture che non richiedono l'interazione dei compilatori NtS. La sezione del messaggio riguardante le acque contiene informazioni per un oggetto (ad es. una stazione idrometrica) o una sezione di canale navigabile (ad es. la profondità minima rilevata per un tratto, il regime applicabile a una sezione di canale navigabile). L'oggetto è identificato dal proprio codice di localizzazione ISRS; la sezione di canale navigabile è definita dai codici di localizzazione ISRS di inizio e di fine della sezione [si rimanda al capitolo 3].

— Sezione relativa al ghiaccio: un «messaggio ICE» (ICEM) contiene informazioni sulle condizioni del ghiaccio per un tratto di canale navigabile definito dai codici di localizzazione ISRS di inizio e di fine del tratto [si rimanda al capitolo 4].

— Sezione di tipo meteorologico: un «messaggio di tipo meteorologico» (WERM) consente di inviare informazioni sulle condizioni meteorologiche effettive e previste in un tratto di via navigabile definito dai codici di localizzazione ISRS di inizio e di fine del tratto [si rimanda al capitolo 5].

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:

— livello idrometrico (comprese le previsioni),

— profondità minima rilevata (comprese le previsioni),

— tirante d'aria (comprese le previsioni),

— portata d'acqua (comprese le previsioni),

— stato dello sbarramento,

— regime.

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:

<value_min> valore minimo dell'intervallo di confidenza

<value_max> valore massimo dell'intervallo di confidenza

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

1) Le applicazioni NtS possono offrire ai compilatori NtS l'opportunità di: a) usare gli avvisi esistenti come bozza per la creazione di un nuovo ICEM (ad es. se le condizioni del ghiaccio sono simili a quelle dell'avviso esistente), e/o di b) usare modelli di avviso per determinate situazioni.

2) Il contenuto (ad es. l'ora della rilevazione o le corrispondenti condizioni del ghiaccio) deve essere inserito dal compilatore conformemente al capitolo 6 della guida alla codifica degli NtS per i compilatori. La data e l'ora della rilevazione possono essere fissate anche dall'applicazione in base alle definizioni nazionali.

3) Quando un compilatore/i responsabili della pubblicazione di un NtS avvia/avviano la pubblicazione, a) si controlla che tutti i contenuti obbligatori siano presenti, conformemente all'NtS XSD (in caso contrario tornare al punto 2); b) l'nts_number viene generato dall'applicazione NtS: i) «organisation» viene compilato con il nome o il codice dell'organizzazione responsabile, a seconda del ruolo dell'utente che avvia la pubblicazione, ii) «year» è compilato con l'anno in corso, iii) viene assegnato il «number» disponibile successivo, iv) viene assegnato il «serial number» 0; c) «date_issue» è compilato automaticamente con la data/l'ora effettive di pubblicazione; d) «validity_period» — «date_start» è compilato automaticamente con la data effettiva di pubblicazione; e) «validity_period» — «date_end» è compilato automaticamente con il giorno successivo alla data di 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).

4.2. Aggiornamento di un ICEM esistente

1) Il relativo messaggio pubblicato deve essere selezionato a fini di aggiornamento nello strumento di compilazione ICEM. L'ICEM originale deve essere copiato o modificato nella banca dati (a seconda dei processi nazionali) Un ICEM scaduto (che ha oltrepassato la validity_date_end) non può più essere aggiornato; in tal caso i compilatori NtS devono creare un nuovo ICEM.

2) Il contenuto (ad es. l'ora della rilevazione o le corrispondenti condizioni del ghiaccio) deve essere modificato dal compilatore conformemente al capitolo 6 della guida alla codifica degli NtS per i compilatori. La data e l'ora della rilevazione possono essere modificati anche dall'applicazione in base alle definizioni nazionali.

3) Quando un compilatore/responsabile della pubblicazione di un NtS avvia la pubblicazione: a) si controlla che tutti i contenuti obbligatori siano presenti, conformemente all'NtS XSD (in caso contrario tornare al punto 2); b) l'nts_number viene generato dall'applicazione NtS: i) «organisation» rimane inalterato, ii) «year» rimane inalterato, iii) «number» rimane inalterato, iv) «serial number» è incrementato (aumentato di 1); c) «date_issue» è compilato automaticamente con la data/l'ora effettive di pubblicazione; d) «validity_period» — «date_start» è compilato automaticamente con la data effettiva di pubblicazione; e) «validity_period» — «date_end» è compilato automaticamente con il giorno successivo alla data di 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).

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.

Valore, significato Visibilità Informazioni supplementari 13, nebbia fitta inferiore a 50 metri 14, nebbia densa inferiore a 100 metri 15, nebbia moderata inferiore a 200 metri 16, nebbia inferiore a 1 000 metri La nebbia è costituita di goccioline d'acqua. 17, nebbia leggera da 1 km a 4 km La nebbia leggera è costituita di goccioline d'acqua. Il termine «nebbia leggera» è usato in caso di «nebbia secca», fenomeno che si verifica di solito prima dell'alba. 18, foschia da 1 km a 4 km La foschia è costituita di particelle secche. 19, foschia leggera da 4 km a 10 km 20, sereno da 10 km a 20 km 21, molto sereno nessuna limitazione della visibilità 22, assenza di nebbia Il termine «assenza di nebbia» è usato per designare l'assenza di nebbia sulla base delle prescrizioni nazionali/locali.

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

1) Le applicazioni NtS possono offrire ai compilatori NtS l'opportunità di: a) usare gli avvisi esistenti come bozza nella creazione di un nuovo FTM e/o b) usare modelli di avviso per determinate situazioni.

2) Il contenuto (ad es. periodo di validità o restrizioni) deve essere inserito dal compilatore conformemente ai capitoli 3 e 4 della guida alla codifica degli NtS per i compilatori.

3) Quando un compilatore/responsabile della pubblicazione di un NtS avvia la pubblicazione: a) si controlla che tutti i contenuti obbligatori siano presenti, conformemente all'NtS XSD (in caso contrario tornare al punto 2); b) l'nts_number viene generato dall'applicazione NtS: i) «organisation» viene compilato con il nome o il codice dell'organizzazione responsabile, a seconda del ruolo dell'utente che avvia la pubblicazione, ii) «year» è compilato con l'anno in corso, iii) viene assegnato il «number» disponibile successivo, qualora il compilatore NtS abbia inserito un numero dedicato oppure si riprenda il processo dell'applicazione alla fase 2, dal momento che (Organizzazione/Anno/Numero/Numero progressivo) è unico, come illustrato nel capitolo 15.1; iv) viene assegnato il «serial number» 0; c) «date_issue» è compilato automaticamente con la data/l'ora effettive di pubblicazione.

6.2. Aggiornamento/revoca di un FTM esistente

1) Il relativo messaggio pubblicato deve essere selezionato a fini di aggiornamento nello strumento di compilazione FTM; l'FTM originale deve essere copiato o modificato nella banca dati (a seconda dei processi nazionali). a) Un FTM scaduto (che ha oltrepassato la validity_date_end) non può più essere aggiornato; in tal caso il compilatore NtS deve creare un nuovo FTM. b) Il codice oggetto «Avviso revocato» viene utilizzato solo se: i) la data di compilazione è anteriore alla validity_date_start. Qualora sia possibile modificare solo il contenuto del campo «informazioni supplementari nella lingua nazionale»; il contenuto codificato del messaggio (fase 2) deve rimanere inalterato; ii) il periodo di validità è già iniziato e la nuova data di fine per tutte le restrizioni è fissata al passato. La data di fine della restrizione deve essere fissata in corrispondenza dell'ora corretta. c) Se un avviso viene revocato, la data di fine del periodo di validità deve essere fissata in corrispondenza della data di revoca.

2) Il contenuto (ad es. periodo di validità o restrizioni) deve essere modificato dal compilatore conformemente ai capitoli 3 e 4 della guida alla codifica degli NtS per i compilatori.

3) Quando un compilatore/responsabile della pubblicazione di un NtS avvia la pubblicazione: a) si controlla che tutti i contenuti obbligatori siano presenti, conformemente all'NtS XSD (in caso contrario tornare al punto 2); b) l'nts_number viene generato dall'applicazione NtS: i) «organisation» rimane inalterato, ii) «year» rimane inalterato, iii) «number» rimane inalterato, iv) «serial number» è incrementato (aumentato di 1); c) «date_issue» è compilato automaticamente con la data/l'ora effettive di pubblicazione. d) Un FTM con codice oggetto «Avviso revocato» non è (più) preso in considerazione per la pianificazione del viaggio.

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

— a una o più sezioni di canale navigabile, oppure a

— uno o più oggetti su una o più sezioni di canale navigabile.

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:

Posto Valore Significato (IT) 1 OBSTRU ostruzione totale 2 PAROBS ostruzione parziale 3 NOSERV nessun servizio / esercizio 4 SERVIC servizio / esercizio limitato 5 VESDRA pescaggio della nave 6 VESBRE larghezza della nave 7 CONBRE larghezza del convoglio 8 VESLEN lunghezza della nave 9 CONLEN lunghezza del convoglio 10 CLEHEI tirante d'aria 11 VESHEI altezza della nave dal pelo dell'acqua 12 AVALEN lunghezza massima ammessa 13 CLEWID larghezza della via navigabile 14 AVADEP pescaggio massimo 15 LEADEP profondità minima rilevata 16 DELAY ritardo 17 ALTER traffico in senso alternato 18 TURNIN divieto di manovra 19 PASSIN divieto di transito 20 OVRTAK divieto di sorpasso 21 NOBERT divieto di attracco 22 NOMOOR divieto di ormeggio 23 ANCHOR divieto di ancoraggio 24 SPEED limite di velocità 25 WAVWAS divieto di moto ondoso 26 NOSHORE divieto di approdo 27 MINPWR potenza minima 28 CAUTIO particolare cautela 29 NOLIM nessuna restrizione

6.5. Gestione del periodo di restrizione

— Restrizioni aventi periodi di restrizione identici dovrebbero essere visualizzate in gruppo, in un elenco comune o in maniera combinata per agevolare la consultazione.

— Gli strumenti di compilazione NtS dovrebbero prevedere una funzione che consenta ai compilatori di evitare la riscrittura dei periodi di restrizione.

— Tutte le restrizioni devono includere un periodo di restrizione con un codice intervallo per effettuare gli opportuni calcoli nell'ambito delle applicazioni di pianificazione del viaggio. Per agevolare il lavoro dei compilatori NtS è possibile attivare le seguenti funzioni: — lo strumento di compilazione NtS può prevedere una funzione per copiare le restrizioni già inserite, in modo da evitare che il compilatore NtS debba riscrivere il periodo di restrizione; — gli strumenti di compilazione NtS possono prevedere una funzione per selezionare più di un codice di restrizione per uno specifico periodo di restrizione e creare automaticamente le sezioni di restrizione necessarie, sulla base delle informazioni inserite dal compilatore NtS.

— «Da lunedì a venerdì eccetto i giorni festivi»: il valore «giorni festivi» presenta notevoli difficoltà per le applicazioni di pianificazione del viaggio. Per effettuare i calcoli in maniera corretta è necessario disporre di un elenco di giorni festivi per ciascun paese. In assenza di tale elenco le rispettive restrizioni saranno comunque assegnate ai giorni festivi.

— «Ad eccezione di»: non deve essere usato. Gli intervalli interrotti devono essere riportati come periodi di restrizione separati all'interno della stessa restrizione; questo codice non sarà pertanto visualizzabile/disponibile per i compilatori di avvisi.

— Logica e visualizzazione delle informazioni applicabili nel caso di codice intervallo «continuativo»: <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 l'interval_code è continuativo, lo start_time appartiene alla start_date e l'end_time appartiene alla end_date: ad es. dal 1o aprile alle 06:00 al 30 giugno alle 10:00.

— Logica e visualizzazione delle informazioni applicabili nel caso di ogni altro codice intervallo, diverso da «continuativo»: <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 l'interval_code ha un altro valore, lo start_time e l'end_time appartengono a tale interval_code: ad es. dal 1oaprile al 30 giugno, dal lunedì al venerdì dalle 06:00 alle 10:00.

— Nell'ultima versione di un messaggio è sempre obbligatorio compilare la fine del periodo di restrizione.

7. Norme generali di attuazione

Si deve tenere conto dei seguenti fattori:

— La tabella «GUI_labels» contenuta nelle tavole di riferimento NtS deve essere presa in considerazione per l'elaborazione delle applicazioni NtS (maschere di ricerca, moduli di iscrizione via e-mail, visualizzazione di messaggi).

— Il date_end non può essere anteriore al date_start.

— I codici che sono stati disabilitati (cioè che non devono più essere utilizzati) tramite richieste di modifica NtS (cfr. i commenti nell'NtS XSD) non devono essere visualizzabili dai compilatori NtS nel creare di nuovi messaggi. I codici restano inseriti nelle enumerazioni NtS XSD per garantire la retrocompatibilità.

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:

— Gruppo di destinatari: target_group_code ALL con direction_code ALL (se nel messaggio non vi sono altri gruppi di destinatari specifici),

— position_code: AL,

— reason_code: OTHER.

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»

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

— NAP: nei Paesi Bassi l'abbreviazione NAP è usata e compresa; NAP non viene tradotto

— KP: «channel level» viene tradotto e quindi comunicato nella lingua nazionale

— FZP: si usa solo l'abbreviazione «FZP» (oggi quasi caduta in disuso)

— ADR: «Mare Adriatico» viene tradotto e quindi comunicato nella lingua nazionale

— TAW/DNG: «Tweede algemene waterpassing» (neerlandese) — «Deuzième Nivellement Général» (francese) è l'altezza di riferimento usata in Belgio per esprimere le rilevazioni di altezza. 0 è il livello idrometrico marino medio con bassa marea a Ostenda — Neerlandese: TAW — Francese: DNG — Tutte le altre lingue: TAW/DNG

— LDC: «livello di magra navigabile fissato dalla Commissione del Danubio» viene tradotto e quindi comunicato nella lingua nazionale

— HDC: «livello di piena navigabile fissato dalla Commissione del Danubio» viene tradotto e quindi comunicato nella lingua nazionale

— ETRS: «European Terrestrial Reference System 1989»; l'abbreviazione «ETRS89» è usata in tutte le lingue

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:

— le applicazioni NtS possono dare ai compilatori NtS la possibilità di salvare le bozze dei messaggi NtS (non è necessario comunicare tutti i contenuti obbligatori per salvare le bozze di messaggi);

— ruoli utenti diversi possono applicarsi a compilatori diversi: ad es. i compilatori autorizzati a inserire/modificare gli avvisi, i responsabili della pubblicazione autorizzati a pubblicare avvisi (oltre alla compilazione).

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:

— XML Schema Definition (XSD),

— Simple Object Access Protocol (SOAP),

— Web Services Description Language (WSDL) e

— Universal Description, Discovery and Integration (UDDI).

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.

SOAP è un protocollo di applicazione per la trasmissione di dati tra sistemi informatici ed è standardizzato dai World Wide Web Consortiums (W3C). Gli elementi specifici per il servizio web NtS sono definiti conformemente alle corrispondenti specifiche WSDL di cui all'appendice D del presente regolamento della Commissione. Lo schema dello standard NtS (XSD) è inserito con una dichiarazione d'importazione. UDDI (Universal Description, Discovery and Integration) è segnalato in questa sede come un registro centrale, eventualmente internazionale, dei servizi web, in cui si potrebbe registrare il servizio web NtS. In questo registro i potenziali consumatori del servizio web potrebbero effettuare ricerche e individuare il servizio. Tuttavia, dal momento che i potenziali fornitori del servizio web NtS sono limitati dagli Stati membri partecipanti e la specifica WSDL è parte integrante dello standard, non appare evidente la necessità di una registrazione indipendente del servizio web NtS.

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:

— versione del servizio web

— versione dello schema NtS usato dal servizio web

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

— versione estesa del servizio web

— versione ridotta del servizio web

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:

— i codici di localizzazione ISRS devono essere presentati come codici completi di 20 caratteri, ossia senza eliminare gli zeri finali;

— se nello stesso elemento id si usano due ids, entrambi i codici di localizzazione ISRS devono riferirsi alla stessa via navigabile. Ciò significa che i codici includono alcuni caratteri identici situati nella parte fairway_section del codice di localizzazione ISRS. Il codice della sezione di canale navigabile, insieme all'ettometro del canale navigabile, definisce un tratto di via navigabile espresso come coppia di elementi id.

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:

— caratteri da 1 a 2 (codice paese — Country code): — devono essere identici nella coppia id, ma — nella stessa coppia id si possono definire codici paese diversi qualora paesi limitrofi usino lo stesso codice della sezione di canale navigabile per una specifica via navigabile e lo stesso sistema per definire gli ettometri;

— caratteri da 3 a 5 (codice di localizzazione delle Nazioni Unite — UN Location code): — non sono pertinenti, possono contenere elementi differenti nella coppia id;

— caratteri da 6 a 10 (codice della sezione di canale navigabile — Fairway section code): — devono essere identici nella coppia id, ma — [eccezione]: se si usano i codici ISRS belgi nel servizio web NtS, per identificare la sezione di canale navigabile è opportuno utilizzare solo i caratteri da 6 a 8, in quanto i messaggi NtS saranno pubblicati in sezioni diverse dello stesso canale navigabile;

— caratteri da 11 a 15 (codice di riferimento dell'oggetto — Object Reference Code): — non sono pertinenti, possono contenere elementi differenti nella coppia id;

— caratteri da 16 a 20 (ettometro del canale navigabile — Fairway Hectometre): — si compongono di cinque caratteri numerici che definiscono l'ettometro; di norma avranno quindi un contenuto diverso nella coppia id. Esempio: «00235» per il km 23,5 del canale navigabile; «00001» per il km 0,1 del canale navigabile; — [eccezione]: nel caso dei Paesi Bassi non vi è sempre una connessione diretta tra l'ettometro del canale navigabile e il chilometro fisico di quest'ultimo, a causa della definizione dell'inizio del tratto di canale navigabile nel modello in rete e nel mondo reale; in tali casi il codice di riferimento dell'oggetto per gli oggetti di tipo «dismar» inizia con Kxxxx [xxxx comprende il chilometro fisico, ad es. NLSVG00130K000300191 (km 3)]. Per altri tipi di oggetti, tuttavia, nei codici ISRS non c'è relazione diretta con il chilometro fisico del canale navigabile: ad es. il ponte di Sas van Gent, al km 2,5 dello stesso canale navigabile, reca il codice ISRS NLSVG001300521600186. Per il Kanaal Gent-Terneuzen il km fisico 0,0 inizia alla frontiera tra Belgio e Paesi Bassi, mentre l'ettometro 0,0 del canale navigabile comincia all'inizio del canale a Gent.

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:

— i due codici di localizzazione ISRS NL sono una definizione valida di un tratto di via navigabile (che presenta un'eccezione NL rispetto al chilometro del canale navigabile): NLSVG00130K000300191 (km 3,0 a Sas van Gent sul Kanaal Gent-Terneuzen) — NLWDP00130K000400200 (km 4,0 a Westdorpe sul Kanaal Gent-Terneuzen);

— i due codici di localizzazione ISRS BE sono una definizione valida di un tratto di via navigabile [che presenta un'eccezione BE rispetto al codice della sezione di canale navigabile («020» Albertkanaal)]: BEGNK02016L010100414 (conca di Genk situata al km 41,4 sul canale Albert) — BEOSH02033L010500772 (conca di Ham situata al km 77,2 sul canale Albert).

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:

— tutti i messaggi per l'oggetto con il codice di localizzazione ISRS SKXXX0000010000*****, ettometro d'inizio = 0 ed ettometro di fine ≥ 0 (cfr. caso 2);

— tutti i messaggi per l'oggetto con il codice di localizzazione ISRS SKXXX0000500000***** che intersecano l'intervallo di ettometri [11,0, 15,0] (cfr. caso 3);

— tutti i messaggi per l'oggetto con il codice di localizzazione ISRS SKXXX0000200000*****, ettometro d'inizio ≤ 110,5 ed ettometro di fine ≥ 110,5 (cfr. caso 2)

— tutti i messaggi per l'oggetto con il codice di localizzazione ISRS SKXXX0000500000***** che intersecano l'intervallo di ettometri [220,0, 300,0] (cfr. caso 3).

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:

1. NtS FTM (messaggio relativo al canale navigabile e al traffico)

2. NtS WRM (messaggio riguardante le acque)

3. NtS ICEM (messaggio relativo al ghiaccio)

4. NtS WERM (messaggio di tipo meteorologico)

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:

— tipo di messaggio (obbligatorio; uno tra «FTM», «WRM», «ICEM», «WERM»)

— specifiche sezioni di vie navigabili o parti di esse, oppure oggetti specifici (facoltativi; descritti da singoli codici di localizzazione ISRS e/o coppie di codici di localizzazione ISRS)

— periodo di validità (facoltativo; data di inizio e data di fine)

— data di pubblicazione dell'avviso (facoltativa; singole date e/o intervalli di date)

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:

— offset: numero progressivo del primo messaggio rinviato (numero intero ≥ 0)

— limit: numero massimo di messaggi (numero intero ≥ 0)

— total count: flag, se deve essere rinviata la totalità dei messaggi (valore booleano)

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

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

Termine Spiegazione ID Identificazione ISRS Location Code Codice di localizzazione «Standard internazionale di segnalazione navale» NtS Avvisi ai naviganti ONU Nazioni Unite RIS Servizi d'informazione fluviale SOAP Simple Object Access Protocol: protocollo di rete usato di norma per i servizi web UDDI Universal Description, Discovery and Integration: standard per i servizi di registrazione nel contesto dei servizi web URL Uniform Resource Locator: localizzazione di una risorsa di rete usata di norma per gli indirizzi Internet WGS 84 Sistema geodetico mondiale 1984 WS Servizio web: servizio che offre le proprie interfacce su Internet ed è usato dalla comunicazione via Internet WSDL Linguaggio di descrizione dei servizi web: standard per la specifica dei servizi web WS-I Web Services Interoperability Organisation: consorzio industriale volto a sostenere l'interoperabilità dei servizi web XML Linguaggio a marcatori estensibile: metalinguaggio per la rappresentazione dei dati strutturata e indipendente dalle piattaforme XSD Definizione dello schema XML: standard atto a specificare la struttura dei documenti XML

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