-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ignore singleton coordinates without dims when attempting to generate bounds #281
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #281 +/- ##
==========================================
Coverage 100.00% 100.00%
==========================================
Files 9 14 +5
Lines 742 1143 +401
==========================================
+ Hits 742 1143 +401 ☔ View full report in Codecov by Sentry. |
# determine if the axis is also a dimension by determining | ||
# if there is overlap between the CF axis names and the dimension | ||
# names. If not, skip over axis for validation. | ||
if len(set(CF_NAME_MAP[axis]) & set(self._dataset.dims.keys())) == 0: | ||
continue | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to make it clear what is going on...
For an axis like lat
, set(CF_NAME_MAP[axis])
yields {"Y", "latitude", "lat"}
.
set(self._dataset.dims.keys()))
yields {'axis_nbounds', 'lat', 'lon', 'time'}
.
set(...) & set(...)
determines the intersection between these two groups. If there are elements in the resulting set (i.e., len(...) > 0
, it means that the axis is also a dimension. If there are no elements in the set, then the axis is not a dimension.
If the axis is not a dimension, there is no need to find bounds and we skip adding bounds.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me. Thanks for the quick turnaround Steve!
* initial solution for #278 add unit test add comments for test, cleanup extraneous code initial work on #282 Bugfix/278 cannot generate bounds (#281) * initial solution for #278 * add unit test * add comments for test, cleanup extraneous code * PR review refactor - Add `types-python-dateutil` to `mypy` dependencies - Update `ref_date` var to `ref_dt_obj` to avoid mypy error `error: Unsupported operand types for + ("str" and "relativedelta")` - Use dictionary unpacking for units variable - Use `datetime.strptime` instead of `pd.datetime()` which runs into the `pd.Timestamp` limitation - Add logger.warning when non-CF compliant time coords cannot be decoded * Consider calendar type when decoding non-Cf time - Fix tests * Update xcdat/dataset.py Co-authored-by: pochedls <[email protected]> * Update xcdat/dataset.py Co-authored-by: pochedls <[email protected]> * Fix datetime reference * return more specific cftime datetime types * removing extraneous calendar specification * Refactor using xarray methods - Move try and except statements into `decode_non_cf_time()` - Extract function `_get_cftime_coords()` to encapsulate related logic from `decode_non_cf_time()` * Update docstrings and silence logger warnings in tests * Fix Timestamp limitation from dtype - Update logger warning * Add space in logger warning Co-authored-by: tomvothecoder <[email protected]>
Description
This fixes an issue for datasets that have a singleton coordinate value (e.g., height = 2m), but not a corresponding dimension. When xcdat tries to add bounds, it hits an error, because the dimension is singleton.
Checklist
If applicable: