<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE article PUBLIC "-//NLM//DTD Journal Publishing DTD v2.3 20070202//EN" "journalpublishing.dtd">
<article xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink" article-type="research-article">
<front>
<journal-meta>
<journal-id journal-id-type="publisher-id">Front. Big Data</journal-id>
<journal-title>Frontiers in Big Data</journal-title>
<abbrev-journal-title abbrev-type="pubmed">Front. Big Data</abbrev-journal-title>
<issn pub-type="epub">2624-909X</issn>
<publisher>
<publisher-name>Frontiers Media S.A.</publisher-name>
</publisher>
</journal-meta>
<article-meta>
<article-id pub-id-type="doi">10.3389/fdata.2020.00020</article-id>
<article-categories>
<subj-group subj-group-type="heading">
<subject>Big Data</subject>
<subj-group>
<subject>Original Research</subject>
</subj-group>
</subj-group>
</article-categories>
<title-group>
<article-title>Conditional MaxRS Query for Evolving Spatial Data</article-title>
</title-group>
<contrib-group>
<contrib contrib-type="author" corresp="yes">
<name><surname>Mas-ud Hussain</surname> <given-names>Muhammed</given-names></name>
<xref ref-type="aff" rid="aff1"><sup>1</sup></xref>
<xref ref-type="corresp" rid="c001"><sup>&#x0002A;</sup></xref>
<uri xlink:href="http://loop.frontiersin.org/people/735726/overview"/>
</contrib>
<contrib contrib-type="author">
<name><surname>Mostafiz</surname> <given-names>Mir Imtiaz</given-names></name>
<xref ref-type="aff" rid="aff2"><sup>2</sup></xref>
<uri xlink:href="http://loop.frontiersin.org/people/866802/overview"/>
</contrib>
<contrib contrib-type="author">
<name><surname>Mahmud</surname> <given-names>S. M. Farabi</given-names></name>
<xref ref-type="aff" rid="aff2"><sup>2</sup></xref>
<uri xlink:href="http://loop.frontiersin.org/people/993678/overview"/>
</contrib>
<contrib contrib-type="author">
<name><surname>Trajcevski</surname> <given-names>Goce</given-names></name>
<xref ref-type="aff" rid="aff3"><sup>3</sup></xref>
<uri xlink:href="http://loop.frontiersin.org/people/944927/overview"/>
</contrib>
<contrib contrib-type="author">
<name><surname>Eunus Ali</surname> <given-names>Mohammed</given-names></name>
<xref ref-type="aff" rid="aff2"><sup>2</sup></xref>
<uri xlink:href="http://loop.frontiersin.org/people/944152/overview"/>
</contrib>
</contrib-group>
<aff id="aff1"><sup>1</sup><institution>Department of Electrical Engineering and Computer Science, Northwestern University</institution>, <addr-line>Evanston, IL</addr-line>, <country>United States</country></aff>
<aff id="aff2"><sup>2</sup><institution>Department of Computer Science and Engineering, Bangladesh University of Engineering and Technology</institution>, <addr-line>Dhaka</addr-line>, <country>Bangladesh</country></aff>
<aff id="aff3"><sup>3</sup><institution>Department of Electrical and Computer Engineering, Iowa State University</institution>, <addr-line>Ames, IA</addr-line>, <country>United States</country></aff>
<author-notes>
<fn fn-type="edited-by"><p>Edited by: Liyue Fan, University at Albany, United States</p></fn>
<fn fn-type="edited-by"><p>Reviewed by: Budhitama Subagdja, Nanyang Technological University, Singapore; Kyoung-Sook Kim, National Institute of Advanced Industrial Science and Technology, Japan</p></fn>
<corresp id="c001">&#x0002A;Correspondence: Muhammed Mas-ud Hussain <email>mas-ud&#x00040;u.northwestern.edu</email></corresp>
<fn fn-type="other" id="fn001"><p>This article was submitted to Data Mining and Management, a section of the journal Frontiers in Big Data</p></fn></author-notes>
<pub-date pub-type="epub">
<day>19</day>
<month>06</month>
<year>2020</year>
</pub-date>
<pub-date pub-type="collection">
<year>2020</year>
</pub-date>
<volume>3</volume>
<elocation-id>20</elocation-id>
<history>
<date date-type="received">
<day>10</day>
<month>12</month>
<year>2020</year>
</date>
<date date-type="accepted">
<day>11</day>
<month>05</month>
<year>2020</year>
</date>
</history>
<permissions>
<copyright-statement>Copyright &#x000A9; 2020 Mas-ud Hussain, Mostafiz, Mahmud, Trajcevski and Eunus Ali.</copyright-statement>
<copyright-year>2020</copyright-year>
<copyright-holder>Mas-ud Hussain, Mostafiz, Mahmud, Trajcevski and Eunus Ali</copyright-holder>
<license xlink:href="http://creativecommons.org/licenses/by/4.0/"><p>This is an open-access article distributed under the terms of the Creative Commons Attribution License (CC BY). The use, distribution or reproduction in other forums is permitted, provided the original author(s) and the copyright owner(s) are credited and that the original publication in this journal is cited, in accordance with accepted academic practice. No use, distribution or reproduction is permitted which does not comply with these terms.</p></license>
</permissions>
<abstract><p>We address the problem of maintaining the correct answer-sets to a novel query&#x02014;<italic>Conditional</italic> Maximizing Range-Sum (C-MaxRS)&#x02014;for spatial data. Given a set of 2D point objects, possibly with associated weights, the traditional MaxRS problem determines an optimal placement for an axes-parallel rectangle <italic>r</italic> so that the number&#x02014;or, the weighted sum&#x02014;of the objects in its interior is maximized. The peculiarities of C-MaxRS is that in many practical settings, the objects from a particular set&#x02014;e.g., restaurants&#x02014;can be of different types&#x02014;e.g., fast-food, Asian, etc. The C-MaxRS problem deals with maximizing the overall sum&#x02014;however, it also incorporates class-based constraints, i.e., placement of <italic>r</italic> such that a lower bound on the count/weighted-sum of objects of interests from particular classes is ensured. We first propose an efficient algorithm to handle the static C-MaxRS query and then extend the solution to handle dynamic settings, where new data may be inserted or some of the existing data deleted. Subsequently we focus on the specific case of bulk-updates, which is common in many applications&#x02014;i.e., multiple data points being simultaneously inserted or deleted. We show that dealing with events one by one is not efficient when processing bulk updates and present a novel technique to cater to such scenarios, by creating an index over the bursty data on-the-fly and processing the collection of events in an aggregate manner. Our experiments over datasets of up to 100,000 objects show that the proposed solutions provide significant efficiency benefits over the na&#x000EF;ve approaches.</p></abstract>
<kwd-group>
<kwd>maximizing range sum query</kwd>
<kwd>constrained query processing</kwd>
<kwd>conditional MaxRS</kwd>
<kwd>C-MaxRS</kwd>
<kwd>bulk data updates</kwd>
<kwd>bursty streams</kwd>
<kwd>spatial data streams</kwd>
<kwd>spatial indexing</kwd>
</kwd-group>
<contract-num rid="cn001">CNS 1646107</contract-num>
<contract-num rid="cn001">III 1213038</contract-num>
<contract-sponsor id="cn001">National Science Foundation<named-content content-type="fundref-id">10.13039/100000001</named-content></contract-sponsor>
<counts>
<fig-count count="14"/>
<table-count count="8"/>
<equation-count count="10"/>
<ref-count count="46"/>
<page-count count="26"/>
<word-count count="17015"/>
</counts>
</article-meta>
</front>
<body>
<sec sec-type="intro" id="s1">
<title>1. Introduction</title>
<p>Rapid advances in accuracy and miniaturization of location-aware devices, such as GPS-enabled smartphones, and increased use of social networks services (e.g., check-in updates) have enabled a generation of large volumes of spatial data(e.g., Manyika et al., <xref ref-type="bibr" rid="B26">2011</xref>). In addition to the <italic>(location, time)</italic> values, that data is often associated with other contextual attributes. Numerous methods for effective processing of various queries of interest in such settings&#x02014;e.g., range, (<italic>k</italic>) nearest neighbor, reverse nearest-neighbor, skyline, etc.&#x02014;have been proposed in the literature(cf., Zhang et al., <xref ref-type="bibr" rid="B43">2003</xref>; Zhou et al., <xref ref-type="bibr" rid="B46">2011</xref>; Issa and Damiani, <xref ref-type="bibr" rid="B19">2016</xref>).</p>
<p>One particular spatial query that has received recent attention is the, so called, <italic>Maximizing Range-Sum (MaxRS)</italic> (Choi et al., <xref ref-type="bibr" rid="B8">2014</xref>), which can be specified as follows: given a set of weighted spatial-point objects <italic>O</italic> and a rectangle <italic>r</italic> with fixed dimensions (i.e., <italic>a</italic> &#x000D7; <italic>b</italic>), MaxRS retrieves a location of <italic>r</italic> that maximizes the sum of the weights of the objects in its interior. Due to diverse applications of interest, variants of MaxRS (e.g., Phan et al., <xref ref-type="bibr" rid="B34">2014</xref>; Amagata and Hara, <xref ref-type="bibr" rid="B2">2016</xref>; Feng et al., <xref ref-type="bibr" rid="B13">2016</xref>; Hussain et al., <xref ref-type="bibr" rid="B15">2017a</xref>,<xref ref-type="bibr" rid="B16">b</xref>; Wongse-ammat et al., <xref ref-type="bibr" rid="B42">2017</xref>; Liu et al., <xref ref-type="bibr" rid="B25">2019</xref>, etc.) have been recently addressed by the spatial database and sensor network communities.</p>
<p>What motivates this work is the observation that in many practical scenarios, the members of the given set <italic>O</italic> of objects can be of different types, e.g., if <italic>O</italic> is a set of restaurants, then a given <italic>o</italic><sub><italic>i</italic></sub> &#x02208; <italic>O</italic> can belong to a different class from among fast-food, Asian, French, etc. Similarly, a vehicle can be a car, a truck, a motorcycle, and so on. In the settings where data can be classified in different (sub)categories, there might be class-based participation constraints when querying for the optimum region&#x02014;i.e., a desired/minimum number of objects from particular classes inside <italic>r</italic>. However, due to updates in spatial databases&#x02014;i.e., objects appearing and disappearing at different times&#x02014;one needs to accommodate such dynamics too. Following two examples illustrate the problem:</p>
<p><italic>Example 1:</italic> Consider a campaign scenario where a mobile headquarters has limited amount of staff and needs to be positioned for a period of time in a particular area. The US Census Bureau has multiple surveys on geographic distributions of income categories<xref ref-type="fn" rid="fn0001"><sup>1</sup></xref> and, for effective outreach purposes, the campaign managers would like to ensure that within the limited reachability from the headquarters, the staff has covered a maximum amount of voters&#x02014;with the constraint that a minimum amount of representative from different categories are included. This would correspond to the following query:</p>
<p><bold>Q1</bold>: &#x0201C;<italic>What should be the position of the headquarters at time</italic> <italic>t</italic> <italic>so that at least</italic> &#x003BA;<sub><italic>i</italic></sub> <italic>residents from each income Category</italic><sub><italic>i</italic></sub> <italic>can be reached, while maximizing the number of voters reached, during that campaign date.&#x0201D;</italic></p>
<p><italic>Example 2:</italic> Consider the scenario of X&#x00027;s <bold>Loon Project</bold><xref ref-type="fn" rid="fn0002"><sup>2</sup></xref>, where there are different types of users&#x02014;premium (class A), regular (class B), and free (class C), and users can disconnect or reconnect anytime. In this context, consider the following query:</p>
<p><bold>Q2</bold>: &#x0201C;<italic>What should be the position of an Internet-providing balloon at time</italic> <italic>t</italic> <italic>to ensure that there are at least</italic> &#x00398;<sub><italic>i</italic></sub> <italic>users from each Class</italic><sub><italic>i</italic></sub> <italic>inside the balloon-coverage and the number of users in its coverage is maximized?&#x0201D;</italic>.</p>
<p>It is not hard to adapt <bold>Q1</bold> and <bold>Q2</bold> to many other applications settings:&#x02014;environmental tracking (e.g., optimizing a range-bounded continuous monitoring of different herds of animals with both highest density and diversity inside the region);&#x02014;traffic monitoring (e.g., detecting ranges with densest trucks);&#x02014;video-games (e.g., determining a position of maximal coverage in dynamic scenarios involving change of locations of players and different constraints).</p>
<p>We call such queries <italic>Conditional Maximizing Range-Sum</italic> (C-MaxRS) queries, a variant of the traditional MaxRS problem. For dynamic settings, where the objects can be inserted and/or deleted, we have <italic>Conditional Maximizing Range-Sum with Data Updates</italic> (C-MaxRS-DU) query.</p>
<p>An illustration for C-MaxRS query in a setting of 7 users grouped into 3 classes (i.e., A, B, and C), and with a query rectangle size <italic>a</italic> &#x000D7; <italic>b</italic> (i.e., height <italic>a</italic> and width <italic>b</italic>) is shown in <xref ref-type="fig" rid="F1">Figure 1</xref>. Assume that the participation constraint is that <italic>the positioning of</italic> <italic>r</italic> <italic>must be such that at least 1 user is included from each of the classes A, B, and C, respectively</italic>. There are two rectangles <italic>r</italic><sub>1</sub> and <italic>r</italic><sub>2</sub>, with dimension <italic>a</italic> &#x000D7; <italic>b</italic>, that are candidates for the solution. However, upon closer inspection it turns out that although <italic>r</italic><sub>2</sub> contains most users (corresponding to the traditional MaxRS solution), it is <italic>r</italic><sub>1</sub> that is the sought-for solution for the C-MaxRS problem. Namely, <italic>r</italic><sub>2</sub> does not satisfy the participation constraints (see <xref ref-type="fig" rid="F1">Figure 1i</xref>).</p>
<fig id="F1" position="float">
<label>Figure 1</label>
<caption><p>An example of C-MaxRS problem in spatial data updates at time <bold>(i)</bold> <italic>t</italic><sub>1</sub> and <bold>(ii)</bold> <italic>t</italic><sub>2</sub>.</p></caption>
<graphic xlink:href="fdata-03-00020-g0001.tif"/>
</fig>
<p>Now, suppose that at time <italic>t</italic><sub>2</sub>, user <italic>o</italic><sub>6</sub> disconnects and a new user <italic>o</italic><sub>8</sub> joins the system. Then the C-MaxRS solution will need to be changed to <italic>r</italic><sub>2</sub> from <italic>r</italic><sub>1</sub> (see <xref ref-type="fig" rid="F1">Figure 1ii</xref>).</p>
<p>Our key idea for efficient C-MaxRS processing is to partition the space and apply effective pruning rules for each partition to quickly update the result(s). The basic processing scheme follows the technique of spatial subdivision from Feng et al. (<xref ref-type="bibr" rid="B13">2016</xref>), dividing the space into a certain number of slices, whose local maximum points construct the candidate solution point set. In each slice, the subspace was divided into slabs which helps in reducing the solution space. To handle dynamic data stream scenarios, i.e., appearances and disappearances of objects, we propose two algorithms, <italic>C-MaxRS</italic><sup>&#x0002B;</sup> and <italic>C-MaxRS</italic><sup>&#x02212;</sup>, respectively, which works as a backbone for solving the constrained maximum range sum queries in the dynamic insertions/deletions settings (C-MaxRS-DU). Our novelty is in incorporating heuristics to reduce redundant calculations for the newly appeared or disappeared points, relying on two trees: a quadtree and a balanced binary search tree. Experiments over a wide range of parameters show that our approach outperforms the baseline algorithm by a factor of three to four, for both Gaussian and Uniform distribution of datasets.</p>
<p>The above idea for the C-MaxRS-DU algorithm takes an event-based approach, in the sense that C-MaxRS is evaluated (maintained) every time an event occurs, i.e., new point appears (<italic>e</italic><sup>&#x0002B;</sup>) or an old point disappears (<italic>e</italic><sup>&#x02212;</sup>). This approach works efficiently when events are distributed fairly uniformly in the temporal domain and occur at different time instants that are enough apart for reevaluation to complete. However, the recent technological advancements and the availability of hand-held devices have enabled a large increase (or decrease) of the number of active/mobile users in multitude of location-aware applications in relatively short time-spans. In the context of Examples 1 and 2, this would correspond to the following scenarios:</p>
<p><italic>Example 1</italic>: If the area involves businesses, then one would want to exploit the fact that many individuals may: (a) come (or leave) their place of work in the morning (or evening); (b) enter (or leave) restaurants during lunch-time; etc.</p>
<p><italic>Example 2</italic>: In the settings of X&#x00027;s Loon Project, there can be multiple users disconnecting from the service simultaneously (within a short time span), or new users may request connections.</p>
<p>There are many other scenarios from different domains&#x02014;e.g., Facebook has on average 2 billion daily active users&#x02014;approximately 23,000 users per second. These Facebook users can be divided into many groups (classes), and C-MaxRS can be used to retrieve the most interesting regions (with respect to particular requirements) among the active daily users. In this scenario, a large number of users can become online (<italic>e</italic><sup>&#x0002B;</sup>), or go offline (<italic>e</italic><sup>&#x02212;</sup>) at almost-same time instant. Similarly, flocks of different kinds of animals may be approaching the water/food source; the containment of the diseases across the population and regions may vary; etc.</p>
<p>To address the efficiency of processing in such settings, we propose a novel technique, namely <italic>C-MaxRS-Bursty</italic>. The key idea of our approach is as follows: instead of processing every single update, we assume that the update streams are gathered for a period of time. Then, we create a modified slice-based index for the entire batch of the new events, and then snap the new data over the existing slice structure in a single pass. Finally, we perform the pruning conditions for each slice only once in an aggregated manner. Experimental results show that C-MaxRS-Bursty outperforms our one-at-a-time approach, C-MaxRS-DU, by a speed-up factor of 5&#x02013;10.</p>
<p>The main contributions of this work can be summarized as follows:</p>
<list list-type="bullet">
<list-item><p>We formally define the C-MaxRS and C-MaxRS-DU problems (for both weighted and non-weighted versions) and provide a baseline solution using spatial subdivision (slices).</p></list-item>
<list-item><p>We extend the solution to deal with spatial data streams (appearing and disappearing objects) for which we utilize effective pruning schemes for both appearing and disappearing events, capitalizing on a self-balancing binary search tree (e.g., AVL-tree) and a quad-tree.</p></list-item>
<list-item><p>We propose an efficient methodology to handle bulk updates of data (i.e., updates with large data-volumes) along with the appropriate extensions of the data structures to cater to such settings.</p></list-item>
<list-item><p>We demonstrate the benefits of our proposed method via experiments over a large dataset. Experiments over a wide range of parameters show that our approaches outperform the baseline algorithms by a factor of three to four. Moreover, experiments with bulk updates demonstrate the effectiveness and scalability of C-MaxRS-Bursty over other techniques (e.g., C-MaxRS-DU).</p></list-item>
</list>
<p>A preliminary version of this paper has appeared in Mostafiz et al. (<xref ref-type="bibr" rid="B28">2017</xref>), where we focused on non-weighted version of the C-MaxRS problem, i.e., we only count the number of objects inside the query window. We proposed two algorithms, <italic>C-MaxRS</italic><sup>&#x0002B;</sup> and <italic>C-MaxRS</italic><sup>&#x02212;</sup> to efficiently solve C-MaxRS for data updates appearing and disappearing one at a time. The current article provides the following modifications and extensions to Mostafiz et al. (<xref ref-type="bibr" rid="B28">2017</xref>): (1) we provide the modified version of our algorithms from Mostafiz et al. (<xref ref-type="bibr" rid="B28">2017</xref>) to explicitly incorporate weighted version of the C-MaxRS problem, where each object and/or class can have different weights denoting its importance in the MaxRS computation. As it turns out (and demonstrated in the corresponding experiments) the weighted variant enables an increased pruning power; (2) we extend the work to consider novel settings of bulk updates handling of objects&#x00027; appearance and disappearance and propose techniques for efficient computation of the C-MaxRS in those settings; (3) we conducted an extensive set of additional experiments to evaluate the benefits of our approaches.</p>
<p>In the rest of this paper, section 2 positions the work with respect to the existing literature, and section 3 formalizes the C-MaxRS problem. Section 4 describes the necessary properties of the conditional count functions and lays out the basic solution. Section 5 presents the details of our pruning strategies, along with the data structures and algorithms for incorporating dynamic data, while section 6 presents an extension of the C-MaxRS problem to include weights of objects (or, classes). Section 7 discusses the challenges of processing bursty inputs, and offers additional data structures and algorithms to deal with them. Section 8 presents the quantitative experimental analysis and Section 9 summarizes and outlines directions for future work.</p>
</sec>
<sec id="s2">
<title>2. Related Works</title>
<p>The Range Aggregation and Maximum Range Sum (MaxRS) queries, and their variants have been extensively studied in the recent years (e.g., Lazaridis and Mehrotra, <xref ref-type="bibr" rid="B24">2001</xref>; Tao and Papadias, <xref ref-type="bibr" rid="B40">2004</xref>; Cho and Chung, <xref ref-type="bibr" rid="B7">2007</xref>; Sheng and Tao, <xref ref-type="bibr" rid="B36">2011</xref>; Choi et al., <xref ref-type="bibr" rid="B8">2014</xref>). A <italic>Range Aggregation Query</italic>, returning the aggregate result from a set of points, was solved for both 1-dimensional space&#x02014;i.e., calculating result from set of values in given interval by Tao et al. (<xref ref-type="bibr" rid="B41">2014</xref>) and for 2 dimensional point space, i.e., calculating result from a given rectangle with fixed location by Papadias et al. (<xref ref-type="bibr" rid="B33">2001</xref>). To calculate the aggregate result, an <italic>Aggregate Index</italic>, storing the summarized result for specific region referenced by that index is used in Cho and Chung (<xref ref-type="bibr" rid="B7">2007</xref>). Different data structures are introduced to store the aggregate index&#x02014;e.g., Lazaridis and Mehrotra (<xref ref-type="bibr" rid="B24">2001</xref>) proposed <italic>Multi-Resolution Aggregate tree</italic> (MRA-tree) to reduce the complexity. Although closely related, the MaxRS problem itself differs from these range aggregation queries.</p>
<p>The MaxRS problem was first addressed by researchers in the computational geometry community&#x02014;e.g., Imai and Asano (<xref ref-type="bibr" rid="B18">1983</xref>) used a technique that finds connected components and a maximum clique of an intersection graph of rectangles in the plane. A solution based on plane sweep strategy was presented in Nandy and Bhattacharya (<xref ref-type="bibr" rid="B29">1995</xref>), where the input point-objects were &#x0201C;dualized&#x0201D; into rectangles (centered at the points and with dimensions equivalent to the query rectangle <italic>r</italic>). Then an interval tree was used to record the regions (a.k.a. windows) with highest number of intersecting (dual) rectangles along the sweep&#x02014;denoting the possible locations for placing the (center of the) query rectangle, yielding <inline-formula><mml:math id="M1"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>n</mml:mi><mml:mo class="qopname">log</mml:mo><mml:mi>n</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> time complexity (<italic>n</italic> = number of points). However these solutions are not scalable, and Choi et al. (<xref ref-type="bibr" rid="B8">2014</xref>) proposed scalable extensions suited for LBS-applications&#x02014;e.g., retrieve best location for a new franchise store with a specified delivery range. Subsequently, different variants of the MaxRS problem have been investigated:&#x02014;constraining to underlying road networks (Phan et al., <xref ref-type="bibr" rid="B34">2014</xref>; Zhou and Wang, <xref ref-type="bibr" rid="B45">2016</xref>);&#x02014;processing MaxRS queries in wireless sensor networks (Hussain et al., <xref ref-type="bibr" rid="B17">2015</xref>; Wongse-ammat et al., <xref ref-type="bibr" rid="B42">2017</xref>);&#x02014;considering rotating MaxRS problem (Chen et al., <xref ref-type="bibr" rid="B6">2015</xref>), where rectangles do not need to be axes parallel, i.e., allowing much more flexibility. A rather complementary work, tackling the problem of approximate solution to the MaxRS query was presented in Tao et al. (<xref ref-type="bibr" rid="B39">2013</xref>), using randomized sampling to bound the error with higher probability, with increasing number of objects in question. A more recent work, Liu et al. (<xref ref-type="bibr" rid="B25">2019</xref>) has proposed a novel solution PMaxRS to deal with the inherent location uncertainty of objects, and used smart candidate generation process (pruning) and sampling-based approximation algorithm (refinement) to efficiently solve the problem.</p>
<p>Monitoring MaxRS for dynamic settings, where objects can be inserted and/or deleted was first addressed in Amagata and Hara (<xref ref-type="bibr" rid="B2">2016</xref>). To efficiently detect the new locations for placing the query rectangle, Amagata and Hara (<xref ref-type="bibr" rid="B2">2016</xref>) exploited the aggregate graph <italic>aG</italic>2 in a grid index and devised a branch-and-bound algorithm (cf. Narendra and Fukunaga, <xref ref-type="bibr" rid="B30">1977</xref>) over that <italic>aG</italic>2 graph for efficient approximation. We note that our work is complementary to Amagata and Hara (<xref ref-type="bibr" rid="B2">2016</xref>), in the sense that we addressed the settings of having different classes of objects and participation constraints based on them&#x02014;whereas Amagata and Hara (<xref ref-type="bibr" rid="B2">2016</xref>) solves the basic MaxRS problem. Moreover, Amagata and Hara (<xref ref-type="bibr" rid="B2">2016</xref>) considered a sliding-window based model in the problem settings (i.e., if <italic>m</italic> new objects appear, then <italic>m</italic> old objects disappear in a time-window <italic>T</italic>), which is completely different to our event-based model. Additionally, we used contrasting approaches (and different data structures) in this work&#x02014;dividing the 2D space into slices and slabs.</p>
<p>An interesting variant of MaxRS is addressed in Feng et al. (<xref ref-type="bibr" rid="B13">2016</xref>)&#x02014;the, so called, <italic>Best Region Search</italic> problem, which generalizes the MaxRS problem in the sense that the goal of placing the query rectangle is to maximize a broader class of aggregate functions<xref ref-type="fn" rid="fn0003"><sup>3</sup></xref>. Our work adapts the concepts from Feng et al. (<xref ref-type="bibr" rid="B13">2016</xref>) (slices and pruning)&#x02014;however, we tackle a different context: class-based participation constraints and dynamic/streaming data updates and, toward that, we also incorporated additional data structures (see section 5). As a summary, our methodology (as well as the actual implementation) is based on the idea of event driven approach for monitoring appearing and disappearing cases of objects, and we included a self-balancing binary tree (i.e., AVL-tree) to reduce the processing time that is needed for computing the MaxRS as per the event queue needs.</p>
<p>The issue of real-time query processing and indexing over spatio-temporal streaming data have been addressed extensively in prior literature, e.g., Hart et al., <xref ref-type="bibr" rid="B14">2005</xref>; Mokbel et al., <xref ref-type="bibr" rid="B27">2005</xref>; Dallachiesa et al., <xref ref-type="bibr" rid="B10">2015</xref>, etc. For real-time computation, it is necessary to restrict the set of inspected data points at any time using techniques such as punctuation (embedded annotations), synopses (data summaries), windows (e.g., sliding windows&#x02014;only items received in past <italic>t</italic> minutes), etc. In Mokbel et al. (<xref ref-type="bibr" rid="B27">2005</xref>), the authors implemented a continuous query processor designed specifically for highly dynamic environments. The proposed system utilized the idea of predicate-based sliding windows, and employed an incremental evaluation paradigm by continuously updating the query answer over a window. Dallachiesa et al. (<xref ref-type="bibr" rid="B10">2015</xref>) proposed both exact and approximate algorithms to manage <italic>count-based uncertain sliding windows</italic> for uncertain data streams (e.g., tuples can have both value and existential uncertainty). In contrast to these traditional window-based settings, we process C-MaxRS query in an event-based manner using all the data points received so far. This is necessary to maintain accurate answers for C-MaxRS over the whole dataset, i.e., trading off real-time processing power for accuracy.</p>
<p>On the other hand, both tree-based (cf. Hart et al., <xref ref-type="bibr" rid="B14">2005</xref>) and grid-based (cf. Amini et al., <xref ref-type="bibr" rid="B3">2011</xref>) indexing schemes have been proposed previously to deal with traditional streaming data. Dynamic Cascade Tree (DCT) is used in Hart et al. (<xref ref-type="bibr" rid="B14">2005</xref>) to index spatio-temporal query regions, ensuring optimized query processing for Remotely- Sensed Imagery (RSI) streaming data. Additionally, researchers such as Amini et al. (<xref ref-type="bibr" rid="B3">2011</xref>) have devised many hybrid clustering algorithms for data streams, using both density-based methods and grid-based indexing. In these density-based clustering algorithms, each point in a data-stream maps to a grid and grids are subsequently clustered based on their density. In our approach, we used slice-based (a specialized version of grid) indexing schemes to compute the range and class constrained optimal density clustering of data points (i.e., C-MaxRS).</p>
<p>Finally, as mentioned in section 1, a preliminary version of this work has been presented in Mostafiz et al. (<xref ref-type="bibr" rid="B28">2017</xref>). However, we note that the techniques for processing continuous monitoring queries over data streams (i.e., dynamic settings) must be adaptive, as data updates are often bursty and input characteristics may vary over time. Many previous works have demonstrated the tendency of bursty streams in various applications, and proposed general solutions such as Kleinberg (<xref ref-type="bibr" rid="B23">2003</xref>), Babcock et al. (<xref ref-type="bibr" rid="B4">2004</xref>), and Cervino et al. (<xref ref-type="bibr" rid="B5">2012</xref>), etc. For example, Babcock et al. (<xref ref-type="bibr" rid="B4">2004</xref>) utilized &#x0201C;load shedding&#x0201D; technique for aggregation queries over data updates, i.e., gracefully degrading performance when load is unmanageable; while Cervino et al. (<xref ref-type="bibr" rid="B5">2012</xref>) offered distributed stream processing systems to handle unpredictable changes in update rates. In this work, we address specifically the &#x0201C;algorithmic&#x0201D; part of the problem, i.e., presenting an optimal processing technique for C-MaxRS during bursty inputs. We conclude this section with a note that our proposed technique is implementation-independent, and can be augmented by existing distributed and parallel schemes seamlessly (cf. section 7).</p>
</sec>
<sec id="s3">
<title>3. Preliminaries</title>
<p>We now introduce the C-MaxRS problem and extend the definition for appearance of new objects, and disappearance of existing ones. Additionally, we discuss the concept of submodular monotone functions.</p>
<p><bold><italic>C</italic></bold><bold>-MaxRS &#x00026;</bold> <bold><italic>C</italic></bold><bold>-MaxRS-DU</bold>: Let us define a set of <italic>POIClass</italic> <italic>K</italic> = {<italic>k</italic><sub>1</sub>, <italic>k</italic><sub>2</sub>, &#x02026;, <italic>k</italic><sub><italic>m</italic></sub>}, where each <italic>k</italic><sub><italic>i</italic></sub> &#x02208; <italic>K</italic> refers to a class (alternatively, tag and/or type) of the objects, a.k.a. points of interest (POI). In this setting, each object <italic>o</italic><sub><italic>i</italic></sub> &#x02208; <italic>O</italic> is represented as a <italic>(location, class)</italic> tuple at any time instant <italic>t</italic>. We denote a set <italic>X</italic>= {<italic>x</italic><sub>1</sub>, <italic>x</italic><sub>2</sub>, &#x02026;, <italic>x</italic><sub><italic>m</italic></sub>} as <italic>MinConditionSet</italic>, where |<italic>X</italic>| =|<italic>K</italic>| and each <italic>x</italic><sub><italic>i</italic></sub> &#x02208; &#x02124;&#x0002B; denotes the desired lower bound of the number of objects of class <italic>k</italic><sub><italic>i</italic></sub> in the interior of the query rectangle <italic>r</italic>&#x02014;i.e., the optimal region must have at least <italic>x</italic><sub><italic>i</italic></sub> number of objects of class <italic>k</italic><sub><italic>i</italic></sub>. Let us assume <italic>l</italic><sub><italic>i</italic></sub> as the number of objects of type <italic>k</italic><sub><italic>i</italic></sub> in the interior of <italic>r</italic> centered at a point <italic>p</italic>. A utility function <inline-formula><mml:math id="M2"><mml:mi>f</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>O</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>:</mml:mo><mml:mrow><mml:mi mathvariant="-tex-caligraphic">P</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>O</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x02192;</mml:mo><mml:msub><mml:mrow><mml:mi>&#x02115;</mml:mi></mml:mrow><mml:mrow><mml:mn>0</mml:mn></mml:mrow></mml:msub></mml:math></inline-formula>, mapping a subset of spatial objects to a non-negative integer is defined as below,</p>
<disp-formula id="E1"><mml:math id="M3"><mml:mtable columnalign="left"><mml:mtr><mml:mtd columnalign="left"><mml:mi>f</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>O</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:mrow><mml:mo stretchy="true">{</mml:mo><mml:mtable style="text-align:axis;" equalrows="false" columnlines="none" equalcolumns="false" class="array"><mml:mtr><mml:mtd columnalign="left"><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mstyle displaystyle="true"><mml:msubsup><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mrow><mml:mo>|</mml:mo><mml:mi>K</mml:mi><mml:mo>|</mml:mo></mml:mrow></mml:msubsup></mml:mstyle><mml:msub><mml:mrow><mml:mi>l</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>,</mml:mo></mml:mtd><mml:mtd columnalign="left"><mml:mtext class="textrm" mathvariant="normal">if&#x000A0;</mml:mtext><mml:mo>&#x02200;</mml:mo><mml:mi>i</mml:mi><mml:mo>&#x02208;</mml:mo><mml:mrow><mml:mo>{</mml:mo><mml:mrow><mml:mn>1</mml:mn><mml:mo>,</mml:mo><mml:mn>2</mml:mn><mml:mo>,</mml:mo><mml:mn>3</mml:mn><mml:mo>,</mml:mo><mml:mo>.</mml:mo><mml:mo>.</mml:mo><mml:mo>.</mml:mo><mml:mo>,</mml:mo><mml:mo>|</mml:mo><mml:mi>K</mml:mi><mml:mo>|</mml:mo></mml:mrow><mml:mo>}</mml:mo></mml:mrow><mml:mo>,</mml:mo><mml:msub><mml:mrow><mml:mi>l</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>&#x0003E;</mml:mo><mml:mo>=</mml:mo><mml:msub><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:mtd></mml:mtr><mml:mtr><mml:mtd columnalign="left"><mml:mn>0</mml:mn><mml:mo>,</mml:mo></mml:mtd><mml:mtd columnalign="left"><mml:mtext class="textrm" mathvariant="normal">if&#x000A0;</mml:mtext><mml:mo>&#x02203;</mml:mo><mml:mi>i</mml:mi><mml:mo>&#x02208;</mml:mo><mml:mrow><mml:mo>{</mml:mo><mml:mrow><mml:mn>1</mml:mn><mml:mo>,</mml:mo><mml:mn>2</mml:mn><mml:mo>,</mml:mo><mml:mn>3</mml:mn><mml:mo>,</mml:mo><mml:mo>.</mml:mo><mml:mo>.</mml:mo><mml:mo>.</mml:mo><mml:mo>,</mml:mo><mml:mo>|</mml:mo><mml:mi>K</mml:mi><mml:mo>|</mml:mo></mml:mrow><mml:mo>}</mml:mo></mml:mrow><mml:mo>,</mml:mo><mml:msub><mml:mrow><mml:mi>l</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>&#x0003C;</mml:mo><mml:msub><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:mtd></mml:mtr></mml:mtable></mml:mrow></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula>
<p>Additionally, we mark <italic>O</italic><sub><italic>r</italic><sub><italic>p</italic></sub></sub> as the set of spatial objects in the interior of rectangle <italic>r</italic> centered at any point <italic>p</italic>. Formally, <bold>Conditional-MaxRS (C-MaxRS):</bold> Given a rectangular spatial field &#x1D53D;, a set of objects of interest <italic>O</italic> (bounded by &#x1D53D;), a query rectangle <italic>r</italic> (of size <italic>a</italic> &#x000D7; <italic>b</italic>), a set of <italic>POIClass</italic> <italic>K</italic> = {<italic>k</italic><sub>1</sub>, <italic>k</italic><sub>2</sub>, &#x02026;, <italic>k</italic><sub><italic>m</italic></sub>} and a <italic>MinConditionSet</italic> <italic>X</italic> = {<italic>x</italic><sub>1</sub>, <italic>x</italic><sub>2</sub>, &#x02026;, <italic>x</italic><sub><italic>m</italic></sub>}, the C-MaxRS query returns an optimal location (point) <italic>p</italic><sup>&#x0002A;</sup> for <italic>r</italic> such that:</p>
<disp-formula id="E2"><mml:math id="M4"><mml:mrow><mml:msup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msup><mml:mo>=</mml:mo><mml:mi>a</mml:mi><mml:mi>r</mml:mi><mml:mi>g</mml:mi><mml:mi>m</mml:mi><mml:mi>a</mml:mi><mml:msub><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>p</mml:mi><mml:mo>&#x02208;</mml:mo><mml:mo>&#x1D53D;</mml:mo></mml:mrow></mml:msub><mml:mi>f</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msub><mml:mrow><mml:mi>O</mml:mi></mml:mrow><mml:mrow><mml:msub><mml:mrow><mml:mi>r</mml:mi></mml:mrow><mml:mrow><mml:mi>p</mml:mi></mml:mrow></mml:msub></mml:mrow></mml:msub></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mrow></mml:math></disp-formula>
<p>where <italic>O</italic><sub><italic>r</italic><sub><italic>p</italic></sub></sub> &#x02286; <italic>O</italic>.</p>
<p>Note that, in the case that there is no placement <italic>p</italic> for which all the conditions of <italic>MinConditionSet</italic> is met, the query will return an empty answer&#x02014;indicating to the user to either increase the size of <italic>R</italic> or decrease the lower bounds for some classes.</p>
<p>In a spatial data stream environment, old points of interest may disappear and new ones may appear at any time instant. We can deal with this in two-ways:</p>
<list list-type="bullet">
<list-item><p><italic>Time-based:</italic> C-MaxRS is computed on a regular time-interval &#x003B4;.</p></list-item>
<list-item><p><italic>Event-based:</italic> C-MaxRS is computed on an <italic>event</italic>, where C-MaxRS is maintained (evaluated) every time a new point appears or an old point disappears.</p></list-item>
</list>
<p>Although faster algorithms can be developed in time-based settings, the solutions provided would be inherently erroneous for time between <italic>t</italic> and <italic>t</italic> &#x0002B; &#x003B4;. On the other hand, event-based processing ensures that a correct answer-set is maintained all the time. Thus, we deal with the streaming data in event-based manner, for which we denote <italic>e</italic><sup>&#x0002B;</sup> as the new point <italic>appearance</italic> and <italic>e</italic><sup>&#x02212;</sup> as the old point <italic>disappearance</italic> event. We note that, most of the settings for basic C-MaxRS remains same, except that the set of objects <italic>O</italic> is altered at each event. We define the set of points of interest in this data stream for any event <italic>e</italic><sub><italic>i</italic></sub> over an object <italic>o</italic><sub><italic>e</italic><sub><italic>i</italic></sub></sub> as:</p>
<disp-formula id="E3"><mml:math id="M5"><mml:mtable columnalign="left"><mml:mtr><mml:mtd><mml:msub><mml:mrow><mml:mi>O</mml:mi></mml:mrow><mml:mrow><mml:msub><mml:mrow><mml:mi>e</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mrow><mml:mo stretchy="true">{</mml:mo><mml:mtable style="text-align:axis;" equalrows="false" columnlines="none" equalcolumns="false" class="array"><mml:mtr><mml:mtd><mml:msub><mml:mrow><mml:mi>O</mml:mi></mml:mrow><mml:mrow><mml:msub><mml:mrow><mml:mi>e</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>-</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>&#x0222A;</mml:mo><mml:mrow><mml:mo>{</mml:mo><mml:mrow><mml:msub><mml:mrow><mml:mi>o</mml:mi></mml:mrow><mml:mrow><mml:msub><mml:mrow><mml:mi>e</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:mrow></mml:msub></mml:mrow><mml:mo>}</mml:mo></mml:mrow><mml:mo>,</mml:mo></mml:mtd><mml:mtd><mml:mtext class="textrm" mathvariant="normal">if&#x000A0;</mml:mtext><mml:msub><mml:mrow><mml:mi>e</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>.</mml:mo><mml:mi>t</mml:mi><mml:mi>y</mml:mi><mml:mi>p</mml:mi><mml:mi>e</mml:mi><mml:mo>=</mml:mo><mml:msup><mml:mrow><mml:mi>e</mml:mi></mml:mrow><mml:mrow><mml:mo>&#x0002B;</mml:mo></mml:mrow></mml:msup></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:msub><mml:mrow><mml:mi>O</mml:mi></mml:mrow><mml:mrow><mml:msub><mml:mrow><mml:mi>e</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>-</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>\</mml:mo><mml:mrow><mml:mo>{</mml:mo><mml:mrow><mml:msub><mml:mrow><mml:mi>o</mml:mi></mml:mrow><mml:mrow><mml:msub><mml:mrow><mml:mi>e</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:mrow></mml:msub></mml:mrow><mml:mo>}</mml:mo></mml:mrow><mml:mo>,</mml:mo></mml:mtd><mml:mtd><mml:mtext class="textrm" mathvariant="normal">if&#x000A0;</mml:mtext><mml:msub><mml:mrow><mml:mi>e</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>.</mml:mo><mml:mi>t</mml:mi><mml:mi>y</mml:mi><mml:mi>p</mml:mi><mml:mi>e</mml:mi><mml:mo>=</mml:mo><mml:msup><mml:mrow><mml:mi>e</mml:mi></mml:mrow><mml:mrow><mml:mo>-</mml:mo></mml:mrow></mml:msup></mml:mtd></mml:mtr></mml:mtable></mml:mrow></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula>
<p>Formally, <bold>Conditional-MaxRS for Data Stream/Updates (C-MaxRS-DU)</bold> definition is an extension of the above definition of C-MaxRS, for which we additionally have a sequence of events <italic>E</italic>={<italic>e</italic><sub>1</sub>, <italic>e</italic><sub>2</sub>, <italic>e</italic><sub>3</sub>, &#x02026;} where each <italic>e</italic><sub><italic>i</italic></sub> denotes the appearance or disappearance of a point of interest.</p>
<p><bold>Submodular Monotone Function:</bold> Feng et al. (<xref ref-type="bibr" rid="B13">2016</xref>) devised solutions to a variant of the MaxRS problem (<italic>best region search</italic>) where the utility function for the given POIs is a submodular monotone function&#x02014;which is defined as: [<bold>Submodular Monotone Function</bold>] If &#x003A9; is a finite set, a submodular function is a set function <inline-formula><mml:math id="M6"><mml:mi>f</mml:mi><mml:mo>:</mml:mo><mml:mrow><mml:mi mathvariant="-tex-caligraphic">P</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mo>&#x003A9;</mml:mo></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x02192;</mml:mo><mml:mi>&#x0211D;</mml:mi></mml:math></inline-formula> if &#x02200;<sub><italic>X, Y</italic></sub>&#x02282;&#x003A9;, with <italic>X</italic> &#x02286; <italic>Y</italic> and <italic>x</italic> &#x02208; &#x003A9;\<italic>Y</italic> we have (1) <italic>f</italic>(<italic>X</italic>&#x0222A;{<italic>x</italic>}) &#x02212; <italic>f</italic>(<italic>X</italic>) &#x02265; <italic>f</italic>(<italic>Y</italic>&#x0222A;{<italic>x</italic>}) &#x02212; <italic>f</italic>(<italic>Y</italic>) and (2) <italic>f</italic>(<italic>X</italic>) &#x02264; <italic>f</italic>(<italic>Y</italic>).</p>
<p>In the above definition, (1) represents the condition of submodularity, while (2) presents the condition of monotonicity of the function. In section 4, we will discuss these properties of our introduced utility function <inline-formula><mml:math id="M7"><mml:mi>f</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>O</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>:</mml:mo><mml:mrow><mml:mi mathvariant="-tex-caligraphic">P</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>O</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x02192;</mml:mo><mml:msub><mml:mrow><mml:mi>&#x02115;</mml:mi></mml:mrow><mml:mrow><mml:mn>0</mml:mn></mml:mrow></mml:msub></mml:math></inline-formula>.</p>
<p><bold>Discussion:</bold> Note that, for the sake of simplicity, initially we have considered only the counts of POIs when defining the utility function or conditions in <italic>X</italic>. In section 6, we show that they can be extended to incorporate different non-negative weights for objects with only minor modifications. Similarly, although in our provided examples, for brevity, we&#x00027;ve only depicted one class per object, the techniques proposed in this work extends to the objects of multiple classes (or tags), e.g., objects can be considered as (<italic>location, classes</italic>) tuple.</p>
</sec>
<sec id="s4">
<title>4. Basic C-MaxRS</title>
<p>In this section, we first convert the C-MaxRS problem to its dual variant and then discuss important properties of the conditional weight function <italic>f</italic>(.), showing how we can utilize them to devise an efficient solution to process C-MaxRS.</p>
<sec>
<title>4.1. C-MaxRS &#x02192; Dual Problem</title>
<p>A naive approach to solve C-MaxRS is to choose each discrete point <italic>p</italic> iteratively from the rectangular spatial field &#x1D53D; and compute the value of <italic>f</italic>(<italic>O</italic><sub><italic>r</italic><sub><italic>p</italic></sub></sub>) for the set of spatial objects covered by the query rectangle <italic>r</italic>. As there can be infinite number of points in &#x1D53D;, this approach is too costly to be practical. Existing works (see Nandy and Bhattacharya, <xref ref-type="bibr" rid="B29">1995</xref>; Feng et al., <xref ref-type="bibr" rid="B13">2016</xref>; Hussain et al., <xref ref-type="bibr" rid="B15">2017a</xref>) have demonstrated that feasible solutions can be derived for MaxRS (and related problems) by transforming it into its dual problem&#x02014;<italic>rectangle intersection problem</italic>. A similar conversion is possible for C-MaxRS as well, enabling efficient solutions. In this regards, let <italic>R</italic>={<italic>r</italic><sub>1</sub>, <italic>r</italic><sub>2</sub>, &#x02026;, <italic>r</italic><sub><italic>n</italic></sub>} be a set of rectangles of user-defined size <italic>a</italic> &#x000D7; <italic>b</italic>. Each rectangle <italic>r</italic><sub><italic>i</italic></sub> &#x02208; <italic>R</italic> is centered at each point of interest <italic>o</italic><sub><italic>i</italic></sub> &#x02208; <italic>O</italic>, i.e., |<italic>R</italic>|=|<italic>O</italic>|. We define <italic>r</italic><sub><italic>i</italic></sub> as the <italic>dual rectangle</italic> of <italic>o</italic><sub><italic>i</italic></sub>. Let us consider a function <inline-formula><mml:math id="M8"><mml:mi>g</mml:mi><mml:mo>:</mml:mo><mml:mrow><mml:mi mathvariant="-tex-caligraphic">P</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x02192;</mml:mo><mml:msub><mml:mrow><mml:mi>&#x02115;</mml:mi></mml:mrow><mml:mrow><mml:mn>0</mml:mn></mml:mrow></mml:msub></mml:math></inline-formula> that maps a set of dual rectangles to a non-negative integer. For a set of rectangles <italic>R</italic><sub><italic>k</italic></sub> &#x0003D; {<italic>r</italic><sub>1</sub>, <italic>r</italic><sub>2</sub>, &#x02026;, <italic>r</italic><sub><italic>k</italic></sub>}, let <italic>g</italic>(<italic>R</italic><sub><italic>k</italic></sub>) &#x0003D; <italic>f</italic>({<italic>o</italic><sub>1</sub>, <italic>o</italic><sub>2</sub>, &#x02026;, <italic>o</italic><sub><italic>k</italic></sub>}). Note that, a rectangle is <italic>affected</italic> by a point <italic>p</italic> if it is in the interior of that rectangle. Let <italic>A</italic>(<italic>p</italic>) be the sets of rectangle affected by <italic>p</italic> &#x02208; &#x1D53D;. Now, we can redefine C-MaxRS as the following equivalent problem:</p>
<p><italic>Given a rectangular spatial field</italic> &#x1D53D;<italic>, a set of rectangles</italic> <italic>R</italic><italic>=</italic>{<italic>r</italic><sub>1</sub>, <italic>r</italic><sub>2</sub>, &#x02026;, <italic>r</italic><sub><italic>n</italic></sub>} <italic>(with centers bounded by</italic> &#x1D53D;<italic>) where each</italic> <italic>r</italic><sub><italic>i</italic></sub> <italic>is of a given size</italic> <italic>a</italic> &#x000D7; <italic>b</italic><italic>, a set of</italic> <italic>POIClass</italic> <italic>K</italic><italic>=</italic>{<italic>k</italic><sub>1</sub>, <italic>k</italic><sub>2</sub>, &#x02026;, <italic>k</italic><sub><italic>m</italic></sub>} <italic>and a</italic> <italic>MinConditionSet</italic> <italic>X</italic><italic>=</italic>{<italic>x</italic><sub>1</sub>, <italic>x</italic><sub>2</sub>, &#x02026;, <italic>x</italic><sub><italic>m</italic></sub>}<italic>, retrieve an optimal location (point)</italic> <italic>p</italic><sup>&#x0002A;</sup> <italic>such that:</italic></p>
<disp-formula id="E4"><mml:math id="M9"><mml:mrow><mml:msup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msup><mml:mo>=</mml:mo><mml:mi>a</mml:mi><mml:mi>r</mml:mi><mml:mi>g</mml:mi><mml:mi>m</mml:mi><mml:mi>a</mml:mi><mml:msub><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>p</mml:mi><mml:mo>&#x02208;</mml:mo><mml:mi>P</mml:mi></mml:mrow></mml:msub><mml:mi>g</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>,</mml:mo></mml:mrow></mml:math></disp-formula>
<p><italic>where</italic> <italic>A</italic>(<italic>p</italic>) &#x02286; <italic>R</italic>.</p>
<p>The bijection is illustrated with the help of <xref ref-type="fig" rid="F2">Figure 2</xref> using the same example (and conditions) of <xref ref-type="fig" rid="F1">Figure 1</xref>, i.e., <italic>the positioning of</italic> <italic>r</italic> <italic>must be such that at least 1 user is included from each of the classes A, B, and C, respectively</italic>. Suppose, rectangles {<italic>r</italic><sub>1</sub>, <italic>r</italic><sub>2</sub>, <italic>r</italic><sub>3</sub>, &#x02026;, <italic>r</italic><sub>7</sub>} are the dual rectangles of given objects {<italic>o</italic><sub>1</sub>, <italic>o</italic><sub>2</sub>, <italic>o</italic><sub>3</sub>, &#x02026;, <italic>o</italic><sub>7</sub>} in <xref ref-type="fig" rid="F2">Figure 2</xref>, and <italic>p</italic><sub>1</sub> and <italic>p</italic><sub>2</sub> are two points within the given space. <italic>p</italic><sub>1</sub> affects rectangles <italic>r</italic><sub>1</sub>, <italic>r</italic><sub>2</sub>, <italic>r</italic><sub>3</sub> and <italic>p</italic><sub>2</sub> affects <italic>r</italic><sub>4</sub>, <italic>r</italic><sub>5</sub>, <italic>r</italic><sub>6</sub>, <italic>r</italic><sub>7</sub>, i.e., <italic>A</italic>(<italic>p</italic><sub>1</sub>) &#x0003D; {<italic>r</italic><sub>1</sub>, <italic>r</italic><sub>2</sub>, <italic>r</italic><sub>3</sub>} and <italic>A</italic>(<italic>p</italic><sub>2</sub>) &#x0003D; {<italic>r</italic><sub>4</sub>, <italic>r</italic><sub>5</sub>, <italic>r</italic><sub>6</sub>, <italic>r</italic><sub>7</sub>}. Thus, <italic>g</italic>(<italic>A</italic>(<italic>p</italic><sub>1</sub>))=<italic>f</italic>({<italic>o</italic><sub>1</sub>, <italic>o</italic><sub>2</sub>, <italic>o</italic><sub>3</sub>}) &#x0003D; 3 as the points conform to the constraints mentioned above, while <italic>g</italic>(<italic>A</italic>(<italic>p</italic><sub>2</sub>))=<italic>f</italic>({<italic>o</italic><sub>4</sub>, <italic>o</italic><sub>5</sub>, <italic>o</italic><sub>6</sub>, <italic>o</italic><sub>7</sub>}) &#x0003D; 0 as they do not.</p>
<fig id="F2" position="float">
<label>Figure 2</label>
<caption><p>C-MaxRS &#x02192; dual problem.</p></caption>
<graphic xlink:href="fdata-03-00020-g0002.tif"/>
</fig>
<p>Similarly, C-MaxRS-DU can be redefined as follows:</p>
<p><italic>Given a rectangular spatial field</italic> &#x1D53D;<italic>, a set of rectangles</italic> <italic>R</italic><italic>=</italic>{<italic>r</italic><sub>1</sub>, <italic>r</italic><sub>2</sub>, &#x02026;, <italic>r</italic><sub><italic>n</italic></sub>} <italic>(with centers bounded by</italic> &#x1D53D;<italic>) where each</italic> <italic>r</italic><sub><italic>i</italic></sub> <italic>is of a given size</italic> <italic>a</italic> &#x000D7; <italic>b</italic><italic>, a set of</italic> <italic>POIClass</italic> <italic>K</italic><italic>=</italic>{<italic>k</italic><sub>1</sub>, <italic>k</italic><sub>2</sub>, &#x02026;, <italic>k</italic><sub><italic>m</italic></sub>}<italic>, a</italic> <italic>MinConditionSet</italic> <italic>X</italic><italic>=</italic>{<italic>x</italic><sub>1</sub>, <italic>x</italic><sub>2</sub>, &#x02026;, <italic>x</italic><sub><italic>m</italic></sub>}<italic>, and an event</italic> <italic>e</italic> <italic>(appearance/disappearance of a rectangle</italic> <italic>r</italic><sub><italic>e</italic></sub><italic>), update the optimal location (point)</italic> <italic>p</italic><sup>&#x0002A;</sup> <italic>such that:</italic></p>
<disp-formula id="E5"><mml:math id="M10"><mml:mtable columnalign="left"><mml:mtr><mml:mtd><mml:msup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msup><mml:mo>=</mml:mo><mml:mi>a</mml:mi><mml:mi>r</mml:mi><mml:mi>g</mml:mi><mml:mi>m</mml:mi><mml:mi>a</mml:mi><mml:msub><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>p</mml:mi><mml:mo>&#x02208;</mml:mo><mml:mi>P</mml:mi></mml:mrow></mml:msub><mml:mi>g</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>,</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula>
<p><italic>where</italic></p>
<disp-formula id="E6"><mml:math id="M11"><mml:mtable columnalign="left"><mml:mtr><mml:mtd columnalign="left"><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x02286;</mml:mo><mml:mrow><mml:mo stretchy="true">{</mml:mo><mml:mtable style="text-align:axis;" equalrows="false" columnlines="none" equalcolumns="false" class="array"><mml:mtr><mml:mtd columnalign="left"><mml:mi>R</mml:mi><mml:mo>&#x0222A;</mml:mo><mml:mrow><mml:mo>{</mml:mo><mml:mrow><mml:msub><mml:mrow><mml:mi>r</mml:mi></mml:mrow><mml:mrow><mml:mi>e</mml:mi></mml:mrow></mml:msub></mml:mrow><mml:mo>}</mml:mo></mml:mrow><mml:mo>,</mml:mo></mml:mtd><mml:mtd columnalign="left"><mml:mi>i</mml:mi><mml:mi>f</mml:mi><mml:mtext>&#x000A0;</mml:mtext><mml:mi>e</mml:mi><mml:mo>.</mml:mo><mml:mi>t</mml:mi><mml:mi>y</mml:mi><mml:mi>p</mml:mi><mml:mi>e</mml:mi><mml:mo>=</mml:mo><mml:msup><mml:mrow><mml:mi>e</mml:mi></mml:mrow><mml:mrow><mml:mo>&#x0002B;</mml:mo></mml:mrow></mml:msup></mml:mtd></mml:mtr><mml:mtr><mml:mtd columnalign="left"><mml:mi>R</mml:mi><mml:mo>\</mml:mo><mml:mrow><mml:mo>{</mml:mo><mml:mrow><mml:msub><mml:mrow><mml:mi>r</mml:mi></mml:mrow><mml:mrow><mml:mi>e</mml:mi></mml:mrow></mml:msub></mml:mrow><mml:mo>}</mml:mo></mml:mrow><mml:mo>,</mml:mo></mml:mtd><mml:mtd columnalign="left"><mml:mi>i</mml:mi><mml:mi>f</mml:mi><mml:mtext>&#x000A0;</mml:mtext><mml:mi>e</mml:mi><mml:mo>.</mml:mo><mml:mi>t</mml:mi><mml:mi>y</mml:mi><mml:mi>p</mml:mi><mml:mi>e</mml:mi><mml:mo>=</mml:mo><mml:msup><mml:mrow><mml:mi>e</mml:mi></mml:mrow><mml:mrow><mml:mo>-</mml:mo></mml:mrow></mml:msup></mml:mtd></mml:mtr></mml:mtable></mml:mrow></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula>
</sec>
<sec>
<title>4.2. Properties of <italic>f</italic> and <italic>g</italic></title>
<p>A method to solve an instance of <italic>Best Region Search</italic> (BRS) problem was devised in Feng et al. (<xref ref-type="bibr" rid="B13">2016</xref>), where the weight function <inline-formula><mml:math id="M12"><mml:mi>f</mml:mi><mml:mo>:</mml:mo><mml:mrow><mml:mi mathvariant="-tex-caligraphic">P</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>O</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x02192;</mml:mo><mml:mi>&#x0211D;</mml:mi></mml:math></inline-formula> is a submodular monotone function (cf. defined in section 3). In Feng et al. (<xref ref-type="bibr" rid="B13">2016</xref>), the problem is first converted to the dual <italic>Submodular Weighted Rectangle Intersection (SIRI)</italic> problem, and then optimization techniques are applied based on these properties of <italic>f</italic>(.). We now proceed to discuss submodularity and monotonicity of functions <inline-formula><mml:math id="M13"><mml:mi>f</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>O</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>:</mml:mo><mml:mrow><mml:mi mathvariant="-tex-caligraphic">P</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>O</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x02192;</mml:mo><mml:msub><mml:mrow><mml:mi>&#x02115;</mml:mi></mml:mrow><mml:mrow><mml:mn>0</mml:mn></mml:mrow></mml:msub></mml:math></inline-formula> and <inline-formula><mml:math id="M14"><mml:mi>g</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>:</mml:mo><mml:mrow><mml:mi mathvariant="-tex-caligraphic">P</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x02192;</mml:mo><mml:msub><mml:mrow><mml:mi>&#x02115;</mml:mi></mml:mrow><mml:mrow><mml:mn>0</mml:mn></mml:mrow></mml:msub></mml:math></inline-formula> in our problem settings. We establish two important results for <italic>f</italic> and <italic>g</italic> as follows:</p>
<p>Lemma 1. <italic>Both <italic>f</italic> and <italic>g</italic> are monotone functions</italic>.</p>
<p><italic>Proof</italic>: For a set of spatial objects <italic>O</italic>,</p>
<disp-formula id="E7"><mml:math id="M15"><mml:mtable columnalign="left"><mml:mtr><mml:mtd columnalign="left"><mml:mi>f</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>O</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:mrow><mml:mo stretchy="true">{</mml:mo><mml:mtable style="text-align:axis;" equalrows="false" columnlines="none" equalcolumns="false" class="array"><mml:mtr><mml:mtd columnalign="left"><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mstyle displaystyle="true"><mml:msubsup><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mrow><mml:mo>|</mml:mo><mml:mi>K</mml:mi><mml:mo>|</mml:mo></mml:mrow></mml:msubsup></mml:mstyle><mml:msub><mml:mrow><mml:mi>l</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>,</mml:mo></mml:mtd><mml:mtd columnalign="left"><mml:mtext class="textrm" mathvariant="normal">if&#x000A0;</mml:mtext><mml:mo>&#x02200;</mml:mo><mml:mi>i</mml:mi><mml:mo>&#x02208;</mml:mo><mml:mrow><mml:mo>{</mml:mo><mml:mrow><mml:mn>1</mml:mn><mml:mo>,</mml:mo><mml:mn>2</mml:mn><mml:mo>,</mml:mo><mml:mn>3</mml:mn><mml:mo>,</mml:mo><mml:mo>.</mml:mo><mml:mo>.</mml:mo><mml:mo>.</mml:mo><mml:mo>,</mml:mo><mml:mo>|</mml:mo><mml:mi>K</mml:mi><mml:mo>|</mml:mo></mml:mrow><mml:mo>}</mml:mo></mml:mrow><mml:mo>,</mml:mo><mml:msub><mml:mrow><mml:mi>l</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>&#x0003E;</mml:mo><mml:mo>=</mml:mo><mml:msub><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:mtd></mml:mtr><mml:mtr><mml:mtd columnalign="left"><mml:mn>0</mml:mn><mml:mo>,</mml:mo></mml:mtd><mml:mtd columnalign="left"><mml:mtext class="textrm" mathvariant="normal">if&#x000A0;</mml:mtext><mml:mo>&#x02203;</mml:mo><mml:mi>i</mml:mi><mml:mo>&#x02208;</mml:mo><mml:mrow><mml:mo>{</mml:mo><mml:mrow><mml:mn>1</mml:mn><mml:mo>,</mml:mo><mml:mn>2</mml:mn><mml:mo>,</mml:mo><mml:mn>3</mml:mn><mml:mo>,</mml:mo><mml:mo>.</mml:mo><mml:mo>.</mml:mo><mml:mo>.</mml:mo><mml:mo>,</mml:mo><mml:mo>|</mml:mo><mml:mi>K</mml:mi><mml:mo>|</mml:mo></mml:mrow><mml:mo>}</mml:mo></mml:mrow><mml:mo>,</mml:mo><mml:msub><mml:mrow><mml:mi>l</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>&#x0003C;</mml:mo><mml:msub><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:mtd></mml:mtr></mml:mtable></mml:mrow></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula>
<p>For any of the classes, if the given lower-bound condition is not met, i.e. &#x02203;<italic>i</italic> &#x02208; {1, 2, 3, ..., |<italic>K</italic>|}, <italic>l</italic><sub><italic>i</italic></sub> &#x0003C; <italic>x</italic><sub><italic>i</italic></sub>, then <italic>f</italic>(<italic>O</italic>)=0 for the spatial object set <italic>O</italic>. However, if all of the conditions are satisfied&#x02014;i.e., &#x02200;<italic>i</italic> &#x02208; {1, 2, 3, ..., |<italic>K</italic>|}, <italic>l</italic><sub><italic>i</italic></sub> &#x02265; <italic>x</italic><sub><italic>i</italic></sub>, then the utility value is equal to the number of spatial objects in <italic>O</italic>.</p>
<p>Let <italic>O</italic><sub><italic>i</italic></sub> &#x02286; <italic>O</italic><sub><italic>j</italic></sub>. If <italic>O</italic><sub><italic>i</italic></sub> &#x0003D; <italic>O</italic><sub><italic>j</italic></sub>, <italic>f</italic>(<italic>O</italic><sub><italic>i</italic></sub>) &#x0003D; <italic>f</italic>(<italic>O</italic><sub><italic>j</italic></sub>), otherwise if <italic>O</italic><sub><italic>i</italic></sub>&#x02282;<italic>O</italic><sub><italic>j</italic></sub>, there are three possible cases:</p>
<p><italic>Case (a)</italic>: Both <italic>O</italic><sub><italic>i</italic></sub> and <italic>O</italic><sub><italic>j</italic></sub> fail to conform to the <italic>MinConditionSet</italic> <italic>X</italic>&#x02014;then <italic>f</italic>(<italic>O</italic><sub><italic>i</italic></sub>) &#x0003D; <italic>f</italic>(<italic>O</italic><sub><italic>j</italic></sub>) &#x0003D; 0.</p>
<p><italic>Case (b)</italic>: <italic>O</italic><sub><italic>j</italic></sub> conforms to <italic>X</italic>, but <italic>O</italic><sub><italic>i</italic></sub> does not&#x02014;then <italic>f</italic>(<italic>O</italic><sub><italic>i</italic></sub>) &#x0003D; 0 and <italic>f</italic>(<italic>O</italic><sub><italic>j</italic></sub>) &#x0003D; |<italic>O</italic><sub><italic>j</italic></sub>|. Thus, <italic>f</italic>(<italic>O</italic><sub><italic>i</italic></sub>) &#x0003C; <italic>f</italic>(<italic>O</italic><sub><italic>j</italic></sub>).</p>
<p><italic>Case (c)</italic>: Both <italic>O</italic><sub><italic>i</italic></sub> and <italic>O</italic><sub><italic>j</italic></sub> conform to <italic>X</italic>, then <italic>f</italic>(<italic>O</italic><sub><italic>i</italic></sub>) &#x0003D; |<italic>O</italic><sub><italic>i</italic></sub>| and <italic>f</italic>(<italic>O</italic><sub><italic>j</italic></sub>) &#x0003D; |<italic>O</italic><sub><italic>j</italic></sub>|. As <italic>O</italic><sub><italic>i</italic></sub>&#x02282;<italic>O</italic><sub><italic>j</italic></sub>, |<italic>O</italic><sub><italic>i</italic></sub>| &#x0003C; |<italic>O</italic><sub><italic>j</italic></sub>|, implying, <italic>f</italic>(<italic>O</italic><sub><italic>i</italic></sub>) &#x0003C; <italic>f</italic>(<italic>O</italic><sub><italic>j</italic></sub>).</p>
<p>We note that there are no possible cases where <italic>O</italic><sub><italic>i</italic></sub> conforms to <italic>X</italic>, but <italic>O</italic><sub><italic>j</italic></sub> does not. Thus, <italic>f</italic> is a monotone function. Let <italic>R</italic><sub><italic>i</italic></sub> and <italic>R</italic><sub><italic>j</italic></sub> be two sets of dual rectangles generated from the aforementioned two sets of spatial objects&#x02014;<italic>O</italic><sub><italic>i</italic></sub> and <italic>O</italic><sub><italic>j</italic></sub>, respectively. Here, <italic>O</italic><sub><italic>i</italic></sub> &#x02286; <italic>O</italic><sub><italic>j</italic></sub> &#x02192; <italic>R</italic><sub><italic>i</italic></sub> &#x02286; <italic>R</italic><sub><italic>j</italic></sub>. According to the definition of <italic>g</italic>, <italic>g</italic>(<italic>R</italic><sub><italic>i</italic></sub>) &#x0003D; <italic>f</italic>(<italic>O</italic><sub><italic>i</italic></sub>) and <italic>g</italic>(<italic>R</italic><sub><italic>j</italic></sub>) &#x0003D; <italic>f</italic>(<italic>O</italic><sub><italic>j</italic></sub>). As <italic>f</italic>(<italic>O</italic><sub><italic>i</italic></sub>) &#x02264; <italic>f</italic>(<italic>O</italic><sub><italic>j</italic></sub>), then <italic>g</italic>(<italic>R</italic><sub><italic>i</italic></sub>) &#x02264; <italic>g</italic>(<italic>R</italic><sub><italic>j</italic></sub>). Thus, <italic>g</italic> is a monotone function too.</p>
<p>Lemma 2. <italic>None of <italic>f</italic> and <italic>g</italic> is a submodular function</italic>.</p>
<p><italic>Proof</italic>: Let us consider the settings of the preceding proof, i.e., two sets of spatial objects <italic>O</italic><sub><italic>i</italic></sub> and <italic>O</italic><sub><italic>j</italic></sub> (where <italic>O</italic><sub><italic>i</italic></sub> &#x02286; <italic>O</italic><sub><italic>j</italic></sub>), and corresponding sets of dual rectangles <italic>R</italic><sub><italic>i</italic></sub> and <italic>R</italic><sub><italic>j</italic></sub>. Suppose, <italic>O</italic> and <italic>R</italic> are the set of all objects and dual rectangles, respectively. Let us consider a spatial object <italic>o</italic><sub><italic>k</italic></sub> &#x02208; <italic>O</italic>\<italic>O</italic><sub><italic>j</italic></sub> and its associated dual rectangle <italic>r</italic><sub><italic>k</italic></sub> &#x02208; <italic>R</italic>\<italic>R</italic><sub><italic>j</italic></sub>. Then there is a possible case where <italic>O</italic><sub><italic>j</italic></sub> conforms to <italic>X</italic>, but neither <italic>O</italic><sub><italic>i</italic></sub> nor <italic>O</italic><sub><italic>i</italic></sub>&#x0222A;{<italic>o</italic><sub><italic>k</italic></sub>} conform to <italic>X</italic>. As <italic>O</italic><sub><italic>j</italic></sub> conforms to <italic>X</italic>, <italic>O</italic><sub><italic>j</italic></sub>&#x0222A;{<italic>o</italic><sub><italic>k</italic></sub>} will conform too. Thus, <italic>f</italic>(<italic>O</italic><sub><italic>i</italic></sub>) &#x0003D; 0, <italic>f</italic>(<italic>O</italic><sub><italic>j</italic></sub>) &#x0003D; |<italic>O</italic><sub><italic>j</italic></sub>|, <italic>f</italic>(<italic>O</italic><sub><italic>i</italic></sub>&#x0222A;{<italic>o</italic><sub><italic>k</italic></sub>}) &#x0003D; 0, <italic>f</italic>(<italic>O</italic><sub><italic>j</italic></sub>&#x0222A;{<italic>o</italic><sub><italic>k</italic></sub>}) &#x0003D; |<italic>O</italic><sub><italic>j</italic></sub>&#x0222A;{<italic>o</italic><sub><italic>k</italic></sub>}| &#x0003D; |<italic>O</italic><sub><italic>j</italic></sub>|&#x0002B;1. Interestingly, we obtain: <italic>f</italic>(<italic>O</italic><sub><italic>i</italic></sub>&#x0222A;{<italic>o</italic><sub><italic>k</italic></sub>}) &#x02212; <italic>f</italic>(<italic>O</italic><sub><italic>i</italic></sub>) &#x0003D; 0 &#x02212; 0 &#x0003D; 0 and <italic>f</italic>(<italic>O</italic><sub><italic>j</italic></sub>&#x0222A;{<italic>o</italic><sub><italic>k</italic></sub>}) &#x02212; <italic>f</italic>(<italic>O</italic><sub><italic>j</italic></sub>) &#x0003D; |<italic>O</italic><sub><italic>j</italic></sub>|&#x0002B;1 &#x02212; |<italic>O</italic><sub><italic>j</italic></sub>| &#x0003D; 1; that means <italic>f</italic>(<italic>O</italic><sub><italic>i</italic></sub>&#x0222A;{<italic>o</italic><sub><italic>k</italic></sub>}) &#x02212; <italic>f</italic>(<italic>O</italic><sub><italic>i</italic></sub>) &#x0003C; <italic>f</italic>(<italic>O</italic><sub><italic>j</italic></sub>&#x0222A;{<italic>o</italic><sub><italic>k</italic></sub>}) &#x02212; <italic>f</italic>(<italic>O</italic><sub><italic>j</italic></sub>) violating the condition of submodularity. Hence, <italic>f</italic> is not submodular.</p>
<p>On the other hand, <italic>g</italic>(<italic>R</italic><sub><italic>i</italic></sub>&#x0222A;{<italic>r</italic><sub><italic>k</italic></sub>}) &#x02212; <italic>g</italic>(<italic>R</italic><sub><italic>i</italic></sub>) &#x0003D; <italic>f</italic>(<italic>O</italic><sub><italic>i</italic></sub>&#x0222A;{<italic>o</italic><sub><italic>k</italic></sub>}) &#x02212; <italic>f</italic>(<italic>O</italic><sub><italic>i</italic></sub>) &#x0003D; 0 &#x02212; 0 &#x0003D; 0 and <italic>g</italic>(<italic>R</italic><sub><italic>j</italic></sub>&#x0222A;{<italic>r</italic><sub><italic>k</italic></sub>}) &#x02212; <italic>g</italic>(<italic>R</italic><sub><italic>j</italic></sub>) &#x0003D; <italic>f</italic>(<italic>O</italic><sub><italic>j</italic></sub>&#x0222A;{<italic>o</italic><sub><italic>k</italic></sub>}) &#x02212; <italic>f</italic>(<italic>O</italic><sub><italic>j</italic></sub>) &#x0003D; |<italic>O</italic><sub><italic>j</italic></sub>|&#x0002B;1 &#x02212; |<italic>O</italic><sub><italic>j</italic></sub>| &#x0003D; 1; which means <italic>g</italic>(<italic>R</italic><sub><italic>i</italic></sub>&#x0222A;{<italic>r</italic><sub><italic>k</italic></sub>}) &#x02212; <italic>g</italic>(<italic>R</italic><sub><italic>i</italic></sub>) &#x0003C; <italic>g</italic>(<italic>R</italic><sub><italic>j</italic></sub>&#x0222A;{<italic>r</italic>}) &#x02212; <italic>g</italic>(<italic>R</italic><sub><italic>j</italic></sub>). Thus, <italic>g</italic> is not submodular too.</p>
<p>Let us consider the example of <xref ref-type="fig" rid="F2">Figure 2</xref>&#x02014;suppose <italic>O</italic><sub><italic>i</italic></sub>={<italic>o</italic><sub>4</sub>, <italic>o</italic><sub>5</sub>, <italic>o</italic><sub>6</sub>, <italic>o</italic><sub>7</sub>} and two new POIs <italic>o</italic><sub>8</sub> and <italic>o</italic><sub>9</sub> arrive from class <italic>A</italic> and <italic>C</italic>, respectively. let <italic>O</italic><sub><italic>j</italic></sub>=<italic>O</italic><sub><italic>i</italic></sub>&#x0222A;{<italic>o</italic><sub>8</sub>} (i.e., <italic>O</italic><sub><italic>i</italic></sub> &#x02286; <italic>O</italic><sub><italic>j</italic></sub>). Now, considering constraints for class A, B, and C, respectively, we have <italic>f</italic>(<italic>O</italic><sub><italic>i</italic></sub>)=(0 &#x0002B; 2 &#x0002B; 2)(0)(1)(1)=0 and <italic>f</italic>(<italic>O</italic><sub><italic>j</italic></sub>)=(1 &#x0002B; 2 &#x0002B; 2)(1)(1)(1)=5, i.e., <italic>f</italic>(<italic>O</italic><sub><italic>i</italic></sub>) &#x02264; <italic>f</italic>(<italic>O</italic><sub><italic>j</italic></sub>), proving monotonicity of <italic>f</italic>. But <italic>f</italic>(<italic>O</italic><sub><italic>i</italic></sub>&#x0222A;{<italic>o</italic><sub>9</sub>})=(0 &#x0002B; 3 &#x0002B; 2)(0)(1)(1)=0 and <italic>f</italic>(<italic>O</italic><sub><italic>j</italic></sub>&#x0222A;{<italic>o</italic><sub>9</sub>})=(1 &#x0002B; 3 &#x0002B; 2)(1)(1)(1)=6. Thus, (<italic>f</italic>(<italic>O</italic><sub><italic>i</italic></sub>&#x0222A;{<italic>o</italic><sub>9</sub>}) &#x02212; <italic>f</italic>(<italic>O</italic><sub><italic>i</italic></sub>) &#x0003D; 0 &#x02212; 0 &#x0003D; 0) &#x0003C; (<italic>f</italic>(<italic>O</italic><sub><italic>j</italic></sub>&#x0222A;{<italic>o</italic><sub>9</sub>}) &#x02212; <italic>f</italic>(<italic>O</italic><sub><italic>j</italic></sub>) &#x0003D; 6 &#x02212; 5 &#x0003D; 1), proving non-submodularity of <italic>f</italic>. Similar examples can be shown for <italic>g</italic> too.</p>
</sec>
<sec>
<title>4.3. Processing of C-MaxRS</title>
<p>Although <italic>f</italic> and <italic>g</italic> are not submodular functions, we show that their monotonicity property can be utilized to derive efficient processing and optimization strategies, similar to the ideas presented in Feng et al. (<xref ref-type="bibr" rid="B13">2016</xref>). For the rest of this section, let us denote <italic>n</italic> = |<italic>O</italic>| = |<italic>R</italic>|.</p>
<sec>
<title>4.3.1. Disjoint and Maximal Regions</title>
<p>The edges of the dual rectangles divide the given spatial field into <italic>disjoint</italic> regions where each disjoint region &#x1D53D;<sub><italic>d</italic><sub><italic>i</italic></sub></sub> is an intersection of a set of rectangles. Consider the examples shown in <xref ref-type="fig" rid="F3">Figure 3i</xref>. Rectangles {<italic>r</italic>1, <italic>r</italic>2, ..., <italic>r</italic>7} divided the space into distinct regions numbered 0 &#x02212; 19, e.g., region 0 is the region outside all rectangles, and region 14 is the intersection of rectangles {<italic>r</italic>4, <italic>r</italic>5, <italic>r</italic>6, <italic>r</italic>7}. Intuitively, all points in a single disjoint region &#x1D53D;<sub><italic>d</italic><sub><italic>i</italic></sub></sub> affects the same set of rectangles, i.e., <italic>A</italic>(<italic>p</italic>) is same for all <italic>p</italic> &#x02208; &#x1D53D;<sub><italic>d</italic><sub><italic>i</italic></sub></sub>. There could be at most <inline-formula><mml:math id="M16"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msup><mml:mrow><mml:mi>n</mml:mi></mml:mrow><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> disjoint regions (shown in Feng et al., <xref ref-type="bibr" rid="B13">2016</xref>). To compute C-MaxRS, a straightforward approach can be to iterate over all the <inline-formula><mml:math id="M17"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msup><mml:mrow><mml:mi>n</mml:mi></mml:mrow><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> disjoint regions (one point from each region) and choose the optimal one&#x02014;thus reducing the search space into a finite point set. For example, we only need to evaluate 20 points for the settings of <xref ref-type="fig" rid="F3">Figure 3i</xref>.</p>
<fig id="F3" position="float">
<label>Figure 3</label>
<caption><p><bold>(i)</bold> Disjoint, <bold>(ii)</bold> Maximal regions, <bold>(iii)</bold> Maximal Slabs, and <bold>(iv)</bold> Slices.</p></caption>
<graphic xlink:href="fdata-03-00020-g0003.tif"/>
</fig>
<p>A disjoint region &#x1D53D;<sub><italic>d</italic><sub><italic>i</italic></sub></sub> is termed as a <italic>maximal region</italic> &#x1D53D;<sub><italic>m</italic><sub><italic>i</italic></sub></sub> if: (1) it is rectangular, and (2) its left, right, bottom, top edges are (respectively) the parts of the left, right, bottom and top edges of some dual rectangles of <italic>R</italic>. In <xref ref-type="fig" rid="F3">Figure 3ii</xref>, region 5 and 14 are maximal regions. For example, the left, right, bottom, and top edges of region 5 is a part of the corresponding edges <italic>r</italic><sub>2</sub>, <italic>r</italic><sub>1</sub>, <italic>r</italic><sub>1</sub>, <italic>r</italic><sub>3</sub> respectively. Feng et al. (<xref ref-type="bibr" rid="B13">2016</xref>) showed that for each distinct region &#x1D53D;<sub><italic>d</italic><sub><italic>i</italic></sub></sub>, there exists a maximal region &#x1D53D;<sub><italic>m</italic><sub><italic>i</italic></sub></sub> such that <italic>A</italic>(&#x1D53D;<sub><italic>d</italic><sub><italic>i</italic></sub></sub>) &#x02286; <italic>A</italic>(&#x1D53D;<sub><italic>m</italic><sub><italic>i</italic></sub></sub>). Using this idea, and the fact that <italic>g</italic>(.) is monotonic, we can shrink the possible search space to only the set of all maximal regions. As an example (see <xref ref-type="fig" rid="F3">Figure 3</xref>), region 4 and 5 are affected by <italic>R</italic><sub>1</sub> &#x0003D; {<italic>r</italic><sub>1</sub>, <italic>r</italic><sub>3</sub>} and <italic>R</italic><sub>2</sub> &#x0003D; {<italic>r</italic><sub>1</sub>, <italic>r</italic><sub>2</sub>, <italic>r</italic><sub>3</sub>}, respectively. As <italic>R</italic><sub>1</sub>&#x02282;<italic>R</italic><sub>2</sub>, so by the monotonicity of <italic>g</italic>, <italic>g</italic>(<italic>R</italic><sub>1</sub>) &#x02264; <italic>g</italic>(<italic>R</italic><sub>2</sub>). So, only evaluating <italic>g</italic>(<italic>R</italic><sub>2</sub>) is sufficient instead of evaluating both <italic>g</italic>(<italic>R</italic><sub>1</sub>) and <italic>g</italic>(<italic>R</italic><sub>2</sub>). Though there could still be <inline-formula><mml:math id="M18"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msup><mml:mrow><mml:mi>n</mml:mi></mml:mrow><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> maximal regions in the worst case, the actual number in practice is much lower (compared to disjoint regions).</p>
</sec>
<sec>
<title>4.3.2. Maximal Slabs and Slices</title>
<p>A <italic>maximal slab</italic> is the area between two horizontal lines in the space where the top line passes along the top edge of a dual rectangle and bottom one passes along the bottom edge of a dual rectangle, and the area between two horizontal lines contains no top or bottom edge of any other dual rectangles. In <xref ref-type="fig" rid="F3">Figure 3iii</xref>, there are three maximal slabs, enclosed by the top and bottom edges of rectangles {<italic>r</italic><sub>3</sub>, <italic>r</italic><sub>1</sub>}, {<italic>r</italic><sub>4</sub>, <italic>r</italic><sub>3</sub>}, and {<italic>r</italic><sub>6</sub>, <italic>r</italic><sub>5</sub>} (top edges are solid line, and bottom edges are dotted lines). According to Feng et al. (<xref ref-type="bibr" rid="B13">2016</xref>), each maximal region intersects at least one maximal slab&#x02014;i.e., the solution space can be reduced to the interior of all the maximal slabs only. As maximal slabs are defined based on one top and one bottom edge of dual rectangles, there could be at most <inline-formula><mml:math id="M19"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>n</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> maximal slabs.</p>
<p>All the maximal slabs can be retrieved using a horizontal sweep line algorithm in a bottom-up manner. A set is maintained to keep track of the rectangles intersecting the current slab, and a <italic>flag</italic> to indicate the type of the last horizontal edge processed. When the sweep line is at the bottom (top) edge of a rectangle, it is inserted into (deleted from) the set and <italic>flag</italic> is set to bottom (top). Additionally, when processing a top edge of a rectangle, the algorithm checks whether a maximal slab is encountered (i.e., currently <italic>flag</italic>=bottom). We can compute the upper bound for a slab by applying <italic>g</italic>(.) on the rectangles intersecting that slab, i.e., if <italic>R</italic><sub><italic>s</italic><sub><italic>i</italic></sub></sub> is the set of rectangles that intersects slab &#x1D53D;<sub><italic>s</italic><sub><italic>i</italic></sub></sub>, then the upper bound of <italic>g</italic>(<italic>p</italic>) for any point <italic>p</italic> &#x02208; &#x1D53D;<sub><italic>s</italic><sub><italic>i</italic></sub></sub> is <italic>g</italic>(<italic>R</italic><sub><italic>s</italic><sub><italic>i</italic></sub></sub>). For example, in <xref ref-type="fig" rid="F3">Figure 3iii</xref>, {<italic>r</italic><sub>4</sub>, <italic>r</italic><sub>5</sub>, <italic>r</italic><sub>6</sub>, <italic>r</italic><sub>7</sub>} intersect the bottommost slab. So, the upper bound for that slab is <italic>g</italic>({<italic>r</italic><sub>4</sub>, <italic>r</italic><sub>5</sub>, <italic>r</italic><sub>6</sub>, <italic>r</italic><sub>7</sub>}) &#x0003D; 0 (as no members of class A present&#x02014;not conforming to the introduced constraints in section 1).</p>
<p>Finally, the monotonicity of <italic>g</italic> allows us to adapt another optimization technique introduced in Feng et al. (<xref ref-type="bibr" rid="B13">2016</xref>)&#x02014;<italic>slices</italic> (see <xref ref-type="fig" rid="F3">Figure 3iv</xref>). The idea is to divide the whole space into vertical slices (along <italic>x</italic>-axis). The width of the slices is query-dependent, i.e., &#x003B8; &#x000D7; <italic>b</italic>, where &#x003B8; is a real positive constant value (&#x003B8; &#x0003E; 1 and optimal value can be tuned empirically) and <italic>b</italic> is the width of the query rectangle <italic>r</italic>. After dividing the space into slices, we retrieve the slabs within each slice using the horizontal sweep-line algorithm described above and obtain upper-bound of a slice by computing the maximum upper-bound among all the slabs within that slice. We can then process the slices in a greedy manner&#x02014;sort them in order of their upper-bounds and process one by one until the currently obtained result is greater than the upper-bounds of the remaining slices. Similar greedy approach can be adopted to process the maximal slabs within each slice. As an example, suppose there are four slices {<italic>s</italic><sub>1</sub>, <italic>s</italic><sub>2</sub>, <italic>s</italic><sub>3</sub>, <italic>s</italic><sub>4</sub>} with upper bounds {8, 3, 5, 2}, respectively. The order in which the slices will be processed is: {<italic>s</italic><sub>1</sub>, <italic>s</italic><sub>3</sub>, <italic>s</italic><sub>2</sub>, <italic>s</italic><sub>4</sub>}. Assume that after processing <italic>s</italic><sub>1</sub>, current optimal <italic>g</italic> value is 3. So there is a possibility the optimal solution within <italic>s</italic><sub>3</sub> might exceed the current overall optimal solution of 3. After processing <italic>s</italic><sub>3</sub>, if the result is 4, then processing <italic>s</italic><sub>2</sub> and <italic>s</italic><sub>4</sub> is unnecessary. Slices allow more pruning than slabs, and also <inline-formula><mml:math id="M20"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>n</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> maximal slabs is processed in all the slices (see Feng et al., <xref ref-type="bibr" rid="B13">2016</xref>).</p>
</sec>
</sec>
</sec>
<sec id="s5">
<title>5. C-MaxRS in Data Updates</title>
<p>We now proceed with introducing novel techniques to deal with more realistic scenarios, i.e., data arriving in streams with the possibility of objects appearing and disappearing at different time instants. Using the approach of the basic C-MaxRS problem presented in previous section as a foundation, we augment the solution with compact data-structures and pruning strategies that enable effective handling of data streams environment.</p>
<sec>
<title>5.1. Data Structures</title>
<p>Before proceeding with the details of the algorithms and pruning schemes, we describe the data structures used. We introduce two necessary data structures: quadtree (denoted <italic>QTree</italic>) and a self-balanced binary search tree (denoted <italic>SliceUpperBoundBST</italic>), and describe the details of our representation of slices. We re-iterate that while Feng et al. (<xref ref-type="bibr" rid="B13">2016</xref>) tackled the problem of best-placement with respect to an aggregate function, we are considering different constraints&#x02014;class membership. In addition, we do not confine to a limited time-window. This is why, in addition to the quadtree used in Feng et al. (<xref ref-type="bibr" rid="B13">2016</xref>), we needed self-balancing binary tree to be invoked as dictated by the dynamics of the modifications.</p>
<sec>
<title>5.1.1. QTree</title>
<p>We need to process a large number of (variants of) range queries when computing <italic>f</italic> for any point, i.e., finding intersecting rectangles for a given rectangle. To ensure this is processed efficiently, we use quadtree (Samet, <xref ref-type="bibr" rid="B35">1990</xref>)&#x02014;a tree-based structure ensuring fast (<inline-formula><mml:math id="M21"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mo class="qopname">log</mml:mo><mml:mi>n</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula>) insertion, deletion, retrieval and aggregate operations in 2D space. <italic>QTree</italic> recursively partitions &#x1D53D; into four equal sized rectangular regions until each leaf only contains one POI.</p>
</sec>
<sec>
<title>5.1.2. <italic>SliceUpperBoundBST</italic></title>
<p>Recall that the algorithm proposed in section 4.3 iterates through the slices in decreasing order of their maximum possible utility values (upper-bounds). Let us assume there are total <italic>s</italic> number of slices. To achieve this for basic C-MaxRS, sorting the slices in order is sufficient (<inline-formula><mml:math id="M22"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>s</mml:mi><mml:mo class="qopname">log</mml:mo><mml:mi>s</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> operation). However, given the possibility of appearance (<italic>e</italic><sup>&#x0002B;</sup>) and disappearance (<italic>e</italic><sup>&#x02212;</sup>) events in dynamic streaming scenarios, the upper-bounds of slices (and their respective order) may change frequently with time. To deal with these efficiently, we introduce a balanced binary search tree (<italic>SliceUpperBoundBST</italic>, see Nievergelt and Reingold, <xref ref-type="bibr" rid="B31">1973</xref>) in our data structures instead of maintaining a sorted list whenever an event occurs. Different kinds of self-balancing binary search tree (e.g., AVL tree, Red-black tree, Splay tree, etc.) can be used for this purpose. We used AVL tree in our implementation. If there are &#x003F5; number of dynamic events and <italic>s</italic> number of slices, sorting them on each event would incur a total of <inline-formula><mml:math id="M23"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>&#x003F5;</mml:mi><mml:mo>&#x0002B;</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mi>s</mml:mi><mml:mo class="qopname">log</mml:mo><mml:mi>s</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> time-complexity. Whereas we can build a balanced BST <italic>SliceUpperBoundBST</italic> initially in <inline-formula><mml:math id="M24"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>s</mml:mi><mml:mo class="qopname">log</mml:mo><mml:mi>s</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula>, and update the tree at each event in <inline-formula><mml:math id="M25"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mo class="qopname">log</mml:mo><mml:mi>s</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> time. Thus the total cost of maintaining the sorted slices via <italic>SliceUpperBoundBST</italic> is <inline-formula><mml:math id="M26"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>s</mml:mi><mml:mo class="qopname">log</mml:mo><mml:mi>s</mml:mi><mml:mo>&#x0002B;</mml:mo><mml:mi>&#x003F5;</mml:mi><mml:mo class="qopname">log</mml:mo><mml:mi>s</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> time. As in real-world applications running for a long time, we would incur large values of both &#x003F5; and <italic>s</italic>, in which case, using <italic>SliceUpperBoundBST</italic> is much more efficient.</p>
<p>To traverse the slices in decreasing order via <italic>SliceUpperBoundBST</italic>, an in-order traversal from left to right order is needed (assuming, higher values are stored on the left children), and vice versa. <italic>SliceUpperBoundBST</italic> arranges the slices based on their upper bounds of <italic>g</italic>. In <xref ref-type="fig" rid="F4">Figure 4</xref>, a sample slice structure (of 7 slices) and their respective maximum utility upper bounds (dummy values) are shown for two events at different times <italic>t</italic><sub>1</sub> and <italic>t</italic><sub>2</sub>. The corresponding <italic>SliceUpperBoundBST</italic> structure for both cases is shown as well. The process of accessing the slices in decreasing order (an in-order traversal) is demonstrated in <xref ref-type="fig" rid="F4">Figure 4ii</xref>.</p>
<fig id="F4" position="float">
<label>Figure 4</label>
<caption><p><italic>SliceUpperBoundBST</italic> at time <bold>(i)</bold> <italic>t</italic><sub>1</sub> and <bold>(ii)</bold> <italic>t</italic><sub>2</sub>.</p></caption>
<graphic xlink:href="fdata-03-00020-g0004.tif"/>
</fig>
</sec>
<sec>
<title>5.1.3. List of Slices</title>
<p>We use a list <italic>S</italic><sub><italic>slice</italic></sub> (where |<italic>S</italic><sub><italic>slice</italic></sub>| = <italic>s</italic>) to maintain the slices and their related information. Each slice <italic>s</italic><sub><italic>i</italic></sub> &#x02208; <italic>S</italic><sub><italic>slice</italic></sub> is represented as a 6&#x02212;tuple (<italic>id, R, S</italic><sub><italic>slabs</italic></sub>, <italic>p</italic><sub><italic>c</italic></sub>, <italic>lazy, maxregsearched</italic>). These fields are described as follows:</p>
<list list-type="bullet">
<list-item><p><bold><italic>id</italic></bold>: A numeric identification number for the slice.</p></list-item>
<list-item><p><bold><italic>R</italic></bold>: The set of rectangles currently intersecting with the corresponding slice.</p></list-item>
<list-item><p><bold><italic>S</italic><sub><italic>slabs</italic></sub></bold>: The set of maximal slabs in the interior of the slice.</p></list-item>
<list-item><p><bold><italic>p</italic><sub><italic>c</italic></sub></bold>: The local optimum point within the slice.</p></list-item>
<list-item><p><bold><italic>lazy</italic></bold>: This field is used to reduce computational overhead in certain scenarios. While processing streaming data, there are cases when an <italic>e</italic><sup>&#x0002B;</sup> or <italic>e</italic><sup>&#x02212;</sup> event may alter the local solution (optimal point) for a particular slice, but overall, the global solution is guaranteed to remain unchanged. In those cases, we will not re-evaluate the local processing of that slice (i.e., pruning)&#x02014;rather will set the <italic>lazy</italic> field to <italic>true</italic>. Later, when the possibility of a global solution change arises&#x02014;local optimal points are re-processed for all the <italic>lazy</italic> marked slices to sync with the up-to-date state. Initially, <italic>lazy</italic> fields for all slices are set to <italic>false</italic>.</p></list-item>
<list-item><p><bold><italic>maxregsearched</italic></bold>: This field is used to indicate whether the slice&#x00027;s local solution is up-to-date or not. <italic>maxregsearched</italic> is set to <italic>true</italic> when the corresponding slice is evaluated and its local maximal point is stored in <italic>p</italic><sub><italic>c</italic></sub>. Initially, <italic>maxregsearched</italic> is set to <italic>false</italic> for all the slices. While processing C-MaxRS by iterating through the slices, all the slices with this field set to <italic>true</italic> are not re-evaluated (skipped).</p></list-item>
</list>
</sec>
</sec>
<sec>
<title>5.2. Base Method</title>
<p>In this section, we start by introducing two related functions (sub-methods), and then proceed with describing the details of the base method to process C-MaxRS.</p>
<sec>
<title>5.2.1. PrepareSlices(<italic>S</italic><sub><italic>slice</italic></sub>)</title>
<p>Function 1 takes <italic>S</italic><sub><italic>slice</italic></sub> as input and sets up different fields of each slice accordingly. For each slice <italic>s</italic><sub><italic>i</italic></sub> &#x02208; <italic>S</italic><sub><italic>slice</italic></sub>, their respective <italic>R</italic> and <italic>S</italic><sub><italic>slabs</italic></sub> are computed (lines 2&#x02013;3), and other variables are properly initialized (lines 4&#x02013;6). In line 3, the maximum upper bounds of <italic>g</italic> (denoted <italic>g</italic><sub><italic>maxub</italic></sub>) among all the slices is retrieved as well, while <italic>ScanSlab</italic> is the horizontal sweep-line procedure discussed in section 4.3.2. <italic>SliceUpperBoundBST</italic> is also build via line 7.</p>
<sec>
<title>Time-Complexity</title>
<p>While analyzing time-complexities, we will denote |<italic>S</italic><sub><italic>slice</italic></sub>| = <italic>s</italic> and number of rectangles (and objects too) as <italic>n</italic>. Suppose all of the slices in <italic>S</italic><sub><italic>slice</italic></sub> is passed to Function 1 for processing. In worst case scenario, line 2 takes <inline-formula><mml:math id="M27"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>n</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> time. Feng et al. (<xref ref-type="bibr" rid="B13">2016</xref>) shows <italic>Scanslab</italic>() (i.e., line 3) aggregately takes at most <inline-formula><mml:math id="M28"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>n</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> time for all the slices together. Any <italic>SliceUpperBoundBST</italic> operations (cf., line 4) need <inline-formula><mml:math id="M29"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mo class="qopname">log</mml:mo><mml:mi>s</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> time. Thus, the overall time-complexity of Function 1 is <inline-formula><mml:math id="M30"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>s</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>n</mml:mi><mml:mo>&#x0002B;</mml:mo><mml:mo class="qopname">log</mml:mo><mml:mi>s</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x0002B;</mml:mo><mml:mi>n</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula>&#x02014;or, <inline-formula><mml:math id="M31"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>s</mml:mi><mml:mi>n</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> (as typically, <italic>n</italic> &#x0003E; <italic>s</italic>).</p>
<table-wrap position="float">
<label>Function 1</label>
<caption><p>PrepareSlices(<italic>S<sub>slice</sub></italic>)</p></caption>
<graphic xlink:href="fdata-03-00020-i0001.tif"/>
</table-wrap>
</sec>
</sec>
<sec>
<title>5.2.2. SliceSearchMR(<inline-formula><mml:math id="M32"><mml:msubsup><mml:mrow><mml:mstyle mathvariant="bold"><mml:mi>p</mml:mi></mml:mstyle></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:math></inline-formula>)</title>
<p>Function 2 takes the current global maximal point <inline-formula><mml:math id="M33"><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:math></inline-formula> as input and returns the updated solution. The function iterates through all the slices via in-order traversal of <italic>SliceUpperBoundBST</italic> from the <italic>root</italic> (lines 1&#x02013;2). The process is terminated if <italic>g</italic><sub><italic>maxub</italic></sub> of the current slice is &#x02264; of current maximum utility value <inline-formula><mml:math id="M34"><mml:mi>g</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> (lines 3&#x02013;4), or when all the slices are evaluated. At each iteration, we check whether there exists an already computed solution (unchanged) for the slice. If so, we avoid recomputing it (lines 6&#x02013;7), otherwise we retrieve the current optimal solution for the slice and update related variables accordingly (lines 9&#x02013;11). Finally, we update the global optimal point by comparing it with the local solution (lines 12&#x02013;13).</p>
<sec>
<title>Time-Complexity</title>
<p>In the worst case scenario, all the nodes in <italic>SliceUpperBoundBST</italic> are traversed in Function 2. A stack based implementation of in-order traversal takes <inline-formula><mml:math id="M35"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>s</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> time, and computing the <italic>g</italic>() function can take up to <inline-formula><mml:math id="M36"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>n</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> time. Thus, the overall worst-case complexity for Function 2 is <inline-formula><mml:math id="M37"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>s</mml:mi><mml:mi>n</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula>.</p>
<table-wrap position="float">
<label>Function 2</label>
<caption><p>SliceSearchMR<inline-formula><mml:math id="M38"><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula></p></caption>
<graphic xlink:href="fdata-03-00020-i0002.tif"/>
</table-wrap>
</sec>
</sec>
<sec>
<title>5.2.3. SolveCMaxRS</title>
<p>Algorithm 1 presents the base method <italic>SolveCMaxRS</italic> that retrieves the optimal point <inline-formula><mml:math id="M48"><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:math></inline-formula> from a snapshot of the database. <inline-formula><mml:math id="M49"><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:math></inline-formula>, <italic>QTree</italic> and <italic>SliceUpperBoundBST</italic> are initialized, and the dual rectangles of the given POIs <italic>O</italic> is computed in lines 1&#x02013;4. In lines 5&#x02013;6, we update the <italic>QTree</italic> by inserting all the dual rectangles in the structure. Line 7 retrieves the list of slices using the given width &#x003B8;<italic>b</italic>. Finally, the method uses Function 1 to initialize the fields of slices properly in line 8, and computes the C-MaxRS solution using Function 2 in line 9.</p>
<sec>
<title>Time-Complexity</title>
<p>Initializing and inserting all the rectangles in the quadtree takes <inline-formula><mml:math id="M50"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>n</mml:mi><mml:mo class="qopname">log</mml:mo><mml:mi>n</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> time along with a random initialization of <italic>SliceUpperBoundBST</italic> in <inline-formula><mml:math id="M51"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>s</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula>. Listing all the slices (line 7) also takes <inline-formula><mml:math id="M52"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>s</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> time. Using the complexities of <italic>PrepareSlices</italic>() and <italic>SliceSearchMR</italic>() from previous discussion, we can conclude that worst-case time complexity of Algorithm 1 is <inline-formula><mml:math id="M53"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>n</mml:mi><mml:mo class="qopname">log</mml:mo><mml:mi>n</mml:mi><mml:mo>&#x0002B;</mml:mo><mml:mi>s</mml:mi><mml:mi>n</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula>.</p>
<table-wrap position="float">
<label>Algorithm 1</label>
<caption><p>SolveCMaxRS(<italic>O, a, b</italic>)</p></caption>
<graphic xlink:href="fdata-03-00020-i0003.tif"/>
</table-wrap>
</sec>
</sec>
</sec>
<sec>
<title>5.3. Event-Based Pruning</title>
<p>Recall that, to cope with the challenges of real-time dynamic updates of the point space via data streams, we opted for the event-driven approach rather than the time-driven approach. Our goal is to maintain correct solution by performing instant updates during an event. In case of spatial data updates, a straightforward approach is to use Algorithm 1 whenever an event occurs. We now proceed to identify specific properties/states of events (both <italic>e</italic><sup>&#x0002B;</sup> and <italic>e</italic><sup>&#x02212;</sup>) that allow us to prune unnecessary computations while processing them. Note that, in this settings, a bunch of <italic>e</italic><sup>&#x0002B;</sup> and <italic>e</italic><sup>&#x02212;</sup> events can occur at the same time.</p>
<sec>
<title>5.3.1. Pruning in <italic>e</italic><sup>&#x02212;</sup></title>
<p>To derive an optimization technique for <italic>e</italic><sup>&#x02212;</sup> events, let us first establish few related important results.</p>
<p>Lemma 3. <italic>Removal of a rectangle</italic> <italic>r</italic><sub><italic>e</italic></sub> <italic>(object</italic> <italic>o</italic><sub><italic>e</italic></sub>) <italic>from the point space</italic> &#x1D53D; <italic>never increases the value of</italic> <italic>g</italic>(<italic>A</italic>(<italic>p</italic>)) <italic>(correspondingly</italic> <italic>f</italic>(<italic>A</italic>(<italic>p</italic>))), &#x02200;<italic>p</italic> &#x02208; <italic>P</italic>.</p>
<p><italic>Proof</italic>: Denote the removed rectangle as <italic>r</italic><sub><italic>e</italic></sub>. We consider two cases:</p>
<list list-type="bullet">
<list-item><p><italic>r</italic><sub><italic>e</italic></sub> &#x02208; <italic>A</italic>(<italic>p</italic>): After the removal of <italic>r</italic><sub><italic>e</italic></sub>, the set of rectangles affected by <italic>p</italic> becomes <italic>A</italic>(<italic>p</italic>)\{<italic>r</italic><sub><italic>e</italic></sub>}. Now, <italic>A</italic>(<italic>p</italic>)\{<italic>r</italic><sub><italic>e</italic></sub>}&#x02282;<italic>A</italic>(<italic>p</italic>). Hence, from Theorem 1, <italic>g</italic>(<italic>A</italic>(<italic>p</italic>)\{<italic>r</italic><sub><italic>e</italic></sub>}) &#x02264; <italic>g</italic>(<italic>A</italic>(<italic>p</italic>)). Thus, the removal in this case does not increase <italic>g</italic>(<italic>A</italic>(<italic>p</italic>)).</p></list-item>
<list-item><p><italic>r</italic><sub><italic>e</italic></sub> &#x02209; <italic>A</italic>(<italic>p</italic>)): After removal of <italic>r</italic><sub><italic>e</italic></sub>, the set of rectangles affected by <italic>p</italic> is still <italic>A</italic>(<italic>p</italic>). Hence, <italic>g</italic>(<italic>A</italic>(<italic>p</italic>)) remains unchanged. In this case as well, the removal does not increase <italic>g</italic>(<italic>A</italic>(<italic>p</italic>)).</p></list-item>
</list>
<p>Similarly, we can show a proof for removing an object&#x02014;i.e., <italic>o</italic><sub><italic>e</italic></sub> from &#x1D53D;.</p>
<p>Lemma 3 paves the way for the pruning of slices from being considered a solution at <italic>e</italic><sup>&#x02212;</sup> events.</p>
<p>Lemma 4. <italic>The maximum utility point (global solution)</italic> <inline-formula><mml:math id="M59"><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:math></inline-formula> <italic>is unchanged after the removal of a rectangle</italic> <italic>r</italic><sub><italic>e</italic></sub> <italic>from the space</italic> &#x1D53D; <italic>if</italic> <inline-formula><mml:math id="M60"><mml:msub><mml:mrow><mml:mi>r</mml:mi></mml:mrow><mml:mrow><mml:mi>e</mml:mi></mml:mrow></mml:msub><mml:mo>&#x02209;</mml:mo><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula>.</p>
<p><italic>Proof</italic>: Here, <inline-formula><mml:math id="M61"><mml:msub><mml:mrow><mml:mi>r</mml:mi></mml:mrow><mml:mrow><mml:mi>e</mml:mi></mml:mrow></mml:msub><mml:mo>&#x02209;</mml:mo><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula>. Suppose, after removing <italic>r</italic><sub><italic>e</italic></sub>, <inline-formula><mml:math id="M62"><mml:msup><mml:mrow><mml:mi>A</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> rectangles are affected by <inline-formula><mml:math id="M63"><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:math></inline-formula>. Note that, <inline-formula><mml:math id="M64"><mml:msup><mml:mrow><mml:mi>A</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula>=<inline-formula><mml:math id="M65"><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> (as <inline-formula><mml:math id="M66"><mml:msub><mml:mrow><mml:mi>r</mml:mi></mml:mrow><mml:mrow><mml:mi>e</mml:mi></mml:mrow></mml:msub><mml:mo>&#x02209;</mml:mo><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula>), implying <inline-formula><mml:math id="M67"><mml:mi>g</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msup><mml:mrow><mml:mi>A</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:mi>g</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula>. Thus, the utility values of <inline-formula><mml:math id="M68"><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:math></inline-formula> remains the same. By Lemma 3, the removal of <italic>r</italic><sub><italic>e</italic></sub> does not increase the utility value of <italic>p</italic>, &#x02200;<italic>p</italic> &#x02208; <italic>P</italic>. Suppose, the utility value of a point <italic>p</italic>, (<italic>p</italic> &#x02208; <italic>P</italic> and <italic>p</italic> &#x02260; <italic>p</italic><sub><italic>c</italic></sub>), are <italic>g</italic>(<italic>A</italic>(<italic>p</italic>)) and <italic>g</italic>&#x02032;(<italic>A</italic>(<italic>p</italic>)), respectively before and after the removal of <italic>r</italic><sub><italic>e</italic></sub>, then <italic>g</italic>&#x02032;(<italic>A</italic>(<italic>p</italic>)) &#x02264; <italic>g</italic>(<italic>A</italic>(<italic>p</italic>)). Again, <inline-formula><mml:math id="M69"><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:math></inline-formula> being the maximal point, <inline-formula><mml:math id="M70"><mml:mi>g</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x02264;</mml:mo><mml:mi>g</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula>, <inline-formula><mml:math id="M71"><mml:mo>&#x02200;</mml:mo><mml:mi>p</mml:mi><mml:mo>&#x02208;</mml:mo><mml:mi>P</mml:mi><mml:mo>,</mml:mo><mml:mi>p</mml:mi><mml:mo>&#x02260;</mml:mo><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:math></inline-formula>. Above mentioned inequalities imply that <inline-formula><mml:math id="M72"><mml:msup><mml:mrow><mml:mi>g</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x02264;</mml:mo><mml:mi>g</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msup><mml:mrow><mml:mi>A</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula>, <inline-formula><mml:math id="M73"><mml:mo>&#x02200;</mml:mo><mml:mi>p</mml:mi><mml:mo>&#x02208;</mml:mo><mml:mi>P</mml:mi><mml:mo>,</mml:mo><mml:mi>p</mml:mi><mml:mo>&#x02260;</mml:mo><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:math></inline-formula>, meaning <inline-formula><mml:math id="M74"><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:math></inline-formula> remains unchanged.</p>
<p>Using Lemma 4, we can prune local slice processing at an <italic>e</italic><sup>&#x02212;</sup> event, if <inline-formula><mml:math id="M75"><mml:msub><mml:mrow><mml:mi>r</mml:mi></mml:mrow><mml:mrow><mml:mi>e</mml:mi></mml:mrow></mml:msub><mml:mo>&#x02209;</mml:mo><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula>, i.e., we need to only update <italic>QTree</italic> in this case.</p>
<p>Lemma 5. <italic>The utility value of the maximal point</italic> <inline-formula><mml:math id="M76"><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:math></inline-formula> <italic>is changed after the removal of a rectangle</italic> <italic>r</italic><sub><italic>e</italic></sub> if <inline-formula><mml:math id="M77"><mml:msub><mml:mrow><mml:mi>r</mml:mi></mml:mrow><mml:mrow><mml:mi>e</mml:mi></mml:mrow></mml:msub><mml:mo>&#x02208;</mml:mo><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula>.</p>
<p><italic>Proof</italic>: If <inline-formula><mml:math id="M78"><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:math></inline-formula> is returned as the maximal point, then <inline-formula><mml:math id="M79"><mml:mi>g</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x0003E;</mml:mo><mml:mn>0</mml:mn></mml:math></inline-formula> (i.e., we have a solution). After the removal of <italic>r</italic><sub><italic>e</italic></sub>, the set of rectangles affected by <inline-formula><mml:math id="M80"><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:math></inline-formula> becomes <inline-formula><mml:math id="M81"><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>-</mml:mo><mml:mrow><mml:mo>{</mml:mo><mml:mrow><mml:msub><mml:mrow><mml:mi>r</mml:mi></mml:mrow><mml:mrow><mml:mi>e</mml:mi></mml:mrow></mml:msub></mml:mrow><mml:mo>}</mml:mo></mml:mrow></mml:math></inline-formula>. There are two possible cases:</p>
<list list-type="bullet">
<list-item><p><inline-formula><mml:math id="M82"><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>-</mml:mo><mml:mrow><mml:mo>{</mml:mo><mml:mrow><mml:msub><mml:mrow><mml:mi>r</mml:mi></mml:mrow><mml:mrow><mml:mi>e</mml:mi></mml:mrow></mml:msub></mml:mrow><mml:mo>}</mml:mo></mml:mrow></mml:math></inline-formula> conforms to <italic>X</italic>: In this scenario, <inline-formula><mml:math id="M83"><mml:mi>g</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>-</mml:mo><mml:mi>g</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>-</mml:mo><mml:mrow><mml:mo>{</mml:mo><mml:mrow><mml:msub><mml:mrow><mml:mi>r</mml:mi></mml:mrow><mml:mrow><mml:mi>e</mml:mi></mml:mrow></mml:msub></mml:mrow><mml:mo>}</mml:mo></mml:mrow></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:mo>|</mml:mo><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>|</mml:mo><mml:mo>-</mml:mo><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mo>|</mml:mo><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>|</mml:mo><mml:mo>-</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:math></inline-formula>.</p></list-item>
<list-item><p><inline-formula><mml:math id="M84"><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>-</mml:mo><mml:mrow><mml:mo>{</mml:mo><mml:mrow><mml:msub><mml:mrow><mml:mi>r</mml:mi></mml:mrow><mml:mrow><mml:mi>e</mml:mi></mml:mrow></mml:msub></mml:mrow><mml:mo>}</mml:mo></mml:mrow></mml:math></inline-formula> does not conform to <italic>X</italic>: Here, <inline-formula><mml:math id="M85"><mml:mi>g</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>-</mml:mo><mml:mi>g</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>-</mml:mo><mml:mrow><mml:mo>{</mml:mo><mml:mrow><mml:msub><mml:mrow><mml:mi>r</mml:mi></mml:mrow><mml:mrow><mml:mi>e</mml:mi></mml:mrow></mml:msub></mml:mrow><mml:mo>}</mml:mo></mml:mrow></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:mo>|</mml:mo><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>|</mml:mo><mml:mo>-</mml:mo><mml:mn>0</mml:mn><mml:mo>=</mml:mo><mml:mo>|</mml:mo><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>|</mml:mo></mml:math></inline-formula>.</p></list-item>
</list>
<p>In both cases, <inline-formula><mml:math id="M86"><mml:mi>g</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> is changed.</p>
<p>Lemma 5 implies that, if a rectangle removed at an <italic>e</italic><sup>&#x02212;</sup> event is in <inline-formula><mml:math id="M87"><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula>, we need to re-evaluate local solutions for the respective slice(s), and update global maximal point if necessary.</p>
<p>Lemma 6. <italic>Suppose a point space</italic> <italic>P</italic> <italic>is divided into a set of slices</italic> <italic>S</italic><sub><italic>slice</italic></sub>, <italic>and the slice containing the maximum utility point</italic> <inline-formula><mml:math id="M88"><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:math></inline-formula> <italic>is</italic> <italic>s</italic><sub><italic>max</italic></sub>. <italic>Let</italic>, <italic>S</italic><sub><italic>s</italic></sub> <italic>be another set of slices, where</italic> <italic>S</italic><sub><italic>s</italic></sub>&#x02282;<italic>S</italic><sub><italic>slice</italic></sub> <italic>and</italic> <italic>s</italic><sub><italic>max</italic></sub> &#x02209; <italic>S</italic><sub><italic>s</italic></sub>. <italic>Subsequently, the removal of a rectangle</italic> <italic>r</italic><sub><italic>e</italic></sub> <italic>spanning through only the slices in</italic> <italic>S</italic><sub><italic>s</italic></sub>, <italic>i.e., affecting only the local maximum utility values of</italic> <italic>s</italic><sub><italic>i</italic></sub>, &#x02200;<italic>s</italic><sub><italic>i</italic></sub> &#x02208; <italic>S</italic><sub><italic>s</italic></sub>, <italic>does not have any effect on the global maximum utility point</italic> <inline-formula><mml:math id="M89"><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:math></inline-formula>.</p>
<p><italic>Proof</italic>: Let <inline-formula><mml:math id="M90"><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>l</mml:mi><mml:mi>o</mml:mi><mml:mi>c</mml:mi><mml:mi>a</mml:mi><mml:mi>l</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:math></inline-formula> be the maximum utility point of a slice <italic>s</italic><sub><italic>i</italic></sub> &#x02208; <italic>S</italic><sub><italic>s</italic></sub>. &#x02200;<italic>p</italic> &#x02208; <italic>s</italic><sub><italic>i</italic></sub> where <italic>s</italic><sub><italic>i</italic></sub> &#x02208; <italic>S</italic><sub><italic>s</italic></sub>, <inline-formula><mml:math id="M91"><mml:mi>g</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x02265;</mml:mo><mml:mi>g</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>l</mml:mi><mml:mi>o</mml:mi><mml:mi>c</mml:mi><mml:mi>a</mml:mi><mml:mi>l</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> and <inline-formula><mml:math id="M92"><mml:mi>g</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>l</mml:mi><mml:mi>o</mml:mi><mml:mi>c</mml:mi><mml:mi>a</mml:mi><mml:mi>l</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x02265;</mml:mo><mml:mi>g</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula>. According to Lemma 3, after the removal of <italic>r</italic><sub><italic>e</italic></sub>, for any <italic>s</italic><sub><italic>i</italic></sub> &#x02208; <italic>S</italic><sub><italic>s</italic></sub>, <italic>g</italic>(<italic>A</italic>(<italic>p</italic> &#x02212; {<italic>r</italic><sub><italic>e</italic></sub>})) &#x02264; <italic>g</italic>(<italic>A</italic>(<italic>p</italic>)). From the above three inequalities, we can deduce: &#x02200;<italic>p</italic> &#x02208; <italic>s</italic><sub><italic>i</italic></sub> where <italic>s</italic><sub><italic>i</italic></sub> &#x02208; <italic>S</italic><sub><italic>s</italic></sub>, <inline-formula><mml:math id="M93"><mml:mi>g</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>-</mml:mo><mml:mrow><mml:mo>{</mml:mo><mml:mrow><mml:msub><mml:mrow><mml:mi>r</mml:mi></mml:mrow><mml:mrow><mml:mi>e</mml:mi></mml:mrow></mml:msub></mml:mrow><mml:mo>}</mml:mo></mml:mrow></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x02264;</mml:mo><mml:mi>g</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula>. This holds true &#x02200;<italic>s</italic><sub><italic>i</italic></sub>&#x02208;<italic>S</italic><sub><italic>s</italic></sub>. Thus, <inline-formula><mml:math id="M94"><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:math></inline-formula> still remains the maximum utility point (as <italic>s</italic><sub><italic>max</italic></sub> is not altered), and <italic>s</italic><sub><italic>max</italic></sub> is still the slice containing <inline-formula><mml:math id="M95"><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:math></inline-formula>.</p>
<p>Lemma 6 implies that, if the slice containing global maximal point <inline-formula><mml:math id="M96"><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:math></inline-formula> is unchanged while some other slices are altered, then following the update of <italic>QTree</italic>, we can delay the processing of altered slices at that time instance as it is not going to affect the global maximal answer anyway. For this reason, we incorporated the <italic>lazy</italic> field in each slice. In this case, we set <italic>lazy</italic> to <italic>true</italic> for each of these altered slices, indicating that they should be re-evaluated later only when the slice containing global maximal point is altered.</p>
</sec>
<sec>
<title>5.3.2. Pruning in <italic>e</italic><sup>&#x0002B;</sup></title>
<p>During an <italic>e</italic><sup>&#x0002B;</sup> event, a rectangle (object) appears in the given space &#x1D53D;. We now present two lemmas, based on which we derive pruning strategies at <italic>e</italic><sup>&#x0002B;</sup> events.</p>
<p>Lemma 7. <italic>Addition of a rectangle</italic> <italic>r</italic><sub><italic>e</italic></sub> <italic>(object</italic> <italic>o</italic><sub><italic>e</italic></sub>) <italic>in the given space &#x1D53D; never decreases the value of</italic> <italic>g</italic>(<italic>A</italic>(<italic>p</italic>)) <italic>(correspondingly</italic> <italic>f</italic>(<italic>A</italic>(<italic>p</italic>))), &#x02200;<italic>p</italic> &#x02208; <italic>P</italic>.</p>
<p><italic>Proof</italic>: Let the added rectangle be <italic>r</italic><sub><italic>e</italic></sub>. We consider two cases:</p>
<list list-type="bullet">
<list-item><p><italic>r</italic><sub><italic>e</italic></sub> &#x02208; <italic>A</italic>(<italic>p</italic>): After the addition of <italic>r</italic><sub><italic>e</italic></sub>, the set of rectangles affected by <italic>p</italic> becomes <italic>A</italic>(<italic>p</italic>)&#x0222A;{<italic>r</italic><sub><italic>e</italic></sub>}. Now, <italic>A</italic>(<italic>p</italic>)&#x02282;<italic>A</italic>(<italic>p</italic>)&#x0222A;{<italic>r</italic><sub><italic>e</italic></sub>}. Hence, from Theorem 1, <italic>g</italic>(<italic>A</italic>(<italic>p</italic>)&#x0222A;{<italic>r</italic><sub><italic>e</italic></sub>}) &#x02265; <italic>g</italic>(<italic>A</italic>(<italic>p</italic>)). So, in this case <italic>g</italic>(<italic>A</italic>(<italic>p</italic>)) does not decrease.</p></list-item>
<list-item><p><italic>r</italic><sub><italic>e</italic></sub> &#x02209; <italic>A</italic>(<italic>p</italic>)): After addition of <italic>r</italic><sub><italic>e</italic></sub>, the set of rectangles affected by <italic>p</italic> still remains <italic>A</italic>(<italic>p</italic>). Hence, <italic>g</italic>(<italic>A</italic>(<italic>p</italic>)) does not change as well. Thus, <italic>g</italic>(<italic>A</italic>(<italic>p</italic>)) does not decrease in this scenario as well.</p></list-item>
</list>
<p>Similarly, we can show a proof for adding an object&#x02014;i.e., <italic>o</italic><sub><italic>e</italic></sub> to &#x1D53D;.</p>
<p>For <italic>e</italic><sup>&#x02212;</sup> events, we leveraged on ideas like Lemma 3&#x02014;i.e., removal of a rectangle never increases utility value of a point, to devise clever pruning schemes depending on the fact that local or global maximal points are guaranteed to be unchanged in certain scenarios. But, for <italic>e</italic><sup>&#x0002B;</sup> events, those are not applicable as addition of a rectangle <italic>may</italic> increase utility of affected points. Interestingly, though, there are scenarios when the utility values are unchanged, e.g., when <italic>A</italic>(<italic>p</italic>) does not conform to <italic>X</italic>. Also, as shown in the 2nd case of the proof of Lemma 7&#x02014;we only process a slice if its affected by the addition of <italic>r</italic><sub><italic>e</italic></sub>.</p>
<p>Lemma 8. <italic>Suppose, we have a set of classes</italic> <italic>K</italic> = {<italic>k</italic><sub>1</sub>, <italic>k</italic><sub>2</sub>, &#x02026;, <italic>k</italic><sub><italic>m</italic></sub>}, <italic>and are given corresponding</italic> <italic>MinConditionSet</italic> <italic>X</italic> = {<italic>x</italic><sub>1</sub>, <italic>x</italic><sub>2</sub>, &#x02026;, <italic>x</italic><sub><italic>m</italic></sub>}. <italic>Let</italic> <italic>R</italic> <italic>be the set of rectangles overlapping with a slice</italic> <italic>s</italic><sub><italic>i</italic></sub> &#x02208; <italic>S</italic><sub><italic>slice</italic></sub>, <italic>and let</italic> <italic>l</italic><sub><italic>i</italic></sub> <italic>be the number of rectangles of class</italic> <italic>k</italic><sub><italic>i</italic></sub> in <italic>R</italic>. <italic>Then, addition of a rectangle</italic> <italic>r</italic><sub><italic>e</italic></sub> <italic>of class</italic> <italic>k</italic><sub><italic>i</italic></sub> <italic>has no effect on the local maximal solution of</italic> <italic>s</italic><sub><italic>i</italic></sub> <italic>if:</italic></p>
<list list-type="simple">
<list-item><p><italic>(1)</italic> <italic>x</italic><sub><italic>i</italic></sub> &#x02212; <italic>l</italic><sub><italic>i</italic></sub> &#x02265; 2, or</p></list-item>
<list-item><p><italic>(2)</italic> (&#x02203;<italic>l</italic><sub><italic>j</italic></sub> &#x02260; <italic>l</italic><sub><italic>i</italic></sub>) <italic>x</italic><sub><italic>j</italic></sub> &#x02212; <italic>l</italic><sub><italic>j</italic></sub> &#x02265; 1</p></list-item>
</list>
<p><italic>Proof</italic>: (1) In this settings, the maximum possible utility value of <italic>s</italic><sub><italic>i</italic></sub> before addition of <italic>r</italic><sub><italic>e</italic></sub> is 0. Because, even if for a point <italic>p</italic> &#x02208; <italic>s</italic><sub><italic>i</italic></sub>, <italic>A</italic>(<italic>p</italic>) = <italic>R</italic>, then <italic>g</italic>(<italic>A</italic>(<italic>p</italic>))=0 as <italic>l</italic><sub><italic>i</italic></sub> &#x0003C; <italic>x</italic><sub><italic>i</italic></sub> and <italic>R</italic> does not conform to <italic>X</italic>. After the addition of <italic>r</italic><sub><italic>e</italic></sub>, suppose the number of class <italic>k</italic><sub><italic>i</italic></sub> objects in <italic>R</italic> is <inline-formula><mml:math id="M97"><mml:msubsup><mml:mrow><mml:mi>l</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msubsup></mml:math></inline-formula>, i.e., <inline-formula><mml:math id="M98"><mml:msubsup><mml:mrow><mml:mi>l</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msubsup></mml:math></inline-formula>=<italic>l</italic><sub><italic>i</italic></sub> &#x0002B; 1. As given <italic>x</italic><sub><italic>i</italic></sub> &#x02212; <italic>l</italic><sub><italic>i</italic></sub> &#x02265; 2, then <inline-formula><mml:math id="M99"><mml:msubsup><mml:mrow><mml:mi>l</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msubsup><mml:mo>&#x0003C;</mml:mo><mml:msub><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>. Thus, <italic>R</italic> still does not conform to <italic>X</italic>, and maximum possible utility value of <italic>s</italic><sub><italic>i</italic></sub> remains 0.</p>
<p>(2) Similarly, the maximum possible utility value of <italic>s</italic><sub><italic>i</italic></sub> before addition of <italic>r</italic><sub><italic>e</italic></sub> is 0. Because, even if for a point <italic>p</italic> &#x02208; <italic>s</italic><sub><italic>i</italic></sub>, <italic>A</italic>(<italic>p</italic>) = <italic>R</italic>, then <italic>g</italic>(<italic>A</italic>(<italic>p</italic>))=0 as <italic>l</italic><sub><italic>j</italic></sub> &#x0003C; <italic>x</italic><sub><italic>i</italic></sub> for &#x02203;<italic>l</italic><sub><italic>j</italic></sub> &#x02260; <italic>l</italic><sub><italic>i</italic></sub>, and <italic>R</italic> does not conform to <italic>X</italic>. After the addition of <italic>r</italic><sub><italic>e</italic></sub> of class <italic>k</italic><sub><italic>i</italic></sub>, <italic>l</italic><sub><italic>j</italic></sub> remains unchanged. Thus, <italic>R</italic> still does not conform to <italic>X</italic>, and maximum possible utility value of <italic>s</italic><sub><italic>i</italic></sub> remains 0.</p>
<p>Lemma 8 lays out the process of pruning during an <italic>e</italic><sup>&#x0002B;</sup> event. For each slice, we maintain an integer value <italic>diff</italic> (i.e., <italic>x</italic><sub><italic>i</italic></sub> &#x02212; <italic>l</italic><sub><italic>i</italic></sub>) per class in <italic>K</italic> denoting whether the corresponding upper-bound for that class has been met or not. When adding a rectangle of class <italic>k</italic><sub><italic>i</italic></sub>, for each affected slices, we first check whether <italic>diff</italic><sub><italic>i</italic></sub> &#x02265; 2, and if so&#x02014;we just update <italic>diff</italic><sub><italic>i</italic></sub> and skip processing that slice. Similarly, if <italic>diff</italic><sub><italic>i</italic></sub> &#x02264; 1, but for &#x02203;<italic>diff</italic><sub><italic>j</italic></sub> &#x02265; 1, we can skip the slice. For example, suppose we have a setting of three classes <italic>A</italic>, <italic>B</italic>, <italic>C</italic> where <italic>X</italic>={2, 3, 5}. Suppose a slice contains {2, 1, 4} members of respective classes. In this case, arrival of a rectangle of class <italic>B</italic> or <italic>C</italic> has no effect on that slice. We incorporate these ideas in our Algorithm 3 (although, for brevity, we skip details of implementing and maintaining <italic>diff</italic> in algorithms).</p>
</sec>
</sec>
<sec>
<title>5.4. Algorithmic Details</title>
<p>We now proceed to augment the ideas from the previous section in our base solution. We provide the details of two algorithms <italic>SolveCMaxRS</italic><sup>&#x02212;</sup> and <italic>SolveCMaxRS</italic><sup>&#x0002B;</sup>, implementing the ideas of pruning in <italic>e</italic><sup>&#x02212;</sup> and <italic>e</italic><sup>&#x0002B;</sup> events, respectively.</p>
<table-wrap position="float">
<label>Algorithm 2</label>
<caption><p>SolveCMaxRS<inline-formula><mml:math id="M100"><mml:msup><mml:mrow></mml:mrow><mml:mrow><mml:mo>-</mml:mo></mml:mrow></mml:msup><mml:mtext>&#x000A0;</mml:mtext><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msup><mml:mrow><mml:mi>e</mml:mi></mml:mrow><mml:mrow><mml:mo>-</mml:mo></mml:mrow></mml:msup><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msub><mml:mrow><mml:mi>o</mml:mi></mml:mrow><mml:mrow><mml:mi>e</mml:mi></mml:mrow></mml:msub></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>,</mml:mo><mml:mi>a</mml:mi><mml:mo>,</mml:mo><mml:mi>b</mml:mi><mml:mo>,</mml:mo><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula></p></caption>
<graphic xlink:href="fdata-03-00020-i0004.tif"/>
</table-wrap>
<sec>
<title>5.4.1. <italic>SolveCMaxRS</italic><sup>&#x02212;</sup></title>
<p>In Algorithm 2, we present the detailed method for maintaining C-MaxRS result during an <italic>e</italic><sup>&#x02212;</sup> event using the ideas introduced in section 5.3.1. Firstly, <italic>r</italic><sub><italic>e</italic></sub> is retrieved (from <italic>o</italic><sub><italic>e</italic></sub>) and then deleted from then <italic>QTree</italic> is updated accordingly (cf. lines 1&#x02013;2). Subsequently, in lines 3&#x02013;4, all the slices intersecting with <italic>r</italic><sub><italic>e</italic></sub> is retrieved and the set of slices marked lazy (<italic>S</italic><sub><italic>lazy</italic></sub>) is initialized. Lines 5-8 iterate through all the affected slices one by one and check for each of them to see if the local maximal point <inline-formula><mml:math id="M109"><mml:msub><mml:mrow><mml:mi>s</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>.</mml:mo><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:math></inline-formula> is affected by <italic>r</italic><sub><italic>e</italic></sub>&#x02014;if so, it marks them as lazy for future update and also adds them to <italic>S</italic><sub><italic>lazy</italic></sub>. If the slice containing global maximal point i(i.e., <italic>s</italic><sub><italic>max</italic></sub>) is not affected, then the processing of slices in <italic>S</italic><sub><italic>lazy</italic></sub>i skipped (pruning) in lines 9&#x02013;12. Otherwise, if pruning is not possible, necessary computations are carried out in lines 11&#x02013;12.</p>
<sec>
<title>Time-Complexity</title>
<p>Deleting from a quadtree takes <inline-formula><mml:math id="M110"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mo class="qopname">log</mml:mo><mml:mi>n</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> time (line 2). Listing all the intersecting and lazy slices in worst cases will generate <inline-formula><mml:math id="M111"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>s</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> computations (lines 3&#x02013;4). Iterating over all the overlapped slices and computing <italic>g</italic>() takes up <inline-formula><mml:math id="M112"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>s</mml:mi><mml:mi>n</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> times in worst case (lines 5&#x02013;8). If pruning is not possible, the complexities of <italic>PrepareSlices</italic>() and <italic>SliceSearchMR</italic>() adds up too (lines 10-12). The overall worst-case time complexity of Algorithm 2 is <inline-formula><mml:math id="M113"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>s</mml:mi><mml:mi>n</mml:mi><mml:mo>&#x0002B;</mml:mo><mml:mi>s</mml:mi><mml:mo>&#x0002B;</mml:mo><mml:mo class="qopname">log</mml:mo><mml:mi>n</mml:mi><mml:mo>&#x0002B;</mml:mo><mml:mi>s</mml:mi><mml:mi>n</mml:mi><mml:mo>&#x0002B;</mml:mo><mml:mi>s</mml:mi><mml:mi>n</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula>&#x02014;or, in short, <inline-formula><mml:math id="M114"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>s</mml:mi><mml:mi>n</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula>.</p>
</sec>
</sec>
<sec>
<title>5.4.2. <italic>SolveCMaxRS</italic><sup>&#x0002B;</sup></title>
<p>In Algorithm 3, we initially retrieve the dual rectangle <italic>r</italic><sub><italic>e</italic></sub> associated with the event and update <italic>QTree</italic> by inserting <italic>r</italic><sub><italic>e</italic></sub> as a new node in lines 1&#x02013;2. Then, the set of slices affected by <italic>r</italic><sub><italic>e</italic></sub> is computed and <italic>S</italic><sub><italic>lazy</italic></sub> is initialized in lines 3&#x02013;4. We introduce a Boolean variable <italic>isPrunable</italic> in line 5 to track whether Lemma 8 can be applied or not. Lines 6-10 iterate through all the affected slices one by one, an checks: if <italic>s</italic><sub><italic>i</italic></sub>.<italic>R</italic> now conforms to <italic>X</italic> and makes change accordingly (modifies <italic>isPrunable</italic>), and sets up <italic>s</italic><sub><italic>i</italic></sub>.<italic>lazy</italic> and list <italic>S</italic><sub><italic>lazy</italic></sub> properly. Lines 11&#x02013;12 prunes the event if conditions of Lemma 8 is satisfied, i.e., if <italic>isPrunable</italic> = <italic>true</italic> then the global maximal <inline-formula><mml:math id="M115"><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:math></inline-formula> needs no update. Otherwise, it processes C-MaxRS on the snapshot (lines 13&#x02013;14).</p>
<sec>
<title>Time-Complexity</title>
<p>The analysis of lines 1&#x02013;4 here is similar to Algorithm 2. Iterating over all the intersecting slices and checking the constraints takes up <inline-formula><mml:math id="M116"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>s</mml:mi><mml:mo>&#x000D7;</mml:mo><mml:mo>|</mml:mo><mml:mi>X</mml:mi><mml:mo>|</mml:mo></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> times in worst case. So, if pruning is possible, the time-complexity of Algorithm 3 is <inline-formula><mml:math id="M117"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>s</mml:mi><mml:mo>&#x000D7;</mml:mo><mml:mo>|</mml:mo><mml:mi>X</mml:mi><mml:mo>|</mml:mo><mml:mo>&#x0002B;</mml:mo><mml:mi>s</mml:mi><mml:mo>&#x0002B;</mml:mo><mml:mo class="qopname">log</mml:mo><mml:mi>n</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> time (faster than pre-pruning stage of Algorithm 2). But, in worst case, if pruning is not possible, then the complexity will be <inline-formula><mml:math id="M118"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>s</mml:mi><mml:mi>n</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> (similar to Algorithm 2).</p>
<table-wrap position="float">
<label>Algorithm 3</label>
<caption><p>SolveCMaxRSSolveCMaxRS<sup>&#x0002B;</sup> <inline-formula><mml:math id="M119"><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msup><mml:mrow><mml:mi>e</mml:mi></mml:mrow><mml:mrow><mml:mo>&#x0002B;</mml:mo></mml:mrow></mml:msup><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msub><mml:mrow><mml:mi>o</mml:mi></mml:mrow><mml:mrow><mml:mi>e</mml:mi></mml:mrow></mml:msub></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>,</mml:mo><mml:mi>a</mml:mi><mml:mo>,</mml:mo><mml:mi>b</mml:mi><mml:mo>,</mml:mo><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula></p></caption>
<graphic xlink:href="fdata-03-00020-i0005.tif"/>
</table-wrap>
</sec>
</sec>
</sec>
</sec>
<sec id="s6">
<title>6. Weighted C-MaxRS</title>
<p>In the discussions so far, we only considered the counting variant of the C-MaxRS problem, i.e., the weights of each participating object are all equal to 1. While we have noted the portability of the results, in this section, we explicitly show how the algorithms and pruning schemes proposed thus far should be modified to cater to the case when the objects can have different weights. Firstly, we appropriately revise the definitions of <italic>f</italic>, <italic>g</italic>, and C-MaxRS-DU to allow different weights, and show that it does not affect the monotonicity and non-submodularity of <italic>f</italic> and <italic>g</italic>. Subsequently, we outline the modifications for the pruning schemes for the weighted version. While there are no major changes incurred in the fundamental algorithmic aspects, we note that weights may have impact on the pruning effects, as illustrated in section 8.</p>
<sec>
<title>6.1. Redefining <italic>f</italic>, <italic>g</italic>, and C-MaxRS-DU</title>
<p><bold><italic>f</italic><sup><italic>w</italic></sup></bold>: Let us define a set of <italic>POIClass</italic> <italic>K</italic> = {<italic>k</italic><sub>1</sub>, <italic>k</italic><sub>2</sub>, &#x02026;, <italic>k</italic><sub><italic>m</italic></sub>}, where each <italic>k</italic><sub><italic>i</italic></sub> &#x02208; <italic>K</italic> refers to a class of objects. Suppose, <italic>O</italic> = {<italic>o</italic><sub>1</sub>, <italic>o</italic><sub>2</sub>, &#x02026;, <italic>o</italic><sub><italic>n</italic></sub>} is the set of objects (POIs), and the set <italic>W</italic> = {<italic>w</italic><sub>1</sub>, <italic>w</italic><sub>2</sub>, &#x02026;, <italic>w</italic><sub><italic>n</italic></sub>}, where <italic>w</italic><sub><italic>i</italic></sub> &#x0003E; 0, &#x02200;<italic>w</italic><sub><italic>i</italic></sub> &#x02208; <italic>W</italic>, contains the weight values of all POIs, i.e., the weight of an object <italic>o</italic><sub><italic>i</italic></sub> is <italic>w</italic><sub><italic>i</italic></sub>. In this setting, each object <italic>o</italic><sub><italic>i</italic></sub> &#x02208; <italic>O</italic> is represented as a <italic>(location, class</italic>, <italic>w</italic><sub><italic>i</italic></sub><italic>)</italic> tuple at any time instant <italic>t</italic>. We denote a set <italic>X</italic>= {<italic>x</italic><sub>1</sub>, <italic>x</italic><sub>2</sub>, &#x02026;, <italic>x</italic><sub><italic>m</italic></sub>} as <italic>MinConditionSet</italic>, where |<italic>X</italic>| =|<italic>K</italic>| and each <italic>x</italic><sub><italic>i</italic></sub> &#x02208; &#x0211D;&#x0002B; denotes the desired lower bound of the weighted-sum of the objects of class <italic>k</italic><sub><italic>i</italic></sub> in the interior of the query rectangle <italic>r</italic>, i.e., <inline-formula><mml:math id="M126"><mml:munderover accentunder="false" accent="false"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:msub><mml:mrow><mml:mi>o</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>&#x02208;</mml:mo><mml:mi>r</mml:mi><mml:mo>&#x02227;</mml:mo><mml:msub><mml:mrow><mml:mi>o</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>.</mml:mo><mml:mi>c</mml:mi><mml:mi>l</mml:mi><mml:mi>a</mml:mi><mml:mi>s</mml:mi><mml:mi>s</mml:mi><mml:mo>=</mml:mo><mml:msub><mml:mrow><mml:mi>k</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:mrow><mml:mrow><mml:mo>&#x02200;</mml:mo><mml:msub><mml:mrow><mml:mi>o</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:mrow></mml:munderover><mml:msub><mml:mrow><mml:mi>w</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>. Thus, the optimal region must have objects of class <italic>k</italic><sub><italic>i</italic></sub> whose weights add up to at least <italic>x</italic><sub><italic>i</italic></sub>. Let us define <inline-formula><mml:math id="M127"><mml:msubsup><mml:mrow><mml:mi>l</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>w</mml:mi></mml:mrow></mml:msubsup></mml:math></inline-formula>, a non-negative real number, for a given set of objects <italic>O</italic> as follows:</p>
<disp-formula id="E8"><mml:math id="M128"><mml:mtable columnalign="left"><mml:mtr><mml:mtd><mml:msubsup><mml:mrow><mml:mi>l</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>w</mml:mi></mml:mrow></mml:msubsup><mml:mo>=</mml:mo><mml:mstyle displaystyle="true"><mml:munderover accentunder="false" accent="false"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:msub><mml:mrow><mml:mi>o</mml:mi></mml:mrow><mml:mrow><mml:mi>j</mml:mi></mml:mrow></mml:msub><mml:mo>&#x02208;</mml:mo><mml:mi>O</mml:mi><mml:mo>&#x02227;</mml:mo><mml:msub><mml:mrow><mml:mi>o</mml:mi></mml:mrow><mml:mrow><mml:mi>j</mml:mi></mml:mrow></mml:msub><mml:mo>.</mml:mo><mml:mi>c</mml:mi><mml:mi>l</mml:mi><mml:mi>a</mml:mi><mml:mi>s</mml:mi><mml:mi>s</mml:mi><mml:mo>=</mml:mo><mml:msub><mml:mrow><mml:mi>k</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:mrow><mml:mrow><mml:mo>&#x02200;</mml:mo><mml:msub><mml:mrow><mml:mi>o</mml:mi></mml:mrow><mml:mrow><mml:mi>j</mml:mi></mml:mrow></mml:msub></mml:mrow></mml:munderover></mml:mstyle><mml:msub><mml:mrow><mml:mi>w</mml:mi></mml:mrow><mml:mrow><mml:mi>j</mml:mi></mml:mrow></mml:msub><mml:mo>.</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula>
<p>Subsequently, we can define a utility function <inline-formula><mml:math id="M129"><mml:msup><mml:mrow><mml:mi>f</mml:mi></mml:mrow><mml:mrow><mml:mi>w</mml:mi></mml:mrow></mml:msup><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>O</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>:</mml:mo><mml:mrow><mml:mi mathvariant="-tex-caligraphic">P</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>O</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x02192;</mml:mo><mml:msub><mml:mrow><mml:mi>&#x02115;</mml:mi></mml:mrow><mml:mrow><mml:mn>0</mml:mn></mml:mrow></mml:msub></mml:math></inline-formula>, mapping a subset of spatial objects to a non-negative real number as below,</p>
<disp-formula id="E9"><mml:math id="M130"><mml:mtable columnalign="left"><mml:mtr><mml:mtd columnalign="left"><mml:msup><mml:mrow><mml:mi>f</mml:mi></mml:mrow><mml:mrow><mml:mi>w</mml:mi></mml:mrow></mml:msup><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>O</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:mrow><mml:mo stretchy="true">{</mml:mo><mml:mtable style="text-align:axis;" equalrows="false" columnlines="none" equalcolumns="false" class="array"><mml:mtr><mml:mtd columnalign="left"><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mstyle displaystyle="true"><mml:msubsup><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mrow><mml:mo>|</mml:mo><mml:mi>K</mml:mi><mml:mo>|</mml:mo></mml:mrow></mml:msubsup></mml:mstyle><mml:msubsup><mml:mrow><mml:mi>l</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>w</mml:mi></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>,</mml:mo></mml:mtd><mml:mtd columnalign="left"><mml:mtext class="textrm" mathvariant="normal">if&#x000A0;</mml:mtext><mml:mo>&#x02200;</mml:mo><mml:mi>i</mml:mi><mml:mo>&#x02208;</mml:mo><mml:mrow><mml:mo>{</mml:mo><mml:mrow><mml:mn>1</mml:mn><mml:mo>,</mml:mo><mml:mn>2</mml:mn><mml:mo>,</mml:mo><mml:mn>3</mml:mn><mml:mo>,</mml:mo><mml:mo>.</mml:mo><mml:mo>.</mml:mo><mml:mo>.</mml:mo><mml:mo>,</mml:mo><mml:mo>|</mml:mo><mml:mi>K</mml:mi><mml:mo>|</mml:mo></mml:mrow><mml:mo>}</mml:mo></mml:mrow><mml:mo>,</mml:mo><mml:msubsup><mml:mrow><mml:mi>l</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>w</mml:mi></mml:mrow></mml:msubsup><mml:mo>&#x0003E;</mml:mo><mml:mo>=</mml:mo><mml:msub><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:mtd></mml:mtr><mml:mtr><mml:mtd columnalign="left"><mml:mn>0</mml:mn><mml:mo>,</mml:mo></mml:mtd><mml:mtd columnalign="left"><mml:mtext class="textrm" mathvariant="normal">if&#x000A0;</mml:mtext><mml:mo>&#x02203;</mml:mo><mml:mi>i</mml:mi><mml:mo>&#x02208;</mml:mo><mml:mrow><mml:mo>{</mml:mo><mml:mrow><mml:mn>1</mml:mn><mml:mo>,</mml:mo><mml:mn>2</mml:mn><mml:mo>,</mml:mo><mml:mn>3</mml:mn><mml:mo>,</mml:mo><mml:mo>.</mml:mo><mml:mo>.</mml:mo><mml:mo>.</mml:mo><mml:mo>,</mml:mo><mml:mo>|</mml:mo><mml:mi>K</mml:mi><mml:mo>|</mml:mo></mml:mrow><mml:mo>}</mml:mo></mml:mrow><mml:mo>,</mml:mo><mml:msubsup><mml:mrow><mml:mi>l</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>w</mml:mi></mml:mrow></mml:msubsup><mml:mo>&#x0003C;</mml:mo><mml:msub><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>.</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:mrow></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula>
<p><bold>C-MaxRS-DU</bold>: Let us denote the rectangle <italic>r</italic> centered at point <italic>p</italic> as <italic>r</italic><sub><italic>p</italic></sub>, and <italic>O</italic><sub><italic>r</italic><sub><italic>p</italic></sub></sub> as the set of spatial objects in the interior of <italic>r</italic><sub><italic>p</italic></sub>. We can now define C-MaxRS-DU as follows (including the weights):<bold>Conditional-MaxRS for Data Updates (C-MaxRS-DU):</bold> Given a rectangular spatial field &#x1D53D;, a set of objects of interests <italic>O</italic> (bounded by &#x1D53D;) and their corresponding set of weight values <italic>W</italic>, a query rectangle <italic>r</italic> (of size <italic>a</italic> &#x000D7; <italic>b</italic>), a set of <italic>POIClass</italic> <italic>K</italic> = {<italic>k</italic><sub>1</sub>, <italic>k</italic><sub>2</sub>, &#x02026;, <italic>k</italic><sub><italic>m</italic></sub>}, a <italic>MinConditionSet</italic> <italic>X</italic> = {<italic>x</italic><sub>1</sub>, <italic>x</italic><sub>2</sub>, &#x02026;, <italic>x</italic><sub><italic>m</italic></sub>}, and a sequence of events <italic>E</italic>={<italic>e</italic><sub>1</sub>, <italic>e</italic><sub>2</sub>, <italic>e</italic><sub>3</sub>, &#x02026;} (where each <italic>e</italic><sub><italic>i</italic></sub> denotes the appearance or disappearance of a point of interest), the C-MaxRS-DU query maintains the optimal location (point) <italic>p</italic><sup>&#x0002A;</sup> for <italic>r</italic> such that:</p>
<disp-formula id="E10"><mml:math id="M131"><mml:mrow><mml:msup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msup><mml:mo>=</mml:mo><mml:mi>a</mml:mi><mml:mi>r</mml:mi><mml:mi>g</mml:mi><mml:mi>m</mml:mi><mml:mi>a</mml:mi><mml:msub><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>p</mml:mi><mml:mo>&#x02208;</mml:mo><mml:mo>&#x1D53D;</mml:mo></mml:mrow></mml:msub><mml:msup><mml:mrow><mml:mi>f</mml:mi></mml:mrow><mml:mrow><mml:mi>w</mml:mi></mml:mrow></mml:msup><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msub><mml:mrow><mml:mi>O</mml:mi></mml:mrow><mml:mrow><mml:msub><mml:mrow><mml:mi>r</mml:mi></mml:mrow><mml:mrow><mml:mi>p</mml:mi></mml:mrow></mml:msub></mml:mrow></mml:msub></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mrow></mml:math></disp-formula>
<p>where <italic>O</italic><sub><italic>r</italic><sub><italic>p</italic></sub></sub> &#x02286; <italic>O</italic><sub><italic>e</italic></sub> for every event <italic>e</italic> in <italic>E</italic> of the data stream.</p>
<p><bold><italic>g</italic><sup><italic>w</italic></sup></bold>: Similar to the function <italic>g</italic>, we can introduce <italic>g</italic><sup><italic>w</italic></sup> as a bijection of <italic>f</italic><sup><italic>w</italic></sup>, i.e., for a set of rectangles <italic>R</italic><sub><italic>k</italic></sub> &#x0003D; {<italic>r</italic><sub>1</sub>, <italic>r</italic><sub>2</sub>, &#x02026;, <italic>r</italic><sub><italic>k</italic></sub>}, let <inline-formula><mml:math id="M132"><mml:msup><mml:mrow><mml:mi>g</mml:mi></mml:mrow><mml:mrow><mml:mi>w</mml:mi></mml:mrow></mml:msup><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:mi>k</mml:mi></mml:mrow></mml:msub></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:msup><mml:mrow><mml:mi>f</mml:mi></mml:mrow><mml:mrow><mml:mi>w</mml:mi></mml:mrow></mml:msup><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mrow><mml:mo>{</mml:mo><mml:mrow><mml:msub><mml:mrow><mml:mi>o</mml:mi></mml:mrow><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mrow><mml:mi>o</mml:mi></mml:mrow><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:mo>&#x02026;</mml:mo><mml:mo>,</mml:mo><mml:msub><mml:mrow><mml:mi>o</mml:mi></mml:mrow><mml:mrow><mml:mi>k</mml:mi></mml:mrow></mml:msub></mml:mrow><mml:mo>}</mml:mo></mml:mrow></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula>. <inline-formula><mml:math id="M133"><mml:msup><mml:mrow><mml:mi>g</mml:mi></mml:mrow><mml:mrow><mml:mi>w</mml:mi></mml:mrow></mml:msup><mml:mo>:</mml:mo><mml:mrow><mml:mi mathvariant="-tex-caligraphic">P</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x02192;</mml:mo><mml:msub><mml:mrow><mml:mi>&#x0211D;</mml:mi></mml:mrow><mml:mrow><mml:mn>0</mml:mn></mml:mrow></mml:msub></mml:math></inline-formula> maps a set of dual rectangles to a non-negative real number (weighted-sum).</p>
</sec>
<sec>
<title>6.2. Monotonicity and Non-submodularity of <italic>f</italic><sup><italic>w</italic></sup> and <italic>g</italic><sup><italic>w</italic></sup></title> 
<p>As we define <italic>w</italic><sub><italic>i</italic></sub> &#x02208; <italic>W</italic> as a positive real number, the weighted-sum of a set of objects&#x02014;<inline-formula><mml:math id="M134"><mml:munder class="msub"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:msub><mml:mrow><mml:mi>o</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:mrow></mml:munder><mml:msub><mml:mrow><mml:mi>w</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>, is also a positive real number. This is similar to the counting variant of the problem. Thus, using the similar logic as Lemma 1 and Lemma 2, we derive the following:</p>
<p>Lemma 9. <italic>Both <italic>f</italic><sup><italic>w</italic></sup> and <italic>g</italic><sup><italic>w</italic></sup> are monotone functions</italic>.</p>
<p>Lemma 10. <italic>None of <italic>f</italic><sup><italic>w</italic></sup> and <italic>g</italic><sup><italic>w</italic></sup> is a submodular function</italic>.</p>
<p>The proofs follow the similar intuition as the corresponding proofs of Lemma 1 and Lemma 2 and are omitted &#x02013;however, we proceed with discussing their implication in a more detailed manner next.</p>
</sec>
<sec>
<title>6.3. Discussion</title>
<p>Lemma 9 and Lemma 10 show that the properties of the utlity functions remain same, for both counting and weighted version. Subsequently, we can derive the following:</p>
<p>Lemma 11. <italic>Removal of a rectangle</italic> <italic>r</italic><sub><italic>e</italic></sub> <italic>(object</italic> <italic>o</italic><sub><italic>e</italic></sub>) <italic>from the point space</italic> &#x1D53D; <italic>never increases the value of</italic> <italic>g</italic><sup><italic>w</italic></sup>(<italic>A</italic>(<italic>p</italic>)) <italic>(correspondingly</italic> <italic>f</italic><sup><italic>w</italic></sup>(<italic>A</italic>(<italic>p</italic>))), &#x02200;<italic>p</italic> &#x02208; <italic>P</italic>.</p>
<p>Lemma 11 can be proved in similar way as the proof of Lemma 3, as <italic>f</italic><sup><italic>w</italic></sup> and <italic>g</italic><sup><italic>w</italic></sup> are also monotonous. Thus, Lemma 11 validates the other necessary lemmas (i.e., Lemma 4, 5, and 6) related to the <italic>e</italic><sup>&#x02212;</sup> pruning scheme. This shows that we can solve the problem of an <italic>e</italic><sup>&#x02212;</sup> event, for an object <italic>o</italic><sub><italic>e</italic></sub> (rectangle <italic>r</italic><sub><italic>e</italic></sub>) and its weight <italic>w</italic><sub><italic>e</italic></sub>, by using the same algorithm <italic>SolveCMaxRS</italic><sup>&#x02212;</sup>. For the <italic>e</italic><sup>&#x0002B;</sup> event, we present the following lemmas: (skipping proof for brevity)</p>
<p>Lemma 12. <italic>Addition of a rectangle</italic> <italic>r</italic><sub><italic>e</italic></sub> <italic>(object</italic> <italic>o</italic><sub><italic>e</italic></sub>) <italic>in the given space</italic> &#x1D53D; <italic>never decreases the value of</italic> <italic>g</italic><sup><italic>w</italic></sup>(<italic>A</italic>(<italic>p</italic>)) (<italic>correspondingly</italic> <italic>f</italic><sup><italic>w</italic></sup>(<italic>A</italic>(<italic>p</italic>))), &#x02200;<italic>p</italic> &#x02208; <italic>P</italic>.</p>
<p>Lemma 13. <italic>Suppose, we have a set of classes</italic> <italic>K</italic> = {<italic>k</italic><sub>1</sub>, <italic>k</italic><sub>2</sub>, &#x02026;, <italic>k</italic><sub><italic>m</italic></sub>}, <italic>and are given corresponding</italic> <italic>MinConditionSet</italic> <italic>X</italic> = {<italic>x</italic><sub>1</sub>, <italic>x</italic><sub>2</sub>, &#x02026;, <italic>x</italic><sub><italic>m</italic></sub>}. <italic>Let</italic> <italic>R</italic> <italic>be the set of rectangles overlapping with a slice</italic> <italic>s</italic><sub><italic>i</italic></sub> &#x02208; <italic>S</italic><sub><italic>slice</italic></sub>, <italic>and let</italic> <inline-formula><mml:math id="M135"><mml:msubsup><mml:mrow><mml:mi>l</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>w</mml:mi></mml:mrow></mml:msubsup></mml:math></inline-formula> <italic>be the weighted-sum of rectangles of class</italic> <italic>k</italic><sub><italic>i</italic></sub> <italic>in</italic> <italic>R</italic>. <italic>Then, addition of a rectangle</italic> <italic>r</italic><sub><italic>e</italic></sub> <italic>of class</italic> <italic>k</italic><sub><italic>i</italic></sub> <italic>has no effect on the local maximal solution of</italic> <italic>s</italic><sub><italic>i</italic></sub> <italic>if:</italic></p>
<list list-type="simple">
<list-item><p><italic>(1)</italic> <inline-formula><mml:math id="M136"><mml:msub><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>-</mml:mo><mml:msubsup><mml:mrow><mml:mi>l</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>w</mml:mi></mml:mrow></mml:msubsup><mml:mo>&#x0003E;</mml:mo><mml:msub><mml:mrow><mml:mi>w</mml:mi></mml:mrow><mml:mrow><mml:mi>e</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>, or</p></list-item>
<list-item><p><italic>(2)</italic> (&#x02203;<italic>l</italic><sub><italic>j</italic></sub> &#x02260; <italic>l</italic><sub><italic>i</italic></sub>) <inline-formula><mml:math id="M137"><mml:msub><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>j</mml:mi></mml:mrow></mml:msub><mml:mo>-</mml:mo><mml:msubsup><mml:mrow><mml:mi>l</mml:mi></mml:mrow><mml:mrow><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>w</mml:mi></mml:mrow></mml:msubsup><mml:mo>&#x0003E;</mml:mo><mml:mn>0</mml:mn></mml:math></inline-formula></p></list-item>
</list>
<p>Lemmas 12 and 13 demonstrates that an <italic>e</italic><sup>&#x0002B;</sup> event, for an object <italic>o</italic><sub><italic>e</italic></sub> (rectangle <italic>r</italic><sub><italic>e</italic></sub>) and its weight <italic>w</italic><sub><italic>e</italic></sub>, can be processed similarly via <italic>SolveCMaxRS</italic><sup>&#x0002B;</sup> algorithm.</p>
</sec>
</sec>
<sec id="s7">
<title>7. C-MaxRS in Bursty Updates</title>
<p>In many spatial applications, the data streaming rate often varies wildly depending on various external factors&#x02014;e.g., the time of the day, the need of the users, etc. A peculiar phenomenon in such cases is the, so called, bursty streaming updates&#x02014;which is, the streaming rate becomes unusually high and a large number of objects appearing or disappearing in a very short interval. In such scenarios, instead of processing every single update, we assume that the update streams are gathered for a period of time. The C-MaxRS-DU algorithm is based on sequential processing of events, and thus, its efficiency is particularly sensitive to the bursty input scenario. In this section, we first briefly discuss the challenges of processing bulk of events via Algorithm 2 and 3, and argue that a different technique is necessary. Subsequently, we propose additional data-structures and a new algorithm, C-MaxRS-Bursty, to maintain C-MaxRS during bursty streaming updates scenarios. Finally, we briefly discuss how our proposed scheme can be utilized in a distributed manner, for the purpose of further improvements in scalability.</p>
<sec>
<title>7.1. Challenges</title>
<p>As per the algorithms presented in section 5, Algorithm 2 (<italic>SolveCMaxRS</italic><sup>&#x02212;</sup>) and Algorithm 3 (<italic>SolveCMaxRS</italic><sup>&#x0002B;</sup>) are used to deal with any new <italic>e</italic><sup>&#x02212;</sup> and <italic>e</italic><sup>&#x0002B;</sup> event, respectively. The worst case time complexity of both the algorithms is <inline-formula><mml:math id="M138"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>s</mml:mi><mml:mi>n</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula>. Let us denote &#x003B3; as the average streaming (a.k.a. bulk-updates) rate during a bursty stream scenario, i.e., &#x003B3; events (both <italic>e</italic><sup>&#x0002B;</sup> and <italic>e</italic><sup>&#x02212;</sup>) occur simultaneously per time instance. In this setting, the worst-case complexity of processing these events using C-MaxRS-DU is <inline-formula><mml:math id="M139"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>&#x003B3;</mml:mi><mml:mi>s</mml:mi><mml:mi>n</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula>. We note that, due to the effectiveness of the pruning schemes, the average processing time is considerably faster than the worst case complexity presented here (details in section 8). However, the overhead of performing Algorithm 2 and Algorithm 3 &#x003B3; times is still significant, specially when fast and accurate responses are required. For example, line 3 of Algorithm 2 takes <inline-formula><mml:math id="M140"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>s</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> time to find the slices <italic>S</italic><sub><italic>e</italic></sub> that intersect with the new event rectangle <italic>r</italic><sub><italic>e</italic></sub>. Instead of computing this &#x003B3; times (i.e., <inline-formula><mml:math id="M141"><mml:mi>&#x003B3;</mml:mi><mml:mo>&#x000D7;</mml:mo><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>s</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula>), it would be better if we scan the list of slices only once, and retrieve all the slices that are affected by the new &#x003B3; events in one pass. Moreover, if the slice containing global <inline-formula><mml:math id="M142"><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:math></inline-formula>, i.e., <italic>s</italic><sub><italic>max</italic></sub>, is affected by multiple events, then <italic>PrepareSlices</italic>() and <italic>SliceSearchMR</italic>() would be redundantly processed multiple times. Hence, the intuition is that we can get rid of these overheads by dealing with the bursty events aggregately.</p>
<p>To this end, we propose an additional data structure (e.g., a spatial index) and devise an efficient algorithmic solution. In section 8, we demonstrate via experimental observations that, for a sufficiently large value of &#x003B3;, C-MaxRS-Bursty outperforms the event-based processing scheme by an order of magnitude. The basic idea is as follows: we first create a modified slice-based index, <italic>S</italic><sub><italic>index</italic></sub> for newly occurring &#x003B3; events (appearing or disappearing objects). Then, we directly add/remove these new events over the existing slice structure <italic>S</italic><sub><italic>slice</italic></sub> in one iteration, and check the pruning conditions for each slice only once. We describe these ideas in the following section.</p>
</sec>
<sec>
<title>7.2. Additional Data Structures</title>
<p>The first step, when handling bursty data updates, is to index the new events based on the locations of their related objects. This allows us later to efficiently retrieve all the new events related to each slice <italic>s</italic><sub><italic>i</italic></sub> &#x02208; <italic>S</italic><sub><italic>slice</italic></sub>. Any well-known indexing scheme may be used, e.g., R-tree, Quad-tree, Grid indexing (cf. Ooi et al., <xref ref-type="bibr" rid="B32">1993</xref>; &#x00160;idlauskas et al., <xref ref-type="bibr" rid="B38">2009</xref>), etc. To take advantage of the already introduced slice data structure, we propose to use slice-based indexing for the new data. Slice indexing is, basically, a special version of the <italic>p</italic> &#x000D7; <italic>q</italic> grid-indexing&#x02014;where <italic>q</italic> = 1. Suppose, <italic>S</italic><sub><italic>index</italic></sub> represents the slice index of new appearing/disappearing objects. Then, we can create <italic>S</italic><sub><italic>index</italic></sub> as a duplicate of <italic>S</italic><sub><italic>slice</italic></sub>, i.e., width of each slice in <italic>S</italic><sub><italic>index</italic></sub> is also &#x003B8; &#x000D7; <italic>b</italic> (where, &#x003B8; &#x0003E; 1) and |<italic>S</italic><sub><italic>index</italic></sub>| = |<italic>S</italic><sub><italic>slice</italic></sub>| = <italic>s</italic>. An example of the proposed slice indexing is given in <xref ref-type="fig" rid="F5">Figure 5</xref>. Suppose, there are 10 new events occurring at the same time&#x02014;7 <italic>e</italic><sup>&#x0002B;</sup> and 3 <italic>e</italic><sup>&#x02212;</sup>, and there are three slices which enclose these event locations. Note that, by event location, we mean the location of the appearing/disappearing object related to the event. In <xref ref-type="fig" rid="F5">Figure 5i</xref>, <italic>Slice</italic><sub>1</sub>, <italic>Slice</italic><sub>2</sub>, <italic>Slice</italic><sub>3</sub> has, respectively, 3, 4, 3 new events falling within their boundary.</p>
<fig id="F5" position="float">
<label>Figure 5</label>
<caption><p><bold>(i)</bold> Slice indexing over new data and <bold>(ii)</bold> Regions within a slice.</p></caption>
<graphic xlink:href="fdata-03-00020-g0005.tif"/>
</fig>
<p>As described in section 5, each of the slices in <italic>S</italic><sub><italic>slice</italic></sub> track the corresponding rectangles intersecting with them, in addition to the list of maximal slabs, local optimum points and the other attributes. <italic>S</italic><sub><italic>index</italic></sub>, in turn, indexes new events over the slices. An event <italic>e</italic>, corresponding an object <italic>o</italic><sub><italic>e</italic></sub>, is exclusively enclosed by exactly one slice in <italic>S</italic><sub><italic>index</italic></sub>, although the rectangle <italic>r</italic><sub><italic>e</italic></sub> can overlap with multiple slices. This is illustrated in <xref ref-type="fig" rid="F5">Figure 5ii</xref>. Based on this, we can divide the interior of each slice into three regions:</p>
<p>&#x02022; <bold>Left-overlapping Region (<italic>lr</italic>):</bold> Rectangles of events in this region overlaps with the left neighboring slice. Width of <italic>lr</italic> is <inline-formula><mml:math id="M143"><mml:mfrac><mml:mrow><mml:mi>b</mml:mi></mml:mrow><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:mfrac></mml:math></inline-formula>. In <xref ref-type="fig" rid="F5">Figure 5ii</xref>, events in <italic>lr</italic> of <italic>Slice</italic><sub>2</sub> impact the processing of <italic>Slice</italic><sub>1</sub> too.</p>
<p>&#x02022; <bold>Non-overlapping Region (<italic>nr</italic>):</bold> Rectangles of events in this region are fully enclosed within the slice itself. <italic>nr</italic> is (&#x003B8; &#x02212; 1) &#x000D7; <italic>b</italic> wide, i.e., always non-empty as &#x003B8; &#x0003E; 1.</p>
<p>&#x02022; <bold>Right-overlapping Region (<italic>rr</italic>):</bold> Rectangles of events in this region overlaps with the right neighboring slice. Width of <italic>rr</italic>, similar to <italic>lr</italic>, is <inline-formula><mml:math id="M144"><mml:mfrac><mml:mrow><mml:mi>b</mml:mi></mml:mrow><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:mfrac></mml:math></inline-formula>. In <xref ref-type="fig" rid="F5">Figure 5ii</xref>, events in <italic>rr</italic> of <italic>Slice</italic><sub>2</sub> is also a part of the processing of <italic>Slice</italic><sub>3</sub>.</p>
<p>Based on the discussion above, each slice <italic>s</italic><sub><italic>i</italic></sub> &#x02208; <italic>S</italic><sub><italic>index</italic></sub> is represented as a 4&#x02212;tuple (<italic>seq</italic>_<italic>num, E</italic><sub><italic>lr</italic></sub>, <italic>E</italic><sub><italic>nr</italic></sub>, <italic>E</italic><sub><italic>rr</italic></sub>). The role of each attribute is as follows:</p>
<list list-type="bullet">
<list-item><p><bold><italic>seq</italic>_<italic>num</italic></bold>: An integer value assigned to the slice. This encodes the boundary of the slice. For a slice <italic>s</italic><sub><italic>i</italic></sub>, the horizontal extent of <italic>s</italic><sub><italic>i</italic></sub> is represented by [(<italic>seq</italic>_<italic>num</italic><sub><italic>i</italic></sub> &#x02212; 1) &#x000D7; &#x003B8;<italic>b, seq</italic>_<italic>num</italic><sub><italic>i</italic></sub> &#x000D7; &#x003B8;<italic>b</italic>).</p></list-item>
<list-item><p><bold><italic>E</italic><sub><italic>lr</italic></sub></bold>: The set of new events in the <italic>lr</italic> region of the slice.</p></list-item>
<list-item><p><bold><italic>E</italic><sub><italic>nr</italic></sub></bold>: The set of new events in the <italic>nr</italic> region of the slice.</p></list-item>
<list-item><p><bold><italic>E</italic><sub><italic>rr</italic></sub></bold>: The set of new events in the <italic>rr</italic> region of the slice.</p></list-item>
</list>
<p>Note that, both <italic>S</italic><sub><italic>index</italic></sub> and <italic>S</italic><sub><italic>slice</italic></sub> can be merged into one giant slice data structure during implementation. We present them as separate structures here, so that the background motivation and complexity analysis can be clearly demonstrated in the text, i.e., the objective of these two structures are different&#x02014;<italic>S</italic><sub><italic>slice</italic></sub> divides the space and overall computation in small slices, while <italic>S</italic><sub><italic>index</italic></sub> is used only to efficiently index a set of new events.</p>
</sec>
<sec>
<title>7.3. Processing Bursty Updates</title>
<p>When a collection of new <italic>e</italic><sup>&#x0002B;</sup> and <italic>e</italic><sup>&#x02212;</sup> events occur at a time instant, the first step is to initialize and built the slice index <italic>S</italic><sub><italic>index</italic></sub>. Function 3 shows the steps used to build the index from scratch over the new data. In line 1, <italic>S</italic><sub><italic>index</italic></sub> and <italic>seq</italic>_<italic>num</italic> of its slices are initialized. The other attributes of each slice <italic>s</italic><sub><italic>i</italic></sub> &#x02208; <italic>S</italic><sub><italic>index</italic></sub> is initialized in lines 2&#x02013;3, i.e., all event lists (based on the region) are set to an empty list. Lines 4&#x02013;11 iterate though each new events from <italic>E</italic><sub><italic>new</italic></sub> and set the index attributes accordingly. In line 5, the function retrieves the slice to which <italic>o</italic><sub><italic>e</italic></sub> belongs, which can be computed in <inline-formula><mml:math id="M145"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mn>1</mml:mn></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> time. Lines 6&#x02013;11 find which region <italic>o</italic><sub><italic>e</italic></sub> is in, and add the corresponding event to the appropriate list. Finally, the newly created index <italic>S</italic><sub><italic>index</italic></sub> is returned in line 12. The operations from lines 1&#x02013;3 takes <inline-formula><mml:math id="M146"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>s</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> time, and lines 4&#x02013;11 takes <inline-formula><mml:math id="M147"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>&#x003B3;</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> time, where &#x003B3; is the bursty updates rate. The processing cost of Function 6 is <inline-formula><mml:math id="M148"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>&#x003B3;</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x0002B;</mml:mo><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>s</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula>. If we assume &#x003B3; &#x0003E; <italic>s</italic>, then the overall time-complexity is <inline-formula><mml:math id="M149"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>&#x003B3;</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula>.</p>
<table-wrap position="float">
<label>Function 3</label>
<caption><p>BuildIndex(<italic>E<sub>new</sub></italic>, <italic>&#x003B8;</italic>, <italic>b</italic>)</p></caption>
<graphic xlink:href="fdata-03-00020-i0006.tif"/>
</table-wrap>
<p>Algorithm 4 shows the steps of our approach for handling a set of new bursty events <italic>E</italic><sub><italic>new</italic></sub>, where |<italic>E</italic><sub><italic>new</italic></sub>| = &#x003B3;. We combine the pruning ideas of Algorithm 2 and 3, and ensure that <italic>PrepareSlices</italic> and <italic>SliceSearchMR</italic> functions are only called once for these &#x003B3; new events. In line 1, we use the <italic>BuildIndex</italic> function to prepare the slice index over the new data in <inline-formula><mml:math id="M160"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>&#x003B3;</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> time. We initialize <italic>S</italic><sub><italic>lazy</italic></sub>, <italic>isPrunable</italic>, and <italic>prev</italic> in lines 2&#x02013;4. The idea is to traverse the slices from <italic>S</italic><sub><italic>slice</italic></sub> in one direction, e.g., from left to right. The main idea is that for each slice <italic>s</italic><sub><italic>i</italic></sub> of <italic>S</italic><sub><italic>slice</italic></sub>, we retrieve the required information of new events from the slice-index <italic>S</italic><sub><italic>index</italic></sub>. The goal is to make sure that we query information of each slice from <italic>S</italic><sub><italic>index</italic></sub> only once throughout the process. In this regard, we maintain 3 variables&#x02014;<italic>prev</italic>, <italic>cur</italic>, and <italic>next</italic>&#x02014;representing the <italic>seq</italic>_<italic>num</italic> &#x02212; 1, <italic>seq</italic>_<italic>num</italic>, and <italic>seq</italic>_<italic>num</italic> &#x0002B; 1 slices from <italic>S</italic><sub><italic>index</italic></sub> (new information) any time. Initially, in lines 4&#x02013;6, <italic>cur</italic> is set to the left-most slice, and <italic>prev</italic> is set to null as there is no slice before that value of <italic>cur</italic>.</p>
<p>Lines 7&#x02013;29 iterate though each of the slices <italic>s</italic><sub><italic>i</italic></sub> from <italic>S</italic><sub><italic>slice</italic></sub> in order (e.g., left to right). At first, information for the (<italic>i</italic> &#x0002B; 1)-th slice index is retrieved into <italic>next</italic>. In line 9, all the related new events of <italic>s</italic><sub><italic>i</italic></sub> is stored in <italic>E</italic><sub><italic>cu</italic><sub><italic>r</italic></sub><sub><italic>s</italic></sub><italic>lice</italic></sub>, which is the union of new objects in <italic>cur</italic> region, and <italic>prev</italic>.<italic>rr</italic> and <italic>next</italic>.<italic>lr</italic> region (cf. <xref ref-type="fig" rid="F5">Figure 5ii</xref>). In line 10, we check if there are any new events that overlap with the current slice <italic>s</italic><sub><italic>i</italic></sub>&#x02014;otherwise we move on to the next slice. In lines 12&#x02013;15, we iterate through the <italic>e</italic><sup>&#x0002B;</sup> events of <italic>s</italic><sub><italic>i</italic></sub>&#x02014;retrieve <italic>r</italic><sub><italic>e</italic></sub>, insert <italic>r</italic><sub><italic>e</italic></sub> in the <italic>QTree</italic> and add <italic>r</italic><sub><italic>e</italic></sub> to <italic>s</italic><sub><italic>i</italic></sub>.<italic>R</italic> for each of them. Similarly, lines 16&#x02013;23 iterate over the <italic>e</italic><sup>&#x02212;</sup> events of <italic>s</italic><sub><italic>i</italic></sub>, although <italic>r</italic><sub><italic>e</italic></sub> is deleted from <italic>QTree</italic> and <italic>s</italic><sub><italic>i</italic></sub>.<italic>R</italic> in this case. Also, lines 20&#x02013;22 ensure that <italic>s</italic><sub><italic>i</italic></sub>.<italic>lazy</italic> is set to <italic>true</italic> and <italic>s</italic><sub><italic>i</italic></sub> is added to <italic>S</italic><sub><italic>lazy</italic></sub> if <italic>r</italic><sub><italic>e</italic></sub> overlaps with the local optimum solution. Lines 28 and 29 updates the <italic>prev</italic> and <italic>cur</italic> variables appropriately, and line 30 retrieves the slice <italic>s</italic><sub><italic>max</italic></sub> containing the global solution. We need to recompute global solution whenever <italic>s</italic><sub><italic>max</italic></sub>.<italic>lazy</italic> = <italic>true</italic> or <italic>isPrunable</italic> = <italic>false</italic> (cf. lines 31 - 33). Finally, the newly computed (or, if pruned, the old) <inline-formula><mml:math id="M161"><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:math></inline-formula> is returned in line 34. In Algorithm 4, each new event is only processed at most 2 times, because &#x003B8; &#x0003E; 1 and a rectangle <italic>r</italic><sub><italic>e</italic></sub> can only overlap with at most two slices. Thus, the overall time-complexity of lines 1&#x02013;30 of Algorithm 4 is <inline-formula><mml:math id="M162"><mml:mrow><mml:mi mathvariant="-tex-caligraphic">O</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>&#x003B3;</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula>. Also, <italic>PrepareSlices</italic> and <italic>SliceSearchMR</italic> is only processed once for all the new events, instead of worst case &#x003B3; times via Algorithms 2 and 3. For large values of <italic>N</italic>, the overall processing time of Algorithm 4 is consumed by the execution time of <italic>PrepareSlices</italic> and <italic>SliceSearchMR</italic>.</p>
<table-wrap position="float">
<label>Algorithm 4</label>
<caption><p>SolveCMaxRSBursty <inline-formula><mml:math id="M150"><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msub><mml:mrow><mml:mi>E</mml:mi></mml:mrow><mml:mrow><mml:mi>n</mml:mi><mml:mi>e</mml:mi><mml:mi>w</mml:mi></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:mi>a</mml:mi><mml:mo>,</mml:mo><mml:mi>b</mml:mi><mml:mo>,</mml:mo><mml:mi>&#x003B8;</mml:mi><mml:mo>,</mml:mo><mml:msubsup><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mi>c</mml:mi></mml:mrow><mml:mrow><mml:mo>*</mml:mo></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula></p></caption>
<graphic xlink:href="fdata-03-00020-i0007.tif"/>
</table-wrap>
</sec>
<sec>
<title>7.4. Discussion</title>
<p>We presented a slice-based simplified indexing scheme in this section to process a set of bursty events. As slice-indexes are a specialized grid-indexing (see Ooi et al., <xref ref-type="bibr" rid="B32">1993</xref>), they can be implemented both as main-memory or external-memory based. We implemented the proposed slice-indexing in main memory for our experiments. The reason is two- fold. (1) Many recent works such as Kipf et al. (<xref ref-type="bibr" rid="B22">2020</xref>) and &#x00160;idlauskas et al. (<xref ref-type="bibr" rid="B38">2009</xref>) have shown that main-memory indexes are usually necessary to provide high update and build performance&#x02014;which is paramount in dealing with bursty updates scenarios; and (2) In our experiments, we vary &#x003B3; from 100 to 100k &#x02014; which can be stored in-memory. Although, we note that, in extreme scenarios (e.g., Facebook users) where the number of total objects as well as bursty objects surpass the main memory storage capacity of servers, external memory implementations and parallel processing of indexes would be necessary. Many works such as Kamel and Faloutsos (<xref ref-type="bibr" rid="B20">1992</xref>) and Kim et al. (<xref ref-type="bibr" rid="B21">2013</xref>) presented parallel processing techniques for R-trees and range queries. Kamel and Faloutsos (<xref ref-type="bibr" rid="B20">1992</xref>) developed a simple hardware architecture consisting of one processor with several disks to parallelize R-tree processing, where R-tree code is identical to the one for a single-disk R-tree with minimal modifications. Zhong et al. (<xref ref-type="bibr" rid="B44">2012</xref>) proposed a novel architecture named VegaGiStore, to enable efficient spatial query processing over big spatial data and concurrent access, via distributed indexing and map-reduce (cf. Dean and Ghemawat, <xref ref-type="bibr" rid="B11">2008</xref>) technique. Recently, SpatialHadoop (Eldawy and Mokbel, <xref ref-type="bibr" rid="B12">2015</xref>) provides a library to perform map-reduce based parallel processing for many spatial operations, including R-tree and grid indexing. We can modify the grid indexing parameters for SpatialHadoop to convert it into a slice-indexing in a straightforward manner. In this way SpatialHadoop can be useful for static scenarios (e.g., Basic C-MaxRS), though the extension to handle dynamic or bursty scenarios is not straight-forward. We note that, Hadoop (Shvachko et al., <xref ref-type="bibr" rid="B37">2010</xref>) and map reduce procedure has a significant overhead, i.e., these will be only be useful if there are a huge number of bursty events, as well as a lot of resources (Hadoop nodes) available.</p>
</sec>
</sec>
<sec id="s8">
<title>8. Experimental Study</title>
<p>In this section, we evaluate the performance of our algorithms. Since there are no existing solutions, to evaluate our solutions to the C-MaxRS-DU problem, we extended the best known MaxRS solution to cater to C-MaxRS-DU (see section 5.2&#x02014;i.e., processing the C-MaxRS at each event without any pruning) and used it as a baseline. For bursty streams, we compare the performance of C-MaxRS-Bursty and C-MaxRS-DU, i.e., C-MaxRS-DU becomes the baseline then.</p>
<p><bold><italic>Dataset</italic></bold>: Due to user privacy concerns and data sharing restrictions, very few (if any) authentic large categorical streaming data (with accurate time information) is publicly available. Thus, we used synthetic datasets in our experiments to simulate spatial data streams. Data points are generated by using both Uniform and Gaussian distributions in a two-dimensional data space of size 1, 000 &#x000D7; 1, 000<italic>m</italic> = <italic>1km</italic><sup>2</sup>. To simulate the behavior of spatial data streams from these static data points, we use exponential distribution with mean inter-arrival time of 10<italic>s</italic> and mean service time of 10<italic>s</italic>. Initially, we assume that 60% of all data points have already arrived in the system, and use this dataset for static part of evaluation. The remaining 40% of the data points arrive in the system by following exponential distribution as stated earlier. Any data point that is currently in the system, can depart after being served by the system. For experiments related to C-MaxRS-Bursty, we select &#x003B3; number of events (either in Gaussian or uniform distribution) at any time instant to emulate bursty inputs.</p>
<p><bold><italic>Parameters</italic></bold>: The list of parameters with their ranges, default values and symbols are shown in <xref ref-type="table" rid="T1">Table 1</xref>.</p>
<table-wrap position="float" id="T1">
<label>Table 1</label>
<caption><p>Parameters.</p></caption>
<table frame="hsides" rules="groups">
<thead><tr>
<th valign="top" align="left"><bold>Parameter name and symbol</bold></th>
<th valign="top" align="center"><bold>Possible values</bold></th>
<th valign="top" align="left"><bold>Default value</bold></th>
</tr>
</thead>
<tbody>
<tr>
<td valign="top" align="left">Object distribution</td>
<td valign="top" align="center">Uniform, Gaussian</td>
<td valign="top" align="left">Gaussian</td>
</tr>
<tr>
<td valign="top" align="left">Number of objects, <italic>N</italic></td>
<td valign="top" align="center">10k, 20k, 30k, 40k, 50k, 60k, 70k, 80k, 90k, 100k, 200k</td>
<td valign="top" align="left">50k</td>
</tr>
<tr>
<td valign="top" align="left">Number of POIClass, &#x003B2;</td>
<td valign="top" align="center">3, 4, 5, 6, 7</td>
<td valign="top" align="left">5</td>
</tr>
<tr>
<td valign="top" align="left">Min count (per class), &#x003BC;</td>
<td valign="top" align="center">1, 2, 3, 4, 5</td>
<td valign="top" align="left">3</td>
</tr>
<tr>
<td valign="top" align="left">Query area, &#x003BB; (in m<sup>2</sup>)</td>
<td valign="top" align="center">100, 225, 400, 625, 900</td>
<td valign="top" align="left">400</td>
</tr>
<tr>
<td valign="top" align="left">Theta (&#x003B8;)</td>
<td valign="top" align="center">1, 2, 3, 4, 5</td>
<td valign="top" align="left">3</td>
</tr>
<tr>
<td valign="top" align="left">Shape of <italic>R</italic>, <italic>b</italic>:<italic>a</italic></td>
<td valign="top" align="center">0.25,0.5,1,2,4</td>
<td valign="top" align="left">1</td>
</tr>
<tr>
<td valign="top" align="left">Weight, <italic>w</italic><sub><italic>i</italic></sub></td>
<td valign="top" align="center">[1, 10]</td>
<td valign="top" align="left">1</td>
</tr>
<tr>
<td valign="top" align="left">Bursty updates rate, &#x003B3;</td>
<td valign="top" align="center">100, 250, 500, 1k, 2.5k, 5k, 10k, 20k,</td>
<td valign="top" align="left">1k</td>
</tr>
<tr>
<td/>
<td valign="top" align="left">30k, 40k, 50k, 60k, 70k, 80k, 90k, 100k</td>
<td/>
</tr>
</tbody>
</table>
</table-wrap>
<p><bold><italic>Settings</italic></bold>: We have used Python 3.5 programming language to implement our algorithms. All the experiments were conducted in a PC equipped with intel core i5 6500 processor and 16 GB of RAM. We measure the average processing time of monitoring C-MaxRS in various settings. We also compute the performance of Static C-MaxRS computation. In the default settings, the processing time for Static C-MaxRS is 85.86 s. Note that, we exclude the processing time for static C-MaxRS computation in further analysis as this part is similar for both baseline and our approach.</p>
<sec>
<title>8.1. Performance Evaluation: Event-Based Scenario</title>
<p>We now present our detailed observations over different combinations of the parameters for non-bursty scenario (i.e., C-MaxRS-DU).</p>
<sec>
<title>8.1.1. Varying Number of Objects, <italic>N</italic></title>
<p>In this set of experiments, we vary the number of objects, <italic>N</italic>, from 10K to 100K (denoted 1&#x02013;10, respectively, in <xref ref-type="fig" rid="F6">Figure 6</xref> for brevity, i.e., each label of x-axis needs to be multiplied by 10k), and compare our algorithm with the baseline for different <italic>N</italic> using both Gaussian and Uniform distributions. <xref ref-type="fig" rid="F6">Figure 6i</xref> shows that for Gaussian distribution, the average processing time for our approach (in seconds) increases quadratically (semi-linearly) with the number of objects, whereas the processing time of baseline increases exponentially with the increase of <italic>N</italic>. For Gaussian distribution, on average our approach runs 3.08 times faster than the baseline algorithm. For Uniform distribution, on an average our approach runs 3.23 times faster than the baseline algorithm (<xref ref-type="fig" rid="F6">Figure 6ii</xref>). We also observe that our approach outperforms the baseline in a greater margin for a large number of objects as processing time of our approach increases linearly with <italic>N</italic> for Uniform distribution.</p>
<fig id="F6" position="float">
<label>Figure 6</label>
<caption><p><bold>(i)</bold> Varying <italic>N</italic> for Gaussian. <bold>(ii)</bold> Varying <italic>N</italic> for Uniform. <bold>(iii)</bold> Varying &#x003B8; for Gaussian. <bold>(iv)</bold> Varying &#x003B8; for Uniform.</p></caption>
<graphic xlink:href="fdata-03-00020-g0006.tif"/>
</fig>
</sec>
<sec>
<title>8.1.2. Varying Theta (&#x003B8;)</title>
<p><xref ref-type="fig" rid="F6">Figures 6iii,iv</xref> compare the performance of our approach with the baseline by varying theta (&#x003B8;) for Gaussian and Uniform distributions, respectively. We observe that for both distributions the processing time of baseline algorithm increases at a higher rate than our algorithm, with the increase of &#x003B8;. Moreover, in all the cases, our approach significantly outperforms the baseline algorithm in the absolute scale/sense. On the average, our approach runs 3.37 and 3.31 times faster than the baseline in Gaussian and Uniform distributions, respectively.</p>
</sec>
<sec>
<title>8.1.3. Varying &#x003BB; - the Area of the Query Rectangle</title>
<p>The impact of varying the area of the query rectangle on the average processing times of our approach and baseline algorithm, is shown in <xref ref-type="fig" rid="F7">Figures 7i,ii</xref>. For Gaussian distribution, on an average our approach shows 2.22 times better performance than the baseline approach. Similarly, in Uniform distribution, our approach runs 2.25 times (on average) faster than the baseline. Additionally, note that, as the area of query rectangle increases, corresponding processing time increases as well&#x02014;due to the possibility of a dual rectangle intersecting with more slices (and other dual rectangles).</p>
<fig id="F7" position="float">
<label>Figure 7</label>
<caption><p><bold>(i)</bold> Varying &#x003BB; for Gaussian. <bold>(ii)</bold> Varying &#x003BB; for Gaussian. <bold>(iii)</bold> Varying &#x003B2; for Gaussian. <bold>(iv)</bold> Varying &#x003B2; for Uniform.</p></caption>
<graphic xlink:href="fdata-03-00020-g0007.tif"/>
</fig>
</sec>
<sec>
<title>8.1.4. Varying POIClass Count, &#x003B2;</title>
<p>The average processing time of our approach and the baseline for varying POIClass Count, &#x003B2; is shown in <xref ref-type="fig" rid="F7">Figure 7</xref> [Gaussian (iii) and Uniform (iv)]. We observe that the processing time is maximum for the initial case where POIClass Count, &#x003B2; is minimum. Also, we can see that for the both distributions, the processing time decreases with increasing value of &#x003B2;&#x02014;i.e., handling larger number of classes is faster. On an average our approach runs 3.45 times faster than the baseline algorithm for Gaussian distribution of dataset. In case of Uniform distribution of data, our approach runs 3.06 times faster than the baseline.</p>
</sec>
<sec>
<title>8.1.5. Varying Min Class Count, &#x003BC;</title>
<p><xref ref-type="fig" rid="F8">Figures 8i,ii</xref> show the average processing time of our approach and the baseline by varying Min Class Count, &#x003BC;. Figures show that for both Gaussian and Uniform distributions, our approach outperforms the baseline significantly. We observe that on an average our approach runs 3.09 and 3.21 times faster than the baseline for Gaussian and Uniform distributions of dataset, respectively. We also note that, the processing time for our approach is largely unaffected by the varying &#x003BC; values.</p>
<fig id="F8" position="float">
<label>Figure 8</label>
<caption><p><bold>(i)</bold> Varying &#x003BC; for Gaussian. <bold>(ii)</bold> Varying &#x003BC; for Uniform. <bold>(iii)</bold> Varying <italic>b</italic>:<italic>a</italic> for Gaussian. <bold>(iv)</bold> Varying <italic>b</italic>:<italic>a</italic> for Uniform.</p></caption>
<graphic xlink:href="fdata-03-00020-g0008.tif"/>
</fig>
</sec>
<sec>
<title>8.1.6. Varying Shape of <italic>R</italic>, <italic>b</italic>:<italic>a</italic></title>
<p>By default, we have used <italic>b</italic>:<italic>a</italic> = 1 in other experiments, i.e., <italic>R</italic> is square-shaped. In this experiment, we investigate whether varying the shape of <italic>R</italic>, i.e., changing the ratio between its width and height, has any effects on the processing time of C-MaxRS-DU. In <xref ref-type="fig" rid="F8">Figure 8iii</xref> for Gaussian distribution, as width (<italic>b</italic>) of <italic>R</italic> is increased, the processing time increases too. This is because, we use &#x003B8; &#x000D7; <italic>b</italic> as the slice width and as <italic>b</italic> increases, number of slices <italic>s</italic> decreases&#x02014;reducing the benefits of spatial subdivision. Interestingly, similar trend is not observed in the uniform settings. We note that, in all cases, our approach runs faster than the baseline. In case of Uniform distribution (see <xref ref-type="fig" rid="F8">Figure 8iv</xref>), our approach outruns the baseline approach by 2.99 times on average. In case of Gaussian distribution, our approach outruns the baseline approach by 2.82 times on average.</p>
</sec>
<sec>
<title>8.1.7. Comparing Pruning Rules</title>
<p>In this set of experiments, we compare the performance of the different components of our approach. First, we have extended the static C-MaxRS algorithm to handle spatial data streams, which we call the baseline. Then we introduce two pruning rules, one for the appearance event, <italic>e</italic><sup>&#x0002B;</sup>-Pruning and the other for disappearance event, <italic>e</italic><sup>&#x02212;</sup>-Pruning. Finally, we combine both pruning rules to design our approach.</p>
<p>From <xref ref-type="fig" rid="F9">Figure 9</xref>, we can see that <italic>e</italic><sup>&#x0002B;</sup>-Pruning scheme gives 8.25% performance gain from the baseline algorithm for Gaussian distribution and gives 8.56% performance gain from the baseline algorithm for Uniform distribution of data. The <italic>e</italic><sup>&#x02212;</sup>-Pruning scheme provides almost 62.49% performance gain from the baseline for Uniform distribution and 63.01% performance gain from the baseline algorithm for Gaussian distribution.</p>
<fig id="F9" position="float">
<label>Figure 9</label>
<caption><p>Comparing pruning rules (Unweighted Objects) <bold>(i)</bold> Gaussian and <bold>(ii)</bold> Uniform.</p></caption>
<graphic xlink:href="fdata-03-00020-g0009.tif"/>
</fig>
<p>We also perform this experiment using weighted objects, where each object is assigned with a random weight. We vary the weights of the objects from 1 to 10. In <xref ref-type="fig" rid="F10">Figure 10</xref>, we see similar trends among the evaluated algorithms. Also, we note that, the processing time is faster for the weighted experiments. It is because, due to the variance in the weights of objects, more events can be pruned easily. This experiment also validates our analysis in section 6.</p>
<fig id="F10" position="float">
<label>Figure 10</label>
<caption><p>Comparing pruning rules (Weighted Objects) <bold>(i)</bold> Gaussian and <bold>(ii)</bold> Uniform.</p></caption>
<graphic xlink:href="fdata-03-00020-g0010.tif"/>
</fig>
</sec>
</sec>
<sec>
<title>8.2. Performance Evaluation: Bursty Streaming Updates</title>
<p>We now present our detailed observations over different combinations of the parameters for bursty updates (i.e., C-MaxRS-Bursty vs. C-MaxRS-DU).</p>
<sec>
<title>8.2.1. C-MaxRS-Bursty vs. C-MaxRS-DU</title>
<p>We present the performance comparison (over both distribution of data) for C-MaxRS-DU and C-MaxRS-Bursty in <xref ref-type="fig" rid="F11">Figure 11</xref> in default settings (i.e., &#x003B3; = 1000). We can see that C-MaxRS-Bursty is way more efficient than C-MaxRS-DU in handling bursty streams in both distributions, i.e., C-MaxRS-Bursty is almost 5 and 10 times faster than C-MaxRS-DU in the default settings for uniform and Gaussian distribution of data, respectively.</p>
<fig id="F11" position="float">
<label>Figure 11</label>
<caption><p>Comparing <italic>C</italic>-MaxRS-DU and <italic>C</italic>-MaxRS-Bursty for default settings.</p></caption>
<graphic xlink:href="fdata-03-00020-g0011.tif"/>
</fig>
</sec>
<sec>
<title>8.2.2. Varying &#x003B3;</title>
<p>We change the value of the bursty streaming rate, &#x003B3;, from 100 to 5,000. <xref ref-type="fig" rid="F12">Figure 12</xref> shows the total processing time (in seconds) of &#x003B3; events together. In <xref ref-type="fig" rid="F12">Figure 12i</xref> (uniform distribution), initially when &#x003B3; = 100, C-MaxRS-DU (2.99 s) performs better than C-MaxRS-Bursty (3.51s). But, for &#x003B3; = 250, C-MaxRS-Bursty performs faster, i.e., 7.4 vs. 4.88 s. Thus, for this setting, there is a value of &#x003B3; in-between 100 and 250, after which C-MaxRS-Bursty starts out-performing C-MaxRS-DU. This aligns with our intuition that for cases where &#x003B3; is not too high, C-MaxRS-DU gives us the optimal performance, whereas, C-MaxRS-Bursty is more efficient as &#x003B3; increases.</p>
<fig id="F12" position="float">
<label>Figure 12</label>
<caption><p>Varying &#x003B3; <bold>(i)</bold> Gaussian and <bold>(ii)</bold> Uniform.</p></caption>
<graphic xlink:href="fdata-03-00020-g0012.tif"/>
</fig>
<p>In <xref ref-type="fig" rid="F12">Figure 12</xref>, as the value of &#x003B3; increases, the processing time for C-MaxRS-DU increases exponentially, but the increase in C-MaxRS-Bursty is linear. C-MaxRS-Bursty outperforms C-MaxRS-DU by 5.89 times on average for uniform distribution of data, and by 10.94 times in case of Gaussian distribution of data. This experiment shows the effectiveness of C-MaxRS-Bursty for high streaming data.</p>
</sec>
<sec>
<title>8.2.3. Varying <italic>N</italic></title>
<p>Subsequently, we vary the value of <italic>N</italic>, i.e., number of objects, and preset the results in <xref ref-type="fig" rid="F13">Figure 13</xref>. Processing times of both the algorithms increase with the increasing cardinality, although, we note that the increase in C-MaxRS-Bursty is much slower. C-MaxRS-Bursty outperforms C-MaxRS-DU by 5.60 times on average for uniform distribution of data. For Gaussian distribution, C-MaxRS-Bursty outperforms C-MaxRS-DU by 11.34 times on average.</p>
<fig id="F13" position="float">
<label>Figure 13</label>
<caption><p>Varying <italic>N</italic> <bold>(i)</bold> Gaussian and <bold>(ii)</bold> Uniform.</p></caption>
<graphic xlink:href="fdata-03-00020-g0013.tif"/>
</fig>
</sec>
<sec>
<title>8.2.4. Scalability of C-MaxRS-Bursty</title>
<p>In the final experiment, we show the effect of larger &#x003B3; values on C-MaxRS-Bursty in <xref ref-type="fig" rid="F14">Figure 14</xref>. We also use a larger value of <italic>N</italic> for this experiment&#x02013;i.e., the value of &#x003B3; is varied from 10, 000 to 100, 000, and the total number of objects <italic>N</italic> is set to 200, 000. We omit the performance of C-MaxRS-DU for this experiment as the processing time for large &#x003B3; values is exponentially high (to avoid skewing the graph). We can see that, the results in <xref ref-type="fig" rid="F14">Figure 14</xref> illustrate similar trend as <xref ref-type="fig" rid="F12">Figure 12</xref>, even though we used significantly larger values of &#x003B3; and <italic>N</italic>. For both distributions, processing time increases only slightly as the value of &#x003B3; increases. For example, in <xref ref-type="fig" rid="F14">Figure 14i</xref>, for a 10 times increase of &#x003B3; value (from 10 k to 100k), the processing time only increases by 1.4 times (from 124.2 to 174.3 s). Same is true for uniform distribution (cf. <xref ref-type="fig" rid="F14">Figure 14i</xref>), where this increase is even less (1.27 times, i.e., from 95.1 to 124.8 s). We also note that, the bulk of the processing time of C-MaxRS-Bursty is consumed by lines 32&#x02013;33 of Algorithm 4&#x02013;i.e., executing the function <italic>PrepareSlices</italic> and <italic>SliceSearchMR</italic>. These results demonstrate the scalability of C-MaxRS-Bursty &#x02013; where it is ensured that recomputation (i.e., lines 32&#x02013;33) is performed only once (in worst case) instead of &#x003B3; times.</p>
<fig id="F14" position="float">
<label>Figure 14</label>
<caption><p>Varying &#x003B3; in larger scale <bold>(i)</bold> Gaussian and <bold>(ii)</bold> Uniform.</p></caption>
<graphic xlink:href="fdata-03-00020-g0014.tif"/>
</fig>
</sec>
</sec>
</sec>
<sec id="s9">
<title>9. Conclusions and Future Work</title>
<p>In this paper, we have proposed a new variant of MaxRS query, namely <italic>Conditional Maximizing Range-Sum</italic> (C-MaxRS) query in spatial data streaming updates for both non-weighted and weighted objects. Initially, we simply adapted the traditional MaxRS settings to incorporate conditional constraints of different class of objects. However, to handle data updates (i.e., appearance and disappearance of objects) with class-awareness, we needed additional spatial data structures, quadtree and a variant of self-balancing binary tree (e.g., we used AVL-tree), which enabled our algorithm to efficiently compute the changes in the result for different partitions (or slices) of the dataspace. To further improve the overall time-efficiency, we developed two pruning rules: one to handle the appearance of an object and the other to handle disappearance of an object while updating C-MaxRS results. Additionally, to accommodate a different kind of applications settings where a bursty stream of data updates occur in a short time interval, we have proposed a novel technique, C-MaxRS-Bursty to efficiently compute the C-MaxRS results via bulk updates handling. We considered a large parameters space and conducted extensive set of experiments. In sequential spatial data stream scenario, our approach, C-MaxRS-DU yields three to four times improvements (on average) in terms of processing time, when compared to the baseline algorithm. We have also observed that in a bursty scenario, our approach C-MaxRS-Bursty outperforms our one-at-a-time approach, C-MaxRS-DU, by 5&#x02013;10 times.</p>
<p>There are several immediate extensions to our work. Firstly, we would like to investigate the trade-offs arising when there is a constraint between the time-instant of a particular update and the update of the answer. This, in some sense, may require a new approach where the bulk update algorithms and data structures proposed in this work will need to be adapted to handle dynamic invocations (e.g., when the buffer of new data reaches certain capacity). Complementary to this, we plan to investigate the C-MaxRS in more traditional streaming settings&#x02014;i.e., when there is a constraint on the memory and the arrival rate is explicitly taken in consideration. In such cases, relying on data sketches may be inevitable (similar to Cormode, <xref ref-type="bibr" rid="B9">2017</xref>). Lastly, we are investigating the variations of C-MaxRS where different kinds of mobility may need to be incorporated&#x02014;for both the users (cf. Hussain et al., <xref ref-type="bibr" rid="B15">2017a</xref>) and the query rectangle (e.g., in the Loon Project settings), as well as the mutual dependencies of both.</p>
</sec>
<sec sec-type="data-availability-statement" id="s10">
<title>Data Availability Statement</title>
<p>The datasets and the code used in the experiments are publicly available at: <ext-link ext-link-type="uri" xlink:href="https://users.cs.northwestern.edu/&#x0007E;mmh683/project-works/Conditional-MaxRS-Streams/">https://users.cs.northwestern.edu/&#x0007E;mmh683/project-works/Conditional-MaxRS-Streams/</ext-link>.</p>
</sec>
<sec id="s11">
<title>Author Contributions</title>
<p>All authors listed have made a substantial, direct and intellectual contribution to the work, and approved it for publication.</p>
</sec>
<sec id="s12">
<title>Conflict of Interest</title>
<p>The authors declare that the research was conducted in the absence of any commercial or financial relationships that could be construed as a potential conflict of interest.</p>
</sec>
</body>
<back>
<ack><p>We acknowledge that a preliminary version of this paper has appeared in Mostafiz et al. (<xref ref-type="bibr" rid="B28">2017</xref>), where we focused on non-weighted version of the C-MaxRS problem only, and in section 1, we briefly listed modifications and extensions to Mostafiz et al. (<xref ref-type="bibr" rid="B28">2017</xref>) in the current article.</p>
</ack>
<ref-list>
<title>References</title>
<ref id="B1">
<citation citation-type="web">(<year>2016</year>). <source>Google X Loon Project</source>. Available onlineat: <ext-link ext-link-type="uri" xlink:href="https://x.company/loon/">https://x.company/loon/</ext-link> (accessed January 31 ,2017).</citation></ref>
<ref id="B2">
<citation citation-type="book"><person-group person-group-type="author"><name><surname>Amagata</surname> <given-names>D.</given-names></name> <name><surname>Hara</surname> <given-names>T.</given-names></name></person-group> (<year>2016</year>). <article-title>&#x0201C;Monitoring MaxRS in spatial data streams,&#x0201D;</article-title> in <source>19th International Conference on Extending Database Technology</source> (<publisher-loc>Bordeaux</publisher-loc>).</citation></ref>
<ref id="B3">
<citation citation-type="book"><person-group person-group-type="author"><name><surname>Amini</surname> <given-names>A.</given-names></name> <name><surname>Wah</surname> <given-names>T. Y.</given-names></name> <name><surname>Saybani</surname> <given-names>M. R.</given-names></name> <name><surname>Yazdi</surname> <given-names>S. R. A. S.</given-names></name></person-group> (<year>2011</year>). <article-title>&#x0201C;A study of density-grid based clustering algorithms on data streams,&#x0201D;</article-title> in <source>2011 Eighth International Conference on Fuzzy Systems and Knowledge Discovery (FSKD)</source>, Vol. <volume>3</volume> (<publisher-loc>Shanghai</publisher-loc>: <publisher-name>IEEE</publisher-name>), <fpage>1652</fpage>&#x02013;<lpage>1656</lpage>. <pub-id pub-id-type="doi">10.1109/FSKD.2011.6019867</pub-id></citation></ref>
<ref id="B4">
<citation citation-type="book"><person-group person-group-type="author"><name><surname>Babcock</surname> <given-names>B.</given-names></name> <name><surname>Datar</surname> <given-names>M.</given-names></name> <name><surname>Motwani</surname> <given-names>R.</given-names></name></person-group> (<year>2004</year>). <article-title>&#x0201C;Load shedding for aggregation queries over data streams,&#x0201D;</article-title> in <source>20th International Conference on Data Engineering, 2004</source> (<publisher-loc>Boston, MA</publisher-loc>: <publisher-name>IEEE</publisher-name>), <fpage>350</fpage>&#x02013;<lpage>361</lpage>. <pub-id pub-id-type="doi">10.1109/ICDE.2004.1320010</pub-id></citation></ref>
<ref id="B5">
<citation citation-type="book"><person-group person-group-type="author"><name><surname>Cervino</surname> <given-names>J.</given-names></name> <name><surname>Kalyvianaki</surname> <given-names>E.</given-names></name> <name><surname>Salvachua</surname> <given-names>J.</given-names></name> <name><surname>Pietzuch</surname> <given-names>P.</given-names></name></person-group> (<year>2012</year>). <article-title>&#x0201C;Adaptive provisioning of stream processing systems in the cloud,&#x0201D;</article-title> in <source>2012 IEEE 28th International Conference on Data Engineering Workshops (ICDEW)</source> (<publisher-loc>Arlington, VA</publisher-loc>: <publisher-name>IEEE</publisher-name>), <fpage>295</fpage>&#x02013;<lpage>301</lpage>. <pub-id pub-id-type="doi">10.1109/ICDEW.2012.40</pub-id></citation></ref>
<ref id="B6">
<citation citation-type="journal"><person-group person-group-type="author"><name><surname>Chen</surname> <given-names>Z.</given-names></name> <name><surname>Liu</surname> <given-names>Y.</given-names></name> <name><surname>Wong</surname> <given-names>R. C.-W.</given-names></name> <name><surname>Xiong</surname> <given-names>J.</given-names></name> <name><surname>Cheng</surname> <given-names>X.</given-names></name> <name><surname>Chen</surname> <given-names>P.</given-names></name></person-group> (<year>2015</year>). <article-title>Rotating MaxRS queries</article-title>. <source>Inform. Sci</source>. <volume>305</volume>, <fpage>110</fpage>&#x02013;<lpage>129</lpage>. <pub-id pub-id-type="doi">10.1016/j.ins.2015.02.009</pub-id></citation></ref>
<ref id="B7">
<citation citation-type="journal"><person-group person-group-type="author"><name><surname>Cho</surname> <given-names>H.-J.</given-names></name> <name><surname>Chung</surname> <given-names>C.-W.</given-names></name></person-group> (<year>2007</year>). <article-title>Indexing range sum queries in spatio-temporal databases</article-title>. <source>Inform. Softw. Technol</source>. <volume>49</volume>, <fpage>324</fpage>&#x02013;<lpage>331</lpage>. <pub-id pub-id-type="doi">10.1016/j.infsof.2006.05.005</pub-id></citation></ref>
<ref id="B8">
<citation citation-type="journal"><person-group person-group-type="author"><name><surname>Choi</surname> <given-names>D. W.</given-names></name> <name><surname>Chung</surname> <given-names>C. W.</given-names></name> <name><surname>Tao</surname> <given-names>Y.</given-names></name></person-group> (<year>2014</year>). <article-title>Maximizing Range Sum in external memory</article-title>. <source>ACM Trans. Database Syst</source>. <volume>39</volume>, <volume>21</volume>:<fpage>1</fpage>&#x02013;<lpage>21:44</lpage>. <pub-id pub-id-type="doi">10.1145/2629477</pub-id></citation></ref>
<ref id="B9">
<citation citation-type="journal"><person-group person-group-type="author"><name><surname>Cormode</surname> <given-names>G.</given-names></name></person-group> (<year>2017</year>). <article-title>Data sketching</article-title>. <source>ACM Queue</source> <volume>15</volume>:<fpage>60</fpage>. <pub-id pub-id-type="doi">10.1145/3080008</pub-id></citation></ref>
<ref id="B10">
<citation citation-type="journal"><person-group person-group-type="author"><name><surname>Dallachiesa</surname> <given-names>M.</given-names></name> <name><surname>Jacques-Silva</surname> <given-names>G.</given-names></name> <name><surname>Gedik</surname> <given-names>B.</given-names></name> <name><surname>Wu</surname> <given-names>K.-L.</given-names></name> <name><surname>Palpanas</surname> <given-names>T.</given-names></name></person-group> (<year>2015</year>). <article-title>Sliding windows over uncertain data streams</article-title>. <source>Knowl. Inform. Syst</source>. <volume>45</volume>, <fpage>159</fpage>&#x02013;<lpage>190</lpage>. <pub-id pub-id-type="doi">10.1007/s10115-014-0804-5</pub-id></citation></ref>
<ref id="B11">
<citation citation-type="journal"><person-group person-group-type="author"><name><surname>Dean</surname> <given-names>J.</given-names></name> <name><surname>Ghemawat</surname> <given-names>S.</given-names></name></person-group> (<year>2008</year>). <article-title>Mapreduce: simplified data processing on large clusters</article-title>. <source>Commun. ACM</source> <volume>51</volume>, <fpage>107</fpage>&#x02013;<lpage>113</lpage>. <pub-id pub-id-type="doi">10.1145/1327452.1327492</pub-id></citation></ref>
<ref id="B12">
<citation citation-type="book"><person-group person-group-type="author"><name><surname>Eldawy</surname> <given-names>A.</given-names></name> <name><surname>Mokbel</surname> <given-names>M. F.</given-names></name></person-group> (<year>2015</year>). <article-title>&#x0201C;Spatialhadoop: a mapreduce framework for spatial data,&#x0201D;</article-title> in <source>2015 IEEE 31st International Conference on Data Engineering (ICDE)</source> (<publisher-loc>Seoul</publisher-loc>: <publisher-name>IEEE</publisher-name>), <fpage>1352</fpage>&#x02013;<lpage>1363</lpage>. <pub-id pub-id-type="doi">10.1109/ICDE.2015.7113382</pub-id></citation></ref>
<ref id="B13">
<citation citation-type="book"><person-group person-group-type="author"><name><surname>Feng</surname> <given-names>K.</given-names></name> <name><surname>Cong</surname> <given-names>G.</given-names></name> <name><surname>Bhowmick</surname> <given-names>S. S.</given-names></name> <name><surname>Peng</surname> <given-names>W.</given-names></name> <name><surname>Miao</surname> <given-names>C.</given-names></name></person-group> (<year>2016</year>). <article-title>&#x0201C;Towards best region search for data exploration,&#x0201D;</article-title> in <source>ACM SIGMOD International Conference on Management of Data</source> (<publisher-loc>San Francisco, CA</publisher-loc>). <pub-id pub-id-type="doi">10.1145/2882903.2882960</pub-id></citation></ref>
<ref id="B14">
<citation citation-type="book"><person-group person-group-type="author"><name><surname>Hart</surname> <given-names>Q.</given-names></name> <name><surname>Gertz</surname> <given-names>M.</given-names></name> <name><surname>Zhang</surname> <given-names>J.</given-names></name></person-group> (<year>2005</year>). <article-title>&#x0201C;Evaluation of a dynamic tree structure for indexing query regions on streaming geospatial data,&#x0201D;</article-title> in <source>International Symposium on Spatial and Temporal Databases</source> (<publisher-loc>Angra dos Reis</publisher-loc>: <publisher-name>Springer</publisher-name>), <fpage>145</fpage>&#x02013;<lpage>162</lpage>. <pub-id pub-id-type="doi">10.1007/11535331_9</pub-id></citation></ref>
<ref id="B15">
<citation citation-type="book"><person-group person-group-type="author"><name><surname>Hussain</surname> <given-names>M. M.</given-names></name> <name><surname>Islam</surname> <given-names>K. A.</given-names></name> <name><surname>Trajcevski</surname> <given-names>G.</given-names></name> <name><surname>Ali</surname> <given-names>M. E.</given-names></name></person-group> (<year>2017a</year>). <article-title>&#x0201C;Towards efficient maintenance of continuous MaxRs query for trajectories,&#x0201D;</article-title> in <source>20th International Conference on Extending Database Technology</source> (<publisher-loc>Venice</publisher-loc>: <publisher-name>EDBT</publisher-name>).</citation></ref>
<ref id="B16">
<citation citation-type="book"><person-group person-group-type="author"><name><surname>Hussain</surname> <given-names>M. M.</given-names></name> <name><surname>Trajcevski</surname> <given-names>G.</given-names></name> <name><surname>Islam</surname> <given-names>K. A.</given-names></name> <name><surname>Ali</surname> <given-names>M. E.</given-names></name></person-group> (<year>2017b</year>). <article-title>&#x0201C;Visualization of range-constrained optimal density clustering of trajectories,&#x0201D;</article-title> in <source>International Symposium on Spatial and Temporal Databases</source> (<publisher-loc>Arlington, VA</publisher-loc>: <publisher-name>Springer</publisher-name>), <fpage>427</fpage>&#x02013;<lpage>432</lpage>. <pub-id pub-id-type="doi">10.1007/978-3-319-64367-0_29</pub-id></citation></ref>
<ref id="B17">
<citation citation-type="book"><person-group person-group-type="author"><name><surname>Hussain</surname> <given-names>M. M.</given-names></name> <name><surname>Wongse-ammat</surname> <given-names>P.</given-names></name> <name><surname>Trajcevski</surname> <given-names>G.</given-names></name></person-group> (<year>2015</year>). <article-title>&#x0201C;Demo: distributed MaxRS in wireless sensor networks,&#x0201D;</article-title> in <source>ACM Conference on Embedded Networked Sensor Systems (SenSys)</source> (<publisher-loc>Seoul</publisher-loc>: <publisher-name>ACM</publisher-name>). <pub-id pub-id-type="doi">10.1145/2809695.2817863</pub-id></citation></ref>
<ref id="B18">
<citation citation-type="journal"><person-group person-group-type="author"><name><surname>Imai</surname> <given-names>H.</given-names></name> <name><surname>Asano</surname> <given-names>T.</given-names></name></person-group> (<year>1983</year>). <article-title>Finding the connected components and a maximum clique of an intersection graph of rectangles in the plane</article-title>. <source>J. Algor</source>. <volume>4</volume>, <fpage>310</fpage>&#x02013;<lpage>323</lpage>. <pub-id pub-id-type="doi">10.1016/0196-6774(83)90012-3</pub-id></citation></ref>
<ref id="B19">
<citation citation-type="book"><person-group person-group-type="author"><name><surname>Issa</surname> <given-names>H.</given-names></name> <name><surname>Damiani</surname> <given-names>M. L.</given-names></name></person-group> (<year>2016</year>). <article-title>&#x0201C;Efficient access to temporally overlaying spatial and textual trajectories,&#x0201D;</article-title> in <source>IEEE 17th International Conference on Mobile Data Management, MDM 2016</source> (<publisher-loc>Porto</publisher-loc>), <fpage>262</fpage>&#x02013;<lpage>271</lpage>. <pub-id pub-id-type="doi">10.1109/MDM.2016.47</pub-id></citation></ref>
<ref id="B20">
<citation citation-type="journal"><person-group person-group-type="author"><name><surname>Kamel</surname> <given-names>I.</given-names></name> <name><surname>Faloutsos</surname> <given-names>C.</given-names></name></person-group> (<year>1992</year>). <source>Parallel R-Trees</source>. Vol. 21. ACM. <pub-id pub-id-type="doi">10.1145/141484.130315</pub-id></citation></ref>
<ref id="B21">
<citation citation-type="journal"><person-group person-group-type="author"><name><surname>Kim</surname> <given-names>J.</given-names></name> <name><surname>Kim</surname> <given-names>S.-G.</given-names></name> <name><surname>Nam</surname> <given-names>B.</given-names></name></person-group> (<year>2013</year>). <article-title>Parallel multi-dimensional range query processing with R-trees on GPU</article-title>. <source>J. Parallel Distrib. Comput</source>. <volume>73</volume>, <fpage>1195</fpage>&#x02013;<lpage>1207</lpage>. <pub-id pub-id-type="doi">10.1016/j.jpdc.2013.03.015</pub-id></citation></ref>
<ref id="B22">
<citation citation-type="book"><person-group person-group-type="author"><name><surname>Kipf</surname> <given-names>A.</given-names></name> <name><surname>Lang</surname> <given-names>H.</given-names></name> <name><surname>Pandey</surname> <given-names>V.</given-names></name> <name><surname>Alexandru Persa</surname> <given-names>R.</given-names></name> <name><surname>Anneser</surname> <given-names>C.</given-names></name> <name><surname>Tzirita Zacharatou</surname> <given-names>E.</given-names></name> <etal/></person-group>. (<year>2020</year>). <article-title>&#x0201C;Adaptive main-memory indexing for high-performance point-polygon joins,&#x0201D;</article-title> in <source>Proceedings of the 23nd International Conference on Extending Database Technology, EDBT 2020</source> (<publisher-loc>Copenhagen</publisher-loc>), <fpage>347</fpage>&#x02013;<lpage>358</lpage>.</citation></ref>
<ref id="B23">
<citation citation-type="journal"><person-group person-group-type="author"><name><surname>Kleinberg</surname> <given-names>J.</given-names></name></person-group> (<year>2003</year>). <article-title>Bursty and hierarchical structure in streams</article-title>. <source>Data Mining Knowl. Discov</source>. <volume>7</volume>, <fpage>373</fpage>&#x02013;<lpage>397</lpage>. <pub-id pub-id-type="doi">10.1023/A:1024940629314</pub-id></citation></ref>
<ref id="B24">
<citation citation-type="book"><person-group person-group-type="author"><name><surname>Lazaridis</surname> <given-names>I.</given-names></name> <name><surname>Mehrotra</surname> <given-names>S.</given-names></name></person-group> (<year>2001</year>). <article-title>&#x0201C;Progressive approximate aggregate queries with a multi-resolution tree structure,&#x0201D;</article-title> in <source>ACM SIGMOD Record</source> (<publisher-loc>Santa Barbara, CA</publisher-loc>). <pub-id pub-id-type="doi">10.1145/376284.375718</pub-id></citation></ref>
<ref id="B25">
<citation citation-type="book"><person-group person-group-type="author"><name><surname>Liu</surname> <given-names>Q.</given-names></name> <name><surname>Lian</surname> <given-names>X.</given-names></name> <name><surname>Chen</surname> <given-names>L.</given-names></name></person-group> (<year>2019</year>). <article-title>&#x0201C;Probabilistic maximum range-sum queries on spatial database,&#x0201D;</article-title> in <source>Proceedings of the 27th ACM SIGSPATIAL International Conference on Advances in Geographic Information Systems</source> (<publisher-loc>Chicago, IL</publisher-loc>), <fpage>159</fpage>&#x02013;<lpage>168</lpage>. <pub-id pub-id-type="doi">10.1145/3347146.3359376</pub-id></citation>
</ref>
<ref id="B26">
<citation citation-type="web"><person-group person-group-type="author"><name><surname>Manyika</surname> <given-names>J.</given-names></name> <name><surname>Chui</surname> <given-names>M.</given-names></name> <name><surname>Brown</surname> <given-names>B.</given-names></name> <name><surname>Bughin</surname> <given-names>J.</given-names></name> <name><surname>Dobbs</surname> <given-names>R.</given-names></name> <name><surname>Roxburgh</surname> <given-names>C.</given-names></name> <etal/></person-group>. (<year>2011</year>). <source>Big Data: The Next Frontier for Innovation, Competition, and Productivity</source>. Available online at: <ext-link ext-link-type="uri" xlink:href="https://www.mckinsey.com/business-functions/mckinsey-digital/our-insights/big-data-the-next-frontier-for-innovation">https://www.mckinsey.com/business-functions/mckinsey-digital/our-insights/big-data-the-next-frontier-for-innovation</ext-link></citation></ref>
<ref id="B27">
<citation citation-type="journal"><person-group person-group-type="author"><name><surname>Mokbel</surname> <given-names>M. F.</given-names></name> <name><surname>Xiong</surname> <given-names>X.</given-names></name> <name><surname>Hammad</surname> <given-names>M. A.</given-names></name> <name><surname>Aref</surname> <given-names>W. G.</given-names></name></person-group> (<year>2005</year>). <article-title>Continuous query processing of spatio-temporal data streams in place</article-title>. <source>GeoInformatica</source> <volume>9</volume>, <fpage>343</fpage>&#x02013;<lpage>365</lpage>. <pub-id pub-id-type="doi">10.1007/s10707-005-4576-7</pub-id></citation></ref>
<ref id="B28">
<citation citation-type="book"><person-group person-group-type="author"><name><surname>Mostafiz</surname> <given-names>M. I.</given-names></name> <name><surname>Mahmud</surname> <given-names>S.</given-names></name> <name><surname>Hussain</surname> <given-names>M. M.</given-names></name> <name><surname>Ali</surname> <given-names>M. E.</given-names></name> <name><surname>Trajcevski</surname> <given-names>G.</given-names></name></person-group> (<year>2017</year>). <article-title>&#x0201C;Class-based conditional MaxRs query in spatial data streams,&#x0201D;</article-title> in <source>Proceedings of the 29th International Conference on Scientific and Statistical Database Management</source> (<publisher-loc>Chicago, IL</publisher-loc>: <publisher-name>ACM</publisher-name>), <fpage>13</fpage>. <pub-id pub-id-type="doi">10.1145/3085504.3085517</pub-id></citation></ref>
<ref id="B29">
<citation citation-type="journal"><person-group person-group-type="author"><name><surname>Nandy</surname> <given-names>S. C.</given-names></name> <name><surname>Bhattacharya</surname> <given-names>B. B.</given-names></name></person-group> (<year>1995</year>). <article-title>A unified algorithm for finding maximum and minimum object enclosing rectangles and cuboids</article-title>. <source>Comput. Math. Appl</source>. <volume>29</volume>, <fpage>45</fpage>&#x02013;<lpage>61</lpage>. <pub-id pub-id-type="doi">10.1016/0898-1221(95)00029-X</pub-id></citation></ref>
<ref id="B30">
<citation citation-type="journal"><person-group person-group-type="author"><name><surname>Narendra</surname> <given-names>P. M.</given-names></name> <name><surname>Fukunaga</surname> <given-names>K.</given-names></name></person-group> (<year>1977</year>). <article-title>A branch and bound algorithm for feature subset selection</article-title>. <source>IEEE Trans. Comput</source>. <volume>26</volume>, <fpage>917</fpage>&#x02013;<lpage>922</lpage>. <pub-id pub-id-type="doi">10.1109/TC.1977.1674939</pub-id></citation></ref>
<ref id="B31">
<citation citation-type="journal"><person-group person-group-type="author"><name><surname>Nievergelt</surname> <given-names>J.</given-names></name> <name><surname>Reingold</surname> <given-names>E. M.</given-names></name></person-group> (<year>1973</year>). <article-title>Binary search trees of bounded balance</article-title>. <source>SIAM J. Comput</source>. <volume>2</volume>, <fpage>33</fpage>&#x02013;<lpage>43</lpage>. <pub-id pub-id-type="doi">10.1137/0202005</pub-id></citation></ref>
<ref id="B32">
<citation citation-type="journal"><person-group person-group-type="author"><name><surname>Ooi</surname> <given-names>B.</given-names></name> <name><surname>Sacks-Davis</surname> <given-names>R.</given-names></name> <name><surname>Han</surname> <given-names>J.</given-names></name></person-group> (<year>1993</year>). <source>Indexing in Spatial Databases</source>. Unpublished/Technical Papers.</citation></ref>
<ref id="B33">
<citation citation-type="book"><person-group person-group-type="author"><name><surname>Papadias</surname> <given-names>D.</given-names></name> <name><surname>Kalnis</surname> <given-names>P.</given-names></name> <name><surname>Zhang</surname> <given-names>J.</given-names></name> <name><surname>Tao</surname> <given-names>Y.</given-names></name></person-group> (<year>2001</year>). <article-title>&#x0201C;Efficient OLAP operations in spatial data warehouses,&#x0201D;</article-title> in <source>International Symposium on Spatial and Temporal Databases</source> (<publisher-loc>Redondo Beach, CA</publisher-loc>: <publisher-name>Springer</publisher-name>), <fpage>443</fpage>&#x02013;<lpage>459</lpage>. <pub-id pub-id-type="doi">10.1007/3-540-47724-1_23</pub-id></citation></ref>
<ref id="B34">
<citation citation-type="journal"><person-group person-group-type="author"><name><surname>Phan</surname> <given-names>T.-K.</given-names></name> <name><surname>Jung</surname> <given-names>H.</given-names></name> <name><surname>Kim</surname> <given-names>U.-M.</given-names></name></person-group> (<year>2014</year>). <article-title>An efficient algorithm for Maximizing Range Sum queries in a road network</article-title>. <source>Sci. World J</source>. <volume>2014</volume>:<fpage>541602</fpage>. <pub-id pub-id-type="doi">10.1155/2014/541602</pub-id><pub-id pub-id-type="pmid">25152915</pub-id></citation></ref>
<ref id="B35">
<citation citation-type="book"><person-group person-group-type="author"><name><surname>Samet</surname> <given-names>H.</given-names></name></person-group> (<year>1990</year>). <source>Applications of Spatial Data Structures: Computer Graphics, Image Processing, and GIS</source>. <publisher-loc>Boston, MA</publisher-loc>: <publisher-name>Addison-Wesley Longman Publishing Co</publisher-name>., Inc. <pub-id pub-id-type="doi">10.1007/3-540-52208-5_28</pub-id></citation></ref>
<ref id="B36">
<citation citation-type="book"><person-group person-group-type="author"><name><surname>Sheng</surname> <given-names>C.</given-names></name> <name><surname>Tao</surname> <given-names>Y.</given-names></name></person-group> (<year>2011</year>). <article-title>&#x0201C;New results on two-dimensional orthogonal range aggregation in external memory,&#x0201D;</article-title> in <source>Proceedings of the Thirtieth ACM SIGMOD-SIGACT-SIGART Symposium on Principles of Database Systems</source> (<publisher-loc>Athens</publisher-loc>). <pub-id pub-id-type="doi">10.1145/1989284.1989297</pub-id></citation></ref>
<ref id="B37">
<citation citation-type="book"><person-group person-group-type="author"><name><surname>Shvachko</surname> <given-names>K.</given-names></name> <name><surname>Kuang</surname> <given-names>H.</given-names></name> <name><surname>Radia</surname> <given-names>S.</given-names></name> <name><surname>Chansler</surname> <given-names>R.</given-names></name></person-group> (<year>2010</year>). <article-title>&#x0201C;The Hadoop distributed file system,&#x0201D;</article-title> in <source>2010 IEEE 26th symposium on Mass Storage Systems and Technologies (MSST)</source> (<publisher-loc>Incline Village, NV</publisher-loc>: <publisher-name>IEEE</publisher-name>), <fpage>1</fpage>&#x02013;<lpage>10</lpage>. <pub-id pub-id-type="doi">10.1109/MSST.2010.5496972</pub-id></citation></ref>
<ref id="B38">
<citation citation-type="book"><person-group person-group-type="author"><name><surname>&#x00160;idlauskas</surname> <given-names>D.</given-names></name> <name><surname>&#x00160;altenis</surname> <given-names>S.</given-names></name> <name><surname>Christiansen</surname> <given-names>C. W.</given-names></name> <name><surname>Johansen</surname> <given-names>J. M.</given-names></name> <name><surname>&#x00160;aulys</surname> <given-names>D.</given-names></name></person-group> (<year>2009</year>). <article-title>&#x0201C;Trees or grids?: indexing moving objects in main memory,&#x0201D;</article-title> in <source>Proceedings of the 17th ACM SIGSPATIAL International Conference on Advances in Geographic Information Systems</source> (<publisher-loc>Redondo Beach, CA</publisher-loc>: <publisher-name>ACM</publisher-name>), <fpage>236</fpage>&#x02013;<lpage>245</lpage>. <pub-id pub-id-type="doi">10.1145/1653771.1653805</pub-id></citation></ref>
<ref id="B39">
<citation citation-type="journal"><person-group person-group-type="author"><name><surname>Tao</surname> <given-names>Y.</given-names></name> <name><surname>Hu</surname> <given-names>X.</given-names></name> <name><surname>Choi</surname> <given-names>D.-W.</given-names></name> <name><surname>Chung</surname> <given-names>C.-W.</given-names></name></person-group> (<year>2013</year>). <article-title>Approximate MaxRs in spatial databases</article-title>. <source>Proc. VLDB Endow</source>. <volume>6</volume>, <fpage>1546</fpage>&#x02013;<lpage>1557</lpage>. <pub-id pub-id-type="doi">10.14778/2536258.2536266</pub-id></citation></ref>
<ref id="B40">
<citation citation-type="journal"><person-group person-group-type="author"><name><surname>Tao</surname> <given-names>Y.</given-names></name> <name><surname>Papadias</surname> <given-names>D.</given-names></name></person-group> (<year>2004</year>). <article-title>Range aggregate processing in spatial databases</article-title>. <source>IEEE Trans. Knowl. Data Eng</source>. <volume>16</volume>, <fpage>1555</fpage>&#x02013;<lpage>1570</lpage>. <pub-id pub-id-type="doi">10.1109/TKDE.2004.93</pub-id></citation></ref>
<ref id="B41">
<citation citation-type="journal"><person-group person-group-type="author"><name><surname>Tao</surname> <given-names>Y.</given-names></name> <name><surname>Sheng</surname> <given-names>C.</given-names></name> <name><surname>Chung</surname> <given-names>C.-W.</given-names></name> <name><surname>Lee</surname> <given-names>J.-R.</given-names></name></person-group> (<year>2014</year>). <article-title>Range aggregation with set selection</article-title>. <source>IEEE Trans. Knowl. Data Eng</source>. <volume>26</volume>, <fpage>1240</fpage>&#x02013;<lpage>1252</lpage>. <pub-id pub-id-type="doi">10.1109/TKDE.2013.125</pub-id></citation></ref>
<ref id="B42">
<citation citation-type="book"><person-group person-group-type="author"><name><surname>Wongse-ammat</surname> <given-names>P.</given-names></name> <name><surname>Hussain</surname> <given-names>M. M.</given-names></name> <name><surname>Trajcevski</surname> <given-names>G.</given-names></name> <name><surname>Avci</surname> <given-names>B.</given-names></name> <name><surname>Khokhar</surname> <given-names>A.</given-names></name></person-group> (<year>2017</year>). <article-title>&#x0201C;Distributed in-network processing of K-MaxRs in wireless sensor networks,&#x0201D;</article-title> in <source>7th International Conference on Sensor Networks, SENSORNETS</source> (<publisher-loc>Funchal</publisher-loc>). <pub-id pub-id-type="doi">10.5220/0006210701080117</pub-id></citation></ref>
<ref id="B43">
<citation citation-type="book"><person-group person-group-type="author"><name><surname>Zhang</surname> <given-names>J.</given-names></name> <name><surname>Zhu</surname> <given-names>M.</given-names></name> <name><surname>Papadias</surname> <given-names>D.</given-names></name> <name><surname>Tao</surname> <given-names>Y.</given-names></name> <name><surname>Lee</surname> <given-names>D. L.</given-names></name></person-group> (<year>2003</year>). <article-title>&#x0201C;Location-based spatial queries,&#x0201D;</article-title> in <source>Proceedings of the 2003 ACM SIGMOD</source> (<publisher-loc>San Diego, CA</publisher-loc>). <pub-id pub-id-type="doi">10.1145/872757.872812</pub-id></citation></ref>
<ref id="B44">
<citation citation-type="journal"><person-group person-group-type="author"><name><surname>Zhong</surname> <given-names>Y.</given-names></name> <name><surname>Han</surname> <given-names>J.</given-names></name> <name><surname>Zhang</surname> <given-names>T.</given-names></name> <name><surname>Li</surname> <given-names>Z.</given-names></name> <name><surname>Fang</surname> <given-names>J.</given-names></name> <name><surname>Chen</surname> <given-names>G.</given-names></name></person-group> (<year>2012</year>). <article-title>&#x0201C;Towards parallel spatial query processing for big spatial data,&#x0201D;</article-title> in <source>2012 IEEE 26th International Conference on Parallel and Distributed Processing Symposium Workshops &#x00026; PhD Forum (IPDPSW)</source> (IEEE), <fpage>2085</fpage>&#x02013;<lpage>2094</lpage>. <pub-id pub-id-type="doi">10.1109/IPDPSW.2012.245</pub-id></citation></ref>
<ref id="B45">
<citation citation-type="book"><person-group person-group-type="author"><name><surname>Zhou</surname> <given-names>X.</given-names></name> <name><surname>Wang</surname> <given-names>W.</given-names></name></person-group> (<year>2016</year>). <article-title>&#x0201C;An index-based method for efficient maximizing range sum queries in road network,&#x0201D;</article-title> in <source>Australasian Database Conference</source> (<publisher-loc>Sydney, NSW</publisher-loc>: <publisher-name>Springer</publisher-name>), <fpage>95</fpage>&#x02013;<lpage>109</lpage>. <pub-id pub-id-type="doi">10.1007/978-3-319-46922-5_8</pub-id><pub-id pub-id-type="pmid">25152915</pub-id></citation></ref>
<ref id="B46">
<citation citation-type="book"><person-group person-group-type="author"><name><surname>Zhou</surname> <given-names>Z.</given-names></name> <name><surname>Wu</surname> <given-names>W.</given-names></name> <name><surname>Li</surname> <given-names>X.</given-names></name> <name><surname>Lee</surname> <given-names>M. L.</given-names></name> <name><surname>Hsu</surname> <given-names>W.</given-names></name></person-group> (<year>2011</year>). <article-title>&#x0201C;MaxFirst for MaxBRkNN,&#x0201D;</article-title> in <source>Proceedings of the 27th IEEE ICDE 2011</source> (<publisher-loc>Hannover</publisher-loc>), <fpage>828</fpage>&#x02013;<lpage>839</lpage>. <pub-id pub-id-type="doi">10.1109/ICDE.2011.5767892</pub-id></citation></ref>
</ref-list>
<fn-group>
<fn id="fn0001"><p><sup>1</sup>cf. https://www.census.gov/topics/income-poverty/income.html.</p></fn>
<fn id="fn0002"><p><sup>2</sup>The Loon project (formerly Google X goo, <xref ref-type="bibr" rid="B1">2016</xref>) aims at providing internet access to remote/rural areas via a collection of high-altitude balloons providing wireless networks with up to 4G LTE speeds.</p></fn>
<fn id="fn0003"><p><sup>3</sup>More specifically, Feng et al. (<xref ref-type="bibr" rid="B13">2016</xref>) was considering submodular monotonic functions as aggregates.</p></fn>
</fn-group>
<fn-group>
<fn fn-type="financial-disclosure"><p><bold>Funding.</bold> This research was supported by the NSF Grants III 1213038 and CNS 1646107.</p>
</fn>
</fn-group>
</back>
</article>