Custom Query (125 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (58 - 60 of 125)

Ticket Resolution Summary Owner Reporter
#77 fixed Add sinusoidal projection davidhassell etourigny
Description

The sinusoidal projection is used in NASA's MODIS products, and is supported by PROJ.4, Snyder and OGC WKT.

The mapping would be simple as this projection uses few existing CF projection parameters.

Proposed text :

====

Sinusoidal

grid_mapping_name = sinusoidal

Map parameters:

  • longitude_of_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 packages for computing the mapping may be found at http://www.remotesensing.org/geotiff/proj_list/sinusoidal.html. Detailed formulas can be found in [Snyder] pages 243-248.

#76 fixed More than one name in Conventions attribute davidhassell Dave.Allured
Description

Introduction

It is proposed to support the listing of more than one convention name in the Conventions global attribute. As of CF-1.6, only the CF identification by itself is allowed. The option of a list has been in Unidata's recommendations for a long time; see references. There was some community support for this in the recent mailing list discussion.

Process

I would like to present this in two parts. This trac ticket is part 1, which proposes to adopt verbatim, the Unidata language for listing more than one convention name. The original Unidata recommendation allows the list of names to be separated by either spaces or commas.

Part 2, which I plan to file as a separate ticket, would propose more detailed parsing rules and would probably replace the syntax description of part 1. The main objectives of part 2 would be to accommodate both unambiguous machine parsing, and flexibility in allowable characters in convention names.

Why two tickets? I think that part 1 has a better chance of approval. It accomplishes the most important objective of multiple conventions in a workable way. If part 2 succeeds, it can replace part 1, sooner or later.

The mailing list discussion beginning December 2011 should be considered part of the record for this proposal.

Text of proposed changes

Two new paragraphs are to be added at the end of the current section 2.6.1, Identification of Conventions:

It is possible for a netCDF file to adhere to more than one set of conventions, even when there is no inheritance relationship among the conventions. In this case, the value of the Conventions attribute may be a single text string containing a list of the convention names separated by blank space (recommended) or commas (if a convention name contains blanks). This is the Unidata recommended syntax from NetCDF Users Guide, Appendix B.

When CF is listed with other conventions, this asserts the same full compliance with CF requirements and interpretations as if CF was the sole convention. It is the responsibility of the data-writer to ensure that all common metadata is used with consistent meaning between conventions.

In the conformance document, add a new second line under 2.6.1 Identification of Conventions:

  • The Conventions attribute may be a single text string containing a list of convention names separated by blank space or commas, one of which shall be the full CF string as described above.

References

Current language of section 2.6.1, Identification of Conventions (CF-1.6)

NetCDF Users Guide, Appendix B, Attribute Conventions

List of registered conventions, NetCDF website

Ticket #27, Use namespace tags to include other conventions, 2008
(Previous proposal and discussion of Conventions attribute, not yet adopted)

#75 fixed fix documentation and definitions of 3 grid mapping definitions davidhassell etourigny
Description

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.

Note: See TracQuery for help on using queries.