ICAD-GEO. STUDIO DI FATTIBILITÀ PER LA REALIZZAZIONE DI UN PROGETTO PER LA REALIZZAZIONE DI UNA "INFRASTRUTTURA PER LA COOPERAZIONE APPLICATIVA ...
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Data emissione: 29 luglio 2008
Codice: CI08-03-1.0
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
Gruppo di lavoro Lotto 4: “Studio di fattibilità di infrastruttura per la cooperazione applicativa di dati geografici”
Verso un modello di SDI
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. Fabrizio Niceta;
- Ing. Salvatore Lattuca.
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.
Nome file: report3.odt
Data emissione: 31 luglio 2008
Codice: CI08-03-1.0
Pagina 2 di 66
Progetto di ricerca del Centro Interregionale di Coordinamento e documentazione per le informazioni territoriali
Gruppo di lavoro Lotto 4: “Studio di fattibilità di infrastruttura per la cooperazione applicativa di dati geografici”
Verso un modello di SDI
Titolo documento Verso un modello 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 31 luglio 2008
Soggetto Applicazioni GIS e WEB-GIS
Editore Centro Interregionale di Coordinamento e documentazione
per le informazioni territoriali
Tipo Testo
Descrizione Il documento descrive l'utilizzo dei software RDBMS e di
strumenti software tipo mapserver per la implementazione di
geoservizi e quindi per la realizzazione di infrastrutture dati
geografiche (SDI)
Contributi
Formato Openoffice .ODT
Riferimento
Identificatore report3-5_pub
Lingua Italiano
Relazioni
Estensione temporale 10 mesi
Estensione spaziale Italia
Nome file: report3.odt
Data emissione: 31 luglio 2008
Codice: CI08-03-1.0
Pagina 3 di 66
Progetto di ricerca del Centro Interregionale di Coordinamento e documentazione per le informazioni territoriali
Gruppo di lavoro Lotto 4: “Studio di fattibilità di infrastruttura per la cooperazione applicativa di dati geografici”
Verso un modello di SDI
Indice generale
PIATTAFORMA DI TEST DELLE FUNZIONALITÀ DEI RDBMS....................................10
Test di funzionalità RDBMS.....................................................................................................12
Intersezione...........................................................................................................................13
Contenimento........................................................................................................................16
Contatto.................................................................................................................................18
Conclusioni sulla fase di test dei RDBMS............................................................................19
I GEOSERVIZI.........................................................................................................................22
GEOSERVIZI WMS E GESTIONE METADATI CON UNM MAPSERVER..................23
Introduzione......................................................................................................................24
WMS per dati a scala comunale: l'esempio del Comune di Desio...................................24
WMS per dati a scala regionale: l'esempio della Regione Sardegna................................35
Accesso ai Geoservizi realizzati.......................................................................................37
WMS client on-line...........................................................................................................40
WMS client desktop..........................................................................................................41
L'archivio dei metadati..........................................................................................................42
Accesso ai metadati tramite protocollo CS-W..................................................................43
Riferimenti........................................................................................................................45
GEOSERVIZI WFS E WMS CON GEOSERVER.............................................................46
Introduzione......................................................................................................................47
Il geoservizio WFS............................................................................................................47
Il geoservizio WMS..........................................................................................................48
GEOSERVIZI WFS BASATI SU RDBMS CON ESTENSIONI SPAZIALI.....................51
IPOTESI DI MODELLO DI INFRASTRUTTURA NAZIONALE BASATA SU
SOFTWARE LIBERO E OPEN SOURCE..............................................................................56
ANALISI COSTI BENEFICI...................................................................................................60
CONCLUSIONI........................................................................................................................65
Nome file: report3.odt
Data emissione: 31 luglio 2008
Codice: CI08-03-1.0
Pagina 4 di 66
Progetto di ricerca del Centro Interregionale di Coordinamento e documentazione per le informazioni territoriali
Gruppo di lavoro Lotto 4: “Studio di fattibilità di infrastruttura per la cooperazione applicativa di dati geografici”
Verso un modello di SDI
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à:
1. Università degli Studi di Palermo - Dip.to di Rappresentazione
- Ing. Andrea Scianna (coord. tecnico);
- Ing. Alessio Ammoscato.
- Dott. Fabrizio Niceta
- Ing. Salvatore Lattuca.
2. Politecnico di Milano, Polo di Como - Dip.to DIIAR
- Prof. Maria Antonia Brovelli (coord. locale);
- 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 (coord. locale);
- 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);
Nome file: report3.odt
Data emissione: 31 luglio 2008
Codice: CI08-03-1.0
Pagina 5 di 66
Progetto di ricerca del Centro Interregionale di Coordinamento e documentazione per le informazioni territoriali
Gruppo di lavoro Lotto 4: “Studio di fattibilità di infrastruttura per la cooperazione applicativa di dati geografici”
Verso un modello di SDI
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 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 alle fasi 4, 5 e 6.
------
Nel precedente report sono state illustrate tutte le componenti disponibili per la realizzazione
di un'infrastruttura dati geografici basata sul possibile utilizzo di strumenti software FOSS
(Free/Open-Source Software ) e GFOSS (Geographic Free/Open-Source Software ) . E' stato
inoltre preso in considerazione un software tipo RDBMS commerciale proprietario come
Oracle, di cui è stata rilevata l'utilizzazione in alcuni progetti, a carattere regionale o
interregionale, avviati dalle regioni Italiane per come riportato nel report n°1.
Pertanto a fini del riuso si ritiene che Oracle, purchè dotato di estensione SPATIAL ed
aggiornato alla versione 11G Enterprise, possa essere una piattaforma software utilizzabile in
alternativa ad un analogo strumento FOSS come PostgresSQL con la sua estensione spaziale -
GFOSS – PostGIS.
Sulla base di quanto avvenuto nella fasi precedenti della ricerca, nelle fasi di cui al presente
report sono state prese valutate le possibilità di realizzazione di una 'spatial data infrastructure'
(SDI) basata sull'utilizzo totale di software GFOSS o su una configurazione mista
comprendente anche software commerciale.
Ancor prima di parlare delle risorse da utilizzare è utile ribadire che alla base dell’esistenza e
del funzionamento di un’Infrastruttura Dati Territoriali, ad un più alto livello, stanno
l’insieme di accordi politico-amministrativi che permetteranno la gestione, la condivisione e
l’interscambio dei dati della SDI, fra Enti ed utenti pubblici e privati interessati, che potranno
anche essere resi disponibili agli utenti esterni.
Per quanto riguarda le risorse, si fa riferimento ovviamente a tutte quelle che possono essere
le componenti di un'Infrastruttura dati geografica caratterizzata, tramite i suoi componenti
software, dalle funzioni di :
● consultazione e/o download dei metadati;
● consultazione dei dati , tramite applicazione WEB-GIS, sulla base delle selezione
operata tramite i metadati;
● download dei dati sulla base delle selezione operata tramite i metadati;
Nome file: report3.odt
Data emissione: 31 luglio 2008
Codice: CI08-03-1.0
Pagina 6 di 66
Progetto di ricerca del Centro Interregionale di Coordinamento e documentazione per le informazioni territoriali
Gruppo di lavoro Lotto 4: “Studio di fattibilità di infrastruttura per la cooperazione applicativa di dati geografici”
Verso un modello di SDI
● attivazione di servizi web per l'accesso ai dati secondo modalità standardizzate e tali
da permettere l'utilizzo dei dati sia tramite software GIS desktop con funzionalità di
accesso tramite web-service che tramite applicazioni web-gis.
Schema semplificato di interazione dei componenti software principali di una SDI con
le relative funzioni
L'SDI si caratterizza in particolare per la possibilità di accesso alle informazioni tramite
procedure standardizzate a differenza di quanto avviene con le applicazioni WEBGIS. Inoltre
l'aspetto della cooperatività di dati e funzioni è garantito tramite gli application server che
implementano sostanzialmente due tipi di servizi
WEB Service e Geoservice
- Standard (secondo le specifiche OGC - ISO);
- non standard, per il settore dell’informazione geografica, ma aderenti comunque alla gamma
dei WEB Service standardizzati
In ambiente WEB grazie alle tecnologie dei web service, esistono già dei servizi con delle
specifiche stabilite dall'OGC che permettono l'integrazione di diverse piattaforme e che si
appoggiano al web. Essi sono:
- Web Feature Service per l'estrazione (WFS) e la modifica (WFS-Transactional) di feature
ovvero oggetti geografici archiviati in modo vettoriale.
Nome file: report3.odt
Data emissione: 31 luglio 2008
Codice: CI08-03-1.0
Pagina 7 di 66
Progetto di ricerca del Centro Interregionale di Coordinamento e documentazione per le informazioni territoriali
Gruppo di lavoro Lotto 4: “Studio di fattibilità di infrastruttura per la cooperazione applicativa di dati geografici”
Verso un modello di SDI
- Web Coverage Service (WCS) per l’accesso e manutenzione di dati geografici raster o
grid..
– Web Map Service (WMS) rende disponibili mappe (come immagini) di dati geografici.
Oltre a questi servizi è possibile estendere il sistema con diversi altri geoservizi attraverso la
progettazione di nuovi moduli web service utilizzando esclusivamente strumenti opensource,
anche interfacciabili anche con prodotti commerciali come ORACLE. Ad esempio è possibile
realizzare un geo-servizio utilizzando i seguenti strumenti (tutti opensource):
APACHE (web server/HTTP)
lTOMCAT (contenitore delle servlet JAVA)
lJ2EE (JAVA 2 enterprise edition)
lJSP (JAVA SERVER PAGE)
lGeoServer (Mapserver)
In ogni caso i vari servizi hanno accesso ad una banca dati dai quali viene estratta
l'informazione richiesta. Il database server è pertanto è un componente fondamentale di
un'infrastruttura dati, che sta alla base del corretto ed efficiente funzionamento del sistema. Le
soluzioni per l'archiviazione come illustrato sono diverse e le più idonee sono ORACLE
SPATIAL (soluzione commerciale proprietaria) e POSTGIS (GFOSS).
Questi prodotti seguono le specifiche dell'OGC. In un’infrastruttura dati ORACLE e
POSTGIS possono condividere i dati, in quanto forniscono tutto il supporto in termini di
driver e librerie di sviluppo per l'interfacciamento alla loro piattaforma. Questo ovviamente è
ciò che garantisce la possibilità, al servizio web, di connettersi a diverse piattaforme RDBMS.
Nome file: report3.odt
Data emissione: 31 luglio 2008
Codice: CI08-03-1.0
Pagina 8 di 66
Progetto di ricerca del Centro Interregionale di Coordinamento e documentazione per le informazioni territoriali
Gruppo di lavoro Lotto 4: “Studio di fattibilità di infrastruttura per la cooperazione applicativa di dati geografici”
Verso un modello di SDI
Per quanto riguarda le principali sezioni a livello di operatività dell'infrastruttura, questa può
essere vista come costituita fondamentalmente da tre parti di cui la prima parte relativa alla
fruizione dell'informazione geografica, la seconda parte relativa all'archiviazione ed
all'accesso alle informazioni e la terza parte relativa alla produzione intesa quest'ultima come
implementazione e gestione della banca dati.
Nel presente report pertanto saranno illustrati i geoservizi attivati a livello sperimentale nel
corso della ricerca nei server dei laboratori universitari, al fine di testare ed mostrare la
fattibilità di talune soluzioni; quindi sulla base di un possibile modello di cui è proposto lo
schema, viene condotta un analisi costi benefici.
Nome file: report3.odt
Data emissione: 31 luglio 2008
Codice: CI08-03-1.0
Pagina 9 di 66
Progetto di ricerca del Centro Interregionale di Coordinamento e documentazione per le informazioni territoriali
Gruppo di lavoro Lotto 4: “Studio di fattibilità di infrastruttura per la cooperazione applicativa di dati geografici”
Verso un modello di SDI
PIATTAFORMA DI TEST DELLE FUNZIONALITÀ DEI RDBMS
In questa fase del progetto si confrontano e si illustrano a parità di stack tecnologico le
prestazioni di ciascun database spaziale a seguito di diverse interrogazioni più o meno
complesse.
Per questi test il primo step fondamentale è stato configurare una workstation con i server
RDBMS dotati di estensioni spaziali per la gestione di database geografici.
La configurazione Hardware della macchina è la seguente:
● Sistema : Dell Inc. Precision WorkStation T3400
● Processore : Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz
● Mainboard : Dell Inc. 0TP412
● Modello : Dell X38 Processor to I/O Controller
● Memoria Totale : 4GB ECC DIMM DDR2
● Sistema Video: NVIDIA Quadro FX 1700 (512MB DDR2,
191MHz/444MHz/2x799MHz, PCIe 1.00 x16, PS3.0, VS3.0)
● Disco Rigido (C:) : 466GB (NTFS) @ ST3500630AS 500GB (SATA300, 3.5", NCQ,
16MB Cache)
● CD-ROM/DVD (D:) : N/A @ HL-DT-STDVD-ROM GDRH20N (SATA300, DVD+-
R, CD-R, NCQ, 16MB Cache)
● CD-ROM/DVD (E:) : N/A @ HL-DT-STDVD+-RW GSA-H73N (SATA300, DVD+-
RW, CD-RW, NCQ, 16MB Cache)
● Stampante : Canon iP4300 (USB, Gestione colori immagine)
● Camera : Periferica video USB (USB)
● Adattatori di Rete : Broadcom NetXtreme 57xx Gigabit Controller - Miniport
dell'Utilità di pianificazione pacchetti (Ethernet, 100Mbps)
Nome file: report3.odt
Data emissione: 31 luglio 2008
Codice: CI08-03-1.0
Pagina 10 di 66Progetto di ricerca del Centro Interregionale di Coordinamento e documentazione per le informazioni territoriali
Gruppo di lavoro Lotto 4: “Studio di fattibilità di infrastruttura per la cooperazione applicativa di dati geografici”
Verso un modello di SDI
PRIMA Soluzione Software utilizzata:
● Sistema Operativo: Microsoft Windows XP (2002) Professional 5.01.2600 (Service
Pack 3),
● DBMS ORACLE database Enterprise 11g
● Estensione spaziale ORACLE Spatial
● PostgreSLQ 8.3
● Estensione spaziale: PostGIS 1.3.3
● UNM Mapserver
● Java Platform 6 – Standard Edition
● Java Development Kit 6
● Driver JDBC per Postgres: postgresql-8.3-603.jdbc4.jar
● Driver JDBC per ORACLE: ojdbc6.jar
SECONDA Soluzione Software utilizzata:
● Sistema Operativo: Kubuntu Linux 7.10
● PostgreSLQ 8.3
● Estensione spaziale: PostGIS 1.3.3
● UNM Mapserver
● Java Platform 6 – Standard Edition
● Java Development Kit 6
● Driver JDBC per Postgres: postgresql-8.3-603.jdbc4.jar
● Driver JDBC per ORACLE: ojdbc6.jar
Il secondo passo consiste nel popolare i database configurati con un set dati eguali per
entrambe le piattaforme, dati ovviamente di diversa tipologia e dimensione.
Nome file: report3.odt
Data emissione: 31 luglio 2008
Codice: CI08-03-1.0
Pagina 11 di 66Progetto di ricerca del Centro Interregionale di Coordinamento e documentazione per le informazioni territoriali
Gruppo di lavoro Lotto 4: “Studio di fattibilità di infrastruttura per la cooperazione applicativa di dati geografici”
Verso un modello di SDI
TEST DI FUNZIONALITÀ RDBMS
In questa fase del progetto si valutano le funzionalità dei RDBMS dotati di estensioni spaziali.
Come detto nei precedenti report oggi esistono diversi RDBMS per la gestione di dati
geografici; si hanno sia delle piattaforme commerciali proprietarie che libero ed open-source.
Tra le piattaforme commerciali sono state illustrate le funzionalità di due prodotti: ORACLE
SPATIAL e ARCSDE con SQLServer.
Relativamente alle piattaforme libere ed open source sono state illustrate le funzionalità di
POSTGRES con estensione spaziale Postgis.
Queste piattaforme seguono le specifiche OGC per i dati spaziali che danno indicazione sui
tipi e sulle funzioni necessarie per rappresentare in maniera esaustiva le informazioni
geografiche. Naturalmente ognuno dei RDBMS implementa i propri “tipi” con metodologie
proprie; esistono quindi delle differenze per quando riguarda la prestazione del sistema
informativo territoriale dovute appunto all'efficienza ed efficacia degli algoritmi e delle
funzioni utilizzate per realizzare i tipi spaziali. In relazione alla valutazione delle funzionalità,
PostGIS e ORACLE SPATIAL prevedono dei tipi specifici per i dati spaziali che sono nativi
nei rispettivi sistemi, mentre ARCSDE è un applicazione middleware che si interfaccia tra
l'applicazione client e il RDBMS quindi le prestazioni del database spaziale dipendono dalle
caratteristiche del server RDBMS a cui è connesso ARCSDE.
Pertanto, confronti prestazionali valutabili potrebbero essere condotte per PostGIS e
ORACLE SPATIAL in quanto esse non sono applicazione middle-ware, ma sono dei
software RDBMS server caratterizzati da architettura propria e funzionamento indipendente
da altri software.
I test sono effettuati con lo scopo di valutare le funzionalità delle query spaziali più comuni
quali ad esempio intersezioni, contatto e contenimento.
Per effettuare i test sono state avviate, da terminale sql, diverse query spaziali; che sono state
riportate di seguito; talvolta le query hanno tempi elevati di risposta al primo avvio (ciò può
essere dovuto a problemi di bufferizzazione del sistema operativo); pertanto per essere certi
che la query funziona correttamente è bene lanciare più volte la stessa query.
I test sono stati eseguiti su due database strutturati in Oracle Spatial e Postgis contenenti le
stesse informazioni. In particolare i dati sono dei layer vettoriali di diverso tipo: layer
composti da poligoni, linee, punti e ecc..
Ogni layer oltre al dato geometrico ha una serie di attributi associati ad esso che consistono in
diverse colonne di tipi di dati diversi.
I database scelti per i test contengono i seguenti dati:
1. Layer dei bacini della regione Abruzzo. Sono dei poligoni che rappresentano i bacini
della regione Abruzzo. È composto da 33 feature (poligoni)
2. Layer dei centri abitati della regione Abruzzo. È composto da 305 geometrie
(poligoni).
3. Layer dei confini provinciali della regione Abruzzo. È composto da 4 geometrie
(poligoni).
4. Layer delle unità edilizie della regione Abruzzo. È composto da 2232 geometrie
(punti).
5. Layer delle scuole della regione Abruzzo. È composto da 2232 geometrie (punti).
6. Layer dei confini comunali della zona NASO (provincia di Messina-Catania-Palermo).
È compost da 177 geometrie (poligoni).
7. Layer dei fiumi di NASO. È composto da 1867 geometrie (linee)
Nome file: report3.odt
Data emissione: 31 luglio 2008
Codice: CI08-03-1.0
Pagina 12 di 66Progetto di ricerca del Centro Interregionale di Coordinamento e documentazione per le informazioni territoriali
Gruppo di lavoro Lotto 4: “Studio di fattibilità di infrastruttura per la cooperazione applicativa di dati geografici”
Verso un modello di SDI
8. Layer delle curve di livello della Sicilia quotate ogni 10 metri. È composto da 331
geometrie (linee)
9. Layer delle curve di livello della Sicilia quotate ogni 20 metri. È composto da 165
geometrie (linee)
10. Layer delle curve di livello della Sicilia quotate ogni 100 metri. È composto da 33
geometrie (linee).
Le query per effettuare i test quindi svolgono le stesse operazioni sia su PostGIS sia su
ORACLE restituendo gli stessi risultati.
I test valutano la prestazioni di tre query spaziali più comuni:
● Intersezione.
● Contatto.
● Contenimento.
I test consistono in una serie di query SQL che utilizzano le particolari funzioni spaziali che
sono disponibili in Postgres + PostGIS e ORACLE Spatial.
Intersezione
Questi test verificano la funzionalità di una query spaziale basata sull'intersezione delle
geometrie.
Test 1
Il primo test verifica l'intersezione di un poligono con un curva. In questo caso consideriamo
l'intersezione di un comune della zona di naso (ME) con una curva di livello.
La query eseguita su PostGIS è la seguente:
select b.comune
from sicilia_curve_100m a, comuni_naso b
where ST_Intersects(A.the_geom,B.the_geom)=true AND a.contour=100 and
b.comune='Milazzo'
Nome file: report3.odt
Data emissione: 31 luglio 2008
Codice: CI08-03-1.0
Pagina 13 di 66Progetto di ricerca del Centro Interregionale di Coordinamento e documentazione per le informazioni territoriali
Gruppo di lavoro Lotto 4: “Studio di fattibilità di infrastruttura per la cooperazione applicativa di dati geografici”
Verso un modello di SDI
La query eseguita su ORACLE è la seguente:
select b.comune
from curve_sicilia_100m a, comuni_naso b
where SDO_OVERLAPBDYDISJOINT(A.geometry,B.geometry)='TRUE' AND
a.contour=100 and b.comune='Milazzo'
Queste due query eseguono la stessa operazione e individuano se il perimetro del Comune di
Milazzo interseca la curva di livello a quota 100 metri.
E' da notare che in questa query non vengono effettuate operazioni di ricerca in quanto il
poligono del comune di Milazzo e la curva a quota 100 metri sono ben definite nella clausola
WHERE della query.
Un altro possibile test potrebbe essere di individuare i comuni che hanno nel loro territorio
quote che stanno al sopra o al di sotto di una determinata altezza. In questo caso i DBMS
dovranno verificare diverse intersezioni; tale tipo di test richiederebbe un maggiore carico
computazionale ed i tempi di risposta di PostGIS e ORACLE sarebbero certamente più
elevati.
Test 2
Il secondo test per le Intersezioni è relativo alla verifica dell'intersezione fra due poligoni. In
questo test si considerano i layer dei limiti provinciali della regione Abruzzo e il layer dei suoi
bacini. Si vogliono individuare i bacini che sono presenti all'interno di una provincia e in
particolare si è scelto di individuare i bacini della provincia di Pescara.
La query eseguita su PostGIS è la seguente:
select a.cr73_nome
from abruzzo_bacini a, abruzzo_lim_provinciali b
where cpc60_nome='PESCARA' and St_intersects(b.the_geom,a.the_geom)
La query eseguita su ORACLE è la seguente:
select a.cr73_nome
Nome file: report3.odt
Data emissione: 31 luglio 2008
Codice: CI08-03-1.0
Pagina 14 di 66Progetto di ricerca del Centro Interregionale di Coordinamento e documentazione per le informazioni territoriali
Gruppo di lavoro Lotto 4: “Studio di fattibilità di infrastruttura per la cooperazione applicativa di dati geografici”
Verso un modello di SDI
from s3_cr73g_bacini a, s3_cpc60g_lim_provinciale b
where cpc60_nome='PESCARA' and
SDO_OVERLAPBDYINTERSECT(b.shape,a.cr73_geometria)='TRUE'
in questo caso viene verificata l'intersezione fra due poligoni. La query estrae i nomi dei
bacini che si trovano nella provincia di pescara. Il risultato è di 6 bacini che che fanno parte
del territorio della provincia di Pescara.
In questo caso le geometrie in esame erano di una complessità minore rispetto alle curve di
livello della Sicilia. Quindi si è osservato un calo sensibile dei tempi di risposta.
Test 3
Il terzo test sulle intersezioni, verifica di nuovo l'intersezione di una linea con dei poligoni,
ma stavolta si esegue il test su delle linee meno complesse delle curve di livello.
I layer scelti sono “fiumi_naso” che contiene tutti i fiumi dell'area costiera nord della
Sicilia nell'intorno di Naso e “comuni_naso” che contiene tutti i perimetri dei comuni
dell'area costiera nord della Sicilia limitrofi al Comune di Naso;
Esempio: si vogliono individuare tramite la query seguente, i fiumi che attraversano il
comune di Brolo.
La query eseguita su PostGIS è la seguente:
select a.nome
from fiumi_naso a, comuni_naso b
where b.comune='Brolo' and st_intersects(a.the_geom,b.the_geom) or
st_contains(a.the_geom,b.the_geom)
La query eseguita su ORACLE è la seguente:
select a.nome
from fiumi_naso a, comuni_naso b
where b.comune='Brolo' and
sdo_overlapbdydisjoint(a.geometry,b.geometry)='TRUE' or
sdo_contains(a.geometry,b.geometry)='TRUE'
Nome file: report3.odt
Data emissione: 31 luglio 2008
Codice: CI08-03-1.0
Pagina 15 di 66Progetto di ricerca del Centro Interregionale di Coordinamento e documentazione per le informazioni territoriali
Gruppo di lavoro Lotto 4: “Studio di fattibilità di infrastruttura per la cooperazione applicativa di dati geografici”
Verso un modello di SDI
i fiumi che attraversano il territorio del comune di Brolo sono 2 e sono ottenuti grazie alle
funzioni spaziali di PostGIS e ORACLE, rispettivamente st_intersects() e
sdo_overlapbdydisjoint() che individuano se due geometrie si intersecano o meno.
Contenimento
dopo aver valutato le funzionalità per le intersezioni, in questo paragrafo verranno illustrati
alcuni test sulle operazioni topologiche di contenimento di due geometrie. Saranno eseguite
delle query su PostGIS e su ORACLE che dovranno dare gli stessi risultati.
Test 1
L'operazione di contenimento è un operazione che viene utilizzata spesso nelle query spaziali
in quanto permettono di verificare un territorio ha determinate caratteristiche o sono presenti
oggetti geografici specifici emergenze di pubblica utilità.
Si può verificare ad esempio la presenza di stazioni di polizia in un territorio, il numero di
farmacie, il numero di alberghi, ecc... operazione applicabile quindi ai casi più svariati
In questo primo test si vogliono individuare le scuole esistenti nella provincia di Teramo.
In pratica si verifica il contenimento di elementi puntuali – le scuole- presenti all'interno dei
confini della Provincia di Teramo.
La query eseguita da PostGIS è la seguente:
select a.cpc03_id_u
Nome file: report3.odt
Data emissione: 31 luglio 2008
Codice: CI08-03-1.0
Pagina 16 di 66Progetto di ricerca del Centro Interregionale di Coordinamento e documentazione per le informazioni territoriali
Gruppo di lavoro Lotto 4: “Studio di fattibilità di infrastruttura per la cooperazione applicativa di dati geografici”
Verso un modello di SDI
from abruzzo_scuole a, abruzzo_lim_provinciali b
where cpc60_nome='TERAMO' and st_contains (b.the_geom,a.the_geom)
La query eseguita con ORACLE è la seguente:
select a.cpc03_id_ue
from s3_cpc03g_scuole a, s3_cpc60g_lim_provinciale b
where cpc60_nome='TERAMO' and SDO_CONTAINS(b.shape,a.shape)='TRUE'
l'operazione di contenimento viene eseguita dalle funzioni st_contains() e sdo_contains
rispettivamente di PostGIS e di ORACLE.
Queste operazione individua 486 elementi.
Test 2
Il secondo test di contenimento viene eseguito insieme con una operazione di conteggio. In
questo caso dopo aver verificato il contenimento, viene eseguito un conteggio del numero di
elementi individuati. Non si tratta in questo caso di una query solamente spaziale, ma è un
query con un'operazione di conteggio che viene spesso utilizzata in vari contesti applicativi
tipici del trattamento dell'informazione geografica.
Il test consiste nel contare le zone abitate all'interno della provincia di Teramo. In questo caso
si verifica inizialmente il contenimento di un poligono dentro un altro poligono.
le zone evidenziate in rosso sono i centri abitati che possono essere comuni o centri abitati di
minore importanza.
La query eseguita su PostGIS è la seguente:
select count(a.cpc63_nome)
from abruzzo_centri_abitati a, abruzzo_lim_provinciali b
where b.cpc60_nome='TERAMO' and st_contains(b.the_geom,a.the_geom)
La query eseguita su ORACLE è la seguente:
select count(a.cpc63_nome)
from s3_cpc63g_centri_abitati a, s3_cpc60g_lim_provinciale b
where b.cpc60_nome='TERAMO' and sdo_contains(b.shape,a.shape)='TRUE'
count() nella clausola SELECT è la funzione di conteggio di SQL.
Nome file: report3.odt
Data emissione: 31 luglio 2008
Codice: CI08-03-1.0
Pagina 17 di 66Progetto di ricerca del Centro Interregionale di Coordinamento e documentazione per le informazioni territoriali
Gruppo di lavoro Lotto 4: “Studio di fattibilità di infrastruttura per la cooperazione applicativa di dati geografici”
Verso un modello di SDI
In questo caso l'operazione di conteggio richiedeva un maggior impiego delle risorse
hardware.
Contatto
I test sono stati eseguiti anche per le operazioni di contatto che vengono di solito utilizzate
per verificare la presenza di oggetti geografici confinanti con altri.
Test 1
Il primo test verifica, dato un comune, i comuni confinanti con esso, e pertanto i territori dei
comuni devono avere una relazione topologica di contatto.
In prima istanza si vogliono verificare i comuni confinanti con il comune di Torregrotta,
comune della zona di NASO in provincia di Messina.
Il layer dei comuni è visualizzato nella figura seguente, con il comune di Torregrotta
evidenziato.
La query eseguita su PostGIS è la seguente:
select a.comune
from comuni_naso a, comuni_naso b
where ST_Touches(A.the_geom,B.the_geom)=true AND b.comune='Torregrotta'
La query eseguita su ORACLE è la seguente:
select a.comune
from comuni_naso a, comuni_naso b
where SDO_TOUCH(A.geometry,B.geometry)='TRUE' AND b.comune='Torregrotta'
Il comune di Torregrotta confina con 3 comuni. Le funzioni di st_touches e sdo_touch sono
rispettivamente le funzioni ORACLE e di PostGIS che verificano se i contorni di due
geometrie sono a contatto.
Nome file: report3.odt
Data emissione: 31 luglio 2008
Codice: CI08-03-1.0
Pagina 18 di 66Progetto di ricerca del Centro Interregionale di Coordinamento e documentazione per le informazioni territoriali
Gruppo di lavoro Lotto 4: “Studio di fattibilità di infrastruttura per la cooperazione applicativa di dati geografici”
Verso un modello di SDI
Test 2
Il secondo test per il contatto viene eseguita sullo stesso layer, ma si è scelto un comune nelle
zone interne che avesse un territorio confinante con più comuni in modo che le relazioni da
contatto da verificare fossero in numero superiore. Il comune scelto è Petralia Sottana.
La query eseguita da PostGIS è la seguente:
select a.comune
from comuni_naso a, comuni_naso b
where ST_Touches(A.the_geom,B.the_geom)=true AND b.comune='Petralia
Sottana'
La query eseguita ORACLE è la seguente:
select a.comune
from comuni_naso a, comuni_naso b
where SDO_TOUCH(A.geometry,B.geometry)='TRUE' AND b.comune='Petralia
Sottana'
Il comune di Petralia Sottana confina con altri 11 territori comunali. Di conseguenza le
relazioni di contatto che la query ha dovuto verificare sono state in numero superiore; quindi
rispetto al test precedente aumenta il carico di lavoro computazionale della query, ma la query
in entrambi i casi va a buon fine.
Conclusioni sulla fase di test dei RDBMS
I test hanno valutato l'efficienza delle funzioni spaziali di PostGIS e ORACLE.
I software si comportano per lo più in modo regolare. In taluni casi si sono verificati
rallentamenti nelle risposte probabilmente dovuti ai diversi algoritmi che i software utilizzano
per i diversi tipi di query spaziali.
Nome file: report3.odt
Data emissione: 31 luglio 2008
Codice: CI08-03-1.0
Pagina 19 di 66Progetto di ricerca del Centro Interregionale di Coordinamento e documentazione per le informazioni territoriali
Gruppo di lavoro Lotto 4: “Studio di fattibilità di infrastruttura per la cooperazione applicativa di dati geografici”
Verso un modello di SDI
In generale si può affermare che entrambi i software RDBMS sono idonei in termini di
funzionalità all'utilizzo come gestori di informazioni geografiche, per un uso professionale.
Nome file: report3.odt
Data emissione: 31 luglio 2008
Codice: CI08-03-1.0
Pagina 20 di 66Progetto di ricerca del Centro Interregionale di Coordinamento e documentazione per le informazioni territoriali
Gruppo di lavoro Lotto 4: “Studio di fattibilità di infrastruttura per la cooperazione applicativa di dati geografici”
Verso un modello di SDI
Nome file: report3.odt
Data emissione: 31 luglio 2008
Codice: CI08-03-1.0
Pagina 21 di 66Progetto di ricerca del Centro Interregionale di Coordinamento e documentazione per le informazioni territoriali
Gruppo di lavoro Lotto 4: “Studio di fattibilità di infrastruttura per la cooperazione applicativa di dati geografici”
Verso un modello di SDI
I GEOSERVIZI
Nome file: report3.odt
Data emissione: 31 luglio 2008
Codice: CI08-03-1.0
Pagina 22 di 66Progetto di ricerca del Centro Interregionale di Coordinamento e documentazione per le informazioni territoriali
Gruppo di lavoro Lotto 4: “Studio di fattibilità di infrastruttura per la cooperazione applicativa di dati geografici”
Verso un modello di SDI
GEOSERVIZI WMS E GESTIONE METADATI CON UNM MAPSERVER
Nome file: report3.odt
Data emissione: 31 luglio 2008
Codice: CI08-03-1.0
Pagina 23 di 66Progetto di ricerca del Centro Interregionale di Coordinamento e documentazione per le informazioni territoriali
Gruppo di lavoro Lotto 4: “Studio di fattibilità di infrastruttura per la cooperazione applicativa di dati geografici”
Verso un modello di SDI
Introduzione
L'obiettivo di questo lavoro è stata la realizzazione di un web service geografico per la gestione e la
distribuzione di contenuti cartografici e dei metadati ad essi associati. Per definire le caratteristiche
di implementazione si è deciso di fare riferimento a quanto stabilito nell'ambito della direttiva
INSPIRE che prevede, per la pubblicazione dei metadati, l'utilizzo dello standard OGC CSW ISO
19115/19119 Application Profile (CSW ISO AP), con l'utilizzo dello standard ISO/TS19139,
ovvero la codifica XML dell'ISO19115, come protocollo di scambio e di accesso. Per quando
riguarda invece l'accesso ai contenuti cartografici INSPIRE prevede che il WMS sia conforme a
quanto stabilito dallo standard ISO 19128:2005(E), che riprende il documento dell'Open Geospatial
Consortium relativo alla versione 1.3.0 del WMS.
Sulla base di queste indicazioni il servizio è stato realizzato utilizzando il seguente software open
source:
1
● UNM MapServer 5.2.0 per la distribuzione di dati seguendo il protocollo WMS 1.1.1;
2
● GeoNetwork 2.2.0 per la gestione dell'archivio dei metadati e la realizzazione del servizio
CS-W 2.0.1;
3
● Apache per la realizzazione del portale web;
4
● PostgreSQL come database di appoggio;
5
● Distribuzione Linux CentOS 5.2 per il sistema operativo.
Allo stato attuale la versione 1.3.0 delle specifiche per il WMS è stata implementata da un numero
ridotto di software (vedere "Appendice 1: software conformi allo standard WMS-1.3" del
documento di descrizione delle caratteristiche di MapServer). Si è scelto quindi, per garantire una
maggiore fruibilità, di realizzare il servizio in modo che sia conforme allo standard WMS 1.1.1,
tenendo presente che il passaggio alla nuova versione di MapServer (5.4) che implementerà lo
standard WMS 1.3.0 non comporterà problemi e permetterà di preservare tutto il lavoro fin qui
realizzato.
WMS per dati a scala comunale: l'esempio del Comune di Desio
I dati distribuiti dal geoservizio realizzato appartengono ai DB topografici comunali a scala 1:2000
della Regione Lombardia e per la loro pubblicazione sono state seguite le specifiche definite in
questo ambito. In particolare per le modalità di pubblicazione si è fatto riferimento all'ultima
normativa regionale “Specifiche Tecniche aerofotogrammetriche per la realizzazione del data base
topografico alle scale 1:1000 e 1:2000” - Versione 3.0 - dicembre 2007, approvata con DGR
VIII/006650 del 20/02/2008 - [LOM01].
I dati pubblicati hanno riguardato inizialmente il DB topografico del Comune di Desio e sono in
formato shape file.
Nella costruzione del servizio si è lavorato nell'ottica di mettere a disposizione una struttura in
grado di pubblicare i dati dei DB topografici comunali che rispettasse le specifiche tecniche definite
a livello regionale. Nella predisposizione dell'ambiente si è in particolare curato l'aspetto grafico per
fare in modo che tutta la simbologia utilizzata rispettasse, dove possibile, quella standard già
utilizzata a livello regionale. Rispettare questo tipo di conformità è stato in alcuni casi difficoltoso a
causa dell'utilizzo, in altri servizi regionali, di librerie di simboli inclusi nei software adottati e
quindi non riutilizzabili in ambiti diversi. Per questo motivo in molti casi si è dovuto provvedere
alla ricostruzione ex-novo della simbologia. Questo caso evidenzia come una scelta più accurata
1 http://mapserver.gis.umn.edu/
2 http://geonetwork-opensource.org/
3 http://httpd.apache.org/
4 http://www.postgresql.org/
5 http://www.centos.org/
Pag. 24Progetto di ricerca del Centro Interregionale di Coordinamento e documentazione per le informazioni territoriali
Gruppo di lavoro Lotto 4: “Studio di fattibilità di infrastruttura per la cooperazione applicativa di dati geografici”
Verso un modello di SDI
avrebbe consentito una apertura maggiore e un minor dispendio di risorse per la realizzazione del
servizio.
E' stata quindi creata una struttura composta da:
- un servizio WMS basato su MapServer;
- una libreria predefinita di simboli, costruita rispettando specifiche regionali;
- un file di configurazione per la pubblicazione dei dati.
La costruzione della libreria di simboli è molto importante perché mette a disposizione uno
strumento libero, riutilizzabile e modificabile senza grossi problemi.
Per la definizione della simbologia si è fatto riferimento ai documenti della Regione Lombardia
"Specifiche tecniche di rappresentazione" versione 2.0 – dicembre 2007 [LOM02] e "Specifiche di
contenuto e schema fisico di consegna del Data base topografico" versione 3.0 - dicembre 2007
[LOM03].
Per illustrare il lavoro compiuto per ogni file da pubblicare si prenda in considerazione come
esempio il file di dati A020102. Il nome di questo file è fissato dalla normativa regionale [LOM03]
che ci permette di dire che l'informazione geografica rappresentata è quella degli edifici (estratto del
documento in Tabella 1). Ogni edificio è inoltre classificato in base alla destinazione d'uso mediante
un codice nel campo EDIFC_USO degli attributi ed ha associato un codice disegno (Tabella 2); ad
ogni codice disegno corrisponde una descrizione corredata da un esempio (estratto del documento
in Tabella 3). Utilizzando queste informazioni è stato quindi definito nel file di configurazione di
MapServer - il Mapfile - un layer che facesse riferimento allo shape file dei dati con la
classificazione in base all'attributo EDIFC_USO (Figura 1).
Per ogni layer definito nel Mapfile sono state inoltre definite tutte le classi previste nella normativa
[LOM03] includendo anche le classi che non comparivano nei dati di test, ma che erano previste
dalla normativa, preparando in questo modo il Mapfile ad un uso generico, rendendolo quindi
disponibile per tutti i casi possibili e non unicamente per quelli presenti nel Comune di Desio.
Seguendo la classificazione regionale sono stati definiti i diversi simboli da associare agli edifici in
funzione della loro destinazione d'uso. Come esempio semplice di definizione delle proprietà
grafiche da utilizzare possiamo considerare il tipo 020101 - Residenziale, Abitativa; in Figura 2 è
riportata la definizione della relativa classe grafica nel Mapfile. Come esempio più complesso si
può fare riferimento al tipo 020303 - Sede di Scuola, Università, laboratori di ricerca nel quale ad
una certa scala (1:2000) viene introdotta anche una etichetta sovrapposta all'edificio. In questo caso
sono stati definiti due layer nel Mapfile: uno per la geometria, l'altro per l'etichetta (layer
Edificio_simbolo). In Figura 3 è riportato un estratto del Mapfile che riguarda questo esempio.
Un'altra situazione riguarda la definizione di appositi simboli personalizzati - nel file symbols.sym -
come nel caso del tipo 020801 - Edificio industriale, stabilimento industriale riportato in Figura 4.
Il lavoro relativo alla definizione della simbologia, illustrato in modo dettagliato per tre classi del
layer degli edifici, è stato fatto per tutti i layer definiti nella normativa Regionale [LOM02].
Per creare un nuovo servizio per un altro comune sarà quindi sufficiente rispettare i nomi standard
stabiliti dalla normativa regionale per quanto riguarda i file di dati: in questo modo non sarà
necessario ricostruire il Mapfile e si potrà riutilizzare anche il file con la definizione dei simboli.
L'infrastruttura così creata sarà a disposizione in forma gratuita e aperta per tutti gli enti territoriali
che si saranno dotati di un DB cartografico conforme alle specifiche della Regione Lombardia.
I dati accessibili tramite il servizio WMS realizzato sono stati riportati in Tabella 4. La banca dati è
costituita da un insieme di shape file ai quali MapServer può accedere direttamente per estrarre le
informazioni necessarie per soddisfare le richieste che arrivano dai client WMS. Si è utilizzato
questo formato perché è quello in cui sono resi normalmente disponibili questi dati dalla Regione
Lombardia: in presenza di particolari necessità è possibile portare tutte le informazioni su database
come PostgreSQL/PostGIS e adattare facilmente il Mapfile per far operare MapServer su questa
Pag. 25Progetto di ricerca del Centro Interregionale di Coordinamento e documentazione per le informazioni territoriali
Gruppo di lavoro Lotto 4: “Studio di fattibilità di infrastruttura per la cooperazione applicativa di dati geografici”
Verso un modello di SDI
nuova sorgente di dati. Tutta la parte di definizione dei simboli e delle classi rimarrà in ogni caso
inalterata e immediatamente disponibile per il nuovo ambiente.
Tabella 1: corrispondenze tra nomi nomi file e classi di dati - [LOM03]
Pag. 26Progetto di ricerca del Centro Interregionale di Coordinamento e documentazione per le informazioni territoriali
Gruppo di lavoro Lotto 4: “Studio di fattibilità di infrastruttura per la cooperazione applicativa di dati geografici”
Verso un modello di SDI
EDIFICIO - file A020102
EDIFC_USO CATEGORIA USO Codice
disegno
2010 residenziale, abitativa 3010100
2020 municipio 3030600
2020 sede provincia 3030700
2020 sede regione 3030800
20 servizio pubblico 3030900
2030 sede asl 3030100
203010 sede di servizio socio assistenziale 3041000
203010 sede di ospedale 3030100
2030 sede di clinica 3030100
2030 sede di scuola, università, laboratorio di ricerca 3030200
2030 sede di poste-telegrafi 3030400
2030 sede di tribunale 3030300
2030 sede di polizia 3010100
2030 sede di vigili del fuoco 3010100
2030 casello forestale 3051300
20 militare 3010100
2040 caserma 3010100
2040 prigione 3010100
20 luogo di culto 3020100
20 luogo di culto 3050102
20 servizi di trasporto 3010100
2060 aereo 3050502
206010 stazione passeggeri aeroportuali 3050502
206010 eliporto 3050701
2060 stradale 3010100
206020 stazione autolinee 3050801
206020 parcheggio multipiano o coperto 3010100
206020 edificio accessorio alle strade 3010100
2060 ferroviario 1040101
206030 stazione passeggeri ferroviaria 1040101
206030 deposito ferroviario per vagoni, rimessa locomotive 1040101
206030 casello ferroviario 1040400
206030 fermata ferroviaria 1040400
206030 scalo merci 1040500
Pag. 27Progetto di ricerca del Centro Interregionale di Coordinamento e documentazione per le informazioni territoriali
Gruppo di lavoro Lotto 4: “Studio di fattibilità di infrastruttura per la cooperazione applicativa di dati geografici”
Verso un modello di SDI
EDIFICIO - file A020102
EDIFC_USO CATEGORIA USO Codice
disegno
2060 altro impianto di trasporto 3010100
206040 stazione marittima 3010100
206040 stazione metropolitana 1040101
206040 stazione tranviaria 3010100
206040 stazione funivia 3010100
206040 stazione cabinovia 3010100
206040 stazione seggiovia 3010100
206040 stazione skilift 3010100
20 commerciale 3040200
2070 sede di banca 3010100
2070 sede di centro commerciale 3040200
2070 mercato 3040300
2070 sede di supermercato, ipermercato 3040200
2070 sede di albergo, locanda 3010100
20 industriale 3040100
2080 stabilimento industriale 3040100
2080 impianto di produzione energia 3050900
208020 centrale elettrica 3050900
208020 centrale termoelettrica 3051000
208020 centrale idroelettrica 3050900
208020 centrale nucleare 3051100
208020 stazione-sottostazione elettrica 3051200
208020 stazione di trasformazione 3051200
2080 impianto tecnologico 3040100
2080 depuratore 4040300
2080 inceneritore 3040100
2080 stazione di telecomunicazioni 3030500
2080 edificio di teleriscaldamento 3040100
2080 edificio di area ecologica 3010100
20 agricolturale 3040201
2090 fattoria 3040201
2090 stalla 3040201
2090 fienile 3040201
21 ricreativo 3060102
Pag. 28Progetto di ricerca del Centro Interregionale di Coordinamento e documentazione per le informazioni territoriali
Gruppo di lavoro Lotto 4: “Studio di fattibilità di infrastruttura per la cooperazione applicativa di dati geografici”
Verso un modello di SDI
EDIFICIO - file A020102
EDIFC_USO CATEGORIA USO Codice
disegno
2100 sede di attività culturali 3010100
210010 biblioteca 3010100
210010 cinema 3010100
210010 teatro, auditorium 3010100
210010 museo 3010100
210010 pinacoteca 3010100
2100 sede di attività sportive 3060102
210020 piscina coperta 3060102
210020 palestra 3060102
210020 palaghiaccio 3060102
2100 altre attivtà ricreative 3060102
210030 campeggio 3060403
Tabella 2: Tabella di corrispondenza tra codici entità e codici disegno - [LOM02]
Tabella 3: Definizione segni grafici - [LOM02]
Pag. 29Progetto di ricerca del Centro Interregionale di Coordinamento e documentazione per le informazioni territoriali
Gruppo di lavoro Lotto 4: “Studio di fattibilità di infrastruttura per la cooperazione applicativa di dati geografici”
Verso un modello di SDI
LAYER
NAME "Edificio"
METADATA
"wms_title" "Edificio"
"wms_feature_info_mime_type" "text/plain"
"wms_include_items" "all"
END
DATA "A020102"
STATUS on
TYPE polygon
CLASSITEM "EDIFC_USO"
...
Figura 1: Definizione del layer Edificio
LAYER
NAME "Edificio"
...
CLASS
EXPRESSION "020101"
STYLE
OUTLINECOLOR 115 76 0
COLOR 204 170 102
END
END
...
END
Figura 2: Layer Edificio: definizione grafica per la classe 020101
Pag. 30Progetto di ricerca del Centro Interregionale di Coordinamento e documentazione per le informazioni territoriali
Gruppo di lavoro Lotto 4: “Studio di fattibilità di infrastruttura per la cooperazione applicativa di dati geografici”
Verso un modello di SDI
LAYER
NAME "Edificio"
...
CLASS
EXPRESSION "020303"
STYLE
OUTLINECOLOR 200 133 68
COLOR 235 180 60
END
END
...
END
LAYER
NAME "Edificio_simbolo"
...
MAXSCALEDENOM 2000
CLASS
EXPRESSION "020303"
SYMBOL "03030201"
COLOR 0 0 0
SIZE 15
LABEL
TYPE truetype
FONT "arial"
SIZE 0
COLOR 255 255 255
END
...
END
Figura 3: Layer Edificio: definizione grafica per la classe 020303 con etichette
Pag. 31Progetto di ricerca del Centro Interregionale di Coordinamento e documentazione per le informazioni territoriali
Gruppo di lavoro Lotto 4: “Studio di fattibilità di infrastruttura per la cooperazione applicativa di dati geografici”
Verso un modello di SDI
Mapfile:
LAYER
NAME "Edificio"
...
CLASS
EXPRESSION "020801"
STYLE
COLOR 255 255 255
END
STYLE
SYMBOL 'hatch'
ANGLE 45
SIZE 8
WIDTH 1
COLOR 204 133 68
OUTLINECOLOR 115 76 0
END
STYLE
SYMBOL 'hatch'
ANGLE 135
SIZE 8
WIDTH 1
COLOR 204 133 68
OUTLINECOLOR 115 76 0
END
END
...
END
File symbols.sym:
SYMBOL
NAME "hatch"
TYPE HATCH
END
Figura 4: Layer Edificio: definizione grafica per la classe 020801
Pag. 32Progetto di ricerca del Centro Interregionale di Coordinamento e documentazione per le informazioni territoriali
Gruppo di lavoro Lotto 4: “Studio di fattibilità di infrastruttura per la cooperazione applicativa di dati geografici”
Verso un modello di SDI
Figura 5: Layer Edificio, rappresentazione complessiva
nome shape WMS name WMS title
file
P000101 Vertice_di_rete Vertice di rete
P000103 Punto_di_appoggio_fotogrammetrico Punto di appoggio fotogrammetrico
L000301 Asse_di_volo Asse di volo
A000303 Abbracciamento_al_suolo_del_fotogram Abbracciamento al suolo del
ma fotogramma
A010101 Area_di_circolazione_veicolare Area di circolazione veicolare
A010102 Area_di_circolazione_pedonale Area di circolazione pedonale
A010103 Area_di_circolazione_ciclabile Area di circolazione ciclabile
A010104 Area_stradale Area stradale
A010105 Viabilita_mista_secondaria_area Viabilita mista secondaria
L010105 Viabilita_mista_secondaria_linea Viabilita mista secondaria
L010107 Elemento_stradale Elemento stradale
P010108 Giunzione_stradale Giunzione stradale
L010116 Elemento_di_viabilita_mista_secondaria Elemento di viabilita mista secondaria
A010201 Sede_di_trasporto_su_ferro Sede di trasporto su ferro
L010202 Elemento_ferroviario Elemento ferroviario
L010204 Elemento_tranviario Elemento tranviario
P010205 Giunzione_tranviaria Giunzione tranviaria
A020101 Unita_Volumetrica Unita Volumetrica
A020102 Edificio Edificio
A020102 Edificio_simbolo Edificio_simbolo
L020104 Elemento_di_copertura Elemento di copertura
Pag. 33Puoi anche leggere
