Così ho fatto la cosa teoricamente più ovvia del mondo: una ricerca su Google. In non più di 10 minuti ho rinvenuto, sul sito dell’Agenzia Regionale per la Tutela dell’Ambiente (ARTA), le informazioni che volevo. Tutto era riportato negli allegati della D.G.R. 148 del 10/03/2016 e in un’applicazione web della stessa ARTA, da cui era possibile scaricare i risultati delle analisi in formato Excel e PDF.
Entusiasta di questa scoperta ho subito pensato di realizzare un’applicazione di web mapping, di quelle che “mi piacciono TANTO”, per facilitare la lettura dei dati messi a disposizione dall’ARTA. Il mio entusiasmo, però, si è smorzato non poco quando ho notato che l’unico file in cui erano riportate le coordinate dei limiti dei tratti di costa analizzati e dei punti di prelievo era il PDF della D.G.R.
Storcendo un po’ il naso, l’ho scaricato, ho estratto le pagine con i dati e, dopo un paio di tentativi poco fortunati di tirarne fuori in maniera (semi)automatica qualcosa di utilizzabile con dei programmi OCR online, mi sono rassegnato a ricopiare a mano le righe che riguardavano la mia provincia (Pescara) in un file di testo che ho poi salvato in CSV. Usando questo file parziale ho creato una mappa tematica semplicissima con Google My Maps e l’ho condivisa, molto poco soddisfatto del risultato, su Facebook, dicendomi: “Meglio di niente!”. Nonostante non fossi soddisfatto a livello tecnico, l’obiettivo si poteva dire raggiunto: i risultati delle analisi dicono che l’acqua è sostanzialmente pulita, addirittura di qualità eccellente lungo gran parte della costa. Alla faccia del disfattismo e del qualunquismo da tastiera.

Discorso chiuso? Sembrava di sì, anche perché nel frattempo avevo scritto una mail all’ARTA chiedendo gli stessi dati del PDF, ma in un formato diverso, senza ricevere alcuna risposta. Come al solito, però, Andrea è stato in grado di darmi un suggerimento fondamentale:

Grazie ai dati del Portale Acque, distribuiti sotto licenza CC per mezzo di una serie di servizi ReST (per quanto non sia ancora riuscito a capire fino in fondo come sono strutturati) la musica è cambiata radicalmente e, realizzando uno script in PHP per il recupero dei dati in cross origin e un client Javascript basato sull’ottimo Bootleaf, ho sviluppato una sorta di clone dell’applicazione di web mapping ufficiale, con la differenza che la mia considera i soli dati sulla costa abruzzese e che la tematizzazione della mappa non si limita a classificare le zone indagate secondo una scala di due colori (verde/rosso = aperto/chiuso) ma riprende una scala più fine che, sul Portale Acque, è espressa da un simbolo colorato visibile solo accedendo con un clic al pannello di dettaglio di ogni zona. La potete vedere all’opera cliccando qui, mentre qui trovate il repository con il codice su GitHub.

A lavoro ultimato ho pubblicato un nuovo post sui canali social e stavolta, non so se per il maggior “impatto estetico” della nuova applicazione o per la più immediata leggibilità rispetto al tentativo precedente, in poche ore ho ottenuto diversi commenti con richieste di dettagli, svariate condivisioni e sono stato anche contattato telefonicamente da una persona che mi voleva far intervistare da una sua collaboratrice per un quotidiano locale.
Insomma, mi posso ritenere soddisfatto del risultato perché probabilmente, oggi, c’è in giro qualche persona in più che, anche grazie alla mia piccola opera di divulgazione e a un po’ di sano passaparola (perché basato su dati oggettivi), sa che può andare al mare in Abruzzo e fare il bagno avendo delle buone probabilità di portare a casa la pelle.

In chiusura, mi preme sottolineare quanto sia importante rendere accessibili e divulgare nel modo più chiaro possibile dati di interesse pubblico come questi, evitando di dare respiro alle chiacchiere, al disfattismo e ai facili allarmismi, che al giorno d’oggi corrono veloci sulla rete, attecchiscono più facilmente e sono più duri da sradicare dell’erba cattiva!

L'articolo Non fare il bagno in Abruzzo! Lo dicono gli amici dei miei amici di Facebook! è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Verso la fine del 2011 nella mia casella di posta elettronica trovai un invito per una conferenza dal titolo “Gli squali nel Mediterraneo”, che si sarebbe tenuta di lì a pochi giorni a Pescara.
Ormai non ricordo più se il titolo fosse davvero quello, né chi fosse il mittente della mail, fatto sta che decisi di andare, spinto in gran parte dalla voglia di passare – dopo anni – una giornata ad ascoltare discorsi di biologia marina “pura” e prendermi una pausa dalle solite cose: gis, json, rest, php, cors, script, sql, ecc.
Dell’intervento principale sugli squali ricordo poco o nulla, non mi colpì granché, ma ricordo bene l’intervento del dottor Vincenzo Olivieri, veterinario e presidente della Onlus “Centro Studi Cetacei” (CSC), che non parlò di squali, ma di spiaggiamenti di cetacei, dei casi di studio più interessanti che aveva incontrato, di indagini sul campo e metodologie analitiche, del lavoro svolto dalla sua associazione e di tanto altro. Ciò che mi fece drizzare le orecchie, man mano che andava avanti, fu pensare alla quantità di dati – dati spaziali, probabilmente – che il Centro Studi Cetacei poteva (e doveva!) aver raccolto.
Le domande che avevo in testa erano: “Dove li terranno questi dati?”, “In che formato saranno conservati?”, “Saranno disponibili?”, “Saranno accessibili?”.
Al termine della conferenza andai dritto da Olivieri, parlammo una decina di minuti e venne fuori un accordo, direi uno scambio: il Centro Studi Cetacei mi avrebbe fornito i dati sugli spiaggiamenti dopo averli riordinati e organizzati il meglio possibile, visto che erano sparsi in vari fogli Excel, documenti PDF e addirittura qualche scheda cartacea e io avrei sviluppato, senza costi per il CSC, uno strumento informatico per consultarli in maniera semplice e veloce sul web. In cambio chiesi che il risultato di questo nostro sforzo congiunto fosse messo a disposizione come open data.
Ci tengo a sottolineare che questa mia richiesta venne accolta immediatamente e con entusiasmo, segno di un’apertura mentale da parte del mio interlocutore che, ancora oggi, non so quanto sia facile trovare tra i non addetti ai lavori.

Pronti, si comincia!

La primissima fase consistette in una serie di incontri con Vincenzo e con altre persone del CSC; il nostro obiettivo era individuare un minimo comune denominatore nelle informazioni in loro possesso e, partendo da qui, organizzare lo storico in maniera coerente e il più possibile ordinata.
Successivamente fu la volta di scegliere gli strumenti informatici da usare per dare vita al nostro progetto e, non avendo vincoli se non mantenere a zero i costi dell’operazione, decisi per uno stack tecnologico collaudato e completamente open source: PostGIS, GeoServer e OpenLayers. A dire il vero penso che questa sarebbe stata la mia scelta anche se avessimo avuto un budget da spendere!
Scelto lo stack, restava però il problema di mettere in piedi un server. Come molti di voi sapranno, anche se installato con solo software libero, un server ha comunque dei costi legati all’hardware e alla connettività, il che cozzava non poco con il vincolo del costo zero.
Ebbene, senza TANTO e Andrea, al quale parlai del progetto il giorno dopo la conferenza, l’idea sarebbe rimasta nella mia testa, inespressa nella pratica o, al massimo, sarebbe diventata l’ennesima demo in “localhost” sul mio computer.
Il server, alla fine, ce lo ha messo TANTO! Un hosting non da poco, con PostGIS e GeoServer belli e pronti, Apache e PHP per creare pagine web e, soprattutto, persone competenti a gestire l’infrastruttura.
A questo punto, con i dati che iniziavano a prendere forma ed il server pronto ad accogliere l’applicazione, per me era finalmente ora di entrare nel vivo e tirarmi su le maniche per produrre qualcosa di tangibile da mostrare a Vincenzo e al CSC che, nel ripulire, organizzare e armonizzare i dati storici, avevano passato parecchi giorni a lavorare.
Così all’inizio del 2012 venne fuori il primo output, un’applicazione di web mapping strutturata in maniera abbastanza classica e in grado di mostrare i punti dove erano stati effettuati i rilievi sugli animali spiaggiati e le informazioni ad essi associate su una mappa, una griglia ordinabile e dei grafici. Scegliemmo di chiamarla GeoCetus.

I dati potevano essere filtrati su base annuale, adeguando le tre viste di conseguenza. Selezionando un punto, come lecito aspettarsi, compariva una scheda con tutte le informazioni di dettaglio ed era possibile scaricare tutti i dati disponibili in formato KML e CSV, ovviamente sotto licenza CC BY-SA. Nulla di eclatante, insomma, ma funzionale.
Questa prima versione si basava su una sola tabella PostGIS, denominata “spiaggiamenti”, un po’ di codice PHP per tirare fuori un GeoJSON – preferii non scomodare GeoServer in prima battuta – e la mia collaudata cassetta degli attrezzi JavaScript composta da OpenLayers 2.12, jqGrid e Google Charts.

Un buon inizio, ma serve sempre qualcosa in più

L’applicazione di web mapping prodotta non era male, nel senso che faceva quello che doveva fare in base ai requisiti concordati con il CSC e lo faceva discretamente: mostrava i dati e consentiva di interrogarli e scaricarli.
Ben presto, però, sorse la necessità di aggiornare la banca dati in modo che fosse sempre attuale ed utile, così pensai di ricorrere ad un foglio di calcolo su Google Drive. I nuovi dati sarebbero stati inseriti lì e poi, tramite uno script Python, trasferiti in PostGIS con una query SQL.
Lo script funzionava senza particolari problemi, però lasciava irrisolte due questioni importanti:

• vincolare alcuni campi ad un dominio specifico di valori;
• calcolare automaticamente il codice identificativo di ogni evento registrato, il quale doveva seguire uno schema preciso per non violare il vincolo di univocità.

Probabilmente lavorando un po’ di più allo striminzito script Python che avevo prodotto si sarebbe potuta trovare la soluzione ad entrambi i problemi, ma ho preferito creare qualcosa che girasse completamente sul nostro server e sviluppare un modulo gestionale in PHP con interfaccia basata sull’ottimo Twitter Bootstrap (all’epoca la versione stabile era la 2.3.2). Dopo qualche giorno di lavoro venne fuori il prototipo del modulo gestionale:

Questo modulo, accessibile solo agli utenti registrati sul database, costituiva uno strumento di facile utilizzo, tramite il quale chiunque poteva registrare un nuovo spiaggiamento senza incappare in errori grossolani, di distrazione e senza doversi preoccupare del codice di registrazione, che veniva compilato in automatico dal modulo stesso, sulla base delle regole stabilite.
Problema risolto? Certo che no! Le esigenze, man mano che GeoCetus e il suo modulo gestionale venivano utilizzati, divenivano ben maggiori del semplice consultazione e inserimento di nuovi dati. Occorreva spesso correggere o cancellare qualcosa e sarebbe stato bello anche poter allegare dei file per caratterizzare meglio i rilievi registrati.
Inoltre, nel frattempo, era saltata fuori anche la necessità di gestire i dati sulle tartarughe marine.
Come spesso accade, l’appetito viene mangiando.

GeoCetus diventa un portale

Per organizzare al meglio tutti le funzioni e i moduli previsti la cosa migliore era, sicuramente, ripensare l’applicazione in forma di un portale, così, dopo qualche mese di lavoro e svariati aggiornamenti a librerie e script vari, il risultato è quello che tutti possono vedere puntando il browser a questo indirizzo: http://geocetus.spaziogis.it.

Il portale prevede diverse tipologie di utenti, che hanno prerogative diverse sulla gestione dei dati e degli allegati. Ad ogni evento inserito sotto forma di punto è possibile associare fino a 3 foto e 3 documenti in formato PDF relativi a necroscopie ed analisi di laboratorio; a breve sarà possibile collegare anche dei filmati. Tutti i contenuti sono aperti, distribuiti sotto licenza CC BY-SA e messi a disposizione degli interessati sia sotto forma di servizi OGC che dei più comuni formati di file usati in ambito di geodati.
Ora, piuttosto che annoiarvi con l’elenco particolareggiato delle caratteristiche del portale, vi invito a consultare lo slideshow in calce al post e, soprattutto, a visitarlo in prima persona.
Piuttosto, mi preme dire che, per quanto ne so, ad oggi, quella di GeoCetus è la più completa banca dati sugli spiaggiamenti di cetacei e tartarughe marine dell’intero panorama nazionale, che si tratta di una banca dati libera ed accessibile e che, questo risultato, per quanto sia ancora passibile di miglioramenti, è stato raggiunto da un gruppo di volontari. Abbiamo investito parte del nostro tempo libero per dare vita a un progetto che, speriamo, diventi un riferimento per gli addetti ai lavori e, soprattutto, contribuisca ad innescare un clima virtuoso di collaborazione e condivisione delle informazioni anche da parte di altri soggetti.

L'articolo GeoCetus: la banca dati italiana aperta sugli spiaggiamenti di cetacei e tartarughe marine è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Vediamo subito un esempio. Come fonte di dati prendiamo il risultato di un query task lanciato verso un MapService ReST di ArcGIS Server. Il codice per ottenere la griglia di attributi è molto semplice e il risultato di sicuro effetto.

	
$('#grid').jqGrid({
url: 'http://sampleserver1.arcgisonline.com/ArcGIS/rest/'+
     'services/Demographics/ESRI_Census_USA/MapServer/4/query',
datatype: 'jsonp',
postData: $.param({
where: "1=1",
returnGeometry: false,
outFields: "ObjectID,NAME,STATE_NAME,CNTY_FIPS",
f: "json"
}),
colModel: [
{name: 'ObjectID', label: 'ID', width: 60, jsonmap: 'attributes.ObjectID',sorttype:'number'},
{name: 'NAME', label: 'Name', width: 170, jsonmap: 'attributes.NAME'},
{name: 'STATE_NAME', label: 'State', width: 150, jsonmap: 'attributes.STATE_NAME'},
{name: 'CNTY_FIPS', label: 'FIPS', width: 60, jsonmap: 'attributes.CNTY_FIPS'}
],
caption:"ArcGIS Server 10 query",
toppager: false,
pager:"#pager",
rowList: [50, 100, 250, 1000],
rowNum: 50,
jsonReader: {
root: 'features',
repeatitems: false,
},
loadonce: true,
ignoreCase: true,
viewrecords: true,
height: '300',
width:'500'
}).jqGrid('navGrid', '#pager', {search:false, add: false, edit: false, del: false});
});
	

Il codice è volutamente semplice e ovviamente si può sostituire il valore della clausola where, qui passata come parametro e valorizzata con 1=1, con qualcosa di più utile (o dinamico).
Qui sotto potete vedere l’output della query in una tabella dinamica che offre la possibilità di consultare in modo ricco ed interattivo la nostra sorgente di dati spaziali d’esempio

L'articolo jqGrid, ArcGIS Server e JSONP è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Sicuramente si parla di una delle specializzazioni dei Sistemi Informativi Geografici che negli ultimi anni si sono trasformate più velocemente, complice l’evoluzione del World Wide Web e delle tecnologie legate ad esso. Si tratta, inoltre, di una materia fortemente interdisciplinare in quanto, a prescindere dall’ambito nel quale l’applicazione di webmapping verrà impiegata (turismo, analisi ambientale, monitoraggi di vario genere, ecc.), a monte ci sono le competenze di almeno quattro figure professionali differenti che comprendono l’esperto di GIS, il Database administrator, lo sviluppatore e il sistemista.

Ho pensato di scrivere un articolo come questo perché spesso mi capita di avere a che fare con persone interessate ad avvicinarsi a questo mondo o semplicemente curiose di sapere “cosa c’è sotto” ma messe in seria difficoltà dalla quantità, eterogeneità e frammentazione delle informazioni disponibili in rete.
Tutto ciò, insieme all’esistenza di una moltitudine di soluzioni software, di tanti standard reali e de facto, di moltissime filosofie e approcci diversi, crea un labirinto intricato in cui è facile smarrirsi specialmente se si è agli inizi.

La cartografia su internet diventa popolare

Un grande contributo all’esplosione della cartografia su internet è arrivato da alcune applicazioni web basate su mappe, come Google Maps, Google Earth, Yahoo! Maps, Virtual Earth (ora noto come Bing Maps), comparse relativamente pochi anni fa e divenute di massa nel giro di pochissimo tempo.
Lungi dall’essere delle applicazioni GIS in senso stretto, hanno comunque il merito di saper mostrare la forza del punto di vista spaziale: ogni oggetto, se collocato nello spazio geografico, viene arricchito con nuove informazioni intrinseche nella sua localizzazione e nella relazione con gli altri oggetti che si trovano nelle sue vicinanze.
La potenza espressiva della cartografia su internet, per la prima volta sotto gli occhi di tutti e non dei soli addetti ai lavori, ha dato un importante input per il cambio di passo che ha condotto alle moderne applicazioni di webmapping.
Certamente questa direzione si è potuta intraprendere anche grazie all’aumento delle capacità di elaborazione dei browser e alla crescita degli strumenti e delle tecnologie per lo sviluppo delle applicazioni web, alcuni dei quali ideati e rilasciati dagli stessi soggetti titolari delle famose mappe online (si pensi, ad esempio, alle API di Google Maps).
Le vecchie cartografie web, oltre ad essere accessibili a pochi, richiedevano spesso tempi di caricamento lunghi o l’installazione di plug-in sulla macchina dell’utente. Le recenti applicazioni di webmapping, invece, beneficiano di uno spiccato livello di interattività e reattività, caratteristiche tipiche delle applicazioni Web 2.0 che sfruttano tecnologie come AJAX e si integrano alla perfezione nell’ecosistema del web moderno, composto da social network, feed RSS e servizi di varia natura.

Standard è bello… e pratico

Una ulteriore spinta alla diffusione di questa nuova generazione di applicazioni di webmapping è venuta dall’affermarsi di standard aperti, documentati e condivisi messi a punto dall’Open Geospatial Consortium (OGC).
Le maggiori case produttrici di software GIS, nonché le comunità open source con i loro innumerevoli progetti, hanno implementato nei loro prodotti il supporto ai principali standard OGC (WMS, WFS, WCS, ecc.) favorendo l’interoperabilità. Chi progetta e sviluppa applicazioni di webmapping oggi ha la possibilità di mescolare risorse disponibili in rete e risorse locali, di utilizzare tecnologie e piattaforme differenti in grado, però, di scambiare informazioni grazie al rispetto degli standard e di ottenere così degli efficacissimi mash-up tramite i quali diffondere l’informazione spaziale.

Lato server

A prescindere dai dati, preferibilmente mantenuti in un RDBMS spaziale (come PostGIS o Oracle Spatial), salvo situazioni particolari un’applicazione di webmapping ha generalmente bisogno di due componenti che operano sul server: il web server e il map server.
Il web server, come Apache, solo per citare il più diffuso e più famoso, è l’ambiente che renderà possibile la pubblicazione del lavoro e accoglierà le richieste provenienti dall’applicazione client (quella con cui l’utente interagisce) per passarle al map server. Quest’ultimo, per dirla in maniera molto sintetica, interpreta tali richieste e produce di conseguenza degli output (le mappe) che vengono spedite al client di nuovo attraverso il web server. Ovviamente questo è uno schema generale ed anche se formalmente corretto (ricalca il funzionamento di UMN-MapServer, che è uno dei map server più validi e versatili), occorre tenere presente che ogni software appartenente a questa categoria ha le proprie modalità specifiche di azione. Geoserver ed ArcGIS Server sono altri due ottimi esempi, il primo è gratuito ed open source, come lo è anche UMN-MapServer, mentre l’altro è un prodotto proprietario distribuito da ESRI.
Prima di chiudere la breve panoramica sugli strumenti lato server, è bene ricordare che nel caso delle applicazioni di webmapping più avanzate è necessario avere a disposizione anche un linguaggio di programmazione (Java, PHP, Python, ecc.) per organizzare la logica di business, cioè l’insieme degli algoritmi che gestiscono lo scambio di informazioni tra il client e la banca dati. UMN-Mapserver, ad esempio, è completo di API (Application Programming Interface) per i principali linguaggi di programmazione, mentre ArcGIS Server propone due ADF (Advanced Development Framework) per Java e .Net.

Lato client

Il client, come anticipato nel precedente paragrafo, è quella parte dell’applicazione con cui l’utente finale interagisce. Questo “strato” ha, perciò, un ruolo fondamentale nel decretare il successo o insuccesso dell’intera applicazione. Senza un client efficace che metta in risalto gli strumenti più importanti offerti all’utente e lo prenda quanto più possibile per mano nel compiere le operazioni che lo porteranno ad ottenere la risposta desiderata (un’estrazione di dati tramite interrogazione, l’analisi di una determinata variabile ambientale, ecc.), si rischia seriamente di vanificare gli sforzi profusi nella progettazione e implementazione del database e degli algoritmi lato server.
E’ ovvio che, pur progettando un client ideale, non è sempre possibile raggiungere la massima facilità di utilizzo, poiché tutto è influenzato dal numero delle funzionalità offerte, dalla loro complessità, dal tipo di utenti a cui ci si rivolge e da diversi altri fattori. Tuttavia un’interfaccia utente intuitiva è il risultato a cui si dovrebbe tendere quando si inizia a progettarla.

Come si realizza il client? Le soluzioni sono tantissime, dai template html di UMN-Mapserver, ai framework in PHP come p.Mapper (sempre per UMN-Mapserver) che mettono a disposizione un client con dei moduli dinamici lato server (PHP MapScript), a librerie Javascript come OpenLayers, di cui si è spesso parlato qui su TANTO.
Personalmente preferisco l’ultima soluzione in quanto costruire il proprio client da zero usando una libreria Javascript (OpenLayers non è l’unica), sebbene possa essere inizialmente più laborioso rispetto alla configurazione di un framework come p.Mapper, presenta degli indubbi vantaggi.
Sorvolando sulla valenza didattica del costruire una ad una le funzioni attivate dai vari tasti di una toolbar, ci si rende conto della bontà della scelta quando quello che offre un framework out of the box non basta più e si deve procedere ad un lavoro di personalizzazione/integrazione. Spesso modificare il comportamento di un software complesso, legato ad una specifica piattaforma (UMN-MapServer e PHP MapScript, nel caso di p.Mapper), che comprende numerosi script interconnessi tra loro richiede uno sforzo ben superiore a quello necessario per scrivere da zero una nuova funzione che faccia uso di una classe della libreria OpenLayers (oppure delle API di Google Maps o ArcGIS Server).
Un altro vantaggio – sempre nel caso in cui si scelga di lavorare con Javascript – è che si semplifica di molto l’integrazione nell’interfaccia di librerie per la costruzione di Rich Internet Application (RIA), come jQuery, Dojo, Mootools, YUI o ExtJS, ottime per la creazione di tutti quei piccoli espedienti che rendono il client efficace (nell’accezione usata in precedenza). C’è davvero l’imbarazzo della scelta.

Considerazioni conclusive

Come dicevo in apertura, ci si può discostare anche di molto da quasi tutti gli strumenti elencati e da questo approccio senza per questo sbagliare. Tuttavia nelle prime fasi è utile individuare e chiarire dei concetti specifici, imparare a padroneggiare gli strumenti per muoversi con disinvoltura e poi, in seguito, avventurarsi e testare soluzioni alternative e sempre più originali. In ogni caso alcuni punti, come la creazione di un client intuitivo o il rispetto degli standard, hanno una valenza generale e andrebbero sempre tenuti in debita considerazione a prescindere dalle scelte che si opereranno. Non mi resta che augurare buon divertimento a tutti.

L'articolo Parliamo di webmapping è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

La proiezione di Google Maps

Effetto di distorsione delle aree

Google Maps, Bing Maps ed altri provider (come OpenStreetMap, Yahoo e, di recente, la stessa ESRI) utilizzano una proiezione nota come Spherical Mercator, derivata dalla proiezione di Mercatore. Il codice EPSG ufficiale è 3785, anche se prima della sua definizione molti software hanno utilizzato l’ufficioso 900913. L’identificativo per i software ESRI, tra cui ovviamente ArcGIS Server, è invece 102113.
Questa proiezione considera la Terra come una sfera e consente di includerne completamente la superficie all’interno di un quadrato.
Quando però si rappresenta una superficie curva su di un piano, come un foglio di carta o il monitor di un computer, si introducono delle deformazioni. In questo caso, man mano che ci si allontana dall’equatore le aree cartografate subiscono un pesante stiramento sia in senso verticale che orizzontale e diventano, quindi, via via più esagerate verso i poli (la Groenlandia, per esempio, sembra più grande dell’Africa). Questa proiezione evidentemente non è fatta per minimizzare la deformazione delle aree (la proiezione di Mercatore è conforme infatti), ma risulta vantaggiosa per l’uso attraverso il web perché consente di applicare un modello efficiente di tassellamento e caching.

Il problema…

Ammettiamo di voler creare un’applicazione di webmapping con le sopracitate estensioni delle API Javascript di ArcGIS Server per Google Maps.
La prima cosa da fare è creare un mapservice in grado di esporre i nostri dati spaziali con la medesima proiezione delle basi cartografiche di Google. Come spiegato nel post dedicato ad ArcGIS Server (linkato all’inizio di questo articolo) un mapservice “aggancia” e pubblica un progetto redatto in ArcMap (il classico .mxd), quindi basta assegnare al dataframe del progetto il sistema di riferimento appropriato (che si trova nella lista dei sistemi proiettati, alla voce WGS 84 Web Mercator, con identificativo 102113), salvare il tutto e pubblicarlo con ArcGIS Server. Niente di difficile insomma.
Focalizziamoci ora sullo sviluppo del client: tra i tanti strumenti che oggi ci si aspetta di trovare in una applicazione WebGIS ci sono i “righelli” che consentono di disegnare spezzate e poligoni e di misurarne poi lunghezza ed area. ESRI lo sa, ed ha giustamente incluso un esempio per mostrare come creare questi tool nella documentazione delle sue API.
Abbiamo detto però che l’uso della proiezione Spherical Mercator provoca una deformazione crescente man mano che ci si spinge verso i poli e, tracciando una spezzata per misurare un oggetto al suolo di dimensioni note, come uno stadio di calcio, ci si accorge dell’inghippo: è più lungo di quanto dovrebbe essere (circa 146 metri invece di 105-110).
L’esempio fornito da ESRI non considera la deformazione e può indurre gli sviluppatori all’errore. E’ vero che una persona con le adeguate conoscenze di geomatica può arrivare ad intuire il rischio insito nell’uso della proiezione di Google, ma è anche vero che il webmapping è terra di confine tra “gissologi” e sviluppatori informatici “puri”, senza particolari cognizioni tipiche del mondo gis. Non è per nulla detto, quindi, che chi sviluppa abbia i mezzi per immaginare il problema prima di averci sbattuto il muso e personalmente credo che aver pubblicato un esempio del genere nella documentazione ufficiale, senza neanche accennare alla questione della deformazione, sia stata una leggerezza.

…e la soluzione

Non molto tempo fa sul blog di ArcGIS Server è comparso un interessante post che mette in evidenza il problema della misurazione delle distanze e spiega come comportarsi per risolverlo.
Il servizio che in ArcGIS Server è incaricato di calcolare lunghezze ed aree, il Geometry Service, è in grado di svolgere diverse altre operazioni, tra cui la proiezione al volo delle geometrie.
Il “trucco” consiste nel riproiettare la geometria tracciata dall’utente nel sistema di riferimento più adatto alla zona mappata prima di effettuarne la misurazione e stampare a schermo il risultato.
Purtroppo lo snippet di codice fornito da ESRI è pronto all’uso solo per le API Javascript, mentre per le estensioni di Google Maps bisogna fare da soli e il discorso è un po’ meno semplice.
Al posto di questa funzione:

var sr = new esri.SpatialReference({wkid:32610});
geometryService.project([graphic], sr, function(projectedGraphic) {
geometryService.areasAndLengths(projectedGraphic, function(result) {
var perimeter = result.lengths[0];
var area = result.areas[0];
});
});

abbiamo bisogno di questa:

var geometryService = new esri.arcgis.gmaps.Geometry("http://sampleserver1.arcgisonline.com/ArcGIS/rest/services/Geometry/GeometryServer");
function calculateLengths() {
//Parametri per la riproiezione
var params = new esri.arcgis.gmaps.ProjectParameters();
params.geometries = [polyline];
params.inSpatialReference  = 4326;
params.outSpatialReference = 3004; //Gauss-Boaga fuso Est
//Riproiezione e funzione di callback
geometryService.project(params, getLengths);
}
function getLengths(projectResults){
var url = "http://sampleserver1.arcgisonline.com/ArcGIS/rest/services/Geometry/GeometryServer/lengths";
var parameters = {
polylines: projectResults.geometries,
sr: 3004
};
esri.arcgis.gmaps.JSONRequest(url, test, parameters);
}
function test(result) {
alert(result.lengths[0]+" m");
}

Ho realizzato un veloce esempio che mostra i risultati ottenuti dal codice proposto da ESRI nella propria documentazione a confronto con quelli ottenuti dalla riproiezione con il Geometry Service e dalle semplici API di Google Maps, che hanno dei metodi propri per la misura di linee e poligoni.

L'articolo ArcGIS Server e Google Maps: come misurare correttamente le distanze è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Per chi non lo sapesse, jQuery è un framework Javascript open source molto potente, caratterizzato da una sintassi snella e di facile comprensione.
Il framework è rilasciato con doppia licenza: MIT e GPL.
I motivi per usare jQuery nei propri progetti non mancano di certo: comunità attiva, disponibilità di molti temi e ottimi plugin, compatibilità e leggerezza sono i primi che mi vengono in mente.

In questo articolo vedremo come costruire una mappa online sfruttando jQuery UI e OpenLayers.
Il risultato della “fusione” è un client dotato di funzionalità di base come zoom, pan, misurazione delle distanze e vari layer di sfondo intercambiabili.
Si tratta, in pratica, di un template da cui partire per sviluppare applicazioni di web-mapping vere e proprie.

Per creare il client dell’esempio abbiamo bisogno di:

• OpenLayers
• jQuery UI, pensato per creare widget personalizzati con jQuery
• jQuery UI.Layout, un plugin ispirato al border layout di ExtJs
• qTip, un plugin per modellare dei tooltip avanzati

Ho già raccolto il tutto in questo archivio .zip. Qui dentro, oltre alle librerie, si trova la totalità dei file che compongono il client. Vi basta quindi cliccare sul link per avere il template sul vostro computer, pronto all’uso e/o ad essere trasformato come volete.
Vi invito però a dare lo stesso un’occhiata alla pagina di download di jQuery UI: noterete che è possibile modificare radicalmente il pacchetto prima di scaricarlo. Potete includere le sole componenti utili ai vostri scopi e scegliere tra vari temi già pronti o uno composto da voi con ThemeRoller.
Io ho fatto solo qualche semplice modifica al tema UI-Darkness (in questo periodo non mi piacciono i bordi arrotondati…) ma, come dicevo, si può fare molto di più. Provare per credere.

Ora un po’ di anatomia.
Scompattato l’esempio, è bene posare lo sguardo su alcune delle directory e dei file compresi al suo interno.

jsLib

E’ la directory contenente tutte le librerie elencate in precedenza, necessarie al funzionamento del template.

index.html

Nella sezione header sono referenziate le librerie utilizzate, i fogli di stile e i file javascript.
Nel body è possibile notare che l’attributo class di molti degli elementi della pagina (div, button, span, ecc.) è parecchio popolato. Questo è il metodo con cui jQuery UI e jQueryUI.Layout si “ancorano” alla pagina web.
Per comprendere meglio vi rimando alla pagina degli esempi di jQuery UI.Layout e a questo articolo che spiega in maniera egregia la composizione della toolbar e dei suoi pulsanti.

jsFunc/mappa.js

Contiene la mappa realizzata con OpenLayers.
Nella funzione di inizializzazione (initMap) richiamata al caricamento della pagina, ci sono, tra le altre cose, i controlli collegati ai bottoni della toolbar.

jsFunc/layout.js

In questo script, con poco più di 40 righe di codice, jQuery UI e i suoi plugin definiscono Il layout dell’applicazione, il tema, il comportamento e l’aspetto di bottoni e tooltip.

Css/style.css

A parte qualche piccola “frivolezza” come queste (a mio giudizio) bellissime icone, in questo foglio di stile sono descritte le regole fondamentali per la corretta presentazione del layout e della toolbar creati tramite jQuery UI.

Ecco, questo è grossomodo ciò che bisogna sapere per iniziare a studiare i mille modi di mescolare le potenzialità di jQuery a quelle di OpenLayers.
Fondamentale, come sempre, è il ricorso alla documentazione ufficiale dei vari progetti e al supporto offerto dalla comunità.
Per chiudere segnalo anche due guide in italiano, estremamente ben fatte ed utilissime per avvicinarsi a jQuery e jQuery UI. Entrambe sono firmate HTML.it:
Guida a jQuery
Guida a jQuery UI

L'articolo jQuery e OpenLayers: agitare prima dell’uso… è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Grazie agli esempi, che coprono quasi tutto lo spettro delle possibilità, è stato facile produrre la parte client del mio lavoro.
L’editor ottenuto è adattabile a qualsiasi back-end “spatial enabled”, è indipendente dal mapserver scelto per pubblicare i dataset online, dal geodbms usato per contenerli e dal linguaggio di programmazione lato server.
Il cuore del client è costituito dalle funzioni presentate in questo esempio, che consentono di disegnare una feature da serializzare sotto forma di stringa in ben 6 formati standard differenti. Ottenuta la stringa, il gioco è fatto: uno script lato server si occupa di recuperarla e lanciare una query di inserimento nel geodabase (ci sono, come sempre, anche altre soluzioni).
L’operazione inversa, vale a dire deserializzare una stringa ed ottenere una feature, è ugualmente possibile e può essere molto utile.
Per esempio, volendo rifinire degli shapefile su una base Google Maps o Openstreetmap, basta trasformarli KML (o in uno degli altri 5 formati supportati), aprire il file con un editor di testo e, infine, copiare ed incollare il contenuto dentro la textarea del nostro editor. A questo punto si è liberi di modificare a piacimento le feature importate.
Questo è solo un esempio grezzo di import, dispobile “out of the box”, ma una volta collegato l’editor ad un back-end spaziale si può dare sfogo alla fantasia e creare delle funzioni di importazione più raffinate.

Cliccando qui potete vedere una versione super-generica del client di editing da me realizzato. Ho usato MapFish 1.1^[1] per dare un aspetto un po’ più carino^[2] al tutto ed ho modificato il codice degli esempi affinché le diverse funzioni di editing potessero essere attivate da una toolbar invece che da una serie di checkbox e radiobutton. I commenti nel codice dovrebbero essere abbastanza esplicativi.

^[1] Si tratta di una versione leggermente modificata in cui ho sostituito OpenLayers 2.7 con OpenLayers 2.8

^[2] Qualcuno potrebbe cimentarsi con Dojo o jQuery… sono sicuro che non verrebbe affatto male

Nota
Devo scusarmi con i lettori di TANTO iscritti al feed RSS.
Stamattina ho accidentalmente cliccato sul bottone “Pubblica” mentre scrivevo la bozza e nonostante mi sia precipitato a recuperare, non sono riuscito ad evitare che l’articolo incompleto finisse nel feed. Per farmi perdonare mi sono incollato al computer ed ho fatto il possibile per finire l’articolo e la demo alla svelta! In futuro starò più attento a dove clicco e soprattutto non inizierò a scrivere bozze di domenica mattina prima di colazione!

L'articolo Editing vettoriale con OpenLayers è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

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!

L'articolo ArcGIS Server 9.3: impressioni di utilizzo è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

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

L'articolo Condividere geodati sul web tramite Google Earth e Google Maps è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

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.

L'articolo Introduzione a MapFish: OpenLayer e ExtJs “a braccetto” è apparso originariamente su TANTO. Rispettane le condizioni di licenza.