jsmorley wrote: ↑February 9th, 2020, 3:22 am
I don't think that is right. The "units" are static, based on your language code. I firmly believe that amount of rain is measured in @UnitsPrecipitation, and amount of snow is measured in @UnitsAccumulation.
Maybe - that was my first impression as well, and I would be happy to be like this. In that case though, they should have included another row for accumulation (separated from precipitation) in the table from the 2nd document I linked to. Plus, to make matters more confusing, while in "Observation" the "precip24Hour" and "snowDepth" are separated (making clear that one is mm and the other is cm), for "DailyForecast" of day and night there's only one field specifying the accumulation ("precipAmt") and is followed by a "precipType". So for daily forecasts, you have no way of separating mm from cm in different fields, while you do have a field telling you what kind of precipitation "precipAmt" refers to. Of course, there is also "snowQpf" there, but that's only for the whole day, not for day and night cycles.
You understand where my confusion comes from now, don't you?
jsmorley wrote: ↑February 9th, 2020, 3:43 am
You may be right now that I look at it.
If you get this information from each day/night "forecast":
"precipPct":10,"precipAmt":0,"precipType":"rain"
Then perhaps if precipType is "rain / precip" it is measured in @UnitsPrecipitation, and if precipType is "snow" is it measured in @UnitsAccumulation.
That's not going to be rocket-science to deal with with an IFMatch is this is the case.
Something like that, yeah. I'm not sure, of course, but that would be one of the few explanations possible.
[@ForecastTodayDayPrecipitationAmount]
[@ForecastTodayDayPrecipitationType]
[@ForecastTodayNightPrecipitationAmount]
[@ForecastTodayNightPrecipitationType]
[@ForecastDay2DayPrecipitationAmount]
[@ForecastDay2DayPrecipitationType]
[@ForecastDay2NightPrecipitationAmount]
[@ForecastDay2NightPrecipitationType]
... and on though Day6
And changed:
[@ForecastTodayDayPrecipitation]
To:
[@ForecastTodayDayPrecipitationPercent]
In all the Forecast sections for Today/Tonight through Day6
Yes, I know some measure names are getting pretty long, but I want to err on the side of "clarity" for this. Nobody is going to want to need to keep a reference guide in front of them. I want the meaning of the measures in About/Skins to be as obvious as possible.
I don't use those "amount" and "type" measures in my skin, so not being sure about units is ok, while I watch to see if over some time we can figure out how they work. Then we will see if we need to jump through any hoops to use the right "units" for them.
If the answer turns out to be that we need to use IFMatch on "type", that's going to be a real problem if that string value of "rain" or "snow" is returned in the user's chosen language. Don't Eskimo's have 1000 words for "snow" or some such?
Edit: Might have dodged the bullet there. I changed my language to French, and those values stayed a static "precip / rain / snow" and were not translated. That, and the fact that this is the only string that isn't capitalized, adds weight to the idea that the "type" is used as a key to determine the proper "unit", otherwise, why wouldn't they translate that... We will see...
jsmorley wrote: ↑February 9th, 2020, 4:44 amI don't use those "amount" and "type" measures in my skin, so not being sure about units is ok, while I watch to see if over some time we can figure out how they work. Then we will see if we need to jump through any hoops to use the right "units" for them.
If the answer turns out to be that we need to use IFMatch on "type", that's going to be a real problem if that string value of "rain" or "snow" is returned in the user's chosen language. Don't Eskimo's have 1000 words for "snow" or some such?
Edit: Might have dodged the bullet there. I changed my language to French, and those values stayed a static "precip / rain / snow" and were not translated. That, and the fact that this is the only string that isn't capitalized, adds weight to the idea that the "type" is used as a key to determine the proper "unit", otherwise, why wouldn't they translate that... We will see...
Exactly. I will use those units in my skin, so if I notice something happening often enough to be considered "sure", I'll let you know.
jsmorley wrote: ↑February 9th, 2020, 4:44 amYes, I know some measure names are getting pretty long, but I want to err on the side of "clarity" for this. Nobody is going to want to need to keep a reference guide in front of them. I want the meaning of the measures in About/Skins to be as obvious as possible.
Yincognito wrote: ↑February 9th, 2020, 1:31 pm
Exactly. I will use those units in my skin, so if I notice something happening often enough to be considered "sure", I'll let you know.
Also need to see if "precip", "rain" and "snow" are the only values returned. I could see "sleet" or "hail" or "frogs" or "meteors" and such perhaps.
jsmorley wrote: ↑February 9th, 2020, 1:47 pm
Also need to see if "precip", "rain" and "snow" are the only values returned. I could see "sleet" or "hail" or "frogs" or "meteors" and such perhaps.
Yes. Will keep an eye on this, because it's critical to my skin to know the length of the string values returned. I use unicode characters to keep the length of a tooltip "row" the same and right align values, for visual purposes, so whenever that length is changing, is bad for the skin. That's why I test extensively these things before publishing the result.
That being said, these values, in theory, should exist in the translation section (i.e. window.i18n = {...}), but for some reason don't. Maybe that's an indication that "rain", "precip" (probably some standard undefined type of rain) and "snow" are the only values possible for precipType.
Yincognito wrote: ↑February 9th, 2020, 2:06 pm
Yes. Will keep an eye on this, because it's critical to my skin to know the length of the string values returned. I use unicode characters to keep the length of a tooltip "row" the same and right align values, for visual purposes, so whenever that length is changing, is bad for the skin. That's why I test extensively these things before publishing the result.
That being said, these values, in theory, should exist in the translation section (i.e. window.i18n = {...}), but for some reason don't. Maybe that's an indication that "rain", "precip" (probably some standard undefined type of rain) and "snow" are the only values possible for precipType.
Be aware that you need to *escape* the measure name when you set it, or it won't work. It needs to be dynamic on the String measure. This is because the IfNotMatchAction "succeeds" on the first skin update, when the values for @ForecastTodayDayPrecipitationType and @UnitsPrecipitation have not yet been retrieved. You could alternatively use IfMatchMode=1 on the WebParser measure, but I like to avoid hammering things like that. I'm pretty sure the !SetOption is a tad more expensive than the DynamicVariables=1.
1.png
You do not have the required permissions to view the files attached to this post.
Be aware that you need to *escape* the measure name when you set it, or it won't work. It needs to be dynamic on the String measure. This is because the IfNotMatchAction "succeeds" on the first skin update, when the values for @ForecastTodayDayPrecipitationType and @UnitsPrecipitation have not yet been retrieved. You could alternatively use IfMatchMode=1 on the WebParser measure, but I like to avoid hammering things like that. I'm pretty sure the !SetOption is a tad more expensive than the DynamicVariables=1.
That looks good. I might very well use your method in my skin when I get to those fields. Right now my "current condition" is complete, but I would like to make a single set of measures for whatever forecast day is "active", instead of (number of forecast days x number of measures for a day), pretty much the same I did within my feeds skin. That way, the user will be able to control how many forecast days he would like to see, without bothering to copy-paste or cut dozens of new measures when he wants the number of days to be changed. This is something I wanted to do for a long time in my weather skin, but I didn't get the right "vibe" yet. Hopefully, this time will go smoothly, because the weather skin is the only one left in my set of skin that isn't fully "dynamic" yet.
The site will make a pretty decent effort to figure out where you are based on your IP address, and although it won't be as precise as specifying an exact location code you desire, it's not a bad starting point for a skin when a user first loads it. For many, it may even be good enough without them being any more exact.
In that case, the URL it will internally "use" will look like this:
Nice find indeed. Would that provide as accurate data as using the code, from what you've been able to notice?
Of course, one other option, if it turns out that the data is the same, would be to just use the geocode and forget about the TWC code. That should be easier to understand and find by the user.
EDIT: Just saw that you pretty much answered these things already. I have to fully wake up, my attention span is still sleeping at this point...