INSPIRE Community Forum

Which is the meaning of the value of the swe:significantFigures element ?

Looking at the GMLCOV example in the TG for elevation (see corrigendum), can someone explain which is the meaning of the value of the swe:significantFigures element ?

<swe:AllowedValues>

<swe:interval>-100 3143</swe:interval>

<swe:significantFigures>5</swe:significantFigures>

</swe:AllowedValues>

In the example above the swe:interval is quite clear: -100 is the minimum value within the grid and 3143 is the maximum value in the grid. What about swe:significantFigures ?

INSPIRE Thematic Cluster Elevation, Orthoimagery, Reference systems, Geographical grids - Join this group to share your knowkledge, learn and collaborate in solving issues related to the Elevation, Orthoimagery, Reference systems and Geographical grids themes

Is this the number of digits ?

Is it the number of digits after the decimal point (178.12345) or is the number of digits for numerical representations (1789.2 has five significant figures) ?

I'll work through my reasoning, to help others find the answer to this kind of question.

The XML examples in INSPIRE Data Specifications are sometimes GML fragments. At least some in EL are full XML documents, so the namespaces & schema imports are there. You'vecorrectly guessed that 'swe' is imported as part of 'gmlcov'. Following the link for gmlcov (in the xsi:schemaLocation), and then following the "include" statement there, and then the "import", gets you to the machine readable definition of 'swe' at http://schemas.opengis.net/sweCommon/2.0/swe.xsd.

That "includes" four files, and XML includes don't change the namespace, so I had to try them one by one. http://schemas.opengis.net/sweCommon/2.0/simple_components.xsd simply tells you it has to be an integer. Dead end!

But at least swe.xsd has documentation mentioning the OGC standard "SWE Common Data Model 2.0 specification". Googling that takes me to http://www.opengeospatial.org/standards/swecommon, where the standard is available free as a PDF. Searching within that (now human readable), I find:

"The number of significant digits can also be specified with the “significantFigures” property though it is only applicable when used with a decimal representation"

Now "significant digits" is a mathematical term; the OGC standard goes on to give examples that indicate what it means. It is, basically, "the number of digits", ignoring leading zeros (but not trailing zeros!). So the second of lurie MAXIM's suggestions. As you can see in many maths sources, from school text books to wikipedia.

Thank you for the documented answer.

So the OGC SWE Common Data Model states at page 55 where the AllowedValues class is described

<<

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.ExamplesAll non-zero digits are considered significant. 123.45 has five significant figures: 1, 2, 3, 4 and 5Zeros between two non-zero digits are significant. 101.12 has five significant figures: 1, 0, 1, 1 and 2Leading 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.Note: The number of significant figures and/or an interval constraint (i.e. min/max values) can help a software implementation choosing the best data type to use (i.e. ‘float’ or ‘double’, ‘short’, ‘int’ or ‘long’) to store values associated to a given data component.>>At page 187 is mentioned as a test "

A float cannot be used for a number of significant figures greater than 7"Therefore the significantFigures is used to determine the data type to store the numbers:

Float - 7 digits (32 bit)

Double-15-16 digits (64 bit)

Decimal -28-29 significant digits (128 bit)

1/3 equals

float: 0.3333333

double: 0.333333333333333

decimal: 0.3333333333333333333333333333

Than there is a mistake in the TG for Elevation where at page 52 in the pdf (page 41 printed in the document) is written for the rangeType property "Quantity::constraint attribute (optional) To state the number of

significant digits after the decimal point(float values)." ?Is my understanding correct that the optional "Quantity: constraint" attribute mentioned in the EL DS is encoded by using significant figures as in the example provided in the guideline (page 126 in pdf) ?

<rangeType>

....

</swe:Quantity>

<swe:constraint>

<swe:AllowedValues>

<swe:interval>0 255</swe:interval>

<swe:significantFigures>3</swe:significantFigures>

</swe:AllowedValues>

</swe:constraint>

</swe:Quantity>

....

</rangeType>

In the above example 0 255 interval is for a Panchromatic image, so most probably there are only integer numbers from 0 to 255 and no decimals. As the significantFigures property

"is only applicable when used with a decimal representation"I suppose that in the example above the <swe:significantFigures>3</swe:significantFigures> should be erased if there are only integer numbers. A software would know if it is a short, int or long, based on the values provided in the <swe:interval> element. Is this correct ?â€‹float number above for elevations at millimeter precision and short number below for grids with integer elevation values (updated 25/6/2018 Not clear if this correct or not !):

Let me add two facets:

- number of digits is measured in the _decimal_system; obviously, in a binary representtion there would be more significant bits. (This is also a reason why we feel uneasy because "3 digits" does not exactly capture a maximum value of 255 - saying "8 binary digits" would be more exact, but that's not what we want in reality.)

- Only (inverse) powers of 2 can be represented exactly as floating points, so 0.5, 0.25, 0.125, etc. _Everything_ else is rounded, and that means: inexact. For example, 0.3333333 should be read as 0.33333330 - hence, it is not entirely correct to say " 1/3 is 0.3333333" as done above. This has several serious consequences:

- range set: don't use null values with floating point pixels - a tiny numerical distortion might change the value just at the last digit, and it will not be recognized any longer. "Null" actually is a categorial value. As in one of our projects oceanographers insisted in doing that we had to teach our software interval arithmetics (ie, every "==NULL" transforms now into "close to NULL within the range of this machine's accuracy").

- domain set: be extremely cautious with fractional resolutions. Say you have an extent of 2/3 degrees = 0.6666667. 6 pixels will select 6*0.6666667 = 4.0000002, which is not 6*2/3 = 4.0. Now think about a large image where the fraction amounts to more than half a pixel. Your software might cut out one more pixel - and in other situations one less - than expected so that the image delivered does not match. We have seen plenty such cases.

Bottom line, numerical math is a beast.

-Peter

PS: As to "before or after decimal point": normally scientific notation is assumed in floats, so 2535.120 would be written normalized as 0.2535120*e4, which illustrates the (correct) 7 shown above.

Thank you for pointing the cases with NULL values with floating point and that with fractional resolutions. They are very valuable recommendations.

Returning now to INSPIRE Elevation Data Theme, for a terrestrial DTM that has the values of the grid cells expressed with positive numbers with three decimals (millimeter precision), the correct encoding would be this one ?

significant digits after the decimal point(float values)." ?From your last PS I can understand that the sintagm in the TG "Quantity::constraint attribute (optional) To state the number of

significant digits after the decimal point(float values)." could refer to the representation of 2535.120 as 0.2535120*e4 and therefore the number of digits are 7.I am curios how many people can understand this from the TG ?

First of all the the word "normalised" is not found in the TG.

Second, the normalised representation of 2535.120 is 2.535120e3 (6 digits after the decimal point) and not 0.2535120*e4 (seven digits after the decimal point). We are writing 1.0 × 10-8 and not 0.1 × 10-7. https://en.wikipedia.org/wiki/Normalized_numberâ€‹ A number is

normalizedwhen it is written in scientific notation with onenon-zerodecimal digit before the decimal point.Iurie

For Elevation data theme the number of signiticant figures are correct the following ?

for elevation expressed in meters with milimeter precision (with three decimals):

and for values expressed in meters (integer numbers)

Re normalization, you are right, Iurie: there are two definitions around (x.xxx and 0.xxx), my numerics instructor back last millennium liked to use the 0.x notation. So INSPIRE might indeed give a brief definition of the format they want to use, just to avoid any doubt.

With your example of 4 significant digits I agree in full; with your example of 7 my instinct warns me about the trailing 0: is that meant to be exact, or just some "don't care" figure to fill up some aligned column format in Excel? After all, the guy wrote "0.000" and not "0.0" without any particularly visible reason. So precision might be meant to be 6, and only documentation can tell (if there is one, hopefully). Otherwise, you'd be right with 7.

-Peter

Never heard about 0.xxx normalisation, but in any case in the TG the definition must be changed in order to be clear.

Related the trailing zero, I specified that the values are in millimeters expressed in the uom meter as we are speaking about elevation. The minimum value in the grid is 0.000 and not 0. The maximum value in the grid is 2535.120, other values in the grid are 1.234, 12.345, 123.456 and 1234.567.

So this means that not only the definition in the TG is missleading, but the example in the links of the corrigendum are wrong as well

If the example with 4 significant digits is correct, than the definition in the OCG SWE Data Model is not misleading as it does not points to integer numbers as well ?