So far, we seem to agree that: 1) mid-point should be used if there if not strong arguments for doing so, 2) mid-point is actually the most representative value for _evenly_ averaged quantities, 3) time accumulated/integrated quantities are maybe the exception.
What about integrated quantities along other axis, then? Aerosol Optical Depth (z), Mean Sea Level Pressure (z), broadband reflectance (wavelength), spectral directional-hemispherical albedo (view angles)... at which axis value would they be expected? Let's not forget that, in the end, we are only trying to "patch" over the requirement for a valid axis value (COARDS/Unidata) and that "practical" reasons (like mentionned by Seth for the time associated to NWP fields) might be just as valid as "theoretical" choices. Thomas ----- "Steve Hankin" <[email protected]> wrote: > John Caron wrote: > > 1. The CDM library uses the bounds if they are present. If only the > > > coordinate values are present, the CDM generates bounds. These grids > > > bounds are used by ncWMS and other visualization software to draw > > color filled images. The IDV (I think) uses a contouring algorithm > > > with just the coordinate values. > > > > 2. Spatial coordinates probably want to use midpoint values. > > > > 3. I think theres a good argument that time coordinates want to use > > > the end-point. Seth makes the argument for numerical models. In this > > > case, all the output variables should have the same time coordinate. > > > Im trying to think of a case where thats not true (point > observations, > > radar data etc), and im not thinking of any. > Hi John, > > I'm not understanding the logic that suggests using midpoints for > spatial coordinates, but endpoints for times. Whenever an > applications > sees a particular reason to place the grid point at something other > than > the midpoint (on whatever axis) of course it should do so. That may > lead to placing the grid point at the start, middle or end of the > interval. But the question that is before us is to say what the > default > should be for the case where the boundaries of cell values is clearly > > understood, but it is unclear what coordinate value best to use for > the > grid point. > > All other things being equal using a consistent strategy for space and > > time is the simpler, "KISS", approach. Both instantaneous and > time-interval-averaged values are most naturally encoded using > midpoint > representation (disagreeing with both Seth's conclusion and your > speculation. Are we using terms differently?). The compelling case > for > a time endpoint may be continuous integrals (e.g. accumulated > precipitation). If one has a mixture of model variables to output and > > the interpretations of their time coordinates needs to be different, > then placing two different time axes into the file is the only way to > > eliminate the confusion. Arbitrarily shifting the grid point > locations > by 1/2 time cell will not eliminate confusion, will it? It seems like > > it would merely hide the confusion and increase the chances of > misinterpretation. > > (To be frank, although I have seen many CF datasets using both > midpoint > and start-point times, I have never encountered one previously that > uses > the end point of the time interval. It seems possible that as a > practical matter this choice may introduce confusion rather than > reduce it.) > > - Steve > > ===================== > > Seth's argument about confusion remains the same if one > > > > 4. Perhaps "interval of accumulation" is different enough that one > > should just encode it in a separate attribute or auxiliary > coordinate > > on the data variable. Numerical models can have different variables > > > with different intervals, possibly overlapping. This is perhaps not > > > really the same as the bounds on the coordinate, they just share the > > > same codomain (time). An advantage of this approach is that you dont > > > have to create new coordinate variables for each data variable, > which > > seems like more trouble than its worth. > > > > > > Seth McGinnis wrote: > >> In the case of 'raw' output from numerical models, it probably > makes > >> sense to > >> use the end-point of the time interval rather than the mid-point. > > >> That's the > >> moment for which the model stores the data, whether they're > >> instantaneous > >> values (intensive variables) or time-averages over the previous > timestep > >> (extensive variables). > >> > >> If you used the mid-point of the interval for extensive variables, > they > >> wouldn't have the same time coordinates as the intensive variables, > > >> which would > >> be very confusing. Using the end-point keeps everything aligned. > >> > >> --Seth > >> > >> > >> On Thu, 12 Nov 2009 14:41:26 +0000 (UTC) > >> Thomas Lavergne <[email protected]> wrote: > >> > >>> Dear Jonathan, > >>> > >>> ----- "Jonathan Gregory" <[email protected]> wrote: > >>> > >>>> Dear Thomas > >>>> > >>>> I'm not saying the coordinate *must* be the mid-point. If there's > a > >>>> good reason > >>>> for it being something else, then you could choose it to be so. I > was > >>>> suggesting that we could recommend it should be the mid-point if > there > >>>> is > >>>> no strong basis for making another choice. We could also say that > it > >>>> must not > >>>> be outside the bounds. > >>>> > >>> I agree with your recommendation. > >>> But I was also trying to gain support on "which axis value should > I > >>> choose for > >>> my variable" and your answer does not help :-). > >>> I have rather little basis for making the choice of the end time > for > >>> representing an accumulated quantity but, at least, CF does not > >>> forbid it. I > >>> guess I have to seek agreement inside my scientific community and > > >>> that it is > >>> not CF's role to decide upon that. > >>> Are there people interested in taking the discussion further? We > >>> seek the > >>> answer to the question: "In which cases would another choice > (other > >>> than > >>> mid-point) be relevant?". > >>> > >>> Thomas > >>> > >>> > >>> > >>>> You are right, it cannot be missing data. That would break some > >>>> applications, > >>>> anyway. > >>>> > >>>> Cheers > >>>> > >>>> Jonathan > >>>> _______________________________________________ > >>>> CF-metadata mailing list > >>>> [email protected] > >>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > >>>> > >>> _______________________________________________ > >>> CF-metadata mailing list > >>> [email protected] > >>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > >>> > >> > >> _______________________________________________ > >> CF-metadata mailing list > >> [email protected] > >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > >> > > > > _______________________________________________ > > CF-metadata mailing list > > [email protected] > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > _______________________________________________ > CF-metadata mailing list > [email protected] > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
