Post Reply 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
astrometric uncertainties
10-25-2017, 21:10
Post: #1
astrometric uncertainties

Some explanation is likely warranted.

The observational minor planet community uses diverse tools to acquire astrometry on asteroids and comets. The Catalina Sky Survey (CSS) ( uses SExtractor to detect and centroid known and unknown (candidate) solar system objects against the background stars, and SCAMP to match against astrometric and photometric catalog(s). A variety of other tools completes the workflow to recognize motion against the stars and determine rates and angles.

Astrometry is submitted to a central clearing house, the Minor Planet Center at the Smithsonian Astrophysical Observatory. For several decades the astrometric format has been quite terse, containing not much more than RA, Dec, a UTC timestamp, and the magnitude and bandpass. The community is transitioning to a much richer format ( which, in particular, includes positional uncertainties and cross-terms.

The CSS workflow runs SCAMP after SExtractor to attach WCS keywords to about a thousand images per night from each telescope. As a separate step, we currently extract our candidate moving object detections from the original per-pixel SExtractor lists cross-matched between four-exposure fields looking for linear motion. Final validation is done by human eye after highly tuned scoring is applied.

We have evaluated running SExtractor a second time after SCAMP to pick up on the various "world" columns, but the logistics of handling the arbitrarily interleaved fields from our queue manager makes it undesirable to have to wait until each 4 frame stack completes. The pixel coordinates for each candidate detection are converted to sky coordinates directly from the FITS WCS using WCSTOOLS.

The difficulty is in how to combine the per-pixel centroiding uncertainties and cross-terms from SExtractor with sky-fitting uncertainties from the SCAMP solution. And honestly I don't understand from the SCAMP manual how fit uncertainties are meant to be applied from catalog stars onto non-catalog sources even if done in world coordinates. If it matters we recently transitioned from UCAC4 to the Gaia DR1 catalogs.

Perhaps it's best to leave it here to start. I can answer any questions, and maybe I'll have more pointed questions of my own when I grok the zen of SCAMP a bit better. I should say that we also use SWARP to build deep images, but these are not used in the astrometric workflow per se, which relies solely on solving many hundreds of single epoch images to find the moving dots.

Many thanks for any illumination or suggestions!

Rob Seaman
Catalina Sky Survey
Lunar and Planetary Laboratory
University of Arizona
Find all posts by this user
Quote this message in a reply
11-07-2017, 16:53
Post: #2
RE: astrometric uncertainties
Hi Rob,
thanks for your post and really sorry for not replying earlier to this (and many other forum questions Sad). I can comment on two of your points:
  • Assessing calibration uncertainties is a serious issue in SCAMP. Currently, people generally use the (3-sigma-clipped) "internal" RMS dispersion of High SNR (100x) sources as an indication of the relative accuracy of the calibration, and the "external" High SNR dispersion as an indication of the accuracy with respect to the reference catalog. For ground based images, turbulence is often the dominating factor (see e.g., Bouy et al. 2013). However when position uncertainties in the reference catalog are dominated by random, uncorrelated errors, the high SNR dispersion will often be a pessimistic estimation of the local calibration uncertainties. When using the Gaia DR1 catalog as a reference, calibration uncertainties will often be dominated by proper motions unless your observations were done very close to epoch 2015.
  • When it comes to converting source positions to world coordinates after calibration, you may also generate directly catalogs in world coordinates within SCAMP using the FULLOUTCAT_TYPE and MERGEDOUTCAT_TYPE config options. "Full" catalogs have one line per detection, while "merged" catalogs have one line per source. The latter also have proper motion estimations.
This gives me an opportunity to give some news on ongoing developments (a broader announcement will be done later). The GitHub repository of SCAMP has just been made public. The SubVersion repository is deprecated and will be removed soon. The GitHub version has built-in support for the Gaia catalog (with the caveat above about proper motions). A binary repository with optimized builds of the package for most popular Linux distributions is being put in place. We are also currently in the process of improving the documention, which is now part of the source package in Sphinx format, and which makes it easier for anyone to contribute. It is still very preliminary, but it will grow in the coming months. A ReadTheDocs build is available.
- Emmanuel.
Visit this user's website Find all posts by this user
Quote this message in a reply
Post Reply 

Forum Jump:

User(s) browsing this thread: 1 Guest(s)