Pull requests - nigel.stanger/Publications

nigel.stanger / Publications

...

21 commits

34 files changed

0 commit comments

2 contributors

Commits on 2017-05-30

Nigel Stanger

• Moved files in preparation for repository merge.

f88c3e8

Commits on 2013-05-06

Nigel Stanger

- Fixed file permissions. - Added some missing files. - Added .gitignore.

ac695d9

Commits on 2006-08-22

nstanger

- Various minor tweaks. - Moved Table II into the conclusions. - Fixed capitalisation of Dodge & Kitchin.

41a6885

Commits on 2006-08-19

nstanger

- Changed y-axis title of memory plots. - Ran through US spell-checker and fixed a few words. - Removed obsolete commented-out material. - Reformatted fixed overhead table. - Added maximum values for virtual memory usage. - Tweaked many other bits and pieces.

508ea22

Commits on 2006-08-18

nstanger

- Removed the remaining first person phrasing.

ad78b3a

Commits on 2006-08-17

nstanger	- Fixed some first person stuff that George doesn't like :)	d2eed22
nstanger	- Added two more references. - Made some adjustments per suggestions by George.	66dfaf5

Commits on 2006-08-12

nstanger	- Cropped Google Maps image. - Rearranged order of lines on plots. - Finished conclusion. - Added acknowledgements. - Shrank all images to save space. - Tweaked various minor bits of wording. - Removed acmtocl document class option. - Added more keywords. - Changed "single layer" to "single-layer". - Noted that Google Maps is a JavaSript-based data server technique. - Removed Google Earth experiments and results; added mention in conclusion. - Discussed performance divergence points (+ table).	4607c24
nstanger	- Removed Google Earth data and reformatted plots.	632a453

Commits on 2006-08-08

nstanger

- Added 16384-point figure image. - Changed base map image to provide greater contrast. - Added discussion of remaining results. - Added first part of conclusion. - Changed technique classification and cleaned up terminology.

6a2e2ae

Commits on 2006-08-07

nstanger	- Added references on Ajax, GIS web services and debugging distributed systems. - Cleaned up centering of figures. - Added table listing fixed overheads. - Added discussion of data size results.	b53792c
nstanger	- Added CIA World Factbook. - Revamped details of how the techniques were implemented. - Restored real memory chart.	d68e502
nstanger	- Updated abstract. - Corrected distribution style for Google Maps. - Rewrote various bits across the whole paper. - Added some results text. - Added figure for example of a plotted data set (image to come).	f240247

Commits on 2006-08-04

nstanger

- 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.

46a1b59

Commits on 2006-08-03

nstanger	- Updated data values.	2ab5026
nstanger	- Added initial files for ploticus charts.	c17e81d

Commits on 2006-07-29

nstanger

- Finished rewriting section 2.

8ef7e74

Commits on 2006-07-28

nstanger

- Rearranged images. - Added makefile. - Rewrote earlier sections. - Removed what are now automatically generated images.

27e7b25

Commits on 2006-07-24

nstanger	- Added MacEachren & Wood references. - Changed architecture terminology to match MacEachran. - Added further justification for interactivity. - Fixed broken itemize.	e41439a
nstanger	- Added more references.	478abb3
nstanger	- Added more references and experimental design stuff. - Added note about DataCrossing software to check out.	da0c077

Patch

Showing 34 changed files

Show notes View GoogleMap-full.png 100755 → 0

Show notes View ImageGeneration-full.png 100755 → 0

Show notes View Map_Visualisation.bib 100755 → 0
This file was created with JabRef 2.1 beta. Encoding: ISO8859_1 @STRING{acj = {Australian Computer Journal}} @STRING{adt = {Application Development Trends}} @STRING{ai = {Artificial Intelligence}} @STRING{ajis = {Australian Journal of Information Systems}} @STRING{cacm = {Communications of the ACM}} @STRING{cj = {The Computer Journal}} @STRING{database = {ACM SIGMIS Database}} @STRING{dbms = {DBMS Magazine}} @STRING{dbpd = {Database Programming {\&} Design}} @STRING{develop = {{d}evelop, The Apple Technical Journal}} @STRING{directions = {Apple Directions}} @STRING{dke = {Data {\&} Knowledge Engineering}} @STRING{ejis = {European Journal of Information Systems}} @STRING{idt = {Internet Development Trends}} @STRING{ijast = {International Journal of Applied Software Technology}} @STRING{ijgis = {International Journal of Geographical Information Systems}} @STRING{ijhcs = {International Journal of Human-Computer Studies}} @STRING{ijmms = {International Journal of Man-Machine Studies}} @STRING{ijseke = {International Journal of Software Engineering and Knowledge Engineering}} @STRING{is = {Information Systems}} @STRING{isj = {Information Systems Journal}} @STRING{ist = {Information and Software Technology}} @STRING{jacm = {Journal of the ACM}} @STRING{jlp = {Journal of Logic Programming}} @STRING{jot = {Journal of Object Technology}} @STRING{jss = {Journal of Systems and Software}} @STRING{lncs = {Lecture Notes in Computer Science}} @STRING{misq = {MIS Quarterly}} @STRING{nzjc = {New Zealand Journal of Computing}} @STRING{nzjis = {New Zealand Journal of Information Systems}} @STRING{oracle = {Oracle Magazine}} @STRING{reg = {\scriptsize\textsuperscript{\textregistered}}} @STRING{sej = {Software Engineering Journal}} @STRING{sigmod = {ACM SIGMOD Record}} @STRING{spe = {Software---Practice and Experience}} @STRING{surveys = {ACM Computing Surveys}} @STRING{tkde = {IEEE Transactions on Knowledge and Data Engineering}} @STRING{tm = {\scriptsize\texttrademark}} @STRING{tods = {ACM Transactions on Database Systems}} @STRING{toit = {ACM Transactions on Internet Technology}} @STRING{tose = {IEEE Transactions on Software Engineering}} @STRING{tweb = {ACM Transactions on the Web}} @STRING{vldb = {The VLDB Journal}} @INCOLLECTION{Beau-JR-1991-GIS, author = {J.\ R.\ Beaumont}, title = {{GIS} and market analysis}, booktitle = {Geographical Information Systems, Volume 2: Applications}, publisher = {Longman}, year = {1991}, editor = {David J.\ Maguire and Michael F.\ Goodkind and David W.\ Rhind}, chapter = {45}, pages = {139--151}, address = {Harlow, UK}, timestamp = {2006.07.11} } @BOOK{Dodg-M-2001-cybermap, title = {Mapping cyberspace}, publisher = {Routledge}, year = {2001}, author = {Martin Dodge and Rob Kitchin}, address = {London, UK}, timestamp = {2006.07.04} } @MISC{IP2L-C-2006-GeoIP, author = {{IP2Location.com}}, title = {{IP2L}ocation} # tm # {: {B}ringing geography to the {I}nternet}, howpublished = {Web site}, month = jul, year = {2006}, note = {Accessed on 18 July 2006.}, timestamp = {2006.07.18}, url = {http://www.ip2location.com/} } @ARTICLE{Lamm-SE-1996-webvis, author = {Stephen E.\ Lamm and Daniel A.\ Reed and Will H.\ Scullin}, title = {Real-time geographic visualization of {W}orld {W}ide {W}eb traffic}, journal = {Computer Networks and ISDN Systems}, year = {1996}, volume = {28}, pages = {1457--1468}, number = {7--11}, month = may, doi = {doi:10.1016/0169-7552(96)00055-4}, pdf = {L/Lamm-SE-1996-webvis.pdf}, timestamp = {2006.07.18} } @MISC{Maxm-G-2006-GeoIP, author = {{Maxmind LLC}}, title = {Geo{IP}: {IP} address location technology}, howpublished = {Web site}, month = jul, year = {2006}, note = {Accessed on 18 July 2006.}, timestamp = {2006.07.18}, url = {http://www.maxmind.com/app/ip-location} } @MISC{Maxm-G-2006-GeoLiteCity, author = {{Maxmind LLC}}, title = {Geo{L}ite {C}ity: Free {IP} address to city database}, howpublished = {Web site}, month = jul, year = {2006}, note = {Accessed on 18 July 2006.}, timestamp = {2006.07.18}, url = {http://www.maxmind.com/app/geolitecity} } @INPROCEEDINGS{Papa-N-1998-Palantir, author = {Nektarios Papadakakis and Evangelos P.\ Markatos and Athanasios E.\ Papathanasiou}, title = {Palantir: {A} visualization tool for the {W}orld {W}ide {W}eb}, booktitle = {Proceedings of the INET'98 Conference}, year = {1998}, address = {Geneva, Switzerland}, month = {21--24~} # jul, citeseerurl = {http://citeseer.ist.psu.edu/68932.html}, pdf = {P/Papa-N-1998-Palantir.pdf}, timestamp = {2006.07.18}, url = {http://www.isoc.org/inet98/proceedings/1e/1e_1.htm} } @MISC{Sale-A-2006-stats, author = {Arthur Sale and Christian McGee}, title = {Tasmania {S}tatistics {S}oftware}, howpublished = {University of Tasmania}, month = {12~} # feb, year = {2006}, note = {Accessed on 7 March 2006.}, timestamp = {2006.07.11}, url = {http://eprints.comp.utas.edu.au:81/archive/00000262/} } @TECHREPORT{Stan-N-2006-running, author = {Nigel Stanger and Graham McGregor}, title = {Hitting the ground running: {B}uilding {N}ew {Z}ealand's first publicly available institutional repository}, institution = {Department of Information Science, University of Otago}, year = {2006}, type = {Discussion Paper}, number = {2006/07}, address = {Dunedin, New Zealand}, month = mar, pdf = {S/Stan-N-2006-running.pdf}, timestamp = {2006.07.11}, url = {http://www.business.otago.ac.nz/infosci/pubs/papers/papers/dp2006-07.pdf} } @ARTICLE{MacE-AM-1998-GIS, author = {Alan M.\ MacEachren}, title = {Cartography, {GIS} and the {W}orld {W}ide {W}eb}, journal = {Progress in Human Geography}, year = {1998}, volume = {22}, pages = {575--585}, number = {4}, month = dec, doi = {doi:10.1191/030913298670626440}, pdf = {MacE-AM-1998-GIS.pdf}, timestamp = {2006.07.18} } @MISC{Goog-M-2006-maps, author = {Google}, title = {Google {M}aps {API}}, howpublished = {Web site}, year = {2006}, note = {Accessed on 18 July 2006.}, timestamp = {2006.07.18}, url = {http://maps.google.com/apis/maps/} } @MISC{Bout-T-2004-GD, author = {Thomas Boutell}, title = {{GD} {G}raphics {L}ibrary}, howpublished = {Web site}, year = {2004}, note = {Updated on 3 November 2004; accessed on 18 July 2006.}, timestamp = {2006.07.18}, url = {http://www.boutell.com/gd/} } @comment{jabref-meta: selector_journal:} @comment{jabref-meta: selector_author:} @comment{jabref-meta: selector_keywords:} @comment{jabref-meta: selector_publisher:}

Show notes View

Map_Visualisation.bib 100755 → 0

This file was created with JabRef 2.1 beta.
Encoding: ISO8859_1

@STRING{acj = {Australian Computer Journal}}

@STRING{adt = {Application Development Trends}}

@STRING{ai = {Artificial Intelligence}}

@STRING{ajis = {Australian Journal of Information Systems}}

@STRING{cacm = {Communications of the ACM}}

@STRING{cj = {The Computer Journal}}

@STRING{database = {ACM SIGMIS Database}}

@STRING{dbms = {DBMS Magazine}}

@STRING{dbpd = {Database Programming {\&} Design}}

@STRING{develop = {{d}evelop, The Apple Technical Journal}}

@STRING{directions = {Apple Directions}}

@STRING{dke = {Data {\&} Knowledge Engineering}}

@STRING{ejis = {European Journal of Information Systems}}

@STRING{idt = {Internet Development Trends}}

@STRING{ijast = {International Journal of Applied Software Technology}}

@STRING{ijgis = {International Journal of Geographical Information Systems}}

@STRING{ijhcs = {International Journal of Human-Computer Studies}}

@STRING{ijmms = {International Journal of Man-Machine Studies}}

@STRING{ijseke = {International Journal of Software Engineering and Knowledge Engineering}}

@STRING{is = {Information Systems}}

@STRING{isj = {Information Systems Journal}}

@STRING{ist = {Information and Software Technology}}

@STRING{jacm = {Journal of the ACM}}

@STRING{jlp = {Journal of Logic Programming}}

@STRING{jot = {Journal of Object Technology}}

@STRING{jss = {Journal of Systems and Software}}

@STRING{lncs = {Lecture Notes in Computer Science}}

@STRING{misq = {MIS Quarterly}}

@STRING{nzjc = {New Zealand Journal of Computing}}

@STRING{nzjis = {New Zealand Journal of Information Systems}}

@STRING{oracle = {Oracle Magazine}}

@STRING{reg = {\scriptsize\textsuperscript{\textregistered}}}

@STRING{sej = {Software Engineering Journal}}

@STRING{sigmod = {ACM SIGMOD Record}}

@STRING{spe = {Software---Practice and Experience}}

@STRING{surveys = {ACM Computing Surveys}}

@STRING{tkde = {IEEE Transactions on Knowledge and Data Engineering}}

@STRING{tm = {\scriptsize\texttrademark}}

@STRING{tods = {ACM Transactions on Database Systems}}

@STRING{toit = {ACM Transactions on Internet Technology}}

@STRING{tose = {IEEE Transactions on Software Engineering}}

@STRING{tweb = {ACM Transactions on the Web}}

@STRING{vldb = {The VLDB Journal}}

@INCOLLECTION{Beau-JR-1991-GIS,
  author = {J.\ R.\ Beaumont},
  title = {{GIS} and market analysis},
  booktitle = {Geographical Information Systems, Volume 2: Applications},
  publisher = {Longman},
  year = {1991},
  editor = {David J.\ Maguire and Michael F.\ Goodkind and David W.\ Rhind},
  chapter = {45},
  pages = {139--151},
  address = {Harlow, UK},
  timestamp = {2006.07.11}
}

@BOOK{Dodg-M-2001-cybermap,
  title = {Mapping cyberspace},
  publisher = {Routledge},
  year = {2001},
  author = {Martin Dodge and Rob Kitchin},
  address = {London, UK},
  timestamp = {2006.07.04}
}

@MISC{IP2L-C-2006-GeoIP,
  author = {{IP2Location.com}},
  title = {{IP2L}ocation} # tm # {: {B}ringing geography to the {I}nternet},
  howpublished = {Web site},
  month = jul,
  year = {2006},
  note = {Accessed on 18 July 2006.},
  timestamp = {2006.07.18},
  url = {http://www.ip2location.com/}
}

@ARTICLE{Lamm-SE-1996-webvis,
  author = {Stephen E.\ Lamm and Daniel A.\ Reed and Will H.\ Scullin},
  title = {Real-time geographic visualization of {W}orld {W}ide {W}eb traffic},
  journal = {Computer Networks and ISDN Systems},
  year = {1996},
  volume = {28},
  pages = {1457--1468},
  number = {7--11},
  month = may,
  doi = {doi:10.1016/0169-7552(96)00055-4},
  pdf = {L/Lamm-SE-1996-webvis.pdf},
  timestamp = {2006.07.18}
}

@MISC{Maxm-G-2006-GeoIP,
  author = {{Maxmind LLC}},
  title = {Geo{IP}: {IP} address location technology},
  howpublished = {Web site},
  month = jul,
  year = {2006},
  note = {Accessed on 18 July 2006.},
  timestamp = {2006.07.18},
  url = {http://www.maxmind.com/app/ip-location}
}

@MISC{Maxm-G-2006-GeoLiteCity,
  author = {{Maxmind LLC}},
  title = {Geo{L}ite {C}ity: Free {IP} address to city database},
  howpublished = {Web site},
  month = jul,
  year = {2006},
  note = {Accessed on 18 July 2006.},
  timestamp = {2006.07.18},
  url = {http://www.maxmind.com/app/geolitecity}
}

@INPROCEEDINGS{Papa-N-1998-Palantir,
  author = {Nektarios Papadakakis and Evangelos P.\ Markatos and Athanasios E.\
	Papathanasiou},
  title = {Palantir: {A} visualization tool for the {W}orld {W}ide {W}eb},
  booktitle = {Proceedings of the INET'98 Conference},
  year = {1998},
  address = {Geneva, Switzerland},
  month = {21--24~} # jul,
  citeseerurl = {http://citeseer.ist.psu.edu/68932.html},
  pdf = {P/Papa-N-1998-Palantir.pdf},
  timestamp = {2006.07.18},
  url = {http://www.isoc.org/inet98/proceedings/1e/1e_1.htm}
}

@MISC{Sale-A-2006-stats,
  author = {Arthur Sale and Christian McGee},
  title = {Tasmania {S}tatistics {S}oftware},
  howpublished = {University of Tasmania},
  month = {12~} # feb,
  year = {2006},
  note = {Accessed on 7 March 2006.},
  timestamp = {2006.07.11},
  url = {http://eprints.comp.utas.edu.au:81/archive/00000262/}
}

@TECHREPORT{Stan-N-2006-running,
  author = {Nigel Stanger and Graham McGregor},
  title = {Hitting the ground running: {B}uilding {N}ew {Z}ealand's first publicly
	available institutional repository},
  institution = {Department of Information Science, University of Otago},
  year = {2006},
  type = {Discussion Paper},
  number = {2006/07},
  address = {Dunedin, New Zealand},
  month = mar,
  pdf = {S/Stan-N-2006-running.pdf},
  timestamp = {2006.07.11},
  url = {http://www.business.otago.ac.nz/infosci/pubs/papers/papers/dp2006-07.pdf}
}

@ARTICLE{MacE-AM-1998-GIS,
  author = {Alan M.\ MacEachren},
  title = {Cartography, {GIS} and the {W}orld {W}ide {W}eb},
  journal = {Progress in Human Geography},
  year = {1998},
  volume = {22},
  pages = {575--585},
  number = {4},
  month = dec,
  doi = {doi:10.1191/030913298670626440},
  pdf = {MacE-AM-1998-GIS.pdf},
  timestamp = {2006.07.18}
}

@MISC{Goog-M-2006-maps,
  author = {Google},
  title = {Google {M}aps {API}},
  howpublished = {Web site},
  year = {2006},
  note = {Accessed on 18 July 2006.},
  timestamp = {2006.07.18},
  url = {http://maps.google.com/apis/maps/}
}

@MISC{Bout-T-2004-GD,
  author = {Thomas Boutell},
  title = {{GD} {G}raphics {L}ibrary},
  howpublished = {Web site},
  year = {2004},
  note = {Updated on 3 November 2004; accessed on 18 July 2006.},
  timestamp = {2006.07.18},
  url = {http://www.boutell.com/gd/}
}

@comment{jabref-meta: selector_journal:}

@comment{jabref-meta: selector_author:}

@comment{jabref-meta: selector_keywords:}

@comment{jabref-meta: selector_publisher:}

Show notes View Map_Visualisation.tex 100755 → 0
\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 Methods for Online Geovisualisation 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 typically achieved by dynamic generation of images on the server. In this paper we compare this method with two others: overlaying CSS-enabled HTML on an underlying image and using Google Maps. The results show that all three methods are suitable for small data sets, but that the latter two methods do not scale well 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, geovisualisation, 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 running a web site, it is quite reasonable to want information on the nature of traffic to the site. 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 visualisation 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 repository management software\footnote{\url{http://www.eprints.org/}}. 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 monitoring 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 a numerical ranking of the number of hits from each country, it does not provide any visual clues as 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. There have been several prior efforts to plot web activity geographically. \citeN{Lamm-SE-1996-webvis} developed a sophisticated system for real-time visualisation of web traffic on a 3D globe, but this was intended for use with a virtual reality interface, thus limiting its general applicability. \citeN{Papa-N-1998-Palantir} describe a similar system (Palantir) that is written in Java, and thus able to be run within a web browser, asssuming that a Java virtual machine is available. \citeN[pp.\ 100--103]{Dodg-M-2001-cybermap} describe these and several other related systems. 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}. 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. Based on the literature, it appeared that a Palantir-style model would be suitable for our purposes. The Palantir software itself appears to no longer be available, but we would probably not have used it anyway as it requires the client machine to have a Java virtual machine installed. Palantir worked by plotting web hits directly onto a base map image, then displaying the composite image, all within a client-side Java applet. However, the basic technique can just as easily be implemented as a server-side application that returns a bitmap image to the client. We shall henceforth refer to this technique as \emph{image generation}; it will be discussed further in Section~\ref{sec-imagegen}. However, there are alternative techniques that have become possible only relatively recently, and are therefore unlikely to be in wide use (if at all). One possible technique is to load a base image into the browser, then overlay points onto the image using using absolutely positioned HTML \verb\|<DIV>\| elements. This technique raises the potential for a more GIS-like style of interaction with the map, with multiple layers that can be activated and deactivated as necessary. We refer to this technique as \emph{HTML overlay}; it will be discussed further in Section~\ref{sec-overlay}. Another recent development is the release of the Google Maps API \cite{Goog-M-2006-maps}, which enables web developers to easily embed dynamic, interactive maps within web pages. These maps have an obvious visual appeal and provide quite powerful interactive functionality (including pan and zoom) out of the box. They also offer significant customisability to the developer. This technique will be discussed further in Section~\ref{sec-google}. % This technique % requires a browser that supports the Cascading Style Sheet (CSS) % positioning properties; such support has only appeared relatively % recently. % % The former technique, which we shall henceforth refer to as \emph{base % map + HTML overlay}, involves overlaying points onto a base map image on % the client side, using HTML \verb\|<DIV>\| elements that are absolutely % positioned via CSS. The latter technique % % % % We therefore % considered options that did not require additional client software byond what % was provided by the web browser. We identified three % possible techniques for generating such a map: % \begin{description} % % \item[Image generation] An image (e.g., a JPEG or PNG) is generated % at the server by plotting points directly onto a base map. The final % image is then sent to the client. % % \item[Base map + HTML overlay] A base map image is sent to the % client. Points are then overlaid on this map at either the client or % the server using HTML \verb\|<DIV>\| elements that are absolutely % positioned via CSS. % % \item[Google Maps] The Google Maps API is used at the client to % generate a base map and plot points on the map. The data for this % map are generated at the server. % % \end{description} % We will describe these techniques in more detail in % Section~\ref{sec-techniques}. The first technique (image generation) % appears to be fairly widespread and has been in use for some time, % whereas the latter two do not appear to have been widely used (we will % examine possible reasons for this shortly). The identification of these three techniques immediately raised the question of which was the best for our purposes. The greatest concern was whether these techniques 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. Taking into consideration the type of hit (abstract view versus document download) increased that figure to nearly 13,000. Ideally we wanted a technique that could plot a large number of points as quickly as possible. We therefore set about testing the scalability of the three techniques 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 initial intuition was that the image generation technique would prove the most scalable, and this was borne out by the results of the experiments, which show that image generation scales 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), but their performance deteriorated rapidly beyond this. The results are discussed in more detail in Section~\ref{sec-results}. \section{The techniques in more detail} \label{sec-techniques} In this section we discuss in more detail each of the three techniques outlined in the previous section. For each technique, 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{Image generation} \label{sec-imagegen} As noted earlier, this technique works by directly plotting geolocated IP addresses onto a base map image, then displays the composite image at the client, as shown in Figure~\ref{fig-image}. It requires two additional pieces of software: one that can create and manipulate bitmap images programmatically (for example, the GD image library\footnote{\url{http://www.boutell.com/gd/}}); and one that can 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]{gd_map} \end{center} \caption{Example output from the image generation technique.} \label{fig-image} \end{figure} The Palantir system implemented a distributed architecture for this technique, where the source data were generated at the server and the map was generated by a Java applet at the client \cite{Papa-N-1998-Palantir}. Alternatively, the map image can be generated entirely on the server. Both architectures are illustrated in Figure~\ref{fig-image-architecture}. We have adopted the latter approach in our experiments (server-side image generation), as the former would require installing additional software at the client (for generating images and performing cartographic projection operations). \begin{figure} \caption{Distributed vs.\ server-side architectures for the image generation technique.} \label{fig-image-architecture} \end{figure} This technique provides some distinct advantages. If a server-side architecture is adopted, the technique 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 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 for the map image can impact on the quality of the final result. For example, lossy compression methods such as JPEG can make the points plotted on the map appear distinctly fuzzy (see Figure~\ref{fig-image-quality}). A lossless compression method such as PNG will avoid this problem, but will produce larger image files. Finally, it is harder to provide interactive map manipulation features with this technique, as the output is a 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 with a very high resolution base map image, but the number of zoom levels may be restricted. \subsection{HTML overlay} \label{sec-overlay} This technique also involves plotting points onto a base map image, but it differs from the image generation technique 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, using HTML \verb\|<DIV>\| elements that are absolutely positioned via CSS. This technique thus requires a web browser that supports the appropriate CSS positioning attributes, but such support is now standard in many browsers. (The output looks essentially identical to that from the image generation technique, so we have not provided an example.) As with the image generation technique, we can adopt either a distributed architecture, where source data are generated at the server and converted into an HTML overlay at the client, or a server-side architecture, where the HTML overlay is generated at the server. (The base map image is static and thus requires no additional processing.) Both architectures are illustrated in Figure~\ref{fig-html-architectures}. Unlike the image generation technique, however, the distributed architecture can be implemented without additional software on the client side. JavaScript is now standard in most browsers, and this is sufficient to implement the client-side behaviour. Both architectures thus meet our requirement for avoiding additional client-side software. \begin{figure} \caption{Distributed vs.\ server-side architectures for the HTML overlay technique.} \label{fig-html-architectures} \end{figure} If a server-side architecture is adopted, this technique is actually slightly easier to implement than the image generation technique, because we do not need the code to generate or manipulate images. Implementing a distributed architecture is more complex, but this has more to do with the nature of distributed applications than the technique itself. It does not suffer the image generation technique's problem of fuzzy-looking points (see Figure~\ref{fig-image-quality}), because the points are not part of the map image. Finally, the most significant advantage of the HTML overlay technique over the image generation technique is that 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, albeit on a much smaller scale. As with the image generation technique, however, we still have the problem of finding a suitable base map image. The technique also relies on relatively recent technologies that have not yet been fully or consistently implemented by all browsers. The most significant disadvantage of the HTML overlay technique, however, is that the size of the HTML overlay will be directly proportional to the number of points to be plotted, as there will be one \verb\|<DIV>\| element per point. A very large number of points will almost certainly lead to excessive memory usage, so this technique is unlikely to scale well at the high end. However, it may still be useful for smaller data sets that require interactive manipulation. \begin{figure} \begin{center} \includegraphics[scale=1.25]{gd_detail}\medskip \includegraphics[scale=1.25]{html_detail} \end{center} \caption{Image quality of JPEG image generation (top) vs.\ HTML overlay (bottom).} \label{fig-image-quality} \end{figure} \subsection{Google Maps} \label{sec-google} This technique uses the client-side Google Maps API \cite{Goog-M-2006-maps} to both generate the base map and plot points on it, as shown in Figure~\ref{fig-google}. The output and interaction is therefore significantly different in nature from that provided by the other two techniques. Google Maps requires JavaScript support at the client and the Google Maps software must be installed on the client. However, since the latter happens automatically when the corresponding web page is loaded, this technique meets our requirements. \begin{figure} \begin{center} \includegraphics[width=0.95\textwidth,keepaspectratio]{google_map} \end{center} \caption{Example output from the Google Maps technique.} \label{fig-google} \end{figure} Google Maps by definition uses a distributed architecture, as shown in Figure~\ref{fig-google-architecture}. Data are generated at the server, while all map display and manipulation occurs at the client. \begin{figure} \caption{Distributed architecture of the Google Maps technique.} \label{fig-google-architecture} \end{figure} The primary advantage of this technique is that it provides an appealing visual display and powerful functionality for 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 ``speech bubble'' next to the point, as shown in Figure~\ref{fig-google}. However, there are also some significant disadvantages compared to the previous two techniques. As a distrbiuted applicatiopn, it is more complex to implement and debug. It also relies on an active Internet connection in order to run. The server must register an API key with Google, which is checked 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. Consequently, this technique cannot be used on an isolated network. Finally, the Google Maps API does not currently provide any method of toggling the visibility of markers on the map, so it is not possible to implement the ``layers'' that are possible with the HTML overlay technique (it is of course possible that Google will implement this feature in a later version of the API). Interestingly, the Google Earth application addresses several of these issues, but this is clearly outside the scope of our work, as it requires the manual installation of extra software and runs outside the web browser entirely. (Just for fun, however, we will do an informal comparison in Section~\ref{sec-results} between Google Earth and the three techniques discussed here.) \section{Experimental design} \label{sec-experiment} \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}

Show notes View

Map_Visualisation.tex 100755 → 0

\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 Methods for Online Geovisualisation 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 typically achieved by dynamic generation of images
on the server. In this paper we compare this method with two others:
overlaying CSS-enabled HTML on an underlying image and using Google
Maps. The results show that all three methods are suitable for small
data sets, but that the latter two methods do not scale well 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, geovisualisation, 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 running a web site, it is quite reasonable to want information on
the nature of traffic to the site. 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 visualisation 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 repository management
software\footnote{\url{http://www.eprints.org/}}. 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 monitoring 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 a numerical ranking of the number of hits from
each country, it does not provide any visual clues as 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.

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

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}. 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.

Based on the literature, it appeared that a Palantir-style model would
be suitable for our purposes. The Palantir software itself appears to no
longer be available, but we would probably not have used it anyway as it
requires the client machine to have a Java virtual machine installed.
Palantir worked by plotting web hits directly onto a base map image,
then displaying the composite image, all within a client-side Java
applet. However, the basic technique can just as easily be implemented
as a server-side application that returns a bitmap image to the client.
We shall henceforth refer to this technique as \emph{image generation};
it will be discussed further in Section~\ref{sec-imagegen}.

However, there are alternative techniques that have become possible only
relatively recently, and are therefore unlikely to be in wide use (if at
all). One possible technique is to load a base image into the browser,
then overlay points onto the image using using absolutely positioned
HTML \verb|<DIV>| elements. This technique raises the potential for a
more GIS-like style of interaction with the map, with multiple layers
that can be activated and deactivated as necessary.  We refer to this
technique as \emph{HTML overlay}; it will be discussed further in
Section~\ref{sec-overlay}.

Another recent development is the release of the Google Maps API
\cite{Goog-M-2006-maps}, which enables web developers to easily embed
dynamic, interactive maps within web pages. These maps have an obvious
visual appeal and provide quite powerful interactive functionality
(including pan and zoom) out of the box. They also offer significant
customisability to the developer. This technique will be discussed
further in Section~\ref{sec-google}.

% This technique
% requires a browser that supports the Cascading Style Sheet (CSS)
% positioning properties; such support has only appeared relatively
% recently.
% 
% The former technique, which we shall henceforth refer to as \emph{base
% map + HTML overlay}, involves overlaying points onto a base map image on
% the client side, using HTML \verb|<DIV>| elements that are absolutely
% positioned via CSS. The latter technique 
% 
% 
% 
% We therefore
% considered options that did not require additional client software byond what
% was provided by the web browser. We identified three
% possible techniques for generating such a map:

% \begin{description}
% 
% 	\item[Image generation] An image (e.g., a JPEG or PNG) is generated
% 	at the server by plotting points directly onto a base map. The final
% 	image is then sent to the client.
% 	
% 	\item[Base map + HTML overlay] A base map image is sent to the
% 	client. Points are then overlaid on this map at either the client or
% 	the server using HTML \verb|<DIV>| elements that are absolutely
% 	positioned via CSS.
% 	
% 	\item[Google Maps] The Google Maps API is used at the client to
% 	generate a base map and plot points on the map. The data for this
% 	map are generated at the server.
% 
% \end{description}

% We will describe these techniques in more detail in
% Section~\ref{sec-techniques}. The first technique (image generation)
% appears to be fairly widespread and has been in use for some time,
% whereas the latter two do not appear to have been widely used (we will
% examine possible reasons for this shortly).

The identification of these three techniques immediately raised the
question of which was the best for our purposes. The greatest concern
was whether these techniques 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. Taking into consideration
the type of hit (abstract view versus document download) increased that
figure to nearly 13,000. Ideally we wanted a technique that could plot a
large number of points as quickly as possible.

We therefore set about testing the scalability of the three techniques
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 initial intuition was that the image generation technique would
prove the most scalable, and this was borne out by the results of the
experiments, which show that image generation scales 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), but their performance deteriorated rapidly beyond this. The
results are discussed in more detail in Section~\ref{sec-results}.

\section{The techniques in more detail}
\label{sec-techniques}

In this section we discuss in more detail each of the three techniques
outlined in the previous section. For each technique, 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{Image generation}
\label{sec-imagegen}

As noted earlier, this technique works by directly plotting geolocated
IP addresses onto a base map image, then displays the composite image at
the client, as shown in Figure~\ref{fig-image}. It requires two
additional pieces of software: one that can create and manipulate bitmap
images programmatically (for example, the GD image
library\footnote{\url{http://www.boutell.com/gd/}}); and one that can
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]{gd_map}
	\end{center}
	\caption{Example output from the image generation technique.}
	\label{fig-image}
\end{figure}

The Palantir system implemented a distributed architecture for this
technique, where the source data were generated at the server and the
map was generated by a Java applet at the client
\cite{Papa-N-1998-Palantir}. Alternatively, the map image can be
generated entirely on the server. Both architectures are illustrated in
Figure~\ref{fig-image-architecture}. We have adopted the latter approach
in our experiments (server-side image generation), as the former would
require installing additional software at the client (for generating
images and performing cartographic projection operations).

\begin{figure}
	\caption{Distributed vs.\ server-side architectures for the image
	generation technique.}
	\label{fig-image-architecture}
\end{figure}

This technique provides some distinct advantages. If a server-side
architecture is adopted, the technique 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 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 for the map image
can impact on the quality of the final result. For example, lossy
compression methods such as JPEG can make the points plotted on the map
appear distinctly fuzzy (see Figure~\ref{fig-image-quality}). A
lossless compression method such as PNG will avoid this problem, but
will produce larger image files. Finally, it is harder to provide
interactive map manipulation features with this technique, as the output
is a 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 with a very high
resolution base map image, but the number of zoom levels may be
restricted.

\subsection{HTML overlay}
\label{sec-overlay}

This technique also involves plotting points onto a base map image, but
it differs from the image generation technique 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, using HTML
\verb|<DIV>| elements that are absolutely positioned via CSS. This
technique thus requires a web browser that supports the appropriate CSS
positioning attributes, but such support is now standard in many
browsers. (The output looks essentially identical to that from the image
generation technique, so we have not provided an example.)

As with the image generation technique, we can adopt either a
distributed architecture, where source data are generated at the server
and converted into an HTML overlay at the client, or a server-side
architecture, where the HTML overlay is generated at the server. (The
base map image is static and thus requires no additional processing.)
Both architectures are illustrated in
Figure~\ref{fig-html-architectures}. Unlike the image generation
technique, however, the distributed architecture can be implemented
without additional software on the client side. JavaScript is now
standard in most browsers, and this is sufficient to implement the
client-side behaviour. Both architectures thus meet our requirement for
avoiding additional client-side software.

\begin{figure}
	\caption{Distributed vs.\ server-side architectures for the HTML
	overlay technique.}
	\label{fig-html-architectures}
\end{figure}

If a server-side architecture is adopted, this technique is actually
slightly easier to implement than the image generation technique,
because we do not need the code to generate or manipulate images.
Implementing a distributed architecture is more complex, but this has
more to do with the nature of distributed applications than the
technique itself. It does not suffer the image generation technique's
problem of fuzzy-looking points (see Figure~\ref{fig-image-quality}),
because the points are not part of the map image. Finally, the most
significant advantage of the HTML overlay technique over the image
generation technique is that 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, albeit on
a much smaller scale.

As with the image generation technique, however, we still have the
problem of finding a suitable base map image. The technique also relies
on relatively recent technologies that have not yet been fully or
consistently implemented by all browsers. The most significant
disadvantage of the HTML overlay technique, however, is that the size of
the HTML overlay will be directly proportional to the number of points
to be plotted, as there will be one \verb|<DIV>| element per point. A
very large number of points will almost certainly lead to excessive
memory usage, so this technique is unlikely to scale well at the high
end. However, it may still be useful for smaller data sets that require
interactive manipulation.

\begin{figure}
	\begin{center}
		\includegraphics[scale=1.25]{gd_detail}\medskip
		
		\includegraphics[scale=1.25]{html_detail}
	\end{center}
	\caption{Image quality of JPEG image generation (top) vs.\ HTML
	overlay (bottom).}
	\label{fig-image-quality}
\end{figure}

\subsection{Google Maps}
\label{sec-google}

This technique uses the client-side Google Maps API
\cite{Goog-M-2006-maps} to both generate the base map and plot points on
it, as shown in Figure~\ref{fig-google}. The output and interaction is
therefore significantly different in nature from that provided by the
other two techniques. Google Maps requires JavaScript support at the
client and the Google Maps software must be installed on the client.
However, since the latter happens automatically when the corresponding
web page is loaded, this technique meets our requirements.

\begin{figure}
	\begin{center}
		\includegraphics[width=0.95\textwidth,keepaspectratio]{google_map}
	\end{center}
	\caption{Example output from the Google Maps technique.}
	\label{fig-google}
\end{figure}

Google Maps by definition uses a distributed architecture, as shown in
Figure~\ref{fig-google-architecture}. Data are generated at the server,
while all map display and manipulation occurs at the client.

\begin{figure}
	\caption{Distributed architecture of the Google Maps technique.}
	\label{fig-google-architecture}
\end{figure}

The primary advantage of this technique is that it provides an appealing
visual display and powerful functionality for 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 ``speech bubble'' next
to the point, as shown in Figure~\ref{fig-google}.

However, there are also some significant disadvantages compared to the
previous two techniques. As a distrbiuted applicatiopn, it is more
complex to implement and debug. It also relies on an active Internet
connection in order to run. The server must register an API key with
Google, which is checked 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. Consequently, this technique
cannot be used on an isolated network. Finally, the Google Maps API does
not currently provide any method of toggling the visibility of markers
on the map, so it is not possible to implement the ``layers'' that are
possible with the HTML overlay technique (it is of course possible that
Google will implement this feature in a later version of the API).

Interestingly, the Google Earth application addresses several of these
issues, but this is clearly outside the scope of our work, as it
requires the manual installation of extra software and runs outside the
web browser entirely. (Just for fun, however, we will do an informal
comparison in Section~\ref{sec-results} between Google Earth and the
three techniques discussed here.)

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

\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 TOIT_2006/.gitignore 0 → 100644
Map_Visualisation.pdf data_size.pdf data_generation_time.pdf page_load_time.pdf combined_time.pdf real_memory.pdf virtual_memory.pdf

Ignore Space Show notes View TOIT_2006/16384_points.png 0 → 100644

Ignore Space Show notes View TOIT_2006/GoogleMap-full.png 0 → 100644

Ignore Space Show notes View TOIT_2006/ImageGeneration-full.png 0 → 100644

Ignore Space Show notes View TOIT_2006/Makefile 0 → 100644
.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 \ 16384_points.png 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)',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','Browser real memory size (MB)',10,1200) virtual_memory.pdf: d_virtual_memory.txt lineplot.plo $(call lineplot,$,$<,'Virtual Memory Usage','Browser virtual memory size (MB)',10,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 $< $@

Ignore Space Show notes View

TOIT_2006/Makefile 0 → 100644

.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 \
	16384_points.png

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)',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','Browser real memory size (MB)',10,1200)

virtual_memory.pdf: d_virtual_memory.txt lineplot.plo
	$(call lineplot,$*,$<,'Virtual Memory Usage','Browser virtual memory size (MB)',10,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 $< $@

Ignore Space Show notes View TOIT_2006/Map_Visualisation.bib 0 → 100644
This file was created with JabRef 2.1 beta. Encoding: ISO8859_1 @STRING{acj = {Australian Computer Journal}} @STRING{adt = {Application Development Trends}} @STRING{ai = {Artificial Intelligence}} @STRING{ajis = {Australian Journal of Information Systems}} @STRING{cacm = {Commun.\ ACM}} @STRING{cj = {Comput.\ J.}} @STRING{asper = {ACM SIGMETRICS Perf.\ Eval.\ Review}} @STRING{database = {ACM SIGMIS Database}} @STRING{dbms = {DBMS Magazine}} @STRING{dbpd = {Database Programming {\&} Design}} @STRING{develop = {{d}evelop, The Apple Technical Journal}} @STRING{directions = {Apple Directions}} @STRING{dke = {Data {\&} Knowledge Engineering}} @STRING{ejis = {European Journal of Information Systems}} @STRING{idt = {Internet Development Trends}} @STRING{ieeec = {IEEE Comput.}} @STRING{ieees = {IEEE Softw.}} @STRING{ijast = {International Journal of Applied Software Technology}} @STRING{ijgis = {International Journal of Geographical Information Systems}} @STRING{ijhcs = {International Journal of Human-Computer Studies}} @STRING{ijmms = {International Journal of Man-Machine Studies}} @STRING{ijseke = {International Journal of Software Engineering and Knowledge Engineering}} @STRING{is = {Information Systems}} @STRING{isj = {Information Systems Journal}} @STRING{ist = {Inf.\ Softw.\ Tech.}} @STRING{jacm = {Journal of the ACM}} @STRING{jlp = {Journal of Logic Programming}} @STRING{jot = {Journal of Object Technology}} @STRING{jss = {J.\ Syst.\ Softw.}} @STRING{lncs = {Lecture Notes in Computer Science}} @STRING{misq = {MIS Quarterly}} @STRING{nzjc = {New Zealand Journal of Computing}} @STRING{nzjis = {New Zealand Journal of Information Systems}} @STRING{oracle = {Oracle Magazine}} @STRING{reg = {\scriptsize\textsuperscript{\textregistered}}} @STRING{sej = {Software Engineering Journal}} @STRING{sigmod = {ACM SIGMOD Record}} @STRING{spe = {Software---Practice and Experience}} @STRING{surveys = {ACM Comput.\ Surv.}} @STRING{tkde = {IEEE Trans.\ Knowl.\ Data Eng.}} @STRING{tm = {\scriptsize\texttrademark}} @STRING{tocs = {ACM Trans.\ Comput.\ Syst.}} @STRING{tods = {ACM Trans.\ Database Syst.}} @STRING{toit = {ACM Trans.\ Internet Tech.}} @STRING{tose = {IEEE Trans.\ Softw.\ Eng.}} @STRING{tweb = {ACM Trans.\ Web}} @STRING{vldb = {The VLDB Journal}} @INCOLLECTION{Beau-JR-1991-GIS, author = {J.\ R.\ Beaumont}, title = {{GIS} and market analysis}, booktitle = {Geographical Information Systems, Volume 2: Applications}, publisher = {Longman}, year = {1991}, editor = {David J.\ Maguire and Michael F.\ Goodkind and David W.\ Rhind}, chapter = {45}, pages = {139--151}, address = {Harlow, UK}, timestamp = {2006.07.11} } @BOOK{Dodg-M-2001-cybermap, title = {Mapping Cyberspace}, publisher = {Routledge}, year = {2001}, author = {Martin Dodge and Rob Kitchin}, address = {London, UK}, timestamp = {2006.07.04} } @MISC{IP2L-C-2006-GeoIP, author = {IP2Location}, title = {{IP2L}ocation} # tm # {: {B}ringing geography to the {I}nternet}, howpublished = {\url{http://www.ip2location.com/}, IP2Location.com}, month = jul, year = {2006}, note = {Accessed on 18 July 2006.}, timestamp = {2006.07.18}, url = {http://www.ip2location.com/} } @ARTICLE{Lamm-SE-1996-webvis, author = {Stephen E.\ Lamm and Daniel A.\ Reed and Will H.\ Scullin}, title = {Real-time geographic visualization of {W}orld {W}ide {W}eb traffic}, journal = {Computer Networks and ISDN Systems}, year = {1996}, volume = {28}, pages = {1457--1468}, number = {7--11}, month = may, doi = {doi:10.1016/0169-7552(96)00055-4}, pdf = {L/Lamm-SE-1996-webvis.pdf}, timestamp = {2006.07.18} } @MISC{Maxm-G-2006-GeoIP, author = {Maxmind}, title = {Geo{IP}: {IP} address location technology}, howpublished = {\url{http://www.maxmind.com/app/ip-location}, Maxmind LLC}, month = jul, year = {2006}, note = {Accessed on 18 July 2006.}, timestamp = {2006.07.18}, url = {http://www.maxmind.com/app/ip-location} } @MISC{Maxm-G-2006-GeoLiteCity, author = {Maxmind}, title = {Geo{L}ite {C}ity: Free {IP} address to city database}, howpublished = {\url{http://www.maxmind.com/app/geolitecity}, Maxmind LLC}, month = jul, year = {2006}, note = {Accessed on 18 July 2006.}, timestamp = {2006.07.18}, url = {http://www.maxmind.com/app/geolitecity} } @INPROCEEDINGS{Papa-N-1998-Palantir, author = {Nektarios Papadakakis and Evangelos P.\ Markatos and Athanasios E.\ Papathanasiou}, title = {Palantir: {A} visualization tool for the {W}orld {W}ide {W}eb}, booktitle = {Proceedings of the INET'98 Conference}, year = {1998}, address = {Geneva, Switzerland}, month = {21--24~} # jul, citeseerurl = {http://citeseer.ist.psu.edu/68932.html}, pdf = {P/Papa-N-1998-Palantir.pdf}, timestamp = {2006.07.18}, url = {http://www.isoc.org/inet98/proceedings/1e/1e_1.htm} } @MISC{Sale-A-2006-stats, author = {Arthur Sale and Christian McGee}, title = {Tasmania {S}tatistics {S}oftware}, howpublished = {\url{http://eprints.comp.utas.edu.au:81/archive/00000262/}, University of Tasmania, Hobart, Australia}, month = {12~} # feb, year = {2006}, note = {Accessed on 7 March 2006.}, timestamp = {2006.07.11}, url = {http://eprints.comp.utas.edu.au:81/archive/00000262/} } @TECHREPORT{Stan-N-2006-running, author = {Nigel Stanger and Graham McGregor}, title = {Hitting the ground running: {B}uilding {N}ew {Z}ealand's first publicly available institutional repository}, institution = {Department of Information Science, University of Otago}, year = {2006}, type = {Discussion Paper}, number = {2006/07}, address = {Dunedin, New Zealand}, month = mar, pdf = {S/Stan-N-2006-running.pdf}, timestamp = {2006.07.11}, url = {http://www.business.otago.ac.nz/infosci/pubs/papers/papers/dp2006-07.pdf} } @ARTICLE{MacE-AM-1998-GIS, author = {Alan M.\ MacEachren}, title = {Cartography, {GIS} and the {W}orld {W}ide {W}eb}, journal = {Progress in Human Geography}, year = {1998}, volume = {22}, pages = {575--585}, number = {4}, month = dec, doi = {doi:10.1191/030913298670626440}, pdf = {MacE-AM-1998-GIS.pdf}, timestamp = {2006.07.18} } @MISC{Goog-M-2006-maps, author = {Google}, title = {Google {M}aps {API}}, howpublished = {\url{http://maps.google.com/apis/maps/}}, year = {2006}, note = {Accessed on 18 July 2006.}, timestamp = {2006.07.18}, url = {http://maps.google.com/apis/maps/} } @MISC{Bout-T-2004-GD, author = {Thomas Boutell}, title = {{GD} {G}raphics {L}ibrary}, howpublished = {\url{http://www.boutell.com/gd/}}, year = {2004}, note = {Updated on 3 November 2004; accessed on 18 July 2006.}, timestamp = {2006.07.18}, url = {http://www.boutell.com/gd/} } @ARTICLE{Offu-J-2002-quality, author = {Jeff Offutt}, title = {Quality attributes of {W}eb software applications}, journal = ieees, year = {2002}, volume = {19}, pages = {25--32}, number = {2}, month = mar # {/} # apr, doi = {doi:10.1109/52.991329}, pdf = {O/Offu-J-2002-quality.pdf}, timestamp = {2006.07.04} } @ARTICLE{Jian-B-2000-cybermap, author = {Bin Jiang and Ferjan Ormeling}, title = {Mapping cyberspace: {V}isualizing, analysing and exploring virtual worlds}, journal = {The Cartographic Journal}, year = {2000}, volume = {37}, pages = {117--122}, number = {2}, month = dec, pdf = {J/Jian-B-2000-cybermap.pdf}, timestamp = {2006.07.04}, url = {http://www.hig.se/~bjg/cybermap2000.pdf} } @ARTICLE{Eick-SG-2001-sitevis, author = {Stephen G.\ Eick}, title = {Visualizing online activity}, journal = cacm, year = {2001}, volume = {44}, pages = {45--50}, number = {8}, month = aug, doi = {http://doi.acm.org/10.1145/381641.381710}, pdf = {E/Eick-SG-2001-sitevis.pdf}, timestamp = {2006.07.04} } @INPROCEEDINGS{Wood-J-1996-vis, author = {Jason Wood and Ken Brodlie and Helen Wright}, title = {Visualization over the {W}orld {W}ide {W}eb and its application to environmental data}, booktitle = {Proceedings of IEEE Visualization '96}, year = {1996}, editor = {Roni Yagel and Gregory M.\ Nielson}, pages = {81--86}, address = {San Francisco, California}, month = oct # {~27--} # nov # {~1}, organization = {IEEE Computer Society and ACM}, pdf = {W/Wood-J-1996-vis.pdf}, timestamp = {2006.07.24}, url = {http://portal.acm.org/citation.cfm?id=245010&dl=ACM&coll=GUIDE&CFID=15151515&CFTOKEN=6184618} } @MISC{CIA-WFB-2006, author = {{CIA}}, title = {The {W}orld {F}actbook}, howpublished = {\url{https://www.cia.gov/cia/publications/factbook/}, Central Intelligence Agency, Washington, DC, USA}, year = {2006}, timestamp = {2006.08.07}, url = {https://www.cia.gov/cia/publications/factbook/} } @INPROCEEDINGS{Saya-A-2006-GISWS, author = {Ahmet Sayar and Marlon Pierce and Geoffrey Fox}, title = {Integrating {AJAX} approach into {GIS} visualization web services}, booktitle = {Proceedings of the Advanced International Conference on Telecommunications and International Conference on Internet and Web Applications and Services (AICT/ICIW 2006)}, year = {2006}, pages = {169--175}, address = {Guadeloupe, French Caribbean}, month = {19--25~} # feb, publisher = {IEEE Computer Society}, doi = {http://doi.ieeecomputersociety.org/10.1109/AICT-ICIW.2006.114}, pdf = {S/Saya-A-2006-GISWS.pdf}, timestamp = {2006.08.07} } @TECHREPORT{Garr-JJ-2005-Ajax, author = {Jesse James Garrett}, title = {Ajax: {A} new approach to web applications}, institution = {Adaptive Path, LLC}, year = {2005}, type = {Web essay, \url{http://www.adaptivepath.com/publications/essays/archives/000385.php}}, timestamp = {2006.08.07}, url = {http://www.adaptivepath.com/publications/essays/archives/000385.php} } @ARTICLE{Bates-PC-1995-distdebug, author = {Peter C.\ Bates}, title = {Debugging heterogeneous distributed systems using event-based models of behavior}, journal = tocs, year = {1995}, volume = {13}, pages = {1--31}, number = {1}, month = feb, doi = {http://doi.acm.org/10.1145/200912.200913}, pdf = {B/Bates-PC-1995-distdebug.pdf}, timestamp = {2006.08.07} } @ARTICLE{Ensl-PH-1978-distributed, author = {P.\ H.\ Enslow}, title = {What is a ``distributed'' data processing system}, journal = ieeec, year = {1978}, volume = {1}, pages = {13--21}, number = {1}, month = jan, timestamp = {2006.08.07} } @ARTICLE{Barf-P-1999-webperf, author = {Paul Barford and Mark Crovella}, title = {Measuring {W}eb performance in the wide area}, journal = asper, year = {1999}, volume = {27}, pages = {37--48}, number = {2}, month = sep, doi = {http://doi.acm.org/10.1145/332944.332953}, pdf = {B/Barf-P-1999-webperf.pdf}, timestamp = {2006.07.04} } @TECHREPORT{Gibb-H-2006-Gridscape, author = {Hussein Gibbins and Rajkumar Buyya}, title = {Gridscape {II}: {A} customisable and pluggable grid monitoring portal and its integration with {G}oogle {M}aps}, institution = {Grid Computing and Distributed Systems Laboratory, The University of Melbourne}, year = {2006}, type = {Technical Report}, number = {GRIDS-TR-2006-8}, address = {Melbourne, Australia}, month = may # {~12}, pdf = {G/Gibb-H-2006-Gridscape.pdf}, timestamp = {2006.07.04}, url = {http://arxiv.org/abs/cs.DC/0605053} } @comment{jabref-meta: selector_journal:} @comment{jabref-meta: selector_author:} @comment{jabref-meta: selector_keywords:} @comment{jabref-meta: selector_publisher:}

Ignore Space Show notes View

TOIT_2006/Map_Visualisation.bib 0 → 100644

This file was created with JabRef 2.1 beta.
Encoding: ISO8859_1

@STRING{acj = {Australian Computer Journal}}

@STRING{adt = {Application Development Trends}}

@STRING{ai = {Artificial Intelligence}}

@STRING{ajis = {Australian Journal of Information Systems}}

@STRING{cacm = {Commun.\ ACM}}

@STRING{cj = {Comput.\ J.}}

@STRING{asper = {ACM SIGMETRICS Perf.\ Eval.\ Review}}

@STRING{database = {ACM SIGMIS Database}}

@STRING{dbms = {DBMS Magazine}}

@STRING{dbpd = {Database Programming {\&} Design}}

@STRING{develop = {{d}evelop, The Apple Technical Journal}}

@STRING{directions = {Apple Directions}}

@STRING{dke = {Data {\&} Knowledge Engineering}}

@STRING{ejis = {European Journal of Information Systems}}

@STRING{idt = {Internet Development Trends}}

@STRING{ieeec = {IEEE Comput.}}

@STRING{ieees = {IEEE Softw.}}

@STRING{ijast = {International Journal of Applied Software Technology}}

@STRING{ijgis = {International Journal of Geographical Information Systems}}

@STRING{ijhcs = {International Journal of Human-Computer Studies}}

@STRING{ijmms = {International Journal of Man-Machine Studies}}

@STRING{ijseke = {International Journal of Software Engineering and Knowledge Engineering}}

@STRING{is = {Information Systems}}

@STRING{isj = {Information Systems Journal}}

@STRING{ist = {Inf.\ Softw.\ Tech.}}

@STRING{jacm = {Journal of the ACM}}

@STRING{jlp = {Journal of Logic Programming}}

@STRING{jot = {Journal of Object Technology}}

@STRING{jss = {J.\ Syst.\ Softw.}}

@STRING{lncs = {Lecture Notes in Computer Science}}

@STRING{misq = {MIS Quarterly}}

@STRING{nzjc = {New Zealand Journal of Computing}}

@STRING{nzjis = {New Zealand Journal of Information Systems}}

@STRING{oracle = {Oracle Magazine}}

@STRING{reg = {\scriptsize\textsuperscript{\textregistered}}}

@STRING{sej = {Software Engineering Journal}}

@STRING{sigmod = {ACM SIGMOD Record}}

@STRING{spe = {Software---Practice and Experience}}

@STRING{surveys = {ACM Comput.\ Surv.}}

@STRING{tkde = {IEEE Trans.\ Knowl.\ Data Eng.}}

@STRING{tm = {\scriptsize\texttrademark}}

@STRING{tocs = {ACM Trans.\ Comput.\ Syst.}}

@STRING{tods = {ACM Trans.\ Database Syst.}}

@STRING{toit = {ACM Trans.\ Internet Tech.}}

@STRING{tose = {IEEE Trans.\ Softw.\ Eng.}}

@STRING{tweb = {ACM Trans.\ Web}}

@STRING{vldb = {The VLDB Journal}}

@BOOK{Dodg-M-2001-cybermap,
  title = {Mapping Cyberspace},
  publisher = {Routledge},
  year = {2001},
  author = {Martin Dodge and Rob Kitchin},
  address = {London, UK},
  timestamp = {2006.07.04}
}

@MISC{IP2L-C-2006-GeoIP,
  author = {IP2Location},
  title = {{IP2L}ocation} # tm # {: {B}ringing geography to the {I}nternet},
  howpublished = {\url{http://www.ip2location.com/}, IP2Location.com},
  month = jul,
  year = {2006},
  note = {Accessed on 18 July 2006.},
  timestamp = {2006.07.18},
  url = {http://www.ip2location.com/}
}

@MISC{Maxm-G-2006-GeoIP,
  author = {Maxmind},
  title = {Geo{IP}: {IP} address location technology},
  howpublished = {\url{http://www.maxmind.com/app/ip-location}, Maxmind LLC},
  month = jul,
  year = {2006},
  note = {Accessed on 18 July 2006.},
  timestamp = {2006.07.18},
  url = {http://www.maxmind.com/app/ip-location}
}

@MISC{Maxm-G-2006-GeoLiteCity,
  author = {Maxmind},
  title = {Geo{L}ite {C}ity: Free {IP} address to city database},
  howpublished = {\url{http://www.maxmind.com/app/geolitecity}, Maxmind LLC},
  month = jul,
  year = {2006},
  note = {Accessed on 18 July 2006.},
  timestamp = {2006.07.18},
  url = {http://www.maxmind.com/app/geolitecity}
}

@MISC{Sale-A-2006-stats,
  author = {Arthur Sale and Christian McGee},
  title = {Tasmania {S}tatistics {S}oftware},
  howpublished = {\url{http://eprints.comp.utas.edu.au:81/archive/00000262/},
  	University of Tasmania, Hobart, Australia},
  month = {12~} # feb,
  year = {2006},
  note = {Accessed on 7 March 2006.},
  timestamp = {2006.07.11},
  url = {http://eprints.comp.utas.edu.au:81/archive/00000262/}
}

@MISC{Goog-M-2006-maps,
  author = {Google},
  title = {Google {M}aps {API}},
  howpublished = {\url{http://maps.google.com/apis/maps/}},
  year = {2006},
  note = {Accessed on 18 July 2006.},
  timestamp = {2006.07.18},
  url = {http://maps.google.com/apis/maps/}
}

@MISC{Bout-T-2004-GD,
  author = {Thomas Boutell},
  title = {{GD} {G}raphics {L}ibrary},
  howpublished = {\url{http://www.boutell.com/gd/}},
  year = {2004},
  note = {Updated on 3 November 2004; accessed on 18 July 2006.},
  timestamp = {2006.07.18},
  url = {http://www.boutell.com/gd/}
}

@ARTICLE{Offu-J-2002-quality,
  author = {Jeff Offutt},
  title = {Quality attributes of {W}eb software applications},
  journal = ieees,
  year = {2002},
  volume = {19},
  pages = {25--32},
  number = {2},
  month = mar # {/} # apr,
  doi = {doi:10.1109/52.991329},
  pdf = {O/Offu-J-2002-quality.pdf},
  timestamp = {2006.07.04}
}

@ARTICLE{Jian-B-2000-cybermap,
  author = {Bin Jiang and Ferjan Ormeling},
  title = {Mapping cyberspace: {V}isualizing, analysing and exploring virtual
	worlds},
  journal = {The Cartographic Journal},
  year = {2000},
  volume = {37},
  pages = {117--122},
  number = {2},
  month = dec,
  pdf = {J/Jian-B-2000-cybermap.pdf},
  timestamp = {2006.07.04},
  url = {http://www.hig.se/~bjg/cybermap2000.pdf}
}

@ARTICLE{Eick-SG-2001-sitevis,
  author = {Stephen G.\ Eick},
  title = {Visualizing online activity},
  journal = cacm,
  year = {2001},
  volume = {44},
  pages = {45--50},
  number = {8},
  month = aug,
  doi = {http://doi.acm.org/10.1145/381641.381710},
  pdf = {E/Eick-SG-2001-sitevis.pdf},
  timestamp = {2006.07.04}
}

@INPROCEEDINGS{Wood-J-1996-vis,
  author = {Jason Wood and Ken Brodlie and Helen Wright},
  title = {Visualization over the {W}orld {W}ide {W}eb and its application to
	environmental data},
  booktitle = {Proceedings of IEEE Visualization '96},
  year = {1996},
  editor = {Roni Yagel and Gregory M.\ Nielson},
  pages = {81--86},
  address = {San Francisco, California},
  month = oct # {~27--} # nov # {~1},
  organization = {IEEE Computer Society and ACM},
  pdf = {W/Wood-J-1996-vis.pdf},
  timestamp = {2006.07.24},
  url = {http://portal.acm.org/citation.cfm?id=245010&dl=ACM&coll=GUIDE&CFID=15151515&CFTOKEN=6184618}
}

@MISC{CIA-WFB-2006,
  author = {{CIA}},
  title = {The {W}orld {F}actbook},
  howpublished = {\url{https://www.cia.gov/cia/publications/factbook/},
	Central Intelligence Agency, Washington, DC, USA},
  year = {2006},
  timestamp = {2006.08.07},
  url = {https://www.cia.gov/cia/publications/factbook/}
}

@INPROCEEDINGS{Saya-A-2006-GISWS,
  author = {Ahmet Sayar and Marlon Pierce and Geoffrey Fox},
  title = {Integrating {AJAX} approach into {GIS} visualization web services},
  booktitle = {Proceedings of the Advanced International Conference on Telecommunications
	and International Conference on Internet and Web Applications and
	Services (AICT/ICIW 2006)},
  year = {2006},
  pages = {169--175},
  address = {Guadeloupe, French Caribbean},
  month = {19--25~} # feb,
  publisher = {IEEE Computer Society},
  doi = {http://doi.ieeecomputersociety.org/10.1109/AICT-ICIW.2006.114},
  pdf = {S/Saya-A-2006-GISWS.pdf},
  timestamp = {2006.08.07}
}

@TECHREPORT{Garr-JJ-2005-Ajax,
  author = {Jesse James Garrett},
  title = {Ajax: {A} new approach to web applications},
  institution = {Adaptive Path, LLC},
  year = {2005},
  type = {Web essay,
	\url{http://www.adaptivepath.com/publications/essays/archives/000385.php}},
  timestamp = {2006.08.07},
  url = {http://www.adaptivepath.com/publications/essays/archives/000385.php}
}

@ARTICLE{Bates-PC-1995-distdebug,
  author = {Peter C.\ Bates},
  title = {Debugging heterogeneous distributed systems using event-based models
	of behavior},
  journal = tocs,
  year = {1995},
  volume = {13},
  pages = {1--31},
  number = {1},
  month = feb,
  doi = {http://doi.acm.org/10.1145/200912.200913},
  pdf = {B/Bates-PC-1995-distdebug.pdf},
  timestamp = {2006.08.07}
}

@ARTICLE{Ensl-PH-1978-distributed,
  author = {P.\ H.\ Enslow},
  title = {What is a ``distributed'' data processing system},
  journal = ieeec,
  year = {1978},
  volume = {1},
  pages = {13--21},
  number = {1},
  month = jan,
  timestamp = {2006.08.07}
}

@ARTICLE{Barf-P-1999-webperf,
  author = {Paul Barford and Mark Crovella},
  title = {Measuring {W}eb performance in the wide area},
  journal = asper,
  year = {1999},
  volume = {27},
  pages = {37--48},
  number = {2},
  month = sep,
  doi = {http://doi.acm.org/10.1145/332944.332953},
  pdf = {B/Barf-P-1999-webperf.pdf},
  timestamp = {2006.07.04}
}

@TECHREPORT{Gibb-H-2006-Gridscape,
  author = {Hussein Gibbins and Rajkumar Buyya},
  title = {Gridscape {II}: {A} customisable and pluggable grid monitoring portal
	and its integration with {G}oogle {M}aps},
  institution = {Grid Computing and Distributed Systems Laboratory, The University
	of Melbourne},
  year = {2006},
  type = {Technical Report},
  number = {GRIDS-TR-2006-8},
  address = {Melbourne, Australia},
  month = may # {~12},
  pdf = {G/Gibb-H-2006-Gridscape.pdf},
  timestamp = {2006.07.04},
  url = {http://arxiv.org/abs/cs.DC/0605053}
}

@comment{jabref-meta: selector_journal:}

@comment{jabref-meta: selector_author:}

@comment{jabref-meta: selector_keywords:}

@comment{jabref-meta: selector_publisher:}

Ignore Space Show notes View TOIT_2006/Map_Visualisation.tex 0 → 100644
\documentclass[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 useful approach to visualizing the geographical distribution of web site hits is to geolocate the IP addresses of hits and plot them on a world map. This can be achieved by dynamic generation and display of map images at the server and/or the client. This paper compares the scalability with respect to source data size of four techniques for dynamic map generation and display: generating a single composite map image, overlaying transparent images on an underlying base map, overlaying CSS-enabled HTML on an underlying base map and generating a map using Google Maps. These four techniques embody a mixture of different display technologies and distribution styles. The results show that all four techniques are suitable for small data sets, but that the latter two techniques scale poorly to larger 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{downloads, geolocation, geovisualization, scalability, Google Maps, distribution style, dynamic map generation} \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 the site, so as to decide where best to target marketing resources. One approach to doing so is to plot geographical locations 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. The author's interest in this area derives from implementing a pilot digital institutional repository for the University of Otago School of Business\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. This repository quickly attracted interest from around the world and the number of abstract views and document downloads began to steadily increase. There was great interest within the University in tracking this increase, particularly with respect to where in the world the hits were coming from. The EPrints statistics management software developed at the University of Tasmania \cite{Sale-A-2006-stats} proved very useful in this regard, providing 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 greater detail beyond the country level, nor does it provide any visual clues as to the spatial distribution of hit sources around the globe. \begin{figure} \centering \includegraphics[width=\textwidth,keepaspectratio]{tasmania_stats} \caption{A portion of the by-country display for the Otago EPrints repository, generated by the Tasmania statistics software \protect\cite{Sale-A-2006-stats}.} \label{fig-tas-stats} \end{figure} The author therefore began to explore possible techniques for plotting repository hit data onto a world map, with the aim of adding this capability to the Tasmania statistics package. Preference was given to techniques that could be used within a modern web browser without the need to manually install additional client software, so as to make the new feature available to the widest possible audience and reduce 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 geovisualize web activity. \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 called \emph{Palantir}, which was written as a Java applet and 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, with fairly crude results \cite{Lamm-SE-1996-webvis}. 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 and detailed databases were commercially available at the time \cite[p.\ 1466]{Lamm-SE-1996-webvis}, but were not generally 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 services\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 these prior systems can generally be divided into two classes. The first class of techniques generate a single bitmap image that contains both the map and the graphics representing web hits. This can be achieved by programmatically plotting points onto a base map image; the composite image is then displayed at the client. This class of techniques shall henceforth be referred to as \emph{single-layer} techniques. The second class of techniques separately return both a base map image and some kind of overlay containing the plotted points. The overlay and the base map are then displayed as separate items at the client. This class of techniques shall henceforth be referred to as \emph{multi-layer} techniques. Both classes of techniques have been used in the aforementioned systems, but multi-layer techniques appear to have been the most prevalent. For example, Palantir used a multi-layer technique, in which 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 interactive maps within web pages. Google Maps is a dynamic multi-layer technique that has only become feasible relatively recently with the advent of widespread support for CSS positioning and Ajax technologies \cite{Garr-JJ-2005-Ajax} in many browsers. Multi-layer techniques enjoy a particular advantage over single-layer techniques, in that they provide the potential for a more flexible GIS-like interaction with the map, with multiple layers that can be activated and deactivated as desired. This flexibility could explain why such techniques appear more prevalent in the literature. As will be seen shortly, however, web-based multi-layer techniques tend to rely either on the installation of additional client-side software, or on more recent web technologies such as CSS and Ajax. Single-layer techniques, in contrast, typically do not rely on these things. Single-layer techniques should therefore be portable to a wider range of client and server environments. Each map generation and display technique comprises a specific technology or collection of technologies (such as transparent bitmap overlays + CSS positioning), implemented using a specific distribution style. For example, a particular single-layer technique might be implemented completely server-side while another might use a mixture of server-side and client-side processing. Similarly, multi-layer techniques may adopt different distribution styles, and the overlays themselves might take the form of transparent images, absolutely positioned HTML elements, dynamically generated graphics, etc. Given the wide variety of possible techniques that were available, the next question was which techniques would be most suitable? Ideally, a technique should not only efficiently fulfil the task of plotting repository hits on a map, but also provide tangible benefits to end-users. Scalability is a key issue for web applications in general \cite[p.\ 28]{Offu-J-2002-quality}, and for online activity visualization in particular \cite[p.\ 50]{Eick-SG-2001-sitevis}, so techniques that could scale to a large number of points were of particular interest. For example, at the time of writing the Otago EPrints repository had been accessed from 13,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 16,000. Informal testing with these data suggested that a single-layer composite map image would perform well with this volume of data, taking at most a few seconds to load and display. Conversely, it appeared that Google Maps would not perform well, taking on the order of minutes to load and display a map containing a few thousand points. The range of techniques was first narrowed down 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}. The scalability of these four techniques was then tested to determine how well each technique handled large numbers of points. A series of experiments was conducted on each technique with progressively larger synthetic data sets, and the data set volume, elapsed time and memory usage were measured. The experimental design is discussed in Section~\ref{sec-experiment}. Informal tests suggested that the server-side image generation and the server-side image overlay techniques would scale best, and this was borne out by the results of the experiments, which show that both techniques scale reasonably well to very large numbers of points. The other two techniques proved to be reasonable for relatively small 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}. It should be noted that the intent of the experiments was not to identify statistically significant differences in performance across the four techniques. It was expected that variations across techniques would be reasonably clear-cut, and the experiments were designed to test this expectation. However, the two best performing techniques, server-side image generation and server-side image overlay, produced very similar results, so a more formal statistical analysis of these techniques may be warranted. This and other possible future directions are discussed in Section~\ref{sec-conclusion}. \section{Technique selection} \label{sec-techniques} In this section the four techniques that were chosen for testing are discussed in more detail, along with the reasons for choosing these particular techniques. First, the impact of distribution style on the choice of technique is discussed. This is followed by an examination of how each 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 a multi-layer technique using this distribution style \cite{Papa-N-1998-Palantir}, where the source data were generated at the server and the map was generated, displayed and manipulated by a Java applet running at the client. The data server distribution style can provide a very dynamic and interactive environment to the end user, but clearly requires support for executing application code within the web browser, typically using something like JavaScript, Java applets or Flash. JavaScript is now tightly integrated into most browsers, but the same cannot be said for either Java or Flash. That is, the existence of a Java virtual machine or Flash plugin cannot necessarily be guaranteed in every browser, which violates the requirement to avoid manual installation of additional client-side software. Java- or Flash-based data server techniques can therefore be eliminated from consideration, but JavaScript-based data server techniques are feasible. Indeed, Google Maps is an example of such a technique (see Section~\ref{sec-overlay}). \begin{figure} \centering \begin{tabular}{ccc} \includegraphics[scale=0.9]{data_server} & \qquad & \includegraphics[scale=0.9]{image_server} \\ \footnotesize (a) Data server & \qquad & \footnotesize (b) Image server \\ \\ \\ \includegraphics[scale=0.9]{model_interaction} & \qquad & \includegraphics[scale=0.9]{shared} \\ \footnotesize (c) Model interaction environment & \qquad & \footnotesize (d) Shared environment \\ \end{tabular} \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} Conversely, the \emph{image server} style is where the display is created and manipulated entirely at the server and is only passively 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. The downside is that the resultant visualization can tend to be very static and non-interactive in nature, as it is typically just a simple bitmap image. The \emph{model interaction environment} style is where a model created at the server can be explored at the client, as illustrated in Figure~\ref{fig-distribution-styles}(c). \citeN{MacE-AM-1998-GIS} calls this the ``3D model interaction'' style, but this 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. ``Model interaction environment'' therefore seems a more appropriate name for this style. 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 at the server and downloaded to the client. Similar restrictions apply to techniques using this style as to the data server style, so Java- and Flash-based model interaction environment techniques can be eliminated from consideration. For similar reasons, solutions such as VRML or SVG that require external browser plugins can also be eliminated (although native support for SVG is beginning to appear in some browsers). It may be possible to implement this distribution style using only client-side JavaScript, but it is presently unclear as to how effective this might be. Finally, the \emph{shared environment} style is where data manipulation is done at the server, but control of that manipulation, and 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. Ajax technologies can easily support this kind of distribution style. For example, \citeN{Saya-A-2006-GISWS} use Ajax to integrate Google Maps with existing GIS visualization web services. Specific shared environment techniques can be eliminated from consideration based on the same criteria as were applied to the other three styles (e.g., no Java- or Flash-based techniques). \subsection{Single-layer techniques} \label{sec-image-gen} As noted earlier, single-layer techniques work by directly plotting 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 latitude/longitude coordinates into projected map coordinates on the base map (for example, the PROJ.4 cartographic projections library\footnote{\url{http://www.remotesensing.org/proj/}}). \begin{figure} \centering \includegraphics[width=\textwidth,keepaspectratio]{ImageGeneration-full} \caption{Sample output from the (single-layer) server-side image generation technique.} \label{fig-image} \end{figure} Single-layer techniques could use any of the distribution styles 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 only single-layer techniques that use the image server distribution style (or \textbf{server-side image generation} techniques) are considered here. For this research, the author chose a representative server-side image generation technique based on the GD and PROJ.4 libraries. Server-side image generation techniques provide some distinct advantages. They are relatively simple to implement and are fast at producing the final image, mainly because they use existing, well-established technologies. They are also bandwidth efficient, because the size of the generated map image is determined by its pixel dimensions and the compression method used, rather than by the number of points to be plotted. The amount of data to be sent to the client should therefore remain more or less constant, regardless of the number of points plotted. Server-side image generation techniques also have 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 copyright issues. Second, the compression method used to produce the final composite map image can have a significant impact on visual quality. For example, lossy compression methods such as JPEG can make the points plotted on the map appear distinctly fuzzy or ``muddy'', even at high quality levels. Lossless compression methods such as PNG avoid this problem, but may produce larger files for the same image. Finally, it is harder to provide interactive map manipulation features with server-side image generation techniques, as the output is a simple static image. Anything that changes the content of the map (such as panning or changing the visibility of certain points) will require the entire image to be regenerated. Zooming could be achieved if a very high resolution base map image was available, but the number of possible zoom levels is likely to be restricted. \subsection{Multi-layer techniques} \label{sec-overlay} Multi-layer techniques also involve plotting points onto a base map image, but they differ from single-layer techniques in that the points are not plotted directly onto the base map image. Rather, the points are displayed as an independent overlay on top of the base map image. This provides a significant advantage over single-layer techniques, as it enables the possibility of multiple independent layers that can be individually shown or hidden. This is very similar to the multi-layer functionality provided by a GIS, and is an effective way to provide interactive visualizations of geographic data \cite{Wood-J-1996-vis,MacE-AM-1998-GIS}. There is still the problem of finding a suitable base map image, however. Until relatively recently, implementing multi-layer techniques would likely have required additional software to be installed at the client, but most modern browsers now support absolute positioning of HTML elements using CSS. This enables the creation of a map overlay using nothing more than HTML, CSS and a few bitmap images. The author has identified two main alternatives for producing such an overlay, which can be 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 (in the author's implementation, the output looks essentially identical to that shown in Figure~\ref{fig-image} on page~\pageref{fig-image}). This requires the overlay image to be in either PNG or GIF format, as JPEG does not support transparency. The overlay image is likely to contain considerable ``white space'', which compresses very well, so use of a lossless compression method should not be an issue. This also eliminates the image quality issue noted earlier. The size of the image overlay will generally be proportional to the number of points to be plotted, but the image compression should moderate this. As noted in Section~\ref{sec-image-gen}, generating images at the client would require additional software to be installed, so only the data server distribution style will be considered here for image overlays (i.e., \textbf{server-side image overlay}). That is, both the base map image and the overlay(s) are generated at the server. An HTML overlay comprises a collection of HTML elements corresponding to the points to be plotted, which are positioned over the base map image using CSS absolute positioning. There is considerable flexibility as to the types of elements that could be used to construct the overlay. One possibility is to use \verb\|<IMG>\| elements to place icons on the base map, which appears to be the approach adopted by Google Maps (see Figure~\ref{fig-google}). Another possibility is to use appropriately sized and colored \verb\|<DIV>\| elements, which then appear as colored blocks ``floating'' over the base map image (in the author's implementation, the output looks essentially identical to that shown in Figure~\ref{fig-image} on page~\pageref{fig-image}). \begin{figure} \centering \includegraphics[width=\textwidth,keepaspectratio]{GoogleMap-full.png} \caption{Sample output from the (multi-layer) 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, not images. This can be easily achieved using client-side JavaScript, so HTML overlays can use any of the distribution styles discussed in Section~\ref{sec-distribution} without violating the requirement to avoid additional client-side software. Two representative HTML overlay techniques have thus been adopted for the experiments: \textbf{server-side HTML overlays} (using the image server distribution style) and \textbf{Google Maps} (using the data server distribution style). Since Google Maps uses \verb\|<IMG>\| elements, \verb\|<DIV>\| elements have been used for the server-side HTML overlay. Server-side HTML overlays are actually slightly simpler to implement than either server-side image generation or image overlays, because it is not necessary to write any code to generate or manipulate images (the base map image is static and thus requires no additional processing). All that is required is code to transform latitude/longitude coordinates into projected map coordinates and generate corresponding \verb\|<DIV>\| elements. Google Maps \cite{Goog-M-2006-maps} is a more complex proposition. This technique uses the data server distribution style, where JavaScript code running within the browser enables the client to manipulate the base map and its overlays. Data and map images are requested asynchronously from the server as required using Ajax technologies, which seems to imply that Google Maps in fact uses the shared environment distribution style. However, the server has no involvement beyond simply supplying data to the client. In the shared environment distribution style, the server is directly involved in manipulating the map, under the control of the client. This is clearly not the case with Google Maps. The primary advantage of Google Maps is the powerful and compelling functionality it provides for generating and interacting with the map. Users may pan the map in any direction and zoom to many different levels of detail. A satellite imagery view is also available. In addition, further information about each point plotted (such as the name of the city) can be displayed in a callout attached to the point, as shown in Figure~\ref{fig-google}. Google Maps also has a proven record for visualization of network resources. For example, \citeN{Gibb-H-2006-Gridscape} use Google Maps to visualize and manage world-wide computing grids. 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 this research.}. First, it is a distributed application, thus making it more complex to implement, test and debug \cite{Bates-PC-1995-distdebug,Ensl-PH-1978-distributed}. Second, the server must have a registered API key from Google, which is verified every time that a page attempts to use the API. Similarly, the client must connect to Google's servers in order to to download the API's JavaScript source. This means that the technique requires an active Internet connection in order to work. Finally, the Google Maps API does not currently provide any way to toggle the visibility of markers on the map, so it is not possible to implement the interactive ``layers'' mentioned at the start of this section. (It is possible, of course, that Google may implement this feature in a future version of the API.) The most significant disadvantage of all HTML overlay techniques, however, is that the size of the HTML overlay is directly proportional to the number of points to be plotted. There will be one overlay element (\verb\|<DIV>\| or \verb\|<IMG>\|) per point, so a very large number of points will result in an even larger amount of HTML source being generated. It is expected that this will lead to excessive browser memory usage for large data sets, and consequently that these techniques will not scale well at the high end. However, they may still be appropriate 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, a series of experiments was undertaken to test the scalability of the four chosen techniques. Each technique was tested using the same collection of progressively larger synthetic data sets. The first data set comprised one point at the South Pole. A regular grid of points at one degree intervals was then constructed by progressively incrementing the latitude and longitude, with each data set being twice the size of its predecessor. 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 result of plotting the 16,384-point data set is shown in Figure~\ref{fig-grid-points}. The grid spacing used meant that 64,800 points were sufficient to fill the entire map, so the five largest data sets had many duplicate points. This does not affect the results of the experiments, however, as it is the total number of points that is significant, not their location. \begin{figure} \centering \includegraphics[width=\textwidth,keepaspectratio]{16384_points} \caption{The 16,384-point data set plotted on the base map.} \label{fig-grid-points} \end{figure} The focus on scalability meant that the primary measures of interest were page load time, memory usage and the volume 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 and other ancillary material to the client across the network, and the time taken by the client to display the map. Unfortunately, as noted in Section~\ref{sec-overlay}, the Google Maps technique requires an active Internet connection, so the experiments could not be run on an isolated network. This meant that traffic on the local network was a potential confounding factor. It was therefore decided to eliminate network performance from the equation by running both the server and the client on the same machine\footnote{A Power Macintosh G5 1.8\,GHz (single processor) 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 independent measurement of the times for data generation and page display, thus simplifying the process of data collection and also ensuring that the client and server processes did not unduly interfere with each other, despite running on the same machine. It could be argued that network performance would still have a confounding effect on the Google Maps technique, but this would only be likely for the initial download of the API (comprising about 235\,kB of JavaScript source and images), which would be locally cached thereafter. The API key verification does occur every time a map is loaded, but the amount of data involved is very small, so it is less likely 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, its size, the time taken to generate it, the time taken to display the resultant map in the browser, and the amount of real and virtual memory used by the browser during the test were recorded. It was also intended to measure the memory usage of the server, but this proved more difficult to isolate than expected, and was thus dropped from the experiments. The data set generation time and browser memory usage were measured using the \texttt{time} and \texttt{top} utilities respectively (the latter was run after each test run to avoid interference). 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 an excessive amount of time to complete. Further testing for a particular technique was generally halted when a single test run took longer than about five minutes, as by this stage performance had already deteriorated well beyond usable levels. The web browser was quit and reloaded afresh before each group of tests. \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 arguments---such as the number of points to be plotted---to be passed 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 dispatcher page included a standard \verb\|<IMG>\| element that called the Perl script. This script loaded a base map PNG image, plotted points directly onto it, and returned the composite map to the client as a JPEG image (with the ``quality'' parameter set to 90). \item[server-side image overlay] The dispatcher page included two \verb\|<IMG>\| elements, the first for the base map and the second for the overlay, both with identical CSS positioning attributes. The first \verb\|<IMG>\| simply loaded a static JPEG image representing the base map. The second \verb\|<IMG>\| called the Perl script, which generated and returned the overlay as a transparent PNG image. \item[server-side HTML overlay] The dispatcher page included an \verb\|<IMG>\| element for the base map and a \verb\|<DIV>\| element for the overlay, both with identical CSS positioning attributes. The \verb\|<IMG>\| simply loaded a static JPEG image representing the base map. The \verb\|<DIV>\| contained inline PHP code that called the Perl script. This in turn generated and returned the overlay as a collection of CSS-positioned \verb\|<DIV>\| elements, nested within the top-level \verb\|<DIV>\| element. \end{description} For all of these techniques, the base map image was 1,024 \(\times\) 520 pixels. In PNG format it occupied approximately 1.2\,MB (but this version was never returned to the client), while in JPEG format (Q=90) it occupied approximately 180\,kB. The base map image was derived from an original 3,599 \(\times\) 1,826 pixel image, which was part of a collection of maps released into the public domain by the \citeN{CIA-WFB-2006}. All three techniques used the PROJ.4 cartographic projections library to convert latitude/longitude pairs into projected map coordinates, while the first two techniques also used the GD graphics library to programmatically generate and manipulate images. The Google Maps technique was implemented using the data server distribution style. As with the other three techniques, a PHP dispatcher page was used. This time, however, the page included client-side JavaScript code to load and initialize 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 asynchronously call a server-side Perl script, which 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} As noted in the introduction, 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. There has not, therefore, been any statistical analysis carried out on the results. The remainder of this section will discuss the results for data size, page load time and memory usage. Because the number of points in each data set increases in powers of two, log-log scales have been used for all plots. \subsection{Data size} For each data set, the data generated by the server was saved to a file and its size in bytes recorded. In the case of the server-side image generation and server-side image overlay techniques, the file comprised a bitmap image; whereas for the server-side HTML overlay and Google Maps techniques, the file comprised HTML or XML text, respectively. In addition to the generated data, there was a certain amount of fixed overhead associated with each technique tested, as summarized in Table~\ref{tab-overhead}. This overhead comprised static files that were always downloaded to the client regardless of the number of points to be plotted. Examples of fixed overhead items include the base map image, various icons, the PHP source of the dispatcher page and the JavaScript source for the Google Maps API. \begin{acmtable}{11cm} \centering \begin{tabular}{lll} Technique & Fixed overhead & Content \\ \hline Server-side image generation & 629\,bytes & \textbf{dispatcher (PHP)}\medskip \\ Server-side image overlay & \(\approx\) 181\,kB & dispatcher (PHP) \\ & & \textbf{base map image (JPEG)}\medskip \\ Server-side HTML overlay & \(\approx\) 181\,kB & dispatcher (PHP) \\ & & \textbf{base map image (JPEG)}\medskip \\ Google Maps & \(\approx\) 235\,kB & dispatcher (PHP) \\ & & base map image tiles (PNG) \\ & & \textbf{API (JavaScript)} \\ & & various icons (PNG) \\ \end{tabular} \caption{Fixed overhead for each technique. The largest contributing item for each technique is shown in \textbf{bold face}.} \label{tab-overhead} \end{acmtable} \begin{figure} \centering \includegraphics[scale=0.55]{data_size} \caption{Comparison of generated data size for each technique (log-log scale).} \label{fig-data-size} \end{figure} The volume of data generated by each technique, including fixed overhead, is shown in Figure~\ref{fig-data-size}. It is immediately apparent from these results that there is a divergence between the two techniques that generate images (server-side image generation and server-side image overlay), and the two techniques that generate text (server-side HTML overlay and Google Maps). Both the server-side image generation and server-side image overlay techniques scale particularly well with regard to the amount of data generated. Interestingly, the amount of data generated by the image generation technique increases by about 8\,kB up to the 8,192-point data set, but then \emph{drops} by about 90\,kB over the next three data sets. This occurs because the number of points plotted has become sufficient to cover most of the base map. This means that a large portion of the composite map image is a single color (see Figure~\ref{fig-grid-points} on page~\pageref{fig-grid-points} for an example), which compresses more efficiently. The amount of data generated by the image overlay technique appears constant, but actually increases by about 2\,kB across the range. This has important implications for the ability of this technique to handle multiple layers. Because the overlay images are quite small (less than 2\,kB for up to one million points), it should be feasible to pre-load several overlay images into a client-side array and switch them on and off as desired. The server-side HTML overlay and Google Maps techniques clearly do not scale well with respect to data size, and begin to visibly diverge from the other two techniques once the amount of data generated exceeds about 5\% of the fixed overhead. For the HTML overlay technique this occurs somewhere between 64 and 128 points, whereas for Google Maps it occurs somewhere between 256 and 512 points. The divergence increases rapidly for both techniques beyond these points, with the HTML overlay technique suffering the most. The latter occurs because the HTML overlay technique needs to generate additional CSS attributes (i.e., more text) in order to correctly position the \verb\|<DIV>\| elements, whereas the Google Maps technique needs only to return a more compact list of latitude/longitude coordinates. \subsection{Page load time} For each test run, both the length of time taken to generate the data at the server and to display the page in the client browser were recorded. The former is illustrated in Figure~\ref{fig-data-generation-time} and the latter in Figure~\ref{fig-page-load-time}. The combined time (data generation + display time) is shown in Figure~\ref{fig-combined-time}. \subsubsection{Data generation time} \begin{figure} \centering \includegraphics[scale=0.55]{data_generation_time} \caption{Comparison of data generation time for each technique (log-log scale).} \label{fig-data-generation-time} \end{figure} The results (see Figure~\ref{fig-data-generation-time}) show that the length of time taken to generate the source data increases in proportion to the number of points to be plotted, as expected. It is interesting to note the differences in data generation time for each technique, however. Data generation for both of the ``text-based'' techniques (HTML overlay and Google Maps) is generally faster than for the ``image-based'' techniques (image generation and image overlay). The results show that server-side image generation generally takes the longest to generate its data. This is because it not only has to map points from latitude/longitude into projected map coordinates, but also must plot these points onto the base map image, then compress the composite image as a JPEG. The image to be compressed is also moderately complex, which only adds to the data generation time. Server-side image overlay performs somewhat better because it uses a less complex compression method (PNG) and the image to be compressed is much simpler (a collection of colored points on a blank background). The server-side HTML overlay technique appears faster at generating data than either of the two image-based techniques at the low end, but is similar in performance at the high end. In this technique the server only needs to map latitude/longitude to projected map coordinates; no images need to be generated and there is no compression to deal with. At the high end, however, this advantage is clearly offset by the significant volume of data being generated. Google Maps is faster again, because almost all processing is carried out on the client; the server's only involvement is to generate a simple list of latitude/longitude coordinates. In terms of data generation, it appears that all techniques tested scale reasonably well. The image-based techniques perform worse at the low end because they involve more complex processing than the text-based techniques, but this is offset at the high end by the relatively constant amount of data generated. Conversely, the text-based techniques perform better at the low end, but are negatively impacted at the high end by the sheer volume of data produced (tens or hundreds of megabytes vs.\ hundreds of kilobytes). \subsubsection{Map display time} \begin{figure} \centering \includegraphics[scale=0.55]{page_load_time} \caption{Comparison of map display time for each technique (log-log scale).} \label{fig-page-load-time} \end{figure} These results (see Figure~\ref{fig-page-load-time}) reveal quite a spectacular difference between the image-based and text-based techniques. The time taken to display the map is essentially constant for both of the image-based techniques, regardless of the number of points to be plotted. This is not surprising given that the size of the generated data is also essentially constant, and that the browser is simply loading and displaying static images. The image overlay technique appears slightly slower than the image generation technique. This is probably because the image overlay technique has to load two images from the server (the base map and the overlay), compared to one image for the image generation technique. In contrast, the text-based techniques clearly do not scale well with respect to map display time. Google Maps suffers particularly in this regard, with display time exceeding ten seconds shortly past 512 points. Testing was abandoned at 4,096 points, with a single test run taking over seven minutes. The HTML overlay technique fares better, exceeding ten seconds somewhere between 4,096 and 8,192 points. Testing was abandoned at 32,768 points, with a single test run taking almost ten minutes. \subsubsection{Combined time} \begin{figure} \centering \includegraphics[scale=0.55]{combined_time} \caption{Comparison of combined page load time for each technique (log-log scale).} \label{fig-combined-time} \end{figure} Combining the data generation and map display times (see Figure~\ref{fig-combined-time}) yields little change in the curves for the text-based techniques, because the data generation times are very small compared to the map display times. There is a more obvious impact on the image-based techniques, with both techniques remaining more or less constant up to about 2,048 points, then slowing as the number of points increases beyond that. However, the slowdown is nowhere near as dramatic as for the text-based techniques; even the largest data set only takes about nineteen seconds overall. The image overlay technique does display a slight advantage of about half a second over the image generation technique for the largest data set, but further experiments will be required to determine whether this difference is statistically significant. \subsection{Memory usage} Both the real and virtual memory usage of the browser were measured by running the \texttt{top} utility after each test run and observing the memory usage in each category. This provided the size of both the current ``working set'' and the total memory footprint of the browser process after it had completed a test run. The real memory results are shown in Figure~\ref{fig-real-memory} and the virtual memory results are shown in Figure~\ref{fig-virtual-memory}. \begin{figure} \centering \includegraphics[scale=0.55]{real_memory} \caption{Comparison of browser real memory usage for each technique (log-log scale).} \label{fig-real-memory} \end{figure} \begin{figure} \centering \includegraphics[scale=0.55]{virtual_memory} \caption{Comparison of browser virtual memory usage for each technique (log-log scale).} \label{fig-virtual-memory} \end{figure} While both sets of results display similar trends, the real memory data proved somewhat problematic. Real memory usage was generally consistent across test runs, but would also frequently fluctuate upwards by a factor of nearly two for no readily apparent reason. This is particularly apparent with the HTML overlay technique beyond 1,024 points. It seems likely that this was a result of other processes on the test machine interacting with the browser process in unexpected ways. There is some doubt therefore as to the validity of the real memory data, but they are at least broadly consistent with the virtual memory data. The virtual memory data proved more consistent overall, as the virtual memory footprint of a process is less likely to be impacted by other running processes. The results show that the two image-based techniques have essentially constant virtual memory usage of about 170\,MB regardless of the number of points plotted. This is to be expected, given that the size of the generated data is also essentially constant. The text-based techniques, however, clearly begin to diverge as the number of points increases. The HTML overlay technique starts to visibly diverge somewhere between 2,048 and 4,096 points, reaching a maximum of about 216\,MB at the point that testing was terminated. Google Maps starts to visibly diverge between 64 and 128 points, reaching a maximum of about 264\,MB at the point that testing was terminated. This is in line with the initial expectation for these techniques, that is, that memory usage would increase in proportion to the number of points to be plotted. \section{Conclusion and future work} \label{sec-conclusion} In this research, the scalability of four techniques for online geovisualization of web site hits was tested, with respect to the number of points to be plotted on the map. The four techniques tested were server-side image generation, server-side image overlay, server-side HTML overlay and Google Maps. The results clearly show that the server-side image generation and server-side image overlay techniques scale the best from small to large data sets. The HTML overlay and Google Maps techniques work well for small data sets, but their performance rapidly deteriorates as the size of the data set increases, to the point where they become unusable. Despite this clear difference in scalability, there are still some interesting questions remaining. The model interaction environment distribution style was not investigated in this research, as it was unclear whether this could be achieved using only client-side JavaScript. This is clearly an avenue for further investigation. In addition, the appearance of native SVG support in browsers means that this may become a viable option for implementing this distribution style in future. It was somewhat surprising that the server-side HTML overlay and Google Maps techniques exhibited no obvious consistency in where the different measures (data size, map display time and virtual memory usage) diverged, as shown in Table~\ref{tab-divergence}. Google Maps appears to exhibit greater consistency than HTML overlay in this respect, but it seems logical to expect some form of correlation, so further research will be required to investigate this. One possibility might be to implement an instrumented web browser and server in order to gather more precise data. \begin{acmtable}{11cm} \centering \begin{tabular}{lccc} Technique & Data size & Map display time & Virtual memory \\ \hline Server-side HTML overlay & 64--128 & 128--256 & 2,048--4,096 \\ Google Maps & 256--512 & 64--128 & 64--128 \\ \end{tabular} \caption{Approximate number of points at which each measure begins to visibly diverge, for the HTML overlay and Google Maps techniques.} \label{tab-divergence} \end{acmtable} Shortly after completing the experiments, the author discovered \emph{msCross Web\-gis}\footnote{\url{http://datacrossing.crs4.it/en_Documentation_mscross.html}}, an open source Google Maps clone. Its documentation implies that it may be possible to build a fully self-contained implementation that requires no external network access. This would enable testing on an isolated network with the client and server running on different machines. Measurements of network transfer time could then be included, and any issues arising from running the client and server on the same machine would be eliminated. This would require a distributed measurement infrastructure similar to that developed by \citeN{Barf-P-1999-webperf}. The overall aim of this work was to identify the best technique for plotting the large number of downloads and abstract views from the Otago School of Business digital repository. Based on the results, both the server-side HTML overlay and Google Maps techniques are clearly inappropriate for this task. This leaves a choice between two very similarly-performing techniques: server-side image generation and server-side image overlay. However, multi-layer techniques display many practical advantages over single-layer techniques, such as the ability to dynamically show and hide multiple overlays. These advantages provide greater flexibility and a more dynamic experience for end-users. Taking these end-user benefits into consideration, the server-side image overlay technique is the clear winner in this case. \begin{acks} The author would like to acknowledge Dr.\ Antoni Moore and Prof.\ George Benwell for their input into this research. \end{acks} \bibliography{Map_Visualisation} \begin{received} ... \end{received} \end{document}

Ignore Space Show notes View

TOIT_2006/Map_Visualisation.tex 0 → 100644

\documentclass[acmnow]{acmtrans2m}

\usepackage{graphicx}

\markboth{Nigel Stanger}{...}

\title{Scalability of Techniques for Online Geovisualization of Web Site Hits}
            
\author{NIGEL STANGER \\ University of Otago}
            
\begin{abstract} 
A useful approach to visualizing the geographical distribution of web
site hits is to geolocate the IP addresses of hits and plot them on a
world map. This can be achieved by dynamic generation and display of map
images at the server and/or the client. This paper compares the
scalability with respect to source data size of four techniques for
dynamic map generation and display: generating a single composite map
image, overlaying transparent images on an underlying base map,
overlaying CSS-enabled HTML on an underlying base map and generating a
map using Google Maps. These four techniques embody a mixture of
different display technologies and distribution styles. The results show
that all four techniques are suitable for small data sets, but that the
latter two techniques scale poorly to larger 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{downloads, geolocation, geovisualization, scalability, Google
	Maps, distribution style, dynamic map generation}
            
\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 the site, so as to decide where
best to target marketing resources. One approach to doing so is to plot
geographical locations 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.

The author's interest in this area derives from implementing a pilot
digital institutional repository for the University of Otago School of
Business\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. This repository quickly attracted interest from around the
world and the number of abstract views and document downloads began to
steadily increase. There was great interest within the University in
tracking this increase, particularly with respect to where in the world
the hits were coming from. The EPrints statistics management software
developed at the University of Tasmania \cite{Sale-A-2006-stats} proved
very useful in this regard, providing 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 greater detail beyond the country level, nor does it provide
any visual clues as to the spatial distribution of hit sources around
the globe.

\begin{figure}
	\centering
	\includegraphics[width=\textwidth,keepaspectratio]{tasmania_stats}
	\caption{A portion of the by-country display for the Otago EPrints
	repository, generated by the Tasmania statistics software
	\protect\cite{Sale-A-2006-stats}.}
	\label{fig-tas-stats}
\end{figure}

The author therefore began to explore possible techniques for plotting
repository hit data onto a world map, with the aim of adding this
capability to the Tasmania statistics package. Preference was given to
techniques that could be used within a modern web browser without the
need to manually install additional client software, so as to make the
new feature available to the widest possible audience and reduce 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 geovisualize web activity.
\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 called \emph{Palantir}, which was written as a Java applet and
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, with fairly crude results
\cite{Lamm-SE-1996-webvis}. 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 and detailed databases were commercially available
at the time \cite[p.\ 1466]{Lamm-SE-1996-webvis}, but were not generally
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
services\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 these prior systems can generally be divided into
two classes. The first class of techniques generate a single bitmap
image that contains both the map and the graphics representing web hits.
This can be achieved by programmatically plotting points onto a base map
image; the composite image is then displayed at the client. This class
of techniques shall henceforth be referred to as \emph{single-layer}
techniques. The second class of techniques separately return both a base
map image and some kind of overlay containing the plotted points. The
overlay and the base map are then displayed as separate items at the
client. This class of techniques shall henceforth be referred to as
\emph{multi-layer} techniques.

Both classes of techniques have been used in the aforementioned systems,
but multi-layer techniques appear to have been the most prevalent. For
example, Palantir used a multi-layer technique, in which 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 interactive maps within web pages. Google Maps is a dynamic
multi-layer technique that has only become feasible relatively recently
with the advent of widespread support for CSS positioning and Ajax
technologies \cite{Garr-JJ-2005-Ajax} in many browsers.

Multi-layer techniques enjoy a particular advantage over single-layer
techniques, in that they provide the potential for a more flexible
GIS-like interaction with the map, with multiple layers that can be
activated and deactivated as desired. This flexibility could explain why
such techniques appear more prevalent in the literature. As will be seen
shortly, however, web-based multi-layer techniques tend to rely either
on the installation of additional client-side software, or on more
recent web technologies such as CSS and Ajax. Single-layer techniques,
in contrast, typically do not rely on these things. Single-layer
techniques should therefore be portable to a wider range of client and
server environments.

Each map generation and display technique comprises a specific
technology or collection of technologies (such as transparent bitmap
overlays + CSS positioning), implemented using a specific distribution
style. For example, a particular single-layer technique might be
implemented completely server-side while another might use a mixture of
server-side and client-side processing. Similarly, multi-layer
techniques may adopt different distribution styles, and the overlays
themselves might take the form of transparent images, absolutely
positioned HTML elements, dynamically generated graphics, etc.

Given the wide variety of possible techniques that were available, the
next question was which techniques would be most suitable? Ideally, a
technique should not only efficiently fulfil the task of plotting
repository hits on a map, but also provide tangible benefits to
end-users. Scalability is a key issue for web applications in general
\cite[p.\ 28]{Offu-J-2002-quality}, and for online activity
visualization in particular \cite[p.\ 50]{Eick-SG-2001-sitevis}, so
techniques that could scale to a large number of points were of
particular interest. For example, at the time of writing the Otago
EPrints repository had been accessed from 13,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 16,000. Informal testing with these data
suggested that a single-layer composite map image would perform well
with this volume of data, taking at most a few seconds to load and
display. Conversely, it appeared that Google Maps would not perform
well, taking on the order of minutes to load and display a map
containing a few thousand points.

The range of techniques was first narrowed down 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}. The
scalability of these four techniques was then tested to determine how
well each technique handled large numbers of points. A series of
experiments was conducted on each technique with progressively larger
synthetic data sets, and the data set volume, elapsed time and memory
usage were measured. The experimental design is discussed in
Section~\ref{sec-experiment}.

Informal tests suggested that the server-side image generation and the
server-side image overlay techniques would scale best, and this was
borne out by the results of the experiments, which show that both
techniques scale reasonably well to very large numbers of points. The
other two techniques proved to be reasonable for relatively small
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}.

It should be noted that the intent of the experiments was not to
identify statistically significant differences in performance across the
four techniques. It was expected that variations across techniques would
be reasonably clear-cut, and the experiments were designed to test this
expectation. However, the two best performing techniques, server-side
image generation and server-side image overlay, produced very similar
results, so a more formal statistical analysis of these techniques may
be warranted. This and other possible future directions are discussed in
Section~\ref{sec-conclusion}.

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

In this section the four techniques that were chosen for testing are
discussed in more detail, along with the reasons for choosing these
particular techniques. First, the impact of distribution style on the
choice of technique is discussed. This is followed by an examination of
how each 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 a multi-layer technique using this distribution
style \cite{Papa-N-1998-Palantir}, where the source data were generated
at the server and the map was generated, displayed and manipulated by a
Java applet running at the client. The data server distribution style
can provide a very dynamic and interactive environment to the end user,
but clearly requires support for executing application code within the
web browser, typically using something like JavaScript, Java applets or
Flash. JavaScript is now tightly integrated into most browsers, but the
same cannot be said for either Java or Flash. That is, the existence of
a Java virtual machine or Flash plugin cannot necessarily be guaranteed
in every browser, which violates the requirement to avoid manual
installation of additional client-side software. Java- or Flash-based
data server techniques can therefore be eliminated from consideration,
but JavaScript-based data server techniques are feasible. Indeed, Google
Maps is an example of such a technique (see Section~\ref{sec-overlay}).

\begin{figure}
	\centering
	\begin{tabular}{ccc}
		\includegraphics[scale=0.9]{data_server}	&
		\qquad	&
		\includegraphics[scale=0.9]{image_server}	\\
		\footnotesize (a) Data server	&
		\qquad	&
		\footnotesize (b) Image server	\\
		\\
		\\
		\includegraphics[scale=0.9]{model_interaction}	&
		\qquad	&
		\includegraphics[scale=0.9]{shared}	\\
		\footnotesize (c) Model interaction environment	&
		\qquad	&
		\footnotesize (d) Shared environment	\\
	\end{tabular}
	\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}

Conversely, the \emph{image server} style is where the display is
created and manipulated entirely at the server and is only passively
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. The downside
is that the resultant visualization can tend to be very static and
non-interactive in nature, as it is typically just a simple bitmap
image.

The \emph{model interaction environment} style is where a model created
at the server can be explored at the client, as illustrated in
Figure~\ref{fig-distribution-styles}(c). \citeN{MacE-AM-1998-GIS} calls
this the ``3D model interaction'' style, but this 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. ``Model interaction
environment'' therefore seems a more appropriate name for this style.
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 at the server and downloaded to the client.
Similar restrictions apply to techniques using this style as to the data
server style, so Java- and Flash-based model interaction environment
techniques can be eliminated from consideration. For similar reasons,
solutions such as VRML or SVG that require external browser plugins can
also be eliminated (although native support for SVG is beginning to
appear in some browsers). It may be possible to implement this
distribution style using only client-side JavaScript, but it is
presently unclear as to how effective this might be.

Finally, the \emph{shared environment} style is where data manipulation
is done at the server, but control of that manipulation, and 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. Ajax technologies can easily support this kind of
distribution style. For example, \citeN{Saya-A-2006-GISWS} use Ajax to
integrate Google Maps with existing GIS visualization web services.
Specific shared environment techniques can be eliminated from
consideration based on the same criteria as were applied to the other
three styles (e.g., no Java- or Flash-based techniques).

\subsection{Single-layer techniques}
\label{sec-image-gen}

As noted earlier, single-layer techniques work by directly plotting
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 latitude/longitude coordinates into projected map coordinates
on the base map (for example, the PROJ.4 cartographic projections
library\footnote{\url{http://www.remotesensing.org/proj/}}).

\begin{figure}
	\centering
	\includegraphics[width=\textwidth,keepaspectratio]{ImageGeneration-full}
	\caption{Sample output from the (single-layer) server-side image
		generation technique.}
	\label{fig-image}
\end{figure}

Single-layer techniques could use any of the distribution styles
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 only single-layer techniques that use the image server
distribution style (or \textbf{server-side image generation} techniques)
are considered here. For this research, the author chose a
representative server-side image generation technique based on the GD
and PROJ.4 libraries.

Server-side image generation techniques provide some distinct
advantages. They are relatively simple to implement and are fast at
producing the final image, mainly because they use existing,
well-established technologies. They are also bandwidth efficient,
because the size of the generated map image is determined by its pixel
dimensions and the compression method used, rather than by the number of
points to be plotted. The amount of data to be sent to the client should
therefore remain more or less constant, regardless of the number of
points plotted.

Server-side image generation techniques also have 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 copyright issues. Second, the compression method
used to produce the final composite map image can have a significant
impact on visual quality. For example, lossy compression methods such as
JPEG can make the points plotted on the map appear distinctly fuzzy or
``muddy'', even at high quality levels. Lossless compression methods
such as PNG avoid this problem, but may produce larger files for the
same image. Finally, it is harder to provide interactive map
manipulation features with server-side image generation techniques, as
the output is a simple static image. Anything that changes the content
of the map (such as panning or changing the visibility of certain
points) will require the entire image to be regenerated. Zooming could
be achieved if a very high resolution base map image was available, but
the number of possible zoom levels is likely to be restricted.

\subsection{Multi-layer techniques}
\label{sec-overlay}

Multi-layer techniques also involve plotting points onto a base map
image, but they differ from single-layer techniques in that the points
are not plotted directly onto the base map image. Rather, the points are
displayed as an independent overlay on top of the base map image. This
provides a significant advantage over single-layer techniques, as it
enables the possibility of multiple independent layers that can be
individually shown or hidden. This is very similar to the multi-layer
functionality provided by a GIS, and is an effective way to provide
interactive visualizations of geographic data
\cite{Wood-J-1996-vis,MacE-AM-1998-GIS}. There is still the problem of
finding a suitable base map image, however.

Until relatively recently, implementing multi-layer techniques would
likely have required additional software to be installed at the client,
but most modern browsers now support absolute positioning of HTML elements
using CSS. This enables the creation of a map overlay using nothing more
than HTML, CSS and a few bitmap images. The author has identified two
main alternatives for producing such an overlay, which can be 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 (in the
author's implementation, the output looks essentially identical to that
shown in Figure~\ref{fig-image} on page~\pageref{fig-image}). This
requires the overlay image to be in either PNG or GIF format, as JPEG
does not support transparency. The overlay image is likely to contain
considerable ``white space'', which compresses very well, so use of a
lossless compression method should not be an issue. This also eliminates
the image quality issue noted earlier. The size of the image overlay
will generally be proportional to the number of points to be plotted,
but the image compression should moderate this.

As noted in Section~\ref{sec-image-gen}, generating images at the client
would require additional software to be installed, so only the data
server distribution style will be considered here for image overlays
(i.e., \textbf{server-side image overlay}). That is, both the base map
image and the overlay(s) are generated at the server.

An HTML overlay comprises a collection of HTML elements corresponding to
the points to be plotted, which are positioned over the base map image
using CSS absolute positioning. There is considerable flexibility as to
the types of elements that could be used to construct the overlay. One
possibility is to use \verb|<IMG>| elements to place icons on the base
map, which appears to be the approach adopted by Google Maps (see
Figure~\ref{fig-google}). Another possibility is to use appropriately
sized and colored \verb|<DIV>| elements, which then appear as colored
blocks ``floating'' over the base map image (in the author's
implementation, the output looks essentially identical to that shown in
Figure~\ref{fig-image} on page~\pageref{fig-image}).

\begin{figure}
	\centering
	\includegraphics[width=\textwidth,keepaspectratio]{GoogleMap-full.png}
	\caption{Sample output from the (multi-layer) 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, not images. This can
be easily achieved using client-side JavaScript, so HTML overlays can
use any of the distribution styles discussed in
Section~\ref{sec-distribution} without violating the requirement to
avoid additional client-side software. Two representative HTML overlay
techniques have thus been adopted for the experiments:
\textbf{server-side HTML overlays} (using the image server distribution
style) and \textbf{Google Maps} (using the data server distribution
style). Since Google Maps uses \verb|<IMG>| elements, \verb|<DIV>|
elements have been used for the server-side HTML overlay.

Server-side HTML overlays are actually slightly simpler to implement
than either server-side image generation or image overlays, because it
is not necessary to write any code to generate or manipulate images (the
base map image is static and thus requires no additional processing).
All that is required is code to transform latitude/longitude coordinates
into projected map coordinates and generate corresponding \verb|<DIV>|
elements.

Google Maps \cite{Goog-M-2006-maps} is a more complex proposition. This
technique uses the data server distribution style, where JavaScript code
running within the browser enables the client to manipulate the base map
and its overlays. Data and map images are requested asynchronously from
the server as required using Ajax technologies, which seems to imply
that Google Maps in fact uses the shared environment distribution style.
However, the server has no involvement beyond simply supplying data to
the client. In the shared environment distribution style, the server is
directly involved in manipulating the map, under the control of the
client. This is clearly not the case with Google Maps.

The primary advantage of Google Maps is the powerful and compelling
functionality it provides for generating and interacting with the map.
Users may pan the map in any direction and zoom to many different levels
of detail. A satellite imagery view is also available. In addition,
further information about each point plotted (such as the name of the
city) can be displayed in a callout attached to the point, as shown in
Figure~\ref{fig-google}. Google Maps also has a proven record for
visualization of network resources. For example,
\citeN{Gibb-H-2006-Gridscape} use Google Maps to visualize and manage
world-wide computing grids.

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 this research.}. First, it is a
distributed application, thus making it more complex to implement, test
and debug \cite{Bates-PC-1995-distdebug,Ensl-PH-1978-distributed}.
Second, the server must have a registered API key from Google, which is
verified every time that a page attempts to use the API. Similarly, the
client must connect to Google's servers in order to to download the
API's JavaScript source. This means that the technique requires an
active Internet connection in order to work. Finally, the Google Maps
API does not currently provide any way to toggle the visibility of
markers on the map, so it is not possible to implement the interactive
``layers'' mentioned at the start of this section. (It is possible, of
course, that Google may implement this feature in a future version of
the API.)

The most significant disadvantage of all HTML overlay techniques,
however, is that the size of the HTML overlay is directly proportional
to the number of points to be plotted. There will be one overlay element
(\verb|<DIV>| or \verb|<IMG>|) per point, so a very large number of
points will result in an even larger amount of HTML source being
generated. It is expected that this will lead to excessive browser
memory usage for large data sets, and consequently that these techniques
will not scale well at the high end. However, they may still be
appropriate 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, a series of experiments was undertaken to test the
scalability of the four chosen techniques. Each technique was tested
using the same collection of progressively larger synthetic data sets.
The first data set comprised one point at the South Pole. A regular grid
of points at one degree intervals was then constructed by progressively
incrementing the latitude and longitude, with each data set being twice
the size of its predecessor. 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 result of plotting the 16,384-point data
set is shown in Figure~\ref{fig-grid-points}. The grid spacing used
meant that 64,800 points were sufficient to fill the entire map, so the
five largest data sets had many duplicate points. This does not affect
the results of the experiments, however, as it is the total number of
points that is significant, not their location.

\begin{figure}
	\centering
	\includegraphics[width=\textwidth,keepaspectratio]{16384_points}
	\caption{The 16,384-point data set plotted on the base map.}
	\label{fig-grid-points}
\end{figure}

The focus on scalability meant that the primary measures of interest
were page load time, memory usage and the volume 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 and other ancillary material to
the client across the network, and the time taken by the client to
display the map.

Unfortunately, as noted in Section~\ref{sec-overlay}, the Google Maps
technique requires an active Internet connection, so the experiments
could not be run on an isolated network. This meant that traffic on the
local network was a potential confounding factor. It was therefore
decided to eliminate network performance from the equation by running
both the server and the client on the same machine\footnote{A Power
Macintosh G5 1.8\,GHz (single processor) 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
independent measurement of the times for data generation and page
display, thus simplifying the process of data collection and also
ensuring that the client and server processes did not unduly interfere
with each other, despite running on the same machine.

It could be argued that network performance would still have a
confounding effect on the Google Maps technique, but this would only be
likely for the initial download of the API (comprising about 235\,kB of
JavaScript source and images), which would be locally cached thereafter.
The API key verification does occur every time a map is loaded, but
the amount of data involved is very small, so it is less likely 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, its size, the time taken to generate it,
the time taken to display the resultant map in the browser, and the
amount of real and virtual memory used by the browser during the test
were recorded. It was also intended to measure the memory usage of the
server, but this proved more difficult to isolate than expected, and was
thus dropped from the experiments. The data set generation time and
browser memory usage were measured using the \texttt{time} and
\texttt{top} utilities respectively (the latter was run after each test
run to avoid interference). 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 an excessive amount of time to complete. Further testing for a
particular technique was generally halted when a single test run took
longer than about five minutes, as by this stage performance had already
deteriorated well beyond usable levels. The web browser was quit and
reloaded afresh before each group of tests.

\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 arguments---such as the number of points
to be plotted---to be passed 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 dispatcher page included a
	standard \verb|<IMG>| element that called the Perl script. This
	script loaded a base map PNG image, plotted points directly onto it,
	and returned the composite map to the client as a JPEG image (with
	the ``quality'' parameter set to 90).

\item[server-side image overlay] The dispatcher page included two
	\verb|<IMG>| elements, the first for the base map and the second for
	the overlay, both with identical CSS positioning attributes. The
	first \verb|<IMG>| simply loaded a static JPEG image representing
	the base map. The second \verb|<IMG>| called the Perl script, which
	generated and returned the overlay as a transparent PNG image.

\item[server-side HTML overlay] The dispatcher page included an
	\verb|<IMG>| element for the base map and a \verb|<DIV>| element for
	the overlay, both with identical CSS positioning attributes. The
	\verb|<IMG>| simply loaded a static JPEG image representing the base
	map. The \verb|<DIV>| contained inline PHP code that called the Perl
	script. This in turn generated and returned the overlay as a
	collection of CSS-positioned \verb|<DIV>| elements, nested within
	the top-level \verb|<DIV>| element.

\end{description}

For all of these techniques, the base map image was 1,024 $\times$ 520
pixels. In PNG format it occupied approximately 1.2\,MB (but this
version was never returned to the client), while in JPEG format (Q=90)
it occupied approximately 180\,kB. The base map image was derived from
an original 3,599 $\times$ 1,826 pixel image, which was part of a
collection of maps released into the public domain by the
\citeN{CIA-WFB-2006}. All three techniques used the PROJ.4 cartographic
projections library to convert latitude/longitude pairs into projected
map coordinates, while the first two techniques also used the GD
graphics library to programmatically generate and manipulate images.

The Google Maps technique was implemented using the data server
distribution style. As with the other three techniques, a PHP dispatcher
page was used. This time, however, the page included client-side
JavaScript code to load and initialize 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 asynchronously call a server-side
Perl script, which 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}

As noted in the introduction, 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. There has
not, therefore, been any statistical analysis carried out on the
results. The remainder of this section will discuss the results for data
size, page load time and memory usage. Because the number of points in
each data set increases in powers of two, log-log scales have been used
for all plots.

\subsection{Data size}

For each data set, the data generated by the server was saved to a file
and its size in bytes recorded. In the case of the server-side image
generation and server-side image overlay techniques, the file comprised
a bitmap image; whereas for the server-side HTML overlay and Google Maps
techniques, the file comprised HTML or XML text, respectively.

In addition to the generated data, there was a certain amount of fixed
overhead associated with each technique tested, as summarized in
Table~\ref{tab-overhead}. This overhead comprised static files that were
always downloaded to the client regardless of the number of points to be
plotted. Examples of fixed overhead items include the base map image,
various icons, the PHP source of the dispatcher page and the JavaScript
source for the Google Maps API.

\begin{acmtable}{11cm}
	\centering
	\begin{tabular}{lll}
		Technique						&	Fixed overhead		&	Content	\\
		\hline
		Server-side image generation	&	629\,bytes			&	\textbf{dispatcher (PHP)}\medskip	\\

Server-side image overlay		&	$\approx$ 181\,kB	&	dispatcher (PHP) \\
										&						&	\textbf{base map image (JPEG)}\medskip	\\

Server-side HTML overlay		&	$\approx$ 181\,kB	&	dispatcher (PHP) \\
										&						&	\textbf{base map image (JPEG)}\medskip	\\

Google Maps						&	$\approx$ 235\,kB	&	dispatcher (PHP) \\
										&						&	base map image tiles (PNG) \\
										&						&	\textbf{API (JavaScript)} \\
										&						&	various icons (PNG)	\\
	\end{tabular}
	\caption{Fixed overhead for each technique. The largest contributing
	item for each technique is shown in \textbf{bold face}.}
	\label{tab-overhead}
\end{acmtable}

\begin{figure}
	\centering
	\includegraphics[scale=0.55]{data_size}
	\caption{Comparison of generated data size for each technique (log-log scale).}
	\label{fig-data-size}
\end{figure}

The volume of data generated by each technique, including fixed
overhead, is shown in Figure~\ref{fig-data-size}. It is immediately
apparent from these results that there is a divergence between the two
techniques that generate images (server-side image generation and
server-side image overlay), and the two techniques that generate text
(server-side HTML overlay and Google Maps).

Both the server-side image generation and server-side image overlay
techniques scale particularly well with regard to the amount of data
generated. Interestingly, the amount of data generated by the image
generation technique increases by about 8\,kB up to the 8,192-point data
set, but then \emph{drops} by about 90\,kB over the next three data
sets. This occurs because the number of points plotted has become
sufficient to cover most of the base map. This means that a large
portion of the composite map image is a single color (see
Figure~\ref{fig-grid-points} on page~\pageref{fig-grid-points} for an
example), which compresses more efficiently.

The amount of data generated by the image overlay technique appears
constant, but actually increases by about 2\,kB across the range. This
has important implications for the ability of this technique to handle
multiple layers. Because the overlay images are quite small (less than
2\,kB for up to one million points), it should be feasible to pre-load
several overlay images into a client-side array and switch them on and
off as desired.

The server-side HTML overlay and Google Maps techniques clearly do not
scale well with respect to data size, and begin to visibly diverge from
the other two techniques once the amount of data generated exceeds about
5\% of the fixed overhead. For the HTML overlay technique this occurs
somewhere between 64 and 128 points, whereas for Google Maps it occurs
somewhere between 256 and 512 points. The divergence increases rapidly
for both techniques beyond these points, with the HTML overlay technique
suffering the most. The latter occurs because the HTML overlay technique
needs to generate additional CSS attributes (i.e., more text) in order
to correctly position the \verb|<DIV>| elements, whereas the Google Maps
technique needs only to return a more compact list of latitude/longitude
coordinates.

\subsection{Page load time}

For each test run, both the length of time taken to generate the data at
the server and to display the page in the client browser were recorded.
The former is illustrated in Figure~\ref{fig-data-generation-time} and
the latter in Figure~\ref{fig-page-load-time}. The combined time (data
generation + display time) is shown in Figure~\ref{fig-combined-time}.

\subsubsection{Data generation time}

\begin{figure}
	\centering
	\includegraphics[scale=0.55]{data_generation_time}
	\caption{Comparison of data generation time for each technique (log-log scale).}
	\label{fig-data-generation-time}
\end{figure}

The results (see Figure~\ref{fig-data-generation-time}) show that the
length of time taken to generate the source data increases in proportion
to the number of points to be plotted, as expected. It is interesting to
note the differences in data generation time for each technique,
however. Data generation for both of the ``text-based'' techniques (HTML
overlay and Google Maps) is generally faster than for the
``image-based'' techniques (image generation and image overlay).

The results show that server-side image generation generally takes the
longest to generate its data. This is because it not only has to map
points from latitude/longitude into projected map coordinates, but also
must plot these points onto the base map image, then compress the
composite image as a JPEG. The image to be compressed is also moderately
complex, which only adds to the data generation time. Server-side image
overlay performs somewhat better because it uses a less complex
compression method (PNG) and the image to be compressed is much simpler
(a collection of colored points on a blank background).

The server-side HTML overlay technique appears faster at generating data
than either of the two image-based techniques at the low end, but is
similar in performance at the high end. In this technique the server
only needs to map latitude/longitude to projected map coordinates; no
images need to be generated and there is no compression to deal with. At
the high end, however, this advantage is clearly offset by the
significant volume of data being generated. Google Maps is faster again,
because almost all processing is carried out on the client; the server's
only involvement is to generate a simple list of latitude/longitude
coordinates.

In terms of data generation, it appears that all techniques tested scale
reasonably well. The image-based techniques perform worse at the low end
because they involve more complex processing than the text-based
techniques, but this is offset at the high end by the relatively
constant amount of data generated. Conversely, the text-based techniques
perform better at the low end, but are negatively impacted at the high
end by the sheer volume of data produced (tens or hundreds of megabytes
vs.\ hundreds of kilobytes).

\subsubsection{Map display time}

\begin{figure}
	\centering
	\includegraphics[scale=0.55]{page_load_time}
	\caption{Comparison of map display time for each technique (log-log scale).}
	\label{fig-page-load-time}
\end{figure}

These results (see Figure~\ref{fig-page-load-time}) reveal quite a
spectacular difference between the image-based and text-based
techniques. The time taken to display the map is essentially constant
for both of the image-based techniques, regardless of the number of
points to be plotted. This is not surprising given that the size of the
generated data is also essentially constant, and that the browser is
simply loading and displaying static images. The image overlay technique
appears slightly slower than the image generation technique. This is
probably because the image overlay technique has to load two images from
the server (the base map and the overlay), compared to one image for the
image generation technique.

In contrast, the text-based techniques clearly do not scale well with
respect to map display time. Google Maps suffers particularly in this
regard, with display time exceeding ten seconds shortly past 512 points.
Testing was abandoned at 4,096 points, with a single test run taking
over seven minutes. The HTML overlay technique fares better, exceeding
ten seconds somewhere between 4,096 and 8,192 points. Testing was
abandoned at 32,768 points, with a single test run taking almost ten
minutes.

\subsubsection{Combined time}

\begin{figure}
	\centering
	\includegraphics[scale=0.55]{combined_time}
	\caption{Comparison of combined page load time for each technique (log-log scale).}
	\label{fig-combined-time}
\end{figure}

Combining the data generation and map display times (see
Figure~\ref{fig-combined-time}) yields little change in the curves for
the text-based techniques, because the data generation times are very
small compared to the map display times. There is a more obvious impact
on the image-based techniques, with both techniques remaining more or
less constant up to about 2,048 points, then slowing as the number of
points increases beyond that. However, the slowdown is nowhere near as
dramatic as for the text-based techniques; even the largest data set
only takes about nineteen seconds overall. The image overlay technique
does display a slight advantage of about half a second over the image
generation technique for the largest data set, but further experiments
will be required to determine whether this difference is statistically
significant.

\subsection{Memory usage}

Both the real and virtual memory usage of the browser were measured by
running the \texttt{top} utility after each test run and observing the
memory usage in each category. This provided the size of both the
current ``working set'' and the total memory footprint of the browser
process after it had completed a test run. The real memory results are
shown in Figure~\ref{fig-real-memory} and the virtual memory results are
shown in Figure~\ref{fig-virtual-memory}.

\begin{figure}
	\centering
	\includegraphics[scale=0.55]{real_memory}
	\caption{Comparison of browser real memory usage for each technique
	(log-log scale).}
	\label{fig-real-memory}
\end{figure}

\begin{figure}
	\centering
	\includegraphics[scale=0.55]{virtual_memory}
	\caption{Comparison of browser virtual memory usage for each
	technique (log-log scale).}
	\label{fig-virtual-memory}
\end{figure}

While both sets of results display similar trends, the real memory data
proved somewhat problematic. Real memory usage was generally consistent
across test runs, but would also frequently fluctuate upwards by a
factor of nearly two for no readily apparent reason. This is
particularly apparent with the HTML overlay technique beyond 1,024
points. It seems likely that this was a result of other processes on the
test machine interacting with the browser process in unexpected ways.
There is some doubt therefore as to the validity of the real memory
data, but they are at least broadly consistent with the virtual memory
data. The virtual memory data proved more consistent overall, as the
virtual memory footprint of a process is less likely to be impacted by
other running processes.

The results show that the two image-based techniques have essentially
constant virtual memory usage of about 170\,MB regardless of the number
of points plotted. This is to be expected, given that the size of the
generated data is also essentially constant. The text-based techniques,
however, clearly begin to diverge as the number of points increases. The
HTML overlay technique starts to visibly diverge somewhere between 2,048
and 4,096 points, reaching a maximum of about 216\,MB at the point that
testing was terminated. Google Maps starts to visibly diverge between 64
and 128 points, reaching a maximum of about 264\,MB at the point that
testing was terminated. This is in line with the initial expectation for
these techniques, that is, that memory usage would increase in
proportion to the number of points to be plotted.

\section{Conclusion and future work}
\label{sec-conclusion}

In this research, the scalability of four techniques for
online geovisualization of web site hits was tested, with respect to the number of
points to be plotted on the map. The four techniques tested were
server-side image generation, server-side image overlay, server-side
HTML overlay and Google Maps. The results clearly show that the
server-side image generation and server-side image overlay techniques
scale the best from small to large data sets. The HTML overlay and
Google Maps techniques work well for small data sets, but their
performance rapidly deteriorates as the size of the data set increases,
to the point where they become unusable.

Despite this clear difference in scalability, there are still some
interesting questions remaining. The model interaction environment
distribution style was not investigated in this research, as it was
unclear whether this could be achieved using only client-side
JavaScript. This is clearly an avenue for further investigation. In
addition, the appearance of native SVG support in browsers means that
this may become a viable option for implementing this distribution style
in future.

It was somewhat surprising that the server-side HTML overlay and Google
Maps techniques exhibited no obvious consistency in where the different
measures (data size, map display time and virtual memory usage)
diverged, as shown in Table~\ref{tab-divergence}. Google Maps appears to
exhibit greater consistency than HTML overlay in this respect, but it
seems logical to expect some form of correlation, so further research
will be required to investigate this. One possibility might be to
implement an instrumented web browser and server in order to gather more
precise data.

\begin{acmtable}{11cm}
	\centering
	\begin{tabular}{lccc}
		Technique						&	Data size	&	Map display time	&	Virtual memory	\\
		\hline
		Server-side HTML overlay		&	64--128		&	128--256			&	2,048--4,096 \\
		Google Maps						&	256--512	&	64--128				&	64--128	\\
	\end{tabular}
	\caption{Approximate number of points at which each measure begins to
		visibly diverge, for the HTML overlay and Google Maps techniques.}
	\label{tab-divergence}
\end{acmtable}

Shortly after completing the experiments, the author discovered
\emph{msCross Web\-gis}\footnote{\url{http://datacrossing.crs4.it/en_Documentation_mscross.html}},
an open source Google Maps clone. Its documentation implies that it may
be possible to build a fully self-contained implementation that requires
no external network access. This would enable testing on an isolated
network with the client and server running on different machines.
Measurements of network transfer time could then be included, and any
issues arising from running the client and server on the same machine
would be eliminated. This would require a distributed measurement
infrastructure similar to that developed by \citeN{Barf-P-1999-webperf}.

The overall aim of this work was to identify the best technique for
plotting the large number of downloads and abstract views from the Otago
School of Business digital repository. Based on the results, both the
server-side HTML overlay and Google Maps techniques are clearly
inappropriate for this task. This leaves a choice between two very
similarly-performing techniques: server-side image generation and
server-side image overlay. However, multi-layer techniques display many
practical advantages over single-layer techniques, such as the ability
to dynamically show and hide multiple overlays. These advantages provide
greater flexibility and a more dynamic experience for end-users. Taking
these end-user benefits into consideration, the server-side image
overlay technique is the clear winner in this case.

\begin{acks}
The author would like to acknowledge Dr.\ Antoni Moore and Prof.\ George
Benwell for their input into this research.
\end{acks}

\bibliography{Map_Visualisation}

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

Ignore Space Show notes View TOIT_2006/PointOverlay-full.png 0 → 100644

Ignore Space Show notes View TOIT_2006/chunk_logstubs 0 → 100644
.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 TOIT_2006/chunk_logtics 0 → 100644
.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 TOIT_2006/d_combined_time.txt 0 → 100644
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,,,

Ignore Space Show notes View

TOIT_2006/d_combined_time.txt 0 → 100644

Ignore Space Show notes View TOIT_2006/d_data_generation_time.txt 0 → 100644
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

Ignore Space Show notes View

TOIT_2006/d_data_generation_time.txt 0 → 100644

Ignore Space Show notes View TOIT_2006/d_data_size.txt 0 → 100644
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

Ignore Space Show notes View

TOIT_2006/d_data_size.txt 0 → 100644

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

Ignore Space Show notes View TOIT_2006/d_page_load_time.txt 0 → 100644
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,,,

Ignore Space Show notes View

TOIT_2006/d_page_load_time.txt 0 → 100644

Ignore Space Show notes View TOIT_2006/d_real_memory.txt 0 → 100644
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,,,

Ignore Space Show notes View

TOIT_2006/d_real_memory.txt 0 → 100644

Ignore Space Show notes View TOIT_2006/d_virtual_memory.txt 0 → 100644
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,,,

Ignore Space Show notes View

TOIT_2006/d_virtual_memory.txt 0 → 100644

Ignore Space Show notes View TOIT_2006/data_generic.xls 0 → 100644
Not supported

Ignore Space Show notes View TOIT_2006/data_server.pdf 0 → 100644
Not supported

Ignore Space Show notes View TOIT_2006/data_server.svg 0 → 100644

Ignore Space Show notes View TOIT_2006/image_server.pdf 0 → 100644
Not supported

Ignore Space Show notes View TOIT_2006/image_server.svg 0 → 100644

Ignore Space Show notes View TOIT_2006/lineplot.plo 0 → 100644
#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 #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: image_gen pointsymbol: shape=diamond linecolor=black fillcolor=white legendlabel: Image generation 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: google_maps pointsymbol: shape=triangle linecolor=black fillcolor=white legendlabel: Google Maps legendsampletype: line+symbol #proc legend format: multiline location: min+2 max-1 textdetails: size=10 seglen: 0.25 frame: yes backcolor: white

Ignore Space Show notes View

TOIT_2006/lineplot.plo 0 → 100644

#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

#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: image_gen
	pointsymbol: shape=diamond linecolor=black fillcolor=white
	legendlabel: Image generation
	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: google_maps
	pointsymbol: shape=triangle linecolor=black fillcolor=white
	legendlabel: Google Maps
	legendsampletype: line+symbol

#proc legend
	format: multiline
	location: min+2 max-1
	textdetails: size=10
	seglen: 0.25
	frame: yes
	backcolor: white

Ignore Space Show notes View TOIT_2006/model_interaction.pdf 0 → 100644
Not supported

Ignore Space Show notes View TOIT_2006/model_interaction.svg 0 → 100644

Ignore Space Show notes View TOIT_2006/shared.pdf 0 → 100644
Not supported

Ignore Space Show notes View TOIT_2006/shared.svg 0 → 100644

Ignore Space Show notes View TOIT_2006/tasmania_stats.pdf 0 → 100644
Not supported

Show notes View gd_detail.png 100755 → 0

Show notes View html_detail.png 100755 → 0

Show notes View tasmania_stats.pdf 100755 → 0
Not supported

Showing you all comments on commits in this comparison.