Place search by text query vs coordinates

Sometimes the user typed “ramen in brooklyn.” Sometimes you already have a point and want coffee nearby. google-maps.fetcher.sh search supports both: a text query, or a query pinned to latitude and longitude.

This is not Google Cloud geocoding, not an address-to-latlng SKU, not routing, not “find my closest store” as a Google product. Yelp’s location parameter is a city string on another host — different shape. Mixing them is how you get a 400 and a wasted hour.

The host’s featured examples are exactly the two shapes: query=ramen in brooklyn, and query=coffee with latitude=40.7128 and longitude=-74.0060. Everything else in local search is a consequence of picking the right one.

Maps access covers Places API as the thing we are not. This note only picks the search mode. Reviews still want a fid after you have a hit.

Text or a point

Use text when the user typed a place, a cuisine plus a neighborhood, or a business name. Use coordinates when you already have a point from a phone, a store, or a previous geocode you trust.

curl -H 'Authorization: Bearer bby_live_…' 'https://google-maps.fetcher.sh/api/place/search?query=coffee&latitude=40.7128&longitude=-74.0060'

query=ramen+in+brooklyn is one GET. A query pinned to latitude and longitude is the other. Do not send lat/lng to Yelp’s location field, and do not send Yelp’s city string as Maps coordinates.

Optional zoom and offset exist on Maps search if you are paging or tightening the map. They are not a substitute for knowing whether your input was a sentence or a pin. languageCode and countryCode change the listing language, not the search mode.

If you only have a postal address and you needed lat/lng, that conversion is geocoding, which this host does not sell. Get a point somewhere else you already trust (the user’s device is the honest source), then pin.

Why the two modes feel different

A text query is only as good as the string. “Coffee” without a where will not do what you want. “Coffee in brooklyn” is a where inside the string. A pin plus query=coffee is a where outside the string. Pick one where. Do not stack a neighborhood name and a pin from a different borough and then argue with the results.

Editors and researchers almost always want text: they are thinking in cities and cuisines. Field apps, “near me” buttons, and delivery-adjacent tools almost always want a pin: they already know where the phone is. Concierge desks sit in the middle — they have a hotel coordinate and a neighborhood name. Prefer the pin for “near the hotel,” text for “in Williamsburg even though we are in Midtown.”

Yelp remains query + location as strings. There is no lat/lng on that search. If your app is pin-native, Maps is the search you want first; Yelp is the second corpus once you have a place, not the first search.

A case: a pin from the phone, not a neighborhood name

A field app already knows the user is at 40.7128, -74.0060. Asking them to type “Tribeca” is worse than pinning coffee to that point.

The search is query=coffee plus latitude and longitude. They pick a fid, then reviews. They do not reverse-geocode into a neighborhood string just to paste it into the query. They do not call Yelp with those numbers in location.

If the user then types “ramen” as a refinement, keep the pin and change the query. If the user types “ramen in queens,” drop the pin or you are mixing two wheres.

A case: an editor who only has a neighborhood

The opposite mistake. An editor in another country writes “coffee” and pastes the office coordinates from an old email, which turn out to be a coworking space in a different borough than the piece.

Results look local to the pin, not to the neighborhood in the headline. They switch to query=coffee in brooklyn with no coordinates, and the shortlist matches the article. Pins are precise. Precision is only a virtue when the point is the point you meant.

Zoom is not a substitute for a better where. Tight zoom around the wrong pin is a confident wrong shortlist. Offset pages the list; it does not change the mode. If results look like a different city, you probably left a pin in the request from a previous screen. Clear it.

Yelp still wants San Francisco, not a pair of floats. A product that has a map pin and a Yelp second opinion should search Maps by pin, pick a place, then resolve Yelp separately by name plus city — two searches, two ids. One mashed parameter list will 400.

Not geocoding, not routing

We do not turn an address into a lat/lng SKU. We do not give driving directions. We do not snap to roads. Place search, two input shapes, JSON out.

Docs on google-maps.fetcher.sh. Pay the GET or send a key. If you needed official Geocoding API, that is Cloud, and it is a different bill.