10 agosto, 2009 | di Pietro Blu Giandonato

Era un pezzo che desideravo sperimentare Yahoo Pipes , dopo esserne venuto a conoscenza grazie ad Andrea (ricorderete il suo precedente geniale post). In effetti ho giocato d’anticipo proprio su di lui, per cimentarmi a produrre un GeoRSS in puro stile web 2.0.

Non ho certo intenzione di mettermi qui a tessere le lodi di Pipes, sebbene a mio avviso non se ne parli mai abbastanza. Voglio solo ribadire che si tratta di uno strumento web 2.0 dalle potenzialità pressoché infinite, che aumentano esponenzialmente in funzione della crescente messe di risorse e fonti di dati disponibili sul web. A patto che, inutile dirlo, lo siano secondo standard aperti, come già Andrea ha molto ben sottolineato proprio nel suo citato articolo.

Passiamo ai fatti.

Un item GeoRSS, nella codifica W3C ha la seguente struttura:

<?xml version=\"1.0\"?>
 <?xml-stylesheet href=\"/eqcenter/catalogs/rssxsl.php?feed=eqs7day-M5.xml\" type=\"text/xsl\"
                  media=\"screen\"?>
 <rss version=\"2.0\"
      xmlns:geo=\"http://www.w3.org/2003/01/geo/wgs84_pos#\"
      xmlns:dc=\"http://purl.org/dc/elements/1.1/\">
  <channel>
     <title>USGS M5+ Earthquakes</title>
     <description>Real-time, worldwide earthquake list for the past 7 days</description>
     <link>http://earthquake.usgs.gov/eqcenter/</link>
     <dc:publisher>U.S. Geological Survey</dc:publisher>
     <pubDate>Thu, 27 Dec 2007 23:56:15 PST</pubDate>
     <item> <pubDate>Fri, 28 Dec 2007 05:24:17 GMT</pubDate> <title>M 5.3, northern Sumatra, Indonesia</title> <description>December 28, 2007 05:24:17 GMT</description> <link>http://earthquake.usgs.gov/eqcenter/recenteqsww/Quakes/us2007llai.php</link> <geo:lat>5.5319</geo:lat> <geo:long>95.8972</geo:long> </item>
     </channel>
   </rss>

L’obiettivo è costruire un GeoRSS a partire da una fonte di dati che viene aggiornata in tempo reale, nella fattispecie – e tanto per essere originali – l’elenco dei terremoti rilevati dal Centro Nazionale Terremoti dell’INGV, sul cui sito vedrete una pagina html con tutti gli ultimi eventi rilevati.

Per il nostro lavoro utilizzeremo sempre le stesse informazioni, ma in formato standard CSV – disponibili qui – dunque perfettamente importabili pressochè ovunque. Vediamone i contenuti:

• Lat – la latitudine dell’evento in gradi decimali;
• Lon – la longitudine dell’evento in gradi decimali;
• Depth – la profondità dell’ipocentro in km;
• UTC_Date – il momento temporale nel quale l’evento è stato registrato;
• Magnitude – la magnitudine Richter dell’evento;
• Locality – il distretto sismico nel quale è avvenuto il terremoto;
• Code – un codice univoco relativo all’evento;
• Query_Time – il tempo di query del file CSV, corrispondente a quello di caricamento della pagina del sito INGV.

In Pipes, il primo passo consiste nell’andare a recuperare (fetch) la fonte dei dati (il file CSV) per poterne poi utilizzare il contenuto. Verrà utilizzato il modulo “Fetch CSV” nel quale andremo ad inserire l’URL del CSV, usando la prima riga come intestazione delle colonne.

Per poter generare il GeoRSS, Pipes deve “vedere” nei dati recuperati elementi che siano chiaramente riferibili a una coppia di coordinate, pertanto rinomineremo i campi “Lat” e “Lon” del CSV nei prosaici “Latitude” e “Longitude” mediante il modulo “Rename”.

Lo standard GeoRSS prevede alcuni item che consentono di arricchire di informazioni descrittive ogni elemento geotaggato, poi visibili nel “balloon” ad esso associato in fase di visualizzazione su mappa.

Naturalmente si tratta di informazioni residenti nel CSV, che noi andremo opportunamente a rinominare in modo da consentire a Pipes di includerle nel singolo elemento del GeoRSS. Si tratta essenzialmente di:

• <title> – il titolo dell’elemento, in questo caso il distretto sismico nel quale è avvenuto l’evento;
• <link> – l’URL alla risorsa associata all’elemento, ovvero la pagina dedicata al singolo evento sismico, realizzata dall’INGV;
• <description> – la descrizione dell’elemento, con la magnitudine, la profondità dell’ipocentro e la data del terremoto.

Passeremo queste informazioni al Pipe semplicemente usando sempre il modulo “Rename” avendo stavolta l’accortezza di scegliere l’opzione “Copy As”.

Qui sopra per <title>, con la necessità di sostituire l’antiestetico underscore presente nel campo “Locality” del CSV con uno spazio vuoto (blank) grazie al modulo “Regex”.

La <description> dell’elemento geotaggato come già detto è costituita da magnitudine, profondità dell’ipocentro e data dell’evento sismico, informazioni presenti in tre differenti campi del CSV, che andremo a comporre in un’unica stringa grazie al modulo “String Builder”. Questo verrà utilizzato però nell’ambito di un modulo “Loop”, poichè è un’operazione che va ripetuta per ogni elemento presente nel CSV.

Notate come il risultato dello String Builder vada ad essere assegnato all’item <description>.

L’INGV, per ogni evento sismico registrato, genera una pagina html che riporta informazioni estremamente dettagliate riguardanti il terremoto, molto preziose per chi si occupa di sismologia, di protezione civile o comunque davvero interessanti anche a scopo didattico. Qui quella relativa al famigerato evento del 6 aprile scorso che ha devastato l’Aquilano.

Osservando l’URL si nota che la stringa risulta la seguente:

http://cnt.rm.ingv.it/data_id/[codice evento]/event.html

dunque ciò che cambia è il codice evento, registrato nel campo “Code” del CSV. Ancora una volta, useremo la combinazione dei moduli “Loop” e “String Builder” per costruire il link alla pagina di ogni evento, assegnando il risultato all’item “eventoURL” che verrà poi rinominato nell’item <link>.

Dulcis in fundo… il modulo che genera il vero e proprio GeoRSS… voilà, si tratta di “Location Extractor”.

Voi direte: “embè, e i parametri dove sono?!?”. E’ quel che mi son chiesto anch’io quando l’ho visto. Ma poi leggendo la descrizione del modulo (cosa che vi consiglio vivamente di fare), si capisce come funziona:

Questo modulo esamina il feed in input, alla ricerca di informazioni che indichino una località geografica. Se trova dati geografici, il modulo crea una y:location che costituisce l’elemento di output. Questo contiene svariati sotto-elementi, in funzione del feed di input.

Dunque fa tutto lui. In pasto possiamo dargli sorgenti GML, W3C Basic Geo, tags KML e ovviamente GeoRSS, in output fornirà appunto l’elemento y:location, che potrà essere visualizzato direttamente su una mappa interattiva Yahoo Map. Qui sotto il risultato…

Ma il vero valore aggiunto del pipe è quello di poter essere impiegato in svariati modi, dal “banale” embedding della mappa in blog e siti web, per finire ad altri davvero potentissimi, riutilizzabili in una miriade di modalità. Solo per citarne alcuni JSON, PHP, KML e ovviamente GeoRSS.

E proprio il GeoRSS può essere usato ad esempio con OpenLayers, scrivendo un pò di codice html è possibile in pochi minuti importare il feed generato dal pipe come layer grazie alla call OpenLayers.Layer.GeoRSS ottenendo una mappa semplice ma efficace, come si vede in questo esempio… Altre modalità di fruizione del GeoRSS – generate sempre in modo automatico – le riporto qui appresso giusto per coloro che non hanno voglia di andare a consultare la pagina del pipe:

• Direttamente in Google Maps;
• Un kml da aprire con Google Earth.

Insomma, a noi Yahoo Pipes ci fa letteralmente sognare… Perchè sapere di avere uno strumento col quale poter attingere, trasformare, plasmare e “ricablare il web” (il loro slogan) e i dati sparsi per il mondo usando la logica ad oggetti, dedicando i propri neuroni solo ed esclusivamente alle idee e al modo di tradurle in fatti… beh, è davvero troppo, troppo entusiasmante.

E allora “Yes, we Pipe!”… ma prima ancora “Linked Data… now!!!”.

Posted in Didattica | 4 Comments »

2 agosto, 2009 | di Alessio Di Lorenzo

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!

Posted in Strumenti | 27 Comments »

1 luglio, 2009 | di Andrea Borruso

I miei siti di ispirazione di web-mapping sono diversi. Nella mia top five c’è sicuramente EveryBlock, perché unisce leggibilità, efficacia, eleganza e attenzione alle buone pratiche (non soltanto dal punto di vista tecnologico).

Risponde ad una domanda “necessaria”: cosa avviene attorno a me?

Sono raccolte essenzialmente tre tipi di notizie:

• Informazione civica — permessi di costruzione, informazioni sulla criminalità, verifiche sui ristoranti, eccetera. In molti casi l’informazione è già sul web ma è dispersa in database dell’amministrazione difficili di individuare. In altri casi l’informazione viene pubblicata per la prima volta in collaborazione con gli enti pubblici.
• Notizie — dai principali quotidiani, settimanali locali, TV e radio, pubblicazioni e blog. L’informazione viene classificata geograficamente in modo da evidenziare la copertura mediatica di uno specifico rione cittadino.
• Divertimento — fotografie relative alle zone coperte pubblicate su Flickr, opinioni sulle attività commerciali recensite su Yelp, annunci di oggetti smarriti/ritrovati su Craigslist e altro.

E’ un servizio disponibile soltanto per alcune città degli Stati Uniti. Questo ad esempio l’URL per New York: http://nyc.everyblock.com/

L’interfaccia è raffinata e semplice allo stesso tempo, ed è notevole il numero di informazioni che trovate raccolte. Qui una lista di quelle del quartiere “DUMBO – Vinegar Hill – Downtown Brooklyn – Boerum Hill”.

Di ciascuno di questi report è possibile averne una visualizzazione cartografica e molto spesso anche un grafico che illustra l’andamento della variabile in oggetto (ad esempio la richiesta di rimozioni di graffiti!). Le città sono esplorabili per quartieri e per CAP.

Da oggi il codice che sta dietro EveryBlock è rilasciato in opensource, e già sogno di vederlo in azione per realtà a noi più vicine. Questo è quello che ci troverete dentro:

The main package (probably the thing you’re looking for) is the publishing system, known as ebpub.
Second, the packages ebdata and ebgeo contain Python modules for processing data and making maps.
Third, the packages ebinternal and everyblock round out the code that powers EveryBlock.com. They’re internal tools and are likely not of general use, but we’re including them to be complete.
Finally, ebblog and ebwiki are our blog and wiki software, respectively. Because, dammit, the world needs another Django-powered blogging tool.

Il codice è scritto Python sfruttando il framework web Django. Mi piacerebbe potermici sporcare le mani, ma in Python non vado oltre la dichiarazione di una variabile.

Se qualche lettore di TANTO dovesse fare qualche esperimento, ci contatti subito

Via O’Reilly Radar.

Posted in News, osgeo | 1 Comment »

4 maggio, 2009 | di Alessio Di Lorenzo

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?

• dei vostri geodati in formato KML o KMZ;
• di un account Google^[1] che, se usate Gmail, avete già;
• Google Earth.

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

Posted in Didattica | 19 Comments »

23 aprile, 2009 | di Alessio Di Lorenzo

Come prima cosa vorrei ringraziare Andrea per avermi dato la possibilità di contribuire, nel mio piccolo, a TANTO, scusandomi con lui per tutto il tempo (davvero troppo) passato da quando gli ho promesso questo tutorial ad oggi!

In questo breve articolo-tutorial cercherò di fare una panoramica sulla componente client di MapFish, un framework open source basato su ExtJs e OpenLayers, grazie al quale è possibile realizzare delle applicazioni webgis in pieno stile web 2.0 con poco sforzo una volta compreso il funzionamento degli “ingranaggi”.

Innanzitutto va detto che la parte relativa al mapping vero e proprio può essere gestita esattamente come in OpenLayers che, come già ricordato, è compreso all’interno di MapFish.
Si ha quindi a disposizione tutta la flessibilità di OpenLayers (layer WMS, WFS, Google, Yahoo, ecc.) e se si sanno già realizzare mappe online con questa ottima libreria, il passaggio a MapFish consiste semplicemente nel comprendere come gestire layout ed eventi alla maniera di ExtJs (l’altra componente del framework) e nello scoprire gli utili widget che MapFish mette a disposizione dello sviluppatore.

L’utilizzo di questi widget è simile a quello dei controlli di OpenLayers, con la differenza che in questo caso viene sfruttata la potenza di ExtJs per aggiungere un’interfaccia utente avanzata al controllo. I widget che necessitano del solo codice lato client sono:

• Toolbar – una barra degli strumenti con dei tasti preimpostati (full-extent, pan, zoombox, zoom out) che è possibile espandere con nuovi bottoni sapendosi muovere un minimo con OL;
• Layer Tree – si tratta di una “toc”, simile al layer switcher di OL, ma molto più configurabile, con la possibilità di includere facilmente icone e di annidare e raggruppare i layer a proprio piacimento;
• Scorciatoie – liste a discesa con possibilità di autocompletamento del testo inserito (come avviene in Google suggest, per capirci) che centrano la mappa sulle coordinate corrispondenti al luogo/elemento scelto;
• Stampa – un semplice controllo da includere per stampare la porzione di mappa visualizzata.

Affinché gli altri widget di MapFish (stampa complessa, ricerca nel db, ecc.) funzionino, è necessario che sia installata la componente server del framework che, però, non tratteremo in questo articolo (anche perché, non avendoci mai lavorato, rischierei di scrivere una montagna di cavolate!).
ExtJs semplifica la creazione di layout, anche molto complessi, che risultano accattivanti per l’utente e cross-browser. Con poche righe di codice è possibile creare interfacce a schede (tab), menu accordion, form avanzati, ecc… avendo la sicurezza che l’applicazione verrà correttamente visualizzata su tutti i browser più diffusi in circolazione. Con ExtJs possiamo ottenere rapidamente delle belle GUI in cui “infilare” le nostre applicazioni webgis. Insomma, sono assicurati un risultato di tutto rispetto e un bel risparmio di diottrie e bile (è risaputo che quella di rendere cross-browser delle appicazioni web “complesse” sia una delle attività che più contribuiscono alla creazione di nuovi tipi di imprecazioni… ).

Fatta questa introduzione, passiamo al tutorial vero e proprio!

Tutorial MapFish

Creeremo una semplice applicazione webgis, munita di una toolbar e di un layer tree, con cui sarà possibile visualizzare la localizzazione degli utenti GRASS su due mappe di base alternative.
Le informazioni che mostreremo provengono da diversi server WMS (Nasa, Metacarta, Grass).
Utilizzeremo la versione 1.1 del framework MapFish, scaricabile da qui come archivio compresso in formato tar.gz (se state lavorando in ambiente Windows, vi consiglio di procurarvi l’ottimo 7zip per estrarne il contenuto).

Il primo passaggio consiste ovviamente nello scompattare quanto abbiamo scaricato in modo da ottenere una cartella (MapFish-1.1) che contiene tutto il necessario per creare la nostra applicazione d’esempio.
Utilizzando la sola parte client non abbiamo bisogno di rendere visibile il tutto ad un eventuale webserver e possiamo posizionare la directory di cui sopra dove più ci aggrada nel filesystem…
Tuttavia, per mantenere un certo ordine, consiglio di creare una ulteriore cartella, che chiameremo “EsempioMF”, e di lavorare al suo interno.
Creiamo anche un file index.html, un file myMapFish.js e spostiamo anche loro nella cartella di lavoro “EsempioMF”.
A questo punto, quindi, la situazione dovrebbe essere la seguente:

EsempioMF
|
– MapFish-1.1
|
– index.html
|
– myMapfish.js

Ora che siamo organizzati in modo più o meno ordinato, è il momento di riempire il file index.html.
Ecco come:

	
<html>
<head>
<title>Esempio MapFish by TANTO</title>
	
<!-- link ai CSS della componente ExtJS
(è possibile scaricare temi dal sito di extjs e sostituire default.css con il foglio di stile del tema scaricato... ce ne sono un paio che meritano) -->
<link rel="stylesheet" type="text/css" href="MapFish-1.1/client/mfbase/ext/resources/css/ext-all.css" />
<link rel="stylesheet" type="text/css" href="MapFish-1.1/client/mfbase/ext/resources/css/default.css" />
	
<!-- Inserisco i riferimenti agli script Javascript necessari al funzionamento del framework MapFish -->
<script type="text/javascript" src="MapFish-1.1/client/mfbase/openlayers/lib/OpenLayers.js"></script>
<script type="text/javascript" src="MapFish-1.1/client/mfbase/ext/adapter/ext/ext-base.js"></script>
<script type="text/javascript" src="MapFish-1.1/client/mfbase/ext/ext-all.js"></script>
<script type="text/javascript" src="MapFish-1.1/client/mfbase/mapfish/MapFish.js"></script>
	
<!-- Inserisco il riferimento allo script Javascript myMapFish.js -->
<script type="text/javascript" src="myMapFish.js"></script>
</head>
<body>
<!-- Nel body creo i div che faranno da contenitori per la mappa vera e propria, per la toolbar e per il layer tree -->
<div id="map"></div>
<div id="buttonbar"></div>
<div id="tree"></div>
</body>
</html>
	

I commenti indicano cosa è stato inserito nell’header.Quindi possiamo chiudere index.html e iniziare a lavorare sullo script myMapFish.js.
Questo script conterrà due porzioni ben distinte:
- la prima servirà a definire il layout dell’applicazione (codice ExtJs);
- la seconda definirà la mappa vera e propria (codice OpenLayers) ed i widget MapFish che utilizzeremo.

Cominciamo, quindi, dalla prima parte dello script ed inseriamo quanto segue:

	
//Layout dell'applicazione
//************************
Ext.onReady(function() {
    new Ext.Viewport({
        layout:'border',
        items:[{
                region:'north',
                margins:'4 4 4 4',
                height: 63,
                html: '<img src="http://blog.spaziogis.it/wp-content/themes/blacknwhite/blacknwhite/images/TANTO_logo.png"/>',
                bodyStyle:'padding:2px;'
                },{
                region:'center',
                layout:'border',
                margins:'0 4 4 4',
                items:[{
                        region:'north',
                        border:false,
                        contentEl:'buttonbar',
                        height:26
                        },{
                        region:'center',
                        contentEl:'map',
                        border:false
                }]
                },{
                title:'Layer tree',
                region:'east',
                margins:'0 4 4 0',
                width:350,
                contentEl:'tree',
                collapsible:true
                },{
                region:'south',
                margins:'0 4 4 4',
                height:20,
                html:'Esempio realizzato per TANTO',
                bodyStyle:'padding:2px;font-size:12px;font-family:tahoma,arial,helvetica'
        }]
	
    });
	
});
	

questa porzione di codice definisce completamente la webgui, non c’è bisogno di altro.
In sintesi, dopo aver inizializzato ExtJs con il metodo Ext.onReady, abbiamo creato un oggetto Viewport per dire ad ExtJs di utilizzare tutta la finestra del browser (dimenticavo… vogliamo che la nostra applicazione sia a tutto schermo ) e poi abbiamo inserito un layout di tipo ‘border’ all’interndo del quale (nel pannello ‘center’) abbiamo annidato un secondo layout dello stesso tipo.
Ogni layout di tipo border può contenere 5 panneli (‘region’), detti north, center, east, west, south. Di questi solo ‘center’ è obbligatorio.
Ad ogni modo vi rimando all’esplorazione del sito di ExtJs per scoprire come complicare a piacimento i vostri layout. Il sito è molto ben fatto, pieno di tutorial ed esempi.

Passiamo ora alla mappa e ai mapfish widget.
Sempre all’interno del file myMapFish.js inseriamo questo pezzo di codice sotto al precedente:

	
//Mappa e Widget
//************************
	
function initMap(){
	
    //Creo la mappa e definisco alcuni controlli di base
    var map = new OpenLayers.Map('map',{controls:[
        new OpenLayers.Control.Navigation(),
        new OpenLayers.Control.PanZoomBar()
    ]});
	
    //Definisco l'extent che utilizzerò come vista iniziale
    var bounds = new OpenLayers.Bounds(5,36,21,50);
	
    //Definisco i layer WMS, due di base (alternativi) e uno di overlay
    var jpl_wms = new OpenLayers.Layer.WMS("NASA_Global_Mosaic",
"http://t1.hypercube.telascience.org/cgi-bin/landsat7",{layers: "landsat7"});
	
    var ol_wms = new OpenLayers.Layer.WMS("OpenLayers_WMS",
"http://labs.metacarta.com/wms/vmap0",{layers: 'basic'});
	
    var grass_users = new OpenLayers.Layer.WMS.Untiled("Utenti_grass",
"http://mapserver.gdf-hannover.de/cgi-bin/grassuserwms?",
        {layers: 'GRASS-Users',transparent:true, format:'image/png'},
        {isBaseLayer:false});
	
    //Aggiungo i layer alla mappa
    map.addLayers([jpl_wms,ol_wms,grass_users]);
	
    //Aggiungo il toolbar widget di MapFish:
    //**************************************
    //Creo la toolbar
    var toolbar = new mapfish.widgets.toolbar.Toolbar({map: map, configurable:true});
	
    //Scelgo di renderizzare la toolbar in un div con id = buttonbar
    toolbar.render('buttonbar');
	
    //Aggiungo i bottoni/controlli
    toolbar.addControl(new OpenLayers.Control.ZoomBox(), {iconCls: 'zoomin',toggleGroup: 'map'});
    toolbar.addControl(new OpenLayers.Control.ZoomOut(), {iconCls: 'zoomout',toggleGroup: 'map'});
    toolbar.addControl(new OpenLayers.Control.DragPan({isDefault: true}),{iconCls: 'pan', toggleGroup: 'map'});
	
    //Attivo la toolbar
    toolbar.activate();
	
    //Layer tree
    //***************************************
    //Creo un modello per il layer tree, distribuendo i layer in due nodi espandibili distinti (Mappe di base e Overlay)
    var model = [{
         text: "Mappe di base",
         expanded: true,
         children: [{
              checked:true,
              text:"Nasa Global Mosaic",
              layerName:"NASA_Global_Mosaic"
              },{
              checked:false,
              text:"OpenLayers WMS",
              layerName:"OpenLayers_WMS"
         }]},{
         text: "Overlay",
         expanded: true,
         children: [{
              checked:false,
              text:"Utenti GRASS",
              layerName:"Utenti_grass"
          }]
    }];
	
    //Inserisco il widget vero e proprio indicando
    var tree = new mapfish.widgets.LayerTree({
    map: map, el: 'tree',
    model: model,
    border:false, autoHeight:true
    });
    tree.render();
	
    //Centro la mappa sull'extent definito in precedenza
    map.zoomToExtent(bounds);
	
} //fine della funzione init()
	

Anche qui i commenti dovrebbero essere abbastanza chiari.
Abbiamo creato una mappa esattamente come se stessimo lavorando con buon vecchio OpenLayers e, in più, abbiamo inserito nel codice due MapFish widget.

Prima di vedere il risultato del nostro lavoro dobbiamo fare due piccole modifica al file index.html:
- inserire un evento onload a livello del tag per fare in modo che la mappa venga caricata all’apertura della pagina (esattamente come in OL);
- inseire alcune regole CSS necessarie per la corretta visualizzazione dei MapFish widget

Ecco come deve apparire index.html modificato a dovere:

	
<html>
<head>
<title>Esempio MapFish by TANTO</title>
	
<!-- link ai CSS della componente ExtJS
(è possibile scaricare temi dal sito di extjs e sostituire default.css con il foglio di stile del tema scaricato... ce ne sono un paio che meritano) -->
<link rel="stylesheet" type="text/css" href="MapFish-1.1/client/mfbase/ext/resources/css/ext-all.css" />
<link rel="stylesheet" type="text/css" href="MapFish-1.1/client/mfbase/ext/resources/css/default.css" />
	
<!-- Inserisco i riferimenti agli script Javascript necessari al funzionamento del framework MapFish -->
<script type="text/javascript" src="MapFish-1.1/client/mfbase/openlayers/lib/OpenLayers.js"></script>
<script type="text/javascript" src="MapFish-1.1/client/mfbase/ext/adapter/ext/ext-base.js"></script>
<script type="text/javascript" src="MapFish-1.1/client/mfbase/ext/ext-all.js"></script>
<script type="text/javascript" src="MapFish-1.1/client/mfbase/mapfish/MapFish.js"></script>
	
<!-- Inserisco il riferimento allo script Javascript myMapFish.js -->
<script type="text/javascript" src="myMapFish.js"></script>
</head>
<body onload="initMap()">
<!-- Nel body creo i div che faranno da contenitori per la mappa vera e propria, per la toolbar e per il layer tree -->
<div id="map"></div>
<div id="buttonbar"></div>
<div id="tree"></div>
</body>
</html>
	
<style type="text/css">
/* Icone dei bottoni della toolbar */
.zoomin {
background-image:url(MapFish-1.1/client/mfbase/mapfish/img/icon_zoomin.png) !important;
height:20px !important;
width:20px !important;
}
.zoomout {
background-image:url(MapFish-1.1/client/mfbase/mapfish/img/icon_zoomout.png) !important;
height:20px !important;
width:20px !important;
}
	
.pan {
background-image:url(MapFish-1.1/client/mfbase/mapfish/img/icon_pan.png) !important;
height:20px !important;
width:20px !important;
}
	
/* Dimensioni del Layer tree */
#tree {
height: 100%;
width: 100%;
}
</style>
	

Adesso apriamo index.html col borwser e il risultato dovrebbe essere questo.

Posted in Didattica | 19 Comments »