My Geocode

Guides

Build a store locator with reverse geocoding

· 3 min read · My Geocode · #reverse-geocoding#store-locator#retail

A store locator needs two things working together: a way to know where the customer is, and a list of store coordinates to compare against. Reverse geocoding covers the first part cleanly.

Turning coordinates into a readable location

Once you have the customer's coordinates, from a location they entered or from an IP lookup, reverse geocode them to show a readable place name back to the customer, confirming the search location before showing results.

GET /v1/reverse?lat=51.5074&lon=-0.1278
{
  "status": "ok",
  "formatted": "Trafalgar Square, London, UK",
  "lat": 51.5074,
  "lon": -0.1278,
  "type": "address",
  "precision": "street",
  "confidence": 0.9,
  "place_id": "lm345",
  "components": {"city": "London", "country": "GB"}
}

Finding the nearest stores

The API returns coordinates, not distances between two arbitrary points, so once you have the customer's latitude and longitude, calculate distance to each store in your own list using standard great-circle distance math on the two coordinate pairs. Sort your store list by that calculated distance and show the closest few.

Letting customers type an address instead

Not every visitor will share their location. For a typed address search, geocode the entered text with /v1/forward first to get coordinates, then run the same nearest-store distance calculation against that result. If you want suggestions to appear as the customer types rather than waiting for a full address, /v1/autocomplete can back a type-ahead field that feeds a place_id or resolved text into the same forward geocoding step.

A second example: a mobile app using device GPS

A native app can skip the reverse geocoding step for finding nearby stores, since it already has raw device coordinates to compare against your store list directly. Reverse geocoding still earns its place there for the confirmation text shown to the customer, something like "Showing stores near Trafalgar Square, London" rather than a bare pair of numbers, which reassures the customer that the app understood their location correctly before they scroll through results.

A common mistake to avoid

Do not assume every typed address geocodes to house-level precision before running the distance calculation. A broad query like just a city name will still return a result, but at a coarser precision, and treating that coarse point as if it pinpointed the customer's exact building will make your "nearest store" ranking less reliable than the confidence and precision fields would have told you to expect.

Handling a tie between two nearby stores

When two stores come back at nearly identical calculated distances, distance alone will not tell the customer which one actually suits them better. Showing both, along with details like opening hours or stock availability, gives the customer the deciding factor rather than an arbitrary sort order.

Confirming the match

Show the formatted address from the reverse geocoding result alongside the store results, so the customer can immediately see whether the location that was detected or resolved matches where they actually meant to search from, and can correct it if not.

What it costs

Each search is one reverse or forward geocoding request, regardless of how many stores you compare it against afterward, since the distance calculation itself happens in your own code once you have coordinates for both sides. A store locator getting a moderate amount of daily traffic fits easily within the 2,500 free requests a day included with every key.

A store locator built this way needs exactly one geocoding request per customer search, with everything after that handled locally against your own store list. Full response fields are on the reverse geocoding docs.

More in Guides