Hi Jon, all,
Jon Blower wrote:
This is an interesting discussion. I haven't had much time to input
any brainpower into this, but I just wanted to suggest that whoever
eventually takes charge of this issue should probably consult the
GeoTools guys, who have done a lot of work in this area. They
probably can't help with what is and isn't in scope for CF, but they
would certainly be able to share their thinking on vertical CRSs in
general.
Good idea. It would certainly be worth while to pass whatever we come up
with past some folks more expert in CRS and geodesy.
Just a quick thought about grid mappings. In the horizontal plane we
have the lat-lon system, which often acts as a "reference" CRS that
everyone can understand (e.g. curvilinear coordinate systems are
usually mapped to lat-lon). Hence provided that we can convert an
arbitrary CRS to and from lat-lon, then we can convert any horizontal
CRS to any other. It's not obvious to me that we have an equivalent
for the vertical CRS, particularly considering that vertical CRSs can
be defined using a number of physical quantities (length, pressure,
density, even sometimes temperature). Hence converting one vertical
CRS to another might be hard in the general case.
Not to mention that transformations between different vertical CRS may
depend on X and Y because the reference surfaces may not be tangential
in all locations.
Ethan
Cheers, Jon
On Fri, Sep 12, 2008 at 11:16 PM, Ethan Davis <[EMAIL PROTECTED]> wrote:
Hi Dale,
Dale Robinson wrote:
I guess we are getting to the core of this discussion, at least in terms
of whether or not my further involvement is needed.
Yes indeed. Good discussion
The question for me is, does or will the CF convention allow some method
to include offsets between tidal datums, or allow some other means for a
user to convert among z referenced to different datums?
Your answer below suggests that the CF convention is not the place for
this information... that the information is out there and it is up to the
user to find it.
Please let me know if I've got that right.
Sorry that detail of your question slipped under my radar and I was focused
on how to identify a vertical datum. It is an interesting question since the
grid mapping part of CF was originally designed to describe a
mapping/transformation between two sets of coordinates. The existing grid
mappings generally have a half dozen or so parameters and a name to identify
the set of formulas in which to use those parameters to perform the
transformation. In your case, it sounds like the vertical datum grid mapping
variable would contain an offset for each point where you have data. You
wouldn't even need to name the transformation (though you probably would
want to name the two vertical CRS if known), you would just need to indicate
how the offset is applied.
Which leads me to think that CF very well may be the place for data on
offsets between vertical datums. What do others think about a grid mapping
variable being an actual array of data as opposed to simply a container for
attributes?
Ethan
PS Just a thought about grid mappings. Both EPSG and ISO 19111 keep CRS and
transformations between CRS as separate entities. Grid mappings kind of do
double duty as they can now either:
1) define both a transformation and the two CRS at the endpoints of the
transformation, or
2) just define a single CRS.
Of course, I can't think of many advantages to separating things into
components and the disadvantage is separation of related information.
Cheers.
-Dale
-----------------------------
3) "The fact the Dale wants to distinguish the various tidal datums shows
that they define distinct quantities."
When I think about it, yes they seem to be distinct quantities. The range
of mean lower low water and mean higher high water varies from location to
location. A user of the data may not know what the offsets among datums are
in a particular area. Heights referenced to these datums (especially MLLW)
are very important to local users of the data. As a user of the CF
convention and netCDF, I want to make sure that the people using my data can
convert the height values we give them into values most useful to them. So
inclusion of an offset variable, especially one so intuitively named
(altitude_of_mean_low_water) would help me and many of the users of my data
immensely.
Even if the user doesn't know the offsets between two tidal datums, they
do exist. To me, that doesn't seem like enough of a difference to consider
them distinct quantities.
Ethan
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
Ethan R. Davis Telephone: (303) 497-8155
Software Engineer Fax: (303) 497-8690
UCAR Unidata Program Center E-mail: [EMAIL PROTECTED]
P.O. Box 3000
Boulder, CO 80307-3000 http://www.unidata.ucar.edu/
---------------------------------------------------------------------------
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
Ethan R. Davis Telephone: (303) 497-8155
Software Engineer Fax: (303) 497-8690
UCAR Unidata Program Center E-mail: [EMAIL PROTECTED]
P.O. Box 3000
Boulder, CO 80307-3000 http://www.unidata.ucar.edu/
---------------------------------------------------------------------------
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
