...
What | Required | Description | schema location |
|---|---|---|---|
ValidationRulesets.xml | no | Definition of validation rule sets | httphttps://fewsfewsdocs.wldelftdeltares.nl/schemas/version1.0/validationRuleSets.xsd |
| Table of Contents | ||
|---|---|---|
|
...
default Flag to indicate the version is the default configuration (otherwise omitted).
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
...
| Info | ||
|---|---|---|
| ||
For information on RateofChangeTimespan, see this wiki page (needs to be integrated in this page) |
...
Validation on series of same readings
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
<validationRuleSet validationRuleSetId="OscillationAttributes" timeZone="GMT">
<oscillationFunctions validationFlag="doubtful">
<minDifference constantLimit="@MIN_DIFF@"/>
<maxPeriod constantLimit="@MAX_PERIOD@"/> <!-- 3 days -->
<minOscillations constantLimit="@MIN_OSC@"/>
</oscillationFunctions>
<timeSeriesSet>
...
</timeSeriesSet>
</validationRuleSet> |
...
Example for "Rate of Rise" and "Temporary Shift" validation rules
Examples of 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:
| Code Block | ||||
|---|---|---|---|---|
| ||||
<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. Example for "Rate of Rise" and "Temporary Shift" validation rules