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 <edavis at unidata.ucar.edu> 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/
>> ---------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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:40:22 BST
