Gestione venatoria Friuli - Server users.dimi.uniud.it

Indice
Indice....................................................................................................................................................i
Introduzione.........................................................................................................................................1
1. Analisi dei Requisiti.........................................................................................................................3
1.1 Distretti Venatori........................................................................................................................3
1.2 Riserve di Caccia........................................................................................................................5
1.3 Azienda faunistico-venatoria .....................................................................................................5
1.4 Azienda agri-turistico-venatoria.................................................................................................6
1.5 Zone cinofile
.........................................................................................................................6
2. Progettazione Concettuale................................................................................................................7
3. Progettazione Logica......................................................................................................................19
4. Creazione ed Istanziazione della BD Oracle..................................................................................24
5. Visualizzazione dei dati con GeoServer.........................................................................................28
1.6 Alcune Implementazioni..........................................................................................................28
30
Bibliografia........................................................................................................................................42
i
ii
Introduzione
Lo scopo di questo laboratorio è quello di progettare e modellare un sistema informativo
informatizzato per la gestione venatoria della Regione Friuli Venezia Giulia.
Un sistema informativo ha la capacità di raccogliere, elaborare e archiviare dati, per produrre e
distribuire informazioni a tutti gli utenti che ne hanno bisogno.
La gestione venatoria è l’insieme di tutte quelle attività necessarie all’attuazione di un prelievo
venatorio programmato e funzionale con lo scopo di conseguire gli obiettivi stabiliti dal Piano
Faunistico Regionale.
Il Piano Faunistico Regionale si occupa della tutela, della conservazione e della riproduzione della
fauna selvatica e anche della gestione del patrimonio faunistico e della gestione venatoria.
Per realizzare questo sistema informativo, è necessario considerare le seguenti tre fasi.
La prima fase si compone in:
•
analisi e raccolta dei requisiti;
•
progettazione concettuale;
•
progettazione logica;
L’analisi e la raccolta dei requisiti identificherà tutte le peculiarità e caratteristiche che l’utente si
aspetta quando interagirà con il sistema.
La progettazione concettuale costruirà, a partire dai requisiti individuati, uno schema concettuale.
Di solito, il modello utilizzato per costruire uno schema concettuale è il modello ER. Poiché il
problema preso in esame usa componenti spaziali, noi utilizzeremo un modello spaziale come il
modello CGG [4], un’estensione spaziale (temporale) del modello ER.
La progettazione logica costruirà uno schema a partire dallo schema prodotto durante la
progettazione concettuale. A causa della presenza di componenti spaziali, il classico modello
relazionale verrà esteso con l’inserimento di oggetti spaziali.
La progettazione concettuale e logica saranno implementate utilizzando il tool ChronoGeoGraph.
Tale tool permette di costruire schemi CGG [4] e, allo stesso tempo, possiede tutte le funzionalità
necessarie per la loro traduzione in schemi logici basati sul modello di Oracle.
La seconda fase consiste nell’implementare lo schema su un DBMS, nel nostro caso Oracle, e
successivamente, popolare le tabelle con i vari dati acquisiti nella prima fase.
1
La terza fase sarà quella della visualizzazione e per fare ciò utilizzeremo la tecnologia
GeoServer[7].
GeoServer[7] è un server che ci permette di visualizzare, inserire e modificare oggetti geografici
tramite una semplice interfaccia web.
2
1. Analisi dei Requisiti
La Regione Friuli Venezia Giulia si estende su una superficie di 7856,50 Kmq ed è suddivisa in
quattro provincie: Gorizia 466,00 Kmq, Pordenone 2273,20 Kmq, Trieste 211,80 Kmq e Udine
4905,40 Kmq.
La Regione ha una superficie di 6725,50 Kmq di territorio agro-silvo-pastorale, che consiste in tutto
quel territorio usato dalla fauna per poter vivere e riprodursi.
Per una gestione venatoria seria e sostenibile, la Giunta Regionale emana leggi e direttive.
L’ultima legge in materia di disposizioni per la programmazione faunistica e per l’esercizio
dell’attività venatoria è la Legge Regionale del 6 Marzo 2008 [2]. Insieme a questa legge, è stata
approvato il Piano Faunistico Regionale, allegato al DGR 26.06.2008, n.1264 [1], che istituisce i
Distretti Venatori, le Riserve di Caccia che sono destinate alla caccia pubblica, le Aziende venatorie
e le Zone cinofile che sono destinate a caccia riservata a gestione privata.
Le competenze in materia venatoria sono esercitate dai Distretti Venatori.
1.1
Distretti Venatori
I Distretti Venatori sono unità territoriali omogenee dal punto di vista ambientale e di vocazione
faunistico, di usi e consuetudini locali e sono istituiti con delibere dalla Giunta Regionale.
Un Distretto Venatorio è composto dall’insieme delle riserve di caccia, delle aziende faunisticovenatorie, delle aziende agri-turistico-venatorie e delle zone cinofile.
Ogni distretto venatorio ha un Presidente, un VicePresidente e un’assemblea ed un codice che
identifica univocamente ogni singolo distretto.
La superficie e il perimetro di ogni Distretto Venatorio vengono calcolatati in base alle diverse
tipologie agro-ambientale e alle diverse tradizioni socio-culturali delle comunità che vivono in
regione.
3
Nella Figura 1, possiamo vedere che il territorio regionale è suddiviso in 15 distretti. Ad ogni
distretto è associata sia la sua superficie territoriale che il numero delle riserve di caccia.
In definitiva, la Regione Friuli Venezia Giulia ha 237 riserve di caccia su una superficie distrettuale
totale di 7826,02 Kmq. Sempre in Figura 1, le città di Gorizia e di Trieste sono escluse dall’attività
venatoria.
Figura 1-1: Distretti Venatori e Riserve di Caccia
4
1.2
Riserve di Caccia
Il territorio Regionale destinato a gestione venatoria pubblica è suddiviso in unità territoriali
chiamate riserve di caccia.
Le riserve di caccia sono composte da associazioni di cacciatori che operano secondo le direttive e
le leggi emanate dallo Stato, dalla Regione e dalla stessa Riserva di Caccia.
I naturali confini della riserva di caccia possono essere modificati attraverso accorpamenti di
territori confinanti se e solo se essi sono necessari per un miglioramento dell’attività venatoria.
Ogni riserva di caccia è diretta da un Direttore che è il rappresentante della riserva.
Il suo lavoro è quello di attuare il Piano Venatorio Distrettuale, attuare il regolamento dell’attività
venatoria e trasmettere al rispettivo Distretto Venatorio di appartenenza tutte le analisi e consuntivi
di gestione venatoria.
Ogni Riserva di Caccia viene identificata da un codice. La Giunta Regionale definisce la superficie
territoriale e l’indice venatorio di ogni riserva di caccia.
Per un elenco di tutte le riserve di caccia della Regione, si rimanda al Paragrafo 4.2.1 del Piano
Faunistico Regionale (PFR) [2].
Ogni Riserva di Caccia, in base alla Massima Produzione Sostenibile (MPS), può determinare il
numero massimo di cacciatori che possono operare nella riserva.
La MPS corrisponde al massimo prelievo venatorio compatibile con la conservazione delle risorse
faunistiche e cioè tali da non indurre la diminuzione della fauna (definizione tratta dal PFR).
A questo valore di applica un Indice Teorico di Soddisfazione Specifica (ITSS) che individua il
numero di soggetti abbattibili per ogni singola specie.
Per avere un elenco del numero massimo di cacciatori per ogni Distretto Venatorio e per ogni
singola Riserva di Caccia, si rimanda alla Tabella t1 dell’allegato al Piano Faunistico Regionale [2].
1.3
Azienda faunistico-venatoria
Queste aziende hanno lo scopo di ripristinare e migliorare l’ambiente naturale per la protezione e
l’incremento della fauna. Le aziende sono istituite a favore di uno o più proprietari o cacciatori che
utilizzano i loro terreni per una sana attività venatoria.
Ogni azienda viene identificata da un codice e possiede una determinata superficie.
5
1.4
Azienda agri-turistico-venatoria
Queste aziende sono istituite con lo scopo di consentire un’integrazione del reddito delle imprese
agricole. Ogni azienda viene identificata da un codice e possiede una determinata superficie.
Sia le aziende faunistico-venatoria che le aziende agri-turistico-venatoria, in base alla legge
regionale attuale, devono costituire non più del 10% del territorio cacciabile di ogni riserva di
caccia. Quando i territori cessino di far parte di un’azienda, essi saranno inclusi direttamente nella
riserva di caccia confinante.
Per un elenco di tutte le aziende venatorie, si rimanda al Piano Faunistico Regionale, Paragrafo
4.41.
1.5
Zone cinofile
Le zone cinofile vengono istituite per l’addestramento, l’allevamento, le prove cinofile e le gare per
i cani da caccia. Queste zone, in base alla legge regionale attuale, non devono interessare più del
20% del territorio di ciascuna riserva di caccia.
Ogni zona cinofila viene identificata da un codice e possiede una determinata superficie.
Anche in questo caso, per un elenco di tutte le zone cinofile della Regione, si rimanda al Piano
Faunistico Regionale, Paragrafo 4.5.
6
2. Progettazione Concettuale
La fase di Progettazione Concettuale consiste nella costruzione di uno schema CGG [4], a partire
dai requisiti precedentemente raccolti.
Per costruire il nostro sistema informativo, utilizzeremo il territorio di schema, che risulta essere
costituito dalla regione Friuli Venezia Giulia (FVG), e sei entità principali.
Poiché la regione è organizzata in provincie, introduciamo l’entità Provincia.
L’entità Provincia è un’entità spaziale con una geometria di tipo multi-polygon. Questa entità viene
identificata univocamente da un attributo chiave, Prv_Cod, e oltre ad esso, abbiamo individuato altri
attributi: Denominazione, Prv-Sigla e SuperficieKmq. L’attributo Denominazione memorizza il
nome della provincia, l’attributo Prv_Sigla memorizza la sigla della provincia e l’attributo
SuperficieKmq è un attributo derivato dall’entità spaziale Provincia.
La Figura 2-1 mostra tale entità.
Figura 2-2: L'entità spaziale Provincia
Una Provincia è composta da vari comuni e perciò, abbiamo individuato un’altra entità, l’entità
Comune. Anche questa è un’entità spaziale con una geometria di tipo multi-polygon.
In questa entità abbiamo definito un solo attributo, Denominazione, che è anche l’attributo chiave.
Questo attributo memorizza il nome di ogni singolo Comune.
7
Tra l’entità Provincia e l’entità Comune esiste una relazione di aggregazione spaziale, come in
Figura 2-2.
Figura 2-3: La relazione di aggregazione tra Provincia e Comune
Poiché la Regione è suddivisa in distretti venatori, l’entità che ci interessa adesso modellare è il
Distretto Venatorio. Tale entità, spaziale, ha una geometria di tipo multi-polygon e un attributo
chiave CodiceDistretto, che la identifica univocamente.
Questa entità ha altri attributi: Presidente, VicePresidente, Perimetro, Denominazione,
NumRiserCaccia e SuperficieKmq. Sia l’attributo Presidente e sia l’attributo VicePresidente sono
attributi
composti,
rispettivamente
formati
da
NomePresidente,
CognomePresidente,
NomeVicePresidente e CognomeVicePresidente.
L’attributo Denominazione e l’attributo Perimetro vengono utilizzati per memorizzare il nome e il
perimetro di ciascun distretto.
Ogni Distretto può comprendere un numero massimo di riserve di caccia e ciò viene definito
utilizzando l’attributo NumRiserCaccia.
Infine, la SuperficieKmq è un attributo derivato dall’entità spaziale Distretto Venatorio.
La Figura 2-3 mostra la definizione dell’entità spaziale Distretto Venatorio.
8
Figura 2-4: L'entità Distretto Venatorio
Un Distretto Venatorio è composto da riserve di caccia e quindi abbiamo definito un’altra entità
spaziale, anch’essa con una geometria di tipo multi-polygon, chiamata Riserva di caccia. La
relazione esistente tra Distretto Venatorio e Riserva di Caccia è una relazione di aggregazione
spaziale.
9
La Figura 2-4 mostra tale relazione.
Figura 2-5: La relazione di aggregazione tra Distretto Venatorio e Riserva di Caccia
Come possiamo vedere in Figura 2-4, una Riserva di Caccia viene identificata univocamente da un
codice, Cod_Riserva. Ognuna di esse ha alcuni attributi: Direttore, IndiceVenatorio, MaxSoci,
Denominazione, AreaCatastale, MPSUngulati e SuperficieKmq. L’attributo Direttore è un attributo
composto, formato da NomeDirettore e CognomeDirettore.
Ogni Riserva di Caccia ha un attributo Denominazione, che definisce il nome della riserva, un
attributo MaxSoci, per il numero massimo di cacciatori per ogni riserva di caccia, un attributo
AreaCatastale, per definire l’area di ogni riserva di caccia memorizzata nelle mappe catastali, un
attributo MPSUngulati, utilizzato per rappresentare il numero massimo di prelievo venatorio per
ogni tipo di animale e un attributo IndiceVenatorio, utilizzato per definire un indice venatorio per
ogni riserva di caccia.
10
Infine, la SuperficieKmq è un attributo derivato dall’entità spaziale Riserva di caccia.
Una riserva di caccia può anche contenere delle aziende di caccia privata a gestione privata e per
questo, abbiamo definito un’altra entità spaziale con una geometria di tipo multi-polygon, chiamata
Azienda, messa successivamente in relazione con Riserva di Caccia.
La figura 2-5 mostra tale relazione.
Figura 2-6: La relazione tra Riserva di Caccia e Azienda
La nuova entità Azienda viene identificata univocamente da un codice, CodiceAzienda, e possiede
anche altri attributi, Denominazione e SuperficieKmq. L’attributo Denominazione memorizza il
nome dell’azienda e invece l’attributo SuperficieKmq è un attributo derivato dall’entità spaziale
Azienda.
La relazione include tra Azienda e Riserva di caccia è una relazione topologica di tipo contains,
Figura 2-5, che indica che una Riserva di caccia può contenere molte aziende e che un’azienda può
essere in una sola Riserva di caccia.
La relazione include possiede anche un attributo ScadConcessione, che indica il termine di scadenza
della concessione per l’attività venatoria privata.
Dalla fase di analisi e raccolta dei requisiti, un’azienda può essere di tipo faunistico-venatoria, agrituristico-venatoria e una zona cinofila.
Per definire questo vincolo, abbiamo deciso di fare una specializzazione totale e disgiunta
dell’entità Azienda.
11
La figura 2-6 mostra tale specializzazione.
Figura 2-7: La relazione di specializzazione per l'entità Azienda
Poiché una riserva di caccia può corrispondere o alla dimensione di un comune o un comune può
avere più di una riserva o una riserva di caccia può contenere più comuni, abbiamo deciso di fare
due specializzazioni totali e disgiunti, una per il Comune e una per la Riserva di Caccia.
Nella prima specializzazione, figura 2-7, abbiamo specializzato Comune in Comune Standard, che
rappresenta tutti i comuni il cui territorio è uguale a quello di una riserva, Comune multiriserva, che
memorizza tutti i comuni che comprendono più riserve, e Comune sottoriserva, dove il suo
territorio è compreso in una riserva che contiene più comuni.
12
Figura 2-8: Specializzazione totale e disgiunta dell'entità spaziale Comune
Invece, per la seconda specializzazione, Figura 2-8, abbiamo specializzato l’entità Riserva di Caccia
in Riserva standard, che rappresenta le riserve il cui territorio è uguale a quello del comune di
appartenenza, Riserva multicomune, che rappresenta tutte le riserve che consistono di più comuni, e
Riserva sottocomune, che rappresenta tutte le riserve il cui territorio è più piccolo del territorio del
comune di appartenenza.
13
Figura 2-9: La specializzazione totale e disgiunta dell’entità spaziale Riserva di caccia
Successivamente abbiamo individuato delle relazione tra Comune sottoriserva e Riserva
multicomune, tra Comune standard e Riserva standard e tra Comune multiriserva e Riserva
sottocomune.
La prima relazione è una relazione topologica di tipo contains, Figura 2-9, che indica che una
Riserva multicomune può contenere da due a molte istanze di Comune sottoriserva, invece ogni
Comune sottoriserva è contenuto in una sola Riserva multicomune.
Figura 2-10: Relazione di tipo contains tra Comune sottoriserva e Riserva multicomune
14
La seconda relazione è una relazione topologica di tipo equals, Figura 2-10, che indica che ogni
Comune standard è in relazione di uguaglianza con esattamente una sola Riserva standard, e ogni
Riserva standard è in relazione di uguaglianza con esattamente un solo Comune standard.
Figura 2-11: Relazione di tipo equals tra Comune standard e Riserva standard
La terza e ultima relazione è ancora una relazione topologica di tipo contains, Figura 2-11, che
indica che un Comune multiriserva contiene da due a molte Riserve sottocomune, e una Riserva
sottocomune è contenuta in un solo Comune multiriserva.
Figura 2-12: Relazione di tipo contains tra Comune multi riserva e Riserva sottocomune
15
L’ultima entità del nostro modello è quella che prende il nome di Cacciatore. L’entità Cacciatore è
identificata univocamente da un codice, CodiceFiscale, ed ha alcuni attributi.
Gli attributi dell’entità Cacciatore sono: Nome, Cognome e Indirizzo.
L’attributo Indirizzo è un attributo composto, formato dall’attributo Via, Numero e CAP.
La Figura 2-12 mostra tale definizione.
Figura 2-13: L'entità Cacciatore
L’entità Cacciatore si mette in relazione con altre due entità, rispettivamente l’entità Comune e
l’entità Riserve di caccia.
Con l’entità Comune, definisce la relazione risiede, Figura 2-13, che indica che un Cacciatore
risiede in un solo comune, e che in un Comune risiedono molti cacciatori.
Figura 2-14: La relazione "risiede" tra l'entità Cacciatore e l'entità Comune
16
Con l’entità Riserva di caccia, definisce la relazione caccia, Figura 2-14, che indica che in una
Riserva di caccia possono cacciare molti cacciatori e che un cacciatore può cacciare in una sola
Riserva di caccia.
Figura 2-15: La relazione "caccia" tra l'entità Cacciatore e l'entità Riserva di caccia
Mettendo insieme tutte le entità e le relazioni analizzate precedentemente, otteniamo lo schema
globale come visualizzato in Figura 2-15.
17
Figura 2-16: Diagramma completo per la gestione venatoria del Friuli Venezia Giulia
18
3. Progettazione Logica
La fase di Progettazione Logica rappresenta la base di dati come una collezione di relazioni.
Partendo da uno schema concettuale, si arriva a costruire uno schema logico equivalente utilizzando
un opportuno algoritmo di traduzione. L’algoritmo di traduzione è implementato nello stesso tool
utilizzato per costruire lo schema concettuale. L’algoritmo di fronte ad un’entità E dello schema
concettuale, costruisce una relazione R che contiene tutti gli attributi semplici di E. Se esiste un
attributo composto, allora inserisce nella relazione solo gli attributi componenti semplici. Per
definire la chiave primaria di R, si sceglie uno degli attributi chiave di E. Se nella progettazione
concettuale sono state definite più chiavi per E, le informazioni che descrivono gli attributi che
formano ogni ulteriore chiave vengono mantenute al fine di specificare le chiavi secondarie di R.
Nel progetto in esame, sono state identificate sette relazioni: Distretto_Venatorio, Riserve_di
Caccia, Cacciatore, Provincia, Azienda, Comune e uno schema di Territorio . La Figura 3-1 illustra
le relazioni con i propri attributi.
Figura 3-17: Le sette relazioni con i propri attributi.
19
Dallo schema concettuale ci accorgiamo che l’entità spaziale Azienda, l’entità spaziale
Riserve_di_Caccia e l’entità spaziale Comune vengono specializzate mediante una specializzazione
totale disgiunta. In questo caso l’algoritmo di traduzione inserirà nell’entità padre un attributo type,
che indicherà la sottoclasse a cui appartiene ciascuna tupla, solo se essa è specificata.
La Figura 3-2 indica le tre relazione con l’attributo type che indica il tipo di specializzazione.
Figura 3-18: La traduzione della specializzazione totale e disgiunta usando l'attributo type.
Dalla Figura 2-13 ci accorgiamo che esiste una relazione uno-a-molti tra l’entità Cacciatore e
l’entità spaziale Comune, chiamata risiede. L’algoritmo del tool traduce questa relazione inserendo
nella tabella Cacciatore l’attributo DenominazionerisiedeComune che sarà successivamente una
chiave esterna della relazione Comune. Allo stesso modo ci accorgiamo che tra l’entità Cacciatore e
l’entità spaziale Riserve_di_Caccia esiste una relazione caccia di tipo uno-a-molti, come in Figura
2-14. Come nel caso precedente, l’algoritmo traduce la relazione inserendo nella tabella Cacciatore
l’attributo Cod_RiservacacciaRiserve_di_Caccia che sarà successivamente una chiave esterna della
relazione Riserve_di_Caccia. La Figura 3-3 ne mostra il risultato della traduzione.
Figura 3-19: La nuova relazione Cacciatore
20
Dalla Figura 2-5 vediamo che esiste una relazione topologica di tipo contains con cardinalità uno-amolti tra l’entità spaziale Azienda e l’entità spaziale Riserve_di_Caccia. In questo caso il tool
traduce
la
relazione
inserendo
nella
tabella
Azienda
l’attributo
Cod_RiservaincludeRiserva_di_Caccia che sarà una chiave esterna della tabella Riserve_di_Caccia.
La relazione include ha anche una attributo ScadConcessione che nel processo di traduzione sarà
inserito nella tabella Azienda.
La Figura 3-4 mostra la nuova tabella Azienda dopo aver eseguito questo nuovo passo di
traduzione.
Figura 3-20: La nuova tabella Azienda
La traduzione continua prendendo in esame le tre relazioni esistenti tra le sottoclassi dell’entità
spaziale Comune e le sottoclassi dell’entità spaziale Riserve_di_Caccia. La prima relazione è tra la
sottoclasse Comune_standard che è in relazione topologica di tipo equals con la sottoclasse
Riserva_standard, come in Figura 2-10. Questa relazione è di tipo uno-a-uno e l’algoritmo di
traduzione inserisce nella tabella Comune l’attributo CodRiservacorrisponde_aRiserva_standard
che sarà una chiave esterna della tabella Riserve_di_Caccia. La seconda relazione è tra la
sottoclasse Comune sottoriserva che è in relazione topologica di tipo contains con la sottoclasse
Riserva multicomune. Questa è una relazione di tipo uno-a-molti e l’algoritmo di traduzione
inserisce nella tabella Comune l’attributo Cod_RiservacontieneRiserva_multicomune che sarà una
chiave esterna della tabella Riserve_di_Caccia. La Figura 3-5 mostra la nuova tabella Comune,
dopo la traduzione di queste due relazioni.
Figura 3-21: La nuova tabella Comune
La terza relazione è tra Comune multiriserva che è in relazione topologica di tipo contains con
Riserva sottocomune, come in Figura 2-11. Questa è una relazione di tipo molti-a-uno e l’algoritmo
di traduzione inserisce nella tabella Riserve_di_Caccia l’attributo
Denominazioneè_situata_inComune_multiriserva che sarà una chiave esterna della tabella Comune.
21
La Figura 3-6 mostra la nuova tabella Riserve_di_Caccia dopo la traduzione di quest’ultima
relazione.
Figura 3-22: La nuova tabella Riserve_di_Caccia
Dalla Figura 2-2 ci accorgiamo che esiste una relazione di aggregazione spaziale tra l’entità spaziale
Provincia e l’entità spaziale Comune. In questo caso l’algoritmo di traduzione traduce questa
relazione inserendo nella tabella Comune l’attributo Prv_Cod2Provincia che sarà una chiave
esterna dell’entità spaziale Provincia. La Figura 3-7 mostra la nuova tabella Comune.
Figura 3-23: La nuova tabella di Comune
Allo stesso tempo esiste un’altra relazione di aggregazione spaziale tra l’entità spaziale
Distretto_Venatorio e l’entità spaziale Riserve_di_Caccia, come in Figura 2-4. In questo caso
l’algoritmo di traduzione inserisce nella tabella Riserve_di_Caccia due nuovi attributi,
CodiceDistretto0Distretto_Venatorio e CodiceDistretto0Distretto_Venatorio, che saranno due
chiavi esterne della tabella Distretto_Venatorio.
La Figura 3-8 mostra la nuova tabella Riserve_di_Caccia.
Figura 3-24: La nuova tabella Riserve_di_Caccia
Fino adesso abbiamo parlato di entità spaziale senza mai far riferimento a come l’algoritmo di
traduzione del tool ChronoGeoGraph traduce una simile entità. Il metodo usato è quello di
22
aggiungere ad ogni entità di tipo spaziale l’attributo geometry, indispensabile per inserire
successivamente il dato spaziale.
La Figura 3-9 mostra lo schema logico finale.
Figura 3-25: Lo schema logico finale
23
4. Creazione ed Istanziazione della BD Oracle
Dopo aver completato la fase di progettazione logica, possiamo adesso passare alla fase di
implementazione della base di dati. Di solito questo compito spetta al DBA che grazie ad istruzioni
SQL, compila e crea gli schemi e i file (vuoti) della base di dati. In seguito, il database può essere
poi riempito con i dati.
Prima di compilare ed eseguire le istruzioni SQL necessarie alla creazione delle nostre tabelle,
abbiamo bisogno di recuperare dei dati, soprattutto quelli spaziali, memorizzati in altre due basi di
dati di tipo Access, LimitiRegionali.mdb e SAGFV_V.mdb. Per far questo, è necessario utilizzare un
tool che ci dà la possibilità di connetterci ai nostri database e di esportare i dati nel modello Oracle.
Il tool che abbiamo utilizzato è GeoMedia Professional 5.2 [5] che appunto permette di connettersi
a database esistenti, di mostrare i dati e di interrogarli.
Prima di spiegare come avviene la connessione e la visualizzazione dei dati, è necessario definire
che cosa si intende per feature e feature class. Una feature è un’entità geografica rappresentata su
una mappa da una geometria e definita da attributi alfanumerici, mentre una feature class è la
classificazione alla quale è assegnata ogni istanza di feature. Ritornando ai nostri dati, le feature
class sono i Comuni, le Province, le Riserve_di_Caccia, la Regione e i Distretti_Venatori, mentre
Udine è una feature della feature class Comuni e Province, la Carnia è una feature della feature
class Distretti_Venatori, ecc..
Adesso spiegheremo come connettersi al database LimitiRegionali.mdb e come esaminare i dati.
Per connettersi ad un database, è necessario eseguire i seguenti passi:
1. Selezioniamo Warehouse dal menu e successivamente New Connection
Questo ci mostra i diversi warehouse ai quali è possibile connettersi
2. Selezioniamo Access e premiamo Next
3. Premiamo Browse per scegliere il database voluto
4. Selezioniamo LimitiRegionali.mdb e premiamo Apri
5. Premiamo Next
6. Selezioniamo l’opzione Access all feature in the warehouse e premiamo Next
7. Selezioniamo l’opzione Let the wizard open the connection as read-only
8. Selezioniamo Fine
24
A questo punto siamo connessi al database scelto ed ora possiamo aggiunge le nostre feature class
per esaminare i dati. Per fare ciò, dobbiamo effettuare i seguenti passi:
1. Selezioniamo Legend dal menu e successivamente clicchiamo su Add Feature Class
Questo aprirà una finestra di dialogo contenete la lista delle feature class presenti nel nostro
database
2. Selezioniamo quale feature class vogliamo visualizzare
3. Premiamo il pulsante OK
Questo aggiungerà la voce scelta nella legenda e l’entità geografica verrà visualizzata nella
map window.
Allo stesso modo possiamo connetterci ad un altro database e visualizzare nella stessa map window
feature class appartenenti a database diversi.
Adesso siamo pronti ad esportare nel modello Oracle i dati presenti nella map window compiendo i
seguenti passi:
1. Selezioniamo Warehouse dal menu e successivamente selezioniamo da sottomenu Export
to l’opzione Oracle Object Model. Questo aprirà una finestra di dialogo con la lista delle
feature class salvate nel database a cui siamo connessi
2. Selezioniamo la feature class che vogliamo esportare
3. Premiamo Browse per scegliere la cartella dove vogliamo che i file esportati siano salvati
4. Selezioniamo o deselezioniamo l’opzione Export 3D coordinates
5. Premiamo Apply
Alla fine, la cartella di esportazione conterrà, per ogni feature class esportata, i file:
•
FeatureClassName.pre: è il file che contiene le istruzioni SQL necessarie per creare la
tabella
•
FeatureClassName.ctl: è il file di controllo per il caricamento dei dati
•
FeatureClassName.dat: è il file di dati
•
FeatureClassName.pos: è il file che popola la tabella dei metadati di Oracle
•
Import.bat: è il file che contiene tutti i file descritti precedentemente
•
Export.log: è il file che memorizza o la causa di un fallimento o il numero di valori per
ogni tabella esportata
25
Prima di importare i dati creati dall’Export to Oracle Object, è necessario creare lo schema
GDOSYS. Per creare questo schema, dobbiamo eseguire lo script CreateGDOSYS.sql che di solito
si trova nella cartella GeoMediaProfessional\Program. Affinché l’esecuzione di questo script vada
a buon fine, dobbiamo definire alcuni parametri importanti. Per fare ciò, o ci posizioniamo
all’interno dello script alla riga di definizione dei parametri e modifichiamo quelli originali con
quelli da noi definiti, come in Figura 4-1, oppure li possiamo passare come un solo parametro.
DEFINE
gserver =&1
DEFINE gpassword =&2
DEFINE gprofile
=&3
DEFINE gserver = localhost
DEFINE gpassword = ********
DEFINE gprofile = GDOSYS
DEFINE userspace =&4
DEFINE userspace = USER
DEFINE tempspace =&5
DEFINE tempspace = TEMP
Figura 4-26: La definizione dei parametri
Se optiamo per la seconda scelta, sarà sufficiente usare la seguente sintassi:
@CreateGDOSYS <NET_SERVICE> <GDOSYS_PSWD> <ORA_PROFILE>
<USER_TABLESPACE> <TEMP_TABLESPACE>
dove
•
<NET_SERVICE> è il nome usato per il servizio Oracle
•
<GDOSYS_PSWD> è la password da usare per l’utente GDOSYS
•
<ORA_PROFILE> è il profilo da usare quando si crea l’account dell’utente
•
<USER_TABLESPACE> è il tablespace dove sarà creato lo schema
•
<TEMP_TABLESPACE> è il temporary tablespace da usare
Quindi, per esempio:
@CreateGDOSYS LOCALHOST ******** GDOSYS USER TEMP
L’esecuzione di questo script produrrà la creazione di un nuovo utente, GDOSYS, con tabelle,
view, trigger e sequence.
Per ulteriori informazioni e chiarimenti su ciò che crea questo script, si rimanda sia al manuale di
GeoMedia Professional che alle connessione con Oracle [5,6].
A questo punto possiamo mandare in esecuzione sia lo script FeatureClassName.pre che lo script
FeatureClassName.pos. Successivamente possiamo popolare le tabelle appena create con i valori
26
memorizzati nel file Import.bat. Per eseguire questo file, dobbiamo aprire la finestra del prompt
dei comandi, posizionarci sulla cartella dove si trova il file e scrivere la seguente istruzione:
IMPORT GDOSYS/LOGO@LOCALHOST
A questo punto, creiamo le nostre personali tabelle prodotte nella fase di progettazione logica
dentro l’utente GDOSYS.
Il passo successivo è quello di popolare le nostre ultime tabelle create con i dati già memorizzati.
Per far questo, è necessario una semplice istruzione SQL che inserisce in una tabella, dei dati che
provengono da altre tabelle. Per spiegare meglio, facciamo un esempio di inserimento dati dalla
tabella Distretti_Venatori alla tabella da noi creata, chiamata Distretto_VenatorioMIO:
INSERT INTO DISTRETTO_VENATORIOMIO(CODICEDISTRETTO,GEOMETRY,DENOMINAZIONE)
SELECT CODICEDISTRETTO,SPATIALAREA,DENOMINAZIONE
FROM DISTRETTI_VENATORI;
Riusando questa istruzione, con le necessarie modifiche, siamo in grado di popolare tutte le tabelle.
27
5. Visualizzazione dei dati con GeoServer
GeoServer [7] prevede uno GeoSpatial Web, come WWW, dove l’utente può cercare e scaricare
dati, o semplicemente può cercare o leggere dati spaziali sul web. I dati possono essere pubblicati
sul web e gli utenti possono accedere ad essi senza sapere chi è il fornitore di questi dati.
Quando il progetto GeoServer ebbe inizio, l’OpenGis Consortium stava lavorando sullo standard
Web Feature Service (WFS). Questo standard specifica un protocollo per rendere i dati disponibili
sul web. WFS dà la possibilità all’utente di decidere che cosa fare dei dati o, se è necessario, fare un
qualche tipo di analisi prima della loro visualizzazione. Questo standard utilizza il formato dati
GML (Geographic Markup Language), un linguaggio basato su XML, che dà una chiara struttura su
come i dati sono formati e descritti. Mentre si lavorava al progetto GeoServer, nasceva e si
sviluppava il lavoro su PostGis, un database open source, che alla fine diventerà il primo database
spaziale su cui correrà la prima release di GeoServer. Con il passare del tempo, il progetto
GeoServer diventa cosi importante e conosciuto a livello mondiale, che i maggiori sistemi
commerciali di database, come Oracle, Db2 e successivamente MySql, richiesero che GeoServer
funzionasse anche con i loro sistemi.
Successivamente si sviluppò lo standard Web Map Service (WMS). Questo standard si occupa
principalmente di fornire all’utente, una picture di una mappa. È importante sottolineare che, in una
WMS, l’utente ha una limitata interattività con la mappa a differenza di una WFS, dove l’utente
interagisce e personalizza i dati che vuole visualizzare.
Per visualizzare i dati memorizzati nella nostra base di dati, utilizzeremo la nuova versione di
GeoServer, GeoServer 1.7.0.
Per installare e configurare il tool con il database Oracle, si rimanda alla relazione di Paolo Gallo
[7].
1.6
Alcune Implementazioni
Questo paragrafo illustrerà dettagliatamente come costruire una WMS con la libreria OpenLayers.
La libreria può essere scaricata dal sito www.openlayers.org o utilizzare una sua copia che si trova
già su GeoServer. Per utilizzare la libreria è necessario inserire un’istruzione javascript nel modulo
head del file html che andremo a costruire. L’istruzione utilizzata è la seguente:
<script src=http://localhost:8080/geoserver/openlayers/OpenLayers.js></script>
28
Questa istruzione dice al browser dove si trova il file javascript su cui corre OpenLayers.
Successivamente, la prima cosa da fare è dire ad OpenLayers quali layer vogliamo caricare e
visualizzare. Prima di far ciò, è necessario definire la mappa su cui andremo a caricare i nostri layer.
L’istruzione che utilizzeremo è la seguente:
var map = OpenLayers.Layer(‘map’);
Questa istruzione dice ad OpenLayers di costruire una nuova mappa e questa sarà il posto dove i
nostri layer saranno caricati.
Per
definire
un
layer
dobbiamo
modificare
la
sezione
che
definisce
l’oggetto
OpenLayers.Layer.WMS. OpenLayers.Layer.WMS prende i seguenti argomenti:
-
name : il nome del layer
-
url: l’indirizzo dove si trova il nostro layer
-
params: i parametri necessari al programma per lavorare
-
options: opzioni di visualizzazione del layer
I due pezzetti di codice che definiscono i due nuovi layer e le opzioni che può prendere
OpenLayers.Layer.WMS sono:
var distretto_wms = new OpenLayers.Layer.WMS( "topp:DISTRETTO_VENATORIONEW",
"http://localhost:8080/geoserver/wms",
{layers: 'topp:DISTRETTO_VENATORIONEW',
srs:'EPSG:4326',
format: "image/png" }, {singleTile:true, ratio:1});
var riserve_wms= new OpenLayers.Layer.WMS("topp:RISERVE_DI_CACCIANEW",
"http://localhost:8080/geoserver/wms",
{layers:'topp:RISERVE_DI_CACCIANEW',
srs:'EPSG:4326',
format: "image/png" },{'isBaseLayer': false});
OpenLayers assume che i layer WMS sono tutti layer di base. Questo è un problema se noi
vogliamo vedere i diversi layer uno alla volta e cosi sarà necessario aggiungere l’opzione
isBaseLayer:false a quel layer che sarà visualizzato sopra il layer di base.
A questo punto dobbiamo aggiungere i due layer sopra la mappa e per fare questo utilizzeremo la
seguente istruzione
map.addLayers([distretto_wms,riserve_wms]);
29
Quello che sarà visualizzato all’apertura del file è mostrato nella Figura 5-1. Questa figura ci mostra
come si dispongono nel territorio i 15 Distretti Venatori individuati e decisi dall’Amministrazione
Regionale del Friuli Venezia Giulia.
Figura 5-27: La mappa dei Distretti Venatori
Cliccando adesso sul pulsante +, è possibile visualizzare il layer riguardante le Riserve di Caccia.
La Figura 5.2 mostra il layer Riserve di Caccia sopra al layer Distretto Venatorio.
Figura 5-28: La mappa delle Riserve sopra la mappa dei Distretti
30
Quello che adesso vogliamo fare è ottenere informazione cliccando sulla mappa visualizzata.
Questo lo possiamo fare utilizzando il seguente pezzo di codice:
// support GetFeatureInfo
map.events.register("click", map, function(e) {
document.getElementById('nodelist').innerHTML = "Loading... please wait...";
var url = map.layers[0].getFullRequestString(
{
REQUEST: "GetFeatureInfo",
EXCEPTIONS: "application/vnd.ogc.se_xml",
BBOX: map.getExtent().toBBOX(),
X: e.xy.x,
Y: e.xy.y,
INFO_FORMAT: 'text/html',
QUERY_LAYERS: map.layers[0].params.LAYERS,
FEATURE_COUNT:1,
WIDTH: map.size.w,
HEIGHT: map.size.h
}, "http://localhost:8080/geoserver/wms"
);
OpenLayers.loadURL(url, '', this, setHTML, setHTML);
Questo “register” registra la funzione che viene chiamata quando avviene un click, cioè quando
l’utente clicca sulla mappa. Per prima cosa, la funzione cambia l’inneHTML del nodelist a
“Loading…Please wait…” in modo da dare al’utente l’impressione che si sta facendo qualcosa.
Successivamente viene costruito un nuovo URL basato sull’URL di uno dei nostri layer.
Quando si definisce la richiesta “GetFeatureInfo”, è indispensabile settare alcuni parametri
importanti come il BBOX, che definisce l’estensione corrente della mappa, il width e l’height, per
definire la dimensione della mappa. Successivamente, aggiungiamo in X eY la posizione del click
del mouse, il layer richiesto e l’INFO_FORMAT.
Finalmente, con la chiamata alla funzione loadURL, inizia la richiesta al server e questa chiamata ci
dice che è indispensabile una funzione setHTML per maneggiare il risultato dell’URL. Quindi
quello che noi abbiamo, è una funzione setHTML che faccia qualcosa quando ritorna il risultato dal
server.
In cima al file, inseriamo il seguente pezzettino di codice:
31
function setHTML(response) {
document.getElementById('nodelist').innerHTML = response.responseText;
};
Questa funzione si prende la risposta del server e copia il testo nell’elemento nodelist del
documento HTML. A questo punto salviamo il file e lo carichiamo nel browser Internet Explorer 7.
Se si usa questa versione di GeoServer, il browser Mozilla Firefox versione 3.0.0 e successive è in
grado di visualizzare la mappa ma non di interrogarla. Quindi, dopo averla caricata su Internet
Explorer 7, proviamo a vedere se funziona quando clicchiamo su una feature. Per esempio,
clicchiamo su un qualche distretto, come evidenziato dal puntino rosso della Figura 5-1.
Dopo un momento di attesa, la risposta che ci viene restituita è uguale quella della Figura 5-3.
Figura 5-29: La risposta del server su un Distretto
Se adesso clicchiamo su una qualsiasi Riserva di Caccia, come evidenziato dal puntino rosso della
Figura 5-2, la risposta che ci viene restituita è uguale a quella della figura 5-4.
Figura 5-30: La risposta del server su una Riserva
32
Un altro esempio di implementazione è dato dal layer di base FVG e dall’overlay Riserve di Caccia.
Per definire questo esempio, è necessario eseguire gli stessi passi fatti precedentemente cambiando
soltanto l’istruzione che indica la definizione dei layer.
Se noi clicchiamo sul primo layer, come evidenziato dal puntino rosso della Figura 5-5, la risposta
che ci viene restituita è come quella della Figura 5-6.
Figura 5-31: La Regione Friuli Venezia Giulia
Figura 5-32: La risposta del server sulla Mappa Regionale
A questo punto possiamo cliccare sul pulsante +, in alto a destra, e possiamo selezionare l’overlay
Riserve di Caccia, ottenendo la Figura 5-7.
33
Figura 5-33: L'overlay Riserve di Caccia
Anche in questo caso, cliccando sul puntino rosso, come evidenziato nella Figura 5-7, possiamo
ottenere le seguenti informazioni, Figura 5-8.
Figura 5-34: La risposta del server su una data Riserva
34
L’ultimo esempio è quello di un layer di base Provincia con due overlays Distretto e Riserve. Per
ottenere questo esempio basta aggiungere all’esempio precedente un nuovo overlay.
Al caricamento del file, la mappa che ci viene visualizzata è quella Figura 5-9.
Figura 5-35: Le Province del Friuli Venezia Giulia
Cliccando sul puntino rosso, come mostrato nella Figura 5-9, la risposta restituita dal server è come
quella della Figura 5-10.
Figura 5-36: La risposta sulla Provincia cliccata
Adesso aggiungiamo il layer Distretto e quello che andremo a visualizzare è quello mostrato in
Figura 5-11.
35
Figura 5-37: L'overlay Distretto
Allo stesso modo, cliccando sul puntino rosso della Figura 5-11, la risposta che verrà restituita dal
server è quella mostrata nella Figura 5-12.
Figura 5-38: La risposta del server dopo il click
Allo stesso modo possiamo aggiungere il layer Riserve e togliere il layer Distretto e così la mappa
che ci viene visualizzata è come quella della Figura 5-13.
36
Figura 5-39: L'overlay Riserve di Caccia
Anche in questo caso cliccando sul puntino rosso, come mostrato nella Figura 5-13, la risposta che
giunge dal server è uguale a quella della Figura 5-14.
Figura 5-40: La risposta del server al click
37
In questa nuova versione, è stato aggiunto un toolbar, capace di eseguire, in modalità WMS,
semplici interrogazioni di Filter, generando nella mappa il risultato della richiesta.
Proviamo adesso ad eseguire qualche interrogazione con questo nuovo strumento. Carichiamo sul
brower una mappa, nel nostro caso WMS COMUNENEW, Figura 5-15, e cliccando sul pulsante
rosso si apre la finestra come in Figura 5-16.
Figura 5-41: Il pulsante per il toolbar nella WMS Comune
Figura 5-42: L'interrogazione con CQL Filter
38
La prima interrogazione sarà quella di ricercare i Comuni con un numero di residenti minore di 700.
Prima di eseguire questa interrogazione, dobbiamo scegliere il giusto Filter.
I FILTER che possiamo utilizzare, sono tre: CQL, OGC e FeatureId. Il primo filtro, CQL Filter,
permette di selezionare le feature che soddisfano particolari vincoli sui dati e, in sostanza, questo
filtro risponde alla traduzione dell’istruzione SQL WHERE. Il secondo filtro, OGC Filter, è un open
standard, proposto dall’Open Geospatial Consortium, e per utilizzarlo è sufficiente leggerne le
specifiche. Quando le interrogazioni diventano più complesse, l’uso del OGC Filter fa perdere
molta comprensibilità e per ovviare a questo problema, si usa il CQL Filter. Il terzo e ultimo filtro è
il FeatureID che permette di selezionare una singola feature fornendo il suo id.
Scegliamo il filtro CQL e nell’apposita casella, possiamo inserire la nostra interrogazione,
NUMRESIDENTI < 700.
La risposta sarà come quella della Figura 5-17.
Figura 5-43: I Comuni con NUMRESIDENTI < 700
Per ottenere informazioni sui Comuni visualizzati sulla mappa, è necessario cliccare su uno di esso.
La seconda interrogazione sarà quella di recuperare tutte le feature dei Comuni contenute in un dato
bounding box. Per effettuare questa richiesta, è necessario inserire nell’apposita casella questa
istruzione:
39
BBOX(GEOMETRY,23558386611.87773,512812636.59414,235609810.62070,514803741.05076)
La risposta sarà come quella della Figura 5-18.
Figura 5-44: I Comuni in un dato Bounding Box
Anche in questo caso, possiamo ottenere le informazioni cui Comuni cliccando uno di essi.
La terza interrogazione sarà quella di richiedere i soli Distretti Venatori il cui numero di soci è tra
300 e 500. Dopo aver caricato la mappa WMS DISTRETTO_VENATORIONEW e inserito
l’istruzione MAXSOCI BETWEEN 300 AND 500, la risposta restituita dal server è uguale a quella
della Figura 5-19.
40
Figura 5-45: I Distretti con MAXSOCI tra 300 e 500
Anche in questo caso, per ottenere informazioni sui Distretti, è necessario cliccare su uno di essi.
La quarta e ultima interrogazione sarà quella di richiedere i Distretti il cui numero di soci è tra 300 e
500 e che sono contenute in un dato bounding box. Per questa interrogazione è necessario inserire
l’istruzione
BBOX(GEOMETRY,23558386611.87773,512812636.59414,235609810.62070,514803741.05076)
AND MAXSOCI BETWEEN 300 AND 500
La risposta ottenuta è uguale a quella della Figura 5-20.
Figura 5-46: I Distretti ottenuti dopo aver eseguito l'interrogazione
Anche in questo caso, per ottenere informazioni è necessario cliccare sulla feature restituita dal
server.
41
Bibliografia
[1] Piano Faunistico Regionale, allegato alla DGR 26.06.2008, n.1264.
[2] Legge Regionale n.06/2008, Disposizioni per la programmazione faunistica e per
l’esercizio dell’attività venatoria.
[3] Legge Regionale n.30 del 31 dicembre 1999, Gestione ed esercizio dell’attività venatoria
nella Regione Friuli-Venezia Giulia.
[4] Tesi di Laurea, UNO STRUMENTO PER LA PROGETTAZIONE CONCETTUALE DI
SISTEMI INFORMATIVI GEOGRAFICI, Alberto Frappa.
[5] Manuale di GeoMedia Professional 5.2, WORKING with GeoMedia Professional.
[6] Come connettersi a Oracle da GeoMedia, Using Oracle Connections.
[7] Introduzione a GeoServer, Una soluzione per GIS open-source, Paolo Gallo.
Siti consultati
-
Friuli Venezia Giulia:
http://www.regione.fvg.it
-
Caccia nel Friuli Venezia Giulia:
http://www.caccia.fvg.it
-
Comuni Italiani
http://www.comuni-italiani.it
-
Prodotto software GeoMedia Professional:
http://imgs.intergraph.com
-
Oracle:
http://www.oracle.com
-
Java, per l’ultimo SUN JDK, qualora non fosse già installato:
http://java.sun.com
-
GeoServer:
http://www.geoserver.org
-
OpenLayers:
http://www.openlayers.org
42
-
OGC, Open Geospatial Consortium:
http://www.opengeospatial.org
-
OGC WMS Specification:
http://portal.opengeospatial.org/files/?artifact_id=14416
-
OGC WFS Specification:
https://portal.opengeospatial.org/files/?artifact_id=7176
43