decode variable with mismatched coordinate attribute

[kmuehlbauer]

• decode variable with mismatched coordinate attribute
• propagate coordinates to encoding in any case

• Closes WRF output : cannot serialize variable #1809
• Closes to_netcdf is not idempotent when stacking rename and set_coords #5170
• Tests added
• User visible changes (including notable bug fixes) are documented in whats-new.rst
• New functions/methods are listed in api.rst

[kmuehlbauer]

This is still draft, because I wanted to get more insight on the approach first.

For now this will properly decode and propagate coordinates to encoding, but the missing coordinate is removed from that string. Additionally a warning is raised. I've added a "coordinates_strict" to the available options for decode_coords to enable a workflow which raises in the case of mismatched coordinates.

Some questions:

• Should we just not propagate coordinate to encoding in case of mismatches?
• Should we also check if coordinates are matching on write (see to_netcdf is not idempotent when stacking rename and set_coords #5170)?

Any comments appreciated!

[kmuehlbauer]

This solves the problem in #1809.

But I'm not really happy with the naming of decode_coords-strings.

[kmuehlbauer]

OK, thanks to the test suite we now have a contradicting issue here:

#308

@shoyer It would be great if you can share your thoughts on how to handle mismatched coordinates here. In #313 it silently does not handle mismatched coordinates and keeps mismatched coordinates attributes on the variable. Should we just raise on mismatch (no good idea!) or keep current behaviour but issue warning (might be overlooked or disabled)? Or is there some other solution, beside the proposed by this PR?

[dcherian]

I think we shouldn't add more options and just silently ignore the names of any missing variables. This attribute gets out of sync quite easily.

Should we just not propagate coordinate to encoding in case of mismatches?

Let's propagate if decode_coords is not False

Should we also check if coordinates are matching on write

We could warn if the coordinates attribute refers to absent variables at write time. But I suspect it would just be annoying.

[kmuehlbauer]

Thanks @dcherian, that greatly simplifies the code.

As a compromise with #308 coordinates are now only propagated to encoding if at least one coordinate name matches a variable.

[kmuehlbauer]

As this now does not emit any warning, should I revert the change using warnings.warn -> emit_user_level_warning or is this OK to proceed?

[kmuehlbauer]

I hope that this is short enough but explains how missing variables are treated. No native speaker here, so please suggest better wording/grammar.

[dcherian]

LGTM :) but could use a pass from someone else to double check our decisions

[kmuehlbauer]

LGTM :) but could use a pass from someone else to double check our decisions

Current behaviour:

coordinates are propagated to encoding if all coordinates are in variables

New behaviour:

coordinates are propagated to encoding if at least one coordinate is in variables

[kmuehlbauer]

Current behaviour (if decode_coords is not False):

coordinates are only propagated to encoding if all coordinates are in variables

New behaviour (if decode_coords is not False):

coordinates are propagated to encoding in any case, but only coordinates in variables are added as coords