CF-Metadata List Response

[bekozi]

Jonathan Gregory sent a thoughtful response to our proposal via the cf-metadata list. We should put together a response over the next week or so. I'll post a draft on the wiki unless someone else gets to it first.

[twhiteaker]

Currently completely swamped. Will gladly review draft.

[dblodgett-usgs]

I'll be flying home tomorrow into Monday. Have you made progress I should review or would you like me to draft this @bekozi ?

[dblodgett-usgs]

Here's what I've got. Needs you guys' input, especially in bolded sections.

Dear Jonathan,

Apologies for taking a bit to get back to you, but we wanted to be a deliberate in formulating our thoughts. We’ve responded to your sections in order rather than interleaving.

Need/purpose: Yes, you’ve got this mostly right. It’s common to have a collection of lines or polygons with associated time series, like a weather station, only the feature is a line or polygon rather than a point.

DSG wording: Our proposal would certainly necessitate changing the language in section 9.1 What it would change to depends on the outcome of this work.

Use of bounds to encode polygons: Since sets of polygons, leaving ‘meshes’ as would be encoded using UGRID aside for the moment, would never have the same number of nodes, having a dimension to hold the number of vertices, as you would for bounds, doesn’t work. Additionally, the cell bounds concept doesn’t include the structure and semantics needed to support MultiLines and MultiPolygons or holes.

Use of UGRID: Others have already commented on this, and we’ll reiterate. The purpose of this addition to CF is to encode data stored in the typical ’simple features’ de-facto standard as is implemented by the shape file or geodatabase feature class/table types. The genesis of this work was with full knowledge of UGRID. The major difference is that this encodes polygons as independent unrelated features with no shared nodes or edges. There are details of UGRID that would complicated this use case and aspects of this that would not make sense in the context of a UGRID mesh.

Use of NetCDF4 vlen arrays: Yes, let’s leave that conversation for another time. We mostly want to be forward compatible understanding that vlen provides a more simple and some would say more elegant way of handling these data.

coordinate_index variable: Our example may not be complete enough to fully demonstrate the use case we are trying to describe. The example given, inspired by the DSG Continuous Ragged Array encoding, but uses a ‘stop’ variable rather than a ‘count’ variable. The detail that may not be apparent is that each ‘simple feature’, for which there may be the series variables, may actually be multiple polygons (with hole polygons or not) or lines. So in the example you suggest an ‘inside_outside’ variable, we should maybe show an example where the geom dimension is more than 1 and a given ‘geom’ has multiple polygons prior to the ‘stop’ coordinate. The encoding of words was meant to convey this, but may not have been sufficient?

Configurable break values: I don’t remember why we did this.

Clockwise/anticlockwise and closure: I don’t have an opinion on this. Maybe there is an argument to be made? I think specifying how it should be done would be fine…

Multiple Geometries: Our example with the dimension geom=1 is meant to convey that it is incomplete. We should make one with geom=3 to be more clear? The use of ‘stop’ needs to be demonstrated with polygons.

[twhiteaker]

I agree about geom=3. I'll add an example to the VLEN netCDF3 wiki page.

[dblodgett-usgs]

👍

[twhiteaker]

geom=3 example added. Not sure it's the right place for it, but there it is. https://github.com/bekozi/netCDF-CF-simple-geometry/wiki/VLEN-Arrays-in-NetCDF-3

[bekozi]

Thanks for the draft @dblodgett-usgs and the additional examples @twhiteaker. There has been a lively discussion on the CF list. I'll get my edits in later today and hopefully we can send a response tomorrow (9/27) or the day after.

[bekozi]

I hacked at @dblodgett-usgs's text. I decided to interleave as it helped me track the response better. Let me know when you guys have made your changes, and I will make another pass: https://github.com/bekozi/netCDF-CF-simple-geometry/wiki/Letter-to-CF-Response-20160926.

[twhiteaker]

We have strong use cases for lines and polygons, but what about multiparts?

The following sentence is awkward.

In the example you suggesting an ‘inside_outside’ variable,

Did you mean suggested? Also, I suspect there's an inside_outside example I'm missing. I'm not on the CF list (but have requested to join).

Ah, I'm missing a character array example, too.

[marqh]

Use of bounds to encode polygons: Since sets of polygons, leaving ‘meshes’ as would be encoded using UGRID aside for the moment, would never have the same number of nodes, having a dimension to hold the number of vertices, as you would for bounds, doesn’t work. Additionally, the cell bounds concept doesn’t include the structure and semantics needed to support MultiLines and MultiPolygons or holes.

this is a key point. These are collections of polygons, not collections of cells of the same shape.

Similarly, the notion of a 'point' location for a polygon is difficult. It is a polygon, not one of a collection of similar cells.

[twhiteaker]

I got on the CF list. I really appreciate the time and thoughtfulness that Jonathan put into his response. I hope he and others provide more feedback upon seeing our geom=3 example, which I wish we had included in the first email.

I'm pretty happy with reply on the wiki. I attempted to correct the "In the example you suggesting an ‘inside_outside’ variable" phrasing. Thanks Ben and Dave for putting this together.

[dblodgett-usgs]

:shipit:

[bekozi]

Thanks, all. I'm sending now...