Drive vcoord_type and origin_z from grib message #120
Conversation
| VCOORD_TYPE = { | ||
| "generalVertical": ("model_level", -0.5), | ||
| "generalVerticalLayer": ("model_level", 0.0), | ||
| "isobaricInPa": ("pressure", 0.0), | ||
| } |
There was a problem hiding this comment.
How come surface and hybrid keys are removed?
There was a problem hiding this comment.
The typeOfLevel is the same as the vcoord_type for those so they're actually handled by the pass through
| @@ -96,6 +96,15 @@ def _update_grid(field: xr.DataArray, dim: Literal["x", "y"]) -> dict[str, Any]: | |||
| ) | |||
|
|
|||
|
|
|||
| def _update_vertical(field) -> dict[str, Any]: | |||
| if field.vcoord_type != "model_level": | |||
| raise ValueError("Field.vcoord_type must model_level") | |||
There was a problem hiding this comment.
| raise ValueError("Field.vcoord_type must model_level") | |
| raise ValueError("Vertical coordinate type must equal model_level") |
| @@ -155,7 +164,7 @@ def destagger( | |||
| keep_attrs=True, | |||
| ) | |||
| .transpose(*dims) | |||
| .assign_attrs(origin=field.origin | {dim: 0.0}) | |||
| .assign_attrs({f"origin_{dim}": 0.0}, **_update_vertical(field)) | |||
There was a problem hiding this comment.
Why does destaggering z enforce typeOfLevel="generalVerticalLayer" ?
There was a problem hiding this comment.
All staggered fields should be defined on the generalVertical levels as far as I understand
There was a problem hiding this comment.
But why then does it change from generalVertical to generalVerticalLayer during destaggering?
There was a problem hiding this comment.
I believe that's just the way that those level types are defined.
|
|
||
| def override(message: bytes, **kwargs: typing.Any) -> dict[str, typing.Any]: | ||
| """Override GRIB metadata contained in message. | ||
|
|
||
| Note that no special consideration is made for maintaining consistency when | ||
| overriding template definition keys such as productDefinitionTemplateNumber. | ||
| Note that the origin components in x and y will be unset. |
There was a problem hiding this comment.
I cant see where in override or extract origin_x or origin_y are unset. Does this happen in earthkit-data's GribMetadata override method?
There was a problem hiding this comment.
Yeah this note is a bit outdated, in the current implementation, the origin_xy values just remain untouched. I'll update the note
There was a problem hiding this comment.
Yes thanks, since untouched and unset have different meanings it would be good to update
Purpose
Use the
typeOfLevelkey as the source of truth for thevcoord_typeattribute. Anextractfunction is added to the metadata module to enable this workflow. Theoverridefunction now updates all attributes previously extracted by thegrib_decodermodule. This does not include theorigin_xandorigin_yattributes as they need to be derived from a reference field.Code changes
metadata.extractmetadata.overridewill call theextractfunction to update attributes in the return value