Hi all,
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.
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.
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
>
--
Dr Jon Blower
Technical Director, Reading e-Science Centre
Environmental Systems Science Centre
University of Reading
Harry Pitt Building, 3 Earley Gate
Reading RG6 6AL. UK
Tel: +44 (0)118 378 5213
Fax: +44 (0)118 378 6413
j.d.blower at reading.ac.uk
http://www.nerc-essc.ac.uk/People/Staff/Blower_J.htm
Received on Mon Sep 15 2008 - 01:55:00 BST
