Guida all uso del GeoUML Validator (versione software 2.0) 1 febbraio 2012

Transcript

1 Guida all uso del GeoUML Validator (versione software 2.0) 1 febbraio 2012 pagina 1 di 42

2 Autori Politecnico di Milano Spatial DB Group Giuseppe Pelagatti (coordinatore), Alberto Belussi, Jody Marca, Mauro Negri Coordinamento delle attività CISIS CPSG Comitato di Progetto CISIS CPSG Struttura di supporto interna Maurizio De Gennaro (Regione del Veneto coordinatore tecnico), Massimo Attias (CISIS-referente area geografica e progetti) Stefano Olivucci (Regione Emilia- Romagna), Raffaella Gelleti, Marco Lunardis, Massimo Zia (Regione Friuli Venezia Giulia), Massimiliano Basso, Alessandra Chiarandini (INSIEL- Regione FVG), Simone Patella (Regione Lazio), Gianbartolomeo Siletto (Regione Piemonte), Mauro Vasone (CSI Piemonte), Marco Guiducci, Andrea Peri (Regione Toscana), Gianfranco Amadio, Domenico Bertoldi, Gianluca Riscaio, Sandra Togni (Regione Umbria), David Freppaz (Regione Valle d Aosta), Virgilio Cima, Umberto Trivelloni (Regione del Veneto), Leonardo Donnaloia, Claudio Mazzi, Pierpaolo Milan (CISIS) Massimo Attias, (coordinatore struttura), Leonardo Donnaloia, Claudio Mazzi, Pierpaolo Milan, Antonio Rotundo (CISIS) pagina 2 di 42

3 INDICE 1. INTRODUZIONE 2. L INTERFACCIA DEL VALIDATOR E CARICAMENTO SI UNA SPECIFICA 2.1 I menù del Validator 2.2 La gestione della specifica 3. ESPLORAZIONE DI UNA SPECIFICA 3.1 Visualizzazione contenuto della specifica 3.2 Ricerca di elementi nella specifica 4. CONFIGURAZIONE ED ESECUZIONE DEL VALIDATOR 4.1 La configurazione delle connessioni 4.2 La configurazione del validatore 4.3 La configurazione dei parametri metrici 4.4 L esecuzione della validazione 5. ELABORAZIONE E INTERPRETAZIONE DELLA DIAGNOSTICA 5.1 Modalità di elaborazione della diagnostica 5.2 Funzionamento del Validator e organizzazione del DB di reportistica 5.3 Tabelle Analitiche e Tabelle Sintetiche 5.4 Identificazione dei singoli errori 5.5 Contenuto generale delle tabelle di reportistica in base alla fase in cui sono prodotte Tabelle generate in fase di caricamento Tabelle generate in fase di normalizzazione Tabelle generate in fase di validazione 5.6 Descrizione dettagliata delle singole tabelle del database di reportistica Tabelle per il controllo strutturale generate dai caricatori dei MI del validatore Tabelle per la verifica dei valori degli attributi generate dai caricatori dei MI del validatore Tabelle generate nel processo di normalizzazione 5.6.4Tabelle generate dai controlli sul DBN APPENDICE 1. INSTALLAZIONE, ESECUZIONE E AGGIORNAMENTO DEL GEOUMLVALIDATOR 1.1 Requisiti 1.2 Installazione 1.3 Esecuzione del programma 1.4 Creazione dei database di appoggio 1.5 Aggiornamento delle versioni e specifiche APPENDICE 2. CONFIGURAZIONE E UTILIZZO DI IREPORT 2.1 Inclusione delle librerie per accedere alla tecnologia Apache Derby 2.2 Connessione al database dei report preconfezionati 2.3 Generare dei documenti pagina 3 di 42

4 Premessa GeoUMLvalidator è un programma sviluppato dal gruppo di ricerca SpatialDBgroup, DEI, Politecnico di Milano nell ambito di un progetto co-finanziato col Centro Interregionale per i Sistemi Informatici, Geografici e Statistici (CISIS). Le versioni del Validator, della documentazione e informazioni aggiuntive sono disponibili sul sito spatialdbgroup.polimi.it. Questa guida fa riferimento inoltre ai seguenti documenti: - GeoUML Methodology e Tools. Organizzazione Complessiva, 1 febbraio Guida alla lettura di uno schema GeoUML, 1 febraio Il Modello GeoUML. Regole di Interpretazione delle Specifiche di Contenuto per i Database Geotopografici, approvato dal Comitato per le regole tecniche sui dati territoriali delle Pubbliche Amministrazioni, 27/4/ Guida ai Modelli implementativi di tipo Flat, 1 febbraio Guida all uso del GeoUML Catalogue (versione software 2.0), 1 febbraio 2012 pagina 4 di 42

5 1. INTRODUZIONE Il GeoUML validator (chiamato Validator nel seguito) è uno strumento in grado di operare il controllo di conformità intrinseca di un generico Data Product (chiamato nel seguito dataset) relativamente ad una specifica di contenuto SC gestita dal GeoUML catalogue. Come mostrato nella seguente figura, la Specifica Concettuale, le DPS e i relativi mapping generati dal GeoUMLcatalogue sono esportati nel file di Specifica.scs e sono importati dal Validator che li carica in un proprio database interno. Il Validator poi carica un dataset da validare, strutturato secondo le regole (incluso il modello implementativo) definito da una delle DPS e ne verifica la congruenza alla specifica, generando come risultato una serie di informazioni diagnostiche. GeoUML catalogue SC.scs Data Product da validare GeoUML validator Informazioni diagnostiche La comprensione del comportamento del Validator e l interpretazione della diagnostica richiedono una conoscenza del modello GeoUML. Le versioni del Validator Il Catalogue viene distribuito in due versioni: il Validator completo di tutte le funzioni che permette l importazione di una specifica di contenuto generato col Catalogue, la configurazione dei controlli da eseguire, la validazione dei dati e la produzione della diagnostica. - il Validator chiuso che possiede tutte le funzionalità di validazione del Validator, ad eccezione della funzione di importazione. Questo Validator può quindi applicare i controlli a data Product che siano conformi alla sola specifica che è stata incorporata nel Validator. Il processo di validazione Il Validator utilizza per il proprio funzionamento da uno a due Database di Appoggio: 1. il DB di caricamento, detto DBF, che costituisce un database di transito utilizzato nel processo di trasferimento del dataset verso il DBN 2. il DB normalizzato, detto DBN, sul quale vengono eseguiti i controlli di corrispondenza dei dati alla specifica I database di appoggio devono essere creati in un DBMS PostGIS installato sullo stesso server del Validator oppure essere messi a disposizione da un server remoto. Osservazioni: 1) per alcuni tipi di modelli implementativi non è necessaria la disponibilità di un DBF, perché il caricamento viene effettuato direttamente sul DBN. Al momento pagina 5 di 42

6 questa semplificazione riguarda solamente i modelli implementativi di tipo SQL multigeometria. 2) per supportare la validazione di dati relativi a diverse DPS (ad esempio, per validare sia dati in formato Shapefile, sia dati contenuti in un DB) è possibile definire propri database di Appoggio per ogni DPS; in alternativa, gli stessi database di Appoggio possono essere utilizzati per più DPS, ma i processi di validazione dovranno essere eseguiti sequenzialmente (questo aspetto è approfondito nella sezione dedicata alla configurazione). La configurazione dei database di Appoggio e di altri parametri di validazione sono preliminari all esecuzione di una validazione, tuttavia non è necessario ridefinirli quando il Validator è usato per validare più volte uno stesso dataset aggiornato. Teoricamente il funzionamento del Validator sarebbe da dividere in 2 parti: portare i dati nel DBN e quindi eseguire tutti i controlli sul DBN. In pratica il processo è leggermente più complicato, perché intervengono due problematiche: in primo luogo, per portare i dati nel DBN è risultato opportuno prima caricarli in un DB di caricamento (DBF), più simile al modello della Sorgente, e poi ristrutturarli in secondo luogo, per eseguire sia il caricamento del DBF che la trasformazione in DBN devono essere eseguiti alcuni controlli di validità minima dei dati indispensabili per poterli caricare In base a queste considerazioni il processo di validazione è diviso i 3 fasi: 1) fase di caricamento: il dataset da validare viene letto e caricato nel DBF; durante questa fase vengono eseguiti tutti i controlli necessari per garantire la caricabilità del dato. In particolare si controlla la conformità delle strutture della sorgente a quelle previste dal MI scelto. Si controllano anche i singoli valori degli attributi e della componente spaziale prima di procedere al loro caricamento nel database di caricamento; 2) fase di normalizzazione: il contenuto del DBF viene letto, ristrutturato e caricato in DBN; durante questa fase vengono eseguiti alcuni controlli sui valori dei singoli oggetti ricostruiti, completando quindi il controllo dei singoli valori degli attributi descrittivi e delle componenti spaziali. 3) fase di validazione: durante questa fase vengono eseguiti sui dati presenti in DBN tutti i restanti controlli. In particolare è possibile effettuare la verifica delle proprietà inerenti l insieme degli oggetti di una classe o delle relazioni tra le diverse classi (ad es., le proprietà strutturali quali l univocità degli attributi e i vincoli topologici). Il peso relativo delle diverse fasi dipende dal Modello Implementativo del dataset; se tale modello è molto simile a quello del DBN (ad esempio nei MI SQL monogeometria) la fase di normalizzazione è molto leggera, mentre può essere pesante in caso contrario (in particolare nel MI Shape Topologico). I controlli svolti nelle fasi di caricamento e normalizzazione sono esclusivamente interni ad ogni singolo oggetto mentre i controlli che coinvolgono molti oggetti sono tutti svolti nella fase di validazione. La descrizione dei controlli che vengono svolti è trattata nella sezione del documento dedicata alla interpretazione della diagnostica. pagina 6 di 42

7 Struttura della guida La Sezione 2 del documento descrive il menù del Validator e la gestione delle specifiche nello strumento. Sezione 3 richiama le funzionalità che permettono la visualizzazione della specifica concettuale caricata nel Validator. Sezione 4 descrive come configurare i database PostGIS necessari alla validazione e come connetterli allo strumento, l eventuale connessione del database da validare nel caso dei modelli implementativi SQL e infine le modalità di esecuzione della validazione. La Sezione 5 descrive le modalità di elaborazione della diagnostica e il significato degli errori attraverso la descrizione della struttura del database della reportistica DERBY. Appendice 1 illustra come installare, esecuguire e aggiornare il GeoUMLvalidator. Appendice 2 spiega come attivare Ireport per generare i documenti che riportano i dati della diagnostica descrittiva in forma sintetica e analitica. pagina 7 di 42

8 2. L INTERFACCIA DEL VALIDATOR E CARICAMENTO DI UNA SPECIFICA 2.1 I menù del Validator Dopo l avviamento del Validator si presenta con una finestra vuota, grigia, e la barra laterale sinistra e il menù principale nella parte in alto. La barra laterale sinistra visualizza una serie di TABS orientati alla visualizzazione degli elementi principali della specifica di contenuto caricata nel Validator, con una struttura uguale a quella del Catalogue; le altre componenti di una specifica sono invece visualizzabili tramite il menù Visualizza. Il menù Configurazione permette di configurare i parametri e i database necessari all esecuzione della validazione e permette inoltre l esecuzione della validazione. Il menù Genera permette la generazione del DB di reportistica dopo la validazione, mentre il menù File offre funzioni per la gestione della specifica utilizzata. Menù a tendine Elenco strati e temi della specifica Nome della specifica Elenco classi Elenco dei vincoli spaziali Elenco degli Strati topologici Figure specifica Elenco delle Data Product specifications 2.2 La gestione della specifica Il Validator è distribuito senza una specifica precaricata e mette quindi a disposizione funzioni per il caricamento di una specifica generata dal Catalogue, per la cancellazione della specifica caricata e per trasformare il Validator originale in un Validator chiuso. Queste funzioni sono rese disponibili dal menù File come mostrato dalla figura. pagina 8 di 42

9 Importazione di una specifica. Il caricamento di una specifica nel Validator richiede di selezionare il menù File alla voce Importa la specifica. La scheda di importazione, mostrata sotto, richiede poi l individuazione del file della specifica (di tipo.scs o di tipo.zip se compattato) e l attivazione dell importazione tramite il click sul bottone Importa. Si noti che una specifica può essere caricata in un Validator versione X.* se e solo se è stata creata da un Catalogue versione X.*, altrimenti viene rifiutata l importazione; si rimanda alla guida all uso del Catalogue per le modalità di allineamento della versione di una specifica (sezione importazione ed esportazione) e all appendice 1 di questa guida. L importazione di una specifica non altera le configurazioni dei database definite in precedenza, mentre vanno ridefinite le altre configurazioni. Si ricorda che il Validator può caricare una specifica in uno qualsiasi dei propri stati: working, pre-release, released (vedere la guida al GeoUMLcatalogue per una descrizione dettagliata), tuttavia la funzione di chiusura del Validator richiede che la specifica caricata sia in stato released. Cancellazione della specifica Selezionando il menù File alla voce Proprietà è possibile inoltre cancellare la specifica presente nel Validator, generando una specifica vuota; questa funzione va attivata solo qualora in presenza di molteplici importazioni si verifichino problemi nell esecuzione di una nuova importazione. Per la cancellazione è necessario premere il bottone cancella tutto il contenuto del databasee successivamente il bottone Salva modifiche della stessa scheda. La cancellazione non annulla la configurazione dei database e dei parametri metrici. Congelamento di una specifica Per permettere ad un soggetto privato di utilizzare il Validator su un dataset (ad esempio, in produzione) è necessario che l estensore della specifica esporti dal Catalogue Editor la specifica nello stato released, la importi nel Validator, poi attivi la pagina 9 di 42

10 voce Congela SC del menù File. A questo punto deve terminare l esecuzione del Validator e rieseguire nuovamente il Validator; quest ultima operazione trasforma il Validator in un Validator chiuso. Il Validator chiuso può essere utilizzato su più Dataset purchè siano tutti associati alla stessa specifica caricata nel Validator chiuso poiché è disabilitata la funzione di importazione. Si noti che nel caso in cui sia necessario cambiare la specifica presente in un Validator chiuso è necessario ricreare il Validator chiuso con le modalità spiegate prima. pagina 10 di 42

11 3. ESPLORAZIONE DI UNA SPECIFICA Dopo l importazione di una specifica il Validator permette di visualizzare il contenuto della specifica secondo le stesse modalità del GeoUML Catalogue Viewer. Il Validator permette di visualizzare gli elementi della specifica di contenuto caricata anche attraverso una funzione di ricerca, ma non ne permette la stampa se non attraverso una funzione generale di stampa della scheda corrente del Validator attivata alla voce Print del menù File e che permette la stampa di un elemento della specifica quando questo è visualizzato nella scheda corrente. 3.1 Visualizzazione contenuto della specifica Per visualizzare la descrizione degli elementi concettuali della specifica di contenuto associato si usa principalmente la barra laterale. Per accedere ad una delle voci di primo livello presenti sulla barra laterale è sufficiente un singolo click del mouse sulla voce selezionata. Ad esempio, nella figura sulla destra è mostrato il risultato di un click sulla voce Classi. Da questo elenco, con un click su una classe si ottiene l apertura di una scheda che contiene le informazioni relative a quella classe. In generale, una volta aperta una qualsiasi scheda, è possibile analizzare gli elementi informativi GeoUML presenti su tale scheda selezionandoli con un click; in questo modo si apre una nuova scheda relativa all elemento selezionato. Questo metodo permette l esplorazione delle specifiche, ad esempio permette, data una classe, di selezionare un attributo o una componente spaziale, e di visualizzarne tutte le caratteristiche (ad es., attributi dipendenti dalla geometria e poi i valori di domini enumerati, ecc...). Si noti che le associazioni sono visibili solo accedendo alle classi coinvolte. Oltre agli elementi formali della specifica il Validator permette di visionare le descrizioni, le immagini e i diagrammi associati agli elementi della specifica. Ulteriori informazioni inerenti la specifica di contenuto disponibili nel menù principale sono: - i dati di identificazione della specifica (nome, versione, autore, creazione, lingua, ) che si ottengono selezionando dal menù visualizza la voce Specifica (vedi figura a destra). - La presenza dell introduzione generale alla specifica di contenuto e di eventuali allegati alla specifica stessa è verificabile selezionando dal menù Visualizza la voce Struttura documenti; se sono presenti appare un box relativo (box RTF introduzione o RTF allegati) in fondo alla scheda; si noti che l introduzione e gli allegati non possono essere visualizzati con il Validator. - I livelli di scala definiti per la specifica, che sono visualizzabili selezionando dal menù Visualizza la voce Livelli di scala. - I valori di interpretazione dei valori nulli (ad esempio, 91 Non conosciuto delle specifiche del National Core) se sono stati definiti nella specifica, visibili selezionando dal menù Visualizza la voce Valore nullo. pagina 11 di 42

12 3.2 Ricerca di elementi nella specifica La barra laterale sinistra permette di accedere a specifici elementi che vengono individuati negli elenchi mostrati selezionando un opportuno TAB, tuttavia il Validator permette di accedere agli elementi della specifica anche attraverso una funzionalità di ricerca per nome attivata dal menù Visualizza alla voce Cerca che mostra la scheda della figura a lato. La scheda permette di indicare il nome cercato (ad es., EDIFC) e di specificare se il nome si riferisca al valore di uno specifico campo di identificazione (codice, codice alfanumerico, descrizione) o al valore di uno qualsiasi dei tre. Inoltre si può indicare in quale parte della specifica cercare (ad esempio, in tutta la specifica come mostrato in figura), oppure nei soli attributi o associazioni. La ricerca mostrerà poi tutti gli elementi individuati (ad esempio, una classe e sei attributi descrittivi nella figura) suddivisi per tipologia e con un click sulla tipologia prima e sullo specifico elemento poi sarà possibile come con la barra laterale accedere ai dati di dettaglio dello specifico elemento. Si noti che selezionando Tutto il catalogo nel campo in si restringe la ricerca agli elementi formali: Classi, Associazioni, DataType, DominiGerarchici, Domini, Vincoli, Eventi, Tratti e Sottoaree. pagina 12 di 42

13 4. CONFIGURAZIONE ED ESECUZIONE DEL VALIDATOR L esecuzione di una validazione richiede che siano state eseguite tutte le operazioni previste in Appendice 1 inerenti la creazione dei database di appoggio utilizzati dal Validator. Dopo la creazione dei database di appoggio e l importazione di una specifica si devono: - memorizzare nel validatore i parametri necessari alla connessione al dataset da validare (modelli implementativi SQL) e ai database di appoggio; - agganciare ogni DPS al dataset e ai database di supporto; - definire i parametri per l esecuzione dei controlli metrici e di distanza minima (per il modello implementativo Shape_Topo). 4.1 La configurazione dei database Selezionare il menù, mostrato nella figura a destra, Configurazione alla voce Gestione Configurazioni Database che permette la visualizzazione della scheda delle connessioni effettuate mostrata sotto (in figura non sono presenti connessioni). Si noti che questa operazione richiede che prima siano stati creati i database come descritto in Appendice 1 in base alla tecnologia del modello implementativo del dataset da controllare. La creazione di una nuova connessione avviene premendo il bottone Nuova che appare nella scheda precedente, il quale estende la precedente scheda con la scheda per la generazione della configurazione corrente descritta nella prossima figura; questa operazione di creazione va ripetuta per ogni database di appoggio. In figura si mostra la compilazione della scheda per il database Postgres di caricamento in base ai dati di esempio utilizzati in Appendice 1; vengono selezionati il tipo di database (PostGIS ad indicare Postgres con l inserimento delle librerie geometriche di PostGIS), l utilizzo (Caricamento e nella seconda configurazione sarà Normalizzazione), la porta (assegnata dal Validator), l URL (per convenzione IP perché i database di appoggio sono nel nostro esempio sullo stesso calcolatore del Validator, altrimenti sarebbe necessario l IP reale), il nome assegnato (vedi Appendice 1), l utente e la password dell amministratore di Postgres e lasciando in bianco il campo schema. pagina 13 di 42

14 Dopo aver compilato i campi è conveniente premere il bottone Prova connessione per verificare la correttezza dei parametri e infine premere Salva per memorizzare la connessione creata. Nel caso in cui il dataset sia stato creato con un modello implementativo Shape è necessario ripetere l operazione precedente anche per il secondo database di appoggio per la normalizzazione selezionando nuovamente il bottone Nuova. Si noti che nella parte inferiore della scheda a lato rimangono visibili i parametri dell ultima connessione salvata che possono essere nuovamente modificati e salvati. Infine se il dataset da validare è stato realizzato con un modello implementativo SQL Flat allora è necessario configurare la connessione anche al database contenente i dati da validare; in tal caso il tipo di database potrà essere PostGIS o Oracle, l utilizzo sarà sorgente (nel caso Oracle questa voce sarà omessa in quanto sorgente per default) e in questo caso si dovrà specificare il nome dello schema se i dati sono messi in un particolare schema del database selezionato. Attenzione nel caso di dataset SQL per il modello implementativo SQL Flat multigeometria si deve configurare solo il database di Appoggio di caricamento. Le connessioni create sono elencate nella parte alta della scheda in righe colorate in base al parametro di uso (rosso caricamento, giallo normalizzazione, bianco sorgente); nella figura sotto appare l elenco delle connessioni dopo la creazione della connessione al database di Appoggio per il caricamento dei dati. Si noti che per correggere i dati di una connessione esistente è sufficiente selezionarla nella lista con un doppio click del mouse. 4.2 La configurazione del validatore Selezionando la voce Configurazione del validatore del menù Configurazione si definiscono i parametri che permettono l associazione di una DPS al proprio dataset sorgente e ai database di Appoggio. La prima operazione consiste nella selezione di una delle DPS presenti nella specifica. Nel caso di DPS con modello implementativo Shape, ad esempio, appare la seguente figura pagina 14 di 42

15 E necessario per questo tipo di DPS indicare il pathname completo della cartella che contiene il dataset (shape). Inoltre si devono selezionare due dei database precedentemente creati e configurati come database di caricamento e normalizzazione e salvare i dati. Nel caso di DPS di modelli implementativi SQL Flat multigeometria si devono selezionare, come indicato nella figura sotto, la DPS, il database sorgente precedentemente configurato e il solo database di caricamento. Nel caso del modello implementativo SQL monogeometria si richiedono invece entrambi i database di Appoggio. Attenzione. E possibile che più DPS condividano uno o entrambi i database di Appoggio ma con i seguenti vincoli del Validator: - DBF condiviso. Se viene caricato (anche normalizzato) il dataset della DPS1 allora all atto del caricamento del dataset della DPS2 (che condivide il DBF) vengono eliminati dal database interno del validatore tutti i dati che si riferiscono al dataset della DPS 1 incluso i risultati della diagnostica. - DBN condiviso. Il caricamento dei due dataset nel relativo DBF avviene senza restrizioni. Se il dataset della DPS1 viene normalizzato allora all atto della normalizzazione del dataset della DPS2 (che condivide DBN) vengono eliminati tutti i dati che si riferiscono al dataset della DPS1. Questi vincoli impongono di ripetere dei controlli eventualmente già eseguiti imponendo una sequenzializzazione delle validazioni. Pertanto se si vogliono validare in parallelo più dataset di DPS differenti è conveniente utilizzare database di Appoggio non condivisi tra le DPS. pagina 15 di 42

16 4.3 La configurazione dei parametri metrici La selezione del menu Configurazione alla voce Parametri dei controlli geometrici fa apparire la seguente scheda che è suddivisa in due parti: - nella prima parte devono essere indicati i valori metrici da utilizzare come soglia nei controlli metrici; si noti che il controllo relativo sarà eseguito se viene selezionato il checkbox a sinistra del parametro; - la seconda parte riguarda il controllo della distanza minima disponibile solo per il modello implementativo Shape_Topo e richiede di definire il valore di soglia e di selezionare il checkbox relativo per abilitare il controllo. Dopo l effettuazione delle scelte si deve premere il bottone Salva i parametri. La scheda propone sempre alcuni valori di default che possono essere sempre riselezionato attraverso il bottone Reimposta parametri di default. 4.4 L esecuzione della validazione Per eseguire la validazione del dataset si deve selezionare la voce Esecuzione del menù Configurazione per far apparire la scheda mostrata a lato. La scheda richiede di selezionare una delle DPS configurate con la voce configurazione validatore; se si sceglie una DPS non configurata apparirà la scritta Non configurata accanto alla DPS selezionata e non appariranno i bottoni per l esecuzione dei controlli.. Nella stessa scheda è possibile indicare il numero di processi concorrenti (livello di multithreading al quale opera il Validator); la scelta ottimale dipende dalle caratteristiche della macchina (Hardware) utilizzata e non può essere indicata in generale. Un criterio ragionevole può essere il seguente, a condizione di una disponibilità adeguata di RAM: Numero di Processi Concorrenti = Numero di Processori o di Core + 1. Il Validator permette l esecuzione sequenziale di tutti i controlli (bottone Caricamento + Normalizzazione + Validazione completa), oppure l esecuzione parziale dei controlli come indicato nella seguente lista: 1. i controlli della fase di caricamento dei dati dal dataset al database di appoggio di caricamento (bottone Importazione); in questa fase sono eseguiti i controlli sui singoli valori descrittivi e geometrici del dataset da validare. pagina 16 di 42

17 2. I controlli della fase di normalizzazione sono effettuati sulla trasformazione strutturale dei dati (eccetto Oracle multigeometria) e sulla ricostruzione delle geometrie del modello implementativo Shape_Topo; i dati trasformati sono poi caricati nel database di normalizzazione (bottone Normalizzazione) 3. I controlli strutturali (ad es., vincoli primary key, foreign key) (bottone Solo struttura). 4. Il controllo dei vincoli spaziali (bottone Solo vincoli); si noti che il bottone Completa esegue i controlli strutturali e i vincoli spaziali). Il Validator controlla che i controlli 2, 3, 4 siano eseguiti dopo l importazione e i controlli 3 e 4 dopo i controlli della normalizzazione. Tenere inoltre presente che la fase di caricamento popola un nuovo DBF, eliminando il contenuto di quello preesistente; la fase di normalizzazione crea un nuovo DBN, eliminando quello preesistente. Si noti che la possibilità di eseguire separatamente le diverse fasi permette di correggere i dati di input di una fase, ripetendola anche più volte, prima di passare alla successiva. Quando si attiva l esecuzione di uno dei precedenti controlli viene mostrata una finestra di log nella quale appare una sintesi delle operazioni eseguite (nella figura a lato è mostrata la finestra per il controllo di Importazione). Il log delle operazioni può essere esaminato a video allargandone le dimensioni o essere estratto selezionandolo e utilizzando il comando CTRL C; si tratta tuttavia di segnalazioni utili soprattutto in caso di problemi dell esecuzione. Inoltre se si vuole interrompere l esecuzione dei controlli in corso è necessario premere il bottone Ferma; si noti che l interruzione può richiedere anche due minuti al fine di non lasciare il validatore in uno stato inconsistente per riprendere la validazione. pagina 17 di 42

18 5. ELABORAZIONE E INTERPRETAZIONE DELLA DIAGNOSTICA 5.1 Modalità di elaborazione della diagnostica Le operazioni di validazione producono una serie di informazioni diagnostiche che il Validator salva nel database interno. Il Validator permette di esportare la diagnostica in una Directory a scelta dell utente, selezionando la voce Database reportistica del menu Genera. Tale funziona visualizza una scheda che chiede di selezionare la DPS per la quale si vuole la diagnostica e la cartella (bottone Sfoglia ) dove memorizzare tale diagnostica. E infine premere il bottone Genera. Si noti che questa funzione permette di generare la diagnostica per tutte le DPS per le quali è stata eseguita una validazione dei dati. L analisi dei dati della diagnostica può essere effettuata secondo diverse modalità. Nella cartella selezionata viene creato un database con tecnologia Apache DERBY, open source e quindi usabile liberamente contenente i dati della diagnostica che sarà chiamato database della reportistica. La maggior parte delle informazioni diagnostiche prodotte dal Validator sono corredate di geometria, cioè contengono la geometria dell oggetto errato. Dato che DERBY non è un Database spaziale, le geometrie sono memorizzate in formato standard WKB in un binary object (blob). La seguente figura illustra i 4 modi in cui può essere analizzato il contenuto del database di Reportistica: Validator Genera database reportistica Database Client (es. Squirrel) Database Reportistica (Apache Derby) Openjump (+ Plugin per Derby) Report Generator IReport (+ Configurazione per GeoUMLreport) 1. Database client. Uso di un generico Database Client, cioè di uno strumento in grado di interrogare un DB in tecnologia DERBY (esistono numerosi strumenti di questo tipo); questo metodo è il più potente ed è consigliabile per utenti esperti nell accesso ai database relazionali, però non permette di analizzare direttamente le geometrie (che possono essere analizzate sui dati del dataset sorgente, ad esempio). pagina 18 di 42

19 2. GIS client. Uso di un Client per dati territoriali in grado di accedere ai dati di un database DERBY; per il GIS Openjump è messo a disposizione sul sito un plugin per accedere ai dati di DERBY. In questo modo è possibile esplorare i dati geometrici. 3. Documento di report. Uso di un qualsiasi Report Generator per prodursi un documento di report adatto alle proprie esigenze; questo metodo è indicato per chi dovrà ripetere molte volte particolari analisi sulla diagnostica, ma richiede la prima volta un utente capace di configurare il Report Generator. 4. GeoUMLreport. Si tratta di un modello di report preconfigurato con il report generator IReport reso disponibile dal Validator per un primo accesso alla diagnostica ad esclusione delle geometrie adatto all utente non esperto negli altri strumenti e non fornisce alcuna forma di flessibilità. In Appendice vengono fornite le istruzioni per l installazione di Ireport e la produzione dei due documenti di reportistica (analitico e di sintesi). Si noti che i report fanno riferimento alle tabelle di diagnostica di DERBY descritte nel seguito e il report sintetico riporta l indicazione di quanti oggetti e con quale incidenza percentuale violano un controllo, mentre quello analitico riporta sostanzialmente il contenuto delle tabelle del database della reportistica ad eccezione dei casi in cui il 100% degli oggetti risulta sbagliato. 5.2 Funzionamento del Validator e organizzazione del DB di reportistica Prima di analizzare in dettaglio la struttura e il significato del database di reportistica è opportuno prendere in considerazione come l impostazione di tale database sia legata ai principi di funzionamento del Validator, in particolare ai seguenti: Il Validator può trovare errori in ognuna delle 3 fasi descritte precedentemente: caricamento, normalizzazione e validazione Dato che le fasi di caricamento e normalizzazione dipendono dal Modello Implementativo, anche il tipo di errori riscontrabile in queste due fasi preliminari dipende dal MI; tuttavia, la struttura delle tabelle del DB di reportistica destinate a tener traccia di questi errori è unica per tutti i MI. Inoltre: o Il validatore controlla solo le strutture fisiche richieste e gli attributi previsti dallo specifico MI considerato; strutture fisiche aggiuntive o attributi aggiuntivi nella sorgente non sono quindi considerati. o Le strutture fisiche dedicate alla descrizione dei domini enumerati non sono considerate dal validatore che le carica direttamente dalla specifica (file.scs) per i controlli di dominio. In presenza di un errore il Validator tenta di procedere nell analisi; per questo motivo nelle fasi di caricamento e normalizzazione a fronte di un dato errato il Validator se possibile carica un valore scelto opportunamente (spesso è il valore NULLO) nel corrispondente campo del DBF o DBN, in modo da poter proseguire nell analisi. Naturalmente, questo approccio comporta che: o Nelle fasi successive si possono generare molti ulteriori errori dovuti agli errori precedenti o In certe situazioni il Validator deve fermarsi perché non è in grado di procedere La diagnostica prodotta dal Validator deve servire a rintracciare gli errori sia a livello concettuale che a livello fisico; il Validator riscontra infatti gli errori sui dati, quindi nel modello fisico, ma spesso l interpretazione degli errori richiede di rintracciare le categorie concettuali che il dato fisico deve rappresentare; pertanto, la comprensione della diagnostica richiede di conoscere le regole del MI utilizzato. pagina 19 di 42

20 AVVERTENZA: Dato che la struttura delle tabelle di reportistica è unica, indipendentemente dal MI utilizzato, nelle spiegazioni seguenti in alcuni casi vengono indicati diversi contenuti possibili di una tabella, dovuti ai diversi MI; per semplicità, tali alternative sono riportate senza specificare a quali MI si riferiscono se il lettore conosce o è interessato a un solo MI deve riconoscere le affermazioni rilevanti per lui trascurando quelle non rilevanti. Ad esempio, l identificatore di un oggetto in una classe si chiama ClassID in alcuni MI e UUID in altri; indicando come valore di un campo ClassID oppure UUID si lascia all utente di riconoscere l elemento che gli interessa. 5.3 Tabelle Analitiche e Tabelle Sintetiche Il Database di reportistica consiste di tabelle dedicate alla segnalazione analitica dell errore e di tabelle di sintesi; le Tabelle sintetiche sono in corrispondenza biunivoca con le tabelle analitiche per le quali ha senso fornire il livello sintetico e hanno un nome costituito dal concatenamento del nome della corrispondente tabella analitica con il suffisso SIN. Le tabelle analitiche descrivono, in generale, il dettaglio di ogni singolo errore incontrato specificandone la gravità, l elemento concettuale e fisico interessato e l identificazione dell oggetto coinvolto e riportano, ove possibile, una geometria che riporti l oggetto errato o l area dove si verifica l errore. Le tabelle sintetiche forniscono a livello di componenti come le classi, ad esempio, l indicazione del numero totale di errori e della loro incidenza percentuale; si noti che nel caso di un errore che coinvolga tutti gli oggetti di una classe (incidenza del 100%) l errore viene segnalato solo nelle tabelle sintetiche. Le tabelle analitiche servono quindi per individuare e correggere i singoli errori, mentre le tabelle sintetiche servono per individuare le aree di maggior criticità e stabilire se si tratti di errori metodologici e infine per valutare complessivamente la qualità del dataset sorgente. 5.4 Identificazione dei singoli errori La segnalazione degli errori trovati dal validatore avviene a doppio livello, sia identificando l oggetto fisico, il suo attributo e la struttura fisica di appartenenza, sia associando tali elementi ai corrispondenti elementi concettuali della specifica. Inoltre, viene generalmente fornito l identificatore dell istanza di oggetto che ha causato l errore. I riferimenti alle strutture fisiche e concettuali degli oggetti con errore sono i seguenti: SFPHYSTRUCTNAME: nome della struttura fisica della sorgente alla quale appartiene l oggetto con errore. SFPHYATTRNAME: nome dell attributo della struttura fisica che contiene l errore. SCELEMENNAME: nome dell elemento concettuale collegato alla struttura fisica SCELEMTYPE: tipo dell elemento concettuale (in generale classe, strato, associazione). SCATTRNAME: nome dell attributo dell elemento concettuale associato all attributo fisico. SCATTRTYPE: tipo dell attributo concettuale. Nel caso degli attributi descrittivi (mono o multivalore) normali di classe o associazione, di componente spaziale, a tratti, eventi, sottoaree, nel caso dei ruoli e delle componenti spaziali (MI Shape_Flat e SQL_Flat) saranno riportati i nomi dell attributo pagina 20 di 42

21 concettuale e del relativo attributo fisico prodotto dal mapping e analogamente per i nomi delle classi, associazioni, strati e delle relative strutture fisiche. Il campo SCATTRTYPE qualifica il tipo di attributo o ruolo; ad esempio, possibili valori sono: attributo di classe, attributo enumerato o enumerato gerarchico di classe, di datatype, ruolo, attributo a tratti, attributo multivalore, enumerato multivalore, datatype multivalore, attributo geometrico, attributo geometrico collassato a linea o a punto, geometria di strato topologico. Nel caso del MI Shape_Flat nella colonna del nome dell attributo fisico associato alla componente spaziale si mette per convenzione il codice alfanumerico della componente spaziale concettuale (classi) e la costante geometria (strati) per identificare la geometria dello shape file. I modelli implementativi introducono nel mapping nuovi attributi fisici che comunque vengono, dove possibile, associati all elemento concettuale di riferimento. In particolare: - i MI Shape_Flat e MI SQL_Flat introducono attributi geometrici per descrivere la geometria minima degli attributi a eventi, tratti e a sottoaree che vengono associati concettualmente alla componente spaziale sulla quale sono definiti specificando in SCATTRTYPE: Geometria eventi minimi, Geometria dei tratti minimi, Geometria delle sottoaree minime; anche in questo caso si adottano le convenzioni precedenti sui nomi degli attributi fisici per il MI Shape_Flat. - Gli identificatori fisici ClassID, TopoID, EventID, SegmentID, SubRegID nei MI SQL_Flat monogeometria, Shape_Flat e MI Shape_Topo (UUID e UUIDref nel MI SQL ORACLE_Flat multigeometria) associati ai valori di SCATTRTYPE: identificatore univoco della classe, identificatore dello strato topologico, identificatore degli eventi puntiformi minimi, identificatore degli attributi a tratti minimi, identificatore degli attributi a sottoaree minime (rispettivamente).questi attributi vengono convenzionalmente associati all attributo concettuale ObjectID. - Gli attributi fisici ClassREF (UUIDREF nel MI SQL ORACLE_Flat multigeometria) delle tabelle degli attributi multivalore e datatype multivalore, delle tabelle dei tratti, eventi e sottoaree minime e delle tabelle delle componenti spaziali separate nei MI SQL_Flat monogeometria e Shape_Flat vengono associati rispettivamente all attributo multivalore e alla componente spaziale a cui si riferiscono le tabelle. Il MI Shape_Topo crea una struttura topologica nella quale un insieme di geometrie è riunita in un unico shape, pertanto l attributo geometrico della geometria topologica, l identificatore primid della singola geometria elementare, la coppia di attributi <primid, geoid> della tabella di composizione per la costruzione delle geometrie degli oggetti non hanno una relazione diretta con un particolare elemento della specifica concettuale; per questo motivo si adotta la convenzione di riportare nelle colonne di diagnostica del nome dell attributo e dell elemento concettuale il nome dell insieme topologico al quale si riferiscono, specificando nel tipo dell attributo concettuale il ruolo dell attributo fisico nell ambito dell insieme topologico: geometria insieme geometrico, primid, geoid nel dbf di composizione ; nel tipo dell elemento concettuale per convenzione si specifica invece Insieme geometrico. Si noti che per la geometria nella colonna del nome dell attributo fisico si riporta per convenzione geometria come nel caso del MI Shape_Flat. Infine gli attributi fisici delle componenti spaziali delle classi (strati) o delle geometrie minime dei tratti (eventi, sottoaree) non contengono la geometria effettiva, ma il geoid che identifica la geometria e pertanto il campo SCATTRTYPE riporta: geoid della classe, geoid dello strato pagina 21 di 42

22 topologico, geoid degli eventi minimi, geoid dei tratti minimi, geoid delle sottoaree minime. L identificazione dell oggetto che ha causato l errore avviene nei seguenti modi: l identificatore dell oggetto è memorizzato nella colonna OBJID (OBJID1 se la tabella prevede due identificatori) il nome dell attributo usato per l identificazione è memorizzato nella colonna SFPHYATTIDNAME (SFPHYATTID1NAME se la tabella prevede due identificatori) Nel seguito sono riportati gli attributi dell oggetto fisico utilizzati per l identificazione di ogni tipo di oggetto concettuale; se diversi MI prevedono diversi attributi fisici questi vengono riportati in alternativa tra loro, lasciando al lettore di riconoscere quello di interesse per il suo MI Classi: ClassID o UUID, Strati: TopoID, attributi a tratti: SegmentID, attributi a sottoaree: subregid, attributi a eventi: eventid, attributi multi valore: Classref o UUIDref, geometrie esterne (nei MI che la prevedono): ClassREF associazioni: si usano i due identificatori dei due oggetti che determinano l istanza di associazione coinvolta campi OBJID1 e OBJID2 - e i nomi dei due campi identificatori in SFPHYATTRID1NAME, SFPHYATTRID2NAME rispettivamente. 5.5 Contenuto generale delle tabelle di reportistica in base alla fase in cui sono prodotte La tabella INFO riporta dati inerenti la specifica di contenuto considerata, la DPS utilizzata per la validazione con i relativi parametri. Le tabelle PARAMETERSTEP e PROCESSSTEP riportano rispettivamente le informazioni sulla validazione eseguita; in particolare, esse riportano rispettivamente i parametri dell esecuzione della validazione e lo stato e il tempo di esecuzione delle varie fasi di validazione (Import process, Normalization process, Check process structure, Check process constraints). Le tabelle degli errori sono descritte nelle sottosezioni seguenti Tabelle generate in fase di caricamento Tabella ELEMENTSTATE Elenca le strutture fisiche previste dal MI riportandone l assenza o la presenza, e in questo caso il numero di record presenti. Tabella ATTRIBUTESTRUCTURE Riporta errori nella definizione del tipo degli attributi descrittivi, dei ruoli, delle componenti spaziali e degli attributi descrittivi aggiuntivi generati dal MI. Tabella WRONGATTRIBUTEVALUE riporta gli errori dovuti al fatto che un valore di un attributo descrittivo dichiarato nella tabella ATTRIBUTESTRUCTURE con ERROR= compatibilità possibile non sia congruente col tipo richiesto. pagina 22 di 42

23 Tabella GEOMETRYERROR riporta gli errori rilevati sulle geometrie delle componenti spaziali della sorgente, degli attributi a tratti, eventi, sottoaree dei MI SQL e MI Shape_Flat e le geometrie (archi e nodi) degli insiemi topologici. Tabella GEOCOMPATIBILITYWARNING (solo per i MI SQL_Flat) riporta le segnalazioni inerenti le geometrie che hanno un tipo diverso da quello richiesto, ma ritenuto compatibile (ad esempio, la geometria è di tipo multipoint e contiene un solo punto e il tipo richiesto è point). La geometria viene convertita al tipo richiesto e poi sottoposta ai controlli descritti nella sezione precedente e i cui errori saranno memorizzati nella tabella GEOMETRYERROR. Tabella METRICWARNING non riporta errori, ma segnalazioni inerenti alcuni controlli metrici effettuati sulle geometrie che sono state caricate nel DBF; tali segnalazioni sono da considerare dei possibili warning rispetto a possibili geometrie errate e non comportano l eliminazione della geometria dal DBF. Tabella MINIMUMDISTANCESHAPETOPO (solo per il MI Shape_TOPO) Riporta le geometrie che non soddisfano la distanza minima Tabelle generate in fase di normalizzazione La normalizzazione è un processo importante soprattutto nel MI Shape_Topo e che prevede la ricostruzione delle geometrie delle classi, strati e delle geometrie minime a partire dagli archi e dai nodi della sorgente (tabelle GEOCOMPATIBILITYWARNINGNORM, GEOMETRYERRORNORM e METRICWARNINGNORM). Nel MI SQL_Flat multigeometria non esiste questa fase e nei MI SQL_Flat_monogeometria (Oracle e Postgis) e Shape_Flat la normalizzazione è responsabile della riaggregazione delle componenti spaziali di una classe che nella sorgente sono memorizzate in strutture separate nella tabella della classe; ciò riguarda il caso di classi multigeometria, le componenti spaziali collassate e gli aggregati (Tabella STRUCTURALCONSTRAINTVIOLATIONNORM). Tabella ELEMENTSTATEDBF Riporta tutte le strutture fisiche previste dal MI e generate come tabelle nel DBF. La struttura è sostanzialmente identica alla tabella elementstate. Nei MI Shapeflat e Shape_Topo la tabella elemenstatedbf aggiunge anche le tabelle di NULL INTERPRETATION (_NI) assenti nella tabella elementstate caricandovi i valori dedotti dall analisi dei valori degli attributi. La cardinalità di una struttura fisica coincide con quella definita in elementstate per quelle presenti nella sorgente e 0 per quelle assenti. Tabella GEOCOMPATIBILITYWARNINGNORM Vedere analoga tabella del caricamento. Tabella GEOMETRYERRORNORM (solo MI Shape_Topo) ha la stessa struttura dell equivalente tabella del caricamento, ma fa riferimento anche alle geometrie ricostruite durante la fase di normalizzazione in base alle primitive topologiche Tabella METRICWARNINGNORM (solo MI Shape_Topo) ha la stessa struttura dell equivalente tabella del caricamento, ma riporta le segnalazioni metriche rilevate sulle geometrie ricostruite pagina 23 di 42

24 Tabella STRUCTURALCONSTRAINTVIOLATIONNORM riporta gli errori incontrati nella riaggregazione degli attributi geometrici delle classi Tabelle generate in fase di validazione Tabella ELEMENTSTATEDBN Riporta tutte le strutture fisiche previste dal MI normalizzato del validatore e memorizzate nel DB. Tabella STRUCTURALCONSTRAINTVIOLATION Riporta gli errori rispetto ai vincoli strutturali del GeoUML, ad esempio i vincoli di cardinalità Tabella FKCONSTRAINTVIOLATION Riporta i riferimenti errati tra oggetti Tabella GEOUMLCONSTRAINTNOTVERIFIED Tabella GEOMETRICCONSTRAINTVIOLATION Riporta le violazioni dei vincoli della specifica concettuale 5.6 Descrizione dettagliata delle tabelle del database di reportistica Tabelle per il controllo strutturale generate dai caricatori dei MI del validatore Tabella ELEMENTSTATE Struttura < ELEMENNAME, SCELEMTYPE, SFPHYSTRUCTNAME, CARDINALITY, STATE> Elenca le strutture fisiche previste dal MI riportandone l assenza (state=assente, cardinality = NULL) o la presenza (state = presente, cardinality = numero record presenti nella struttura fisica). Nel caso delle strutture fisiche _NI (null value interpretation nei MI SQL_Flat) SCELEMTYPE riporterà Attributi nulli e SCELEMENNAME oltre al nome della classe (strato, associazione) potrà specificare il nome dell attributo concettuale nel caso di tabella _NI associata alla struttura fisica di un attributo multivalore (semplice, datatype e attributo di attributo geometrico) oppure la stringa concatenata Attributi a tratti di (Attributi a sottoaree di, Eventi puntiformi di) seguito dal nome dell associata componente spaziale e dal nome della classe nel caso in cui la tabella _NI sia associata alla tabella dei tratti (eventi, sottoaree) minime. Es. <CARDINALITY,SCELEMENNAME, SCELEMTYPE, SFPHYSTRUCTNAME, STATE> 6 Area di circolazione ciclabile Classe AC_CIC presente Rete stradale liv.1 Classe RT_ST1 assente Attributi a sottoaree di Sup_estensione 74 (Classe Bosco ) Attributi nulli BOSCO_BOSCO_SUP_SR_NI presente Tabella ATTRIBUTESTRUCTURE Struttura < SCELEMNAME, SCELEMTYPE, SCATTRNAME, SCATTRTYPE, SFPHYSTRUCTNAME, SFPHYATTRNAME, ERRLEV, ERROR > pagina 24 di 42

25 Riporta eventuali errori nella definizione del tipo degli attributi descrittivi, dei ruoli, delle componenti spaziali e degli attributi descrittivi aggiuntivi generati dal MI. Il controllo di tipo delle componenti spaziali o delle geometrie dei tratti (eventi, sottoaree) minimi consiste nella sola verifica che l attributo sia di tipo geometrico (ulteriori controlli sono delegati a controlli successivi) nei MI Oracle_SQL_Flat mono/multi geometria e Postgis_SQL_Flat monogeometria. Nei MI SHape_Flat e Shape_Topo invece si controlla la corrispondenza della specifica tipologia (ad es., polyline) prevista rispetto a quella della sorgente. Si possono verificare 4 casi: - l attributo previsto non esiste nella sorgente (ERRLEVEL=E(error) e ERROR=assente): nel DBF viene definito l attributo e in ogni record sarà caricato NULL nell attributo; - l attributo è di tipo incompatibile (ERRLEVEL = E(error) e ERROR=tipo incompatibile): tutti i valori dell attributo nella sorgente sono sostituiti da NULL nel DBF; - l attributo descrittivo ha un tipo diverso, ma compatibile (ERRLEVEL=W(warning) e ERROR= tipo compatibile): il tipo della sorgente è più restrittivo di quello richiesto e quindi sarà convertito nel DBF (ad esempio tipo consegnato è una string(m) e quello richiesto è string(n) con n>m). Questo tipo di segnalazione viene effettuata anche quando una componente spaziale richiesta è di tipo multipoint e la sorgente è dichiarata di tipo point (nei soli MI SHape_Flat e Shape_Topo); - l attributo descrittivo ha un tipo diverso, ma potenzialmente compatibile (ERRLEVEL=W(warning) e ERROR= compatibilità possibile): il tipo della sorgente è meno restrittivo di quello richiesto, ma i valori dell attributo potrebbero essere compatibili; (ad esempio tipo consegnato è una string(m) e quello richiesto è string(n) con n<m). Questo tipo di segnalazione viene effettuata anche quando una componente spaziale richiesta è di tipo point e la sorgente è dichiarata di tipo multipoint (nei soli MI SHape_Flat e Shape_Topo); Tabelle per la verifica dei valori degli attributi generate dai caricatori dei MI del validatore Si noti che: - i valori NULLI presenti negli attributi (descrittivi o geometrici) della sorgente vengono ricopiati nel DBF senza generare alcuna diagnostica; saranno i controlli successivi a verificare la correttezza di tale mancanza di informazione; - la stringa di caratteri (o di numeri) vuota ( ) in qualsiasi attributo descrittivo (incluso ClassID, SegmentID, eventid,subregid) provoca l inserimento di un NULL nel DBF senza generazione di diagnostica; - una geometria vuota viene sostituita dal valore NULL nel DBF senza generazione di diagnostica Tabella WRONGATTRIBUTEVALUE Struttura <SCELEMNAME,SCELEMTYPE,SCATTRNAME,SCATTRTYPE, SFPHYSTRUCTNAME,SFPHYATTRNAME, ERRLEV, ERROR, WRONGVALUE, SFPHYATTRID1NAME, SFPHYATTRID2NAME, OBJID1, OBJID2, > Questa tabella riporta gli errori dovuti al fatto che un valore di un attributo descrittivo dichiarato nella tabella ATTRIBUTESTRUCTURE con ERROR= compatibilità pagina 25 di 42

26 possibile non sia congruente col tipo richiesto. Il valore descrittivo errato viene riportato nel campo WRONGVALUE. Si distinguono due casi: - valore incompatibile (ERRLEVEL=E(error) e ERROR= boolean sconosciuto) applicato a valori di tipo boolean: il valore logico è stato codificato con un valore non riconoscibile e quindi viene sostituito con NULL nel DBF; - valore convertito: in questo caso il valore della sorgente viene adattato al tipo richiesto; ad esempio, se il tipo richiesto è string(n) e la stringa della sorgente è più lunga, la stringa viene troncata alla lunghezza n segnalando ERROR= tronco a lunghezza n. Il valore viene quindi modificato e inserito nel DBF e pertanto nella tabella si riporta solo una segnalazione ERRLEVEL=W(warning) e in ERROR si riporterà l operazione eseguita. I campi SFPHYATTRID1NAME, SFPHYATTRID2NAME, OBJID1, OBJID2 sono usati per l identificazione dell oggetto a cui appartiene l attributo. Tabella GEOMETRY ERROR Struttura <SCELEMNAME,SCELEMTYPE,SCATTRNAME,SCATTRTYPE SFPHYSTRUCTNAME,SFPHYATTRNAME, ERRLEV, ERROR, GEOMETRY SFPHYATTRIDNAME, OBJID> Questa tabella riguarda gli errori rilevati sulle geometrie delle componenti spaziali della sorgente, degli attributi a tratti, eventi, sottoaree dei MI SQL e MI Shape_Flat e le geometrie (archi e nodi) degli insiemi topologici del MI Shape_Topo. In particolare si effettuano due tipi di controlli: - nei MI SQL_Flat si verifica che la geometria contenuta in un attributo geometrico della sorgente corrisponda al tipo richiesto dal MI; nei MI Shape questo controllo è effettuato nella verific effettuata per la tabella AttributeStructure; - per tutti i MI: controllo delle caratteristiche dell ESFM del GeoUML. Le geometrie errate sono memorizzate nel campo GEOMETRY definito di tipo blob e codificato in WKB. L oggetto interessato è identificato nei campi SFPHYATTRIDNAME, OBJID. Si hanno due tipi di errore: 1. geometria incompatibile (ERRLEVEL=F(fatal) e ERROR=geometria errata): la geometria è eliminata e viene inserito NULL nel DBF; La verifica di tipo degli attributi descrittivi e delle geometrie dei MI Shape avviene prima e gli esiti sono memorizzati nella tabella ATTRIBUTESTRUCTURE. Il controllo del tipo delle geometrie dei MI SQL_Flat viene effettuato durante la valutazione della qualità della singola geometria, pertanto il tipo derivato dalla geometria può risultare corretto (nessuna segnalazione e il valore viene caricato nel DBF), incompatibile (Fatal error precedente) o compatibile; in questo ultimo caso si esegue una conversione del tipo (segnalazione nella tabella GEOCOMPATIBILITYWARNING) e il valore viene caricato nel DBF. 2. violazione proprietà GeoUML: viene segnalato l errore e nel caso in cui sia di livello Fatal si inserisce NULL nel DBF, mentre nel caso sia di livello error la geometria è comunque inserita nel DBF. Nella seguente tabella si elencano le tipologie di violazione delle proprietà GeoUML, riportando i valori di ERROR e ERRLEVEL, la descrizione del controllo eseguito sui valori dei diversi tipi geometrici; si noti che un pagina 26 di 42

27 controllo definito per un tipo GeoUML si applica anche alle sue specializzazioni definite nella gerarchia dei tipi del GeoUML e che nel MI Shape_Topo in questa tabella si riportano gli errori delle geometrie degli insiemi topologici (punti, curve) e non quelli delle componenti spaziali o delle geometrie minime poiché non sono ancora state ricostruite. Tipo geometrico GeoUML Descrizione controllo Error Error Tutti i tipi 2D Tutti i tipi 3D e le superfici B3D Tutti i tipi ad eccezione dei punti, multipunto e dei punti negli aggregati Tutti i tipi di tipo curva e le curve degli aggregati GU_CPSurface2D, GU_CXSurface2D, GU_CPSurfaceB3D, GU_CXSurfaceB3D Superfici di un GU_Aggregate2D e GU_Aggregate3D GU_CPCurve2D/3D, GU_CXCurve2D/3D GU_CNCurve2D/3D,Curve in GU_Aggregate2D/3D (curve semplici, anelli e frontiere di superfici già garantite da altro controllo) GU_CXCurve2D, GU_CXCurve3D, GU_CXRing2D, GU_CXRing3D, GU_CNCurve2D, GU_CNCurve3D (frontiere delle superfici già garantite da altro controllo) Esistenza dei valori per X e Y e non Z in coordinata 2D errata tutti i punti (vertici, estremi) della geometria Esistenza dei valori per X e Y e Z in tutti i coordinata 3D errata punti (vertici, estremi) della geometria Rimozione di vertici adiacenti nella Vertici 2D/3D adiacenti dimensione del tipo (2D/3D) duplicati in duplicati ogni curva/frontiera Esistenza di almeno 2 vertici in ogni curva Meno di due vertici componente Esistenza di almeno 4 vertici in ogni frontiera - anche sulle frontiere proiettate delle superfici B3D non considerando vertici duplicati Assenza di selfoverlapping in ogni curva componente Assenza di overlap tra due curve componenti GU_CPSimpleCurve2D/3D,GU_CPRing2D/3D, Ogni curva/frontiera componente sia GU_CXRing2D/3D, GU_CPSurface2D, semplice GU_CXSurface2D, GU_CPSurfaceB3D, GU_CXSurfaceB3D Superfici di GU_Aggregate2D/3D GU_CPRing2D/3D, GU_CXRing2D/3D, GU_CPSurface2D, GU_CXSurface2D, GU_CPSurfaceB3D, GU_CXSurfaceB3D, Superfici di GU_Aggregate2D/3D Meno di 4 vertici level F F W curva2d/3d sovrapposta, E curva complessa 2D/3D sovrapposta F F E curva2d (anello2d) non E semplice, curva3d (anello3d) non semplice, frontiera esterna 2D (interna 2D) non semplice, frontiera 3D non semplice Ogni curva/frontiera componente sia chiusa curva2d (3D) non chiusa, Frontiera 2D (3D) non chiusa, oppure quando anello 2D/3D non chiuso PathConnected Le superfici componenti possono toccarsi al più in punti GU_CNCurve2D/3D Connessione della curva complessa curva complessa 2D (3D) non connessa Esistenza della frontiera esterna in ogni frontiera esterna 2D (3D) F superficie componente mancante Assenza di buchi esterni alla propria superficie 2D con buco E superficie componente esterno Assenza di buchi che toccano la frontiera intersezione 2D errata E esterna della propria superficie componente frontiera esterna e interna in più di un punto GU_CPSurface2D GU_CXSurface2D Assenza di buchi che contengono altri buchi buco 2D innestato E GU_CPSurfaceB3D GU_CXSurfaceB3D della stessa superficie Superfici di un GU_Aggregate2D e di un Assenza di buchi che toccano un altro buco intersezione 2D errata tra E GU_Aggregate3D della stessa superficie in più di un punto buchi Ogni superficie componente sia superficie 2D non path- E connessa Intersezione 2D errata tra superfici E E pagina 27 di 42

28 Tabella GEOCOMPATIBILITYWARNING (solo per i MI SQL_Flat) Struttura < SCELEMNAME, SCELEMTYPE, SCATTRNAME, SCATTRTYPE SFPHYSTRUCTNAME, SFPHYATTRNAME, ERROR, GEOMETRY, SFPHYATTRIDNAME, OBJID> Questa tabella riporta le segnalazioni inerenti le geometrie che hanno un tipo diverso da quello richiesto, ma ritenuto compatibile (ad esempio, la geometria è di tipo multipoint e contiene un solo punto e il tipo richiesto è point). La geometria viene quindi convertita al tipo richiesto e poi sottoposta ai controlli descritti nella sezione precedente che segnaleranno gli errori nella tabella GEOMETRYERROR. Attualmente si riporta la geometria convertita (campo GEOMETRY), l identificazione dell oggetto interessato (campi SFPHYATTRIDNAME, OBJID) e nel campo ERROR il valore conversione di tipo TABELLA METRICWARNING Struttura <SCELEMNAME,SCELEMTYPE,SCATTRNAME,SCATTRTYPE SFPHYSTRUCTNAME,SFPHYATTRNAME, ERROR, GEOMETRY SFPHYATTRIDNAME, OBJID> Questa tabella non riporta errori, ma segnalazioni inerenti alcuni controlli metrici effettuati sulle geometrie che sono state caricate nel DBF; tali segnalazioni sono da considerare dei possibili warning rispetto a possibili geometrie errate e non comportano l eliminazione della geometria dal DBF. In particolare, sono segnalati gli oggetti che hanno valori sotto soglia in alcuni controlli metrici, riportandone la geometria e l identificazione dell oggetto di appartenenza. I valori di soglia sono inseriti in fase di parametrizzazione del GeoUML validator. I tipi di errore riportati nel campo ERROR sono: segmento o curva sotto soglia, cuspide, perimetro poligono sotto soglia, area sotto soglia, troppi vertici. L identificazione dell oggetto interessato avviene tramite i campi SFPHYATTRIDNAME, OBJID. Tabella MINIMUMDISTANCESHAPETOPO (solo MI Shape_Topo) Struttura <DISTANCETYPE, GEOMETRYSETNAME1, PRIMIDNAME1, PRIMIDVALUE1, GEOMETRYSETNAME2, PRIMIDNAME2, PRIMIDVALUE2, DISTANCEVALUE, DISTANCEGEOMETRY BLOB> La tabella riporta le geometrie primitive che non soddisfano la distanza minima all interno di ogni insieme topologico. Questa tabella associa la diagnostica alle solo primitive fisiche che saranno poi usate per la ricostruzione delle componenti spaziali degli elementi concettuali. Per ogni violazione riporta il tipo (DISTANCETYPE) delle primitive confrontate (punto/punto, punto/segmento, segmento/segmento), gli shape delle due primitive (GEOMETRYSETNAME), l identificatore delle due primitive (PRIMIDVALUE), il valore della distanza calcolata (DISTANCEVALUE) e infine il segmento che visualizza la distanza tra le due primitive (DISTANCEGEOMETRY BLOB). pagina 28 di 42

29 5.6.3 Tabelle generate nel processo di normalizzazione La normalizzazione è un processo importante soprattutto nel MI Shape_Topo e che prevede la ricostruzione delle geometrie delle classi, strati e delle geometrie minime a partire dagli archi e dai nodi della sorgente (tabelle GEOCOMPATIBILITYWARNINGNORM, GEOMETRYERRORNORM e METRICWARNINGNORM). Inoltre è verificata la congruenza delle strutture fisiche utilizzate nella ricostruzione, specificando eventuali errori nella tabella STRUCTURALCONSTRAINTVIOLATIONNORM. Nel MI SQL_Flat multigeometria non esiste questa fase e nei MI SQL_Flat_monogeometria (Oracle e Postgis) e Shape_Flat la normalizzazione è responsabile della riaggregazione delle componenti spaziali di una classe che nella sorgente sono memorizzate in strutture separate nella tabella della classe; ciò riguarda quindi le classi con più componenti spaziali, le componenti spaziali collassate e gli aggregati (Tabella STRUCTURALCONSTRAINTVIOLATIONNORM). TABELLA ELEMENTSTATEDBF Struttura < ELEMENNAME, SCELEMTYPE, SFPHYSTRUCTNAME, CARDINALITY > Riporta tutte le strutture fisiche previste dal MI e generate come tabelle nel DBF. Per ogni struttura si riporta l elemento concettuale di appartenenza col tipo e la cardinalità (cardinality =0 se la struttura era assente in elementstate o presente, ma senza record). La struttura è sostanzialmente identica alla tabella elementstate. Nei MI Shape-flat e Shape_Topo la tabella elemenstatedbf aggiunge anche le tabelle di NULL INTERPRETATION (_NI) assenti nella tabella elementstate caricandovi i valori dedotti dall analisi dei valori degli attributi. La cardinalità di una struttura fisica coincide con quella definita in elementstate per quelle presenti nella sorgente e 0 per quelle assenti. TABELLA GEOCOMPATIBILITYWARNINGNORM (solo MI Shape_Topo) Struttura: < SCELEMNAME, SCELEMTYPE, SCATTRNAME, SCATTRTYPE SFPHYSTRUCTNAME, SFPHYATTRNAME, ERROR, GEOMETRY, SFPHYATTRIDNAME, OBJID> Questa tabella ha lo stesso obiettivo della tabella GEOCOMPATIBILITYWARNING applicata alle geometrie ricostruite, il cui tipo viene riconosciuto dopo la ricostruzione e nel caso in cui sia diverso dal richiesto, ma compatibile viene convertito segnalandolo in questa tabella. Successivamente è sottoposto ai controlli della qualità geometrica della tabella GEOMETRYERRORNORM. L identificazione dell oggetto interessato avviene tramite i campi SFPHYATTRIDNAME, OBJID. TABELLA GEOMETRYERRORNORM (solo MI Shape_Topo) Struttura <SCELEMNAME,SCELEMTYPE,SCATTRNAME,SCATTRTYPE SFPHYSTRUCTNAME,SFPHYATTRNAME, ERRLEV, ERROR, GEOMETRY SFPHYATTRIDNAME, OBJID> La tabella GEOMETRYERRORNORM ha la stessa struttura dell equivalente tabella del caricamento e riporta: pagina 29 di 42

30 - gli errori incontrati nella topologia degli insiemi topologici ad eccezione della verifica della qualità degli edge (curva semplice - verificato in caricamento); le geometrie errate sono comunque conservate nel DBF. ERRLEVEL è sempre E e i valori di ERROR sono i seguenti (la diagnostica non riporta in generale e, in generale, la dimensione della geometria derivabile peraltro dallo shape di appartenenza: - segmento verticale: segmento 3D verticale; - toposhape dj or tc on boundary error: archi che violano la relazione DJ or TC sui boundary; - primitiva topologica duplicata: nodi che violano la relazione DJ - node edge consistency error: nodo che viola relazione di DJ or TC con arco - geometry 3d2d consistency error: la proiezione planare di un arco 3D non trova il corrispondente arco 2D o la proiezione planare di un nodo 3D non trova il corrispondente nodo 2D. - l incompatibilità del tipo della geometria ricostruita dagli archi/nodi dell insieme topologico (ERROR = SELECT_DERIVATION_ERROR); - Errore nella derivazione dei poligoni 3d che rileva una differenza tra la frontiera del poligono generato e quella che si genererebbe unendo le primitive 3d che lo compongono nella tabella di composizione. ERROR = DERIVATION_ERROR_BOUNDARY ; - gli errori della geometria ricostruita nel rispettare le caratteristiche del modello ESFM del GEOUML (i valori di ERROR sono quelli specificati per la tabella GEOMETRYERROR). A differenza della tabella GEOMETRYERROR del caricatore la colonna GEOMETRY riporta la geometria errata della sorgente per gli errori sulle primitive topologiche e la geometria errata dopo la sua ricostruzione negli altri casi. L identificazione dell oggetto interessato avviene tramite i campi SFPHYATTRIDNAME, OBJID. TABELLA METRICWARNINGNORM (solo MI Shape_Topo) Struttura <SCELEMNAME,SCELEMTYPE,SCATTRNAME,SCATTRTYPE SFPHYSTRUCTNAME,SFPHYATTRNAME, ERROR, GEOMETRY SFPHYATTRIDNAME, OBJID> La tabella METRICWARNINGNORM ha la stessa struttura dell equivalente tabella METRICWARNING del caricamento, ma riporta le segnalazioni metriche rilevate sulle geometrie ricostruite L identificazione dell oggetto interessato avviene tramite i campi SFPHYATTRIDNAME, OBJID. Tabella STRUCTURALCONSTRAINTVIOLATIONNORM Struttura <SCCONSTRAINTDESCR, SCLIVSCALA SCELEMNAME, SCELEMTYPE, SCATTRNAME, SCATTRTYPE, SFPHYSTRUCTNAME, SFPHYATTRNAME, ERROR, ERRLEV, VALUE, SFPHYID1, SFPHYID2, OBJID1, OBJID2> pagina 30 di 42

31 Un primo tipo di errori rilevati in questa tabella riguarda la riaggregazione di più attributi geometrici (anche quelli prodotti dal mapping per il collassamento o quelli di un aggregato) di una stessa classe che vengono riuniti nella struttura fisica della classe (fusi nel caso dell aggregato); la riaggregazione utilizza i valori dell attributo ClassREF della struttura fisica della geometria separata e l attributo ClassID della struttura fisica della classe. L identificazione del record della geometria da riaggregare che presenta un errore avviene tramite i campi SFPHYID1, SFPHYID2, OBJID1, OBJID2, mentre nel campo VALUE si riporta il valore di ClassREF della struttura fisica della geometria separata. SCCONSTRAINTDESCR riporta chiavi esportate per segnalare un problema inerente la correlazione tra strutture fisiche diverse. Non tutte le situazioni anomale che si possono verificare generano diagnostica, pertanto si dettagliano le situazioni anomale e il comportamento del validatore: - più record della struttura fisica della geometria si riferiscono ad uno stesso oggetto della classe; un valore geometrico non può essere scomposto su più record. Viene segnalato riferimento duplicato nel campo ERROR e ERRLEV = E e le geometrie sono eliminate e viene inserito un NULL nell attributo geometrico riaggregato nel record della classe; - nessun record della struttura fisica della geometria si riferisce ad un oggetto della classe. In questo caso viene inserito NULL nell attributo geometrico riaggregato nel record della classe senza segnalazione di diagnostica; - un record della struttura fisica della geometria si riferisce ad un identificatore di oggetto che è duplicato in più oggetti della classe. La geometria viene riportata nell attributo geometrico riaggregato di tutti gli oggetti che condividono l identificatore senza alcuna segnalazione diagnostica; - un record della struttura fisica della geometria non trova alcun oggetto corrispondente della classe. La geometria è eliminata senza alcuna segnalazione diagnostica. Un secondo tipo di errore riguarda le corrispondenze tra strutture fisiche degli insiemi topologici. Anche in questo caso SCCONSTRAINTDESCR riporta chiavi esportate e ERRLEVEL è sempre E.. In particolare i casi segnalati sono i seguenti: - una primitiva geometrica non è utilizzata per ricostruire alcuna componente spaziale o geometria dei tratti, L identificatore PRIMID di una primitiva di uno shape topologico non viene referenziato nel campo PRIMID della tabella di composizione. Il campo ERROR riporta: PRIMID not in component; - una geometria ricostruita referenzia una primitiva topologica che non esiste. Un valore di PRIMID della tabella di composizione non si relaziona ad alcun identificatore di primitiva nello shape. Il campo ERROR riporta: COMPONENT PRIMID not in topological shape; - una geometria ricostruita non appartiene a nessun attributo geometrico di classe, strato, di geometria minima. L identificatore GEOID di una geometria ricostruita presente nella tabella di composizione non viene referenziato da nessun oggetto di classe, strato e da nessun tratto, evento, sottoarea minimo dell insieme topologico considerato. Il campo ERROR riporta: Component GEOID not in geometry; pagina 31 di 42

32 - una classe, strato tratto, evento, sottoarea referenzia una geometria ricostruita che non esiste. In una classe, strato, geometria minima si riferisce un GEOID assente nella tabella di composizione corrispondente. Il campo ERROR riporta: geometry GEOID not in component. - Incongruenza tra una geometria 3D e la corrispondente 2D nel caso degli insiemi topologici 5.6.4Tabelle generate dai controlli sul DBN Tabella ELEMENTSTATEDBN Struttura < SCELEMENNAME, SCELEMTYPE, SFPHYSTRUCTNAME, CARDINALITY> La tabella riporta tutte le strutture fisiche previste dal MI normalizzato del validatore e memorizzate nel DBN. Nel caso di MI Shape_Topo il DBN non contiene più le tabelle dell insieme topologico in quanto sono state materializzate le geometrie nelle tabelle di classe, strato, tratti, eventi, sottoaree. Nei MI Shape_Flat e SQL_Flat monogeometria il DBN contiene in generale meno tabelle del DBF in quanto le classi con più attributi geometrici e presenti in strutture fisiche separate vengono riunite in una sola struttura fisica normalizzata nel DBN. Lo scopo di questa tabella è quello di fornire le cardinalità delle nuove strutture dati generate utili ad una valutazione dell incidenza percentuale degli errori generati dai controlli strutturali e dai controlli dei vincoli spaziali. Per ogni struttura fisica si riporta cardinality =0 se la struttura è vuota o erano vuote o inesistenti le strutture dati di generazione nella tabella elemenstatedbf. Nei MI SQL_Flat multigeometria esse coincidono con quelle del DBN. Tabella STRUCTURALCONSTRAINTVIOLATION Struttura <SCCONSTRAINTDESCR, SCLIVSCALA SCELEMNAME, SCELEMTYPE, SCATTRNAME, SCATTRTYPE SFPHYSTRUCTNAME, SFPHYATTRNAME, ERROR, ERRLEV, VALUE, SFPHYID1, SFPHYID2, OBJID1, OBJID2 ERRLEVEL è sempre E per tutte le segnalazioni di questa tabella. CONSTRAINTDESCR = Cardinalità. Assenza NULL in attributi concettuali obbligatori o in attributi aggiunti dal MI e definiti obbligatori dal MI. 1. Obbligatorietà degli identificatori ClassID (UUID nel MI SQL_FLAT Oracle multigeometria) delle classi, TopoID (UUID nel MI SQL_FLAT Oracle multigeometria) degli strati, eventid, subregid, segmentid nelle corrispondenti tabelle degli eventi, tratti, sottoaree. Il campo ERROR= Valori nulli nell object ID; si noti che in questo caso non è possibile identificare il record errato e quindi i campi di identificazione contengono NULL e il campo VALUE contiene per convenzione #uuid nulli ; 2. Obbligatorietà degli attributi descrittivi e dei ruoli nelle classi e nelle associazioni e dei ruoli negli strati. VALUE = NULL, ERROR = cardinalità minima violata. 2.1 attributi monovalore e ruoli delle classi, strati e associazioni. L oggetto con errore è identificato tramite il valore di ClassID (UUID) per attributi pagina 32 di 42

33 monovalore e ruoli di una classe, TopoID(UUID) per i ruoli degli strati, col valore di ClassREF (UUIDref) congiunto a eventid (subregid, segmentid) nelle tabelle per eventi (tratti, sottoaree) e con la coppia <ruolo1, ruolo2> per le associazioni. 2.2 attributi multivalore (anche datatype) delle classi e delle associazioni si segnalano due situazioni di errore sulla tabella multivalore che si differenziano nell identificazione: - righe con NULL nell attributo descrittivo (o in uno degli attributi nel datatype). L identificazione della riga avviene tramite ClassREF (UUIDref) per gli attributi delle classi e tramite la coppia <ruolo1, ruolo2> nel caso di associazione; - inesistenza di un record nella tabella per un oggetto. In questo caso è identificato l oggetto mancante tramite ClassID (UUID) per gli attributi delle classi e tramite la coppia <ruolo1, ruolo2> nel caso di associazione. 3. Obbligatorietà degli attributi ClassREF (UUIDref nel MI SQL_FLAT Oracle multigeometria) delle tabelle degli attributi multivalore (anche datatype), delle tabelle degli eventi, tratti, sottoaree associate a classi o ad associazioni e obbligatorietà dei ruoli delle tabelle delle associazioni. Il campo ERROR= Valori nulli nei riferimenti a object ID; si noti che in questo caso non è possibile identificare il record errato e quindi i campi di identificazione contengono NULL e il campo VALUE contiene per convenzione #ref nulli ; CONSTRAINTDESCR = Univocità. Assenza di duplicazione negli attributi concettuali dichiarati primary key e in quelli multivalore anche datatype; inoltre si controlla l univocità anche sugli identificazione introdotti dai MI. 1. Duplicati negli identificatori ClassID (UUID) per le classi, TopoID(UUID) per gli strati, ERROR= Valori duplicati nell object ID, VALUE = #ripetizioni UUID. I campi di identificazione riporteranno il valore dell identificatore duplicato. 2. Duplicati negli identificatori eventid (subregid, segmentid) nelle tabelle degli eventi (tratti, sottoaree). ERROR = UUID degli eventi duplicati (UUID dei tratti duplicato, UUID delle sottoaree duplicati, VALUE = #ripetizioni UUID. I campi di identificazione riporteranno il valore dell identificatore duplicato. 3. Righe duplicate nella tabella multivalore (anche datatype). ERROR = valori duplicati, VALUE = #duplicati, l identificazione del record avviene tramite il valore di ClasseREF (UUIDref). 4. Duplicazione della geometria di eventi, tratti, sottoaree. ERROR = eventi con duplicazione geometrica (tratti con duplicazione geometrica, sottoaree con duplicazione geometrica). I campi di identificazione riporteranno il valore dell identificatore degli eventi, tratti, sottoaree duplicati. 5. Più righe di una tabella di associazione si riferiscono alla stessa coppia di oggetti. ERROR = valori duplicati nei riferimenti all object ID, VALUE = #duplicati, i campi identificatori contengono gli identificatori dei due ruoli coinvolti. Tabella FKCONSTRAINTVIOLATION Struttura < SCCONSTRAINTDESCR, SCLIVSCALA, SCELEMNAME,SCELEMTYPE,SCATTRNAME,SCATTRTYPE SFPHYSTRUCTNAME,SFPHYATTRNAME, ERROR, ERRLEVEL, VALUE SFPHYID, SFPHYID2, OBJID1, OBJID2> pagina 33 di 42

34 ERRLEVEL è sempre E per tutte le segnalazioni di questa tabella. CONSTRAINTDESCR = chiavi esportate. Queste segnalazioni riguardano i ruoli o gli attributi ClassREF (UUIDref) che non referenziano oggetti esistenti. Per questi errori ERROR = Riferimento a object ID inesistente, 1. Ruoli in classe o strato riportano un identificatore di un oggetto che non esiste nello strato o nella classe referenziata (includendo le classi sue specializzazioni). VALUE contiene l identificatore non trovato, i campi identificatori riportano l identificatore dell oggetto della classe, strato errato. 2. Almeno uno dei due ruoli di un associazione contiene un identificatore che non esiste nello strato o nella classe referenziata (includendo le classi sue specializzazioni). Questa segnalazione produce due record di diagnostica. VALUE contiene nei due record il valore dei due ruoli, i campi identificatori riportano la coppia dei valori dei due ruoli. 3. L attributo ClassREF (UUIDref) delle tabelle degli eventi, tratti, sottoaree o delle tabelle multivalore (anche datatype) riporta un identificatore di un oggetto inesistente nella classe (o sue specializzazioni) referenziata. VALUE contiene l identificatore non trovato, i campi identificatori riportano l eventid, segmentid, subregid dell evento, tratto, sottoarea o del multivalore errato. 4. La coppia di attributi che correlano un attributo multivalore (anche datatype) ad una istanza di associazione non trova una corrispondente coppia nell associazione. VALUE=NULL e i campi identificatori riportano la coppia dei valori errati. CONSTRAINTDESCR = chiavi esportate. Queste segnalazioni riguardano gli attributi con dominio enumerato che contengono un valore inesistente nel dominio. Per questi errori ERROR = Riferimento a codice inesistente, VALUE riporta il valore inesistente I campi identificatori della diagnostica riportano il ClassID degli oggetti col codice errato, l eventid (segmentid, subregid) dell evento (tratto, sottoarea) con il codice errato, o il ClassREF nel caso di attributi multivalore (anche datatype) col codice errato. Nel caso delle associazioni i campi identificatori contengono la coppia di ruoli di identificazione dell associazione. Tabella GEOUMLCONSTRAINTNOTVERIFIED Struttura < SCCONSTRAINTNAME, INFOMESSAGE, CONSTRAINTTYPE> Questa tabella elenca i vincoli spaziali che non sono stati eseguiti in quanto assente l elemento vincolato o vincolante. Il campo SCCONSTRAINTNAME riporta la descrizione del vincolo non verificato (ad es., GZ_STR.Posizione ( DJ) perogni GZ_STR.Posizione). INFOMESSAGE segnala se sia assente l elemento vincolato (D) o quello vincolante (G) e infine CONSTRAINTTYPE riporta il tipo di vincolo (ad es., composedof, exists). pagina 34 di 42

35 Tabella GEOMETRICCONSTRAINTVIOLATION Struttura <SCCONSTRAINTNAME, CONSTRAINTTYPE, SCLIVSCALA SCVINCOLATANAME, SCELEMTYPE, SCATTRNAME, SCATTRTYPE, SFPHYSTRUCTNAME, SFPHYATTRNAME, GEOMETRY> Questa tabella contiene una riga per ogni violazione riscontrata di un Vincolo Spaziale GeoUML. SCCONSTRAINTNAME riporta la descrizione del vincolo controllato (ad es., CANALE.Percorso.BND ( IN) unione ND_IDR.Posizione), CONSTRAINTTYPE riporta il tipo di vincolo (ad es., composedof, exists) e infine GEOMETRY riporta la geometria vincolata errata. pagina 35 di 42

36 Appendice 1. Installazione, esecuzione e aggiornamento del GeoUMLvalidator 1.1 Requisiti Installazione di una Java runtime machine JRE versione1.5 o superiore Sistemi operativi Windows, Unix-like (linux, MacOS10 o superiori, Sun Solaris..) 50MB liberi ad installazione effettuata per i file temporanei. Installazione dei sistemi Postgres e PostGIS Creazione dei database di appoggio Per la validazione di dataset Oracle è necessario aggiungere al Validator la libreria proprietaria Oracle JDBC (ojdbc14.jar ) scaricabile da: Dopo averla scaricata deve essere inserirla nella cartella lib del Validator 1.2 Installazione del GeoUML Validator completo (per la pubblica amministrazione) Dopo aver effettuato il download dal sito spatialdbgroup.polimi.it del file.zip contenente il programma è sufficiente estrarre il contenuto del file in una cartella scelta dall utente. L estrazione genera una cartella chiamata GeoUML-Validator contenente il programma, la licenza accettata all atto del download (GeoUML per soggetti di diritto pubblico.txt) e la licenza da far controfirmare dal soggetto di diritto privato al quale si fornisce il Validator chiuso generato dal GeoUML Validator completo (GeoUML validator Chiuso.txt) e la cartella Report per la produzione del documento di reportistica degli errori. 1.3 Esecuzione del programma Per avviare il programma eseguire il file GeoUMLvalidator.exe per i sistemi operativi Windows oppure./geoumlvalidator.sh da console /bin/bash o /bin/sh per i sistemi operativi Unix-like (in questo caso è necessario che il file abbia i permessi che rendono l esecuzione possibile); qualora i tempi di esecuzione siano troppo alti è possibile migliorare le prestazioni del validator, ottimizzando alcuni parametri nei file GeoUMLvalidator.bat (Windows) o GeoUMLvalidator.sh (Unix-like) e utilizzare poi questi file per l esecuzione. Sebbene nei due file esistano alcuni commenti per l ottimizzazione si ricorda che tale operazione richiede personale esperto che sappia pagina 36 di 42

37 valutare correttamente le conseguenze di tali operazioni. Il download del validator genera automaticamente l icona dell applicazione nel caso del sistema operativo MacOS10x. 1.4 Creazione dei database di appoggio Dopo aver installato Postgres e PostGIS è necessario creare i database di appoggio in Postgres; si ricorda che i database di appoggio sono due nel caso dei modelli implementativi Shape e uno solo nel caso dei modelli implementativi SQL_Flat (si omette il database di normalizzazione). Si illustrano nel seguito le operazioni da eseguire per la creazione dei database, utilizzando l interfaccia PgAdmin di Postgres e supponendo di creare due database sullo stesso calcolatore sul quale si è installato il Validator. L interfaccia PgAdmin propone alla sinistra l elenco dei server disponibili. Selezionando Localhost (server sul quale si stannno effettuando queste operazioni) con un doppio click, appaiono le voci Database, Tablespace,. Posizionarsi sulla voce Database, premere tasto destro del mouse e selezionare la voce Nuovo database. Appare la scheda mostrata in figura nella quale va inserito nel campo Nome il nome che assegnate al primo database di appoggio (in figura si assegna il nome DBF, supponendo che sia quello usato per il caricamento dei dati da controllare), selezionato poi nel campo Modello il valore postgis si preme OK. Ripetere la stessa operazione per il secondo database (nell esempio della figura sarebbe il database d utilizzare per la normalizzazione). Dopo queste due operazioni i due database appariranno nell elenco dei database esistenti nell elenco di sinistra di PgAdmin. Attenzione Dato che i database utilizzati per il caricamento e la normalizzazione vengono cancellati e riscritti non si devono utilizzare per queste funzioni dei database dei quali si vuole conservare il contenuto. pagina 37 di 42

38 1.5 Aggiornamento delle versioni e specifiche Esistono due modalità distinte per allineare il software ad una nuova versione disponibile dello strumento: Validator completo Per utilizzare una nuova versione X.Y del Validator ci sono due possibilità che dipendono dalla versione della specifica importata nel Validator in uso: - se la specifica caricata nel vecchio Validator era stata generata da un Catalogue versione X.* è sufficiente importare la specifica presente nel vecchio Validator nel nuovo Validator; - se la specifica era stata generata da un Catalogue versione (X-1).* allora è necessario rigenerare le specifiche con un Catalogue di versione X.*, esportarle dal Catalogue e importarle nel nuovo Validator. Validator chiuso Come è spiegato nella guida la generazione di un Validator chiuso è un operazione eseguita dal soggetto di diritto pubblico che ha la responsabilità di cedere il Validator ad un soggetto di diritto privato e avviene utilizzando il Validator completo. Il soggetto privato che sta utilizzando il Validator chiuso e che vuole utilizzare una nuova versione X.Y del Validator chiuso dovrà comportarsi in uno dei due seguenti modi che dipendono dalla versione della specifica importata nel Validator in uso: - se la specifica caricata nel vecchio Validator chiuso era stata generata da un Catalogue versione X.* allora l aggiornamento potrà essere effettuato direttamente dal soggetto che sta usando il Validator chiuso, effettuando il download dal sito spatialdbgroup.polimi.it dell aggiornamento del validator chiuso e seguendo le istruzioni presenti nel download; - se la specifica era stata generata da un Catalogue versione (X-1).* allora è necessario che il soggetto che ha generato il precedente Validator chiuso riproduca un nuovo Validator chiuso sulla specifica prodotta da un Catalogue di versione X.*. pagina 38 di 42

39 Appendice 2. Configurazione e utilizzo di Ireport Ireport è un prodotto open source per la generazione di documenti contenenti dati estratti da database disponibile per il download e l installazione al sito Questa appendice e i template generati per la produzione dei report fanno riferimento alla versione di Ireport. 2.1 Inclusione delle librerie per accedere alla tecnologia Apache Derby Avviare il programma e selezionare dal menù strumenti la voce Opzioni come mostrato nella figura a destra. Nella scheda che appare successivamente e mostrata sotto si deve selezionare Classpath e poi selezionare il bottone Add Jar, facendo apparire la scheda Aggiungi Jar(s) / path al classpath che appare in basso nella figura seguente. Usando la funzione cerca in posizionarsi nella cartella dove si sono copiati i file del GeoUML validator e poi nella sottocartella lib dove si selezionano i file derby.jar e derbylocale_it.jar Infine premere il bottone Apri. Tornati nella precedente scheda premere il bottone OK. 2.2 Connessione al database dei report preconfezionati I report preconfezionati sono due (uno analitico e uno sintetico) sono inclusi nei file di distribuzione del GeoUMLvalidator, ma devono essere inizializzati con l indicazione di dove si trovi il database Derby creato quando si è attivata la funzione genera database di reportistica del Validator. Posizionarsi nella cartella dove si sono copiati i file del GeoUML validator e poi nella sottocartella report. Aprire con un qualsiasi editor di testo (Blocco Note) il file DataSourceValidatorReport.xml (vedi figura seguente). pagina 39 di 42

40 La riga evidenziata in figura appare preconfigurata al solo fine di esemplificare la sintassi della riga; essa infatti deve essere sostituita con il pathname completo della cartella nella quale sono memorizzati i file del database Derby con i dati da estrarre. Ad esempio, se la cartella di destinazione dei report indicata alla funzione genera database della reportistica fosse stata D:\cartellareport allora la riga evidenziata sarebbe sostituita dalla riga <connectionparameter name= Url > <![CDATA[jdbc:derby:D:\cartellareport\reportdb]]> </connectionparameter>. Dopo la sostituzione salvare e chiudere il file. A questo punto ritornare alla scheda iniziale di Ireport, mostrata sotto, e selezionare l icona evidenziata per la connessione al database. Nella scheda Connections/Datasources che appare selezionare il bottone Import e nella successiva scheda riportata in figura sotto selezionare tramite la funzione Cerca in il file appena salvato al passo precedente. La selezione del bottone Apri comporta l aggiunta nell elenco delle connessioni precedenti di una nuova connessione indirizzata al database Derby; se l apertura fallisce significa che è stato commesso un errore nella modifica del pathname nel file precedente. pagina 40 di 42

41 A questo punto è conveniente verificare la correttezza della connessione esplicitata, selezionando la connessione appena creata e premendo il bottone Modify. Nella successiva scheda, mostrata nella figura a fianco, premere il bottone prova per testare la connessione; se l operazione fallisce verificare la correttezza del pathname inserito con l editor di testo. Se tutto è andato a buon fine ora è possibile creare i documenti. Dalla scheda corrente uscire premendo il bottone Annulla e contestualmente uscire dalla scheda Connections /Datasources premendo il bottone Close. 2.3 Generare dei documenti La generazione dei documenti richiede l apertura e compilazione del template del report e il caricamento dei dati nel template per produrre il documento. Nel menù principale di Ireport selezionare il menù File alla voce Apri report e nella successiva scheda con la funzione Cerca in posizionarsi nella cartella dove si sono copiati i file del Validator e poi nella sottocartella report nella quale ci si posiziona nell ulteriore sottocartella sintetici o analitici in base al tipo di report (in figura si è scelto il report Compile report sintetico). Nella cartella selezionare il file reportmastersintetico.jrxml (oppure il file reportmasteranalitico.jrxml nel caso dell analitico). Dopo la selezione appare nella finestra centrale di Ireport (vedi figura a lato) lo schema del report che sarà generato. Selezionare l icona compile report che predispone il report per il caricamento dei dati. La compilazione genera una diagnostica visibile nella scheda Report Problems windows che appare sotto quella mostrata in figura. Se la generazione è avvenuta con successo si può generare il documento con i dati, eseguendo le due seguenti operazioni: si seleziona nel box della sorgente dati quella per la quale si era creata la connessione in precedenza e poi si preme il bottone Anteprima come indicato in figura. Ireport visualizza il documento in un altra scheda, mostrata nella figura seguente, dove è possibile visionare le pagine del documento creato. Cambiare figura seguente pagina 41 di 42

42 Da questa scheda è possibile stampare il documento creato oppure esportarlo in diversi formati, quali ad esempio.rtf, PDF e.odt. Le due funzionalità sono attivate selezionando le icone poste sopra il report visualizzato: icona dischetto per l esportazione e l icona stampante per la stampa. Il documento riporta un intestazione nella quale si descrivono la specifica di contenuto di riferimento, la DPS utilizzata per la validazione del dataset e i relativi parametri. Entrambi i report estraggono i dati delle singole tabelle della reportistica descritte nella Sezione 5 di questa guida. pagina 42 di 42