Repeat last node for polygons? CCW nodes?

[bekozi]

Software varies on its need for repeated first-last nodes for polygons and counter-clockwise node ordering. ESMF meshes does not expect the last node to repeat, but do want CCW node ordering, for example.

I am inclined to not enforce node repetition or ordering. I think optional attributes to indicate if the data was written with a specific pattern would be useful.

[dblodgett-usgs]

I'd vote to expect repeated but just warn if closure isn't found.

[twhiteaker]

Are there any existing recommendations in the netCDF community on this? I was thinking of UGRID in particular but haven't read the spec yet.

If there aren't netCDF best practices for dealing with CCW nodes and last=first, I'd look at OGC simple features for guidance, which says the last node is repeated and CCW is the outer ring while CW is for holes. As for whether we recommend ("expect") this approach as @dblodgett-usgs suggested or require it, I'm undecided. In an ideal world I would require it so that clients can be dumber, but you risk alienating those who use conflicting formats, and there are several.

[dblodgett-usgs]

IRL, everyone should probably be defensive and warn when they don't find closure... right?

[twhiteaker]

Since CCW/CW matters to some software for computing area, how about we require an attribute poly_outer_ring_order with possible values of clockwise or counter clockwise. This informs software without enforcing a certain order. In other words, you can use CCW or CW just so long as you tell us what you're using. The alternative I think is to require CCW for the outer ring.

[bekozi]

This sounds good. I think we should allow for an indeterminate case, personally, but allowing it to be defined would be useful for clients. I would always test for ordering before trusting the attribute anyway if my software were dependent on this.

Regardless, I feel our implementation should be a good example and do CCW for outer and CW for interiors as @twhiteaker suggests.

[twhiteaker]

An attempt to summarize our answer to the question:

Repeat last node for polygons? CCW nodes?

Not required for our proposed CF enhancement. Our examples, however, will follow OGC guidelines.

We recommend, but do not require, an outer_ring_order attribute for polygon geometry with possible values of clockwise or anticlockwise (CF 1.7 uses anticlockwise, not counter clockwise). We require (though enforcement for compliance checking is onerous) that node orientation of holes is opposite that of outer rings. We recommend following the OGC Simple Feature Access convention of using anticlockwise order for outer rings and clockwise orientation for holes.

We recommend, but do not require, a closure_convention attribute for polygon geometry with possible values of last_node_equals_first or last_node_does_not_equal_first (I don't feel as strongly about this attribute since it's not that hard for ETL software to check and insert a node, so I'm open to dropping this attribute). We recommend following the OGC Simple Feature Access convention of topologically closing polygons by making the first and last polygon node coordinates equivalent.

Once we're in agreement, two new issues arise.

1. Where to put these attributes. This is coevolving with our overall nc4 and nc3 solutions, though for nc4 I imagine they would go on the coordinate index variable.
2. We need a wiki or something to build the text that would eventually make it into the CF conventions.

[bekozi]

We recommend, but do not require, an outer_ring_order attribute for polygon geometry with possible values of clockwise or anticlockwise (CF 1.7 uses anticlockwise, not counter clockwise). We require (though enforcement for compliance checking is onerous) that node orientation of holes is opposite that of outer rings. We recommend following the OGC Simple Feature Access convention of using anticlockwise order for outer rings and clockwise orientation for holes.

Nice. Should we also have an inner_ring_order optional attribute on polygon geometries?

We recommend, but do not require, a closure_convention attribute for polygon geometry with possible values of last_node_equals_first or last_node_does_not_equal_first (I don't feel as strongly about this attribute since it's not that hard for ETL software to check and insert a node, so I'm open to dropping this attribute). We recommend following the OGC Simple Feature Access convention of topologically closing polygons by making the first and last polygon node coordinates equivalent.

I'm okay with this because I also like verbose names and attributes. As another option for closure_convention, we could simply use closed (repeated) or open (last node not repeated). Integer values are also an option. No strong feelings here.

1. Where to put these attributes. This is coevolving with our overall nc4 and nc3 solutions, though for nc4 I imagine they would go on the coordinate index variable.

This is where I'd like to put it. Keeping all geometry-specific attributes here will allows us to store multiple geometry representations in a single group. We'll also need to think about the cf_role attribute.

1. We need a wiki or something to build the text that would eventually make it into the CF conventions.

I started one here: https://github.com/bekozi/netCDF-CF-simple-geometry/wiki. I double-checked and we do have access to the revision history on GitHub wikis.

[twhiteaker]

Should we also have an inner_ring_order optional attribute on polygon geometries?

While outer ring order varies by software, I think it's standard practice that hole order is opposite outer ring order. So as long as outer ring order is specified, we shouldn't need inner ring order. Is that true for the GIS software you use?

I thought about closed and open for closure_convention as well. It's nice and neat...if you know what topologically closed and open means regarding rings. But for the uninitiated, it's confusing because of course your polygons look closed in your GIS display even if the last node isn't actually repeated. I think being more descriptive with this attribute is worth it to head off potential mistakes.

I started one here

Ha ha. Duh, I'ma GitHub noob who forgot about that Wiki button glaring at me from the top.

[twhiteaker]

Once we're in agreement, I'll write this up in the wiki.

[bekozi]

While outer ring order varies by software, I think it's standard practice that hole order is opposite outer ring order. So as long as outer ring order is specified, we shouldn't need inner ring order. Is that true for the GIS software you use?

I don't have a good answer for this. As long as we document that if the outer ring order is specified then the inner ring must be ordered opposite, I think we're good.

I thought about closed and open for closure_convention as well. It's nice and neat...if you know what topologically closed and open means regarding rings. But for the uninitiated, it's confusing because of course your polygons look closed in your GIS display even if the last node isn't actually repeated. I think being more descriptive with this attribute is worth it to head off potential mistakes

Sure. Sounds good. If anything is easy to change, it's the names and values of attributes.

Ha ha. Duh, I'ma GitHub noob who forgot about that Wiki button glaring at me from the top.

The path from noob to pro is a short one indeed. :smile:

Once we're in agreement, I'll write this up in the wiki.

I say go for it. Nothing alarmed me.

[dblodgett-usgs]

I'm staying out of this conversation and will defer to you guys on this level of detail. Way out of my depth.

[twhiteaker]

Added conclusion of this thread to the landing page of the wiki.

[bekozi]

:+1:

[marqh]

Are there any existing recommendations in the netCDF community on this? I was thinking of UGRID in particular but haven't read the spec yet.

UGrid http://ugrid-conventions.github.io/ugrid-conventions/#2d-triangular-mesh-topology states that:

The attribute face_node_connectivity points to an index variable identifying for every face (here consistently triangle) the indices of its three corner nodes. The corner nodes should be specified in anticlockwise (also referred to as counterclockwise) direction as viewed from above (consistent with the CF-convention for bounds of p-sided cells. The connectivity array will thus be a matrix of size nFaces x 3. For the indexing one may use either 0- or 1-based indexing; the convention used should be specified using a start_index attribute to the index variable (i.e. Mesh2_face_nodes in the example below). 

Thus, in their current implementation, there appears to be no repeating of last nodes for faces.

However, UGrid are not currently handling collections of edges as independent entities, which I think this effort aims to do.

If there is no repeating of last nodes to identify closure, a different mechanism will be required to define a lack of closure: a collection of edges which do not form a closed polygon. How could this be done?

[bekozi]

If there is no repeating of last nodes to identify closure, a different mechanism will be required to define a lack of closure: a collection of edges which do not form a closed polygon. How could this be done?

We are using a closure_convention attribute to indicate last node repetition for the polygon case: https://github.com/bekozi/netCDF-CF-simple-geometry/wiki/Examples---VLen-Ragged-Arrays#polygon-2d.

a collection of edges which do not form a closed polygon

I'm not exactly sure what you are asking here, but I think the important distinction is the geom_type. A polygon will always close when converted to a geometry object with or without last node repetition. A linestring will allow connected edges/lines with no closure expectation. We have linestring examples here: https://github.com/bekozi/netCDF-CF-simple-geometry/wiki/Examples---VLen-Ragged-Arrays#linestring-2d. We are attempting to be consistent with OGC geometry types.

Does this make sense?

[twhiteaker]

Anything left to discuss with this issue?

[bekozi]

I don't think so. We can reopen if @marqh would recommend any changes to our proposed method. Closing!