Rework Wiki Intro to the Specification

[dblodgett-usgs]

Building on the general readme overview in #53 - Modify what's there to reflect changes.

• No more node sharing.
• Use count instead of start point.
• Remove some options like closure_convention.
• Complete CRS section
• Complete associating with data section.
• Complete Python and R sections.
• Remove section on multi-geometry-type abstraction?

[dblodgett-usgs]

Getting going on this, will work on it offline today, hope to have something up by evening.

[dblodgett-usgs]

Alright. https://github.com/twhiteaker/netCDF-CF-simple-geometry/wiki

This brought up a few things about my draft implementation that should get another look.

• multipoint should probably use part_node_count rather than node_count.
• the code should probably take a variable list to attach the geometry to and add the geometry attribute to those variables. The examples should have the geometry attached to the name variable.
• we should take another look at the CRS topic. I drafted an idea of how to handle it.
• is a polygon with a =hole a multi-part geometry? It's weird to have part_node_count on a single part geometry just because it has a hole... but I guess that's how it should be? Or is a polygon with a hole a multipolygon?

[twhiteaker]

What's your rationale for part_node_count rather than node_count? I think of a multipoint as a multipart geometry, where each part consists of a single node, so part_node_count would always be an array of ones whose length equals the number of parts in the instance. I think node_count is more appropriate since you really are counting the number of nodes in the multipoint. In my wiki edit, I reworded the multipoint sections to reflect this.

Your CRS idea sounds good.

WKT and GeoJSON distinguish polygons with holes and from multipolygons. A polygon with holes does consist of multiple parts, so to speak, but there is only one exterior ring (in the WKT+GeoJSON definition). The "multi" in multipolygon means you can have more than one exterior ring.

Can you reword the geometry section so that it doesn't use node_count, since that attribute isn't required for point geometries? Something like this (if I got your intent)?

geometry Carried by any 1-d variable whose instances are represented by geometries defined by the geometry container variable named by this attribute. Comparable to the cell_bounds attribute but links to representative geometry for each position in the variable.

Are we sure we want to require anticlockwise outside rings and first-last node equivalence? If so, we should add those checks to our code.

[dblodgett-usgs]

I wasn't thinking about the multipoint right. You are right, each part is of length 1.

The geometry attribute definition is going to be a bit picky to make sure we match the CF spec terminology and are clear about how things relate. I find it ironic that the simplest case is actually the most complicated because it is so degenerate. How is this for the geometry attribute definition?

geometry
Carried by any variable that shares a dimension with the geometry instances defined by the geometry container variable named by this attribute. Comparable to the cell_bounds attribute, but links to representative geometry for each position of dimension of the shared dimension.

I think we should require both anticlockwise and first-last equivalence. I know my code gets these right, but I don't test for it super carefully. The R spatialPolygons object that I coerce data to/from enforces it for me so I'm kind of playing it lose.

[twhiteaker]

Geometry definition looks good.

The Python implementation doesn't enforce those polygon requirements. I'd want to lean on Shapely to determine node order for me. This may mean a major rewrite of the code, using Shapely geometries as our primary object type rather than our custom type. It might actually make the code cleaner, with the downside being a tighter dependency on Shapely and its geometry types, i.e.., no true curves or ellipses in the future. I need to ruminate a little more.

[twhiteaker]

Wiki looks good. Python implementation is a separate issue.