Documentazione disponibile - Centro Interregionale Gis

Prototipo software per la consultazione e gestione dei Piani Territoriali Paesistici
I prodotti utilizzati
La cartografia raster
La “mosaicatura” dei piani
Consultabili, confrontabili, duplicabili.
Alcuni aspetti tecnici
La sovrapposizione tra elaborati
2
2
3
3
5
6
8
L’esempio campione: i PTP della Regione Molise
11
Approccio, metodologia e problemi pratici
15
La costruzione degli “shape files”
20
Il programma di visualizzazione
I tasti di “Vettorizzazione” e “Ripristino”
Sommario del tema
Dissolve
La visualizzazione delle relazioni
Il tasto di Aggiornamento
I layouts
26
28
29
29
30
30
31
Il programma di editing
Il tasto “S”, che elimina sovrapposizioni tra poligoni
Il tasto “E”, che esplode i poligoni
Il tasto “A” che ricalcola area e lunghezza
La procedura di editing
31
32
33
34
34
1
Prototipo software per la consultazione e gestione dei Piani
Territoriali Paesistici
Il presente lavoro è stato avviato nell’ambito di una ricerca tesa a costituire un “Sistema
Cartografico di Riferimento” nazionale, ad uso della Pubblica Amministrazione. L’obiettivo di
questo specifico studio era quello di individuare strumenti software che potessero fornire un
ausilio nella definizione, consultazione e implementazione dei Piani Paesistici. L’idea era quella
di giungere a una razionalizzazione della spesa, realizzando un prototipo che potesse venire
utilizzato da più utenti, evitando duplicazioni nell’investimento, e ad una qualche forma di
standardizzazione “de facto”, definendo legende, categorie e forme di rappresentazione
concordate con diverse Regioni, che potessero venir prese a riferimento per rendere più
facilmente interpretabili e confrontabili i diversi elaborati.
L’esame di alcune specifiche situazioni ha permesso di meglio focalizzare i problemi reali
connessi allo studio, e di meglio definirne obiettivi e portata.
I prodotti utilizzati
Per motivi di comodità e di diffusione dei prodotti e del formato (shape), abbiamo utilizzato
prodotti della famiglia ESRI, e in particolare ArcView e procedure sviluppate nel linguaggio
Avenue. Non abbiamo utilizzato ArcView serie 8, nonostante l’idea di sviluppare gli applicativi
in Visual Basic invece che nel linguaggio Avenue fosse attraente, per gli stessi motivi di
diffusione. Per adesso le istallazioni della serie 8 sono ancora poche (sono parecchio più costose,
anche se ESRI offre degli accordi molto convenienti per chi vuole effettuare il passaggio) e la
casa madre dichiara che (per adesso almeno) non si tratta di una nuova versione della serie 3, ma
di un nuovo prodotto che avrà una sua vita autonoma e parallela, senza sostituire la serie più
economica e diffusa.
Abbiamo ritenuto di sviluppare due programmi separati ed autonomi, uno di consultazione, e uno
per l’editing. Il motivo di questa scelta diversificata è abbastanza ovvio, le operazioni da
effettuare in fase di costruzione o rielaborazione sono molte e non perfettamente prevedibili.
Operazioni quindi che vengono effettuate da operatori esperti, che hanno bisogno di uno
strumento flessibile e potente, da adattare di volta in volta alle diverse esigenze. La
visualizzazione e consultazione dei piani vengono invece effettuate da un pubblico più largo e
meno esperto, che richiede un interfaccia utente chiaro e semplice, e comportano operazioni
ripetitive, compatibili con una procedura relativamente chiusa.
La distinzione si fa ancora più netta se il prodotto per la consultazione e visualizzazione evolve
verso una applicazione in rete. Non abbiamo lavorato su questa opzione, ma è abbastanza ovvio
che questa è la naturale evoluzione del modulo sviluppato in MapObjects (mentre non lo è, o
almeno non necessariamente) per le procedure previste in ArcView.
In linea di principio quindi abbiamo ritenuto che le elaborazioni tese a costruire e rimaneggiare i
Piani andassero svolte sotto ArcView, sviluppando sotto questo ambiente una serie di esempi,
coperture campione, legende tipo e funzioni ausiliarie.
Avevamo pensato inizialmente di sviluppare il modulo di consultazione con MapObjects. La
soluzione avrebbe comportato dei notevoli vantaggi, primo tra tutti la possibilità di diffondere il
programma in forma gratuita o quasi. Abbiamo però trovato un ostacolo nella gestione delle
legende. ArcView permette di normalizzare le legende entro un file “.avl”, che il programma
interpreta come parte integrante del file (qualora abbia lo stesso nome, o meglio la stessa radice,
2
degli altri file che nel loro insieme costituiscono lo “shapefile”) aprendo e visualizzando lo strato
con quelle specifiche forme di rappresentazione in modo automatico. Si tratta di una facilitazione
notevole per un applicativo di questo genere, che non siamo riusciti a riprodurre in forma
soddisfacente sotto MapObjects. I due programmi quindi, sia quello di visualizzazione che di
editing, sono stati in definitiva, e per questo motivo, sviluppati sotto ArcView 3.2.
Analizzeremo in seguito alcuni dei problemi incontrati e alcune delle procedure approntate.
La cartografia raster
Uno dei problemi che abbiamo dovuto affrontare è stato quello delle carte base in formato
“raster”. Alcuni tipi di coperture “raster” (carte tecniche regionali, ortofotopiani) sono
difficilmente gestibili in formato non compresso (a parte il problema dello spazio occupato,
bisogna “pescare” di volta in volta la tavoletta o porzione che interessa, o a mano o attraverso
una procedura non semplicissima), per cui abbiamo sperimentato alcune forme di accorpamento
e compressione. I prodotti esaminati (e i più diffusi) sono stati due: MrSid ed ER Mapper.
Entrambi hanno la caratteristica di comprimere in modo radicale le immagini raster, e di
permettere di unificare in un unico file compresso un numero molto elevato di moduli. Ad
esempio la carta tecnica del Lazio, contenuta originalmente in circa 500 immagini per
un’occupazione complessiva di 500 Mbytes, è stata compressa con MrSid ad un unico file di 40
Mbytes.
Il formato MrSid è incorporato in forma standard in ArcView (attivando un’estensione), e tutte le
zoomate e operazioni di pan vengono effettuate in tempi molto brevi, dato che il software
decomprime di volta in volta solo la porzione di file relativa alla finestra di visualizzazione. La
perdita di informazione (nitidezza di immagine) è abbastanza irrilevante.
Il formato ER mapper ha caratteristiche simili. Non è incorporato in forma standard, ma degli
add on di semplice istallazione sono disponibili in rete.
Entrambi i prodotti si integrano in modo soddisfacente nel sistema, ma alla fine abbiamo optato
per una terza soluzione, che è quella di utilizzare un “catalogo” di immagini, gestito da
un’estensione di ArcView. La velocità di visualizzazione resta buona (la procedura “pesca” solo
quelle immagini che vengono toccate dalla finestra di visualizzazione) la qualità dell’immagine è
quella originale e, salvo una semplice operazione di generazione dell’indice del catalogo, non
richiede complesse rielaborazioni.
L’inconveniente è la mancata compressione, e quindi la forte occupazione su disco. Quindi non
escludiamo, per altre applicazioni, una delle soluzioni di compressione indicate. Per Regioni
molto estese, difficilmente una documentazione che contenga una Carta Tecnica Regionale potrà
venire contenuta su un unico CD senza compressione. Ma nel nostro caso, avendo utilizzato
come Regione campione il Molise, non se ne è riscontrata l’esigenza.
La “mosaicatura” dei piani
Eravamo partiti con l’idea che uno degli strumenti base da inserire nel prototipo fosse costituito
da procedure atte a “mosaicare” insieme i diversi moduli che costituiscono il Piano Paesistico di
una Regione, al fine di poterne ricavare quadri di sintesi complessivi. Infatti i Piani Paesistici
coprono in genere delle estensioni relativamente ridotte, definite in base a criteri diversi, ma che
riguardano, nel loro insieme l’intera Regione. Per molte applicazioni e finalità la Regione ha
difficoltà a fare riferimento ai singoli elaborati, ed ha bisogno di un quadro generale di insieme.
In diversi casi questo quadro di insieme, somma dei singoli Piani Territoriali Paesistici (PTP)
3
diventa uno strumento a sé, un Piano Territoriale Paesistico Regionale (PTPR) complementare o
sostitutivo dei PTP.
I singoli piani possono essere molto numerosi, il Lazio è ad esempio coperto da 28 strumenti
zonali, la Sicilia da 10. La consultazione, distribuzione e uso delle cartografie su supporto
cartaceo e della documentazione testuale è molto difficile, e la conservazione e duplicazione del
materiale onerosa.
L’ipotesi di partenza era quella che i diversi piani, i diversi pezzi del “puzzle” regionale avessero
una base e un’impostazione comune, e che quindi il lavoro di ricomposizione potesse consistere
semplicemente nella digitalizzazione e fusione dei vari strati informativi, e nella definizione di
categorie comuni (sacrificando in alcuni casi un dettaglio informativo più spinto in un elaborato,
per renderlo compatibile e confrontabile con le categorie usate per un'altra zona) e forme di
rappresentazione standard. L’adozione di una legenda comune non comporta necessariamente
una perdita di informazione; se un certo fenomeno, causa l’adozione di un comune
denominatore tra i valori assunti da un attributo nei vari moduli, viene rappresentato in sole tre
categorie (p.es. 0-25/26-50/51-100) mentre uno dei moduli zonali ne distingueva quattro (p.es. 025/26-50/51-75/76-100), l’informazione più dettagliata non va perduta, ma resta consultabile e
visualizzabile, associata a un altro attributo degli elementi grafici (categoria originale/ categoria
standardizzata).
Di fatto abbiamo riscontrato situazioni molto meno favorevoli. In teoria i singoli piani, benché
affidati generalmente a gruppi di professionisti diversi, dovrebbero avere un aspetto e un
contenuto relativamente omogeneo, in quanto è sempre previsto un momento di coordinamento,
costituito ad esempio da un comitato scientifico a cui partecipano i diversi capigruppo o i loro
rappresentanti. Inoltre la base di partenza per ogn’uno dei Piani, cartografia di base e
informazioni conoscitive sul territorio, dovrebbe essere comuni, fornendo un ulteriore elemento
di continuità tra i vari strumenti contermini.
In diversi casi abbiamo però constatato difformità di impostazione molto profonde, che arrivano
fino al materiale di partenza, alla interpretazione delle preesistenze, per non parlare
dell’impostazione e individuazione delle zonizzazioni di piano. Affiancando elaborati di base,
sullo stato di fatto, si evidenzia a volte, a titolo di esempio, come solo uno o due dei moduli
riporti le aree di vegetazione ripariale attorno ai fiumi. Leggendo il mosaico appare evidente la
difformità, anche a questi livelli di partenza, con aree vegetazionali estese individuate per un
comparto, che scompaiono di colpo arrivate ai confini della zona.
In casi come questi è chiaro che una procedura automatica o guidata che sia può fare ben poco.
Non si tratta di rendere confrontabili informazioni più o meno equivalenti ma rappresentate in
modo diverso. Il problema è molto più sostanziale: l’informazione di base stessa è diversa, e in
molti casi del tutto mancante.
In queste situazioni il Piano di insieme, il Piano Paesistico Regionale, è in pratica definito da un
progetto ex novo, e la preesistenza di Piani Paesistici di zona, disomogenei, di difficile
consultazione, con lacune informative e per forza di cose in genere datati e in parte superati,
costituisce al meglio una fonte informativa di confronto, e al peggio un intralcio.
Il prototipo software deve quindi tener presente questa situazione, o meglio la possibilità di un
riscontro di situazioni del genere (non sempre le cose hanno caratteristiche così negative, in
diversi casi il coordinamento tra i diversi progettisti di PTP è stato efficace ed effettivo). Al
modulo software per agevolare la costruzione di un mosaico tra i vari elaborati zonali, andrebbe
aggiunto un modulo, forse più importante, per guidare ed agevolare la progettazione ex novo
degli strumenti, che preveda uno strato omogeneo e comune per le analisi e informazioni di base
4
sull’intera estensione regionale, e omogenei criteri per la definizione e rappresentazione delle
diverse categorie di analisi o di vincolo. Funzionalità di questo tipo non sono state per ora
inserite nel prototipo da noi sviluppato, ma potrebbero essere oggetto di sviluppi futuri.
Consultabili, confrontabili, duplicabili.
Lavorare con i PTP ha evidenziato, se ce ne fosse ancora bisogno, i vantaggi della cartografia
digitale e dei sistemi GIS. Gli elaborati originali della maggior parte dei PTP sono dei pesanti
faldoni, che contengono eliografie sbiadite e polverose, con documentazione organizzata in
volumi di testo altrettanto sbiaditi e di difficile lettura. Difficili da trovare, consultare,
interpretare. Quasi impossibile operare dei confronti tra le varie carte, verificare ad esempio
quante delle indicazioni della carta vegetazionale sono state trasformate in vincoli, ecc.
Da questo punto di vista la superiorità della tecnologia digitale appare enorme. Costruire un CD
con tutti i contenuti dei piani non è semplice né economico (ma ovviamente per il futuro, con
delle adeguate specifiche, tutto il materiale dovrebbe già venire elaborato e reso disponibile in
forma digitale, dai testi alle carte alle tabelle di dati). Ma una volta raggiunto un risultato, il
contenuto di venti pesanti faldoni viene archiviato in un unico CD, con i testi tradotti in digitale
(e quindi interrogabili con ricerche indicizzate, associati a tabelle e grafici, ecc.), carte chiare,
“zoomabili” e affiancabili, procedure di ricerca e stampa più o meno agevoli ecc. Inoltre, sotto
questa forma, la reperibilità delle informazioni, e quindi la loro cogenza e utilità, diventa
enormemente maggiore. In troppe occasioni piani e strumenti importanti per il territorio sono
rimasti lettera morta per la difficoltà per il pubblico o per i tecnici di consultare o reperire i
necessari elaborati. Senza ricorrere ad esempi estremi (quali quello del vincolo idrogeologico,
teoricamente importante e valido, ma esistente in pratica in un'unica copia manoscritta disegnata
a mano sulle tavolette IGM e giacente presso un ufficio inaccessibile del Ministero LLPP), in
molti casi la disponibilità al pubblico di questi strumenti viene attuata attraverso la messa a
disposizione, entro orari limitati dalla disponibilità del personale, di un'unica copia presso la
Regione. In queste situazioni, l’utilizzazione dello strumento da parte del pubblico, compresi
tecnici e operatori, si annulla o quasi. E anche la possibilità di avanzare osservazioni o ricorsi in
fase elaborativi si riduce di molto. La digitalizzazione del Piano, specie se accompagnata da una
adeguata strumentazione per la consultazione, cambia completamente il livello di accessibilità e
fruibilità di questi strumenti.
Un CD è duplicabile in forma semplice e a bassissimo costo (pochi minuti e poche migliaia di
lire: un CD vergine costa sulle 2500 lire, e in 600 Mbyte si possono inserire tutte le cartografie di
piano di una media Regione, con tanto di carte tecniche). E l’altra opzione, di organizzazione dei
dati in rete, garantisce un accesso ancora più generalizzato, con l’ulteriore garanzia
dell’aggiornamento del dato. Non a caso la legge regionale del Lazio (LR 6 luglio 1998, n. 24)
sulla “Pianificazione e tutela dei beni e delle aree sottoposte a vincolo paesistico” prevede,
all’art. 3, l’istituzione del Sistema Informativo Territoriale Regionale, quasi che il SIT sia una
naturale e necessaria conseguenza. I PTP sono uno strumento base del quale tutte le Regioni si
sono dotate, i vantaggi di una loro informatizzazione sono evidenti, e tale informatizzazione
costituisce sovente il primo passo verso la creazione di un SIT. Non è una consequenzialità
automatica, ma ha comunque un senso.
Restano comunque da affrontare e superare i soliti problemi di confidenzialità e proprietà del
dato. I Piani dovrebbero per definizione essere pubblici, duplicabili e distribuibili. E quanto più
vengono conosciuti e diffusi tanto meglio. Ma in molti casi ciò può scontrarsi con i diritti di
proprietà di certi elementi (la Carta Tecnica Regionale che fa da sfondo a molti di questi
elaborati, ad esempio) o la confidenzialità di certe informazioni. In una organizzazione in rete
alcuni di questi problemi possono venire superati, attraverso l’uso di permessi di accesso
5
adeguatamente strutturati, o attraverso visualizzazioni di elaborati con modalità che non
permettono di estrarre alcune informazioni (quali ad esempio i vettoriali di origine delle carte).
Su CD si può optare per soluzioni diverse, ad esempio sfumando e sfuocando leggermente la
carta base, in modo da renderla ancora leggibile come sfondo, ma meno appetibile dell’originale
autorizzato, e quindi di valore commerciale scarso o nullo.
Resta comunque un problema generale che riguarda la possibilità di distribuire liberamente dei
dati cartografici di pubblica utilità, che dovrebbe spingere ad estendere l’ambito, per ora molto
limitato, delle informazioni considerate di pubblico dominio, e quindi accessibili a tutti e a titolo
gratuito. Un’importante passo in questa direzione dovrebbe essere l’attuazione del “Sistema
Cartografico di Riferimento”, che dovrebbe risolvere il problema almeno per quanto attiene a
tutte le espressioni della Pubblica Amministrazione.
Alcuni aspetti tecnici
Una delle prestazioni che si richiede da un software quale quello in discussione, come si è detto,
è la mosaicatura. Un gran numero di PTP di zona deve poter essere collazionato, e deve essere
possibile consultare l’insieme nel suo complesso, sia graficamente che analiticamente. A parte il
tempo necessario per organizzare il materiale, e i problemi di revisione e di verifica della
compatibilità delle informazioni, dal punto di vista tecnico la soluzione è relativamente semplice.
Si tratta di unificare le coperture delle zone contermini in modo da creare una carta continua
(verificando quindi che coordinate e proiezioni siano compatibili, e adattando le linee comuni di
confine), di definire una classifica comune per le informazioni riportate, creando dei nuovi campi
di attributi per far si che le informazioni originali non vadano perdute.
Figura 1 – Uno schema semplificato che rappresenta lo stesso strato tematico per due PTP contermini
Ad esempio, le due cartine della figura 1 fanno riferimento allo stesso tema per due zone
contermini, ma la classifica della zona 2 è più dettagliata, o disaggregata, di quella usata per la
zona 1.
6
Figura 2 – Le due zone “incollate” e la tabella ampliata con i nuovi attributi
Va quindi definita una nuova codifica, che costituisce il minimo comune denominatore tra le due
legende (nell’esempio riportato coincide, per semplicità, con la legenda della zona 1) e vanno
aggiunti due campi di attributi; uno con il codice di zona, e uno con la nuova codifica unificata.
La nuova copertura con la mosaicatura dei due piani, in questo modo, contiene tutte le
informazioni iniziali, ed è quindi possibile, selezionando in base al campo “zona”, rappresentare
i dati della fig. 1 a partire dalla nuova copertura complessiva. Ma d’altra parte la copertura unica
permette di calcolare aree complessive, estrarre tematismi o effettuare incroci sul complesso
dell’area.
L’operazione di mosaicatura comporta inoltre una serie di difficoltà tecniche, che rientrano però
nelle usuali procedure di gestione di un SIT. Si tratta di riportare tutte le coperture zonali di
origine ad un comune sistema di coordinate (il che può comportare problemi di riproiezione, ma
nel caso di PTP afferenti ad un'unica Regione non è in genere il caso), e di modificare i confini
delle singole tessere del mosaico in modo che le “attaccature” risultino perfette, senza
sovrapposizioni lungo i bordi (overlapping) o lacune. Questo si ottiene in genere costruendo una
copertura “master” con i confini precisi tra le zone, definite come poligoni chiusi. Estendendo
poi le aree o le linee contenute nei vari strati di piano leggermente oltre questi limiti, e usando
quindi il limite della copertura “master” per ritagliare perfettamente i confini degli strati zonali.
Se le cartografie dei piani per le singole zone sono su supporto cartaceo, ancora da digitalizzare,
bisognerà istruire gli operatori al digitizer di prevedere questa “sbordatura” oltre i confini.
Se si utilizza, come noi abbiamo fatto, ArcView per gestire queste operazioni, il “ritaglio” si
effettua con un comando di “clipping” (dopo aver attivato l’estensione di “geoprocessing”,
presente come estensione standard dalla versione 3.1 in poi), dopo aver selezionato il poligono
da usare come maschera nella copertura “master”. Le coperture di zona risultanti dall’operazione
di ritaglio potranno poi venire unificate in un'unica copertura regionale mediante un comando di
“merge”.
7
Figura 3 – Una copertura “master” con i confini delle due zone (A), e un elaborato di zona che “sborda” oltre i
confini (B).
Figura 4 – Il risultato del “ritaglio”. A sinistra (C) la zona perfettamente “rifilata”, e a destra (D) lo “sfrido”
eliminato.
Dato che si tratta di operazioni standard, già previste dal programma ArcView, e gestite da menu
molto esplicativi, non è il caso di creare delle procedure specifiche o guidate per gestirle.
La sovrapposizione tra elaborati
Alla cartografia digitale si chiede anche la possibilità di sovrapporre, e di interpretare quindi
congiuntamente, due o più elaborati (overlay). Bisogna distinguere due tipi di operazioni.
L’analisi spaziale vera e propria, che costituisce l’aspetto più caratteristico e la maggiore
potenzialità di un sistema SIT, e la semplice sovrapposizione visiva.
Figura 5 – Ipotizziamo di voler analizzare due strati informativi, ad esempio una altimetria (a sinistra) e un’area di
rispetto (destra)
L’analisi spaziale permette di effettuare incroci anche complessi tra strati informativi diversi,
ottenendo nuove cartografie e nuove informazioni derivate dall’elaborazione. Prendendo
8
esempio dalla figura, se si hanno informazioni relative a un vincolo (una certa distanza da un
corso fluviale) e una carta sull’uso del suolo, se ne può generare una nuova che contiene le aree
vincolate classificate per uso del suolo, con la relativa tabella con le superfici. E si può
eventualmente isolare una estensione che interessa (area vincolata e forestata) con le relative
informazioni.
Figura 6 – Una intersezione spaziale tra due strati, e la selezione e le statistiche per una classe.
Di nuovo, si tratta di funzioni tipo disponibili in ArcView (in questo caso “Intersect”, sempre
dopo aver attivato l’estensione “Geoprocessing”, seguita dal comando “Statistics” per ottenere la
somma complessiva delle aree che interessano, o “Dissolve” per unificarle effettivamente).
L’ausilio che abbiamo predisposto per queste situazioni, e per altre analoghe, è l’aggiunta di un
bottone alla View, che crea o aggiorna nella tabella di attributi del tema selezionato le colonne
Area (calcolata in ettari), e la lunghezza per i tematismi lineari.
Anche se queste elaborazioni sono molto importanti e potenti, il loro uso avviene in genere in
fase di elaborazione del piano, e dato che le possibili combinazioni e incroci sono praticamente
infinite, la procedura non è molto sistematizzabile. Oltre all’aggiunta del bottone per
l’aggiornamento delle tabelle, non c’è molto altro che si possa fare per aiutare nell’utilizzo degli
elaborati.
In fase di consultazione dei piani avviene più sovente che si voglia semplicemente visualizzare
una sovrapposizione tra due carte, il che è sempre possibile, ma presenta a volte qualche
problema.
Va notato prima di tutto che, mentre negli elaborati cartacei una mappa è una costruzione rigida
di informazioni grafiche, in una cartografia digitale la stessa carta è quasi sempre rappresentata
da una “vista” già predisposta, contenente una sovrapposizione di tematismi. Una carta sui
vincoli della legge Galasso sarà costituita da uno strato di sfondo (in genere un “raster” della
carta tecnica), dalle poligonali che evidenziano le aree di rispetto definite dal vincolo, da una
copertura lineare con l’idrografia, e da altre informazioni complementari, quali legende, simboli
ecc.
Quindi alcune sovrapposizioni saranno già presenti nella presentazione “standard” del Piano. E
alcune soluzioni tipo sono già incorporate in queste presentazioni. Ad esempio la cartografia
“raster” della carta tecnica, per quanto chiamata “di sfondo”, in genere viene sovrapposta alle
campiture di vincolo o ad altre informazioni, “svuotando” le aree bianche per lasciar vedere ciò
che c’è sotto. La cosa è semplice quando si tratta di un bitmap bicolore (bianco/nero), solo
leggermente più complessa se si tratta di una carta che per qualche motivo (p.es. se si sono
utilizzati determinati strumenti di compressione) è stata registrata come toni di grigio (in questo
caso bisogna fissare una soglia per i toni chiari “svuotati”).
9
L’altro caso semplice è quello della sovrapposizione tra coperture lineari e coperture per
superfici (raster o vettoriali). In questo caso il solo problema è quello di definire spessori e colori
per la copertura lineare che rendano agevolmente leggibile le informazioni sovrapposte.
Il caso più comune e che presenta le maggiori difficoltà si verifica quando si vogliono
confrontare due strati informativi rappresentati da superfici. Ad esempio visualizzare una carta
con zonizzazioni di piano sovrapposta a una carta dell’uso del suolo. In alcuni casi il problema
può venire semplificato, visualizzando i soli confini di una delle due carte, il che ci riporta al
caso anteriore (sovrapposizione tra coperture lineari e coperture per superfici), ad esempio la
sovrapposizione di un area vincolata come parco su una carta dell’uso del suolo; in questo caso
una delle due zonizzazioni (area a parco) è semplice da interpretare, e resta leggibile anche se
ridotta al solo perimetro.
Negli altri casi la visualizzazione richiede qualche accorgimento, onde evitare che lo strato
sovrapposto nasconda in tutto o in parte quello sottostante. I metodi possibili sono due: per
campiture o per trasparenza. Il metodo per campiture funziona meglio nel caso di
sovrapposizioni tra superfici a colori piani (tipicamente due coperture vettoriali), quello per
trasparenza quando dei colori piani vanno sovrapposti a un ortofotopiano o un’altra immagine
raster del genere (DTM, carta delle pendenze ecc.).
Nelle versioni di ArcView che abbiamo utilizzato la trasparenza non è disponibile, ma lo è in
altri programmi, e nella versione ArcView 8.
Quando si propongono delle sovrapposizioni, si ricorre quindi alla campitura rigata o puntinata,
avendo in genere cura di mantenere come copertura sottostante quella più estesa (con campiture
che coprono tutta o molta della superficie della mappa). In ArcView usando questa forma di
rappresentazione bisogna generalmente usare un accorgimento non sempre noto, dato che le
campiture rigate standard, con background trasparente, diventano opache quando si stampano o
si esportano come immagine. Si mantengono trasparenti in stampa o in esportazione immagine
solo le campiture della serie di simboli “carto” (c:\…\symbols\carto.avp), che vanno
appositamente caricati.
Figura 7 – Esempio di sovrapposizione utilizzando campiture rigate.
In genere per una agevole visualizzazione si mantiene la copertura sottostante a colori pieni, e si
campisce in rigato trasparente quella sovrapposta (la sovrapposizione di due carte a campiture
rigate dà un risultato di difficile lettura). Un accorgimento, che fino a un certo punto si può
sistematizzare con una procedura, è quello di sovrapporre con campitura rigata la copertura con
la minor percentuale di area campita tra le due esaminate. Il tentativo di sovrapporre più di due
10
coperture con vaste aree di sovrapposizione risulta in genere in un elaborato o una
visualizzazione quasi illeggibili.
Nella procedura approntata si è messo a disposizione anche un altro sistema, molto comodo, che
è quello della “vettorizzazione” della campitura. Viene trattato in dettaglio nella descrizione
della procedura di visualizzazione, e si attiva con un tasto che mantiene il colore base della
legenda, ma sostituisce la campitura piena con una campitura rigata e trasparente, sia in
visualizzazione che in stampa. E’ meno flessibile rispetto alla scelta di una campitura vettoriale
specifica (i simboli “carto”), ma molto più veloce e semplice da usare.
Figura 8 – Sovrapposizione, mediante l’uso di trasparenza, di poligonali vettoriali su un ortofotopiano
L’esempio campione: i PTP della Regione Molise
Come esempio campione di Piano Territoriale Paesistico abbiamo utilizzato quello della Regione
Molise. E’ difficile dire se si è trattato di una scelta indovinata o meno. Ma forse sì, in quanto il
Piano presenta diverse difficoltà e peculiarità, che coprono una buona gamma dei possibili
problemi che si possono incontrare.
I PTP del Molise sono stati elaborati in base a 10 zone di “vincolo” o di Piano, delle quali solo 8
sono coperte da strumenti. Le altre zone sono state lasciate scoperte per scelta, in quanto non si
ritenne necessario ricorrere al PTP come strumento di piano, a causa delle problematiche
territoriali o della struttura insediativa. In questo il Molise si differenzia da altre situazioni, dove
la somma dei PTP in genere coincide con la superficie complessiva della Regione.
11
Figura 9 – Le zone di piano (o di “vincolo”) della Regione Molise. In verde quelle coperte dallo strumento.
I piani sono stati elaborati nel 1991 in formato cartaceo, seguendo un certo criterio di
coordinamento tra piano e piano.
Successivamente è stato dato incarico ad una società di servizi di digitalizzarne i contenuti, e di
renderli accessibili tramite un programma di consultazione. Questo è avvenuto vari anni fa, e la
piattaforma utilizzata è stata quella di ArcInfo, organizzando i dati in coperture separate,
articolate in “tiles” (o tessere) corrispondenti alle singole aree di piano, ma coordinate entro un
sistema di “library” che permetteva di visualizzarle in forma unificata su tutta la Regione.
Gli elaborati sono raggruppabili in tre categorie:
•
Carte di analisi;
•
Carte di sintesi;
•
Carte di progetto.
Ogn’una di queste categorie a sua volta si articola in temi:
Carte di analisi:
AN1
GEOLITOLOGICA
AN2
GEOMORFOLOGICA
AN3
IDROGEOLOGICA
AN4
GEOPEDOLOGICA E DELLE ATTITUDINI COLTURALI
AN5
VEGETAZIONALE E DEI CARATTERI FAUNISTICI
AN6
ESPOSIZIONI DEI VERSANTI
AA1
USI PRODUTTIVI DEL SUOLO
AA2
SISTEMA INSEDIATIVO
AA3
INFRASTRUTTURE
AI1
VINCOLI
AI2
DISCIPLINA URBANISTICA VIGENTE
AI3
INTERVENTI PUBBLICI
AE1
ASSETTO SOCIO - ECONOMICO
AP1
CARATTERI PERCETTIVI
12
Carte di sintesi
S1 CARATTERISTICHE QUALITATIVE DEL TERRITORIO
S2 ALTERAZIONE E DEGRADO DEL TERRITORIO
Carte di progetto
P1 TRASFORMABILITA' DEL TERRITORIO
P2 TRASFORMAZIONI PRIORITARIE DI SISTEMAZIONE E RIPRISTINO
P3 SCOSTAMENTI E INCOMPATIBILITA'
E ogni tema comporta in genere più di uno strato informativo. Quindi 3 categorie (p. es. Carte di
Analisi), per 16 temi (p. es. Sistema Insediativo), articolati in 158 strati informativi (p. es.
Tratturi e percorsi storici), articolati a loro volta in 8 zone, per un totale di 1264 tessere
cartografiche (non tutte effettivamente esistenti, molti strati contengono solo una o due tessere,
mancando l’informazione per le altre zone).
Gli 8 piani furono elaborati da gruppi diversi, seppure sotto un coordinamento di insieme
assicurato da un comitato di supervisione che doveva garantire la congruità degli elaborati. In
realtà tale congruità è molto relativa. A volte un tematismo che per un gruppo aveva una certa
valenza, per un altro ne aveva una diversa. Quindi le classi altimetriche di una zona possono
essere solo due, e per un’altra zona cinque. Questo tipo di problema è stato risolto individuando
un minimo comun denominatore, e affiancando alla legenda originale una nuova legenda
“riclassificata”, che dovrebbe avere una sua validità e uniformità su tutta la Regione. Le 2542
voci degli elaborati originali sono quindi state sintetizzate in 602 voci “riclassificate”.
A volte però la riclassifica non risolve il problema, perché fenomeni uguali possono essere stati
letti e presentati in forme diverse. Addirittura, un certo fenomeno che in un piano è stato
individuato come “di area”, in un altro piano può essere stato interpretato come “puntuale”, o
“lineare”. Ad esempio i tratturi in un piano sono definiti come area (corridoio) e in un altro come
linea (tracciato). In molti di questi casi gli strati informativi, per fenomeni in realtà identici,
restano separati.
In altri casi ancora un certo fenomeno è stato analizzato in dettaglio in un piano, e considerato
irrilevante e trascurato in un altro, e così via.
Inutile dire che nella gestione di una massa così importante di dati, sfuggono molti errori di ogni
genere, codifiche errate, associazioni di informazioni incongruenti in uno stesso strato ecc. Ad
esempio nella cartografia di piano riferita alle “incompatibilità e scostamenti”, a fianco a
“insediamenti produttivi” abbiamo trovato “isoiete”. Non avendo gli elementi per effettuare la
correzione (e non essendo la revisione del piano lo scopo che ci eravamo prefissi), la codifica è
restata quella; qualcun’altro dovrà metterci le mani. Ma è un’occasione per sottolineare che un
eccesso di complessità comporta di conseguenza anche forti difficoltà nel controllare gli errori e
la coerenza dell’insieme, difficoltà di consultazione, e in ultima analisi perdita di utilità e
significato del tutto. La regola del KISS (“Keep It Simple, Stupid!”) è sempre valida.
Lo specifico progetto del Centro Interregionale aveva come finalità quella di individuare
possibili strumenti software di interrogazione e di editing, e quindi potremmo anche sorvolare su
questi problemi, che non ci riguardano direttamente. Ma viene spontaneo avanzare alcune
osservazioni in proposito.
13
La prima riguarda la scarsa utilità di molti degli elaborati cartografici, che hanno un senso in
quanto elementi di indagine, a supporto di scelte effettuate, ma che nelle forme in cui sono stati
raccolti e consegnati non sono praticamente consultabili. L’uso di strumenti informatici
costituisce certamente un salto qualitativo determinante. I faldoni cartacei erano destinati a
raccogliere polvere in qualche scaffale, e salvo qualche elaborato finale con cogenza operativa,
le cartografie non venivano in pratica più consultate se non da qualche raro specialista o
studioso. Che incontrava comunque difficoltà sia nel reperimento dell’oggetto che nella sua
lettura.
Un piano informatizzato può essere agevolmente riprodotto copiando un CD, o reso consultabile
in rete, e la sua analisi e interpretazione, attraverso “query” a cursore, richieste di sintesi, o
sovrapposizione di tematismi, è enormemente maggiore. Ma l’informatizzazione non è un
toccasana, e proprio il processo di informatizzazione, che richiede un recupero e una
sistematizzazione del dato, ne evidenzia, se esistono, i limiti di partenza.
Per una valida gestione di insieme, a livello di Regione, definizione e codifica dei dati devono
essere rigidamente predefiniti; un processo di riclassifica a posteriori è faticoso, e porta nel
migliore dei casi a una forte perdita di informazioni.
Vanno inoltre distinte chiaramente quelle informazioni cartografiche che sono il risultato di
ricerche originali, da quelle che sono recuperate da altre fonti, soggette a revisione e
aggiornamento. Analizzando gli strati del PTP Molise si incontrano ad esempio informazioni
sulla pendenza del terreno, o sull’uso del suolo, che la ditta preposta alla digitalizzazione ha
faticosamente recuperato dalle basi cartacee, ma che sono oggi disponibili in forma molto più
dettagliata da fonti di facile accesso. I PTP, come tutti gli altri strumenti di piano, non possono
essere autoreferenziali (completi di una serie di elaborati sviluppati ad hoc), ma devono fare
riferimento a un Sistema Informativo Regionale, che comprenda strati di informazione
autonomamente e periodicamente aggiornati.
Si potrebbero anche sollevare dei dubbi sul senso che può avere, a fronte del rilevante sforzo e
investimento necessari, un meccanico recupero e informatizzazione dei singoli piani, qualora la
finalità sia, come in genere è, la gestione a livello regionale. In effetti la casistica teorica può
variare tra due estremi: da una parte ci si può trovare con una serie di piani di Zona sviluppati in
base a specifiche chiare e precise, e coordinati in maniera talmente perfetta, da permettere una
trasposizione meccanica e senza inconvenienti (omogeneità di definizione degli strati,
suddivisione standard dei fenomeni in classi, uniformità dei criteri di lettura e interpretazione
ecc.); all’altro estremo una situazione che presenta difformità di impostazione e rappresentazione
tali da rendere velleitario qualsiasi tentativo di ricompaginazione.
Il primo caso ovviamente non presenta problemi, le tessere incastrano perfettamente a formare
un quadro regionale complessivo. Nel secondo caso invece ogni tentativo è inutile; il piano
regionale va riprogettato, salvando il salvabile dagli elaborati di zona. Ma non si tratta più di un
lavoro meccanico di compilazione, bensì di un nuovo progetto, che richiede una revisione
radicale e competenze specialistiche. Non è, o non è soltanto, un compito da informatici. Almeno
in una delle Regioni con cui abbiamo preso contatto abbiamo incontrato una situazione di questo
tipo; il PTP regionale, più che un collage di PTP di zona, è stato generato come un vero e proprio
nuovo strumento, rivisto e ridefinito ad hoc.
In genere la situazione che si incontra è intermedia, molte cose si possono recuperare (anche se
va valutato attentamente anche il tempo trascorso: i piani e le informazioni invecchiano), altre
vanno scartate e sostituite. Il lavoro deve comunque, in questi casi (che sono la maggioranza)
essere svolto da un gruppo misto, dove siano presenti specialisti di pianificazione e territorio.
Non va affrontato come un processo neutro, delegabile solo ad informatici.
14
Stiamo ovviamente parlando della casistica che ci siamo proposti di affrontare; i PTP sono stati
elaborati all’inizio degli anni ’90, generalmente con elaborati tradizionali (carta da lucido e copie
eliografiche) e nel migliore dei casi con cartografia digitale CAD, non organizzata in formato
GIS.
Questo approccio oggi non è pensabile, e non è ammissibile. Gli strumenti di piano per il
territorio vanno elaborati e realizzati (o dovrebbero esserlo) fin dall’inizio utilizzando strumenti
GIS, coordinando le informazioni con il contenuto di un Sistema Informativo Regionale,
recuperando stratigrafie informative di base di uso generico, individuando una struttura dei dati
che faciliti revisioni e aggiornamenti. L’utilizzo di questi strumenti non va visto come un fattore
aggiuntivo, da inserire a posteriori, ma va inserito nella prassi di analisi e progettazione,
condizionando fortemente metodologie e approccio ai problemi. L’informatica come strumento
progettuale, e non solo come ausilio all’archiviazione e consultazione degli elaborati.
L’utilizzo corretto dell’informatica dovrebbe inoltre permettere di superare il concetto di piano
che si elabora, si consegna, si approva (e si archivia). In favore di una approccio dinamico, nel
quale non c’è discontinuità tra progettazione, applicazione, aggiornamento, gestione e
monitoraggio.
La Regione Sicilia, che per la sua particolare situazione ha ritardato l’elaborazione dei PTP, e
che solo adesso ne sta avviando l’attuazione, potrà essere un interessante banco di prova per
verificare un approccio di questo genere, che dovrebbe permettere di evitare tutti gli
inconvenienti fin qui elencati.
Resta da risolvere un problema di coordinamento interregionale, che a livello conoscitivo e
comparativo sarebbe importante. Progettisti e Pianificatori potrebbero reagire negativamente,
vedendo in ciò un attentato al loro ambito di decisionalità e scelta, ma sarebbe molto interessante
poter operare degli assemblaggi di piano tra Regioni, unendo insieme documenti perfettamente
confrontabili sia per quanto attiene gli elaborati di analisi che per quelli contenenti indicazioni
progettuali, vincolistiche e normative. Avrebbe un utilità metodologica, per ciò che attiene alle
modalità di affrontare problemi simili in diverse Regioni, e di confrontare politiche di intervento,
ed eventualmente (qualora sia previsto in futuro un adeguato monitoraggio degli effetti) i risultati
conseguenti. Ma avrebbe un’utilità operativa determinante per alcune zone con problematiche
interregionali, quali alcuni parchi ed aree protette che si estendono su territori di più Regioni
contermini.
In sede di progetto non abbiamo ancora l’ambizione di definire degli standard, né per la scelta
degli strati informativi legati ai piani, né per i criteri di classifica, né per quanto attiene alle
codifiche e legende. Ma sarebbe interessante se la disponibilità di questo prototipo da noi
elaborato potesse costituire un punto di partenza per un confronto e una discussione su questi
temi, in vista di una futura proposta di standards. Almeno per quanto riguarda simbolismi e
legende.
Approccio, metodologia e problemi pratici
Come abbiamo detto, nel caso del Molise c’era stata una prima operazione di informatizzazione,
fatta in un epoca e con strumenti diversi da quelli attualmente disponibili. La struttura era
gestibile solo da macchine centralizzate e costose, e la dimensione della banca dati costituiva un
fattore critico. Attualmente la situazione è alquanto mutata, i personal sono diventati molto più
potenti e di minor costo, le memorie disponibili non pongono più gli stessi limiti.
Una prima esigenza era quindi quella di unificare le “tessere” organizzate in “librerie”,
producendo delle semplici coperture in formato “shapefile”, con una struttura uniforme e
15
standardizzata, riducendo il numero di elementi almeno da 1264 (il numero di tessere) a 158 (il
numero degli strati informativi).
D’altra parte doveva essere possibile anche estrarre ed analizzare il contenuto di piano per ogni
singola zona di progetto, per cui l’informazione di “zona” (che nella vecchia struttura coincideva
con i confini della “tessera”) doveva essere mantenuta nella nuova configurazione.
A questo punto, dovendo prevedere una codifica di “zona”, e un’articolazione del dato grafico
conseguente, abbiamo ritenuto utile prevedere anche la suddivisione degli strati e la conseguente
codifica per limiti comunali. Il vantaggio è quello di poter consultare e interrogare gli elaborati
per singolo comune, il che riteniamo possa essere utile (il sindaco del comune Tale può ottenere
agevolmente la rappresentazione dei vincoli applicati entro il suo ambito amministrativo, e la
tabella degli ettari soggetti ad ogn’uno dei diversi vincoli). L’inconveniente è un certo
appesantimento della banca dati, e la comparsa, nelle cartografie di insieme, di alcune linee
divisorie ausiliarie in più del necessario, lungo i confini comunali. Abbiamo comunque ritenuto
che i vantaggi fossero maggiori degli inconvenienti.
Figura 10 – Tutti gli strati sono visualizzabili per l’intera Regione (in alto), per zona di piano (a sinistra) o per
singolo comune (a destra). Ad ogn’uno di questi livelli può essere richiesta una tabella di sintesi con le superfici o
altre informazioni.
16
Se si richiede un elaborato particolarmente curato, di insieme, si può ricorrere ad un’operazione
di “dissolve”, eliminando eventualmente la copertura ausiliaria così ottenuta al termine dell’uso.
Alcuni pacchetti “software” ammettono inoltre un “dissolve” virtuale, che evita anche la
costruzione di una copertura ausiliaria. Dato che ArcView non lo fa, abbiamo incluso un
comando (tasto “D”) con questa funzione. Il tasto crea uno shapefile di appoggio, denominato
temp.shp (che verrà eliminato e sostituito al seguente utilizzo del comando).
Ogni strato poligonale ha quindi una tabella di attributi standard con i seguenti contenuti:
Il codice ISTAT del comune, la zona di piano (Vincolo), il codice di provincia, l’area in ettari, la
codifica originale, quella riclassificata, la decodifica del codice riclassificato, e un codice di
simbolo. Tutti gli strati poligonali hanno la stessa struttura. Quelli lineari hanno la lunghezza al
posto dell’area (in metri). Quelli puntuali ovviamente nè area nè lunghezza. Ma il resto dei dati è
lo stesso.
La tabella non è evidentemente normalizzata (la normalizzazione, in una banca dati relazionale,
consiste nella minimizzazione, o al limite l’eliminazione, di ogni rindondanza, grazie ad un
sistema di tabelle tra loro relazionate), ma è stata prevista così per facilitarne l’uso. Il testo
descrittivo è rindondante, una corretta tabella normalizzata avrebbe contenuto solo il codice, e
una seconda tabella da collegare con la decodifica. La codifica originale (liv_orig) funziona
effettivamente così (come il nome del comune, o quello della provincia). Ma il vantaggio di
avere il testo già decodificato è che ArcView, se si apre un tema, recupera automaticamente la
legenda collegata, e disegna il tema nella maniera e con la legenda corretta. Se la tabella fosse
normalizzata bisognerebbe aprire il tema, recuperare la tabella di decodifica, effettuare il “link”
tra le due tabelle, e poi recuperare la legenda manualmente. E’ un compromesso utilitario. Lo
stesso vale per il codice di provincia, e al limite anche per l’area di piano (attributo “Vincolo”). Il
codice di provincia è estraibile da quello ISTAT, e l’articolazione in zone di piano poteva essere
delegata (ma solo in questo caso, nel quale le zone di piano sono aggregazioni di comuni
completi) a una tabella autonoma che elencasse i codici di comune associati ad ogni area di
piano.
Si è scelto di esplicitare solo la codifica riclassificata, in quanto si ritiene che quella sia
l’interrogazione più interessante, con la possibilità di confronti omogenei sull’intera regione.
Come si è detto, in un Piano sviluppato dall’inizio come si deve, non dovrebbe nemmeno esistere
la duplice codifica. Comunque, per chi volesse recuperare la codifica originale, il dato è
preservato.
L’attributo “symbol” si riferisce alla rappresentazione di ArcInfo, probabilmente non servirà mai
a niente, ma è stato preservato per prudenza, potrebbe essere ancora utile, se si sviluppa una
17
procedura che associa una rappresentazione al codice. Per ora la forma di rappresentazione è
invece legata a un file di legenda (.avl) collegato al nome della copertura, che decodifica
l’attributo “label”.
Da un punto di vista puramente metodologico, avremmo preferito evitare coperture con elementi
“ballerini” nel vuoto. Anche se la struttura del file “shape” non è topologica, per una corretta
gestione è preferibile che la coerenza topologica sia mantenuta, e che ogni strato copra l’intera
Regione, anche se poi i poligoni significativi sono piccoli ed isolati. E riteniamo preferibile
evitare sovrapposizioni tra poligoni. Anche in questo caso ci sono i pro e i contro. Nel modo da
noi suggerito, per ogni Comune, ad esempio, una tabella di aree avrà una somma costante: l’area
complessiva del Comune. L’area vincolata (se ad esempio la cartografia rappresenta un vincolo)
sarà eventualmente molto piccola, l’area non vincolata grande. La somma sarà l’insieme del
Comune. Se non si agisce così si ottiene solo il primo dato, che è certamente quello significativo,
ma si perde una informazione di verifica e controllo.
Figura 11 – Un esempio di strato cartografico dove l’informazione significativa è sparpagliata in piccoli poligoni.
In linea di principio riteniamo preferibile organizzare il dato coprendo l’intera regione, generando anche i poligoni
che definiscono le aree complementari (in grigio).
Per vari motivi non sempre è stato possibile attenerci a questa regola. In alcuni casi abbiamo
evitato di generare le aree complementari, in quanto forse si poteva procedere all’assemblaggio
di più strati in uno solo, e abbiamo voluto lasciare aperta e facilmente praticabile questa
eventualità. In altri casi non l’abbiamo fatto, in quanto l’area si estende all’esterno dei confini,
“sbordando” per qualche motivo (una carta, ad esempio, riporta la fascia di mare potenzialmente
inquinato, un’altra alcuni elementi viabilistici contermini, ecc.). Quindi non si tratta di
un’indicazione rigida, ma di una preferenza.
L’altra preferenza, più motivata, è quella di evitare sovrapposizioni tra poligoni. Gli strati di
vincolo, ad esempio, sono articolati su nove files. Potrebbero tranquillamente essere concentrati
in un unico file, in due modalità diverse. La prima semplicemente per poligoni che si
sovrappongono tra di loro (“overlap”), in forma non topologica. La seconda creando tutte le
possibili intersezioni tra poligoni. Nel primo caso la struttura tipo della tabella potrebbe venire
preservata, ma la somma delle aree non avrebbe un significato logico, si potrebbe ottenere
un’area molto superiore all’area complessiva regionale, dato che molti vincoli si sovrappongono
l’uno all’altro. Inoltre per interpretare le visualizzazioni si dovrebbe comunque procedere per
18
selezione, e quindi il vantaggio ricavato dalla unificazione del file sarebbe annullato. La seconda
alternativa è più interessante, e può anche venire generata a titolo di esempio. Avrebbe il
vantaggio di permettere di ricavare, con un unica interrogazione, la lista di vincoli relativi a un
punto determinato del territorio. Ma richiede una struttura degli attributi completamente diversa
da quella standard sopra indicata.
Per quanto riguarda la cartografia di base, sulla quale “appoggiare” le informazioni, il Molise
dispone di un’ottima cartografia a scala 1:5.000 (Carta Tecnica Regionale – CTR), oltre ad una
carta “raster” ricavata dall’IGM 1:25.000. Il programma di visualizzazione chiede se si vuole
visualizzare o meno la cartografia di riferimento. Se si attiva la richiesta della cartografia base,
non viene chiesto di specificare quale si vuole. La scelta è demandata al livello di “zoom”. Da
1000 a 8.000 viene visualizzata la CTR, tra 8.000 e 40.000 la IGM. Al di sotto o al di sopra le
carte apparirebbero troppo “sgranate” o troppo “infittite”, e non vengono visualizzate.
Si è scelto di utilizzare la carta in formato raster, anche se per il Molise è disponibile la CTR in
forma vettoriale, per vari motivi, non ultimo quello di limitare la diffusione di un’informazione
(la CTR vettoriale) proprietaria e a distribuzione controllata.
La cartografia raster, anche se l’abbiamo chiamata cartografia “di sfondo”, viene visualizzata
dal programma come ultimo strato, al di sopra di tutti gli altri, ma rendendo trasparente il bianco
della carta, il che permette in genere di leggere senza inconvenienti le informazioni sottostanti.
Per quanto riguarda la forma di organizzazione del dato raster, esistevano diverse possibili
soluzioni: compressione di tutte le carte in un file unico in formato MrSid o in formato ECW di
ERmapper (entrambi i formati sono supportati da ArcView, anche se MrSid viene incluso “di
fabbrica” e per ERmapper bisogna aggiungere un piccolo file “driver” gratuito, reperibile su
internet), oppure utilizzare un’estensione aggiuntiva che “cataloga” i diversi files che nel loro
insieme coprono l’area regionale. Abbiamo testato tutti e tre i sistemi, trovandoli tutti
soddisfacenti.
Figura 12 – La Carta Tecnica Regionale (CTR) sovrapposta a un tematismo di progetto.
19
Figura 13 – La cartografia IGM all’1:25.000 sovrapposta a un tematismo di progetto. L’area (a una scala minore)
e il tema sono gli stessi della figura precedente.
Nel prototipo abbiamo utilizzato la terza soluzione, quella del “catalogo”, che mantiene i files
nel formato originale (nel nostro caso .TIF con file di georeferenziazione .TFW ) presentando di
volta in volta quelli richiesti dalla schermata. Il vantaggio di questa soluzione è che non richiede
la generazione di un nuovo file, di non semplice costruzione, e che va effettuato mediante un
software complesso e non troppo economico (si tratta comunque di un operazione “una tantum”,
che può essere facilmente effettuata “in service”). Inoltre non c’è nessun decadimento nella
definizione delle immagini. Lo svantaggio è dato dall’occupazione di memoria molto maggiore,
da un proliferare di files non facile da controllare, e dall’inclusione nel sistema di files raster
originali, che non sempre la Regione ritiene di poter diffondere liberamente.
Il Ministero dell’Ambiente ha messo a disposizione delle Pubbliche Amministrazioni tramite
connessione in rete internet anche l’ortofotopiano a scala 1:10.000 (dettaglio equivalente a ...), e
quindi il programma prevede anche un tasto per visualizzare, se connessi in rete, questo tipo di
cartografia, che può risultare estremamente utile per verifiche e aggiornamenti. Trattandosi di un
immagine deve per forza essere visualizzata al di sotto delle altre informazioni (strato di sfondo),
e quindi in genere le indicazioni vettoriali vanno ridotte a linee (perimetro dei poligoni) per non
nascondere lo sfondo. Il sito non sempre è attivo, crediamo vi siano i soliti problemi di diritti
proprietari sull’informazione, e non sappiamo quindi fino a che punto ci si potrà fare
affidamento. Finchè dura costituisce un iniziativa molto importante, effettuata nella giusta
direzione, di garantire l’accesso a informazioni standardizzate e di dominio pubblico.
La costruzione degli “shape files”
Come si è detto, nella sperimentazione sul Molise abbiamo incontrato una situazione molto
particolare: esistevano cioè delle coperture ArcInfo, organizzate per “tessere” e “libraries”, che
andavano convertite in “shape files”. Inoltre volevamo ristrutturare il contenuto della tabella
eliminando attributi inutili, ma aggiungendo la definizione esplicita (“label”), aggiungendo dei
campi di misura di area o lunghezza, e in più l’informazione relativa alla disaggregazione
comunale. Per quanto particolare, descriviamo la procedura seguita perchè potrebbe essere
d’aiuto a qualcuno.
•
Per prima cosa, abbiamo creato una copertura poligonale con i confini comunali, e con
solo gli attributi che si volevano incorporare nella copertura finale. Nel nostro caso:
Codice ISTAT, Zona di piano e Codice Provincia. Stiamo facendo l’esempio per il
Molise, dove le zone di Piano sono aggregati di comuni. Non sempre è così: in Sicilia le
20
zone di Piano tagliano i comuni. In questo caso la copertura da predisporre sarà un poco
più complicata, ma la sostanza non cambia.
•
Poi abbiamo dovuto visualizzare il tema su ArcView, ricavandolo dalla libreria ArcInfo
(in realtà abbiamo anche dovuto ricostruire la libreria ArcInfo, che per la sua
configurazione è difficilmente trasportabile da un computer all’altro). In ArcView
quando si aziona il comando di aggiunta di un tema, appare un opzione a scelta cui in
genere non si fa caso (directory o library?). Normalmente si accetta il default: directory.
Se invece si sceglie una library, appaiono i layers disponibili per quella library. Se ne
sceglie uno, e si va subito incontro a quello che si può considerare un baco di ArcView.
Invece di creare come “default” un tema con tutto il layer, per “default” si visualizza una
sola delle tessere, a caso. Per visualizzare l’intero layer bisogna usare un tastino
sconosciuto, che compare a sorpresa solo in questa situazione (con una icona simile al
tasto di selezione, ma con un quadratino nero all’interno), col quale bisogna selezionare
l’intera area di interesse. Nel nostro caso tutta la Regione, sbordando abbondantemente
per prudenza. Solo allora il tema appare completo.
Figura 14 – Quello che si vede per “default” (una tessera a caso della library) e l’intero layer, visualizzato dopo
che si è selezionata l’intera area di interesse (AOI – Area Of Interest) usando il pulsantino misterioso evidenziato a
sinistra.
•
A questo punto si è creato un tema con l’intero “layer” completo di tutte le sue tessere;
bisogna ora richiamare la tabella di proprietà del tema, effettuare un “link” con la tabella
che decodifica i codici “riclassificati”, e disattivare poi dalla tabella risultante tutti gli
attributi ritenuti inutili.
21
Figura 15 – Due coperture sostanzialmente equivalenti, sulle “alterazioni e degrado del territorio”. In quella a
sinistra sono stati generati solo i poligoni significativi, e quindi i “buchi” sono effettivamente vuoti. In quella a
destra sono stati generati anche i poligoni complementari, che permettono di calcolare le aree non degradate,
comune per comune. In questo secondo caso, anche i “buchi” hanno valore di area complementare, e devono
esistere come poligoni. In genere questi poligoni complementari non verranno visualizzati.
•
Ora siamo quasi pronti alla conversione in “shape file”. C’è ancora un’operazione
prudenziale da fare. Dato che la copertura ArcInfo è topologica, e lo “shape file” no, le
due si comportano in modo diverso per ciò che concerne i “buchi nella ciambella”, i
poligoni isola vuoti all’interno di aree poligonali. Nella copertura topologica, i “buchi
nella ciambella” sono comunque dei poligoni, ma con l’attributo di codifica (e quindi la
“label”) nullo. Nello “shape file” invece normalmente il buco è un buco, non c’è
poligono. Ma se si avvia la conversione a “shape file” senza aver filtrato i “buchi”
topologici, nello “shape file” risultante appariranno degli inutili (e pericolosi, possono
ingenerare molti equivoci) poligoni con attributo nullo. Vanno quindi filtrati,
selezionando dalle proprietà del tema ArcInfo solo gli elementi con “label” non nulla (<>
“”). Questo vale ovviamente se si desidera generare una copertura con solo le aree di
interesse, e non vale se si vogliono generare anche le aree complementari
•
Fatto questo si aziona il comando “Convert to shapefile” (dal menu “Theme”), e
otteniamo uno shapefile come desiderato. Solo che il tema non ha ancora la
disaggregazione per comuni e zone di piano. Un altra nota su questo passo. Nella
conversione da una copertura ArcInfo a uno shapefile, vengono esportate solo le colonne
attive della tabella, le altre scompaiono. Ma se la conversione è da shapefile a shapefile,
come avviene nella operazione seguente, la tabella viene ricopiata completa. Solo le
colonne attive saranno visibili nel risultato, ma anche le altre saranno presenti (anche se
momentaneamente disattivate) occupando uno spazio inutile e appesantendo il tutto. In
questo caso per eliminare le colonne indesiderate bisognerà editare la tabella, cancellando
gli attributi in eccesso (“delete field”).
•
L’ultima operazione è quella di incrocio (“overlay”) tra la copertura ottenuta fin’ora e
quella con i confini comunali e le zone di piano. Il caso più comune e semplice è quello
tra due coperture poligonali. Volendo ottenere anche le aree complementari (immagine di
destra della figura precedente) si attiverà l’estensione “geoprocessing” (dal menu “File”,
comando “extensions”, e poi scelta dell’estensione che si desidera), si attiverà il pannello
di comandi dal menu “View” (comando “Geoprocessing Wizard”, che compare solo
dopo aver attivato l’estensione) e si sceglierà l’opzione “Union”. Il resto del
procedimento è guidato con molta chiarezza. Se si vuole una copertura con solo le aree
22
significative (immagine di sinistra), si sceglierà l’opzione “intersect”. Volendo invece
effettuare l’incrocio su una copertura lineare (ad esempio una copertura con i percorsi di
interesse turistico, che si vuole disaggregata per comuni, per poter calcolare l’estensione
dei percorsi che interessano ogni singolo comune) bisogna usare l’opzione “intersect”.
Ma bisogna stare attenti, in quanto a volte nella copertura di origine, per facilitare la
comprensione di certi percorsi, vengono incluse anche delle tratte esterne alla Regione,
ma contermini, e che servono per creare dei collegamenti nella rete. L’operazione di
intersect rischia di eliminare questi elementi di contorno. Bisogna quindi creare una
copertura di intersezione che contenga anche un’area nulla (esterna all’area di interesse)
tutto attorno. Questo si può fare, ad esempio, usando il comando Buffer (ma anche
facendo una Union con un bel rettangolone grande) e poi effettuando una “union” del
risutalto con la copertura di origine. Il comando “Buffer” è disponibile sotto il menu
“Theme” (a volte è fonte di bestemmie il fatto che non si attiva il comando se non sono
state “settate” le unità di misura, nelle proprietà della View. Val la pena di ricordarlo).
Figura 16 – Un buffer di 20 km. attorno alla Regione Molise.
•
Un’ultima situazione è quella relativa alle coperture puntuali. Anche in questo caso è
utile collegare ad ogni record l’informazione relativa al comune di appartenenza, per
poter sapere quante abbazie benedettine ci sono nel comune Tale. Il modo più semplice è
tramite un “join” tra la tabella di attributi della copertura puntuale, e quella della
copertura con i confini comunali. Anche in questo caso risulta conveniente l’uso della
copertura con la corona esterna: a volte ci sono punti fuori confine, in mare di fronte alla
costa, in prosecuzione di percorsi ecc. Il “join” si fa selezionando come campo di unione
il campo “shape” sulle due tabelle, si attiva il “join” ed è fatta. Il risultato, che è completo
ma temporaneo, si rende permanente con un comando di “create shapefile”, che genera
una nuova copertura di punti completa delle nuove informazioni.
•
Nella tabella di attributi sono state incluse le colonne “area”, per i temi poligonali, e
“length” (avremmo anche potuto usare “lungh” o qualcosa di simile, ma abbiamo scelto
di mantenere i nomi standard di ArcInfo), che a questo punto non sono aggiornate.
Abbiamo aggiunto al progetto un tasto di aggiornamento (tasto “A”), che tra altre cose
23
ricalcola i valori di “area” con il corretto valore in ettari, e i valori di “length” con
l’estensione in metri.
Per quanto possibile agli shapefiles sono state associate delle legende (file *.avl) che al momento
di richiamare il tema lo presentano già “vestito” con i simbolismi desiderati.
Per poter gestire l’insieme di informazioni è stato inoltre creata una tabella che agisce da indice.
Figura 17 – La tabella “indice”, che contiene la lista degli strati informativi disponibili, il nome del file, la
categoria di appartenenza, il titolo del tema, il tipo di geometria (poligono, linea o punto), le zone (aree di piano)
coinvolte dall’informazione, un campo che registra l’esistenza o meno del file, e un campo che registra l’esistenza o
meno della legenda.
Questa tabella è quella che permette di creare un programma flessibile, applicabile a qualsiasi
collezione di strati informativi. Il programma attinge la lista e le caratteristiche degli strati da
questa tabella, che può facilmente venire modificata o sostituita.
Quando si apre il progetto con una View, appare nella barra dei bottoni un tasto con una “A”.
Premendo il tasto si lancia una procedura che aggiorna la tabella indice. La procedura controlla
l’effettiva esistenza del file (succede che il file non sia stato ancora creato, ma sia previsto, e il
suo nome compaia quindi nella lista), e registra l’esistenza nella colonna “Esiste”. Poi controlla
l’esistenza di una legenda collegata, e lo registra nella colonna “Legenda”. Poi apre i file, e
controlla, area di piano per area di piano, l’esistenza di elementi significativi per quell’area.
Controlla cioè sia l’esistenza di elementi (poligoni, linee o punti) appartenenti all’area, sia la
presenza di una “Label” non nulla. Abbiamo già detto, infatti, che metodologicamente
preferiamo, nel caso di coperture poligonali, una copertura continua, che contenga anche i
poligoni non significativi, complementari. In questo caso, il poligono esiste, ma l’informazione è
nulla (area senza vincolo, o area non di interesse paesaggistico, ecc.).
Il programma aggiorna la tabella indice, e allo stesso tempo effettua una verifica dello stato delle
coperture, denunciando ad esempio l’assenza della colonna “Vincolo” o altri errori di
costruzione. Aggiorna i valori di AREA (in ettari) per i files poligonali, e di LENGTH
(lunghezza in metri) per i files lineari. Aggiorna il campo TIPO dela tabella indice (Tipo = 1 per
i poligoni; 2 per le linee; 3 per i punti). Si tratta quindi sia di una procedura di aggiornamento,
che un ausilio nella sequenza di operazioni che portano alla costruzione del sistema, fornendo
informazioni di “debug” e uno stato di avanzamento del lavoro. Il messaggio alla fine
dell’aggiornamento (che può richiedere qualche minuto) segnala il numero di files registrati
nell’indice, e il numero di quelli effettivamente riscontrati nella directory.
24
Figura 18 – Poligoni di risulta della carta geolitologica entro l’area della zona di piano 0, che non dovrebbe
contenere informazioni. I poligoni sono molto piccoli, si tratta di un dettaglio molto ingrandito.
Da sottolineare un altro ausilio alla costruzione del sistema di strati che può essere fornito dalla
tabella indice e dalla procedura di aggiornamento. Se si è seguito l’iter descritto per la
generazione degli shapefiles, è facile che si siano generati dei poligoni “sprinter” (schegge, o
sfridi) in quanto in genere la copertura dei confini comunali è più precisa, o semplicemente un
po’ diversa, dai confini di zona presenti nei diversi strati. Succede quindi che zone di piano per le
quali è noto che non esiste informazione per quel determinato strato, appaiano invece come
presenti in tabella. Si tratta di scarti che andranno eliminati. Il modo più semplice, se
appartengono tutti ad una zona che si sa non dovrebbe contenere informazioni per quello strato, è
quello di selezionarli con una interrogazione, eventualmente da tabella (seleziona Vincolo = 0,
ad es.) e cancellarli tutti in un colpo solo.
Dopo l’editing e l’eliminazione si può far girare di nuovo la procedura di aggiornamento, e la
tabella riporterà la situazione corretta.
25
Il programma di visualizzazione
Il programma di visualizzazione è stato concepito per un massimo di flessibilità possibile, e le
funzioni inserite sono quelle che si pensa possano rivelarsi utili nelle situazioni più generiche.
Il programma propone una schermata iniziale con tre tasti, che selezionano l’ambito di
consultazione: Intera Regione; singola Zona; singolo Comune.
Se si sceglie l’intera Regione, si passa direttamente alla scelta dei tematismi. Se si sceglie un
ambito parziale, la schermata seguente richiede l’individuazione del Comune o della Zona.
26
Si può cliccare in successione su diversi comuni, se si ha qualche dubbio, e il loro nome appare
al di sopra del tasto (lo stesso avviene per le Zone). Quando si è individuato quello giusto, si
batte l’OK, e si passa alla selezione dei temi.
La schermata di scelta propone la lista degli strati informativi disponibili, separati in coperture
poligonali, lineari e puntuali. La lista degli strati disponibili è ricavata dalla tabella indice, e
contiene quindi solo gli strati significativi per la scelta effettuata. Se si è scelto di visualizzare
l’intera Regione, gli strati saranno tutti quelli esistenti. Se si sceglie di visualizzare una Zona, la
lista conterrà solo gli strati che contengono informazioni per quella specifica Zona, e sarà quindi,
in genere, più corta. Come abbiamo visto, la tabella indice non contiene questa informazione
comune per comune, quindi, scegliendo di visualizzare un singolo comune, la lista conterrà tutti
gli strati che contengono informazioni significative per la Zona di appartenenza del comune,
anche se può succedere che non contengano informazioni per quello specifico comune. Si tratta
di un compromesso, per non appesantire la tabella indice, che abbiamo ritenuto accettabile.
Nella figura gli strati sono tutti quelli esistenti, e come si può vedere quelli poligonali non ci
stavano in un unica lista, che è stata quindi duplicata dal programma con una lista “polig (cont)”.
Vengono selezionati i tematismi che si intendono visualizzare utilizzando il cursore e cliccando
sul quadratino bianco. Viene inoltre indicato allo stesso modo se si desidera visualizzare la
copertura di base (non viene richiesto se si vuole la CTR o l’IGM, in quanto la scelta di quale
mostrare dipenderà dalla scala di visualizzazione). E poi viene dato l’OK al programma.
Le coperture verranno visualizzate in sequenza, con sopra a tutte la copertura base, seguita dalle
coperture lineari, puntuali e infine le poligonali. Viene anche visualizzato un tema con i confini
27
comunali, che serve da inquadramento, soprattutto quando non siano visibili le cartografie di
base.
La modalità di visualizzazione dei temi è determinata dal file di legenda, che dovrebbe essere
presente per ogni shapefile. Il file indice contiene l’informazione relativa all’esistenza o meno
della legenda, che aiuta quindi nell’operazione di completamento delle informazioni. Il file
indice è un file .DBF (NOMEF.DBF) è può quindi essere aperto come tabella e consultato da
ArcView. Se la legenda non esiste, il tema viene creato lo stesso nell’identico modo degli altri,
ma con una campitura unica. Se si desidera creare o modificare una legenda, la si definisce
usando gli strumenti di arcView, e poi la si salva, nella stessa directory e con lo stesso nome
dello shapefile (cambia la desinenza, .AVL invece che .SHP). Per aggiornare il file indice,
registrando l’esistenza della nuova legenda, basterà attivare di nuovo il relativo bottone (“A”).
La legenda sarà comunque attiva fin dal momento della sua creazione, indipendentemente
dall’aggiornamento del file indice, che ha, in questo caso, solo funzione di pro memoria.
Resta evidenziato nella barra dei comandi il tasto di inizializzazione, che permette di riproporre
l’intero processo, tornando alla prima schermata, per generare una diversa presentazione.
Il programma propone a questo punto alcune funzioni ausiliarie di consultazione, che
descriviamo a seguito. Per rendere immediatamente riconoscibili la serie di comandi aggiuntivi
che abbiamo inserito, questi sono stati in genere caratterizzati da lettere maiuscole. Ogni
comando ha inoltre una targhetta (tag) che compare in giallo quando il cursore si avvicina, e un
messaggio esplicativo della sua funzione che compare in basso sullo schermo.
I tasti di “Vettorizzazione” e “Ripristino”
Una delle funzioni che si desiderano sfruttare esaminando gli elaborati digitali, è quella di
confronto tra più tematismi. Ma questo risulta in genere difficile in quanto l’ultimo tema
aggiunto copre quelli precedenti.
Figura 19 – Dettaglio di una carta con l’uso del suolo e, a destra, la stessa carta combinata con l’informazione sul
vincolo di immodificabilità temporanea. La campitura opaca nasconde l’informazione sottostante.
Per rendere confrontabili le due informazioni, è stato inserito un tasto di “vettorizzazione della
campitura”, che trasforma la campitura del tematismo in una campitura rigata con le righe dello
stesso colore del colore principale (di “foreground”, nell’esempio il rosso del puntinato). Questo
permette di vedere in trasparenza il tema sottostante. La trasparenza viene mantenuta in fase di
stampa o plottata dell’immagine (operazione che con ArcView a volte genera risultati inattesi).
Il comando di vettorizzazione (bottone con una “V” sopra) ad ogni applicazione successiva ruota
la campitura di 45°. Quindi se vengono vettorizzati in successione quattro strati informativi, il
28
primo avrà una rigatura a 45°, il secondo a 90° e così via. Ovviamente non consigliamo a
nessuno di sovrapporre più di due, massimo tre strati (contando quello di sfondo a tinta piena).
Ma nel caso, le informazioni, con molta attenzione, sarebbero ancora distinguibili. Schiacciando
in successione il tasto “V” sullo stesso tema, si possono provare su uno stesso strato le varie
inclinazioni di campitura rigata. Ad esempio, nel generare l’immagine riportata a seguito, il
primo tentativo aveva generato una rigatura verticale, che interferiva con la campitura verde
rigata delle zone coltivate ad olivo. Un nuovo comando “V” ha prodotto la campitura a 45°.
A fianco al tasto di vettorizzazione ne esiste un’altro di ripristino della legenda (bottone con
sopra una “R”) che fa tornare le campiture a quelle definite nella legenda di default.
Figura 20 – La campitura della carta dei vincoli “vettorizzata” e resa quindi trasparente. A destra la stessa
immagine, con sovrapposta la carta IGM 1:25.000.
Sommario del tema
Un tastino con la lettera “S” attiva una funzione che crea una tabella con il sommario del tema
attivo. Si possono quindi ottenere, a seconda dell’area visualizzata, tabelle di sintesi generali per
la Regione, tabelle per zona, o per singolo comune.
La tabella sommario ha come titolo visualizzato il nome del tema (non il nome del file, che
potrebbe generare errori, ma il nome del tema così come compare nell’indice dei files e nella
legenda della View), è una tabella in formato .Dbf, e contiene i campi Label, con i nomi delle
varie zone elencate nel tema, la colonna Sum_Area, con la somma complessiva delle superfici
dei poligoni appartenenti a quella categoria, e la colonna Count, con il numero di tali poligoni.
Funziona anche su temi lineari, fornendo la somma delle lunghezze, e il conteggio dei segmenti.
La tabella, dopo creata viene caricata e visualizzata. Si tratta di una cartella provvisoria, dal
nome reale temb.dbf, che verrà sovrascritta da una successiva chiamata allo stesso tasto. Per
renderla permanente bisogna cambiargli nome, salvandola con il comando “Export” del menu
“File”.
Dissolve
Per vari motivi la visualizzazione di certi strati può apparire inutilmente frazionata da linee di
confine tra poligoni uguali. Queste linee sono conseguenza sia della riclassifica dei codici, che
dell’inserimento delle suddivisioni provinciali e comunali.
29
Se si richiede un elaborato particolarmente curato, che non mostri queste linee indesiderate, si
può ricorrere ad un’operazione di “dissolve”, eliminando eventualmente la copertura ausiliaria
così ottenuta al termine dell’uso. Alcuni pacchetti “software” ammettono inoltre un “dissolve”
virtuale, che evita la costruzione di una copertura ausiliaria. Dato che ArcView non lo fa,
abbiamo incluso un comando (tasto “D”) con questa funzione. Il tasto crea uno shapefile di
appoggio, denominato temp.shp (che verrà eliminato e sostituito al seguente utilizzo del
comando), e visualizza un tema con lo stesso nome e la stessa legenda del tema selezionato, ma
privo delle linee superflue.
Figura 21 – L’effetto del tasto “D”. A sinistra il tema originale, con tutte le linee ausiliarie, a destra quello
modificato, “pulito” da linee indesiderate.
Dato che questo dovrebbe essere lo strato di sfondo, non è previsto dal programma che se ne
costruiscano più di uno per volta. Se si tenta di crearne due, il secondo sostituirà il file del primo,
con effetti imprevisti e indesiderati (volendo salvare un file “dissolto” bisogna andare a cercarlo
da sistema, e cambiargli il nome; o dare un comando “convert to shapefile” dal menu “Theme”,
con risultati equivalenti), ma va tenuto presente che questo file ausiliario contiene soltanto il
campo “Label” e le aree di sintesi ricalcolate).
La visualizzazione delle relazioni
Ai PTP sono allegati una serie di testi esplicativi, norme, descrizioni ecc. Per la consultazione di
questi testi è stata inserita, sulla barra di Menu, la voce “Specifiche”, che si apre elencando i
documenti a disposizione. Cliccando su uno di questi si apre una finestra con il testo
corrispondente.
Il tasto di Aggiornamento
Il tasto “A” è già stato descritto nelle pagine precedenti. Premendo il tasto si lancia una
procedura che aggiorna la tabella indice, che agisce anche sui files, elencati aggiornando i campi
di area e lunghezza.
La procedura controlla l’effettiva esistenza di ogni file elencato (succede che il file non sia stato
ancora creato, ma sia previsto, e il suo nome compaia quindi nella lista), e ne registra l’esistenza
nella colonna “Esiste”. Poi controlla l’esistenza di una legenda collegata, e lo registra nella
colonna “Legenda”. Poi apre i file, e controlla, area di piano per area di piano, l’esistenza di
elementi significativi per quell’area. Controlla cioè sia l’esistenza di elementi (poligoni, linee o
punti) appartenenti all’area, sia la presenza di una “Label” non nulla.
La procedura aggiorna la tabella indice, e allo stesso tempo effettua una verifica dello stato delle
coperture, denunciando ad esempio l’assenza della colonna “Vincolo” o altri errori di
30
costruzione. Nei singoli file aggiorna i valori di AREA (in ettari) per i files poligonali, e di
LENGTH (lunghezza in metri) per i files lineari. Aggiorna il campo TIPO della tabella indice
(Tipo = 1 per i poligoni; 2 per le linee; 3 per i punti).
I layouts
Sono stati predisposti alcuni “layout” tipo, che permettono di produrre rapidamente delle stampe
di cartografie. Per ora quelli inseriti sono due, denominati “A3” e “A4”, che hanno ovviamente i
due corrispondenti formati. Il programma provvede anche a modificare il titolo, inserendo il
nome del Comune o della Zona rappresentati.
Figura 22 – Una carta tratta dal programma, layout A3, senza alcun altro intervento. Come è noto ArcView
permette di apportare facilmente modifiche, e quindi questi schemi vanno considerati come base di partenza per
aggiustamenti più precisi.
Il programma di editing
Dato che il programma di editing può fare delle cose terribili ai files, è stato organizzato in un
diverso progetto, che verrà utilizzato solo da utenti esperti. Il programma propone una serie di
funzioni di ausilio nella costruzione e correzione degli shapefiles, e in particolare di quelli
poligonali. Il programma è stato sviluppato nell’ipotesi che i files non siano proiettati, o meglio,
che la proiezione (UTM 33 nel nostro caso) sia già incorporata “hard” nella definizione della
carta, e che non sia invece effettuata sul momento dal programma stesso. Per le icone dei tasti
sono state usate le stesse convenzioni del programma di visualizzazione, e i tasti nuovi (salvo i
due per aggiunta o modifica grafica dei poligoni) sono caratterizzati da una lettera.
31
Il problema che si voleva fondamentalmente risolvere con questo programma, è quello della
gestione del formato non topologico. Lo “shapefile” di ArcView è molto comodo da gestire, ma
dato che lavora per poligoni chiusi, non garantisce in maniera intrinseca che la linea di confine
tra due poligoni adiacenti coincida perfettamente. In una struttura topologica, la linea di confine
è una sola, in una struttura non topologica, la linea di confine viene duplicata, una volta per
definire il contorno del poligono di destra, una volta per quello di sinistra. Questo comporta il
rischio sia di creare delle aree di sovrapposizione difficili da individuare (e che possono alterare
completamente calcoli delle aree e altre elaborazioni), sia zone scoperte, in particolare piccole
“schegge”, dette anche micropoligoni, lungo i confini.
Figura 23 – Due poligoni non topologici affiancati, con aree di sovrapposizione e con “schegge” vuote.
Il programma di editing mette a disposizione alcuni strumenti che aiutano a risolvere il
problema. Una prima funzione “batch” dovrebbe permettere di individuare ed eliminare le
sovrapposizioni eventuali, mentre altre funzioni di “taglia” e “rinomina” dovrebbero permettere
di effettuare correzioni senza perdere la congruità dell’insieme. Le procedure che abbiamo
individuato hanno degli evidenti punti deboli, richiedono molta attenzione nel venire applicate,
salvano solo alcuni degli attributi, e possono, per strati complessi, diventare molto lente e, in
situazioni limite, arrivare a bloccare completamente il computer. Le funzioni si sono dimostrate
particolarmente sensibili nella gestione di poligoni molto grandi e complessi, mentre in genere
gestiscono meglio un gran numero di poligoni semplici. Questo è uno dei motivi per cui le
operazioni di “dissolve” vengono applicate alla fine, e non alla partenza, della procedura.
Il tasto “S”, che elimina sovrapposizioni tra poligoni
Il formato shapefile di ArcView è un formato molto diffuso e semplice da gestire, ma non è un
formato topologico. In altri termini, ammette sovrapposizioni tra poligoni, il che può produrre
effetti indesiderati. Ad esempio, può provocare errori di calcolo, dato che la somma delle aree
delle diverse destinazioni di piano di un Comune, possono risultare maggiori dell’estensione
territoriale totale del comune. Inoltre possono esistere dei poligoni che contengono, per errore di
digitalizzazione, delle sovrapposizioni interne ad uno stesso poligono, tipo un nastro “annodato”,
che passa su sè stesso). Questi poligoni “sporchi” provocano effetti indesiderati e imprevisti,
come “sparate” e fuoriuscita di colore durante le zoomate ecc.
La procedura attivata dal tasto “S” ripulisce tutte queste situazioni indesiderate, e restituisce un
file coerente e geometricamente valido. Ovviamente bisogna pensarci due volte prima di
applicarlo, dato che non sempre la sovrapposizione di poligoni costituisce un errore. Se si è
32
voluto rappresentare, ad esempio, in uno stesso file due tipologie di vincolo, non correlate, per
cui esistono aree coperte da entrambi i vincoli, l’applicazione del programma in effetti
distruggerà un’informazione. Noi riteniamo comunque che, almeno nell’applicazione in esame
(PTP e altri strumenti urbanistici analoghi) questo tipo di rappresentazione sia da evitare. Le
quattro immagini riportate a seguito chiariscono l’operato della procedura.
Figura 24 – L’aspetto visivo del tema prima e dopo lo svolgimento della procedura di correzione è identico, ma se
si “smontano” i poligoni che lo costituiscono, si apprezzano le differenze.
Figura 25 – Quello che effettivamente ha fatto la procedura: ha eliminato tutte le aree di sovrapposizione invisibili,
seguendo la sequenza di visualizzazione, eliminando cioè quelle che stavano sotto, che nel file sono le prime in
sequenza, e che quindi vengono coperte da quelle che seguono. A sinistra lo “smontaggio” del file prima della
procedura, e a destra dopo.
Il tasto “E”, che esplode i poligoni
Arc View permette di raggruppare poligoni, anche completamente isolati tra loro, in un unica
entità. Ad esempio le isole di un arcipelago possono venire rappresentate graficamente da otto
poligoni distinti, ma possono venire definite nella tabella degli attributi da un unico record, che
registra il nome dell’arcipelago e l’area complessiva. Sulla View, di conseguenza, cliccando per
selezionare una delle isole dell’arcipelago, si otterrà la selezione dell’intero arcipelago.
Ciò è molto comodo per diverse situazioni e applicazioni, ma può diventare un inconveniente se
si desidera modificare l’attributo di uno dei poligoni indipendentemente dagli altri. Il tasto “E”
effettua una esplosione logica dei poligoni. Dopo averlo utilizzato nulla sarà cambiato dal punto
di vista grafico, ma in tabella ad ogni poligono corrisponderà un record distinto, e i singoli
33
poligoni potranno quindi venire editati e modificati, sia graficamente che per gli attributi,
singolarmente e uno per uno.
Se il file da esplodere è un file di editing (il nome del file inizia con “ed_”) i poligoni del file
vengono esplosi, e il nome del file resta lo stesso. In caso contrario si crea un nuovo file con i
poligoni esplosi, e la procedura chiede il nome e la posizione del nuovo file.
Il tasto “A” che ricalcola area e lunghezza
Il ricalcolo delle aree e delle lunghezze viene normalmente gestito dal programma generale che
aggiorna la tabella indice, e che effettua anche questa operazione sui files. Ma durante l’editing
possono verificarsi modifiche ai files (ad esempio quelle conseguenti all’impiego del tasto “I”)
che richiedono il ricalcolo e aggiornamento delle aree. Il tasto “A” agisce sul tema attivo, e
aggiorna i relativi valori.
La procedura di editing
La procedura di editing si articola in più fasi. In sostanza si inizia una sequenza di operazioni di
editing con un comando iniziale che crea un nuovo file di editing; si effettuano una serie di
operazioni di correzione, che possono implicare ritagli, aggiunta, ridefinizioni di categoria, e che
possono comportare diverse sessioni, articolate su più giornate. Una volta completato l’iter di
correzione si attiva una funzione di chiusura, che effettua un dissolve tra tutti i poligoni che
hanno uguale definizione per l’attributo base prescelto (per default dovrebbe essere “label”), ed
effettua poi una unione con una copertura base contenente i confini comunali e di piano.
Tasto “I”, inizio editing
A seconda che il file di editing esista già o meno, crea un nuovo file di editing (con un nome che
inizia da “ed_”) o apre un file esistente.
Tasto “R”, ritaglia
Chiede la definizione di una linea che ritaglia una parte di un poligono esistente, generando un
nuovo poligono.
Il programma di editing si muove nella logica di uno strato continuo, che copre tutta l’area
regionale. Non è previsto quindi il caso dell’aggiunta di nuove aree, o della cancellazione di
aree, in quanto all’interno della Regione tutte le aree sono coperte da poligoni, anche se alcuni
avranno una codifica nulla. Quindi l’aggiunta si risolve nel ritaglio di un area da un’area con
codifica nulla, e la sua successiva rinomina. La cancellazione in una ricodifica con un codice
nullo.
Tasto “N”, nomina
Permette di etichettare o di ridefinire l’etichetta di un poligono. Selezionando un poligono
(eventualmente un nuovo poligono appena definito tramite il tasto “R”) compare un menu a
tendina, con tutte le opzioni disponibili per quello strato informativo, e una opzione aggiuntiva di
“eliminazione”. Bisogna scegliere la nuova etichetta e attivare il tasto di accettazione (“ok”).
Tasto “F”, fine editing
Fa un’operazione di pulizia, unificando tutti i poligoni adiacenti con etichetta uguale, e
incrociando poi il risultato con le informazioni di uno strato con i confini comunali e di piano. Il
programma richiede di confermare se va sostituito il file iniziale, e chiede se va creato un file di
34
riserva (backup). Va tenuto conto che la procedura perde una serie di informazioni, in particolare
quelle relative alla codifica di origine. Perde in realtà anche la codifica numerica ricalcolata, e il
codice di simbolo ArcInfo, ma si tratta di informazioni legate in modo biunivoco con il testo
dell’etichetta (“label”), e quindi eventualmente recuperabili.
35