-
Notifications
You must be signed in to change notification settings - Fork 1
UI Workflow
Either a Return Period is selected from a drop-down menu or a Wave Height Range is entered into the input text boxes.
The Return Period and Wave Height Range are related for a particular Hazard Point. If a Return Period and Hazard Point are selected, the appropriate Wave Height Range input text box can be populated. Conversely, if a Wave Height Range is specified by the user and a Hazard Point is selected, the appropriate Return Period can be selected in the Drop Down.
If a new Hazard Point is selected by the user, and there is either a Return Period -or- a Wave Height Range specified, the other value(s) will be updated. If both the Return Period and the Wave Height range are specified and the Hazard Point is changed, the Return Period should remain unchanged and the appropriate Wave Height Range updated (not the other way around).
When a return period is selected all the hazard points should be coloured according to their waveheights. This colour stretch should be different to the colour stretch of the source zones.
A Single Hazard Point is selected using the Map Interface
Once a Return Period and Hazard Point are selected the Source Zones are displayed and colored by % contribution of the hazard to the selected Hazard Point.
User should be able to right click on hazard point to view the hazard curve (graph) for that point in a pop up box.
A Source Zone is selected by activating a 'Select Source Zone' tool and clicking on a single sub-fault (A Source Zone is made up of one or more sub faults). When a single sub-fault is selected, -all- of the other Sub Faults in that Source Zone are highlighted.
Once a Hazard Point, Source Zone and Wave Height range are all selected, the Events Grid is populated with the events valid for that set of parameters.
A -single- Event is selected in the Events Grid. Once this event is selected, the sub-faults that constitute this particular event are highlighted in another way so as to be distinct from all the other subfaults that make up the selected Source Zone.
A Simulation Area is defined by -either- activating the "Draw Simulation Area" tool and drawing a simple closed polygon on the map -or- uploading a text file that specifies the points that make up the desired polygon. If a file is uploaded the polygon should be drawn on the map. In either case, the Simuation Area polygon should be drawn with a solid stroke and transparent fill.
Simulation Area should include one or more hazard points. If no hazard points are included it should generate a warning message. "You must include at least one hazard point in your Simulation Area."
When the user creates the Simulation Area polygon they MUST define the mesh resolution and mesh friction values. These will be the default values used for the entire model if no mesh resolution or mesh friction polygons are used. The user enters the desired Mesh Resolution and Mesh Friction in an input text box. The valid range of values are 1 - 1 million for resolution and 0.0001 - 1 for mesh friction. The input text box should validate that the range is both numeric and positive and falls within the valid range. If the input is not valid, the user should be notified immediately.
Elevation data is the key input to the ANUGA model run. The user should be able to upload one or more files containing elevation data of various formats (to be defined which formats are supported). It is envisioned that normal the normal GeoNode upload processes (including batch upload) will be used for this step. It is desirable to allow the user to have access to the upload data form directly within the GXP app interface via an Ext Form rather than have to leave the GXP app to upload via the GeoNode Page.
This step can be done at -any- point in the process. It is quite possible that all of the data needed for the model run will already exist in the GeoNode/GeoServer and the user can skip this step and go to step 8 directly.
A base elevation data set will be included (250m grid resolution) so user could choose to run the simulation with this data (often used to do a first-pass model, or include higher resolution data for detailed inundation modelling.
The elevation data must be 'ranked' or ordered according to its spatial resolution and other factors (quality, date etc). After the user has uploaded elevation data in step 7, or the interface should select all of the elevation data in the GeoNode/GeoServer that is valid for the Simulation Area specified in step 5. Initially, the app should make a 'best effort' attempt to order the layers based the metadata criteria attached to each layer. The interface should then allow the user to see the metadata parameters (spatial resolution, date, etc) for each layer and drag and drop them into the desired order for processing in step 9.
Once the ordering is specified in step 8, the user will initiate the process of compositing the elevation data based on the ordering specified. The output should be clipped/masked to the extent of the Bounding Polygon specified in step 5. The new layer should be added to the GeoNode/GeoServer and 'owned' by the logged in user and the source layers and other provenance information should be indicated in the metadata of the new layer. The user should also be given the opportunity to specify metadata values for the new layer (comments etc).
The user should be able to specify one or more Internal Polygons. There are 3 types of Internal Polygons: Mesh Resolution, Mesh Friction and Area of Interest. Each internal polygon -must- fall completely within the Bounding Polygon specified in step 5.
The Mesh Resolution and Mesh Friction polygons allow the user to specify a numeric level of detail or friction for specific areas within the larger bounding polygon and the overall Mesh Resolution specified in step 6. The user can specify one or more internal Mesh Resolution polygons and their value, but the internal polygons must not overlap. Nesting of the polygons is permissible with no assumption that the values of the nested polygons are ordered in any way. It should also be possible to disjoint internal mesh resolution polygons as long as they do not overlap. The user should activate a tool to draw the polygon at which time the app should validate that it is completely within the larger bounding polygon and then provide a form for the user to specify the value. The values should be immediately validate and the user notified if they are invalid. Valid ranges for mesh resolution are 1-1million and for mesh friction is 0.00001-1.
The Area of Interest polygons indicate the boundary of the area of detailed elevation data. The export results script will use this polygon to output the inundation raster only over this area.
Users should also be able to import polygons as ESRI shapefiles or x,y csv files and assign attributes to them.
The user should be able to specify one or more points within the Simulation Area. The app should immediately validate that the point falls within the Simulation Area and discarded if it does not after notifying the user. For each point created, the user should be prompted to specify some parameters - name (string field) and elevation (0 default).
Once -all- of the above steps are complete, the user will be prompted to specify various Project and Scenario metadata via an Input form. The required set of model params is not fully defined yet, but the app should validate the values based on valid ranges, lengths etc for each field. These include (name, default, description):
- Tide (float, 0.0) - The initial water level during the simulation
- Starttime (integer, 0) - The start time in seconds of the simulation, most cases will be 0.
- Finaltime (integer, max - 1million) - The final time in seconds of the simulation. Most times less than 80k (22hrs).
- Alpha (float, 0.1) - The smoothing parameter for generating the mesh. Range (0.00001 - 1).
There are many different layers that can be created from the simulation. So here the user must specify what results they want. This will include:
- Quantities - This is the physical parameter that they will output which could be:
- Depth - this is also called flow depth and is the depth of the water (m)
- Stage - this is the height of the water above MSL (m)
- Velocity - this is the velocity of the water (m/s)
- Energy - this is the contained energy of the water, a function of velocity and depth (kj)
- Bed shear stress - this is the shear stress that acts on the base of the water column
- Maximum / Timestep - the user can select to output the quanitiy above as the maximum value over the entire simulation (default and used in most cases OR the value at a certain time step.
- Area - the user must define the area that the output raster will cover. This will usually be the AOI (defined by AOI polygon) as this is the area with the highest resolution mesh, which is the most reliable data OR the Simulation Area (SA) which is often used as QC of the initial simulations.
- Raster resolution - the user must define the resolution of the output raster. This will usually be 20-50m in the AOI or 250m+ in for the whole model.
Once steps 1-12 are complete, the user will click to indicate that they are ready to run the model, and the app will validate that all values are within valid ranges, field lengths and geometric constraints. Once validation is complete, the server app will generate one or more python scripts with all the specified params for use by ANUGA.
Once the run scripts are generated, ANUGA will be invoked with the generated run scripts. The server app will provide an asynchronous task queue (using celery and djcelery) that tracks the progress of each job. The user will be able to check on the progress of the job and will be notified when it is complete. Django-notifications will likely be used which allows the user to specify how to be notified (via the UI, email, sms etc).
Once the model run is complete, ANUGA will output a NetCDF file with the values for each grid cell over the range of timestamps specified. This file is then processed to derive the maximum inundation depth, maximum velocities and maximum water heights for each grid cell, and a single raster is produced. This raster should be pushed into GeoNode/GeoServer with the appropriate metadata indicating the source layers, model params, provenance etc.
Once the layer is in GeoNode/GeoServer, the user should be able to access this via the Map Composer app which will provide some raster symbology tools to style the layer as desired. The user can use normal GeoNode tools to share the layer, and maps created with it ... either by exporting the layer as an image, pdf or other export format, or embedding the map into other web pages using the embed tool.
The User should be able to access saved Projects and their constituent scenarios and modify any of the the parameters and the initiate a new model run with the new values.