luglio 18

Visualizzare i dati in tempo reale dal sensore di #acqualta

Una delle caratteristiche dei sensori connessi a Internet (la famosa Internet delle Cose, o Internet of Things) è che sono fonti continue di dati, non producono un dataset statico e immutabile una volta per tutte. In particolare, se previsto, possono inviare un flusso continuo di dati leggibili da un URL pubblico. Una volta caricata la pagina si hanno i dati fino a quel momento. Ricaricandola dopo un certo tempo, le informazioni sono diverse: in particolare ci saranno i nuovi dati prodotti nel frattempo. Si tratta di risorse dinamiche: dato un URL a cui connettersi (inclusi dominio, percorso e variabili GET), la risposta dipende da quando ci si connette.

S.Basilio_aperta Naturalmente tutto dipende anche da quanto spesso il sensore raccoglie e invia i suoi dati: potrebbe essere una volta al giorno, una all’ora, una ogni tot secondi o anche più spesso, in un flusso di dati in tempo reale. Per usufruire fino in fondo di questi dati è necessario tener conto di questa peculiarità dei sensori come fonti. Se l’aggiornamento del dato avviene per esempio ogni secondo, fornire l’ultimo disponibile solo al caricamento della pagina web di pubblicazione è limitante, perché già dopo qualche minuto quel dato sarà vecchio. A meno di ricaricare la pagina. Le moderne tecnologie del Web, per fortuna, mettono a disposizione strumenti più utili e avanzati, come il caricamento asincrono di risorse esterne (noto sotto il nome di AJAX, Asynchronous JavaScript and XML).

Tipicamente i dati di sensori vengono pubblicati mediante API in un formato utile per essere gestito da altre applicazioni. È il caso dei sensori del progetto #acqualta, che misurano il livello dei canali della laguna di Venezia. Il formato scelto è in questo caso il JSON e i dati sono accessibili a questo indirizzo: http://api.acqualta.org/api/data. Tutte le informazioni sulla sintassi da usare per personalizzare la richiesta di dati sono sul sito ufficiale. Si tratta di dati temporali: l’altezza del livello dell’acqua nel tempo, raccolta ogni 10 minuti circa durante alcune ore di ogni giorno. Sono perfetti quindi per essere efficacemente visualizzati mediante un semplice grafico a linee.

Lo strumento migliore e più potente per sviluppare applicazioni di visualizzazione di dati su web è senza dubbio la libreria javascript D3js. Sul sito della Dataninja School si possono trovare un paio di mie lezioni sull’uso base di questa libreria. L’esempio più semplice da cui partire è comunque quello presente nella gallery del sito ufficiale, il grafico a linee. La modifica più importante a quel codice riguarda la possibilità di ricaricare dinamicamente e in maniera asincrona (cioè senza bloccare la pagina) i dati del sensore e aggiornare e ridisegnare quindi il grafico davanti agli occhi dell’utente. Qui sotto il risultato, il cui codice è accessibile pubblicamente su GitHub. EDIT: se siete interessati alla questione Same-origin policy delle richieste AJAX, in coda a questo mio post su Facebook potete trovare un’utile discussione a riguardo.

La chiave per ricaricare periodicamente i nuovi dati è la funzione setInterval( (function) callback, (integer) interval ) definita nativamente in javascript. In maniera asincrona esegue ogni [interval] millisecondi la funzione [callback], che al suo interno scarica gli eventuali nuovi dati, mantiene memoria di quelli vecchi e aggiorna opportunamente il grafico. Nel caso specifico dei dati di #acqualta tutto questo non è strettamente necessario, perché la frequenza di aggiornamento dei sensori è di circa 10 minuti, quindi richiedere nuovi dati ogni 30 secondi è abbastanza inutile. Ma è sufficiente per dimostrare il principio di un’applicazione web pensata per visualizzare in tempo (quasi) reale i dati provenienti da un sensore remoto.

E se conoscete altri progetti che mettono a disposizione i dati dei propri sensori via API, fatemelo sapere!

Category: Intro | LEAVE A COMMENT
luglio 7

Il progetto #acqualta a Venezia

L’autore di questo articolo è Luca Corsato, civic hacker e attivista open data di quelli che “ce ne vorrebbero di più”, oggi ospite speciale di questo blog per raccontare la sua avventura sensor-based a Venezia.


Quando nell’aprile 2013 io e Oreste Venier abbiamo iniziato a lavorare al progetto #acqualta siamo partiti da due esigenze:

  • Oreste voleva testare in Laguna dei sensori di livello di liquidi che aveva provato solo su piccoli corsi d’acqua;
  • io volevo estrarre letteralmente dei dati dal territorio in maniera diretta e in tempo reale.

Ci è sembrata subito una buona idea quella di concentrarci sulla questione alta marea a Venezia, anche per due ulteriori, importanti motivi: innanzitutto perché ci sono già soggetti che raccolgono questo tipo di dati (ISPRA, Centro Maree, ISMAR CNR) e questo ci avrebbe consentito di controllare e verificare i nostri, e poi perché nessuno di questi soggetti fornisce i dati in modalità scaricabile in tempo reale attraverso delle API. L’elemento che ci ha dato la spinta decisiva è stata la possibilità di proporre l’adozione dei sensori da parte di qualsiasi cittadino avesse a disposizione un punto di accesso all’acqua.

Per realizzare il progetto in tempi brevi abbiamo attivato da subito i nostri amici con le competenze necessarie: Roberto Scano per il lato web, Diego La Monica per il server, Paolo Mainardi per le API, Simone Venturini per i passaggi amministrativi e la relazione con il Comune di Venezia (in quanto allora era consigliere comunale) e Francesco Piero Piersoft Paolicelli per i test su una app di prova. Infine si è aggiunto Andrea Raimondi per le traduzioni e la costruzione del modello concettuale presentato a State of the Net.

La costruzione del modello concettuale ci ha consentito di formulare una serie di considerazioni che partono da un primo assunto: si sta sedimentando l’idea che i dati siano disponibili in modalità download di tipo click and save e questo è limitante perché impone una intermediazione umana. Invece con #acqualta si è voluto introdurre da subito la possibilità di accedere ai dati in modalità automatica attraverso opportune API, consentendo in questo modo di affrontare fin dall’inizio un digital divide ancora troppo poco considerato.

acqualtamap
La posizione dei tre sensori di #acqualta installati in questo momento.

Su #acqualta si possono fare ulteriori riflessioni che possono essere considerate come una sorta di coordinate per l’approccio ai sensori e – per estensione – al sensor journalism:

  1. sistema di riferimento: i dati forniti da sensori richiedono una serie di parametri che permettano la confrontabilità, anche tra fonti diverse;
  2. georeferenziazione: i sensori sono strettamente legati al luogo geografico in cui sono installati ed da cui estraggono i dati;
  3. automatizzazione: i dati in tempo reale, soprattutto se di tipo ambientale, spesso sono prodotti rapidamente e in grande quantità, il che obbliga ad avere un minimo di confidenza con la lettura automatica su database e con strumenti di visualizzazione e sintesi efficaci.
S.Basilio_aperta
Il sensore installato a San Basilio.

Al momento siamo in piena fase di sviluppo, anche perché ci siamo resi conto che lo schema impresa – comunità civic hacker – cittadini è realmente in grado di esprimere una capacità conoscitiva efficace ed efficiente, consentendo alle Amministrazioni di concentrarsi maggiormente sull’aspetto puramente decisionale.