C’era bisogno dell’ennesimo progetto GIS open-source? Non bastavano i veterani QGIS e GRASS e la numerosa schiera dei più giovani uDIG, GvSIG, OpenJUMP, MapWindow solo per citare i più famosi? Ma certo che no! Open source in open minds ci piace dire da queste parti…
E allora senza indugi vediamo di che si tratta.
Intanto il nome del software Whitebox – affermano al Centro di Idrogeomatica dell’Università di Guelph, Canada – è ispirato alla filosofia della trasparenza, base dell’open source. Sembra abbiano scoperto l’acqua calda, e invece qualcosina in più la danno. In ogni tool che compone il GIS c’è un bel pulsantino che mostra il codice usato per realizzarlo. Più trasparente di cosi! Didatticamente costituisce un enorme valore aggiunto, anche dal punto di vista dello sviluppo.
E si spingono anche più oltre… pare Whitebox sia autenticamente estensibile. E’ possibile infatti creare nuovi tool ad hoc in relativamente pochi passaggi usando un wizard di scripting per Python o Visual Basic/C# , tra l’altro convertendo il codice da un linguaggio all’altro! Leggete qui e qui. C’è anche la possibilità di creare delle finestre per gestire i nuovi tools, mediante un dialog designer.
E’ possibile scaricare il codice sorgente del software – distribuito con licenza GPLv3 – o già compilato, pronto per essere utilizzato senza doverlo installare, ma solo su Windows. Non parlano sul sito di portabilità su Linux, ma chi è più esperto di me potrà valutarlo grazie al sorgente. E magari farcelo sapere qui su TANTO
Posso dire di essere un sostenitore dell’open source e senza dubbio preferisco avere a che fare con software, tecnologie e formati aperti. Al movimento del software libero sono molto legato, per alcuni versi ne faccio parte e, quando posso, cerco di dare i miei microscopici contributi qui e la.
Il mio mondo (digitale) ideale è un mondo in cui tutto il software è libero e, soprattutto, in cui le persone si scambiano dati e servizi in formati standard e liberi.
Il mondo reale, però, è fatto anche di altro e quando c’è da portare a casa la proverbiale pagnotta è bene tenerlo a mente. Inoltre penso che sia un preciso dovere, per un buon analista, essere sempre aggiornato sulle soluzioni esistenti indipendentemente dalla licenza che le accompagna.
In questo articolo racconterò quindi le impressioni che ho avuto durante le mie prime due settimane di lavoro con ArcGIS Server 9.3. Inizio subito col dire che partivo prevenuto nei confronti di questa piattaforma, date le allucinanti esperienze con ArcIMS, ma devo ammettere di essere rimasto piacevolmente sorpreso!
Che cos’è?
Bene, mi tocca entrare nel vivo e dare una definzione di massima che aiuti a capire meglio di cosa stiamo parlando.
Senza scendere troppo nel dettaglio tecnico, possiamo dire che ArcGIS Server è un ambiente che permette di pubblicare geowebservices sulla base dei quali si potranno poi sviluppare applicazioni di web-mapping.
Su questo fronte lo spettro di possibilità offerte da ArcGIS Server 9.3 agli sviluppatori GIS è davvero ampio. Si va dagli ADF (Advanced Development Framework) per gli ambienti .NET e Java, alle API Javascript, Flex e – di recente – Silverlight.
C’è anche un wizard che permette di pubblicare un’applicazione web senza grosse pretese di originalità e nel giro di qualche click, pur non avendo alcuna conoscenza di programmazione.
Come funziona?
Innanzitutto si deve installare!
Non ho avuto modo di provare l’installazione in ambiente GNU/Linux, ma in ambiente Windows la procedura non si discosta da quella classica che caratterizza la maggior parte dei programmi. Di certo avete presente il tipico: “Avanti → Avanti → Ok”…
Ultimata l’installazione vera e propria, vengono richieste delle informazioni utili alla configurazione dell’ambiente e, infine, si procede con l’autenticazione della licenza.
Al riavvio potremo finalmente effettuare il login in ArcGIS Server Manager, un applicativo di amministrazione da browser, oppure, se preferiamo, connetterci all’istanza di ArcGIS Server usando ArcCatalog.
A questo punto siamo pronti per tirarci su le maniche e creare servizi di vario tipo (mapservice, dataservice, gisservice, geoprocessing e geocoding service).
Consideriamo per esempio il mapservice, un tipo di servizio che serve ad esporre una mappa composta da uno o più layer, sui quali si possono eseguire delle operazioni (task) come find, query e identify.
Pubblicare un mapservice è decisamente semplice. Basta avere un progetto redatto in ArcMap (un normale file .mxd) ed effettuare delle semplici scelte per la configurazione del servizio.
Oltre al servizio proprietario ESRI, sono a disposizione vari standard: KML, WMS, WFS-T e WCS.
Sviluppo client con REST e Javascript
ArcGIS Server 9.3 offre, out-of-the box, la possibilità di esporre i servizi secondo il paradigma REST.
Questa, insieme alle API Javascript basate sull’ottimo toolkit open source Dojo, è probabilmente la novità di maggior rilievo di ArcGIS Server 9.3.
Imparare a sfruttare questi mezzi equivale ad aprirsi la possibilità di sviluppare delle applicazioni web 2.0 che, col solo codice lato-client, offrono la maggior parte delle caratteristiche che normalmente ci si aspetta di trovare in una applicazione di web-mapping. Qui ci sono alcuni esempi che sicuramente vale la pena di esplorare per rendersi conto delle potenzialità delle API.
E’ interessante, inoltre, che l’ultima versione di OpenLayers, la 2.8, permetta di utilizzare anche i layer REST di ArcGIS Server 9.3.
Se volete saperne di più sull’argomento vi consiglio caldamente questo video!
Pro e contro
Siamo alla fine del post ed è ora di fare un bilancio.
Prima le cattive notizie: il supporto, non me ne vogliano in ESRI Italia, è assolutamente inadeguato!
Se si naviga tra EDN e Resource Gateway o si bazzica la comunità internazionale sul forum, in fin dei conti non è proprio malaccio (anzi, sul forum ci sono utenti molto preparati e dispobili grazie ai quali ho risolto alcuni piccoli intoppi).
Però chi ha acquistato un prodotto in Italia, pagandolo profumatamente, tollera con un po’ di mal di pancia che il supporto locale non sappia nemmeno dare un aiuto di tipo “getting started” se ci si vuole discostare dall’uso del wizard o dello sviluppo con l’ADF Java o .NET.
Personalmente, ho telefonato 3 volte al supporto ponendo delle domande tecniche precise e non ho mai ricevuto una risposta utile dall’interlocutore (quasi sempre: “apra un ticket”). Oggi, con poche settimane di esperienza di sviluppo con queste API alle spalle, mi rendo conto che le mie domande erano davvero molto semplici, il che mi porta a pensare che quello dello sviluppo con le API Javascript, in ESRI Italia, sia un tema molto trascurato.
Comunque devo essere onesto e dire che in altre occasioni ho trovato utilissimo (spesso risolutivo) il supporto di ESRI Italia. Questo mi fa ben sperare per il futuro nel caso in cui a Roma decidano di dedicare un po’ di attenzione anche quei balordi (come il sottoscritto) che si sono fissati col Javascript!
Passiamo ai pro che, invece, sono tanti:
scalabilità dell’architettura
semplicità nella configurazione e nello sviluppo degli applicativi
versatilità delle API e possibilità di creare Mash-Up praticamente con tutto
buon supporto agli standard del settore
Basta con le chiacchiere!
Cliccando qui, potete vedere un piccolo esempio live da me realizzato.
Divertitevi (si fa per dire…) a fare lo stesso… e condividete il risultato!
E’ di qualche settimana fa il lancio dell’ultima versione dell’ottimo – sebbene ostico e agnostico – GIS olandese, che compie ulteriori piccoli passi avanti riguardo alcuni dei punti deboli che da sempre lo caratterizzano:
migliorata l’integrazione con le librerie GDAL, nelle precedenti versioni parecchio instabile, fondamentale per aprire ILWIS al resto del mondo;
garantito ora l’accesso anche a database Postgres/PostGIS;
miglioramenti anche al modulo SEBS, a mio avviso uno dei punti di forza di ILWIS, anche se poco conosciuto ai più.
Altre importanti novità riguardano gli sviluppatori:
ILWIS è ora a tutti gli effetti un progetto MS Visual 2008, con i suoi pro e i suoi contro;
la GUI (la faccia) e gli algoritmi funzionali (il cervello) di ILWIS sono stati completamente disaccoppiati, in tal modo sarà possibile scrivere più facilmente plugin per estenderne le funzionalità, così come sviluppare applicazioni server-side.
Ci ho giocato un po’ in questi giorni, per verificarne le funzionalità soprattutto sull’interoperabilità, e se da un lato ho riscontrato un effettivo miglioramento della performance riguardo l’importazione di dati esterni via GDAL (rimangono in realtà alcune “minor issues”), dall’altro ci sono ancora parecchi problemi sul modulo WMS, che purtroppo fa cilecca con tutti i server che ho provato. Solo con il solido JPL/NASA ILWIS riesce a leggere per lo meno il catalogo, ma poi non è in grado di caricare nessun layer.
Peccato, di strada da fare ce n’è ancora tanta sull’interoperabilità per ILWIS. Il problema è che è proprio su questo ormai che si gioca il destino di un GIS. Sono passati da anni i tempi durante i quali chi sviluppava software si poteva permettere di mantenere formati proprietari, fregandosene di ciò che accadeva nel resto del mondo. Chi è partito prima ha vinto la battaglia (vedi ESRI con gli shapefile e AutoCAD con i dwg).
Oggi anche i progetti OS più giovani, come uDIG o gvSIG, la prima cosa sulla quale hanno lavorato è proprio l’interoperabilità: garantire la lettura degli shapefile (e aggiungerei anche ecw, ma parlarne è delicato perchè non è standard aperto) è il minimo richiesto a software che debuttano nel mondo difficile dei GIS.
E’ per questo che i vari IDRISI, OSUMAP (si vabbè), GeoMedia (mi perdonino i suoi fan), e altri software o si sono estinti naturalmente, o li usano una decina di persone nel mondo, sebbene abbiano contribuito a fare la storia dei GIS (dategli un’occhiata, ne vale la pena).
Ma io personalmente credo in ILWIS, ci sono legato da quando ho cominciato a muovere i primi passi nella geomatica – quasi 15 anni fa – e sono convinto addirittura che i suoi algoritmi possano essere alla pari di quelli di GRASS, ciò che gli manca è però la capacità di parlare al resto del mondo… interoperabilità e WMS, basta formati proprietari. Mica poco!
Prima di entrare nel vivo di questo brevissimo tutorial, caliamoci nello scenario adatto:
supponiamo che vi siano arrivati dei geodati o delle informazioni geografiche su cui lavorare e che dobbiate, una volta completata la loro elaborazione, mostrare il risultato del vostro brillante operato a qualcuno che non può sedersi di fronte al monitor del computer con voi ed è colto da visioni apocalittiche al solo sentir nominare uno shapefile o pensa che PostGIS sia un piatto tipico.
Che fare? Mettere in piedi un’applicazione di webmapping “vera” (per esempio con MapFish) richiede quel minimo di tempo, di cui non è sempre detto che si disponga, e ci costringe a scrivere un po’ di codice… cosa che oggi non abbiamo assolutamente voglia di fare
Per fortuna, per soddisfare in maniera rapida e indolore la sete di “sapere geografico” del nostro interlocutore, possiamo approfittare dei servigi di Google.
Fatto il doveroso preambolo, passiamo alla pratica.
Creeremo un’applicazione che, pur non essendo di webmapping in senso stretto, svolgerà egregiamente il suo compito, vale a dire condividere online l’informazione geografica in maniera estremamente speditiva e piuttosto efficace.
Di cosa c’è bisogno?
Per trasformare i dati in KML ci sono un’infinità di metodi e di programmi più o meno adatti alle varie esigenze, quindi non entreremo nel merito di questa operazione nel tutorial.
Personalmente, se sto lavorando con ArcGIS, per esportare le feature in formato KML direttamente da ArcMap utilizzo questo script liberamente scaricabile dal sito di ESRI.
In alternativa possiamo ottenere tutti i KML che vogliamo sfruttando la libreria GDAL/ORG (magari attraverso FWTools).
Una volta che i file KML sono pronti all’uso potremmo già pubblicarli su Google Maps grazie al nostro account (utilizzando il link “My maps” o, in italiano, “Le mie mappe” nella home page di Google Maps), ma noi vogliamo di più!
Spesso, infatti, allo scopo di rendere più leggibile l’informazione che vogliamo comunicare con una mappa, è comodo organizzare i contenuti in categorie da mostrare secondo una struttura ad albero composta da cartelle e sottocartelle (del tutto simile a quella ottenibile con il widget layer tree di MapFish).
Per creare questa struttura lanciamo, quindi, Google Earth e aggiungiamo le varie cartelle con un semplice click destro sulla cartella predefinita “Luoghi temporanei”. Si aprirà un menu contestuale dal quale selezioneremo la voce “Aggiungi” e poi “Cartella”:
Ripetiamo questa operazione tante volte quanti sono i nodi (o rami, se preferite) dell’albero che stiamo impostando e, se necessario, annidiamo sottocartelle a piacimento:
Ora che la struttura ad albero è pronta aggiungiamo i file KML dal menu “File” → “Apri” di Google Earth e poi spostiamoli diligentemente uno per uno all’interno della cartella desiderata. Infine, salviamo tutto in un unico file KML (o KMZ) cliccando col tasto destro del mouse sulla cartella “Luoghi temporanei” (che dovrebbe risultare la radice dell’albero).
Siamo finalmente pronti per pubblicare il risultato online tramite Google Maps ed è qui che entra in gioco il servizio Google Sites collegato col nostro account.
Grazie ad esso, infatti, disponiamo di uno spazio web sul quale possiamo caricare file di svariati tipi tra cui, ovviamente, anche KML e KMZ.
Accediamo quindi alla pagina principale del nostro account Google e, una volta effettuata l’autenticazione, clicchiamo sul link “Google Sites”. Se è la prima volta che utilizziamo il servizio, creiamo un nuovo sito cliccando sul bottone apposito.
Scegliamo la modalità preferita per caricare il nostro KML (è possibile allegarlo ad una pagina qualsiasi, magari alla homepage, che troviamo bella e pronta, o creare un “File cabinet” allo scopo).
Da adesso in poi la risorsa caricata sarà disponibile all’URL http://sites.google.com/site/nomesito/nomefile.kml
Per vedere il risultato finale incolliamo questo URL nel campo di ricerca di Google Maps, clicchiamo sul bottone “Cerca sulle mappe”… et voilà[2]
Non resta che copiare l’URL della nostra mappa cliccando sull’apposita voce “link” che appare in alto a destra in Google Maps ed inviarlo a chi ci pare!
… [1]Disponendo di uno spazio web alternativo su cui caricare i file possiamo farne a meno
[2]I simboli utilizzati sono quelli disponibili di default in Google Earth… Vi consiglio anche di visitare i luoghi dell’esempio se capitate da quelle parti
Mi era già capitato di parlare di GISCorps, una ONG di esperti che prestano su base volontaria le loro conoscenze e capacità geomatiche in tutto il mondo. Si è aggiunta di recente anche l’inglese MapAction, e qui voglio segnalare la loro fantastica “Field Guide to Humanitarian Mapping”.
Al di là del target espressamente rivolto alle emergenze umanitarie, la guida è davvero ben fatta, utilissima anche per chi desidera un documento agile – sono poco più di un centinaio di pagine – e chiaro – molti tutorial – per acquisire i concetti alla base dei GIS come pure dell’uso del GPS in campo.
Il primo capitolo introduce alla cartografia e approfondisce argomenti riguardanti i dati spaziali e i vari formati nei quali è possibile trovarli, i sistemi di coordinate. Il secondo capitolo è dedicato all’uso dei dispositivi GPS per raccogliere dati in campo, con un pratico schema per registrare i waypoint. Il terzo e quarto capitolo sono veri e propri tutorial per l’utilizzo di Google Earth e MapWindow – un GIS open source – per la cartografia a scopo umanitario. MapAction lavora soprattutto con Google Earth perchè da un lato si tratta del software di mapping che mette a disposizione i dati cartografici di base – foto aeree e immagini satellitari – più aggiornati disponibili, dall’altro perchè è estremamente diffuso anche tra i non addetti ai lavori.
In definitiva, questa guida è certamente un ottimo modo per i newbie di sporcarsi le mani e capire cosa vuol dire fare della cartografia digitale e quali possono essere i suoi impieghi pratici. Se poi ci si appassiona e si vuol dare il proprio contributo alla causa umanitaria… tanto meglio!
TANTO non rappresenta una testata giornalistica ai sensi della legge n. 62 del 7.03.2001, in quanto non viene aggiornato con una precisa e determinata periodicita'. Pertanto, in alcun modo puo' considerarsi un prodotto editoriale.
C’era bisogno dell’ennesimo progetto GIS open-source? Non bastavano i veterani QGIS e GRASS e la numerosa schiera dei più giovani uDIG, GvSIG, OpenJUMP, MapWindow solo per citare i più famosi? Ma certo che no! Open source in open minds ci piace dire da queste parti…
Posso dire di essere un sostenitore dell’open source e senza dubbio preferisco avere a che fare con software, tecnologie e formati aperti. Al movimento del software libero sono molto legato, per alcuni versi ne faccio parte e, quando posso, cerco di dare i miei microscopici contributi 
