Add Viirs L2 Reader + Enhancments

[wjsharpe]

Feature Request

Is your feature request related to a problem? Please describe.
I would like to add a reader for level 2 nc files that use the VIIRS instrument and have a layer in NASA Worldview. There is currently no reader available for a lot of the products that we deliver.

Describe the solution you'd like
I would like to add a reader for CLDPROP, Clear Sky Confidence, DB Aerosol Optical Depth and DB Angstrom Exponent L2 files and then show/save the images with the same colormaps that NASA Worldview uses.

Describe any changes to existing user workflow
This feature should be fully backwards compatible. The only changes to existing code that I have found necessary is to make some very minor changes to the yaml_reader. I will be sure to point these out when I believe the changes are ready for a PR.

Additional context
This feature would likely be a first step which could be expanded upon in the future to support many more of the VIIRS L2 worldview layers once I am more familiar with the Satpy project and workflow.

[djhoese]

So these are NASA L2 products based on the NASA VIIRS L1B files? For modifications to the base yaml reader, what were you thinking? I'm pretty surprised changes would be needed at this point that aren't performance related. Oh ancillary variable loading is a mess so that is expected too.

[wjsharpe]

Yes these are products based on L1b files. I was thinking about 2 minor changes. The first being adding .lower() to the check for the longitude and latitude attrs in _get_lons_lats_from_coords on line 789 and 791 since those attributes are Longitude and Latitude in the CLD files with a capital L. The second change is a check in _set_orientation. I would like the ability to set the upper right corner since SW is in the top right by default for these products. With the current setup of that method it gets the projection type (line 1018) and checks that it is one of two geostationary values. These products are coming from either SNPP or NOAA20 so they aren't geostationary and those attrs don't exist so I was just going to add an if dataset.attrs['area'].area_id != 'viirs_l2_area': or something similar around those checks to bypass them for my case.

My current dev changes are here.

[djhoese]

1. .lower() on the standard_name: The standard_name attributes have capital letters? That's not CF standard is it? I think standard_names are by specification all lowercase. Additionally, standard_name can be overwritten in the reader, either as "extra metadata" that the file handler adds and overwrites when creating the DataArray, or by forcing all standard_name attributes to .lower().
2. There is no need to set orientation for polar-orbiter data. Any orientation changes will/would be done as part of resampling the data to a uniform grid. Well I guess that depends and leads me to the question:

Are these L2 products gridded or on the original swath? If the original swath then the orientation area reply above stands. If gridded, then your first .lower() change doesn't make sense to me as you won't be loading lon/lat swath arrays.

[wjsharpe]

The L2 products are gridded, you are 100% correct about the .lower() being unnecessary, and I will remove that change. Thanks for the help with this. My desire to set the orientation just comes from wanting to use upper_right_corner argument in ._set_orientation so that the NE is in the top right instead of the southwest and you can more easily compare the images to those in worldview since they would be facing the same dir. If this isn't the purpose of that method let me know and I can remove these changes.

I had one other unrelated question. The colormaps for these products are quite long (~200 colors), and looking at the documentation for create_colormap it seemed best to import them from a file so I didn't have huge lists in the enhancement code. Is there a standard place to store these .txt files in Satpy? Or would they be expected to be outside of the project and then have the config path pointed to somewhere local?