GIS Tools - Full-Text Search

What Is Full-Text Attribute Search?

Full-text attribute search is the ability to type a search query into a single input field and instantly find features whose attribute values contain the matching text — across all string fields at once. It is the spatial equivalent of Ctrl-F in a document, and it shortcuts the entire build-an-attribute-filter workflow when you just want to find a feature by its name, ID, or any descriptive text.

Unlike a structured filter expression that requires you to pick a field, choose an operator, and enter a value, full-text search inverts the workflow: type the value, see the matches. The search engine indexes every string field across the dataset and matches your query against any of them. Type "oak street" and you find every feature where the name contains those words, regardless of which field stores it.

The gis.tools full-text search runs entirely in the browser using a lightweight inverted index built lazily on first search. The index uses tokenization (split on whitespace and punctuation), case folding, and optional fuzzy matching so that "oak" matches "Oak", "OAK", and even "oka" with a typo. The search bar provides instant autocomplete as you type, with results highlighted on the map.

Full-text search is the killer feature for casual users who do not want to learn SQL or build filter expressions. It collapses the time-to-first-result from minutes to seconds and lowers the barrier to spatial data exploration.

How Full-Text Search Works

Inverted index construction

When you load a dataset, the search engine walks every feature and every string field, tokenizing the values into words and storing a mapping from each word to the set of feature IDs that contain it. This is the same data structure used by Elasticsearch, Lucene, and Solr, but built in JavaScript and small enough to live in browser memory.

For a 100,000-feature dataset with average 5 string fields and 10 words per field, the index holds about 5 million word-to-feature pairs. Compressed in memory, this is typically under 50MB.

Tokenization and normalization

The tokenizer splits values on whitespace and punctuation, converts to lowercase, and optionally strips diacritics so that "café" matches "cafe". Some implementations also stem (so "running" matches "run") but this is usually skipped for GIS data because place names are not natural language.

Query matching

When you type a query, the engine tokenizes it the same way and looks up each token in the inverted index. It returns the intersection (AND-mode) or union (OR-mode) of the matching feature ID sets. Phrase matching uses positional information to enforce word order.

Fuzzy matching

Optional fuzzy matching uses Levenshtein distance to allow up to N character differences between query and indexed value. This catches typos like "oka" → "oak" or "strret" → "street".

Key Parameters and Options

Field scope

By default, search runs across all string fields. You can restrict to specific fields if you want to search only addresses or only descriptions.

Match mode

AND-mode requires every query token to match (default). OR-mode matches any token. Phrase mode requires consecutive matches in order.

Fuzzy distance

Set the maximum edit distance for fuzzy matching. Distance 1 catches single-character typos; distance 2 is more permissive but slower.

Result limit

Cap the number of returned results to keep the UI responsive. Typical default is 100 with a "show more" option.

Practical Applications

Address lookup

A city resident loads a GeoJSON of their neighborhood and types their street address into the search bar to find their parcel. The search matches across address, owner name, and parcel ID fields all at once. Within milliseconds, the matching parcel highlights on the map.

Place name discovery

A tourist plans a hike using a national park trail dataset. They type "hidden lake" into the search bar and the engine returns three matching trails — one to Hidden Lake, one to Hidden Lake Overlook, and one to the Hidden Lake spur. They click each in turn to see the elevation and distance.

Asset lookup

A utility worker types an asset tag ("TX-4471") into the search bar to instantly find the corresponding transformer on a citywide grid map.

Permit search

A building inspector types an applicant name to find all permits associated with that contractor across the city.

Wildlife sighting search

A biologist types a species name ("red-tailed hawk") into the search bar of a survey dataset and sees every observation pinned on the map.

Bibliography lookup

A historian working with a dataset of historical photo locations types a photographer's name to find every photo they took.

Customer lookup

A delivery dispatcher types a customer phone number to find their address on the route map.

Step-by-Step Workflow

Load your dataset into the GeoJSON, KML, Shapefile & GIS File Viewer.
Click the search bar in the toolbar.
Type your query — autocomplete suggestions appear after the third character.
Select a result to zoom to that feature on the map.
Or hit Enter to highlight all matches and see them in a list.
Refine your query if there are too many or too few matches.
Optionally convert the result set to a selection for export with Multi-Select & Export.

Common Pitfalls and Gotchas

Numeric fields not searchable. The full-text index covers strings only. Use the Attribute Filter Builder for numeric fields.
Case sensitivity. Default is case-insensitive, but some implementations are case-sensitive. Confirm in the search settings.
Diacritic handling. Without diacritic stripping, "cafe" will not match "café".
Index build delay. First search after loading triggers the index build, which adds a brief lag.
Memory pressure. Very large datasets can consume hundreds of MB of index memory.
Tokenization quirks. Hyphens, apostrophes, and underscores are split inconsistently across implementations.
Stop words. Some indexers strip common words like "the", "and", "of" — useful for natural language but bad for place names.
Substring matching. "oak" matches "oak" but not "oakland" unless you use fuzzy or wildcard mode.

Tips for Best Results

Use the most specific query first; broaden if there are no results.
Combine full-text search with spatial filters to narrow by area before searching.
For very large datasets, restrict the search to the most relevant field.
Enable fuzzy matching when working with user-generated data prone to typos.
Use phrase mode for multi-word queries where word order matters.
Convert search results to a selection for export downstream.
Index only on data load; do not rebuild on every keystroke.

Comparison with Other GIS Search Approaches

QGIS includes a basic Locator Bar that searches feature attributes among other things. ArcGIS Pro has a built-in Locate widget. PostGIS supports full-text search via the tsvector/tsquery types. Elasticsearch and OpenSearch are full-blown search engines with spatial extensions.

The gis.tools approach is closer to a desktop locator bar in scope but runs entirely in the browser without a server. It is purpose-built for the common case of "I have a dataset, I want to find a feature by name," and it is significantly faster than building an attribute filter expression for that case.

Performance Considerations

Index build is the most expensive step, taking O(N × tokens-per-feature) time. For 100,000 features with ~50 tokens each, expect 1-2 seconds. After that, individual searches return in single-digit milliseconds. Memory usage scales with the number of unique tokens and the average length of each feature's text.

Data Privacy and Browser-Based Processing

The search index is built and queried entirely in your browser. Search queries never travel to a server. This is a critical property for legal, healthcare, and law enforcement workflows where attribute values may include personally identifiable information or sensitive case details.

Related GIS Concepts

Inverted index. A data structure mapping each token to the set of documents (or features) containing it. Foundation of all full-text search engines.

Tokenization. Splitting text into discrete units (words) for indexing.

Geocoding. Converting an address string to coordinates. Different problem from feature search but related.

Locator service. A search service that combines attribute search with geocoding.

Frequently Asked Questions

Can I search numeric fields?

No — full-text search is for string values. Use the Attribute Filter Builder for numbers.

How do I search for an exact phrase?

Wrap the phrase in quotes: "main street".

Does it match partial words?

Yes if you use fuzzy or wildcard mode. By default, it matches whole tokens.

Why is the first search slow?

The index is built lazily on first use. Subsequent searches are instant.

Is the search case-sensitive?

Default is case-insensitive.

Search Tips