Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add explanation and justification for inclusion of this new legacysurvey module #2

Open
volodymyrss opened this issue May 31, 2021 · 8 comments
Assignees

Comments

@volodymyrss
Copy link
Member

We would need to explain why are we doing this: what is the value for us and for the community.

@andriineronov
Copy link
Collaborator

It is convenient to have python interface to the LegacySurvey data, in a way similar to already existing SDSS astroquery interface. For the moment the data are publicly accessible, but through wget. Accessing them through astroquery provides better traceability of the data and supplements them with metadata useful for reproducibility / traceability of results obtained with the data.

@volodymyrss
Copy link
Member Author

@volodymyrss
Copy link
Member Author

volodymyrss commented Jul 12, 2021

we could try to see if we can use TAP https://github.com/oda-hub/oda-sdss/issues/11

It's not guaranteed it will have the necessary data exposed.

@volodymyrss
Copy link
Member Author

the request can be made as so:

# see details in https://datalab.noirlab.edu/query.php?name=ls_dr9.tractor_n

from astroquery.utils.tap.core import Tap

datalab = Tap(url="https://datalab.noirlab.edu/tap")

#tables = gaia.load_tables(only_names=True)
job = datalab.launch_job('''
                         select top 10 ra,dec from ls_dr8.tractor_n where 
                         ra > 100
                         
                            '''
)

I did not follow what exactly you request, but this seems somewhere around what is needed.

Note that TAP does not exclude an dedicated astroquery module.
In fact, a number of common astroquery modules use TAP.
I guess it is because TAP and ADQL are too detailed and powerful for many purposes.

So it is often useful to reduce complexity to "query_object" and "query_target".
Not coincidentially, it is also easier to build our ontology from these requests than from generic TAP.

So my suggestion now would be:

  • try to use TAP as shown above instead of simple GET. It's not guaranteed to be any easier, but it could be good to get familiar with TAP, and TAP interface is likely to persist/easily-relocate while files are less predictable.
    • if TAP works instead of GET, use legacysurvey module over TAP (like many modules do).
    • if TAP does NOT work instead of GET, continue using GET or TAP + GET
  • come up with suggestion taking into account TAP suggestion from LS and contact them again.

@burnout87
Copy link
Collaborator

I've just given a first try to TAP, and it looks really interesting and powerful indeed.

It could actually help us a lot

@burnout87
Copy link
Collaborator

query_region has now been fully implemented using TAP.

@volodymyrss
Copy link
Member Author

this is needed before the PR to astroquery @andriineronov

@volodymyrss
Copy link
Member Author

possibly should be renamed! Need to consult JP Kneib

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants