Hi Jonathan, Our existing GRIB to netCDF mapping of the accumulated precipitation data places the data at the forecast hours (with all the other model data) and doesn't include any cell bounds information. I would like to add cell bounds information while maintaining backward compatibility with software that doesn't understand cell bounds. Also, I would like to maintain the conceptual model, as I understand it, held by the forecasters who use this data.
Though I agree that the grid point location for extensive quantities is somewhat arbitrary for spatial dimensions. For time, it does not seem as arbitrary. Because of the directionality of time, the latest point in the interval seems most appropriate for the grid point. Now, I'll try to restate my original question a bit more clearly ... Is there a fundamental reason not to allow the association of multiple boundary variables with a single coordinate variable (by way of a data variable that uses the coordinate variable)? Thanks, Ethan Jonathan Gregory wrote: > Dear Ethan > > You are right, boundary variables are associated with coordinate variables. > That is because you need to supply point coordinates as well as cell bounds. > I think it is usually natural to regard both the extent of a cell and the > coordinate of the point as aspects of the definition of the cell. Of course > for > extensive quantities, like accumulated precipitation, the cell bounds are > more important, and the coordinate value is more arbitrary. I would argue that > it is helpful to have different time coordinate variables for each of your > data variables. They happen to have the same-size dimension in your example, > but the bounds and coordinates don't correspond, and it could be confusing to > share the time axes, when really they are not the same. If the time-coordinate > is taken to be the middle of the interval, as people often do, the 3-h bounds > have coordinates 1.5, 4.5, 7.5, ..., while the 6-h bounds have coordinates > 3, 6, 9, ... These should not share a coordinate variable. > > Best wishes > > Jonathan _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
