Figure 1: Startup screen
Keywords: Rocket Trajectory Monitoring, Rocket Trajectory Analysis, Interoperability, XML, SVG
Biography
B.Sc. Data Processing Technologist - Universidade de Taubaté (1983)
Part time M.S. student in Applied Computing, National Institute for Space Research (INPE)
Biography
N. L. Vijaykumar received a B.Sc. degree in Computational Technology from the Aeronautics Institute of Technology (ITA), Brazil, a M.S. in Applied Computing from National Institute for Space Research (INPE), Brazil, and a Ph.D. in Informatics from the Aeronautics Institute of Technology (ITA), Brazil. He has been an employee of the National Institute for Space Research (INPE), Brazil since 1978 within the Laboratory of Computing and Applied Mathematics (LAC). He was also at the King Fahd University of Petroleum & Minerals, Saudi Arabia and Center for Ocean-Land Atmosphere Interactions (COLA), University of Maryland, USA. He has been involved in designing and constructing software for scientific applications such as Remote Sensing, Operational Research, Meteorological Applications, Satellite checkout system, Urban Planning and others. His areas of research includes Specification of Complex Systems for Performance Evaluation, Performance Models, Interoperability Issues based on XML, Computer Graphics, Data Assimilation, Spatio-Temporal series analysis, Neural Networks. He is a Lecturer of Data Structures and Algorithms, Specification of Complex Systems, Hyperdocument-based Applications within the Post-Graduate program in Applied Computing at INPE. On official leave from INPE, he is presently with CMRC, UCC, Cork, Ireland to work on the HIPOCAS (Hindcast of Dynamic Process of the Ocean and Coastal Areas of Europe) project and Environmental Modeling of Coastal Processes based on Global Climate Change Impacts.
Graphics are the main means used to quickly disseminate information to a wide range of users. Due to its importance, Web applications also have to consider graphics as a major issue to embed them. However, for Web applications, issues such as interoperability pop up. Therefore, the idea of this paper is to present MART (Monitoring and Analyzing Rocket Trajectory), which tries to exploit existing web standards (XML, SVG, etc.) for use in visualizing a Rocket Trajectory path in a cartographic map projection. MART deals with data obtained in real-time so that animation procedures can be deployed. Zooming facilities are also enabled to verify, for example, launch pad region. Examples of use of this application along with a full animation will be presented.
1. Introduction
2. Tools Description
3. Application Development Description
3.1 Coordinates Data
3.2 SVG Canvas
3.3 Some functionalities
3.4 Mouse actions
4. Drawing Trajectory path
4.1 Analyzing a trajectory path
4.2 End User
4.3 Monitoring Real Time Trajectory
4.4 Simulating MART
5. Conclusions
Bibliography
Applications involving Rocket Trajectory can take a significant advantage if visualization is considered. It should cater for visualizing the trajectory path in a cartographic map enabling the determination of vehicle's actual position. A visualization tool for this purpose has been developed and presented in this paper. The main idea of this tool is to be used via web and therefore some issues of interoperability have been taken into consideration. This visualization tool is essential not only for monitoring a rocket in real-time for the purpose of safety conditions, but also for helping to achieving the best prediction information for rocket trajectory path. This application also includes the possibility to perform pre flight and post flight analysis for all types of rockets.
This application has been developed by making use of interoperability technologies such as XML (http://www.w3.org/XML/), and in particular SVG (http://www.w3.org/Graphics/SVG/) that enables the visualization within the web.
Based on the use of SVG resources one can, if authorized, simulate the launching from any part of the world. Data can be input in real time and can be visualized. Map zooming is enabled in order to view the details of about 500 meters around the launch pad. While zooming, the map is yielded in a large scale and therefore the actual point ends up lying outside the map. Due to this fact, the system automatically determines the new zoomed area in which the point should lie. This process can go on as needed. It is possible to handle with some issues such as Launch Pad, radar, cities closer to the launcher, and telemetry. The user may also insert other issues of interest as well as text and lines depicting impact point evolution, trajectory evolution, security boundary limits, cities, impact dispersion area and others. Most of the facilities within this application package can be accessed via Adobe Viewer plug-in, see http://www.adobe.com/svg/viewer/install/ for details. JavaScripts and DOM (http://www.w3.org/DOM/) have also been used. The present version makes the connection with the server through URL, and data is accepted based on Latitude and Longitude coordinates. It is also possible to monitor other kind of objects, like airplanes or balloons.
This application system is accessed by means of invoking a HTML (http://www.w3.org/MarkUp/) page in which SVG files are embedded and has all references directed to the XML files as well as to the java-scripts files.
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" > ... <script src="AVIProC.js" language="javascript"></script> <script src="AVIProCaux.js" language="javaScript"></script> ... <XML id="dataXML" src="Map.xml"></XML> <XML id="PredictXML" src="Testing.xml"></XML> ... <embed src="AVIProC.svg" name="map" width="900" height="500" type="image/svg+xml" pluginspage="http://www.adobe.com/svg/viewer/install/" /> |
However, this HTML file must be validated in accordance with XHTML 1.1 (http://www.w3.org/TR/xhtml11/). The paper is organized as follows: Section 2 describes briefly the open web standards used for this application; some details of how the application system has been developed are provided in Section 3; and Section 4 provides the particularities of this application as well as some information of what kind of end user that could use it. Finally, the paper ends with some conclusions.
This section is dedicated to provide a brief description of the open web standards used for the application: XHTML, HTML, XML, SVG, DOM, JavaScript and SVGViewer. Detailed information of these web standards can be accessed at [W3C] site or [adobe] site.
Special care was taken to develop the software in accordance with W3C (World Wide Web Consortium) guidelines. This Consortium develops interoperable technologies to take the Web to its full potential. It is a forum for information, commerce, communication, and collective understanding. Details about this consortium can be found in W3C site.
Interoperability technologies that are used for the application in question are listed below along with a brief description:
Other powerful technologies used by this application to perform its operability are:
For unknown reasons, some troubles were encountered when using XML specification along with, for example, the Netscape browser. Due to this reason, this application's version requires the Internet Explorer 5.0 or higher to work properly.
As mentioned earlier the main feature for this application is to visualize the trajectory path in a cartographic map to determine vehicle's actual position. When the application is started for the first time, a startup graphic is displayed on the computer screen as shown in Figure 1 . For analysis purposes, the user can specify the Latitude and Longitude coordinates, which will become the - of the map when a zoom is performed. The user must also specify, in degrees, the distance from the center and the border of map. Section 4 deals with details of this functionality. In all cases, texts, circles, paths can be inserted on the map.
Taking a look at the map, the following questions remain to be answered:
All the coordinates are represented in terms of geodetic latitude and longitude. Therefore, the outlines of the continents as well as the outlines of some countries are based on latitude and longitude. However, in some continents the outlines for the countries are yet to be developed. For each country or continent, a color was defined and a name was given.
These data are stored in XML format, and must obey the hierarchical structure shown in Figure 2 :
The following block shows a part of the XML file in order to have an idea of how it looks like:
<?xml version="1.0" encoding="ISO-8859-1"?>
<Map>
<Continents name="America">
<Country>
<Name>Brazil</Name>
<Color>rgb(0,200,0)</Color>
<Points>
-32.897 -53.261
-32.837 -53.244
-32.805 -53.207
-32.787 -53.186
-32.764 -53.116
-32.727 -53.111
-32.695 -53.052
-32.658 -53.009
-32.630 -52.977
-32.575 -52.950
-32.538 -52.924
-32.519 -52.929
-32.483 -52.897
-32.409 -52.870
-32.409 -52.844
...
|
The HTML page, which has the SVG files embedded, has all references directed to the XML files as well as to the JavaScript files. Then, in order to draw the cartographic map shown above, DOM manipulates the XML data as a structure, making it easy for JavaScript commands to deal with each country, island or lake as an object and incorporate these objects to the computer screen. The following block shows a part of the source:
mapXML = dataXML.XMLDocument; // dataXML is definied .html file
svgmap = document.map.getSVGDocument(); // map is name defined in .html in embed tag
allPointsWorld = mapXML.getElementsByTagName("Points"); // get ALL the POINTS
pointsWorldName = mapXML.getElementsByTagName("Name"); // get ALL the NAMES
pointsWorldColor = mapXML.getElementsByTagName("Color"); // get ALL the COLORS
// Start populating polygon countries
pointsCountry = allPointsWorld(0).text; // the first group of POINTS
var populatePolygon = svgmap.getElementById("World"); // defined in .svg file
populatePolygon.setAttribute("points", pointsCountry);
style = populatePolygon.getStyle();
style.setProperty("fill", pointsWorldColor(0).text);
style.setProperty("stroke", "none");
populatePolygon.setAttribute("onmouseover", "viewDetails('" + pointsWorldName(0).text + "')");
populatePolygon.setAttribute("onmouseout", "emptyDetails()");
for (i = 1; i < allPointsWorld.length ; i++) {
cloneCountry[i - 1] = svgmap.createElement("polygon");
pointsCountry = allPointsWorld(i).text;
cloneCountry[i - 1].getFirstChild();
cloneCountry[i - 1].setAttribute("points", pointsCountry);
style = cloneCountry[i - 1].getStyle();
style.setProperty("fill", pointsWorldColor(i).text);
cloneCountry[i - 1].setAttribute("onmouseover", "viewDetails('" + pointsWorldName(i).text + "')");
cloneCountry[i - 1].setAttribute("onmouseout", "emptyDetails()");
}
|
The next sub-section describes how these objects will effectively be incorporated to the screen.
At this point, the application knows all the objects and it also knows that these objects have to be drawn on the computer screen. As mentioned elsewhere, the objective of this paper is to exploit existing web standards, and therefore the means through which graphics are rendered based on XML is SVG. First of all, it is essential to understand the philosophy defined by SVG. According to its philosophy, the space to which drawings are rendered is known as canvas and it is assumed to be infinite in each dimension in the space. However, the graphics are rendered within an area relative to a finite rectangular region of the canvas. This finite rectangular region is known as the SVG view-port. For visual media [CSS2-VISUAL] , the SVG view-port is the viewing area where the user sees the SVG content. SVG ViewBox is another relevant concept. It corresponds to a "window" within the canvas whose contents are mapped to the SVG view-port.
Some attributes of SVG ViewBox are relevant, within the application point of view, such as aspect ratio attribute.
The coordinate system is organized with the origin at the top-left from which x-axis scans rightwards whereas the y-axis scans to a downward direction. Specific transformations, on a group element, can be used to establish a new current coordinate system. These transformations consist of rotation, translation and scaling.
As this application draws cartographic map, the SVG ViewBox must be within the range of -180 deg to +180 deg for the x-axis and -90 deg to +90 deg for the y-axis. X-axis refers to Longitude coordinate and y-axis to Latitude. Thus, the SVG ViewBox must be set according to these values. However, when ViewBox is set according to its attributes (http://www.w3.org/TR/SVG11/coords.html#ViewBoxAttribute), the coordinate point of the upper left corner is (-180, -90). But that is not accepted for the application in question. What is really required for the application is, that this coordinate point should correspond, in fact, to the bottom left corner. Therefore, a rotation of -90 degrees has to be performed over the x-axis, so that all the subsequent groups of elements that are to be plotted can be affected. The application does not accept any distortions and therefore, the aspect ratio was already preset so that its value is preserved. This makes the aspect ratio of the Viewport to be different from that of the ViewBox. So, the ViewPort will not occupy the entire area and within this application, the view-port's area is centered.
The initial coordinate system for MART as well as the group definition where all elements will be plotted, could be as follows:
<svg id="root" x="30" y="0" width="700" height="500" version="1.1"
viewBox="-180 -90 360 180" preserveAspectRatio="xMidYMid meet" xmlns="http://www.w3.org/2000/svg"
onload="initMAP(evt)" onmousemove="mouseMove(evt)" onmouseup="mouseUp(evt)" onmousedown="mouseDown(evt)" >
<g id="workarea" transform="rotate(-90) translate(0,0) scale(1.0)" >
...
<polygon id="World" style="stroke:rgb(0,0,0); fill:rgb(220,130,40); fill-opacity: 0.8; stroke-width:0.001" />
...
</g>
|
The source code in order to plot those objects on the screen can now be viewed.
workarea = svgmap.getElementById("workarea");
for (i = 1; i < allPointsWorld.length ; i++) {
workarea.appendChild(cloneCountry[i - 1]);
}
|
One of the main functionalities of this application is associated to help to achieving the best prediction for a rocket trajectory path. The tool is also useful for following the trajectory of the rocket. Usually, anyone could use the application in order to take advantages of the visual analysis; however, in order to gain access to server data as well as receiving data that is drawn in real-time, users must be given special privileges previously and duly authorized. Section 4 discusses this issue with more details.
These data that are drawn can be saved at any time in order to be redrawn at a later stage. One can obtain a graphical picture of as many paths as specified in a file for analysis purposes. Since the file with the coordinates is indeed an XML file, the following structure must be obeyed as shown in Figure 3 :
In order to make a specific analysis, usually the user wishes to use her or his own references on the map. Important locations like radar building, telemetry building, cities close to the launcher and others could be represented by a circle and text. The entire predicted trajectory as well as the boundary lines that delimit the safety range could be drawn by using polylines and text. The user can save this configuration in order to review the same features in the future when he or she starts MART. The following block shows a part of the saved XML file in order to have an idea of how it looks like:
<?xml version="1.0" encoding="ISO-8859-1"?>
<Traject>
<RocketName name="Testing 1">
<predict>
<nameOpe>Predict</nameOpe>
<Points>
-2.99 -44.00
-2.89 -44.10
-2.79 -44.20
-2.69 -44.30
...
</Points>
</predict>
<security>
</security>
<Details>
<StartForReal latitude="-2.0" longitude="-44.0" r="10"/>
<circle cx="-2.0" cy="-44.0" r="0.01"/>
</Details>
...
|
Functionalities involving mouse actions will be discussed in next sub-section.
Event handlers can be associated to any object. Thus, any mouse events, such as mousemove, mouseover and mouseout, can be associated to any country or island that are objects in SVG Viewport. In fact, this means that when the mouse drags over any object, its position is detected by the application and converted to Latitude and Longitude coordinates; besides, its name is "captured". It is necessary to emphasize that, using SVG resources one can associate any event handlers to any object as well as to get information of all objects according to its specification in XML file.
The mouseclick event has a wide variety of functionalities. First of all, in spite of SVG Specifications have its own actions for right mouse clicking, MART overrides this functionality and make its own. When the left mouse button is clicked on the map, the action performed depends on the choice, previously made by the user. If a circle was selected, then a circle is drawn where clicked. If a text was selected, then a dialog box will appear to input text and the text will be drawn, and so on. In case of a right mouse button click, MART tries to recognize which object is exactly in the clicked position, and a drop-down menu appears along with menu options depending on the object that was encountered. For example, if a circle is recognized, then the center coordinates and radius of the circle will be part of menu items. Consequently, a user could change these values. When a text is recognized the left coordinates will be part of menu items. In this case, as a text can be inserted relative to its latitude, longitude coordinates or relative to its x, y position on the screen, menu items of one text could be different from another. One should remember that if the text was inserted according to its x, y position, this will not change its location even when a zoom is performed. All elements created can respond to an event based on a mouse click.
Although keyboard events are part of the SVG Specification, this resource is used only to insert texts.
Figure 4 is an example for the application. For security reasons, the trajectory above is for illustration purposes only. This is a map around Alcantara Launch Center (CLA), located in north Brazil. This illustration could be drawn according to the XML file represented in Figure 3 .
SVG resources enable one to perform zooms by specifying transformation operations such as translation, scaling, rotation and others in order to place the new desired area in the view-port space. However, by changing ViewBox attributes one can also achieve the same results. Each method has its own advantage. This application changes ViewBox attributes to perform zoom operations.
To reproduce an image like the one in Figure 4 , Latitude and Longitude coordinates from the center of the map as well as the distance from this center and the border of the map, must be set. Thus, with these attributes the system will perform a new ViewBox. It doesn't matter whether the user inserts circles, texts, paths on the map before or after a new ViewBox is set, except for the radius, font-size and stroke-width respectively. Why radius, font-size and stroke-width? The reason is while zooming, if these features are not somehow changed, they may not appear on the screen. Therefore, the new values are adjusted automatically according to the zoom or ViewBox.
Any objects inserted in analysis could be left on the screen in order to help visualizing where the rocket is really located in a real time monitoring.
One of the major uses for the tool described in this paper is for those that are responsible to determine the best trajectory path for a given rocket based on its restrictions. The tool can be used not only for visualization of the calculated trajectory in a cartographic map, but also for comparing trajectories with another.
Indeed, authorities can also have an access to accompany the rocket launch from any place by using a PC. Usually they are linked to Launch Center.
So far it has been shown that the application can be used as an off-line job to visualize and identify flight security problems as well as rocket performance well ahead of its launch.
Now, due to the use of SVG resources one can, if authorized, simulate the launching from any part of the world.
However, when the application "is in real-time state", it stops accepting any kind of interruptions, such as mouse events, unless there is a user request to stop the acquisition.
Recalling the structure shown in Figure 3 , based on "Start Position for Real Time", Figure 5 shows the initial screen for real time monitoring. It is assumed that the latitude and longitude coordinates belong to the area of Alcantara Launching Center (CLA).
Figure 5 shows the zoomed area around Alcantara Launching Center (CLA), and the application makes the connection with the server and waits for the first data arrival. This application makes a request for data through URL, using the method getURL, which is a predefined function form the Adobe Viewer scripting engine. Periodically, the path file specified in getURL method, is checked to ensure when its length becomes bigger than zero. This is used to synchronize the rocket lift-off with the application controls. When this occurs, the system starts "reading" the contents of the file, which has only two values at each time, associating the first value to the Latitude coordinate and the second one to the Longitude coordinate of actual position of the rocket. Part of java-script code, which deals with this feature is as follows:
function initRT(evt) {
var startstop;
var svg_startstop = evt.getTarget().getOwnerDocument().getElementById("startstop");
startstop = svg_startstop.getFirstChild();
if ( startReal == true ) {
startReal = false;
startstop.setData("Stop Real Time from WEB"); // Now the user may stop getting data
Latitude[0] = StartPosRT.Lat; // Central point in the map acoording with XML file
Longitude[0] = StartPosRT.Lon;
getURLReal();
}
else {
startstop.setData("Start Real Time from WEB");
startReal = true;
}
}
function getURLReal() {
getURL("SITDL.out", drawReal); // Checks the file SITDL.out in the server
}
function drawReal(object) {
if ( object.success ) {
var pointsFromWEB = new String(object.content);
if ( pointsFromWEB.length > 0 ) {
var eachpointsFromWEB = pointsFromWEB.split(' ');
Latitude[count] = eachpointsFromWEB[0];
Longitude[count] = eachpointsFromWEB[1];
if ( startReal == true ) return;
var drawRocket = svgmap.getElementById("drawRocket");
averageX = moveX(); // calculates the average x-axis dislocate
averageY = moveY(); // calculates the average y-axis dislocate
limits(averageX, averageY); // makes a new ViewBox if need
if ( count == 1 ) RTLine[count - 1] = svgmap.getElementById("lineALL");
else RTLine[count - 1] = TrajetoriaReal.cloneNode(true); // creates a new line element
TrajetoriaReal = RTLine[count - 1];
TrajetoriaReal.setAttribute("x1", Latitude[count - 1]); // draws a new line element
TrajetoriaReal.setAttribute("y1", Longitude[count - 1]);
TrajetoriaReal.setAttribute("x2", Latitude[count]);
TrajetoriaReal.setAttribute("y2", Longitude[count]);
drawRocket.setAttribute("x", Latitude[count]); // move symbol rocket
drawRocket.setAttribute("y", Longitude[count]);
workarea.appendChild(TrajetoriaReal);
count++;
}
else { } // pointsFromWEB.length less than zero
}
else {
var errorOcurreded = "";
errorOcurreded = "File connection has failed";
alert(errorOcurreded);
return;
}
if ( count < 10000 ) setTimeout('getURLReal()', 100) // Getting data in 10 Hertz
}
|
Thus, it can update the data in the picture, creating a new line segment and moving the rocket symbol to the new coordinates, as shown in Figure 6 .
As can be viewed, the map is yielded in a large scale, thereupon each new coordinate must be checked whether or not it is inside the actual view-port space. This check means that the actual Latitude coordinate must be within upper and bottom coordinates of the view-port, as well as the actual Longitude coordinate must be within left and right coordinates.
For cases where the point lies outside of the map, this application sets new values to the ViewBox attributes, according to the "last" points. This is necessary not only to ensure that the actual point does not lie out of the map, but the next ones, as well. The process of, automatically determining the new area where the point lies in the zoomed area, can go on as needed.
So, while the length of the file specified in the URL method is greater than zero, the application continues the process.
Although this application uses real-time features, they are not required as a main objective. Anyhow, a remote user will not have access to actions that change the rocket's path and therefore it doesn't matter whether the data takes how many seconds to reach her or him. The very important factor that one has to bear in mind is that the data is reliable and the data, regardless of WEB delays, should reach the user.
In order to use MART, one must access the site at http://www.directnet.com.br/users/joaol/cnd/AVIProC.html and use all functionalities granted. MART takes about 10 seconds to be loaded and efforts will be made to sort this out for future versions. This is one of the reasons that disabled the inclusion of the MART functionalities within the context of this paper.
Use of computer graphics, if properly applied, presents a gracious interface to many a application and invites the users (even laypersons to computers) to interact with the application without any fear, quite natural to those not used with computers. Definitely, rocket trajectory is such application that should make use of the potential of computer graphics. However, within the context of the paper, it was essential to develop the application for use over the Internet by space-related community. Interoperability technologies such as XML and in particular SVG to deal with graphics over the web have come to the rescue.
It was shown that web standards could be and must be adopted for such applications. The technologies used and supporting software needed to develop for the proposed application are free of charge and can be downloaded from many sites. Moreover, discussions over these issues are going on in order to standardize such technologies as well as the supporting tools.
However, the proposed application has yet to be worked to overcome some problems. The outlines for continents beyond South America, Central America and Africa must be included. This issue will be extended to countries, islands and lakes. More research and experimentation must be performed in order to reduce the loading time especially if the outlines for other continents as well as for countries, islands and lakes are included.
SVG Specification enables the use of group elements similar to a class within object-oriented technology. By using such features it will be possible to embed all of the rocket characteristics in the application, such as rocket layout, details of payload, details of the mission, etc.
More research will be dedicated to deal with other types of map projections. Another drawback that will be tackled is to make this application available from browsers other than Internet Explorer.
XHTML rendition created by gcapaper Web Publisher v2.0, © 2001-3 Schema Software Inc.
