Good morning Dan,
We are trying to align with 9.3.3 as much as we can. When you say ?where a count variable is used to indicate the number of elements in the main array? which is the ?main?? In my mind that is the node coordinates, which we are counting along ? which seems in alignment with 9.3.
You are right, it can only be dropped if _all_ the geometries in the file are single part, and yeah, it?s not that much overhead and probably doesn?t matter much in the grand scheme. I do want to make sure we don?t say ?meh, good enough? though!
- Dave
> On Mar 15, 2017, at 7:12 AM, Hollis, Dan <dan.hollis at metoffice.gov.uk> wrote:
>
> 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:dblodgett at usgs.gov]
> 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 <dan.hollis at metoffice.gov.uk <mailto:dan.hollis at metoffice.gov.uk>> 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: dan.hollis at metoffice.gov.uk <mailto:dan.hollis at metoffice.gov.uk> 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 <http://www.metoffice.gov.uk/climate>
>
>
> From: CF-metadata [mailto:cf-metadata-bounces at cgd.ucar.edu <mailto:cf-metadata-bounces at cgd.ucar.edu>] 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 <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20170315/0655f9b2/attachment.html>
Received on Wed Mar 15 2017 - 06:57:06 GMT
