This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Hi Mike, re: forgot to include SSEC updates in the Unidata mcupdate process > Whoops, I guess that explains that. Yea, not good :-( re: the full distribution is always a snapshot, so it should always be up to date > Understood. I'll do that soon and let you know how that goes. But before > I do, just want to make sure I understand something... re: FYI new, test ADDE server for NOAAPort-delivered GOES-R products > So let's say all I do is the full McIDAS upgrade. Will these changes > affect current operations? No, for two reasons: - I just finished tweaking the servers this morning, and I am now in a testing phase This means that they are not in the snapshot that can be downloaded... yet. - the work is not a change to the SCMI ADDE servers; those are untouched re: > I'm using goes-restitch.py to take NOAAPort tiles, put them together > and save them as a single .nc4 file. > Example file name, goes_restitch default: > (GOES16_CONUS_20190429_170121_0.64_500m_30.1N_87.1W.nc4) As part of the revamp of the NIMAGE datastream that I referred to in previous emails, I researched the GOES-R mission standard naming conventions. What the version of goes-restitch.py uses for output names are _not_ GOES-R mission standard compliant. The web page I put together to illustrate what the product names in the upcoming revamp of the NIMAGE datastream. re: > If I'm reading > you right, the current ABIN server used to read these files would still > work, The ABIN servers require that the files have a GOES-R mission standard name format. The names being created by the version of goes-restitch.py are _not_ mission standard, so the ABIN servers can not be used. I am sure you are using my SCMI servers currently, and, as I said above, those have not been touched. re: > and that it's just a new/alternative method is now available > correct? Well, the new servers that I made the comment about will be a new way of serving the NOAAPort-delivered GOES-R/S products when they are released. re: > Just want to make sure I don't break things working now when I go > to upgrade. Nothing should break by upgrading to v2018c as the new servers that I am talking about are not in that release. They will be in a v2018d or v2019 release when these are available. re: the speed improvement is dramatic > Interesting. I'm not sure I'll have a chance to explore this in depth > right away, but I will definitely keep this in mind. Thanks for letting me > know! Again, you can "kick the tires" by accessing the NPGOESR and NPGOESS ADDE datasets off of lead.unidata.ucar.edu. If you ever loaded a single NPGOESR/NPGOESS image or loop off of lead.unidata.ucar.edu before yesterday, and then try doing the same today, you will experience the massive speedup. Aside: the reason for the incredible speedup is the ABIN and now CMIP servers relay on the product names having enough information (e.g., coverage, band, start time down to the second/tenths of a second) to winnow down the list of files that have to be opened in order to had back a listing of available data or a particular image. The ABI L2 images that are created by stitching together the tiles from NOAAPort that are distributed in our NOTHER datastream and will be available in the revamped NIMAGE datastream (available not from one's own NOAAPort ingester, but, rather, from our IDD top level relay clusters) will have GOES-R mission standard names, and users of those products that do not change the names will be able to use the new ADDE servers I have been working on. Those who choose to change the names (a bad idea for McIDAS users) will be forced to continue to use the SCMI ADDE servers. Cheers, Tom -- **************************************************************************** Unidata User Support UCAR Unidata Program (303) 497-8642 P.O. Box 3000 address@hidden Boulder, CO 80307 ---------------------------------------------------------------------------- Unidata HomePage http://www.unidata.ucar.edu **************************************************************************** Ticket Details =================== Ticket ID: FFB-510199 Department: Support McIDAS Priority: Normal Status: Closed =================== NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.