Hello Jonathan, yes I am not proposing at_bottom as a suffix,
_at_sea_floor is the one to be used. Just recapitulating, my
suggestions of variables to be included in the CF standard names table
are:
# at sea floor currents
eastward_sea_water_velocity_at_sea_floor
northward_sea_water_velocity_at_sea_floor
sea_water_to_direction_at_sea_floor
sea_water_speed_at_sea_floor
# currents due to tides
eastward_sea_water_velocity_due_to_tides
northward_sea_water_velocity_due_to_tides
sea_water_to_direction_due_to_tides
sea_water_speed_due_to_tides
# currents due to stokes drift
sea_surface_wave_stokes_drift_eastward_velocity
sea_surface_wave_stokes_drift_northward_velocity
sea_surface_wave_stokes_drift_to_direction
sea_surface_wave_stokes_drift_speed
Thank you.
Em ter, 15 de out de 2019 ?s 14:35, <cf-metadata-request at cgd.ucar.edu> escreveu:
>
> Send CF-metadata mailing list submissions to
> cf-metadata at cgd.ucar.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> or, via email, send a message with subject or body 'help' to
> cf-metadata-request at cgd.ucar.edu
>
> You can reach the person managing the list at
> cf-metadata-owner at cgd.ucar.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of CF-metadata digest..."
>
>
> Today's Topics:
>
> 1. Re: Clarification of what content is allowed to be in a
> single file (Daniel Neumann)
> 2. Question to Parametric Vertical Coordinates (Jonathan Gregory)
> 3. Suggestion for standard names for bottom current and due to
> tides and Stokes drift (Jonathan Gregory)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 15 Oct 2019 17:21:08 +0200
> From: Daniel Neumann <daniel.neumann at dkrz.de>
> To: cf-metadata at cgd.ucar.edu
> Subject: Re: [CF-metadata] Clarification of what content is allowed to
> be in a single file
> Message-ID: <2528de0e-978c-b62a-d668-901590de7ae0 at dkrz.de>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> The background of my question is that the IOOS Compliance Checker [1,2]
> identifies 2D or 3D grids as individual feature types (lines 7001 to 1708 in
> [3]) and throws an error. Although I find it reasonable to forbid the
> combination of regularly gridded and e.g. trajectory data in one file, I would
> not interprete the CF Conventions in this sense.
>
>
> [1] https://compliance.ioos.us/index.html
> [2] https://github.com/ioos/compliance-checker
> [3]
> https://github.com/ioos/compliance-checker/blob/master/compliance_checker/cfutil.py
>
>
> Am 09.10.2019 um 15:20 schrieb Jim Biard:
> > Good question, Daniel!
> >
> > On 10/9/19 7:37 AM, Daniel Neumann wrote:
> >> Dear List,
> >>
> >> If data in a file is of a specific feature type (time series, trajectory,
> >> ...), only one feature type is allowed per file (Chapter 9.1. Features and
> >> feature types). Regularly gridded data (not ragged) has no feature type. Is it
> >> allowed to have gridded data and data of one feature type in a single file? Or
> >> is gridded data considered to have an implicit feature type?
> >>
> >> It might be reasonable to keep these two types of data separated in different
> >> files to prevent misinterpretation of the one or other variable. However, I
> >> cannot find a passage in the CF Conventions that explicitly prohibits it.
> >>
> >> Cheers,
> >> Daniel
> >>
> >
>
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/pkcs7-signature
> Size: 5352 bytes
> Desc: S/MIME Cryptographic Signature
> URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20191015/11b70395/attachment-0001.p7s>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 15 Oct 2019 17:31:42 +0000
> From: Jonathan Gregory <j.m.gregory at reading.ac.uk>
> To: "cf-metadata at cgd.ucar.edu" <cf-metadata at cgd.ucar.edu>
> Subject: [CF-metadata] Question to Parametric Vertical Coordinates
> Message-ID: <20191015173207.GA12383 at met.reading.ac.uk>
> Content-Type: text/plain; charset="us-ascii"
>
> Dear Daniel
>
> > Does "Parametric Vertical Coordinates" mean that there is a mathematical
> > function, which describes the relation between the relevant (auxiliary)
> > coordinate variables and the parametric vertical coordinate?
>
> In section 4.3.3, it means that the physical vertical coordinate z(k,j,i),
> where i,j are indices of the horizontal dimensions and k of the vertical,
> can be written as as a mathematical function
> z=f(V1(k)[,V2(k),...],H1([t,]j,i)[,H2([t,]j,i)...])
> where V1,... depend only on level, and H1,H2,... depend only on horizontal
> position (and perhaps on time). I think that describes all the cases of
> Appendix D, but someone may correct me! The entries in App D describe the
> physical vertical coordinate and how to compute it with the formula f.
>
> > Speaking in terms of the example provided further below: Value of `depth` is
> > a `f(time, lev, lat, lon)`, whereas `f` is a mathematical function with
> > considerably less parameters than `depth` has values. Then `depth` is a
> > parametric vertical coordinate.
> >
> > Formulated the other way arond: Is `depth` NOT a parametric vertical
> > coordinate if its values are somehow set by hand (by a human), calculated by
> > some nested if-clause, or by some iterative procedure?
> >
> > If `depth` is not a parametric vertical coordinate in this sense, am I
> > allowed to use it in a CF-compliant file?
>
> The depth variable in your example is a 4D auxiliary coordinate variable. It
> is CF-compliant, but it's not a CF parametric vertical coordinate variable.
>
> > Example:
> >
> > ...
> > int lev(lev):
> > lev:standard_name = "model_level_number" ;
> > lev:long_name = "model_level_number" ;
> > lev:positive = "down" ;
> > lev:units = "1" ;
> > double depth(time, lev, lat, lon);
> > depth:long_name = "depth" ;
> > depth:positive = "down" ;
> > depth:standard_name = "depth" ;
> > depth:units = "m" ;
> > depth:axis = "Z" ;
> > float some_data_variable(time, lev, lat, lon);
> > some_data_variable:standard_name = "some_standard_name" ;
> > some_data_variable:units = "some_unit" ;
> > some_data_variable:coordinates = "depth"
>
> Best wishes
>
> Jonathan
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 15 Oct 2019 17:35:21 +0000
> From: Jonathan Gregory <j.m.gregory at reading.ac.uk>
> To: "cf-metadata at cgd.ucar.edu" <cf-metadata at cgd.ucar.edu>
> Subject: [CF-metadata] Suggestion for standard names for bottom
> current and due to tides and Stokes drift
> Message-ID: <20191015173548.GA22798 at met.reading.ac.uk>
> Content-Type: text/plain; charset="us-ascii"
>
> Dear Marcelo
>
> These look fine to me, thanks. Just to be clear - you're *not* proposing
> at_bottom, are you? I agree with you that at_sea_floor would be the right
> phrase to use.
>
> Best wishes
>
> Jonathan
>
> ----- Forwarded message from Marcelo Andrioni <marceloandrioni at gmail.com-----
>
> Date: Mon, 14 Oct 2019 22:02:50 -0300
> From: Marcelo Andrioni <marceloandrioni at gmail.com>
> To: cf-metadata at cgd.ucar.edu
> Subject: [CF-metadata] Suggestion for standard names for bottom current and
> due to tides and Stokes drift
>
> Hello,
>
> I would like to suggest the inclusion of standard names for u, v,
> speed and direction for bottom current and due to tides and Stokes
> drift:
>
> An example of model output with bottom velocity is the HYCOM NCODA forecast:
> https://tds.hycom.org/thredds/catalog/GLBv0.08/expt_93.0/data/forecasts/runs/catalog.html?dataset=GLBv0.08/expt_93.0/data/forecasts/runs/FMRC_RUN_2019-10-13T12:00:00Z
> water_u_bottom (m/s) = Eastward Water Velocity =
> eastward_sea_water_velocity_at_bottom
> water_v_bottom (m/s) = Northward Water Velocity =
> northward_sea_water_velocity_at_bottom
>
> based on existing variables:
> sea_water_potential_temperature_at_sea_floor
> sea_water_temperature_at_sea_floor
> sea_water_salinity_at_sea_floor
> sea_water_pressure_at_sea_floor
>
> my suggestion would be:
> eastward_sea_water_velocity_at_sea_floor
> northward_sea_water_velocity_at_sea_floor
> sea_water_to_direction_at_sea_floor
> sea_water_speed_at_sea_floor
>
> An example of model output with currents due to tides and Stokes drift
> is the Mercator Forecast:
> http://marine.copernicus.eu/services-portfolio/access-to-products/?option=com_csw&view=details&product_id=GLOBAL_ANALYSIS_FORECAST_PHY_001_024
>
> based on existing variables:
> eastward_sea_water_velocity_assuming_no_tide
> northward_sea_water_velocity_assuming_no_tide
> ocean_vertical_momentum_diffusivity_due_to_tides
> ocean_vertical_tracer_diffusivity_due_to_tides
>
> my suggestion would be:
> eastward_sea_water_velocity_due_to_tides
> northward_sea_water_velocity_due_to_tides
> sea_water_to_direction_due_to_tides
> sea_water_speed_due_to_tides
>
> Stokes drift is present in the current CF table with:
> sea_surface_wave_stokes_drift_x_velocity
> sea_surface_wave_stokes_drift_y_velocity
> I think it could help to add
> sea_surface_wave_stokes_drift_eastward_velocity
> sea_surface_wave_stokes_drift_northward_velocity
> as aliases to make it clear it is zonal and meridional currents, and
> not just along the grid X and Y dimensions.
>
> Thank you very much.
> --
> Marcelo Andrioni
> marceloandrioni at gmail.com
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
> ----- End forwarded message -----
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
> ------------------------------
>
> End of CF-metadata Digest, Vol 198, Issue 8
> *******************************************
--
Marcelo Andrioni
marceloandrioni at gmail.com
Received on Tue Oct 15 2019 - 12:48:14 BST
