Let me throw a big wrench into this argument about not allowing string
arrays.
1. I would prefer a consistent decision and standard about the use of
char vs. string so a user does not need to know where to use char
array, scalar string, or string arrays.
2. Use of string arrays with flag_meanings (not sure it would be needed
with flag_values?) will solve many problems for my program to
actually merge our standards with CF. Currently with char arrays we
need to connect all words for a single flag by underscores for space
delimiting. Many of our variable names and attribute names contain
underscores. So when the flag description is parsed and changed to
be more human readable all the attribute and variable names are not
preserved. Automated tools can no longer replace attribute or
variable names with the attribute or variable value. We do this a
lot. We also have lengthy descriptions for our flag_meanings. I
would prefer to use flag_mask, flag_values and flag_meanings as that
general method is better than the one we currently employ.
3. I do see the benefit of storing history as string arrays. Without
checking date stamps I can see how many times the file has been
modified by checking the list length. It also removes any ambiguity
about separators in the history attribute which differs from the CF
standard of space separation and is often institution defined. The
current definition for history attribute is "List of the
applications that have modified the original data." In the python
world the use of "list" is different than the intended definition.
4. I'm starting to get a lot of more complicated data that are
multidimensional but do not share the same units. We would need to
work with udunits, but Cf/Radial is proposing a new standard for
complex data which often have different units for different index in
a second dimension. If we allowed string arrays in units we could
store complex data or other data structures more native to the
intended use since uduints interprets space characters as
multiplication not a delimiter.
5. missing_value or _FillValue currently allow one value. For string
type data allowing sting arrays to have multiple fill values which
would allow numeric data also have multiple fill values defined,
which I'm sure there are many data sets that have multiple fill
values used, but not defined correctly in the data file.
6. valid_range can be used with string data type
7. Conventions attribute could group multiple indicators with the same
class of conventions. For example ["CF-1.7", "Cf/Radial
instrument_parameters radar_parameters", "ARM-1.3"]
8. and on and on ....
I'm not suggesting the use of all these use cases, but this relatively
small change can go a long way to improve the standard and future use of
the data.
OK, I've made my case I'll be quite now.
Ken
On 2018-7-27 09:23, JimBiardCics wrote:
>
> @JonathanGregory
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_JonathanGregory&d=DwMFaQ&c=qKdtBuuu6dQK9MsRUVJ2DPXW6oayO8fu4TfEHS8sGNk&r=Vm7o2ZGxPkkqRuPs8nVMVQ&m=8yXRwSE3siXwVZGSqDHhbz4T34VwzI3u8GXmHkJaWkY&s=d4qYLgaugDM0kdWoZHbgieEpVU-Xg_SJ1d1F_dbBs2M&e=>
>
> The use of an array of strings for history would simplify denoting
> where each entry begins and ends as entries are added, appending or
> prepending a new array element each time rather than the myriad
> different ways people do it now. This would actually be a good thing
> to standardize.
>
> I think we can just not mention string array attributes right now. The
> multi-valued attributes (other than history, perhaps) pretty much all
> specify how they are to be formed and delimited.
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_cf-2Dconvention_cf-2Dconventions_issues_141-23issuecomment-2D408452242&d=DwMFaQ&c=qKdtBuuu6dQK9MsRUVJ2DPXW6oayO8fu4TfEHS8sGNk&r=Vm7o2ZGxPkkqRuPs8nVMVQ&m=8yXRwSE3siXwVZGSqDHhbz4T34VwzI3u8GXmHkJaWkY&s=SzizwDsedBZ_n_qPzSCZ1OVJv5eli4zFSJXKogaOAtE&e=>,
>
> or mute the thread
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AH4NvmnCKFC7HSpXQx-5FMi6Yfc-5F1HSfBaks5uKzBvgaJpZM4VbMvb&d=DwMFaQ&c=qKdtBuuu6dQK9MsRUVJ2DPXW6oayO8fu4TfEHS8sGNk&r=Vm7o2ZGxPkkqRuPs8nVMVQ&m=8yXRwSE3siXwVZGSqDHhbz4T34VwzI3u8GXmHkJaWkY&s=F3efrdVvqb932q5mp7D_eux9BSLztraUFgqR52IYak0&e=>.
>
--
Kenneth E. Kehoe
Research Associate - University of Oklahoma
Cooperative Institute for Mesoscale Meteorological Studies
ARM Climate Research Facility - Data Quality Office
e-mail: [email protected] | Office: 303-497-4754 | Cell: 405-826-0299
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/141#issuecomment-408471576
