It is currently September 23rd, 2020, 12:25 pm

⭐ Weather.com - Parsing the V3 JSON - NEW!

Our most popular Tips and Tricks from the Rainmeter Team and others
User avatar
jsmorley
Developer
Posts: 21386
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: ⭐ Weather.com - Parsing the V3 JSON - NEW!

Post by jsmorley »

Well bummer...

I'll have to chew on this.

I'd prefer to keep the approach the same from the standpoint of the end user, where "today" just returns null values that can be reacted to with IfMatch. This is going to require some thought on how I force in null values for "today" and then push the others forward by one, and deal with the missing data at the end of the parsing.
User avatar
jsmorley
Developer
Posts: 21386
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: ⭐ Weather.com - Parsing the V3 JSON - NEW!

Post by jsmorley »

That might just be too difficult. I guess I will have to get and return the day part "name" like "today" and "tonight", and the skin will have to be written so that those are a part of the display.

So the measures will just be something like [@PollenDay0Part1GrassIndex]
User avatar
Yincognito
Posts: 2587
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: ⭐ Weather.com - Parsing the V3 JSON - NEW!

Post by Yincognito »

jsmorley wrote: August 3rd, 2020, 10:28 pmI'd prefer to keep the approach the same from the standpoint of the end user, where "today" just returns null values that can be reacted to with IfMatch. This is going to require some thought on how I force in null values for "today" and then push the others forward by one, and deal with the missing data at the end of the parsing.
Well, maybe, just maybe, the missing data at the end could remain missing data and never be displayed in a meter if the "dayInd":["N" exists in the string, then:
- separate the RegExp option for today and tonight in your .inc
- use a regex conditional to test for the existence of "dayInd":["N" and capture nothing if it does or capture normally if it doesn't, e.g. (?(?=.*"dayInd":\["N")|<capture the 0th index(es) normally here>)

That would only require changes on the today and tonight measures (well, tonight would just have to be index 1 and be separated from today), the rest would be unaffected (unless you insist on handling the missing data at the end, that is). Basically, the today measures will be "fake" if today's data doesn't exist, and behave normally if it does.

EDIT: You could even use the branch reset group, i.e. (?|(a)|(b)) in regex for that, so that different captures will share the same group number.
User avatar
jsmorley
Developer
Posts: 21386
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: ⭐ Weather.com - Parsing the V3 JSON - NEW!

Post by jsmorley »

Yincognito wrote: August 3rd, 2020, 11:14 pm Well, maybe, just maybe, the missing data at the end could remain missing data and never be displayed in a meter if the "dayInd":["N" exists in the string, then:
- separate the RegExp option for today and tonight in your .inc
- use a regex conditional to test for the existence of "dayInd":["N" and capture nothing if it does or capture normally if it doesn't, e.g. (?(?=.*"dayInd":\["N")|<capture the 0th index(es) normally here>)

That would only require changes on the today and tonight measures (well, tonight would just have to be index 1 and be separated from today), the rest would be unaffected (unless you insist on handling the missing data at the end, that is). Basically, the today measures will be "fake" if today's data doesn't exist, and behave normally if it does.

EDIT: You could even use the branch reset group, i.e. (?|(a)|(b)) in regex for that, so that different captures will share the same group number.
I don't really follow. The problem right now is that there are "groups" {0}, {2}, etc. that are capturing the "pairs" for [1,2,3,4 and so on. When the data starts with "N" instead of "D", those "pairs" become mismatched as instead of the group capturing "day1day", "day1night", it becomes "day1night", "day2"day".
User avatar
jsmorley
Developer
Posts: 21386
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: ⭐ Weather.com - Parsing the V3 JSON - NEW!

Post by jsmorley »

Seems to me that I need to stop using those "pairs" entirely, and just individually capture each value in the "array" as a separate entity, and then just pass the day/night indicator, "D" or "N" as a part of the values.

If the very first indicator is "N" instead of "D", then I just disable the final measure so I don't get an error, or use a lookahead on it.
User avatar
Yincognito
Posts: 2587
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: ⭐ Weather.com - Parsing the V3 JSON - NEW!

Post by Yincognito »

jsmorley wrote: August 3rd, 2020, 10:28 pmI'd prefer to keep the approach the same from the standpoint of the end user, where "today" just returns null values that can be reacted to with IfMatch. This is going to require some thought on how I force in null values for "today" and then push the others forward by one, and deal with the missing data at the end of the parsing.
As long as this doesn't hang Rainmeter due to empty capture (shouldn't happen for WebParser though, only for String measures), it should be a starting point:

Code: Select all

RegExp=(?siU)(?|.*"dayInd":\["D".*"grassPollenIndex":\[(?:.*[,|\]]){0}(.*),|())
Tested with a string similar to what pbutler6 posted.

EDIT: Just read your last posts, and yes, I concur. Treating the field values individually is best. I already do that, but well, our approaches are a bit different, so it isn't relevant.
User avatar
jsmorley
Developer
Posts: 21386
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: ⭐ Weather.com - Parsing the V3 JSON - NEW!

Post by jsmorley »

Yeah, I'm starting to think that the best approach, although it's a bit different for the skin author than the other data is to:

capture each individual element of each "array" as a separate entity. Add captures for the date, day/night indicator (D/N), and the day name value (today/tonight/tomorrow/tomorrow night/thursday/thursday night) and create measures for those.

I also think I will change this to a 14day version of the .inc, so it will always return 0-26 values and won't ever "run out of" data. It might start with "day" and end with "night" or start with "night" and end with "day", but it will be a consistent number of values.

I wish there was a V3 version of this, although I don't see one. The old V2 version of this stuff was I think tailored to the "cards" that used to be on the actual website, that worked like that. During the day it started with "today/tonight" and at night it started with "tonight/tomorrow". I'm betting a V3 version this data would be indexed the same as the other V3 stuff.
User avatar
Yincognito
Posts: 2587
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: ⭐ Weather.com - Parsing the V3 JSON - NEW!

Post by Yincognito »

jsmorley wrote: August 3rd, 2020, 11:40 pm Yeah, I'm starting to think that the best approach, although it's a bit different for the skin author than the other data is to:

capture each individual element of each "array" as a separate entity. Add captures for the date, day/night indicator (D/N), and the day name value (today/tonight/tomorrow/tomorrow night/thursday/thursday night) and create measures for those.

Have at least the 30th capture be a (?(?= lookahead) so if they decide to use the full 15day .inc file, they don't get an error.

I wish there was a V3 version of this, although I don't see one. The old V2 version of this stuff was I think tailored to the "cards" that used to be on the actual website, that worked like that. During the day it started with "today/tonight" and at night it started with "tonight/tomorrow". I'm betting a V3 version this data would be indexed the same as the other V3 stuff.
I don't use lookaheads for this, I just take how many groups are available through the (?<group>){0,N}+ approach:

Code: Select all

(?siU)"grassPollenIndex":\[(?:.*[,|\]]){0,29}+([^"\{\[\]\}]*)[,|\]]
which automatically makes non existing captures blank, but then I use it on String measures and have empty capture failsafe mechanisms, like replacing stuff with _\1_ or <\1> instead of simply \1 (so that the result isn't empty, even if the capture is), clearing the garbage afterwards. You'd probably be more comfortable with lookaheads though - I just shared this as an alternative, that's all.

Yeah, I tried the V3 approach on pollen, but just couldn't nail the right section name (couldn't use V1 so I settled for V2). As I said, it takes some attempts and permutations (if the thing is available in V3 for this API Key, that is) to find the correct URL syntax, as the documentation, besides being "confidential", is quite sparse on these things...

I'm not sure it would change things if a V3 was available and known by us. Maybe it's a pollen thing, after all. :confused:
User avatar
jsmorley
Developer
Posts: 21386
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: ⭐ Weather.com - Parsing the V3 JSON - NEW!

Post by jsmorley »

Capturing the values that have distinct "day/night" components was mostly done in "pairs" like that for the purpose of organizing the measures into "days" in the .inc file, so they were displayed that way in About / Skins. It just made things a bit easier to follow when creating a skin.

There is no other particular value in pairing up the values like that.
User avatar
jsmorley
Developer
Posts: 21386
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: ⭐ Weather.com - Parsing the V3 JSON - NEW!

Post by jsmorley »

As to any lookaheads, I'm now leaning toward this:
I also think I will change this to a 14day version of the .inc, so it will always return 0-26 values and won't ever "run out of" data. It might start with "day" and end with "night" or start with "night" and end with "day", but it will be a consistent number of values.