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
>
--
Steve Hankin, NOAA/PMEL -- Steven.C.Hankin at noaa.gov
7600 Sand Point Way NE, Seattle, WA 98115-0070
ph. (206) 526-6080, FAX (206) 526-6744
"The only thing necessary for the triumph of evil is for good men
to do nothing." -- Edmund Burke
Received on Mon Sep 15 2008 - 09:25:08 BST
