Expected Lasair ssObjectId behaviour

Support Lasair
#1

Hi all, I have a couple questions related to how we can expect Lasair to handle moving solar system objects (SSOs), i.e. alerts with an ssObjectId:

  • Is the Lasair-LSST alert schema available? Or is it just the official LSST schema? I’m interested to see what fields are possible to write queries for, e.g. ssObjectId.
  • Currently with Lasair-ZTF queries can be written on objects.ssnamenr (i.e. moving object identifier), however the ZTF alerts available from Lasair all have objects.ssnamenr=NULL. Will this behaviour be the same for LSST alerts, i.e. filtering out NOT NULL ssObjectId alerts before queries?
  • There has been talk that alerts will move to a nearest SSO system, i.e. alerts not explicitly matched to an SSO. Quoting a recent update from Mario Juric “New scheme: we will add SSSource/SSObject records to all alerts that have an SSO nearby”. This implies to me that Lasair will have to keep ALL alerts, as having a nearby SSO does not preclude the source being a static transient? Therefore it might be possible to write a query on ssObjectId?
#2
  • So far, Lasair has not built any sort of infrastructure concerning Solar System data except for ingesting it and storing it in the database.
  • We have not seen any ssObject records at all in the last few months of commissioning
  • Lasair tries to capture the SS data as it comes. The Cassandra table schema is an automated copy of the Rubin schema: mpc_orbits, ssSources, and ssObjects.
  • The Lasair-ZTF system does not handle SS objects
  • Lasair-LSST is keeping all the SSSource/SSObject/mpc_orbit records that arrive