Proximate vs Ultimate FoI

[KathiSchleidt]

In OMS, we've differentiated FoI into proximate- and ultimateFeatureOfInterest. How do we implement this in STA?

Initial work has been done in the WQ IE, resulting in the following UML:
https://raw.githubusercontent.com/hylkevds/FROST-Server.Plugin.WaterQualityIE/temp/Datamodel-SensorThingsApi-WaterQualityIE.drawio.png

The approach taken here takes into account that proximate vs. ultimate FoI is not a modification the FoI class itself, its just the role this Feature takes for the Observation. Thus:

• FeatureOfInterest should be renamed Feature (of interest is just a role)
• Modify the FeatureOfInterest association from the Observation to FoI to ProximateFeatureOfInterest
• Add an UltimateFeatureOfInterest association from the Datastream to the FoI

[Sam-Bolling]

I am curious if this effort helps in resolving a limitation we ran into when implementing the SOS 2.0 specification. The most common military concept that matched "feature of interest" was/is "area of interest," but another concept was the "target of interest." Neither of these really synergized well with declaring the sensor ID as the feature of interest. So the profile practice of always using a sensor/monitoring station ID as the feature of interest didn't really work for us. However, we understood why communities would do this, because it offered a reasonably robust way to performed filtered queries to return lists of sensor IDs when the SOS 2.0 standard did not offer such an operation. Personally, I would advocate that an observation service should consider including operations focused on robust filtered queries and subscriptions that returned lists of sensor IDs (features that are sensors) but keep that concept separate from the feature of interest (features that are the focus of a sensor's observations) and maintain/improve the capabilities related to FoI discovery and access. Is there a conceptual conflict that precludes treating these as separate concepts altogether and building out the interface/API specifications to support them both well with use case -oriented operations?

[hylkevds]

The Ultimate / Proximate FoI distinction is hopefully addressed by the addition of an UltimateFeatureOfInterest link from Datastream:

This allows connecting a Datastream to a Feature. This means that, for all use cases where many Observations are made for a Feature over a longer period of time, the Observations for this Feature are no longer all in a big collection, but sorted per time series (Datastream).

In STA one can filter across the entire data model. So one can fetch all Sensors that have Observations on Features in a certain Area.

[humaidkidwai]

This means that, for all use cases where many Observations are made for a Feature over a longer period of time, the Observations for this Feature are no longer all in a big collection, but sorted per time series (Datastream).

In STA one can filter across the entire data model. So one can fetch all Sensors that have Observations on Features in a certain Area.

Why would you want to split the Observations for the same Feature into multiple Datastreams? Unless there is any updates (such as in the ObservedArea: Datastream or feature:Feature) that causes filtering parameters to change, how would it be effective?

[hylkevds]

For the same reason why we split the Observations for the same Thing into multiple Datastreams. Most Features have time series of Observations for may ObservedProperties, and currently those are all lumped together.

ObservedProperties for Feature 5044
SO2 Observations for Feature 5044

In the case where the Feature is a Sample this doesn't matter, since samples don't generally have time series attached to them. But for that we have the proximateFeatureOfInterest relation directly from the Observation.

[humaidkidwai]

Since we now link Feature to a Datastream and essentially create partitioned Datastreams on a per Feature basis, how relevant is observedArea::Datastream?

• If a Datastream groups observations over an area with only one Feature(ofInterest), the feature::Feature property should suffice.

• If a Datastream groups observations over a larger area with multiple Features(ofInterest), the link between Feature and Datastream breaks (0..1)

[hylkevds]

In the moving car measuring air quality example there is no ultimate FoI, only proximate PoIs, linked through the Observation. In that case the observedArea may still be useful even though it's importance has clearly decreased. Though, to be honest, I've never used the field. Unlike Datastream/phenomenonTime, I've used that for graphs.

[humaidkidwai]

The field is also useful for storage optimizations at the data layer on the server side (space-time partitioning?) and improves efficiency for queries filtering Datastreams over a certain region only.

Another use case could be when a user wants to create ObservedProperty partitioned Datastreams only and then they could only link ProximateFeatureOfInterest to the Observation.

Example: Methane monitoring over an upstream facility, where the methane leak for the overall site (observedArea) is more relevant than individual Features (wells, unloading spots, etc.) within the site.

[hylkevds]

I've made an object diagram for the sampling extension proposal, showing a river, a water sample from that river and an observation on that sample: