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 [email protected]
_______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
