Closed hellkite500 closed 3 years ago
I left this as waterbody_edge_list.json on purpose with the expectation that long run, we will decouple the waterbodies from flowpaths. Theoretically, the waterbody_edge_list is actually duplicative of the catchment_edge_list right now since they are 1:1.
If there are no waterbodies (yet) should we just drop the waterbody_edge_list.json until there are?
Possibly. It's kind of grey in my mind. A degenerate waterbody_edge_list is the catchment_edge_list ... so is it really a problem?
The problem is probably more in semantics and managing expectations.
Adding this note to get waterbody edge list.
#' NOTE: In some cases, there is one waterbody per catchment. In this case,
#' the waterbody edge list will be identical to the catchment edge list and
#' the waterbodies will coorespond 1:1 with flowpath **features.**
The intro vignette already has this paragraph:
Given the flowpaths, catchments, and nexuses, we can generate topology edge lists and data representations. The nexuses are outlet points along flowpaths in this case. Waterbodies are 1:1 with flowpath catchment realizations in this example but the data model will support 1:n or n:1 waterbody:catchment relationships.
Added to the README:
In the relatively common case where one waterbody is modeled per catchment, the waterbody edge list and catchment edge list are identical and there is one flowpath per waterbody. This is not a requirement of the data model but is a common hydrologic-model implementation scheme.
Since implementing
flowpath_data.geojson
,waterbody_edge_list.json
should semantically be calledflowpath_edge_list.json
.