SkyView Blog

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.

I’ve been at the International Virtual Observatory Alliance meeting in Trieste Italy this week. SkyView has had a bit of visibility here. The WorldWideTelescope use of SkyView surveys was prominently mentioned in Jonathan Fay’s presentation on the WWT, and SkyView was also prominent in the Virtual Observatory Integration and Mining (VIM) software developed at Caltech that was discussed by Roy Williams.

SkyView both uses and supports the Virtual Observatory. Users can get data from SkyView using the VO’s Simple Image Access Protocol (SIAP). SkyView gets information for catalog overlays using the VO Cone Search. If you would like to set up an SIAP, the SkyView distribution provides support for this too.

There was an error in the VO Simple Image Access (SIA) server for the SkyMorph/NEAT database.  It had an error in its error handling. When an SIA call results in an error the service is supposed to return a specified XML format which describes the error. In this case the server call failed before finishing the table. This should now be fixed. While this service is located on the SkyView server (at http://skyview.gsfc.nasa.gov/vo/sia_skm.pl) there was no error in actual SkyView code.

The release of Microsoft’s WorldWideTelescope this week made a big splash with articles in the New York Times and other media. It’s a very nice interface where you can just zoom and pan and compare data in a very elegant fashion. The ability to build tours of the sky is amazing.

When they look inside the hood of the WWT, SkyView users may find a lot of stuff that looks familiar. Most of the survey images in the initial release of WWT were taken from SkyView. The TOAST projection was added to SkyView to help support the WWT’s ingest of many of our most popular surveys.

We are very pleased to have been able to play a role in the WWT. We anticipate closer integration of SkyView and this kind of interface (WWT, GoogleSky, sky-map.org) in the future. The unprecedented ability to rapidly browse the entire survey nicely complements SkyView’s ability to create precisely tailored images. SkyView’s role as an archive for multi-wavelength survey data remains unparalleled and should be strengthened with the release of our publication interface.

Congratulations to the WWT team.

If you’ve tried the new GALEX survey from the command line, you may have noticed some messages

Warning: Multiple occurrences of key: EPOCH

popping up. Many of the GALEX FITS files have two EPOCH keywords in their headers. Fortunately they both have the same value, so this is innocuous enough. Still the FITS reader gets a bit nervous when it sees this.

It’s a little more embarrassing since the EPOCH keyword is deprecated in FITS. Epoch usually means the time of the observation, but it was explicitly defined to be the epoch of the coordinate system in the original FITS definition. To relieve the confusion this engendered EPOCH was deprecated. We’re supposed to use EQUINOX for the epoch of the coordinate system and DATE-OBS for the epoch of the observatoin.

So having even one EPOCH keyword is bad form much less two!

We’ve updated the astrometry for two DSS plates: XJ643 and XP338. These are at RA,Dec of 180.62,14.74 and 282.84,40.08 in the DSS2 Blue and Red respectively. Thanks to Sergei Goshko at sky-map.org for pointing out the discrepancies.