Dear Dave
Thanks for this
> https://github.com/twhiteaker/netCDF-CF-simple-geometry/blob/master/README.md
I think your explanation of what is needed and why is very clear, and I like
the present form of the proposal.
You asked me what I'd expect the bounds attribute to point to. This is my only
reservation about the current design. We agree that the simple geometries are
a kind of complicated bounds specification. However, we don't have to use the
existing bounds att with a new purpose because of that. It currently points to
a variable which must be numeric and have particular dimensions; hence one
could tell reliably if it was a simple geometry instead if we insist that the
geometry container variable must be a scalar, for example. So this does work,
but to make it work would require changing existing software, which otherwise
would think this new convention is an error. That wouldn't be friendly.
Therefore I would suggest *not* using the bounds att of the aux coord vars, but
instead giving them a new att e.g. geometry, to point to the geometry container
variable. We can make a rule that it's an error to have both a geometry and a
bounds att, like we do with climatology and bounds att.
I'd also suggest requiring the data variable to have the same geometry att.
That's because CF is generally "centred" on the data variable. If you've found
the data variable, it's convenient to go straight from there to the geometry
spec, rather than having to go via the aux coords. However I can see that you
also want to attach it to the coordinates, since you might want to describe a
geometry without a data variable at all but with nominal coordinates (although,
at present, CF always expects there to be data variables).
Arising from your discussion with Dan, I suppose you could say that if there
is no part_node_count it must imply there is only one part per instance i.e.
you can omit this attribute if it's not needed.
I assume that 0 means inside and 1 outside for the polygon_ring_type. If it's
a binary choice like that, maybe it would be more self-explanatory to call it
outside, or something else which indicates the convention.
I would note that this new convention is applicable for data on a grid too
i.e. on a polyhedron which is composed of more than one type of polygon. Its
usefulness is not limited to DSGs.
Best wishes
Jonathan
Received on Thu Mar 16 2017 - 11:28:38 GMT
