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.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20160922/4d93750e/attachment.html>
Received on Thu Sep 22 2016 - 10:00:21 BST
