%TODO: Still at least one \ref{sec:.... at work in here - not any more!

\begin{article}

\title{Collaborative Web-Based Mapping of Real-Time Flight Simulator and Sensor Data}

\author{Rabih Dagher, Cristian Gadea, Bogdan Ionescu, Dan Ionescu and Robin Tropper}

\maketitle

\section{Abstract}
Google Maps is an example of how Web 2.0 technology such as AJAX can be used to create online map services that are easy to access, user-friendly and fast. Thanks to flexible web-based mapping APIs, it is now possible for non-experts to plot and distribute GIS (Geographic Information System) data to a large audience. Most data plotted so far, however, has been relatively static. In addition, the typical webpage layout has limited the interaction possibilities for online maps when compared with windowed desktop applications. This paper will present a JEE-based publish/subscribe architecture that allows real-time sensor data to be displayed collaboratively on the web, requiring users to have nothing more than a web browser and Internet connectivity to gain access to that data. The architecture is tested using live data from Microsoft Flight Simulator and data conforming to the OGC Sensor Observation Service (SOS) standard. By using the latest web-based technology from open source projects like OpenLayers and 52North, this paper shows how maps and GIS data can be made more accessible, more social and generally more useful.

\section{Introduction}
\label{sec:Introduction}

With the growing adoption of social websites like Twitter, the demand for real-time data on the Internet is now higher than ever before. New web browser technologies have made it easy for users to access and publish dynamic data, such as what they are doing and where they are currently located. However, while there exist online services that promise ``real-time'' geographic data, a closer look will almost always reveal that the data is delayed or otherwise not presented in a useful way. In addition, collaborating with others in real-time on maps themselves containing real-time data has yet to be attempted from inside a web browser. 

This paper introduces a new framework that allows displaying real-time sensor data within a collaborative web-based environment. The framework extends the publish/subscribe messaging model to meet the reliability and scalability demands of a social and collaborative online environment based on real-time data. While the framework can be adapted to a large variety of real-time streaming data sources, this paper will focus on live data provided by Microsoft Flight Simulator 2004 and data that conforms to the Sensor Observation Service (SOS) standard. SOS is one of the Sensor Web Enablement (SWE) standards of the Open Geospatial Consortium (OGC), an international standards organization with nearly 400 supporting companies and institutions \cite{ogc}. 

The real-time data will be rendered by using the open source OpenLayers API and will be displayed inside an in-house platform for real-time web-based collaboration known as UC-IC (``you see I see''). UC-IC recreates a familiar desktop environment within the web browser, allowing maps to be organized within windows and manipulated in user-friendly ways. Additionally, the UC-IC platform was designed from the ground up to provide a social environment that enables the real-time transfer of applications and information to and from collaborators. This paper will show how the UC-IC platform allows for novel ways of interacting with maps containing real-time GIS data.

\setcounter{section}{1}
The rest of this paper is organized as follows. \emph{\ztitleref{sec:Background}} introduces the technology involved in displaying real-time data on the web and analyzes how the approach presented in this paper differs from existing solutions. \emph{\ztitleref{sec:SystemDesign}} then discusses the unique client and server design of the proposed system. \emph{\ztitleref{sec:Results}} offers a look at two different deployments of the architecture: one with real-time data provided by running instances of Microsoft Flight Simulator, and the other using live SOS sensor data. Finally, \emph{\ztitleref{sec:Conclusion}} reflects on the contributions of this paper and proposes topics for future research.

\section{Background}
\zlabel{sec:Background}

It was just over a decade ago that the Internet was limited to static content accessed using archaic web browsers. Despite these limitations, Geographic Information System (GIS) data quickly found its place on the Internet. Released in 1996 as a free service, MapQuest \cite{mapquest} made it possible for users to search for a location by name and to navigate the resulting map by using several buttons that surrounded the static map image (including buttons to select the zoom level). Users would see the entire webpage refresh for each navigation operation. Even with these inconveniences, there was something appealing about the interactivity and accessibility brought forth by the Internet that made it a good fit for geographic information.

As the Internet evolved to support more dynamic webpage content through the introduction of Rich Internet Application (RIA) technologies such as Asynchronous JavaScript and XML (AJAX), it came as no surprise that one of the first websites to make the most out of this new technology was a mapping site, namely Google Maps \cite{gm}. Launched in 2004, Google Maps combined visually appealing maps with a very accessible user interface. It used AJAX to dynamically load sections of the map as the user dragged the map with the mouse cursor, a defining characteristic of what are now known as ``slippy maps'' \cite{slippy}.

While Google Maps offered many benefits (including that the service and developer tools were available at no charge), it also had some shortcomings. Its simplified interface, while pleasant to use, omitted support for the addition and selection of user-defined layers, such as layers based on the Web Map Service (WMS) standard defined by the OGC. The API available to developers required obtaining a key from Google, which was only functional on one domain and imposed numerous restrictions on how the map was to be used, including the following as described in the Google Maps Terms and Conditions:
\begin{quotation}\small
Except where you have been specifically licensed to do so by Google, you may not use Google Maps with any products, systems, or applications installed or otherwise connected to or in communication with vehicles, capable of vehicle navigation, positioning, dispatch, real time route guidance, fleet management or similar applications.\cite{gmterms}
\end{quotation}
Another limitation of the Google Maps API was that the API code itself could not be deployed on servers not owned by Google, meaning that developers had to rely on Google's uptime and availability. If developers wanted to demo their browser-based map application in an area without Internet access, they would be out of luck.

Several open source ``slippy maps'' emerged to address these drawbacks, with OpenLayers currently being the largest after absorbing many of the developers from the now-defunct MapBuilder project \cite{mapbuilder}. OpenLayers has appeared in several academic papers \cite{ol1}\cite{ol2}. There are no references to any ``slippy map'' being used for real-time data within a flexible collaborative environment, however. 

Several papers have looked into the implications of real-time data delivery to a browser \cite{ClAp}. In addition, online ``WebOS'' environments have existed for some time \cite{desktoptwo}, although interaction with other users in these environments is usually limited to basic sharing of media, and they do not allow for full real-time collaboration of entire web-based applications and their data. 

The publish/subscribe messaging model is a well known solution for real-time communication and is used in numerous examples, including as part of the OGC Sensor Alert Service (SAS) implementation of 52North. In this SAS architecture, both Publisher and Subscriber register themselves on the SAS server and communicate with each other using the open Extensible Messaging and Presence Protocol (XMPP) through a Multi-User Chat (MUC) channel \cite{sasfwk}. This paper, however, will present an approach that uses a registry service and other techniques to ensure that the architecture is scalable and robust enough for streaming data to a real-time social networking environment.

\section{System Design}
\zlabel{sec:SystemDesign}

This section presents the client-side and server-side design that allows real-time GIS data to be delivered to a collaborative web-based environment.

\subsection{Client-Side Design}

The client-side user interface is a web-based implementation of the desktop metaphor, consisting of familiar windows, icons and menus that can be manipulated by using the mouse. The entire environment, however, is built on top of a collaborative platform that allows any window to be ``sent'' to another user. This is done simply by dragging a window onto an icon on the web-based desktop representing the friend who is to receive the application (and who must acknowledge a dialog to accept it). This sending process is unique in that the entire application logic, in addition to the current data within that application, is sent as part of the window. This is made possible by an advanced XML-based syntax and dynamic resource loading techniques (AJAX-Push) that go beyond the scope of this paper.

What is important to note, however, is that this concept of ``sending'' does not necessarily mean that the user doing the sending no longer retains the application. Rather, both users can have the same window open, and the inherent collaboration built into the system ensures that any actions performed within that application are automatically synchronized to the other user. For example, any text being typed into a text field will be communicated character-by-character to the other user's browser so that, as much as possible, both users always see the same application state. The environment was named ``UC-IC'' to highlight these collaborative characteristics.

\begin{figure}
	\centering
	\includegraphics[width=0.95\textwidth]{foss4g09/gadea/jipbasic.jpg}
	\caption{UC-IC environment with JIP Windows open.}
	\label{fig:JIPBasic}
\end{figure}

Real-time collaboration on UC-IC is supported for applications programmed in, or able to communicate through, DHTML (AJAX). This includes Java Applets and Adobe Flash components, all of which can communicate through the DHTML-based UC-IC platform, offering a flexible environment for collaborative application development. Existing applications built on the UC-IC platform include a videoconferencing/chat application, a rich-text editor for live co-authoring, a collaborative video player, and a drawing application that can be reused for annotations on top of other applications. 

The real-time nature of the platform makes it ideal for GIS applications dealing with sensor data. The GIS application implemented on the UC-IC platform was named Joint Intelligence Picture (JIP) and is shown in Figure \ref{fig:JIPBasic}. It consists of four different windows that communicate with each other through methods provided by the platform:

\begin{figure}
	\centering
	\includegraphics[width=0.95\textwidth]{foss4g09/gadea/collabmap.png}
	\caption{Two users collaborating on a JIP Map Window inside UC-IC.}
	\label{fig:collabmap}
\end{figure}


\begin{description}
\item[JIP Map Window] The Map Window contains an interactive ``slippy map'' generated by the OpenLayers API \cite{ol}. It is the main window that appears when JIP is selected from the UC-IC applications list and it contains buttons for hiding and showing the other three windows that make up JIP. Inviting other users to collaborate on a JIP Map Window allows all of those users to see actions such as zooming, panning and drawing on the map. Figure \ref{fig:collabmap} shows how a red circle drawn by one user appears on the collaborative Map Window of another user. A close-up of each screen is provided in the top half of the image.
Other JIP Windows can also affect the contents of the Map Window; for example, using the Search Window can invoke the Map Window to show a specific location. In addition, markers may be displayed on the map based on real-time sensor data (for example, GPS coordinates of a moving vehicle).

\item[JIP Search Window] The Search Window contains a search box and list area where search results appear. Clicking on a search result updates the JIP Map Window. A custom geocoding solution provided by M3Data \cite{m3data} is used to generate the results.

\item[JIP Layers Window] Part of the OpenLayers API, the Layers Window allows users to choose from a list of predefined map base layers. The list contains several custom map layers conforming to the OGC WMS standard and hosted on a local GeoServer \cite{geoserver} deployment, as well as free WMS layers from NASA \cite{nasawms} and OpenSteetMaps \cite{osm}. In addition, the OpenLayers API supports loading layers from commercial services such as Google Maps, although these were avoided for reasons related to ease of deployment as mentioned in section \emph{\ztitleref{sec:Background}}. The Layers Window also contains checkboxes for showing and hiding the sensor data markers that are to appear on the map.

\item[JIP Data Window] The Data Window contains information based on user clicks in the Map Window. For example, a user can click on a barometric sensor marker on the map and see a real-time dial indicating barometric pressure in the Data Window. Like all windows in the UC-IC environment, the Data Window can be shared with other users on its own (for example, if a receiving user only needs to watch the live dial move and does not need the corresponding map).

\end{description}


\subsection{Server-Side Design}

In order to obtain real-time SOS data and display it within the JIP Map Window or Data Window, the web browser has to be in constant communication with the UC-IC server using AJAX. The Java Enterprise Edition (JEE) technology found in the open source JBoss Application Server \cite{jboss} is used to make this possible. Of particular importance to the real-time architecture is JBoss' built-in Java Message Service (JMS) Server called JBoss Messaging. 

JMS allows for asynchronous messaging based on the publish/subscribe messaging software pattern. The purpose of a JMS Server (sometimes also called a JMS Provider) is to route messages between JMS Clients, which can be either JMS Publishers or JMS Subscribers. JMS Publishers publish messages to a certain ``topic'' on the JMS Server, and JMS Subscribers subscribe to that topic to asynchronously receive the messages. The JBoss Application Server includes a JMS Server, while JMS Clients can be Java applications that use the JMS API.

\begin{figure}
	\centering
	\includegraphics[width=0.95\textwidth]{foss4g09/gadea/JMSArch.pdf}
	\caption{Basic real-time architecture using JMS.}
	\label{fig:JMSArch}
\end{figure}

A basic real-time architecture is shown in Figure \ref{fig:JMSArch}. To initiate the transfer of real-time data, the client (the user in a web browser) must send an AJAX request that causes the UC-IC server (the JMS Subscriber) to subscribe to the real-time stream via the JMS Server. A JMS Publisher component is tasked with polling a real-time data source and receiving its response. The JMS Publisher then publishes the response to the JMS Server using a pre-arranged topic. The JMS Server then uses asynchronous messaging to forward the results to any JMS Subscribers who have subscribed to receive messages on that specific topic. Finally, the subscribed UC-IC Server sends the message to the client using AJAX-Push. The browser based client then parses the data and displays it within JIP. 

This sequence of events can be seen in Figure \ref{fig:MSC}. Note that, as was shown in Figure \ref{fig:JMSArch}, multiple JMS Publishers can be sending real-time data to the JMS Server at the same time. Additionally, standard JMS methods exist for unsubscribing (based on an AJAX request from a user) and terminating the publishing process.

\begin{figure}
	\centering
	\includegraphics[width=0.95\textwidth]{foss4g09/gadea/MSC.pdf}
	\caption{Event sequence for basic real-time data delivery to web browser.}
	\label{fig:MSC}
\end{figure}

While the above architecture would be sufficient for basic real-time data transmission, our final architecture features several enhancements that offer additional scalability and robustness required for real-time delivery to a social and collaborative platform like UC-IC. Having one centralized JMS Server, for example, is not ideal for real-time data delivery since the JMS Server could suffer an outage or become overloaded. A JNDI (Java Naming and Directory Interface) Registry Server is therefore introduced. The JNDI Registry Server stores a list of topics and the network address of the corresponding JMS Server where the topic is managed. JMS Publishers and Subscribers, which are pre-configured with the topics that they are to access, must first request the location of a JMS Server via the JNDI Registry Server. Once they obtain the location of the JMS Server, they can proceed as above.

By using a JNDI Registry Server, new JMS Servers can be added to the system with ease, allowing for much better scalability of the system as the number of topics increases. In addition, the support for redundancy of the system is increased since topics can be reassigned to different JMS Servers by changing the values stored by the JNDI Registry Server. By changing the location of the topics, JMS Clients can be dynamically assigned to the best JMS Server for optimal real-time data delivery. 

The architecture robustness is further increased by keeping a list of alternate JNDI Registry Server locations in the JMS Servers and JMS Clients. The architecture can also support security through the use of SSL certificates, although security implications are beyond the scope of this paper.

\section{Results}
\zlabel{sec:Results}

The design described in section \emph{\ztitleref{sec:SystemDesign}} was applied to two different deployments: one with real-time data from Microsoft Flight Simulator, and the other using live sensor data based on the Sensor Observation Service (SOS) standard.

\subsection{Flight Simulator}\label{subsec:PlanesRes}

\begin{figure}
	\centering
	\includegraphics[width=0.95\textwidth]{foss4g09/gadea/rtplanes.png}
	\caption{Flight Simulator test setup overview.}
	\label{fig:rtplanes}
\end{figure}

To test how the real-time architecture functions within a collaborative web-based environment, a controllable real-time data source was needed. Microsoft Flight Simulator 2004 was selected since the real-time aircraft data from inside the game could be accessed through a driver called FSUIPC \cite{fsuipc}. By setting up the JMS Publisher with the driver as the data source, XML data could be obtained for asynchronous sending to the UC-IC Server and display on the JIP client. A high-level view of this architecture is summarized in Figure \ref{fig:rtplanes}.

\begin{figure}
	\centering
	\includegraphics[width=0.95\textwidth]{foss4g09/gadea/threeplanes.jpg}
	\caption{Real-time data from three different Microsoft Flight Simulator sessions displayed inside JIP.}
	\label{fig:threeplanes}
\end{figure}

The system was tested with three different Flight Simulator instances running on three different computers, each with their own JMS Publisher. This is shown in Figure \ref{fig:threeplanes}. As the planes moved, a marker on the JIP client would move to show each plane's latest location. In addition, clicking a marker would populate the JIP Data Window with additional streaming information, such as the plane's current altitude, air speed and heading. 

Although it was clear that a stream of data from the game was being received by the browser, the exact delay in the data was difficult to gauge. An additional feature was added that would change the plane marker color to red in the case of a simulated engine failure, which could be quickly activated from within Flight Simulator. The delay was observed to be less than two seconds when testing on a local network. The JIP Map Window was shared with five other UC-IC users, who could navigate and draw on the map while the planes were moving.

\subsection{SOS Data}\label{subsec:SOSRes}

To test the system with more typical GIS sensor data, a standard SOS server was set up by hosting the open source 52North SOS Server component \cite{north}. The JMS Publisher component was tasked with polling the SOS Server using GetObservation requests. The JMS Publisher then received a response in the OGC Observation \& Measurements (O\&M) format. The JMS Publisher component then sent the O\&M response to the JMS Server component, which would asynchronously forward it to the UC-IC Server, and the UC-IC Server would send it for parsing and display on the client using AJAX. In this case, an open source library called JFreeChart was used to display the data as a real-time dial \cite{freechart}.

Again, the real-time performance was very good with almost no noticeable delay, and the collaborative nature of the system made it easy to monitor and annotate the data as a group.

\section{Conclusion}
\zlabel{sec:Conclusion}
This paper introduced an architecture used to deliver real-time Flight Simulator and SOS sensor data to a social and collaborative UC-IC environment accessible from within a web browser. This was accomplished by using open source technologies, including OpenLayers to display the real-time data and JBoss to make asynchronous communication possible. The system was tested by using real-time data from Microsoft Flight Simulator and a locally-hosted SOS server using open source components from 52North. In both cases, the real-time data streamed smoothly to the JIP client application and was available for real-time collaboration with other users of UC-IC.

Future work will attempt to address limitations of JavaScript memory management techniques used by browsers, which can cause performance issues if the real-time data is left streaming for long periods of time. The SOS standard, for example, offers a less-verbose GetResult request which is more ideal for real-time data and would allow for more complex sets of real-time data to be delivered to the client. Although experiments with mobile devices have already been undertaken, the great breadth of mobile web browsers has given inconsistent results when attempting to load the DHTML-based UC-IC environment, and are worth exploring further. Finally, other standards such as the Sensor Alert Service could be implemented to communicate scenarios like the plane engine failure.

\address{Rabih Dagher, Cristian Gadea, Bogdan Ionescu, Dan Ionescu and Robin Tropper,\\
NCCT Laboratory\\ 
University of Ottawa\\ 
161 Louis Pasteur Room B-306\\ 
Ottawa ON K1N-6N5\\ 
CANADA\\ 
\email{rdagher AT ncct.uottawa.ca}\\ 
\email{cgadea AT ncct.uottawa.ca}\\ 
\email{bogdan AT ncct.uottawa.ca}\\ 
\email{dan AT ncct.uottawa.ca}\\ 
\email{rtropper AT ncct.uottawa.ca}
}

%\input{referenc}

\bibliographystyle{spmpsci}  % Use the "unsrtnat" BibTeX style for formatting the Bibliography, amsplain would do it by author name
\bibliography{Bibliography} %keeping dupe until can clear up escape character support in other one... gives flexibility to fix hboxes too

%\bibliography{../../ThesisClean/Bibliography}  % The references (bibliography) information are stored in the file named "Bibliography.bib"


\end{article}
