Difference between revisions of "Meeting SP7 - 14/15-11-2013"

Revision as of 17:56, 25 November 2013

Agenda

Giorno 14 Novembre 2013

• 10:30 - 12:30 Introduzione generale riguardante:
  • scopi delle giornate di lavoro (presentazione IREA),
  • ragioni per la realizzazione degli Starter kit (presentazione IREA),
  • principali caratteristiche e funzionalità degli Starter kit (demo a cura di IREA e di ISMAR).
• 14:00 - 17:00 Metadati, creazione e gestione, all'interno di SP7 e degli Starter kit
  • introduzione generale riguardante i Metadati e il loro utilizzo semantico (presentazione IREA)
    • discussione riguardante le funzionalità che dovranno essere implementate nel prototipo,
    • collegamento a linked data (LD).

Giorno 14 Novembre 2013

a cura di A.Basoni

Partecipanti:Stefano Menegon, A. Oggioni, P. Carrara, G. Bordogna, A.Basoni, C.Fugazza,F.Pavesi, Tomas Kliment, Mauro Bastianini, in teleconferenza: Tiziano Minuzzo,Andrea Vianello e Giovanni Bortoluzzo (dalle 14.30 con Carrara e Giuseppe) perdiscutere la questione servizi accentrati o distribuiti). Mattina Vengono introdotti i partecipanti e si ricapitolano i temi della giornata. Inparticolare gli starter kit che hanno l’obiettivo di stimolare l’erogazione deidati dalle periferie (ottica bottom up) con poche difficoltà e garantendo ainodi periferici di farlo con un server e a SP7 che i dati vengano erogati con standarddefinito. Lo starter kit (SK) geografico (CIGNO – Ente responsabile: ISMARcoordinatore: S. Menegon) verrà testato con i dati – mappe relative allatematica mare di IREA mentre lo starter kit osservativo (ENVEUROPE – Enteresponsabile CNR IREA, coord: A. Oggioni) verrà testato con dati messi adisposizione da ISMAR. Viene sottolineata l’importanza di testare il prototipo e le relative funzionalità eindividuarne di aggiuntive. A. Oggioni illustra la sua presentazione per quanto riguarda le funzionalità del kit osservativo la discovery di metadati dei sensori non èstato ancora fatto; viene sottolineato come per l’upload di osservazioni emisure verrà utilizzato uno schema fisso, già prefedinito, mutuato da modellodati OGC, a cui ci si deve adattare, si vorrebbe fare un importatore (per filexls, ecc) per facilitare gli utenti nell’inserimento dei propri datisoprattutto per coloro che non sono in grado di lavorare con insert observationstandard. G. Bordogna sottolinea come sia allora necessario creare unamappatura delle applicazioni se ciascun utente ha un tipo diverso diorganizzazione dei dati. Per ora non è pensato per tutte le esigenze ma èpositivo avere un’interfaccia buona per non obbligarli a fare insertobservation. Si sottolinea che ci sono dei bachi a livello di editor di testiche corrompono il DB e che danno un sacco di problemi. Viene posta attenzione sulle domande aperte, operative e viene stimolata la discussionein particolare sui seguenti temi:

• Come fornire supporto help desk per l’istallazione degli starter kit?
• Come regolare gli aggiornamenti delle versioni dello SK? All’inizio lo diamo comemacchina virtuale se ci accorgiamo di un baco come del DB come facciamo aaggiornare anche lo SK?*Come garantire sicurezza e accesso ai servizi e alle funzionalità? Ad Es. centromaree che ha chiesto proprio questo…*Come gestire un eventuale servizio hosting per nodi non autosufficienti (fino ad orasempre persone con ottima preparazione e disponibilità sistemisti) o nel casole persone non vogliano interagire con i sistemisti?*Architettura cataloghi metadati: mantenerli distribuiti (nelle sedi) o accentrati?

Viene sottolineato come sia necessario attivare canali (web, email) per ricevere segnalazioni automatiche e/o manuali, si propone bug tracking digitato o altro esi chiede di aprire un indirizzo dedicato per assistenza per evitare che vadanosulla sua posta personale (S.Menegon). Si discute la possibilità di fare log per tracciare chi carica i dati, relativafrequenza con la finalità di monitorare quanto il servizio viene usato e anche permappare nodi critici. Per fare in modo che i server esterni depositino i log nel nostro occorre preparareun disclaimer che ogni partecipante dovrà sottoscrivere in modo da assicurarciche le informazioni ci arrivino e per tutelarci. Si propone di utilizzare github per gestire (documentazione, ricezione mail su bug, ecc.)e distribuire gli SK (F. Pavesi sottolinea come consista solo di un link ma nondeployment delle macchine virtuali perché non è possibile); https://github.com/SP7-Ritmare/ (a cui si deve aggiungereil logo di Ritmare) Per le richieste di aiuto occorrerà attivare un help desk, se github lo permettealtrimenti si va verso altre soluzioni. Siamo aperti ad altri suggerimenti. Vienesottolineato come si debba registrarsi su github per fare segnalazione e forsenon è immediato per l’utente “non esperto”. Si svolge una discussione sulla necessità pubblicare i codici sorgente che sesono open source vanno resi disponibili (Menegon). Sarebbe bene avere unrepository dove il codice che andiamo a sviluppare noi sia in chiaro. Inoltre, vistoche non è possibile brevettare, è importante evidenziare che questo softwaresia uscito da Ritmare. Viene sottolineato che l’assistenza porta via molto tempo, mettere in piedi un nodoper chi non è sistemista è molto impegnativo. Inoltre chi non ha il sistemistasi deve appoggiare a un hosting. Se non si è in grado di dialogare con sistemista, si va nel proprio CED o altri,almeno temporaneamente lo ospitiamo noi, poi ci sarà il piano della maintanancee occorre preparare un piano della sostenibilità per il futuro. Viene stressato il fatto che è molto importante offrire questa soluzione perchéaltrimenti non avremo i dati, è meglio fare uno sforzo ora ma per vedere deirisultati poi. Inoltre i livelli di difficoltà dipendono anche dalla maturità del software, adesso èpacchettizzato molto più stabile si aspetta meno difficoltà, in più si cercheràdi non aggiungere cose complesse e strumenti di base senza voli pindarici. Poi il prodotto meno si tocca più è affidabile. Adesso è difficile dare opinione senza avere esperienza. Parte di incertezza con laquale dobbiamo fare i conti. Meglio forse proporlo prima a persone con un certoskill poi vedere come va… Viene sottolineato che non ci si aspetta che SP7 operi come una società di servizi mache per ora crei solo prototipo testato su soluzioni più mature. E bisogneràstare attenti a dare in pasto lo SK a persone che non ci daranno problemi.Faremo anche dei disclaimer per tutelarci anche per qualsiasi cosa possasuccedere ai loro server. Faremo il monitoraggio sui log e in modo da non essereresponsabili se i nodi spengono; la macchina introdurrà dei test per fare delleverifiche. Si suggerisce anche una lista dei requirements – se vuoipartecipare, ti devi dotare di questo, ecc. Viene proposto di usare il metodo del memorandum of understanding (esempio delprogetto DORIS_Net) con accettazione di alcune condizioni da soddisfare suirequirements. Viene poi introdotto il discorso relativo alla possibilità di “pingare” eventuali SKgià attivi, interessante per futuro prototipo. Quando gli SK verranno accesi ilprototipo dovrà cercare di vedere si in nodi sono attivi. F.Pavesi propone di usare SNMP in modo da ottenere altreinformazioni…visualizzazione dati in forma grafica. Forse un po’ invasivo comeprotocollo. Anche a Tiziano non vengono in mente sistemi meno invasivi. Dalpunto di vista tecnico sono tutti equivalenti. S. Menegon afferma che in Cignoviene usato google analytics, non ci traccia i servizi geoserver, va bene perclient meno per server. Per noi è importante tracciare anche questi ultimi. Vengono elencate le soluzioni da adottare per lo SK esistono 3 livelli:

• google analytics buono per lato client,
• analisi log http per info su come sta erogando il servizio supposto raggiungibile,
• monitoraggio della raggiungibilità del server.

Vengono decise le seguenti suddivisioni dei compiti: S. Menegon si occupa di google analytics per vedere se lo strumento è adeguato. F. Pavesi si può occupare del secondo livello; le informazioni ottenibiliriguardano l’IP client, che query è passata, ecc. Si offre di stabilire unformato comune per i log apache e una modalità di trasmissione per tutti. Chevale anche per le query dei singoli utenti quando fanno le discovery, utileanche per il prototipo successivo.Tiziano si occupa del monitoraggio della raggiungibilità del server e dello SK (ping). A.Oggioni introduce la questione dell’aggiornamento. Ovvero: l’aggiornamento comefarlo? Ci sono due orientamenti chi vuole aggiornare spesso chi mai. SI riesce con il DB esistente? Se inizi a popolare il DB poi bisogna fare aggiornamenti, con quali impatti? con Monica Pepe si è tenuto conto di due possibili livelli.

Il primo come effettuare tecnicamente gli aggiornamenti? Secondo aspetto, una volta stabilito che occorre aggiornarli quali sono le caratteristiche degli aggiornamenti e le esigenze delle persone? Si cercherà di rispondere a queste domande. E’interessante abilitare l’aggiornamento degli SK che ci permette di fare un delay delle azioni di monitoring (prevedendo delle azioni di monitoringnecessarie fin dall’inizio dal prototipo e altre che possono essere aggiunte inseguito), dato che gli SK vengono aggiornati e se pensiamo di voler monitoraredelle funzionalità differenti lo possiamo fare in qualsiasi momento perchél’aggiornamento ce lo consente. Vengono suggerite da F. Pavesi dei differenti livelli di priorità di aggiornamento: unlivello di base-macchina al livello del sistema operativo. Meno si aggiornameglio è (perfetto accorso con Tiziano) a meno di problemi gravi come bug, ecc.Mentre per gli applicativi abbiamo due situazioni: quelli che mutuiamo (ad es. geoserver,52 North) e quelli dei software che produciamo noi. Frequenze consigliate da F. Pavesi:

• per il livello base macchina la più BASSA possibile;
• per l’applicativo mutuato: una frequenza MEDIA;
• per il software che sviluppiamo noi e delle terze parti, soprattutto nella fase iniziale di sviluppo, una frequenza più ALTA.

F.Pavesi ipotizza un tool da parte dello SK, una sorta di anticamera, dove gli SKsanno dove poter andare a verificare seci sono degli aggiornamenti: lo SK chiede periodicamente (settimana?) se ci sono e quali sono gli aggiornamenti. Noi dobbiamo avere pronto un piano diaggiornamento sullo SK. Il sistema operativo va predeterminato con unafrequenze per testare la sicurezza e versioni (LTS). Per gli altri livellidobbiamo avere la possibilità di verifica prima di fare l’aggiornamento, non èbanale bisogna avere la possibilità di fare un’istantanea, uno snapshot della macchina primadell’aggiornamento, procedimento per affinamento in modo che se il processofallisce sia possibile tornare indietro. Si sviluppa una discussione sull’opzionalità di alcuni aggiornamenti che non è ritenuta fattibile dato che le periferie non rientrano nella decisione del merito degli aggiornamenti ma sono obbligati a l’obiettivo è rendere disponibili i dati a tutte le comunità e garantire l’interoperabilità ma con la condizione che venga fornito supporto alle periferie. In conclusione si tratta il tema della sicurezza e dell'accesso. Si dovrebbe tutelare il fatto che i dati sono a disposizione della rete ma non dell’esterno. Per quanto riguarda gli aspetti di sicurezza le funzionalità di amministratore dello SK le rileva chi prende in carico lo SK e fa l’istallazione tramite la sottoscrizionedel MoU dovremmo garantirci che loro utilizzeranno il software e che lo farannofunzionare se gli viene dato supporto e si devono occupare della sicurezza. Per la parte accesso differenziato ai dati occorre aggiungere un proxy nostro sullo SK che valuti le richieste. Viene citato ad esempio il caso dei dati osservativi di ENVEUROPE: tutti i dati vengono condivisi dalle comunità partecipanti. I metadati sono accessibili a tutti per la ricerca, solo chi ha un’utenza ad hoc può accedere ai dati.

Giorno 15 Novembre 2013

• 9:30 - 10:00 Divisione in gruppi di lavoro:
  • Starter kit geografico,
  • Starter kit osservazioni.

10:00 - 16:00 parallelamente:

• Gruppo di lavoro Starter kit geografico:
  • testing GeoNode con vector e raster preparati da IREA
• Gruppo di lavoro Starter kit osservazioni:
  • testing con dati osservativi centro marea e testing/realizzazione editor SensorML

minute 15 novembre

• Discussione sullo sviluppo di un tool di editing di metadati (per dati raster e vettoriali)condiviso dai due starter-kit geografico e osservativo : occorre fare un mapping tra campi di MD INSPIRE - RNDT - OpenData Portal (RDF) - GeoNode default. Il mapping INSPIRE/OpenData Portal è già stato fatto da Cristiano, il mapping tra INSPIRE e RNDT è offerdo dal documento RNDT_guida_operativa_dati_v1.2.pdf.
  • Le utenze dell'infrastruttura Ritmare si troveranno in una di queste 4 situazioni:
    • A) dati non pubblicati non metadatati
    • B) dati non pubblicati, metadatati
    • C) dati pubblicati non metadatati
    • D) dati pubblicati, metadatati
  • L'editor di metadati dello starter kit dovrà servire alle utenze A) e C), mentre le necessità delle altre utenze dovranno essere risolte con altre soluzioni, eventualmente esterne allo starter kit. Il tool di editing dovrà dunque prioritariamente aiutare a compilare metadati ex novo. Critiano e Paola si occupano di analizzare gli scenari per i casi B) e D)
  • I nodi periferici saranno abilitati a gestire i metadati lì compilati. Il nodo centrale avrà utilità per reperire e riutilizzare i metadati gestiti dai nodi periferici
  • Lo starter kit dovrà fornire dei cataloghi periferici, dai quali poi estrarre informazioni per l'infrastruttura centrale? L'alternativa è concentrare sin da subito i metadati nell'infrastruttura centrale.
  • Discussione su parallelismi e differenze della matadatazione in campo mapping geografico e in campo osservativo. Mentre per i dati geografici esiste un servizio di catalogo standard CSW, bisogna stabilire il sistema migliore per fare la discovery dei dati osservativi (e anche qui decidere se fare harvesting) e decidere se vale la pena di unificare i due sistemi. Poichè non ci saranno beneficiari di entrambi gli starter kit, non c'è una reale necessità di unificare i due sistemi di discovery, questo farebbe propendere a favore della separazione dei sistemi di discovery (cataloghi) e di metadatazione tra starter kit geografico e osservativo.
  • Separazione dei lavori in due gruppi: uno dedicato allo starter kit geografico (Menegon, Criscuolo, Pepe) e uno al mapping fra profili di metadati (Fugazza, Oggioni, Carrara).
• Test sullo starter kit geografico:
  • import di file vettoriali: il gruppo SHP (dbf + prj + shp + shx) relativo ad una linea di costa viene caricato correttamente da locale e appare la finestra di compilazione del metadato relativo
  • import di file raster: il geotiff di test ritorna error auto-configuring coverage -> dopo l'aggiornamento di geonode l'errore cambia in: could not aquire reader for coverage. Il problema si dimostra relativo alla cattiva definizione della proiezione all'interno del geotiff; purtroppo il geotiff è l'unico formato raster supportato (vedi sotto) ed è difficile comprendere a priori se contiene difetti (come quello relativo alla proiezione).
    • per risolvere il problema di mancato o erroneo sistema di riferimento-proiezione per i tif, si possono mettere a disposizione file prj per ciascun sistema (ma il prj può essere associato solo tramite comando il shell)
  • campi di metadati di default: alcuni campi mancano ed alcuni campi vanno chiariti (es Data, DataQuality, .../ le keywords vanno blindate in base al dizionario controllato/ la categorie vanno modificate in considerazione dei tematismi Ritmare, ad es manca la categoria Sea mentre esiste la categoria Oceans)ma queste discussioni sono rimandate a quando sarà definitiva l'analisi dell'allineamento dei profili
  • compilazione metadati: caricando un layer con il suo metadato in formato XML tramite drag-and-drop Geonode associa automaticamente i metadati contenuti nell'XML file al layer.
  • batch import di gruppi di dati e metadati:
    • si possono trascinare/selezionare più dati sulla finestra di caricamento, purtroppo la richiesta di metadatazione non è più diretta, ma deve avvenire tramite il relativo pulsante che si presenta sulla lista, non c'è un passaggio automatico all'ambiente di editing MD, come nel caso del caricamento di file singolo; per non ripetere da capo l'editing di MD simili. Si può mettere in grado l'utente di creare un template di metadato xml da associare poi a gruppi di layers. Sarebbe da implementare una icona di warning accanto a ciascun layer privo di metadati, per ricordare all'utente di inserirli.
    • possibile per un'intera directory anche senza selezione, solo da linea di comando, può anche favorire la compilazione dei metadati, applicando a tutto il dataset gli stessi metadati (per ora applica alcuni campi comuni a tutto il dataset). Esistono già degli script degli sviluppatori GeoNode che si possono utilizzare per estendere la funzione di compilazione "di gruppo" a tutti i campi di metadati.
  • vestizione: tramite file SLD, è possibile infatti caricare anche file.sld contenente lo stile da applicare al layer insieme allo stesso e poi agire sulle associazioni per più file.
  • sarebbe utile stilare una lista dei formati supportati, dei gruppi di file che devono essere caricati insieme (es il gruppo shp-shx-prj-dbf), fornire soluzioni per conversioni più comuni (es kml-shp, hdf-tiff), delle procedure per favorire tipi alternativi di upload (batch import, da DB con estensione geografica). Sarebbe utile aggiungere nella pagina di upload un breve testo con l'elenco di formati accettati e qualche indicazione di massima.
  • nella tendina per scaricare metadati si può cambiare la dicitura TC211 in ISO 19115

Conclusioni

Sono stati riportati i risultati e i commenti dei primi esperimenti di importazione di vettori e mappe, prima singolarmente e poi sotto forma di gruppi. Le considerazioni e i suggerimenti sono le seguenti:

1. l'interfaccia è molto diretta per il caricamento dei dati, anche in gruppi;
2. per evitare onerose ripetizioni di metadatazione durante l'inserimento di gruppi omogenei di dati, si dovrà abilitare la creazione di template (in gergo GeoNetwork).
3. nell'ingestione di gruppi di dati bisognerà notificare la necessità di metadatazione, più di quanto non sia presente nell'implementazione attuale (warning o alerting), per rendere la creazione del metadato obbligatoria.
4. bisogna trovare soluzioni di supporto ben congegnate perché i formati di ingestione sono molto limitati: SHP & TIFF (fra l'altro non quelli con tfw esterno), quindi:
   1. bisognerà renderlo noto e ben visibile, e comprensibile per i non addetti ai lavori
   2. bisognerà fornire o concepire (a livello starter kit o a livello nodo centrale) degli strumenti di conversione in tali formati (e qui Laura e Monica, con l'aiuto di Fabio dovranno indagare, se specificati nelle interviste, i formati più comuni)
   3. bisognerà rendere consapevoli gli utenti della necessità delle informazioni relative al sistema di riferimento geografico in cui sono inquadrate le loro mappe: es. presenza del file prj; problema più grosso è invece poter verificare la loro correttezza