...

To make it possible to reproduce the time series generated in the past it is necessary that FEWS still has knowledge about how the location configuration was in the past.

The chapter will describe how it is possible to configure time dependent locations. It is also very important to note that only the functionality which is described in this chapter can be considered time dependent. 

Configuration of time dependent locations

...

A set of time dependent locations can be configured in the LocationSets.xml file. Below is an example file.

<locationSet id="example">
	  <csvFile>
	<file>myLocationFile</file>
	<geoDatum>Rijks Driehoekstelsel</geoDatum>
	<id>%ID%</id>
	<name>%NAME%</name>
	<startDateTime>%START%<
    <dateTimePattern>yyyy-MM-dd HH:mm:ss</dateTimePattern>
    <startDateTime>%START%</startDateTime>
	<endDateTime>%EIND%</endDateTime>
	<x>%X%</x>
	<y>%Y%</y>
	<relation id="relation">
		<relatedLocationId>%REL%</relatedLocationId>
	</relation>
	<attribute id="PARAMETERS">
		<text>%PARAMETERS%</text>
	</attribute>
	<attributeFile>
		<csvFile>attribute.csv</csvFile>
		<id>%ID%</id>
		<timeZoneOffset>+00:00</timeZoneOffset>
 		<attribute id="Q"><dateTimePattern>yyyy-MM-dd HH:mm:ss</dateTimePattern>
		<number>%Q%</number>
<startDateTime>%START%</startDateTime>
		<endDateTime>%EIND%</endDateTime>
		<attribute id="Q">
			<number>%Q%</number>
		</attribute>
	</attributeFile>
	  </csvFile>
</locationSet>

...

The tags startDateTime and endDateTime relate to the columns in the file mapLayersFiles/myLocationFile.csv.  This csv file defines which locations are in the locationSet example. 

Besides defining the locations in a csv file it is also possible to define the locations in a dbf file.

...

The tag endDateTime refers to the column EIND. Together the startDateTime and  endDateTime define for which period this location is valid.

The tag relation with id "relation" defines a related location. The value is stored in the column REL. The value should be the location id of the related location. 

...

To configure this the following csv (or dbf) file should be used: 

...

First a row should exists in the csv (or dbf) file of this locationset with the value A in the column ID and the column which defines the relation (REL) should have the id

...

The element csv file contain an element startDateTime and endDateTime which define the columns which contain the start and endtime of a single row of attribute definitions. 

The configuration of the start time and end time of a location and its attributes must be configured according to the following rules:

• The period in which the location exists in FEWS (visibilty period) is derived from the main configuration file in the locationSet configuration
• The periods defined in the attributes file should be consistent with the visibility period defined for the location. If all the periods defined in the attributefile for a certain location were combined they should span the exact period if all the periods defined in the main configuration file were combined to a period. If this is not the case an configuration error will be thrown during the startup of FEWS and the behaviour of the system with regard to time dependent locations is undefined.

...

Grid display

The grid display supports the usage of time dependent locations and polygons. The time displayed in the grid display can be varied by using the time slider at the top of the display. In a FEWS system were locations are not time

...

		<locationHistoryBarRelativePeriod unit="week" start="-100" end="100"/>

...

The screenshot below shows the slider button which appears when the locationHistoryBarRelativePeriod is configured in the explorer.xml

...

Note: the usage of time dependent location relations and time dependent location set constraints is not supported in the transformation module before 2020.01 because this requires to switch the location itself during the transformation. This will be supported from 2020.01 onwards. There will be a warning for transformations This is not supported for all transformations. Transformations that do not support this , this will mainly be transformations that have when multiple time steps are necessary for the calculation in their input and / or output (like aggregation and accumulation), . This is because the individual transformation can not handle a change in within their input or output period.  Exceptions to this rule have been made after analysis of their functionality:

• <interpolationSerial><default>
• <merge><simple>
• <sample><equidistant>

Secondary validation

The secondary validation module also takes into account the time dependency of the locations. The secondary validation will only run if all of the used locations are valid, the values of location attributes used in the

...

		<seriesComparisonCheck id="timeDependentSeriesComparisonCheck">
			<expression>output - A1 >@A@</expression>
			<validatingVariableId>output</validatingVariableId>
			<outputFlag>unreliable</outputFlag>
			<logLevel>DEBUG</logLevel>
			<logEventCode>SecondaryValidation.locationSeriesComparisonCheckUnreliable</logEventCode>
			<logMessage>%AMOUNT_CHANGED_FLAGS% flags set to %OUTPUT_FLAG% by [%CHECK_ID%, %EXPRESSION%].</logMessage>
		</seriesComparisonCheck>

However it is important to explain how the time dependency of locations influences resolving location attributes.

...

Using the input is not very logical and in addition it would still not be clear which location to use in the case that the input consists of time series with more than one location. 

What should be done in the case that more than one validating variable is configured? In that case the validation is being done for one validating variable at the time.

...

In that case the location of variable A will be used to determine the value of the location attributes. After that, the secondary validation will run for validating variable B which will mean that the location of this variable will be used.

Time dependent location relations and time dependent location set constraints. (since 2022.01)

Since 2022.01 the Secondary Validation module has improved for handling time dependent location relations and location sets based on time dependent constraints.

The special thing about these time dependencies are that at different times a time series set contains different time series. This goes even further than location with start and or end time because here locations can still exist but actually at one point in time be part of a time series set and at another time not anymore.

For location sets based on a time dependent constraint and time dependent location relations it is needed to split the run period over all time dependent changes within that period and resolve all time series for each sub period individually.

Before 2022.01 the time series are only resolved for T0, this causes some validations to be executed for parts of time series that are actually not part of the time series set at a certain time, or parts of a time series not being validated while it is actually part of a time series set.

Chainage Chainage Location Sets (since 2020.02)

Since 2020.02 it is possible to use time dependent chainage attributes to determine a longitudinal profile based on a chainage attribute.

The longitudinal profile will be visualized with all chainage locations that are part of the profile at any time in the period of the time slider.

When at a specific moment in time a location is not part of the profile a missing value will be shown in the table, but the graph will just connect the line to the next location that is part of the profile.

The