Moving Object Search Service

Introduction

The Keck Observatory Archive (KOA) contains tens of thousands of observations of solar system objects. The Moving Object Search Service (MOSS) is an interface that supports searches of KOA in time and space for observations of known solar system objects. This document gives a brief overview of the MOSS; a more detailed description is in Berriman et al. (2016).

How the Service Works

For catalogued objects in the solar system, users can enter either the IAU designation or SPK-ID.

There are two options for specifying asteroids and comets: (1) If it is a cataloged object already in JPL's Small-Body Database, request using its unique IAU designation or SPK-ID number. (2) If it is not cataloged, but instead a newly discovered object not yet published, heliocentric ecliptic orbital elements may be manually input. A date range of interest is required for either search method. MOSS then obtains the object's ephemeris from the Horizons System provided by NASA/JPL's Solar System Dynamics Group. Note that for precise input consistency with Horizons, an ecliptic obliquity angle of 84381.448 arcseconds with respect to the ICRF equator plane is assumed for the input angular elements (IAU76).

Manual input of asteroid or comet orbital elements should be done only if the object is not in JPL's Small-Body Database. If the object exists in the Small-Body Database, which generally occurs within two hours of discovery publication notice by the Minor Planet Center, best results will be obtained by querying the object's SPK ID in the KOA MOSS, since the database contains the most precise and up-to-date orbits consistent with published data. If manual input of orbital elements for an unpublished small-body is necessary, provide as many significant figures as available. To demonstrate the importance of the orbital precision on the query, we investigated the impact of finding NIRC2 files for the asteroid Lutetia with varying precision in the orbital elements.


Orbital Elements Num. NIRC2 files
  • Epoch: 2457800.5
  • Eccentricity = 0.164587024192538
  • Inclination (deg) = 3.06376292337028
  • Ascending Node (deg) = 80.88034501826424
  • Argument of Perihelion (deg) = 250.0144262431933
  • Semi-major Axis (AU) = 2.434292642077133
  • Mean Anomaly (deg) = 136.722830835853
560
  • Epoch: 2457800.5
  • Eccentricity = 0.1645870241925
  • Inclination (deg) = 3.063762923370
  • Ascending Node (deg) = 80.880345018264
  • Argument of Perihelion (deg) = 250.01442624319
  • Semi-major Axis (AU) = 2.4342926420771
  • Mean Anomaly (deg) = 136.7228308358
546
  • Epoch: 2457800.5
  • Eccentricity = 0.164
  • Inclination (deg) = 3.063
  • Ascending Node (deg) = 80.880
  • Argument of Perihelion (deg) = 250.01
  • Semi-major Axis (AU) = 2.4342
  • Mean Anomaly (deg) = 136.722
18

In order to find potential matches to the requested query, the service constructs bounding boxes covering 15 hours in time around the computed sky track. The width of a bounding box is adaptive, and is based on the complexity of the sky track and on the field of-view of the instrument. For each instrument, the box bounding is extended in all directions to include the maximum field of view for all instrument configurations. For example, HIRES has slits with lengths from 1.0 to 28.0 arcsec. For all HIRES searches, the bounding box used is 28.0 arcsec, regardless of which slits were used in the observations. The primary consequence of this approach is that some observations returned in the search may not have the object of interest in the field of view. Fortunately, we expect the rate of this over-reporting of results to be small since both the position and time of observation need to match and the chance of having an observation, particularly a spectrum, a few arcsec away from a moving object is low (it depends, of course, on the duration of the observation and the speed at which the object is moving). One the other hand, by using a buffer in the searches, it is possible to retrieve blank sky images that could be useful for image processing.

After the initial list of potential matches is found from the bounding boxes, a post-filtering step finds which of those are valid hits and and which are near misses. Both of these classes of results are returned in an interactive table and are described here.

Query Times

The time it takes to complete a query and return results depends on many factors, including the range of dates searched, the moving object's speed, the number of instruments included in the query, the number of files returned, and the current load on KOA. The table below presents some representative query times for all-instrument and HIRES-only searches for Mercury data over different date ranges. Please note that your own times may differ from those here, particularly if there is a high load on KOA.

Query Search Times

date range Time to Results Page
[UT] all instruments HIRES only
1995-01-01 to 2016-06-30 11m 3s 2m 48s
2000-01-01 to 2016-06-30 7m 54s 2m 6s
2005-01-01 to 2016-06-30 5m 31s 1m 39s
2010-01-01 to 2016-06-30 3m 19s 1m 9s
2015-01-01 to 2016-06-30 0m 58s (no results) 0m 9s (no results)
2010-01-01 to 2011-01-01 0m 33s 0m 21s