feat: add comparison processes

[ValentinaHutter]

No description provided.

[codecov]

Codecov Report

Merging #50 (193bf1c) into main (64b00b9) will increase coverage by 1.40%.
The diff coverage is 94.66%.

@@            Coverage Diff             @@
##             main      #50      +/-   ##
==========================================
+ Coverage   75.05%   76.46%   +1.40%     
==========================================
  Files          23       24       +1     
  Lines         886      956      +70     
==========================================
+ Hits          665      731      +66     
- Misses        221      225       +4     

Impacted Files	Coverage Δ
...eo_processes_dask/process_implementations/utils.py	88.88% <88.88%> (ø)
...ocesses_dask/process_implementations/comparison.py	94.82% <94.82%> (ø)
...processes_dask/process_implementations/__init__.py	75.00% <100.00%> (+1.66%)	⬆️
...cesses_dask/process_implementations/cubes/utils.py	86.66% <100.00%> (+11.66%)	⬆️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[SerRichard]

lgtm, only comment would be to try and exhaust all conditional cases. Not so familiar with the processes at this point, but the test set up looks good!

[clausmichele]

What's the status of this PR? Can I help to proceed with this?

[LukeWeidenwalker]

Let's look into this after the SRR!

[ValentinaHutter]

#50 (comment)

I now added this check to make sure that the example of eq(x = 0, y = false) => false works, but there is one problem left:
I do this check for inputs that only consist of one value, e.g. int, float, bool. As soon as I want to do this for an array and check if it is a bool array, it might not work, because numpy easily converts a bool array into a float array. In that case, False would be set to 0 and the example would not work.

[ValentinaHutter]

@LukeWeidenwalker I tried implementing the eq(x = 0, y = false) => false example with an explicit check for the bool type if the input value only consists of one number - as soon as there are numpy or dask arrays, I would not check it explicitely, is this fine for you? or should I add a check for the numpy array dtype?

[ValentinaHutter]

The current version shows one problem that now occured, as I tested merge_cubes with the overlap_resolver eq: The result of the merge_cubes process is of type xr.DataArray and loads the data into memory. I am not sure, why this happens within merge_cubes, as the eq process works as expected with apply. Need to investigate further.

[LukeWeidenwalker]

Btw, I just realised, comparison of temporal stuff is deprecated with 2.0: Open-EO/PSC#21, so we don't need to bother implementing this! :)

[ValentinaHutter]

Btw, I just realised, comparison of temporal stuff is deprecated with 2.0: Open-EO/PSC#21, so we don't need to bother implementing this! :)

Ah, thanks for pointing this out, then I will quickly update the check for the datetime again!

[clausmichele]

Hi @ValentinaHutter and @LukeWeidenwalker, today it would be the last day to merge and make available the comparison processes and let me prepare the notebook for Monday

[LukeWeidenwalker]

Hi @ValentinaHutter and @LukeWeidenwalker, today it would be the last day to merge and make available the comparison processes and let me prepare the notebook for Monday

Yesterday was a public holiday in Austria, so I just saw this! @ValentinaHutter made more changes to this on Wednesday, which I'll review and iterate on again today. However, I don't think you really need us to merge&release these changes to use them. If you're happy with the current level of implementation, couldn't you just grab the code and stick it into your process registry manually?

[clausmichele]

Unfortunately it's not a viable option, I would have to ask 20+ users to install a non released version from source and I wouldn't have the time for testing it now.

[LukeWeidenwalker]

@ValentinaHutter I've made a few more changes, and found another bug in merge_cubes! Just FYI, not_null wasn't dask-friendly yet, so now I was able to replace da.where with np.where again.

Think this looks good now, thanks for adding all the tests, these were really useful to have in place already! :)

@clausmichele: I'll merge this now and cut a release for you to use in your demo!