你用的每一张地图，其实都是两层叠在一起的。下面一层是几何数据：道路、海岸线、建筑轮廓，这些形状让地图看起来像地图。上面一层才让地图真正有用，它回答的是「这里到底有什么」。第二层就是POI数据。
POI是point of interest（兴趣点）的缩写，POI数据是对人们真正关心的场所所做的结构化记录：营业到晚上十点的药店、接口匹配的充电桩、能用你那份保险的诊所、有无障碍入口的咖啡馆。没有它，地图只是一张街道图片。有了它，地图变得可搜索、可筛选，也变成软件能够推理的对象。
本文讲清一条POI记录到底包含什么、数据从何而来、为什么不同供应商之间质量差距如此之大，以及POI数据在应用和AI智能体中如何被使用。
什么算作兴趣点
兴趣点是被建模为单个点而非面或线的命名场所。判定方法是：人们是否可能想去那里，或者想知道那里有这么一个地方。
餐厅、酒店、医院、取款机、游乐场、观景点、邮筒、电动车充电桩、公交站、回收站都是POI。街道不是，因为它是线。街区和行政区也不是，因为它们是多边形，没有人会导航到一个区的几何中心。建筑处在一个有意思的中间地带：购物中心本身是一个POI，同时它内部还包含着几十个独立的POI。
最后这种情况值得多说两句，因为粗糙的数据集正是在这里崩溃的。在机场中心打一个坐标，不足以把旅客导航到具体的登机口、休息室或租车柜台。好的POI数据会把父级和子级分别建模，并把两者关联起来。
一条POI记录包含什么
最小可用的POI是一个带名称和类别的坐标。这足以画出一个图钉，但不足以做出一个产品。
生产级记录承载的内容要多得多：
- 稳定标识符。 如果记录更新时ID也跟着变，你就无法跨时间追踪一个场所，也无法与自己的数据库做比对。
- 名称，包含本地语言变体。 布鲁塞尔的场所可能同时需要法语名和荷兰语名。雅典的场所需要希腊字母写法和罗马化写法。
- 坐标，最好同时说明这个点代表什么：建筑屋顶质心、出入口，还是按地址插值得出的近似位置。
- 结构化地址，拆分为字段而不是一整个字符串，这样才能匹配、校验，并按不同国家的规范重新排版。
- 类别，取自定义好的分类体系而非自由文本。restaurant 是有用的取值；同一个概念在四条记录里分别写成 restaurant / eatery / Restaurant / food 就不是。
- 营业时间，采用机器可读格式，能处理午休断档、季节调整和法定假日这些麻烦的现实情况。
- 联系方式与网络信息：电话、网站、预订链接。
- 配套与无障碍属性：轮椅通行、户外座位、停车、支持的支付方式、是否允许携带宠物。
- 来源与新鲜度：这条记录出自哪里，最近一次核验是什么时候。
最后一项是最常被跳过、事后又最让人后悔的字段。一个没有新鲜度信号的POI数据集，无法让你判断某家餐厅是不是两年前就关门了。
POI数据的来源
大致有三类来源，而几乎所有真实数据集都是它们的混合。
开放数据。 OpenStreetMap是全球规模最大的开放许可POI集合，由全球社区直接为场所打标签并持续维护。在欧洲密集城区覆盖极佳，在乡村地区以及欧洲和北美之外的部分区域则参差不齐。它的属性丰富度往往令人惊讶，因为贡献者会标注商业采集人员根本不会去关心的细节。
官方登记。 工商登记、交通主管部门的站点清单、医疗机构目录、学校名录、地籍记录等。这类数据权威且维护良好，但它以几十种互不兼容的国家格式提供，而且很少包含终端用户真正在意的属性。
商业采集。 厂商聚合上述来源，加上自有抓取，采购数据源，然后出售访问权限。你付费买到的通常不是原始场所本身，而是把它们合并起来的这份工作。
这项合并工作叫做实体融合（conflation），难点几乎都集中在这里。同一家咖啡馆可能出现在三个来源中，带着三种拼写、两个略有差异的坐标，以及一个早已过期的电话号码。判定它们是同一个场所，并决定每个属性该以哪个版本为准，才是构建POI数据库最难的部分。
为什么质量差距这么大
两个数据集都可以声称自己有四千万个POI，实际用起来却天差地别。真正有意义的指标是：
- 位置精度。 图钉落在建筑上、街道上，还是邮编区的中心？对门店查找来说这只是观感问题，对最后一公里配送来说，它决定司机能否找到那扇门。
- 属性完整度。 一千万条只有名称的记录，不如两百万条带营业时间、类别和无障碍标记的记录有用。
- 类别一致性。 分类体系不一致，你建的每一个筛选条件都会漏数据。
- 新鲜度。 零售和餐饮的更替速度很快，一年才刷新一次的数据集描述的是一个已经不存在的世界。
- 重复率。 融合做得差会虚增数量，一家店冒出三个图钉。
评估供应商时，请忽略标题里的总数，转而追问：多少比例的记录带有营业时间，以及它们最近一次核验是什么时候。
POI数据的典型用法
门店查找与网点定位。 最常见的用途：显示我附近的网点，并按我需要的条件筛选。具体做法参见如何构建门店查找功能。
选址与商圈分析。 在候选点位周围的通行时间边界内，统计竞品、互补业态和引流场所。POI数据加上等时圈，构成了大多数零售选址决策的核心。
物流与配送。 把目的地解析到精确的出入口而不是屋顶质心，并判断收件方是否处于营业状态。
房产与房源。 描述一处房产周边有什么：学校、交通、商店、绿地。正是这些内容，让房源从一组照片变成买家或AI可以评估的对象。
旅行与本地发现。 从酒店附近有什么，一直到完整行程生成。
面向AI智能体的POI数据
这是需求转移最快的方向。当有人问助手「帮我找车站附近现在开门、并且有无障碍入口的药店」时，助手没法眯着眼睛看地图。它需要能够以程序方式筛选的记录：类别等于药店、营业时间包含当前时间戳、轮椅属性为真、坐标落在从车站出发的步行时间边界内。
这里每一个条件都是一项POI属性。拥有丰富POI数据源的智能体能够回答问题；只有名称和坐标的智能体只能猜，而对真实世界场所的猜测，正是那些语气笃定却完全错误的推荐的来源。
因此，POI数据越来越多地以工具而非瓦片的形式交付给智能体。通过API或MCP服务器，智能体可以查询场所、按属性筛选，并拿回可供推理和引用的结构化结果。
把POI数据接入你的产品
有三个实际决策。
许可。 弄清楚你被允许拿这些数据做什么，尤其是缓存、再分发，以及在地图之外展示。开放数据同样有义务，主要是署名，某些许可证还带有相同方式共享条款。
在哪里处理。 如果你在欧洲运营，而查询中携带了用户位置，那么这些查询在哪里被处理就不只是延迟问题，而是合规问题。参见欧盟开发者的GDPR合规地图API指南。
如何保持更新。 一开始就决定你是查询实时API，还是同步一份快照。快照快速且可预测，但从落盘那一刻就开始腐坏；实时查询始终最新，代价是多一个依赖。
MapAtlas提供符合GDPR的POI搜索、地点详情和周边查询，覆盖欧洲及更广区域，基于开放地图数据构建，并同时通过搜索API和MCP服务器对外提供，因此同一批结构化记录既能支撑门店查找，也能服务AI智能体。
一句话总结
POI数据是让地图能够回答问题的那一层。一条记录等于一个坐标，加上让软件可以筛选的属性：名称、类别、地址、营业时间、无障碍信息、新鲜度。它来自开放数据、官方登记和商业采集，而供应商创造的价值主要在于把这三者干净地合并起来。
判断一个数据集，要看它的属性深度和新鲜度，而不是它宣称有多少个图钉。如果你的路线图上有AI智能体，那就再加一条标准：智能体能不能在不靠猜的前提下对它做筛选。
延伸阅读
常见问题
什么是POI数据？
POI数据是关于兴趣点的结构化信息，也就是人们可能想要查找或前往的具体场所，例如药店、充电桩、学校、酒店或公交站。一条POI记录把一个坐标和一组描述性属性绑定在一起：名称、类别、地址、营业时间、联系方式，通常还包括无障碍设施和配套设施标记。正是这一层数据，让地图从一张街道图片变成可以搜索、可以筛选、可以被程序推理的对象。
兴趣点指的是什么？
兴趣点是以点的形式表示在地图上的单个命名场所，而不是面或线。判定标准在于它是否是人们可能想去或想知道的地方。餐厅、取款机、观景点、回收站都是兴趣点。道路和行政边界则不是，因为它们被建模为线和多边形，没有人会导航到一条边界线上。
一条POI记录包含哪些属性？
最低限度的POI包含稳定标识符、名称、经纬度和类别。生产级数据集会补充更多内容：结构化地址、营业时间、电话和网站、价格区间、轮椅通行情况、是否有户外座位或停车场、支持的支付方式，以及该记录最近一次核验的日期。属性的丰富程度，通常就是可用POI数据集与一份光秃秃的坐标清单之间的分界线。
POI数据从哪里来？
主要有三类来源。一是开放数据，以OpenStreetMap为代表，由全球社区直接为场所打标签，成果以自由许可发布。二是官方与行政登记，例如工商登记、交通主管部门的站点清单、医疗机构目录。三是商业采集，厂商对数据进行聚合、抓取或采购，再出售访问权限。真正可用的数据集大多同时融合这三类来源，然后通过实体融合与校验来合并重复项、解决冲突。
AI智能体如何使用POI数据？
当AI智能体要回答「帮我找一家车站附近现在还开门的药店」时，它无法从一张地图图片里推理出答案。它需要可以直接筛选的结构化记录：类别等于药店、营业时间覆盖当前时间、坐标落在车站的通行时间范围内。POI数据提供的正是这些条件，这也是为什么它越来越多地通过API和MCP服务器暴露给智能体，而不是渲染到屏幕上供人肉眼扫描。
