-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prevent "band math" like attempts with filter_bands
#239
Comments
If I'm not mistaken, this is what should happen in pseudo code:
final result will be a 4D datacube (2 bands) with 1 values everywhere :0 |
For a bit more context:
The first case works fine and is a handy feature.
Users probably have different expectations: for example: only have I think we should reconsider using |
FYI as far as I can remember,
which works without issues mentioned above because there is 100% overlap Some options to resolve this whole issue:
what do you think @jdries ? |
Having an "overlap-only" version of |
I seem to be mostly in favor of trying to detect this case on the client side. So throwing an error is fine for me. There's possibly also an option to introduce even more logic in the client to resolve the case, but that might be too much magic? |
Spin-off from #76 (comment) :
User might mistakenly use
filter_bands()
instead ofbands()
to do band math: e.g.This will currently be translated to 3
merge_cubes
operations with an overlap resolver (one for each of the three math operators). Not only is this very inefficient, it will also give unexpected results.We should raise error or warning if we detect this (doing math operation on
filter_bands
result)The text was updated successfully, but these errors were encountered: