Re: [CF-metadata] support for multiple auxulary coordinate variables
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.bi...@noaa.gov 828-271-4900 On Sep 3, 2012, at 12:58 PM, Randy Horne rho...@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
[CF-metadata] support for multiple auxulary coordinate variables
Dear Randy I agree with what you write. You could list the alternative sets of three coordinates each all as auxiliary coord vars, and distinguish them with standard_names; presumably you would want to propose some new standard_names. That would be fine and quite simple to do. In addition, you could propose new grid_mappings. Up to now grid_mappings have been for 2D coordinate systems, but you would want something in 3D, I think. If it's likely generally useful, it would interesting to see a proposal of what it might look like. There is already an agreed change to the CF standard to allow more than one grid_mapping for a given data variable. This was proposed by Mark Hedley in ticket 70 https://cf-pcmdi.llnl.gov/trac/ticket/70 and will go in CF 1.7. In response to Jim's comment, I would say that the data variable does have a coordinate system; it's defined by the various coordinate variables that the data variable is associated with, either 1D (Unidata) coordinate variables or auxiliary coordinate variables. The role of the grid_mapping is to make explicit the relationship among the coordinate variables of the space in which the data variable exists. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] support for multiple auxulary coordinate variables
Hi. The new grid_mapping scheme looks great! It accomplishes, in a more backward compatible way, most of the things that I was suggesting. Regarding Jonathan's reply to my previous comment: If I read a temperature using a thermometer, the value does not have a geographic coordinate system associated with it. If I also use my handy GPS unit to read my location, I can associate that location with the temperature. The location does have a coordinate system associated with it, and in fact is nearly meaningless without one. I could also use more traditional surveying tools and determine a location with respect to an entirely different coordinate system. The coordinate systems naturally associate with the locations, not the temperature. The current CF approach leaves the coordinate system association with a given regular or auxiliary coordinate variable unspecified (in any direct fashion). In order to determine the coordinate system for a coordinate, you must search the data variables for an association with the coordinate (through shape or through the coordinates attribute), then find the grid_mapping attribute. The new scheme represents an improvement, but I still find myself asking why we are placing a fundamental attribute of a coordinate anywhere other than directly with the coordinate. 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.bi...@noaa.gov 828-271-4900 On Sep 5, 2012, at 1:28 PM, Jonathan Gregory j.m.greg...@reading.ac.uk wrote: Dear Randy I agree with what you write. You could list the alternative sets of three coordinates each all as auxiliary coord vars, and distinguish them with standard_names; presumably you would want to propose some new standard_names. That would be fine and quite simple to do. In addition, you could propose new grid_mappings. Up to now grid_mappings have been for 2D coordinate systems, but you would want something in 3D, I think. If it's likely generally useful, it would interesting to see a proposal of what it might look like. There is already an agreed change to the CF standard to allow more than one grid_mapping for a given data variable. This was proposed by Mark Hedley in ticket 70 https://cf-pcmdi.llnl.gov/trac/ticket/70 and will go in CF 1.7. In response to Jim's comment, I would say that the data variable does have a coordinate system; it's defined by the various coordinate variables that the data variable is associated with, either 1D (Unidata) coordinate variables or auxiliary coordinate variables. The role of the grid_mapping is to make explicit the relationship among the coordinate variables of the space in which the data variable exists. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] Proposal for standard name surface_snow_cover_binary_mask
Jonathan, That sounds great! I was thinking there needed to be some way to capture the 42% figure. So, to sum up, the standard name and definition would be: surface_snow_cover_binary_mask: The value is 1 where the snow cover area fraction is greater than a threshold, and 0 elsewhere. The threshold must be specified by associating a scalar coordinate variable with the data variable and giving the scalar coordinate variable a standard name of surface_snow_area_fraction. The value of the scalar coordinate variable is the threshold value. Does that look/sound right? 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.bi...@noaa.gov 828-271-4900 On Sep 5, 2012, at 1:34 PM, Jonathan Gregory j.m.greg...@reading.ac.uk wrote: Dear Jim I'd like to propose the new standard name snow_cover_binary_mask. There is a NOAA snow coverage extent product that is being put into netCDF format. The product is derived from the IMS Daily Northern Hemisphere Snow Ice Analysis. It is a grid in which cells are marked as snow-covered or not snow-covered. The GCMD already has the keywords Cryosphere Snow/Ice Snow Cover and Terrestrial Hydrosphere Snow/Ice Snow Cover, which are applied to the source product. This idea seems fine to me. However, existing names for snow cover refer to it as surface_snow, so I would suggest surface_snow_binary_mask instead. In this particular product, grid cells are marked as snow-covered when 42% of the cell indicates the presence of snow. For generality and to make the data self-describing, I would suggest that the definition of snow_cover_binary_mask should require that the data variable has coordinate variable or a scalar coordinate variable of surface_snow_area_fraction (42% in your case) to specify the threshold. That is an existing standard_name. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] Proposal for standard name snow_cover_binary_mask
Dear All, It's becoming clear that we need a Standard Name component to cover boolean values whose trigger point may then be specified elsewhere as Jonathan stated. In the biological domain, the syntax 'presence_of_x' where x is a taxon name is often used. Could this be adopted giving the Standard Name 'presence_of_surface_snow' for Jim and opening the door for a raft of Standard Names to cover Ute's use case? Cheers, Roy. From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Ute Brönner [ute.broen...@sintef.no] Sent: 05 September 2012 18:40 To: Jim Biard Cc: Heather Brown; Raymond Nepstad; cf-metadata@cgd.ucar.edu; Alisa Young Subject: Re: [CF-metadata] Proposal for standard name snow_cover_binary_mask Hei, Wouldn't that feature come in handy for other grids as well where we would like to mark sth. like exposed or not exposed? So I would suggest to make it snow independent. Regards, Ute Am 05.09.2012 um 18:31 schrieb Jim Biard jim.bi...@noaa.govmailto:jim.bi...@noaa.gov: Hi. I'd like to propose the new standard name snow_cover_binary_mask. There is a NOAA snow coverage extent product that is being put into netCDF format. The product is derived from the IMS Daily Northern Hemisphere Snow Ice Analysis. It is a grid in which cells are marked as snow-covered or not snow-covered. The GCMD already has the keywords Cryosphere Snow/Ice Snow Cover and Terrestrial Hydrosphere Snow/Ice Snow Cover, which are applied to the source product. In this particular product, grid cells are marked as snow-covered when 42% of the cell indicates the presence of snow. I'd appreciate any thoughts or comments. 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.bi...@noaa.govmailto:jim.bi...@noaa.gov 828-271-4900 ___ CF-metadata mailing list CF-metadata@cgd.ucar.edumailto:CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata-- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] Proposal for standard name snow_cover_binary_mask
Suggestion 'presence_of_surface_snow' should have been 'presence_of_surface_snow_cover' to maintain consistency From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Lowry, Roy K. [r...@bodc.ac.uk] Sent: 05 September 2012 19:49 To: Ute Brönner; Jim Biard Cc: Heather Brown; Raymond Nepstad; cf-metadata@cgd.ucar.edu; Alisa Young Subject: Re: [CF-metadata] Proposal for standard name snow_cover_binary_mask Dear All, It's becoming clear that we need a Standard Name component to cover boolean values whose trigger point may then be specified elsewhere as Jonathan stated. In the biological domain, the syntax 'presence_of_x' where x is a taxon name is often used. Could this be adopted giving the Standard Name 'presence_of_surface_snow' for Jim and opening the door for a raft of Standard Names to cover Ute's use case? Cheers, Roy. From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Ute Brönner [ute.broen...@sintef.no] Sent: 05 September 2012 18:40 To: Jim Biard Cc: Heather Brown; Raymond Nepstad; cf-metadata@cgd.ucar.edu; Alisa Young Subject: Re: [CF-metadata] Proposal for standard name snow_cover_binary_mask Hei, Wouldn't that feature come in handy for other grids as well where we would like to mark sth. like exposed or not exposed? So I would suggest to make it snow independent. Regards, Ute Am 05.09.2012 um 18:31 schrieb Jim Biard jim.bi...@noaa.govmailto:jim.bi...@noaa.gov: Hi. I'd like to propose the new standard name snow_cover_binary_mask. There is a NOAA snow coverage extent product that is being put into netCDF format. The product is derived from the IMS Daily Northern Hemisphere Snow Ice Analysis. It is a grid in which cells are marked as snow-covered or not snow-covered. The GCMD already has the keywords Cryosphere Snow/Ice Snow Cover and Terrestrial Hydrosphere Snow/Ice Snow Cover, which are applied to the source product. In this particular product, grid cells are marked as snow-covered when 42% of the cell indicates the presence of snow. I'd appreciate any thoughts or comments. 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.bi...@noaa.govmailto:jim.bi...@noaa.gov 828-271-4900 ___ CF-metadata mailing list CF-metadata@cgd.ucar.edumailto:CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata-- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] Proposal for standard name snow_cover_binary_mask
Ute, It is a good concept. As best as I understand it (I'm still learning), the existing grammar for standard names doesn't allow a qualifier of this sort. Qualifiers are not allowed to change the units of a quantity, for one thing, and a binary mask qualifier doesn't fit into any of the existing qualifier categories. That doesn't mean one can't be developed, but the usual way this is handled is to just request a new standard name. 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.bi...@noaa.gov 828-271-4900 On Sep 5, 2012, at 1:40 PM, Ute Brönner ute.broen...@sintef.no wrote: Hei, Wouldn't that feature come in handy for other grids as well where we would like to mark sth. like exposed or not exposed? So I would suggest to make it snow independent. Regards, Ute Am 05.09.2012 um 18:31 schrieb Jim Biard jim.bi...@noaa.govmailto:jim.bi...@noaa.gov: Hi. I'd like to propose the new standard name snow_cover_binary_mask. There is a NOAA snow coverage extent product that is being put into netCDF format. The product is derived from the IMS Daily Northern Hemisphere Snow Ice Analysis. It is a grid in which cells are marked as snow-covered or not snow-covered. The GCMD already has the keywords Cryosphere Snow/Ice Snow Cover and Terrestrial Hydrosphere Snow/Ice Snow Cover, which are applied to the source product. In this particular product, grid cells are marked as snow-covered when 42% of the cell indicates the presence of snow. I'd appreciate any thoughts or comments. 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.bi...@noaa.govmailto:jim.bi...@noaa.gov 828-271-4900 ___ CF-metadata mailing list CF-metadata@cgd.ucar.edumailto:CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
