[CF-metadata] Extension of Discrete Sampling Geometries for Simple Features

From: Jonathan Gregory <j.m.gregory>
Date: Tue, 7 Feb 2017 15:34:48 +0000

Dear Dave

Thanks for being so accommodating and flexible.

> 1) Rename geometry as topology and geom_type as topology_type.
> While I?d be open to something other than geom, topology is odd. If this is really ?node_collection_topology_type? I guess I could be convinced, but would be curious how people react to this. (Especially in relation to UGRID)

The difference between a line and a polygon is topological, I would say,
rather than geometrical. However, let's see how others understand these terms!
If you keep "geometry" I would like to appeal not to abbreviate it to "geom"
since we usually do not abbreviate in CF. (Abbreviations can make things harder
to remember and may cause inconsistencies since there may be more than one
possible abbreviation.)

> 2) This extension is more appropriate as an extension to the concept of cell bounds than the addition of a complex time-invariate type of discrete sampling geometry.
> Having just re-read the cell bounds chapter, I think it would over complicate the cell bounds to include this material. My basic issue here is that these geometries do not necessarily have a reference location. They are, rather, first order entities that need to be treated as such. That said, it makes sense that these geometries are not necessarily a good fit for the original intent of Discrete Sampling Geometries. Jonathan suggested they may belong in their own chapter, which may be a good alternative?

Yes, I agree, it may be too much and too different for ch 7 and needs its own
chapter, with cross-ref for relevance. In particular, where ch 7 talks about
polygonal bounds, it should be explained when simple-feature polygons would be
needed instead, with a link, and in the reverse direction.

> Note that the issue of coordinates is sticking out like a sore thumb. Below, I?ve attempted to reconcile Jonathan?s ideas regarding coordinates with my thoughts about how these geometries are ?first order entities? that don?t have a single representative x and y. The spatial coordinates can be said to reside in the system of geometries described in the ?sf? container variable? I realize this goes against the idea of coordinates a bit, but I think it is holding with the spirit of the attribute?

sf can't be an aux coord var because it doesn't have a dimension of the data
variable, so it can't be named by someData:coordinates. However it would be
OK to include someVariable in someData:coordinates, to give the representative
locations, if that's what it is. As you suggest, instance_name could also be
named in someData:coordinates.

Best wishes

Jonathan

netcdf multipolygon_example {
dimensions:
 node = 47 ;
 part = 9 ;
 instance = 3 ;
 time = 5 ;
 strlen = 5 ;
variables:
 char instance_name(instance, strlen) ;
   instance_name:cf_role = "timeseries_id" ;
 double someVariable(instance) ;
   someVariable:long_name = "a variable describing a single-valued attribute of a polygon" ;
   someVariable:coordinates = "sf" ; // or "instance_name"?
 int time(time) ;
   time:units = "days since 2000-01-01" ;
 double someData(instance, time) ;
   someData:coordinates = "time sf" ; // or "time instance_name"?
   someData:featureType = "timeSeries" ;
   someData:geometry="sf";
 int sf; // containing variable -- datatype irrelevant because no data
   sf:geom_type = "multipolygon" ; // could be node_topology_type?
   sf:node_count_variable="node_count";
   sf:node_coordinates = "x y" ;
   sf:part_count = "part_node_count" ;
   sf:part_type = "part_type" ; // Note required unless polygons with holes present.
   sf:outer_ring_order = "anticlockwise" ; // not required if written in spec?
   sf:closure_convention = "last_node_equals_first" ; // not required if written in spec?
   sf:outer_type_code = 0 ; // not required if written in spec?
   sf:inner_type_code = 1 ; // not required if written in spec?
 int node_count(instance);
   node_count:long_name = ?count of coordinates in each instance geometry" ;
 int part_node_count(part) ;
   part_node_count:long_name = ?count of coordinates in each geometry part" ;
 int part_type(part) ;
   part_type:long_name = ?type of each geometry part" ;
 double x(node) ;
   x:units = "degrees_east" ;
   x:standard_name = "longitude" ; // or projection_x_coordinate
   X:cf_role = "geometry_x_node" ;
 double y(node) ;
   y:units = "degrees_north" ;
   y:standard_name = ?latitude? ; // or projection_y_coordinate
   y:cf_role = "geometry_y_node"
// global attributes:
    :Conventions = "CF-1.8" ;

data:

 instance_name =
  "flash",
  "bang",
  "pow" ;

 someVariable = 1, 2, 3 ;

 time = 1, 2, 3, 4, 5 ;

 someData =
  1, 2, 3, 4, 5,
  1, 2, 3, 4, 5,
  1, 2, 3, 4, 5 ;

 node_count = 25, 15, 7 ;

 part_node_count = 5, 4, 4, 4, 4, 8, 6, 8, 4 ;

 part_type = 0, 1, 1, 1, 0, 0, 0, 1, 0 ;

 x = 0, 20, 20, 0, 0, 1, 10, 19, 1, 5, 7, 9, 5, 11, 13, 15, 11, 5, 9, 7,
    5, 11, 15, 13, 11, -40, -20, -45, -40, -20, -10, -10, -30, -45, -20, -30, -20, -20, -30, 30,
    45, 10, 30, 25, 50, 30, 25 ;

 y = 0, 0, 20, 20, 0, 1, 5, 1, 1, 15, 19, 15, 15, 15, 19, 15, 15, 25, 25, 29,
    25, 25, 25, 29, 25, -40, -45, -30, -40, -35, -30, -10, -5, -20, -35, -20, -15, -25, -20, 20,
    40, 40, 20, 5, 10, 15, 5 ;
}
Received on Tue Feb 07 2017 - 08:34:48 GMT