Count Class Requirements Class: Basic Types and Simple Components Packages Requirements Class

OGC 08-094r1 SWE Common Data Model The “constraint” attribute can be used to restrict the range of possible values to a list of inclusive intervals andor single values using the “AllowedValues” class defined in clause 7.2.18. Numbers used to define these constraints should be integers and expressed in the same scale as the count value itself. The “significantFigures” constraint allowed by the “AllowedValues” class is not applicable to the “Count” class. The “value” attribute or the corresponding value in out-of-band data is an integer that must be within one of the constraint intervals or exactly one of the enumerated values.

7.2.8 Quantity Class

The “Quantity” class is used to specify a component with a continuous numerical representation as defined in clause 6.2.3. It derives from “AbstractSimpleComponent” and is shown below: AbstractSimpleComponent «Type» Quantity «property» + uom: UnitOfMeasure + constraint: AllowedValues [0..1] + value: Real [0..1] Figure 7.12 – Quantity Class In addition to attributes inherited from the “AbstractSimpleComponent” class, this class provides a unit of measure declaration through the “uom” attribute. This unit is essential for the correct interpretation of data represented as decimal numbers and is thus mandatory. Quantities with no physical unit still have a scale such as unity, percent, per thousands, etc. that must be specified with this property. The “constraint” attribute is used to restrict the range of possible values to a list of inclusive intervals andor single values using the “AllowedValues” class defined in clause 7.2.18. Numbers used to define these constraints must be expressed in the same unit as the quantity value itself. Additionally, it is possible to constrain the number of significant digits that can be added after the decimal point. The “value” attribute or the corresponding value in out-of-band data is a real value that is within one of the constraint intervals or exactly one of the enumerated values, and most importantly is expressed in the unit specified. 32 Copyright © 2011 Open Geospatial Consortium SWE Common Data Model OGC 08-094r1

7.2.9 Time Class

The “Time” class is used to specify a component with a date-time representation and whose value is projected along the axis of a temporal reference frame. This class is also necessary to specify that a time value is expressed in a calendar system. This class derives from “AbstractSimpleComponent” and is shown below: AbstractSimpleComponent «Type» Time «property» + referenceTime: DateTime [0..1] + localFrame: TM_TemporalCRS [0..1] + uom: UomTime + constraint: AllowedTimes [0..1] + value: TM_Position [0..1] Figure 7.13 – Time Class Time is treated as a special type of continuous numerical quantity that can be either expressed as a scalar number with a temporal unit or a calendar date with or without a time of day. Consequently, this class has all properties of the “Quantity” class, plus some others that are specific to the treatment of time. As time is always expressed relative to a particular reference frame, the “referenceFrame” attribute inherited from the parent class “AbstractSimpleComponent” shall always be set on instances on this class unless the default ‘UTC’ is meant. Requirement http:www.opengis.netspecSWE2.0requml-simple-componentstime-ref-frame-defined Req 27. The “referenceFrame” attribute inherited from “AbstractSimple Component” shall always be set on instance of the “Time” class unless the UTC temporal reference system is used. Note that specifying the frame of reference is required even when using ISO notation because there can be ambiguities between several universal time references such as UTC, TAI, GPS, UT1, etc… Differences between these different time reference systems are indeed in the order of a few seconds and increasing, that is to say not negligible in various situations. Example J2000 is a well known epoch in astronomy and is equal to: - January 1, 2000, 11:59:27.816 in the TAI time reference system - January 1, 2000, 11:58:55.816 in the UTC time reference system - January 1, 2000, 11:59:08.816 in the GPS time reference system These offsets are not always constant and depend on the irregular insertion of leap seconds in UTC Copyright © 2011 Open Geospatial Consortium 33