issue_comments

Where a cast is specified in encoding, could xarray not cast the data first to get that isolated copy and then set the fill on the cast array?

If you cast float to int you might lose information neeeded to accurately do the filling step.

the only possible gotcha here for users is that data stored in a netcdf file as integer type data but with a _FillValue is loaded as a float using np.NaN because there is no np.nan equivalent for integer types.

Yes. but your data originated as floating point so this is correct.

ncdump asserts that there has to be a missing data value, which is 65535 unless set otherwise, but xarray is using the presence of the _FillValue attribute to signal the presence of missing data.

You can specify missing_value and/or _FillValue attributes. So you could try that. Xarray does not follow the default "fill values" because it can be confusing; it is valid to store 65535 as u2 for example.

So, I am using _FillValue=65535 in the encoding to to_netcdf.

encoding is really an instruction to Xarray to encode the data. But you've already done that. So specify _FillValue in attrs instead of encoding. This will get written to file and be interpreted on read. At least IIUC =)

Try setting _FillValue in attrs? I haven't triedf this...

Yeah I think the issue is that the "CFMaskCoder" tries to repalce NaNs regardless of the dtype of the variable. Doing this creates a copy in this step: where(notnull(data), data, other).

https://github.com/pydata/xarray/blob/787a96c15161c9025182291b672b3d3c5548a6c7/xarray/coding/variables.py#L149

You should set FillValue to None after manually encoding to ints to skip the extra copy.

We should probably raise an error or at least a warning for integer dtypes and not-None FillValue

As for your initial question, we create a copy of the float array when replacing NaNs (does not happen in-place), then convert to int. So you'll need to account for 2x float array + 1x int array memory use.