Guida Uso GeoUML Validator - CISIS

Guida all’uso del GeoUML Validator
(versione software 2.0)
1 febbraio 2012
pagina 1 di 42
Autori
Politecnico di Milano – Giuseppe Pelagatti (coordinatore),
Spatial DB Group
Alberto Belussi, Jody Marca, Mauro
Negri
Coordinamento CISIS – CPSG
Comitato di Progetto
delle attività
CISIS –CPSG
Struttura
di
interna
Maurizio De Gennaro (Regione del
Veneto – coordinatore tecnico),
Massimo Attias (CISIS-referente area
geografica e progetti)
Stefano Olivucci (Regione EmiliaRomagna), Raffaella Gelleti, Marco
Lunardis, Massimo Zia (Regione Friuli
Venezia Giulia), Massimiliano Basso,
Alessandra Chiarandini (INSIELRegione FVG), Simone Patella
(Regione Lazio), Gianbartolomeo
Siletto (Regione Piemonte), Mauro
Vasone (CSI Piemonte), Marco
Guiducci, Andrea Peri (Regione
Toscana),
Gianfranco
Amadio,
Domenico Bertoldi, Gianluca Riscaio,
Sandra Togni (Regione Umbria),
David Freppaz (Regione Valle
d’Aosta), Virgilio Cima, Umberto
Trivelloni (Regione del Veneto),
Leonardo Donnaloia, Claudio Mazzi,
Pierpaolo Milan (CISIS)
Massimo
Attias,
(coordinatore
supporto struttura),
Leonardo
Donnaloia,
Claudio Mazzi, Pierpaolo Milan,
Antonio Rotundo (CISIS)
pagina 2 di 42
INDICE
1. INTRODUZIONE
2. L’INTERFACCIA DEL VALIDATOR E CARICAMENTO SI UNA SPECIFICA
2.1 I menù del Validator
2.2 La gestione della specifica
3. ESPLORAZIONE DI UNA SPECIFICA
3.1 Visualizzazione contenuto della specifica
3.2 Ricerca di elementi nella specifica
4. CONFIGURAZIONE ED ESECUZIONE DEL VALIDATOR
4.1 La configurazione delle connessioni
4.2 La configurazione del validatore
4.3 La configurazione dei parametri metrici
4.4 L’esecuzione della validazione
5. ELABORAZIONE E INTERPRETAZIONE DELLA DIAGNOSTICA
5.1 Modalità di elaborazione della diagnostica
5.2 Funzionamento del Validator e organizzazione del DB di reportistica
5.3 Tabelle Analitiche e Tabelle Sintetiche
5.4 Identificazione dei singoli errori
5.5 Contenuto generale delle tabelle di reportistica in base alla fase in cui sono prodotte
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
APPENDICE 1. INSTALLAZIONE,
GEOUMLVALIDATOR
ESECUZIONE
E
AGGIORNAMENTO
1.1 Requisiti
1.2 Installazione
1.3 Esecuzione del programma
1.4 Creazione dei database di appoggio
1.5 Aggiornamento delle versioni e specifiche
APPENDICE 2. CONFIGURAZIONE E UTILIZZO DI IREPORT
2.1 Inclusione delle librerie per accedere alla tecnologia Apache Derby
2.2 Connessione al database dei report preconfezionati
2.3 Generare dei documenti
pagina 3 di 42
DEL
Premessa
GeoUMLvalidator è un programma sviluppato dal gruppo di ricerca SpatialDBgroup,
DEI, Politecnico di Milano nell’ambito di un progetto co-finanziato col Centro
Interregionale per i Sistemi Informatici, Geografici e Statistici (CISIS).
Le versioni del Validator, della documentazione e informazioni aggiuntive sono
disponibili sul sito spatialdbgroup.polimi.it.
Questa guida fa riferimento inoltre ai seguenti documenti:
- GeoUML Methodology e Tools. Organizzazione Complessiva, 1 febbraio 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 software 2.0), 1 febbraio 2012
pagina 4 di 42
1. INTRODUZIONE
Il GeoUML validator (chiamato Validator nel seguito) è uno strumento in grado di
operare il controllo di conformità intrinseca di un generico Data Product (chiamato nel
seguito dataset) relativamente ad una specifica di contenuto SC gestita dal GeoUML
catalogue. Come mostrato nella seguente figura, la Specifica Concettuale, le DPS e i
relativi mapping generati dal GeoUMLcatalogue sono esportati nel file di Specifica .scs
e sono importati dal Validator che li carica in un proprio database interno. Il Validator
poi carica un dataset da validare, strutturato secondo le regole (incluso il modello
implementativo) definito da una delle DPS e ne verifica la congruenza alla specifica,
generando come risultato una serie di informazioni diagnostiche.
GeoUML
catalogue
SC.scs
Data Product
da validare
GeoUML
validator
Informazioni
diagnostiche
La comprensione del comportamento del Validator e l’interpretazione della diagnostica
richiedono una conoscenza del modello GeoUML.
Le versioni del Validator
Il Catalogue viene distribuito in due versioni:
il Validator completo di tutte le funzioni che permette l’importazione di una
specifica di contenuto generato col Catalogue, la configurazione dei controlli da
eseguire, la validazione dei dati e la produzione della diagnostica.
- il Validator “chiuso” che possiede tutte le funzionalità di validazione del
Validator, ad eccezione della funzione di importazione. Questo Validator può
quindi applicare i controlli a data Product che siano conformi alla sola specifica
che è stata incorporata nel Validator.
Il processo di validazione
Il Validator utilizza per il proprio funzionamento da uno a due Database di Appoggio:
1. il DB di caricamento, detto DBF, che costituisce un database di transito
utilizzato nel processo di trasferimento del dataset verso il DBN
2. il DB normalizzato, detto DBN, sul quale vengono eseguiti i controlli di
corrispondenza dei dati alla specifica
I database di appoggio devono essere creati in un DBMS PostGIS installato sullo stesso
server del Validator oppure essere messi a disposizione da un server remoto.
Osservazioni:
1) per alcuni tipi di modelli implementativi non è necessaria la disponibilità di un
DBF, perché il caricamento viene effettuato direttamente sul DBN. Al momento
pagina 5 di 42
questa semplificazione riguarda solamente i modelli implementativi di tipo SQL
multigeometria.
2) per supportare la validazione di dati relativi a diverse DPS (ad esempio, per
validare sia dati in formato Shapefile, sia dati contenuti in un DB) è possibile
definire propri database di Appoggio per ogni DPS; in alternativa, gli stessi
database di Appoggio possono essere utilizzati per più DPS, ma i processi di
validazione dovranno essere eseguiti sequenzialmente (questo aspetto è
approfondito nella sezione dedicata alla configurazione).
La configurazione dei database di Appoggio e di altri parametri di validazione sono
preliminari all’esecuzione di una validazione, tuttavia non è necessario ridefinirli
quando il Validator è usato per validare più volte uno stesso dataset aggiornato.
Teoricamente il funzionamento del Validator sarebbe da dividere in 2 parti: portare i
dati nel DBN e quindi eseguire tutti i controlli sul DBN. In pratica il processo è
leggermente più complicato, perché intervengono due problematiche:
• in primo luogo, per portare i dati nel DBN è risultato opportuno prima caricarli
in un DB di caricamento (DBF), più simile al modello della Sorgente, e poi
ristrutturarli
• in secondo luogo, per eseguire sia il caricamento del DBF che la trasformazione
in DBN devono essere eseguiti alcuni controlli di validità minima dei dati
indispensabili per poterli caricare
In base a queste considerazioni il processo di validazione è diviso i 3 fasi:
1) fase di caricamento: il dataset da validare viene letto e caricato nel DBF;
durante questa fase vengono eseguiti tutti i controlli necessari per garantire la
caricabilità del dato. In particolare si controlla la conformità delle strutture della
sorgente a quelle previste dal MI scelto. Si controllano anche i singoli valori
degli attributi e della componente spaziale prima di procedere al loro
caricamento nel database di caricamento;
2) fase di normalizzazione: il contenuto del DBF viene letto, ristrutturato e caricato
in DBN; durante questa fase vengono eseguiti alcuni controlli sui valori dei
singoli oggetti ricostruiti, completando quindi il controllo dei singoli valori degli
attributi descrittivi e delle componenti spaziali.
3) fase di validazione: durante questa fase vengono eseguiti sui dati presenti in
DBN tutti i restanti controlli. In particolare è possibile effettuare la verifica delle
proprietà inerenti l’insieme degli oggetti di una classe o delle relazioni tra le
diverse classi (ad es., le proprietà strutturali quali l’univocità degli attributi e i
vincoli topologici).
Il peso relativo delle diverse fasi dipende dal Modello Implementativo del dataset; se
tale modello è molto simile a quello del DBN (ad esempio nei MI SQL monogeometria)
la fase di normalizzazione è molto leggera, mentre può essere pesante in caso contrario
(in particolare nel MI Shape Topologico).
I controlli svolti nelle fasi di caricamento e normalizzazione sono esclusivamente interni
ad ogni singolo oggetto mentre i controlli che coinvolgono molti oggetti sono tutti svolti
nella fase di validazione. La descrizione dei controlli che vengono svolti è trattata nella
sezione del documento dedicata alla interpretazione della diagnostica.
pagina 6 di 42
Struttura della guida
La Sezione 2 del documento descrive il menù del Validator e la gestione delle
specifiche nello strumento. Sezione 3 richiama le funzionalità che permettono la
visualizzazione della specifica concettuale caricata nel Validator. Sezione 4 descrive
come configurare i database PostGIS necessari alla validazione e come connetterli allo
strumento, l’eventuale connessione del database da validare nel caso dei modelli
implementativi SQL e infine le modalità di esecuzione della validazione.
La Sezione 5 descrive le modalità di elaborazione della diagnostica e il significato degli
errori attraverso la descrizione della struttura del database della reportistica DERBY.
Appendice 1 illustra come installare, esecuguire e aggiornare il GeoUMLvalidator.
Appendice 2 spiega come attivare Ireport per generare i documenti che riportano i dati
della diagnostica descrittiva in forma sintetica e analitica.
pagina 7 di 42
2. L’INTERFACCIA DEL VALIDATOR E CARICAMENTO DI UNA
SPECIFICA
2.1 I menù del Validator
Dopo l’avviamento del Validator si presenta con una finestra vuota, grigia, e la barra
laterale sinistra e il menù principale nella parte in alto.
La barra laterale sinistra visualizza una serie di TABS orientati alla visualizzazione
degli elementi principali della specifica di contenuto caricata nel Validator, con una
struttura uguale a quella del Catalogue; le altre componenti di una specifica sono invece
visualizzabili tramite il menù Visualizza. Il menù Configurazione permette di
configurare i parametri e i database necessari all’esecuzione della validazione e
permette inoltre l’esecuzione della validazione. Il menù Genera permette la generazione
del DB di reportistica dopo la validazione, mentre il menù File offre funzioni per la
gestione della specifica utilizzata.
Menù a tendine
Nome della specifica
Elenco strati e temi della
specifica
Elenco classi
Elenco dei vincoli spaziali
Elenco degli Strati topologici
Figure specifica
Elenco delle Data Product specifications
2.2
La gestione della specifica
Il Validator è distribuito senza una specifica precaricata e mette quindi a disposizione
funzioni per il caricamento di una specifica generata dal Catalogue, per la cancellazione
della specifica caricata e per trasformare il Validator originale in un Validator chiuso.
Queste funzioni sono rese disponibili dal menù File come mostrato dalla figura.
pagina 8 di 42
Importazione di una specifica.
Il caricamento di una specifica nel Validator richiede di
selezionare il menù File alla voce Importa la specifica.
La scheda di importazione, mostrata sotto, richiede poi
l’individuazione del file della specifica (di tipo .SCS o di
tipo .ZIP se compattato) e l’attivazione dell’importazione
tramite il click sul bottone Importa. Si noti che una
specifica può essere caricata in un Validator versione X.*
se e solo se è stata creata da un Catalogue versione X.*,
altrimenti viene rifiutata l’importazione; si rimanda alla guida all’uso del Catalogue per
le modalità di allineamento della versione di una specifica (sezione importazione ed
esportazione) e all’appendice 1 di questa guida.
L’importazione di una specifica non altera le configurazioni dei database definite in
precedenza, mentre vanno ridefinite le altre configurazioni.
Si ricorda che il Validator può caricare una specifica in uno qualsiasi dei propri stati:
working, pre-release, released (vedere la guida al GeoUMLcatalogue per una
descrizione dettagliata), tuttavia la funzione di chiusura del Validator richiede che la
specifica caricata sia in stato released.
Cancellazione della specifica
Selezionando il menù File alla voce Proprietà è possibile inoltre cancellare la specifica
presente nel Validator, generando una specifica
vuota; questa funzione va attivata solo qualora in
presenza di molteplici importazioni si
verifichino problemi nell’esecuzione di una
nuova importazione. Per la cancellazione è
necessario premere il bottone cancella tutto il
contenuto del databasee successivamente il
bottone Salva modifiche della stessa scheda.
La cancellazione non annulla la configurazione
dei database e dei parametri metrici.
Congelamento di una specifica
Per permettere ad un soggetto privato di utilizzare il Validator su un dataset (ad
esempio, in produzione) è necessario che l’estensore della specifica esporti dal
Catalogue Editor la specifica nello stato “released”, la importi nel Validator, poi attivi la
pagina 9 di 42
voce Congela SC del menù File. A questo punto deve terminare l’esecuzione del
Validator e rieseguire nuovamente il Validator; quest’ultima operazione trasforma il
Validator in un Validator chiuso. Il Validator chiuso può essere utilizzato su più Dataset
purchè siano tutti associati alla stessa specifica caricata nel Validator chiuso poiché è
disabilitata la funzione di importazione. Si noti che nel caso in cui sia necessario
cambiare la specifica presente in un Validator chiuso è necessario ricreare il Validator
chiuso con le modalità spiegate prima.
pagina 10 di 42
3. ESPLORAZIONE DI UNA SPECIFICA
Dopo l’importazione di una specifica il Validator permette di visualizzare il contenuto
della specifica secondo le stesse modalità del GeoUML Catalogue Viewer.
Il Validator permette di visualizzare gli elementi della specifica di contenuto caricata
anche attraverso una funzione di ricerca, ma non ne permette la stampa se non
attraverso una funzione generale di stampa della scheda corrente del Validator attivata
alla voce Print del menù File e che permette la stampa di un elemento della specifica
quando questo è visualizzato nella scheda corrente.
3.1 Visualizzazione contenuto della specifica
Per visualizzare la descrizione degli elementi concettuali della specifica di contenuto
associato si usa principalmente la barra laterale. Per accedere
ad una delle voci di primo livello presenti sulla barra laterale
è sufficiente un singolo click del mouse sulla voce
selezionata. Ad esempio, nella figura sulla destra è mostrato
il risultato di un click sulla voce “Classi”.
Da questo elenco, con un click su una classe si ottiene
l’apertura di una scheda che contiene le informazioni relative
a quella classe.
In generale, una volta aperta una qualsiasi scheda, è possibile
analizzare gli elementi informativi GeoUML presenti su tale
scheda selezionandoli con un click; in questo modo si apre
una nuova scheda relativa all’elemento selezionato. Questo
metodo permette l’esplorazione delle specifiche, ad esempio permette, data una classe,
di selezionare un attributo o una componente spaziale, e di visualizzarne tutte le
caratteristiche (ad es., attributi dipendenti dalla geometria e poi i valori di domini
enumerati, ecc...). Si noti che le associazioni sono visibili solo accedendo alle classi
coinvolte. Oltre agli elementi formali della specifica il Validator permette di visionare le
descrizioni, le immagini e i diagrammi associati agli elementi della specifica.
Ulteriori informazioni inerenti la specifica di contenuto
disponibili nel menù principale sono:
- i dati di identificazione della specifica (nome, versione,
autore, creazione, lingua, …) che si ottengono
selezionando dal menù visualizza la voce Specifica (vedi
figura a destra).
- La presenza dell’introduzione generale alla specifica di
contenuto e di eventuali allegati alla specifica stessa è
verificabile selezionando dal menù Visualizza la voce
Struttura documenti; se sono presenti appare un box relativo (box RTF
introduzione o RTF allegati) in fondo alla scheda; si noti che l’introduzione e gli
allegati non possono essere visualizzati con il Validator.
- I livelli di scala definiti per la specifica, che sono visualizzabili selezionando dal
menù Visualizza la voce Livelli di scala.
- I valori di interpretazione dei valori nulli (ad esempio, “91 – Non conosciuto …”
delle specifiche del National Core) se sono stati definiti nella specifica, visibili
selezionando dal menù Visualizza la voce Valore nullo.
pagina 11 di 42
3.2 Ricerca di elementi nella specifica
La barra laterale sinistra permette di accedere a specifici elementi che vengono
individuati negli elenchi mostrati selezionando un opportuno TAB, tuttavia il Validator
permette di accedere agli elementi della specifica anche attraverso una funzionalità di
ricerca per nome attivata dal menù Visualizza alla
voce Cerca che mostra la scheda della figura a lato.
La scheda permette di indicare il nome cercato (ad
es., EDIFC) e di specificare se il nome si riferisca al
valore di uno specifico campo di identificazione
(codice, codice alfanumerico, descrizione) o al
valore di uno qualsiasi dei tre. Inoltre si può indicare
in quale parte della specifica cercare (ad esempio, in
tutta la specifica come mostrato in figura), oppure
nei soli attributi o associazioni. La ricerca mostrerà
poi tutti gli elementi individuati (ad esempio, una
classe e sei attributi descrittivi nella figura) suddivisi
per tipologia e con un click sulla tipologia prima e
sullo specifico elemento poi sarà possibile come con
la barra laterale accedere ai dati di dettaglio dello
specifico elemento.
Si noti che selezionando “Tutto il catalogo” nel campo in si restringe la ricerca agli
elementi formali: Classi, Associazioni, DataType, DominiGerarchici, Domini, Vincoli,
Eventi, Tratti e Sottoaree.
pagina 12 di 42
4. CONFIGURAZIONE ED ESECUZIONE DEL VALIDATOR
L’esecuzione di una validazione richiede che siano state eseguite tutte le operazioni
previste in Appendice 1 inerenti la creazione dei database di appoggio utilizzati dal
Validator. Dopo la creazione dei database di appoggio e l’importazione di una specifica
si devono:
- memorizzare nel validatore i parametri necessari alla connessione al dataset da
validare (modelli implementativi SQL) e ai database di appoggio;
- agganciare ogni DPS al dataset e ai database di supporto;
- definire i parametri per l’esecuzione dei controlli metrici e di distanza minima (per il
modello implementativo Shape_Topo).
4.1 La configurazione dei database
Selezionare il menù, mostrato nella
figura a destra, Configurazione
alla voce Gestione Configurazioni
Database
che
permette
la
visualizzazione della scheda delle
connessioni effettuate mostrata
sotto (in figura non sono presenti
connessioni). Si noti che questa
operazione richiede che prima siano stati creati i database come descritto in Appendice
1 in base alla tecnologia del modello implementativo del dataset da controllare.
La creazione di una nuova connessione avviene premendo il bottone Nuova che appare
nella scheda precedente, il quale estende la precedente scheda con la scheda per la
generazione della configurazione corrente descritta nella prossima figura; questa
operazione di creazione va ripetuta per ogni database di appoggio. In figura si mostra la
compilazione della scheda per il database Postgres di caricamento in base ai dati di
esempio utilizzati in Appendice 1; vengono selezionati il tipo di database (PostGIS ad
indicare Postgres con l’inserimento delle librerie geometriche di PostGIS), l’utilizzo
(Caricamento e nella seconda configurazione sarà Normalizzazione), la porta (assegnata
dal Validator), l’URL (per convenzione IP 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 Appendice 1), l’utente e la password
dell’amministratore di Postgres e lasciando in bianco il campo schema.
pagina 13 di 42
Dopo aver compilato i campi è
conveniente premere il bottone Prova
connessione per verificare la correttezza
dei parametri e infine premere Salva per
memorizzare la connessione creata. Nel
caso in cui il dataset sia stato creato con
un modello implementativo Shape è
necessario
ripetere
l’operazione
precedente anche per il secondo database
di appoggio per la normalizzazione
selezionando nuovamente il bottone
Nuova.
Si noti che nella parte inferiore della
scheda a lato rimangono visibili i
parametri dell’ultima connessione salvata
che
possono
essere
nuovamente
modificati e salvati. Infine se il dataset da
validare è stato realizzato con un modello
implementativo SQL Flat allora è
necessario configurare la connessione
anche al database contenente i dati da
validare; in tal caso il tipo di database
potrà essere PostGIS o Oracle, l’utilizzo sarà sorgente (nel caso Oracle questa voce sarà
omessa in quanto sorgente per default) e in questo caso si dovrà specificare il nome
dello schema se i dati sono messi in un particolare schema del database selezionato.
Attenzione nel caso di dataset SQL per il modello implementativo SQL Flat
multigeometria si deve configurare solo il database di Appoggio di caricamento.
Le connessioni create sono elencate nella parte alta della scheda in righe colorate in
caricamento, giallo
normalizzazione, bianco
base al parametro di uso (rosso
sorgente); nella figura sotto appare l’elenco delle connessioni dopo la creazione della
connessione al database di Appoggio per il caricamento dei dati. Si noti che per
correggere i dati di una connessione esistente è sufficiente selezionarla nella lista con un
doppio click del mouse.
4.2 La configurazione del validatore
Selezionando la voce Configurazione del validatore del menù Configurazione si
definiscono i parametri che permettono l’associazione di una DPS al proprio dataset
sorgente e ai database di Appoggio. La prima operazione consiste nella selezione di una
delle DPS presenti nella specifica. Nel caso di DPS con modello implementativo Shape,
ad esempio, appare la seguente figura
pagina 14 di 42
E’ necessario per questo tipo di DPS indicare il pathname completo della cartella che
contiene il dataset (shape). Inoltre si devono selezionare due dei database
precedentemente creati e configurati come database di caricamento e normalizzazione e
salvare i dati.
Nel caso di DPS di modelli implementativi SQL Flat multigeometria si devono
selezionare, come indicato nella figura sotto, la DPS, il database sorgente
precedentemente configurato e il solo database di caricamento.
Nel caso del modello implementativo SQL monogeometria si richiedono invece
entrambi i database di Appoggio.
Attenzione. E’ possibile che più DPS condividano uno o entrambi i database di
Appoggio ma con i seguenti vincoli del Validator:
- DBF condiviso. Se viene caricato (anche normalizzato) il dataset della DPS1
allora all’atto del caricamento del dataset della DPS2 (che condivide il DBF)
vengono eliminati dal database interno del validatore tutti i dati che si
riferiscono al dataset della DPS 1 incluso i risultati della diagnostica.
- DBN condiviso. Il caricamento dei due dataset nel relativo DBF avviene senza
restrizioni. Se il dataset della DPS1 viene normalizzato allora all’atto della
normalizzazione del dataset della DPS2 (che condivide DBN) vengono eliminati
tutti i dati che si riferiscono al dataset della DPS1.
Questi vincoli impongono di ripetere dei controlli eventualmente già eseguiti
imponendo una sequenzializzazione delle validazioni.
Pertanto se si vogliono validare in parallelo più dataset di DPS differenti è conveniente
utilizzare database di Appoggio non condivisi tra le DPS.
pagina 15 di 42
4.3 La configurazione dei parametri metrici
La selezione del menu Configurazione alla voce Parametri dei controlli geometrici fa
apparire la seguente
scheda che è suddivisa
in due parti:
- nella prima parte
devono essere indicati
i valori metrici da
utilizzare come soglia
nei controlli metrici;
si noti che il controllo
relativo sarà eseguito
se viene selezionato il
checkbox a sinistra
del parametro;
- la seconda parte
riguarda il controllo
della distanza minima disponibile solo per il modello implementativo Shape_Topo e
richiede di definire il valore di soglia e di selezionare il checkbox relativo per
abilitare il controllo.
Dopo l’effettuazione delle scelte si deve premere il bottone Salva i parametri. La
scheda propone sempre alcuni valori di default che possono essere sempre riselezionato
attraverso il bottone Reimposta parametri di default.
4.4 L’esecuzione della validazione
Per eseguire la validazione del dataset si deve selezionare la voce Esecuzione del menù
Configurazione per far
apparire
la
scheda
mostrata a lato. La scheda
richiede di selezionare
una delle DPS configurate
con
la
voce
configurazione
validatore; se si sceglie
una DPS non configurata
apparirà la scritta “Non
configurata” accanto alla DPS selezionata e non appariranno i bottoni per l’esecuzione
dei controlli.. Nella stessa scheda è possibile indicare il numero di processi concorrenti
(livello di multithreading al quale opera il Validator); la scelta ottimale dipende dalle
caratteristiche della macchina (Hardware) utilizzata e non può essere indicata in
generale. Un criterio ragionevole può essere il seguente, a condizione di una
disponibilità adeguata di RAM: Numero di Processi Concorrenti = Numero di
Processori o di Core + 1.
Il Validator permette l’esecuzione sequenziale di tutti i controlli (bottone Caricamento
+ Normalizzazione + Validazione completa), oppure l’esecuzione parziale dei controlli
come indicato nella seguente lista:
1. i controlli della fase di caricamento dei dati dal dataset al database di appoggio
di caricamento (bottone Importazione); in questa fase sono eseguiti i controlli
sui singoli valori descrittivi e geometrici del dataset da validare.
pagina 16 di 42
2. I controlli della fase di normalizzazione sono effettuati sulla trasformazione
strutturale dei dati (eccetto Oracle multigeometria) e sulla ricostruzione delle
geometrie del modello implementativo Shape_Topo; i dati trasformati sono poi
caricati nel database di normalizzazione (bottone Normalizzazione)
3. I controlli strutturali (ad es., vincoli primary key, foreign key) (bottone Solo
struttura).
4. Il controllo dei vincoli spaziali (bottone Solo vincoli); si noti che il bottone
Completa esegue i controlli strutturali e i vincoli spaziali).
Il Validator controlla che i controlli 2, 3, 4 siano eseguiti dopo l’importazione e i
controlli 3 e 4 dopo i controlli della normalizzazione.
Tenere inoltre presente che
• la fase di caricamento popola un nuovo DBF, eliminando il contenuto di quello
preesistente;
• la fase di normalizzazione crea un nuovo DBN, eliminando quello preesistente.
Si noti che la possibilità di eseguire separatamente le diverse fasi permette di correggere
i dati di input di una fase,
ripetendola anche più
volte, prima di passare
alla successiva. Quando si
attiva l’esecuzione di uno
dei precedenti controlli
viene
mostrata
una
finestra di log nella quale
appare una sintesi delle
operazioni eseguite (nella
figura a lato è mostrata la
finestra per il controllo di
Importazione). Il log delle
operazioni può essere esaminato a video allargandone le dimensioni o essere estratto
selezionandolo e utilizzando il comando CTRL C; si tratta tuttavia di segnalazioni utili
soprattutto in caso di problemi dell’esecuzione. Inoltre se si vuole interrompere
l’esecuzione dei controlli in corso è necessario premere il bottone Ferma; si noti che
l’interruzione può richiedere anche due minuti al fine di non lasciare il validatore in uno
stato inconsistente per riprendere la validazione.
pagina 17 di 42
5. ELABORAZIONE E INTERPRETAZIONE DELLA DIAGNOSTICA
5.1 Modalità di elaborazione della diagnostica
Le operazioni di validazione producono una serie di informazioni diagnostiche che il
Validator salva nel database interno. Il Validator
permette di esportare la diagnostica in una Directory a
scelta dell’utente, selezionando la voce Database
reportistica del menu Genera.
Tale funziona visualizza una scheda che chiede di
selezionare la DPS per la quale si vuole la diagnostica e la cartella (bottone “Sfoglia”)
dove memorizzare tale diagnostica. E infine premere il bottone Genera.
Si noti che questa funzione permette di generare la diagnostica per tutte le DPS per le
quali è stata eseguita una validazione dei dati.
L’analisi dei dati della diagnostica può essere effettuata secondo diverse modalità.
Nella cartella selezionata viene creato un database con tecnologia Apache DERBY,
open source e quindi usabile liberamente contenente i dati della diagnostica che sarà
chiamato database della reportistica.
La maggior parte delle informazioni diagnostiche prodotte dal Validator sono corredate
di geometria, cioè contengono la geometria dell’oggetto errato. Dato che DERBY non è
un Database spaziale, le geometrie sono memorizzate in formato standard WKB in un
“binary object (blob)”.
La seguente figura illustra i 4 modi in cui può essere analizzato il contenuto del
database di Reportistica:
Validator
Genera
database
reportistica
Openjump
Database Client
(es. Squirrel)
Database
Reportistica
(+ Plugin per Derby)
(Apache Derby)
IReport
Report
Generator
(+ Configurazione per
GeoUMLreport)
1. Database client. Uso di un generico Database Client, cioè di uno strumento in grado
di interrogare un DB in tecnologia DERBY (esistono numerosi strumenti di questo
tipo); questo metodo è il più potente ed è consigliabile per utenti esperti nell’accesso
ai database relazionali, però non permette di analizzare direttamente le geometrie
(che possono essere analizzate sui dati del dataset sorgente, ad esempio).
pagina 18 di 42
2. GIS client. Uso di un Client per dati territoriali in grado di accedere ai dati di un
database DERBY; per il GIS Openjump è messo a disposizione sul sito
www.spatialdbgroup.polimi.it un plugin per accedere ai dati di DERBY. In questo
modo è possibile esplorare i dati geometrici.
3. Documento di report. Uso di un qualsiasi Report Generator per prodursi un
documento di report adatto alle proprie esigenze; questo metodo è indicato per chi
dovrà ripetere molte volte particolari analisi sulla diagnostica, ma richiede la prima
volta un utente capace di configurare il Report Generator.
4. GeoUMLreport. Si tratta di un modello di report preconfigurato con il report
generator IReport reso disponibile dal Validator per un primo accesso alla
diagnostica ad esclusione delle geometrie adatto all’utente non esperto negli altri
strumenti e non fornisce alcuna forma di flessibilità. In Appendice vengono fornite le
istruzioni per l’installazione di Ireport e la produzione dei due documenti di
reportistica (analitico e di sintesi). Si noti che i report fanno riferimento alle tabelle di
diagnostica di DERBY descritte nel seguito e il report sintetico riporta l’indicazione
di quanti oggetti e con quale incidenza percentuale violano un controllo, mentre
quello analitico riporta sostanzialmente il contenuto delle tabelle del database della
reportistica ad eccezione dei casi in cui il 100% degli oggetti risulta sbagliato.
5.2 Funzionamento del Validator e organizzazione del DB di reportistica
Prima di analizzare in dettaglio la struttura e il significato del database di reportistica è
opportuno prendere in considerazione come l’impostazione di tale database sia legata ai
principi di funzionamento del Validator, in particolare ai seguenti:
• Il Validator può trovare errori in ognuna delle 3 fasi descritte precedentemente:
caricamento, normalizzazione e validazione
• Dato che le fasi di caricamento e normalizzazione dipendono dal Modello
Implementativo, anche il tipo di errori riscontrabile in queste due fasi preliminari
dipende dal MI; tuttavia, la struttura delle tabelle del DB di reportistica destinate a
tener traccia di questi errori è unica per tutti i MI. Inoltre:
o Il validatore controlla solo le strutture fisiche richieste e gli attributi previsti
dallo specifico MI considerato; strutture fisiche aggiuntive o attributi
aggiuntivi nella sorgente non sono quindi considerati.
o Le strutture fisiche dedicate alla descrizione dei domini enumerati non sono
considerate dal validatore che le carica direttamente dalla specifica (file
.scs) per i controlli di dominio.
• In presenza di un errore il Validator tenta di procedere nell’analisi; per questo
motivo nelle fasi di caricamento e normalizzazione a fronte di un dato errato il
Validator se possibile carica un valore scelto opportunamente (spesso è il valore
NULLO) nel corrispondente campo del DBF o DBN, in modo da poter proseguire
nell’analisi. Naturalmente, questo approccio comporta che:
o Nelle fasi successive si possono generare molti ulteriori errori dovuti agli
errori precedenti
o In certe situazioni il Validator deve fermarsi perché non è in grado di
procedere
• La diagnostica prodotta dal Validator deve servire a rintracciare gli errori sia a
livello concettuale che a livello fisico; il Validator riscontra infatti gli errori sui dati,
quindi nel modello fisico, ma spesso l’interpretazione degli errori richiede di
rintracciare le categorie concettuali che il dato fisico deve rappresentare; pertanto,
la comprensione della diagnostica richiede di conoscere le regole del MI utilizzato.
pagina 19 di 42
AVVERTENZA: Dato che la struttura delle tabelle di reportistica è unica,
indipendentemente dal MI utilizzato, nelle spiegazioni seguenti in alcuni casi vengono
indicati diversi contenuti possibili di una tabella, dovuti ai diversi MI; per semplicità,
tali alternative sono riportate senza specificare a quali MI si riferiscono – se il lettore
conosce o è interessato a un solo MI deve riconoscere le affermazioni rilevanti per lui
trascurando quelle non rilevanti. Ad esempio, l’identificatore di un oggetto in una classe
si chiama ClassID in alcuni MI e UUID in altri; indicando come valore di un campo
“ClassID oppure UUID” si lascia all’utente di riconoscere l’elemento che gli interessa.
5.3 Tabelle Analitiche e Tabelle Sintetiche
Il Database di reportistica consiste di tabelle dedicate alla segnalazione analitica
dell’errore e di tabelle di sintesi; le Tabelle sintetiche sono in corrispondenza biunivoca
con le tabelle analitiche per le quali ha senso fornire il livello sintetico e hanno un nome
costituito dal concatenamento del nome della corrispondente tabella analitica con il
suffisso “SIN”.
Le tabelle analitiche descrivono, in generale, il dettaglio di ogni singolo errore
incontrato specificandone la gravità, l’elemento concettuale e fisico interessato e
l’identificazione dell’oggetto coinvolto e riportano, ove possibile, una geometria che
riporti l’oggetto errato o l’area dove si verifica l’errore.
Le tabelle sintetiche forniscono a livello di componenti come le classi, ad esempio,
l’indicazione del numero totale di errori e della loro incidenza percentuale; si noti che
nel caso di un errore che coinvolga tutti gli oggetti di una classe (incidenza del 100%)
l’errore viene segnalato solo nelle tabelle sintetiche.
Le tabelle analitiche servono quindi per individuare e correggere i singoli errori, mentre
le tabelle sintetiche servono per individuare le aree di maggior criticità e stabilire se si
tratti di errori metodologici e infine per valutare complessivamente la qualità del dataset
sorgente.
5.4 Identificazione dei singoli errori
La segnalazione degli errori trovati dal validatore avviene a doppio livello, sia
identificando l’oggetto fisico, il suo attributo e la struttura fisica di appartenenza, sia
associando tali elementi ai corrispondenti elementi concettuali della specifica. Inoltre,
viene generalmente fornito l’identificatore dell’istanza di oggetto che ha causato
l’errore.
I riferimenti alle strutture fisiche e concettuali degli oggetti con errore sono i seguenti:
SFPHYSTRUCTNAME: nome della struttura fisica della sorgente alla quale
appartiene l’oggetto con errore.
SFPHYATTRNAME: nome dell’attributo della struttura fisica che contiene
l’errore.
SCELEMENNAME: nome dell’elemento concettuale collegato alla struttura
fisica
SCELEMTYPE: tipo dell’elemento concettuale (in generale classe, strato,
associazione).
SCATTRNAME: nome dell’attributo dell’elemento concettuale associato
all’attributo fisico.
SCATTRTYPE: tipo dell’attributo concettuale.
Nel caso degli attributi descrittivi (mono o multivalore) normali di classe o
associazione, di componente spaziale, a tratti, eventi, sottoaree, nel caso dei ruoli e delle
componenti spaziali (MI Shape_Flat e SQL_Flat) saranno riportati i nomi dell’attributo
pagina 20 di 42
concettuale e del relativo attributo fisico prodotto dal mapping e analogamente per i
nomi delle classi, associazioni, strati e delle relative strutture fisiche. Il campo
SCATTRTYPE qualifica il tipo di attributo o ruolo; ad esempio, possibili valori sono:
attributo di classe, attributo enumerato o enumerato gerarchico di classe, di datatype,
ruolo, attributo a tratti, attributo multivalore, enumerato multivalore, datatype
multivalore, attributo geometrico, attributo geometrico collassato a linea o a punto,
geometria di strato topologico. Nel caso del MI Shape_Flat nella colonna del nome
dell’attributo fisico associato alla componente spaziale si mette per convenzione il
codice alfanumerico della componente spaziale concettuale (classi) e la costante
“geometria” (strati) per identificare la geometria dello shape file.
I modelli implementativi introducono nel mapping nuovi attributi fisici che comunque
vengono, dove possibile, associati all’elemento concettuale di riferimento.
In particolare:
- i MI Shape_Flat e MI SQL_Flat introducono attributi geometrici per descrivere la
geometria minima degli attributi a eventi, tratti e a sottoaree che vengono associati
concettualmente alla componente spaziale sulla quale sono definiti specificando in
SCATTRTYPE: Geometria eventi minimi, Geometria dei tratti minimi, Geometria
delle sottoaree minime; anche in questo caso si adottano le convenzioni precedenti
sui nomi degli attributi fisici per il MI Shape_Flat.
- Gli identificatori fisici ClassID, TopoID, EventID, SegmentID, SubRegID nei MI
SQL_Flat monogeometria, Shape_Flat e MI Shape_Topo (UUID e UUIDref nel MI
SQL ORACLE_Flat multigeometria) associati ai valori di SCATTRTYPE:
identificatore univoco della classe, identificatore dello strato topologico,
identificatore degli eventi puntiformi minimi, identificatore degli attributi a tratti
minimi, identificatore degli attributi a sottoaree minime (rispettivamente).Questi
attributi vengono convenzionalmente associati all’attributo concettuale ObjectID.
- Gli attributi fisici ClassREF (UUIDREF nel MI SQL ORACLE_Flat
multigeometria) delle tabelle degli attributi multivalore e datatype multivalore,
delle tabelle dei tratti, eventi e sottoaree minime e delle tabelle delle componenti
spaziali separate nei MI SQL_Flat monogeometria e Shape_Flat vengono associati
rispettivamente all’attributo multivalore e alla componente spaziale a cui si
riferiscono le tabelle.
Il MI Shape_Topo crea una struttura topologica nella quale un insieme di geometrie è
riunita in un unico shape, pertanto l’attributo geometrico della geometria topologica,
l’identificatore “primid” della singola geometria elementare, la coppia di attributi
<primid, geoid> della tabella di composizione per la costruzione delle geometrie degli
oggetti non hanno una relazione diretta con un particolare elemento della specifica
concettuale; per questo motivo si adotta la convenzione di riportare nelle colonne di
diagnostica del nome dell’attributo e dell’elemento concettuale il nome dell’insieme
topologico al quale si riferiscono, specificando nel tipo dell’attributo concettuale il
ruolo dell’attributo fisico nell’ambito dell’insieme topologico: “geometria insieme
geometrico”, “primid”, “geoid nel dbf di composizione”; nel tipo dell’elemento
concettuale per convenzione si specifica invece “Insieme geometrico”. Si noti che per la
geometria nella colonna del nome dell’attributo fisico si riporta per convenzione
“geometria” come nel caso del MI Shape_Flat. Infine gli attributi fisici delle
componenti spaziali delle classi (strati) o delle geometrie minime dei tratti (eventi,
sottoaree) non contengono la geometria effettiva, ma il geoid che identifica la geometria
e pertanto il campo SCATTRTYPE riporta: geoid della classe, geoid dello strato
pagina 21 di 42
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.
pagina 22 di 42
Tabella GEOMETRYERROR
riporta gli errori rilevati sulle geometrie delle componenti spaziali della sorgente,
degli attributi a tratti, eventi, sottoaree dei MI SQL e MI Shape_Flat e le
geometrie (archi e nodi) degli insiemi topologici.
Tabella GEOCOMPATIBILITYWARNING (solo per i MI SQL_Flat)
riporta le segnalazioni inerenti le geometrie che hanno un tipo diverso da quello
richiesto, ma ritenuto compatibile (ad esempio, la geometria è di tipo multipoint
e contiene un solo punto e il tipo richiesto è point). La geometria viene
convertita al tipo richiesto e poi sottoposta ai controlli descritti nella sezione
precedente e i cui errori saranno memorizzati nella tabella
GEOMETRYERROR.
Tabella METRICWARNING
non riporta errori, ma segnalazioni inerenti alcuni controlli metrici effettuati
sulle geometrie che sono state caricate nel DBF; tali segnalazioni sono da
considerare dei possibili warning rispetto a possibili geometrie errate e non
comportano l’eliminazione della geometria dal DBF.
Tabella MINIMUMDISTANCESHAPETOPO (solo per il MI Shape_TOPO)
Riporta le geometrie che non soddisfano la distanza minima.
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 Shapeflat e Shape_Topo la tabella elemenstatedbf aggiunge anche le tabelle di NULL
INTERPRETATION (_NI) assenti nella tabella elementstate caricandovi i valori
dedotti dall’analisi dei valori degli attributi. La cardinalità di una struttura fisica
coincide con quella definita in elementstate per quelle presenti nella sorgente e 0
per quelle assenti.
Tabella GEOCOMPATIBILITYWARNINGNORM
Vedere analoga tabella del caricamento.
Tabella GEOMETRYERRORNORM (solo MI Shape_Topo)
ha la stessa struttura dell’equivalente tabella del caricamento, ma fa riferimento
anche alle geometrie ricostruite durante la fase di normalizzazione in base alle
primitive topologiche
Tabella METRICWARNINGNORM (solo MI Shape_Topo)
ha la stessa struttura dell’equivalente tabella del caricamento, ma riporta le
segnalazioni metriche rilevate sulle geometrie ricostruite
pagina 23 di 42
Tabella STRUCTURALCONSTRAINTVIOLATIONNORM
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 24 di 42
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, >
Questa tabella riporta gli errori dovuti al fatto che un valore di un attributo descrittivo
dichiarato nella tabella ATTRIBUTESTRUCTURE con ERROR= compatibilità
pagina 25 di 42
possibile non sia congruente col tipo richiesto. Il valore descrittivo errato viene riportato
nel campo WRONGVALUE. Si distinguono due casi:
- valore incompatibile (ERRLEVEL=E(error) e ERROR= boolean sconosciuto)
applicato a valori di tipo boolean: il valore logico è stato codificato con un
valore non riconoscibile e quindi viene sostituito con NULL nel DBF;
- valore convertito: in questo caso il valore della sorgente viene adattato al tipo
richiesto; ad esempio, se il tipo richiesto è string(n) e la stringa della sorgente è
più lunga, la stringa viene troncata alla lunghezza n segnalando ERROR= tronco
a lunghezza n. Il valore viene quindi modificato e inserito nel DBF e pertanto
nella tabella si riporta solo una segnalazione ERRLEVEL=W(warning) e in
ERROR si riporterà l’operazione eseguita.
I campi SFPHYATTRID1NAME, SFPHYATTRID2NAME, OBJID1, OBJID2 sono
usati per l’identificazione dell’oggetto a cui appartiene l’attributo.
Tabella GEOMETRY ERROR
Struttura
<SCELEMNAME,SCELEMTYPE,SCATTRNAME,SCATTRTYPE
SFPHYSTRUCTNAME,SFPHYATTRNAME, ERRLEV, ERROR, GEOMETRY
SFPHYATTRIDNAME, OBJID>
Questa tabella riguarda gli errori rilevati sulle geometrie delle componenti spaziali della
sorgente, degli attributi a tratti, eventi, sottoaree dei MI SQL e MI Shape_Flat e le
geometrie (archi e nodi) degli insiemi topologici del MI Shape_Topo.
In particolare si effettuano due tipi di controlli:
- nei MI SQL_Flat si verifica che la geometria contenuta in un attributo
geometrico della sorgente corrisponda al tipo richiesto dal MI; nei MI Shape
questo controllo è effettuato nella verific effettuata per la tabella
AttributeStructure;
- per tutti i MI: controllo delle caratteristiche dell’ESFM del GeoUML.
Le geometrie errate sono memorizzate nel campo GEOMETRY definito di tipo “blob” e
codificato in WKB. L’oggetto interessato è identificato nei campi
SFPHYATTRIDNAME, OBJID.
Si hanno due tipi di errore:
1. geometria incompatibile (ERRLEVEL=F(fatal) e ERROR=geometria errata): la
geometria è eliminata e viene inserito NULL nel DBF;
La verifica di tipo degli attributi descrittivi e delle geometrie dei MI Shape avviene
prima e gli esiti sono memorizzati nella tabella ATTRIBUTESTRUCTURE. Il
controllo del tipo delle geometrie dei MI SQL_Flat viene effettuato durante la
valutazione della qualità della singola geometria, pertanto il tipo derivato dalla
geometria può risultare corretto (nessuna segnalazione e il valore viene caricato nel
DBF), incompatibile (Fatal error precedente) o compatibile; in questo ultimo caso si
esegue
una
conversione
del
tipo
(segnalazione
nella
tabella
GEOCOMPATIBILITYWARNING) e il valore viene caricato nel DBF.
2. violazione proprietà GeoUML: viene segnalato l’errore e nel caso in cui sia di livello
Fatal si inserisce NULL nel DBF, mentre nel caso sia di livello error la geometria è
comunque inserita nel DBF. Nella seguente tabella si elencano le tipologie di
violazione delle proprietà GeoUML, riportando i valori di ERROR e ERRLEVEL, la
descrizione del controllo eseguito sui valori dei diversi tipi geometrici; si noti che un
pagina 26 di 42
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
Esistenza dei valori per X e Y e non Z in
tutti i punti (vertici, estremi) della geometria
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
Tutti i tipi ad eccezione dei punti, multipunto e Rimozione di vertici adiacenti nella
dei punti negli aggregati
dimensione del tipo (2D/3D) duplicati in
ogni curva/frontiera
Tutti i tipi di tipo curva e le curve degli
Esistenza di almeno 2 vertici in ogni curva
aggregati
componente
coordinata 2D errata
F
coordinata 3D errata
F
Vertici 2D/3D adiacenti
duplicati
W
Meno di due vertici
F
GU_CPSurface2D, GU_CXSurface2D,
Esistenza di almeno 4 vertici in ogni
GU_CPSurfaceB3D, GU_CXSurfaceB3D
frontiera - anche sulle frontiere proiettate
Superfici di un GU_Aggregate2D e
delle superfici B3D non considerando
GU_Aggregate3D
vertici duplicati
GU_CPCurve2D/3D, GU_CXCurve2D/3D
Assenza di selfoverlapping in ogni curva
GU_CNCurve2D/3D,Curve in
componente
GU_Aggregate2D/3D
(curve semplici, anelli e frontiere di superfici
già garantite da altro controllo)
GU_CXCurve2D, GU_CXCurve3D,
Assenza di overlap tra due curve
GU_CXRing2D, GU_CXRing3D,
componenti
GU_CNCurve2D, GU_CNCurve3D
(frontiere delle superfici già garantite da altro
controllo)
GU_CPSimpleCurve2D/3D,GU_CPRing2D/3D, Ogni curva/frontiera componente sia
GU_CXRing2D/3D, GU_CPSurface2D,
semplice
GU_CXSurface2D,
GU_CPSurfaceB3D,
GU_CXSurfaceB3D
Superfici di GU_Aggregate2D/3D
GU_CPRing2D/3D, GU_CXRing2D/3D,
Ogni curva/frontiera componente sia chiusa
GU_CPSurface2D, GU_CXSurface2D,
GU_CPSurfaceB3D, GU_CXSurfaceB3D,
Superfici di GU_Aggregate2D/3D
GU_CNCurve2D/3D
Connessione della curva complessa
Meno di 4 vertici
F
Tutti i tipi 2D
GU_CPSurface2D GU_CXSurface2D
GU_CPSurfaceB3D GU_CXSurfaceB3D
Superfici di un GU_Aggregate2D e di un
GU_Aggregate3D
curva2D/3D sovrapposta, E
curva complessa 2D/3D
sovrapposta
E
curva2D (anello2D) non E
semplice, curva3D
(anello3D) non semplice,
frontiera esterna 2D
(interna 2D) non semplice,
frontiera 3D non semplice
curva2D (3D) non chiusa, E
Frontiera 2D (3D) non
chiusa, oppure quando
anello 2D/3D non chiuso
curva complessa 2D (3D)
non connessa
Esistenza della frontiera esterna in ogni
frontiera esterna 2D (3D) F
superficie componente
mancante
Assenza di buchi esterni alla propria
superficie 2D con buco
E
superficie componente
esterno
Assenza di buchi che toccano la frontiera
intersezione 2D errata
E
esterna della propria superficie componente frontiera esterna e interna
in più di un punto
Assenza di buchi che contengono altri buchi buco 2D innestato
E
della stessa superficie
Assenza di buchi che toccano un altro buco intersezione 2D errata tra E
della stessa superficie in più di un punto
buchi
Ogni superficie componente sia
superficie 2D non path- E
PathConnected
connessa
Le superfici componenti possono toccarsi al Intersezione 2D errata tra E
più in punti
superfici
pagina 27 di 42
Tabella GEOCOMPATIBILITYWARNING (solo per i MI SQL_Flat)
Struttura
< SCELEMNAME, SCELEMTYPE, SCATTRNAME, SCATTRTYPE
SFPHYSTRUCTNAME, SFPHYATTRNAME, ERROR, GEOMETRY,
SFPHYATTRIDNAME, OBJID>
Questa tabella riporta le segnalazioni inerenti le geometrie che hanno un tipo diverso da
quello richiesto, ma ritenuto compatibile (ad esempio, la geometria è di tipo multipoint
e contiene un solo punto e il tipo richiesto è point). La geometria viene quindi convertita
al tipo richiesto e poi sottoposta ai controlli descritti nella sezione precedente che
segnaleranno gli errori nella tabella GEOMETRYERROR.
Attualmente si riporta la geometria convertita (campo GEOMETRY), l’identificazione
dell’oggetto interessato (campi SFPHYATTRIDNAME, OBJID) e nel campo ERROR
il valore “conversione di tipo”
TABELLA METRICWARNING
Struttura
<SCELEMNAME,SCELEMTYPE,SCATTRNAME,SCATTRTYPE
SFPHYSTRUCTNAME,SFPHYATTRNAME, ERROR, GEOMETRY
SFPHYATTRIDNAME, OBJID>
Questa tabella non riporta errori, ma segnalazioni inerenti alcuni controlli metrici
effettuati sulle geometrie che sono state caricate nel DBF; tali segnalazioni sono da
considerare dei possibili warning rispetto a possibili geometrie errate e non comportano
l’eliminazione della geometria dal DBF.
In particolare, sono segnalati gli oggetti che hanno valori sotto soglia in alcuni controlli
metrici, riportandone la geometria e l’identificazione dell’oggetto di appartenenza. I
valori di soglia sono inseriti in fase di parametrizzazione del GeoUML validator.
I tipi di errore riportati nel campo ERROR sono: segmento o curva sotto soglia, cuspide,
perimetro poligono sotto soglia, area sotto soglia, troppi vertici. L’identificazione
dell’oggetto interessato avviene tramite i campi SFPHYATTRIDNAME, OBJID.
Tabella MINIMUMDISTANCESHAPETOPO (solo MI Shape_Topo)
Struttura
<DISTANCETYPE, GEOMETRYSETNAME1, PRIMIDNAME1, PRIMIDVALUE1,
GEOMETRYSETNAME2, PRIMIDNAME2, PRIMIDVALUE2,
DISTANCEVALUE, DISTANCEGEOMETRY BLOB>
La tabella riporta le geometrie primitive che non soddisfano la distanza minima
all’interno di ogni insieme topologico. Questa tabella associa la diagnostica alle solo
primitive fisiche che saranno poi usate per la ricostruzione delle componenti spaziali
degli elementi concettuali. Per ogni violazione riporta il tipo (DISTANCETYPE) delle
primitive confrontate (punto/punto, punto/segmento, segmento/segmento), gli shape
delle due primitive (GEOMETRYSETNAME), l’identificatore delle due primitive
(PRIMIDVALUE), il valore della distanza calcolata (DISTANCEVALUE) e infine il
segmento che visualizza la distanza tra le due primitive (DISTANCEGEOMETRY
BLOB).
pagina 28 di 42
5.6.3 Tabelle generate nel processo di normalizzazione
La normalizzazione è un processo importante soprattutto nel MI Shape_Topo e che
prevede la ricostruzione delle geometrie delle classi, strati e delle geometrie minime a
partire
dagli
archi
e
dai
nodi
della
sorgente
(tabelle
GEOCOMPATIBILITYWARNINGNORM,
GEOMETRYERRORNORM
e
METRICWARNINGNORM). Inoltre è verificata la congruenza delle strutture fisiche
utilizzate nella ricostruzione, specificando eventuali errori nella tabella
STRUCTURALCONSTRAINTVIOLATIONNORM.
Nel MI SQL_Flat multigeometria non esiste questa fase e nei MI
SQL_Flat_monogeometria (Oracle e Postgis) e Shape_Flat la normalizzazione è
responsabile della riaggregazione delle componenti spaziali di una classe che nella
sorgente sono memorizzate in strutture separate nella tabella della classe; ciò riguarda
quindi le classi con più componenti spaziali, le componenti spaziali collassate e gli
aggregati (Tabella STRUCTURALCONSTRAINTVIOLATIONNORM).
TABELLA ELEMENTSTATEDBF
Struttura
< ELEMENNAME, SCELEMTYPE, SFPHYSTRUCTNAME, CARDINALITY >
Riporta tutte le strutture fisiche previste dal MI e generate come tabelle nel DBF. Per
ogni struttura si riporta l’elemento concettuale di appartenenza col tipo e la cardinalità
(cardinality =0 se la struttura era assente in elementstate o presente, ma senza record).
La struttura è sostanzialmente identica alla tabella elementstate. Nei MI Shape-flat e
Shape_Topo la tabella elemenstatedbf aggiunge anche le tabelle di NULL
INTERPRETATION (_NI) assenti nella tabella elementstate caricandovi i valori dedotti
dall’analisi dei valori degli attributi. La cardinalità di una struttura fisica coincide con
quella definita in elementstate per quelle presenti nella sorgente e 0 per quelle assenti.
TABELLA GEOCOMPATIBILITYWARNINGNORM (solo MI Shape_Topo)
Struttura:
< SCELEMNAME, SCELEMTYPE, SCATTRNAME, SCATTRTYPE
SFPHYSTRUCTNAME, SFPHYATTRNAME, ERROR, GEOMETRY,
SFPHYATTRIDNAME, OBJID>
Questa tabella ha lo stesso obiettivo della tabella GEOCOMPATIBILITYWARNING
applicata alle geometrie ricostruite, il cui tipo viene riconosciuto dopo la ricostruzione e
nel caso in cui sia diverso dal richiesto, ma compatibile viene convertito segnalandolo
in questa tabella. Successivamente è sottoposto ai controlli della qualità geometrica
della tabella GEOMETRYERRORNORM. L’identificazione dell’oggetto interessato
avviene tramite i campi SFPHYATTRIDNAME, OBJID.
TABELLA GEOMETRYERRORNORM (solo MI Shape_Topo)
Struttura
<SCELEMNAME,SCELEMTYPE,SCATTRNAME,SCATTRTYPE
SFPHYSTRUCTNAME,SFPHYATTRNAME, ERRLEV, ERROR, GEOMETRY
SFPHYATTRIDNAME, OBJID>
La tabella GEOMETRYERRORNORM ha la stessa struttura dell’equivalente tabella
del caricamento e riporta:
pagina 29 di 42
-
gli errori incontrati nella topologia degli insiemi topologici ad eccezione della
verifica della qualità degli edge (curva semplice - verificato in caricamento); le
geometrie errate sono comunque conservate nel DBF. ERRLEVEL è sempre E e i
valori di ERROR sono i seguenti (la diagnostica non riporta in generale e, in
generale, la dimensione della geometria derivabile peraltro dallo shape di
appartenenza:
- segmento verticale: segmento 3D verticale;
- toposhape dj or tc on boundary error: archi che violano la relazione DJ or TC sui
boundary;
- primitiva topologica duplicata: nodi che violano la relazione DJ
- node – edge consistency error: nodo che viola relazione di DJ or TC con arco
- geometry 3d2d consistency error: la proiezione planare di un arco 3D non trova
il corrispondente arco 2D o la proiezione planare di un nodo 3D non trova il
corrispondente nodo 2D.
- l’incompatibilità del tipo della geometria ricostruita dagli archi/nodi dell’insieme
topologico (ERROR = SELECT_DERIVATION_ERROR);
- Errore nella derivazione dei poligoni 3d che rileva una differenza tra la frontiera del
poligono generato e quella che si genererebbe unendo le primitive 3d che lo
compongono
nella
tabella
di
composizione.
ERROR
=
“DERIVATION_ERROR_BOUNDARY”;
- gli errori della geometria ricostruita nel rispettare le caratteristiche del modello
ESFM del GEOUML (i valori di ERROR sono quelli specificati per la tabella
GEOMETRYERROR).
A differenza della tabella GEOMETRYERROR del caricatore la colonna GEOMETRY
riporta la geometria errata della sorgente per gli errori sulle primitive topologiche e la
geometria errata dopo la sua ricostruzione negli altri casi.
L’identificazione
dell’oggetto
interessato
avviene
tramite
i
campi
SFPHYATTRIDNAME, OBJID.
TABELLA METRICWARNINGNORM (solo MI Shape_Topo)
Struttura
<SCELEMNAME,SCELEMTYPE,SCATTRNAME,SCATTRTYPE
SFPHYSTRUCTNAME,SFPHYATTRNAME, ERROR, GEOMETRY
SFPHYATTRIDNAME, OBJID>
La tabella METRICWARNINGNORM ha la stessa struttura dell’equivalente tabella
METRICWARNING del caricamento, ma riporta le segnalazioni metriche rilevate sulle
geometrie ricostruite L’identificazione dell’oggetto interessato avviene tramite i campi
SFPHYATTRIDNAME, OBJID.
Tabella STRUCTURALCONSTRAINTVIOLATIONNORM
Struttura
<SCCONSTRAINTDESCR, SCLIVSCALA
SCELEMNAME, SCELEMTYPE, SCATTRNAME, SCATTRTYPE,
SFPHYSTRUCTNAME, SFPHYATTRNAME, ERROR, ERRLEV, VALUE,
SFPHYID1, SFPHYID2, OBJID1, OBJID2>
pagina 30 di 42
Un primo tipo di errori rilevati in questa tabella riguarda la riaggregazione di più
attributi geometrici (anche quelli prodotti dal mapping per il collassamento o quelli di
un aggregato) di una stessa classe che vengono riuniti nella struttura fisica della classe
(fusi nel caso dell’aggregato); la riaggregazione utilizza i valori dell’attributo ClassREF
della struttura fisica della geometria separata e l’attributo ClassID della struttura fisica
della classe. L’identificazione del record della geometria da riaggregare che presenta un
errore avviene tramite i campi SFPHYID1, SFPHYID2, OBJID1, OBJID2, mentre nel
campo VALUE si riporta il valore di ClassREF della struttura fisica della geometria
separata.
SCCONSTRAINTDESCR riporta “chiavi esportate” per segnalare un problema
inerente la correlazione tra strutture fisiche diverse.
Non tutte le situazioni anomale che si possono verificare generano diagnostica, pertanto
si dettagliano le situazioni anomale e il comportamento del validatore:
- più record della struttura fisica della geometria si riferiscono ad uno stesso oggetto
della classe; un valore geometrico non può essere scomposto su più record. Viene
segnalato “riferimento duplicato” nel campo ERROR e ERRLEV = E e le
geometrie sono eliminate e viene inserito un NULL nell’attributo geometrico
riaggregato nel record della classe;
- nessun record della struttura fisica della geometria si riferisce ad un oggetto della
classe. In questo caso viene inserito NULL nell’attributo geometrico riaggregato
nel record della classe senza segnalazione di diagnostica;
- un record della struttura fisica della geometria si riferisce ad un identificatore di
oggetto che è duplicato in più oggetti della classe. La geometria viene riportata
nell’attributo geometrico riaggregato di tutti gli oggetti che condividono
l’identificatore senza alcuna segnalazione diagnostica;
- un record della struttura fisica della geometria non trova alcun oggetto
corrispondente della classe. La geometria è eliminata senza alcuna segnalazione
diagnostica.
Un secondo tipo di errore riguarda le corrispondenze tra strutture fisiche degli insiemi
topologici. Anche in questo caso SCCONSTRAINTDESCR riporta “chiavi esportate” e
ERRLEVEL è sempre “E”..
In particolare i casi segnalati sono i seguenti:
- una primitiva geometrica non è utilizzata per ricostruire alcuna componente
spaziale o geometria dei tratti,… L’identificatore PRIMID di una primitiva di uno
shape topologico non viene referenziato nel campo PRIMID della tabella di
composizione. Il campo ERROR riporta: PRIMID not in component;
- una geometria ricostruita referenzia una primitiva topologica che non esiste. Un
valore di PRIMID della tabella di composizione non si relaziona ad alcun
identificatore di primitiva nello shape. Il campo ERROR riporta: COMPONENT
PRIMID not in topological shape;
- una geometria ricostruita non appartiene a nessun attributo geometrico di classe,
strato, di geometria minima. L’identificatore GEOID di una geometria ricostruita
presente nella tabella di composizione non viene referenziato da nessun oggetto di
classe, strato e da nessun tratto, evento, sottoarea minimo dell’insieme topologico
considerato. Il campo ERROR riporta: Component GEOID not in geometry;
pagina 31 di 42
-
-
una classe, strato tratto, evento, sottoarea referenzia una geometria ricostruita che
non esiste. In una classe, strato, geometria minima si riferisce un GEOID assente
nella tabella di composizione corrispondente. Il campo ERROR riporta: geometry
GEOID not in component.
Incongruenza tra una geometria 3D e la corrispondente 2D nel caso degli insiemi
topologici
5.6.4Tabelle generate dai controlli sul DBN
Tabella ELEMENTSTATEDBN
Struttura
< SCELEMENNAME, SCELEMTYPE, SFPHYSTRUCTNAME, CARDINALITY>
La tabella riporta tutte le strutture fisiche previste dal MI normalizzato del validatore e
memorizzate nel DBN. Nel caso di MI Shape_Topo il DBN non contiene più le tabelle
dell’insieme topologico in quanto sono state materializzate le geometrie nelle tabelle di
classe, strato, tratti, eventi, sottoaree. Nei MI Shape_Flat e SQL_Flat monogeometria il
DBN contiene in generale meno tabelle del DBF in quanto le classi con più attributi
geometrici e presenti in strutture fisiche separate vengono riunite in una sola struttura
fisica normalizzata nel DBN.
Lo scopo di questa tabella è quello di fornire le cardinalità delle nuove strutture dati
generate utili ad una valutazione dell’incidenza percentuale degli errori generati dai
controlli strutturali e dai controlli dei vincoli spaziali. Per ogni struttura fisica si riporta
cardinality =0 se la struttura è vuota o erano vuote o inesistenti le strutture dati di
generazione nella tabella elemenstateDBF. Nei MI SQL_Flat multigeometria esse
coincidono con quelle del DBN.
Tabella STRUCTURALCONSTRAINTVIOLATION
Struttura
<SCCONSTRAINTDESCR, SCLIVSCALA
SCELEMNAME, SCELEMTYPE, SCATTRNAME, SCATTRTYPE
SFPHYSTRUCTNAME, SFPHYATTRNAME, ERROR, ERRLEV, VALUE,
SFPHYID1, SFPHYID2, OBJID1, OBJID2
ERRLEVEL è sempre “E” per tutte le segnalazioni di questa tabella.
CONSTRAINTDESCR = Cardinalità. Assenza NULL in attributi concettuali
obbligatori o in attributi aggiunti dal MI e definiti obbligatori dal MI.
1. Obbligatorietà degli identificatori ClassID (UUID nel MI SQL_FLAT Oracle
multigeometria) delle classi, TopoID (UUID nel MI SQL_FLAT Oracle
multigeometria) degli strati, eventid, subregid, segmentID nelle corrispondenti
tabelle degli eventi, tratti, sottoaree. Il campo ERROR= Valori nulli nell’object ID;
si noti che in questo caso non è possibile identificare il record errato e quindi i
campi di identificazione contengono NULL e il campo VALUE contiene per
convenzione “#uuid nulli”;
2. Obbligatorietà degli attributi descrittivi e dei ruoli nelle classi e nelle associazioni e
dei ruoli negli strati. VALUE = NULL, ERROR = cardinalità minima violata.
2.1 attributi monovalore e ruoli delle classi, strati e associazioni. L’oggetto con
errore è identificato tramite il valore di ClassID (UUID) per attributi
pagina 32 di 42
monovalore e ruoli di una classe, TopoID(UUID) per i ruoli degli strati, col
valore di ClassREF (UUIDref) congiunto a eventid (subregid, segmentID)
nelle tabelle per eventi (tratti, sottoaree) e con la coppia <ruolo1, ruolo2> per
le associazioni.
2.2 attributi multivalore (anche datatype) delle classi e delle associazioni si
segnalano due situazioni di errore sulla tabella multivalore che si
differenziano nell’identificazione:
- righe con NULL nell’attributo descrittivo (o in uno degli attributi nel
datatype). L’identificazione della riga avviene tramite ClassREF
(UUIDref) per gli attributi delle classi e tramite la coppia <ruolo1,
ruolo2> nel caso di associazione;
- inesistenza di un record nella tabella per un oggetto. In questo caso è
identificato l’oggetto mancante tramite ClassID (UUID) per gli attributi
delle classi e tramite la coppia <ruolo1, ruolo2> nel caso di associazione.
3. Obbligatorietà degli attributi ClassREF (UUIDref nel MI SQL_FLAT Oracle
multigeometria) delle tabelle degli attributi multivalore (anche datatype), delle
tabelle degli eventi, tratti, sottoaree associate a classi o ad associazioni e
obbligatorietà dei ruoli delle tabelle delle associazioni. Il campo ERROR= Valori
nulli nei riferimenti a object ID; si noti che in questo caso non è possibile
identificare il record errato e quindi i campi di identificazione contengono NULL e
il campo VALUE contiene per convenzione “#ref nulli”;
CONSTRAINTDESCR = Univocità. Assenza di duplicazione negli attributi concettuali
dichiarati primary key e in quelli multivalore anche datatype; inoltre si controlla
l’univocità anche sugli identificazione introdotti dai MI.
1. Duplicati negli identificatori ClassID (UUID) per le classi, TopoID(UUID) per
gli strati,
ERROR= Valori duplicati nell’object ID, VALUE = #ripetizioni UUID. I campi
di identificazione riporteranno il valore dell’identificatore duplicato.
2. Duplicati negli identificatori eventid (subregid, segmentID) nelle tabelle degli
eventi (tratti, sottoaree). ERROR = UUID degli eventi duplicati (UUID dei tratti
duplicato, UUID delle sottoaree duplicati, VALUE = #ripetizioni UUID. I campi
di identificazione riporteranno il valore dell’identificatore duplicato.
3. Righe duplicate nella tabella multivalore (anche datatype). ERROR = valori
duplicati, VALUE = #duplicati, l’identificazione del record avviene tramite il
valore di ClasseREF (UUIDref).
4. Duplicazione della geometria di eventi, tratti, sottoaree. ERROR = eventi con
duplicazione geometrica (tratti con duplicazione geometrica, sottoaree con
duplicazione geometrica). I campi di identificazione riporteranno il valore
dell’identificatore degli eventi, tratti, sottoaree duplicati.
5. Più righe di una tabella di associazione si riferiscono alla stessa coppia di
oggetti. ERROR = valori duplicati nei riferimenti all’object ID, VALUE =
#duplicati, i campi identificatori contengono gli identificatori dei due ruoli
coinvolti.
Tabella FKCONSTRAINTVIOLATION
Struttura
< SCCONSTRAINTDESCR, SCLIVSCALA,
SCELEMNAME,SCELEMTYPE,SCATTRNAME,SCATTRTYPE
SFPHYSTRUCTNAME,SFPHYATTRNAME, ERROR, ERRLEVEL, VALUE
SFPHYID, SFPHYID2, OBJID1, OBJID2>
pagina 33 di 42
ERRLEVEL è sempre “E” per tutte le segnalazioni di questa tabella.
CONSTRAINTDESCR = chiavi esportate.
Queste segnalazioni riguardano i ruoli o gli attributi ClassREF (UUIDref) che non
referenziano oggetti esistenti. Per questi errori ERROR = Riferimento a object ID
inesistente,
1. Ruoli in classe o strato riportano un identificatore di un oggetto che non esiste
nello strato o nella classe referenziata (includendo le classi sue specializzazioni).
VALUE contiene l’identificatore non trovato, i campi identificatori riportano
l’identificatore dell’oggetto della classe, strato errato.
2. Almeno uno dei due ruoli di un’associazione contiene un identificatore che non
esiste nello strato o nella classe referenziata (includendo le classi sue
specializzazioni). Questa segnalazione produce due record di diagnostica.
VALUE contiene nei due record il valore dei due ruoli, i campi identificatori
riportano la coppia dei valori dei due ruoli.
3. L’attributo ClassREF (UUIDref) delle tabelle degli eventi, tratti, sottoaree o
delle tabelle multivalore (anche datatype) riporta un identificatore di un oggetto
inesistente nella classe (o sue specializzazioni) referenziata. VALUE contiene
l’identificatore non trovato, i campi identificatori riportano l’eventid, segmentid,
subregid dell’evento, tratto, sottoarea o del multivalore errato.
4. La coppia di attributi che correlano un attributo multivalore (anche datatype) ad
una istanza di associazione non trova una corrispondente coppia
nell’associazione. VALUE=NULL e i campi identificatori riportano la coppia
dei valori errati.
CONSTRAINTDESCR = chiavi esportate.
Queste segnalazioni riguardano gli attributi con dominio enumerato che contengono un
valore inesistente nel dominio. Per questi errori ERROR = Riferimento a codice
inesistente, VALUE riporta il valore inesistente
I campi identificatori della diagnostica riportano il ClassID degli oggetti col codice
errato, l’eventid (segmentid, subregid) dell’evento (tratto, sottoarea) con il codice errato,
o il ClassREF nel caso di attributi multivalore (anche datatype) col codice errato. Nel
caso delle associazioni i campi identificatori contengono la coppia di ruoli di
identificazione dell’associazione.
Tabella GEOUMLCONSTRAINTNOTVERIFIED
Struttura
< SCCONSTRAINTNAME, INFOMESSAGE, CONSTRAINTTYPE>
Questa tabella elenca i vincoli spaziali che non sono stati eseguiti in quanto assente
l’elemento vincolato o vincolante. Il campo SCCONSTRAINTNAME riporta la
descrizione del vincolo non verificato (ad es., GZ_STR.Posizione ( DJ) perOgni
GZ_STR.Posizione). INFOMESSAGE segnala se sia assente l’elemento vincolato (D) o
quello vincolante (G) e infine CONSTRAINTTYPE riporta il tipo di vincolo (ad es.,
composedOf, exists).
pagina 34 di 42
Tabella GEOMETRICCONSTRAINTVIOLATION
Struttura
<SCCONSTRAINTNAME, CONSTRAINTTYPE, SCLIVSCALA
SCVINCOLATANAME, SCELEMTYPE, SCATTRNAME, SCATTRTYPE,
SFPHYSTRUCTNAME, SFPHYATTRNAME, GEOMETRY>
Questa tabella contiene una riga per ogni violazione riscontrata di un Vincolo Spaziale
GeoUML.
SCCONSTRAINTNAME riporta la descrizione del vincolo controllato (ad es.,
CANALE.Percorso.BND ( IN) unione ND_IDR.Posizione), CONSTRAINTTYPE
riporta il tipo di vincolo (ad es., composedOf, exists) e infine GEOMETRY riporta la
geometria vincolata errata.
pagina 35 di 42
Appendice 1. Installazione, esecuzione e aggiornamento del GeoUMLvalidator
1.1 Requisiti
• Installazione di una Java runtime machine JRE versione1.5 o superiore
• Sistemi operativi Windows, Unix-like (linux, MacOS10 o superiori, Sun
Solaris..)
• 50MB liberi ad installazione effettuata per i file temporanei.
• Installazione dei sistemi Postgres e PostGIS
• Creazione dei database di appoggio
• Per la validazione di dataset Oracle è necessario aggiungere al Validator la
libreria proprietaria Oracle JDBC (ojdbc14.jar ) scaricabile da:
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 completo (per la pubblica amministrazione)
Dopo aver effettuato il download dal sito spatialdbgroup.polimi.it del file .zip
contenente il programma è sufficiente estrarre il contenuto del file in una cartella scelta
dall’utente. L’estrazione genera una cartella chiamata GeoUML-Validator contenente il
programma, la licenza accettata all’atto del download (GeoUML per soggetti di diritto
pubblico.txt) e la licenza da far controfirmare dal soggetto di diritto privato al quale si
fornisce il Validator “chiuso” generato dal GeoUML Validator completo (GeoUML
validator Chiuso.txt) e la cartella “Report” per la produzione del documento di
reportistica degli errori.
1.3 Esecuzione del programma
Per avviare il programma eseguire il file GeoUMLvalidator.exe per i sistemi operativi
Windows oppure ./GeoUMLvalidator.sh da console /bin/bash o /bin/sh per i sistemi
operativi Unix-like (in questo caso è necessario che il file abbia i permessi che rendono
l’esecuzione possibile); qualora i tempi di esecuzione siano troppo alti è possibile
migliorare le prestazioni del validator, ottimizzando alcuni parametri nei file
GeoUMLvalidator.bat (Windows) o GeoUMLvalidator.sh (Unix-like) e utilizzare poi
questi file per l’esecuzione. Sebbene nei due file esistano alcuni commenti per
l’ottimizzazione si ricorda che tale operazione richiede personale esperto che sappia
pagina 36 di 42
valutare correttamente le conseguenze di tali operazioni. Il download del validator
genera automaticamente l’icona dell’applicazione nel caso del sistema operativo
MacOS10x.
1.4 Creazione dei database di appoggio
Dopo aver installato Postgres e PostGIS è necessario creare i database di appoggio in
Postgres; si ricorda che i database di appoggio sono due nel caso dei modelli
implementativi Shape e uno solo nel caso dei modelli implementativi SQL_Flat (si
omette il database di normalizzazione). Si illustrano nel seguito le operazioni da
eseguire per la creazione dei database, utilizzando l’interfaccia PgAdmin di Postgres e
supponendo di creare due database sullo stesso calcolatore sul quale si è installato il
Validator. L’interfaccia PgAdmin propone alla sinistra l’elenco dei server disponibili.
Selezionando Localhost (server sul quale si stannno effettuando queste operazioni) con
un doppio click, appaiono le voci Database, Tablespace,…. Posizionarsi sulla voce
Database, premere tasto destro del mouse e selezionare la voce Nuovo database.
Appare la scheda
mostrata in figura
nella
quale
va
inserito nel campo
Nome il nome che
assegnate al primo
database
di
appoggio (in figura
si assegna il nome
DBF, supponendo
che sia quello usato
per il caricamento
dei
dati
da
controllare),
selezionato poi nel
campo Modello il
valore postgis si
preme OK. Ripetere
la stessa operazione
per
il
secondo
database
(nell’esempio della
figura sarebbe il
database d utilizzare
per la normalizzazione). Dopo queste due operazioni i due database appariranno
nell’elenco dei database esistenti nell’elenco di sinistra di PgAdmin.
Attenzione
Dato che i database utilizzati per il caricamento e la normalizzazione vengono cancellati
e riscritti non si devono utilizzare per queste funzioni dei database dei quali si vuole
conservare il contenuto.
pagina 37 di 42
1.5
Aggiornamento delle versioni e specifiche
Esistono due modalità distinte per allineare il software ad una nuova versione
disponibile dello strumento:
Validator completo
Per utilizzare una nuova versione X.Y del Validator ci sono due possibilità che
dipendono dalla versione della specifica importata nel Validator in uso:
- se la specifica caricata nel vecchio Validator era stata generata da un Catalogue
versione X.* è sufficiente importare la specifica presente nel vecchio Validator
nel nuovo Validator;
- se la specifica era stata generata da un Catalogue versione (X-1).* allora è
necessario rigenerare le specifiche con un Catalogue di versione X.*, esportarle
dal Catalogue e importarle nel nuovo Validator.
Validator chiuso
Come è spiegato nella guida la generazione di un Validator chiuso è un’operazione
eseguita dal soggetto di diritto pubblico che ha la responsabilità di cedere il Validator ad
un soggetto di diritto privato e avviene utilizzando il Validator completo. Il soggetto
privato che sta utilizzando il Validator chiuso e che vuole utilizzare una nuova versione
X.Y del Validator chiuso dovrà comportarsi in uno dei due seguenti modi che
dipendono dalla versione della specifica importata nel Validator in uso:
- se la specifica caricata nel vecchio Validator chiuso era stata generata da un
Catalogue versione X.* allora l’aggiornamento potrà essere effettuato
direttamente dal soggetto che sta usando il Validator chiuso, effettuando il
download dal sito spatialdbgroup.polimi.it dell’aggiornamento del validator
chiuso e seguendo le istruzioni presenti nel download;
- se la specifica era stata generata da un Catalogue versione (X-1).* allora è
necessario che il soggetto che ha generato il precedente Validator chiuso
riproduca un nuovo Validator chiuso sulla specifica prodotta da un Catalogue di
versione X.*.
pagina 38 di 42
Appendice 2. Configurazione e utilizzo di Ireport
Ireport è un prodotto open source per la generazione di documenti contenenti dati
estratti da database disponibile per il download e l’installazione al sito
http://jasperforge.org/projects/ireport. Questa appendice e i template generati per la
produzione dei report fanno riferimento alla versione 4.5.0 di Ireport.
2.1 Inclusione delle librerie per accedere alla tecnologia Apache Derby
Avviare il programma e
selezionare dal menù strumenti
la voce Opzioni come mostrato
nella figura a destra.
Nella scheda che appare
successivamente e mostrata
sotto si deve selezionare
Classpath e poi selezionare il
bottone Add Jar, facendo apparire la scheda Aggiungi Jar(s) / path al classpath che
appare in basso nella figura seguente.
Usando la funzione
cerca in posizionarsi
nella cartella dove si
sono copiati i file del
GeoUML validator e
poi nella sottocartella
lib dove si selezionano
i file “derby.jar” e
“derbyLocale_it.jar”
Infine
premere
il
bottone Apri. Tornati
nella
precedente
scheda premere il
bottone OK.
2.2 Connessione al database dei report preconfezionati
I report preconfezionati sono due (uno analitico e uno sintetico) sono inclusi nei file di
distribuzione del GeoUMLvalidator, ma devono essere inizializzati con l’indicazione di
dove si trovi il database Derby creato quando si è attivata la funzione genera database
di reportistica del Validator.
Posizionarsi nella cartella dove si sono copiati i file del GeoUML validator e poi nella
sottocartella report. Aprire con un qualsiasi editor di testo (Blocco Note) il file
“DataSourceValidatorReport.xml” (vedi figura seguente).
pagina 39 di 42
La riga evidenziata in figura appare preconfigurata al solo fine di esemplificare la
sintassi della riga; essa infatti deve essere sostituita con il pathname completo della
cartella nella quale sono memorizzati i file del database Derby con i dati da estrarre. Ad
esempio, se la cartella di destinazione dei report indicata alla funzione genera database
della reportistica fosse stata D:\cartellareport allora la riga evidenziata sarebbe
sostituita dalla riga
<connectionParameter name=”Url”>
<![CDATA[jdbc:derby:D:\cartellareport\reportdb]]>
</connectionParameter>.
Dopo la sostituzione salvare e chiudere il file.
A questo punto ritornare alla scheda iniziale di Ireport, mostrata sotto, e selezionare
l’icona evidenziata per la connessione al database.
Nella scheda Connections/Datasources che appare selezionare il bottone Import e nella
successiva
scheda
riportata in figura sotto
selezionare tramite la
funzione Cerca in il
file appena salvato al
passo precedente. La
selezione del bottone
Apri
comporta
l’aggiunta nell’elenco
delle
connessioni
precedenti di una
nuova
connessione
indirizzata al database
Derby; se l’apertura
fallisce significa che è
stato commesso un errore nella modifica del pathname nel file precedente.
pagina 40 di 42
A questo punto è conveniente verificare la correttezza della connessione esplicitata,
selezionando la connessione appena
creata e premendo il bottone Modify.
Nella successiva scheda, mostrata nella
figura a fianco, premere il bottone
prova per testare la connessione; se
l’operazione fallisce verificare la
correttezza del pathname inserito con
l’editor di testo.
Se tutto è andato a buon fine ora è
possibile creare i documenti.
Dalla scheda corrente uscire premendo
il bottone Annulla e contestualmente
uscire dalla scheda Connections
/Datasources premendo il bottone Close.
2.3 Generare dei documenti
La generazione dei documenti richiede l’apertura e compilazione del template del report
e il caricamento dei dati nel template per produrre il documento. Nel menù principale di
Ireport selezionare il menù File alla voce Apri report e nella successiva scheda con la
funzione Cerca in posizionarsi nella cartella dove si sono copiati i file del Validator e
poi nella sottocartella report nella quale ci si posiziona nell’ulteriore sottocartella
sintetici o analitici in base al tipo di
report (in figura si è scelto il report
sintetico).
Compile report
Nella cartella selezionare il file
reportMasterSintetico.jrxml (oppure
il file reportMasterAnalitico.jrxml nel
caso dell’analitico).
Dopo la selezione appare nella
finestra centrale di Ireport (vedi
figura a lato) lo schema del report che
sarà generato. Selezionare l’icona
compile report che predispone il
report per il caricamento dei dati. La
compilazione genera una diagnostica
visibile nella scheda Report Problems windows che appare sotto quella mostrata in
figura.
Se la generazione è avvenuta con successo si può generare il documento con i dati,
eseguendo le due seguenti operazioni: si seleziona nel box della sorgente dati quella per
la quale si era creata
la connessione in
precedenza e poi si
preme il bottone
Anteprima
come
indicato in figura.
Ireport visualizza il documento in un’altra scheda, mostrata nella figura seguente, dove
è possibile visionare le pagine del documento creato. Cambiare figura seguente
pagina 41 di 42
Da questa scheda è possibile stampare il documento creato oppure esportarlo in diversi
formati, quali ad esempio .RTF, PDF
e .ODT. Le due funzionalità sono
attivate selezionando le icone poste
sopra il report visualizzato: icona
dischetto per l’esportazione e l’icona
stampante per la stampa. Il
documento riporta un’intestazione
nella quale si descrivono la specifica
di contenuto di riferimento, la DPS
utilizzata per la validazione del
dataset e i relativi parametri.
Entrambi i report estraggono i dati
delle singole tabelle della reportistica
descritte nella Sezione 5 di questa
guida.
pagina 42 di 42