Re: [CF-metadata] Feedback requested on proposed CF Simple Geometries

Dear Jonathan, As I mentioned in my response yesterday, we have worked through these issues and think we have a compromise proposal for the community. Since the conversation is active, I’ll go ahead and share our work with the list in a follow up email in a moment. A couple specific

Re: [CF-metadata] Feedback requested on proposed CF Simple Geometries

Dear Ben and Chris Following Chris's comment about preferring variables to multi-valued attributes, here are the examples for linestring and multipolygon redone so that both use variables to store the counts of parts and nodes. In this scheme more variables and dimensions are needed, but it may

Re: [CF-metadata] Feedback requested on proposed CF Simple Geometries

Dear Jonathan and Chris, Thanks for bringing this thread back to life! Please don’t take silence on the part of Ben and I as a lack of activity. We have been working on a thorough proposal and are hoping to share it with the community very soon. Chris, I think you will find a number of

Re: [CF-metadata] Feedback requested on proposed CF Simple Geometries

Dear Chris > I really don't like storing info like this in an attribute -- I think it > should be another variable, instead. it is a bit tricky with "nested" data > like this, but yu can link variables together with something like: > > int SOMETHING(station); // number of polygons in each

Re: [CF-metadata] Feedback requested on proposed CF Simple Geometries

My CDL-reading was off a bit yesterday, so: On Tue, Jan 31, 2017 at 1:22 AM, Jonathan Gregory wrote: > So, for example, we could > store three timeseries, each applying to a collection of polygons, like > this: > > dimensions: > station = 3; // collections of

Re: [CF-metadata] Feedback requested on proposed CF Simple Geometries

Dear Chris Thanks for your comments on my comments. Here are replies to a subset! > > Your aim is to > > describe the network alone. ... > > You would like to have SOMETHING alone in the file, just to > > describe the network itself. CF doesn't do this at present (domain without > > data), > >

Re: [CF-metadata] Feedback requested on proposed CF Simple Geometries

A couple quick comments: I think we're close here, so that's good. I'm not that clear on where tehre are decisions left to be made, but I'll highlight two: ... > Your aim is to > describe the network alone. > ... > a collection of timeseries is stored as a > data variable with a single

Re: [CF-metadata] Feedback requested on proposed CF Simple Geometries

Dear Ben Thanks for your new thoughts. I find this intriguing but still puzzling, and I think this means we are talking at cross-purposes. Perhaps we ought to speak on the phone? However, here are some replies. Maybe this is a clue to our differences: > We intend for this proposal to fit in the

Re: [CF-metadata] Feedback requested on proposed CF Simple Geometries

A little note: On Tue, Nov 1, 2016 at 9:43 AM, Chris Barker wrote: > I'm on shakier ground about when you want to use a GeometryCollection vs a > FeatureCollection, but I _think_ that the point of a geometrycollection is > that you can group different types of geometry --

Re: [CF-metadata] Feedback requested on proposed CF Simple Geometries

A few comments, though you all seem to have this in hand :-) I was asking whether this means that for each *collection* (of points, > lines or > polygons) there is a *single* timeseries. I don't get why this matters -- any number of time series could be associated with a single "entity" --

[CF-metadata] Feedback requested on proposed CF Simple Geometries

Dear Dave > I’ll respond the first question by saying that we are talking about > (time,geometry) NOT (time,node). Good. Thanks for the clarification. > You are correct in thinking that this is analogous to a complex (potentially > multipart) cell. In this case, we feel that it is more

Re: [CF-metadata] Feedback requested on proposed CF Simple Geometries

Dear Ben and Bert Thanks for your emails, which help me to understand the simple geometry proposals better. Just to be clear, I'd like to repeat my first question. > You explain that the need is to specify spatial coordinates with a simple > geometry for a timeSeries variable. For example, this

Re: [CF-metadata] Feedback requested on proposed CF Simple Geometries

Thanks for all the great input, Bert. One comment: > > 5) Besides inventing our own storage format (either in line with UGRID or > CF), a third way was discussed namely: to store the simple geometry shapes > as ascii or binary blobs in an extended format NetCDF 4 file. I think binary blobs is

Re: [CF-metadata] Feedback requested on proposed CF Simple Geometries

Jonathan and CF-Metadata List, Thanks for the suggestions and discussion. We’ve attempted to respond to the major questions and concerns using Jonathan's mail as a template. Apologies in advance if we missed anything outstanding or did not appropriately acknowledge contributions in this thread.

Re: [CF-metadata] Feedback requested on proposed CF Simple Geometries

-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Jonathan Gregory Sent: 22 September 2016 18:26 To: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] Feedback requested on proposed CF Simple Geometries Dear Chris > > If the regions were irregular > > polygons in latitude a

Re: [CF-metadata] Feedback requested on proposed CF Simple Geometries

un...@cgd.ucar.edu] on behalf of Ben Koziol - NOAA Affiliate [ben.koz...@noaa.gov] Sent: 07 September 2016 19:13 To: CF metadata Cc: Bob Simons - NOAA Federal; Whiteaker, Timothy L Subject: [CF-metadata] Feedback requested on proposed CF Simple Geometries Greetings, As part of an

Re: [CF-metadata] Feedback requested on proposed CF Simple Geometries

Hi all, Just a quick note on Chris' CF 2 question (until I have a bit more time to think more fully on this discussion) ... The EC netCDF-CF project that Ben mentioned is working on a number of CF extension efforts that are looking to use features of the netCDF enhanced data model. Those

Re: [CF-metadata] Feedback requested on proposed CF Simple Geometries

On Thu, Sep 22, 2016 at 9:26 AM, Jonathan Gregory wrote: > I didn't suggest parsing attribute strings. The same numbers that Ben > would put > in his x and y auxiliary coordinate variables for a single polygon can > appear > in coordinate bounds variables according to

Re: [CF-metadata] Feedback requested on proposed CF Simple Geometries

Dear Chris > > If the regions were irregular > > polygons in latitude and longitude, nv would be the number of vertices and > > the > > lat and lon bounds would trace the outline of the polygon e.g. nv=3, > > lat=0,90,0 > > and lon=0,0,90 describes the eighth of the sphere which is bounded by the

Re: [CF-metadata] Feedback requested on proposed CF Simple Geometries

Dear Jonathan, I can’t speak to the technical details, but can mention some motivation for simple geometries. Among other applications, NetCDF-CF is now being used as an intermediate & output data format in the US National Weather Service’s National Water Model (NWM). This forecasts

Re: [CF-metadata] Feedback requested on proposed CF Simple Geometries

Dear Ben Thank you for your thoughtful and interesting proposal. I have quite a lot of questions and comments about it. * You explain that the need is to specify spatial coordinates with a simple geometry for a timeSeries variable. For example, this could be for the discharge as a function of

[CF-metadata] Feedback requested on proposed CF Simple Geometries

Greetings, As part of an EarthCube project for advancing netCDF-CF [1], we are developing an approach to represent simple geometries in enhanced netCDF-4 with a variable length array backport for netCDF-3. Simple geometries, for example, may be used to associate stream discharge with river lines