pagina 1 di 48

Guida all’uso del GeoUML Validator (versione software 2.2)

20 dicembre 2013

pagina 2 di 48

Autori Politecnico di Milano –

Spatial DB Group Giuseppe Pelagatti (coordinatore), Alberto Belussi, Jody Marca, Mauro Negri

Coordinamento delle attività

CISIS – CPSG Comitato di Progetto

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)

CISIS –CPSG Struttura di supporto interna

Massimo Attias, (coordinatore struttura), Leonardo Donnaloia, Claudio Mazzi, Pierpaolo Milan, Antonio Rotundo (CISIS)

pagina 3 di 48

INDICE 1. INTRODUZIONE 2. L’INTERFACCIA DEL VALIDATOR E CARICAMENTO SI UNA SP ECIFICA

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

5.5.1 Tabelle generate in fase di caricamento 5.5.2 Tabelle generate in fase di normalizzazione 5.5.3 Tabelle generate in fase di validazione

5.6 Descrizione dettagliata delle singole tabelle del database di reportistica. 5.6.1 Tabelle per il controllo strutturale generate dai caricatori dei MI del validatore 5.6.2 Tabelle per la verifica dei valori degli attributi generate dai caricatori dei MI del validatore 5.6.3 Tabelle generate nel processo di normalizzazione 5.6.4Tabelle generate dai controlli sul DBN

6. FUNZIONI DI SUPPORTO ALLA VALIDAZIONE

6.1 Generazione degli strati 6.2 Estrazione dei buchi dagli strati poligonali 6.3 Esportazione dati nel modello implementativo Shape-Flat

APPENDICE 1. INSTALLAZIONE, ESECUZIONE E AGGIORNAME NTO 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 4 di 48

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). La versione 2.2 di questa guida fa riferimento alla versione 2.2 del GeoUMLvalidator. La versione 2.2 ha introdotto le seguenti novità:

• La funzione di supporto che permette di derivare gli strati per i quali siano definiti vincoli di composizione.

• La funzione che permette di identificare i buchi presenti in uno strato poligonale (ad es., copertura del suolo).

• La funzione che permette di esportare i dati caricati nel validatore nel modello implementativo Shape-Flat, indipendentemente dal formato dei dati in ingresso.

• Modifica della gestione del parallelismo dell’esecuzione del validatore. • Adattamento alla versione 2.1 di PostGIS e allaa versione 5.1.0 di Ireport

(Appendice 2); il validator permette comunque l’uso delle versioni 1.5 e 2.0 di PostGIS, mentre non garantisce la compatibilità con precedenti versioni di Ireport.

La precedente versione 2.1 di questa guida (GeoUMLvalidator versione 2.1) aveva introdotto le seguenti novità rispetto alla versione 2.0:

• Adattamento alla versione 2.0 di PostGIS con compatibilità anche verso la versione 1.5 di PostGIS. Questa compatibilità permette a chi ha già implementato il proprio DB locale in tecnologia Postgis di non allinearsi all’ultima versione disponibile per utilizzare il GeoUMLvalidator.

• Adattamento dei driver di Derby di Ireport (Appendice 2) e adattamento dei template per Ireport versione 4.7.x (Appendice 2).

• E’ stata introdotta la possibilità di generare il DB della diagnostica in un database postgis.

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 2012 - Guida alla lettura di uno schema GeoUML, 1 febraio 2012 - 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/2010

- Guida ai Modelli implementativi di tipo Flat, 1 febbraio 2012 - Guida all’uso del GeoUML Catalogue versione 2.2 (20 dicembre 2013)

pagina 5 di 48

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. La comprensione del comportamento del Validator e l’interpretazione della diagnostica richiedono una conoscenza del modello GeoUML. Le versioni del Validator Il Validator 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 completo, ad eccezione della funzione di importazione di una specifica. 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 da validare verso il DBN;

2. il DB normalizzato, detto DBN, sul quale viene eseguita la maggior parte dei controlli di corrispondenza dei dati alla specifica.

I database di appoggio devono essere creati in un DBMS PostgreSQL/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

SC.scs

GeoUML validator

Data Product da validare

Informazioni diagnostiche

GeoUML catalogue

pagina 6 di 48

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 7 di 48

ATTENZIONE: il validator utilizza un approccio ottimistico in base al quale esegui i controlli di un fase anche se ci sono stati errori nella fase precedente; ciò comporta che la presenza di molti errori in una fase determini un incremento significativo degli errori nelle fasi successive. Valutare quindi con attenzione l’opportunità di proseguire nei controlli in presenza di troppi errori nella fase eseguita. 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. La Sezione 6 descrive le funzioni di supporto disponibili dalla versione 2.2. Appendice 1 illustra come installare, eseguire 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 8 di 48

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.

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.

Nome della specifica

Elenco strati e temi della specifica

Elenco classi

Elenco dei vincoli spaziali

Elenco degli Strati topologici

Menù a tendine

Figure specifica

Elenco delle Data Product specifications

pagina 9 di 48

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. Attenzione: se la specifica non ha il mapping per la DPS interessata il validator non può funzionare.

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 Questa opportunità serve per garantire l’utilizzo della stessa specifica in presenza di diversi soggetti che utilizzano gli strumenti e in presenza di una specifica che cambia.

pagina 10 di 48

L’attivazione di questa funzione impedisce successive importazioni di specifiche nel validator (ad es., per garantire che un produttore di dati utilizzi sempre la stessa specifica). Per congelare una specifica nel validator è necessario che l’estensore della specifica esporti dal Catalogue Editor la specifica nello stato “released”, la importi nel Validator, poi attivi la 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. Ulteriori dettagli sulla distribuzione del validator chiuso sono riportati in Appendice 1.

pagina 11 di 48

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 12 di 48

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 13 di 48

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). Questa operazione richiede che siano già stati creati i database di supporto e quello sorgente del dataset (solo nei MI SQL) come descritto in Appendice 1.

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 il DB di caricamento, di normalizzazione (sorgente nei MI SQL); è possibile definire più connessioni per il DB di caricamento (normalizzazione) qualora si debbano effettuare validazioni con DPS diverse. In figura si mostra la compilazione della scheda per il database PostGIS 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 si indica localhost, tipicamente IP 127.0.0.1 perché i database di appoggio sono nel nostro esempio sullo stesso calcolatore del Validator, altrimenti sarebbe necessario l’IP reale), il nome assegnato (vedi

pagina 14 di 48

Appendice 1), l’utente e la password dell’amministratore di Postgres. Non è possibile scegliere uno schema e la configurazione adotterà lo schema public. 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 generare i soli DB di supporto per il caricamento e la normalizzazione. 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 15 di 48

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. Il salvataggio della configurazione crea il mapping della specifica verso i due DB di supporto, mentre le tabelle dei database saranno caricate all’atto della validazione. 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.

pagina 16 di 48

Pertanto se si vogliono validare in parallelo più dataset di DPS differenti è conveniente utilizzare database di Appoggio non condivisi tra le DPS.

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:

pagina 17 di 48

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.

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 18 di 48

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 un database Derby oppure 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, il tipo di database (open-source Apache DerbyEmbedded, Postgis), come memorizzare la geometria (in un “binary object (blob)” - WKB per entrambi, PGgeometry per Postgis) oltre all’indicazione opzionale dello schema. Nel caso di Derby si richiede inoltre la cartella (bottone “Sfoglia”) dove memorizzare il database della diagnostica, mentre nel caso di Postgis si devono indicare i parametri di connessione. Infine premere il bottone Genera. Si ricorda che il DB PostGIS deve essere stato precedentemente creato come quelli di supporto. Si noti che questa funzione permette di generare la diagnostica per tutte le DPS per le quali è stata eseguita una validazione dei dati. La seguente figura illustra i 4 modi in cui può essere analizzato il contenuto del database di Reportistica: 1. Database client. Uso di un generico Database Client, cioè di uno strumento in grado

di interrogare un DB (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).

2. GIS client. Uso di un Client per dati territoriali in grado di accedere ai dati di un database; per l’open-source GIS Openjump è messo a disposizione sul sito

Validator

Genera database

reportistica

Database Reportistica (Apache Derby

PostGIS)

Database Client (es. Squirrel)

Report Generator

IReport

Openjump

(+ Plugin per Derby)

(+ Template per Derby)

pagina 19 di 48

www.spatialdbgroup.polimi.it un plugin per accedere ai dati se memorizzati in DERBY. In questo modo è possibile esplorare i dati geometrici.

3. Report generator. 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. Ireport. Si tratta di un modello di report preconfigurato disponibile solo se la diagnostica è memorizzata in Derby che utilizza il prodotto open-source IReport. I template sono resi disponibili dal Validator per un primo accesso alla diagnostica ad esclusione delle geometrie ed è 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 considerati 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 20 di 48

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 Sintetiche del DB di reportistica 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 21 di 48

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 22 di 48

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

Tabella GEOMETRYERROR

pagina 23 di 48

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.

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

Tabella STRUCTURALCONSTRAINTVIOLATIONNORM

pagina 24 di 48

riporta gli errori incontrati nella riaggregazione degli attributi geometrici delle classi

5.5.3 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 5.6.1 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 25 di 48

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);

5.6.2 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, >

pagina 26 di 48

Questa tabella 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. 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 verifica 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

pagina 27 di 48

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

Tutti i tipi 2D Esistenza dei valori per X e Y e non Z in tutti i punti (vertici, estremi) della geometria

coordinata 2D errata F

Tutti i tipi 3D e le superfici B3D

Esistenza dei valori per X e Y e Z in tutti i punti (vertici, estremi) della geometria

coordinata 3D errata F

Tutti i tipi ad eccezione dei punti, multipunto e dei punti negli aggregati

Rimozione di vertici adiacenti nella dimensione del tipo (2D/3D) duplicati in ogni curva/frontiera

Vertici 2D/3D adiacenti duplicati

W

Tutti i tipi di tipo curva e le curve degli aggregati

Esistenza di almeno 2 vertici in ogni curva componente

Meno di due vertici F

GU_CPSurface2D, GU_CXSurface2D, GU_CPSurfaceB3D, GU_CXSurfaceB3D Superfici di un GU_Aggregate2D e GU_Aggregate3D

Esistenza di almeno 4 vertici in ogni frontiera - anche sulle frontiere proiettate delle superfici B3D non considerando vertici duplicati

Meno di 4 vertici F

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)

Assenza di selfoverlapping in ogni curva componente

curva2D/3D sovrapposta, E

GU_CXCurve2D, GU_CXCurve3D, GU_CXRing2D, GU_CXRing3D, GU_CNCurve2D, GU_CNCurve3D (frontiere delle superfici già garantite da altro controllo)

Assenza di overlap tra due curve componenti

curva complessa 2D/3D sovrapposta

E

GU_CPSimpleCurve2D/3D,GU_CPRing2D/3D, GU_CXRing2D/3D, GU_CPSurface2D, GU_CXSurface2D, GU_CPSurfaceB3D, GU_CXSurfaceB3D Superfici di GU_Aggregate2D/3D

Ogni curva/frontiera componente sia semplice

curva2D (anello2D) non semplice, curva3D (anello3D) non semplice, frontiera esterna 2D (interna 2D) non semplice, frontiera 3D non semplice

E

GU_CPRing2D/3D, GU_CXRing2D/3D, GU_CPSurface2D, GU_CXSurface2D, GU_CPSurfaceB3D, GU_CXSurfaceB3D, Superfici di GU_Aggregate2D/3D

Ogni curva/frontiera componente sia chiusa curva2D (3D) non chiusa, Frontiera 2D (3D) non chiusa, oppure quando anello 2D/3D non chiuso

E

GU_CNCurve2D/3D Connessione della curva complessa curva complessa 2D (3D) non connessa

GU_CPSurface2D GU_CXSurface2D GU_CPSurfaceB3D GU_CXSurfaceB3D Superfici di un GU_Aggregate2D e di un GU_Aggregate3D

Esistenza della frontiera esterna in ogni superficie componente

frontiera esterna 2D (3D) mancante

F

Assenza di buchi esterni alla propria superficie componente

superficie 2D con buco esterno

E

Assenza di buchi che toccano la frontiera esterna della propria superficie componente in più di un punto

intersezione 2D errata frontiera esterna e interna

E

Assenza di buchi che contengono altri buchi della stessa superficie

buco 2D innestato E

Assenza di buchi che toccano un altro buco della stessa superficie in più di un punto

intersezione 2D errata tra buchi

E

Ogni superficie componente sia PathConnected

superficie 2D non path-connessa

E

Le superfici componenti possono toccarsi al più in punti

Intersezione 2D errata tra superfici

E

pagina 28 di 48

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). 5.6.3 Tabelle generate nel processo di normalizzazione

pagina 29 di 48

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

pagina 30 di 48

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

pagina 31 di 48

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;

- 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

pagina 32 di 48

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

pagina 33 di 48

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

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,

pagina 34 di 48

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

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.

pagina 35 di 48

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 36 di 48

6. FUNZIONI DI SUPPORTO ALLA VALIDAZIONE

6.1 Generazione degli strati

Questa funzione permette la derivazione della geometria di uno strato topologico poligonale o lineare, utilizzando un vincolo compostoDa o Partizionato che vincola lo strato da derivare e generando l’unione delle geometrie delle classi o strati vincolanti presenti nel vincolo.

Precondizione:

• lo strato deve essere vincolato da almeno un vincolo di composizione (partizione); la funzione utilizzerà uno di quelli disponibili.

• la funzione può essere eseguita solo dopo aver effettuato le operazioni di caricamento e normalizzazione del GeoUML validator.

Per attivare la funzione si deve selezionare nel menù genera la voce Derivazione strati, la quale mostra la seguente scheda che richiede di inserire il nome della DPS usata nella validazione e necessaria per risalire al dataset da selezionare, la cartella nella quale memorizzare gli shape generati e infine mostra gli strati topologici poligonali disponibili nella specifica, richiedendo di selezionare i checkbox degli strati da derivare.

Nel caso in cui gli strati da derivare siano tra di loro interconnessi (ad esempio, lo strato csuolo è composto dalle geometrie degli altri 6 strati della figura e tutti gli strati sono da derivare) la funzione sequenzializza le derivazioni in modo opportuno (ad esempio, esegue prima la derivazione dei 6 strati componenti e infine deriva

lo strato csuolo).

Si noti che:

• se per uno strato che esiste nel dataset validato se ne chiede comunque la derivazione, il validator procede alla produzione dello shape derivato senza sovrascrivere lo strato originale;

• se le classi/strati vincolanti utilizzati per derivare uno strato non hanno record allora la derivazione produce uno strato derivato vuoto e quindi viene generato uno shape vuoto e nel file di log dell’esecuzione della derivazione si segnala l’anomalia incontrata.

6.2 Estrazione dei buchi dagli strati poligonali

Questa funzione identifica i buchi presenti nella geometria di uno strato topologico poligonale, li estrae in shapefile e li documenta in un file excel e può essere usata per

…

pagina 37 di 48

identificare errori in strati che dovrebbero coprire integralmente un territorio come, ad esempio, nel caso dell’uso del suolo.

Precondizione: la funzione può essere eseguita solo dopo aver effettuato le operazioni di caricamento e normalizzazione del GeoUML validator.

Per attivare la funzione si deve selezionare nel menù genera la voce Estrazione buchi strati, la quale mostra la seguente scheda che richiede di inserire il nome della DPS usata nella validazione e necessaria per risalire al dataset da selezionare, la cartella nella quale memorizzare il file excel descrittivo e gli shape generati, il formato excel previsto (xls, xlsx) e infine mostra gli strati topologici poligonali disponibili nella specifica concettuale, richiedendo di selezionare i checkbox degli strati a cui si applica l’estrazione. Si noti che il formato excel determina il massimo numero intero rappresentabile in excel (65535 per excel ≤ 2003 e 1048576 per excel ≥ 2007).

Per ogni strato selezionato con buchi la funzione genera uno shape file poligonale nel quale inserisce la geometria dei poligoni dei buchi trovati e riporta tutti gli attributi descrittivi presenti nei fogli di dettaglio dei singoli strati ad eccezione delle coordinate del punto di riferimento.

Inoltre la funzione produce un file excel chiamato Riepilogo_estrazione composto da:

• un foglio riassuntivo nel quale si riporta il numero di buchi individuati in ogni strato analizzato; nel caso in cui il numero di buchi non sia rappresentabile nel formato excel selezionato, per convenzione, viene scritto il valore massimo rappresentabile e la riga è mostrata in rosso. Se non sono individuati buchi nello strato la riga è visualizzata in verde e se lo strato non contiene alcun record o la geometria dello strato è NULL la riga corrispondente è mostrata in giallo; attenzione: questo caso si applica anche se lo strato per errore contiene più record – rilevabili nel quadro di consegna – e la geometria di tutti i record è NULL.

• Un foglio per ogni strato selezionato con almeno un buco contenente per ogni poligono che descrive il buco: l’identificatore dello strato (TOPOID), un identificatore assegnato ai poligoni elementari di uno strato (IDPOLY) allo scopo di facilitare l’associazione del buco alla geometria dello strato, l’identificatore del poligono del buco che serve per identificare la geometria del poligono nello shape correlato (IDHOLE), l’area, il perimetro, numero di vertici del poligono (NUMPUNTI) e le coordinate X e Y di un punto interno al poligono del buco.

Si noti che la funzione richiede la DPS utilizzata in una validazione e in generale essa corrisponderà a quella dell’ultima validazione eseguita (caso consigliato). E’ tuttavia possibile scegliere una DPS utilizzata per una validazione avvenuta in precedenza purché il database interno utilizzato per la validazione conservi ancora i dati di tale validazione.

…

pagina 38 di 48

6.3 Estrazione dati nel modello implementativo Shape-Flat

L’esportatore Shape flat permette l'esportazione negli shapefile previsti dal MI Shape_Flat di un dataset caricato nel GeoUMLvalidator. Precondizioni:

• la funzione può essere eseguita solo dopo aver effettuato le operazioni di caricamento e normalizzazione del GeoUML validator;

• deve essere definita nel GeoUMLcatalogue una DPS per il MI Shape_Flat da utilizzare nell’esportazione.

Definizione della DPS di estrazione Si può utilizzare una DPS esistente oppure definirne una dedicata all’esportazione. Nella scelta dei valori dei parametri della DPS si devono tenere presenti i seguenti aspetti:

Checkbox di gestione valori nulli. I valori nulli o le interpretazioni dei valori nulli utilizzati per descrivere l’assenza dei valori in attributi opzionali in un dataset sorgente sono trasformati sempre in un unico valore nel dataset estratto in base alla seguente regola: • se la DPS di estrazione prevede la gestione di default dei null oppure prevede

l’interpretazione dei NULL, ma con una sola interpretazione definita, allora il validatore utilizzerà la tabella corrispondente della DPS per generare il valore sostitutivo del nullo nel dataset estratto;

• se invece la DPS di estrazione prevede l’interpretazione dei null, definendo più di un valore (vedi i 3 del NC) allora il validatore chiederà quale delle N interpretazione scegliere e adotterà la relativa tabella di transcodifica della DPS nel dataset estratto;

Osservazioni: a) una DPS per Shape_Flat definita solo per supportare l’estrazione conterrà solo la

gestione di default dei nulli o solo una interpretazione dei null. b) Se una specifica prevede una DPS shape_flat per la consegna con più valori di

interpretazione, le precedenti regole permettono di non ridefinire un’ulteriore DPS shape_flat con un solo valore interpretativo (o di default) per l’estrazione. Infatti può essere usata (se gli altri parametri concordano) la DPS della consegna anche per l’estrazione, infatti il GeoUMLvalidator poi chiederà di scegliere il valore da adottare nell’estrazione, risolvendo l’ambiguità. Si noti che un ulteriore vantaggio è costituito dal fatto che nell’estrazione sarà utilizzata una delle tabelle di transcodifica previste per la consegna, evitando errori nella sua ridefinizione nella DPS di estrazione. Ovviamente nulla vieta di definire due DPS, ad esempio perché si vuole esplicitamente utilizzare una diversa tabella di transcodifica in estrazione.

Implementazione tratti, segmenti, sottoaree. L’estrazione non impone di adottare la stessa implementazione (connessa, non connessa) del dataset sorgente nel dataset da estrarre. L’operazione non comporta problemi nel caso in cui l’implementazione

pagina 39 di 48

sia connessa nel dataset sorgente, infatti se l’implementazione in estrazione è non connessa il GeoUMLvalidator convertirà punti, linee e poligoni in aggregati tipizzati di punti, linee e poligoni senza segnalare alcun messaggio, mantenendo la persistenza degli identificativi degli eventi, tratti e sottoaree di input. Viceversa se l’implementazione del dataset sorgente è non connessa e invece quella del dataset estratto è connessa il GeoUMLvalidator deve trasformare il dato nel seguente modo: Si ipotizzi di trovare un tratto (segmentid=”11a”) composto da un aggregato di due curve sconnesse. Tale tratto sarà diviso in due tratti (due record nello shapefile corrispondente), dove in ognuno avremo una delle singole curve dell’aggregato, la copia degli altri attributi descrittivi e del ClassREF del tratto originale nei due nuovi tratti e infine la generazione di un nuovo identificatore dei nuovi tratti : vecchioSegmentid_1 e vecchioSegmentid_2 (se il nuovo identificatore supera i 70 caratteri, si saranno applicate le regole sul troncamento dei nomi definite per il GeoUMLcatalogue. Implementazione B3D. Non è possibile scegliere l’implementazione 3D nell’estrattore se non è prevista anche nella DPS del dataset sorgente; il GeoUMLvalidator rifiuterà tale DPS in configurazione dell’estrazione. Nel caso in cui invece l’implementazione nell’estrattore sia 2D il GeoUML provvederà all’estrazione e nel caso in cui il dataset sorgente abbia un’implementazione 3D provvederà ad eliminare dalle coordinate di ogni tratto,… la coordinata Z. Sistema di riferimento. Il sistema di riferimento è un’informazione che si inserisce in una DPS, ma che non ha alcun impatto sul comportamento del GeoUMLvalidator. Pertanto lo strumento segnala l’eventuale differenza in configurazione, ma nel caso in cui si proceda con l’estrazione il GeoUMLvalidator procederà ignorando tale informazione e senza effettuare quindi alcuna conversione.

Configurazione di un’estrazione L’estrazione richiede come prima operazione di completare i relativi campi nella scheda di configurazione del validatore selezionando nel menù Configurazione la voce Configurazione del validatore. Come mostrato in figura, nel campo DPS esportazione si seleziona una DPS con MI Shape_Flat e nel campo Directory di esportazione si specifica la cartella nella quale memorizzare il risultato dell’estrazione come mostrato in figura; si noti che la Directory di esportazione viene visualizzata solo se viene selezionata una DPS Shape_Flat richiesta impedisce di compilare il campo directory di esportazione. In tal caso il validatore disabilita la stessa funzione di esportazione.

Nel caso in cui siano previsti diversi valori di interpretazione del null value, la scheda di configurazione mostrerà i seguenti campi come mostrato in figura:

• La scelta di uno dei valori di interpretazione, tra quelli disponibili nella DPS di estrazione, nel campo Valore nullo di default;

…

…

pagina 40 di 48

• il campo successivo ricorda che la scelta implica la perdita della molteplicità delle interpretazioni del valore nullo presenti nel dataset sorgente.

Inoltre la configurazione del validatore segnala le seguenti informazioni derivate dal confronto tra la DPS dei dati validati e quella d’esportazione: 1. Implementazione tratti,…. Nel caso in cui l'implementazione è definita non connessa

nel dataset sorgente e connessa in quella di estrazione il GeoUMLvalidator segnala la potenziale modifica degli identificatori dei tratti, sottoaree,… .

2. Implementazione B3D. Se l’implementazione è 3D nella DPS del dataset sorgente ed è 2D in quella dell’estrazione il cambiamento dei dati con la trasformazione planare dei dati sorgenti è segnalata col seguente messaggio:

L’implementazione 3D in estrazione non è invece possibile se nel dataset sorgente l’implementazione è 2D e in tal caso il configuratore non mostra tale DPS tra quelle disponibili per l’estrazione.

3. Sistema di riferimento. Se la DPS del dataset sorgente e quella dell’estrazione non hanno lo stesso sistema di riferimento viene mostrato il seguente messaggio:

Esecuzione dell’esportazione Selezionando nel menù Configurazione la voce Esecuzione appare la seguente scheda nella quale si deve selezionare il bottone Esportazione:

Al termine del processo nella cartella di estrazione saranno presenti un insieme di shapefile (dbf) popolati e una sottocartella chiamata "Empty" nella quale saranno memorizzati gli shapefile (dbf) senza alcun record.

….

pagina 41 di 48

Appendice 1. Installazione, esecuzione e aggiornamento del GeoUMLvalidator completo e chiuso 1.1 Requisiti

• Installazione di una Java virtual machine (Java Runtime Environment) versione1.5 o superiore. Se si possiede un sistema operativo a 64 bit si consiglia di installare Java Runtime Environment x64.

• Sistemi operativi Windows, Unix-like (linux, MacOS10 o superiori, Sun Solaris) • 50MB liberi ad installazione effettuata per i file temporanei. • Installazione dei sistemi Postgres (dalla versione 8.4 – www.postgresql.org) e

PostGIS (dalla versione 1.5 – postgis.refractions.net). • Creazione dei database PostGIS di supporto alla validazione. • Per la validazione di dataset Oracle è necessario aggiungere al Validator la

libreria proprietaria Oracle JDBC (ojdbc14.jar ) scaricabile da: http://www.oracle.com/technetwork/database/enterprise-edition/jdbc-10201-088211.html Dopo averla scaricata deve essere inserirla nella cartella lib del Validator

1.2 Installazione del GeoUML Validator 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 tools license.txt); questa licenza si applica anche al GeoUML Validator “chiuso” generato dal GeoUML Validator completo e la cartella “Report” con i template 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 42 di 48

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 Suggerimenti E' possibile ottimizzare l'esecuzione del validatore sfruttando le potenzialità del proprio computer configurando alcune opzioni della JVM (Java Virtual Machine)

- Si consiglia di configurare il parametro Xmx e, se disponibile, l'opzione server. Il parametro Xmx fa riferimento alla massima memoria utilizzabile dal processo del GeoUML validator, tale parametro non deve mai essere superiore alla memoria fisica (poiché l'esecuzione del processo non sarebbe neanche avviata) e si consiglia di non assegnare mai più del 50% della memoria fisica. Alcune versioni di Java Virtual Machine hanno delle limitazioni sulla quantità massima di memoria assegnabile quindi qualora il processo non si dovesse avviare diminuire la memoria e riprovare l'esecuzione.

- Il secondo parametro che si consiglia di attivare è -server che dovrebbe migliorare le performance infatti l'avvio dell'applicazione dovrebbe essere più semplice mentre l'esecuzione dovrebbe risultare più veloce. Prima di attivare tale parametro è necessario assicurarsi che la propria Java Virtual Machine supporti la modalità server.

1.5 Creazione dei database di appoggio Dopo aver installato Postgres e PostGIS è necessario creare i database di supporto in Postgres; si ricorda che i database di supporto 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 (versione 2012) e supponendo di creare due database sullo stesso calcolatore sul quale si è installato il Validator (per versioni diverse di PgAdmin l’importante è non dimenticare di creare un database con l’estensione postgis). 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.

pagina 43 di 48

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. 1.5 Aggiornamento delle versioni e specifiche del validator completo 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.

pagina 44 di 48

1.6 Distribuzione Validator chiuso e suo aggiornamento Come è spiegato nella guida la generazione di un Validator chiuso, a partire da un Validator aperto, è un’operazione in generale eseguita da chi è responsabile di una specifica e intende congelare il validator su una determinata specifica in modo che non sia possibile per errore caricare nel validator una specifica diversa da quella voluta. Per sostituire una vecchia versione del Validator chiuso con una nuova versione del Validator è necessario che il responsabile della chiusura del Validator effettui il download della nuova versione del Validator, carichi nel Validator la specifica usata nel vecchio Validator, effettui la chiusura del Validator e riconsegni il nuovo Validator chiuso all’utilizzatore.

pagina 45 di 48

Appendice 2. Configurazione e utilizzo di Ireport Questa appendice descrive come generare i report della diagnostica nel caso in cui si sia generato un database della reportistica con tecnologia open source Apache Derby. GeoUMLvalidator supporta la generazione di report a partire dal database della diagnostica, utilizzando Ireport. Ireport è un prodotto open source per la generazione di documenti contenenti dati estratti da database disponibile (ad es., Derby). Per il download e l’installazione si consiglia di collegarsi al sito http://sourceforge.net/projects/ireport/files/iReport ed effettuare il download della versione 5.1.0 del prodotto (non collegarsi al sito http://jasperforge.org/projects/ireport che mostra solo le versioni più recenti del prodotto); data la dinamicità di Ireport si è adottata la versione verificata prima del rilascio della corrente release, tuttavia non si esclude, ma non si garantisce, che versioni diverse di Ireport funzionino correttamente sui template messi a disposizione negli strumenti. Per coloro che hanno già utilizzato il GeoUMLvalidator 2.1. Si ricorda che la versione 2.1 degli strumenti utilizzava la versione 4.7.1 di Ireport e che utilizzava la nuova libreria di accesso Derby versione 10.9.1, la quale continua ad essere la versione utilizzata nella versione 2.2. Si ricorda inoltre che tale libreria è disponibile nel GeoUMLvalidator come descritto nella successiva sezione e va incorporata in eventuali altri software eventualmente utilizzati per accedere ai dati del DB interno agli strumenti GeoUML (ad es., Openjump per il plugin GeoUML per la diagnostica prodotta dal validator). Per Ireport tale allineamento è descritto nella sezione seguente. 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

pagina 46 di 48

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

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.

pagina 47 di 48

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

pagina 48 di 48

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 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 Anteprima che compila il report, accede ai dati e produce il documento del report. Eventuali problemi sono visibili nella scheda Report Problems windows che appare sotto quella mostrata in figura. 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. Si ricordi di verificare, qualora non carichi i dati, che la sorgente utilizzata sia corretta. Per verificare è sufficiente selezionare il box della sorgente dati (come mostrato nella figura seguente) e verificare che la connessione corrente ed evidenziata nell’elenco corrisponda a quella per la quale si era creata la connessione in precedenza; nel

caso in cui non sia selezionata quella corretta è sufficiente riselezionare quella desiderata e rieseguire l’anteprima. 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.