FTUS42 KFFC 131551 AAB
TAFATL
TAF AMD
KATL 131551Z 1316/1418 09007KT P6SM FEW250
     FM140000 12003KT P6SM SCT250
     FM141600 14005KT P6SM SCT150=

A user of this archive requested the tracking of "Amendment" status, which the IEM was previously not doing. In the example above, this is denoted as TAF AMD. Support for this was added, but it will take a few days to reprocess the archive to include this attribute within the download service and various web services. Whilst adding web service support for this, the taf overview got some interesting updates and this news item intends to advertise those changes.

Newly supported TAF overview request examples

Provide GeoJSON of all most recently issued TAFs valid at 12 UTC on 25 Dec 2025
https://mesonet.agron.iastate.edu/api/1/nws/taf_overview.geojson?at=2025-12-25T12:00:00Z
This would return the most current issued TAF at or prior to the given UTC timestamp.

Provide JSON of available TAFs for Des Moines during July 2012.
https://mesonet.agron.iastate.edu/api/1/nws/taf_overview.json?station=KDSM&sts=2012-07-01&ets=2012-08-01
This returns all TAF metadata that can be used for subsequent queries to get an individual TAF.

Provide a CSV of all available TAFs for 15 December 2021 (UTC)
https://mesonet.agron.iastate.edu/api/1/nws/taf_overview.txt?sts=2021-12-15&ets=2021-12-16
Requests like these are limited to a 10 day period. The response seqnumber value orders the TAFs descending in time for a given station.

Hopefully folks find this useful and please always send bug reports and feedback our way!

The IEM attempts to archive various meteorological datasets useful for funded research projects that keep the IEM going. These archives include relational databases, flat files on spinning disks / servers at ISU, and files stored within various cloud services Iowa State University has contracts with. Over the years, the IEM took advantage of "unlimited" storage options available at Google and Box to make various archives available within ISU and the public. Sadly, there are no unlimited options left, so a number of archives curated there need to spin down prior to newly enforced quotas set to start off 2026.

The good news is that the vast majority of data you access via the IEM is not impacted by this change, but there are two niche datasets that do have users that will be impacted. The most significant one is the archival of raw MRMS grib data. The other dataset being the archival of satellite imagery generated by the College of DuPage. The mitigation for these two archives is that the MRMS data is now mostly redundantly stored within the AWS Opendata Project and the raw GOES satellite data is stored at AWS as well, so there is a path to regenerate archive plots via that data source.

The IEM just found out about this quota change on Monday (22 September) and have just begun engaging collaborators on what could be done with some of this archived data. Some of the datasets are small enough to come back to live at ISU within current IEM hardware on campus.

To summarize, hopefully impacts to IEM users and projects will be minimal, but some archives will need to be removed or scaled back in scope. As always, please reach out to daryl with any questions you have!

FTUS43 KMPX 220156 AAA
TAFSTC
TAF AMD
KSTC 220156Z 2202/2224 17005KT P6SM BKN050
      TEMPO 2202/2204 -SHRA
     FM220400 18005KT P6SM SCT250 PROB30 2210/2215 4SM -TSRA
      OVC035CB
     FM221500 27010KT P6SM OVC050=

A review of the IEM's TAF processing found some gaps with how the TEMPO and PROB30 fields were stored within the database. These have hopefully now been corrected with an additional field now available within the download called ftype, which delineates between the observation, forecast, tempo, and probability data types.

As always, please send any feedback on this and how the archive could be more useful for your needs!

• Hopefully mobile friendly now!
• App uses URL parameters instead of hash linking, which should be a cleaner interface. Previous hash links will continue to work.
• There are many small UI wins with improved interaction between table and map.
• Additional basemaps are configured to allow for more striking displays.

The previous app is available here, but will hopefully be removed someday once everybody is happy with the new interface.

As always, thanks for your usage and interest in IEM website tools!

Like other "networks" the IEM curates, the data will be organized into state based network identifiers. Data from Canada will be found as an identifier of "CAN_COCORAHS".

As always, feedback is welcome. This change was the most often requested new feature from me over the past number of years.

Update 9:45 PM: The problems continue, will await networking help tomorrow.

Update 16 Jan 8 AM: ISU networking folks continue to troubleshoot this problem. No ETR at the moment, so thank you for your continued patience.

Update 16 Jan 12 PM: ISU networking folks put a fix in place and initial testing looks very promising. Declaring victory for now.]]> akrherz@iastate.edu (Daryl Herzmann) https://mesonet.agron.iastate.edu/onsite/news.phtml?id=1470 https://mesonet.agron.iastate.edu/onsite/news.phtml?id=1470 downloadable archive of many National Weather Service Watch, Warning, and Advisories. This archive is very unique to the known public Internet with no known freely available alternatives, which I suppose is a prideful statement, but also a scary one as there is no known "answer key" to compare IEM processing with. Anyway, this archive intends to be a complete archive of NWS products implementing VTEC (Valid Time Event Code), which was another in the line of convoluted things attempting to make parsing NWS ASCII text products sane. The VTEC implementation started in 2005, but many moons ago the IEM did some special processing attempting to create VTEC events prior to 2005 for a limited set of warning types.

Enough backstory, this news item denotes an addition of fake-VTEC warning types covering certain marine products in Alaska. Again with the convoluted term, but for such reasons Alaska forecast offices do not implement VTEC for things like Gale Warnings and Small Craft Advisories. Instead, they have a zone based forecast product that implements these events as headlines within the forecast. An example product is CWFNSB with an ASCII text like so:

PKZ811-210330-
Cape Thompson to Cape Beaufort out to 15 NM-
402 AM AKST Wed Nov 20 2024

...STORM WARNING IN EFFECT THROUGH LATE THIS MORNING...
...HEAVY FREEZING SPRAY WARNING IN EFFECT FROM LATE THIS
AFTERNOON THROUGH EARLY THURSDAY MORNING...

The IEM now has processing that attempts to create these "fake-VTEC" events in realtime and has back-filled this processing to the start of 2005. FAQ Item 7 for the VTEC dataset has a bit more color on this. The biggest caveat is that the temporal handling of these events is very crude. Absent of any NWS documentation on how these events are to be timed, the least painful coding life choices were made with the pyWWA ingestor written.

As always, I am happy to field any questions about this and hope the community finds this addition useful.

TL;DR. Official ASOS temperatures that go into "daily" max/min summaries are 2 minute averages of 2-5 second sampled data reported in integer (whole degree) Fahrenheit.

The Source of Confusion

There are a number of data sources on the Internet that report data from the ASOS in whole degree Fahrenheit, but were sourced from data without the two minute average and/or subject to rounding pain with the upstream source data being in whole degree Celsius.

Next TL;DR. I don't know of any near realtime source of temperature data in whole degree F that uses the two minute averaging and not subject to the F to C to F round tripping problem.

Frequently Asked Questions

1. What are sources of ASOS high/low temperatures that have integer Fahrenheit fidelity?
   A. The METAR 6-hourly summary, which looks like so 10017 21017, Example
   B. The Daily Summary Message, which is emitted by the ASOS and has something looking like 331616/ 090255 Example
   C. The CLI/CF6 Message, which is a NWS product and will get some manual quality control in some instances. CLI Example, CF6 Example.
2. Your website has near-realtime 5 minute data, but temperatures are all missing. Huh?
   Welcome to the year 2016 when I discovered this problem and intentionally set this data to missing to avoid confusion.
3. I am just wagering on "top of the hour" temperatures, surely this is straight forward?
   Oh boy. If by "top of the hour" you mean the METAR reported T-group temperature found at the "synoptic reset time" report, the answer is unfortunately no. So the 1970s called and automated hourly reports were made a number of minutes prior to the top of the hour to allow time for these reports to be centrally collected and analyzed on a map. So sites have their hourly "reset time" at some minute between :50 and :59 after the hour. The reported temperature at this time is typically labelled as the top of the hour temperature, but it technically came a few minutes prior. Additionally, during active weather, the ASOS may generate a special METAR a few minutes prior to the reset time and if insignificant changes happened afterwards, it will skip the report at the "reset time". A temperature change of 1 degree within these few minutes may not be reported. It gets worse.
   The common understanding is that the METAR T-group exists to provide 0.1 degree Celsius resolution necessary to convert back to whole degree Fahrenheit. I believed this for many moons before doing a closer check of the actual data and finding all kinds of horrors. It is very possible that the 0.1 degree C T-Group temperature is different from the integer Celsius mandatory integer C temperature. Within the ASOS manual, it does not make the conventional claim that T-group temperature should jive with the integer C temperature (!!). In fact, it calls the T-group temperature as the "hourly temperature", but offers no further details on what exactly that means.
   So what is the "top of the hour" temperature? Who knows at this point. There is a nerdy Github discussion about this within a python based METAR parser, for those intersted.
4. The IEM website sometimes shows a daily high/low temperature different than other websites. What gives?
   This typically is due to the IEM ingesting the Daily Summary Message (DSM), which tends to come before the CLI and has a reliable max/min temperature. The IEM also attempts to appropriately use the 6 Hour METAR max/min, which other sites may not be using.
5. The IEM website offers 1 minute ASOS data, albeit delayed, but manual max/min calculations do not match! Why?
   The IEM processes an one minute interval dataset made available by NCEI and provides a downloadable archive. While this dataset does have whole degree Fahrenheit fidelity, it does not use two minute averaging, so the values are not directly considered in the daily summary. Additionally, it is delayed by 12-36 hours due to the manual phone collection method of retrieving the data by NCEI.

Last Updated: 17 Dec 2024 8:00 AM ]]> akrherz@iastate.edu (Daryl Herzmann) https://mesonet.agron.iastate.edu/onsite/news.phtml?id=1468 https://mesonet.agron.iastate.edu/onsite/news.phtml?id=1468 Updated 8:40 AM: The load balancer admins reverted a routing change and things seem to be back to normal at the moment. Still am attempting to understand why the routing change caused adverse problems. Will update again once more is known!

Updated 12:35 PM: A brief outage happened now as an updated configuration was put in place. Monitoring for any issues!

Updated 1 Oct 9:30 AM: While there were no enduser impacts, the webfarm itself was in a degraded monitoring state. It all should be rectified now]]> akrherz@iastate.edu (Daryl Herzmann) https://mesonet.agron.iastate.edu/onsite/news.phtml?id=1467 https://mesonet.agron.iastate.edu/onsite/news.phtml?id=1467

ISU Facilities folks have a power maintenance window scheduled between 7 and 9 AM on 23 July 2024 for Agronomy Hall, but they are not sure which exact rooms in the building will not have power during this time. So the IEM website could go into a bit of degraded state when/if this happens, but most services should remain healthy. Will update this news item during the maintenance window with any updates.

Thanks for your patience.

Updated 7 AM: Still do not have clarity if the server room is about to loose power or not, but am watching closely!

Updated 9 AM: Still have power, but continue to be unsure what is happening. Will update this news item once I learn more.

Updated sometime later: This remains a mystery, but no harm no foul I guess.]]> akrherz@iastate.edu (Daryl Herzmann) https://mesonet.agron.iastate.edu/onsite/news.phtml?id=1466 https://mesonet.agron.iastate.edu/onsite/news.phtml?id=1466 Updated 9 AM: Data is flowing again, but observations valid at 7 AM are still missing. Have not seen any official word yet on what may be happening.

Updated 11:30 AM: Outage was resolved, but the 7 AM observations were lost.]]> akrherz@iastate.edu (Daryl Herzmann) https://mesonet.agron.iastate.edu/onsite/news.phtml?id=1465 https://mesonet.agron.iastate.edu/onsite/news.phtml?id=1465 Updated 6:30 AM: An update from the NWS denotes that troubleshooting continues, but there is no ETR. The primary impact to the IEM is lack of observational data from HADS, WMO_BUFR, and MADIS. Some additional grid data flows are down as well.

Updated 10:30 AM: Not much for updates. Continue to impatiently wait!

Updated 9:30 PM: Some services have been restored, but others remain unavailable. restoration work continues.

Updated 26 June 7:30 AM: Latest update as the outage continues.

Updated 27 June 7 AM: I have not seen any official statement from the NWS that this is resolved, but I am not currently aware of anything still broken from this outage, so will mark as resolved.]]> akrherz@iastate.edu (Daryl Herzmann) https://mesonet.agron.iastate.edu/onsite/news.phtml?id=1464 https://mesonet.agron.iastate.edu/onsite/news.phtml?id=1464

Update 6:15 PM: The NWS finally issued some update. Things look promising to be fully resolved soon.

Update 6:50 PM: There is an unrelated outage with the boulder datacenter, which has knocked out NOMADS. I should have that worked around now.

Update 7 AM: I continue to attempt fixes of various archive holes, but some appear to be unrepairable. This is probably the last update on the outage.]]> akrherz@iastate.edu (Daryl Herzmann) https://mesonet.agron.iastate.edu/onsite/news.phtml?id=1462 https://mesonet.agron.iastate.edu/onsite/news.phtml?id=1462

FTUS43 KDMX 221343 AAA
TAFDSM
TAF AMD
KDSM 221343Z 2214/2312 28011KT P6SM BKN120
     FM221500 27013G21KT P6SM BKN120
     FM222200 27008KT P6SM FEW120
     FM230300 15005KT P6SM FEW250=

A user of the available downloadable archive found that the IEM archive had a massive hole between 1 Jan 2010 and 4 Apr 2015 for all TAF sites. It is unclear what happened(^TM), but the raw text archive of this product was missing as well from the IEM NWS Text Product Archives.

So this hole was repaired by back-filling the raw text from the NCEI SRRS and reprocessing those historical TAFs into the archive database.

As always, please let me know when you find variances like these within the IEM archives.

Updated 5:30 AM 17 April: The NWS has issued an update and many things remain busted. No ETRs...

Updated 8:30 AM 18 April: The latest NWS update, outage continues, no ETR.

Updated 8 AM 23 April: The outage of some NWS services continues. The latest update from the NWS is here.

Updated 10 PM 23 April: NWS denotes that this outage is now resolved.]]> akrherz@iastate.edu (Daryl Herzmann) https://mesonet.agron.iastate.edu/onsite/news.phtml?id=1459 https://mesonet.agron.iastate.edu/onsite/news.phtml?id=1459 Updated 9 PM: This outage was resolved at about 1:30 PM this afternoon.