fix documentation and definitions of 3 grid mapping definitions

[etourigny]

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.

[etourigny]

I would like to prepare addditional documentation on how to relate the CF parameters to PROJ.4 an WKT parameters, should this be in a wiki entry?

Here are proposed changes to the conventions document (Appendix F. Grid Mappings):

1) lambert_conformal_conic

Notes:

Notes on using the PROJ.4 software package for computing the mapping may be found at ​http://www.remotesensing.org/geotiff/proj_list/lambert_conic_conformal_1sp.html ("Lambert Conic Conformal (1SP)" or EPSG 9801) or ​http://www.remotesensing.org/geotiff/proj_list/lambert_conic_conformal_2sp.html ("Lambert Conic Conformal (2SP)" or EPSG 9802). For the 1SP variant, latitude_of_projection_origin=standard_parallel and the PROJ.4 scale factor is 1.

2) lambert_cylindrical_equal_area

Map parameters:

- longitude_of_central_meridian
- standard_parallel
...

OR:

Map parameters:

- longitude_of_central_meridian
- standard_parallel or scale_factor_at_projection_origin (deprecated)
...

3) polar_stereographic

Map parameters:

...
- Either standard_parallel (EPSG 9829) or scale_factor_at_projection_origin (EPSG 9810)
...

Notes:

Notes on using the PROJ.4 software package for computing the mapping may be found at ​http://www.remotesensing.org/geotiff/proj_list/polar_stereographic.html.

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). As PROJ.4 requires the standard parallel, [Snyder] formula 21-7 can be used to compute it from the scale factor if needed.

[markh]

Replying to etourigny:

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

I agree that this needs addressing

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).

The notes are useful clarification. I do wonder whether the two separate approaches lend themselves to two different grid_mappings, rather than one, with two options about how to define SP and conditional behaviour for scale_factor

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

I thought that EPSG codes referred to specific instances of projections, not projection definitions. Is the intention of this inclusion that a specific projection instance is referenced?

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.

I agree, this attribute should be deprecated or preferably dropped. I have not found a way of interpreting this attribute in the context of a Lambert Cylindrical Projection.

The definition implies one or other is required. Is this change suggesting that standard_parallel is essential for such a grid_mapping?

If so, is there a usable default value that could be included?

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.

I am not clear what information you propose to add here. Neither of these options is referenced in the ​link within the specification, that I can see.

The wording suggests that I must supply one or other with my grid_mapping definition

I think a statement of how this grid_mapping may be defined would be helpful to review. I am not convinced that adding the note you provided gives us enough for this definition.

[etourigny]

Replying to markh:

Replying to etourigny:

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

I agree that this needs addressing

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).

The notes are useful clarification. I do wonder whether the two separate approaches lend themselves to two different grid_mappings, rather than one, with two options about how to define SP and conditional behaviour for scale_factor

It might be clearer but more disruptive.

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

I thought that EPSG codes referred to specific instances of projections, not projection definitions. Is the intention of this inclusion that a specific projection instance is referenced?

There are other grid_mapping definitions that refer to EPSG coordinate operation method codes (e.g. lambert_cylindrical_equal_area, mercator).

The EPSG codes you are referring to are projected coordinate system definitions (such as 32722 which is a specific Transverse_Mercator projection with central_meridian=51)

The EPSG coordinate operation method codes are defined in the EPSG Guidance Note 7-1

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.

I agree, this attribute should be deprecated or preferably dropped. I have not found a way of interpreting this attribute in the context of a Lambert Cylindrical Projection.

The definition implies one or other is required. Is this change suggesting that standard_parallel is essential for such a grid_mapping?

Looking more closely, in Snyder pp. 79-80 for the transverse and oblique aspects

the scale factor (normally 1) is used instead of standard parallel. But it seems that proj4 and OGR do not support that. I don't know if one could or if it makes sense to calculate one from the other.

So perhaps it should remain but with a note (in the "Notes") section :

"The scale_factor_at_projection_origin variant is used for the transverse and oblique aspects"

If so, is there a usable default value that could be included?

scale factor default to 1,

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.

I am not clear what information you propose to add here. Neither of these options is referenced in the ​link within the specification, that I can see.

The wording suggests that I must supply one or other with my grid_mapping definition

I think a statement of how this grid_mapping may be defined would be helpful to review. I am not convinced that adding the note you provided gives us enough for this definition.

The link uses only EPSG 9810 (the scale_factor_at_projection_origin variant). I got the other from the EPSG Guidance Note 7-1

Have you read my first comment with proposed changes to the document? The full proposed modification are below (the formatting was wrong). I think they address your concerns as the 2 alternatives are related to EPSG coordinate operation method codes and I give the reference to pass from one to the other.

The choice of using one or the other depends on which one is readily available, I just added this to clarify why you can use one or the other.

What do you mean exactly by "a statement of how this grid_mapping may be defined" ?

Map parameters:

...
- Either standard_parallel (EPSG 9829) or scale_factor_at_projection_origin (EPSG 9810)
...

Notes:

Notes on using the PROJ.4 software package for computing the mapping may be found at http://www.remotesensing.org/geotiff/proj_list/polar_stereographic.html.

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). As PROJ.4 requires the standard parallel, [Snyder] formula 21-7 can be used to compute it from the scale factor if needed.

[markh]

Replying to etourigny:

Apologies for the lag in response to this, I should have responded to this months ago to indicate that I am happy with the responses provided and that I support this ticket moving to be concluded, but there are a couple of minor clarifications required: Further comments are in line.

Replying to markh:

Replying to etourigny:

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

I agree that this needs addressing

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).

The notes are useful clarification. I do wonder whether the two separate approaches lend themselves to two different grid_mappings, rather than one, with two options about how to define SP and conditional behaviour for scale_factor

It might be clearer but more disruptive.

I think avoiding disruption at the price of clarity is a shame, but in this case, a price that we should just choose to pay.

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

I thought that EPSG codes referred to specific instances of projections, not projection definitions. Is the intention of this inclusion that a specific projection instance is referenced?

There are other grid_mapping definitions that refer to EPSG coordinate operation method codes (e.g. lambert_cylindrical_equal_area, mercator).

The EPSG codes you are referring to are projected coordinate system definitions (such as 32722 which is a specific Transverse_Mercator projection with central_meridian=51)

The EPSG coordinate operation method codes are defined in the EPSG Guidance Note 7-1

ok, this makes sense.

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.

I agree, this attribute should be deprecated or preferably dropped. I have not found a way of interpreting this attribute in the context of a Lambert Cylindrical Projection.

The definition implies one or other is required. Is this change suggesting that standard_parallel is essential for such a grid_mapping?

Looking more closely, in Snyder pp. 79-80 for the transverse and oblique aspects

the scale factor (normally 1) is used instead of standard parallel. But it seems that proj4 and OGR do not support that. I don't know if one could or if it makes sense to calculate one from the other.

So perhaps it should remain but with a note (in the "Notes") section :

"The scale_factor_at_projection_origin variant is used for the transverse and oblique aspects"

if the software we use cannot interpret it, I question its usefulness. I don't think this should be included unless we have good reason to and we understand how to interpret it.

If so, is there a usable default value that could be included?

scale factor default to 1,

ok

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.

I am not clear what information you propose to add here. Neither of these options is referenced in the ​link within the specification, that I can see.

The wording suggests that I must supply one or other with my grid_mapping definition

I think a statement of how this grid_mapping may be defined would be helpful to review. I am not convinced that adding the note you provided gives us enough for this definition.

The link uses only EPSG 9810 (the scale_factor_at_projection_origin variant). I got the other from the EPSG Guidance Note 7-1

Have you read my first comment with proposed changes to the document? The full proposed modification are below (the formatting was wrong). I think they address your concerns as the 2 alternatives are related to EPSG coordinate operation method codes and I give the reference to pass from one to the other.

The choice of using one or the other depends on which one is readily available, I just added this to clarify why you can use one or the other.

this looks good

What do you mean exactly by "a statement of how this grid_mapping may be defined" ?

I think the revised note provides enough information for the data producer to properly define their grid_mapping variable.

Map parameters:

...
- Either standard_parallel (EPSG 9829) or scale_factor_at_projection_origin (EPSG 9810)
...

Notes:

Notes on using the PROJ.4 software package for computing the mapping may be found at http://www.remotesensing.org/geotiff/proj_list/polar_stereographic.html.

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). As PROJ.4 requires the standard parallel, [Snyder] formula 21-7 can be used to compute it from the scale factor if needed.

[etourigny]

Replying to markh:

Replying to etourigny:

Apologies for the lag in response to this, I should have responded to this months ago to indicate that I am happy with the responses provided and that I support this ticket moving to be concluded, but there are a couple of minor clarifications required: Further comments are in line.

Sorry I didn't respond sooner also, I thought I had!

Replying to markh:

Replying to etourigny:

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

I agree that this needs addressing

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).

The notes are useful clarification. I do wonder whether the two separate approaches lend themselves to two different grid_mappings, rather than one, with two options about how to define SP and conditional behaviour for scale_factor

It might be clearer but more disruptive.

I think avoiding disruption at the price of clarity is a shame, but in this case, a price that we should just choose to pay.

On one side, this is in line with other conventions/software which separate the 1SP and 2SP in different definitions. In the case of Mercator, EPSG and OGC also have 2 definitions, but they are functionally equivalent.

However, how to deal with backwards-compatibility and which names should be used for the two variants in CF? I see a high potential for disruption here. I still think it would be simpler to just amend the docs as I proposed, which would remove these two problem.

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

I thought that EPSG codes referred to specific instances of projections, not projection definitions. Is the intention of this inclusion that a specific projection instance is referenced?

There are other grid_mapping definitions that refer to EPSG coordinate operation method codes (e.g. lambert_cylindrical_equal_area, mercator).

The EPSG codes you are referring to are projected coordinate system definitions (such as 32722 which is a specific Transverse_Mercator projection with central_meridian=51)

The EPSG coordinate operation method codes are defined in the EPSG Guidance Note 7-1

ok, this makes sense.

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.

I agree, this attribute should be deprecated or preferably dropped. I have not found a way of interpreting this attribute in the context of a Lambert Cylindrical Projection.

The definition implies one or other is required. Is this change suggesting that standard_parallel is essential for such a grid_mapping?

Looking more closely, in Snyder pp. 79-80 for the transverse and oblique aspects

the scale factor (normally 1) is used instead of standard parallel. But it seems that proj4 and OGR do not support that. I don't know if one could or if it makes sense to calculate one from the other.

So perhaps it should remain but with a note (in the "Notes") section :

"The scale_factor_at_projection_origin variant is used for the transverse and oblique aspects"

if the software we use cannot interpret it, I question its usefulness. I don't think this should be included unless we have good reason to and we understand how to interpret it.

I'm not sure I understand - your opinion is that this change should not be included, or that the scale_factor_at_projection_origin variant should not be included?

If your answer is the former here is my answer:

Proj.4 is quite a good software, and it's referenced pretty much in all the projections...

I merely included this for clarity. The current CF spec is vague about why you would use standard_parallel or scale_factor_at_projection_origin and this should be clarified.

If so, is there a usable default value that could be included?

scale factor default to 1,

ok

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.

I am not clear what information you propose to add here. Neither of these options is referenced in the ​link within the specification, that I can see.

The wording suggests that I must supply one or other with my grid_mapping definition

I think a statement of how this grid_mapping may be defined would be helpful to review. I am not convinced that adding the note you provided gives us enough for this definition.

The link uses only EPSG 9810 (the scale_factor_at_projection_origin variant). I got the other from the EPSG Guidance Note 7-1

Have you read my first comment with proposed changes to the document? The full proposed modification are below (the formatting was wrong). I think they address your concerns as the 2 alternatives are related to EPSG coordinate operation method codes and I give the reference to pass from one to the other.

The choice of using one or the other depends on which one is readily available, I just added this to clarify why you can use one or the other.

this looks good

What do you mean exactly by "a statement of how this grid_mapping may be defined" ?

I think the revised note provides enough information for the data producer to properly define their grid_mapping variable.

Map parameters:

...
- Either standard_parallel (EPSG 9829) or scale_factor_at_projection_origin (EPSG 9810)
...

Notes:

Notes on using the PROJ.4 software package for computing the mapping may be found at http://www.remotesensing.org/geotiff/proj_list/polar_stereographic.html.

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). As PROJ.4 requires the standard parallel, [Snyder] formula 21-7 can be used to compute it from the scale factor if needed.

[markh]

tl;dr

I support this proposal

Replying to etourigny:

Replying to markh:

Replying to etourigny:

On one side, this is in line with other conventions/software which separate the 1SP and 2SP in different definitions. In the case of Mercator, EPSG and OGC also have 2 definitions, but they are functionally equivalent.

However, how to deal with backwards-compatibility and which names should be used for the two variants in CF? I see a high potential for disruption here. I still think it would be simpler to just amend the docs as I proposed, which would remove these two problem.

agreed

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.

I agree, this attribute should be deprecated or preferably dropped. I have not found a way of interpreting this attribute in the context of a Lambert Cylindrical Projection.

The definition implies one or other is required. Is this change suggesting that standard_parallel is essential for such a grid_mapping?

Looking more closely, in Snyder pp. 79-80 for the transverse and oblique aspects

the scale factor (normally 1) is used instead of standard parallel. But it seems that proj4 and OGR do not support that. I don't know if one could or if it makes sense to calculate one from the other.

So perhaps it should remain but with a note (in the "Notes") section :

"The scale_factor_at_projection_origin variant is used for the transverse and oblique aspects"

if the software we use cannot interpret it, I question its usefulness. I don't think this should be included unless we have good reason to and we understand how to interpret it.

I'm not sure I understand - your opinion is that this change should not be included, or that the scale_factor_at_projection_origin variant should not be included?

If your answer is the former here is my answer:

Proj.4 is quite a good software, and it's referenced pretty much in all the projections...

I merely included this for clarity. The current CF spec is vague about why you would use standard_parallel or scale_factor_at_projection_origin and this should be clarified.

apologies for my lack of clarity. I agree with your assessment of Proj4, my concern is allowing a parameterisation which is not supported by our primary software tools such as proj4 and OGR.

My preference would be that:

the scale_factor_at_projection_origin variant should not be included

but that the rest of the change should be included as described here.

However I am not so strongly of this view that I want to hold up this ticket any further. If including the scale_factor_at_projection_origin variant is helpful in your view, then I think it can be managed, but I am struggling to see it's usefulness if the libraries I know of do not interpret it.

[etourigny]

Replying to markh:

tl;dr

I support this proposal

Replying to etourigny:

Replying to markh:

Replying to etourigny:

On one side, this is in line with other conventions/software which separate the 1SP and 2SP in different definitions. In the case of Mercator, EPSG and OGC also have 2 definitions, but they are functionally equivalent.

However, how to deal with backwards-compatibility and which names should be used for the two variants in CF? I see a high potential for disruption here. I still think it would be simpler to just amend the docs as I proposed, which would remove these two problem.

agreed

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.

I agree, this attribute should be deprecated or preferably dropped. I have not found a way of interpreting this attribute in the context of a Lambert Cylindrical Projection.

The definition implies one or other is required. Is this change suggesting that standard_parallel is essential for such a grid_mapping?

Looking more closely, in Snyder pp. 79-80 for the transverse and oblique aspects

the scale factor (normally 1) is used instead of standard parallel. But it seems that proj4 and OGR do not support that. I don't know if one could or if it makes sense to calculate one from the other.

So perhaps it should remain but with a note (in the "Notes") section :

"The scale_factor_at_projection_origin variant is used for the transverse and oblique aspects"

if the software we use cannot interpret it, I question its usefulness. I don't think this should be included unless we have good reason to and we understand how to interpret it.

I'm not sure I understand - your opinion is that this change should not be included, or that the scale_factor_at_projection_origin variant should not be included?

If your answer is the former here is my answer:

Proj.4 is quite a good software, and it's referenced pretty much in all the projections...

I merely included this for clarity. The current CF spec is vague about why you would use standard_parallel or scale_factor_at_projection_origin and this should be clarified.

apologies for my lack of clarity. I agree with your assessment of Proj4, my concern is allowing a parameterisation which is not supported by our primary software tools such as proj4 and OGR.

My preference would be that:

the scale_factor_at_projection_origin variant should not be included

but that the rest of the change should be included as described here.

However I am not so strongly of this view that I want to hold up this ticket any further. If including the scale_factor_at_projection_origin variant is helpful in your view, then I think it can be managed, but I am struggling to see it's usefulness if the libraries I know of do not interpret it.

It would be nice to have John Caron's opinion about this. From his response in ​http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2011/049568.html he seems to find it important to keep it.

snyder 21-7 gives the formula for the scale factor, which can easily be 
inverted to derive the "standard_parallel" which i think just means the 
latitude at which the scale factor = 1. Thats why in CF you give one or 
the other.  so my guess is that the OGC is specifying redundant info.

GRIB-1 has "Grid lengths are in units of metres, at the 60-degree 
parallel nearest to the pole on the projection plane." If one uses 21-7 
to compute the scale factor at the pole that makes scale factor = 1 at 
60 degress, one gets 0.9330127018922193. use this for GRIB-1 GDS=5, and 
lo! the pictures look correct. GRIB-2 allows the user to specify and 
wowwa! they often have 0.933.

In any case, even though Proj.4 does not support that variant, [Snyder] formula 21-7 allows to calculate it. I have included that in my provisional gdal netcdf driver code.

[markh]

Replying to etourigny:

In any case, even though Proj.4 does not support that variant, [Snyder] formula 21-7 allows to calculate it. I have included that in my provisional gdal netcdf driver code.

OK, let us accept it's potential use and work with it.

You have my support for this propsal and all it's details

mark

[jonathan]

Thanks for indicating you are content with this defect ticket, Mark. The ticket will be accepted by default on 9 August if no-one objects before then. Jonathan