Archivio del mese di aprile, 2010

29 aprile, 2010 | di

La Banca Mondiale , come molti sapranno, fornisce prestiti agevolati ai paesi in via di sviluppo per finanziare programmi volti alla riduzione della povertà. Come spesso accade, non è tutto oro quello che luccica, e infatti da molti anni è stata lanciata una campagna internazionale per la sua riforma.

Ma non è dei lati oscuri che ogni banca ha – e ai quali nemmeno la World Bank sfugge – che voglio parlare qui oggi, ma della decisione di liberare i dati che questa istituzione detiene, e che riguardano i Paesi di tutto il mondo. Le attività di ricerca e finanziarie che la Banca svolge, si basano infatti su dati di tipo demografico, produttivo e ambientale di assoluto valore, e la decisione di renderli disponibili è un grande passo verso l’idea di dati “grezzi, aperti e liberi”.

Come fa presente Andrew Turner in un suo recente post, la Banca Mondiale aveva da tempo rilasciato delle API per poter utilizzare la propria banca dati in applicazioni esterne (c’è perfino un’app per iPhone), ma poterli ora scaricare in formati aperti (CSV, XML) li rende davvero accessibili a chiunque, per qualunque scopo.

Il catalogo dei dati è consultabile direttamente sul sito della WB, per Paese (qui l’esempio relativo all’Italia) con la possibilità di visionare direttamente in una stessa pagina i trend dei classici indicatori finanziari (PIL, export, reddito pro-capite, ecc.), demografici (indice alfabetizzazione, disoccupazione, educazione), sanitari (mortalità) e ambientali (produzione CO2 pro-capite). Ogni singolo dataset è poi scaricabile, come detto, in formati aperti utilizzabili in qualunque applicazione e per qualunque scopo.

World Bank data

Dati grezzi, aperti e liberi… a livello mondiale!

25 aprile, 2010 | di

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


mercator

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.

24 aprile, 2010 | di

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

Openlayers viewer per Zoomify

Zoomify Flash Viewer

Zoomify Flash Viewer

Buon divertimento!!!

20 aprile, 2010 | di

fontem Un’esperienza, professionale ma soprattutto umana, nata quasi per caso. Un amico, che conosco da anni e che lavora per una ONG di Roma,  tramite giri nelle mailing-list di software gis open source, vede spuntare il mio nome, e così scopre che mi occupo di  “robe” geografiche. Ecco quindi che con una telefonata mi racconta che un gruppo di ONG, afferenti ad ActNow Alliance,  in collaborazione con ESA hanno attivato il progetto Digital Bridge, ovvero un ponte satellitare Italia-Camerun (fornito da ESA-ESRIN) tramite il quale realizzare una serie di attività di collaborazione e scambio tra i due paesi.

Il progetto prevede di indirizzare una parte delle attività anche al capacity-building nel settore delle tematiche territoriali. Nasce così l’idea di realizzare per gli studenti e i tecnici di Fontem (una città nella provincia camerunense  di Liebalem), un corso introduttivo alla cartografia, ai sistemi di Earth Observations, ai GPS, ai GIS… gulp! Non basterebbe nemmeno un anno per introdurre tutti questi argomenti, ma ci lanciamo nell’avventura, coscienti che gli obiettivi sono anzitutto due:  offrire a questi ragazzi gli elementi per cominciare a formarsi una prospettiva “dall’alto” del loro territorio, e fornire gli strumenti essenziali per orientarsi nel mondo della geomatica.

IMG_0682Per realizzare il progetto coinvolgo un amico e collega forestale, Pier Lorenzo Marasco, col quale iniziamo a studiare il territorio di Fontem e ci mettiamo sulle tracce di tutta la cartografia di dominio pubblico disponibile (quante serate passate tra siti camerunensi, russi, inglesi, ecc.!). All’interno del college di Fontem sappiamo che c’è un gruppo di studio che sta approfondendo le problematiche della deforestazione in Cameroon, e varie tematiche relative al  Climate Change, per cui abbiamo cercato di raccogliere cartografie tematiche sull’argomento, per dare al corso un taglio che fosse per loro interessante, e realmente utile.
Nel frattempo, assieme agli amici di Roma, compriamo alcuni GPS (alcuni Garmin Etrex e un GPS60) che inviamo a Fontem.

Raccolto quanto più materiale possibile e preparate le lezioni, finalmente arriva il giorno della prima connessione con Fontem.  Emozionante: migliaia di chilometri e un cambio di stagione, bruciati in un attimo. Tramite un software di teleconferenza fornitoci dalla stessa ESA,  nel nuovo laboratorio di informatica del college di Fontem  realizzato da AMU, possiamo incontrare i ragazzi di quella città che finora, per noi,  era poco più che una macchia di colore su Google Earth. Saluti, sguardi, sorrisi. Domande e risposte “intercontinentali”. E’ vero che il mezzo è pur sempre virtuale, che un contatto reale richiede molti altri sensi, ma ci sembra che la sincera voglia d’incontrarsi e di condividere conoscenze ed esperienze,  permettono comunque di vivere un’esperienza umana reale, e pienamente vera, che ha richiesto a noi e a loro un attegiamento di ascolto e di comprensione reciproca… perché anche se si parla di GPS, l’approccio è profondamento diverso!

E così, weekend dopo weekend, parliamo di geografia, di cartografia, di immagini aeree, di GPS… E tramite un blog interno ci scambiamo domande, opinioni,  e risorse varie. La cosa che mi ha impressionato di più è stata la voglia d’imparare di quei ragazzi. Niente era scontato, o inutile. Si sono subito interessati particolarmente ai GPS, ed è comprensibile in un contesto dove poco o niente è cartografato.  E’ stato bello vedere la capacità di stupirsi, e l’interesse anche per gli strumenti più semplici. Lì è tutto da fare.
Durante le settimane sono andati in giro per il loro territorio a registrare tracce e punti (foto), che poi insieme abbiamo importato in QGis per scoprire come funziona un sistema GIS desktop. Ma l’ovazione è scoppiata quando hanno visto le loro strade su Google Earth: da un paese in mezzo alla foresta, si sono visti parte del mondo!

L’ultima lezione si è svolta in diretta durante il Sat Expo di Roma (nella foto, un’istantanea della lezione sul megaschermo dello stand ESA), durante le quale

img_7195

ci siamo salutati con la volontà di dare continuità a questo progetto,  e con la speranza di poter fare la prossima lezione dal vivo, a Fontem!

Bhè, ci sarebbero tante cose ancora da raccontare, ma non si addice ad un articolo di blog. Questo piccolo racconto era solo per condividere un’esperienza che, devo dire, mi ha rimotivato anche nella mia attività professionale: ho visto come la geomatica e la geografia, che ogni giorno ritrovo sul tavolo di lavoro, possono essere strumenti per unire il mondo.

Colgo l’occasione per ringraziare tutti i colleghi della Discussion list di Osgeo che per l’occasione hanno condiviso materiale didattico utile alla preparazione del corso.

10 aprile, 2010 | di

L’istrionico Paul Ramsey di OpenGeo in una sua presentazione di 5 minuti a Where 2.0 2010, ci apre gli occhi su quanto realmente i nostri dati facciano schifo… e ci invita a rendercene conto e a dirlo agli altri.

Le mappe sono cose pericolose, la gente crede alle mappe” afferma Paul, “le mappe sono verità, e la gente prende questa verità e ci costruisce sopra informazioni“… questo è l’incipit di una critica ad una realtà – quella sulla precisione dei geodati pronti all’uso – che in effetti ormai sfugge anche a molti di noi, che con questa roba ci lavoriamo.

Ma non voglio aggiungere altro. Godetevi l’ironia di Paul e… pentitevi peccatori! Siete ancora in tempo! ;)

Immagine anteprima YouTube


TANTO non rappresenta una testata giornalistica ai sensi della legge n. 62 del 7.03.2001, in quanto non viene aggiornato con una precisa e determinata periodicita'. Pertanto, in alcun modo puo' considerarsi un prodotto editoriale.