Open micahnyc opened 3 years ago
(As reported by Ken at SMSU)
Maybe the perfectly spherical earth?
--local earthEllipsoid = { 6378137.0, 6378137.0, 6356752.314245 }
local earthEllipsoid = { 6378137.0, 6378137.0, 6378137.0 }
Good point!
@jccosta What was the reason for the non tri-axial ellipsoid? Shouldn't it be possible to apply a non uniform scaling to the scene graph now that we have that type?
@alexanderbock, the reason for the non-tri-axial ellipsoid is partly because of the eclipse shadow's calculation and partly because of the atmosphere's calculations. I think the problem with the eclipses' shadows alignment is one of (or all) the following (order by what I think is more probable): 1) The initial premises when calculating the eclipses. It is a geometric approximation of planets and the Sun in 2D, extended to 3D. Here, the Sun and the planets are considered perfect spheres 2) An error in the eclipses' calculation 3) Precision issues in the calculations (we are using double precision for all calculations, but we are talking about comparisons between large distances and small position on the globe) 4) GDAL tile positioning (although I think this is very improbable of happening, if the three points above are discarded, we may need to investigate this further)
Certainly hits St. Louis better at 18:19 on Aug 21, 2017, when the earth is oblate:
local earthEllipsoid = { 6378137.0, 6378137.0, 6356752.314245 }
(Though I'm not sure why my shadows are so chunky? - different issue I guess)
To check: Maybe it is related to the SSB/Sun position offset that we had before
So, the position of the eclipse was not improved by the SSB/Sun position change (image from master as of July 5, ffd3514b773db823b644f582a2d8fca8aee3740f). Looks like the same offset as before
with the spheroid radii in v 17
local earthEllipsoid = { 6378137.0, 6378137.0, 6356752.314245 }
Though, things might now be off by a minute or two (that I don't remember from before). at 18:19 GMT:
vs.
Also, this was done with the oblate spheroid for the Earth asset. (and some tweaks to atmosphere so that the height at NYC latitude was correct.) It seemed pretty close to what others predicted.
Though, things might now be off by a minute or two (that I don't remember from before).
Good catch @hedbergj. My first thought is that maybe the shadow might be offset with the same difference that the sun position had after the SSB/Sun position update... 🤔 Someone gotta look into this
Yeah @WeirdRubberDuck - that's probably the case. My current master is from before the atm updates @alexanderbock did very recently. Those might fix the timing for the atmosphere shadows, but then also the globebrowsing tile eclipse shadows might need to be looked at too. Changes in SSB/Sun should affect longitudinal (e/w) errors more than latitude (n/s) I bet.
Yeah @WeirdRubberDuck - that's probably the case. My current master is from before the atm updates @alexanderbock did very recently. Those might fix the timing for the atmosphere shadows, but then also the globebrowsing tile eclipse shadows might need to be looked at too. Changes in SSB/Sun should affect longitudinal (e/w) errors more than latitude (n/s) I bet.
Ah, I see. For completion then, here's how it looks with the oblate spheroid Earth, including the atmosphere code updates from @alexanderbock. Hits St Luis pretty well but I'm unsure about the timing. Looks like it might be off by close to a minute, if comparing with this tool
Maybe related to the sun position to be hardcoded to (0,0,0)? We have an issue for it, but I wasn't able to find it
Maybe related to the sun position to be hardcoded to (0,0,0)? We have an issue for it, but I wasn't able to find it
You closed it as a duplicate. I just reopoened it https://github.com/OpenSpace/OpenSpace/issues/2243
As seen in attached images in comparison to eclipse tracker websites showing path of totality.
https://eclipse.gsfc.nasa.gov/SEgoogle/SEgoogle2001/SE2020Dec14Tgoogle.html http://xjubier.free.fr/en/site_pages/solar_eclipses/TSE_2017_GoogleMapFull.html