Inflexibility of Geostationary coordinate-systems args

[pp-mo]

#3406 added iris.coord_systems.Geostationary and netcdf read/write support for it.
However, this did not have much practical testing.

Since found a specific problem:

With a netcdf sourcefile looking like this :

netcdf geostationary_problem_case {
dimensions:
    y = 2 ;
    x = 3 ;
variables:
    short radiance(y, x) ;
        radiance:standard_name = "toa_outgoing_radiance_per_unit_wavelength" ;
        radiance:units = "W m-2 sr-1 um-1" ;
        radiance:coordinates = "y x" ;
        radiance:grid_mapping = "imager_grid_mapping" ;
    short y(y) ;
        y:units = "rad" ;
        y:axis = "Y" ;
        y:long_name = "fixed grid projection y-coordinate" ;
        y:standard_name = "projection_y_coordinate" ;
    short x(x) ;
        x:units = "rad" ;
        x:axis = "X" ;
        x:long_name = "fixed grid projection x-coordinate" ;
        x:standard_name = "projection_x_coordinate" ;
    int imager_grid_mapping ;
        imager_grid_mapping:long_name = "fixed grid projection" ;
        imager_grid_mapping:grid_mapping_name = "geostationary" ;
        imager_grid_mapping:perspective_point_height = 35786023. ;
        imager_grid_mapping:semi_major_axis = 6378137. ;
        imager_grid_mapping:semi_minor_axis = 6356752.31414 ;
        imager_grid_mapping:latitude_of_projection_origin = 0. ;
        imager_grid_mapping:longitude_of_projection_origin = -75. ;
        imager_grid_mapping:sweep_angle_axis = "x" ;
}

iris.load then fails like this :

>>> cubes = iris.load(filepath)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/h05/itpp/git/iris/iris_main/lib/iris/__init__.py", line 304, in load
    return _load_collection(uris, constraints, callback).merged().cubes()
  File "/home/h05/itpp/git/iris/iris_main/lib/iris/__init__.py", line 271, in _load_collection
    result = iris.cube._CubeFilterCollection.from_cubes(cubes, constraints)
  File "/home/h05/itpp/git/iris/iris_main/lib/iris/cube.py", line 144, in from_cubes
    for cube in cubes:
  File "/home/h05/itpp/git/iris/iris_main/lib/iris/__init__.py", line 258, in _generate_cubes
    for cube in iris.io.load_files(part_names, callback, constraints):
  File "/home/h05/itpp/git/iris/iris_main/lib/iris/io/__init__.py", line 207, in load_files
    for cube in handling_format_spec.handler(fnames, callback):
  File "/home/h05/itpp/git/iris/iris_main/lib/iris/fileformats/netcdf.py", line 788, in load_cubes
    cube = _load_cube(engine, cf, cf_var, filename)
  File "/home/h05/itpp/git/iris/iris_main/lib/iris/fileformats/netcdf.py", line 598, in _load_cube
    engine.activate(_PYKE_RULE_BASE)
  File "/tmp/persistent/miniconda3/envs/iristest_py3/lib/python3.6/site-packages/pyke/knowledge_engine.py", line 297, in activate
    for rb_name in rb_names: self.get_rb(rb_name).activate()
  File "/tmp/persistent/miniconda3/envs/iristest_py3/lib/python3.6/site-packages/pyke/rule_base.py", line 159, in activate
    self.run_fc_rules(current_rb)
  File "/tmp/persistent/miniconda3/envs/iristest_py3/lib/python3.6/site-packages/pyke/rule_base.py", line 147, in run_fc_rules
    for fc_rule in rb.fc_rules: fc_rule.run()
  File "/tmp/persistent/miniconda3/envs/iristest_py3/lib/python3.6/site-packages/pyke/fc_rule.py", line 90, in run
    self.rule_fn(self)
  File "/home/h05/itpp/git/iris/iris_main/lib/iris/fileformats/_pyke_rules/compiled_krb/fc_rules_cf_fc.py", line 223, in fc_provides_grid_mapping_geostationary
    build_geostationary_coordinate_system(engine, cf_grid_var)
  File "/home/h05/itpp/git/iris/iris_main/lib/iris/fileformats/_pyke_rules/compiled_krb/fc_rules_cf_fc.py", line 2169, in build_geostationary_coordinate_system
    false_northing, ellipsoid)
  File "/home/h05/itpp/git/iris/iris_main/lib/iris/coord_systems.py", line 771, in __init__
    self.false_easting = float(false_easting)
TypeError: float() argument must be a string or a number, not 'NoneType'
>>> 

---

"The problem" is that Geostationary provides defaults for an unspecified false_easting or false_northing, but can't handle a passed None in these arguments.

Strictly speaking, the cf conventions documentation doesn't suggest that any of the parameters can be omitted.
But that account is very incomplete, and it doesn't help if "standard" data sources have this problem, like the original NOAA-derived test data this problem was found in.

[pp-mo]

Strictly speaking, the cf conventions documentation doesn't suggest that any of the parameters can be omitted. But that account is very incomplete.

Update: it is under discussion in this CF proposal that this should be clarified, including that these parameters should be optional

[erget]

Note that making these parameters optional will not mean that they are undefined. Rather, when they are omitted they should take a default value of 0 under the current proposal. Would this be helpful for iris?

[pp-mo]

@neumannd Note that making these parameters optional will not mean that they are undefined. Rather, when they are omitted they should take a default value of 0 under the current proposal. Would this be helpful for iris?

Thanks for asking !

From a practical perspective, I don't think this makes any difference to Iris : As we already know that existing files may omit these parameters, the intended meaning is obvious, and we should support reading such files : That would still be true, even if if it were judged that this usage is not properly CF compliant.
So, updating the detail in CF clarifies the usage, but I don't think it changes our problem here or what we should be doing about it.