Path forward for a better functioning JPL Scout interface?

[talister]

As a Planetary Defender, for follow-up of the larger number of new Rubin (and potentially NEO Surveyor) NEO discoveries, and potential source of Rubin ToO triggers, I would like to be able to ingest and update close-passing NEOs from the JPL Scout service (API docs) into a TOM e.g. FOMO.
As highlighted by #837 the current Broker code has limited functionality (the current creation of a NON_SIDEREAL Target with only a snapshot RA and Dec for such fast moving objects has little to no utility) and as detailed in #1108 , the Broker infrastructure is being replaced by TOM Data Services. The following is a list of required improvements for the TOM Toolkit Scout interface to be useful for the purposes described above:

• Targets need to be created and updated with the orbital elements obtainable from the '?orbits=1' API query parameter. A measure of the orbit quality (e.g. RMS and/or no. of obs) is needed for these rapidly evolving knowledge of these objects. (TBD (by FOMO folks): How many of the up to 1000 Monte Carlo orbit clones do we need with the n-orbits=X API parameter)
• Targets created from Scout need to be easily and rapidly distinguished both visually and via Django filtering
• There are a set of quantities on the Scout summary page that are desired to be filtered on by different users/cron tasks within the TOM (but which can't be pre-filtered in the Scout summary API). These include:
  • POS Unc (Positional uncertainty now)
  • POS Unc+1 (Positional uncertainty in +1 day)
  • Impact rating
  • CA Dist (close approach distance (in lunar distances))
  • NEO score (0...100 score on chance of being a NEO)
  • Geo. score (0...100 score on being a geocentric object i.e. artificial satellite (to be ignored))
    There needs to be a way of specifying cuts on these parameters to the Scout interfacing service so it can filter down to the objects that pass before creating/updating targets
• Needs to be an easy way to re-poll Scout and update Targets in the background, which can handle Scout targets being removed (after they are no longer a threat or (more rarely) impact) without losing the history of the TOM Target
• A way to send alerts to users when a new object appears that passes a threshold (e.g. Impact Rating>=3, NEO>=90, Geo. <5) or when an existing Scout object cross a threshold (e.g. Impact Rating goes from 1 to >=2)

Some of this e.g. item 1, probably 2-3 are doable by the FOMO team now with the existing code but I don't want to waste time and effort on a dead-end code subsystem (unless there's substantial code reuse). What's the best way forward for getting this improved functionality in the next ~2 months?

[jchate6]

First step is taking a look at the existing SCOUT code and seeing how hard it will be to convert to a data service. If this is straightforward, then I can do that and unblock the FOMO team from making further enhancements.