ott 25

Condividi


La gestione delle risorse idriche, attualmente soggette ad una crescente pressione antropica ed alle crisi ricorrenti legate ai cambiamenti climatici, costituisce una delle problematiche ambientali cui si deve porre maggiore attenzione. In questo senso numerose raccomandazioni relative alla necessità di un nuovo approccio verso le metodologie e procedure di gestione delle risorse idriche sono state emanate recentemente anche dall’Agenzia Europea dell’Ambiente. In questo scenario si colloca il progetto di ricerca SID&GRID (Simulazione e sistemi IDroinformatici per la Gestione delle Risorse Idriche), attualmente in corso, il cui obiettivo principale è di progettare e sviluppare un framework open source per l’integrazione del mondo GIS con la modellistica idrologica ed idrogeologica, per la pianificazione e gestione condivisa degli usi della ricorsa idrica da parte di Enti pubblici e società preposte a tale ruolo.

Obiettivo del Progetto SID&GRID è di sviluppare e rendere operativo un Sistema di Supporto alle Decisioni basato su software open source che possa essere utilizzato quale strumento operativo e condiviso per la gestione e la pianificazione degli usi della risorsa idrica dalla comunità, Enti pubblici e società che gestiscono e utilizzano tale risorsa. Ciò presuppone un importante lavoro di integrazione, in ambiente open, del mondo della modellistica idrologica ed idrogeologica con il mondo GIS attraverso la progettazione e realizzazione di appositi moduli. L’interfaccia grafica strutturerà un sistema di controllo in grado di agevolare e guidare l’utente dalla preparazione dei dati geografici fino alla loro traduzione in variabili numeriche (dati di input) richieste dal solutore del codice del modello matematico.

E’ attivo un sito del progetto in cui è possibile seguire lo stato di avanzamento della ricerca. 

ott 25

Condividi


Di recente ho avuto modo di confrontarmi con alcuni colleghi (anche in occasione di seminari) su temi molto interessanti per la nostra professione. In particolare mi riferisco all’impatto che ha l’informazione territoriale nei processi partecipativi relativamente all’uso delle nuove tecnologie dell’informazione. A tal proposito ho incrociato spesso questo rapporto sia nel corso del dottorato che della ricerca post-doc svolta a Venezia.

Come ci ricorda C. Beguinot nel suo saggio introduttivo al testo “Città nel XXI secolo tra recupero, innovazione, cooperazione”,
nel 1994 a Napoli vennero presentati alla Comunità scientifica mondiale i nuovi principi e le nuove regole attraverso cui configurare la città del terzo millennio, che si declinano nei dieci principi enunciati nella testo della Carta di Megaride 94. Citiamo tre dei dieci principi che intercettano il tema di cui si scrive:

  • Città e Cittadini – “La città futura dovrà garantire ad ogni cittadino la più ampia possibilità di accesso ai luoghi, ai servizi ed alle informazioni; è una città nella quale ogni diversità trova condizioni adeguate alle proprie esigenze che devono potersi esprimere liberamente”. Ciò implicherà che il dialogo tra i cittadini e le istituzioni potrà essere ampliato anche attraverso l’uso delle nuove tecnologie, che forniscono strumenti di controllo, di analisi e di supporto alle decisioni.
  • Città e Complessità – “Nella città futura il governo della complessità deve coinvolgere l’intero sistema urbano e ogni sub-sistema che ne fa parte e deve attuarsi alle diverse scale di intervento: dal sistema funzionale a quello istituzionale, dalla scala architettonica alla scala territoriale”. Ciò implica la necessità di dotarsi di nuovi strumenti e modelli in grado di governare la complessità urbana. Le trasformazioni della città futura dovranno, quindi, essere governate attraverso strumenti in grado di consentire l’indirizzo, la regolarizzazione ed il controllo dei fenomeni urbani.
  • Città e Tecnologia – “L’innovazione tecnologica e la telematica, in particolare, devono essere orientate al miglioramento delle prestazioni urbane e al governo della città futura”. Ciò vuol dire che i contributi dell’avanzamento culturale, scientifico, tecnologico dovranno essere impiegati nell’analisi, nel progetto e nel governo della città per contribuire ad innalzare il livello della qualità della vita e della vitalità urbana.

Questa citazione dovrebbe chiarire quali erano le luci quando si discuteva di nuove tecnologie e qualità della vita nelle città. Con ciò non intendo affermare che oggi tali luci si siano spente o sbiadite, ma forse amplificate fino a far correre il rischio di abbagliarci perdendo, a volte, di vista il reale obiettivo di integrazione. I primi anni ’90 risultano particolarmente vitali per l’accendersi di questioni, riflessioni e suggestioni che mirano ad inquadrare e delineare un nuovo scenario in cui le nuove tecnologie potrebbero svolgere un ruolo di neurone per la “trasformazione” della società in cui viviamo. L’intervento di C. Donolo nel 1997 è altresì interessante nel contesto di questo post:  «le istituzioni sono capaci di “intelligenza”, sono capaci di apprendere [...] occorre smettere di guardare alle istituzioni come a enti estranei, opprimenti, se non quasi nemici, da raggirare non appena possibile». Bene, sembra cosa fatta…ovvero ICT come strumento comunicativo a disposizione delle P.A. (e non solo) il tutto contestualizzato (geotaggato) su immagini del territorio.

Queste riflessioni, già trattate in un altro post in cui si fa esplicito riferimento allo strumento del geotagging, dovrebbero oggi stimolare nuove riflessioni. In particolare ritengo che si stiano esprimendo alcuni dubbi e timori sull’uso di tali strumenti che sono emersi anche nel corso di alcuni seminari a cui ho partecipato come relatore e uditore.

Il geotagging basato sull’approccio 2.0 richiede un dialogo tra tutti i soggetti coinvolti per il raggiungimento di un determinato obiettivo. Questo dialogo è proficuo se a partecipare non sono soltanto gli utenti (tra cui i cittadini), ma anche il soggetto promotore (l’amministratore nel web).
Ma chi è l’amministratore?

Nel caso più semplice, ovvero di un geoblog avviato da una P.A per un particolare processo (es. piani strategici, PGT, etc.), è la stessa P.A ad esporsi rispondendo alle istanze che provengono dal web. Rispondere non vuol dire sempre accogliere, ma far sentire la propria voce in accordo o disaccordo. Basterebbe rendere in forma esplicita l’analisi di tali istanze anche in fase di redazione dei documenti di piano. In assenza di tale dialogo, il rischio è quello di promuovere una semplice “piazza” senza mediatore.

Anche l’obiettivo nel Geoblog deve essere chiaro…a cosa serve? perché dovrei contribuire? chi mi sta ascoltando? Quest’ultima domanda chiarisce anche il perché tali strumenti vengano chiamati, più correttamente, “sistemi di ascolto” ed un “sistema di ascolto” richiede almeno due interlocutori altrimenti si rischia un monologo.

Altra questione riguarda la tematizzazione del Geoblog, fortemente legata all’obiettivo. Quali sono le voci di legenda che devono presentarsi all’utente in funzione non solo dell’obiettivo, ma anche del contesto territoriale in cui lo si sta applicando.

Osservatorio del paesaggio - Regione Puglia

Il rischio è di sottovalutare alcuni “vincoli” per la corretta (in termini di risultato) applicabilità di tali strumenti in processi partecipativi supportati dalle GeoICT. CIò che noto (ed era già emerso nel corso della ricerca) è che l’uso del geotagging rischia seriamente di configurarsi come uno slogan tecnologico perdendo di vista alcune luci intraviste a partire degli anni ’90.
Concludo con un paio di link (uno lè già stato citato) di alcune esperienze che ritengo possano esplicitare queste mie semplici riflessioni.

[1] Il Paesaggio visto dagli abitanti – Regione Puglia
[2] Manutenzione urbana a Venezia

…esperienza nata “dal basso”
[3] Segnala Livorno - interessante la sezione “Problemi risolti”

 

Tagged with:
mar 04

Condividi


Questo articolo è il seguito di “sextante parte prima” e si consiglia la lettura prima di proseguire.
Nel primo tutorial abbiamo creato il progetto Java e scritto un semplice algoritmo di manipolazione dei dati raster. Ora procederemo con la scrittura di un nuovo algoritmo nel mondo vettoriale. L’algoritmo prevederà un dato vettoriale di input, un campo della tabella attributi ed un parametro numerico per generare un nuovo layer vettoriale in cui i valori del campo di input saranno moltiplicati per il parametro numerico inserito. Il primo passo consiste nella creazione di un nuovo package “es.unex.sextante.multiplyVector”  ed una nuova classe “MultiplyVectorFieldAlgorithm”.

Definiamo i parametri di input e le caratteristiche del nuovo algoritmo

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
package es.unex.sextante.multiplyVector;
import com.vividsolutions.jts.geom.Geometry;
import es.unex.sextante.additionalInfo.AdditionalInfoNumericalValue;
import es.unex.sextante.core.GeoAlgorithm;
import es.unex.sextante.dataObjects.IFeature;
import es.unex.sextante.dataObjects.IFeatureIterator;
import es.unex.sextante.dataObjects.IVectorLayer;
import es.unex.sextante.exceptions.GeoAlgorithmExecutionException;
import es.unex.sextante.exceptions.RepeatedParameterNameException;
 
public class MultiplyVectorFieldAlgorithm extends GeoAlgorithm{
 
	public static final String RESULT       = "RESULT";
	public static final String INPUT       = "INPUT";
        public static final String FIELD       = "FIELD";
        public static final String VALUE       = "VALUE";
 
	@Override
	public void defineCharacteristics() {
		this.setName("Multiply vector");
		this.setGroup("My algorithm");
 
		try {
		    m_Parameters.addInputVectorLayer(INPUT, "Vectorlayer",IVectorLayer.SHAPE_TYPE_POLYGON,true);
		    m_Parameters.addTableField(FIELD, Sextante.getText("field"), INPUT);
                    m_Parameters.addNumericalValue(VALUE,"Value",1,AdditionalInfoNumericalValue.NUMERICAL_VALUE_DOUBLE);
                    addOutputVectorLayer(RESULT, "Result");
			} catch (final RepeatedParameterNameException e) {
	                   Sextante.addErrorToLog(e);
	                }
	                 catch (final UndefinedParentParameterNameException e) {
	                   Sextante.addErrorToLog(e);
	               }
	                 catch (final OptionalParentParameterException e) {
	                   Sextante.addErrorToLog(e);
	                }
		    }

Definiti i parametri di input dell’algoritmo, si procede con la definizione del corpo del processo, ovvero con il metodo processAlgorithm().

39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
public boolean processAlgorithm() throws GeoAlgorithmExecutionException {
 
int iField;
double dValue;
double dConstant;
IVectorLayer layer;
 
layer = m_Parameters.getParameterValueAsVectorLayer("INPUT");
iField = m_Parameters.getParameterValueAsInt("FIELD");
dConstant = m_Parameters.getParameterValueAsDouble("VALUE");
 
Class type = layer.getFieldType(iField);
if !(Number.isAsignableFrom(type)){
throw new GeoalgorithmExecutionException(
"Selected field is not numeric");
}

Dalla riga 50 alla 54 è chiaro come stiamo catturando un’eventuale eccezione relativa alla tipologia del campo definito come input. Se il campo non è di tipo numerico, l’algoritmo non potrà procedere con la moltiplicazione della costante e restituirà un errore.
Proseguiamo con la definizione dei campi attributi di input ed output e con il layer vettoriale risultato.

55
56
57
58
59
60
61
62
63
64
65
66
67
Class[] fieldTypes = layer.getFieldTypes();
Class[] outputFieldTypes = new Class[fieldTypes.length];
 
for(int i = 0; i < fieldTypes.length; i++){
	if (i == iTop || i == iBottom){
	     outputFieldTypes[i] = Double.class;
	     }
	     else{
	     outputFieldTypes[i] = fieldTypes[i];
	      }
}
 
IVectorLayer output = getNewVectorLayer("RESULT",nome,layer.getShapeType(),outputFieldTypes,layer.getFieldNames());

Procediamo con il vero corpo dell’algoritmo in cui il layer vettoriale è letto nella sua componente geometrica ed alfanumerica. Tale procedura avviene tramite due metodi:
public Geometry getGeometry();
public IRecord getRecord();
Il primo legge e archivia e ritorna le geometrie attraverso la JTS (Java Topology Suite), mentre il secondo ritorna l’oggetto record implementato nell’interfaccia IRecord di Sextante.

Nel codice seguente andremo a copiare tutti i valori in un nuovo array che sarà usato per popolare i record del nuovo layer di output, eccetto che per il campo selezionato e dove andremo a moltiplicare i valori per la costante dConstant. Chiarita la procedura principale non sarà difficile comprendere dal codice che il layer di input “smontato” ed analizzato sarà successivamente ristrutturato nella sua componente geometrica ed alfanumerica.
Continue reading »

Tagged with:

 
preload preload preload