Continuando la digitalizzazione secondo uno schema di archiviazione organizzato in base alle esigenze, contenuti e tipo di lavoro da svolgere è stato creato un livello informativo inerente ai soli elementi franosi avvenuti il 19 Giugno 1996.
Lo scopo di questo strato è stato quello di poter gerarchizzare le linee di contorno delle frane in maniera tale da avere una completa classificazione dello scheletro lineare di ognuna.
Questa scelta è stata approvata in previsione di una seconda operazione che sarà protagonista della ricostruzione dei relativi poligoni da dover poi associare al database delle frane, realizzato secondo una tabella principale ed alcune di collegamento, seguendo le linee guida adottate per le “schede di censimento dei fenomeni franosi verificatisi nel bacino del Torrente del Cardoso il 19 Giugno 1996” create da Giannecchini.
La caratteristica di questa nuova entità lineare, nominata appositamente “LINEE CONTORNO FRANE 19_06_96”, è anche quella di essere elemento chiave che permetterà tutte le possibili elaborazioni ed analisi necessarie, costituendo il tema centrale del presente lavoro.
Mantenendo la stessa linea operativa della digitalizzazione adottata per le entità precedenti, la classificazione delle linee che costituiscono i perimetri delle frane è stata effettuata tramite una tabella appositamente costruita (tab. 6):
Tabella 6 - Struttura campi e descrizione valori della tabella associata alla feature class lineare LINEE CONTORNO FRANE 19_06_96
CAMPO LUNGHEZZA TIPO NOTE
OBJECTID Numeric contatore progressivo univoco automatico SHAPE Geometry identificazione primitiva geometrica
(Polyline) CONT_LIN Default Value Short
Integer
Integer codice identificativo univoco e non nullo dell’elemento grafico
TIPO Default Value Short Integer
Integer 1 = perimetro area denudamento
2 = linea delimitazione frana principale da una secondaria
3 = linea delimitazione area denudamento - area accumulo
4 = perimetro area accumulo frana 5 = perimetro area accumulo frana prevalentemente grossolano SHAPE_Lenght Default Value Double Double lunghezza in metri della spezzata
Durante l’operazione di riproduzione dei perimetri è stato tenuto conto anche di alcune situazioni particolari (fig. 49):
a) fusione di più eventi franosi verso un'unica area di accumulo, la linea 2 delimita la frana principale da quella secondaria, è un caso molto frequente e si possono avere sino a 4/5 fusioni dove la frana principale risulta quella più ampia e/o che parte da quote superiori;
b) condivisione di un’area di accumulo da parte di due frane che non si sono fuse: è un caso raro che si presenta in sole due occasioni (es. frane 57 e 58, riclassificate con nuovo codice 53 e 54) per i quali non è stato scelto di adoperare una linea di perimetrazione che suddivide l’area di accumulo condivisa ma, vista la poca quantità di casi riscontrati e lo scarso scarto areale che ne deriva, è risultato utile trattare le frane derivanti come singole utilizzando perimetri molto ravvicinati nell’area di accumulo.
Figura 49 - Casi particolari di digitalizzazione frane semplificati; a) fusione di più eventi franosi verso un'unica area di accumulo; b) condivisione di un’area di accumulo da parte di due frane che non si sono fuse a monte
Controllo topologico – La feature class creata ha tra le altre un’altra particolarità che la rende fondamentale: con i suoi 1094 segmenti digitalizzati non si parla più di una primitiva geometrica lineare fine a sé ma della base costruttiva per la creazione dei poligoni di frana.
Ogni linea infatti chiude un perimetro, avendo punto iniziale e finale combaciante, quindi la correttezza di posizionamento geometrico secondo le regole topologiche è fondamentale al fine di evitare errori di interpretazione dovuti a possibili sviste avvenute durante la digitalizzazione (sovrapposizioni, intersezioni, vuoti, ecc.). I vincoli topologici permettono di controllare la correttezza e l’integrità delle relazioni spaziali tra feature. I controlli non vengono effettuati con ArcCatalog, un altro programma della suite ArcGIS di ESRI®.
1 1 2 3 4 1 1 3 3 4 4 4 4
a
b
Una volta aperto il software è possibile associare al feature dataset “carta” un controllo attraverso il comando “New → Topology” e selezionando la (o le) feature class della quale si vogliono creare le relazioni topologiche.
Una volta seguite le principali richieste di base si procede nella selezione delle regole che devono essere rispettate, attraverso il comando “Add Rule”. Tra quelle disponibili sono state scelte le seguenti:
• Must not overlap: una linea di un layer non deve sovrapporsi ad una linea appartenente allo stesso layer (fig. 50a);
• Must not intersect: una linea di un layer non deve sovrapporsi od intersecare una linea appartenente allo stesso layer (fig. 50b);
• Must not have dangles: una linea di un layer deve toccare linee dello stesso layer ad entrambi gli estremi (fig. 50c);
• Must not self-overlap: una linea di un layer non deve soprapporsi o intersecarsi con sé stessa (fig. 50d);
• Must be single part: una linea di un layer non deve avere più di una parte (fig. 50e); • Must not intersect or touch interior: una linea di un layer deve toccare una linea dello
stesso layer solo ai suoi estremi e non nei punti nel mezzo, senza sovrapposizione od intersezione (fig. 50f).
Figura 50 - Rappresentazione dei controlli di validazione topologica eseguiti sulla feature class " Linee contorno frane 19_06_96”, le parti segnate di rosso individuano gli errori riscontrabili dalla regola in atto
Dopo aver evidenziato e corretto gli errori l’entità è resa attendibile sotto tutti i punti di vista ed è stata utilizzata come base per operazioni di vario tipo, tra le prime la creazione, tramite selezioni effettuate in linguaggio SQL (Structured Query Language), di nuove feature class in base alla natura (tipo) delle linee. Il comando infatti è strutturato in modo tale da poter agire direttamente sugli attributi della tabella fornendo come risultato tutti gli elementi che soddisfano le richieste (query) compilate secondo una precisa sintassi informatica.
Il comando “Select by Attributes” opera secondo questa procedura ed è stato applicato per ottenere tre nuove diverse tabelle.
Ogni nuova tabella viene considerata a tutti gli effetti come base per creare nuove feature class. L’operazione di salvataggio mediante “export data”, eseguita una volta appurata l’efficacia e la correttezza delle selezioni effettuate, ha permesso di ottenere le seguenti nuove entità:
•
LINEE CONTORNO DISTACCO ACCUMULO: la query esclude le linee di tipo 3 al fine di ottenere i contorni esterni di ogni singola frana senza interruzioni interne (fig. 51a).[TIPO] = 1 OR [TIPO] = 2 OR [TIPO] = 4 OR [TIPO] = 5
• LINEE CONTORNO DISTACCO: la query esclude le linee di tipo 4 e 5 per ottenere i perimetri delle aree dove è avvenuto il distacco (fig. 51b).
[TIPO] = 1 OR [TIPO] = 2 OR [TIPO] = 3
•
LINEE CONTORNO ACCUMULO: La query esclude le linee di tipo 1 e 2 per ottenere i perimetri delle aree dove è avvenuto l’accumulo (fig. 51c)[TIPO] = 3 OR [TIPO] = 4 OR [TIPO] = 5
Figura 51 - Rappresentazione della feature class "LINEE CONORNO ACCUMULO" con focalizzazione sulle frane n° 57 e 58. a) linee contorno distacco_accumulo; b) linee contorno distacco; c) linee contorno accumulo
Come osservabile ogni query è stata costruita in modo tale da richiedere esplicitamente i valori caratteristici della feature class obiettivo della selezione, esiste comunque un altro metodo per ottenere lo stesso risultato: è infatti possibile richiedere i valori da escludere per ottenere una selezione degli elementi non utili, e successivamente invertire la selezione tramite il comando “switch selection”.
Questo metodo risulta efficace quando i valori da conservare sono maggiori di quelli da scartare, scrivendo così una riga di comando più breve.
Nei casi in esame è stato scelto il primo metodo in quanto non è sussistito il bisogno di aggirare la richiesta, dati i pochi valori a disposizione, ma nel caso di database più articolati può senz’altro trovare applicazione.
La costruzione di una query per effettuare le operazioni su tabelle è senz’altro l’operazione tipica e che meglio identifica l’ambiente informatico di gestione di database come ArcMap. Nel caso non si sappia applicare il linguaggio SQL è altresì possibile effettuare una selezione manuale dei record direttamente sulla tabella e procedere con il salvataggio, con questo metodo però si rischia di mancare qualche elemento o di inserirne di errati.
Anche la duplicazione di feature class con successiva diretta eliminazione dei record non utili può essere una soluzione, ma risulta ancora più macchinosa della precedente e sicuramente sono operazioni da effettuare quando si hanno pochi elementi a disposizione al fine di ridurre l’errore. Niente come la costruzione di una query può ampiamente rispecchiare le potenzialità delle operazioni effettuabili su database con correttezza, sicurezza, ciclicità e garanzia dell’affidabilità del risultato ottenuto.
Le ultime tre feature class prodotte con questo metodo risultano utili non solo per identificazione dei perimetri delle diverse aree che caratterizzano i movimenti franosi ma anche per future elaborazioni.