Jonathan,
To summarize: We will have a standard name
which defines the datum, and a parameter attribute that gives the offset.
Right? I am happy with this.
-Rich
Gregory wrote:
>Dear Rich
>
>
>
>>>I tend to think it is better to make the surface/geoid distinction even
>>>more
>>>blatant by putting it in the standard name.
>>>
>>>
>>>
>>Ok, that's fine. I would just like to make sure that we allow the
>>possibility of using a
>>local datum for z=0 and specifying the offset between this local datum
>>and the geoid.
>>This is important, since many people use local datums that are not the
>>geoid, and we don't want
>>to break any of their software. (we don't break anything if we only
>>*add* variables and attributes)
>>
>>Here's another possible solution:
>>Just as we allow different units, origin and offset for time:
>>(e.g. units:"days since 1968-05-23 00:00:00 EST")
>>
>>we could allow different units, origin and offset for height:
>> units:"meters above WGS84 -10.24"
>>
>>
>
>I see what you mean. I don't think we can do exactly what you propose because
>that units string doesn't comply with udunits so would break other software.
>I agree that this is effectively an offset in the units, like the difference
>between degC and K. udunits provides a syntax for specifying an offset but we
>have disallowed it in CF.
>
>In another thread we are discussing the introduction of a parameters attribute
>to supply numbers which are used to define quantities when the standard_name
>alone is not sufficient. We could have a standard_name of height_above_
>geopotential_surface (more general than geoid) with parameters to specify the
>the height of the geopotential surface above the geoid and to identify the
>geoid/ellipsoid.
>
>
>
>>I agree with you that the average of the free-surface is not the datum
>>(z=0). I'm not
>>sure I understand the issue, however. This is why we want to be able
>>to specify the offset between the datum and some pedigreed geoid.
>>
>>
>
>The issue is that when comparing a free-surface model simulation with altimetry
>we would probably like heights wrt geoid i.e. subtract the area-average of zeta
>uniformly from zeta. In other applications the model might like to output zeta
>itself. Again, these are two different quantities (though only by a constant
>offset, as you say). I think we agree we need to be able to distinguish them.
>
>Cheers
>
>Jonathan
>_______________________________________________
>CF-metadata mailing list
>CF-metadata at cgd.ucar.edu
>http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
--
Richard P. Signell rsignell at usgs.gov
U.S. Geological Survey Phone: (508) 457-2229
384 Woods Hole Road Fax: (508) 457-2310
Woods Hole, MA 02543-1598
Received on Thu Oct 28 2004 - 06:04:17 BST
