Re: ssn resultQuality thoughts.

The way I look at it Observations can be Features too (located in time !)

so a chain of observations such as various data quality measures can have
additional metadata using the existing patterns - we should describe this.

the "simple" hasResultQuality  would rely on external metadata describing
its procedure etc - e.g. part of the (unspecified) procedure model, or
possibly the observedProperty model. or its range could be a complex
object.....

IMHO it will be chaos if we dont provide canonical patterns - any number of
complex result formats and no interoperability

rechartering will allow us to bottom this out with good examples,
entailment rules, API for navigation of canonical patterns (at least as
testing of the model with implementations - if not formally specified APIs)




Rob Atkinson
*Senior Research Engineer * | Open Geospatial Consortium (OGC)
Mobile: +61 419 202973
ratkinson@ogc.org | ogc.org | @opengeospatial



Sign up for OGC News
<https://ogc.us4.list-manage.com/subscribe?u=704e02f81107a6caab1568067&id=4e4528fd9d>


On Wed, Mar 27, 2024 at 6:28 AM Robert Warren <warren@glengarryag.com>
wrote:

> I'm writhing this to follow up to a few brief comments on last week's
> teleconference.
>
> One of the corner cases of Sosa is that some sensors return result quality
> / precision data along with the result. The sosa examples we have so far
> are focused on nominal or static measurement errors.
>
> In the case of GPS units and other "smart" sensor, the result is
> accompanied by performance data such as HVOP, Circular Error Probable or
> rms95. The GPS sensor reports point data as a result, but the actual
> location is within the area of an ellipse.
>
> Do we know what is supposed to go "into" resultQuality? A second set of
> observable properties?
>
> All my best,
> Rob Warren
>
>
>
>

-- 

Sign up for OGC News 
<https://ogc.us4.list-manage.com/subscribe?u=704e02f81107a6caab1568067&id=4e4528fd9d>