A Foundation for Efficient Indoor Distance-AwareQuery Processing

Hua Lu1, Xin Cao2, Christian S. Jensen3

1Department of Computer Science, Aalborg University, Denmarkluhua@cs.aau.dk

2School of Computer Engineering, Nanyang Technological University, Singaporexcao1@e.ntu.edu.sg

3Department of Computer Science, Aarhus University, Denmarkcsj@cs.au.dk

Abstract—Indoor spaces accommodate large numbers of spa-tial objects, e.g., points of interest (POIs), and moving popu-lations. A variety of services, e.g., location-based services andsecurity control, are relevant to indoor spaces. Such services canbe improved substantially if they are capable of utilizing indoordistances. However, existing indoor space models do not accountwell for indoor distances.

To address this shortcoming, we propose a data manage-ment infrastructure that captures indoor distance and facilitatesdistance-aware query processing. In particular, we propose adistance-aware indoor space model that integrates indoor dis-tance seamlessly. To enable the use of the model as a founda-tion for query processing, we develop accompanying, efficientalgorithms that compute indoor distances for different indoorentities like doors as well as locations. We also propose anindexing framework that accommodates indoor distances thatare pre-computed using the proposed algorithms. On top of thisfoundation, we develop efficient algorithms for typical indoor,distance-aware queries. The results of an extensive experimentalevaluation demonstrate the efficacy of the proposals.

I. INTRODUCTION

People spend large amounts of their daily lives in indoorspaces such as office buildings, shopping centers, and trans-portation infrastructures, e.g., airports and metro stations. Avariety of technologies that use, e.g., Wi-Fi, Bluetooth, andRFID, enable positioning in indoor settings [3], [6]–[8]. Avariety of location-based services (LBSs) that use such posi-tioning are relevant to people in indoor spaces. For example, amuseum service can guide visitors through an interesting yetcomplex exhibition. As another example, a boarding reminderservice in an airport can remind air passengers, especiallythose far away from their gates, of their departures.

Such indoor LBSs will benefit from the availability ofaccurate indoor distances. Referring to the boarding reminderservice, a naive approach is to broadcast reminders to all pas-sengers that have checked in for a particular flight. However,this may well annoy those passengers already at the gate andin the process of boarding. It is attractive to target instead onlypassengers far from their boarding gates, and to appropriatelydirect them to their gates.

To achieve this, it is necessary to know the indoor distancefrom passengers’ current positions to their correspondingboarding gates. In the museum tour guide service example,

indoor distance awareness also offers tourist desirable conve-nience of shortest indoor walking paths.

Distances play an important role in a variety of indoorservice scenarios, just as they do in outdoor settings. Shortestindoor paths are critical in emergency response, e.g., in caseof a fire in an office building. Also, shortest indoor paths oftenimply optimal routes in computer games [1] that have complexindoor environments as (parts of) their settings.

Indoor spaces are characterized by various entities, notablydoors and rooms. Such entities enable as well as constrainindoor movement, and thus render traditional space modelsfor Euclidean spaces and spatial network spaces unsuitablefor indoor environments.

An example indoor floor plan is shown in Figure 1. Each

Fig. 1. Floor Plan

door is identified by a corresponding di, and an arrow attachedto a door implies directionality of the door. For example, doorsd12 and d15 are unidirectional. One can walk through door d15only from room 13 to room 12.

The Euclidean distance between two indoor positions suchas p and q carries little meaning because it goes through wallsbetween rooms. Rather, one has to go through door d13, ordoors d15 and d12, to reach position q from position p.

2012 IEEE 28th International Conference on Data Engineering

1084-4627/12 $26.00 © 2012 IEEE

DOI 10.1109/ICDE.2012.44

438

2012 IEEE 28th International Conference on Data Engineering

1084-4627/12 $26.00 © 2012 IEEE

DOI 10.1109/ICDE.2012.44

438

On the other hand, existing indoor space models [4], [11],[12], [14] pay little attention to indoor distances. For example,Li and Lee [11] count the number of doors along indoor routesto identify indoor nearest neighbors. This arrangement oftenfails to reflect the actual indoor distance one needs to walk toreach an indoor destination.

In the example shown in Figure 1, the shortest indoor pathfrom position p to position q (p → d15 → d12 → q) goesthrough doors d15 and d12. The aforementioned model [11]takes the clearly longer path that goes through door d13 (p→d13 → q) since this path only involves one door.

To improve on existing models, we propose a versatiledistance-aware data management infrastructure for indoorspaces. The infrastructure provides a graph-based indoor spacemodel that captures indoor topology information and integratesbasic indoor distances. Such a distance-aware model supportsefficient computation of different types of indoor distances,e.g., door-to-door distance as well as position-to-positiondistance. Furthermore, the infrastructure provides an indexingframework that indexes pre-computed door-to-door distancesand thus facilitates indoor distance-aware query processing.

In summary, we make the following contributions. First, wepropose a distance-aware indoor space model that integratesindoor distances. Second, we develop efficient algorithms thatcompute indoor distances accordingly. Third, we design an in-dexing framework for indoor distances as well as objects withthe intention to facilitate the processing of indoor distance-aware queries. Fourth, on top of the foundation thus formed,we develop efficient algorithms for different types of indoordistance-aware queries. Finally, we conduct an extensive em-pirical study to evaluate our proposals.

The rest of this paper is organized as follows. Section IIreviews related work. Section III details our distance-awareindoor space model and the algorithms for indoor distancecomputation. Section IV presents the indexing framework forindoor objects. Section V discusses indoor distance-awarequery processing that utilizes the indexing framework. Sec-tion VI reports the experimental findings and Section VIIconcludes the paper and discusses directions for future work.

II. RELATED WORK

Symbolic indoor space models are often preferred overgeometric coordinate models because the former are able tocapture the semantics associated with indoor entities [4] andthe movements enabled (or disabled) by such entities.

An existing 3D Geometric Network Model [10] treats thevertical and horizontal connectivity relationship among 3Dspatial cells separately. A related 3D Indoor Geo-Coding tech-nique employs the 3D Poincare Duality [13] transformationto map 3D spatial cells from primal space to dual space.This technique is used for the planning of an evacuation net-work in a multi-level building [9]. A 3D metrical-topologicalmodel [17] describes both the shapes and connectivity ofspatial cells for navigation purposes. Another 3D model [14]combines space partitions with possible events in a dualspace, to enable navigation in multi-layered buildings. Such

3D models focus on topological relationships rather thanquantitative indoor distances. In other words, they do notsupport calculations of indoor distances and distance-awarequeries, which is what we consider in this paper.

A lattice-based semantic location model [11] maintainssemantic relationships and distances, e.g., the nearest neigh-bor relationship among indoor entities. This model, however,defines the “length” of an indoor path by the number ofdoors it goes through, rather than the actual walking distanceconsidered in this paper. As discussed in Section I, this modelis likely to fall short in many practical scenarios.

Different ways of transforming a floor plan into a graphalso exist [5], [16]. Our previous work on a graph-basedmodel for indoor space is proposed to support efficient indoortracking [8], but lacks support for indoor distance. The relevantprevious work [18] employs the metric of minimum indoorwalking distance, but it does not elaborate on how indoordistances can be incorporated into a space model.

The recent iNav proposal [20] models doors as nodes androoms as edges in a graph but it is unable to capture doordirectionality. A brief discussion of this aspect is given inSection III-C2. Further, iNav does not include the arbitraryindoor position-to-position distances. The LEGO representa-tion [19] involves only so-called connector-to-connector in-door distances, and it covers neither how to compute suchdistances nor how to compute more complex indoor distances.

The indoor space model we propose also differs from thoseones used for path planning in robotics applications [2], [15].Such robotics models focus on connectivity and reachabilityrather than on distances, and they target applications in relationto robots with very limited spatial awareness. In contrast, ourmodel aims to support very different indoor location-basedservices that involve humans equipped with mobile deviceslike smartphones.

Last but not least, obstacles and obstructed distances are notthe focus of this paper. Our model is able to handle generalindoor topologies and distances. Obstructed distances form asmall, local part in our model only if an indoor partition hasobstacles. Reversely, it is unclear whether or how an existingapproach [21] for spaces with obstacles can be used to modelcomplex indoor topologies. Extending the existing approach tosupport indoor distances and distance-aware queries requiressubstantial efforts and does not appear to be feasible. Given apair of source and destination positions, a complex visibilitygraph must be created on the fly by regarding all indoor entities(rooms, doors, walls, etc.) as obstacles before any furtheroperations can be applied. In contrast, our model creates, forthe entire indoor space, a single general graph, on top of whichall indoor distances are computed efficiently.

III. DISTANCE-AWARE MODELING OF INDOOR SPACES

This section presents the details of the distance-aware indoorspace model. Section III-A proposes mapping structures thatcapture indoor topology information needed for measuringindoor distances. Section III-B briefly introduces a basegraph model that does not accommodate indoor distances.

439439

Section III-C presents the indoor distance-aware model thatsubstantially extends the base graph model. Section III-Dproposes relevant indoor distance computation algorithms thatmake use of the proposed distance-aware model.

For simplicity and due to space limitations, we use therelatively simple floor plan in Figure 1 as a running example.Rooms, a staircase, a hallway, and doors and walls are shownin the figure. We use the term indoor partition to indicatea room, a hallway, or a staircase. Semantically, each indoorpartition is a smallest piece of independent space that is con-nected to other partitions by one or more doors. For example,room 11 is a partition in Figure 1, and so is staircase 50.Table I lists the notation used throughout the paper.

Notation MeaningSpartition Set of indoor partitionsSdoor Set of doorsv, vi Indoor partitionsd, di Doorsp, pi Indoor positionsGaccs Accessibility graph for an indoor spaceGdist Distance-aware graph for an indoor space

TABLE INOTATION

A. Topology Information Mappings

A door usually connects two adjacent partitions in the sensethat one can move from one partition to the other through thedoor. To simplify the presentation, we stipulate that each dooralways connects exactly two partitions1. Accordingly, we usethe mapping D2P to map a door dk to one or two partitionpairs (vi, vj) such that one can move from partition vi topartition vj through door dk.

D2P : Sdoor → 2Spartition×Spartition (1)

Referring to Figure 1, we have D2P(d12) = {(v12, v10)} fordoor d12. For door d15, we have D2P(d15) = {(v13, v12)}.In addition, we have D2P(d21) = {(v20, v21), (v21, v20)} fordoor d21. Thus, D2P(di) captures the directionality of a givendoor di. Specifically, door di is unidirectional if |D2P(di)| =1 and bidirectional if |D2P(di)| = 2. In our example, doord21 is bidirectional; doors d12 and d15 are unidirectional.

Given a door dk, from π2(D2P(dk))2, we are able to know

the partition(s) one can enter through dk. We call each suchpartition an enterable partition of dk. For convenience, we usethe following derived mapping to denote π2(D2P (dk)).

D2P� : Sdoor → 2Spartition (2)

Similarly, from π1(D2P(dk)) we are able to know thepartition(s) one can leave through dk. We call each suchpartition a leaveable partition of dk. Also for convenience, weuse the following derived mapping to denote π1(D2P(dk)).

D2P� : Sdoor → 2Spartition (3)

1We regard all of outdoor space as a special partition. If a door connectsmore than two partitions, we can convert it to multiple doors, each connectingtwo partitions.

2Here, π2({(v11 , v2

1), . . . , (v1n, v

2n)})={v2

1, . . . , v2n}, and π1 is defined

correspondingly.

For door d12 in Figure 1, we have D2P�(d12) = {v10} andD2P�(d12) = {v12}; for door d15, we have D2P�(d15) ={v12} and D2P�(d15) = {v13}; and for door d15, we haveD2P�(d21) = D2P�(d21) = {v20, v21}.

Two derived mappings can be reversed to capture relevanttopology information in the opposite direction. In particular,the mapping P2D� maps a partition v to all the doors throughwhich one can enter v; similarly, the mapping P2D� maps apartition v to all the doors through which one can leave v.

P2D� : Spartition → 2Sdoor (4)

P2D� : Spartition → 2Sdoor (5)

Given a partition v, we call each door in P2D�(v) anenterable door of v. Similarly, a door in P2D�(v) is aleaveable door of partition v. Refer again to Figure 1. Forpartition v10, we have P2D�(v10) = {d1, d11, d12, d13, d14}and P2D�(v10) = {d1, d11, d13, d14}. For partition v12, wehave P2D�(v12) = {d15} and P2D�(v12) = {d12}. Forpartition v13, we have P2D�(v13) = {d13} and P2D�(v13)= {d13, d15}. Finally, for partition v21, we have P2D�(v21) =P2D�(v21) = {d21, d24}.

When there is no need to differentiate the directionality,we use P2D(vj) to denote P2D�(vj)∪P2D�(vj). For eachdoor di ∈ P2D(vj), we say di touches partition vj . It canbe observed that only the mapping D2P is fundamental, inthat all other mappings can be derived from it. We utilize thederived mappings for ease of presentation.

B. Accessibility Base Graph

By capturing the essential connectivity and accessibility, thebase graph describes the topology of a floor plan of a possiblycomplex indoor space. A base graph is constructed from a floorplan based on the Poincare Duality [13]. Each partition in thefloor plan, such as a single room, a staircase, or a hallway,is represented as a vertex in the base graph. In addition, theexterior of the indoor space is represented by a singe vertex.

Edges are used for capturing the relationships betweenvertices. An edge can capture the connectivity between twopartitions. Each connection in the floor plan, such as a door,a hatch, or an escape window, is then represented by an edge.For example, if two rooms are connected by a door, the twocorresponding vertices are connected by an edge. Since severaldoors may connect two rooms, several edges between the samepair of vertices must be accommodated.

Sometimes, a door may permit movement in only onedirection. For example, a security check point in an airportallows only one-way movement. This also applies at entrancesand exits in underground stations. In Figure 1, door d12 onlypermits entry into the hallway from room 12, and door d15only permits the movement from room 13 to room 12 butnot in the opposite direction. Accordingly, the accessibilitygraph, a labeled, directed graph, is constructed to representthe movement permitted by doors or connections. The acces-sibility graph Gaccs is given by the triple (V,Ea, L), where:

1) V = Spartition is the set of the vertices.

440440

2) Ea = {(vi, vj , dk) | (vi, vj) ∈ D2P(dk)} is the set oflabeled, directed edges.

3) L = Sdoor is the set of edge labels.

The accessibility graph for our example is shown in Figure 2.The direction of an edge indicates the movement directionpermitted by the corresponding connection.

Fig. 2. Accessibility Base Graph

C. Distance-Aware Model

The accessibility graph does not capture indoor distanceinformation. It is also noteworthy that we cannot plug indoordistances into the base graph by simply adding costs to edges.Edges represent doors that in themselves do not define anyindoor distances. In Figure 2, the edge between partitions 12and 10 represents door d12. However, no distance informationis associated with door d12 (and the corresponding edge). Thisargument also applies to the case that involves the outdoorspace, e.g., partition 0 in Figure 2.

This important particularity calls for novel model designfor indoor distances. Our objective is to integrate indoordistances into the base graph such that distance-aware queriescan be supported efficiently with the same structure. Next, wepropose an extended graph model with specific constructs thatincorporate relevant kinds of indoor distances.

1) Extended Graph Model: Our distance-aware model in-tegrates indoor distances into the accessibility graph in aseamless way such that both topology and distance informationare captured in the same structure. We are concerned with theminimum indoor walking distance [18], the shortest distanceone has to move in an indoor space to reach a destination,e.g., to reach the nearest heart starter in an office building.

The distance-aware model is a graph structure Gdist that isgiven by the 5-tuple (V,Ea, L, fdv , fd2d), where:

1) V = Spartition is the set of vertices.2) Ea = Gaccs .Ea is the set of directed edges, where Gaccs

is the accessibility graph as defined in Section III-B.3) L = Sdoor is the set of edge labels.4) fdv : Sdoor×V →R∪{∞} maps an edge to a distance

value. Specifically, given a door di and a partition vj ,

fdv (di, vj) =

{maxp∈vj‖di, p‖, if vj ∈ D2P�(di);∞, otherwise.

In other words, if vj is an enterable partition of door di ,

fdv (di, vj) returns the longest distance one can reachwithin vj from di; otherwise, fdv (di, vj) returns ∞.

5) fd2d : V ×Sdoor×Sdoor →R∪{∞} maps a 3-tuple toa distance value. Given a partition vk and two differentdoors di and dj ,

fd2d(vk, di, dj) =

⎧⎪⎪⎪⎪⎨⎪⎪⎪⎪⎩

‖di, dj‖vk , if di ∈ P2D�(vk)and dj ∈ P2D�(vk);

0, if di = dj anddi, dj ∈ P2D(vk);

∞, otherwise.In other words, if doors di and dj both touch partitionvk, fd2d (vk, di, dj) returns the distance between di anddj within vk, which is termed ‖di, dj‖vk . If di = dj andboth are in P2D(vk), we stipulate fd2d(vk, di, dj) = 0.Otherwise, fd2d(vk, di, dj) returns ∞ to indicate thatone cannot go from di to dj (or the other way around)by only moving within vk.

Note that distance ‖di, dj‖vk above is not necessarily aEuclidean distance because there may be entities in the line ofsight between two doors. This is exemplified by the distancebetween doors d22 and d24 in Figure 1. Likewise, exhibitionstands in a large museum may be arranged in such a waythat they represent obstacles that block straight Euclideanmovements. The model proposed in this paper is able toaccommodate possible obstacles and to support obstructeddistances in indoor spaces. Nevertheless, obstructed distancesare not the focus of the paper as they are relevant only if anindoor partition has obstacles. Computation of such obstructed,local distances is covered elsewhere [21].

We refer to the running example in Figure 1 to explain theproposed model. Door d22 has two edges in Gdist : the onefrom partition v20 to partition v22, and the one from v22 tov20. The longest distance one can go within v22 from doord22 is fdv (d22, v22) = 5.6 meters, and the similar distancewithin v20 is fdv (d22, v20) = 6.6 meters3. For partition v20and its doors d2 and d22, we have fd2d(v20, d2, d22) = 5.2meters, the shortest distance between d2 and d22 within v20.For partition v12 and its two doors d12 and d15, we havefd2d(v12, d12, d15) = ∞ because one cannot go from d12 tod15 within v12. Accordingly, we have fd2d(v12, d15, d12) =1.6 meters, the Euclidean distance between d12 and d15.

2) Discussion: Consistent with the accessibility base graph,the distance-aware model represents indoor partitions as graphvertices and doors as edges. This design decision is justifiedby the following reasons.

Doors can be unidirectional, i.e., only permitting movementin one direction. For example, this occurs in settings wheresecurity is a concern, such as in airports. When representingdoors by directed graph edges, this directionality is capturednaturally. In contrast, it is not obvious how to capture direc-tionality if doors are modeled as vertices.

Doors can also be open only at certain times. This occurs ina variety of real-world settings, e.g., in office buildings, shop-ping centers, and airports. Modeling doors as edges enables

3We use the midpoints of doors when measuring door-related distances.

441441

easy extension of our proposal to accommodate such temporalvariations, simply by adding temporal information to edges.In contrast, if modeling doors as vertices, the closing of adoor invalidates corresponding vertices, which may invalidateadditional edges; and the opening of a door also necessitatessimilar, complicated operations on the graph.

D. Indoor Distance Computation

In this section, we present how different kinds of indoordistances can be computed efficiently using the distance-awaremodel. Given a start and an end, we are interested in theminimum indoor walking distance between them. We givealgorithms for different start and end types: a door or a positionin the indoor space of interest.

1) Door-to-Door Minimum Walking Distance: Given asource door ds and a destination door dt, Algorithmd2dDistance(ds, dt) finds the minimum walking distance fromds to dt by searching the distance-aware graph Gdist . Thepseudo code is shown in Algorithm 1. The idea is to expand thesearch from ds in a similar way as does Dijkstra’s algorithm,keeping all unvisited doors in a priority queue.

Two arrays, namely dist[.] and prev[.], are used to store theindoor path information during the execution of the algorithm.Specifically, dist[dj ] stores the current shortest path distancefrom source ds to a door dj ; prev[dj ] stores the correspondingprevious partition and door pair (v, di) through which thealgorithm visits the current door dj .

Algorithm 1 d2dDistance(Source door ds, destination doordt)

1: initialize a min-heap H2: for each door di ∈ Sdoor do3: if di �= ds then4: dist[di]←∞5: else6: dist[di]← 07: enheap(H, 〈di, dist[di]〉)8: prev[di]← null9: while H is not empty do

10: 〈di, dist[di]〉 ← deheap(H)11: if di = dt then12: return dist[di]13: mark door di as visited14: parts← D2P�(di)15: for each partition v ∈ parts do16: for each unvisited door dj ∈ P2D�(v) do17: if dist[di] +Gdist .fd2d (v, di, dj) < dist[dj ] then18: dist[dj ]← dist[di] +Gdist .fd2d (v, di, dj)19: replace dj’s element in H by 〈dj , dist[dj ]〉20: prev[dj ]← (v, di)

Two characteristics distinguish algorithm d2dDistance fromDijkstra’s algorithm. First, algorithm d2dDistance works oncomplex structures encompassing graph elements and addi-tional constructs that are necessary for computing indoordistances. In contrast, Dijkstra’s algorithm assumes that graphedges are directly associated with distances (or costs). Second,algorithm d2dDistance visits each graph edge (correspondingto a door) at most once by keeping them in the priority queue.

Whereas Dijkstra’s algorithm visits graph vertices which in ourcase correspond to indoor partitions.

Array prev[.] can be omitted if we are only interested in theshortest distance and do not care about the concrete shortestpath. In other words, array prev[.] can be used to reconstructthe concrete shortest path, in terms of indoor partitions anddoors, from source door ds to destination door dt.

2) Position-to-Position Minimum Walking Distance: Givenan indoor position p, function getHostPartition(p) returns thepartition that contains p. This function can be implemented asa point query using a spatial access method (e.g., an R-tree)that indexes all partitions in the indoor space of interest.

We need a function distV that captures, for an indoorposition p and a door d, the distance(s) that involves only onepertinent partition v, the one that contains p and is touchedby d. In other words, such a distance is obtained within onesingle partition v only. This is formalized as follows:

distV : P × Sdoor →R∪ {∞} (6)

Here, P denotes the set of all positions in the indoor spaceof interest. Given a position p and a door d that touches thepartition obtained in getHostPartition(p), distV (p, d) returnsthe shortest intra-partition distance between p and d. This isthe minimum distance one must walk to get from position p

to door d without leaving p’s host partition. For the sake ofsimplicity, we stipulate that distV (p, d) returns ∞ if d doesnot touch p’s host partition.

Now we are ready to give the algorithms that computethe minimum walking distance from a position ps to anotherposition pt. The basic algorithm (shown in Algorithm 2) firstlocates the source partition vs that hosts ps and the destinationpartition vt that hosts pt. The set of doors that allow one toleave vs is obtained in set P2D�(vs); the set of doors thatallow one to enter vt is obtained in set P2D�(vt).

The minimum door-to-door distance from each door ds inP2D�(vs) to each door dt in P2D�(vt) is computed, and theintra-partition distances distV (ps, ds) and distV (pt, dt) areadded to that distance to get one possible position-to-positiondistance from ds to dt. All such possible position-to-positiondistances are computed in the same way, and the minimumone is returned as the result.

Algorithm 2 pt2ptDistance(Source indoor position ps, desti-nation indoor position pt)

1: vs ← getHostPartition(ps)2: vt ← getHostPartition(pt)3: dist←∞4: for each door ds ∈ P2D�(vs) do5: dist1 ← distV (ps, ds)6: for each door dt ∈ P2D�(vt) do7: dist2 ← distV (pt, dt)8: if dist > dist1+ d2dDistance(ds, dt) + dist2 then9: dist← dist1+ d2dDistance(ds, dt) + dist2

10: return dist

Algorithm 2 calls d2dDistance(ds, dt) blindly for each pairof source and destination doors. The algorithm can be refined

442442

to avoid this. Specifically, common portions of doors, par-titions, and paths may exist when all possible door-to-doordistances are computed for different ds’s and dt’s, and it ispossible to make use of such overlapping to reduce the com-putational cost in position-to-position distance computation.

A refined version is shown in Algorithm 3. Variable doorss

is initialized to contain all leaving doors (line 3) of thesource partition vs. Variable doors t is initialized to contain allentering doors (line 4) of the destination partition vt. A door dsin doorss is excluded if it leads to a non-destination partitionthat has ds as its sole leaving door (lines 5–8). In such a case,one cannot reach the destination by entering ds’s enterablepartition. The remainder of the algorithm uses computationsin previous iterations for source-destination pairs (lines 9–37).

Algorithm 3 pt2ptDistance2(Source indoor position ps, des-tination indoor position pt)

1: vs ← getHostPartition(ps)2: vt ← getHostPartition(pt)3: doorss ← P2D�(vs)4: doors t ← P2D�(vt)5: for each door ds ∈ doorss do6: np← the partition in D2P�(ds) \ {vs}7: if P2D�(np) = {ds} and np �= vt then8: remove ds from doorss

9: distm ←∞10: for each door ds ∈ doorss do11: doors ← ∅12: for each door dt ∈ doors t do13: if distV (ps, ds) + distV (pt, dt) < distm then14: add dt to doors

15: initialize a min-heap H16: for each door di ∈ Sdoor do17: if di �= ds then18: dist[di]←∞19: else20: dist[di]← 021: enheap(H, 〈di, dist[di]〉)22: while H is not empty do23: 〈di, dist[di]〉 ← deheap(H)24: if di ∈ doors then25: doors ← doors \ {di}26: if distm > distV (ps, ds) + dist[di] + distV (pt, di)

then27: distm ← distV (ps, ds) + dist[di] + distV (pt, di)28: if doors = ∅ then29: break30: mark door di as visited31: parts← D2P�(di)32: for each partition v ∈ parts do33: for each unvisited door dj ∈ P2D(v) do34: if dj ∈ P2D�(v) then35: if dist[di]+Gdist .fd2d (v, di, dj) < dist[dj ] then36: dist[dj ]← dist[di] +Gdist .fd2d (v, di, dj)37: return distm

For each source door ds, all destination doors to be con-sidered are used to initialize a set doors , excluding anydestination door dt that is too far away compared to the currentshortest indoor distance distm (lines 11–14). After that, anexpansion following the spirit of Dijkstra’s algorithm is carriedout for ds and all doors in set doors . When expanding the

search to further away doors, the algorithm only visits thosedoors that allow objects to move out (lines 34). Also, thealgorithm updates the shortest distance when a shorter pathis found (lines 24–27). The current expansion for a door dsterminates when set doors becomes empty (lines 25, 28–29).

Unlike Algorithm 1, Algorithm 3 does not use array prev[.]to store the concrete indoor shortest path information. Such anarray can be employed to further optimize the computation ofposition-to-position minimum indoor walking distance. Specif-ically, the stored shortest indoor paths and distances that havebeen computed in previous iterations can be used to furthereliminate unnecessary distance computations. The correspond-ing further optimized version is shown in Algorithm 4.

It initializes in the same way as does Algorithm 3, exceptthat a two-dimensional array dists[di][dj ] is employed to storethe currently shortest indoor distance from source door di todestination door dj (lines 9–10). The algorithm uses arraydists[di][dj ] in two ways. When a destination door di ispopped from priority queue H and processed (lines 26–30),its previous door dj on the shortest path is obtained (line 31).If this door dj is a source door and its identifier is largerthan that of the current source door ds (line 33),4 the shortestindoor distance from source door dj to destination doordi, stored in dists[dj ][di], is exactly the difference betweendist[di] − dist[dj ]. This, together with the check in line 15to see whether dists[dj][di] is infinity, saves computationsthat are otherwise invoked for dj in a future for-loop iterationstarting in line 12. Accordingly, the shortest indoor distancefrom the source position to the destination position is updatedif necessary (lines 35–36), by using the distance from door djto door di. This backward optimization is continued until thecurrent source door ds is reached (line 32).

A similar optimization also applies to the forward directionin the algorithm (lines 40–45). In this case, di, popped frompriority queue H , is a source door and its identifier is less thanthat of the current source door ds (line 40). This implies that dihas been processed before by the for-loop starting in line 12.Therefore, the shortest path distances from di to all destinationdoors in set doors is available in array dists[.][.]. As a result,we do not continue the for-loop to compute the shortest pathdistance from ds to each destination door dj in set doors .Instead, we make use of the known shortest distance from di toeach dj (line 41–42), since the iterations so far indicate that theshortest path from ds to dj must go through di. Accordingly,the shortest indoor distance from source position to destinationposition is updated if necessary (lines 43–44), by using thedistance from door ds to door dj .

In summary, we have developed three means of computingposition-to-position distances in indoor spaces. Algorithm 2iteratively makes blind use of door-to-door distances (Algo-rithm 1) to obtain the minimum indoor position-to-positiondistance. In contrast, Algorithms 3 and 4 utilize specializedoptimizations and reuse the door-to-door distances that have

4We assume that all doors in set doorss are accessed in ascending orderof their identifiers in the for-loop in line 10. Therefore, it is implied that djhas not been processed by the for-loop as a source door.

443443

Algorithm 4 pt2ptDistance3(Source indoor position ps, des-tination indoor position pt)

1: vs ← getHostPartition(ps)2: vt ← getHostPartition(pt)3: doorss ← P2D�(vs)4: doors t ← P2D�(vt)5: for each door ds ∈ doorss do6: np← the partition in D2P�(ds) \ {vs}7: if P2D�(np) = {ds} and np �= vt then8: remove ds from doorss

9: for each door dt ∈ doors t do10: dists[ds][dt]←∞11: distm ←∞12: for each door ds ∈ doorss do13: doors ← ∅14: for each door dt ∈ doors t do15: if dists[ds][dt] =∞ and distV (ps, ds)+distV (pt, dt) <

distm then16: add dt to doors

17: initialize a min-heap H18: for each door di ∈ Σdoor do19: if di �= ds then20: dist[di]←∞21: else22: dist[di]← 023: enheap(H, 〈di, dist[di]〉)24: prev[di]← null25: while H is not empty do26: 〈di, dist[di]〉 ← deheap(H)27: if di ∈ doors then28: doors ← doors \ {di}29: if distm > distV (ps, ds) + dist[di] + distV (pt, di)

then30: distm ← distV (ps, ds) + dist[di] + distV (pt, di)31: (v, dj)← prev[di]32: while dj �= ds do33: if dj ∈ doorss and dj > ds then34: dists[dj ][di]← dist[di]− dist[dj ]35: if distm > distV (ps, dj) + dists[dj ][di] +

distV (pt, di) then36: distm ← distV (ps, dj) + dists[dj ][di] +

distV (pt, di)37: (v, dj)← prev[dj]38: if doors = ∅ then39: break40: else if di ∈ doorss and di < ds then41: for each door dj ∈ doors do42: dists[ds][dj ]← dist[di] + dists[di][dj ]43: if distm > distV (ps, ds) + dists[ds][dj ] +

distV (pt, dj) then44: distm ← distV (ps, ds) + dists[ds][dj ] +

distV (pt, dj)45: break46: mark door di as visited47: parts← D2P�(di)48: for each partition v ∈ parts do49: for each unvisited door dj ∈ P2D(v) do50: if dj ∈ P2D�(v) then51: if dist[di]+Gdist .fd2d (v, di, dj) < dist[dj ] then52: dist[dj ]← dist[di] +Gdist .fd2d (v, di, dj)53: prev[dj ]← (v, di)54: return distm

been computed so far. We experimentally compare all three

versions in Section VI-A.

IV. INDOOR DISTANCE-AWARE INDEXES

We propose an indexing framework that is aware of thenotion of indoor distance presented in Section III. In Sec-tion IV-A, we present the base indexing structure that isderived from the indoor topology and indoor distances. InSection IV-B, we show how to index indoor objects on topof the base indexing structure.

A. Base Indexing Structure

To support distance based queries, we need to accessindoor distances, especially door-to-door distances. Therefore,we store all door-to-door distances, computed as defined inSection III-D1, in a Door-to-Door Distance Matrix, denotedas Md2d . It is an N -by-N matrix, where N = |Sdoors |is the total number of doors. Let di and dj be two dooridentifiers. Without loss of generality, we suppose 1 ≤ di <

dj ≤ |Sdoors |. Regarding Md2d , we have the following: (1)Md2d [di, di] = 0; (2) Md2d [di, dj ] = d2dDistance(di, dj); and(3) Md2d [di, dj ] may differ from Md2d [dj , di].

The top-left part of Figure 1 has six doors, namely d1,d11, d12, d13, d14, and d15. The corresponding door-to-doordistance matrix is shown in Figure 3. It is clear that this matrixis not symmetric, e.g., Md2d [d11, d15] �= Md2d [d15, d11]. Thisis due to the existence of directed doors. A door-to-doorshortest path from door di to dj via a directional door dkis not identical to the shortest path in the other direction, i.e.,from dj to di.⎛

⎜⎜⎜⎜⎜⎜⎜⎜⎝

d1 d11 d12 d13 d14 d15d1 0 1.7 2.7 3.2 2.6 4.3d11 1.7 0 1.9 3.4 3 4.4d12 2.7 1.9 0 2 2.2 3d13 3.2 3.4 2 0 1.2 1d14 2.6 3 2.2 1.2 0 2.2d15 3.2 3.4 1.5 3.5 3.7 0

⎞⎟⎟⎟⎟⎟⎟⎟⎟⎠

Fig. 3. Distance Matrix

We also use Md2d [di, ∗] to denote all the distances fromdoor di to all (other) doors, which can be regarded as anarray of distance values. To further facilitate the processing ofdistance based queries, we create a sequential index for everydistance array Md2d [di, ∗] such that distance retrieval for doordi can be conducted in a sorted fashion. Specifically, we createfor the distance matrix Md2d an N -by-N Distance IndexMatrix, denoted as Midx , with the following property: Givena door identifier di, and two integers 1 ≤ j < k ≤ |Sdoor |,Md2d [di,Midx [di, j]] ≤Md2d [di,Midx [di, k]].

Referring again to the top-left part of Figure 1, the dis-tance index matrix corresponding to the door-to-door distancematrix is shown in Figure 4. In this particular example,the first row indicates that the following distance order-ing holds: d2dDistance(d1, d1) ≤ d2dDistance(d1, d11) ≤d2dDistance(d1, d14) ≤ d2dDistance(d1, d12) ≤ d2dDist−ance(d1, d13) ≤ d2dDistance(d1, d15).

444444

⎛⎜⎜⎜⎜⎜⎜⎜⎜⎝

1 2 3 4 5 6d1 d1 d11 d14 d12 d13 d15d11 d11 d1 d12 d14 d13 d15d12 d12 d11 d13 d14 d1 d15d13 d13 d15 d14 d12 d1 d11d14 d14 d13 d12 d15 d1 d11d15 d15 d12 d1 d11 d13 d14

⎞⎟⎟⎟⎟⎟⎟⎟⎟⎠

Fig. 4. Distance Index Matrix

In the design of the matrixes Md2d and Midx we implicitlyregard all doors as being topologically equal. This was doneto achieve a general design. It is possible that a particulardoor or staircase is topologically more important than others.In such cases, it is of interest to build such knowledge intoour proposal so that this can be exploited in indoor distancecomputation and even query processing. Nevertheless, identi-fying the different degrees of topological significance of doorsand staircases requires extra effort and domain knowledge. Inthis paper we aim for a general and self-contained design andleave topological significance for future research.

B. Indexing Indoor Objects

Motivated by the fact that any indoor object must be locatedin some partition, we store objects within the same partitiontogether in an object bucket or several chained buckets. Sinceeach partition is touched by one or more doors through whichobjects can move in or out, we create pointers from doors totheir connected partitions and the associated bucket(s).

We use a linear table Door-to-Partition Table (DPT) tostore the relationship between doors and partition object buck-ets. Each record in DPT is a 5-tuple (di, vP tr1, dist1, vP tr2,dist2), where di is a door identifier. The remaining fields arerelevant to the partitions that di touches.

If D2P(di) = {(vj , vk)}, which means that door di isdirectional from partition vj to vk, then field vP tr1 is a nullpointer, vP tr2 is a pointer that points to the object bucket ofpartition vk , dist1 is ∞, and dist2 is Gdist .fdv(di, vk).

Otherwise, D2P(di) = {(vj , vk), (vk, vj)}, meaning thatdoor di is bidirectional between partition vj to vk. Without lossof generality, we assume that two partition identifiers satisfyvj < vk. Then field vP tr1 is a pointer that points to theobject bucket of partition vj , vP tr2 is a pointer that pointsto the object bucket of partition vk, dist1 is Gdist .fdv (di, vj),and dist2 is Gdist .fdv (di, vk).

Referring to Figure 1 again. Remember that we haveD2P(d15) = {(v13, v12)}. As a result, door d15’s correspond-ing DPT entry is (d15, null,∞, vP tr2, 2.4), where vP tr2points to partition v13’s object bucket.

As a door touches at most two partitions, there is only onerecord for each door, and the field of door identifier di servesas the primary key of the DPT. To facilitate record retrievalbased on door identifiers, we sort the whole DPT on the difield. Given a door identifier di, we use DPT[di] to denote thecorresponding record.

V. PROCESSING INDOOR DISTANCE-AWARE QUERIES

We proceed to propose algorithms for indoor distance-aware queries. In Section V-A, we describe how distance-aware queries over indoor spatial objects can be processedby exploiting the indexing structures proposed in Section IV.In Section V-B, we describe how to organize spatial objectswithin an indoor partition in a more fine-grained mannerwithin our proposed indexing framework.

A. Queries

We consider range and nearest neighbor queries over indoorobjects. We process each query type by making use of theindexing structures described in Section IV.

1) Range Query: Given an indoor position q and a distancerange r, a range query Qr(q, r) returns those indoor objectsthat are within distance r of q. By making use of the indexingstructures, a range query Qr(q, r) is processed according tothe pseudo code shown in Algorithm 5.

Algorithm 5 range(Position q, distance r)1: v ← getHostPartition(q)2: R← rangeSearch(v’s bucket, p, r)3: for each door di ∈ P2D�(v) do4: r1 ← r − distV (q, di)5: for j from 1 to |Sdoor | do6: dj ← Midx [di, j]7: if Md2d [di, dj ] > r1 then8: break9: else

10: r2 ← r1 −Md2d [di, dj ]11: if DPT[dj].vP tr1 �= null then12: if DPT[dj].dist1 ≤ r2 then13: add objects in DPT[dj ].vP tr1’s bucket to R14: else15: R← R ∪ rangeSearch(DPT[dj ].vP tr1, dj , r2)16: if DPT[dj].vP tr2 �= null then17: if DPT[dj].dist2 ≤ r2 then18: add objects in DPT[dj ].vP tr2’s bucket to R19: else20: R← R ∪ rangeSearch(DPT[dj ].vP tr2, dj , r2)21: return R

The algorithm first gets the query position q’s host partitionv (line 1), then searches for possibly qualifying objects withinv by utilizing the grid index built on v (line 2). Here,procedure rangeSearch(Bi, q, r) searches an object bucket Bi

for all objects within distance r of q. Specifically, bucketBi corresponds to an indoor partition vi and contains all theobjects currently in vi. In contrast, q is either a position insidevi or a door of vi. More details regarding intra-partition objectorganization and search are to be addressed in Section V-B.

Subsequently, for each door di through which one can leavev, a linear search is done among its distances to all otherdoors that are stored in Md2d [di, ∗] (lines 3–20). By exploitingthe index in Midx [di, ∗], the search is conducted in non-descending order of Md2d [di, dj ], where dj is a door coveredby the query distance r from query position q (lines 4–8).

For every such door dj , the algorithm processes its con-nected partition(s) through DPT. If a partition is entirely

445445

within the query range, i.e., DPT[dj ].distx + distV (q, di) +Md2d [di, dj ] ≤ r (x ∈ {1, 2}), all objects in the correspondingbucket are added to the result (lines 12–13 and 17–18).Otherwise, a range query is done against the partition withdj as the query position and r − distV (q, di)−Md2d [di, dj ]as the range distance (lines 15 and 20). The above process isrepeated for every door dj until it is found that a new door djis too far away from q, i.e., Md2d [di, dj ] + distV (q, di) > r.

Note that DPT[dj ].vP tr1 and DPT[dj ].vP tr2 can be thepartitions where q is located, but we still need to do the rangesearch again. This is because obstacles can result in the intra-partition distance between two points not being the shortest.We refer to the example shown in Figure 5. The figure containsfour obstacles O1 to O4 in rooms 1 and 2. For two points inroom 2, p near d6 and q near d9, intra-room path p→ C1 →C2 → C3 → q is not the shortest indoor distance path from p

to q. Instead, path p→ d7 → d8 → q is the shortest althoughit starts from room 2, enters room 1, and finally returns toroom 2. This remark also holds for the other query type.

Fig. 5. Indoor Obstacles

2) Nearest Neighbor Query: Given an indoor position q, anearest neighbor (NN) query Qnn(q) returns the indoor objectwhose distance from q is the smallest among all objects. Bymaking use of the indexing structures, an NN query Qnn(q)is processed as detailed in Algorithm 6.

The current nearest neighbor and its distance from q arekept in nn and distnn respectively (line 1). Initially, thealgorithm gets the query position q’s host partition v andsearches v utilizing a grid index built on v (lines 2–3). Here,nnSearch(Bi, q, distnn) searches an object bucket Bi to findthe nearest neighbor from q, where distnn is the currentnearest neighbor distance that can be used for fast pruning.As mentioned above, bucket Bi contains all the objects in itscorresponding indoor partition vi, and q is either a positioninside vi or a door of vi. Details regarding the intra-partitionobject organization and search are given in Section V-B.

Subsequently, for each door di through which one canleave v, search is conducted in the similar way as for rangequery processing (lines 4–19). All other doors are accessedin non-descending order of the distances from di by makinguse of the index in Midx [di, ∗] for the distances stored inMd2d [di, ∗]. If a door dj is within the current nearest distance,i.e., distV (q, di) + Md2d [di, dj ] ≤ distnn , dj’s connectedpartition(s) is searched (lines 11–19). Otherwise, door dj is

outside the current nearest distance, and therefore the searchwith respect to door di stops (lines 8–9).

In order to return k (k > 1) nearest neighbors, the algorithmcan be extended as follows. Instead of two variables nn

and distnn , a k-element array result is used to maintainthe k nearest neighbor as well as their distances to queryposition q. In particular, result[i].nn (1 ≤ i ≤ k) is the i-th nearest neighbor and result[i].dist is the correspondingdistance to q. Initially, each result.nn is set to null and eachresult[i].dist is set to ∞. In addition, function nnSearch(.)is revised accordingly. It takes the entire result array as thethird parameter, and updates the array directly during its searchrather than returning the result of a single nearest neighborfinally. Given a bucket Bi, nnSearch(.) continues searchingBi for nearest neighbors. When a nearest neighbor nn withdistance distnn to q is found, nnSearch(.) compares distnnto result[k].dist. If distnn < result[k].dist, (nn, distnn)will be inserted into result at the appropriate position so thatall distances are in non-descending order and the old k-thelement is discarded. Otherwise, i.e., distnn ≥ result[k].dist,nnSearch(.) stops searching because no further objects in Bi

can be closer to q than the current k nearest neighbors.

Algorithm 6 NN(Position q)1: nn← null; distnn ←∞2: v ← getHostPartition(q)3: (nn, distnn)← nnSearch(v’s bucket, q, distnn )4: for each door di ∈ P2D�(v) do5: r1 ← distV (q, di)6: for j from 1 to |Sdoor | do7: dj ← Midx [di, j]8: if r1 +Md2d [di, dj ] > distnn then9: break

10: else11: r2 ← r1 +Md2d [di, dj ]12: if DPT[dj].vP tr1 �= null then13: (obj, dist)← nnSearch(DPT[dj ].vP tr1, dj , distnn−

r2)14: if dist+ r2 < distnn then15: (nn, distnn)← (obj, dist+ r2)16: if DPT[dj].vP tr2 �= null then17: (obj, dist)← nnSearch(DPT[dj ].vP tr2, dj , distnn−

r2)18: if dist+ r2 < distnn then19: (nn, distnn)← (obj, dist+ r2)20: return R

B. Intra-Partition Object Index and Search

To process the two types of queries more efficiently, webuild a grid index for spatial objects in each indoor partition.We apply a uniform grid to each partition, where each gridcell captures the positions of all the objects in it. Accordingly,we organize all spatial objects in an indoor partition vi usinga corresponding bucket Bi, and Bi consists of multiple sub-buckets each of which corresponds to a grid cell.

The grid index for each indoor partition is built staticallywhen the floor plan is given. As a matter of fact, the grid fora partition needs not necessarily be uniform. We can take intoaccount the shape and possible obstacles in a partition when

446446

constructing the grid. For example, we can create a grid insuch a way that some cells cover obstacles only and thus haveno corresponding object sub-buckets. As the grid configurationis not the focus of this paper, we omit the low-level details.

We use a simple grid to index spatial objects within eachindoor partition because a grid is able to accelerate thedistance comparison within a partition. This grid configurationinformation helps us prune non-qualifying sub-buckets andthus their objects. This way, we can further prune the searchspace within each indoor partition.

For rangeSearch(Bi, q, r), we search only those grid cells(and their sub-buckets in Bi) that overlap the circle centeredat q and with radius r. If a cell is fully inside the circle, allthe objects in its sub-bucket are included directly.

For nnSearch(Bi, q, distnn), similarly, we need to searchonly those grid cells (and their sub-buckets in Bi) that overlapthe circle centered at q and with radius distnn. During theintra-partition search, distnn is updated dynamically to reducethe search range.

VI. EXPERIMENTAL EVALUATION

We experimentally evaluate our proposals in this section.Section VI-A evaluates the indoor distance computation algo-rithms of the indoor distance model. Section VI-B evaluatesthe query algorithms. All algorithms are implemented in Java.

A. Performance of Distance Computation

We evaluate the efficiency of three indoor position-to-position distance algorithms, namely Algorithms 2, Algo-rithm 3, and Algorithm 4 that are proposed in Section III-D2.Both a desktop PC and a mobile phone are used to run thedistance algorithms. Specifically, we use a desktop PC with a2.66GHz Core2 Duo CPU and 3.25GB main memory runningWindows XP Pro. In addition, we use a Samsung Nexus Sphone with a 1GHz ARM processor and 346MB memoryaccessible to applications and running Android.

We generate different office building plans. For each floorof a building, we generate 30 rooms and 2 staircases, and allof them are connected by doors to a hallway in a star-likemanner. We vary the number of floors and therefore also thenumber of doors in each simulated building.

Given a simulated building generated as described above,we treat each staircase as a special room with two doors, eachof which connects to its corresponding floor. Inside such avirtual room, the door-to-door distance is the actual walkingdistance when using the corresponding staircase. This way,the entire multi-floor building is “transformed” into a flatone with a single floor. We then apply the distance-awaremodel proposed in Section III-C and compute the position-to-position distances accordingly. For each algorithm invocation,we generate at random two indoor positions in the floor plan.

On the desktop PC, we run each algorithm 50 times withrandom indoor positions, measuring the average running timefor each algorithm. According to the results reported inFigure 6, the refined Algorithms 3 and 4 clearly outperformthe simpler Algorithm 2. This is attributed to the fact that the

latter blindly calls the basic door-to-door distance algorithm(Algorithm 1) without any optimizations.

It is also seen that Algorithms 3 and 4 scale well with thenumber of floors (and doors), indicating that the optimizationsof reusing computations are quite effective and that the opti-mized algorithms are scalable with respect to the size of anindoor space.

Taking a closer look, Algorithm 4 incurs less time than doesAlgorithm 3, especially when the indoor space size is large.With 40 floors, Algorithm 4 runs faster than Algorithm 3 byup to 0.5 seconds. This indicates that the optimization appliedto Algorithm 4 is effective.

7000

6000

5000

4000

3000

2000

1000

040302010

Tim

e (m

illis

ec.)

Number of Floors

Algorithm 2Algorithm 3Algorithm 4

Fig. 6. Distance Algorithms on Desktop PC

On the Android mobile phone, we run each algorithm 10times with random indoor positions and still measure theaverage running time for each algorithm. The results are shownin Figure 7, where we disregard Algorithm 2 because it isconsiderably slower than the two refined versions.

0

1000

2000

3000

4000

5000

6000

7000

8000

10 20 30 40

Tim

e (m

illis

ec.)

Number of Floors

Algorithm 3Algorithm 4

Fig. 7. Distance Algorithms on Android Phone

The results in Figure 7 show that Algorithm 4 runs approx-imately twice as fast as Algorithm 3 in all settings. This isa significant performance gain in terms of user experience onresource-constrained smartphones.

It is expected that the pt2ptdistance algorithm runs fasterif the door-to-door distances are pre-computed and stored forreference. However, such pre-computed results are not alwaysavailable. Moreover, it can be space-consuming to maintainsuch pre-computed results, e.g., on a resource-constrainedmobile device. These observations, as well as the betterperformance of Algorithms 3 and 4 as seen in this section,justify the two refined versions of the pt2ptdistance algorithm.

447447

B. Performance of Query Processing

We proceed to evaluate the query processing algorithmsproposed in Section V using the desktop PC.

We generate indoor objects (POIs) as follows. Given anindoor space as generated in Section VI-A, a floor is firstchosen at random, and then a partition is picked at randomon that floor. Subsequently, a random position within theparticular indoor partition is chosen as the object’s position.In summary, all indoor objects are distributed randomly in thegiven indoor space.

The indoor partitions used in the experiments do not allhave the same size. Nevertheless, the exact size of a partitionis not a concern, as all POIs are generated in relative units withrespect to a partition. We believe that the star-like manner is areasonably simplified case that reflects a frequently seen typeof indoor spaces.

In all experiments, we issue 100 queries for each query typeand report the average response time per query type. For eachquery type, we look into the effects of three aspects.

First, we investigate how use of the door-to-door distanceindex matrix proposed in Section IV-A affects query perfor-mance. In all experiments relevant to this aspect, we generatespatial objects in a 30-floor building with about 1,000 doors.The number of objects is varied from 1K to 50K, and thecorresponding query parameters are set to their default values.When the distance index matrix Midx is not used, each queryprocessing algorithm has to search the entire door-to-doordistance matrix Md2d directly.

Second, we investigate how the building size, i.e., thenumber of floors, affects the query performance. In particular,we set the object density on each floor to 10,000, and we varythe number of floors from 10 to 40. We compare the queryperformance with and without the distance index matrix.

Third, we investigate how query performance is affected bythe corresponding query parameters. In the relevant experi-ments, we use the same data sets as above, and we processqueries by using the distance index matrix.

We store all indexing structures in main memory. The size ofthe Distance Index Matrix is |Sdoor |×|Sdoor |×4 bytes, whereeach matrix element is a door identifier of integer type. Thesimulated 40-floor building in our experiment has 30 doorsplus 2 virtual doors (staircases) at each floor and therefore32 × 40 = 1280 doors in total. The corresponding DistanceIndex Matrix’s size is 1280 × 1280 × 4 = 6.25 MB. Eachelement in DPT is of 4+4+8+4+8 = 28 bytes. The size ofDPT is at most 2× |Sdoor | × 28 = 56× |Sdoor | bytes as eachdoor touches at most two partitions. For the 40-floor buildingin our experiment, DPT’s size is thus 56× 1280 = 70 KB.

1) Range Query Performance: For a range query, we ran-domly pick a floor and generate a random query position onthat particular floor. The default range distance is set to 30meters. We study the effect of using the index matrix whenvarying the number of objects and the number of floors, andwe study the effect of varying the range query size when usingthe index matrix. The results are reported in Figure 8.

Referring to Figure 8(a), the index matrix improves thequery performance only moderately. This is mainly becausethe query range is not large. The distance index matrix doesnot help much in pruning when the query range is limited.

According to the results shown in Figure 8(b), the distanceindex matrix improves the range query performance, especiallywhen the building has more floors and doors.

As the query range increases, according to the resultsshown in Figure 8(c), the query response time also increases.However, the overall time is still moderate. This indicates thatthe algorithm using the distance index matrix is effective.

2) kNN Query Performance: For a kNN query, we stillrandomly pick a floor and then generate a random queryposition on that particular floor. The default k is set to 100,and the experimental results are reported in Figure 9.

Figure 9(a) shows that the distance index matrix improvesthe kNN query performance significantly. In particular, therunning time is about four times shorter across all objectcardinalities. This indicates that the kNN query processingalgorithm equipped with the distance index matrix is effectivein pruning unpromising parts of the search space. The non-ascending ordering of door-to-door distances indicated by theindex matrix enables us to prune indoor partitions drasticallywhenever the current kNN bound is reduced.

Next, Figure 9(b) again shows that use of the distanceindex matrix improves kNN query performance significantly.Importantly, the performance gain compared to the caseswithout the index matrix increases when the number of floorsincreases. Thus, the matrix renders the kNN query processingscalable with respect to building size.

The results in Figure 9(c) show that larger k values incurlonger query response times. This is because a larger k valuetends to result in more indoor partitions having to be searchedfor nearest neighbors. Nevertheless, the overall response timeof searching for up to 200 indoor nearest neighbors is still aslow as 4.5 milliseconds. Thus, matrix-facilitated kNN searchis scalable in terms of k.

VII. CONCLUSION AND FUTURE WORK

In this paper, we propose a distance-aware indoor spacedata model that is also equipped with efficient indoor distancecomputation algorithms. To support efficient distance-awarequeries, an indexing framework is designed to organize indoordistances that are computed by the proposed algorithms. Ontop of the foundation thus formed, specific algorithms areproposed for processing indoor distance-aware queries overindoor spatial objects.

An experimental study is conducted to evaluate the propos-als on a desktop PC as well as an Android mobile phone.The results show that the proposals are effective, efficient,and scalable in terms of the indoor space size, indoor objectcardinality, as well as the query parameters.

Several directions for future work exist. It is of interest tointroduce temporal variations in a distance-aware indoor spacemodel and query processing. For example, some doors in abuilding may be open only during particular periods of time.

448448

40

30

20

10

050K40K30K20K10K5K1K

Tim

e (m

illis

ec.)

Number of Objects (r=30m)

With d2d IndexWithout d2d Index

70

60

50

40

30

2040302010

Tim

e (m

illis

ec.)

Number of Floors (r=20m)

With d2d IndexWithout d2d Index

200

150

100

50

050K40K30K20K10K5K1K

Tim

e (m

illis

ec.)

Number of Objects

10m20m30m40m50m

(a) Effect of Object Number (b) Effect of Floor Number (c) Effect of Query Parameter

Fig. 8. Performance of Range Query

12

10

8

6

4

2

050K40K30K20K10K5K1K

Tim

e (m

illis

ec.)

Number of Objects (k=100)

With d2d IndexWithout d2d Index

20

15

10

5

040302010

Tim

e (m

illis

ec.)

Number of Floors (k=100)

With d2d IndexWithout d2d Index

6

5

4

3

2

1

050K40K30K20K10K5K1K

Tim

e (m

illis

ec.)

Number of Objects

k=1k=50

k=100k=150k=200

(a) Effect of Object Number (b) Effect of Floor Number (c) Effect of Query Parameter

Fig. 9. Performance of kNN Query

Accordingly, an indoor space model must be able to returncorresponding indoor distances for different time points.

Further, it is also relevant to consider other types ofdistance-aware indoor queries that capture practical needs, byusing the query types in this paper as building blocks.

Yet another relevant possibility is to propose an integrateddistance model for both outdoor and indoor spaces, such thatoutdoor and indoor location-based services can be supportedseamlessly. In such a scenario, the shortest distance path froman outdoor/indoor position to another outdoor/indoor positionmay involve outdoor and indoor spaces in an interweavedfashion. Consequently, simply applying an outdoor modelfollowed by an indoor model, or the other way around, doesnot work because it disables the interweaving.

ACKNOWLEDGMENTS

This research was partially supported by the Indoor SpatialAwareness project of the Korean Land Spatialization Groupand BK21 program. The authors thank Artur Baniukevic forrunning the distance algorithms on the Android mobile phone.

REFERENCES

[1] MobyGames. http://www.mobygames.com/.[2] P. K. Agarwal, B. Aronov, and M. Sharir. Motion Planning for a

Convex Polygon in a Polygonal Environment. Discrete & ComputationalGeometry, 22(2):201–221, 1999.

[3] P. Bahl and V. Padmanabhan. RADAR: an in-building RF-based userlocation and tracking system. In Proc. of INFOCOM, pages 775–784,2000.

[4] C. Becker and F. Durr. On location models for ubiquitous computing.Personal and Ubiquitous Computing, 9(1):20–31, 2005.

[5] G. Franz, H. Mallot, and J. Wiener. Graph-based Models of Space inArchitecture and Cognitive Science-a Comparative Analysis. In Proc.IIAS InterSymp, pages 30–38, 2005.

[6] M. Hermersdorf. Indoor Positioning with a WLAN Access Point Liston a Mobile Device. In Proc. Workshop on World-Sensor-Web, 5 pages,2006.

[7] J. Hightower and G. Borriello. Location Systems for UbiquitousComputing. IEEE Computer, 34(8):57–66, 2001.

[8] C. S. Jensen, H. Lu, and B. Yang. Graph model based indoor tracking.In Proc. MDM, pages 122–131, 2009.

[9] J. Lee. 3D GIS for geo-coding human activity in micro-scale urbanenvironments. In Proc. GIScience, pages 162–178, 2004.

[10] J. Lee. A spatial access-oriented implementation of a 3-D GIS topo-logical data model for urban entities. GeoInformatica, 8(3):237–264,2004.

[11] D. Li and D. L. Lee. A lattice-based semantic location model for indoornavigation. In Proc. MDM, pages 17–24, 2008.

[12] D. Li and D. L. Lee. A topology-based semantic location model forindoor applications. In Proc. GIS, page 6, 2008.

[13] J. Munkres. Elements of algebraic topology. Addison Wesley PublishingCompany, 1993.

[14] C. N. T. Becker and T. H. Becker. A multilayered space-event modelfor navigation in indoor spaces. Proc. Workshop on 3D Geo-Info, pages61-77, 2008.

[15] J. A. Storer and J. H. Reif. Shortest Paths in the Plane with PolygonalObstacles. J. ACM, 41(5):982–1012, 1994.

[16] C. van Treeck and E. Rank. Analysis of building structure and topologybased on graph theory. In Proc. ICCCBE, 10 pages, 2004.

[17] E. Whiting, J. Battat, and S. Teller. Topology of Urban Environments:Graph construction from multi-building floor plan data. In Proc. CAADFutures, pages 115–128, 2007.

[18] B. Yang, H. Lu, and C. S. Jensen. Probabilistic threshold k nearestneighbor queries over moving objects in symbolic indoor space. InProc. EDBT, pages 335–346, 2010.

[19] W. Yuan and M. Schneider. Supporting 3D route planning in indoorspace based on the LEGO representation. In Proc. of ISA, pages 16–23,2010.

[20] W. Yuan and M. Schneider. iNav: An Indoor Navigation ModelSupporting Length-Dependent Optimal Routing. In Proc. of AGILE,pages 299–314, 2010.

[21] J. Zhang, D. Papadias, K. Mouratidis, and M. Zhu. Spatial queries inthe presence of obstacles. In Proc. EDBT, pages 366–384, 2004.

449449