wmdr:observableRange

[joergklausen]

Schema extension needed to support vertical extent of observation. A code list has been proposed and is under development (wmo-im/wmds#185). Is this sufficient or is there also a need to specify vertical extent explicitly in terms of an altitude range? Should this be modeled as an attribute of the instrument or (more likely) the observation? What does OM_ provide?

[joergklausen]

As a work-around (or a community convention), vertical extent can be specified as follows (bold text in snippets):

Example: Wind profiler

XPath: /wmdr:WIGOSMetadataRecord/wmdr:facility/wmdr:ObservingFacility/wmdr:observation/wmdr:ObservingCapability/wmdr:observation/om:OM_Observation/om:type

Sample element: <om:type xlink:type="simple" xlink:href="http://codes.wmo.int/wmdr/Geometry/verticalProfile"/>

XPath: /wmdr:WIGOSMetadataRecord/wmdr:facility/wmdr:ObservingFacility/wmdr:observation/wmdr:ObservingCapability/wmdr:observation/om:OM_Observation/om:procedure/wmdr:Process/wmdr:deployment/wmdr:Deployment/wmdr:deployedEquipment/wmdr:Equipment/wmdr:observableRange

Sample element: wmdr:observableRange[{"vertical": {"lower": "100m", "upper": "4000m", "resolution": "50m"}}, {"temporal": {"resolution": "30s"}}, {"velocity": {"resolution": "0.2ms-1"}}]</wmdr:observableRange>

[joergklausen]

Cf. related issue at wmo-im/wmds#185

[ejwelton]

The proposed addition of a vertical extent of observation code list, traceable to OSCAR requirements, is required and valuable. However, it does not capture an instrument's explicit ranging capability (ie, 250m to 30000m) and vertical resolution. Therefore I feel we do need a standard approach to specify instrument range. The proposal above is fine, but I do not understand including temporal information in observableRange. I thought this information is described by temporalReportingInterval?

[joergklausen]

@ejwelton temporalReportingInterval specifies the reporting interval (how often data are effectively made available). It does not describe the capabilities of an instrument, which can be different. In fact, the message received every reporting interval could in principle contain several time stamps denoting aggregated values. That is why the standard also defines entities such as samplingTimePeriod, temporalSamplingInterval, aggregationPeriod and timeliness.

[joergklausen]

The Note for element wmdr:observableRange has been updated as follows. Comments for further improvements are most welcome!

5-03 Intrinsic capability of the measurement/observing method - range
Depending on the instrument, its configuration and the observedProperty, this element can be more or less complex. Content should be encoded as a JSON object. In all cases, this should contain an expression for 'measure' as follows:

{"measure": {"min": "\<value\>", "max": "\<value\>", "resolution": "\<value\>", "uom": "\<element from MeasurementUnitType codelist\>"}}
Example: Thermometer (observedProperty: temperature)
{"measure": {"min": "-30", "max": "70", "resolution": "0.1", "uom": "degC"}}

More complex instruments can specify other relevant elements, e.g., the vertical range or a temporal resolution.

Example: Windprofiler (observedProperty: horizontal wind speed)
{"measure": {"min": "0", "max": "40", "resolution": "1", "uom": "m.s-1"}, "verticalRange": {"min": "100", "max": "5000", "resolution": "50", "uom": "m"}, "temporalResolution": {"resolution": "60", "uom": "s"}}

Example: Weather radar (observedProperty: Intensity of Precipitation)
{"measure": {"min": "0", "max": "80", "resolution": "1", "uom": "mm.h-1"}, "angle": {"min": "-0.2", "max": "40", "resolution": "1.5", "uom": "deg"}, "temporalResolution": {"resolution": "300", "uom": "s"}, "power": {"peakPower": "400", "uom": "kW"}}

[joergklausen]

Looking at @ejwelton, @gaochen-larc, @tomkralidis, @amilan17, @RMaerz to provide comments. The issue has evolved from the original requirement to provide a way to specify vertical extent of the observation to now allowing the description of some intrinsic capabilities of instrumentation. Does the approach make sense? Are there better alternatives? Is it over-engineered, or just right?