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 GML}3_{. 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.

3_{Il 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.

Questi file sono stati creati tramite operazioni di aggregazione sugli attributi dello shapefile contenente la suddivisione in zone OMI (Tabella 3.3). Per esempio, per ottenere la suddivisione in comuni sulla Tabella 3.3 abbiamo effettuato un GROUP BY sull’attributo id_com, ottenendo così le geometrie dei comuni. La sovrapposizione dei file da parte dell’editor web ha restituito il file TopoJSON contenente i diversi layer di granularità spaziale.