Letter to CF introducing proposed 1.8 changes.

[dblodgett-usgs]

After a conversation at ESIP, I wanted to jot down a draft of a cover letter to the the CF list regarding our proposal.

@bekozi - I started a list of arguments for our selected approach... please help fill in, you have the most well thought through arguments for it. I couldn't find the list you wrote out in an issue some place though.

I borrowed heavily from the readme. Thinking we might just link to the wiki description(s) too?

[bekozi]

There is no solid list for this. They have sort of been collected in the CF-Metadata list mails which have the drafts on the wiki. Where did you start to collect the rationale? I can add to that. Did you get push back on any issues in particular?

This year has started out harried on my end, and I am wondering if @dblodgett-usgs may want to guide this moving forward. @dblodgett-usgs also seems better plugged into the community! This will need strong face-to-face advocacy moving forward and @dblodgett-usgs is in all the right places. :smile:

I gave the DSG document an initial look through. This approach seems reasonable (editing the DSG spec as opposed to a new spec doc).

• I don't like how the point geometry is kept separate. Is this necessary to be compliant with DSG? The coordinate indexing is superfluous for points so it makes sense in that regard. It seems we should permit points to be stored in the newer geometry format as well.
• It is also not clear how the featureType attribute conundrum is resolved. Is DSG okay with a non-global feature type attribute? I didn't see where this attribute should go now that the global requirement is removed. I think it is on the data variables?
• Are we going exclusive with zero-based indexing only? I noticed that in the doc, but I thought we were supporting one-based as well. Zero is fine with me...just want to confirm.

Food for thought: I have been thinking about coordinate indexing in relation to parallelism. I wonder if an optional attribute should be added to the coordinate index variable indicating coordinate have been de-duplicated. This can be done with a unique search in the index variable, but I wonder if there are advantages to indicating this outright. I was trying to think how one would distribute the coordinates for a read in parallel and this information would be useful from an implementation perspective.

Overall this is looking good and many thanks for getting the doc started!

[dblodgett-usgs]

Yeah, I think I can take the lead from here. I'll need to rely on @bekozi and @twhiteaker for backup, but I'll do what I can.

• I don't really like point and geometry being separate either, but to keep this backward compatible, I think we should leave the point stuff essentially un-touched?
• We need to add more about allowing featureTypes to be on data variables. The proposal coming together for swath data is doing the same thing, so I think it's just a thing we are going to do now.
• I think we are going zero indexed only.

The de-duplicate flag would be interesting... I'm open to throwing it in there if it would be helpful.

[twhiteaker]

Made some minor edits to the cover letter. I'm pretty happy with it.

What do you think about bringing the Google doc link to the forefront? It kinda gets lost in the middle of the letter.

[dblodgett-usgs]

Makes good sense. I'll reorder things to get it toward the top.

[bekozi]

Late to the party... I made a pass-through: https://github.com/bekozi/netCDF-CF-simple-geometry/wiki/Proposal-Cover-Letter-to-CF-list/_compare/d7b0f3f291adf26395202aa33fa04f0ed5894732...7fc97bf76b431cd45f7c69fe9bb6a268bfbb8684.

I think it is looking good, and thanks @dblodgett-usgs for taking the lead on this!

[dblodgett-usgs]

Thanks, @bekozi

I've shared this with a couple USGS colleagues for a final proof and will send out when they get back to me.