CAT: Correct Answers of Continuous Queries using Triggers Goce Trajcevski,Peter Scheuermann Ouri Wolfson, Nimesh Nedungadi Dept. of ECE Dept. of CS Northwestern University University of Illinois at Chicago Evanston, IL 60208 Chicago, IL 60607 {goce,peters@ece.northwestern.edu} {wolfson,nnedunga@cs.uic.edu}

In order to position the work properly, let me first present this slide which shows the GUI part of the DOMINO system, which is a database for modeling and tracking moving objects. What the slide shows is the trajectories (routes and timing informations), of three moving objects traveling in the Cook County – Chicago, along with a region of interest for the query “Which object will be inside the region sometime between 12:15 and 12:30”. Clearly, this is an example of a continuous query which spans over a time interval. Now, if the trajectory corresponds to a future motion plan of a given object and the continuous query pertains to some future time interval, the motion plan of the object may be subject to changes due to unforeseen traffic variations which, in turn, may affect the correctness of the answer to the query posed to the system.

Typically, a trajectory is represented as a polyline, which is, a sequence of points in the 3D space, corresponding to the (location(X,Y),time) information and in between the points the object is assumed to move along a straight line and with a constant speed. The slide shows the trajectories and their 2D projections (routes) for three moving objects. Assume that the object o1, whose trajectory is Tr1 issued the query Q1, as illustrated on the slide, at 4PM. Further, assume that at 4:30PM an unexpected road-work starts on the road-segment AB, which should last for a few hours. Clearly, this may affect the (future-time) portions of some of the trajectories which will need to be correspondingly updated. In the situation illustrated, the trajectory Tr2 need not be updated because it passed through the segment AB before the road-work started. The trajectory Tr3 also needs no update because it does not go through the affected road-segment. However, the trajectory Tr1 will enter the affected segment after 4:30PM (at 4:35PM) and it will move slower than predicted when it was being generated based on the available information about the speed profiles distribution. Due to the slow-down, it will leave the affected segment at 5:05PM, instead of 4:50PM. Note how the rest of the updated Tr1 (after 5:05PM) has a same “slope” as its earlier version, except it is translated along the time axis. The key observation, which is the main motivation for this work is that if a trajectory is modified AND it has posed a continuous query, then the answer to the query should be re-evaluated automatically (and transmitted to the user who posed it), without any need for the user to re-ask the query. This can be done by generating a trigger whenever the system receives a continuous query.

In the previous slide we saw that due to the traffic perturbations, the trajectory Tr1 of object o1 had to be updated. The impact of the slow-down effect of Tr1 to Q1 is that some motels that object o1 would have passed by before 7:00PM may now fall in the time-interval of interest. Similarly, o1 may not be able to reach the desired proximity of some motels that were originally part of the answer to Q1, before 8:00PM. This slide illustrates the basic building blocks of the CAT system in the context of this particular example. It shows the information that the current version of the system maintains (buildings of interest, Moving Objects Table, and the other needed data). However, in the heart of the CAT system are two types of triggers, as shown. The first type of trigger TRIGGER1 is enabled whenever a traffic abnormality is reported to the system. Its action part detects the trajectories that can be affected by the abnormality (spatio-temporal query) and updates them. The second type of the trigger, TRIGGER2, is enabled by an update to a particular trajectory. It’s condition part checks if the object whose trajectory is updated has posed any (pending) continuous query, and its action part re-evaluates the answer to the query. ****************************** IN SUMMARY, CAT is not intended to be a stand-alone product, but it is to be integrated in the DOMINO system (and like). At its current implementation, its front-end is a simple Java-based GUI which allows the user to enter the object_id, query start_time and end_time, and the distance for the locations of interest along the route of the object_id. Once queries are entered, the user can enter the sequence of route end-points (from the available electronic maps) end the percentage value of the decrease of the speed along the selected route segments. Upon this, the system will simply display back the new answers to the pending continuous queries which were affected by the simulated traffic jam. ****************