Page History

...

...

default                                       Flag to indicate the version is the default configuration (otherwise omitted).Image Removed

Image Added

Figure 33 Elements of the ValidationRuleSets configuration.

...

From 2014.02 on multiple rules of the same type within a single validationRuleSet can be given to apply to all locations within the timeSeriesSet instead of them to be location specific. Also from 2014.02 on multiple rateOfChangeFunctions, sameReadingFunctions and temporaryShiftFunctions can be used within the same validation rule set.

Validation on extreme values

This group of validation rules checks that the values in the time series do not exceed minimum and maximum limits. These limits may be defined as soft limits or as hard limits. Values exceeding soft limits will be marked as doubtful but retained. Values exceeding hard limits will be marked as unreliable. In case any of these rules are violated, a violation comment is added to the time step. If the time step already includes a comment, the violation comment is appended to the original comment. If no violation comment is provided, then the original comments would be added in the output only.

Figure 34 Elements of the Extreme values configuration of the ValidationRuleSets.

...

This group of validation rules checks that the values in the time series do not exceed maximum rates of change. When the rate of change limit is exceeded, the values causing the limit to be exceeded will be marked as unreliable. Rate of change limits may be defined to be the same for the rate of rise as for the rate of fall. These may also be defined to be different. The rates need to be specified in the unit of the timeseries it applies per second. E.g. if you define a rate of change for a water level gauge with values in metres the rate should be given in metres per second. Please note that this validationRule can only be succesfully applied to a value if there is a value at the time step before it as well. Especially when applying this rule to a temporary series that is merged (i.e. including the validation flags) to a permanent series this can lead to unwanted behaviour. The first value of the temporary series can't be validated with this rule, as there exists no value before it, even though there is in fact a value present in the destination series of the merge. 

If these rules are violated, and there exists an original comment for a given time step, no violation comment is added to the time step. However, if the time step does not include a comment, in the case of violating these rules, a violation comment is added to the time step.

Figure 35 Elements of the rate of change configuration of the ValidationRuleSets.

...

...

Validation on series of same readings

...

SameReadingViolations are marked as such if values stay within the sameReadingDeviation for at least the sameReadingPeriod. The way the check is applied is by having each value in the timeSeries be considered as potential start of a period in which the reading will be the same. In the case of a violation, a violation comment is added to the time step. If the time step already includes a comment, the violation comment is appended to the original comment. 

For each non missing value (start value) a check on the timeSeries is applied as follows. After the start value, each non missing value is compared to the start value to see if the absolute difference is no more than the sameReadingDeviation. If it's equal to or less than the sameReadingDeviation, the value is considered to be within the bandwidth and the check is continued. If not (or if it was the last non missing value of the timeSeries), the check is stopped. If the time between the start value and the last value inside the bandwidth is equal to or greater than the sameReadingPeriod, all non missing values from the start value up to (and including) the last value are marked sameReading (SR).

...

Element used when defining variable limits per calendar month. Twelve values must be defined. When defined the monthly limit will overrule the constant limit.

excludeMissingsFromSameReadingPeriod

Since 2020.01. If true a same reading period ends when a missing value is found. Default is false.

Validation on Temporary Shifts

Time series of data can be validated on temporary shifts. These occur when instruments are reset, and can be identified by the values rapidly falling to a constant value, remaining at that value for a short period of time and then returning to the original value range. A complex set of validation criteria include the rate of change as well as a maximum time the value remains the same. Please note that this validationRule can only be succesfully applied to a value if there is a value at the time step before it as well (or multiple). Especially when applying this rule to a temporary series that is merged (i.e. including the validation flags) to a permanent series this can lead to unwanted behaviour. The first value of the temporary series can't be validated with this rule, as there exists no value before it, even though there is in fact a value present in the destination series of the merge. 

In case of violating this rule, a violation comment is added to the time step. In that case, if a comment originally exists in the time step, it will be overridden by the violation comment.

Figure 37 Elements of the temporary shift configuration of the ValidationRuleSets.

...

The minimum amount of oscillations required for the values to be flagged as oscillating. For example if the following pattern is found: high, low, high, low, this would be considered to be 1,5 oscillations. 

validationFlag

Optional attribute to configure the validation flag that should be set for values in the oscillation period. When this validationFlag is not configured, only the oscillation flag source will be added to these values, and the flag will remain unchanged. Use this attribute when you want to set the flag of the values to doubtful or unreliable.

Example:

In the picture below 4.5 oscillations with a high vs low value difference of at least 0.3 and an oscillation period (2 subsequent high's or lows) of maximum 1800 seconds are illustrated.

Image Added

<validationRuleSet validationRuleSetId="OscillationSimpleTest" timeZone="GMT">
   <oscillation validationFlag="doubtful">
      <minDifference constantLimit="0.3"/>
      <maxPeriod constantLimit="1800"/> <!-- 30 minutes -->
      <minOscillations constantLimit="2.5"/>
   </oscillation>
   <timeSeriesSet>
      ...
   </timeSeriesSet>
</validationRuleSet>

<validationRuleSet validationRuleSetId="OscillationAttributes" timeZone="GMT">
   <oscillationFunctions validationFlag="doubtful">
      <minDifference constantLimit="@MIN_DIFF@"/>
      <maxPeriod constantLimit="@MAX_PERIOD@"/> 
      <minOscillations constantLimit="@MIN_OSC@"/>
   </oscillationFunctions>
   <timeSeriesSet>
      ...
   </timeSeriesSet>
</validationRuleSet>

flagSources

Since version 2012.01 FEWS stores not only the quality flags, but also the source of the flag, the so-called flagSource. So the user is able to see why a certain value is validated as unreliable, eg. due to exceeding of the hard max.
The list of flagSources is:

• IMP: flag is imported
• SN: soft min.
• HN: hard min.
• SX: soft max.
• HX: hard max.
• ROR: rate of rise
• ROF: rate of fall
• SR: same reading
• TS: temporary shift
• OSC: oscillation
• SC: secundairy secondary validation, series comparison
• FC: secundairy secondary validation, flag comparison
• KT: secundairy secondary validation, Mann-Kendall test
• MAN: manual edit

Example for "Rate of Rise" and "Temporary Shift" validation rules

Use of <timeSeries> instead of <timeSeriesSets>

Since 2023.02 it is possible to use the <timeSeries> element instead of the <timeSeriesSets> elements.

The <timeSeries> element works like a more general filter on all time series instead of the more explicitly defined <timeSeriesSet> element.

When there is no element defined for a time series key, there will be no filtering which means everything matches.

The most useful part of the <timeSeries> is the fact that multiple parameters can be defined instead of just the single one in a <timeSeriesSet>.

This can be done by defining multiple single parameters or even 1 or more parameter groups:

	<validationRuleSet validationRuleSetId="SetWithTimeSeriesFilter" timeZone="GMT">
		<extremeValues>
			<hardMax constantLimit="20"/>
			<hardMin constantLimit="0"/>
			<softMax constantLimit="10"/>
			<softMin constantLimit="2"/>
		</extremeValues>
		<timeSeries>
			<moduleInstanceId>moduleA</moduleInstanceId>
			<valueType>scalar</valueType>
			<parameterGroupId>ParGroupA</parameterGroupId>
			<parameterId>Par1</parameterId>
			<parameterId>Par2</parameterId>
			<locationSetId>locationSetA</locationSetId>
			<timeSeriesType>external historical</timeSeriesType>
			<timeStep unit="hour"/>
		</timeSeries>
	</validationRuleSet>

Examples of validation rules

Example for "Rate of Rise" and "Temporary Shift" validation rules

Changing validation 

When validation rules have changed after data has been already validated, it is possible to revalidate all time series connected to all validation rules via the revalidation module which is available from version 2023.02.

When data in the past has been changed with validation rules like Same Reading, Temporary Shift or Oscillation connected to it, it is also advised to run this module.

This is because these validation rules work with a validation period which may not be enclosed entirely in the rewritten period. This could cause changes in validation. 

If for example 100 identical subsequent values have been flagged as Same Reading, but then afterwards only the first 10 will be rewritten by a workflow with a relative view period in the past, those 10 values may not be flagged as Same Reading anymore because the values afterwards are not taken into account. The revalidation module, however, always revalidates the whole time series, and can be run for specific locations via the manual forecast dialog.