petascopedb to fully support SWE Quantities

[Piero Campalani]

New petascopedb schema follows the SWE data model (as by GMLCOV standard) to describe the Range Type of a coverage.

Currently many of the SWE metadata are supported in the schema, but not all.

This tickets collects all the fixes to the db schema that fill this lack. Due to the relative complexity of the ​SWE data model some decision needs to be taken now in order to select the required subset of SWE metadata we want to enable.

Indeed currently only Quantity components are supported, whereas petascope db has been design to be extended with further types in the future like Category or Count.
Additionally, GMLCOV imports only Data Records from SWE (no Vectors, or Choices, etc.).

Among the pending issues which are generally valid for any component, or either specifically valid for Quantity elements, we have:

• TO ADD/FIX (my personal opinion):
  • NiL values (swe:NilValuesPropertyType) to be established (value→description, e.g. "0→Below detection limit") (tech note: add it to ps9_range_type_component);
  • Data Quality (swe:QualityPropertyType): which however can be expressed in several ways, i.e. as number, range, category or free text (tech note: add it to ps9_range_type_component);
  • '@updatable' attribute (boolean): "Specifies if the value of a data component can be updated externally (i.e. is variable)" (tech note: add it to ps9_range_type_component).
  • '@identifier' attribute (anyUri): "Unique identifier of the data component. It can be used to globally identify a particular component of the dataset, a process input/output or a universal constant" (tech note: add it to ps9_range_type_component).
  • '@definition' attribute (anyUri): "Reference to semantic information defining the precise nature of the component" (tech note: move definition_uri from ps9_quantity to ps9_range_type_component).
  • @referenceFrame attribute (anyUri): "Frame of reference (usually temporal or spatial) with respect to which the value of the component is expressed. A reference frame anchors a value to a real world datum". This would be a CRS URI (tech note: import FK from ps9_crs to ps9_range_type_component). For an example see ​OGC 08-094r1, Sec. 8.1.7, last XML example).
  • '@axisID' attribute (string): "Specifies the reference axis (refer to gml:axisID). The reference frame URI should also be specified unless it is inherited from parent Vector" (tech note: add it to ps9_range_type_component).
  • '@name' attribute (NCName): already present in ps9_range_type_component, but a trigger should be added to ensure that the name is not colonized ([\i-[:]][\c-[:]]*).
  • 'significantFigures' should be moved from ps9_quantity to ps9_interval since they are part of swe:AllowedValuesType.
• TO IGNORE (my personal opinion):
  • '@optional' attribute (boolean): "Specifies that data for this component can be omitted in the datastream".
  • 'value' element in Quantity` components: GMLCOV uses SWE for data descriptors and not data containers ("Value is optional, to enable structure to act as a schema for values provided using other encodings").
  • '@id' attribute (​ID) for the AllowedValues defined in the optional constraint of a Quantity, which in in the substitution group of AbstractSWEType type. I just don't see it as necessary. The '@id' for the field or Quantity components can be replaced with the '@identifier' URI.

This ticket will be closed as fixed when all discussions have been resolved, petascopedb has been updated and Petascope is able to port all the information to a GML response.

A separate ticket might be opened for the implementation of utilities that help the user insert such metadata without personally entering the database (which in turn could be used by rasimport, see #169).

[Piero Campalani]

NIL values support as been enabled in #476.

I suggest to add referenceFrame attribute support: it can be quickly supported, it does not break compatibility with the existing db schema (add 1 attribute to ps_quantity) and is needed especially with elevation models where the values of the range are height which could be properly set in their reference CRS.

[Peter Baumann]

is referenceFrame a SWE Common attribute? If so, I'm definitely for it.
BTW, do we comprehensively support all that DataRecord in SWE Common defines? The ticket makes me feel that we don't yet, so something to be clarified.

[Piero Campalani]

It is better to group all SWE-related additions to a unique updateN.sql file imho.
We need to evaluate as well if we want to add information on the encoding of eg. a Multipart response by including an SWE DataArray inside the SWE DataRecord.

[Dimitar Misev]

Vlad, please reassess this ticket and close if it's obsolete.

[Peter Baumann]

my 2 cents: as long as we support the SWE DataRecord that is used in CIS I am all fine. No need to support anything beyond that.

[Bang Pham Huu]

Replying to pbaumann:

my 2 cents: as long as we support the SWE DataRecord that is used in CIS I am all fine. No need to support anything beyond that.

It changed to follow CIS data model for SWE element containing DataRecord.