Deprecate `lon_name` and `lat_name`?

If the coords are named "lon" and "lat" we can do the following:

region.mask(ds)

If they are named "longitude" and "latitude" we have two possibilities:

region.mask(ds, lon_name="longitude", lat_name="latitude")  # (1)
region.mask(ds.longitude, ds.latitude)  # (2)

I don’t think ~(2)~ (1) offers any advantage over ~(1)~ (2) - it’s more verbose and harder to read (for me). Without (1) you can always do:

region.mask(ds["longitude"], ds["latitude"])
region.mask(ds[lon_name], ds[lat_name])

What we loose is the possibility to set a custom name when numpy arrays are passed. I.e. the following is no longer possible:

region.mask(ds.lon.values, ds.lat.values, lon_name="longitude", lat_name="latitude") 

But I don’t think it’s worth it - if you pass a numpy array you are unlikely wanting back a DataArray with a very specific naming (?). And the workaround would be relatively straightforward:

mask = region.mask(ds.lon.values, ds.lat.values) 
mask = mask.rename(lat="latitude", lon="longitude")

This allows to remove two params from mask which is always a gain (IMHO).

[mathause]

Thanks for the feedback @jbusecke !

[jbusecke]

Just my two cents: I support the initial proposal to deprecate this syntax:

region.mask(ds, lon_name="longitude", lat_name="latitude")  # (1)

As you suggested in my personal workflows I would not miss the ability to pass numpy arrays (e.g. region.mask(ds.lon.values, ds.lat.values, lon_name="longitude", lat_name="latitude") ). In fact I think that it is better to force the user to wrap things into xarray before passing them.

The options setting seem quite confusing to me and I believe the initial deprecation + #364 would be a better choice!