Hi.
The issue you are raising regarding coordinate systems and the grid_mapping attribute is something I have been wondering about lately. Doesn't the grid_mapping attribute more properly reside on the coordinate (or auxiliary coordinate) variable? Strictly speaking, the data values don't have a coordinate system. The coordinate values have a coordinate system. Moving this attribute probably represents too great a change, so perhaps what we need to do is propose a new attribute (named coordinate_system?) that would be attached to (auxiliary) coordinate variables. This attribute would contain the name of a projection variable. This way, N different coordinate systems could attach to the same data variable. The old "grid_mapping" method can be maintained for legacy purposes.
Grace and peace,
Jim
Jim Biard
Research Scholar
Cooperative Institute for Climate and Satellites
Remote Sensing and Applications Division
National Climatic Data Center
151 Patton Ave, Asheville, NC 28801-5001
jim.biard at noaa.gov
828-271-4900
On Sep 3, 2012, at 12:58 PM, Randy Horne <rhorne at excaliburlabs.com> wrote:
>
> There is one thing I forgot to mention.
>
> The CF conventions support grid mappings. Conceptually, grid mappings exist for these space weather products. For example, J2000 is a specific type of earth centered inertial coordinate system. Similarly, "body reference frame" can be viewed as being a grid mapping.
>
> So, in the example discussed in the previous email, there would be a need for a data variable to have two distinct grid mappings, and the current CF syntax does not allow relating some coordinate variables to one grid mapping, and some of the other coordinate variables to another grid mapping.
>
> On the other hand, maybe all this grid mapping "stuff" can be avoided by creating and using standard names that preclude the need for grid mappings for space weather. However, this approach will introduce some constraints down the road because some of these celestial coordinate systems and satellite local coordinate systems have "mapping parameters" like the earth projections do, and without a grid mapping of some sort, there will be no way to express them using a standard method.
>
> Also note, that it may be overloading the current CF grid mapping to use it for these non-Earth coordinate system spaces because they are so different and are relevant to a very specific set of users.
>
> very respectfully,
>
> randy
>
>
> On Sep 3, 2012, at 12:25 PM, Randy Horne wrote:
>
>> Jonathan:
>>
>> Thanks for the follow-up !
>>
>> I am currently working level 1b space weather products.
>>
>> These products are derived from instruments in orbit. These instruments have have one or more sensing apertures that point out into space. these instruments sniff for energetic particles. The field of view of these instruments is angular and have a field of view that is typically a circular cone.
>>
>> One of the coordinates for these these products is the instrument aperture's boresight. The boresight angle is best described with a unit vector with 3 components (x,y, and z), in a 3D coordinate system where all the axes are orthogonal.
>>
>> The users of these products need the coordinates of this boresight angle in more than one coordinate systems. They will need the coordinates in a "celestial" coordinate system, such as a J2000 ECI unit vector. They will also need it in a local / spacecraft-centric coordinate system, such as a body reference frame coordinate system unit vector where the origin and coordinate system axes are understood.
>>
>> So, for the same data value, there is a need to be able to associate two different coordinates from different systems.
>>
>> I went back and looked over the CF conventions. In the beginning of chapter 5 it says ?."Note that it is permissible, but optional, to list coordinate variables as well as auxiliary coordinate variables in the coordinates attribute.".
>>
>> The implication being that I could include all of the unit vector x,y, and z component coordinate variables for J2000 ECI and body reference frame in the coordinate attribute of the data variable.
>>
>> But, it goes on to say "However, it is not permissible for a data variable to have both a coordinate variable and an auxiliary coordinate variable, or more than one of either type of variable, having an axis attribute with any given value e.g. there must be no more than one axis attribute for X for any data variable. Note that if the axis attribute is not specified for an auxiliary coordinate variable, it may still be possible to determine if it is a spatiotemporal dimension from its own units or standard_name, or from the units and standard_name of the coordinate variable corresponding to its dimensions (see Chapter 4, Coordinate Types ).".
>>
>> The use of the axis attribute with each of the x,y, and z components of both the J2000 ECI and body reference frame unit vector component coordinate variables is desirable. But, as suggested in the same narrative, the standard name could be used by the end user applications in lieu of the axis attribute.
>>
>> Does all/any of this make sense ?
>>
>> very respectfully,
>>
>> randy
>>
>>
>>
>> On Sep 3, 2012, at 6:17 AM, Jonathan Gregory wrote:
>>
>>> Dear Randy
>>>
>>>> I have a situation where there is value in including multiple auxiliary coordinate variablles for the same data variable. Specifically, I would like to communicate that there are two distinct three dimensional cartesian coordinates for each data value.
>>>>
>>>> Do the current CF conventions provide such a capability ?
>>>
>>> There is no limit on the use of auxiliary coordinate variables for a given
>>> data variable, so that is fine. However, if they are going to be useful they
>>> will have to be distinguishable in some way. Could you describe this more
>>> specifically? i.e. what are these two sets of coordinates?
>>>
>>> Best wishes
>>>
>>> Jonathan
>>> _______________________________________________
>>> CF-metadata mailing list
>>> CF-metadata at cgd.ucar.edu
>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>>
>>
>>
>> ____________________________________
>>
>> Randy C. Horne (rhorne at excaliburlabs.com)
>> Principal Engineer, Excalibur Laboratories Inc.
>> voice & fax: (321) 952.5100
>> url: http://www.excaliburlabs.com
>>
>>
>>
>>
>>
>
>
> ____________________________________
>
> Randy C. Horne (rhorne at excaliburlabs.com)
> Principal Engineer, Excalibur Laboratories Inc.
> voice & fax: (321) 952.5100
> url: http://www.excaliburlabs.com
>
>
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20120905/25ae0697/attachment.html>
Received on Wed Sep 05 2012 - 09:10:40 BST
