Hi Jonathan and Olivier
backward(s)_scattering_coefficient
why not simply
backscatter_coefficient
Tx
Hans
>>> "olivier lauret" <olauret at cls.fr> 10/04/2008 18:00 >>>
Dear Jonathan,
Thanks for comments. The other parallel CF discussion about introducing
standard names for SST data, that became a "What standard names are for"
topic is really interesting and raises a few questions about what we
(scientists, developers, users) are expecting from metadata in general.
Anyway about altimeter data, I agree with many of your points and I
think my colleagues from satellite altimetry community will be happy
with this. In particular I am glad to see that "altimeter_range" is OK,
the previous suggestion is a (bad!) idea of mine, I was anticipating
what we will do when we'll have to deal with plenty of standard names
that represent quite the same quantity. I have no need of a generic name
for the moment, and we personnaly prefer to use "altimeter_range".
Now we have:
sea_surface_height_correction_due_to_air_pressure_and_wind_at_high_frequency
(m)
Correction representative of high frequency fluctuations (for period
lower than 20 days) of sea surface topography; this must be added to
altimeter range.
sea_surface_height_correction_due_to_air_pressure _at_low_frequency (m)
Correction representative of inverted barometer effect (for period
higher than 20 days); this must be added to altimeter range.
backward(s)_scattering_coefficient
(I think it is better not to name it with no reference to the kind of
surface, because backscattering coefficient can be used in satellite
altimetry to study ice sheets, for example. Moreover some flags are used
to discriminate if measurement is on ocean or land.)
sea_surface_height_bias_due_to_sea_surface_roughness (m)
altimeter_range_correction_due_to_ionosphere (m)
Correction representative of atmosphere's electron content in the
ionosphere; this must be added to altimeter range.
altimeter_range_correction_due_to_wet_troposphere (m)
Correction representative of liquid water in the troposphere; this must
be added to altimeter range.
altimeter_range_correction_due_to_dry_troposphere (m)
Correction representative of dry gases in the troposphere; this must be
added to altimeter range.
altimeter_range (m)
height_above_reference_ellipsoid (m)
sea_surface_height_amplitude_due_to_geocentric_ocean_tide (m)
sea_surface_height_amplitude_due_to_earth_tide (m)
sea_surface_height_amplitude_due_to_pole_tide (m)
sea_surface_height_amplitude_due_to_equilibrium_ocean_tide (m)
sea_surface_height_amplitude_due_to_non_equilibrium_ocean_tide (m)
geoid_height_above_reference_ellipsoid (m)
The only point where I have doubts is about the pair:
mean_sea_surface_height_above_reference_ellipsoid (m)
mean_sea_surface_height_above_geoid (m)
Well, I already thought about using cell_methods, but I am not sure it
is a good idea: the dataset is based in grid points, and actually the
data themselves are not obtained by averaging sea_surface_height data
(in facts it is a more complex computing). That's why I think maybe we
should introduce standard names for these parameters too..Shouldn't we?
Cheers,
Olivier.
-----Message d'origine-----
De : Jonathan Gregory [mailto:jonathan at met.reading.ac.uk] De la part de
Jonathan Gregory
Envoy? : mercredi 9 avril 2008 21:18
? : olivier lauret
Cc : cf-metadata at cgd.ucar.edu; Jeremy Throwe; Picot Nicolas; Julia
Figa; Jean Paul Dumont; Kenneth Casey; John Lillibridge; psicard at cls.fr;
Hans Bonekamp
Objet : Re: [CF-metadata] Adding new standard names for satellite
altimetry
Dear Olivier
Thanks for your altimeter-related names. Some comments:
>
sea_surface_height_correction_due_to_air_pressure_and_wind_at_high_frequency
(m)
> sea_surface_height_correction_due_to_air_pressure_at_low_frequency
(m)
I think "correction" is fine, myself. To me it would mean something
that was
added to the data to obtain the (final) sea surface height. There is a
possible
ambiguity that a user might not know whether it had been added already,
or
should be added, and the definition would have to clarify that. It
would
be good to clarify "high" and "low" frequency in the definition too,
if
they can't be specified precisely. If they can be specified precisely
you
could consider using a coord variable to do so.
> backscatter_coefficient
Perhaps sea_surface_backscatter_coefficient would be a helpful
clarification.
I note that we have got backwards_scattering_coefficient in an
existing
standard name. Would that be a possibility? (I think, however, that it
should
have been "backward", not "backwards", as "backward" seems much more
common in
Google - but that's a trivial point.)
> sea_surface_height_bias_due_to_sea_surface_roughness (m)
OK.
> ionosphere_path_delay (m)
> troposphere_wet_path_delay (m)
> troposphere_dry_path_delay (m)
It strikes me as a bit surprising to have a delay in units of length.
Perhaps
these could be called altimeter_range_correction_due_to_X like the
first ones?
> range (m), or scanned_pulse_distance (m)
I think altimeter_range would be most informative, since that is what
the
measurement is usually called, as you say. There would be no problem
in
defining a lidar_range separately. Do you have a need for a generic
name
at the moment?
> altitude_above_reference_ellipsoid (m)
That should be height_above, I think, because the standard_name of
altitude
means height above the geoid, and height in general means vertical
distance.
> sea_surface_height_amplitude_due_to_geocentric_ocean_tide (m)
> sea_surface_height_amplitude_due_to_earth_tide (m)
> sea_surface_height_amplitude_due_to_pole_tide (m)
> sea_surface_height_amplitude_due_to_equilibrium_ocean_tide (m)
> sea_surface_height_amplitude_due_to_non_equilibrium_ocean_tide (m)
> geoid_height_above_reference_ellipsoid (m)
OK (given definitions of the tides).
> mean_sea_surface_height_above_reference_ellipsoid (m)
> mean_sea_surface_height_above_geoid (m)
What does "mean" mean here? Is it a time-mean? If so, that should be
indicated
in the cell_methods, not the standard name. We already have names like
these
without "mean_" prefixed.
Best wishes
Jonathan
Cliquez sur l'url suivante
https://www.mailcontrol.com/sr/wJs8cE55UiQ!afMmuJt8jDpE4S2mLLdpjxie3ip3zEkPk83c8S!g9ebUd9RAfRANANuk8rMF1jN1saSXVPDMF2HlGD5l6pLYNGhBsGJRcDiWGmmA9cDre0tBGbA6Ho6mH9!SNQjTnjklT2iNbzfM4LhLtzhmDX9KxLgQzuXCQCOBUcFXN3XxcUcnODbmPoWMWleOeRFGiOlWQcLMIAU6ItkzRWvZw8j!
si ce message est ind?sirable (pourriel).
Received on Mon Apr 14 2008 - 02:58:30 BST
