Monitoring Orientation of Moving Objects around Focal Points

1. Monitoring Orientation of Moving Objects around Focal Points Kostas Patroumpas and Timos Sellis School of Electrical and Computer Engineering National Technical University of Athens, Hellas SSTD’09

2. Management of Moving Objects • Proliferation of location-enabled mobile devices • mobile phones, PDA’s, GPS, … for trackingmoving objects: people, vehicles, animals … • Continuous user requests require real-time results • e.g., range or k-NN search, skyline computation • againstdata streamsof massive positional updates • Less attention to evolving trajectories or motion patterns • Holistic approach: aggregate headings in the entire area of interest? • Volatile variety of orientations (e.g., caused by sudden turns) • Cannot easily capture distribution and density of objects • FOCUS:study movement from anavigational perspective • Exploit heading (a.k.a. bearing) of each moving object • Orientation expressed as angle w.r.t. a known direction (e.g., North) SSTD’09

3. Monitoring Object Orientations • Examine orientations w.r.t. fixed focal points • Sites of interest: terminal stations, sporting venues, traffic junctions • Detect orientation trends online • Divergence vs. convergence • Assumptions : • Consistent object movement • Synchronized positional updates • Orientation-based queries • Continuous response for a given: • direction of interest • distance from focal site • Much like a radar system • Identify frequently-followed directions at progressively finer resolution SSTD’09

4. Our Approach • Adopt a collaborative scheme • Objects have minimal processing capabilities • Each object retains its recent positions and updates its heading • Objects communicate with server • Only upon significant deviations at their course or after server request • A set of focal points allocated in the monitored area • For each site, server maintains current distribution of headings • Evaluation of orientation-based queries • Novel indexing scheme: PolarTree • Organize detection range of each site as a hierarchical tree • Adjust sectors of interest at gradually refined extents • Assign influencing objects to tree nodes • Support multiple queries with a common focal site • Examine trajectory movements over the recent past (sliding windows) SSTD’09

5. Related Work • Spatiotemporal databases • Object-based directional relationships (Liu et al.[TKDE’03]) • Coordinate-based vs. trajectory-based queries(Pfoser et al [VLDB’00]) • Navigational queries: speed, heading, traveled distance,… • Dead-reckoning policies • Uncertainty thresholds at velocity vectors (Wolfson et al.[DPDB’99]) • Indexing with motion-sensitive bounding box (Gedik et al. [TKDE’06]) • Threshold-guided detection of movement changes ([SSDBM’06]) • Continuous monitoring of moving objects • Range(Gedik & Liu[EDBT’04]) or k-NN(Mouratidis et al.[SIGMOD’05]) • …but not explicitly handling object headings and related queries • Monitoring object orientations ? • Not yet studied from a streaming perspective SSTD’09

6. Outline • Preliminaries • Focal scopes, focal distances and object headings • Polar mapping of objects • Introducing the PolarTree • Index structure • Operations (insert, delete, search, …) • Properties • Processing streaming orientations of moving objects • System model • Continuous monitoring of object headings • Examining trajectory headings • Experimental Evaluation • Concluding Remarks SSTD’09

7. Focal Points • Assume a finite set of nfocal points • Stationary sites on 2-d Euclidean space • No particular allocation of sites, application-dependent • Focal scope for each site fi • Max range for detecting moving objects • A circle of given radius Ri around fi • Focal scopes may overlap • Focal distance of a moving object o • Euclidean distance di = || o – fi || • if o is within scope of site fi • Objects may influence multiple sites • Different focal distances from each site SSTD’09

8. Object Headings • Location-aware objects • Move freely, but follow consistent courses • Retain current position<x, y, t> +velocity • Object heading • signifies direction of movement (navigation) • w.r.t. a previous position or anchor point • depends on each object’s movement • As angleθw.r.t. to a fixed direction • Azimuth: angle with North axis • Use slopes to measure headings • Slope θ of vector connecting two object positions • counterclockwise from positive x-axis • Variant atan2 maintains direction of the vector SSTD’09

9. Polar Mapping of Objects Consider objects within scope of a site f • Create a polar circle for site f with • Pole: fixed site location (centerf ) • Scope: circle of radius R • Object o abstracted to a point (d, θ) • Distance d : focal distance of o from site f • Angleθ: object heading w.r.t. x-axis • NOT the usual transformation • from Cartesian into polar coordinates • Specifying orientation-based queries • Each query refers to a single site f • Search for qualifying objects: • within range [θ1, θ2) specified for headings • within range (d1, d2] of focal distances from f SSTD’09

10. The PolarTree Index • Main-memory access method • Indexes object orientations • Maintained for a single focal site • Recursive subdivision of focal scope • into non-overlapping polar sectors A binary tree structure • Each node A is a polar sector with: • a distance range (radiusr ) • an angular range (bisectorφ) • After splitting a node A • Half of its area equally shared by its children • Catalogue of entries in each node (excl. root) • objects within distance and angular range • Data stored in leaves and internal nodes SSTD’09

11. PolarTree Operations • Inherently dynamic index supporting: • SearchSector (f, d,θ) • Start from root and descend following a single path • Insert (f, o) • Assign object o to a suitable sector of the PolarTree of f • Bisect (s) • Overflowing (> M) leaf sector s gets subdivided • Delete (f, o) • Remove existing object o from a sector of the tree • Merge (s) • Collapse children leaves of s due to underflow (< m) • Update (f, o,θ,d,θ',d') • Revise heading and focal distance of object o  may change sector ! • RangeSearch (f,d1 ,d2 ,θ1 ,θ2) • Recursive depth-first search to report qualifying headings SSTD’09

12. Bisection Operation • Check overflows for leaf nodes only • Partition existing sector into: • Two circular sectors assigned to new children leaves • Remaining truncated sector assigned to the initial node  internal node SSTD’09

13. Merge Operation • Collapse two sibling leaves • Append entries to their parent node • Underflow : total count of entries at the three nodes ≤m • Parent node becomes a leaf • Collapsing may propagate further up in the tree SSTD’09

14. PolarTree Properties • Tree is usually unbalanced: • Leaf nodes may appear at any level • Structure depends on distribution of object locations and headings • Internal nodes may occasionally be left empty • Nodes may be unevenly filled • Degenerate case: a root with two empty leaves • Node entries • Tuples of the form < oid, addrH, fDistance, sign > • sign (+ / –) : converging to / diverging from focal point f • Actual headings and locations maintained in another structure • Repetitive pattern of bisections • Decompose scope into sectors of progressively higher resolution • Intention: more detailed tracking closer to the focal point • Parameter M specifies the resolution and controls tree height SSTD’09

15. Continuous Monitoring of Headings • System model • A central server communicating with location-aware objects • Each object relays its status< oid, x, y, t, v, θ> to server: • at most every τ0time units • upon significant deviation on heading ( >dθ) or speed (>λ%) • after a server request • Server registers a set F of focal points • monitor movement in their scope • maintain a separatePolarTree for each site • keep synchronized object statuses in a common array H • evaluate orientation-based queries (each associated to a single site) • Processing at execution cycles • Updatephase process incoming statuses one by one • Refresh phase synchronize statuses for all remaining objects • predict new status assuming unchanged velocity SSTD’09

16. Handling of a Status Update • Identify affected focal sites • Object may fall within multiple scopes • Find earliest forecast from all affected sites send message to object • Use a regular grid to index scopes • hash object location • get candidate sites that need inspection • check sites influenced by previous status • Examine status for each candidate site f : • Entering within scope – Remain in scope • Exiting scope – Beyond scope • Compute deadline for next status update • Departure forecast • Expected time that object might get out of scope • Arrival forecast • Earliest time that object could cross focal scope SSTD’09

17. Trajectory Headings • Instead of monitoring instantaneous orientations • examine heading over recent trajectory portions • Sliding windows of w time units • Each object derives its heading • from the two extreme locations within window • Server-side processing unchanged • Windows specified for each focal point • Applied on all objects within a given scope • Objects may participate in multiple windows • a single status update  varying headings • Server computes trajectory headings • from available statuses within recent w units • server maintains recent movement history • Reflects orientation trends for objects SSTD’09

18. Experimental Evaluation • Experimental setting • Synthetic datasets emulating movement of vehicles • Objects moving at diverse speeds along the road network of Athens • Basic simulation parameters: • Number of objects P= 10k, 20k, 50k,100k • Number of focal sites n = 100, 200, 500, 1000 • Focal radius R=0.5, 1, 2, 3, 4 km • Leaf capacity M= 100, 200, 500 items • Heading deviation dθ = 10ο, 20ο, 30ο • Speed deviation λ = 0.05, 0.1, 0.2 • Reportingthresholdτ0 = 30time units • Trajectories produced by running shortest path between pairs of randomly chosen network nodes • Samples at 200 concurrent timestamps along each route • Diverse sets of focal points at various radii R SSTD’09

19. Experimental Results • Grid cell size for indexing focal scopes • Measure the per cycle cost for update + refresh phases • Grid partitioning more useful for larger scopes • Higher degree of overlaps among multiple focal scopes • For subsequent experiments, a 100x100 grid was chosen • Server cost mainly depends on object count • Linear in the number of sites, as PolarTrees are maintained separately SSTD’09

20. Experimental Results • Execution cost escalates for larger scopes • Objects may influence multiple sites with intersecting scopes • Increased overhead from frequent forecasting & extra status updates • Processing time per phase • Handling new updates is more costly than refreshing existing statuses • …particularly for wider scopes • Performance sensitive to scope sizes, but chiefly on mutual overlaps SSTD’09

21. Experimental Results • Message savings for varying scope sizes • Measure % statuses not relayed to the server • For smaller radii, great reduction in communication cost • For larger radii, insignificant gains due to frequent status reports • objects influence diverse sites as they move • Leverage scope with monitoring resolution (leaf capacity M) • By increasing M, the tree gets shorter and has wider sectors SSTD’09

22. Experimental Results • Maintenance cost of trajectory headings is affordable • almost independent of window extent, but proportional to scope size • Assessing quality of orientation-based queries • Comparison: approximate answers from PolarTreevs. exhaustive evaluation • Less than 5% of objects may not be reported within scope • Objects misallocateddue to small variations in their assumed heading • Overall, a reliable insight on actual distribution of headings SSTD’09

23. Conclusions • PolarTree: novel spatiotemporal access method • continuous monitoring of movement orientations • adaptable subdivisions in sectors around focal points of interest • Stream processing framework • Offer real-time response to multiple orientation-based queries • Avoid unnecessary updates from objects • Provide a reliable approximation on distribution of object headings • Possible future extensions: • Variant tree structure • Data-driven subdivision in dissimilar sectors • Sensitive to observed density of object headings • Distributed mechanism for processing orientations • Designate base stations instead of a central server • Increased scalability and robustness SSTD’09

24. Monitoring Orientation of Moving Objects around Focal Points Thank you! SSTD’09