You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In pydata/xarray#2844, the option decode_coords='all' was added, which handles turning the appropriate grid_mapping variables into coordinates at dataset load time. This came along after we built up a bunch of our xarray integration, so there are some things I wonder now:
Could we deprecate our metpy_crs coordinate in favor of relying on decode_coords='all' and doing everything else we need with projections on-demand? Might be some issues with our inference of lat/lon projections.
The need to work across multiple, non-coordinate variables was the main motivation for the parse_cf() approach in the beginning. Could we deprecate parse_cf() entirely and do everything else on demand? The "special" handling for GOES coordinates is still something that might be tricky.
#3664 is handling making sure we work with this option at all, since it breaks our own finding of grid_mapping in parse_cf().
In pydata/xarray#2844, the option
decode_coords='all'
was added, which handles turning the appropriategrid_mapping
variables into coordinates at dataset load time. This came along after we built up a bunch of our xarray integration, so there are some things I wonder now:metpy_crs
coordinate in favor of relying ondecode_coords='all'
and doing everything else we need with projections on-demand? Might be some issues with our inference of lat/lon projections.parse_cf()
approach in the beginning. Could we deprecateparse_cf()
entirely and do everything else on demand? The "special" handling for GOES coordinates is still something that might be tricky.#3664 is handling making sure we work with this option at all, since it breaks our own finding of
grid_mapping
inparse_cf()
.cc @jthielen
The text was updated successfully, but these errors were encountered: