Last modification:
2007-03-26
2007-03-26
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.
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.
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.
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.
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:
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.
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:
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.
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.
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.
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).
