Hello everyone,
Not earlier than 27th of August, we are planning to release the next version of SatNOGS Network software, the version 1.128. At the same date we are going also to release SatNOGS DB.
In this release there are several bug fixes and several changes and enhancements in the UI and the API. The main changes are multi-veting 1st phase, station status changes and the culmination/horizon station settings. Read more about the below.
Here are three notable changes and one of them needs some attention as it breaks the observation API endpoint:
-
In this release we deploy code developed for the 1st phase to support mutli-vetting. Currently only one vetting is available per artifacts (currently only for waterfall artifact), but after the release each user would be able to vet separately artifacts.
This new feature opens the way for other changes that will come in the next phases and will improve rating/vetting of observations and artifacts. Some of them are vetting through API, vetting with the help of internal or external bots (AI or not), vetting all the artifacts not only waterfall, add and expose certainty in observation rating etc.
Due to the changes above, we have now removed the “vetted_status” field in the observations API endpoint. This field was set as deprecated in previous release as it has been replaced by the “status” field.
-
Another important change introduced is the changes in the station status. Currently we have three values for the status: “online”, “testing” and “offline”.
However pretty early (first issues opened 8 year ago) became obvious that these values are describing and used to implement three different properties of the stations. Connection status (online/offline), Availability of using a station (available/not available), Testing status (station is or not under testing its functionality, performance or configuration).
Thus we remove the old status and introduce these three different properties, “is_connected”, “is_available”, “testing”. These fields will be exposed to the station API endpoint together with the deprecated “status” field which will remain for now for backwards compatibility.
The “status” field in the API will get these values depending on the three properties:
Status values “is_connected” “is_available” “testing” Online True True False Offline False True/False True/False Offline True/False False True/False Testing True True True Station owners will be able to change the availability of their stations by editing their stations and un-check the related checkbox in the “Settings” section.
These changes also introduce some changes in permissions and who and when can schedule a station. Currently you can review all the details in the related issue, these details will be transferred to the wiki in the Network Permissions Matrix section.
A quick summary of the above is that unavailable stations will not be available for scheduling (with exception of admins after an agreement with the station owner), testing stations now will be available to anyone with scheduling permissions for scheduling in order to allow other station owners to help in testing these stations.
Given that until now testing stations were scheduled only by their owners and admins, we are going to set all the current testing stations as testing and unavailable in order to avoid any unwanted scheduling.
Introducing availability as a property, will open the way in a future release to add the feature to schedule non-availability periods for a station either through UI or through an API endpoint.
-
Introducing “Minimum Culmination” and “Minimum Horizon” settings for stations. This is another wanted-for-years feature as the current min horizon setting describes two different properties.
One is from which elevation observation should start and to which elevation should end, this will now be described by “Minimum Horizon” setting. The other property defines the minimum elevation observations should have in order to be scheduled in this station, this will be described by the “Minimum Culmination” setting.
Both settings will have an additional checkbox that will set if each limitation is a hard one or it can be overridden (in advance settings in scheduling page). Not using hard limits will be helpful to schedule passes that track satellites with not accurate orbital data/TLE for example during new deployments.
However it is known that in some cases, mostly due to hardware limitations/installations, these limits should not be overridden, thus we added this option.
For better understanding you can read this example in the related issue, which will be updated and used in the user documentation in the wiki.
-
Another feature important for some station owners is the introduction of deleting future observations through the observations API. The deletion though the API will be allowed for now only by the station owner and not by admins or observation’s author.
More or less these are the most notable changes, more details on all the developments/features/fixes will be available in the release notes. If you have any questions or comments, please reply to this thread.