The project's main goal has been to create a web application similar to Windows and Linux applications like Stellarium, Starry Night or KStars. Unlinke Neave planetarium for example, this application should be done using Web 2.0 techniques (AJAX) only, i.e. not using porprietary and plug-in based approaches like Flash, Java Applets or ActiveX.

Planetarium Screenshot

This web application is one of several parts of a project called Ciclope Astro at the Faculty for Computer Science at the Polytechnical University of Madrid, Spain. Preceeding this work, there's been done some research on available web toolkits, frameworks and techniques for the Ciclope Astro project in general as well as several design studies. Nevertheless this has been done in teamwork and is not to be documented here.

Possible Approaches for a Web-based Planetarium

As mentioned above, a web-based planetarium could be realized using plug-in based techniques like Java Applets, ActiveX or Flash, but the requirements of this projects have been not to use any techniques of this type. Thus, relying on AJAX techniques "only", leads to two possible scenarios, as following.

Client-based versus server-based solution

  1. Have a web-server provide astronomical data only and do all calculation and drawing operations regarding the display of the planetarium on the client side, i.e. using JavaScript.
  2. Treat all the workload on the server side and just serve the final images to the client.

Advantages and disadvantages of various solutions

The two possible aproaches mentioned above have different advantages and disadvantages. The client-based version minimizes the traffic over the network / internet as well as the performance necessary on the server side. Nevertheless, it would demand intensive processing power from the client and would most probably hit the limits of JavaScript performance. Given the fact that we're talking of calculating the position of thousands of stars which are then to be drawn on into an image, most probably using the SVG functionalities provided by JavaScript (for example packed into a framework like Dojo) and last but not least need to be updated every few seconds or at least minutes, JavaScript is likely to have immense problems performing all this.

Considering a server-based aproach, we would of course be able to overcome all the limitations just mentioned. The client would have to do nothing but display an image, allthough in this case the server would have to do ALL the work. In detail, this means calculating the positions of celestial objects and creating the images served to the client. Although there are quite sofisticated techniques for achieving these tasks, such as JSP, ASP or PHP, this leads to the problem of the workload depending extremely on the number of clients to be served and possibilities of different views among the clients. Thus, depending on the exact implementation, anything between a cheap standard PC or a high-end server cluster could be required to run this application.

Considering the strong limitations of JavaScript and the greater flexibility in implementing a server-based aproach, the latter one has finally been chosen as the solution to be done in this project and will be discussed in detail in the next chapter.

Current Implementation

General Considerations and Limitations

As said, with a server-based solution, requirements for the web-server will vary extremely depending on the actual implementation and functionality of the application. Given for exmample a worst-case scenario of a planetarium application where some thousand stars of a typical catalogue such as Hipparcos are to be displayed and the user can freely select his location on earth as well as the point in time for which to show the constellations, all this with an update rate of a few seconds and having 1000 users connected at the same time, the workload on the server would be tremendous, as it would have to calculate all constellations and create the according images to be served for every location and point of time selected by any of the users connected. Furthermore this would have to be repeated every few seconds to update the contellations for every user according to the change in time.

Due to the limited hardware resources available for this project by the time and in accordane with its primary purpose of providing an additional way to control the telescope situated at the faculty campuse, this scenary has been stripped down to the following design, requiring much less computing power:

  1. The planetarium will only be able to show the sky for a single location, namely the faculty campus where the telescope is situated.
  2. The point of time to display the sky for cannot be selected freely. The sky can only be shown for the current time.
  3. Images are pre-calculated. The images of the sky will be calculated in advance instead of calculating them in realtime.
  4. An intelligent design of the client-side application will ask for only those parts of the sky which is actually to be displayed (e.g. if zoomed in to a certain location).
  5. The update rate for the sky will be limited to one minute.

Implementation Overview

While the client-side consists of no more than a simple web browser running an AJAX web-site, the server side consists of two parts.

  1. A JAVA application used to calculate the star constellations and create the images necessary for the planetarium application.
  2. A web server hosting an application written in JSP to serve the planetarium web site as well as the created images and the server time to the client.

The following diagram shows a logical overview of the design of the complete application and points out the relationship and interactions between the client and server side:

System Diagram

  1. The administrator will run the JAVA tile image generation application on the server side which will create and save tiled star charts in a directort on the web server and furthermore add a mapping of pixel positions in the tile images to star identifiers in the database.
  2. A user acceses the planetarium by its main site.
  3. The JavaScript code in the HTML page sent to the client will create an instance of a Google Maps object in the web browser of the user and show the default view of the planetarium. All necesary tile images for this view will be loaded asynchronously in the background and displayed as soon as they are loaded.
  4. As the user moves or zooms around in the planetarium view, necesary tiles will again be loaded in the background and displayed afterwards.
  5. Every minute, a background timer makes a request to the server to get the current server time and redirect tile images request to another foleder according to the minute of the day returned by the server. Therefore the view gets update every minute.
  6. If the user click on the planetarium at a certain locatio, the JavaScript will (in the background) pass the pixel location of the click to the server to ask it which star might be at the clicked position. The server will look up the given position in the mapping table in the database to see if there is any star at this position and return its ID if so. Finally the client side can then display information about this star.

Implementation Details

Client-side Application

To keep the amount of work for the client side application to a minimum, but also for its functionality, Google Maps API has been chosen to be used for rendering the planetarium on the client side. It provides all functionality necessary for tiled loading and displaying images a various resolutions as well as moving and zooming these images. In other words, it is perfect for displaying images of the sky.

Especially important is the fact that this API is very sofisticated regarding the display of images. Only tiles necessary to display the current field of view are loaded from the server. When moving around in the image, additional tiles will be fetched from the server just as they are needed. Furthermore, most users should be familiar with the usage of the application as they probably know it already from Google Maps.

Speaking of saving time using existent solutions for certain purposes, I'd also like to mention the Google Web Toolkit. This toolkit has not been of special interest for the planetarium but is related to it, as it is the toolkit we are using for the Ciclope Astro project in general. The toolkit provides a framework and a set of Web 2.0 classes especially regarding user interface creation but also covering asynchronous transfer, XML parsing and other aspects of Web 2.0 programming. The remarkable point about GWT is, that it provides a JAVA framework including a debugger. All programming of you web application will be done in JAVA with extremely useful debugging capabilities and when it comes to deploying your application, it can be compiled (with one click) into a HTML and JavaScript version. Google provides a special compiler for this.

Planetarium integration for this toolkit has been a bit tricky, as their is no built-in support for the Google Maps API and therefore one has to bridge the gap between native JavaScript and the JAVA code in GWT manually and with quite a few workarounds, but finally it has been achieved and can also be found in the download section.

JAVA Application for Image Generation

The JAVA application used to generate the images required for the planetarium is and adapted verion of an open source application named Mobile Star Chart. After intensive investigation on how to use existing planetarium applications such as Stellarium, KStars or PP3 to create the images necessary for the web planetarium, Mobile Star Chart has been found to be the only application of those mentioned to be adapted to create the needed images with an acceptable amount of time and programming.

PP3 has unsuitable limitations to the size of output images as it is using the tex engine. Furthermore it cannot draw star charts for a specific location. KStars and especially Stellarium are even less suitable for beeing adapted for image generation, as they are using 3D worlds and proprietary projection code as well as hardware acceleration in the sense of OpenGL. An enormous amount of time would have been necesary to change these applications to do the job.

Finally Mobile Star Chart turned out to be exacly what is needed. As it is inteded to run on mobile devices, the it already contains the code for calculating the constellations of stars and project them on a 2D image (the mobile device screen) without using any libraries as OpenGL. Nevertheless an acceptable but still significant amount of programming had to be done to make this application run on J2SE instead of J2ME and furthermore to output large, scaled and tiled star charts for various points of time to the hard disk. Last but not least, the application has also been modified to output a mapping of every star in the database (Yale Bright Star catalog) to its location on every tile image to a (MySQL) database, which is important to handle mouse clicks on the planetarium and display information on objects under the mouse cursor.

This adapted version of the application is customizable regarding various aspects of the output such as the objects to display, the point of time, the location on earth and many other settings. Details on this can be found in the operational section of this documentation.

Web Content & Web Server

The webserver basically hosts the planetarium's HTML and JavaScript content (as part of the complete Ciclope Astro page). Inside these documents is very few code just configuring (without much worth to mention) the paramteres for the Google Maps API and finally creating an instance of the sky map. Only two things that should be noted have been added.

  1. Code to handle mouse clicks on the planetarium to display information for objects under the mouse cursor.
  2. Code to update the planetarium view every minute.

Regarding the first point, a event handler has been regitered with the Google Maps API to react to mouse clicks on the screen. A click on the screen will start an asynchronous JavaScript request to a serverside JSP page containing the coordinates of the mouse, the zoom level and the current map time. As a result, the page called will deliver an XML file containing the object under the cursor, if any, as well as its catalog ID. With this result, the client-side code can finally open a popup windows displaying information about the object under the mouse cursor.

Concerning the second point, a JavaScript timer has been added to the page making an asynchronous call to a JSP on the server every minuten which will return the current time on the server. This is to keep the client-side synchronized with the server as it is to display the sky as it can be seen by the telescope at the faculty at that time and not the sky accoring to the time on the user's computer (which could be wrong or just different for users outside Spain in another timezone).