Si richiede un sostanziale mutamento nelle previsioni di utilizzazione di programmi applicativi per l'Osservatorio e per la diffusione delle attività dei diversi sottoprogetti (dati raccolti ed attività); si richiedono infatti applicazioni capaci di elaborazioni dei dati prodotti per l'amministrazione (soprattutto per l'Osservatorio) e possibilità di diffusione senza il ricorso ad applicazioni costose per gli utenti privati o per gli altri enti partecipanti per mezzo dell'interfaccia WWW sulla rete Internet. Si individuano inoltre le diverse modalità per la consultazione dei dati prodotti, affiancandoli ad alcune specifiche applicative e di linguaggio per le applicazioni suggerite.
Le scelte a suo tempo effettuate per l'utilizzazione dei dati dell'osservatorio vanno riviste considerando le esperienze prodotte ed i dati raccolti, privilegiando una loro agevole utilizzazione da parte dei diversi livelli di utenza.
La presentazione dei dati deve essere affidata a meccanismi diversi, a seguito delle due modalità di utilizzazione:
con le eventuali variazioni connesse alla replicazione dei dati su rete geografica, le possibili integrazioni tra i livelli eventualmente realizzabili.
Escluso preliminarmente il prodotto in precedenza indicato, Oracle SQL*Forms, capace solo di presentare i dati, senza alcuna possibilità di ulteriore elaborazione da parte dell'utente, due sono le modalità suggerite.
Una prima serie di opzioni è orientata all'elaborazione dei soli dati alfanumerici, la seconda consente anche il trattamento di dati grafici.
Per il trattamento dei dati si suggerisce di assecondare l'uso dei più diffusi pacchetti quali i data base Microsoft Access 2 e Lotus Approach, le diverse applicazioni relazionali in linguaggio xBase (Fox Base, dbFast ed altri), Borland Paradox, oltre ai fogli di calcolo Lotus 123 e Microsoft Excel. Prodotti che consentono di realizzare schermate di presentazione piuttosto complesse, capaci di rappresentare adeguatamente l'articolazione dei dati raccolti e correlati e, allo stesso tempo possibilità di ulteriore elaborazione di tali dati.
I fogli di calcolo consentono un accesso più agevole e la rapida realizzazione di grafici e di presentazioni su dati tendenzialmente tabulari. La ridotta attenzione alle informazioni testuali; informazioni spesso necessarie alla rappresentare situazioni complesse o contraddittorie, costituisce tuttavia una limitazione di questo strumento.
La principale limitazione riscontrata è tuttavia l'assenza di una presentazione spazializzata dei dati. E per la valutazione dei fenomeni a carattere territoriale ciò costituisce un vincolo importante.
L'ipotesi che suggeriremmo è quella di instaurare anche qui tre livelli di trattamento dei dati:
Per i primi è stato adottato all'inizio del progetto il pacchetto MGE di Intergraph. Pacchetto modulare, come afferma il nome (Modular Geographic Environment), destinato soprattutto all'analisi scientifica dei dati ed all'integrazione con la progettazione ingegneristica ed architettonica.
Non sono il primo a valutare il pacchetto assai antiquato nelle modalità di approccio, farragginoso nell'accesso ai dati alfanumerici ed estremamente precario nel funzionamento degli elementi di supporto. L'elevato prezzo corrisponde qui ad un limitato numero di copie e quindi al minor numero di errori di programmazione (bug) scoperti dagli utenti e successivamente eliminati.
Alcune delle funzioni del pacchetto sono tuttavia allo stato attuale ineliminabili.
Esistono tuttavia applicativi di più agevole uso ed assai diffusi. Si tratta di pacchetti tradizionalmente presenti in ambiente personal computer. Caratterizzati da una interazione meno onerosa per l'utente, forniscono abitualmente prestazioni appena sufficienti ad una presentazione decorosa ed alle indagini più elementari.
Tra questi, anche per l'integrazione col pacchetto MGE si analizza MapInfo. Non si tratta tuttavia né dell'unico, né necessariamente del migliore pacchetto applicativo di cartografia automatica su personal computer.
Se l'aspetto originariamente più interessante dell'applicativo era la sua integrazione con MGE (MGE, privo di un programma destinato alla presentazione dei dati, vi si rivolgeva per l'elaborazione finale delle carte tematiche, mentre oggi ricorre al modulo MapFinisher), gradualmente il prodotto che conta centinaia di migliaia di installazioni (si tratta del primo prodotto commerciale diffuso sulla piattaforma personal), si è gradualmente evoluto, coprendo prima il divario rispetto all'analisi topologica, poi superando il MGE sulla integrazione con il data base.
Se si tratta sempre di un prodotto totalmente integrato e 'leggero' rispetto ad MGE, se sono assenti le più sofisticate capacità di analisi topologica e geometrica, se la cartografia non fa ricorso alla terza dimensione (esistono tuttavia integrazioni di presentazione 'a due dimensioni e mezza', come si usa dire, ove cioè la terza dimensione è computata a partire dal dato alfanumerico), l'integrazione con il data base è diretta ed elevata, mentre le funzioni principali per il trattamento della cartografia - dalla grafica quantitativa alla lucidatura di originali acquisiti allo scanner in qualsiasi proiezione - sono agevolmente disponibili all'utente.
Oltre alla versione Professional, l'ultima pubblicata (v. 4.02), esiste anche una versione ridotta, MapInfo Desktop, di minor costo, dedicata agli utenti che non necessitano delle prestazioni avanzate della prima. Si tratta in sostanza della riproposizione con opportuni adattamenti della versione precedente, ad oggi largamente utilizzata presso gli uffici della Regione Liguria.
Un terzo livello possibile è presentato da MapInfo applet. Quella delle 'applettes' è una categoria emergente. Si tratta di piccoli programmi che integrano le prestazioni di altri già esistenti. Ne segnaliamo in particolare tre, destinate ai fogli di calcolo: una integrazione statistica, una integrazione di analisi dei dati (ricerca di ricorrenze significative), oltre alla citata Map applet, una integrazione che consente la realizzazione di carte tematiche a partire dai dati raccolti attraverso interrogazioni di data base o rilevazioni sul campo.
Il ricorso a queste applicazioni potrebbe permettere, ad esempio valutazioni di tipo territoriale presso servizi, come il Patrimonio, l'Annona, i Tributi, la Vigilanza che spesso necessitano di questa modalità di accesso ai dati, senza ricorso a costose applicazioni specializzate.
Gli strumenti tradizionali del sistema operativo Unix consentono un aggiornamento privo di vere difficoltà. Infatti il problema in oggetto si è più volte resentato all'attenzione dei progettisti di sistemi informativi.
Si adotterà quindi il protocollo TFTP che consente l'aggiornamento di una macchina remota con un set di file prestabilito. L'operazione si presenta agevole, all'accensione l'apparecchio verifica lo stato di alcuni file rispetto all'elenco presente sul server e, qualora vi siano differenze di aggiornamento, sostituisce i file presenti con la versione più aggiornata.
Ciò consente di operare in una situazione simile a quella riscontrabile in sede locale. Ma la possibilità di utilizzare pienamente i dati, attraverso la loro elaborazione sembra confliggere per la tradizionale condizione della pubblica amministrazione, con una esigenza fondamentale, quella di poter disporre in ogni caso dei dati prodotti. Per ottenere il meglio -- la capacità di elaborazione -- si finisce per rinunciare al bene -- la possibilità di consultazione.
Appare dunque opportuno qualificare questi utenti quali utenti remoti e per questi ultimi avanziamo l'opportunità di consultare i dati proposti attraverso il sistema (peraltro del tutto gratuito) del WWW, come per gli utenti connessi in rete geografica.
Se e ove sia necessaria la sola consultazione dei dati proponiamo che il sistema informativo territoriale sia consultato ricorrendo allo strumento universalizzante del World Wide Web.
La disponibilità di applicazioni cliente per il sistema WWW su tutte le piattaforme, anche sui mainframe Ibm, consente l'accesso al sistema da parte di tutta l'amministrazione comunale e la diffusione attraverso la rete Internet alla generalità dei cittadini.
Veniamo ora alle modalità di consultazione proposte, modalità che, per la natura dello strumento devono essere prefigurate prima della costruzione dell'interfaccia. Allo stato attuale si sono individuate le seguenti modalità:
A quest'ultima modalità vanno infine collegate le diverse rilevazioni attuate negli ultimi anni. In particolare saranno reperibili attraverso questa modalità le schede redatte nell'ambito del progetto 'Giacimenti culturali' (Verso Genova Medievale, attualmente in corso di trasferimento) e dal Comune di Genova nell'ambito della revisione del piano regolatore generale.
E' invece riservata all'attività dell'osservatorio la realizzazione di carte tematiche o l'indagine sulla totalità dei dati raccolti, intendendosi con 'carta tematica' la mappa che presenta tematismi tratti dalla combinazione di singole modalità di variabili diverse, combinate per mostrare la manifestazione di uno specifico tema di ricerca.
Vediamo dunque più in dettaglio le modalità proposte e la possibilità che esse vengano a sostituire altri supporti da tempo previsti fra le attività dell'osservatorio.
La prima modalità è la più agevolmente pianificabile. Si tratta della riproposizione 'statica' delle tabelle e delle mappe coropletiche (non si tratta infatti di carte tematiche, ma, nell'accezione del geografo Bertin, di carte-inventario) che accompagnano le relazioni presentate all'amministazione dall'Istituto di storia dell'architettura.
Si tratta quasi sempre di tabelle complete, query semplici (semplici viste logiche del data base), selezioni prive di unioni relazionali, con clausola limitativa nel numero di record presentati (per zona, per blocchi numerici) cui corrispondono carte già realizzate, che vengono proposte a diversi livelli di ingrandimento. Le modalità di presentazione non richiedono la presenza di un sistema informativo territoriale interfacciato al WWW, ma soltanto del collegamento a Oracle sin d'ora disponibile.
La seconda modalità, puramente testuale, anche se accompagnata da schermate che semplificano la costruzione della query, prevede la realizzazione in rete di speciali rapporti di ricerca (report). In particolare sarà in tal modo possibile porre in relazione elementi di uno stesso fenomeno presentati da diverse variabili in tabelle diverse.
Si tratta probabilmente dell'elemento più interessante anche per l'amministrazione. Le modalità utilizzate possono inoltre consentire, con opportune estensioni, le stesse modalità di presentazione fornite, secondo le ipotesi iniziali, da SQL*Forms o dalle schermate a suo tempo prodotte da Automa nel già citato prototipo in Visual Basic.
Inoltre a questa modalità di presentazione, attraverso la procedura GrassLinks (pubblicamente disponibile) sarebbe possibile collegare anche carte tematiche realizzate dinamicamente.
La terza modalità di presentazione costruita attraverso una serie di query analitiche per singolo civico/corpo edificato consente di visualizzare il risultato dell'indagine, comprendendo eventualmente alcune selezioni sulle fonti storiche (catasti, censimenti), oltre alle fotografie presenti nell'archivio prodotto dall'Istituto nell'ambito dell'indagine Civis. Inoltre per i fenomeni principali non soggetti a mutamenti importanti verrebbero inseriti anche alcuni estratti delle carte coropletiche relative alle variabili presentate nell'intorno dell'edificio analizzato.
La selezione, notevolmente esaustiva potrebbe anche consentire all'utente possibilità di interazione attiva, come la proposta di correzione, aggiornamenti o compilazione di apposite tabelle, secondo le indicazioni emergenti dal sottoprogetto n 5.
La selezione operata dall'utente non investirebbe soltanto l'ubicazione dell'oggetto di indagine, ma soprattutto gli ambiti di informazione (tabelle) che corrispondono ai suoi interessi.
Oltre che con una pre-selezione per via e civico, attraverso il meccanismo della imagemap (sempre presente nei server Web, e disponibile in tutti i programmi di visualizzazione grafica) è possibile selezionare l'edificio anche a partire da una mappa, consentendo di concatenare la consultazione nella modalità 1 all'approfondimento sul civico nella modalità 3.
Proprio questa modalità di consultazione consentirebbe di integrare senza procedure onerose anche altre rilevazioni disponibili, tra queste abbiamo già citato -- ma altre certamente saranno le prospettive al termine del progetto Civis ambiente -- le schede realizzate dal Servizio urbanistica per la revisione del piano regolatore generale sul Centro storico e le principali risultanze della ricerca Verso Genova medievale.
Assoggettando infatti alle medesime modalità di consultazione il data base realizzato nell'ambito del progetto 'Giacimenti Culturali, da sempre carente di adeguate modalità di presentazione dei dati, si risolverebbe il principale vincolo all'utilizzazione dei dati raccolti. La presentazione attraverso il WWW consente di sopperire all'impossibilità di trasferire il materiale non tabulabile tratto dal progetto. E' infatti possibile una presentazione multimediale assai più ricca di quella ottenibile attraverso tradizionali form di consultazione di un data base. Fra gli altri mezzi posti a disposizione dal protocollo di trasferimento, è possibile visualizzare immagini in movimento, eventualmente accompagnate da suoni secondo diversi standard.
Il principale risultato dell'orientamento indicato si colloca già nel breve periodo. La prevedibile rapida diffusione delle reti Internet all'interno della pubblica amministrazione induce a ritenere che - al di là degli stessi orientamenti dei diversi enti - al termine del progetto tutti i partecipanti possano disporre di un accesso distribuito ed agevole ai dati prodotti, senza il ricorso a 'standardizzazioni' lunghe e di esisto incerto, ma disponibile ad una vasta serie di programmi di consultazione, quasi tutti gratuiti, ed a tutti i tipi di calcolatore utilizzato (anche i terminali meno dotati).
In effetti, la procedura proposta di colloca al termine di una lunga serie di esperienze negative, ove strumenti avanzati (nella concezione) ma di difficile utilizzazione venivano predisposti, attivati, pagati e mai utilizzati. Le aziende che li avevano proposti, dopo aver utilizzato cospicui finanziamenti, chiudevano le attività senza poter sperare in alcuna commessa futura da parte dell'amministrazione, mentre le apparecchiature, sempre onerose, giacevano nei depositi.
Una sommaria analisi di questa esperienze mostra come l'esito delle attività intraprese sia stato condizionato da tre elementi:
A distanza di anni l'argomento si ripropone con modalità non dissimili da quelle già percorse.
Almeno per gli elementi b e c ci pare potersi suggerire un diverso orientamento, e di poter prevedere esiti più confortanti.
L'analisi del comportamento degli enti per il progetto "Verso Genova medievale" mostra come a condizionare gli esiti di un progetto valutabile a prezzi 1996 circa 30 mld, sia stata l'impossibilità pratica per l'ente destinatario di disporre della piattaforma applicativa richiesta, valutabile per impegno finanziario in meno dell'uno per mille dell'importo totale investito.
Il ricorso ad una applicazione gratuita e la rinuncia alla scelta di una piattaforma (marca, modello, sistema operativo, programma del calcolatore necessario) riteniamo possa evitare il ripetersi della vicenda. L'alternativa proposta, il ricorso all'applicativo SQL*forms di Oracle muta soltanto la versione (v. 4 invece della v. 2), un prodotto certamente caratterizzato da risultati interessanti ma che riteniamo destinato a funzionare soltanto all'interno dell'Osservatorio.
Per quanto attiene l'esperienza di utilizzazione, durante l'anno e mezzo ormai trascorso, lo strumento prescelto, certamente di facile utilizzazione, è stato utilizzato da diversi uffici nell'ambito comunale, sempre con valutazioni positive.
L'elemento di insuccesso principale deve tuttavia essere ricordato, si tratta del 'disinteresse verso il risultato' degli investimenti.
In realtà tale disinteresse non risultava da valutazioni 'ex-post' ma si era già manifestato lungo tutto il percorso di realizzazione dell'investimento. Lontani dalle esigenze 'immediate' degli enti coinvolti, sofisticate nella concezione quanto onerosi nella domanda di specialismi lontani dalla tradizione e dai 'saperi specifici' dei membri dell'organizzazione, svincolati dalle procedure di attuazione della pubblica amministrazione e dalla formazione delle decisioni, i progetti erano fin dalla loro concezione destinati al fallimento.
Quali gli elementi di potenziale successo delle operazioni in corso di ultimazione? Cinque sono le 'contrapposizioni' che possono permettere risultati lontani da quelli già prefigurati:
Infatti, a partire dalla nuova legislazione sugli enti locali, l'orientamento tipico della pubblica amministrazione è mutato, assumendo la centralità del monitoraggio delle attività amministrative. A ben guardare, infatti, le conseguenze di un orientamento obsoleto dell'attività amministrative sono di fronte agli occhi di noi tutti: la redazione del nuovo Prg ha incontrato impreviste difficoltà nell'affrontare l'assenza di informazioni strutturali. Sono dunque 'venuti al pettine' i nodi di una tutela degli aspetti idrogeologici stancamente rivolta ad una serie di 'emergenze' mancate, di un impegno episodico, anche se talvolta strenuo, gettato (si pensi alla diuturna attività del geom. Grossi per quanto attiene il Centro storico).
Insomma, o si assume l'insieme delle ricerche in corso come un mezzo di recupero del pregresso, in cui le strutture dell'amministrazione collaborano e pongono le basi per un diverso orientamento, oppure ci troviamo di fronte ad un ulteriore oneroso fallimento e ad una amministrazione consapevolmente avversa alla nuova legislazione sugli enti locali. Per dirla tutta, ad una amministrazione fuorilegge.
Assumere quindi la centralità delle procedure amministrative da parte del progetto di ricerca, significa da un lato concedere priorità alla realizzazione degli elementi di comunicazione che consentono fin da oggi di realizzare i collegamenti, ad esempio, con la discussione dei progetti che investono la città vecchia presso la commissione edilizia.
A partire da oggi è infatti possibile verificare e riportare organicamente i dati per le zone di rilevazione già ultimate. A ciò potrebbe affiancarsi la realizzazione delle schermate di reporting, visualizzabili attraverso Internet ed elaborabili dal pur ridotto staff dell'Osservatorio.
Passare, seppure con tempi (e mezzi) ragionevoli ad una struttura dell'informazione interna all'amministrazione operante in tempo reale significa offrire una importante sponda a chi, operando con onestà, ha costituito all'interno dell'Università e degli altri enti di ricerca una prospettiva non accademica, lontana dalla centralità delle discipline tradizionali, una prospettiva interdisciplinare legata ai problemi ed agli oggetti, in un orientamento 'realistico' così lontano e così minoritario nell'ambito della cultura italiana.
L'orientamento verso l'informazione rispetto ad un privilegio di lunga data alle macchine ed alla specificità informatica delle operazioni svolte viene in questa occasione fortemente affermato. Prima il 'cosa', dunque, cioè il contenuto della ricerca, poi necessariamente il 'come'. Quello che potrebbe essere considerata un'aberrazione disciplinare ha trovato in questa occasione una sintesi, certo onerosa, tra la ridefinizione continua della struttura della rilevazione ed il tentativo di adeguata valutazione delle entità in gioco.
Chiediamo oggi che lo sforzo affrontato abbia riscontro in una realizzazione informatica coerente con le finalità e con l'attuazione dell'indagine. E che ad essa si affianchi un adeguato rapporto con le strutture comunali.
Il data base dell'Osservatorio costituisce un importante occasione di sperimentazione per l'individuazione di soluzioni per il rilancio del Sistema informativo territoriale.
Più volte ho avanzato proposte orientate alle soluzioni di seguito indicate, ma mi pare oggi opportuno presentare le soluzioni nel loro contesto operativo.
In ragione della sua flessibilità applicativa, dell'indipendenza dalla piattaforma hardware, dai sistemi operativi e dalla stessa possibilità di presentazione grafica, ritengo opportuno adottare come interfaccia unificata del data base una serie di schede articolate in linguaggio Html, secondo l'amplissimo novero di esperienze consultabili sul World Wide Web.
E' infatti possibile utilizzare una sola descrizione della schermata di consultazione (ma anche di immissione) per generare in divesi sistemi ed ambienti operativi diverse modalità di presentazione, tutte coerenti al contenuto e tutte secondo le convenzioni del sistema utilizzato.
E', ad esempio, assai facile generare su una qualsiasi macchina una pagina che sarà consultata con risultati sostanzialmente corrispondenti su:
Le possibilità indicate sono agevolmente verificabili con una connessione al sistema erbamatta.arch.unige.it (utente lynx, senza password), un sistema unix, con un qualsiasi terminale. Sarà così possibile accedere ad una qualsiasi pagina html (tabelle e data base compresi).
E' necessario ammettere che la soluzione prefigurata appare potenzialmente più onerosa di quelle realizzate con strumenti di costruzione dell'interfaccia normalmente disponibili. Sia PowerBuilder che lo stesso diffuso Sql*Forms, che il nuovo, flessibile, Oracle Power Objects, dispongono di strumenti automatici di costruzione delle interfacce.
Ciò è tuttavia parzialmente compensato dalla natura dell'interfaccia html. Infatti la sintassi di questo semplice linguaggio è orientata ad una coerente organizzazione del contenuto e non alla semplice (o sofisticata) presentazione dei dati. Tale adesione agli elementi di contenuto è necessaria per poter consentire le diverse modalità di presentazione corrispondenti alle diverse interfacce su cui i dati sono destinati ad essere visualizzati.
Sono in particolare disponibili nella vers. 2 del linguaggio:
Tutto ciò consente di operare non già a livello del sigolo elemento di presentazione ma a quello di una più accurata espressione dell'organizzazione interna del dato, superando così il tema di una espressività formale definita, affidata invece, da un lato agli automatismi interni del linguaggio, dall'altro alle preferenze dell'utilizzatore.
Valutiamo con maggiore attenzione quest'ultima affermazione.
Da un lato abbiamo citato gli elementi di automatismo del linguaggio. Ad esempio la realizzazione di una lista di definizioni del tipo:
termine definito 1 definizione del primo termine, il
cui significato deve essere compo-
sto in una lista compatta.
termine definito 2 anche questo termine deve essere
spiegato da questa lista compatta;
oppure la realizzazione di una tabella del tipo:
primo caratteristiche prestazioni del costo del
elemento del primo primo elemento primo
elemento elemento
secondo caratteristiche prestazioni del costo del
elemento del secondo secondo secondo
elemento elemento elemento
avviene in modo totalmente automatico. E' l'applicazione cliente a determinare la suddivisione delle colonne, a seconda del carattere utilizzato e del contenuto massimo di testo delle colonne stesse.
Anche l'applicazione cliente si attiene a regole sintattiche precise, connesse alle caratteristiche del contenuto, tuttavia le modalità di presentazione del testo sono regolate dall'utente nei limiti di quanto consentito dall'interfaccia. E' così possibile mutare le caratteristiche tipografiche, le dimensioni del testo, la larghezza della finestra di presentazione, sia in stampa che a video.
Questo livello di automatismo e la flessibilità di presentazione ad essa connessa consente di evitare nella maggior parte dei casi la generalizzata tendenza a stampare tutto quello che si intende veramente leggere. Tendenza tanto più onerosa in termini di tempo (scelta di modalità di presentazione spesso sofisticate quanto insoddisfacenti) di quanto non siano rilevanti le conseguenze sull'ambiente.
Proprio l'ultimo esempio presentato evidenzia un limite nella soluzione individuata. Non tutte le applicazioni cliente risultano allineate alla versione 2 del linguaggio. In particolare non tutte consentono la presentazione delle tabelle.
E molto spesso, almeno nella presentazione di data base caratterizzati da strutture anche minimamente complesse, è necessario il ricorso a tabelle per una presentazione gerarchica dei dati. Ad esempio ciò avviene quando si debbano presentare più modalità in una relazione 'uno a molti'.
Ciò può determinare la necessità di una doppia redazione della scheda, assai più onerosa, sia in termini generali di interfaccia, sia per la necessità, sovente rimossa, di operare tale conversione. E', ad esempio, sempre più frequente vedere assenti da pulsanti grafici visualizzabili solo con interfaccia pienamente grafica, le necessarie didascalie alternative, utilizzabili con la sola interfaccia testuale. Si rischierebbe così trovare testi realizzati per gli utenti meglio dotati, privi cioè della necessaria portablità.
E' tuttavia possibile specificare l'identità dell'utente che accede al server html e, in tale ambito, indicare di quale interfaccia egli disponga. Una possibilità che consente al server di operare in due modi principali. Inviando una tra diverse redazioni del medesimo documento preventivafmente realizzate, oppure attraverso un meccanismo presente su molti server, pre-trattare gli elementi non adeguatamente visualizzabili dall'applicazione cliente per consentirne la consultazione.
In particolare, in corrispondenza delle diverse interfacce e delle diverse applicazioni cliente ci troveremo nella possibilità di poter visualizzare:
La combinazione di questi tre elementi dà, ad esempio, la possibilità di visualizzare le tabelle con una pre-elaborazione grafica, oppure con caratteri mono-spazio in più colonne pre-calcolate.
Il meccanismo utilizzato è detto cgi, common gateway interface, una modalità unificata per incorporare nell'azione del server diversi programmi. Tra questi, ad esempio, il programma di gestione delle mappe (map.cgi) che consente di rendere 'attiva' (cioè di attribuire la funzione di un pulsante invisibile) ad una qualsiasi parte di un elemento grafico.
Anche l'applicazione cliente può tuttavia vedere estese le proprie capacità. Si può, ad esempio, pensare che essa, oltre a visualizzare opportunamente i diversi stili del documento, possa operare con specifici programmi, scaricati dal server, secondo modalità definite dal codice inviato. In pratica potendo realizzare qualsiasi comportamento, integrando dati e programmi in un nuovo ambiente operativo, al limite generando virus che possono danneggiare l'utente od il gruppo di utenti che usufruiscono del programma stesso.
A prescindere dagli elementi di sicurezza, che sono tuttavia oggetto di approfondimento da parte degli ideatori di questi linguaggi (Java e TCL - tool command language - sono prodotti da diversi gruppi della società Sun microsystems, il più grande produttore mondiale di workstation per il calcolo scientifico ed ingegneristico), essi consentono di accedere a tutti gli elementi di un sistema informativo territoriale.
In effetti questo scopo è già stato raggiunto con la semplice utilizzazione delle attuali capacità fornite dalle normali applicazioni cliente dotate di capacità grafiche e di possibilità di acquisire dati dall'utente (form capable web client). In particolare si ricordano alcune delle esperienze realizzate con il ricorso al programma Grass (realizzato dallo U.S. Army Corps of Engineers, l'equivalente del nostro Genio Militare, e pubblicamente disponibile sul server ftp moon.cecer.army.mil), come GrassLinks (giunto alla vers. 2) di Susan Huse, realizzato nell'ambito delle ricerche ambientali dell'università di Berkeley in California (il sistema si può provare con un collegamento a http://www.regis.berkeley.edu ed è disponibile al pubblico) e Grasslite, un completo sistema interattivo, limitato tuttavia ai soli clienti operanti sotto XWindow.
Nelle pagine che seguono presentiamo tre esempi di sistemi distribuiti per la consultazione dei dati. Si tratta in particolare di tre realizzazioni riferite
Alcune brevi didascalie affiancano le schermate, riprodotte così come sono state catturate dallo schermo del calcolatore. Si tratta tuttavia soltanto di un 'marcaposto' più che di un sostituto di una esperienza diretta, caratterizzata infatti dall'interattività, non riproducibile da una illustrazione.
La prima schermata presenta la scelta tra due modalità di consultazione, la prima, che viene utilizzata per le schermate presentate successivamente, è quella testuale - l'accesso attraverso il toponimo -, la second (non presentata) consente invece l'accesso attraverso il riconoscimento degli edifici sulla mappa.
In questa seconda modalità, premendo con il puntatore sulla mappa se ne ottiene l'ingrandimento, per passare poi alla terza schermata presentata alla pag ???.
Tornando alla prima modalità di consultazione, basta inserire una parte del toponimo per avviare la ricerca sull'archivio strade del Comune di Genova.
Dato il comando, il programma di visualizzazione (sottolineamo che la consultazione è possibile in tutto il mondo attraverso la rete Internet) riceve dal server l'elenco dei toponimi che contengano la dicitura richiesta (es. via Bernardo Castello, piazza S. Bernardo, via S. Bernardo), che vengono presentati in un menu a scomparsa, consentendo quindi l'immissione del numero civico (schermata n. 2).
Contemporaneamente vengono presentate in un elenco da spuntare (checkbox) le tabelle (o più propriamente le viste logiche) del data base disponibili alla consultazione. Una di queste, la scheda edificio è già preselezionata. Sarà questa la modalità di consultazione più frequentemente utilizzata.
Effettuate le scelte, il server presenterà in forma tabellare (o in altra forma eventualmente progettata) i dati richiesti. Oltre ai testi, comunque resi disponibili con un formato flessibile, possono trovare adeguata collocazione anche fotografie o disegni connessi alle informazioni raccolte.
Naturalmente la realizzazione è ampiamente preliminare. Il prodotto utilizzato, OraLink, è gratuitamente disponibile, tuttavia l'impegno per il passaggio dal prototipo ad una implementazione completa appare piuttosto consistente.
Attraverso la metodologia indicata è possibile giungere ad una presentazione grafica dei dati tale da emulare le prestazioni di un sistema territoriale con il ricorso a mappe statiche, realizzate una volta per tutte a diversi livelli di ingrandimento. Naturalmente non si tratta di una situazione pienamente soddisfacente, ma l'onere per l'eventuale aggiornamento una tantum dell'insieme della cartografia (10-12 carte coropletiche) può essere favorevolmente confrontato in termini di impegno con la completa implementazione di un sistema informativo territoriale distribuito, come quelli presentati alle pagine seguenti.
Modalità di selezione del toponimo (oltre ad immettere una parte del toponimo desiderato si può operare una scelta su base geografica, premendo sulla mappa riportata)
Individuazione degli elementi desiderati
Risultato dell'interrogazione per la scheda edificio.
La realizzazione di una grande indagine ecologica sul sistema idrogeologico della California settentrionale è l'occasione per la realizzazione di questo sistema di cartografia automatica on line.
La prima schermata riportata, in effetti la prima cui si giunge accedendo al sistema) è insieme la presentazione dell'intero progetto (i contenuti), dello strumento (breve descrizione e possibilità di accedere ad alcune informazioni sul prodotto) e della procedura, con la possibilità di consultare un aiuto in linea.
Con la seconda schermata possiamo 'costruire' la cartografia che ci verrà presentata, scegliendo la base a matrice di punti (raster base) su cui si fonda il sistema grass ed i diversi lucidi contenenti le diverse informazioni richieste, con il colore preferito per il tematismo prescelto.
Infine viene scelta l'area geografica (region) sulla quale si vuole porre l'attenzione e la dimensione dell'immagine trasmessa. Ovviamente immagini di minori dimensioni vengono trasmesse quasi immediatamente (anche all'utente europeo, per il quale attraversano l'Atlantico), mentre immagini di maggiore dimensione consentono di apprezzare un maggior dettaglio.
Le pagine successive consentono ulteriori esplorazioni delle mappe realizzate - in questo caso si è ottenuto l'ingrandimento di 25 volte su una parte della mappa iniziale -, oppure, tornando indietro, la modificazione dei tematismi presentati. L'operazione, pienamente interattiva, appare tuttavia maggiormente orientata alla presentazione grafica (anche di immagini prodotte da satellite, eventualmente sovrapposte a cartografia tematica di diverse provenienze) deve essere integrata dalla possibilità di consultazione dei dati alfanumerici, secondo le procedure presentate al precedente paragrafo.
La schermata iniziale di GrassLinks
Scelta delle modalità di presentazione
Due schermate di visualizzazione di GrassLinks: l'opzione scelta nella schermata precedente ed un suo ingrandimento di cinque volte (secondo la selezione dell'opzione `Zoom')
Con giugno 1996 il Laboratorio di Cartografia è divenuto beta test site per i nuovi prodotti MapInfo proprio per l'interesse suscitato dalle attività connesse al progetto Civis ambiente.
Tra i nuovi prodotti, che purtroppo ci è stato impossibile utilizzare per l'impegno operativo richiesto dalla loro implementazione, MapServer consente di presentare carte ed informazioni alfanumeriche attraverso una procedura in linguaggio basic (MapBasic) e l'utilizzazione dei file di comando ottenuti automaticamente con la redazione di carte tematiche.
Presentiamo in questa occasione alcune schermate dimostrative, articolate in cinque modalità di consultazione, con l'integrazione di informazioni grafiche e dati alfanumerici.
Le modalità di consultazione prevedono un approccio non procedurale, le carte vengono infatti prodotte e modificate a partire dai comandi impartiti nei quattro pannelli di selezione ed individuazione delle opzioni. Passando dalla mappa (affiancata da una tavolozza di strumenti) alla selezione delle informazioni è possibile ottenere risultati di notevole interesse.
La schermata introduttiva del dimostrativo MapServer
La scelta dell'ambito di ricerca (e della base cartografica) in MapServer
La visualizzazione della mappa e le modalità di presentazione in MapServer
I dati associati all'edificio in MapServer
Le opzioni di produzione della mappa in MapServer
