La Direttiva 2008/50/CE costruisce tutto l’impianto di valutazione della qualità dell’aria attorno a punti di campionamento fissi, con i criteri di ubicazione su macroscala e microscala fissati negli Allegati III e VIII. Una lettura presa da un sensore montato su un veicolo in movimento in quello schema non rientra: non ha una posizione stabile, non ha un periodo di mediazione legato a un sito, e produce un valore per ogni coordinata che attraversa. Il dato c’è, è fitto, e sta fuori dalla cornice che dovrebbe dargli un significato legale. È questo il problema di governo che il monitoraggio mobile mette sul tavolo, e lo sto incontrando lavorando attorno al sistema RIPEG.

Contesto

RIPEG (l’acronimo del progetto, finanziato sul POR FESR della Regione Toscana) è un sistema portatile che rileva in tempo reale particolato ultrafine, ozono, monossido di carbonio e ossidi di azoto, installato su veicoli che girano per l’area urbana. Quello che esce non è una serie temporale per un sito, ma una traiettoria: una sequenza di letture, ognuna con un timestamp e una posizione. Rispetto alla rete fissa cambia la natura del dato, non la quantità.

Il particolato ultrafine (diametro sotto gli 0,1 µm) lo mostra bene. La Direttiva 2008/50/CE regola PM10 e PM2.5 come concentrazioni di massa, perché il metodo di riferimento è gravimetrico (l’Allegato VI rimanda alla EN 12341 e alla EN 14907). La frazione ultrafine però non pesa quasi niente: il suo segnale è il numero di particelle per centimetro cubo, non la massa. La si misura con contatori a condensazione, non con un campionatore su filtro. Già lavori del 2009 su piattaforme ciclabili — Berghmans et al. a Mol, Boogaard et al. su undici città olandesi — avevano mostrato che le concentrazioni numeriche di ultrafini cambiano molto nella stessa via e che i loro picchi non vanno insieme a quelli del PM2.5. La grandezza che il veicolo misura bene è proprio quella che la rete fissa non vede, e per cui non c’è un valore limite normato.

Architettura

Sul lato software il sistema si divide in tre responsabilità. Un’unità a bordo del veicolo accoppia le letture dei sensori al dato di posizione e le trasmette. Un livello server le riceve, le normalizza e le archivia (PostgreSQL come base dati, con un livello geospaziale per indicizzare le coordinate). Un livello di visualizzazione mostra la traiettoria sulla mappa in tempo reale.

La visualizzazione è il punto in cui la scelta tecnica del 2010 è più esposta. Il pannello gira su HTML5 e Google Maps, senza plugin: il browser scarica il dato via AJAX e disegna i punti misurati sopra la cartografia. A metà 2010 il terreno si muove ancora sotto i piedi. La Geolocation API del W3C è ferma all’ultima Last Call Working Draft e non ha ancora raggiunto la Candidate Recommendation; l’elemento canvas e gli altri pezzi di HTML5 sono Working Draft, non standard chiusi. Costruire l’interfaccia su HTML5 adesso è una scommessa sulla direzione, non l’adozione di una base ferma. È una scelta difendibile — evita il plugin proprietario — ma va detta per quella che è.

Punto critico

Il nodo non è raccogliere il dato mobile, è renderlo leggibile a chi sul veicolo non c’era. Una concentrazione di 30.000 particelle/cm³ misurata in un punto, da sola, non dice quasi niente: dipende dal sensore e dalla sua taratura, dalla velocità del veicolo in quell’istante (che fissa il tempo di residenza nella cella d’aria), dal ritardo tra aspirazione e lettura, dalla bontà del fix di posizione. Una stazione fissa tiene molti di questi fattori costanti e documentati una volta per tutte. Il veicolo li fa variare lungo la traiettoria.

Quindi il dato grezzo, da solo, non si governa. Si governa solo se ogni lettura si porta dietro il proprio contesto di acquisizione: identificativo e stato di taratura del sensore, velocità istantanea, accuratezza del fix, ritardo della catena di misura. Senza questi metadati attaccati alla singola riga, il riuso a valle — confronto tra campagne, aggregazione su una via, costruzione di mappe — sforna numeri di provenienza opaca. Con un sistema mobile non è un dettaglio facoltativo: è la condizione perché il dato voglia dire qualcosa fuori dal momento in cui è stato preso. Disegnare il modello dati, qui, è una scelta di governo della misura prima che di ingegneria.

Implicazioni

Il peso vero ricade sull’analisi a valle. Per costruire indicatori sintetici (medie per via, mappe di esposizione, serie aggregate) sopra dati mobili servono regole di aggregazione esplicite e ripercorribili: quante letture per cella, con quale soglia di velocità, quali fix imprecisi da scartare. Strumenti di business intelligence geospaziale possono calcolare questi indicatori, ma l’indicatore vale quanto la regola che lo genera, e la regola va versionata insieme al dato. Un numero su una mappa che non si riesce a ricondurre alle letture che lo compongono e ai filtri applicati è un’affermazione che nessuno può verificare, per quanto curata sia la grafica. Il pannello di controllo che noze sta costruendo per RIPEG — server di raccolta, viewport HTML5 su Google Maps e strumenti di BI geospaziale — affronta proprio questo nodo: https://www.noze.it/insights/ripeg-expo-shanghai/.

C’è poi il rapporto con la rete regolamentata. Il monitoraggio mobile non rimpiazza le stazioni fisse della Direttiva 2008/50/CE — non ne ha né i metodi di riferimento né i regimi di mediazione. Le affianca, e copre la variabilità spaziale fine che la rete fissa, per come è fatta, non risolve. Tenere distinti i due piani è già di per sé un atto di governo del dato: trattare una traiettoria mobile come se fosse una serie da stazione fissa vuol dire dare al numero una validità legale che non ha.

Il sistema rientra tra i progetti scelti per la rassegna “Italia degli Innovatori” all’Expo di Shanghai, aperta dal 1° maggio al 31 ottobre 2010 sul tema “Better City, Better Life”. Il tema dell’Expo è la città; la qualità dell’aria misurata strada per strada è una sua descrizione possibile, a patto che i numeri restino ricostruibili.

Limiti

Quanto sopra descrive un problema, non lo chiude. Restano aperti almeno tre punti. Il primo è la deriva dei sensori: senza un protocollo di taratura periodica e di registrazione del suo stato, i metadati di calibrazione che ho chiamato in causa restano incompleti. Il secondo è la stabilità della base HTML5, oggi non chiusa: un’interfaccia costruita su Working Draft eredita le incertezze di quelle specifiche. Il terzo è l’assenza di un riferimento normativo per il numero di particelle ultrafini: il dato che il veicolo misura meglio è quello per cui manca un valore limite a cui agganciarlo. Su nessuno dei tre la tecnologia, da sola, ha l’ultima parola.

https://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2008:152:0001:0044:EN:PDF https://www.w3.org/TR/2009/WD-geolocation-API-20090707/ https://www.w3.org/TR/2010/WD-html5-20100304/ https://en.wikipedia.org/wiki/Expo_2010

Immagine di copertina: Il Padiglione Italia all’Expo 2010 di Shanghai di notte, con l’ampia facciata in vetro illuminata dall’interno e alcuni visitatori in… — foto di 凌智, CC BY 2.0 — https://commons.wikimedia.org/wiki/File:Italy_Pavilion_of_Expo_2010.jpg