Meeting DevelopmentTeam SK - 23-04-2014

Stato EDI

Nuova implementazione SensorML

Stato: il template che accoglie l'implementazione 4.0 di SOS da parte di 52N è pronto per il testing. Persone coinvolte: Alessandro e Fabio per il testing di funzionamento EDI

Implementazione modulo compilazione

stato: task in chiusura manca: gestione campi alternativi priorità: alta tempi: martedì 29 per RNDT, TBD per SensorML Passo successivo: validazione metadati RNDT (ISO e INSPIRE), loro gestione in PyCSW, validazione SensorML Persone coinvolte: Fabio, Cristiano, Monica, Alessandro

Editing di EDIML pre-esistenti

stato: task in chiusura Soluzione adottata: dalla generazione di un XML viene memorizzato l'EDIML, aggiunta di un URI all'interno del DB di EDI lato server in modo che il client lo possa richiamare, il lato di reperimento lato server è pronto Manca: creazione dell'interfaccia di editing e la richiesta da parte del thin client dell'URI via JS, come URL (NDR: aiuto Fabio, ho scritto malissimo!), da decidere (vedi sotto) se da remoto o in locale (perché anche in locale avviene la archiviazione degli EDIML compilati) Passo successivo: integrazione in SK Persone coinvolte: Fabio, Stefano

Stato integrazione EDI in SK

stato: in sviluppo e a cascata da [[1]]

Soluzione attuale:

meccanismo di post con un proxy, dove si innesta anche la verifica del certificato dell'autenticazione del nodo sul server centrale
quindi inserimento dei XML generati nel CSW e archiviazione di EDIML nel repository locale

Nel momento dell'integrazione del re-editing di MD bisognea decidere se effettuarlo sul EDIML del nodo periferico o centrale. La filosofia finora è stata quella di privilegiare il nodo centrale, per assicurare eventuali recovery (che però possono essere anche dai nodi periferici al centrale).

Passo successivo: Controllo CSW In discussione: Attualmente l'inserimento di XML di datasets popola il CSW e crea i campi ISO a Geonode per funzionalità proprie come ricerca per categorie. Si discute brevemente di questo e della possibilità di intervenire sul search interno di Geonode che funziona sulle Categorie Tematiche ISO (NDR: ho controllato in geosk ma non ho trovato riscontro: la linea di costa risulta boundary come categoria geonode, ma Oceani come Categoria tematica nel suo MD) Difficile intervenire nel meccanismo di search di Geonode che è piuttosto cablato (eventualmente si può mascherarne parte), keywords a testo libero, possono essere utilizzati i temi INSPIRE. Il problema cmq non si pone, anzi che la discovery locale in GeoNode rimanga ristretta, perché la discovery principale e più completa sarà quella dell'infrastruttura centrale. Persone coinvolte: Stefano, Fabio Deadline: ???

Stato integrazione SOS in SK

Stato: 3 subtask:

explore SOS per la visualizzazione dei metadati del SOS locale: completato
sensor registration per la registrazione sensore tramite compilazione SensorML relativo
upload observation per il caricamento delle osservazioni

manca:

sensor registration: da EDI del nuovo SensorML
upload observation: ereditato dalla prima implementazione OSK (di Alessandro e Fabio) bisogna decidere se direttamente in "SQL" sul DB locale o passando dalla chiamata SOS InsertObservation con XML relativo

In discussione: disaccoppiamento delle chiamate SOS 2.0 con un proxy server che supporta il client (NDR: aggiungete pure) Deadline: la comunicheranno Alessandro e Stefano via mail

Stato autenticazione

Stato: pending, funziona la certificazione lato client (ovvero il client vede il certificato del server) ma non viceversa e non si hanno indicazioni sul perché Proposta: trovare una soluzione alternativa del tipo OpenID o OAuth, che fra l'altro sono abilitati già in locale su SK (in SK c'è la parte client di Python social auth che li supporta entrambi https://github.com/omab/python-social-auth) Persone coinvolte: Fabio, con supporto di Stefano e di chiunque si candidi Deadline: dopo aver finito con EDI

Help e supporto a SK

Stato: in sviluppo

help

stato: pennding, si concluderà quando i template dei MD saranno definitivi considerare le due lingua IT e inglese, considerando anche l'utenza internazionale Persone coinvolte: Monica, Anna B.

supporto agli SK

Stato: in sviluppo

Proposta: gestione manuale del ticketing da parte di un front-end umano (Anna Basoni), che ridiriga le questioni alle persone di riferimento adeguate e che tenga traccia dell'apertura e della chiusura degli incidenti. Obiettivo è di non intralciare chi si occupa attivamente dello sviluppo del progetto tramite: - gestione di un incidente per volta - cercare di ridirezionare il più possibile gliutenti alle pagine wiki dedicate e a tutta la documentazione fornita - introdurre un tutoring da parte di personale non direttamente coinvolto nello sviluppo

Discussione: utilizzo di un forum oltre che di wiki? la possibilità di utilizzare gli strumenti di github (che fanno anche ticketing), può essere interessante e aiutare anche il coinvolgimento di realtà esterne a RITMARE; non è un vero e proprio forum ed è pubblico. Si decide che comunque è una buona soluzione, dato che github verrà usato anche per la distribuzione.

Persone coinvolte: Anna, Monica e Paola (controllo qualità), ma con supporto di tutto il team Deadline: ???

Licenza SK

Stato: pending Discussione: La questione si fa urgente, non solo per l'imminente rilascio, ma anche per i contatti con ODIP e le collaborazioni in atto con lo stesso ed IMOS. Paola propone di semplificare la proposta iniziale foggiando la licenza sullo stile di OpenLocast-Web del MIT (https://github.com/mitmel/OpenLocast-Web) e completandola con i disclaimer riguardanti le responsabilità dei gestori del nodo.

Stato call of participation

Al momento ci sono state sottoposte on-line (call for participation results) 4 candidature (OGS , CINFAI Università di Camerino, CNR-ISMAR u.o.s. La Spezia, CNR - ISMAR U.O.S. di Pozzuolo di Lerici (SP)), ma sappiamo si aggiungerà ISMAR Lesina, e poi Comune di Venezia e ARPAV (ma come boe gestite ISMAR)

Varie ed eventuali

Si propone di usare Trello per avere una visione sinottica sullo stato dei task ed evitare duplicazioni degli sforzi. Dopo una breve discussione si conviene di utilizzarlo, dopo una breve alfabetizzazione di chi non è abituato al suo utilizzo.

Si decide di riaggiurnarsi il giorno 6 maggio, dopo EGU e prima della visita di Roger Proctor.

Meeting DevelopmentTeam SK - 23-04-2014

Contents

Presenti (via skype)

Ordine del Giorno

Deadline Versione Beta