Noticed while re-running the LPS notebooks last week that save result now complains of too many dimensions when saving to GTiff, if you have assigned a new value for time. Using aggregate_temporal_period of "month" will lead to a new dimension, but we will also are assigning 't' to the dataset dimensions. The following ends in 4 dimensions, I've drafted a PR that works around this, but I am not sure that this is an appropriate solution, as we would have to maintain a list of possibly alternative values for 'time' or 't'.
See:
if 'time' in data.dims:
data = data.rename({'time': 't'})
if 't' not in data.dims:
data = data.assign_coords(t=datetime.now())
data = data.expand_dims('t')
Imo, it might be better to only ever have 3 dimensions for consistency, x, y, and t. If someone has used a process like aggregate_temp... then the process should still aggregate by the requested value, but instead of changing the dimension, a property value can be added to reflect the aggregation. I think this would make dimension handling a little easier, @ValentinaHutter wdyt? :smile:
Noticed while re-running the LPS notebooks last week that save result now complains of too many dimensions when saving to GTiff, if you have assigned a new value for time. Using aggregate_temporal_period of "month" will lead to a new dimension, but we will also are assigning 't' to the dataset dimensions. The following ends in 4 dimensions, I've drafted a PR that works around this, but I am not sure that this is an appropriate solution, as we would have to maintain a list of possibly alternative values for 'time' or 't'.
See:
Imo, it might be better to only ever have 3 dimensions for consistency, x, y, and t. If someone has used a process like aggregate_temp... then the process should still aggregate by the requested value, but instead of changing the dimension, a property value can be added to reflect the aggregation. I think this would make dimension handling a little easier, @ValentinaHutter wdyt? :smile: