Georeferenziazione delle Proprietà Comunali di Palermo

Relazione tecnica dettagliata

---

1. Acquisizione dei dati: PDF → CSV

Il documento originale è un PDF di 336 pagine contenente l'elenco degli immobili di proprietà del Comune di Palermo aggiornato al 31 dicembre 2024. Ogni pagina contiene una tabella con 8 colonne: CATEGORIA, TIPO, SUBTIPO, INDIRIZZO, NUMERO CIVICO, FOGLIO, P.LLA, SUB. L'estrazione in formato CSV ha richiesto la risoluzione di diversi problemi tecnici, affrontati con lo script pdf_to_csv.py.

1.1 Nessuna tabella rilevata automaticamente

Il primo tentativo con pdfplumber e extract_tables() ha restituito zero tabelle in tutte le 336 pagine. Il PDF non usa linee di griglia visibili: le colonne sono definite unicamente dalla posizione orizzontale del testo. Soluzione adottata: analisi diretta delle coordinate dei singoli caratteri.

1.2 Colonne troppo ravvicinate

Le posizioni x dei caratteri mostrano gap molto ridotti tra alcune colonne:

Con soglia iniziale a 25 pt, SUBTIPO, INDIRIZZO e NUMERO CIVICO venivano fusi in un unico campo (es. ALLOGGIO (E.R.P.)VIA BERGAMINI CARLO AMM.24). Soluzione: soglia abbassata a 8 pt con controllo esplicito sui confini di colonna.

1.3 Caratteri fisicamente sovrapposti

In alcune righe, caratteri di colonne diverse occupano la stessa posizione x. Esempio: la riga PZZA ORLANDO VITTORIO EMANUELE — le ultime lettere (L a x=600.9, E a x=605.4) si sovrappongono al numero civico 3 (x=600.0). Un estrattore che ordina per posizione x produrrebbe EMANUE3LE.

Soluzione: rilevamento del salto "backward" nel PDF stream. Nell'ordine interno del file, tutti i caratteri di EMANUELE appaiono prima del 3. Quando si incontra il 3 a x=600 dopo la E finale a x=605.4, il salto all'indietro — impossibile nel testo lineare — segnala l'inizio di un nuovo campo:

INDIRIZZO      = PZZA ORLANDO VITTORIO EMANUELE
NUMERO_CIVICO  = 3

1.4 Casi particolari nel dato grezzo

• Fogli alfanumerici: alcuni valori FOGLIO non sono numerici puri (044C, 44A, 47/G, 128/) — codici catastali del centro storico di Palermo, non errori di estrazione.
• Indirizzi assenti: 714 righe senza INDIRIZZO, relative a terreni identificati solo da foglio e particella catastale.
• Numeri civici multipli: 33 righe con NUMERO CIVICO superiore a 7 caratteri (164 - 270, 8-8A-8B-10, 76-78-80) — intervalli legittimi riferiti a immobili su più civici consecutivi.

Output: file ELENCO_IMMOBILI_COMUNALI_2024.csv · 11.418 righe · encoding UTF-8 con BOM (compatibile Excel) · separatore virgola.

---

2. Obiettivo

Il Comune di Palermo dispone di un elenco degli immobili di proprietà comunale (ELENCO_IMMOBILI_COMUNALI_2024) in formato tabulare, privo di coordinate geografiche. L'obiettivo dell'elaborazione è stato quello di associare a ciascun record una geometria poligonale (particella catastale), rendendo il dataset cartografabile e analizzabile spazialmente.

Il processo ha dovuto risolvere due problemi distinti:

1. Eterogeneità delle chiavi di ricerca: parte dei record dispone di riferimenti catastali (foglio e particella), parte solo di indirizzo postale, parte di entrambi o di nessuno.
2. Qualità dei dati testuali: gli indirizzi presenti nel CSV presentano abbreviazioni non standard, varianti toponomastiche storiche, errori di battitura e nomi di strade nel frattempo rinominati.

---

3. Dataset utilizzati

Il layer ELENCO_IMMOBILI_COMUNALI_2024 contiene i campi:
CATEGORIA · TIPO · SUBTIPO · INDIRIZZO · NUMERO_CIVICO · FOGLIO · PLLA · SUB

---

4. Architettura del processo

Il processo è implementato interamente in PyQGIS (Python 3, QGIS 3.x) ed eseguito tramite il plugin QGIS-MCP. La pipeline si articola in quattro fasi:

ELENCO_IMMOBILI_COMUNALI_2024 (11.418 record)
          │
          ├─ [1] JOIN CATASTALE ──────────────► Particelle (foglio+plla)
          │         │ match: 7.562
          │         │ no match ↓
          ├─ [2] JOIN INDIRIZZO ──────────────► Civici ANNCSU → Particelle
          │         │ polygon: 3.000
          │         │ nearest: 513
          │         │ no match ↓
          ├─ [3] NO MATCH (343)
          │
          └─ [4] SPATIAL JOIN UPL ────────────► UPL + Quartiere + Circoscrizione

---

5. Fase 1 — Join catastale

Logica

Per ogni record del CSV che presenta valori nei campi FOGLIO e PLLA, viene costruita una chiave di ricerca (foglio, particella) normalizzata (rimozione degli zeri iniziali) e confrontata con il dizionario delle particelle catastali.

chiave_elenco  = (FOGLIO.lstrip('0'), PLLA.lstrip('0'))
chiave_catasto = (Foglio.lstrip('0'), particella.lstrip('0'))

Quando più particelle condividono la stessa chiave (es. frazionamenti), le geometrie vengono unite con combine().

Risultato

7.562 record georeferenziati (66,2%) — metodo più preciso, corrispondenza diretta con il Catasto.

---

6. Fase 2 — Join per indirizzo

Per i record senza riferimento catastale (o con catastale non trovato), si utilizza il layer Civici - ANNCSU come ponte: dato un indirizzo testuale e un numero civico, si individua il punto del civico, e da quel punto si risale alla particella catastale.

6.1 Pipeline di normalizzazione degli indirizzi

La normalizzazione è il passaggio critico: le stesse strade compaiono con grafie diverse nel CSV e nel layer Civici. È stata implementata la funzione norm_addr() con le seguenti trasformazioni in sequenza:

a) Pulizia base

• Conversione in maiuscolo
• Rimozione contenuto tra parentesi: VICOLO RITIRO SUOR VINCENZA (1) → VICOLO RITIRO SUOR VINCENZA
• Normalizzazione spazi e rimozione punti terminali non significativi

b) Gestione elisioni italiane

Le contrazioni italiane (DELL', SANT', SULL', NELL', DALL', ALL', COLL', GL') vengono compattate, evitando però di eliminare spazi nei cognomi siciliani con apostrofo finale (CALABRO' GIOVANNI, URZI' MARIO).

c) Espansione abbreviazioni

d) Ordinamento token (token sorting)

Per gestire l'inversione nome/cognome nei dedicatari di strade:

"VIA GIUSEPPE CIRINCIONE"  →  norm: "VIA CIRINCIONE GIUSEPPE"
"VIA CIRINCIONE GIUSEPPE"  →  norm: "VIA CIRINCIONE GIUSEPPE"  ✓ match

Il primo token (tipo di via) è mantenuto fisso; i token successivi vengono ordinati alfabeticamente, escludendo le stop word (DELLA, DELLO, DEGLI, DELLE, DEL, DEI).

e) Gestione SAN / SANTA

Per le abbreviazioni S. seguite da consonante, vengono generate due candidature: una con SAN e una con SANTA, per coprire ambiguità come S. ROSALIA (santa) vs S. ROCCO (san).

6.2 Dizionario alias toponomastici

Per strade con denominazione errata nel CSV o rinominate nel tempo, è stato aggiunto un dizionario di alias applicato dopo la normalizzazione:

6.3 Ricerca del numero civico

La funzione parse_civico() estrae i numeri civici da stringhe non standardizzate:

• 7/D-7/E → [7]
• 02/03/2026 (data per errore nel campo) → [2, 3] (match sul primo valido)
• SNC, S.N.C., 0 → [None] (nessun numero, prende primo civico disponibile sulla strada)

6.4 Da punto civico a particella

Una volta individuato il punto del civico, la ricerca della particella avviene in due passi:

1. Polygon-in-point: interroga il QgsSpatialIndex delle particelle e verifica quale poligono contiene il punto. Le particelle stradali (campo particella contenente la stringa STRADA) sono escluse dall'indice.
2. Nearest neighbor (fallback): se nessun poligono contiene il punto (es. civico sul bordo), si recuperano le 10 particelle più vicine e si seleziona quella a distanza minima reale.

La trasformazione di coordinate Civici (EPSG:4326) → Particelle (EPSG:6706) viene applicata prima della ricerca.

Risultato

---

7. Fase 3 — Record non georeferenziati (no match)

Totale: 343 record (3,0%)

I 181 record con chiave catastale non trovata sono probabilmente riferiti a particelle soppresse, accorpate o con numerazione non aggiornata nel layer catastale disponibile.

I 40 record con indirizzo non trovato in Civici si riferiscono prevalentemente a strade periferiche, vicinali private o accessi non censiti nel dataset ANNCSU.

Distribuzione per categoria

---

8. Fase 4 — Arricchimento territoriale (UPL)

Per tutte le feature con geometria, è stato eseguito un spatial join per posizione con il layer ISTAT - UPL, trasferendo i campi:

• UPL — nome dell'Unità di Primo Livello ISTAT
• Quartiere — quartiere amministrativo
• circoscrizione — circoscrizione comunale (I–VIII)

Metodo: centroide della particella → poligono UPL che lo contiene. Il layer UPL (EPSG:4326) è stato trasformato in EPSG:6706 prima del confronto.

11.074 feature arricchite (le 343 no_match rimangono prive di dato territoriale).

---

9. Risultati complessivi

9.1 Georeferenziazione

9.2 Distribuzione per categoria

9.3 Distribuzione per tipo (top 10)

9.4 Distribuzione territoriale per circoscrizione

9.5 Top 10 UPL per concentrazione

---

10. Specifiche tecniche dell'output

Driver: GeoPackage (OGC standard)
Layer: immobili_comunali_georef
Geometria: MultiPolygon
CRS: EPSG:6706 (RDN2008 — Geographic 2D)
Encoding: UTF-8
Feature totali: 11.418
Dimensione file: ~4,4 MB

Schema dei campi

Valori del campo MATCH_TYPE