GEMPAK Data Question

[jproberts-wx]

Hi everyone! I was curious about something. I've been using the decoded satellite image files from the motherlode server, but wondered if there was another way to get more information. I determined that GEMPAK 7.5.1 and higher will support the display of netCDF data from the Level 2 GOES data from AWS. However, when I attempted to display this information in nMAP2, it appeared to reference the wrong table (pointing to GOES-16), despite updating the tables from the most recent build to GOES-19, and also inverted the color table (thinking that might have something to do with temperature versus brightness -- maybe?). I am wondering if there is something else I need to do to make this work? I tried to see if perhaps there was another image type number that would work, but I could not find anything. Does anyone have any solutions or thoughts on this?

Appreciate your insight! Jay

[mzuranski]

Howdy!

This sounds a lot like #162 and #163 which was this past April. Is there any chance your gempak/tables/sat/imgtyp.tbl doesn't have these changes?

[jproberts-wx]

Hey there! Yep I updated the imgtyp.tbl when that thread came out. In fact, I just did it again to be sure and the same problem persists. I do wonder (since I am not a GEMPAK expert) if I am missing something here. I assumed since GEMPAK can read the netCDF files without problem that simply renaming them from the netCDF format to *_YYYYMMDD_HHNN would be okay or is there a step I am missing? Here's a screenshot of what it attempts to display. Looks like it continues to reference GOES-16 references Ch01 when I am attempting to display 6.9 WV and appears to invert the colors.

I am thinking my half-witted attempt to display the data is likely the cause of this - as standard image files (such as the 6.2 water vapor) from motherlode server work just fine.

[mzuranski]

Well that looks neat but probably not what you're going for.

What motherlode URL(s) were you using? What scripting made those images; is it the same scripting? Does any textual output appear in terminal when you run these?

[jproberts-wx]

Yeah, it looks cool but definitely incorrect. So I was getting the processed image files from motherlode.ucar.edu that work fine via wget script. The other ones that are displaying wrong originated from Amazon Web Services bucket. I did not use a script to download or process them - just manually downloaded and renamed the file based on the channel, date, and time. I’m assuming there is another way to do this though. Sent from my iPhoneOn Jul 16, 2025, at 5:05 PM, Mike Zuranski ***@***.***> wrote: Well that looks neat but probably not what you're going for. What motherlode URL(s) were you using? What scripting made those images; is it the same scripting? Does any textual output appear in terminal when you run these? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[mzuranski]

Okay, I understand. Those are two rather different data sets, and what you're seeing is a result of how the netCDF data is a little more "raw." Beware that I'm going off some pretty rusty memory here...

The first difference is the projections (the top is the native satellite projection, the lower is some conic projection over the CONUS). The other difference is some extra "math" was done to the IR bands; a bi-linear function that escapes me at the moment will stretch the data to replicate what we're used to from the previous GOES satellites (that processing used to be done further upstream for everybody). So the top image you see neither has been done to the netCDF data, while the processing for Motherlode has that baked in.

Side-note: If you've tried visualizing the vis bands you may have noticed some color differences there too. A square-root function was applied to that data in order to brighten up the low ends and level out the high end. This too isn't natively applied to the netCDF data.

You can change the projection using the proj parameter to something else. I can try to find what projection is used in the Motherlode imagery later on, but iirc it's some form of LCC with a standard lon of 100W. Come to think of it, I'm pretty sure it's what Gempak refers to as the SAT projection.

As far as the stretching, I can't recall but there might be a decoder for that data that would help process it first for use in Gempak programs. Otherwise I'd have to think about how to manipulate that more... it's been a while since I've worked with satellite data in Gempak.

[jproberts-wx]

Interesting. So, it sounds like it still reads the data but requires some processing to get it to display correctly. I will have to try using the VIS bands to see how it works. These math functions you speak of - would they have anything to do with the image coefficient tables, or is that something completely different? I believe you are correct that the SAT projection is LCC, but I would have to double-check, too. I've looked through most of the programs/decoders in GEMPAK, and nothing stuck out as particularly useful - unless there is a way to generate an image file (like nex2img or gini) - but it doesn't seem like netCDF has a direct decoder for that purpose.