Dear Dave Since it's quite large, and it sort-of has comparable status to bounds, rather than being an addition to bounds, I wouldn't make it a subsect of 7.1. I suggest putting it as 7.2 and renumbering, or appending it as 7.5. Of course you can make a reference to it in 7.1.
I'm happy about this proposal too. Thanks for putting it forward. Best wishes Jonathan ----- Forwarded message from David Blodgett <[email protected]> ----- > Date: Fri, 17 Mar 2017 10:06:11 -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, > > 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 > ----- End forwarded message ----- _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
