1.1
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
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 indexes, a user can never see what is happening in his coastal system. The report component will therefore also be used to interpret the indexes and transform these into information that a user can understand. The ValueAttributeMaps (see Regional Configuration) define how these indeces 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 to defined declatations to be sued 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).
1.2 Figure 89 Elements of the Reports configuration
1.2.1
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
1.2.2 h5. 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.
1.2.3 Figure 90 Elements of the declarations configuration
1.2.4
1.2.5 h5. 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.
Wiki Markup |
---|
Related TAG: $DEFINITION(definitionId)$
1.2.6 \\
1.2.7 h5. \[item\]Format
Formatting instructions for a specific item in the report. See Appendix D for details.
1.2.8 \\
1.2.9 h5. templateDir
Root directory of the directory containing report templates.
1.2.10 \\
1.2.11 h5. 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
1.2.12
1.2.13 h5. reportRootsSubDir
Root directory to which the current reports are to be exported. This directory is relative to the reportsRootsDir
1.2.14
1.2.15 h5. 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.
1.2.16
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
1.2.17 h5. report
Root element for defining the data to be included in the report.
1.2.18 Figure 91 Elements of the Report configuration
1.2.19
1.2.20 h5. 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 definint an inputVariable element.
1.2.21
1.2.22 h5. 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)$
1.2.23
1.2.24 h5. 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)$
1.2.25
1.2.26 h5. 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)$
1.2.27
1.2.28 h5. 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)$
1.2.29
1.2.30 h5. Status
The Status element links a Status ID that is referenced in the STATUS TAG to a Status Format ID.
Related TAG: $STATUS(statusId)$
1.2.31
1.2.32 h5. Template
Template file name to be used for the report.
1.2.33
1.2.34 h5. OutputSubDir
Output Sub Directory for the report
1.2.35
1.2.36 h5. OutputFileName
Report Filename.
1.2.37
1.2.38 h5. 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)$
1.2.39
Anchor | ||||
---|---|---|---|---|
|
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 (indivudual) *.png files.
1.2.40
1.2.41 Figure 92 Example of a chart (*.png file)
1.2.42
1.2.43
1.2.44 h5. 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)$
1.2.45
1.2.46 h5. Configuration aspects
Chart should be configured according the following schema definition (reports.xsd)
1.2.47
1.2.48
1.2.49 Figure 93 Chart definition according the ChartComplexType (sharedTypes.xsd).
1.2.50
For adding a chart to a report the following aspects are important to configure:
- Chart attributes;
- Chart timeseries;
1.2.51
1.2.52 h5. 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;
1.2.53
1.2.54 h5. Chart timeseries
To display lines, dots etc. of a certain timeseries, the reference to this timeseries (variableId) should be mentioned.
1.2.55
1.2.56 Figure 94 chart declaration in the report section
1.2.57
Anchor | ||||
---|---|---|---|---|
|
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.
1.2.58
1.2.59 h5. 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)$
Wiki Markup |
---|
1.2.60 \\
1.2.61 h5. 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: |
Wiki Markup Copy current map to a .png file (\[F12\]+ L);
Wiki Markup Copy current map extent to the clipboard (\[F12\]+ K);
Wiki Markup |
---|
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. |
Wiki Markup |
---|
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. |
1.2.62
1.2.63 h5. Configuring a summary
1.2.64 Declaration section
1.2.65
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 coordintes;
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;
1.2.66
1.2.67
1.2.68 Figure 95 Summaryformat in the declarations section
1.2.69
1.2.70
1.2.71 h5. 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.
Wiki Markup 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:
1.2.72 | Position | Type | Variable |
1.2.73 | 0 | number | Absolute x position of map image. |
1.2.74 | 1 | number | Absolute y position of map image. |
1.2.75 | 2 | number | Image width. |
1.2.76 | 3 | number | Image height |
1.2.77 | 4 | number | Image filename. |
1.2.78 | 5
(optional) | number | Reference to a clickable map (#clickmap by default) |
1.2.79
- 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;
Wiki Markup |
---|
1.2.80 | *Position* | *Type* | *Variable* |
1.2.81 | 0 | number | Absolute x position of status icon. |
1.2.82 | 1 | number | Absolute y position of status icon. |
1.2.83 | 2 | string | Image filename. |
1.2.84 | 3 | string | Status description. |
1.2.85 | 4 | string | Location name. |
1.2.86 | 5\\ (optional) | string\\ | Html-link for opening a individual html page (forecastlocation.html) |
1.2.87
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). |
1.2.88
1.2.89 h5. Use of optional settings in mapFormat and overlayFormat
In both formats, an optional item can be specified.
1.2.90
1.2.91 h5. 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.
1.2.92
1.2.93
When adding the string "usemap="{5}" to the mapFormat (see above) the outcome in the html page will be (printed in bold).
Wiki Markup |
---|
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. |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="8fa158c7-4324-4f10-ba12-030ef559d324"><ac:plain-text-body><![CDATA[ |
| ]]></ac:plain-text-body></ac:structured-macro> |
To avoid hot spots on a map, do not include the "usemap="{5}" in the mapFormat.
1.2.94
1.2.95 h5. 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.
1.2.96
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.
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="fdd5d2d2-1572-4bea-b538-816845ef6d9a"><ac:plain-text-body><![CDATA[ | [!-- 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 --] | ]]></ac:plain-text-body></ac:structured-macro> |
Html result for mapFormat and
1.2.97
1.2.98 h5. Report section
1.2.99 A summary can be added to a report configuration as shown below.
1.2.100
1.2.101
1.2.102 Figure 96 Summary configuration in the reports section
The following elements need to be defined.
1.2.103* Id: identifier referring to the tag in the template. In this case the corresponding template will contain $SUMMARY(statusAreaMap)$
1.2.104* formatId: identifier referring to the unique identifier of this map in the declarations section.
1.2.105* timeSeries: reference to an inputVariable (declared in the report or in the declarations section.
1.2.106* mapId: reference to a valueAttributeMap;
1.2.107
1.2.108
Anchor | ||||
---|---|---|---|---|
|
Tables are available in different types. The similarity between them is that they are referenced with the same template tag.
1.2.109
1.2.110 h5. 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.
1.2.110.1
Anchor | ||||
---|---|---|---|---|
|
The htmlTable is the successor of the table described earlier. The configuration of this htmlTable is easier and more readable.
1.2.110.2
1.2.110.3 h5. 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.
1.2.110.4
1.2.110.5 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";
1.2.110.6
1.2.110.7
1.2.110.8 h5. 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:
1.2.110.9
1.2.110.10 Figure 98 Declaration and reference of a htmlTable in a report
1.2.110.11
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.
1.2.110.12* cellFormat: addition to tableStyleX class for adding specific styles to the content of the cell;
1.2.110.13
Rremark: htmlTables can contain more than one timeseries. By adding different cellFormats to the series (see picture obove) different styles can be attached for display in the table. In this way you can distinguish the two timeseries in the table!
1.2.110.14
1.2.110.15 h5. 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.
1.2.110.16 | class | description | specific for |
1.2.110.17 | _beforeT0 | date/time indication before time zero (TO) of the forecast | time column (most left column) |
1.2.110.18 | _firstAfterT0 | date/time indication of the first occurrence after time zero (T0) of the forecast | time column (most left column) |
1.2.110.19 | _afterT0 | date/time indication after time zero (TO) of the forecast | time column (most left column) |
1.2.110.20 | _data | default indication of data content of a cell | data cells |
1.2.110.21 | _anyString | user defined cellFormat | data cells |
1.2.110.22 | _datamax | addition to current style if value is maximum of that series (_data_datamax or _anyString_datamax) | data cells |
1.2.110.23 | _leftcol | default indication of a row header | |
1.2.110.24 | _header | default indication of a column header | |
1.2.110.25 | _threshold_n | indication of threshold level (n=0,1,2,...) | threshold tables (colouring of backgrounds) |
1.2.110.26
Anchor | ||||
---|---|---|---|---|
|
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' thershold crossings is counted. An example of a thresholdsCrossingsTable is given below.
1.2.110.27
1.2.110.28 Figure 99 Example of a thresholdCrossingTable (NE Region)
1.2.110.29
1.2.110.30
1.2.110.31 h5. Declarations section
In the declaration sections the layout of the table needs to be defined.
1.2.110.32
1.2.110.33 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";
- 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;
1.2.110.34
1.2.110.35
1.2.110.36 h5. Report section
A thresholdsCrossingsTable should be defined in the report as well. E.g. this table needs to be 'filled' with its corresponding timeseries.
1.2.110.37
1.2.110.38 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. By default this This is explained in detail.
1.2.110.39
Anchor | ||||
---|---|---|---|---|
|
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.
1.2.110.40
1.2.110.41 Figure 102 Example of a maximumStatusTable (NE Region)
1.2.110.42
1.2.110.43
1.2.110.44 h5. Declarations section
In the declaration sections the layout of the table needs to be defined.
1.2.110.45
1.2.110.46 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.
1.2.110.47 ++
1.2.110.48
1.2.110.49 h5. Reports Section
In the report itself the necessary timeseries needs to be assigned to the the table.
1.2.110.50
1.2.110.51 Figure 104 Declaration of a maximumStatusTable in a report
1.2.110.52
1.2.110.53 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);
1.2.110.54* 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.
1.2.110.55
1.2.110.56 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.
1.2.110.57
1.2.110.58
1.2.110.59 h5. 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.
1.2.110.60
1.2.110.61
1.2.110.62
1.2.110.63 h5. 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.
1.2.110.64
1.2.110.65 h5. Some examples
1.2.110.66
Source: 12 hrs of 15min data
Display: maximumStatus with 15 minute data, time header by the hour (with minutes)
Configuration
1.2.110.67 | ** | value | explanation |
1.2.110.68 | timeStepsInTable | 48 | (12*4=48 timesteps) |
1.2.110.69 | timeStepsAggregation | 1 | each column represent 1 timestep |
1.2.110.70 | timeHeaderInterval | 4 | 4 columns have a merged header (hour) |
1.2.110.71 | timeHeaderDisplayMinutes | true | minute indication |
1.2.110.72
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
1.2.110.73 | ** | value | explanation |
1.2.110.74 | timeStepsInTable | 24 | (6*4=24 timesteps) |
1.2.110.75 | timeStepsAggregation | 4 | 4*15min aggregate to 1 hour |
1.2.110.76 | timeHeaderInterval | 1 | each hour 'column' has its own header |
1.2.110.77 | timeHeaderDisplayMinutes | false | no minute indication in header |
1.2.110.78
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 shouls 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.
1.2.110.79
1.2.110.80
1.2.110.81
Anchor | ||||
---|---|---|---|---|
|
A mergedPrecipitationTable contains both observerd 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 seperate 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.
1.2.110.82
1.2.110.83 Figure 105 Example of a mergedPrecipitationTable (NE Region)
1.2.110.84
1.2.110.85
1.2.110.86 h5. Declaration Section
In the declaration section the layout of the table needs to be defined.
1.2.110.87
1.2.110.88 Figure 106 mergedPrecipitationTable configuration in the declarations section
1.2.110.89
1.2.110.90 The following elements need to be defined.
1.2.110.91* id: unique identifier (as reference to this table);
1.2.110.92* tableStyle: a choice of tableStyle which can be influenced by using the corresponding classes in a cascading style sheet. Choices are tableStyle1 to tableStyle10;
1.2.110.93* headerRow1Text: text to be displayed in table header (first line);
1.2.110.94* headerRow2Text: text to be displayed in table header (second line);
1.2.110.95* dataColumns: definition of individual column with a time interval for aggregating precipitation. Each column should contain:
1.2.110.96* columnHeader: text to be displayed in column header (first line);
1.2.110.97* unitHeader text to be displayed in column header (second line);
1.2.110.98* relativeViewPeriod: period to aggregate the data;
1.2.110.99* unit: unit to aggregate. Choices: day/hour/minute/second/week
1.2.110.100* start: start of interval (in time unit) compared to T0;
1.2.110.101* end: end of interval (in time unit) compared to T0;
1.2.110.102* nameColumnWidth: integer value of width of the name column (most left column (if present);
1.2.110.103* dataColumnWidth: integer value of width of the data columns;
1.2.110.104* 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.
1.2.110.105
1.2.110.106
1.2.110.107 h5. Report section
In the report section the content (timeseries) are 'attached' to this table.
1.2.110.108
1.2.110.109 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:
o id: identifier (used for comments only)
o formatId: reference to the format of this table (to one of the mergedPrecipitationTables in the declarations section)
o timeSeries: reference to an inputVariable.
1.2.110.110
1.2.111
SystemStatusTablesAnchor _Toc154574447 _Toc154574447
SystemStatusTables display information about the status and behaviour of the FEWS system itself (like in the System monitor).
SystemStatysTables come in different types:
1.2.112* liveSystemStatus: information about live system: MC and FSS('s);
1.2.113* exportStatus: information about exported files/reports;
1.2.114* importStatus: information about files imported;
1.2.115* scheduledWorkflowStatus: information about (next) scheduled workflows;
1.2.116* completedWorkflowStatus: information about number of workflows completed in last 24 hrs.
1.2.117* currentForecastStatus: information about which workflows are set to CURRENT;
1.2.118* logMessageListing list of logmessages (based on a query)
1.2.119* 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.
1.2.120
1.2.121 Figure 108 A systemStatusTable is divided into a status part and an extraOutputFields part.
Each type will be briefly explained:
1.2.121.1
Anchor | ||||
---|---|---|---|---|
|
A liveSystemStatusTable displays information about the status and behaviour of the live system components (MasterController and Forecasting Shell Server(s))
1.2.121.2
1.2.121.3 Figure 109 Example of a liveSystemStatus table (NE Region)
1.2.121.4 Declarations Section
1.2.121.5
1.2.121.6
1.2.121.7 Figure 110 Example of the configuration of a liveSystemStatus table in the declarations section
1.2.121.8
1.2.121.9 The following elements need to be defined:
1.2.121.10
- 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.
1.2.121.11
1.2.121.12
1.2.121.13 h5. Report Section
1.2.121.14 ++
1.2.121.15 Figure 111 Example of the configuration of a liveSystemStatus table in the report section
1.2.121.16 ++
1.2.121.17 The following elements need to be defined:
1.2.121.18 - id: identifier to the template tag ($TABLE(liveSystemStatusTable)$);
- formatId: reference to the format of this type of systemStatus table in the declarations section);
1.2.121.19* mcStatusQuery:
1.2.121.20* itemTextStatus: left blank will display MC name;
1.2.121.21* benchmarkTextStatus: benchmark text;
1.2.121.22* fssStatusQuery:
1.2.121.23* itemTextStatus: left blank will display FSS name;
1.2.121.24* benchmarkTextStatus: benchmark text for status;
1.2.121.25* itemTextSize: text for size query;
1.2.121.26* benchmarkTextStatus: benchmark text for size
1.2.121.27* singleRecordQuery
1.2.121.28* tableName: tablename in local datastore;
1.2.121.29* inputfield reference to column in table (to query):
1.2.121.30* recordId reference to record in table:
1.2.121.31* statusField reference to column in table (to display):
1.2.121.32* itemText: text to be displayed (can be empty)
1.2.121.33* benchmarkText: benchmark text
1.2.121.34
Anchor | ||||
---|---|---|---|---|
|
1.2.121.35 A exportStatus table displays information about the status of a number export features of the system, such as:
1.2.121.36* last occurence of a (export) workflow (by workflowStatusQuery);
1.2.121.37* nr of files present in an export directory (by logMessageParseQuery);
1.2.121.38* transfer speed of exporting files (by
Anchor | ||||
---|---|---|---|---|
|
1.2.121.39
1.2.121.40
1.2.121.41 Figure 112 Example of an exportStatus table (NE Region)
1.2.121.42
1.2.121.43
1.2.121.44 h5. Declarations Section
1.2.121.45
1.2.121.46
1.2.121.47 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.
1.2.121.48
1.2.121.49
1.2.121.50 h5. Report Section
1.2.121.51 ++
1.2.121.52 ++
1.2.121.53 Figure 114 Example of the configuration of an exportStatus table in the report section
1.2.121.54 ++
1.2.121.55 This table is constructed using two types of queries:
1.2.121.56* workflowStatusQuery;
1.2.121.57* logMessageParseQuery
1.2.121.58
1.2.121.59 The following elements need to be defined:
id: identifier to the template tag ($TABLE(liveSystemStatusTable)$);Anchor OLE_LINK2 OLE_LINK2 - formatId: reference to the format of this type of systemStatus table in the declarations section);
1.2.121.60* workflowStatusQuery:
1.2.121.61* workflowId:
1.2.121.62* itemText: text in 'Item' column;
1.2.121.63* benchmarkTextStatus: text in the 'Benchmark' column;
1.2.121.64* selectCompletedWorkflowsOnly: boolean indicating completed or scheduled workflows;
1.2.121.65* statusField: field from the taskRunsCompletions table indicating whether a workflow has been completed or not;
1.2.121.66* logMessageParseQuery
1.2.121.67* itemText: text in 'Item' column;
1.2.121.68* benchmarkTextStatus: text in the 'Benchmark' column;
1.2.121.69* logEntryEventCode: eventcode to filter on;
1.2.121.70* keyword: typical/unique keyword to parse for;
1.2.121.71* displayWord: integer value for the word to display (n-th word in this log message);
1.2.121.72 **
1.2.121.73
Anchor | ||||
---|---|---|---|---|
|
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.
1.2.121.74 Figure 115 Example of an importStatus table (NE Region)
1.2.121.75 ++
1.2.121.76 +
+
1.2.121.77 ++
1.2.121.78
1.2.121.79 h5. Declarations Section
1.2.121.80 ++
1.2.121.81
1.2.121.82
1.2.121.83 Figure 116 Example of the configuration of an importStatus table in the declarations section
1.2.121.84
1.2.121.85 The following elements need to be defined:
1.2.121.86
- 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:
o Last file imported
o Nr. of files read
o Nr. of files failed - showOutputFieldsOnly: boolean value for displaying the outputfields only.
1.2.121.87Remark: 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.
1.2.121.88 ++
1.2.121.89
1.2.121.90 h5. Report Section
1.2.121.91 ++
1.2.121.92 ++
1.2.121.93 Figure 117 Example of the configuration of an importStatus table in the report section
1.2.121.94 ++
1.2.121.95 The following elements need to be defined:
1.2.121.96
- id: identifier to the template tag ($TABLE(importStatusTable)$);
- formatId: reference to the format of this type of systemStatus table in the declarations section);
- datafeedStatusQuery
o BenchmarkText - id: textual string contain the name of the datafeed
- text: textual string indicating the benchmark for this datafeed
o statusField: textual reference to main field in the database table ImportStatus, lastImportTime - extraOutputField
o 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
1.2.121.97
scheduledWorkflowStatus tableAnchor _Toc154574451 _Toc154574451
A scheduledWorkflowStatus table displays the workflows which are scheduled together with their repeat time and next due time. The figure below illustrates this.
1.2.121.98 Figure 118 Example of a scheduledworkflowStatus table (NE Region)
1.2.121.99
1.2.121.100 h5. Declarations Section
1.2.121.101 ++
1.2.121.102
1.2.121.103
1.2.121.104 Figure 119 Example of the configuration of a completedWorkflowStatus table in the declarations section
1.2.121.105
1.2.121.106 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:
o Workflows
o Description
o MC Id
o Repeat Time
o 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. |
1.2.121.107
1.2.121.108 h5. Report Section
1.2.121.109 ++
1.2.121.110 ++
1.2.121.111 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
o workflowId: textual reference (case-sensitive!) to an existing workflow in the configuration
o itemText: text in the 'Item' Column (can be left blank in case of this statusTableSubType)
o benchmarkText: text in the 'Benchmark' column (can be left blank in case of this statusTableSubType)
o selectCompletedWorkflowsOnly: boolean variable: 'true' refers to query completed workflows (see next table subtype) and 'false' refers to query scheduled workflows (this type)
o 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)
o 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
1.2.121.112
1.2.121.113
completedWorkflowStatus tableAnchor _Toc154574452 _Toc154574452
A completedWorkflowStatus table contains an overview of all workflows carried out in the last 24 hours. An example is given below.
1.2.121.114
1.2.121.115 Figure 121 Example of a completedworkflowStatus table (NE Region)
1.2.121.116 *+
+*
1.2.121.117 h5. Declarations Section
1.2.121.118 ++
1.2.121.119
1.2.121.120
1.2.121.121 Figure 122 Example of the configuration of a completedWorkflowStatus table in the declarations section
1.2.121.122
1.2.121.123 The following elements need to be defined:
1.2.121.124
- 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:
o Nr. of Runs
o Nr. Failed - showOutputFieldsOnly: boolean value for displaying the outputfields only.
1.2.121.125
1.2.121.126 ++
1.2.121.127 *
1.2.121.128 h5. Report Section
1.2.121.129 ++
1.2.121.130 ++
1.2.121.131 Figure 123 Example of the configuration of a completedWorkflowStatus table in the report section
1.2.121.132 ++
1.2.121.133 The following elements need to be defined:
1.2.121.134- id: identifier to the template tag ($TABLE(scheduledWorkflowTable)$);
- formatId: reference to the format of this type of systemStatus table in the declarations section);
- workflowStatusQuery
o workflowId: textual reference (case-sensitive!) to an existing workflow in the configuration
o itemText: text in the 'Item' Column (can be left blank in case of this statusTableSubType)
o benchmarkText: text in the 'Benchmark' column (can be left blank in case of this statusTableSubType)
o selectCompletedWorkflowsOnly: boolean variable: 'true' refers to query completed workflows (this type) and 'false' refers to query scheduled workflows (see previous table subtype)
o statusField: textual reference to the field in the database table TaskRuns. In this case taskRunStatus.
1.2.121.135
1.2.121.136
currentForecastStatus tableAnchor _Toc154574453 _Toc154574453
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.
1.2.121.137 Figure 124 Example of a currentForecastStatus table (NE Region)
1.2.121.138 *
1.2.121.139 h5. Declarations Section
1.2.121.140 ++
1.2.121.141
1.2.121.142
1.2.121.143 Figure 125 Example of the configuration of a currentForecast table in the declarations section
1.2.121.144
1.2.121.145 The following elements need to be defined:
1.2.121.146- 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:Anchor OLE_LINK3 OLE_LINK3
o T0
o What-if Scenario
o Description
o FDO- showOutputFieldsOnly: boolean value for displaying the outputfields only.
1.2.121.147 ++
1.2.121.148 *
1.2.121.149 h5. Report Section
1.2.121.150 ++
1.2.121.151 ++
1.2.121.152 Figure 126 Example of the configuration of a currentForecastStatus table in the report section
1.2.121.153 ++
1.2.121.154 The following elements need to be defined:
1.2.121.155- id: identifier to the template tag ($TABLE(scheduledWorkflowTable)$);
- formatId: reference to the format of this type of systemStatus table in the declarations section);
- currentForecastQuery
o workflowId: textual reference (case-sensitive!) to an existing workflow in the configuration
o itemText: text in the 'Item' Column
o benchmarkText: text in the 'Benchmark' column
o statusField: textual reference: should be "dispatchTime"!
1.2.121.156* extraOutputField: textual references to specific TaskRun details (see figure above):
1.2.121.157* T0
1.2.121.158* whatIfId
1.2.121.159* description
1.2.121.160* FDO
1.2.121.161
1.2.121.162
Anchor | ||||
---|---|---|---|---|
|
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.
1.2.121.163 Figure 127 Example of a logMessageListing table (NE Region)
1.2.121.164 ++
1.2.121.165
1.2.121.166 h5. Declarations Section
1.2.121.167 ++
1.2.121.168
1.2.121.169
1.2.121.170 Figure 128 Example of the configuration of a logMessageListing table in the declarations section
1.2.121.171
1.2.121.172 The following elements need to be defined:
1.2.121.173
- 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:
o Log Creation Time
o Log Message
o TaskrunId - showOutputFieldsOnly: boolean value for displaying the outputfields only. This tableType requires a 'true' here.
1.2.121.174 ++
1.2.121.175
1.2.121.176 h5. Report Section
1.2.121.177 ++
1.2.121.178+ +
1.2.121.179 ++
1.2.121.180 Figure 129 Example of the configuration of a currentForecastStatus table in the report section
1.2.121.181 ++
1.2.121.182 The following elements need to be defined:
1.2.121.183 - id: identifier to the template tag ($TABLE(scheduledWorkflowTable)$);
- formatId: reference to the format of this type of systemStatus table in the declarations section);
- logMessageQuery
o logLevelFilter: textual (case-sensitive) reference to one of the log message levels. Choices are: INFO, WARN, ERROR, FATAL.
o 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.
o statusField: textual reference to the correct field in the LogEntries table in the database (="logLevel");
o 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)
1.2.121.184
forecastHistory tableAnchor _Toc154574455 _Toc154574455
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.
1.2.121.185 Figure 130 Example of a forecastHistory table (NE Region)
1.2.121.186 *
1.2.121.187 h5. Declarations Section
1.2.121.188 ++
1.2.121.189 ++
1.2.121.190
1.2.121.191
1.2.121.192 Figure 131 Example of the configuration of a forecastHistory table in the declarations section
The following elements need to be defined:
1.2.121.193* tableStyle: a choice of tableStyle which can be influenced by using the corresponding classes in a cascading style sheet. Choices are tableStyle1 to tableStyle10;
1.2.121.194* id: unique identifier (as reference to this table);
1.2.121.195* statusTableSubType: Choice for one of the subtypes of systemStatusTables: Choices are: liveSystemStatus, exportStatus, importStatus, scheduledWorkflowStatus, completedWorkflowStatus, currentForecastStatus, logMessageListing, forecastHistory;
1.2.121.196* tableTitle: a text for a title for this table;
1.2.121.197* headerRows: integer value for the number of header rows;
1.2.121.198* itemHeader: header text for the 'Item' column;
1.2.121.199* benchmarkHeader: header text for the 'Benchmark' column;
1.2.121.200* statusHeader: header text for the 'Status' column;
1.2.121.201* statusHeaderSplit: value indicating the number of header rows in the status column.
1.2.121.202* extraOutputFieldHeader: Additional Field(s) definition specifically for scheduled workflow related topics. Recommended fields are:
1.2.121.203* Dispatch Time
1.2.121.204* Completion Time
1.2.121.205* T0
1.2.121.206* Workflow
1.2.121.207* What-if Scenario
1.2.121.208* Description
1.2.121.209* FDO
1.2.121.210* showOutputFieldsOnly: boolean value for displaying the outputfields only. This tableType requires a 'true' here.
1.2.121.211 ++
1.2.121.212
1.2.121.213 h5. Report Section
1.2.121.214 ++
1.2.121.215+ +
1.2.121.216 ++
1.2.121.217 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
1.2.122Anchor _Toc154574456 _Toc154574456
Report Export Module ConfigurationAnchor _Toc95297294 _Toc95297294
This Report Export module is one of the DELFT-FEWS export modules. This export module is responsible for retrieving reports generated by forecasting runs from the database, and exporting these to the relevant directory structure on the web server. Reports can then be accessed from there via the web interface to DELFT-FEWS. All reports are exported as is, by the report module- ie the module is only responsible for distributing reports created.
Access to these reports through the web server may be at different levels depending on the user in question. The report export module itself does not explicitly consider these access rights, but exports the reports in such a structure to allow the static part of the web server to correctly administer the access rights.
This means the export of reports is divided into three parts
- Export of the current forecast information
- Export of forecast information other than the current forecast.
- Export of system status information
The web server will control access to all or some reports in these categories to appropriate users.
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_Export may be:
Report_Export 1.00 default.xml
Report_Export File name for the Report_Export configuration.
1.00 Version number
default Flag to indicate the version is the default configuration (otherwise omitted).
1.2.123 Figure 133 Elements of the reportExport module configuration
1.2.124
1.2.125 h5. reportExportRootDir
Root directory to which the all reports are to be exported to. This directory is typically the root directory of the web server
1.2.126
1.2.127 h5. currentForecastReports
Root element for definition of exporting reports for the current forecast
1.2.128
1.2.129 h5. currentForecastSubDir
Root directory for exporting current forecasts to.
1.2.130
1.2.131 h5. excludeModuleInstanceId
Optional list of reports generated by report module instances that should not be included in the export of current forecasts.
1.2.132
1.2.133 h5. exportForecastReports
Root element for definition of exporting reports from recent forecasts made. Includes both the current forecast and a configurable number of recently made forecasts.
1.2.134
1.2.135 h5. numberForecastsToExport
Definition of number of recent forecasts to report.
NOTE: The number defined here should comply with the number of links to other forecasts in the index_template.html file. This file is located in the reportExportRootDir directory.
1.2.136
1.2.137 h5. exportForecastSubDir
Directory to use as root for exporting other forecasts to. For identification a sub-directory is created for each forecast exported. This sub-directory is constructed using the id of the taskRun it was created by.
1.2.138
1.2.139 h5. excludeModuleInstanceId
Optional list of reports generated by report module instances that should not be included in the export of other forecasts.
1.2.140
1.2.141 h5. exportSystemStatusReports
Root directory for exporting system status reports to.
1.2.142
1.2.143 h5. includeModuleInstanceId
List of reports identified by moduleInstanceId of the report module instances that created them that should be included in the export of other system status reports.
1.2.144