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 responses
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 be
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 thing
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 col
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 polygons
> time = UNLIMIT
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),
>
>
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 dimensi
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
Jonathan, Chris, and CF-Metadata,
Thank you kindly for the replies and apologies for the delay on the
response. Please see responses below. The comments were very useful in
introducing some conceptual hangups and will help us moving forward. As
usual, looking forward to continued discussion.
A qu
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 -- but still want them to
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" -- just
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 analogous
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 c
On Tue, Sep 27, 2016 at 3:52 PM, Chris Barker wrote:
> 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
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 a
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.
Y
ecause of the link to 1D numerical modelling, this
> will be discussed in a separate thread in the UGRID community first.
>
> Best regards,
>
> Bert
>
> -Original Message-
> From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of
> Jonathan Greg
s,
Bert
-Original Message-
From: CF-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 we
oun...@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 a
Dear Ethan
> 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 efforts will all target CF 2 rather than CF 1.x. However,
> as with the Simple Geometries, we should also expect sug
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 efforts
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 the existing convention.
O
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
Sorry, not enough time to really read tis all carefully, but a couple
comments from a brief look:
>
> 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
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 streamflow
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 tim
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
27 matches
Mail list logo