La dimensione spaziale: GIS e Spatial Decision Support System

Densham (1991) propone la definizione di Spatial Decision Support System (SDSS) quale strumento esplicitamente progettato per supportare il processo di ricerca di una decisione a problemi complessi aventi componente spaziale. Si sottolinea, in prima battuta, la differenza posta tra GIS e SDSS: per quanto il primo, grazie alla sua capacità di trattare, conservare, analizzare e rappresentare dati spaziali contenga nella sua definizione stessa l’idea di SDSS, viene considerato poco incidente all’interno del processo decisionale. I principali limiti del GIS sono da ricercare nella struttura fortemente orientata al trattamento dei dati spaziali inadatta alla modellizzazione dei problemi in maniera flessibile in relazione della specificità del processo decisionale. Quindi si identificano le caratteristiche peculiari che definiscono un SDSS rispetto a quelle dei DSS4:

• avere meccanismi per l’input di dati spaziali;

• permettere la rappresentazione di relazioni spaziali e strutture complesse, comuni nei dati di natura spaziale;

• includere tecniche analitiche dedicate ad analisi spaziali e geografiche;

• prevedere output nelle diverse tipologie di dati spaziali incluse mappe, grafici o altri tipi specializzati.

Si sottolinea la natura iterativa, integrativa e partecipativa del sistema, fondata su un reiterativo processo di raffinamento delle informazioni quantitative del giudizio di valore, vero output del processo.

Nonostante i DSS facciano spesso uso di comuni strumenti o modelli per l’analisi ed il trattamento dei dati, una peculiarità del processo decisionale riferito al territorio è la strutturazione di SDSS particolarmente orientati a risolvere il problema specifico.

Si può però cercare di definire una struttura comune ai SDSS partendo dalla letteratura dei DSS. Sprague e Carlson (1980,1983) identificano tre livelli dello sviluppo tecnico del sistema, che si costruisce tramite un processo di successivi affinamenti tra chi effettivamente implementa il sistema e chi ne fruisce degli output (fig. n°2.3). Parallelamente sono quindi individuabili vari ruoli, non necessariamente ricopribili da persone diverse, in funzione del livello di sviluppo tecnico del sistema. Al livello più basso del SDSS si trova il SDSS toolbox dove sono raccolti tutti i componenti hardware e software utili alla trattazione dei dati spaziali e non: tale parte del sistema è implementata dal toolsmith che ha il compito di aggiungere o raffinare i componenti in funzione delle nuove necessità che si palesassero durante l’iter decisionale. Nel livello medio è presente il SDSS generator dove il

4 _{Vengono ricordate le caratteristiche dei DSS in sei punti (GEOFFRION, 1983): strumento esplicitamente} disegnato per la risoluzione di ill-structured problems dove gli obiettivi dei decision makers e il problema stesso non sono ben definiti; possiede una user interface potente e semplice da usare; il sistema permette all’user di combinare i modelli analitici in maniera flessibile; il DSS esplora lo spazio delle soluzioni possibili usando gli strumenti al suo interno e simulando diverse alternative; il sistema è in grado di supportare vari stili decisionali e può implementare nuovi strumenti seguendo l’evoluzione dei bisogni dello user; il sistema permette la risoluzione del problema tramite un processo ricorsivo - reiterativo dove non esiste un solo percorso possibile per il raggiungimento del giudizio.

technical supporter combina gli strumenti presenti nel toolbox per rispondere al problema specifico; qualora il processo decisionale evidenziasse altre necessità possono essere prese altre funzioni dal toolbox o se ne possono implementare di nuove. Al livello può alto è quindi presente lo SpecificSDSS , dove il builder configura gli strumenti del SDSS generator, già orientati alla risoluzione dello specifico problema, per relazionarsi con il processo decisionale ossia per strutturare la user interface. L’intemediary interagisce fisicamente con l’interfaccia del SDSS per inserire le istanze dei decision maker nel sistema e supportare l’interpretazione dei suoi risultati. Il processo di costruzione del SDSS si basa, già nella definizione costituiva stessa, su una dimensione iterativa incrementale che può contribuire indirettamente alla formazione della conoscenza e alla chiarificazione degli obiettivi degli attori del processo.

Fig. n°2.3, Sprague e Carlson (1980-1983) modificato da Densham (1991) schema dello sviluppo dello strumento tecnico SDSS

Densham (1991) riprende la struttura di Sprague (1980) e, specificandola per i SDSS, mantiene la divisione del software in moduli per la sua utilità ai programmatori (toolsmith, builder, technical supporter) ma sottolinea che per gli users del SDSS (intemediary, decision maker) il sistema appare nella sua interezza (fig. n°2.4). I moduli del software sono rappresentati con i riquadri, messi in contatto con le frecce che simboleggiano il flusso di dati. L’user interface comprende tutto il sistema perché è tramite essa che sia i tecnici che i decision maker interagiscono col sistema secondo i propri livelli di competenza. Gli output del sistema sono sia definizioni di alternative per la soluzione del problema, che semplici interrogazioni del data base rappresentabili tramite grafici e carte per facilitare l’attività valutativa dei decisori. Similmente ai DSS il DataBase Management System (DBMS) è il cuore del sistema contenendo tutta la base dati e le routine per la loro manipolazione: un DBMS deve essere in

grado di manipolare e conservare dati spaziali e non, di supportarne la visualizzazione cartografica e le interrogazioni del database a differenti scale territoriali, grado di risoluzione e livelli di aggregazione (DENSHAM,1991). I DBMS della maggior parte dei GIS sono basati su database relazionali, ma Armstrong e Densham (1990), partendo dalle esperienze ricavabili nell’ambito dei DSS, dimostrano che si possono efficacemente rappresentare molte forme di relazioni spaziali utilizzando extended network model come struttura dei dati (CHEN 1983). Probabilmente esistono tre approcci di complessità crescente alla modellizzaione nei SDSS. Il primo è il semplice uso delle capacità di trattamento dei dati presenti nel DBMS stesso come strumento di aiuto alla decisione: da una parte si ha il vantaggio della semplicità dello strumento, ma dall’altra questo presenterà limitate capacità di analisi e necessiterà di un forte apporto dell’intemediary che deve adattarne la rigidità alle richieste del processo decisionale. Un altro approccio è quello di sviluppare una libreria di routine che si possa facilmente combinare in maniera funzionale al processo decisionale: è disponibile un gran numero di applicativi per risolvere problemi di vario genere quali, analisi spaziali complesse, modellizzaione, analisi statistiche, problemi di ottimizzazione e quant’altro. Tale approccio crea librerie spesso molto onerose per la gestione del software a causa di un’estrema replicazione di codici comuni a più strumenti. Il moderno sviluppo di tale approccio consiste nella creazione di un MBMS che, similmente ai DBMS, contenga una serie di elementi capaci di combinarsi a piacimento qualora venisse richiesto di risolvere un dato problema. Si tratta di una libreria di piccoli codici “atomic elements” che risolvono uno step di un algoritmo più complesso. Così da una parte, si evita di replicare i codici comuni a più algoritmi risolutivi e, dall’altra, si rende più facile modificare le procedure risolutive, avendo la possibilità di potenziarne o sostituirne solo una parte. Il MBMS conterrà quindi anche le regole di combinazione degli atomic elements, al fine di richiamare gli algoritmi esistenti e ricavarne nuovi tramite semplici formule. Tale possibilità, insieme a quella di inserire nuovi atomic elements, rende lo strumento flessibile e permette di sviluppare SDSS molto specifici. Le capacità di base che devono essere presenti nel Report Generator sono la possibilità di generare mappe e grafici a partire dal database di partenza o dai risultati delle analisi svolte; a queste bisogna però implementare output specifici in modo da migliorarne l’efficacia all’interno dello specifico processo decisionale. Il decision maker vuole riceve informazioni in forma grafica o di tabelle, ma richiede anche una certa interattività dello strumento con il proprio sapere esperto. L’interfaccia dell’utente dei SDSS deve rappresentare due spazi: lo spazio obiettivo e lo spazio della mappa. Il primo, prevalentemente costituito da tabelle, visualizza i parametri del problema e l’interfaccia di gestione del processo risolutivo; mentre il secondo, tramite rappresentazioni grafiche e cartografiche, presenta gli output del SDSS tanto le semplici interrogazioni del database, quanto i prodotti delle analisi e del processo decisionale (DENSHAM,1991).

Fig. n°2.4, schema della struttura di un SDSS (DENSHAM 1991)

Le caratteristiche dei SDSS presentate da Densham e Sprague (1991, 1983) sono facilmente riscontrabili nelle piattaforme GIS di recente realizzazione tanto da rendere molto labile la differenza tra SDSS e strumenti GIS (MENNECKE. 1997, AIRINEI 2010, MURPHY 1995). Il GIS è uno strumento utilizzabile per la gestione e la strutturazione dei DBMS e dei MBMS capace di effettuare query sui dati ed analisi spaziali, che può essere integrato come parte costituiva di un SDSS (AIRINEI 2010). Il GIS presenta una sostanziale debolezza nel rapportarsi con gli ill-structured problems, sia a causa di un’interfaccia che richiede un utente di medie alte capacità per l’interazione, che per la limitata disponibilità di tool ed applicazioni al suo interno che sovente rende necessario spostarsi su altri software per risolvere alcune parti dello specifico problema decisionale (MURPHY 1995). Mennecke (1997), sottolineando l’importanza e la diffusione dei desktop GIS tra le istituzioni che si occupano della gestione del territorio, dimostra come gli strumenti attuali ricadano perfettamente nelle definizioni di DSS di Sprague e Turban (1983,1995) e come la loro struttura possa essere facilmente rappresentata come quella di un SDSS con un vastissimo ventaglio di campi di applicazione (fig. n°2.4). In particolare è in accordo con una definizione più restrittiva dei SDSSche li definisce come strumenti per analisi spaziali complesse, muniti di una efficace interfaccia con gli specifici attori del processo decisionale, ma caratterizzati da essere uno strumento chiuso dedicato ad un preciso processo decisionale (COOKE, 1992). Per questo motivo Mennecke (1997) preferisce la denominazione GIS per un DSS che abbia a che fare con problemi caratterizzati da una

dimensione territoriale complessa e ne propone una struttura generale sviluppata sulla base di quella proposta da Sprague e Turban5 (1983,1995) (fig. n°2.5, n°6, n°2.7).

Fig. n° 2.5, tipi di funzioni e campi di applicazione dei GIS, (MENNECKE, 1997)

Fig. n° 2.6 Modello Concettuale di DSS dopo Turban (1995), (Mennecke, 1997)

Fig. n° 2.7 Modello Concettuale di GIS usato per Strategic Spatial planing (MENNECKE, 1997)

Airinei (2010) confronta alcuni diversi strumenti per la strutturazione di un DSS riferito ad uno stesso problema decisionale6 concludendo che le forti possibilità di integrazione tra diverse tipologie di strumenti software permettono di approcciasi alla strutturazione del DSS in maniera piuttosto flessibile, orientando la scelta degli stessi sulle richieste dei decision maker, i dati del problema e le risorse dello sviluppatore, anche combinando strumenti ed applicazioni già disponibili. Gli approccii GIS oriented o SDSS oriented possono essere sia complementari che alternativi; il loro uso efficace dipende dalle caratteristiche del problema decisionale.