Quantity: constraint attribute in the OGC SWE Common Data Model (08-094r1)
|Status:||Submitted||Start date:||08 Sep 2014|
|Proposed change or action:|
The intended use of the Quantity: constraint attribute in the OGC SWE Common Data Model (08-094r1) is 'to specify a constraint on a decimal number (so only applicable to “Quantity”) is to limit the number of significant figures'. To help those unfamiliar with the mathematical concept, the OGC document goes on to give examples:
'Constraining a number to 5 significant figures means that a total of only 5 digits are or can be used for the representation of the value. The numbers 1.2345, 5.4823e-3, 0.98655 and 00235 are all composed of 5 significant figures, but 1.23450 and 658970 have six significant figures (leading zeros are ignored).'
The INSPIRE Elevation specification contradicts this, proposing to use it 'To state the number of significant digits after the decimal point (float values).'
This would make the INSPIRE data not compliant with the OGC standard, and potentially not usable by OGC compliant software (if any actually uses this value!).
The two need to be reconciled. If there is good evidence that the INSPIRE meaning is in common use, then INSPIRE should request that the OGC amends its specification. If not, then INSPIRE will need to find another way to express the 'number of significant digits after the decimal place'. It would seem a useful concept to encourage OGC to standardise the description.
#1 Updated by Peter Parslow almost 6 years ago
Note: this was raised in UK with subject 'INSPIRE Elevation specification, 18.104.22.168.4 Quantity: constraint attribute'. I think it is a theme specific issue/question, not a cross cutting one. The consolidated model does not go into detail of rangeType.
The OI spec does a different thing, suggesting that the constraint attribute of the record is used for 'the number of bits per sample'. OI gives an XML sample:
<swe:constraint> <swe:AllowedValues gml:id="VALUE_SPACE"> <swe:interval>0 255</swe:interval> </swe:AllowedValues> </swe:constraint>
On further reading, I think the issue is within the OGC document (08-094r1). At 6.2.6 it says of Constraints 'A numerical representation can be constrained by a list of allowed values and/or bounded or unbounded intervals. A decimal representation can also be constrained by the number of significant digits after the decimal point.' At 7.2.8 (Quantity class) it says 'it is possible to constrain the number of significant digits that can be added after the decimal point.' - the meaning used in INSPIRE Elevation. But at 7.2.18 when describing the AllowedValues class, OGC SWE is very clear:
'The number of significant digits can also be specified with the “significantFigures” property though it is only applicable when used with a decimal representation (i.e. within the “Quantity” class). This limits the total number of digits that can be included in the number represented whether a scientific notation is used or not.
All non-zero digits are considered significant. 123.45 has five significant figures: 1, 2, 3, 4 and 5
Zeros between two non-zero digits are significant. 101.12 has five significant figures: 1, 0, 1, 1 and 2
Leading zeros are not significant. 0.00052 has two significant figures: 5 and 2 and is equivalent to 5.2x10-4 and would be valid even if the number of significant figures is restricted to 2.
Trailing zeros are significant. 12.2300 has six significant figures: 1, 2, 2, 3, 0 and 0 and would thus be invalid if the number of significant figures is restricted to 4.'
This is the meaning used at 8.1.16 when describing the XML encoding AllowedValues element (a child of Constraint) it says 'The last option to specify a constraint on a decimal number (so only applicable to “Quantity”) is to limit the number of significant figures' (as quoted above).
The OGC document contradicts itself, and it seems that INSPIRE EL has followed the less likely definition.
1. report issue to OGC, suggesting they revise 6.2.6 and 7.2.8 to fall in line with mathematics, and their own 7.2.18 & 8.1.16. But also asking them to standardise an option for expressing 'number of digits after the decimal point' (as that seems widely used in elevation datasets).
2. consider the impact on INSPIRE EL. It would be easy to revise the text to fall in line with SWE, but as I understand it the more normal practice in an elevation data set is to specify the ranges to a fixed number of decimal digits - something that OGC SWE doesn't seem to allow for.