Hi All,
A message from Jonathan yesterday mentioned the impending
release of the first non-BETA CF standard. (I second the
plan, of course!) I would like to return to our previous
discussions of Cell Bounds (just a year ago -- one sample
message attached to help you locate the dialog). I'm not
sure that the outcomes of that discussion are incorporated
into the current CF beta. In particular we discussed an
attribute to indicate that the cells were contiguous. I am
perhaps overlooking it, but I did not find it in
http://www.cgd.ucar.edu/cms/eaton/cf-metadata/CF-working.html#bnds
1. The concern: Consider the pressing need to create model
access and inter-comparison frameworks on the Web.
Curvilinear grids will be commonplace. A Web server for
this purpose (such as LAS) will need to open a CF file and
rapidly (in interactive time) extract coordinates and data
and create a plot. The most common and informative style of
plot is one in which the individual cells are colored --
producing a filled contour plot that also communicates grid
resolution. The "contiguous" attribute is important here.
If the application has no way of knowing a priori that the
cells are contiguous, then it must either use
extraordinarily inefficient graphics of plotting every
polygon individually, or it must examine all relevant
vertices to confirm that the data are contiguous. In a
stateless Web server it must repeat this for every plot.
====
The "contiguous" attribute is the main point and one that I
believe we agreed upon. What follows should be considered as
a separate discussion.
2. CF-1.0-beta5 encodes curvilinear coordinate bounds using
n*m*nv instead of n*m*2*2. This is nasty for the common,
simple graphics of contiguous cells. The application has to
read all of the (redundant) vertices; then knowing neither
the ordering of the vertices nor the starting "corner" it
must figure out which edges the adjacent cells share. This
is a fussy problem rather than hard, but it definitely makes
reading CF files more complex and specialized code will be
required. The problem gets even more fun in a model
inter-comparison framework. Do file A and file B contain
identical grids? The algorithm needed in order to know this
involves a "blind grope" over the bounds of the first cells,
knowing neither the relative orientation, nor the relative
starting vertex ("corner") on the two grids. These problems
are not shared by the n*m*2*2 encoding.
Standards such as CF are built upon trade-offs -- commonly,
generality vs. simplicity. In weighing the choice we
consider the level of generality gained vs the level of
complexity added. In our last discussions of the "nv vertex
encoding" the stated generality goal was to accommodate a
particular hexagonal grid. At that time our discussions
revealed that i) no one had yet attempted to encode that
grid in a CF file; and ii) the "hexagonal" grid actually had
varying numbers of vertices (i.e. it was not a good fit to
the standard, anyway). Before CF-1.0-beta5 becomes official
are we comfortable that we have adequately tested cases
where the generality of this encoding is required and we
have demonstrated that the trade-off is positive on balance?
- steve
--
| NOAA/PMEL | ph. (206)
526-6080
Steve Hankin | 7600 Sand Point Way NE | FAX (206)
526-6744
| Seattle, WA 98115-0070 |
hankin at pmel.noaa.gov
-------------- next part --------------
An embedded message was scrubbed...
From: Bob Drach <drach at llnl.gov>
Subject: Re: CF cell edges in curvilinear coordinate systems
Date: Mon, 11 Feb 2002 09:58:13 -0800
Size: 6565
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20030312/e4fbb779/attachment.mht>
Received on Wed Mar 12 2003 - 10:21:27 GMT
