Ethan: Yes, though I'm not that familiar with the details of UGRID, it does (now that you mention it) seem related in some ways to the river/basin topic.
Chris: well, maybe -- but while UGRIDs are "unstructured", there is SOME structure to them -- i.e. they are usually made up of cells with the same number of sides (triangles, quads, etc), or at least a small number (six or less). And the UGRID data structure does assume this.
I know that some 2D codes support cells with many more nodes. Usually we stop 6 nodes, but we also write larger cells. Unfortunately the sparseness of the connectivity matrix increases in such cases. NetCDF 4 offers better solutions for ragged arrays, I believe.
Ethan: I've been thinking of the river/basin
Chris: Rivers can be a 1-d "mesh" which there is support in UGRID for, but I think of basins as being arbitrary often high order polygons.
It was my intention to capture 1D river networks using the 1D mesh, but since the initial formulation of UGRID I jave come to the conclusion that the 1D mesh is sufficient only for the basic river shape. It's just defining the curvature of the 1D space (like in 2D we consider space to be flat or a sphere). Objects and numerical discretizations on the river network are usually either specified using x,y or more frequently branch id and chainage. We have some experience with capturing this in NetCDF but it hasn't been formalized into a draft standard yet.
Chris: Is there any standard for supporting polygons (i.e. what you might put in shape files) in netcdf?
Not that I'm aware of, but OGC involvement will help here. I know that GIS tools sometimes also need connectivity between neighbouring polygons and maybe even connectivity of polygons to 1D breaklines, so there sufficient challenges and some look like things that we've started to formalize using UGRID.
One "arbitrary polygon" feature that we don't have a good solution for yet in UGRID is polgons with holes. We have come across this issue in our finite volume based water quality simulations for which we frequently "aggregate" (or merge) small flow grid cells into arbitrary larger volumes.
Cheers,
Bert
On Tue, Mar 29, 2016 at 6:43 AM, Jonathan Gregory <j.m.gregory at reading.ac.uk> wrote:
Dear Ethan
I agree with Steve about ugrid and aggregation being important topics.
> 1. "UGRID"
The ugrid design is rather CF-compatible and it would be good if they could be
cemented together somehow. ugrid could be a proposed as a chapter of CF but it
doesn't have to be, of course. I suppose the advantage of doing so would be
that CF and ugrid development would subsequently remain compatible.
Could ugrid deal with this one of your agenda items:
> * Drafting a CF enhancement that would add support for complex data
> footprints (e.g., river segments and drainage basins)
I'm not sure what you have in mind but it sounds possibly related.
> 2. "Aggregation" -- CF structures to link multiple files into larger
> conceptual datasets. Time series aggregations, union aggregations
> (associated variables in separate files), and ensemble membership
> are the most obvious applications of this. Another important
> application is "tiled grids" (ref. the "gridspec" proposal).
There are various types of aggregation which should be distinguished, I think.
* Aggregation of variables. This is needed when one variable is split among
several files (often along the time axis) but it can also apply to variables in
the same file (for instance combining ensemble members or time series with the
same time coordinates - Steve's other examples). In general it means combining
several variables to make one variable, by concatenating one or more of their
axes. This can be done entirely using CF metadata and David Hassell and I wrote
a CF proposal for it
http://cf-trac.llnl.gov/trac/ticket/78 a long time ago,
which David has since implemented in cf-python software. I believe that this
approach is fine for CMIP6 purposes, for example.
* Aggregation of domains. By this I mean regarding domains which have their
own axes as part of a larger domain, like gridspec does. It's not aggregation
of variables in the same sense as above because the axes can't be concatenated.
It is similar to ugrid, though, and I think it would be good if an extension
to CF like ugrid could be developed for this.
* Aggregation of files. By this I mean regarding several files as one file
*without* associating or joining variables together, just putting them into
one container. This needs rules for dealing with collisions of identically
named variables, like NCO ncks has, or groups could be used, which are also on
Ethan's agenda.
> Harmonizing CF grid mapping with OGC CRS (coordinate reference
> systems), possibly with WKT
It should be possible to translate between CF and OGC CRS descriptions. Some
extensions to help with this are in
DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.
Received on Tue Apr 05 2016 - 00:16:37 BST
