Re: [CF-metadata] Rotated-pole grids
Thanks all - I can certainly see the convenience value in including the lat/lon arrays, but it is frustrating that some tools will reject a dataset because of the absence of mandatory fields that they don't need! Still, you have provided many valid arguments for retaining the arrays and it's good to have confirmation that this information is indeed redundant. Just a word about GIS clients, picking up on one of Steve's comments - many GIS clients would prefer to have the coordinate system properly specified (as a CRS code or Well-Known Text) rather than by listing the lat-lons exhaustively. (Another conversation could be started to discuss the value of including these as optional attributes, since most of the CF projections are commonly used in GIS.) Cheers, Jon On Wed, Jun 17, 2009 at 6:43 PM, John Caron wrote: > A few more cents: > > 1. Its more powerful for the client to know the projection transformation > than to know only the 2D lat/lon values. For that reason I always encourage > providers to include the projection info. When the client doesnt know what > to do with the projection info, having the 2D lat/lon info make the data > useable anyway, and for that reason i think the decision by CF to require > the 2D lat/lon is correct for archival files. > > 2. The CDM/TDS uses netcdf/CF as a way to transfer binary information in WCS > and other web services. Adding two-dim lat/lon fields can triple (worst > case) the size of the file. For that reason CDM/TDS allows the user to > specify if they want 2D lat/lon fields or not. This makes the files not > strictly CF compliant, but we leave it to the client to decide what tradeoff > they want. > The point is that web service binary encoding is a use case likely not > originally envisioned by the CF committee. > > Steve Hankin wrote: >> >> [with a small correction embedded in "**", because I know our community >> will point it out if I don't] >> >> Hi Jon, >> >> Assuming I've understood your situation ... >> >> First to restate the party line: The philosophy of CF has always been >> that the coordinate systems be self-describing without the application >> needing to know the specific algorithms used to calculate coordinates (from >> the name of the projection and a list of parameters). This approach has >> great merit. It shifts the burden of generating coordinates from clients, >> who would need to know all projection types (in a dynamically growing list), >> to the individual data provider, who needs to know how to generate just the >> coordinates for the particular coordinate system being used. Admittedly, >> there are some geometric computations that are only possible through >> knowledge of the projection parameters. For that reason **and because GIS >> clients will likely require the projection parameters** those parameters >> have been added over the past 2-3 years to CF. GFDL's proposed "gridspec" >> additions to CF actually find a way to include most of that geometry >> information in the file without the need to know the projection parameters >> -- making the file more self-describing, but again at the expense of effort >> to the data provider. (Gridspec tooling can add a whole lot of additional >> power, too -- support for generalized regridding, etc.) >> >> It sounds like the situation that you face is that you are the lucky one >> to receive files that contain implied coordinates and you have to serve them >> as CF with explicit coordinates. That is a pain in the neck for sure. On >> the other hand think of the bright side ;-) . The pain in the neck lands >> only on you; not on every client who would access this file. That seems >> like a good trade-off to promote broad interoperability. (Would a GIS >> client understand a rotated pole projection? It seems like a projection >> that might be known only by numerical ocean modelers.) >> >> 2 cents - Steve >> >> === >> >> Jon Blower wrote: >>> >>> Thanks for the confirmation Don. This seems very odd indeed - if the >>> source data don't contain the (real) lon and lat coordinates then it's >>> quite onerous (and quite pointless) to do so in a convenient fashion >>> (it would generally involve re-writing the headers, or using some long >>> and ugly NcML). Presumably there must have been a good reason for >>> including these coordinates? >>> >>> Cheers, Jon >>> >>> On Wed, Jun 17, 2009 at 3:52 PM, Don Murray >>> wrote: >>> John- I believe for all grid_mappings that lat/lon are required even though the grid mapping defines the transformations necessary. I think it is redundant in all cases, not just for the rotated lat/lon. Don Jon Blower wrote: > > Dear all, > > We have some data that use a rotated pole grid. The CF convention for > describing this is here: > > > http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.html#id2985006. > Are the
Re: [CF-metadata] Rotated-pole grids
A few more cents: 1. Its more powerful for the client to know the projection transformation than to know only the 2D lat/lon values. For that reason I always encourage providers to include the projection info. When the client doesnt know what to do with the projection info, having the 2D lat/lon info make the data useable anyway, and for that reason i think the decision by CF to require the 2D lat/lon is correct for archival files. 2. The CDM/TDS uses netcdf/CF as a way to transfer binary information in WCS and other web services. Adding two-dim lat/lon fields can triple (worst case) the size of the file. For that reason CDM/TDS allows the user to specify if they want 2D lat/lon fields or not. This makes the files not strictly CF compliant, but we leave it to the client to decide what tradeoff they want. The point is that web service binary encoding is a use case likely not originally envisioned by the CF committee. Steve Hankin wrote: [with a small correction embedded in "**", because I know our community will point it out if I don't] Hi Jon, Assuming I've understood your situation ... First to restate the party line: The philosophy of CF has always been that the coordinate systems be self-describing without the application needing to know the specific algorithms used to calculate coordinates (from the name of the projection and a list of parameters). This approach has great merit. It shifts the burden of generating coordinates from clients, who would need to know all projection types (in a dynamically growing list), to the individual data provider, who needs to know how to generate just the coordinates for the particular coordinate system being used. Admittedly, there are some geometric computations that are only possible through knowledge of the projection parameters. For that reason **and because GIS clients will likely require the projection parameters** those parameters have been added over the past 2-3 years to CF. GFDL's proposed "gridspec" additions to CF actually find a way to include most of that geometry information in the file without the need to know the projection parameters -- making the file more self-describing, but again at the expense of effort to the data provider. (Gridspec tooling can add a whole lot of additional power, too -- support for generalized regridding, etc.) It sounds like the situation that you face is that you are the lucky one to receive files that contain implied coordinates and you have to serve them as CF with explicit coordinates. That is a pain in the neck for sure. On the other hand think of the bright side ;-) . The pain in the neck lands only on you; not on every client who would access this file. That seems like a good trade-off to promote broad interoperability. (Would a GIS client understand a rotated pole projection? It seems like a projection that might be known only by numerical ocean modelers.) 2 cents - Steve === Jon Blower wrote: Thanks for the confirmation Don. This seems very odd indeed - if the source data don't contain the (real) lon and lat coordinates then it's quite onerous (and quite pointless) to do so in a convenient fashion (it would generally involve re-writing the headers, or using some long and ugly NcML). Presumably there must have been a good reason for including these coordinates? Cheers, Jon On Wed, Jun 17, 2009 at 3:52 PM, Don Murray wrote: John- I believe for all grid_mappings that lat/lon are required even though the grid mapping defines the transformations necessary. I think it is redundant in all cases, not just for the rotated lat/lon. Don Jon Blower wrote: Dear all, We have some data that use a rotated pole grid. The CF convention for describing this is here: http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.html#id2985006. Are the 2D lon and lat variables in this example really necessary? They would seem to be redundant as their values can be calculated from rlon, rlat and the location of the new "north" pole. Thanks, Jon -- * Don Murray UCAR Unidata Program dmur...@unidata.ucar.eduP.O. Box 3000 (303) 497-8628 Boulder, CO 80307 http://www.unidata.ucar.edu/staff/donm * ___ 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] Rotated-pole grids
Hi Jon, In our experience they are very useful coordinate variables. Allowing a simple and quick lookup without having to perform any calculations. For example, cdms allows you to say: >>> print myvar.getLatitude() 52.4555 If the data provider knows the lats and lons at write time it is far easier to provide them than to expect all users to re-generate them. It just simplifies usage. Cheers, Ag -Original Message- From: cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Jon Blower Sent: 17 June 2009 15:46 To: CF metadata Cc: Adit Santokhee Subject: [CF-metadata] Rotated-pole grids Dear all, We have some data that use a rotated pole grid. The CF convention for describing this is here: http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.htm l#id2985006. Are the 2D lon and lat variables in this example really necessary? They would seem to be redundant as their values can be calculated from rlon, rlat and the location of the new "north" pole. Thanks, Jon -- Dr Jon Blower Technical Director, Reading e-Science Centre Environmental Systems Science Centre University of Reading Harry Pitt Building, 3 Earley Gate Reading RG6 6AL. UK Tel: +44 (0)118 378 5213 Fax: +44 (0)118 378 6413 j.d.blo...@reading.ac.uk http://www.nerc-essc.ac.uk/People/Staff/Blower_J.htm ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- Scanned by iCritical. ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] Salinity units
FWIW I've heard the same opinion from physical oceanographers (probably the same ones!) that salinity has no units. I.e. that one says "the salinity is 35", not "the salinity is 35psu". I interpret this as meaning that the unit is actually part of the definition of what salinity is (i.e. if it's not in psu then it's not salinity: http://en.wikipedia.org/wiki/Salinity). I agree with Jonathan that this seems strange and could cause confusion, particularly since I think there has been more than one way of defining the salinity scale and I have certainly seen different ways of expressing salinity (whether technically correct or not) in data files in per mil or other units. I'm certainly not an expert here though. The question of how to express this given CF's dependency on udunits (which should surely itself be reviewed - but that's another discussion). Jon On Wed, Jun 17, 2009 at 8:18 AM, Lowry, Roy K wrote: > Hello Jonathan, > > The reason I'm resurrecting this discussion is that we came under strong > pressure from a group of physical oceanographers to use 'dimensionless' with > no scaling factor instead of PSU for salinity. I was raising the issue on > the list to see how widespread this opinion was. > > Cheers, Roy. > > -Original Message- > From: cf-metadata-boun...@cgd.ucar.edu > [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Jonathan Gregory > Sent: 17 June 2009 08:06 > To: cf-metadata@cgd.ucar.edu > Subject: [CF-metadata] Salinity units > > Dear Roy and Alison > > The intention of recording the units as 1e-3 (dimensionless) was to suggest > a canonical unit of PSU i.e. approximately the same as parts per thousand. > However, this is unclear and therefore unsatisfactory. We have discussed this > before, in fact, and I believe we have decided in principle that the unit > should be indicated as psu. Since that is not a legal unit in the standard > udunits.dat, in past discussions we have also decided we would publish our > own CF version of udunits.dat, including psu as a unit (not convertible to > other units). The CF udunits.dat should also include sverdrup (=1e6 m3 s-1) > and bel B (hence decibel dB, dimensionless). The latter is already given as > the canonical unit for some standard names, although it is not a legal udunit. > > I'd suggest that the CF udunits.dat, with these changes, should be put on our > website, mentioned in 3.1 section about units in the CF standard, and used by > the CF checker. > > Best wishes > > Jonathan > ___ > 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 > -- Dr Jon Blower Technical Director, Reading e-Science Centre Environmental Systems Science Centre University of Reading Harry Pitt Building, 3 Earley Gate Reading RG6 6AL. UK Tel: +44 (0)118 378 5213 Fax: +44 (0)118 378 6413 j.d.blo...@reading.ac.uk http://www.nerc-essc.ac.uk/People/Staff/Blower_J.htm ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] Rotated-pole grids
[with a small correction embedded in "**", because I know our community will point it out if I don't] Hi Jon, Assuming I've understood your situation ... First to restate the party line: The philosophy of CF has always been that the coordinate systems be self-describing without the application needing to know the specific algorithms used to calculate coordinates (from the name of the projection and a list of parameters). This approach has great merit. It shifts the burden of generating coordinates from clients, who would need to know all projection types (in a dynamically growing list), to the individual data provider, who needs to know how to generate just the coordinates for the particular coordinate system being used. Admittedly, there are some geometric computations that are only possible through knowledge of the projection parameters. For that reason **and because GIS clients will likely require the projection parameters** those parameters have been added over the past 2-3 years to CF. GFDL's proposed "gridspec" additions to CF actually find a way to include most of that geometry information in the file without the need to know the projection parameters -- making the file more self-describing, but again at the expense of effort to the data provider. (Gridspec tooling can add a whole lot of additional power, too -- support for generalized regridding, etc.) It sounds like the situation that you face is that you are the lucky one to receive files that contain implied coordinates and you have to serve them as CF with explicit coordinates. That is a pain in the neck for sure. On the other hand think of the bright side ;-) . The pain in the neck lands only on you; not on every client who would access this file. That seems like a good trade-off to promote broad interoperability. (Would a GIS client understand a rotated pole projection? It seems like a projection that might be known only by numerical ocean modelers.) 2 cents - Steve === Jon Blower wrote: Thanks for the confirmation Don. This seems very odd indeed - if the source data don't contain the (real) lon and lat coordinates then it's quite onerous (and quite pointless) to do so in a convenient fashion (it would generally involve re-writing the headers, or using some long and ugly NcML). Presumably there must have been a good reason for including these coordinates? Cheers, Jon On Wed, Jun 17, 2009 at 3:52 PM, Don Murray wrote: John- I believe for all grid_mappings that lat/lon are required even though the grid mapping defines the transformations necessary. I think it is redundant in all cases, not just for the rotated lat/lon. Don Jon Blower wrote: Dear all, We have some data that use a rotated pole grid. The CF convention for describing this is here: http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.html#id2985006. Are the 2D lon and lat variables in this example really necessary? They would seem to be redundant as their values can be calculated from rlon, rlat and the location of the new "north" pole. Thanks, Jon -- * Don Murray UCAR Unidata Program dmur...@unidata.ucar.eduP.O. Box 3000 (303) 497-8628 Boulder, CO 80307 http://www.unidata.ucar.edu/staff/donm * ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] Rotated-pole grids
Hi Jon, Assuming I've understood your situation ... First to restate the party line: The philosophy of CF has always been that the coordinate systems be self-describing without the application needing to know the specific algorithms used to calculate coordinates (from the name of the projection and a list of parameters). This approach has great merit. It shifts the burden of generating coordinates from clients, who would need to know all projection types (in a dynamically growing list), to the individual data provider, who needs to know how to generate just the coordinates for the particular coordinate system being used. Admittedly, there are some geometric computations that are only possible through knowledge of the projection parameters, and for that reason those parameters have been added over the past 2-3 years to CF. GFDL's proposed "gridspec" additions to CF actually find a way to include most of that geometry information in the file without the need to know the projection parameters -- making the file more self-describing, but again at the expense of effort to the data provider. (Gridspec tooling can add a whole lot of additional power, too -- support for generalized regridding, etc.) It sounds like the situation that you face is that you are the lucky one to receive files that contain implied coordinates and you have to serve them as CF with explicit coordinates. That is a pain in the neck for sure. On the other hand think of the bright side ;-) . The pain in the neck lands only on you; not on every client who would access this file. That seems like a good trade-off to promote broad interoperability. (Would a GIS client understand a rotated pole projection? It seems like a projection that might be known only by numerical ocean modelers.) 2 cents - Steve === Jon Blower wrote: Thanks for the confirmation Don. This seems very odd indeed - if the source data don't contain the (real) lon and lat coordinates then it's quite onerous (and quite pointless) to do so in a convenient fashion (it would generally involve re-writing the headers, or using some long and ugly NcML). Presumably there must have been a good reason for including these coordinates? Cheers, Jon On Wed, Jun 17, 2009 at 3:52 PM, Don Murray wrote: John- I believe for all grid_mappings that lat/lon are required even though the grid mapping defines the transformations necessary. I think it is redundant in all cases, not just for the rotated lat/lon. Don Jon Blower wrote: Dear all, We have some data that use a rotated pole grid. The CF convention for describing this is here: http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.html#id2985006. Are the 2D lon and lat variables in this example really necessary? They would seem to be redundant as their values can be calculated from rlon, rlat and the location of the new "north" pole. Thanks, Jon -- * Don Murray UCAR Unidata Program dmur...@unidata.ucar.eduP.O. Box 3000 (303) 497-8628 Boulder, CO 80307 http://www.unidata.ucar.edu/staff/donm * ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] Rotated-pole grids
Thanks for the confirmation Don. This seems very odd indeed - if the source data don't contain the (real) lon and lat coordinates then it's quite onerous (and quite pointless) to do so in a convenient fashion (it would generally involve re-writing the headers, or using some long and ugly NcML). Presumably there must have been a good reason for including these coordinates? Cheers, Jon On Wed, Jun 17, 2009 at 3:52 PM, Don Murray wrote: > John- > > I believe for all grid_mappings that lat/lon are required even though the > grid mapping defines the transformations necessary. I think it is redundant > in all cases, not just for the rotated lat/lon. > > Don > > Jon Blower wrote: >> >> Dear all, >> >> We have some data that use a rotated pole grid. The CF convention for >> describing this is here: >> >> http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.html#id2985006. >> Are the 2D lon and lat variables in this example really necessary? >> They would seem to be redundant as their values can be calculated from >> rlon, rlat and the location of the new "north" pole. >> >> Thanks, Jon >> > > -- > * > Don Murray UCAR Unidata Program > dmur...@unidata.ucar.edu P.O. Box 3000 > (303) 497-8628 Boulder, CO 80307 > http://www.unidata.ucar.edu/staff/donm > * > > -- Dr Jon Blower Technical Director, Reading e-Science Centre Environmental Systems Science Centre University of Reading Harry Pitt Building, 3 Earley Gate Reading RG6 6AL. UK Tel: +44 (0)118 378 5213 Fax: +44 (0)118 378 6413 j.d.blo...@reading.ac.uk http://www.nerc-essc.ac.uk/People/Staff/Blower_J.htm ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] Rotated-pole grids
John- I believe for all grid_mappings that lat/lon are required even though the grid mapping defines the transformations necessary. I think it is redundant in all cases, not just for the rotated lat/lon. Don Jon Blower wrote: Dear all, We have some data that use a rotated pole grid. The CF convention for describing this is here: http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.html#id2985006. Are the 2D lon and lat variables in this example really necessary? They would seem to be redundant as their values can be calculated from rlon, rlat and the location of the new "north" pole. Thanks, Jon -- * Don Murray UCAR Unidata Program dmur...@unidata.ucar.eduP.O. Box 3000 (303) 497-8628 Boulder, CO 80307 http://www.unidata.ucar.edu/staff/donm * ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
[CF-metadata] Rotated-pole grids
Dear all, We have some data that use a rotated pole grid. The CF convention for describing this is here: http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.html#id2985006. Are the 2D lon and lat variables in this example really necessary? They would seem to be redundant as their values can be calculated from rlon, rlat and the location of the new "north" pole. Thanks, Jon -- Dr Jon Blower Technical Director, Reading e-Science Centre Environmental Systems Science Centre University of Reading Harry Pitt Building, 3 Earley Gate Reading RG6 6AL. UK Tel: +44 (0)118 378 5213 Fax: +44 (0)118 378 6413 j.d.blo...@reading.ac.uk http://www.nerc-essc.ac.uk/People/Staff/Blower_J.htm ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
[CF-metadata] Salinity units
Dear Russ I think it's a good development for udunits to support logarithmic units. In CF standard names, however, we have taken the approach of stating the reference level as part of the definition of the quantity, possibly allowing it to be specified alternatively in a scalar coordinate variable. Therefore the units of the quantity can be simply given as dB, without reference level. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] Salinity units
Jonathan, > The intention of recording the units as 1e-3 (dimensionless) was to > suggest a canonical unit of PSU i.e. approximately the same as parts > per thousand. However, this is unclear and therefore > unsatisfactory. We have discussed this before, in fact, and I believe > we have decided in principle that the unit should be indicated as > psu. Since that is not a legal unit in the standard udunits.dat, in > past discussions we have also decided we would publish our own CF > version of udunits.dat, including psu as a unit (not convertible to > other units). The CF udunits.dat should also include sverdrup (=1e6 m3 > s-1) and bel B (hence decibel dB, dimensionless). The latter is > already given as the canonical unit for some standard names, although > it is not a legal udunit. The ability to represent logarithmic units such as decibels has been added to udunits, although the string representation for such units includes a reference level. For example, decibels can be represented as "0.1 lg(re m/(5 s)^2) @ 50". The new udunits software also has an XML database that can be extended with new units, a new API, and support for the current udunits API: http://www.unidata.ucar.edu/software/udunits/ We're planning on including the new udunits with the upcoming netCDF 4.1 release, but you can try it now by configuring with --enable-udunits in the current snapshot release. > I'd suggest that the CF udunits.dat, with these changes, should be put on our > website, mentioned in 3.1 section about units in the CF standard, and used by > the CF checker. That seems like a good idea, and I think we should also include the XML version if the new udunits package becomes more widely used. --Russ ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] salinity units
to throw in an oceanographers viewpoint... measured salinity has no units - it is determined from conductivity and has no relationship to ppt, ppm psu or any other unit. 10-3 seems very dangerous (and equally wrong) the only 'units' used recently (officially) are to state 'pss78' to define that salinity has been determined from the practical salinity scale, 1978. In the UNESCO report (UNESCO (1985) The international system of units (SI) in oceanography, UNESCO Technical Papers No. 45, IAPSO Pub. Sci. No. 32, Paris, France.) you can see (pages 43 / 44) that the 10-3 units was from an older definition of salinity and definitely should NOT be used when using pss78. Having said that, I understand that there is a lot of work going on at the moment to redefine salinity, and that this is likely to 'relink' conductivity measurements and salt concentrations, so we are likely to get a salinity units again soon (but this is an oceanographic soon - faster than an geological one, but not by much) Helen On 17 Jun 2009, at 09:19, Lowry, Roy K wrote: Dear All, Might be worth looking at http://www.oceanographers.net/forums/showthread.php?t=902 Cheers, Roy. -- 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. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Helen --- Dr. Helen Snaith Head of Scientific Data Management 254/23 National Oceanography Centre, Southampton European Way, Southampton, SO14 3ZH, UK Tel: +44 (0)23 8059 6410Fax: +44 (0)23 8059 6400 e-mail: h.sna...@noc.soton.ac.uk This e-mail (and any attachments) is confidential and intended solely for the use of the individual or entity to whom it is addressed. Both NERC and the University of Southampton (who operate NOCS as a collaboration) are subject to the Freedom of Information Act 2000. The information contained in this e-mail and any reply you make may be disclosed unless it is legally exempt from disclosure. Any material supplied to NOCS may be stored in the electronic records management system of either the University or NERC as appropriate. ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
[CF-metadata] salinity units
Dear All, Might be worth looking at http://www.oceanographers.net/forums/showthread.php?t=902 Cheers, Roy. -- 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] Salinity units
Dear Roy > The reason I'm resurrecting this discussion is that we came under strong > pressure from a group of physical oceanographers to use 'dimensionless' with > no scaling factor instead of PSU for salinity. I was raising the issue on > the list to see how widespread this opinion was. Yes, I see. It is good to bring it up again since it has not been resolved. I think giving a unit of 1 would be confusing and therefore not a good idea. No-one would know what was being suggested e.g. whether salinity is about 0.035 or about 35. To specify it as psu and permit this as a udunit would be much clearer, I believe. As you say, it would be good to know general opinion. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] Salinity units
Hello Jonathan, The reason I'm resurrecting this discussion is that we came under strong pressure from a group of physical oceanographers to use 'dimensionless' with no scaling factor instead of PSU for salinity. I was raising the issue on the list to see how widespread this opinion was. Cheers, Roy. -Original Message- From: cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Jonathan Gregory Sent: 17 June 2009 08:06 To: cf-metadata@cgd.ucar.edu Subject: [CF-metadata] Salinity units Dear Roy and Alison The intention of recording the units as 1e-3 (dimensionless) was to suggest a canonical unit of PSU i.e. approximately the same as parts per thousand. However, this is unclear and therefore unsatisfactory. We have discussed this before, in fact, and I believe we have decided in principle that the unit should be indicated as psu. Since that is not a legal unit in the standard udunits.dat, in past discussions we have also decided we would publish our own CF version of udunits.dat, including psu as a unit (not convertible to other units). The CF udunits.dat should also include sverdrup (=1e6 m3 s-1) and bel B (hence decibel dB, dimensionless). The latter is already given as the canonical unit for some standard names, although it is not a legal udunit. I'd suggest that the CF udunits.dat, with these changes, should be put on our website, mentioned in 3.1 section about units in the CF standard, and used by the CF checker. Best wishes Jonathan ___ 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] Salinity units
Dear Roy and Alison The intention of recording the units as 1e-3 (dimensionless) was to suggest a canonical unit of PSU i.e. approximately the same as parts per thousand. However, this is unclear and therefore unsatisfactory. We have discussed this before, in fact, and I believe we have decided in principle that the unit should be indicated as psu. Since that is not a legal unit in the standard udunits.dat, in past discussions we have also decided we would publish our own CF version of udunits.dat, including psu as a unit (not convertible to other units). The CF udunits.dat should also include sverdrup (=1e6 m3 s-1) and bel B (hence decibel dB, dimensionless). The latter is already given as the canonical unit for some standard names, although it is not a legal udunit. I'd suggest that the CF udunits.dat, with these changes, should be put on our website, mentioned in 3.1 section about units in the CF standard, and used by the CF checker. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
