[CF-metadata] What do models assume for the shape of the Earth?

From: John Caron <caron>
Date: Tue, 12 Apr 2005 09:16:51 -0700

Bryan Lawrence wrote:

>Hi John et al ...
>
>
>
>>Well, Mr Toyoda has shown that the difference between geodetic
>>(ellipsoidal earth) and geocentric (spherical earth) latitude is around
>>20 km at mid-latitude. My understanding of the conversation is that we
>>should assume spherical earth for global models, unless otherwise
>>stated. Now when I send that info to a GIS package that uses an
>>ellipsoidal earth, presumably they will correct the coordinates to take
>>this into account.
>>
>>Now for models that do have accuracy in which 20 km matters, they will
>>need to record information as to earth shape in order to get correct
>>geolocation. Perhaps there are no such models yet (??) but someday there
>>may be.
>>
>>
>
>My point is that one should worry about this error when it matters. Rich's
>situation is one where it matters. But for a global model, a 20km grid box
>is equivalent to an 80km true resolution in the output fields. Doing a
>correction on the coordinates on output back to an ellipsoid is something you
>can do, but I would argue is counter to the underlying scale analysis that
>went into the equations in the model ... Karl is right about how orographic
>coordinates are used in the UM ... and I'd be surprised if it was different
>in any other global model.
>
>Having said all that, I agree with Jonathan, the data from such models can be
>projected in whatever manner is convenient ...
>
>
>
>
>>If CF doesnt want to cope with this, it would be helpful if CF stated
>>that the scope of its mission is to deal with model data with resolution
>>greater than such and such.
>>
>>
>
>Don't get me wrong (I keep only telling half the story), CF needs a way to
>support real projections ... and a way to distinguish between them. I'll try
>and reply to Rich this weekend ...
>
>(Which is what I was trying to say about nowcasting models in my original
>email, I think they'll have this problem too).
>
>
>
>>Perhaps these are issues to be discussed at the GO-ESSP conference?
>>
>>
>
>Yes, but it wont hurt to thrash it out more here ... ideally we should go to
>the GO-ESSP meeting with a good understanding of the issues, if we go with an
>intention to discuss them all in detail, we'll not make a lot of progress.
>
>
>
>>In any case, I really appreciate everyone's help in responding to this
>>question, and in everyone's thoughts about what CF should do.
>>
>>
>
>I think most of us appreciate the detailed analysis of the real problems on
>the frontiers of CF that you do ... speaking personally, I wish I had the
>time to be as thorough as you ...
>
>Cheers
>Bryan
>
>
Ok, so heres a summary of what I understand so far about this issue:

1. For geolocation of model data, calculating location using
geodetic/geographic latitude which uses an ellipsoidal earth, versus
using geocentric latitude which uses a spherical earth, can differ up to
20 km at mid-latitude. Differences of location using different
ellispoids/datums can be as much as 300-500 m.

2. Global models generally are not accurate enough to worry about these
differences, and so can use any reasonable Earth shape. Since input data
probably use geographic lat/lon locations, there may be some good
reasons to prefer an ellisoidal model as default, such as WGS80.

3. For regional and local models that need to be accurate at these
resolutions, the assumed earth shape should be specified in the file
metadata. CF intends to specify a standard for this.

Now to switch to more of my own thoughts:

1. Tentatively, i will probably assume WGS80 if not explicitly specified.

2. We had already talked about adding some FGDC compliant "earth shape"
parameters like semimajor axis and inverse flattening. this is worth
finishing. These would be attached to the "grid-mapping" dummy variable
that specifies the projection.

3. We should allow an attribute that refers to the EPSG codes in the
same place, whose value is any valid code from the EPSG table.
Specialized clients will know how to interpret these codes. Best
practice would be to also include explicitly the semimajor axis and
inverse flattening, so less specialized clients can still get "pretty
good" accuracy.
Received on Tue Apr 12 2005 - 10:16:51 BST