special_feature metadata file variable

[tcarval]

In the NetCDF user's manual, it is mentioned :
This vocabulary captures the possible SPECIAL_FEATURES in a float’s characteristics.
Additional float features can be specified here such as algorithms used by the float.
The SPECIAL_FEATURES variable in a float metadata file must be filled by the DAC, to indicate there are AUX data files (see https://argo.ucsd.edu/data/auxiliary-directory).

Actually, it should not be a fixed vocabulary.
Today, for floats having experimental sensors it is required that :
The SPECIAL_FEATURES string must include the substring ‘AUX’ for machine parsing

Is that syntax sufficient ? Yes in my opinion.
Action : in Argo User's manual, replace This vocabulary captures with This variable captures

[tcarval]

Here are the SPECIAL_FEATURES entries from Coriolis DAC for BGC experimental sensors

<style> </style>

SENSOR_MAKER	SENSOR_MODEL	SENSOR	SPECIAL_FEATURES
Biospherical instruments inc.	MPE	RADIOMETER_PAR	THIS FLOAT HAS AUXILIARY SENSORS FOR RADIOMETRIC MEASUREMENT OF PAR
HYDROPTIC	UVP6-LP	PARTICLES_PLANKTON_CAMERA	THIS FLOAT HAS AUXILIARY SENSORS FOR SIZE SPECTRUM MEASUREMENT
TRIOS	RAMSES_ACC	RADIOMETER_DOWN_IRR	THIS FLOAT HAS AUXILIARY SENSORS FOR HYPERSPECTRAL RADIOMETRIC MEASUREMENT
TRIOS	OPUS	SPECTROPHOTOMETER_NITRATE	THIS FLOAT HAS AUXILIARY SENSORS FOR NITRATE MEASUREMENT

[anthoninlize]

Thanks Thierry.

Today, for floats having experimental sensors it is required that :
The SPECIAL_FEATURES string must include the substring ‘AUX’ for machine parsing

Is that syntax sufficient ? Yes in my opinion.

It depends what is expected by 'machine parsing' then. What would be expected from the parsing at OceanOPS?
We could check easily that, if the string is not empty or different from 'n/a', it contains 'AUX', and if not sending a feedback email.

We can include the special features in the official notification as well, the question is do we do that in any case, or just if it's compliant (ie contains 'AUX')?

[vpaba]

Just a reference to an older discussion on SPECIAL_FEATURES etc.: #8

[tcarval]

It depends what is expected by 'machine parsing' then. What would be expected from the parsing at OceanOPS?

In this "Auxiliary directory" page, it is mentioned:
The Argo Information Centre (AIC) presently tracks the sensors that provide measurements in the PARAMETER list in the meta.nc file.
The AIC can also make the SPECIAL_FEATURES string available.
The SPECIAL_FEATURES string should be suitable to be included as part of notification of floats about to drift into EEZs. It must be clear and completely describe all auxiliary measurements.

For a float, the list of sensors comes from PARAMETER and SPECIAL_FEATURES containing"AUX".
To make public the list of sensors of a floats, the 2 variables should be used.

[anthoninlize]

Thanks. So:

• we'll make sure that we ingest the SPECIAL_FEATURES information properly, and we'll populate it
• we'll add the SPECIAL_FEATURES field on the web dashboard (editing, float sheet)
• if the string contains "AUX" (should it be case sensitive?), we'll include it in the EEZ notification and deployment notification (it might be a mention that some special features exist, redirecting to ocean-ops.org; to not overload the notification)

My only question now is about this:

For a float, the list of sensors comes from PARAMETER and SPECIAL_FEATURES containing"AUX".

"AUX" will indicate relevant value in the string, but it can be something else than a sensor? Am I wrong?

[tcarval]

Personally I do not like upper case strings. So let's decide that "AUX" is not case sensitive (AUX, aux, ... are valid).
AUX indicates that there are auxiliary feature on this float that are stored on GDAC "aux" directory.
It could be something other than a sensor.