Geo2Grid allow image processing of native resolution imagery to finer resolution than 0.5km ?

[jpnIII]

Good day, all! Just wondering if it would be possible to consider enhancing the Geo2Grid software package to be able to generate native projection GOES/Meteosat/etc imagery at a finer resolution than the nominal 0.5km resolution? 0.5km is the nominal resolution of GOES-16 -> 19 Advanced Baseline Imager (ABI) band 2 (and Advanced Himawari Imager (AHI) band 3) imagery, and is the highest resolution of any of the 16 bands available on either instrument. Currently, a user is not limited to any specific horizontal resolution when they run geo2grid.sh to generate REMAPPED imagery. For example, one can quickly and easily generate a 0.1km (or even finer) resolution Lambert-Conformal true color image from GOES-16 over the east coast of Florida to view imagery from the time of the recent Space-X launch from Cape Canaveral. However, if the same user wants to look instead at the same GOES-16 imagery in its native GOES projection, they are limited to the finest available resolution of any of the GOES bands, which is 0.5 km. Even though looking at higher resolution native projection GOES/Himawari data is just duplicating pixel values, it can be useful nonetheless at times to be able to "blow up" interesting features, to see them in very high detail. The Geo2Grid software package is a very powerful and useful package for displaying Level-1b and (especially) generating/displaying Level-2 satellite imagery. It is our opinion that adding the above capability would enhance the package even further. Thank you for your thoughts on this request!

[djhoese]

Hi Jim, Although it would take some calculations to get the exact numbers it is possible to do this by providing your own grids that match the resolution you want:

https://github.com/ssec/polar2grid/blob/master/polar2grid/grids/grids.conf#L41-L44

We realize this isn't the easiest thing to do, but luckily we are hoping to add downsampling functionality which could probably be used for upsampling as well. See #187 for details.

[jpnIII]

Hi Dave – Thank you for responding so quickly to me! I had not thought about that. 1.) Did you by chance document somewhere how you did the computations to get those numbers in grids.conf for, example, goes_east_1km? I could then use the same to compute whatever resolution GOES-E and –W “native projection” grids I wanted! I would need to be able to compute the quantities: pixel_size_x, pixel_size_y, origin_x, origin_y 2.) I will have to test goes_east_1km, and compare the results to simple McIDAS-X IMGDISP commands of 1km GOES-16 imagery. I will be anxious to see how the two compare! Do you know if the grids.conf definition for goes_east_1km should match exactly, or is it just very close? If it is an approximation, do you have any thoughts on where geographically the approximation might be least accurate? Talk to you soon! Sincerely, Jim From: David Hoese <[email protected]> Sent: Monday, June 1, 2020 5:12 PM To: ssec/polar2grid <[email protected]> Cc: James P. Nelson <[email protected]>; Author <[email protected]> Subject: Re: [ssec/polar2grid] Geo2Grid allow image processing of native resolution imagery to finer resolution than 0.5km ? (#280) Hi Jim, Although it would take some calculations to get the exact numbers it is possible to do this by providing your own grids that match the resolution you want: https://github.com/ssec/polar2grid/blob/master/polar2grid/grids/grids.conf#L41-L44 We realize this isn't the easiest thing to do, but luckily we are hoping to add downsampling functionality which could probably be used for upsampling as well. See #187<#187> for details. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#280 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AARELF4T6DF3S5MOFLFCLFLRUQRTFANCNFSM4NQFJ6YA>.

[djhoese]

1. No. The origin values in the grids.conf are the center coordinates of the upper-left pixel. This obviously changes for the different resolutions. However, if we have the outer edge coordinates of the pixels then we can do some basic math to calculate the pixel center for a given resolution since the outer edge coordinates should be the same regardless of resolution. For GOES-16 that is:

   (-5434894.8851, -5434894.8851, 5434894.8851, 5434894.8851)
   

   That's minimum x, minimum y, maximum x, maximum y. This came from Satpy by doing:

   from satpy import Scene
   scn = Scene(reader='abi_l1b', filenames=['OR_ABI-L1b-RadF-M3C02_G16_s20181741200454_e20181741211221_c20181741211258.nc'])
   scn.load(['C02'])
   print(scn['C02'].attrs['area'])
   

   Which shows:

   Area ID: GOES-East
   Description: 0.5km at nadir
   Projection ID: abi_fixed_grid
   Projection: {'ellps': 'GRS80', 'h': '35786023', 'lon_0': '-75', 'no_defs': 'None', 'proj': 'geos', 'sweep': 'x', 'type': 'crs', 'units': 'm', 'x_0': '0', 'y_0': '0'}
   Number of columns: 21696
   Number of rows: 21696
   Area extent: (-5434894.8851, -5434894.8851, 5434894.8851, 5434894.8851)
   

   With that we can do:

   minx = -5434894.8851
   maxy = 5434894.8851
   res = 1000
   origin_x = minx + res / 2.0
   origin_y = maxy - res / 2.0
   

   With this I get origin_x -5434394.8851 and origin_y 5434394.8851 which I'm realizing is not what is in grids.conf (off by 5 millimeters see edit below). The numbers and method I posted here should be correct (see below).

2. I put a lot of work into Satpy to make sure that ABI's outer edges (extents) were consistent between the various channel resolutions. This required a lot more than the PUG instructions to calculate X/Y coordinates in meters (if those exist at all) to account for floating point error and the fact that 32-bit floats aren't enough precision to describe/store these coordinates in the NetCDF files. It's possible (based on my above answer) that this work in Satpy happened after I added the GOES-related grids to grids.conf in Geo2Grid. Some of the lower resolution grids in grids.conf are little odd because it isn't a clear division of pixels after a certain point (can't have half a pixel). Using the math above you should get exact alignment to anyone who is doing it "right". If not, I'd be curious to figure out why.

Edit: Look at the differences, I see that in my example above I used 1000m but in grids.conf I used 1002.008644 to match what I saw from the actual data coming from Satpy as the resolution of the 1km channels. If we plug that in to my equations above (instead of 1000) then we get the same answer. You will likely want your resolutions to be based on this 1km resolution (divide by 2, divide by 4, etc) to get semi-evenly spaced pixels that match the original full resolution data. Geo2Grid should be able to tell that these are "factors" of the full resolution data and do native resampling.

[jpnIII]

Thank you again, Dave. I have been looking at what you said. Most of it makes sense to me. ☺ 1.) Based on what you are saying at: #280 I will use 1002.008644 meters as the resolution of the 1km bands on both GOES-16 and -17. This same number should also hold for Himawari, I would think. 2.) When I try to import Satpy in my python session on imaginator, Satpy cannot be found. It does not matter whether I am using python 2 or python 3. Any suggestions for what to try next? The reason I am trying to do this is that I want to try to mimic what you did, looking at band 2 NetCDF file variables, and I also want to try the same with GOES-17, to see what those upper-left and lower-right X and Y coordinates are. Thanks Dave! Sincerely, Jim From: David Hoese <[email protected]> Sent: Tuesday, June 2, 2020 8:30 AM To: ssec/polar2grid <[email protected]> Cc: James P. Nelson <[email protected]>; Author <[email protected]> Subject: Re: [ssec/polar2grid] Geo2Grid allow image processing of native resolution imagery to finer resolution than 0.5km ? (#280) 1. No. The origin values in the grids.conf are the center coordinates of the upper-left pixel. This obviously changes for the different resolutions. However, if we have the outer edge coordinates of the pixels then we can do some basic math to calculate the pixel center for a given resolution since the outer edge coordinates should be the same regardless of resolution. For GOES-16 that is: 2. (-5434894.8851, -5434894.8851, 5434894.8851, 5434894.8851) That's minimum x, minimum y, maximum x, maximum y. This came from Satpy by doing: from satpy import Scene scn = Scene(reader='abi_l1b', filenames=['OR_ABI-L1b-RadF-M3C02_G16_s20181741200454_e20181741211221_c20181741211258.nc']) scn.load(['C02']) print(scn['C02'].attrs['area']) Which shows: Area ID: GOES-East Description: 0.5km at nadir Projection ID: abi_fixed_grid Projection: {'ellps': 'GRS80', 'h': '35786023', 'lon_0': '-75', 'no_defs': 'None', 'proj': 'geos', 'sweep': 'x', 'type': 'crs', 'units': 'm', 'x_0': '0', 'y_0': '0'} Number of columns: 21696 Number of rows: 21696 Area extent: (-5434894.8851, -5434894.8851, 5434894.8851, 5434894.8851) With that we can do: minx = -5434894.8851 maxy = 5434894.8851 res = 1000 origin_x = minx + res / 2.0 origin_y = maxy - res / 2.0 With this I get origin_x -5434394.8851 and origin_y 5434394.8851 which I'm realizing is not what is in grids.conf (off by 5 millimeters). The numbers and method I posted here should be correct (see below). 3. I put a lot of work into Satpy to make sure that ABI's outer edges (extents) were consistent between the various channel resolutions. This required a lot more than the PUG instructions to calculate X/Y coordinates in meters (if those exist at all) to account for floating point error and the fact that 32-bit floats aren't enough precision to describe/store these coordinates in the NetCDF files. It's possible (based on my above answer) that this work in Satpy happened after I added the GOES-related grids to grids.conf in Geo2Grid. Some of the lower resolution grids in grids.conf are little odd because it isn't a clear division of pixels after a certain point (can't have half a pixel). Using the math above you should get exact alignment to anyone who is doing it "right". If not, I'd be curious to figure out why. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#280 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AARELF7SG3KXKLPAZDBVW3DRUT5E3ANCNFSM4NQFJ6YA>.

[djhoese]

1. It might not be exactly the same for AHI, but GOES-17 ABI should be the same.
2. Satpy is not builtin to python. You need to be using a python environment that has it installed. You can "cheat" and use the one provided by Geo2Grid by doing /path/to/g2g/bin/python and then type in the code I posted above. That said, the extents for GOES-17 should actually be the same since everything in projection coordinates should be the same. So in the custom grids you make the only things that should be different between G16 and G17 versions of the grid are the name of the grid and the PROJ (projection) parameters (lon_0 is the only one that's different I think).

[djhoese]

I think we got your original question(s) answered here so I'm going to close this issue for our own record keeping. If you have similar questions or new questions please file a new issue.