I Successi Del Software Libero: Postgis

Transcript

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