Institutionen för datavetenskap
Department of Computer and Information Science
Examensarbete
Towards a mobile user interface used for monitoring
purposes in context of a Geographical Information
System
avMatic Hajdinjak
LIU-IDA/LITH-EX-A--13/027--SE
2013-06-18
Linköpings universitet SE-581 83 Linköping, SwedenLinköpings universitet 581 83 Linköping
Examensarbete
Towards a mobile user interface used for
monitoring purposes in context of a
Geographical Information System
avMatic Hajdinjak
LIU-IDA/LITH-EX-A--13/027--SE
2013-06-18
Handledare: Anders Fröberg / Aner Gusic Examinator: Erik Berglund
To my parents, thank you for the unwavering support, love and best wishes that have been invaluable to me over the years.
To The Slovene Human Resources and Scholarship Fund for providing me with financial support during MSc studies under a grant number 11010-758/2011.
§ Mobile Geographical Information Systems are becoming a more and more important tool for presenting geographical data. They are used to support decision making processes, present an overview of distributed infor-mation or are in a form of location based services. The problem lies in the fact that mobile devices have limited resources and should still be able to present massive amounts of content. Ideally, the user and the conditions in which the program runs are well defined, but this is usually not the case.
This thesis provides a sample prototype implementation of a mobile GIS developed as an alternative to an existing web-based user interface (UI). It focuses on specific conditions present on mobile devices, ways of presenting the data and possibilities of reusing existing elements from the web UI that could be suitable for the mobile environment.
Contents
1 Introduction 1
2 Geographical Information Systems 3
2.1 Basics . . . 4
2.1.1 Geographic Information Monitoring System . . . 4
2.2 Real world representation . . . 5
2.3 Spatial data types . . . 5
2.3.1 Data entry and preparation . . . 6
2.3.2 Data analysis . . . 7 2.3.3 Data presentation . . . 8 2.3.4 Data prediction . . . 10 2.4 Mobile GIS . . . 11 3 Design 13 3.1 Platform . . . 14 3.2 Data . . . 14 3.2.1 Obtaining data . . . 16 3.2.2 Data organization . . . 16 3.2.3 Data maintenance . . . 18 3.2.4 Data presentation . . . 19 3.2.5 Data pre-caching . . . 20
3.3 User experience and usability . . . 22
3.3.1 Control . . . 23
4 Results and Solution 24 4.1 Application . . . 25
4.2 Use-cases . . . 26
4.2.1 Items . . . 26
4.3 Comparison to the existing Web UI . . . 27
4.4 Testing . . . 29
5 Conclusion 34
Bibliography 36
List of Figures
2.1 Scheme of data gathering present in the system. . . 7 2.2 Longest repeating sequence. Bold line represents a
sub-string that has occurred at least twice and a dotted line a string occurring exactly once. Image on the left shows sub-string ’AB’, image on the right sub-sub-string ’ABC’ . . . 11 3.1 Test case data organization. . . 17 3.2 Probe groups are organized in a tree-like structure. Group
shown here is in the lowest hierarchy (level 4 - leaf), belonging to the he.rec.kpn.a004 (or simplified .a004 ) root group. . . 17 3.3 Data flow chart representing data request and decision
mech-anisms used in the solution. . . 18 3.4 Relationship between the detail level (zoom) on the map to the
hierarchy of presented items. Squares represent probe group items. . . 20 4.1 UML diagram of the basic steps proposed to achieve a desired
view implemented in the prototype solution. . . 25 4.2 Basic view on application start up, showing 2 distinct probe
groups as pie charts, analyzers as graphs and the core network infrastructure, presented as red lines. . . 28 4.3 View showing dependency of groups between each other and
their relationship to the nearest analyzer. . . 29 4.4 Shows detailed information of the probe group and the various
parameters being collected. It also shows raw QoD figures used to draw pie charts. Bellow, m (max 15) last updates (pie charts) are showed and an interactive graph of past QoD parameters. It is possible to use the hand gestures to move on the graph (zoom in/out, swipe left/right). . . 30
4.5 Shows worst n (max 10) worst probes in the selected group along with their QoD parameters and the appropriate Ana-lyzer trace that could reveal some insight on why the probes are behaving the way they do. . . 31 4.6 Shows current active alarms along with its parameters in the
probe group. . . 32 4.7 Shows groups located near the viewing group, ordered by
dis-tance. Used to pin point the source of problems, or to get some context on how the problems in one probe group are reflected in others. . . 32 4.8 Parameters needed to be set in order to see a specific probe
group in the existing web UI. . . 33 4.9 Result of a query, showing probe group overview in existing UI. 33 4.10 Result of a query, showing analyzer overview in existing UI. . 33
Chapter 1
Introduction
Agama monitoring system is used for monitoring tv-networks with ”probes” inserted on interesting points in the delivery network and in customer devices. An Enterprise server aggregates all the data and implements a web-based User Interface (UI) presenting a variety of facts to a Network Operations Center (NOC) person.
Examples of facts presented to a NOC:
• Simple red, yellow, blue, green color indication of quality
• Current and historical quality graphs per channel or per logical group • Geographical view of the entire network
• Drill down from complete network view to single in-home devices • Quality matrix channels/network-points
• Alarms on different events, sometimes configurable, that notify NOC of events in network that need human attention
To view the above mentioned facts, a NOC person must select and/or input a variety of different parameters, making the UI very flexible but not easy to use by a user without adequate technical skills.
In order to make this system in the form of an application running on a mobile device (tablet computer, smart-phone), it is necessary that it is user friendly, interactive and smooth to use. The targeted user of the system is a technical knowledge lacked user (e.g. mid management instead of a NOC person). Therefore the data should be easy to understand and even easier to obtain. From the demands it is clear that the set of data and the flexibility will be smaller than in the web-based UI, yet it should be big enough to suit the users needs.
This thesis concerns itself primarily with ways of implementing a suitable Mobile Geographical Information Monitoring System (GIS) that is capable of presenting relevant real time data to the user on a mobile device. The goal is to create a prototype Android OS1 based application, capable of
demonstrating aspects of monitoring that benefit from a multi-touch and multi-screen UI. It is of interest to determine the following:
• What aspects are improved by a multi-touch and multi-screen UI? • What customer benefits can be gained?
• What presentation techniques can be used? • How can the current UI be extended?
• How can the content of this work be used in other Agama solutions? Focus is on the presentation part of a GIS, while parts such as data gathering and data analysis are prepared by the aggregation server. Still those parts are not completely omitted as suggestion for improvements on the server side can be obtained from the presentation results and its limitations.
Chapter 2
Geographical Information
Systems
This chapter provides an insight of a Geographical Information System (GIS). First its definition and basic properties are explained. After, basics on ways of representing real world events or activities are mentioned and a notion of spatial data is defined and over-viewed. Interpretation of GIS crosses between general GIS properties and by the actual properties and needs of this study. For this reason, subsections 2.3.4, 2.4 and 2.1.1 are added to capture the unique problems faced, when implementing such a system on a mobile device. GIS covers a very broad area of terms and is consisted from many parts. This chapter will cover and elaborate only the parts needed for this project. More details regarding GIS are given in Getting Started With Geographic Information Systems [3], Principles of Geographic Information Systems [1] or Geographic Information Systems and Science [2].
2.1
Basics
Geographical Information System is a special type of an information sys-tem designed to create, integrate, manipulate, edit, analyze and present var-ious types of knowledge or data used in a decision making process. This can vary from simple control systems that generate some kind of an sta-tus overview, to crucial parts of a risk management system. What sepa-rates it from a normal information system is the data having an additional component - location. Therefore it can be referred to as spatial-geographic data-knowledge. Spatial data is said to be georeferenced when it is given geographical parameters, such as longitude or latitude or some other form of measurement. Other ways of positioning data are useful in specific cases, for example to cover data located outside of the Earth. Data can represent events, activities or things. Interest is solely on things that have information, will have information or had information in geographic space.
As it can be seen, the notion of GIS is very broad, technology indepen-dent, process independent and can therefore be potentially used in various situations and applications. Examples of their use can be found in all veins of society, such as transport, logistics, telecommunications, insurance, mete-orology and many more Usually GIS are custom designed. This makes them not compatible with systems made for different purposes. Despite looking bad on the first sight as custom designs usually come with a higher cost, it does mean that the solution is more accurate and relevant.
Historically they can be traced back to spatial analysis of 19th century when researchers started to present disease occurrences on maps in order to determine the source of the outbreak. The computer related GIS era started in the end of the 1950s - begging of the 1960s. One of the fathers of a modern GIS is Waldo Tobler, who described a GIS system as a MIMO (map-in, map-out) system, [4]. His proposed GIS model included three steps; (i) map input, (ii) map manipulation and (iii) map output, which is still a valid concept today.
2.1.1
Geographic Information Monitoring System
Geographic Information Monitoring Systems represent a subset of GIS and as the name suggest, are used to monitor the state of a system (e.g. a railway infrastructure) by showing (real time) data on a map. This helps users to geographically observe problems as they appear, making the decision making easier or simply reducing costs and increasing efficiency as described by Vecchia et al. [15]. Another implementation of such a monitoring system was proposed by Hiemstra et al. [14]. In essence both are somewhat similar to
Master Thesis - Matic Hajdinjak 5
the problems exposed in this study, despite they are used to solved completely different issues, using different technologies and with different goals in mind. This shows the strength of GIS as a multipurpose tool.
2.2
Real world representation
GIS represents a part or a state of the real world as it is, will be, was or something defined by us. Since the presentation medium chosen is usually a computer, there is no possibility to present the real world entirely. Details not relevant to the users are left out while the important ones are emphasized. Representation is achieved by using a model. Models can be separated in:
• Static models
• Dynamic or process models
Static models represent a state of an item at a point in time. Examples of these models are a map and a database. Map, the most used GIS representation model, is nothing else than a graphic representation of an area with some level of detail. In the age of computers they have evolved greatly where almost anything can be presented on them on several detail levels and in several layers. Yet, they still poses some limitations. They are limited with their scale and their 2-dimensional presentation. Databases on the other hand are very flexible, can store almost any kind of data, support concurrent use, data storage optimization and data integrity. While these properties are very useful, it is still hard to represent geographical appearances in a database. To mitigate this, spatial databases have been developed. They are a special kind of databases intended solely for purpose of storing geographical data.
Dynamic models represent models that have capabilities of simulating real world processes. They are far more complex than the static ones. Fur-ther discussion on them can be found in Dynamic GIS Models for Regional Sustainable Development [9]. For the purpose of this project, static maps will be used, accompanied with a database, to present events on maps.
2.3
Spatial data types
In essence, content of a GIS is a big database storing numbers and text that are many times context-free. Therefore it is essential to apply some context to this data in some smart way. In this case the GIS is implemented on a mobile device, which makes the amount of information available to be
stored locally rather limited. Therefore some techniques need to be used to mitigate this issue.
According to de By et al. [1], there are 3 distinct phases when dealing with data. They are:
• Data preparation and entry • Data analysis
• Data presentation
These will be described in the following sections. Data preparation in sec-tion 2.3.1, data presentasec-tion in secsec-tion 2.3.3 and data analysis in secsec-tion 2.3.2. The three stages are in close relationship between each other. To achieve bet-ter results, it is essential that designing each stage is done with other stages in mind. Despite the mentioned steps seem to be ordered, this is not al-ways the case. It can happen that data analysis concludes that more data is needed, or that the representation is not good enough. In that case, several iterations of the steps are necessary.
2.3.1
Data entry and preparation
Data entry and preparation part covers the first step of GIS - data gener-ation. This is typically achieved by having sensors located on various strate-gically important locations. Sensors, not necessarily identical, are measuring a set of parameters, depending on their use cases. Measurements, along with sensors meta data, are transmitted to the data collection center. How the data is transmitted relays on the underlying technology and the needs of the system. Depending on the application, transmit periods can vary dramat-ically, e.g. between nanoseconds to months. In general, there is no strict limitations on the accuracy of the period.
In this study, the data entry points - sensors are referred to as analyzers or probes. Analyzers are a specific type of probes, located on specially cho-sen points in the core delivery network, while probes are typically customer Set-top boxes (STBs). Another difference is that analyzers are capable of monitoring several channel streams at once, while the probes only monitor the currently active stream. The data used by the mobile GIS is not obtained directly from these sensors. Instead it is obtained via the data collection cen-ter, here referenced as aggregation servers. Data from analyzers and probes is collected on best effort basis. Analyzers send data periodically, while probes send data on event and time driven basis. Time reports include information on the probe it self, such as CPU temperature, memory usage and other sim-ilar measurements. Event reports on the other side consist of events caused
Master Thesis - Matic Hajdinjak 7
by the active stream. Examples include changing the active stream, black screen occurrences, freeze and frames occurrences. See figure 2.1.
Figure 2.1: Scheme of data gathering present in the system.
2.3.2
Data analysis
After the data is obtained, the time comes to add them in context and perform some sort of analysis on them. This step ends by producing the model (map) which is explained in the next section. What context means, depends on the purpose of the GIS. The point of interest is the spatial data analysis. Depending on how the data will be presented, the analysis is ad-justed. Therefore these two steps go hand in hand. For example, for data gathered on distinct geographical locations (e.g. buoys on the sea), there exist locations where no data was collected. In order to present data for a whole area (thus including locations with no sensors), one needs to either use interpolation or some other way to extend the data beyond their point of origin. Another approach is to search for patterns in data and present them as clusters. Output can be roughly divided into (i) qualitative data and (ii) quantitative data. The first one stands for data that sums up some charac-teristics of a set of data and the latter being the set of data. For example average monthly temperature represents qualitative data and the set con-taining temperatures of monthly daily temperatures represent quantitative data.
Data analysis is in our case made on aggregation servers and is beyond control of this study. As a consequence the presentation is somewhat limited
to the results of the analysis made by the servers. This is valid only for spatial data referring to either groups of analyzers or groups of probes. It is still possible to access individual analyzer or probe data. However, the reasonableness of doing this is questionable, since grouping data in clusters is a more feasible way of presentation, when dealing with such quantities of information. Result of the server side analysis are various qualitative data for each analyzer, probe, group of analyzers or group of probes gathered within a certain time period. There are several parameters that can be adjusted before performing server queries and are independent of the data gathering process it self. More can be seen in section 3.2.1.
2.3.3
Data presentation
Goal of data presentation is to put the results into a perspective that captures the essence of the data analysis in the best manner possible. While it sounds as a very straight forward procedure, this is generally not the case. Before choosing how the presentation will look like, some issues need to be inspected. According de By et al. [1] some of them are:
• Who is the target?
• What is the presentation medium?
• What kind of presentation techniques are available? • What facts should be highlighted?
• Are there some rules of aesthetics?
• What detail of presented data is required?
For a simplification, lets consider the case when the presentation medium is a static map. This leads to the next problem; how will the map be presented to the user. This is an important issue and a lot of research and effort has been put in it.
Berendt et al. [6] suggest that before even considering to present the spatial information, one must first carefully decide on the maps. Authors create a notion of aspect maps - presentation medium. To be able to relate the entities on the map to the spatial knowledge correctly, the appropriate aspect should be shown. This covers aspects that are represented pictori-ally, symbolically and aspects that are not represented at all. The authors present an interesting approach for geographical modeling, while not giving any attention to user profiling which would have an affect on the map.
Another approach presented by Zipf et al. [7] proposes that the map should be organized in zones. They are presented with different level of
Master Thesis - Matic Hajdinjak 9
details, where the zones of users current interest are presented with the most details. They suggest that users focus is automatically attracted to the part of the map with most details. There is an issue of knowing whether all this detail is actually relevant to the user or not. Again as in [6], there is no effort to produce any kind of user profiling on the maps.
Another attempt to solve the problem of presenting user profiled map was made by Zipf et al. [8]. Their model suggest profiling beyond the standard users interests and includes notions like cultural aspects as well. The draw-back of this model is its complexity in order to meet all the requirements.
From the research done it can be concluded that selecting a map is not as straightforward process. Depending on the needs, maps can either be generated as a part of the spatial data presentation or the data can lay on the static maps.
Another important challenge is the spatial data presentation itself. In order to present the spatial information on the map in an user friendly way, one must relate to users cognitive capabilities. People’s cognitive capabilities as well as previous knowledge differ. Therefore, according to Golledge et al. [11], the design of a GIS should be made with the needs, knowledge of the area, interest and before mentioned cognitive capabilities in mind. Lazar [5] describes that selecting colors and shapes used to present information is very important and not an easy task. For instance, one must take care when choosing color patterns as some of them might cause problems to color blind people; using too many different colors or not sticking to known patterns significantly decreases usability and confuses the users.
While it is obvious that these questions are not easy to answer, the help of the context in which the GIS is implemented can help greatly. To relate it to the current challenge; as mentioned in section 1, the target user lacks the deep technical understanding, therefore the presentation should hide techni-cal facts not important to him/her and highlight facts reflecting the general overview, performance, dependencies between items and status of the sys-tem. Presentation medium is a static map presented on a tablet computer or a smart-phone. For presentation techniques essence of a modern application look should be reflected. By that it is meant that the presentation must look dynamic, interactive, clear and easy to handle. For the aesthetics part, the solution tries to reflect other Agama products in order to blend in among other solutions. Data details problem is handled in two stages: (i) less is more perspective, meaning the user should see nothing more than necessary and (ii) multilevel view, giving the user possibility to see more details when needed. More on actual design is mentioned in chapter 3. Despite the presen-tation medium and the target audience is well defined here, the presenpresen-tation techniques are not.
2.3.4
Data prediction
Data prediction is not strictly a part of GIS, but is mentioned due to the nature of the project. As the target platform is a mobile device, pre-caching is needed in order to deliver a smooth and fast experience accompanied by relevant spatial data. Because of systems constraints, it needs to be done in some smart way, to save and utilize the resources in an optimal manner.
A lot of research has been done on World Wide Web (WWW) web site pre-caching techniques as well as in GIS. In latter it is mostly based on users location or his direction of movement. Those techniques are only partly rel-evant to the problem at hand. On the other side, classic monitoring systems present data in real time or upon request and do not apply to this problem as well. Therefore both WWW and GIS caching techniques are briefly ob-served. In essence both techniques are very similar. The concept in a bit wider scale can be traced back to web search engines, where all pages needed to be indexed in some way to be efficiently presented to a user as a result of a search phrase. One of the first attempts of an automatic system capable of doing this was described by Balabanovic et al. [17]. As this index needed to be made in advance, it can be said that this is a form of pre-caching. Therefore it seems that the idea is not limited to devices size, but is uniform regardless of the scale of the system.
Implementing an effective pcaching mechanism is not easy. Much re-search has been done and several different techniques that differ in perfor-mance and complexity have been presented. Both Padmanabhan et al. [19] and Aldous et al. [20] suggest solving the problem by using Markov chains. Markov chain is defined as a random memory-less process. It is a system of finite number of states, where the next state depends only on the cur-rent one. Transition weights are calculated based on some set of parame-ters. That makes them a powerful tool when dealing with user predictions. Another approach is presented by Pitkow et al. [18], where they try to sim-plify the pre-fetching module by introducing the notion of Longest Repeating Sub-sequences (LRS). LRS represents a problem of finding the longest sub-string of a sub-string that repeats at least twice. See figure 2.2. In WWW these strings represent URI addresses. Those are than matched against users moves through the website to predict further events. Performance and complexity vise comparison between LRS and Markov chain algorithms can be seen in A calendar based internet content pre-caching agent for small computing de-vices [16]. Besides those, there are more ways of predictions (such as random walks, described by Aldous et al. [20]).
In contrast to fore mentioned WWW techniques, Weakliam et al. [12] investigate an implementation of a GIS prediction in LBS applications on
Master Thesis - Matic Hajdinjak 11
mobile devices (see section 2.4 for a LBS definition). They undertake the challenge from another perspective. Unlike web sites, which are context de-fined in advanced, they assume that that GIS (maps) are not. They propose a concept where all user movements and user-map interactions are recorded in order to obtain an awareness of users preferences. This is than used to pre-dict the users context and interests. Users movement prepre-diction can than be achieved by adding trajectory of movement, accompanied by the users cur-rent location to the basic LBS. Similar procedures were proposed by Ogrady et al.,[21] and [13]. Solution used for this project is described in section 3.2.5.
Figure 2.2: Longest repeating sub-sequence. Bold line represents a sub-string that has occurred at least twice and a dotted line a string occurring exactly once. Image on the left shows sub-string ’AB’, image on the right sub-string ’ABC’
2.4
Mobile GIS
Since traditional GIS systems have big memory and CPU requirements they are not suited for mobile devices. To mitigate this, the processing is spread across several systems. The mobile client is now a small program only used for the presentation of data and is not used for data gathering and analysis parts. Also, small devices suffer from small screen sizes, limited battery and screen resolution.
GIS have evolved greatly in recent years. They are very useful in con-nection with smart phones, tablets, PDA’s and other mobile devices. On these devices GIS usually comes in form of an Location-Based Service (LBS) applications. LBS applications show spatial data on a map depending on
the users geographical position and are usually available through mobile networks. Therefore it can be said that LBS puts the data stored in GIS databases into a context. However there is a distinction between the two. According to Virrantaus et al. [25] the GIS was developed for a few experi-enced users with a wide range of functionalities, while the LBS is intended for masses without any special knowledge. Therefore we can talk more of a GIS system in the case of this study.
The amount of content available via GIS is increasingly growing. And with them the issues before known only on World Wide Web are coming to GIS as well. One of them is an overload of information the user is presented with. Separating the relevant and the irrelevant information is a big problem. Even if this separation can be done efficiently, pre-caching the information as seen in section 2.3.4 is difficult. This is especially the case when GIS is not used in connection with the users current geographical position, but in the case the user browses the ”map” freely. Such a user expects immediate and interactive spatial data accompanied with a smooth experience. This is not an easy challenge to handle.
Device limitations have a direct impact on the amount of data that can be pre-cached on the device and makes the notion of accurate prediction of users need very important. Another issue is the connectivity. While in a server or a home PC environment, connectivity to the Internet is taken for granted; this is not the case mobile environments. Modern devices use both the phone network and Wi-Fi networks. Both of them are considered unreliable for data transfer. While Wi-Fi can offer high bandwidth, it is very limited in range and sensitive to the environment properties (wall thickness, environ-ment layout, materials used and others). Mobile networks on the other side are considered to be available almost everywhere, but their performance can vary greatly depending on the mobile communication standard used. Exam-ples of such mobile systems can be seen in Managing spatial knowledge for mobile personalized applications [12], Gulliver’s Genie: A multi-agent system for ubiquitous and intelligent content delivery [13], DGPS for Mobile Users: A Mobile Agent Approach [10] and more.
Chapter 3
Design
In this chapter the focus will be on the description of methods used in creating the prototype. It will start by presenting the platform on which the application is developed, reasons for using it and capabilities it offers. Given the fact that the main concern is in presenting the data, next part will make an overview of how the data is obtained in the first place, followed by the data organization. After, it will be explained how the data is maintained and presented. In the end, applications usability and performance will be discussed.
3.1
Platform
There are several mobile platforms available on the marker. The most popular ones are Apple iOS1, Google Android, Microsoft Windows Phone2,
Blackberry3. For this project Android platform was chosen due to its
preva-lence on the market, support for various devices and an excellent application programming interface (API). Above all that, Android is an open source OS. Code for it can be written in Java, it has a built in SQLite relational database and a very adaptable handset layout. Java code it self does not run in Java Virtual Machine (JVM) as usually but is rather compiled into an Dalvik executable. Dalvik is a process virtual machine developed specifically for Android and optimized for running on devices with limited memory and hardware resources. More on the system itself is described in Android de-velopers [22] and Hello, Android: Introducing Google’s Mobile Development Platform [23].
3.2
Data
Data plays the essential role and will be given the most attention. As presented on figure 3.1 the data is gathered first by the aggregation servers. The reason for referring to it as data and not spatial data is, that despite the fact, that information is gathered on specific geographical locations, the system does not track it. It is however gathered in a hierarchical matter, making it possible to determine whether a data belongs to a particular set or not. This is discussed in details in section 3.2.2. To overcome this system pitfall, geographical locations are given to probe groups and analyzers for the needs of this project. They might not reassemble their actual geographic locations, but this is not of an important issue in this case. Data of interest for this project is:
• Probes with the worst quality of distribution.
• Probe group’s quality of distribution, size and the number of active probes within a group.
• Analyzer status per particular channel.
• Alarms appearing in the network (either in probe groups or analyz-ers).
1http://www.apple.com/ios/
2http://www.windowsphone.com/en-us 3http://us.blackberry.com/
Master Thesis - Matic Hajdinjak 15
Quality of distribution (QoD) is a term describing several individual param-eters that are used to present the state of a system. Some of the important ones are:
• OK − the proportion of active time when the probe or probe group has had no problems. A value in the interval [0.0, 1.0].
• MINOR − the proportion of active time when the probe or probe group has had minor problems. A value in the interval [0.0, 1.0]. • MAJOR − the proportion of active time when the probe or probe group has had major problems. A value in the interval [0.0, 1.0]. • UNAVAILABLE − the proportion of active time when the probe or probe group has had major problems. A value in the interval [0.0, 1.0]. • ACTIVITY − the activity level of the probe or probe group in IP Linear TV during the specified interval. A value in the interval [0.0, 1.0].
How this individual values are calculated is a part of the data analysis seg-ment done on the server and is not important for the case at hand.
Analyzer channel status report is presented as a simple number indicating its state. Despite being defined with whole numbers, its status and QoD values are somewhat related. Possible analyzer channel status values are:
• 10 − monitor is stopped. • 20 − channel is OK.
• 30 − channel has minor errors. • 40 − channel has major errors. • 50 − channel is unavailable.
Alarm reports are organized in structure consisting of several parameters. Not all are used as some describe technical details beyond the understanding of the targeted user. Used alarm parameters include:
• ID − unique identifier given to alarm.
• Severity − indicates the seriousness of the alarm in accordance to RFC 38774.
• Event type − describes the type of alarm (e.g. Quality of Service alarms).
• Message − describes the cause of the alarm.
• Time − time stamp, indicates the first report of this alarm.
• Probable cause − describes the event that might have caused the alarm.
3.2.1
Obtaining data
Due to the way the data is handled in Agama systems, obtaining the data is the bottle neck of this project. Current system offers two Application Programming Interface (APIs). They are:
• XML-RPC5
• SOAP6
Both of them are nowadays considered to be outdated, and lack official sup-port in the targeted OS. Both standards are based on the XML format which is verbose on one side but bloated on the other. In case of simple function calls, the result is a big overhead. Depending on the complexity of the call-ing function, the servers response time can vary. To mitigate this, several concurrent calls can be made to the server. This however comes at a price. Concurrent calls result in several threads on the mobile system to run at the same time. This makes the control logic more complex and causes a burden for the already limited hardware. However there is some support available for adjusting threads priority. It is crucial that these calls do not have a visible impact on other tasks that are connected with the visible parts of the application.
3.2.2
Data organization
Data used in the project is split between two databases. Distribution can be seen on figure 3.1. Aggregation server database performs data analysis and holds the entire set of data. It is also used by several other Agama solutions. Data stored locally on the mobile device is a copy of data from the aggregation server and is obtained upon requests. Reasons for having a localized database is to improve performance and to have a way of showing data in case of Internet connection issues.
As mentioned previously data is organized in groups, with hierarchy ex-isting within the groups. That makes it possible to be treated as a tree
5http://xmlrpc.scripting.com/default.html 6http://www.w3.org/TR/soap/
Master Thesis - Matic Hajdinjak 17
based structure, where the leaf nodes are probe groups that contain no other probe groups. Nodes represent probe groups that can be divided into several smaller probe groups and the root is a super-set containing all probe groups. The super-set of all groups is however never used, instead the root is defined as the first node (there fore there can be several trees). See figure 3.2.
Information on the device is kept in a database (built-in SQLite7database).
This is used as a sort of a cache to provide a constant access time to data. Data is assigned made up locations, while still trying to preserve some kind of order. It is assumed that items located on nodes close to each other, are also located close in terms of geographical proximity. For example probe groups a004.b003.c002 and a004.b003.c003, both belong to the a004.b003 group and are thus part of the same sub-network. It is therefore reasonable to assume that they are located relatively close to each other.
Figure 3.1: Test case data organization.
Figure 3.2: Probe groups are organized in a tree-like structure. Group shown here is in the lowest hierarchy (level 4 - leaf), belonging to the he.rec.kpn.a004 (or simplified .a004 ) root group.
3.2.3
Data maintenance
Data maintenance covers the area of deciding how long the data will be stored on the mobile device and how often will it be updated. Storing data indefinitely would present a waste of resources. During simulations it was observed, that roughly 5 − 6[M b] of raw data are gathered on the mobile device daily. While this does not sound much in PC storage terms, it is a lot for small devices. Also, old data is of very limited use. Therefore a query is run on application start up which deletes data older than 24 hours.
Due to the design of the aggregation servers, the smallest interval in which they aggregate data is 4[min]. For this reason, querying for new data within this interval is pointless as no new information is available. Doing this would only result in wasting servers resources, having duplicated results in the local database or getting a null response from the server. Proposed data flow on the mobile part is presented on figure 3.3
Figure 3.3: Data flow chart representing data request and decision mecha-nisms used in the solution.
Master Thesis - Matic Hajdinjak 19
3.2.4
Data presentation
Data presentation is crucial as it is the part of the GIS that the user sees and interacts with. For this project data is presented on a static map based on OpenStreetMaps8, with locally stored map tiles.
On the map, an overlay containing items (probe groups, analyzers) is located. Overlay is updated upon user interaction with the map or when items on it are updated. It contains items which are located within the currently visible boundaries of the map and lay in the correct detail−zoom level. Determining which probe group fits in which detail level of the map is achieved by establishing a relation between those two terms. Relation can be seen on figure 3.4. This relation gives a possibility of instant scaling of data, providing the possibility to monitor the whole system or a very small part of the system, with merely zooming in and out. Note, analyzers are not part of the map detail−to−map paradigm and are represented on all available detail levels.
To recreate the network infrastructure, analyzers are connected together, forming a backbone of the network. Probe groups are then connected to appropriate analyzers. To make sure the distinction is clear enough, lines representing probe group − > analyzers connections are of a different color (blue) than ones presenting analyzer − > analyzer connections (red ).
Information describing items is presented in various views. They are split into two groups. Some are a detailed representation of an item and others present several items in a relation using some dependency. Views do not effect each other and are presented simultaneously. As of this moment, only the probe group views can be changed upon users interaction.
• Probe group views ◦ Biggest groups view ◦ Most active groups view ◦ Group detailed view • Analyzer view
◦ Analyzer detailed view ◦ Time-line correlation view
Figure 3.4: Relationship between the detail level (zoom) on the map to the hierarchy of presented items. Squares represent probe group items.
3.2.5
Data pre-caching
Data pre-caching is an important step to achieving a good user experience and avoid periods when a user waits for new information. The goal was to make sure, the user always has some information available. Even if it slightly outdated, it is seen as a better solution than no data at all.
Process is split into two distinct parts. (i) ”What items should be up-dated?” and (ii) ”Perform the update”.
Answer to the first question can be seen as the following two strategies. At (i) minimum, the currently visible items should be updated and at (ii) maximum all of the items should be updated. Both approaches will give a sufficient results, but at a cost. Minimum approach will be efficient as it only delivers data needed at the moment, but will lack relevant data if the user moves or adjusts the zoom level on the map. Maximum approach ensures that data is up-to-date for all items, but pays the price in big update cycles, problems with scalability and a big overhead when the item pool is sufficiently big. Therefore attempt is made to add some smartness in this decision making in order to find some middle ground where effect of out-dated items and overhead is as small is possible. This is discussed bellow in the Pre-caching algorithm part. After a set of items-to-update is selected, performing an update is done silently without attracting the user. In Service part bellow it is described how this is achieved.
Pre-caching algorithm
Due to the nature of data organization, a pre-caching algorithm is based upon a mixture of Longest Repeating Sub-sequence (LRS) paradigm (meaning simply, the selection of a root of the probe group), the visible area and maps detail level. LRS weights are calculated from swipe direction, items location and items last update. Algorithm strictly searches only items that
Master Thesis - Matic Hajdinjak 21
are currently not visible and does not make any checks whether the data actually needs to be updated. This is carried out later, upon a data request for either scheduled update (service) or upon users interference (as described in section 3.2.3).
Data: visible items[], swipe direction, view level, map bounds Result: prefetch items[]
if view level != MAX LEVEL then
//find suitable items lying one level bellow the current one; items[] = find visible(map bounds, view level + 1);
for item in items do
weight = calculate weight(item.loc, item.last update, swipe direction);
if weight > THRESHOLD then prefetch items.add(item); end
end end
if view level != MIN LEVEL then
//find suitable items lying one level above the current one; items[] = find visible(map bounds, view level - 1);
for item in items do
if prefetch items.contains(item) then //item is already added;
continue; else
if item == LRS(visible items) then
//item is a root of a visible item, add it without calculating weights;
prefetch items.add(item); else
weight = calculate weight(item.loc, item.last update, swipe direction);
if weight > THRESHOLD then prefetch items.add(item); end end end end end
Service
Services are a standard approach for performing silent updates in the background. Here three independent ones are used to keep information on the mobile device up-to-date.
• Service that takes care for probe groups information. • Service that takes care for analyzer information. • Service that takes care for worst probes information.
The reason to split them up, is to be able to perform updates in concurrent manner. Before updates are run, a check is made to determine which items should be updated. Set of possible update candidates depends on (i) items on the visible part of the map and (ii) items that get selected by the pre-caching algorithm (described in section 3.2.5). This results in a subset of items upon which further filtering is applied based on the time passed since the item in question was updated for the last time. If it is reasonable to expect new data to be available, than the item is selected from this set. In that case, the following condition needs to be satisfied:
systemt− itemu >= itemp,
where itemu is the last successful item update, systemt, the current system
time and itemp is this items update period (e.g. 4[min] for probe groups).
3.3
User experience and usability
It is important that the user experience is not just a copy of the web UI interface. Hoivik [24] splits requirements needed for a good mobile experience (content vise) into 4 categories.
• Elite edition − version of only selected, important, well presented data. • Sampling − mobile version should provide samples of the capabilities
of the full website.
• Interface − mobile application can behave as an interface to the general repositories.
• Polyvalence − ability to present the same content on various screen dimensions, sizes, resolutions,..
Master Thesis - Matic Hajdinjak 23
While this lemmas were intended for websites presented on mobile devices, they are also valid in this case. The author does not get involved into ways the user actually handles with the application. It is important that this is done in a user-familiar way. This means, using gestures (mainly tap and swipe), structures (positions of menus) and handling techniques (buttons, selectors) seen in other applications.
To achieve the liveliness effect, data (items) are dynamically loaded. How-ever this presents some difficulties. It was anticipated, that a user is able to move to an area where items are located (e.g. a probe group), but the data is not available for some reason (for instance, Internet connection is currently unavailable). To solve this, dummy default data is inserted when displaying it (presenting it in a distinct way, to not confuse the user). However, due to items being dependent on each other when being presented, some basic item parameters must be available to be able to draw it. For example, pa-rameter number of probes within a probe group is needed in order to draw probe groups in group size perspective, since the the number of probes within a group affects its final size.
3.3.1
Control
Control of the application should be simple, intuitive and unambiguous. Controls are defined as gestures. Proposed ones are as follows:
• Pinch − used to change details level (zoom) on the map.
• Swipe − used to move on the map and the QoD graphs (Described in section 4.2.1).
• Tap − used as a selector gesture (e.g. mouse button 1). Can also be used to zoom in on the map.
• Long tap − used as a selector gesture to mark an item and open a new view.
Results and Solution
This chapter first presents a prototype solution developed upon the parts presented in previous chapters. The solution is then described. Besides im-ages of the application, individual views are described along with the intended use cases. A few lines are devoted to making a comparison between the ex-isting UI and the developed one. Procedures used to reduce the complexity of the UI comparing to the existing ones are shown. This is then followed by a discussion on how this in turn affects the flexibility of the solution. In the end, methods of validating the prototype are presented and discussed.
Master Thesis - Matic Hajdinjak 25
4.1
Application
Prototype called Agama Monitor was developed on the Android platform, targeting tablet computers. It is a port of an existing web-based user interface made suitable for touch screen systems. Data is presented to the user in a spatial matter, therefore the system as a whole is a GIS, but it is not meant to be used together with users geographical location. Rather it resemblance a monitor of an infrastructure, such as road network, rail network, computer network,.. Due to the platform used and the preexisting infrastructure upon which the system was built, the GIS is split in several independent parts. Hardware intensive parts (data gathering, data analysis) are performed on the server side, while the mobile device is only used for data presentation. Applications basic UML diagram can be seen on figure 4.1
Focus is on making the interface present data as up-to-date as possible and in the ”not more than necessary” detail level. This ensures that handling with large amounts of information is simple and transparent. The basic application view can be seen on figure 4.2. Application organization is very simple, with the control line on top and the map view taking the rest of space. Probe groups are presented as sort of pie charts with an additional parameter presented on the side of them. Analyzers are presented as chart graphs.
Figure 4.1: UML diagram of the basic steps proposed to achieve a desired view implemented in the prototype solution.
4.2
Use-cases
Use-cases represents a list of steps an actor (user in this case) needs to perform in order to achieve some kind of a goal. They are an important mechanism to present and evaluate the capabilities of a system. Bellow, several use cases will be presented. They will be compared to the existing solution.
4.2.1
Items
Both probe groups and analyzers share the same view. This is not the case in the existing UI. The goal was to present as much information as possible at once in order to keep the users interference on the minimum, while still achieving clarity on the map. For efficiency reasons, item images are stored in a 2−level Least Recently Used (LRU) cache, where 1st level is a memory cache and the 2nd a disk cache. To show the strength of the UI, lets observe the content on the map from figure 4.2. It can be interpreted as follows:
• There are 2 visible root probe groups (this is visible from the name) and their geographical location.
• Last update of the probe groups.
• Since there are no blue lines connecting a probe group to any analyz-ers, it can be concluded that the individual groups have the closest analyzer located at the same geographical location (their images are visible under the group images).
• Both groups are experiencing some issues (alarms). This is marked with an exclamation mark in the middle of the group image.
• Underlying analyzers do not have any alarm signals on them, therefore the issue might lie in the ”last-mile” part of the network and not the part of the core network located close to these groups.
• Probe group QoD parameters (defined in section 3.2) are showed in a pie chart and it can be seen that group .a021 is currently performing slightly better than group .a004.
• .a021 pie chart is a bit bigger than .a004 one indicating (in this case) the size relationship between the groups (.a021 has more probes than .a004 ).
• Pink indicator next to the pie charts shows the average activity of the probe group, giving the user an oversight on the validity of the data.
Master Thesis - Matic Hajdinjak 27
• Last update of the analyzers. • Analyzer geographical locations.
• Analyzer hierarchy (their location depending to the network entry point). • Analyzer QoD parameters for the last period and alarms present on
them.
Another example of a more in depth view can be seen on figure 4.3. There the probe group−analyzer relationship can be seen better (observe the blue lines).
Detailed view
Detailed view is needed in order to avoid filing up the map with to many parameters which would make the interpretation of the information unbear-able and ambiguous. Distribution of views inside of an detailed view is orga-nized as it was presented once before on the figure 4.1. The view is custom for every item and is reached by a long press gesture to the item. The view is split into several sections depending on the type of the item (probe group or analyzer). Those sections are:
• Parameters − present in both analyzers and probe groups • Worst Probes − present only in probe groups
• Alarms − present in both analyzers and probe groups • Nearby Groups − present only in probe groups
A sample of the different group detailed views can be seen on figures 4.4, 4.5, 4.6, 4.7. From the orientation on the top of the screen it can be seen which section of the view is selected and possibly, which item or parameter is observed. Analyzer details view looks identical, only lacking the Worst Probes and Nearby Groups options. Interactive graphs used in the detail view along with analyzer graphs presented on the map are taken from the existing UI, as can be observed from figures 4.9 and 4.10. With adding support for gestures on top of the graph images, they have become interactive, where a user can zoom in and out, swipe to the left or to the right. The interactivity feel was achieved by retrieving graph images on the fly.
4.3
Comparison to the existing Web UI
Implemented solution tries to reduce the number of steps needed to access information, link information together and mainly simplify the whole user
Figure 4.2: Basic view on application start up, showing 2 distinct probe groups as pie charts, analyzers as graphs and the core network infrastructure, presented as red lines.
Master Thesis - Matic Hajdinjak 29
Figure 4.3: View showing dependency of groups between each other and their relationship to the nearest analyzer.
experience. In the existing UI, the user sets a few parameters before accessing any kind of information. While some parameters affect what information the user is seeing, others decide only on the presentation techniques (e.g. graph size and resolution). Parameter selection for probe groups can be seen on figure 4.8. In proposed implementation, parameter selection was solved in the following way; Start time, End time, Probe group are preset and the user has a limited influence on them (he or she can only change the update interval, which in terms has an effect on the start and the end time). Other parameters are left with default values. Now the users does not have to set any parameters anymore, simplifying the experience. This does lead to lower flexibility, but it is suitable in this case, as the target user is interested more in the overview than in the fine-tuning of the system. Analyzer selection parameters window is very similar and will not be discussed further.
For comparison, the results of probe group and analyzer selections on the existing UI can be seen on figures 4.9 and 4.10 respectively. Here the graphs adapted in the prototype are generated.
4.4
Testing
Testing for this project was split in two parts. • Correctness of the solution
Figure 4.4: Shows detailed information of the probe group and the various parameters being collected. It also shows raw QoD figures used to draw pie charts. Bellow, m (max 15) last updates (pie charts) are showed and an interactive graph of past QoD parameters. It is possible to use the hand gestures to move on the graph (zoom in/out, swipe left/right).
• Usability testing
Correctness was tested by comparing the raw values with the ones on the existing UI. Despite the data source is the same in both cases, some issues have been observed during implementation stage. They were a result of wrong constraints in the local database. The whole system is populated with thousands of items, but the prototype was tested with only 120. While this was enough to determine the grade of performance while rendering the items, it was a challenge proving the effectiveness of the pre-caching algorithm. Due to time constraints the performance was visually measured in terms of the responsiveness of the whole application.
Applications response was compared to the one achieved by the minimum and maximum strategies described in section 3.2.5. It was observed that minimum strategy performed relatively well in situations when the Internet connection was stable and reliable, showing a small delay time between the map manipulation event and new items being available. Delay was on an average between 5-15[sec]. Maximum strategy on the other hand performed terribly, lagging the application under the heavy load of updates. Usage of
Master Thesis - Matic Hajdinjak 31
Figure 4.5: Shows worst n (max 10) worst probes in the selected group along with their QoD parameters and the appropriate Analyzer trace that could reveal some insight on why the probes are behaving the way they do.
smart prediction caused a more evenly distributed amount of items being updated regularly. Instead of having burst events when several items need to be updated, followed by a long period when no updates are necessary, algorithm divides the updates into several steps. This is the consequence of using weights. During application run time, these update distributions can be seen as items lying together having a different last update parameter, which is not an issue as long as those parameters lie within the aggregation servers update periods (otherwise the item is immediately updated). Delay did lower to 1-10[sec].
Usability testing was done among the employees of the company where the project was performed. They were given no instruction on how to handle with the application. Their behavior was then observed to determine how quickly did they get the grasp of it. After that, the use cases were presented to them. In the end, feedback regarding the user-friendliness, transparency and overall impression was collected. Their suggestions were used to correct the issues exposed by the testers. Unfortunately, the sample of testers was limited to 9 people of roughly the same age and technical knowledge. Therefore the test needs to be taken with caution. Also, none of the testers had disabilities such as color blindness, which could reveal potential additional problems.
Figure 4.6: Shows current active alarms along with its parameters in the probe group.
Figure 4.7: Shows groups located near the viewing group, ordered by dis-tance. Used to pin point the source of problems, or to get some context on how the problems in one probe group are reflected in others.
Master Thesis - Matic Hajdinjak 33
Figure 4.8: Parameters needed to be set in order to see a specific probe group in the existing web UI.
Figure 4.9: Result of a query, showing probe group overview in existing UI.
Conclusion
Geographical Information Systems are an evolving industry, making their way in a all aspects of the society. It truly is a powerful tool when dealing with spatial data. With the boom of ”smart” personal devices, GIS in the shape of LBS have penetrated to this area and took its share. Due to a lot of research done it is evident, that GIS popularity is still growing.
This thesis presents an attempt of using a GIS in the form of a tv-network monitoring system, running on a tablet computer. This is a step away from traditionally centralized monitoring centers. While there is a lack of some functions, it shows that a monitoring system can be implemented in an easy to use, self-explanatory high enough level, making it understandable to a technical knowledge lacked user. A successful prototype implementation pro-vides a proof-of-concept presenting a ground upon which the future attempts can be made. It also exposes problems in the current structural organization of the back-end systems used at Agama. Such problems are strict separation of the analyzer system and EMP (probe) system and the absence of storing actual geographical locations of analyzers and probes.
Accessing data proved to be an initial issue. Problems appeared on both the server and client side. Servers used XML-RPC and SOAP API’s which are fairly outdated, suffer from overhead (comparing to, for example JSON or CORBA) and lack from official support in Android. Another downside was the fact that servers did not follow the XML-RPC standard entirely, which caused some remote procedure calls done via XML-RPC not to work. Ideally queries should return immediately, but as the data for several functions is generated upon request, this resulted in slow server response times in some cases.
One of the prerequisites was interactivity − application must seem alive and dynamic. This posed a challenges, as the data is aggregated in 4[min] intervals. There is no way to change this, as it is one of the basic principles
Master Thesis - Matic Hajdinjak 35
upon which the whole aspects of Agama solutions work.
To make the application look smooth, overlay items on the map must gen-erate smoothly and fast. An effective solution would be caching the overlay items images and scale them appropriately when needed. However, despite down-scaling was always used (image size * n; where n< 1) the results were not good. For that reason all overlay items were generated on-the-fly using data from the local database. Generating times were in area of 5 − 10 ∗ times bigger than when accessing them then via cache. The absolute generation time depended on the amount of items needed to be drawn. Durings tests it was on average slightly bellow 1[sec].
Further work suggestions can range from expanding the prototype to other operating systems such as iOS and Microsoft Windows Phone. Project was made with some degree of portability in mind. The SQLite database used, is used also on the mentioned platforms, which decreases the amount of work required. Another possibility is to increase the range of use-cases by adding new features that are suitable for touch screen environments, such as real interactive graphs, instead of using static images. Both proposals require quite some effort to be put into the project. However an extension in terms of adding a new view by extending the current ones (biggest groups, most active groups) should be rather trivial on the client side, but would require new features to be developed on the server side.
[1] Rolf A. de By, et al., Principles of Geographic Information Systems., International Institute for Aerospace Survey and Earth Sciences, En-schede, The Netherlands, 2nd Edition, 2001.
[2] P. A. Longley, M Goodchild, D. J. Maguire, and D. W. Rhind, Ge-ographic Information Systems and Science., John Wiley & Sons, Inc., Chichester, England, UK, 3nd Edition, 2011.
[3] K. C. Clarke, Getting Started With Geographic Information Systems., Prentice Hall, USA, 5th Edition, 2010.
[4] W. Tobler, Automation and Cartography., In Geographical Review., vol-ume 49, pages 526−534, 1959.
[5] J. Lazar, Web Usability: A User-Centered Design Approach. Addison-Wesley, USA, 1st Edition, 2006.
[6] B. Berendt, B. Barkowsky, and C. Freksa., Spatial Representation with Aspect Maps., In Proceedings of Spatial Cognition: An Interdisciplinary Approach to Rep-resenting and Processing Spatial Knowledge., pages 157−175, Springer-Verlag, London, UK, 1998.
[7] A. Zipf, and K-F. Richter., Using Focus Maps to Ease Map Reading., In In: Kunstliche Intelligenz (KI)., pages 35−37, 2002.
[8] A. Zipf., User-Adaptive Maps for Location-Based Services (LBS) for Tourism., In Proceedings of the 9th International Conference for Infor-mation and Communication Technologies in Tourism., Innsbruck, Aus-tria, 2002.
[9] V. Despotakis, M. Giaoutzi, P. and Nijkamp., Dynamic GIS Models for Regional Sustainable Development., in M.M. Fisher and P. Nijkamp (eds.)., Geographic Information Systems, Spatial Modelling and Policy Evaluation., pages 235–261, Springer-verlag, Berlin, 1993.
Master Thesis - Matic Hajdinjak 37
[10] M. J. O’Grady, and G. M. P. O’Hare, DGPS for Mobile Users: A Mo-bile Agent Approach., In Proceedings of 2nd European Space Agency (ESA) Workshop on Satellite Navigation User Equipment Technologies NAVITEC., Noordwijk, The Netherlands, 2004.
[11] R. G. Golledge, R. L. Klatzky, J. M. Loomis, J. Speigle, and J. Tietz, A geographical information system for a GPS based personal guidance system., In International Journal of Geographical Information Science., volume 12, number 7, pages 727−749, 1998.
[12] J. Weakliam, D. Lynch, J. Doyle, H. M. Zhou, E. M. Aoidh, M. Bertolotto, and D. Wilson, Managing spatial knowledge for mobile per-sonalized applications., In Lecture Notes in Computer Science (includ-ing subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics)., volume 3684, pages 329−335, 2005.
[13] M. J. O’Grady, and G. M. P. O’Hare, Gulliver’s Genie: A multi-agent system for ubiquitous and intelligent content delivery, In Computer Communications, volume 26, number 11, pages 1177−1187, 2003. [14] P. H. Hiemstra, E. J. Pebesma, C. J. W. Twenh¨ofel, and G. B. M.
Heuvelink, Real-time automatic interpolation of ambient gamma dose rates from the Dutch radioactivity monitoring network., In Computers and Geosciences., volume 3, number 8, pages 1711−1721, 2009.
[15] G. D. Vecchia, L. Gallo, M. Esposito, and A. Coronato, An infrastruc-ture for smart hospitals., In Multimedia Tools and Applications., volume 59, number 1, pages 341−362, 2012.
[16] A. Komninos, and M. D. Dunlop, A calendar based internet content pre-caching agent for small computing devices., In Personal and Ubiquitous Computing., volume 12, number 7, pages 495−512, 2008.
[17] M. Balabanovic, Y. Shoham, and Y. Yun, An Adaptive Agent for Auto-mated Web Browsing., Stanford InfoLab, 1996.
[18] J. Pitkow, and P. Pirolli, Mining longest repeating subsequence to pre-dict world wide web surfing., In Proceesings of USITS’ 99: The 2nd USENIX Symposium on Internet Technologies & Systems., Boulder, Col-orado, USA, 1999.
[19] V. N. Padmanabhan, and J. C. Mogul, Using predictive prefetching to improve www latency., In ACM SIGCOMM Computer Communication Review., volume 26, number 3, pages 22−36, 1996.
[20] D. Aldous, and J. Fill, Reversible Markov chains and random walks on graphs., In progress. Manuscript available at http://stat-www.berkeley.edu/users/aldous/RWG/book.html.
[21] M. J. O’Grady, and G. M. P. O’Hare, Just-in-time multimedia distribu-tion in a mobile computing environment., In IEEE Multimedia, volume 11, number 4, pages 66−74, 2004.
[22] Google Inc., Android developers., The Official Website at http://developer.android.com/
[23] E. Brunette., Hello, Android: Introducing Google’s Mobile Development Platform., Pragmatic Bookshelf, 2nd Edition, 2009.
[24] J. Hoivik., Mobile Digital Library in the National Library of Norway., Presented at World Library and Information Congress: 76th IFLA Gen-eral Conference and Assembly., IFLA, Gothenburg, Sweden, 2010 [25] K. Virrantaus, J. Veijalainen, J. Markkula, A Katasonov, A. Garmash,
H. Tirri, V. Terziyan., Developing GIS-Supported Location-Based Ser-vices., In Proc. of WGIS 2001 First International Workshop on Web Geographical Information Systems., pages 423−432, Kyoto, Japan, 2001.
