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:

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 (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.

Jonathan

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

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

Note: See TracTickets for help on using tickets.