It is currently March 29th, 2024, 10:41 am

Weather Json [new stuff] Moon Position on a 24 hour Roundline/Rotator ?

Get help with creating, editing & fixing problems with skins
User avatar
Yincognito
Rainmeter Sage
Posts: 7029
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: Weather Json [new stuff] Moon Position on a 24 hour Roundline/Rotator ?

Post by Yincognito »

pbutler6 wrote: September 6th, 2020, 2:15 pmI am getting my times from www.wunderground.com/weather/, not https://api.weather.com/v2/
So, in other words, the times and such are correct, right?
Regarding the source for the times, does wunderground.com allow setting the interval for which you want data for? For example, can I request something like "give me data from 2 days ago until 17 days from now" (i.e. from 04.09.2020 to 22.09.2020)?
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
pbutler6
Posts: 100
Joined: April 27th, 2020, 8:10 pm

Re: Weather Json [new stuff] Moon Position on a 24 hour Roundline/Rotator ?

Post by pbutler6 »

Most of the times are pretty close. The only discrepancy is for yesterday. I don't think wunderground.com or weather.com have data for yesterday. However, after the 3 AM reset sunset time is yesterday's sunset, not today's, and moonrise and moonset times can be yesterday's times for several hours.

Right now I am estimating these times. I am thinking to improve this by saving today's times to a file and moving today's times to yesterday's times when there is a difference between the downloaded times and the stored times. On a skin reset I would estimate yesterday's times (just once) and then compare the calculated times with the stored times. If the calculated times are more than some interval (1 to 2 hrs) after the stored times, then I would store the calculated times as yesterday's times.

With this calculation, yesterday's times will be the times that were downloaded yesterday except when the skin wasn't running yesterday, and then the times will be the estimated times that I have calculated.

I haven't tried to program this yet. It really wouldn't make much of a change in my times and would only be for the programming challenge. :) This would be a whole lot easier if I found a source for yesterday's values. :(

As you point out, things become harder above 67 degrees of latitude. I know this is a programming challenge. However, I expect that the only reliable way to derive these times is to calculate them directly and not use a website source. At the north pole, from the spring equinox to the fall equinox the sun will only traverse the 180-degree upper arc of your skin for 6 months. While it may be possible to include these regions, there are no permanent residents living south of 67 degrees south and only a few thousand people living permanently north of 67 degrees north. For most of these polar regions, internet service is very slow (satellites are close to the horizon and there is very little bandwidth). So if you do manage to calculate values for the polar regions, there are very few people to use the information, and their internet connection may be limited as well. (Probably full committed to cat videos.) :D
User avatar
balala
Rainmeter Sage
Posts: 16110
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: Weather Json [new stuff] Moon Position on a 24 hour Roundline/Rotator ?

Post by balala »

Yincognito wrote: September 6th, 2020, 2:43 pm Yeah, I know about it. It's no big deal and not a timing issue, just a division by 0, due to (Event1-Event0) for the sun and moon being 0 in those measures at the start (since Event1 and Event0 for the sun and moon are themselves 0 at skin refresh, thus 0-0=0 and one can't divide by 0). It's not affecting the calculations in any way, it's more a matter of comfort for the user to not see those harmless errors popping up in the Log.
There is an extremely simple solution to fix these kind of errors: you have to add an extremely small, but non-zero value to the denominator. For instance if you add such a constant, the Formula option of the [SinceSunEvent] measure should become: Formula=(((#SunUp#=1)?(0):(0.5))+(#NowEvent#-#SunEvent0#)/(#SunEvent1#-#SunEvent0#+0.000001)/2), while the Formula option of [SinceMoonEvent]: Formula=(((#MoonUp#=1)?(0):(0.5))+(#NowEvent#-#MoonEvent0#)/(#MoonEvent1#-#MoonEvent0#+0.000001)/2).
No more error messages.
User avatar
Yincognito
Rainmeter Sage
Posts: 7029
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: Weather Json [new stuff] Moon Position on a 24 hour Roundline/Rotator ?

Post by Yincognito »

balala wrote: September 6th, 2020, 7:13 pm There is an extremely simple solution to fix these kind of errors: you have to add an extremely small, but non-zero value to the denominator. For instance if you add such a constant, the Formula option of the [SinceSunEvent] measure should become: Formula=(((#SunUp#=1)?(0):(0.5))+(#NowEvent#-#SunEvent0#)/(#SunEvent1#-#SunEvent0#+0.000001)/2), while the Formula option of [SinceMoonEvent]: Formula=(((#MoonUp#=1)?(0):(0.5))+(#NowEvent#-#MoonEvent0#)/(#MoonEvent1#-#MoonEvent0#+0.000001)/2).
No more error messages.
Yes, I know, and you're right. I chose to divide by 1 instead of 0, probably out of (an unfounded) concern of not affecting the result of the calculations for the positions on the arcs.
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
User avatar
balala
Rainmeter Sage
Posts: 16110
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: Weather Json [new stuff] Moon Position on a 24 hour Roundline/Rotator ?

Post by balala »

Yincognito wrote: September 6th, 2020, 7:57 pm Yes, I know, and you're right. I chose to divide by 1 instead of 0, probably out of (an unfounded) concern of not affecting the result of the calculations for the positions on the arcs.
A such small constant as +0.000001 (which I proposed above) doesn't affect the result at all.
User avatar
Yincognito
Rainmeter Sage
Posts: 7029
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: Weather Json [new stuff] Moon Position on a 24 hour Roundline/Rotator ?

Post by Yincognito »

pbutler6 wrote: September 6th, 2020, 6:48 pmI am thinking to improve this by saving today's times to a file and moving today's times to yesterday's times when there is a difference between the downloaded times and the stored times. On a skin reset I would estimate yesterday's times (just once) and then compare the calculated times with the stored times. If the calculated times are more than some interval (1 to 2 hrs) after the stored times, then I would store the calculated times as yesterday's times.
Yes, this is probably the simplest solution, as we already discussed earlier. I wanted precision and availability as well though, so I wasn't quite happy with doing an estimation or rely on present or absent data in an .inc file. It was an approach I considered though. I guess in the end it's the choice of the skin designer. From my point of view, one either needs to be precise in astronomical matters or don't do them at all - but that's just me.

I also wanted to avoid having dozens of measures to choose the values from, or to permutate / move from today to yesterday, from tomorrow to today and all that - it just made my head spin like crazy, LOL. I'm really confident that identifying the interval the now time belongs to is the best logical and mathematical solution to this if we talk about parsed data - after all, that's how humans process that information as well when looking at the data. It might not be the most comfortable approach in Rainmeter's native code, as FOR / WHILE loops are stuff of programming languages (like Lua), but then I'm not a fan of half code in native Rainmeter and half in Lua - for me it's either one or the other. There are already solutions that do all this calculations to get the times locally in Lua, but none (that I know of) really appropriate in Rainmeter code using parsed data, so I took the opportunity to try it and I'm really happy with the result. It also felt like (yes, I said it) "reinventing the wheel" to calculate or estimate something that has been already calculated and estimated by people much more familiar with these things than us - hence I took the parsed data route instead of doing calculations locally.

Regarding latitutes and such, I hate half done solutions. If I'm not able to do something that works for whatever scenario you throw at it (like above 67 degrees latitudes in an astronomical related skin), I just don't do it, simple as that. I really don't care what kind of internet connections do they have at those latitudes or if people live there or not - could be aliens or giant ants there for all I care - it's the quality of the solution that matters to me rather than the "audience" the solution has, and this won't change. I'm equally happy if the solution is used by a half a million people or just me, but I just can't stand it not to work for certain values or to be limited by a "valid range" less than the actual valid range.
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
User avatar
Yincognito
Rainmeter Sage
Posts: 7029
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: Weather Json [new stuff] Moon Position on a 24 hour Roundline/Rotator ?

Post by Yincognito »

balala wrote: September 6th, 2020, 8:30 pm A such small constant as +0.000001 (which I proposed above) doesn't affect the result at all.
You're absolutely right, which is why I said that it was an "unfounded concern" from my part. :thumbup:
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
User avatar
Yincognito
Rainmeter Sage
Posts: 7029
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: Weather Json [new stuff] Moon Position on a 24 hour Roundline/Rotator ?

Post by Yincognito »

dvo wrote: September 6th, 2020, 8:16 pm had just a little glitch in weather.com saying it's 1601 :o but refreshed after 4 sec with all oke.. :D
Hahaha! You made my day. Yeah, those 0 timestamps are used a lot to reflect "invalid" or "absent" times. Though I'm not sure which skin you're talking to... :D
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
pbutler6
Posts: 100
Joined: April 27th, 2020, 8:10 pm

Re: Weather Json [new stuff] Moon Position on a 24 hour Roundline/Rotator ?

Post by pbutler6 »

Here's the sun information for Alert Canada for August:
Screenshot 2020-09-06 174238.jpg
If you want to be able to show the Sun position viewed from Alert using a web data source you will need to look beyond weather.com or wunderground.com :-( However, it definitly is a programming challenge. :great:
You do not have the required permissions to view the files attached to this post.
User avatar
Yincognito
Rainmeter Sage
Posts: 7029
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: Weather Json [new stuff] Moon Position on a 24 hour Roundline/Rotator ?

Post by Yincognito »

pbutler6 wrote: September 6th, 2020, 9:52 pm Here's the sun information for Alert Canada for August:Screenshot 2020-09-06 174238.jpg

If you want to be able to show the Sun position viewed from Alert using a web data source you will need to look beyond weather.com or wunderground.com :-( However, it definitly is a programming challenge. :great:
I agree that looking beyond those two is required, but I don't see it as a programming challenge - it's a source challenge (I am talking from the skin I posted point of view). The Astro API does indeed limit its days interval to 30, so a 5 month interval (corresponding to the time between the last sunrise to the first sunset for that location) isn't possible to get from there, but as I said, there are plenty of other sources offering whole year "calendars" with rise and set times, so as long as the source is changed and the regex (i.e. the Substitute in the [Sunrises], [Sunsets], [Moonrises] and [Moonsets] measures) to build those 4 initial sun and moon rise and set lists is adjusted, the rest will work as expected. It's been a long time since I used it, but I believe the NASA source was suitable for it, too bad is unavailable at the moment.

Of course, the new source should be able to provide data that can be parsed with WebParser.

My point is, the "framework" to deal with this is done (i.e. the "hard" part). Now it's just a matter of slightly adjusting the source or the framework to the source.
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth