“天地图2024版”正式启用这个消息我是从一个做自然资源调查的老同学那里听到的。他手里压着一个2020年立项的土地复垦项目甲方验收时要“同一地块不同年度的影像对比说明”。放在两年前这种活儿只能翻自己硬盘里的存档或者去买商业影像一幅图几百到上千不等预算紧的项目根本扛不住。他这次甩给我的链接是天地图新上线的多时相影像专题——不用装插件不用付费浏览器里拖一下时间轴同一个位置的历史影像就出来了。我当晚把这个专题从头到尾跑了一遍顺手把天地图API调用和ArcGIS加载的老流程也重新对了一遍发现2024版这块的改动比我预想的要实在。这篇就把天地图、多时相影像、历史卫星影像这几件事一起讲透网页端怎么查、怎么对比、怎么留证开发端key怎么申请、301001这个报错怎么排桌面端ArcGIS和ArcGIS Pro又该怎么把服务挂上去。写得比较细新手照着做能跑通有基础的朋友可以直接跳到第3、第4章看接口和服务配置。1. 天地图2024版与多时相影像这次更新到底改了什么1.1 多时相影像到底“多”在哪从一张快照到一条时间轴传统意义上的在线底图本质上是一张快照。不管你今天打开还是下个月打开看到的都是同一个时间生产的那批瓦片顶多隔一年半载换一次版本老版本就直接下线了。你在上面看到的地块、道路、建筑反映的是“出图那一刻”的状态之前是什么样平台不会告诉你。这就是很多人做核查时最头疼的地方——事后的现场已经变了你手上没有能自证的影像。多时相影像解决的就是这件事。它把同一片区域、不同时间生产的影像分别切成瓦片按时间维度分层组织前端展示的时候只切换瓦片数据源位置、比例尺、坐标系全部保持一致。你平移、缩放的时候看到的是同一个空间范围只是地表的样子换了一个年份。技术上讲这比做一套全新的地图引擎要简单得多难点全在数据侧得有足够长的历史存档、得把不同来源不同分辨率的影像统一到同一个投影和切片规则下、还得处理云量、色差、季节差异带来的视觉跳变。天地图2024版首次把这块能力单独做成专题开放出来意义在于把过去只存在于内部数据池里的历史影像变成普通用户点几下就能用的东西。我实测下来专题里的年份是一段一段给的不是每个区域都有连续覆盖具体能选到哪些年份、分辨率到什么程度不同地区差异挺大用之前最好先在你关心的那个位置试一下。这一点我后面第2章会讲怎么快速判断。1.2 这次更新解决的三个真实痛点第一个痛点是成本。商业历史影像按景或按面积计价一个县域范围、要三四个年份报价很容易上到五位数。对做前期调研、写论文、做内部汇报的人来说这个门槛太高。天地图把历史影像放到公共专题里等于把“看一眼过去长什么样”这件事的成本降到了零只有需要正式成果出图、需要更高分辨率的时候才值得考虑付费渠道。第二个痛点是效率。以前比对一个地块的变化常见做法是开两个窗口、两个平台、甚至两个软件手动对齐位置和缩放级别稍微一挪就错位了。多时相专题把切换做成了同一个视图内的操作时间轴一拉位置纹丝不动判读的注意力可以全部放在地物本身而不是浪费在“对齐”上。第三个痛点是留证的规范性。做过外业核查的人都懂截图容易证明这张截图是哪一年、哪个位置、什么比例尺很难。以前的截图往往只有画面没有时间标注验收的时候被打回来是常事。多时相专题界面上会带出当前影像的时相信息配合比例尺和坐标截出来的图本身就构成了可追溯的链条这一点是它被很多做审计、做验收的人看重的原因。具体的应用场景我列几个自己接触过的土地复垦与占补平衡核查对比立项前、施工中、验收后三个时点的地表状态确认复垦范围是不是真的种上了、有没有撂荒。违法用地疑似图斑初筛拿两期影像快速扫一遍新增的硬化地面、厂房、堆场基本一眼能看出来。工程项目进度佐证施工便道、临时堆土场的位置和清理情况历史影像比照片更有说服力。灾害与突发事件评估洪涝、山火、滑坡的范围变化靠前后两期影像叠加能快速圈定影响区。城市扩张与土地利用变化研究写论文、做课程作业的时候免费且可追溯的历史影像是很实在的数据来源。1.3 先泼盆冷水多时相影像不是万能的用得多了就会发现几个必须提前知道的边界不然容易在正式场合翻车。它不是实时影像。最新一期也是生产出来之后才上线的跟“今天的现场”之间有时间差做执法取证的时候千万不要把它当成现势资料。它不能作为权属依据。影像上看到的界线、范围只能作为参考和线索真正的权属认定还得回到审批文件和实地测量数据上。我在项目上见过有人直接拿影像描边界交差被打回来的例子不止一次。它的分辨率不是统一的。早年影像受限于当时的卫星条件地面分辨率可能只有几米判读小地物会吃力。相邻两年之间分辨率不一致视觉上会有明显的“糊—清”跳变这是正常的不是平台出问题了。它的时相分布不均匀。同一区域可能2020年有一期、2022年有一期中间空着也可能某一年的影像只有部分覆盖。做连续变化分析之前先在专题里把可用年份列出来别默认它每年都有。2. 网页端实操历史影像查询与对比的完整流程2.1 从进入专题到锁定目标地块的六步走先把最常走的路径捋一遍这套流程我在不同项目里重复了几十次基本是稳的。第一步进入天地图官网首页在服务或专题入口里找到“多时相影像”这一项。不同时期的界面布局会有调整但入口一般都在顶部导航或者首页的服务卡片区找不到就直接用站内搜索。第二步等底图加载出来之后先把视图定位到你的目标区域。定位方式有两种一是在搜索框里输入行政区名称或地名直接跳过去二是如果你手上有坐标可以直接输入经纬度定位这个更精确后面2.3会单独讲。第三步调整缩放级别。这一步很多人忽略其实很关键。多时相影像的瓦片是分级切片的放到太低级别看不出地物放到太高又可能超出某一期影像的最大切片级别出现“空白”或者“糊成一片”。我的习惯是放到能看清目标地物轮廓为止通常城郊地块在15到17级之间比较合适。第四步找到时间轴或时相选择控件。2024版这块做得比较直观通常会以年份或期次的形式列出来有的版本还带一个拖动滑块。点一下就能切换切换过程中注意不要平移视图否则位置会变。第五步逐期对比。把几期影像在同一视图下快速来回切几遍地表的变化会很直观地跳出来——新增的建筑、消失的水塘、颜色从绿变黄的地块切两次就记住了。第六步截图或导出留证。截图的时候一定要把界面上的比例尺、坐标信息、时相标注一起截进去不要只截中间那块图。需要出一份说明材料的话把几期影像并排放在一起标注清楚各自的时相和获取日期形成一份完整的对比说明。2.2 三种对比手法卷帘、闪烁、并排各有各的场合光靠手动切换其实已经能解决大部分问题了但遇到“变化很小、需要精细判断”的场景还是有更趁手的办法。卷帘对比是可视性最好的一种画面中间出现一条分割线线左边是A期影像线右边是B期影像你可以拖动分割线左右移动同一位置的两期影像就并排贴在了一起。它的优势是能直观看出边界的位移比如岸线后退了多少、建筑外扩了多少。判断得很细的场景比如河道整治前后、填海范围变化用这个最合适。闪烁对比是效率最高的一种两期影像自动交替显示靠视觉暂留把差异“闪”出来。大范围扫查的时候特别好用一屏一屏地过有变化的地方会自己“跳”。缺点是截图留证不方便它更适合前期找线索找到可疑点之后再切回单期细看。并排对比是留证最规范的一种把两期甚至多期影像裁到同一个范围并列排布配上统一的图例、比例尺和时相标注。这个做法在正式报告里最容易被认可因为信息完整、可复核。做的时候注意统一范围和比例尺不要一个放大一个缩小那样对比没有意义。提示不管用哪种对比方式前提都是视图位置和比例尺保持一致。切换时相之前先记下中心点和当前级别或者用浏览器的截图工具先拍一张参考避免来回找位置浪费时间。2.3 坐标拾取的正确用法与坐标系陷阱坐标拾取这个功能看着简单实际是翻车率最高的一个环节跟它相关的坐标系问题能把人折腾到怀疑人生。先说基本用法。在天地点位上点击想取的位置工具会给出该点的经纬度通常是十进制度格式也可以切换成度分秒。这个值一般在CGCS2000或WGS84的经纬度体系下两者日常使用差别在米级以内做常规的定位查询、粗略上图完全够用。真正的坑在“拿来干什么用”上。你拾到的经纬度是地理坐标系下的角度值而你在ArcGIS或者Web地图里看到的图层如果是Web墨卡托EPSG:3857投影那是平面坐标单位是米。这两个东西不能混。直接把手拾的经纬度填进一个要求Web墨卡托坐标的输入框位置会偏到几百公里开外而且偏得毫无规律非常容易被误判成“数据错了”。判断方法很简单看目标系统的坐标系标识或者看输入的坐标值长什么样。经纬度是“小数、范围在-180到180和-90到90之间”Web墨卡托是“大数、单位米、数值动辄几百万”。两者一眼能分。还有一个容易忽略的点拾取精度受你当前缩放级别影响。放得太小点一下误差可能几十米做地块级别的核对至少放到16级以上再去点。注意在正式材料里引用坐标一定要写清楚坐标系名称和版本比如“CGCS2000地理坐标系”。只写一串数字接收方按什么坐标系解读全靠猜出了问题说不清责任。3. 开发者必看天地图API的Key申请与301001报错排查3.1 Key的类型、配额与绑定逻辑先把规则弄明白天地图的服务调用全部依赖一个叫tk的令牌中文习惯叫key。这个key不是随便申请一个就能用所有服务它有明确的类型划分和配额规则这两点决定了你后面会遇到哪些报错。从类型上看最常打交道的分为“浏览器端”和“服务端”两类。浏览器端key是给前端直接调用的场景准备的比如网页地图、Leaflet或者OpenLayers里加载底图这种key通常要绑定域名防止被别人拿去白用。服务端key是给后端程序、桌面软件、脚本调用的不绑定域名但配额和调用频率的约束方式不一样。选错了类型最常见的表现就是“本地测试好的部署上去就不出图了”。从配额上看每个key在单位时间内有调用次数上限也有总量限制。个人开发、学习用途基本够用商业项目或者高并发场景就要提前估算不然跑着跑着突然不出图排查半天才发现是配额用完了。申请流程本身不复杂官网注册账号、完成实名认证、进入控制台或者开发者中心、创建应用、选择应用类型、填写用途说明、提交后拿到一串tk。关键在于创建应用时选的类型要跟你的实际使用场景对上这个选择后面改起来麻烦前期想清楚。3.2 301001非法Key一份能直接照着排的清单返回码301001含义就是非法key。这个报错我在不同项目里遇到过至少五六次原因其实就那么几类按下面这个顺序排基本十分钟内能定位。排查项典型现象处理方式key拼写或截断复制时带上了空格、换行或者少了一段从控制台重新完整复制粘贴后检查首尾参数名写错用了key、token、appkey等非标准参数名参数名必须是tk大小写敏感key尚未生效刚创建就调用服务端还没同步等几分钟后重试一般会自行恢复key类型不匹配浏览器端key被用在服务端脚本里反之亦然回到控制台按场景重新创建对应类型的keykey被禁用或删除之前能用突然全部请求失败检查控制台应用状态确认没有被停用域名白名单不匹配本地能跑部署到正式域名后失败把正式域名加入白名单注意带上端口和协议服务地址与key不配套部分图层能出图部分不能确认该服务是否包含在当前key的授权范围内除了301001实际开发中还常遇到另外几类返回比如配额超限、权限不足、域名校验不通过。这些的提示文字通常比较直白具体返回码建议以官方开发者文档为准别照着网上的老帖子硬套服务端的规则时不时会调整。提示排查这类问题时第一件事是把完整的请求URL打印出来包括所有查询参数。很多人只看代码里的变量不看最终拼出来的字符串结果参数重复拼了两次或者多了个问号肉眼根本看不出来。3.3 常用服务地址与调用示例直接抄天地图的瓦片服务遵循OGC WMTS标准地址格式固定主要变量是图层名、投影类型和切片行列号。底图服务按投影分两套带_w后缀的是Web墨卡托EPSG:3857带_c后缀的是经纬度直投对应CGCS2000地理坐标系。网页端和大多数Web框架用_w这套最省事。常用的图层名对照如下图层名内容说明vec矢量底图路网、水系、居民地等线划要素cva矢量注记配合矢量底图的地名标注img影像底图卫星或航空影像cia影像注记配合影像的地名标注ter地形晕渲地形起伏表达cta地形注记配合地形的地名标注标准KVP方式的请求长这样https://t0.tianditu.gov.cn/vec_w/wmts?SERVICEWMTSREQUESTGetTileVERSION1.0.0LAYERvecSTYLEdefaultTILEMATRIXSETwFORMATtilesTILEMATRIX{z}TILEROW{y}TILECOL{x}tk你的tk也可以换成更简洁的RESTful路径写法可读性更好https://t0.tianditu.gov.cn/img_w/wmts/img/default/w/{z}/{y}/{x}?tk你的tk注意{z}/{y}/{x}的顺序RESTful模板里是先层级、再行、再列跟KVP参数里的书写顺序一致写反了会出现图片错位或者直接404。子域名方面天地图提供了t0到t7共八个节点。浏览器对同一域名的并发连接数有限制地图一屏要加载几十张瓦片如果全部走t0很容易卡住。前端代码里一般用一个简单的取模来轮询const getTiandituUrl (layer, z, x, y, tk) { const sub Math.floor(Math.random() * 8); return https://t${sub}.tianditu.gov.cn/${layer}_w/wmts/${layer}/default/w/${z}/${y}/${x}?tk${tk}; };这个小改动对加载速度的提升非常明显尤其是缩放和拖动的时候。我早期做的一个内网地图系统没做子域名轮询用户反馈“地图一顿一顿的”加上之后就顺了。4. 桌面端集成ArcGIS与ArcGIS Pro加载天地图完整步骤4.1 ArcMap或ArcGIS 10.x 添加WMTS服务的操作路径桌面端加载在线底图本质上是把天地图当成一个标准的WMTS服务器挂进来不需要装任何插件。第一步打开ArcMap或ArcGIS Desktop先建一个空白地图文档把数据框的坐标系设置好。这一步很多人跳过后面出问题再回头改很麻烦。如果你的目标图层是Web墨卡托数据框也设成对应的投影坐标系。第二步通过“添加数据”下拉菜单找到“添加WMTS服务器”或者从Catalog窗口里找到“GIS服务器”节点右键新建一个WMTS连接。第三步在URL栏里填入服务地址。这里填的是服务根地址不包括具体的图层路径形如https://t0.tianditu.gov.cn/img_w/wmts?tk你的tk有些版本会更进一步要求能力文档地址如果第一次连接失败把URL换成带SERVICEWMTSREQUESTGetCapabilities的完整形式再试一次这个技巧解决过我好几次“连不上但URL明明没错”的问题。第四步连接成功后服务器下面会列出这个服务里可用的图层。天地图的一个服务节点通常只暴露一个图层所以要加影像底图就连img_w要加注记就连cia_w分别连接、分别添加。想同时要底图和注记就重复一遍上面的流程。第五步把添加进来的图层调整顺序。底图在下注记在上否则地名会被影像盖住。第六步设置可见比例范围。这是解决“放大之后一片空白”的关键。天地图的瓦片一般切到18级左右超过这个级别就没有数据了ArcMap在超范围的时候不会自动停止请求而是一直发请求拿不到东西表现就是图没了。手动把图层的最大可见比例卡在18级对应的比例尺附近问题就解决了。4.2 ArcGIS Pro 连接天地图的差异与注意点ArcGIS Pro 的界面逻辑跟ArcMap差别不小很多人第一次用会找不到入口路径其实在顶部功能区里。在“插入”选项卡下找到“连接”组选择“服务器”再选“新建WMTS服务器”弹出的对话框里填连接名称和服务器URL。填法跟ArcMap一致直接给服务根地址加tk。连接建立之后在“目录”窗格的“服务器”节点下能看到它展开就能把具体图层拖进地图。Pro里有一个很实用的能力是可以直接把WMTS图层当成普通图层处理设置透明度、混合模式、可见比例范围都在同一个图层属性面板里比ArcMap顺手不少。需要特别注意两点。一是坐标系自动匹配Pro比ArcMap聪明但仍建议你手动确认地图的坐标系跟服务一致尤其是你的项目里还有其他矢量数据要叠上去的时候不一致会导致视觉上偏移。二是关于地形图很多人问“怎么在Pro里显示天地图地形图”。地形晕渲的图层名是ter注记是cta服务地址把img_w换成ter_w就行操作路径完全一样加两层、调好顺序、卡好比例范围即可。注意企业内网环境调用天地图服务要先确认网络出口是否放通相关域名和端口。很多单位的内网安全策略会拦掉外部地图服务表现就是“家里能用办公室不能用”这种情况不要怀疑配置先找网络管理员。4.3 叠加顺序、坐标系与比例尺三个决定成像效果的细节图层顺序这件事看起来是小问题实际决定了图面能不能看。正确的顺序从下到上是地形晕渲或影像底图、矢量底图、注记图层、你自己的业务数据。注记一定要在业务数据下面否则你自己画的图斑会被地名盖得乱七八糟。坐标系不一致是另一个高频问题。如果你的业务数据是地方坐标系或者CGCS2000的高斯投影直接叠加在Web墨卡托的在线底图上位置会偏。正确的做法是先做一次投影转换把业务数据转到底图所在的坐标系下再叠加。转换的时候记得检查转换参数不同地区的高程异常和转换参数不一样直接套用别处的参数误差可能到十几米。比例尺与切片级别的对应关系也值得心里有个数。Web墨卡托在赤道处的分辨率0级是约156543米每像素之后每升一级减半。所以你在设置可见比例范围的时候可以大致反推15级大约是5米每像素16级约2.4米17级约1.2米18级约0.6米。知道这个你就能判断“我要看清一辆车还是看清一栋楼”从而决定底图需要到多少级、业务数据的比例尺该定在多少。再补一个实操细节多个在线图层同时加载的时候ArcGIS会并发发起大量请求如果key的配额不高很容易触发限流。我的做法是只加载当前分析必需的图层把注记层在不需要出图的时候关掉能省下不少调用量。5. 常见问题速查与实战避坑经验5.1 问题速查表对号入座先看现象下面这张表是我这几年积累下来的对照表遇到问题先扫一眼现象能省掉大量重复排查的时间。现象大概率原因处理方向返回301001非法keytk错误、参数名写错、类型不匹配按3.2清单逐项排部分图层能出图、部分不行不同服务用了不同key或授权范围不同统一key或确认授权范围本地正常、部署后失败域名白名单未配置在控制台添加正式域名放大后图面空白超出切片最大级别设置图层最大可见比例地图加载卡顿、一屏一屏出未做子域名轮询引入t0-t7轮询逻辑底图偏移几百米坐标系不匹配统一为同一坐标系地名被遮挡图层顺序错误注记层放到最上突然全部请求失败配额用尽或key被停用查控制台用量与状态历史影像年份不全该区域本身覆盖不全换范围或换时相查看相邻年份分辨率差异大影像来源不同属正常判读时注意区分5.2 几个没人会写在文档里、但我踩过坑的细节第一历史影像的季节差异比分辨率差异更容易骗人。同一块地夏天是绿的冬天是黄的甚至裸土看起来像“地表发生了剧烈变化”实际上什么都没变。做变化检测的时候尽量比较同一季节或相邻季节的影像跨季节对比一定要在报告里注明植被物候的影响。我在一个撂荒地监测的项目里就吃过这个亏算法报出来的变化图斑人工核查后发现一半以上是季节性差异。第二子域名轮询别省。这个改动只有几行代码收益却最直接。我见过有人为了省事固定用t0结果在并发稍微高一点的场景下地图加载速度直接掉一半。前端项目里这属于投入产出比最高的优化之一。第三key一定要做后端中转。纯前端项目里把tk写在JavaScript里等于公开了。虽然浏览器端key有域名白名单保护但配置不当或者被人抓包后风险还是存在。稳妥的做法是把瓦片请求通过自己的服务端代理一层tk放在服务端配置里前端只请求自己的域名。代价是增加了一点服务器开销收益是可控性和可维护性。第四截图留证要截全。这个前面提过但值得再说一遍。比例尺、坐标、时相标注缺一样这份材料在正式场合的说服力就打折。我现在做核查材料固定流程是三张图起始时相、结束时相、变化范围标注图每张都带完整界面信息。第五配额要提前算。一个用户浏览一屏地图可能触发几十次瓦片请求。如果你有几十个并发用户每天的调用量很容易上到几万甚至几十万次。个人开发基本不用管但项目上线前一定按并发用户数乘以平均会话时长估算一遍把这个数字和key的配额对一下不够就提前申请调整。第六多时相影像的判读结论最好留一份人工复核记录。影像判读有主观性同一个图斑两个人可能一个判成“新增建设”一个判成“地表翻耕”。把判读标准、判读人、判读时间记下来后面别人质疑的时候你拿得出依据。这份记录不用很正式一张带勾选列的表格就够了但它在项目复盘和成果验收时的作用远超它的制作成本。最后说个容易被忽略的扩展方向把多时相影像和自己业务数据结合往往能挖出比单纯看图更大的价值。比如把你手上的图斑数据逐年套合到不同时相的影像上统计每个图斑在各年份的地表状态变化做出来的时间序列比单张对比图信息量大得多。这个思路我在做区域土地利用变化分析时用过效果比逐块人工判读好不少后续如果有兴趣这块可以再单独展开聊。