Specifications

Specifications for AstroQuery modules & functions

This is very out of date - refer to the template module instead.

Catalog Query Tools

Must include: - query_[catalog] which accepts an astropy.Coordinates object [when such a thing exists]

Should include the following 'helper functions':

• query_[catalog]_radec
• query_[catalog]_hmsdms [coordinates specified as a sexagesimal string]
• query_[catalog]_gal

These functions should accept at minimum (longitude, latitude, size). The size should be arcminutes by default. The default tools should, if possible, define a circular search. They should also accept a 'save' keyword to determine whether the file should be saved onto the HD, a 'directory' keyword defaulting to './' to determine where a file should be saved, and a 'savename' keyword to specify a filename.

These functions should return a Table instance (either atpy or astropy.tables... not sure what is defined yet in astropy)

Image Query Tools

Should include the following 'helper functions':

• query_[imageserver]_radec
• query_[imageserver]_hmsdms [coordinates specified as a sexagesimal string]
• query_[imageserver]_gal

These functions should accept at minimum (longitude, latitude, size). The size should be arcminutes by default. The size should define a square region by default. They should also accept a 'save' keyword to determine whether the file should be saved onto the HD, a 'directory' keyword defaulting to './' to determine where a file should be saved, and a 'savename' keyword to specify a filename [only valid if there is a single file? Maybe save_prefix instead?]

• Both catalog and image queries should include an option to save the downloaded

file in some format. Specified with the saveformat keyword, default to None?

These functions should return a list of astropy.io.fits.HDUList (even if there is only one file returned, because many services will return multiple files).

Services Requiring Login

Some services require a login. What is the best way to accomodate these?

• login/password keywords to any query tool -> re-log-in for each query (inefficient for repeat queries)

• Object-based querying? Breaks above strategy. Unless you can do some "functional" module-based login (i.e.,

  let the module initialize the query class and make the standard suite of query functions available)?

• Object-based querying, where the default login query functions are exposed?