Hi Dave,

I see your point about using node counts for both quantities. I guess I was 
expecting something similar to the contiguous ragged array representation 
described in 9.3.3 of the convention, where a count variable is used to 
indicate the number of elements in the main array. Would there be any merit in 
trying to align your proposal with this approach?

I agree that one part per geometry will be the common case. However 
part_node_count can only be dropped if _all_ the geometries in the file have 
only one part. In a real situation the geometries are likely to be comprised of 
many nodes, so the overhead of always storing both a part count and a node 
count doesn’t seem that great to me.

At the end of the day it probably doesn’t matter too much which approach is 
used as either one stores the same information. I’m not an R programmer (so 
haven’t studied your code) but it seems like you’ve already demonstrated that 
counting nodes is easy enough. I imagine users of such files will want tools 
that quickly allow them to visualise the geometries (e.g. using GIS, or an 
enhanced ncview), so as long as it’s straightforward to pull out the 
information then that’s all that matters.

Regards,

Dan


From: David Blodgett [mailto:[email protected]]
Sent: 14 March 2017 12:49
To: Hollis, Dan
Cc: CF metadata
Subject: Re: [CF-metadata] Geometries in NetCDF Update

Dear Dan,

Glad you found this version more clear. We’ve learned a lot about how to 
communicate the need for this and the hope is that the latest proposal is going 
to be much more familiar to those who already know CF. Sounds like we achieved 
that.

We _could_ use “part_count_per_geom" and “node_count_per_part” where we are 
using node_count for each right now.


My feeling on this is two fold.
1) using node counts for both feels less confusing because it is only one kind 
of count.
2) In the common case of 1 part per geometry, the “node_count_per_part” can be 
dropped all together.


I had written a basic implementation of our old indirect index approach and 
refactored it over the last few days to use this new count approach. I found 
that counting nodes was very straight forward. You can see my writer 
here<https://github.com/dblodgett-usgs/NCDFSG/blob/master/R/addGeomData.R> and 
my reader 
here<https://github.com/dblodgett-usgs/NCDFSG/blob/master/R/FromNCDFSG.R> if 
anyone’s curious and can tolerate R code.

Best,

- Dave


On Mar 14, 2017, at 5:12 AM, Hollis, Dan 
<[email protected]<mailto:[email protected]>> wrote:

Hi Dave et al,

Thanks for all your work on drafting this proposal. I’ve found some of the 
previous technical discussions re geometries a bit tricky to follow in detail 
but your latest text and example are nice and clear.

One thought – If I understand correctly, the number of parts per geometry has 
to be inferred from node_count and part_node_count. For example, the first 
geometry has two parts because the first element of node_count (10) equals the 
sum of the first two elements of part_node_count (5 + 5). Why not simply store 
the part count itself? i.e. instead of:

node_count = 10, 5;

you’d have:

part_count = 2, 1;

The sum of the elements in part_count (i.e. 3, in this example) would need to 
equal the number of elements in part_node_count and part_type.

Regards,

Dan


Dan Hollis   Climatologist
Met Office   Hadley Centre   FitzRoy Road   Exeter   Devon   EX1 3PB   United 
Kingdom
Tel: +44 (0)1392 884535   Mob: +44 (0)7342058682   Fax: +44 (0)1392 885681
E-mail: [email protected]<mailto:[email protected]>   
Website: http://www.metoffice.gov.uk<http://www.metoffice.gov.uk/>
For UK climate and past weather information, visit 
http://www.metoffice.gov.uk/climate


From: CF-metadata [mailto:[email protected]] On Behalf Of David 
Blodgett
Sent: 14 March 2017 01:54
To: CF metadata
Subject: [CF-metadata] Geometries in NetCDF Update

Dear CF,

Based on feedback we’ve received and the phone call we held last week, Time 
Whiteaker and I have worked up a mostly complete new draft of how to store 
geometries in NetCDF. We’d greatly appreciate more eyes on it if you have time 
or interest.

It’s been written up in some detail here: 
https://github.com/twhiteaker/netCDF-CF-simple-geometry/blob/master/README.md

Feel free to open issues in that GitHub repository to track further 
conversation or follow up on list.

Best,

- Dave

_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Reply via email to