spacetelescope / drizzlepac

AstroDrizzle for HST images.
https://drizzlepac.readthedocs.io
BSD 3-Clause "New" or "Revised" License
52 stars 38 forks source link

Update GAIA catalog query to include date #740

Closed stscijgbot-hstdp closed 4 years ago

stscijgbot-hstdp commented 4 years ago

Issue HLA-396 was created on JIRA by Warren Hack:

The standard pipeline astrometry processing relies on a web-service provided by ASB to return the GAIA catalog suitable for a given set of observations or a given pointing.  This service, though, does not return catalog positions appropriate for the observations date of observation, rather all coordinates are simply 2015.5 positions.  ASB (B. McLean) has plans to implement an update to the web-service to take the observations date (decimal year) and uses that to correct the GAIA catalog positions based on the GAIA catalog proper motions.  

Once this update has been made to the GAIA catalog web service, the astrometry code will need to be revised to compute and pass the observation's date (DATE-OBS) as a decimal year to the web service in 'create_astrometric_catalog'.  This should result in more accurate fits to GAIA, and perhaps even allow additional fields to match to GAIA that currently do not due to the proper motions affecting the cross-matching.  

stscijgbot-hstdp commented 4 years ago

Comment by Warren Hack on JIRA:

I have defined the add_gaia_epoch branch for this work.

stscijgbot-hstdp commented 4 years ago

Comment by Rick White on JIRA:

Brian McLean has updated his web services so that the EPOCH parameter now works correctly.  Here is a sample query (near the Tadpole Galaxy) that shows the use of the parameter:

https://gsss.stsci.edu/webservices/VO/CatalogSearch.aspx?RA=241.50&DEC=55.42&SR=0.03&FORMAT=CSV&CAT=GAIADR2&EPOCH=2002.2

A warning about using these results: the proper motions are assumed to be zero for objects that do not have measured proper motions in the Gaia DR2 catalog.  Such objects should not be used for alignment because their positions are not accurate.  An example is Gaia object 1621444987118062464 in the results of the above query.  You should omit objects that have null values for the proper motion columns.  Here's a code snippet that does that:

from astropy.table import Table
tab = Table.read('test.csv',format='ascii.csv')
# handle case where there are no masked rows
if hasattr(tab,'mask'):
    tab = tab[~tab['pmra'].mask]

Note that the (now fixed) bug in the gsss web service was not apparent in the pipeline code up to now because the pipeline code did not try to pass an EPOCH parameter in the query.  So really the reason the proper motions were not being used was that the drizzlepac code did not specify an EPOCH value.

stscijgbot-hstdp commented 4 years ago

Comment by Warren Hack on JIRA:

This has been implemented with Drizzlepac PR #⁠743.

In addition to using EPOCH, The primary interface, create_astrometric_catalog, was also updated to allow the user to get ALL the columns from the web-service upon request, with the default being only to return the subset of columns needed for pipeline alignment (ra, dec, mag, objID).

These changes were tested against dataset icw402010 which generates a successful fit to GAIADR1 and GAIADR2, with the DR2 fit being the final.

stscijgbot-hstdp commented 4 years ago

Comment by Warren Hack on JIRA:

Merged in to master.