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 ; } _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata