Analisi degli elementi dell’interfaccia riassuntiva per funzioni

Figura 18 – form dell’interfaccia per funzioni

7.3.2.1 Elemento funzione

Questo elemento è molto semplice da realizzare, è un semplice combo box contenente l’elenco delle funzioni eseguibili.

Le funzioni eseguibili sono essenzialmente i 4 tipi elencati nei paragrafi precedenti.

Le funzioni sugli attributi sono un insieme molto ampio, pertanto ne verranno scelte solo alcune nel nostro prototipo (verranno scelte le funzioni di massimo, minimo, media, somma).

L’elemento funzione appena scelto, sblocca/tiene bloccati gli elementi successivi di interesse, portando l’interfaccia generica ad essere simile all’interfaccia propria della funzione analizzata.

CAPITOLO 7 – Il Software

7.3.2.2 Elemento layer

Anche in questo caso abbiamo un combo box.

Questo combo box si riempie dinamicamente a seconda dei layer che abbiamo a disposizione nel nostro data base geografico.

A seconda della scelta che facciamo qui, vengono caricati alcuni degli elementi successivi, per l’esattezza: “condizione su attributi” e “attributo su cui eseguire operazione”.

7.3.2.3 Elemento layer di supporto

Combo box che si riempie dinamicamente considerando tutti i layer lineari in nostro possesso.

Intuitivamente, non tutti i layer lineari sono idonei per essere considerati percorso. Il come scegliere se un layer lineare può o no essere percorso rappresenta un primo problema.

Una soluzione che si potrebbe adottare per risolvere questo problema prettamente semantico, è l’adozione di meta-dati.

Per meta-dato si intende una documentazione associata (metainformazione) al nostro layer che spiega come è fatto il layer, quali sono gli attributi delle feature (se il layer è vettoriale), e altre informazioni utili all’utilizzo del dato stesso.

Nessuno vieta che tra queste informazioni ci possa essere "utilizzabilità per calcolo percorsi".

Il problema della metainformazione è ben noto in bibliografia ed esistono diversi standard (FGDC, CEN, ISO, e altri).

Una definizione di meta dato può essere la seguente [www18]:

i meta-dati (dati sui dati) consentono di conoscere, senza esaminare il dato vero, e quindi a priori: il contenuto, i riferimenti geografici (proiezioni, ecc.), l’accuratezza (posizionale, tematica, temporale), la copertura territoriale, il metodo di acquisizione (fondamentale per comprendere fino in fondo il significato del tema), il formato, i dati di tipo amministrativo, il costo delle informazioni. Il meta-dato è quindi lo strumento per consentire una veloce ricerca del dato e la sua conoscenza.

Un interessante documento riguardante i metadati è da considerarsi il documento del CNIPA [www19], documento in cui si parla dello standard ISO 19115 per la costruzione di metainformazione.

In questo documento si dà descrizione degli elementi essenziali del modello concettuale di metadato e si fa cenno ad alcuni modelli uml e xml.

7.3.2.4 Elemento attributo su cui svolgere operazioni

Questo combo box ha un elenco di attributi che, come già detto, si riempie in automatico quando scegliamo il layer su cui vogliamo operare. Essendo la funzione sugli attributi una funzione numerica (media, massimo, minimo, somma ecc), bisogna filtrare il combo box da tutti gli attributi che contengono dati non numerici.

Un problema di interfaccia presente a questo elemento è il seguente:

L’interfaccia deve considerare funzioni su un solo attributo o anche funzioni su più attributi?

A livello concettuale, non ci sono troppe differenze tra la somma di uno o più valori di attributi, il problema sorge in fase di disegno dell’interfaccia.

Per il nostro prototipo, per semplicità, sfrutteremo solamente funzioni che riguardano un unico attributo.

7.3.2.5 Elemento condizione sugli attributi

Il caso più semplice di interfaccia per rappresentare l’elemento “condizione sugli attributi” è dato da:

• un combo box da cui scegliere un attributo, • un combo box per selezionare l’operatore e

• un text box per inserire il valore a cui vogliamo rapportare il nostro attributo.

Figura 19 – Interfaccia basilare di condizione sugli attributi

Ovviamente l’interfaccia deve avere l’intelligenza di riuscire a confrontare il tipo dell’attributo e il tipo del valore immesso.

Questo modello è molto semplice da realizzare ma esistono numerosi problemi da risolvere:

1. le condizioni possono essere più di una, esempio, considerando un layer dei terreni, posso volere i terreni con area > 50 metri e perimetro = 30 metri.

In questo caso una soluzione potrebbe essere avere una riga per ogni attributo del layer (soluzione più semplice ma non ottimale).

CAPITOLO 7 – Il Software

2. le condizioni possono essere più di una sullo stesso attributo. Tornando al nostro esempio dei terreni, potremmo volere tutti i terreni che abbiano le seguenti caratteristiche:

area > 50 metri, area <= 100 metri.

In questo caso, la soluzione adottata al punto 1, per quanto di semplice realizzazione, risulta errata, in quanto potenzialmente potrei aver bisogno di un numero infinito di righe.

3. ci possono essere condizioni che riguardano più attributi contemporaneamente, queste condizioni si dividono in 3 categorie differenti:

• condizioni del tipo F(attr1, attr2, …, attrn) operatore valore come per esempio: 2 × ( area + perimetro ) > 3000 • condizioni del tipo attr1 operatore attr2

come per esempio: area > perimetro • condizioni miste

come ad esempio: 2 × ( area + perimetro ) < area × perimetro

quindi qui si hanno 3 problemi che determinano la necessità di una modifica dell’interfaccia in un’interfaccia più versatile.

L’interfaccia che adotteremo per risolvere questi problemi è un’interfaccia di questo tipo:

Quest’interfaccia, mediante l’ausilio di un parser è in grado di risolvere i problemi che abbiamo riscontrato. Inoltre, mediante una verifica sulla condizione non permette l’occorrere di eventuali errori di sintassi che l’utente può commettere. Per una questione di semplicità del prototipo, i casi che verranno considerati validi da questa interfaccia non saranno tutti i casi possibili.

Siano A, B, C, D alcuni attributi (numerici o stringhe) e siano i, j, k, l, alcuni valori (numerici o testuali).

Le condizioni che verranno implementate sono quelle dei seguenti tipi:

• A op i dove op è un operatore matematico (=,>,<,< >) o su stringhe (=,< >,contiene)

• A op C con op come descritto sopra.

Altra cosa molto importante che viene gestita dalla nostra form è la gestione booleana delle condizioni AND, OR e NOT.

7.3.2.6 Elemento condizione geografica

Le categorie di condizioni geografiche che vogliamo rappresentare (sottoinsieme di tutte le condizioni possibili) sono le seguenti:

• “contenuto in un intorno radiale del punto di applicazione”

• “contenuto in un intorno su percorso del nostro punto di applicazione”

• “contenuto in un’area contenente il nostro punto di applicazione” (se per esempio vogliamo vedere se un punto appartiene o no ad un determinato comune)

Analizziamole una per una.

La condizione geografica di più semplice rappresentazione è la seguente:

“elementi di un insieme che appartengono ad un intorno radiale del nostro punto di applicazione”.

Questa condizione ha il vantaggio che non ha bisogno di null’altro che un valore in metri rappresentante il raggio del nostro intorno.

La rappresentazione in interfaccia è altrettanto semplice, basta un combobox ad indicare che la nostra funzione è una funzione di intorno e un textbox in cui inserire un valore numerico.

CAPITOLO 7 – Il Software

Se prendiamo in considerazione un intorno non radiale ma “su strada”, ovvero la condizione

“elementi di un insieme che appartengono ad un intorno calcolato su percorso del nostro punto di applicazione”.

abbiamo bisogno di un layer lineare di supporto per calcolare l’intorno.

Su questo layer di supporto (lineare) vige lo stesso problema semantico che vigeva per il layer di supporto descritto in precedenza in questo paragrafo (elemento layer di supporto).

Problema analogo ma di minor entità viene riscontrato se prendiamo in considerazione la condizione

“elementi di un insieme che giacciono all’interno della stessa area rispetto al nostro punto di applicazione”.

anche qui abbiamo bisogno di un layer aggiuntivo di supporto, in questo caso però è un layer areale.

A questo punto, abbiamo una scelta da compiere:

nella nostra interfaccia, dobbiamo consentire la definizione di una sola condizione o di più condizioni geografiche contemporaneamente?

Nel caso la risposta sia “una sola”, l’interfaccia è facilmente disegnabile mediante 3 elementi di cui 2 (textbox del valore e combobox del layer di supporto) opzionali e attivati solo in alcune scelte.

Figura 22 – schema di interfaccia per condizione geografica

Nel caso la risposta sia “più di una”, ci ritroviamo in una condizione analoga a quella analizzata nel caso della condizione sugli attributi.

Abbiamo i seguenti problemi:

1. le condizioni sono al massimo 3 ma non è detto non siano ripetibili, infatti posso valutare ad esempio 1 intorno radiale, n intorni non radiali e l’essere contenuto in m aree differenti.

2. ci possono essere condizioni geografiche ricorsive, ovvero ad esempio: case contenute in un intorno radiale del nostro punto di applicazione

La scelta che attueremo per il nostro prototipo sarà quella di consentire un’unica condizione geografica per funzione.

CAPITOLO 7 – Il Software