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 at 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: edavis at ucar.edu
P.O. Box 3000
Boulder, CO 80307-3000 http://www.unidata.ucar.edu/
---------------------------------------------------------------------------
Received on Fri Sep 12 2008 - 16:16:57 BST
