| | \documentclass[acmtocl,acmnow]{acmtrans2m} |
---|
| | \documentclass[acmnow]{acmtrans2m} |
---|
| | |
---|
| | |
---|
| | \usepackage{graphicx} |
---|
| | |
---|
| |
---|
| | \category{H.3.5}{Information Storage and Retrieval}{Online Information Services}[web-based services] |
---|
| | |
---|
| | \terms{Experimentation, Measurement, Performance} |
---|
| | |
---|
| | \keywords{geolocation, geovisualization, scalability, GD, Google Maps} |
---|
| | \keywords{downloads, geolocation, geovisualization, scalability, Google |
---|
| | Maps, distribution style, dynamic map generation} |
---|
| | |
---|
| | \begin{document} |
---|
| | |
---|
| | |
---|
| |
---|
| | \cite{Stan-N-2006-running}, using the GNU |
---|
| | EPrints\footnote{\url{http://www.eprints.org/}} repository management |
---|
| | software. This repository quickly attracted interest from around the |
---|
| | world and the number of abstract views and document downloads began to |
---|
| | steadily increase. We were obviously very interested in tracking this |
---|
| | increase, particularly with respect to where in the world the hits were |
---|
| | coming from. The EPrints statistics management software developed at the |
---|
| | steadily increase. We were very interested in tracking this increase, |
---|
| | particularly with respect to where in the world the hits were coming |
---|
| | from. The EPrints statistics management software developed at the |
---|
| | University of Tasmania \cite{Sale-A-2006-stats} proved very useful in |
---|
| | this regard, providing us with detailed per-eprint and per-country |
---|
| | download statistics; an example of the latter is shown in |
---|
| | Figure~\ref{fig-tas-stats}. However, while this display provides an |
---|
| |
---|
| | city level for the US within a 25 mile radius'' |
---|
| | \cite{Maxm-G-2006-GeoLiteCity}. Their commercial \emph{GeoIP City} |
---|
| | database claims 80\% accuracy for the same parameters. |
---|
| | |
---|
| | The techniques used by these systems can generally be divided into two |
---|
| | classes. The first class of techniques generate a single bitmap image |
---|
| | that contains both the map and the icons representing web hits. This can |
---|
| | be achieved by programmatically plotting points onto a base map image; |
---|
| | the composite image is then displayed at the client. We shall henceforth |
---|
| | refer to this class of techniques as \emph{single layer} techniques. |
---|
| | The second class of techniques separately return both a base map image |
---|
| | and some kind of overlay containing the plotted points. The overlay is |
---|
| | then combined with the base map at the client. We shall henceforth refer |
---|
| | to this class of techniques as \emph{multi-layer} techniques. |
---|
| | The techniques used by these prior systems can generally be divided into |
---|
| | two classes. The first class of techniques generate a single bitmap |
---|
| | image that contains both the map and the graphics representing web hits. |
---|
| | This can be achieved by programmatically plotting points onto a base map |
---|
| | image; the composite image is then displayed at the client. We shall |
---|
| | henceforth refer to this class of techniques as \emph{single-layer} |
---|
| | techniques. The second class of techniques separately return both a base |
---|
| | map image and some kind of overlay containing the plotted points. The |
---|
| | overlay and the base map are then displayed as separate items at the |
---|
| | client. We shall henceforth refer to this class of techniques as |
---|
| | \emph{multi-layer} techniques. |
---|
| | |
---|
| | Both classes of techniques have been used in the aforementioned systems, |
---|
| | but multi-layer techniques appear to have been particularly popular. For |
---|
| | example, Palantir used a multi-layer technique, where a Java applet running |
---|
| |
---|
| | dynamic multi-layer technique that has only become feasible relatively |
---|
| | recently with the advent of widespread support for CSS positioning and |
---|
| | Ajax technologies in many browsers. |
---|
| | |
---|
| | Multi-layer techniques enjoy a particular advantage over single layer |
---|
| | Multi-layer techniques enjoy a particular advantage over single-layer |
---|
| | techniques, in that they provide the potential for a more flexible |
---|
| | GIS-like interaction with the map, with multiple layers that can be |
---|
| | activated and deactivated as desired. This flexibility could explain why |
---|
| | such techniques appear more prevalent in the literature. However, |
---|
| | multi-layer techniques tend to rely on more recent web technologies such as |
---|
| | CSS2 and Ajax, whereas single layer techniques generally do not. Single |
---|
| | layer techniques should therefore be portable to a wider range of client |
---|
| | and server environments. |
---|
| | |
---|
| | Each technique comprises a specific technology or collection of |
---|
| | technologies (such as transparent bitmap overlays), implemented using a |
---|
| | specific distribution style. For example, one single layer technique |
---|
| | might be implemented completely server-side while another might use a |
---|
| | mixture of server-side and client-side processing. Similarly, multi-layer |
---|
| | such techniques appear more prevalent in the literature. As we shall see |
---|
| | shortly, however, web-based multi-layer techniques tend to rely on more |
---|
| | recent web technologies such as CSS and Ajax, whereas single-layer |
---|
| | techniques generally do not. Single-layer techniques should therefore be |
---|
| | portable to a wider range of client and server environments. |
---|
| | |
---|
| | Each map generation and display technique comprises a specific |
---|
| | technology or collection of technologies (such as transparent bitmap |
---|
| | overlays + CSS positioning), implemented using a specific distribution |
---|
| | style. For example, a particular single-layer technique might be |
---|
| | implemented completely server-side while another might use a mixture of |
---|
| | server-side and client-side processing. Similarly, multi-layer |
---|
| | techniques may adopt different distribution styles, and the overlays |
---|
| | themselves might take the form of transparent images, absolutely |
---|
| | positioned HTML elements, dynamically generated graphics, etc. |
---|
| | |
---|
| | Given the many possible techniques that were available, the next |
---|
| | question was which techniques would be most suitable for our purposes? |
---|
| | Scalability is a key issue for web applications in general \cite[p.\ |
---|
| | 28]{Offu-J-2002-quality}, and online activity visualization in |
---|
| | Given the wide variety of possible techniques that were available, the |
---|
| | next question was which techniques would be most suitable for our |
---|
| | purposes? Scalability is a key issue for web applications in general |
---|
| | \cite[p.\ 28]{Offu-J-2002-quality}, and online activity visualization in |
---|
| | particular \cite[p.\ 50]{Eick-SG-2001-sitevis}, so we were particularly |
---|
| | interested in techniques that could scale to a large number of points. |
---|
| | For example, at the time of writing the Otago EPrints repository had |
---|
| | been accessed from over 10,000 distinct IP addresses, each potentially |
---|
| | representing a distinct geographical location. Separating out the type |
---|
| | of hit (abstract view versus document download) increased that figure to |
---|
| | nearly 13,000. |
---|
| | nearly 13,000. Early informal experiments with these data indicated that |
---|
| | a single-layer composite map image would work quite well, whereas Google |
---|
| | Maps would not. |
---|
| | |
---|
| | We first narrowed down the range of techniques to just four (server-side |
---|
| | image generation, server-side image overlay, server-side HTML overlay |
---|
| | and Google Maps); the selection process and details of the techniques |
---|
| |
---|
| | experiments was conducted on each technique with progressively larger |
---|
| | data sets, and the elapsed time and memory usage were measured. The |
---|
| | experimental design is discussed in Section~\ref{sec-experiment}. |
---|
| | |
---|
| | Our initial intuition was that server-side image generation and |
---|
| | Our initial intuition was that the server-side image generation and |
---|
| | server-side image overlay techniques would scale best, and this was |
---|
| | borne out by the results of the experiments, which show that both |
---|
| | techniques scale reasonably well to very large numbers of points. The |
---|
| | other two techniques proved to be reasonable for relatively small |
---|
| |
---|
| | performance deteriorated rapidly beyond this. The results are discussed |
---|
| | in more detail in Section~\ref{sec-results}. |
---|
| | |
---|
| | It should be noted that the intent of the experiments was not to |
---|
| | identify statistically significant differences between techniques. It |
---|
| | was expected that variations across techniques would be obvious, and the |
---|
| | experiments were designed to test this expectation. However, the two |
---|
| | best performing techniques, server-side image generation and server-side |
---|
| | image overlay, produced very similar results, so a more formal |
---|
| | statistical analysis of these techniques may be warranted. This and |
---|
| | other possible future directions are discussed in |
---|
| | Section~\ref{sec-future}. |
---|
| | identify statistically significant differences in performance across the |
---|
| | four techniques. It was expected that variations across techniques would |
---|
| | be reasonably clear-cut, and the experiments were designed to test this |
---|
| | expectation. However, the two best performing techniques, server-side |
---|
| | image generation and server-side image overlay, produced very similar |
---|
| | results, so a more formal statistical analysis of these techniques may |
---|
| | be warranted. This and other possible future directions are discussed in |
---|
| | Section~\ref{sec-conclusion}. |
---|
| | |
---|
| | |
---|
| | \section{Technique selection} |
---|
| | \label{sec-techniques} |
---|
| |
---|
| | \emph{data server} style is where the server only supplies raw data, and |
---|
| | all manipulation, display and analysis takes place at the client. In |
---|
| | other words, this is primarily a client-side processing model, as |
---|
| | illustrated in Figure~\ref{fig-distribution-styles}(a). For example, |
---|
| | Palantir implemented a multi-layer technique using this distribution style |
---|
| | \cite{Papa-N-1998-Palantir}, where the source data were generated at the |
---|
| | server and the map was generated, displayed and manipulated by a Java |
---|
| | applet running at the client. The data server distribution style can |
---|
| | provide a very dynamic and interactive environment to the end user, but |
---|
| | clearly requires support for executing application code within the web |
---|
| | browser, typically using something like JavaScript, Java applets or |
---|
| | Palantir implemented a multi-layer technique using this distribution |
---|
| | style \cite{Papa-N-1998-Palantir}, where the source data were generated |
---|
| | at the server and the map was generated, displayed and manipulated by a |
---|
| | Java applet running at the client. The data server distribution style |
---|
| | can provide a very dynamic and interactive environment to the end user, |
---|
| | but clearly requires support for executing application code within the |
---|
| | web browser, typically using something like JavaScript, Java applets or |
---|
| | Flash. JavaScript is now tightly integrated into most browsers, but the |
---|
| | same cannot be said for either Java or Flash. That is, we cannot |
---|
| | necessarily guarantee the existence of a Java virtual machine or Flash |
---|
| | plugin in every browser, which violates our requirement to avoid manual |
---|
| | installation of additional client-side software. We can therefore |
---|
| | eliminate Java- or Flash-based data server techniques from |
---|
| | consideration, but JavaScript-based data server techniques may still be |
---|
| | feasible. |
---|
| | consideration, but JavaScript-based data server techniques are feasible. |
---|
| | Indeed, as we will see in Section~\ref{sec-overlay}, Google Maps is an |
---|
| | example of such a technique. |
---|
| | |
---|
| | |
---|
| | \begin{figure} |
---|
| | \centering |
---|
| | \begin{tabular}{ccc} |
---|
| | \includegraphics[scale=1]{data_server} & |
---|
| | \includegraphics[scale=0.9]{data_server} & |
---|
| | \qquad & |
---|
| | \includegraphics[scale=1]{image_server} \\ |
---|
| | \includegraphics[scale=0.9]{image_server} \\ |
---|
| | \footnotesize (a) Data server & |
---|
| | \qquad & |
---|
| | \footnotesize (b) Image server \\ |
---|
| | \\ |
---|
| | \\ |
---|
| | \includegraphics[scale=1]{model_interaction} & |
---|
| | \includegraphics[scale=0.9]{model_interaction} & |
---|
| | \qquad & |
---|
| | \includegraphics[scale=1]{shared} \\ |
---|
| | \includegraphics[scale=0.9]{shared} \\ |
---|
| | \footnotesize (c) Model interaction environment & |
---|
| | \qquad & |
---|
| | \footnotesize (d) Shared environment \\ |
---|
| | \end{tabular} |
---|
| |
---|
| | illustrated in Figure~\ref{fig-distribution-styles}(b). Consequently, |
---|
| | techniques that use this style require no additional client-side |
---|
| | software, and thus meet our requirements. The downside is that the |
---|
| | resultant visualization can tend to be very static and non-interactive |
---|
| | in nature, as it is just a simple bitmap image. |
---|
| | in nature, as it is typically just a simple bitmap image. |
---|
| | |
---|
| | The \emph{model interaction environment} style is where a model created |
---|
| | at the server can be explored at the client, as illustrated in |
---|
| | Figure~\ref{fig-distribution-styles}(c). \citeN{Wood-J-1996-vis} |
---|
| |
---|
| | interaction between the client and server after the model has been |
---|
| | downloaded. This means that while the downloaded model can be very |
---|
| | dynamic and interactive, changing the underlying data requires a new |
---|
| | model to be generated at the server and downloaded to the client. |
---|
| | Similar restrictions apply to techniques using this style as to the |
---|
| | data server style, so Java- and Flash-based model interaction |
---|
| | environment techniques can be eliminated from consideration. For similar |
---|
| | reasons, we can also eliminate solutions that require browser plugins |
---|
| | such as VRML or SVG (although native support for the latter is beginning |
---|
| | to appear in some browsers). It may be possible to implement this |
---|
| | distribution style using only client-side JavaScript, but it is presently |
---|
| | unclear as to how effective this might be. |
---|
| | |
---|
| | % future work: implement model interaction using JavaScript? |
---|
| | Similar restrictions apply to techniques using this style as to the data |
---|
| | server style, so Java- and Flash-based model interaction environment |
---|
| | techniques can be eliminated from consideration. For similar reasons, we |
---|
| | can also eliminate solutions such as VRML or SVG that require external |
---|
| | browser plugins (although native support for SVG is beginning to appear |
---|
| | in some browsers). It may be possible to implement this distribution |
---|
| | style using only client-side JavaScript, but it is presently unclear as |
---|
| | to how effective this might be. |
---|
| | |
---|
| | Finally, the \emph{shared environment} style is where data manipulation |
---|
| | is done at the server, but control of that manipulation, rendering, and |
---|
| | display all occur at the client, as illustrated in |
---|
| |
---|
| | interaction environment style, but with the addition of a feedback loop |
---|
| | from the client to the server, thus enabling a more flexible and dynamic |
---|
| | interaction. Ajax technologies \cite{Garr-JJ-2005-Ajax} can easily |
---|
| | support this kind of distribution style. For example, |
---|
| | \citeN{Saya-A-2006-GISWS} discuss the use of Ajax to integrate Google |
---|
| | Maps with existing GIS visualization web services. We can eliminate |
---|
| | \citeN{Saya-A-2006-GISWS} use Ajax to integrate Google Maps with |
---|
| | existing GIS visualization web services. We can eliminate specific |
---|
| | shared environment techniques from consideration based on the same |
---|
| | criteria as were applied to the other three styles. |
---|
| | |
---|
| | |
---|
| | \subsection{Single layer techniques} |
---|
| | criteria as were applied to the other three styles (e.g., no Java- or |
---|
| | Flash-based techniques). |
---|
| | |
---|
| | |
---|
| | \subsection{Single-layer techniques} |
---|
| | \label{sec-image-gen} |
---|
| | |
---|
| | As noted earlier, single layer techniques work by directly plotting |
---|
| | As noted earlier, single-layer techniques work by directly plotting |
---|
| | geolocated IP addresses onto a base map image, then displaying the |
---|
| | composite image at the client. A typical example of the kind of output |
---|
| | that might be produced is shown in Figure~\ref{fig-image}. Such |
---|
| | techniques require two specific components: software to programmatically |
---|
| | create and manipulate bitmap images (for example, the GD image |
---|
| | library\footnote{\url{http://www.boutell.com/gd/}}); and software to |
---|
| | transform raw latitude/longitude coordinates into projected map |
---|
| | coordinates on the base map (for example, the PROJ.4 cartographic |
---|
| | projections library\footnote{\url{http://www.remotesensing.org/proj/}}). |
---|
| | |
---|
| | |
---|
| | \begin{figure} |
---|
| | \centering |
---|
| | \includegraphics[width=0.95\textwidth,keepaspectratio]{ImageGeneration-full} |
---|
| | \caption{Sample output from the server-side image generation technique.} |
---|
| | transform latitude/longitude coordinates into projected map coordinates |
---|
| | on the base map (for example, the PROJ.4 cartographic projections |
---|
| | library\footnote{\url{http://www.remotesensing.org/proj/}}). |
---|
| | |
---|
| | |
---|
| | \begin{figure} |
---|
| | \centering |
---|
| | \includegraphics[width=0.9\textwidth,keepaspectratio]{ImageGeneration-full} |
---|
| | \caption{Sample output from the (single-layer) server-side image |
---|
| | generation technique.} |
---|
| | \label{fig-image} |
---|
| | \end{figure} |
---|
| | |
---|
| | |
---|
| | Single layer techniques could use any of the distribution styles |
---|
| | Single-layer techniques could use any of the distribution styles |
---|
| | discussed in Section~\ref{sec-distribution}. However, all but the image |
---|
| | server style would require the installation of additional client-side |
---|
| | software for generating images and performing cartographic projection |
---|
| | operations, so we will only consider single layer using the image |
---|
| | server distribution style (or \textbf{server-side image generation}) |
---|
| | from this point on. |
---|
| | operations, so we will only consider single-layer techniques that use |
---|
| | the image server distribution style (or \textbf{server-side image |
---|
| | generation}). |
---|
| | |
---|
| | The server-side image generation technique provides some distinct |
---|
| | advantages. It is relatively simple to implement and is fast at |
---|
| | producing the final image, mainly because it uses existing, |
---|
| | well-established technologies. It is also bandwidth efficient: the size |
---|
| | of the generated map image is determined by the total number of pixels |
---|
| | and the compression method used, rather than by the number of points to |
---|
| | be plotted. The amount of data to be sent to the client should therefore |
---|
| | remain more or less constant, regardless of the number of points |
---|
| | plotted. |
---|
| | well-established technologies. It is also bandwidth efficient, because |
---|
| | the size of the generated map image is determined by its pixel |
---|
| | dimensions and the compression method used, rather than by the number of |
---|
| | points to be plotted. The amount of data to be sent to the client should |
---|
| | therefore remain more or less constant, regardless of the number of |
---|
| | points plotted. |
---|
| | |
---|
| | This technique also has some disadvantages, however. First, a suitable |
---|
| | base map image must be acquired. This could be generated from a GIS, but |
---|
| | if this is not an option an appropriate image must be obtained from a |
---|
| | third party. Care must be taken in the latter case to avoid potential |
---|
| | copyright issues. Second, the compression method used to produce the |
---|
| | final composite map image can have a significant impact on visual |
---|
| | quality. For example, lossy compression methods such as JPEG can make |
---|
| | the points plotted on the map appear distinctly fuzzy or ``muddy'', as |
---|
| | shown in Figure~\ref{fig-image-quality}. A lossless compression method |
---|
| | such as PNG will avoid this problem, but will tend to produce larger |
---|
| | image files. Finally, it is harder to provide interactive map |
---|
| | manipulation features with this technique, as the output is a simple |
---|
| | static image. Anything that changes the content of the map (such as |
---|
| | panning or changing the visibility of points) will require the entire |
---|
| | image to be regenerated. Zooming could be achieved if a very high |
---|
| | resolution base map image was available, but the number of possible zoom |
---|
| | levels might be restricted. |
---|
| | |
---|
| | |
---|
| | \begin{figure} |
---|
| | \centering |
---|
| | \includegraphics[scale=1.25]{jpeg_detail}\medskip |
---|
| | |
---|
| | \includegraphics[scale=1.25]{overlay_detail} |
---|
| | \caption{Image quality of JPEG (Q=90) image generation (top) vs.\ |
---|
| | PNG image overlay (bottom).} |
---|
| | third party. Care must be taken in the latter case to avoid copyright |
---|
| | issues. Second, the compression method used to produce the final |
---|
| | composite map image can have a significant impact on visual quality. For |
---|
| | example, lossy compression methods such as JPEG can make the points |
---|
| | plotted on the map appear distinctly fuzzy or ``muddy'', as shown in |
---|
| | Figure~\ref{fig-image-quality}. Lossless compression methods such as PNG |
---|
| | avoid this problem, but may produce larger files for the same image. |
---|
| | Finally, it is harder to provide interactive map manipulation features |
---|
| | with this technique, as the output is a simple static image. Anything |
---|
| | that changes the content of the map (such as panning or changing the |
---|
| | visibility of certain points) will require the entire image to be |
---|
| | regenerated. Zooming could be achieved if a very high resolution base |
---|
| | map image was available, but the number of possible zoom levels might be |
---|
| | restricted. |
---|
| | |
---|
| | |
---|
| | \begin{figure} |
---|
| | \centering |
---|
| | \includegraphics[scale=0.98]{jpeg_detail} |
---|
| | \includegraphics[scale=0.98]{overlay_detail} |
---|
| | \caption{Image quality of JPEG (Q=90) image generation (left) vs.\ |
---|
| | PNG image overlay (right).} |
---|
| | \label{fig-image-quality} |
---|
| | \end{figure} |
---|
| | |
---|
| | |
---|
| | \subsection{Multi-layer techniques} |
---|
| | \label{sec-overlay} |
---|
| | |
---|
| | % Look for publications regarding the DataCrossing Ajax client. |
---|
| | % See <http://datacrossing.crs4.it/en_Documentation_Overlay_Example.html>. |
---|
| | % They use <IMG> rather than <DIV>, which has the advantage of the image |
---|
| | % being loaded only once, but makes it harder to dynamically change the |
---|
| | % appearance of markers. The amount of data generated will still be |
---|
| | % proportional to the number of points (one <IMG> per point). |
---|
| | |
---|
| | Multi-layer techniques also involve plotting points onto a base map image, |
---|
| | but they differ from single layer techniques in that the points are |
---|
| | not composited directly onto the base map image. Rather, the points are |
---|
| | Multi-layer techniques also involve plotting points onto a base map |
---|
| | image, but they differ from single-layer techniques in that the points |
---|
| | are not plotted directly onto the base map image. Rather, the points are |
---|
| | displayed as an independent overlay on top of the base map image. This |
---|
| | provides a significant advantage over single layer techniques, as it |
---|
| | provides a significant advantage over single-layer techniques, as it |
---|
| | enables the possibility of multiple independent layers that can be |
---|
| | individually shown or hidden. This is very similar to the multi-layer |
---|
| | functionality provide by GIS, and is an effective way to provided |
---|
| | functionality provided by GIS, and is an effective way to provide |
---|
| | interactive visualizations of geographic data |
---|
| | \cite{Wood-J-1996-vis,MacE-AM-1998-GIS}. We still have the problem of |
---|
| | finding a suitable base map image, however. |
---|
| | |
---|
| |
---|
| | points are plotted, which is then overlaid on the base map image (in our |
---|
| | implementation, the output looks essentially identical to that shown in |
---|
| | Figure~\ref{fig-image} on page~\pageref{fig-image}). This requires the |
---|
| | overlay image to be in either PNG or GIF format, as JPEG does not |
---|
| | support transparency. Fortunately the overlay image is likely to contain |
---|
| | a lot of ``white space'', which compresses very well, so use of a |
---|
| | support transparency. The overlay image is likely to contain |
---|
| | considerable ``white space'', which compresses very well, so use of a |
---|
| | lossless compression method should not be an issue. This also eliminates |
---|
| | the ``fuzziness'' issue noted earlier (see |
---|
| | Figure~\ref{fig-image-quality}). The size of the image overlay will |
---|
| | generally be proportional to the number of points to be plotted, but the |
---|
| | image compression should have a moderating effect on this. |
---|
| | |
---|
| | As noted earlier, generating images at the client would require |
---|
| | additional software to be installed, so we will only consider the data |
---|
| | server distribution style for image overlays (or \textbf{server-side |
---|
| | image overlay}). That is, both the base map image and the overlay(s) are |
---|
| | generated at the server. |
---|
| | As noted in Section~\ref{sec-image-gen}, generating images at the client |
---|
| | would require additional software to be installed, so we will only |
---|
| | consider the data server distribution style for image overlays (or |
---|
| | \textbf{server-side image overlay}). That is, both the base map image |
---|
| | and the overlay(s) are generated at the server. |
---|
| | |
---|
| | 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 |
---|
| | the types of elements that could be used to construct the overlay. One |
---|
| | possibility is to use \verb|<IMG>| elements to place icons on the base |
---|
| | map; this appears to be the approach adopted by Google Maps (see |
---|
| | map, which appears to be the approach adopted by Google Maps (see |
---|
| | Figure~\ref{fig-google}). Another possibility is to use appropriately |
---|
| | sized and colored \verb|<DIV>| elements, which then appear as colored |
---|
| | blocks ``floating'' over the base map image (in our implementation, the |
---|
| | output looks essentially identical to that shown in |
---|
| |
---|
| | |
---|
| | |
---|
| | \begin{figure} |
---|
| | \centering |
---|
| | \includegraphics[width=0.95\textwidth,keepaspectratio]{GoogleMap-full.png} |
---|
| | \includegraphics[width=0.9\textwidth,keepaspectratio]{GoogleMap-full.png} |
---|
| | \caption{Sample output from the Google Maps technique.} |
---|
| | \label{fig-google} |
---|
| | \end{figure} |
---|
| | |
---|
| |
---|
| | because only HTML (i.e., text) is being generated, not images. 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 multi-layer techniques for our |
---|
| | experiments: \textbf{server-side HTML overlays} (using the image server |
---|
| | distribution style) and \textbf{Google Maps} (using the data server |
---|
| | distribution style). Since Google Maps uses \verb|<IMG>| elements, we |
---|
| | have used \verb|<DIV>| elements for the server-side HTML overlay. |
---|
| | have therefore adopted two representative HTML overlay techniques for |
---|
| | our experiments: \textbf{server-side HTML overlays} (using the image |
---|
| | server distribution style) and \textbf{Google Maps} (using the data |
---|
| | server distribution style). Since Google Maps uses \verb|<IMG>| |
---|
| | elements, we have used \verb|<DIV>| elements for the server-side HTML |
---|
| | overlay. |
---|
| | |
---|
| | Server-side HTML overlays are actually slightly simpler to implement |
---|
| | than either server-side image generation or image overlays, because we |
---|
| | do not need to write 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|<DIV>| |
---|
| | into projected map coordinates and generate corresponding \verb|<DIV>| |
---|
| | elements. |
---|
| | |
---|
| | Google Maps \cite{Goog-M-2006-maps} is a more complex proposition. This |
---|
| | technique uses the data server distribution style, where JavaScript code |
---|
| | running within the browser enables the client to manipulate the base map |
---|
| | and its overlays. Data and map images are requested asynchronously from |
---|
| | the server as required, using Ajax technologies, which seems to imply |
---|
| | the server as required using Ajax technologies, which seems to imply |
---|
| | that Google Maps in fact uses the shared environment distribution style. |
---|
| | However, the server has no involvement beyond simply supplying data to |
---|
| | the client. In the shared environment distribution style, the server is |
---|
| | directly involved in manipulating the map, under the control of the |
---|
| | client. This is clearly not the case with Google Maps. |
---|
| | |
---|
| | The primary advantage of Google Maps is the powerful functionality it |
---|
| | provides for generating and interacting with the map. Users may pan the |
---|
| | map in any direction and zoom in and out to many different levels. A |
---|
| | map in any direction and zoom to many different levels of detail. A |
---|
| | satellite imagery view is also available. In addition, further |
---|
| | information about each point plotted (such as the name of the city, for |
---|
| | example) can be displayed in a callout attached to the point, as shown |
---|
| | in Figure~\ref{fig-google}. |
---|
| | information about each point plotted (such as the name of the city) can |
---|
| | be displayed in a callout attached to the point, as shown in |
---|
| | Figure~\ref{fig-google}. |
---|
| | |
---|
| | 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 our consideration. However, for |
---|
| | interest's sake we did an informal comparison between Google Earth and |
---|
| | the four techniques that we have tested, and this has been included in |
---|
| | the results in Section~\ref{sec-results}.}. First, it is a distributed |
---|
| | application, thus making it more complex to implement, test and debug |
---|
| | \cite{Bates-PC-1995-distdebug,Ensl-PH-1978-distributed}. 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 way to toggle the visibility of markers on the |
---|
| | map, so it is not possible to implement the interactive ``layers'' |
---|
| | mentioned at the start of this section. (It is possible, of course, that |
---|
| | Google will implement this feature in a later version of the API.) |
---|
| | solution it falls outside the scope of our consideration.}. First, it is |
---|
| | a distributed application, thus making it more complex to implement, |
---|
| | test and debug \cite{Bates-PC-1995-distdebug,Ensl-PH-1978-distributed}. |
---|
| | 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 requires an |
---|
| | active Internet connection in order to work. Finally, the Google Maps |
---|
| | API does not currently provide any way to toggle the visibility of |
---|
| | markers on the map, so it is not possible to implement the interactive |
---|
| | ``layers'' mentioned at the start of this section. (It is possible, of |
---|
| | course, that Google may implement this feature in a future version of |
---|
| | the API.) |
---|
| | |
---|
| | 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|<DIV>| or \verb|<IMG>|) 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. |
---|
| | high end. However, they may still be appropriate for smaller data sets |
---|
| | that require interactive manipulation. |
---|
| | |
---|
| | |
---|
| | \section{Experimental design} |
---|
| | \label{sec-experiment} |
---|
| |
---|
| | |
---|
| | |
---|
| | \begin{figure} |
---|
| | \centering |
---|
| | \includegraphics[width=0.95\textwidth,keepaspectratio]{16384_points} |
---|
| | \includegraphics[width=0.9\textwidth,keepaspectratio]{16384_points} |
---|
| | \caption{The 16,384-point data set plotted on the base map.} |
---|
| | \label{fig-grid-points} |
---|
| | \end{figure} |
---|
| | |
---|
| |
---|
| | the local network was a potential confounding factor. We therefore |
---|
| | decided to eliminate network performance from the equation by running |
---|
| | both the server and the client on the same machine\footnote{A Power |
---|
| | Macintosh G5 1.8\,GHz with 1\,GB RAM, running Mac OS X 10.4.7, Apache |
---|
| | 2.0.55, PHP 4.4 and Perl 5.8.6.}. This in turn enabled us to measure the |
---|
| | time taken for data generation and page display independently, thus |
---|
| | simplifying the process of data collection and also ensuring that the |
---|
| | client and server processes did not unduly interfere with each other, |
---|
| | despite running on the same machine. |
---|
| | 2.0.55, PHP 4.4 and Perl 5.8.6.}. This in turn enabled us to |
---|
| | independently measure the time taken for data generation and page |
---|
| | display, thus simplifying the process of data collection and also |
---|
| | ensuring that the client and server processes did not unduly interfere |
---|
| | with each other, despite running on the same machine. |
---|
| | |
---|
| | It could be argued that network performance would still have a |
---|
| | confounding effect on the Google Maps technique, but this would only be |
---|
| | likely for the initial download of the API (comprising about 235\,kB of |
---|
| |
---|
| | server from proceeding. |
---|
| | |
---|
| | For each data set generated, we recorded its size, the time taken to |
---|
| | generate it, the time taken to display the resultant map in the browser, |
---|
| | and the amount of real and virtual memory used during the test by the |
---|
| | browser. We also intended to measure the memory usage of the server, but |
---|
| | and the amount of real and virtual memory used by the browser during the |
---|
| | test. We also intended to measure the memory usage of the server, but |
---|
| | this proved more difficult to isolate than expected, and was thus |
---|
| | dropped from the experiments. The data set generation time and browser |
---|
| | memory usage were measured using the \texttt{time} and \texttt{top} |
---|
| | utilities respectively (the latter was run after each test run to avoid |
---|
| |
---|
| | test'' debugging feature of Apple's Safari web browser, which can |
---|
| | repetitively load a set of pages while recording various statistics, in |
---|
| | particular the time taken to load the page. Tests were run up to twenty |
---|
| | times each where feasible, in order to reduce the impact of random |
---|
| | variations. Some tests were run fewer times because they took a very |
---|
| | long time (several minutes for a single test run). We typically broke |
---|
| | off further testing when a single test run took longer than about five |
---|
| | minutes, as by this stage performance had already deteriorated well |
---|
| | beyond usable levels. |
---|
| | |
---|
| | While it is somewhat beyond the scope of this work, out of interest some |
---|
| | informal tests were also undertaken using the Google Earth application. |
---|
| | A Perl script was used to generate a collection of KML files |
---|
| | corresponding to the data sets described above. Each data set was then |
---|
| | loaded into Google Earth, and a stopwatch was used to measure how long |
---|
| | it took to load the data set, defined as the period during which the |
---|
| | dialog box ``\textsf{Loading myplaces.kml, including enabled overlays}'' |
---|
| | was displayed on screen. |
---|
| | variations. Some tests were run fewer times because they took an |
---|
| | excessive amount of time to complete (i.e., several minutes for a single |
---|
| | test run). We typically broke off further testing when a single test run |
---|
| | took longer than about five minutes, as by this stage performance had |
---|
| | already deteriorated well beyond usable levels. |
---|
| | |
---|
| | |
---|
| | \subsection{Technique implementation} |
---|
| | |
---|
| |
---|
| | \begin{description} |
---|
| | |
---|
| | \item[server-side image generation] The dispatcher page included a |
---|
| | standard \verb|<IMG>| element that called the Perl script. This |
---|
| | script then loaded a base map PNG image, plotted points directly |
---|
| | onto it, and returned the |
---|
| | composite map to the client as a JPEG image (with the ``quality'' |
---|
| | parameter set to 90). |
---|
| | script loaded a base map PNG image, plotted points directly onto it, |
---|
| | and returned the composite map to the client as a JPEG image (with |
---|
| | the ``quality'' parameter set to 90). |
---|
| | |
---|
| | \item[server-side image overlay] The dispatcher page included two |
---|
| | \verb|<IMG>| elements, the first for the base map and the second for |
---|
| | the overlay, both with identical CSS positioning attributes. The |
---|
| |
---|
| | do a full analysis and statistical comparison of the performance of the |
---|
| | different techniques, but rather to identify broad trends. We have not, |
---|
| | therefore, carried out any statistical analysis on the results. We will |
---|
| | now discuss the results for data size, page load time and memory usage. |
---|
| | Because the data set size increases by powers of two, we have used |
---|
| | log-log scales for all plots. |
---|
| | Because the number of points in each data set increases in powers of |
---|
| | two, we have used log-log scales for all plots. |
---|
| | |
---|
| | |
---|
| | \subsection{Data size} |
---|
| | |
---|
| | During each test run, the data generated by the server was saved to a |
---|
| | file and its size in bytes recorded. In the case of the server-side |
---|
| | image generation and server-side image overlay techniques, the file |
---|
| | comprised a bitmap image; whereas for the server-side HTML overlay and |
---|
| | Google Maps techniques, the file comprised XML data. (The latter was |
---|
| | also true of the KML files generated for use with Google Earth.) |
---|
| | Google Maps techniques, the file comprised HTML or XML text, |
---|
| | respectively. |
---|
| | |
---|
| | There was a certain amount of fixed overhead for each technique tested, |
---|
| | as summarised in Table~\ref{tab-overhead}. This overhead comprised |
---|
| | static files that were always downloaded to the client, regardless of |
---|
| |
---|
| | \centering |
---|
| | \begin{tabular}{lll} |
---|
| | Technique & Fixed overhead & Content \\ |
---|
| | \hline |
---|
| | Server-side image generation & 629\,bytes & PHP (dispatcher)\smallskip \\ |
---|
| | |
---|
| | Server-side image overlay & \(\approx\) 181\,kB & PHP (dispatcher) \\ |
---|
| | Server-side image generation & 629\,bytes & dispatcher (PHP)\smallskip \\ |
---|
| | |
---|
| | Server-side image overlay & \(\approx\) 181\,kB & dispatcher (PHP) \\ |
---|
| | & & base map image (JPEG)\smallskip \\ |
---|
| | |
---|
| | Server-side HTML overlay & \(\approx\) 181\,kB & PHP (dispatcher) \\ |
---|
| | Server-side HTML overlay & \(\approx\) 181\,kB & dispatcher (PHP) \\ |
---|
| | & & base map image (JPEG)\smallskip \\ |
---|
| | |
---|
| | Google Maps & \(\approx\) 235\,kB & PHP (dispatcher) \\ |
---|
| | & & base map tiles \\ |
---|
| | & & JavaScript (API) \\ |
---|
| | & & various icons\smallskip \\ |
---|
| | |
---|
| | (Google Earth) & unknown & \\ |
---|
| | Google Maps & \(\approx\) 235\,kB & dispatcher (PHP) \\ |
---|
| | & & base map image tiles (PNG) \\ |
---|
| | & & API (JavaScript) \\ |
---|
| | & & various icons (PNG) \\ |
---|
| | \end{tabular} |
---|
| | \caption{Fixed overhead for each technique.} |
---|
| | \label{tab-overhead} |
---|
| | \end{acmtable} |
---|
| | |
---|
| | |
---|
| | \begin{figure} |
---|
| | \includegraphics[scale=0.66]{data_size} |
---|
| | \centering |
---|
| | \includegraphics[scale=0.5]{data_size} |
---|
| | \caption{Comparison of generated data size for each technique (log-log scale).} |
---|
| | \label{fig-data-size} |
---|
| | \end{figure} |
---|
| | |
---|
| | |
---|
| | The amount of data generated for each technique, including fixed |
---|
| | overhead, is shown in Figure~\ref{fig-data-size}. It is immediately |
---|
| | apparent from these results that there is a divergence between the two |
---|
| | techniques that generate bitmap images (server-side image generation and |
---|
| | server-side image overlay), and the remaining techniques that generate |
---|
| | either HTML or XML (i.e., text). |
---|
| | techniques that generate images (server-side image generation and |
---|
| | server-side image overlay), and the two techniques that generate text |
---|
| | (server-side HTML overlay and Google Maps). |
---|
| | |
---|
| | Both the server-side image generation and server-side image overlay |
---|
| | techniques scale particularly well with regard to the amount of data |
---|
| | generated. Interestingly, the amount of data generated by the image |
---|
| |
---|
| | scale well, and begin to visibly diverge from the other two techniques |
---|
| | once the amount of data generated exceeds about 5\% of the fixed |
---|
| | overhead. For the HTML overlay technique this occurs somewhere between |
---|
| | 64 and 128 points, whereas for Google Maps it occurs somewhere between |
---|
| | 256 and 512 points. The divergence increases rapidly beyond this point |
---|
| | for both techniques, with the HTML overlay technique suffering the most. |
---|
| | 256 and 512 points. The divergence increases rapidly for both techniques |
---|
| | beyond these points, with the HTML overlay technique suffering the most. |
---|
| | The latter occurs because the HTML overlay technique needs to generate |
---|
| | additional CSS attributes in order to correctly position the |
---|
| | \verb|<DIV>| elements, whereas the Google Maps technique needs only to |
---|
| | return a more compact list of latitude/longitude coordinates. |
---|
| | |
---|
| | For Google Earth, the amount of data generated is clearly proportional |
---|
| | to the number of points, but the Google Earth results are otherwise not |
---|
| | directly comparable with the other techniques, as we were unable to |
---|
| | determine whether Google Earth had any fixed overhead. |
---|
| | additional CSS attributes (i.e., more text) in order to correctly |
---|
| | position the \verb|<DIV>| elements, whereas the Google Maps technique |
---|
| | needs only to return a more compact list of latitude/longitude |
---|
| | coordinates. |
---|
| | |
---|
| | |
---|
| | \subsection{Page load time} |
---|
| | |
---|
| |
---|
| | \subsubsection{Data generation time} |
---|
| | |
---|
| | |
---|
| | \begin{figure} |
---|
| | \includegraphics[scale=0.66]{data_generation_time} |
---|
| | \centering |
---|
| | \includegraphics[scale=0.5]{data_generation_time} |
---|
| | \caption{Comparison of data generation time for each technique (log-log scale).} |
---|
| | \label{fig-data-generation-time} |
---|
| | \end{figure} |
---|
| | |
---|
| | |
---|
| | The results show that the length of time taken to generate the source |
---|
| | data increases in proportion with the amount of points to be plotted, as |
---|
| | expected. It is interesting to note the differences in data generation |
---|
| | time for each technique, however. Data generation for all of the |
---|
| | ``text-based'' techniques (HTML overlay, Google Maps and Google Earth) |
---|
| | is consistently faster than for the ``image-based'' techniques (image |
---|
| | generation and image overlay). |
---|
| | |
---|
| | Server-side image generation generally takes the longest to generate its |
---|
| | data. This is because it not only has to map points from |
---|
| | latitude/longitude into projected map coordinates, but also must plot |
---|
| | these points onto the base map image, then compress the composite image |
---|
| | as a JPEG. The image to be compressed is also moderately complex, which |
---|
| | only adds to the data generation time. Server-side image generation |
---|
| | performs slightly better because it uses a less complex compression |
---|
| | method (PNG) and the image being compressed is much simpler (a |
---|
| | collection of colored points on a blank background). |
---|
| | |
---|
| | The server-side HTML overlay techniques appears faster at generating |
---|
| | data than either of the two image-based techniques at the low end, but |
---|
| | is similar in performance at the high end. In this technique the server |
---|
| | The results (see Figure~\ref{fig-data-generation-time}) show that the |
---|
| | length of time taken to generate the source data increases in proportion |
---|
| | to the number of points to be plotted, as expected. It is interesting to |
---|
| | note the differences in data generation time for each technique, |
---|
| | however. Data generation for both of the ``text-based'' techniques (HTML |
---|
| | overlay and Google Maps) is consistently faster than for the |
---|
| | ``image-based'' techniques (image generation and image overlay). |
---|
| | |
---|
| | The results show that server-side image generation generally takes the |
---|
| | longest to generate its data. This is because it not only has to map |
---|
| | points from latitude/longitude into projected map coordinates, but also |
---|
| | must plot these points onto the base map image, then compress the |
---|
| | composite image as a JPEG. The image to be compressed is also moderately |
---|
| | complex, which only adds to the data generation time. Server-side image |
---|
| | overlay performs somewhat better because it uses a less complex |
---|
| | compression method (PNG) and the image to be compressed is much simpler |
---|
| | (a collection of colored points on a blank background). |
---|
| | |
---|
| | The server-side HTML overlay technique appears faster at generating data |
---|
| | than either of the two image-based techniques at the low end, but is |
---|
| | similar in performance at the high end. In this technique the server |
---|
| | only needs to map latitude/longitude to projected map coordinates; no |
---|
| | images need to be generated and there is no compression. At the high |
---|
| | end, however, this advantage is clearly offset by the large volume of |
---|
| | data that is generated. Google Maps is faster again, because all |
---|
| | processing is carried out on the client; the server's only involvement |
---|
| | is to generate a list of latitude/longitude coordinates. A similar |
---|
| | argument also applies for Google Earth. |
---|
| | images need to be generated and there is no compression to deal with. At |
---|
| | the high end, however, this advantage is clearly offset by the |
---|
| | significant volume of data being generated. Google Maps is faster again, |
---|
| | because almost all processing is carried out on the client; the server's |
---|
| | only involvement is to generate a simple list of latitude/longitude |
---|
| | coordinates. |
---|
| | |
---|
| | In terms of data generation, it appears that all techniques tested scale |
---|
| | reasonably well. The image-based techniques perform worse at the low end |
---|
| | because they involve more complex processing than the text-based |
---|
| | techniques, but this is offset at the high end by the relatively |
---|
| | constant amount of data generated. Conversely, the text-based techniques |
---|
| | perform better at the low end, but are negatively imapcted at the high |
---|
| | perform better at the low end, but are negatively impacted at the high |
---|
| | end by the sheer volume of data produced (tens or hundreds of megabytes |
---|
| | vs.\ hundreds of kilobytes). |
---|
| | |
---|
| | |
---|
| |
---|
| | |
---|
| | |
---|
| | \begin{figure} |
---|
| | \centering |
---|
| | \includegraphics[scale=0.66]{page_load_time} |
---|
| | \includegraphics[scale=0.5]{page_load_time} |
---|
| | \caption{Comparison of map display time for each technique (log-log scale).} |
---|
| | \label{fig-page-load-time} |
---|
| | \end{figure} |
---|
| | |
---|
| | |
---|
| | These results show quite a spectacular difference between the |
---|
| | image-based and text-based techniques. The time taken to display the map |
---|
| | is essentially constant for both of the image-based techniques, |
---|
| | regardless of the number of points to be plotted. This is not surprising |
---|
| | given that the size of the generated data is also essentially constant, |
---|
| | and that the browser is simply loading and displaying static images. The |
---|
| | image overlay technique appears slightly slower than the image |
---|
| | generation technique. This is probably because the image overlay |
---|
| | technique has to load two images from the server (the base map and the |
---|
| | overlay), compared to one image for the image generation technique. |
---|
| | These results (see Figure~\ref{fig-page-load-time}) reveal quite a |
---|
| | spectacular difference between the image-based and text-based |
---|
| | techniques. The time taken to display the map is essentially constant |
---|
| | for both of the image-based techniques, regardless of the number of |
---|
| | points to be plotted. This is not surprising given that the size of the |
---|
| | generated data is also essentially constant, and that the browser is |
---|
| | simply loading and displaying static images. The image overlay technique |
---|
| | appears slightly slower than the image generation technique. This is |
---|
| | probably because the image overlay technique has to load two images from |
---|
| | the server (the base map and the overlay), compared to one image for the |
---|
| | image generation technique. |
---|
| | |
---|
| | In contrast, the text-based technique clearly do not scale well with |
---|
| | regards to map display time. Google Maps suffers particularly in this |
---|
| | regard, with display time exceeding ten seconds shortly past 512 points. |
---|
| | Testing was abandoned at 4,096 points, with a single test run taking |
---|
| | over seven minutes. The HTML overlay technique fares better, exceeding |
---|
| | ten seconds somewhere between 4,096 and 8,192 points. Testing was |
---|
| | abandoned at 32,768 points, with a single test run taking almost ten |
---|
| | minutes. Interestingly, Google Earth performed worse at the low end but |
---|
| | did better at the high end, presumably because it is specifically |
---|
| | designed to handle these kinds of tasks. We were able to reach 131,072 |
---|
| | points before testing was abandoned. |
---|
| | minutes. |
---|
| | |
---|
| | |
---|
| | \subsubsection{Combined time} |
---|
| | |
---|
| | |
---|
| | \begin{figure} |
---|
| | \centering |
---|
| | \includegraphics[scale=0.66]{combined_time} |
---|
| | \includegraphics[scale=0.5]{combined_time} |
---|
| | \caption{Comparison of combined page load time for each technique (log-log scale).} |
---|
| | \label{fig-combined-time} |
---|
| | \end{figure} |
---|
| | |
---|
| | |
---|
| | Combining the data generation and map display times yields little change |
---|
| | in the curves for the text-based techniques, because the data generation |
---|
| | times are very small compared to the map display times. There is a more |
---|
| | obvious impact on the image-based techniques, with both techniques |
---|
| | remaining more or less constant up to about 2,048 points, then slowing |
---|
| | as the number of points increases beyond that. However, the slowdown is |
---|
| | nowhere near as dramatic as for the text-based techniques; even the |
---|
| | largest data set only takes about nineteen seconds overall. The image |
---|
| | overlay technique does display a slight advantage of about half a second |
---|
| | over the image generation technique for the largest data set, but |
---|
| | further experiments will be required to determine whether this is a |
---|
| | statistically significant difference. |
---|
| | Combining the data generation and map display times (see |
---|
| | Figure~\ref{fig-combined-time}) yields little change in the curves for |
---|
| | the text-based techniques, because the data generation times are very |
---|
| | small compared to the map display times. There is a more obvious impact |
---|
| | on the image-based techniques, with both techniques remaining more or |
---|
| | less constant up to about 2,048 points, then slowing as the number of |
---|
| | points increases beyond that. However, the slowdown is nowhere near as |
---|
| | dramatic as for the text-based techniques; even the largest data set |
---|
| | only takes about nineteen seconds overall. The image overlay technique |
---|
| | does display a slight advantage of about half a second over the image |
---|
| | generation technique for the largest data set, but further experiments |
---|
| | will be required to determine whether this is a statistically |
---|
| | significant difference. |
---|
| | |
---|
| | |
---|
| | \subsection{Memory usage} |
---|
| | |
---|
| |
---|
| | memory usage in each category. This told us the size of both the current |
---|
| | ``working set'' and the total memory footprint of the browser process |
---|
| | after it had completed a test run. The real memory results are shown in |
---|
| | Figure~\ref{fig-real-memory} and the virtual memory results are shown in |
---|
| | Figure~\ref{fig-virtual-memory} |
---|
| | |
---|
| | |
---|
| | \begin{figure} |
---|
| | \centering |
---|
| | \includegraphics[scale=0.66]{real_memory} |
---|
| | Figure~\ref{fig-virtual-memory}. |
---|
| | |
---|
| | |
---|
| | \begin{figure} |
---|
| | \centering |
---|
| | \includegraphics[scale=0.5]{real_memory} |
---|
| | \caption{Comparison of real memory usage for each technique (log-log scale).} |
---|
| | \label{fig-real-memory} |
---|
| | \end{figure} |
---|
| | |
---|
| | |
---|
| | \begin{figure} |
---|
| | \centering |
---|
| | \includegraphics[scale=0.66]{virtual_memory} |
---|
| | \includegraphics[scale=0.5]{virtual_memory} |
---|
| | \caption{Comparison of virtual memory usage for each technique (log-log scale).} |
---|
| | \label{fig-virtual-memory} |
---|
| | \end{figure} |
---|
| | |
---|
| | |
---|
| | While both sets of results display similar trends, the real memory data |
---|
| | proved somewhat difficult to interpret. Real memory usage was generally |
---|
| | consistent across test runs, but would also frequently fluctuate upwards |
---|
| | by a factor of nearly two for no readily apparent reason. This is |
---|
| | proved somewhat problematic. Real memory usage was generally consistent |
---|
| | across test runs, but would also frequently fluctuate upwards by a |
---|
| | factor of nearly two for no readily apparent reason. This is |
---|
| | particularly apparent with the HTML overlay technique beyond 1,024 |
---|
| | points. We can only assume that this was a result of other processes on |
---|
| | the test machine interacting with the browser process in unexpected |
---|
| | ways. We are therefore somewhat wary of the real memory data, but they |
---|
| |
---|
| | memory footprint of a process is less likely to be impacted by other |
---|
| | running processes. |
---|
| | |
---|
| | The results show that the two image-based techniques have essentially |
---|
| | constaint memory usage regardless of the number of points plotted. This |
---|
| | constant memory usage regardless of the number of points plotted. This |
---|
| | is to be expected, given that the size of the source data is also |
---|
| | essentially constant. The text-based techniques, however, clearly begin |
---|
| | to diverge as the number of points increases. The HTML overlay technique |
---|
| | starts to visibly diverge somewhere between 2,048 and 4,096 points, |
---|
| | while Google Maps starts to visbly diverge 64 and 128 points. This is in |
---|
| | line with our expectation for these techniques that memory usage would |
---|
| | increase in proportion to the number of points. |
---|
| | |
---|
| | |
---|
| | \section{Conclusion} |
---|
| | while Google Maps starts to visibly diverge 64 and 128 points. This is |
---|
| | in line with our expectation for these techniques that memory usage |
---|
| | would increase in proportion to the number of points. It is intriguing |
---|
| | to note that for both techniques, there appears little consistency as to |
---|
| | where the performance of each measure begins to diverge, as shown in |
---|
| | Table~\ref{tab-divergence} (although Google Maps appears to exhibit |
---|
| | greater consistency than HTML overlay in this regard). |
---|
| | |
---|
| | |
---|
| | \begin{acmtable}{11cm} |
---|
| | \centering |
---|
| | \begin{tabular}{lccc} |
---|
| | Technique & Data size & Map display time & Virtual memory \\ |
---|
| | \hline |
---|
| | Server-side HTML overlay & 64--128 & 128--256 & 2,048--4,096 \\ |
---|
| | Google Maps & 256--512 & 64--128 & 64--128 \\ |
---|
| | \end{tabular} |
---|
| | \caption{Approximate number of points at which each measure begins to diverge, |
---|
| | for the HTML overlay and Google Maps techniques.} |
---|
| | \label{tab-divergence} |
---|
| | \end{acmtable} |
---|
| | |
---|
| | |
---|
| | \section{Conclusion and future work} |
---|
| | \label{sec-conclusion} |
---|
| | |
---|
| | In this research, we tested the scalability of four techniques for |
---|
| | online geovisualization of web site hits, with respect to the number of |
---|
| | points to be plotted on the map. The four techniques tested were |
---|
| |
---|
| | server-side image generation and server-side image overlay techniques |
---|
| | scale the best from small to large data sets. The HTML overlay and |
---|
| | Google Maps techniques work well for small data sets, but their |
---|
| | performance rapidly deteriorates as the size of the data set increases, |
---|
| | to the point where they are essentially unusable. |
---|
| | |
---|
| | Our aim was to identify which was the best technique to use to plot hits |
---|
| | on the Otago School of Business repository. We are now left with a choice |
---|
| | between two very similarly-performing techniques. |
---|
| | |
---|
| | |
---|
| | % The |
---|
| | % software extracts IP addresses from the web server logs, geolocates them |
---|
| | % using the free MaxMind GeoLite Country database\footnote{See |
---|
| | % \url{http://www.maxmind.com/app/ip-location}.}, then stores the |
---|
| | % resulting country information in a separate database. |
---|
| | |
---|
| | % The Tasmania software, however, uses countries as its base unit of |
---|
| | % aggregation. We were interested in looking at the distribution on a finer |
---|
| | % level, down to individual cities if possible |
---|
| | to the point where they become unusable. |
---|
| | |
---|
| | Despite this clear difference in scalability, we are still left with |
---|
| | some interesting questions. We did not investigate the model interaction |
---|
| | environment distribution style in this research, as it was unclear |
---|
| | whether this could be achieved using only client-side JavaScript. This |
---|
| | is clearly an avenue for further investigation. In addition, the |
---|
| | appearance of native SVG support in some browsers means that this may |
---|
| | also become a viable option in future. |
---|
| | |
---|
| | We were somewhat surprised that the server-side HTML overlay and Google |
---|
| | Maps techniques exhibited no obvious consistency in where the different |
---|
| | measures (data size, map display time and virtual memory usage) |
---|
| | diverged. It seems logical that some form of correlation might exist, so |
---|
| | further research will be required to investigate this. One possibility |
---|
| | might be to implement an instrumented web browser and server in order to |
---|
| | gather more precise data. |
---|
| | |
---|
| | Shortly after completing our experiments, we discovered \emph{msCross |
---|
| | Webgis}\footnote{\url{http://datacrossing.crs4.it/en_Documentation_mscross.html}}, |
---|
| | which is an open source Google Maps clone. Its documentation implies |
---|
| | that it may be possible to build a fully self-contained implementation |
---|
| | that requires no external network access. This would enable us to test |
---|
| | on an isolated network with the client and server running on different |
---|
| | machines. We could then include measurements of network transfer time, |
---|
| | and eliminate any problems caused by running the client and server on |
---|
| | the same machine. |
---|
| | |
---|
| | Our overall aim was to identify which was the best technique to use to |
---|
| | plot downloads and abstract views from the Otago School of Business |
---|
| | digital repository. Based on our results, both the server-side HTML |
---|
| | overlay and Google Maps techniques are clearly inappropriate for this |
---|
| | task. This leaves us with a choice between two very similarly-performing |
---|
| | techniques: server-side image generation and server-side image overlay. |
---|
| | However, the practical advantages of multi-layer techniques over |
---|
| | single-layer techniques, such as the ability to dynamically show and |
---|
| | hide multiple overlays, mean that server-side image overlay is the clear |
---|
| | winner in this case. |
---|
| | |
---|
| | |
---|
| | \begin{acks} |
---|
| | The author would like to acknowledge Dr.\ Antoni Moore and Prof.\ George |
---|
| | Benwell for their input into this research. |
---|
| | \end{acks} |
---|
| | |
---|
| | |
---|
| | \bibliography{Map_Visualisation} |
---|
| | |
---|
| | |
---|
| | \begin{received} |
---|
| | ... |
---|
| | \end{received} |
---|