Difference between revisions of "Ingredienti per un prototipo"

Revision as of 12:54, 6 December 2013

Abstract

Appunti per un piano un po’ più esecutivo, individuando casi d’uso e soggetti che garantiscano sia una certa fattibilità (disponibilità di dati e funzionalità) in tempi ragionevoli, che una buona rappresentatività (vedi viste elencate sotto).

Razionale

Secondo quanto emerso dalle interviste e dalle successive analisi e sintesi, emergono alcuni “ingredienti” da privilegiare per il prototipo, ovvero:

1. rete osservativa (metadatazione sensori – SensorML – e distribuzione osservazioni, anche in Real Time – SOS) (importante in particolare per SP5)
2. strumenti di collaborazione trasversale fra gruppi (importante in particolare per SP3 ma trasversale al progetto)
3. inquadramento dell’area geografica (trasversale a tutto il progetto)

Obiettivo: selezionare e descrivere casi d'uso e prospettare scenari d’interazione fra soggetti appartenenti a RITMARE basandoci su persone reali (in grado quindi di fornire o richiedere dati/funzionalità). Questi casi e persone devono essere rappresentativi sotto diversi profili, o viste. Tali viste sono state individuate come:

1. flussi di lavoro
2. tipo di comunità (Aree di ricerca)
3. tipo di dati (osservativo, raster, vector)
4. campagne di misura in situ
5. tipo di processi (Quality Check per sp5 (Cardin), analisi di dati biologici (Bastianini, Foglini) analisi di serie temporali (Fontolan), Analisi di mappe (Piatanesi))
6. rappresentatività dei sottoprogetti e degli enti coinvolti

Soggetti e loro classificazione

Si è proceduto ad una individuazione di soggetti candidati, ovvero persone di riferimento, e ad una loro classificazione, quali consumatori/produttori, in riferimento ai macrorequisiti

1. boe ed intercalibrazione (Cardin, OGS; Manzella, ENEA; Bastianini, CNR)
2. habitat costieri, carote di sedimento, biologia (Foglini, CNR)
3. metadati di crociera, batimetrie, transetti nave (Campiani, Bortoluzzi, CNR)
4. aspetti collaborativi (Bresciani, CNR; Del Negro, OGS; Fontolan, CONISMA)
5. tsunami (Piatanesi, INGV)
6. DSS difesa costiera (Scarcella, CNR)
7. ground true validation per remote sensing, serie storiche (Bastianini, CNR)

(manca SZN)

Per queste persone, considerando i Macrorequisiti (WP1_AZ1) come ordinati dal Panel, si possono desumere due matrici: consumatori e produttori (come nelle figure seguenti).

Ipotetico flusso di lavoro

1. macrorequisiti secondo il panel
2. selezione persone secondo il punto 1)
3. selezione persone secondo le viste
4. ipotesi di flussi di interscambio tra le persone coinvolte
5. individuazione dei flussi di interscambio fattibili
6. rappresentazione di casi d'uso
7. utilizzo delle analisi delle soluzioni interne al progetto per l'approvvigionamento di dati e funzionalità nei flussi di interscambio fattibili
8. progettazione del prototipo alla luce delle soluzioni interne esistenti e dei casi d'uso
9. implementazione del middleware, del controller e dei widget di interfaccia per rispondere ai casi d'uso delle persone coinvolte

Ipotesi flussi di interscambio

Secondo quanto riportato sopra e relativamente al punto 4), sono stati ipotizzati, seguendo l'ottica dei macrorequisiti, diversi piani di interscambio, numerati appunto secondo i macrorequisiti. Nei diagrammi seguenti sono riportate le istantanee di questi piani di interscambio possibile fra gli attori individuati (come selezionati al punto precedente) in forma diagrammatica.

Condivisione dati di base

Informazioni sull'area geografica

Strumenti di collaborazione trasversale fra gruppi

Gestione dati Real-Time

Opzioni di visualizzazione avanzate

Casi d'uso di interscambio

1. intercalibrazione di boe o elementi della rete osservativa (su base della descrizione nominale)
2. utente che misura transetti e che utilizza lo use case precedente per validare od indirizzare la propria misura
3. utente (e.g. Bresciani) misura in situ parametri che servono a caliibrare/validare stime degli stessi da immagini telerilevate
4. utente (e.g. Bresciani) usa parametri di base misurati dalla rete osservativa per decidere dove/quando misurare
5. utente (e.g. Bortoluzzi) usa prodotti da telerilevamento a bassa risoluzione per la scelta delle rotte da seguire in crociera (e quindi dei transetti da operare)
6. utenti che usano come input a modelli: dati di base da rete osservativa intercalibrati (UC1), dati di verità a terra (UC3) e mappe da telerilevamento (UC7)
7. produzione di mappe de telerilevamento utilizzando dati di base da rete osservativa intercalibrati (UC1), dati di verità a terra (UC3)
8. visualizzazione/accesso ai dati di base per un confronto analitico, per cui occorre aggregare (e..g. diverse frequenze), trasformare (e.g. unità di misura) e più genericamente armonizzare
9. visualizzazione 2D+, 3D o nD dei dati di base (anche previa spazializzazione)
10. modelli per la produzione di mappe di sintesi e/o indicatori utilizzando come input datasets forniti da Data Services (es OGC-WFS, OCG-WMS).