## 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

## V3.1.7: SkyView and Google Analytics

Today we will be releasing version 3.1.7 of SkyView. There are no changes to the user code, but the primary pages will now be instrumented so that usage will be tracked through Google Analytics. This implements the NASA general policy that has been linked at the bottom of our home page for some time. If you want to understand what information is recorded please look there for more details. If for some reason you would prefer to disable this tracking there are plug-ins available. You can also simply disable JavaScript. Or you can use the earlier versions of SkyView. As of now only some of the key web pages are being tracked but this will gradually expand to include all documentation, this blog and all image gallery access.

## V3.1.6: RGB Images Bug Fix

The survey descriptions for a number of our surveys (notably including some of the DSS surveys and the IRAS and IRIS surveys) had an error in them that made it impossible to create RGB images if one of the affected surveys was the first of the three images. Basically we used the keyword <Scale> to describe the size of the pixels in the survey metadata rather than <PixelScale>. This misuse conflicted with the use of the <Scale> keyword elsewhere to give the default scale for the survey. In fact the actual value usually represents the same value as <PixelScale>, but it is always given in decimal degrees while the <PixelScale> typically includes non-numeric characters (e.g., a ‘ to indicate arcminutes or ” for arcseconds) that define the units.

We will be releasing Version 3.1.6 with the updated survey descriptions. Our apologies for any problems that users may have run into.

## SkyView 3.1.5: Update to ImageJ library

SkyView uses the ImageJ software library to generate all of the quicklook (JPEG, GIF, TIFF, PNG, …) images it uses. ImageJ is a very powerful public domain package for analyzing and manipulating images. A full implementation of ImageJ is included in the SkyView jar. The last time we updated this was a several years ago when we went to ImageJ version 138k. ImageJ is now at Version 149b, and we thought it was time to catch up.

If you use the SkyView jar directly, you can run ImageJ to analyze SkyView images by just adding the ImageJ setting, e.g.,

``` java -jar skyview.jar position=3c273 survey=dss imagej ```
This will start an ImageJ session with your SkyView images loaded in. There are a lot of new capabilities in ImageJ including some for combining images to produce animations that we may use in SkyView or other tools.

The change shouldn’t affect users — unless you’re already using ImageJ as described above. Then you’ll get the benefit of several years of enhancements and upgrades to ImageJ.

Note that the version of ImageJ used in SkyView is very slightly changed from the standard distribution. The most significant change is we enhanced the text plotting capabilities to allow for text at arbitrary angles. We use that for our coordinate and contour gridding.

## SkyView V3.1.4: GALEX update, Memory fix

A user (thanks Steve U!) brought to our attention a problem with the GALEX survey in SkyView. SkyView uses the GALEX archive at MAST and only retrieves files when a user first requests data in a region. We keep files in a cache, so we never request the same file twice. Only about 1/2 of the GALEX GR6 data are cached, so user requests often require us to retrieve data from MAST. It turns out that MAST reprocessed a bit under 1% of the GR6 data after we got the URL locations, which meant that the URLs that we were using to point to the data were out-of-date. If we already had the image in our cache all was copacetic, but an attempt to download an updated file caused a complete failure for that survey.

Version 3.1.4 of SkyView has been released with updated survey description files for the two GALEX surveys and should address this problem. Users of the SkyView-in-a-Jar should download the latest jar if they want to retrieve GALEX data.

In testing this out, I noticed that SkyView was failing due to memory problems when trying to tile together a large number of images. This was due to a failure to deallocate memory when we were using 4-byte reals in the input images. [That was put in recently to allow us to handle larger input images.] That’s fixed too though we haven’t heard of anyone having problems with it.

Posted in Announce, releases | Tagged , | 4 Comments

## Release 3.1.3: SkyView, DS9, Aladin and SAMP

For some while we’ve supported the Virtual Observatory Simple Application Messaging Protocol (SAMP) for SkyView when you are using the jar file. The idea is that you can run a command like:
``` java -jar skyview.jar position=3c273 survey=dss samp=true ```
and any SAMP-aware application will be notified about the new image. Such tools include Aladin and the popular DS9 image viewer (and many others). Using SAMP you can pop an image directly into these interfaces. However we weren’t including the SAMP library so you needed to add this into the Java class path to get this to work.

Another thing you had to worry about is that SAMP needs a running SAMP hub. The way SAMP works is that all of the coordinated tasks talk to a single hub task which relays messages as appropriate. Some tools, e.g., Aladin, start up a hub for you so that you don’t need to worry about this, but others, including DS9 do not.

We’ve added the full JSAMP 1.2 JAR (developed by Mark Taylor at Bristol University) inside the SkyView jar to version 3.1.3 of SkyView. That’s pretty much the only change to this version. This not only makes it easier to use the capability — you don’t need to link an outside JAR — it also includes the code for a SAMP hub, so you can use the SkyView jar to start one up for you.

So to push images to Aladin — or any task that starts its own hub — just start Aladin (or other task) and then run SkyView requests.

E.g.,
``` java -jar Aladin.jar &```

``` ```

``` java -jar skyview.jar position=3c273 survey=dss java -jar skvyiew.jar position=3c274 survey=dss ... ```

To send data to DS9, we add a command to start up a hub using the JSAMP code included in the SkyView jar:
``` java -cp skyview.jar org.astrogrid.samp.hub.Hub & ds9 &```

``` ```

``` java -jar skyview.jar position=3c273 survey=dss java -jar skvyiew.jar position=3c274 survey=dss ... ```

In both cases the generated images should magically appear in the viewing applications.

In our examples we’ve run the commands in sequence in the same shell, but you can use different windows if you prefer, but they must all be running on the same machine. You should start the Hub before you start DS9. It’s OK to use the second approach with tasks that run their own hub. Hubs’ initialization code checks to see if a hub is already running and they won’t start up if one is found.

## V3.1.2 released. Fixes to Mellinger survey

Version 3.1.2 of SkyView has been released.

Three bugs all related to the Mellinger optical surveys have been fixed in this latest release. All relate to use of the the Mellinger data. The errors were present only in images of less than 30 degrees and should not have affected all-sky images. Since release 3.0.0 the high resolution data was improperly scaled. Mellinger data is byte-scaled to values from 0-255, but values > 127 had 256 subtracted from them, so the high values were showing up as negative values. Since June 2012 the red and blue Mellinger high resolution data were transposed. Finally, due to a formatting error in the survey description file, users could not use the default values for the size (in degrees) of the field of view. The query failed without producing any image. Any queries which specified a field of larger than 30 degrees on a size should not have been affected by these problems.

We apologize for the errors which should have been caught by our regression tests — these have been updated. Many thanks for Ignacio Cisneros for graciously but persistently pointing out the problems.

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

## SkyView Surveys Summary

With the inclusion of multiple GOODS surveys we thought it might be useful to take a look at the overall properties of SkyView surveys. So here’s a summary of what we have in a few graphs.

With the addition of the HST ACS data we now have resolutions better than 0.1″ for some surveys.

The relatively miniscule coverage of the GOODS surveys is manifest in this plot.

The sensitivity (here the product of the frequency and the limiting flux in Jy) is shown here

## SkyView Version 3.1.1: New GOODS Surveys

We have just released SkyView Version 3.1.1 which has a number of new surveys in the north and south GOODS regions.
With this release SkyView includes GOODS data from the following

• Space Observatories:
• Chandra ACIS
• Hubble ACS
• Hubble NICMOS
• Spitzer MIPS
• Spitzer IRAC
• Herschel
• Ground Observatories:
• VLA
• APEX LABDOCA sub-millimeter bolometer
• VLT-ISAAC
• VLT-VIMOS
• NOAO Mayall Telescope
• Subaru
• Hawaii 2.2 m

A total of 33 distinct survey datasets of the GOODS regions including data in the radio, millimeter, infrared, optical, ultraviolet and X-ray regimes are available.

Please let us know of any other GOODS survey data the you would like to see incorporated into SkyView.

This release also includes a bug fix in the handling of the GLS projection. The GLS is simply a shifted version of the SFL projection, but the shift was not being properly accommodated in the projection. The APEX-LABDOCA survey uses this projection, but it had not been used before in any SkyView survey nor is it offered as an output choice. However users who downloaded the jar and tried to add local data in the GLS projection would have encountered the problem.

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

## More GOODS

We’ve just put out the preliminary version of SkyView V3.1.1 which has several more GOODS survey datasets:
8 new images of the north mostly from Gemini, three of south from the VLT ISAAC instrument, and five bands of Herschel data (though only 2 have data in the south). Once we’ve checked this out we’ll be formally releasing these surveys by making 3.1.1 the current version. But you can try them out right away by using specifying the version explicity — or just clicking on this link.

The Herschel data are relatively low resolution compared to most of the other GOODS surveys. The resolution decreases from about 6″ to 30″ as we go from 100 to 500 microns. Of course as with all the GOODS surveys only a tiny fraction of the sky is included. The resolution of the others is typically a bit better than 1″.

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