Vittorio Paola mi ha segnalato questo evento che si terrà a Cork il 21 ed il 22 Giugno, e con piacere rigiro la cosa qui. Questi i temi:

Environmental data and applications have some peculiar features that make them distinct from the typical application in applied computer science. During recent years, this has led to the emergence of Environmental Informatics or Enviromatics (Environmental Information and Decision Support Systems). This is a novel field of Applied Informatics which is concerned with the application of computer science techniques to environmental problems. The same methodological and conceptual framework is shared by Computational Sustainability: “an interdisciplinary field that aims to apply techniques from computer science, information science, operations research, applied mathematics, and statistics for balancing environmental, economic, and societal needs for sustainable development”. The ultimate aim of these new and evolving areas of modern research is to develop computational and mathematical models to support decision making in challenging real world problems denoted by the often misused or vaguely defined concept of “sustainability”.
The colloquium will provide cutting-edge data analysis and modeling tools for a variety of practical applications by presenting concepts, algorithms, and case studies related to environmental problems. Attendees can expect a series of presentations on spatio-temporal data organization, analysis, modelling.
The colloquium will be useful for beginning users as well as advanced researchers.

Trovate qui tutti i dettagli:
http://www.4c.ucc.ie/colloquium2010/


Questa è una piccola grande notizia che apprendo grazie @lucamenini : il Ministero dell’Ambiente e della Tutela del Territorio e del Mare, ha autorizzato (il 30 Aprile scorso) a “ricalcare le foto aeree tramite l’accesso al WMS del PCN“.

Sarà possibile arricchire la base dati di OpenStreetMap, tracciando punti, linee, e poligoni su delle basi di buona qualità e finalmente omogenee per il territorio nazionale. Molti dei client con i quali è possibile modificare i dati di OSM, consentono infatti di aggiungere layer WMS come base per il ricalco.

Questo il link da usare in JOSM per la sorgente WMS delle ortofoto del 2006:

http://wms.pcn.minambiente.it/cgi-bin/mapserv.exe?map=/ms_ogc/service/ortofoto_colore_06.map&LAYERS=

ortofoto_colore&REQUEST=GetMap&VERSION=1.1.1&FORMAT=image%2Fpng&

Questo per quella del 2008 (soltanto Umbria e Lazio)

http://wms.pcn.minambiente.it/cgi-bin/mapserv.exe?map=/ms_ogc/service/ortofoto_colore_08.map&LAYERS=

ortofoto_colore&REQUEST=GetMap&VERSION=1.1.1&FORMAT=image%2Fpng&

Ringrazio coloro i quali si sono battuti per questo risultato, ed in particolare Simone Cortesi di OpenStreetMap Foundation, e ovviamente anche il PCN.
Simone ha inoltre lanciato una proposta di virtual mapping party di ritracciatura durante la settimana delle libertà digitali: http://www.libertadigitali.org/

Sono molto contento di questa notizia e chiedo a tutti i lettori interessati di darne ampia eco. Grazie in anticipo!!


“I vostri dati fanno schifo” di Pietro Blu Giandonato è caduto a fagiolo proprio mentre stavo riflettendo su come concludere il mio intervento inserito in scaletta al convegno ”La condivisione dei dati geografici in Europa”. Troverete tutte le informazioni riguardanti questa iniziativa  sul sito istituzionale del progetto GIS4EU, qui. Da questo indirizzo  si può inoltre accedere ai documenti riguardanti l’attività svolta.

Ipotizzo che il lettore interessato sia andato a dare una sbirciatina sul sito ed abbia letto di cosa si è occupato questo progetto. Per i più pigri traduco così: “Proviamo a vedere cosa significa e cosa comporta applicare le regole della direttiva INSPIRE ai dataset esistenti”.

Ciò premesso, posso entrare nel merito dell’argomento che mi era stato affidato, cioè la prospettiva degli utenti sulle SDI: dall’analisi delle esigenze all’utilizzo dei risultati.

GIS4EU WP9-2 Genova Conclusioni1In sintesi, si è trattato di esporre  i risultati di due analisi effettuate nel corso del progetto. La  prima ha riguardato l’individuazione dei bisogni degli utenti di un’Infrastruttura di Dati Territoriali, lavoro svolto nella fase iniziale del progetto. La seconda indagine ha inteso raccogliere informazioni relative all’impatto dei risultati del progetto, coinvolgendo i partner con un ruolo di produttori e fornitori di geodati, ovvero gestori di una SDI.

Ho riassunto l’esito di queste indagini nella slide riportata qui a fianco. Per quanto riguarda i bisogni degli utenti di una SDI, oltre alle esigenze di carattere tecnico (requisiti di standardizzazione e armonizzazione dei dati nonché indicazioni per migliorare i servizi di fruizione dei dati stessi) sono emerse esigenze non tecniche, come il miglioramento delle modalità di comunicazione e di dialogo tra data provider e utenti, la riduzione dei vincoli per l’accesso ai dati, il miglioramento della gestione dei metadati, l’aggiornamento più frequente dei dati, politiche di accesso (licenze e prezzi) ai dati minori (in numero) e più chiare.  E’ stata anche indicata la necessità di debellare il digital divide esistente all’interno delle pubbliche amministrazioni tra addetti ai lavori e chi ha ruoli di decision maker. Risultato in qualche modo scontato: i limiti segnalati contribuiscono a penalizzare i contenuti di origine pubblica ed il loro impiego per tante applicazioni consumer, ma non solo.

Meno prevedibile il risultato della valutazione che i data provider coinvolti in GIS4EU hanno espresso nei confronti dell’esperienza sviluppata e dei risultati conseguiti. In generale, la metodologia individuata per rendere fruibili i propri dataset secondo le regole INSPIRE è ritenuta adeguata allo scopo. Sussistono sicuramente problematiche legate ai costi della sua applicazione, in particolare, costi da sostenere per la formazione del personale (ad es. per fare propria la complessa documentazione tecnica e mantenersi aggiornati) e per adeguamenti organizzativi: ma è anche ragionevole supporre che questi decresceranno nel tempo, potendo anche immaginare una sempre maggiore diffusione, assimilazione e condivisione delle conoscenze essenziali nel mondo della geomatica. E’ stato certamente incoraggiante –rispetto al punto di vista degli utenti- rilevare che il processo GIS4EU è ritenuto utile per favorire la fruibilità dei dati, soprattutto grazie al miglioramento della compatibilità tra dataset, alla disponibilità di data model ed al salto di qualità nella possibilità di condividere fonti di origine differente. I tecnici interpellati, sollecitati a fornire indicazioni sugli effetti dell’esperienza acquisita secondo diversi aspetti (rispetto alle ricadute operative per le organizzazioni, al valore sociale, a quello strategico e politico), hanno comunque  sempre rimarcato –tra i diversi motivi di miglioramento indotti da GIS4EU-  la capacità di comunicazione e l’adozione di modalità di collaborazione in rete.

In conclusione: i risultati di GIS4EU possono concorre a soddisfare i bisogni degli utenti delle SDI.  Quindi, come evitare che questo risultato si dissolva, come valorizzare l’esperienza acquisita?

E’ stato chiesto ai Data Provider di esprimersi anche riguardo ad una disponibilità per assistere eventuali SDI interessate ad applicare il processo GIS4EU ai propri dataset. L’esito è stato tradotto in termini di “visione”, utile per orientare le persone coinvolte e per comunicare questo proposito anche a progetto terminato.

GIS4EU WP9-2 Genova Conclusioni2L’obiettivo dei partner è quello di  “Supportare la più attiva ed efficiente cooperazione tra i fornitori di geodataset, gli enti cartografici e altri gestori di dati geografici, nonché per offrire proposte e fornire piani per sostenere la rapida creazione di un’infrastruttura armonizzata di dati geografici europea”.

Ma sarà raggiunto questo obiettivo?  Certamente i dati e l’informazione geografica sono di grande interesse, nei più diversi campi, e i produttori di GIS4EU WP9-2 Genova Conclusioni4dati sono un riferimento indispensabile per tanti operatori … e sulla Rete si trovano tanti dati … ma… Ecco, qui Pietro Blu mi è venuto in aiuto: segnala l’avvertimento di Paul Ramsey di OpenGeo recentemente lanciato al congresso Where2.0.

Già, crediamo alle mappe e spesso le prendiamo come oro colato. Attraverso di esse produciamo altre informazioni, senza prendere alcuna precauzione. La conclusione di Ramsey è perentoria: “Produttori  di dati controllate se e perché i vostri dati ‘fanno schifo’ e ditelo ai vostri utenti”.

L’impegno profuso durante questo biennio da tanti esperti GI, di SDI nazionali, regionali e  locali, di diverse nazioni europee può essere raccolto per affermare: “I nostri dati saranno affidabili!”.

Perché prima dell’avvento del computer, il mercato “mapping” aveva caratteristiche affatto differenti ed al prodotto cartaceo si poteva anche perdonare d’invecchiare per anni prima di essere sostituito da una nuova edizione. Non è più così. Ma il mutamento del contesto comporta anche nuovi problemi: Ramsey dixit! Soprattutto: nessun ente cartografico o sistema informativo geografico può ormai lavorare da solo!

Per il settore pubblico questa è un’opportunità da cogliere al volo. Quanto ho imparato partecipando a questo progetto e quanto ho ascoltato dai GIS4EU WP9-2 Genova Conclusioni5relatori dell’incontro genovese va proprio nella direzione che segnalavo di ritorno dalla Global SDI Conference di Rotterdam, l’anno passato:  “Le SDI nascono e stanno crescendo più rapidamente, armoniosamente ed hanno maggior successo -cioè soddisfano i bisogni degli utenti (e sono loro a dichiararlo!)- dove è maggiore l’attitudine alla collaborazione, la cooperazione tra istituzioni”.

Non si può, non si deve interrompere la strada intrapresa.

Un cammino che dovrà essere percorso insieme: da soggetti pubblici, privati, del mondo della ricerca, come GIS4EU ha dimostrato. Valorizzando le comunità e le aggregazioni di singoli, come stiamo imparando nel word wide web.

D’altro canto –mi son chiesto- perché  il direttore di OSGeo si è scatenato con un intervento “a gamba tesa” nell’arena più eterodossa ma anche più creativa della comunità IG internazionale?

Posso sbagliarmi, ma credo che ci sia lo zampino di questa norma:  Open Government Directive (OGD, 12/2009). Le parole d’ordine su cui si basa sono:  trasparenza, partecipazione e collaborazione (anche in Italia s’inizia a parlarne: a me, per esempio, è piaciuto questo). Mi pare che la “provocazione”  di Paul voglia andare a parare lì, come dire: “Il futuro è l’OGD ed io ho la soluzione per aiutarvi ad implementare i suoi principi”.  Leggo appunto, visitando il sito di OpenGeo, che propongono una soluzione per aiutare l’implementazione di questi tre principi: “OpenGeo Suite software is standards compliant, fostering collaboration that encourages partnerships and promotes cooperation within the Federal Government, across levels of government, and between governments and private institutions”. Questa è l’evoluzione dell’Open Source: TANTO se n’è interessato qui. Cioè si avvera quanto scriveva T. L. Friedman (Il Mondo è Piatto, Mondadori 2006, pag. 116) soltanto pochi anni fa: “Con  il tempo, vedremo emergere un nuovo equilibrio all’interno del quale tutte le differenti forme di software troveranno la propria collocazione: il tradizionale software commerciale, in stile Microsoft o SAP, insieme al modello Business web del software in affitto, in stile Salesforce.com, e al software libero prodotto o da comunità finanziate o da individui ispirati”.

Le SDI saranno conformi ai principi dell’Open Government Directive; formeranno reti cooperative di SDI, sapranno essere aggregatrici di conoscenze e competenze, guarderanno alla tecnologia come contenitore di soluzioni per le proprie esigenze e i propri obiettivi, senza preconcetti “ideologici”, consapevoli della complessità sempre crescente e dei ritmi di obsolescenza a cui sono soggette. E’ per questo che garantiranno dati affidabili.


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!


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.


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.