You Are Here. Timon van de Velde ( ) June 14, 2011

Transcription

1 You Are Here Timon van de Velde ( ) June 14, 2011 Supervisors: Dr. R.G. Belleman Dr. G.D. van Albada Dr. I. Bethke

2

3 Contents 1 Introduction Research Objective Related Work Design Functional Requirements Design Choices Architecture Overview Implementation Building the HTML Image Maps Structure of HTML Image Maps Parsing the Data Mapping Locations to the Graph Finding the Shortest Path Finding Employee s Offices Website Set-up Determining the User s Location Visualizing the Route Benchmarks LDAP Server Sequential testing Parallel testing Pathfinding Web Server Discussion 27 6 Conclusion 28 3

4 Abstract Visitors of the Faculty of Science of the University of Amsterdam at Science Park Amsterdam often get lost inside the main building. We have created a system that will help them find a way to their destination. Several kinds of destinations are currently supported, the most important being employee offices. The offices are automatically extracted from an LDAP server when a user enters the employee s name. Access to our system is ubiquitous through the use of technologies provided by most smartphones and tablets. It is web-based and displays the shortest route in a Google Maps interface. There is no element of sensor based navigation, only the route is displayed. At the core of our system are QR codes that are strategically placed throughout the building. Users can reach the website by scanning these QR-tags, which pass the user s location to the website and computes routes based on that location. 1 Introduction Science Park Amsterdam, one of the many locations of the University of Amsterdam, is often visited by people who are not familiar with the building s layout. There have been many occurrences of visitors having a hard time finding the office of one of the employees. In order to make the building more accessible, the idea rose to create a system that would help in guiding visitors to their destination. With this system, people should be able to search for employees. If that employee has an office, the user gets a map of the building that shows a line indicating the route to follow. We expanded on this idea and we now have functionality that allows people to find their way to all sorts of different interest points. Among these are restrooms, fire alarms and AED (Automated External Defibrillator) devices. Through careful consideration, we decided the system would become a webbased solution. There are several technical reasons for this, but most importantly, a web-based system is available to all platforms that have a browser. This includes mobile devices. If people can use their smartphones or tablets, for instance, to access the website, that would be a major advantage. This also means we can use some functionality that most mobile devices have; scanning QR codes. We put QR codes throughout the building, these tags are then used to determine where the user is. The system can then set the user s location as the start of the routing algorithm. We use the Google Maps API to draw the map of the building containing route information. In order to render this map, the browser does have to support JavaScript. This is a dependency that technically could be avoided, but we feel JavaScript is so readily available in browsers that this is not an issue. 4

5 1.1 Research Objective The main goal of this research is to be able to guide people around the C building at Science Park. There will be several points of interest people can be navigated to, but it is most important to be able to guide them to the offices of FNWI (Faculty of Science) employees. All this should be done in such a manner that is minimally obtrusive, but still as helpful as possible. 1.2 Related Work In Salomon et al. [1], an approach is presented for navigating through a complex environment. A pre-computed global roadmap is used to compute collision free paths through the environment. Users are able to manually control the avatar that travels through the environment. In such a case, collision checks are automatically performed. A variant of A* search algorithm (see section 3.5), IDA*[2], is used to perform the path planning. This variant is designed to have lower memory usage than A*. The most commonly used form of navigation by consumers is found in cars. These devices determine their own location by using the Global Positioning System (GPS)[3]. By overlaying their location on a map containing data on streets, they are able to compute a path between two locations. This path is visualized to the user with a top-down or angled view of this map, where the correct route is highlighted. The downside to GPS is that it generally cannot be used indoors. Systems exist that perform indoor navigation based on Radio-frequency identification (RFID)[4] sensor tags. Such a system was made by Kulyukin et al. [5]. In that system, a robot could guide the visually impaired by scanning for RFID tags in an indoor environment. The problem with indoor navigation based on RFID is that tags cost money and scanners are not widely available. Augmented reality was used by Reitmayr and Schmalstieg [6] to allow navigation and information browsing in urban environments. Users could get information on screen that is of particular interest to tourists. The system used a notebook with a 2 GHz processor and an NVidia Quadro4Go graphics accelerator. Visual overlays on the screen are positioned by using GPS signals. This cannot be used indoors, and will most likely require fast hardware to execute properly on a device. QR codes have been used by Seine et al. [7] to trace fishery products. Unique QR tags were placed on the product, and data about its history stored in a database. Consumers could then scan these tags to retrieve this data. No additional information was included in the tags. They were all unique serial numbers. 5

6 2 Design 2.1 Functional Requirements Before implementing a system, it is good practice to first think about the functional requirements expected from the system. The functional requirements will be influenced by restrictions caused by the available technologies which in turn will influence our system design. 1. Compute route between two locations across multiple floors A way to compute a route is of course essential to any navigation system. In order to compute a route between two locations. Both locations must be known to the system first. After both locations are known, there must be some way to indicate how to travel. This brings us to additional requirements in order to meet this one. (a) There must be a data structure that tells us where points of interest are. (b) There must be a data structure that tells us where we can travel. (c) There must be an algorithm that tells us how we should travel. 2. When given the name of an employee, guide the user to their office This is the main reason why the idea for this system came up. Visitors get lost trying to find their way to some employee s office. In order to navigate to one, the system will require the name of the employee. After which their office has to be determined. (a) Obtain employee s room number. 3. Determine the user s current location. In order to be able to navigate a user to some point of interest, it is necessary to know the user s current location. 4. Visualize route in such a way that is helpful to the user The user must have some way to interpret the route to some destination, therefore there must be some sort of visualization. (a) There must be a device on which to visualize something. (b) There must be a method of visualizing. 5. The system should be easily available to a large number of users The goal of this system is to guide visitors of the faculty. These visitors will not have access to very specific hard- and/or software. We want our solution to be helpful to many people. 6

7 6. The required amount of user-machine interactions before results are obtained should be minimal If it takes too much time before users have what they want, they might just give up halfway. To make this system a success, it should provide a good user experience. 2.2 Design Choices Here we will explain what strategies we have chosen to satisfy the requirements specified in section 2.1. This section only serves that sole purpose. Any in-depth information will be included in section Compute route between two locations across multiple floors (a) We need some method of storing data about the building s offices and other points of interest. Luckily, previous research already produced such a data structure. HTML image maps were used to model the building and divide offices between employees when it went into use [8]. These HTML image maps are files that contain two-dimensional shapes and a URL (as they are designed to be used for web development to make images clickable in specific areas). We decided to use these maps for our cause. (b) A data structure for navigating is most commonly a graph. There are many traversal strategies for graphs. Since we are using HTML maps for representing points of interest, we are going to also add graph data to these maps. (c) We are going to compute the shortest route between two locations within the building. In situations where floor plans are very complex, it is possible to imagine a path that is difficult to follow, even though it is the shortest way from A to B. In such a situation, it could be an idea to devise an algorithm that takes into account whether or not a path is overly complex. However, the layout of the C building at Science Park is fairly straightforward, so it would be hard to find paths that are less complex than the shortest path. We can add flexibility to the shortest path solution by allowing users to select whether they want to travel by elevator or staircase or either. There are several commonly used algorithms for calculating the shortest path in a graph. Among those are the A* search algorithm and Dijkstra s algorithm. Both are guaranteed to find the shortest path between two nodes in a graph. We have opted to use the A* algorithm for its performance benefit. Even though we currently only navigate a single building which results in a relatively small graph, this could be expanded in the future. In terms of development, it is not a lot of work to implement A*. We see no reason to use Dijkstra s algorithm instead of A*. 2. When given the name of an employee, guide the user to their office 7

8 We have to obtain employee office data before this can work. The only easily available source on this data is found in an LDAP server located within the UvA domain. LDAP stands for Lightweight Directory Access Protocol [9]. It can be accessed remotely and represents a tree like directory structure. There is an alternative source available online as well, but this is not accessible to us. The problem with both sources, is that neither is guaranteed to be complete or up-to-date. For some employees, there is no office data while they do have an office and for others, wrong room numbers might appear. For most entries, however, the data is correct, so we can use this as a source. The LDAP server is only reachable within the UvA domain. This influences the design of our system in that at least part of it needs to execute in a location within the UvA domain. 3. Compute route based on user s location The problem here is obtaining the user s location. This position can then be used in the pathfinding algorithm. An option would be to let the user say where he is. This would require a few extra steps before the user gets to any material that will help guide him. This conflicts with requirement 6. It would be better to extract this information automatically. In today s digital world, most mobile devices come with cameras and software to scan QR codes 1 (see Table 1). These codes are two-dimensional bit strings. When scanned, they produce a character string. QR codes are commonly used to direct mobile devices to websites (in which case the character string is in fact a URL). We can make use of this functionality to locate users by encoding a position in the QR code. There are two ways we can use these QR codes. One would be to develop a system that is to run directly on the device. This would require the user to install the system first, which again conflicts with requirement 6. It would also mean that in order to satisfy requirement 5 we would have to develop the system for multiple platforms. It would be better to create a web-based solution. This has the advantage that it works on any device that has a browser. That satisfies requirement 5. The QR codes could simply refer to a website with an additional location parameter. It would also satisfy requirement 6, by making the system easily accessible. Operating system Android BlackBerry Windows Phone Symbian ios Application Barcode Scanner QR Code Scanner Pro Mobiletag Barcodes Reader BeeTagg QR Reader RedLaser Table 1: QR readers on popular mobile operating systems. 4. Visualize route in such a way that is helpful to the user 1 8

9 (a) Routes can be visualized in many different ways ranging from virtual reality to text-based directions. Augmented and virtual reality might help in making sure users get to their destination, but both are beyond the scope of this paper and in addition, would conflict with requirements 5 and 6. Virtual reality would require specific hardware, which visitors do not have access to. Visualizing anything would have to happen on some device available to many people. Requirement 3 suggests to use mobile devices. Any kind of visualization is going to happen there. (b) Augmented reality (AR) could work on mobile devices [10]. In fact, there are free AR applications available for Android, Symbian and ios, e.g. Layar 2. However, an AR solution requires the user to install an application. And once again, according to requirement 5, this is undesirable. It would require the system to be ported to multiple mobile platforms. In addition, many devices might not be fast enough to smoothly render augmented reality images. A common way of navigating people is displayed by GPS navigation devices used in cars. In such a solution, maps are drawn with lines that show the suggested route. Online route planning services (like Google Maps) have brought this technique to browsers. Going by the web-based approach suggested in requirement 3, we could use this technology. Google has a JavaScript API available for rendering maps in browsers. Most mobile browsers can run JavaScript code, so this does not conflict with requirement The system should be available to a large number of users Our system should not place strict requirements on the user s device. Smartphones and tablets are the most generic portable devices that can be used for our purposes. The only alternative would be to use desktop machines, but these are hard to use when navigating through the building. We have opted to use mobile devices instead. Most, if not all, mobile devices have browsers. As long as those browsers comply with HTML and JavaScript, they should be able to view our system. 6. The required amount of user-machine interactions before results are obtained should be minimal The system we have made is just a quick tool. Each additional action the user has to perform, forms a barrier between learning of the system s existence and being able to use it. Having to install applications is one such action and, unless absolutely necessary, this must be avoided. In order to satisfy requirement 3, we do need at least one application to be installed on the user s device: an application to scan QR codes. The web-based approach suggested in item 3 would satisfy this requirement. The only thing that needs to be done for users is scan the tag and they will be directed to the website

10 The second part of this requirement is in the user interface. It should not be cumbersome and require more user interaction than strictly necessary. Having results within one or two mouse clicks is very efficient and makes for an overall pleasant experience. 2.3 Architecture Overview In this section, we will describe the full architecture of our system. There are four major components: our web server, the LDAP server, mobile devices and data structures on local storage. This is shown in Figure 1. Figure 1: Architecture diagram. Our code is to run on a single server. This server (for now, at least) is located at mangkus.science.uva.nl. Note that this is within the UvA s domain. Recall that this is required in order to access the LDAP server, which is located at omni.science.uva.nl. The web server sends queries to the LDAP server, which responds with any results it may find. Users with mobile devices can scan QR codes with any application specific to their device s platform. This application will then decode the QR code into a URL, which can then be manually or automatically passed to the device s web browser. This web browser then sends HTTP requests to our server, to which the server will respond by sending HTML pages. Additionally, there are JavaScript calls that aid in this communication. Finally there is the server s local storage. Our data structures required for pathfinding are stored here. These are accessible only by the server. This data is stored in HTML image maps. 10

11 3 Implementation 3.1 Building the HTML Image Maps We have edited the HTML maps using GIMP; the GNU Image Manipulation Program. GIMP has support for editing image maps. However, before maps can be created or altered, there must first be an image on which to base the map. For this purpose, we have contacted the FNWI building manager to get PDF 3 files of the floor plans (one for each floor). In order to use these PDF files for creating image maps, we have exported them as PNG 4 images. These floor plans are very cluttered. There is a lot of information on there that we do not need and the users do not need. That makes for a difficult time trying to identify hallways, offices and other points of interest. Figure 2: Second floor of FNWI C. The image map editing screen is found in GIMP under Filters - Web - Image Map... An image has to be loaded into main GIMP screen before the Image Map... button becomes available. With images as large as the ones we have used, it may take a few minutes for the image map editing screen to come up. Once it has loaded, a new image map can either be created, or an existing one can be loaded. In the GIMP version we have used, it was not possible to zoom out in the editing screen. This also frustrated a clear view of which part of the floor plan was shown. 3 Portable Document Format 4 Portable Network Graphics 11

12 Figure 3: GIMP Image Map editor. In the editing screen, we find three basic shapes we can place over the image. The first is a rectangle, the second a circle and the third a polygon. Any of these shapes require drawing of the shape, after which a screen pops up where a string can be added to the entry. This string is coded as the HTML field href. There is more data that can be added, but we only used the URL field. GIMP can also enable a grid which shapes can snap to. We used this for creating waypoints throughout the hallway. 3.2 Structure of HTML Image Maps The base of our project are the HTML maps of the building. When it was initially presented to us, it contained all the rooms on the top three floors of the C building. Below an example of how offices are represented in HTML maps: <area shape="poly" coords="796,3264,796,3447,837,3447,837,3376, 1084,3376,1084,3264" href="c2.140a" /> <area shape="rect" coords="796,2886,1084,3066" href="c2.136" /> <area shape="rect" coords="796,2698,1084,2879" href="c2.134" /> <area shape="rect" coords="796,2511,1084,2691" href="c2.132" /> Here, the field shape indicates how the string in the coords field should be interpreted. The value "rect" tells us the coordinates represent two opposing corners as (x1, y1), (x2, y2) and the value "poly" tells us the coordinates are a list of all vertices in the polygon shape: x1, y1, x2, y2,... The numbers in the coordinate fields are pixel coordinates that correspond with the pixels of 12

13 the image the map was based on. Finally, the href field gives meaning to the described area. All points of interest are stored in this manner. In order to be able to use the map for pathfinding, we had to add information that told us where people can walk, how they traverse floors and how a certain walk able area can be reached through other walk able areas. We have mapped all hallways of the building in a graph by placing a small rectangle on all of the junctions. A junction is defined as a place where two or more straight hallways meet, where a hallway makes a turn and at the end of a hallway. These junctions were given unique names. The entire href string for each junction was then updated to include a reference to its neighbouring junctions. There are currently three different kinds of graph nodes. There is the junction, the staircase and the elevator. Below is an example of how this looks: <".." href="junction2.1:junction2.2,junction2.16" /> <".." href="junction2.2:junction2.1,junction2.3,junction2.4" /> <".." href="junction2.3:junction2.2,staircase2.1" /> <".." href="junction2.4:junction2.2,junction2.5,junction2.17" /> <".." href="junction2.5:junction2.4,junction2.6,staircase2.2" /> <".." href="junction2.6:junction2.5,junction2.7,elevator2.1" /> <".." href="junction2.7:junction2.6,junction2.8,junction2.9" /> The format here is: identifier:reference 1,reference n. A single identifier consists of an object name(junction, elevator) and two values separated by a dot. The first value indicates on which floor the object is located and the second value makes the object unique on that floor. This example brings us to something else; floor traversing. As you can see junction2.3 and junction2.5 refer to an identifier that starts with staircase. At the top and bottom of each flight of stairs, a rectangle akin to the ones used for junctions, was placed. These staircase rectangles are also included in the graph. Each staircase refers to the junctions it directly neighbours and the other staircase identifiers reachable directly through that particular staircase. That means staircase2.1 will only refer to staircase1.1 and staircase3.1, but not staircase4.1. Finally in the graph, there is the elevator identifier. Like the staircases, an elevator, as part of the graph, will reference junctions it directly neighbours. The difference between staircases is that elevators will refer to all floors that can be reached with that elevator. elevator2.1 will also refer to elevator4.1. This is to provide some flexibility for future development (see section 5). The last type of element in the maps are destinations of which multiple exist. For instance, restroom. There are multiple restrooms in the building and it would be difficult to give all these restrooms unique identifiers. The user would not be able to tell the website to which restroom he wants to go, so having uniquely defined restrooms would be pointless. Through the process of adding areas to the HTML image maps, we have ended up with the interest points shown in Table 2. 13

14 Nodes Points of interest Type # Type # Junctions 76 Offices 506 Elevator 8 AED 5 Staircase 53 Fire alarms 39 Restrooms 20 Evacuation chairs 5 Reception 1 Table 2: Summary of objects stored in the HTML maps. 3.3 Parsing the Data Parsing is done with a regular expression that searches for the coordinate and the href fields in the HTML map file. The data is stored in two separate Python 5 dictionaries. One dictionary contains a list of coordinates for each unique identifier in the file. These coordinates are stored in a tuple. In the case of the restroom identifier, for each additional occurrence, another set of coordinates is added to this list. For identifiers that only appear once, like junctions, the list of coordinates will have length 1, with just a single tuple of numbers. Coordinates are not directly stored in tuples, however. The system does not need to know the size or shape of the areas, yet the HTML map contains multiple (x, y) coordinates for a single shape. In case of a rectangle there will be two (x, y) pairs, each of opposing corners. In case of a polygon, every vertex will be represented by a pair of (x, y). Before the coordinates from the HTML map file are stored in tuples, all the x coordinates are averaged and all the y coordinates are averaged. Now every shape on the map is represented by a single coordinate. This may mean this coordinate does not actually lie within the specified area, but because of the way we map interest points to the graph (section 3.4), this is merely an aesthetics problem. We now have a coordinate dictionary and a graph dictionary for each floor of the building. For graph searching purposes, we have combined these dictionaries across the floors in order to represent the entire building in just two dictionaries. Since the HTML image map files only contain two-dimensional coordinates, we have to manually assign a third dimension when combining the data structures. This third dimension was arbitrarily chosen as f loor Since we are searching for the shortest path and the separate floors are all in two dimensions, the choice for this value will not influence the outcome. The resulting dictionaries look like this: The coordinate dictionary: {... "elevator0.1": [(4965, 2565, 0)], "C3.239": [(9616, 3066, 3000)],

15 "C3.238": [(9814, 3132, 3000)], "AED": [(5235, 2355, 0), (5235, 2325, 1000), (5235, 2325, 2000), (5235, 2325, 3000), (5235, 2325, 4000)], "C2.159a": [(3779, 3570, 2000)], "C3.230": [(9040, 3574, 3000)],...} And the graph dictionary: {... "junction1.8": ("junction1.7", "junction1.9"), "junction1.9": ("junction1.6", "junction1.8", "junction1.10"), "junction1.1": ("junction1.2", "staircase1.2", "staircase1.3"), "junction1.2": ("junction1.1", "junction1.3"), "junction1.3": ("junction1.2", "junction1.4"), "junction1.4": ("junction1.3", "junction1.5"),...} 3.4 Mapping Locations to the Graph Before we can start computing a route between two locations, we first need to know their relation to the graph. We currently only have a single threedimensional coordinate for each point of interest. We know where junctions are and how to get from junction to junction. But we also have to find out where we enter the graph and where we get off again. We do not have data stored that tell us for each interest point where they insert into the graph. There are hallways (or otherwise traversable areas) between junctions. If the HTML maps were built correctly, every point of interest can be reached through one of these hallways. A correct map assumes that each interest point is adjacent to a hallway. If there are ambiguities, like multiple hallways adjacent to an interest point, they are to be resolved in the image map by placing additional nodes. In order to determine entry and exit points in the graph, we have to find the hallway closest to our particular point of interest. We can represent hallways as line segments and interest points as single points. Now the distance between a point and a line can be computed. The shortest distance between a line and a point can be found by finding a line that intersects both the point and the line segment and is perpendicular to the line segment. # Return point on line ((x1,y1), (x2,y2)) that is closest # to point (x0,y0). def posonline((x0, y0), (x1, y1), (x2, y2)): m = linelength((x1, y1), (x2, y2)) u = (((x0 - x1) * (x2 - x1)) + ((y0 - y1) * (y2 - y1))) / (m ** 2) 15

16 # Shortest distance not within bounds. if u < 0 or u > 1: return None x3 = int(x1 + u * (x2 - x1)) y3 = int(y1 + u * (y2 - y1)) return x3, y3 We can now perform this calculation for each line segment there is (could be optimized if necessary) and compare distances to find the closest one, and with that, the closest hallway to our point of interest. Not every point of interest will be directly adjacent to a hallway. Corner offices may just miss the hallway in this calculation. In order to avoid this, the closest hallway is also compared with the closest junction node. If there is one junction closer to our point than the closest hallway, the junction is selected as entry or exit node in the graph. Because a hallway consists of two graph nodes, we can now add insert and exit nodes in our graph dictionary. We do this, by simply adding a start and goal field to both dictionaries. For the coordinate dictionary, we use the coordinates given as (x3, y3) in the previous code segment. The graph dictionary requires references to neighbouring junctions to be added to the entries for start and goal. These neighbouring junctions are the two endpoints of the hallway. In addition, these neighbouring nodes also need references to start and goal. With this step complete, we can now use a graph searching algorithm to find paths through the building. 3.5 Finding the Shortest Path The A* search algorithm is guaranteed to find the shortest path in any graph [11]. Our graph is three-dimensional, but this does not matter for A*. A* is only concerned with node neighbours and some kind of heuristic to estimate distance to the destination node. The algorithm tries to find a shortest path between two nodes in a graph. It can end up searching the entire graph, but it tries to minimize the number of nodes actually searched. It does so by only visiting nodes that seem most promising. Whether a node looks promising is determined by travelled distance at that point and the estimated distance to the goal node. There are two sets: one closed set and one open set. The open set contains nodes that have not yet been visited and the closed set contains nodes that have already been visited once. If a node has been visited once, it will never have to be visited again within a different path, because, due to the nature of the A* algorithm, the first time a node will be visited, is the shortest path between that node and the start node. The algorithm will iterate over the graph, and will visit each node at most once. Each step, the algorithm will select one node from the open set that 16

17 looks the most promising. Let us call this node node o. This node o is selected by using two scores. One score is the travelled distance between the start node and node o (which is also the shortest path that exists between those two nodes). The other score is a heuristic function. This function, in our case, is the linear distance between node o and the goal node. That is, three-dimensional Pythagoras between both nodes coordinates. Now, the heuristic must be an admissible heuristic. That means that no path may exist that is shorter than the heuristic suggests. Otherwise, A* is not guaranteed to find the shortest path. The heuristic function is usually called h(x) and the travelled distance function is called g(x). The total score of a node is f(x) = g(x) + h(x). Our node, node o, has the lowest value for f(x). Figure 4: Example of A* execution. 6 Every iteration, the most promising node is selected until finally, the goal node has been found. Now, the coordinates of the goal node are not always unambiguous. Recall that there were some interest points that have multiple occurrences, e.g. the restrooms. We have a list of coordinates for each separate restroom, but we do not know which is closest to the start position in terms of walking distance. We can not use Pythagoras to select a single restroom to navigate to, because that method fails to take the graph into consideration. Instead, routes are computed 6 Source: by user Naugtur. 17

18 to all instances of the interest point. Since we now know the actual distances between start and destination locations, we can select the closest instance for navigation. 3.6 Finding Employee s Offices We get our data on employees and their offices from an LDAP server. LDAP stands for Lightweight Directory Access Protocol. We have used a Python module called python-ldap for communicating with the server. This module provides several basic methods for connecting to the server and searching for data in the server. Figure 5: LDAP directory structure. Below is an example of connecting to the server and searching directory entries. Searching is done within the LDAP BASE DN (Distinguished Name) subtree. The parameters in this constant all have some meaning. dc is Domain Component, ou is Organizational Unit. LDAP_URI = "ldap://omni.science.uva.nl" LDAP_DN = "dc=science,dc=uva,dc=nl" LDAP_PW = "" LDAP_BASE_DN = "ou=people,dc=science,dc=uva,dc=nl" The query parameter contains a cn, or Common Name field. This is the field we want when we are looking for employee names. It is searched as "(cn=*%s*)". This is a simple regular expression pattern, where the %s part is substituted by the string in the variable name. The attrs parameter contains a list of data we want to receive from the LDAP server in entries that match our query. 18

19 l = ldap.initialize(ldap_uri) l.protocol_version = ldap.version3 l.simple_bind_s(ldap_dn, LDAP_PW) query = "(cn=*%s*)" % name attrs = ["givenname", "sn", "telephonenumber", "roomnumber",..] res = l.search_s(ldap_base_dn, ldap.scope_subtree, query, attrs) After results have been stored in our res variable, we can browse through it to extract the data we want. Every line in res consists of a dn and a dictionary of items, item. The keys of this dictionary match with the strings we previously passed in the attrs parameter. for dn, item in res: name = "%s %s" % (item.get("givenname", ""), item["sn"]) people.append((item["uid"], name)) In much the same way, we can extract data with the key roomnumber as well, which contains the employee s room number. 3.7 Website Set-up Everything discussed above is put together in a website built with the Django web framework for Python 7. Django defines apps which are easily pluggable. This allows you to import apps from other projects with relative little effort. It also helps developers to structure their code (although they could still avoid the apps concept if they wish). Basic apps have a file that interacts with the database and a file that handles views. Further, there will be some folder on the file system that contains templates from HTML files to be sent to a browser. This describes a model-view-controller set-up (although the Django developers prefers model-template-view). The database is accessed by the file commonly called models.py, our model layer. Our controller (what Django calls view) is commonly called views.py. These are found within an app s own folder. The HTML templates are found in some other folder (the Django settings file knows where). This can be any folder accessible to the server. Django matches URLs with patterns it has stored somewhere. A pattern match will result in a call of some method in a views file. Methods in the models file will be called and templates will be rendered from the views file. Templates are HTML files that will alter themselves depending on what data they receive from the views layer. They can contain simple for loops and conditional statements. The views layer can pass a context, which is a dictionary. This context can be accessed from within templates by putting double curly

20 braces like so: {{ contextkey }}. If the value for that key is some kind of object, its variables can be accessed with dotted syntax: {{ person.name }}. Lists can also be accessed this way: {{ somelist.1 }}. We have three apps. One for the main interface, one for looking up LDAP data and one for route related code. These apps are shown in Figure 6. Figure 6: Apps shown in architecture overview. The main app builds a simple interface that allows users to quickly select a destination. Start locations can easily be passed to the website with a GET parameter. This functionality is used with QR codes to directly have a starting position available to the user (see section 3.8). This start location can also be entered manually if necessary. Otherwise, users can navigate to most destinations with a single click. There are currently two destinations that require additional information from the user. That is, for the employee lookup and for a manually entered office number. The LDAP app is used for searching for employees. The user first enters a string to be matched with the LDAP server s employee names. Our website then displays the list of matches. Users can select one of these matches, and if that employee has an office number registered in the LDAP server, the user is redirected to the navigating part of the website with that specific office set as the destination. Finally, the pathfinding app handles start and destination parameters to compute a route based on algorithms described above. This route is then displayed in a Google Maps window, which is what we will describe next. This app returns both a list of junctions and a list of coordinates. This is then used to draw a line on the map rendered with the Google Maps API. 20

21 3.8 Determining the User s Location We have used QR codes to allow users to easily access the website. These codes have been given additional functionality than what is typical. In most cases, QR tags only contain hyperlinks or other static information. By assigning a position in the URL, the QR codes have become more dynamic. By scanning one of the tags placed on a wall, the user can instantly start navigating to any destination of their choice. Figure 7: QR code linking to the website with the reception set as the starting location. The start parameter is currently encoded as a GET field start, for example: The value for this field can be any object stored in the HTML image maps. Additionally, the same could be done for destinations. This is currently not used, but it would not be difficult to implement it. If both start and destination can be encoded in a QR code, specific codes can be made for special events in the building. People could be given codes to find out where they are expected. The destination the user selects is stored in a cookie. That way, if a user scans another QR tag, they can continue navigating to the same destination from the newly acquired start position. This piece of functionality can come in handy when a user manages to stray off course despite our wonderful system (maybe some people just cannot read maps). 21

22 3.9 Visualizing the Route The Google Maps API 8 allows us to render custom maps in the famous Google Maps interface we all know 9. Google Maps works with latitude and longitude as coordinate systems. Latitude ranges from 90 to +90 and longitude ranges from 0 to 360. In 2D, we would say latitude is our y coordinate and longitude our x coordinate. Google uses this system to unambiguously reference a point on the world. This is because the map size changes when the zoom level is adjusted. If the view zooms out, the map becomes smaller, therefore regular coordinates cannot be used to indicate a single location on the world. Furthermore, there are tile coordinates. The map is rendered in parts. This is especially important for large maps, to prevent excessive data to be sent. These parts are made by tiling the image you want rendered. The tiles we used have a dimension of 256 x 256 pixels. The tiles are numbered like pixels would be on a computer screen. That is, (x, y) with (0, 0) in the top left corner. There is a set of tiles to be used for each zoom level. This is to show different data at different zoom levels (streets are not visible at the highest zoom level) and to prevent that the user s browser has to do any scaling. The tiles are stored statically on the server and they have been assigned names that can be used to determine where the tile should be placed. Our naming convention is /floor/zoom.x.y.png 10. There are multiple floors in our building, so we have a folder that contains a set of tiles for each floor. Then there are tiles for each zoom level and for each (x, y) coordinate. The path users should follow is indicated as a red line. The list of coordinates received as a context from the path app view layer, is filtered to only contain coordinates on the current floor. These coordinates are then drawn as a polyline. A polyline is a line that consists of multiple vertices, each connected with a line to the next vertex Image tiler was made by Fajran Iman Rusadi. 22

23 Figure 8: Screenshot of our Google Maps interface on an Android phone. We can only render one floor at a time using Google Maps. But in order to guide people throughout the building, we need to be able to render all floors. We have placed buttons below the main map screen that allow users to go up and down a floor to follow the path indicated on the screen. 4 Benchmarks We have performed some benchmarks to verify that our system is efficient enough to allow for a good user experience. Waiting times should be minimal as not to frustrate this. All benchmarks were performed on the machine where the website is currently active; mangkus.science.uva.nl. 4.1 LDAP Server The LDAP server was benchmarked to ensure it is fast enough for direct querying from our website Sequential testing Several tests were performed. In the first, the string "xxx" was queried 100 times. This produced the following result: 100 triples were searched in seconds. A total of 0 records were found. 23

24 There were no names that matched this string. The average time for each query is roughly seconds. It could be a little faster, but it is certainly usable. The next test uses a random pattern to query the LDAP server. This pattern is a random strings of length 3 following the pattern consonant, vowel, consonant. This pattern is very common in words and is therefore likely to partially match with employee names in the server. 100 triples were searched in seconds. A total of 1823 records were found. In this case, there were 1823 names in total that matched the random strings. The total time it took is similar to the first test, producing an average time of seconds per query. Clearly, the amount of data transferred does not have a huge impact on performance. It also tells us any caching the LDAP server might do most likely did not influence the first test significantly. Searching repeatedly for the same string could have resulted in faster response times due to caching, but there is no significant time difference between the two tests. Repeating the test with more queries produces the following results: 200 triples were searched in seconds. A total of 3820 records were found. 300 triples were searched in seconds. A total of 4594 records were found. The time increases here are as expected. With each additional query, the total execution time is roughly extended by the time we previously estimated as the average single query time; seconds Parallel testing In sequential testing, only one query will be performed at a time. This skews view of the LDAP server s capabilities. In order to benchmark the LDAP server s scalability, we have expanded on this test by sending 100 queries from up to six different machines simultaneously. That means that each machine executed the benchmark described above with the random strings. Averages: 1 machine: 100 triples were searched in seconds. 2 machines: 100 triples were searched in seconds. 24

25 3 machines: 100 triples were searched in seconds. 4 machines: 100 triples were searched in seconds. 5 machines: 100 triples were searched in seconds. 6 machines: 100 triples were searched in seconds. The time it takes for six separate machines to receive 100 LDAP responses each, is clearly significantly higher than when just one machine sends 100 queries. However, search time is lower than what would be expected from a sequential querying. Whether this is because the server can handle multiple queries at the same time or a reduction of network overhead is not clear at this moment. This benchmark does suggest the LDAP server would perform better if queries are sent in parallel to each other. This would require our web server to handle HTTP requests in parallel as well. The currently used server is the development server that comes with Django. Unfortunately, this server is not multithreaded and therefore will not handle multiple requests simultaneously. 4.2 Pathfinding By far the most complicated and CPU intensive part of the system is in the pathfinding. It is important that this happens efficiently. Path lengths are the number of nodes the path consists of, including the start and goal nodes. For this benchmark, 1000 random pairs of interest points were generated. Points with multiple coordinates assigned to them (e.g. exits, AEDs) are omitted from random selection. This is because multiple routes are computed for these kind of goals. Including those would make the test results difficult to interpret. After the 1000 random paths are computed, paths are computed of which the length of the shortest path is known. This is necessary to determine how performance is affected by path length random shortest paths were computed Average path length is: Total time for 1000 paths is: seconds --- Computing 1000 random paths of length 2 takes seconds Computing 1000 random paths of length 3 takes seconds Computing 1000 random paths of length 4 takes seconds Computing 1000 random paths of length 5 takes seconds Computing 1000 random paths of length 6 takes seconds 25

26 Computing 1000 random paths of length 7 takes seconds Computing 1000 random paths of length 8 takes seconds Computing 1000 random paths of length 9 takes seconds Computing 1000 random paths of length 10 takes seconds Computing 1000 random paths of length 11 takes seconds Computing 1000 random paths of length 12 takes seconds Computing 1000 random paths of length 13 takes seconds Computing 1000 random paths of length 14 takes seconds Computing 1000 random paths of length 15 takes seconds Computing 1000 random paths of length 16 takes seconds Computing 1000 random paths of length 17 takes seconds The average time to compute a single random path is only seconds. This is plenty fast for our system. In most cases, only one route has to be computed to help a single user. The second part of this benchmark shows that execution time increases as a larger part of the graph has to be searched. But, even at path lengths of 17 nodes, execution time per path is still only seconds. 4.3 Web Server There is one more component that may consume a significant amount of time. The web server itself. This set of tests may be the most accurate estimate of retrieval time for the user. Keep in mind that these tests are all performed with the Django development server. This server is not suited for deployment. Deployment to a large user base should be done with software like the Apache HTTP Server 11. During testing, we experienced multiple errors where the connections had timed out. The frequency of these errors increased as tests increased in retrieval time. This first test simply retrieves the index page of our website several times. Retrieving the index page 100 times takes seconds. Retrieving the index page 200 times takes seconds. The average time per page lies around 0.12 seconds. We have tried to increase the number of retrievals to 300 times, but the server would fail every time. The next test activates the pathfinding part of the website. In the same way as described in section 4.2, two random locations are selected for which a shortest path will be computed. The website is requested with two parameters for start and goal. Retrieving 100 random paths takes seconds. Retrieving 200 random paths takes seconds

27 The thing that s most notable is that the total time it takes for 100 random paths to be computed and the HTML content including JavaScript code to be returned, is actually lower than just loading the index page. The suspected reason for this is the use of a loop in the index page s HTML template file, but we have not further tested this, because no form of caching is used at the moment. Caching would likely significantly reduce loading times of the index page. Other than that, this test gives no strange results. As the number of random paths increase, retrieval time also increases. This last test only resulted in an HTML page containing some JavaScript code to be returned. On browsers, however, the JavaScript code is also executed. The Google Maps API will try to retrieve the tiles stored on the server. This is something we can simulate. Retrieving 100 tiles takes seconds. Retrieving 200 tiles takes seconds. Tiles are 256 x 256 pixels. We estimate that on average four tiles will be loaded at a time on smartphones. The average time it takes for four tiles to load is 0.18 seconds. But again, we could not retrieve more than 200 tiles as the server would fail. 5 Discussion There are several things that could be improved in the future and some things that could have gone differently. First of all, if this system turns out to be successful, it could be expanded with the other buildings at Science Park to include classrooms, laboratories and other points of interest people might find useful. And with the inclusion of classrooms comes the option to have the system retrieve data from the timetables so students can enter their student identification number and then automatically be guided to their lecture. The timetables are also interesting when searching for employees that are also teachers. If the teachers are giving a lecture, the system can present the option to navigate to the classroom, instead of their office or use that information some other way. Another problem that is currently unsolved is what to do with incorrect and missing data in the LDAP server. A solution would be to set up a database that could correct data, but in order for that to work, there must be some mechanism for quality control to ensure the database does not end up containing corrupt data. Building HTML image maps is currently fairly time consuming. Especially constructing the graph is prone to errors and therefore takes a lot of time to do correctly. It might be easier and faster to draw out shapes over hallways and write a script to combine and interpret those as a graph. This approaches a pathfinding situation similar to cases one might find in robotics. 27