Land as np.nan or 0 in v4?

[reint-fischer]

Maybe we should discuss whether land is np.nan or 0.0 in the internal model of v4?

Originally posted by @erikvansebille in #2387 (comment)

In the new XLinearInvdistLandTracer interpolator, land values are assumed to be np.nan, instead of 0, which is the current assumed value. I think this makes a lot of sense for many fields where no valid value exists on land and using 0 could result in ambiguous interpolation?

[erikvansebille]

One consideration in using/assuming np.nan for land is that the default XLinear interpolation then throws an Error (since the return value is NaN. This could be either an advantage (users will realise that their interpolation method is 'wrong' for the field with land) or a disadvantage (their simulations will frequently crash; unless we fix XLinear too)

For a bit of history: Note that in v3 we used 0 for land values because of the C-conversion; it was not easy to propagate NaN

In summary; I'm on the fence whether np.nan or 0 is a better value to define land...

[VeckoTheGecko]

As a note users have sometimes found difficulty with the nan to 0.0 conversion #2229 (comment)

[erikvansebille]

I was thinking, perhaps we could simply use a Field attribute (e.g. Field.land_value) to determine what the value of land is, rather than hard-coding a 0 or np.nan. Down the line this land_value could even be parsed from the Field.data._FillValue?

[reint-fischer]

I like that a lot. I also think it would be great to read the field as the user presents it: if it contains 0 on land, interpolation will go well, and if there is a landmask with np.nan, the basic interpolation should throw an error (suggesting XLinearInvdistLandTracer?)