22 Locations and attributes defined in shape or DBF files

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.

Finally you have a configuration that has many links to the 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 DBF 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

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="gegevensdump" editable="false">
    <esriShapeFile>
      <file>gegevens</file>
      <geoDatum>Rijks Driehoekstelsel</geoDatum>
      <id>%ID%</id>
      <name>%NAAM%</name>
      <description>%TYPE%</description>
      <parentLocationId>%PARENT%</parentLocationId>
      <x>%X%</x>
      <y>%Y%</y>
      <z>0</z>
      <attribute id="PARENT">
        <text>%PARENT%</text>
      </attribute>
      <attribute id="TYPE">
        <text>%TYPE%</text>
      </attribute>
      <attribute id="CITECTLOC">
        <text>%CITECTLOC%</text>
      </attribute>
      <attribute id="IDMAP_Q">
        <text>%DEBIET%</text>
      </attribute>
      <attribute id="HMIN_Q">
        <number>%HMIN_Q%</number>
      </attribute>
      <attribute id="HMAX_Q">
        <number>%HMAX_Q%</number>
      </attribute>
      <attribute id="ROC_Q">
        <number>%ROC_Q%</number>
      </attribute>
    </esriShapeFile>
  </locationSet>

Next you can derive the required locationSets from this dump by using constraints.
You can use constraints like:

• attributeTextEquals
• attributeTextContains
• attributeTextStartsWith
• idContains
• attributeExists
• etc (see schema)

For example:

<locationSet id="ST_K.meting" editable="false">
    <locationSetId>gegevensdump</locationSetId>
    <constraints>
      <not>
        <attributeTextEquals equals="" id="IDMAP_KLEP"/>
      </not>
      <attributeTextEquals equals="Stuwen" id="TYPE"/>
    </constraints>
</locationSet>

It is also possible in a locationSet to link to time-dependent attributes. Time-dependent attributes need to be defined in a separate 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 DBF file that contain the start and end dateTimes for each row. A given row in the 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.

<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>

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"/>

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:

! 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.

singleLocationDisplays
Adds multiple displays at once to this display group. Every display will show only one location.

singleParentLocationDisplays
Adds multiple displays at once to this display group. Every display will show only childs for one parent location, and the the parent location itself when specified in the time series sets.

<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

• extremeValuesFunctions
• sameReadingFunctions
• etc...

<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.

<transformation id="pump with coefficient set functions">
  <structure>
    <pumpFixedDischarge>
      ...
      <coefficientSetFunctions>
        <discharge><at:var at:name="discharge" /> / 1000</discharge>
      </coefficientSetFunctions>
      ...
    </pumpFixedDischarge>
  </structure>
</transformation>

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

<moduleDescriptor id="ENTRY">
<description>DESCRIPTION</description>