Proposed OGC SensorThings API Version 2.0 - Multiple UltimateFeatureOfInterest case

[vuthanho]

In some situations a Datastream/Observation may be associated with multiple UltimateFeatureOfInterest instances.

For example, a single well can belong to several hydrological units. The proposed 2.0 specification currently allows only one UltimateFeatureOfInterest, which does not cover this case (which is covered in OMS).

[hylkevds]

Thank you for the suggestion. Use cases with multiple UltimateFoIs for a Datastream have not come up so far, so finding one is quite valuable.

Can you elaborate a bit more on the use case you are modeling? In the case of a well, can those different hydrological units be at the same depth?

[vuthanho]

I work for BRGM - France. We have a large network of wells where the water level, temperature, conductivity and quality is monitored. Knowing which hydrological units are actually monitored is crucial. There are some cases (7020 in total) where the well screen is in contact with several hydrological units.

Here is an exemple with the borehole BSS004LWEN:

In the borehole pdf report, the well screen (horizontal dashed column) is in contact with "Marnes et Caillasses du Lutétien" and "Calcaire gris - Calcaire grossier du Lutétien". Hence, the well is said to be belonging to two hydrological units, 113AO01 and 113AQ21, as it can be seen in the well sheet at "Rattachement du point d'eau au référentiel hydrogéologique BDLISA".

We can't group these two under a unit of lesser level either. See the corresponding hydrogeological log, the unit 113 is grouping them but is including units that are not concerned.

can those different hydrological units be at the same depth?

No they can't.

[hylkevds]

But if those hydrological units are not at the same depth, then how can an observation be on both of those at the same time? Since that is what it means to have multiple UltimateFeaturesOfInterest on one Datastream.
Can you give an example of such an Observation?

[vuthanho]

Sure, here are two examples:

• If the hydrogeological units are connected and not separated by an impermeable layer, the water level is representative of both units.
• When physico-chemical analyses are performed, you need to pump water from the well. If the hydrogeological units are connected, the sample you collect can be representative of both units, not just one.

[hylkevds]

Another potential use case for multiple Ultimate Features of Interest: A black-ice sensor measuring the status of a road surface at a crossing of two roads.

[sgrellet]

extra notes after a worksession with @vuthanho today

• the sample you collect can be representative of both units, not just one : clearly a field usecase. we have situation where the 'screen' (@fr 'crépine) is deployed in the well in a such a way that it overlaps to hydrogeologic unit. We cannot disambiguate the uFoI
• we also identified a side use case : EU Water Framework Directive (WFD) Water Bodies
  • the well monitores a real world entity (the hydrogeounit) but for EU WFD reporting purposes we also declare the corresponding WFD GroundWater Body (Management Unit) > extra UFoI

[KathiSchleidt]

Question - would one need a role to disambiguate between different UFoIs, or are they all considered equivalent?

[sgrellet]

Apart from providing info from the hydrogeo unit dataset like one is on top that one (if useful in that context), I don't see what else we can provide.

@vuthanho : any other idea ?

[hylkevds]

I would not add another role, that would make things really complicated.
The Ultimate part is already enough role, and the Features can be differentiated by their FeatureType and other attributes.

[vuthanho]

Another use case for multiple UltimateFeatureOfInterest is groundwater - surface water exchange, where the features are the hydrogeological unit and the surface water body. Scenarios involving multiple groundwater units and/or multiple surface water bodies are also possible.

[sgrellet]

For that extra Use Case, one idea discussed in the HydrDWG when I presented a BRGM project (CENARI-O), was to create an extra 'interface Feature' (that would embody the interface between Ground/Surface Water).

[hylkevds]

While adding an in-between feature would work, it would make discovery of the data harder, so we'll open up the Ultimate relationship between Datastream and Feature to many-to-many.

Such an extra interface-feature is still useful, as the proximateFeatureOfInterest, to indicate the exact location where the two (or more) UltimateFeaturesOfInterest are touching. In the groundwater case this proximate feature would be the well.