Hi all, Just a quick note on Chris' CF 2 question (until I have a bit more time to think more fully on this discussion) ...
The EC netCDF-CF project that Ben mentioned is working on a number of CF extension efforts that are looking to use features of the netCDF enhanced data model. Those efforts will all target CF 2 rather than CF 1.x. However, as with the Simple Geometries, we should also expect suggestions for changes to CF 1.x spinning out of these efforts. The CF-2 discussion has been pretty quite for awhile now. However, I expect it will be more active as these various CF extension efforts start seeking more community input and making proposals. Cheers, Ethan On Thu, Sep 22, 2016 at 12:00 PM, Chris Barker <chris.bar...@noaa.gov> wrote: > Sorry, not enough time to really read tis all carefully, but a couple > comments from a brief look: > >> >> If the regions were irregular >> polygons in latitude and longitude, nv would be the number of vertices >> and the >> lat and lon bounds would trace the outline of the polygon e.g. nv=3, >> lat=0,90,0 >> and lon=0,0,90 describes the eighth of the sphere which is bounded by the >> meridians at 0E and 90E and the Equator. I think, therefore, we do not >> need an >> additional convention for points or polygonal regions. > > > this seems fine for this simple example, but burying a bunch of > coordinates of a complex polygon in a text string in an attribute is really > not a good idea -- the coordinates of a polygon should be in the array data > one way or another, rather than having to parse out attribute strings. > > * I suspect that geometries of this kind can be described by the ugrid >> convention http://ugrid-conventions.github.io/ugrid-conventions, which is >> compliant with CF. Their purpose is to describe a set of connected points, >> edges or faces at which values are given, > > > I'm not so sure -- UGRID is about defining a bunch of polygons that all > share vertices, and are all of the same order (usually all triangles, or > quads, or maybe hexes). if they are a mixture, you still store the full set > (say, six vertices), while marking some as unused. But it's not that well > set up for a bunch of polygons of different order. > > Not too bad if there are only one or two complex polygons, but it would be > a bit weird -- you'd have vertices and boundaries, but no faces. And you'd > lose t order of the vertices (thought that could probably be added to the > UGRID standard) > > >> whereas in your case you'd give a >> single value for the whole set, but the description of the geometry itself >> might be similar. Have you had a look at whether ugrid could meet your >> needs? >> If it almost does so, perhaps a better thing to do would be to propose >> additions to ugrid. We would like to avoid having more than one way to >> describe >> such geometries. >> > > Ben has been involved in UGRID, so I'm sure he's thought this out. For my > part, I think it's really a different problem, though it would be nice if > it were as similar to UGRID as possible. > > * So far CF does not say anything about the use of netCDF-4 features (i.e. >> not >> the classic model). We have often discussed allowing them but the general >> argument is also made that there has to be a compelling case for >> providing a >> new way to do something which can already be done. (Steve Hankin often >> made >> this argument, but since he's mostly retired I'll make it now in his name >> :-) >> > > Maybe it's time to embrace netcdf4? It's been a while! Though maybe for CF > 2.* -- any movement on that? > > >> If there are two ways to do something, software has to support both of >> them. We >> already have ways to encode ragged arrays, so is there a compelling case >> for >> needing the netCDF-4 vlen array as well? > > > I think the ragged array option ins fine -- though I haven't looked at > vlen arrays enough to know if they offer a compelling alternative. One > issue is that the programming environments that we use to work with the > data may not have an equivalent of vlen arrays. > > * Similarly, you propose attributes for clockwise/anticlockwise node order >> and >> for the polygon closure convention. > > > This should match the OGC conventions as much as is practical. > > -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 > > chris.bar...@noaa.gov > > _______________________________________________ > CF-metadata mailing list > CF-metadata@cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > >
_______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata