Concepts

<< Click to Display Table of Contents >>

Navigation:  DATA MANAGER > Background >

Concepts

Flood Study Data Storage

Flood information derived from flood modelling is supported by many studies each with numerous file sets covering design flood frequencies, flood type and flood scenarios such as climate change and blockage.

 

Once a study has been completed the raw model results require processing for use in floodplain management activities and this data needs to be stored in a central location enabling all stakeholders to access the data through waterRIDE™ projects. To accommodate a variety of end users, the flood data can be accessed on a per study basis as well as through a master surface that is a mosaic of all current flood study results. The data may also include spatial and temporal flood products derived from the model results or the master surfaces to serve specific needs of other stakeholders.

 

A key concept of Data Manager is the storage and listing of this data. The data is a collection of files which are stored in a main root folder with sub-folders for each study. Once a study has aged and is to be replaced with an updated version, the current version is archived into a separate archive folder, where it can be rolled back if needed in the future. Flood products that are generated for external stakeholders such as GIS extracts, profiles and time series charts, waterRIDE™ project extracts, etc are exported to the Publish Folder which is publicly accessible by the stakeholders.

 

Copying files into the root folder is controlled through a study registration process within the Data Manager interface and the list of files and associated study and file meta data is stored in Data Manager's database. The rigor in the system will be compromised if files are manually copied or moved within the folders.

 

Having the three main folders should provide IT services with the flexibility to locate or re-locate the folders as required to meet storage availability. Data Manager is an optional module within Flood Manager and the logical path to the root folder is stored in the Data Manager .INI file that resides in the same folder as the Flood Manager executable. Likewise, access to the Publish Folder for end users is stored in the Flood Manager .INI file which also resides in the same folder as the Flood Manager executable. In a waterRIDE™ Enterprise setup, there is an additional enterprise .INI file that resides in a central configuration folder. The settings in the central .INI file override those of the local .INI file.

 

Data Manager File Folder Structure

 

Folders

 

 

Data Manager's Database

The list of all files registered in Data Manager are stored in Data Manager's database along with associated meta data. The meta data includes some free form text, but is primarily sourced from lookup tables, some of which have fixed content and others with content that can be added by users. The following list summarises the key data base tables and their fields. Field names ending in '_ID' are indices into the various lookup tables.

 

Table:  GIS_Layers

Fields: ID, UNC_Folder, filename, file_type_ID, alias_name, study_ID

 

Table:  Master_Grids

Fields: ID, filename, version, ari_ID (idx to ARI), scenario_ID (idx to Scenario), start_date, end_date, use_status_ID, archive_ID

 

Table:  Pk_Surfaces

Fields: ID, study_ID, filename, file_type_ID, flood_ID, ari_ID, historic_ID, scenario_ID, use_status_ID, archive_ID, adoption_ID, date_adopted, date_retired

 

Table:  Products

Fields: ID, study_ID, filename, date_created, operator, prod_service_ID, prod_type_ID, source, surface_ID, time_set_ID, ARI_ID, historic_ID, terrain_enhanced, comment

 

Table:  Publish

Fields: ID, product_ID,operator, date_published, customer, comment

 

Table:  Reports

Fields: ID, study_ID, filename, report_date, author, comments

         

Table:  Rollbacks

Fields: ID, study_ID, start_date, end_date, comment

         

Table:  Studies

Fields: ID, study_name, version, sub_version, study_folder, ,study_by, study_date, locale_ID, catchment_ID, study_quality, model_quality, Xmin, Xmax, Ymin, Ymax, date_registered, registered_by, use_status_ID, archive_ID, adoption_ID, date_adopted, date_retired, pmf_extents_file

 

Table:  Ts_Surfaces

Fields: ID, study_ID, filename, file_type_ID, flood_ID, ari_ID, historic_ID, scenario_ID, use_status_ID, archive_ID

 

Table:  wR_Projects

Fields: ID, study_ID, filename, date_created, operator, notes

 

 

Master Grid Surfaces

The concept behind the master grids is to have all flood studies, riverine, overland flow and storm surge, for a given design flood and scenario (existing climate change, blockage, etc) on a single surface. This can be achieved with infinite grids in waterRIDE™ but where the studies are widely spaced a waterRIDE™ composite file would be more efficient and provide similar benefits.

 

waterRIDE™ Projects

waterRIDE™ Projects can be created from a template within Data Manager using the registered flood surface files and the registered GIS reference files. Following this rule will ensure that the projects should always open successfully without any missing files.

Projects can be launched from within Data Manager to support the flood custodians, and to support the other stakeholders using Flood Viewer or Flood Manager, the list of internal Projects is updated in the Publish folder whenever a project is registered. The Flood Viewer and Flood Manager .INI files contain a reference to the location of this list in the Publish folder enabling users to select a project from the Central Projects list in the application's startup form. This avoids the need to setup Windows shortcuts or for the user to have to browse in Windows Explorer to find them.

Support is also provided for flood modellers undertaking localised models, eg for development impacts, that are within the bounds of an existing flood study model. An extract of the existing study waterRIDE™ Project can be created and provided to the modeller enabling them to extract boundary conditions for the localised model. Then when the localised model is finished, the result surfaces can be dropped and blended with the existing study surfaces.