Geocoding vs place search is the first split in a location query: one call resolves a geographic subject, and the other discovers candidate places. An address, a coordinate, or a place identifier belongs to geocoding. A request for businesses, landmarks, or other named places belongs to place search. A spatial query then tests geometry the application already holds, and vector search matches meaning without proving that a record is nearby or eligible.
What Does Each Location Query Answer?
Each method answers a different question, and a vendor menu that combines them in one product family does not erase the difference. Geocoding resolves identity. Place search discovers candidates in a provider or private index. A spatial query applies a geometric relationship to records the application already stores. Vector search retrieves records whose embeddings are close in meaning. A production decision often needs more than one of those answers, in an order the question itself sets.
| Query | The job | A typical input | A typical output |
|---|---|---|---|
| Geocoding | Resolve one location | A street address or a coordinate | A coordinate, a normalized address, or a stable identifier |
| Place search | Discover named places | Text, a category, and an area | A candidate set of places |
| Spatial query | Test geometry | Within a distance, inside a polygon, intersects, nearest | Records that satisfy the relationship |
| Vector search | Match meaning | A phrase such as a quiet place for a first meeting | Records with similar descriptions |
The four cards separate resolve, discover, filter geography, and match meaning. Each card pairs an input with an output: an address with a coordinate, a category with points of interest, a geometry relationship with matching records, and a concept with semantic neighbors. The street address, the coordinate, the café query, and the count of places inside the polygon are sample labels on the figure. Those labels are not a live query against a Kaleidr index.
The table is the selection rule. A team that starts from the endpoint name, rather than from the question, will ask a geocoder for a recommendation or a vector index for a containment test. Both mistakes produce a confident answer to a question the system never ran. The rest of this guide keeps the four jobs separate, then shows where a pipeline has to join them.
Which Query Fits the Question?
The opening words of the request usually name the method. "Where is this address?" starts with geocoding. "What places match this text or category?" starts with place search. "Which of our records satisfy this geographic relationship?" starts with a spatial query. "Which records mean something like this?" is the case for vector search, and only after the hard geographic and business limits are in place. A request that mixes those questions needs a hybrid, not a single winner.
| The question | Start here |
|---|---|
| Where is this address, or what address is at this coordinate? | Geocoding, including reverse geocoding |
| Which named places match this text, category, or nearby intent? | Place search |
| Which of our records fall inside this distance, polygon, or corridor? | Spatial query |
| Which descriptions are similar to this phrase? | Vector search, inside an eligible set |
| Which approved place has the item and adds little detour? | Business filters, then spatial or routing, then rank |
The tree opens with the question the caller is trying to answer, then branches to resolving one address, discovering businesses, filtering the caller's own records by geography, or finding records with similar meaning. A fifth band at the bottom combines the four methods when one query is not enough. The sample address, the café cards, the one-kilometer radius, and the quoted date-night phrase are figure labels. The check marks describe the job of each method, not a measured quality score.
A hybrid is the ordinary case for an AI map assistant, not an exception reserved for a later version. "Coffee near 20 W 34th St" still needs the address resolved before a nearby search can run. "A quiet café near the hotel, open after nine" adds a business filter and a semantic preference on top of that resolution. The pipeline sections below keep those steps in an order a reviewer can test.
What Does Geocoding Resolve?
Geocoding converts a textual location into a geographic representation, and reverse geocoding converts a coordinate or a place identifier back into a readable address. Google's Geocoding API overview defines the service as accepting an address, latitude and longitude, or a Place ID, and converting an address into coordinates and a Place ID, or converting coordinates or a Place ID into an address (Google, 2026). The same overview uses "1600 Amphitheatre Parkway, Mountain View, CA" as the forward-geocoding example and lists deliveries and pickups among the reverse-geocoding uses. The output of a successful call is a subject the map can place, not a ranked set of businesses.
The product boundary is moving, and the retrieval job is still the thing to name. Google's Geocoding API v4 overview lists forward geocoding, reverse geocoding, place geocoding, and a destination-search method that accepts an address, a Place ID, or coordinates (Google, 2026). That overview also separates generally available, preview, and experimental channels, and it tells callers to use the experimental channel for destination features that are not on the generally available path. A destination lookup can enrich a location the application has already resolved. A destination lookup does not become a place-discovery index, and an experimental channel is not a promise that every field is ready for a production contract.
Geocoding is the right tool when the application must plot an address, normalize one before storing it, center a map, reverse-geocode a device location, or resolve a delivery point before a later query. Geocoding does not choose the best nearby restaurant, read private inventory, test a private service-area polygon, or rank results by customer intent. Those jobs start only after a subject exists. Plot places on a map covers the address-to-marker step that follows a successful resolution.
How Does Geocoding vs Place Search Differ?
Place search discovers named geographic entities: restaurants, stores, stations, landmarks, and other points of interest. Mapbox draws the product line explicitly in the current Geocoding API. That API performs forward and reverse geocoding, and the Geocoding v6 API no longer provides point-of-interest data (Mapbox, 2026). Mapbox points point-of-interest search at the Search Box API, which supports interactive and stand-alone queries for addresses, places, and points of interest, including a category search (Mapbox, 2026). The endpoint family is one vendor's. The jobs remain two.
Google's current Places API makes the same split inside place search itself. Text Search (New) returns places for a text string, and the documented examples include "shoe stores near Ottawa" and "123 Main Street," so an address-shaped string can enter a place-search call (Google, 2026). Nearby Search (New) takes one or more place types and returns matching places inside a specified area (Google, 2026). Text Search can therefore look like geocoding when the string is an address, and Nearby Search can look like a spatial query when the area is a circle. The result is still a candidate set from that provider's index. Open state, inventory, authorization, and travel time remain later tests. The same Text Search page also says the service is not intended for ambiguous queries, including postal-address forms that are not represented as places.
The left panel asks where one address is and shows a single location identity. The address and coordinate on that panel match the sample in Kaleidr's forward-geocode reference, and the café names, distances, and star ratings on the right are sample labels rather than a live place-search response. The footer walks "coffee near 20 W 34th St" through geocoding the address and then searching for coffee. The right-hand takeaway calls the result a candidate set, which is the correct stopping point before eligibility and ranking.
| Geocoding | Place search | |
|---|---|---|
| Core job | Resolve one location | Discover candidate places |
| Common input | Address, coordinate, place identifier | Text, category, nearby area |
| Common output | One or several interpretations of that location | A ranked candidate list from an index |
| Next step | Map, spatial query, or route | Filter, enrich, rank, or route |
| Private inventory | No | No |
A robust application uses both when the anchor is an address and the target is a category. Geocode "20 W 34th St," then search for coffee near the resolved point, then calculate walking time and rank only the places that remain eligible. A nearby-places map is the discovery surface for that second step. The provider's order is a retrieval convenience. The product's order is a later decision.
What Does a Spatial Query Test?
A spatial query filters records the application already holds, using a relationship between geometries. Common relationships are within a distance, inside a polygon, intersects, contains, and nearest neighbor. The records and their geometry exist before the query. The query asks which of those records satisfy the relationship. A place-search API answers a different question, because the candidate set comes from the provider's index rather than from the caller's table.
The panels are within a distance, inside a polygon, a route that intersects a zone, and a nearest feature. The one-kilometer radius, the service-area outline, and the distance badge are sample geometry, not a measured service area. The nearest panel also marks one feature as excluded. That exclusion is a sample of a later eligibility check. The distance predicate by itself does not test whether a place is open.
PostGIS defines ST_DWithin as a test of whether two geometries are within a given distance, and the call includes a bounding-box comparison that uses any spatial indexes available on the geometries (PostGIS, 2026). For the geography type, the distance is in meters. A store table with a geography column can therefore keep "within five kilometers" as a predicate rather than as a sentence for a language model to interpret.
SELECT store_id, name
FROM stores
WHERE ST_DWithin(stores.geog, user_location, 5000);
Containment is the same class of predicate. ST_Within returns true when every point of the first geometry lies in the second and the interiors share a point, and the function likewise uses available spatial indexes (PostGIS, 2026). ST_Within(A, B) is the converse of ST_Contains(B, A). A delivery question of the form "does this address fall inside the service area?" is a geocode, then a containment test, then the operational rule. A vector index does not replace the polygon, and a public place search does not replace the service-area geometry the company drew.
The index note is an architecture constraint, not a tuning footnote. A distance expression that cannot use an index will compare far more rows than ST_DWithin on the same table. The practical rule for a location-aware assistant is to filter geographically before any model sees the set. If only a small share of a large catalog can satisfy the geometry, the language model should receive that share, plus the reason the others were dropped. Sending the rest spends context on records the predicate has already excluded.
What Does Vector Search Match?
Vector search retrieves records whose embeddings are near the query in a vector space. pgvector, the Postgres extension commonly used for that job, performs exact nearest-neighbor search by default and can add an HNSW or IVFFlat index for approximate search (pgvector, 2026). The same documentation lists L2 distance, inner product, cosine distance, and other measures. Exact search is the recall baseline. An approximate index trades some of that recall for speed, and queries can return different neighbors after the index exists. That property matters when a team compares a prototype, which used exact search, with a production query, which uses the index.
Vector search earns its cost when the words in the request are not the words in the record. A description that says "intimate wine bar with low lighting" can be a useful neighbor for "quiet place for a first meeting," even though the strings do not match. Place descriptions, amenity notes, and destination copy are the usual inputs, where the license allows the text to be embedded. A known brand, a store number, an airport code, or an explicit category is usually a better job for keyword or structured search. Embeddings add a system to operate, and they should be added when the semantic miss is real.
Vector similarity does not record geographic distance, route time, service-area containment, current inventory, opening hours, authorization, or whether the embedded text is still true. A close neighbor in embedding space can sit hundreds of miles from the caller. A place across the street can be a poor semantic match and still be the right operational answer. The two results are not in conflict. The two results come from different spaces, and the pipeline has to say which space is allowed to reject a candidate.
Why Are Geographic Distance and Vector Distance Different?
Both systems use the word distance, and the word hides a change of subject. Geographic distance is separation on the earth or along a path: a straight-line length, a walk, a drive, or a containment result. Vector distance is separation in an embedding space: cosine distance, Euclidean distance, or an inner-product score. A small vector distance does not place two venues near each other. A short walk does not make two descriptions mean the same thing.
The left panel measures physical separation and shows a sample walk between two labeled places. The kilometer and minute badges are sample labels, not a routed trip. The right panel places words in an embedding diagram and marks coffee as distant in meaning from train. That cosine callout is an illustration of the two spaces, not a measured embedding from a Kaleidr index. The center label is the point of the figure: the same word, distance, names both quantities.
The naming collision shows up in product copy. A screen that says "nearest" may mean nearest in the embedding index, nearest in straight-line meters, or fewest minutes of detour. Those three orders disagree often enough that the interface should name the quantity. A ranker can use more than one of them. A ranker should not add a cosine score to a kilometer value and treat the sum as a single distance.
How Should a Hybrid Pipeline Order the Work?
A production location search is usually a pipeline, because the request mixes a subject, a category, a geographic limit, a business rule, and a preference. One workable order is to interpret the request, resolve the anchor, retrieve candidates, apply the spatial filter, apply business eligibility, then use semantic similarity only inside the eligible set. Routing and other enrichment run on the survivors. Ranking orders those survivors. The explanation and the map action use the same identifiers the filters used. Spatial context engineering is the companion question of what, from that pipeline, is allowed to reach the language model.
The stages are labeled with the method that owns each one: geocoding, place search, a spatial query, business data, and vector search, followed by enrichment, rank, and the map action. The place names, star ratings, score bars, the "100K+" funnel, and the "top 3–5" claim are illustrative labels. The figure is a reference sketch of the order of work, not a Kaleidr benchmark and not a request format. The business-filter column shows sample rules such as open now and a minimum rating, which belong to the host's data rather than to the public place index.
Order changes recall. Searching the whole embedding index first, then testing geography on a short semantic list, can miss a valid local place that never entered that short list. Restricting the candidate set with the hard geography and the hard business rules first, then ranking by meaning inside that set, keeps the boundary. Where the database can apply both filters in one query, the same principle holds: semantic similarity does not get to erase a required geographic limit.
pgvector's own filtering notes are the practical warning. With an approximate index, the filter is applied after the index scan, and the documentation's illustration is a condition that matches 10 percent of rows under the default HNSW ef_search of 40, which leaves about four rows on average. Iterative index scans, which that documentation introduces for this shortfall, continue until enough rows remain. A team should test filtered recall on realistic data rather than assume the elegant query is the production query.
Why Must Hard Filters Run Before Similarity?
Retrieval asks which candidates may enter consideration. Ranking asks in what order the valid candidates should appear. Mixing the two lets a closed, unauthorized, or out-of-stock place win because it is convenient or semantically close. Kaleidr's place-ranking guide keeps authorization, availability, required capability, and service area as filters before scoring, rather than as weak penalties (Kaleidr, 2026). A penalty can lose to a large convenience term. A filter cannot.
The left column lists four boolean gates and ends in removing invalid candidates. The right column shows sample similarity scores for quiet, family-friendly, and work-friendly, and it ranks only the places that passed. The photographs and the three scores are sample labels, not measured ratings and not a Kaleidr score. The arrow is the order: eligibility, then similarity.
Hard gates stay boolean. Authorized, in stock, open on arrival, and inside the service area are conditions, not weights. Semantic signals can stay scores, and they apply to the places the gates kept. The same split covers a required accessibility rule or a tenant boundary. A required fact that is unknown should stay unknown. Treating an unavailable lookup as false turns a missing inventory read into a confident "out of stock," which is a different error and a worse one.
Why Is On-the-Way Search Not a Radius?
"Near me" and "on my way home" describe different geometry. A radius around the origin returns places within a distance of the start, including places that sit in the wrong direction. A route-corridor query returns places that add little detour to a trip the routing service has already planned. Straight-line distance is a legitimate filter when the question is truly radial. Straight-line distance is the wrong quantity when the decision depends on the journey. Two kilometers of straight line can be a long drive, and a longer straight line can be the shorter trip.
The left panel is a simple radius and shows sample pharmacies inside and outside a one-mile ring. The right panel follows a sample route from work to home and labels pharmacies with detour minutes. The mile values, the detour minutes, and the place names are sample labels, not a live route. The figure's point is the relationship: low route deviation is not the same predicate as a circle around the origin.
The routing service should calculate the detour, and the ranker should receive that result. A language model that estimates the minutes will sometimes contradict the route the service just returned. The route call belongs after resolution and after candidate selection. The route call is not a place search, and a missing path should stay a visible failure rather than a guessed line on the map.
Where Does Kaleidr Fit in This Pipeline?
Kaleidr's public Platform API exposes a forward-geocode endpoint built for a search box or a From/To field, not a private business index. GET /retrieval/geocode/forward accepts q as a place name, a street address with a house number, or a typed latitude and longitude, plus optional near_lat and near_lng used together, limit, and a travel mode (Kaleidr, 2026). The same reference documents a route between coordinates the caller already has, with driving, walking, cycling, and transit profiles, and a route that cannot be planned comes back as a successful HTTP status with an error in the body rather than as a path. Results carry attribution the caller must pass on, and a street-address result can include an identifier that stays stable across data updates. An empty results list means nothing to show, including the case of an internal lookup failure, so an empty list is not proof that the address is invalid.
The documented parameters do not include a customer's private catalog. Public geocoding does not become an inventory system by being mounted on the same map. A caller that needs private stores or inventory has to read those systems directly, then join them to a resolved place with a stable identifier. The geocode response is the public subject, and the business record stays the business record.
Place detail has a current successor, and the older path should not be the one a new integration builds on. The endpoint reference marks GET /retrieval/poi/enrich as deprecated and points new work at POST /spot, which answers what is at a point and can add descriptive content and photos. The deprecated route can be removed after 2027-01-15.
Enrichment still does not decide private eligibility. Hours, photos, and a category from a public source are public facts, with the attribution that source requires. Stock, account permission, and a service area the customer drew stay in the systems that own them. Grounded spatial AI for business data is the guide for that boundary.
The left column separates addresses and named places from private stores, inventory, and service areas. The middle column names Kaleidr forward geocoding, a place-detail step, and the host's own spatial database and business systems. The place-detail box is the job now documented as POST /spot. The older enrich endpoint is the deprecated predecessor, not the integration to start. The right column is what happens after retrieval: a route between known coordinates, a rank of eligible places, an explanation, and a map action. The warning on the figure matches the endpoint reference. A public geocode or place API does not index the caller's private locations, inventory, or service areas.
Organization-specific data follows the plan boundary, not the map. Kaleidr's account documentation says that uploading an organization's own business data for AI answers is Enterprise only, and that the key scope which lets answers draw on that uploaded data is Enterprise only (Kaleidr, 2026). The current public endpoint reference does not document a general-purpose vector-search endpoint. A team that needs semantic retrieval over its own descriptions should treat that index as part of the host or Enterprise design, and should confirm the current contract rather than call a path this article does not cite. How to build a map-aware AI assistant covers the map actions that follow a validated place identifier.
What Should a Team Measure Separately?
Each layer fails in its own way, and a single relevance score will hide which layer failed. Geocoding fails on an ambiguous address, a missing unit, a reversed coordinate, or a match that is only street-level. Place search fails when the provider's coverage, category, or freshness does not match the product. A spatial query fails on an invalid geometry, a mismatched coordinate reference, or a polygon that no longer matches the operation.
Vector search fails on a weak embedding, a stale text, or an approximate index that returns too little after a filter. Business data fails when inventory is unknown, the record is unauthorized, or the hours are stale. A useful log names the layer. "Search failed" does not.
Evaluate the layer against its job, then evaluate the decision. Geocoding wants match quality and stable identifiers. Place search wants candidate recall, category precision, and a stale-place rate. Spatial queries want geometric correctness and evidence that the query used the index. Vector search wants semantic relevance and filtered recall against an exact-search baseline. The end-to-end check is whether an eligible place was retrieved, whether a no-result was the honest outcome, and whether the action used the identifier the filters approved. An authorization miss or a containment miss should not disappear inside an average click-through rate.
Where Should the Stack Start?
Choose the method that can prove the clause the user asked. Geocoding proves where a subject is. Place search proves which known places match a text, a category, or an area in that index. A spatial query proves a geometric relationship over records the application holds. Vector search proves similarity of meaning, and only inside the set the hard filters kept. Business systems prove the current fact. A routing service proves the journey. A ranker orders what remains. The language model explains that result and should not be the source of the distance, the containment test, or the stock count.
Public place data is the right source when public discovery is the job. Private stores, inventory, and eligibility stay in the systems that own them, with stable identifiers joining the provider place, the inventory location, and the map marker. Semantic similarity does not erase a geographic boundary, and a radius does not answer an on-the-way question. Explore Kaleidr Enterprise when the retrieval has to run on organization-specific data, and read the Platform API endpoints for the forward-geocode, spot, and route contracts cited above.
Note: Kaleidr uses AI-assisted tools for image creation, content refinement, and research throughout its creative and development workflows.
FAQs
What is the difference between geocoding and place search?
Geocoding resolves an address, a coordinate, or a known place reference into a geographic identity. Place search discovers businesses, landmarks, stations, and other named places that match text, a category, or a nearby area. One returns a subject. The other returns candidates.
Is point-of-interest search the same as geocoding?
No. Some vendor APIs can accept both an address and a place query. By contrast, Mapbox's Geocoding v6 API no longer provides point-of-interest data at all. Point-of-interest search discovers candidates. Geocoding resolves a location.
What is a spatial query?
A spatial query filters geographic records by a geometry relationship such as within a distance, inside a polygon, intersects, or nearest neighbor. The records and their geometry already belong to the application. The predicate is deterministic.
What is vector search?
Vector search retrieves records whose embeddings are near the query embedding. The method is useful for meaning and for phrasing that does not match the source text. The method does not prove distance, containment, or eligibility.
Can vector search replace a spatial query?
No. Similarity in an embedding space does not prove geographic distance, containment, route fit, or service-area membership. Use a spatial predicate for geographic truth, and use vector search for semantic relevance inside the set that predicate allows.
Should geography filter the set before vector search?
Yes when geography is a hard limit. Searching a global embedding index and then checking location on a short list can drop valid local places that never made that list. The database and the index decide the implementation. The boundary does not.
Should a team geocode before a nearby search?
Yes when the anchor is an address or another unresolved location. Resolve the anchor, then run place retrieval or a spatial query around the resolved point. A category search with no anchor is already a place-search question.
Should a product use a Places API or its own database?
Use a Places API for public discovery when the coverage, the license, and the attribution fit the product. Use the product's own database for first-party stores, inventory, private facilities, eligibility, and current business state. A public place record can identify a store. A public place record should not be the authority for what that store holds today.
What is hybrid location search?
Hybrid location search combines two or more of these methods for one decision. A typical chain resolves an anchor, retrieves place candidates, applies a spatial predicate and a business rule, then ranks any semantic preference inside the eligible set. The language model explains the survivors.
Does Kaleidr document a public vector-search endpoint?
The Platform API endpoint reference cited here does not document a general-purpose vector-search endpoint. The documented retrieval surfaces used in this article are forward geocoding, POST /spot for what is at a point, and the route call between coordinates already in hand. Confirm the current Enterprise contract before building a semantic index into a product plan.
References
- Google Maps Platform. Geocoding API overview. The service accepts an address, coordinates, or a Place ID, and converts an address into coordinates and a Place ID, or coordinates or a Place ID into an address. Accessed October 27, 2026. https://developers.google.com/maps/documentation/geocoding/overview
- Google Maps Platform. Geocoding API v4 overview. Documents forward geocoding, reverse geocoding, place geocoding, and destination search, and separates generally available, preview, and experimental channels. Accessed October 27, 2026. https://developers.google.com/maps/documentation/geocoding/geocoding-v4-overview
- Mapbox. Geocoding API. Forward and reverse geocoding. The Geocoding v6 API no longer provides point-of-interest data and directs that job to the Search Box API. Accessed October 27, 2026. https://docs.mapbox.com/api/search/geocoding/
- Mapbox. Search Box API. Interactive and stand-alone search for addresses, places, and points of interest, including category search. Accessed October 27, 2026. https://docs.mapbox.com/api/search/search-box/
- Google Maps Platform. Text Search (New). Returns places for a text string. Documented examples include "shoe stores near Ottawa" and "123 Main Street." Accessed October 27, 2026. https://developers.google.com/maps/documentation/places/web-service/text-search
- Google Maps Platform. Nearby Search (New). Takes one or more place types and returns matching places within a specified area. Accessed October 27, 2026. https://developers.google.com/maps/documentation/places/web-service/nearby-search
- PostGIS. ST_DWithin. Tests whether two geometries are within a given distance. The call includes a bounding-box comparison that uses available spatial indexes. Geography distance is in meters. Accessed October 27, 2026. https://postgis.net/docs/ST_DWithin.html
- PostGIS. ST_Within. Tests whether every point of one geometry lies in another and the interiors share a point. The function uses available spatial indexes. Accessed October 27, 2026. https://postgis.net/docs/ST_Within.html
- pgvector. pgvector. Exact and approximate nearest-neighbor search in Postgres, including HNSW and IVFFlat indexes, cosine and other distances, and iterative scans when a filter leaves too few approximate results. Accessed October 27, 2026. https://github.com/pgvector/pgvector
- Kaleidr Developer Docs. Platform API endpoints. Documents forward geocoding for a search box or From/To field,
POST /spotas the successor to the deprecated POI enrich endpoint, and a route call between known coordinates. Accessed October 27, 2026. https://docs.kaleidr.com/platform-api/endpoints - Kaleidr. Place Ranking API for Customer Intent. Hard filters such as authorization, availability, required capability, and service area run before scoring. Accessed October 27, 2026. https://kaleidr.com/blog/place-ranking-api
- Kaleidr Developer Docs. How Kaleidr works. Uploading an organization's own business data for AI answers is Enterprise only, as is the key scope that lets answers draw on that data. Accessed October 27, 2026. https://docs.kaleidr.com/concepts/how-kaleidr-works
- Kaleidr. Plot Places on a Map. A related guide for turning resolved places into markers. Accessed October 27, 2026. https://kaleidr.com/blog/plot-places-on-a-map
- Kaleidr. How to Build a Nearby Places Map for Near Me Search. A related guide for nearby discovery. Accessed October 27, 2026. https://kaleidr.com/blog/how-to-build-a-nearby-places-map-for-near-me-search
- Kaleidr. Spatial Context Engineering for Map-Aware AI. A related guide for what reaches the model after retrieval. Accessed October 27, 2026. https://kaleidr.com/blog/spatial-context-engineering
- Kaleidr. Grounded Spatial AI for Business Data. A related guide for keeping business facts in the systems that own them. Accessed October 27, 2026. https://kaleidr.com/blog/grounded-spatial-ai-business-data
- Kaleidr. Map-Aware AI Assistant: How to Build One. A related guide for map actions around a validated place. Accessed October 27, 2026. https://kaleidr.com/blog/how-to-build-a-map-aware-ai-assistant
References in BibTeX
@misc{google_geocoding_overview_2026,
title = {Geocoding API overview},
author = {{Google Maps Platform}},
year = {2026},
url = {https://developers.google.com/maps/documentation/geocoding/overview}
}
@misc{google_geocoding_v4_overview_2026,
title = {Geocoding API v4 overview},
author = {{Google Maps Platform}},
year = {2026},
url = {https://developers.google.com/maps/documentation/geocoding/geocoding-v4-overview}
}
@misc{mapbox_geocoding_api_2026,
title = {Geocoding API},
author = {{Mapbox}},
year = {2026},
url = {https://docs.mapbox.com/api/search/geocoding/}
}
@misc{mapbox_search_box_api_2026,
title = {Search Box API},
author = {{Mapbox}},
year = {2026},
url = {https://docs.mapbox.com/api/search/search-box/}
}
@misc{google_places_text_search_2026,
title = {Text Search (New)},
author = {{Google Maps Platform}},
year = {2026},
url = {https://developers.google.com/maps/documentation/places/web-service/text-search}
}
@misc{google_places_nearby_search_2026,
title = {Nearby Search (New)},
author = {{Google Maps Platform}},
year = {2026},
url = {https://developers.google.com/maps/documentation/places/web-service/nearby-search}
}
@misc{postgis_st_dwithin_2026,
title = {ST_DWithin},
author = {{PostGIS}},
year = {2026},
url = {https://postgis.net/docs/ST_DWithin.html}
}
@misc{postgis_st_within_2026,
title = {ST_Within},
author = {{PostGIS}},
year = {2026},
url = {https://postgis.net/docs/ST_Within.html}
}
@misc{pgvector_2026,
title = {pgvector},
author = {{pgvector}},
year = {2026},
url = {https://github.com/pgvector/pgvector}
}
@misc{kaleidr_platform_api_endpoints_2026,
title = {Platform API endpoints},
author = {{Kaleidr}},
year = {2026},
url = {https://docs.kaleidr.com/platform-api/endpoints}
}
@misc{kaleidr_place_ranking_api_2026,
title = {Place Ranking API for Customer Intent},
author = {{Kaleidr}},
year = {2026},
url = {https://kaleidr.com/blog/place-ranking-api}
}
@misc{kaleidr_how_kaleidr_works_2026,
title = {How Kaleidr works},
author = {{Kaleidr}},
year = {2026},
url = {https://docs.kaleidr.com/concepts/how-kaleidr-works}
}