企业官网建设流程全解析

“天地图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。这个报错我在不同项目里遇到过至少五六次，原因其实就那么几类，按下面这个顺序排，基本十分钟内能定位。

除了301001，实际开发中还常遇到另外几类返回，比如配额超限、权限不足、域名校验不通过。这些的提示文字通常比较直白，具体返回码建议以官方开发者文档为准，别照着网上的老帖子硬套，服务端的规则时不时会调整。

提示：排查这类问题时，第一件事是把完整的请求URL打印出来，包括所有查询参数。很多人只看代码里的变量，不看最终拼出来的字符串，结果参数重复拼了两次或者多了个问号，肉眼根本看不出来。

3.3 常用服务地址与调用示例，直接抄

天地图的瓦片服务遵循OGC WMTS标准，地址格式固定，主要变量是图层名、投影类型和切片行列号。底图服务按投影分两套：带_w后缀的是Web墨卡托（EPSG:3857），带_c后缀的是经纬度直投（对应CGCS2000地理坐标系）。网页端和大多数Web框架用_w这套最省事。

常用的图层名对照如下：

标准KVP方式的请求长这样：

https://t0.tianditu.gov.cn/vec_w/wmts?SERVICE=WMTS&REQUEST=GetTile&VERSION=1.0.0&LAYER=vec&STYLE=default&TILEMATRIXSET=w&FORMAT=tiles&TILEMATRIX={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换成带SERVICE=WMTS&REQUEST=GetCapabilities的完整形式再试一次，这个技巧解决过我好几次“连不上但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 问题速查表：对号入座，先看现象

下面这张表是我这几年积累下来的对照表，遇到问题先扫一眼现象，能省掉大量重复排查的时间。

5.2 几个没人会写在文档里、但我踩过坑的细节

第一，历史影像的季节差异比分辨率差异更容易骗人。同一块地，夏天是绿的，冬天是黄的甚至裸土，看起来像“地表发生了剧烈变化”，实际上什么都没变。做变化检测的时候，尽量比较同一季节或相邻季节的影像，跨季节对比一定要在报告里注明植被物候的影响。我在一个撂荒地监测的项目里就吃过这个亏，算法报出来的变化图斑，人工核查后发现一半以上是季节性差异。

第二，子域名轮询别省。这个改动只有几行代码，收益却最直接。我见过有人为了省事固定用t0，结果在并发稍微高一点的场景下，地图加载速度直接掉一半。前端项目里，这属于投入产出比最高的优化之一。

第三，key一定要做后端中转。纯前端项目里把tk写在JavaScript里，等于公开了。虽然浏览器端key有域名白名单保护，但配置不当或者被人抓包后，风险还是存在。稳妥的做法是把瓦片请求通过自己的服务端代理一层，tk放在服务端配置里，前端只请求自己的域名。代价是增加了一点服务器开销，收益是可控性和可维护性。

第四，截图留证要截全。这个前面提过，但值得再说一遍。比例尺、坐标、时相标注，缺一样，这份材料在正式场合的说服力就打折。我现在做核查材料，固定流程是三张图：起始时相、结束时相、变化范围标注图，每张都带完整界面信息。

第五，配额要提前算。一个用户浏览一屏地图，可能触发几十次瓦片请求。如果你有几十个并发用户，每天的调用量很容易上到几万甚至几十万次。个人开发基本不用管，但项目上线前一定按并发用户数乘以平均会话时长估算一遍，把这个数字和key的配额对一下，不够就提前申请调整。

第六，多时相影像的判读结论，最好留一份人工复核记录。影像判读有主观性，同一个图斑，两个人可能一个判成“新增建设”，一个判成“地表翻耕”。把判读标准、判读人、判读时间记下来，后面别人质疑的时候你拿得出依据。这份记录不用很正式，一张带勾选列的表格就够了，但它在项目复盘和成果验收时的作用远超它的制作成本。

最后说个容易被忽略的扩展方向：把多时相影像和自己业务数据结合，往往能挖出比单纯看图更大的价值。比如把你手上的图斑数据逐年套合到不同时相的影像上，统计每个图斑在各年份的地表状态变化，做出来的时间序列比单张对比图信息量大得多。这个思路我在做区域土地利用变化分析时用过，效果比逐块人工判读好不少，后续如果有兴趣，这块可以再单独展开聊。