day for the validity of the location attributesdbServerType
_Functionality to define locations and to generate locationSets from a CSV file /Shape-DBF file / DB Table
Where to Use?
Locations, LocationSets, IdMaps, DisplayGroups, ThresholdValueSets and ValidationRuleSets
Why to Use?
To have only one file or a set of files where all region specific information is stored.
Based on the CSV, DBF-Shape file or DB table you can easily manage the configuration
To be able to have only one file that manages all the regional information, Delft-FEWS offers the functionality to use a CSV, DBF or shape files that can be linked to the configuration. Locations and locationSets can be automatically generated and useful information as idMaps, thresholdvalues or validation values can be derived from these tables. It is also possible to link to one or more CSV/DBF files that contain time-dependent attributes. This can be used to define time-dependent coefficients that can be used by the new transformation module.
Finally you have a configuration that has many links to the CSV / DBF / shape files, but that will be managed only in these files. The advantage is that these files can simply be updated by automatic updating processes.
The functionality is based on the next principal:
- you generate locations in a locationSet and define attributes to these locations that store additional information like idMapping or validation limits.
- locationSets can be generated from the CSV, SHP/DBF, db table or from another locationSet by using conditions.
- idMaps can be linked to the location text attributes.
- all values in validationRuleSets can be linked to location number attributes
- all threshold values can be linked to location number attributes
- displayGroups can be generated automatically from locationSets
- it works both for regular point locations as for grids
- values in coefficientSetFunctions in a transformation config file can be linked to location number attributes
CSV file format
When the CSV file is not using the character set "Western Europe (ISO-8859-1)" the character set should be configured
DBF file format
This functionality only works for DBF files in the dBASE III format. When the Dbase file is not using the character set "Western Europe (ISO-8859-1)" the character set should be configured
locationSets from CSV file
The most useful way is first to read all locations from the CSV file into one locationSet, where all attributes are assigned.
See for example:
locationSets from esriShapeFile
The most useful way is first to read all locations from the Shape/DBF file into one locationSet, where all attributes are assigned.
See for example:
locationSets from database table
It is also possible to read locations directly from a database table. The contents of the database table are on the fly read and converted to a DBZ file. This DBZ file will be used by FEWS. This is for backup purpose in case the database is not available any more, like in stand-alone test environments.
In this example the above database table PEILBUIZEN is read from the database and completely converted to a zipped DBase file, named PEILBUIZEN.dbz. This file is used by FEWS to read all the required data.
To use a Firebird/Derby database file you should use the element <databaseFile> instead of <dbServerName>. Other connection strings:
To encrypt the password, use F12 menu (clipboard - > encrypt password, available since 2016.01)
using attributes, constraints, relations etc.
In the above example the visibilityStartTime and visibilityEndTime tags are used to define the columns in the CSV/DBF file that contain the start and end dateTimes of the visibilityPeriod for each location. The (optional) visibilityPeriod is the period for which a location is visible in the user interface. The start and the end of the period are inclusive. Currently the visibility period is used in the map (explorer) window, the time series display and the spatial display. If startDateTime is not defined, then the location is visible for all times before endDateTime. If endDateTime is not defined, then the location is visible for all times after startDateTime. If startDateTime and endDateTime are both not defined, then the location is visible for all times. Furthermore the (optional) dateTimePattern tag is used to define the pattern for the dateTimes defined in the CSV/DBF file. If dateTimePattern is not specified, then the default pattern "yyyyMMdd" is used, which is the internal format that a CSV/DBF file uses for columns of type 'D' (date columns). The (optional) timeZoneOffset is the offset of the times in the CSV/DBF file, relative to GMT. For example "+02:00" means GMT+02:00. If no offset is specified, then time zone GMT is used by default.
Next you can derive the required locationSets from this dump by using constraints.
You can use constraints like:
- etc (see schema or the schema diagram)
It is also possible in a locationSet to link to time-dependent attributes. Time-dependent attributes need to be defined in a separate CSV/DBF file. In the locationSet use the attributeFile tag to make a reference to such a file. The following xml example has a reference to the file PumpStationsAttributes.dbf, which contains attributes that have different values for different periods in time, as well as different values for different locations. In this case the startDateTime and endDateTime tags are used to define the columns in the CSV/DBF file that contain the start and end dateTimes for each row. A given row in the CSV/DBF file contains values that are only valid between the time period for that row. This period is defined by the optional startDateTime and endDateTime for that row. If a row has no startDateTime, then it is valid always before the endDateTime. If a row has no endDateTime, then it is valid always after the startDateTime. If a row has no startDateTime and no endDateTime, then it is always valid. When Time-dependent attributes are change in time, make sure the startDateTime of one row is the same as the endDateTime of the previous row. If there is a gap of one day between the startDeteTime and the endDateTime, then there is a gap of one day for the validity of the location attributes. Since the 2021.01 the <attributeFile> can also be used to add additional attributes when the locations itself are read from a database table <table> .
It is possible to define the location icon with a new option in the locationSets derived from CSV/Shape-DBF files. You can define the location icon with the element iconName. The icon files should be defined as complete file name and this file should be available in the Config\IconFiles directory. If you want to refer to Config\IconFiles\Waterlevel.gif, you should define the iconName as
The old method by defining icons in the systemconfigfiles\locationIcons.xml is still available.
The regional configuration file Locations is not needed any more, except for other locations that are not supplied in a CSV/DBF file.
Attribute functions are supported in configurations for parameter enumerations, id maps, primary validation, secondary validation, thresholds, transformation, general adapter, reports, map layer symbol sizes, statistics in time series dialog, display groups
It is possible to reference an attribute that is available at a related location by prefixing an attribute id with a location relation id.
@discharge@ / 1000
See that actual idMapping schema for all possible options.
Notice that you can use the location attributes as a function to map to the correct locations. You can create strings based on the attributes, like:
See all available options in the actual schema. The useful options for using together with the CSV/DBF configuration are explained here. Both options automatically generate the list of the locations in the shortcut trees. The list of locations is ordered alphabetically.
Adds multiple displays at once to this display group. Every display will show only one location.
Adds multiple displays at once to this display group. Every display will show only children for one parent location, and the parent location itself when specified in the time series sets.
you can use now ...Function alternatives for all the values
you can use now ...Function alternatives for all the values, like
In the new transformation module it is possible to define transformations with embedded coefficientSetFunctions in a transformation config file. For a given transformation, e.g. StructurePumpFixedDischarge, there is a choice between a coefficientSetFunctions object and a coefficientSet object. The coefficientSetFunctions object is the same as its corresponding coefficientSet counterpart, only all elements with a value are replaced by elements with a function. A function is a function expression that can refer to location attributes, e.g. " (discharge) / 60". See the following xml example.
CoefficientSetFunctions are currently (as of build 30246) supported for the following transformations: userSimple, stageDischargePower, dischargeStagePower, filterLowPass and all structure transformations. See the pages of those specific transformations for configuration examples.
different types of attributes
When using coefficientSetFunctions, note that the elements can have different types, e.g. float, boolean, enumeration. For each coefficientSetFunctions type see the schema definition of its corresponding coefficientSet counterpart for the types of the different elements. The type of an attribute as defined in the locationSets configuration file must match the type of the element in which the attribute is used.
For elements of type float (e.g. userSimple coefficient value) the attribute should be defined as a number attribute in the locationSets configuration file as follows:
For elements of type string, boolean (e.g. structureCrumpWeir energyHeadCorrection) or enumeration (e.g. stageDischarge type) the attribute should be defined as a text attribute in the locationSets configuration file as follows:
Coefficients that depend on location and time
A coefficientSetFunction can be very useful when using coefficients that depend on location and/or time. In that case the coefficientSetFunction needs to be defined only once with a link to the correct attributes. The attributes are defined in a CSV/DBF file. Then a transformation run will use the coefficientSetFunction to create coefficientSets for each location and time-period by taking the required values from the attributes from the CSV/DBF file automatically.
If several attributes are used in the same coefficientSetFunction, then it is still possible to have some of those attributes time-independent and some time-dependent. However all the time-dependent attributes that are used in a given coefficientSet should be defined with exactly the same time-periods in the CSV/DBF file.
Coefficients with multiple values (tables)
Some transformations require a table, e.g. a head-discharge table, in a coefficientSet. For the purpose of tables it is possible to define a given attribute in a CSV/DBF file with multiple values. To do this make multiple rows with the same location and same period, only with different values for the attributes. If a given attribute is used in a table in a coefficientSetFunctions object, then for each location and period the multiple values that are defined for that location and period will be converted to a table during a transformation run. This only works for elements in a coefficientSetFunctions object that are designated as table elements. An element in a coefficientSetFunctions object is designated as a table element if, according to the schema, the element can occur only once in the coefficientSetFunctions object, but can occur multiple times in the corresponding coefficientSet object. This is how a transformation run knows that it should search for multiple values for attributes to create a table. This is the case e.g. for the headDischargeTableRecord element in the StructurePumpHeadDischargeTable transformation, which would be used as in the following xml example. In this case the "head" and "discharge" attributes should have multiple values defined in the CSV/DBF file so that a head-discharge table can be created.
All attributes, e.g. "head" and "discharge", that are used in the same table element, e.g. headDischargeTableRecord, should have the same number of values defined per location per period. It is still possible to have a different number of values for different periods and different locations, as long as there are as many head values as discharge values per location per period.
Sample input and output
Error and warning messages
Description of errors and warnings that may be generated
Action to fix
Describe all known issues and unexpected behaviour
Since 2016.01 an error is logged when values contain decimal comma instead of decimal point. e.g. 453,73 should be 453.73
Related modules and documentation
Links to related parts of the system
Entry in moduleDescriptors:
Specification of: ENTRY and DESCRIPTION in the SystemConfigFiles\ModuleDescriptors.xml