dbServerType
Wiki Markup |
---|
{scrollbar} |
Excerpt | ||
---|---|---|
| ||
Functionality to define Locations, LocationSets, IdMaps, DisplayGroups, ThresholdValueSets and ValidationRuleSets from a DBF file |
Function: | _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. |
Description: | Based on the CSV, DBF-Shape file or DB table you can easily manage the configuration |
Available since: | DelftFEWS200803 |
Contents
Table of Contents |
---|
...
Overview
...
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.
...
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:
Code Block | ||||
---|---|---|---|---|
| ||||
<locationSet id="gegevensdump" editable="false">
<csvFile>
<file>gegevens.csv</file>
<geoDatum>Rijks Driehoekstelsel</geoDatum>
<id>%ID%</id>
<name>%NAAM%</name>
<description>%TYPE%</description>
<iconName>%ICONFILE%</iconName>
<parentLocationId>%PARENT%</parentLocationId>
<timeZoneOffset>+05:00</timeZoneOffset>
<dateTimePattern>yyyyMMdd HH:mm:ss</dateTimePattern>
<visibilityStartTime>%START%</visibilityStartTime>
<visibilityEndTime>%EIND%</visibilityEndTime>
<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>
</csvFile>
</locationSet>
|
...
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:
Code Block | ||||
---|---|---|---|---|
| ||||
<locationSet id="gegevensdump" editable="false">
<esriShapeFile>
<file>gegevens</file>
<geoDatum>Rijks Driehoekstelsel</geoDatum>
<id>%ID%</id>
<name>%NAAM%</name>
<description>%TYPE%</description>
<iconName>%ICONFILE%</iconName>
<parentLocationId>%PARENT%</parentLocationId>
<timeZoneOffset>+05:00</timeZoneOffset>
<dateTimePattern>yyyyMMdd HH:mm:ss</dateTimePattern>
<visibilityStartTime>%START%</visibilityStartTime>
<visibilityEndTime>%EIND%</visibilityEndTime>
<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>
|
...
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.
Code Block | ||||
---|---|---|---|---|
| ||||
<locationSet id="grondwater"> <table> <databaseServer> <dbServerType>sqlserver</dbServerType> <dbServerName>srvcodatestsql</dbServerName> <dbServerPort>1433</dbServerPort> <dbInstanceName>ULTIMO</dbInstanceName> <dbInstanceUser>*******</dbInstanceUser> <dbInstanceEncryptedPassword>*******</dbInstanceEncryptedPassword> </ <databaseServer> <url>jdbc:oracle:thin:@oraclex02:1521:FEWS</url> <user>fews</user> <encryptedPassword>***</encryptedPassword> </databaseServer> <name>PEILBUIZEN</name> <geoDatum>Rijks Driehoekstelsel</geoDatum> <id>ult_%FEWS_ID%</id> <name>%NAAM%</name> <description>Gebiedsnaam: %GEBIEDSNAA% </description> <x>%X_COORDINA%</x> <y>%Y_COORDINA%</y> <attribute id="DOMMEL_ID"> <text>%MEETPUNTCO%</text> </attribute> <attribute id="TMX_ID"> <text>%TMX%</text> </attribute> <attribute id="HARD_MAX"> <number>%HARD_MAX%</number> </attribute> <attribute id="HARD_MIN"> <number>%HARD_MIN%</number> </attribute> </table> </locationSet> |
...
For example:
Code Block | ||||
---|---|---|---|---|
| ||||
<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 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.
Code Block | ||||
---|---|---|---|---|
| ||||
<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>
<csvFile>PumpStationsAttributes.csv</csvFile>
<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>
|
...
The regional configuration file Locations is not needed any more, except for other locations that are not supplied in a CSV/DBF file.
idMaps
...
Code Block | ||||
---|---|---|---|---|
| ||||
<locationIdFunction internalLocationSet="Meteo Stations" externalLocationFunction="@region@"/>
<locationIdPattern internalLocationSet="Pattern Stations" internalLocationPattern="H-*"
externalLocationPattern="*"/>
..
or
..
<function externalLocationFunction="@CITECTLOC@" internalParameter="Q.meting"
externalParameterFunction="@IDMAP_DEBIET@" internalLocationSet="VV_Q.meting"/>
|
...
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:
No Format |
---|
! uses the complete attribute value
externalParameterFunction="@IDMAP_DEBIET@"
! uses two concatenated attribute values
externalParameterFunction="@CITECTLOC@_@IDMAP_DEBIET@"
! uses attribute values concatenated with a fixed string
externalParameterFunction="@CITECTLOC@_DEBIET"
|
...
singleParentLocationDisplays
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.
Code Block | ||||
---|---|---|---|---|
| ||||
<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>
|
...
you can use now ...Function alternatives for all the values
Code Block | ||||
---|---|---|---|---|
| ||||
<levelThresholdValue>
<levelThresholdId>LevelWarn</levelThresholdId>
<description>.....</description>
<valueFunction>@SOFT_MAX@</valueFunction>
<upActionLogEventTypeId>TE.571</upActionLogEventTypeId>
</levelThresholdValue>
|
...
- extremeValuesFunctions
- sameReadingFunctions
- etc...
Code Block | ||||
---|---|---|---|---|
| ||||
<levelThresholdValue>
<levelThresholdId>LevelWarn</levelThresholdId>
<description>.....</description>
<valueFunction>@SOFT_MAX@</valueFunction>
<upActionLogEventTypeId>TE.571</upActionLogEventTypeId>
</levelThresholdValue>
|
...
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.
Code Block | ||||
---|---|---|---|---|
| ||||
<transformation id="pump with coefficient set functions">
<structure>
<pumpFixedDischarge>
...
<coefficientSetFunctions>
<discharge>@discharge@ / 1000</discharge>
</coefficientSetFunctions>
...
</pumpFixedDischarge>
</structure>
</transformation>
|
...
Note | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||
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.
|
...
Note | ||
---|---|---|
| ||
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. |
Code Block | ||||
---|---|---|---|---|
| ||||
<transformation id="pump with head-discharge table with coefficient set functions">
<structure>
<pumpHeadDischargeTable>
...
<coefficientSetFunctions>
<headDischargeTableRecord head="@head@" discharge="@discharge@ * 1000"/>
</coefficientSetFunctions>
...
</pumpHeadDischargeTable>
</structure>
</transformation>
|
...
Entry in moduleDescriptors: | Specification of: ENTRY and DESCRIPTION in the SystemConfigFiles\ModuleDescriptors.xml |
---|
No Format |
---|
<moduleDescriptor id="ENTRY">
<description>DESCRIPTION</description>
|