Categories
Idee e progetti

Un geodatabase per la Pianificazione territoriale comunale

Laureando in Pianificazione territoriale, urbanistica ed ambientale, dal 2003 al 2007, ho appreso la naturale evoluzione della gestione delle informazioni territoriali, mediante sistemi informatici, comunemente raggruppati sotto il termine di GIS (Geographic information system) o SIT (Sistemi informativi territoriali) che varie scuole di pensiero, tendono a volte a differenziare, ma altre a considerarli sinonimi. Penso che questo sia un compito in stile Wikipedia, da affrontare come discussione, proprio nelle sue pagine e quindi tralascio ulteriori commenti.

Un geodatabase per la Pianificazione territoriale comunale: laureando in Pianificazione territoriale, urbanistica ed ambientale, dal 2003 al 2007, ho appreso la naturale evoluzione della gestione delle informazioni territoriali, mediante sistemi informatici, comunemente raggruppati sotto il termine di GIS (Geographic information system) o SIT (Sistemi informativi territoriali) che varie scuole di pensiero, tendono a volte a differenziare, ma altre a considerarli sinonimi. Penso che questo sia un compito in stile Wikipedia, da affrontare come discussione, proprio nelle sue pagine e quindi tralascio ulteriori commenti.

Ciò che invece vorrei illustrare in questo articolo è la mia esperienza che insieme a vari team di professionisti, ho sviluppato sul campo, portando dei risultati più che sufficienti a dimostrare che lo schema di geodatabase che ho perfezionato può essere applicato ad ogni Piano di governo del territorio ed essere una base consolidata per apportare ulteriori sviluppi.


Il livello di maturazione di questo schema di geodatabase è frutto di uno accurato studio dei diversi sistemi per l’archiviazione dei dati territoriali ed elaborazioni connesse, da cui ho preso riferimento ed unito le caratteristiche più funzionali di ognuno di essi.

Le banche dati su cui ho lavorato principalmente sono quelle fornite dalla Regione Lombardia, che dall’anno 2000, con la conversione in vettoriale della CTR del 1994 (Carta tecnica regionale), ha prodotto una buona banca dati territoriale. Per citare le più utilizzate, sono state oggetto dei miei studi, la base informativa pedologica, quella della pianura sui beni ambientali, il censimento del patrimonio rurale della Provincia di Milano, i Piani territoriali di coordinamento provinciale, il MISURC e il DUSAF.

Questi ultimi due hanno introdotto molti aspetti tuttora sotto-utilizzati: il primo, che si tratta di un sistema di raccolta di tutta la pianificazione comunale, è costituito da un geodatabase che raccoglie una numerosa quantità di informazioni, ma purtroppo, sembra che è stato abbandonato, in vista dei nuovi sistemi utilizzati dalla Regione, per la raccolta dei dati (come l’obbligo degli incaricati del PGT alla consegna) relativi al PGT, che però rispetto al MISURC, è decisamente riduttivo; il secondo è un progetto interessante, soprattutto dal punto di vista degli aggiornamenti, essendo arrivati alla 5a versione, in cui si cerca sempre di più di avvicinarsi a standard europei, più precisamente al progetto INSPIRE.

Svolgendo un’attività professionale, non di ricerca, ma applicata sul campo, ho sempre cercato di appoggiarmi agli schemi predefiniti, ma il livello di conoscenza, acquisito dal mio percorso di studi, mi ha portato spesso a pretendere di più di quanto offerto, o comunque intuire ciò che questi sistemi prevedevano di offrire.

Con questo articolo,  illustrativo, intendo spiegare la teoria del mio prodotto, perchè il vero gap del mio progetto è la documentazione descritta in modo dettagliato, che non ho mai avuto il tempo di fare. Vorrei così aprire una discussione, che porta gli interessati a collaborare per creare insieme questa documentazione, perchè penso che sia una valore indispensabile, unico modo per poter evolvere questo metodo.

Esempio PGT con geodatabase

Lo schema del geodatabase

Una breve descrizione dello schema del geodatabase, dovrebbe servire a chiarire fin da subito di cosa si tratta, soprattutto ai meno esperti di GIS, visto che la Pianificazione territoriale, risulta essere una materia con varie sfaccettature, che usa diversi strumenti, ma sempre più spesso i GIS sono il filo conduttore. I così detti shapefile, che prefisco chiamare entità geometriche o semplicemente features, sono ridotti al minimo indispensabile e la parte costituita da poligoni è ridotta a soli 2: gli edifici e le destinazioni d’uso; altri features principali, di tipo lineare, per essere pronti ad analisi specifiche di rete, sono quelle dei corsi idrici, della rete dei sottoservizi e quella stradale; mentre gli elementi puntuali sono maggiormente divisi in diversi features, sia per comodità, sia per motivi di sviluppo in quanto poco significativi in termini di analisi per la pianificazione comunale. Ciò che risultano numerose sono le tabelle, visto che contengono molte informazioni, derivanti da fonti diverse, che si preferisce tenere separate anche solo per la diversità della denominazione delle colonne; una ulteriore massiccia elaborazione viene fatta su queste tabelle per ottimizzare la gestione col sistema GIS/geodatabase.

In questa breve descrizione è necessario specificare gli “attrezzi” per la gestione di questa mole di dati. Mi definisco un Geografo che ha studiato la Pianificazione territoriale e ho studiato veramente poco i linguaggi di programmazione, quindi mi scuso anticipatamente sulla semplificazione e banalizzazione che sicuramente incappo nella seguente descrizione del sistema che utilizzo, ma tutto sommato è ciò che mi trovo davanti quando mi siedo alla mia scrivania e cerco di descriverlo a modo mio. La scelta è ricaduta su un database Postgres con estensione geografica PostGis. Questo, utilizzato su sistemi operativi Linux, permette di accedere ai dati archiviati, in modo molto agevole con i software GIS come QGis e gvSig, mentre la gestione grafica del database è affidata al software pgAdmin o phppgAdmin. Avendo a disposizione proprio questo database, lo sviluppo web, oltre ad essere ready to use, permette di ampliarlo all’infinito, con una conoscenza di programmazione base, in modo immediato e piuttosto semplice, sia dalla parte di diffusione dei dati come servizio web, utilizzando Geoserver e Mapserver, sia per la creazione di interfacce di visualizazzione, interrogazione e modifica dei dati, sfruttando le potenzialità offerte dal linguaggio PHP.

I features che voglio riportare, essendo i principali elementi che permettono di gestire quasi la totalità di un PGT sono:

  • pg_destinazioni

  • pg_edifici

  • pl_viabilita

  • pl_aerofotogrammetrico

Ognuno di questi features ha funzioni specifiche, ruoli ben precisi e al loro interno (le tabelle associate alle geometrie) contengono informazioni codificate che coprono la panoramica delle richieste che la Pianificazione territoriale si attende. La regolarità geometrica unita alla topologia delle forme è fondamentale, mentre la moltiplicazione della segmentazione, che ha sempre portato problemi nella restituzione grafica, ha molta libertà, visto che la scelta di PostGIS, risolve anche questi problemi, senza moltiplicare i features per ogni esigenza o comunque è fatto in automatico attraverso regole.

Questo sistema complesso è tenuto insieme da regole e lo sviluppo continuo, si basa proprio sulla semplificazione di procedure e processi, ricercando continuamente regole, che permettono di consolidare le diverse parti, i così detti geoprocessing e spatial analyst.

La differenza in termini di gestione del territorio, tra i 4 features, è data da pg_destinazioni, perché a differenza degli altri, questo è costituito da un sandwich di informazioni, mentre gli altri, compresi quelli minori non citati in questo elenco perché non principali, tengono insieme anch’essi molti dati, ma provenienti dallo stesso oggetto: gli edifici hanno la componente strutturale, quella documentale, quella immobiliare e quella tipologica; così le strade e tutti gli elementi che costituiscono l’aerofotogrammetrico. Mentre pg_destinazioni è considerato un sandwich perché si sovrappongono vincoli, dati catastali, destinazioni d’uso, uso effettivo del suolo, azzonamento ed è l’unico riferimento per contare in modo preciso le aree su tutto il territorio comunale, dove si appoggiano sia gli altri 3 features, sia tutti i features non principali.

Questo ci porta a considerare la logica di relazione tra le geometrie, agevolata da PostGIS. Un edificio è posizionato su un’area di territorio, che è attraversata da diverse strade; una area, essendo identificata in modo preciso, è confinante con un’altra area, dove ci sono altri edifici e altre tipologie d’uso e altre strade; in questo modo posso così calcolare la disponibilità di servizi, tipo parcheggi e aree verdi, le attrezzature con cui è costruita la strada, tipo spartitraffico e marciapiedi, il numero virtuale in base al volume degli abitanti insediabili e le potenzialità dell’area ad ospitare nuove volumetrie; tutto questo sempre tenendo sotto controllo i calcoli (ovvero gli impatti) attraverso una dashboard, aggiornata in real-time ad ogni modifica. Lo sviluppo di questo sistema potrebbe sfruttare questa dinamicità per creare scenari in base a scelte di pianificazione differenti, per supportare le decisioni che le amministrazioni devono prendere, che troppo spesso si basano su dati non di tipo territoriale, semplicemente perché non sono dotate di un sistema che reagisce in questo modo.

Applicazioni

Con questo sistema, di cui rimando a fine articolo, la specifica della struttura principale, riesco ad affrontare in modo lineare, tutta una serie di analisi, richieste (o di solito ipotizzate) dalla pianificazione comunale. Si possono chiamare analisi spaziali o semplicemente analisi territoriali, che consentono di creare scenari di analisi, su cui poter discutere ed effettuare le scelte di pianificazione.

  • verifica della compatibilità dell’area urbanizzata definita dalla Provincia, con le trasformazioni previste

  • stato di attuazione della pianificazione vigente

  • calcolo degli abitanti insediabili

  • calcolo dei servizi disponibili

  • verifica dei parametri urbanistici

  • calcolo di indicatori di caratterizzazione dei comparti

  • valutazione dell’indice di forma

  • valutazione dell’indice di compatibilità edificata

  • classificazione sensibilità paesistica

  • valutazione rischio idrogeologico

Questo elenco sicuramente non è esaustivo, ma vorrei sottolineare, che le analisi elencate sono frutto di una mia interpretazione della Legge per il governo del territorio, validata insieme ai tecnici/professionisti con cui collaboro, arrivando a definire delle linee guida, da sviluppare e da approfondire, sia la tecnica di realizzazione, sia la reale applicazione.

I features

A seguito, riporto l’elenco delle colonne, che costituiscono la struttura delle tabelle (e loro decodifica) all’interno del (mio)geodatabase.

pg_destinazioni

  • gid identificativo univoco

  • g01_studio macro area di studio

  • g02_indagine segmentazione della macro area di studio

  • comparto segmentazione dell’area di indagine

  • cod_uni_p nel caso in cui il comparto ha diversi azzonamenti

  • catasto foglio e mappale

  • au area urbanizzata definita dalla Provincia

  • scen1a pianificazione vigente

  • scen2a ulteriore definizione sovracomunale (parchi, aree militari …)

  • scen2b codice di confronto tra pianif. attuale e di PGT

  • scen2c prima classificazione azzonamento

  • scen2d specifica di scen2c

  • scen2e specifica di scen2d

  • cod_st codice identificativo strada

  • ambtrasf ambito di trasformazione (vero/falso)

  • ambito_2 cod.uni. ambito di trasformazione

  • stato libero/occupato

  • pa_tipo pianificazione attuativa

  • pian_esec cod.uni. pianif. attuativa

  • pubb_priv proprietà (pubblico/privato/altro)

  • ambser ambito servizi (vero/falso)

  • cod_serv cod.uni. servizi

  • v_strada vincolo codice della strada (vero/falso)

  • v_idro vincolo idrogeologico (vero/falso)

  • v_pozzo vincolo acque potabili (vero/falso)

  • v_cimi vincolo cimiteriale (vero/falso)

  • v_cscs vincolo beni storico/architettonici (vero/falso)

  • … altri vincoli (vero/falso)

  • ptcp specifica PTCP

  • notes (…)

Tabelle di decodifica.

tb_scen2b

1 – consolidato

2 – in trasformazione con cambio di destinazione da agroforestale

3 – in trasformazione con cambio di destinazione da ind.art.comm

4 – in trasformazione con cambio di destinazione da residenziale

5 – in trasformazione con cambio di destinazione da servizio

6 – in trasformazione possibile

7 – modifica (trasformazione senza cambio di destinazione)

8 – non trasformabile

9 – rettifica / errori materiali

10 – consolidato in realizzazione

tb_scen2c

1 – residenza

2 – ind.art.comm.

3 – servizi

4 – verde

5 – strade

Oltre a queste esistono anche (come visibile dalla struttura) tb_scen2a, 2d e 2e, ma riportare la loro decodifica, porterebbe via molto spazio a questo articolo.

By pjhooker

Tutti mi chiamano "uomo del gis" ... i software così detti GIS (Geographic information system) hanno accompagnato il mio percorso di studi universitario, fin dalle prime elaborazioni, quando mi fecero calcolare la lunghezza di una pista ciclabile e l'area di un bosco ... per un po' di mesi, mi chiedevo perché non mi facevano usare il mio amato AutoCad, visto che lo usavo già da 3-4 anni ... ma poi ho capito la differenza ... e tutto cambiò!