Efficient Maintenance of Continuous Queries for Trajectories

Abstract

We address the problem of optimizing the maintenance of continuous queries in Moving Objects Databases, when a set of pending continuous queries need to be reevaluated as a result of bulk updates to the trajectories of moving objects. Such bulk updates may happen when traffic abnormalities, e.g., accidents or road works, affect a subset of trajectories in the corresponding regions, throughout the duration of these abnormalities. The updates to the trajectories may in turn affect the correctness of the answer sets for the pending continuous queries in much larger geographic areas. We present a comprehensive set of techniques, both static and dynamic, for improving the performance of reevaluating the continuous queries in response to the bulk updates. The static techniques correspond to specifying the values for the various semantic dimensions of trigger execution. The dynamic techniques include an in-memory shared reevaluation algorithm, extending query indexing to queries described by trajectories and query reevaluation ordering based on space-filling curves. We have completely implemented our system prototype on top of an existing Object-Relational Database Management System, Oracle 9i, and conducted extensive experimental evaluations using realistic data sets to demonstrate the validity of our approach.

Exploring movement-similarity analysis of moving objects

“…In another work, Euclidean time-Uniform distance has been introduced in optimal or approximate matching between trajectories under translation and rotation [27]. On a similar attempt an extension of Frèchet distance has been applied to support trajectory similarity join [8].…”

BORA: Routing and Aggregation for Distributed Processing of Spatio-Temporal Range Queries

“…The server has a map available, describing the graph of the road-segments, as well as the information about the velocity-distribution patterns on each segment in a given time-interval. Given the starting and end-location information, the server uses a dynamic variant of the Dijkstra's algorithm [4] in which the cost of the edges in a graph (road segments) depend on the time, in order to generate a traveltime optimal trajectory, which is subsequently transmitted back to the user [24,3]. In our settings, each MOD manages only the portion of a given object's trajectory which is in its cell -the region of coverage of the BS that can communicate with the object during the time it is inside the cell.…”

“…Assume that C 4,4 is done aggregating LA(C 4,4 ) with the data along the path starting at C 7,1 , before C 4,5 is ready for a transmission. Then, C 3,5 will aggregate the result received from C 4,4 with LA(C 3,5 ) and transmit it to the root. Subsequently, C 3,5 will forward the aggregated result that it receives from C 4,5 to the root.…”

“…Subsequently, C 3,5 will forward the aggregated result that it receives from C 4,5 to the root. In a similar manner, the subtree rooted at C 5,4 will generate the data that will be forwarded to the root via C 4,4 → C 3,5 . At the end, the root C 2,5 will have to merge 8 different data sets (albeit, of a larger size) sorted by the OIDs of its elements, instead of the original 24 data sets that would end up being transmitted by the naive approach.…”

“…The answers which are obtained by the individual MOD servers are relevant only for their cells and the query region may span over multiple cells. Moreover, the trajectories in the answer-set may also span over multiple cells throughout the time-interval of interest for the query, as illustrated by o 3 and o 7 in Figure 1. In such cases, if the final recipient is expected to do the aggregations of the multiple time-intervals per individual OID, it may experience too large workload, especially if the answer is to be sorted by the OIDs.…”