I successi del software libero: PostGIS

Libero e Open Source
I successi del software libero:
PostGIS
CHI USA POSTGIS? IL SOFTWARE PROPRIETARIO HA UNA PERCEZIONE ESATTA DEI PROPRI CLIENTI, LEGATI DA RAPPORTI COMMERCIALI ESPLICITI E NECESSARI. IL SOFTWARE
LIBERO INVECE PUÒ ESSERE SCARICATO ED UTILIZZATO LIBERAMENTE, ED È SPESSO DIFFICILE CAPIRE QUANTO VENGA UTILIZZATO, ED IN QUALI CONTESTI. DI CONSEGUENZA,
ALCUNI HANNO LA PERCEZIONE CHE I GIS LIBERI SIANO USATI SOLO IN AMBIENTI DI
RICERCA O DILETTANTISTICI. UN'INCHIESTA HA PERÒ RIVELATO ALCUNI INTERESSANTI
CASI DI UTILIZZO DI POSTGIS IN AMBIENTI COMPLESSI E MISSION-CRITICAL. VEDIAMO
ALCUNI ESEMPI.
In molti contesti, anche in Italia, chi usa software
libero ed Open Source non rende nota la sua scelta, forse per non “spaventare” i clienti con scelte
tecnologiche che potrebbero essere percepite
come troppo innovative, in altri casi per godere di
un vantaggio competitivo senza che questo sia
immediatamente percepibile ai concorrenti, a
volte per semplice mancanza di consapevolezza. Il
risultato è che il “portafoglio clienti” del software
libero ed Open Source in ambito geografico viene
percepito come molto più scarso di quanto sia in
realtà, e questo, generando un'impressione di
marginalità dei prodotti, è in molto casi un ostacolo alla loro diffusione. Inoltre, la scarsa consapevolezza del modello di business specifico del software libero fa spesso sì che gli utilizzatori, anche
in contesti altamente professionali, non percepiscano l'importanza di reinvestire (sia in termini di
codice che di risorse) nel software che stanno
usando, in modo da assicurarne il progresso sempre più rapido ed efficace. In realtà alcuni dei programmi liberi sono ben solidi e maturi, immediatamente impiegabili in contesti dove si richieda
grande affidabilità e robustezza. Gli esempi di successi del software libero non mancano, ed in alcuni casi sono ben documentati. Riportiamo qui di
seguito alcuni casi esemplari che riguardano
soprattutto PostGIS, spesso come backend di
UMN Mapserver (si vedano gli articoli su
MondoGIS per un'introduzione a questi due programmi).
UC DAVIS SOIL RESOURCE LABORATORY, USA
Il laboratorio di pedologia dell'Università della
California a Davis è un centro di ricerca per gli Stati
Uniti occidentali. I ricercatori del laboratorio, pur
esperti, trovano talvolta tecnicamente complesso
accedere alla grande mole di dati che gestiscono.
Per migliorare la facilità di accesso ai dati pedologici, il personale del laboratorio ha iniziato nel 2004
un progetto per rendere i dati accessibili al pubblico.
I dati di base sono forniti, a varie scale, dal
Dipartimento dell'Agricoltura del governo USA. Alla
scala 1:24.000, i dati comprendono più di mezzo
milione di poligoni, con un numero rilevante di
tabelle associate.
Inizialmente, i ricercatori hanno utilizzato un sistema basato su UMN Mapserver e MySQL, realizzando una interfaccia interattiva cartografica. MySQL
veniva usato per gestire le tabelle di attributi, e i
dati spaziali venivano gestiti separatamente come
shapefile.
Il sistema aveva una serie di limitazioni:
• la mappa era disponibile separatamente per
ogni area di survey; l'utente aveva quindi la percezione che i dati disponibili terminassero ai
confini di ciascuna delle aree;
• gestire i dati in 120 aree di survey separate era
scomodo e complesso;
• quando sono stati aggiunti i dati sul reticolo
stradale (TIGER), la gestione dei file divenne anche più complessa, a causa dell'incremento nel
numero dei file;
MondoGIS 58 gennaio/febbraio ‘07
61
Libero e Open Source
tà analitiche sono disponibili per i ricercatori. Ancora
con le parole di Dylan: “con l'approccio SQL al GIS,
possiamo ora realizzare analisi multi-survey all'interno di PostGIS; questi sarebbero stati complessi da
realizzare con gli shapefile o con ArcGIS”.
I dati pubblicati dal laboratorio sono ora resi disponibili anche all'esterno di esso, per i consulenti agronomi e ambientali, facendone così una risorse
importante per gli scienziati in tutto il sud ovest
degli Stati Uniti (Fig. 1).
Per ulteriori informazioni: http://casoilresource.
lawr.ucdavis.edu.
Figura 1 - L'interfaccia WebGIS del California Soil
Resource Lab
•
fare interrogazioni non spaziali e unire i risultati all'informazione spaziale richiedeva scripts
complicati e difficili da mantenere.
Nella primavera del 2006, il gruppo di lavoro ha
deciso di migrare tutti i dati in un singolo database
PostGIS/PostgreSQL. Per caricare i dati nel database,
è stato impiegato lo strumento ogr2ogr (parte della
libreria GDAL), e l'applicazione Mapserver è stata
modificata in modo da leggere i dati (sia alfanumerici che geografici) direttamente da PostGIS.
Con la nuova architettura sono stati immediatamente disponibili una serie di vantaggi:
• un'unica tabella contiene tutte le informazioni
di tutte le 120 aree, rendendo possibile l'interrogazione e la visualizzazione contemporanea
di tutti i dati;
• la funzione di PostGIS "simplify()" è stata usata
per creare versioni semplificate di alcuni degli
strati, in modo da migliorare significativamente
la velocità dell'applicazione alle scale geografiche più piccole;
• anche gli strati TIGER sono stati aggiunti come
tabelle unitarie, ed anche in questo caso la
semplificazione ha consentito di creare strati di
più veloce visualizzazione.
La migrazione a PostGIS ha sollevato il gruppo dai
problemi della gestione dei dati, ed ha consentito di
concentrarsi sulle funzionalità necessarie. “I miglioramenti più rilevanti negli ultimi sei mesi sono strettamente dipendenti dalla migrazione verso PostGIS”
- così Dylan Beaudette, sviluppatore e ricercatore del
laboratorio. Una volta che i dati sono stati resi disponibili tramite accesso standard SQL, nuove possibili-
62
GLOBEXPLORER, USA
GlobeXplorer fornisce servizi Web per l'accesso ad
immagini satellitari ed aeree, gestendo le relazioni
con decine di fornitori di immagini, e fornendo un
accesso web semplificato ad una raccolta unificata
di immagini pari a molti Terabytes.
I suoi clienti spaziano da singoli utenti finali che
accedono tramite Web Map Server (WMS) a portali
Web che ricevono milioni di click al giorno. Questa
situazione di altissimo carico richiede soluzioni ad
alta affidabilità che scalino efficientemente fino a
rispondere a milioni di richieste al giorno.
L'architettura GlobeXplorer (GX) non mantiene le
immagini all'interno del database, ma usa il database per mantenere i metadati sulle immagini disponibili. Il middleware GX gestisce le richieste di immagini prima interrogando il database per determinare
la disponibilità, poi recuperando le immagini dai
sistemi di storage e infine inviandole al cliente. Di
conseguenza, ogni richiesta di immagine genera
una o più richieste di metadati al database.
Inizialmente, nel 1999, GX ha implementato il sistema basandosi su Oracle 8i, ma ha presto realizzato
che Oracle non riusciva a gestire il carico generato
dal sistema. Informix ha quindi formulato un'offerta
di migrazione dell'intero sistema sul proprio database, usando lo "Spatial Blade", e nel 2001 il sistema
girava interamente su Informix.
GlobeXplorer ha continuato a crescere ogni anno,
incrementando sia i propri clienti sia il numero di
immagini nei propri archivi. Di conseguenza, anche
l'infrastruttura è cresciuta, fino al punto che nel
2004 un totale di 11 CPU erano dedicate a far girare Informix; le licenze costavano 30.000 US$ per
ogni CPU. Guardando in prospettiva, GlobeXplorer
ha valutato che un ulteriore espansione del sistema
non sarebbe stata economicamente sostenibile,
dato che un raddoppio della capacità avrebbe comportato costi di licenza nell'ordine del mezzo milione di dollari.
Dopo aver valutato le alternative, GlobeXplorer ha
optato per PostGIS come possibile alternativa ad
Informix, ed ha iniziato a condurre test di carico nel
2004. Un gruppo di ingegneri ha scritto il codice che
consentiva di far girare in parallelo i due sistemi
MondoGIS 58 gennaio/febbraio ‘07
Libero e Open Source
(Informix e PostGIS), e un gruppo di amministratori
di database ha verificato le opzioni di tuning.
Quando la performance del sistema è risultata accettabile, il sistema è stato gradualmente migrato, e
alla fine del 2004 tutti i database in produzione
erano migrati a PostGIS.
Da allora, GlobeXplorer ha continuato ad utilizzare
intensamente PostGIS, aggiungendo grandi insiemi
di dati vettoriali al pool di informazioni raster disponibili per i clienti: tutte le strade degli USA, i bacini
idrografici, le aree inondabili, e i poligoni relativi a 32
milioni di particelle. GlobeXplorer fornisce mappe
risultanti da queste tabelle vettoriali usando UMN
Mapserver. GX inoltre usa PostGIS per analizzare
dati spaziali per valutare la priorità nell'acquisizione
di nuove immagini. Il sistema di GlobeXplorer al
momento risponde a più di un milione di richieste al
giorno in media (con punte di oltre 5 milioni). Anche
i sistemi di preparazione dei dati e di gestione dei
contenuti usano PostGIS. Il gruppo sta ora lavorando anche sulla migrazione su PostgreSQL del sistema
di pagamento online.
PostGIS ha fornito a GlobeXplorer stabilità e performance equivalenti ai sistemi proprietari precedentemente in uso, consentendo di espandere l'infrastruttura in modo economicamente sostenibile. Al crescere del carico sul sistema, è stato in grado di
aggiungere nuovi nodi di database senza acquistare
ulteriori costose licenze software.
“Probabilmente non ci saremmo potuti permettere
una soluzione commerciale per le nostre esigenze di
database” sostiene l'amministratore di database di
GlobeXplorer, Greg Williamson, “persino acquistando un numero minore di CPU più veloci, i costi di
licenza sarebbero enormi”.
Dato che GlobeXplorer continua a crescere, incrementa i propri clienti e servizi, ognuno dei quali
aggravano il carico sull'infrastruttura di database.
Indipendentemente da quali saranno le prossime
richieste del mercato, “probabilmente PostGIS sarà
parte integrale del sistema”, per citare le parole di
Williamson.
Per ulteriori informazioni: www.globexplorer.com.
benchmark di varie tecnologie, incluso Oracle, DB2
e PostGIS/PostgreSQL, alla ricerca di un prodotto che
rispettasse alcune specifiche fondamentali:
• capacità di gestire più di 100 milioni di oggetti
spaziali;
• velocità sufficiente per restituire rapidamente i
risultati di una query su un database di quelle
dimensioni;
• piena integrità transazionale in modo da assicurare la qualità dei dati durante le operazioni di
manutenzione del database.
I test hanno mostrato come PostgreSQL/PostGIS
avesse prestazioni simili alle alternative commerciali.
Frank Fuchs è un project manager all'IGN, ed ha
fatto parte del team che ha operato la scelta. “Dato
che PostgreSQL e PostGIS sono software liberi e
Open Source, abbiamo avuto la possibilità di usarli in
un prototipo. Al contrario, se avessimo usato uno
specifico DBMS commerciale, avremmo avuto problemi in seguito, in caso di gare d'appalto” dice
Fuchs “inoltre, il basso costo [di PostGIS] era un elemento positivo”.
Il gruppo di lavoro di Fuchs ha integrato PostGIS nel
sistema di gestione dati per il database "BDUni" - un
DB in 3D, integrato a livello nazionale, che contiene
strade, ferrovie, idrografia, vegetazione, edifici, confini amministrativi ed altro. Hanno definito un nuovo
processo e nuovi strumenti per gestire tutti i dati di
BDUni in un database unificato a livello nazionale,
Figura 2 - Lo strumento interattivo per l'analisi e rilevamento delle immagini SAR. Questa versione è
bastata su Eclipse e implementata in Java.
L'interfaccia consente di mostrare contemporaneamente l'immagine SAR (in alto a sinistra) insieme
all'analisi 3D delle risposte di ciascun obiettivo (al
centro) e una scheda delle caratteristiche (a destra).
In basso, la finestra di un browser che mostra l'interfaccia UMN MapServer
INSTITUT GÉOGRAPHIQUE NATIONAL, FRANCE
L'Institut Géographique National (IGN) è l'agenzia
cartografica nazionale francese, con 1800 impiegati
con la finalità di raccogliere, integrare, gestire e
distribuire le informazioni geografiche ufficiali per
l'intero territorio nazionale.
Per molti anni, l'IGN ha gestito i dati spaziali nazionali utilizzando i sistemi GIS GeoConcept. Come in
altri sistemi GIS desktop, GeoConcept richiedeva,
per poter gestire efficacemente le mappe, che i dati
fossero divisi in sezioni.
l'IGN ha iniziato intorno al 2002 a valutare la possibilità di gestire in maniera unitaria i dati relativi all'intero territorio nazionale. Ha quindi condotto un
MondoGIS 58 gennaio/febbraio ‘07
63
Libero e Open Source
adattando il nuovo sistema agli strumenti esistenti,
a cui i tecnici IGN erano già abituati. Il team ha quindi scelto PostGIS come database, e mantenuto
GeoConcept come ambiente di editing per aggiornare i dati. Il software GeoConcept è stato modificato in modo da aggiungere nuovi strumenti per
l'inserimento e la consultazione di dati nel database
centralizzato:
• un convertitore che carica i dati dagli archivi esistenti (formato GeoConcept) in PostGIS; questo
è di solito usato solo una volta per ciascun file,
in occasione della migrazione verso il nuovo
sistema;
• un estrattore di dati che seleziona una specifica
sezione dei dati dal database e li carica in
GeoConcept per la modifica; varie sezioni possono essere sovrapposte, e vari estrattori possono operare simultaneamente sugli stessi elementi. La sovrapposizione di varie aree risolve
l'annoso problema della collimazione fra confini adiacenti;
• un sincronizzatore di dati che inserisce le modifiche dal client verso il database e invia le modifiche presenti nel database al client. Se due
operatori hanno modificato lo stesso elemento,
viene generato un conflitto, e l'operatore deve
scegliere come risolverlo.
Utilizzando GeoConcept come ambiente di editing, il
nuovo sistema consente agli operatori di lavorare sul
campo, anche senza nessuna connettività, aggiornando il database al loro ritorno in un punto connesso al network principale di IGN. I tecnici non hanno
dovuto apprendere un nuovo sistema per digitalizzare i dati, ma utilizzano lo strumento a loro consueto.
Gli strumenti di estrazione e sincronizzazione fanno
estensivo uso del sistema transazionale di PostgreSQL, in modo da assicurare che l'integrità del dato
non sia violata in caso di inattesi guasti o disconnessioni durante il processo di sincronizzazione. Da luglio
a ottobre 2006, più di un quarto dei dati nazionali
(circa 30 milioni di elementi) erano stati caricati nel
database. Alla fine del 2006, il sistema BDUni è usato
da circa 130 ricercatori di campo in molte città francesi. In conseguenza dell'esigenza di alta affidabilità
e integrità dei dati, il sistema include anche un server
di backup ridondante, che è sincronizzato con quello
principale varie volte al giorno. In seguito all'esperienza acquisita con il completamento del progetto, il
parere di Fuchs per gli altri amministratori è “ricordate che i database sono strumenti molto potenti, e le
transazioni sono una funzionalità essenziale. PostGIS
rende disponibili queste funzioni in modo molto efficiente”. Per ulteriori informazioni: www.ign.fr.
INFOTERRA, REGNO UNITO
Infoterra è presente nel settore geospaziale da oltre
25 anni, a partire dalla sua fondazione nel 1980
come National Remote Sensing Centre del Regno
Figura 3 - Un'interfaccia Web cartografica allo stesso database
64
MondoGIS 58 gennaio/febbraio ‘07
Libero e Open Source
Unito. In questo lungo periodo, NRSC è cresciuto,
ha stretto partnership internazionali con agenzie
spaziali, si è espanso nel settore della raccolta di dati
aerei, finché è stata privatizzata e rinominata
“Infoterra” alla fine degli anni '90.
In qualità di importante rivenditore di immagini
satellitari e di foto aeree, Infoterra si trova a gestire
raccolte di dati in continua espansione. Con l'avvento di Internet, Infoterra ha reso disponibile online la
maggior parte dei propri cataloghi di dati, e i clienti
si sono abituati ad avere accesso diretto alle informazioni relative.
Nel 2001, Infoterra ha messo a punto un nuovo
catalogo per l'UK Ordnance Survey tramite
PostgreSQL, come strumento di supporto ad un
grosso programma di acquisizione dati. Alla fine del
contratto, il database gestiva un milione di record di
metadati senza nessun problema operativo, e
Infoterra valutò fattibile la migrazione verso
PostgreSQL anche di architetture più importanti.
Dato che presso Infoterra i vari progetti di acquisizione dati erano gestiti indipendentemente, ognuno
tendeva ad avere il proprio sistema di gestione dati
e ricevimento degli ordini di acquisto. In seguito al
successo del progetto Ordnance Survey, Infoterra
decise di consolidare la gestione dati ed il sistema di
ricevimento degli ordini in un singolo sistema aziendale, chiamato “GeoStore.
GeoStore usa PostgreSQL/PostGIS come backend di
database, UMN Mapserver per la restituzione cartografica online, ed una varietà di applicazioni minori
per il caricamento dei dati, la compilazione degli
ordini di acquisto, e l'accesso ai dati stessi. I dati
gestiti in GeoStore adesso includono:
• 30 Terabyte di dati aerei, satellitari e vettoriali
direttamente online;
• 1.000 TeraByte di dati su nastri robotizzati;
• 600 milioni di record relativi a dati topografici
dell'Ordnance Survey per tutto il Regno Unito.
I dati mantenuti presso il GeoStore sono accessibili
in molti modi diversi:
• tramite interfacce OGC Web Map Service;
• come ordini di acquisto su CDROM, FTP, hard
disk;
• attraverso servizi Web autenticati;
• con servizi interni, tramite WMS o ArcXML.
Ross Elliott è un Senior Software Engineer per
Infoterra, ed ha collaborato a disegnare il sistema
GeoStore e i suoi predecessori negli ultimi 5 anni.
“Per giustificare l'uso di qualunque software, il criterio principale per noi è che il costo sia proporzionale all'effettiva utilità” dice Elliott, “e questo
nella maggior parte dei casi significa che scegliamo l'open source. Se non ci fosse PostGIS, saremmo costretti a tornare a Oracle, e questo comporterebbe enormi costi. La maggior parte dei nostri
server di database hanno due o più CPU, e sono
collegati al Web. Questo aggiungerebbe un milio-
ne di sterline ai nostri costi di licenze, oltre alla
manutenzione annuale”.
Il database Ordnance Survey è uno dei più grandi
set unificati di dati spaziali al mondo, e Infoterra
ha sviluppato strumenti specializzati per manipolare l'enorme numero di elementi. Per importare i
dati, Infoterra ha sviluppato un'applicazione che
carica l'intero set di dati GML in appena 12 ore un tasso di quasi 14.000 elementi per secondo.
In aggiunta al GeoStore, Infoterra struttura e
gestisce un numero di piccole applicazioni personalizzate per altre compagnie, e la maggior parte
di queste è basata su PostGIS. Oracle viene usato
su richiesta del cliente, ma Infoterra impiega prioritariamente PostGIS. “PostGIS ha reso possibile
strutturare i nostri sistemi in modo da aderire al
nostro modo di lavorare, senza preoccuparsi dei
costi di licenza” dice Elliott, “usare PostGIS è una
scelta facile”.
Per ulteriori informazioni: www.infoterra-global.
com; www.geostore.com.
EU JOINT RESEARCH CENTRE
Il Joint Research Centre (JRC) della Commissione
Europea fornisce supporto alla Direzione Generale
della Pesca e Mare e agli Stati Membri nell'esecuzione del piano comune europeo sulla pesca. Fra
le altre cose, il piano della pesca stabilisce quote
sulle quantità di pesce di ciascuna specie che ogni
stato membro dell'EU ha il diritto di prelevare.
Com'è facile immaginare, far rispettare le quote
presenta notevoli difficoltà. L'oceano è grande com'è possibile per i responsabili europei sapere
che i pescherecci operino effettivamente nelle
aree corrette, o se pescherecci non europei pescano in acque europee?
I ricercatori del JRC stanno lavorando per una possibile soluzione, il "Vessel Detection System"
(sistema di rilevamento navale, VDS). Il VDS è
l'unione di tecnologia spaziale all'avanguardia,
scienza dell'analisi di immagine e strumenti Open
Source per la gestione dei dati, e fornirà a chi deve
effettuare il controllo strumenti per il monitoraggio pressoché in tempo reale.
Il VDS combina le informazioni dai satelliti ad apertura sintetica (SAR) Radarsat-1 e ENVISAT, dai transponders posti su navi mercantili e pescherecci per
creare un'immagine operativa delle navi note e
ignote presenti nelle acque europee. I satelliti SAR
sono molto efficaci nel rilevamento delle navi, dato
che le gli scafi metallici sono molto riflettenti per i
raggi radar, mentre l'acqua non lo è.
I satelliti SAR generano un fascio di 300x300 km
su di un'area preselezionata, e i dati sono convogliati su stazioni riceventi a terra. I dati bruti sono
elaborati tramite software proprietario SAR in
modo da ricavarne un'immagine, che viene trasferita al sistema VDS. L'arrivo di una nuova immagi-
MondoGIS 58 gennaio/febbraio ‘07
65
Libero e Open Source
Figura 4 - Alcune interfacce Web cartografiche al
database delle proprietà demaniali della cittadina di
Orchard Park
ne attiva il VDS che fa partire un processo che
estrae i segnali radar come punti e inserisce i punti
in un database PostGIS, insieme ai metadati sull'intervallo di confidenza, la dimensione, e un riferimento all'immagine originale. Contemporaneamente, vengono inoltre inserite in PostGIS le posizioni dei transponder delle navi mercantili e da
pesca, tramite Web Service e script. Le informazioni dei transponders e dei punti rilevati dall'analisi
radar sono messi in correlazione all'interno del
database in modo da identificare le possibili navi.
Infine i dati possono essere inviati alle autorità di
controllo via e-mail e rese disponibili tramite Web
Mapping (basato su UMN Mapserver).
Tutta la catena di analisi dell'immagine e correlazione (Fig. 2) richiede circa 20 minuti, per cui le
informazioni geografiche fornite alle autorità sono
direttamente impiegabili per dirigere le operazioni
di ricognizione. Aeromobili di vedetta possono
essere indirizzati verso obiettivi non identificati
sulla base delle informazioni fornite dal VDS.
Guido Lemoine si è unito al gruppo VDS nel 2003,
ed ha collaborato allo sviluppo del sistema sperimentale. “All'inizio, il team intendeva strutturare
il database in Oracle Spatial e il front-end in
ArcInfo” dice Lemoine, “ma alla fine abbiamo
deciso di impiegare esclusivamente componenti
Open Source, per evitare di legarci esclusivamente
a soluzioni proprietarie”. Il primo prototipo software è stato mostrato nel 2003, e il sistema è
stato regolarmente verificato dalle autorità fin da
quel momento.
Le precedenti esperienze di Lemoine con database
Open Source avevano riguardato MySQL, ma la
carenza di funzionalità spaziali in MySQL ha reso
PostGIS una scelta più adatta. “Non ci siamo mai
pentiti della scelta fatta” dice Lemoine. Il databa-
66
se PostGIS gioca un ruolo centrale nel sistema, sia
come punto centrale di immagazzinamento dei
dati in inserimento (radar e transponder), sia come
motore di integrazione per la correlazione dei dati,
necessaria per la localizzazione degli obiettivi non
identificati. In ogni momento, varie centinaia di
migliaia di punti e poligono con la relativa identificazione temporale sono mantenuti nel database
VDS. Inoltre, tutte le informazioni di base per la
visualizzazione delle mappe (batimetria, linee di
costa, regioni di pesca) sono gestite dal database
PostGIS.
Dimostrazioni di successo del VDS per il monitoraggio dei battelli da pesca hanno incoraggiato il
gruppo ad effettuare ulteriori ricerche per fornire
supporto tecnico alla decisione in altre aree, quali
la vigilanza marittima per scopi di igiene ambientale e di sicurezza. Il gruppo sta inoltre sperimentando la riconfigurazione della sequenza di analisi, in modo da dimezzare il tempo di analisi dall'immagine alla mappa finale.
Per ulteriori informazioni: Joint Research Centre,
www.jrc.ec.europa.eu.
NORTH DAKOTA STATE WATER COMMISSION,
USA
L'agenzia statale per le risorse idriche (State Water
Commission, SWC) regola l'utilizzo delle risorse
idriche in Nord Dakota. La comprensione dello
stato delle risorse, la sua comunicazione al pubblico e agli scienziati, e la pianificazione dei futuri usi
richiedono la raccolta e la gestione di una mole
importante di dati spaziali.
Intorno al 2001, la SWC ha intrapreso una migrazione completa verso piattaforma ESRI: ArcSDE
come server di database, ArcIMS per la pubblicazione delle mappe, e ArcMap per i desktop. La
migrazione avrebbe richiesto l'acquisto di un
notevole numero di licenze per molti anni, con
una spesa totale non indifferente. Nel 2003, però,
il governo del Nord Dakota ha ridotto i fondi a
disposizione, e questo ha arrestato completamente i piani di migrazione.
La SWC aveva quindi bisogno di un nuovo piano
sulla base della propria situazione finanziaria: non
erano disponibili fondi per acquisti importanti, ma
le nuove funzionalità erano ormai necessarie per
sostenere le attività istituzionali.
Nella loro ricerca di opzioni alternative, hanno
valutato la combinazione PostGIS/PostgreSQL e
UMN Mapserver come insieme di strumenti che
potevano risolvere le esigenze immediate di
gestione dei dati e rappresentazione cartografica.
Gli strumenti open source potevano essere installati ed espansi senza incorrere in importanti costi
di licenza, il che voleva dire che le scarse risorse
economiche potevano essere impiegate per l'infrastruttura fisica: computers e personale che li
MondoGIS 58 gennaio/febbraio ‘07
Libero e Open Source
amministrasse. La SWC come primo passo ha sostituito ArcIMS con UMN Mapserver. Questo ha consentito un accesso ad alte prestazioni ai loro dati
spaziali, attraverso un'applicazione Web, sia internet
che intranet. Basandosi su shapefiles, il sistema
richiedeva frequenti interventi manuali per l'aggiornamento.
L'aggiunta di PostgreSQL e PostGIS all'infrastruttura
ha consentito a SWC di integrare i propri dati spaziali ed alfanumerici in un ambiente di gestione unitario. Dato che era già presente un sistema
client/desktop per la gestione dei dati non spaziali,
l'integrazione di PostgreSQL/PostGIS ha implicato
che questi potessero operare sulla stessa base di dati
del sistema di pubblicazione su Web.
SWC ha presto constatato che il nuovo software
Open Source era molto più facile da mettere online
e gestire. In particolare, l'aggiornamento dei componenti dell'infrastruttura era molto più agevole
rispetto al software proprietario utilizzato in precedenza. L'applicazione Web dà accesso ai dati
relativi a 31.000 pozzi, 2.000.000 record dei
livelli idrici e 54.000 analisi chimiche (Fig. 3).
Questi dati sono usati dal pubblico, tramite l'applicazione di Web mapping, e dagli esperti idrologi, sia interni all'amministrazione che consulenti esterni, che possono scaricare ed analizzare i dati direttamente.
Il team di sviluppo in SWC consiste di sole tre persone, ma negli ultimi due anni hanno sviluppato
interamente tutte le funzionalità pianificate per la
migrazione ad ESRI, e stanno ora affrontano applicazioni originariamente neppure previste.
Chris Bader ha guidato il gruppo nella transizione.
“In questa fase, l'infrastruttura Open Source è
integrata in ogni aspetto della nostra gestione dei
dati” dice Bader, “per la prima volta, non dobbiamo affrontare l'incertezza derivante dalla determinazione politica del bilancio, e non vediamo limiti
a quello che possiamo realizzare”. Ora che il
nucleo dell'infrastruttura è operativo, il team può
concentrarsi sugli strumenti analitici per fornire la
conoscenza necessaria per la gestione delle risorse idriche del Nord Dakota.
Il gruppo sta ora analizzando ulteriori strumenti
Open Source per includere la generazione di
mappe di isosuperfici potenziometriche, la visualizzazione di complessi trend spaziotemporali, ed
altre funzioni analitiche sofisticate. Dato che l'infrastruttura è basata su standard, il gruppo di sviluppo può anche consentire l'accesso ai dati da
parte di altri esperti all'interno di SWC. Ad esempio, uno degli idrologi sta ora sviluppando interfacce in Python per far girare modelli sulle acque
superficiali che estraggono automaticamente i
dati dal database PostgreSQL centralizzato.
Per ulteriori informazioni: www.swc.nd.gov; http://
mapservice.swc.state.nd.us.
TOWN OF ORCHARD PARK, NEW YORK, USA
Orchard Park è una cittadina di 28.000 abitanti nello
stato di New York. Al pari di molte altre agenzie
governative statunitensi, Orchard Park sta migrando
ad una nuova forma di bilancio per le proprietà pubbliche, il “Government Accounting Standards Board
Rule” o GASB. GASB impone alle amministrazioni di
avere un inventario completo delle proprietà demaniali, ed una loro valutazione, in modo da valutare il
loro ammortamento, come in un'azienda privata. Per
molte amministrazioni, implementare GASB può
essere complesso. Orchard Park aveva quindi bisogno
di un sistema di inventario, e di collegare le informazioni finanziarie e catastali ad una base cartografica
che si potesse evolvere nel tempo, in modo da creare un sistema che consentisse di valutare dati e
trends. Tutti gli uffici usavano indipendentemente
piccoli database locali o fogli di calcolo a questo
scopo, per cui si rendeva necessario un database centrale per consolidare tutta l'informazione in una vista
unitaria. Paul Warrimer, il coordinatore del network,
ha scelto PostgreSQL per gestire ed integrare l'informazione proveniente da tutti i vari settori dell'amministrazione. “I finanziamenti disponibili non ci consentivano di acquisire sistemi quali Oracle o SQL
Server” dice Warrimer, “ed ero preoccupato della
scalabilità di MySQL”. Il disegno originario prevedeva
di mantenere i dati di inventario in PostgreSQL, mentre la rappresentazione spaziale degli oggetti risiedeva in un insieme di shapefile indipendenti. La migrazione dell'informazione spaziale in PostGIS ha consentito a Orchard Park di integrare le informazioni, e
renderle facilmente disponibili al pubblico (Fig. 4).
“Con PostGIS, speravo di aver la possibilità di evitare
l'uso degli shapefiles, limitandomi a caricare ed
esportare regolarmente i dati “ dice Warrimer, “quello che mi ha sorpreso è stata la ricchezza delle funzioni di analisi spaziale”. Oggi Orchard Park pubblica
tutti i propri dati tramite UMN Mapserver e PostGIS,
con l'interfaccia Cartoweb, e sta lavorando all'integrazione nel proprio sistema Web di un sistema di
valutazione delle proprietà e di autorizzazione alla
costruzione di nuovi edifici.
Per ulteriori informazioni:www.orchardparkny.org
MondoGIS 58 gennaio/febbraio ‘07
[autori]
Paul Ramsey
Refractions Research
www.refractions.net
Paolo Cavallini
Faunalia
Piazza Garibaldi 5 - Pontedera (PI)
www.faunalia.it
67