Location-Aware Information Retrieval for Mobile Computing

Location-Aware Information Retrieval for Mobile Computing 1

1

2

Jiannong Cao , Kwok Ming Chan , Geofffrey Yu-Kai Shea , and Minyi Guo

3

1 Internet and Mobile Computing Lab, Department of Computing Hong Kong PolyTechnic University, Hung Hom, Kowloon, Hong Kong 2 Department of Land Survey and Geo-informatic, Hong Kong Polytechnic University Hung Hom, Kowloon, Hong Kong 3 Department of Computer Software, University of Aizu Aizu-Wakamatsu City, Fukushima 965-8580, Japan

Abstract. With the knowledge about their locations, mobile users are able to issue location-dependent queries. Most of existing approaches focus on how to obtain the information about objects within a certain distance to the location of the mobile user. In this paper, we describe techniques for location aware information retrieval to answer more specific queries about surrounding objects such as which room is on my left, right, up and down. We developed a system with applications in building and construction, where the objects of our interests are rooms. The data model for representing building-related spatial data and the query algorithms for the location aware information retrieval are proposed. The implementation of a prototype of the system is described.

1 Introduction Nowadays, various technologies are available to estimate the location of users carrying mobile devices. It is desirable for mobile users to request and receive data related to their locations. Location dependent queries imply that information asked is related to a location which may not be explicitly specified. In order to provide the answer to the query, first we have to know the location of the user issuing the query. The query can then be bound to this location. The information about the user’s mobility and the absolute and relative physical positions of real-world objects allow applications to customize their functionality to satisfy users’ requirements for various purposes [1, 2]. Most of the existing works on location aware queries are dealing with the closest objects or the objects that are within certain distance away from the user. In this paper, we describe techniques for location aware information retrieval to answer more specific queries about surrounding objects such as which room is on my left, right, up and down. We developed a system with applications in buildings where the objects we are interested in are the rooms. In building and construction applications, people involved in several projects always need to travel between sites. Usually, they have to bring along all the information about these sites. To be more convenient, portable computing devices such as PDA or notebook can be used to store data, but still, their information may not be the latest. Thus, it is useful if the user could obtain the most up-to-date data through the use of wireless connection and portable computing deL.T. Yang et al. (Eds.): EUC 2004, LNCS 3207, pp. 450–459, 2004. © Springer-Verlag Berlin Heidelberg 2004

Location-Aware Information Retrieval for Mobile Computing

451

vices. In this case, rather than just providing information to the user, we could enhance the service by providing location aware features. Depending on the location of the user, queries related to user’s current location will be interpreted and then the result data will be transferred back to the user. The paper is focused on indoor situation with the assumption that the user’s location and orientation are known. We propose techniques for storing and retrieving information to support location aware query. A system is developed where the Location Information Server is responsible for processing user’s queries and then sending the result back to the client. The client side software will render the result and display it on screen so that the user will be able to view the result as well as save it. The data model is used to store data in the spatial database. When it works with the location aware information retrieval algorithm implemented in the Location Information Server, the relationship information between stored items can be constructed and the location aware query can be answered. The client communicates with the server application through wireless connections. The rest of the paper is organized as follows. Section 2 describes the data model. Section 3 presents the algorithms for supporting location aware information retrieval. In section 4, we describe the system architecture and the issues of implementing a prototype system. The testing and evaluation results are also reported. Finally, section 5 concludes this paper.

2 Data Model The data model for storing the geographical data is essential for designing the location aware retrieval algorithm. A geographic object has two components, a description and a spatial component which corresponds to the shape and location of the object in the embedding space. In order to distinguish an object from others, an explicit identity is assigned to it. The entire set (identity, spatial object, and common description) constitutes a geographic object, also called an entity or feature. This is the basis of entitybased models. There is another model called field-based model, where space is considered as a continuous field and each point in space is associated one or several attribute values [11]. One of the practical implementation of geometric information to overcome the representation of infinite point sets of the Euclidean space in a computer is Vector mode. In Vector model, objects are constructed from points and edges as primitives. A point is represented by its pair of coordinates, whereas more complex linear and surface objects are represented by structures (lists, sets, arrays) on the point representation. In contrast to a raster representation, a vector representation is not eager in memory. In particular, a polygon is represented by the finite set of its vertices. Another model is called tessellation mode which represent geographical information by approximating the continuous space by a discrete one. Spaghetti, network, and topological models are three commonly used representations of collections of spatial objects [11]. In the Spaghetti model, the geometry of any object is described independently of other objects. No topology is stored in such a model, and all topological relationships must be computed on demand. The advantage of this approach is its simplicity. In addition, because all objects are stored independently, it provides the end user with easy input of new objects into the collection. In the

452

J. Cao et al.

network model, topological relationships among points and polylines are stored. Also, concept of node and arc are necessary in this model. A node is a distinguished point that connects a list of arcs. An arc is a polyline that starts at a node and ends at a node. There are two types of points, namely regular points and nodes. A node is either an arc endpoint or an isolated point in the plane. Other line and polygon vertices are regular points. The topological model is similar to the network model. Node is also represented by a point and the list of arcs starting (or ending) at this node. For arcs, besides ending points and list of its vertices, the two polygons that use the arc as common boundary are also recorded. A polygon is represented by a list of arcs, each arc being shared with a neighbor polygon. The data model used in our system is an entity-based model and uses vector-based representation. Polygons (e.g. room) are the objects that we need to deal with. As described above, a polygon can be represented by either a list of points or a list of arcs. The arc list representation (as used in the topological model) stores the information of the arcs constructing the polygon as well as the topology information along the arcs. This method provides an ease of access to the topology information of the arc or polygon, but it is more difficult to change the information. In the point list representation of a polygon, each point is represented by x and y coordinates. This method is simpler in nature and flexible as no topology information is stored, although it implies that a more complicated algorithm is needed in other to discover the relationships between polygons. We choose to use this later method to represent a polygon. As shown in Figure 1, the turning points of each polygon are stored. The x and y coordinates are stored for each point. The data for the above example polygon are stored as shown in Table 1. The points of the polygon are stored in clockwise order.

1

2 Fig. 1. (1) Data Model Sample (Single Room), (2) Data Model Sample (Rooms)

Table 1. Sample data stored Polygon

Points

Room

(x1,y1),(x2,y2),(x3,y3),(x4,y4)

Office

(x5,y5),(x6,y6),(x7,y7),(x8,y8),(x9,y9)

Store Room

(x9,y9),(x8,y8),(x10,y10),(x11,y11)

Location-Aware Information Retrieval for Mobile Computing

453

3 Algorithms for Location-Aware Query Processing Based on the data model, an algorithm for processing location aware queries has been proposed. Since we focus on location-aware information retrieval, we assume that the location of the user is known, which can be obtained by either letting the user to enter it as input or by using different mobile positioning technologies, such as GPS [3, 4], wireless LAN [5, 6], and sensors using RF and ultrasound technologies [7]. For our algorithm to work, the orientation of the user (e.g. which direction the user is facing) is also important. The detection of user’s orientation is difficult and is an active area of research. Thus, we assume that the user’s orientation is received together with other query information (e.g. input by the user), and it is in compass reading. We assume that the North-South is on the y-axis of the coordinate system with North pointing to the increasing direction of y coordinate. In Figure 2-1, we divide user’s orientation into four zones and assume that the user is standing at the interception point of x and y axis (0, 0). If the user is facing zone 1 (e.g. North), then the left side of the user would mean that the x coordinate of the item is smaller than the user’s current location, while the right side of the user would mean that the x coordinate of the item is greater than the user’s current location.

1

2 Fig. 2. (1) User’s Orientation Zone, (2) Compass reading

Suppose user’s current location was (userX, userY) and the coordinate of the result item of the query was (itemX, itemY). Then, the respective zone can be identified. For o o example, the range of Zone 1 would be < 45 or > 315 as shown in Figure 2-2b. Thus, when we obtain the orientation, it is possible to resolve the orientation and zone, and therefore generate useful information for processing the query (see Table 2). Table 2. User’s orientation rules Facing Zone

Left

Right

Front

Back

1

itemX < userX

itemX > userX

itemY < userY

itemY > userY

2

itemY > userY

itemY < userY

itemX > userX

itemX < userX

3 4

itemX > userX itemY < userY

itemX < userX itemY > userY

itemY > userY itemX < userX

itemY < userY itemX > userX

454

J. Cao et al.

With the user’s location and orientation and the information about the building in question, the location dependent information can be retrieved on user’s demand. The algorithm used to retrieve the information about the Left, Right, Front and Back sides is separated from that for Up and Down, because the data model is mainly for two dimensions. The Up and Down search is handled by using other information such as the floor. Algorithm 1 1. 2. 3. 4. 5.

Obtain information related to user’s query, e.g. user’s location (x and y coordinates, floor and building), user’s orientation (a compass reading), direction of query (Left, Right, Font, Back) and amount of search (1,2…) Retrieve information (e.g. points that construct the polygon) about the polygon that the user is staying by the user’s location Generate the rules for the query (e.g. x coordinate > user’s x coordinate) by using the user’s orientation and direction of the query Select the information obtained from (2) that satisfies the rules generated in (3). E.g. points (shared properties) that do not violate the rule Calculate the distance (d) between the points (px, py) and the user (x1, y1) by using the following equation:

6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.

d = (x1 - px) 2 + (y1 - py) 2

Sort the points in ascending order of d Choose the nearest point Search for polygons that is constructed with the point selected in (7) Estimate the new location of the user with respect to the point selected in (7) with the rule obtained in (3) Search for the polygon that contains the new location Check if any polygon found in (8) is the same as that found in (10) If (11) is true, then the result from 10 is obtained and goes to (15) If none of the polygons in (8) is the same as in (10) and there is point in the list has not been tested, step (8) – (13) is repeated for the next nearest point Return “No result” Check if the amount of polygon search equals to 1 If (15) is true, stops and returns the result obtained from (10) If (15) is false, starts from step (1) again with new location from (9) and the amount of polygon search minus by 1 as parameters

Search for the Left, Right, Front and Back location information is based on the idea that the floor plan consists of numbers of polygons, representing rooms or corridors. These polygons are joined together, so they must have shared properties (e.g. point). The shared properties could be used as the key for finding the result of the query by applying certain rules. The rules are derived from the user’s location and orientation. Thus, the polygons that have properties shared with the polygon that the user is staying and satisfy the rules would be the result of the search. Further test could be applied on the result to check for the correctness. The reason for searching the shared properties is to ensure that the polygons are adjacent to each other. Algorithm 1 shows the steps for obtaining the information about Left, Right, Front, and Back locations. Users can send a batch query such as Left 2 and Front 2. Algorithm 2 shows the steps for obtaining the information about Up and Down. Users can

Location-Aware Information Retrieval for Mobile Computing

455

send a batch query such as Up 2 and Down 3, in which case the floor parameter is updated according to the amount that the user wants. Algorithm 2 1. 2. 3. 4. 5. 6. 7.

Obtain information related to the user’s query, e.g. user’s location (x and y coordinates, floor and building), direction of the query (Up, Down) and the amount of search (1,2…) Retrieve the information about floors in the building that the user is staying Search for the floor (up or down with the amount stated) that the user wants If no result is found in (3), the algorithm stops and return “no result” If result is found in (3), check if the user’s location is within the boundary of the result floor If the user is within the boundary, stops and returns the result found from (3) If the user is outside the boundary, stops and returns “no result”

4 System Architecture and Implementation A distributed system approach with client-server architecture is used for our locationaware information retrieval system. Based on the data model, the geographical information is stored in the backend spatial database management system. A middleware implements the business logic and is responsible for communicating with the client and processing the queries, including accessing the backend data store. It also works with a Web server to provide service for mobile client. The most basic function of the client application is to send the query to the server and when the result arrives, displays it on the screen. Thus, a graphical user interface is needed for getting user’s input as well as showing the result. Functions such as zoom in, zoom out and pan are also important for the user to see the result easily. Moreover, in order to reduce the network traffic for querying the same information all the time, the function for saving the current displaying map and opening the map that had been stored are also provided. The user is able to choose whether the query is location aware or not as well as the scope of result (e.g. floor, zone or single room). For the client application running on a mobile device such as a PDA or mobile phone, because the mobile device has limited computation power and support for software development, the application cannot not provide as many functions as in the laptop. The minimum requirement is to submit the query and display the result. One way is to work with a Web server. As in the laptop client, similar input value needs to be obtained from the user through a user interface but the screen size of mobile device is limited so it is not possible to have all the input in one screen or else the user has to scroll up and down to fill in different fields. Therefore, we separate the input fields in different screens. The query information is sent to the server which forwards it to the location aware information server (middleware). The Web server is also responsible of transferring the result from the middleware back to the mobile client. Spatial database management system is the most common approach for storing spatial data. A building consists of number of floors and each floor has a numbers of polygons representing rooms or corridors. Each building has a name to identify itself. Each floor also has a name or number as identity. The same situation is applied to the

456

J. Cao et al.

rooms or corridors. As our search is based on the points that construct each polygon, all the points of a polygon has to be stored. For room searching, the points of each room are required. For floor plan searching, the points that construct the outermost boundary of the floor are required. If we separate the floor into different zones in order to provide fast access to the information about a certain area, then the points that construct the zone are also required. It also meant that a floor has a number of zones. Moreover, there may be some items that are related to the room e.g. door, table or text, and these information also need to be stored. Sometime, when the information about a single room is not enough and the information about the whole floor is too much, the zone information enables the user to obtain information about certain area in the floor. A prototype of the location aware information retrieval system has been implemented using Java. PostgreSQL is used as the spatial database management system. It is an open source relational database with spatial features. JDBC drive is available for Java programs to access the information in PostgreSQL database. SVG (Scalable Vector Graphics), a language for describing two-dimensional graphics in XML, is used represent graphic information in a compact, portable form [12]. In our implementation, the SVG documents are generated dynamically based on the query result. The Location Information Server was implemented with a graphical user interface, as shown in Figure 3, and the user could change several settings (e.g. database connection information and port assigned for RMI) on demand. This enabled the server to access different database and use different port without recompiling the program. Java RMI is used for the communication between the client and Web server (Java servlet). The methods provided by the Location Aware Server are invoked by the client applications over the network through RMI. For client application running on a laptop computer, the GUI is depicted in Figure 4. On the right hand side, the message

Fig. 3. GUI for Location Aware Information Server

Location-Aware Information Retrieval for Mobile Computing

Fig. 4. User interface for Laptop client application

Fig. 5. User interface for mobile device client application

457

458

J. Cao et al.

area is at the bottom and the area on top of it is the JSVGCanvas [16] that displays SVG files or documents. Zoom including in, out and reset and pan functions are supported in the client application. The user can view the result in different ways by using the function buttons on the toolbar on the left hand side of the GUI, together with save, save as and open functions. The user can also input and select information for the query. If the user wants to obtain location aware information, then she needs to select the check box beside the title “Location Aware Query” and the information such as orientation, direction and amount should be filled in. The batch query model is supported and user can add several queries such as Left 1, Up 1 to the query area. If the check box had not been selected, when the user clicks the search button, it only returned the information (e.g. room, zone and floor) about the current user’s location. Client application for mobile devices is developed using J2ME. Figure 5 shows the user interface. The mobile client used HttpConnection to access and passes necessary information to the servlet. The servlet invokes the remote methods to obtain the result. The result in SVG document is transcoded to a PNG file, because J2ME only supports PNG image. The URL for the generated image is sent back to the client as a redirect link. The client then can obtain the image and display it on the mobile device.Tests have been performed to evaluate the correctness of the data model and the query processing algorithms. Different kinds of queries have been used for the tests and the results obtained showed that our system can provide the desired information.

5 Conclusions and Future Work A system to retrieve the location aware information depending on the user’s location and orientation is developed. Starting from the underlying data model, the system is built with data storage (Spatial Database Management System) schema, query processing algorithms, map graphics processing and font-end applications. The location aware information retrieval for the Left, Right, Font, Back, Up and Down relative to the user’s current is addressed. We believe the work presented here will be very useful for supporting location-based services, especially in the future when query-innatural-language features are available. There are several directions for our future work. Firstly, in this paper, as only a small amount of data is stored in the database, the performance is not a big issue. When the database size grows, it is necessary to have a scalable physical design such as indexing to improve the performance. Second, it is a good idea to implement the system to facilitate the path searching feature, so that the path found could be shown as a list of Left, Right, Up and Down. Finally, a location-aware query language can be developed so that the user can write more complicated queries with ease. Acknowledgement. This work is partially supported by the Hong Kong Polytechnic University under HK PolyU ICRG grant G-YD63.

Location-Aware Information Retrieval for Mobile Computing

459

References 1.

2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.

Seydim, Y. Dunham, M. H., & Kumar, V. (2001) Location dependent query processing. In Banerjee, S., Chrysanthis, P. & Pitoura, E., editors, Second ACM International Workshop on Data Engineering for Mobile and Wireless Access, MobiDE’01, pages 47–53, Santa Barbara, California, USA. Maass, H. (1998) Location-aware mobile applications based on directory services. ACM Baltzer Journal on Mobile Networks and Applications (MONET), 3:157-173. Peng, Z. R. (2003). Internet GIS: distributed geographic information services for the Internet and wireless networks. Hoboken, N.J.: Wiley. ESRI. . What Is GIS? Retrieved August 8, 2003 from http://www.gis.com/whatisgis/index.html Prasithsangaree, P., Krishnamurthy, P. & Chrysanthis, P. K. (2002) On Indoor Position Location With Wireless LANs , The 13th IEEE International Symposium on Personal, Indoor, and Mobile Radio Communications (PIMRC 2002), Lisbon, Portugal. Paramvir Bahl & Venkata N. Padmanabhan. (2000) RADAR: An In-Building RF-based User Location and Tracking System, IEEE Infocom 2000, volume 2, pages 775-784. Priyantha, N. B., Chakraborty, A. & Balakrishnan, H. (2000) “The Cricket LocationSupport system,” Proc. 6th ACM MOBICOM, pages 32-43, Boston, MA, U.S.A. Guting, R. H. (1994). An Introduction to Spatial Database Systems. VLDB, 3:357:399. Ravada, S. Spatial database services for location-aware applications. Retrieved September 26, 2003 from http://www.gisdevelopment.net/technology/lbs/techlbs004pf.htm Howes, T. A., Smith, M. C. & Good, G. S. (2003). Understanding and Deploying LDAP Directory Services. : Addison Wesley. Rigaux, P. (2002). Spatial database: with applications to GIS . San Francisco: Morgan Kaufmann Publishers. W3C. (2003). Scalable Vector Graphics (SVG) 1.1 Specification. Retrieved December 28, 2003 from http://www.w3.org/TR/2003/REC-SVG11-20030114/ Eisenberg, J. D. (2002). SVG Essentials. Sebastopol: O'Relly & Associates, Inc.. Eason, D. K. & Powell, G. L. (2001). Using middleware for GIS integration and factors for evaluating technologies. Retrieved September 8, 2003 from http://www.gisdevelopment.net/proceedings/gita/2001/system/techgi075.shtml Keogh, J. (2003). J2ME: The Complete Reference. Berkeley, California: McGrawHill/Osborne. The APACHE XML Project. Batik SVG Toolkit. Retrieved from http://xml.apache.org/batik/ Piroumian, V., & (2002). Wireless J2ME platform programming. Palo Alto, Calif.: Sun Microsystems.