3
$\begingroup$

I would like to use ASOS data from Iowa State University to compute daily rainfall totals for specific locations. Using ASOS, I am unable to match the official NWS totals. I am assuming that the definition of a day is midnight to midnight, local time.

For example: KLGA had a record rainfall total of 3.33" on June 7, 2013. An excerpt of the ASOS data covering June 7 is below. The "D" and "H" columns are EDT. It appears that rainfall totals are cumulative and reset hourly at 51 minutes (see hours 12 and 13 EDT for example). But I am unsure how to interpret certain cases. What do I do with hour 21, which reports 0.21" at 36 minutes, 0 at 48 minutes, and 0.24" at 49 minutes. Does that 0 denote a reset prior to 51 minutes, implying a total of 0.45" for that hour? Or does it indicate something else, such as a temporary cessation?

The general questions are: a) how does one parse the p01i column, and b) should it be possible to use ASOS precipitation data to match official NWS totals? Thanks!

Excerpt from ASOS data: GMT M D H M p01i ... 2013-06-07T16:23:00Z 6 7 12 23 0.11 2013-06-07T16:43:00Z 6 7 12 43 0.19 2013-06-07T16:51:00Z 6 7 12 51 0.21 2013-06-07T17:35:00Z 6 7 13 35 0.18 2013-06-07T17:51:00Z 6 7 13 51 0.22 ... 2013-06-08T01:16:00Z 6 7 21 16 0.18 2013-06-08T01:29:00Z 6 7 21 29 0.21 2013-06-08T01:36:00Z 6 7 21 36 0.21 2013-06-08T01:48:00Z 6 7 21 48 0 2013-06-08T01:49:00Z 6 7 21 49 0.24 2013-06-08T02:47:00Z 6 7 22 47 0.22 2013-06-08T02:51:00Z 6 7 22 51 0.22 2013-06-08T03:51:00Z 6 7 23 51 0.11 2013-06-08T03:58:00Z 6 7 23 58 0

Edit: See below. Note that the value of p01i at 6:59 (0.01") is less than that at 6:51 (0.05"), and greater than that at 7:40 (0"), which in turn is less than that at 7:51 (0.09"). What exactly is being reported here?

GMT M D H M p01i 2013-06-07T10:51:00Z 6 7 6 51 0.05 2013-06-07T10:59:00Z 6 7 6 59 0.01 2013-06-07T11:40:00Z 6 7 7 40 0 2013-06-07T11:51:00Z 6 7 7 51 0.09

Edit #2: @JeopardyTempest confirms the importance of 51 minutes past the hour. I have an algorithm that (almost!) works. Assume:

  • The day is measured from midnight to midnight local time, without a DST adjustment. So in June, LGA remains at -0500.
  • Precipitation totals are accumulated to 51 minutes each hour

The official daily 2013 rainfall totals for June 2, 3, 6, and 7 are 0.11, 0.96, 0.10, 3.33, 0.79. Using the algorithm above with the ASOS data for the same days yields 0.11, 0.96, 0.10, 3.32, 0.80.

$\endgroup$
5
  • $\begingroup$ They are 'hourly accumulations', i.e. the amount of rain that has fallen in the previous hour up to the labelled time. FWIW, the closest I can get to 3.3" for the source given is 2013-06-07 05:51 - 2013-06-08 05:51 (3.19"); not far off given the NWS defined rainfall day is 0700-0700. $\endgroup$ Commented Jun 16, 2017 at 10:30
  • $\begingroup$ @KieranHunt Can you source the 0700-0700 day? $\endgroup$
    – user967
    Commented Jun 16, 2017 at 14:22
  • $\begingroup$ @KieranHunt In addition to a source for 0700-0700, I would be interested in your thoughts about how to interpret the values I've added (for hours 06 and 07) in the edit. $\endgroup$ Commented Jun 16, 2017 at 16:13
  • $\begingroup$ Looking back, I'm guessing the differences in your algorithm were from precip coming in between 2351 and 0000. Which I'm guessing end up being counted in the day of for recordkeeping, but would next be reported in the 0051. $\endgroup$ Commented Jan 25, 2022 at 2:16
  • $\begingroup$ I think that it can be a real challenge to matching metar to climate reports (as metar will do 6/24 hour totals at 51ishZ [and not necessarily at midnight], whereas climo is midnight to midnight I believe). I'm not sure the answer... you could try contacting the director of wxchallenge.com where we often came to such an issue and see if he has any input on it. $\endgroup$ Commented Jan 25, 2022 at 2:42

2 Answers 2

2
$\begingroup$

Typical synoptic (hourly) obs come in about 51 past the hour (sometimes a couple minutes off). The other reports you're seeing are generally subops (SPECIs) which generally only report precip since the last ob given, but the total of which should always be reflected in the hourly.

So for 2136/2148/2149 timed obshour... you just use the 0.24 from 2149, and it should include the others in it (so skip the others that would lead to double-counting).

On the other hand, the 659 ob being smaller than the 651 ob makes sense... as 659 is in the NEW hour... so would be reflected in the 751 ob (which is indeed higher).

I didn't get a chance to look too closely, but looks like all of these are unfortunately altered forms of the data. I believe typical full data should have METAR or SPECI in it to indicate which obs you want?

But no big deal, if you look back at the rawer-looking data you gave, looks like you can find which ones you want by looking for the ones with SLP reported right about the end. Or, even better, just look for the 6**** fields right about the end, which are the 6 hour total precipitation. Just add the four of those up, and you'll have the daily total.

If you're trying to accomplish all this in Excel, some formulas could be worked up to automatically take what you need from the day's data, or you could use a regex in any of the variety of online regex testers. Or writing some sort of script could save a lot of time if you're downloading a lot of data. But the rawer data is often safer and more easy to work with.

I think I used a page like this for more info back in the day when I had to do it.

$\endgroup$
13
  • $\begingroup$ Thank you! The confirmation of 51 minutes past the hour is helpful but I still can't find a source. The other wrinkle is that the daily precipitation totals seem to ignore daylight savings time. With this change, which I also can't find documented anywhere, the totals most days exactly match the official totals. $\endgroup$ Commented Jun 17, 2017 at 3:14
  • $\begingroup$ I should have mentioned that you are correct that the data I presented was "altered". I did this to clarify the question. The actual ASOS data from Iowa State has the raw METAR strings and numerous additional fields, some of which, such as precipitation, are obviously derived from the METAR. $\endgroup$ Commented Jun 17, 2017 at 14:35
  • $\begingroup$ No worries, I thought one of the other sites you'd used presented it that way. Not a problem, helpful :-) I tried to find a source for the 51ish info too. Some suggested it's more like 55. Think it may have even varied over time or by countries/regions. But 51 or 52 is the number I'm generally used to over the past 15 years of viewing metar :-) Indeed looks like you are right that the 6 hourlies won't be useful, because they're 0/6/12/18Z, whereas indeed midnight to midnight won't match that. $\endgroup$ Commented Jun 17, 2017 at 16:21
  • 1
    $\begingroup$ I think my question is resolved, see the top of my original post. You might be interested in the linked presentation there. I was thinking more about DST in daily rainfall calculations and concluded that precipitation totals probably had to ignore it, because otherwise one hour would be missed and another double-counted every year. Or there would be some other funky workaround. Again, thanks for your responses! $\endgroup$ Commented Jun 19, 2017 at 14:40
  • 1
    $\begingroup$ @JeopardyTempest: I've converted the question and posted an answer. Thanks for the suggestion. I've also posted R code to a github site. $\endgroup$ Commented Jun 20, 2017 at 3:48
2
$\begingroup$

I am grateful to Daryl Herzmann at Iowa State, who wrangles data at the Iowa State Environmental Mesonet for providing an off-exchange answer.

  • Synoptic reset times are between 51 and 57 minutes past the hour, depending on the site. A possible way to automate the use of ASOS data is to find the modal minute value in the data. This seems highly likely to be the reset minute.

  • The most quoted daily rainfall total is measured midnight to midnight, local standard time, by summing the synoptic hourly total. Because it is standard time, DST is ignored.

  • I have created a github site that includes R code to compute daily precipitation totals from ASOS data. This code:

    • Uses the modal minute as the ASOS reset minute
    • Converts the time from GMT to local
    • Subtracts 3600 seconds if DST is in effect

Daryl has a presentation that discusses precipitation measurement. Thank you Daryl!

$\endgroup$
5
  • $\begingroup$ I'm still not sure why you want to account for DST. What's the advantage or reason for that? $\endgroup$
    – haresfur
    Commented Jun 20, 2017 at 4:01
  • 1
    $\begingroup$ Think about what happens when you switch from standard to DST. In New York you go from GMT - 0500 to GMT -0400. At 2am it becomes 3am. In the Fall you go from 2am to 1am. What do you with precipitation between 2am and 3am in the spring, or between 1am and 2am in the Fall? You've got 23 and 25 hour days. I'm not saying you can't handle this in some way, but it seems much cleaner to just ignore DST. $\endgroup$ Commented Jun 20, 2017 at 4:09
  • $\begingroup$ Suggest you accept this answer, as it's a great resource. I've followed Daryl for a long time, he has some superb information. $\endgroup$ Commented Dec 5, 2021 at 6:01
  • $\begingroup$ @JeopardyTempest I'm not sure what you're suggesting. I did accept my answer which cites Daryl. $\endgroup$ Commented Dec 6, 2021 at 23:31
  • $\begingroup$ Sorry for the trouble, must've misseen it. Thanks for taking the time to make the answer (and respond to my aloof comment!) $\endgroup$ Commented Dec 7, 2021 at 2:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.