Difference between revisions of "GeoPortal"

From Gcube Wiki
Jump to: navigation, search
 
(10 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
[[Category:gCube Features]]
 
[[Category:gCube Features]]
== Overview ==
 
 
GeoPortal is a feature-complete framework enabling the publication, access and management of GIS projects consisting of multiple documents, images, and datasets. It can be configured with the XML specification of the GIS project data model.
 
GeoPortal is a feature-complete framework enabling the publication, access and management of GIS projects consisting of multiple documents, images, and datasets. It can be configured with the XML specification of the GIS project data model.
  
Line 6: Line 5:
  
 
=== Key features ===
 
=== Key features ===
 
+
GeoPortal key features are :
;GIS Projects Publication mangement
+
;Support for publication lifecycle:
:CRUD operations, publication lifecycle, validation and associated data management features.
+
:By supporting '''complex Data''' (Meta + Payloads) archives;
 
+
:By enableing '''versioning''', '''workflows''', '''access policies''';
;Automatic GIS Indexing
+
:By supporting several '''materialisations''' (GIS, Databases, ...)
:GIS Data is indexed in order to serve custom defined queries.
+
:By managing '''indexes''' (Meta catalogues, Index GIS layers)
 
+
;Maximise reusability:
;OGC Compliant interfaces
+
:By exploiting '''space-time''' [[GeoPortal Service]]
:GIS Data and metadata is exposed in OGC Compliant services and formats
+
:By allowing for '''configurable behaviour''';
 
+
:By supporting a '''generic meta-model''';
;Extensible GIS Project defintions and behaviour
+
:By offering '''configurable GUIs''' (Management grid, Insert/Edit Form, Data Viewers);
:GIS Projects structure are defined by extensible profiles which include instruction for GUI generation, indexing and validation.
+
;External Data Integration:
 
+
:By exploiting '''OGC standards'''.
  
 
== Design ==
 
== Design ==
Line 26: Line 25:
 
Aim of the framework is to maximize adaptability by supporting custom model and behaviour definition.  
 
Aim of the framework is to maximize adaptability by supporting custom model and behaviour definition.  
  
=== Architecture===
+
=== Architecture ===
The framework includes:  
+
[[Image:Geo Portale(1).png|frame|center|GeoPortal Architecture]]
*'''Data Collection Form''' assisting users to publish GIS projects;
+
*'''GIS Viewer''' allowing any user to visualize projects on a map;
+
*'''Project Viewer''' assisting users to access all the information, documents, images and datasets associated to the GIS project;
+
*'''GeoPortal Service''' managing validation and management of GIS projects.  
+
  
The service relies on the D4Science Workspace for storing and accessing attached documents and on the D4Science SDI [[Spatial_Data_Infrastructure_Facilities| Spatial Data Infrastructure]] to offer '''OGC''' Compliant Services (e.g. WMS, WFS, WCS, etc.).  
+
The framework provides the following Dynamic GUIs, which use the Profile metadata definition to enable tailored:
 +
*[[Data Collection]] : Form assisting users to publish GIS projects;
 +
*[[GIS Viewer]] : allowing any user to visualise projects on a map;
 +
*[[Project Viewer]] : assisting users in accessing information, documents, images and datasets associated with the GIS project.
  
It also uses an internal archive of registered documents for the management of Projects lifecycle and for querying purposes.  
+
'''Dynamic GUIs''' rely on java client libraries to communicate to the [[GeoPortal Service]], managing validation and management of GIS projects.
 +
The service relies on the [[StorageHub | D4Science Workspace]] to store and access attached documents and on the [[Spatial Data Infrastructure | D4Science SDI]] to offer '''OGC''' Compliant Services (e.g. WMS, WFS, WCS, etc.). It also uses an internal archive of Profiled Document to manage publication lifecycle and for querying purposes.
  
Following is a conceptual schema of the framework in relation to the D4Science infrastructure and user perspective.
+
=== Extensible Model ===
 +
Dataset schemata are defined as '''Profile''', and every managed collection of documents refer to a specific Profile. A complex geo-temporal dataset linked to a Profile is called '''Profiled Document'''.
 +
This approach allows for the definition of tailored Profiles allowing the management of a heterogeneous collection of documents. Moreover, it supports evolution by intrinsically enabling the extensions of any Profile.  
  
[[Image:Geo Portale(1).png|frame|center|GeoPortal Architecture]]
+
[[Image:DataCube model.png|frame|center|'''Profile''' and '''Profiled Document''']]
  
== Deployment ==
+
'''Profiled Documents''' are stored as :
 +
*'''Meta''': core section for publication management, containing:
 +
**Ownership
 +
**Identification
 +
**Versioning
 +
**Status
 +
***Phase
 +
***User-oriented messages
 +
*'''JSON''' Document metadata;
 +
*'''FileSets''' uploaded along with metadata;
 +
*'''Materialised Resources''' obtained by publishing FileSets, e.g.
 +
** GIS Layer
 +
** RDBMS Table
 +
** Indexing information (GIS centroids, Catalogues IDs ..)
  
=== Large Deployment ===
 
  
=== Small Deployment ===
+
'''Profiles''' define collections in a VRE, specifying :
 +
*Document '''structure'''
 +
**Fields (cardinality, type, constraint, defaults, indexing, GUI declaration)
 +
*Publication '''lifecycle handlers'''
 +
**Default values
 +
**Java model for specific business logic
 +
**Validators
 +
**Publishers
 +
*Handlers '''configuration'''
 +
 
  
 
== Use Cases ==
 
== Use Cases ==
 +
The '''gCube GeoPortal''' suite is designed to better serve publication management of complex data in Data e-infrastructures.
 +
Following examples are hypotetic situations in which the suite could be used in.
  
 
=== Well suited use cases===
 
=== Well suited use cases===
 +
The suite is designed to easily serve situations like :
 +
* Managing publication of simple and complex documents in multiple platforms
 +
* Allow communities to define / reuse / adopt :
 +
** Shared Document workflow
 +
** Shared Document structure
 +
** Shared Collections and Indexes
 +
** Shared Document Materialization praxis
  
 
=== Less well suited use cases===
 
=== Less well suited use cases===
 +
Although the suite could be used in the following situations, they remain outside of the scope of the application for the time being :
 +
* Intensive processing of datasets
 +
* Complex workflows
 +
 +
 +
=== Case Studies ===

Latest revision as of 19:17, 2 February 2021

GeoPortal is a feature-complete framework enabling the publication, access and management of GIS projects consisting of multiple documents, images, and datasets. It can be configured with the XML specification of the GIS project data model.

This document outlines the design rationale, key features, and high-level architecture, the options for their deployment and as well some use cases.

Key features

GeoPortal key features are :

Support for publication lifecycle
By supporting complex Data (Meta + Payloads) archives;
By enableing versioning, workflows, access policies;
By supporting several materialisations (GIS, Databases, ...)
By managing indexes (Meta catalogues, Index GIS layers)
Maximise reusability
By exploiting space-time GeoPortal Service
By allowing for configurable behaviour;
By supporting a generic meta-model;
By offering configurable GUIs (Management grid, Insert/Edit Form, Data Viewers);
External Data Integration
By exploiting OGC standards.

Design

Philosophy

Aim of the framework is to maximize adaptability by supporting custom model and behaviour definition.

Architecture

GeoPortal Architecture

The framework provides the following Dynamic GUIs, which use the Profile metadata definition to enable tailored:

  • Data Collection : Form assisting users to publish GIS projects;
  • GIS Viewer : allowing any user to visualise projects on a map;
  • Project Viewer : assisting users in accessing information, documents, images and datasets associated with the GIS project.

Dynamic GUIs rely on java client libraries to communicate to the GeoPortal Service, managing validation and management of GIS projects. The service relies on the D4Science Workspace to store and access attached documents and on the D4Science SDI to offer OGC Compliant Services (e.g. WMS, WFS, WCS, etc.). It also uses an internal archive of Profiled Document to manage publication lifecycle and for querying purposes.

Extensible Model

Dataset schemata are defined as Profile, and every managed collection of documents refer to a specific Profile. A complex geo-temporal dataset linked to a Profile is called Profiled Document. This approach allows for the definition of tailored Profiles allowing the management of a heterogeneous collection of documents. Moreover, it supports evolution by intrinsically enabling the extensions of any Profile.

Profile and Profiled Document

Profiled Documents are stored as :

  • Meta: core section for publication management, containing:
    • Ownership
    • Identification
    • Versioning
    • Status
      • Phase
      • User-oriented messages
  • JSON Document metadata;
  • FileSets uploaded along with metadata;
  • Materialised Resources obtained by publishing FileSets, e.g.
    • GIS Layer
    • RDBMS Table
    • Indexing information (GIS centroids, Catalogues IDs ..)


Profiles define collections in a VRE, specifying :

  • Document structure
    • Fields (cardinality, type, constraint, defaults, indexing, GUI declaration)
  • Publication lifecycle handlers
    • Default values
    • Java model for specific business logic
    • Validators
    • Publishers
  • Handlers configuration


Use Cases

The gCube GeoPortal suite is designed to better serve publication management of complex data in Data e-infrastructures. Following examples are hypotetic situations in which the suite could be used in.

Well suited use cases

The suite is designed to easily serve situations like :

  • Managing publication of simple and complex documents in multiple platforms
  • Allow communities to define / reuse / adopt :
    • Shared Document workflow
    • Shared Document structure
    • Shared Collections and Indexes
    • Shared Document Materialization praxis

Less well suited use cases

Although the suite could be used in the following situations, they remain outside of the scope of the application for the time being :

  • Intensive processing of datasets
  • Complex workflows


Case Studies