On Tue, Jan 2, 2018 at 11:03 AM, Karl Taylor <[email protected]> wrote:
> In CMIP we require that both missing_value and _FillValue be defined as > 1.e20 for requested variables that occupy only a portion of the global > grid. For bounds variables, I'll suggest that when needed, both _FillValue > and missing_value also be defined as 1.e20. That way software that relies > on either one will work. > good practice, as the use-cases for _FillValue and missing_value often get conflated. But it's still a good idea to have one clearly specified as the preferred one to use for a particular meaning. > My understanding of UGRID is that it provides for a much fuller > description of a grid than CF. > well, yes, that's why it exists -- but I'm not sure "fuller" is the right word -- it provides a standardised way to describe unstructured meshes, which CF simply does not support. For CMIP, I think we can recommend UGRID be used for non-standard grids, > but I'm reluctant to require it > "standard" isn't the issue - -the issue is whether the grid is structured or not -- if it is not a structured grid, then there may be a way to describe it in a CF compliant way , but there won't be ONE way to describe given type of grid, which, again, is why UGRID conventions were developed. Why be reluctant? I haven't followed CMIP at all, but it sure looks like the goal is to have things standardized. Most grids for most purposes I think can be adequately described with the > CF-mandated attributes. Does anyone disagree? > Well, yes -- again, I haven't followed CMIP, so I don't know what types of grid in practice you need to support. If you don't need to support unstructured grids, then, there isn't an issue. But if you do, you really want to standardize how they are defined, and yes, they CAN be adequately described by CF (a UGRID file, should also be valid CF). What UGRID provides not an alternative to CF, but an extension that standardizes how those grids are described. By the way, the UGRID standard maps pretty well to how unstructured grid models generally store their grids and read and write them anyway, so it shouldn't be a heavy lift to support it. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [email protected]
_______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
