2 marzo, 2016 | di Andrea Borruso
Da novembre è attivo Transit.land, un progetto sponsorizzato da Mapzen che ha come obiettivo quello di creare un catalogo “integrato” di dati sulle reti di trasporto di tutto il mondo.
Nasce da una sperimentazione fatta a San Francisco, città con più di 30 agenzie di trasporto pubblico, un numero crescente di servizi privati, il carpooling, ecc.. L’obiettivo era proprio quello di mettere a rete tutti questi dati e catalogare le informazioni su autobus, treni, tram, traghetti anche le funivie e renderli interrogabili come se fossero in un unico database.
Tutto talmente bello, che dopo la sperimentazione “locale” è partito il progetto globale, con l’obiettivo di mettere a catalogo file GTFS da tutto il mondo.
La scelta del formato file di input è caduta proprio su General Transit Feed Specification, oggi lo standard di fatto per questo tipo di dati, usato da Google Maps, Microsoft Bing Maps, Apple Maps, ecc. Molti operatori di servizi di trasporto pubblicano i dati in questo formato, e molti innovatori civici hanno creato questi file per le loro città.
Ma si tratta di risorse che per lo più fluttuano nel web spesso come elementi separati. Transitlad, ancora invero in uno stato iniziale, mira a diventare un centro di gravità per questi dataset, completamente aperto in termini di licenza di software e di dati.
Contribuire
Uno dei modi per contribuire al progetto, lanciato da poco, è quello di inviare una nuova sorgente di dati GTFS, in modo che possa essere integrata al catalogo generale, che oggi comprende più di 70 risorse.
Farlo è molto semplice: a partire da questo wizard dove viene richiesto essenzialmente di inserire l’URL della sorgente dati, il tipo di licenza con cui sono pubblicati ed alcune informazioni anagrafiche del mittente.
Il dataset, a quel punto, viene sottoposto ad una verifica e dopo qualche giorno verrà inserito in catalogo.
Un po’ per testare l’oggetto, un po’ perché mi sembra un gran bella idea – non nuova, ma mai pienamente realizzata – mi sono messo all’opera e nel catalogo Trantit.land oggi sono in eleno le “nostre”:
Le API e la “vita” dei dati
I dati, come dice spesso chi fa didattica su questi temi, sono come la farina e l’acqua: materia prima con cui c’è chi farà torte e chi “busiate” (io non ho dubbi).
A Transit.land hanno impastato tutto e invece hanno tirato fuori delle API, rendendo l’interrogazione del loro catalogo un processo semplice, comodo e che potenzialmente potrà produrre diversi effetti a cascata.
Qualche esempio di query:
- Tutte le fermate di un operatore
- Tutte le rotte di un operatore
- Tutte le fermate nel raggio di 500 metri da un punto di coordinate note
- Tutte le fermate comprese in un rettangolo di coordinate note
- Tutte le fermate in cui un certo tag è valorizzato (in questo caso ingresso con sedia a rotelle) in una certa area
- Tutte le fermate che ricadono nella via che ha come OSM ID il valore 395047052 (Corso Vittorio Emanuele a Napoli)
- Tutti i dati su una determinata rotta
- Tutte le rotte comprese in un rettangolo di coordinate note
- Tutti i dati di un oggetto con un determinato Onestop ID
Ma sono solo alcuni esempi e le chiamate disponibili sono molte di più:
https://github.com/transitland/transitland-datastore#api-endpoints
I risultati sono esposti con una paginazione di 50 in 50.
Open Data Day
Sabato 5 marzo 2016 è l’Open Data Day, e una delle sedi sarà la città di Napoli.
Il bello è che sino a 15 giorni fa i dati sui trasporti di questo comune non erano disponibili ed oggi, solo per il fatto di essere stati pubblicati in formato aperto e documentato sono pure accessibili tramite API. Questo è stato possibile grazie anche a Ilaria Vitellio che si è spesa personalmente con la pubblica amministrazione locale, che ha risposto prontamente ed ha pubblicato questi dati.
In bocca al lupo allora a Ilaria ed a tutti i presenti a Napoli, che avranno a disposizione nuova farina e nuovi mattarelli.
In chiusura una nota personale. Anche i dati sulla mia città, Palermo, sono presenti nel catalogo e quindi accessibili via API, ma purtroppo valgono per fare qualche demo di qualità.
Si tratta di dati aggiornati a fine dicembre, in cui non è contemplata la nuova rete tranviaria e tutti i grossi cambiamenti che la rete ha subito tra fine 2015 e inizio 2016.
E’ un fatto grave, specie per una città ricca di turisti come Palermo e con grossi problemi di traffico autoveicolare, che non siano ancora disponibili dati aggiornati sui trasporti pubblici.
Ne riparlerò in un altro post.
Posted in Strumenti | 5 Comments »
6 ottobre, 2015 | di Andrea Borruso
NdR: questo è stato pubblicato originariamente sul sito della dataninjaschool.
Introduzione
Tra gli strumenti esposti da Google Drive c’è Sheet, un foglio elettronico online ricco di funzioni, molto usato per le professioni e gli utilizzi più svariati.
I fogli creati fungono spesso da “contenitori” di dati, che fanno da sorgente a grafici, mappe, infografiche e applicazioni di svariata natura
L’accesso a Sheet si può eseguire tramite le API ufficiali di interrogazione. Nella documentazione ufficiale è indicato come generare un output, come generarne uno filtrato, come impostare i formati di output, come usarlo come un database relazionale su cui fare delle query SQL con aggregazione, calcoli, ecc.. Sul web, oltre alla guida dedicata, numerosi tutorial ed esempi.
Si tratta di operazioni semplici, con possibilità di uso molto ricche, per uno strumento che è comunque “per tutti“. Nella mia esperienza da formatore ho riscontrato però che per alcuni, la costruzione di una query non è di immediato apprendimento.
Questo post nasce proprio allo scopo di presentare uno strumento che consente di superare questi ostacoli: il buon vecchio Guardian Datastore Explorer di Tony Hirst.
Lo strumento
Il Guardian Datastore Explorer è un vecchietto arzillo: fa la sua prima apparizione nel lontanissimo 2009, un’altra era (non c’era ad esempio Instagram).
Sono due le caratteristiche principali che lo rendono molto interessante:
- consente facilmente di costruire in modo guidato un’interrogazione su uno Sheet di GDrive;
- è molto didattico. Utilizzandolo si impara ad usare il linguaggio di query e dopo poco tempo si impareranno a scrivere stringhe di interrogazione in autonomia con un semplice editor di testo.
E’ uno strumento web ed il suo URL è http://ouseful.open.ac.uk/datastore/gspreadsheetdb4.php.
Come si usa
Predisposizione del foglio Google Drive Sheet
E’ propedeutico avere un account su Google Drive. E poi è necessario avere un foglio elettronico con cui testare il Guardian Datastore Explorer: per le spiegazioni successive verrà utilizzato questo, con i musei del territorio comunale fiorentino.
Si tratta di dati aperti presenti sul portate dati.gov.it. Lo sottolineo perché un’altra cosa abilitata dagli open data è la didattica.
La prima cosa da fare con il foglio elettronico, è crearne una copia:
Fatta la “vostra” copia, è necessario impostarne la condivisione (tasto “Condividi” o “Share” in alto a destra), e fare in modo che (1) chiunque abbia l’URL del foglio, (2) possa visualizzarlo.
Poi si dovrà pubblicare sul web:
In questo video la sequenza della procedura sopra descritta:
La condivisione e la pubblicazione sul web sono necessarie perché il Guardian Datastore Explorer è utilizzabile soltanto con fogli pubblicamente accessibili.
Costruzione della query sul del foglio elettronico
La prima cosa da fare è ricavare il codice identificativo del foglio. Si trova all’interno dell’URL dello sheet ed è facilmente indetificabile.
Ad esempio nell’URL sottostante l’ID del foglio è quello in grassetto:
http://docs.google.com/spreadsheets/d/1nS167pnytroD9SQWi0BUa_eFaeCwuWOk1_0GvsBFmsg/edit#gid=108845820
Quindi in questo caso è “1nS167pnytroD9SQWi0BUa_eFaeCwuWOk1_0GvsBFmsg“.
Poi c’è aprire la pagina web del Guardian Datastore Explorer e (1) inserire l’ID del foglio e (2) fare click su “Preview table headings”. In questo modo l’interrogazione è stata attivata e come risultato vengono visualizzate le (3) intestazione delle colonne del foglio.
Subito dopo si può andare a pescare dati (“Go Fish” scrive l’autore) e iniziare a imparare come usare questo linguaggio di interrogazione, tramite la tabella di esempi riportata sul sito. Leggendola si vede che a tutti gli effetti si tratta un classico SQL (Structured Query Language). Qualche esempio:
| Obiettivo |
Comando |
| Selezionare tutti i record |
SELECT * |
| Selezionare le colonne A e B (ovvero la prima e la seconda) per tutti i record |
SELECT A,B |
| Selezionare tutti record per le colonne A e B, dove il valore della colonna I è uguale a “3467″ |
SELECT A,B WHERE I = 3467 |
| Selezionare tutti record delle colonne C e D, in cui la colonna F non assume il valore di 42043 |
SELECT C,D WHERE F != 3467 |
Nella pagina trovate molti altri esempi.
Un’interrogazione che si potrebbe fare sul foglio dei musei di Firenze potrebbe essere quella per cui applichiamo questi filtri:
- Soltanto le colonne A, B, E, F, G, H, I e K;
- i soli musei a Est della “Cappella Brancacci”;
- solo quelli Statali;
- solo quelli che hanno un numero di telefono associato;
- ordinati da Nord verso Sud.
Prima di costruirla, un breve video che illustra una prima query più semplice, in modo da prendere confidenza con lo strumento: le sole colonne “latitude” e “longitude”, dove la “latitude” è maggiore di 43.77 e tutto ordinato per longitudine crescente.
Fatta la query, poco sopra i risultati di output, tre righe di testo molto interessanti:
La prima è proprio la query che abbiamo costruito, secondo il linguaggio delle API di Google Drive:
select%20A%2CB where B%20%3E%2043.77 order by A asc
Nella stringa ci sono dei caratteri che ne rendono poco “leggibili” alcune parti: select A,B where B > 43.77 order by A asc si comprende meglio. In realtà la prima è il risultato dell’encoding dei caratteri della seconda. Questa è una procedura necessaria perché l’interrogazione viene lanciata tramite un URL, e in questo alcuni caratteri non sono consentiti. Nel nostro caso lo spazio deve essere codificato in “%20″, la “,” in “%2C”, il “<” in “%3E”.
La seconda contiene due hyperlink, a due dei formati di output possibili di una query fatta su Google Drive Sheet: l’HTML e il CSV. Il secondo è forse il formato più comodo per chi dovrà utilizzare i risultati di un’interrogazione per creare grafici, mappe e infografiche.
Questo ad esempio l’hyperlink per l’output in CSV:
http://spreadsheets.google.com/tq?tqx=out:csv&tq=select%20A%2CB%20where%20B%20%3E%2043.77%20order%20by%20A%20asc&key=1nS167pnytroD9SQWi0BUa_eFaeCwuWOk1_0GvsBFmsg
Se lo separiamo in blocchi, si evidenziano elementi interessanti:
tqx=out:csvserve per impostare il formato di output;tq=select%20A%2CB%20where%20B%20%3E%2043.77%20order%20by%20A%20asc per dichiarare la query;key=1nS167pnytroD9SQWi0BUa_eFaeCwuWOk1_0GvsBFmsg per dichiarare l’ID del foglio.
La terza riga un segnalibro che consente di aprire il Guardian Data Explorer con e fargli lanciare la query appena eseguita. E’ un modo per salvare l’interrogazione costruita.
Adesso siamo in grado di costruire la query indicata a inizio paragrafo:
- Soltanto le colonne A, B, E, F, G, H, I e K ->
select A,B,E,F,G,H,I,K
- i soli musei a Est della “Cappella Brancacci” ->
where B > 11.2438292167895
- solo quelli Statali ->
AND I matches 'Statale'
- solo quelli che hanno un numero di telefono associato ->
AND H !=""
- ordinati da Nord verso Sud ->
order by A desc
select A,B,E,F,G,H,I,K where B > 11.2438292167895 AND I matches 'Statale' AND H !=\"\" order by B desc
Per potere usare questa query è necessario eseguire la codifica dei caratteri in modo che possa essere inserita in un URL. Il risultato (mille strumenti online per farlo, uno è questo) dell’endoding è:
select%20A%2CB%2CE%2CF%2CG%2CH%2CI%2CK%20where%20B%20%3E%2011.2438292167895%20AND%20I%20matches%20%27Statale%27%20AND%20H%20!%3D%22%22%20order%20by%20B%20desc
E’ possibile usare allora questa stringa per creare l’URL che esegue l’interrogazione di sopra e che produce come un risultato un file CSV:
http://spreadsheets.google.com/tq?tqx=out:csv&tq=select%20A%2CB%2CE%2CF%2CG%2CH%2CI%2CK%20where%20B%20%3E%2011.2438292167895%20AND%20I%20matches%20%27Statale%27%20AND%20H%20!%3D%22%22%20order%20by%20B%20desc&key=1nS167pnytroD9SQWi0BUa_eFaeCwuWOk1_0GvsBFmsg
Il file scaricato sarà apribile con qualsiasi editor di testo, e qualsiasi foglio elettronico.
Usare l’output di una query per costruire una mappa online
Come già scritto sopra, il risultato di una di queste query può essere usata per visualizzare i dati in differenti modi. Uno è una mappa online (deformazione professionale).
Il dataset di esempio si presta, perché contiene la latitudine e la longitudine di ogni museo. Uno strumento free e open-source molto comodo per generare mappe da output di questo tipo è uMap. Tra i formati di input supportati proprio il CSV; l’unico requisito è che nel file CSV siano presenti le colonne denominate “latitude” e “longitude“.
La cosa interessante è che la mappa online sarà live e ogni aggiornamento fatto nel foglio elettronico, produrrà un aggiornamento della mappa. Questo avviene perché tutte le volte che verrà visualizzata, verrà lanciata una nuova query.
Nel video sottostante è illustrato come creare una mappa online live a partire proprio dall’URL soprastante, che produce in output un CSV.
Considerazioni finali
Il Guardian Datastore Explorer non è un query builder particolarmente potente ed elegante, ma è sicuramente uno strumento che rende semplice l’avvicinamento al Query Language di Google Drive Sheet.
Sopratutto fa comprendere che si tratta di un linguaggio semplice, e dopo poco tempo anche i novizi scriveranno le query “a mano” senza più usarlo. Bastano concetti di base di SQL, sapere fare l’encoding dei caratteri e leggersi la documentazione 
Posted in Didattica | No Comments »
29 aprile, 2010 | di Pietro Blu Giandonato
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.
Dati grezzi, aperti e liberi… a livello mondiale!
Posted in Dati | No Comments »
21 gennaio, 2009 | di Pietro Blu Giandonato
Quelli di 52°North sono forse più noti come coloro che hanno rilevato lo sviluppo di ILWIS da ITC di Enschede. Ma tra i loro progetti più interessanti c’è anche un framework Web Processing Service (WPS) molto promettente, con API a disposizione di tutti e anche due plugin per uDIG e Jump.
Dal loro sito:
The 52N Web Processing Service enables the deployment of geo-processes on the web. It features a pluggable architecture for processes and data encodings. The implementation is based on the current OpenGIS specification: 05-007r7 .
Molto interessanti le caratteristiche della nuova release, tra le quali l’implementazione di Sextante. Qui di seguito l’annuncio lanciato dalla stessa 52°North in mailing-list, con riferimenti alle risorse per poterlo testare e approfondirne l’uso:
The 52°North Geoprocessing Community is proud to announce the release of the Web Processing Service Version 2.0! This new release contains the following changes and extensions:
- Sextante (http://www.sextantegis.com/en/index.htm) processes integration: the current 52N WPS now provides more than 220 Sextante geoalgorithms (http://forge.osor.eu/plugins/wiki/index.php?id=13&type=g) as real WPS processes. Sextante support can easily be enabled/disabled and does not hinder custom developments of individual processes.
- GRID support: any existing process or algorithm can be reused and distributed in the grid for parallel execution. This release enables the user to easily outsource geoprocessing tasks to an external data processing center. It fully supports the widely adopted UNICORE 6 grid middleware. In addition, it is possible to support other grid middlewares (e.g. Globus Tookit 4). No administrative access to the grid infrastrucutre is necessary, only a valid certificate for accessing the target system is required.
- internal architecture redesign with new flexible bindings of different internal datastructures (e.g. Geotools Datamodel)
- support for (very large) rasters
- new Geotiff parser and generator
- improved asychronous datahandling + download of stored files
- several bugfixes
- extended Tutorial: it guides the user through the process of setting up the 52N WPS, creating a new process, as well as executing and exporting the process.
The 52N Web Processing Service enables the deployment of geo-processes on the web. It features a pluggable architecture for processes and data encodings. The implementation is based on the current OpenGIS specification: 05-007r7.
download tutorial here: http://52north.org/twiki/bin/viewfile/Processing/52nWebProcessingService?rev=1;filename=WPS_Tutorial.pdf
download binary distribution here: http://52north.org/index.php?option=com_jdownloads&Itemid=73&task=viewcategory&catid=22
browse the sources in our svn repository here: http://52north.org/svn/geoprocessing/main/WPS/trunk/WPS/
test instances can be invoked here:
http://52north.org:8080/wps/WebProcessingService
http://geoserver.itc.nl:8080/wps/WebProcessingService
more information can be found here: http://52north.org/maven/project-sites/wps/52n-wps-webapp/
Posted in News | No Comments »
