街景数据平台详细对比：全球、区域、开放与专业测绘来源

街景类项目大多从看地图开始：打开某个平台，发现自己关心的那些街道上都有影像，于是断定「数据是有的」。但「看得见的影像」和「拿得到的影像」是两回事，而这中间的落差，比任何技术难题都更常让街景项目中途夭折。

本文覆盖五类共十个平台，因为几乎没有一个像样的研究区域能靠单一平台服务得好。文章刻意围绕「每个平台你究竟能拿它做什么」来组织，而不是围绕画质——画质很少是决定项目成败的那道约束，接口、授权和覆盖才是。

对每个平台都要分开问三个问题

混乱大多来自把三件互相独立的事，压缩成「能不能访问」一个说法。一个平台完全可能在其中一项上很开放，在另外两项上完全封闭；不把它们拆开的对比，只会把人带偏。

1. 展示接口：你能不能在平台自己的组件里把影像展示给用户？答案几乎总是「能」，而这一点完全说明不了你是否可以处理这些像素。
2. 数据接口：有没有一个有文档的端点，能把影像文件和结构化元数据返回给你自己的程序，而且吞吐量撑得起你的研究范围？
3. 授权与再利用：你能存什么、能存多久、能公开什么、必须标注什么？这由条款决定，而不是由「技术上能不能下载成功」决定。

覆盖范围是第四个问题，但那是人人都会问的一个。真正被跳过的，是前面这三个。

把三种接口性质分开命名同样有帮助，因为厂商会把它们统称为「API」。查看器 / 展示 API 是把厂商自己的组件嵌进你的页面，像素只出现在屏幕上。静态图 / 数据 API 会在文档化的配额内，把影像文件和结构化记录返回给你的程序。商业授权数据则是一份合同，允许在约定的区域、期限和用途内批量交付影像或衍生图层。「能显示」完全不等于「能批量导出」——这个领域里绝大多数落空的预期，都来自把第一种当成第三种。

街景平台的五个类别

平台的行为方式，更像它所属的类别，而不像各家宣传里彼此的差异。一旦判断出一个来源属于哪一类，你在读文档之前就已经能预判它大部分要紧的性质。

• 全球车队平台：Google 街景与 Apple Look Around。专用采集车、按路网系统性采集、覆盖多个国家，条款也是为庞大的开发者群体写的。Google 开放了影像与元数据端点，Apple 开放的是查看器。
• 中国大陆平台：百度全景与腾讯街景。这是中国大陆境内的现实选择，各有自己的坐标系、开发者账号和配额规则，也各自都有文档化的全景静态图服务。
• 区域性平台：Yandex Panoramas、Kakao Roadview 与 NAVER 街景。在本土市场都是很强的产品，但公开的开发者接口是播放器或 SDK——所以除非另行商务协商，它们在项目里应当作为展示层与核验层来用。
• 开放众包平台：Mapillary 与 KartaView。由贡献者上传影像，配有真正可用的开发者 API，采用开放或署名类许可，因此再分发成为可能，而覆盖则变得不可预测。
• 专业测绘供应商：Cyclomedia 及同类公司。经过标定的采集，同时获取 LiDAR 与深度数据，按合同覆盖指定区域交付，目标是「可量测」，而不是廉价的全球广度。

选型总表

第三列才是决定性的一列。它描述的是第三方接口的性质——查看器、影像/数据 API，还是商业授权数据——而不是「有没有影像」。

逐个平台来看

Google 街景：文档化影像接口最完整的一家

在中国大陆以外，许多项目默认先看 Google，因为它把较广的道路覆盖与两套彼此独立的文档化影像接口放在了一起。Street View Static API 接收坐标或全景 ID，返回一张平面透视 JPEG，朝向、俯仰和视场角都由你控制。多个固定朝向可以描述采样点周边、用于测量，但这个端点不会把原始的等距柱状全景直接交给你导出。与之配套的元数据端点用来判断某个位置到底有没有影像，免费、且不消耗影像配额——正是它让「先做覆盖审计再花预算」这件事变得便宜。

第二套接口知道的人少得多。Maps Tile API 里包含一组 Street View Tiles 端点，这是 Google 文档化的、最接近全景级访问的一层。流程是：先以 street view 作为 mapType 开启会话，再解析全景 ID，然后取影像。其中批量解析方法接收一组坐标——文档明确单次请求最多 100 个位置，并可附带搜索半径——为每个位置返回一个全景 ID，查不到的位置返回空字符串。这一个上限就决定了大规模采样任务的形状：十万个采样点，在取到第一个像素之前，就已经至少是一千次请求。

• tiles 方法按瓦片返回全景，共六个缩放层级，从单张 512 像素的瓦片，到被切分成瓦片的完整尺寸全景。要重新拼回全景，需要一个查看器。
• thumbnail 方法针对一个全景 ID 返回非瓦片的 JPEG，朝向、俯仰、尺寸和视场角由你指定。Google 文档给出的尺寸范围是高 16 至 250 像素、宽 16 至 600 像素，所以它是预览用的接口，而不是分析分辨率的接口。
• metadata 方法接收全景 ID，或者坐标加半径，返回可用时的拍摄年月、全景尺寸、相机朝向 / 倾角 / 滚转、影像类型（室内或室外）、地址组成、相邻全景的链接，以及版权字符串。
• Google 明确说明全景 ID 是临时的，不应假定其在单次用户会话之外仍然有效；同时要求每个全景都必须展示元数据响应中的版权文本。这两条约束应当落进你的数据结构和界面，而不是写在脚注里。

Apple Look Around：很好看，但不是数据源

Apple 的街景产品在其覆盖的城市里表现很好，而且从 WWDC25 起也开放给了 Web：MapKit JS 新增了用户可以平移、前进的 Look Around 视图，以及一个渲染静帧、点击后进入完整体验的 Look Around 预览元素。但这两者都是展示面，设计目标是把 Apple 的影像放在 Apple 自己的组件里呈现给人看。

百度全景：中国大陆的第一来源

Google 在中国大陆基本没有街景覆盖，因此国内平台是这里的现实选择，而百度通常是团队最先想到的一个。它有文档化的全景静态图服务，按坐标或场景 ID 返回一张渲染好的视图——这正是采样流水线真正调用的那个接口。

有两件事需要提前规划。其一，坐标使用 BD-09 而非 WGS 84，每个采样点进去时要转换、结果出来时要转回来；跳过这一步的项目，点位会整体偏离几十米，而这个偏移足以把一处立面归到马路对面去。其二，接入要通过中国大陆开发者账号，有自己的认证与配额规则，而且接口目录不止一次发生过调整。请在立项阶段确认当前可用的服务、参数、你的日配额与并发配额，以及适用条款，而不是默认去年那套仍然成立。

历史影像的可获取性也远不如 Google 的接口稳定。在中国大陆做时序变化研究，应当先用抽样核实平台针对你那几个具体片区实际返回了什么，再确定范围，而不是先做承诺。

腾讯街景：中国大陆的第二来源

腾讯位置服务至今仍有与百度并行的街景静态图 API，而两家一起用，比单用任何一家都更有价值。影像接口接收尺寸、坐标或场景 ID，以及可选的偏航角与俯仰角，返回渲染好的 JPEG；文档给出的尺寸上限是宽 960 像素、高 640 像素——所以应当把它当作采样与指标计算的接口，而不是高分辨率立面影像的来源。

对流水线更有意思的是场景点吸附接口 getpano。给定坐标与半径（文档说明最大值与默认值均为 200 米），它返回最近的场景 ID、吸附后的坐标，以及一段简短描述（例如所在道路名）。这就是中国大陆版的覆盖探针：在花掉一次影像请求之前，它就告诉你这个采样点有没有影像、相机实际站在哪里。坐标使用腾讯自己的坐标系，因此需要与百度同样严格的转换纪律，只是换一套转换参数。

Yandex Panoramas：区域性的本土强者

在俄罗斯及部分周边地区，Yandex 是拥有实质街景与航拍全景覆盖的那个平台。它公开文档化的东西是一个播放器：JavaScript 全景 API 提供 locate 调用，接收一个坐标、搜索最近的全景，并解析成一个携带元数据的全景对象——名称、地面或航拍类型、绑定坐标、几何以及瓦片信息；再由 Player 类把这个全景嵌入到指定的 DOM 元素中。Yandex 同时说明，全景 API 的请求是计费的。

这套组合让 Yandex 在两件事上很好用，在第三件事上不适用。它适合把区域性街景嵌入产品，也适合做逐点的覆盖核验——一次 locate 没有解析出结果，对你的采样点来说就是一个真实的答案。但它不是文档化的批量影像出口，不要按此去做方案。

Kakao Roadview：韩国，需协商使用

Kakao Roadview 是韩国两个成熟街景产品之一。它的地图 SDK 允许你按全景 ID 或按坐标请求 Roadview，并设定注视位置、水平旋转与俯仰，还有一个两段式搜索半径：文档给出的默认搜索半径为 100 米，在更近处找不到数据时扩展到 400 米。请求成功后会返回全景 ID、位置，以及一组按日期区分的 Roadview 条目——这正是韩国项目获取同一地点更早影像的机制。

关键的一句话写在官方文档里：Roadview 的使用需要单独协商。所以应当把 Kakao 当成展示型与合作型来源。在条款谈定之后，它对韩国市场产品或按日期做视觉比对都是很好的选择；但它不是开放的批量下载接口。

NAVER 街景：以查看器为主

NAVER 的 Maps API 通过 Naver Cloud Platform 提供，其街景与航拍全景由一个随地图一起加载的 panorama 子模块开放。应用需要使用 Naver Cloud 的凭据进行认证，并登记允许调用该服务的域名。与 Kakao 一样，官方路径是查看器：你把全景定位好，用户在其中浏览，影像始终留在 NAVER 的组件里。

对韩国研究区域，诚实的方案是：用 NAVER 和 Kakao 做核验与呈现，处理需求由开放影像或自采来满足；如果交付物确实必须用到它们的像素，就尽早启动授权沟通。请在立项阶段到 Naver Cloud 文档核对当前的模块名、认证方式与配额——这是一个在持续维护中的平台，接口会变。

Mapillary：开放覆盖，配真正的 API

Mapillary 是由贡献者上传的街景影像，并配有一套像样的开发者 API。Graph API 支持按外接矩形查询，返回影像 ID、所属序列、拍摄时间戳、罗盘方位角、几何位置、多种分辨率的缩略图地址，以及平台侧计算出的识别结果与地图要素。覆盖瓦片与矢量瓦片则让你可以直接绘制或审计「哪里有影像」，而不必逐条拉取影像记录。对于贡献者活跃的研究区域，它是本文这些平台里编程调用最省事的一个。

# Mapillary Graph API: bounding-box query for imagery metadata.
# The token identifies the application. Review Mapillary's current terms and
# keep the required attribution with any image or extracted data you publish.
curl -G "https://graph.mapillary.com/images" \
  --data-urlencode "access_token=$MAPILLARY_TOKEN" \
  --data-urlencode "bbox=-73.9860,40.7500,-73.9750,40.7570" \
  --data-urlencode "fields=id,sequence,captured_at,compass_angle,geometry,thumb_2048_url" \
  --data-urlencode "limit=500"

许多研究项目偏爱它，原因在授权：Mapillary 影像一般以「知识共享 署名-相同方式共享」类许可提供，在保留署名的前提下允许再分发。但相同方式共享的条件在你的场景里究竟波及到哪一层——你再发布的影像、衍生的指标表、还是训练出来的模型——需要对照 Mapillary 当前条款逐项确认；若交付物是商业产品，还应当征求法律意见。既不能想当然地认为所有衍生成果都必须采用同一许可，也不能想当然地认为都不必。

真正需要留意的地方在贡献者，而不在 API。覆盖跟着人实际走过的路线走，所以在通勤主干和绘图活动覆盖过的区域很密，隔两条街就是空白。采集设备从挡风玻璃后的手机到经过标定的 360° 相机都有，这会让相距几米的两张影像在分辨率、镜头几何、曝光和安装高度上完全不同。时间戳是逐张的，同一个街区内跨度可能有好几年。这三点每一点都必须变成流水线里的一个筛选条件和一个记录字段，而不是报告里的一句脚注。

KartaView：轨迹、帧，以及一扇敞开的门

KartaView（原 OpenStreetCam）是另一个开放平台：由贡献者上传带地理标记的行车轨迹，并提供面向序列及其有序帧的端点。其影像以「知识共享 署名-相同方式共享 4.0」发布，因此在保留署名并延续相同方式共享条件的前提下可以再分发。由于影像沿着贡献者实际开车或骑行的路线分布，它的覆盖不均匀程度是厂商车队采集所没有的——一条覆盖极好的走廊，旁边可能就是一整片完全空白的街区。

接入门槛低得少见。KartaView 的官方 FAQ 说明，多数端点公开可用、无需认证；只有上传影像、访问用户资料、管理自有内容，以及提高频率上限时才需要访问令牌——文档给出的数字是带令牌每小时 1000 次请求，不带令牌 100 次。在为任务估算规模之前请以官方 FAQ 的当前数值为准，但可以按这个形状来规划：一个令牌能把慢速的踩点脚本变成可行的城市级采集，而「按小时计」的频率上限意味着决定节奏的是你的调度器，而不是带宽。

作为补偿，轨迹本身就是一个真正的序列：帧沿着一条线有序排列并带时间戳，在走廊资产盘点和重复路线比较中，可能比吸附到路网的全景点阵更合适。帧间距仍要实际测量，不能默认很密——它完全取决于贡献者使用的设备和采集过程。

Cyclomedia：专业测绘，按合同交付

以上所有平台，本质上都是把面向消费者的影像挪用到分析场景。Cyclomedia 属于另一个类别：一家测绘公司，其车辆采集经过标定的 360° 影像并同步获取 LiDAR，服务对象是那些需要「从照片上量测」而不只是「看照片」的机构。它的 Street Smart 查看器把 360° 影像、LiDAR 数据、地图与 GIS 图层以及深度图放进同一个浏览器工作台，并提供线长、面积、高度与净空的量测工具、沿路线的走廊式浏览、GIS 图层叠加，以及可分享的视图与可导出的报告素材。

面向集成的开发者接口也是有文档的，但全部需要合同项下签发的凭据。一个覆盖范围 Web 要素服务（以 OGC WFS 形式发布，支持外接矩形与距离过滤，输出 GML 或 GeoJSON）告诉你哪些区域被采集过、采集于何时；一个拍摄点位服务给出相机的实际位置；全景渲染 API 则把影像送进应用。历史影像是这类产品价值的一部分，但你所在区域究竟存在哪些采集年份，属于需要与厂商在合同中确认的覆盖问题，不能凭假设。

当交付物是市政部门要据此行动的资产台账、需要有人签字确认的工程量测，或必须经得起质疑的保险与公共安全审查时，选这一类。当你需要的是横跨多个国家的低成本广度时，不要选它——它的定价与范围本来就不是为此设计的。

Bing Streetside：仅作为遗留系统看待

Bing Streetside 至今仍出现在一些旧教程里，通过影像元数据取 Streetside 瓦片的做法也还留有文档，所以偶尔仍会被写进方案。但微软自己的文档现在带着退役声明：Bing Maps for Enterprise 已弃用，并已对免费（Basic）账户客户停止服务；企业账户客户可继续使用至 2028 年 6 月 30 日，在此之前需将 REST API 与 SDK 迁移到 Azure Maps。

覆盖范围与历史深度是两个属性

一个平台完全可能今天覆盖了某条街，却没有它三年前的可用记录，而后者恰恰是大多数变化研究真正需要的。请把当前覆盖和历史深度当成两列来看，永远不要合成一列。另外请注意，下表的历史一列描述的是「通过第三方接口能够触及到什么」——一个允许用户在手机上往回翻历史影像的消费级应用，和一个能为你的流水线枚举这些影像的端点，不是一回事。

决定权在授权条款，而不在 API

• 通过商业 API 获得的平台影像，通常受条款约束，限制缓存、存储时长与再分发。这种情况下你的交付物一般是衍生指标加一份影像清单，而不是一个影像库。
• 以「知识共享 署名-相同方式共享」类许可发布的开放影像可以再分发，但署名必须延续到你的产出中；至于相同方式共享的条件在你的衍生数据上究竟延伸到哪一层，应当明确确认，而不要往任何一个方向想当然。
• 仅有查看器的平台——Apple、Yandex、NAVER，以及未达成协议时的 Kakao——完全可以合法地嵌入使用，也可以用于覆盖核验。提取是另一场需要与厂商谈的对话，结果要么是拿到授权，要么是换一个来源。
• 专业测绘供应商卖的是合同，不是 API 密钥。范围、区域、期限与许可用途都需要谈定，启动更慢，但合规边界要清楚得多。
• 自行拍摄的影像同时解决上述问题，并把拍摄时间固定在你选定的时刻。若只是一条走廊，自采往往比谈授权更划算。
• 无论来源如何，都要在清单里逐张记录授权信息。一份日后无法还原来源的数据集，日后也就无法公开发布。

同一项目里混合多个来源

大多数真实研究区域都需要不止一个来源，把它们组合起来是合理的设计，而不是一种妥协。真正毁掉分析的，是让来源悄悄混在一起：相机、安装高度、分辨率与拍摄月份的差异，对指标造成的偏移常常大于你想要检测的那些差异本身。解决办法是结构性的：能归一的全部归一，不能归一的全部记录下来，然后把「平台」本身当成一个可以控制的变量。

1. 把几何统一到一个坐标参照系，通常是 WGS 84；BD-09 与腾讯坐标在进出时各自转换，并同时保存采样点和平台返回的相机吸附位置。
2. 跨来源固定采样几何：相对道路的同一组朝向、同一俯仰、同一视场角、同一输出尺寸。在 90° 视场角下算出的指标，和在 120° 下算出的并不可比。
3. 逐张记录来源平台、平台原生的影像或全景 ID、拍摄日期、许可，以及抓取时间戳。部分平台明确说明其 ID 是临时的，所以要把它当作来源溯源信息存，而不是当作稳定主键。
4. 为每张影像加一个质量等级——分辨率档位、遮挡、曝光、拍摄设备是手机还是标定过的相机——并在它变成隐性偏差之前先用它做筛选。
5. 把来源与质量作为控制变量放进模型或对比中，然后带着它们重跑你的主要结论。如果某个结论只有在忽略混源时才成立，那它就是一个关于混源的结论。

我们见到的工作里，大部分落在三种组合上。中国大陆以外：用一个厂商车队平台做系统性覆盖，再用 Mapillary 或 KartaView 去补车队漏掉、或上次拍摄年代过久的走廊。中国大陆境内：让百度与腾讯在同一套采样框上作为两个独立探针运行，把单一平台的盲区从一个看不见的缺口，变成一个可测量的分歧。在韩国、俄罗斯等以查看器为主的市场：用本土平台做核验与呈现，可处理的影像则由开放来源、谈定的授权，或在最关键走廊上的自采来提供。

一条简短的选型规则

1. 研究区域在中国大陆：百度与腾讯一起用，并从一开始就把坐标转换和双源交叉核验纳入设计。
2. 中国大陆以外的跨国比较：选 Google，按其条款与计费模式确定范围，并先用免费的元数据端点做审计。
3. 必须再分发影像本身：评估 Mapillary 或 KartaView，并逐项核对当前条款、署名要求和具体素材所附许可。
4. 需要有人签字确认的量测——资产尺寸、净空、状况评定：为 Cyclomedia 这类专业测绘供应商留出预算，或者用已知相机几何自己去拍这条走廊。
5. 韩国、俄罗斯或其他以查看器为主的市场：用本土平台做核验与嵌入，可处理的影像另找来源。
6. 对方明确点名要 Look Around：先确认项目获得了哪些授权能力，再确定范围，并为同一区域准备备选来源。
7. 接手了建在 Bing Streetside 上的遗留系统：先记录清楚，再规划迁移；没有一对一的继任者。
8. 所有平台都漏掉、或上次拍摄年代过久到无法回答你问题的走廊：自己去拍。

平台上已有的街景，我们都能按需采集

上面的对比是在画这张市场地图，不是在列我们做不到的事。Google、Apple、百度、腾讯、Yandex、Kakao、NAVER、Mapillary、KartaView、Cyclomedia，以及客户点名的其他街景平台：只要影像已经存在于该平台，我们就可以按你的需求取回来——朝向、年代、密度，城市级或全球级都可以。

• 上面每一个平台，以及你另外指定的来源。你给出平台和范围，我们返回该平台在这个范围内实际持有的影像与元数据。
• 城市级采集是常规交付，不是极限目标：整座都会按规则格网或沿路网抽样，带质量控制，以及逐张记录来源的影像清单。
• 全球级任务同样可以做：一个国家、一组国家，或全球一批城市的抽样。流水线相同，只是体量不同。
• 大规模时单价可以压得很低。大批量街景按生产任务计价，而不是按零售 API 调用堆出来，所以城市级乃至全球抽样，通常比团队自己试过一遍之后预想的便宜。