Hi all,
Just a quick note on Chris' CF 2 question (until I have a bit more time to
think more fully on this discussion) ...
The EC netCDF-CF project that Ben mentioned is working on a number of CF
extension efforts that are looking to use features of the netCDF enhanced
data model. Those efforts will all target CF 2 rather than CF 1.x. However,
as with the Simple Geometries, we should also expect suggestions for
changes to CF 1.x spinning out of these efforts.
The CF-2 discussion has been pretty quite for awhile now. However, I expect
it will be more active as these various CF extension efforts start seeking
more community input and making proposals.
Cheers,
Ethan
On Thu, Sep 22, 2016 at 12:00 PM, Chris Barker <chris.barker at noaa.gov>
wrote:
> Sorry, not enough time to really read tis all carefully, but a couple
> comments from a brief look:
>
>>
>> If the regions were irregular
>> polygons in latitude and longitude, nv would be the number of vertices
>> and the
>> lat and lon bounds would trace the outline of the polygon e.g. nv=3,
>> lat=0,90,0
>> and lon=0,0,90 describes the eighth of the sphere which is bounded by the
>> meridians at 0E and 90E and the Equator. I think, therefore, we do not
>> need an
>> additional convention for points or polygonal regions.
>
>
> this seems fine for this simple example, but burying a bunch of
> coordinates of a complex polygon in a text string in an attribute is really
> not a good idea -- the coordinates of a polygon should be in the array data
> one way or another, rather than having to parse out attribute strings.
>
> * I suspect that geometries of this kind can be described by the ugrid
>> convention http://ugrid-conventions.github.io/ugrid-conventions, which is
>> compliant with CF. Their purpose is to describe a set of connected points,
>> edges or faces at which values are given,
>
>
> I'm not so sure -- UGRID is about defining a bunch of polygons that all
> share vertices, and are all of the same order (usually all triangles, or
> quads, or maybe hexes). if they are a mixture, you still store the full set
> (say, six vertices), while marking some as unused. But it's not that well
> set up for a bunch of polygons of different order.
>
> Not too bad if there are only one or two complex polygons, but it would be
> a bit weird -- you'd have vertices and boundaries, but no faces. And you'd
> lose t order of the vertices (thought that could probably be added to the
> UGRID standard)
>
>
>> whereas in your case you'd give a
>> single value for the whole set, but the description of the geometry itself
>> might be similar. Have you had a look at whether ugrid could meet your
>> needs?
>> If it almost does so, perhaps a better thing to do would be to propose
>> additions to ugrid. We would like to avoid having more than one way to
>> describe
>> such geometries.
>>
>
> Ben has been involved in UGRID, so I'm sure he's thought this out. For my
> part, I think it's really a different problem, though it would be nice if
> it were as similar to UGRID as possible.
>
> * So far CF does not say anything about the use of netCDF-4 features (i.e.
>> not
>> the classic model). We have often discussed allowing them but the general
>> argument is also made that there has to be a compelling case for
>> providing a
>> new way to do something which can already be done. (Steve Hankin often
>> made
>> this argument, but since he's mostly retired I'll make it now in his name
>> :-)
>>
>
> Maybe it's time to embrace netcdf4? It's been a while! Though maybe for CF
> 2.* -- any movement on that?
>
>
>> If there are two ways to do something, software has to support both of
>> them. We
>> already have ways to encode ragged arrays, so is there a compelling case
>> for
>> needing the netCDF-4 vlen array as well?
>
>
> I think the ragged array option ins fine -- though I haven't looked at
> vlen arrays enough to know if they offer a compelling alternative. One
> issue is that the programming environments that we use to work with the
> data may not have an equivalent of vlen arrays.
>
> * Similarly, you propose attributes for clockwise/anticlockwise node order
>> and
>> for the polygon closure convention.
>
>
> This should match the OGC conventions as much as is practical.
>
> -CHB
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R (206) 526-6959 voice
> 7600 Sand Point Way NE (206) 526-6329 fax
> Seattle, WA 98115 (206) 526-6317 main reception
>
> Chris.Barker at noaa.gov
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20160922/f41ea548/attachment-0001.html>
Received on Thu Sep 22 2016 - 12:17:34 BST
