Re: [CF-metadata] fixed sensors, depth, datum
Dear Ethan Ah good - I am glad we agree now about the geophysical distinction. I agree with this too: > It seems there are two important characteristics that need capturing: > 1) the geophysical significance of a vertical CRS (height, altitude, > pressure, sigma, etc), and > 2) the details of a vertical CRS, possibly enough to enable > intercomparison with data on a different vertical CRS. > > The first seems appropriate to capture in the standard name attribute. I too am unsure about how station vertical datums should be dealt with, because I remain in the dark about what they mean. I suspect (as I've said before) that it may mean that a given physical location (a benchmark) is assigned a particular height above a specified definition of the geoid, and hence fixes the altitude of all other locations - but I would be very grateful to be corrected or enlightened. I think that the tidal datums, which Dale raised when he started this thread, are distinct geophysical quantities. They again are things which have to be measured and distinguished and might coexist in one dataset. There are several of them, as you say, but not as many as there are of chemical species, for instance, so I don't think they pose a serious problem. You have pointed out before that the definition of the ellipsoid affects the definition of lat and lon. Hence it relates to both vertical and horizontal CRS. To avoid repetition, it seems to me that it would be better to keep them in the same place. I agree with Phil that we could rename the grid_mapping attribute e.g. to crs (keeping the old name as an alternative for existing datasets). However, I understand that you don't like repeating the horizontal CRS if you combine it with several vertical ones in the same dataset. When you do this, what differs among the vertical CRSs? Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] fixed sensors, depth, datum
Dear all, A quite complicated topic!..Probably we may be able to provide you some feedback on such aspects here in the frame of Seadatanet project - they are in copy of this e-mail. One the main issue we have to raise in the coming months is the integration of in-situ netCDF datasets following CF conventions. Hope this will help.. Best wishes Olivier. -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Ethan Davis Envoyé : mardi 30 septembre 2008 06:44 À : Philip Bentley Cc : cf-metadata@cgd.ucar.edu Objet : Re: [CF-metadata] fixed sensors, depth, datum Hi Phil, Philip Bentley wrote: > Hi, > > Since I'm name-checked in this thread I thought I ought to chip in > with my 2 cents worth. > > FWIW, I'd make the following observations (some of which reiterate > other contributions): > > * I don't think that the 'grid_mapping' attribute (and its associated > variable) is the right place to encode this information. In the case > of in situ observations/measurements, for example, presumably it would > be quite normal to want to provide geoid and/or reference datum > metadata that has little or no relevance to grids or grid mappings > (i.e. in the map projection sense). > > * We could encode geoid metadata in an attribute called, say, > 'geoid_name' or 'geoid_id', at either the global or variable level. As > already discussed this would identify a well-known geoid, the details > of which would need to be determined from external sources. > > * We could encode vertical datum metadata in an attribute called, say, > 'vertical_datum_name' or 'vertical_datum_id', again at either the > global or variable level, the latter overriding the former. As before, > this attribute would identify a well-known datum, defined externally > to CF. > > * Where appropriate, we might consider encoding a local datum offset > to an agreed reference datum (the WGS 1984 datum perhaps?) in the same > way as is currently done for WGS 84-related lat-long coords. This we > could do using an attribute called, say, > 'vertical_offset_from_wgs1984_datum'. Of course, this would only make > sense in the simple case of a constant offset (I have no feeling for > how common or rare this scenario is - presumably the relationship > between different vertical datums is decidedly non-trivial). > > * If we don't like the idea of attaching the above attributes to > individual variables then we could collect them together in a > 'container' CRS attribute & variable as per the 'grid_mapping' > attribute & variable. This was my preferred approach when compiling my > original Trac ticket (#9). However, in order to reach agreement on the > core aspects of that ticket, it was decided to keep them within the > existing grid mapping container. I agree with all your above points. I prefer the idea in your last point of a new container variable for holding vertical CRS attributes. It should give us a bit more flexibility than one or more global or variable attributes would provide and it will better allow for any unforeseen complexity. I'm not sure about how to contain transformation/offset data or just a relationship between a vertical coordinate variable and a vertical auxiliary coordinate variable. Allowing some explicit connection between a vertical coordinate variable and an auxiliary coordinate variable seems related to your notion of trying to map to a standard vertical CRS like WGS84 geoid. > * If the 'grid_mapping' attribute is intended to encapsulate all > things CRS then we should consider renaming it (e.g. 'crs_definition'). If I'm understanding what you mean here, I would prefer to keep the current correspondence between grid mapping and horizontal CRS. So maybe horizontal_crs_definition? Keeping vertical CRS separate would allow for combining horizontal and vertical CRS in a single file in different ways to describe different 3-D CRS. [We deal with a lot of data that has all/most variables on a single horizontal CRS but different sets of variables are on different vertical CRS. So that use case is always front and center for me.] > * IMO, pulling together a coherent proposal covering the desired > facets of horizontal and vertical coordinate reference systems will > likely take a suitably-knowledgeable person 3 months work, possibly > more. Does anyone have that kind of time to spare? > > * As mentioned in a previous posting, I believe that these (and some > other key) updates might best be addressed by a small team of > technical experts producing a draft CF 2.0 specification. I'm not > convinced that the current Trac discussion mechanism wou
Re: [CF-metadata] fixed sensors, depth, datum
Hi Phil, Philip Bentley wrote: Hi, Since I'm name-checked in this thread I thought I ought to chip in with my 2 cents worth. FWIW, I'd make the following observations (some of which reiterate other contributions): * I don't think that the 'grid_mapping' attribute (and its associated variable) is the right place to encode this information. In the case of in situ observations/measurements, for example, presumably it would be quite normal to want to provide geoid and/or reference datum metadata that has little or no relevance to grids or grid mappings (i.e. in the map projection sense). * We could encode geoid metadata in an attribute called, say, 'geoid_name' or 'geoid_id', at either the global or variable level. As already discussed this would identify a well-known geoid, the details of which would need to be determined from external sources. * We could encode vertical datum metadata in an attribute called, say, 'vertical_datum_name' or 'vertical_datum_id', again at either the global or variable level, the latter overriding the former. As before, this attribute would identify a well-known datum, defined externally to CF. * Where appropriate, we might consider encoding a local datum offset to an agreed reference datum (the WGS 1984 datum perhaps?) in the same way as is currently done for WGS 84-related lat-long coords. This we could do using an attribute called, say, 'vertical_offset_from_wgs1984_datum'. Of course, this would only make sense in the simple case of a constant offset (I have no feeling for how common or rare this scenario is - presumably the relationship between different vertical datums is decidedly non-trivial). * If we don't like the idea of attaching the above attributes to individual variables then we could collect them together in a 'container' CRS attribute & variable as per the 'grid_mapping' attribute & variable. This was my preferred approach when compiling my original Trac ticket (#9). However, in order to reach agreement on the core aspects of that ticket, it was decided to keep them within the existing grid mapping container. I agree with all your above points. I prefer the idea in your last point of a new container variable for holding vertical CRS attributes. It should give us a bit more flexibility than one or more global or variable attributes would provide and it will better allow for any unforeseen complexity. I'm not sure about how to contain transformation/offset data or just a relationship between a vertical coordinate variable and a vertical auxiliary coordinate variable. Allowing some explicit connection between a vertical coordinate variable and an auxiliary coordinate variable seems related to your notion of trying to map to a standard vertical CRS like WGS84 geoid. * If the 'grid_mapping' attribute is intended to encapsulate all things CRS then we should consider renaming it (e.g. 'crs_definition'). If I'm understanding what you mean here, I would prefer to keep the current correspondence between grid mapping and horizontal CRS. So maybe horizontal_crs_definition? Keeping vertical CRS separate would allow for combining horizontal and vertical CRS in a single file in different ways to describe different 3-D CRS. [We deal with a lot of data that has all/most variables on a single horizontal CRS but different sets of variables are on different vertical CRS. So that use case is always front and center for me.] * IMO, pulling together a coherent proposal covering the desired facets of horizontal and vertical coordinate reference systems will likely take a suitably-knowledgeable person 3 months work, possibly more. Does anyone have that kind of time to spare? * As mentioned in a previous posting, I believe that these (and some other key) updates might best be addressed by a small team of technical experts producing a draft CF 2.0 specification. I'm not convinced that the current Trac discussion mechanism would work successfully for such a large proposal (the fragmentation of the 'common concept' proposal illustrates the problem here). * The suggestions above run counter to current 'CF philosophy' in that (i) CF/netCDF files would not necessarily be self-describing; (ii) we would be introducing changes to the CF conventions which anticipate future rather than immediate requirements. As a community are we willing to go down this route? I agree this is a big job and can't imagine any of us individually can spare all the time needed. However, I think the big challenge is to find a few people to champion the issue and keep it moving forward (even if slowly, hopefully not too slowly). If we don't have that, it won't matter how the discussion is conducted. So, in that spirit, I will commit to doing two things in the next two or three weeks: 1) summarizing the conversation we've had up to this point; and 2) writing a draft document that lists requirements and use cases from the conver
Re: [CF-metadata] fixed sensors, depth, datum
Hi Jonathan, all, Jonathan Gregory wrote: - Vertical coordinate values (heights, altitudes etc) are often inferred from other quantities (esp. pressure in both air and water). Since CF is expanding to include in situ data, can we express this somehow, so that users know that the coordinate value depends on certain assumptions? Yes, we could, but I would not make that distinction in the standard name, if the intention is just to supply some extra information about how the quantity was obtained. That does not make different kinds of quantity. On the other hand, if the quantities are regarded as distinct, so that you might have several of them in the same dataset, and wanted to compare them with the corresponding ones in another dataset, perhaps an argument could be made for distinguishing them by standard name. However, another attribute might still be a better way, I suspect. We would need some use-cases to discuss this when it arises. I'm not sure about completely capturing the assumptions or precise calculations/transformation of the relationship. But a vertical CRS description similar to current grid mappings seems a reasonable approach to capture this relationship. And in particular might be a good place to explicitly define the relationship between a coordinate variable and an auxiliary coordinate variable. Ethan -- Ethan R. DavisTelephone: (303) 497-8155 Software Engineer Fax: (303) 497-8690 UCAR Unidata Program Center E-mail:[EMAIL PROTECTED] P.O. Box 3000 Boulder, CO 80307-3000 http://www.unidata.ucar.edu/ --- ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] fixed sensors, depth, datum
Hi Jon, Jonathan, all, I definitely agree with Jon that this is a head-scratcher. I also finally understand what Jonathan means by distinct geophysical quantities in this case. And agree that height above a geoid and height above a reference ellipsoid are distinct geophysical quantities. (Sorry it took so long for me to understand.) It seems there are two important characteristics that need capturing: 1) the geophysical significance of a vertical CRS (height, altitude, pressure, sigma, etc), and 2) the details of a vertical CRS, possibly enough to enable intercomparison with data on a different vertical CRS. The first seems appropriate to capture in the standard name attribute as Jonathan has been suggesting. However, I am still a bit concerned about the proliferation of standard names. I'm not sure if tidal or station vertical datum should be marked as height_above_geoid and I don't know vertical datum well enough to know how many other types there are in common use. As the second could be fairly complicated, it seems best captured in a vertical crs variable (similar to a grid mapping variable). Which would also allow files to contain data on multiple vertical CRS (just as files can now contain multiple horizontal CRS/grid mappings). This also seems likely to allow CF to capture vertical datum transformation/offset information if desired. Then again, I'm not sure the relationship between vertical coordinate variables and auxiliary coordinate variables is as clean as it is with grid mappings. Ethan Jon Blower wrote: Dear Jonathan and Ethan (et al), Definitely a head-scratcher, this one. My own view (which may well change!) is as follows: - If we were concerned only with data expressed as discrete vertical profiles then I would tend to agree with Ethan (the distinction is just a vertical coordinate transformation). - However, given that we are primarily concerned with 3D fields I think that the quantities are distinct (agreeing with Jonathan). A x-y slice through the field has a specific geophysical meaning if the vertical coordinate is height_above_geoid, but it has no particular geophysical meaning if the vertical coordinate is height_above_ellipsoid. Two points to muddy the waters further: - Being pedantic, two points at the same height above the geoid might not have quite the same potential energy. The 3D geopotential contours are not everywhere equally-spaced. However, I imagine this is not usually a large effect, unless the data in question are close to a large gravity anomaly. - Vertical coordinate values (heights, altitudes etc) are often inferred from other quantities (esp. pressure in both air and water). Since CF is expanding to include in situ data, can we express this somehow, so that users know that the coordinate value depends on certain assumptions? Cheers, Jon On Mon, Sep 29, 2008 at 9:10 AM, Jonathan Gregory <[EMAIL PROTECTED]> wrote: Dear Ethan I agree that different definitions of the reference ellipsoid do not constitute different geophysical quantities. Likewise different definitions of the geoid all give the same geophysical quantity. Therefore I agree that the geoid should be identified as part of the CRS (naming it in the grid_mapping would be convenient), just as the ellipsoid is identified as part of the CRS (we added the parameters specifying the ellipsoid to the grid_mapping as part of Phil Bentley's change to the conventions). I agree too that the definition of the vertical CRS is relevant both to coordinate variables and data variables. That is another reason why it would make sense to put it in the grid_mapping. I do not agree that the geoid and the ellipsoid are geophysically equivalent. It is quite likely that you might want to have data variables in the same file for both height above geoid and height above ellipsoid, just as you might also want to have height above the surface and height above mean sea level. These are all heights wrt to surfaces which are defined as a function of lat and lon. All of these surfaces therefore depend on the horizontal CRS, as you say. But these surfaces are all geophysically distinct. The reference ellipsoid is "just" a matter of definition, but the others (geoid, surface = bottom of atmos and mean sea level) are not matters of definition: they are complicated facts about the real world that have to be measured. Wikipedia says "The geoid surface is irregular, unlike the reference ellipsoids often used to approximate the shape of the physical Earth, but considerably smoother than Earth's physical surface." These surfaces have different physical meanings. For instance, surfaces with constant height above the geoid (geopotential surfaces) are those on which there is zero gravitational/centrifugal force; this not true of other surfaces. Height above these various surfaces has different geophysical meaning. You would not want to replace height above geoid with height above ellipsoid by changing
Re: [CF-metadata] fixed sensors, depth, datum
Hi, Since I'm name-checked in this thread I thought I ought to chip in with my 2 cents worth. FWIW, I'd make the following observations (some of which reiterate other contributions): * I don't think that the 'grid_mapping' attribute (and its associated variable) is the right place to encode this information. In the case of in situ observations/measurements, for example, presumably it would be quite normal to want to provide geoid and/or reference datum metadata that has little or no relevance to grids or grid mappings (i.e. in the map projection sense). * We could encode geoid metadata in an attribute called, say, 'geoid_name' or 'geoid_id', at either the global or variable level. As already discussed this would identify a well-known geoid, the details of which would need to be determined from external sources. * We could encode vertical datum metadata in an attribute called, say, 'vertical_datum_name' or 'vertical_datum_id', again at either the global or variable level, the latter overriding the former. As before, this attribute would identify a well-known datum, defined externally to CF. * Where appropriate, we might consider encoding a local datum offset to an agreed reference datum (the WGS 1984 datum perhaps?) in the same way as is currently done for WGS 84-related lat-long coords. This we could do using an attribute called, say, 'vertical_offset_from_wgs1984_datum'. Of course, this would only make sense in the simple case of a constant offset (I have no feeling for how common or rare this scenario is - presumably the relationship between different vertical datums is decidedly non-trivial). * If we don't like the idea of attaching the above attributes to individual variables then we could collect them together in a 'container' CRS attribute & variable as per the 'grid_mapping' attribute & variable. This was my preferred approach when compiling my original Trac ticket (#9). However, in order to reach agreement on the core aspects of that ticket, it was decided to keep them within the existing grid mapping container. * If the 'grid_mapping' attribute is intended to encapsulate all things CRS then we should consider renaming it (e.g. 'crs_definition'). * IMO, pulling together a coherent proposal covering the desired facets of horizontal and vertical coordinate reference systems will likely take a suitably-knowledgeable person 3 months work, possibly more. Does anyone have that kind of time to spare? * As mentioned in a previous posting, I believe that these (and some other key) updates might best be addressed by a small team of technical experts producing a draft CF 2.0 specification. I'm not convinced that the current Trac discussion mechanism would work successfully for such a large proposal (the fragmentation of the 'common concept' proposal illustrates the problem here). * The suggestions above run counter to current 'CF philosophy' in that (i) CF/netCDF files would not necessarily be self-describing; (ii) we would be introducing changes to the CF conventions which anticipate future rather than immediate requirements. As a community are we willing to go down this route? Regards Phil On Mon, 2008-09-29 at 09:10 +0100, Jonathan Gregory wrote: > Dear Ethan > > I agree that different definitions of the reference ellipsoid do not > constitute > different geophysical quantities. Likewise different definitions of the geoid > all give the same geophysical quantity. Therefore I agree that the geoid > should > be identified as part of the CRS (naming it in the grid_mapping would be > convenient), just as the ellipsoid is identified as part of the CRS (we added > the parameters specifying the ellipsoid to the grid_mapping as part of Phil > Bentley's change to the conventions). I agree too that the definition of the > vertical CRS is relevant both to coordinate variables and data variables. That > is another reason why it would make sense to put it in the grid_mapping. > > > 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] fixed sensors, depth, datum
Dear Jonathan, >> Since CF is expanding to include in situ data, can we express this >> somehow, so that users know that the coordinate value depends on >> certain assumptions? > > Yes, we could, but I would not make that distinction in the standard name, I agree that this shouldn't be expressed in the standard name - I guess this was a little off-topic for this thread and probably merits a separate conversation. Cheers, Jon On Mon, Sep 29, 2008 at 11:33 AM, Jonathan Gregory <[EMAIL PROTECTED]> wrote: > Dear Jon > >> - Being pedantic, two points at the same height above the geoid might >> not have quite the same potential energy. The 3D geopotential >> contours are not everywhere equally-spaced. However, I imagine this >> is not usually a large effect, unless the data in question are close >> to a large gravity anomaly. > > If I understand you, then I agree. That is because geopotential is not the > same as gravitational potential, so height above a gravitational equipotential > surface is not the same as height above geoid. These again are two distinct > physical quantities. > >> - Vertical coordinate values (heights, altitudes etc) are often >> inferred from other quantities (esp. pressure in both air and water). >> Since CF is expanding to include in situ data, can we express this >> somehow, so that users know that the coordinate value depends on >> certain assumptions? > > Yes, we could, but I would not make that distinction in the standard name, if > the intention is just to supply some extra information about how the quantity > was obtained. That does not make different kinds of quantity. On the other > hand, if the quantities are regarded as distinct, so that you might have > several of them in the same dataset, and wanted to compare them with the > corresponding ones in another dataset, perhaps an argument could be made > for distinguishing them by standard name. However, another attribute might > still be a better way, I suspect. We would need some use-cases to discuss > this when it arises. > > Cheers > > Jonathan > ___ > 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 [EMAIL PROTECTED] 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] fixed sensors, depth, datum
Dear Jon > - Being pedantic, two points at the same height above the geoid might > not have quite the same potential energy. The 3D geopotential > contours are not everywhere equally-spaced. However, I imagine this > is not usually a large effect, unless the data in question are close > to a large gravity anomaly. If I understand you, then I agree. That is because geopotential is not the same as gravitational potential, so height above a gravitational equipotential surface is not the same as height above geoid. These again are two distinct physical quantities. > - Vertical coordinate values (heights, altitudes etc) are often > inferred from other quantities (esp. pressure in both air and water). > Since CF is expanding to include in situ data, can we express this > somehow, so that users know that the coordinate value depends on > certain assumptions? Yes, we could, but I would not make that distinction in the standard name, if the intention is just to supply some extra information about how the quantity was obtained. That does not make different kinds of quantity. On the other hand, if the quantities are regarded as distinct, so that you might have several of them in the same dataset, and wanted to compare them with the corresponding ones in another dataset, perhaps an argument could be made for distinguishing them by standard name. However, another attribute might still be a better way, I suspect. We would need some use-cases to discuss this when it arises. Cheers Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] fixed sensors, depth, datum
Dear Jonathan and Ethan (et al), Definitely a head-scratcher, this one. My own view (which may well change!) is as follows: - If we were concerned only with data expressed as discrete vertical profiles then I would tend to agree with Ethan (the distinction is just a vertical coordinate transformation). - However, given that we are primarily concerned with 3D fields I think that the quantities are distinct (agreeing with Jonathan). A x-y slice through the field has a specific geophysical meaning if the vertical coordinate is height_above_geoid, but it has no particular geophysical meaning if the vertical coordinate is height_above_ellipsoid. Two points to muddy the waters further: - Being pedantic, two points at the same height above the geoid might not have quite the same potential energy. The 3D geopotential contours are not everywhere equally-spaced. However, I imagine this is not usually a large effect, unless the data in question are close to a large gravity anomaly. - Vertical coordinate values (heights, altitudes etc) are often inferred from other quantities (esp. pressure in both air and water). Since CF is expanding to include in situ data, can we express this somehow, so that users know that the coordinate value depends on certain assumptions? Cheers, Jon On Mon, Sep 29, 2008 at 9:10 AM, Jonathan Gregory <[EMAIL PROTECTED]> wrote: > Dear Ethan > > I agree that different definitions of the reference ellipsoid do not > constitute > different geophysical quantities. Likewise different definitions of the geoid > all give the same geophysical quantity. Therefore I agree that the geoid > should > be identified as part of the CRS (naming it in the grid_mapping would be > convenient), just as the ellipsoid is identified as part of the CRS (we added > the parameters specifying the ellipsoid to the grid_mapping as part of Phil > Bentley's change to the conventions). I agree too that the definition of the > vertical CRS is relevant both to coordinate variables and data variables. That > is another reason why it would make sense to put it in the grid_mapping. > > I do not agree that the geoid and the ellipsoid are geophysically equivalent. > It is quite likely that you might want to have data variables in the same file > for both height above geoid and height above ellipsoid, just as you might also > want to have height above the surface and height above mean sea level. These > are all heights wrt to surfaces which are defined as a function of lat and > lon. > All of these surfaces therefore depend on the horizontal CRS, as you say. But > these surfaces are all geophysically distinct. The reference ellipsoid is > "just" a matter of definition, but the others (geoid, surface = bottom of > atmos > and mean sea level) are not matters of definition: they are complicated facts > about the real world that have to be measured. Wikipedia says > "The geoid surface is irregular, unlike the reference ellipsoids often used to > approximate the shape of the physical Earth, but considerably smoother than > Earth's physical surface." > > These surfaces have different physical meanings. For instance, surfaces with > constant height above the geoid (geopotential surfaces) are those on which > there is zero gravitational/centrifugal force; this not true of other > surfaces. > Height above these various surfaces has different geophysical meaning. You > would not want to replace height above geoid with height above ellipsoid by > changing the definition of the CRS. They should remain distinct quantities, > regardless of the definition of geoid and ellipsoid in the CRS. Hence I think > they need different standard names. > > Best wishes > > Jonathan > ___ > 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 [EMAIL PROTECTED] 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] fixed sensors, depth, datum
Dear Ethan I agree that different definitions of the reference ellipsoid do not constitute different geophysical quantities. Likewise different definitions of the geoid all give the same geophysical quantity. Therefore I agree that the geoid should be identified as part of the CRS (naming it in the grid_mapping would be convenient), just as the ellipsoid is identified as part of the CRS (we added the parameters specifying the ellipsoid to the grid_mapping as part of Phil Bentley's change to the conventions). I agree too that the definition of the vertical CRS is relevant both to coordinate variables and data variables. That is another reason why it would make sense to put it in the grid_mapping. I do not agree that the geoid and the ellipsoid are geophysically equivalent. It is quite likely that you might want to have data variables in the same file for both height above geoid and height above ellipsoid, just as you might also want to have height above the surface and height above mean sea level. These are all heights wrt to surfaces which are defined as a function of lat and lon. All of these surfaces therefore depend on the horizontal CRS, as you say. But these surfaces are all geophysically distinct. The reference ellipsoid is "just" a matter of definition, but the others (geoid, surface = bottom of atmos and mean sea level) are not matters of definition: they are complicated facts about the real world that have to be measured. Wikipedia says "The geoid surface is irregular, unlike the reference ellipsoids often used to approximate the shape of the physical Earth, but considerably smoother than Earth's physical surface." These surfaces have different physical meanings. For instance, surfaces with constant height above the geoid (geopotential surfaces) are those on which there is zero gravitational/centrifugal force; this not true of other surfaces. Height above these various surfaces has different geophysical meaning. You would not want to replace height above geoid with height above ellipsoid by changing the definition of the CRS. They should remain distinct quantities, regardless of the definition of geoid and ellipsoid in the CRS. Hence I think they need different standard names. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] fixed sensors, depth, datum
Hi Jonathan, Jonathan Gregory wrote: - height relative to the ellipsoid - height relative to the geoid I would argue against them being different quantities because there exist transformations between these various heights. Is that not enough to indicate they are the same quantity? I don't think so, because the transformations aren't a simple matter of convention, but involve geophysical data viz. the shape of geopotential surfaces. If you say that height relative to ellipsoid and geoid is the same quantity, aren't you saying that the geoid and ellipsoid are essentially the same thing? I don't think they are the same thing; they are by definition different from each other, and from other surfaces such as mean sea level and "the" surface (the bottom of the atmosphere). To me, they both indicate location in a vertical dimension. And just like latitude and longitude are dependent on the shape of the reference ellipsoid and the prime meridian, the vertical dimension depends on the vertical datum both to define the direction of vertical and the zero level in the vertical. So, just like lat and lon are the same quantity in different horizontal CRS it seems that height should be the same quantity even when in different vertical CRS. Which is why I think extending the horizontal CRS/grid mapping section to include vertical CRS is the way to go. And whether the values are in a coordinate variable or a data variable, they should reference a CRS. Ethan -- Ethan R. DavisTelephone: (303) 497-8155 Software Engineer Fax: (303) 497-8690 UCAR Unidata Program Center E-mail:[EMAIL PROTECTED] P.O. Box 3000 Boulder, CO 80307-3000 http://www.unidata.ucar.edu/ --- ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
[CF-metadata] fixed sensors, depth, datum
Dear Ethan > >>>- height relative to the ellipsoid > >>>- height relative to the geoid > I would argue against them being different quantities because there > exist transformations between these various heights. Is that not enough > to indicate they are the same quantity? I don't think so, because the transformations aren't a simple matter of convention, but involve geophysical data viz. the shape of geopotential surfaces. If you say that height relative to ellipsoid and geoid is the same quantity, aren't you saying that the geoid and ellipsoid are essentially the same thing? I don't think they are the same thing; they are by definition different from each other, and from other surfaces such as mean sea level and "the" surface (the bottom of the atmosphere). Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] fixed sensors, depth, datum
Hi Jonathan, I would argue against them being different quantities because there exist transformations between these various heights. Is that not enough to indicate they are the same quantity? Ethan Jonathan Gregory wrote: Dear Jon - height relative to the ellipsoid - height relative to the geoid From a coordinate referencing point of view they both give height (in units of length) above a reference surface, but the surfaces happen to be different. Do you consider them geophysically distinct because "height relative to geoid" is a close approximation to potential energy, whereas "height relative to ellipsoid" is not? Similarly, the geoid approximates sea level whereas the ellipsoid does not? Yes, I would say that distinctions like that make them different quantities. Plain "height" (above the surface) is likewise a different geophysical quantity. However, I think that specification of geoid or ellipsoid is not part of the identity of the geophysical quantity. It is more in the nature of an extra parameter for working out the numbers, like the reference pressure used for potential temperature. Of course, I realise this is somewhat arbitrary. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- Ethan R. DavisTelephone: (303) 497-8155 Software Engineer Fax: (303) 497-8690 UCAR Unidata Program Center E-mail:[EMAIL PROTECTED] P.O. Box 3000 Boulder, CO 80307-3000 http://www.unidata.ucar.edu/ --- ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
[CF-metadata] fixed sensors, depth, datum
Dear all Referring to Dale's list of requirements, this is my understanding of where we are: > - height relative to the ellipsoid > - height relative to the geoid Olivier pointed out we have already agreed to add height_above_reference_ellipsoid, and Dale reminded us that height relative to the geoid is "altitude". > - name of the ellipsoid > - name of the geoid These could be added as possible attributes to the grid_mapping variable. That is a conventions change that would need a trac ticket to propose and discuss. > - altitude of (offset to) other common datums (e.g. MLLW) Dale could propose new standard names such as altitude_of_mean_lower_low_water and altitude_of_mean_low_water. Cheers Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
[CF-metadata] fixed sensors, depth, datum
Dear Jon > > - height relative to the ellipsoid > > - height relative to the geoid > > From a coordinate referencing point of view they both > give height (in units of length) above a reference surface, but the > surfaces happen to be different. Do you consider them geophysically > distinct because "height relative to geoid" is a close approximation > to potential energy, whereas "height relative to ellipsoid" is not? > Similarly, the geoid approximates sea level whereas the ellipsoid does not? Yes, I would say that distinctions like that make them different quantities. Plain "height" (above the surface) is likewise a different geophysical quantity. However, I think that specification of geoid or ellipsoid is not part of the identity of the geophysical quantity. It is more in the nature of an extra parameter for working out the numbers, like the reference pressure used for potential temperature. Of course, I realise this is somewhat arbitrary. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] fixed sensors, depth, datum
Dear Jonathan et al, > - height relative to the ellipsoid > - height relative to the geoid > In my opinion these are distinct geophysical quantities. I don't quite understand why these quantities are distinct geophysically. From a coordinate referencing point of view they both give height (in units of length) above a reference surface, but the surfaces happen to be different. Do you consider them geophysically distinct because "height relative to geoid" is a close approximation to potential energy, whereas "height relative to ellipsoid" is not? Similarly, the geoid approximates sea level whereas the ellipsoid does not? Regards, Jon On Mon, Sep 15, 2008 at 6:32 PM, Jonathan Gregory <[EMAIL PROTECTED]> wrote: > Dear all > > Referring to Dale's list of requirements > > - height relative to the ellipsoid > - height relative to the geoid > In my opinion these are distinct geophysical quantities. As Dale pointed out, > we already have the standard name of "altitude" for the second of them, and > the first should probably have the name height_above_reference_ellipsoid for > consistency with other standard names. That would need to be proposed to this > email list. > > - name of the ellipsoid > - name of the geoid > These could be added as possible attributes to the grid_mapping variable. > That is a conventions change that would need a trac ticket to propose and > discuss. In fact Phil Bentley did propose to have such attributes in his > CRS ticket. We had discussions in which I expressed my usual disquiet about > redundancy. What if the name of the ellipsoid is not consistent with the > parameters of the ellipsoid that have been supplied, if they have been? I > am not sure how to resolve that. This concern does not apply to the geoid, > because it is not practical to specify it in detail as part of CF metadata; > we can only identify it by name. If the ellipsoid_name is a grid_mapping > attribute too, it simplifies Dale's example, as it doesn't have to appear > in its own dummy variable. > > - altitude of (offset to) other common datums (e.g. MLLW) > Dale's offsets are single numbers, but they could in some circumstances be > (lon,lat) fields, as Ethan says. In either case, they can be data variables, > so I see no problem that that. The other common datums are tidal datums, for > instance. Again, I think the various tidal levels are distinct geophysical > variables, and need different standard names to be proposed > e.g. altitude_of_mean_lower_low_water and altitude_of_mean_low_water. > > I think I don't properly understand how these concepts relate to concepts > like "Australian height datum", which Ethan mentions. What does that mean > exactly, can someone explain? I suspect it must mean the designation of a > particular geoid, and saying that a particular location has a certain altitude > wrt that geoid. By specifying a geoid, a location and an altitude you would > thereby define altitude for everywhere else in the world. Is that right? > > Best wishes > > Jonathan > ___ > 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 [EMAIL PROTECTED] 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] fixed sensors, depth, datum
Dear all, Note that 'height_above_reference_ellipsoid' has already been discussed and accepted a few months ago. So it is one (little) thing in less to be done for Dale! Olivier -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Jonathan Gregory Envoyé : lundi 15 septembre 2008 19:32 À : cf-metadata@cgd.ucar.edu Objet : [CF-metadata] fixed sensors, depth, datum Dear all Referring to Dale's list of requirements - height relative to the ellipsoid - height relative to the geoid In my opinion these are distinct geophysical quantities. As Dale pointed out, we already have the standard name of "altitude" for the second of them, and the first should probably have the name height_above_reference_ellipsoid for consistency with other standard names. That would need to be proposed to this email list. - name of the ellipsoid - name of the geoid These could be added as possible attributes to the grid_mapping variable. That is a conventions change that would need a trac ticket to propose and discuss. In fact Phil Bentley did propose to have such attributes in his CRS ticket. We had discussions in which I expressed my usual disquiet about redundancy. What if the name of the ellipsoid is not consistent with the parameters of the ellipsoid that have been supplied, if they have been? I am not sure how to resolve that. This concern does not apply to the geoid, because it is not practical to specify it in detail as part of CF metadata; we can only identify it by name. If the ellipsoid_name is a grid_mapping attribute too, it simplifies Dale's example, as it doesn't have to appear in its own dummy variable. - altitude of (offset to) other common datums (e.g. MLLW) Dale's offsets are single numbers, but they could in some circumstances be (lon,lat) fields, as Ethan says. In either case, they can be data variables, so I see no problem that that. The other common datums are tidal datums, for instance. Again, I think the various tidal levels are distinct geophysical variables, and need different standard names to be proposed e.g. altitude_of_mean_lower_low_water and altitude_of_mean_low_water. I think I don't properly understand how these concepts relate to concepts like "Australian height datum", which Ethan mentions. What does that mean exactly, can someone explain? I suspect it must mean the designation of a particular geoid, and saying that a particular location has a certain altitude wrt that geoid. By specifying a geoid, a location and an altitude you would thereby define altitude for everywhere else in the world. Is that right? Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata Cliquez sur l'url suivante https://www.mailcontrol.com/sr/VxKchdZbMKvTndxI!oX7UvGHrMX8oTLhQL5XW7KT3CL7NjueKPhZM6zw6AwbJ1okw2YSczghXVhPbv5+FCDqIw== si ce message est indésirable (pourriel). ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] fixed sensors, depth, datum
Hi Steve, Sounds good. I will work on that. For those interested and going to the GO-ESSP meeting, maybe we can carve out a few minutes during a break or something to talk in person about this. I'd like to be able to say I'll have the summary Steve mentions done before GO-ESSP but I'm not sure I'll have the time. Ethan Steve Hankin wrote: Hi Ethan, Given the depth of this discussion, I imagine that only a small handful of individuals followed it in detail. In order to capture what was learned in a form that can readily be evaluated, would you consider writing it up as a trac ticket? - Steve == Ethan Davis wrote: Hi Dale, Dale Robinson wrote: I guess we are getting to the core of this discussion, at least in terms of whether or not my further involvement is needed. Yes indeed. Good discussion The question for me is, does or will the CF convention allow some method to include offsets between tidal datums, or allow some other means for a user to convert among z referenced to different datums? Your answer below suggests that the CF convention is not the place for this information... that the information is out there and it is up to the user to find it. Please let me know if I've got that right. Sorry that detail of your question slipped under my radar and I was focused on how to identify a vertical datum. It is an interesting question since the grid mapping part of CF was originally designed to describe a mapping/transformation between two sets of coordinates. The existing grid mappings generally have a half dozen or so parameters and a name to identify the set of formulas in which to use those parameters to perform the transformation. In your case, it sounds like the vertical datum grid mapping variable would contain an offset for each point where you have data. You wouldn't even need to name the transformation (though you probably would want to name the two vertical CRS if known), you would just need to indicate how the offset is applied. Which leads me to think that CF very well may be the place for data on offsets between vertical datums. What do others think about a grid mapping variable being an actual array of data as opposed to simply a container for attributes? Ethan PS Just a thought about grid mappings. Both EPSG and ISO 19111 keep CRS and transformations between CRS as separate entities. Grid mappings kind of do double duty as they can now either: 1) define both a transformation and the two CRS at the endpoints of the transformation, or 2) just define a single CRS. Of course, I can't think of many advantages to separating things into components and the disadvantage is separation of related information. Cheers. -Dale - 3) “The fact the Dale wants to distinguish the various tidal datums shows that they define distinct quantities.” When I think about it, yes they seem to be distinct quantities. The range of mean lower low water and mean higher high water varies from location to location. A user of the data may not know what the offsets among datums are in a particular area. Heights referenced to these datums (especially MLLW) are very important to local users of the data. As a user of the CF convention and netCDF, I want to make sure that the people using my data can convert the height values we give them into values most useful to them. So inclusion of an offset variable, especially one so intuitively named (altitude_of_mean_low_water) would help me and many of the users of my data immensely. Even if the user doesn't know the offsets between two tidal datums, they do exist. To me, that doesn't seem like enough of a difference to consider them distinct quantities. Ethan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- Ethan R. DavisTelephone: (303) 497-8155 Software Engineer Fax: (303) 497-8690 UCAR Unidata Program Center E-mail:[EMAIL PROTECTED] P.O. Box 3000 Boulder, CO 80307-3000 http://www.unidata.ucar.edu/ --- ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] fixed sensors, depth, datum
Hi Jon, all, Jon Blower wrote: This is an interesting discussion. I haven't had much time to input any brainpower into this, but I just wanted to suggest that whoever eventually takes charge of this issue should probably consult the GeoTools guys, who have done a lot of work in this area. They probably can't help with what is and isn't in scope for CF, but they would certainly be able to share their thinking on vertical CRSs in general. Good idea. It would certainly be worth while to pass whatever we come up with past some folks more expert in CRS and geodesy. Just a quick thought about grid mappings. In the horizontal plane we have the lat-lon system, which often acts as a "reference" CRS that everyone can understand (e.g. curvilinear coordinate systems are usually mapped to lat-lon). Hence provided that we can convert an arbitrary CRS to and from lat-lon, then we can convert any horizontal CRS to any other. It's not obvious to me that we have an equivalent for the vertical CRS, particularly considering that vertical CRSs can be defined using a number of physical quantities (length, pressure, density, even sometimes temperature). Hence converting one vertical CRS to another might be hard in the general case. Not to mention that transformations between different vertical CRS may depend on X and Y because the reference surfaces may not be tangential in all locations. Ethan Cheers, Jon On Fri, Sep 12, 2008 at 11:16 PM, Ethan Davis <[EMAIL PROTECTED]> wrote: Hi Dale, Dale Robinson wrote: I guess we are getting to the core of this discussion, at least in terms of whether or not my further involvement is needed. Yes indeed. Good discussion The question for me is, does or will the CF convention allow some method to include offsets between tidal datums, or allow some other means for a user to convert among z referenced to different datums? Your answer below suggests that the CF convention is not the place for this information... that the information is out there and it is up to the user to find it. Please let me know if I've got that right. Sorry that detail of your question slipped under my radar and I was focused on how to identify a vertical datum. It is an interesting question since the grid mapping part of CF was originally designed to describe a mapping/transformation between two sets of coordinates. The existing grid mappings generally have a half dozen or so parameters and a name to identify the set of formulas in which to use those parameters to perform the transformation. In your case, it sounds like the vertical datum grid mapping variable would contain an offset for each point where you have data. You wouldn't even need to name the transformation (though you probably would want to name the two vertical CRS if known), you would just need to indicate how the offset is applied. Which leads me to think that CF very well may be the place for data on offsets between vertical datums. What do others think about a grid mapping variable being an actual array of data as opposed to simply a container for attributes? Ethan PS Just a thought about grid mappings. Both EPSG and ISO 19111 keep CRS and transformations between CRS as separate entities. Grid mappings kind of do double duty as they can now either: 1) define both a transformation and the two CRS at the endpoints of the transformation, or 2) just define a single CRS. Of course, I can't think of many advantages to separating things into components and the disadvantage is separation of related information. Cheers. -Dale - 3) "The fact the Dale wants to distinguish the various tidal datums shows that they define distinct quantities." When I think about it, yes they seem to be distinct quantities. The range of mean lower low water and mean higher high water varies from location to location. A user of the data may not know what the offsets among datums are in a particular area. Heights referenced to these datums (especially MLLW) are very important to local users of the data. As a user of the CF convention and netCDF, I want to make sure that the people using my data can convert the height values we give them into values most useful to them. So inclusion of an offset variable, especially one so intuitively named (altitude_of_mean_low_water) would help me and many of the users of my data immensely. Even if the user doesn't know the offsets between two tidal datums, they do exist. To me, that doesn't seem like enough of a difference to consider them distinct quantities. Ethan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- Ethan R. DavisTelephone: (303) 497-8155 Software Engineer Fax: (303) 497-8690 UCAR Unidata Program Center E-mail:[E
[CF-metadata] fixed sensors, depth, datum
Dear all Referring to Dale's list of requirements - height relative to the ellipsoid - height relative to the geoid In my opinion these are distinct geophysical quantities. As Dale pointed out, we already have the standard name of "altitude" for the second of them, and the first should probably have the name height_above_reference_ellipsoid for consistency with other standard names. That would need to be proposed to this email list. - name of the ellipsoid - name of the geoid These could be added as possible attributes to the grid_mapping variable. That is a conventions change that would need a trac ticket to propose and discuss. In fact Phil Bentley did propose to have such attributes in his CRS ticket. We had discussions in which I expressed my usual disquiet about redundancy. What if the name of the ellipsoid is not consistent with the parameters of the ellipsoid that have been supplied, if they have been? I am not sure how to resolve that. This concern does not apply to the geoid, because it is not practical to specify it in detail as part of CF metadata; we can only identify it by name. If the ellipsoid_name is a grid_mapping attribute too, it simplifies Dale's example, as it doesn't have to appear in its own dummy variable. - altitude of (offset to) other common datums (e.g. MLLW) Dale's offsets are single numbers, but they could in some circumstances be (lon,lat) fields, as Ethan says. In either case, they can be data variables, so I see no problem that that. The other common datums are tidal datums, for instance. Again, I think the various tidal levels are distinct geophysical variables, and need different standard names to be proposed e.g. altitude_of_mean_lower_low_water and altitude_of_mean_low_water. I think I don't properly understand how these concepts relate to concepts like "Australian height datum", which Ethan mentions. What does that mean exactly, can someone explain? I suspect it must mean the designation of a particular geoid, and saying that a particular location has a certain altitude wrt that geoid. By specifying a geoid, a location and an altitude you would thereby define altitude for everywhere else in the world. Is that right? Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] fixed sensors, depth, datum
https://bugzilla.novell.com/show_bug.cgi?id=414146 User [EMAIL PROTECTED] added comment https://bugzilla.novell.com/show_bug.cgi?id=414146#c5 --- Comment #5 from Hin-Tak Leung <[EMAIL PROTECTED]> 2008-09-08 17:19:29 MDT --- problem of 2.0 preview 2 still with 2.0 rc1. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. You are the assignee for the bug. ___ mono-bugs maillist - mono-bugs@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-bugs
Re: [CF-metadata] fixed sensors, depth, datum
Josh, When Webrick gets over a certain threshold, it just falls over. Mongrel degrades more gracefully and can recover. Depending on how complicated your configurations are and how long they compile, you might need to run more than one instance of mongrel. Regards, Andrew On Fri, Sep 12, 2008 at 11:09 AM, josh <[EMAIL PROTECTED]> wrote: > > Andrew, > I am using Webrick ,and yes, the process becomes unresponsive. > I ran puppetmasterd in --no-daemonize mode, and nothing useful, after > a certain amount of time just no more log data was being generated. > It's almost like it's not reading my puppet.conf (Do I need to call it > puppetmasterd.conf? From what I understand it shouldn't matter) > > And yes, I'm reading on page 142 of the "Advanced Puppet" book that > WEBrick can't scale well. (Thanks James for the book - I just got it > yesterday and it's quite helpful). Time to crank open mongrel and sanother might be hard in the general case. Cheers, Jon On Fri, Sep 12, 2008 at 11:16 PM, Ethan Davis <[EMAIL PROTECTED]> wrote: > Hi Dale, > > Dale Robinson wrote: >> >> I guess we are getting to the core of this discussion, at least in terms >> of whether or not my further involvement is needed. > > Yes indeed. Good discussion > >> The question for me is, does or will the CF convention allow some method >> to include offsets between tidal datums, or allow some other means for a >> user to convert among z referenced to different datums? >> Your answer below suggests that the CF convention is not the place for >> this information... that the information is out there and it is up to the >> user to find it. >> Please let me know if I've got that right. > > Sorry that detail of your question slipped under my radar and I was focused > on how to identify a vertical datum. It is an interesting question since the > grid mapping part of CF was originally designed to describe a > mapping/transformation between two sets of coordinates. The existing grid > mappings generally have a half dozen or so parameters and a name to identify > the set of formulas in which to use those parameters to perform the > transformation. In your case, it sounds like the vertical datum grid mapping > variable would contain an offset for each point where you have data. You > wouldn't even need to name the transformation (though you probably would > want to name the two vertical CRS if known), you would just need to indicate > how the offset is applied. > > Which leads me to think that CF very well may be the place for data on > offsets between vertical datums. What do others think about a grid mapping > variable being an actual array of data as opposed to simply a container for > attributes? > > Ethan > > PS Just a thought about grid mappings. Both EPSG and ISO 19111 keep CRS and > transformations between CRS as separate entities. Grid mappings kind of do > double duty as they can now either: > > 1) define both a transformation and the two CRS at the endpoints of the > transformation, or > 2) just define a single CRS. > > Of course, I can't think of many advantages to separating things into > components and the disadvantage is separation of related information. > >> Cheers. >> >> -Dale >> >> - >>> >>> 3) "The fact the Dale wants to distinguish the various tidal datums shows >>> that they define distinct quantities." >>> >>> When I think about it, yes they seem to be distinct quantities. The range >>> of mean lower low water and mean higher high water varies from location to >>> location. A user of the data may not know what the offsets among datums are >>> in a particular area. Heights referenced to these datums (especially MLLW) >>> are very important to local users of the data. As a user of the CF >>> convention and netCDF, I want to make sure that the people using my data can >>> convert the height values we give them into values most useful to them. So >>> inclusion of an offset variable, especially one so intuitively named >>> (altitude_of_mean_low_water) would help me and many of the users of my data >>> immensely. >> >> Even if the user doesn't know the offsets between two tidal datums, they >> do exist. To me, that doesn't seem like enough of a difference to consider >> them distinct quantities. >> >> Ethan >> >> >> ___ >> CF-metadata mailing list >> CF-metadata@cgd.ucar.edu >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > -- > Ethan R. DavisTelephone: (303) 497-8155 > Software Engineer Fax: (303) 497-8690 > UCAR Unidata Program Center E-mail:[EMAIL PROTECTED] > P.O. Box 3000 > Boulder, CO 80307-3000 http://www.unidata.ucar.edu/ > --- > > ___ > CF-metadata mailing list > CF-metadata@cgd.ucar.edu > http://mailman.cgd.ucar.e
Re: [CF-metadata] fixed sensors, depth, datum
Hi Dale, Dale Robinson wrote: I guess we are getting to the core of this discussion, at least in terms of whether or not my further involvement is needed. Yes indeed. Good discussion The question for me is, does or will the CF convention allow some method to include offsets between tidal datums, or allow some other means for a user to convert among z referenced to different datums? Your answer below suggests that the CF convention is not the place for this information... that the information is out there and it is up to the user to find it. Please let me know if I've got that right. Sorry that detail of your question slipped under my radar and I was focused on how to identify a vertical datum. It is an interesting question since the grid mapping part of CF was originally designed to describe a mapping/transformation between two sets of coordinates. The existing grid mappings generally have a half dozen or so parameters and a name to identify the set of formulas in which to use those parameters to perform the transformation. In your case, it sounds like the vertical datum grid mapping variable would contain an offset for each point where you have data. You wouldn't even need to name the transformation (though you probably would want to name the two vertical CRS if known), you would just need to indicate how the offset is applied. Which leads me to think that CF very well may be the place for data on offsets between vertical datums. What do others think about a grid mapping variable being an actual array of data as opposed to simply a container for attributes? Ethan PS Just a thought about grid mappings. Both EPSG and ISO 19111 keep CRS and transformations between CRS as separate entities. Grid mappings kind of do double duty as they can now either: 1) define both a transformation and the two CRS at the endpoints of the transformation, or 2) just define a single CRS. Of course, I can't think of many advantages to separating things into components and the disadvantage is separation of related information. Cheers. -Dale - 3) “The fact the Dale wants to distinguish the various tidal datums shows that they define distinct quantities.” When I think about it, yes they seem to be distinct quantities. The range of mean lower low water and mean higher high water varies from location to location. A user of the data may not know what the offsets among datums are in a particular area. Heights referenced to these datums (especially MLLW) are very important to local users of the data. As a user of the CF convention and netCDF, I want to make sure that the people using my data can convert the height values we give them into values most useful to them. So inclusion of an offset variable, especially one so intuitively named (altitude_of_mean_low_water) would help me and many of the users of my data immensely. Even if the user doesn't know the offsets between two tidal datums, they do exist. To me, that doesn't seem like enough of a difference to consider them distinct quantities. Ethan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- Ethan R. DavisTelephone: (303) 497-8155 Software Engineer Fax: (303) 497-8690 UCAR Unidata Program Center E-mail:[EMAIL PROTECTED] P.O. Box 3000 Boulder, CO 80307-3000 http://www.unidata.ucar.edu/ --- ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf- <!-- google_ad_client = "pub-7266757337600734"; google_alternate_ad_url = "http://www.mail-archive.com/blank.png"; google_ad_width = 160; google_ad_height = 600; google_ad_format = "160x600_as"; google_ad_channel = "8427791634"; google_color_border = "FF"; google_color_bg = "FF"; google_color_link = "006792"; google_color_url = "006792"; google_color_text = "000000"; //--> [CF-metadata] fixed sensors, depth, datum Jonathan Gregory Re: [CF-metadata] fixed sensors, depth, datum Jon Blower Re: [CF-metadata] fixed sensors, depth, datum Dale Robinson [CF-metadata] fixed sensors, depth, datum Jonathan Gregory Re: [CF-metadata] fixed sensors, depth, datum Jon Blower [CF-metadata] fixed sensors, depth, datum Jonathan Gregory [CF-metadata] fixed sensors, depth, datum Jonathan Gregory Re: [CF-metadata] fixed sensors, depth, datum Dale Robinson Re: [CF-metadata] fixed sensors, depth, datum Ethan Davis Re: [CF-metadata] fixed sensors, depth, datum Dale Robinson Re: [CF-metadata] fixed sensors, depth, datum Ethan
Re: [CF-metadata] fixed sensors, depth, datum
--~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Democrats4Change" group. To post to this group, send email to democrats4change@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/democrats4change?hl=en -~--~~~~--~~--~--~--- --- Begin Message --- Google Web Alert for: After all the mismanagement/corruption/and shame this administration has brought us. I'm thinking like our neighboring countries, how can America be so dumb!? How-To Guide For a Clinton Comeback - The Fix Feb 13, 2008 ... Our country is screwed up, so I'm voting for experience this fall. . Some ofit is merited, though, I think. Like it or not, HRC has ... This once a day Google Alert is brought to you by Google. Remove this alert. Create another alert. Manage your alerts. --- End Message ---
Re: [CF-metadata] fixed sensors, depth, datum
Hi all, Dale Robinson wrote: Thank you Johnathan et al. for your great comments and suggestions. I like Johnathan’s suggestions very much. They seem straightforward, especially for people who are not experts in vertical datums or in the logic of the CF convention. I will address Johnathan’s points one at a time below. I certainly am not knowledgeable in the correct usages of CF stn. names and attributes and I don’t want to sidetrack the discussion by suggesting inappropriate usages. Therefore, I will restrict my comments to my role as a user of the CF convention and a data provider. 1) Johnathan: “I think that height above geoid (altitude) and height above reference ellipsoid are different geophysical quantities and do need different standard names” Yes, I agree. Looking at the std. names table I see the following “height” terms: I disagree on this. Both are distances above a reference surface that is used as the zero level. A vertical datum is a reference from which to measure height and/or depth. Vertical datums can be based on ellipsoids, tidal measurements (e.g., EPSG datum 5111, "Australian Height Datum", description: "MSL 1966-68 at 30 gauges around coast."), a set of station locations (e.g., EGSG datum 5102, "National Geodetic Vertical Datum 1929", description: "26 tide gauges in the US and Canada."), or a geoid (e.g., WGS 84 EGM96 geoid, which EPSG calls datum 5203). Two good links on Wikipedia: http://en.wikipedia.org/wiki/Geodetic_system http://en.wikipedia.org/wiki/Datum_(geodesy) And then there's the WGS84 report, linked from http://earth-info.nga.mil/GandG/wgs84/gravitymod/index.html a. geopotential_height Geopotential is the sum of the specific gravitational potential energy relative to the geoid and the specific centripetal potential energy. Geopotential height is the geopotential divided by the standard acceleration due to gravity. It is numerically similar to the altitude (or geometric height) and not to the quantity with standard name height, which is relative to the surface. I do agree this is a different geophysical quantity. But there still should be a way to define the particular geoid from which potential energy is being measured. b. height Height is the vertical distance above the surface. c. altitude Altitude is the (geometric) height above the geoid, which is the reference geopotential surface. The geoid is similar to mean sea level. Unless I am missing something, what seems to be missing here is a term for Geodetic or Ellipsoidal height. *d. ellipsoidal_height * Height of a point above the reference ellipsoid Speaking as a user of CF, the lack of this term seems to be a gap in the standard names that should be filled. The inclusion of this term was deemed important when describing sea surface height; both sea_surface_height_above_geoid and sea_surface_height_above_reference_ellipsoid standard names are included in CF. Therefore, I suggest including a term like height_above_reference_ellipsoid or ellipsoidal_height. 2) Johnathan: “If you have a *data* variable with the standard name of altitude, for instance, you might want to identify the geoid… What if we allowed the grid_mapping_name to be optional if the grid mapping was included only in order to describe the geoid or reference ellipsoid?” Yes. I don’t know about the method (grid_mapping_name), but it does seem that if you define something as ‘height above the geoid’ or ‘height above the reference ellipsoid’, a user would want to know which geoid or reference ellipsoid. I agree that data variables as well as vertical coordinate variales should be able to reference/define a vertical datum. Expanding the grid mapping section to deal with vertical datum seems like a good option. However, I think we are going to want to name vertical datum as well. Perhaps we should expand the "Horizontal CRS, Grid Mappings, and Projections" section to deal with vertical CRS as well by adding a vertical_datum_name attribute similar to the grid_mapping_name attribute. This gets complicated by the fact that grid_mapping can define 2-D or 3-D CRS and you might want to combine the same 2-D horiz CRS with multiple 1-D vertical CRS. 3) “The fact the Dale wants to distinguish the various tidal datums shows that they define distinct quantities.” When I think about it, yes they seem to be distinct quantities. The range of mean lower low water and mean higher high water varies from location to location. A user of the data may not know what the offsets among datums are in a particular area. Heights referenced to these datums (especially MLLW) are very important to local users of the data. As a user of the CF convention and netCDF, I want to make sure that the people using my data can convert the height values we give them into values most useful to them. So inclusion of an offset variable, especially one so intuitively named (altitude_of_mean_low_water) would hel
Re: [CF-metadata] fixed sensors, depth, datum
Thank you Johnathan et al. for your great comments and suggestions. I like Johnathan’s suggestions very much. They seem straightforward, especially for people who are not experts in vertical datums or in the logic of the CF convention. I will address Johnathan’s points one at a time below. I certainly am not knowledgeable in the correct usages of CF stn. names and attributes and I don’t want to sidetrack the discussion by suggesting inappropriate usages. Therefore, I will restrict my comments to my role as a user of the CF convention and a data provider. 1) Johnathan: “I think that height above geoid (altitude) and height above reference ellipsoid are different geophysical quantities and do need different standard names” Yes, I agree. Looking at the std. names table I see the following “height” terms: a. geopotential_height Geopotential is the sum of the specific gravitational potential energy relative to the geoid and the specific centripetal potential energy. Geopotential height is the geopotential divided by the standard acceleration due to gravity. It is numerically similar to the altitude (or geometric height) and not to the quantity with standard name height, which is relative to the surface. b. height Height is the vertical distance above the surface. c. altitude Altitude is the (geometric) height above the geoid, which is the reference geopotential surface. The geoid is similar to mean sea level. Unless I am missing something, what seems to be missing here is a term for Geodetic or Ellipsoidal height. *d. ellipsoidal_height * Height of a point above the reference ellipsoid Speaking as a user of CF, the lack of this term seems to be a gap in the standard names that should be filled. The inclusion of this term was deemed important when describing sea surface height; both sea_surface_height_above_geoid and sea_surface_height_above_reference_ellipsoid standard names are included in CF. Therefore, I suggest including a term like height_above_reference_ellipsoid or ellipsoidal_height. 2) Johnathan: “If you have a *data* variable with the standard name of altitude, for instance, you might want to identify the geoid… What if we allowed the grid_mapping_name to be optional if the grid mapping was included only in order to describe the geoid or reference ellipsoid?” Yes. I don’t know about the method (grid_mapping_name), but it does seem that if you define something as ‘height above the geoid’ or ‘height above the reference ellipsoid’, a user would want to know which geoid or reference ellipsoid. 3) “The fact the Dale wants to distinguish the various tidal datums shows that they define distinct quantities.” When I think about it, yes they seem to be distinct quantities. The range of mean lower low water and mean higher high water varies from location to location. A user of the data may not know what the offsets among datums are in a particular area. Heights referenced to these datums (especially MLLW) are very important to local users of the data. As a user of the CF convention and netCDF, I want to make sure that the people using my data can convert the height values we give them into values most useful to them. So inclusion of an offset variable, especially one so intuitively named (altitude_of_mean_low_water) would help me and many of the users of my data immensely. In summary, a set of std. names and attributes that allows the following would help me as a user of CF and the users of my data: - height relative to the ellipsoid - name of the ellipsoid - height relative to the geoid - name of the geoid - altitude of (offset to) other common datums (e.g. MLLW) I don’t know how to correctly format the following within the CF convention, but I’ll take a chance below based on Johnathan’s suggestions. No doubt it is incorrectly formulated, but I think you will see what I am getting at. float ellips_height; ellips_height:standard_name="ellipsoidal_height” // i.e. height_above_reference_ellipsoid ellips_height:grid_mapping="ellipsoid"; float altitude; // data variable altitude:standard_name="altitude"; altitude:grid_mapping="geoid"; float alt_mllw; // offset variable alt_mllw:standard_name="altitude_of_mean_lower_low_water "; char geoid; // grid mapping variable geoid:geoid_name="geoid03"; char ellipsoid; // grid mapping variable ellipsoid: ellipsoid_name="WGS84"; Thanks. -Dale Dear Dale et al. You're quite right, altitude is height above geoid. Hence the names for the tidal datums should be altitude_of_DATUM, which is neater. We should spell them out, I think e.g. altitude_of_mean_low_water, as we generally avoid abbreviations in standard names for the sake of intelligibility by people who aren't experts in the relevant area. The way you propose to use attribute ancillary_variables isn't quite what it was intended for, I think. Do you envisage there could be several data variables in the file giving alternative values for
[CF-metadata] fixed sensors, depth, datum
Dear Dale et al. You're quite right, altitude is height above geoid. Hence the names for the tidal datums should be altitude_of_DATUM, which is neater. We should spell them out, I think e.g. altitude_of_mean_low_water, as we generally avoid abbreviations in standard names for the sake of intelligibility by people who aren't experts in the relevant area. The way you propose to use attribute ancillary_variables isn't quite what it was intended for, I think. Do you envisage there could be several data variables in the file giving alternative values for a particular offset? If so, I can appreciate there may be a need for a link. But if there is only one, is a link required? You could find the variable you want by examining the standard names. While I think that it's better not to have different standard names for altitude wrt different geoids as I would consider them to be varying definitions of the same geophysical quantity, I think that height above geoid (altitude) and height above reference ellipsoid are different geophysical quantities and do need different standard names. Hence I would not be in favour of a generic "height above vertical datum". I don't think that is sufficiently well-defined to have a standard name. I also think that "height above reference ellipsoid" is a different quantity from "height above mean low water" etc. The fact the Dale wants to distinguish the various tidal datums shows that they define distinct quantities. Ethan argues for putting the definition of vertical coordinate system with vertical coordinate variables, not in the grid mapping, which is so far for horizontal coordinate systems. I would note that * we have already defined the ellipsoid in the grid mapping. To define it separately somewhere else, even if only by name, could be confusing or inconsistent. * it's not needed only for vertical coordinate variables. If you have a *data* variable with the standard name of altitude, for instance, you might want to identify the geoid. However I do feel that it's a bit cumbersome to introduce a grid_mapping variable with a "dummy" horizontal coordinate system just to name the geoid. What if we allowed the grid_mapping_name to be optional if the grid mapping was included only in order to describe the geoid or reference ellipsoid? float altitude; // data variable altitude:standard_name="altitude"; altitude:grid_mapping="geoid"; char geoid; // grid mapping variable geoid:geoid_name="WGS84"; Cheers Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] fixed sensors, depth, datum
Dear All, Just to throw into the pot that there are datums important to sea level data that are neither geoids nor ellipsoids such as Ordnance Datum Newlyn or Normaal Amsterdams Peil that are carefully levelled chunks of metal set into something solid. Cheers, Roy. >>> Dale Robinson <[EMAIL PROTECTED]> 09/11/08 6:27 PM >>> -- 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] fixed sensors, depth, datum
Dear Johnathan, I agree with you. I don't like the idea of renaming same geophysical quantities that differ in value only by an offset. BTW: looking at the CF standard name table, it appears that 'height_above_geoid' is the definition of 'altitude'. altitude= Altitude is the (geometric) height above the geoid, which is the reference geopotential surface. The geoid is similar to mean sea level. Your suggestion of creating standard names and offset variables is more what I had in mind. E.g. height_above_geoid_of_mllw. I think that the connection between this offset and the geoid based z variable (e.g. altitude) could be made stronger by using the ancillary_variables attribute. e.g. ht_offset_mllw ht_offset_mllw:long_name = "Offset between the geoid and MLLW"; ht_offset_mllw:standard_name = "height_above_geoid_of_mllw" ht_offset_mllw:ancillary_variables = "altitude" and/or altitude altitude:long_name = "altitude"; altitude:standard_name = "altitude" altitude:ancillary_variables = "height_above_geoid_of_mllw" I would prefer it if something were added to the convention that allows identification of the geoid or ellipsoid. Using grid_mapping seems unduly complicated. Thanks. -Dale Jonathan Gregory wrote: Dear Dale It seems none of us who has so far contributed claims to be an expert. If any experts are listening in, they are welcome to comment! The recommendation is that I request a few new standard names. Standard names like height_above_geoid and height_above_reference_ellipsoid seem appropriate Yes. Can one use in any variable an attribute normally found in the crs variable such as vertical_datum_name? For example float ht_wgs84 ht_wgs84:long_name = "Height referenced to WGS84"; ht_wgs84:standard_name = height_above_reference_ellipsoid ht_wgs84:vertical_datum_name = "World Geodetic System 1984" vertical_datum_name is not a CF attribute. CF doesn't preclude other attributes being included, so that's fine, but software implementing CF would not use the attribute. In my earlier posting, I suggested that we could define the geoid by extending the grid_mapping variable (CF 5.6). There is currently not a standard CF way to name the geoid or ellipsoid, but the ellipsoid can be defined geometrically by the grid_mapping variable. Any solution to this would need an addition to the CF standard. One option is to propose more specific standard names as suggested by Jon. E.g. height_above_wgs84 and height_above_navd88. Do you think that this is a viable direction? I don't like that so much myself, because I feel that heights above various geoids are the same geophysical quantity, so they should not have different standard names. It seems better to me to add something to the convention, especially as this has been raised before but not solved. In your example it appeared that you wanted to record the offsets between the geoid and the various tidal datums. My suggestion for that is to put them in separate data variables and give them standard names (to be proposed) of the form height_above_geoid_of_TIDAL_DATUM. Finally, how do I go about suggesting new standard names? By proposing them to this email list, with canonical units and brief description. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- Dale Robinson, Ocean Observing Programs Coordinator Romberg Tiburon Center 3152 Paradise Drive Tiburon, CA 94920 email [EMAIL PROTECTED] http://sfbeams.sfsu.edu -- Dale Robinson, Ocean Observing Programs Coordinator Romberg Tiburon Center 3152 Paradise Drive Tiburon, CA 94920 email [EMAIL PROTECTED] http://sfbeams.sfsu.edu ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] fixed sensors, depth, datum
Thanks John. Nice to hear from you. So, this is the point where the discussion goes above my head. The points I think I grasped follow: 1. There should be a single more general standard name for the z coodinate variable. e.g. standard_name = "height_above_vertical_datum" 2. The vertical datum type or instance would be reference via an attribute of the above variable. 3. CF should not get into providing information like offsets to MLLW or tide datum epoch. Rather, that information should be provide via an external reference (a link or something). Did I get that right? -Dale John Graybeal wrote: I agree that CF has enough things on its plate, and adding the ability to internally define vertical datum specifications should not be yet another one. And so it is important to provide the means to reference existing vertical datums. I think a single height_above_vertical_datum as a standard name is more coherent (cogent?) than creating multiple 'height_above_' parameters, whether they're referring to a vertical datum type (geoid, ellipsoid) or instance (WGS_84). The height_above_vertical_datum concept lends itself to two cases: (1) A vertical datum for the entire file; (2) different vertical datums for different variables. I suppose the case of a vertical datum for each measurement is fairly degenerate...). Having both cases supported by attributes would be idea, it seems to me. The vertical datum reference could be specified in several forms: (a) a single URI for the vertical datum (or coordinate system incorporating a vertical datum), (b) organization name + vertical datum name or ID (note standard vocabularies often aren't defined for the organization name, so if you want computers to understand, these two terms would both need controlled vocabularies or some other unique referencing specification, like URIs or other unique IDs), (c) an internal reference to a CF-specified datum in the file, as for example the extended grid concept mentioned earlier. (The last is only needed to support existing CF specifications that are relevant, if any; otherwise no need to worry about it.) I suspect (a), the best choice IMHO, will be implementable within a year if not months, but maybe is not usable today. Conceivably attributes for both (a) and (b) could be created, and the user selects whichever is most appropriate. John On Sep 11, 2008, at 10:31 AM, Ethan Davis wrote: Hi all, Jonathan Gregory wrote: Dear Dale It seems none of us who has so far contributed claims to be an expert. If any experts are listening in, they are welcome to comment! Yes, please. The recommendation is that I request a few new standard names. Standard names like height_above_geoid and height_above_reference_ellipsoid seem appropriate Yes. As I understand it, a vertical datum can be based on sea levels, ellipsoids, or gravitational models. I think it would be better to add height_above_vertical_datum rather than the two more specific terms above. Can one use in any variable an attribute normally found in the crs variable such as vertical_datum_name? For example float ht_wgs84 ht_wgs84:long_name = "Height referenced to WGS84"; ht_wgs84:standard_name = height_above_reference_ellipsoid ht_wgs84:vertical_datum_name = "World Geodetic System 1984" vertical_datum_name is not a CF attribute. CF doesn't preclude other attributes being included, so that's fine, but software implementing CF would not use the attribute. In my earlier posting, I suggested that we could define the geoid by extending the grid_mapping variable (CF 5.6). There is currently not a standard CF way to name the geoid or ellipsoid, but the ellipsoid can be defined geometrically by the grid_mapping variable. Any solution to this would need an addition to the CF standard. Up to this point, grid mappings have only dealt with horizontal coordinates. I think the vertical datum information would fit better as attributes on vertical coordinates. That way it is closer to the actual coordinate variable and doesn't require a redirection to the grid mapping variable. This seems to more closely follow the lead of other CRS models (ISO and OGC, including Well-Known-Text) in keeping the vertical and horizontal coordinates separate. Combining a 2-D horizontal coordinate system and a 1-D vertical coordinate system to build a 3-D CRS. [With, as discussed earlier on this list I believe, an exception for the case where the 3-D CRS is fully based on an ellipsoid model of the earth. And for that we would need some way for the vertical coordinate to reference a grid mapping variable as the place the vertical datum is defined.] Dale you also asked: In addition, there are locally derived datums that I assume are derived by observation over a specific period of time (e.g. tide datum epoch from1983-2001). Once again one can propose specific standard names, e.g. heigh
Re: [CF-metadata] fixed sensors, depth, datum
I agree that CF has enough things on its plate, and adding the ability to internally define vertical datum specifications should not be yet another one. And so it is important to provide the means to reference existing vertical datums. I think a single height_above_vertical_datum as a standard name is more coherent (cogent?) than creating multiple 'height_above_' parameters, whether they're referring to a vertical datum type (geoid, ellipsoid) or instance (WGS_84). The height_above_vertical_datum concept lends itself to two cases: (1) A vertical datum for the entire file; (2) different vertical datums for different variables. I suppose the case of a vertical datum for each measurement is fairly degenerate...). Having both cases supported by attributes would be idea, it seems to me. The vertical datum reference could be specified in several forms: (a) a single URI for the vertical datum (or coordinate system incorporating a vertical datum), (b) organization name + vertical datum name or ID (note standard vocabularies often aren't defined for the organization name, so if you want computers to understand, these two terms would both need controlled vocabularies or some other unique referencing specification, like URIs or other unique IDs), (c) an internal reference to a CF-specified datum in the file, as for example the extended grid concept mentioned earlier. (The last is only needed to support existing CF specifications that are relevant, if any; otherwise no need to worry about it.) I suspect (a), the best choice IMHO, will be implementable within a year if not months, but maybe is not usable today. Conceivably attributes for both (a) and (b) could be created, and the user selects whichever is most appropriate. John On Sep 11, 2008, at 10:31 AM, Ethan Davis wrote: Hi all, Jonathan Gregory wrote: Dear Dale It seems none of us who has so far contributed claims to be an expert. If any experts are listening in, they are welcome to comment! Yes, please. The recommendation is that I request a few new standard names. Standard names like height_above_geoid and height_above_reference_ellipsoid seem appropriate Yes. As I understand it, a vertical datum can be based on sea levels, ellipsoids, or gravitational models. I think it would be better to add height_above_vertical_datum rather than the two more specific terms above. Can one use in any variable an attribute normally found in the crs variable such as vertical_datum_name? For example float ht_wgs84 ht_wgs84:long_name = "Height referenced to WGS84"; ht_wgs84:standard_name = height_above_reference_ellipsoid ht_wgs84:vertical_datum_name = "World Geodetic System 1984" vertical_datum_name is not a CF attribute. CF doesn't preclude other attributes being included, so that's fine, but software implementing CF would not use the attribute. In my earlier posting, I suggested that we could define the geoid by extending the grid_mapping variable (CF 5.6). There is currently not a standard CF way to name the geoid or ellipsoid, but the ellipsoid can be defined geometrically by the grid_mapping variable. Any solution to this would need an addition to the CF standard. Up to this point, grid mappings have only dealt with horizontal coordinates. I think the vertical datum information would fit better as attributes on vertical coordinates. That way it is closer to the actual coordinate variable and doesn't require a redirection to the grid mapping variable. This seems to more closely follow the lead of other CRS models (ISO and OGC, including Well-Known-Text) in keeping the vertical and horizontal coordinates separate. Combining a 2-D horizontal coordinate system and a 1-D vertical coordinate system to build a 3-D CRS. [With, as discussed earlier on this list I believe, an exception for the case where the 3-D CRS is fully based on an ellipsoid model of the earth. And for that we would need some way for the vertical coordinate to reference a grid mapping variable as the place the vertical datum is defined.] Dale you also asked: In addition, there are locally derived datums that I assume are derived by observation over a specific period of time (e.g. tide datum epoch from1983-2001). Once again one can propose specific standard names, e.g. height_above_mllw. If there is no attribute like vertical_datum_epoch, then the epoch info could go in the comments attribute, but that does not seem satisfying. I would rather see the definition and description of the vertical datum kept somewhere external to the data file and probably external to CF. With CF providing a place to reference the keeper of the vertical datum definition and an ID for the referenced vertical datum (maybe vertical_datum_authority and vertical_datum_name, or _id). Are there cases when a vertical datum is well defined but not used
Re: [CF-metadata] fixed sensors, depth, datum
Dear Johnathan, I agree with you. I don't like the idea of renaming same geophysical quantities that differ in value only by an offset. BTW: looking at the CF standard name table, it appears that 'height_above_geoid' is the definition of 'altitude'. altitude= Altitude is the (geometric) height above the geoid, which is the reference geopotential surface. The geoid is similar to mean sea level. Your suggestion of creating standard names and offset variables is more what I had in mind. E.g. height_above_geoid_of_mllw. I think that the connection between this offset and the geoid based z variable (e.g. altitude) could be made stronger by using the ancillary_variables attribute. e.g. ht_offset_mllw ht_offset_mllw:long_name = "Offset between the geoid and MLLW"; ht_offset_mllw:standard_name = "height_above_geoid_of_mllw" ht_offset_mllw:ancillary_variables = "altitude" and/or altitude altitude:long_name = "altitude"; altitude:standard_name = "altitude" altitude:ancillary_variables = "height_above_geoid_of_mllw" I would prefer it if something were added to the convention that allows identification of the geoid or ellipsoid. Using grid_mapping seems unduly complicated. Thanks. -Dale Jonathan Gregory wrote: Dear Dale It seems none of us who has so far contributed claims to be an expert. If any experts are listening in, they are welcome to comment! The recommendation is that I request a few new standard names. Standard names like height_above_geoid and height_above_reference_ellipsoid seem appropriate Yes. Can one use in any variable an attribute normally found in the crs variable such as vertical_datum_name? For example float ht_wgs84 ht_wgs84:long_name = "Height referenced to WGS84"; ht_wgs84:standard_name = height_above_reference_ellipsoid ht_wgs84:vertical_datum_name = "World Geodetic System 1984" vertical_datum_name is not a CF attribute. CF doesn't preclude other attributes being included, so that's fine, but software implementing CF would not use the attribute. In my earlier posting, I suggested that we could define the geoid by extending the grid_mapping variable (CF 5.6). There is currently not a standard CF way to name the geoid or ellipsoid, but the ellipsoid can be defined geometrically by the grid_mapping variable. Any solution to this would need an addition to the CF standard. One option is to propose more specific standard names as suggested by Jon. E.g. height_above_wgs84 and height_above_navd88. Do you think that this is a viable direction? I don't like that so much myself, because I feel that heights above various geoids are the same geophysical quantity, so they should not have different standard names. It seems better to me to add something to the convention, especially as this has been raised before but not solved. In your example it appeared that you wanted to record the offsets between the geoid and the various tidal datums. My suggestion for that is to put them in separate data variables and give them standard names (to be proposed) of the form height_above_geoid_of_TIDAL_DATUM. Finally, how do I go about suggesting new standard names? By proposing them to this email list, with canonical units and brief description. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- Dale Robinson, Ocean Observing Programs Coordinator Romberg Tiburon Center 3152 Paradise Drive Tiburon, CA 94920 email [EMAIL PROTECTED] http://sfbeams.sfsu.edu ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] fixed sensors, depth, datum
Thank you all for your help. Sorry to have taken so long to reply. I am no expert on vertical datums so it is talking me some time to digest this. One requirement of our project is to provide the information so that a user can convert between heights referenced to the different datums. In practice, these are offsets (conversions require adding or subtracting a constant), but the best way solution within CF is to put the converted values into variables. As I understand it from your comments, the standards names for height above or depth below a specific datum/geoid/ellipsoid do not exist. The recommendation is that I request a few new standard names. Standard names like height_above_geoid and height_above_reference_ellipsoid seem appropriate since they are analogous to the accepted standard names 'sea_surface_height_above_reference_ellipsoid' and sea_surface_height_above_geoid. Can one use in any variable an attribute normally found in the crs variable such as vertical_datum_name? For example float ht_wgs84 ht_wgs84:long_name = "Height referenced to WGS84"; ht_wgs84:standard_name = height_above_reference_ellipsoid ht_wgs84:vertical_datum_name = “World Geodetic System 1984” If not, there seems to be no easy way to include specifics about the datums. So if I need to specify a gravity-based geodetic datum such as NAVD88 or an ellipsoid-based datum such as WGS84, then height_above_geoid and height_above_reference_ellipsoid would not work well. One option is to propose more specific standard names as suggested by Jon. E.g. height_above_wgs84 and height_above_navd88. Do you think that this is a viable direction? In addition, there are locally derived datums that I assume are derived by observation over a specific period of time (e.g. tide datum epoch from1983-2001). Once again one can propose specific standard names, e.g. height_above_mllw. If there is no attribute like vertical_datum_epoch, then the epoch info could go in the comments attribute, but that does not seem satisfying. In summary, I have a few options to consider: 1. For NAVD88 and WG84, propose more general st. names if I can use attributes like vertical_datum_name. 2. Propose more specific st. names, e.g height_above_mllw and height_above_wgs84 with details in the comment attribute. If one includes all of the local datums (MLLW, MLW, LMSL, MTL, DTL, MHW, MHHW) I would welcome input on the best way to go forward. Please let me know if I have miss represented something. Finally, how do I go about suggesting new standard names? Thanks. -Dale - Jon Blower wrote: Hi Jonathan, Just to chip in - WGS84 is an ellipsoidal approximation to the geoid, so I don't think "depth_below_geoid" etc would be right. I would prefer "depth_below_ellipsoid" where the ellipsoid is defined somewhere, or perhaps even "depth_below_wgs84" considering that WGS84 is an extremely commonly-used ellipsoid. Regards, Jon On Wed, Sep 10, 2008 at 1:18 PM, Jonathan Gregory <[EMAIL PROTECTED]> wrote: Dear Dale + Create a z dimension with a value of 1 + The vertical coordinate variable 'z' (i.e. z(z) ) will be used to fix the location of the sensor in vertical space (i.e. not the distance below the water's surface) referenced to a datum. + For the datum we use WGS84. By "WGS84" I presume you mean their geoid (I am not an expert in vertical datums). If so, as Olivier says, you could request a new standard name of depth_below_geoid or height_above_geoid. As an alternative to a dimension of size 1, you can use a scalar coordinate variable (CF 5.7). + The depth variable (pressure sensor) gives depth in vertical distance below surface (which varies with the tide for fixed instruments). The standard name of "depth", which you have used, means depth below the (sea) surface, which I think is what you want. Since it is not a coordinate variable, it doesn't need a positive attribute. If I understand correctly, the offsets are giving the height_above_geoid of various tidal datums. I suggest that a more CF-like way to do this would be to provide these offsets as data variables, each with its own standard name; the standard names would be e.g. height_above_geoid_of_mean_lower_low_water. You could request such standard names. If they are all standard tidal datums, that might be unproblematic! The tidal datum epoch would then naturally be given as the bounds of the time coordinate variable for these various datums. The instrument goes up and down with the tide and the sensors are at a fixed distance below the surface. The vertical values are all distance below the surface. How do we handle that? One solution is to keep the vertical dimension of unity and have a vertical coordinate variable referenced t
Re: [CF-metadata] fixed sensors, depth, datum
Hi all, Jonathan Gregory wrote: Dear Dale It seems none of us who has so far contributed claims to be an expert. If any experts are listening in, they are welcome to comment! Yes, please. The recommendation is that I request a few new standard names. Standard names like height_above_geoid and height_above_reference_ellipsoid seem appropriate Yes. As I understand it, a vertical datum can be based on sea levels, ellipsoids, or gravitational models. I think it would be better to add height_above_vertical_datum rather than the two more specific terms above. Can one use in any variable an attribute normally found in the crs variable such as vertical_datum_name? For example float ht_wgs84 ht_wgs84:long_name = "Height referenced to WGS84"; ht_wgs84:standard_name = height_above_reference_ellipsoid ht_wgs84:vertical_datum_name = "World Geodetic System 1984" vertical_datum_name is not a CF attribute. CF doesn't preclude other attributes being included, so that's fine, but software implementing CF would not use the attribute. In my earlier posting, I suggested that we could define the geoid by extending the grid_mapping variable (CF 5.6). There is currently not a standard CF way to name the geoid or ellipsoid, but the ellipsoid can be defined geometrically by the grid_mapping variable. Any solution to this would need an addition to the CF standard. Up to this point, grid mappings have only dealt with horizontal coordinates. I think the vertical datum information would fit better as attributes on vertical coordinates. That way it is closer to the actual coordinate variable and doesn't require a redirection to the grid mapping variable. This seems to more closely follow the lead of other CRS models (ISO and OGC, including Well-Known-Text) in keeping the vertical and horizontal coordinates separate. Combining a 2-D horizontal coordinate system and a 1-D vertical coordinate system to build a 3-D CRS. [With, as discussed earlier on this list I believe, an exception for the case where the 3-D CRS is fully based on an ellipsoid model of the earth. And for that we would need some way for the vertical coordinate to reference a grid mapping variable as the place the vertical datum is defined.] Dale you also asked: In addition, there are locally derived datums that I assume are derived by observation over a specific period of time (e.g. tide datum epoch from1983-2001). Once again one can propose specific standard names, e.g. height_above_mllw. If there is no attribute like vertical_datum_epoch, then the epoch info could go in the comments attribute, but that does not seem satisfying. I would rather see the definition and description of the vertical datum kept somewhere external to the data file and probably external to CF. With CF providing a place to reference the keeper of the vertical datum definition and an ID for the referenced vertical datum (maybe vertical_datum_authority and vertical_datum_name, or _id). Are there cases when a vertical datum is well defined but not used repeatedly so not worth standardizing? If so, then maybe CF should make it possible to capture that information. Thanks, Ethan -- Ethan R. DavisTelephone: (303) 497-8155 Software Engineer Fax: (303) 497-8690 UCAR Unidata Program Center E-mail:[EMAIL PROTECTED] P.O. Box 3000 Boulder, CO 80307-3000 http://www.unidata.ucar.edu/ --- ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] fixed sensors, depth, datum
Dear Dale It seems none of us who has so far contributed claims to be an expert. If any experts are listening in, they are welcome to comment! >The recommendation is that I request a few new standard names. >Standard names like height_above_geoid and >height_above_reference_ellipsoid seem appropriate Yes. >Can one use in any variable an >attribute normally found in the crs variable such as >vertical_datum_name? For example >float ht_wgs84 >ht_wgs84:long_name = "Height referenced to WGS84"; >ht_wgs84:standard_name = height_above_reference_ellipsoid >ht_wgs84:vertical_datum_name = "World Geodetic System 1984" vertical_datum_name is not a CF attribute. CF doesn't preclude other attributes being included, so that's fine, but software implementing CF would not use the attribute. In my earlier posting, I suggested that we could define the geoid by extending the grid_mapping variable (CF 5.6). There is currently not a standard CF way to name the geoid or ellipsoid, but the ellipsoid can be defined geometrically by the grid_mapping variable. Any solution to this would need an addition to the CF standard. >One option is to propose more specific standard names as suggested by >Jon. E.g. height_above_wgs84 and height_above_navd88. Do you think >that this is a viable direction? I don't like that so much myself, because I feel that heights above various geoids are the same geophysical quantity, so they should not have different standard names. It seems better to me to add something to the convention, especially as this has been raised before but not solved. In your example it appeared that you wanted to record the offsets between the geoid and the various tidal datums. My suggestion for that is to put them in separate data variables and give them standard names (to be proposed) of the form height_above_geoid_of_TIDAL_DATUM. >Finally, how do I go about suggesting new standard names? By proposing them to this email list, with canonical units and brief description. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] fixed sensors, depth, datum
Thank you all for your help. Sorry to have taken so long to reply. I am no expert on vertical datums so it is talking me some time to digest this. One requirement of our project is to provide the information so that a user can convert between heights referenced to the different datums. In practice, these are offsets (conversions require adding or subtracting a constant), but the best way solution within CF is to put the converted values into variables. As I understand it from your comments, the standards names for height above or depth below a specific datum/geoid/ellipsoid do not exist. The recommendation is that I request a few new standard names. Standard names like height_above_geoid and height_above_reference_ellipsoid seem appropriate since they are analogous to the accepted standard names 'sea_surface_height_above_reference_ellipsoid' and sea_surface_height_above_geoid. Can one use in any variable an attribute normally found in the crs variable such as vertical_datum_name? For example float ht_wgs84 ht_wgs84:long_name = "Height referenced to WGS84"; ht_wgs84:standard_name = height_above_reference_ellipsoid ht_wgs84:vertical_datum_name = “World Geodetic System 1984” If not, there seems to be no easy way to include specifics about the datums. So if I need to specify a gravity-based geodetic datum such as NAVD88 or an ellipsoid-based datum such as WGS84, then height_above_geoid and height_above_reference_ellipsoid would not work well. One option is to propose more specific standard names as suggested by Jon. E.g. height_above_wgs84 and height_above_navd88. Do you think that this is a viable direction? In addition, there are locally derived datums that I assume are derived by observation over a specific period of time (e.g. tide datum epoch from1983-2001). Once again one can propose specific standard names, e.g. height_above_mllw. If there is no attribute like vertical_datum_epoch, then the epoch info could go in the comments attribute, but that does not seem satisfying. In summary, I have a few options to consider: 1. For NAVD88 and WG84, propose more general st. names if I can use attributes like vertical_datum_name. 2. Propose more specific st. names, e.g height_above_mllw and height_above_wgs84 with details in the comment attribute. If one includes all of the local datums (MLLW, MLW, LMSL, MTL, DTL, MHW, MHHW) I would welcome input on the best way to go forward. Please let me know if I have miss represented something. Finally, how do I go about suggesting new standard names? Thanks. -Dale - Jon Blower wrote: Hi Jonathan, Just to chip in - WGS84 is an ellipsoidal approximation to the geoid, so I don't think "depth_below_geoid" etc would be right. I would prefer "depth_below_ellipsoid" where the ellipsoid is defined somewhere, or perhaps even "depth_below_wgs84" considering that WGS84 is an extremely commonly-used ellipsoid. Regards, Jon On Wed, Sep 10, 2008 at 1:18 PM, Jonathan Gregory <[EMAIL PROTECTED]> wrote: Dear Dale + Create a z dimension with a value of 1 + The vertical coordinate variable 'z' (i.e. z(z) ) will be used to fix the location of the sensor in vertical space (i.e. not the distance below the water's surface) referenced to a datum. + For the datum we use WGS84. By "WGS84" I presume you mean their geoid (I am not an expert in vertical datums). If so, as Olivier says, you could request a new standard name of depth_below_geoid or height_above_geoid. As an alternative to a dimension of size 1, you can use a scalar coordinate variable (CF 5.7). + The depth variable (pressure sensor) gives depth in vertical distance below surface (which varies with the tide for fixed instruments). The standard name of "depth", which you have used, means depth below the (sea) surface, which I think is what you want. Since it is not a coordinate variable, it doesn't need a positive attribute. If I understand correctly, the offsets are giving the height_above_geoid of various tidal datums. I suggest that a more CF-like way to do this would be to provide these offsets as data variables, each with its own standard name; the standard names would be e.g. height_above_geoid_of_mean_lower_low_water. You could request such standard names. If they are all standard tidal datums, that might be unproblematic! The tidal datum epoch would then naturally be given as the bounds of the time coordinate variable for these various datums. The instrument goes up and down with the tide and the sensors are at a fixed distance below the surface. The vertical values are all distance below the surface. How do we handle that? One solution is to keep the vertical dimension of unity and have a vertical coordinate variable referenced
[CF-metadata] fixed sensors, depth, datum
Dear Jon Good - I'm glad we agree about WGS84. At the moment there isn't a way in CF to identify the geoid. It would be too complicated to describe it as part of the metadata, I think, but it could be named. A possible way to do this would be as an attribute in the grid_mapping variable, I suppose. If there is no grid_mapping variable because the grid is lat-lon and the ellipsoid doesn't need to specified, a grid_mapping variable could still be included with grid_mapping_name="latitude_longitude". Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] fixed sensors, depth, datum
Dear Jonathan, Sorry, it looks like I've misunderstood the meaning of "WGS84". Previously I have only ever seen the term "WGS84" as meaning a reference ellipsoid, but it looks like the WGS84 is really a geoid, which is based upon that reference ellipsoid. So you are quite right. So in Dale's case, "depth_below_geoid" would seem appropriate. Is there a way of saying which geoid is meant? Regards, Jon On Wed, Sep 10, 2008 at 3:37 PM, Jonathan Gregory <[EMAIL PROTECTED]> wrote: > Dear Jon > > As I've said, I'm pretty ignorant on this, but I had thought on reading e.g. > wikipedia that WGS84 must include a more detailed geoid as well as a reference > ellipsoid. Is it not the case these two can different by large amounts locally > owing to the bumps in the gravity field? If so, I would have thought that > measurements like these might relate to the geoid (which is much more like > sea level) than the ellipsoid. What have I misunderstood? > > Best wishes > > Jonathan > ___ > 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 [EMAIL PROTECTED] 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] fixed sensors, depth, datum
Dear Jon As I've said, I'm pretty ignorant on this, but I had thought on reading e.g. wikipedia that WGS84 must include a more detailed geoid as well as a reference ellipsoid. Is it not the case these two can different by large amounts locally owing to the bumps in the gravity field? If so, I would have thought that measurements like these might relate to the geoid (which is much more like sea level) than the ellipsoid. What have I misunderstood? Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] fixed sensors, depth, datum
Hi Jonathan, Just to chip in - WGS84 is an ellipsoidal approximation to the geoid, so I don't think "depth_below_geoid" etc would be right. I would prefer "depth_below_ellipsoid" where the ellipsoid is defined somewhere, or perhaps even "depth_below_wgs84" considering that WGS84 is an extremely commonly-used ellipsoid. Regards, Jon On Wed, Sep 10, 2008 at 1:18 PM, Jonathan Gregory <[EMAIL PROTECTED]> wrote: > Dear Dale > >> + Create a z dimension with a value of 1 >> + The vertical coordinate variable 'z' (i.e. z(z) ) will be >> used to fix the location of the sensor in vertical space >> (i.e. not the distance below the water's surface) referenced >> to a datum. >> + For the datum we use WGS84. > > By "WGS84" I presume you mean their geoid (I am not an expert in vertical > datums). If so, as Olivier says, you could request a new standard name of > depth_below_geoid or height_above_geoid. As an alternative to a dimension of > size 1, you can use a scalar coordinate variable (CF 5.7). > >> + The depth variable (pressure sensor) gives depth in vertical >> distance below surface (which varies with the tide for fixed >> instruments). > > The standard name of "depth", which you have used, means depth below the > (sea) surface, which I think is what you want. Since it is not a coordinate > variable, it doesn't need a positive attribute. > > If I understand correctly, the offsets are giving the height_above_geoid of > various tidal datums. I suggest that a more CF-like way to do this would be to > provide these offsets as data variables, each with its own standard name; the > standard names would be e.g. height_above_geoid_of_mean_lower_low_water. You > could request such standard names. If they are all standard tidal datums, that > might be unproblematic! The tidal datum epoch would then naturally be given as > the bounds of the time coordinate variable for these various datums. > >>The instrument goes up and down with the tide and the >>sensors are at a fixed distance below the surface. The vertical >>values are all distance below the surface. How do we handle that? >>One solution is to keep the vertical dimension of unity and have a >>vertical coordinate variable referenced to depth below the surface. > > Yes, I think that is the right solution. > > Cheers > > Jonathan > ___ > 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 [EMAIL PROTECTED] 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] fixed sensors, depth, datum
Dear Dale > + Create a z dimension with a value of 1 > + The vertical coordinate variable 'z' (i.e. z(z) ) will be > used to fix the location of the sensor in vertical space > (i.e. not the distance below the water's surface) referenced > to a datum. > + For the datum we use WGS84. By "WGS84" I presume you mean their geoid (I am not an expert in vertical datums). If so, as Olivier says, you could request a new standard name of depth_below_geoid or height_above_geoid. As an alternative to a dimension of size 1, you can use a scalar coordinate variable (CF 5.7). > + The depth variable (pressure sensor) gives depth in vertical > distance below surface (which varies with the tide for fixed > instruments). The standard name of "depth", which you have used, means depth below the (sea) surface, which I think is what you want. Since it is not a coordinate variable, it doesn't need a positive attribute. If I understand correctly, the offsets are giving the height_above_geoid of various tidal datums. I suggest that a more CF-like way to do this would be to provide these offsets as data variables, each with its own standard name; the standard names would be e.g. height_above_geoid_of_mean_lower_low_water. You could request such standard names. If they are all standard tidal datums, that might be unproblematic! The tidal datum epoch would then naturally be given as the bounds of the time coordinate variable for these various datums. >The instrument goes up and down with the tide and the >sensors are at a fixed distance below the surface. The vertical >values are all distance below the surface. How do we handle that? >One solution is to keep the vertical dimension of unity and have a >vertical coordinate variable referenced to depth below the surface. Yes, I think that is the right solution. Cheers Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] fixed sensors, depth, datum
Dear Dale, I am quite ignorant about datum and reference systems, but the only things I know that may help you are the following: - There was a discussion about CF grid mapping attributes here: http://cf-pcmdi.llnl.gov/trac/ticket/9 , it deals about the way you can describe coordinate reference system in CF. Probably some interesting stuff for your work. - There is no standard_name attribute such as "height referenced to WGS84", you may pick one in the standard name table (http://cf-pcmdi.llnl.gov/documents/cf-standard-names/9/cf-standard-name-table.html) or propose to add a new one. In this table if you search for "height" you'll get several answers; then to me the idea would be to combine a standard_name attribute (like, let's say, "sea_surface_height_above_reference_ellipsoid") with some CRS attributes that would describe which datum is used. - Or another lead I would try is to use XML for describing and transforming the data, and combine it with netCDF files for storage, aggregation and maps. I know there are initiatives such as Sensor Web Enablement, Sensor ML, GML and Web Processing Services (WPS) from OGC. Your situation is exactly the kind of use case such projects are made for, except that from OGC point of view data is encoded in XML (GML) files, not in netCDF. But I guess there should be a way to combine them in an efficient way??.. Hope this helps! Olivier Lauret. Olivier Lauret CLS - Space Oceanography Division Products Dissemination Dpt 8-10 rue Hermes, 31520 Ramonville St.Agne France Tel. (+33) (0) 561 39 48 51 Fax:(+33) (0) 561 39 47 80 http://www.cls.fr <http://www.cls.fr/> http://www.aviso.oceanobs.com/ <http://www.aviso.oceanobs.com/> De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Dale Robinson Envoyé : mardi 2 septembre 2008 21:41 À : CF-metadata@cgd.ucar.edu Objet : [CF-metadata] fixed sensors, depth, datum Good afternoon, The CeNCOOS Bays group is developing a netCDF standard for our water monitoring instruments. We've receive some fantastic help from John Graybeal and the folks at MMI. We are to a point where we have a couple of questions that are stumping us. I was hoping the CF group could help. I am a neophyte when it come to netCDF so please forgive my naive approach. The our group (CeNCOOS Bays) has two types of platforms for their water monitoring sensors: a floating platform (following the surface with the sensors a fixed distance below the surface) and fixed platform (fixed to a pier). Each platform type measures depth of sensors below the surface using pressure. However, for the fixed sensors, we want to locate the height of the sensor (z axis) in "real" space, i.e. in relation to some vertical datum, which would allow user to generate derive parameters such as tidal height. We also want to provide the information to allow users to convert to other tide datums. The solution we are working on for fixed instrument is outlined below, based on an example found in the SEACOOS NetCDF Standard, v2.0: For an instrument in a fixed position, for example fixed to a pier, then the z variable takes the form of a coordinate variable [i.e. z(z)] with a constant value that is referenced to a datum. * Create a z dimension with a value of 1 * The vertical coordinate variable 'z' (i.e. z(z) ) will be used to fix the location of the sensor in vertical space (i.e. not the distance below the water's surface) referenced to a datum. * For the datum we use WGS84. * the z data value, e.g. z= -34.8194 m, is the vertical location of the sensor in WGS84. * The depth variable (pressure sensor) gives depth in vertical distance below surface (which varies with the tide for fixed instruments). * Associated with most measured variables (e.g. depth, water temperature, salinity...) is the attribute z and its value (e.g. depth: z = "-34.8194" ; ), which is a reference to the Z coordinate axis and value in m that locates the sensor relative to the datum. This information also is provided to allow the derivation of parameters such as water level from the depth parameter. * The definition of the Z coordinate axis has the attribute reference value set to the tidal datum WGS84. * We also provide the statistically determined local offsets to other tide datums, a local bench mark, and the averaging period and tidal epoch. We use the attribute reference_to_'datum' to provide the offsets. The reference_to_datum attributes each give the value of a common vertical pos
[CF-metadata] fixed sensors, depth, datum
Good afternoon, The CeNCOOS Bays group is developing a netCDF standard for our water monitoring instruments. We've receive some fantastic help from John Graybeal and the folks at MMI. We are to a point where we have a couple of questions that are stumping us. I was hoping the CF group could help. I am a neophyte when it come to netCDF so please forgive my naive approach. The our group (CeNCOOS Bays) has two types of platforms for their water monitoring sensors: a floating platform (following the surface with the sensors a fixed distance below the surface) and fixed platform (fixed to a pier). Each platform type measures depth of sensors below the surface using pressure. However, for the fixed sensors, we want to locate the height of the sensor (z axis) in "real" space, i.e. in relation to some vertical datum, which would allow user to generate derive parameters such as tidal height. We also want to provide the information to allow users to convert to other tide datums. The solution we are working on for fixed instrument is outlined below, based on an example found in the SEACOOS NetCDF Standard, v2.0: For an instrument in a fixed position, for example fixed to a pier, then the z variable takes the form of a coordinate variable [i.e. z(z)] with a constant value that is referenced to a datum. Create a z dimension with a value of 1 The vertical coordinate variable 'z' (i.e. z(z) ) will be used to fix the location of the sensor in vertical space (i.e. not the distance below the water’s surface) referenced to a datum. For the datum we use WGS84. the z data value, e.g. z= -34.8194 m, is the vertical location of the sensor in WGS84. The depth variable (pressure sensor) gives depth in vertical distance below surface (which varies with the tide for fixed instruments). Associated with most measured variables (e.g. depth, water temperature, salinity...) is the attribute z and its value (e.g. depth: z = "-34.8194" ; ), which is a reference to the Z coordinate axis and value in m that locates the sensor relative to the datum. This information also is provided to allow the derivation of parameters such as water level from the depth parameter. The definition of the Z coordinate axis has the attribute reference value set to the tidal datum WGS84. We also provide the statistically determined local offsets to other tide datums, a local bench mark, and the averaging period and tidal epoch. We use the attribute reference_to_'datum' to provide the offsets. The reference_to_datum attributes each give the value of a common vertical position when referenced to different vertical datums. We have chosen a vertical position equal to 0 m when referenced to WGS84. The value of any reference_to_datum attribute (e.g.:reference_to_MLLW) is then an offset that can be used to convert a z-coordinate that is referenced to WGS84 (z[WGS84]) to a z-coordinate that is referenced to the other datum (e.g. z[MLLW]). For example, z(WGS84) plus z:reference_to_MLLW = z[MLLW]. The more offsets that we can provide, the more likely data users can transform water-level data to their reference level and make use of it. Simplified example of an optimal description that is fixed to the pier at the Romberg Tiburon Center at a height of -2 m MLLW (i.e. WGS84 = -34.8194): dimensions: z = 1 ; float z(z); z: standard_name = "height referenced to WGS84"; z: units = "m"; z: positive = "up"; z: axis = "Z"; z:reference = "WGS84" z:reference_to_WGS84= 0. z:reference_to_MLLW = 32.8194. z:reference_to_MLW = 32.4829 z:reference_to_LMSL = 31.8717 z:reference_to_MTL = 31.8585 z:reference_to_DTL = 31.9442 z:reference_to_MHW = 31.2487 z:reference_to_MHHW = 31.0710 z:reference_to_NAVD88 = 32.8116 z:reference_to_NAVD88_benchmark_id = "HT1060" z:reference_tide_datum_epoch = "1983-2001" z: comment = "The reference_to_datum attributes gives the value of a single vertical position when referenced to different vertical datums. We have chosen a vertical position equal to 0 m when referenced to WGS84. The value of any z:reference_to_datum attribute (e.g.:reference_to_MLLW) is an offset that can be used to convert a z-coordinate that is referenced to WGS84 (z[WGS84]) to a z-coordinate that is referenced to the other datum (e.g. z[MLLW]). For example, z(WGS84) plus z:reference_to_MLLW = z[MLLW]"; float depth(time); depth: standard_name = "depth"; depth: units = "m"; depth: reference = "surface depth: positive = "down"; depth: z = "-34.8194"; data: z = -34.8194 ; Does the above approach make sense? Any comments that you can provide would be appreciated. 2. The next question I have now is for creating a file for a floating instrument. In that case we have no datum in the vertical to reference. The instrument goes up and down with the tide and the sensors are at a fixed distance bel
