-
-
Notifications
You must be signed in to change notification settings - Fork 400
Specifications
This is very out of date - refer to the template module instead.
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)
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).
- 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?