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

[pbutler6]

Thanks for the images with the moon phases. This certainly makes things easier.

I still have a problem with the moon rotation. I would like to maintain the phase orientation as the moon revolves around the circle. It is sort of like a Ferris wheel. You don't want the seats to be upside down at the top of the ride. I don't know if there is an easy way to keep the moon upright.

[SilverAzide]

I still have a problem with the moon rotation. I would like to maintain the phase orientation as the moon revolves around the circle. It is sort of like a Ferris wheel. You don't want the seats to be upside down at the top of the ride. I don't know if there is an easy way to keep the moon upright.

Well, perhaps I'm not following, but you DO want the seats to be upside down. What "upside down" is depends on where you are standing. The shadow on the moon doesn't change just because you are looking at it from Australia or from Norway.
Oh, sorry, I see what you are referring to. I had assumed you were "sliding" the moon along the arc, maintaining it's orientation.

[Yincognito]

Thanks for the images with the moon phases. This certainly makes things easier.

I still have a problem with the moon rotation. I would like to maintain the phase orientation as the moon revolves around the circle. It is sort of like a Ferris wheel. You don't want the seats to be upside down at the top of the ride. I don't know if there is an easy way to keep the moon upright.

Normally, it would be done like this:

Code: Select all

[Moon]
Meter=Rotator
MeasureName=SinceMoonrise
ImageName=#@#Moon.png
ImageRotate=(-([SinceMoonrise]/(24*60*60))*360)
X=(#Radius#)
Y=(#Radius#)
W=(#ImageW#)
H=(#ImageW#)
OffsetX=(-(#Radius#-#ImageW#/2))
OffsetY=(#ImageW#/2)
StartAngle=(PI)
RotationAngle=(PI*2)
DynamicVariables=1

Notice the ImageRotate option, which rotates the image counter-clockwise, proportionally with [SinceMoonrise], in degrees (not radians, since the unit differs for this option). However, what happens is that the size of the meter (being a rectangle, and not a circle) plays a part in this and thus the image "fluctuates" on the orbit (notice how here it's not exactly "centered" on the circle arc):

SunDial24H.jpg

I'm not sure how to fix this in a Rotator, probably modifying the X and Y as well accordingly according to some combination between the Pythagorean Theorem and the current rotation angle (aka [SinceMoonrise]), will have to think about it later on.

Another option would be to just use a plain Image meter (and not a Rotator) and move the meter on the circle "manually" using Sin() and Cos(). This isn't as complicated as it looks, but again, I will take a look at it later on (if SilverAzide doesn't come up with a solution in the meantime, that is).

That being said, I agree with SilverAzide, but from a different perspective: if you picture the Earth in the middle of the circle (in my own skin, a little Earth image is actually in the middle of it all, LOL - and although it wasn't really correct from an astronomical point of view, in the interest of looking good, I made it rotate around its center) and with its orientation on the Z axis (i.e. the Pole being visible and not the Equator), the moon rotating its phase in the Rotator is actually correct, since it always has the same "face" directed towards the Earth. So, from this point of view, trying to have the phase orientation static doesn't make that much sense. Just saying...

[pbutler6]

Any representation must compromise with reality.

If you were to stand at the Tropic of Cancer (23.5 degrees north) on the summer solstice the sun would rise in the east, reach an altitude of 90 degrees, and set 12 hours after sunrise in the west. However, if you were instead at the North Pole the sun will remain at 23.5 degrees above the horizon for the whole day -- if you stand facing the sun, then 12 hours later the sun would be directly behind you. If you were to stand on the equator the sun would reach an altitude of 78.5 degrees in the northern sky. And if you were at the South Pole the sun would be 23.5 degrees below the horizon for the entire day.

The moon makes a north-south journey similar to the sun, but on a 28-day cycle instead of a 365-day cycle.

My compromise is to view the moon from my point of view. When the moon is down it is blocked from view by the earth, but if I could look through the earth the view would be the same as when it is above the horizon. I live north of the Tropic of Cancer. If the moon is waxing, the left side will be dark whether the moon is up or down. (If I was viewing from Australia, the moon would still be waxing, but the right side would be dark. Between the Tropic of Cancer and the Tropic of Capricorn, it can even more confusing.)

For me, ImageRotate would give the desired view. Hopefully, there is a way to have it rotate on the arc.

Thanks for your help with a complicated problem.

[SilverAzide]

For me, ImageRotate would give the desired view. Hopefully, there is a way to have it rotate on the arc.

I thought another user tried this a little while ago and -- I could be wrong because the math involved gave me a migraine -- but I think he discovered that you can't rotate twice. In other words he couldn't rotate the moon along the arc AND rotate the moon to maintain its orientation. Something like that. You'd have to "slide" the image along the arc using math to find the X/Y position, then rotate the image to the proper view angle.

[Yincognito]

For me, ImageRotate would give the desired view. Hopefully, there is a way to have it rotate on the arc.

Thanks for your help with a complicated problem.

Well, the math part of the problem wasn't that complicated for me - and it wouldn't be for anyone, assuming they'd know how Rotator meters work (very important, even more important than the others), how to calculate the hypotenuse in a isosceles triangle (aka the diagonal of a square, the 32x32 pixel square in this case) and how to use Sin() and Cos() to either draw or simulate a "curved" path or set of values. I do admit it looked complicated at first sight, and I was leaning towards a simpler approach by moving the meter using Sin() and Cos() without a Rotator. But then I remember I love this kind of "tough" challenges, so here it is:

Code: Select all

[Moon]
Meter=Rotator
MeasureName=SinceMoonrise
ImageName=#@#Moon.png
ImageRotate=(-([SinceMoonrise]/(24*60*60))*360)
X=(#Radius#)
Y=(#Radius#)
W=(#ImageW#)
H=(#ImageW#)
OffsetX=(-(#Radius#-#ImageW#/2-Abs(Sin(([SinceMoonrise]/(24*60*60))*PI*2*2))*(Sqrt(#ImageW#**2*2)/2-#ImageW#/2)))
OffsetY=(#ImageW#/2+Abs(Sin(([SinceMoonrise]/(24*60*60))*PI*2*2))*(Sqrt(#ImageW#**2*2)/2-#ImageW#/2))
StartAngle=(PI)
RotationAngle=(PI*2)
DynamicVariables=1

What happens when reverse rotating the "image meter" in the Rotator at the same time with normally rotating the Rotator is that since the meter is actually a (static) 32x32 pixels square, the "corners" of that square change the distance to the center of rotation (aka the OffsetX and OffsetY), because the Rotator (rightfully) expects the image "frame" / "square" to be rotated as well and the offsets to remain constant. So, the offsets formulas need to adjust those offsets to compensate for the unavoidable change in their values. In other words, a subtraction is needed from the OffsetX and an addition is needed to OffsetY to make it all work.

The key in figuring out how much to subtract and add lies in the knowledge that those values follow the path of an (adjusted to 4*PI instead of the usual 2*PI, to match the "fluctuation" points from the orbit) Sin() graph, that has its maximum point of (Sqrt(W^2+W^2)-W)/2, where W is the length of a meter side, i.e. its width (or height, if you want, since at 32x32 it's basically a square).

So, in the end, I'm glad I followed the Rotator approach (the other approach presented nothing special to me, since I've done it before), because again, it seems the "impossible" is indeed possible. My conclusion is that the user SilverAzide mentioned didn't try hard enough - although he might have been referring to some other type of rotation that's kind of tricky in the case of Rotators (if that was the case, I'd have to agree with that user, as I've discovered that myself - fortunately, it wasn't the case here).

P.S. You can try placing 2 moon Rotator meters - one rotating normally without ImageRotate or the adjustments in OffsetX and OffsetY, and one with these additional changes - to check and see if the 2 moons' paths coincide. They certainly do for me - and if I didn't do that, I wouldn't have discovered that OffsetY needed the adjustment as well (albeit in the form of an addition instead of a subtraction).

[pbutler6]

Wow!! Fantastic job.

The new skin looks great. Your math skill are way beyond mine. Very impressive.

Do I have to reduce SilverZides images to 32x32, or is there a way to dynamically change the size on the go? The original images are 128x128.

[Yincognito]

For demonstration purposes - this final version takes the rise set data from weather.com's JSON and on idle just displays the "sundial" for now while on left click it starts a "simulation" animation iterating from day 0 to day 14 from weather.com's forecast by incrementing the "now" time with 5 minutes on each 25 ms update. One would probably need to adjust the code to suit his needs, of course.
Skin:

SunDial24H_1.0.0.rmskin

Preview:

ezgif.com-optimize.gif

I didn't get rid of the "jump" in the animation as that turned out to be simply because the data changes from one day to another (with the moon taking most of the hit since its 'up' period and rise / set times change day by day more than the sun's). I guess that could be adjusted by applying a 30.4 days Gregorian month to 29.5 days synodic month ratio, though I wasn't sure it would be entirely correct for all locations and didn't want to bother with more math at this time. I did choose the correct moonset though, i.e. if the current day moonset is less than the current day moonrise take the next moonset from the list. The animation will appear to have some "glitches" / "jumps" towards the end of the 15 day forecast, but that's only because I take the 0th index after the 14th using the modulo function in the interest of keeping the animation endless until it's "paused" using the same left click or stopped by refreshing the skin.

All in all, I'm happy with the result - after all it's not a skin that I would release to bother with it being absolutely perfect, and one has to admit the astronomical calculations and inter-relations are not that easy to get right. I even tested it on Novaya Zemlya's latitude and longitude to see how it behaves around the poles and it didn't do bad there either, considering many moonrises / moonsets missing from the data since...well, it's the poles and celestial bodies like staying there for longer, LOL. In normal usage one wouldn't notice those "jumps" anyway, since it's a millisecond in a day when the date is updated anyway, and one doesn't normally use the 15 day forecast in a sundial, but rather the current day (and possibly the next day) data. Me using the forecast was just to be able to animate the whole thing in order to "timelapse" the whole 2 week interval and notice potential discrepancies and problems.

[Yincognito]

Wow!! Fantastic job.

The new skin looks great. Your math skill are way beyond mine. Very impressive.

Do I have to reduce SilverZides images to 32x32, or is there a way to dynamically change the size on the go? The original images are 128x128.

Yeah, I'm afraid that you'll have to reduce them, as Rotators apparently don't handle image resizing very well (actually, not at all) - try to do this in either my skin or yours and change the ImageW=32 to ImageW=64 and you'll see what I mean. The formulas in the options are absolutely correct, so it may be that changing the W and H of the meter doesn't really translates into resizing the image itself - probably some limitation in Rotators due to their different purpose (and different meaning in the context) of the meter size compared to the Image meters. Or, it may be that it's a bug, but somehow I doubt on this one.

Glad you liked my approach - hopefully it will serve you well in your skin.

[pbutler6]

Too bad about the sizing.

My skin doesn't have the jump. The top hemisphere position is based on the percent of the circle since moonrise based on the current rise and set time as 50% of the circle and in the lower hemisphere, the position is based on 50% of the circle + the percent of the current set and rise times as the other 50% of the circle.

Code: Select all

[SinceMoonrise]
Measure=Calc
Formula= #Moonup#=1 ? (TimeNowStamp-#Moonrise#)/(#Moonset#-#Moonrise#) : 1 + (TimeNowStamp-#Moonset#)/(#Moonrise#-#Moonset#)
MaxValue=2
Group=Sun&Moon
Disabled=1
DynamicVariables=1

I had to do some calculations and shifting to figure out which JSON "day" is the right day for "now" because the Weather.com day changes at 3 AM and there is at least one day each month when the moon doesn't have a rise time and at least one that doesn't have a set time. So the rise time and the set time often from different days. That doesn't matter so long as the current hemisphere is using the correct start and end times.