# Model: Conceptual, Logical, XML Issue Date Submitter
1 Logical, XML Using Constituent as Feature-of-Interest 11-08-2015 B. Brodaric
2 Logical, XML Linkage between GWML2 and TimeSeriesML 11-08-2015 B. Simons
3 XML Change documentation to state that we used GML 3.3 12-02-2015 E. Boisvert

1. Using Constituent as Feature-of-Interest

Discussion:

OM_Observation featureOfInterest can be the samplingFeature (GW_Well) or the sampledFeature (GW_Aquifer). For some observed properties (e.g. pH) the former doesn’t make sense, so need to be able to distinguish the two. The featureOfInterest for the observations was mapped to the GW_Well (i.e. the samplingFeature), but it should be the ultimate featureOfInterest (e.g. the GW_FluidBody.

The Observations & Measurements specification proposes two patterns for featureOfInterest:

(1) the feature of interest can either refer to the real world object that is being observed, or

(2) to a sampling feature (SF_SamplingFeature) that acts as a proxy for the real world feature (which is then accessible through the sampling feature’s sampledFeature property).

Because the property featureOfInterest has cardinaliy 1..1, a data provider must choose one of these approaches. Problems occur when a sampling feature is chosen: while many observations can refer to the same domain feature, it is impossible to navigate back to the sampling feature. Solutions have been proposed using OM_Process to document the relationship between the observation and the sampling feature, but they are cumbersome and require much encoding. Consequently, the JSON (OGC 15-100) and RDF encodings for O&M include an extra samplingRegime property that is absent from the GML encoding. In GWML2, there is no restriction on featureOfInterest—it can refer to a real world feature or a sampling feature.

Solution:

Put in change request to OGC to modify O&M conceptual model and OMXML to have ultimate featureOfInterest (0..n) and samplingStrategy (0..n) for intermediate sampling features.

2. Linkage between GWML2 and TimeSeriesML

Discussion:

For GW_Flow, gwFlowVolumeRate is OM_Measurement: that constrains the result to be a gml:Measurement , so a single value with a uom but these may be ranges.

Additionally, the use of OM_Measurement precludes using TimeSeries as a result (uses a specialisation of OM_Observation). The GWML2IE did not investigate whether there were any properties that have data type OM_Measurement that could be a time series.

Solution:

Investigate whether there are any properties that require data type to be OM_Observation.

-- BruceSimons - 08 Oct 2015

-- BoyanBrodaric - 12 Aug 2015

3. GML 3.3 encoding

The encoding rule we used (we might want to check if it's all true) is actually GML 3.3 - specially the CodeType -> gml:ReferenceType. I always thought it was a INSPIRE thing, it's not. We must change the documentation and state that we used GML 3.3 (GML 3.3 is not a new schema, it's actually an extension of 3.2 + encoding patterns)

-- EricBoisvert - 02 Nov 2015

4. GeoSciML 4

  • Pro
    • All optional properties - consistent with GWML2.0
    • On OGC standardization process
  • Con
    • schema will change
    • instance will change
    • service will change

This topic: HydrologyDWG > WebHome > GroundwaterInteroperabilityExperiment2 > GW2IE_KnownIssues
Topic revision: 02 Dec 2015, EricBoisvert
This site is powered by FoswikiThe information you supply is used for OGC purposes only. We will never pass your contact details to any third party without your prior consent.
If you enter content here you are agreeing to the OGC privacy policy.

Copyright &© by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding OGC Public Wiki? Send feedback