Page History

...

With these rules it is possible to define for example that the output of the transformation is reliable if less than 10% of the input is unreliable and/or missing and that if this percentage above 10% that in that case the output will be unreliableshould be a missing value.

It is important to note that input values which are missing and input values which are marked as unreliable are treated the same. Both are seen as missing values by the validation rules.

This prevents that a single missing value in the input will lead to a missing value in the aggregated output value.

...

				<validationRule>
					<inputMissingPercentage>10</inputMissingPercentage>
					<outputValueFlag>reliable</outputValueFlag>
				</validationRule>
				<validationRule>
					<inputMissingPercentage>100</inputMissingPercentage>
					<outputValueFlag>missing</outputValueFlag>
				</validationRule>

The configured validation rules are applied in the following way. The first validation rules is applied first. In the example above the first rule is that if 10% or less of the input is missing (or unreliable) that the output flag will be set the reliable. If the input doesn't meet the criteria for the first rule the transformation module will try to apply the second rule. In this case the second rule will always apply because a percentage 100% is configured.

This is a recommended way of configuring the validation rules. By default if validation rules are configured and none of the configured rules are valid the output will be set to missing. But for the users of the system it is more understandable if the behaviour of the aggregation is configured instead of a hard-coded fallback mechanism in the software.

To explain the validation rules a bit more a more difficult example will explained. Let's say that we would like configure our aggregation in such a way that the following rules are applied:

1 if the percentage of missing and/or unreliable values is less than 15% the output should be reliable.
2 if the percentage of missing values is less than 40% the output should be doubtfull.
3 in all other cases the output should be a missing value.

Below shows a configuration example if the rules above were implemented.

				<validationRule>
					<inputMissingPercentage>15</inputMissingPercentage>
					<outputValueFlag>reliable</outputValueFlag>
				</validationRule>
				<validationRule>
					<inputMissingPercentage>40</inputMissingPercentage>
					<outputValueFlag>doubtful</outputValueFlag>
				</validationRule>
				<validationRule>
					<inputMissingPercentage>100</inputMissingPercentage>
					<outputValueFlag>missing</outputValueFlag>
				</validationRule>

In some cases in it one would like to differ between situations in which for example the output was marked as reliable. In the example above if all of the input values were reliable the output is marked reliable. But if for example 10% of the input values were unreliable the output is also marked as reliable.

It would be nice if the user of the system would be able to see in the GUI of FEWS why the input was marked reliable.

To make this possible the concept of the custom flag source is added the validation rules. In addition to configuring an output flag it is also possible to configure a custom flag source. In the table of the Timeseriesdialog the custom flag source can be visible by

Below an example in which wThe concept of the validation rules will be explained below by an example.

Configuration example

	<transformation id="aggregation accumulative">
		<aggregation>
			<accumulative>
				<inputVariable>
					<timeSeriesSet>
						<moduleInstanceId>ImportTelemetry</moduleInstanceId>
						<valueType>scalar</valueType>
						<parameterId>H.obs</parameterId>
						<locationSetId>hydgauges</locationSetId>
						<timeSeriesType>external historical</timeSeriesType>
						<timeStep unit="minute" multiplier="15"/>
						<relativeViewPeriod unit="day" startOverrulable="true" start="-7" end="0"/>
						<readWriteMode>read only</readWriteMode>
						<delay unit="minute" multiplier="0"/>
					</timeSeriesSet>
				</inputVariable>
				<outputVariable>
					<timeSeriesSet>
						<moduleInstanceId>Aggregate_Historic</moduleInstanceId>
						<valueType>scalar</valueType>
						<parameterId>accumulative</parameterId>
						<locationSetId>hydgauges</locationSetId>
						<timeSeriesType>external historical</timeSeriesType>
						<timeStep unit="hour" multiplier="1"/>
						<relativeViewPeriod unit="day" startOverrulable="true" start="-7" end="0"/>
						<readWriteMode>add originals</readWriteMode>
						<synchLevel>1</synchLevel>
					</timeSeriesSet>
				</outputVariable>
			</accumulative>
		</aggregation>
	</transformation>