Good Enough Maps Places API vs geocoding API: which one do you need?
A geocoding API answers “where is this address?” A Places API answers “what places match this query?”
Those sound similar until you build a product. Then the difference matters fast.
What geocoding does
Forward geocoding turns text into coordinates: “1600 Pennsylvania Avenue NW” becomes a latitude and longitude. Reverse geocoding does the opposite: a coordinate becomes a human-readable address or area.
Mapbox describes the same distinction in its Geocoding API docs, and Nominatim describes itself as OpenStreetMap-based geocoding for finding locations by name or address (Nominatim).
Use geocoding when the user gives you:
- a street address
- a postal code
- a city or region
- a coordinate that needs a human-readable address
The output is usually one or more candidate locations.
What place search does
Place search returns real-world places: businesses, venues, landmarks, services, and other POIs. Google’s Text Search docs describe queries like “pizza in New York” or “shoe stores near Ottawa” returning a list of matching places. This is the nearby search API job when the product already knows the user’s location.
Use place search when the user asks:
- coffee near this hotel
- pharmacies within 10 miles
- ramen near Tokyo Station
- approved vendors near this job site
The output is a list of places with names, coordinates, categories, addresses, and sometimes richer fields depending on the provider.
Most location products need a chain
A common flow is:
- User types a city, ZIP code, or address.
- Geocoder turns it into a coordinate.
- Places API searches near that coordinate.
- Your UI renders the resulting places.
Good Enough Maps handles step 3. It deliberately does not handle step 2. That makes the API smaller and easier to reason about, but it means you need a geocoder when the user starts with address text.
Wrong API, bad product
If you use a geocoder as a POI search engine, you usually get awkward results. Geocoders are optimized for resolving locations, not ranking nearby businesses.
If you use a Places API as a geocoder, you can overpay or return ambiguous business matches when the user wanted an address.
The decision rule:
| User input | API first |
|---|---|
| ”123 Main Street” | Geocoding |
| ”10001” | Geocoding |
| ”coffee near me” | Places search |
| ”hardware stores within 20 miles” | Places search |
| ”restaurants near this lat/lon” | Places search |
Where Good Enough Maps fits
Good Enough Maps is a Places API for server-side proximity search. Every request needs q, lat, and lon. You can add radius_mi, limit, and layer controls, but you cannot ask it to geocode a street address.
That boundary is useful. Pair any geocoder you like with Good Enough Maps, then keep the place-search bill flat and capped.
FAQ
What is the difference between a Places API and a geocoding API?
A geocoding API converts addresses or place text into coordinates. A Places API searches real-world places and returns place records, usually near a coordinate.
Does Good Enough Maps geocode addresses?
No. Good Enough Maps requires latitude and longitude. Use a geocoder first when the user starts with an address or postal code.
Can I use both APIs together?
Yes. That is often the cleanest architecture: geocode once to get a coordinate, then search places near that coordinate.
Last validated 2026-06-23.