Find the Place, Even When the Spelling Is Wrong
A traveler types Zlotaa 59 while looking for a destination in Warsaw. They mean Złota 59. Your app should help them get there—not ask them to become better at spelling Polish street names.
GLSearch now handles common typos in online map search. It helps people find addresses, businesses, and places even when they miss a letter, add an extra one, or mix up the spelling. The goal is simple: less retyping between opening your app and choosing a destination.
Built for the way people search on a phone
People search while walking, planning a trip, or switching between messages and maps. They copy unfamiliar addresses, use keyboards without local accents, and remember only part of a place name.
With the map centered on Warsaw, Zlotaa 59 can return Złote Tarasy at Złota 59. The street-name typo does not erase the house number. A search for Marszalkowsk can find Marszałkowska, without requiring the user to type ł or remember the last letter.
These are different kinds of help working together:
| What the user needs | What GLSearch offers |
|---|---|
| Find an address despite a small typo | Spelling corrections that keep the other address details in the search |
| Search a foreign city with their usual keyboard | Accent-insensitive matching, such as cafe and café, alongside typo tolerance |
| Recognize a destination before finishing the query | Autocomplete with corrections for complete misspelled words |
| Find a nearby business rather than a similar name far away | Location-aware results guided by the search center and, optionally, the visible map area |
Accent-insensitive matching was already part of GLSearch. Typo tolerance extends that experience to more of the everyday mistakes people make.
A useful destination, not just a similar word
A spelling correction is only helpful if it leads to the right place. An unfamiliar local name should not be replaced just because a better-known name looks similar.
GLSearch protects strong matches to what the user actually typed. Corrections are a fallback when the ordinary results are weak, not an instruction to rewrite every query. The search center helps keep suggestions geographically relevant; GLMap 2.2 also lets your app supply the visible map area as additional context. If the query names a city, that city can guide the search instead.
Your category filters still apply. An app searching for cafés does not need to discard that constraint to benefit from spelling corrections.
Where this helps your product
- Travel and city guides: help visitors find streets and attractions whose names they have only heard or briefly seen.
- Navigation apps: make destination entry more forgiving without asking users to leave the search screen to check a spelling.
- Delivery and field-service apps: help users look up an address while retaining the house number and other details they entered. Search results still need to be confirmed by the user; this is not postal-address verification.
- Local discovery: combine business and category search with the area the user is exploring.
You can keep your existing results list, map markers, and route-selection flow. Corrected matches arrive as normal GLSearch results, ready for your app to display.
Add it without building a separate search experience
Fuzzy matching runs in the online search service and works with GLSearchRequest.startOnline. Your team does not need to maintain a spelling dictionary or add a separate correction service to the app.
Use a meaningful search center, such as the map center or the area the user is exploring. With GLMap 2.2, you can also pass visibleArea to give the service viewport context. It is a relevance hint, not a strict boundary on results.
Search can be used with the GLMap renderer or on its own—for example, in a destination picker that shows a list before opening a map. See the search integration guide and setup without a map view.
Online assistance, offline independence
Your app can still search downloaded maps when there is no connection. Offline mobile search does not include fuzzy matching; spelling corrections described here require the online service. The correction machinery stays on the server rather than adding dictionaries to the mobile SDK.
The feature is designed for common, small spelling mistakes—not arbitrary misspellings or several mistyped words in one query. Results depend on the available map data and geographic context. It complements ordinary search rather than guaranteeing a match for every input.
Try it with the places your users care about
Start with real destinations in your target region: a street with an extra letter, a business name typed from memory, or an address entered without local accents. Compare the suggestions with the destination your user intended to select.
Create an API key and follow the GLSearch guide to try it in your app. If you are evaluating search for a travel, navigation, or location-based product, talk to us about your regions and search scenarios.