# Place search by text query vs coordinates 2026-08-22 > google-maps.fetcher.sh searches by text or by latitude and longitude. Two methods, not Cloud geocoding. - Index: https://fetcher.sh/blog.md - This page (HTML): https://fetcher.sh/blog/place-search-text-query-vs-coordinates ![A city skyline photographed from above](https://images.unsplash.com/photo-1477959858617-67f85cf4f1df?auto=format&fit=crop&w=1600&q=80) Photo by Pedro Lastra on [Unsplash](https://unsplash.com/?utm_source=fetcher_sh&utm_medium=referral). Sometimes the user typed “ramen in brooklyn.” Sometimes you already have a point and want coffee nearby. [google-maps.fetcher.sh](https://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](/blog/google-maps-places-reviews-without-places-api-key) 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](https://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.