Re: [CF-metadata] standard names and area type for ice sheet surface mass balance
Dear Jonathan, Back in February you proposed three new names for ice sheet mass balance: surface_snow_and_ice_melt_flux (kg m-2 s-1): the mass flux of melting at the surface surface_snow_and_ice_refreezing_flux (kg m-2 s-1): the mass flux of surface meltwater which refreezes within the snow or firn land_ice_surface_specific_mass_balance_flux (kg m-2 s-1): the net rate of gain (if positive) or loss (if negative) of frozen water mass per unit area due to all processes of surface accumulation and ablation I would also like to propose a new area_type of ice_free_land. No comments were received on any of these names. The first two are fine and I have included them in the table update today. When entering the third name into the vocabulary editor I noticed that it is very similar to an existing name land_ice_surface_specific_mass_balance (m s-1). The definition of the existing name says Specific mass balance means the net rate at which ice is added per unit area at the land ice surface which also sounds very similar to the definition of your proposed name. However, the units of m s-1 make me think this name perhaps refers to the thickness of ice being deposited/ablated per unit time so should it really refer to mass balance? Your proposed name has units of kg m-2 s-1 which seems correct for a mass flux. Please can you confirm that the two quantities are distinct? Do you think we need to modify the existing name? I agree that it is fine to introduce a new area_type of ice_free_land. Best wishes, Alison -- Scanned by iCritical. ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] CF feature type trajectory (Ch. 9; May 10, 2011) and axis, attribute
Hi Chris: I think we agreed that this sentence in section 5 should be removed: The|axis|attribute is not allowed for auxiliary coordinate variables. If anyone has a better idea, let me know. otherwise i will submit a defect change. John On 7/20/2011 7:51 AM, Chris Paver wrote: Dear list, Was there any resolution to the issue I brought up? Thanks, Chris Original Message Date: Thu, 07 Jul 2011 11:59:09 -0700 From: Steve Hankin steven.c.han...@noaa.gov Subject: Re: [CF-metadata] CF feature type trajectory (Ch. 9; May 10, 2011) and axis attribute To: Jeffrey F. Painter paint...@llnl.gov Cc: cf-metadata@cgd.ucar.edu Message-ID: 4e1601fd.5020...@noaa.gov Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 7/7/2011 11:53 AM, Jeffrey F. Painter wrote: It looks as though you've been reviewing the public draft of the future CF Conventions version 1.6. It's great that someone has been looking at it! It seems to me that z in the examples of Appendix H (formerly designated A9) plays the role of an auxiliary coordinate variable, although technically it's not because there isn't (but should be) a 'coordinates' attribute which lists auxiliary coordinate variables. I don't know why axes are banned for auxiliary coordinate variables in the case of trajectories. Something needs to be clarified here, or the examples changed. This was ticket 37. Are there any comments from Steve Hankin, the moderator, or any of the other people who contributed to writing Chapter 9, or anyone else who knows more than me? stand by. I think Chris has pointed out a needed correction to Chapter 5 that was discussed, but was not documented. (thanks Chris) But need to confirm with others. - Steve Thanks to all! - Jeff Painter On 7/7/11 5:13 AM, Chris Paver wrote: Dear List, I have been reviewing the use of the axis attribute as defined in Chapter 5, and comparing it to the trajectory example in the Chapter 9 document at A9.4. The Ch. 5 rules states that only a coordinate variable can have an axis attribute, whereas the auxiliary variables cannot. However, in Ch. 9, the single trajectory dimension is time, but the variable z contains the axis attribute. Is this a change to the rule as stated in Ch. 5, or a typo? I briefly looked over the other feature types in Ch. 9, and they all look to have the vertical variable listed with the axis attribute, so maybe it is a typo. Thanks, Chris ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] new TEOS-10 standard names
Dear all I agree with Roy in his remark that the existing salinity Standard Name is a much broader term than the TEOS-10 recommendations. In some datasets, it may not be well-defined precisely which kind of salinity we have. This is particularly the case for model datasets, since most ocean models used for climate are not capable of distinguishing owing to the approximations they make. (I note that CF and the standard name table began as a convention for GCMs, and later expanded to accommodate observations.) We cannot redefine the existing standard name because of the existing datasets and because it is useful to have a generic name anyway. However it is fine both to keep this existing generic name and to define some new ones to make the distinction in new obs and model datasets where it is appropriate, as proposed by Paul and Trevor. It is usual in CF to have a choice of precision for different applications. On Paul's proposals, I have a couple of comments: sea_water_preformed_salinity Definition: Preformed Salinity is a salinity variable that is designed to be as conservative as possible, by removing the estimated biogeochemical influences on the seawater composition from other forms of salinity. I assume this is a newly introduced term. I would say that it would be good to be more informative. Preformed does not tell me what it is - it doesn't suggest anything in particular to me as a non-expert. CF standard names do not have to be the term in common use if we could be more self-explanatory. Perhaps we could be more self-explanatory in this term with a phrase such as assuming_no_biogeochemical_influence. But actually, I am unsure what that means - could you explain a bit further? How can salinity not be influenced by geochemistry, in particular? Please excuse my ignorance. sea_water_potential_enthalpy Since this quantity is in J kg-1, I suggest that it should contain the word specific. Omitting this might imply that it was an extensive quantity e.g. an ocean integral. By analogy with the existing standard name specific_kinetic_energy_of_sea_water it might be best phrased as specific_potential_enthalpy_of_sea_water The salinity quantities are by definition intensive and so specific is not required. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] COARDS - positive attribute
Dear Glenn The positive attribute hasn't been extended to data variables in CF because the standard name always implies the sign convention e.g. toa_net_downward_longwave_flux toa_net_upward_shortwave_flux The advantage of doing it is this way is that it is impossible for the sign convention to be missing if the quantity is identified by standard name! I am not clear about the details of your case, but I guess that it should be possible to use a standard name which states what the sign convention is for the thickness of the water column. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] CF feature type trajectory (Ch. 9; May 10, 2011) and axis, attribute
Dear Chris, Jeff, Steve, John It seems to me that z in the examples of Appendix H (formerly designated A9) plays the role of an auxiliary coordinate variable, although technically it's not because there isn't (but should be) a 'coordinates' attribute which lists auxiliary coordinate variables. I don't know why axes are banned for auxiliary coordinate variables in the case of trajectories. Something needs to be clarified here, or the examples changed. This was ticket 37. Are there any comments from Steve Hankin, the moderator, or any of the other people who contributed to writing Chapter 9, or anyone else who knows more than me? stand by. I think Chris has pointed out a needed correction to Chapter 5 that was discussed, but was not documented. (thanks Chris) But need to confirm with others. Ticket 62 discusses the proposed change to allow auxiliary coordinate variables to have the axis attribute. This ticket was originally proposed by Karl to correct a defect, and I think when we were writing chapter 9 we had in mind this change. I propose that ticket 62 should be implemented in CF 1.6 (it wasn't one of the tickets I had listed earlier to Jeff - I must have overlooked it). In that ticket, I proposed some wording, to which no-one subsequently objected, and that was many months ago. Also, Jeff, if there are any examples in App H where a data variables does not list its aux coord vars in a coordinates attribute, please could you correct them? This is required, as you say. It says in 9.5, The coordinates attribute must be attached to every data variable to indicate the spatiotemporal coordinate variables that are needed to geo-locate the data. Best wishes and thanks Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] the need to store lat/lon coordinates in a CF metadata compliant netCDF file
Dear all For datasets which are intended for analysis by end-users I think it would be undesirable to remove the requirement of providing explicit lat and lon coords even if a grid_mapping is provided. I think it is unrealistic to expect all software which someone might use to analyse netCDF files to be able to recognise and act upon all possible values of the CF grid_mapping attribute, and without the lat and lon information the user would have a problem. If the issue is storage space in the file I think the much better choice is to store the explicit coordinates in another file, by extending the CF convention to allow datasets to be distributed over several linked files, as gridspec does for example. Steve appears to suggest that grid_mapping is required in some circumstances, but I don't think it is at present. However, the text Steve quotes may not be quite right: /When the coordinate variables for a horizontal grid are not longitude and latitude,*_it is required that the true latitude and longitude coordinates be supplied_* via the coordinates attribute/. The text should make it clear that this requirement applies when the data has a geolocated horizontal grid. It doesn't necessarily apply to idealised cases. We could clarify this with a defect ticket. Without the grid_mapping, the lat and lon still make sense in the common case (and original CF case) of GCM data, and in many other cases, the intended usage of the data does not require precision about the figure of the Earth. Although this metadata could be valuable if it can be defined, I think it would be too onerous to require it. CF is primarily intended to promote the processing and sharing of netCDF files, it says in the Abstract. As John notes, it could be used for other purposes, such as internal files in models. Do they have to be CF-compliant, however, if they're not intended for analysis or for sharing? Cheers Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] More background on the burned area
Dear Kevin burned_area and burned_area_fraction would be OK as standard names, I think, but I would tend to agree with your suggestion that vegetation could also be mentioned somehow, in order to make the standard_name more self-explanatory when in the context of a dataset that might contain many other geophysical quantities. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] Units: degrees - COARDS/CF Convention
Dear Glenn I too agree with your interpretation. COARDS and CF disallow degree for lat and lon, but degree is allowed for some other quantities in the standard name table e.g. grid_latitude and grid_longitude (for a rotated-pole system) have units of degree. I agree with Roy that quantities which are distinguished by according to either magnetic or true bearing should have that distinction indicated in CF by semantics i.e. standard_name, not by units. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] new TEOS-10 standard names:- reply to two emails.
Hi Trevor, As one who has worked in a data centre for a long time I can tell you that the transition to Practical Salinity was nowhere near as clean as you imply. The 1978 Equations of State weren't published by UNESCO until 1982 or 1983 and it took some people a long while to latch on (I remember locating at least one bit of code in use in the 90s that hadn't been updated). There was also uncertainty resulting from the lack of information on the algorithms built into the STD systems of the 70s that were still in use well into the 80s. Hopefully, the transition to TEOS-10 will be much cleaner. Thanks for correcting my misunderstanding that models couldn't generate Practical Salinity. However, I still feel that aliasing the current salinity standard names to practical salinity is a little too risky. Cheers, Roy. -Original Message- From: cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of trevor.mcdoug...@csiro.au Sent: 22 July 2011 03:05 To: trevor.mcdoug...@csiro.au; ngalbra...@whoi.edu; CF-metadata@cgd.ucar.edu; paul.dur...@csiro.au; paul.bar...@csiro.au; rainer.feis...@io-warnemuende.de; r...@eos.ubc.ca; King, Brian A.; stephen.griff...@noaa.gov Subject: Re: [CF-metadata] new TEOS-10 standard names:- reply to two emails. Two replies follow, first to Karl Taylor, then to Roy Lowrie. Hello Karl, (1) potential temperature is what it always was, namely the temperature of a seawater parcel after an adiabatic and isohaline change of pressure to p = 0 dbar. (2) Conservative Temperature is proportional to potential enthalpy which is the enthalpy of a seawater parcel after the same adiabatic and isohaline change of pressure to p = 0 dbar. Conservative temperature is a more accurate measure of the heat content of seawater, by a factor of one hundred, than is potential temperature. See the figure on page 10 of Getting _Started.. to see how different Conservative Temperature is to potential temperature. (3) in situ temperature is a pretty useless variable. It corresponds to electrical conductivity in that both are measured variables, but we quickly move on from these measured variables to calculate variables that have the potential property, and that are as conservative as possible. It is, and always has been, a little dangerous (although not illegal) to use the word temperature if in-situ temperature t is intended. Rather it is best described as in-situ temperature. I refer you to the brochure Getting Started with TEOS-10 and the Gibbs SeaWater Oceanographic Toolbox (nicknamed TEOS-10 for dummies) where the new variables, Absolute Salinity and Conservative Temperature are explained, as is the way in which TEOS-10 should be included in ocean models. This document can be found here http://www.teos-10.org/pubs/Getting_Started.pdf TEOS-10 allows the calculation of heaps of thermodynamic properties of seawater, ice and humid air; properties that we never had beforehand (the mathematical beauty and self-consistency of having three Gibbs functions allows this, namely Gibbs functions for seawater, for ice and for humid air). For example we now have entropy, enthalpy, internal energy, latent heat of melting, latent heat of evaporation, all precisely defined and we have algorithms that are really accurate and that are 100% consistent with each other. But the things that are important for oceanographers are Absolute Salinity and Conservative Temperature. These variables are the axes for our T-S diagrams now. As far as the practicing ocean modeller and climate scientist is concerned, once Absolute Salinity and Conservative Temperature are adopted, all of the other beautiful thermodynamic machinery that underlies TEOS-10 does not need to be learnt; it is there as a supporting thermodynamic framework. _ Now I am replying to an email from Roy Lowrie. Roy, First, thanks for drawing attention to the following, Finally, can I draw peoples' attention to the statement on the TEOS-10 Web Site that data centres should continue to ingest and store salinity observations as Practical Salinity. It is abundantly clear from a number of conversations I have had recently that this is being overlooked. This is perhaps the MOST IMPORTANT point for people to grasp, especially data centres! This is one thing we cannot afford to get wrong; observational data must be stored as Practical Salinity. Then you make the point that the existing data bases contain at least two different types of salinity. There is the Knudsen salinity (ppt) which is calculated from S_K = 0.03 + 1.805 Cl and I think I am correct in saying that any salinity data in national data centres with dates between 1901 and 1977 will be this Knudsen salinity. Then after 1978, the salinity in national data bases should be Practical Salinity S_P (sometimes called PSAL). The
Re: [CF-metadata] new TEOS-10 standard names
Dear all I understand the need to be clear, with new standard names, which observational quantity is being collected in future. I do not agree, however, that we should make the plain salinity name an alias for something more precise. This is partly because that might change the meaning of existing data, possibly incorrectly as Trevor points out. Partly it is also because I think it is quite possible that models, perhaps idealised, may be used in which it would not be meaningful to be more precise than just salinity. Trevor argues that existing ocean models use practical salinity because (a) they are initialised with observations of that and (b) they assume so in their equation of state. I don't think (a) is necessarily so. In some cases, they might not be initialised with observations, for instance in idealised investigations of spin-up. Even when initialised from obs, they will almost certainly drift to a less realistic state. I don't know enough about it to be sure about (b). Unless we could be certain this is always the case, I think plain salinity should be retained for possible use in models. However, we could certainly recommend that models should use one of the new more precise terms if definitely appropriate. This recommendation could be included in the standard_name definition of plain salinity. I understand the existing standard name sea_water_temperature to mean in-situ temperature, as it does for air temperature. This could be stated in the definition. The purpose of standard names themselves is not to prescribe or recommend what quantities people should store in netCDF files. It is to allow them to describe with sufficient precision the quantities they have chosen to store, in order to make it possible to decide which quantities from different datasets should be regarded as comparable. Standard names are all in lower case, regardless of what case is used in ordinary writing. This is for simplicity in matching strings. Case-sensitive matching would inevitably trip people up and cause a nuisance when they got it wrong. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] standard names and area type for ice sheet surface mass balance
Dear Alison Re: land_ice_surface_specific_mass_balance_flux (kg m-2 s-1) When entering the third name into the vocabulary editor I noticed that it is very similar to an existing name land_ice_surface_specific_mass_balance (m s-1). The definition of the existing name says Specific mass balance means the net rate at which ice is added per unit area at the land ice surface which also sounds very similar to the definition of your proposed name. However, the units of m s-1 make me think this name perhaps refers to the thickness of ice being deposited/ablated per unit time so should it really refer to mass balance? Your proposed name has units of kg m-2 s-1 which seems correct for a mass flux. Please can you confirm that the two quantities are distinct? Do you think we need to modify the existing name? Thanks for noticing this. It shows the value of the vocab editor! Yes, I propose that the existing name in m s-1 should be changed to land_ice_surface_specific_mass_balance_rate and the same for land_ice_lwe_surface_specific_mass_balance_rate The use of rate is consistent with other names in m s-1 such as land_ice_lwe_basal_melt_rate and will distinguish them from flux names. Thanks for making the other changes. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] CF feature type trajectory (Ch. 9; May 10, 2011) and axis, attribute
Hey John, Thanks for the info. Jonathan Gregory stated that this fix would roll out with CF-1.6; is that still correct? What will the Chapter 9 examples look like then? Will any requirements based on feature types be addressed for the axis attribute? Thanks, Chris On 07/25/2011 12:51 PM, John Caron wrote: Hi Chris: I think we agreed that this sentence in section 5 should be removed: The|axis|attribute is not allowed for auxiliary coordinate variables. If anyone has a better idea, let me know. otherwise i will submit a defect change. John On 7/20/2011 7:51 AM, Chris Paver wrote: Dear list, Was there any resolution to the issue I brought up? Thanks, Chris Original Message Date: Thu, 07 Jul 2011 11:59:09 -0700 From: Steve Hankin steven.c.han...@noaa.gov Subject: Re: [CF-metadata] CF feature type trajectory (Ch. 9; May 10, 2011) and axis attribute To: Jeffrey F. Painter paint...@llnl.gov Cc: cf-metadata@cgd.ucar.edu Message-ID: 4e1601fd.5020...@noaa.gov Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 7/7/2011 11:53 AM, Jeffrey F. Painter wrote: It looks as though you've been reviewing the public draft of the future CF Conventions version 1.6. It's great that someone has been looking at it! It seems to me that z in the examples of Appendix H (formerly designated A9) plays the role of an auxiliary coordinate variable, although technically it's not because there isn't (but should be) a 'coordinates' attribute which lists auxiliary coordinate variables. I don't know why axes are banned for auxiliary coordinate variables in the case of trajectories. Something needs to be clarified here, or the examples changed. This was ticket 37. Are there any comments from Steve Hankin, the moderator, or any of the other people who contributed to writing Chapter 9, or anyone else who knows more than me? stand by. I think Chris has pointed out a needed correction to Chapter 5 that was discussed, but was not documented. (thanks Chris) But need to confirm with others. - Steve Thanks to all! - Jeff Painter On 7/7/11 5:13 AM, Chris Paver wrote: Dear List, I have been reviewing the use of the axis attribute as defined in Chapter 5, and comparing it to the trajectory example in the Chapter 9 document at A9.4. The Ch. 5 rules states that only a coordinate variable can have an axis attribute, whereas the auxiliary variables cannot. However, in Ch. 9, the single trajectory dimension is time, but the variable z contains the axis attribute. Is this a change to the rule as stated in Ch. 5, or a typo? I briefly looked over the other feature types in Ch. 9, and they all look to have the vertical variable listed with the axis attribute, so maybe it is a typo. Thanks, Chris ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- Chris Paver, Oceanographer NOAA/NODC E/OC1 1315 East-West Hwy Silver Spring MD 20910 Phone: 301-713-3272 ext. 118 Fax: 301-713-3302 http://www.nodc.noaa.gov/ ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] CF feature type trajectory (Ch. 9; May 10, 2011) and axis, attribute
I'll include Ticket 62 with CF-1.6. The Chapter 9 examples are Appendix H, now available in the public draft of CF 1.6. At the moment I don't remember what's in them! - Jeff On 7/26/11 2:13 PM, Chris Paver wrote: Hey John, Thanks for the info. Jonathan Gregory stated that this fix would roll out with CF-1.6; is that still correct? What will the Chapter 9 examples look like then? Will any requirements based on feature types be addressed for the axis attribute? Thanks, Chris On 07/25/2011 12:51 PM, John Caron wrote: Hi Chris: I think we agreed that this sentence in section 5 should be removed: The|axis|attribute is not allowed for auxiliary coordinate variables. If anyone has a better idea, let me know. otherwise i will submit a defect change. John On 7/20/2011 7:51 AM, Chris Paver wrote: Dear list, Was there any resolution to the issue I brought up? Thanks, Chris Original Message Date: Thu, 07 Jul 2011 11:59:09 -0700 From: Steve Hankinsteven.c.han...@noaa.gov Subject: Re: [CF-metadata] CF feature type trajectory (Ch. 9; May 10, 2011) and axis attribute To: Jeffrey F. Painterpaint...@llnl.gov Cc: cf-metadata@cgd.ucar.edu Message-ID:4e1601fd.5020...@noaa.gov Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 7/7/2011 11:53 AM, Jeffrey F. Painter wrote: It looks as though you've been reviewing the public draft of the future CF Conventions version 1.6. It's great that someone has been looking at it! It seems to me that z in the examples of Appendix H (formerly designated A9) plays the role of an auxiliary coordinate variable, although technically it's not because there isn't (but should be) a 'coordinates' attribute which lists auxiliary coordinate variables. I don't know why axes are banned for auxiliary coordinate variables in the case of trajectories. Something needs to be clarified here, or the examples changed. This was ticket 37. Are there any comments from Steve Hankin, the moderator, or any of the other people who contributed to writing Chapter 9, or anyone else who knows more than me? stand by. I think Chris has pointed out a needed correction to Chapter 5 that was discussed, but was not documented. (thanks Chris) But need to confirm with others. - Steve Thanks to all! - Jeff Painter On 7/7/11 5:13 AM, Chris Paver wrote: Dear List, I have been reviewing the use of the axis attribute as defined in Chapter 5, and comparing it to the trajectory example in the Chapter 9 document at A9.4. The Ch. 5 rules states that only a coordinate variable can have an axis attribute, whereas the auxiliary variables cannot. However, in Ch. 9, the single trajectory dimension is time, but the variable z contains the axis attribute. Is this a change to the rule as stated in Ch. 5, or a typo? I briefly looked over the other feature types in Ch. 9, and they all look to have the vertical variable listed with the axis attribute, so maybe it is a typo. Thanks, Chris ___ 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] CF feature type trajectory (Ch. 9; May 10, 2011) and axis, attribute
I added Ticket 62 to my to-do list for CF 1.6. This is a bit unusual in that the ticket has no moderator. So if there are no objections, I'll close the ticket and implement the wording which Jonathan proposed on the Trac system on 12/23/10. I was wrong when I said there were examples without the required coordinates attribute - I hadn't looked at them carefully enough. - Jeff On 7/26/11 2:13 AM, Jonathan Gregory wrote: Dear Chris, Jeff, Steve, John It seems to me that z in the examples of Appendix H (formerly designated A9) plays the role of an auxiliary coordinate variable, although technically it's not because there isn't (but should be) a 'coordinates' attribute which lists auxiliary coordinate variables. I don't know why axes are banned for auxiliary coordinate variables in the case of trajectories. Something needs to be clarified here, or the examples changed. This was ticket 37. Are there any comments from Steve Hankin, the moderator, or any of the other people who contributed to writing Chapter 9, or anyone else who knows more than me? stand by. I think Chris has pointed out a needed correction to Chapter 5 that was discussed, but was not documented. (thanks Chris) But need to confirm with others. Ticket 62 discusses the proposed change to allow auxiliary coordinate variables to have the axis attribute. This ticket was originally proposed by Karl to correct a defect, and I think when we were writing chapter 9 we had in mind this change. I propose that ticket 62 should be implemented in CF 1.6 (it wasn't one of the tickets I had listed earlier to Jeff - I must have overlooked it). In that ticket, I proposed some wording, to which no-one subsequently objected, and that was many months ago. Also, Jeff, if there are any examples in App H where a data variables does not list its aux coord vars in a coordinates attribute, please could you correct them? This is required, as you say. It says in 9.5, The coordinates attribute must be attached to every data variable to indicate the spatiotemporal coordinate variables that are needed to geo-locate the data. Best wishes and thanks 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
