We have completed changes to SkyView to accommodate FIRST data changes at the MAST archive. FIRST data file names have changed and files for additional coverage have been added. Both the SkyView web site and SkyView-in-a-Jar file have been updated.
The latest version of SkyView has a new capability for drawing overlays on SkyView images. One major use of this will be to allow us to provide templates of the fields of view of various telescopes. E.g., in the image below we’ve overlaid information on the fields of view of two of the instruments of the Swift observatory on a simple DSS image of the region around 3c273. The X-ray Telescope (XRT) field of view has calibration sources (C1-4) marked in the corners, while the UltraViolet-Optical Telescope (UVOT) has a large rotation (and small offset) with respect to the satellite’s nominal pointing.
The overlays use simple ‘Draw’ files that describe the fields of view. E.g., the draw file for the XRT part of the overlay above is just:
reset
scale 2.36"
thick 2
color cyan
-300 -301
300 -301
300 301
-300 301
-300 -301
text 0 270 0 XRT FOV
text 0 -290 0 XRT FOV
text 290 0 90 XRT FOV
text -270 0 90 XRT FOV
thick 1
color pink
circle -265 269 47
circle 273 260 48
circle -264 -274 47
circle 276 -281 44
text -265 269 0 C0
text 273 260 0 C1
text -264 -274 0 C2
text 276 -281 0 C3
SkyView gets the underlying data for the FIRST data from the MAST archive. They have recently changed how they provide the data a little. The data used to be gzip-compressed but is now uncompressed. There’s a little bit of extra data too — coverage is extended over an additional 22 square degrees. The change shouldn’t affect many users of the Web page. Most of the FIRST data is already cached here at SkyView. It can cause problems for SkyView-in-a-Jar users since the current jar is trying to access the URLs using the old names.
We’ll be putting out an updated jar in the next couple of days. 99% of what we need to do is to just get rid of the .gz suffixes in the FIRST survey description which is very easy, but we also need to index the new files which will take a little longer.
The bug that caused the incorrect values of FITS CRVAL keywords for fixed projections (described in the previous post) has been fixed.
SkyView is currently putting incorrect values in the FITS CRVAL keywords of the fixed projections. The CRVAL keywords should be the center of the projection which in fixed projections is not necessarily the center of the image. For CAR, SFL and AIT projections the fixed center is 0,0 while it is 0,90 for the TOAST projection. SkyView is currently giving the center of the image — so that all-sky images, for which these projections are often used, are fine.
The image data themselves are unaffected.
We’ll be installing a patch shortly.
We are working on the capability to enable users to incorporate their own data into SkyView to take advantage of the geometry engine and image processing tools that SkyView offers. User data can be shared in the SkyView-In-A-Jar application and be included on the SKyView Query Form or the user may choose to keep the data private.
The current iteration of the user interface is below. Users have the option to create a new survey or edit a previously submitted survey. At this time data uploaded must be FITS files or compressed archives of FITS files. The simplest upload requires only the survey name and a listing of the files. More survey details can be added in the Optional Information and the Metadata Information sections.
Once a survey has been uploaded and auto-validated users will be able to see their data immediately in SkyView or later by logging in again. If the user has chosen to make the survey public it will appear on the general Query Form after being checked by SkyView staff.
This new feature should be available sometime this summer.
This afternoon we released the new Jar version 2.4b of SkyView. The changes are predominantly internal and are described in a previous post. However, there is one change that affects the SkyView web site. An old feature from the pre-java version of SkyView is returning. When Catalog Overlays are selected in the Query Form a link to the source listing is currently displayed with each SkyView image. Now there is also a link to the HEASARC Browse query used to obtain the listing providing much more data about each source. Note that HEASARC Browse uses a cone search that may return more catalog sources than would appear on the SkyView image.
The current SkyView JAR files were compiled using Java 1.5. We’re likely to move to 1.6 in the next release unless we hear an outcry from our users. It should be a little faster but if you just download the JAR file and use it on your machine you will need to have 1.6 installed. We’ll add a link to a 1.5 version, but we’ll likely stop updating that in a release or two.
Unless you’re interested in the SkyView internals you probably don’t need to read this one!
None of the changes discussed below will affect how SkyView is called or what it does. If you have been building your own version of SkyView classes or using SkyView Java classes in other applications you may want check to see if this will affect you.
One of the main design goals of the Java-based implementation of SkyView is to enable new capabilities by dynamically loading the major components of the system. So the projections, samplers, and such are all loaded based upon default names or settings the user has specified. Recently I’ve begun rationalizing this, so that the same scheme is used everywhere. Currently in some cases you specify the entire class name (e.g., skyview.process.imagefinder.Exposure). In others you specify a part of the name and it builds up the class, e.g., projection=Ait means load the class skyview.geometry.project.AitProjecter. In still others you can specify the class name and it will look both within a default package and for the class name exactly as you specified it.
In the next release all of these will use this last approach to create the class, calling the method:
Object x = skyview.util.Utilities.newInstance(String name, String pkg)
This method first looks for the class with the package name prepended to the class and then for the class name alone. Each type of object (projecters, samplers imagefinders, …) has a ‘default’ package, or the user can put them in any package and give the fully qualified class name as the appropriate setting.
The effect of this is that the names of some of the low level classes in SkyView will change. The class skyview.geometry.projecter.AitProjecter becomes skyview.geometry.projecter.Ait. Similarly skyview.geometry.sampler.ClipSampler becomes skyview.geometry.sampler.Clip. The functionality of these classes is unchanged. This eliminates some redundancy from the class names, allows a more uniform handling of errors in the loading of classes, and allows shorter setting values in some cases.
Please let us know if you have questions or concerns about this upcoming change.
Today at 6 PM EDT we celebrate the sidereal anniversary of the public release of the new Java based SkyView web site. Completely changing our server-side hardware and software, CGI scripts and documentation was a bit of a risk, but with just a few hiccups everything worked out pretty well. We have been pleased with how smoothly the initial transition went and with how the system has worked over the past year.
SkyView has generated about 1.8 million images in this year. The VLSS, IRIS, BAT and GALEX surveys have been released and the RASS background surveys have been completely updated. All of the DSS and DSS2 data is now incorporated as local data in SkyView. In the next year we plan on releasing a new survey publication interface so users can add their own surveys to SkyView. SkyView surveys have been incorporated with Microsoft’s new WorldWideTelescope and serve images to Caltech’s VIM tool.
The new Java software had lots of new capabilities and makes it much easier to adapt software to new circumstances. We’ve added a few new projections: Arc, Sfl, Stg and TOAST. There are new capabilities for running batch scripts. Users can see exactly where each output pixel is sampled. New image finders were customized to handle the GALEX surveys. A JavaScript widget that translates pixel locations to coordinates has been added to the Web display. And there are many minor changes and a few bug fixes. With our new framework it has been much easier to add new capabilities and make changes without increasing the complexity of the underlying code.
Overall we believe this has been a good year. Let us know what you’d like to see in SkyView over the coming year.