Is this based on the L2 data? Would that then technically make this L3 data? I guess not. Wondering if a more specific reader name is needed like glm_l2_imagery or something. @deeplycloudy @mraspaud thoughts? Main concern is if we add a reader for the point data then it can"t also be called glm_l2, but is probably a more "accurate" name for that reader versus this reader.

Coverage increased (+0.05%) to 87.364% when pulling 2bdc33f on deeplycloudy:glm-imagery into f03fd62 on pytroll:master.

I"m certainly supportive of reusing the ABI infrastructure since my goal has been to have the GLM imagery be just another ABI channel. If you want to point to the essential bits from which I could inherit, I have no objections to making that change.

I wrote my reader from scratch because the ABI reader has a lot of machinery for tasks specific to the radiance data (and surely other matters that I don"t understand), whereas the GLM data can use the default xarray reader (since it comes from the xarray writer in the first place). So it was easier to do that as a first effort than to try to understand everything the ABI reader was doing.

Completely understood and I agree, but @yufeizhu600 did some work to get the ABI L2 reader working which included separating out the "shareable" functionality to one abi_base.py module. I"d still wait on #905 before starting the work on anything. It may be simple enough that I can just do it and have you review it, but I"m not sure my time availability coming up.

That said, I"m trying to get some last minute proof-of-concept things done for my talk at the Joint Satellite Conference in Boston in a week and a GLM/ABI composite from Satpy would be pretty sweet. But I also need to actually have slides to show so I should probably work on that first.

Edit: The abi_base.py work was done recently I should have said. So it only recently made easier to do this.

Codecov Report

Merging #854 into master will increase coverage by 0.04%.
The diff coverage is 92.81%.

@@            Coverage Diff             @@
##           master     #854      +/-   ##
==========================================
+ Coverage   87.31%   87.36%   +0.04%     
==========================================
  Files         181      183       +2     
  Lines       28042    28158     +116     
==========================================
+ Hits        24486    24601     +115     
- Misses       3556     3557       +1

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f03fd62...2bdc33f. Read the comment docs.

@deeplycloudy I made some important changes that look big but really aren"t big to how the data is loaded.

1. I changed the file handler to be based on the ABI L1b/L2 base file handler. This let"s the GLM file handler benefit from some work I"ve done on getting better more consistent precision with the GOES AreaDefinition.
2. I kept the scene_abbr in the file name pattern to be consistent with ABI L1b and changed the area_code in the ABI L2 (FYI @yufeizhu600). This way all three readers use the same names for these fields.
3. Fixed a couple trailing spaces that our linters didn"t like and added docstrings.
4. I added extra metadata to the reader YAML based on some work I did relatively recently to make readers more usable for GUI applications and other tools.
5. I added an available_datasets method to dynamically add resolution information to the datasets when the files are loaded. This method also checks if the variable actually exists in the file. I did this after noticing that some of the L2 files on Unidata"s THREDDS server that you pointed me to didn"t have any data variables (I assume this is because there was no lightning data for the time I picked).

@mraspaud This is ready for re-review.