You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In CODA, the dynamic definitions for netcdf use a scalar for netcdf attributes if there is only one element, and will use an array if there is more than one element. If we want to create a codadef where the number of elements can range from 1 to more, then we have a problem, since we don’t read the attributes with one element as an array.
The best way forward (which also solves other aspects, such as allowing conversions and introducing 'time' types) is to use codadefs to (re)interpret how netcdf/etc. products are read (just as XML).
We could combine this with a global CODA option that will either read products using the dynamic format or using the codadef format. If the dynamic format is used a codacheck will then still be possible. This will allow to present all issues instead of stopping at the first issue found (which is what will happen when (re)interpreting the product using the codadef as format).
The text was updated successfully, but these errors were encountered:
Similar to the netcdf attribute issue, there is also the problem of how to deal with the difference between char and string as the choice for 'native type' (single char vs. char sequence) for self-describing formats.
For the netcdf4 format, which uses HDF5, the netcdf4 library seems to always store attributes of numbers as arrays. This means that CODA will always use an array for attributes in netcdf4 files.
The downside is that it is thus currently not possible to represent a scalar attribute as a scalar in CODA for netcdf4 files.
In CODA, the dynamic definitions for netcdf use a scalar for netcdf attributes if there is only one element, and will use an array if there is more than one element. If we want to create a codadef where the number of elements can range from 1 to more, then we have a problem, since we don’t read the attributes with one element as an array.
The best way forward (which also solves other aspects, such as allowing conversions and introducing 'time' types) is to use codadefs to (re)interpret how netcdf/etc. products are read (just as XML).
We could combine this with a global CODA option that will either read products using the dynamic format or using the codadef format. If the dynamic format is used a codacheck will then still be possible. This will allow to present all issues instead of stopping at the first issue found (which is what will happen when (re)interpreting the product using the codadef as format).
The text was updated successfully, but these errors were encountered: