Hello Jonathan,
In my view this surface could be considered as the top of the ice, not the bottom and then it can be used as the reference for ice core data. That would remove one problem with 'solid-surface', although Bert doesn't like the term due to his semantic interpretation of 'solid'.
The problem with naming something like this is that so many different communities are involved so any name with a semantic content will attract criticism. Could we possibly circumvent this by using a namespace-based approach such as cf_solid_surface?
Cheers, Roy.
Please note that I partially retired on 01/11/2015. I am now only working 7.5 hours a week and can only guarantee e-mail response on Wednesdays, my day in the office. All vocabulary queries should be sent to enquiries at bodc.ac.uk. Please also use this e-mail if your requirement is urgent.
________________________________________
From: CF-metadata <cf-metadata-bounces at cgd.ucar.edu> on behalf of Jonathan Gregory <j.m.gregory at reading.ac.uk>
Sent: 25 February 2016 17:27
To: cf-metadata at cgd.ucar.edu
Subject: Re: [CF-metadata] vertical coordinate for bed stratigraphy / sediment layers
Dear Bert et al.
soil_surface does not sound obvious to me as a general description which
includes sea_floor. In addition there are some areas of land with bare rock
and no soil. We could perhaps call it the "solid surface" i.e. it
is the bottom of the fluid, which is either water or air, except that I
guess that below ice-sheets it's bottom of the ice you want, not the top.
Under ice-sheets CF refers to this level as bedrock, which seems to ignore
sediments because no-one's worried yet about that distinction. For air and
sea I think bedrock wouldn't be right for your purpose, as it sounds like
the top of the crust. To exclude ice (both land ice and sea ice) we could
call it non_ice_solid_surface.
Best wishes
Jonathan
----- Forwarded message from Bert Jagers <Bert.Jagers at deltares.nl> -----
> Date: Wed, 24 Feb 2016 16:00:22 +0000
> From: Bert Jagers <Bert.Jagers at deltares.nl>
> To: "cf-metadata at cgd.ucar.edu" <cf-metadata at cgd.ucar.edu>
> Subject: Re: [CF-metadata] vertical coordinate for bed stratigraphy /
> sediment layers
>
> Dear Roy, Reyna, All,
>
> Thank you for your input.
>
> Within Deltares (at least the modelling groups) we also refer to this surface as the "bed" and refer to the elevation as "bed level". From a hydrodynamic modelling point of view the "bed_surface" would be attractive, however this doesn't sound generic enough for broader applications.
>
> As Roy indicates this surface should be more generic than "sea_floor", unless we accept that in a world with changing sea level we are all walking on the sea floor.
>
> I discussed this topic with a geomorphologist of Utrecht university and he indicated that "crust" is typically associated with the bedrock on top of which the alluvial sediments and biota forming soil are located. Since we are mostly interested in the alluvial sediments, this would suggest that "top_of_crust" doesn't quite fit the purpose. Although soil is typically only used for sediment mixed with material of biological origin (and in our models such components are still absent most of the time), he suggested to use "soil_surface" as it is more generic moving towards the future and is compatible with most field observations. The use of soil in the standard name table seems to be consistent with this use. Any objections against this name?
>
> Best regards,
>
> Bert
>
> -----Original Message-----
> From: Reyna Jenkyns [mailto:reyna at uvic.ca]
> Sent: 24 February 2016 14:49
> To: Lowry, Roy K.; Bert Jagers; cf-metadata at cgd.ucar.edu
> Subject: Re: [CF-metadata] vertical coordinate for bed stratigraphy / sediment layers
>
>
> Hi all,
>
> Joining in on this, because we have instrumentation taking measurements in seafloor boreholes that I've been unable to put in CF convention to this point. We refer to their depth referenced from the seafloor as well. That's what we are typically able to know at deployment. Similarly when we are doing sediment cores, we know the depth of the core in the sediment. Personally, I would prefer sea_floor to top_of_crust.
>
>
> Reyna Jenkyns | Data Stewardship Team Lead - Digital Infrastructure Ocean Networks Canada | T 250 853 3908 | oceannetworks.ca University of Victoria PO Box 1700 STN CSC 2300 McKenzie Avenue Victoria, BC V8W 2Y2
>
>
> ________________________________________
> From: CF-metadata <cf-metadata-bounces at cgd.ucar.edu> on behalf of Lowry, Roy K. <rkl at bodc.ac.uk>
> Sent: Wednesday, February 24, 2016 2:07 AM
> To: Bert Jagers; cf-metadata at cgd.ucar.edu
> Subject: Re: [CF-metadata] vertical coordinate for bed stratigraphy / sediment layers
>
> Dear All,
>
> Bert is raising an interesting issue which is a result of the historical extension of CF from atmospheric science, through oceanography and now into geology.
>
> What we're talking about is a reference plane that is synonymous to 'surface' for the base of the atmosphere, but instead refers to the top of the crust. To date this layer has been labelled 'sea_floor' in CF, which is a portion of this reference plane that happens to be overlain by salt water. In my organisation we have started to call it the 'bed' (although we still have some historical references to seafloor) because we deal with estuaries, rivers and lakes in addition to seas and oceans and don't want to worry about the salinity of the overlying water when discussing a spatial reference. We also accept that the 'bed' can be dry at times because the tide comes in and out. It therefore makes perfect sense to continue this reference onto land where it becomes known to a terrestrial geologist as 'soil_surface'.
>
> This reference would be used as the reference for measurements of distances to 'things' below the surface of the crust, such as layer boundaries or location of a captured burrowing animal. However, this reference is also something whose variation as a function of time at a given point may be measured relative to another 'fixed' reference such as the geoid.
>
> Assuming we agree that such a global continuum reference in the Standard Name vocabulary, the $64,000 question is what should it be called? It could be done by redefining what we mean by 'sea_floor', but I can see that being somewhat unpopular!! How about something like 'top_of_crust'?
>
> Note that I don't feel that introducing such a name would necessarily force the abandonment of 'sea_floor' - I don't see a problem with having sea_floor as a specialisation of top_of_crust (i.e. top_of_crust overlain by salt water or even just water).
>
> Other thoughts and opinions?
>
> Cheers, Roy.
>
> -----Original Message-----
> From: CF-metadata [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Bert Jagers
> Sent: 22 February 2016 13:35
> To: cf-metadata at cgd.ucar.edu
> Subject: [CF-metadata] vertical coordinate for bed stratigraphy / sediment layers
>
> Follow-up of Nov 2015 thread: "standard names and vertical coordinate for bed stratigraphy / sediment layers"
> ----------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Dear Jonathan, Roy, Steve, all,
>
>
> I've finally again time to focus on this issue. The feedback that I got from Roy and Jonathan is to store the depth rather than trying to define a formula for computing the depth from layer thicknesses (and nobody suggested anything else). So, what I'll need is a name for the quantity that stores the (minimum/maximum/...) depths of the sedimentation layers.
>
> To summarize the comments made earlier:
>
> The discussion with Roy Lowry hinted at standard names for the vertical coordinate at:
> * depth_below_seabed, or
> * depth_below_sea_floor
>
> In the context of defining a standard name for the thickness of sediment layers, Jonathan asked whether the phrase "below_sea_floor" would be necessary in the initially suggested name "thickness_of_sediment_layers_below_sea_floor". I fully agree with Jonathan that it would much better to simply refer to "thickness_of_sediment_layers" without any addition since I'm actually interested in sediment layers that could be below land or water (rivers, lakes, estuaries, seas, ...). BTW. I'm indeed primarily interested in active sedimentation (and erosion) processes, such that this will usually exclude sedimentary rock (although the base layer of the alluvial sediment layers will typically be equal to the top of the sedimentary rock - if such a clear distinction can be made).
>
> So, can we come up with a name for the vertical coordinate without reference to "below_sea_floor"? The existing standard name "depth" refers to the vertical distance below the surface where I assume 'surface' should be read as "the lower boundary of the atmosphere" as in other quantities. That's not the surface I'm looking for. I would be looking for the surface consisting of the land surface and the river/lake/eastuary/sea/ocean floor. Would this be the earth_surface or would you interpret the earth_surface as equivalent to the "the lower boundary of the atmosphere". Another alternative could possibly be soil_surface. A more generic approach could be to define a standard_name "depth_below_reference_surface" (with unit m) which would then need a reference surface which in our case could be either the sea_floor_depth_below_geoid and/or the land surface. However, I don't see any previous case setting a convention for defining reference plane. There are two exiting examples of !
> reference
> surfaces:
>
> (1)
>
> * geoid_height_above_reference_ellipsoid,
> * height_above_reference_ellipsoid,
> * histogram_of_backscattering_ratio_over_height_above_reference_ellipsoid,
> * histogram_of_equivalent_reflectivity_factor_over_height_above_reference_ellipsoid, and
> * sea_surface_height_above_reference_ellipsoid
>
> all refer to a reference_ellipsoid. However, there doesn't seem to be a way of defining the reference_ellipsoid (at least no reference is made to a description of how this ellipsoid should be defined), and furthermore the ellipsoid would be too generic for our application where we really need the local topography (or bathymetry) as reference surface.
>
> (2)
> * water_surface_height_above_reference_datum
>
> is defined relative to a reference surface with the explicit name:
>
> * water_surface_reference_datum_altitude
>
> which makes it impossible to reuse an already existing quantity (such as sea_floor_depth_below_geoid).
>
> Can we define a standard_name "depth_below_reference_surface" which would require an explicit attribute 'reference_surface' that points to any depth or altitude variable?
>
>
> Best regards,
>
> Bert
>
> -----Original Message-----
> From: CF-metadata [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Jonathan Gregory
> Sent: 10 November 2015 15:50
> To: cf-metadata at cgd.ucar.edu
> Subject: [CF-metadata] standard names and vertical coordinate for bed stratigraphy / sediment layers
>
> Dear Bert
>
> > * thickness_of_sediment_layers_below_sea_floor
> >
> > > Is below_sea_floor necessary in this name? If the aim is to indicate what sediment you mean, would thickness_of_sea_floor_sediment_layer be OK?
> >
> > We came up with the "below_sea_floor" phrase since we considered to use this variable as a vertical coordinate as explained in the mail. Roy Lowry suggested (in a partially offline discussion) to replace the thickness variable with the proposed formula by an explicit neutral vertical coordinate "depth_below_sea_floor" and subsequently specify both maximum and minimum values per layer. This would be consistent with observation data but it would no longer be clear that the layers are consecutive (or you would have to check whether the minimum depth of one layer matches the maximum depth of the other layer). On the other hand I would love to get rid of the "below_sea_floor" addition since the layers could be in rivers, lakes, or below dry land as well.
>
> I think it might be better to separate your two purposes of naming quantities and constructing coordinates. This quantity is one which could be used in other situations where it's not a coordinate, and below_sea_floor would then be confusing. Would just thickness_of_sediment_layer be OK? Can sediment mean anything else in geoscientific terminology? Below dry land, are you thinking of sedimentary rock? - that is different, I would say. Sediments are at the bottom of liquid, in my understanding (although I appreciate that sedimentary rock started like that). I note that due_to_sedimentation appears in the stdname table, and I think it's the same meaning of sedimentation.
>
> > > In using mass_content you are following other standard names, I know, but it might not be clear what it means, and I wonder if mass_per_unit_area might be better, which is also in use.
> >
> > Mass_per_unit_area sounds better to me as well
>
> OK.
>
> I agree that "areic" is not a well-known word (I hadn't heard it before) and since it is not used in CF already I'd rather not introduce it. I think "mass content" makes sense in the context of atmosphere_mass_content_of_X, where is it most often used, and it's also the sense in soil_moisture_content.
>
> > * mass_content_of_sediment_fraction_in_sediment_layer
> > * volume_fraction_of_sediment_fraction_in_sediment_layer
> >
> > > sediment_fraction_of_sediment_layer sounds odd to me. Isn't it 100%?
> >
> > Yes, the name did feel odd to me as well, but it isn't 100%. In the model we can include any number of sediment fractions (think gravel, sand, silt, clay, but the sediment classes can be subdivided further or grouped differently dependent on the use case, so predefined enumeration is not an option). So, I would explain the term as the mass_content or volume_fraction of a particular sediment fraction (likely to be an array dimension to be associated with a string valued scalar coordinate containing sediment fraction names and auxiliary sediment fraction properties such as fraction specific minimum, median, and maximum grain size, specific density, etc.
>
> I see. Just as there are many atmosphere_mass_content_of_X names, you could have several mass_per_unit_area_of_X_in_sediment_layer for various X. That would be clearer than using sediment in two senses. If you want to have a coordinate variable which runs over X, I agree that you need a generic name.
> Maybe it could be sediment_type, like area_type?
>
> > > Could "layer" be omitted from the volume_fraction? - it's an intensive quantity, not dependent on layer thickness.
> > Yes, probably it can. Was trying to make names similar.
>
> Yes, I understand, but it would be more generally useful without.
>
> > Our model is not the only model to use multiple sediment layers, so I do think that it is not very specific to our own use case. However, there seems as Roy indicated some discussion how to store it most generically. There are a couple of options:
> > 1) would be to specify a regular CF coordinate for the centres of the N layers and then upper and lower bounds of the N layers, but I consider this to be too verbose (and also there is currently no CF bounds formulation that would allow us to do precisely this): 3N values.
> > 2) define per layer the maximum and minimum depth: 2N values. This still duplicates data, but seems to be consistent with observation data practices of SeaDataNet. Also separate minimum and maximum values suggest that layers may not be consecutive; there could be gaps; or layers may overlap. I'm interested in just a simple stack of layers.
> > 3) define the N thicknesses of the layers and define how to determine the vertical coordinate using some formula (this is what I tried).
> > 4) define the N+1 layer interfaces and use this as a coordinate for
> > the quantities in the N layers. The CF conventions don't have any
> > feature to support this. Following the UGRID development we worked a
> > bit in this direction with SGRID:
> > https://publicwiki.deltares.nl/display/NETCDF/Deltares+proposal+for+St
> > aggered+Grid+data+model+%28SGRID%29
>
> I like (2) best, especially if it's been used before, because it's most like CF bounds and is more general. You could avoid defining standard names for the maximum and minimum depth if you had some notional vertical 1D coordinate variable (say VERTICAL). In that case the max and min depths could be auxiliary coord variables that were also data variables in their own right, distinguished by cell_methods that contain "VERTICAL: maximum" and "VERTICAL: minimum".
>
> Alternatively we could define some new CF bounds convention for this sort of case. CF presently does not have a convention which adds a single dimension of size 2 to a multidimensional bounds variable. The convention would have to indicate which spatial dimension the 2 applies to. E.g. you might have data variables (vertical,lat,lon) and a bounds variable (vertical,lat,lon,2) or upper and lower vertical bounds that depend on (vertical,lat,lon). I am sure that such a mechanism would be needed by other applications. In fact I recall some related discussion on email before.
>
> Best wishes
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> ________________________________
> This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system.
> ________________________________
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
> DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
----- End forwarded message -----
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
________________________________
This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system.
________________________________
Received on Mon Feb 29 2016 - 08:10:35 GMT
