Custom Query (124 matches)
Results (16 - 18 of 124)
Ticket | Resolution | Summary | Owner | Reporter | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
#17 | fixed | Remove ambiguity in cell_methods, especially means over subgrid areas | cf-conventions@… | jonathan | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description |
1. TitleRemove ambiguity about statistics described by cell_methods, especially means over subgrid areas 2. ModeratorKarl Taylor 3. RequirementTo indicate the portion of a cell over which a statistic has been calculated, in situations where there is a need to distinguish between statistics calculated for the same quantity over different portions of the cell, or where the quantity might be considered to be undefined over some portion of the cell. The statistic is usually a mean or a sum. The situation most often arises with cells in the horizontal, where the "portions" are different types of surface that don't have defined geographical boundaries. Some examples:
the entire area of the cell including land. These can all be written as A/B, where A is the total volume of sea ice in the cell, and B is the area of sea ice, the area of sea or the area of the cell.
within the cell e.g. land, sea, land ice, forest. These might similarly be written as A/B, A (in W) being the area-integral of the flux applying to the given surface type, and B (in m2) either the area occupied by that type, or the cell area. Alternatively, this means the flux (W m-2) is expressed either per unit area of the particular surface type, or per unit area of the grid cell. When the values for different types are given per unit area of the cell, the sum of these values over all types is the mean for the cell as a whole.
cell. This is only likely to be given as a average value for each surface type i.e. formally where B is the area of that type e.g. the temperature is 300 K over the land portion of the cell, 310 K over the forest portion. 4. Initial Statement of Technical ProposalIn the standard_name guidelines, this issue is partly addressed by using where-phrases. However, this approach is unclear and inadequate. It can't indicate, for instance, whether the sensible heat flux applying to the land portion of the box is expressed per unit area of land or per unit area of the cell. The present proposal follows the one made on the email list in December 2006 http://www.cgd.ucar.edu/pipermail/cf-metadata/2006/001449.html. Following our discussion in Paris in June 2007, the proposal extends the use of cell_methods and coordinates to indicate subgrid variation more precisely, and eliminates where-phrases from standard names.
intensive quantity is "point", which means a local value in area or an instantaneous value in time, and "sum" for an extensive quantity, meaning the sum over area or time in the cell. No change is proposed to this: it is unproblematic, because point values and integrals do not involve dividing by anything. It is undefined what value should be given if the quantity does not exist e.g. for sea_ice_thickness where there is no sea ice, the value could be zero or missing, as either would make sense for a point value.
of names without the where-phrases. There are only nine of them at present: precipitation_flux_onto_canopy_where_land surface_net_downward_radiative_flux_where_land surface_snow_thickness_where_sea_ice surface_temperature_where_land surface_temperature_where_open_sea surface_temperature_where_snow surface_upward_sensible_heat_flux_where_sea water_evaporation_flux_from_canopy_where_land water_evaporation_flux_where_sea_ice
the surface_cover types as well as any distinctions of horizontal area which are not surface types, such as "cloud". It is not proposed to standardise the values of area_type at present, but they could be standardised later.
especially string-valued scalar coordinate variables:
...] method" (see CF 7.3), where names are the names of dimensions, scalar coordinate variables, or standard_names. Horizontal area-means are indicated by "lat: lon: mean", if lat and lon are the latitude and longitude dimensions. I propose to introduce a special name of area to indicate horizontal area, so an area-mean can be written "area: mean". This is more obvious and convenient. To do this, modify the paragraph in 7.3 beginning "If a data value is representative of variation over a combination of axes" by changing "a longitude-latitude gridbox would have" to "... could have", and appending the following:
portions of cells before the paragraph beginning "The convention of specifying", as follows:
dimensions: lat=73; lon=96; maxlen=20; lc2=2; variables: float surface_temperature(lat,lon); surface_temperature:cell_methods="area: mean where land"; float surface_upward_sensible_heat_flux(lc2,lat,lon); surface_upward_sensible_heat_flux:coordinates="land_cover2"; surface_upward_sensible_heat_flux:cell_methods="area: mean"; char land_cover2(lc2,maxlen); data: land_cover2="land","sea";
variables: float snow_thickness(lat,lon); snow_thickness:cell_methods="area: mean where sea_ice over sea"; snow_thickness:standard_name="lwe_thickness_of_surface_snow_amount"; snow_thickness:units="m"; float sea_ice_thickness(lat,lon); sea_ice_thickness:cell_methods="area: mean over sea"; sea_ice_thickness:standard_name="sea_ice_thickness"; sea_ice_thickness:units="m";
as follows:
5. BenefitsThese clarifications will particularly benefit those providing or using data from models, when it is important to be clear exactly how area-means have been calculated. The current standard is unclear. 6. Status QuoThe necessary clarification could be recorded as a comment in () in the cell_methods. This is not usually done, and even if it were done, generic applications could not use it to distinguish the possibilities as it is not standardised. For the CMIP3 database, PCMDI described how means should be calculated e.g. whether sea ice thickness is calculated as the mean over sea ice area or some other area; the prescription was not recorded in the netCDF data produced, which is therefore not self-describing. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#18 | fixed | Additions and Revisions to CF Grid Mapping Attributes (v2.0) | cf-conventions@… | pbentley | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description |
1. TitleAdditions and revisions to CF grid mapping attributes to support the specification of coordinate reference system properties. 2. ModeratorJonathan Gregory 3. RequirementThis submission is a follow-up proposal to the informative discussions that took place as part of CF Trac ticket #9. Consequently the requirements remain as stated in that ticket, and can be paraphrased as follows:
Based on the discussions arising from Trac ticket #9 it was concluded that further research needs to be undertaken in order to address the complexities of vertical datums and vertical coordinate systems. Accordingly the corresponding attributes have been dropped from this revised proposal. It is hoped that a domain expert within the CF community will be able to submit a separate proposal covering these topics. 4. Initial Statement of Technical ProposalThe following sections detail the proposed changes to the CF-1.0 specification. They hopefully represent a synthesis of the discussions and conclusions arising from Trac ticket #9. 4.1. Additions and Revisions to Appendix F, Table F.1This section describes the new and revised grid mapping attribute definitions that are required to be added to Table F.1 in Appendix F of the CF specification. Attributes are listed in alphabetical order. Attribute names appearing in normal typeface are newly defined in this proposal. Attribute names appearing in italic typeface refer to existing CF attributes for which a revised definition is proposed. Table F.1 Grid Mapping Attributes
4.2. Insertion of Additional Grid Mapping Examples into Appendix FThe following examples of grid mapping definitions are required to be added to Appendix F. Example F.9. 2D Latitude-Longitude Coordinate System (Spherical Earth) This grid mapping defines the canonical 2D geographical coordinate system based upon latitude and longitude coordinates on a spherical Earth. If required, the Earth radius can be specified via the semi_major_axis attribute. grid_mapping_name = "lat_long_on_sphere" dimensions: lat = 18 ; // dummy values lon = 36 ; variables: double lat(lat) ; // conventional definition double lon(lon) ; // conventional definition float temp(lat, lon) ; temp:long_name = "temperature" ; temp:units = "K" ; temp:grid_mapping = "crs" ; int crs ; crs:grid_mapping_name = "lat_long_on_sphere" ; crs:crs_id = "urn:ogc:def:cs:EPSG:6.0:6422" ; // EPSG ID 6422 == "Ellipsoidal 2D CS" crs:crs_name = "Spherical 2D Coordinate System" ; crs:ellipsoid_name = "Sphere" ; crs:semi_major_axis = 6371000.0 ; crs:inverse_flattening = 0 ; Example F.10. 3D Latitude-Longitude-Height Coordinate System (Spherical Earth) This grid mapping defines the canonical 3D geographical coordinate system based upon latitude and longitude and height coordinates on a spherical Earth. If required, the Earth radius can be specified via the semi_major_axis attribute. grid_mapping_name = "lat_long_ht_on_sphere" dimensions: lat = 18 ; // dummy values lon = 36 ; ht = 50 ; variables: double lat(lat) ; // conventional definition double lon(lon) ; // conventional definition double ht(ht) ; // conventional definition float temp(ht, lat, lon) ; temp:long_name = "temperature" ; temp:units = "K" ; temp:grid_mapping = "crs" ; int crs ; crs:grid_mapping_name = "lat_long_ht_on_sphere" ; crs:crs_id = "urn:ogc:def:cs:EPSG:6.0:6423" ; // EPSG ID 6423 == "Ellipsoidal 3D CS" crs:crs_name = "Spherical 3D Coordinate System" ; crs:ellipsoid_name = "Sphere" ; crs:semi_major_axis = 6371000.0 ; crs:inverse_flattening = 0 ; Example F.11. Latitude-Longitude on the WGS 1984 Datum This grid mapping defines the commonly-used CRS involving geodetic latitude and longitude coordinates - and potentially also ellipsoidal height - based upon the WGS 1984 geodetic datum. grid_mapping_name = "lat_long_wgs1984" (2D case) or "lat_long_ht_wgs1984" (3D case) dimensions: lat = 18 ; // dummy values lon = 36 ; variables: double lat(lat) ; // conventional definition double lon(lon) ; // conventional definition float temp(lat, lon) ; temp:long_name = "temperature" ; temp:units = "K" ; temp:grid_mapping = "crs" ; int crs ; crs:grid_mapping_name = "lat_long_wgs1984" ; crs:crs_id = "urn:ogc:def:crs:EPSG:6.0:4326" ; // Use EPSG ID 4979 for 3D CRS. ID 4326 refers to 2D CRS. crs:crs_name = "WGS 84" ; crs:geodetic_datum_name = "World Geodetic System 1984" ; crs:longitude_of_prime_meridian = 0.0 ; crs:ellipsoid_name = "WGS 84" ; crs:semi_major_axis = 6378137.0 ; crs:inverse_flattening = 298.257223563 ; Example F.12. British National Grid (with CRS_WKT attribute) This example illustrates the use of grid mapping attributes to provide a full description of the 2D projected CRS that forms the basis of the British National Grid reference system. It also demonstrates how the same information could be encoded - possibly in an automated fashion by software applications - in OGC WKT format using the crs_wkt attribute. grid_mapping_name = "british_national_grid" dimensions: lat = 648 ; // dummy values lon = 648 ; y = 18 ; x = 36 ; variables: double x(x) ; x:standard_name = "projection_x_coordinate" ; x:long_name = "x coordinate of projection" ; x:units = "m" ; double y(y) ; y:standard_name = "projection_y_coordinate" ; y:long_name = "y coordinate of projection" ; y:units = "m" ; double lat(y, x) ; // conventional definition double lon(y, x) ; // conventional definition float temp(y, x) ; temp:long_name = "temperature" ; temp:units = "K" ; temp:coordinates = "lat lon" ; temp:grid_mapping = "crs" ; int crs ; crs:grid_mapping_name = "british_national_grid" ; crs:crs_id = "urn:ogc:def:crs:EPSG:6.0:27700" ; crs:crs_name = "OSGB 1936 / British National Grid" ; crs:geodetic_datum_name = "OSGB 1936" ; crs:longitude_of_prime_meridian = 0.0 ; crs:ellipsoid_name = "Airy 1830" ; crs:semi_major_axis = 6377563.396 ; crs:semi_minor_axis = 6356256.910 ; crs:inverse_flattening = 299.3249646 ; crs:projection_name = "British National Grid" ; crs:latitude_of_projection_origin = 49.0 ; crs:longitude_of_projection_origin = -2.0 ; crs:false_easting = 400000.0 ; crs:false_northing = -100000.0 ; crs:scale_factor_at_projection_origin = 0.9996012717 ; crs:crs_wkt = "[PROJCS ['OSGB 1936 / British National Grid', GEOGCS ['OSGB 1936', DATUM ['OSGB 1936', SPHEROID ['Airy 1830', 6377563.396, 299.3249646]], PRIMEM ['Greenwich', 0], UNIT ['Degree', 0.0174532925199433]], PROJECTION ['Transverse Mercator'], PARAMETER ['False Easting', 400000], PARAMETER ['False Northing', -100000], PARAMETER ['Central Meridian', -2.0], PARAMETER ['Scale Factor', 0.9996012717], PARAMETER ['Latitude of Origin', 49.0], UNIT ['Meter', 1.0]]" ; In this example the optional crs_wkt attribute is shown spread across multiple lines. In a netCDF file such an attribute value would, of course, appear as a single text string. Also, occurrences of the single-quote character would be replaced with double-quote characters. Example F.13. Cartesian (X-Y) Coordinates based on the Vertical Perspective Projection The following example demonstrates the use of grid mapping attributes to describe X-Y cartesian coordinates based on the vertical perspective projection. Such a CRS might be used, for example, to describe image data that simulates the view from a Meteosat satellite. grid_mapping_name = "vertical_perspective" variables: double x(x) ; // conventional definition double y(y) ; // conventional definition double lat(y, x) ; // conventional definition double lon(y, x) ; // conventional definition float temp(lat, lon) ; temp:long_name = "temperature" ; temp:units = "K" ; temp:grid_mapping = "crs" ; int crs ; crs:grid_mapping_name = "vertical_perspective" ; crs:crs_name = "X-Y Coordinates based on Vertical Perspective Projection" ; // Fabricated for this example. crs:geodetic_datum_name = "World Geodetic System 1984" ; crs:longitude_of_prime_meridian = 0.0 ; crs:ellipsoid_name = "WGS 84" ; crs:semi_major_axis = 6378137.0 ; crs:inverse_flattening = 298.257223563 ; crs:projection_name = "Vertical Perspective" ; crs:latitude_of_projection_origin = 0.0 ; // Above the equator... crs:longitude_of_projection_origin = 75.0 ; // ... and over the Indian Ocean. crs:perspective_point_height = 36000000 ; // 36,000 km crs:earth_radius = 6371007 ; // Indicates that the projection used a spherical Earth approximation. The crs_id attribute is omitted from the above definition as, currently, a unique identifier for this map projection has yet to be assigned in the EPSG/OGP geodetic database. 4.3. Addition of New Sub-Section F.1 to Appendix FThe following sub-section is required to be added to Appendix F. This sub-section is also required to be repeated (or paraphrased) as a new section entitled F. Grid Mapping Attributes appended to the CF conformance document. F.1. Recommended minimum set of grid mapping attributes In order to achieve a basic level of consistency of specification it is proposed that, wherever practicable, a minimum set of attribute values is employed to specify the CRS referenced by a netCDF variable. The recommended minimum set of grid mapping attributes for describing 2D geographic and 2D projected coordinate reference systems is given below. F.1.1. Recommended minimum set of attributes required to describe a 2D geographic CRS: grid_mapping_name crs_id* crs_name geodetic_datum_name ellipsoid_name semi_major_axis semi_minor_axis and/or inverse_flattening longitude_of_prime_meridian (* if known) In the case of a 3D geographic CRS the third dimension (or axis) is height above or below the ellipsoid, in which case a further parameter – units of ellipsoidal height – is normally required. However, this parameter typically will be defined via the units attribute for the relevant coordinate variable (e.g. Z). Hence no separate attribute is defined here. F.1.2. Recommended minimum set of attributes required to describe a 2D projected CRS: grid_mapping_name crs_id* crs_name geodetic_datum_name ellipsoid_name semi_major_axis semi_minor_axis and/or inverse_flattening longitude_of_prime_meridian projection_name latitude_of_projection_origin longitude_of_projection_origin earth_radius#
(* if known) Additional projection-specific attributes should be defined as required, e.g. false_easting, false_northing, scale_factor_at_projection_origin, and so on. 4.4. Addition of New Sub-Section F.2 to Appendix FThe following sub-section is required to be added to Appendix F. F.2 OGC CRS Identifiers corresponding to CF grid mapping definitions Table F.2 lists the Open Geospatial Consortium (OGC) URNs for the coordinate reference systems, coordinate systems, and map projections (OGC 'coordinate operation methods') that correspond to the example grid mapping names illustrated in this version of the CF specification. Grid mapping names that are not currently associated with an equivalent OGC URN (e.g. "rotated_latitude_longitude") do not appear in Table F.2. It is noted that the majority of grid mapping names defined in CF-1.0 refer to OGC coordinate operation methods (i.e. map projections) rather than coordinate reference systems. The values defined in the OGC URN Identifier column may be used, as and when appropriate, to define the crs_id grid mapping attribute. The OGC URN syntax is described in reference [OGC-URN]. Table F.2. OGC URNs corresponding to CF grid mapping names
(* OGC object types can be considered equivalent to like-named objects in the OGP/EPSG database.) 4.5. Addition of References to BibliographyThe following bibliographic references are required to be appended to the CF bibliography chapter. [OGC-SRC] Topic 2: Spatial Referencing by Coordinates. OGC Abstract Specification. OGC document 04- 046r3. 16 August 2004. (URL: http://www.opengeospatial.org/standards/as) [OGC-SFA1] OpenGIS Implementation Specification for Geographic information - Simple feature access - Part 1: Common architecture. OGC document 06-103r3. 5 October 2006. (URL: http://www.opengeospatial.org/standards/sfa) [OGC-URN] Definition Identifier URNs in OGC Namespace. OGC Best Practices Paper. OGC document 06- 023r1. 8 August 2007. (URL: http://www.opengeospatial.org/standards/bp) 5. BenefitsAs per original Trac ticket #9. 6. Status QuoAs per original Trac ticket #9. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#19 | fixed | Standard Name Modifiers | ros | ros | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description |
Allow standard_name attribute to be comprised of a standard name optionally followed by one or more blanks and a standard name modifier (a string value from Appendix C, Standard Name Modifiers). |