**1. Introduction**

There are many LBS applications, such as taxi hailing, ride sharing and car navigation, and various *K*-nearest-neighbor (KNN) query algorithms have been proposed to solve these problems. With the development of geographic information systems (GISs), KNN query in road networks has evolved from static objects to dynamic objects. The moving objects change their locations and directions frequently over time; therefore, the cost of retrieving the exact results of continuous *K*-nearest neighbor (CKNN) for moving objects is expensive, particularly in highly dynamic spatio-temporal applications, for example, finding the nearest taxi while the user moves in road networks over a period of time. When the user moves to a new location, the traditional solution is to perform a snapshot KNN query. Due to the objects' continuous movement in road networks, a series of frequent snapshot KNN queries are necessary, which are unrealistic and expensive. The cost includes updating the location of moving objects when the velocities change over time and processing the CKNN queries that are posed by the moving object to the server. Therefore, this paper proposes a continuous KNN query method for predicting the *K*-nearest moving objects via predictive computation.

As shown in Figure 1, there are a query object, which is denoted by *q*, and a moving object set, which is denoted by *P*. Each object in the road network moves in the direction of arrow. Taking the query object *q* as an example, *q*(2) indicates that the query object *q* moves at speed 2 towards starting point *n*2 of the edge where *q* is located in the road network. The moving query object *q* requests to retrieve the nearest neighbor object in a specified period. In Figure 1a, the result of the nearestneighbor query is *p*1 at timestamp 0, and the query result is changed to *p*2 at timestamp 2, as shown in Figure 1b. The query system must monitor the timestamp when the query result will change in the time interval [0, 2] and return the updated result. The query result consists of two-tuples, <{*p*1}, [*t*0, *t*1]<sup>&</sup>gt;, <{*p*2}, [*t*1, *t*2]> ... <{*pi*}, [*ti-*1, *ti*]<sup>&</sup>gt;. {*pn*}, [*tn-*1, *tn*]. The query results in Figure 1 are as follows: <{*p*1}, [0, 10/7]> and <{*p*2}, [10/7, 2]<sup>&</sup>gt;.

**Figure 1.** The local road network information under different timestamp: (**a**) at timestamp 0; (**b**) at timestamp 2.

As in Figure 1, the CKNN query only uses distance as the criterion, namely, the KNN query recommended objects are the nearest objects to the query object; however, there may be objects that move away from the query object gradually and the distance to the query object will increase. Moreover, in one-way roads, these moving objects need to turn around at the next intersection to reach the query object. For identifying the object that is nearest to the query object in application scenarios, the object that is queried in Figure 1a is invalid. Therefore, the CKNN query should not only consider the distance factor but also the direction of moving objects. In this paper, we propose a method of direction-aware continuous moving *K*-nearest neighbor (DACKNN) query in road networks. By using the direction constraint, we can continuously monitor the *K*-nearest moving objects that are moving towards the query object.

Many scholars [1–3] have utilized the search-space pruning algorithm, which is based on a road network, to deal with continuous *K*-nearest neighbor queries. Most of them only consider the nearest objects in the dimension of distance. There are some scholars [4–6] that consider the direction-aware query of moving objects in Euclidean space. However, the problem does not involve road network constraints; hence, it cannot be applied to continuous nearest-neighbor query in road networks. In this paper, we consider direction-aware continuous nearest-neighbor queries under the following three assumptions: (1) all objects (including the query object) are dynamic in the road network. (2) The distance between two objects is represented by the shortest path between the two objects in the road network. (3) The result set in each sub-interval of a period is determined. The first problem to be solved is the calculation of the distances between moving objects and the query object at every timestamp in the road network. Because of the continuous movement of objects in the road network, the distance between any two objects is constantly changing. If the Dijkstra algorithm is used for every movement change, the re-computation of the network distance is highly time-consuming. In this paper, the distance between moving objects is calculated based on three factors: the moving speed, the moving direction, and the shortest path between the nodes in the road network. It is a linear function of time.

The main contributions of this paper are as follows:


In this paper, Section 2 introduces the related work on the *K*-nearest-neighbor query in road networks; Section 3 presents the data structure, problem definition and related concepts; Section 4 describes the direction-aware continuous moving *K*-nearest-neighbor query algorithm in a road network environment; Section 5 presents the results and analyses of the relevant comparative tests; and Section 6 summarizes the paper, identifies the shortcomings and discusses future work.

## **2. Related Work**

Shifting from static objects to dynamic objects, many scholars focused on CKNN queries under road network constraints. However, the practical requirements of users are not met by only considering the distance factor. Therefore, the direction-based CKNN query will inevitably become a trend in spatial database technology.

#### *2.1. K-Nearest-Neighbor Query in Road Networks*

The *K*-nearest-neighbor query in road networks has been widely studied in the field of spatial databases. Papadias et al. [7] proposed a flexible system for handling KNN queries in spatial road network databases, which used the Incremental Euclidean Restriction (IER) algorithm and the Incremental Network Expansion (INE) algorithm to discover KNN objects. These extensions are inspired by the Dijkstra algorithm [8]. Kolahdouzan et al. [9] introduced the Network Nearest Neighbor (VN3) algorithm for solving KNN queries by dividing the spatial network into several small voronoi polygons, and calculated the road network distance based on these voronoi polygons. Hu et al. [10,11] facilitated the KNN query by establishing an index. The KNN query was performed by retrieving a set of interconnected trees [10]. These trees come from the road network. Hu et al. [11] used the distance labeling to maintain approximate road network distances and construct indices to accelerate KNN search. Lee et al. [12] pruned the KNN search space into a subspace without objects. The above studies only consider the distances in the road network as the criterion for judging the neighborhoods; however, in practice, the distance between moving objects cannot be determined only by the physical distance and the relative direction of motion between the two is also an important factor.

#### *2.2. Continuous K-Nearest-Neighbor Query in Road Networks*

With the rapid development of moving devices, the motion states of moving objects in space can be monitored in real time. We are no longer satisfied with KNN query in static environments. The KNN query in dynamic environments has attracted more attention and CKNN query has become a research hotspot. The query results of CKNN query processing are computed continuously in the specified period by moving users; thus, the process is highly complicated.

Tao et al. [1] designed a CKNN query processing method for a line edge. This query processing method uses R-tree as the underlying data structure and the KNN query results of a query object on a line can be obtained via a single calculation; however, this method can only query on a pre-defined line. The authors in [2,3] solved the CKNN query for a moving query location on the query path. Cho et al. [2] employed the unique continuous search algorithm which divides the query path into effective intervals by considering the distance between the object and the query object. Within each interval, regardless of where the query moves, the KNN object is the same. Kolahdouzan et al. [3]

introduced the IE/UBA algorithm for identifying CKNN candidates and divided paths into several sub-paths, each of which has the same KNN result set. The objects that are queried in [2,3] are static on the road network; only the query object can move on the path. Since the object that is being queried is moving, Shahabi et al. [13] developed a Road Network Embedding (RNE) technique, which transforms the road network into a higher-dimensional space, retrieves approximate results, and mainly deals with CKNN queries of moving objects on the road network. Mouratidis et al. [14] proposed the incremental monitoring algorithm (IMA) and group monitoring algorithm (GMA) algorithms for updating the results when updates from objects and edges falling in the expansion tree. Demiryurek et al. [15] extended the method for solving the same problem in [14]. The proposed ER-CKNN algorithm avoids blindly expanding the road network when searching for candidate objects and selects candidate objects based on the Euclidean distance between each object and the query object. Huang et al. [16] developed a continuous *K-*nearest-neighbor query algorithm (CKNN) for moving objects in road networks. This algorithm uses a continuous detection method for moving objects in road networks, eliminates unqualified moving objects and identifies candidate objects, and evaluates candidate objects to determine whether they belong to the *K*-nearest neighbors of the query objects. Li et al. [17] introduced a continuous KNN (SCKNN) algorithm that is based on a moving state value. This algorithm considers the continuous *K*-nearest-neighbor queries of query object and the moving objects' moving states, identifies fewer candidate objects, and increases the computational e fficiency. Although the existing continuous *K*-nearest-neighbor query method considers the distance attributes and the motion state of the object, it does not consider the moving direction of the moving object relative to the query object; thus, it cannot accurately realize continuous *K*-nearest-neighbor query towards the query object.

#### *2.3. Direction-Based KNN Query*

In the spatial database query, researchers have introduced direction attributes and carried out some researches on direction-based spatial query technology. To improve the e fficiency of direction determination, an open shape-based strategy (OSS) model proposed by Liu et al. [4], which transforms the direction determination between geometric objects and query objects into a spatial topology analysis between open-shape and closed-geometric objects and improves the query e fficiency. Patroumpas [5] solved the range query problem of objects that are moving towards query objects in Euclidean space. To quickly determine whether the moving objects are moving towards the query object, a Polar-Tree is generated for each query object via polarization mapping with query objects as poles to e fficiently complete the range query and the objects in the result set are moving towards the query object. However, this method can only be applied to scenarios in which the query object is fixed and known and cannot handle random query requests. Nutanong et al. [6] studied visible *K-*nearest neighbor (VkNN) queries. The main problem is to identify the neighbors that can be seen by the query object; objects that are blocked by obstacles should be excluded. Gao et al. [18] studied the continuous visible *K-*nearest neighbor (CVkNN) queries, in which the query object can move along a straight edge and the algorithm returns the visible *K*-nearest object at any point on the edge. The main strategy of CVkNN is to perform only one single-point query for the whole edge instead of one query for each point of the edge. At the same time, an e fficient heuristic strategy is used to prune the interest point set and the obstacle set separately, which substantially improves the query e fficiency.

Li et al. [19] solved the *K*-nearest-neighbor query problem in the perspective direction of query object using direction-aware spatial keyword search. Given the location of the query object and the viewing angle range, the algorithm returns the *K*-nearest neighbors within the viewing angle range. View-field *K*-nearest-neighbor (VFkNN) query, which was proposed by Yi et al. [20], solves similar problems to direction-aware spatial keyword search; however, and VFkNN supports query processing of moving objects. This method uses a grid to index interest points, accesses the grid within the perspective, and directly excludes the grid outside the perspective, which substantially increases the query e fficiency. Because of the high applicability of the grid index to moving objects, the VFkNN

algorithm can not only process queries of static interest points but also fully support moving interest points. At the same time, they also solve the problem of continuous VFkNN query. Continuous VFkNN query is divided into two stages: an initial stage and an update stage. In the initial stage, the author implements two query algorithms, namely, naive search and sector search, which are used to process snapshot VFkNN queries. In the update stage, the sector surveillance algorithm, which is proposed in this paper, can e fficiently handle the updating of moving objects. Lee et al. [21–23] studied the nearest surrounder (NS) query. No longer is only the interest point that is nearest to the query object identified; multiple interest points are returned. These interest points are centered on the query object, distributed in various directions of query object and have a unique interest point in each direction. These interest points become the surroundings of the query object, that is to say, NS gives the query object a global perspective, from which the nearest-neighbor object to the query object in any direction can be identified. Guo [24] and others proposed Direction-Based Surrounder (DBS) queries for solving NS queries in Euclidean space and road network space and supporting continuous DBS query processing. Lee et al. [25] solved the *K*-nearest-neighbor query problem with the same direction as the query object by using a direction-constrained *K*-nearest-neighbor (DCkNN) query. Given the location and direction of query object, DCkNN can identify a point in the direction of the query object from the set of interest points if the di fference value does not exceed a specified threshold, which is denoted as θ. Chen et al. [26] determined the nearest-neighbor query of the path and retrieved the nearest-neighbor object along the path of the query object.

Although these KNN query methods consider the direction attribute, the solved problems do not involve road network constraints or continuous moving *K*-nearest-neighbor query. Therefore, we propose a direction-aware continuous moving *K*-nearest-neighbor query algorithm in road networks that is based on progressive network expansion. Our previous research has solved the problem of Direction-aware KNN queries for moving objects in a road network (DAKNN) [27]. In this paper, we focused on the problem of continuous queries and the e fficiency of continuous *K*-nearest-neighbor query for moving objects in road networks that are moving towards query objects.

#### **3. Data Structure and Problem Definition**

In this section, we present important concepts and data structures that are involved in directional-aware continuous moving *K*-nearest neighbor queries and formally define the problem that we attempt to solve in the paper.

## *3.1. Data Structure*

In our method, it is assumed that the speed of each object that is moving in road networks is constant. The data structures are designed as follows.

The road network is composed of nodes and edges, which is represented by an undirected weighted graph, namely, *G* (*N*, *E*, *W*), where *N* represents the set of nodes and stores all node information of the road network; *E* represents the set of edges and stores the edges of the road network; *W* represents the weight of the edge, where the weight that is set by the system is the length of the edge [27]. In addition, the two endpoints of a specified edge are denoted by *ns* and *ne*. *ns* represents the starting point and *ne* represents the ending point of the edge. For simplicity, we do not consider the direction of each edge; therefore, the starting points and ending points of the edges in the road network are represented by only two endpoints, which are arbitrarily specified.

The moving objects are a set *<sup>S</sup>*(*t*), where *p*(*t*) ∈ *S*(*t*) is a moving object *p* in the road network at timestamp *t*. The spatial information for each moving object *p*(*t*) in the road network, such as its location, speed, and movement direction at a timestamp, is available. Especially, when the moving object reaches a road network node, an adjacent edge of the node is randomly selected as its next traveling edge, the moving object will travel along the selected edge.

The query object refers to the spatial object that makes the query request, such as when a pedestrian makes the following query request: "At a certain period of time, find two taxis coming toward me." In this case, the pedestrian is the initiator of the query request, namely, the query object. The query object typically contains the following information: (1) the query coordinates; (2) the query time interval; (3) the value of *K*; and (4) the result set.

Given a range value *m*, starting from the query object, the node is gradually expanded until the distance from all adjacent nodes of the current node to query object is greater than the range value *m*. Expanded edges constitute the influencing edge, which is composed of triples (*ni*, *nj*, *dist*), where *dist* represents the distance between the *nj* node and *ni*.

In our algorithm, a data structure of memory is used to store edge, node and moving object information [27].


#### *3.2. Road Network Distance*

The distance between two objects on an undirected weighted graph is the length of the shortest path. If two objects are not reachable, the distance is ∞.

In this paper, we must determine the road network distances between moving objects at each timestamp in the time interval. The distance between the moving object *p* and the query object *q* is denoted as *NDq*,*p*(*t*). When the object arrives at the network node, the network distance *NDq*,*p*(*t*) must be recalculated. If the query object *q* and the moving object *p* are specified, the distance between them in any time interval can be calculated. According to the edge of the moving object and the location of the query object, there are two cases.

In the first case, the query object and the moving object move on the same edge, namely *e*, and the distance *NDq*,*<sup>p</sup>* is calculated as follows:

$$\text{ND}\_{q,p(t)} = \left| (q.\text{distTos} + q.\text{signS} \ast (t - q.\text{tu})) - (p.\text{distTos} + p.\text{signS} \ast (t - p.\text{tu})) \right| \tag{1}$$

In an undirected weighted graph, the starting and ending nodes are arbitrarily specified on each edge. If the object moves towards the ending node, *signS* indicates the positive speed; otherwise, *signS* indicates the negative speed. *q*.*signS* and *q*.*tu* represent the marking speed and the last update time, respectively, of the query object. Similarly, *p*.*signS* and *p*.*tu* represent the marking speed and the last update time, respectively, of the moving object. *q*.*distTos* represents the distance between the query object and the starting point of the edge that is located by the query object. When an object arrives at the road network node, the distance between the object and the query object must be recalculated.

In the second case, query object *q* and the moving object *p* move on different edges, e.g., edge *ei*(*nis*, *nie*) and edge *ej*(*njs*, *nje*). For simplicity, in this paper, we pre-calculate the shortest distance between the nodes in the road network and use *SP*(*ni*, *nj*) to represent the shortest path between nodes *ni* and *nj*. In this case, the distance between objects can be calculated by the shortest path between nodes. The shortest paths between the starting nodes and the ending nodes of the two moving objects are denoted as *SP*(*nis*, *njs*), *SP*(*nis*, *nje*), *SP*(*nie*, *njs*), and *SP*(*nie*, *nje*). Therefore, the distance between the moving object and the query object at timestamp *t* is composed of the following three parts: (1) the distance between the query object and node *nis* or *nie*; (2) the shortest path between the

*ND*1(*t*)

*ND*2(*t*)

nodes; and (3) the distance between the moving object and node *njs* or *nje*. The road network distance can be expressed as:

$$\text{ND}\_{q, p(t)} = \min\{\text{ND1}\_{(t)}, \text{ND2}\_{(t)}, \text{ND3}\_{(t)}, \text{ND4}\_{(t)}\} \tag{2}$$

$$t = q.\text{distTos} + q.\text{signS}\*(t - t.\text{tu}) + \text{SP}(\text{nis}, \text{njs}) + p.\text{distTos} + p.\text{signS}\*(t - t.\text{tu})$$
 $t = q.\text{distTos} + q.\text{signS}\*(t - t.\text{tu}) + \text{SP}(\text{nis}, \text{nje}) + p.\text{distTos} - p.\text{signS}\*(t - t.\text{tu})$  $t = q.\text{distTos} - q.\text{signS}\*(t - t.\text{tu}) + \text{SP}(\text{nis}, \text{njs}) + p.\text{distTos} + p.\text{signS}\*(t - t.\text{tu})$ 

*ND*3(*t*) *ND*4(*t*) = *q*.*distToe* − *q*.*signS* ∗ (*t* − *<sup>t</sup>*.*tu*) + *SP*(*nis*, *njs*) + *p*.*distToe* − *p*.*signS* ∗ (*t* − *<sup>t</sup>*.*tu*)

where *p*.*distTos* represents the distance between the object and the starting point of the edge and *q*.*distToe* represents the distance between the object and the ending point of the edge. For example, in Figure 2, the paths are composed of edges *e*<sup>1</sup>(*n*1, *n*<sup>2</sup>) and *e*<sup>3</sup>(*n*2, *<sup>n</sup>*<sup>3</sup>). The moving object, namely, *p*3, and the query object, namely, *q*, are located at *e*<sup>3</sup>(*n*2, *n*<sup>3</sup>) and *e*<sup>1</sup>(*n*1, *<sup>n</sup>*<sup>2</sup>), respectively. The object *p*3 moves towards the starting point, namely, *n*2; hence, *p*3.*signS* is −1. The query object *q* moves towards the ending point, namely, *n*2; hence, *q*.*signS* is 1. The distance between them is *NDq*.*p*<sup>3</sup>(*t*) = 14 − 2*t*. We can find that when the moving object arrives at the node, its moving edge will change, and the four nodes involved in the distance calculation formula also change; thus, once the moving object reaches the node, its distance formula to the query point needs to be recalculated.

**Figure 2.** The local road network information.
