You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Meteorflux should have three databases with different interfaces and roles/rights.
real-time graph: Every active camera send a short http / JSON message every minute, and from these data we generate real-time plots for all active showers. This interface will be described in more detail later.
intermediate graph: Every time an observer post-processes his own observation of one night, the flux data will be uploaded automatically via http / zip file to this interface The data quality is already improved (the observer deleted false detections) but not perfect (individual observers may use different shower lists, some observers will upload their flux data at the next days, others only after weeks or months).
final graph: This interface has the biggest delay (right now about 6 month) but offers the best data quality: Once all data are collected and doubled-checked, I re-calculate the flux densities for a full month with the standard set of meteor showers, and manually upload the data set via http / zip or sftp / zip at once.
Each graph shall have it´s own database and there are no plans to sync these databases.
The real-time graph has a special UI, but the intermediate and final graph have the same UI with the same parameters to be selected. The user should have the option to decide which dataset (intermediate or final) to use.
The first and second graph need no special data handling: Every observer can upload his data. If he uploads the data twice, the old data set will be overwritten. No admin access is required.
Data upload for the final graph should only be allowed for the admin. The following functions are required:
upload of a data set (ZIP)
deletion of data set (by year, year & month, year & month & day, year & camera, year & month & camera, year & month & day & camera)
Before data are overwritten, I should get a warning.
All interfaces should be protected with basic authentication (username/password). For the first and second interface, all users share the same username/password. The third interface has an own admin user / password.
The text was updated successfully, but these errors were encountered:
Meteorflux should have three databases with different interfaces and roles/rights.
real-time graph: Every active camera send a short http / JSON message every minute, and from these data we generate real-time plots for all active showers. This interface will be described in more detail later.
intermediate graph: Every time an observer post-processes his own observation of one night, the flux data will be uploaded automatically via http / zip file to this interface The data quality is already improved (the observer deleted false detections) but not perfect (individual observers may use different shower lists, some observers will upload their flux data at the next days, others only after weeks or months).
final graph: This interface has the biggest delay (right now about 6 month) but offers the best data quality: Once all data are collected and doubled-checked, I re-calculate the flux densities for a full month with the standard set of meteor showers, and manually upload the data set via http / zip or sftp / zip at once.
Each graph shall have it´s own database and there are no plans to sync these databases.
The real-time graph has a special UI, but the intermediate and final graph have the same UI with the same parameters to be selected. The user should have the option to decide which dataset (intermediate or final) to use.
The first and second graph need no special data handling: Every observer can upload his data. If he uploads the data twice, the old data set will be overwritten. No admin access is required.
Data upload for the final graph should only be allowed for the admin. The following functions are required:
Before data are overwritten, I should get a warning.
All interfaces should be protected with basic authentication (username/password). For the first and second interface, all users share the same username/password. The third interface has an own admin user / password.
The text was updated successfully, but these errors were encountered: