Abi l2 nc reader can't handle AOD product

[mraspaud]

Describe the bug
The ABI l2 nc reader lists AOD in the yaml configuration, but actually trying to create a filehandler for it fails.

To Reproduce

# Your code here
from satpy import Scene
filenames = ["simplecache::https://noaa-goes16.s3.amazonaws.com/ABI-L2-AODC/2022/002/02/OR_ABI-L2-AODC-M6_G16_s20220020206173_e20220020208546_c20220020210191.nc"]
scn = Scene(filenames=filenames, reader='abi_l2_nc')

Expected behavior
I would expect the scene to be created

Actual results

Traceback (most recent call last):
  File "/home/a001673/usr/src/spy-test/test_abi_l2.py", line 15, in <module>
    scn = Scene(filenames=filenames, reader='abi_l2_nc')
  File "/home/a001673/usr/src/satpy/satpy/scene.py", line 133, in __init__
    self._readers = self._create_reader_instances(filenames=filenames,
  File "/home/a001673/usr/src/satpy/satpy/scene.py", line 154, in _create_reader_instances
    return load_readers(filenames=filenames,
  File "/home/a001673/usr/src/satpy/satpy/readers/__init__.py", line 570, in load_readers
    reader_instance.create_filehandlers(
  File "/home/a001673/usr/src/satpy/satpy/readers/yaml_reader.py", line 612, in create_filehandlers
    filehandlers = self._new_filehandlers_for_filetype(filetype_info,
  File "/home/a001673/usr/src/satpy/satpy/readers/yaml_reader.py", line 600, in _new_filehandlers_for_filetype
    return list(filtered_iter)
  File "/home/a001673/usr/src/satpy/satpy/readers/yaml_reader.py", line 568, in filter_fh_by_metadata
    for filehandler in filehandlers:
  File "/home/a001673/usr/src/satpy/satpy/readers/yaml_reader.py", line 509, in _new_filehandler_instances
    yield filetype_cls(filename, filename_info, filetype_info, *req_fh, **fh_kwargs)
  File "/home/a001673/usr/src/satpy/satpy/readers/abi_base.py", line 52, in __init__
    self.nlines = self.nc['y'].size
  File "/home/a001673/mambaforge/envs/satpy/lib/python3.10/functools.py", line 981, in __get__
    val = self.func(instance)
  File "/home/a001673/usr/src/satpy/satpy/readers/abi_base.py", line 71, in nc
    nc = self._rename_dims(nc)
  File "/home/a001673/usr/src/satpy/satpy/readers/abi_base.py", line 79, in _rename_dims
    nc = nc.rename({'lon': 'x', 'lat': 'y'})
  File "/home/a001673/mambaforge/envs/satpy/lib/python3.10/site-packages/xarray/core/dataset.py", line 3393, in rename
    raise ValueError(
ValueError: cannot rename 'lon' because it is not a variable or dimension in this dataset

Screenshots
If applicable, add screenshots to help explain your problem.

Environment Info:

• OS: Linux
• Satpy Version: main brance

[djhoese]

I just checked and the CSPP Geo Beta release does not produce files with the same variables as the AWS files. The AWS files have variables and attributes like this:

lat_band_aod550_retrievals_attempted_land:grid_mapping = "goes_lat_lon_projection: latitude_bands goes_imager_projection: y_image x_image" ;

The file says it is CF 1.7. This syntax/scheme is probably closer to CF 1.10 as I found it described here: https://cfconventions.org/Data/cf-conventions/cf-conventions-1.10/cf-conventions.html#use-of-the-crs-well-known-text-format. So that CF conventions attribute is wrong, but also I think the formatting of this attribute is wrong. It is supposed to be "<grid mapping variable name>: <axis1 variable> <axis2 variable>. It lists one variable (so fine it is 1D maybe), but also listed the other grid mapping in the file and y_image and x_image variables but those variables are scalars which I don't think this is how this is supposed to work. I definitely don't understand there being two grid mapping variables listed in the single grid_mapping attribute.

[djhoese]

Ah nevermind, maybe the x_image and y_image part are accurate. They are scalar variables with metadata about the axes. I still think the two grid mappings in one attribute is wrong.

[djhoese]

Nevermind one more time, the two grid mappings is fine and is used to describe a single grid in both lon/lat space and in x/y space. I do think the x_image and y_image variables referenced should be x and y since these are the non-scalar versions. I don't think latitude_bands is correct...or rather it isn't correct that the 1D variables in this file have 1D and 2D grid mappings.