Contesto e Requisiti
1.1 Introduzione al Progetto MAPS
Il progetto MAPS (Multidimensional Area Place-based System) si inserisce nel contesto dell'analisi territoriale italiana con l'obiettivo di definire Sistemi Locali Omogenei (SLO) basati su pattern di mobilità quotidiana multidimensionale.
Obiettivi del Progetto
- Mappatura sistemi locali: Identificazione di aree funzionali basate su accessibilità ai servizi
- Individuazione aree svantaggiate: Classificazione territori in base a indicatori di svantaggio
- Analisi investimenti pubblici: Integrazione dati Open Coesione, PNRR, fondi regionali
- Valutazione impatto: Simulazione scenari "what-if" per allocazione investimenti
Approccio Innovativo
A differenza dei tradizionali Sistemi Locali del Lavoro (SLL) ISTAT, che si basano principalmente sul pendolarismo lavorativo, MAPS adotta un approccio multidimensionale che considera:
- Lavoro (32% degli spostamenti)
- Gestione familiare (37.2% degli spostamenti)
- Tempo libero (26.2% degli spostamenti)
- Istruzione (4.6% degli spostamenti)
- Accesso a servizi pubblici essenziali
1.2 Requisiti del Data Lake
Requisiti Funzionali
RF1: Ingestion Dati Eterogenei
Il Data Lake deve supportare l'acquisizione di ~200 dataset da fonti eterogenee:
- ISTAT: Popolazione, confini amministrativi, pendolarismo
- EUROSTAT: Indicatori socio-economici europei
- Ministeri: Istruzione, Salute, Lavoro
- GTFS: Trasporto pubblico
- OpenStreetMap: Infrastrutture territoriali
- Open Coesione: Progetti finanziati
- PNRR: Investimenti Recovery Fund
RF2: Gestione Serie Storiche
- Periodo: 2010-2025 (15 anni)
- Granularità: Comunale (~8.000 comuni italiani)
- Discontinuità: Gap temporali COVID-19 (2020-2021)
- Fusioni comunali: Gestione tramite lookup storico
RF3: Standardizzazione Dati
- Normalizzazione codici ISTAT
- Uniformazione coordinate spaziali (EPSG:32632)
- Gestione valori mancanti vs nulli semantici
- Riconciliazione fusioni/separazioni comunali
RF4: Pattern Medallion
Implementazione del pattern di data lake a 3 livelli:
- Bronze: Dati grezzi immutabili
- Silver: Dati standardizzati (schema EAV)
- Gold: Data mart analitici business-ready
Requisiti Non Funzionali
RNF1: Completeness
- Target: Copertura ≥95% dei comuni italiani per ogni dataset
- Metrica: % comuni con dati completi vs totale
RNF2: Accuracy
- Target: ≥99.9% record con codice ISTAT valido
- Validazione: Confronto con reference dataset (confini ISTAT ufficiali)
RNF3: Timeliness
- Ingestion: Dataset mensili processati entro 5 giorni dall'availability
- Latenza ETL: <24h per pipeline prioritarie
RNF4: Lineage
- Tracciabilità: Completa per ogni record (fonte → Bronze → Silver → Gold)
- Versionamento: Tracking modifiche su fonti dati
RNF5: Scalabilità
- Volume: Supporto fino a 1TB dati nel triennio
- Throughput: ≥100 record/s per pipeline ETL
RNF6: Governance
- Catalogazione: Metadata per tutti i dataset
- Quality monitoring: Dashboard data quality real-time
- Audit: Log completo operazioni su dati sensibili
1.3 Dati Critici per MVP (Fase 1a)
Per la fase iniziale del progetto (Mesi 1-4), si identificano 5 dataset critici:
| Dataset | Fonte | Formato | Frequenza | Priorità |
|---|---|---|---|---|
| Confini comunali + metadata | ISTAT | Shapefile/JSON | Annuale | Alta |
| Popolazione residente | ISTAT | CSV | Annuale | Alta |
| Matrici pendolarismo | ISTAT | CSV | Decennale | Alta |
| Rete trasporto pubblico | GTFS | ZIP | Mensile | Media |
| Strutture sanitarie | Min. Salute | Excel | Annuale | Media |
1.4 Vincoli Architetturali
Vincolo V1: Self-Hosted Open Source
- Rationale: Indipendenza da vendor, costi prevedibili
- Stack tecnologico: PostgreSQL, PostGIS, Prefect, OpenMetadata, DuckDB
- Esclusioni: BigQuery, Azure, AWS managed services
Vincolo V2: Adeguatezza di Scala
- Volumetria: ~10⁴ righe × ~10³ colonne (ordine di grandezza DEPP)
- Giustificazione: BigQuery sarebbe overkill per questa scala
Vincolo V3: Standard Territoriali
- PostGIS: Industry standard per dati spaziali
- EPSG:32632: Sistema di riferimento WGS84 / UTM zone 32N
Vincolo V4: Compliance FAIR
Dataset rilasciati devono essere:
- Findable: Catalogati con metadata strutturati
- Accessible: Licenze open (CC-BY, CC0)
- Interoperable: Formati standard (GeoJSON, GeoParquet, CSV)
- Reusable: DOI per citabilità scientifica
1.5 Sfide Specifiche
Sfida S1: Assenza Geolocalizzazione Puntuale
La maggior parte dei servizi (scuole, ospedali, uffici postali) non ha coordinate precise:
- Approccio: Presenza/assenza a livello comunale
- Implicazione: Isocrone municipality-to-municipality
Sfida S2: Evoluzione Confini Amministrativi
Nel periodo 2010-2025 ci sono state ~100 fusioni/separazioni comunali:
- Soluzione: Lookup storico con validità temporale (SCD Type 2)
- Schema Silver: Colonne
valid_from,valid_to
Sfida S3: Gap Temporali COVID
Dati 2020-2021 hanno discontinuità metodologiche:
- Gestione: Flag
covid_affectedper dataset impattati - Analisi: Tecniche di imputation o esclusione periodi
Sfida S4: Eterogeneità Formati
207 dataset con formati diversi (CSV, XLSX, HTML, PDF):
- Stack estrazione: Docling (PDF), Pandas (CSV/Excel), BeautifulSoup (HTML)
- Normalizzazione: Schema EAV flessibile in Silver layer
1.6 Obiettivi del WP2
Al termine del WP2, il Data Lake dovrà:
- ✅ Ingestire 150+ dataset da fonti eterogenee
- ✅ Coprire ≥95% comuni italiani per dataset prioritari
- ✅ Fornire tracciabilità completa (lineage Bronze→Silver→Gold)
- ✅ Validare pipeline ETL con report data quality
- ✅ Preparare infrastruttura per algoritmi SLO (WP3)
1.7 Output Attesi (Deliverable)
- D2.1.1: Documento Progettazione Tecnica Data-Lake
- D2.1.2: Solution Design Architettura Cloud
- D2.1.3: Specifiche Infrastruttura Hosting
- D2.2: Script ETL (Python/SQL) documentati e testati
- D2.3: Report di Validazione Pipeline ETL
Prossimo capitolo: Architettura Tecnica Data-Lake