Custom Query (124 matches)
Results (37 - 39 of 124)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#104 | fixed | Clarify the interpretation of scalar coordinate variables | davidhassell | jonathan |
Description |
David Hassell and I propose the following changes to the CF standard document to clarify the interpretation of scalar coordinate variables. We do not think this is a material change to the convention, which already implies this interpretation, and we believe this interpretation is what was intended when scalar coordinate variables were introduced. Section 5.7, Scalar coordinate variables. The convention contains the following sentences:
These sentences are OK as they stand, we think, but it would be better to describe the current situation without emphasising its history, so we would propose to replace them with the following. In addition, we propose to add a bit extra, as shown, to the second sentence below:
The next sentence would be unchanged; it mentions how this situation relates to that of the COARDS convention. At the end of the section, after the example, we propose to append the following sentences:
We think the above interpretation and implications are consistent with the convention already, which says in this section that, "Scalar coordinate variables have the same information content and can be used in the same contexts as a size one coordinate variable". However, it would be an improvement to spell it out. Section 6.1, Labels Replace the last sentence
with
The last part is a repetition of what Section 5.7 says. The reason for the change is that the existing wording is careless in implying that a string could be a coordinate variable; in fact, this is not possible, since string- value coordinates must be auxiliary coordinate variables. The interpretation of scalar coordinate variables in Section 9 may be different from the above, and this may require further clarification if the above is agreed. |
|||
#140 | fixed | Clarifying the role of attributes on boundary variables. | cf-conventions@… | davidhassell |
Description |
1. Title
2. Moderator
3. Requirement
4. Initial Statement of Technical Proposal
5. Benefits
6. Status Quo
David Hassell |
|||
#70 | fixed | Connecting coordinates to Grid Mapping variables | davidhassell | markh |
Description |
TitleConnecting coordinates to Grid Mapping variables ModeratorDavid Hassell RequirementTo allow each Coordinate or Auxiliary Coordinate Variable to be explicitly attached to a particular Grid Mapping Variable. ProposalTo define a coordinate reference system, a grid_mapping variable is defined, with variable attributes to define the coordinate reference system attributes. http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.5/ch05s06.html To define coordinates, be they coordinate variable or auxiliary coordinates, with respect to a coordinate system an enhanced grid_mapping syntax is proposed. A data variable's grid_mapping attribute may use a syntax, derived from the cell_methods and cell_measures approach. Using this model, the Grid Mapping variable name is stated, followed by a ':' followed by a space separated list of Coordinate names; a name finishing with a ':' indicates a new Grid Mapping variable name, to be followed by the coordinates which are linked to it. GRID_MAPPING_VAR: COORD_VAR [COORD_VAR ...] [GRID_MAPPING_VAR: ...] The current grid_mapping attribute syntax is a regressive case of this, so the proposal is backwards compatible. In the case where the grid_mapping attribute contains no ':' then the grid_mapping is defined by the current methodology. The grid_mapping attribute is interpreted differently if it uses the enhanced syntax, in which case different coordinates may be linked to different Grid Mappings. Section 5.6 should include the text: A data variable may link Coordinates and Auxiliary Coordinate Variables to Grid Mapping Variables by supplying the name of the Grid Mapping variable, a ':' and a space separated list of Coordinate names: GRID_MAPPING_VAR: COORD_VAR [COORD_VAR ...] [GRID_MAPPING_VAR: ...] within the data variable's grid_mapping attribute. Use CaseConsider a file containing a data variable referencing coordinate variables: Easting, Northing, Height (above mean sea level). These are all defined with respect to the Ordnance Survey of Great Britain coordinate reference system, a parametric transverse Mercator with a defined vertical datum. To be CF compliant I need to include two auxiliary coordinates, latitude and longitude. I can calculate these for a specifically defined coordinate reference system, using the definition of the transverse Mercator projection. I will also include the height with respect to this new datum as an auxiliary_coordinate. In the example use case then the data variable's grid_mapping attribute would read: "OSGB: Easting Northing Height GeogCS: Lat Lon geogHeight" dimensions: y = 100000 ; x = 100000 ; z = 100; variables: double x(x) ; x:standard_name = "projection_x_coordinate" ; x:long_name = "Easting" x:units = "m" ; double y(y) ; y:standard_name = "projection_y_coordinate" ; y:long_name = "Northing" y:units = "m" ; double z(z) ; y:standard_name = "height_above_reference_ellipsoid" ; y:long_name = "height_above_osgb_msl" ; y:units = "m" ; double lat(y, x) ; lat:standard_name = "latitude" ; lat:units = "degrees_north" ; double lon(y, x) ; lon:standard_name = "longitude" ; lon:units = "degrees_east" ; float temp(y, x) ; temp:standard_name = "air_temperature" ; temp:units = "K" ; temp:coordinates = "lat lon" ; temp:grid_mapping = "crsOSGB: x y z GeogCS: lat lon" ; float pres(y, x) ; temp:standard_name = "air_pressure" ; temp:units = "Pa" ; temp:coordinates = "lat lon" ; temp:grid_mapping = "crsOSGB: x y z GeogCS: lat lon" ; int crsOSGB ; crs:grid_mapping_name = "transverse_mercator"; crs:semi_major_axis = 6377563.396 ; crs:inverse_flattening = 299.3249646 ; 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:vert_CS = "Newlyn" ; crs:vert_datum = "Ordnance Datum Newlyn, 2005" ; crs:unit = "metre" ; int crsWGS84 ; crs:grid_mapping_name = "latitude_longitude"; crs:longitude_of_prime_meridian = 0.0 ; crs:semi_major_axis = 6378137.0 ; crs:inverse_flattening = 298.257223563 ; |