Weather Details are not accurate

[myopenflixr]

Hello,

I wanted to report a couple discrepancies on what is being reported in Pirateweather versus AccuWeather.

Pirateweather is showing current wind speed at 78.62 mph (SSW). It is a bit windy today, but actual wind speed according to AccuWeather is only 7 mph (SSW) with Max Wind Gusts of 20 mph.

Pirateweather is also showing humidity at 76% and AccuWeather is only showing humidity at 68%

Temperature and Air Pressure look to be pretty accurate compared to AccuWeather

Just thought I'd share this with you.

Thanks, Mike

[myopenflixr]

Hi,

For comparisons, I took the following screenshots of Pirateweather and Dark sky to show a side-by-side comparison of the differences in the weather details. These screenshots are about 2 minutes apart in time.

For the most part, they are reporting fairly similar details with the exception of the Wind Speed

[alexander0042]

Hi, thanks for posting this report! It really helps me get a sense of how things are working by comparing against some other sources.

I'm happy seeing the icons and temperatures line up, since precipitation has always been one of the trickier things. Wind speed remains an issue though (also identified here: Pirate-Weather/pirate-weather-ha#16). Do you mind sharing roughly where in the world you are, since that helps with troubleshooting this!

I almost have things set up to use the higher resolution version of the GFS model, so I'm hopeful that helps somewhat here. I'll write up a better process document when the update goes live, but the main issue is that the GFS files were too big to fit in the lambda temporary storage space, so I've moved over to AWS Fargate, which has more room!

[myopenflixr]

Hi, I live in Hilliard, OH USA. Zip code 43026

I absolutely love this weather option versus any others that are out there and willing to give you the time it takes to get things working as expected!

I'm also more than happy to help with any testing that you may need from me, however I have virtually no coding skills. and can't help with that aspect

[alexander0042]

So this is interesting! It seems to be the classic computing problem of multiple things being incorrect, which makes it really hard to isolate exactly what's wrong.

Since you're in the US, the first problem doesn't apply to you, but it's pretty interesting! I was surprised to see this, but it turns out there's a bug in the original Dark Sky integration code I pulled from Home Assistant. The integration requests the "ca" units if it detects the install is outside the US. This is fine, but Dark Sky returns wind speed in kph in this case. However, the card displays it using m/s, which is incorrect.

This one has an easy fix, which I'll push out shortly as a new version- change the requested units to SI! It also appears to be an issue in the current Dark Sky integration for HA, so I'll submit a PR to fix that as well.

However, you're in the US, so this metric issue doesn't explain your problem. I checked the raw model data for that date, and the wind speed should have been about 17 mph, not the insane result I'm showing here. The question is why?

As a first step in debugging, do you mind checking https://weather.pirateweather.net/ next time you see a weird wind speed? I'm trying to work out if it's an issue with the integration, or my model processing.

Thanks, Alexander

[alexander0042]

Metric wind speeds corrected in commit https://github.com/alexander0042/pirate-weather-ha/commit/e95083f235817ba3f5653114afe5602ab323b8ae

[myopenflixr]

I have updated to the new version and will continue to monitor. If I do see anything that appears to be off, I'll compare it to https://weather.pirateweather.net/ as you requested and report back.

[alexander0042]

Holy cow, I found the issue! Wind speed is a combination of the X and Y components, and I take the vector magnitude sqrt(x^2 + Y^2) to get the wind speed. I did this correctly a dozen times in the script... except once, for the current data, where I had sqrt(x^2 * Y^2). Because wind speed tended to bound around 1-2 m/s, this was a smaller issue than you'd think, but definitely not correct, and more incorrect the higher the winds got!

I have a major update this weekend, so I've batched this fix as part of that, but starting next week the wind speed issues should be resolved

[myopenflixr]

Hi,

I just came across another discrepancy this morning. PirateWeather showing the temp is 36...However, in reality it's closer to 13.

Here's a screenshot of weather pulled from weather.pirateweather.net compared to weather.com. Hilliard, OH around 8:40am EST.

[alexander0042]

Thanks for catching this- I saw this in real time, which really helped troubleshooting! It's a combination of two things- NOAA's distribution system crashed hard last night (https://www.nco.ncep.noaa.gov/status/messages/), which mean Pirate Weather hasn't been able to ingest any new results since then. However, the API should gracefully fall back on older forecasts, and it didn't do that.

However, the good news is that the shiny new V1.0 version of this API fixes this problem! I'm updating the front end to use the new version, so you can check that out shortly!

[cloneofghosts]

I'm seeing the same issue on my end with the incorrect data being shown. I looked at the API call and it's showing incorrect data there as well. There is no new API call for the 1.0 release right? I didn't see anything in the docs about if the API call has changed since the 1.0 release.

EDIT: Few hours after this post it did start to update the current conditions but it still seemed to off by quite a bit. It did fix itself recently so NOAA must have fixed their issues.

I'm still seeing the wind speed issue even after the 1.0 release though it doesn't seem as bad as before.

[alexander0042]

Hi,

I should be turning on the V1 version later today (you'll see a new field in the flags for version), so it's NOAA's improvements that should have the largest changes so far. However, I have updated the front end website (https://weather.pirateweather.net/) to use the new version while I'm testing it, so let me know if that is looking any better for you?

[alexander0042]

Actually, even better idea, if you'd like to help test the new version, change your API url from api.pirateweather.net to dev.pirateweather.net! I use that as my testing endpoint (it calls the latest Lambda code, as opposed to a stable version), but in this case is several steps ahead.

[cloneofghosts]

I tried to call dev.pirateweather.net but I get an empty response error when visiting. https://weather.pirateweather.net/ does seem to be better and has fixed the wind speed issue.

[alexander0042]

Weird- you might need to go into the developer portal and click subscribe to the .dev backend?

[cloneofghosts]

It seems to have fixed itself as the dev url works now.

[cloneofghosts]

Just something I noticed yesterday and this morning when looking at the hourly details in the API and on https://weather.pirateweather.net

I see that in the hourly section the 4 hours show as rain but the temperature is below the freezing mark. Is it supposed to represent freezing rain or is it just an error with your processing? Also shouldn't the current hour be excluded from the hourly section?

[alexander0042]

Good spotting! Now that old forecasts are archived for a bit, this way was easier to diagnose, so that's a win!

What you're noticing here is the mismatch between the high resolution, rapidly updating HRRR model that's used for temperate and minute-by-minute data, and the slow, low resolution model (GEFS) that's used for the hourly forecasts. HRRR was showing temperatures below freezing, but since the GEFS model was showing rain, we ended up with this.

These will keep cropping up for the next couple weeks, but the next update to bring in the National Blend of Models should improve this, since temperature and precipitation will come from the same source. The icon is another matter- right now I have it set not to display precipitation unless it's greater than 1 mm/h, but I'm starting to think this is too high- might be better to drop it to 0.5 mm/h as a threshold

[cloneofghosts]

Ideally for current conditions it should show the icon if it's greater then 0 but then you might have the problem of it saying rain/snow/sleet if it isn't. I know Dark Sky uses Possible Precipitation for this but that isn't implemented here yet so maybe 0.2/0.3?

For forecasts maybe if it's above a certain percentage (maybe 30%) and above 0 then show the icon? I'm not sure what other sites do but I feel like 30% is reasonable.

[alexander0042]

This comment is exactly the reason I put this project together- it shouldn't be a mystery about how a weather API chooses an icon, so thanks for asking this!

The issue with "any precipitation" is that for really light rain/ snow conditions (think "trace"), you don't want the icon showing as rain/ snow. This is particularly an issue in the winter, where you can get very light snowfall amounts on sunny days. However, 1 mm/h is probably too high of a bar, so I'm thinking 0.25 mm/h as the threshold for the precipitation icon? Percent of precipitation is a good idea, but it would have to come from the global ensemble model, which is less accurate, so want to avoid using that if possible.

[cloneofghosts]

I think 0.25mm/h is a good bar to show the icon. What you described is likely why DarkSky uses Possible Drizzle/Flurries/Light Rain as the text for very light precipitation. If the precipitation percentage is coming from a less accurate model then you can not include it for now. Would NBM be better for that or would it still not be super accurate?

Since you merged my issue with this one I will mention that I'm still seeing the issue with the fog icon as stated in the other issue. I know we were discussing the wind icon there as well but never came to any conclusion so maybe wind speeds above 35 km/h would show the icon? Obviously converted for the other units to keep it consistent.

EDIT: I noticed that the precipitation fields in the API response are not rounded to 2 decimal points like the rest of the fields are. Same with the current windSpeed, the daily moonPhase, humidity and cloud cover fields.

[cloneofghosts]

Quick Question about snow and precip rate. I'm seeing this in the API: "precipIntensity": 3.6 and comparing it to Dark Sky I see "precipIntensity": 0.0662

I'm guessing it's not using the snowfall precipitation ratio of 1:10 so it just looks higher then it actually is

[alexander0042]

I really love these questions, so keep em coming!

Great spot here- you're 100% correct that this is an error. I double checked Dark Sky's documentation, and they define that intensity should always be in mm of liquid water per hour (aka, without that 1:10 snow factor), but accumulation should have snow factored in. I think this is kind of weird, since why would someone want intensity in a different unit than accumulation, but if I wanted to make these sorts of decisions, I wouldn't have set up an API with Dark Sky compatibility!

I've updated the API script so that intensity always returns the liquid water equivalent, and the update should show up in about 20 minutes or so!

[cloneofghosts]

That fixed the issue. One thing I'm noticing at the moment is that the reported conditions are off compared to other sites such as Environment Canada/Accuweather/Weather.com.

Right now PirateWeather is showing 0% Cloud Cover and Clear. Those other sites are showing Mostly Cloudy/Cloudy. I'm guessing NBM will help fix the issue but is there no datasets on AWS that have current conditions?

I've also seen the opposite where PirateWeather shows 100% cloud cover on a sunny day.

EDIT: Just going to point out that compared to DarkSky it's giving similar results so its similar in that regard.

[RaptahJezus]

I am also seeing mismatching weather results. Just for fun, I tried checking weather for Houston, Texas on both DarkSky and PirateWeather. Houston has a pretty big storm passing over it, and this is displayed correctly on DarkSky, but the results from PirateWeather don't seem to agree. PirateWeather's hourly forecast indicates rain through the night, but current forecast has it at cloudy. There is also no precipitation shown. I'm attaching images of both just for reference

And here is DarkSky's take on the situation:

Thanks for all your great work on this project so far, it's very exciting to see .

[alexander0042]

Thanks for the updates @cloneofghosts and @RaptahJezus! Those are both really good catches, and I've got separate answers here:

1. Cloud cover is a tricky one to get, since clouds can be super localized, the match can be off. I've looked into using current condition datasets, since there is one that has all the airport/ met station data in it, but only gets updated daily at this point (https://registry.opendata.aws/noaa-isd/), so isn't nearly quick enough yet. NBM will fix this to some extent however, so I'm going to start there and see how it works!
2. I love it when people run these comparisons, so keep it up! Thanks to the V1.0 update, I could actually go back and check exactly what was happening here, and this one was a bug! There was a glitch where it wasn't using the higher resolution forecast for the front end, so that's why you saw that result, combined with the previous comment about what classifies as trace being set to high. I just released V1.1 out into into the wild (it's the default, so you don't have do do anything to use it), and it's been corrected there.

[cloneofghosts]

Thanks for the updates @cloneofghosts and @RaptahJezus! Those are both really good catches, and I've got separate answers here:

1. Cloud cover is a tricky one to get, since clouds can be super localized, the match can be off. I've looked into using current condition datasets, since there is one that has all the airport/ met station data in it, but only gets updated daily at this point (https://registry.opendata.aws/noaa-isd/), so isn't nearly quick enough yet. NBM will fix this to some extent however, so I'm going to start there and see how it works!

No worries, I've used other APIs which has the same issues as yours does so it isn't something unique to your API. DarkSky has a ton of different sources so I wonder if it's combining different ones together to get their current conditions? Here's the list of sources in case you wanted to look: https://web.archive.org/web/20200627122418/https://darksky.net/dev/docs/sources

[alexander0042]

Yea, I've checked out that list, and it's pretty extensive! What Dark Sky managed to do a few years ago when they launched was harder than it is now, which is something I'm taking advantage of here. One of the guiding principals of this project is to avoid trying to replicate anything NOAA does, since there's no way I'm ever going to outdo them! Along these lines, since NOAA now has high resolution forecasts down to 15 minute intervals, it let me avoid having to replicate the custom "darksky" item on that list, and generally get the same breadth of data from fewer sources.

For the forecasts, I use HRRR in the US and Canada to 48 hours, and then GFS for everything else. UV data also comes entirely from GFS, and the ensemble version of the GFS model (GEFS) is what's driving the precipitation estimates. The perk of NBM is that it has its own blend of several models (including the Canadian one), which avoids the really tricky issue of how to blend multiple data sources on my end.

In the medium term, I'm planing on adding a new url variable that will let people request data from a specific model (ex. models=hrrr,gfs,nbm,cmc). The idea is that the default would continue to return either the highest resolution model or some sort of blend, but let people either select what data they want, or use multiple calls to compare sources. The V1.0 update to move the processing over the fargate was the first step for this, since it'll let me pull in grib files that aren't only available on AWS.

[cloneofghosts]

So with HRRR and NBM it will be close to what DarkSky offers then. Will definitely check once NBM is added to see if it helps.

[alexander0042]

Exactly! For the minute by minute data, NBM won't change anything, since it's an hourly dateset, but the giant improvement will be to the precipitation probability. Currently, I have to use GFS data for the probability, since HRRR only gives one value, not a range. Since NBM of models is a blend, there's a range of results, which is exactly what's needed for the probabilistic variables. Plus, since the amount, type, and probability of precipitation will all be aligned, there won't be the edge cases where there's a 0% chance of rain but a rain icon, or visa-versa

[cloneofghosts]

I've noticed the last few days on https://weather.pirateweather.net/ that the hourly data is showing 0 mm / 0 cm and a rain/snow icon

The data in the API is fine though

[cloneofghosts]

Disregard my last comment it seems to be fixed.

I also noticed the same issue last night as mentioned by RaptahJezus. There was some light snowfall which passed through last night but the currently/minutely data. I know at some point last night Kemptville showed snow but that was really all I saw last night in my area.

EDIT: I've noticed that the wind_gust seems to always correspond to the hourly data instead of the 15m rapid data. I wonder if it's looking for it in the wrong spot?

[alexander0042]

Not a coincidence that it's fixed! I saw your comment and worked out the issues (related to the problem that accumulation is always in cm), so it's all good now! It was handy that it's been snowing or raining pretty much everywhere, so lots of places I could check against.

Re: wind_gust. Your guess is 100% correct. What's weird here is that I honestly can't remember why I made that decision- it may have been that there wasn't guest data in the subhourly, but honestly I'm not sure. Let me check that and get back to you on that one

[cloneofghosts]

Looking at your processing script it shows that you are using 10m above ground for wind speeds and surface for gusts. I found this documentation for the sub-hourly fields https://rapidrefresh.noaa.gov/hrrr/GRIB2Table_hrrrncep_subh.txt and it shows that GUST is 10m above ground and there is no surface GUST available

EDIT: Something else I've noticed is that when it gets close to the hour it updates the current condition fields except precip to the hourly data. I assume the sub-hourly and hourly models match up at that point so it just looks like it updated to the hourly data?

[alexander0042]

Ok, this is corrected in the dev back-end for the gust data! I was already processing it (as shown in the scripts- chalking it up as a win for open source that you were able to notice that), so it was just a case of reading that parameter, which was easy (for once!).

The current conditions is harder. I took a look at it this weekend, and the variable I use to assess cloud cover (TCDC: https://rapidrefresh.noaa.gov/hrrr/GRIB2Table_hrrrncep_2d.txt), is only in the hourly data. However, the subhourly does have a composite radar precipitation, which appears promising, but needs more investigation to see how the value returned from that field would relate to the current conditions. If there's precipitation, then that overrides it, but that doesn't help for cloudy/ vs sunny.

[cloneofghosts]

I'm sure there's a dataset somewhere which has current conditions but I'm not sure where to find it.

There is a 3D version of HRRR which they call the "analytical/nowcast" model. Might be worth looking into? Though it does seem like the data is 2h behind currently? https://rapidrefresh.noaa.gov/hrrr/GRIB2Table_hrrrncep_prs.txt

[alexander0042]

Yea, I've looked into that one, but because it's trailing, I really need a forecast to be able to provide a "current", especially since it takes at least 15 minutes for the data to be loaded into AWS, then converted by the scripts into NetCDF files for the API

[cloneofghosts]

I know they have a discussion forum on Github that you could start a thread on https://github.com/NOAA-GSL/GSL-Regional-Model-Forum/discussions otherwise it likely won't be useful. The few google searches for some feeds haven't amounted to anything which is unfortunate. Otherwise I haven't noticed much else in terms of issues with current conditions.

[alexander0042]

Yea, it's a tough nut to crack (although that's kind of the point of this project- if it were easy, it wouldn't be any fun).

In North America, NBM should improve things somewhat, since it's integrating data from a wider range of sources, but I don't think it'll be earth shattering. The real answer is to either work radar data in somehow, since it's already gridded and on AWS, or pull real-time observations from airports and whatnot, and then us the closest station (which is what's typically done)

[cloneofghosts]

I know that some APIs use a combination of personal weather stations and airports to get their data. While this is good it won't help much if there is no airport nearby or if it doesn't report any conditions. I know there's a few times where there's a difference between what the airport says and what I see at my location.

Working with radar data will help somewhat but it might be tricky to implement? I haven't worked with any of this stuff so I can't say for sure how easy it will be to use them.

EDIT: I know there is satellite datasets on AWS but I think they're just images and won't be helpful for this. Here is the link to the combined dataset on AWS https://registry.opendata.aws/noaa-gmgsi/

EDIT2: I found this which could be useful https://www.nssl.noaa.gov/projects/mrms/. Looks to have precip rate in grib format and it does have surface temp as well but it seems to be 1h behind.

EDIT3: I also found this which could be helpful https://www.nco.ncep.noaa.gov/pmb/products/rtma/? It has a rapid update model which updates every 15 or so and an hourly one as well. It's still delayed but not by as much as the 3D version (~15m for rapid update and ~40m for hourly)

[cloneofghosts]

I just noticed this when looking at the forecast for Thursday. I know there's supposed to be rain and snow but 200+ mm seems a little ridiculous. Other places are calling for 10mm of rain with 15-30cm of snow.

I had a chance to look at the API and it shows this "precipAccumulation": 21.6743, which makes much more sense.

[alexander0042]

Now that would be a wet day!

I've been thinking about this the last couple days. Since I changed things to always show accumulation in cm and intensity in mm, I knew this would come up at some point, but I'm not sure the best way to "fix" it.

What's happening is that the API always returns accumulations in cm. The weather models return the amount of liquid water per hour, as well as if it is snow or rain, so I use the standard 10:1 ratio to return an amount (in cm). For hourly results, this is easy, since I know what the precipitation type is, and then that's easy to display. But daily data is harder.

Right now, I just add up all the hourly results and spit that out, which works well when it's the same precipitation type all day. But as you can see, when it's a mix of rain and snow, this approach starts to break down. What's happening here is that there's more than 12 hours of rain (so the daily type returns rain), but there's also a fair bit of snow, with that 10x factor.

Looking at the official Dark Sky docks, accumulation always refers to snow. So maybe the answer here is to keep them separate (which is what newer APIs do), and add another variable for rain accumulation, showing that one separately on the web page. Alternatively, and less of a "breaking change" (although not really, since accumulation for rain should never have been reported for daily data), would be to have it default to the rain accumulation factor (1:1, instead of 10:1) when there's a mix, since this would avoid these crazy results.

Thoughts?

PS. Don't even get me started on sleet!

[cloneofghosts]

Right now, I just add up all the hourly results and spit that out, which works well when it's the same precipitation type all day. But as you can see, when it's a mix of rain and snow, this approach starts to break down. What's happening here is that there's more than 12 hours of rain (so the daily type returns rain), but there's also a fair bit of snow, with that 10x factor.

When I look now the icon has changed to snow and the correct precipitation amount is being shown. So it's a case of if there is more rain then snow it will use the wrong calculation when displaying on the website.

Looking at the official Dark Sky docks, accumulation always refers to snow. So maybe the answer here is to keep them separate (which is what newer APIs do), and add another variable for rain accumulation, showing that one separately on the web page. Alternatively, and less of a "breaking change" (although not really, since accumulation for rain should never have been reported for daily data), would be to have it default to the rain accumulation factor (1:1, instead of 10:1) when there's a mix, since this would avoid these crazy results.

It depends on the website for showing the rain accumulation. I know most sites will give a range like 5-10 mm of rain or 10-20 cm of snow as examples. When looking for more details on Accuweather it shows the exact rain amount and the exact snow amount for Thursday afternoon.

Maybe the answer here is to have 3 different precipAccumulation variables:

• precipAccumulation - This would be the total amount of precipitation always in mm. So it would convert the snow using the 1:10 factor
• precipAccumulationRain - Total amount of rain in mm.
• precipAccumulationSnow - Total amount of snow in cm.

It would be more information for those who want it but I'm not sure if it's really necessary or not. More then likely the total accumulation will be equal to rain or snow (after you take into account the 1:10 factor). So maybe just total and snow are needed?

[cloneofghosts]

I've noticed the last few days on https://weather.pirateweather.net/ that the hourly data is showing 0 mm / 0 cm and a rain/snow icon

The data in the API is fine though

This issue seems to have popped up for Sleet in the daily conditions. Thinking about the accumulation for rain/snow I think it would make the most sense to have a total accumulation in mm and one for snow in cm. Maybe having a separate precip rate for snow in cm/h might be useful?

I added this as a comment above but in case you missed it:

I also found this which could be helpful https://www.nco.ncep.noaa.gov/pmb/products/rtma/? It has a rapid update model which updates every 15 or so and an hourly one as well. It's still delayed but not by as much as the 3D version (~15m for rapid update and ~40m for hourly)

EDIT: In hourly block I see icon sleet with summary Rain which is incorrect.

EDIT2: Fog icon still not working correctly. I saw visibilities of 0km and 0.4km and cloudy when it should be fog.

[alexander0042]

Just wanted to pass along a quick update here! There's a few things going on (weather is hard), but at least one of them is fixed! There was an "off-by-one" bug in the processing code, which is what threw the really weird icon != summary issue you saw. That should never happen, and the corrected version is now live.

In other news, I really love that gridded real-time assimilation source that you posted! They have a 15 minute updating one, which is pretty rapid. I'm going to run some tests this weekend to see how quickly I can ingest it to a netcdf, but it looks promising, especially since it's just 1 time step. This should really improve the current conditions, which I'm learning are a major use case for this sort of thing.

What time of day were you taking about for the fog icon? I'm thinking the issue might be with the day/ night logic now, so this would help troubleshooting

[cloneofghosts]

What time of day were you taking about for the fog icon? I'm thinking the issue might be with the day/ night logic now, so this would help troubleshooting

It was at night when I saw the issue.

[cloneofghosts]

Did the precipIntensity get changed back in the currently data as I see it displaying the snowfall rates in cm/h instead of mm/h. Everywhere else the data is showing the snowfall intensity in mm/h so I'm not sure why currently is displaying the wrong information now.

currently: "precipIntensity": 3.6, minutely: "precipIntensity": 0.542, hourly: "precipIntensity": 0.6374, daily: "precipIntensityMax": 0.7273,

[cloneofghosts]

Any updates on this one? Haven't heard a reply in over two weeks.

[alexander0042]

Apologies for the radio silence here! I got sucked into another issue trying to optimize the response time, since it's been slowing down with additional winter weather alerts being issues.

I never actually adjusted the currently repose, which was an oversight on my part. Thanks for pointing that out, and I've fixed it in for the dev back end, which should go live later this week. In the next couple weeks, I'm going to add a new accumulation variable for rain. Since Dark Sky says that "precipAccumulation" should only be snow, it makes sense to keep this consistent, and clearly solves the 10:1 issue.

This is the plan:

• If snow is forecast, "precipAccumulation" will be the snow accumulation, in cm.
• If rain/ sleet is forecast, "precipAccumulation" will be zero, and the new "liquidAccumulation" will be the rainfall accumulation.
• "precipIntensity" will stay as the Dark Sky compatible mm of liquid water equivalent per hour. I was thinking of adding a "snowIntensity" in cm/h, but I don't think it makes sense in this context.

I'd love to hear your thoughts on this approach? I think it's the clearest, most compatible way of addressing this permanently, but always open to other ways

[cloneofghosts]

I think this issue is starting to get a bit messy with the multiple different things going on in this thread. Maybe it would make sense to have a separate topic for the precip stuff?

I think doing it that way would make the most sense though it will break things for people that use the precipAccumulation to display the total snowfall/rainfall though it's not a huge deal. I'm not sure if it would be worth having a totalAccumulation in mm which shows the combined amount of rain/snow as it would be an easy replacement for those using precipAccumulation to show the total precipitation.

As for adding a snowIntensity while it would be nice but I don't think it's really necessary since it would just be the precipIntensity multiplied by 10. In the future if the 10:1 ratio changes then it could be useful information.

Did you ever get a chance to test the source I posted about earlier in this issue? I know you said you were working on response times so you might not have tested it.

[cloneofghosts]

Any updates here? I'm still seeing the cloud cover issue I pointed out before for the last few hours.

EDIT: Going to clarify that for most part cloud cover seems accurate but there are times when you can definitely tell it's off.