Questa pagina web vuole essere un manuale operativo per semplificare la comprensione dell’ambito e degli strumenti del SINFI. Nonostante sia stata posta la massima accuratezza nella sua redazione, non è sottoposto ai formali processi di verifica di tutte le parti coinvolte. Non può quindi assolutamente essere assunto come un documento ufficiale o di riferimento. Ricordiamo che gli unici testi definitivi sono quelli pubblicati sulla gazzetta ufficiale a mezzo stampa e sul sito dell’AGID.


SINFI

Sistema Informativo Nazionale Federato delle Infrastrutture

Il SINFI è lo strumento identificato per il coordinamento e trasparenza per la nuova strategia per la banda larga e ultralarga. Tra le funzioni che svolge vi è favorire la condivisione delle infrastrutture, mediante una gestione ordinata del sotto e sopra suolo e dei relativi interventi, ed anche offrire un unico cruscotto che gestisca con efficienza e monitori tutti gli interventi.



Riferimenti Normativi

Il SINFI è frutto della Direttiva 2014/61/UE del Parlamento Europeo e del Consiglio del 15 maggio 2014, la quale esplicita lo scopo di "facilitare e incentivare l'installazione di reti di comunicazione elettronica ad alta velocità promuovendo l'uso condiviso dell'infrastruttura fisica esistente e consentendo un dispiegamento più efficiente di infrastrutture fisiche nuove in modo da abbattere i costi dell'installazione di tali reti." art.1, comma 1.

Tale Direttiva è stata recepita dallo Stato Italiano per mezzo dell'emanazione del D.Lgs. n. 33/2016 e successivamente con il D.M. 11/05/2016 il Ministero dello Sviluppo Economico ha stabilito le modalità tecniche per la definizione del contenuto del Sistema Informativo Nazionale Federato delle Infrastrutture.


Documenti operativi a supporto

Con riferimento allo schema normativo precedente, a partire dalle Specifiche di Contenuto vengono inoltre prodotti, a supporto degli operatori che devono conferire i dati, una serie di ulteriori manuali e strumenti a supporto:

DOCUMENTI COSA E’ SOGGETTI REALIZZATORI CHI MODIFICA DOVE TROVARLI

Specifiche di contenuto di riferimento per i Database delle Reti di sottoservizi e per il SINFI
Specifica di contenuto che definisce, in conformità alle più generali specifiche sui DataBase Geotopografici, i contenuti e la struttura delle Classi di riferimento del SINFI, discriminando gli elementi obbligatori nell'ambito di una specifica estesa. Gruppo di lavoro sulle "Reti di sottoservizi" (GdL 8), Ministero dello Sviluppo Economico, AgID, Regioni, Comuni, Infratel Italia. Il Comitato del SINFI delibera le variazioni alle specifiche di contenuto www.rndt.gov.it

Modifiche introdotte nella versione 2.3 rispetto alla versione precedente
Il presente documento raccoglie le variazioni intercorse rispetto alla versione iniziale della Specifica SINFI (19 giugno 2015) AgIDComitato di coordinamento e monitoraggio del SINFI (istituito con DM del 2 dicembre 2016) Download

Linee guida per la produzione dati del SINFI
È di supporto all’interpretazione delle specifiche di contenuto, che rappresentano comunque la fonte ufficiale. Realizzato da AgID e supportato da Infratel Infratel, sulla base degli scambi tenuti con gli operatori durante la raccolta dati Download

Mapping shape flat
È il modello fisico (ovvero la descrizione della modellazione in file) delle Specifiche di contenuto di riferimento per il SINFI Infratel, AgID Infratel, a partire dalle Specifiche di Contenuto Download

Shape flat dei campi (solo per i campi obbligatori)
Shape di base vuoto, strutturato con i soli campi obbligatori. Utile per poter popolare comodamente i contenuti richiesti Infratel, AgID Infratel, a partire dalle Specifiche di Contenuto Download

Shape flat di esempio
Dati di esempio Operatore Operatore Download

Shape flat esempio: META.shp
Esempio del file META ipotizzando che l'infrastruttura/rete insista sul territorio del Comune di Roma Infratel Infratel Download

Manuale operativo di prima consegna dei dati
Guida per poter effettuare un caricamento di dati, anche di dimensione rilevante, tramite una piattaforma ad hoc predisposta da Infratel. Da utilizzare quando l’invio via mail dei dati non sia possibile. Infratel Infratel, secondo i suggerimenti degli operatori Download

Guida alla lettura del Report di sintesi del GeoUML Validator
A valle della validazione dei dati viene generato un report di validazione (leggasi la parte relativa in questa pagina). Il gruppo di supporto SINFI riporta via mail le indicazioni su cosa correggere. Questo manuale fornisce una ulteriore guida di approfondimento per la lettura del report di validazione. CISIS e Politecnico di Milano CISIS e Politecnico di Milano Download

Chi deve conferire i dati

I soggetti [1] deputati al conferimento dei dati sono:

  • Le amministrazioni pubbliche titolari e detentrici delle informazioni;
  • Gli operatori di rete;
  • I gestori di infrastrutture fisiche.

Quali dati devono essere conferiti

Con riferimento specificatamente agli operatori di rete ed ai gestori di infrastrutture (siano essi pubblici o privati) i dati contenuti nel SINFI [2] comprendono elementi del soprasuolo ed elementi del sottosuolo:

  • Rete
    • idrica di approvvigionamento
    • di smaltimento delle acque
    • elettrica
    • del gas
    • di teleriscaldamento
    • oleodotti
    • di telecomunicazioni e cablaggi
  • Infrastruttura di alloggiamento reti: tutti gli elementi di una rete di infrastrutture destinati ad ospitare altri elementi di una rete senza che diventino essi stessi un elemento attivo della rete.

Entro quando dovranno essere conferiti i dati

Il D.M. 11/05/2016 nelle disposizioni finali definisce le scadenze per adempiere agli obblighi definiti dall'art.3:

  • Per gli operatori di rete: i dati dovrebbero essere già stati conferiti entro il 14 settembre 2016 [3]
  • Per le pubbliche amministrazioni titolari e detentrici delle informazioni: i dati dovrebbero essere già stati conferiti entro il 14 dicembre 2016 [4]

Cosa succede in caso di mancato o tardivo conferimento dei dati?

Il D.L. 33/2016 prevede sanzioni per il mancato o tardivo conferimento dei dati di cui sopra. Non sono presenti casi ad oggi di sanzioni applicate, ed è stato anzi creato un gruppo di supporto per facilitare la raccolta dei dati. Tuttavia per gli operatori che continueranno a dimostrarsi inadempienti, saranno applicate le sanzioni previste.

Si consideri che mediamente il tempo di raccolta e validazione dati può estendersi sino a qualche mese. È fondamentale quindi avviare il processo di dialogo con il gruppo SINFI quanto prima per ottemperare a quanto richiesto dai decreti e limitare ulteriori aggravi nel ritardo e quindi nelle sanzioni.

Conoscere il SINFI per conferire i dati

Prerequisiti

Nella logica dei sistemi informativi territoriali, la piattaforma SINFI fornirà servizi territoriali basati su un DataBase Geotopografico strutturato e popolato da dati conformi alla specifica di riferimento; pertanto, la produzione dei dati richiede competenze generali in materia di geomatica e specifiche in ambito di sistemi GIS. Tali professionalità, già diffuse nella PA regionali e nei maggiori operatori economici di sottoservizi, fanno riferimento a specifiche competenze digitali, in materia di dati e servizi geografici, relative ai profili professionali in corso di normazione nell'ambito di UNINFO.

Il SINFI presuppone quindi la conoscenza dei software GIS. In caso contrario i gestori delle reti, tenuti ad inviare i dati [5] potranno dotarsi di soggetti professionisti in tale campo.


Architettura del modello dati

I dati catalogati nel SINFI secondo le specifiche di contenuto comprendono elementi del soprasuolo ed elementi del sottosuolo e sono classificati negli strati sopra riportati. Le specifiche di contenuto sono state rilasciate assieme alle relative linee guida. Ogni strato definisce i suoi dati secondo una alberatura di temi, classi ed attributi:

Di particolare interesse per il SINFI sono i temi dello Strato 07 relativo alle Reti di Sottoservizi, come riportato in figura:

Come modellare i dati

Il modello concettuale dei dati [6] trova applicazione nella sua trasposizione in un modello fisico [7] e rappresenta le classi come shapefile.

Il modello fisico mostra le strutture fisiche dei dati all’interno di ogni classe indicando anche quali attributi debbano essere specificati. Ad esempio la classe ”INFR_RT – 070001” dello Strato “07 – Reti di sottoservizi”, tema “0700 – Gestione infrastrutture di alloggiamento reti”, nel modello concettuale indica come componente spaziale geometrie di tipo poligonale. Tuttavia, nella pratica spesso accade che al di sotto di certi livelli di scala gli oggetti possano essere stilizzati come punti e linee, quindi il modello fisico prevede che le geometrie poligonali possano essere collassate in archi e nodi, consentendo di fatto anche queste tipologie di geometrie. Generalmente, il collassamento a arco o nodo dipende dalla tipologia di infrastruttura rappresentata, quindi:

  • Nell’arco si possono collassare:
    • cunicolo tecnologico;
    • galleria polifunzionale;
    • cavidotto.
  • Nei nodi si possono collassare:
    • palo;
    • pozzetto/cameretta.

Relativamente allo Strato “07 – Reti di sottoservizi” è possibile osservare che le sole classi relative alle reti (quindi dal tema 0701 al tema 0707, escludendo il tema 0700 che si riferisce alle infrastrutture) presentano delle caratteristiche comuni che è importante sottolineare:

  • Le classi relative alle tratte generano 2 shapefile:
    • Uno relativo alle tratte (“TR_xxx”, dove “xxx” varia a seconda del tipo di rete)
    • Uno relativo alle tratte minime (“TR_xxx_TR_xxx_TRA_SG”)
  • Gli attributi che nel modello concettuale riportano la dicitura “a Tratti su – Tracciato” sono quelli che caratterizzano le tratte minime, gli altri sono attributi delle tratte;
  • Le tabelle del modello fisico che non hanno un attributo geometrico sono singole tabelle in formato DBF che integrano le informazioni direttamente contenute nei file SHP;
  • Ogni classe (di ogni strato, non solo delle reti di infrastrutture) include gli attributi che definiscono i “Metadati di Istanza” che nel modello concettuale sono indicati con “TR_xxx_MET” o “ND_xxx_MET” e fanno riferimento agli attributi DATA_INI, DATA_FIN, FONTE e SCALA;
  • Le classi relative ai nodi presentano attributi comuni indicati nelle specifiche di contenuto come “ATT_COM_P”, ma nel modello fisico si traducono in P_BORN, P_MAT, P_STAT (obbligatorio) e P_POS.

Componenti Tabellari e Geometriche

Di seguito si forniscono alcuni chiarimenti relativi alle componenti tabellari e geometriche di ciascun file del modello fisico.

Nota bene: infrastrutture di alloggiamento reti

È doveroso porre attenzione sulla parte fondamentale del SINFI, ovvero le infrastrutture in grado di ospitare reti: le informazioni per queste sono raccolte con obbligo di dichiarazione nel Tema 0700, “classe INFR_RT. Questa deve essere individuata in una delle seguenti tipologie:

  • cunicolo tecnologico
  • galleria polifunzionale
  • traliccio
  • palo
  • cavidotto
  • pozzetto/cameretta d'ispezione

Nei casi in cui un soggetto gestisca una rete alloggiata in un’infrastruttura gestita da altri, non dovrà dichiarare i relativi elementi della classe INFR_RT, i quali saranno invece dichiarati dal gestore della stessa anche nei casi in cui non siano utilizzati per reti di sua proprietà e/o gestione.

A supporto di questa classe, nell’esempio di figura è rappresentata la contemporaneità di 9 diversi oggetti da riportare nella classe INFR_RT. Ulteriori chiarimenti sono disponibili nel relativo documento operativo.

Nota bene: classe META

Lo Strato 00, nel Tema 0002, definisce la Classe META: questa corrisponde al poligono che identifica l'area coperta dal dataset fornito. Collima con la sezione definita dal RNDT. Seppur non funzionale per il SINFI e non bloccante nella fase di prima consegna dei dati, sarà successivamente considerata nei futuri sviluppi di interazione tra il SINFI ed il RNDT.


Nota bene: La cardinalità

Alcuni attributi mostrano accanto alla descrizione testuale un valore incluso tra parentesi quadre che indica la cardinalità, ovvero il tipo di relazione tra la classe e l’attributo:

  • [1], l’attributo ammette un solo valore non nullo per ogni elemento della classe;
  • [0.. 1], l’attributo ammette un solo valore, anche nullo, per ogni elemento della classe;
  • [0.. *], l’attributo ammette i valori nulli e per ogni elemento della classe può essere specificato più di un valore;
  • [1.. *], l’attributo non ammette i valori nulli e per ogni elemento della classe può essere specificato più di un valore.

Attenzione: Per gli attributi con cardinalità multipla, ovvero quelli che consentono di specificare più di un valore per ogni elemento della classe, il modello fisico prevede la creazione di una tabella esterna in formato DBF nella quale oltre al valore specificato per l’attributo, è presente il campo “ClassREF” che funge da chiave esterna per il legame con il “ClassID” della classe;


Nota bene: Valori nulli

Per la compilazione degli attributi con valori nulli è necessario utilizzare i valori specifici per ogni tipo di campo come specificato nella tabella estratta dal documento “modello_fisico_SHP_SINFI” e riportata di seguito.


Nota bene: Geometrie

Le componenti geometriche delle classi relative alle reti di sottoservizi presentano alcune peculiarità che è opportuno tenere in considerazione al fine della corretta produzione dei dati:

  • Le geometrie devono rispettare il formato richiesto nel modello dati: in 2D o 3D e devono sempre essere geometrie Singlepart, mai Multipart (ad esempio, nel caso di punti, sono accettabili i tipi Point o PointZ, mentre non sono ammessi i PointZM o Multipoint);
  • Gli elementi della classe INFR_RT possono essere rappresentati con differenti shapefile in base al tipo di geometria: INFR_RT_ESTENSIONE se l’estensione spaziale è di tipo poligonale, INFR_RT_ESTENSIONE_L se le geometrie sono linee e INFR_RT_ESTENSIONE_P se sono punti. È inoltre possibile abbinare più di una geometria, anche di tipologia diversa, a ciascun elemento della classe;
  • La relazione tra tratte e tratte minime deve essere sempre di tipo uno a molti (al limite uno a uno) e le geometrie devono essere esattamente sovrapponibili. In sostanza le tratte minime sono una duplicazione delle tratte, ma possono essere spezzate in un numero maggiore di segmenti separati;
  • Per il rispetto dei vincoli topologici imposti dal modello dati, ai vertici delle estremità di ogni tratta dello shapefile TR_xxx deve sempre corrispondere un nodo esattamente sovrapposto dello shapefile ND_xxx. Qualora alcune estremità delle tratte fossero sprovviste di un nodo, è necessario aggiungere dei nodi fittizi;

Per quanto concerne la correttezza del formato degli attributi (sia quelli geometrici che quelli tabellari) può essere di aiuto l’utilizzo degli Shape_flat (strutture dati vuote) che si trovano nel toolkit SINFI o al link
upload.sinfi.it



Il processo di validazione

La verifica della piena conformità dei dati ai dettati del modello SINFI è un’operazione che, a fronte di vari passaggi operativi, deve permettere di poter caricare sulla piattaforma SINFI dati omogenei provenienti da tutti gli operatori ed enti del territorio italiano.

Ogni dato inviato verrà sottoposto al processo di validazione per la verifica di conformità con il modello dati previsto nelle “Specifiche di contenuto di riferimento per i DataBase delle Reti di sottoservizi e per il SINFI”, e al modello fisico ad esso riferito.

Lo strumento deputato al processo di validazione è il GeoUML Validator [8] , che a partire da un dataset è in grado di controllare la conformità geometrica, topologica e di database rispetto ad una specifica di riferimento (SCS), riportando gli esiti in un report (file PDF).

Nel report, che viene sempre inviato all’operatore, gli errori sono raccolti per tipologia secondo il seguente ordine:

  1. Strutture assenti
  2. Assenza e compatibilità degli attributi
  3. Violazione dei controlli metrici
  4. Violazioni di cardinalità e univocità
  5. Violazioni dei vincoli di chiave esterna
  6. Violazioni dei vincoli GeoUML


Il gruppo di validazione fornirà comunque all’operatore un supporto specifico alla lettura del report degli errori riscontrati nel proprio dataset, mettendo in evidenza le criticità più urgenti da correggere rispetto a violazioni che possono rientrare nelle cosiddette eccezioni. Ad ulteriore approfondimento dell’operatore verrà fornito anche il manuale di lettura al Report Sintetico

Per maggiore supporto il processo di validazione è oggi eseguito dal reparto tecnico predisposto da Infratel. E’ lasciato l’arbitrio all’operatore, di far effettuare la validazione ad Infratel o in autonomia. Trascorso questo periodo di supporto iniziale, sarà compito del gestore a procedere autonomamente alla validazione dei dati. In tal senso per gli operatori che conferiranno il primo invio di dati in tempi non imminenti, si suggerisce di prendere confidenza con questo processo, in particolare con lo strumento del GeoUML, già predisposto e funzionante attraverso una macchina virtuale ( GeoUML_Virtual_Machine ).

La validazione dell’operatore diverrà, come previsto dal decreto, obbligatoria.

Per approfondire nello specifico il flusso operativo di validazione di un campione rappresentativo e il conferimento dei dati finali rimandiamo alla lettura del documento Manuale per la consegna dei dati.



Contatti




[1] Il D.M. 11/05/2016 all'art. 2 comma 2 definisce i soggetti che contribuiscono alla costituzione ed aggiornamento del SINFI e nell'art.3, comma 3 gli attribuisce la responsabilità dell'invio dei dati, della validazione, della correttezza e dell'aggiornamenti
[2] D.M. 11/5/2016, Allegato A, Premesse
[3] Entro 90 giorni dalla data della pubblicazione del decreto
[4] Entro 180 giorni dalla data della pubblicazione del decreto
[5] secondo il D.M. 11/05/2016 (G.U. n.139 16.06.2016),
[7] Reperibile all’indirizzo www.sinfi.it/modellofisicocompleto
[8] CISIS e PoliMI