Page History

...

Contents

Overview

To be able to have only one file that manages all the regional information, Delft-FEWS offers the functionality to use a 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 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.

...

Configuration

locationSets

The most useful way is first to read all locations from the DBF into one locationSet, where all attributes are assigned.
See for example:

...

<locationSet id="PumpStations">
  <esriShapeFile>
    <file>PumpStations</file>
    <geoDatum>WGS 1984</geoDatum>
    <id>%ID%</id>
    <name>%ID%</name>
    <x>%X%</x>
    <y>%Y%</y>
    <z>0</z>
    <attributeFile>
      <dbfFile>PumpStationsAttributes</dbfFile>
      <id>%ID%</id>
      <timeZoneOffset>+05:00</timeZoneOffset>
      <dateTimePattern>dd-MM-yyyy HH:mm</dateTimePattern>
      <startDateTime>%START%</startDateTime>
      <endDateTime>%EIND%</endDateTime>
      <attribute id="speed">
        <number>%FREQ%</number>
      </attribute>
      <attribute id="discharge">
        <number>%POMPCAP%</number>
      </attribute>
    </attributeFile>
  </esriShapeFile>
</locationSet>

locationIcons

Since 2009.02 it is possible to define the location icon with a new option in the locationSets derived from 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.

locations

The regional configuration file Locations is not needed any more, except for other locations that are not supplied in a DBF file.

idMaps

<locationIdFunction internalLocationSet="Meteo Stations" externalLocationFunction="<at:var at:name="region" />"/>
<locationIdPattern internalLocationSet="Pattern Stations" internalLocationPattern="H-*" 
     externalLocationPattern="*"/>

..
or
..
  <function externalLocationFunction="<at:var at:name="CITECTLOC" />" internalParameter="Q.meting"
    externalParameterFunction="<at:var at:name="IDMAP_DEBIET" />" internalLocationSet="VV_Q.meting"/>

...

! uses the complete attribute value
externalParameterFunction="<at:var at:name="IDMAP_DEBIET" />"        

! uses two concatenated attribute values
externalParameterFunction="<at:var at:name="CITECTLOC" />_<at:var at:name="IDMAP_DEBIET" />"  

! uses an attribute values concatenated with a fixed string
externalParameterFunction="<at:var at:name="CITECTLOC" />_DEBIET" 

displayGroups

See all available options in the actual schema. The useful options for using together with the 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.

...

<displayGroup name="Meteo">
    <singleParentLocationDisplays>
      <locationSetId>VV_P.meting.dag</locationSetId>
      <locationSetId>VV_P.meting</locationSetId>
      <parentLocationSetId>VV_P.meting.dag</parentLocationSetId>
      <parentLocationSetId>VV_P.meting</parentLocationSetId>
      <plotId>meteo</plotId>
    </singleParentLocationDisplays>
  </displayGroup>

Thresholds

you can use now ...Function alternatives for all the values

<levelThresholdValue>
	<levelThresholdId>LevelWarn</levelThresholdId>
	<description>.....</description>
	<valueFunction><at:var at:name="SOFT_MAX" /></valueFunction>
	<upActionLogEventTypeId>TE.571</upActionLogEventTypeId>
</levelThresholdValue>

ValidationRuleSets

you can use now ...Function alternatives for all the values, like

...

<levelThresholdValue>
	<levelThresholdId>LevelWarn</levelThresholdId>
	<description>.....</description>
	<valueFunction><at:var at:name="SOFT_MAX" /></valueFunction>
	<upActionLogEventTypeId>TE.571</upActionLogEventTypeId>
</levelThresholdValue>

CoefficientSetFunctions

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.

...

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 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 DBF file automatically.

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 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 DBF file so that a head-discharge table can be created.

...

<transformation id="pump with head-discharge table with coefficient set functions">
  <structure>
    <pumpHeadDischargeTable>
      ...
      <coefficientSetFunctions>
        <headDischargeTableRecord head="<at:var at:name="head" />" discharge="<at:var at:name="discharge" /> * 1000"/>
      </coefficientSetFunctions>
      ...
    </pumpHeadDischargeTable>
  </structure>
</transformation>

Sample input and output

Sample input and output. You can attach files if necessary

Error and warning messages

Description of errors and warnings that may be generated

Known issues

Describe all known issues and unexpected behaviour

Related modules and documentation

Links to related parts of the system

Technical reference

...