Popolamento del Data Warehouse

A seguito delle operazioni di trasformazione introdotte nella sezione precedente, è stato creato un dataset che contiene i CDR arricchiti con le informazioni riguardanti la zona OMI dalla quale viene effettuata la chiamata, il profilo dell’utente e l’ora in cui è avvenuto l’evento di chiamata (Tabella 3.9).

Il fatto definito in Sezione 2.3 prevede di fornire le informazioni sul numero di presenze rilevate rispetto il profilo dell’utente, la zona e l’orario di rilevazione. Questa informazione si deve ottenere tramite il calcolo della misura nUtenti, che

consiste in un COUNT DISTINCT degli identificativi degli utenti. Per far sì che questa operazione fosse possibile anche sul sistema distribuito che abbiamo deciso di adottare per la memorizzazione dei dati, siamo stati costretti a sottoporre il dataset in Tabella 3.9 ad ulteriori manipolazioni. Il fatto (Presenze) è stato materializzato come un attributo che rispetto alle tre dimensioni (Data, Luogo, Utente) contiene le presenze rilevate, ovvero gli identificativi degli utenti. In questo modo, per ogni record abbiamo un profilo utente, una zona ed un orario con l’insieme di utenti rilevati in base alle precedenti coordinate. Come accennato in Sezione 2.3, dato il tipo di sistema di archiviazione dei dati, la misura nUtenti viene calcolata come lunghezza del set di identificativi degli utenti. Ricordiamo che la nostra decisione di conservare la lista degli identificativi degli utenti serve perché non vogliamo una misura additiva. Un utente può essere presente nella stessa ora nella zona A e nella zona B allo stesso livello di granularità, non vogliamo che in un’eventuale aggregazione di A e B l’utente venga contato due volte. Per cui, con la nostra soluzione, nel momento in cui decidiamo di aggregare A a B, viene effettuato un nuovo COUNT DISTINCT sul set totale di utenti dell’una e dell’altra zona.

L’output del processo di Data Engineering ha la struttura della Tabella 3.10. Avendo adottato questo tipo di struttura per memorizzare i dati, abbiamo deciso che le computazioni delle serie temporali devono essere effettuate da un layer Spark di cui parleremo nel prossimo capitolo.

Come possiamo vedere, in Tabella 3.10 decidiamo di materializzare in un unico record tutte le informazioni relative al fatto di analisi e alle dimensioni comprensive delle gerarchie. La dimensione Data è stata ricreata scompattando il timestamp (Tabella 3.9) in diversi attributi contenenti le informazioni sull’ora, il giorno, il mese, l’anno e il giorno della settimana. La dimensione Luogo è stata ricostruita tramite l’indicazione del codice OMI e del comune (Tabella 3.9) alle quali sono state aggiunte le informazioni sulla provincia e sulla regione, come previsto dalla gerarchia spaziale descritta in Sezione 2.2. Infine, il fatto coincide con la lista degli utenti rilevati in base alle diverse dimensioni, dato che la misura calcolata nUsers viene implementata da un programma che restituisce le informazioni sulle presenze estrapolando la lunghezza di questa lista, come è stato descritto nel Capitolo precedente in Figura 2.3.

Nel prossimo capitolo descriveremo in che modo i dati memorizzati nel sistema distribuito vengono elaborati e rappresentati graficamente.

anno mese giorno giorno ora reg prov com omi label ids _sett

2015 11 22 5 7 toscana firenze signa R1 resident 15,..

Tabella 3.10: Struttura dei record memorizzati nel sistema di archiviazione dati distribuito. Ogni record possiede un profilo utente, le informazioni temporali ri- guardanti anno, mese, giorno, ora e giorno della settimana e le informazioni spaziali rispetto la regione, la provincia, il comune e la zona OMI. In base a queste dimensioni nell’attributo ids viene salvata la lista degli identificativi degli utenti.

Capitolo 4

Mobility Atlas Booklet: Web

Analytics

Il capitolo precedente mostra come abbiamo manipolato i dati di input e come questi sono stati trasformati e caricati nel sistema di archiviazione dati distribuito. In questo capitolo descriviamo come rendiamo possibile la loro rappresentazione in modo tale da comunicare informazioni rilevanti.

In Figura 4.1 vengono mostrati gli attori che partecipano al processo che porta dai dati memorizzati alla loro rappresentazione grafica sulla piattaforma Web sviluppata. Al centro della figura troviamo il layer API, descritto in Sezione 4.1, dal quale è possibile accedere ai dati in memoria tramite un sistema di richiesta in base ad alcuni parametri forniti in input. Il layer progettato restituisce i dati aggregati in un formato adeguato a realizzare delle viste di interesse. Per il sistema di API sono state sviluppate due funzioni (getStat, getOd ) che restituiscono gli aggregati relativi alle serie temporali di presenza e alle origine delle stesse.

Nella Sezione 4.2 descriviamo come abbiamo deciso di rappresentare i dati restituiti dalle API soffermandoci sulle funzionalità della web application e sulla descrizione di ogni vista di analisi.

Questa fase del progetto di tesi mi ha consentito di imparare ad utilizzare il sistema di creazione di API RESTful apiDoc. Inoltre, ho messo in pratica le mie conoscenze riguardanti il framework Spark per la creazione delle serie temporali. Infine, ho potuto mettere in pratica le mie conoscenze del framework d3.js e la mia esperienza nel Web Design per realizzare delle rappresentazioni grafiche di una piattaforma Web interattiva.

4.1

Layer API

Il sistema di API RESTful, è stato creato tramite Flask. Per creare la documen- tazione necessaria alla definizione delle nostre API è stato utilizzato il tool apiDoc

Figura 4.1: Rappresentazione grafica dell’interazione tra le API ed il sistema di archiviazione dati distribuito e tra le API e le analisi mostrate nella piattaforma Web. Ogni volta che serve un’analisi le API mandano una richiesta al sistema distribuito inviandogli dei parametri. Quando otteniamo i dati le due funzioni previste calcolano le varie statistiche sui dati ed infine questi vengono restituiti in diversi formati utili per la realizzazione delle viste di analisi.

(Figura 4.2).

Le API si occupano dell’accesso ai dati mentre le computazioni vengono effettuate mediante l’utilizzo delle librerie di map/reduce fornite da Spark.

In base alle domande che ci siamo posti in Sezione 2.3 le API effettuano diversi calcoli sui dati e restituiscono due risultati con i dati aggregati rispetto diversi orizzonti spazio-temporali. Come già accennato, per permettere la restituzione dei

Figura 4.2: Esempio di documentazione di una delle funzioni implementate nelle API.

due tipi di risultati abbiamo sviluppato due funzioni all’interno delle nostre API, getStat e getOd. Procediamo col definire per ognuna i parametri che ricevono in input, la chiamata ad essa ed il formato dei risultati in output.

4.1.1

Funzione getStat

In questa sezione descriviamo la funzione API getStat che restituisce le serie temporali di presenza in un certo territorio rispetto il giorno del mese, il giorno della settimana e l’ora.

Parametri in input La funzione getStat prende come parametro in input la gerarchia spaziale dell’area territoriale per la quale ci interessa conoscere l’affluenza degli utenti. In base a che livello spaziale ci troviamo abbiamo 4 diversi formati per i parametri in input (Tabella 4.1).

Livello spaziale Formato parametro in input

Regionale /regione

Provinciale /regione/provincia Comunale /regione/provincia/comune

OMI /regione/provincia/comune/omi

Tabella 4.1: Descrizione dei diversi formati che può prendere la funzione getStat in input. Il formato cambia in base al livello di granularità spaziale richiesto.

In base al formato del parametro in input la funzione riconosce il livello di granularità spaziale delle analisi. Per cui, nel caso in cui il parametro in input è

sbagliato, verrà restituito un errore. Ad esempio, se la funzione riceve in input i parametri /regione/OMI la funzione non è in grado di restituire la gerarchia richiesta perché non esiste nella definizione del Data Warehouse.

Chiamata API Quando interroghiamo le API, effettuando una richiesta alla funzione getStat indichiamo la gerarchia spaziale desiderata, ossia per quale zona geografica siamo interessati a calcolare l’aggregato. Le chiamate sono implementate come chiamate GET con il seguente formato:

http://mab:8000/api/getStat/users/<regione>/<provincia>/<comune>/<omi>

Le richieste di questo tipo producono in output i dati relativi ad una zona OMI che si trova in un comune, a sua volta contenuto in una provincia di una regione. Ritroviamo qui la gerarchia del parametro in input come descritta nel paragrafo precedente.

Formato output Il risultato di una chiamata alla funzione getStat è in formato JSON. La formattazione ci permette un suo facile utilizzo e rappresentazione.

All’interno del risultato restituito troviamo due serie temporali in cui i dati sulle presenze sono aggregati rispetto due orizzonti, ovvero quello giornaliero e quello settimanale e orario.

La prima serie temporale presenta i dati con una struttura a matrice in cui il conteggio delle presenze è riportato stratificato per le classi di comportamento degli utenti rispetto all’ora e al giorno della settimana (ad esempio 23-7 contiene il conteggio degli utenti presenti nel settimo giorno della settimana, ossia di domenica, alle 23). Come mostrato in Figura 4.3 per ogni combinazione di ora del giorno e giorno della settimana abbiamo il conteggio delle presenze rispetto la tipologia dell’utente.

La seconda serie temporale calcolata restituisce per ogni categoria di utente il conteggio delle presenze per timestamp contenente le informazioni su anno, mese e giorno. In questo modo, per ogni classe di comportamento degli utenti abbiamo le serie temporali alla granularità del giorno del mese. In Figura 4.4 viene riportato il risultato restituito dalla chiamata API ovvero la serie temporale rappresentata in formato JSON, per la quale la chiave è la classe degli utenti e il valore è il conteggio delle presenze di utenti di quel tipo per giorno del mese.

I risultati delle computazioni svolte dalla funzione vengono salvati in una memoria cache. In questo modo se le API ricevono una richiesta per la funzione con un parametro per cui sono stati già svolti i calcoli una volta, vengono restituiti i risultati presenti in memoria. Tale memorizzazione permette un accesso rapido ai risultati senza bisogno di attendere ad ogni richiesta il termine dei calcoli, anche perché questi vengono effettuati su dataset molto grandi.

Figura 4.3: Prima sezione del risultato restituito dalla funzione getStat che contiene le informazioni sulle presenze stratificate per classe di comportamento utente aggregate per ora e giorno della settimana.

4.1.2

Funzione getOD

In questa sezione descriviamo la funzione getOD implementata all’interno delle API la quale restituisce le informazioni sulle residenze degli utenti contenute nel dataset CDR calcolate con la metodologia del Sociometro.

Parametri in input La funzione getOD esegue un diverso tipo di aggregazione dei dati e prende due parametri in input, l’indicazione spaziale nel formato specificato in Tabella 4.1 per la funzione getStat, ed il giorno del mese rispetto il quale vogliamo avere le informazioni sulle residenze degli utenti affluenti. Quindi oltre alla gerarchia spaziale, alla funzione forniamo in input il giorno per cui vogliamo le analisi, nel formato AAAA-MM-GG.

Chiamata API Per richiamare la funzione getOD, la chiamata alle API viene effettuata nel seguente formato:

http://mab:8000/api/getOD/users/<regione>/<provincia>/<comune>/<omi>?timefilter= AAAA-MM-DD

Nella chiamata all’indicazione della gerarchia spaziale viene concatenato un altro parametro (timefilter) il cui valore viene definito dall’utente. Quindi, stiamo

Figura 4.4: Seconda sezione del risultato restituito dalla funzione getStat riguardante le time series, ossia le presenze stratificate per classe di comportamento utente, aggregate per giorno del mese.

chiedendo le informazioni sulle residenze di provenienza degli utenti che si trovavano in una zona omi in un dato giorno.

Formato output La funzione getOD restituisce in output un oggetto JSON contenente le informazioni sui comuni di residenza degli utenti stratificate per categoria di utente rispetto al luogo di destinazione che ha generato la chiamata. Il formato dell’oggetto è riportato in Figura 4.5, nel quale abbiamo per ogni provincia l’elenco dei comuni con associato il numero di utenti ivi residenti stratificato per categoria d’utente. La chiamata restituisce diversi livelli geografici (provincia e comune), in quanto siamo interessati nel fornire la stessa informazione sia a livello comunale che superiore. In questa fase non abbiamo considerato la possibilità di riportare la residenza a livello regionale, tuttavia il metodo è facilmente estendibile.

Anche per i risultati ottenuti con la funzione getOD avviene lo stesso tipo di memorizzazione esposto per getStat, secondo la quale viene messa a disposizione una memoria cache contenente le computazioni calcolate di volta in volta in base ai diversi parametri con i quali la richiesta viene effettuata.

Figura 4.5: Struttura del risultato restituito dalla funzione getOD. Le residenze degli utenti stratificate per classe di comportamento vengono conteggiate per comune con riferimento alle province di afferenza.

4.2

Layer Analytics

Le chiamate alle funzioni fornite dalle API, descritte in Sezione 4.1, vengono effettuate dalla web application (MAB). L’applicazione sviluppata serve per visua- lizzare i risultati restituiti dalle funzioni getStat e getOD tramite rappresentazioni intuitive delle serie temporali. Tra l’applicazione e le API vi è un rapporto di domanda-risposta per cui l’applicazione Mobility Atlas Booklet interroga il layer API inviando le richieste con gli input opportuni, il layer API restituisce i risultati sotto forma di oggetti Json ed, infine, l’applicazione mostra le metafore grafiche utilizzate per la rappresentazione dei valori ottenuti.

I risultati delle time series restituiti dalle funzioni delle API vengono rappresentati graficamente attraverso grafici a linee o a barre molto efficaci nel mostrare i risultati delle analisi sulle presenze delle persone, soprattutto per osservare caratteristiche particolari come variazioni e andamento nel tempo e nello spazio dei fenomeni rilevati. Una delle finalità di analisi di questo tipo è la Event Detection, ossia la scoperta di eventi su un territorio in base alla variazione delle presenze su di esso. Questa procedura ci aiuta a verificare l’attrattività e l’efficacia di un particolare evento.

Il prodotto finale si presenta come una single-page web application sviluppata utilizzando tecnologie web che ci permettono di visualizzare le informazioni di nostro interesse a diversi livelli di granularità spazio-temporale. Per quanto riguarda la parte grafica, la pagina è stata realizzata utilizzando Bootstrap. Per la realizzazione dei vari grafici, è stata utilizzata la libreria d3.js. Per gestire invece, le interazioni e la parte logica della pagina sono stati utilizzati degli script in Javascript. La maggior parte di questi sono stati utilizzati per gestire la navigazione e l’interazione

dell’utente con l’applicazione.

La web application è progettata in modo tale da permettere all’utente la navigazio- ne di aree territoriali ai diversi livelli di granularità spaziale (Regionale, Provinciale, Comunale, OMI). Per la navigazione spaziale l’applicazione fornisce una mappa interattiva che permette la selezione delle aree territoriali per le quali vogliamo visualizzare le informazioni sulle presenze. Questa mappa viene caricata tramite Leaflet e grazie alla sua usabilità e alla sua flessibilità è stato possibile permettere il caricamento su di essa del file topoJSON (Sezione 3.1.2) contenente le informazioni riguardanti i diversi layer che si vogliono visualizzare sulla mappa, i quali sono navi- gabili sia attraverso la selezione sulla mappa sia grazie al menu a tendina presente nell’intestazione della pagina web.

Figura 4.6: Mappa interattiva MAB.

In base all’area selezionata dall’utente l’applicazione invia una chiamata alla funzione getStat fornita dalle API, passandogli come parametro in input la gerarchia relativa alla area scelta. Di seguito, descriviamo i grafici presenti sulla web application, soffermandoci sulla loro utilità ai fini che ci eravamo preposti. Inoltre, mostriamo quando viene chiamata la funzione getOD e come facciamo a passargli il secondo parametro di input.

Temporal distribution Tramite un grafico a linee mostriamo i risultati restituiti dalla funzione getStat relativi alle distribuzioni delle presenze rispetto al giorno del mese. Questo tipo di rappresentazione riesce a mettere in evidenza in modo opportuno eventuali picchi di presenze presenti nelle time series.

Il grafico in Figura 4.7 mostra la distribuzione normalizzata giornaliera delle presenze divisa per le diverse categorie di utenti, per ognuna delle quali abbiamo una linea di diverso colore. Tramite il radio button all’interno del grafico è possi-

Figura 4.7: Temporal distribution. Distribuzione delle presenze nell’area geografica in analisi per giorno del mese, stratificate per categoria d’utente.

bile visualizzare anche i risultati non normalizzati di questa analisi, fornendo un riferimento sulle cifre reali registrate. Inoltre, la legenda della vista è cliccabile e permette la selezione di alcune categorie d’utente, non solo nel grafico di contesto ma anche per il resto della pagina. Questo ci permette di effettuare delle analisi sulle distribuzioni delle presenze, differenziate per categorie di utente direttamente sulla web application.

Al di sotto di questo grafico vi è un cruscotto per la selezione di un diverso intervallo temporale di analisi, che permette di effettuare il focus su un periodo in particolare.

Infine, a livello provinciale, comunale e di zona OMI è possibile cliccare su un giorno di una categoria compresa tra Visitatori, Pendolari e Passanti, e visualizzare le province o i comuni di residenza (dipende dal livello di granularità di analisi in cui ci troviamo) degli utenti selezionati in quel giorno, in un grafico che descriveremo successivamente. Questo è possibile grazie alla chiamata alla funzione getOD alla quale diamo in input il riferimento spaziale della zona che stiamo analizzando, sempre nel formato gerarchico richiesto, e il giorno del mese selezionato dall’utente sul grafico. Temporal Matrix Le informazioni sulle presenze rispetto il giorno della settimana e l’ora presenti nell’oggetto json restituito dalla funzione getStat sono d’aiuto per la rappresentazione della settimana tipo di un territorio.

Il grafico in Figura 4.8 mostra la densità delle presenze rispetto al giorno della settimana e l’ora, quindi sugli assi ritroviamo le due dimensioni ed ogni casella è colorata in base al numero di presenze rilevate in quella finestra temporale, si passa da un blu scuro in presenza di valori minimi fino ad un rosso scuro per quelli massimi. Come descritto nel precedente paragrafo, questa matrice risponde alla selezione

Figura 4.8: Temporal matrix. Time grid contenente la rappresentazione della settimana tipo nell’area selezionata.

delle categorie di utente visualizzate nella Temporal Distribution, perciò è possibile visualizzare diverse analisi rispetto alle diverse categorie di utente selezionate. Daily distribution Sempre utilizzando le informazioni restituite da getStat, ab- biamo deciso di rappresentare anche la distribuzione delle presenze per ora del giorno rispetto ai giorni feriali e festivi, per cercare di individuare dei comportamenti inte- ressanti negli andamenti delle presenze rispetto queste due tipologie di giorni. Questa analisi la rappresentiamo tramite il grafico a linee esposto in Figura 4.9 che mostra la distribuzione oraria rispetto ai giorni feriali, indicati tramite una linea grigia con area, e a quelli festivi, rappresentati tramite una linea rossa. Questo grafico è in grado di catturare le diverse forme che prendono gli andamenti delle presenze rispetto ai giorni della settimana e rispetto alle categorie di utente, sempre utilizzando la loro selezione nella Temporal Distribution.

Figura 4.9: Daily distribution. Distribuzione delle presenze per ora del giorno stratificate per giorni feriali e festivi.

Origin distribution I grafici descritti finora vengono mostrati a tutti i livelli di analisi anche regionale. Il grafico descritto in questo paragrafo viene mostrato solamente quando si scende al di sotto del livello regionale. Si tratta del grafico di cui parlavamo nel paragrafo sulle Temporal Distribution che permette di visualizzare le residenze, quindi le origini, degli utenti selezionando un giorno ed una categoria, compresa tra Visitatori, Pendolari e Passanti, nel grafico della distribuzione giorna- liera. Il grafico viene visualizzato solo per le categorie di utenti la cui provenienza può fornirci informazioni interessanti. In questo caso, i dati rappresentati sono quelli restituiti dalla funzione getOD. Nel grafico a barre mostrato in Figura 4.10 viene mostrato un prospetto delle provenienze degli utenti della categoria selezionata presenti sul territorio in quel giorno. Anche in questo grafico è possibile decidere se