⭐ Weather.com - Parsing the V3 JSON

[Yincognito]

One update on the location thing we talked about earlier. It's my second time when I check Sevastopol in the Crimean Peninsula for weather, and just like the last time, there is an error in the JSON part, in place of the 2nd subsection of "Location", while the 1st subsection is fine - you can check it as well.

I still think, based on the vast majority of other observations, that the 2nd subsection of "Location" is the most complete (thus, reliable) one, not to mention it is in English (I checked a city in China in Chinese and the Chinese characters were in the 1st subsection of "Location"), but I lean more and more to some sort of "aggregation" of data where there are more than one section involved (thankfully, there aren't many, in fact if I think about it, just this one). That way you can't go wrong, as if something is unavailable in one subsection, you get the non-empty / non-null data from the other.

Of course, that just adds to an already heavy effort, but as I said before, things are very volatile in TWC's case (and not only in "Location") and there is nothing we can do about it. I thought you should know about this - what you decide to do (or not do) eventually is your decision to make. I'll weigh in the pros and cons as well and see what the best solution would look like.

P.S. So far, nothing out of the ordinary with the precipitation and those amounts. I don't know if you noticed, but when there is an accumulation of snow, it is also mentioned in the "snowRange" field. I have a day where:

Code: Select all

"precipAmt": 2.49,"precipType": "snow",...,"narrative": "Snow showers. Low -2ºC. Winds NW at 15 to 30 km\u002Fh. Chance of snow 60%. Snowfall of 2-3 cm.",...,"snowRange": "2-3",

so it's clear that the snowRange string is aggregated into the narrative presented to the user, but it seems to be also present in precipAmt, albeit more precise. I don't know the reason for these duplicates however, but this is not the only case, as the "narrative" field is also aggregated from various others (including the "qualifier" field, which has things like hard freeze expectations and such).

EDIT:

My final conclusion on this is that precipType is only relevant to precipPct (e.g. 60% chances of rain/snow), and not to precipAmt. In the end, my observation strongly suggests that precipAmt is the amount of precipitation in general (e.g. 35 mm of precipitation), while the field showing the amount (i.e. accumulation) of snow is exclusively snowRange (e.g. 3 cm of snow).

Thus:
- precipType can be precip/rain/snow (where precip can be a combination of both or otherwise a generic term - no frogs or sleet noticed)
- precipPct is measured in %
- precipAmt is measured in mm/in
- snowRange is measured in cm/in

Sorry to lead you in the wrong direction before, but only recently I've been able to see radically different values for these fields that allowed me to reach a definitive conclusion:

Code: Select all

"precipPct": 90,"precipAmt": 10.2,"precipType": "precip",...,"phrase": "Rain \u002F Snow","narrative": "A mix of rain and snow. Low 1ºC. Winds N at 15 to 30 km\u002Fh. Chance of precip 90%. Snowfall of 2-3 cm.",...,"snowRange": "2-3",...

[jsmorley]

Added another @Include file

WeatherComJSONPollen.inc

This must be @Included AFTER WeatherComJSONVariables.inc and WeatherComJSONMeasures.inc in your skin, and will provide:

[@PollenDay1TimeStamp]
[@PollenDay1Date]
[@PollenDay1Time]
[@PollenDay1Tree] : 0 (no report) 1 (low) through 5 (very high)
[@PollenDay1Grass] : 0 (no report) 1 (low) through 5 (very high)
[@PollenDay1Weed] : 0 (no report) 1 (low) through 5 (very high)

...

Follows the same pattern for Days 2 though 4

New .rmskin in the first post of this thread.

[jsmorley]

My final conclusion on this is that precipType is only relevant to precipPct (e.g. 60% chances of rain/snow), and not to precipAmt. In the end, my observation strongly suggests that precipAmt is the amount of precipitation in general (e.g. 35 mm of precipitation), while the field showing the amount (i.e. accumulation) of snow is exclusively snowRange (e.g. 3 cm of snow).

Thus:
- precipType can be precip/rain/snow (where precip can be a combination of both or otherwise a generic term - no frogs or sleet noticed)
- precipPct is measured in %
- precipAmt is measured in mm/in
- snowRange is measured in cm/in

Sorry to lead you in the wrong direction before, but only recently I've been able to see radically different values for these fields that allowed me to reach a definitive conclusion:

Code: Select all

"precipPct": 90,"precipAmt": 10.2,"precipType": "precip",...,"phrase": "Rain \u002F Snow","narrative": "A mix of rain and snow. Low 1ºC. Winds N at 15 to 30 km\u002Fh. Chance of precip 90%. Snowfall of 2-3 cm.",...,"snowRange": "2-3",...

If that is the case, that's not a bad thing. It actually simplifies the measures I need to create, since I don't need to test precipType at all. It will always be "mm" in metric, and only snowDepth is measured in "cm / accumulation". This actually makes more sense...

[jsmorley]

Ok...

1) Corrected the rain vs snow "units" to reflect that "precipitation" of any type is measured in @UnitsPrecipitation (in / mm) and only snowDepth (current) and snowRange (forecast) are measured in @UnitsAccumulation (in / cm).

2) Added snowRange to the "forecast" sections of the measure(s). If snow is forecasted, this is a narrative string like "1-3" and you will use the units @UnitsAccumulation. If snow is not forecasted, this will be an empty string.

This is one you might want to "overload" in the skin, to test for an empty string value and not display the units of measure, or change the Text option to display "0" or "None" if so.

New .rmskin in the first post of this thread.

[SilverAzide]

Would it be possible to further optimize the number of active measures similar to the way the Weather.com Template skin is done?

I am currently having an issue with a weather skin variant that uses an ActionTimer to collapse/expand the skin to reveal additional weather details. There are so many enabled measures in the WeatherComJSONMeasures.inc file that the skin is "stuttering" when sliding open/closed and leaving trails of partially painted windows behind on the screen.

In my particular case, for example, I don't need the "Day2" thru "Day6" measures enabled by default. I like the way the super-parent is triggering the parent measures, so it would be cool if the children could be triggered similarly, and in "chunks" so folks could customize what they need. Using separate files is good, like the way the pollen alerts are being handled in the latest iteration. Using measure groups is nice too, but I don't have a preference, just looking for ideas.

Or maybe it is just that my ActionTimer code stinks and it's only me that's having this issue....

[jsmorley]

Would it be possible to further optimize the number of active measures similar to the way the Weather.com Template skin is done?

I am currently having an issue with a weather skin variant that uses an ActionTimer to collapse/expand the skin to reveal additional weather details. There are so many enabled measures in the WeatherComJSONMeasures.inc file that the skin is "stuttering" when sliding open/closed and leaving trails of partially painted windows behind on the screen.

In my particular case, for example, I don't need the "Day2" thru "Day6" measures enabled by default. I like the way the super-parent is triggering the parent measures, so it would be cool if the children could be triggered similarly, and in "chunks" so folks could customize what they need. Using separate files is good, like the way the pollen alerts are being handled in the latest iteration. Using measure groups is nice too, but I don't have a preference, just looking for ideas.

Or maybe it is just that my ActionTimer code stinks and it's only me that's having this issue....

I sorta resist that the number of WebParser "child" measures are a factor in this. Can you test by just making a copy of WeatherComJSONMeasures.inc and just whacking out all the days 2 through 6 measures? Does this really change anything?

[SilverAzide]

I sorta resist that the number of WebParser "child" measures are a factor in this. Can you test by just making a copy of WeatherComJSONMeasures.inc and just whacking out all the days 2 through 6 measures? Does this really change anything?

I will try that ASAP, later today. I wouldn't put it past my crappy ActionTimer code, but just thought I'd check first.

[jsmorley]

I can break this up into separate .inc files for each "day", but all things being equal, I'd just as soon not if I don't really need to. Makes it a bit of a pain to maintain, particularly in these early days, when there is some tweaking going on...

Having said that, if having fewer child measures being stood up makes a demonstrable difference, I will do so.

[Yincognito]

If that is the case, that's not a bad thing. It actually simplifies the measures I need to create, since I don't need to test precipType at all. It will always be "mm" in metric, and only snowDepth is measured in "cm / accumulation". This actually makes more sense...

Indeed. One more thing about what I said about precipType - just for the record. Even though I never saw a precipType different than precip/rain/snow (it's pretty hard to find a place with hail at the exact moment of hail, for example), I did find in the TWC's "dictionary" (i.e. window.i18n section) a couple of terms that may or may not appear one day as values of precipType.

They are hail and ice/mixed (with the / encoded as \u002F, obviously). I'm not certain they both belong to precipType values, as "ice/mixed" is contained in another string in the imap subsection, but I covered these possibilities just in case.

Would it be possible to further optimize the number of active measures similar to the way the Weather.com Template skin is done? [...] Using measure groups is nice too, but I don't have a preference, just looking for ideas.

Or maybe it is just that my ActionTimer code stinks and it's only me that's having this issue....

I don't know if the parent / child WebParser measures are causing this. In my skin (which still uses your icons - thank you again for the permission), I grab nearly all the fields in Location, Observation, DateTime, DailyForecast and unitOfMeasurement (not the Alerts or HourlyForecast fields though, although I am tempted to grab the hourly forecasts too, seeing how easy I can navigate between days or day/night cycles now) and I don't have any visual problem. Granted, my skin is very small and optimized, but the most probable cause I can think of for those "artefacts" is the regular "lag" in parsing the entire TWC main page. This is noticeable even in my super-quick skin, as I have to wait a second or two until the page is read and everything is parsed. Just saying - maybe it helps somehow...

[jsmorley]

Changed my skin (not the @Include files) to better handle today's "high" temperature when it is after the point in the evening when today's "day" forecast is no longer available/applicable.

What I discovered is that the JSON contains a field for the "max temperature since 7am" in the "current" section, and that will in fact be the "high" for today once the data switches over from "day" to "night".

So if you so the same IFMatch on [@ForecastTodayDayShort] and look for an empty string, you can just toggle between using [@ForecastTodayDayTemperature] and [@CurrentTemperatureMaxSince7AM] as the MeasureName option on the String meter for the "High Temperature".

Then you always have both a "high" and "low" for today.

Code: Select all

[MeasureToggleAtNight]
Measure=String
Group=Weather
String=[@ForecastTodayDayShort]
DynamicVariables=1
IfMatch=^$
IfMatchAction=[!SetOption MeterTodayIcon MeasureName "@ForecastTodayNightIcon"][!SetOption MeterTodayName MeasureName "@ForecastTodayNightShort"][!SetOption MeterTodayHighLow Measurename "@CurrentTemperatureMaxSince7AM"][!SetOption MeterTodayPrecipitation MeasureName "@ForecastTodayNightPrecipitationPercent"]
IfNotMatchAction=[!SetOption MeterTodayIcon MeasureName "@ForecastTodayDayIcon"][!SetOption MeterTodayName MeasureName "@ForecastTodayDayShort"][!SetOption MeterTodayHighLow Measurename "@ForecastTodayDayTemperature"][!SetOption MeterTodayPrecipitation MeasureName "@ForecastTodayDayPrecipitationPercent"]