Hardiness zones

[Zeitsperre]

Pull Request Checklist:

• This PR addresses an already opened issue (for bug fixes / features)
  • This PR addresses part of Add Hardiness Zones and generic functions for calculating climatologies #1290
• Tests for the changes have been added (for bug fixes / features)
  • (If applicable) Documentation has been added / updated (for bug fixes / features)
• CHANGES.rst has been updated (with summary of main changes)
  • Link to issue (:issue:number) and pull request (:pull:number) has been added

What kind of change does this PR introduce?

• Adds the Hardiness Zones index with options for both Australian and USDA classifications
• Adds separate indicators for each classification scheme.

Does this PR introduce a breaking change?

No.

Other information:

[coxipi]

In get_zones, zone_min, zone_max and step_size could have conflicting values if (zone_max - zone_min)/step_size is not a integer. Should I raise an error, or give a warning and extend zone_max?

[coxipi]

Also, I'm thinking we could maybe allow input bins instead of creating them in the function. It might cover some cases where users don't want linearly spaced zones.

[Zeitsperre]

Also, I'm thinking we could maybe allow input bins instead of creating them in the function. It might cover some cases where users don't want linearly spaced zones.

This would make the "Heat Zones" Index (uses non-linearly-spaced bins) very simple to support. Why not? I vote to go for it.

[Zeitsperre]

Does this accept Quantified or xr.DataArray | list[Quantity]?

[coxipi]

Isn't the same?

[coxipi]

It should be the same as a threshold in other indices e.g. "20 degC" and Quantified seems to be used in this context

[Zeitsperre]

Oh geez, maybe. I keep getting confused by that variable type. Hold on.

[Zeitsperre]

Oh sorry! I'm speaking specifically to bins!

I can see that Quantified is xr.DataArray | str | Quantity, but if we want to provide the option for users setting their own bins, this would be provided as list[str | Quantitiy], no?

[Zeitsperre]

I think we're using Quantity and Quantified interchangeably here. I think having a list of bins with different units should be acceptable (or, at the very least, supported).

My understanding here is that we can potentially accept the following:

1. xr.DataArray
2. list[str] → ["5 degC", "10 degC", "30 degF", "20 K"]
3. list[pint.Quantity] → [5 * pint.ureg.kelvin, 5 * pint.ureg.celsius]

I hate the 3rd option, but my understanding is that it is technically supported by convert_units_to(). Is this correct?

[coxipi]

I think keeping zone_min, zone_max makes sense, invoke them as we do with thresholds, allow different units.

For bins, xr.DataArray makes more sense. List would be a nice shorthand, but not essential. list[Quantity] seems like a generalization of zone_min , zone_max, zone_step to [zone_a, zone_b, ..., zone_z], but at this point, I'm not sure if it could benefit anybody. I think most people would use: xr.DataArray([value_a,value_b, ...,], attrs={"units":units})

[Zeitsperre]

I agree. I think it's probably enough to support zone_min and zone_max with different units, but we should ask that bins consistently use the same unit. It's very difficult to imagine cases where a user would want something more than that.

We can let them open up an issue if ever that happens, which will likely be "never" haha

[coxipi]

Ok, let me check what is done elsewhere in the code. I just have the feeling this would be much more flexible than what is otherwise allowed elsewhere, but maybe it's not comparable

EDIT: I don't think there is something comparable really?

[coxipi]

Ok, implemented bins : xr.DataArray | list[Quantity] | None.

I agree now that a simple list without units was not a good idea.

As for xr.DataArray vs. xr.DataArray | list[Quantity], I think there is merit to both. We can build indicators with Optional[xr.DataArray] and use bins in this way later. Do we generally aim to limit the generic functions only to inputkinds accepted in indicators? If so, then maybe yes, it's a violation of this rule that does not bring much.

Anyways, once the list of Quantities is converted, I sort it, assuming a user could input a list of bins not necessarily ordered.

I can revert changes if we don't agree on this.