Hi Steve,
Sounds good. I will work on that.
For those interested and going to the GO-ESSP meeting, maybe we can
carve out a few minutes during a break or something to talk in person
about this. I'd like to be able to say I'll have the summary Steve
mentions done before GO-ESSP but I'm not sure I'll have the time.
Ethan
Steve Hankin wrote:
> Hi Ethan,
>
> Given the depth of this discussion, I imagine that only a small
> handful of individuals followed it in detail. In order to capture
> what was learned in a form that can readily be evaluated, would you
> consider writing it up as a trac ticket?
> - Steve
>
> ==============================================
>
> Ethan Davis 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 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 Mon Sep 15 2008 - 12:44:22 BST
