We just launched geocoding autocomplete, delivering a dramatically better geocoding experience. You’ve probably seen autocomplete before when searching a map: as you type in a city name, like Washington DC, the search returns possible matches, saving you the trouble of writing your entire query. That’s autocomplete.
This is possible thanks to several upgrades to our geocoder:
Autocomplete support in our data structures
A proximity option (aka “helicopter mode”) that prioritizes results in the area being viewed
And lots and lots of tests.
To judge how good our geocoder is at autocomplete – and how it stacks up against the competition – we test. And test again. And then write more tests.
To evaluate autocomplete performance, a portion of an input query is sent multiple times, adding one more character with each iteration, until the expected result is at the top of the returned suggestions. The fewer iterations a given query requires, the better the result. Here’s a sample of how a test run looks:
Lubbock United States (3 chars)
North Adams United States (8 chars)
Poway United States (4 chars)
Santa Ana United States (7 chars)
Toledo United States (8 chars)
6.4 avg chars to match
4.7 avg chars to first relevant suggestion
In this example, it only takes 3 characters Lub to get to Lubbock USA. Queries that match more results like Toledo require more context (the = means the result is one of the suggestions but not the top result).
Autocomplete suggestions can be made more accurately when proximity bias is enabled. There are a lot of 1308 W Main’s in the world. Without more context there’s really no way to guess the right result at 10 characters.
Testing without location bias
# 1308 W Main St Yadkinville (17 chars)
Without location bias, it takes an average of 45% more characters to deliver the correct suggestion. Using proximity signals can deliver a big improvement to users’ experience.