Inconsistent usage of false_easting and false_northing in grid mappings definitions and in examples

[neumannd]

Summary

Title

Inconsistent usage of false_easting and false_northing in grid mappings definitions and in examples

Moderator

@erget

Moderator status review

Explicit support from

• @JimBiardCics
• @marqh
• @JonathanGregory
• @erget

No objections expressed in this discussion.

SciTools/iris#3626 notes that the current inconsistency sometimes leads to problems; @erget has proposed that solving the ambiguity would at least make the intent of the Conventions clear. Impact: Software would need to be aware of the defaults.

Requirement Summary

Definitions of grid mappings / projections and their usage in examples should be consistent with respect to required attributes.

Technical Proposal Summary

As in cf-convention/discuss#225.

Add false_easting and false_northing to example 5.7 or make them optional in the definition of all projections where applicable (e.g. Lambert Conformal Conic projection).

Benefits

Consistency

Status Quo

The attributes false_easting and false_northing are required in the grid mapping variable for a Lambert Conformal Conic projection. Example 5.7 does not use false_easting and false_northing.

Detailed Proposal

Either false_easting and false_northing should be made optional in the definition of the projections (assumed to be zero if not set) or they should be added to example 5.7. I would prefer the first option as it is already the case for the attribute north_pole_grid_longitude in the grid mapping for rotated poles:

north_pole_grid_longitude - This parameter is option (default is 0).

Hence, I would suggest to replace

false_easting
false_northing

in all grid mapping definitions by

false_easting - This parameter is option (default is 0).
false_northing - This parameter is option (default is 0).

[neumannd]

Shouldn't it be "This parameter is optional (default is 0)." instead of "This parameter is option (default is 0)."? If yes, should I create another issue for it or can it be done via this one?

[erget]

@dblodgett-usgs I'd be willing to moderate this one but can't self-assign. Could you check my privileges?

[erget]

@neumannd I'm happy to moderate this and await responses from the community. IMHO the editorial correction you suggest in the second comment can be addressed in the same issue.

[JimBiardCics]

I agree that false_easting and false_northing should be made optional with assumed default values of zero.

[marqh]

hello @neumannd

I think this is sensible as well.

Given the broad support, it would be good to see a Pull Request created, with the explicit changes proposed, to enable a more detailed review and a following commit to master.

As you content to create this Pull Request and propose changes to the document yourself?

thank you
mark

[neumannd]

@marqh I will create a pull request the next days and submit it.

[JonathanGregory]

Thank you, all. I support this as well.

[erget]

PR cf-convention/discuss#225 looks OK to me. I've requested a formatting change that won't affect content in any way.

Current status looks like consensus to me and >2 committee members have expressed support. I'm starting the 3 weeks timer, after which I will merge provided that a sample file has been provided (@neumannd can you please do this?) and no objections are raised.

[neumannd]

I'm starting the 3 weeks timer, after which I will merge provided that a sample file has been provided (@neumannd can you please do this?) and [...].

@erget: Do you mean a sample netCDF file that is uses this new feature (some projection information with false_easting = 0 and false_northing = 0)?

[erget]

@neumannd yes - whereas I think it would be best if the sample data sets these values to 0 by omitting them. This is to make sure that the merge is in line with the rules for changing the Conventions:

Once the summary has been made, if the test netCDF file does not yet exist, it must be created (unless the summary suggests the proposal should be rejected).

[davidhassell]

I've just been reviewing all of the issues in advance of 1.8, and whilst I said "already merged" issues will be included (cf-convention/discuss#26), I should have said "merged by 31st January 2020". It looks like this should have passed the 3 week timer by then. The sample file isn't mandatory, and this seems like a straight forward change. Therefore I think that whilst a sample would be great, I personally would be happy merge in 8 days time (this side of February!) regardless. What do you think, @erget, @neumannd?

[neumannd]

Excuse me that I did not provide a file. I will add a file until end of this week.

[erget]

Fine by me, I'll merge this as soon as the sample file is uploaded or on 2020-01-27 at latest.

[neumannd]

@erget : Sorry for the delay. I forget to upload the files in the end of last week.

Attached a netCDF (als zip archive) and a CDL file (with txt ending).

example_file_cf_issue_212.zip
example_file_cf_issue_212.txt

[erget]

Many thanks, they're still good to have!

[davidhassell]

@erget Was there a PR associated with this? Thanks

[davidhassell]

... Sorry, I see it now (#225)