Appendix F: inconsistent name for Polar stereographic map parameter

[sadielbartholomew]

Title

Appendix F: use consistent name for Polar stereographic map parameter

Moderator

<TBC>

Requirement Summary

I propose to rename the quoted parameter 'straight_vertical_longitude_from_pole' for the Polar stereographic grid mapping to 'longitude_of_projection_origin', so that it becomes consistent with the documented corresponding parameter for other grid mappings and a symmetry is formed (latitude and longitude as a pair) in the parameters quoted for that grid mapping.

Technical Proposal Summary

n/a

Benefits

I think this will make the Polar Stereographic grid mapping less confusing in relation to the other mappings (it certainly would have saved me a lot of confusion). For example (and this is how I noticed this issue, during some work towards cf-python), if one wanted to create a class hierarchy to model the recognised grid mappings including their map parameters, Azimuthal grid mappings all take certain parameters and the Polar Stereographic one having this oddly-named parameter makes inheritance from an Azimuthal base class less clean and simple.

Status Quo

I can't see any open or closed issues noting this or inquiring about it. But I am no expert in grid mappings or projections, so some expert advice would be appreciated. I might have misunderstood something important about this...

Associated pull request

n/a (at present).

Detailed Proposal

In 'Appendix F: Grid Mappings', there are a number of grid mappings corresponding to Azimuthal class projections which have a map parameter 'longitude_of_projection_origin', which in analogous to the PROJ option +lon_0 ie, "longitude of projection center" as described in the PROJ documentation. For all but one of the grid mappings in which this is a parameter, it is referred to as "longitude of projection center", such as for the Orthographic, Stereographic and Vertical perspective cases, the exception being the case of Polar Stereographic, where it is referred to by the alias 'straight_vertical_longitude_from_pole' instead.

I don't quite understand the reasons for calling the parameter this (apparently in line with the 'GeoTIFF ID' name) for this one specific case, instead of 'longitude_of_projection_origin' as it is referred to as in the named parameters for other grid mappings it applies to, especially when 'latitude_of_projection_origin' is the next parameter and there would be a natural symmetry there (for latitude and longitude as a pair) which is broken by it being referred to by this alternate name.

As I understand it, 'straight_vertical_longitude_from_pole' essentially reduces down to 'longitude_of_projection_origin' for the case of the Universal Polar Stereographic projection, so unless I am missing something here, it wouldn't be inaccurate to use this name instead. Note that the Polar Stereographic grid mapping is the only one listed under Appendix F to need the 'straight_vertical_longitude_from_pole' parameter, and cross-referencing the 'Table F.1. Grid Mapping Attributes' the descriptions are almost identical apart from in the first case to denote that the context is "to be oriented straight up from the North or South Pole":

straight_vertical_longitude_from_pole | N | The longitude (degrees_east) to be oriented straight up from the North or South Pole. Domain: -180.0 <= straight_vertical_longitude_from_pole < 180.0

longitude_of_projection_origin | N | The longitude (degrees_east) chosen as the origin of rectangular coordinates for a map projection. Domain: -180.0 <= longitude_of_projection_origin < 180.0

Therefore my proposal is to:

• rename the quoted parameter for Polar stereographic from 'straight_vertical_longitude_from_pole' to 'longitude_of_projection_origin', so that it is consistent with all other named cases of the corresponding parameter and to introduce a symmetry (through a latitude and longitude pair) in the parameters quoted for that grid mapping, perhaps keeping the present name in as an accepted alias;
• remove 'straight_vertical_longitude_from_pole' as a map parameter from the table, since it is only used for Polar Stereographic, so if it is no longer used for that grid mapping it can be deprecated I believe.

[JonathanGregory]

Dear @sadielbartholomew

Thanks for raising the issue. If I remember correctly, many of the names of these attributes were taken from the PROJ software. Perhaps it would be useful to see whether it has anything to say about this?

By the way, I note that the Snyder map projection document, which we also refer to in App F, is no longer at the URL we give in the bibliography. It is at https://pubs.er.usgs.gov/publication/pp1395, but it also has a DOI, which would be more future-proof, viz https://doi.org/10.3133/pp1395.

Best wishes

Jonathan

[dopplershift]

lon0/longitude of projection center is what I see in the PROJ docs.

[larsbarring]

I did not find my way to the documentation of old PROJ versions, but it seems to have been the same back in 2008 (PROJ4), see this email. When browsing the net (for about an hour) I only found this parameter name sort of mentioned in Section 6.2.3 of this GEOTIFF document. Probably this is the same document that @sadielbartholomew found regarding GEOTIFF ID.

And when searching the net for "straight vertical longitude from pole" (also with underscores) a few US government organizations come up (maybe not so up-to-date??). Also, a number of fairly recent ESA product documents appears high up, but those seems to be based on CF.

[sadielbartholomew]

Thanks all for your useful comments. I'll respond to them all in turn, one moment...

[sadielbartholomew]

@JonathanGregory:

By the way, I note that the Snyder map projection document, which we also refer to in App F, is no longer at the URL we give in the bibliography. It is at https://pubs.er.usgs.gov/publication/pp1395, but it also has a DOI, which would be more future-proof, viz https://doi.org/10.3133/pp1395.

Good spot, thanks. Do we need to update the link in the Conventions Document in this respect? If so, I am happy to coordinate to put up a minor PR to sort that. Either way, I managed to find my way to it via the references in the PROJ documentation, but naturally better it is clearly linked in the CF document itself.

If I remember correctly, many of the names of these attributes were taken from the PROJ software. Perhaps it would be useful to see whether it has anything to say about this?

Indeed. I've in fact been using the PROJ and pyproj documentation in parallel with the CF Conventions parts relating to Grid Mappings, and cross-referencing between all of those, as part of doing some work for cf-python (NCAS-CMS/cf-python#628 if anyone finds it useful to see what I'm doing, though note I'm doing some subsidiary work related to modelling the Grid Mappings to facilitate the work for that Issue), which is how I noted that there was this, as I see it, discrepancy with the two RE the Polar Stereographic parameters.

The particular aspect of divergence between PROJ and CF is as I will outline below in response to @dopplershift's comment, and probably the main argument I can provide to back up my proposal here, so maybe I should highlight that as a supporting comment...

[sadielbartholomew]

Thanks @dopplershift. You pick up on an important point which I believes makes the case for the proposal I am suggesting. As you link, in PROJ, both the Stereographic ("stere") projection and the (Universal) Polar Stereographic ("ups") have the parameter Longitude of projection center (+lon_0). In fact, all projections of classification Azimuthal have such a parameter in PROJ.

In the CF Appendix F, however, the only longitude referred to for the Polar Stereographic GM is this 'straight_vertical_longitude_from_pole' one which has this different name unlike for all of the other Azimuthal classification GMs under both CF and PROJ, though that parameter has the same valid domain as the Longitude of projection center (+lon_0) (see my opening comment for evidence) and it seems like it would be equivalent for the case of polar context. So I believe they amount to the same thing, but have different names in this one case.

Hence why I highlight this as an inconsistency that could potentially (and did for me) cause confusion.

With respect to object-oriented code, with an inheritance structure of:
An abstract Grid Mapping -> An abstract Azimuthal Grid Mapping -> A concrete Grid Mapping recognised by CF, of which there are 7 concrete cases, the Polar Stereographic Grid Mapping is the odd one out to not have a Longitude of projection center (+lon_0) parameter, which is I think unwieldy in a way that can be avoided (unless anyone knows of a reason it must be named differently, in this concrete GM case).

[larsbarring]

If it can established for a fact that the parameter 'straight_vertical_longitude_from_pole' is indeed the same as Longitude of projection center, which to me as non-expert seems to be the case, it would be useful to change (i.e. update to modern terminology) as is evident from @sadielbartholomew 's comments. In addition, conceptually within CF the two terms "vertical" and "longitude" does not play well together. I am not sure about the rules for changing/deprecating/aliasing a CRS parameter name, nor about possible implications for existing datasets.

[JonathanGregory]

Dear @sadielbartholomew et al.

I agree with all the arguments given for renaming the parameter, provided the old and new names refer to the same parameter (echoing Lars's proviso). Earlier I said that CF parameters have been named after PROJ, but my memory was faulty, it seems, because in a posting of 4 Oct 2006, John Caron wrote

I know that we decided to use FGDC names for projection parameters, but there doesnt seem to be any further documentation or references in the FGDC-STD-001-1998 doc to explain them. ... I would assume "straight_vertical_longitude_from_pole" = "Longitude of natural origin" but the FGDC name seems poorly chosen, whats a "vertical longitude?"

It appears from earlier emails that the decision to use FGDC parameter names was made in beta releases of the convention in 2002.

In a posting of 15 Oct 2003, I wrote

the longitude_of_natural_origin is the straight vertical longitude from the pole of the FGDC terminology.

In a posting of 16 Dec 2011, John Caron wrote

"straight_vertical_longitude_from_pole" just gives the longitude at which x = 0, as you have figured out. dunno where these names came from, no doubt historical accidents.

Does this help at all?

I don't remember whether we have renamed a grid mapping attribute before, but it doesn't strike me as problematic. We can retain the old one in App F, and say it means the same as the new one but is deprecated. In that case the CF checker will emit a warning if it finds it used, but no existing data will be invalidated.

Best wishes

Jonathan

[JonathanGregory]

Dear @sadielbartholomew

If you are willing and have time to raise a defect issue with a PR to fix the Snyder ref, that would be great. Thanks. I was thinking it could perhaps be wrapped up with this one for convenience, but maybe that's not ideal.

Best wishes

Jonathan

[dopplershift]

PyProj is currently mapping straight_vertical_longitude_from_pole to longitude_of_origin.

My MetPy project is essentially doing that (with Cartopy as the middle step).

[larsbarring]

It seems like we have convergence towards deprecating straight_vertical_longitude_from_pole in favor of longitude_of_origin. I imagine that software should do exactly as @dopplershift writes.

While we are at it, looking into the technicalities of the Polar Stereographic projection: The Notes states:

Notes on using the PROJ software package for computing the mapping may be found at https://proj.org/operations/projections/ups.html and ....

I do not think that linking to Universal Polar Stereographic is correct. This is, I believe, a special case of the Stereographic projection designed to be used with the Universal Transverse Mercator (UTM) projection. I.e. the "universal" is in reference to UTM, not to "universal" as in "general". I think, again as non-expert, that a better link would be to the documentation of the Stereographic projection, https://proj.org/en/9.2/operations/projections/stere.html

[larsbarring]

When deprecating straight_vertical_longitude_from_pole in favour of longitude_of_origin in the Conventions text, the following list of translations between different standards should be updated:
https://github.com/cf-convention/cf-conventions/wiki/Mapping-from-CF-Grid-Mapping-Attributes-to-CRS-WKT-Elements

[sadielbartholomew]

Hi all, sorry for the delay in replying, due to my taking annual leave.

Some interesting points have been made since I last commented. I am glad that there seems to be a consensus towards making a change, though I would like to emphasise first that I think it is much better to, as per my original suggestion:

rename the quoted parameter for Polar stereographic from 'straight_vertical_longitude_from_pole' to 'longitude_of_projection_origin',

rather than:

in favour of longitude_of_origin

as the latest comments are suggesting (specifically, the same but without projection_), since although similar the former new name would be consistent with the precise name used for the other Grid Mappings corresponding to Azimuthal projections as supported in the CF Conventions presently. With the latter name, it would be more useful a name but still remain inconsistent, so my original issue wouldn't be resolved.

[sadielbartholomew]

I do not think that linking to Universal Polar Stereographic is correct. This is, I believe, a special case of the Stereographic projection designed to be used with the Universal Transverse Mercator (UTM) projection. I.e. the "universal" is in reference to UTM, not to "universal" as in "general". I think, again as non-expert, that a better link would be to the documentation of the Stereographic projection, https://proj.org/en/9.2/operations/projections/stere.html

Thanks Lars, I wasn't aware of this. Though we already have the Stereographic GM linking to the PROJ stere projection which you suggest as a more appropriate PROJ projection link. Wouldn't that then support that the 'Polar stereographic' projection is a special case of a Stereographic one? That would actually make sense on the surface, since with the change I am suggesting here to one map parameter in place, the two GMs would then have identical map parameters. And if it is the case it is just a special case, then couldn't we even deprecate the whole GM of 'Polar Stereographic' and subsume it into the existing 'Stereographic' GM, documenting clearly that the former is a case of the latter so that anyone thinking of the former knows to make use of the latter?

But equally, I am not an expert in this, so getting the opinion(s) of those who do know much more about Grid Mappings, projections, and the likes would be really useful...

[larsbarring]

Digging as bit deeper it seems that my unauthoritative conjecture regarding UPS being connected to UTM seems to be corroborated by Snyder, who under the heading "UNIVERSAL TRANSVERSE MERCATOR PROJECTION" (p.57) writes on p.58:

"From lat. 84" N. and 80° S. to the respective poles, the Universal Polar Stereographic (UPS) projection is used instead."

Further down, when describing the stereographic projection, he writes (p.157):

The Universal Transverse Mercator (UTM) grid employs the UPS (Universal Polar Stereographic) projection from the North Pole to lat. 84° N., and from the South Pole to lat. 80° S. For the UPS, the scale at each pole is reduced to 0. 994, resulting in a standard parallel of 81 °06' 52.3" N. or S.

which means that +k_0 is fixed at 0.994, which corresponds to a latitude of true scale of either 81° 06' 52.3" N. or S., i.e lat_ts = 81.1145278°

This table may give a better overview of how the projections we are discussing compare in terms of parameter specification:

CF -- polar_stereographic	proj -- ups	proj -- stere
straight_vertical_longitude_from_pole (name to be changed)	+lon_0 (defaults to 0.0)	+lon_0 (defaults to 0.0)
latitude_of_projection_origin (either +90. or -90.)	Default is +90.0 +south gives -90.0	+lat_0 (defaults to 0.0)
Either standard_parallel (EPSG 9829) or scale_factor_at_projection_origin (EPSG 9810)	N/A +k_0 is fixed at 0.994 which is equivalent to +lat_ts = 81.11452777777777° N or S	+lat_ts or +k_0
false_easting (this parameter is optional (default is 0))	+x_0 (defaults to 0.0)	+x_0 (defaults to 0.0)
false_northing (this parameter is optional (default is 0))	+y_0 (defaults to 0.0)	+y_0 (defaults to 0.0)
N/A	+ellps	+ellps
N/A	+R	+R

As is shown in the table neither of the proj alternatives are fully equivalent to the CF polar_stereographic projection. But the proj stere alternative at least allows one to find a general translation, which is not possible for proj ups

[larsbarring]

@sadielbartholomew writes;

Though we already have the Stereographic GM linking to the PROJ stere projection which you suggest as a more appropriate PROJ projection link. Wouldn't that then support that the 'Polar stereographic' projection is a special case of a Stereographic one?

Yes, that is my understanding, too.

Then she continues:

That would actually make sense on the surface, since with the change I am suggesting here to one map parameter in place, the two GMs would then have identical map parameters.

This would indeed be a good outcome of this discussion.

And further:

And if it is the case it is just a special case, then couldn't we even deprecate the whole GM of 'Polar Stereographic' and subsume it into the existing 'Stereographic' GM, documenting clearly that the former is a case of the latter so that anyone thinking of the former knows to make use of the latter?

Well, I do not think so because Polar Stereographic is a well established and widely known name/label/concept for a specific projection. Similarly, we have the Oblique Mercator as the general case with the two special cases Mercator and Transverse Mercator. All these map projection names are commonplace, which means that it is helpful to have them in Appendix F, so I do not think that deprecating polar_stereographicto just be mentioned under stereographic is going in the right direction.

It seems that we are in agreement to change the name of the attribute to longitude_of_projection_origin as you suggested, and to replace the proj link to point to the "stereographic projection". Would you @sadielbartholomew be able to put together a pull request?

[larsbarring]

I just came across the initial section of Appendix F, which states

We have used the FGDC "Content Standard for Digital Geospatial Metadata" [FGDC] as a guide in choosing the values for grid_mapping_name and the attribute names for the parameters describing map projections.

When (if ...) we are implementing the attribute name change as @sadielbartholomew suggests this piece of text should maybe be updated, e.g.:

{With few exceptions we | In general we} have used the FGDC "Content Standard for Digital Geospatial Metadata" [FGDC] as a guide in choosing the values for grid_mapping_name and the attribute names for the parameters describing map projections.

[sadielbartholomew]

Thanks @larsbarring and sorry for the slow reply to your new comments. Admittedly the Issue here fell off my radar, I think I must have accidentally dismissed it on my GitHub notifications.

Thanks firstly for your research and clarifications about the Polar Stereographic grid mapping.

All these map projection names are commonplace, which means that it is helpful to have them in Appendix F, so I do not think that deprecating polar_stereographicto just be mentioned under stereographic is going in the right direction.

Fair enough. Your explanation make sense, so I am happy to retract the idea to change that and leave it as-is in that respect. Thanks.

When (if ...) we are implementing the attribute name change as @sadielbartholomew suggests this piece of text should maybe be updated

Good spot (I did notice that text during writing my proposal). That sounds like a good idea, to me, assuming we go ahead with my proposal. It would be sensible, and accurate, to include this update.

It seems that we are in agreement to change the name of the attribute to longitude_of_projection_origin as you suggested, and to replace the proj link to point to the "stereographic projection". Would you @sadielbartholomew be able to put together a pull request?

Yes, I am more than happy to put together a PR for this.

To confirm, do we think this proposal is at a stage where it is likely to be approved, and therefore it isn't likely for it to end up being a waste of time if I create the corresponding PR very soon? If not, I'll wait to check we have consensus (I'll wait a few days at least, anyway, for a chance for anyone to add anything first). Anyone with immediate comments against the current idea, please do comment ASAP!

A related question is, do we need and have a moderator for this thread, since I believe an issue is meant to be assigned one?

[larsbarring]

When briefly looking through the comments I do not see any diverging views, rather the opposite regarding changing the name of the attribute. And there are no direct comments at all (except for the one from you) regarding changing the proj link from UPS to STERE, which is uncontroversial given the parameters and their values as detailed in the table.

Thus, I do not think that a moderator is essential at this stage, but it would be good to have approval from one or a few more (ping @dblodgett-usgs, @davidhassell)

[JonathanGregory]

Dear @sadielbartholomew

I agree with Lars that this isn't controversial, so a moderator is not needed at the moment. If you could restate in this issue explicitly what you are now proposing, that will serve as a summary. If enough support is expressed and no concerns, we'll count it as accepted in three weeks, according to the usual rule. It's fine to do the PR after that, having already set out what changes it will make.

Best wishes and thanks

Jonathan

[sadielbartholomew]

Thanks @larsbarring and @JonathanGregory for your guidance. And everyone for the discussion so far.

If you could restate in this issue explicitly what you are now proposing, that will serve as a summary.

Sounds wise at this stage. Here goes...

---

Present proposal, incorporating ideas and feedback from the thread above (and edited to include points from a later comment, #445 (comment) and a correction from #445 (comment))

This discussion has converged (I think) so that we are proposing seven updates to the Conventions, all relating to the Polar Stereographic Grid Mapping. Namely, for the Polar stereographic grid mapping:

1. Rename the quoted parameter straight_vertical_longitude_from_pole to longitude_of_projection_origin. Reasons this would be a good change include:
   • For consistency: for all other Grid Mappings listed as supported by CF in Appendix F, in which this (analogous to the PROJ option +lon_0 ie, "longitude of projection center" as described in the PROJ documentation) is a parameter, it is referred to as "longitude of projection center", such as for the Orthographic, Stereographic and Vertical perspective cases.
   • To remove unnecessary specificity: 'straight_vertical_longitude_from_pole' essentially reduces down to 'longitude_of_projection_origin' for the case of the Universal Polar Stereographic projection and the Polar Stereographic grid mapping is the only one listed under Appendix F to need the 'straight_vertical_longitude_from_pole' parameter.
   • PyProj and MetPy are both currently making a similar mapping, specifically from straight_vertical_longitude_from_pole to longitude_of_origin., but throughout the CF Grid Mappings we use 'longitude_of_projection_origin', so we should be consistent and choose that.
2. Therefore deprecate the old parameter name, straight_vertical_longitude_from_pole, by (quote from Appendix F: inconsistent name for Polar stereographic map parameter #445 (comment)):

retain the old one in App F, and say it means the same as the new one but is deprecated. In that case the CF checker will emit a warning if it finds it used, but no existing data will be invalidated.

3. And, since the Polar Stereographic grid mapping was the only one listed under Appendix F to need the straight_vertical_longitude_from_pole parameter, we can remove it as a parameter from the table 'Table F.1. Grid Mapping Attributes'.
4. Since this parameter change would make an existing statement in the initial section of Appendix F inaccurate, update it as suggested in Appendix F: inconsistent name for Polar stereographic map parameter #445 (comment) by @larsbarring.
5. As a separate but related issue brought up during the thread, as suggested also by @larsbarring in Appendix F: inconsistent name for Polar stereographic map parameter #445 (comment), and motivated in Appendix F: inconsistent name for Polar stereographic map parameter #445 (comment), change the PROJ projection link from 'linking to Universal Polar Stereographic' to 'Stereographic' which is more appropriate.
6. Given point 2, the conformance.adoc needs to be updated to include a specific rule to ensure the cf-checker raising a warning, as Lars raises in Appendix F: inconsistent name for Polar stereographic map parameter #445 (comment).
7. Finally, the wiki document needs a small update, as Lars points out in Appendix F: inconsistent name for Polar stereographic map parameter #445 (comment).

I welcome further thoughts on the above. Maybe we can work with the numbering I have assigned here, to help us refer to the specific proposed update of concern?

---

[larsbarring]

This looks good to me!

Two minor points:

• Regarding your second point (cf-checker raising a warning), I think that also the conformance.adoc needs to be updated to include a specific rule.
• Also the wiki document needs a small update (cf my earlier comment)

[JonathanGregory]

Dear @sadielbartholomew

Thanks for this clear summary. I support the proposal and I don't have any concerns. In point 1b, do you mean 'longitude_of_projection_origin'? Lars is right that point 2 requires a new recommendation in the conformance document.

Best wishes

Jonathan

[sadielbartholomew]

Thanks again, both. I will correct my proposal above, via edit (without changing anything else, though the visible comment edit history should confirm this if you want to see what's changed to re-review) to:

• add in the two minor points made by Lars, so we have 7 points (up from 5) covering the various related updates required; and
• correct to 'latitude_of_projection_origin' to 'longitude_of_projection_origin' as per Jonathan's observation (good spot, thanks).

Then it should be up-to-date. And it seems as well as my (obvious) support for this, Lars and Jonathan are in support, therefore we have three people backing the proposal. So we now wait for any further comments, I believe (all of which are very welcome, naturally)...

[sadielbartholomew]

Edits all one! Thanks all. Awaiting any further thoughts on this.

Newcomers to the thread, or those who aren't up-to-date: please see my summary in #445 (comment) which states where we are at with our precise proposal, at present.

[JonathanGregory]

Thanks, @sadielbartholomew. If there are no new concerns raised, this proposal will be accepted in three weeks (9th Oct).

[larsbarring]

As there has been no further comments regarding this proposal, could you @sadielbartholomew put together a PR implementing the changes detailed in your excellent summary of this issue.

[sadielbartholomew]

Thanks @larsbarring. Yes of course, I can and will prepare and open a PR to implement this all and link it to this Issue. I might not get time to do that until next week, but I will try to do it by then at the latest.

[sadielbartholomew]

Hi all, just FYI I have been busy with other work lately but I am committing to putting up a PR for this by the end of this working week, so that there is enough time to review it for (hopeful, eventual) merging in time for the release of CF 1.11.

[larsbarring]

A small comment regarding Table F.1 in the PR: Because there are a number of published datasets using straight_vertical_longitude_from_pole we should probably not delete it from the table. How about something like one of these suggestions:

Attribute	Type	Description
straight_vertical_longitude_from_pole	N	Deprecated, instead use latitude_of_projection_origin which has the same meaning
straight_vertical_longitude_from_pole	N	Deprecated. Instead use latitude_of_projection_origin which has the same meaning

[davidhassell]

I agree with Lars, keeping it in the table seems prudent. I prefer the first option, but would like to suggest an alternative wording:

Attribute	Type	Description
straight_vertical_longitude_from_pole	N	Deprecated. Has the same meaning as latitude_of_projection_origin, which has must be used instead.

(I used "must" because a BCP14 SHOULD would still allow the deprecated parameter to be used in some circumstances - we don't want that, right?)

Thanks,
David

[sadielbartholomew]

OK, thanks @larsbarring and @davidhassell: I will update my PR to amend point (3) from my summary, specifically to not remove straight_vertical_longitude_from_pole from Table F.1 but instead indicate its deprecation via a message as suggested. I am happy to go with David's preference of Lars' suggestion, namely:

Deprecated. Has the same meaning as latitude_of_projection_origin, which has must be used instead.

removing the 'has' (typo left in, it seems). Good thinking David to consider BCP14!

[JonathanGregory]

Dear @sadielbartholomew

Regarding your question on the PR, Yes, please add yourself as a contributing author, because this is a material change to the conventions.

I don't think straight_vertical_longitude_from_pole should be deleted in Table F1. It is being deprecated, but not abolished.

Best wishes

Jonathan

[sadielbartholomew]

OK, thanks Jonathan and all. Sounds like we have agreement RE Table F.1. I'm updating the PR now.

Regarding your question on the PR, Yes, please add yourself as a contributing author, because this is a material change to the conventions.

Great, will do. Thanks for clarifying.

[sadielbartholomew]

As for the precise message for Table F.1, I am going with:

"Deprecated. Has the same meaning as longitude_of_projection_origin, which must be used instead."

with the important update of latitude -> longitude from the suggestions above which obviously folk meant to refer instead to! 🙂

[larsbarring]

Ops -- of course I did ....🙂

[larsbarring]

If there are no further comments to this proposal (cf #469) it can be accepted in three weeks time counting from November 2, which means on November 24.