Dear Jonathan, OK. This tracks with how I was thinking.
I was actually thinking this would be section 7.1.1. The rest of my comments about what I think we’ll do in the specification is here (https://github.com/twhiteaker/netCDF-CF-simple-geometry/issues/58 <https://github.com/twhiteaker/netCDF-CF-simple-geometry/issues/58>) for the record. Thank you so much for all your time on this, I am very pleased with the outcome. - Dave > On Mar 17, 2017, at 10:00 AM, Jonathan Gregory <[email protected]> > wrote: > > Dear Dave > > Yes, I think you would have a multi-dimensional node_count. I think that fits > the design, because a DSG can always be thought of as though it were an > orthogonal array, albeit sparsely filled, with an instance dimension and an > element dimension. The instance dimension is a discrete axis in the sense of > CF section 4.5. Instead of this single discrete axis, you could have several > spatial axes. > > In fact, in the case I mentioned of a polyhedron, I imagine the data array > might have to be 1D anyway, because you can't generally flatten a polyhedron > into a rectangular 2D array of faces. So that would be formally just like the > case of a DSG. > > Until/unless there is a use-case for the application of simple geometries > outside DSGs we don't need to say anything about this, but I suggest that the > possibility of its being needed means your new section doesn't belong in ch 9. > > Best wishes > > Jonathan > > ----- Forwarded message from David Blodgett <[email protected]> ----- > >> Date: Thu, 16 Mar 2017 14:19:43 -0500 >> From: David Blodgett <[email protected]> >> To: Jonathan Gregory <[email protected]> >> CC: [email protected] >> Subject: Re: [CF-metadata] Geometries in NetCDF Update >> X-Mailer: Apple Mail (2.3259) >> >> 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 <[email protected]> >>> 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 >>> [email protected] >>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >>> >> > > ----- End forwarded message ----- > _______________________________________________ > CF-metadata mailing list > [email protected] > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
