Re: [CF-metadata] water level with/without datum
Hello Jonathan, I have concerns about having separate names for river, lake and sea. If you have them for height, then the logic would extend to temperature. I have temperature data from a boat that started in the North Sea, went up the Humber and then up to the navigable limit of the Yorkshire Ouse. I would much prefer a single Standard Name across the whole dataset. My suggestion of 'water body' as the generic term didn't get any reaction. Was that acceptance or did nobody notice it? Cheers, Roy. -Original Message- From: cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Jonathan Gregory Sent: 22 February 2010 19:02 To: Jeff deLaBeaujardiere Cc: Andrea Hardy; cf-metadata@cgd.ucar.edu Subject: [CF-metadata] water level with/without datum Dear Jeff et al About water_level_with|above_reference_datum water_level_without_reference_datum I'd like to make some suggestions: * Since we don't have a convenient word for river, lake or sea, perhaps we should have separate names for each of them i.e. sea_surface_height, lake_surface_height and river_surface_height. All these terms are in use, often in connection with altimetry. Obviously the same duplication (or triplication) could occur with other sea-related names, but we have not had a great demand for terms related to lakes and rivers up to now. Even if we did, it would not be an unmanageable expansion of the standard name table. There are currently 284 standard names containing the word sea. * If the datum is an arbitrary local benchmark, then I think a name of sea/lake/river_surface_height_above_reference_datum would be fine. If the datum itself needs to be located, we could have standard names for that such as sea/lake/river_surface_reference_datum_altitude. * If the datum is a quantity which could be regarded as a continuous function of location, I think it should be identified in the standard name, as in the existing sea_surface_height_above_geoid. Other standard names would thus be needed for sea_surface_height_above_mean_high_water etc. We also have an existing name of sea_surface_height_above_reference_ellipsoid. Here, the ellipsoid is not identified, but it can be with other CF metadata. I think that's OK because the geophysical intention of the reference ellipsoid is always the same, so this is in a sense a matter of measurement rather than the quantity itself. By contrast, mean high water is a different geophysical concept from the geoid. 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
Re: [CF-metadata] water level with/without datum
Dear Roy I have concerns about having separate names for river, lake and sea. If you have them for height, then the logic would extend to temperature. I have temperature data from a boat that started in the North Sea, went up the Humber and then up to the navigable limit of the Yorkshire Ouse. I would much prefer a single Standard Name across the whole dataset. I share that concern, but I didn't have a use-case where it would be a problem to have separate names, so thanks for that. My suggestion of 'water body' as the generic term didn't get any reaction. Was that acceptance or did nobody notice it? I noticed it, yes, thanks! It is a correct generic term, of course, but I feel it would cause a loss of clarity to replace sea with water body in existing standard names e.g. water_body_surface_height, water_body_water_temperature, water_body_water_speed and water_body_ice_thickness are all unfamiliar terms, whereas sea_surface_height, sea_water_temperature, sea_water_speed and sea_ice_thickness are all recognisable. In the particular case of Jeff's, water body surface height is not a term that Google finds, whereas sea surface height, lake surface height and river surface height do all exist. More cumbersome than water body, but clearer I think, would be to use the phrase sea/lake/river (I think / is a permitted character) e.g. sea/lake/river_surface_height, sea/lake/river_water_temperature. We could provide such names of this type as are requested, for generic uses like yours, but keep the sea names as well. In a case such as yours, would it be acceptable to use sea all the time, even when it's a river? Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] water level with/without datum
Hi Roy, Would simply inventing an artificial new term to represent sea+lakes+rivers be an option here? Presumably, back in the day, there was no word for a land-locked body of fresh water so someone thought, I know, I'll call it a 'lake'. Or whatever the latin/greek equivalent was back then! So we might choose, say, the word 'sorl', this being an acronym for seas, oceans, rivers and lakes. Sure that's not very pretty but no doubt someone can think of a better word. Answers on an e-postcard... Regards, Phil -Original Message- From: cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Lowry, Roy K Sent: 23 February 2010 09:06 To: Jonathan Gregory Cc: Andrea Hardy; cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] water level with/without datum Hello again, I wouldn't recommend using '/' in a string, such as a Standard Name, that could potentially be incorporated into a URL. I think using 'sea' as defined shorthand for 'river/lake/sea' has been suggested before. I certainly have no problem with it as long as that information is included in the definition. Cheers, Roy. -Original Message- From: Jonathan Gregory [mailto:jonat...@met.reading.ac.uk] On Behalf Of Jonathan Gregory Sent: 23 February 2010 08:47 To: Lowry, Roy K Cc: Jeff deLaBeaujardiere; Andrea Hardy; cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] water level with/without datum Dear Roy I have concerns about having separate names for river, lake and sea. If you have them for height, then the logic would extend to temperature. I have temperature data from a boat that started in the North Sea, went up the Humber and then up to the navigable limit of the Yorkshire Ouse. I would much prefer a single Standard Name across the whole dataset. I share that concern, but I didn't have a use-case where it would be a problem to have separate names, so thanks for that. My suggestion of 'water body' as the generic term didn't get any reaction. Was that acceptance or did nobody notice it? I noticed it, yes, thanks! It is a correct generic term, of course, but I feel it would cause a loss of clarity to replace sea with water body in existing standard names e.g. water_body_surface_height, water_body_water_temperature, water_body_water_speed and water_body_ice_thickness are all unfamiliar terms, whereas sea_surface_height, sea_water_temperature, sea_water_speed and sea_ice_thickness are all recognisable. In the particular case of Jeff's, water body surface height is not a term that Google finds, whereas sea surface height, lake surface height and river surface height do all exist. More cumbersome than water body, but clearer I think, would be to use the phrase sea/lake/river (I think / is a permitted character) e.g. sea/lake/river_surface_height, sea/lake/river_water_temperature. We could provide such names of this type as are requested, for generic uses like yours, but keep the sea names as well. In a case such as yours, would it be acceptable to use sea all the time, even when it's a river? Best wishes Jonathan -- 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] water level with/without datum
Hi Phil, Jonathan's argument against 'water body' was that it was not as well-known as 'sea'. I think that the argument applies even more strongly to 'sorl'. Cheers, Roy. -Original Message- From: Bentley, Philip [mailto:philip.bent...@metoffice.gov.uk] Sent: 23 February 2010 09:25 To: Lowry, Roy K Cc: cf-metadata@cgd.ucar.edu Subject: RE: [CF-metadata] water level with/without datum Hi Roy, Would simply inventing an artificial new term to represent sea+lakes+rivers be an option here? Presumably, back in the day, there was no word for a land-locked body of fresh water so someone thought, I know, I'll call it a 'lake'. Or whatever the latin/greek equivalent was back then! So we might choose, say, the word 'sorl', this being an acronym for seas, oceans, rivers and lakes. Sure that's not very pretty but no doubt someone can think of a better word. Answers on an e-postcard... Regards, Phil -Original Message- From: cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Lowry, Roy K Sent: 23 February 2010 09:06 To: Jonathan Gregory Cc: Andrea Hardy; cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] water level with/without datum Hello again, I wouldn't recommend using '/' in a string, such as a Standard Name, that could potentially be incorporated into a URL. I think using 'sea' as defined shorthand for 'river/lake/sea' has been suggested before. I certainly have no problem with it as long as that information is included in the definition. Cheers, Roy. -Original Message- From: Jonathan Gregory [mailto:jonat...@met.reading.ac.uk] On Behalf Of Jonathan Gregory Sent: 23 February 2010 08:47 To: Lowry, Roy K Cc: Jeff deLaBeaujardiere; Andrea Hardy; cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] water level with/without datum Dear Roy I have concerns about having separate names for river, lake and sea. If you have them for height, then the logic would extend to temperature. I have temperature data from a boat that started in the North Sea, went up the Humber and then up to the navigable limit of the Yorkshire Ouse. I would much prefer a single Standard Name across the whole dataset. I share that concern, but I didn't have a use-case where it would be a problem to have separate names, so thanks for that. My suggestion of 'water body' as the generic term didn't get any reaction. Was that acceptance or did nobody notice it? I noticed it, yes, thanks! It is a correct generic term, of course, but I feel it would cause a loss of clarity to replace sea with water body in existing standard names e.g. water_body_surface_height, water_body_water_temperature, water_body_water_speed and water_body_ice_thickness are all unfamiliar terms, whereas sea_surface_height, sea_water_temperature, sea_water_speed and sea_ice_thickness are all recognisable. In the particular case of Jeff's, water body surface height is not a term that Google finds, whereas sea surface height, lake surface height and river surface height do all exist. More cumbersome than water body, but clearer I think, would be to use the phrase sea/lake/river (I think / is a permitted character) e.g. sea/lake/river_surface_height, sea/lake/river_water_temperature. We could provide such names of this type as are requested, for generic uses like yours, but keep the sea names as well. In a case such as yours, would it be acceptable to use sea all the time, even when it's a river? Best wishes Jonathan -- 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 -- 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] water level with/without datum
Hi Roy, For sure, I wasn't proposing use of the word 'sorl', that was merely an examplar. My argument was that since there appears to be no existing term for what you want to describe - at least none without overloaded meaning(s) - then just invent a completely new word. So, yes, by its very nature it wouldn't be well-known on day 1! Cheers, Phil -Original Message- From: Lowry, Roy K [mailto:r...@bodc.ac.uk] Sent: 23 February 2010 11:19 To: Bentley, Philip Cc: cf-metadata@cgd.ucar.edu Subject: RE: [CF-metadata] water level with/without datum Hi Phil, Jonathan's argument against 'water body' was that it was not as well-known as 'sea'. I think that the argument applies even more strongly to 'sorl'. Cheers, Roy. -Original Message- From: Bentley, Philip [mailto:philip.bent...@metoffice.gov.uk] Sent: 23 February 2010 09:25 To: Lowry, Roy K Cc: cf-metadata@cgd.ucar.edu Subject: RE: [CF-metadata] water level with/without datum Hi Roy, Would simply inventing an artificial new term to represent sea+lakes+rivers be an option here? Presumably, back in the day, there was no word for a land-locked body of fresh water so someone thought, I know, I'll call it a 'lake'. Or whatever the latin/greek equivalent was back then! So we might choose, say, the word 'sorl', this being an acronym for seas, oceans, rivers and lakes. Sure that's not very pretty but no doubt someone can think of a better word. Answers on an e-postcard... ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] water level with/without datum
Dear Stephen The issue here is that water doesn't only exist in these bodies of water viz seas, lakes and river. It also exists in the atmosphere and the ground. For this reason we don't have a standard name of just water temperature, for instance. We could define aqua to mean sea, lake or river, but this is not really any more self-explanatory than using an abbreviation, I'd say. Roy pointed out that / would be a dangerous character to use, so I'd next suggest sea+lake+river. I prefer + to - because - looks like _, and it's terribly confusing to have a mixture of - and _. I really would prefer defining sea to mean sea, lake or river but not everyone who's given an opinion would support that, and I agree that it's not really self-describing - it would be new jargon. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] water level with/without datum
Dear CF group: Thank you for your time in discussing this matter. I would counsel you *not* to make wholesale changes to existing names just because IOOS needs names for water levels that may or may not be measured in the ocean! Replacing 'sea_' with something else seems like it would break much existing code. Adding some names should be mostly harmless. For the specific case of water-level measurement devices, I think the term water_level_* is better, applied generically regardless of oceanic, lacustrine or riverine environment, for the following reasons. * There is no other generic name, and inventing one like SLR or sea+lake+river seems contrived. * Every use of sea_level I can find in the CF name list refers to sea level as a semi-constant reference point rather than as an instantaneous measurement. Indeed, a comment used repeatedly in the CF table is that sea_level means mean sea level, which is close to the geoid in sea areas. Therefore, separate names for sea_level_*, lake_level_ and river_level_* do not seem appropriate. * Yes, there is water in the atmosphere and underground. CF already seems to qualify those uses with terms like 'atmosphere', 'cloud' and 'in air.' Therefore, it does not seem necessary to qualify 'water' as being on the surface--simply retain the existing non-surface qualifiers. If you later need a name to refer to the level of water in an underground aquifer or something, then create one. Regarding the Use Case of measuring temperature in the sea and then continuing the trajectory upriver: there currently do not exist water_temperature names other than sea_water_temperature, so the Use Case is not satisfied at present. Perhaps in future CF could define additional generic names like water_temperature that may have specializations such as sea_water_temperature and fresh_water_temperature, but this can be done later and independently of the existing actual use case of water level measurements. Cheers, Jeff DLB -- Jeff de La Beaujardière, PhD Senior Systems Architect, Data Integration Framework Integrated Ocean Observing System (IOOS) Program Office National Oceanic and Atmospheric Administration 1100 Wayne Ave #1225, Silver Spring MD 20910 USA +1 301 427 2427 jeff.delabeaujardi...@noaa.gov ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] water level with/without datum
Dear Jeff Thanks for your email. I appreciate your arguments, which are very reasonable, but I don't agree with them so far. Replacing 'sea_' with something else seems like it would break much existing code. Adding some names should be mostly harmless. Yes, adding names is better. We can resolve this by keeping sea to mean sea, and adding some other ones to refer to sea, lake or river, as requested. We agree on that point. For the specific case of water-level measurement devices, I think the term water_level_* is better, applied generically regardless of oceanic, lacustrine or riverine environment, for the following reasons. * There is no other generic name, and inventing one like SLR or sea+lake+river seems contrived. Contrived, yes, but sea+lake+river is certainly explicit and self-explanatory, isn't it? Standard names are contrived to explain what they mean, rather than being the terms used most commonly (although some of them are common terms). The term name is a bit misleading. They are not names, in most cases. They are answers to the question, What does that mean?, when a term is used. * Every use of sea_level I can find in the CF name list refers to sea level as a semi-constant reference point rather than as an instantaneous measurement. Indeed, a comment used repeatedly in the CF table is that sea_level means mean sea level, which is close to the geoid in sea areas. Therefore, separate names for sea_level_*, lake_level_ and river_level_* do not seem appropriate. Yes, sea_level refers to a fixed level, like geoid, but the quantity you are referring to as water_level is more like sea_surface_height, which is a time-varying level, and is referred to a fixed level. I am proposing of sea+lake+river_surface_height_above_X for your water level, if it's not the sea. * Yes, there is water in the atmosphere and underground. CF already seems to qualify those uses with terms like 'atmosphere', 'cloud' and 'in air.' Therefore, it does not seem necessary to qualify 'water' as being on the surface--simply retain the existing non-surface qualifiers. If you later need a name to refer to the level of water in an underground aquifer or something, then create one. That gives a special status to water on the surface. CF names attempt to deal even-handedly with all geophysical quantities. Such an argument would mean that, in the first place, we would have used the plain name temperature to mean air temperature (since we started with atmospheric models, mostly), and later added sea_water_temperature. That would have been inconsistent and I believe that such inconsistencies would make standard names less satisfactory in practice. In general, we have tried to include some context in standard names. Regarding the Use Case of measuring temperature in the sea and then continuing the trajectory upriver: there currently do not exist water_temperature names other than sea_water_temperature, so the Use Case is not satisfied at present. Perhaps in future CF could define additional generic names like water_temperature that may have specializations such as sea_water_temperature and fresh_water_temperature, but this can be done later and independently of the existing actual use case of water level measurements. I think Roy's example is a relevant use case. Although he has not made a proposal, his data set requires either a new name of river_water_temperature, or a name which can be used for both sea and river. The existing name of sea_water_temperature is not sufficient for the case he described. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] Some questions about 360-day calendars
john caron wrote: Jonathan Blower wrote: 4) Finally on practical note: I seem to remember that someone has implemented the 360-day calendar using the Java library joda-time? Is this code available for re-use? roland schweitzer has extended joda for 360 day calendar. I am planning to use joda time or its JSR successor in the future, replacing udunits for date/time processing. To give credit where due, Emanuele Lombardi emanuele.lomba...@enea.it actually did the 360 calendar. I did the all-leap and no-leap. :-) I have all three and will gladly share them with anybody that wants them. I did send them to the joda folks, but I did not follow up to see if they went into their source tree. ROland ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] water level with/without datum
On Feb 23, 2010, at 06:33, Jonathan Gregory wrote: Contrived, yes, but sea+lake+river is certainly explicit and self- explanatory, isn't it? Standard names are contrived to explain what they mean, rather than being the terms used most commonly (although some of them are common terms). The term name is a bit misleading. They are not names, in most cases. They are answers to the question, What does that mean?, when a term is used. water_surface_height_above_x seems to meet all the criteria. It answers what does that mean? It is explicit and self-explanatory (and even reasonably short). Thanks to the 'surface' term, it can not be confused with 'atmospheric surface water height' (what would that mean?). The fact that it also applies to underground water is a non-issue, scientifically speaking, and in my mind is advantageous, because it is equally meaningful in that context. (Two data sets with this term can be compared, regardless of whether the water is underground or not -- the x normalized the reference, as does the location.) I can even construct a valid use case (for an AUV or hydro model) that is the analog of Roy's, in the case of underground streams feeding into oceans or rivers. I could handle sea+lake+river but it doesn't thrill me, because of (a) special characters which can have unintended consequences for times now and yet to come, (b) 'sea' is not self-explanatory until you know it really means ocean (in some local dialects) and excludes inland seas (or maybe not?), and (c) awkwardness. Not a preference but if all others get ruled out, there we'd be. John ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
