Quality Gate passed

Issues
9 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

The output reading methods are fine, in my opinion. They just need some tests.

The input class needs more attention:

• Schemata are still missing (but should be generally easy to write);
• I'm unsure what the current option handling logic should be; I overloaded _render but perhaps there are cleaner ways;
• obs_id2 is only required for FLOW-JA-FACE, not HEAD or DRAWDOWN. I currently just pad it with nan, this feels cleanest to me;
• FLOW-JA-FACE would also be relevant to specify in grid form, but I'm not sure how. Could be omitted for now. The non-grid class will support it just fine.

The biggest question for me lies in the alternative from_boolean_grid constructor. It requires validation as well which would fit well in the form schemata, one might also imagine that a grid based class could be worthwhile, like the other intermediate classes.

obs_id is also relatively difficult to construct for a user, because its 2D (nobs * ndim). So for DIS it's shaped (nobs, 3), for DISV it's (nobs, 2) and for DISU it's (nobs, 1). So the grid form is probably more ergonomic in practice (or it should take a x, y, z constructor or something).

Finally, there is the question of whether we need to expose some official logic to put the OBS output back on a grid. The utility in the example above , e.g. will only work if an entire layer is observed. In practice, one might want to place observations in different layers via a pattern like DataArray, which may essentially contain random True values anywhere.
However, this becomes again more tedious with stuff like FLOW-JA-FACE entries.