Progetto di ricerca del Centro Interregionale di Coordinamento e documentazione per le informazioni territoriali - Area di approfondimento 4

Transcript

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

2 Pagina 2 di 193

3 Titolo documento Repertorio delle tecnologie disponibili per la realizzazione di SDI Autore 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) Data 19 giugno 2008 Soggetto Applicazioni GIS e WEB-GIS Editore Centro Interregionale di Coordinamento e documentazione per le informazioni territoriali Tipo Testo Descrizione Il documento descrive le applicazioni software e le relative tecnologie disponibili per la realizzazione di infrastrutture dati geografiche Contributi Formato Openoffice.ODT Riferimento Identificatore report2 Lingua Italiano Relazioni Estensione temporale 10 mesi Estensione spaziale Italia Pagina 3 di 193

4 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 Introduzione Funzionamento Il Template file Il Mapfile Implementazione dello standard WMS in MapServer Implementazione dello standard WFS in MapServer Pagina 4 di 193

5 Implementazione dello standard WCS in MapServer Chameleon Appendice 1: software conformi allo standard WMS GEODATABASE Introduzione POSTGIS Import/export delle feature Funzioni di Postgis ORACLE SPATIAL Geometrie spaziali (shape) Importazione dei dati Esportazione dati Operazioni spaziali in Oracle Spatial operator Spatial aggregate function Georaster Spatial Tabella riassuntiva di confronto tra PostGIS e ORACLE SPATIAL ArcSDE Comparazioni riassuntive GEONETWORK Introduzione Modalità di Ricerca Analisi dei risultati Visualizzazione dei risultati Aggiornamento dell'archivio Ruolo di amministratore Pagina 5 di 193

6 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 E- Government 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 Pagina 6 di 193

7 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. Pagina 7 di 193

8 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 Pagina 8 di 193

9 (Hypertext Transfer Protocol), CORBA (Common Object Request Broker Architecture), SOAP, XML (Extensible Markup Language), ecc. 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. GRASS QGIS UNM MapServer Postgres SQL PostGIS Applicazioni C/C++ Geonetwork Geoserver Deegree OpenMap udig AlovMap Jump Applicazioni Java 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 ). Pagina 9 di 193

10 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). Proj4 GDAL/OGR GEOS E00compr Librerie C/C++ Geotools Librerie Java Java Map Projection Library (javaproj) Fulcrum 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. Pagina 10 di 193

11 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 Specifiche OGC Tipo Autodesk GIS SFS 1.1 Design Server 8.x Server Autodesk WFS 1.0, WMS (compliant) MapGuide Server Enterprise 2007 Autodesk WFS 1.0, WMS (compliant) MapGuide Server Enterprise 2007 Autodesk WMS 1.1.1, WFS 1.0 MapGuide Server Enterprise 2008 Autodesk SFS 1.1 Topobase 2008 Client e Server Bentley Map GML 2.1.2, GML 3.1.1, GMLsf 1.0.0, WFS(T) Client Chameleon 1.99 WMS 1.1, WMS 1.0, WMC 1.0, WFS 1.0, SLD 1.0, Filter 1.0, WMS Client - Binary Schema SFS(BG) 1.1 (compliant) 9.2 Server ArcExplorer Web WMC 1.0, WMS 1.0, WMS 1.1, WMS Client ArcGIS 8.1 SFO 1.1 (compliant) Client ArcGIS Server WMS (compliant) 9.2 Server ArcGIS Server WFS 1.1, WCS c1, WCS 1.1.0, WCS 1.0.0, 9.3 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, Server 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, 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 WMS SFS(TF) 1.1 (compliant) SFS(TF) 1.1 (compliant) SFS(BG) 1.1 (compliant) SFS(TF) 1.1 (compliant) SFS(BG) 1.1 (compliant) Server Server Server Server Server Pagina 11 di 193

12 ArcGIS Server SFS(BG) 1.1 (compliant) Enterprise: SQL - Binary Schema Server 9.2 ArcGIS Server SFS(BG) 1.1 (compliant) Enterprise: SQL Server Express - Server Binary Schema 9.2 ArcGIS Server SFS(BG) 1.1 (compliant) Enterprise: SQL Server Express - Server Binary Schema 9.2 ArcIMS 9.0 WMS 1.0, WMS 1.1, WMS (compliant) Server ArcIMS 9.0, 9.1 OLSCore 1.0, OLSCore 1.1, OLSCore(DS) 1.0, OLSCore(LUS) 1.0, OLSCore(PS) 1.0, Server OLSCore(RS) 1.0 ArcIMS 9.1 WMS (compliant), WFS 1.0, SLD 1.0, GML 3.0, GML 2.1.2, GML 2.1.1, Filter 1.0 Client e Server ArcIMS 9.1 SP1 Filter 1.0, GML 2.1.1, GML 2.1.2, GML 3.0, SLD 1.0, WFS 1.0 (compliant), WMS Server ArcIMS 9.2 WMS (compliant), WFS 1.0 (compliant) Server ArcSDE for DB2 SFS(TF) 1.1 (compliant) 8.1 Client e Server ArcSDE for DB2 SFS(TF) 1.1 (compliant) 9.0 Server ArcSDE for DB2 SFS(TF) 1.1 (compliant) 9.1 Server ArcSDE for SFS(TF) 1.1 (compliant) Informix 8.1 Client e Server ArcSDE for SFS(TF) 1.1 (compliant) Informix 9.0 Server ArcSDE for SFS(TF) 1.1 (compliant) Informix 9.1 Server ArcSDE for SFS(BG) 1.1 (compliant) Oracle 9.0 Server ArcSDE for SFS(BG) 1.1 (compliant) Oracle 9.1 Server ArcSDE for SQL SFS(BG) 1.1 (compliant) Server 9.0 Server ArcSDE for SQL SFS(BG) 1.1 (compliant) Server Server 9.1 ArcWeb Services 2006 GIS Portal Toolkit 3.1 Spatial Database Engine for DB2 Datajoiner Spatial Database Engine for Informix OLSCore(RS) 1.0, OLSCore(PS) 1.0, OLSCore(LUS) 1.0, OLSCore(GS) 1.0, Server OLSCore(DS) 1.0, OLSCore 1.1, OLSCore 1.0 WCS c1, WCS 1.0, SLD 1.0, Filter 1.1, Filter 1.0, CAT2 ISO AP 1.0.0, CAT2 ebrim part , CAT2 ebrim part , CAT2 AP Client e Server 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 SFS(TF) 1.1 (compliant) Client SFS(TF) 1.1 (compliant) Client Pagina 12 di 193

13 FAO-UN Generalitat Valenciana ans.org Intergraph Corporation Lat/lon Spatial Database Engine for Oracle GeoNetwork opensource 2.1 gvsig 0.6 GeoServer 1.3 GeoServer 1.5 GeoMedia Data Server for Oracle Object Model Server (Read/Write) GeoMedia Professional GeoMedia SFS(NG) 1.1 (compliant) CAT 1.1.1, CAT CS/W 2.0.1, CAT2 AP 19115/ , GeoRSS 1.0.0, SOAP 0.8, WMC 1.1, WMS 1.0, WMS CAT2 AP 19115/ , 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 WFS(T) 1.0 (compliant), WFS 1.0 (compliant), WMS (compliant) 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 SFS(BG) 1.1 (compliant) Client Client e Server Client Server Server Server WMS 1.1, SFS(BG) 1.1 (compliant), WMS 1.0, WFS 1.0, WMS 1.1.1, WFS 1.0, GML 2.0 Client e Server GML 2.1.1, WMS 1.0, WMS 1.1, WMS 1.1.1, Viewer GML 2.0, WFS 1.0 Client GeoMedia Web SFS(BG) 1.1 (compliant), WMS Map Professional (compliant), WFS 1.0 (compliant), GML 2.0, Client e Server 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 WebMap (compliant), WFS 1.0 (compliant), GML 2.1.1, Client e Server GML 2.0 WMS Viewer WMS 1.1, WMS 1.0, SLD 1.0, WMS Client (HTML) deegree CAT2 AP 19115/ , GAZ 0.9.3, WFS igeoportal - 1.1, WMS 1.0, WMS 1.1, WMS portlet edition Client (HTML) deegree igeoportal - standard edition deegree owsproxy deegree Web Coordinate Transformation Service deegree Web Coverage Service deegree Web Coverage Service deegree Web Feature Service deegree Web Feature Service WTS 0.5, WMS 1.1.1, WMS 1.1, WMS 1.0, WMC 1.0, WFS 1.1, GML 3.1.1, GML 2.1.2, GAZ 0.9.3, CAT2 AP 19115/ , CAT CS/W WMS 1.1.1, WFS 1.1, CAT2 AP 19115/ WCTS WCS 1.0 (compliant) WCS 1.0 (compliant) GML CityGML 0.3.0, GML 3.1.1, GML 2.1.1, GAZ 0.9.3, Filter 1.1, WFS 1.1 GML CityGML 0.3.0, GML 3.1.1, GML 2.1.1, GAZ 0.9.3, Filter 1.1, WFS 1.1 Client (HTML) Proxy (Client/Server) Server Server Server Server Server Pagina 13 di 193

14 MapInfo Corporation deegree Web Gazetteer Service deegree Web Gazetteer Service deegree Web Map Service deegree Web Map Service deegree Web Processing Service MsSqlSpatial MsSqlSpatial - Spatial Extensions for SQL Server Oracle Corporation 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 WMS (compliant), WMS 1.1, WMS 1.0, SLD 1.0 WMS (compliant), WMS 1.1, WMS (compliant) WPS Server Server Server Server Server deejump WMS 1.1.1, WMS 1.1, WFS 1.1 Client Envinsa 4.0 WMS (compliant), WFS 1.0, OLSCore 1.1, Server GML 3.0 MapInfo WMS 1.1.1, WMS 1.1, WMS 1.0, WFS 1.0, Professional 8.5 SFS(TF) 1.1, GML 2.1.1, WMS Client MapXtreme 2005 WMS (compliant), WMS 1.1, WMS 1.0, 6.5 WFS 1.0, GML 3.0, GML Client e Server MapXtreme 2005 WMS (compliant), GML 2.1.1, GML 3.0, 6.6 WFS 1.0, WMS 1.0, WMS 1.1 Client e Server MapXtreme Java WMS (compliant), GML 2.1.1, SFS(TF) Edition , WMS 1.1 Client e Server MapXtreme Java WMS (compliant), GML 2.1.1, SFS(TF) Edition , WMS 1.1 Client e Server SFS(TF) 1.1, SFS Oracle Application Server MapViewer, 10g Release 2 (10.1.2) Oracle Spatial 11g Oracle Locator, 10g Release 2 ( ) Oracle Spatial, 10g Release 2 ( ) Oracle Spatial, 9i Release 2 (9.2.0) Oracle Spatial, release 9i (9.0.1) Oracle8 Spatial Cartridge Oracle8i Spatial PCI Geomatics Geomatica - WebServer Suite 10.0 Geomatica WebServer - WMS (compliant) WFS 1.0, WFS-T 1.0, CSW 2.0, OpenLS 1.1 SFS(TF) 1.1 (compliant) SFS(TF) 1.1 (compliant) SFS(NG) 1.1 (compliant) SFS(NG) 1.1 (compliant) SFS(NG) 1.1 (compliant) SFS(NG) 1.1 (compliant) WMS 1.1.1, WFS 1.0, WCS 1.0 (compliant) WMS Server Client e Server Client e Server Client e Server Client e Server Client e Server Client e Server Client e Server Client e Server Client e Server Client e Server Pagina 14 di 193

15 GWS 9.0 Refractions PostGIS / SFS (compliant), SFS(TF) 1.1 (compliant) Research Inc PostgreSQL Server / Safe Software FME 2008 GML CityGML 0.4.0, GML 3.1.1, GML 2.1.2, 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 Client e Server UMN MapServer MapServer 4.2 WMS 1.1, WMS 1.0, WMC 1.0, WFS 1.0, SLD 1.0, GML 2.0, Filter 1.0, WMS Client e Server WhereGroup GmbH & Co. KG Mapbender Mapbender OWS Proxy 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 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, Client (HTML) Proxy (Client/Server) WMS 1.1, WMS 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 CAT Common CORBA GML KML Documento Vers. più recente Link Catalogue Services Specification Web Services Common Specification Simple Features Specification For CORBA Geography Markup Language (GML) Encoding Standard OGC KML - OGC r spatial.org/standard s/cat with Corrigendum 1 Revision spatial.org/standard s/common patial.org/standards/sf c patial.org/standards/g ml patial.org/standards/k ml SLD Styled Layer (revision 4) Pagina 15 di 193

16 SFS Descriptor profile of the Web Map Service Implementation Specification Implementation Specification for Geographic information - Simple feature access - Part 1: Common architecture patial.org/standards/sl d patial.org/standards/sf a SFS (TF) WCS WFS WMS Specification for Geographic information - Simple feature access - Part 2: SQL option Web Coverage Service (WCS) Implementation Standard Web Feature Service Implementation Specification Web Map Server Implementation Specification patial.org/standards/sf a patial.org/standards/w cs patial.org/standards/w fs patial.org/standards/w 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 Pagina 16 di 193

17 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, (812) ; Open Geospatial Consortium - Pagina 17 di 193

18 STANDARD METADATI Pagina 18 di 193

19 Standard CNIPA Lo standard definito dal CNIPA 1 (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): fornisce le 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): fornisce informazioni sulla frequenza di 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 IT/Aree_operative/Progetti,_applicazioni_e_servizi/Sistemi_Informativi_Territoriali_/Repertorio_Nazionale_ dei_dati_territoriali/ Pagina 19 di 193

20 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. Pagina 20 di 193

21 Informazioni sui metadati (MD_Metadata) ID Nome del metadato Descrizione 1 Identificatore del file di metadati (O) Identificatore univoco del file di metadati 2 Lingua dei metadati (O) Lingua in cui sono scritti i metadati 3 Set dei caratteri dei metadati (C) Set di caratteri utilizzato per i metadati (es. utf8) 4 Identificatore metadati di rango superiore (O) 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 5 Livello gerarchico (O) Livello gerarchico del metadato (es. serie, dataset, sezione) Nome dell Ente (O) Nome dell ente responsabile 6 Contatto (O) Ruolo (O) Informazioni per contattare l Ente (O) Ruolo ricoperto dall ente Informazioni utili per contattare l ente (num. di telefono, , ) 7 Data dei metadati (O) Data di creazione dei metadati 8 Nome dello standard dei metadati (O) Standard di metadati utilizzato 9 Versione dello standard dei metadati (O) Versione dello standard utilizzato 10 Limitazione d uso dei metadati (Op) Vincoli d accesso dei metadati (Op) Vincoli di fruibilità dei metadati (Op) Altri vincoli sui metadati (C) 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 CI Pagina 21 di 193

22 Informazioni di identificazione dei dati (MD_Identification-MD_DataIdentification) Titolo (O) Data (O) Tipo di data (O) Nome dell Ente (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, , ) Riferimento univoco che identifica la risorsa nel livello gerarchico specificato. Informazioni sulla serie/dataset di cui il dataset/sezione fa parte Ulteriori informazioni CI Pagina 22 di 193

23 12 Descrizione (O) Descrizione del dato 13 Parole chiave (O) Elenco parole chiave che caratterizzano il dato 14 Punto di contatto (O) Responsabile della risorsa 15 Tipo di rappresentazione spaziale (C) Rappresentazione spaziale utilizzata 16 Risoluzione spaziale dei dati (O) Scala equivalente (C) Scala della carta Distanza (C) Risoluzione geometrica al suolo. 17 Lingua dei dati (O) Lingua utilizzato per i dati 18 Set di caratteri dei dati (C) Set di caratteri utilizzato per i metadati (es. utf8) 19 Tema (O) Tema a cui si riferisce il dato WestBoundLongitude (O) Limite ovest in gradi decimali Localizzazione geografica dei dati EastBoundLongitude (O) Limite est in gradi decimali SouthBoundLongitude (O) Limite sud in gradi decimali 20 NorthBoundLongitude (O) Limite nord in gradi decimali Quota min (O) Quota minima Estensione verticale (Op) Quota max (O) Quota massima Unità di misura (O) Unità di misura della quota Datum verticale (O) Datum utilizzato per definire le quote 21 Informazioni supplementari (Op) Eventuali informazioni descrittive supplementari 22 Esempio grafico (Op) Eventuale immagine che illustra la risorsa Informazioni sui vincoli dei dati (MD_Constraints) 23 Limitazione d uso dei dati (O) Restrizioni di utilizzo dei dati 24 Vincoli di accesso dei dati (O) Definizione di eventuali vincoli di accesso esistenti 25 Vincoli di fruibilità dei dati (O) Definizione di eventuali vincoli di utilizzo esistenti 26 Altri vincoli sui dati (C) Definizione di altri eventuali vincoli esistenti Informazioni sulla qualità dei dati (DQ_DataQuality) CI Pagina 23 di 193

24 27 28 Livello di qualità (O) Livello cui sono applicate le informazioni di qualità Qualità dei dati (accuratezza posizionale) (C) Unità di misura (O) 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 Genealogia del dato-processo di produzione (O) Informazioni sul sistema di riferimento (MD_ReferenceSystem) 30 Sistema di riferimento spaziale (O) Informazioni sulla distribuzione (MD_Distribution) Nome formato (O) 31 Formato di distribuzione (O) Versione formato (O) Descrizione del processo di realizzazione del dato (es. stereorestituzione) Sistema di riferimento utilizzato (es. ROMA 40/ EST) Nome del formato dei dati Versione del formato dei dati 32 Distributore (O) 33 Risorsa on-line (Op) Nome dell Ente (O) Ruolo (O) Informazioni per contattare l Ente (O) 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 CI Pagina 24 di 193

25 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) Descrizione dalla grandezza misura 2 Tipi di contenuto (O) Tipo di informazione rappresentato dal valore della cella 3 Risoluzione radiometrica (Op) Numero massimo di bit significativi in cui può essere rappresentata l intensità radiometrica di ogni pixel 4 Triangolazione aerea (Op) 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 dimensione (O) Nome degli assi 6 Proprietà dimensioni (O) Misura dimensione (O) Numero degli elementi lungo gli assi Risoluzione (Op) Grado di dettaglio dei dati (es. passo 40 metri) 7 Geometria della cella (O) Geometria utilizzata per le celle raster 8 Disponibilità coefficienti della trasformazione (O) 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 CI Pagina 25 di 193

26 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 CI Pagina 26 di 193

27 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 Core 3. 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 Pagina 27 di 193

28 Standard di metadati adottati da GeoNetwork Il software GeoNetwork 4 adotta come schema per i metadati una versione personalizzata dello standard ISO 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 Pagina 28 di 193

29 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,...) CI Pagina 29 di 193

30 9 Point of contact Individual name * Nome del responsabile dei metadati Organization name * Position name * Voice Facsimile Delivery point City Administrative area Postal code Country Electronic mail address Role * Nome dell organizzazione Ruolo esercitato dal responsabile Numero di telefono del responsabile Numero di fax del responsabile Indirizzo dell organizzazione Città Suddivisione amministrativa (ad es. per l'italia la provincia di appartenenza) Codice di avviamento postale Paese Indirizzo Ruolo del responsabile 10 Point of contact Responsabile della risorsa e modalità di contatto CI Pagina 30 di 193

31 11 Maintenance and update * Informazioni circa l aggiornamento dei dati 12 Descriptive keywords (1) Keyword Parole chiave associate alla risorsa Type Tipo di parola chiave (es. temporale, disciplina, tema,...) 13 Descriptive keywords (2) 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 * Denominator * Scala 19 Language * Lingua utilizzata per i dati CI Pagina 31 di 193

32 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 * Temporal Extent Begin date Data di inizio di validità del dato 23 Extent Geographic bounding box End date West bound latitude * East bound latitude * South bound latitude * North bound latitude * Data di fine di validità del dato Limite ovest in gradi decimali Limite est in gradi decimali Limite sud in gradi decimali Limite nord in gradi decimali 24 Supplemental information Informazioni supplementari CI Pagina 32 di 193

33 Distribution info (default view) 25 OnLine resource URL Indirizzo internet di una risorsa Protocol Description * Protocollo di connessione usato Descrizione dell evento inclusi i parametri e la tolleranza 26 OnLine resource URL Indirizzo internet di una risorsa Protocol File Description * Protocollo di connessione usato Nome file Descrizione dell evento inclusi i parametri e la tolleranza 27 Online resource URL Indirizzo internet di una risorsa Protocol Name * Description * Protocollo di connessione usato Nome delle serie, dei dataset aggregati o del dataset di cui fa parte il dato Descrizione dell evento inclusi i parametri e la tolleranza CI Pagina 33 di 193

34 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 Set di caratteri utilizzato per i metadati (es. utf8) CI Pagina 34 di 193

35 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 CI Pagina 35 di 193

36 37 Metadata author * Individual name * Nome dell autore dei metadati Organization name * Position name * Voice Facsimile Delivery point City Administrative area Postal code Country Electronic mail address Role * Nome dell organizzazione Ruolo dell'autore Numero di telefono dell'autore Numero di fax dell'autore Indirizzo dell organizzazione Città Suddivisione amministrativa Codice di avviamento postale Paese Indirizzo Ruolo dell'autore CI Pagina 36 di 193

37 Spatial representation info (default view) 38 Number of dimension * Numero degli assi spaziali-temporali indipendenti 39 Dimension name * Nome degli assi 40 Dimension size * Numero degli elementi lungo gli assi 41 Resolution Grado di dettaglio dei dati 42 Dimension name * Nome degli assi 43 Dimension size * Numero degli elementi lungo gli assi 44 Resolution Grado di dettaglio dei dati 45 Dimension name * Nome degli assi 46 Dimension size * Numero degli elementi lungo gli assi 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 CI Pagina 37 di 193

38 CI Pagina 38 di 193

39 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à. Pagina 39 di 193

40 Identification Section ID-GeoNetwork Nome del metadato Occorrenza Tipo Dominio Elemento CNIPA ID-CNIPA Elemento ISO ID-ISO Elemento Doublin Core ID-Dublin Core 1 Title 1 Character string Testo libero Titolo 134 Title 360 Title 1 2 Date N Integer Date selector Data 135 Date 362 Date 7 3 Data Type 1 String Creation, Publication, revision Tipo data 150 DataType 395 Date 7 4 Edition 1 Character string Testo libero Edition 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 52 Purpose 26 8 Status N String On-going, obsolete, Status 28 CI Pagina 40 di 193

41 Individual name 1 String Testo libero Individual name 375 Organization name 1 Character string Testo libero Nome dell Ente 142 Organization name 376 Creator /Publisher 2/5 9 Point of contact Position name 1 Character string Testo libero Position name 377 Voice N Character String Testo libero Telefono 156 Voice 408 Facsimile N Character string Testo libero Facsimile 409 Delivery point 1 Character string Testo libero Informazion i per contattare l Ente 143 Contact Info 378 City 1 Character string Testo libero City 382 Administrative area 1 Character string Testo libero Administrative area 383 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 CI Pagina 41 di 193

42 10 Point of contact N String Point of contact Punto di contatto 21 Point of contact Maintenance and update N Associazione Daily, weekly,... Gestione della risorsa 22 Resource Maintenance Descriptiv e keywords Descriptiv e keywords Keyword N Character string Testo libero Parola chiave Type 1 Theme, place, Thesaurus 39 Keyword N Character string Testo libero Parola chiave Type 1 String Theme, place, Thesaurus Keyword 53 Thesaurus name Keyword 53 Subject 3 Thesaurus name Access constraints N String Copyright, license, Vincoli di accesso 48 Access constraints 70 Rights Use constraints N String Copyright, license, Vincoli di fruibilità 49 Use constraints 71 Rights Other constraints N Character string Testo libero Altri vincoli 50 Other constraints 72 Rights 15 CI Pagina 42 di 193

43 17 Spatial representation type N String Vector, gride,video, Tipo di rappresenta zione spaziale 28 Spatial representation type 37 Type 8 18 Equivalent scale 1 Character string Number Scala equivalente 43 Equivalent scale Language 1 Character string ISO Character set 1 String Utf8 Lingua dei metadati Set dei caratteri dei metadati 3 Language 3 Language 12 4 Character set 4 21 Topic category code N String Boundaries, farming, Tema 32 Topic category code 41 Subject 3 22 Temporal Extent N Integer Date selector Estensione 33 Extent 45 CI Pagina 43 di 193

44 West bound latitud e 1 Integer Integer Longitudine Ovest 120 West bound latitude 343 coverage Geographic bounding box East bound latitud e South bound latitud e 1 Integer Integer 1 Integer Integer Longitudine Est Latitudine Sud East bound latitude South bound latitude 344 coverage coverage 14 North bound latitud e 1 Integer Integer Latitudine Nord 123 North bound latitude 346 coverage Supplemental information 1 Character string Testo libero Informazio ni supplement ari 34 Supplemental information 46 CI Pagina 44 di 193

45 Distribution Section ID-GeoNetwork Nome del metadato Occorrenza Tipo Dominio Elemento CNIPA ID-CNIPA Elemento ISO ID-ISO Elemento Doublin Core ID-Dublin Core URL 1 Classe URL (IETF RFC1738) Risorsa on line 147 Linkage OnLine resource Protocol 1 String Web address, related link,... Protocol 398 Description 1 Character string Testo libero Description 401 URL 1 Classe URL (IETF RFC1738) Risorsa on line 147 Linkage OnLine resource Protocol 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 CI Pagina 45 di 193

46 URL 1 Classe URL (IETF RFC1738) Risorsa on line 147 Linkage OnLine resource Protocol 1 String Web address, related link,... Protocol 398 Name 1 Character string Testo libero Name 400 Description 1 Character string Testo libero Description 401 Reference System Info ID-GeoNetwork Nome del metadato Occorrenza Tipo Dominio Elemento CNIPA ID-CNIPA Elemento ISO ID-ISO Elemento Doublin Core ID-Dublin Core 28 Code 1 Character string Testo libero Identificatore del sistema di riferimento 88 Reference system identifier 187 CI Pagina 46 di 193

47 Data Quality Info ID-GeoNetwork Nome del metadato Occorrenza Tipo Dominio Elemento CNIPA ID-CNIPA Elemento ISO ID-ISO Elemento Doublin Core ID-Dublin Core 29 Hierarchy level N String Dataste, series, attributes, Livello gerarchico 6 Hierarchy level 6 Type 8 30 Statement 1 Character String Testo libero Genealogia del dato- Processo di produzione 56 Statement 83 CI Pagina 47 di 193

48 Metadata Information Section ID-GeoNetwork Nome del metadato Occorrenza Tipo Dominio Elemento CNIPA ID-CNIPA Elemento ISO ID-ISO Elemento Doublin Core ID-Dublin Core 31 File identifier 1 Character string Testo libero 32 Language 1 Character string ISO Character set 1 Classe Utf8 34 Date stamp 1 Character string ISO 8601 Identificatore del file di metadati Lingua dei metadati Set dei caratteri dei metadti Data dei metadata 2 File identifier 2 Identifier 10 3 Language 3 Language 12 4 Character set 4 8 Date stamp 9 Date 7 35 Metadata standard name 1 String ISO 19115:2003/ Nome dello standard dei metadati 9 Metadata standard name Metadata standard Version 1 String 1.0 Versione dello standard dei metadati 10 Metadata standard version 11 CI Pagina 48 di 193

49 Individual name 1 Character string Testo libero Individual name 375 Organizati on name 1 Character string Testo libero Nome dell Ente 142 Organization name 376 Creator /Publisher 2/5 Position name 1 Character string Testo libero Position name Metadata author Voice N Character String Testo libero Telefono 156 Voice 408 Facsimile N Character string Testo libero Facsimile 409 Delivery point 1 Character string Testo libero Informazioni per contattare l Ente 143 Contact Info 378 City 1 Character string Testo libero City 382 Administr ative area 1 Character string Testo libero Administrative area 383 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 CI Role 1 String Custodian, Ruolo 144 Role 379 Pagina 49 di 193

50 Spatial Representation Info ID-GeoNetwork Nome del metadato Occorrenza Tipo Dominio Elemento CNIPA ID-CNIPA Elemento ISO ID-ISO Elemento Doublin Core ID-Dublin Core 38 Number of dimension 1 Integer Integer Numero delle dimensioni 70 Number of dimension Dimension name 1 String Row, column, Nome dimensione 84 Nome dimensione Dimension size 1 Integer Integer Misura dimensione 85 Dimension size Resolution 1 Classe Measure Risoluzione 86 Resolution Dimension name 1 String Row, column, Nome dimensione 84 Nome dimensione Dimension size 1 Integer Integer Misura dimensione 85 Dimension size Resolution 1 Classe Measure Risoluzione 86 Resolution Dimension name 1 String Row, column, Nome dimensione 84 Nome dimensione 180 CI Pagina 50 di 193

51 46 Dimension size 1 Integer Integer Misura dimensione 85 Dimension size Cell geometry 1 Classe Area, point Geometria della cella 72 Cell geometry Transformation parameter availability 1 Character string Testo libero Disponibilità dei coefficienti della trasformazion e 73 Transformatio n parameter availability 161 CI Pagina 51 di 193

52 RNDT - REPERTORIO NAZIONALE DEI DATI TERRITORIALI Pagina 52 di 193

53 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 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: PHP 5 ; navigazione/interrogazione dei dati: UMN MapServer 6 /Ka-Map 7 ; database: PostgreSQL 8 /PostGIS 9. 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 Pagina 53 di 193

54 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 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 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 IT/Aree_operative/Progetti,_applicazioni_e_servizi/Sistemi_Informativi_Territoriali_/Repertorio_Nazionale_ dei_dati_territoriali/ Pagina 54 di 193

55 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 Geonetwork 11. 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 Pagina 55 di 193

56 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 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. Pagina 56 di 193

57 Figura 1: inserimento metadati: modalità interattiva Figura 2: inserimento metadati: modalità di cooperazione - singolo XML Pagina 57 di 193

58 Figura 3: inserimento metadati: modalità di cooperazione - XML multiplo Figura 4: validazione XML Pagina 58 di 193

59 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. Pagina 59 di 193

60 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" Pagina 60 di 193

61 Figura 6: consultazione accessibile Figura 7: consultazione estesa Pagina 61 di 193

62 Figura 8: risultato ricerca su Regione Sardegna Pagina 62 di 193

63 Figura 9: elenco dei dataset Pagina 63 di 193

64 GEOSERVER E DEEGREE Pagina 64 di 193

65 GeoServer: caratteristiche generali GeoServer ( è 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 ( 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: O ancora segnalare un baco al seguente indirizzo: 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. ( GeoServer si pone come obiettivi: L apertura dei dati, non una semplice fornitura di immagini: Pagina 65 di 193

66 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). Pagina 66 di 193

67 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 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. Pagina 67 di 193

68 Figura 12: Certificazioni OGC Pagina 68 di 193

69 Figura 13: Client, chi parla con GeoServer Figura 14: Diagramma complessivo di GeoServer Pagina 69 di 193

70 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: Pagina 70 di 193

71 Figura 15: WFS GetCapabilities, sommario e operazioni Figura 16: WFS GetCapabilities, feature types Pagina 71 di 193

72 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) Pagina 72 di 193

73 Figura 19: WFS GetFeature, esempio di richiesta (2) Pagina 73 di 193

74 Figura 20: WFS GetFeature, esempio di richiesta (3) Figura 21: WFS GetFeature, esempio di richiesta (4) Pagina 74 di 193

75 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) Pagina 75 di 193

76 Figura 23: WFS Transaction, schema XML (2) Figura 24: WFS Transaction, esempio di insert Pagina 76 di 193

77 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. Pagina 77 di 193

78 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. Pagina 78 di 193

79 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 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 Pagina 79 di 193

80 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: Pagina 80 di 193

81 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. Pagina 81 di 193

82 Figura 29: WCS DescribeCoverage, una porzione dello schema Pagina 82 di 193

83 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. Pagina 83 di 193

84 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). Pagina 84 di 193

85 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 Pagina 85 di 193

86 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) Pagina 86 di 193

87 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 Pagina 87 di 193

88 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 Pagina 88 di 193

89 Figura 36: SLD schema, line symbolizer Figura 37: SLD schema, polygon symbolizer Pagina 89 di 193

90 Figura 38: SLD schema, point symbolizer Figura 39: SLD schema, text symbolizer Pagina 90 di 193

91 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 Pagina 91 di 193

92 Figura 41: Esempi SLD, con etichette Figura 42: Esempi SLD, con filtri (1) Pagina 92 di 193

93 Figura 43: Esempi SLD, con filtri (2) Figura 44: Esempi SLD, con filtri (3) Pagina 93 di 193

94 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. Pagina 94 di 193

95 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: Pagina 95 di 193

96 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. Pagina 96 di 193

97 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. Pagina 97 di 193

98 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. Pagina 98 di 193

99 Figura 50: Web Coordinate Service (WCTS) Figura 51: I servizi offerti da Degree Pagina 99 di 193

100 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) e Web-Catalogo Service Profilo (CSW) 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 js_pane/download, da cui è possibile scaricare una versione di Deegree 2.1 e delle versioni precedenti (più stabili). Nome Versione scaricabile Documentazione Implementazioni OGC-Standard deegree Web Map Service (WMS) ZIP (157 MB) MD5 PDF go to HTML docs WMS / WMS 1.3 deegree Web Feature Service (WFS) ZIP (17 MB) MD5 PDF go to HTML docs WFS 1.1 deegree Web Coverage Service (WCS) ZIP (117 MB) MD5 PDF go to HTML docs WCS 1.0 Pagina 100 di 193

101 deegree Catalogue Service (CSW) ZIP (17 MB) MD5 PDF go to HTML docs CSW deegree Web Terrain Service (WTS) / Web Perspective View Service (WPVS) ZIP (142 MB) MD5 PDF go to HTML docs Discussion Paper; Pre-Standard Tabella 1: Deegree OGC 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 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 Tabella 2: Deegree OGC 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. Pagina 101 di 193

102 MAPSERVER Pagina 102 di 193

103 Introduzione UMN MapServer ( è 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 Il progetto MapServer aderisce all'open Source Geospatial Foundation (OSGEO - 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 ( è 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,...): Anche il progetto GDAL/OGR aderisce alla fondazione OSGEO. MapServer implementa inoltre diversi standard dell'open Geospatial Consortium (OGC: Pagina 103 di 193

104 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; versioni supportate: 1.0.0, 1.0.7, e Web Feature Service (WFS), sia client che server, nella implementazione nontransactional; versione supportata: Web Coverage Server (WCS), servizio come server; versione supportata: Geography Markup Language (GML); versione supportata: e Web Map Context Documents; versione supportata: Styled Layer Descriptor: versione supportata: Filter Encoding Specification: versione supportata: Pagina 104 di 193

105 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 Pagina 105 di 193

106 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 Pagina 106 di 193

107 Nome formato Arc/Info ASCII Grid ADRG/ARC Digitilized Raster Graphics (.gen/.thf) Arc/Info Binary Grid (.adf) AIRSAR Polarimetric Magellan BLX Topo (.blx,.xlb) Microsoft Windows Device Independent Bitmap (.bmp) BSB Nautical Chart Format (.kap) VTP Binary Terrain Format (.bt) CEOS (Spot for instance) DRDC COASP SAR Processor Raster TerraSAR-X Complex SAR Data Product Spot DIMAP (metadata.dim) First Generation USGS DOQ (.doq) DODS / OPeNDAP New Labelled USGS DOQ (.doq) Military Elevation Data (.dt0,.dt1,.dt2) ERMapper Compressed Wavelets (.ecw) ESRI.hdr Labelled NASA ELAS ENVI.hdr Labelled Raster Envisat Image Product (.n1) EOSAT FAST Format FITS (.fits) GSat File Format Codice AAIGrid ADRG AIG AIRSAR BLX BMP BSB BT CEOS COASP COSAR DIMAP DOQ1 DODS DOQ2 DTED ECW EHdr ELAS ENVI Envisat FAST FITS GFF Pagina 107 di 193

108 Graphics Interchange Format (.gif) WMO GRIB1/GRIB2 (.grb) GMT Compatible netcdf GRASS Rasters Golden Software ASCII Grid Golden Software Binary Grid Golden Software Surfer 7 Binary Grid TIFF / GeoTIFF (.tif) GXF - Grid exchange File Hierarchical Data Format Release 4 (HDF4) Hierarchical Data Format Release 5 (HDF5) Intergraph Raster Vexcel MFF2 Idrisi Raster Image Display and Analysis (WinDisp) ILWIS Raster Map (.mpr,.mpl) GIF GRIB GMT GRASS GSAG GSBG GS7BG GTiff GXF HDF4 HDF5 INGR HKV RST IDA ILWIS JAXA PALSAR Product Reader (Level 1.1/1.5) Japanese DEM (.mem) JPEG JFIF (.jpg) JPEG2000 (.jp2,.j2k) JPEG2000 (.jp2,.j2k) JPEG2000 (.jp2,.j2k) JPEG2000 (.jp2,.j2k) NOAA Polar Orbiter Level 1b Data Set JAXAPALSAR JDEM JPEG JPEG2000 JP2KAK JP2ECW JP2MrSID L1B Pagina 108 di 193

109 (AVHRR) Erdas 7.x.LAN and.gis Daylon Leveller Heightfield In Memory Raster Vexcel MFF Multi-resolution Seamless Image Database Meteosat Second Generation NDF NITF NetCDF OGDI Bridge PCI.aux Labelled PCI Geomatics Database File Portable Network Graphics (.png) PCRaster (.map) Netpbm (.ppm,.pgm) Swedish Grid RIK (.rik) RadarSat2 XML (product.xml) ArcSDE Raster Raster Product Format/RPF (a.toc) USGS SDTS DEM (*CATD.DDF) Raster Matrix Format (*.rsw,.mtw) SAR CEOS SGI Image Format SRTM HGT Format USGS ASCII DEM (.dem) LAN Leveller MEM MFF MrSID MSG NLAPS Data Format NITF netcdf OGDI PAux PCIDSK PNG PCRaster PNM RIK RS2 SDE RPFTOC SDTS RMF SAR_CEOS SGI SRTMHGT USGSDEM Pagina 109 di 193

110 Terragen Heightfield (.ter) TerraSAR-X Product GDAL Virtual (.vrt) OGC Web Coverage Server OGC Web Map Server X11 Pixmap (.xpm) TERRAGEN TSX VRT WCS WMS 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,... Pagina 110 di 193

111 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 SWIG MapScript => Perl, Python, Ruby, Java 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 Pagina 111 di 193

112 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). Pagina 112 di 193

113 Figura 54: Template file Figura 55: pagina generata a partire dal Template file di Figura 54 Pagina 113 di 193

114 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,... Pagina 114 di 193

115 POINTS (n) SYMBOL STYLE (n) LEGEND LABEL SCALEBAR LABEL REFERENCE METADATA PARAMETER (n) MAP 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 Pagina 115 di 193

116 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 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 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 ( docs/howto/wms_server), cioè di offrire il servizio ai client che lo richiedono, sia di essere client WMS ( 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. Pagina 116 di 193

117 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: redatta dall Open Geospatial Consortium. Lo standard OGC-WFS 1.1 sarà introdotto in MapServer 5.2, il cui rilascio è previsto per il luglio 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 ( docs/howto/wfs_server), cioè di offrire il servizio ai client che lo richiedono, sia di essere client WFS ( 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. Pagina 117 di 193

118 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 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: ( Chameleon È un ambiente distribuito e personalizzabile per lo sviluppo di applicazioni web ( scritto in linguaggio PHP. E' stato realizzato dalla società canadese DM Solution ( 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. Pagina 118 di 193

119 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. Pagina 119 di 193

120 Figura 58: Template per Chameleon Pagina 120 di 193

121 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: Pagina 121 di 193

122 Società / Nome software versione server client Cadcor - Cadcorp SIS Active Server Component 6.2 si si Cadcorp SIS Map Server 6.2 si si CARIS - CARIS Spatial Fusion Enterprise si si con terra-applied Information Technologies - sdi.suite mapclient 2.1 no si CubeWerx - CubeSERV Cascading Web Map Server 4.6 si no CubeXPLOR 4.6 no si Google Earth Extension for WMS 1.0 si no Generic Logic - GLG Map Server 2.10 si no Manifold Net - Manifold System 6.50 si si Newgrove - Address Caf 4.2 si no SuperMap GIS Techonologies - SuperMap Deskpro 5.3 no si Tabella 5: software conformi allo standard OGC-WMS 1.3 Pagina 122 di 193

123 Pagina 123 di 193

124 GEODATABASE Pagina 124 di 193

125 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. Pagina 125 di 193

126 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 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. Pagina 126 di 193

127 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: Pagina 127 di 193

128 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 VALUES ( SS118, ); INSERT INTO mia_tabella (nome_strada, strada) GeometryFromText( LINESTRING(2 2, 4 6,., ),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 Pagina 128 di 193

129 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", , ] ], PRIMEM["Greenwich",0], UNIT["degree", ] ], 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 Pagina 129 di 193

130 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. Pagina 130 di 193

131 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. Pagina 131 di 193

132 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 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. Pagina 132 di 193

133 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 I C:\shape\abruzzo_centri_abitati.shp abruzzo_centri_abitati psql -d salvogis -U postgres -h localhost 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 Pagina 133 di 193

134 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 -u postgres -g geom -f abruzzo_centri_abitati.shp salvogis abruzzo_centri_abitati Pagina 134 di 193

135 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 Pagina 135 di 193

136 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 ) 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; Pagina 136 di 193

137 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. Pagina 137 di 193

138 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 Pagina 138 di 193

139 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) ); ) Pagina 139 di 193

140 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. Pagina 140 di 193

141 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 che contengono le informazioni generali del sistema di coordinate. SDO_DATUMS, SDO_ELLIPSOIDS, SDO_PRIME_MERIDIANS che 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. 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. Pagina 141 di 193

142 Figura 66: schema del geodatabse in Oracle Oracle SPATIAL supporta il tipo ST_xxx ISO , 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 Pagina 142 di 193

143 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. Pagina 143 di 193

144 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 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. Pagina 144 di 193

145 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 Pagina 145 di 193

146 //caricamento del control file Figura 69: caricamento dei dati sqlldr 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. Pagina 146 di 193

147 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 Pagina 147 di 193

148 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: Pagina 148 di 193

149 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 Pagina 149 di 193

150 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.. Pagina 150 di 193

151 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. Pagina 151 di 193

152 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. Pagina 152 di 193

153 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: Pagina 153 di 193

154 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. Pagina 154 di 193

155 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: Pagina 155 di 193

156 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. Pagina 156 di 193

157 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 Pagina 157 di 193

158 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. Pagina 158 di 193

159 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. Pagina 159 di 193

160 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 Pagina 160 di 193

161 Una volta inserita l'immagine è possibile visualizzarla selezionandola dall'archivio georaster in MapBuilder, come visibile nella figura 86. Figura 86: Raster Output in Mapbuilder Pagina 161 di 193

162 Tabella riassuntiva di confronto tra PostGIS e ORACLE SPATIAL Installazione PostGIS ORACLE SPATIAL Modalità e difficoltà di installazione L'installazione di PostGIS è molto semplice sia su Windows che su LINUX. L'installazione guidata indica quali servizi bisogna installare affinché il database funzioni correttamente. 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. Funzionalità Tipi vettoriale Supporta i vari elementi geometrici di un layer vettoriale: 1. punti 2. linee 3. poligoni 4. multipunti Supporta i vari elementi geometrici di un layer vettoriale: 1. punti 2. linee 3. poligoni 4. archi Pagina 162 di 193

163 5. multilinee 6. multipoligoni 7. geometrie composte (punti + linee, linee + poligoni, ecc..) 5. poligoni di archi 6. poligoni composti 7. linee composte 8. circonferenze Operazioni topologiche Operazioni geometriche Proprietà delle geometrie Gestione del sistema di coordinate Fornisce funzioni che permettono di fare le operazioni topologiche: inclusione, intersezione, adiacenza,... Permette di eseguire il calcolo della distanza delle geometrie, l'unione, la differenza e le intersezioni delle geometrie. Fornisce funzioni per il calcolo di aree, perimetri, centroidi, lunghezza... Supporta diversi sistemi di riferimento, grazie alle librerie proj4. 9. rettangoli Fornisce funzioni che permettono di fare le operazioni topologiche: inclusione, intersezione, adiacenza,... Permette di eseguire il calcolo della distanza delle geometrie, l'unione, la differenza e le intersezioni delle geometrie. Fornisce funzioni per il calcolo di aree, perimetri, centroidi, lunghezza... Supporta diversi sistemi di riferimento. Indicizzazione delle geometrie Permette di creare indici (del tipo GiST) sulle geometrie. Supporta un indice R-Tree (approssimazione mediante un rettangolo minimo di contenimento) per le geometrie. Import e export dei dati vettoriali Supporto raster Supporto per importare ed esportare i dati vettoriali nel formato shape ESRI 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 Supporto per importare ed esportare i dati nel formato shape ESRI 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 Pagina 163 di 193

164 raster sono: (anche multibanda). PGCHIP che utilizza le librerie 'gdal'. PGRASTER di Xlin che supportano l'importazione e esportazione dei TIFF monobanda. SPATIAL supporta il modello a piramidi per i raster. Import e export dei raster Operazioni sui raster Vari tools non standard che fanno uso delle librerie 'gdal'. Non fornite dalla distribuzione di PostGIS. I formati di importazione e esportazione sono i seguenti: TIFF, GeoTIFF, JPEG, BMP, GIF, PNG e JP2. Esistono diverse funzioni che 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. Pagina 164 di 193

165 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 Pagina 165 di 193

166 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. Pagina 166 di 193

167 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 Pagina 167 di 193

168 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. Pagina 168 di 193

169 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 Pagina 169 di 193

170 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 Pagina 170 di 193

171 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", , ]], Pagina 171 di 193

172 PRIMEM["Greenwich",0],UNIT["Degree", ]], PROJECTION["Transverse_Mercator"],PARAMETER["False_Easting", ], 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, , Pagina 172 di 193

173 , 10000, , 10000, 9.999E35, E35, 9.999E35, E35, 9.999E35, E35, 9.999E35, E35, 4269, WKT 'GCS_North_American_1983', 'PROJECTED', NULL, 'GEOGCS["GCS_North_American_1983",DATUM["D_North_American_1983",SPHEROID["GRS_198 0", , ]],PRIMEM["Greenwich",0.0],UNIT["Degree", ]]', 'ArcSDE SpRef' ); inserimento delle feature nella tabella con la colonna geometrica: INSERT INTO sensitive_areas VALUES ( 1, 'Summerhill Elementary School', , WKT 'school', ST_PolyFromText('polygon ((52 28,58 28,58 23,52 23,52 28))',1)); Pagina 173 di 193

174 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 Il primo passo da eseguire è la creazione della connessione con il geodatabase, come mostrato in figura 95: Figura 95: Connessione al Db Pagina 174 di 193

175 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. Pagina 175 di 193

176 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: Pagina 176 di 193

177 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; Pagina 177 di 193