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 <dblodgett at usgs.gov> -----
> Date: Fri, 17 Mar 2017 10:06:11 -0500
> From: David Blodgett <dblodgett at usgs.gov>
> To: Jonathan Gregory <j.m.gregory at reading.ac.uk>
> CC: cf-metadata at cgd.ucar.edu
> 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 <j.m.gregory at reading.ac.uk> 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 <dblodgett at usgs.gov> -----
> >
> >> Date: Thu, 16 Mar 2017 14:19:43 -0500
> >> From: David Blodgett <dblodgett at usgs.gov>
> >> To: Jonathan Gregory <j.m.gregory at reading.ac.uk>
> >> CC: cf-metadata at cgd.ucar.edu
> >> 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 <j.m.gregory at 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 at cgd.ucar.edu
> >>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >>>
> >>
> >
> > ----- End forwarded message -----
> > _______________________________________________
> > CF-metadata mailing list
> > CF-metadata at cgd.ucar.edu
> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
----- End forwarded message -----
Received on Fri Mar 17 2017 - 09:15:02 GMT
