Commit to netCDF4 ? #343
Replies: 2 comments
-
I think it would definitely be a good idea to try to be more explicit about which parts of CF are netcdf4-only. I also think it makes sense to discuss taking an official position on 3 vs 4. My inclination would be to say that going forward, the Conventions assume netCDF4 by default, and to have a document (an Appendix?) that tracks which parts are only applicable to one version or the other. We can aim to keep things compatible with both versions wherever feasible, but if it's much easier to resolve an issue using netcdf4 features, that's okay. If we take a position on 3 vs 4, my suggestion would be that we recommend 4, but don't (yet) recommend it strongly. |
Beta Was this translation helpful? Give feedback.
-
Good idea -- It seems CF already allows nc4-only features -- so we should very clearly mark: "If you so this, you won't be able to use netcdf3" |
Beta Was this translation helpful? Give feedback.
-
Topic for discussion
#341 reminded me that there's a challenge with extending CF to allow constructs that are only supported in netcdf4, and not netcdf3.
Looking at the current version, the only mention I see is:
"The string type is only available in files using the netCDF version 4 (netCDF-4) format"
So it implies that you should be able to do CF compliance with a netcdf3 file, but that you can also be compliant in a netcdf4 file that would not be convertible to netcdf3.
And of course, issue #533 is about groups, so netcdf4 only.
I wonder if it's time to commit to netcdf4? or at least be more explicit about what it means to use version4-only features... or ??
NOTE: I think netcdf3 only software is getting rare now, but there are still issues -- in particular, the netCDF4 python library (ironically) only supports netcdf3 in its MFDataset feature --which bites us a fair bit.
Anyway -- I do think some clarity on this would be good, though I'm not at all sure what that should be ....
Beta Was this translation helpful? Give feedback.
All reactions