-
Notifications
You must be signed in to change notification settings - Fork 13
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
FillValue #70
Comments
During our last meeting, we agree that aggregating data set together should not be our driver to define the format. I do not have strong opinion on this. |
Well, as long as it is clear that this is a free value, clearly defined on _FillValue, we can transfer the responsibility to the aggregator to inspect and conform the aggregating elements. My suggestion is to let it be a free field, suggesting the use of NaN for float and double. |
I am fine with that ! |
If no one step in, I will open a new PR on the first chance. |
Discussion 24th April 2023 - recommended fill values are agreeable. |
During the meeting on Jun 14 it was raised the question if FillValue should be locked, i.e. fixed value, or allow the user to define. There is an advantage to leaving it free, since it is clearly defined in the file and any software can parse it, as long as it is the same data type. Seems like we are inclined toward a free value.
Emma raised an important point that if it is a free value it would be a problem when aggregating multiple deployments. For instance, ERDDAP would take the first or the last attribute.
Since we haven't clear a path to go, we decided to move the discussion here to give us some time to think about it.
The text was updated successfully, but these errors were encountered: