Closed d2hydro closed 7 months ago
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.)
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?
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:
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.
Some thoughts:
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.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).A specification:
Let's define the GeoSeries I need for my 'use-case' as non-intersecting-Polygons as defined by Shapely:
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.htmlmesh
is not the same as non-intersecting-polygons by definition of MDAL (Lutra Consulting), at least last year.Keep it as simple as possible:
@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 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.
What Next to the Point-representation of a Node, I propose to add a Polygon to basins representing the area for:
Why
How Current thoughts: