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

[Yincognito]

Hello everybody,
Just got home from my holiday. As such, I have to admit I didn't follow closely this topic (and nor any other), so I have to appologise. Accordingly, now my question is if is there anything I can / have to do related to this topic.
Sorry about this...

Hehe, welcome back, balala - I hope your holidays were great and you didn't catch anything "suspicious".
I'm not sure about the answer to your question, I will probably do things my way even if help comes (that's just the way I am, I must completely understand the things I use before using them, and that's a bit harder when it's someone else's work), but for sure pbutler6 or Mor3bane would be happy to "hear" your opinion about the things discussed in this thread.

To summarize, we built different versions of a "24 hour sundial" using Roundlines and Rotators, basically a circle on which the sun and moon are 'up' (risen) in the upper part of it and are 'down' (set) in the lower part of it. All things went well from a visual and parsing point of view, but there is this problem when on the data source changing its "current day" to the following one, it affects the sun and moon (the sun effect is insignificant, unlike the moon's) positions on their arcs because the values for the rise and set times change from a day to another. The mistake was probably treating the current day as a singularity, when in fact the rise and set times for the previous and the next day (days, in certain scenarios) matter because they might contain the rise or set "pair" of the current day's moonset or moonrise. The fact that the weather.com's API doesn't provide the previous day(s) rise and set times is part of the problem, because, for example, when there is a moonset at 02:30:00 in the current day, it's obvious that the moonrise of that rise + set cycle (which is needed for calculations) happened either the previous day or in some cases more than one day ago - but the weather.com API doesn't provide that data.

I'm currently investigating taking the data from the Weather.com's Astro API (you posted a reply on that thread, you probably know what I'm talking about), because unlike Weather.com's weather API, it allows setting the "start day" to a day in the past, and not necessarily today.

That being said, I might have a question: normally the local computing of rise and set times is pretty complicated. Do you know of a simpler way? Oh, and by the way, if it involves Lua I'll pass.

[pbutler6]

I currently calculate yesterday's values. My calculated value for yesterday's sunset is very close (I change the time of sunset by 1/2 of the day length change from yesterday from WeatherUnderground), but my calculations are a little less accurate for the moon (using the same change for yesterday as today is from tomorrow.) Still, the moonset and moonrise times are normally within a couple of minutes of the right time.

I await Yincognito's solution. The easiest answer is to find a source for yesterdays' values. If that is not possible, one way to improve on my method is to save today's values to a moonset variable and a moonrise variable and then use these variables for yesterday's values if the skin has been running for more than a day.

[Yincognito]

If that is not possible, one way to improve on my method is to save today's values to a moonset variable and a moonrise variable and then use these variables for yesterday's values if the skin has been running for more than a day.

Yeah, thought about this approach as well, but it has a flaw: if the skin didn't yet run, you have no saved variable. Another possibility is to just take one year's values (there are sites which provide that) and then you'll be going smooth and have all the values you need - and the skin would only need to be updated once a year, LOL. The latter has a smaller problem though, as rise and set times are often adjusted during the course of a year. Typically those adjustments are small, but they do exist.

[pbutler6]

I was thinking that my calculations could be entered as initial values when the skin is loaded but then updates could use the saved variables.

[balala]

Hehe, welcome back, balala - I hope your holidays were great and you didn't catch anything "suspicious".

Thanks God, not. At least not so far. Hoping the best...

but there is this problem when on the data source changing its "current day" to the following one, it affects the sun and moon (the sun effect is insignificant, unlike the moon's) positions on their arcs because the values for the rise and set times change from a day to another.

The differences between the Sunrise / Sunset from a day to the next one are not too high, up to a few minutes. But in case of the Moon, these diferences are much larger, half an hour - hour, or even more, which causes these troubles. I faced the same problem long time ago, when I was working with different codes, but found no good solution.

The fact that the weather.com's API doesn't provide the previous day(s) rise and set times is part of the problem, because, for example, when there is a moonset at 02:30:00 in the current day, it's obvious that the moonrise of that rise + set cycle (which is needed for calculations) happened either the previous day or in some cases more than one day ago - but the weather.com API doesn't provide that data.

If the Moonset is for instance at 2:30:00, it definitely rises up somewhere on afternoon. On my SunMoon skin (which calculates the Sun / Moon rise / set for the current day), this is not a problem, because that skin only shows these times, but if you want to use them for a graphic visualization, that's a completely different question.
Although I faced some similar problems, as said above, found no good solution.

That being said, I might have a question: normally the local computing of rise and set times is pretty complicated. Do you know of a simpler way? Oh, and by the way, if it involves Lua I'll pass.

It definitely involves lua scripts. I doubt these calculations can be made in native Rainmeter codes, being enoughly complicated. Probably the simplest solution is to get them online, as you did.

[Yincognito]

Thanks God, not. At least not so far. Hoping the best...

The differences between the Sunrise / Sunset from a day to the next one are not too high, up to a few minutes. But in case of the Moon, these diferences are much larger, half an hour - hour, or even more, which causes these troubles. I faced the same problem long time ago, when I was working with different codes, but found no good solution.

If the Moonset is for instance at 2:30:00, it definitely rises up somewhere on afternoon. On my SunMoon skin (which calculates the Sun / Moon rise / set for the current day), this is not a problem, because that skin only shows these times, but if you want to use them for a graphic visualization, that's a completely different question.
Although I faced some similar problems, as said above, found no good solution.

It definitely involves lua scripts. I doubt these calculations can be made in native Rainmeter codes, being enoughly complicated. Probably the simplest solution is to get them online, as you did.

Yep, thought so, thanks for confirming it (given your extensive past experience with these sort of things).

[balala]

Yep, thought so, thanks for confirming it (given your extensive past experience with these sort of things).

[Mor3bane]

Hello,

I was just going to chime in on the level of accuracy being aspired toward with all of the fancy maths.

This isnt really meant to be a compass to determine safe travel through the expanses of the greater oceans, it is just really only needing to be a close approximation.

I havent been able to get a close approximation with my poor trigonometry skills, so I asked for those with better maths skills to assist. But the level of detail is just way too much and there is really no need for such perfection.

It was just my hopes that if the moon was up, in the east and rising, for example, that the prospective skin would reflect that - if not imperfectly - but better than I alone could math-out to accomplish.

Any way your time is your own and I am just chiming in to say thanks for looking into all of this detail, but its really not necessary - it isnt...

[Yincognito]

Hello,

I was just going to chime in on the level of accuracy being aspired toward with all of the fancy maths.

This isnt really meant to be a compass to determine safe travel through the expanses of the greater oceans, it is just really only needing to be a close approximation.

I havent been able to get a close approximation with my poor trigonometry skills, so I asked for those with better maths skills to assist. But the level of detail is just way too much and there is really no need for such perfection.

It was just my hopes that if the moon was up, in the east and rising, for example, that the prospective skin would reflect that - if not imperfectly - but better than I alone could math-out to accomplish.

Any way your time is your own and I am just chiming in to say thanks for looking into all of this detail, but its really not necessary - it isnt...

Don't worry, the project isn't abandoned - I just put it on hold for a little while since a small break is usually providing me with better ideas on how to tackle this in a way that I would be satisfied (as I'm not easy to be satisfied when it comes to things, see your mention of perfection). I can only speak for myself, but if something is not perfect, I don't do it, that's just the way I am - it's not about you or anyone else, I just don't feel "ok" with it, that's all.

The skin will be able to grab a sh..load of data from the weather.com Astro API, so if needed will be able to display a ton of stuff. For now however I'm just thinking how to best approach this rise / set in another day, whether it will be based on indexes and taking previdx2 / previdx1 or nextidx1 / nextidx2 fields, or some time comparison using Time measures (here I don't like Time measures giving errors on blanks, for example, so I need to format that blank beforehand), or some String based approach that will remove "invalid" rise set times from their string to end up with just the times one needs, etc. So far I have all the rise set times well placed in comma separated string lists from the Astro API (from two days ago from the current day to two days away from the desired day count - that would be 19 days for a 15 day forecast), and as soon as the correct rise set times will be identified based on that, the rest will be trivial - so it's just one hurdle in the way, really.

I won't state a deadline for this as I don't like to state such things only to be delayed by various things like in the past few days, but rest assured it WILL going to happen. I will work well, without jumps, with proper accuracy and all. I work for myself as well, not just for others, and as I said, I came to like this "sundial" thing so I want to have my own version well done and pretty as well.

[pbutler6]

I'm glad to hear it's in the works. I'm still working to get the rotator part working the way I want (I'm also trying for perfection).