29 ottobre, 2010 | di Antonio Falciano

Il processo di liberazione dei dati pubblici procede abbastanza lentamente in Italia, nonostante le prime lodevoli iniziative in tal senso (dati.piemonte.it, CKAN Italiano, Linked Open Camera), mentre in altri Paesi (USA e UK in primis) si tratta di un fenomeno già ampiamente consolidato, tanto da rivoluzionare radicalmente il tradizionale modo di intendere il rapporto tra cittadini e Pubblica Amministrazione. Si veda, ad esempio, il portale Challenge.gov, dove i vari dipartimenti esecutivi ed agenzie federali americani lanciano delle vere e proprie sfide ai cittadini sulle questioni più disparate, che vanno dall’ambiente alla sanità, dall’economia alla tecnologia, a fronte della risoluzione delle quali sono previsti premi di natura economica.

Challenge.gov is a place where the public and government can solve problems together.

Il clamoroso ritardo del Belpaese in materia di Open Data è imputabile a diversi fattori. Da un lato, persiste di fatto l’assenza di una forte e concreta volontà politica di innescare tale processo in tempi brevi. Dall’altro, tuttavia, si comincia a registrare una graduale presa di coscienza del notevole impatto positivo che la liberazione dei dati prodotti dalla PA è potenzialmente in grado di produrre in termini di trasparenza dell’azione amministrativa e, al tempo stesso, come valida opportunità di sviluppo economico nei vari settori dell’IT. Ampio merito va dato alla Regione Piemonte, che con il suo portale dati.piemonte.it, rappresenta finora l’unica PA italiana che, pur non essendo obbligata a farlo (come argomenta Gerlando Gibilaro in un suo recente post su InDiritto), ha predisposto un banco di prova utile per mostrare effettivamente cosa si può fare con i dati grezzi e qual è il loro potenziale intrinseco ancora tutto da esplorare. A tal proposito, recentemente il portale si è arricchito di un’ulteriore sezione dedicata ai casi d’uso dei dati finora rilasciati, ancora piuttosto limitati in numero, ma non per molto visto che i tempi sono più che maturi…

Infatti, dopo essere rimasti a guardare a lungo cosa accadeva oltremanica o oltreoceano, è giunto finalmente il momento di tradurre questa opportunità in azione! Pertanto, al di là delle etichette, civic hacker, hacktivisti o civil servant di tutta Italia mettiamoci anche noi in gioco, “sporchiamoci” le mani con gli open data e affrontiamo la nostra sfida per l’innovazione e lo sviluppo. Ne va di mezzo anche la reputazione del nostro estro creativo che, da sempre, ci invidia tutto il mondo!

Gli open data piemontesi sul turismo…

All’esordio di dati.piemonte.it, i primi dataset resi disponibili non erano caratterizzati da forte connotazione geografica. Oggi, invece, grazie al recente rilascio dei dati relativi al settore del turismo, è possibile cominciare a ragionare in termini di localizzazione di attività produttive, nella fattispecie di strutture ricettive, e di rappresentazione all’interno di un’applicazione di web mapping, utilizzando un approccio maggiormente legato al territorio rispetto a quello prettamente illustrativo adottato in questo post. Nel dettaglio, sto riferendomi ai dati “Anagrafica esercizi – ricettività”, contenenti l’elenco delle quasi 5000 strutture ricettive piemontesi censite nel 2009, per ognuna delle quali è fornito l’indirizzo (via e comune), alcuni recapiti, la tipologia, l’eventuale qualifica (numero di stelle) e alcuni indicatori di capacità ricettiva (numero di camere, letti e bagni).

Data cleansing e faceted navigation…

Scaricati i dati di interesse, questi si presentano come un file di estensione .7z comprendente, a sua volta, due file .csv, di cui uno contenente i dati veri e propri e l’altro dei metadati. Fin qui tutto ok! Aprendo entrambi i file, tuttavia è possibile notare delle strane sequenze di caratteri (es. +AC0-, +AC1-, +Aog-, …): esse rappresentano la codifica di alcuni caratteri speciali (es. lettere accentate) derivanti dalla conversione dei dati grezzi nel formato CSV a partire dalla sorgente di dati originaria… Emerge chiaramente la necessità di dover ripulire questi dati e, piuttosto che utilizzare un comune editor di testo o un foglio di calcolo, ne ho approfittato per testare Google Refine (ex Freebase Gridworks), software con cui avevo visto fare cose davvero strabilianti in queste screencast.

Si tratta, infatti, di un potente strumento per ripulire i dati grezzi (data cleansing), in grado di renderli consistenti, collegarli a basi di dati esterne come Freebase, aggregarli con dati provenienti da altre fonti, convertirli nei formati necessari da utilizzare in altri strumenti e contribuire ad alimentare, a loro volta, altre fonti di dati. Ma non è finita qui… Pur essendo utilizzato all’interno di un browser, Google Refine non è un servizio web, ma un’applicazione desktop eseguibile sul proprio computer che consente ampia libertà nel flusso di lavoro, prevede un meccanismo di “undo/redo” persistente (anche in caso di crash della macchina!) e supporta diverse modalità avanzate di ricerca e di filtraggio dei dati mediante facet (faccette). In particolare, la “faceted navigation“ (“navigazione guidata” o “ricerca a faccette“) è quel metodo di ricerca incrementale per parole chiavi, molto utilizzato ad es. nei portali di e-commerce, che guida l’utente in tempo reale verso le informazioni ricercate attraverso una serie di piccoli e semplici passaggi, garantendogli ampia libertà di scelta.
I dati sono stati quindi ripuliti dai vari refusi presenti, effettuando operazioni di sostituzione in maniera batch (in caso di errore, come accennavo prima, esiste fortunatamente la possibilità di annullare le modifiche) e controllando, infine, la congruenza dei risultati ottenuti tramite le comode facet e i filtri di testo. I dati così ottenuti sono stati quindi esportati in formato CSV ed, infine, importati e pubblicati in un Google Spreadsheet.

Un problema di geocoding…

Occupandomi di sistemi informativi geografici, il mio interesse nei confronti di questo dataset è scaturito dal fatto che ogni struttura ricettiva è dotata di indirizzo (non solo il comune o la provincia di appartenenza) e che quindi, ai fini della sua rappresentazione su mappa, si presta bene ad essere risolto come un classico problema di geocoding, ovvero di determinazione delle coordinate geografiche (latitudine e longitudine) a partire dagli indirizzi dei punti di interesse (POI). A tal fine, esistono diversi servizi web (geocoder), liberi o proprietari, caratterizzati da diverso grado di copertura, accuratezza ed eventuali restrizioni d’uso, che si occupano di convertire gli indirizzi in coordinate.
Dovendo effettuare tale operazione per migliaia di indirizzi e desiderando automatizzare il processo, ho scelto di utilizzare questo servizio di Google, che consiste in una procedura guidata per la generazione batch dei valori di latitudine e longitudine a partire da un Google spreadsheet, contenente almeno due attributi: un identificatore univoco e l’indirizzo dei punti di interesse. Effettuato il geocoding e verificato che questo sia andato a buon fine, l’accuratezza dell’operazione dipenderà fortemente dalla qualità e soprattutto dal grado di capillarità degli indirizzi che diamo in pasto al geocoder. Per intenderci, mentre nei centri urbani sarà possibile individuare con buona approssimazione le coordinate dei numeri civici, d’altro canto risulterà alquanto improbabile determinare la posizione accurata di un rifugio alpino!
A valle di questa operazione, ho esportato gli identificativi e le coordinate così ottenute all’interno di un foglio di calcolo sul mio pc, manipolandole in funzione del particolare formato richiesto dal framework che mi accingevo ad utilizzare. Successivamente, ho collegato le coordinate alla tabella dei dati originari sfruttando l’identificativo univoco come attributo comune ed ho quindi nuovamente esportato e pubblicato i dati in Google Spreadsheet.

Il framework utilizzato…

Una volta sistemati i dati, il passo successivo consiste nella progettazione e nell’implementazione dell’applicazione web da utilizzare per la loro rappresentazione. A tal proposito, la scelta fin da subito è ricaduta sullo strepitoso SIMILE Exhibit, un framework per la pubblicazione di pagine web caratterizzate da una forte interazione con i dati, che utilizza funzionalità di ricerca e di filtraggio basate ancora una volta sul concetto di “faceted navigation” e che consente di riprodurre agevolmente visualizzazioni interattive dei dati sotto forma di tabelle, thumbnail, mappe, grafici e timeline (come ad esempio ci aveva mostrato Andrea Borruso nel suo post scritto a seguito del terremoto in Abruzzo), senza richiedere il setup di database e di altre tecnologie server-side, nè tanto meno il possesso di skill avanzati di programmazione.
In particolare, il formato di dati che SIMILE Exhibit accetta in ingresso è JSON se la sorgente di dati risiede sullo stesso server dell’applicazione, JSONP negli altri casi. Tra le varie alternative a disposizione, è possibile importare dati da un Google spreadsheet, seguendo queste indicazioni.
Pertanto, dopo aver letto un po’ di documentazione e spulciato il codice di alcuni esempi, ho provato a caricarci sopra l’intero dataset delle strutture ricettive piemontesi. Ahimè… mi sono scontrato con le uniche effettive controindicazioni all’utilizzo di queste API JavaScript, ovvero la limitazione della memoria cache dei browser in cui sono temporaneamente immagazzinati i dati e l’accettabilità del tempo di attesa in fase di caricamento. Trattandosi semplicemente di una proof of concept, ho deciso quindi di ridurre la mole dei dati in Google Refine, filtrando solo la provincia torinese e ripubblicando il tutto su Google Docs. In definitiva, il risultato ottenuto è il seguente (per accedere all’applicazione cliccare sull’immagine):

Nel dettaglio, l’applicazione “Where to sleep in Turin” consente la ricerca delle strutture ricettive della provincia torinese mediante l’utilizzo di:

• tre facet di ricerca di testo sul comune, la denominazione e l’indirizzo delle strutture ricettive;
• una “cloud facet” sulla tipologia;
• una “filter facet” sulla categoria delle strutture dotate di tale qualifica;
• e, infine, tre “slider facet” per controllare l’intervallo di valori dei parametri di capacità ricettiva.

Tra le varie modalità alternative di visualizzazione offerte da Exhibit, sono presenti:

• una thumbnail “STRUTTURE RICETTIVE” al fine di poter consultare in maniera descrittiva ed aggregata i risultati man mano che si restringe il campo della ricerca;
• una mappa nella quale visualizzare l’ubicazione delle strutture ricettive e poterne interrogare gli attributi
• ed, infine, tre scatterplot in cui si pongono reciprocamente in relazione i parametri di capacità ricettiva e dove, ancora una volta, è possibile interrogare le singole strutture su grafico.

In particolare, gli scatterplot presenti nell’applicazione non hanno una finalità strettamente legata alla ricerca delle strutture ricettive, piuttosto vogliono lasciar immaginare e quindi pregustare quanto di buono si possa fare con strumenti come SIMILE Exhibit. In questa applicazione, infatti, le correlazioni individuabili tra i vari parametri esaminati scaturiscono banalmente dalla tipologia di struttura (ad es. se la struttura è un albergo, il numero di bagni per posti letto si aggirerà generalmente attorno al valore 0.5, mentre se si tratta di un campeggio sarà decisamente minore). Diversamente, se al posto di questi dati ci fossero stati, ad esempio, quelli relativi alla concentrazione di un inquinante e all’incidenza di determinate patologie (a tal proposito, si veda questo post), allora la potenza e l’immediatezza di tale modalità di rappresentazione dei dati potrebbe acquistare decisamente tutto un altro spessore ed utilità sociale. Lascio spazio alla vostra immaginazione…

E non è finita qui! Ne approfitto per segnalare la presenza di TANTO alla seconda edizione di ITN 2010, evento che si terrà a Torino l’11 e il 12 novembre 2010 (in concomitanza con le giornate conclusive di ASITA, sic!), in cui il nostro hacktivista Pietro Blu Giandonato interverrà con “I ‘luoghi’ degli open data: dove e come trovare in Italia i dati per sviluppare applicazioni location aware“ (slide) nella sessione “Domanda (potenziale) e offerta (implicita) di informazione geolocalizzata: gli anelli mancanti”. In particolare, uno dei temi chiave della sessione è rappresentato dai “Dati geografici del settore pubblico o free, consolidati e facilmente accessibili, potenzialmente utilizzabili per la costruzione di significative applicazioni basate su informazione geolocalizzata” e credo che quelli utilizzati nell’applicazione appena mostratavi ne sono un più che valido esempio. Come si dice da queste parti …stay tuned!

Posted in Dati, osgeo | 9 Comments »

13 aprile, 2009 | di Andrea Borruso

Gli eventi abruzzesi mi hanno toccato molto. Non poteva essere diversamente.

Sono un geologo e mi occupo di sistemi informativi geografici; posso dare un piccolo aiuto anche io, sfruttando le mie attitudini e le mie competenze?
Per giorni non ho trovato la risposta, poi mi contatta in chat Alessio Di Lorenzo, un amico biologo abruzzese e curatore  del portale cartografico del Parco Nazionale della Majella, e mi chiede se conosco una fonte da cui estrapolare dei dati sugli eventi sismici di questi giorni. Li vuole elaborare e trasformare in una sorgente geoRSS, prendendo spunto proprio da quanto abbiamo scritto qui. Inizialmente la cosa mi ha fatto piacere, ma non mi ha stimolato nulla. In seguito,  aprendo l’URL che gli ho inviato, quello del Centro Nazionale Terremoti dell’Istituto Nazionale di Geofisica e Vulcanologia, qualcosa mi ha fatto “click” in testa. Ma “poco poco, piano piano”.

Mi sono passati davanti agli occhi, i dati sismici pubblicati in questi giorni. Quelli “ufficiali”, quelli presentati dai giornali online di tutto il mondo, quelli sui blog. Alcuni sono caratterizzati da piccole grandi carenze, potenzialmente superabili con poco sforzo, ma con origini che sono profonde.

Tim Berners-Lee, uno degli “inventori” del World Wide Web, ha presentato nello scorso Febbraio una relazione orale sul futuro del Web (grazie a Stefano Costa per la segnalazione). E’ visibile in diversi siti, e gli dovreste dedicare 15 minuti del vostro tempo (se la guardate qui ci sono i sottotitoli, ha un inglese “difficile”), qualsiasi mestiere facciate.  In quella sede ha lanciato uno slogan: “raw data now“, letteralmente “dati grezzi ora”. Ha invitato il “mondo”, gli enti pubblici e quelli privati, a “liberare” i propri dati e creare i presupposti affinché questi possano essere accessibili e mescolati tra loro. Ha invitato inoltre tutti noi a stimolare chi detiene dati, a muoversi in questo senso; senza la condivisione, questi perdono quasi del tutto la loro qualità.

Berners-Lee individua tre regole:

1. deve bastare un semplice indirizzo web, un URL, per puntare ad un dato
2. chiunque abbia accesso a quell’URL, deve poter scaricare i dati in qualche formato standard
3. devono essere descritte le relazioni tra i dati (Andrea è nato a Palermo, Palermo è in Italia, etc.), e queste relazioni devono essere espresse ancora una volta tramite un’URL

Questo sarà il web 3.0, basato sui dati e (si spera) sulle relazioni semantiche tra gli stessi. Ma torniamo ai dati sismici sul nostro paese. Rispettano queste tre regole?

Questa non sarà una critica al CNR ed all’INGV. Leggo sul loro sito, che gran parte dei dati da loro pubblicati in questo contesto, sono affidati (ancora una volta) al volontariato. A molti dipendenti infatti sembra non sia stato rinnovato il contratto. Non conosco questa situazione, ma è molto triste anche soltanto immaginare che una funzione di questo tipo possa essere “relegata” a semplici attività di volontariato.
Quello dei dati sismici è per me solo uno spunto, ed il discorso va allargato a tutti i contesti in cui esistano dei dati pubblicati in modalità poco efficienti (o addirittura non pubblicati).

Il formato in cui sono accessibili gran parte dei dati sismici è il CSV :

è un formato di file basato su file di testo utilizzato per l’importazione ed esportazione (ad esempio da fogli elettronici o database) di una tabella di dati.  Non esiste uno standard formale che lo definisca, ma solo alcune prassi più o meno consolidate.

Un esempio pratico è quello delle date, espresso in alcuni file dell’INGV in questo formato YYYY/MM/DD (2009/04/13). Aprendo uno di questi file con un foglio elettronico, il campo “data” verrà quasi sicuramente interpretato in automatico ed adattato alle impostazioni “locali” del vostro PC. Su molti PC italiani, sarà infatti forzato questo formato: DD/MM/YYYY (13/04/2009). E’ la stessa data? Sembra di si. Ma se iniziassimo a scambiare questi dati con colleghi, che usano un semplice blocco note per aprire il file CSV (senza quindi che i dati siano “trasformati”), o che vivono in un altro paese (quindi con un’impostazione locale differente), in quanto tempo ne perderemmo l’integrità?
Usando degli standard, ad esempio per le date l’ISO 8601 , riusciremo a dare ai nostri dati una vita più lunga ed anche una “platea” molto più estesa.

Altre volte i dati sono pubblicati come tabelle HTML. Avete mai provato a fare copia ed incolla di una tabella, da una pagina web ad un foglio elettronico? Molte volte se ne esce con le ossa rotte.
E’ giusto pubblicare i dati in html, ma dovremmo sempre fornire anche altre possibilità. Il servizio geologico americano (“so forti li americani”), lo USGS, pubblica da tanti anni un catalogo di eventi sismici in tre formati: KML (il formato di Google Earth che è ormai uno standard OGC), CSV ed XML (geoRSS). E’ una scelta che mi sembra cristallina. Si conciliano infatti formati adatti ad un’immediata divulgazione, con un formato RAW (come direbbe Tim Berners-Lee).  Il file KML e quello XML consentono ai dati di essere interpretati correttamente da una macchina e di essere “mescolati” più facilmente con altri provenienti da altri pc, scritti con altri software e  prodotti da altri gruppi di lavoro. Questa opportunità è un aspetto molto importante, in quanto l’incrocio di dati diversi spesso fa saltare agli occhi significati inaspettati; a costo di essere noioso, se non definisco i miei dati in un formato standard, sarà difficile riuscire a correlarli “immediatamente” con altri. L’INGV si sta muovendo sullo stesso solco, e in questa pagina troverete i dati degli eventi sismici degli ultimi 90 giorni sia informato CSV, che KML. Ma troverete anche questo avviso:

Le informazioni contenute in queste pagine sono state sinora garantite dalla disponibilità del personale, precario e non dell’Istituto Nazionale di Geofisica e Vulcanologia. L’agitazione del personale dell’Istituto contro l’emendamento 37bis alla proposta di legge 1441 quater, che in sostanza provocherebbe il quasi immediato licenziamento del personale precario, porterà alla sospensione di tutte le attività. Nell’immediato si procederà al blocco di ogni tipo di informazione telematica e telefonica non istituzionale.

Ma torniamo un attimo alle tre regole di sopra. La prima può sembrare meno importante, ma nasconde nella sua semplicità di formulazione un grande potere (sembra Spiderman).
Usiamo ogni giorno gli indirizzi http, gli URL. Li usiamo in modo naturale e spontaneo, senza chiederci cosa siano, su cosa si basino e come funzionino. E non c’è nulla di male.
Quando cambio canale della mia TV con un telecomando, non devo avere alcuna nozione sulla trasmissione dell’infrarosso; devo soltanto saper che devo usare un determinato tasto. Se prendo il telecomando del mio nuovo stereo, mi viene naturale utilizzarlo allo stesso modo. Così per il lettore DVD e per la mia pompa di calore (dite che questa è una forzatura?).
Anche accedere a diversi tipi di dati, di diversa origine, dovrà essere una cosa così semplice e “spontanea”. Con lo stesso protocollo, l’http, non più accedere “soltanto” a pagine web ma anche a fonti di dati grezze.

Quello che gli eventi abruzzesi mi hanno stimolato, come uomo e come professionista, è l’attenzione alla politica della gestione dei dati. Le classi dirigenti del nostro paese dovrebbero allinearsi a quanto esposto da Tim Berners-Lee. Sia perché il cittadino possa essere informato, sia per dare forza e valore ai dati, i quali se chiusi in un hd o divulgati in modo inappropriato rischiano di essere inutili e di produrre uno spreco (non soltanto economico).
Dobbiamo tenere alta l’attenzione verso questi temi.

I fatti di questi giorni, il dialogo con i colleghi di TANTO, l’indiretto stimolo di Alessio, i post di altri blogger, mi hanno spinto anche a provare a realizzare una piccola cosa concreta, proprio a partire dai dati sismici della regione Abruzzo.
Si tratta di qualcosa che a prima vista è confrontabile alle interfacce di webmapping basate su Google Maps, in cui in coincidenza della posizione di ogni evento sismico è raffigurato un “pallino”. Quello che ho provato ad aggiungere è la possibilità di modificare e “mescolare” i criteri di visualizzazione del dato: a partire dalla serie di dati che ho estratto, poter visualizzare ad esempio soltanto gli eventi sismici di Marzo, di magnitudo maggiore di 4, di profondità compresa tra 5 e 10 km e del distretto sismico del “Gran Sasso”. L’utilizzo di questi filtri mi ha dato (da utente) la sensazione di potere leggere “meglio” i dati; spero che non dipenda dall’emotività con cui ho lavorato su questo piccolo progetto.
Ho aggiunto anche una timeline, che da la possibilità di passare dalla visualizzazione degli eventi in scala spaziale, ad una efficacissima in scala temporale. Anche qui potrete usare gli stessi filtri.
C’è una visualizzazione tabellare “dinamica” in HTML, ordinabile usando qualsiasi delle colonne presenti, ed anche questa “sensibile” ad i filtri.
Infine i dati sono esportabili in diversi formati, tra i quali: RDF/XML, Semantic wikitext, Tab Separated Values. Per attivare l’export basta andare con il mouse alla sinistra del modulo “Cerca”, e cliccare sull’icona a forma di forbice che verrà visualizzata (vedi figura).
Purtroppo ho riscontrato un problema con l’export nel formato a cui tenevo di più – RDF/XML – ma spero di risolverlo nei prossimi giorni (è un piccolo autogol ).

L’interfaccia sviluppata ha però un vero grande difetto (e magari non sarà l’unico): non si aggiornerà in automatico, ogni volta che verranno pubblicati nuovi dati dall’INGV. Questo perché sono partito dai quelli pubblicati qui (una tabella HTML), e non da quelli in CSV o KML. Nei prossimi giorni proverò a partire da quelli in CSV, darli in pasto a Yahoo! Pipes ed automatizzare il processo di pubblicazione.

L’applicazione è visibile qui, e qui sotto vedete uno screenshot della timeline.

E’ realizzata con Exhibit, e ci scriverò a breve un tutorial di dettaglio. In questo post volevo “fare” altro.

Chiudo dando la disponibilità di collaborazione mia e dei miei colleghi, a chiunque ritenga che le nostre competenze possano essere d’aiuto in questo momento.

Un abbraccio forte a tutti quelli che stanno vivendo questo terribile momento; uomini, donne e bambini con una compostezza ed una dignità fuori dal comune.

“Sopra le nuvole c’è il sereno” diceva Endrigo in una meravigliosa canzone  “d’amore”.

Posted in Dati, osgeo | 6 Comments »