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, [email protected] wrote: > Message: 3 > Date: Thu, 17 Jan 2019 13:39:20 +0000 > From: Jonathan Gregory <[email protected]> > To: "[email protected]" <[email protected]> > Subject: Re: [CF-metadata] question about proper cell bounds for > ocean_volume_transport_across_line > Message-ID: <[email protected]> > 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: [email protected] 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: [email protected] http://pordlabs.ucsd.edu/mlankhorst/ _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
