地理編碼 vs 地點搜尋

地理編碼 vs 地點搜尋是位置查詢中的第一處分工：一個呼叫解析地理對象，另一個發現候選地點。地址、坐標或地點識別碼屬於地理編碼。查找商家、地標或其他命名地點的請求屬於地點搜尋。隨後，空間查詢驗證應用程式已經持有的幾何關係，而向量搜尋匹配語義，但不能證明某條記錄位於附近或符合條件。

每種位置查詢分別回答什麼問題？

每種方法回答不同的問題，供應商即使把它們放在同一產品系列中，也不會消除這種差異。地理編碼解析身份。地點搜尋在供應商索引或私有索引中發現候選項。空間查詢把幾何關係應用於應用程式已經儲存的記錄。向量搜尋檢索嵌入在語義上接近的記錄。正式環境的決策往往需要這些答案中的多個，並按照問題本身規定的順序執行。

四張卡片把解析、發現、地理過濾和語義匹配分開。每張卡片都把輸入與輸出對應起來：地址對應坐標，類別對應興趣點，幾何關係對應匹配記錄，概念對應語義近鄰。街道地址、坐標、咖啡館查詢以及多邊形內的地點數量都是圖中的範例標籤。這些標籤並不是針對Kaleidr索引的即時查詢結果。

這張表就是選擇規則。如果團隊從端點名稱而不是問題本身出發，就可能讓地理編碼器做推薦，或讓向量索引做包含判斷。這兩種錯誤都會對系統從未真正執行的問題給出看似很確定的答案。本指南接下來會繼續把這四項任務分開，然後說明管線需要在哪一步把它們組合起來。

哪種查詢適合這個問題？

請求開頭的措辭通常就指明瞭方法。“這個地址在哪裡？”從地理編碼開始。“哪些地點與這段文字或這個類別匹配？”從地點搜尋開始。“我們的哪些記錄滿足這種地理關係？”從空間查詢開始。“哪些記錄表達了類似的含義？”則適合向量搜尋，但必須先應用嚴格的地理限制和業務限制。把這些問題混在一起的請求需要混合方案，而不是選出一個單一贏家。

決策樹從呼叫端試圖回答的問題開始，然後分支到解析一個地址、發現商家、按地理條件過濾呼叫端自己的記錄，或查找語義相近的記錄。底部第五條分支在單一查詢不足時組合四種方法。範例地址、咖啡館卡片、一公里半徑以及引號中的約會場景短語都只是圖中標籤。勾選標記說明每種方法的職責，並不是測得的質量分數。

混合方案對於AI地圖助手來說是常見情況，並不是留到後續版本才處理的例外。“20 W 34th St附近的咖啡”仍然需要先解析地址，才能運行附近搜尋。“酒店附近、晚上九點後仍營業的安靜咖啡館”則在地址解析之上加入業務過濾和語義偏好。下面的管線部分會按審核人員能夠測試的順序保留這些步驟。

地理編碼解析什麼？

地理編碼把文字位置轉換為地理表示，反向地理編碼則把坐標或地點識別碼轉換回可讀地址。Google的Geocoding API概述把該服務定義為：接受地址、緯度和經度或Place ID，把地址轉換為坐標和Place ID，或把坐標或Place ID轉換為地址 (Google, 2026)。同一概述使用“1600 Amphitheatre Parkway, Mountain View, CA”作為正向地理編碼範例，並把配送與取貨列為反向地理編碼用途。成功呼叫的輸出是地圖可以定位的對象，而不是經過排序的商家集合。

產品邊界正在變化，但真正需要命名的仍然是檢索任務。Google的Geocoding API v4概述列出了正向地理編碼、反向地理編碼、地點地理編碼，以及接受地址、Place ID或坐標的目的地搜尋方法 (Google, 2026)。該概述還區分正式發布、預覽和實驗性渠道，並要求呼叫端對尚未進入正式可用路徑的目的地功能使用實驗性渠道。目的地查找可以補充應用程式已經解析的位置。但它不會因此變成地點發現索引，實驗性渠道也不意味著每個字段都已經適合正式環境合約。

當地應用程式需要把地址繪制到地圖、儲存前進行正規化、居中地圖、對設備位置執行反向地理編碼，或在後續查詢前解析配送點時，地理編碼就是正確工具。地理編碼不會選擇最佳附近餐廳，不會讀取私有庫存，不會驗證私有服務區域多邊形，也不會按客戶意圖給結果排序。這些任務都要在對象已經存在之後才開始。在地圖上繪制地點講解瞭解析成功之後從地址到標記的步驟。

地理編碼 vs 地點搜尋有什麼不同？

地點搜尋發現有名稱的地理實體：餐廳、門市、車站、地標以及其他興趣點。Mapbox在當前Geocoding API中明確劃分了產品邊界。該API執行正向和反向地理編碼，而Geocoding v6 API已經不再提供興趣點資料 (Mapbox, 2026)。Mapbox把興趣點搜尋指向Search Box API，該API支持地址、地點和興趣點的交互式與獨立查詢，包括類別搜尋 (Mapbox, 2026)。端點系列屬於某一家供應商，但任務仍然是兩個不同的任務。

Google當前的Places API在地點搜尋內部也做了同樣的區分。Text Search (New)針對文字字符串回傳地點，文檔範例包括“shoe stores near Ottawa”和“123 Main Street”，因此類似地址的字符串也可能進入地點搜尋呼叫 (Google, 2026)。Nearby Search (New)接收一個或多個地點類型，並在指定區域內回傳匹配地點 (Google, 2026)。因此，當字符串是地址時，Text Search可能看起來像地理編碼；當區域是圓形時，Nearby Search可能看起來像空間查詢。但結果仍然是來自該供應商索引的候選集合。營業狀態、庫存、授權和出行時間仍然是後續測試。同一Text Search頁面還說明，該服務不適合模糊查詢，包括未以地點形式表示的郵政地址格式。

左側面板詢問一個地址在哪裡，並顯示單一位置身份。該面板中的地址和坐標與Kaleidr forward-geocode參考中的範例一致；右側的咖啡館名稱、距離和星級評分只是範例標籤，並不是即時地點搜尋響應。底部把“coffee near 20 W 34th St”拆成先對地址做地理編碼，再搜尋咖啡。右側結論把結果稱為候選集合，這是進入資格判定和排序之前正確的停止點。

當錨點是地址而目標是類別時，穩健的應用會同時使用兩者。先對“20 W 34th St”進行地理編碼，再在解析後的點附近搜尋咖啡，然後計算步行時間，只對仍符合條件的地點排序。附近地點地圖是第二步的發現界面。供應商的順序只是檢索上的便利。產品的順序才是後續決策。

空間查詢驗證什麼？

空間查詢使用幾何對象之間的關係，對應用程式已經持有的記錄進行過濾。常見關係包括一定距離內、位於多邊形內部、相交、包含和最近鄰。記錄及其幾何對象在查詢之前就已經存在。查詢的任務是判斷哪些記錄滿足該關係。地點搜尋API回答的是另一個問題，因為它的候選集合來自供應商索引，而不是呼叫端自己的表。

這些面板分別表示一定距離內、位於多邊形內、路線與區域相交以及最近要素。一公里半徑、服務區域輪廓和距離徽標都是範例幾何，並不是實際測量的服務區域。最近面板還把一個要素標記為已排除。這是後續資格檢查的範例。距離謂詞本身並不會驗證地點是否營業。

PostGIS把ST_DWithin定義為測試兩個幾何對象是否位於給定距離內，並且呼叫包含邊界框比較，可利用幾何對象上可用的空間索引 (PostGIS, 2026)。對於geography類型，距離單位是米。因此，帶有geography列的門市資料表可以把“5公里以內”作為謂詞保存，而不是寫成一句需要語言模型解釋的話。

SELECT store_id, name
FROM stores
WHERE ST_DWithin(stores.geog, user_location, 5000);

包含判斷屬於同一類謂詞。ST_Within在第一個幾何對象的所有點都位於第二個內部且兩者內部共享一點時回傳true，並同樣利用可用的空間索引 (PostGIS, 2026)。ST_Within(A, B)是ST_Contains(B, A)的逆關係。“這個地址是否位於服務區域內？”這樣的配送問題，需要先地理編碼，再做包含測試，然後應用運營規則。向量索引不能替代多邊形，公開地點搜尋也不能替代企業自己繪制的服務區域幾何。

關於索引的說明是架構約束，不是調優腳注。無法使用索引的距離表達式，會比同一張表上的ST_DWithin比較多得多的行。對於位置感知助手，實用規則是先按地理條件過濾，再讓任何模型看到集合。如果一個大型目錄中只有很小一部分可能滿足幾何條件，語言模型應該只接收這一部分，以及其他記錄被排除的原因。把其餘記錄也發送過去，只會把上下文浪費在謂詞已經排除的記錄上。

向量搜尋匹配什麼？

向量搜尋會檢索在向量空間中嵌入與查詢接近的記錄。pgvector是這一任務常用的Postgres擴展，默認執行精確最近鄰搜尋，也可以增加HNSW或IVFFlat索引用於近似搜尋 (pgvector, 2026)。同一文檔列出了L2距離、內積、余弦距離等度量。精確搜尋是召回率基線。近似索引用部分召回率換取速度，建立索引後查詢可能回傳不同的近鄰。團隊把使用精確搜尋的原型與使用索引的正式環境查詢進行比較時，這一特性非常重要。

當請求中的詞和記錄中的詞不一致時，向量搜尋才真正值得它的成本。比如“燈光昏暗的私密葡萄酒吧”即使字符串不匹配，也可能成為“適合第一次會面的安靜地點”的有用近鄰。地點描述、設施備注和目的地文案通常是輸入，前提是許可證允許把文字做成嵌入。已知品牌、門市編號、機場代碼或明確類別通常更適合關鍵詞或結構化搜尋。嵌入會增加一個需要運營的系統，應該在語義漏召回確實存在時再引入。

向量相似度並不記錄地理距離、路線時間、服務區域包含關係、當前庫存、營業時間、授權狀態，也不記錄被嵌入的文字現在是否仍然真實。在嵌入空間中接近的近鄰，可能離呼叫端幾百英里。街對面的地點可能語義匹配很差，卻仍然是正確的運營答案。這兩個結果並不衝突，因為它們來自不同空間。管線必須明確哪一個空間有權淘汰候選。

為什麼地理距離和向量距離不同？

兩個系統都使用“距離”這個詞，而這個詞掩蓋了測量對象的變化。地理距離是地球表面或沿路徑的分離：直線長度、步行、駕車或包含結果。向量距離是在嵌入空間中的分離：余弦距離、歐氏距離或內積得分。向量距離很小並不代表兩個地點在地理上很近。步行距離短也不代表兩段描述表達相同含義。

左側面板測量物理距離，並顯示兩個帶標籤地點之間的範例步行。公里和分鐘徽標只是範例標籤，不是實際路線規劃結果。右側面板把單詞放入嵌入示意圖，並把coffee標記為在語義上遠離train。余弦標注只是兩個空間的說明，並不是從Kaleidr索引測得的嵌入。中間標籤就是這張圖的重點：同一個“距離”一詞指代兩種不同的量。

這種命名衝突也會出現在產品文案中。界面上的“最近”可能表示嵌入索引中最近、直線米數最近，或繞行分鐘數最少。這三種排序經常不一致，因此界面應該明確指出衡量的是什麼。排序器可以同時使用多個指標，但不應該把余弦得分與公里數相加，再把總和當作一種單一距離。

混合管線應該如何安排工作順序？

正式環境中的位置搜尋通常是一個管線，因為請求會混合對象、類別、地理限制、業務規則和偏好。一種可行順序是：解釋請求、解析錨點、檢索候選、應用空間過濾、應用業務資格，然後只在符合條件的集合內部使用語義相似度。路線規劃和其他補充資訊只對剩餘候選運行。排序對這些候選排序。解釋和地圖操作使用與過濾器相同的識別碼。空間上下文工程是配套問題：這個管線中的哪些內容允許到達語言模型。

各階段按負責的方法標注：地理編碼、地點搜尋、空間查詢、業務資料和向量搜尋，然後是補充、排序和地圖操作。地點名稱、星級評分、得分條、“100K+”漏斗和“top 3–5”說法都是示意標籤。這張圖是工作順序的參考草圖，不是Kaleidr benchmark，也不是request格式。業務過濾列展示了“當前營業”和最低評分等範例規則，它們屬於host資料，不屬於公開地點索引。

順序會改變召回率。先搜尋整個嵌入索引，再在一個較短的語義列表上驗證地理條件，可能錯過從未進入這個短列表的有效本地地點。先用嚴格地理條件和嚴格業務規則縮小候選集合，再在該集合內部按語義排序，可以保留邊界。即使資料庫能在一個查詢里應用兩種過濾，原則也一樣：語義相似度不能抹掉必需的地理限制。

pgvector自己的filtering說明就是實用警告。在近似索引中，過濾是在index scan之後應用程式的；文檔範例使用一個匹配10%行的條件，在默認HNSW ef_search為40時平均只剩大約4行。文檔為這個不足引入的iterative index scans會持續執行，直到剩下足夠的行。團隊應該用真實資料測試filtered 召回率，而不是假設看起來優雅的查詢就是正式環境查詢。

為什麼嚴格過濾必須先於相似度？

檢索問的是哪些候選允許進入考慮範圍。排序問的是有效候選應該按什麼順序出現。把兩者混合，會讓已關閉、未授權或缺貨的地點因為便利或語義接近而勝出。Kaleidr的地點排序指南把授權、可用性、必需能力和服務區域作為評分前的過濾條件，而不是較弱的懲罰項 (Kaleidr, 2026)。懲罰項可能輸給一個很大的便利性項。過濾條件不會。

左列列出四個boolean gate，最後移除無效候選。右列展示安靜、適合家庭、適合工作的範例相似度得分，只對通過的地點排序。照片和三個得分都是範例標籤，不是實際測得的評分，也不是Kaleidr分數。箭頭表示順序：先資格，再相似度。

嚴格gate保持boolean。已授權、有庫存、到達時營業、位於服務區域內都是條件，不是權重。語義信號可以保持為得分，只應用於gate保留下來的地點。同樣的分離也適用於必須滿足的無障礙規則或tenant邊界。必需事實如果是unknown，就應該繼續保持unknown。把不可用的查找當成false，會把一次庫存讀取失敗變成一個很確定的“缺貨”，這是另一種、更糟糕的錯誤。

為什麼“順路”搜尋不是半徑搜尋？

“我附近”和“我回家路上”描述的是不同幾何關係。以起點為中心的半徑會回傳距離起點一定範圍內的地點，其中也包括方向相反的地點。route-corridor查詢會回傳只給路線規劃服務已經規劃的行程增加少量繞行的地點。當問題確實是徑向問題時，直線距離是合理過濾條件。但當決策取決於旅程時，直線距離就是錯誤的量。直線2公里可能需要很長的駕車時間，而直線距離更長的地點反而可能對應更短的實際行程。

左側面板是簡單半徑，顯示一英里圓環內外的範例藥店。右側面板沿從工作地點回家的範例路線行進，並給藥店標注繞行分鐘數。英里數、繞行分鐘和地點名稱都是範例標籤，不是即時路線。圖的重點是兩種關係不同：較低的路線 deviation並不等於以起點為圓心的圓形謂詞。

路線規劃服務應該計算繞行，排序器應該接收這個結果。語言模型如果估算分鐘數，有時會與服務剛剛回傳的路線矛盾。路線呼叫應該放在解析和候選選擇之後。路線呼叫不是地點搜尋；如果沒有可用路徑，就應該保留為明顯失敗，而不是在地圖上猜一條路線。

Kaleidr在這條管線中處於哪裡？

Kaleidr的公開Platform API提供一個用於搜尋框或From/To字段的forward-geocode 端點，而不是私有業務索引。GET /retrieval/geocode/forward接受q作為地點名稱、帶門牌號的街道地址或手動輸入的緯度和經度，還可接受成對使用的可選near_lat和near_lng、limit以及出行mode (Kaleidr, 2026)。同一參考文檔還記錄了呼叫端已經掌握的坐標之間的路線，支持駕車、步行、騎行和公開交通profile。無法規劃的路線會回傳成功HTTP狀態，但在body中包含錯誤，而不是返迴路徑。結果帶有呼叫端必須繼續傳遞的attribution，街道地址結果還可能包含跨資料更新保持穩定的識別碼。空results列表表示沒有內容可顯示，也包括內部查找失敗的情況，因此空列表並不能證明地址無效。

文檔化的參數不包括客戶的私有目錄。公開地理編碼不會因為與私有資料出現在同一張地圖上，就變成庫存系統。需要私有門市或庫存的呼叫端必須直接讀取這些系統，然後用穩定識別碼與已解析地點連接。geocode響應是公開對象，業務記錄仍然是業務記錄。

地點詳情現在有新的後繼路徑，新集成不應該繼續構建在舊路徑上。端點參考把GET /retrieval/poi/enrich標記為deprecated，並把新工作指向POST /spot；後者回答某一點上有什麼，並可以添加描述內容和照片。deprecated路徑可能在2027-01-15之後被移除。

補充資訊仍然不會決定私有資格。來自公開來源的營業時間、照片和類別是公開事實，需要保留該來源要求的attribution。庫存、賬戶權限以及客戶繪制的服務區域仍然留在擁有它們的系統中。基於業務資料的Spatial AI是關於這一邊界的指南。

左列把地址和命名地點與私有門市、庫存和服務區域分開。中間列列出Kaleidr 正向地理編碼、地點詳情步驟，以及host自己的空間資料庫和業務系統。地點詳情框就是現在以POST /spot記錄的任務。舊的enrich 端點是deprecated前身，不是新集成應該開始的路徑。右列展示檢索之後的處理：已知坐標之間的路線、符合條件地點的排序、解釋和地圖操作。圖中的警告與端點參考一致。公開geocode或place API不會索引呼叫端的私有地點、庫存或服務區域。

組織專屬資料遵循的是套餐邊界，而不是地圖邊界。Kaleidr賬戶文檔說明，上傳組織自己的業務資料用於AI回答只對Enterprise開放，讓回答使用這些上傳資料的key scope也只對Enterprise開放 (Kaleidr, 2026)。當前公開端點參考沒有記錄通用向量搜尋端點。需要對自有描述做語義檢索的團隊應該把該索引視為host或Enterprise設計的一部分，並確認當前合同，而不是呼叫本文沒有引用的路徑。如何構建map-aware AI助手講解了經過驗證的地點識別碼之後的地圖操作。

團隊應該分別衡量什麼？

每一層都有自己的失敗方式，一個統一的相關性得分會掩蓋到底哪一層失敗。地理編碼會因為地址含糊、單元資訊缺失、坐標顛倒或只匹配到街道級別而失敗。地點搜尋會因為供應商覆蓋、類別或時效性不符合產品而失敗。空間查詢會因為無效幾何、坐標參考不匹配或多邊形已經不符合運營實際而失敗。

向量搜尋會因為嵌入質量弱、文字過時，或近似索引過濾後回傳太少而失敗。業務資料會因為庫存unknown、記錄未授權或營業時間過時而失敗。有用的日誌會明確指出層。單寫“Search failed”不夠。

先按每層的任務衡量該層，再衡量最終決策。地理編碼要看匹配質量和穩定識別碼。地點搜尋要看候選召回率、類別precision和過期地點率。空間查詢要看幾何正確性以及查詢確實使用索引的證據。向量搜尋要看語義相關性，以及相對於exact-search基線的filtered 召回率。端到端檢查要確認是否檢索到符合條件的地點、no-result是否是誠實結果，以及操作是否使用過濾器批准的識別碼。授權遺漏或包含判斷錯誤不應該消失在平均click-through rate里。

整個stack應該從哪裡開始？

選擇能夠證明使用者所要求條件的方法。地理編碼證明對象在哪裡。地點搜尋證明該索引中哪些已知地點與文字、類別或區域匹配。空間查詢證明應用程式持有記錄之間的幾何關係。向量搜尋證明語義相似性，而且只能在嚴格過濾後保留下來的集合內使用。業務系統證明當前事實。路線規劃服務證明旅程。排序器給剩餘項排序。語言模型負責解釋結果，不應該成為距離、包含測試或庫存數量的來源。

當任務是公開發現時，公開地點資料就是正確來源。私有門市、庫存和資格仍留在擁有它們的系統中，用穩定識別碼把供應商地點、庫存位置和地圖標記連接起來。語義相似性不能抹掉地理邊界，半徑也回答不了“順路”問題。當檢索必須在組織專屬資料上運行時，查看Kaleidr Enterprise，並閱讀Platform API 端點瞭解上文引用的forward-geocode、spot和路線契約。

說明：Kaleidr在創意和開發工作流程中使用AI輔助工具進行圖像創建、內容優化和研究。

常見問題

地理編碼和地點搜尋有什麼區別？

地理編碼把地址、坐標或已知地點引用解析成地理身份。地點搜尋發現與文字、類別或附近區域匹配的商家、地標、車站和其他命名地點。前者回傳一個對象，後者回傳候選項。

興趣點搜尋和地理編碼是一回事嗎？

不是。有些供應商API同時接受地址和地點查詢。相比之下，Mapbox的Geocoding v6 API已經完全不再提供興趣點資料。興趣點搜尋用於發現候選項。地理編碼用於解析位置。

什麼是空間查詢？

空間查詢按照幾何關係過濾地理記錄，例如一定距離內、位於多邊形內、相交或最近鄰。記錄及其幾何已經屬於應用程式本身。謂詞是確定性的。

什麼是向量搜尋？

向量搜尋檢索嵌入接近查詢嵌入的記錄。它適合處理語義以及與源文字措辭不一致的表達。但它不能證明距離、包含關係或資格。

向量搜尋可以替代空間查詢嗎？

不可以。嵌入空間中的相似性不能證明地理距離、包含關係、路線適配或服務區域歸屬。地理事實應使用空間謂詞，向量搜尋只用於該謂詞允許集合內的語義相關性。

向量搜尋之前應該先用地理條件過濾集合嗎？

如果地理條件是硬限制，就應該這樣做。先搜尋全局嵌入索引，再在一個短列表裡檢查位置，可能會丟掉從未進入該列表的有效本地地點。具體實現由資料庫和索引決定，但邊界本身不會改變。

團隊應該在附近搜尋前先做地理編碼嗎？

如果錨點是地址或其他尚未解析的位置，就應該先解析錨點，然後在解析後的點周圍執行地點檢索或空間查詢。沒有錨點的類別搜尋本身就是地點搜尋問題。

產品應該使用Places API還是自己的資料庫？

當覆蓋、許可證和attribution適合產品時，公開發現使用Places API。自有門市、庫存、私有設施、資格和當前業務狀態使用產品自己的資料庫。公開地點記錄可以識別一家門市，但不應成為該門市今天有什麼庫存的權威來源。

什麼是混合位置搜尋？

混合位置搜尋為一次決策組合兩種或更多上述方法。典型流程是解析錨點、檢索地點候選、應用空間謂詞和業務規則，然後在符合條件的集合內對語義偏好排序。語言模型負責解釋最終留下的候選項。

Kaleidr是否記錄了公開向量搜尋端點？

本文引用的Platform API 端點參考沒有記錄通用向量搜尋端點。本文使用的已記錄檢索能力是正向地理編碼、用於查詢某一點有什麼的POST /spot，以及已知坐標之間的路線呼叫。在把語義索引納入產品計劃之前，請確認當前Enterprise合同。

References

1. 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
2. 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
3. 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/
4. 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/
5. 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
6. 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
7. 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
8. 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
9. 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
10. Kaleidr Developer Docs. Platform API endpoints. Documents forward geocoding for a search box or From/To field, POST /spot as 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
11. 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
12. 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
13. 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
14. 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
15. 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
16. 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
17. 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}
}