Use Indexes

An index speeds up the identification of data within a Rule or Action.

Specify indexes in the Read and Commit mapping

In the Data Store Read and Commit mapping tab, every attribute within a class has a toggle to allow you to specify whether the attribute should be indexed or not. The primary geometry is always indexed.

     Note: For Oracle data any other columns with Oracle indexes on them (including primary keys) will be set to be indexed by default.

A datastore input showing attributes, each having the index (Idx in the interface)
Defining indexes in the Read and Commit Mapping of a Data Store

If you are using an Attribute to identify features in a Rule or Action, it will need to be indexed.

Identifying features means anywhere that you need to specify a class of objects other than in the Rule or Action’s root node (e.g. using a For All, Existence, Aggregate, Chaining or Loop Over Objects construct within a rule or action).

Indexed Values in Rules

The following example rule is checking that the ID of Road_Section and the ID for Road objects match. As we are using the Road ID value to identify the objects, this is the value that should be indexed.

A datastore input showing attributes, each having the index (Idx in the interface)
A Rule requiring an indexed value

     Note: If you are doing a spatial search (i.e. a comparison on the geometry) to identify nearby features before subsequently checking an ID, then the index on the ID is not required. You will only need it when the attribute is used as the initial way to select the set of objects.

A datastore input showing attributes, each having the index (Idx in the interface)
Index not required on Building because a small set of objects already identified using another value (in this case a spatial search on the geometry)

     Note: Indexing attributes uses disk space in the cache, which increases the time it takes to run Open Data Tasks in a Session.

Use the unmodified value when comparing indexed data

When utilising indexed values, make sure that the first instance utilises the unmodified value before any changes are made to it.

For the index to work effectively the first comparison needs to run on the raw attribute value itself because this has been indexed, not the result of a Built-in function.

Example

The first Action displayed below will be very slow, because the spatial index to is not being used to identify the Admin Area objects. By running the outer_ring Built-in function on each geometry first every object in the class is tested explicitly, rather than using the Index on the geometry to reduce the set and speed up processi

A datastore input showing attributes, each having the index (Idx in the interface)
Slow use of outer_ring function

Instead, you can add a new initial Check That which uses the unmodified value as the first condition, then utilise an AND condition to pair it together with the outer_ring Built-in.

This requires ordering the Predicates efficiently, filtering down the data by having Predicates above the one containing built-ins. See Order Conditions Efficiently for more insight into narrowing down features through Predicate order.

In the example below, the Intersects condition will find all areas that are spatially in contact with the line in some way. From this limited subset, we next get the outer ring of each one and do the comparison.

 

A datastore input showing attributes, each having the index (Idx in the interface)
Faster use of outer_ring function