地理编码 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}
}