Custom Query (125 matches)

There seems to be a need from the weather satellite people to add the "geos" projection to the list of projections in the CF metadata.

"geos" stands for geostationary. The projection is described in detail in the "CGMS 03, LRIT/HRIT Global specification" (Eumetsat) document. (see here also: ​http://remotesensing.org/geotiff/proj_list/geos.html )

A possible text for this projection is:

Geostationary projection

grid_mapping_name = geos

Map parameters:

latitude_of_projection_origin

longitude_of_projection_origin

perspective_point_height

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 packages for computing the

mapping may be found at ​http://www.remotesensing.org/geotiff/proj_list/geos.html . These notes assume the point of observation is directly over the equator. The projection coordinates in this projection are directly related to the scanning angle of the satellite instrument.

Currently it is not possible for multiple data variables to share an ancillary variable.

Augment the conventions to allow two or more data variables to share an ancillary variable.

Here is an example of a convention, which dovetails with the existing conventions, to provide this capability:

float swpt(lat,lon);

. .

swpt:standard_name="sea_water_potential_temperature"; swpt:ancillary_variables="nobs flags"; . .

float sws(lat,lon);

. . sws:standard_name="sea_water_salinity"; sws:ancillary_variables="nobs flags"; . .

int nobs(lat,lon);

. . nobs:standard_name="sea_water_potential_temperature sea_water_salinity number_of_observations"; . .

int flags(lat,lon);

. . flags:standard_name="sea_water_potential_temperature sea_water_salinity status_flag"; flags:flag_values = 0, 1, 2; flags:flag_meanings = "valid invalid unknown"; . .

Change the text in the CF metadata conventions section 3.3 that reads

"A standard name is associated with a variable via the attribute standard_name which takes a string value 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)."

to

"A standard name is associated with a variable via the attribute standard_name which takes a string value that can have either of two forms. The first form is a standard name alone. The second form is a blank-separated list beginning with one or more standard names and ending with a single standard name modifier (i.e. standard_name [standard_name ...] standard_name_modifier). The standard name modifiers are defined in Appendix C, Standard Name Modifiers. This second form permits a single variable to provide ancillary data (see section 3.4) for two or more variables where each has a unique standard name."

Changes to CF software tools are required. For example, the CF_checker, which validates the standard_name attribute needs to change. However, it does not require any change to software that uses the complete attribute simply as an identifying string (e.g. to label plots, etc.)

The definitions and/or documentation for 3 grid mappings cause confusion and inconsistency when translating to/from WKT.

This ticket is the result of a discussion in the mailing list: ​http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2011/027605.html .

Here is a summary of suggested changes:

1) lambert_conformal_conic

The 1SP (1 standard_parallel) case is not properly documented. There should be a link to ​http://www.remotesensing.org/geotiff/proj_list/lambert_conic_conformal_1sp.html and mention that latitude_of_projection_origin==standard_parallel (and the WKT "Scale factor at natural origin" = 1).

In the case that scale_factor is not 1, then the 2SP version should be used (as scale_factor is not part of this projection's parameters in CF).

Also, the EPSG codes should included in "Notes" (9801 for 1SP and 9802 for 2SP).

2) lambert_cylindrical_equal_area

The scale_factor_at_projection_origin variant has no WKT nor PROJ.4 equivalent (they both require standard_parallel) and there are no known examples using this variant. It should be dropped from the CF spec, or at least deprecated.

3) polar_stereographic

The 2 variants (standard_parallel or scale_factor_at_projection_origin) are not well documented.

The standard_parallel variant corresponds to EPSG Polar Stereographic (Variant B) (EPSG dataset coordinate operation method code 9829), while the scale_factor_at_projection_origin variant corresponds to EPSG Polar Stereographic (Variant A) (EPSG dataset coordinate operation method code 9810).

This information should be included in the "Map parameters" and "Notes" sections, to be consistent with other definitions such as mercator.