Hi folks, as part of the HUN-KON-S1 contribution for performing forced photometry on Solar System moving objects over (potentially years) of past images along the arc, we need to intersect large numbers of positions from an ephemeris with potential Rubin images (using DP0.2 as the proxy currently). We are currently doing this via the RSP TAP to query ivoa.ObsCore and the queries look like this (time/position windows truncated):
SELECT
lsst_visit,
lsst_detector,
lsst_ccdvisitid,
lsst_band,
s_ra,
s_dec,
t_min,
t_max,
s_region
FROM ivoa.ObsCore
WHERE calib_level = 2
AND (lsst_band = ‘r’ OR lsst_band = ‘g’)
AND t_max >= 59802.415775
AND t_min <= 59863.333979
AND (
(t_min >= 59802.415775
AND t_max <= 59802.416122
AND CONTAINS(POINT(‘ICRS’, 58.138352, -41.696853), s_region) = 1)
OR
(t_min >= 59803.360786
AND t_max <= 59803.361133
AND CONTAINS(POINT(‘ICRS’, 58.458592, -41.695724), s_region) = 1)
OR
(t_min >= 59803.362719
AND t_max <= 59803.363066
AND CONTAINS(POINT(‘ICRS’, 58.459217, -41.695733), s_region) = 1)
OR
(t_min >= 59805.314816
AND t_max <= 59805.315163
AND CONTAINS(POINT(‘ICRS’, 59.102676, -41.698524), s_region) = 1)
)
Performance is very slow or just crashes in the query with large numbers of points needed to resolve a long arc.
We’ve investigated other constraints supported by ADQL such as INTERSECTS with POLYGON shapes (since moving objects are often traveling along relatively long but thin paths) based on documentation for the Gaia TAP service. However it seems like support for other than POINTs isn’t available in RSP:
File /opt/lsst/software/stack/conda/envs/lsst-scipipe-10.0.0/lib/python3.12/site-packages/pyvo/dal/tap.py:996, in AsyncTAPJob.raise_if_error(self)
994 msg = self._job.errorsummary.message.content
995 msg = msg or “”
→ 996 raise DALQueryError("Query Error: " + msg, self.url)DALQueryError: Query Error: UnsupportedOperationException:53 is not a supported coordinate system.
Are there are (documented…?) alternatives using the Butler we should use instead or stick with RSP TAP and find workarounds, better queries or get additional support added (I appreciate “scope creep” is the last thing wanted right now…). Being able to investigate past behavior of newly discovered solar system objects or newly detected outbursts from alerts, is going to be critical for a lot of the time-domain/alert-based solar system science the SSSC wants to do with Rubin.