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, 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.



Christopher Barker, Ph.D.

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
CF-metadata mailing list

Reply via email to