-
Notifications
You must be signed in to change notification settings - Fork 17
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
New definitions for fit_curve and predict_curve #420
Conversation
@ValentinaHutter you know this better than I do! :) |
Small side question:
Does "encountered" here mean just in the input data, or also during the fitting procedure? |
I agree that finite numbers should be valid.
In our implementation we actually do not consider invalid values in the fitting procedure.... At least, we explicitely exclude NaN values that naturally occur in the datasets, there. When an infinite number is in the dataset, an exception is raised and the fitting cannot be started. Let me know if we should change this :) |
It was meant to cater for invalid values in the input data, but not sure whether and how we should cater for other cases? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just a suggestion
This process must be able to handle invalid data internally and should not return an error if some invalid points are present in the time series. |
@clausmichele So you are saying we should remove the |
Indeed. I can't think about all the possible scenarios, but the one for which we created this process, fitting an harmonic curve to each pixel of a raster-cube, must handle NaNs occurring due to cloud masked or or invalid pixels along the time series. |
Doesn't it actually all depend on how the callback provided in the openeo-processes/proposals/fit_curve.json Lines 38 to 43 in 0dd3ab0
If that function properly supports handling invalid data, then the whole So this seems like to user's responsibility to make it work with or without invalid data support? Or, would it be a feature of |
@soxofaan yes exactly! So |
I cherry-picked the single word change from this PR which seemed okay. The issues that came up now are somewhat related, but not strictly related to the intial PR. So having the first action done, we can now discuss additional changes here independantly. About removing the InvalidValues error, what happens if a data cube containing strings is passed? The fitting function is defined for numbers only according to the schemas. I think with the wordsmithing updates from @soxofaan the process description makes sense to me, but please correct me if you think otherwise. |
# Conflicts: # proposals/fit_curve.json
Rough example from today's discussions: labels = dimension_labels(datacube) function fit: predictions = predict_curve(cube2) |
Make fit_curve usable in apply_dimension, scrap gap filling for predict_curve, clarify no data handling, etc.