Conversation
* Adds vertical geometry type * Adds additional check for zcoord if gtype is vertical
Very similar to parsing of tracks (_track.py) but z-coordinate is now needed. * remove duplicated (time,z) pairs. Note, duplicated time allowed ( obs with same time on multiple depth)
Stores timeseries data for vertical profiles. data structure time(time) = [t1, t1, t1, t2, t2, t2, t3 ...] z(time) = [z1. z2, z3, z4, z5, z6, z7 ...] data(time) = [d1, d2, d3, d4,d5,d6,d7....]
ryan-kipawa
left a comment
There was a problem hiding this comment.
Nice, very clear and easy to understand. Only a few comments:
- add pyproj to pyproject.toml notebooks dependency group
- the tests seem a bit light compared to other existing observation types
| ds.time.to_index().is_monotonic_increasing | ||
| ), "time must be increasing (please check for duplicate times))" | ||
|
|
||
| if "gtype" not in ds.attrs: |
There was a problem hiding this comment.
Keep this in the # validate attrs section?
There was a problem hiding this comment.
gtype is used right below in validation of the coordinates ( validate if VerticaObservation contains a z-coordinate). I will move the validate attrs section to the top
There was a problem hiding this comment.
looking at it a bit more i would like to keep the gtype validation at the top and other attributes at the bottom. Gtype is like a overall parameter that needs to be validated before going forward. The attributes validation is more about setting stuff if not exists. Also, other attributes are validated in the "data validation" part so i think it is fine to split it like this. Hope you agree, otherwhise i can off course rearrange to be more strict about the sections
|
|
||
| Parameters | ||
| ---------- | ||
| data : VerticalType |
There was a problem hiding this comment.
How does the user know what a vertical type is?
There was a problem hiding this comment.
I notices afterwards that it's in types.py. While I appreciate the DRY aspect of this, I also noticed that all other observation types repeat the actual types in the docstring. I would suggest keeping that style for now
|
Closes #595
First step of 4 in implementation of vertical skills
General idea of vertical skill is to store data for model and obs in 1d (see below). Depth information is stored in auxilary coordinate z. Befinit of this compared to storing in 2d:
Steps:
This PR per commit
(see vertical skill notebook for more info)
VerticalObservation class
Stores timeseries data for vertical profiles.
Validate timeseries with geomtype=vertical.
parse input for timeseries with vertical coordinate.
Very similar to parsing of tracks (_track.py) but z-coordinate is now needed.
data structure:
time(time) = [t1, t1, t1, t2, t2, t2, t3 ...]
z(time) = [z1. z2, z3, z4, z5, z6, z7 ...]
data(time) = [d1, d2, d3, d4,d5,d6,d7....]
Testdata
Tests of new features