Updated Fermi SkyView Surveys.

In the next few days we’ll be updating the Fermi survey datasets. The updates include data through week 379 of the mission (in October). This adds several years of data since we last updated Fermi early in 2012. Unlike the previous edition where the survey was given as count maps, the new data are rendered as intensity maps where we have divided each pixel by the exposure. These new surveys also are based upon the recently reprocessed Pass 8 Fermi archive data.

Many thanks to Dave Davis for providing the updated maps. We’re now planning on updating the Fermi data regularly — likely each quarter — using the Hera facility at the HEASARC. Click on the comparison all-sky images to see the substantial increase in the signal to noise of the Fermi data.

RGB image of Fermi bands 3,4,5: Old data

RGB image of Fermi bands 3,4,5: Old data

RGB Image of Fermi Bands 3,4,5: New Data

RGB Image of Fermi Bands 3,4,5: New Data

Update (11/17/2015): SkyView version 3.1.15 has been released with the new Fermi surveys.

Posted in Notices | Tagged | 1 Comment

SkyView V3.1.14: VLA FIRST (1.4 GHz) survey update

FIRST image of 3C273

FIRST image of 3C273 generated in SkyView

SkyView version 3.1.14 has been released with a change that affects FIRST survey images.

It was brought to our attention that some FIRST images generated using SkyView differed from images generated via the FIRST web server. We investigated and found that the files we created to describe FIRST data contained some older FIRST file names. These older files were being retrieved to generate FIRST images instead of newer reprocessed data files. We have updated out FIRST data description files so that only the latest data files will be used to generate FIRST images in SkyView.

Posted in Discussion, releases | Tagged , , | 7 Comments

SkyView V3.1.13: SkyView-in-a-Jar bug fixes.

We’ve just released new version of SkyView that fixes a couple of bugs associated with using SkyView-in-a-Jar. Users of the web pages should not see any changes.

There is a batch mode option in the jar which allows many requests to be run without restarting Java each time. In some cases batch mode requests after the first would fail. SkyView attempts to optimize the calculation of the resampling geometry when a user requests images from multiple surveys that have exactly the same geometry on the sky, (I.e. they are broken into tiles with the same sky coverage like the four IRAS or IRIS surveys). Unfortunately this ‘optimization’ was sometimes being applied to subsequent batch mode requests even though the requested positions were quite different. Thanks to Kelley Hess for bringing this to our attention. When we fixed this we also updated the parsing of quotes in the batch file to mimic the behavior of the command line more closely.

The other problem did not cause any errors in the output. If a user had set the SaveBySurvey flag to request that data from different surveys be saved in different cache directories, then in a request where there was both multiple surveys requested and a contour image, the cached data for the second and later images was being stored in the directory associated with the survey that contour image was taken from. E.g., if the user had specified

SaveBySurveys Survey=s1,s2,s3 Contour=c1 position=xxx

then the cached files for surveys s2 and s3 were stored in the directory for c1. This is unlikely to be a problem for most users, but it meant that we occasionally had junk in the cache that our SkyView web server maintains.

Posted in Notices, releases | Tagged , | 4 Comments

SkyView release v3.1.12

We have released SkyView v3.1.12  with 2 enhancements!  This new version adds social network sharing options to the SkyView Image Gallery  and a helpful option to the Overlays section of the main SkyView Query form.

Facebook and Twitter Share buttons are now displayed with all images in the SkyView Image Gallery.  So if you have an account on either of these social networks you can share images that you or other users have created. If you are interested but have never added an image to the Gallery check out this post

The new feature in the Overlays section of the SkyView Query form is the option to draw a reticule indicating where the center of your SkyView image is located.

Below are screen shots from a SkyView Image Gallery page, an individual gallery image, and  the SkyView Query form showing the location of the new reticule overlay option.  Note that the gallery images also demonstrate the new overlay option.

 

Gallery_for_2015-04-20_blog

NASA_SkyView_Image_blog

SkyView_Query_Form_blog

 

Posted in Announce, releases | Tagged , , | 2 Comments

V3.1.10: WISE now uses All-WISE data

We’re getting ready to release the next version of SkyView. The only significant change is an update to the WISE datasets which will now point to the All-WISE data release. This provides significantly deeper coverage in some areas and bands but is structurally similar to the previous data sets. Since we’ll be building up the All-WISE data available in our caches, WISE retrievals may be a little slower on average for a while since the base images will more frequently need to be downloaded from the IRSA archive. To access the All-WISE data from the SkyView-in-a-Jar you will need to download the latest jar file.

We’ll be making this the default release shortly (within the day), but if you can’t want you can get the the new release as: http://skyview.gsfc.nasa.gov/v3.1.10

For more information on the All-WISE data see this summary at IRSA.

If you have any questions or concerns or suggestions for new surveys please let us know.

Posted in Discussion, releases | Tagged , | 2 Comments

SkyView v3.1.8 with GALEX DR7 released.

A new version of SkyView, v3.1.8, has been installed as the default version. The significant change from the user perspective is that the GALEX DR7 is included. New data is mostly in the NUV. To access these data through SkyView-in-a-Jar you will need to download a new copy of the jar file.

Posted in Announce, Notices | Tagged , | Leave a comment

GALEX DR7 in SkyView

We’re testing out a new version of SkyView where we’ve upgraded the GALEX survey to include more GR7 data. There are a few minor internal changes. Most of the new data is for the NUV. When we release this survey we will probably clean out the cache of GALEX data at the SkyView site and start repopulating it with the latest files from MAST. Some of the tile files may have been updated since we last downloaded them. This may slightly slow down generation of images as we build the cache back up.

If you wish to try the new release, start at the URL

http://skyview.gsfc.nasa.gov/v3.1.8

Let us know if you have any problems — or suggestions for additional changes.

Posted in Notices | Tagged , | Leave a comment

Looking for Moving Targets? Try SkyMorph

One of the restrictions on SkyView is that you need to specify a fixed position in the sky to look at. For many years the SkyView machine has hosted a companion service, SkyMorph, that allows you to look for many moving targets: asteroids, comets and some planets. It uses the Horizons service at JPL to get the position of the moving target as a function of time and then uses the epoch of various observations to find which fields of view might include the object. The primary set of observations available in SkyMorph are data from the Near Earth Asteroid Tracking (NEAT) project which has about 700,000 images of the sky. DSS and other datasets are also available. Since the NEAT project looked at some areas of the sky dozens of times, the data can also be used to look for transients or high proper motion objects.

In the next year or so SkyMorph will be leaving the SkyView host and moving to JPL. You can access SkyMorph through its ‘classic’ interface, or try the new service at JPL which is now available as an early beta version.

Posted in Discussion, Notices | Tagged , , , | Leave a comment

SkyView and SkyMorph Problems 8/24/2014

SkyView‘s disk area for user-generated images filled up on the morning of August 24 (EDT) and the problem was not corrected until about 9 AM on August 25. SkyView and SkyMorph requests during that time failed. We apologize for any inconvenience to our users.

Posted in Notices | Tagged , | Leave a comment

Babylon’s Legacy: Converting Decimal to Sexagesimal

It’s usually convenient to store and process angles and times in some simple decimal value, but we often wish to display them in a conventional sexagesimal notation or allow users to enter values that way. So we need to be able to convert from 10.3 degrees to 10d 18′ 00″ or vice versa. There are a fair number of subtleties that lead to gotchas in naive code that performs these kinds of conversions.

First lets consider transformation from sexagesimal to decimal. Seems like it should be straightforward: We just parse three integers d, m and s and
dec = d+m/60 + s/3600.
Right?

Great. But what about -10 30 30. That addition doesn’t work right. We need to make the minutes and seconds add to the magnitude of the degrees. How about

dec = abs(d) + m/60 + s/3600;
if (d < 0) dec = -dec;

That handles everything fine doesn't it? Not quite. What about -00 30 30? Typically -00 will be read the same as 0 so as soon as we naively converted the first string to integer we made an error. The code will misrepresent positions just south of the equator. I've done this myself and seen it in the wild more than once. To handle these values we need to explicitly look for the sign and if we find a - sign then invert the sign of our result. This is a really easy bug to miss since it only affects a small fraction of the sky.

So we need something like

sign = 1;
if (the coordinate string starts with a -) sign = -1;
dec = sign*(abs(d) + m/60 + s/3600);

to handle everything properly.

Any issues going the other way, converting from decimal to sexagesimal?

There are a few. There's the obvious counterpart to the the one we just handled.
E.g., if we have an input declination of -0.5, then trying
d = int(dec)
m = 60*int(dec-d)

isn't going to work. The variable d is going to be 0 and we've lost the sign. Bad things will happen. What we want to do is print out the sign first and then work on the absolute value
of the input angle.

And there is a more subtle issue that has to do with rounding...

Suppose we are looking at transforming 10.49999 degrees to sexagesimal.
Ok we have 10 degrees.
Next we see .49999*60 = 29.994 so we 29 minutes.
and .994*60 = 59.64 seconds.

So we could represent this as 10d 29' 59.64"

However we often want to format our results to some specified precision. E.g., suppose I want to output my data to arcsecond precision. I could try
10d 29' 59"
but that's silly we should be rounding to the nearest arcsecond. So we need to round up to
10d 29' 60"

Ooops... 60" isn't something I'm supposed to show. I need to go back and increment the arcminutes to get
10d 30' 00"
If the arcminutes had been 59 prior to the increment then I'd need to go back and increment the degrees... This is a bit of a pain but it needs to be done to format the data properly. If you are doing the longitude or right ascension, you may also want to deal with the special case of what happens when you round up to 360 degrees or 24 hours. Do you want to allow both 0H and 24H?

This kind of rounding issue occurs when we convert to decimal too, but it's handled by the language I/O libraries so we don't have to worry about it.

Rather than having code to respond to the increments when they happen we can convert the input value to a scaled integer early on and make sure the increments don't happen.

E.g., suppose we want to show to a precision of 0.1". We take the input angle (we've already dealt with the sign so we can assume it to be positive) and convert to units of the precision we want. E.g.,
decx = floor(36000*dec+0.5);
so we convert degrees to tenths of arcseconds by multiplying by 36000, then add 0.5 to this value and take the largest integer value equal to or less than the result. This process rounds to the nearest integer value corresponding to our input (assuming the input in positive).

Now we can use integer division and modulus operators to get the degrees and minutes and seconds. We'll need to insert the decimal point appropriately if we're displaying at fractions of seconds.

One final issue is what about objects just south of the equator? Do we want to allow both
00 00 00 and -00 00 00
where the second case arises when we've rounded a position south of but with 1/2" of the equator? We can keep them distinct or handle this special case, but we should probably do it consciously!

Posted in Discussion, Documentation | Tagged , | 2 Comments