Fwd: [CF-metadata] projections

From: John Caron <caron>
Date: Mon, 18 Nov 2002 11:00:06 -0700

Jonathan Gregory wrote:

> Dear John
>
> Many thanks for your email about projections. I agree that we haven't done
> enough on this yet.
>
>
>>1) i would prefer to use existing "authorities" such as FGDC to name the
>>projections.
>>
>
> It is useful to base our standard on existing standards such as FGDC - thanks
> for suggesting it. Doing so saves thinking and confusion. However, I would
> prefer not to give "authority" to something outside our standard. I'm happier
> to adopt/adapt parts of other standards into CF as the need arises for them,
> because as we do so we can satisfy ourselves (a) that the definition is clear
> and (b) that we need it. We shouldn't make CF unnecessarily complicated by
> importing many projections that are not actually used in our field - I would
> prefer us to limit ourselves to what CF users require, expanding as requested.
> Allowing multiple external authorities would have the further drawback that
> there could be more than one way to represent a particular projection, which
> would make life harder for the users of data.


i agree we dont necessrily want to endorse all the complexities of outside
standards. OTOH, we should reuse the useful parts, theres no reason to make up
new names and parameters. a middle ground would be to officially endorse only
what gets explicitly included in the CF Appendix, but to explicitly identify the
"authority" from where it comes.


>
>
>>2) since its highly likely that many variables will share a projection, we
>>should have an option to factor them out, eg:
>>
>
> I'm afraid I'm not in favour of this proposal. In general we have preferred
> to duplicate metadata on a per-variable basis, because this makes it easier to
> distribute and copy variables between files, and also simplifies software
> which processes the data (and hence may change some variables but want to leave
> others unaffected). Hence we have reduced the number of global attributes and
> recommended attributes on variables where relevant. It wastes a bit of space,
> but this is generally minor.


yes, im not worried about space, but coherence. variable that share the same
coordinate system constitute a very special group; for example derived
quantities can automatically be generated by examining the group.

however, discovering these groups can be done at a higher level, so i can
understand your motivations to keep the variables independent.


>
>
>>3) its important that the x and the y coordinates be identified, and that they
>>be understood to be coordinates on the specified projection plane. You could say
>>something like:
>>
>> "Variables representing the x and y coordinates on the projection plane must
>>always explicitly include the units attribute; there is no default value. The
>>units attribute will be a string formatted as per the udunits.dat file. The
>>recommended unit of latitude is km. The variable representing the x and y
>>coordinates must have an attribute axisType="x" and "y" respectively."
>>
>
> The purpose of the mapping information is to tell the software how to
> compute the actual lat and lon from the x and y - yes?


yes

> I suppose that the x
> and y should have units which are specified for the individual projections.
> For the rotated pole mapping that we have defined, x and y are in degrees
> (of longitude and latitude in the rotated system).
>
> The axis attribute may or may not be appropriate. It depends whether x and y
> are in any sense "like" longitude and latitude.


i have in mind the class of projections which are mappings onto a "projection
plane"; the units are typically km on the projection plane. i am not thinking
about the rotated pole type projections.

is there already a meaning of "axis" in CF that this would interfere with?


>
>
>>5) FGDC would be a good start
>>
>>i would be happy to compile these for your appendix if you'd like.
>>
>
> Thank you. It would be very helpful to have proposals for those projections
> that are needed.


ok, ill try to get a list back soon.

i dont really care about the syntax as long as the semantics are clear. but we
definitely need this soon if we are going to use CF conventions.
Received on Mon Nov 18 2002 - 11:00:06 GMT