Skip to content

Support of 1D elements in Mesh Layers #164

@PeterPetrik

Description

@PeterPetrik

QGIS Enhancement: Support of 1D elements in Mesh Layers

Date 2020/01/27

Author Peter Petrik (@PeterPetrik)

Contact [email protected]

maintainer @PeterPetrik

Version QGIS 3.14

Summary

The initial implementation of mesh layer in QGIS supports only basic type of 2D irregular meshes with data defined on faces and vertices. In QGIS 3.12, we added support for 3D Layered/Stacked Meshes. Another type of mesh which is not yet supported is 1D mesh. This proposal describes the required steps to allow usage of 1D mesh for QGIS users.

Description

1D data can be stored as a mesh layer, in the form of mesh nodes (or vertices) and mesh edges. Edge is a straight line between two vertices. The direction of an edge is defined by the first/start and the second/end vertex. Similar to 2D and 3D mesh, 1D mesh components can store multiple variables with temporal dimension. 1D mesh elements can have linkage with 2D (or 3D) elements. Example of such data is urban drainage system: with pipes (edges) and manholes (nodes). In this case, edges can store flow velocity and nodes can store water depth.

One of the standard specifications for representation of 1D mesh is UGRID.

Water management in 1D domain is quite common use-case based on number of QGIS plugins that are available for this purpose. To mention just few, QEsg (16k downloads) or QWater (14k downloads). EPANET, arguably considered as the industry standard, would be possible to support directly in MDAL and 1D Mesh Layer, at beginning for post-processing purposes.

Other use case is river model like HECRAS, where the nodes are profiles on the river and edges are distance from the profile.

Users will be able to load 1D mesh data in QGIS. Similar to 2D mesh symbology, QGIS will provide styling of the nodes and edges based on their quantities. Additionally, mesh elements can contain vector quantities (e.g. velocity) which can be styled in the same way as it is currently handled for 2D meshes.

Example Data

Imagine a simple 1D mesh with 5 vertices (e.g. manholes) and 4 edges (e.g. pipes) with topology as visualised on following figure

1dmeshframe

Data could be vector values (e.g. water flow velocity):

V1 V2 V3 V4 V5
water flow velocity time=0s [6, -1] [2, 0] [2, 2] [2, 1] [2, 1]
water flow velocity time=60s [3, -0.5] [1, 1] [1, -1] [1, 0.5] [2, 1]

The vector values on edges are not usually defined in the data for HEC-RAS or UGRID format. Nevertheless, the styling and rendering of such data is the same as the data defined on vertices.

1dmeshvectordata

There are also scalar values (e.g. water depth on nodes) that could be defined, for example:

V1 V2 V3 V4 V5
water depth time=0s 4 4 4 3 2
water depth time=60s 1 1 1 2 2

1dcontour

Some formats store additional data on nodes, for example cross-section geometries in HEC-RAS format. The extra information can be stored as vertex metadata, so the QGIS Python plugins can take usage of such information.

Design

Changes in MDAL

MDAL can read 3D stacked meshes and 2D meshes at the moment. 1D meshes basically consist of vertices and data defined on vertices which are the same as for 2D meshes. The edges will be added to the MDAL public API (for both edges of 2D elements or edges on 1D meshes) similarly to API for faces or vertices:

MDALedgeiterator

New dataset type defined on edges will be introduces to be able to retreive data from 1D edges:

MDALedgedatatype

Handling of files with multiple meshes

For example UGRID format can store any number of independent meshes in one file (e.g. 1D and 2D mesh). Those meshes do not share any data, they have separate topology, vertex definition, faces or edges definition and temporal data. Therefore, MDAL and QGIS will be updated to handle such file formats similarly to how sublayers are treated for vector layers. If file contains one mesh, the mesh is loaded directly. In case of multiple meshes, user will be able to choose from a pop-up dialog which meshes to load. Each of the selected mesh will be added as a separate layer in the QGIS layer tree.

In the situation when user has loaded multiple mesh layers, e.g. 1D urban drainage system and 2D flood model, both with temporal dimension, it is desirable to be able to change timestep simultaneously on both layers. This will be handled as part of time refactoring initiative started in QEP 128

Styling of the 1D meshes

The renderer and GUI for vectors/arrows (both on defined edges and vertices) will be identical with 2D mesh vector renderer for data defined on vertices. For vector data on edges, there will not be any renderer implemented in the first version.

For contours, the GUI will be similar to 2D mesh faces renderer, but with additional option to be able to display width of line based on selected scalar dataset group. Also user will be able to set fixed line size similar to simple vector layer renderer for lines.

To support regular vector layer symbology for both points and lines, we will develop an API and implement processing algorithms (in Crayfish) to be able to export vertices/edges to OGR-compatible formats.

Identify and plots

To be able to browse raw data, 1D meshes will be integrated to the Identify tool and public API will be created, so it is possible to export raw data for plot creation.
The example of the plots that could be implemented in Crayfish with the new API:

  • For 1D network, user can click on one or multiple nodes/edges and see the selected quantity over time for selected point
  • For 1D network, user can pick 1D line (snapped to 1D network) and see the quantity over spatial dimension

Affected Files

Most of the mesh related files and MDAL library

Performance Implications

None

Further Considerations/Improvements

  • support data defined on edges of 2D faces

Backwards Compatibility

For all formats that do not 1D meshes, the API will be backward compatible.

Issue Tracking ID(s)

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions