Add 'Basin / area' polygon layer with the geometric area of the basin

[d2hydro]

What Next to the Point-representation of a Node, I propose to add a Polygon to basins representing the area for:

• developing, and parameterizing basins in a new model
• re-parameterizing basins in an existing model
• providing more context to a basin.Node represented by a point.

Why

1. As model-developer I want to parameterize a basin with spatial data; shapes/with precipitation, infiltration, etc. For that I need a Polygon-representation of my basin so I can create an overlay to compute basin values.
2. As a model-developer I want to specify all outlets of the basin of interest. These I typically model at the boundary of the basin-polygon
3. As model-developer I want to re-parameterize an existing-model (similar to 1). For that I need a still existing Polygon of my basin. This can only be guaranteed if it is stored in the model database.
4. As a modeller I want to validate my model inputs; e.g. A(h) curves can not exceed A > Polygon.area. I typically check if my basin.areas sum up to the total topographical area to be modelled (e.g. Ribasim-NL ~ total area of NL).
5. As a hydrologist/end-user I want to be able to see the area on a map when clicking as it explicitly defines the basin on a map (more context). The network (Point-representation) still tells me how the basin is related to other basins

How Current thoughts:

• add Basin.area parameter with a Polygon GeoSeries
• parameter could be optional, but I suggest to define that in the toml, e.g. basin_area = true
• if basin_area = true all basins should have a polygon assigned to it, if not I would expect a validation-error.
• In database.gpkg I would suspect a layer Basin / area
• Cherry on cake; enhance qgis plugin by showing polygon when node is selected

[Huite]

One thing to mention: in many coupled models we expect to make a distinction between different river or drainage system within a single hydrological area. We've mostly been speaking in LHM terms, in the sense of primary, secondary and tertiary systems, generally linked together.

That shouldn't create any problems, as in case of (primary, secondary, tertiary) the same polygon just happens to be repeated three times. (Ideally, then, the basin nodes representing the T -> S -> P graph for a single area would be spaced out a little bit, but still located within the polygon.)

[d2hydro]

One thing to mention: in many coupled models we expect to make a distinction between different river or drainage system within a single hydrological area. We've mostly been speaking in LHM terms, in the sense of primary, secondary and tertiary systems, generally linked together.

That shouldn't create any problems, as in case of (primary, secondary, tertiary) the same polygon just happens to be repeated three times. (Ideally, then, the basin nodes representing the T -> S -> P graph for a single area would be spaced out a little bit, but still located within the polygon.)

Good point. As an alternative we can create a (optional) catchment-layer that can be referenced by one or more basins?

[visr]

Ugh last week I wrote quite a long comment here, but coming back I see it never got posted, I lost it. Take 2:

With a few lines of Python (see below) you can add other tables to the database. The main problems with it are:

• It is not standardized or supported by Ribasim so it only becomes some kind of convention, which is not great for interoperability
• The Ribasim QGIS plugin currently errors on extra tables
• Ribasim Python and the core both ignore extra tables

We could support extra columns by adding the meta_ prefix. I suppose we could come up with something similar for extra tables. The GeoPackage spec does not support adding a second geometry column. This doesn't help the interop though.

So far we've completely ignored geometries in the core, to the degree that they are optional. I've never seen a model without geometries, and I feel uneasy about the possibility that the Edge geometry and from_ and to_ mismatch. That could lead to very confusing situations, so I think we should start validating Node and Edge geometries in the core. We could probably just decode the GeoPackage geometry encoding ourselves since we would need very little, and to avoid adding a GDAL dependency.

node = gpd.read_file(modeldir / "database.gpkg", layer="Node")
basin_area = node[node["type"] == "Basin"].geometry.buffer(100.0)
basin_area.to_file(
    modeldir / "database.gpkg", layer="Basin / area", driver="GPKG", index=True
)

For Basin / area in particular we'd first need a good definition. In principle the Basin only corresponds to the water, not the land. Including land leads to prettier polygons though. But even including land, @d2hydro mainly expects a mesh topology without overlap, but @Huite would like overlapping polygons to represent different systems in the same area.

To make matters more complex, to account for every rain droplet falling over the river basin only once, some mesh topology or grid is probably needed, to send it directly to open water (Basin), or some land routine (coupled or not). For the Dutch model we might give MetaSwap that job, though outside I feel like the current Ribasim Basin precipitation is way too error prone for these kinds of issues. A warning recently needed to be added: https://deltares.github.io/Ribasim/core/equations.html#precipitation.

I can't think of much use for polygons for the water areas that the Basin really represents. Perhaps, similarly to #661 where a separate Precipitation node was suggested, we need a separate Land node. This could require a non-overlapping mesh topology or grid, where each land zone maps to one basin, and each basin maps to 1:n zones. So there wouldn't be a Basin / area, but a Land / area, and the primary, secondary and tertiary Basins all map to different zones.

Many things here, some will need separate issues, but I just wanted to put some thoughts out there for discussion.

[Huite]

Some thoughts:

• Realistically: edge geometries will be involved with 100% of the models.
• The fact that Ribasim doesn't use them internally is almost an implementation detail (?)
• Realistically, polygon geometries will also be involved in ~99% of the models.
• The output is currently not self-describing at all. If you run a model, but don't store the input along with the output, you have no way of analyzing it.
• A big bonus is visualization as well: ideally you can associate your timeseries with a polygon dataset, and have it work with the QGIS Temporal Controller. Not sure how well that currently works.
• I don't think we necessarily need to be that strict about the Basin / area definition? The area is just some representative area. In some cases, this can be the water exactly. In most cases, it is just an envelope.
• What seems reasonable to me: Ribasim requires this Basin / area with a 1:1 relation with the basin nodes. Unlike the edge geometry, it can just copy them as-is to the output directory in some form (e.g. to a geometry geopackage, containing just nodes, edges, and these geometries as separate tables).
• Most importantly, I think the envelope geometries solves both of @d2hydro and my problems.
• Accounting for every raindrop is a different problem and probably requires a different concept to begin with. E.g. what if you have a wetland area without clear boundaries between land and water (e.g. is inundated half of the time). You probably want to define a Wetland basin or something, with distinct evapo(transpi)ration rate for land versus water. In the current scheme, accounting for a droplet falling only once is solved in the pre-processing.

[d2hydro]

A specification:

Let's define the GeoSeries I need for my 'use-case' as non-intersecting-Polygons as defined by Shapely:

• @Huite envelope as it has a meaning in GeoPandas (Shapely), and it's not what I mean: https://geopandas.org/en/stable/docs/reference/api/geopandas.GeoSeries.envelope.html
• @visr (2D) mesh is not the same as non-intersecting-polygons by definition of MDAL (Lutra Consulting), at least last year.

Keep it as simple as possible:

• My stories (see introduction) can simply be fulfilled by having a structure to store (Basin) Polygons coherently with your model project. Not forcing it (yet) but standardizing, so we can write code to utilize them in our own, and others models.
• Introducing a manifest-file might offer another solution here? To separate the files/data you need for you julia-core that needs no messing arround (toml, database.gpkg and results), and all meta-data the modeller/user needs to fullfill the user-stories described above.

[Huite]

@d2hydro You're right, I probably shouldn't have used the word envelope, I guess I should've said some kind of bounding polygon.

The non-overlapping part: this doesn't have to be required by Ribasim, right? You need non-overlapping/non-intersecting parts, the MODFLOW coupling need overlapping parts. You can assert that the polygons don't intersect, I would just not assert that.

I agree and think we can keep it (as) simple (as possible).

[d2hydro]

@d2hydro You're right, I probably shouldn't have used the word envelope, I guess I should've said some kind of bounding polygon.

The non-overlapping part: this doesn't have to be required by Ribasim, right? You need non-overlapping/non-intersecting parts, the MODFLOW coupling need overlapping parts. You can assert that the polygons don't intersect, I would just not assert that.

I agree and think we can keep it (as) simple (as possible).

@Huite, you're correct Ribasim doen't have to require/do anything by/with these polygons.