Skip to content

multi-source Galactic extinction querier  #82

Closed

Description

@eteq

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:

ebmv1 = query_ebmv(coordinates, 'SFD')
ebmv2 = query_ebmv(coordinates, 'ogle-vvv')

and have ebmv1 and ebmv2 be exactly comparable.

(of course it should match the general API plan for astroquery, but the result object should be something consistent across the disperate tools.)

Activity

  1. eteq commented on May 9, 2013

    @eteq
    MemberAuthor

    (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.)

  2. keflavich commented on May 9, 2013

    @keflavich
    Contributor

    👍 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.

  3. autocorr commented on Jun 5, 2013

    @autocorr
    Contributor

    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?

  4. eteq commented on Jun 5, 2013

    @eteq
    MemberAuthor

    You mean adding it in as in adding it to astroquery.sha somehow, or cloning the implementation of astroquery.sha?

  5. autocorr commented on Jun 6, 2013

    @autocorr
    Contributor

    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.

  6. eteq commented on Jun 9, 2013

    @eteq
    MemberAuthor

    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.

  7. autocorr commented on Jul 10, 2013

    @autocorr
    Contributor

    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.

  8. keflavich commented on Jul 11, 2013

    @keflavich
    Contributor

    @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).

  9. keflavich commented on Aug 11, 2013

    @keflavich
    Contributor

    #138 and #124 solve this, I think

  10. added a commit that references this issue on Jun 30, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions