Dear Jonathan, Thank you for looking things over.
Makes sense that we would add a new ‘geometry’ attribute that would point at the geometry container variable and be in both the node coordinates and the data variables. Yes, the 0 or 1 is meant to be inside or outside. We thought that would be specified in the document. I hadn’t thought of it as a true/false, but 0 and 1 are nice because they can be treated that way. We could also use O and I, but I’m hesitant to use characters, where an integer will suffice. We will choose a suitable name that allows the variable to be interpreted as a true/false. Your suggestion is a good starting point, I’ll see how Tim feels about it. I spent a lot of brain cycles trying to figure out how a “count”ed contiguous ragged array of nodes could be made to apply to a grid. Would you have a multi-dimension count variable? I guess I’d need to see the cdl structure to understand that case. I’m stuck on the “count” needing to be on the instance dimension. Tim and I will reconcile some of this in the README as well as a more detailed wiki writeup in that GitHub repository then submit the Trac ticket with a proposed section for the spec unless others have input we should consider? Regards, - Dave > On Mar 16, 2017, at 12:28 PM, Jonathan Gregory <j.m.greg...@reading.ac.uk> > wrote: > > 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 > _______________________________________________ > 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
