Review changes for upcoming 0.11.0 release #512
sandorkertesz
started this conversation in
General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
This is the discussion page for the major (breaking) changes in this release.
Xarray engine
A new Xarray engine "earthkit" was implemented and used by default in
Field.to_xarray(). The old (cfgrib) engine can also beinvoked via
engine="cfgrib". This is definitely a BREAKING change.Q:
to_xarray()that the default engine changed?SimpleFieldList
This is a fieldlist that simply stores a list of arbitrary fields. It is a top level object and can be directly imported from earthkit-data. For detailed discussion see here: #471
Q:
Array backend
The array backends for the fields/fieldlists were refactored and simplified with some breaking changes. For detailed discussion see here: #471
Q:
array-api-compatpackage became a mandatory dependency. Is it acceptable?Field modification
The
Field.copy()andField.to_field()methods were added to alter field metadata and values. They have slightly different behaviours.copy(): returns a new field containing modified metadata or/and values. The original field kept unaltered. The new field acts like a wrapper around the original field.to_field(): returns a new (in-memory)ArrayField(values array + Metadata object). New values, array_backend and/or new metadata can be specified. Always callsoverride()to generate the metadata for the newArrayField(so for GRIB data it clones a new handle). The name was chosen to match the existingFieldList.to_fieldlist()method, which currently turns a fieldlist into aSimpleFieldListcontainingArrayFields(so basically callsto_field()on each field).Q:
copy()a suitable namecopy()andto_field()? Or unify them? What should happen toto_fieldlist()?Beta Was this translation helpful? Give feedback.
All reactions