| element per point. A very large number of
-points will almost certainly lead to excessive browser memory usage, so
-this technique is unlikely to scale well at the high end. However, it
-may still be useful for smaller data sets that require interactive
-manipulation.
-
-
-\begin{figure}
- \begin{center}
- \includegraphics[scale=1.25]{jpeg_detail}\medskip
-
- \includegraphics[scale=1.25]{overlay_detail}
- \end{center}
- \caption{Image quality of JPEG image generation (top) vs.\ HTML
- overlay (bottom).}
- \label{fig-image-quality}
-\end{figure}
-
-
-\subsection{Google Maps}
-\label{sec-google}
-
-This technique uses the client-side Google Maps API
-\cite{Goog-M-2006-maps} to both generate the base map and plot points on
-it; an example of the output is shown in Figure~\ref{fig-google}. The
-output and interaction is significantly different in nature and
-appearance from that provided by the other two techniques. Google Maps
-requires JavaScript support at the client and the Google Maps software
-must be installed on the client. However, since the latter happens
-automatically when the corresponding web page is loaded, this technique
-meets our requirements. Google Maps inherently uses a shared environment
-architecture, as shown in Figure~\ref{fig-google-architecture}. Data are
-generated at the server, while all map display and manipulation occurs
-at the client.
+An HTML overlay comprises a collection of HTML elements corresponding to
+the points to be plotted, which are positioned over the base map image
+using CSS absolute positioning. There is considerable flexibility as to
+which elements could be used to construct the overlay. One possibility
+is to use \verb|![]()
| elements, which is the approach adopted by Google
+Maps (see Figure~\ref{fig-google}). Another possibility is to use
+appropriately sized and colored \verb|
| elements, which will then
+appear as colored points ``floating'' over the base map image (the
+output looks essentially identical to that shown in
+Figure~\ref{fig-image}).
\begin{figure}
@@ -511,12 +459,32 @@
\end{figure}
-\begin{figure}
- \caption{Shared environment architecture of the Google Maps
- technique.}
- \label{fig-google-architecture}
-\end{figure}
+HTML overlays may be generated at either the server or the client.
+Unlike the techniques discussed previously, however, HTML overlays can
+be generated at the client without the need for additional software,
+because only HTML (i.e., text) is being generated. This can be easily
+achieved using client-side JavaScript, so HTML overlays can use any of
+the distribution styles discussed in Section~\ref{sec-distribution}
+without violating our requirements. We have therefore adopted two
+representative overlay techniques for our experiments: server-side HTML
+overlays (using the image server distribution style) and Google Maps
+(using the shared environment distribution style). Since Google Maps
+uses embedded \verb|![]()
| elements, we have used embedded \verb|
|
+elements for the our server-side HTML overlays.
+Server-side HTML overlays are actually slightly easier to implement than
+either server-side image generation or image overlays, because we do not
+need any code to generate or manipulate images (the base map image is
+static and thus requires no additional processing). All that is required
+is code to transform latitude/longitude coordinates into projected map
+coordinates and produce corresponding \verb|
| elements.
+
+Google Maps \cite{Goog-M-2006-maps} is a more complex proposition. This
+technique uses the shared environment distribution style, where
+JavaScript code running within the browser enables the client to control
+the display of the base map and any overlays. Data and map images are
+requested asynchronously from the server as required, using Ajax
+technologies.
The primary advantage of Google Maps is the powerful functionality it
provides for generating and interacting with the map. Users may pan the
@@ -526,24 +494,34 @@
example) can be displayed in a callout next to the point, as shown in
Figure~\ref{fig-google}.
-However, there are also some significant disadvantages compared to the
-previous two techniques. As a distributed application, it will be more
-complex to implement, test and debug. It also relies on an active
-Internet connection in order to run. The server must have a registered
-API key from Google, which is verified every time that a page attempts
-to use the API. Similarly, the client must connect to Google's servers
-in order to to download the API's JavaScript source. Finally, the Google
-Maps API does not currently provide any technique of toggling the
-visibility of markers on the map, so it is not possible to implement the
-``layers'' that are possible with HTML overlay (it is of course possible
-that Google will implement this feature in a later version of the API).
+However, there are also some significant disadvantages to the Google
+Maps technique\footnote{Interestingly, the Google Earth application
+addresses many of these issues, but since it is not a browser-based
+solution it falls outside the scope of this work. However, for
+interest's sake we will do an informal comparison in
+Section~\ref{sec-results} between Google Earth and the four techniques
+that we have tested.}. First, it is a distributed application, thus
+making it more complex to implement, test and debug [REF]. Second, the
+server must have a registered API key from Google, which is verified
+every time that a page attempts to use the API. Similarly, the client
+must connect to Google's servers in order to to download the API's
+JavaScript source. This means that the technique must have an active
+Internet connection in order to work. Finally, the Google Maps API does
+not currently provide any technique of toggling the visibility of
+markers on the map, so it is not possible to implement the interactive
+``layers'' that are possible with an HTML overlay. (It is possible, of
+course, that Google will implement this feature in a later version of
+the API.)
-Interestingly, the Google Earth application addresses several of these
-issues, but falls outside the scope of this work, as it requires the
-manual installation of extra software and runs outside the web browser
-entirely. (Just for fun, however, we will do an informal comparison in
-Section~\ref{sec-results} between Google Earth and the three techniques
-discussed here.)
+The most significant disadvantage of all HTML overlay techniques,
+however, is that the size of the HTML overlay is directly proportional
+to the number of points to be plotted. There will be one overlay element
+(\verb|
| or \verb|![]()
|) per point, so a very large number of
+points will result in an even larger amount of HTML source being
+generated. We expect that this will lead to excessive browser memory
+usage, and consequently that these techniques will not scale well at the
+high end. However, they may still be useful for smaller data sets that
+require interactive manipulation.
\section{Experimental design}