Report Module Configuration
The role of the report module is to generate reports of the forecast results in a form that can easily be displayed without using DELFT-FEWS on a web server. Reports that are produced by DELFT-FEWS serve two purposes:
- provision of detailed, specific information to e.g. forecasting duty officers, area officers
- provision of general, overview reports
Reports are used to present the forecast result data in a fixed, user defined, format. The format of a report can be easily customized by a user and stored in a template.
Some functions of the DELFT-FEWS use the report component to present the results. For example the critical condition lookup tables defined in for example coastal forecasting only produce index time series. Without post-processing of these indices, a user can never see what is happening in his coastal system. The report component will therefore also be used to interpret the indices and transform these into information that a user can understand. The ValueAttributeMaps (see Regional Configuration) define how these indices are to be transformed to understandable strings and/or icons.
Reports generated can be exported directly to the file system (for viewing through the web server) or they can be stored in the database. The report export module may then be used to exporting selected reports when required to the web server.
The report template uses tags as placeholders to identify the location of objects in the report. In the following table the available tags are described. Appendix D gives an overview of available tags. Appendix D also gives details on how defined declarations are to be used in the reports- allowing layout of tables etc. to be defined.
When available as configuration on the file system, the name of the XML file for configuring an instance of the correlation module called for example Report_Coastal_Forecast may be:
Report_Coastal_Forecast 1.00 default.xml
Report_Coastal_Forecast |
File name for the Report_Coastal_Forecast configuration. |
1.00 |
Version number |
default |
Flag to indicate the version is the default configuration (otherwise omitted). |
Figure 89 Elements of the Reports configuration
Configuring formatting of reports
declarations
Root element for declaring variables and formats to be used in making the report. Details on how these are to be configured is given in Appendix D.
Figure 90 Elements of the declarations configuration
defineGlobal
The DefineGlobal element can be used to enter some information that is valid for all reports. Multiple DefineGlobal elements may be defined, as long as the ID attribute is kept unique.
Related TAG: $DEFINITION(definitionId)$
<item>Format
Formatting instructions for a specific item in the report. See Appendix D for details.
templateDir
Root directory of the directory containing report templates.
reportRootsDir
Root directory to which the all reports are to be exported. This directory is typically the root directory of the web server
Note: A global.properties tag may be useful to define this directory
reportRootsSubDir
Root directory to which the current reports are to be exported. This directory is relative to the reportsRootsDir
sendToLocalFileSystem
Boolean option to determine if reports are to be written to the file system on creation. If set to false reports will be stored in the Reports table in the database, pending export through the ReportExport module.
Configuring content of reports
report
Root element for defining the data to be included in the report.
Figure 91 Elements of the Report configuration
InputVariable
Input timeseriesSets for the report. All timeSeriesSets that are used in the report must be defined here, both for carts and for tables. See Transformation Module for details on defining an inputVariable element.
FileResource
Reference to an external file that must be copied with the report. The file will be copied to the same location as the report, with the correct filename inserted at the place of the tag. This can be used for copying images.
Related TAG: $FILERESOURCE(resourceId)$
Chart
In the Chart element the variableId's to be used for one or more charts are defined. The Chart ID that is defined is referenced in the TAG.
Related TAG: $CHART(chartId)$
Summary
In the Summary element the variableId's are specified that are used to create the summary information. The OverlayFormat of the SummaryFormat determines what is shown on the map.
Related TAG: $SUMMARY(summaryId)$
Table
In the Table element the variableId's are specified that are used to create a table. The TableFormat controls how the table is formatted, i.e. the row and column information and how the data is displayed in the map.
Related TAG: $TABLE(tableId)$
Status
The Status element links a Status ID that is referenced in the STATUS TAG to a Status Format ID.
Related TAG: $STATUS(statusId)$
Template
Template file name to be used for the report.
OutputSubDir
Output Sub Directory for the report
OutputFileName
Report Filename.
DefineLocal
The DefineLocal element can be used to enter some information that is valid for a single report. Multiple DefineLocal elements may be defined, as long as the ID attribute is kept unique.
A special case of the DefineLocal attribute is when the DefineLocalID is the same as a previously DefineGlobalID. In this case the DefineLocal overrides the setting of the DefineGlobal. This is valid only for the report being configured, not for any other configured reports in the same configuration file.
Related TAG: $DEFINITION(definitionId)$
Charts
Charts can be used for visualising (more than one) timeseries by displaying them on a x and y axis using lines, dots etc. The charts which can be added to html-reports looks more or less the same as in the TimeSeries Display. Charts are being created as (individual) *.png files.
Figure 92 Example of a chart (*.png file)
Template tag
In the Chart element the variableId's to be used for one or more charts are defined. The Chart ID that is defined is referenced in the TAG.
Related TAG: $CHART(chartId)$
Configuration aspects
Chart should be configured according the following schema definition (reports.xsd)
Figure 93 Chart definition according the ChartComplexType (sharedTypes.xsd).
For adding a chart to a report the following aspects are important to configure:
- Chart attributes;
- Chart timeseries;
Chart attributes
To display the chart the following attributes need to be defined:
- Id: unique identifier for this chart (unique in this report);
- formatId: referring to the format of this chart (in declaration section of the report)
- height: an integer value for the height of the chart in pixels;
- width: an integer value for the width of the chart in pixels;
Chart timeseries
To display lines, dots etc. of a certain timeseries, the reference to this timeseries (variableId) should be mentioned.
Figure 94 chart declaration in the report section
Spatial plot snapshots
Gridded time series can be visualized in a report by means of snapshots. The snap shot is an image depicting the time series spatially.
Configuration aspects
Spatial plot snapshots are configured according to the following schema definition (sharedTypes.xsd)
snapshot
The snapshot is defined as a relative time interval from T0. Optionally a file name may be specified for the snapshot which is used to save the snapshot on the file system. If omitted the file name is generated by the report module.
Summary
A summary is a (background) map which can be added to a report. On top of this map, icons can be displayed. The icons indicate the location or the (warning) status of the monitoring or forecasting point. By adding specific html-functionality to the report template(s), maps can be used to navigate through the reports as well. Clickable areas and locations can be distinguished here. The map itself (as a file) can be any image file. For displaying maps in html-reports the following formats are advised: *.png, *.jpg or *.gif.
Template tag
In the Summary element the variableId's are specified that are used to create the summary information. The OverlayFormat of the SummaryFormat determines what is shown on the map.
Related TAG: $SUMMARY(summaryId)$
Creating a summary
The map itself is an existing file and can be created in several ways. An image processing software package (like Paint Shop Pro) can create a 'screendump' from the map section of The FEWS-Explorer. The FEWS-Explorer itself has some hidden features which can be used as well. The [F12] button can be used for:
Copy current map to a .png file ([F12]+ L);
Copy current map extent to the clipboard ([F12]+ K);
The *.png file is named "currentmap.png" and can be found in the /bin directory of your system. The map extent (rectangle containing real world coordinates) can be pasted into any application by choosing Edit-Paste or [Ctrl]+ V. These four coordinates describing the extent of your map picture in world coordinates are needed in the declarations section of the report ModuleConfigFile where you declare this summary.
Remark: Every time you use the above mentioned [F12] features, the png file in the /bin directory and the clipboard is overwritten! In making series of maps you should copy/rename your png file after using this option. You should also paste the map extent in a text editor or spreadsheet directly before repeating the operations with another map extent in the FEWS-Explorer.
Configuring a summary
Declaration section
In the declarations section of the report ModuleConfigFile, the summaryFormat needs to be declared. The following elements should be specified (see figure).
- Id: unique identifier (as reference to this summary)
- Map
o Image - file: relative reference/path to the image file;
- width: width of the image file in pixels;
- height: height of the image file in pixels;
o x0: horizontal margin/shift of the map on the html page;
o y0: vertical margin shift of the map on the html page;
o leftLongitude: left side of the map in real world coordinates;
o rightLongitude: right side of the map in real world coordinates;
o bottomLatitude: bottom side of the map in real world coordinates;
o topLatitude: top side of the map in real world coordinates;
o mapFormat: details for positioning and behaviour of the map;
o overlayFormat: details for positioning and behaviour of icons on the map;
Figure 95 Summaryformat in the declarations section
Detailed explanation
- File details like width and height can be retrieved using image processing software.
- The x0 and y0 elements are margins/shifts of the position of the map compared to the left-upper point of the report (e.g. an A4-sheet). This left-upper point is (0,0). The x0/y0 refer to the left-upper point of the image.
The mapFormat is used for positioning the map on the page (relative to all other content) and therefor it is placed in a so-called [DIV] tag. This type of html tag puts everything which is configured within that tag in that position on the page. The following table explains the references of the number in this format:
Position |
Type |
Variable |
0 |
number |
Absolute x position of map image. |
1 |
number |
Absolute y position of map image. |
2 |
number |
Image width. |
3 |
number |
Image height |
4 |
number |
Image filename. |
5 (optional) |
number |
Reference to a clickable map (#clickmap by default) |
- The overlayFormat is used for positioning location and/or warning icons on the map based on:
- The map itself (defined in mapFormat);
- X and Y coordinates of the required locations from the Locations.xml;
- Note that in case of numbers bigger than 999, it can be that the output may contain unwanted commas, e.g. width 1274 is printed in the reports as 1,274. In order to avoid this, it is recommended to use
instead of
{<position>, number, #}
.{<position>, number}
Position |
Type |
Variable |
0 |
number |
Absolute x position of status icon. |
1 |
number |
Absolute y position of status icon. |
2 |
string |
Image filename. |
3 |
string |
Status description. |
4 |
string |
Location name. |
5 (optional) |
string |
Html-link for opening a individual html page (forecastlocation.html) |
The mapFormat and overlayFormat elements are configured in html language in which some parts needs to be dynamically filled in. The result will be valid html. The map itself is placed as the bottom 'layer' using the <DIV> tag attributes (index="0") in the mapFormat. Objects defined in the overlayFormat are given higher indices to place them 'on top of the map' and will always be visible (location icons, warning icons).
Use of optional settings in mapFormat and overlayFormat
In both formats, an optional item can be specified.
Clickable map
A clickable map is an image on a html page containing 'hot spots' where the cursor change from the normal 'arrow' to a 'pointing finger' during a mouse-over event. These hot spots can contain hyperlinks to other pages.
mapFormat |
<div style="TOP:{1, number, #}px; LEFT:{0, number, #}px; position:absolute;Z-index:0"> <img border="0" src="{4}" width="{2,number,#}" height="{3, number, #}" usemap="{5}"> </div> |
---|
When adding the string "usemap="{5}" to the mapFormat (see above) the outcome in the html page will be (printed in bold).
The part describing the hot spots for this map are defined in the [map] tag. In this example below, three areas are 'clickable'. Every hot spots links to another html page in the set of reports.
<img border="0" src="northeast.png" width="503" height="595" *usemap="#clickmap"*> <!-- Here the clickable map starts: SHOULD BE IN THE TEMPLATE --> <map name="clickmap"> <area alt="Northumbria Area" href="northumbria/area_status.html" shape="polygon" coords="138, ...,...,34"> <area alt="Dales Area" href="dales/area_status.html" shape="polygon" coords="266, ..., ..., 285"> <area alt="Ridings Area" href="ridings/area_status.html" shape="polygon" coords="359, ..., ..., 379"> </map>
To avoid hot spots on a map, do not include the "usemap="{5}" in the mapFormat.
Hyperlinks
Hyperlinks can be added to the overlayFormat. By using the following option, hyperlinks to individual reports will be added automatically. They will have a fixed (non-configurable) name, "forecastlocation.html" and assuming it is located in a directory with the same name as the locationId compared to where this report with the map is located in the directory structure.
overlayFormat |
<div style="TOP:{1,number,#}px; LEFT:{0,number,#}px; position:absolute;Z-index:1"> <a href="{5}"> <img border="0" src="{2}" title="{4}: {3}"> </a> </div>\n |
---|
When adding href="{5}" to the overlayFormat (at that location) a hyperlink is being added to the icon placed on the map. In html it will look like this.
<!-- map --> <div style="TOP:160px;LEFT:5px;position:absolute;Z-index:0"> <img border="0" src="derwent.png" width="503" height="578" usemap="#clickmap"> </div\> <!-- icons --> <div style="TOP:467px;LEFT:427px;position:absolute;Z-index:1"> <a href="BOYNTN1/forecastlocation.html"><img border="0" src="fluvial_site_data.gif" title="Boyntn1: No threshold exceeded"></a> </div>
Report section
A summary can be added to a report configuration as shown below.
Figure 96 Summary configuration in the reports section
The following elements need to be defined.
- Id: identifier referring to the tag in the template. In this case the corresponding template will contain $SUMMARY(statusAreaMap)$
- formatId: identifier referring to the unique identifier of this map in the declarations section.
- timeSeries: reference to an inputVariable (declared in the report or in the declarations section).
- mapId: reference to a valueAttributeMap;
Tables
Tables are available in different types. The similarity between them is that they are referenced with the same template tag.
Template tag
In the Table element the variableId's are specified that are used to create a table. The TableFormat controls how the table is formatted, i.e. the row and column information and how the data is displayed in the map.
Related TAG: $TABLE(tableId)$
The following table types are availabe:
1. table: original table;
2. htmlTable: new style table with same functionality as 'table';
3. thresholdsCrossingsTable: table containing numbers (count) of threshold crossings.
4. maximumStatusTable: table containing (coloured) indicating threshold crossings over time.
5. mergedPrecipitationTable: table containing (merged) precipitation figures in specific time intervals
6. systemStatusTable: table containing system (management) information;
Tables 2 to 6 have references to cascading style sheets. Below the different tables are explained.
htmlTable
The htmlTable is the successor of the table described earlier. The configuration of this htmlTable is easier and more readable.
Declarations section
In the declarations sections a format of a table needs to be defined. In the figure below, a format of a htmlTable is configured.
Figure 97 Declaration of a htmlTableFormat
The following elements needs to be defined:
- id: unique identifier (as reference to this table);
- tableStyle: a choice of tableStyle which can be influenced by using the corresponding classes in a cascading style sheet. Choices are tableStyle1 to tableStyle10;
- column: indicates what (of one or more Timeseries) should be shown in the columns (options are: location, time, date, locationcritical, parameter, parameters, choice);
- row: indicates what (of one or more Timeseries) should be shown in the rows (options are: location, time, date, locationcritical, parameter, parameters, choice);
- relativeWholePeriod: definition of a moving period in time to be displayed (in the example above 24 hours before the day containing T0 of the forecast and 24 after the day containing T0 of the forecast (in total 3 days);
- topLeftText: definition of the text to be displayed in the upper left cell of the table;
- cellFormat: format of the cell containing the values;
- topFormat: format of the column headers;
- leftFormat: format of the most left column;
- missingValueText: definition of the missing value character. Choices are: " ", "#", "" or " -";
- nullValueText: definition of the null value (NAN) indicator. Choices are: " ", "-", "-999", " no data";
Report Section
In the report itself the reference to a tableFormat and the declaration of the content should take place. The schema prescribes as follows:
Figure 98 Declaration and reference of a htmlTable in a report
The following elements need to be defined:
- id: identifier to the template tag (in this case: $TABLE(table1)$);
- formatId: reference to the format of this table (to one of the htmlTableFormats in the declarations section);
- timeSeries: reference to an inputVariable (declared in the report or in the declarations section).
- cellFormat: addition to tableStyleX class for adding specific styles to the content of the cell;
Remark: htmlTables can contain more than one timeseries. By adding different cellFormats to the series (see picture above) different styles can be attached for display in the table. In this way you can distinguish the two timeseries in the table!
Detailed explanation
The choice of adding a certain tableStyle to a table supplies you with the opportunity to influence the looks and style of the table, its borders, background and content. By setting the tableStyle a number of style classes are being generated in the html-pages. By declaring these classes in a stylesheet (*.css) and ascribe a certain font family, font size, border color, background color etc. you are able to 'polish' the looks of your reports. If a tableStyle class is not mentioned in a stylesheet, it is being displayed using default settings.
The following classes are generated automatically and are added after the tableStyleX in which X stand for an integer in the range 1 to 10.
class |
description |
specific for |
_beforeT0 |
date/time indication before time zero (TO) of the forecast |
time column (most left column) |
_firstAfterT0 |
date/time indication of the first occurrence after time zero (T0) of the forecast |
time column (most left column) |
_afterT0 |
date/time indication after time zero (TO) of the forecast |
time column (most left column) |
_data |
default indication of data content of a cell |
data cells |
_anyString |
user defined cellFormat |
data cells |
_datamax |
addition to current style if value is maximum of that series (_data_datamax or _anyString_datamax) |
data cells |
_leftcol |
default indication of a row header |
 |
_header |
default indication of a column header |
 |
_threshold_n |
indication of threshold level (n=0,1,2,...) |
threshold tables (colouring of backgrounds) |
thresholdsCrossingsTable
A thresholdCrossingsTable is a table in which the number of thresholds for each level are counted. The number given in the table suggests with the 'worst' case situation. When a timeseries crosses a number of thresholds in a forecast, only the 'worst' threshold crossings are counted. An example of a thresholdsCrossingsTable is given below.
Figure 99 Example of a thresholdCrossingTable (NE Region)
Declarations section
In the declaration sections the layout of the table needs to be defined.
Figure 100 Declaration of a thresholdsCrossingsTable
The following elements needs to be defined:
- id: unique identifier (as reference to this table);
- tableStyle: a choice of tableStyle which can be influenced by using the corresponding classes in a cascading style sheet. Choices are tableStyle1 to tableStyle10;
- thresholdsCrossingsCounterHeaderText: String to be displayed in the table header;
- thresholdsCrossingsTableUpCrossingsHeaderText: not in use anymore: can be left blank.
- thresholdsCrossingsTableDownCrossingsHeaderText: not in use anymore: can be left blank.
- cellFormat: any string but "_thresholds" is recommended: style class of the table header in combination with the typeId (range always starts with a 0);
- topFormat; not in use anymore, can be left blank ;
- colWidth: width of a column in pixels;
- missingThresholdsText: Choice for missing threshold. Choices are: " ", "#", "" or " -";
- noThresholdsCrossed: definition of the null value (NAN) indicator. Choices are: " ", "-", "-999", " no data";
- countIndividualThresholds: true if individual threshold crossings must be counted; false (= default) if per location only the worst case must be counted
- thresholdTypes: array of thresholds, assuming a logical order
o typeId: textual indication of corresponding threshold level;
o name: indication of the text to appear in column headers;
Report section
A thresholdsCrossingsTable should be defined in the report as well. E.g. this table needs to be 'filled' with its corresponding timeseries.
Figure 101 Declaration of a thresholdsCrossingsTable in a report
The following elements needs to be defined:
- id: identifier to the template tag (in this case: $TABLE(table1)$);
- formatId: reference to the format of this table (to one of the thresholdsCrossingsTable in the declarations section);
- mergeLocations: boolean indicator. True means: treat all locations of mentioned timeseries together for combined assessment. False means: extract individual timeseries so that every row indicates one location (timeseries);
- Choice between
o table; --> this can be used to display a table 'in' another one.
o tableRow - formatId: reference to the thresholdsCrossingsTable format;
- id: identifier (mainly for own use/comment);
- timeSeries:
- mapId: reference to a valueAttributeMap;
- Text: reference to an inputVariable (declared in the report or in the declarations section).
Since this type of table is a table in which you can aggregate data (which means combine timeseries) the following option is available: mergeLocations.
thresholdCrossingCountsTable
A thresholdCrossingsCountsTable displays threshold crossing counts depending on which thresholds have been crossed within a given time period. The thresholdCrossingCountsTable is a new version of the thresholdsCrossingsTable. A thresholdCrossingCountsTable has the same layout as a thresholdCrossingCountsTab in the thresholdOverviewDisplay for consistency.
Declarations section
In the declaration sections the layout of the table needs to be defined in a thresholdCrossingCountsTableFormat.
The following options are available:
- id: identifier of this table format.
- thresholdGroupId: id of a thresholdGroup that is defined in the thresholds configuration file. This table displays all thresholds in the specified thresholdGroup.
- relativePeriod: Relative time period for this table. The time period is relative to timeZero. A relative period can be e.g. -3 to +3 hours or e.g. +3 to +6 hours (relative to timeZero).
- countAllActiveThresholds: If true, then this table counts all thresholds that are active (all thresholds that have been crossed). If false, then for a given location this table only takes into account the active threshold with the most severe warning level. Default is false.
- countWarningAreas: If true, then this table counts warning areas, as follows. It is possible to define warning areas for a levelThresholdValue in the thresholdValueSets configuration file. If a crossed levelThresholdValue has warning areas defined, then the number of warning areas is counted for that levelThresholdValue. If a crossed levelThresholdValue has no warning areas defined, then a count of 1 is used for that levelThresholdValue. If this option is false, then for each crossed levelThresholdValue a count of 1 is used (i.e. the warning areas are ignored). Default is true.
- noThresholdsDefinedText: If specified, then this text is shown in cells that correspond to data for which no thresholds are defined. Default is empty space.
- noDataAvailableText: If specified, then this text is shown in cells for which no data is available. Default is "n/a".
- crossingCountZeroText: If specified, then this text is shown in cells for which there are no threshold crossings. Default is "-".
- tableHeaderText: String to be displayed in the table header. The relative period and thresholdGroup name will be appended to this string.
- columnWidth: The width of the columns in the table.
- tableStyle: The tableStyle to use for this table. The available tableStyles are defined in the report tables .css file.
- cellFormat: The cellFormat to use for this table. The available cellFormats for the configured tableStyle are defined in the report tables .css file.
- scrollableTable: Use this to split the table into two parts, one for the header row(s) and one for the data rows. The data row part refers to the tableStyle for this table with "_scrollable" appended. This can be used to make the data rows scrollable while the header row(s) remain fixed. For this to work the referred style needs to be defined in the report tables .css file.
Report section
In the reports section define a thresholdCrossingCountsTable.
The following options are available:
- id: identifier for the template tag (in this case: $TABLE(table1)$);
- formatId: reference to the format of this table (to one of the thresholdCrossingCountsTableFormats in the declarations section);
- mergeLocations: boolean indicator. True means: treat all locations of mentioned timeseries together for combined assessment. False means: extract individual timeseries so that every row indicates one location (timeseries);
- Choice between
o timeSeries;
o table; --> this can be used to display a table within another one.
o tableRow
flagCountsTable
FlagCountsTable is available since Delft-FEWS release 2011.01. A FlagCountsTable displays flag counts depending on the flags of the values in a time series within a given time period.
Example of a flagCountsTable
Declarations section
In the declaration section the layout of the table needs to be defined in a flagCountsTableFormat.
The following options are available:
- id: identifier of this table format.
- tableStyle: The tableStyle to use for this table. The available tableStyles are defined in the report tables .css file.
- hyperlinkUrl: Optional URL. If specified, then the location name for each time series will be a hyperlink that refers to this URL. It is possible to insert the following tags: !LOCATION_ID!, !LOCATION_NAME!, !PARAMETER_ID! and !PARAMETER_NAME!. The !LOCATION_ID! tag will be replaced with the location id for the time series. The !LOCATION_NAME! tag will be replaced with the location name for the time series. The !PARAMETER_ID! tag will be replaced with the parameter id for the time series. The !PARAMETER_NAME! tag will be replaced with the parameter name for the time series. This can e.g. be used to link each row in this FlagCountsTable to a page (or an anchor within a page) that contains a FlagSourceCountsTable with more detailed information about the time series for that row.
- scrollableTable: Use this to split the table into two parts, one for the header row(s) and one for the data rows. The data row part refers to the tableStyle for this table with "_scrollable" appended. This can be used to make the data rows scrollable while the header row(s) remain fixed. For this to work the referred style needs to be defined in the report tables .css file.
Configuration example:
<flagCountsTableFormat id="flagCountsTableFormat"> <tableStyle>tableStyle1</tableStyle> <hyperlinkUrl>report.html#!LOCATION_NAME!_!PARAMETER_NAME!</hyperlinkUrl> </flagCountsTableFormat>
Report section
In the reports section define a flagCountsTable.
The following options are available:
- id: Identifier for this FlagCountsTable that is used in the report template html file in the table tag (e.g: $TABLE(table1)$).
- formatId: The id of the FlagCountsTableFormat to use for this FlagCountsTable.
- inputVariableId: One or more ids of inputVariables that are defined at the start of this report. For each time series in the inputVariable(s), there will be one row in the table with the location, parameter and flag counts for that time series. For a given time series this uses only the data within the relativeViewPeriod that is defined for that time series in the timeSeriesSet. If a timeSeriesSet contains multiple time series (e.g. a locationSet), then for each time series in the timeSeriesSet a separate row is created.
Configuration example:
<flagCountsTable id="flagCountsTable" formatId="flagCountsTableFormat"> <inputVariableId>Cowbeech</inputVariableId> <inputVariableId>Romsey</inputVariableId> <inputVariableId>CrosslandsDrive</inputVariableId> </flagCountsTable>
flagSourceCountsTable
FlagSourceCountsTable is available since Delft-FEWS release 2011.01. A FlagSourceCountsTable displays counts of flag sources depending on the flag sources of the values in a time series within a given time period. The flag source for a value contains the reason why that value got a certain flag. For example if a value was rejected by a "hard max" validation rule, then it gets flag unreliable and flag source "hard max".
Example of a flagSourceCountsTable
Declarations section
In the declaration section the layout of the table needs to be defined in a flagSourceCountsTableFormat.
The following options are available:
- id: identifier of this table format.
- tableStyle: The tableStyle to use for this table. The available tableStyles are defined in the report tables .css file.
- scrollableTable: Use this to split the table into two parts, one for the header row(s) and one for the data rows. The data row part refers to the tableStyle for this table with "_scrollable" appended. This can be used to make the data rows scrollable while the header row(s) remain fixed. For this to work the referred style needs to be defined in the report tables .css file.
Configuration example:
<flagSourceCountsTableFormat id="flagSourceCountsTableFormat"> <tableStyle>tableStyle1</tableStyle> </flagSourceCountsTableFormat>
Report section
In the reports section define a flagSourceCountsTable.
The following options are available:
- id: Identifier for this FlagSourceCountsTable that is used in the report template html file in the table tag (e.g: $TABLE(table1)$).
- formatId: The id of the FlagSourceCountsTableFormat to use for this FlagSourceCountsTable.
- inputVariableId: The id of an inputVariable that is defined at the start of this report. The time series of this inputVariable is used for this table. This table shows for each validation rule (hard max, hard min, rate of change, etc.) the number of values that were rejected because of that validation rule. This uses only the data within the relativeViewPeriod that is defined for the time series in the timeSeriesSet. If the timeSeriesSet contains multiple time series (e.g. a locationSet), then an error message is given.
Configuration example:
<flagSourceCountsTable id="flagSourceCountsTable1" formatId="flagSourceCountsTableFormat"> <inputVariableId>Cowbeech</inputVariableId> </flagSourceCountsTable>
maximumStatusTable
A maximumStatusTable indicates, by colouring, when certain threshold levels are crossed. In this type of table, the rows should be defined individually and can contain more than one series. The boolean value 'mergLocation' plays an important role in combining the locations or treat them individually.
Figure 102 Example of a maximumStatusTable (NE Region)
Declarations section
In the declaration sections the layout of the table needs to be defined.
Figure 103 Declaration of maximumStatusTable
The following elements needs to be defined:
- tableStyle: a choice of tableStyle which can be influenced by using the corresponding classes in a cascading style sheet. Choices are tableStyle1 to tableStyle10;
- id: unique identifier (as reference to this table);
- mainHeaderText: a textual string which is displayed in the table header;
- timeStepsInTable: integer number of timesteps to be displayed in the table. This should be derived from the relativeViewPeriod of the corresponding timeSeries to add:
- timeStepsAggregation: integer number of timesteps to be aggregated (=taken together). Worst status is being displayed.
- timeHeaderInterval: integer number for aggregating the headers of the cells or not. Number '1' means 'no aggregation' so every column has got its own header.
- timeHeaderDisplayMinutes: boolean value for having the minutes displayed;
- colWidth: integer value for the width of the cells;
- showAsSingleColumn: boolean value for displaying the timeseries into one column only (true). If set to 'true' the last value of the timeseries is considered.
Reports Section
In the report itself the necessary timeseries needs to be assigned to the table.
Figure 104 Declaration of a maximumStatusTable in a report
The following elements need to be defined:
- id: identifier to the template tag (in this case: $TABLE(table1)$);
- formatId: reference to the format of this table (to one of the maximumStatusTables in the declarations section);
- mergeLocations: boolean indicator. True means: treat all locations of mentioned timeseries together for combined assessment. False means: extract individual timeseries so that every row indicates one location (timeseries);
- table: add individual maximumStatusTables here for a correct visualisation (see detailed explanation: 'two tables into one'). In most cases 2: first for observed values, second for forecast table.
For each table:
- formatId: reference to the format of this table (to one of the maximumStatusTables in the declarations section);
- id: identifier (used for comments only)
- mergeLocations: boolean indicator. True means: treat all locations of mentioned timeseries together for combined assessment. False means: extract individual timeseries so that every row indicates one location (timeseries);
- tableRow: (1 or more)
o formatId: reference to the thresholdsCrossingsTable format;
o id: identifier (mainly for own use/comment);
o timeSeries: (1 or more) - mapId: reference to a valueAttributeMap;
- Text: reference to an inputVariable (declared in the report or in the declarations section).
Detailed Explanation: Two tables into one
In fact, the maximumStatusTable is designed as visualised below. To create a nicely aligned table the 'two timeseries tables' (the one with the 'observed' values and the one with the forecast series) are put in individual cells of the outer table. So the outer table only consist of two cells. The left cell contains the observed table, the right cell contains the forecast table. The outer table itself needs to be declared as well!! The report declaration (see above) can be inspected to see this one in practice.
Detailed Explanation: Wide variation of tables
The variation for displaying maximumStatus information is wide. The combination of relativeViewPeriod (length of forecast series), timestep and the desire to aggregate timesteps can all be implemented. The calculation should be correct. If not, several messages will be shown.
Some examples
Source: 12 hrs of 15min data
Display: maximumStatus with 15 minute data, time header by the hour (with minutes)
Configuration
 |
value |
explanation |
timeStepsInTable |
48 |
(12*4=48 timesteps) |
timeStepsAggregation |
1 |
each column represent 1 timestep |
timeHeaderInterval |
4 |
4 columns have a merged header (hour) |
timeHeaderDisplayMinutes |
true |
minute indication |
Result: table with 48 time columns with 12 aggregated headers visualising the hour with a minute indication (like in first figure of this section)
Source: 6 hrs of 15min data
Display: maximumStatus with hourly data (no minute indication)
Configuration
 |
value |
explanation |
timeStepsInTable |
24 |
(6*4=24 timesteps) |
timeStepsAggregation |
4 |
4*15min aggregate to 1 hour |
timeHeaderInterval |
1 |
each hour 'column' has its own header |
timeHeaderDisplayMinutes |
false |
no minute indication in header |
Result: table with 6 (time) columns indicating the 'worst' status of that hour.
Example thresholdsCrossingsTable/maximumStatusTable
In a configuration the following timeSeries/InputVariables exist:
Name |
Parameter |
LocationSet |
Locations |
Catchment1_Waterlevel_Obs |
H.obs |
Catchment1_Locs |
Loc1 |
Catchment1_Waterlevel_For |
H.simulated |
Catchment1_Locs |
Loc1 |
Catchment2_Waterlevel_Obs |
H.obs |
Catchment2_Locs |
Loc4 |
Catchment2_Waterlevel_For |
H.simulated |
Catchment2_Locs |
Loc4 |
The geographical hierarchy is that Area 1 contains 2 Catchments (Catchment1 and Catchment2)
The Region overview should be configured that all catchments belonging to that area are 'put' into one row which is describing the status of that area. This is valid for both the observed as the forecast timeseries. The 'mergeLocations' variable should be put to 'true' because all locations should be merged (combined).
The Area overview should be configured in such way that all catchments are in separate rows. This is valid for both the observed as the forecast timeseries. The 'mergeLocations' variable should be put to 'true' because all locations should be merged (combined).
The Catchment overview forms the exception here. With mergeLocations set to 'False', the corresponding locationSet is extracted into the individual locations and so every location has got its own row.
For the two tables for which this is valid, the last example does not give much additional value for a thresholdsCrossingsTable. Then each row (which is equal to one locatation) will have a '1' in one of the cells. A maximumStatusTable supplies more value because it will indicate when this (maximum) threshold will be reached.
See below mentioned (simplified) figures.
mergedPrecipitationTable
A mergedPrecipitationTable contains both observed rainfall as well as forecast rainfall, preferably in P.merged timeseries. Data can be visualised in configurable time intervals compared to T0 and will appear in separate columns. Additionally, a single column can be added to visualise any parameter (e.g. CWI). An example can be found below (without extra column). In the example below, actually two tables are plotted next to each other. The left table (with names) contains the historical date. The one on the right hand side contains the forecast timeseries and has no name column. A table like this has two header rows to be defined by the user.
Figure 105 Example of a mergedPrecipitationTable (NE Region)
Declaration Section
In the declaration section the layout of the table needs to be defined.
Figure 106 mergedPrecipitationTable configuration in the declarations section
The following elements need to be defined.
- id: unique identifier (as reference to this table);
- tableStyle: a choice of tableStyle which can be influenced by using the corresponding classes in a cascading style sheet. Choices are tableStyle1 to tableStyle10;
- headerRow1Text: text to be displayed in table header (first line);
- headerRow2Text: text to be displayed in table header (second line);
- dataColumns: definition of individual column with a time interval for aggregating precipitation. Each column should contain:
- columnHeader: text to be displayed in column header (first line);
- unitHeader text to be displayed in column header (second line);
- relativeViewPeriod: period to aggregate the data;
- unit: unit to aggregate. Choices: day/hour/minute/second/week
- start: start of interval (in time unit) compared to T0;
- end: end of interval (in time unit) compared to T0;
- nameColumnWidth: integer value of width of the name column (most left column (if present));
- dataColumnWidth: integer value of width of the data columns;
- suppressNameColumn boolean value for setting the name column visible or not. This column, when visible, is filled with the (full) location name of the timeseries which is visualised in this table.
Report section
In the report section the content (timeseries) are 'attached' to this table.
Figure 107 mergedPrecipitationTable in the report section.
The mergedPrecipitationTable in the report section is (very) easy to define. The rule of the 'outer table' is valid here as well. To align the historical and the forecast table nicely, the outer table contains both P.merged tables.
The following elements need to be defined:
- id: identifier (reference to the template tag)
- formatId: reference to the format of this table (to one of the mergedPrecipitationTables in the declarations section);
- table:
- id: identifier (used for comments only)
- formatId: reference to the format of this table (to one of the mergedPrecipitationTables in the declarations section)
- timeSeries: reference to an inputVariable.
SystemStatusTables
SystemStatusTables display information about the status and behaviour of the FEWS system itself (like in the System monitor).
SystemStatysTables come in different types:
- liveSystemStatus: information about live system: MC and FSS('s);
- exportStatus: information about exported files/reports;
- importStatus: information about files imported;
- scheduledWorkflowStatus: information about (next) scheduled workflows;
- completedWorkflowStatus: information about number of workflows completed in last 24 hrs.
- currentForecastStatus: information about which workflows are set to CURRENT;
- logMessageListing list of logmessages (based on a query)
- forecastHistory: historic overview of forecasts.
In most tables it is possible to add 'benchmark' data to compare the actual and the desired/required situation. The configuration of such a table requires the definition of this benchmark value. Such a table contains a 'Item', "Benchmark' and a 'Status' column.
Besides a 'benchmark' (something to compare the actual status with) additional fields (columns from the database) can be included in the table. A specific boolean value (showOutputFieldsOnly) can be used to either include or exclude these benchmark columns. In most tables this boolean is set to 'False' because most tables contain both status information as well as additional (meta)information. See figure below.
Figure 108 A systemStatusTable is divided into a status part and an extraOutputFields part.
Each type will be briefly explained:
liveSystemStatus
A liveSystemStatusTable displays information about the status and behaviour of the live system components (MasterController and Forecasting Shell Server(s))
Figure 109 Example of a liveSystemStatus table (NE Region)
Declarations Section
Figure 110 Example of the configuration of a liveSystemStatus table in the declarations section
The following elements need to be defined:
- tableStyle: a choice of tableStyle which can be influenced by using the corresponding classes in a cascading style sheet. Choices are tableStyle1 to tableStyle10;
- id: unique identifier (as reference to this table);
- statusTableSubType: Choice for one of the subtypes of systemStatusTables: Choices are: liveSystemStatus, exportStatus, importStatus, scheduledWorkflowStatus, completedWorkflowStatus, currentForecastStatus, logMessageListing, forecastHistory;
- tableTitle: a text for a title for this table;
- headerRows: integer value for the number of header rows;
- itemHeader: header text for the 'Item' column;
- benchmarkHeader: header text for the 'Benchmark' column;
- statusHeader: header text for the 'Status' column;
- statusHeaderSplit: value indicating the number of header rows in the status column.
- showOutputFieldsOnly: boolean value for displaying the outputfields only.
Report Section
Figure 111 Example of the configuration of a liveSystemStatus table in the report section
The following elements need to be defined:
- id: identifier to the template tag ($TABLE(liveSystemStatusTable)$);
- formatId: reference to the format of this type of systemStatus table in the declarations section);
- mcStatusQuery:
- itemTextStatus: left blank will display MC name;
- benchmarkTextStatus: benchmark text;
- fssStatusQuery:
- itemTextStatus: left blank will display FSS name;
- benchmarkTextStatus: benchmark text for status;
- itemTextSize: text for size query;
- benchmarkTextStatus: benchmark text for size
- singleRecordQuery
- tableName: tablename in local datastore;
- inputfield reference to column in table (to query):
- recordId reference to record in table:
- statusField reference to column in table (to display):
- itemText: text to be displayed (can be empty)
- benchmarkText: benchmark text
exportStatus table
A exportStatus table displays information about the status of a number export features of the system, such as:
- last occurence of a (export) workflow (by workflowStatusQuery);
- nr of files present in an export directory (by logMessageParseQuery);
- transfer speed of exporting files (by logMessageParseQuery);
Figure 112 Example of an exportStatus table (NE Region)
Declarations Section
Figure 113 Example of the configuration of an exportStatus table in the declarations section
The following elements need to be defined:
- tableStyle: a choice of tableStyle which can be influenced by using the corresponding classes in a cascading style sheet. Choices are tableStyle1 to tableStyle10;
- id: unique identifier (as reference to this table);
- statusTableSubType: Choice for one of the subtypes of systemStatusTables: Choices are: liveSystemStatus, exportStatus, importStatus, scheduledWorkflowStatus, completedWorkflowStatus, currentForecastStatus, logMessageListing, forecastHistory;
- tableTitle: a text for a title for this table;
- headerRows: integer value for the number of header rows;
- itemHeader: header text for the 'Item' column;
- benchmarkHeader: header text for the 'Benchmark' column;
- statusHeader: header text for the 'Status' column;
- statusHeaderSplit: value indicating the number of header rows in the status column.
- showOutputFieldsOnly: boolean value for displaying the outputfields only.
Report Section
Figure 114 Example of the configuration of an exportStatus table in the report section
This table is constructed using two types of queries:
- workflowStatusQuery;
- logMessageParseQuery
The following elements need to be defined:
- id: identifier to the template tag ($TABLE(liveSystemStatusTable)$);
- formatId: reference to the format of this type of systemStatus table in the declarations section);
- workflowStatusQuery:
- workflowId:
- itemText: text in 'Item' column;
- benchmarkTextStatus: text in the 'Benchmark' column;
- selectCompletedWorkflowsOnly: boolean indicating completed or scheduled workflows;
- statusField: field from the taskRunsCompletions table indicating whether a workflow has been completed or not;
- logMessageParseQuery
- itemText: text in 'Item' column;
- benchmarkTextStatus: text in the 'Benchmark' column;
- logEntryEventCode: eventcode to filter on;
- keyword: typical/unique keyword to parse for;
- displayWord: integer value for the word to display (n-th word in this log message);
- workflowStatusQuery:
importStatus table
An importStatus table displays information about the datafeeds which have been imported, how many of them were read and how many failed to be imported. The frequency of the files imported can be (visually) compared with a benchmark figure. See below for an example.
Figure 115 Example of an importStatus table (NE Region)
Declarations Section
Figure 116 Example of the configuration of an importStatus table in the declarations section
The following elements need to be defined:
- tableStyle: a choice of tableStyle which can be influenced by using the corresponding classes in a cascading style sheet. Choices are tableStyle1 to tableStyle10;
- id: unique identifier (as reference to this table);
- statusTableSubType: Choice for one of the subtypes of systemStatusTables: Choices are: liveSystemStatus, exportStatus, importStatus, scheduledWorkflowStatus, completedWorkflowStatus, currentForecastStatus, logMessageListing, forecastHistory;
- tableTitle: a text for a title for this table;
- headerRows: integer value for the number of header rows;
- itemHeader: header text for the 'Item' column;
- benchmarkHeader: header text for the 'Benchmark' column;
- statusHeader: header text for the 'Status' column;
- statusHeaderSplit: value indicating the number of header rows in the status column.
- extraOutputFieldHeader: Additional Field definition specifically for import related topics. Recommended fields are:
- Last file imported
- Nr. of files read
- Nr. of files failed
- showOutputFieldsOnly: boolean value for displaying the outputfields only.
Remark: when defining extraOutputFieldHeaders it is important to maintain the same order in the declarations sections (definition of the fields) and in the report section (referencing the content) otherwise the header and the content will not correspond. |
Report Section
Figure 117 Example of the configuration of an importStatus table in the report section
The following elements need to be defined:
- id: identifier to the template tag ($TABLE(importStatusTable)$);
- formatId: reference to the format of this type of systemStatus table in the declarations section);
- datafeedStatusQuery
- BenchmarkText
- id: textual string contain the name of the datafeed
- text: textual string indicating the benchmark for this datafeed
- statusField: textual reference to main field in the database table ImportStatus, lastImportTime
- BenchmarkText
- extraOutputField
- Text: textual references to the fields in the database table ImportStatus to fill the defined ExtraOutputFields (Declaration section). In this case it is recommended to add here:
- lastFileImported
- filesReadCount
- filesFailedCount
- Text: textual references to the fields in the database table ImportStatus to fill the defined ExtraOutputFields (Declaration section). In this case it is recommended to add here:
scheduledWorkflowStatus table
A scheduledWorkflowStatus table displays the workflows which are scheduled together with their repeat time and next due time. The figure below illustrates this.
Figure 118 Example of a scheduledworkflowStatus table (NE Region)
Declarations Section
Figure 119 Example of the configuration of a completedWorkflowStatus table in the declarations section
The following elements need to be defined:
- tableStyle: a choice of tableStyle which can be influenced by using the corresponding classes in a cascading style sheet. Choices are tableStyle1 to tableStyle10;
- id: unique identifier (as reference to this table);
- statusTableSubType: Choice for one of the subtypes of systemStatusTables: Choices are: liveSystemStatus, exportStatus, importStatus, scheduledWorkflowStatus, completedWorkflowStatus, currentForecastStatus, logMessageListing, forecastHistory;
- tableTitle: a text for a title for this table;
- headerRows: integer value for the number of header rows;
- itemHeader: header text for the 'Item' column;
- benchmarkHeader: header text for the 'Benchmark' column;
- statusHeader: header text for the 'Status' column;
- statusHeaderSplit: value indicating the number of header rows in the status column.
- extraOutputFieldHeader: Additional Field(s) definition specifically for scheduled workflow related topics. Recommended fields are:
- Workflows
- Description
- MC Id
- Repeat Time
- Next Due Time
- showOutputFieldsOnly: boolean value for displaying the outputfields only.
Since this table is not referring to a benchmark (it is just reading the configuration) the value for showOutputFieldsOnly is set to true. Only these fields are displayed.
remark: One reference to an existing workflow is sufficient to extract all scheduled workflows out of the database, that's why it seems that there is only one table row configured here. In fact, this table will be filled with ALL scheduled workflows when configured as above. |
Report Section
Figure 120 Example of the configuration of a scheduledWorkflowStatus table in the report section
The following elements need to be defined:
- id: identifier to the template tag ($TABLE(scheduledWorkflowTable)$);
- formatId: reference to the format of this type of systemStatus table in the declarations section);
- workflowStatusQuery
- workflowId: textual reference (case-sensitive!) to an existing workflow in the configuration
- itemText: text in the 'Item' Column (can be left blank in case of this statusTableSubType)
- benchmarkText: text in the 'Benchmark' column (can be left blank in case of this statusTableSubType)
- selectCompletedWorkflowsOnly: boolean variable: 'true' refers to query completed workflows (see next table subtype) and 'false' refers to query scheduled workflows (this type)
- statusField: textual reference to the field in the database table Tasks. In this case taskStatus. In case of scheduled workflows the column 'taskRepeatTime' contains a integer value indicating that it is a repeating activity (workflow)
- extraOutputField
- Text: textual references to the fields in the database table ImportStatus to fill the defined ExtraOutputFields (Declaration section). In this case it is recommended to add here:
- workflowId
- description
- ownerMcId
- taskRepeatTime
- taskPendingSinceTime
- Text: textual references to the fields in the database table ImportStatus to fill the defined ExtraOutputFields (Declaration section). In this case it is recommended to add here:
completedWorkflowStatus table
A completedWorkflowStatus table contains an overview of all workflows carried out in the last 24 hours. An example is given below.
Figure 121 Example of a completedworkflowStatus table (NE Region)
Declarations Section
Figure 122 Example of the configuration of a completedWorkflowStatus table in the declarations section
The following elements need to be defined:
- tableStyle: a choice of tableStyle which can be influenced by using the corresponding classes in a cascading style sheet. Choices are tableStyle1 to tableStyle10;
- id: unique identifier (as reference to this table);
- statusTableSubType: Choice for one of the subtypes of systemStatusTables: Choices are: liveSystemStatus, exportStatus, importStatus, scheduledWorkflowStatus, completedWorkflowStatus, currentForecastStatus, logMessageListing, forecastHistory;
- tableTitle: a text for a title for this table;
- headerRows: integer value for the number of header rows;
- itemHeader: header text for the 'Item' column;
- benchmarkHeader: header text for the 'Benchmark' column;
- statusHeader: header text for the 'Status' column;
- statusHeaderSplit: value indicating the number of header rows in the status column.
- statusSubHeader: Additional Field(s) definition specifically for completed workflow related topics. Recommended fields are:
- Nr. of Runs
- Nr. Failed
- showOutputFieldsOnly: boolean value for displaying the outputfields only.
Report Section
Figure 123 Example of the configuration of a completedWorkflowStatus table in the report section
The following elements need to be defined:
- id: identifier to the template tag ($TABLE(scheduledWorkflowTable)$);
- formatId: reference to the format of this type of systemStatus table in the declarations section);
- workflowStatusQuery
- workflowId: textual reference (case-sensitive!) to an existing workflow in the configuration
- itemText: text in the 'Item' Column (can be left blank in case of this statusTableSubType)
- benchmarkText: text in the 'Benchmark' column (can be left blank in case of this statusTableSubType)
- selectCompletedWorkflowsOnly: boolean variable: 'true' refers to query completed workflows (this type) and 'false' refers to query scheduled workflows (see previous table subtype)
- statusField: textual reference to the field in the database table TaskRuns. In this case taskRunStatus.
currentForecastStatus table
The currentForecastStatus table gives an overview of which workflows are set to CURRENT. These mentioned workflows in this tables are the same as the marked with a green icon the System Monitor of the Operator Client. An example of this table is given below.
Figure 124 Example of a currentForecastStatus table (NE Region)
Declarations Section
Figure 125 Example of the configuration of a currentForecast table in the declarations section
The following elements need to be defined:
- tableStyle: a choice of tableStyle which can be influenced by using the corresponding classes in a cascading style sheet. Choices are tableStyle1 to tableStyle10;
- id: unique identifier (as reference to this table);
- statusTableSubType: Choice for one of the subtypes of systemStatusTables: Choices are: liveSystemStatus, exportStatus, importStatus, scheduledWorkflowStatus, completedWorkflowStatus, currentForecastStatus, logMessageListing, forecastHistory;
- tableTitle: a text for a title for this table;
- headerRows: integer value for the number of header rows;
- itemHeader: header text for the 'Item' column;
- benchmarkHeader: header text for the 'Benchmark' column;
- statusHeader: header text for the 'Status' column;
- statusHeaderSplit: value indicating the number of header rows in the status column.
- extraOutputFieldHeader: Additional Field(s) definition specifically for scheduled workflow related topics. Recommended fields are:
- T0
- What-if Scenario
- Description
- FDO
- showOutputFieldsOnly: boolean value for displaying the outputfields only.
Report Section
Figure 126 Example of the configuration of a currentForecastStatus table in the report section
The following elements need to be defined:
- id: identifier to the template tag ($TABLE(scheduledWorkflowTable)$);
- formatId: reference to the format of this type of systemStatus table in the declarations section);
- currentForecastQuery
- workflowId: textual reference (case-sensitive!) to an existing workflow in the configuration
- itemText: text in the 'Item' Column
- benchmarkText: text in the 'Benchmark' column
- statusField: textual reference: should be "dispatchTime"!
- extraOutputField: textual references to specific TaskRun details (see figure above):
- T0
- whatIfId
- description
- FDO
- extraOutputField: textual references to specific TaskRun details (see figure above):
logMessageListing table
A logMessageListing table contains logmessages which are available in the Log Browser tab in the System Monitor of the Operator Client. Log messages of a specific type can be queried. By making use of a correct reference to the cascading style sheet this table can be set to 'scrollable' An example of such a table is given in the figure below.
Figure 127 Example of a logMessageListing table (NE Region)
Declarations Section
Figure 128 Example of the configuration of a logMessageListing table in the declarations section
The following elements need to be defined:
- tableStyle: a choice of tableStyle which can be influenced by using the corresponding classes in a cascading style sheet. Choices are tableStyle1 to tableStyle10;
- id: unique identifier (as reference to this table);
- statusTableSubType: Choice for one of the subtypes of systemStatusTables: Choices are: liveSystemStatus, exportStatus, importStatus, scheduledWorkflowStatus, completedWorkflowStatus, currentForecastStatus, logMessageListing, forecastHistory;
- tableTitle: a text for a title for this table;
- headerRows: integer value for the number of header rows;
- itemHeader: header text for the 'Item' column;
- benchmarkHeader: header text for the 'Benchmark' column;
- statusHeader: header text for the 'Status' column;
- statusHeaderSplit: value indicating the number of header rows in the status column.
- extraOutputFieldHeader: Additional Field(s) definition specifically for scheduled workflow related topics. Recommended fields are:
- Log Creation Time
- Log Message
- TaskrunId
- showOutputFieldsOnly: boolean value for displaying the outputfields only. This tableType requires a 'true' here.
Report Section
Figure 129 Example of the configuration of a currentForecastStatus table in the report section
The following elements need to be defined:
- id: identifier to the template tag ($TABLE(scheduledWorkflowTable)$);
- formatId: reference to the format of this type of systemStatus table in the declarations section);
- logMessageQuery
- logLevelFilter: textual (case-sensitive) reference to one of the log message levels. Choices are: INFO, WARN, ERROR, FATAL.
- logEntryEventCode: textual (case-sensitive) reference to a specific type of log message. The eventCode is a 'filter' to retrieve certain types or error messages. In this case the "TaksRun.Completed " eventCode has been used.
- statusField: textual reference to the correct field in the LogEntries table in the database (="logLevel");
- extraOutputField: textual reference to other fields in the LogEntries table which fill the corresponding columns. In this case 3 additional columns need to be filled with information:
- logCreationTime (creation time of message)
- logMessage (content of the log message itself)
- taskRunId (reference to the taskrun that throwed this message)
forecastHistory table
A forecastHistory table provides an overview of all most recent forecasts carried out. The number of foracast to include is configurable. An example of such a table is given below.
Figure 130 Example of a forecastHistory table (NE Region)
Declarations Section
Figure 131 Example of the configuration of a forecastHistory table in the declarations section
The following elements need to be defined:
- tableStyle: a choice of tableStyle which can be influenced by using the corresponding classes in a cascading style sheet. Choices are tableStyle1 to tableStyle10;
- id: unique identifier (as reference to this table);
- statusTableSubType: Choice for one of the subtypes of systemStatusTables: Choices are: liveSystemStatus, exportStatus, importStatus, scheduledWorkflowStatus, completedWorkflowStatus, currentForecastStatus, logMessageListing, forecastHistory;
- tableTitle: a text for a title for this table;
- headerRows: integer value for the number of header rows;
- itemHeader: header text for the 'Item' column;
- benchmarkHeader: header text for the 'Benchmark' column;
- statusHeader: header text for the 'Status' column;
- statusHeaderSplit: value indicating the number of header rows in the status column.
- extraOutputFieldHeader: Additional Field(s) definition specifically for scheduled workflow related topics. Recommended fields are:
- Dispatch Time
- Completion Time
- T0
- Workflow
- What-if Scenario
- Description
- FDO
- showOutputFieldsOnly: boolean value for displaying the outputfields only. This tableType requires a 'true' here.
Report Section
Figure 132 Example of the configuration of a forecastHistory table in the report section
The following elements need to be defined:
- id: identifier to the template tag ($TABLE(scheduledWorkflowTable)$);
- formatId: reference to the format of this type of systemStatus table in the declarations section);
- forecastHistoryQuery
- nrOfForecasts: integer value referring to the number of most recent forecast to include in this table;
- statusField: textual reference to the field in the TaskRuns table of the database
- extraOutputFields: textual references to required fields
- dispatchTime
- completionTime
- T0
- workflowId
- whatIfId
- description
- fdoName
- mcId
- fssId
AnimatedGIF
An animated GIF is an animation of a grid timeserie in a GIF image format. The advantage of this format is that it can easily be added to HTML pages, without the need to embed extra controls (like with AVI).
Reportsection
The following elements need to be defined:
- id
- name (optional, at this moment it is not possible to define the filename)
- timeSeriesSet: Definition of the timeserieset to be animated
- movieFrameDurationMillis: defines the speed of the animation
- barLegend: from 2012.02 it is possible to display a bar legend in the animation
- classBreaks: see Grid Display
- geomap: see Grid Display
- width: the width of the image in pixels
- height: the height of the image in pixels
To export a report see the reportExport module instance
Schematic Status Display Reports
Since 2013_01 it is possible to create reports of the Schematic Status Display in the form of animations in the formats Avi and animated gif as well as snapshots in the form of Png files and Svg files.
For this purpose there will probably already be some Schematic Status Display configuration in the DisplayConfigFiles of the configuration. In order to create a report of this Schematic Status Display, most elements of this configuration can be copied manually to the reports configuration file.
An example Schematic status Display that contains the following configuration,
<dateFormat id="DF1"> <timeZone> <timeZoneName>CET</timeZoneName> </timeZone> <dateTimePattern>dd-MM-yyyy</dateTimePattern> </dateFormat> <numberFormat id="NF1"> <pattern>{0,number,##0.00}</pattern> </numberFormat>
must be transferred to the report declarations. The definitions of the date format and number format cannot be copied directly to the report configuration since they have a slightly different format.
<?xml version="1.0" encoding="UTF-8"?> <reports xmlns="http://www.wldelft.nl/fews" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.wldelft.nl/fews http://fews.wldelft.nl/schemas/version1.0/reports.xsd" version="1.0"> <declarations> <defineGlobal id="ForecastingRegion">IWP-Twentekanalen</defineGlobal> <dateFormat id="DF1"> <timeZone> <timeZoneName>CET</timeZoneName> </timeZone> <pattern>dd-MM-yyyy</pattern> </dateFormat> <numberFormat id="NF1">{0,number,##0.00}</numberFormat> ... </declarations> <report> ... // Add Ssd report elements here for generating Avi, Gif, Png or Svg. ... </report> </reports>
When first configuring a Schematic Status Display report, the scadaPanel section of the Schematic Status Display configuration can be copied directly to the Schematic Status Display Reports configuration. For Svg output the interactive sections will not be supported, so it is recommended to remove these.
Schematic Status Display - Avi
<schematicStatusDisplayPanelAvi id="ssdAvi"> <scadaPanel id="TK" name="Twentekanalen 10 min"> <svgFile>Twentekanalen.svg</svgFile> <nodeId>Twentekanalen Hydro</nodeId> ... </scadaPanel> <width>1024</width> <height>800</height> <relativePeriod unit="hour" start="-20" end="4"/> <timeStep unit="second" multiplier="300"/> <movieFrameDurationMillis>200</movieFrameDurationMillis> <fileName>SSD_test.avi</fileName> </schematicStatusDisplayPanelAvi>
Schematic Status Display - Animated Gif
Schematic Status Display - Png
<schematicStatusDisplayPanelAnimatedGif id="ssdAnimatedGif"> <scadaPanel id="TK" name="Twentekanalen 10 min"> <svgFile>Twentekanalen.svg</svgFile> <nodeId>Twentekanalen Hydro</nodeId> ... </scadaPanel> <width>1024</width> <height>800</height> <relativePeriod unit="hour" start="-20" end="4"/> <timeStep unit="second" multiplier="300"/> <movieFrameDurationMillis>200</movieFrameDurationMillis> <fileName>SSD_test.gif</fileName> </schematicStatusDisplayPanelAnimatedGif>
Sample demonstrating use of transformations:
<schematicStatusDisplayPanelSnapshotsPng> <variable> ... </variable> <transformation id="UserSimpleTransformation"> <user> <simple> <expression>Waterstanden_10min * 100</expression> <outputVariable> <variableId>Waterstanden_10min_times_100</variableId> </outputVariable> </simple> </user> </transformation> <scadaPanel id="TK" name="Twentekanalen 10 min"> .... </scadaPanel > <width>1024</width> <height>800</height> <snapshot id="ssd1"> <relativeTime unit="hour" value="-4"/> <fileName>SSD_test1.png</fileName> </snapshot> <snapshot id="ssd2"> <relativeTime unit="hour" value="-3"/> <fileName>SSD_test2.png</fileName> </snapshot> </schematicStatusDisplayPanelSnapshotsPng>
Schematic Status Display - Svg
The interactive parts of the Schematic Status Display are not supported when exported in the report and it is recommended to remove these sections when appropriate.
<schematicStatusDisplayPanelSnapshotsSvg> <scadaPanel id="TK" name="Twentekanalen 10 min"> .... </scadaPanel > <width>1024</width> <height>800</height> <snapshot id="ssd1"> <relativeTime unit="hour" value="-4"/> <fileName>SSD_test4.svg</fileName> </snapshot> <snapshot id="ssd2"> <relativeTime unit="hour" value="-3"/> <fileName>SSD_test5.svg</fileName> </snapshot> </schematicStatusDisplayPanelSnapshotsSvg>