This page has been validated.

position, time of night, exposure length, and field of view, based on the public database of ephemerides. Current simulation work provides a strong basis for the development of such an application.

A browser-based interface will enable astronomers to predict what satellites will intersect with any given single observation. However, to be effective as a mitigation strategy, astronomers will need to use an interface optimized for planning observations in advance, adjusting either the pointing and/or the timing of the observation to minimize the number of satellite tracks or even (if possible) shifting the observation to a different observatory location/instrument field of view. This will mean multiple queries to the database with adjusted parameters for each observation. Together with the need for intensive observing programs and rapid response to transient events, this implies the need for an interface accessible from programs (i.e., an API) which would handle large batch requests with inputs and outputs in a parseable format (e.g., JSON). Deployment of a queryable system via the IVOA TAP protocol would leverage several existing application tools, such as pyVO. This program will be computationally intensive and may benefit from optimisations (such as grouping calculations of satellites in similar orbits) and from use of parallelization and GPUs.

3.2.1. Inputs and Outputs

Inputs:

  1. Ephemeris database (real or simulated) and in-orbit satellite list
  2. Observatory parameters: latitude, longitude, height
  3. Observation schedule parameters (right ascension, declination, date/time, exposure time, field of view, aperture)
  4. Satellite physical and optical properties (bidirectional reflectance distribution function [BRDF] etc.) including software model to predict brightness (advanced mode only)
  5. Streak minimum brightness threshold (advanced mode only)
  6. Photometric bands in which to estimate brightness (advanced mode only)
  7. Possibly, Satellite attitude ephemeris (needed to use the BRDF)

Outputs:

  1. Transit list: Satellite catalog number, time, probability, trail parameters+uncertainties.
    1. Trail parameters include satellite magnitude, trail surface brightness, trail width, trail start and end location.

The predicted trail location on the image may be too uncertain to be useful for actual predictions, but will be required for simulation exercises.

Accuracy requirements on inputs:

  • We consider two levels of accuracy: COARSE — enough to say if the field of view is affected; and FINE — enough to say where the streak will be in the field of view (ideally to the pixel level).
SATCON2 Algorithms Working Group Report
16