Difference between revisions of "Meeting DevelopmentTeam SK - 23-04-2014"
Line 12: | Line 12: | ||
# stato call of participation e decisioni relative | # stato call of participation e decisioni relative | ||
− | == Deadline Versione Beta == | + | == 0) Deadline Versione Beta == |
Paola propone le date 8-15 maggio, questa seconda coincide con la riunione LTER di Torino in cui presentarà SK | Paola propone le date 8-15 maggio, questa seconda coincide con la riunione LTER di Torino in cui presentarà SK | ||
− | == Stato EDI == | + | == 1) Stato EDI == |
=== Nuova implementazione SensorML === | === Nuova implementazione SensorML === | ||
Stato: il template che accoglie l'implementazione 4.0 di SOS da parte di 52N è pronto per il testing. | 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 | Persone coinvolte: Alessandro e Fabio per il testing di funzionamento EDI | ||
− | === Implementazione modulo compilazione === | + | === Implementazione modulo compilazione === |
stato: task in chiusura | stato: task in chiusura | ||
manca: gestione campi alternativi | manca: gestione campi alternativi | ||
Line 28: | Line 28: | ||
Persone coinvolte: Fabio, Cristiano, Monica, Alessandro | Persone coinvolte: Fabio, Cristiano, Monica, Alessandro | ||
− | === Editing di EDIML pre-esistenti === | + | === Editing di EDIML pre-esistenti === |
stato: task in chiusura | 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 | 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 | ||
Line 35: | Line 35: | ||
Persone coinvolte: Fabio, Stefano | Persone coinvolte: Fabio, Stefano | ||
− | == Stato integrazione EDI in SK == | + | == 2) Stato integrazione EDI in SK == |
stato: in sviluppo e a cascata del punto precedente | stato: in sviluppo e a cascata del punto precedente | ||
soluzione attuale: | soluzione attuale: | ||
Line 49: | Line 49: | ||
Deadline: ??? | Deadline: ??? | ||
− | == Stato integrazione SOS in SK == | + | == 3) Stato integrazione SOS in SK == |
Stato: | Stato: | ||
Line 63: | Line 63: | ||
Deadline: la comunicheranno Alessandro e Stefano via mail | Deadline: la comunicheranno Alessandro e Stefano via mail | ||
− | == Stato autenticazione == | + | == 4) 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é | 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) | + | 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 | Persone coinvolte: Fabio, con supporto di Stefano e di chiunque si candidi | ||
Deadline: dopo aver finito con EDI | Deadline: dopo aver finito con EDI | ||
+ | == 5) Help e supporto a SK == | ||
+ | Stato: in sviluppo | ||
+ | Proposta: gestione manuale del ticketing da parte di un | ||
[[Category:Meeting pubblici]] | [[Category:Meeting pubblici]] |
Revision as of 16:02, 23 April 2014
Contents
Presenti (via skype)
- IREA: Carrara, Fugazza, Oggioni, Pavesi, Pepe, Tagliolato
- ISMAR: Bastianini, Menegon
Ordine del Giorno
- stato EDI (in particolare editing di EDIML pre-esistenti e “nuovo” SensorML)
- stato integrazione EDI in SK
- stato integrazione SOS in SK (con nuova implementazione 52N)
- stato tool di autenticazione
- stato help e supporto
- stato licenza
- stato call of participation e decisioni relative
0) Deadline Versione Beta
Paola propone le date 8-15 maggio, questa seconda coincide con la riunione LTER di Torino in cui presentarà SK
1) 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
2) Stato integrazione EDI in SK
stato: in sviluppo e a cascata del punto precedente 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: ???
3) 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
4) 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
5) Help e supporto a SK
Stato: in sviluppo Proposta: gestione manuale del ticketing da parte di un