企业官网建设流程全解析

做GIS的同行应该都清楚，DEM、DSM这类高程数据在本地怎么打开都容易，但要想发布成服务，供Web端、三维场景或者其他系统实时调用，往往一下就能难住一片人。我之前负责某山区数字孪生项目，里面最关键的一块就是把上万个瓦片的LiDAR高程数据处理成可持续稳定发布的ArcGIS影像高程服务。那段时间先后在ArcMap和ArcGIS Pro两条发布链路里来回切换，踩过不少坑，也积累了一些经验。这篇文章就把整套流程完整梳理出来，从数据格式、坐标系、NoData处理，到两种软件里的发布步骤、高程函数与缓存配置，再到常见的报错和排查思路，尽量做到看完就能照着干活。

1. 影像高程服务，到底解决什么问题

1.1 一个能动态读取海拔的服务长什么样

要理解"影像高程服务"，先把它拆成两半：一半是"影像"，一半是"高程"。

从影像的层面说，你发布的本质是栅格数据，所以走的底子是ArcGIS的影像服务。ArcGIS Server在发布影像服务时，会提供专门的REST接口，让客户端直接按范围取图像、按像素取值。从高程的层面说，这份栅格不是普通的三波段RGB照片，而是单波段浮点型数字高程模型DEM或数字表面模型DSM，每一个像素值代表该位置的海拔，单位通常是米。发布的时候，必须把这个"高程身份"告诉服务器。在ArcMap里，是通过勾选服务的"高程（Elevation）"能力；在ArcGIS Pro里，是直接把图层类型选为"高程图层（Elevation Layer）"。

发布出来的服务，客户端请求一个点或一条线，服务器能实时返回这个点的高程值，或者算出一条剖面线上的高程曲线；它还能在三维场景里被直接挂到"地表"的位置，作为所有对象的Z值来源。这也是它和普通影像底图最本质的区别。很多人一开始没想明白，以为把DEM用常规影像服务发出去就算完事，结果客户端只能看到灰蒙蒙的图，查询像素值返回的也不是海拔，问题就出在服务类型和高程能力没配对。

1.2 它和普通影像服务的关键区别

普通影像服务的核心任务是"好看"：把多波段数据用合适的渲染方式展示，客户端拿到的本质是颜色值；即使你去识别或者取像素值，拿到的也只是DN值，对大多数人来说不直接等于物理海拔。

高程服务要解决的是"可用"：服务器端需要保留原始浮点精度。常见的高程服务本质上仍然是一个影像服务，但带上了高程函数链。客户端可以做到的事情包括：

• 查询任意位置的海拔值，而不是单纯的颜色值
• 实时派生出坡度、坡向、山体阴影，不用预先算好几十层栅格
• 做剖面分析和填挖方辅助计算
• 在三维场景中直接作为地面高程源，给建筑物、管线等模型提供Z值基准

这个区别看着简单，实际影响很大。比如一个三维场景里，如果把高程服务错发成了普通影像服务，选地面高程源的时候就找不到它；就算手动指定了，服务器也只会按颜色值去解释Z，出来的地形完全是扭曲的。所以发布前第一件事，就是先想清楚你要的是哪种能力。

1.3 谁需要这类服务：三个典型场景

我实际接触过的项目里，影像高程服务主要在三个方向上发挥作用。

第一个方向是数字孪生和三维GIS。门户或三维地球客户端加载一个高程图层作为Ground，叠加倾斜摄影、白模、地下管线，所有对象都能正确落到地面上。这个场景最看重服务的稳定性和浮点精度，一旦高程源单位错了，整片地形会被抬高或压低，模型全悬空。

第二个方向是工程选线与剖面分析。电力线路、引水管道、公路路线选线时，业务系统前端画一条线，服务实时返回剖面曲线。以前的做法是把DEM导出成TXT让CAD读取，现在直接在线调服务，效率完全不是一个级别。

第三个方向是多业务系统共享。一个高程服务被多个系统共用，作为洪水淹没、日照分析、可视域分析的统一输入。这种共享场景下，服务的数据预处理必须做扎实，因为一旦发出去，就不是你自己一个人盯着看了。数据源乱、NoData没处理、坐标单位模糊，所有下游应用都会跟着出错。

2. 发布前的高程数据"硬条件"

2.1 格式、波段与类型：不是所有栅格都能当高程源

很多人发布失败，问题不在发布动作，而在数据本身不合格。我总结了一套发布前必须过的"体检项"。

数据类型必须是单波段浮点型（Float32或Float64），不能是8位整型、16位整型。如果是整型DEM，高程值一旦被四舍五入过，查询精度就会受影响。ArcGIS在发布高程图层时，经常会弹"数据集不是浮点型"之类的提示。这时候需要做一次转换，把数据转成32位浮点。

栅格不能带色彩映射表或属性表。有些DEM为了显示好看，被处理后带了ColorMap（色彩映射表）和Raster Attribute Table。带这些东西的栅格，ArcGIS很多时候不认作高程源。解决方法是使用Copy Raster工具，把颜色表移除，转成无属性表的纯浮点栅格。

波段数必须为1。多波段的高程栅格，比如从遥感影像提取后直接保存成RGB的DEM可视化产品，需要先提取出单波段再发布。

格式方面，TIFF、CRF、IMAGINE都是常见的，但个人建议尽量用TIFF或CRF。如果数据量达到几十GB甚至上百GB，CRF云栅格格式在ArcGIS Pro环境里发布效率更好，它能把大影像切分存储，服务器端按需读取。相比之下，老格式在并发访问时容易出现锁文件和读取瓶颈。

2.2 坐标系与单位：最容易埋雷的一环

坐标系和单位的问题，是我在所有高程项目中见过最多的坑。

高程栅格一般自带投影信息，发布前必须确认。这里有个很现实的情况：很多野外采集的DEM是UTM投影，但高程单位却是英尺；还有些数据是WGS84经纬度坐标，高程单位却是米。ArcGIS在处理三维拉伸时，必须明确知道XY和Z的单位，否则它会把1度当成1米来算，整个地表拉伸比例完全错误。

我建议的做法分两种。第一种，如果数据范围不大，直接把数据放进一个投影坐标系，比如UTM或高斯克吕格投影，Z单位设为米，这样发布后最省心。第二种，如果数据覆盖全省甚至全国，必须用地理坐标系发布，那就要在函数链或服务属性里明确设置Z单位换算参数，否则三维场景中表面会以度数被解释，高度方向完全失真。

发布前可以用一段ArcPy脚本快速体检数据：

import arcpy desc = arcpy.Describe(r"D:\dem\sx_dem.tif") print("投影：", desc.spatialReference.name) print("像元尺寸：", desc.meanCellWidth, desc.meanCellHeight) print("像素类型：", desc.pixelType) print("波段数：", desc.bandCount) print("NoData 值：", desc.noDataValue)

这段代码能帮你一眼看清数据最关键的五个属性。如果pixelType显示的是8 bit或16 bit，就说明数据精度可能不够；如果noDataValue是-9999这类异常值，后续必须专门处理。

2.3 用镶嵌数据集组织多幅DEM

如果项目里是单幅DEM，直接发布就行。但现实中的项目几乎都是几十上百个分幅，比如1:1万标准图幅DEM，每幅覆盖范围有限。这种情况下，不建议逐个发布后再在客户端拼接，也不建议做一个巨大的单幅TIFF，更合理的做法是使用镶嵌数据集。

镶嵌数据集的好处在于：它是管理海量影像和栅格数据的最佳容器，可以动态拼接、统一NoData、设置重叠处理方式，还能构建概视图来加速显示。发布时只需要指向这个镶嵌数据集，服务器端会自动按客户端请求范围去调取对应的分幅数据，效率和并发能力远超直接拼一个大文件。

创建镶嵌数据集并添加栅格的操作，用ArcPy也可以完成：

import arcpy arcpy.CreateMosaicDataset_management( r"D:\data.gdb", "sx_dem_mosaic", arcpy.SpatialReference("CGCS2000_3_Degree_GK_Zone_38") ) arcpy.AddRastersToMosaicDataset_management( "sx_dem_mosaic", "Raster Dataset", r"D:\dem_folder", "UPDATE_OVERVIEWS", "BUILD_PYRAMIDS", "BUILD_STATISTICS" )

在添加栅格的时候，有两个参数很重要：一个是NoData值设置，另一个是Source Type。如果这个镶嵌数据集是给高程服务用的，Source Type记得选"Elevation"，这样系统会按高程数据的规则来管理。建完之后，最好再执行一次Build Overviews，也就是构建概视图，否则大比例尺浏览时会感觉卡顿。

2.4 NoData、金字塔与统计信息处理

NoData处理是发布高程服务时最不起眼但最容易出问题的一步。DEM的数据空洞通常会用一组特殊值来标记，常见的是-9999、-32768、0。如果不告诉软件这些值是空值，发布后服务里就会把它们当成真实高程，三维场景中会出现一道道深不见底的裂缝，剖面分析时也会出现异常跳变。

处理办法很简单：在栅格属性里显式设置NoData值，或者在镶嵌数据集的属性中全局设置。发布前最好用"符号化"方式目视检查一遍，如果数据中出现了明显的极值黑洞，说明NoData没设置成功。

金字塔和统计信息影响的是服务发布速度和渲染效果。ArcGIS在发布时如果检测到栅格没有金字塔，会临时构建，这意味着发布过程会变得非常漫长。建议发布前提前构建，顺便把统计信息也建好：

arcpy.BuildPyramidsandStatistics_management( "sx_dem_mosaic", "", "", "1", "NEAREST", "2", "", "NONE" )

重采样方式选择NEAREST是为了保持高程值的原始性，如果用双线性或三次卷积，边缘会因插值而产生微小变化。像元采样间隔2代表金字塔每层缩小到上一层的1/2，这是常规配置。统计信息不建或没更新，会导致发布后默认拉伸渲染效果发灰，影响初步检查时的观感。

3. ArcMap 发布流程，从图层到Image Service

3.1 环境准备与数据源注册

如果你还在用ArcMap 10.x，发布高程服务前必须先处理好两件事：ArcGIS Server连接和数据源注册。

ArcMap是经典的桌面客户端，它发布服务的底层机制是连到ArcGIS Server站点，再把服务定义传上去。打开ArcCatalog，在GIS Servers里添加ArcGIS Server连接，注意权限要选择"发布"级别，否则后面调服务编辑器的选项会被禁用。

数据源注册是最容易忽略的步骤。很多人发布时看到"复制数据到服务器"的选项就选了，结果数据量一大，发布过程慢到怀疑人生，甚至直接失败。正确做法是：先把高程数据所在的文件夹或地理数据库注册到ArcGIS Server的数据存储中。注册之后，发布时就可以选择"引用已注册数据"（也就是调用服务器本地路径），发布速度会快得多。

版本匹配也要注意。ArcMap 10.8.x建议搭配ArcGIS Server 10.8.x，如果你把ArcMap 10.8连到较新版本的企业级平台，发布时经常会遇到"协议不一致""实例不支持"等报错，排查半天其实是版本兼容问题。

3.2 三步发布带高程能力的影像服务

数据准备完毕后，ArcMap的发布操作其实很短。

第一步，打开ArcMap，把高程栅格或者镶嵌数据集的图层拖入地图。这里提醒一下，图层的符号化方式会影响服务发布结果。建议用"拉伸"渲染，配合分级色带或地形色带，让DEM看起来有立体感。千万不要把浮点栅格设置成"唯一值"渲染，那样会相当于把它离散化，发布后的高程查询结果会失真。

第二步，右键图层，选择"共享为（Share As）→ 影像服务（Image Service）"。如果你的右键菜单里没有Share As，可以从文件菜单进去。弹出的窗口其实就是服务编辑器。

第三步，配置服务各项参数：

• 服务名称：全小写英文，不能有空格，尽量简短可读
• 服务器：选之前配置好的ArcGIS Server连接
• 数据：选"引用已注册数据（Reference registered data）"，前提是3.1里的数据源注册已经完成
• 缓存：按实际需要选择，后面会细说
• 功能能力：确保"影像"和"高程"两项都勾选

配置完成后，点击"发布"。ArcMap会把服务定义推送到服务器端，并在服务器上创建对应的影像服务。发布完成后，可以直接在ArcMap里看到服务图层被添加进来，也可以打开浏览器访问REST目录确认。

3.3 高程能力与函数链勾选细节

ArcMap的服务编辑器里，功能能力这一项中有一个"高程"（Elevation）的勾选。很多人忽略了这个选项，导致发布出来的服务只是一个普通影像服务，客户端怎么都查不到海拔。勾选高程能力后，服务REST目录中会出现相应的高程操作，客户端才能把它当作高程源来用。

函数链（Function Chain）是另一个关键点。ArcMap允许在服务发布前预设一条栅格函数处理链，最简单的就是"镶嵌函数"本身。如果你想让客户端能够实时算出坡度、坡向、山体阴影，可以在函数链中追加对应函数。这样客户端调用一个接口就能拿到派生结果，不需要自己去下载DEM再算一遍。

缓存方式选择上，我有一个非常明确的建议：高程服务尽量使用动态影像方式，不要为了速度全量切片。原因是高程服务的核心价值是浮点精度和查询能力，一旦切成了JPEG或PNG切片，高程值在压缩过程中就丢失了精度。如果你确实需要快速显示，也要在缓存配置里保留"允许动态请求"的选项，牺牲一部分性能来保证查询功能可用。

发布完成后，可以用一个很简单的办法验证：在ArcMap里添加这个影像服务，然后用"识别"工具点击任意位置，看返回的属性里是否包含高程值。再或者打开浏览器访问HTTP服务的REST页面，查看支持的操作里有没有高程相关的方法。如果这两个地方都对，服务就基本没问题了。

4. ArcGIS Pro 发布高程图层完整流程

4.1 Pro发布前要确认的事

ArcGIS Pro是现在主流的GIS客户端，发布高程服务的体验和ArcMap有不小差别，但大方向是一致的。

首先，版本建议用ArcGIS Pro 2.8以上，3.x更好。新版Pro对高程图层、LERC压缩、云栅格格式的支持更完善。旧版Pro虽然也能发布影像服务，但高程图层的类型选项和配置项会少一些。

其次，ArcGIS Pro的发布目标通常是ArcGIS Enterprise门户或ArcGIS Online组织。如果你只有一台独立ArcGIS Server，在Pro里也能发布，但需要额外配置门户连接。整体上看，Pro是"门户优先"的思路，所有服务都先成为门户内容项，再被各类客户端调用。

第三，高程图层发布前，最好先在Pro中打开一个全局场景或局部场景，把DEM加载进去，确认显示正常、拉伸合理。Pro中的场景环境能把坐标系、单位问题提前暴露出来，比直接盲发要稳得多。

4.2 共享为Web图层并选对类型

在Pro里发布高程服务的核心操作是：右键图层 → 共享为Web图层。

操作步骤可以这样看：

1. 在内容窗格中选中高程栅格图层，右键选择"共享为Web图层"
2. 在"常规"选项卡填写名称、标签、描述，名称同样建议英文小写，避免中文带来的兼容问题
3. 在"图层类型"下拉框中，选择"高程图层（Elevation Layer）"，这一步是在ArcMap中做"勾选高程能力"的Pro等价操作
4. 在"配置"选项卡选择接口类型和缓存策略
5. 在"共享"选项卡设置可见范围，比如组织内公开或仅特定群组
6. 点击"分析"按钮，等所有错误和警告清空后再发布

Pro的发布界面是选项卡式的，比ArcMap清晰很多。新手最容易漏掉"分析"这一步。Pro不是一个布就完了，它会在发布前检查数据问题，比如数据类型不对、坐标单位缺失、服务名称非法等。点击分析后，错误列表会逐条列出来，双击能定位到配置界面。我自己发布时必做这个动作，它能拦下90%的常规错误。

4.3 高程源、缓存切片与LERC压缩

Pro发布高程图层时，系统会把单波段DEM自动识别为"高程源（Elevation Source）"。在全局场景中，你可以直接把发布后的图层指定为地面高程源，这一步不需要写代码，只要在场景的Elevation Surface设置里选它就行。

缓存配置是Pro里最值得花时间研究的地方。高程数据不适合用JPEG或PNG做切片，因为这两种格式都是针对彩色影像设计的，存浮点高程会产生无法接受的精度损失。Pro里推荐用LERC格式。LERC是专门为浮点栅格设计的压缩格式，它能设定最大误差，比如0.01米，也就是厘米级误差，压缩率通常能做到原始数据的好几倍甚至几十倍。

我自己的习惯是：如果这个服务主要给三维场景当高程源，就选动态影像，不切片；如果还要同时给别人当底图显示，另外再发一个普通影像服务来做切片，高程服务保持纯净。虽然多占了一个服务名额，但每个服务的职责单一，出问题时好排查，性能也互不干扰。

发布后同样可以通过REST目录验证。与ArcMap不同的是，Pro发布的高程图层在门户内容项中显示为一个"高程图层"类型，点进去可以看到服务URL和缩略图；如果把它加到新场景中，系统会直接显示它支持地面高程源属性。

5. ArcMap 与 ArcGIS Pro 的选型对比

5.1 两种流程的异同点对比

我在文章开头说过，我在同一个项目里把两条链路都用透了。这里直接给出我对两者的判断。

从功能覆盖面上看，Pro基本是ArcMap的完全超集，高程服务该有的能力它都有，还多了很多管理层面的便利。但从操作习惯上看，老GIS人会更习惯ArcMap那种一层层菜单的方式。我个人现在的结论很明确：新项目、新环境一律用Pro，尤其是Server版本较新的时候。只在你维护存量老服务、或者Server版本确实很老时，才继续用ArcMap。

5.2 项目迁移与兼容性经验

如果你手上已经有大量用ArcMap发布好的高程服务，不用急着推倒重来。Pro的门户环境可以直接注册传统GIS服务，把旧服务导入门户内容库，实现统一管理。也就是说，你在Pro里能看到、能引用的旧服务，图层面板中照样能用。

但要提醒一个兼容性问题：Pro发布出来的高程图层，在ArcMap 10.8客户端里查看时，有时只显示为一个普通影像服务，ArcMap的旧界面不会识别"高程图层"这个类型。这不是服务坏了，而是老客户端的识别问题。反过来，ArcMap发布的带高程能力的影像服务，在Pro里作为高程源使用，通常没有问题。

迁移过程中，我建议的路径是：先把数据源从文件夹统一迁移到文件地理数据库或云栅格存储；再在Pro里创建镶嵌数据集，统一NoData和坐标系；最后重新发布高程图层。发布完用旧服务的URL做一次对比验证，确认同一点的高程值误差在允许范围内，再切换下游系统。整个过程虽然多花几天时间，但能避免服务上线后大量用户反馈不兼容的窘境。

6. 高频故障排查与调优记录

6.1 发布失败：先查这五个点

我遇到的发布失败，九成以上都集中在这五个原因上。

数据源未注册是最常见的。报错信息通常会带"not registered with server"字样。解决方法是到ArcGIS Server连接属性里的数据存储管理中，把数据所在文件夹或地理数据库注册上去。注意，如果路径是中文、带空格、或者是网络映射盘，服务器端可能会解析失败，最好用统一的本地绝对路径。

栅格带色彩映射表或属性表是第二常见的问题。报错会明确提示"raster has a colormap"或"RAT"存在。处理办法是先用Copy Raster把数据重写一遍，去掉颜色表和属性表，转成干净的浮点TIFF。

多波段数据被选中是第三个坑。高程图层必须单波段，如果你拖进去的是RGB或RGBA的多波段栅格，系统会报波段数错误。先用波段提取工具取出DEM波段，再发布。

第四个是账户权限问题。发布服务本质上是服务器端创建目录、写配置文件的过程，如果运行ArcGIS Server的账户没有目标目录的写权限，发布就会在最后一步突然失败。遇到这种问题，先去看服务器端的日志，通常能找到明确的权限拒绝记录。

第五个是版本不匹配。ArcMap 10.x连新版本的企业级平台时经常报协议错。这个没有巧办法，只能让客户端和服务器版本尽量保持在一个大版本内。

我把这些整理成了一张速查表，方便你临时对照：

6.2 高程服务“查不到值”的排查思路

很多人在服务发布后兴冲冲去查高程，结果发现识别工具返回的不是数值，或者客户端场景里没有高程选项。这个问题的排查顺序我建议这样走。

第一，先确认服务类型。如果发布时选了全缓存影像瓦片，并且没有允许动态请求，那么客户端拿到的只是图片，图片里的像素值已经被渲染和压缩过，不是原始高程。解决办法是在服务配置中把接口改成"动态影像"，或在下拉选项里勾选"允许动态查询"。

第二，确认访问的是镜像服务地址。高程查询要走/ImageServer这个端点，而不是/MapServer。很多人下意识访问了地图服务地址，看到的是渲染后的图层，当然查不到高程值。

第三，确认坐标系和单位。如果服务坐标系是地理坐标，但高程函数中没有配置Z单位换算，三维场景会把经纬度度数当作高度值，表现就是地形被压扁或拉伸得极其夸张。此时需要在服务属性中合理设置Z因子。

第四，确认REST目录里是否列出了高程相关操作。如果发布的ArcMap服务没勾选高程能力，或者Pro图层类型没有选高程图层，服务就只是普通影像服务，不会有高程操作接口。这一步能帮你确定问题出在类型配置还是参数配置上。

6.3 大范围数据服务变卡：切片与压缩调优

最后一个常见问题是性能。服务发布成功后，地图加载慢、剖面分析转圈几秒钟、三维场景拖动掉帧。先说结论：90%的性能问题出在数据没有合理组织，而不是服务器配置不够。

第一，镶嵌数据集一定要建概视图。概视图是金字塔的扩展，专门用于快速显示大范围影像。如果没建概视图，客户端一拉缩小视图，服务器就要临时扫描全库来拼图，不卡才怪。建完之后，再用ArcMap或Pro浏览一下，缩放流畅度会有质的变化。

第二，缓存格式和压缩方式要选对。高程数据体的压缩格式优先级是：LERC 优于 JPEG 2000 优于 LZ77。以某项目为例，原始约68GB的高精度DEM，用LERC压缩并设置误差0.01米后，发布缓存体积降到约9GB，速度明显提升。JPEG虽然体积小，但对高程值是有损压缩，误差可能到半米甚至更大，千万不能用。

第三，如果并发量很大，考虑水平扩展。ArcGIS Server站点可以配置多个实例或单机多实例，配合负载均衡，把高程计算请求分散到多个节点。这种层面不是日常发布能解决的，但架构上要有这个意识，尤其当服务要被大量三维客户端同时访问时。

第四，建议把高程服务和展示服务拆开。同一个镶嵌数据集，可以发布两个服务：一个动态高程服务负责查询和分析，另一个缓存影像服务负责显示。显示服务被打爆不影响高程查询，反过来也一样。虽然多占用一点资源，但生产环境下稳定性优先，这个取舍是值得的。

最后说点个人体会。高程服务的发布流程本身不复杂，关键在数据准备和参数理解。我在项目里最常见的失败，几乎都出在坐标单位和NoData上，而不是软件操作本身。如果读者手头正在做类似工作，建议发布前先把"数据体检"做完——确认单波段浮点、确认坐标系和单位、确认NoData、建好金字塔和概视图，发布过程反而很快。后续想扩展的话，还可以考虑把高程服务挂到门户的三维场景里，甚至搭配移动端离线切片包做现场测量，这些我在项目里都验证过，效果很稳。