You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is in part motivated by the discussion in astropy/astropy#733 . There was (and is) a discussion there about whether or not Galactic extinction should be included in the astropy core vs. astroquery.
Regardless of what goes in the core, it is clear that quite a few different online queryable source exist for all-sky or large-field dust maps, either in E(B-V) form or as dust columns or the like. Some possible examples include
So this issue calls for creating an interface that might allow various sources like this to be queried and return the same/similar type of object. That is, it would be really nice to be able to just do something like:
(Oh, and to be clear, the IRSA SFD already seems to have an interface here... I'm suggesting in this issue that it be pulled into a unified framework that supports other sources.)
👍 This is exactly what is intended in the API - the result objects should be identical if the data are. There is still debate to be had over whether to do query_ebmv_SFD vs query_ebmv(coords, 'SFD'), but perhaps both can be supported.
Since the API for the IPAC Galactic dust extinction service (the SFD maps in the first bullet) is the pretty much the same as the IPAC Spitzer Heritage Archive added in astroquery.sha I was thinking of adding it in. Are there anymore thoughts that people have on this?
Sorry, poor wording on my part. My plan was to make a astroquery.dust module or something similar and have a core.py contain the base functions with modules for each queryable, eg ipac_gdes.py, ogle.py, etc. and just specify the service with a parameter like you have above with query_ebmv(coordinates, 'SFD').
I saw the previous discussion on astropy/astropy#733 and the interpolation and right products will be complex, but sending the queries, parsing the tables, and fetching the fits images, should be do-able. Then we can think about what to do with the data products once we have them. I brought up astroquery.sha because IPAC has the same site interface for each.
Ok, yeah, that sounds reasonable. The interpolation business is only necessary for some use cases of the dustmaps - many of the others the straightforward query is perfectly sufficient, and is easier, so it's the better place to start.
Would an interface/query for this service be something people would like included in astroquery? I could add it in if so, it looks like mostly a problem of getting the HTTP post right and parsing the output ASCII file.
@autocorr - I think LAB/GASS access would be great. If you go ahead with this, make sure to include a means of getting the spectrum (which is delivered as an ASCII file).
Activity
eteq commentedon May 9, 2013
(Oh, and to be clear, the IRSA SFD already seems to have an interface here... I'm suggesting in this issue that it be pulled into a unified framework that supports other sources.)
keflavich commentedon May 9, 2013
👍 This is exactly what is intended in the API - the result objects should be identical if the data are. There is still debate to be had over whether to do
query_ebmv_SFDvsquery_ebmv(coords, 'SFD'), but perhaps both can be supported.added some notes, particularly related to issue astropy#82
autocorr commentedon Jun 5, 2013
Since the API for the IPAC Galactic dust extinction service (the SFD maps in the first bullet) is the pretty much the same as the IPAC Spitzer Heritage Archive added in
astroquery.shaI was thinking of adding it in. Are there anymore thoughts that people have on this?eteq commentedon Jun 5, 2013
You mean adding it in as in adding it to
astroquery.shasomehow, or cloning the implementation ofastroquery.sha?autocorr commentedon Jun 6, 2013
Sorry, poor wording on my part. My plan was to make a
astroquery.dustmodule or something similar and have acore.pycontain the base functions with modules for each queryable, egipac_gdes.py,ogle.py, etc. and just specify the service with a parameter like you have above withquery_ebmv(coordinates, 'SFD').I saw the previous discussion on astropy/astropy#733 and the interpolation and right products will be complex, but sending the queries, parsing the tables, and fetching the fits images, should be do-able. Then we can think about what to do with the data products once we have them. I brought up
astroquery.shabecause IPAC has the same site interface for each.eteq commentedon Jun 9, 2013
Ok, yeah, that sounds reasonable. The interpolation business is only necessary for some use cases of the dustmaps - many of the others the straightforward query is perfectly sufficient, and is easier, so it's the better place to start.
autocorr commentedon Jul 10, 2013
Just as an update, the OGLE-III extinction map queries have been added in PR #124 where different options for interpolation are done on the server.
I've found this nice query interface for the LAB/GASS HI surveys:
http://www.astro.uni-bonn.de/hisurvey/profile/
It returns interpolated column densities and HI profiles (see the "download this data as ASCII" at the bottom after running a query for data that would be easiest for a query module to parse.)
Would an interface/query for this service be something people would like included in
astroquery? I could add it in if so, it looks like mostly a problem of getting the HTTP post right and parsing the output ASCII file.keflavich commentedon Jul 11, 2013
@autocorr - I think LAB/GASS access would be great. If you go ahead with this, make sure to include a means of getting the spectrum (which is delivered as an ASCII file).
keflavich commentedon Aug 11, 2013
#138 and #124 solve this, I think
Merge pull request astropy#82 from larrybradley/sphinx