Opened 4 months ago

Last modified 7 days ago

#164 new enhancement

Simple Geometries in CF

Reported by: whiteaker Owned by: cf-conventions@…
Priority: medium Milestone:
Component: cf-conventions Version:
Keywords: geometry Cc:

Description

Dave Blodgett, others, and I have developed a contribution which augments Chapter 7 of the CF conventions with the ability to describe simple geometries such as lines and polygons. This is useful when encoding feature geometries for data variables like average precipitation over a watershed or velocity in a river segment.

We proposed this contribution on GitHub? via a pull request, in part to help test the GitHub? workflow for making changes to CF. This has been a bit of a struggle as we iron out the GitHub? kinks. In the meantime, Jonathan Gregory suggested that to move the process along, we open a trac ticket for this as a proposed change to 1.7.

GitHub? pull request and discussion: https://github.com/cf-convention/cf-conventions/pull/115

Rendered proposal (the Geometries section is at the end): https://github.com/dblodgett-usgs/cf-conventions/blob/7768e33e7edff459482e8ef8057ea6b8e015c9eb/ch07.adoc

I appreciate your consideration of this proposal. If more discussion of this proposal is required, I ask that you continue the discussion in GitHub?. Thanks!

Tim Whiteaker

Change History (7)

comment:1 Changed 4 months ago by jonathan

Thank you for your hard work on this proposal, which I support in its current form.

Jonathan

comment:2 Changed 2 months ago by davidhassell

Thanks indeed, Tim et al.

I'd like to volunteer to moderate this discussion, and shall shortly post a summary of what I think are the outstanding issues.

All the best, David

comment:3 Changed 2 months ago by davidhassell

Hello,

As far as I can tell, the only conceptual outstanding issue with this ticket is whether multi- and single-part geometry types should be combined into a single type - i.e. all geometries could be "multi", with the current "single" instances being a special case of multi. This is discussed here: https://github.com/cf-convention/cf-conventions/pull/115/files/5f8c0859b7158fd3ebe94a898bbd2837233a22a3#r122266537

I think that the arguments presented against a sole type are reduced interoperability and increased software complexity. The argument for is reduced conventions complexity (although Chris Little might want to add to this?).

Related to this single/multi issue is that the proposal currently allows different cells to have different geometry types. Is this actively desired? or required? Is there a case for insisting that all cells have the same type, for simplicity? I would have thought that we do not need to constrain the proposal in this way, but it's worth mentioning to see what others think.

A minor point: A table defining each of the geometry types would be useful - it seems that currently they are introduced with the assumption that you arlready know what they are.

All the best,

David

comment:4 Changed 4 weeks ago by davidhassell

Hello - forwarding a comment from Chris Little that didn't make it here:

As David mentioned me, I though it worth adding an argument for 'Multi' types - they clarify some inherent potential parallelism in the structures, and the structures, and their processing, are ones that map to the parallel hardware found in GPUs. GPUs have evolved over the last 30 years to process exactly these kinds of structures.

As a provocative aside, this strikes me like an "Assembler is faster than Fortran so we stick with Assembler" kind of debate.

Chris, running for cover.

comment:5 Changed 4 weeks ago by davidhassell

Hello,

It seems from comments at ​https://github.com/cf-convention/cf-conventions/pull/115/files/5f8c0859b7158fd3ebe94a898bbd2837233a22a3#r122266537] and on this ticket that all geometries being "multi" is acceptable to everyone - does anyone disagree?

Assuming this is the case, do the "single" lines need to be removed from the table that was added: https://github.com/dblodgett-usgs/cf-conventions/blob/7768e33e7edff459482e8ef8057ea6b8e015c9eb/ch07.adoc

If that is so, we ought to be close to wrapping this ticket up (subject to modifications to the conformance document).

Many thanks,

David

comment:6 Changed 3 weeks ago by whiteaker

In October I consolidated the items in the table to simply: point, line, and polygon. I also edited the rest of the text to reflect this consolidation. You can view the latest version of the files here: https://github.com/cf-convention/cf-conventions/pull/115/files

I created a branch for conformance updates with most of the new text here: https://github.com/twhiteaker/Conformance/blob/Geometry_Conformance/conformance.adoc#75-geometries

...plus a mention of geometry node coordinates here: https://github.com/twhiteaker/Conformance/blob/Geometry_Conformance/conformance.adoc#4-coordinate-types

Does that address all outstanding issues on this proposal?

comment:7 Changed 7 days ago by davidhassell

Hello,

It would be great if any interested parties could review Tim's latest changes on this ticket. In particular the many conformance requirements.

I have a minor suggestion:

In paragraph 2, a polygon has that it should be assumed that the first and last node are connected. Note that CF does not require the first and last node to be identical but allows them to be coincident if desired. However, in table 7.1 it says a polygon is <snip> a closed line (i.e., the first point in the line is coincident with the last point).

Also the conformance recommends (not insists) that the coordinates of the first and last node in a given ring of a polygon geometry should be coincident.

This is a bit confusing to me. I think that table 7.1 should be made consistent with paragraph 2, and the recommendation should be removed.

All the best,

David

Note: See TracTickets for help on using tickets.