Dear Ben and Bert Thanks for your emails, which help me to understand the simple geometry proposals better. Just to be clear, I'd like to repeat my first question.
> You explain that the need is to specify spatial coordinates with a simple > geometry for a timeSeries variable. For example, this could be for the > discharge as a function of time across some line in a river (your example), > or I suppose it could be an average temperature as a function of time for > the Atlantic Ocean, where you wanted to supply the polygon which drew the > outline of the basin. Have I got the idea? to which you replied > Yes, you have this mostly right. It’s common to have a collection of points > (weather stations), lines (stream reaches), or polygons (hydrologic > catchments) with an associated time series I was asking whether this means that for each *collection* (of points, lines or polygons) there is a *single* timeseries. For instance, in your example of a single geometry composed of several polygons, there is a single number for each time. But that is not the case for weather stations; for each weather station there is a timeseries, and at each time there is a different number (value of temperature, precipitation or whatever) for each weather station. You also write, "The US National Weather Service’s National Water Model (NWM) ... forecasts streamflow rates in about 2.7 million stream segments averaging 2km." The stream network is a MultiLineString geometry, but I don't think there is just one value of streamflow applying to the entire network at any given time; I guess there is a different timeseries for each stream segment. But in my example above, the Atlantic Ocean is a single polygon with a single timeseries for its average temperature, not a different timeseries for each node. Thus I am unclear about the dimensions of the data. In terms of your original example, does the data have dimensions (time,geometry, where geometry=1) or (time,node)? This seems to me to be a crucial difference. In the former case the simple geometry can be regarded as a more complex alternative to cells bounds - the cell has a complicated geometry of nodes and lines, but it's still a single cell. In the latter case you're providing many timeseries in an unstructured geometry, which is what ugrid describes. Which do you have in mind? Nonetheless in both cases the geometries have to be described. I think the difference is how we attach this description to the data or coordinates, rather than how the description is constructed. You propose the index variable in order for the convention to be like ugrid. However this still seems to me to be an unnecessary complexity and use of space if you aren't going to have many shared nodes. I think the case for having another convention, distinct from ugrid, is stronger if it is *unlike* ugrid in this respect, and therefore simpler as well. I agree that repeating the inside/outside flag many times is wasteful. That, coupled with your clarification that you may have several geometries, each consisting of several elements (points, lines, polygons), means that you need, in effect, a ragged array of ragged arrays (geometry,element,node). This is more complicated than DSGs, but it seems to me it would be reasonably easy to understand if your multi-geometry example https://github.com/bekozi/netCDF-CF-simple-geometry/wiki/VLEN-Arrays-in-NetCDF-3#multipolygon-example was stored something like this: geom=3; part=11; node=36; int number_of_parts(geom); number_of_parts:parts="number_of_nodes"; int number_of_nodes(part); number_of_nodes:inout="inout"; char inout(part); float x(node); float y(node); number_of_parts=6, 3, 2; number_of_nodes=4, 3, 3, 3, 3, 3, 3, 5, 3, 3, 3; inout="OIIIOOOIO"; x=0, 20, 20, 0, 1, 10, 19, 5, 7, 9, 11, 13, 15, 5, 9, 7, 11, 15, 13, -40, -20, -45, -20, -10, -10, -30, -45, -30, -20, -20, 30, 45, 10, 25, 50, 30; y = 0, 0, 20, 20, 1, 5, 1, 15, 19, 15, 15, 19, 15, 25, 25, 29, 25, 25, 29, -40, -45, -30, -35, -30, -10, -5, -20, -20, -15, -25, 20, 40, 40, 5, 10, 15; where I assume that all polygons are closed. What do you think? Best wishes Jonathan _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
