Questo articolo nasce dall’idea di aprire una finestra su quella branca della geomatica che si occupa della condivisione e diffusione in rete dell’informazione geografica, comunemente indicata col termine webmapping e spesso protagonista su questo blog.
Prima di entrare nel vivo del discorso, però, vorrei precisare che quello proposto è il mio personale punto di vista, costruito nel tempo in base alla mia esperienza professionale in questo campo. Esistono altri strumenti e approcci diversi rispetto a quello che vedremo nel corso dell’articolo, quindi, come sempre, ogni commento sarà ben accetto e spunto di ulteriore riflessione.

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.

E’ ormai da qualche mese che ESRI, con ArcGIS.com è ufficialmente con la testa tra le nuvole. Giovanni Allegri ha già dato notizia di GISCloud in un precedente articolo, in effetti il primo servizio applicativo di GIS “evoluto” e abbastanza maturo totalmente utilizzabile via web.

I tempi, la tecnologia e il mercato per parlare di GIS in the cloud – come aveva teorizzato Vector One due anni fa – sono dunque ormai maturi, e la scelta di ESRI di lanciare la sua applicazione webGIS quasi assieme alla prossima release di ArcGIS 10 è quindi “dovuta”. Tanto più che la stessa ESRI ha stretto una partnership con Amazon Web Servicesgrazie alla quale è possibile “affittare” ArcGIS Server sulla piattaforma di cloud computing di Amazon.

A mio avviso però, ArcGIS.com va in totale controtendenza con le strategie alla base di progetti come appunto GISCloud o anche CloudMade e GeoCommons e in genere quelli basati su svariate soluzioni tecnologiche, volte a garantire l’interoperabilità tra i dati seguendo le specifiche dell’Open Geospatial Consortium.

Un GIS “in the cloud” dovrebbe essere “aperto” per definizione, almeno per quanto riguarda la possibilità per l’utente di utilizzare dati e servizi di mappa via web provenienti da svariate fonti. Certo, può non esserlo per la parte applicativa, come proprio GISCloud, mentre invece CloudMade offre risorse di sviluppo, e ancora GeoCommons offre servizi business ad-hoc. Bene, ArcGIS.com non lo è nè dal punto di vista dei dati utilizzabili, nè tanto meno applicativo (avevamo dubbi?), anzi è “ESRIcentrico” in una maniera oserei dire “ottusa”. Gli unici contenuti che è possibile caricare nel proprio account non sono, tanto per dire, nemmeno shapefile (sic!) ma formati proprietari ESRI come ad esempio Map Package e Layer Package, mentre tra i servizi di mappa via web si possono importare solo quelli erogati mediante ArcGIS Server… e non certo con formati OGC (WMS, WFS, ecc)!

Qui sotto potete “ammirare” una mappa che ho realizzato utilizzando esclusivamente dati erogati dalla Provincia di Trapani e dalla Regione Siciliana, ovviamente mediante ArcGIS Server. In realtà i dati della Provincia sono esposti in maniera un pò confusa, e lo si può notare consultando i singoli servizi nella relativa pagina di ArcGIS Server. In sostanza sono stati messi troppi layer assieme, spesso ripetendoli da servizio a servizio. Quelli della Regione invece sono organizzati con un singolo layer per ogni singolo servizio, e dunque meglio utilizzabili in ArcGIS.com. In realtà mettere più layer insieme in un solo servizio non è affatto sbagliato, anzi, a patto che lo si faccia seguendo il criterio di realizzare una “vista” o mappa, ovvero rendendo gli strati visivamente compatibili (trasparenze, ordine di sovrapposizione, ecc).

Visualizza mappa più grande

La mappa, incorporabile in pagine web mediante <iframe>, risulta estremamente scarna, con la possibilità di impostare solo la dimensione e metterci o meno un tool di zoom. L’obiettivo è quello di indurre l’utente a visualizzarla direttamente su ArcGIS.com cliccando sul link “Visualizza una mappa più grande”. E magari fargli aprire un account…

Insomma, il cloud GIS secondo ESRI è chiuso, sia dal punto di vista applicativo (e questo ci può pure stare) sia dell’interoperabilità con i dati. E di questo francamente non ne vedo proprio la necessità, visto che la sua posizione dominante – almeno nei segmenti business e pubblico – è sempre molto salda, e non sarebbe di certo stata intaccata dando la possibilità di utilizzare dati vettoriali come shapefile (non dico PostGIS) e importare servizi di mappa via web con standard OGC.

L'articolo ArcGIS.com il cloud GIS secondo ESRI è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Il sistema GIS Cloud (beta) comincia a far parlare di sé.

GIS Cloud – General from GIS Cloud on Vimeo.

Si tratta di un sistema di cloud computing dedicato a servizi webgis che, in linea col concetto di “software as a service” , permette di sfruttare risorse hardware a software distribuite per realizzare servizi GIS online.
Tra le numerose funzionalità, offre la possibilità di creare progetti online, di caricare, gestire, editare, esportare, ecc. dati raster e vector di tutti i principali formati noti. Oltre a diverse librerie proprietarie, GIS Cloud si appoggia anche a GDAL e OGR, a garanzia di un’alta interoperabilità.

I layer, una volta caricati e impostati,  possono essere pubblicati sia tramite il loro flash viewer, che coe servizi WMS/WFS, nonché di fungere da client di servizi OGC, offrendo così la possibilità di realizzare anche mashup e servizi a cascata. Non poteva mancare il supporto ai servizi Openstreetmap, Google Maps, e simili.

Sono presenti inoltre alcuni semplici strumenti di analisi GIS e statistica, come esempio delle ulteriori funzioni che saranno rese disponibili in futuro…

Insomma, un oggetto da tenere d’occhio. In attesa di ricevere il vostro Free Account (che offre tutte le funzionalità ma in un ambiente non dedicato, con risorse condivise tra tutti gli utenti gratuiti e quindi non garantite) vi invito a fare un giro tra i video della loro sua gallery.

L'articolo GIS Cloud – il cloud computing per il webgis è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Tempo fa scrissi un articolo su ArcGIS Server 9.3 soffermandomi sui servizi REST e le API Javascript ed accennando al fatto che ESRI mette a disposizione delle estensioni per le API di Google Maps e per quelle di Bing Maps.
Ultimamente ho lavorato un po’ con le prime e ne ho avuto complessivamente una buona impressione. Tuttavia, durante lo sviluppo, ho riscontrato un problema nella misurazione delle distanze e delle aree che merita di essere messo in evidenza, soprattutto perché gli esempi della documentazione ESRI non lo fanno a dovere ed anzi, secondo me, risultano leggermente fuorvianti.
Terminata la premessa, prima di andare avanti con l’articolo, voglio ringraziare Domenico Ciavarella, che mi ha dato un supporto fondamentale per arrivare ad una soluzione che altrimenti starei ancora cercando.

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.

Come atteso, le novità dell’ultima versione di Openlayers sono numerose e, molte, di largo interesse. L’elenco completo delle funzionalità aggiunte, dei miglioramente e dei bug risolti è lunga, ma la sintesi riportata nell’annuncio su Osgeo-Announce è già indicativa del valore di questa release:

• Controllo Graticule, per la rappresentazione della griglia delle coordinate
• Supporto per il formato delle immagini prodotte con Zoomify, e su questo mi soffermerò dopo
• Gestione degli AtomFeed
• Formato di supporto per i servizi OGC CS-W (Catalog Service for the Web)
• Aggiunta una modalità (Strategy) che permette il refresh dei layer vettoriali, anche temporizzato
• Supporto di base al protocoloo SOS (Sensor Observation Service)
• Controllo TransformFeature: l’esempio è esplicativo
• Supporto alla versione 1.3 del protocollo WMS
• Risolti molti problemi della gestione della memoria (memory leaks)

Un’aggiunta, di interesse anche per chi non si occupa di webgis vero e proprio, è il supporto a Zoomify.
Zoomify è un software gratuituo (non Open Source) che permette una visualizzazione efficiente via web di immagini anche ad alta risoluzione, grazie al metodo della tassellatura (tiling). L’immagine originale viene ingrandita a diverse livelli di zoom, e ad ogni livello viene suddivisa in “mattonelle” di grandezza predefinita, che vengono disposte in una struttura gerarchica di cartelle. Per potere riottenere l’immagine originale, il client deve andarsi a pescare i diversi pezzi e ricomporre il mosaico.
Questo sistema non è certo una novità per il mondo GIS, che lo impiega già da molto tempo (vedi gdal2tiles, tilecache, geowebcache, ecc.), e Openlayers offriva già il supporto a servizi di webmapping basati sul tiling (come TMS). Tuttavia il supporto per Zoomify offre il vantaggio della semplicità di utilizzo di questo software, per il cui impiego non sono necessarie competenze GIS, e la possibilità di distribuire facilmente scansioni non georiferite di carte geografiche storiche.
Tra gli esempi distribuiti con la nuova release di Openlayers è stato replicato lo stesso esempio usato per mostrare il viewer Flash di Zoomify in azione. Eccoli a confronto:

Openlayers viewer per Zoomify

Zoomify Flash Viewer

Buon divertimento!!!

L'articolo Zoomify e le novità di Openlayers 2.9 è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Era da un po’ che avevo in mente di dedicare un articolo a jQuery, finalmente – complici l’influenza che mi ha tenuto a riposo forzato e l’ispirazione tratta da Linfiniti – sono riuscito nell’intento.

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.

Ho ricevuto questo contributo da Claudio Schifani e Giulio Di Chiara, e lo pubblico molto volentieri perché parla di temi a me molto vicini; sia in coordinate, che “con il cuore e con la mente” 
Claudio ha “conosciuto” questo blog tempo fa per le imprevedibili vie del web, e ci siamo incontrati al GISDay (che ho contribuito ad organizzare) nel Novembre del 2009. E’ stato un incontro emozionante in cui mi ha fatto i complimenti per la giornata e per questo blog di cui mi prendo cura insieme ad Alessio, Antonio, Gerlando, Pietro e Sergio (presto delle new entry). Mi ha raccontato che per realizzare GeoMAPpalermo (il progetto di cui si parla in questo post) gli è stato utile leggere gli articoli di TANTO; queste cose sono tra quelle che mi danno più piacere e soddisfazione, e che conservo come “armi emotive segrete” da usare nei momenti di difficoltà.
Giulio l’ho conosciuto tramite Claudio. E’ uno dei creatori di Mobilita Palermo, “un comitato di sostegno verso quelle opere e progetti che possano incentivare lo sviluppo del capoluogo siciliano, con particolare attenzione al miglioramento della viabilità e della mobilità cittadina”. Anche con lui siamo prima “incontrati” digitalmente e poi per fortuna analogicamente. Con Giulio e Claudio ci siamo infatti riuniti attorno ad un tavolo, per cercare di fare insieme qualcosa per la nostra città, a partire dalle nostre professionalità. Abbiamo iniziato a discuterne e Giulio, oltre ad essere un cittadino che si spende per il bene della propria città, è energia pura  .

Mi fermo qui e vi auguro una piacevole lettura.

Il 27 ottobre scorso,
“Mobilita Palermo” (http://www.mobilitapalermo.org), riconosciuto portale-blog su progetti, infrastrutture e mobilità nel capoluogo siciliano, in collaborazione con Claudio Schifani (Assegnista di ricerca presso lo IUAV di Venezia), ha pubblicato on line un nuovo servizio per la cittadinanza palermitana che desidera interagire e “dire la sua” in tema di mobilità urbana.

Presentazione

Mobilita Palermo è un comitato cittadino che nasce ufficialmente dalla rete, una collaborazione prima virtuale e in seguito tangibile tra persone che nutrono un profondo rispetto per la propria città, con un forte senso civico e voglia di cambiamento. Uno scopo importante del comitato è quello di monitorare l’avanzamento dei cantieri e “sollecitare” il rispetto delle tempistiche, segnalando un’eventuale cattiva gestione dei lavori o del denaro pubblico stanziato per gli stessi. Basando la sua mission sulla forza della community e sul “potere comunicativo” della rete, ha individuato Word Press come la soluzione 2.0 per aprirsi alla condivisione delle informazioni, collaborazione ed integrazione di tutti i cittadini interessati.

Claudio Schifani ha svolto una ricerca per l’Università IUAV di Venezia sul tema “Modelli di conoscenza e processi decisionali” presso la scuola di dottorato nel corso in Nuove Tecnologie Informazione Territoriale & Ambiente (http://www.didatticaericercasit.it). La ricerca si è inquadrata nello scenario ormai noto come “Web 2.0” in cui l’informazione geografica assume sempre più carattere di pervasività e di condivisione delle conoscenze, sia esse esperte che locali. Informazione geografica e web rappresentano le componenti del recente scenario caratterizzato dalla sinergia di tre parole chiave, ovvero: territorio/conoscenza/web. Tra i casi di studio analizzati nel corso dell’indagine c’è il progetto ideato e sviluppato dall’Agenzia Europea dell’Ambiente e noto con il nome di “EyeOnEarth”. “Occhio sulla terra” evoca un’azione che è al contempo conoscitiva e collaborativa grazie all’obiettivo dichiarato d’integrazione delle conoscenze “esperte e scientifiche” (dati rilevati dalla EEA) e informazioni rilevate “dal basso”, ovvero dalla comunità che vive o conosce quei luoghi, il tutto aggregato con modalità di rating in interfaccia friendly. Ciò costituisce un’interessante rivoluzione culturale e metodologica che ci apre nuove strade per studiare ed approfondire lo sviluppo di quadri di conoscenza del territorio che siano non soltanto condivisi (Web), ma anche integrati (a livello di conoscenze).

Perché GeoMAPpalermo

L’iniziativa è nata e sviluppata totalmente dal basso (Comitato di Cittadini e non un Ente Istituzionale) e pone tra gli obiettivi quello di “testare” la sensibilità della comunità locale nel valutare gli interventi attuati o in programma, in tema di mobilità, da parte dell’Amministrazione Comunale.

Ecco cosa si legge nel Blog di Mobilita Palermo a proposito dello strumento “GeoMapPalermo”:

«Voi sarete la voce di Palermo, voi farete parlare la città. Dai vostri interventi sulla mappa, traspariranno le priorità, gli aspetti positivi e quelli negativi di Palermo. Il vostro intervento si traduce in una georeferenziazione, ovvero in un’etichetta localizzata all’interno di un areale di progetto presente sulla mappa, attraverso la quale potrete esprimere il vostro parere e fornire una breve motivazione, allargando così la conoscenza globale all’interno del “tessuto urbano”.»

Come

GeoMapPalermo è un servizio 2.0 in cui “l’immagine” del territorio ne costituisce il minimo comun denominatore attraverso cui veicolare una duplice informazione: da un lato i progetti urbani (restituiti come areali corredati da link, che puntano a informazioni dettagliate opportunamente aggiornate nel blog ), dall’altro i cittadini che esprimono una valutazione (da molto positiva a negativa). Ecco cosa si legge nel Blog di Mobilita Palermo a proposito dello strumento “GeoMapPalermo”:

GeoMapPalermo è un Mashup di Google Maps le cui mappe sono state scelte sia perché costituiscono un “linguaggio geografico” noto anche a soggetti non esperti sia perché TANTO è stato un eccellente “supporto didattico” con i suoi interessantissimi tutorial di implementazione di codice javascript con le mappe di Google. La piattaforma si basa sull’interazione tra un codice javascript per la consultazione ed inserimento di GeoTag e due script PHP per la connessione ad un DB in MySQL. Ciò che ha richiesto maggiore attenzione nello sviluppo dell’applicativo è stata la definizione della struttura dell’unica tabella presente nel DB che avrebbe raccolto le informazioni provenienti dalla comunità, al fine di rispettare lo schema logico delle connessioni tra i temi, i progetti, i soggetti e le valutazioni. La compilazione della scheda allegata a ciascun tag è, pertanto, guidata attraverso l’inserimento di valori preformattati che consentono la restituzione tematica delle informazioni in mappa.

Inoltre, è stato posto un importante “vincolo” (non a livello di codice ma di vidimazione del geotag da parte degli amministratori di Mobilita Palermo) di appartenenza ad un areale di progetto sul tema “Mobilità” ed in particolare: Tram, Parcheggi e Passante ferroviario.

Con questo strumento, Mobilita Palermo ha inteso perseguire gli obiettivi che si era posta per l’implementazione nel suo blog del nuovo servizio geografico 2.0: sensibilizzare l’opinione pubblica alla emergente cultura del territorio 2.0 – “territorio parlante” ed esprimere la volontà di testare un sistema di valutazione partecipata “bottom-up” sulle azioni di trasformazione della città. È interessante notare come nel primo mese di vita, la GeoMapPalermo abbia ricevuto oltre 40 geotag (alcuni dei quali sono stati rimossi perché non rispettavano il “vincolo” necessario alla loro accettazione) ed abbia incoraggiato il Comitato “Mobilita Palermo” ad interessarsi nel porre alcuni quesiti a Enti gestori e decisionali (in materia di mobilità) riguardo ad alcune segnalazioni emerse in mappa su questioni relative al progetto Tram ed alla gestione dei nuovi parcheggi urbani.

Un modo innovativo di affrontare tematiche a scala urbana e stimolare l’interesse collettivo sfruttando i moderni strumenti che internet mette a disposizione.

L'articolo GeoMAPpalermo | esprimi il tuo parere sulle azioni di trasformazione urbane è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Google Street View è presente da diverso tempo in Italia, ma oggi ho scoperto che la copertura è decisamente aumentata, specie per due aspetti:

• la copertura nel meridione d’Italia (finalmente anche nella mia Palermo)
• la copertura in zone non soltanto cittadine

Il secondo punto è quello che mi sembra più interessante, in quanto sarà possibile vedere luoghi meravigliosi lungo strade abbandonate da Dio e dagli uomini. Io ho provato ad andare a spiare il Tempio di Segesta, ma lo scatto non è un granché.

Qui sotto, in azzurro, la copertura ad oggi. Vado a farmi una passeggiata in campagna 

L'articolo Google Street View sbarca con forza in Italia è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Introduzione

A Febbraio del 2006 – tantissimo tempo fa … – ho scritto un piccolo post sull’installazione di MapServer in ambiente Windows su un sistema in cui fosse già installato un webserver (Apache in particolare).

E’ stato un post che ha ricevuto molte letture, ma che ha anche subito qualche “legnata tecnologica”. Lo avevo scritto infatti non dentro il motore di questo blog (WordPress), ma dentro Writely.
Cosa è Writely? E’ nientepopodimeno che l’applicazione online su cui è basato l’editor di testo di Google Docs, comprata per l’appunto da Google proprio in quell’anno.
Ho scritto l’articolo, ho inserito anche delle immagini d’aiuto alla comprensione del testo, ed ho pubblicato tutto su questo blog con un click; il testo è stato contestualmente archiviato sui server di TANTO, mentre le immagini sono rimaste sui server di Writely. Questi non sono stati spenti subito e, per diverso tempo, questo vecchio glorioso articolo non ha subito alcuna conseguenza dal passaggio di Writely a Google. Spenti i server, sono sparite le immagini ed in qualche modo anche la leggibilità del post in oggetto. Ho provato a ripescarle dall’Internet Archive Wayback Machine, ma senza fortuna.

In ogni caso dovevo rimediare da tempo. Avevo rimosso dalla memoria il problema (sorry ), e un commento recente mi ha messo nuovamente davanti alla cruda realtà (grazie riccardo). L’articolo inoltre è datato anche nei contenuti, e valeva la pena dargli una rinfrescata.

MapServer su Windows

Installare MapServer è cosa semplice in qualsiasi ambiente (forse il massimo è su Linux); può sembrare meno semplice farlo su server in produzione con diversi servizi già installati e configurati, specie se vogliamo usare degli installer grafici e magari chiudere gli occhi.

I file binari per Windows sono contenuti in questi tre pacchetti:

• OSGeo4W
• MS4W
• FWTools

In questa guida sfrutteremo FWTools, di cui abbiamo parlato diverse volte.

Installazione passo passo di MapServer

Il prerequisito è quello di installare e scaricare FWTools per Windows dal sito ufficiale, e poi lanciarne l’installazione. Io di solito lo faccio scegliendo le opzioni visibili in figura.

I file vengono estratti di default nella cartella “C:\Programmi\FWToolsx.x.x“. L’eseguibile di MapServer – mapserv.exe – è uno dei file a corredo di FWTools e lo troverete nella cartella “C:\Programmi\FWToolsx.x..x\bin“.
Copiatelo nella cartella CGI di Apache (o in una qualsiasi cartella in cui il web server può lanciare applicazioni di questo tipo). Sul PC da cui scrivo la cartella è “C:\Programmi\Apache Software Foundation\Apachex.x\cgi-bin”

Copiare l’eseguibile non basta perché ci sono diverse dipendenze da rispettare. Per soddisfarle basterebbe copiare tutti i file contenuti in “C:\Programmi\FWToolsx.x..x\bin” nella cartella CGI, ma non è una procedura “pulita”. E’ più corretto impostare delle variabili d’ambiente.

La prima è il PATH, in cui inseriremo proprio la cartella “C:\Programmi\FWToolsx.x..x\bin“. Per farlo basta aprire le “Proprietà del sistema” di Windows  e cliccare su “Variabili d’ambiente”.

Tra quelle già definite troverete proprio PATH. Modificatela inserendo nel campo “Valore variabile”, a fine riga, il percorso della cartella bin di FWTools: inserite prima un “;”.

C’è da impostare ancora una variabile d’ambiente in quanto MapServer deve “sapere” dove sono i file in cui sono definiti i sistemi di proiezione. La cartella in questo caso è “C:\Programmi\FWToolsx.x.x\proj_lib” e la variabile  è PROJ_LIB.

Questa (di solito) non è – come PATH – già esistente e la dovrete creare cliccando sul tasto “Nuovo” ed inserire i valori come nella figura sottostante.

A questo punto riavviate il PC, aprite il browser e lanciate un URL di questo tipo: http://vostrosito/cgi-bin/mapserv.exe

Se avrete come risposta la stringa “No query information to decode. QUERY_STRING is set, but empty.“, vorrà dire che tutto è andato a buon fine.

Non vi resta che creare delle belle applicazioni di web-mapping.

L'articolo Installare MapServer su Windows con Apache (riveduto e corretto) è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

E’ stata appena rilasciata la release 5.6 di MapServer. Come sempre tante le novità, ma una è quella che voglio mettere in evidenza qui: è stato definito uno schema XML con cui sarà possibile definire un mapfile anche in formato XML. I mapfile sono il cuore di questa applicazione: definiscono le relazioni tra gli oggetti, i percorsi in cui sono archiviati i layer e le regole per la loro rappresentazione grafica. La sintassi con cui si scrivono normalmente – qui un esempio di “vecchio” mapfile – non consente con facilità di creare degli editor dedicati.
Uno schema XML renderà molto più semplice la creazione di applicativi dedicati alla creazione, gestione e validazione di questo speciale formato di file.

Questa release ancora non lo legge e scrive nativamente; il file XSLT fornito con questa release consentirà però di convertire un file XML costruito con questo schema, in un “normale” mapfile di MapServer.

Qui sotto un esempio di mapfile “costruito” in XML. Mi sembra che anche la leggibilità ne abbia un giovamento.

Le altre tre novità più importanti sono le seguenti:

• MS RFC 52: One-pass query processing, making WFS queries on database backends much much faster
• MS RFC 55: Improve control of output resolution, allows printing maps at printer resolution using a mapfile defined for screen resolution
• MS RFC 57: Labeling enhancements: ability to repeat labels along a  line/multiline

Buon web-mapping!

L'articolo MapServer 5.6: i mapfile in XML è apparso originariamente su TANTO. Rispettane le condizioni di licenza.