icad-geo. studio di fattibilità per la realizzazione di un progetto per la

Transcript

Data emissione: 19 giugno 2008
Codice: CI08-02-1.1
ICAD-GEO. STUDIO DI FATTIBILITÀ PER LA
REALIZZAZIONE DI UN PROGETTO PER LA
REALIZZAZIONE DI UNA “INFRASTRUTTURA
PER LA COOPERAZIONE APPLICATIVA DEI DATI
GEOGRAFICI”
Convenzione tra il Centro Interregionale di coordinamento e documentazione per le
informazioni territoriali e il Dipartimento di Rappresentazione dell'Università degli
Studi di Palermo
Progetto di ricerca del Centro Interregionale di Coordinamento e documentazione per le
informazioni territoriali - Area di approfondimento 4
Responsabile del progetto: Prof. Benedetto Villa (Direttore DIRAP-UNIPA)
Gruppo di ricerca:
1. Università degli Studi di Palermo - Dip.to di Rappresentazione (coordinamento)
- Ing. Andrea Scianna;
- Ing. Alessio Ammoscato;
- Dott. in Pianificazione Fabrizio Niceta.
2. Politecnico di Milano, Polo di Como - Dip.to DIIAR
- Prof. Maria Antonia Brovelli;
- Ing. Marco Negretti;
- Ing. Gianni Leggio;
- Ing. Michele Beretta;
- Ing. Fabio Tagliabue.
3.Università degli Studi di Cagliari - Dipartimento di Ingegneria Strutturale, Sezione di
Topografia
- Ing. Giuseppina Vacca;
- Ing. Antonio Pala;
- Ing. Riccardo Porru.
Responsabili per il Centro Interregionale di Coordinamento e documentazione per le
informazioni territoriali:
- Ing. Domenico Longhi;
- Arch. Luigi Garretti.Arch. Luigi Garretti
Progetto di ricerca del Centro Interregionale di Coordinamento e documentazione per le informazioni territoriali
Gruppo di lavoro Lotto 4: “Studio di fattibilità di infrastruttura per la cooperazione applicativa di dati geografici”
Repertorio delle tecnologie disponibili per la realizzazione di SDI
Nome file: report2.odt
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 2 di 193
Titolo documento
Autore
Data
Soggetto
Editore
Tipo
Descrizione
Contributi
Formato
Riferimento
Identificatore
Lingua
Relazioni
Estensione temporale
Estensione spaziale
Repertorio delle tecnologie disponibili per la realizzazione di
SDI
Gruppo di lavoro 4 “ ICAD-GEO Studio di Fattibilità per la
realizzazione di un progetto per la realizzazione di una
"Infrastruttura per la Cooperazione Applicativa dei Dati
Geografici ”
(Lotto 4 del Progetto di ricerca del Centro Interregionale di
Coordinamento e documentazione per le informazioni
territoriali)
19 giugno 2008
Applicazioni GIS e WEB-GIS
Centro Interregionale di Coordinamento e documentazione
per le informazioni territoriali
Testo
Il documento descrive le applicazioni software e le relative
tecnologie disponibili per la realizzazione di infrastrutture dati
geografiche
Openoffice .ODT
report2
Italiano
10 mesi
Italia
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 3 di 193
Indice generale
STANDARD METADATI.......................................................................................................18
Standard CNIPA...................................................................................................................19
Standard Dublin Core............................................................................................................27
Standard di metadati adottati da GeoNetwork......................................................................28
Corrispondenze tra gli standard di Geonetwok, CNIPA e Dublin Core...............................39
Reference System Info..........................................................................................................46
Data Quality Info..................................................................................................................47
Spatial Representation Info...................................................................................................50
RNDT - Repertorio Nazionale dei Dati Territoriali..................................................................52
Introduzione..........................................................................................................................53
Aspetti tecnologici................................................................................................................53
Standard Metadati adottato...................................................................................................54
Struttura gerarchica del metadato.........................................................................................54
Procedura di popolamento dell'archivio................................................................................55
Accesso e interrogazione dei dati..........................................................................................59
GEOSERVER E DEEGREE....................................................................................................64
GeoServer: caratteristiche generali.......................................................................................65
GeoServer, protocollo WFS..................................................................................................70
Geoserver, protocollo WCS..................................................................................................79
Geoserver, protocollo WMS.................................................................................................84
Sviluppi futuri.......................................................................................................................95
Deegree: caratteristiche generali...........................................................................................95
Architettura di Deegree.........................................................................................................97
Accesso ai dati......................................................................................................................98
MAPSERVER.........................................................................................................................102
Introduzione........................................................................................................................103
Funzionamento....................................................................................................................110
Il Template file....................................................................................................................112
Il Mapfile.............................................................................................................................114
Implementazione dello standard WMS in MapServer........................................................116
Implementazione dello standard WFS in MapServer.........................................................116
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 4 di 193
Implementazione dello standard WCS in MapServer.........................................................117
Chameleon..........................................................................................................................118
Appendice 1: software conformi allo standard WMS 1.3...................................................121
GEODATABASE...................................................................................................................124
Introduzione........................................................................................................................125
POSTGIS............................................................................................................................127
Import/export delle feature..................................................................................................131
Funzioni di Postgis..............................................................................................................135
ORACLE SPATIAL...........................................................................................................136
Geometrie spaziali (shape)..................................................................................................137
Importazione dei dati .........................................................................................................143
Esportazione dati.................................................................................................................150
Operazioni spaziali in Oracle..............................................................................................151
Spatial operator...................................................................................................................151
Spatial aggregate function...................................................................................................153
Georaster Spatial.................................................................................................................155
Tabella riassuntiva di confronto tra PostGIS e ORACLE SPATIAL.................................162
ArcSDE...............................................................................................................................165
Comparazioni riassuntive....................................................................................................178
GEONETWORK....................................................................................................................184
Introduzione........................................................................................................................185
Modalità di Ricerca.............................................................................................................186
Analisi dei risultati..............................................................................................................187
Visualizzazione dei risultati................................................................................................188
Aggiornamento dell'archivio...............................................................................................188
Ruolo di amministratore......................................................................................................192
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 5 di 193
ICAD-GEO. STUDIO DI FATTIBILITÀ PER LA REALIZZAZIONE DI
UN PROGETTO PER LA REALIZZAZIONE DI UNA
“INFRASTRUTTURA PER LA COOPERAZIONE APPLICATIVA DEI
DATI GEOGRAFICI”
A seguito della stipula di CONVENZIONE tra il Centro INTERREGIONALE DI
COORDINAMENTO
E
DOCUMENTAZIONE
PER
LE
INFORMAZIONI
TERRITORIALI e il DIPARTIMENTO di RAPPRESENTAZIONE dell’UNIVERSITÀ di
PALERMO veniva avviata la prima fase delle attività previste nel programma dei
lavori trasmesso con nota del 1 ottobre 2007 allo stesso Centro Interregionale.
Le attività di ricerca sono state condotte da un gruppo costituito dalle seguenti tre
unità:
Gruppo di ricerca:
1. Università degli Studi di Palermo - Dip.to di Rappresentazione (coordinamento)
- Ing. Andrea Scianna;
- Ing. Alessio Ammoscato;
- Dott. in Pianificazione Fabrizio Niceta.
2. Politecnico di Milano, Polo di Como - Dip.to DIIAR
- Prof. Maria Antonia Brovelli;
- Ing. Marco Negretti;
- Ing. Gianni Leggio;
- Ing. Michele Beretta;
- Ing. Fabio Tagliabue.
3.Università degli Studi di Cagliari - Dipartimento di Ingegneria Strutturale, Sezione di
Topografia
- Ing. Giuseppina Vacca;
- Ing. Antonio Pala;
- Ing. Riccardo Porru.
Tale programma, articolato in 6 fasi, prevedeva in particolare:
Fase 1 - Studio dei progetti sviluppati in ambiti nazionale e/o regionali di EGovernment e/o Governance territoriale come ICAR, Sigmater, SITAD, InterGeo,
Pr5CIPE, Apulie, SICS, TopoCore;
Fase 2 - Individuazione delle tecnologie free e open source più appropriate per la
gestione e l’elaborazione delle informazioni territoriali, nel rispetto delle esigenze di
riuso delle infrastrutture esistenti; la fase comprende anche un'analisi delle criticità
relative alla gestione dei diversi tipi di dati geografici con i gestori di database spaziali
(sia già utilizzati nei progetti di cui alla fase 1 che Open Source);
Fase 3 - Definizione di uno stack tecnologico “Open Source” per la gestione e la
pubblicazione dei Dati Geografici e dei Data Base Topografici; in quest'ambito
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 6 di 193
verranno individuati e/o definiti i geoservizi fondamentali per la gestione dei dati
geografici compatibili con le specifiche OGC e la direttiva INSPIRE;
Fase 4 - Definizione di una Piattaforma di Cooperazione Applicativa in ambito
geografico e geo-topografico tale da integrare infrastrutture, tecnologie, modelli
organizzativi specifici ed informazioni relative a progetti di portata regionale o
interregionale di cui alla fase 1;
Fase 5 - Definizione di modelli organizzativi per la gestione dell’infrastruttura in
relazione al funzionamento generale degli eventuali modelli proposti;
Fase 6 - Analisi costi/benefici per ciascun modello individuato (economicità) – si
valuterà in particolare l'eventuale convenienza della piattaforma Open Source.
-----------------------------La presente relazione riassume le attività relative alla seconda fase e parte della
terza.
Sono state in particolare prese in esame le diverse piattaforme software – sia
commerciali che free e open source - e le relative tecnologie poste alla base del loro
funzionamento, con la finalità della proposizione di un possibile stack tecnologico
free e open source.
Si fa riferimento ovviamente a tutte quelle che possono essere le componenti di
un'Infrastruttura dati geografica, caratterizzata dalle funzioni di consultazione dei
metadati, di download degli stessi e dei dati ai quali si riferiscono, di consultazione
dei dati geografici tramite applicazione web-gis e dell'attivazione di servizi web per
l'accesso ai dati secondo modalità standardizzate, tali da permettere l'utilizzo dei dati
sia tramite software GIS desktop con funzionalità di accesso ai web-services che
tramite applicazioni web-gis.
La realizzazione dei software presi in considerazione si basa in generale su modelli
standard ISO o OGC, anche se nel processo attuale di standardizzazione
dell'informazione geografica, sono attive alcune altre iniziative a carattere mondiale,
europeo e nazionale tese a definire standard idonei per le diverse realtà geografiche
nel rispetto, anche della normativa vigente nei diversi paesi.
L'applicazione di norme norme straniere come quelle dell'Unione Europea, alla realtà
nazionale,
com'è
noto,
comporta
notevoli
difficoltà
sotto
l'aspetto
dell'armonizzazione. Ciò è dovuto a situazioni normative molto differenti da nazione a
nazione. L'aspetto è ancora più consistente, nello specifico caso dei GIS, dato il
numero dei settori interessati.
Emerge quindi, in modo consistente, il problema dell'applicazione di norme europee
ad una realtà nazionale, in quanto tale processo potrebbe necessariamente portare
alla realizzazione di strutture dati in qualche modo differenti da paese a paese,
limitando l'aspirazione europea di una SDI omnicomprensiva di informazioni
geografiche relative a tutti i paesi dell'unione.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 7 di 193
Difficoltà consistenti sorgerebbero ad esempio nelle modalità di strutturazione
dell'informazione catastale, di quella relativa alla classificazione amministrativa del
territorio o delle strade, così come la struttura del database dei metadati, qualora si
volesse arrivare a modelli dati unificati a livello europeo.
Una forte iniziativa, attualmente in corso, è quella promossa nell'ambito della direttiva
INSPIRE alla quale sono chiamati a contribuire tutti i paesi dell'Unione Europea. La
Direttiva pur essendo specificamente riferita agli aspetti dell'ambiente e del territorio
influenza peraltro altri settori dell'informazione geografica.
Le infrastrutture dati spaziali sono gli strumenti che potrebbero garantire la
coesistenza di strutturazioni diverse relative a temi similari, anche con il possibile
ricorso a thesaurus tematici multilingue ed alle ontologie.
Figura 1 – Componenti software principali di una SDI
In generale l'infrastruttura dati spaziale si base sull'esistenza di alcuni moduli che
assolvono alle diverse funzioni schematizzate nella figura 1 e colloquiano tramite
protocolli specifici.
I diversi moduli interagiscono tramite protocolli di comunicazione, utilizzando
modalità standard di interazione e strutturazione delle informazioni che vengono
trasmesse fra i moduli. Gli aspetti generali della comunicazione e trasferimento di
dati avvengono sulla base di standard informatici generali. Fra questi i più comuni,
utilizzati anche per il settore dell'informazione geografica in rete sono HTTP
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 8 di 193
(Hypertext Transfer Protocol), CORBA (Common Object
Architecture), SOAP, XML (Extensible Markup Language), ecc.
Request
Broker
Il protocollo basilare per l'interscambio di informazioni fra le applicazioni per il WEB è
certamente SOAP (Simple Object Access Protocol). SOAP è un protocollo leggero
basato su XML che permette l'interscambio di messaggi fra componenti software e
tra l'altro nella denominazione del protocollo vi è un esplicito riferimento – Object –
alla programmazione ad oggetto che è quella che dovrebbe permettere un più
efficiente uso del protocollo.
La strutturazione dei dati geografici, l'accesso ad essi e la manutenzione sono
realizzati nel rispetto di norme definite dall'ISO e/o dall'OGC, che, per gli aspetti
generali, fanno riferimento ad alcuni standard del mondo dell'informatica e del mondo
del WEB in particolare.
In effetti buona parte delle applicazioni GIS per il WEB sono ormai scritte in Java o in
C++, linguaggi specificamente nati per la programmazione ad oggetti talvolta in
visual basic, in Python, in PHP(per rendere dinamiche le pagine web, delle
applicazioni WEBGIS nel caso in questione), essendo questi ultimi linguaggi utilizzati
per lo più per la scrittura di macro o piccole applicazioni.
Applicazioni C/C++
Applicazioni Java
GRASS
Geonetwork
QGIS
Geoserver
UNM MapServer
Deegree
Postgres SQL
OpenMap
PostGIS
uDig
AlovMap
Jump
gvSig
Tabella 1 - Applicazioni Open Source in C/C++ e Java
Una prima classificazione dei software, per la gestione in rete dell'informazione
geografica, può quindi essere fatta con riferimento al linguaggio di programmazione
con il quale tali applicazioni sono state scritte (vedasi tabella 1).
Più specificamente, nel mondo open source, esistono delle applicazioni, che coprono
il settore dell'informazione geografica in rete, riportate nella tabella 1 discriminate in
relazione all'appartenenza alle famiglie delle applicazioni C/C++ o Java.
Esistono inoltre alcune altre applicazioni scritte in linguaggi per l'ambiente .NET, in
visual basic, in Python ( es. OWSLib libreria per definizione di WEB services
conformi alle raccomandazioni OGC ).
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 9 di 193
Nella realizzazione delle applicazioni complete gli strumenti di cui prima vengono
integrati (es. alcune applicazioni UNM Map Server sono ulteriormente potenziate
tramite moduli Java) con applicazioni realizzata con altri linguaggi, per cui si hanno
procedure informatiche costituite da moduli C/C++ con ulteriori moduli Java e
funzioni scritte in PHP/Mapscript o Python, ecc. (vedasi tabella 2).
Librerie C/C++
Librerie Java
Proj4
Geotools
GDAL/OGR
Java Map Projection Library (javaproj)
GEOS
Fulcrum
E00compr
JTS Topology Suite
e00pg
Tabella 2 – Librerie più utilizzate per lo sviluppo di applicazioni geografiche
Quello che comunque nella realizzazione della SDI è fondamentale è l'aderenza a
delle specifiche internazionalmente riconosciute, in modo da dar luogo ad
applicazioni costituite da moduli dotati di funzioni in grado di accedere, gestire ed
elaborare i dati per mezzo di protocolli di accesso e comunicazione standard.
Nei capitoli che seguono in relazione a quanto detto sono evidenziate, per i diversi
strumenti, le compatibilità con le modalità standard di comunicazione e accesso
all'informazione geografica.
Dei software riportati nelle tabelle di cui sopra, ne sono stati presi in considerazione
solo alcuni, quelli che sulla base dello studio condotto, risultano i più diffusi,
performanti ed efficienti.
Per quanto riguarda i software tipo WEBGIS e di gestione dei metadati, sono state
prese in considerazione applicazioni del mondo free e Open Source, mentre
relativamente ai software per la gestione dei dati tramite estensioni spaziali, sono
stati presi in considerazione software sia liberi ed open source che commerciali
proprietari.
Questo al fine di permettere il successivo passo di proposizione di uno stack tecnologico open
source e poter redigere una sorta di analisi costi benefici valutando quali funzioni o
caratteristiche sono disponibili e non in relaziona all'adozione di applicazioni open source
e/o commerciali.
Comunque nel settore dell'informazione geografica, sia il mondo delle applicazioni
commerciali proprietarie che il mondo delle applicazioni free e open source,
comprese quelle della rassegna che segue, per moltissimi aspetti, fanno riferimento
alle specifiche dell'Open Geospatial Consortium (OGC), sostenuto con fondi e
persone che operano all'interno delle società produttrici di software commerciale.
Le raccomandazioni più recenti dell'OGC relative ai servizi WEB per l'informazione
geografica includono la definizione di servizi standardizzati per la scoperta
(conoscenza sulla disponibilità dei servizi), l'accesso e la manutenzione sia ai
metadati, che ai dati in formato vettoriale e raster.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 10 di 193
Nella tabella 3 è stata riportata, per i software più comunemente utilizzati a livello
nazionale, la compatibilità con le raccomandazioni OGC.
Produttore
Autodesk, Inc.
Bentley Systems
Inc.
DM Solutions
Group
ESRI
Nome del
prodotto
Autodesk GIS
Design Server 8.x
Autodesk
MapGuide
Enterprise 2007
Autodesk
MapGuide
Enterprise 2007
Autodesk
MapGuide
Enterprise 2008
Autodesk
Topobase 2008
Bentley Map
8.9.4
Chameleon 1.99
- Binary Schema
9.2
ArcExplorer Web
ArcGIS 8.1
ArcGIS Server
9.2
ArcGIS Server
9.3
ArcGIS Server
Enterprise: DB2 Spatial Types and
Functions 9.2
ArcGIS Server
Enterprise:
Informix - Spatial
Types and
Functions 9.2
ArcGIS Server
Enterprise: Oracle
- Binary Schema
9.2
ArcGIS Server
Enterprise: Oracle
- Spatial Types
and Functions 9.2
ArcGIS Server
Enterprise: SQL Binary Schema
9.2
Specifiche OGC
SFS 1.1
WFS 1.0, WMS 1.1.1 (compliant)
WFS 1.0, WMS 1.1.1 (compliant)
WMS 1.1.1, WFS 1.0
Tipo
Server
Server
Server
Server
SFS 1.1
Client e Server
GML 2.1.2, GML 3.1.1, GMLsf 1.0.0, WFS(T)
1.0
WMS 1.1, WMS 1.0, WMC 1.0, WFS 1.0, SLD
1.0, Filter 1.0, WMS 1.1.1
SFS(BG) 1.1 (compliant)
Client
WMC 1.0, WMS 1.0, WMS 1.1, WMS 1.1.1
SFO 1.1 (compliant)
WMS 1.1.1 (compliant)
Client
Client
WFS 1.1, WCS 1.1.1 c1, WCS 1.1.0, WCS 1.0.0,
WCS 1.0, SLD 1.0, SFS(TF) 1.1, SFS(NG) 1.1,
SFS(BG) 1.1, SFS 1.1.0, SFS 1.1, SFO 1.1,
KML 2.2, KML 2.1.0, GMLsf 1.0.0, GML 3.2.1,
GML 3.1.1, Filter 1.1, Filter 1.0, Common 1.1.0,
Common 1.0, WMS 1.0, WMS 1.1, WMS 1.1.1,
WMS 1.3.0
SFS(TF) 1.1 (compliant)
Client
Server
Server
Server
Server
Server
Server
Server
Server
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 11 di 193
ArcGIS Server
Enterprise: SQL Binary Schema
9.2
ArcGIS Server
Enterprise: SQL
Server Express Binary Schema
9.2
ArcGIS Server
Enterprise: SQL
Server Express Binary Schema
9.2
ArcIMS 9.0
ArcIMS 9.0, 9.1
ArcIMS 9.1
ArcIMS 9.1 SP1
ArcIMS 9.2
ArcSDE for DB2
8.1
ArcSDE for DB2
9.0
ArcSDE for DB2
9.1
ArcSDE for
Informix 8.1
ArcSDE for
Informix 9.0
ArcSDE for
Informix 9.1
ArcSDE for
Oracle 9.0
ArcSDE for
Oracle 9.1
ArcSDE for SQL
Server 9.0
ArcSDE for SQL
Server 9.1
ArcWeb Services
2006
GIS Portal
Toolkit 3.1
Spatial Database
Engine for DB2
Datajoiner 3.0.2
Spatial Database
Engine for
Informix 3.0.2
Server
Server
Server
WMS 1.0, WMS 1.1, WMS 1.1.1 (compliant)
OLSCore 1.0, OLSCore 1.1, OLSCore(DS) 1.0,
OLSCore(LUS) 1.0, OLSCore(PS) 1.0,
OLSCore(RS) 1.0
WMS 1.1.1 (compliant), WFS 1.0, SLD 1.0,
GML 3.0, GML 2.1.2, GML 2.1.1, Filter 1.0
Filter 1.0, GML 2.1.1, GML 2.1.2, GML 3.0,
SLD 1.0, WFS 1.0 (compliant), WMS 1.1.1
WMS 1.1.1 (compliant), WFS 1.0 (compliant)
Server
Server
Server
Client e Server
Server
Server
Server
Server
Server
Server
OLSCore(RS) 1.0, OLSCore(PS) 1.0,
OLSCore(LUS) 1.0, OLSCore(GS) 1.0,
OLSCore(DS) 1.0, OLSCore 1.1, OLSCore 1.0
WCS 1.1.1 c1, WCS 1.0, SLD 1.0, Filter 1.1,
Filter 1.0, CAT2 ISO AP 1.0.0, CAT2 ebRIM
part2 1.0.0, CAT2 ebRIM part1 1.0.0, CAT2 AP
ebRIM 1.0.0, CAT CS/W 2.0.1, CAT 2.0.2, CAT
1.0, WFS 1.0, WFS 1.1, WMS 1.1.1, WMS 1.3.0
Server
Client e Server
Server
Server
Client e Server
Server
Client e Server
Client
Client
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 12 di 193
FAO-UN
Generalitat
Valenciana
http://topp.openpl
ans.org
Intergraph
Corporation
Lat/lon
Spatial Database SFS(NG) 1.1 (compliant)
Engine for Oracle
3.0.2
GeoNetwork
CAT 1.1.1, CAT CS/W 2.0.1, CAT2 AP
opensource 2.1
19115/19119 0.9.3, GeoRSS 1.0.0, SOAP 0.8,
WMC 1.1, WMS 1.0, WMS 1.1.1
gvSIG 0.6
CAT2 AP 19115/19119 0.9.3, CAT2 AP ebRIM
0.9.1, Filter 1.0, Gaz 0.9.1, WCS 1.0, WCS
1.0.0, WMS 1.1, WMS 1.1.1, WMS 1.3.0
GeoServer 1.3
WFS(T) 1.0 (compliant), WFS 1.0 (compliant),
GeoServer 1.5
WCS 1.0 (compliant), Filter 1.1, Filter 1.0, KML
2.1.0, SLD 1.0, WFS 1.0, WFS(T) 1.0, WMS
1.1.1
GeoMedia Data
Server for Oracle
Object Model
Server
(Read/Write)
05.01
GeoMedia
WMS 1.1, SFS(BG) 1.1 (compliant), WMS 1.0,
Professional
WFS 1.0, WMS 1.1.1, WFS 1.0, GML 2.0
GeoMedia
GML 2.1.1, WMS 1.0, WMS 1.1, WMS 1.1.1,
Viewer
GML 2.0, WFS 1.0
GeoMedia Web
SFS(BG) 1.1 (compliant), WMS 1.1.1
Map Professional (compliant), WFS 1.0 (compliant), GML 2.0,
05.01
WFS 1.0, WFS(T) 1.0, WMS 1.0, WMS 1.1
GeoMedia
WMS 1.1, WMS 1.0, WFS(T) 1.0, WMS 1.1.1
WebMap 05.01
(compliant), WFS 1.0 (compliant), GML 2.1.1,
GML 2.0
WMS Viewer
WMS 1.1, WMS 1.0, SLD 1.0, WMS 1.1.1
deegree
CAT2 AP 19115/19119 0.9.3, GAZ 0.9.3, WFS
iGeoPortal 1.1, WMS 1.0, WMS 1.1, WMS 1.1.1
portlet edition
2.1.0
deegree
WTS 0.5, WMS 1.1.1, WMS 1.1, WMS 1.0,
iGeoPortal WMC 1.0, WFS 1.1, GML 3.1.1, GML 2.1.2,
standard edition
GAZ 0.9.3, CAT2 AP 19115/19119 0.9.3, CAT
2.1.0
CS/W 2.0.1
deegree owsProxy WMS 1.1.1, WFS 1.1, CAT2 AP 19115/19119
2.1.0
0.9.3
deegree Web
Coordinate
Transformation
Service 2.1.0
deegree Web
Coverage Service
1.1.5
deegree Web
Coverage Service
2.1.0
deegree Web
Feature Service
2.1.0
deegree Web
Feature Service
2.1.0
Client
Client e Server
Client
Server
Server
Server
Client e Server
Client
Client e Server
Client e Server
Client (HTML)
Client (HTML)
Client (HTML)
Proxy
(Client/Server)
WCTS 0.4.0
Server
WCS 1.0 (compliant)
WCS 1.0 (compliant)
Server
Server
GML CityGML 0.3.0, GML 3.1.1, GML 2.1.1,
GAZ 0.9.3, Filter 1.1, WFS 1.1
Server
GAZ 0.9.3, Filter 1.1, WFS 1.1
Server
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 13 di 193
MapInfo
Corporation
MsSqlSpatial
Oracle
Corporation
PCI Geomatics
deegree Web
Gazetteer Service
2.1.0
deegree Web
Gazetteer Service
2.1.0
deegree Web Map
Service 1.1.2
deegree Web Map
Service 2.1.0
deegree Web
Processing
Service 2.1.0
deeJUMP 2.1.0
Envinsa 4.0
MapInfo
Professional 8.5
MapXtreme 2005
6.5
MapXtreme 2005
6.6
MapXtreme Java
Edition 4.7
MapXtreme Java
Edition 4.8
MsSqlSpatial Spatial
Extensions for
SQL Server 2005
0.1
Oracle
Application
Server
MapViewer, 10g
Release 2 (10.1.2)
Oracle Spatial
11g
Oracle Locator,
10g Release 2
(10.2.0.1)
Oracle Spatial,
10g Release 2
(10.2.0.1)
Oracle Spatial, 9i
Release 2 (9.2.0)
Oracle Spatial,
release 9i (9.0.1)
Oracle8 Spatial
Cartridge 8.0.5
Oracle8i Spatial
8.1.7
Geomatica WebServer Suite
10.0
Geomatica
WebServer -
WFS 1.1, GML 3.1.1, GAZ 0.9.3, Filter 1.1
WFS 1.1, GML 3.1.1, GAZ 0.9.3, Filter 1.1
Server
Server
WMS 1.1.1 (compliant), WMS 1.1, WMS 1.0,
SLD 1.0
WMS 1.1.1 (compliant), WMS 1.1, WMS 1.3.0
(compliant)
WPS 0.3.0
Server
WMS 1.1.1, WMS 1.1, WFS 1.1
WMS 1.1.1 (compliant), WFS 1.0, OLSCore 1.1,
GML 3.0
WMS 1.1.1, WMS 1.1, WMS 1.0, WFS 1.0,
SFS(TF) 1.1, GML 2.1.1, WMS 1.3.0
WMS 1.1.1 (compliant), WMS 1.1, WMS 1.0,
WFS 1.0, GML 3.0, GML 2.1.1
WMS 1.1.1 (compliant), GML 2.1.1, GML 3.0,
WFS 1.0, WMS 1.0, WMS 1.1
WMS 1.1.1 (compliant), GML 2.1.1, SFS(TF)
1.1, WMS 1.1
WMS 1.1.1 (compliant), GML 2.1.1, SFS(TF)
1.1, WMS 1.1
SFS(TF) 1.1, SFS 1.1.0
Client
Server
Server
Server
Client
Client e Server
Client e Server
Client e Server
Client e Server
Server
Client e Server
WFS 1.0, WFS-T 1.0, CSW 2.0, OpenLS 1.1
Client e Server
Client e Server
Client e Server
SFS(NG) 1.1 (compliant)
Client e Server
Client e Server
Client e Server
Client e Server
WMS 1.1.1, WFS 1.0, WCS 1.0 (compliant)
WMS 1.1.1
Client e Server
Client e Server
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 14 di 193
Refractions
Research Inc
Safe Software
UMN MapServer
GWS 9.0
PostGIS /
PostgreSQL
1.1.3 / 8.1.3
FME 2008
MapServer 4.2
WhereGroup
Mapbender 2.4.3
GmbH & Co. KG
Mapbender OWS
Proxy 2.4.3
SFS 1.1.0 (compliant), SFS(TF) 1.1 (compliant)
GeoRSS 1.0.0, GMLsf 1.0.0, KML 2.1.0, KML
2.2.0, WFS 1.0, WFS 1.1, WMS 1.1.1, WMS
1.3.0
WMS 1.1, WMS 1.0, WMC 1.0, WFS 1.0, SLD
1.0, GML 2.0, Filter 1.0, WMS 1.1.1
Common 1.0, Common 1.1.0, WFS 1.0, WFS
1.1, WFS(T) 1.0, WMC 0.1.4, WMC 0.1.7,
WMC 1.0, WMC 1.1, WMS 1.0, WMS 1.1,
WMS 1.1.1
OWS Common 0.1.0, OWS Common 0.2.0,
OWS common 0.3.0, Portal Architecture 0.2,
WFS 1.0, WFS 1.1, WFS(T) 1.0, WMC 0.1.4,
WMC 0.1.7, WMC 1.0, WMC 1.1, WMS 1.0,
WMS 1.1, WMS 1.1.1
Server
Client e Server
Client e Server
Client (HTML)
Proxy
(Client/Server)
Tabella 3 - Software commerciali, free e open source più diffusi nel nostro paese e
relativa compatibilità con le raccomandazioni OGC (rielaborazione fonte OGC)
Principali raccomandazioni OGC
Nella tabella 3 i riferimenti alle norme sono riportati in modo conciso. La tabella 4
seguente riporta le note di riferimento per esteso, per ognuna delle abbreviazioni
riportate nella tabella 3 ; segue quindi un breve glossario esplicativo della funzione
delle principali norme OGC.
Sigla Abbreviata
Raccomandazione
OGC
Documento
Vers. più recente
Link
CAT
Catalogue Services
Specification
2.0.2
http://www.opengeo
spatial.org/standard
s/cat
Common
Web Services
Common
Specification
1.1.0 with
Corrigendum 1
http://www.opengeo
spatial.org/standard
s/common
CORBA
Simple Features
Specification
For CORBA
Revision 1.1
http://www.opengeos
patial.org/standards/sf
c
GML
Geography Markup
Language (GML)
Encoding Standard
3.2.1
http://www.opengeos
patial.org/standards/g
ml
KML
OGC® KML - OGC
07-147r2
2.2.0
http://www.opengeos
patial.org/standards/k
ml
SLD
Styled Layer
1.1.0 (revision 4)
http://www.opengeos
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 15 di 193
patial.org/standards/sl
d
Descriptor profile of
the Web Map Service
Implementation
Specification
SFS
Implementation
Specification for
Geographic
information - Simple
feature access - Part
1: Common
architecture
1.2.0
http://www.opengeos
a
SFS (TF)
Specification for
Geographic
information - Simple
feature access - Part
2: SQL option
1.2.0
http://www.opengeos
a
WCS
Web Coverage
Service (WCS)
Implementation
Standard
1.1.2
http://www.opengeos
patial.org/standards/w
cs
WFS
Web Feature Service
Implementation
Specification
1.1.0
http://www.opengeos
fs
WMS
Web Map Server
Implementation
Specification
1.3.0
http://www.opengeos
ms
Tabella 4 – Principali standard di riferimento dell'OGC
Catalogue Services Specification (CAT)
Le raccomandazioni si riferiscono alla strutturazione di applicazioni
per la
pubblicazione e l'accesso a cataloghi digitali di metadati relativi a dati geografici.
Catalogue Services for the Web (CSW)
La sintassi di un record CSW è una codifica di un blocco di metadati strutturati
secondo lo standard terminologico del Dublin Core. I servizi di catalogo usano
SOAP come protocollo di invio dei messaggi. Sono attivabili servizi di scoperta,
accesso, manutenzione a organizzazione dei cataloghi di informazioni geografiche e
delle relative risorse.
WSDL (Web Service Description Language )
Protocollo utilizzato per descrivere i Web Service basati su XML.
Web Coverage Service (WCS) Implementation Standard
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 16 di 193
Lo standard si riferisce alle modalità di accesso e manutenzione di dati geografici in
formato raster o grid. L'accesso all'informazione geografica è completa a differenza
di quanto avviene per I servizi di tipo WMS tramite I quali viene restituita una
semplice immagine, limitata all'area oggetto di interrogazione, che mostra le
informazioni geografiche richieste.
Web Map Service (WMS)
Un Web Map Service (WMS) rende disponibili mappe di dati geografici. Il servizio
produce mappe a scopo illustrativo senza riferimenti a dati correlati ma è predisposto
per la semplice restituzione del risultato dell'interrogazione della banca dati
geografica, come immagini PNG, GIF, JPEG, talvolta in formato vettoriale semplice
come il Web Computer Graphics Metafile (WebCGM) o lo Scalable Vector Graphics
(SVG).
Riferimenti
●
●
Ahmet Sayar, Geoffrey Fox, Mehmet S. Aktas, Marlon Pierce, Galip Aydin Developing a Web Service-Compatible Map Server for Geophysical
Applications, Community Grids Lab and Department of Computer Science Indiana
University, Bloomington, IN, 47404 (812) 856-0752;
Open Geospatial Consortium - http://www.opengeospatial.org
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 17 di 193
STANDARD METADATI
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 18 di 193
Standard CNIPA
Lo standard definito dal CNIPA1 (Centro Nazionale per l’Informatica nella Pubblica
Amministrazione) identifica l’insieme minimo di elementi di metadati (Core metadati)
necessario per documentare tutte le tipologie di dati territoriali (cartografia, immagini,
modelli digitali del terreno, reti geodetiche,…) prodotti e/o gestiti dalla Pubblica
Amministrazione italiana.
Il documento di riferimento è il “Repertorio Nazionale dei Dati Territoriali – Linee guida per
l’applicazione dello Standard ISO 19115: Geographic Information-Metadata”2, versione 0.3
(25 settembre 2006). In questo documento sono definite le linee guida per l’applicazione dello
Standard ISO 19115:2003 "Geographic Information - Metadata".
L'insieme dei metadati è suddiviso nelle seguenti classi.
•
Metadati (MD_metadata): contiene informazioni sull’insieme delle entità dei
metadati. Può essere vista come un aggregato delle classi descritte ai punti seguenti.
•
Identificazione (MD_Identification e MD_DataIdentification):
informazioni utili a identificare senza ambiguità i dati descritti.
•
Qualità dei dati (DQ_DataQuality): fornisce informazioni sulla qualità dei dati.
•
Provenienza e processo di realizzazione dei dati (LI_Lineage): fornisce
informazioni sulla provenienza e sul processo di realizzazione dei dati.
•
Gestione (MD_Maintenance):
aggiornamento dei dati.
•
Rappresentazione spaziale (MD_SpatialRepresentation): fornisce informazioni
sulla rappresentazione spaziale dei dati territoriali (obbligatorio per immagini e DTM).
•
Sistema di riferimento (MD_ ReferenceSystem): fornisce informazioni sul sistema
di riferimento spaziale dei dati.
•
Contenuto (MD_ContentInformation): questo pacchetto è obbligatorio nel caso si
descriva una ortofoto e fornisce informazioni riguardi il contenuto dell’immagine.
•
Distribuzione(MD_Distribution): fornisce gli elementi necessari a documentare il
formato di distribuzione dei dati e le indicazioni riguardanti la persona/ente da
contattare per ottenere ulteriori informazioni.
•
Responsabile del dato (CI_Citation e CI_ResponsibleParty): fornisce informazioni
riguardanti i responsabili di dati e metadati.
fornisce
informazioni
sulla
fornisce
frequenza
le
di
1 http://www.cnipa.gov.it/
2 http://www.cnipa.gov.it/site/itIT/Aree_operative/Progetti,_applicazioni_e_servizi/Sistemi_Informativi_Territoriali_/Repertorio_Nazionale_
dei_Dati_Territoriali/
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 19 di 193
•
Estensione (EX_Extent): fornisce informazioni riguardanti l’estensione spaziale dei
dati.
Per ogni classe sono definiti uno o più campi per i quali è definito se:
⁃
deve essere sempre documentato, campo obbligatorio (O);
⁃
può non essere compilato, campo opzionale (Op);
⁃
al verificarsi si determinate condizioni deve essere documentato, (C).
L’insieme di metadati caratterizzato da un livello di obbligatorietà di tipo “O” costituisce il
“Core metadati”: insieme minimo di metadati necessario per documentare i dati territoriali.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 20 di 193
Informazioni sui metadati (MD_Metadata)
ID
Nome del metadato
Descrizione
1
2
3
Identificatore del file di metadati (O)
Lingua dei metadati (O)
Set dei caratteri dei metadati (C)
4
Identificatore metadati di rango superiore (O)
5
Livello gerarchico (O)
Identificatore univoco del file di metadati
Lingua in cui sono scritti i metadati
Set di caratteri utilizzato per i metadati (es.”utf8)
Se esistono dei metadati gerarchicamente
superiori (ad es. se i metadati si riferiscono ad un
dataset appartenente ad una serie) questo è
l'identificatore univoco del file di metadati di
rango superiore
Livello gerarchico del metadato (es. serie,
dataset, sezione)
Nome dell’ente responsabile
Ruolo ricoperto dall’ente
Informazioni utili per contattare l’ente (num. di
telefono, e-mail,…)
Data di creazione dei metadati
Standard di metadati utilizzato
Versione dello standard utilizzato
Restrizioni di utilizzo dei metadati
Definizione di eventuali vincoli di accesso
esistenti
Definizione di eventuali vincoli di utilizzo
esistenti
Definizione di altri eventuali vincoli esistenti
6
Contatto (O)
Nome dell’Ente (O)
Ruolo (O)
Informazioni per contattare l’Ente (O)
7
8
9
10
Data dei metadati (O)
Nome dello standard dei metadati (O)
Versione dello standard dei metadati (O)
Limitazione d’uso dei metadati (Op)
Vincoli d’accesso dei metadati (Op)
Vincoli di fruibilità dei metadati (Op)
Altri vincoli sui metadati (C)
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.0
Pagina 21 di 193
Informazioni di identificazione dei dati (MD_Identification-MD_DataIdentification)
Titolo (O)
Data (O)
Tipo di data (O)
11
Responsabile dei dati (O)
Ruolo (O)
Informazioni per contattare l’Ente (O)
Identificatore (O)
Serie-dataset (O)
Altri dettagli (Op)
Titolo del dato
Data associata
Evento a cui si riferisce la data (creazione,
pubblicazione,…)
Nome dell’ente responsabile
Ruolo ricoperto dal responsabile
Informazioni utili per contattare l’ente (num. di
telefono, e-mail,…)
Riferimento univoco che identifica la risorsa nel
livello gerarchico specificato.
Informazioni sulla serie/dataset di cui il
dataset/sezione fa parte
Ulteriori informazioni
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.0
Pagina 22 di 193
12
Descrizione (O)
13
Parole chiave (O)
14
15
Punto di contatto (O)
Tipo di rappresentazione spaziale (C)
16
Risoluzione spaziale dei dati (O)
17
18
19
Lingua dei dati (O)
Set di caratteri dei dati (C)
Tema (O)
Localizzazione geografica dei dati
20
Estensione verticale (Op)
Descrizione del dato
Elenco parole chiave che caratterizzano il dato
Scala equivalente (C)
Distanza (C)
WestBoundLongitude (O)
EastBoundLongitude (O)
SouthBoundLongitude (O)
NorthBoundLongitude (O)
Quota min (O)
Quota max (O)
Unità di misura (O)
Datum verticale (O)
21
Informazioni supplementari (Op)
22
Esempio grafico (Op)
Informazioni sui vincoli dei dati (MD_Constraints)
23
Limitazione d’uso dei dati (O)
Vincoli di accesso dei dati (O)
24
25
26
Vincoli di fruibilità dei dati (O)
Altri vincoli sui dati (C)
Responsabile della risorsa
Rappresentazione spaziale utilizzata
Scala della carta
Risoluzione geometrica al suolo.
Lingua utilizzato per i dati
Tema a cui si riferisce il dato
Limite ovest in gradi decimali
Limite est in gradi decimali
Limite sud in gradi decimali
Limite nord in gradi decimali
Quota minima
Quota massima
Unità di misura della quota
Datum utilizzato per definire le quote
Eventuali informazioni descrittive supplementari
Eventuale immagine che illustra la risorsa
Restrizioni di utilizzo dei dati
Definizione di eventuali vincoli di accesso
esistenti
Definizione di eventuali vincoli di utilizzo
esistenti
Definizione di altri eventuali vincoli esistenti
Informazioni sulla qualità dei dati (DQ_DataQuality)
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.0
Pagina 23 di 193
27
Livello di qualità (O)
Qualità dei dati (accuratezza posizionale) (C)
28
Unità di misura (O)
Livello cui sono applicate le informazioni di
qualità
Unità di misura dei valori di qualità dei dati
Valore (O)
Valore quantitativo della qualità dei dati
Informazioni sulla provenienza e sul processo di produzione dei dati (MD_Lineage)
29
Descrizione del processo di realizzazione del
dato (es. stereorestituzione)
Genealogia del dato-Processo di produzione (O)
Informazioni sul sistema di riferimento (MD_ReferenceSystem)
30
Sistema di riferimento utilizzato (es. ROMA 40/
EST)
Sistema di riferimento spaziale (O)
Informazioni sulla distribuzione (MD_Distribution)
Nome formato (O)
31
Formato di distribuzione (O)
Versione formato (O)
32
33
Distributore (O)
Risorsa on-line (Op)
Ruolo (O)
Informazioni per contattare l’Ente
(O)
Nome del formato dei dati
Versione del formato dei dati
Nome dell’ente responsabile della distribuzione
Ruolo ricoperto dal responsabile
Informazioni utili per contattare l’ente (es. num.
di telefono)
Informazioni sulle fonti on-line dalle quali la
risorsa può essere ottenuta
Per le immagini (foto aeree, ortofoto, immagini da telerilevamento) e i modelli digitali del terreno, oltre all’insieme minimo di metadati definito
nelle tabelle precedenti, ne sono stati definiti altri: sono stati individuati due gruppi per le immagini e i dati raster in generale: i dati
“georeferenziabili” per i quali è utile conoscere i punti di controllo e altri parametri allo scopo di processarli per essere georettificati, e i dati
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.0
Pagina 24 di 193
georettificati. I metadati comuni ad entrambi le categorie (che quindi vanno documentati sempre in caso di dati raster) sono riportati nelle tabelle
seguenti.
Informazioni sul contenuto (MD_ContentInformation)
1
Descrizione degli attributi (O)
2
Tipi di contenuto (O)
Risoluzione radiometrica (Op)
3
4
Triangolazione aerea (Op)
Descrizione dalla grandezza misura
Tipo di informazione rappresentato dal valore della cella
Numero massimo di bit significativi in cui può essere
rappresentata l’intensità radiometrica di ogni pixel
Indica se la triangolazione aerea è stata effettuata o meno
Informazioni sulla rappresentazione spaziale dei dati (MD_GridSpatialRepresentation)
5
Numero di dimensioni (O)
Numero degli assi spazio-temporali indipendenti
Nome degli assi
Nome dimensione (O)
Numero degli elementi lungo gli assi
6
Proprietà dimensioni (O)
Misura dimensione (O)
Risoluzione (Op)
7
Geometria della cella (O)
8
Disponibilità coefficienti della trasformazione (O)
Grado di dettaglio dei dati (es. passo 40 metri)
Geometria utilizzata per le celle raster
Disponibilità dei coefficienti della
trasformazione affine per il passaggio da
coordinate immagine a coordinate terreno
Nel caso si voglia documentare dati raster georettificati, è necessario aggiungere questi ulteriori campi:
Informazioni sulla rappresentazione spaziale dei dati raster georettificati (MD_Georectified)
1
Disponibilità di check-points (O)
Indicazione sulla disponibilità di chek-point
2
Descrizione check-points (C)
Descrizione dei check point
3
Punto dei pixel (O)
Punto del pixel a cui si riferiscono le coordinate
4
Coordinate dei vertici (O)
Coordinate dei vertici della griglia espresse nel
proprio sistema di riferimento
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.0
Pagina 25 di 193
Informazioni sulla rappresentazione spaziale dei dati raster georeferenziabili (MD_Georeferenceable)
1
Disponibilità dei punti di controllo (O)
Indica se esistono o meno dei punti di controllo
2
Disponibilità dei parametri di orientamento (O)
Indica se esistono o meno dei parametri di
orientamento
3
Parametri di georeferenziazione (O)
Parametri utilizzati per la georeferenziazione
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.0
Pagina 26 di 193
Standard Dublin Core
A livello mondiale ha avuto molto seguito il sistema di metadati nato in America, nella città
di Dublin (Ohio), intorno alla metà degli anni novanta e noto con il nome di Dublin Core3.
Questo schema è molto più semplice dello standard ISO: è composto da soli 15 elementi.
 Titolo: nome dato alla risorsa oppure termine con il quale la risorsa è conosciuta.
 Autore: responsabile principale della risorsa.
 Soggetto: argomento principale della risorsa.
 Descrizione: descrizione del contenuto della risorsa.
 Editore: responsabile della pubblicazione della risorsa.
 Autore di contributo subordinato: responsabile della produzione di una parte della
risorsa.
 Data: data di creazione o di disponibilità della risorsa.
 Tipo: natura della risorsa.
 Formato: formato in cui la risorsa è disponibile (fisico o digitale).
 Identificatore: riferimento univoco alla risorsa.
 Fonte: riferimento a una risorsa dalla quale è derivata la risorsa in oggetto.
 Lingua: lingua utilizzata.
 Relazione: riferimento ad una risorsa correlata.
 Copertura: estensione della risorsa (localizzazione spaziale, periodo temporale).
 Gestione dei diritti: informazione sui diritti di accesso alla risorsa.
Il Dublin Core permette la descrizione di una grande varietà di risorse in formati diversi. Data
la sua semplicità questo standard di metadati è molto utilizzato, non solo in ambito
cartografico, e molti progetti fanno riferimento ad esso. Questa diffusione a livello mondiale
ha portato alla definizione della norma ISO 15836:2003 che recepisce le direttive di questo
standard. L’emissione della norma ISO costituisce un riconoscimento ufficiale per l’uso del
set Dublin Core che, sin dalla prima conferenza di Dublin nel marzo del 1995, è stato tradotto
in oltre 20 lingue ed utilizzato in tutto il mondo.
3 http://dublincore.org
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 27 di 193
Standard di metadati adottati da GeoNetwork
Il software GeoNetwork4 adotta come schema per i metadati una versione personalizzata dello
standard ISO 19115 oltre allo standard Dublin Core e allo standard americano FGDC.
Lo standard adottato in GeoNetwork è una semplificazione dello standard ISO, del quale sono
stati conservati solo quei metadati ritenuti indispensabili per catalogare in modo
sufficientemente completo un dato geografico. E' composto da cinque sezioni valide per tutti i
tipi di dati: Identification Section, Distribution Section, Reference System Section, Data
Quality Section, Metadata Section, e da una sezione valida solo per i dati raster: Spatial
Representation Info.
È possibile gestire l'inserimento dei metadati secondo due modalità:
⁃
"default view", che mostra solo i campi definiti come obbligatori;
⁃
"advanced view" che mostra anche ai campi opzionali.
4 http://geonetwork-opensource.org
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 28 di 193
Identification section (default view)
ID
Nome del metadato
Descrizione
1
Title *
Nome del dato
2
Date *
Data di riferimento
3
Data Type *
Evento a cui si riferisce la data (creazione, pubblicazione,
…)
4
Edition
Versione della risorsa
5
Presentation form
Modalità di presentazione
6
Abstract *
Breve descrizione della risorsa
7
Purpose
Scopo per cui è stato creato il dato
8
Status
Stato della risorsa (es. obsoleta, attiva, ...)
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.0
Pagina 29 di 193
9
10
Point of contact
Point of contact
Individual name *
Nome del responsabile dei metadati
Organization name *
Nome dell’organizzazione
Position name *
Ruolo esercitato dal responsabile
Voice
Numero di telefono del responsabile
Facsimile
Numero di fax del responsabile
Delivery point
Indirizzo dell’organizzazione
City
Città
Administrative area
Suddivisione amministrativa (ad es. per l'Italia la provincia
di appartenenza)
Postal code
Codice di avviamento postale
Country
Paese
Electronic mail address
Indirizzo e-mail
Role *
Ruolo del responsabile
Responsabile della risorsa e modalità di contatto
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.0
Pagina 30 di 193
11
Maintenance and update *
12
Descriptive keywords (1)
13
Descriptive keywords (2)
Informazioni circa l’aggiornamento dei dati
Keyword
Parole chiave associate alla risorsa
Type
Tipo di parola chiave (es. temporale, disciplina, tema,...)
Keyword
Parole chiave associate alla risorsa
Type
Tipo di parola chiave (es. temporale, disciplina, tema,...)
14
Access constraints
Vincoli di accesso ai dati per assicurare la privacy o la
proprietà intellettuale e più in generale ogni altra
restrizione o limitazione riguardanti la risorsa
15
Use constraints
Vincoli sulla possibilità di utilizzare il dato, derivanti da
regolamenti e norme nazionali ed europee
16
Other constraints *
Altri vincoli e prerequisiti legali per l’accesso e l’utilizzo
della risorsa
17
Spatial representation type
Metodo di rappresentazione spaziale dei dati (es. vettoriale)
18
Equivalent scale *
19
Language *
Denominator *
Scala
Lingua utilizzata per i dati
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.0
Pagina 31 di 193
20
Character set
Set di caratteri utilizzato per I metadati (es.”utf8)
21
Topic category code *
Tema principale cui si riferiscono i dati
22
Extent *
23
Extent
Temporal Extent
Begin date
Data di inizio di validità del dato
End date
Data di fine di validità del dato
Geographic bounding West
bound Limite ovest in gradi decimali
box
latitude *
East
bound Limite est in gradi decimali
latitude *
South
bound Limite sud in gradi decimali
latitude *
North
bound Limite nord in gradi decimali
latitude *
24
Supplemental information
Informazioni supplementari
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.0
Pagina 32 di 193
Distribution info (default view)
25
26
27
OnLine resource
OnLine resource
Online resource
URL
Indirizzo internet di una risorsa
Protocol
Protocollo di connessione usato
Description *
Descrizione dell’evento inclusi i parametri e la tolleranza
URL
Protocol
File
Nome file
Description *
URL
Protocol
Name *
Nome delle serie, dei dataset aggregati o del dataset di cui fa parte
il dato
Description *
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.0
Pagina 33 di 193
Reference system info (default view)
28
Code *
Nome del sistema di riferimento
Data quality info (default view)
29
Hierarchy level *
Livello con cui sono applicate le informazioni di qualità (es.
dataset, attributo)
30
Statement *
Informazioni circa il livello gerarchico dei dati
Metadata (default view)
31
File identifier
Identificatore univoco del file di metadati
32
Language *
Lingua utilizzata per i metadati
33
Character set
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.0
Pagina 34 di 193
34
Date stamp
Data di creazione dei metadati
35
Metadata standard name
Nome dello standard (incluso il nome del profilo) di
metadati utilizzato
36
Metadata standard version
Versione dello standard/profilo utilizzato
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.0
Pagina 35 di 193
37
Metadata author *
Individual name *
Nome dell’autore dei metadati
Organization name *
Nome dell’organizzazione
Position name *
Ruolo dell'autore
Voice
Numero di telefono dell'autore
Facsimile
Numero di fax dell'autore
Delivery point
Indirizzo dell’organizzazione
City
Città
Administrative area
Suddivisione amministrativa
Postal code
Codice di avviamento postale
Country
Paese
Electronic mail address
Indirizzo e-mail
Role *
Ruolo dell'autore
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.0
Pagina 36 di 193
Spatial representation info (default view)
38
Number of dimension *
Numero degli assi spaziali-temporali indipendenti
39
Dimension name *
Nome degli assi
40
Dimension size *
41
Resolution
Grado di dettaglio dei dati
42
Dimension name *
Nome degli assi
43
Dimension size *
44
Resolution
Grado di dettaglio dei dati
45
Dimension name *
Nome degli assi
46
Dimension size *
47
Cell geometry *
Identificazione dei dati raster come punti o celle
48
Transformation parameter availability *
Indicazione se esistono o meno i coefficienti della
trasformazione affine per il passaggio da coordinate
immagine a coordinate terreno
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.0
Pagina 37 di 193
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.0
Pagina 38 di 193
Corrispondenze tra gli standard di Geonetwok, CNIPA e Dublin Core
In questa tabella sono messi a confronto lo standard utilizzato da GeoNetwork, lo standard
CNIPA e lo standard Dublin Core.
Nelle colonne sono riportati:
⁃
nome: etichetta assegnata all’elemento o all’entità dei metadati;
⁃
elemento corrispondente ISO: viene riportato il corrispondente elemento dello
standard ISO 19115:2003 indicato con il nome in inglese definito dallo standard;
⁃
elemento corrispondente DublinCore: viene riportato il corrispondente elemento dello
standard DublinCore indicato con il nome definito dallo standard;
⁃
occorrenza massima: specifica il numero massimo di istanze che gli elementi e le
entità dei metadati possono avere;
⁃
tipologia del dato: specifica l’insieme di valori per rappresentare l’elemento dei
metadati (es. intero, reale, stringa,…);
⁃
dominio: per un’entità, il dominio indica i numeri di riga coperti da quell’entità.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 39 di 193
Title
1
Character string
Testo libero
Titolo
2
Date
N
Integer
Date selector
Dominio
Elemento
Doublin
Core
ID-Dublin Core
Occorrenza
1
Tipo
ID-ISO
Nome del metadato
360
Title
1
Date
362
Date
7
DataType
395
Date
7
Edition
363
ID-CNIPA
ID-GeoNetwork
Identification Section
Elemento ISO
134
Title
Data
135
Tipo data
150
Elemento
CNIPA
3
Data Type
1
String
Creation,
Publication,
revision
4
Edition
1
Character string
Testo libero
5
Presentation form
N
String
Map digital, map
hard copy,...
Tipo di dato 139
Presentation
form
368
Type
8
6
Abstarct
1
Character string
Testo libero
Descrizione 20
Abstarct
25
Description
4
7
Purpose
1
Character string
Testo libero
Scopo
Purpose
26
8
Status
N
String
On-going, obsolete,
…
Status
28
52
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.0
Pagina 40 di 193
9
Point of contact
Individual name 1
String
Testo libero
Organization
name
1
Character string
Testo libero
Position name
1
Character string
Testo libero
Voice
N
Character String
Testo libero
Facsimile
N
Character string
Testo libero
Nome
dell’Ente
142
Individual
name
375
Organization
name
376
Creator
/Publisher
2/5
Position name 377
Telefono
156
Informazion
i per
143
contattare
l’Ente
Voice
408
Facsimile
409
Contact Info
378
382
Delivery point
1
Character string
Testo libero
City
1
Character string
Testo libero
City
Administrative
area
1
Character string
Testo libero
Administrative
383
area
Postal code
1
Character string
Testo libero
Postal code
384
Country
1
Character string
Testo libero
Country
385
Electronic mail
address
1
Character string
Testo libero
Sito
152
Linkage
397
Role
1
String
Custodian, owner,
user,…
Ruolo
144
Role
379
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.0
Pagina 41 di 193
10
Point of contact
N
String
Point of contact
Punto di
contatto
11
Maintenance and
update
N
Associazione
Daily, weekly,...
Character string
12
Descriptiv
e
keywords
13
Descriptiv
e
keywords
Keyword N
Type
1
Point of
contact
29
Gestione
22
della risorsa
Resource
Maintenance
30
Testo libero
Parola
chiave
38
Keyword
53
Theme, place,…
Thesaurus
39
Thesaurus
name
55
21
Keyword N
Character string
Testo libero
Parola
chiave
38
Keyword
53
Type
1
String
Theme, place,…
Thesaurus
39
Thesaurus
name
55
Subject
3
14
Access constraints
N
String
Copyright, license,
…
Vincoli di
accesso
48
Access
constraints
70
Rights
15
15
Use constraints
N
String
Copyright, license,
…
Vincoli di
fruibilità
49
Use
constraints
71
Rights
15
N
Character string
Testo libero
Altri vincoli 50
Other
constraints
72
Rights
15
16
Other constraints
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.0
Pagina 42 di 193
17
Spatial representation
N
type
String
Tipo di
Vector, gride,video, rappresenta
28
…
zione
spaziale
18
Equivalent scale
1
Character string
Number
19
Language
1
Character string
20
Character set
1
21
Topic category code
22
Temporal Extent
Spatial
representation
type
37
Scala
43
equivalente
Equivalent
scale
60
ISO 639-2
Lingua dei
metadati
Language
3
String
Utf8
Set dei
caratteri dei 4
metadati
Character set
4
N
String
Boundaries,
farming,…
Tema
32
Topic category
41
code
N
Integer
Date selector
Estensione
33
Extent
3
Type
8
Language
12
Subject
3
45
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.0
Pagina 43 di 193
23
24
Geographic
bounding
box
West
bound
1
latitud
e
Integer
Integer
Longitudine
120
Ovest
West bound
latitude
343
coverage
14
East
bound
1
latitud
e
Integer
Integer
Longitudine
121
Est
East bound
latitude
344
coverage
14
South
bound
1
latitud
e
Integer
Integer
Latitudine
Sud
122
South bound
latitude
345
coverage
14
North
bound
1
latitud
e
Integer
Integer
Latitudine
Nord
123
North bound
latitude
346
coverage
14
Testo libero
Informazio
ni
34
supplement
ari
Supplemental
information
46
Supplemental
information
1
Character string
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.0
Pagina 44 di 193
Elemento
CNIPA
1
Classe
URL (IETF
RFC1738)
Risorsa on
line
1
String
Description
1
URL
URL
25
26
Linkage
397
Web address,
related link,...
Protocol
398
Character string
Testo libero
Description
401
1
Classe
URL (IETF
RFC1738)
Linkage
397
1
String
Web address,
related link,...
Protocol
398
File
1
Character string
Testo libero
File Name
49
Description
1
Character string
Testo libero
Description
401
OnLine
resource Protocol
OnLine Protocol
resource
Risorsa on
line
147
Elemento ISO
147
Elemento
Doublin Core
ID-Dublin Core
Dominio
ID-ISO
Tipo
Nome del metadato
ID-CNIPA
Occorrenza
ID-GeoNetwork
Distribution Section
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.0
Pagina 45 di 193
1
Classe
URL (IETF
RFC1738)
1
String
Name
1
Description
1
URL
27
OnLine Protocol
resource
Risorsa on
line
147
Linkage
397
Web address,
related link,...
Protocol
398
Character string
Testo libero
Name
400
Character string
Testo libero
Description
401
28 Code
1
Character string
Testo libero
Elemento
CNIPA
Identificatore
del sistema di
riferimento
88
Elemento ISO
Reference
system
identifier
Elemento
Doublin Core
ID-Dublin Core
Dominio
ID-ISO
Tipo
ID-CNIPA
Nome del metadato
Occorrenza
ID-GeoNetwork
Reference System Info
187
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.0
Pagina 46 di 193
29 Hierarchy level
30 Statement
Elemento
CNIPA
N
String
Dataste, series,
attributes,…
Livello
gerarchico
6
Hierarchy
level
6
Testo libero
Genealogia
del datoProcesso di
produzione
56
Statement
83
1
Character String
Elemento ISO
Elemento
Doublin Core
Type
ID-Dublin Core
Dominio
ID-ISO
Tipo
ID-CNIPA
Nome del metadato
Occorrenza
ID-GeoNetwork
Data Quality Info
8
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.0
Pagina 47 di 193
ID-CNIPA
ID-Dublin Core
Tipo
Elemento ISO
31 File identifier
1
Character string
Testo libero
Identificatore
del file di
metadati
2
File identifier
2
Identifier
10
32 Language
1
Character string
ISO 639-2
Lingua dei
metadati
3
Language
3
Language
12
33 Character set
1
Classe
Utf8
Set dei caratteri
dei metadti
4
Character set
4
34 Date stamp
1
Character string
ISO 8601
Data dei
metadata
8
Date stamp
9
Date
7
Nome dello
standard dei
metadati
9
Metadata
standard name
10
Versione dello
standard dei
metadati
10
Metadata
standard
version
11
Nome del metadato
Dominio
Elemento
CNIPA
Metadata standard
35
name
1
String
ISO
19115:2003/19
139
Metadata standard
Version
1
String
1.0
36
ID-ISO
Occorrenza
ID-GeoNetwork
Metadata Information Section
Elemento
Doublin Core
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.0
Pagina 48 di 193
37
Metadata author
Individual
name
1
Character string
Testo libero
Organizati
on name
1
Character string
Testo libero
Position
name
1
Character string
Testo libero
Voice
N
Character String
Testo libero
Facsimile
N
Character string
Testo libero
Delivery
point
1
Character string
Testo libero
City
1
Character string
Testo libero
Administr
ative area
1
Character string
Testo libero
Postal
code
1
Character string
Testo libero
Postal code
384
Country
1
Character string
Testo libero
Country
385
Electronic
mail
address
1
Character string
Testo libero
Linkage
397
Role
1
String
Role
379
Custodian,
Nome
dell’Ente
Telefono
Informazioni
per contattare
l’Ente
142
156
143
Individual
name
375
Organization
name
376
Position name
377
Voice
408
Facsimile
409
Contact Info
378
City
382
Creator
/Publisher
2/5
Administrative
383
area
Ruolo
144
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.0
Pagina 49 di 193
Elemento
CNIPA
1
Integer
Integer
Numero delle
dimensioni
70
Number of
dimension
158
39 Dimension name
1
String
Row, column,…
Nome
dimensione
84
Nome
dimensione
180
40 Dimension size
1
Integer
Integer
Misura
dimensione
85
Dimension
size
181
41 Resolution
1
Classe
Measure
Risoluzione
86
Resolution
182
42 Dimension name
1
String
Row, column, …
Nome
dimensione
84
Nome
dimensione
180
43 Dimension size
1
Integer
Integer
Misura
dimensione
85
Dimension
size
181
44 Resolution
1
Classe
Measure
Risoluzione
86
Resolution
182
45 Dimension name
1
String
Row, column,…
Nome
dimensione
84
Nome
dimensione
180
38 Number of dimension
Elemento ISO
Elemento
Doublin Core
ID-Dublin Core
Dominio
ID-ISO
Tipo
Nome del metadato
ID-CNIPA
Occorrenza
ID-GeoNetwork
Spatial Representation Info
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.0
Pagina 50 di 193
46 Dimension size
1
Integer
Integer
Misura
dimensione
85
Dimension
size
181
47 Cell geometry
1
Classe
Area, point
Geometria
della cella
72
Cell geometry
160
Testo libero
Disponibilità
dei
coefficienti
della
trasformazion
e
73
Transformatio
n parameter
availability
161
48
Transformation
parameter availability
1
Character string
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.0
Pagina 51 di 193
RNDT - REPERTORIO NAZIONALE DEI DATI TERRITORIALI
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 52 di 193
Introduzione
Il portale realizzato dal CNIPA (Centro Nazionale Per l'Informatica nella Pubblica
Amministrazione) ha lo scopo di fornire una struttura per l'inserimento e la consultazione dei
metadati relativi ai dati territoriali disponibili in ambito nazionale nei diversi enti della
pubblica amministrazione (regioni, province, autorità di bacino, comunità montane....).
Questa struttura, chiamata "Repertorio Nazionale dei Dati Territoriali" (RNDT) permetterà di
catalogare in modo uniforme e rendere accessibili tutte le metainformazioni riguardanti i dati
territoriali disponibili in ambito nazionale. Questo repertorio è stato istituito presso il CNIPA,
seguendo quanto stabilito dall’art.59 del Codice dell’amministrazione digitale.
Le linee guida del progetto sono state definite nel 2005 e approvate sulla base delle
prescrizioni contenute nel documento “Repertorio Nazionale dei Dati Territoriali – Linee
guida per l’applicazione dello Standard ISO 19115: "Geographic Information-Metadata”,
approvato dal Comitato per il coordinamento informatico dei dati territoriali, nella riunione
del 28 febbraio 2006. In questo documento sono definite le linee guida per l’applicazione
dello Standard ISO 19115:2003 "Geographic Information - Metadata" al Repertorio
Nazionale dei Dati Territoriali. In particolare è stato individuato un insieme minimo di
elementi di metadati (Core Metadata) valido per tutte le tipologie di dati territoriali esistenti
presso le PP.AA., che dovranno essere documentati nel Repertorio Nazionale ed è stata
definita la struttura concettuale dei metadati.
La fase operativa del progetto è iniziata nel maggio 2006 ed è tuttora in corso.
Il Repertorio è, quindi, uno strumento conoscitivo mediante il quale, nel rispetto e in coerenza
con le regole tecniche concernenti il Sistema pubblico di connettività e in linea con le
indicazioni contenute nella direttiva INSPIRE, sarà possibile accertare la disponibilità di dati
territoriali, con l’obiettivo di mettere in condivisione e rendere più agevolmente accessibile il
patrimonio pubblico dei dati stessi. Per rendere pubblico l'accesso e completare il progetto si
aspetta il recepimento della direttiva INSPIRE in modo da poter implementare appieno
all'interno della definizione dei metadati quanto previsto in sede comunitaria.
Aspetti tecnologici
Il portale di consultazione/aggiornamento dei metadati, al momento in fase di test e non
completo di tutte le funzionalità previste, risulta così strutturato:
●
linguaggio di sviluppo del sito: PHP5;
●
navigazione/interrogazione dei dati: UMN MapServer6/Ka-Map7;
●
database: PostgreSQL8/PostGIS9.
L'intero progetto è stato quindi sviluppato con tecnologia open source ed è intenzione del
CNIPA, una volta terminato lo sviluppo, rendere disponibile il software all'esterno. Al
5
6
7
8
9
http://www.php.net/
http://mapserver.gis.umn.edu/
http://ka-map.maptools.org/
http://www.postgresql.org/
http://www.postgis.org/
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 53 di 193
momento non è stata comunque ancora definita la licenza che regolamenterà la distribuzione
del software.
Standard Metadati adottato
La struttura dei metadati utilizzata per il RNDT è quella definita nel documento "Repertorio
Nazionale dei Dati Territoriali - Linee guida per l'applicazione dello standard ISO 19115
Geographic Information - Metadata"10 pubblicato dal CNIPA. L'ultima versione pubblicata è
la 0.3 del 25/09/06. Questo documento contiene alcune integrazioni rispetto alla versione
iniziale e inoltre sono stati pubblicati anche gli schemi XSD (10/10/07) necessari per
descrivere, validare e interscambiare i metadati e un documento di approfondimento
presentato al Forum PA 2007.
L’attuale versione degli schemi XSD è stata definita in seguito di una fase di test con la
collaborazione di amministrazioni centrali: Agenzia del Territorio e AGEA (Agenzia per le
erogazioni in agricoltura ); e periferiche: Regione Campania. La fase di test è tuttora in corso,
pertanto potrebbero essere introdotte ulteriori modifiche.
Struttura gerarchica del metadato
Nel Repertorio Nazionale dei Dati Territoriali la descrizione dei dati è organizzata in modo
gerarchico: è infatti possibile applicare i metadati a livello di aggregazioni di dataset che
condividono caratteristiche simili in termini di tema, risoluzione, specifiche e metodologia di
realizzazione (serie), a livello di singoli dataset e a livello di sottoinsiemi di dataset (sezioni).
Come esempio di distribuzione dei dati nei diversi livelli gerarchici può essere considerato il
seguente caso:
●
CTR regionale di un determinato anno: serie => prodotto completo;
●
il singolo lotto di produzione della CTR regionale: dataset => distinte unità che
insieme costituiscono la serie di dati;
●
le singole sezioni che costituiscono una CTR: sezioni o tile => sottoinsiemi del
dataset.
È possibile quindi definire i metadati per i diversi livelli gerarchici che costituiscono questa
struttura: possiamo perciò definire a livello di serie tutte le informazioni valide per più dataset
e mantenere a livello di dataset quelle informazioni che effettivamente distinguono un dataset
da un altro. In generale tutti i metadati definiti ad un determinato livello gerarchico saranno
ereditati da tutti i suoi sottolivelli.
Inoltre, restando valido il concetto di gerarchia introdotto, potremmo avere una serie
composta da un unico dataset: in questo caso i due livelli gerarchici coincidono e si
appiattiscono uno sull'altro.
10 http://www.cnipa.gov.it/site/itIT/Aree_operative/Progetti,_applicazioni_e_servizi/Sistemi_Informativi_Territoriali_/Repertorio_Nazionale_
dei_Dati_Territoriali/
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 54 di 193
Questo tipo di organizzazione gerarchica è stata la causa principale della scelta compiuta dal
CNIPA che ha portato alla realizzazione di un nuovo prodotto e a non utilizzare prodotti già
esistenti, come ad esempio Geonetwork11. Al momento in cui si è deciso in merito alla
struttura software da utilizzare (2006) il CNIPA ha preso in esame Geonetwork, ma non
avendo implementato una struttura gerarchica di questo tipo, si è preferito realizzare un nuovo
software.
Procedura di popolamento dell'archivio
Sono state definite due modalità di popolamento dell'archivio dei metadati, in funzione delle
risorse a disposizione dell'ente interessato.
Modalità interattiva (Figura 1).
L'inserimento dei metadati avviene tramite una serie di form direttamente nel portale del
RNDT. Compilando in modo opportuno queste form diventa poi possibile generare un file
XML che permetterà di inserire effettivamente i dati all'interno del repertorio. Questa
procedura è pensata per i piccoli enti che non hanno a disposizione una struttura interna per la
gestione di queste informazioni e non sono in grado o non sono interessati a utilizzare metodi
più evoluti.
Modalità di cooperazione.
In questo caso si suppone che l'ente interessato abbia predisposto al suo interno un sistema di
gestione dei metadati e che quindi disponga già di un proprio archivio e di strumenti adeguati
per trattare questo tipo di informazioni. A questo livello l'obiettivo è facilitare la trasmissione
dell'informazione al CNIPA e cooperare così alla creazione del registro nazionale. In questo
caso l'ente non dovrà effettuare l'inserimento manuale tramite una form come per la modalità
interattiva ma, disponendo già al suo interno dell'informazione opportunamente catalogata, gli
si chiederà unicamente di produrre un XML (secondo un formato concordato) da sottoporre
alle procedura di validazione del CNIPA. La generazione di questo XML avverrà in modalità
diverse in base ai software utilizzati localmente dell'ente per la gestione del metadato. La
procedura di upload del file XML può avvenire secondo due modalità: è possibile caricare un
singolo file XML alla volta, specificando l'operazione da compiere, inserimento, modifica,
cancellazione (Figura 2); oppure utilizzare la funzione di inserimento multiplo (Figura 3). In
questo caso è possibile specificare più file XML per ognuno dei quali è associato il tipo di
operazione che deve essere compiuta.
Indipendentemente dalla procedura seguita i dati inviati sono inseriti in un database di lavoro
(staging) in attesa di essere sottoposti alla procedura di validazione (Figura 4) che ne verifica
la conformità e, se la validazione ha dato esito positivo, i dati saranno pubblicati e disponibili
all'interno delle funzionalità di ricerca.
11 http://geonetwork-opensource.org/
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 55 di 193
La fase di validazione comporta, da parte del personale del CNIPA, una verifica di
completezza e di coerenza dei file inviati dalle amministrazioni, che comunque restano le
uniche responsabili del contenuto pubblicato.
I test di validazione hanno il compito di verificare la compatibilità dei nuovi dati con le linee
guida del RNDT:
- test di completezza: si determina la conformità nella documentazione di tutte le sezioni, le
entità e gli elementi di metadati che sono indicati nelle linee guida come “obbligatori” o
“condizionati”;
- test dell’occorrenza massima: viene assicurato che ogni elemento è ripetuto non più del
numero di volte indicato nelle linee guida;
- test del tipo di dato: viene determinato se ogni elemento dei metadati documentati utilizza il
tipo di dato specificato nelle linee guida;
- test del dominio: viene determinato se ogni elemento dei metadati documentati nel
Repertorio rientra nel dominio specificato;
- test dello schema: viene determinato se l’insieme dei metadati documentato nel Repertorio
segue lo schema specificato nelle linee guida per l’applicazione dello standard ISO 19115
Geograpich Information – Metadata.
Questa operazione di validazione può comportare diverse interazioni tra il personale del
CNIPA e l'ente che ha fornito i dati, fino alla pubblicazione finale dei dati sul RNDT (Figura
5).
Dopo l’operazione di validazione viene effettuato il trasferimento dei dati validati dal
database di staging al database finale. Sempre rispettando l’ottica di gerarchizzazione dei
metadati viene prima copiata la serie con tutti i suoi metadati, vengono poi inseriti tutti i
dataset della serie con i relativi metadati e, infine, per ciascun dataset vengono inseriti i
metadati relativi a ciascuna sezione.
Allo stato attuale non è stato ancora implementato, ma si prevede che le operazioni di
scambio dell'XML tra l'ente che invia i dati e il portale del RNDT avvenga utilizzando la
porta di dominio ICAR.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 56 di 193
Figura 1: inserimento metadati: modalità interattiva
Figura 2: inserimento metadati: modalità di cooperazione - singolo XML
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 57 di 193
Figura 3: inserimento metadati: modalità di cooperazione - XML multiplo
Figura 4: validazione XML
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 58 di 193
Figura 5: procedura di validazione del CNIPA
Accesso e interrogazione dei dati
Sono previste due modalità di consultazione dei dati dell'archivio:
●
consultazione accessibile: realizzata in modo da rispettare i criteri di accessibilità
(Non è ancora disponibile in quanto deve essere verificata l'effettiva conformità alle
norme in materia di accessibilità sul web) - Figura 6;
●
consultazione estesa: permette di stabilire diversi criteri di ricerca, per parole chiave e
per area geografica definendola direttamente sulla carta - Figura 7.
La ricerca geografica può avvenire in due modalità:
●
dati contenuti nell'area: sono estratti tutti i dati che sono interamente contenuti
all'interno del boundig box specificato come area di interesse
●
dati che contengono l'area: sono estratti tutti i dati che comprendono al loro interno
l'area specificata.
In questo modo si riesce a raffinare la ricerca in base alla necessità di reperire dati che
riguardano una zona dal punto di vista locale o globale.
Entrambi i criteri danno accesso ad una maschera che consente di interrogare i metadati
contenuti nel Repertorio ed individuare le risorse che li soddisfano. Possono essere indicati
criteri di ricerca sia alfanumerici che geografici attraverso le specifiche sezioni della
maschera.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 59 di 193
Sezione "dove": permette di impostare l’area su cui effettuare la ricerca. Può essere scelta
indicando un limite amministrativo, un toponimo o selezionando direttamente sulla carta
un'area di interesse. L'area di ricerca sarà fissata sulle dimensioni del rettangolo minimo
(bounding box) che contiene il limite amministrativo indicato, non sugli effettivi confini
amministratavi.
Sezione "cosa": permette di effettuare la ricerca in base al titolo, alla categoria e all’intervallo
di scala della carta.
Sezione "quando": permette di cercare i dati in base ad un intervallo temporale di validità.
Nell'esempio di Figura 7 è stata definita come zona di interesse la regione Sardegna: il
risultato di questa ricerca è mostrato in Figura 8.
I risultati restituiti sono presentati rispettando la struttura gerarchica di inserimento: serie,
dataset, tile. Il dato è però restituito a livello di dataset. Se all'interno di una serie sono
presenti dei dataset che soddisfano i criteri di ricerca posti, viene restituito un elenco con la
serie e solo i dataset che soddisfano i criteri, non tutti i dataset della serie (Figura 9).
È prevista anche la realizzazione di una funzione di ricerca geografica per intersezione: si
specifica cioè una zona di interesse e si estraggono tutti i dati che la intersecano.
Oltre che mediante consultazione diretta dei risultati (Figura 54) è possibile ottenere i risultati
nel formato XML. E' prevista anche la realizzazione di una mappatura tra lo standard adottato
dal CNIPA e il Dublin Core, in modo da fornire in uscita i metadati anche secondo questo
standard.
È prevista inoltre l'implementazione dello standard OGC "Catalog Service"12.
12 http://www.opengeospatial.org/standards/cat
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 60 di 193
Figura 6: consultazione accessibile
Figura 7: consultazione estesa
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 61 di 193
Figura 8: risultato ricerca su Regione Sardegna
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 62 di 193
Figura 9: elenco dei dataset
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 63 di 193
GEOSERVER E DEEGREE
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 64 di 193
GeoServer: caratteristiche generali
GeoServer (http://docs.codehaus.org/display/GEOS/Home) è un WebGis server open source
(GPL) per la pubblicazione e la modifica di dati geografici, scritto in linguaggio Java e
basato sulla libreria Geotools (la stessa usata da uDig). Si tratta di un sistema
multipiattaforma, supportato direttamente su Windows e Linux, ma sono noti utenti
anche MacOSX, BSD e Solaris.
In particolare richiede Java 1.4 ed un web container (Jetty, Tomcat, JBoss, Glassfish,
WebSphere, WebLogic, ...).
GeoServer supporta gli standard OGC (Open Geospatial Consortium) in particolare i
protocolli WFS, WCS, WMS 1.1.1, Filter , SLD, e produce cartografia sia raster
(JPEG, PNG) che vettoriale (GML, KML, SVG, Shapefile e PDF).
GeoServer è nato a New York grazie ad un progetto no-profit indicato con l’acronimo
“TOPP” (The Open Project Planning).
Topp (http://topp.openplans.org/) essendo no-profit è sponsorizzata da donazioni ed
accetta contratti per finanziare specifici sviluppi di Geoserver. I “profitti” vengono poi
re-incanalati in nuove direzioni per la costruzione di strumenti tecnologici che
facilitino la trasparenza di governo e forniscano ai cittadini strumenti per partecipare
nello sviluppo di vari aspetti della società (pianificazione, urbanistica, etc.).
La comunità di Geoserver è un ambiente collaborativo e pronto. Vengono date
risposte in tempi brevi 24h su 24h e TOPP garantisce la presenza costante dei suoi
sviluppatori (localizzati in Italia, Stati Uniti e Canada). È possibile inoltre accedere
alla mailing list degli sviluppatori e degli utenti (adatta per problemi specifici,
suggerimenti, e per chiunque voglia collaborare allo sviluppo di Geoserver)
attraverso i seguenti indirizzi internet:
•
http://docs.codehaus.org/display/GEOSDOC/1+Mailing+lists
•
http://www.nabble.com/GeoServer-f1193.html
O ancora segnalare un baco al seguente indirizzo:
•
http://jira.codehaus.org/browse/GEOS
Vi sono inoltre vari fornitori di supporto, tra cui si possono citare: Refractions, Axios,
Geo-solutions, ... . Ogni “supporter” ufficiale ha contribuito e contribuisce in modo
significativo allo sviluppo di Geoserver e ne ha sviluppato uno o più moduli attraverso
una conoscenza profonda del sistema.
(http://docs.codehaus.org/display/GEOS/Commercial+Support).
GeoServer si pone come obiettivi:
•
L’apertura dei dati, non una semplice fornitura di immagini:
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 65 di 193
•
WFS, è il “sorgente” di un vettoriale;
•
WCS, è il “sorgente” di un raster;
•
Il dato è scaricabile, riutilizzabile al di là del server.
Comunità:
•
•
Costruire una buona comunità open source.
Scalabilità:
•
•
Gestione di grossi volumi di dati;
•
Il server deve poter essere utilizzato da enti pubblici.
Figura 10: Input e output, cosa legge e cosa genera GeoServer
Geoserver usa i sistemi di riferimento definiti nel database pubblico di EPSG,
l'European Petroleum Survey Group. Più in dettaglio:
•
In Geoserver 1.4, l'elenco è contenuto in un file di testo e codificato in un WKT
(Well Known Text) minimo, senza il parametro WGS;
•
In Geoserver 1.5 abbiamo un clone completo della base dati di EPSG (in un
DBMS embedded, HSQL).
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 66 di 193
Geoserver 1.4 non è in grado di fare cambi di sistemi di riferimento poiché mancano i
parametri per la trasformata di Bursa-Wolf. Geoserver 1.5 è limitato ai cambi che si
possono esprimere con la Bursa-Wolf (in alcuni casi il cambio è “compound”).
Figura 11: Un esempio di WKT
Attualmente GeoServer è alla versione 1.6.0. Queste le novità principali rispetto alle
versioni precedenti:
•
Un grosso aumento di performance nelle renderizzazione di mappe tramite
WMS.
•
Supporto per il versioning: sarà possibile modificare dati spaziali come dentro
un wiki, e mantenere le varie versioni modificate dai vari utenti nel tempo. Il
versioning è possibile al momento soltanto utilizzando PostGIS come base
dati.
•
Supporto per WFS 1.1 (reference implementation).
•
Aggiunta di un sistema di gestione della sicurezza basato su Acegi con la
possibilità di gestire ruoli.
•
Migliore integrazione con Google Maps/Virtual Earth/Yahoo! Maps.
•
Migliore integrazione con OpenLayers.
•
Possibilità di modificare via web un database ArcSDE tramite OpenLayers.
•
Erogazione di dati in modalità di Cascading WFS e Component WMS.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 67 di 193
Figura 12: Certificazioni OGC
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 68 di 193
Figura 13: Client, chi parla con GeoServer
Figura 14: Diagramma complessivo di GeoServer
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 69 di 193
GeoServer, protocollo WFS
Con il protocollo WFS (Web Feature Service) si può avere l’accesso e la modifica di
“Feature” geografiche. Al contrario di WMS, si lavora a livello di dato, non di
rappresentazione. WFS opera a livello di “codice sorgente” dell'informazione
geografica e presuppone un approccio a “oggetti territoriali” (il mondo è vuoto, se non
dove è popolato di entità con una posizione, una forma e attributi ben definiti”). Gli
oggetti territoriali di WFS si chiamano Feature, hanno un identificativo (FID, Feature
ID), una o più geometrie, ed eventuali attributi (Simple Feature). Geoserver è la
reference implementation di WFS 1.0 e presto lo sarà anche di WFS 1.1.
I FeatureType supportati al momento sono “simple”. Non ci sono associazioni,
collegamenti; si tratta dell’equivalente di una tabella di base dati. I FeatureType
descrivono esattamente la struttura della base dati cui sono collegati (nome colonna
-> nome attributo). Per svariate applicazioni questo non è sufficiente, e sono
necessari collegamenti, alcune proprietà devono essere liste, collezioni, etc. La
versione di Geoserver successiva alla 1.6 (1.7, 2.0, ...) supporterà collegamenti,
alias, espressioni calcolate.
Le principali operazioni che si possono eseguire con il WFS sono:
•
GetCapailities
•
DescribeFeatureType
•
GetFeature
•
GetFeatureWithLock
•
LockFeature
•
Transaction
WFS GetCapabilities è la carta di identità del server, il punto di accesso che
consente di conoscerlo, di sapere quali dati fornisce e cosa può fare, consente di
negoziare il livello di protocollo a cui client e server si parlano (1.0 o 1.1).
Esso restituisce un documento XML piuttosto lungo, vediamone gli elementi
essenziali:
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 70 di 193
Figura 15: WFS GetCapabilities, sommario e operazioni
Figura 16: WFS GetCapabilities, feature types
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 71 di 193
WFS GetFeature, estrae le Feature di uno o più FeatureType che rispettano un
determinato filtro. Il filtro (purtroppo) deve essere espresso in XML, ma può essere
molto sofisticato. E' possibile estrarre le Feature nei formati dichiarati in
GetCapabilities. GML2 è richiesto per essere compatibili, ma Geoserver risponde
anche in formato shapefile compresso (.zip).
Esiste un primitivo supporto alle versioni, ma al momento Geoserver non lo sfrutta
(versioning WFS, sarà supportato a breve) inoltre non è previsto il cambio di sistema
di riferimento o proiezione (esso sarà aggiunto con WFS 1.1).
Figura 17: WFS GetFeature, schema XML
Figura 18: WFS GetFeature, esempio di richiesta (1)
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 72 di 193
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 73 di 193
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 74 di 193
Transactional WFS significa poter:
•
Aggiungere
•
Cancellare
•
Modificare
feature di qualunque tipo (puntuali, lineari, poligonali, semplici o complesse). La
modifica può essere effettuata su singole Feature, o in massa: un filtro OGC decide
quali Feature vengono coinvolte, se su singoli attributi, o su tutti gli attributi.
Insomma, vi è totale libertà di movimento.
La specifica WFS non permette di limitare il tipo di geometria o di attributo che si è in
grado di inserire/modificare (o tutti, o non si è compatibili). Si può però limitare il tipo
di operazioni che si possono svolgere su un determinato FeatureType. Geoserver
non sfrutta questa capacità, si può effettuare qualunque tipo di operazione su
qualunque FeatureType (una lama a doppio taglio al momento, non si può limitare
quali FeatureType sono soggetti a modifica).
Lo standard non prevede un modo per creare nuovi FeatureType. Geoserver non
fornisce un modo, nemmeno lui... i FeatureType sono un reverse engineering di una
struttura dati esistente (shapefile, database) inoltre le insert devono essere codificate
in GML, non ci sono formati alternativi (non si può fare l'upload di uno shapefile e
chiedere di fare una sorta di merge).
Figura 22: WFS Transaction, schema XML (1)
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 75 di 193
Figura 23: WFS Transaction, schema XML (2)
Figura 24: WFS Transaction, esempio di insert
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 76 di 193
Figura 25: WFS Transaction, esempio di update
Figura 26: WFS Transaction, esempio di delete
Le transazioni sono certamente utili, ma in un contesto di client desktop, ci vuole
qualcosa di più.. In particolare si vuole poter isolare le feature sulle quali si stà
lavorando in modo che nessun altro le possa modifichicare.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 77 di 193
Se una Feature è sottoposta a lock, si può modificare solo se la transazione fa
riferimento ai LockId che vengono ritornati da Lock e GetFeatureWithLock. Il lock ha
una durata specificata nella richiesta, oltre questa decade automaticamente.
Figura 27: Schemi locking
Il protocollo non è pensato per un uso manuale, ed anche se XML è human
readable, non è certo facile scrivere una richiesta corretta.
I Client disponibili sono:
•
uDig
•
MapBuilder
•
OpenLayers (ancora in beta)
Come risultato si ha che il WFS diventa un protocollo per remotizzare l'editing di dati
geografici; i clienti hanno l'idea di un editing diretto con un normale shapefile o base
dati geografica.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 78 di 193
Geoserver, protocollo WCS
Con il protocollo WCS (Web Coverage Service), GeoServer lavora a livello di livello
di “codice sorgente” dell'informazione geografica e tutto ciò presuppone un approccio
a campi. Gli oggetti territoriali di WCS si chiamano Grid Coverage, ed hanno una
estensione (non necessariamente bi-dimensionale), una risoluzione ed una o più
bande informative. Mentre per i vettoriali il formato standard è GML, in WCS deve
essere supportato almeno uno fra una rosa di formati (GeoTIFF, HDF-EOS, DTED,
NITF, GML).
Geoserver 1.5.x implementa WCS 1.0 e supera i test CITE relativi.
Le grid coverage supportate al momento sono di tipo bidimensionale. In particolare il
supporto è stato testato estensivamente su immagini satellitari semplici, in mosaico,
o su piramide, in true color. Il supporto a raster “geofisici” è presente, ma non
altrettanto testato. Lo stesso si può dire per immagini con palette (256 o più colori). In
Geoserver, il supporto WCS ha permesso di supportare anche i raster nel WMS
(Geoserver 1.4.0 non è in grado di gestire dati raster).
In futuro si prospetta di avere un supporto completo al RasterSymbolizer e si sta
parlando di supporto a grid n-dimensionali (ora possono essere simulate col supporto
multi-banda se la terza dimensione ha un dominio finito e “piccolo”).
Si hanno i seguenti formati standard in ingresso:
•
GeoTIFF nelle sue varie forme. In particolare, per servire mappe tramite
WMS, si consiglia di effettuare il tiling interno e di aggiungere le overview (con
GDAL, anche se si stanno sviluppando tool specifici);
•
Immagine + world file + projection file (proiezione in formato wkt);
•
ArcGRID;
•
Gtopo30;
•
In lavorazione, si hanno ECW e JPEG2000 (appoggiandosi su GDAL), e
NetCDF.
Ed inoltre i seguenti formati di ingresso non standardizzati:
Mosaico di immagini
•
•
•
Supporta tiling regolare o immagini sovrapposte;
•
Usa uno shapefile di appoggio per la descrizione delle envelope e
l'indicizzazione, esattamente come MapServer;
•
Può essere prodotto con gdaltindex, ma richiede un file di proprietà ulteriore.
Piramide di immagini
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 79 di 193
•
Si tratta di un insieme di mosaici regolari contenuti in cartelle separate;
•
Un file di proprietà lega le risoluzioni alle cartelle, consentendo di scegliere il
livello più appropriato alla richiesta WCS o WMS;
•
Esistono strumenti per crearlo, tuttavia al momento piuttosto primitivi.
Per quanto concerne la scalabilità:
•
In linea generale, le Geotiff con overview complete (livelli per potenze di due)
sono piuttosto veloci, si possono servire senza difficoltà raster di centinaia di
megabyte o pochi gigabyte;
•
Le piramidi sono consigliate quando i dati sono di svariati gigabyte e devono
scalare dalla piena risoluzione alla overview di piccola scala;
•
Come ha commentato un utente sulla mailing list:
•
AA: I'm doing other tests, since apparently a 1.4GB image is not big enough to show a
performance difference (between pyramid and overviews)
•
VS: Hey, that's peanuts. Be a man, try mosaicing all SRTM data. But watch out for the tiff 2 or
4 Gb limit. (NDR: 14GB di GTIFF in .zip, si possono scaricare da
ftp://srtm.csi.cgiar.org/srtm_v3/SRTM_Data_GeoTiff/).
Con il protocollo WCS (Web Coverage Service) si possono eseguire le seguenti
operazioni:
•
GetCapabilities
•
DescribeCoverage
•
GetCoverage
La specifica WCS tuttavia non prevede, al momento, un WCS-T (coverage
modificabili).
WCS GetCapabilities è la carta di identità del server, il punto di accesso che
consente di conoscerlo, di sapere quali dati fornisce e cosa può fare.
In questo caso abbiamo una descrizione sommaria delle coverage:
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 80 di 193
Figura 28: Coverage
WCS DescribeCoverage è analoga a DescribeFeature e consente di conoscere la
struttura della coverage:
•
Dominio spaziale e temporale
•
Attributi e loro struttura (possono essere semplici scalari, oppure vettori, o
“compound”, ad esempio, radiazione per lunghezza d'onda, con vari range di
l.o.)
•
CRS in cui la coverage può essere richiesta e fornita
•
Formati in cui la coverage può essere prodotta.
In particolare la risposta può essere molto complessa nel caso generale. Nel caso
specifico di Geoserver, si lavora con immagini a bande per cui i range sono semplici
intervalli o enumerazioni.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 81 di 193
Figura 29: WCS DescribeCoverage, una porzione dello schema
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 82 di 193
Figura 30: DescribeCoverage, Gtopo30
Con la GetCoverage. è possibile eseguire la richiesta di una coverage, specificando:
•
Formato della coverage generata
•
Dominio richiesto (spazio e tempo)
•
CRS
•
Attributi richiesti (quali assi o valori degli assi)
•
Metodo di interpolazione
•
Nuovamente, la richiesta in XML è abbastanza sofisticata
•
La chiamata può essere effettuata anche come GET.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 83 di 193
Figura 31: Esempio di GetCoverage (POST)
Impostare una richiesta WCS a mano è piuttosto laborioso. Allo stesso tempo, i client
sono carenti:
•
GAIA3 supporta WCS (non è liberamente scaricabile)
•
GvSig 0.6 funziona con Geoserver, GvSig 1.0 presenta dei problemi
•
...
La specifica è relativamente recente rispetto alle altre, il suo uso meno richiesto.
Geoserver, protocollo WMS
Il protocollo WMS viene utilizzato per la creazione di mappe con standard OGC. In
questo caso si ha un’idea di layer e di stile, ma non è noto cosa siano internamente.
Nel caso di Geosever, un layer è un feature type WFS o una coverage WCS. Lo stile
è sempre una descrizione in SLD (Styled Layer Descriptor). È supportato il protocollo
WMS 1.1.1, ma non l'1.3 (non è prevista una sua realizzazione).
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 84 di 193
Le principali operazioni che si possono eseguire con il WMS sono:
•
GetCapailities
•
GetMap
•
GetFeatureInfo
•
GetLegendGraphic
•
DescribeLayer
•
GetStyle
•
PutStyle
WMS GetCapabilities e analoga a quella di WFS e WCS. La risposta elenca: i soliti
metadati sul server, le chiamate supportate, l'elenco dei layer, con lo stile di default e
l'elenco dei sistemi di riferimento in cui possono essere restituiti. La parte relativa ai
layer è interessante per quanto riguarda i sistemi di riferimento. L'elenco dei layer è
gerarchico, si può definire un layer padre astratto che contiene definizioni comuni ai
layer figli. Geoserver usa questa capacità per fornire una sola volta il lungo elenco di
SRS supportati.
Figura 32: GetCapabilities, i layer
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 85 di 193
La specifica WMS permette di allegare “dimensioni” ai layer, in modo da poter
estrarre una specifica vista.
“Time” viene usata per layer di cui si dispongono varie versioni, valide in diversi
istanti temporali;
“Elevation” consente invece di accedere allo stesso layer “affettato” su una certa
quota (da voxel a semplice raster, ad esempio).
Geoserver non supporta queste estensioni al momento, probabilmente verranno
aggiunte nella versione 1.6.x.
WMS GetMap, permette di ottenere una mappa specificando nella chiamata:
•
Un elenco di layer da visualizzare
•
Un elenco di stili (può essere vuoto per adottare gli stili di defalt)
•
L'area da visualizzare
•
La dimensione dell'immagine
•
Il formato di immagine restituito
•
Il colore di sfondo, l'eventuale trasparenza dell'immagine
Lo standard base richiede il supporto delle richieste di tipo GET; Geoserver ha una
estensione che consente di usare anche POST (per richieste molto lunghe).
Figura 33: GetMap, esempio (1)
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 86 di 193
Figura 34: GetMap, esempio (2)
Dal documento GetCapabilities di Geoserver 1.5.x si può affermare che i formati
supportati sono:
•
image/jpeg
•
image/png (png 24 bit)
•
image/gif
•
image/tiff
•
image/geotiff
•
image/svg+xml
•
application/pdf
•
application/vnd.google-earth.kml+xml
•
application/vnd.google-earth.kmz
GetFeatureInfo permette di realizzare un tool “info”, ovvero sapere cosa c'é in un
determinato punto e quali sono le sue proprietà. Tuttavia si possono interrogare solo
i layer con queryable=”true” nella risposta di GetCapabilities. Esistono vari formati di
uscita, puro testo e un HTML fisso. I layer di tipo raster al momento non sono
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 87 di 193
interrogabili. Nella prossima release verrà aggiunto un sistema di templating per
consentire di ottenere output ad hoc per la propria applicazione.
SLD è una sofisticata specifica OGC per la vestizione di layer vettoriali e raster. E'
molto flessibile anche se nella sua generalità risulta di difficile comprensione e non
ha sintassi semplificate per i tipi di rendering più comuni. Una volta presa
padronanza dello strumento si possono realizzare styling piuttosto sofisticati, si tratta
in particolare di documenti XML, dove vengono riusate sia le specifiche GML che le
specifiche Filter.
Figura 35: SLD schema, UserStyle, FeatureTypeStyle, Rule
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 88 di 193
Figura 36: SLD schema, line symbolizer
Figura 37: SLD schema, polygon symbolizer
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 89 di 193
Figura 38: SLD schema, point symbolizer
Figura 39: SLD schema, text symbolizer
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 90 di 193
SLD è potente, ma allo stesso tempo, è molto complesso! Per crearlo si possono
adottare varie strategie:
•
Usare un editor SLD capace di creare gli stili più comuni. Udig ne possiede
uno.
•
Usare un editor XML con supporto per XML schema, in grado di creare uno
scheletro di partenza e di autocompletare il codice
•
Partire da esempi già fatti ed effettuare piccole modifiche
Figura 40. Esempi SLD, linea semplice
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 91 di 193
Figura 41: Esempi SLD, con etichette
Figura 42: Esempi SLD, con filtri (1)
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 92 di 193
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 93 di 193
Figura 45: Esempi SLD, raster symbolizer
Quando si scrive un SLD, occorre conoscere gli attributi dei feature type e le
caratteristiche delle grid coverage. Queste informazioni sono fornite dai rispettivi
servizi WFS e WCS. DescribeLayer consente di chiedere dove trovare il layer nel
WFS e nel WCS, o se al contrario questo non è possibile (layer che rappresentano
raggruppamenti di altri layer, ad esempio).
Figura 46: DescribeLayer
Infine GetStyle e PutStyle consentono rispettivamente di ottenere il codice SLD di
uno stile, e di caricare un nuovo stile sul server. Un client avanzato può sfruttare
questa possibilità per ottenere un rendering specifico per le sue necessità. In
particolare GetLegendGraphic permette di ottenere elementi grafici per creare la
legenda di una mappa.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 94 di 193
Sviluppi futuri
In futuro si prevede che GeoServer abbia:
•
Nuova interfaccia utente e sistema di configurazione
•
Miglior esperienza utente
•
Miglior esperienza di sviluppo
•
Semplificazione nella definizione dei filtri e di SLD
•
Miglior supporto alla pubblicazione di mappe in grande scala con Tiled Map
Server, specifica OSGEO analoga negli intenti a KaMap.
•
Collaborazione on-line su dati vettoriali (GeoWiki, GeoCollaborator)
•
Sistema di autenticazione
•
Versioning WFS (log, diff, rollback, ...)
•
Supporto 2.5d per Google Earth
•
Supporto strutture dati complesse
•
Join e associazioni fra feature type
•
Coverage n-dimensionali.
Diversamente da MapServer, supporta anche le funzionalità di editing (modifica) del
servizio WFS. Inoltre vanta un robusto controllo transazionale per l'editing multiutente
del GIS: questo in pratica significa che diversi operatori possono lavorare sul GIS,
senza il rischio che modifiche contemporanee portino alla corruzione dei dati.
GeoServer è quindi indicato nei casi in cui occorre una vera e propria gestione
distribuita di un GIS, e non solo l’accesso alla cartografia via Web.
Deegree: caratteristiche generali
Che cosa è Deegree? La definizione più precisa che si può dare è la seguente:
Deegree è un applicazione Java (Application Programming Interface) per i GIS
(Geographic Information System). Si tratta di un vasto set di classi Java per la
creazione di un Sistema Informativo Territoriale.
Deegree comprende attualmente il più completo set di Web Services dell’ OGC.
La figura seguente dà una visione d’insieme dei vari servizi, secondo le tipologie su
elencate:
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 95 di 193
Figura 47: Componenti struttura dei web services dell’OGC
Nell’agosto del 2003 il consorzio OGC ha pubblicato delle linee guida (CookBook4)
per l’implementazione di Web Map Server (per la fornitura di portrayal services), e
sta preparando la pubblicazione di un CookBook per l’implementazione di Web
Feature Server (per la fornitura di data services).
Il progetto Degree nasce nel 2000 con il nome di JaGO – Java Framework for
Geographical Solutions; è un progetto sviluppato dall’Università di Bonn ed è
rilasciato sotto licenza GPL11 (GNU General Public License).
Il progetto iniziò con l’intento di realizzare un framework per l’integrazione, basata su
standard OGC e ISO, di prodotti sviluppati da aziende diverse. Successivamente
cambiò la sua dicitura in Degree ed attualmente fornisce un elevato numero di
webservices OpenGIS per l’implementazione di Infrastrutture di Dati Territoriali (IDT)
e più nello specifico Web Map Service, Web Feature Service, Web Coverage
Service, Gazetteer Service, Catalog Service, Web Coordinate Transformation
Service e Web terrain Service.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 96 di 193
Architettura di Deegree
Figura 48: Portrayal Model (Cuthbert 1998)
L’architettura di Deegree è basata sul paradigma dei servizi e più nello specifico sugli
standard dell’OGC e ISO/TC 211. Per poter descrivere l’architettura di questo
software possiamo utilizzare il Portrayal Model (Cuthbert 1998). Tale modello
descrive il processo di produzione di carte attraverso quattro unità di processamento
e quattro componenti di rappresentazione (Figura 48).
Un processo di selezione di dati fornisce in output delle entità geografiche che hanno
determinate caratteristiche. Tutto ciò è alla base degli standard di geoprocessing
dell’OGC/ISO (OGC 1999).
La tecnologia dell’interfaccia dipende dalla piattaforma di elaborazione distribuita o
DCP (distributed computing platform). L’accesso ai dati vettoriali tramite CORBA,
SQL, o OLE/COM è fornito con implementazioni specifiche (Simple Features
Specification) mentre per quanto riguarda le applicazioni Web si utilizzano le
specifiche Web Feature Service Specification (WFS). Una tipica rappresentazione
per le entità e per un raggruppamento di entità è il Dataset GML (Geography Markup
Language).
Un Display Element Generator applicando le regole di stile alle entità produce in
uscita la rappresentazione grafica.
Tale rappresentazione mantiene naturalmente i vincoli e le direttive dell’OGC.
Attualmente un tipico software per la visualizzazione di immagini cartografiche è un
browser web. In Deegree ciascun processo, rappresentazione o vincolo è
rappresentato da una classe Java. In particolare ciascun servizio web di Deegre
implementa l’interfaccia org.deegree.services.OGCWebService. Di conseguenza
l’implementazione WMS è realizzata nella classe
org.deegree_impl.services.wms.WMService.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 97 di 193
L'interfaccia OGCWebService definisce semplicemente un metodo - doService (...) che riceve un oggetto OGCWebServiceEvent e avvia il processo di gestione della
richiesta WMS (GetCapabilities, GetMap, GetFeatureInfo). WMS è una applicazione
(org.deegree_impl.enterprise.WMSServlet), che agisce come un client per
WMService e offre le interfacce di connessione di rete.
Accesso ai dati
In linea con il Portrayal Model un WMS utilizza un filtro per accedere ai dati necessari
e quindi per rendere la mappa disponibile per l'esecuzione di GetFeatureInfo. Per
rendere particolarmente flessibile l’accesso ai dati Deegree WMS non implementa
inoltre classi specifiche, ma al contrario offre ad essi sia l’accesso tramite WFC che
WCS (org.deegree.services.filterservice package). Si possono utilizzare inoltre come
sorgente di dati per il WMS sia il WFS che il WCS.
Figura 49: Accesso ai dati in Deegree WMS
Ulteriori informazioni per quanto concerne la configurazione del WMS si trovano nell’
org.deegree.services.wms.capabilities packages. Se il client invia una richiesta
GetCapabilitis, le informazioni aggiuntive saranno filtrate dal documento delle
capacità prima che esso venga inviato al client. Nella figura seguente un Web
Coordinate Service (WCTS) è utilizzato per eseguire una trasformazione di
coordinate.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 98 di 193
Figura 50: Web Coordinate Service (WCTS)
Figura 51: I servizi offerti da Degree
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 99 di 193
Attualmente Deegree è arrivato alla versione 2.1. Dopo più di 5 anni di continuo
sviluppo, il progetto è attualmente la più ampia applicazione di OGC / ISO standard
nel campo del Software Libero. In particolare sono stati portati avanti diffusi
miglioramenti dell’architettura, del modello a oggetti ed il supporto di Java 5. In
Deegree 2.1, vi sono OGC WebServices per Web Map Service (WMS) 1.1.1, Web
Feature Service (WFS) 1.1.0, Copertura Web Service (WCS) 1.0.0 e Web-Catalogo
Service Profilo (CSW) 2.0.0.
Oltre ai miglioramenti di architettura, Deegree 2.1 ha subito numerosi cambiamenti
per quanto riguarda gli utenti:
•
Installazione e configurazione sono state semplificate
•
Il software è stato implementato per la configurazione interattiva di WCS e
WFS
•
Compatibilità con GML 3.1, PostGIS 1.0 e Oracle spatial/locator
•
Fonti di dati multiple per gli strati WMS
•
Rendering dinamico all’interno di SLD
•
Alta qualità e grandi dimensioni di stampa attraverso Web Map Print Service
(WMPS)
Il download è possibile attraverso il sito internet
http://www.deegree.org/deegree/portal/media-type/html/user/anon/page/default.psml/
js_pane/download, da cui è possibile scaricare una versione di Deegree 2.1 e delle
versioni precedenti (più stabili).
Nome
deegree Web Map Service
(WMS)
Versione
scaricabile
Documentazione
ZIP (157 MB) PDF | go to
| MD5
HTML docs
deegree Web Feature Service ZIP (17 MB) | PDF | go to
(WFS)
MD5
HTML docs
deegree Web Coverage
Service (WCS)
| MD5
HTML docs
Implementazioni
OGC-Standard
WMS 1.1.1 / WMS
1.3
WFS 1.1
WCS 1.0
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 100 di 193
deegree Catalogue Service
(CSW)
ZIP (17 MB) | PDF | go to
MD5
HTML docs
deegree Web Terrain Service
(WTS) / Web Perspective View
| MD5
HTML docs
Service (WPVS)
CSW 2.0.0
Discussion Paper;
Pre-Standard
Tabella 1: Deegree OGC 2.1 - Web Services - Server Side
Nome
Versione
scaricabile
Documentazione
Implementazioni
OGC-Standard
deegree Web Map
Service (WMS)
ZIP (48 MB) |
MD5
PDF | go to HTML
docs
WMS 1.1.1
deegree Web Feature
Service (WFS)
ZIP (22 MB) |
MD5
PDF | go to HTML
docs
WFS 1.1
deegree Web Coverage
Service (WCS)
ZIP (45 MB) |
MD5
PDF | go to HTML
docs
WCS 1.0
deegree Catalogue
Service (CSW)
ZIP (15 MB) |
MD5
PDF | go to HTML
docs
CSW 2.0.0
Tabella 2: Deegree OGC 2.0 - Web Services - Server Side
L’uso congiunto di Degree e GeoServer permette di implementare tutte le
componenti essenziali alla realizzazione di una un’Infrastruttura di Dati Territoriali
(IDT), intesa come un insieme di politiche, accordi istituzionali, tecnologie, dati e
persone che collaborano nel rendere possibile la condivisione ed un uso efficiente ed
efficace dell’Informazione Geografica (IG) stessa secondo specifiche e standard
internazionalmente riconosciuti.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 101 di 193
MAPSERVER
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 102 di 193
Introduzione
UMN MapServer (http://mapserver.gis.umn.edu/) è un ambiente di sviluppo open source che
permette la realizzazione di applicazioni e servizi web per la rappresentazione,
l’interrogazione e la restituzione di dati geospaziali provenienti da sistemi GIS.
Lo sviluppo del software è iniziato nell’ambito del progetto "ForNet" ed è stato curato
dell'University of Minnesota (UMN), della National American Space Agency (NASA) e del
Minnesota Department of Natural Resources (MNDNR) per poi proseguire per mano dello
stesso MNDNR e del Minnesota Land Manager Information Center (LMIC). Attualmente lo
sviluppo di MapServer è affidato all'University of Minnesota (UMN) e ad un consorzio di enti
operanti nell'ambito della gestione ambientale e territoriale all'interno del progetto "TerraSip"
finanziato dalla NASA. L'ultima versione rilasciata il 28/01/08 è la 5.0.2
Il progetto MapServer aderisce all'Open Source Geospatial Foundation (OSGEO http://www.osgeo.org): questa fondazione ha come obiettivo di incoraggiare l'uso e lo
sviluppo collaborativo dei progetti open source che ne fanno parte.
Dal punto di vista dell'ambiente di funzionamento di tratta di un software molto versatile:
avendo a disposizione il codice sorgente, scritto in linguaggio C, diventa possibile compilare
e quindi utilizzare MapServer su qualsiasi sistema operativo che abbia un compilatore C
(linux, Unix, MAC, Windows,...).
Inoltre, disponendo di volontà e indirizzando opportunamente le risorse a disposizione,
diventa possibile realizzare modifiche, personalizzazioni, curare e controllare direttamente lo
sviluppo del software, creando il presupposto per la crescita di competenze: obiettivi non
raggiungibili utilizzando un software close source.
Sono comunque a disposizione i binari compilati per diversi sistemi operativi, come ad
esempio Mac OS X, Windows e diverse distribuzioni Linux (come gli RPM di Fedora o
Gentoo).
Per quanto riguarda l'accesso ai dati, MapServer è in grado di leggere un gran numero di
formati, sia vettoriali, che raster:
●
vettoriali: shapefile, PostGIS, ESRI ArcSDE, Oracle Spatial, MySQL e altri mediante
la libreria OGR (vedere Tabella 3);
●
raster: TIFF/GeoTIFF, EPPL7 e altri mediante la libreria GDAL (vedere Tabella 4).
La libreria GDAL/OGR (http://www.gdal.org/) è una importante libreria open source che
fornisce gli strumenti software per accedere a molti formati di dati, sia raster che vettoriali; è
utilizzata da molti software open source (GRASS, gvSIG, MapGuide,...) e non (ArcGIS,
Google Earth,...): http://trac.osgeo.org/gdal/wiki/SoftwareUsingGdal. Anche il progetto
GDAL/OGR aderisce alla fondazione OSGEO.
MapServer implementa inoltre diversi standard dell'Open Geospatial Consortium (OGC:
http://www.opengeospatial.org/):
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 103 di 193
●
Web Map Service (WMS) sia client, quindi accesso ai dati di un altro servizio per poi
pubblicarli, che server, per fornire il servizio di pubblicazione;
○
●
Web Feature Service (WFS), sia client che server, nella implementazione nontransactional;
○
●
versione supportata: 1.0.0.
Styled Layer Descriptor:
○
●
versione supportata: 2.1.2 e 3.1.0.
Web Map Context Documents;
○
●
Geography Markup Language (GML);
○
●
Web Coverage Server (WCS), servizio come server;
○
●
versioni supportate: 1.0.0, 1.0.7, 1.1.0 e 1.1.1.
versione supportata: 1.0.0
Filter Encoding Specification:
○
versione supportata: 1.0.0
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 104 di 193
Nome formato
Codice
Arc/Info Binary Coverage
AVCBin
Atlas BNA
BNA
Comma Separated Value (.csv)
CSV
DODS/OPeNDAP
DODS
ESRI Personal GeoDatabase
PGeo
ESRI ArcSDE
SDE
ESRI Shapefile
ESRI Shapefile
FMEObjects Gateway
FMEObjects Gateway
GeoJSON
GeoJSON
Géoconcept Export
Geoconcept
GML
GML
GMT
GMT
GPX
GPX
GRASS
GRASS
INTERLIS
"Interlis 1" e "Interlis 2"
KML
KML
Mapinfo File
MapInfo File
Microstation DGN
DGN
Memory
Memory
MySQL
MySQL
OGDI Vectors
OGDI
ODBC
ODBC
Oracle Spatial
OCI
PostgreSQL
PostgreSQL
S-57 (ENC)
S57
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 105 di 193
SDTS
SDTS
SQLite
SQLite
UK .NTF
UK. NTF
U.S. Census TIGER/Line
TIGER
VRT - Virtual Datasource
VRT
X-Plane/Flighgear aeronautical data
XPLANE
Informix DataBlade
IDB
Tabella 3: Formati vettoriali supportati tramite la libreria OGR
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 106 di 193
Nome formato
Codice
Arc/Info ASCII Grid
AAIGrid
ADRG/ARC Digitilized Raster Graphics
(.gen/.thf)
ADRG
Arc/Info Binary Grid (.adf)
AIG
AIRSAR Polarimetric
AIRSAR
Magellan BLX Topo (.blx, .xlb)
BLX
Microsoft Windows Device Independent
Bitmap (.bmp)
BMP
BSB Nautical Chart Format (.kap)
BSB
VTP Binary Terrain Format (.bt)
BT
CEOS (Spot for instance)
CEOS
DRDC COASP SAR Processor Raster
COASP
TerraSAR-X Complex SAR Data Product
COSAR
Spot DIMAP (metadata.dim)
DIMAP
First Generation USGS DOQ (.doq)
DOQ1
DODS / OPeNDAP
DODS
New Labelled USGS DOQ (.doq)
DOQ2
Military Elevation Data (.dt0, .dt1, .dt2)
DTED
ERMapper Compressed Wavelets (.ecw)
ECW
ESRI .hdr Labelled
EHdr
NASA ELAS
ELAS
ENVI .hdr Labelled Raster
ENVI
Envisat Image Product (.n1)
Envisat
EOSAT FAST Format
FAST
FITS (.fits)
FITS
GSat File Format
GFF
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 107 di 193
Graphics Interchange Format (.gif)
GIF
WMO GRIB1/GRIB2 (.grb)
GRIB
GMT Compatible netCDF
GMT
GRASS Rasters
GRASS
Golden Software ASCII Grid
GSAG
Golden Software Binary Grid
GSBG
Golden Software Surfer 7 Binary Grid
GS7BG
TIFF / GeoTIFF (.tif)
GTiff
GXF - Grid eXchange File
GXF
Hierarchical Data Format Release 4 (HDF4)
HDF4
Hierarchical Data Format Release 5 (HDF5)
HDF5
Intergraph Raster
INGR
Vexcel MFF2
HKV
Idrisi Raster
RST
Image Display and Analysis (WinDisp)
IDA
ILWIS Raster Map (.mpr,.mpl)
ILWIS
JAXA PALSAR Product Reader
(Level 1.1/1.5)
JAXAPALSAR
Japanese DEM (.mem)
JDEM
JPEG JFIF (.jpg)
JPEG
JPEG2000 (.jp2, .j2k)
JPEG2000
JPEG2000 (.jp2, .j2k)
JP2KAK
JPEG2000 (.jp2, .j2k)
JP2ECW
JPEG2000 (.jp2, .j2k)
JP2MrSID
NOAA Polar Orbiter Level 1b Data Set
L1B
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 108 di 193
(AVHRR)
Erdas 7.x .LAN and .GIS
LAN
Daylon Leveller Heightfield
Leveller
In Memory Raster
MEM
Vexcel MFF
MFF
Multi-resolution Seamless Image Database
MrSID
Meteosat Second Generation
MSG
NDF
NLAPS Data Format
NITF
NITF
NetCDF
netCDF
OGDI Bridge
OGDI
PCI .aux Labelled
PAux
PCI Geomatics Database File
PCIDSK
Portable Network Graphics (.png)
PNG
PCRaster (.map)
PCRaster
Netpbm (.ppm,.pgm)
PNM
Swedish Grid RIK (.rik)
RIK
RadarSat2 XML (product.xml)
RS2
ArcSDE Raster
SDE
Raster Product Format/RPF (a.toc)
RPFTOC
USGS SDTS DEM (*CATD.DDF)
SDTS
Raster Matrix Format (*.rsw, .mtw)
RMF
SAR CEOS
SAR_CEOS
SGI Image Format
SGI
SRTM HGT Format
SRTMHGT
USGS ASCII DEM (.dem)
USGSDEM
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 109 di 193
Terragen Heightfield (.ter)
TERRAGEN
TerraSAR-X Product
TSX
GDAL Virtual (.vrt)
VRT
OGC Web Coverage Server
WCS
OGC Web Map Server
WMS
X11 Pixmap (.xpm)
XPM
Tabella 4: Formati raster supportati tramite la libreria GDAL
Funzionamento
È possibile utilizzare MapServer in due modalità base:
1. generazione delle pagine HTML tramite chiamata al programma mapserv (directory
/cgi-bin) ⇒ modalità MapServer CGI
2. utilizzo di linguaggi di script per la generazione delle pagine HTML dinamiche e
accesso ai servizi di MapServer tramite chiamate alle API ⇒ modalità MapScript
In modalità MapServer CGI (Figura 52) viene chiamato direttamente il programma mapserv
in /cgi-bin/ che riceve in ingresso:
●
i parametri con lo stato corrente della navigazione;
●
i parametri con l'azione che l'utente vuole compiere (zoom in, zoom out,
interrogazioni,...);
●
l'elenco dei layer che si vuole visualizzare/interrogare
Queste informazioni sono fornite al programma tramite una form, che viene di volta in volta
composta in base allo stato di navigazione dell'utente. Questa form e tutta l'interfaccia grafica
di navigazione che permette all'utente di richiedere i servizi di MapServer è definita in uno
speciale file HTML che viene chiamato Template file. Questo file viene utilizzato da
MapServer come base per la generazione delle pagine HTML dinamiche che vengono
restituite in base alle richieste dell'utente.
Sulla base dei dati ricevuti in ingresso MapServer va a leggere il Mapfile nel quale sono
definite le proprietà e le modalità di visualizzazione dei dati da pubblicare, come ad esempio
la definizione di layer, colori, simboli, scala di visualizzazione, attributi interrogabili,...
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 110 di 193
In base a queste informazione MapServer accede al proprio archivio dati, estrae le
informazioni di interesse e genera i file temporanei con le immagini da restituire all'utente
navigatore insieme alla pagina HTML costruita a partire dal Template file.
In modalità MapScript (Figura 53) diventa possibile utilizzare diversi linguaggi di script
(PHP, Perl, Python e Ruby) per accedere alle C API di MapServer:
●
PHP/Mapscript => PHP
○
●
http://mapserver.gis.umn.edu/docs/reference/phpmapscript-class
SWIG MapScript => Perl, Python, Ruby, Java
○
http://mapserver.gis.umn.edu/docs/reference/mapscript
In questo caso lo scambio di informazioni tra utente navigatore e server non avviene più
tramite una chiamata al software in /cgi-bin/ MapServer.
Le pagine a cui accede l'utente navigatore saranno delle pagine miste, HTML+script. Grazie
alle librerie MapScript si avranno a disposizione, oltre alle funzioni del linguaggio di script
che si sta utilizzando, anche delle funzioni che permettono di richiamare le API di MapServer
per visualizzare gli oggetti (carte, legenda,...) e quindi di integrare questi oggetti all'interno
delle pagine.
Figura 52: schema in modalità MapServer CGI
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 111 di 193
Figura 53: schema in modalità MapScript
Il Template file
Il Template file definisce la struttura base per la generazione delle pagine dinamiche
all'interno delle quali saranno messi a disposizione dell'utente navigatore gli strumenti di
navigazione/interrogazione del webGIS e i contenuti richiesti. Questo Template file è
utilizzato quando si lavora in modalità MapServer CGI. Si tratta di una semplice pagina
HTML (Figura 54) all'interno della quale sono contenute delle variabili (identificate dalle
parentesi quadre): MapServer legge questo file e genera la pagina da restituire all'utente
navigatore sostituendo alle variabili il valore assunto nella sessione corrente (Figura 55).
http://mapserver.gis.umn.edu/docs/reference/templatereference
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 112 di 193
Figura 54: Template file
Figura 55: pagina generata a partire dal Template file di Figura 54
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 113 di 193
Il Mapfile
Si tratta di un file di testo nel quale sono definiti degli oggetti e i loro parametri in modo tale
da determinare le modalità di visualizzazione di una carta: il Mapfile è quindi costituito da
oggetti strutturati in modo gerarchico come mostrato in Figura 56.
La definizione di un oggetto inizia con il nome dell'oggetto e termina con la parola chiave
END. All'interno di ogni oggetto possono essere definiti altri oggetti o dei parametri che
qualificano le proprietà dell'oggetto in un certo modo.
In Figura 57 è riportato un estratto di un Mapfile; possiamo evidenziare:
●
l'oggetto map con la definizione dei parametri generali della carta; in questo oggetto
sono contenuti tutti gli altri oggetti del map file;
●
l'oggetto web: con la definizione dei template e delle directory di sistema;
●
l'oggetto reference con la definizione delle caratteristiche della carta di riferimento,
cioè dove si trova l'immagine da utilizzare, di che colore fare il riquadro che evidenzia
l'area corrente, ...
http://mapserver.gis.umn.edu/docs/reference/mapfile
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 114 di 193
POINTS (n)
MAP
SYMBOL
STYLE (n)
LEGEND
LABEL
SCALEBAR
LABEL
REFERENCE
METADATA
PARAMETER (n)
QUERYMAP
FEATURE (n)
POINTS (n)
LAYER (n)
GRID
JOIN
OUTPUT FORMAT
PROJECTION
STYLE (n)
PROJECTION
CLASS (n)
LABEL
WEB
METADATA
PARAMETER (n)
Figura 56: Organizzazione gerarchica degli oggetti nel Mapfile
Figura 57: esempio di Mapfile
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 115 di 193
Implementazione dello standard WMS in MapServer
In base alle regole contenute nel documento redatto dall’Open Geospatial Consortium
possiamo classificare MapServer, in base alle operazioni supportate, come Queryable WMS
in quanto supporta anche le funzioni di interrogazione e non solo quelle di visualizzazione
(Basic WMS).
Il Web Map Service è supportato a partire dalla versione 3.5 di MapServer e si rifà allo
standard definito Open Geospatial Consortium. La versione più recente della direttiva di
riferimento “Open Geospatial Consortium (OGC) Web Map Server Interfaces Implementation
Specification”, sulla quale si basa MapServer, è la 1.1.1 ma sono supportate anche le
precedenti (1.0, e 1.1).
Lo standard OGC-WMS 1.3, necessario per essere conformi alla direttiva europea Inspire,
sarà introdotto in MapServer 5.2, il cui rilascio è previsto per il luglio 2008.
Dalla versione 4.6 di MapServer il servizio WMS è stato ampliato con la realizzazione del
supporto dei documenti Styled Layer Descriptor (SLD) in concomitanza con la definizione di
filtri attraverso lo standard “OpenGis Filter Encoding Implementation Specification”.
MapServer supporta le seguenti richieste WMS:
●
GetCapabilities ⇒ restituisce un documento XML con le informazioni generali che
riguardano il servizio offerto;
●
GetMap ⇒ restituisce una immagine in base alle richieste inoltrate dal client;
●
GetFeaturesInfo ⇒ restituisce informazioni sulle feature interrogate (text/plain formato testo, text/html – in HTML secondo quanto stabilito nei template delle query,
GML – nel formato GML);
●
DescribeLayer ⇒ restituisce un documento XML con la descrizione dei layer
pubblicati;
●
GetLegendGraphic ⇒ restituisce una immagine con i simboli grafici utilizzati.
MapServer è in grado di funzionare sia come server WMS (http://mapserver.gis.umn.edu/
docs/howto/wms_server), cioè di offrire il servizio ai client che lo richiedono, sia di essere
client WMS (http://mapserver.gis.umn.edu/docs/howto/wms_client), cioè di andare a fare
delle richieste ad un server WMS, ottenere i dati e pubblicarli a sua volta insieme ai suoi dati
locali (cascading).
Implementazione dello standard WFS in MapServer
Un Web Feature Service è un interfaccia che permette la richiesta, l'interrogazione e la
modifica di feature geografiche attraverso il web utilizzando piattaforme indipendenti.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 116 di 193
Si può affermare che se un servizio WMS fornisce una rappresentazione grafica del dato, un
servizio WFS fornisce il dato stesso.
La geometria dei dati restituiti è descritta tramite la composizione di più elementi geometrici
semplici (punto, linea, polilinea e poligono) ai quali corrispondono classi di geometrie
definite seguendo le specifiche del linguaggio GML (Geography Markup Language).
MapServer permette di implementare un servizio WFS seguendo la specifica “Web Feature
Service Implementation Specification Version: 1.0.0” redatta dall’Open Geospatial
Consortium. Lo standard OGC-WFS 1.1 sarà introdotto in MapServer 5.2, il cui rilascio è
previsto per il luglio 2008.
Offrire dati di tipo feature significa fornire all’utente sia la struttura geometrica, sia l’insieme
di attributi legati all’entità geografica, mediante uno specifico formato di interscambio.
MapServer è in grado di restituire dati di tipo feature in due formati: GML2 (2.1.2) e GML3
(3.1.0).
MapServer supporta le seguenti richieste WFS:
●
GetCapabilities ⇒ restituisce un documento XML con le informazioni generali che
riguardano il servizio offerto;
●
GetFeature ⇒ restituisce un documento XML con la geometria e gli attributi della
feature richiesta;
●
DescribeFeatureType ⇒ restituisce un documento XML con la descrizione della
feature richiesta.
MapServer implementa le funzioni base di un WFS: non sono implementate le richieste di
modifica delle features Transaction e LockFeature.
MapServer è in grado di funzionare sia come server WFS (http://mapserver.gis.umn.edu/
docs/howto/wfs_server), cioè di offrire il servizio ai client che lo richiedono, sia di essere
client WFS (http://mapserver.gis.umn.edu/docs/howto/wfs_client), cioè di andare a fare delle
richieste ad un server WFS, ottenere i dati e pubblicarli a sua volta insieme ai suoi dati locali
(cascading).
Implementazione dello standard WCS in MapServer
Il Web Coverage Service supporta lo scambio di dati geospaziali definiti "coverage"
(copertura) che consistono in informazioni digitali georeferenziate rappresentanti fenomeni
che variano nello spazio ed, eventualmente, nel tempo.
Un server WCS deve essere dunque in grado di fornire l’accesso a insiemi di dati geospaziali,
potenzialmente complessi e molto dettagliati, nei formati richiesti dal client per una semplice
visualizzazione o per l’inserimento in modelli scientifici di analisi.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 117 di 193
Il servizio WCS è paragonabile al Web Feature Service in quanto non si preoccupa di fornire
una rappresentazione statica del dato come il Web Map Service, ma il dato sorgente stesso in
formati ben definiti. Il Web Coverage Service permette dunque di estrapolare, tramite
interrogazioni complesse, porzioni di dati geospaziali (coverage) restituendo direttamente le
informazioni in formati validi per l'interpretazione e l'analisi da parte del client o
eventualmente da altri Web Service.
La sostanziale differenza con il Web Feature Service consiste nella tipologia del dato
sorgente. Un server WFS fornisce feature discrete ovvero “oggetti territoriali” dove lo spazio
viene considerato vuoto se non dove risulta essere popolato da entità caratterizzate da una
posizione, una forma ed attributi ben definiti. In una coverage lo spazio non può essere
considerato vuoto in quanto rappresenta in maniera continua un fenomeno che può assumere
valori nulli in caso di assenza ma che risulta essere considerato in ogni caso esistente.
MapServer permette di implementare un Web Coverage Service secondo le norme dettate
dallo standard OGC “Web Coverage Server (WCS) version 1.0.0”.
Un server WCS implementato con MapServer supporta tre operazioni:
•
GetCapabilities ⇒ fornisce informazioni sul servizio fornito e sui dati (coverage)
disponibili sul server;
•
DescribeCoverage ⇒ fornisce informazioni riguardanti una o più coverage disponibili
sul server;
•
GetCoverage ⇒ creazione dell'insieme dei dati di interesse e restituzione di questi
ultimi in un formato specifico.
MapServer è in grado di funzionare come server WCS:
(http://mapserver.gis.umn.edu/docs/howto/wcs_server).
Chameleon
È un ambiente distribuito e personalizzabile per lo sviluppo di applicazioni web
(http://chameleon.maptools.org/), scritto in linguaggio PHP.
E' stato realizzato dalla società canadese DM Solution (http://www.dmsolutions.ca/)
utilizzando MapServer come motore tramite la libreria PHP/MapScript.
Per sviluppare un'applicazione web basata su Chameleon è neccessario definire:
●
un Mapfile, come al solito, per la definizione delle proprietà dei dati da pubblicare;
●
un Template file, che ha però una struttura diversa da quello utilizzato da MapServer
in modalità CGI, per la definizione della pagina da pubblicare.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 118 di 193
Utilizzando Chameleon le applicazioni WebGIS possono essere velocemente implementate
tramite l’utilizzo di frammenti di codice precompilati (widget) che possono essere richiamati
all’interno di documenti HTML realizzando un’efficace interfaccia utente.
Ciascuna widget è implementata attraverso il linguaggio di programmazione PHP e, dato che
il codice sorgente è libero, può essere facilmente personalizzata rendendo Chameleon
un’applicazione molto versatile.
All’interno del Template le widget sono identificate dal tag CWC2 e dall’attributo type che
ne specifica la funzionalità. Per ogni widget devono essere definiti dei parametri di
configurazione che permettono di determinarne sia l’aspetto grafico che il comportamento.
Sono attualmente disponibili un centinaio di widget classificate secondo il criterio di “livello
di maturità”:
●
Product Release: sviluppo della widget completo, assenza di bug noti, ampiamente
testate, documentate in modo completo;
●
Tecnical Release: sviluppo della widget completo, assenza di bug noti, ampiamente
testate, documentazione incompleta;
●
Release Candidate: sviluppo della widget completo, sono noti alcuni bug minori, test
da completare, documentazione scarsa;
●
Beta: widget in fase di sviluppo, funzionalità implementate in modo completo,
principali bug corretti, assenza di documentazione;
●
Alpha: widget in fase di sviluppo, funzionalità non ancora completamente
implementate, assenza di documentazione;
●
Unknown: livello base di inizio sviluppo di una widget.
Ad ogni widget corrisponde dunque una determinata funzione: quando la pagina viene
richiesta dall'utente navigatore, Chameleon sostituisce alle widget del Template file (Figura
58) il codice generato dalla funzione corrispondente che varia a seconda dello stato in cui ci si
trova (Figura 59).
E' possibile inoltre creare delle nuove widget introducendo così nuove funzioni pronte per
essere utilizzate nelle applicazioni web.
http://chameleon.maptools.org/
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 119 di 193
Figura 58: Template per Chameleon
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 120 di 193
Figura 59: pagina generate in base al template di Figura 58
Appendice 1: software conformi allo standard WMS 1.3
Si riporta in Tabella 5 l'elenco dei software conformi allo standard OGC-WMS 1.3 alla data di
redazione di questo documento. La compatibilità con questa versione dello standard è
importante perché è la versione presa come riferimento dalla direttiva europea Inspire.
In questa tabella è stato messo in evidenza anche se il software citato implementa lo standard
lato client, server o entrambi.
Fonte: http://www.opengeospatial.org/resource/products/byspec.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 121 di 193
Società / Nome software
versione server
client
Cadcor - http://www.cadcorp.com/
Cadcorp SIS Active Server Component
6.2
si
si
Cadcorp SIS Map Server
6.2
si
si
si
si
CARIS - http://www.caris.com/
CARIS Spatial Fusion Enterprise
4.2.1
con terra-Applied Information Technologies - http://www.sdi-suite.de/
sdi.suite mapClient
2.1
no
si
CubeWerx - http://www.cubewerx.com/
CubeSERV Cascading Web Map Server
4.6
si
no
CubeXPLOR
4.6
no
si
Google Earth Extension for WMS
1.0
si
no
si
no
si
si
si
no
Generic Logic - http://www.genlogic.com/
GLG Map Server
2.10
Manifold Net - http://www.manifold.net/
Manifold System
6.50
Newgrove - http://www.newgrove.com/
Address Caf
4.2
SuperMap GIS Techonologies - http://www.supermap.com.cn/
SuperMap Deskpro
5.3
no
si
Tabella 5: software conformi allo standard OGC-WMS 1.3
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 122 di 193
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 123 di 193
GEODATABASE
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 124 di 193
Introduzione
Questa sezione del documento tratta dell'utilizzo di alcuni software per la gestione
dei database contenenti informazioni geografiche. In generale i tipi di informazione
trattabili sono in formato raster e vettoriale. I dati, in entrambi i formati, di norma
possono essere editati e caricati nei database tramite software GIS tipo desktop, e in
alcuni casi con applicazioni di tipo WEB-GIS. Le operazioni di consultazione e
visualizzazione dei dati possono essere eseguite sia tramite software di tipo desktop
che tramite applicazioni di tipo WEB-GIS.
Normalmente i software GIS permettono di accedere alle tabelle degli attributi degli
oggetti vettoriali quando utilizzano formati semplificati, come gli shape-file della ESRI
e i file .mif e .tab di MapInfo. Nel caso specifico le informazioni vengono scritte
separatamente per quanto riguarda gli attributi geometrici degli oggetti geografici e la
loro parte semantica, cioè gli attributi veri e propri.
In effetti i gestori di database più potenti permettono di strutturare compiutamente
tutte le informazioni che descrivono gli oggetti geografici allocando i relativi dati in
tabelle opportunamente relazionate fra loro. Pur non garantendo sempre il massimo
della velocità di accesso alle informazioni rispetto ad alcuni formati (es. Shape file) la
gestione degli oggetti geografici tramite database server professionali garantisce il
rispetto di alcuni requisiti fondamentali relativi all'utilizzo delle banche dati:
–
agevole accessibilità anche da remoto;
–
possibilità di eseguire query complesse, usufruendo della flessibilità e della
potenzialità del linguaggio SQL;
–
univocità e limitazione della ridondanza del dato;
–
affidabilità;
–
ottimizzazione nella gestione di banche dati molto grandi;
–
accesso multiutente, così da gestire al meglio i permessi e le modalità di accesso
ai dati.
Alcuni software GIS e WEB-GIS permettono di conseguire una gestione complessa
dell'informazione geografica quando la stessa è archiviata tramite database
professionali dotati di estensioni spaziali. Dalla precedente indagine relativa ai
progetti posti in essere dalle Regioni italiane per la gestione dell'informazione
geografica è emerso che i software tipo RDBMS “Relational DataBase Management
System“ più utilizzati sono:
–
Postgres con estensione spaziale PostGIS;
–
ORACLE 11g (versione “Enterprise”) con estensione SPATIAL.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 125 di 193
Il flusso operativo di funzionamento del sistema, sia per la implementazione e
modifica dalla rete interna, che per la fruizione da una rete pubblica, è illustrato in
Figura 62.
Figura 60: Flusso operativo di utilizzo del sistema
Diverse società che realizzano DBMS hanno integrato nel loro sistema anche delle
estensioni che permettono di gestire dati di tipo geografici.
PostGIS è un estensione spaziale di PostgreSQL (completamente open-source), che
permette di gestire oggetti geografici. Seguendo lo standard OGC, in tale estensione
sono implementati dei tipi che rappresentano delle primitive geometriche come punti,
linee, poligoni, multi linee, multi poligoni, . . . , grazie ai quali si hanno tutti gli
strumenti per poter trattare dei dati vettoriali. Inoltre sono state implementate le
funzioni che permettono di eseguire le operazioni topologiche più comuni come
intersezioni e sovrapposizioni. L'ultima versione rilasciata di PostGIS è la 1.3.3.
ORACLE SPATIAL è un componente di Oracle che supporta la gestione di dati
geografici. Esso fornisce dei tipi che implementano le primitive geometriche
seguendo le specifiche OGC. Oltre ai tipi primitivi per i dati vettoriali, SPATIAL
implementa anche un modello per la gestione dei dati raster, denominato
GEORASTER.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 126 di 193
POSTGIS
PostGIS è l’estensione spaziale di POSTGRES che permette di gestire database spaziali;
sviluppato da Refractions Research Inc., PostGIS supporta interamente le funzionalità di
OpenGIS e funzioni topologiche avanzate. Fornisce inoltre gli strumenti per l’importazione e
l’esportazione dei dati e integra anche strumenti basati sull’accesso WEB.
PostGIS segue le specifiche dell’OpenGIS Consortium (OGC) e pertanto, tramite un
opportuno tipo oggetto, ne supporta le primitive geometriche, quali le “Simple
Features”. Oltre ai tipi previsti dall'OGC PostGIS ha esteso le sue funzionalità anche
ad altri tipi di oggetti spaziali, di seguito descritti.
I Simple Features vengono rappresentati utilizzando due metodologie: la Well-Known
Text (WKT) e la Well-Known Binary(WKB).
La WKT è una rappresentazione testuale delle Features e in PostGIS sono le
seguenti:
•
POINT(X Y)
•
LINESTRING(X1 Y1,X2 Y2,…,X(N-1) Y(N-1), X(N) Y(N))
•
POLYGON((X1 Y1,X2 Y2,…,X(N-1) Y(N-1), X(N) Y(N)) , (X1 Y1,X2 Y2,
…,X(N-1) Y(N-1), X(N) Y(N)))
•
MULTIPOINT(X1 Y1,X2 Y2,…,X(N-1) Y(N-1), X(N) Y(N))
•
MULTILINESTRING((X1 Y1,X2 Y2,…,X(N-1) Y(N-1), X(N) Y(N)), (X1 Y1,X2
Y2,…,X(N-1) Y(N-1), X(N) Y(N)))
•
MULTIPOLYGON(((X1 Y1,X2 Y2,…,X(N-1) Y(N-1), X(N) Y(N)), (X1 Y1,X2 Y2,
…,X(N-1) Y(N-1), X(N) Y(N))) , ((X1 Y1,X2 Y2,…,X(N-1) Y(N-1), X(N) Y(N))))
•
GEOMETRYCOLLECTION(POINT(X Y),LINESTRING((X1 Y1,X2 Y2,
…,X(N-1) Y(N-1), X(N) Y(N)))).
Quando bisogna inserire queste simple feature nel nostro database si deve creare
una tabella con una colonna che sia del tipo geometrico previsto da PostGIS, che
deve fare riferimento a un SRID, come nell’esempio seguente:
SELECT AddGeometryColumn( ’mia_tabella’, ’strada’, 3004, ’LINESTRING’, 2 );
Per inserire le feature in questa tabella si deve usare uno dei metodi di
rappresentazione previste da OGC, cioè WKT o WKB. PostGIS mette a disposizione
delle interfacce che permettono di eseguire l'input/output delle feature utilizzando uno
dei metodi previsti dalla OGC le seguenti:
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 127 di 193
 bytea WKB = asBinary(geometry);
 text WKT = asText(geometry);
 geometry = GeomFromWKB(bytea WKB, SRID);
 geometry = GeometryFromText(text WKT, SRID);
Di seguito sono riportati degli esempi di operazioni di input e output utilizzando la
rappresentazione WKT:
INPUT
INSERT INTO mia_tabella (nome_strada, strada)
VALUES (‘SS118’,
GeometryFromText(‘LINESTRING(2 2, 4 6,….,200 289)’,3004)
);
OUTPUT
SELECT asText(strada)
FROM mia_tabella
WHERE nome_strada=’SS118’;
Oltre al tipo di primitive che un geodatabase deve supportare, l'OGC indica anche
quali metadati devono essere opportunamente trattati. Relativamente a tali
indicazioni, PostGIS utilizza due tabelle:
•
SPATIAL_REF_SYS
•
GEOMETRY_COLUMNS
La tabella SPATIAL_REF_SYS contiene i metadati che riguardo i sistemi di
coordinate utilizzati nel database spaziale, con valori numerici e descrizioni testuali.
È definita come segue:
srid
auth_name
auth_srid
srtext
proj4text
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 128 di 193
 SRID è il codice che serve ad identificare il sistema di coordinate;
 AUTH_NAME è l’autore del sistema di coordinate (es. EPSG);
 AUTH_SRID è il codice identificativo che è stato stabilito dalle autorità per il
sistema di coordinate di un determinato territorio;
 SRTEXT è la rappresentazione testuale del sistema di coordinate attraverso la
WKT. Un esempio di rappresentazione del sistema di coordinate in tale
formato è il seguente:
PROJCS["NAD83 / UTM Zone 10N",
GEOGCS["NAD83",
DATUM["North_American_Datum_1983",
SPHEROID["GRS 1980",6378137,298.257222101]
],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433]
],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",-123],
PARAMETER["scale_factor",0.9996],
PARAMETER["false_easting",500000],
PARAMETER["false_northing",0],
UNIT["metre",1]
]
La tabella GEOMETRY_COLUMNS contiene tutti i metadati del layer che stiamo
inserendo nel database tramite una tabella che contiene le 'Simple Feature'; anche in
questo caso il contenuto è conforme agli standard indicati dall'OGC. La struttura della
tabella GEOMETRY COLUMNS è la seguente:
f_table_catalog f_table_schema f_table_name f_geometry_column coord_dimension Srid type
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 129 di 193
●
f_table_catalog, f_table_schema, f_table_name: scompongono il nome
completo della tabella che contiene la geometria attraverso il nome del
catalogo e del schema di cui la tabella fa parte;
●
f_geometry è il nome della colonna geometrica che contiene le features;
●
coord_dimension indica la dimensione spaziale della feature. Le feature
possono essere a 2,3 o 4 dimensioni;
●
Srid indica il sistema di coordinate associato alla feature;
●
Type indica il tipo di feature che rappresenta la colonna geometrica, ovvero:
punto, linea, poligono, multipunto, multilinea, multipoligono, gruppo di
geometrie, ecc.
La struttura di un database spaziale in Postgis è abbastanza semplice. Le uniche
tabelle di metadati sono solo due, e sono relazionate con la tabella che contiene le
feature di un layer che si vuole archiviare.
Ogni tabella che contiene le feature è inserita nella tabella Geometry_column in
modo che si possa tenere traccia di tutte le tabelle che contengono le feature, e
quale sia la loro colonna geometrica. Inoltre in geometry_column viene indicato il
sistema di riferimento associato alla feature e la definizione di tale sistema è
contenuta nella tabella spatial_ref_sys.
Nella figura seguente è rappresentato uno schema di database spaziale in Postgis.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 130 di 193
Figura 61: schema di database spaziale in Postgis
Postgis prevede anche un'indicizzazione della colonna geometrica, per migliorare le
prestazioni delle query spaziali, mediante un indice del tipo GisT.
Import/export delle feature
L'inserimento dei dati può essere fatto sia tramite SQL utilizzando la sintassi WKT,
sia mediante vari tool specialistici che si interfacciano con l'architettura POSTGIS e
permettono di recuperare ed inserire i dati. Una delle operazioni principali è quella di
importare ed esportare dati in formato shape, che viene spesso utilizzato come
standard per i dati vettoriali.
POSTGIS fornice dei tool, a riga di comando, per l'importazione dei dati shape:
●
shp2pgsql per l'importazione degli shape file;
●
pgsql2shp per l'esportazione dal database spaziale al formato shape.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 131 di 193
Il comando di importazione necessita di alcuni flag, che rappresentano le opzioni di
importazione dello shape file:
●
-d cancella la tabella prima di importare i dati e creare una tabella nuova;
●
-a i dati contenuti in shape file vengono aggiunti ad una tabella geometrica già
esistente;
●
-c crea una nuova tabella geometrica che conterrà le feature dello shape file;
●
-P con questa modalità verrà solo creato lo schema della tabella geometrica e
non vi sarà alcuna importazione di dati;
●
-D carica i dati da un dump PostgreSQL e va utilizzato assieme ai parametri -a
o -c;
●
-s è il parametro SRID delle feature contenute nello shape file;
●
-k identifica il formato (maiuscolo o minuscolo) del nome degli attributi dello
shape file;
●
-i forza i valori nel file .dbf dello shape file allo standard di interi a 32 bit;
●
-I create un indice spaziale GiST;
●
-w il formato dell'uscita sarà WKT;
●
-W specifica la codifica dei dati contenuti nel .dbf (ad esempio UTF).
Di seguito viene illustrato un esempio di utilizzo del comando shp2pgsql, che deve
essere avviato dal prompt dei comandi:
#shp2pgsql -s 3004 -I C:\shape\abruzzo_centri_abitati.shp abruzzo_centri_abitati > abruzzo.sql
I parametri principali sono l'indicazione del sistema di riferimento da adottare, il
percorso dello shape file, il nome della tabella che conterrà il layer e il nome dello
script sql generato.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 132 di 193
Il comando sopra indicato genera uno script sql che dovrà successivamente essere
eseguito affinché venga creata la tabella e popolata con le relative feature. Questa
operazione si effettua lanciando il comando psql con la seguente sintassi:
# psql -d salvogis -U postgres -h localhost -f abruzzo.sql
tra i parametri di psql abbiamo indicato quelli relativi alla connessione del database e
quelli relativi allo script sql da eseguire.
L'importazione può comunque essere effettuata accorpando i comandi sopra indicati
in un'unica stringa che genera ed esegue direttamente lo script:
>C:\Programmi\PostgreSQL\8.3\bin>shp2pgsql -s 3004 -I
abruzzo_centri_abitati | psql -d salvogis -U postgres -h localhost
C:\shape\abruzzo_centri_abitati.shp
Dopo avere eseguito l'operazione di importazione del file shape, è possibile
consultare la tabella di Postgis che contiene le feature utilizzando un viewer che
implementa i driver di connessione a PostGis.
Uno di questi viewer è GvSig che, come si evince dalla seguente figura 62, mostra
quali feature sono disponibili per il caricamento nella banca dati Postgis, e fra questi
vi è il layer appena caricato:
Figura 62: elencazione dei layer disponibili con il software GvSig
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 133 di 193
GvSig esegue operazioni di importazione, editing, aggiornamento e esportazione dei
dati. Un esempio di visualizzazione dati tramite GvSig è riportato nella figura 63:
Figura 63: visualizzazione dei dati in GvSig
La lettura dei dati può essere fatta anche tramite delle query sql che estraggono la
colonna che contiene le feature.
Postgis fornisce anche, come detto in precedenza, un tool a linea di comando per
l'esportazione nel formato shape, denominato pgsql2shp. Come per shp2pgsql
anche questo tool ha dei flag per la scelta delle opzioni di esportazione:
●
-f indica il nome del file shape di uscita;
●
-h indica il server dove risiede il database a cui connettersi per estrarre lo
shape file;
●
-p indica la porta tcp dove il server Postgres è in ascolto;
●
-P viene utilizzata per inserire la password necessaria per un'eventuale
autenticazione di accesso;
●
-u indica l'utente con cui ci si connette al database spaziale;
●
-g identifica la colonna geometrica che è contenuta nella tabella che si
desidera estrarre;
Una sintassi del comando può essere la seguente:
# pgsql2shp -h localhost
abruzzo_centri_abitati
-u
postgres
-g
geom
-f
abruzzo_centri_abitati.shp
salvogis
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 134 di 193
oltre a questi due strumenti da linea di comando esistono altri software sviluppati da
software house di sviluppo CAD o desktop GIS, le quali hanno fornito i loro prodotti
di driver per gestire database spaziali in Postgis. Esistono anche software open
source, sviluppati da università, enti pubblici, comunità di ricerca, ecc..., in grado di
interfacciarsi con PostGIS.
Postgis fornisce il supporto per effettuare operazione con le tabelle contenenti le
feature. Queste operazioni possono essere eseguite attraverso diversi gruppi di
funzioni, che sono raggruppate in base al tipo di operazione che effettuano. Di
seguito sono riportati i diversi gruppi di funzioni fornite da Postgis.
Funzioni di Postgis
“Management functions” sono le funzioni che permettono di inserire la colonna
geometrica in una tabella che dovrà contenere delle feature (es. la funzione vista
negli esempi precedenti addgeometrycolumn).
“Geometry relationship” sono delle funzioni che permettono di eseguire delle
operazioni spaziali e in particolare di individuare le relazioni topologiche fra le varie
entità geometriche. Attraverso queste funzioni è possibile eseguire delle query
spaziali, che individuano delle feature che soddisfano relazioni topologiche come
l'intersezione, il contatto, il contenimento, ecc... .
Il nome di queste funzioni è del tipo “ST_xxx”; alcune di queste sono:
●
ST_Intersects (geometry,geometry) è un funzione che permette di verificare
se esiste una relazione topologica di intersezione tra le due geometrie passate
come argomenti;
●
ST_Touches (geometry,geoemetry) è un funzione che verifica se i contorni
delle due geometrie si toccano;
●
ST_Contains (geometry A, geometry B) è un funzione che controlla se la
geometria A è contenuta topologicamente nella geometria B.
“Geometry processing function” è un pacchetto di funzioni che eseguono delle
operazioni per calcolare delle proprietà geometriche, come calcolo dell'area, della
lunghezza, del perimetro, del centroide e varie altre operazioni.
“Geometry accessors” sono delle funzioni che permettono di eseguire operazioni
generiche di diversa utilità, come estrarre la dimensione di una feature, il tipo e la
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 135 di 193
validità di una feature e altre operazioni che possono essere utili durante
l'elaborazione o l'estrazione dei dati.
“Geometry construct” sono funzioni che forniscono un modo per creare le feature ed
inserirle nel database spaziale. Alcune delle principali funzioni sono:
●
ST_GeomFromText (text,srid) crea una feature qualsiasi dalla formattazione
WKT;
●
ST_PointFromText (text,srid) crea un punto da WKT;
●
ST_LineFromText (text,srid) crea una linea da WKT.
“Geometry Editor” sono un pacchetto di funzioni che permettono la modifica delle
features, come inserimento, modifica e rimozione di un punto, trasformazione affine
di una geometria, trasformazione del sistema di coordinate di riferimento.
Postgis non ha ufficialmente un supporto per i dati raster. Esistono comunque delle
estensioni, che non seguono fedelmente le indicazioni dell'OGC per quanto riguarda i
dati raster. Su diversi forum inerenti a Postgis vengono fornite delle indicazione su
come gestire i dati raster, ma al momento non fornisce per tale tipo di dati un
supporto completo.
Tra le estensioni che permettono di archiviare i raster meritano una nota particolare i
driver pgchip, che forniscono una interfaccia tra le librerie GDAL e Postgis. I driver
pgchip di basano sul tipo CHIP già esistente in Postgis; si installano ricompilando le
librerie GDAL, inserendo un supporto per interfacciare le gdal con Postgis,
permettendo così alle librerie gdal di caricare dati raster nel database Postgis. Il
limite della versione attuale di pgchip, oltre al fatto che si tratta di software non
ancora in versione definitiva, è costituito dal limitato numero di formati supportati e
dal supporto parziale alle conversioni fra sistemi di riferimento.
ORACLE SPATIAL
Oracle SPATIAL (comunemente denominata solo SPATIAL) è un estensione di
Oracle enterprise edition (ultima versione è 11g 11.1.0.6.0) che fornisce tipi e schemi
SQL che permettono di gestire, memorizzare, aggiornare dati geografici con tutte le
loro caratteristiche.
Spatial è composto da:
●
uno schema che descrive il tipo geometrico la sua sintassi e semantica utilizza
per rappresentare le caratteristiche geografiche;
●
meccanismi di indicizzazione dei dati geometrici;
●
operatori e funzioni;
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 136 di 193
●
supporto per dati raster.
Nella prima parte della descrizione di Oracle spatial si tratterà di come vengono
gestite le geometrie spaziali e dell'oggetto sdo_geometry, che spatial utilizza per
rappresentarli. Mentre nella seconda parte si descriverà il supporto dei dati raster.
Geometrie spaziali (shape)
Oracle SPATIAL supporta i tipi di dati indicati dall'OGC ( OpenGIS Consortium ) che
ha stabilito degli standard per la rappresentazione di dati geografici con le relative
geometrie. Essi sono:
●
punti;
●
linee;
●
poligoni;
●
archi;
●
poligoni di archi;
●
poligoni composti;
●
linee composte;
●
circonferenze;
●
rettangoli;
SPATIAL dà il supporto a questi tipi di dati attraverso l'oggetto sdo_geometry.
sdo_geometry è un oggetto Oracle che ha gli attributi e i metodi necessari per
trattare i tipi geometrici indicati dall'OGC.
I dati geometrici formano un layer. Un Layer è insieme di geometrie che
rappresentano elementi di territorio quali servizi a rete, punti di interesse, zone di
riserva ecc.
Ogni layer è rappresentato in Oracle Spatial da una tabella. La tabella deve
contenere una colonna che sia del tipo sdo_geometry che come indicato prima è
l'oggetto realizzato da Oracle per rappresentare i dati di tipo geometrico.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 137 di 193
Attributo 1
Attributo 2
SHAPE(SDO_GEOMETRY)
Aa1
Bb1
sdo_geometry(poligono)
Aa2
Bb2
sdo_geometry(poligono)
Figura 64: archiviazione dei dati in Oracle
Il codice SQL che crea la tabella è il seguente:
CREATE TABLE cola_markets (
attributo 1id NUMBER PRIMARY KEY,
attributo 2 VARCHAR2(32),
shape SDO_GEOMETRY);
)
La colonna shape quindi è un oggetto sdo_geometry. L'oggetto sdo_geometry ha
una struttura che è in grado di contenere tutte le informazioni che sono necessarie
per individuare una primitiva geometrica. Si veda lo schema della tabella di un layer.
Attributi vari Colonna
sdo_geometr
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 138 di 193
y
sdo_geometry
sdo_gtype
sdo_srid
sdo_point
sdo_elemen_info
sdo_ordinates
Tabella Layer
●
Sdo_gtype indica il tipo di geometria (punto, linea, poligono, ecc..) e la
dimensione della dalla geometria (2,3 o 4).
●
sdo_srid è usato per identificare il sistema di coordinate associato all'oggettto
geometrico.
●
sdo_point viene utilizzato per indicare le coordinate X , Y , Z se il dato
geometrico è un punto.
●
sdo_elemen_info è un insieme di attributi utilizzati per interpretare le
coordinate d'oggetto geometrico.
●
sdo_ordinates sono le coordinate dell'oggetto geometrico.
Per inserire un oggetto sdo_geometry si utilizza il relativo costruttore. Ecco un
esempio di un possibile script SQL di inserimento di una geometria:
INSERT INTO layer VALUES(
2,
--attributi vari
'geoemtria',
--attributi vari
SDO_GEOMETRY(
2003, -- two-dimensional polygon
NULL,
NULL,
SDO_ELEM_INFO_ARRAY(1,1003,1), -- one polygon (exterior polygon ring)
SDO_ORDINATE_ARRAY(5,1, 8,1, 8,6, 5,7, 5,1)
)
);
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 139 di 193
SPATIAL utilizza anche i format WKT e WKB di rappresentazione delle geometrie
stabiliti da OGC.
La gestione dei metadati indicati dall'OGC è strutturata attraverso alcune tabelle che
contengono tutte le informazioni necessarie.
Le tabelle principali sono:
●
USER_SDO_GEOM_METADATA
●
ALL_SDO_GEOM_METADATA
le tabelle sopra indicate contengono:
●
il nome dell'utente proprietario del layer
●
il nome della tabella che fa riferimento al layer
●
il nome della colonna che viene utilizzata per memorizzare le primitive
geometriche
●
la dimensione spaziale del layer
●
il sistema di coordinate utilizzato per quel layer.
Esse sono le tabelle di riferimento per tutte le applicazioni che desiderano conoscere
il contenuto del geodatabase.
SPATIAL per migliorare le prestazioni, l'efficienza e l'efficacia ha implementato un
indice di tipo R-TREE utilizzato per indicizzare l'oggetto SDO_GEOMETRY.
Attraverso tale indice vengono migliorate le prestazioni di recupero dei dati durante le
varie query, in quanto le geometrie vengono approssimate con dei rettangoli minimi
che contengono l'intera geometria in modo da semplificare l'ordine computazionale di
geometrie complesse.
Figura 65: Indice Spaziale R-TREE
tutte le informazioni degli indici spaziali presenti in un database spaziale sono
contenute nelle tabelle:
USER_SDO_INDEX_INFO
e
USER_SDO_INDEX_METADATA.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 140 di 193
Per quanto riguarda il sistema di coordinate Oracle SPATIAL si basa sul modello
EPSG Tale modello offre i vantaggi della relativa standardizzazione dei sistemi di
riferimento. SPATIAL fornisce delle tabelle che si basano sul modello EPSG le quali
contengono tutte le informazioni riguardanti il sistema di coordinate: le tabelle sono:
●
SDO_COORD_SYS,
SDO_COORD_REF_SYS
informazioni generali del sistema di coordinate.
che
contengono
le
●
SDO_DATUMS,
SDO_ELLIPSOIDS,
SDO_PRIME_MERIDIANS
contengono elementi per la definizione del sistema di coordinate
●
SDO_COORD_OPS, SDO_COORD_OP_METHODS,
SDO_COORD_OP_PARAM_USE, SDO_COORD_OP_PARAM_VALS,
SDO_COORD_OP_PARAMS, SDO_COORD_OP_PATHS,
SDO_PREFERRED_OPS_SYSTEM, SDO_PREFERRED_OPS_USER.
Contengono informazioni utili per effettuare la trasformazione del sistema di
coordinate.
●
SDO_COORD_AXES,SDO_COORD_AXIS_NAMES,SDO_UNITS_OF_MEAS
URE. Contengono ulteriori dati per la definizione del sistema di coordinate.
che
La struttura di un database spaziale in Oracle è composta quindi da diverse tabelle,
che permettono di archiviare un grande volume di dati che sono associati a dei layers
e quindi a delle geometrie spaziali.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 141 di 193
Figura 66: schema del geodatabse in Oracle
Oracle SPATIAL supporta il tipo ST_xxx ISO 13249-3 , Information technology Database languages - SQL Multimedia and Application Packages - Part 3: Spatial.
Quindi è previsto un tipo ST_geometry che è il tipo principale che viene utilizzato per
gestire le geometrie e al suo interno contiene dei sotto tipi che individuano le varie
primitive geometriche:
●
ST_CIRCULARSTRING
●
ST_COMPOUNDCURVE
●
ST_CURVE
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 142 di 193
●
ST_CURVEPOLYGON
●
ST_GEOMCOLLECTION
●
ST_LINESTRING
●
ST_MULTICURVE
●
ST_MULTILINESTRING
●
ST_MULTIPOINT
●
ST_MULTIPOLYGON
●
ST_MULTISURFACE
●
ST_POINT
●
ST_POLYGON
●
ST_SURFACE
La potenzialità di SPATIAL è che il tipo ST_Geometry è interoperabile con
SDO_GEOMETRY e che quindi può essere utilizzato nelle modalità dell'oggetto
SDO_GEOMETRY.
Per creare quindi un oggetto del tipo ST_GEOMETRY si può utilizzare il costruttore
di SDO_GEOMTRY:
ST_GEOMETRY(geom SDO_GEOMETRY);
Importazione dei dati
Un aspetto fondamentale dei database spaziali è l'importazione dei nei vari formati di
dati spaziali e in particolare del formato SHAPE di ESRI che è diventato oramai uno
standard per i dati vettoriali. Esistono diversi strumenti per l'importazione dei dati
forniti sia da Oracle stesso sia da terzi.
I due strumenti d'importazione nativi in Oracle sono:
1. shp2sdo è un applicativo da linea di comando che permette di importare lo
shape nel database spaziale di Oracle utilizzando il tipo sdo_geometry.
2. MapBuilder è un applicativo java desktop grafico che permette di importare gli
shape nel database Oracle SPATIAL, definire le classi di visualizzazione, e
avere una preview dei dati importati.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 143 di 193
Shp2sdo converte i dati shape in SDO_GEOMETRY. Ecco un esempio di come va
utilizzato questo programma.
Dato uno shape che contiene le ferrovie di un determinato territorio lo si vuole
importare nel database spaziale con il suo .dbf associato. Per fare ciò bisogna
lanciare il seguente comando dal prompt:
shp2sdo.exe c:\shape\ferrovia_ptpr-naso ferrovia -g geometry -d -x (-100,100) -y (-100,100) -s
3004 -t 0.05
Figura 67: esecuzione di shp2sdo.exe
●
c:\shape\ferrovia_ptpr-naso è lo shape che si vuole inserire nel database;
●
ferrovia è il nome che verrà assegnato alla tabella spaziale;
●
-g geometry è il nome della colonna che sarà del tipo SDO_geometry che conterrà le
geometrie dello shape;
●
-d mette i dati associata allo shape in un control file che verrà successivamente caricato;
●
-x la dimensione orizzontale della regione di riferimento;
●
-y la dimensione verticale della regione di riferimento;
●
-s indica il sistema di riferimento EPSG;
●
-t indica la tolleranza che le geometrie possono avere.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 144 di 193
Figura 68: output dell'esecuzione di shp2sdo.exe
Il comando shp2sdo.exe crea uno script SQL che contiene la definizione della tabella
spaziale e un control file che contiene i dati associati allo shape. Questi file sono i
seguenti:
●
●
ferrovia.sql (script sql)
ferrovia.ctl (control file che contiene i dati associati allo shape)
Il passo successivo consiste nell'eseguire lo script che crea la tabella spaziale e
successivamente importare il control file che contiene i dati spaziali.
//esecuzione dello script
sqlplus system/salvatore@//localhost:1521/salvo @ferrovia.sql
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 145 di 193
Figura 69: caricamento dei dati
//caricamento del control file
sqlldr system/salvatore@//localhost:1521/salvo control=ferrovia.ctl
a questo punto i dati relativi allo shape 'ferrovia_ptpr-naso.shp' risulteranno caricati in
Oracle SPATIAL.
Lo strumento grafico per eseguire le stesse operazioni è MapBuilder.
In MapBuilder l'importazione avviene prima con la connessione al database spaziale
come mostrato nella figura70
Figura 70: connessione al database spaziale con MapBuilder
dopo di che si utilizza le funzione di importazione dal menù TOOLS.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 146 di 193
Figura 71: importazione di dati con MapBuilder
Provando a visualizzare i dati acquisiti si ottiene la seguente visualizzazione
Figura 72: visualizzazione dei dati con MapBuilder
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 147 di 193
Oltre agli strumenti forniti da Oracle esistono diversi software Desktop-GIS che si
interfacciano con vari database spaziali tra cui Oracle SPATIAL. Uno di questi è
GvSig che è un software Java free open source sviluppato da Conselleria
d'Infraestructures i Transport di Valencia. Con questo strumento tramite un apposito
plug-in java si ha la possibilità di importare ed esportare i livelli informativi in diversi
formati.
La prima operazione da eseguire è la connessione con il database spaziale
utilizzando i driver di connessione per Oracle come in figura 73.
Figura 73: impostazione della connessione con GvSig
Il passo successivo è la lettura del file shape che si desidera importare:
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 148 di 193
Figura 74: caricamento dati shape con GvSig
L'ultimo passo è quello eseguire la funzione esporta dal menù 'layer' scegliendo
l'esportazione verso il database Oracle.
Figura 75: esportazione dei dati con GvSig verso Oracle
una volta caricati i dati sono fruibili da GvSig stesso come mostrato nella figura 76
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 149 di 193
Figura 76: visualizzazione di dati da geodatabase Oracle con GvSig
ovviamente questo è solo uno dei diversi software open source e commerciali atti ad
esportare dati shape in Oracle SPATIAL.
Esportazione dati
Come per l'importazione dei dati in Oracle esistono diversi tools sia open source sia
commerciali che permettono di esportare i dati in un formato diverso da Oracle
SPATIAL. Per quanto riguarda la Oracle stesso non esistono tools che esportano in
altri formati.
Per raggiungere tale scopo uno dei software è il già citato GvSig, che grazie hai suoi
plug-in è in grado, una volta acquisito il layer da Oracle, di esportarlo in ulteriori
formati quali Postgis, Shape, ecc..
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 150 di 193
Figura 77: esportazione dati con GvSig
In figura 77 vediamo un esempio di come sia possibile esportare i layer contenuti in
Oracle nei diversi formati previsti da GvSig (attualmente i formati di esportazione
sono: SHP, Postgis, DXF, annotazione, GML, KLM).
Una volta visualizzato il layer si procede all'esportazione selezionando 'esporta' dal
menù 'layer'.
Operazioni spaziali in Oracle
Oracle SPATIAL fornisce una serie di funzioni che permettono di eseguire
operazioni spaziali su oggetti sdo_geometry (definiti secondo lo standard OGC) tra
cui operazioni topologiche, trasformazioni di sistema di coordinate, calcolo di
proprietà geometriche e altri pacchetti che offrono diversi pacchetti.
Essi sono:
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
spatial operators
spatial aggregate function
SDO_CS Package (coordinate System Transformation)
SDO_CSW_PROCESS package (cws processing)
SDO_GCDR package (geocoding)
sdo_geom package (geometry)
sdo_lrs package (linear referencing system)
sdo_migrate package(upgrading)
sdo_ols package (openls)
sdo_pc_pkg package (point cloud)
sdo_sam package (spatial anlysis and mining)
sdo_tin_pkg package (TINs)
sdo_tune package (tuning)
sdo_utili package (utility)
sdo_wfs_lock package (WFS)
sdo_wfs_process package (WFS processing)
Spatial operator
Questo pacchetto fornisce delle funzioni che permettono di mettere in relazione le
entità spaziali che sono dentro il database. Le relazioni possibili si basano sulla
posizione degli oggetti. Le più importanti relazioni tra oggetti sono quelle topologiche.
Oracle SPATIAL per individuare il tipo di relazione che intercorre fra le entità spaziali
(contatto, intersezione, ecc.) utilizza il NINE-INTERSECTION MODEL. La figura 78
mostra un esempio di questo modello.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 151 di 193
Figura 78: nine intersection model
Oracle individua le seguenti relazioni topologiche fra gli oggetti spaziali:
●
disjoint: i due elementi spaziali non si intersecano;
●
touch: i contorni dei due elementi spaziali si toccano;
●
overlapbdydisjoint: le parti interne degli elementi si intersecano mentre non si
toccano i contorni dei due elementi. Questa relazione si verifica quando una
linea si interseca con un poligono;
●
overlapbdyintersect: i contorni e la parte interna degli oggetti si intersecano;
●
equal: le due entità sono uguali;
●
contains: un elemento spaziale si trova all'interno di un altro elemento
spaziale;
●
covers: un elemento spaziale è contenuto all'interno di un altro elemento
spaziale e i loro contorni si intersecano;
●
inside: è l'opposto di contains;
●
coverdby: è l'opposto di covers;
●
on: la parte interna e il contorno di un elemento è sul contorno di un altro
elemento;
●
Anyinteract: non esiste nessuna relazione fra le due entità spaziali.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 152 di 193
Figura 79: relazioni topologiche
Attraverso questi operatori si possono eseguire delle query spaziali, tramite le quali si
estraggono gli elementi spaziali in base a delle operazioni effettuate sugli elementi
stessi.
Per esempio, dati due layer, uno che contiene le curve di livello di una regione
(comune_10m) e un layer che contiene i limiti comunali, (comuni-naso), si desidera
estrarre i comuni che stanno al di sopra dei 200 metri. Grazie agli operatori spaziali è
possibile fare ciò e la query SQL è la seguente:
SELECT DISTINCT A.comune //seleziona i comuni che soddisfano la clausola where
FROM comuni_naso A, curve_10m B
WHERE(sdo_overlapbdydisjoint(A.geometry,B.geometry)='TRUE'
OR sdo_contains(A.geometry,B.geometry)='TRUE' )
AND B.contour>200
nella clausola WHERE si indica di estrarre solo i comuni che si intersecano o
contengono con le curve di livello al di sopra dei 200 metri.
Spatial aggregate function
Questo pacchetto contiene delle funzioni che permettono di aggregare un insieme di
elementi spaziali. L'esempio che segue è una query che fa delle operazioni di
aggregazione:
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 153 di 193
SELECT SDO_AGGR_UNION(SDOAGGRTYPE(c.shape, 0.005))
FROM cola_markets c WHERE c.name <> 'cola_d';
SDO_CS Package (coordinate System Transformation)
Questo pacchetto contiene le funzioni per gestire, modificare, inserire i sistemi di
coordinate. Vi sono delle funzioni che eseguono la trasformazione del sistema di
riferimento geografico di un layer.
SDO_CSW_PROCESS package (cws processing)
fornisce funzioni che supportano e quindi gestiscono un servizio CWS.
SDO_GCDR package (geocoding)
fornisce delle funzioni utili per il servizio di Geocoding.
SDO_GEOM package (geometry)
Questo pacchetto contiene funzioni che individuano svariate proprietà geometriche
dell'entità spaziale. Per ogni entità si può calcolare l'area, distanze da altri oggetti,
centroide dell'entità spaziale oppure creare una nuova entità spaziale da operazioni
di unione, intersezione e differenza.
SDO_LRS package (linear referencing system)
fornisce delle funzioni che creano, modificano, interrogano e convertono i sistemi di
riferimento lineare (LRS - Linear Referencing Systems).
SDO_MIGRATE package(upgrading)
permette di importare i dati delle versioni precedenti di Spatial.
SDO_OLS PACKAGE (openls)
contiene il supporto per l'openLS.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 154 di 193
SDO_PC_PKG PACKAGE (point clouds)
fornisce delle funzioni che gestiscono una nuvola di punti.
SDO_SAM PACKAGE (spatial anlysis and mining)
pacchetto utilizzato per l'analisi spaziale e estrazione dati.
SDO_TIN_PKG PACKAGE (TINs)
pacchetto utilizzato per le operazioni su triangulated irregular network.
SDO_TUNE PACKAGE (tuning)
questo pacchetto contiene delle funzioni che servono per ottimizzare il database
spaziale (tuning).
SDO_UTIL package (utility)
pacchetto che fornisce varie funzioni che eseguono operazioni di tipo generico.
SDO_WFS_LOCK package (WFS) e SDO_WFS_PROCESS package (WFS
processing)
sono dei pacchetti che forniscono funzioni per il supporto dei web feature service.
Georaster Spatial
Georaster è una estensione di SPATIAL che supporta operazioni di archiviazione,
indicizzazione, interrogazione, analisi e esportazione di dati raster ed i metadati a
loro associati. Georaster fornisce ad Oracle Spatial un tipo di oggetto ed uno schema
relazionale mediante il quale vengono gestiti i dati raster, nonchè qualsiasi tipo di dati
che possono essere rappresentati mediante una griglia o matrice. Georaster è in
grado di gestire raster multidimensionali e multibanda; gestisce inoltre l'eventuale
sistema di riferimento geografico associato con il raster.
Il modello georaster di SPATIAL fornisce degli elementi per i dati raster e sono:
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 155 di 193
●
celle e pixel;
●
dominio spaziale;
●
informazioni di riferimento spaziali, temporali e di banda;
●
attributi delle celle;
●
metadati;
●
operazioni di elaborazione dei dati e supporto per le mappe.
Ogni raster viene rappresentato attraverso una matrice multidimensionale in cui ogni
cella ha un tipo associato e la dimensione in byte del valore associato. Oltre al valore
delle celle e alle sue proprietà associato ai raster ci sono i metadati, raggruppati in
base all'informazione che rappresentano. I metadati possono essere suddivisi come
segue:
●
informazioni sull'oggetto;
●
informazioni sul raster;
●
informazioni sul sistema di riferimento geografico;
●
informazioni su date e orari (temporal reference system);
●
informazioni sul sistema di riferimento delle bande;
●
informazioni di ogni layer che compone il raster;
per quando riguarda il sistema di riferimento dei raster vi sono due modelli di sistema
di coordinate:
●
il cell coordinate system, è il sistema di riferimento interno alla matrice, basato
sulla posizione di riga e colonna e con l'origine posta pari a (0, 0) sull'angolo
superiore sinistro;
●
il model coordinate system, è il sistema di georeferenzazione del raster e che
quindi da la posizione di ogni singolo raster sul sistema di riferimento globale.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 156 di 193
Figura 80: modelli di sistemi di coordinate
Nella figura 80 viene mostrato una rappresentazione del cell coordinate system (a
sinistra) e del model coordinate system, (a destra).
Per quando riguarda il cell coordinate system i pixel vengono rappresentati in base al
numero di riga e colonna e il valore della cella dipende dal modello spaziale che si
decide di adottare. In questo caso si hanno due modelli in cui:
●
ogni cella ha come riferimento il suo baricentro
●
ogni cella ha come riferimento l'angolo in alto a sinistra
Figura 81: modelli per il cell coordinate system
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 157 di 193
L'estensione Georaster, per migliorare l'efficienza di archiviazione dei dati raster,
divide il raster in blocchi di dimensione fissa e fa il padding dei blocchi che si trovano
vicino ai contorni con valori nulli, in modo da avere blocchi con la stessa dimensione
Georaster spatial per gestire i raster fornisce due tipi di dati che sono in grado di
gestire tutte le informazioni necessarie. I due tipi sono:
●
sdo_georaster. La tabella che contiene questo oggetto viene chiamata
GEORASTER TABLE;
●
SDO_RASTER . Contiene informazioni sui blocchi in cui si è diviso il raster. La
tabella di tipo sdo_raster viene chiamata Raster Data Table (RDT).
Figura 82: schema di archiviazione di un raster nel database
La city image è una tabella che contiene l'oggetto sdo_georaster; questo oggetto è il
tipo che contiene l'informazione spaziale del raster, e tutti i relativi metadati con
associato ovviamente il sistema di riferimento geografico. Inoltre ha un attributo
raster-id che serve ad individuare i blocchi che formano il raster relativo che sono
contenuti nella raster-data-table.
La figura 83 mostra la struttura completa di un georaster database, cioè un database
che contiene dei raster con i relativi metadati.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 158 di 193
Figura 83: struttura di un georaster database
sdo_georaster è un tipo definito dalla seguente sintassi SQL.
CREATE TYPE sdo_georaster AS OBJECT (
rasterType
NUMBER,
spatialExtent SDO_GEOMETRY,
rasterDataTable VARCHAR2(32),
rasterID
NUMBER,
metadata
XMLType);
rasterType indica il tipo di raster che si sta trattando
SpatialExtent fornisce le informazioni spaziali che riguardano il raster e quindi anche
il suo sistema di riferimento associato.
RasterDataTable è il nome della tabella che contiene i blocchi che formano il raster
rasterId viene utilizzato per individuare i blocchi all'interno della tabella rdt (raster
definition table) che formano un raster.
Metadata è un attributo formato xml che contiene i metadati relativi al raster.
L'importazione e l'esportazione dei dati raster può essere fatta tramite le API
PL/SQL. I formati supportati sono TIFF, GeoTIFF, JPEG, BMP, GIF, PNG, e JP2.
SDO_GEOR.importfrom è la funzione PL/SQL che importa il raster mentre
SDO_GEOR.exportTo è la funzione PL/SQL che esporta il raster.
Il tool mapbuilder, fornito dall'Oracle, permette l'importazione dei raster nel database
spaziale. Di seguito viene illustrato un esempio di funzionamento.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 159 di 193
Passo 1. scegliere import image dal menu tools.
Figura 84: Import raster in Mapbuilder
Passo 2. indicare il nome della tabella che conterrà il raster e il file che deve essere
importato
Figura 85: Step 1 di 2 di Import raster in Mapbuilder
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 160 di 193
Una volta inserita l'immagine è possibile visualizzarla selezionandola dall'archivio
georaster in MapBuilder, come visibile nella figura 86.
Figura 86: Raster Output in Mapbuilder
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 161 di 193
Tabella riassuntiva di confronto tra PostGIS e ORACLE SPATIAL
Installazione
PostGIS
Modalità e difficoltà L'installazione di PostGIS è
di installazione
molto semplice sia su Windows
che su LINUX. L'installazione
guidata indica quali servizi
bisogna installare affinché il
database funzioni correttamente.
ORACLE SPATIAL
L'installazione di ORACLE
SPATIAL è inclusa
nell'installazione di ORACLE
ENTERPRISE EDITION. È
meno intuitiva
dell'installazione di PostGIS,
poiché è prevista la
configurazione di alcuni
parametri e servizi che
necessitano di una
scrupolosa attenzione.
Documentazione
Tipologia di
documentazione
(PDF, HTML, ecc..)
e reperibilità
La documentazione fornita è
piuttosto scarsa. Vengono
elencate in modo generico le
funzionalità di PostGIS senza
scendere nei particolari del loro
funzionamento.
La documentazione è
abbastanza completa,
soffermandosi su ogni
caratteristica di SPATIAL e
di quello che può realizzare.
Sul sito della ORACLE è
possibile consultare una
guida di riferimento HTML
ben strutturata oppure
ottenere i PDF delle varie
guide.
Supporta i vari elementi
geometrici di un layer vettoriale:
Supporta i vari elementi
geometrici di un layer
vettoriale:
Funzionalità
Tipi vettoriale
1. punti
2. linee
3. poligoni
4. multipunti
1. punti
2. linee
3. poligoni
4. archi
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 162 di 193
5. multilinee
5. poligoni di archi
6. multipoligoni
6. poligoni composti
7. geometrie composte
(punti + linee, linee +
poligoni, ecc..)
7. linee composte
8. circonferenze
9. rettangoli
Operazioni
topologiche
Fornisce funzioni che
permettono di fare le operazioni
topologiche: inclusione,
intersezione, adiacenza, . . .
Fornisce funzioni che
permettono di fare le
operazioni topologiche:
inclusione, intersezione,
adiacenza, . . .
Operazioni
geometriche
Permette di eseguire il calcolo
della distanza delle geometrie,
l'unione, la differenza e le
intersezioni delle geometrie.
Permette di eseguire il
calcolo della distanza delle
geometrie, l'unione, la
differenza e le intersezioni
delle geometrie.
Proprietà delle
geometrie
Fornisce funzioni per il calcolo di Fornisce funzioni per il
aree, perimetri, centroidi,
calcolo di aree, perimetri,
lunghezza...
centroidi, lunghezza...
Gestione del
sistema di
coordinate
Supporta diversi sistemi di
riferimento, grazie alle librerie
proj4.
Supporta diversi sistemi di
riferimento.
Indicizzazione delle Permette di creare indici (del tipo Supporta un indice R-Tree
geometrie
GiST) sulle geometrie.
(approssimazione mediante
un rettangolo minimo di
contenimento) per le
geometrie.
Import e export dei Supporto per importare ed
dati vettoriali
esportare i dati vettoriali nel
formato shape ESRI
Supporto per importare ed
esportare i dati nel formato
shape ESRI
Supporto raster
Forniscono un supporto
completo per i dati raster,
prevedendo un modello
specifico integrato con una
serie di funzioni che
permettono di eseguire
svariate operazioni sui raster
Esistono diversi modi per il
supporto dei raster, ma ancora
non inclusi ufficialmente
all'interno di PostGIS in quanto
sono ancora in fase di
ultimazione. Alcune librerie che
forniscono supporto per i dati
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 163 di 193
raster sono:
●
PGCHIP che utilizza le
librerie 'gdal'.
●
PGRASTER di Xlin che
supportano l'importazione
e esportazione dei TIFF
monobanda.
Import e export dei Vari tools non standard che
raster
fanno uso delle librerie 'gdal'.
(anche multibanda).
SPATIAL supporta il modello
a piramidi per i raster.
I formati di importazione e
esportazione sono i
seguenti:
TIFF, GeoTIFF, JPEG, BMP,
GIF, PNG e JP2.
Operazioni sui
raster
Non fornite dalla distribuzione di Esistono diverse funzioni che
PostGIS.
permettono di analizzare il
contenuto delle celle dei
raster, di estrarre le
informazioni di interesse, di
impostare il contenuto di
alcune celle, ecc..
Servizi WEB
Non forniti.
Forniscono un supporto web
che prevede dei servizi che
danno un contributo
significativo alla piattaforma
web che si interfaccia con il
geo-DB.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 164 di 193
ArcSDE
Oltre ai database server prima descritti esiste una interessante applicazione, anch'essa
utilizzata in alcuni progetti delle regioni italiane per la gestione dell'informazione geografica,
denominata ArcSDE.
ArcSDE permette di allocare informazioni geografiche strutturate in modalità simile a quanto
fatto dalle estensioni spaziali dei database spaziali prima descritti, in tabelle di database server
che non sono dotati di apposite estensioni spaziali. Questo prodotto, denominato dal
produttore ESRI come application server, rappresenta a tutti gli effetti uno strumento di tipo
middleware, in quanto si interfaccia tra l'applicazione client e il DBMS che è in grado
di memorizzare i dati spaziali, facendosi carico della creazione e gestione dei tipi di
dati idonei alla rappresentazione dei dati spaziali. Il client interagisce solo con
ArcSDE e non si cura del come i dati verranno trattati nel DBMS.
CLIENT
ARCSDE
DBMS
ORACLE, DB2,
INFORMIX,SQLSERVER
Figura 87: architettura di ArcSDE
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 165 di 193
In questo progetto di ricerca si è utilizzato ArcSDE 9.2 con SQLserver desktop
engine 2000, che è il porting di SQLserver per Windows XP. La caratteristica
fondamentale di ArcSDE è appunto quella di potersi connettere a vari DBMS, e una
volta connesso l'applicazione client non si cura di gestire i dati nei vari formati dei
DBMS.
ArcSDE implementa tre tipi di geodatabase:
●
personal;
●
workgroup;
●
enterprise;
i primi due sono geodatabase abbastanza semplici che forniscono delle funzionalità
limitate e sono indicati per limitate quantità di dati e in ambienti con pochi utenti.
ArcSDE ENTERPRISE è una piattaforma completa e si integra con i DBMS
relazionali più noti; è quindi possibile usufruire di tutti i vantaggi di tali piattaforme,
quali la condivisione dei dati, l'archiviazione di grandi dati fino ai limiti fisici delle
macchine, sicurezza dei dati, possibilità di creazione di backup per il recupero dati,
ecc. .
In questo progetto si è ritenuto opportuno analizzare le funzionalità di ArcSDE
enterprise per illustrare le sue funzionalità in modo completo.
ArcSDE è in grado di gestire:
●
classi di feature (primitive geometriche per i dati vettoriali);
●
dati raster ;
●
tabelle
Le primitive supportate da ArcSDE sono:
●
punti, che sono le più piccole primitive geometriche rappresentabili;
●
linee, costituite da un insieme di punti connessi;
●
poligoni, costituite da un insieme di linee connesse;
●
annotazioni, ovvero informazioni testuali.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 166 di 193
Figura 88: primitive supportate da ArcSDE
ArcSDE utilizza la topologia dei dati per gestire le feature le cui primitive grafiche
sono condivise fra le feature stesse (oggetti). Oltre a questi tipi semplici sono previsti
i tipi composti:
●
multi-punto;
●
multi-linea;
●
multi-poligono.
Figura 89: tipi composti supportati da ArcSDE
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 167 di 193
Oltre agli elementi vettoriali ArcSDE supporta la gestione dei dati raster. I dati raster
vengono rappresentati con delle matrici, dove ogni elemento della matrice
corrisponde ad una cella o pixel ed ha il suo relativo valore.
Figura 90: archiviazione dei dati raster
I raster hanno associate anche altre informazioni che sono indispensabili per la loro
elaborazione e gestione. Tali informazioni sono le seguenti:
●
il sistema di coordinate associato al raster;
●
il punto di riferimento per le celle (di solito le coordinate del punto in alto a
sinistra);
●
le dimensioni della cella (il numero di bit di una cella);
●
le dimensioni del raster, rappresentate dal numero di righe e colonne.
Il fatto che i file raster possono rappresentare anche enormi estensioni territoriali,
può far sorgere il problema della gestione di grandi moli di dati; in tali condizioni le
operazioni di interrogazione ed estrazione dei dati potrebbero inficiare le prestazioni
del sistema. Per risolvere questo possibile inconveniente ArcSDE divide i dati raster
in blocchi di dimensione fissa, e quindi i raster vengono gestiti in parti più piccole in
modo tale da migliorarne l'efficienza nella gestione. I blocchi vengono memorizzati in
apposite tabelle e sono univocamente identificati affinché si possa risalire al raster di
appartenenza e quindi renderne possibile la sua ricostruzione. La figura 91 mostra
un scomposizione a blocchi dei dati raster.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 168 di 193
Figura 91: scomposizione a blocchi dei dati raster
Oltre ai dati geografici, come le feature e i raster, ArcSDE gestisce tutte le altre
tabelle che contengono attributi associati creando le eventuali associazioni.
Figura 92: relazioni fra tabelle in ArcSDE
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 169 di 193
La struttura di un geodatabase è costituita da un serie di tabelle. Alcune tabelle
contengono i dati delle features o dei raster, altre contengono gli attributi associati ai
dati geometrici; un ruolo particolare rivestono le System tables, che sono le tabelle
usate da ArcSDE per gestire i dati geografici, per tenere traccia delle tabelle
geometriche e per gestire i sistemi di riferimento dei dati geografici che vengono
inseriti nel geodatabase. Queste tabelle sono:
●
le feature table. La loro denominazione è costituita dalla lettera “f” seguita da
una cifra;
●
le spatial index table. La loro denominazione è costituita dalla lettera “s”
seguita da una cifra. Queste tabelle tengono informazioni sugli indici creati
sulle geometrie;
●
gdb_objectclasses;
●
sde_table_registry;
●
sde_layers;
●
sde_spatial_references.
La struttura del geodatabase è riassunta nella figura 93:
Figura 93: struttura del geodatabase
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 170 di 193
I dati geometrici vengono gestiti attraverso dei tipi idonei ad archiviarli. Alcuni DBMS
hanno dei tipi nativi e quindi ArcSDE utilizza questi tipi per gestire i dati, mentre per
altri DBMS, come SQLserver che non ha un tipo nativo per i dati geometrici, ArcSDE
utilizza il tipo blob, di solito utilizzato per archiviare dati binari. I possibili tipi sono:
●
st_geometry (DB2, Informix, Oracle);
●
sdo_geometry (Oracle con estensione oracle spatial);
●
blob (SQLServer, oracle).
Il tipo st_geometry è il tipo principale che al suo interno contiene dei sottotipi per
archiviare le primitive geometriche. La struttura del tipo st_geometry è riportata di
seguito:
Figura 94: struttura del tipo st_geometry
I dati raster vengono memorizzati divisi in blocchi, memorizzati in campi blob.
ArcSDE adotta le indicazioni dell'OGC relative alla rappresentazione dei dati
geografici attraverso i formati WKT (well-known text) e WKB (well-known binary).
Anche per quanto riguarda la rappresentazione del sistema di riferimento utilizza il
formato WKT:
PROJCS["NAD_1983_UTM_Zone_10N",
GEOGCS["GCS_North_American_1983",
DATUM["D_North_American_1983",SPHEROID["GRS_1980",6378137,298.257222101]],
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 171 di 193
PRIMEM["Greenwich",0],UNIT["Degree",0.0174532925199433]],
PROJECTION["Transverse_Mercator"],PARAMETER["False_Easting",500000.0],
PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",-123.0],
PARAMETER["Scale_Factor",0.9996],PARAMETER["Latitude_of_Origin",0.0],
UNIT["Meter",1.0]]
ArcSDE si interfaccia con i DBMS per fornire un servizio di gestione dei dati
geografici alle applicazioni client, e può anche interpretare i comandi sql che
provengono dal client.
I comandi sql per ArcSDE comprendono una suite di funzioni, che consentono una
serie di operazioni spaziali sulle varie geometrie.
Sql per ArcSDE fornisce:
●
procedure per la creazione di tabelle geometriche:
CREATE TABLE sensitive_areas (
area_id integer,
name varchar(128),
area_size float,
type varchar(10),
zone ST_Geometry)
●
Elemento geometrico
creazione di un nuovo sistema di riferimento:
INSERT INTO SDE.ST_SPATIAL_REFERENCES VALUES (
GCS_North_American_1983,
1,
-400,
-400,
1000000000,
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 172 di 193
-100000,
10000,
-100000,
10000,
9.999E35,
-9.999E35,
9.999E35,
-9.999E35,
9.999E35,
-9.999E35,
9.999E35,
-9.999E35,
WKT
4269,
'GCS_North_American_1983',
'PROJECTED',
NULL,
'GEOGCS["GCS_North_American_1983",DATUM["D_North_American_1983",SPHEROID["GRS_198
0",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]]',
'ArcSDE SpRef'
);
●
inserimento delle feature nella tabella con la colonna geometrica:
INSERT INTO sensitive_areas VALUES (
1,
'Summerhill Elementary School',
67920.64,
WKT
'school',
ST_PolyFromText('polygon ((52 28,58 28,58 23,52 23,52 28))',1));
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 173 di 193
●
creazione di indici spaziali;
●
aggiornamento e interrogazione dei dati geometrici;
●
operazioni topologiche;
●
ST_Intersects (g1 ST_Geometry, g2 ST_GEOMETRY): indica se due
geometrie di intersecano;
●
ST_Touches (g1 ST_Geometry, g2 ST_GEOMETRY): indica se due
geometrie si toccano;
●
operazioni di trasformazione del sistema di riferimento di una geometria;
●
ST_Transform (g1 ST_Geometry, SRID INTEGER) trasforma il sistema di
riferimento della geometria nell'SRID specificato come parametro;
●
operazioni di calcolo di proprietà geometriche: area, lunghezza, perimetro,
centroide, unione di geometrie, intersezione di geometrie, differenza di
geometrie.
ArcSDE è un prodotto che naturalmente si integra alla perfezione con gli altri prodotti
della ESRI. I prodotti ESRI hanno anche gli strumenti di importazione dei dati nel
geodatabase e naturalmente possono importare e esportare, nel database, anche gli
shape file. Inoltre i tool di Arcgis, in particolare ArcCatalog, sono anche in grado di
importare i dati raster dai vari formati grafici come jpg, jpeg2000, bmp, tif, ecc.
Oltre a questi tool, ArcSDE è già fornito di un tool di importazione (shp2sde) e
esportazione (sde2shp) attraverso la riga di comando.
Si illustrano di seguito alcuni esempi di importazione dei dati attraverso ArcCatalog. I
test di importazione sono stati effettuati con ArcSDE 9.2 con SQLserver desktop
engine 2000.
Il primo passo da eseguire è la creazione della connessione con il geodatabase,
come mostrato in figura 95:
Figura 95: Connessione al Db
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 174 di 193
dopo aver selezionato addSpatialDatabaseConnection, inserire i parametri di
connessione:
Figura 96: parametri di connessione
●
Server: indica l'indirizzo ip del server a cui si desidera connettersi;
●
Service: è il nome del servizio che è in ascolto per accettare eventuale
richieste di connessione. Esso viene attivato al momento di configurazione di
ArcSDE con il DBMS utilizzato (ORACLE, INFORMIX, DB2, SQLSERVER);
●
Database: è il nome del geodatabase;
●
Username: indica l'utente che si desidera connettere al geodatabase;
●
Password: indica la password necessaria per l'autenticazione dell'utente che
si desidera connettere.
Stabilita correttamente la connessione è possibile consultare il contenuto del
geodatabase.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 175 di 193
Figura 97: visualizzazione di dati archiviati con ArcSDE
Arccatalog ha un “arctoolbox”, dove sono contenuti tutti gli strumenti di gestione di un
geodatabase, inclusi quelli di importazione e di esportazione.
Per importare un file shape bisogna selezionare dalla toolbox gli strumenti di
conversione 'conversion tools' e poi 'to geodabase', e quindi scegliere la funzione di
importazione della feature class. Si apre quindi la finestra seguente:
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 176 di 193
Figura 98: finestra per l'importazione di file shape in ArcSDE
Si inseriscono nei vari campi i dati da importare e la destinazione, che in tal caso è
la connessione al geodatabase. Fatto ciò l'importazione è avvenuta con successo e i
dati sono ora disponibili nel geodatabase per l'esecuzione delle varie operazioni
spaziali.
Sempre nella ArcToolbox vi sono gli strumenti analoghi per effettuare l'esportazione
dei dati nel formato desiderato. Strumenti analoghi sono presenti per l'importazione e
l'esportazione dei dati raster.
Oltre a questo strumento grafico, fornito dall'applicativo Arcgis con licenza ArcInfo,
ArcSDE fornisce dei propri tools di importazione e esportazione, utilizzabili attraverso
la riga di comando.
Per il loro utilizzo bisogna aprire una console di comandi ed inserire la seguente
stringa:
shp2sde -o create -l curve_20m,geom -f curve_gb_20m_p.shp -g AUTOMATIC -a all -D sde -i
ESRI_sde -s apollo5 -u sde -p salvatore
le opzioni hanno il seguente significato:
- o crea una nuova tabella geometrica;
- l curve_20m2,geom indica il nome della tabella e il nome della colonna geometrica;
- f curve_gb_20_ è il nome (percorso) del file shape che si desidera importare;
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 177 di 193
- g AUTOMATIC serve per impostare il sistema di riferimento in modo automatico;
- a all indica che devono essere importati tutti gli attributi contenuti nel file dbf
associato al file shp;
- D sde indica il nome del geodatabase;
- i ESRI_sde è il nome del servizio che gestisce la connessione;
- s nome o indirizzo ip del server;
- u nome dell'utente che si desidera connettere;
- p la password necessaria per autenticare l'utente che si vuol connettere.
Figura 99: caricamento dati shape in ArcSDE da riga di comando
Oltre agli strumenti proprietari di ESRI esistono vari software realizzati da terzi, sia in
ambito opensource che in ambito commerciale, che sono in grado di interagire con la
piattaforma server di ESRI. Ciò è reso possibile dal fatto che ESRI mette a
disposizione delle librerie di sviluppo C e Java, che contengono le API per potersi
connettere al geodatabase attraverso ArcSDE e trattare i relativi dati contenuti in
esso.
Comparazioni riassuntive
Sulla base delle considerazioni fatte, a proposito dei diversi relational database
server con estensioni geografiche, più comunemente utilizzati, si riporta una tabella
riassuntiva al fine di avere un quadro sinottico delle caratteristiche dei diversi sistemi
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 178 di 193
POSTGRES
+
POSTGIS
Tipo di sistema
ORACLE 11g
+
SPATIAL
ARCSDE 9.2
DBMS server con DMBS server con Applicazione server
estensione spaziale estensione spaziale di tipo middleware
che interagisce con
vari DBMS.
DBMS supportati:
● ORACLE
● DB2
● INFORMIX
● SQLServer 2000
Vettoriali
Tipo di dato
ST_Geometry
(OGC)
Importazione dati
Tool
nativo
per Tool
nativi
per
l'importazione
di l'importazione
di
dati SHAPE (ESRI): dati SHAPE (ESRI):
● shp2pgsql
● shp2sdo
● MapBuilder
Tool non nativi di
PostGis forniti da Tool non nativi di
terzi:
Oracle forniti da
● Desktop
Gis terzi:
Open source
● Desktop
Gis
● Desktop
Gis
Open source
commerciali
● Desktop
Gis
commerciali
Esportazione dati
ST_Geometry
Dipende dal DBMS
utilizzato.
(OGC)
● ST_Geometry
● SDO_Geometry
(Oracle,
DB2,
SDO_Geometry e
Informix)
ST_Geometry sono
● BLOB
interoperabili
(SQLServer)
●
Tool nativo PostGis Tool non nativi di
per l'esportazione di Oracle forniti da
dati SHAPE (ESRI): terzi:
● pgsql2shp
● Desktop
Gis
Open source
Tool non nativi di ● Desktop
Gis
PostGis forniti da
commerciali
terzi:
● Desktop
Gis
Tool nativi ArcSde
per l'importazione di
dati SHAPE (ESRI):
● shp2sde
● ARCGIS
Desktop
Tool non nativi di
ArcSde forniti da
terzi:
● Desktop
Gis
Open source
● Desktop
Gis
commerciali
Tools nativi ArcSde
dati SHAPE (ESRI):
● sde2shp
● ARCGIS
Desktop
Tools non nativi di
ArcSde forniti da
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 179 di 193
Open source
● Desktop
Gis
commerciali
terzi:
● Desktop
Gis
Open source
● Desktop
Gis
commerciali
Lettura e scrittura Supporto per la
dei dati
rappresentazione
secondo i format
OGC:
● WKT
● WBT
Supporto per la
rappresentazione
secondo i format
OGC:
● WKT
● WBT
Supporto per la
rappresentazione
secondo i format
OGC
(escluso
ArcSde
9.2
+
SqlServer):
● WKT
● WBT
Modifica dei dati ST_Geometry
in
(API SQL)
PostGis
è
supportato da un
insieme di API SQL
che
effettuano
modifiche
sulle
entità geometriche:
● inserimento
di
punti
in
una
geometria (punti,
linee, poligoni)
● cancellazione di
punti
in
una
geometria
● modifica di punti
in geometria
● trasformazioni
affine
delle
geometrie
queste
funzioni
sono fornite con API
SQL
del
tipo
ST_XXX
ST_Geometry
e
SDO_Geometry
forniscono
una
serie di pacchetti di
funzioni
PL/SQL
che permettono di
gestire o modificare
i dati geometrici:
● SDO_GEOM
Package
(Geometry)
● SDO_UTIL
Package (Utility)
Il
supporto
alla
modifiche
tramite
API SQL dei dati
dipende dal DBMS
connesso al server
ArcSde.
Con
i
DBMS
che
prevedono il tipo
ST_Geometry
vengono utilizzate
le funzioni previste
per esso (come per
PostGis o Oracle).
Query spaziali
In ArcSde 9.2 +
sqlserver200
non
sono fornite funzioni
SQL di modifica dei
dati spaziali.
Funzioni ST_XXX Funzioni SDO_XXX Per i DBMS con
che permettono le che permettono le supporto
di
seguenti operazioni: seguenti operazioni: ST_Geometry sono
● query
spaziali ● query spaziali
previste:
● query spaziali
basate
su
basate su
relazioni
relazioni
basate su
topologiche
topologiche
relazioni
(intersezione,
(intersezione,
topologiche
contatto,
contatto,
(intersezione,
contenimento,
contenimento,
contatto,
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 180 di 193
ecc)
● query spaziali su
proprietà
geometriche
(area, distanza,
lunghezza,
perimetro,
centroide, ecc)
ecc)
proprietà
geometriche
(area, distanza,
lunghezza,
perimetro,
centroide, ecc)
contenimento,
ecc)
proprietà
geometriche
(area, distanza,
lunghezza,
perimetro,
centroide, ecc)
Raster
Tipo di dato
Non è previsto un SDO_GEORASTE
tipo raster nella R
attuale versione di
PostGis.
Esistono
delle
estensioni
realizzate da terzi
che sono ancora in
via di sviluppo e
non ancora testate
(es.
le
librerie
PGCHIP
che
fungono
da
interfaccia
tra
PostGis e le librerie
GDAL).
Importazione dati
PGCHIP forniscono
i
driver
di
connessione
alle
librerie GDAL per
l'importazione.
Tipo
di
dato
supportato:
● GDT_Byte
● GDT_UInt16
Tools
nativi
Oracle:
● MapBuilder
BLOB
di Tool nativo di ESRI:
● ArcCatalog
Tools
forniti
da
patners di Oracle:
● PCI Geomatica
oltre a strumenti
software
Oracle
fornisce
delle
procedure PL/SQL
immagini raster nel
geodatabase.
Formati supportati
per l'importazione:
● tif
● jpeg
● bmp
● png
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 181 di 193
●
Esportazione dati
PGCHIP forniscono
i
driver
di
connessione
alle
librerie GDAL per
l'esportazione.
gif
Esistono tool forniti
da partner di Oracle
Spatial.
Oracle
fornisce
procedure PL/SQL
per l'esportazione
dei dati raster:
● SDO_GEOR.exp
ortTo.
Formati di
esportazione: TIFF,
BMP, GeoTIFF, o
PNG.
Eportazione dei dati
raster in ArcSde
viene
eseguita
mediante plug-in di
arcCatalog.
Formati di
esportazione:
TIFF, BMP, JPEG,
JPEG2000, PNG,
GIF.
Lettura e scrittura Impossibile
dei dati
API PL/SQL per la Viene gestito come
lettura e scrittura un semplice dato
dei dati.
BLOB.
Modifica dei dati Impossibile
(API SQL)
SDO_GEOR
Impossibile
Package
procedure PL\SQL
per la modica dei
dati
Query spaziali
SDO_GEOR
Impossibile
package permette
di estrarre le celle
dei dati raster in
base a dei vincoli
che
devono
soddisfare.
Impossibile
Servizi WEB
WMS
POSTGIS
+
MAPSERVER
ORACLE SPATIAL
+
ORACLE
CONTAINER FOR
JAVA (OC4J).
ARCSDE +
ARCGIS SERVER
9.2
WFS
POSTGIS
+
MAPSERVER
ORACLE SPATIAL
+
ORACLE
CONTAINER FOR
JAVA (OC4J).
Non disponibile
WCS
POSTGIS
+
MAPSERVER
ORACLE SPATIAL
+
ORACLE
CONTAINER FOR
JAVA (OC4J).
Non disponibile
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 182 di 193
Non disponibile
API
(SQL)
per
WEB
SPATIAL
SERVICE
Pacchetti PL/SQL
per la gestione dei
servizi WEB:
● SDO_CSW_PR
OCESS package
● SDO_WFS_LOC
K package
● SDO_WFS_PRO
CESS package
Non disponibile
Conversione SRS
Trasformazione
del sistema di
riferimento per le
coordinate
Supportato
Supportato
Supportato
Disponibili
Disponibili
Disponibili
SDK developer
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 183 di 193
GEONETWORK
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 184 di 193
Introduzione
Le informazioni connesse a temi come la sicurezza alimentare, l’emergenza, le risorse
naturali, le questioni ambientali, le politiche di sviluppo e così via, sono sempre più spesso
rappresentate ed analizzate attraverso i sistemi informativi geografici (GIS), che mettono a
disposizione un insieme di strumenti informatici in grado di acquisire, immagazzinare,
trasformare, analizzare e riprodurre dati spaziali riferiti al territorio e che supportano il lavoro
degli operatori del settore nella pianificazione delle loro attività. La richiesta di dati spaziali
multidisciplinari per poter rappresentare al meglio la complessità delle diverse problematiche
è crescente, soprattutto nella valutazione degli interventi da programmare nelle aree
vulnerabili. In questo scenario si inserisce il progetto della FAO (Food and Agricolture
Organization) chiamato GeoNetwork13.
L'obiettivo di questo progetto è di permettere alle agenzie internazionali, alle università, alle
istituzioni nazionali e regionali, un più facile accesso ai prodotti geografici disponibili ed alle
informazioni ad essi correlate, utilizzando modelli standard di distribuzione riconosciuti dalla
comunità internazionale.
La sfida principale del progetto è quella di migliorare la condivisione ed il flusso di dati tra le
organizzazioni, ampliare la cooperazione tra i produttori delle informazioni per incrementare
lo sfruttamento delle risorse ed evitare inutili duplicazioni di prodotti, permettendo infine
anche il libero e facile accesso al dato da parte di tutti.
Il progetto GeoNetwork è nato inizialmente per facilitare l’archiviazione e lo scambio dei dati
prodotti in FAO, dalle più semplici informazioni spaziali ai prodotti cartografici elaborati. Il
progetto ha quasi subito beneficiato della collaborazione di altre Agenzie delle Nazioni Unite:
UNEP (United Nations Environment Programme), OCHA (Office for the Coordination of
Humanitarian affairs), OMS (Organizzazione Mondiale della Sanità), che hanno contribuito
allo sviluppo del software.
Il primo prototipo di GeoNetwork nasce alla fine del 2001 per archiviare e pubblicare dati
geografici prodotti dalla FAO.
Nel 2002 inizia la collaborazione per la gestione dei dati spaziali tra la FAO e il World Food
Programme (WFP) e inoltre si sviluppa il servizio di Web Map Viewer (visualizzatore di
mappe on-line), che permette di visualizzare mappe ed immagini satellitari provenienti sia da
database locale sia da server esterni.
Nel 2003 viene pubblicata la prima versione di GeoNetwork e con questa viene creato il
primo geocatalogo operativo in FAO e WFP.
Nel 2004 inizia la collaborazione con la UNEP per sviluppare una nuova versione del
software.
Nel 2005 viene costituito il GeoNetwork consortium tra la FAO, WFP, UNEP, WHO (World
Health Organization), OCHA e il CGIAR (Consultative Group on International Agricoltural
Research).
13 http://geonetwork-opensource.org
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 185 di 193
Nel 2007 viene lanciata la versione 2.1 di GeoNetwork, seguita dalla versione 2.2 rilasciata
nell’aprile del 2008 in cui viene garantita una maggiore interoperabilità tra i sistemi
informativi geografici che si basano sugli stessi moduli e gli stessi standard.
Grazie al nuovo sistema dell’harvesting (raccolta automatizzata tesa all’aggregazione di dati
provenienti da fonti differenti al fine di riproporli in un’unica raccolta globale di informazioni
liberamente accessibile e svincolata dalla piattaforma d’origine) è possibile programmare la
ricerca di informazioni da diverse banche dati fisicamente localizzate in diverse parti del
mondo, in modo da restituire in un’unica pagina web un’ampia selezione di dati. L'archivio
della FAO gestito con GeoNetwork14 è un esempio di applicazione di questo concetto di dati
distribuiti: su questo sito è possibile visualizzare informazioni provenienti da geocataloghi di
enti diversi mediante l'accesso a un unico indice centralizzato.
La FAO ha deciso, insieme a tutte le organizzazioni che hanno collaborato al progetto, di
rilasciare il programma con licenza open source (GPL): è quindi disponibile l'intero codice,
permettendo quindi personalizzazioni e sviluppi mirati alle necessità di ogni organizzazione
che interessata ad adottarlo.
Modalità di Ricerca
Il software GeoNetwork mette a disposizione diversi strumenti per effettuare le ricerche
nell'archivio.
- Ricerca semplice (Figura 100)
La ricerca semplice permette di cercare i dati definendo semplicemente delle parole chiave. E'
possibile raffinare ulteriormente la ricerca indicando anche un contesto temporale di interesse.
Naturalmente è necessario impostare il geocatalogo in cui effettuare la ricerca nel caso si
voglia indirizzarsi su un particolare set di dati, ed inoltre viene data la possibilità di includere
nei risultati delle ricerca solo le digital map oppure le hard copy map (mappe digitali o
cartacee).
- Ricerca avanzata (Figura 101)
La ricerca avanzata permette di condurre la ricerca in modo più dettagliato tramite la
definizione degli ambiti di interesse. È possibile ad esempio cercare in base al titolo.
specificando una particolare zona geografica di interesse, indicando delle parole chiave, ...
-Ricerca per categorie
La ricerca per categorie permette di ricercare i contenuti selezionando la categoria a cui si è
interessati: applicazioni, audio/video, casi di studio, risorse interattive, foto, ecc.
14 http://www.fao.org/geonetwork
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 186 di 193
Figura 100: Ricerca semplice
Figura 101: Ricerca avanzata
Analisi dei risultati
Nella pagina con i risultati della ricerca per ogni occorrenza trovata sono elencati: il titolo, un
estratto della descrizione associata al dato, le parole chiave (Figura 102) e la possibilità di
accedere a quattro sezioni con delle descrizioni più dettagliate.
Le quattro sezioni sono:
1. Metadata: sezione con l'elenco di tutti i metadati associati;
2. Download: indicazioni con i riferimenti per effettuare il download dei dati (se consentito
dal proprietario);
3. Graphic Overviews: carta di riferimento dell'area di interesse;
4. Interactive Map: indicazioni per accedere ad un eventuale geoservizio di navigazione dei
dati (Figura 103);
5. View in Google Earth: possibilità di aggiungere i dati e visualizzarli all'interno di Google
Earth insieme alla cartografia fornita da questo servizio (Figura 104).
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 187 di 193
Visualizzazione dei risultati
Una volta completata la ricerca si possono vedere i dettagli di un particolare record,
scegliendo tra tre diverse modalità:
Default View: mostra una selezione dei più importanti campi che compongono i metadati.
Advanced View: mostra l’intera struttura dei metadati accedendo alle varie sezioni
separatamente.Ogni sezione è composta da un campo di tipo mandatory(obbligatorio) ed altri
campi opzionali/non mandatory.
XML View: mostra i metadati in XML (eXstensible Markup Language), Figura 105.
Aggiornamento dell'archivio
Geonetwork permette di definire delle politiche di accesso ai dati (Figura 106) mediante la
definizione di diversi livelli di privilegi (All, Intranet, Sample group, Training group). Per
ognuno di questi gruppi è poi possibile associare il tipo di accesso consentito:
•
Publish: semplice visualizzazione del dato;
•
Download: possibilità di effettuare il download;
•
Interactive Map: accessi alla cartografia interattiva che farà riferimento ad un Web
Map Server;
•
Featured: accesso in modalità di editing dei dati;
•
Notify: utenti che potranno caricare le carte;
•
Admin: l’utente amministratore con pieni diritti sui dati.
È possibile aggiungere nuovi metadati seguendo tre diversi standard: ISO 19115, FGDC
(Federal Geographic Data Committee) e Dublin Core.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 188 di 193
Figura 102: risultato di una ricerca
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 189 di 193
Figura 103: Interactive map
Figura 104: vista in Google earth
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 190 di 193
Figura 105: esempio di XML
Figura 106: Politiche di accesso ai dati
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 191 di 193
Ruolo di amministratore
GeoNetwork prevede due livelli di amministrazione e tre livelli di utenti privilegiati (Figura
107):
⁃
Administrator Profile: permette di creare nuovi workgroup, e nuovi utenti oltre alla
possibilità di editare i metadati;
⁃
User Administrator Profile: per la gestione del singolo workgroup, permette la
creazione di nuovi utenti, e la scrittura dei metadati;
⁃
Content reviewer Profile: è utilizzato solo dagli utenti che hanno il compito di validare
i metadati prima della pubblicazione in Internet;
⁃
Editor Profile: utilizzato per gli utenti che devono scrivere, modificare e cancellare i
dati e i metadati;
⁃
Registered User Profile: utilizzato per gli utenti ai quali si vuole garantire unicamente
il download dei metadati.
Nella sezione dedicata alla gestione dei metadati sono presenti le seguenti funzionalità:
⁃
New metadata: per inserire nuovi dati con i relativi metadati;
⁃
XML Metadata Insert: per inserire i metadati facendo l'upload di un documento XML
creato da un'altra applicazione, ad esempio da un GIS;
⁃
Batch Import: permette di importare tutti i metadati presenti sulla directory locale che
corrispondono ai criteri impostati;
⁃
Search for Unused: permette di ricercare i dati/metadati inutilizzati;
⁃
Transfer ownership: permette di riassegnare ad un utente diverso da quello iniziale la
proprietà dei metadati;
⁃
Manage thesauri: per la gestione del thesaurus dei metadati.
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 192 di 193
Figura 107: Profili utenti
Data emissione:
19 giugno 2008
Codice:
CI08-02-1.1
Pagina 193 di 193

icad-geo. studio di fattibilità per la realizzazione di un progetto per la

Transcript

Documenti analoghi

Titolo della vendita Gemälde und zeichnungen 15.

ENRICO E FRANCESCO MUSICA PER MATRIMONI

PC Portatili 6-Corrispettivi-Lotto 1

ASTE ESATTORIALI DI APRILE 2016

scheda concerto - Casa Internazionale delle Donne

Delegazione Lombardia - SPRINGER SPANIEL della BANDA ALATA

Vendite e acquisti senza confini TRIBUNALE DI

www.markvideo.it Mark Video azienda nella produzione Video

Fabbricati costruiti per esigenze commerciali

202 kB 30 Dec 2015 PULIZIA LOCALI [Settembre 2014]