The method compares a point to a rectangle and returns true if the point falls inside the rectangle.

The method takes a point as input and a rectangle as a parameter:

point(point_x, point_y [, filterindex:configexpression]).inside(rectangle(rect_x, rect_y, width, height))

For the point, please provide the point_x and point_y expressions that return the (x, y)-coordinates of the point. The filterindex named parameter is for use with filter indexes as described below. The left-hand side point can be subject to point-region quadtree indexing (MX-CIF quadtrees do not apply).

For the rectangle, the rect_x expression and rect_y expressions return the (x, y)-coordinates of the rectangle and the width expression and height expressions return the width and height of the rectangle.

All expressions must return a number-type and the implementation compares the double-values returned by the expressions.

A point is considered inside the rectangle if (point_x >= rect_x) and (point_x < rect_x + width) and (point_y >= rect_y) and (point_y < rect_y + height).

point(10, 20).inside(rectangle(0, 0, 50, 50))

point(10, 20).inside(rectangle(20, 20, 50, 50))

point(10, 20).inside(rectangle(9, 19, 1, 1))

point(10, 20).inside(rectangle(9, 19, 1.0001, 1.0001))

The method compares a rectangle to a rectangle and returns true if the rectangles intersect.

The method takes a rectangle as input and a rectangle as a parameter:

rectangle(rect_x, rect_y, rect_width, rect_height [, filterindex:configexpression]).intersects(rectangle(other_x, other_y, other_width, other_height))

The left-hand side is the rectangle's rect_x, rects_y, rect_width and rect_height expressions that return the (x, y)-coordinates and the size of the rectangle. The filterindex named parameter is for use with filter indexes as described below. The left-hand side rectangle can be subject to MX-CIF quadtree indexing (point-region quadtrees do not apply).

For the compared-to rectangle on the right-hand side, the other_x, other_y, other_width and other_height expressions return the (x, y)-coordinates and size of the compared-to rectangle.

All expressions must return a number-type and the implementation compares the double-values returned by the expressions.

A rectangle is considered to intersect another rectangle if:

rectangle(10, 20, 5, 5).intersects(rectangle(0, 0, 50, 50))

rectangle(10, 20, 5, 5).intersects(rectangle(20, 20, 50, 50))

rectangle(10, 20, 5, 5).intersects(rectangle(9, 19, 1, 1))

rectangle(10, 20, 5, 5).intersects(rectangle(9, 19, 0.999, 0.999))

rectangle(10, 20, 5, 5).intersects(rectangle(15, 25, 1, 1))

rectangle(10, 20, 5, 5).intersects(rectangle(15.001, 25.001, 1, 1))

A quadtree is a tree data structure in which each branch node has exactly four children. Quadtrees are often used to partition a two-dimensional space by recursively subdividing it into four quadrants or regions (source:WikiPedia).

Quadtree indexes can be used for:

The point-region quadtree is a quadtree for the efficient finding of points that fall inside a given rectangle. Use this index with the point-inside-rectangle method described above.

The MX-CIF quadtree is a quadtree for the efficient finding of rectangles that intersect with a given rectangle. Use this index with the rectangle-intersects-rectangle method described above.

While point-region quadtree and MX-CIF quadtree are similar, they are not compatible and are not the same. In point-region quadtree, only leaf nodes have data. In MX-CIF quadtrees both branch and leaf nodes have data as branches hold rectangles that don't fit any given quadrant. The engine expands and shrinks both types of trees dynamically based on data by promoting or subdividing a leaf node to branch nodes when adding data and by demoting or merging branches to a leaf node when removing data.

Declaring a point-region quadtree index is the same for both filter indexes and event indexes. Point-region quadtrees are suitable for efficiently finding points inside a rectangle, when there are many points.

The synopsis to declare a point-region quadtree index, as part of an EPL statement, is:

pointregionquadtree(min_x_expression, min_y_expression, 
  width, height [, leaf_capacity_expression [, max_tree_height_expression]])

The min_x_expression, min_y_expression, width, height are index parameter expressions that return the range of the index. The width and height must be greater zero. The index range rectangle is represented by double-type values internally. A point is inside the index range if x >= minX and y >= minY and x < minX+width and y < minY+height.

The leaf_capacity_expression is optional and must return a positive integer. It defines the number of coordinates a node may contain before it gets split into regions. The default value is 4.

The max_tree_height_expression is optional and must return an integer value of 2 or more. It defines the maximum depth of the tree. Upon the tree reaching the maximum depth a leaf node does not get split into regions. The default value is 20.

The section that summarizes filter indexes is Section 3.9.2, “Filter Indexes”. As there could be many point(...).inside(rectangle) filters active, having a filter index allows the engine to efficiently match incoming events to EPL statements.

For use of a point-region quadtree index within filter criteria you must:

For defining a local or global expression, please consult Section 5.2.9, “Expression Declaration”.

This sample EPL query defines the point-region quadtree filter index to have a bounding box of (0,0,100,100):

expression myPointRegionQuadtreeSettings { pointregionquadtree(0, 0, 100, 100) } 
select * from RectangleEvent(point(0, 0, filterindex:myPointRegionQuadtreeSettings).inside(rectangle(x, y, width, height)))

The filterindex named parameter instructs the engine that the settings for the point-region quadtree filter index are provided by the expression myPointRegionQuadtreeSettings, a local expression in this example. For sharing point-region quadtree settings across statements you may use a global expression instead. Please see Section 5.18, “Declaring Global Expressions, Aliases And Scripts: Create Expression”.

If your EPL does not specify filterindex the engine does not build a point-region quadtree filter index.

If your EPL specifies filterindex the engine always builds and uses a point-region quadtree filter index. In the case the engine analyses filter criteria and determines that it cannot use the point-region quadtree filter index, the engine fails statement validation.

If your EPL specifies filterindex and the engine determines that it cannot use the point-region quadtree filter index it fails statement validation.

The engine shares point-region quadtree filter indexes across the engine within the same event type given that:

For use with the filterindex named parameter, the following requirements apply towards point expressions:

For use with the filterindex named parameter, the following requirements apply towards rectangle expressions:

The section that summarizes event indexes is Section 3.9.3, “Event Indexes”. The create index clause is described in Section 6.9, “Explicitly Indexing Named Windows and Tables”.

Declare a point-region quadtree event index as follows:

create index ... on ... (
  (x_expression, y_expression) pointregionquadtree(pointregion_quadtree_configuration)
)

The x_expression and y_expression expressions form the index columns. The expressions return the (x, y)-coordinates and must return numeric values. Coordinates are represented as double-type values internally. See above for the pointregion_quadtree_configuration point-region quadtree configuration.

For example, assume we have a table that contains points:

create table PointTable(pointId string primary key, px double, py double)

This example EPL declares an index on the points, with px and py becoming index columns that determine (x, y)-coordinates:

create index PointIndex on PointTable((px, py) pointregionquadtree(0, 0, 100, 100))

The above sample quadtree index expects (x, y)-coordinates that are in the range 0 <= px <= 100 and 0 <= py <= 100.

The example schema for events providing rectangles is:

create schema RectangleEvent(rx double, ry double, w double, h double)

This EPL outputs, upon arrival of a RectangleEvent, all points that fall inside the rectangle:

on RectangleEvent
select pointId from PointTable
where point(px, py).inside(rectangle(rx, ry, w, h))

Internally the engine does not instantiate point or rectangle objects at all but instead optimizes the expression to comparison between double-type values.

context FramedCtx create index PointIndex on PointTable((Math.round(px/100), Math.round(py/100)) pointregionquadtree(context.frame.startx, context.frame.starty, context.frame.w, context.frame.h))

Declaring a MX-CIF quadtree index is the same for both filter indexes and event indexes. MX-CIF quadtrees are suitable for efficiently finding rectangles that intersect with a rectangle, when there are many rectangles.

The synopsis to declare a MX-CIF quadtree index, as part of an EPL statement, is:

mxcifquadtree(min_x_expression, min_y_expression, 
  width, height [, leaf_capacity_expression [, max_tree_height_expression]])

The min_x_expression, min_y_expression, width, height are index parameter expressions that return the range of the index. The width and height must be greater zero. The index range rectangle is represented by double-type values internally. A given rectangle must intersect with the index range.

The leaf_capacity_expression is optional and must return a positive integer. It defines the number of coordinates a node may contain before it gets split into regions. The default value is 4.

The max_tree_height_expression is optional and must return an integer value of 2 or more. It defines the maximum depth of the tree. Upon the tree reaching the maximum depth a leaf node does not get split into regions. The default value is 20.

The section that summarizes filter indexes is Section 3.9.2, “Filter Indexes”. As there could be many rectangle(...).intersects(rectangle) filters active, having a filter index allows the engine to efficiently match incoming events to EPL statements.

For use of a MX-CIF quadtree index within filter criteria you must:

For defining a local or global expression, please consult Section 5.2.9, “Expression Declaration”.

This sample EPL query defines the MX-CIF quadtree filter index to have a bounding box of (0,0,100,100):

expression myMXCIFQuadtreeSettings { mxcifquadtree(0, 0, 100, 100) } 
select * from RectangleEvent(rectangle(10, 20, 5, 5, filterindex:myMXCIFQuadtreeSettings).intersects(rectangle(x, y, width, height)))

The filterindex named parameter instructs the engine that the settings for the MX-CIF quadtree filter index are provided by the expression myMXCIFQuadtreeSettings, a local expression in this example. For sharing MX-CIF quadtree settings across statements you may use a global expression instead. Please see Section 5.18, “Declaring Global Expressions, Aliases And Scripts: Create Expression”.

If your EPL does not specify filterindex the engine does not build a MX-CIF quadtree filter index.

If your EPL specifies filterindex the engine always builds and uses a MX-CIF quadtree filter index. In the case the engine analyses filter criteria and determines that it cannot use the MX-CIF quadtree filter index, the engine fails statement validation.

If your EPL specifies filterindex and the engine determines that it cannot use the MX-CIF quadtree filter index it fails statement validation.

The engine shares MX-CIF quadtree filter indexes across the engine within the same event type given that:

For use with the filterindex named parameter, the following requirements apply towards left-hand side rectangle expressions:

For use with the filterindex named parameter, the following requirements apply towards right-hand side rectangle expressions:

The section that summarizes event indexes is Section 3.9.3, “Event Indexes”. The create index clause is described in Section 6.9, “Explicitly Indexing Named Windows and Tables”.

Declare a MX-CIF quadtree event index as follows:

create index ... on ... (
  (x_expression, y_expression, width_expression, height_expression) mxcifquadtree(mxcif_quadtree_configuration)
)

The x_expression, y_expression, width_expression and height_expression expressions form the index columns. The expressions return the (x, y)-coordinates and rectangle size and must return numeric values. Coordinates and sizes are represented as double-type values internally. See above for the mxcif_quadtree_configuration MX-CIF quadtree configuration.

For example, assume we have a table that contains rectangles:

create table RectangleTable(rectangleId string primary key, rx double, ry double, rwidth double, rheight double)

This example EPL declares an index on the rectangles, with rx, ry, rwidth and rheight becoming index columns that determine the (x, y)-coordinates and the sizes:

create index RectangleIndex on RectangleTable((rx, ry, rwidth, rheight) mxcifquadtree(0, 0, 100, 100))

The above sample quadtree index expects rectangles to intersect the rectangle (0, 0, 100, 100).

The example schema for arriving events is:

create schema OtherRectangleEvent(otherX double, otherY double, otherWidth double, otherHeight double)

This EPL outputs, upon arrival of a OtherRectangleEvent, all rectangles stored in the table that intersect the arriving-events rectangle:

on OtherRectangleEvent
select rectangleId from RectangleTable
where rectangle(rx, ry, rwidth, rheight).intersects(rectangle(otherX, otherY, otherWidth, otherHeight))

Internally the engine does not instantiate rectangle objects at all but instead optimizes the expression to comparison between double-type values.

context FramedCtx create index RectangleIndex on RectangleTable((Math.round(rx/100), Math.round(ry/100), Math.round(rwidth/100), Math.round(rheight/100)) mxcifquadtree(context.frame.startx, context.frame.starty, context.frame.w, context.frame.h))