Matthias Lankhorst mlankhorst at ucsd.edu
Thu Jan 17 18:33:59 MST 2019

```Hello,

still trying to resolve how to define my section endpoints and which way
is counted as positive...

While I can provide (scalar) lat/lon that would be something like the
section mid-point, and proper cell_bounds with these, the result is that
the user then knows a lat/lon box where my data are from. The user does
not yet know which ones of the box vertices are my actual section
endpoints (could be the NW-to-SE corner or SW-to-NE). I can see a
solution along the following idea:

1. We define lat/lon variables with separate variables linked in
cell_bound attributes. We clarify that these are interpreted
sequentially, i.e. the line connects latbounds(i,1)/lonbounds(i,1) to
latbounds(i,2)/lonbounds(i,2) and so on. Default assumption is that
the section between the points is shaped as great circle. Neither the
lat/lon nor the bounds have to be monotonic, in order to express
odd-shaped sections like OSNAP. Beware: for an east-west section across
e.g. 16N, the latitude bounds would be [16 16], which might be confusing
since the size of that cell would appear to be be zero.

2. We point to these lat/lon variables in the "coordinates" attribute of
the actual transport data.

3. We amend the standard_name definition to clarify that when looking in
the direction in which the line is sequentially defined in the lat/lon
bounds, positive is considered to be 90 degrees to the left. I assume
this would not only apply to my particular standard_name, but all of:
ocean_volume_transport_across_line
sea_ice_area_transport_across_line
sea_ice_transport_across_line
sea_water_transport_across_line
snow_transport_across_line_due_to_sea_ice_dynamics

Together, that might look like the following. I guess the fundamental
logic is that the lat/lon are not true coordinates with each having its
own dimension, but they are auxiliaries and each have the same dimension
expressing the count of stations along the line (much like a trajectory
versus an orthogonal grid).

LATITUDE(numberofsegments)
standard_name="latitude"
axis="Y"
cell_bounds="LATITUDE_BOUNDS"

LATITUDE_BOUNDS(numberofsegments,dim2)

LONGITUDE(numberofsegments)
standard_name="longitude"
axis="X"
cell_bounds="LONGITUDE_BOUNDS"

LONGITUDE_BOUNDS(numberofsegments,dim2)

TIME(TIME)
standard_name="longitude"
axis="T"
cell_bounds="TIME_BOUNDS"

TIME_BOUNDS(TIME,dim2)

PRESSURE(PRESSURE)
standard_name="sea_water_pressure_due_to_sea_water"
axis="Z"
positive="down"
cell_bounds="PRESSURE_BOUNDS"

PRESSURE_BOUNDS(PRESSURE,dim2)

OCEAN_TRANSPORT(TIME)
standard_name="ocean_volume_transport_across_line"
coordinates="TIME PRESSURE LATITUDE LONGITUDE"

Is this reasonable?

Regards, Matthias

On Thu, 2019-01-17 at 06:39 -0700, cf-metadata-request at cgd.ucar.edu
wrote:
> Message: 3
> Date: Thu, 17 Jan 2019 13:39:20 +0000
> From: Jonathan Gregory <j.m.gregory at reading.ac.uk>
>         ocean_volume_transport_across_line
> Content-Type: text/plain; charset="us-ascii"
>
> Dear Matthias
>
> > Recap: I have a time series of ocean volume transport (given in
> > Sverdrup) across a line. The line has two end points, and the
> transport
> > is computed over a specific depth range. I would like to represent
> this
> > in a clever way in a netcdf file with CF conventions.
> >
> > As far as variables go, I really only have two (happy to add more to
> > e.g. contain the cell boundaries), and their standard_names are:
> >    time
> >    ocean_volume_transport_across_line
> >
> > I know how to include bounds for the time such that I can show over
> how
> > many days my data were averaged.
>
> Yes, including a cell_methods of "mean" for time.
>
> > I suppose I could figure out the depth range by including a single
> > scalar for depth, with associated bounds, and having a "coordinates"
> > attribute on my transport that points to the depth. Does this sound
> > correct?
>
> Yes, that would be right. The cell_methods for depth would be "sum".
>
> > How about the two section endpoints? And when I have those, how
> would
> > the user know which direction across that section is counted
> positive?
>
> So far, the tranport across line has been used only with "named"
> sections. The
> names of the sections haven't been standardised in CF, but there's a
> list of
> them for CMIP6, defined by endpoints, in Griffies et al. 2016, Table
> J1,
> doi:10.5194/gmd-9-3231-2016. The reason for using names is that the
> exact line
> depends on the model, so matching the names facilitates model
> comparison. I
> don't remember a discussion about how to specify them more
> quantitatively. I
> think it would be reasonable to attach scalar latitude and longitude
> (like the
> depth range) and use their bounds to specify the endpoints.
>
> The standard name table doesn't mention the sign convention. We should
> have
> defined that. Griffies et al. says it's positive for northwards and
> eastwards.
> But what if the normal to the section is north-west or south-east? Do
> you have
> any in those quandrants? We ought to generalise this.
>
> Best wishes
>
> Jonathan
>
> >
> > Cheers, Matthias
> >
> >
> >
> > On Tue, 2016-04-26 at 08:25 -0700, Matthias Lankhorst wrote:
> > > Dear CF,
> > >
> > > what is the proper way to define the shape and boundaries of an
> oceanic
> > > section, for which I want to report the volume transport across
> that
> > > section?
> > >
> > > The use case is an irregular-shaped section like OSNAP
> > >
> (http://www.o-snap.org/wp-content/uploads/2013/11/20160329_OSNAP_planeview.jpg), and the property to be reported is the seawater volume transport in a given depth range as a timeseries with this CF standard_name:
> > > ocean_volume_transport_across_line
> > >
> > > There needs to be some ancillary variable to say what the line
> > > coordinates are, and I am not sure how to squeeze that into
> > > "cell_bounds".
> > >
> > > In addition, how about the lower limit vertically if this is the
> > > seafloor? If the transports were to be everything below e.g. 1000
> m,
> > > would it be appropriate to state vertical cell bounds as 1000 to
> 5000 m,
> > > even if the ocean is not 5000 m deep? I.e. is the user intelligent
> > > enough to realize that "5000" really means "5000 m or the
> seafloor,
> > > whichever is shallower"?
> > >
> > > Thanks, Matthias
> > >

--
_______________________________________

Dr. Matthias Lankhorst
Scripps Institution of Oceanography
9500 Gilman Drive, Mail Code 0230
La Jolla, CA 92093-0230
USA

Phone:  +1 858 822 5013
Fax:    +1 858 534 9820
E-Mail: mlankhorst at ucsd.edu
http://pordlabs.ucsd.edu/mlankhorst/

--
_______________________________________

Dr. Matthias Lankhorst
Scripps Institution of Oceanography
9500 Gilman Drive, Mail Code 0230
La Jolla, CA 92093-0230
USA

Phone:  +1 858 822 5013
Fax:    +1 858 534 9820
E-Mail: mlankhorst at ucsd.edu
http://pordlabs.ucsd.edu/mlankhorst/

```