UNIVERSITÀ DI PISA Dipartimento di Informatica
Corso di Laurea Magistrale in Informatica per l’Economia e l’Azienda (Business Informatics)
TESI DI LAUREA
Mobility Atlas Booklet: piattaforma per la costruzione, visualizzazione e navigazione di indicatori di presenza dei diversi tipi di utente di un
territorio ottenuti da dati di telefonia mobile
RELATORI
Prof.ssa Fosca GIANNOTTI Dott. Lorenzo GABRIELLI
CANDIDATO Maria Teresa ROSSI
"True, I talk of dreams, Which are the children of an idle brain, Begot of nothing but vain fantasy, Which is as thin of substance as the air And more inconstant than the wind, who woos Even now the frozen bosom of the north, And, being angered, puffs away from thence, Turning his face to the dew-dropping south." W. Shakespeare
Sommario
La tesi propone lo studio delle presenze all’interno di un’area di riferimento attraverso l’uso di dati di telefonia mobile. Come risultato del progetto di tesi mostriamo: la progettazione della struttura di archiviazione dati ad hoc che ha consentito il calcolo delle distribuzioni spazio-temporali delle presenze; l’implementa-zione di una procedura di Estral’implementa-zione, Trasformal’implementa-zione e Caricamento dei dati che ha permesso il popolamento della struttura di archiviazione; lo sviluppo di funzioni API che permettono il calcolo e l’estrazione di informazioni interessanti a partire da un dataset di dati di telefonia mobile. Lo studio effettuato dimostra che a partire da questo tipo di dati è possibile costruire degli indicatori utili per l’analisi dei comportamenti della popolazione presente in un certo territorio. Oltre alle procedure di manipolazione dei dati e di estrazione della conoscenza, vengono anche esposte delle modalità di rappresentazione grafica delle informazioni sulle presenze ottenute. Sono stati presentati dei casi di studio reali sia per testare le modalità di utilizzo dell’applicazione sviluppata, sia per mostrarne le potenzialità nel campo dell’analisi territoriale.
Indice
Introduzione 1
1 Setting the stage 3
1.1 Background . . . 4
1.2 Data sources . . . 8
1.3 Tecnologie . . . 12
1.3.1 Metodologie . . . 12
1.3.2 Strumenti per lo sviluppo . . . 14
2 Mobility Atlas Booklet: Progettazione 17 2.1 Definizione del problema . . . 18
2.2 Analisi dei Requisiti . . . 19
2.3 Disegno del Data Warehouse . . . 22
3 Mobility Atlas Booklet: Data Engineering 26 3.1 Data Acquisition . . . 26
3.1.1 Categorizzazione degli utenti . . . 27
3.1.2 Preparazione del layer spaziale . . . 29
3.1.3 Creazione di altri layer informativi . . . 33
3.2 Data Transformation . . . 34
3.2.1 Preparazione del Dataset . . . 35
3.2.2 Popolamento del Data Warehouse . . . 38
4 Mobility Atlas Booklet: Web Analytics 41 4.1 Layer API . . . 41 4.1.1 Funzione getStat . . . 43 4.1.2 Funzione getOD . . . 45 4.2 Layer Analytics . . . 47 5 Use cases 53 5.1 Lucca Comics&Games 2015 . . . 54
5.3 Stagionalità dei turisti nel comune di Firenze . . . 70 5.4 Relazione tra costo delle abitazioni e presenze sul territorio . . . 73
Conclusioni 75
Introduzione
Negli ultimi anni, la digitalizzazione della società ha prodotto una enorme ric-chezza di dati sulle città ad una notevole frequenza temporale e a bassi livelli di aggregazione spazio-temporale. I cittadini trasmettono informazioni sia volontaria-mente tramite, per esempio, l’uso dei social network, che passivavolontaria-mente grazie ai sistemi di geolocalizzazione. La rivoluzione messa in atto dalla diffusione dei Big Data permette di caratterizzare la società urbana rispetto nuovi aspetti riguardanti la vita e i comportamenti dei cittadini. Il valore aggiunto apportato dalla diffusione dei dati riguardanti le abitudini e le preferenze delle persone non è solo di natura sociale, ma anche economica. Questa grande mole di informazioni implica un grande investimento nello sviluppo di nuove tecnologie capaci di memorizzare, interpretare e valutare enormi quantità di dati. Allo stesso tempo, la possibilità di raccogliere e aggregare questi dati ha fatto emergere nuove problematiche in relazione ai diritti individuali. Tutte le informazioni che abbiamo a disposizione su un individuo ci per-mettono di renderlo identificabile, pertanto un aspetto da non sottovalutare attiene all’uso dei Big Data in modo etico nel rispetto della privacy e delle norme vigenti. Per cui già nella fase di progettazione di un processo analitico su dati riguardanti esseri umani dobbiamo tener conto di queste direttive.
Il lavoro svolto si pone all’interno del progetto di Mobilità Intelligente Ecososteni-bile (Mie) del Cluster Tecnologico Nazionale nell’ambito delle Tecnologie per le Smart Communities, un progetto che vuole raccogliere metodologie hardware/software, in-dicatori e politiche di gestione della mobilità per controllare aspetti quali impatto ambientale, tempi di percorrenza e consumi necessari per compiere gli spostamenti. Il principale problema affrontato durante lo svolgimento della tesi è stato quello di definire una metodologia che permettesse di estrarre della conoscenza relativa ai comportamenti delle persone, partendo da una fonte di dati molto ampia. Il progetto si è incentrato sullo sviluppo di una tecnologia utile a fornire informazioni di interesse agli amministratori di un territorio: se consideriamo un luogo come insieme di dati generati dalla mobilità degli utenti che lo popolano, possiamo gestirne le funzioni tramite la costruzione di una metodologia e di processi analitici ad hoc .
Pertanto, il prodotto sviluppato vuole essere utile ad una pubblica amministra-zione nell’ambito degli Osservatori Turistici di Destinaamministra-zione, in particolare per la
gestione della mobilità, per la misurazione dell’attrattività, oppure per aiutare nella identificazione delle provenienze dei visitatori del territorio.
Per riuscire a realizzare una tecnologia che riuscisse a fornire degli indicatori di un qualche interesse sui comportamenti delle persone, abbiamo utilizzato una fonte di dati generata dall’attività di chiamata di determinati utenti. Questi dati sono stati raccolti da un grande gestore telefonico italiano e contengono i dettagli dell’attività di telefonia mobile di un campione di clienti. I dati a nostra disposizione sono stati sottoposti a metodologie di profilazione degli utenti in base alla loro attività e quindi messi in relazione con dimensioni spazio-temporali. Per effettuare i calcoli necessari ad ottenere degli indicatori di presenza dei diversi tipi di utente di un determinato territorio, abbiamo implementato una architettura che trasforma i dati telefonici in serie temporali stratificate per categorie di utenti. Per poter visualizzare i risultati delle computazioni effettuate sui dati è stata sviluppata internamente una piattaforma web che, tramite delle API, mostra i risultati tramite delle tecniche di visualizzazione dati intuitive.
Nel Capitolo 1 viene introdotto il contesto scientifico di riferimento e vengono presentati i dati utilizzati. Tra i dati utilizzati, sono descritti: la suddivisione territoriale utilizzata; i point of interest raccolti dal servizio di OpenStreetMap; i dati telefonici sotto forma di Call Detail Record. Inoltre, vengono indicate le tecnologie utilizzate durante il percorso di sviluppo della tesi.
Nel Capitolo 2 viene mostrata la progettazione della struttura dati su cui vengono effettuati i calcoli relativi alle distribuzioni spazio-temporali. Quindi, viene effettuata dapprima un’analisi dei requisiti in base alle necessità a cui vogliamo rispondere con il nostro lavoro, e poi viene mostrato il processo di progettazione della struttura dati.
Nel Capitolo 3 mostriamo il processo di Estrazione, Trasformazione e Caricamento dei dati sfruttato durante il lavoro che ha favorito la costruzione dei vari layer di analisi per i diversi livelli di granularità, decisi durante la fase di progettazione. Quindi una volta trasformati i dati in una forma utile è stato possibile implementare e popolare il Data Warehouse progettato nel Capitolo 2.
Nel Capitolo 4 viene illustrata la web application che abilita la visualizzazione dei risultati del lavoro svolto durante il periodo di tirocinio, quindi tutte le sue funzionalità e potenzialità.
Il Capitolo 5 mostra alcuni casi d’uso della web application, in particolare vengono mostrati due casi di analisi relativi ad eventi che si tengono nei territori di Lucca e Pisa. In conclusione vengono trattati gli sviluppi futuri del lavoro.
Capitolo 1
Setting the stage
I Big Data ci permettono di monitorare i comportamenti delle persone e di utilizzarli in diversi ambiti, ovvero per misurare, monitorare e prevedere diversi aspetti socio-economici. L’uso dei Big Data si sta diffondendo in contesti come quello sportivo, medico o di pianificazione territoriale. Negli ultimi anni c’è stata una larga diffusione dei dispositivi dotati di geolocalizzazione, e questo ha reso possibile la raccolta di dati sulla mobilità degli utenti. La mobilità è uno dei temi maggiormente complessi che deve gestire la pubblica amministrazione. Grazie all’utilizzo dei Big Data diventa possibile osservare con maggiore precisione e tempestività le presenze, i flussi e conseguentemente l’attrattività dei luoghi di interesse.
Possiamo ottenere informazioni sugli spostamenti e sulle presenze su un territorio tramite rilevazioni GPS, ma anche grazie ai dati di telefonia mobile. Alcune agenzie di assicurazione installano sulle macchine rilevatori per motivi di sicurezza, pertanto è possibile la rilevazione di informazioni molto dettagliate sui tragitti percorsi dagli utenti. Il loro limite risiede nel fatto che non tutti i veicoli sono dotati di dispositivi GPS e, soprattutto, forniscono informazioni riguardanti soltanto i viaggi in auto, non considerando, per esempio, la mobilità pubblica, di non secondaria importanza per le pubbliche amministrazioni.
D’altra parte, le informazioni sulle attività di telefonia mobile (Call Detail Record ), riescono a rilevare gli spostamenti degli utenti a prescindere dal loro mezzo di trasporto. La letteratura [2] ci dimostra come lo studio delle presenze e dei movimenti delle persone,a livello individuale o collettivo, possa essere utile per osservare fenomeni legati all’uso di energia, alle problematiche legate alla salute, alla statistica nazionale e ai trasporti. In aggiunta, per i paesi in via di sviluppo, il contributo dei Big Data è fondamentale per alimentare la statistica nazionale. Ad esempio, sul territorio del Senegal1 sono state osservate le correlazioni tra la diffusione di malattie virali, come Malaria, Tubercolosi ed Ebola, e le presenze rilevate.
1.1
Background
Lo scopo della tesi è di mostrare come l’analisi della mobilità tramite i dati di telefonia mobile possa servire a rispondere ad alcune necessità della società moderna, come ad esempio la realizzazione del censimento continuo della popolazione. Il dato telefonico è il candidato ideale per questo nuovo tipo di analisi perché il cellulare è estremamente diffuso ed utilizzato in tutto il mondo. Grazie alle informazioni di fatturazione è pertanto possibile risalire alle antenne collegate ai luoghi di chiamata e conseguentemente è possibile dare una rappresentazione della mobilità delle persone molto dettagliata.
Lo studio dei dati di telefonia mobile costituisce uno strumento per responsabili della mobilità di un territorio in grado di rispondere alle seguenti domande:
1. Quante persone, oltre ai residenti, sono presenti ogni giorno sul territorio? 2. Dove vanno, ossia quali sono le zone più visitate?
3. Perché visitano il territorio e da dove vengono? 4. Ci sono aree del territorio più residenziali di altre?
5. Possiamo trovare correlazioni tra le presenze sul territorio e altri indicatori socio-economici?
La pubblica amministrazione potrebbe voler sapere quante persone sono presenti sul territorio in un particolare giorno e di che tipo di presenze si trattano, se di residenti, pendolari o visitatori. La rilevazione delle presenze può servire sia per monitorare il traffico che per analizzare i movimenti dei turisti. Per rispondere a queste necessità la tesi prende spunto dal processo analitico descritto in [7] che mostra come i dati di telefonia mobile possono essere usati per rilevare picchi di presenze sul territorio rispetto un determinato periodo, oppure come ci possono aiutare nel capire quali sono le zone o i punti di interesse più frequentati. L’uso dei dati telefonici rappresenta un grande aiuto nella gestione degli eventi, nella classificazione delle aree in residenziali/lavorative, ma anche nella misurazione innovativa dell’inquinamento derivato dalla mobilità degli individui. Per esempio, in [4] si cerca una correlazione tra la mobilità ed aspetti come inquinamento e sicurezza nelle Megacity. Viene analizzato un paese poco "motorizzato" (Less Motorised Country LCM) come Delhi (India) per verificare l’impatto dei trasporti pubblici e non "motorizzati" sugli aspetti
descritti.
In base al tipo di attività registrata tramite i CDR (Call Detail Record ), in [8] viene mostrato come effettuare una classificazione degli utenti di telefonia mobile tramite l’utilizzo di una metodologia chiamata Sociometro. Questo strumento, a partire dall’attività telefonica registrata costruisce un profilo di chiamata per
ogni utente sulla base del giorno della settimana e l’ora in cui le chiamate sono state effettuate. Analizzando i profili vengono identificate delle categorie di utente: Residente, Pendolare, Visitatore. La categorizzazione degli utenti si basa su un ragionamento secondo il quale i dati telefonici riuscirebbero a determinare la densità di popolazione di un’area, perché assume che gli utenti aventi un’attività telefonica serale/notturna più intensa in un’area siano residenti in questa [5]. In [7] viene mostrata una particolare applicazione del Sociometro nello studio di una grande città come Roma. Gli autori mostrano le distribuzioni delle presenze presso quattro punti di interesse noti: Piazza San Pietro, Stadio Olimpico, Circo Massimo, Piazza San Giovanni in Laterano. Le distribuzioni delle presenze vengono a loro volta stratificate per categoria d’utente per meglio giustificare eventuali comportamenti anomali rilevati. In questo particolare caso, vengono messi in evidenza picchi di presenze in determinate zone soprattutto in prossimità di eventi religiosi o di concerti (come quello di Bruce Springsteen il 16 luglio 2016) che interessano principalmente i visitatori, ma anche altri tipi di eventi, quali la corsa contro i tumori2, ai quali
sono interessati principalmente i residenti. La stratificazione delle presenze, unita alla focalizzazione geografica delle stesse, consente di rilevare eventi che sarebbero invisibili osservando la città nel suo complesso.
La classificazione delle presenze su un territorio è molto utile per capire chi lo visita e perché. A tale scopo, vengono identificati e isolati i picchi di presenze significativi e inusuali nelle distribuzioni temporali o spaziali, questo ci permette di quantificare e capire gli eventi ed il loro impatto sulle dinamiche della città e sulla composizione della popolazione. Per esempio, può aiutarci per sapere se un evento ha avuto successo e quindi ha attratto persone anche non locali, oppure per capire come cambia la composizione degli utenti in base al periodo e cercare dei pattern di presenze ricorrenti. Capire e caratterizzare gli eventi locali con i dati telefonici può infatti aiutare nell’organizzazione degli eventi futuri per la gestione della sicurezza e della mobilità. In [6] è stato realizzato uno studio sui flussi turistici nella città di Pisa utilizzando i dati telefonici forniti un grande provider Italiano. Innanzitutto, per cercare informazioni interessanti, è stata studiata la densità di presenza dei visitatori in alcune aree di interesse della città (Piazza dei Miracoli, Stazione Centrale, Aeroporto, Ippodromo, CNR, Folgore). Successivamente, sono state messe a confronto le distribuzioni giornaliere delle presenze nelle diverse aree ed anche le distribuzioni orarie in particolari giorni in alcune zone. Il lavoro mostra come è possibile ricostruire i comportamenti di una settimana tipica dei cittadini di questa zona tramite il calcolo delle presenze medie giornaliere, che in questo caso specifico sono state messe a confronto con quelle delle persone in transito per verificare se avessero un’alta incidenza sui rilevamenti effettuati. Inoltre, viene esposto anche
come i dati di telefonia permettono di effettuare uno studio sul tempo di permanenza degli utenti su un’area.
L’analisi dei movimenti degli utenti insieme alla loro classificazione ci aiuta anche nella costruzione di una Origin Destination (OD) Matrix per conoscere la provenienza delle persone che visitano il nostro territorio, stratificata per categoria d’utente. Questa analisi serve per ricostruire i flussi tipici di traffico, e fornire un supporto alla gestione della mobilità extra-urbana, fondamentale per cercare di migliorare l’interconnessione tra le città, sia in occasione di eventi che per favorire il pendolarismo. E’ stato dimostrato come l’analisi dei movimenti rilevata con i Big Data sia un ottimo proxy per stimare i movimenti reali sul territorio [3]. A sostegno di quanto sopra presentiamo il framework Urban Mobility Atlas3(UMA) sviluppato dal KDD Lab di Pisa. UMA utilizza le tracce GPS per costruire pattern di mobilità degli utenti a livello comunale. L’interfaccia grafica permette di visualizzare i pattern di accesso/uscita di un comune. Le traiettorie costruite da UMA vengono classificate in sistematiche e occasionali, in modo tale da contestualizzare i risultati osservati. Quando analizziamo le traiettorie possiamo ottenere informazioni anche su aspetti quali lunghezza, velocità e durata del viaggio effettuato da un utente.
Nella letteratura esistono anche diversi lavori che studiano come i dati di telefonia mobile riescano a fornire informazioni utili sull’utilizzo del territorio. In [11] gli autori effettuano una classificazione del territorio in base alle distribuzioni temporali di chiamata. Capire come gli utenti che frequentano un territorio sono distribuiti nel tempo e nello spazio è fondamentale per prendere decisioni di pianificazione all’interno delle città. Soprattutto, perché le informazioni sulle diverse abitudini possono essere d’aiuto per pianificare le infrastrutture di mobilità. Infine, osserviamo come l’utilizzo di dati di telefonia mobile per stimare la presenza, aiuta a superare i limiti derivanti dagli strumenti tradizionali di raccolta di informazioni sui movimenti delle persone (questionari, interviste), come mancanza di precisione, limitata grandezza del campione e costi di raccolta. In [9] tramite l’analisi dell’utilizzo delle telecomunicazioni viene costruita una rappresentazione della città come space of flows. In questo caso l’attività telefonica viene collegata all’utilizzo commerciale del territorio. L’autore effettua un’analisi del territorio suddividendolo in zone e per ognuna di esse cerca di individuare il comportamento dominante, riuscendo infine a trovare pattern simili per le zone commerciali.
Oltre alla mobilità delle persone, i dati telefonici rivelano molte altre informazioni. Ad esempio è possibile studiare le relazioni sociali tra gli individui. In [10] vengono studiate come le implicazioni della mobilità e delle interazioni sociali degli individui siano in relazione con lo sviluppo socio-economico di un territorio. Gli autori osservano come due indici, mobility volume, ossia la distanza caratteristica percorsa
dagli individui, e mobility diversity, diversificazione dei viaggi dell’utente, siano fortemente correlati con gli indicatori economici (reddito procapite e deprivation index). Grazie alla disponibilità di dati sull’intero territorio nazionale francese, in [10] il modello osserva tali relazioni su una scala prima non osservata.
Collocazione della tesi nello stato dell’arte Nella tesi proponiamo di utilizzare i Call Detail Record (CDR) poiché questi ci permettono di analizzare le presenze sul territorio ad una diversa granularità spaziale e temporale. Il cellulare è utilizzato dalle persone in ogni momento della giornata, a prescindere dal mezzo di trasporto su cui si trovano. Nella tesi ci avvaliamo della applicazione della metodologia del Sociometro [8] che ricordiamo consente di arricchire semanticamente l’informazione di chiamata con una etichetta associata al comportamento di un utente sul territorio (es. residente, visitatore, etc.). Il caso di studio che andiamo a mostrare riguarda un’area della Toscana nella quale abbiamo la possibilità di raccogliere una discreta quantità di dati. Grazie al dataset a nostra disposizione, riusciamo a raccogliere informazioni di persone che, per esempio, partecipano ad un evento senza spostarsi con un mezzo di locomozione, contrariamente da come potrebbe succedere se analizzassimo un altro tipo di fonte di dati di localizzazione, come le tracce GPS.
Il principale risultato del progetto di tesi è un’estensione del sopracitato framework UMA. Vogliamo arricchire le informazioni sui percorsi delle persone che ci vengono fornite da questo strumento con quelle relative alle presenze rilevate tramite dati GSM. In questo modo otteniamo le informazioni anche per quegli utenti che non viaggiano in macchina e che quindi utilizzano mezzi di trasporto alternativi oppure vanno a piedi. Tramite questa integrazione vogliamo ottenere il "Libretto della mobilità di un territorio", ossia uno strumento in grado di restituire una visione totale della mobilità.
La tesi propone l’uso dei Big Data per superare gli svantaggi delle tradizionali fonti di dati causati dalla mancanza di tempestività, dai ritardi temporali e dalla limitata copertura spaziale. Nel contesto delle city dynamics, è importante definire nuovi strumenti per la pianificazione, la misura dell’attrattività e delle interazioni tra le città. La sfida è quella di applicare metodologie di demografia real-time per osservare la presenza ed il flusso degli individui. Questa tesi mira a dimostrare in un modo tangibile come i dati telefonici sono uno strumento utile per misurare sistemi complessi. Il lavoro svolto durante la tesi è anche un contributo per perseguire gli obiettivi nell’Ecosistema di Social Mining & Big Data proposto dall’infrastruttura di ricerca SoBigData.eu, in particolare nell’ambito dell’esploratorio City of Citizens 4 il
quale ha come obiettivo quello di raccontare ai cittadini e agli amministratori del territorio le dinamiche urbane.
4
1.2
Data sources
Per lo svolgimento della tesi sono state utilizzate diverse fonti di dati. La prima sorgente è stata il traffico telefonico, la seconda le informazioni geografiche per suddividere il territorio ricavate dalla Agenzia del Catasto presso l’Agenzia delle Entrate5, infine le informazioni sui punti di interesse raccolte da OpenStreetmap6.
La descrizione dei vari tipi di dati coinvolti sarà molto utile sia nel Capitolo 2 per giustificare le scelte di progettazione della piattaforma effettuate, sia nel Capitolo 3 per avere maggior coscienza del processo di trasformazione dei dati.
Dati di telefonia mobile GSM (Call Detail Record) Gli operatori telefo-nici raccolgono le informazioni sulle attività di telefonia mobile svolte dai loro utenti (chiamate, SMS, traffico dati) sotto forma di dati di fatturazione. Per il progetto sono stati utilizzati solo i dati riguardanti le chiamate effettuate dagli utenti, ossia i Call Detail Record (CDR). Al loro interno abbiamo informazioni come il timestamp, l’identificatore anonimo dell’utente, l’antenna da cui è partita la chiamata e la sua durata. Per cui abbiamo informazioni sulle attività degli utenti ad una granularità spaziale dell’antenna telefonica.
Per un’attività di analisi della mobilità, questo tipo di dati è molto utile perché permette di rilevare la presenza degli utenti rispetto ad un luogo e ad un periodo. Questo aspetto è utile per rilevare picchi di presenza in prossimità di eventi, rico-struire in modo approssimativo i movimenti effettuati dagli utenti e cercare una loro profilazione.
I dati a nostra disposizione sono stati forniti da un importante operatore telefonico ed hanno una copertura spaziale che riguarda le province di Firenze, Livorno, Lucca e Pisa su una finestra temporale di un mese (dal 1 novembre 2015 al 30 novembre 2015). Il dataset contiene informazioni circa l’identificativo utente, l’antenna dalla quale è partita la chiamata, il momento in cui è stata effettuata e la sua durata. Invece, non sono disponibili le informazioni riguardanti il destinatario della chiamata. I limiti di questo tipo di dati sono che la posizione dell’utente è nota a livello di antenna e solo quando questo effettua una chiamata; poi le chiamate possono essere distribuite in modo sparso nel tempo, questo significa che non possiamo conoscere la posizione dell’utente tra 2 chiamate consecutive.
Osservatorio del Mercato Immobiliare (OMI) Le geografie utilizzate dalla Agenzia delle Entrate per identificare le Aree omogenee immobiliari (OMI). La suddivisione in aree OMI è disponibile per tutto il territorio nazionale e si presenta molto simile a quella dei quartieri. In aggiunta le informazioni economiche sono
5http://www.agenziaentrate.gov.it/ 6https://www.openstreetmap.org/
timestamp tower caller duration 2007/09/10 23:34 36 4F80460 120 2007/10/10 01:12 36 2B01359 10 2007/10/10 01:43 38 2B19935 301 .. . ... ... ...
(a) Call Detail Record
tower latitude longitude
36 49.54 3.64 37 48.28 1.258 38 48.22 -1.52 .. . ... ... (b) Geodata
Tabella 1.1: Esempio di Call Detail Record (CDR). Ogni volta che un utente effettua una chiamata, viene creato un record con timestamp, l’antenna che serve la chiamata, l’identificativo di chi effettua la chiamata e la durata (a). Per ogni antenna, sono disponibili le coordinate di latitudine e longitudine per mappare l’antenna sul territorio (b).
Figura 1.1: Dettaglio della traiettoria di un singolo utente. Le antenne sono indicate con dei punti grigi, ed il reticolo di Voronoi in grigio approssima le aree di ricezione delle antenne. I CDR registrano l’identità dell’antenna più vicina ad un utente; quindi non possiamo identificare la posizione di un utente all’interno di una cella di Voronoi. La traiettoria descrive i movimenti dell’utente durante 4 giorni (un colore diverso per ogni giorno). L’antenna dove l’utente effettua il maggior numero di chiamate durante le ore notturne è indicata in grigio scuro.
interessanti dal punto di vista socio-economico, perché consentono di osservare le relazioni tra le presenze e il costo delle abitazioni.
Le quotazioni immobiliari effettuate a cadenza semestrale vanno a definire delle zone territoriali omogenee per ogni comune usando strumenti per la valutazione
immobiliare (come cartografia catastale, carta tecnica del suolo, carta toponomastica, strumento urbanistico vigente, dati sul patrimonio edilizio, dati sui valori immobiliari). Per ogni zona si ha un intervallo minimo/massimo dei valori di mercato e locazione per unità di superficie in euro al mq, per tipologia immobiliare e stato di conservazione. Le quotazioni OMI, disponibili in un semestre, sono relative ai comuni censiti negli archivi catastali.
Figura 1.2: Suddivisione in zone OMI del comune di Pisa. Ogni zona è rappresentata con un colore diverso e possiede l’etichetta del suo identificativo. Dalla figura è possibile osservare come le zone OMI coincidano con i quartieri, per esempio è possibile visualizzare una netta suddivisione tra mezzogiorno e tramontana.
L’Agenzia delle Entrate per ogni provincia ripartisce il territorio comunale in fasce: • Centrale (codice B) • Semicentrale (codice C) • Periferica (codice D) • Suburbana (codice E) • Extraurbana (codice R)
Ogni zona OMI è identificata tramite un codice alfanumerico formato da una lettera corrispondente alla fascia di appartenenza ed un numero identificativo della zona (per esempio: fascia centrale B zona 1 = B1). Oltre l’identificativo, la zona OMI può contenere anche una breve descrizione del quartiere, come ad esempio il suo nome. Per ogni zona vengono fornite delle quotazioni immobiliari in base alla destinazione degli immobili, quindi per ogni tipologia immobiliare che possono essere:
• Residenziale (Abitazioni civili, Abitazioni di tipo economico, Abitazioni signorili, Abitazioni tipiche dei luoghi, Ville e villini);
• Commerciale (Magazzini, Negozi, Centri commerciali, Pensioni e assimilati, Fabbricati e locali per esercizi sportivi);
• Terziaria (Uffici, Uffici strutturati)
• Produttiva (Laboratori, Capannoni tipici, Capannoni industriali); • Parcheggi (Box, Posti auto coperti, Posti auto scoperti, Autorimesse).
Nelle quotazioni abbiamo informazioni anche riguardo lo stato di conservazione e manutenzione prevalente degli immobili per tipologia.
La suddivisione di un territorio in zone OMI può essere scaricata tramite il servizio di navigazione territoriale Geopoi7, fornito dall’Agenzia delle Entrate, indicando l’area di interesse (Menu "Download Perimetri"). Le geometrie vengono rilasciate gratuitamente per scopi di studio o di ricerca previa richiesta motivata. I dati sono rilasciati in formato KML o GML e contengono le ripartizioni dei territori nel semestre di riferimento. Per il nostro caso di studio, sono state scaricate le geometrie della suddivisione in zone OMI della regione Toscana per il secondo semestre 2016, che sono rimaste le stesse del 2015, periodo di nostro interesse. Invece, per quanto riguarda le quotazioni, sono state fornite informazioni sui comuni della Toscana per ogni semestre dal 2002 al 2016. Per ognuno abbiamo i valori minimo/massimo di mercato, i valori minimo/massimo di locazione, insieme alle descrizioni della zona OMI, tra cui l’indicazione della regione, provincia e comune, quindi della tipologia degli immobili e lo stato conservativo.
I valori analizzati sono quelli relativi al secondo semestre del 2015 perché coincidenti col periodo di rilevamento dei dati GSM a nostra disposizione.
Point Of Interest I POI utilizzati sono stati raccolti da Geofabrik8 che prende
i dati dal progetto OpenStreetMap, i quali di norma vengono aggiornati giornalmente. È possibile effettuare il download dei dati in diversi formati (.osm.pbf, .shp.zip, .osm.bz2), a diverse granularità partendo dal livello più alto dei continenti fino ad arrivare alle sub-region intese come il livello inferiore agli stati.
Nel nostro caso specifico, sono stati presi i dati del centro Italia, che comprendono le regioni di Toscana, Marche, Umbria e Lazio. Per la rappresentazione grafica abbiamo usato gli shapefile del centro Italia scaricati dal server9 che conteneva
l’indicazione di POI a punti, a linee e come poligoni. Per ogni forma di POI abbiamo
7
http://wwwt.agenziaentrate.gov.it/geopoi_omi
8
http://download.geofabrik.de/index.html
l’indicazione di vari attributi, tra cui quello riguardante la tipologia del punto di interesse.
Per una scelta grafica abbiamo deciso di utilizzare solo le geometrie dei POI a punti, i quali presentavo originariamente 191 tipologie distinte rendendo la loro manipolazione alquanto complicata. Per cui, abbiamo selezionato solo alcune tipologie di punti di interesse e le abbiamo classificate in base alla categoria secondo le classi utilizzate da OpenStreetMap10 in: Hotel, Restaurant, Sport, Tourism.
Figura 1.3: Visualizzazione del portale OpenPoiMap. Su questa vista è possibile vedere le macrocategorie usate da OpenStreetMap per classificare i POI, nel cursore in alto a sinistra. Per ognuna di queste, nel menu a destra vengono mostrate le relative sottocategorie da selezioare e visualizzare sulla mappa.
1.3
Tecnologie
In questa Sezione indichiamo le metodologie e gli strumenti applicati per svilup-pare il progetto di tesi. In Sezione 1.3.1 descriviamo la metodologia utilizzata per classificare i comportamenti telefonici delle persone. In Sezione 1.3.2 elenchiamo le tecnologie impiegate durante lo sviluppo del progetto.
1.3.1
Metodologie
Qui, descriviamo la metodologia utilizzata per profilare gli utenti descritti dai CDR a nostra disposizione (Sezione 1.2). Stiamo parlando della tecnica di categorizzazione degli utenti denominata Sociometro, precedentemente riportata in Sezione 1.1, facente riferimento al lavoro di ricerca di Gabrielli et. [8]. Tale metodologia viene utilizzata come uno strumento per estrarre conoscenza da un dataset di dati telefonici, allo
scopo di comprendere in che modo gli utenti utilizzino il territorio, ovvero se siano essi residenti, visitatori o lavoratori.
Sociometro La tecnica qui descritta consiste in un processo di Data Mining utilizzato per classificare gli utenti che insistono su un territorio. Le classi che associamo agli utenti sono sempre in relazione ad una zona d’analisi (A) e possono essere:
• Residente, per gli utenti che vivono e lavorano dentro A;
– Residente dinamico, è una specializzazione dei residenti. Viene associata questa classe agli utenti che vivono in A e lavorano in un’altra area B; • Pendolare, quando l’utente lavora in A ma la sua residenza è in un’altra area
B;
• Visitatore, per gli utenti che si presume non abbiano né la residenza né il posto di lavoro in A ma, soprattutto, che hanno effettuato chiamate per un periodo limitato di tempo.
– Passante, è una sotto-categoria dei visitatori e definisce gli utenti che effettuano una chiamata singola o comunque un numero veramente esiguo di chiamate.
Nello specifico ogni CDR grezzo è trasformato in un Individual Call Profile (ICP), ossia un profilo del comportamento dell’utente. Gli ICP possono essere rappresentati come delle matrici (Figura 1.4) in cui vengono aggregate le chiamate per le settimane del mese, ed ogni giorno della settimana in giorni feriali e giorni festivi. Per esempio, se consideriamo le chiamate effettuate in un mese in cui abbiamo quattro settimane, la matrice avrà otto colonne, ossia 2 colonne per settimana, una per i giorni feriali ed una per quelli festivi. Inoltre, ogni colonna è divisa in diverse righe, una per ogni periodo del giorno che prendiamo in considerazione. Nell’esempio sono identificati tre intervalli temporali, uno corrispondente alle chiamate effettuate al mattino (00:00 - 08:00), uno relativo alla fascia lavorativa (08:00 - 19:00) e un ultimo relativo all’intervallo serale (19:00 - 24:00). Nell’esempio di Fig 1.4 l’intensità del colore di ogni cella della matrice indica il numero di presenze rilevate in ogni timeslot.
La costruzione degli ICP dai CDR è solo la prima delle fasi che compongono il processo analitico (Fig 1.5). La seconda fase prevede il raggruppamento degli ICP simili utilizzando l’algoritmo K-means. I k centroidi, chiamati stereotipi, definiscono i comportamenti tipici degli utenti. Nella terza fase l’esperto del dominio attribuisce manualmente un’etichetta ai k stereotipi. Infine, nella quarta ed ultima fase avviene la propagazione delle etichette agli utenti in ogni cluster.
Figura 1.4: Individual Call Profile (ICP). Sulla sinistra abbiamo un ICP su 4 settimane con 8 colonne (2 colonne per ogni settimana, una per i feriali Week days ed una per i festivi Week end) e 3 righe, corrispondenti a 3 fasce orarie (P1=[00:00-08:00); P2=[08:00-19:00); P3=[19:00-24:00)).
Figura 1.5: Sociometro. Rappresentiamo graficamente le 4 fasi che portano dai CDR grezzi alla costruzione di un modello di classificazione degli utenti rispetto la zona in cui vengono rilevati. La fase 1 consiste nel processo di ICP Building, la fase 2 prevede la Prototypes Extraction, durante la fase 3 avviene la Prototypes Labeling, infine, nella fase 4 abbiamo la Label Propagation per gli utenti in ogni cluster.
1.3.2
Strumenti per lo sviluppo
In questa Sezione mostriamo tutte le tecnologie utilizzate durante lo sviluppo del progetto. Dividiamo le tecnologie utilizzate in base alla destinazione d’uso.
Dapprima troviamo quelle che sono state necessarie per l’implementazione del sistema di archiviazione dei dati e per la computazione degli indicatori sulle presenze. Quindi, descriviamo gli strumenti utilizzati per la manipolazione dei dati geometrici di cui abbiamo usufruito per contestualizzare gli indicatori sulle presenze. Infine, indichiamo gli strumenti che sono serviti per permettere la visualizzazione dei risultati delle nostre analisi tramite viste web.
Sistemi di archiviazione e di computazione dei dati
• Apache Hadoop11 framework utilizzato per la materializzazione del Data
Ware-house, facilita le operazioni di storage e gestione dei Big Data utilizzando Hadoop Distributed File System (HDFS) per l’archiviazione. Il framework permette la memorizzazione di dati ridondanti avendo cura degli errori, le computazioni parallele e la coordinazione del lavoro. In questo modo, non dobbiamo preoccuparci dell’allocazione o di come dobbiamo gestire le eccezioni o le perdite dei dati, è il framework ad occuparsi di organizzare la divisione delle computazioni e lo scaling dei dati.
• Spark12, framework open source per il calcolo distribuito. Le tecnologie di
questo tipo permettono di caricare dati in un gruppo di memorie e interrogarli ripetutamente in modo più performante rispetto al paradigma di MapReduce utilizzato da Hadoop, che abbiamo utilizzato solo come sistema distribuito di archiviazione.
• apiDoc13, grazie a questo strumento è stato possibile creare la documentazione
delle nostre API tramite l’utilizzo di appositi Tag a corredo del codice sorgente. • Flask14, un microframework di Python, basato su Werkzeug15 e Jinja216, il
primo è una libreria per la gestione del protocollo WSGI, mentre il secondo è un motore di templating molto utilizzato e performante. Con il termine micro si intende che il framework è essenziale, ossia permette di definire le funzionalità di cui si ha bisogno dando la possibilità di aggiungerne delle altre all’occorrenza. In questo modo è possibile gestire il sistema in base alla performance e alla sicurezza richiesta. Questo microframework è molto utilizzato per la creazione di applicazioni web estremamente verticali, ottimizzate, modulari, estensibili.
11http://hadoop.apache.org/ 12https://spark.apache.org/ 13http://apidocjs.com/ 14http://flask.pocoo.org/ 15http://werkzeug.pocoo.org/ 16http://jinja.pocoo.org/
Strumenti per la manipolazione di dati geometrici
• Open Source QGis17 è un’applicazione Desktop per la manipolazione di dati
GIS18. L’applicazione accetta diversi formati di dati per permettere analisi
territoriali. I dati vengono organizzati in layer personalizzabili dall’utente. QGis prevede anche un sistema di scripting per permettere operazioni sui dati. • PostgreSQL19 è un DBMS ad oggetti rilasciato con licenza libera. Per eseguire
query sui dati utilizza il linguaggio SQL. I dati sono conservati in tabelle con chiavi esterne che servono per collegare i dati correlati.
• PostGIS20 è un’estensione spaziale per il database PostgreSQL. É un
geodata-base che fornisce il sistema di gestione dati sui quali è basato un GIS.
• TopoJSON21 è un formato derivato da GeoJSON22 che archivia topologie
spaziali. Il formato codifica strutture di dati geografici come Point, LineString, Polygon, MultiPoint, MultiLineString e MultiPolygon. Una caratteristica aggiuntiva è che unisce le geometrie che condividono archi imponendo la loro rappresentazione una volta sola, mantenendo comunque le informazioni relative ai diversi layer di cui fanno parte. Il TopoJSON consente di aggregare su più livelli le geometrie di base ovvero le zone OMI, consentendo di fondere i layer in modo efficiente.
Strumenti per la visualizzazione grafica
• d3.js23 è una libreria javascript che permette di realizzare visualizzazioni
dina-miche ed interattive partendo da dati organizzati, utilizzando standard web come SVG24, HTML525 e CSS26.
• Bootstrap27, utile per lo sviluppo di pagine web Mobile-friendly, che contiene
modelli di progettazione basati su HTML e CSS, sia per la tipografia, che per le varie componenti di interfaccia.
• Leaflet28, una libreria scritta in Javascript mobile-friendly che viene utilizzata
per la costruzione di mappe interattive.
17
https://www.qgis.org/it/site/
18Sistema per memorizzare, analizzare, manipolare e rappresentare dati di tipo geografico. 19 https://www.postgresql.org/ 20 https://postgis.net/ 21 https://github.com/topojson/topojson 22 http://geojson.org/ 23 https://d3js.org/
24Scalable Vector Graphics una tecnologia per la rappresentazione di oggetti di grafica vettoriale. 25Linguaggio di marcatura utilizzato per realizzare la struttura di pagine web.
26Linguaggio usato per definire la formattazione di pagine web. 27https://getbootstrap.com/
Capitolo 2
Mobility Atlas Booklet:
Progettazione
La tesi propone lo sviluppo del Mobility Atlas Booklet (MAB) di un territorio, un’interfaccia che fornisce indicatori interessanti riguardanti le presenze dei diversi tipi di utente su un territorio. MAB ha la funzione di costruire un prospetto dei comportamenti rilevati su un territorio per riuscire a fornire informazioni utili sul suo utilizzo.
MAB è stato implemento come una web application che permette di selezionare un’area geografica e di visualizzare degli indicatori interessanti riguardanti le presenze di utenti stratificate per residenti, lavoratori o turisti. L’applicazione permette di osservare le informazioni sulle presenze dei diversi tipi di utente a diversi livelli di granularità spaziale, partendo dal livello regionale e scendendo fino al livello minimo di granularità definito dalle aree omogenee immobiliari (OMI) introdotte in Sezione 1.2. Il fatto di analisi prenderà in considerazione diversi livelli di aggregazione temporale.
In questo capitolo, vengono descritte le scelte progettuali. In particolare in Sezione 2.1 definiamo il problema, nella Sezione 2.2 mostriamo l’analisi dei requisiti. Infine nella Sezione 2.3, mostriamo come è stato realizzato il Data Warehouse, evidenziando la progettazione concettuale, logica e le tecnologie che abbiamo utilizzato per implementarlo.
Nel prendere le decisioni progettuali ivi descritte ho messo in pratica le mie conoscenze in campo di progettazione di Basi di Dati per il Supporto delle Decisioni. Ed ho imparato a lavorare con sistemi software con archivi di dati distribuiti che sfruttano il paradigma NoSQL1.
1NoSQL è un paradigma che descrive metodi di implementazione di sistemi di archiviazione dati
non relazionali. Gli archivi di dati sviluppati con tecnologie NoSQL non richiedono uno schema fisso.
2.1
Definizione del problema
Nel Capitolo 1 abbiamo mostrato i diversi ambiti di applicazione in cui lo studio e la gestione della mobilità delle persone risulta molto importante. Abbiamo mostrato anche come tale problema può essere affrontato grazie all’analisi delle tracce digitali rilasciate con i diversi dispositivi mobili che contengono GPS o attraverso l’uso dei social media. La tesi propone uno strumento utile per rispondere a tre principali domande:
1. Quante persone sono presenti sul territorio? 2. Qual è la destinazione d’uso del territorio?
3. Quali sono i periodi in cui è più visitato il territorio?
Il principale limite osservato delle sorgenti dato GPS riguarda la difficoltà di reperi-mento degli stessi e il loro indice di penetrazione, dato che non sono presenti su tutti i veicoli in circolazione. In aggiunta questi dispositivi osservano la mobilità delle persone solamente durante la marcia. Per superare questo limite e rispondere alla domanda 1, poiché la quasi totalità della popolazione possiede almeno un dispositivo cellulare e lo utilizza in ogni fase della giornata, proponiamo l’utilizzo dei dati di telefonia mobile.
Per poter rispondere alla domanda 2, dobbiamo essere capaci di analizzare i dati secondo due dimensioni, quella temporale e quella spaziale. Ad aiutarci è proprio la natura dei dati a nostra disposizione, visto che questi contengono informazioni sia sul luogo che sul momento in cui un utente effettua una chiamata. I dati di chiamata (CDR) presi singolarmente non riescono a fornirci informazioni significative per i nostri scopi, pertanto applichiamo su questi dati la metodologia del Sociometro [8] allo scopo di estrarre l’informazione sulla tipologia di utenti presenti sul territorio in analisi. Tale trasformazione dei dati di input è utile per ricostruire le distribuzioni giornaliere di presenza stratificate per categoria di popolazione (residente, lavoratore, visitatore).
Avere a disposizione la distribuzione giornaliera delle presenze può essere utile per la gestione del turismo e degli eventi, per verificare se un determinato evento ha attratto molte persone o per controllare quali sono i periodi in cui vi è più affluenza turistica. Risponderemo alla domanda 3, attraverso il monitoraggio dei picchi nella distribuzione. Grazie al Sociometro [8] possiamo costruire serie temporali rispetto alla categoria dell’utente ossia sul ruolo che l’utente ha su un territorio. Le rilevazioni di picchi di presenze di utenti ci raccontano storie diverse in base alla categoria di questi ultimi. Per esempio, in corrispondenza di un evento, sapere se gli affluenti nel territorio sono dei residenti o dei visitatori occasionali aiuta a verificare l’attrattività dell’evento.
L’uso delle serie temporali ci pone un altro quesito: quale è la granularità spaziale rispetto alla quale calcolarle? Uno dei problemi affrontati durante lo sviluppo del lavoro è stata la scelta del livello minimo di granularità spaziale. Gli studi effettuati finora si sono fermati al livello comunale, per cui ci siamo domandati come poter scendere al di sotto di questo. Per effettuare un’analisi sul territorio adeguata sarebbe utile riuscire ad analizzarlo a livello di quartiere, per cercare di gestire i problemi locali che a livello comunale non sono facilmente rilevabili. Mentre effettuare analisi ad un livello di granularità troppo basso, come le zone censuarie fornite dall’ISTAT, porterebbe ad ottenere risultati poco interessanti.
2.2
Analisi dei Requisiti
Partendo dalle analisi di contesto effettuate, mostriamo il processo di raccolta dei requisiti del sistema. Abbiamo fissato per ognuno di essi le dimensioni, le misure e le metriche rispetto le quali vogliamo ottenere le informazioni (Tabella 2.1). Le dimensioni che abbiamo deciso di modellare sono tre: Utente, Data e Luogo. Dopo aver descritto le caratteristiche delle dimensioni di analisi riportiamo le caratteristiche della tabella dei Fatti Presenze.
Requirements Dimensions Measures Metrics
Quante persone sono Utente, Numero di Count degli user ID, presenti sul territorio? Luogo utenti aggregati in base
alla zona in analisi. Qual è la destinazione Utente, Numero di Count degli user ID d’uso del territorio? Luogo utenti in una zona, rispetto
le categorie d’utente. Quali sono i periodi Utente, Numero di Count degli user ID in cui è più visitato Luogo, utenti sulla categoria e sui
il territorio? Data periodi in una zona.
Tabella 2.1: Dimensioni, misure e metriche preliminari, necessarie per rispondere ai nostri requisiti. Viene analizzato ogni requisito per identificare le misure del fatto e su quali dimensioni calcolare le metriche.
Utente La dimensione Utente consente di classificare le presenze rilevate su un territorio in base ai comportamenti di chiamata. Tale dimensione, mostrata in Tabella 2.2, possiede un unico attributo, che può assumere solo cinque valori (Residente, Pendolare, Residente dinamico, Visitatore e Passante), corrispondenti alle label risultato del processo di classificazione Sociometro [8] che, come descritto in Sezione 1.3.1, vengono assegnate agli utenti in base ai loro comportamenti su un territorio. Quindi, la dimensione ci serve per navigare il fatto in base alle classi degli utenti.
Nome Descrizione Categoria Può avere come valore:
Residente, Pendolare, Residente dinamico, Visitatore, Passante
Tabella 2.2: Dimensione Utente. La dimensione presenta un solo attributo che può assumere i valori corrispondenti alle classi restituite dal Sociometro [8] applicato sul dataset dei CDR.
Data La dimensione Data ci consente di navigare il fatto di analisi rispetto a una gerarchia temporale per il calcolo delle serie temporali di presenza sul territorio. La dimensione Data fornisce le informazioni per permettere due tipi di aggregazione temporale dei dati: la prima formata dagli attributi anno, mese e giorno per consentire un analisi dei comportamenti fino a livello giornaliero; mentre la seconda composta dal giorno della settimana e l’ora per poter osservare le presenze e ricostruire la settimana tipica degli utenti in un territorio. La Tabella 2.3 fornisce una descrizione aggiuntiva degli attributi che formano questa dimensione, mentre la Tabella 2.4 mostra che è presente una gerarchia all’interno di essa. La gerarchia lega gli attributi Ora, Giorno, Mese e Anno.
Nome Descrizione
Ora L’orario in cui sono state rilevate le presenze all’interno
del fatto, nel formato YYYY-MM-DD-HH. Giorno Il riferimento al giorno in cui
sono state rilevate le presenze all’interno del fatto, nel formato YYYY-MM-DD. Mese L’indicazione del mese in cui
sono state rilevate le presenze all’interno del fatto, nel
formato YYYY-MM. Anno L’anno in cui sono state
rilevate le presenze all’interno del fatto, nel formato YYYY. Giorno della settimana Il giorno della settimana in
cui sono state rilevate le presenze all’interno del fatto,
da 0 a 6.
Tabella 2.3: Dimensione Data. Descriviamo i suoi attributi, indicando anche il formato con cui questi vengono riportati.
Dimensione Descrizione Tipo Data Ora -> Giorno -> Mese -> Anno Balanced
Tabella 2.4: Gerarchia della dimensione Data. La gerarchia temporale descritta è di tipo Balanced, questo significa che i livelli possibili vengono decisi preliminarmente e i valori degli attributi sono sempre definiti.
Luogo Questa dimensione ci consente di navigare il fatto di analisi rispetto a una dimensione spaziale. Le granularità scelte vanno dal livello Regionale fino ad un livello di granularità minimo definito dalle aree denominate Aree Omogenee Immobiliari (OMI) descritte nella Sezione 1.2. La descrizione completa degli attributi di questa dimensione è indicata in Tabella 2.5. Si ricordano brevemente le motivazioni che ci portano a utilizzare come livello di granularità OMI, ovvero la necessità di suddividere il territorio comunale in aree di dimensione superiore alle zone di censimento e il più simile possibile ai quartieri amministrativi. La Tabella 2.6 indica l’organizzazione della gerarchia di navigazione rispetto la dimensione spaziale.
Nome Descrizione
OMI L’identificativo della zona OMI. Comune Il riferimento al comune associato. Provincia Il riferimento alla provincia
del comune associato alla OMI. Regione L’indicazione della regione in cui
si trova la provincia associata alla OMI.
Tabella 2.5: Dimensione Luogo. Gli attributi descritti contengono le informazioni sui diversi livelli spaziali.
Dimensione Descrizione Tipo
Luogo OMI -> Comune -> Provincia -> Regione Balanced
Tabella 2.6: Gerarchia della dimensione Luogo. La gerarchia parte dal livello minimo di granularità spaziale OMI fino ad arrivare al livello massimo Regionale.
Tabella dei Fatti: Presenze In base all’analisi dei requisiti svolta, abbiamo definito come Fatto di analisi le informazioni riguardanti il numero di Presenze rilevate con granularità minima spaziale la tesselazione OMI a granularità temporale oraria. In Tabella 2.7 sono indicati il fatto, le misure e le dimensioni associate ad esso. L’entità di cui stiamo parlando ci aiuta a quantificare il numero di presenze rilevate rispetto alle tre dimensioni descritte nei paragrafi precedenti. Per questo motivo all’interno del fatto troviamo la misura nUtenti, descritta in Tabella 2.8, la
quale è non calcolata e non additiva. Infatti, tale misura è ricavata come COUNT DISTINCT degli identificativi degli utenti riferiti alla combinazione delle dimensioni spazio-temporali. La granularità minima sulla quale è calcolato il Fatto in analisi sono l’ora per la dimensione temporale e la zona OMI a livello spaziale. Per rispondere ai requisiti definiti in Sezione 2.2 il calcolo del numero di utenti rilevati deve dipendere anche dalla categoria di questi ultimi.
Abbiamo implementato la misura come non additiva perché vogliamo contare uno stesso utente un’unica volta nello stesso momento temporale in due zone geografiche diverse. Come riferito in [1], Sezione 2.1, le misure non additive non possono essere aggregate tramite la funzione SUM per nessuna dimensione. Mostreremo in Sezione 2.3, all’interno del paragrafo sulla progettazione fisica come abbiamo superato questo limite.
Fatto Misure Dimensioni
Presenze sul territorio nUtenti Data, rilevate in una OMI, in (Numero di utenti) Luogo,
una certa fascia oraria Utente
in base alla categoria degli utenti.
Tabella 2.7: Tabella dei Fatti Presenze. Descrizione del Fatto ed indicazione delle sue Misure e delle sue Dimensioni.
Nome Descrizione Aggregabilità Calculata
nUtenti Numero di utenti rilevati Non Additiva No alla minima granularità
spaziale e temporale
Tabella 2.8: Misura del Fatto. Descrizione della misura del fatto nUtenti, identificata durante l’analisi dei requisiti. Per la misura indicata indichiamo il suo grado di aggregabilità e se questa è il risultato di un calcolo.
2.3
Disegno del Data Warehouse
In questa sezione mostriamo il percorso di progettazione che ha portato alla realizzazione del Data Warehouse, attraverso la descrizione delle fasi riguardanti la progettazione concettuale, logica e fisica.
Progettazione concettuale A seguito dell’analisi dei requisiti, abbiamo proget-tato concettualmente il Data Warehouse di Figura 2.1 mantenendo le dimensioni e la misura definiti preliminarmente. Questo tipo di progettazione serve come tramite
tra l’analisi dei requisiti e lo sviluppo del Data Warehouse fisico, per formalizzare le decisioni prese durante la fase precedente. La progettazione riporta al centro il Fatto (Presenze) definito in Sezione 2.2 con la misura nUtenti che rappresenta la misura calcolata relativa al numero di utenti distinti presenti rispetto alla granularità minima definita. La tabella dei Fatti Presenze è messa in relazione con le tre tabelle dimensionali:
• Dimensione Utente: il suo unico attributo Categoria descrive la classe con la quale l’utente viene etichettato dalla metodologia Sociometro [8] a causa del suo comportamento telefonico rispetto ad una zona.
• Dimensione Data: riporta la gerarchia temporale (Sezione 2.2) tramite gli attributi Giorno della settimana e Ora, dalla quale possiamo risalire fino all’informazione sull’Anno, passando dal Giorno e dal Mese.
• Dimensione Luogo: contiene la gerarchia spaziale descritta in Sezione 2.2 che parte dal livello OMI e arriva a quello Regione, passando dal Comune e dalla Provincia.
Inoltre, la progettazione concettuale mette in evidenza rispetto quali dimensioni vogliamo effettuare i calcoli necessari per rispondere alle domande che ci siamo posti nella Sezione 2.1. Navigando le tre dimensioni possiamo avere informazioni sul numero di persone presenti su un territorio, sul tipo di persone rilevate su un territorio e su quando queste incidono su un territorio.
Figura 2.1: Risultato della progettazione concettuale del Data Warehouse. Il fatto si trova al centro dello schema a stella. Alla tabella dei fatti sono collegate le tre dimensioni. Le gerarchie dimensionali vengono indicate con delle frecce invece che con degli archi semplici come avviene per gli altri attributi.
Progettazione logica La progettazione logica prevede il disegno logico relazionale delle tabelle all’interno del Data Warehouse. Questo tipo di progettazione serve per stabilire le linee guida che verranno utilizzate durante l’implementazione fisica del Data Warehouse. Nel nostro caso, è stato utilizzato uno schema a stella, al cui centro
è posto il Fatto di analisi, Presenze, che contiene le relazioni uno a molti con le altre tabelle delle dimensioni.
La nostra progettazione, prevede per ogni dimensione (Data, Comune, Utente) una tabella con una chiave primaria e gli attributi che abbiamo definito per ognuna nella Sezione 2.2. Invece, nella tabella dei Fatti chiamata Presenze in ogni record è presente la misura nUtenti e le chiavi esterne che lo collegano alle tabelle delle dimensioni. La misura nUtenti viene calcolata come il conteggio degli utenti distinti presenti nell’intervallo spaziale e temporale individuato e appartenenti ad una determinata categoria d’Utente.
La progettazione logica finale del Data Warehouse è mostrata in Figura 2.2 in cui vengono mostrate le sue tabelle e le relazioni tra di esse.
Figura 2.2: Risultato della progettazione logica del Data Warehouse. Associate alla tabella del fatto troviamo le tabelle delle dimensioni Data, Luogo e Utente tramite delle chiavi esterne.
Progettazione fisica In questo paragrafo descriviamo la tecnologia che abbiamo deciso di utilizzare per l’implementazione fisica del DataWarehouse. Per i nostri scopi, l’uso di un tradizionale DBMS relazionale non sarebbe stato adatto e performante. Quindi, abbiamo deciso di adottare il sistema di archiviazione dati distribuito HDFS fornito dal framework Hadoop. Questo tipo di sistemi, sono molto utili per gestire grandi data set specialmente quelli per cui non sono previste operazioni di modifica. Inoltre, grazie alla interazione con framework di Big Data Processing è possibile accedere ai dati e effettuare calcoli su di essi in modo performante.
Il sistema di Hadoop interagisce con un layer Spark per realizzare le operazioni di aggregazione. Nelle sezioni precedenti abbiamo anticipato la necessità di calcolare in modo intelligente la misura nUtenti ovvero il numero di utenti distinti che ricade in un certo intervallo spazio-temporale. Per poter effettuare il calcolo del numero di utenti distinti in una certa fascia temporale, a livello di implementazione viene mantenuta la lista degli utenti presenti al minimo intervallo di tempo nel minimo
livello di granularità geografica. In questo modo, è possibile calcolare in modo efficace per le aggregazioni richieste la dimensione del set di utenti distinti presenti ad un certo intervallo t in un dato luogo l. Un esempio di come avviene il calcolo è riportato in Figura 2.3.
Figura 2.3: Esempio di calcolo delle presenze su un periodo ed un’area. Nell’esempio vediamo come in base alla richiesta viene selezionata una finestra spazio-temporale. Notiamo anche come l’utente con identificativo 4, presente nel giorno selezionato sia nell’area B1 che B2 viene contato una volta sola quando effettuiamo l’aggregazione sul comune. Il risultato della richiesta viene calcolato come la cardinalità dell’insieme degli identificativi utente rilevati.
Le scelte implementative prese durante la progettazione della struttura dati ci consentono di sviluppare un sistema di archiviazione senza il bisogno di software DBMS di terze parti. Quindi, la progettazione presentata consente di implementare un sistema di archiviazione dati non proprietario, altamente scalabile, con un impatto minimo sulla struttura dell’applicazione web MAB che abbiamo introdotto all’inizio del Capitolo.
Capitolo 3
Mobility Atlas Booklet: Data
Engineering
A seguito della progettazione del Data Warehouse, in questo capitolo mostriamo l’insieme dei processi analitici che hanno consentito di trasformare le sorgenti di dato in input (Sezione 1.2) in informazioni sulle presenze degli individui sul territorio. L’intero processo di trasformazione del dato è riportato in Fig. 3.1, la quale mostra le varie fasi che hanno portato al popolamento della struttura di archiviazione dei dati.
Uno degli obiettivi del capitolo è quello di evidenziare l’importanza della fase di preparazione dei dati che andranno a popolare il Data Warehouse. Il trattamento e la trasformazione dei dati richiedono molto tempo di elaborazione a causa delle procedure di pulizia dei dati necessarie e alla integrazione degli stessi con tecniche di raccolta e manipolazione adeguate al tipo di dati a disposizione (Sezione 3.1). Inoltre è necessario memorizzare i dati nel formato più efficiente ed efficace per renderli ulteriormente fruibili. Quindi, in Sezione 3.2 mostriamo come è stato realizzato il popolamento del Data Warehouse ovvero come sono state costruite le serie temporali delle presenze sul territorio alla granularità minima.
Le fasi di di Estrazione, Trasformazione e Caricamento dei dati, hanno consentito di acquisire diverse competenze nell’ambito della manipolazione dei dati GIS e di gestione dei sistemi di archiviazione dei dati attraverso sistema Hadoop.
3.1
Data Acquisition
In questa sezione mostriamo quali elaborazioni sono state necessarie sui dati in input descritti in Sezione 1.2. In Figura 3.2 mostriamo l’intero processo di Data Acquisition ovvero come sono raccolti i dati, come sono stati modificati e l’output ottenuto al termine di questa fase. In particolare, in Sezione 3.1.1 descriviamo come abbiamo applicato la metodologia del Sociometro [8] descritta in Sezione
Figura 3.1: Descrizione del processo di Data Engineering. I dati in input sono trattati attraverso due fasi. La Data Acquisition contiene i vari processi di raccolta dei dati. La Data Transformation racchiude i processi di trasformazione dei dati affinché questi possano essere memorizzati nel Data Warehouse.
1.3.1 per estrarre dai dati CDR a nostra disposizione l’informazione riguardante il comportamento telefonico degli utenti e conseguentemente la rispettiva categoria di uso del territorio (residente, lavoratore, visitatore). In Sezione 3.1.2 il trattamento dei dati ha riguardato la raccolta delle geometrie del territorio fornite dall’Agenzia delle Entrate. Mentre in Sezione 3.1.3 mostriamo la raccolta e trasformazione dei punti di interesse rilasciati da OpenStreetMap.
3.1.1
Categorizzazione degli utenti
Per la profilazione degli utenti è stata utilizzata la tecnica descritta in Sezione 1.3.1 ovvero la metodologia del Sociometro [8]. Si ricorda come tale processo di Data Mining sia usato in questa tesi per classificare le tipologie di utenti che insistono in un territorio.
Partendo dai CDR grezzi a nostra disposizione abbiamo classificato gli utenti a livello comunale. La categoria associata a un dato utente per ogni Comune dipende dal comportamento di chiamata che esso ha avuto in ogni municipalità in cui ha effettuato
Figura 3.2: Data Acquisition. Descrizione della fase di Data Acquisition che prende in input i dati grezzi e li sottopone a processi di Data Manipulation. Questa fase restituisce in output sia layer informativi che puramente geometrici.
almeno una chiamata. Un utente telefonico può essere classificato ad esempio nel comune A come Residente e nel comune B come Visitatore. L’informazione sulla categoria dell’utente che effettua la chiamata arricchirà il dato di input fornendoci un’ulteriore chiave di lettura per suddividere le presenze sul territorio per misurare la popolazione insistente.
Nell’esposizione della procedura del Sociometro[8] nella Sezione 1.3.1 abbiamo visto che questa prevede l’intervento di un esperto del dominio che manualmente attribuisce ad ogni stereotipo risultante dal clustering un’etichetta. Il dataset CDR sul quale vogliamo effettuare le nostre analisi ha una dimensione considerevole, comprende circa 70 milioni di CDR, dai quali estraiamo 3.5 milioni di ICP per
1.5 milioni di persone. Pertanto, ci siamo avvalsi di un sistema di computazione automatica che utilizza il paradigma Hadoop/Spark per effettuare la classificazione degli utenti. Questa procedura attribuisce in modo automatico l’etichetta di un archetipo, ossia un modello di comportamento definito a priori, che più si avvicina al comportamento rilevato. Innanzitutto, è stato necessario l’accesso a una macchina di supporto sulla quale è installato il file system di Hadoop, al cui interno sono memorizzati i CDR descritti in Sezione 1.2. Il Sociometro viene applicato su questi dati tramite un programma sviluppato col framework Spark il quale fornisce le implementazioni delle varie funzioni necessarie alla classificazione. Per ottenere la classificazione degli utenti è sufficiente indicare al programma dove si trova la sorgente di dati CDR da profilare, il percorso del file risultato e gli archetipi in base ai quali assegnare le classi di comportamento ai cluster:
python Sociometer.py ’cdr-path’ ’results-path’ ’archetypes’ Il programma restituisce un file nel formato mostrato in Tabella 3.1 in cui troviamo il profilo degli utenti rispetto il comune da cui ha effettuato chiamate.
caller municipality label
4F80460 Pisa visitor 2B01359 Pisa resident 2B19935 Livorno resident 2B19935 Pisa visitor .. . ... ...
Tabella 3.1: Output del Sociometro. La procedura restituisce l’etichetta associata all’utente rispetto ai comuni in cui sono stati calcolati i profili di chiamata (ICP). Si noti come l’utente 2B19935 sia classificato come resident nel comune di Livorno e come visitor in quello di Pisa.
3.1.2
Preparazione del layer spaziale
Data la scelta progettuale di definire la granularità minima del Data Warehouse a livello di quartiere (Sezione 2.2), la sorgente di dati che consente di avvicinarsi a una suddivisione simile è quella rilasciata dalla Agenzia delle Entrate. Si ricorda brevemente che la caratteristica della suddivisione territoriale scelta dipende dal valore omogeneo di vendita degli immobili (OMI Sezione 1.2).
In questa Sezione descriviamo il processo di costruzione del layer spaziale di riferimento per le nostre analisi sulle presenze. In particolare, le geometrie risultato di questa fase servono per implementare nella web application una mappa interattiva che ci consente di navigare gli indicatori sulle presenze. Il processo di manipolazione delle geometrie, ivi descritto, è rappresentato in Figura 3.3. Questo è composto di
diverse fasi che hanno richiesto molto tempo e cura, soprattutto per quanto riguarda le operazioni di data cleaning.
Figura 3.3: Processo di creazione della gerarchia spaziale. In una prima fase avviene il download delle geometrie riguardanti la suddivisione in zone OMI dal portale Geopoi per ogni provincia (a). Quindi, i diversi file vengono uniti in un’unica sorgente (b). La fase (c) racchiude il momento di data cleaning del layer geometrico ed il suo arricchimento con le informazioni necessarie per ricreare la gerarchia spaziale (regione, provincia, comune, OMI). Infine, in (d) viene effettuata la conversione del layer geometrico in file TopoJSON.
a L’Agenzia delle Entrate permette di scaricare le geometrie riguardanti la suddivisione in zone OMI attraverso la piattaforma web Geopoi1. Il formato
per le geometrie disponibili può essere KML2 o GML3. Geopoi consente di
scaricare le geometrie delle OMI per comune o per provincia. Pertanto, una volta scaricati, è necessaria una fase di unione dei dataset in un’unica tabella. b Sono state scaricate le geometrie, separatamente per ogni provincia Toscana, in
formato KML e trasformate in un unico shapefile4 dell’intera regione tramite
un plugin che permette il MERGE di layer geometrici fornito dall’applicazione
1
http://wwwt.agenziaentrate.gov.it/geopoi_omi
2(Keyhole Markup Language) è un linguaggio basato su XML creato per gestire dati geospaziali
in tre dimensioni nei programmi Google Earth, Google Maps, EarthBrowser e Google Desktop.
3Il Geography Markup Language (GML) è la grammatica XML definita dall’Open Geospatial
Consortium (OGC) per esprimere oggetti geografici.
QGis. Associati agli shapefile troviamo, oltre agli attributi geometrici, un insieme di attributi testuali o numerici. Di solito alle geometrie vengono associate informazioni descrittive come il nome o il codice della zona. Questa sorgente di dato viene rilasciata da poco tempo in modalità open, pertanto richiede alcune migliorie.
c Alcune di queste geometrie hanno richiesto una manipolazione, perché presen-tavano delle imprecisioni. Uno dei problemi rilevati ha riguardato la presenza di zone sovrapposte rendendo la loro visualizzazione graficamente confusa. Le informazioni contenute negli shapefile riguardano il codice, il nome del comune e il codice della zona OMI (Figura 3.2). Pertanto è stato necessario un ulteriore
Nome Descrizione Codice del comune Codice zona OMI
PISA - B1 ... G702 B1
Tabella 3.2: Tabella degli attributi delle zone OMI contenuti all’interno dello shapefile. L’attributo Nome contiene la concatenazione del nome del comune e il codice della zona OMI. Quindi per ogni zona OMI abbiamo sia le informazioni sul codice che quelle sul nome del comune di appartenenza.
arricchimento del dataset per ricostruire l’intera gerarchia spaziale che contenes-se anche l’informazione della provincia e della regione. Tale operazione è stata possibile attraverso la giunzione con gli attributi contenuti nelle tabelle dei comuni, delle province e delle regioni italiane rilasciate da Istat. Le operazioni sono state implementate attraverso operazioni di MERGE con delle tabelle su un DBMS Postgres/Postgis. Di seguito riportiamo un esempio di query per ottenere le informazioni sulle province e sulle regioni di appartenenza delle zone OMI, in Tabella 3.3 mostriamo un record del risultato della query.
SELECT a.codice as id_omi, a.id_com, a.com, b.codice as id_prov,
b.nome as prov, b.id_reg, b.reg FROM omi as a, provincia as b WHERE a.id_comune = b.id_comune
id_omi id_com com id_prov prov id_reg reg
B1 G702 Pisa 50 Pisa 9 Toscana
Tabella 3.3: Risultato della query di join tra le informazioni sulle zone OMI e quelle sulle province. Grazie al codice del comune presente nella tabella delle OMI riusciamo ad incrociare i due dataset e ad ottenere gli attributi per tutta la gerarchia spaziale.
La realizzazione delle attività sopra descritte ha consentito di imparare ad adoperare le primitive geometriche di PostGis per la realizzazione di query spaziali.
d Il risultato della manipolazione dei dati geometrici sarà fornito in input alle successive fasi di analisi. Le informazioni geometriche sono molto complesse e pertanto è necessario utilizzare un formato che ne consenta l’uso in modo intelligente. La scelta implementativa è stata quella di utilizzare il formato TopoJSON. Grazie a questa soluzione sarà possibile ricavare i layer comuna-li, provinciali o regionali semplicemente come combinazione dei layer delle aree OMI. Abbiamo creato il file TopoJSON, contenente per ogni livello di granularità spaziale delle informazioni diverse, grazie all’utilizzo dell’editor web MapShaper5. Questo editor prende in input Shapefile, file GeoJSON,
TopoJSON e CSV e permette sia la creazione di nuovi TopoJSON partendo da tipi di formati diversi, sia la semplificazione delle topologie. La struttura del file restituito da MapShaper è mostrata in Figura 3.4.
Figura 3.4: Attributi del TopoJSON contenente le geometrie delle zone OMI ai vari livelli di granularità spaziale. Mostriamo come cambiano gli attributi a nostra disposizione in base al livello di analisi in cui ci troviamo.
Per creare i quattro livelli mostrati in Figura 3.4, all’editor sono stati dati in input quattro shapefile, contenenti quattro suddivisioni diverse del territorio:
• zone OMI; • comuni; • province; • regioni.
