> For the complete documentation index, see [llms.txt](https://developers.felt.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developers.felt.com/felt-style-language/style-definition-blocks/the-filters-block.md).

# The filters block

The filters block contains information on how the layer is being filtered before displaying. In order for a feature to be shown on the map it must evaluate the filter expression to `true`.

Filters are written using a JSON infix notation that looks like one of `[identifier, operator, operand]`, `true` or `false` .

* Valid identifiers are either a feature property or a nested expression.
* Valid operators are:
  * `"lt"` – Less than
  * `"gt"` – Greater than
  * `"le"` – Less than or equal to
  * `"ge"` – Greater than or equal to
  * `"eq"` – Equal to
  * `"ne"` – Not equal to
  * `"and"` – And, cast to boolean
  * `"or"` – Or, cast to boolean
  * `"cn"` – Contains the operand, cast to string
  * `"nc"` – Does not contain the operand, cast to string
  * `"in"` – Contained in the operand list
  * `"ni"` – Not contained in the operand list
  * `"is"` – Used to match against null values
  * `"isnt"` – Used to match against null values
* Operands are:
  * A numerical value, a string value, a boolean value
  * An array of numerical, string, or boolean values, a shorthand expanded to these patterns:
    * Input 1: `[id, "in", [element1, …, elementN]]`
    * Expansion 1: `id` is equal (`"eq"`) to one or more of the elements
    * Input 2: `[id, "ni", [element1, …, elementN]]`
    * Expansion 2: `id` is not equal (`"ne"`) to any of the elements
    * Not defined for operators other than `"in"` and `"ni"`
  * A nested expression
* In cases of type mismatch cast the identifier value to the operand’s type
  * Type casting applies element-wise to lists with `"in"` and `"ni"` operators

{% code title="Example of a filter block that filters out features with a value less than 50000 on the acres property" %}

```json
"filters": ["acres", "lt", 50000]
```

{% endcode %}

{% code title="Example of a more complex filter block" %}

```json
"filters": [["acres", "ge", 50000], "and", ["acres", "le", 70000]]
```

{% endcode %}

## Behavior notes

* **Case & diacritics:** `eq`, `ne`, `gt`, `ge`, `lt`, `le`, `cn`, and `nc` compare strings case-insensitively and diacritic-insensitively. `["status", "eq", "active"]` matches `"Active"` and `"ACTIVE"`.
* **`in` / `ni` are case-sensitive**, unlike the operators above, and do per-element type coercion (`["id", "in", [5]]` matches a string `"5"`). `in` with an empty array always returns false; `ni` with an empty array always returns true.
* **Null handling:** use `is` / `isnt` only for null/existence checks (with `null` as the value) — not for value equality. Most other operators yield null (and filter the feature out) when the column is missing or null.
* **Type coercion:** the left-hand value is cast to match the right-hand type, so `["score", "eq", 100]` matches whether the column stores `100` or `"100"`.

## Common patterns

There is no single "between" operator — combine two comparisons:

```json
"filters": [["temperature", "ge", 0], "and", ["temperature", "le", 100]]
```

Check that a value exists and is non-empty:

```json
"filters": [["name", "isnt", null], "and", ["name", "ne", ""]]
```

**Three or more conditions must be written as nested pairs, not a flat list:**

```jsonc
// WRONG: [a, "and", b, "and", c]
// RIGHT:
"filters": [["a", "eq", 1], "and", [["b", "eq", 2], "or", ["c", "eq", 3]]]
```


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://developers.felt.com/felt-style-language/style-definition-blocks/the-filters-block.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.