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-requ...@cgd.ucar.edu> escreveu: > > Send CF-metadata mailing list submissions to > cf-metadata@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-requ...@cgd.ucar.edu > > You can reach the person managing the list at > cf-metadata-ow...@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.neum...@dkrz.de> > To: cf-metadata@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-901590de7...@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.greg...@reading.ac.uk> > To: "cf-metadata@cgd.ucar.edu" <cf-metadata@cgd.ucar.edu> > Subject: [CF-metadata] Question to Parametric Vertical Coordinates > Message-ID: <20191015173207.ga12...@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.greg...@reading.ac.uk> > To: "cf-metadata@cgd.ucar.edu" <cf-metadata@cgd.ucar.edu> > Subject: [CF-metadata] Suggestion for standard names for bottom > current and due to tides and Stokes drift > Message-ID: <20191015173548.ga22...@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 <marceloandri...@gmail.com----- > > Date: Mon, 14 Oct 2019 22:02:50 -0300 > From: Marcelo Andrioni <marceloandri...@gmail.com> > To: cf-metadata@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 > marceloandri...@gmail.com > _______________________________________________ > CF-metadata mailing list > CF-metadata@cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > ----- End forwarded message ----- > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > CF-metadata mailing list > CF-metadata@cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > ------------------------------ > > End of CF-metadata Digest, Vol 198, Issue 8 > ******************************************* -- Marcelo Andrioni marceloandri...@gmail.com _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata