Change behavior of apply_dimension and reduce

[m-mohr]

Based on issue #73: Made apply_dimension more usable and made reduce more restricted to real "reduce" use cases.

• apply_dimension was basically replaced with a completely new definition.
• reduce: Reducers can't return multiple values any longer. Parameter target_dimension was therefore removed.

What do you think?

[m-mohr]

What I'm also thinking about is sorting, for example. It's just the values that change, but also reference system etc should stay intact. What I'm no wondering about is: Should the dimension labels be preserved when sorting? What about preserving the labels when computing the cumsum, for example? This is not really captured any longer with the "enumerated" labels.

[mkadunc]

Re @m-mohr

What I'm also thinking about is sorting, for example. It's just the values that change, but also reference system etc should stay intact. What I'm no wondering about is: Should the dimension labels be preserved when sorting? What about preserving the labels when computing the cumsum, for example? This is not really captured any longer with the "enumerated" labels.

When sorting values, the quantity (variable) remains the same, but the labels change - you go from e.g. time axis time{t_1, t_2, .., t_N} to rank axis rank{1,2,..,N}.

When computing cumsum, the quantity changes (you go from value-at-t_i to sum-value-between-t_0-and-t_i); the labels stay the same, but they (might) change in meaning:

• before cumsum labels on the time axis are points-in-time when the measurement happended;
• after cumsum, labels effectively denote the right boundary of the time interval for which the values apply; left boundary of that same interval is the first of the original labels

[m-mohr]

When sorting values, the quantity (variable) remains the same, but the labels change - you go from e.g. time axis time{t_1, t_2, .., t_N} to rank axis rank{1,2,..,N}.

Ah, okay. So sort/order don't work well with apply_dimension now:

The dimension labels are preserved when the number of pixel values in the source dimension is equal to the number of values computed by the process.

There's more work needed, also having in mind what @soxofaan wrote in #111 (comment) . Will give it a try and check how this can be streamlined better... (two processes either depending on label changes or cardinality change?)

[m-mohr]

Telco: Agreed, but rename reduce to reduce_dimension.

Edit: I guess, we should also rename filter to filer_labels then?!

[m-mohr]

Updated the PR, I think we can merge with one or two reviews.

I also renamed filter to filter_labels as it seems that's what is the direction also with reduce_dimension.

Later, I need to check whether there are references to reduce and filter in API or the docs (e.g. the glossary) and update them.

Remove waiting label from #94 once merged.

[m-mohr]

To not further block my work, merging without approvals. If there's still something to change, open a new PR for it.