- Corrected order of columns in data files. - Fixed log scales on line plots. - Cleaned up line plot formatting - Added distribution styles figure. - Revamped experimental design section. - Added initial figures and text for results section.

nigel.stanger / Publications

Browse code - Corrected order of columns in data files. - Fixed log scales on line plots. - Cleaned up line plot formatting - Added distribution styles figure. - Revamped experimental design section. - Added initial figures and text for results section. TOIT_2006
1 parent 2ab5026 commit 46a1b590fa3f058d8b2f9482901701ad70784920 nstanger authored on 4 Aug 2006

Patch

Showing 15 changed files

Ignore Space Show notes View Makefile
.SUFFIXES: .eps .dvi .ps .bbl .bib .tex .plo .tif .pdf SHELL=/bin/sh lineplot = ploticus -eps -tightcrop -o $(1).eps lineplot.plo infile=$(2) \ title=$(3) ytitle=$(4) ymin=$(5) ymax=$(6); \ epstopdf $(1).eps; \ rm -f $(1).eps GRAPHICS:=ImageGeneration-full.png GoogleMap-full.png \ jpeg_detail.png overlay_detail.png \ tasmania_stats.pdf data_size.pdf data_generation_time.pdf \ page_load_time.pdf combined_time.pdf real_memory.pdf virtual_memory.pdf \ data_server.pdf image_server.pdf model_interaction.pdf shared.pdf Map_Visualisation.pdf: Map_Visualisation.tex Map_Visualisation.bib $(GRAPHICS) pdflatex $< bibtex $* pdflatex $< pdflatex $< jpeg_detail.png: ImageGeneration-full.png convert -crop 180x95+150+95 $< $@ overlay_detail.png: PointOverlay-full.png convert -crop 180x95+150+95 $< $@ data_size.pdf: d_data_size.txt lineplot.plo $(call lineplot,$,$<,'Size of Generated Data','Data size (kB)',0.1,200000) data_generation_time.pdf: d_data_generation_time.txt lineplot.plo $(call lineplot,$,$<,'Data Generation Time','Average time to generate data at server (s)',0.001,2000) page_load_time.pdf: d_page_load_time.txt lineplot.plo $(call lineplot,$,$<,'Map Display Time','Average time to display map at client (s)',0.001,2000) combined_time.pdf: d_combined_time.txt lineplot.plo $(call lineplot,$,$<,'Combined Page Load Time','Average time to generate data and display map (s)',0.001,2000) real_memory.pdf: d_real_memory.txt lineplot.plo $(call lineplot,$,$<,'Real Memory Usage','Application real memory size (MB)',10,2000) virtual_memory.pdf: d_virtual_memory.txt lineplot.plo $(call lineplot,$,$<,'Virtual Memory Usage','Application virtual memory size (MB)',50,1200) %.pdf: %.svg inkscape --file=$< --export-text-to-path --without-gui --export-eps=$.eps ps2eps --ignoreBB --nohires --loose --gsbbox < $.eps \| ps2pdf -dEPSCrop - $@ rm -f $.eps clean: rm -f .aux .bbl .blg .log .dvi .ps Map_Visualisation.pdf %.pdf: %.ps ps2pdf -dNOCACHE $< $@ %.ps: %.dvi dvips -o $@ $< %.dvi: %.tex latex $< latex $< %.eps: %.tif convert $< $@ .SUFFIXES: .eps .dvi .ps .bbl .bib .tex .plo .tif .pdf SHELL=/bin/sh GRAPHICS:=ImageGeneration-full.png GoogleMap-full.png \ jpeg_detail.png overlay_detail.png \ tasmania_stats.pdf Map_Visualisation.pdf: Map_Visualisation.tex Map_Visualisation.bib $(GRAPHICS) pdflatex $< bibtex $ pdflatex $< pdflatex $< jpeg_detail.png: ImageGeneration-full.png convert -crop 180x95+150+95 $< $@ overlay_detail.png: PointOverlay-full.png convert -crop 180x95+150+95 $< $@ throughput.eps: barchart.plo ploticus -eps -tightcrop -o $@ $< yrange="0 2.25" ystubfmt="%2.1f" ylabel="Throughput (bps)" field=throughput movement-time.eps: barchart.plo ploticus -eps -tightcrop -o $@ $< yrange="0 2.25" ystubfmt="%2.1f" ylabel="Movement time (s)" field=movement_time error-rate.eps: barchart.plo ploticus -eps -tightcrop -o $@ $< yrange="0 155" ystubfmt="%g" ylabel="Error rate (%)" field=error_rate combobox-learning.eps: linechart.plo ploticus -eps -tightcrop -o $@ $< field1=combo_mouse_move field2=combo_touch_move label1=Mouse label2=Touch checkbox-learning.eps: linechart.plo ploticus -eps -tightcrop -o $@ $< field1=check_mouse_move field2=check_touch_move label1=Mouse label2=Touch variation-text-mouse.eps: variation.plo ploticus -eps -tightcrop -o $@ $< device=mouse target=text variation-text-touch.eps: variation.plo ploticus -eps -tightcrop -o $@ $< device=touch target=text variation-combo-mouse.eps: variation.plo ploticus -eps -tightcrop -o $@ $< device=mouse target=combo variation-combo-touch.eps: variation.plo ploticus -eps -tightcrop -o $@ $< device=touch target=combo clean: rm -f .aux .bbl .blg .log .dvi .ps Map_Visualisation.pdf %.pdf: %.ps ps2pdf -dNOCACHE $< $@ %.ps: %.dvi dvips -o $@ $< %.dvi: %.tex latex $< latex $< %.eps: %.tif convert $< $@

Ignore Space Show notes View

Makefile

.SUFFIXES: .eps .dvi .ps .bbl .bib .tex .plo .tif .pdf

SHELL=/bin/sh

lineplot = ploticus -eps -tightcrop -o $(1).eps lineplot.plo infile=$(2) \
	title=$(3) ytitle=$(4) ymin=$(5) ymax=$(6); \
	epstopdf $(1).eps; \
	rm -f $(1).eps

GRAPHICS:=ImageGeneration-full.png GoogleMap-full.png \
	jpeg_detail.png overlay_detail.png \
	tasmania_stats.pdf data_size.pdf data_generation_time.pdf \
	page_load_time.pdf combined_time.pdf real_memory.pdf virtual_memory.pdf \
	data_server.pdf image_server.pdf model_interaction.pdf shared.pdf

Map_Visualisation.pdf: Map_Visualisation.tex Map_Visualisation.bib $(GRAPHICS)
	pdflatex $<
	bibtex $*
	pdflatex $<
	pdflatex $<

jpeg_detail.png: ImageGeneration-full.png
	convert -crop 180x95+150+95 $< $@

overlay_detail.png: PointOverlay-full.png
	convert -crop 180x95+150+95 $< $@

data_size.pdf: d_data_size.txt lineplot.plo
	$(call lineplot,$*,$<,'Size of Generated Data','Data size (kB)',0.1,200000)

data_generation_time.pdf: d_data_generation_time.txt lineplot.plo
	$(call lineplot,$*,$<,'Data Generation Time','Average time to generate data at server (s)',0.001,2000)

page_load_time.pdf: d_page_load_time.txt lineplot.plo
	$(call lineplot,$*,$<,'Map Display Time','Average time to display map at client (s)',0.001,2000)

combined_time.pdf: d_combined_time.txt lineplot.plo
	$(call lineplot,$*,$<,'Combined Page Load Time','Average time to generate data and display map (s)',0.001,2000)

real_memory.pdf: d_real_memory.txt lineplot.plo
	$(call lineplot,$*,$<,'Real Memory Usage','Application real memory size (MB)',10,2000)

virtual_memory.pdf: d_virtual_memory.txt lineplot.plo
	$(call lineplot,$*,$<,'Virtual Memory Usage','Application virtual memory size (MB)',50,1200)

%.pdf: %.svg
	inkscape --file=$< --export-text-to-path --without-gui --export-eps=$*.eps
	ps2eps --ignoreBB --nohires --loose --gsbbox < $*.eps | ps2pdf -dEPSCrop - $@
	rm -f $*.eps

clean:
	rm -f *.aux *.bbl *.blg *.log *.dvi *.ps Map_Visualisation.pdf

%.pdf: %.ps
	ps2pdf -dNOCACHE $< $@

%.ps: %.dvi
	dvips -o $@ $<

%.dvi: %.tex
	latex $<
	latex $<

%.eps: %.tif
	convert $< $@

.SUFFIXES: .eps .dvi .ps .bbl .bib .tex .plo .tif .pdf

SHELL=/bin/sh

GRAPHICS:=ImageGeneration-full.png GoogleMap-full.png \
	jpeg_detail.png overlay_detail.png \
	tasmania_stats.pdf

Map_Visualisation.pdf: Map_Visualisation.tex Map_Visualisation.bib $(GRAPHICS)
	pdflatex $<
	bibtex $*
	pdflatex $<
	pdflatex $<

jpeg_detail.png: ImageGeneration-full.png
	convert -crop 180x95+150+95 $< $@

overlay_detail.png: PointOverlay-full.png
	convert -crop 180x95+150+95 $< $@

throughput.eps: barchart.plo
	ploticus -eps -tightcrop -o $@ $< yrange="0 2.25" ystubfmt="%2.1f" ylabel="Throughput (bps)" field=throughput

movement-time.eps: barchart.plo
	ploticus -eps -tightcrop -o $@ $< yrange="0 2.25" ystubfmt="%2.1f" ylabel="Movement time (s)" field=movement_time

error-rate.eps: barchart.plo
	ploticus -eps -tightcrop -o $@ $< yrange="0 155" ystubfmt="%g" ylabel="Error rate (%)" field=error_rate

combobox-learning.eps: linechart.plo
	ploticus -eps -tightcrop -o $@ $< field1=combo_mouse_move field2=combo_touch_move label1=Mouse label2=Touch

checkbox-learning.eps: linechart.plo
	ploticus -eps -tightcrop -o $@ $< field1=check_mouse_move field2=check_touch_move label1=Mouse label2=Touch

variation-text-mouse.eps: variation.plo
	ploticus -eps -tightcrop -o $@ $< device=mouse target=text

variation-text-touch.eps: variation.plo
	ploticus -eps -tightcrop -o $@ $< device=touch target=text

variation-combo-mouse.eps: variation.plo
	ploticus -eps -tightcrop -o $@ $< device=mouse target=combo

variation-combo-touch.eps: variation.plo
	ploticus -eps -tightcrop -o $@ $< device=touch target=combo

clean:
	rm -f *.aux *.bbl *.blg *.log *.dvi *.ps Map_Visualisation.pdf

%.pdf: %.ps
	ps2pdf -dNOCACHE $< $@

%.ps: %.dvi
	dvips -o $@ $<

%.dvi: %.tex
	latex $<
	latex $<

%.eps: %.tif
	convert $< $@

Ignore Space Show notes View Map_Visualisation.tex
\documentclass[acmtocl,acmnow]{acmtrans2m} \usepackage{graphicx} % \usepackage{subfig} \newtheorem{theorem}{Theorem}[section] \newtheorem{conjecture}[theorem]{Conjecture} \newtheorem{corollary}[theorem]{Corollary} \newtheorem{proposition}[theorem]{Proposition} \newtheorem{lemma}[theorem]{Lemma} \newdef{definition}[theorem]{Definition} \newdef{remark}[theorem]{Remark} \markboth{Nigel Stanger}{...} \title{Scalability of Techniques for Online Geovisualization of Web Site Hits} \author{NIGEL STANGER \\ University of Otago} \begin{abstract} A common technique for visualising the geographical distribution of web site hits is to geolocate the IP addresses of hits and plot them on a world map. This is commonly achieved by dynamic generation of images on the server. In this paper we compare the scalability of this technique with three others: overlaying transparent images on an underlying base map, overlaying CSS-enabled HTML on an underlying base map and generating a map using Google Maps. The results show that all four techniques are suitable for small data sets, but that the latter two techniques scale poorly to large data sets. \end{abstract} \category{C.4}{Performance of Systems}{Performance attributes} \category{C.2.4}{Computer-Communication Networks}{Distributed Systems}[distributed applications] \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} \begin{document} \bibliographystyle{acmtrans} \begin{bottomstuff} Author's address: N. Stanger, Department of Information Science, University of Otago, PO Box 56, Dunedin 9054, New Zealand. \end{bottomstuff} \maketitle \section{Introduction} \label{sec-introduction} When administering a web site, it is quite reasonable to want information on the nature of traffic to the site. Information on the geographic sources of traffic can be particularly useful in the right context. For example, an e-commerce site might wish to determine the geographical distribution of visitors to its site, so that it can decide where best to target its marketing resources. One approach to doing so is to plot the geographical location of web site hits on a map. Geographical information systems (GIS) were already being used for these kinds of purposes prior to the advent of the World Wide Web \cite{Beau-JR-1991-GIS}, and it is a natural extension to apply these ideas to online visualization of web site hits. Our interest in this area derives from implementing a pilot digital institutional repository at the University of Otago\footnote{\url{http://eprints.otago.ac.nz/}} in November 2005 \cite{Stan-N-2006-running}, using the GNU EPrints\footnote{\url{http://www.eprints.org/}} repository management software. The 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 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 ordered ranking of the number of hits from each country, it does not provide any visual clues as to the distribution of hit sources around the globe. \begin{figure} \begin{center} \includegraphics[scale=0.65]{tasmania_stats} \end{center} \caption{A portion of the by-country display for the Otago EPrints repository, generated by the Tasmania statistics software.} \label{fig-tas-stats} \end{figure} We therefore began to explore various techniques for plotting our repository hit data onto a world map, with the aim of adding this capability to the Tasmania statistics package. Our preference was for a technique that could be used within a modern web browser without the need to manually install additional client software, thus providing us with the widest possible audience and reducing the impact of wide variation in client hardware and software environments \cite[pp.\ 27--28]{Offu-J-2002-quality}. There have been several prior efforts to plot web activity geographically. \citeN{Lamm-SE-1996-webvis} developed a sophisticated system for real-time visualization of web traffic on a 3D globe, but this was intended for use within a virtual reality environment, thus limiting its general applicability. \citeN{Papa-N-1998-Palantir} described a similar system (Palantir) written in Java, which was thus able to be run within a web browser, assuming that a Java virtual machine was available. \citeN[pp.\ 100--103]{Dodg-M-2001-cybermap} describe these and several other related systems for mapping Web and Internet traffic. These early systems suffered from a distinct limitation in that there was no public infrastructure in place for geolocating IP addresses (that is, translating them into latitude/longitude coordinates). They generally used \texttt{whois} lookups or parsed the domain name in an attempt to guess the country of origin, but these produced fairly crude results. Locations outside the United States were typically aggregated by country and mapped to the capital city \cite{Lamm-SE-1996-webvis,Papa-N-1998-Palantir,Jian-B-2000-cybermap}. Reasonably accurate databases were commercially available at the time \cite[p.\ 1466]{Lamm-SE-1996-webvis}, but were not available to the public at large, thus limiting their utility. The situation has improved considerably in the last five years, however, with the advent of freely available and reasonably accurate geolocation databases\footnote{Such as \url{http://www.maxmind.com/} or \url{http://www.ip2location.com/}.} with worldwide coverage and city-level resolution. For example, Maxmind's \emph{GeoLite City} database is freely available and claims to provide ``60\% accuracy on a 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 previous systems can generally be divided into two classes. Techniques of the first class 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, which is then displayed at the client. We shall henceforth refer to this class of techniques as \emph{image generation} techniques. Techniques of the second class 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{overlay} techniques. Both classes of techniques have been used in the aforementioned systems, but the overlay technique appears to have been particularly popular. For example, Palantir used an overlay technique, where a Java applet running at the client overlaid graphic elements onto a base map image retrieved from the now-defunct Xerox online map server \cite{Papa-N-1998-Palantir}. A more recent example is the Google Maps API \cite{Goog-M-2006-maps}, which enables web developers to easily embed dynamic, interactive maps within web pages. Google Maps is a dynamic overlay technique that has only recently become feasible with the advent of support for CSS positioning and Ajax technologies in most browsers. Overlay techniques enjoy a particular advantage over image generation 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, overlay techniques tend to rely on more recent web technologies such as CSS2 and Ajax, whereas image generation techniques generally do not. Image generation techniques should therefore be portable to a wider range of client and server environments. Within each class, there are several alternative approaches to implementing these techniques. For example, an image generation technique might be completely server-side or use a mixture of server-side and client-side processing. Overlay techniques can also 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 of these 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. 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 chosen are discussed in Section~\ref{sec-techniques}. We then set about testing the scalability of these four techniques, in order to determine how well each technique handled large numbers of points. A series of experiments was conducted using 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 intuition was that server-side image generation and server-side image overlay techniques would prove the most scalable, 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 numbers of points (generally less than about 500--1,000), but their performance deteriorated rapidly beyond this. The results are discussed in more detail in Section~\ref{sec-results}. \section{Technique selection} \label{sec-techniques} In this section we discuss in more detail the four techniques that we chose for testing, and how we decided upon these particular techniques. First, we discuss the impact of distribution style on the choice of technique. Then, for each of the four chosen techniques, we examine how the technique works in practice, its implementation requirements, its relative advantages and disadvantages, and any other issues peculiar to the technique. \subsection{Distribution style} \label{sec-distribution} \citeN{Wood-J-1996-vis} and \citeN{MacE-AM-1998-GIS} identified four distribution styles for web-based geographic visualization software. The \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 an overlay 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 cient-side software. We can therefore eliminate Java- or Flash-based data server techniques from consideration. \begin{figure} \begin{center} \begin{tabular}{ccc} \includegraphics[scale=1]{data_server} & \qquad & \includegraphics[scale=1]{image_server} \\ \footnotesize (a) Data server & \qquad & \footnotesize (b) Image server \\ \\ \\ \includegraphics[scale=1]{model_interaction} & \qquad & \includegraphics[scale=1]{shared} \\ \footnotesize (c) Model interaction environment & \qquad & \footnotesize (d) Shared environment \\ \end{tabular} \end{center} \caption{Distribution styles for web-based geographic visualization \protect\cite{Wood-J-1996-vis}. (F = filtering, M = mapping, R = rendering.)} \label{fig-distribution-styles} \end{figure} In contrast, the \emph{image server} style is where the display is created at entirely the server and is only viewed at the client. In other words, this is primarily a server-side processing model, as 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 a simple bitmap image. The \emph{3D 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). The phrase ``3D model interaction'' seems slightly out of place in the current context. \citeN{Wood-J-1996-vis} originally intended this distribution style to apply to VRML models for GIS applications, but it could be equally applied to any situation where an interactive model is generated at the server, then downloaded to and manipulated at the client. This is very similar to what happens with many Flash-based applications, for example. A more general name for this style could therefore be \emph{model interaction environment}. The key distinguishing feature of this style is that there is no further 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 and downloaded from the server. Similar restrictions apply to techniques using this style as with 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 presentl unclear as to how effective this might be. % future work: implement model interaction using JavaScript? 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 Figure~\ref{fig-distribution-styles}(d). This is similar to the model 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. This is essentially the distribution style provided by Ajax technologies [REF]. We can eliminate techniques based on the same criteria as applied to the other three styles. \subsection{Image generation techniques} \label{sec-image-gen} As noted earlier, image generation 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} \begin{center} \includegraphics[width=0.95\textwidth,keepaspectratio]{ImageGeneration-full} \end{center} \caption{Sample output from the server-side image generation technique.} \label{fig-image} \end{figure} Image generation 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 image generation using an image server distribution style (or ``server-side image generation'') from this point on. 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 generated 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 techniques such as JPEG can make the points plotted on the map appear distinctly fuzzy, as shown in Figure~\ref{fig-image-quality}. A lossless compression technique 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} \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.\ PNG image overlay (bottom).} \label{fig-image-quality} \end{figure} \subsection{Overlay 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). Overlay techniques also involve plotting points onto a base map image, but they differ from image generation techniques in that the points are not plotted directly onto the base map image. Rather, the points are plotted as an independent overlay on the base map image. This provides a significant advantage over image generation techniques, as it enables the possibility of multiple independent overlays 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 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. Until relatively recently, implementing overlay techniques would likely have required additional software at the client, but most modern browsers now support absolute positioning of elements using CSS. This enables us to create a map overlay using nothing more than HTML, CSS and a few bitmap images. We have identified two main alternatives for producing such an overlay, which we have termed \emph{image overlay} and \emph{HTML overlay}. An image overlay comprises a transparent bitmap image into which the points are plotted, which is then overlaid on the base map image (the output looks essentially identical to that shown in Figure~\ref{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 be quite small, 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}). 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 this technique. 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 which elements could be used to construct the overlay. One possibility is to use \verb\|<IMG>\| elements, which is the approach adopted by Google Maps (see Figure~\ref{fig-google}). Another possibility is to use appropriately sized and colored \verb\|<DIV>\| 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} \begin{center} \includegraphics[width=0.95\textwidth,keepaspectratio]{GoogleMap-full.png} \end{center} \caption{Sample output from the Google Maps technique.} \label{fig-google} \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\|<IMG>\| elements, we have used embedded \verb\|<DIV>\| 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\|<DIV>\| 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 map in any direction and zoom in and out to many different levels. 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 next 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 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.) 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. \section{Experimental design} \label{sec-experiment} After some preliminary testing with live data from the Otago School of Business repository, we proceeded with a series of experiments to test the scalability of the four techniques. Each technique was tested using progressively larger synthetic data sets. The first data set comprised one point at the South Pole (latitude \(-90^{\circ}\), longitude \(-180^{\circ}\)). Each successive data set was twice the size of its predecessor, comprising a regular grid of latitude/longitude points at one degree intervals\footnote{It should be noted that only 64,800 points are required to fill the entire grid, so the five largest data sets have many duplicate points.}. A total of twenty-one data sets were created in this way, with the number of points ranging from one to 1,048,576 (\(=2^{20}\)). The focus on scalability meant that we were primarily interested in measuring page load times, memory usage, and the amount of data generated (which impacts on both storage and network bandwidth). Page load time can be further broken down into the time taken to generate the map data, the time taken to transfer the map data to the client across the network, and the time taken by the client to display the map. Unfortunately, the Google Maps technique requires an active Internet connection, so we were unable to run the experiments on an isolated network. This meant that traffic on the local network could be a 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\,MHz 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 of each other, 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 JavaScript source and images), as the API will be locally cached thereafter. The API key verification occurs every time the map is loaded, but the amount of data involved is very small, so it is unlikely that this would be significantly affected by network performance. Any such effect would also be immediately obvious as it would simply block the 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 memory used during the test by both the browser and the web server. The data set generation time and memory usage were measured using the \texttt{time} and \texttt{top} utilities respectively. The map display time was measured using the ``page load 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. While it is really 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 that the dialog box ``Loading myplaces.kml, including enabled overlays'' was displayed on screen. \subsection{Technique implementation} As noted in Sections~\ref{sec-image-gen} and \ref{sec-overlay}, the server-side image generation, server-side image overlay and server-side HTML overlay techniques were all implemented using the image server distribution style. A separate dispatcher page was written in PHP for each technique, which enabled passing arguments---such as the number of points to be plotted---from the client to a corresponding Perl script for each technique. The final page was then constructed as follows: \begin{description} \item[server-side image generation] The Perl script generated a JPEG composite map image that was displayed using a standard \verb\|<IMG>\| element. \item[server-side image overlay] The base map (a JPEG image) was displayed using a CSS-positioned \verb\|<IMG>\| element. The Perl script then generated a transparent PNG image, which was displayed using an \verb\|<IMG>\| element with identical positioning attributes to the base map. \item[server-side HTML overlay] The base map (a JPEG image) was displayed using a CSS-positioned \verb\|<IMG>\| element. The Perl script then generated a collection of CSS-positioned \verb\|<DIV>\| elements, which were included inline into the source of the dispatcher page. \end{description} The Google Maps technique was implemented using the shared environment distribution style. Once again, a PHP dispatcher page was used. This time, however, the page included client-side JavaScript code to load and initialise the Google Maps API, create the base map, and build the map overlay. The first two steps were achieved using standard Google Maps API calls. For the last step, the client used an \texttt{XMLHttpRequest} object to call a server-side Perl script. This script generated and returned to the client an XML data set containing the points to be plotted. The client then looped through this data set and used Google Maps API calls to create a marker on the base map corresponding to each point. \section{Results} \label{sec-results} It is important to note that the intent of these experiments was not to do a full analysis and statistical comparison of the performance of the different techniques, but rather to identify broad trends. We have therefore not carried any statistical analysis of the data. \subsection{Data size} The size of the data generated for each technique is shown in Figure~\ref{fig-data-size}. \begin{figure} \begin{center} \includegraphics[scale=0.66]{data_size} \end{center} \caption{Comparison of generated data size for each technique.} \label{fig-data-size} \end{figure} \subsection{Page load time} \begin{figure} \begin{center} \includegraphics[scale=0.66]{data_generation_time} \end{center} \caption{Comparison of data generation time for each technique.} \label{fig-data-generation-time} \end{figure} \begin{figure} \begin{center} \includegraphics[scale=0.66]{page_load_time} \end{center} \caption{Comparison of map display time for each technique.} \label{fig-page-load-time} \end{figure} \begin{figure} \begin{center} \includegraphics[scale=0.66]{combined_time} \end{center} \caption{Comparison of combined page load time for each technique.} \label{fig-combined-time} \end{figure} \subsection{Memory usage} \begin{figure} \begin{center} \includegraphics[scale=0.66]{virtual_memory} \end{center} \caption{Comparison of virtual memory usage for each technique.} \label{fig-virtual-memory} \end{figure} \section{Conclusion} % 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 \bibliography{Map_Visualisation} \begin{received} ... \end{received} \end{document} \documentclass[acmtocl,acmnow]{acmtrans2m} \usepackage{graphicx} \newtheorem{theorem}{Theorem}[section] \newtheorem{conjecture}[theorem]{Conjecture} \newtheorem{corollary}[theorem]{Corollary} \newtheorem{proposition}[theorem]{Proposition} \newtheorem{lemma}[theorem]{Lemma} \newdef{definition}[theorem]{Definition} \newdef{remark}[theorem]{Remark} \markboth{Nigel Stanger}{...} \title{Scalability of Techniques for Online Geovisualization of Web Site Hits} \author{NIGEL STANGER \\ University of Otago} \begin{abstract} A common technique for visualising the geographical distribution of web site hits is to geolocate the IP addresses of hits and plot them on a world map. This is commonly achieved by dynamic generation of images on the server. In this paper we compare the scalability of this technique with three others: overlaying transparent images on an underlying base map, overlaying CSS-enabled HTML on an underlying base map and generating a map using Google Maps. The results show that all four techniques are suitable for small data sets, but that the latter two techniques scale poorly to large data sets. \end{abstract} \category{C.4}{Performance of Systems}{Performance attributes} \category{C.2.4}{Computer-Communication Networks}{Distributed Systems}[distributed applications] \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} \begin{document} \bibliographystyle{acmtrans} \begin{bottomstuff} Author's address: N. Stanger, Department of Information Science, University of Otago, PO Box 56, Dunedin 9054, New Zealand. \end{bottomstuff} \maketitle \section{Introduction} \label{sec-introduction} When administering a web site, it is quite reasonable to want information on the nature of traffic to the site. Information on the geographic sources of traffic can be particularly useful in the right context. For example, an e-commerce site might wish to determine the geographical distribution of visitors to its site, so that it can decide where best to target its marketing resources. One approach to doing so is to plot the geographical location of web site hits on a map. Geographical information systems (GIS) were already being used for these kinds of purposes prior to the advent of the World Wide Web \cite{Beau-JR-1991-GIS}, and it is a natural extension to apply these ideas to online visualization of web site hits. Our interest in this area derives from implementing a pilot digital institutional repository at the University of Otago\footnote{\url{http://eprints.otago.ac.nz/}} in November 2005 \cite{Stan-N-2006-running}, using the GNU EPrints\footnote{\url{http://www.eprints.org/}} repository management software. The 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 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 ordered ranking of the number of hits from each country, it does not provide any visual clues as to the distribution of hit sources around the globe. \begin{figure} \begin{center} \includegraphics[scale=0.65]{tasmania_stats} \end{center} \caption{A portion of the by-country display for the Otago EPrints repository, generated by the Tasmania statistics software.} \label{fig-tas-stats} \end{figure} We therefore began to explore various techniques for plotting our repository hit data onto a world map, with the aim of adding this capability to the Tasmania statistics package. Our preference was for a technique that could be used within a modern web browser without the need to manually install additional client software, thus providing us with the widest possible audience and reducing the impact of wide variation in client hardware and software environments \cite[pp.\ 27--28]{Offu-J-2002-quality}. There have been several prior efforts to plot web activity geographically. \citeN{Lamm-SE-1996-webvis} developed a sophisticated system for real-time visualization of web traffic on a 3D globe, but this was intended for use within a virtual reality environment, thus limiting its general applicability. \citeN{Papa-N-1998-Palantir} described a similar system (Palantir) written in Java, which was thus able to be run within a web browser, assuming that a Java virtual machine was available. \citeN[pp.\ 100--103]{Dodg-M-2001-cybermap} describe these and several other related systems for mapping Web and Internet traffic. These early systems suffered from a distinct limitation in that there was no public infrastructure in place for geolocating IP addresses (that is, translating them into latitude/longitude coordinates). They generally used \texttt{whois} lookups or parsed the domain name in an attempt to guess the country of origin, but these produced fairly crude results. Locations outside the United States were typically aggregated by country and mapped to the capital city \cite{Lamm-SE-1996-webvis,Papa-N-1998-Palantir,Jian-B-2000-cybermap}. Reasonably accurate databases were commercially available at the time \cite[p.\ 1466]{Lamm-SE-1996-webvis}, but were not available to the public at large, thus limiting their utility. The situation has improved considerably in the last five years, however, with the advent of freely available and reasonably accurate geolocation databases\footnote{Such as \url{http://www.maxmind.com/} or \url{http://www.ip2location.com/}.} with worldwide coverage and city-level resolution. For example, Maxmind's \emph{GeoLite City} database is freely available and claims to provide ``60\% accuracy on a 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 previous systems can generally be divided into two classes. Techniques of the first class 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, which is then displayed at the client. We shall henceforth refer to this class of techniques as \emph{image generation} techniques. Techniques of the second class 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{overlay} techniques. Both classes of techniques have been used in the aforementioned systems, but the overlay technique appears to have been particularly popular. For example, Palantir used an overlay technique, where a Java applet running at the client overlaid graphic elements onto a base map image retrieved from the now-defunct Xerox online map server \cite{Papa-N-1998-Palantir}. A more recent example is the Google Maps API \cite{Goog-M-2006-maps}, which enables web developers to easily embed dynamic, interactive maps within web pages. Google Maps is a dynamic overlay technique that has only recently become feasible with the advent of support for CSS positioning and Ajax technologies in most browsers. Overlay techniques enjoy a particular advantage over image generation 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, overlay techniques tend to rely on more recent web technologies such as CSS2 and Ajax, whereas image generation techniques generally do not. Image generation techniques should therefore be portable to a wider range of client and server environments. Within each class, there are several alternative approaches to implementing these techniques. For example, an image generation technique might be completely server-side or use a mixture of server-side and client-side processing. Overlay techniques can also 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 of these 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. We first narrowed down the range of techniques to just four (server-side image generation, image overlay, server-side HTML overlay and Google Maps); the selection process and details of the techniques chosen are discussed in Section~\ref{sec-techniques}. We then set about testing the scalability of these four techniques, in order to determine how well each technique handled large numbers of points. A series of experiments was conducted using 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 intuition was that server-side image generation and image overlay would prove the most scalable, 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 numbers of points (generally less than about 500--1,000), but their performance deteriorated rapidly beyond this. The results are discussed in more detail in Section~\ref{sec-results}. \section{Technique selection} \label{sec-techniques} In this section we discuss in more detail the four techniques that we chose for testing, and how we decided upon these particular techniques. First, we discuss the impact of distribution style on the choice of technique. Then, for each of the four chosen techniques, we examine how the technique works in practice, its implementation requirements, its relative advantages and disadvantages, and any other issues peculiar to the technique. \subsection{Distribution style} \label{sec-distribution} \citeN{Wood-J-1996-vis} and \citeN{MacE-AM-1998-GIS} identified four distribution styles for web-based geographic visualization software. The \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-data-server}. For example, Palantir implemented an overlay 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 cient-side software. We can therefore eliminate Java- or Flash-based data server techniques from consideration. \begin{narrowfig}{2cm} \caption{The data server distribution style \protect\cite{Wood-J-1996-vis}. (F = filtering, M = mapping, R = rendering.)} \label{fig-data-server} \end{narrowfig} In contrast, the \emph{image server} style is where the display is created at entirely the server and is only viewed at the client. In other words, this is primarily a server-side processing model, as illustrated in Figure~\ref{fig-image-server}. 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 a simple bitmap image. \begin{narrowfig}{2cm} \caption{The image server distribution style \protect\cite{Wood-J-1996-vis}.} \label{fig-image-server} \end{narrowfig} The \emph{3D model interaction environment} style is where a model created at the server can be explored at the client, as illustrated in Figure~\ref{fig-model-interaction}. The phrase ``3D model interaction'' seems slightly out of place in the current context. \citeN{Wood-J-1996-vis} originally intended this distribution style to apply to VRML models for GIS applications, but it could be equally applied to any situation where an interactive model is generated at the server, then downloaded to and manipulated at the client. This is very similar to what happens with many Flash-based applications, for example. A more general name for this style could therefore be \emph{model interaction environment}. The key distinguishing feature of this style is that there is no further 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 and downloaded from the server. Similar restrictions apply to techniques using this style as with 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 unclear as to how effective this might be. \begin{narrowfig}{2cm} \caption{The model interaction environment distribution style \protect\cite{Wood-J-1996-vis}.} \label{fig-model-interaction} \end{narrowfig} 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 Figure~\ref{fig-shared-environment}. This is similar to the model 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. This is essentially the distribution style provided by Ajax technologies [REF]. We can eliminate techniques based on the same criteria as applied to the other three styles. \begin{narrowfig}{2cm} \caption{The shared environment distribution style \protect\cite{Wood-J-1996-vis}.} \label{fig-shared-environment} \end{narrowfig} \subsection{Image generation techniques} \label{sec-image-gen} As noted earlier, image generation 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} \begin{center} \includegraphics[width=0.95\textwidth,keepaspectratio]{ImageGeneration-full} \end{center} \caption{Sample output from the server-side image generation technique.} \label{fig-image} \end{figure} Image generation techniques could use any of the distribution styles discussed in Section~\ref{sec-distribution}. However, all but the image server style would probably require the installation of additional client-side software for generating images and performing cartographic projection operations, so we will only consider image generation using an image servr distribution style (or ``server-side image generation'') from this point on. 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 generated 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 techniques such as JPEG can make the points plotted on the map appear distinctly fuzzy, as shown in Figure~\ref{fig-image-quality}. A lossless compression technique 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} \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.\ PNG image overlay (bottom).} \label{fig-image-quality} \end{figure} \subsection{Overlay techniques} \label{sec-html-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). Overlay techniques also involve plotting points onto a base map image, but they differ from image generation techniques in that the points are not plotted directly onto the base map image. Rather, the points are plotted as an independent overlay on the base map image. This provides a significant advantage over image generation techniques, as it enables the possibility of multiple independent overlays 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 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. Until relatively recently, implementing overlay techniques would likely have required additional software at the client, but most modern browsers now support absolute positioning of elements using CSS. This enables us to create a map overlay using nothing more than HTML, CSS and a few bitmap images. We have identified two main alternatives for producing such an overlay, which we have termed \emph{image overlay} and \emph{HTML overlay}. An image overlay comprises a transparent bitmap image into which the points are plotted, which is then overlaid on the base map image (the output looks essentially identical to that shown in Figure~\ref{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 be quite small, 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}). 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 this technique. 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 which elements could be used to construct the overlay. One possibility is to use \verb\|<IMG>\| elements, which is the approach adopted by Google Maps (see Figure~\ref{fig-google}). Another possibility is to use appropriately sized and colored \verb\|<DIV>\| 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} \begin{center} \includegraphics[width=0.95\textwidth,keepaspectratio]{GoogleMap-full.png} \end{center} \caption{Sample output from the Google Maps technique.} \label{fig-google} \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\|<IMG>\| elements, we have used embedded \verb\|<DIV>\| 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\|<DIV>\| 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 map in any direction and zoom in and out to many different levels. 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 next 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 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.) 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. \section{Experimental design} \label{sec-experiment} After some preliminary experimentation and testing with live data from the Otago School of Business repository, we proceeded with a more formal series of experiments to test the scalability of the three techniques. Each technique was tested using progressively larger synthetic data sets. The first data set comprised one point at the South Pole (latitude \(-90^{\circ}\), longitude \(-180^{\circ}\)). Each successive data set was twice the size of its predecessor, comprising a regular grid of latitude/longitude points at one degree intervals. A total of twenty-one data sets were created in this way, with the number of points ranging from one to 1,048,576 (\(=2^{20}\))\footnote{It should be noted that only 64,800 points are required to fill the entire grid, so the five largest data sets have many duplicate points.}. Our focus on scalability meant that we were primarily interested in measuring page load times, memory usage, and the amount of data generated (which impacts on both storage and network bandwidth). The page load time can be further broken down into the time taken to generate the map data, the time taken to transfer the map data to the client across the network, and the time taken by the client to display the map. Unfortunately, the Google Maps technique requires an active Internet connection, so we were unable to run the experiments on an isolated network. This meant that traffic on the local network could be a 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\,MHz with 1\,GiB 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 of each other, thus simplifying the process of data collection and also ensuring that the client and server processes did not impede each other unduly. 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 155\,KiB of JavaScript source), as the API will be locally cached thereafter. The API key verification occurs every time the map is loaded, but the amount of data involved is very small, so it is unlikely that this would be significantly affected by network performance. Any such effect would also be immediately obvious as it would simply block the server from proceeding. For each data set, we recorded the size of the data set, the time taken to generate it, the time taken to display the resultant map in the browser, and the amount of memory used during the test by both the browser and the web server. The data set generation time and memory usage were measured using the \texttt{time} and \texttt{top} utilities respectively. The map display time was measured using the ``page load 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. %%!! confused! The image generation technique was implemented as an image server architecture. A dispatcher page written in PHP called a Perl script, which generated a JPEG-compressed map image and returned this to the browser. The HTML overlay technique was implemented in two ways: \begin{itemize} \item as an image server architecture that worked in much the same way as the image generation technique, except that the Perl script returned an HTML file containing the \verb\|<DIV>\| elements for the overlay, and an \verb\|<IMG>\| element to load the base map image; and \item as a shared environment architecture, where client-side JavaScript code made an asynchronous call to the server-side Perl script, which returned \end{itemize} and Google Maps techniques were implemented as an image server and a shared environment architecture respectively. The HTML overlay technique was implemented twice; once as an image server architecture and once as a shared environment architecture. \section{Results} \label{sec-results} \subsection{Data size} \subsection{Display time} \subsection{Memory usage} \section{Conclusion} % 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 \bibliography{Map_Visualisation} \begin{received} ... \end{received} \end{document}

Ignore Space Show notes View

Map_Visualisation.tex

\documentclass[acmtocl,acmnow]{acmtrans2m}

\usepackage{graphicx}
% \usepackage{subfig}

\newtheorem{theorem}{Theorem}[section]
\newtheorem{conjecture}[theorem]{Conjecture}
\newtheorem{corollary}[theorem]{Corollary}
\newtheorem{proposition}[theorem]{Proposition}
\newtheorem{lemma}[theorem]{Lemma}
\newdef{definition}[theorem]{Definition}
\newdef{remark}[theorem]{Remark}

\markboth{Nigel Stanger}{...}

\title{Scalability of Techniques for Online Geovisualization of Web Site Hits}
            
\author{NIGEL STANGER \\ University of Otago}
            
\begin{abstract} 
A common technique for visualising the geographical distribution of web
site hits is to geolocate the IP addresses of hits and plot them on a
world map. This is commonly achieved by dynamic generation of images on
the server. In this paper we compare the scalability of this technique
with three others: overlaying transparent images on an underlying base
map, overlaying CSS-enabled HTML on an underlying base map and
generating a map using Google Maps. The results show that all four
techniques are suitable for small data sets, but that the latter two
techniques scale poorly to large data sets.
\end{abstract}
            
\category{C.4}{Performance of Systems}{Performance attributes}
\category{C.2.4}{Computer-Communication Networks}{Distributed Systems}[distributed applications]
\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}
            
\begin{document}

\bibliographystyle{acmtrans}

\begin{bottomstuff} 
Author's address: N. Stanger, Department of Information Science,
University of Otago, PO Box 56, Dunedin 9054, New Zealand.
\end{bottomstuff}
            
\maketitle

\section{Introduction}
\label{sec-introduction}

When administering a web site, it is quite reasonable to want
information on the nature of traffic to the site. Information on the
geographic sources of traffic can be particularly useful in the right
context. For example, an e-commerce site might wish to determine the
geographical distribution of visitors to its site, so that it can decide
where best to target its marketing resources. One approach to doing so
is to plot the geographical location of web site hits on a map.
Geographical information systems (GIS) were already being used for these
kinds of purposes prior to the advent of the World Wide Web
\cite{Beau-JR-1991-GIS}, and it is a natural extension to apply these
ideas to online visualization of web site hits.

Our interest in this area derives from implementing a pilot digital
institutional repository at the University of
Otago\footnote{\url{http://eprints.otago.ac.nz/}} in November 2005
\cite{Stan-N-2006-running}, using the GNU
EPrints\footnote{\url{http://www.eprints.org/}} repository management
software. The 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 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
ordered ranking of the number of hits from each country, it does not
provide any visual clues as to the distribution of hit sources around
the globe.

\begin{figure}
	\begin{center}
		\includegraphics[scale=0.65]{tasmania_stats}
	\end{center}
	\caption{A portion of the by-country display for the Otago EPrints
	repository, generated by the Tasmania statistics software.}
	\label{fig-tas-stats}
\end{figure}

We therefore began to explore various techniques for plotting our
repository hit data onto a world map, with the aim of adding this
capability to the Tasmania statistics package. Our preference was for a
technique that could be used within a modern web browser without the
need to manually install additional client software, thus providing us
with the widest possible audience and reducing the impact of wide
variation in client hardware and software environments \cite[pp.\
27--28]{Offu-J-2002-quality}.

There have been several prior efforts to plot web activity
geographically. \citeN{Lamm-SE-1996-webvis} developed a sophisticated
system for real-time visualization of web traffic on a 3D globe, but
this was intended for use within a virtual reality environment, thus
limiting its general applicability. \citeN{Papa-N-1998-Palantir}
described a similar system (Palantir) written in Java, which was thus
able to be run within a web browser, assuming that a Java virtual
machine was available. \citeN[pp.\ 100--103]{Dodg-M-2001-cybermap}
describe these and several other related systems for mapping Web and
Internet traffic.

These early systems suffered from a distinct limitation in that there
was no public infrastructure in place for geolocating IP addresses (that
is, translating them into latitude/longitude coordinates). They
generally used \texttt{whois} lookups or parsed the domain name in an
attempt to guess the country of origin, but these produced fairly crude
results. Locations outside the United States were typically aggregated
by country and mapped to the capital city
\cite{Lamm-SE-1996-webvis,Papa-N-1998-Palantir,Jian-B-2000-cybermap}.
Reasonably accurate databases were commercially available at the time
\cite[p.\ 1466]{Lamm-SE-1996-webvis}, but were not available to the
public at large, thus limiting their utility.

The situation has improved considerably in the last five years, however,
with the advent of freely available and reasonably accurate geolocation
databases\footnote{Such as \url{http://www.maxmind.com/} or
\url{http://www.ip2location.com/}.} with worldwide coverage and
city-level resolution. For example, Maxmind's \emph{GeoLite City}
database is freely available and claims to provide ``60\% accuracy on a
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 previous systems can generally be divided into two
classes. Techniques of the first class 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,
which is then displayed at the client. We shall henceforth refer to this
class of techniques as \emph{image generation} techniques. Techniques of the
second class 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{overlay} techniques.

Both classes of techniques have been used in the aforementioned systems,
but the overlay technique appears to have been particularly popular. For
example, Palantir used an overlay technique, where a Java applet running
at the client overlaid graphic elements onto a base map image retrieved
from the now-defunct Xerox online map server
\cite{Papa-N-1998-Palantir}. A more recent example is the Google Maps
API \cite{Goog-M-2006-maps}, which enables web developers to easily
embed dynamic, interactive maps within web pages. Google Maps is a
dynamic overlay technique that has only recently become feasible with
the advent of support for CSS positioning and Ajax technologies in most
browsers.

Overlay techniques enjoy a particular advantage over image generation
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, overlay techniques tend
to rely on more recent web technologies such as CSS2 and Ajax, whereas
image generation techniques generally do not. Image generation techniques
should therefore be portable to a wider range of client and server
environments.

Within each class, there are several alternative approaches to
implementing these techniques. For example, an image generation technique
might be completely server-side or use a mixture of server-side and
client-side processing. Overlay techniques can also 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 of these 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.

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
chosen are discussed in Section~\ref{sec-techniques}. We then set about
testing the scalability of these four techniques, in order to determine
how well each technique handled large numbers of points. A series of
experiments was conducted using 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 intuition was that server-side image generation and server-side
image overlay techniques would prove the most scalable, 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
numbers of points (generally less than about 500--1,000), but their
performance deteriorated rapidly beyond this. The results are discussed
in more detail in Section~\ref{sec-results}.

\section{Technique selection}
\label{sec-techniques}

In this section we discuss in more detail the four techniques that we
chose for testing, and how we decided upon these particular techniques.
First, we discuss the impact of distribution style on the choice of
technique. Then, for each of the four chosen techniques, we examine how
the technique works in practice, its implementation requirements, its
relative advantages and disadvantages, and any other issues peculiar to
the technique.

\subsection{Distribution style}
\label{sec-distribution}

\citeN{Wood-J-1996-vis} and \citeN{MacE-AM-1998-GIS} identified four
distribution styles for web-based geographic visualization software. The
\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 an overlay 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 cient-side software. We can therefore
eliminate Java- or Flash-based data server techniques from
consideration.

\begin{figure}
	\begin{center}
		\begin{tabular}{ccc}
			\includegraphics[scale=1]{data_server}	&
			\qquad	&
			\includegraphics[scale=1]{image_server}	\\
			\footnotesize (a) Data server	&
			\qquad	&
			\footnotesize (b) Image server	\\
			\\
			\\
			\includegraphics[scale=1]{model_interaction}	&
			\qquad	&
			\includegraphics[scale=1]{shared}	\\
			\footnotesize (c) Model interaction environment	&
			\qquad	&
			\footnotesize (d) Shared environment	\\
		\end{tabular}
	\end{center}
	\caption{Distribution styles for web-based geographic visualization
	\protect\cite{Wood-J-1996-vis}. (F = filtering, M = mapping, R =
	rendering.)}
	\label{fig-distribution-styles}
\end{figure}

In contrast, the \emph{image server} style is where the display is
created at entirely the server and is only viewed at the client. In
other words, this is primarily a server-side processing model, as
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 a
simple bitmap image.

The \emph{3D 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). The phrase ``3D model
interaction'' seems slightly out of place in the current context.
\citeN{Wood-J-1996-vis} originally intended this distribution style to
apply to VRML models for GIS applications, but it could be equally
applied to any situation where an interactive model is generated at the
server, then downloaded to and manipulated at the client. This is very
similar to what happens with many Flash-based applications, for example.
A more general name for this style could therefore be \emph{model
interaction environment}. The key distinguishing feature of this style
is that there is no further 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 and downloaded from
the server. Similar restrictions apply to techniques using this style as
with 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 presentl
unclear as to how effective this might be.

% future work: implement model interaction using JavaScript?

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
Figure~\ref{fig-distribution-styles}(d). This is similar to the model
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. This is essentially the distribution style provided by Ajax
technologies [REF]. We can eliminate techniques based on the same criteria
as applied to the other three styles.

\subsection{Image generation techniques}
\label{sec-image-gen}

As noted earlier, image generation 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}
	\begin{center}
		\includegraphics[width=0.95\textwidth,keepaspectratio]{ImageGeneration-full}
	\end{center}
	\caption{Sample output from the server-side image generation technique.}
	\label{fig-image}
\end{figure}

Image generation 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 image generation using an image
server distribution style (or ``server-side image generation'') from
this point on.

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 generated 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 techniques such as JPEG can make
the points plotted on the map appear distinctly fuzzy, as shown in
Figure~\ref{fig-image-quality}. A lossless compression technique 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}
	\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.\ PNG image
	overlay (bottom).}
	\label{fig-image-quality}
\end{figure}

\subsection{Overlay 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).

Overlay techniques also involve plotting points onto a base map image,
but they differ from image generation techniques in that the points are
not plotted directly onto the base map image. Rather, the points are
plotted as an independent overlay on the base map image. This provides a
significant advantage over image generation techniques, as it enables
the possibility of multiple independent overlays 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 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.

Until relatively recently, implementing overlay techniques would likely
have required additional software at the client, but most modern
browsers now support absolute positioning of elements using CSS. This
enables us to create a map overlay using nothing more than HTML, CSS and
a few bitmap images. We have identified two main alternatives for
producing such an overlay, which we have termed \emph{image overlay} and
\emph{HTML overlay}.

An image overlay comprises a transparent bitmap image into which the
points are plotted, which is then overlaid on the base map image (the
output looks essentially identical to that shown in
Figure~\ref{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 be quite small, 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}).
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 this technique. 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
which elements could be used to construct the overlay. One possibility
is to use \verb|<IMG>| elements, which is the approach adopted by Google
Maps (see Figure~\ref{fig-google}). Another possibility is to use
appropriately sized and colored \verb|<DIV>| 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}
	\begin{center}
		\includegraphics[width=0.95\textwidth,keepaspectratio]{GoogleMap-full.png}
	\end{center}
	\caption{Sample output from the Google Maps technique.}
	\label{fig-google}
\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|<IMG>| elements, we have used embedded \verb|<DIV>|
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|<DIV>| 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
map in any direction and zoom in and out to many different levels. 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 next 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 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.)

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.

\section{Experimental design}
\label{sec-experiment}

After some preliminary testing with live data from the Otago School of
Business repository, we proceeded with a series of experiments to test
the scalability of the four techniques. Each technique was tested using
progressively larger synthetic data sets. The first data set comprised
one point at the South Pole (latitude $-90^{\circ}$, longitude
$-180^{\circ}$). Each successive data set was twice the size of its
predecessor, comprising a regular grid of latitude/longitude points at
one degree intervals\footnote{It should be noted that only 64,800 points are
required to fill the entire grid, so the five largest data sets have
many duplicate points.}. A total of twenty-one data sets were created in
this way, with the number of points ranging from one to 1,048,576
($=2^{20}$).

The focus on scalability meant that we were primarily interested in
measuring page load times, memory usage, and the amount of data
generated (which impacts on both storage and network bandwidth). Page
load time can be further broken down into the time taken to generate the
map data, the time taken to transfer the map data to the client across
the network, and the time taken by the client to display the map.

Unfortunately, the Google Maps technique requires an active Internet
connection, so we were unable to run the experiments on an isolated
network. This meant that traffic on the local network could be a
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\,MHz 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 of each other, 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
JavaScript source and images), as the API will be locally cached
thereafter. The API key verification occurs every time the map is
loaded, but the amount of data involved is very small, so it is unlikely
that this would be significantly affected by network performance. Any
such effect would also be immediately obvious as it would simply block
the 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 memory used during the test by both the browser and
the web server. The data set generation time and memory usage were
measured using the \texttt{time} and \texttt{top} utilities
respectively. The map display time was measured using the ``page load
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.

While it is really 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 that the dialog box
``Loading myplaces.kml, including enabled overlays'' was displayed on
screen.

\subsection{Technique implementation}

As noted in Sections~\ref{sec-image-gen} and \ref{sec-overlay}, the
server-side image generation, server-side image overlay and server-side
HTML overlay techniques were all implemented using the image server
distribution style. A separate dispatcher page was written in PHP for
each technique, which enabled passing arguments---such as the number of
points to be plotted---from the client to a corresponding Perl script
for each technique. The final page was then constructed as follows:
\begin{description}

\item[server-side image generation] The Perl script generated a JPEG
	composite map image that was displayed using a standard \verb|<IMG>|
	element.

\item[server-side image overlay] The base map (a JPEG image) was
	displayed using a CSS-positioned \verb|<IMG>| element. The Perl
	script then generated a transparent PNG image, which was displayed
	using an \verb|<IMG>| element with identical positioning attributes
	to the base map.

\item[server-side HTML overlay] The base map (a JPEG image) was
	displayed using a CSS-positioned \verb|<IMG>| element. The Perl
	script then generated a collection of CSS-positioned \verb|<DIV>|
	elements, which were included inline into the source of the
	dispatcher page.

\end{description}

The Google Maps technique was implemented using the shared environment
distribution style. Once again, a PHP dispatcher page was used. This
time, however, the page included client-side JavaScript code to load and
initialise the Google Maps API, create the base map, and build the map
overlay. The first two steps were achieved using standard Google Maps
API calls. For the last step, the client used an \texttt{XMLHttpRequest}
object to call a server-side Perl script. This script generated and
returned to the client an XML data set containing the points to be
plotted. The client then looped through this data set and used Google
Maps API calls to create a marker on the base map corresponding to each
point.

\section{Results}
\label{sec-results}

It is important to note that the intent of these experiments was not to
do a full analysis and statistical comparison of the performance of the
different techniques, but rather to identify broad trends. We have
therefore not carried any statistical analysis of the data.

\subsection{Data size}

The size of the data generated for each technique is shown in
Figure~\ref{fig-data-size}.

\begin{figure}
	\begin{center}
		\includegraphics[scale=0.66]{data_size}
	\end{center}
	\caption{Comparison of generated data size for each technique.}
	\label{fig-data-size}
\end{figure}

\subsection{Page load time}

\begin{figure}
	\begin{center}
		\includegraphics[scale=0.66]{data_generation_time}
	\end{center}
	\caption{Comparison of data generation time for each technique.}
	\label{fig-data-generation-time}
\end{figure}

\begin{figure}
	\begin{center}
		\includegraphics[scale=0.66]{page_load_time}
	\end{center}
	\caption{Comparison of map display time for each technique.}
	\label{fig-page-load-time}
\end{figure}

\begin{figure}
	\begin{center}
		\includegraphics[scale=0.66]{combined_time}
	\end{center}
	\caption{Comparison of combined page load time for each technique.}
	\label{fig-combined-time}
\end{figure}

\subsection{Memory usage}

\begin{figure}
	\begin{center}
		\includegraphics[scale=0.66]{virtual_memory}
	\end{center}
	\caption{Comparison of virtual memory usage for each technique.}
	\label{fig-virtual-memory}
\end{figure}

\section{Conclusion}

% 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

\bibliography{Map_Visualisation}

\begin{received}
...
\end{received}
\end{document}

\documentclass[acmtocl,acmnow]{acmtrans2m}

\usepackage{graphicx}

\markboth{Nigel Stanger}{...}

\bibliographystyle{acmtrans}

\begin{bottomstuff} 
Author's address: N. Stanger, Department of Information Science,
University of Otago, PO Box 56, Dunedin 9054, New Zealand.
\end{bottomstuff}
            
\maketitle

\section{Introduction}
\label{sec-introduction}

We first narrowed down the range of techniques to just four (server-side
image generation, image overlay, server-side HTML overlay and Google
Maps); the selection process and details of the techniques chosen are
discussed in Section~\ref{sec-techniques}. We then set about testing the
scalability of these four techniques, in order to determine how well
each technique handled large numbers of points. A series of experiments
was conducted using 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 intuition was that server-side image generation and image overlay
would prove the most scalable, 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 numbers of points (generally less than
about 500--1,000), but their performance deteriorated rapidly beyond
this. The results are discussed in more detail in
Section~\ref{sec-results}.

\section{Technique selection}
\label{sec-techniques}

\subsection{Distribution style}
\label{sec-distribution}

\citeN{Wood-J-1996-vis} and \citeN{MacE-AM-1998-GIS} identified four
distribution styles for web-based geographic visualization software. The
\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-data-server}. For example, Palantir
implemented an overlay 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 cient-side software. We can therefore
eliminate Java- or Flash-based data server techniques from
consideration.

\begin{narrowfig}{2cm}
	\caption{The data server distribution style
	\protect\cite{Wood-J-1996-vis}. (F = filtering, M = mapping, R =
	rendering.)}
	\label{fig-data-server}
\end{narrowfig}

In contrast, the \emph{image server} style is where the display is
created at entirely the server and is only viewed at the client. In
other words, this is primarily a server-side processing model, as
illustrated in Figure~\ref{fig-image-server}. 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 a
simple bitmap image.

\begin{narrowfig}{2cm}
	\caption{The image server distribution style
	\protect\cite{Wood-J-1996-vis}.}
	\label{fig-image-server}
\end{narrowfig}

The \emph{3D model interaction environment} style is where a model
created at the server can be explored at the client, as illustrated in
Figure~\ref{fig-model-interaction}. The phrase ``3D model interaction''
seems slightly out of place in the current context.
\citeN{Wood-J-1996-vis} originally intended this distribution style to
apply to VRML models for GIS applications, but it could be equally
applied to any situation where an interactive model is generated at the
server, then downloaded to and manipulated at the client. This is very
similar to what happens with many Flash-based applications, for example.
A more general name for this style could therefore be \emph{model
interaction environment}. The key distinguishing feature of this style
is that there is no further 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 and downloaded from
the server. Similar restrictions apply to techniques using this style as
with 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 unclear
as to how effective this might be.

\begin{narrowfig}{2cm}
	\caption{The model interaction environment distribution style
	\protect\cite{Wood-J-1996-vis}.}
	\label{fig-model-interaction}
\end{narrowfig}

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
Figure~\ref{fig-shared-environment}. This is similar to the model
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. This is essentially the distribution style provided by Ajax
technologies [REF]. We can eliminate techniques based on the same criteria
as applied to the other three styles.

\begin{narrowfig}{2cm}
	\caption{The shared environment distribution style
	\protect\cite{Wood-J-1996-vis}.}
	\label{fig-shared-environment}
\end{narrowfig}

\subsection{Image generation techniques}
\label{sec-image-gen}

Image generation techniques could use any of the distribution styles
discussed in Section~\ref{sec-distribution}. However, all but the image
server style would probably require the installation of additional
client-side software for generating images and performing cartographic
projection operations, so we will only consider image generation using
an image servr distribution style (or ``server-side image generation'')
from this point on.

\subsection{Overlay techniques}
\label{sec-html-overlay}

\section{Experimental design}
\label{sec-experiment}

After some preliminary experimentation and testing with live data from
the Otago School of Business repository, we proceeded with a more formal
series of experiments to test the scalability of the three techniques.
Each technique was tested using progressively larger synthetic data
sets. The first data set comprised one point at the South Pole (latitude
$-90^{\circ}$, longitude $-180^{\circ}$). Each successive data set
was twice the size of its predecessor, comprising a regular grid of
latitude/longitude points at one degree intervals. A total of twenty-one
data sets were created in this way, with the number of points ranging
from one to 1,048,576 ($=2^{20}$)\footnote{It should be noted that
only 64,800 points are required to fill the entire grid, so the five
largest data sets have many duplicate points.}.

Our focus on scalability meant that we were primarily interested in
measuring page load times, memory usage, and the amount of data
generated (which impacts on both storage and network bandwidth). The
page load time can be further broken down into the time taken to
generate the map data, the time taken to transfer the map data to the
client across the network, and the time taken by the client to display
the map.

Unfortunately, the Google Maps technique requires an active Internet
connection, so we were unable to run the experiments on an isolated
network. This meant that traffic on the local network could be a
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\,MHz with 1\,GiB
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 of each other, thus simplifying the
process of data collection and also ensuring that the client and server
processes did not impede each other unduly.

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 155\,KiB of
JavaScript source), as the API will be locally cached thereafter. The
API key verification occurs every time the map is loaded, but the amount
of data involved is very small, so it is unlikely that this would be
significantly affected by network performance. Any such effect would
also be immediately obvious as it would simply block the server from
proceeding.

For each data set, we recorded the size of the data set, the time taken
to generate it, the time taken to display the resultant map in the
browser, and the amount of memory used during the test by both the
browser and the web server. The data set generation time and memory
usage were measured using the \texttt{time} and \texttt{top} utilities
respectively. The map display time was measured using the ``page load
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.

%%!! confused!

The image generation technique was implemented as an image server
architecture. A dispatcher page written in PHP called a Perl script,
which generated a JPEG-compressed map image and returned this to the
browser.

The HTML overlay technique was implemented in two ways:
\begin{itemize}

\item as an image server architecture that worked in much the same way
	as the image generation technique, except that the Perl script
	returned an HTML file containing the \verb|<DIV>| elements for the
	overlay, and an \verb|<IMG>| element to load the base map image; and
	
	\item as a shared environment architecture, where client-side
	JavaScript code made an asynchronous call to the server-side Perl
	script, which returned

\end{itemize}

and Google Maps techniques were implemented as an image server and a
shared environment architecture respectively. The HTML overlay technique
was implemented twice; once as an image server architecture and once as
a shared environment architecture.

\section{Results}
\label{sec-results}

\subsection{Data size}

\subsection{Display time}

\subsection{Memory usage}

\section{Conclusion}

% 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

\bibliography{Map_Visualisation}

\begin{received}
...
\end{received}
\end{document}

Ignore Space Show notes View chunk_logstubs 0 → 100755
.001 .001 .01 .01 .1 .1 1 1 10 10 100 100 1000 1000 10000 10000 100000 100000 1000000 1000000

Ignore Space Show notes View chunk_logtics 0 → 100755
.002 .003 .004 .005 .006 .007 .008 .009 .02 .03 .04 .05 .06 .07 .08 .09 .2 .3 .4 .5 .6 .7 .8 .9 2 3 4 5 6 7 8 9 20 30 40 50 60 70 80 90 200 300 400 500 600 700 800 900 2000 3000 4000 5000 6000 7000 8000 9000 20000 30000 40000 50000 60000 70000 80000 90000 200000 300000 400000 500000 600000 700000 800000 900000

Ignore Space Show notes View d_combined_time.txt
points,image_gen,image_overlay,html_overlay,google_maps,google_earth 1,0.37225,0.3029,0.14845,1.2851,2.40255 2,0.34105,0.3003,0.1494,1.1398,2.1525 4,0.3532,0.31365,0.15095,1.18335,2.2523 8,0.387,0.30875,0.1433,1.16855,2.2526 16,0.3859,0.29765,0.1562,1.18835,2.403 32,0.31675,0.30315,0.1716,1.34745,2.153 64,0.32795,0.29355,0.15865,1.5299,2.553 128,0.31635,0.30895,0.168,2.24245,2.6034 256,0.32965,0.2972,0.19645,4.16945,2.704 512,0.33115,0.3032,0.3077,9.96335,2.5052 1024,0.34415,0.3335,0.66925,40.8237,2.65765 2048,0.35665,0.333,1.4398,149.11635,2.512 4096,0.4027,0.3949,5.54,435.011,3.0945 8192,0.47435,0.46615,24.9883,,4.745 16384,0.6901,0.61575,114.613,,10.9505 32768,0.9468,0.9045,598.048,,38.0665 65536,1.5084,1.5052,,,144.4265 131072,2.6988,2.66485,,,577.2625 262144,5.1429,4.9853,,, 524288,9.8968,9.67975,,, 1048576,19.5586,18.97765,,, points,image_gen,image_overlay,html_overlay,google_maps,google_earth 1,0.37225,0.14845,0.3029,1.2851,2.40255 2,0.34105,0.1494,0.3003,1.1398,2.1525 4,0.3532,0.15095,0.31365,1.18335,2.2523 8,0.387,0.1433,0.30875,1.16855,2.2526 16,0.3859,0.1562,0.29765,1.18835,2.403 32,0.31675,0.1716,0.30315,1.34745,2.153 64,0.32795,0.15865,0.29355,1.5299,2.553 128,0.31635,0.168,0.30895,2.24245,2.6034 256,0.32965,0.19645,0.2972,4.16945,2.704 512,0.33115,0.3077,0.3032,9.96335,2.5052 1024,0.34415,0.66925,0.3335,40.8237,2.65765 2048,0.35665,1.4398,0.333,149.11635,2.512 4096,0.4027,5.54,0.3949,435.011,3.0945 8192,0.47435,24.9883,0.46615,,4.745 16384,0.6901,114.613,0.61575,,10.9505 32768,0.9468,598.048,0.9045,,38.0665 65536,1.5084,,1.5052,,144.4265 131072,2.6988,,2.66485,,577.2625 262144,5.1429,,4.9853,, 524288,9.8968,,9.67975,, 1048576,19.5586,,18.97765,,

Ignore Space Show notes View

d_combined_time.txt

Ignore Space Show notes View d_data_generation_time.txt
points,image_gen,image_overlay,html_overlay,google_maps,google_earth 1,0.2765,0.1645,0.0425,0.00205,0.00255 2,0.234,0.161,0.045,0.002,0.0025 4,0.265,0.17,0.048,0.00205,0.0023 8,0.2975,0.173,0.043,0.002,0.0026 16,0.294,0.157,0.045,0.00205,0.003 32,0.2285,0.162,0.0515,0.002,0.003 64,0.2385,0.1555,0.048,0.00215,0.003 128,0.23,0.17,0.049,0.00275,0.0034 256,0.241,0.1615,0.049,0.003,0.004 512,0.2415,0.1695,0.063,0.00305,0.0052 1024,0.2565,0.1935,0.067,0.0044,0.00765 2048,0.265,0.199,0.1065,0.007,0.012 4096,0.312,0.2615,0.1595,0.011,0.0445 8192,0.3815,0.33,0.2015,0.0275,0.095 16384,0.599,0.477,0.3475,0.0445,0.1505 32768,0.857,0.762,0.953,0.1115,0.2165 65536,1.4205,1.3615,1.962,0.1795,0.4265 131072,2.61,2.5295,3.557,0.559,1.2625 262144,5.052,4.8425,6.084,0.865,2.508 524288,9.8095,9.545,10.671,1.9315,4.102 1048576,19.4725,18.839,21.8175,3.4455,7.701 points,image_gen,image_overlay,html_overlay,google_maps,google_earth 1,0.2765,0.0425,0.1645,0.00205,0.00255 2,0.234,0.045,0.161,0.002,0.0025 4,0.265,0.048,0.17,0.00205,0.0023 8,0.2975,0.043,0.173,0.002,0.0026 16,0.294,0.045,0.157,0.00205,0.003 32,0.2285,0.0515,0.162,0.002,0.003 64,0.2385,0.048,0.1555,0.00215,0.003 128,0.23,0.049,0.17,0.00275,0.0034 256,0.241,0.049,0.1615,0.003,0.004 512,0.2415,0.063,0.1695,0.00305,0.0052 1024,0.2565,0.067,0.1935,0.0044,0.00765 2048,0.265,0.1065,0.199,0.007,0.012 4096,0.312,0.1595,0.2615,0.011,0.0445 8192,0.3815,0.2015,0.33,0.0275,0.095 16384,0.599,0.3475,0.477,0.0445,0.1505 32768,0.857,0.953,0.762,0.1115,0.2165 65536,1.4205,1.962,1.3615,0.1795,0.4265 131072,2.61,3.557,2.5295,0.559,1.2625 262144,5.052,6.084,4.8425,0.865,2.508 524288,9.8095,10.671,9.545,1.9315,4.102 1048576,19.4725,21.8175,18.839,3.4455,7.701

Ignore Space Show notes View

d_data_generation_time.txt

Ignore Space Show notes View d_data_size.txt
points,image_gen,image_overlay,html_overlay,google_maps,google_earth 1,180.941,181.164,181.108,235.041,0.32 2,180.969,181.17,181.219,235.074,0.508 4,180.997,181.183,181.441,235.14,0.884 8,181.123,181.203,181.885,235.272,1.636 16,181.347,181.25,182.773,235.536,3.141 32,181.724,181.323,184.549,236.064,6.149 64,182.348,181.44,188.101,237.12,12.165 128,183.254,181.632,195.205,239.175,24.084 256,184.427,181.84,209.365,243.346,47.166 512,184.853,181.86,237.734,251.605,91.868 1024,185.045,181.88,294.533,268.202,181.455 2048,187.255,182.636,407.949,301.382,360.599 4096,188.337,182.726,633.395,367.713,718.805 8192,185.19,182.814,1085.281,500.394,1435.279 16384,176.114,182.993,1992.42,764.04,2864.772 32768,150.295,182.676,3806.676,1276.33,5693.776 65536,95.201,182.245,7435.236,2285.657,11325.598 131072,95.201,182.245,14689.475,4336.306,22648.889 262144,95.201,182.245,29197.989,8437.604,45295.469 524288,95.201,182.245,58215.171,16640.159,90588.547 1048576,95.201,182.245,116248.172,33045.282,181174.754 points,image_gen,image_overlay,html_overlay,google_maps,google_earth 1,180.941,181.108,181.164,235.041,0.32 2,180.969,181.219,181.17,235.074,0.508 4,180.997,181.441,181.183,235.14,0.884 8,181.123,181.885,181.203,235.272,1.636 16,181.347,182.773,181.25,235.536,3.141 32,181.724,184.549,181.323,236.064,6.149 64,182.348,188.101,181.44,237.12,12.165 128,183.254,195.205,181.632,239.175,24.084 256,184.427,209.365,181.84,243.346,47.166 512,184.853,237.734,181.86,251.605,91.868 1024,185.045,294.533,181.88,268.202,181.455 2048,187.255,407.949,182.636,301.382,360.599 4096,188.337,633.395,182.726,367.713,718.805 8192,185.19,1085.281,182.814,500.394,1435.279 16384,176.114,1992.42,182.993,764.04,2864.772 32768,150.295,3806.676,182.676,1276.33,5693.776 65536,95.201,7435.236,182.245,2285.657,11325.598 131072,95.201,14689.475,182.245,4336.306,22648.889 262144,95.201,29197.989,182.245,8437.604,45295.469 524288,95.201,58215.171,182.245,16640.159,90588.547 1048576,95.201,116248.172,182.245,33045.282,181174.754

Ignore Space Show notes View

d_data_size.txt

points,image_gen,image_overlay,html_overlay,google_maps,google_earth
1,180.941,181.164,181.108,235.041,0.32
2,180.969,181.17,181.219,235.074,0.508
4,180.997,181.183,181.441,235.14,0.884
8,181.123,181.203,181.885,235.272,1.636
16,181.347,181.25,182.773,235.536,3.141
32,181.724,181.323,184.549,236.064,6.149
64,182.348,181.44,188.101,237.12,12.165
128,183.254,181.632,195.205,239.175,24.084
256,184.427,181.84,209.365,243.346,47.166
512,184.853,181.86,237.734,251.605,91.868
1024,185.045,181.88,294.533,268.202,181.455
2048,187.255,182.636,407.949,301.382,360.599
4096,188.337,182.726,633.395,367.713,718.805
8192,185.19,182.814,1085.281,500.394,1435.279
16384,176.114,182.993,1992.42,764.04,2864.772
32768,150.295,182.676,3806.676,1276.33,5693.776
65536,95.201,182.245,7435.236,2285.657,11325.598
131072,95.201,182.245,14689.475,4336.306,22648.889
262144,95.201,182.245,29197.989,8437.604,45295.469
524288,95.201,182.245,58215.171,16640.159,90588.547
1048576,95.201,182.245,116248.172,33045.282,181174.754

points,image_gen,image_overlay,html_overlay,google_maps,google_earth
1,180.941,181.108,181.164,235.041,0.32
2,180.969,181.219,181.17,235.074,0.508
4,180.997,181.441,181.183,235.14,0.884
8,181.123,181.885,181.203,235.272,1.636
16,181.347,182.773,181.25,235.536,3.141
32,181.724,184.549,181.323,236.064,6.149
64,182.348,188.101,181.44,237.12,12.165
128,183.254,195.205,181.632,239.175,24.084
256,184.427,209.365,181.84,243.346,47.166
512,184.853,237.734,181.86,251.605,91.868
1024,185.045,294.533,181.88,268.202,181.455
2048,187.255,407.949,182.636,301.382,360.599
4096,188.337,633.395,182.726,367.713,718.805
8192,185.19,1085.281,182.814,500.394,1435.279
16384,176.114,1992.42,182.993,764.04,2864.772
32768,150.295,3806.676,182.676,1276.33,5693.776
65536,95.201,7435.236,182.245,2285.657,11325.598
131072,95.201,14689.475,182.245,4336.306,22648.889
262144,95.201,29197.989,182.245,8437.604,45295.469
524288,95.201,58215.171,182.245,16640.159,90588.547
1048576,95.201,116248.172,182.245,33045.282,181174.754

Ignore Space Show notes View d_page_load_time.txt
points,image_gen,image_overlay,html_overlay,google_maps,google_earth 1,0.09575,0.1384,0.10595,1.28305,2.4 2,0.10705,0.1393,0.1044,1.1378,2.15 4,0.0882,0.14365,0.10295,1.1813,2.25 8,0.0895,0.13575,0.1003,1.16655,2.25 16,0.0919,0.14065,0.1112,1.1863,2.4 32,0.08825,0.14115,0.1201,1.34545,2.15 64,0.08945,0.13805,0.11065,1.52775,2.55 128,0.08635,0.13895,0.119,2.2397,2.6 256,0.08865,0.1357,0.14745,4.16645,2.7 512,0.08965,0.1337,0.2447,9.9603,2.5 1024,0.08765,0.14,0.60225,40.8193,2.65 2048,0.09165,0.134,1.3333,149.10935,2.5 4096,0.0907,0.1334,5.3805,435,3.05 8192,0.09285,0.13615,24.7868,,4.65 16384,0.0911,0.13875,114.2655,,10.8 32768,0.0898,0.1425,597.095,,37.85 65536,0.0879,0.1437,,,144 131072,0.0888,0.13535,,,576 262144,0.0909,0.1428,,, 524288,0.0873,0.13475,,, 1048576,0.0861,0.13865,,, points,image_gen,image_overlay,html_overlay,google_maps,google_earth 1,0.09575,0.10595,0.1384,1.28305,2.4 2,0.10705,0.1044,0.1393,1.1378,2.15 4,0.0882,0.10295,0.14365,1.1813,2.25 8,0.0895,0.1003,0.13575,1.16655,2.25 16,0.0919,0.1112,0.14065,1.1863,2.4 32,0.08825,0.1201,0.14115,1.34545,2.15 64,0.08945,0.11065,0.13805,1.52775,2.55 128,0.08635,0.119,0.13895,2.2397,2.6 256,0.08865,0.14745,0.1357,4.16645,2.7 512,0.08965,0.2447,0.1337,9.9603,2.5 1024,0.08765,0.60225,0.14,40.8193,2.65 2048,0.09165,1.3333,0.134,149.10935,2.5 4096,0.0907,5.3805,0.1334,435,3.05 8192,0.09285,24.7868,0.13615,,4.65 16384,0.0911,114.2655,0.13875,,10.8 32768,0.0898,597.095,0.1425,,37.85 65536,0.0879,,0.1437,,144 131072,0.0888,,0.13535,,576 262144,0.0909,,0.1428,, 524288,0.0873,,0.13475,, 1048576,0.0861,,0.13865,,

Ignore Space Show notes View

d_page_load_time.txt

Ignore Space Show notes View d_real_memory.txt
points,image_gen,image_overlay,html_overlay,google_maps,google_earth 1,24.8,16.5,16.4,37.4,118 2,24.8,16.2,16.6,37.9,112 4,25.4,17.3,18.1,38.1,119 8,23.2,16.3,17.5,38.4,117 16,23.7,16.3,16.8,38,112 32,23.9,15.4,19.7,38.2,120 64,26.8,16.4,18.3,38.8,111 128,23.7,16.3,18.4,40.2,117 256,24.6,16.4,17.5,42.7,110 512,24.5,16.3,16.4,48.7,114 1024,27.3,16.3,17.1,60.2,112 2048,25.9,16.4,32.3,82.6,115 4096,25.9,16.2,34.4,129,123 8192,25.9,16.3,30.3,,118 16384,24.1,16.4,41.5,,166 32768,24.4,16.3,62.1,,197 65536,26.1,16.3,,,244 131072,25.7,16.4,,, 262144,25.4,17.3,,, 524288,24.3,16.4,,, 1048576,27.2,16.4,,, points,image_gen,image_overlay,html_overlay,google_maps,google_earth 1,24.8,16.4,16.5,37.4,118 2,24.8,16.6,16.2,37.9,112 4,25.4,18.1,17.3,38.1,119 8,23.2,17.5,16.3,38.4,117 16,23.7,16.8,16.3,38,112 32,23.9,19.7,15.4,38.2,120 64,26.8,18.3,16.4,38.8,111 128,23.7,18.4,16.3,40.2,117 256,24.6,17.5,16.4,42.7,110 512,24.5,16.4,16.3,48.7,114 1024,27.3,17.1,16.3,60.2,112 2048,25.9,32.3,16.4,82.6,115 4096,25.9,34.4,16.2,129,123 8192,25.9,30.3,16.3,,118 16384,24.1,41.5,16.4,,166 32768,24.4,62.1,16.3,,197 65536,26.1,,16.3,,244 131072,25.7,,16.4,, 262144,25.4,,17.3,, 524288,24.3,,16.4,, 1048576,27.2,,16.4,,

Ignore Space Show notes View

d_real_memory.txt

Ignore Space Show notes View d_virtual_memory.txt
points,image_gen,image_overlay,html_overlay,google_maps,google_earth 1,168,169,167,173,426 2,168,169,167,173,425 4,167,169,169,173,422 8,167,169,169,173,421 16,168,169,167,173,428 32,168,167,169,173,426 64,168,170,169,173,427 128,168,169,169,176,423 256,168,169,169,178,426 512,168,169,169,184,431 1024,168,169,169,195,425 2048,168,169,170,219,435 4096,168,167,173,264,451 8192,168,169,179,,465 16384,169,169,190,,568 32768,169,169,216,,560 65536,169,169,,,823 131072,169,169,,, 262144,169,169,,, 524288,169,169,,, 1048576,169,169,,, points,image_gen,image_overlay,html_overlay,google_maps,google_earth 1,168,167,169,173,426 2,168,167,169,173,425 4,167,169,169,173,422 8,167,169,169,173,421 16,168,167,169,173,428 32,168,169,167,173,426 64,168,169,170,173,427 128,168,169,169,176,423 256,168,169,169,178,426 512,168,169,169,184,431 1024,168,169,169,195,425 2048,168,170,169,219,435 4096,168,173,167,264,451 8192,168,179,169,,465 16384,169,190,169,,568 32768,169,216,169,,560 65536,169,,169,,823 131072,169,,169,, 262144,169,,169,, 524288,169,,169,, 1048576,169,,169,,

Ignore Space Show notes View

d_virtual_memory.txt

Ignore Space Show notes View data_server.svg 0 → 100755

Ignore Space Show notes View image_server.svg 0 → 100755

Ignore Space Show notes View lineplot.plo
#musthave infile #musthave title #musthave ytitle #musthave ymin #musthave ymax #proc settings units: cm #endproc #proc getdata delim: comma fieldnameheader: yes file: @infile #proc areadef // title: @title // titledetails: size=10 style=B align=C areaname: standard xscaletype: log yscaletype: log xrange: 1 2000000 yrange: @ymin @ymax // autowidth: 0.33 // autoheight: 0.66 #proc xaxis: selflocatingstubs: text #include chunk_logstubs stubdetails: size=10 label: Number of points labeldetails: style=B size=10 adjust=0,-0.1 ticlen: 0.25 #proc xaxis: axisline: none selflocatingstubs: text #include chunk_logtics ticlen: 0.1 #proc yaxis: selflocatingstubs: text #include chunk_logstubs stubformat: %2.1f stubdetails: size=10 label: @ytitle labeldetails: style=B size=10 adjust=-0.3,0 grid: color=gray(0.7) ticlen: 0.25 #proc yaxis: axisline: none selflocatingstubs: text #include chunk_logtics ticlen: 0.1 #proc lineplot xfield: points yfield: google_earth pointsymbol: shape=circle linecolor=black fillcolor=white legendlabel: Google Earth legendsampletype: line+symbol #proc lineplot xfield: points yfield: google_maps pointsymbol: shape=triangle linecolor=black fillcolor=white legendlabel: Google Maps legendsampletype: line+symbol #proc lineplot xfield: points yfield: image_overlay pointsymbol: shape=square style=spokes linecolor=black legendlabel: Image overlay legendsampletype: line+symbol #proc lineplot xfield: points yfield: html_overlay pointsymbol: shape=square linecolor=black fillcolor=white legendlabel: HTML overlay legendsampletype: line+symbol #proc lineplot xfield: points yfield: image_gen pointsymbol: shape=diamond linecolor=black fillcolor=white legendlabel: Image generation legendsampletype: line+symbol #proc legend format: multiline location: max-3.5 min+3 textdetails: size=10 seglen: 0.25 reverseorder: yes #musthave infile #musthave title //#musthave field2 //#musthave label1 //#musthave label2 #proc settings units: cm #endproc #proc getdata delim: comma fieldnameheader: yes file: @infile #proc areadef title: @title titledetails: size=10 style=B align=C areaname: standard xscaletype: log yscaletype: log xautorange: datafield=points yautorange: datafield=image_gen,image_overlay,html_overlay,google_maps,google_earth // yrange: 1 4.25 // xrange: 0.5 6.5 // autowidth: 0.33 // autoheight: 0.66 #proc yaxis: stubs: datafields=image_gen,image_overlay,html_overlay,google_maps,google_earth stubformat: %2.1f stubdetails: size=10 stubcull: yes label: Time (s) labeldetails: style=B size=10 adjust=-0.1,0 grid: color=gray(0.7) #proc xaxis: stubs: datafields=points stubdetails: size=10 stubcull: yes label: Number of points labeldetails: style=B size=10 adjust=0,-0.1 //adjust=-0.1,0 #proc lineplot xfield: points yfield: image_gen //linedetails: color=black pointsymbol: shape=diamond linecolor=black fillcolor=black legendlabel: Image generation legendsampletype: line+symbol #proc lineplot xfield: points yfield: image_overlay //linedetails: color=gray(0.25) //pointsymbol: shape=square linecolor=gray(0.25) fillcolor=gray(0.25) pointsymbol: shape=square linecolor=black fillcolor=black legendlabel: Image overlay legendsampletype: line+symbol #proc lineplot xfield: points yfield: html_overlay //linedetails: color=gray(0.25) //pointsymbol: shape=square linecolor=gray(0.25) fillcolor=gray(0.25) pointsymbol: shape=square style=spokes linecolor=black legendlabel: HTML overlay legendsampletype: line+symbol #proc lineplot xfield: points yfield: google_maps //linedetails: color=gray(0.25) //pointsymbol: shape=square linecolor=gray(0.25) fillcolor=gray(0.25) pointsymbol: shape=triangle linecolor=black fillcolor=black legendlabel: Google Maps legendsampletype: line+symbol #proc lineplot xfield: points yfield: google_earth //linedetails: color=gray(0.25) //pointsymbol: shape=square linecolor=gray(0.25) fillcolor=gray(0.25) pointsymbol: shape=circle linecolor=black fillcolor=black legendlabel: Google Earth legendsampletype: line+symbol #proc legend format: multiline location: max-1.2 max-0.3 textdetails: size=10 seglen: 0.25 reverseorder: yes

Ignore Space Show notes View

lineplot.plo

#musthave infile
#musthave title
#musthave ytitle
#musthave ymin
#musthave ymax

#proc settings
	units: cm
#endproc

#proc getdata
	delim: comma
	fieldnameheader: yes
	file: @infile

#proc areadef
//	title: @title
//	titledetails: size=10 style=B align=C
	areaname: standard
	xscaletype: log
	yscaletype: log
	xrange: 1 2000000
	yrange: @ymin @ymax
//	autowidth: 0.33
//	autoheight: 0.66

#proc xaxis:
	selflocatingstubs: text
		#include chunk_logstubs
	stubdetails: size=10
	label: Number of points
	labeldetails: style=B size=10 adjust=0,-0.1
	ticlen: 0.25

#proc xaxis:
	axisline: none
	selflocatingstubs: text
		#include chunk_logtics
	ticlen: 0.1

#proc yaxis:
	selflocatingstubs: text
		#include chunk_logstubs
	stubformat: %2.1f
	stubdetails: size=10
	label: @ytitle
	labeldetails: style=B size=10 adjust=-0.3,0
	grid: color=gray(0.7)
	ticlen: 0.25

#proc yaxis:
	axisline: none
	selflocatingstubs: text
		#include chunk_logtics
	ticlen: 0.1

#proc lineplot
	xfield: points
	yfield: google_earth
	pointsymbol: shape=circle linecolor=black fillcolor=white
	legendlabel: Google Earth
	legendsampletype: line+symbol

#proc lineplot
	xfield: points
	yfield: google_maps
	pointsymbol: shape=triangle linecolor=black fillcolor=white
	legendlabel: Google Maps
	legendsampletype: line+symbol

#proc lineplot
	xfield: points
	yfield: image_overlay
	pointsymbol: shape=square style=spokes linecolor=black
	legendlabel: Image overlay
	legendsampletype: line+symbol

#proc lineplot
	xfield: points
	yfield: html_overlay
	pointsymbol: shape=square linecolor=black fillcolor=white
	legendlabel: HTML overlay
	legendsampletype: line+symbol

#proc lineplot
	xfield: points
	yfield: image_gen
	pointsymbol: shape=diamond linecolor=black fillcolor=white
	legendlabel: Image generation
	legendsampletype: line+symbol

#proc legend
	format: multiline
	location: max-3.5 min+3
	textdetails: size=10
	seglen: 0.25
	reverseorder: yes

#musthave infile
#musthave title
//#musthave field2
//#musthave label1
//#musthave label2

#proc settings
	units: cm
#endproc

#proc getdata
	delim: comma
	fieldnameheader: yes
	file: @infile

#proc areadef
	title: @title
	titledetails: size=10 style=B align=C
	areaname: standard
	xscaletype: log
	yscaletype: log
	xautorange: datafield=points
	yautorange: datafield=image_gen,image_overlay,html_overlay,google_maps,google_earth
//	yrange: 1 4.25
//	xrange: 0.5 6.5
//	autowidth: 0.33
//	autoheight: 0.66

#proc yaxis:
	stubs: datafields=image_gen,image_overlay,html_overlay,google_maps,google_earth
	stubformat: %2.1f
	stubdetails: size=10
	stubcull: yes
	label: Time (s)
	labeldetails: style=B size=10 adjust=-0.1,0
	grid: color=gray(0.7)

#proc xaxis:
	stubs: datafields=points
	stubdetails: size=10
	stubcull: yes
	label: Number of points
	labeldetails: style=B size=10 adjust=0,-0.1
	//adjust=-0.1,0

#proc lineplot
	xfield: points
	yfield: image_gen
	//linedetails: color=black
	pointsymbol: shape=diamond linecolor=black fillcolor=black
	legendlabel: Image generation
	legendsampletype: line+symbol

#proc lineplot
	xfield: points
	yfield: image_overlay
	//linedetails: color=gray(0.25)
	//pointsymbol: shape=square linecolor=gray(0.25) fillcolor=gray(0.25)
	pointsymbol: shape=square linecolor=black fillcolor=black
	legendlabel: Image overlay
	legendsampletype: line+symbol

#proc lineplot
	xfield: points
	yfield: html_overlay
	//linedetails: color=gray(0.25)
	//pointsymbol: shape=square linecolor=gray(0.25) fillcolor=gray(0.25)
	pointsymbol: shape=square style=spokes linecolor=black
	legendlabel: HTML overlay
	legendsampletype: line+symbol

#proc lineplot
	xfield: points
	yfield: google_maps
	//linedetails: color=gray(0.25)
	//pointsymbol: shape=square linecolor=gray(0.25) fillcolor=gray(0.25)
	pointsymbol: shape=triangle linecolor=black fillcolor=black
	legendlabel: Google Maps
	legendsampletype: line+symbol

#proc lineplot
	xfield: points
	yfield: google_earth
	//linedetails: color=gray(0.25)
	//pointsymbol: shape=square linecolor=gray(0.25) fillcolor=gray(0.25)
	pointsymbol: shape=circle linecolor=black fillcolor=black
	legendlabel: Google Earth
	legendsampletype: line+symbol

#proc legend
	format: multiline
	location: max-1.2 max-0.3
	textdetails: size=10
	seglen: 0.25
	reverseorder: yes

Ignore Space Show notes View model_interaction.svg 0 → 100755

Ignore Space Show notes View shared.svg 0 → 100755

Show line notes below