Response to Suggestions

MAST will post selected suggestions and responses to them if authorized. We realize that some suggestions may reflect science objectives and we do not wish to compromise our users ideas.

Some suggestions from 2005 Users Survey and 2006 Users Survey including most of the comments, have been posted online.

Great body of work you have done. Please consider enabling superior pixel consumption services. For example, check out WorldWind to see how they have enabled the Sloan Deep space and Wilkinson Microwave Anisotropy Probe survey data to be presented together within a no cost agile viewer. Would be just great to add you data to the mix... (very easy to do) see
http://forum.worldwindcentral.com/
http://www.worldwindcentral.com/wiki/Main_page
http://www.worldwindcentral.com/wiki/SDSS .
As it is with how your team exposes the data, it is not a fluid process to go from image to image and contrast them against standard visual or other wavelength data. The Worldwind application would enable scientists and users to view RF, Optical, UV, X ray while pointed at the same location, but using a slider bar to shift the type of data being made available. This would enhance the cognition process, since it would decrease the find and fetch mode...In any case... thank you for excellent work.

Response

Thanks for your suggestion. We do keep an eye on the various systems out there for browsing image data. The downside of WorldWind from our point of view is that it is currently available only on Windows, which is not widely used in the professional astronomical community (our primary users.) We have only a few Windows machines here and don't really have the resources to do development or testing focussed on that platform. But we are aware of the nice capabilities that WorldWind offers and may work on interfaces to it in the future, especially if the software is ported to the Mac and Linux operating systems. I know that WorldWind has some strong advocates in the "Virtual Observatory" community. We're also working with Google on the "Sky in Google Earth" project (available in the latest release of Google Earth.) That is another interface that has some interesting capabilities and that we are likely to support in the future.

It would be very helpful if the returned hits on a GALEX search contained information which allowed the user to identify which image an object is in. For instance, if I search on NGC1399, then a lot of hits are shown, but if I wish to simply download the unique images, there is no obvious or easy way to identify them. Or is there? So listing the exposure time or the image name would be sufficient, and useful in many other cases as well.

There were two responses sent to the user:

Response 1

When you send a query through the MAST (Simple) form, it returns a list of objects from a search cone of some radius (default = 3 '). This list of objects is tagged by the project with 19 digit, supposedly unique GALEX ID numbers. (I say unique in the sense only that they are unique for a GR release. Also, a given object if observed from two observations in an overlapping "tile" (circle of 0.6 degree radius) can be given two different IDs, 1 for each tile.) The Explore page leading to postage stamp sized images and detailed info about each object is associated with each of these GALEX-IDs (objects). These objects do not have official names other than those we embed in the Explore pages to encourage authors to adopt a standard nomenclature convention. Moreover, the detailed GALEX +J12345... names will change from release to release since new observations ("visits") will modify the centroid image coordinates, and this will change 1 or 2 digits.

Each of these objects is associated with a tile, which you can think of as a Field of View. So a given object and all/most of its immediate neighbors will have been observed as part of a common tile; each of these will have the same exposure time. In the case of a particular object's being observed in more than one tile, we try to give primacy to the tile whose center is closest to the object.

Another staff memeber is going to send you instructions as to how to get information on the results page that you might be interested in. Briefly, this will consist of your modifying the SQL query that generated the results page from your search on the Simple MAST form. You can then cut/paste and modify this query in the open box of the SQL form. When you download the images, bear in mind that your images will be for a whole tile. You will have to go to the coordinates in the image corresponding to the objects you mention and work with them however you might want to.

Response 2

If I understand correctly what you want then if you go here, Search&Retrieval->Search Tile Catalogs->ALL SURVEYS or here's the url to get there directly, http://galex.stsci.edu/GR2/Default.aspx?page=tilelist&survey=allsurveys, and plug in the coordinates for NGC1399, (54.6221667,-35.4501944) and a search radius 0.65 degrees, this is the approximate radius of a tile, the "Search Tile Catalogs" function searches tiles based on the distance from the center of the tile.

To confirm you have only the tiles you need if you redo your query from the main search form and add the two following output columns "tilenum and subvisit", check the box that says show query, and run the query. The result page should show the query, it should look like this.

SELECT TOP 100 p.objid, dbo.fHasSpectrum(p.objid) as specObjID, n.distance as distance_arcmin, dbo.fIAUFromEq(p.ra,p.dec) as IAUName, p.ra, p.dec, p.band, p.fuv_mag, p.nuv_mag, p.fuv_flux, p.nuv_flux, p.e_bv, p.isThereSpectrum, p.fuv_fwhm_world, p.nuv_fwhm_world, p.tilenum, p.subvisit
FROM PhotoObjAll as p LEFT OUTER JOIN SpecObjAll as s on p.objid = s.objid, dbo.fGetNearbyObjEq(54.6221667 , -35.4501944 , 3) as n
WHERE p.objID = n.objID
ORDER BY n.distance ASC,p.fuv_mag ASC ,p.nuv_mag ASC ,p.e_bv ASC

change it to the following, by cutting out everything after "select" and before "p.tilenum,p.subvisit" and add the word distinct before p.tilenum, also remove the entire order by clause

SELECT distinct p.tilenum,p.subvisit
FROM PhotoObjAll as p LEFT OUTER JOIN SpecObjAll as s on p.objid = s.objid, dbo.fGetNearbyObjEq(54.6221667 , -35.4501944 , 3) as n
WHERE p.objID = n.objID

take that query and paste it here, Search&Retrieval->SQL Search Form or here directly, http://galex.stsci.edu/GR2/?page=sqlform and then execute, it should return the following which is the unique tile numbers for all the objects

* * *tilenum * *subvisit *
1 5061 0
2 5062 0
3 7011 0

Oct. 30, 2006

Is there a pipeline available to match the rotation and pixel scale of Galex fits to SDSS fits? I was not able to identify anything in Galex site describing the imaging characteristics in terms of arcsec/pixel (the about Galex is down)

In answer to your first question, the GALEX image scale is 1.5 arcseconds/pixel for both the FUV and NUV images. Of course, the Sloan (SDSS) scale is different.

Unfortunately, MAST does not direct offer services to corotate and align images. MAST allows one (through CASJobs) to "cross-correlate" images archived by many missions, including those from the GALEX and SDSS missions. Cross-correlate is a fancy term for matching positions on the sky by a "cone search" (circle on the sky) around positions from one missions against those of the other. The user has the freedom to change the radius for coincidences. If you're not yet registered with CASJobs, it is a simple thing to do, and we do this only to track usage and prevent abuse from hackers. Once you are logged in, CASJobs, which was written by the SDSS people, has a pretty extensive help page. The GALEX tutorial also has a section of how to work with CASJobs for cross matching.

MAST does not build tools to do more than this. However, you can use the Aladin tool made for professional astronomers. Aladin can be "brought" to your computer as a "trusted applet" if you click its name under "Tools" at the top of the GALEX home page. Once you click on Aladin, you can input coordinates and bring in any images from MAST or elsewhere, including GALEX and SDSS. Aladin will allow you to co-orient the images from 2 or more missions (for example, bringing North to the top of the image), and you can think work with the Zoom in/Zoom out features. However, this is just for screen display. We are not aware of any functionality in Aladin that would allow you to output new fits files to a common pixel grid. Should you need additional help with Aladin, we would have to refer you to their help pages, or to the CDS in Strasbourg, which wrote the tool.

June 15, 2006

I'm a student at the [university name]. I read on the internet that you guys were working on a fits2csv program. I was wondering if theres a way I could get this program.

It took some time to figure out what fits2csv program that you read about on the internet. The best we could come up with is a specific program discussed in a progress report related to our GALEX archive development. This program is very specific in platform and purpose and would not be useful in any other context. However, in the context of the "Virtual Observatory" some tools have been written to read a number of astronomy related formats and to provide the data in an alternate format. You might want to explore an application called "TOPCAT". You can find information about it at http://www.star.bristol.ac.uk/~mbt/topcat/. I hope that TOPCAT will have the functionality that you need. The website includes links to documentation and to get further help.

January 30, 2006

I noticed that the default search radius on your cross-correlation search page is set to 1.0 arcmin for ASTRO/UIT. Because the ASTRO payload combined spectroscopic and imaging instruments on a common mount, the target of interest for UIT was not always near the center of its 40 arcmin field. It would be helpful to increase the search radius for UIT to 5 arcmin. Thanks.

Thanks for writing. Please let us know if you have any other suggestions. We appreciate and need more feedback on our search interfaces. We think we accidently set the UIT radius to be 1.0 arcmin like the spectral missions. We have changed the default to be 5.0 for the cross-correlation search, and its still 3.0 for the UIT search form.

November 4, 2005

I like the new stuff that MAST has done with Aladin and I had a further suggestion. I would like to see an instrument overlay option of some sort in Aladin. This would be particularly useful for spectrograph slits. I imagine being able to ask Aladin to querry MAST and plot as a layer the position, coverage, and orientation of all the STIS slits in the displayed field. This would be _very_ helpful for selecting data to download from the MAST archive. Thanks.

The Astronomer's Proposal Tool (APT) is exploring the possible use of Aladin for visualizing HST observations. In this mode, APT would be able to display, rotate and translate the HST field of view as an Aladin layer. The displayed field of view could consist of any one or more of the HST apertures. The Aladin embedded with APT would be fully functional, so could perform MAST and other queries. It is also possible that a stand-alone version of Aladin which displays HST apertures could result from this work. If you have any further suggestions concerning this topic, please post them in the suggestion box or send them to the archive hotseat at archive@stsci.edu.

November 3, 2005

I am using the ACS pointings search facility with both the web interface and StarView to define a large archive survey. I am finding it to be a very useful tool for characterising the sky covered by ACS. However, I have found 2 bugs and have three suggestions/requests:

Bug 1: the numbers of pointings returned by the web interface and by StarView do not agree. I find 2534 with SV, yet 2483 with the web, when searching the whole sky for exptime in BVRIZ > 2000s with OR logic.

Bug 2: expanding a few ACS pointings on the web interface I find what appear to be non-science datasets (target TUNGSTEN for example). The StarView results seem to be clean.

Suggestions/requests:

1) Could the ACS pointing number be propagated into other parts of the database, so that exposures can be (re-)associated and located on the sky with ease?

2) Could the ACS pointings exposure search output be extended to include filter, exposure time and association ID? (Also, could it be tidied up to remove repeated flag and config columns?)

3) Finally, and most importantly, could the number of pointings able to be expanded into exposures be increased beyond 50 please? I am researching numbers of fields in the thousands, and at present would be forced to write lists of 50 comma-separated pointing numbers and paste them into StarView by hand.

Many thanks!

"Bug 1:" The table that is being used is the same. We think that the difference is related to the slight differences in SQL that are used by Starview and the web interface. Starview uses constructed SQL and does not customize the query logic for the searches and results it gets. The web interface was specifically built for this type of query. We are pretty sure that this causes the difference in the results. We will look at this a bit more.

"Bug 2:" The program that builds the pointings interface uses a field that is supposed to distinguish science observations from calibration observations. The software that creates this flag needs to be updated to flag TUNGSTEN and DEUTERIUM as calibration observations. A problem report has been filed to have the software updated. In the meantime, the pointings software has been updated to explicitly exclude these observations.

----------------

Suggestion/request 1: We are going to investigate a way to make the pointing number stable over time and to incorporate this type of search into other applications that will probably be developed over the next year or so. This should make it easier to "re-associate" the data. The work to stabilize the pointing number will start in the next week or so. However, incorporation of this into other applications and associating it with other parts of the database will be a longer term project.

Suggestion/request 2: This suggestion mostly refers to the Starview interface. Starview is on a fairly strict build/release schedule. We will post a problem report for this. Then it will be incorporated in the one of the next few builds. This may take a couple of months to complete.

The Pointings Table's Web interface architecture is going to be updated to make it easier for you to then choose what fields you would like to display.

Suggestion/request 3: Expanding the number of exposures within the Starview interface may not be feasible. There is a limit on the number of qualifiers that can be in a single field's query. Starview also has a memory limit on the number of rows that can be returned. The web interface now allows you to expand to a basically unlimited number of rows. However, there is a considerable time delay to render the long web page. The new version of the web interface should permit you to choose a comma separated value list as an output format, with the values you choose. It should also permit you to perform this query as a get request so that the searches are scriptable. This work is starting and we hope that it will be completed in the next month or two.

Thank you for your input!