Stellarium / stellarium-web-engine

JavaScript planetarium engine
426 stars 89 forks source link

Azimuthal Data changes for Past Dates #128

Open ghost opened 2 years ago

ghost commented 2 years ago

There appears to be an issue when one enters a date or time and freezes time to refect such moment in time (instead of just using the default of current time and location advancing in real time).

This apparent issue occurs regardless on entering a time in the past or future.

The Azimuthal grid and data for objects change. This occurs whether one reenters the same date and time again (either by switching the time and then going back to the original entered values -- during the same session on is on the website), or if one closes the website and opens tge website again and then reenters the same original time entry).

Examples: The first set of images show entering a date and time in the past [set and frozen at date 1986-07-08 and time 18-16-17]. The location selected is Chicago, IL. The associated first sky-image shows a star with its RA/DEC values and Az/Alt values. After changing the date-time values then changing them back to the original entries (while still keeping the website open), the associated second sky-image shows that tge Az and Alt values have changed. Note: the registered RA/DEC values remain unchanged.

The second set of images show that the same apparant issue occurs when closing the website, then going back to it and reentering the same date and time one did before.

Note: this fluctuation appears to impact Az to a greater shift than it does Alt.

This "fluctuation" [shifting] of the Azimuthal grid and associated Az and Alt values brings up different values each time one reenteres the original date. Therefore, it appears that date and time entries in the past or future do not consistently show the actual [or calculated] Azimuthal values.

These changed [calculated? derived?] azimuthal values and grid in fact should not change. They should remain the same as long as the same date and time is entered. The sky images should reflect a given moment in time for such past and future dates as long as the "viewing" is from the same entered location. 01 01 DateTime Entry 01 02 Location Entry 01 03 Sky Image Star Selected 01 04 Sky Image after DateTime Reentry 02 01 DateTime Reentered on New Website Session 02 02 Location Reentered during New Session 02 03 Sky Image and Star Data at new Session

gzotti commented 2 years ago

You are talking about differences of few arcseconds. Can you guarantee that the position on the ground did not change by ~20-50 metres? If yes, it may also be some rounding error.

ghost commented 2 years ago

As the screenshots demonstrate, yes the location is exactly the same every time. If you or anyone else enters any date in tbe past and future, checks any star or position or any Azimuthal point -- then changes the date or exits the website, the reenters the same date/time/location again -- they will see the Az and Alt discrepancy.

Note: I use the website's feature as designed for Android devices. Specifically, I enter the name of a desired city (Chicago, Detroit, Bangor, etc), then select from the options that come up on the Stellarium list of matching cities. For the examples attached, this was Chicago, USA, showing the exact same coordinates each time.

I have tested this over 50 times with different cities from the list. Each time the Az/Alt position and data changes. The fluctuations I have seen mostly show a difference of up to 5 areseconds.

I do not know if the discrepancy lies in how the "behind the scenes" logic interprets the exact same date, time, and location entries. Are there are fractional differences to the seconds field [adjusted behind the scenes, and possible imoacted by the time-pause field] for which a user would be ignorant? The way the time entry is displayed, we select whole number integers via the up-down arrows to change each time field.

Or maybe there are other limitatiins in the screen's displaying and plotting the Azimuthal grid and data calcs upon refreshing them (or how the screen refresh logic reinterprets reentry of the same date/time/location data)?

If accuracy [or at least consistency] is the intention of the designers, then Azimuthal data should not change when viewing the same date and time from the same location.

On the otherhand, if the goal if Stellarium is to only have very very clise but different approximations If every time the Azimuthal display is refreshed, then maybe a difference of arcseconds is acceptable to them. If so, it may be helpful to note this fudge factor [allowance] in the Stellarium documentation. That way, users with a different expectation will know the Stellarium Azimuthal grid can not be used by those who require precision for past or future dates, but only a varying degree of approximation.