Jump to: navigation, search

Difference between revisions of "Getting Started OLD"

m
m
Line 38: Line 38:
 
* all'utente viene presentata una pagina (che e' servita dallo starter kit) la quale accede in remoto a EDI per ottenere la parte dell'interfaccia (l'editor) da integrare con l'interfaccia residente
 
* all'utente viene presentata una pagina (che e' servita dallo starter kit) la quale accede in remoto a EDI per ottenere la parte dell'interfaccia (l'editor) da integrare con l'interfaccia residente
 
* servizio genera html, da realizzare:
 
* servizio genera html, da realizzare:
  ** X inserimento campi multipli
+
** X inserimento campi multipli
  ** X tipi complessi (es. bb, date range)
+
** X tipi complessi (es. bb, date range)
  ** X integrazione con bootstrap
+
** X integrazione con bootstrap
 
* l'utente lo compila
 
* l'utente lo compila
 
* X al momento del post, avviene validazione di tipo e di mutua dipendenza tra campi (in locale, nel browser)
 
* X al momento del post, avviene validazione di tipo e di mutua dipendenza tra campi (in locale, nel browser)

Revision as of 10:57, 10 January 2014

Perché iniziare?

Queste pagine di supporto sono dedicate alla installazione ed utilizzo dei componenti sviluppati da SP7 per supportare i ricercatori, che non possiedano già un'Infrastruttura di Dati Spaziali, o che vogliano espandere la propria, ad abilitare servizi interoperabili e conformi agli standard nazionali ed internazionali. Questi componenti abilitanti sono dedicati a:

  1. creare ed esporre delle informazioni (metadati) in formato standard relative alle risorse (dati geografici o osservazioni), che ne permettano il reperimento via web da parte del ricercatore stesso o di altri ricercatori;
  2. creare dei servizi web che permettano l'esposizione, sotto forma di visualizzazione, accesso ed eventuale scaricamento di mappe o piani informativi geografici (layer), in modalità interoperabile;
  3. creare creare dei servizi web che permettano l'esposizione, sotto forma di visualizzazione, accesso ed eventuale scaricamento di osservazioni provenienti da sensori di varia natura (boe, gliders, ...)

I componenti abilitanti sono stati sviluppati sotto forma di moduli, ciascuno rispondente alle componenti di cui sopra, essi possono essere utilizzati separatamente o congiuntamente.

Ciascun modulo ha un nome:

  • EDI è l'ambiente per la creazione dei metadati, sia dei dati che dei sensori.

EDI si uniforma, per i metadati dei dati (siano essi mappe od osservazioni) alle specifiche del Repertorio Nazionale dei Dati Territoriali (RNDT), che sono a loro volta in conformità alla Direttiva Europea INSPIRE. EDI si uniforma per i metadati dei sensori le specifiche internazionali SensorML.

  • GSK Geo Starter Kit: è il modulo per la creazione e gestione di servizi web standard relativi a mappe o piani informativi geografici (layer). Ovvero permette di pubblicare, rendendoli visualizzabili e accessibili, i dati geografici, siano essi vettoriali, raster o coverage.

GSK utilizza una soluzione open basata sulla piattaforma CIGNo, personalizzata per le esigenze di progetto, che supporta le principali operazioni per: caricamento dati, archiviazione dati, vestizione ed esposizione web (visualizzazione e/o accesso/download secondo interfacce standard WMS, WFS, WCS). Permette inoltre, la creazione dei metadati relativi ai dati (tramite integrazione del modulo EDI), e la creazione/gestione ed esposizione del catalogo dei metadati stessi.

  • OSK Observation Starter Kit: è il modulo sviluppato per SP7 che si occupa di abilitare i servizi web standard per le osservazioni provenienti da sensori di varia natura.

OKS utilizza una soluzione open basata sulle specifiche Sensor Web Enablement (SWE), come implementate dall'iniziativa per il software opensource denominata 52°North (52N). OSK supporta le principali operazioni per: caricamento dei dati osservativi, archiviazione e gestione dati in un Data Base Management System, esposizione delle osservazioni su web (secondo interfaccia standard SOS)

Cosa fare?

Come farlo?

Workflow e avanzamento

Questo il dettaglio di come EDI di debba integrare nei workflow dei due SK, con indicato cosa resta da realizzare/rivedere. Legenda (tentative):

  • X : aspetto da realizzare/rivedere entro la presentazione del prototipo (il c.d. proto-prototipo).
  • (X) : aspetto da realizzare/rivedere entro la release del prototipo.
  • ((X)) : aspetto da realizzare/rivedere entro la realizzazione dell'infrastruttura centrale.

Dettagli sul workflow:

  • (X) Mappatura autenticazione utente su strutture foaf
    • Scopo: per attualizzare i campi che possono essere autocompilati/suggeriti in base all'utente che si e' autenticato (es. i vari contact point) è necessario realizzare la procedura di autenticazione.
    • Stato: essendo dipendente dal singolo deployment degli SK, è possibile che si possa rimandarne l'implementazione alla release degli stessi, utilizzando in fase di presentazione un utente di default per illustrare il funzionamento.
  • l'utente decide di inserire un dato in GSK o un sensore in OSK (dove vengono inserite le osservazioni dei sensori?), ad un certo punto si provvede all'editing dei metadati.
    • X Da chiarire: abbiamo due entry point distinti, uno per ognuno dgli SK:
      • GSK: verificare con Stefano se e come questo può attivare l'editing dei metadati relativi.
      • OSK: potrebbe essere desiderabile inserire la descrizione di un sensore senza partire da osservazioni; in ogni caso, verificare con Alessandro come strutturare questo passaggio.
    • X Da chiarire: verificare con Stefano che sia chiaramente visibile il modo per inserire risorsa (che dovrebbe avviare l'editor di metadati)
  • all'utente viene presentata una pagina (che e' servita dallo starter kit) la quale accede in remoto a EDI per ottenere la parte dell'interfaccia (l'editor) da integrare con l'interfaccia residente
  • servizio genera html, da realizzare:
    • X inserimento campi multipli
    • X tipi complessi (es. bb, date range)
    • X integrazione con bootstrap
  • l'utente lo compila
  • X al momento del post, avviene validazione di tipo e di mutua dipendenza tra campi (in locale, nel browser)
  • avviene il post
  • il server edi compone l'xml secondo il template (es. rndt), da realizzare:
    • X tutti i campi con isFixed="true", auto
    • X gestione campi multipli
  • X il server valida l'XML secondo lo schema corrispondente (RNDT, SensorML)
  • l'XML torna indietro al browser (non allo starter kit di riferimento), da realizzare:
    • X GSK: vedere con Stefano il passaggio dell'xml a geonode come step worflow inserimento risorsa
    • X OSK: vedere con Alessandro il meccanismo di describesensor o quant'altro