Opened 2 months ago

Last modified 8 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:


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:

Rendered proposal (the Geometries section is at the end):

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 (3)

comment:1 Changed 2 months ago by jonathan

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


comment:2 Changed 10 days 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 8 days ago by davidhassell


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:

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,


Note: See TracTickets for help on using tickets.