Custom Query (125 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (34 - 36 of 125)

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Ticket Resolution Summary Owner Reporter
#89 fixed standard names for vector components davidhassell markh
Description

Objective

A reinterpretation of current standard names to make the identification of vector components clear and able to meet the needs of users.

This issue is related to the proposal on #79

Proposal

To adopt the constrained standard name concept to re-interpret vector quantity standard names, without invalidating any current datasets. This would involve:

  • 'x_' type standard names being valid for all coordinate definitions:
    • '"x" indicates a vector component along the grid x-axis, positive with increasing x.'
  • 'eastward_' type standard names being valid for all 'true east' vectors:
    • '"Eastward" indicates a vector component which is positive when directed eastward (negative westward); where eastward is defined as the grid x-axis direction, this is a constrained version of the "x_" standard name';
    • this may be interpreted in two ways, as:
      1. where eastward is defined as the grid x-axis, this standard name is a constrained version of x_wind
      2. where eastward is not defined as the grid x-axis, this standard name stands independently

This enables data producers to use eastward wind in the same way they currently do, while meeting my requirements, for datasets where x may or may not be east, depending on the location and for data format interoperability with formats which do not have an explicit 'eastward_' phenomenon definition.

It enables datasets to be written where:

  • vector is x but not east
    • standard_name: x_<>
  • vector is x and may be east or eastish
    • standard_name: x_<>
  • vector is x and happens to be always east
    • standard_name: x_<>
  • vector is x constrained to always be east
    • standard_name: eastward_<>
  • vector is east but not x
    • standard_name: eastward_<>

'eastward_<>' is already interpreted in multiple ways, depending on the coordinate variable context of the dataset. 'x_<>' should also be abe to be interpreted based on coordinate variable context, to enable datasets to be encoded which currently cannot be written in a CF compliant fashion

Analogy

This approach, of constraining standard names, is analogous to qualification. For example:

  • there is a standard name of air_pressure
  • this could be defined, for a particular dataset, such that the vertical coordinate indicates that the data is at a surface
  • if the fact that the dataset is at a surface is intrinsic to the data, the qualified (constrained) standard name may be used: surface_air_pressure
#92 fixed Add oblique mercator projection davidhassell mcginnis
Description

The Oblique Mercator projection is used by at least one regional climate model, RegCM3, which is part of the NARCCAP climate modeling program. Currently we record its map projection information using the transverse_mercator projection, which I have learned is very similar but not quite the same. I propose to add this map projection so we can get it right.

Proposed text:


Oblique Mercator

grid_mapping_name = oblique_mercator

Map parameters:

  • azimuth
  • latitude_of_projection_origin
  • longitude_of_projection_origin
  • scale_factor_at_projection_origin
  • false_easting
  • false_northing

Map coordinates:

The x (abscissa) and y (ordinate) rectangular coordinates are identified by the standard_name attribute value projection_x_coordinate and projection_y_coordinate respectively.

Notes:

Notes on using the PROJ.4 software package for computing the mapping may be found at http://www.remotesensing.org/geotiff/proj_list/hotine_oblique_mercator.html . The Rotated Mercator projection is an Oblique Mercator projection with azimuth = +90.


If adding a new attribute for azimuth is problematic, this proposal could be modified to add the rotated_mercator projection instead, which is a special case of Oblique Mercator with azimuth = 90.

Note that apparently there is a subtle technical difference between an Oblique Mercator projection and a Hotine Oblique Mercator projection that depends on when the rectification from skew grid to map grid is applied. Since most mapping packages don't support a rectified grid angle parameter at all (effectively giving it a default value of 90 degrees, such that it has no effect), to avoid unnecessary proliferation of attributes I propose to omit this parameter and elide this distinction until such time as it proves necessary.

My knowledge of this topic is quite limited; I have made this proposal based on what understanding I have gleaned from the geotiff website and communications with colleagues working with our RegCM3 output in GIS. Commentary from experts would be very welcome.

#100 fixed Clarifications to the preamble of sections 4 and 5 davidhassell jonathan
Description

Dear all

I have the honour of opening ticket number 100. In this ticket, Steve Hankin and I have a number of changes to propose to the text of section 5, with the intention of clarifying it, not changing what it means. Therefore this is a defect ticket, but please object if you think it is changing the meaning, or making it any less clear!

Cheers

Jonathan

Replace this text in the first paragraph

A variable's spatiotemporal dimensions are used to locate data values in time and space. This is accomplished by associating these dimensions with the relevant set of latitude, longitude, vertical, and time coordinates.

with

A data variable's dimensions are used to locate data values in time and space or as a function of other independent variables. This is accomplished by associating these dimensions with the relevant set of latitude, longitude, vertical, time and any non-spatiotemporal coordinates.

These changes clarify that coordinate systems belong to data variables (rather than any other type of variable in a CF-netCDF file) and recognise the use of non-spatiotemporal dimensions.

Replace this text in the second paragraph

All of a variable's dimensions that are latitude, longitude, vertical, or time dimensions (see Section 1.2, "Terminology") must have corresponding coordinate variables, i.e., one-dimensional variables with the same name as the dimension

with

Any of a variable's dimensions that is an independently varying latitude, longitude, vertical, or time dimension (see Section 1.2, "Terminology") and that has a size greater than one must have a corresponding coordinate variable, i.e., a one-dimensional variable with the same name as the dimension

These changes remove the implication that spatiotemporal scalar coordinates might be prohibited, and allow for discrete axes (section 4.5, used extensively in section 9).

Replace this text in the third paragraph

All of a variable's spatiotemporal dimensions that are not latitude, longitude, vertical, or time dimensions are required to be associated with the relevant latitude, longitude, vertical, or time coordinates via the new coordinates attribute of the variable

with

Any longitude, latitude, vertical or time coordinate which depends on more than one spatiotemporal dimension must be identified by the coordinates attribute of the data variable.

This change is for clarity.

Replace this text in the fifth paragraph

The use of coordinate variables is required whenever they are applicable. That is, auxiliary coordinate variables may not be used as the only way to identify latitude and longitude coordinates that could be identified using coordinate variables.

with

If the longitude, latitude, vertical or time coordinate is multi-valued and varies in only one dimension, it is not permitted to store it as an auxiliary coordinate variable.

This change is for simplicity and clarity. The use of coordinate variables where applicable is already required by the second paragraph.

Append to the fifth paragraph

If the longitude, latitude, vertical or time coordinate is single-valued, it may be stored either as a coordinate variable with a dimension of size one, or as a scalar coordinate variable (Section 5.7).

This change recognises the use of spatiotemporal scalar coordinates.

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Note: See TracQuery for help on using queries.