企业官网建设流程全解析

做GIS这些年，我接触最多、也最担心在项目上线前出问题的一个环节，就是高程数据服务的发布。所谓影像高程服务，就是把DEM、DSM这类带高程值的栅格，通过ArcGIS Server发布成Web端能调用的影像服务。前端无论是做三维地形、淹没分析、视域分析，还是做剖面提取和填挖方计算，都得靠这么一条服务去读取高程信息。今天这篇我结合用ArcMap和ArcGIS Pro两个平台发布高程影像服务的完整流程，把方案、参数和踩过的坑都摆一摆，给做数据发布和WebGIS的同行留一份可以直接参考的实操笔记。

1. 影像高程服务是什么：发布前先想清楚你的使用场景

1.1 高程服务在项目里的两种打开方式

影像高程服务听起来很专业，我跟刚入行的朋友解释时通常这样说：它就是把硬盘里那个tif高程文件，变成一个浏览器能访问的网址，别人通过网络就能读取栅格里的高程值。具体到项目里，使用方式主要是两类。

第一类是可视化展示。比如在三维地球系统里叠加一个带山体阴影的高程图层，或者用高程数据生成地形骨架，这类需求主要看效果，不要求精确读取每个栅格值。第二类是分析计算。像流域水文分析、视域分析、填挖方计算，前端要拿到服务端返回的高程值去做运算，这就必须保证服务输出的是原始高程数值，而不是被渲染过的彩色图片。

这两类需求直接决定了你后面是选动态服务还是切片缓存、用什么压缩方式、要不要开像素查询功能。很多项目做到一半返工，根源往往不是技术不行，而是发布前没把使用场景想清楚，导致参数选错。

1.2 动态影像服务与切片：不是所有高程都要做缓存

在ArcMap和ArcGIS Pro里发布影像服务时，都会让你选择动态服务还是切片服务。我用一句话总结多年的经验：高程服务大多数时候用动态。

原因很简单。高程栅格一般体积比较大，但前端往往只需要按需读取某个范围或某个点的高程值，动态服务可以实时处理请求，响应灵活。而切片服务是把影像预先渲染成小方块图片缓存到服务端，适合大量用户反复查看同一区域，性能确实好，但切片之后高程就变成一张张图片的像素值，分析类前端根本没有办法还原原始高程。

比如做填挖方分析，前端要的是一个点的高程数值，切片服务只能回给你一个图片URL，这显然不行。但如果你做的只是一个山体阴影底图展示，访问量又高，那么切片反而是更好的选择。所以发布前先问自己一句：下游到底是要“看”这张图，还是要“算”这些值？想清楚这一条，后面很多参数都不会选错。

2. 数据准备阶段，别急着发布

2.1 格式与坐标系检查：地基决定上层建筑

高程数据的常见格式有GeoTIFF、IMG、TIFF、DTED，甚至有时候项目方给的是ASCII GRID或者netCDF。我的习惯是，在进入发布流程之前统一转成GeoTIFF。ArcGIS对TIFF的支持最稳定，发布过程中出错的概率最低。如果拿到的是多波段影像，比如卫星影像或者包含多个波段的栅格，高程服务一般只关心单波段，要先用“提取波段”工具把有效的高程波段单独提出来，不要让服务带着多余波段去发布，白白增加数据体积和处理时间。

坐标系这块坑最深，千万别想当然。之前有个同事遇到过发布的DEM在Web端拉出来完全对不上底图，查了半天才发现原始数据是经纬度坐标系，发布时服务默认按投影坐标系解析，导致坐标严重偏移。发布前，在图层属性里务必确认空间参考信息是完整的，最好统一到CGCS2000投影坐标系再发。不同系统之间如果坐标没有约定，先约定好再做，不要发完再倒腾，那是最浪费时间的事。

提示：带空间参考信息但仍发现叠加对不上时，先确认是不是动态投影导致显示正常但实际坐标不对。把图层属性里的源坐标信息截图保存，这能帮你省掉后面80%的排查时间。

2.2 高程单位、NoData和无效值处理

高程单位问题在跨项目协作时特别典型。很多DEM数据的高程单位是米，但也有一部分海外数据用的是英尺，还有一部分数据因为采集和处理原因，边缘或者异常区域存在噪声值。ArcGIS里高程单位看起来只是一个属性字段，实际影响非常大：下游如果拿这份服务去做坡度和填挖方分析，单位不对，计算结果全部错误。

发布前在栅格属性里检查两件事。第一件，像元大小单位是否和坐标系一致。第二件，高程值单位是否设置正确。如果数据是英尺要转成米，最好提前用栅格计算器做一个乘以0.3048的处理，不要指望发布时自动转换。

NoData值也要单独看。DEM边缘经常有一圈黑色区域，那是无值区。默认情况下，如果NoData被表示为0，ArcGIS在分析时会直接把它当成海拔0米，前端生成地形时就会出现一个巨大的深坑。发布前用“复制栅格”或“填充NoData”工具处理一下，或者至少在符号化时把NoData设为完全透明，避免视觉上的黑洞被带进服务里。

2.3 要不要先做镶嵌数据集

小项目，数据就一两个tif，直接发布原始栅格就行。但有些项目的高程数据是几百景分幅，这时候一定要先建镶嵌数据集Mosaic Dataset，再基于镶嵌数据集发布影像服务。

为什么这么做？镶嵌数据集可以管理海量栅格，允许服务发布后随时添加新的分幅数据，不需要重新发布整个服务。它还能在发布时挂载一系列“栅格函数”，比如动态镶嵌、山体阴影、坡度计算，服务端每次请求时实时算好再返回。这个特性对高程服务特别有用：你发布的是一套“活”的数据集，而不是一张死图片。数据更新时，给镶嵌数据集追加新影像，服务内容自动跟着变，前端完全无感。

3. ArcMap发布影像高程服务实操流程

3.1 正确加载DEM，先做符号化检查

第一步，打开ArcMap，把DEM添加进来。经常有人直接把dem拖进地图，发现黑乎乎一片或者灰白一片，就以为数据坏了。其实DEM默认渲染方式是按高程值拉伸显示，显示效果和数据质量是两回事。

建议先在图层属性“符号化”里把拉伸类型设为“百分比截断”或“标准差”，把高程值拉伸到0到255的灰度显示范围，确认地形起伏能看清楚。也可以右键切换到“山体阴影”渲染方式，快速判断数据有没有明显的缺失和条带。这一步纯属目视检查数据，不影响后续发布，但能帮你第一时间发现数据问题。

3.2 共享为影像服务的具体操作路径

ArcMap发布影像服务的入口在主菜单“文件”下面，选“共享为”，再选“影像服务”。这个菜单跟Pro里的“Web图层”不同，它是独立的一套发布界面。打开以后是一个向导式的面板，默认停留在“数据”标签页，需要选择“地图中的图层”作为服务数据源。此时如果地图里加载了多个图层，只勾选DEM那一层，别把辅助线、标注图层一起勾进去。

第二个重要区域是“位置”，在这里要选择一个服务器连接。如果之前没有配置过，需要先在“目录”窗口里新建一个ArcGIS Server连接，输入服务器URL、用户名和密码。有一个容易忽略的点：ArcGIS Server的登录账号不一定拥有发布权限。有的单位Server站点管理员和数据发布员是两个账号，数据发布账号如果只有访问权限，后面点“发布”时按钮是灰的。不要硬磨，直接找一个有发布权限的账号再试。

然后是“服务名称”。服务名称用英文小写加下划线组合，例如dem_elevation_hillshade。服务发布成功后，REST URL直接拼接的就是这个名称。如果用了中文名甚至是空格，浏览器和前端JavaScript在解析URL时容易出乱码，报404是小事，排查起来非常头疼。

3.3 服务属性中的几个关键参数

ArcMap影像服务发布面板里最容易被跳过的是“服务属性”部分，很多人设置完名称直接发布，结果服务出来不能满足分析需求。

先说“缓存”选项。ArcMap里有一个单选，问你是“开始切片”还是“不切片”。高程服务做分析用途时选“不切片”，做山体阴影展示时可以考虑切片。不要图省事全选切片，我见过有人把DEM发布成切片以后，前端调用不过来，因为高程值已经变成图片像素了，分析工具根本取不到真实的Z值。

再说“影像功能”扩展。想在前端调用高程查询，也就是通过服务读取单点高程，必须在发布时勾选“像素”能力。不勾选的话，服务虽然能出图，但前端调用查询类接口会直接返回Method Not Allowed。

还有一个很少人调整的选项是“压缩类型”。建议直接从下拉里选“LERC”。如果发布面板里没有LERC选项，说明服务器版本偏旧，至少要选“不压缩”或者“LZW”。这个在第5节会详细展开。

设置完以后，窗口底部有个“分析”按钮。点它，系统会开始扫描当前数据和服务配置，列出问题清单。问题分成两类：红色是错误，必须解决；黄色是警告，可以酌情忽略。常见的红色错误包括数据源路径包含中文或空格导致服务器无法访问、坐标系信息缺失、服务名称重复。把这些错误逐个解决，重新再分析，直到没有红色错误，再点“发布”。

3.4 发布完成后必须做的验证

发布流程走完，ArcMap会弹出完成提示，同时目录窗口里自动出现这个服务节点。很多同事到这一步就觉得完事了，开始给前端发URL。我建议先做一个30秒的验证。

打开浏览器，直接访问服务的REST端点，看到返回的JSON里有服务描述信息，往下找“Pixel Type”字段，确认它写着“FLOAT”或“32Bit”。接着在页面底部找一个叫“Pixel”或者“Sample”的链接，点进去输入地图上的坐标，它会返回该点的高程值。此时拿这个值和原始DEM在ArcMap里的属性值比对，一致就说明服务发布成功且高程保真。

我之前带过一个项目，发布完访问量也正常，但前端查出来的高程值总是偏差几米。排查到最后发现，是发布时选了JPEG压缩，高程值被有损压出了误差。掌握这个验证方法以后，这类问题基本当场就能发现。

4. 在ArcGIS Pro里发布Web影像图层

4.1 Pro发布入口和界面逻辑

ArcGIS Pro的发布方式跟ArcMap差异非常大，从ArcMap切换过来会有些不适应。Pro里的概念是“Web图层”，所有发布动作都围绕“共享”选项卡展开。

操作路径是：打开Pro工程，把DEM添加到地图，在“内容”窗格里右键该图层，选择“共享为”——“Web影像图层”。也可以在顶部菜单“共享”页签下点“Web图层”，再把类型改成“影像图层”，两个入口效果一致。

共享窗格打开后，左侧有一个列表：一般、配置、缓存管理，右侧是对应的参数面板。Pro的逻辑不是向导式一步步填写，而更像一个资源管理器，把服务当做一个Web图层对象来配置。好处是一目了然，坏处是参数藏得比较深，不熟悉的容易漏。

“一般”区域填标题、摘要、标签。标题可以写中文，比如“某区高程服务”，用于展示，没有影响。但注意在“配置”区域里，有一个叫“服务名称”或“URL名称”的字段，这个才是真正的REST服务名，必须用英文小写。标题和服务名是两回事，很多人搞混，最后发布出来的URL是一堆编码字符，就是这个地方没改。

4.2 功能与缓存配置的关键选择

Pro里发布影像图层时，要先确认“类型”，一般会看到“影像图层”下面还有两种子类型：动态影像图层与切片影像图层。这个判断逻辑和ArcMap一致：高程分析用动态，纯展示用切片。

在“配置”区域，可以展开“高级设置”，里面能配置栅格压缩、像素查询、最大采样大小、最大请求记录数等参数。高频使用的配置是：压缩类型选LERC，勾选允许像素查询，把最大请求记录数调大到4096以上。

“缓存管理”这块，如果选了动态影像图层，通常不需要额外配置。如果选了切片影像图层，要指定“切片方案”和缩放级别。切片方案建议选“ArcGIS Online/Bing Maps/Google Maps”三选一，因为这个方案是网络通用的，前端底图用的是同一套规则，叠加起来才能严丝合缝。

都设置完成，点共享窗格右下角的“分析”，Pro会跑一次检查。经常遇到的红色错误是“服务器类型需要高版本授权”或“数据没有任何空间参考，将无法发布”。逐个解决后再点“发布”。发布过程在右下角的任务通知里显示进度，等它变成绿色打勾就说明成功了。

4.3 Pro和ArcMap流程的核心差别

两个平台都发布过高程服务以后，我能明显感受到Pro的进步，但也有一些需要注意的地方。

进步方面有三点。第一，检查更严格更早。ArcMap把坐标系缺失这种问题放在分析阶段才提示，而Pro在添加数据时就会警告，无形中逼你把基础工作提前做好。第二，发布结果可即时预览。Pro支持在共享窗格里直接看到服务效果，对调试配色和切片范围很有用。第三，和Portal的集成更强。如果你们用的是私有化Portal那套，Pro发服务的体验比ArcMap顺畅得多，发布后可以直接托管，权限管理也更方便。

需要注意的地方也有三点。第一，Pro发布失败后的报错常常比较笼统，比如“无法访问服务器”，实际原因可能是服务器连接过期。处理办法是把服务器连接删掉重新建一次，再刷新重试。第二，Pro默认会在磁盘里生成一些临时本地缓存，如果工程路径有中文，发布过程容易卡在“检查数据”步骤。需要把工程路径和数据路径改成纯英文再试。第三，旧版本Pro连新版本Server时，有些配置项会显示为灰色不可选，服务发布后高级功能缺失，尽量保持Pro版本和Server版本大版本一致。

5. 服务参数与性能调优：文档里没细讲的细节

5.1 DEM压缩选型：LERC凭什么最重要

影像高程服务的核心是“保真”。我见过不少团队把DEM当普通影像处理，用JPEG压缩发布出去，结果前端高程分析全错，最后返工重发。JPEG属于有损压缩，专门为视觉图片设计，高程数值经过变换后精度已经受损。

ArcGIS针对栅格数据提供的LERC压缩，才是高程服务的正确选项。LERC的全称是Limited Error Raster Compression，直译就是“限差栅格压缩”，它允许你设置一个最大误差阈值。比如设允许误差0.1米，LERC能在保证误差不超过这个阈值的条件下压缩数据；如果设成0，就是完全无损。高程数据用LERC后，文件体积能压到原来的五分之一甚至更小，精度还能保住，这是发布高程服务需要首先学会使用的参数。

实际操作里，在ArcMap发布面板“压缩类型”选“LERC”，如果面板里能看到“最大允许误差”，一般填0或者0.001，单位按数据单位走。在Pro高级设置里，压缩参数是同样的逻辑。没有LERC选项的旧版环境，退而求其次用LZW无损压缩，体积会比LERC大不少，但至少精度能保住。

5.2 金字塔与切片：访问性能的两个闸门

栅格服务为什么卡？十有八九是金字塔没建。金字塔简单说就是影像的多级分辨率副本，大范围显示时读小图，放大时读细节。高程DEM如果发布前没有金字塔，服务端每次请求都要把整张栅格读一遍找对应像元，慢是必然的。

发布前，在ArcMap或Pro里右键栅格图层，选择“属性”——“常规”——“构建金字塔”，或直接用“构建金字塔”工具。设置金字塔压缩用默认就行，但建议选“双线性重采样”或“最近邻”方式，确保高程值不被平滑掉。数据有更新时记得重建金字塔。否则读到的还是旧索引。

切片缓存这块，如果你的高程服务是山体阴影展示用途，建议做一套1到12级的切片，切片格式选“PNG”或“JPEG”，可视效果好且体积小。但如果做高程分析，就别做切片，保持动态服务。这个取舍同样在上面反复强调。另外有一个容易被忽略的“按需生成缓存”开关，允许动态服务在服务器空闲时把请求过的区域自动缓存，第二次请求相同区域直接读缓存，速度明显提升，适合可视化和分析混合使用的场景。这个选项在服务发布后的属性里也能动态修改，不需要重新发布。

5.3 服务能力、权限与资源限制

服务能开放哪些操作，由“能力”配置控制。我建议高程服务至少打开三项：影像能力负责出图，像素能力负责高程查询和取Z值，元数据能力负责返回服务描述信息。一般高程服务都是只读的，不要开“写”和“上传”能力，避免带来安全风险。

再看“资源限制”相关参数。ArcGIS Server服务属性里有“最大图像宽高”“最大像素数”“最大请求返回记录”等限制。默认值比较保守，高程服务前端做剖面分析时一次要拉一整条线的值，请求量很大。我一般把“最大像素数”提升到16384，把“最大请求返回记录”设为10000，同时开启“允许分页”来支持大数据量查询。这些数字不是拍脑袋定的，可以根据前端需求倒推：比如前端要做视域分析，一次读取100乘100个点，就是1万像素，再结合并发量，留出余量即可。

5.4 服务地址与代理配置的一个细节

很多单位不会直接暴露ArcGIS Server的7080端口，而是通过反向代理对外提供服务。高程服务发布到Server之后，如果前端用代理地址访问，有一个隐藏问题：服务端返回的JSON里可能把数据源URL写成内网地址，前端拿到后去请求内网地址，自然失败。处理方案是，在ArcGIS Server管理器里把根地址配置成公网域名，同时确保代理和Server站点注册的URL是同一个域名，不要一边用localhost一边用公网IP。这个细节官方文档里写得比较简单，实际项目里踩过一次以后就会特别注意了。

6. 常见问题与排查技巧实录

6.1 一张实用的问题速查表

下面这张表是几次项目里攒下来的经验，遇到问题照着排查基本能解决：

6.2 一个印象最深的返工案例

分享一下我自己踩过的一个典型坑。有一次给一个三维平台做DEM叠加，数据从甲方那边拿到的GeoTIFF，坐标系看着正常，发布也很顺利，服务状态是启动的。结果前端联调时，地形模型完全变成一大块平地，个别位置还塌成负值深坑。

当时第一反应是数据问题，用ArcMap打开原始DEM，拉伸渲染后看，起伏很明显，数据没有毛病。那问题只能出在服务端。

后来逐项排查，在服务属性的“像素类型”里发现默认变成了“RGB”，而不是浮点型。原因是我在发布前给图层加了一个“拉伸渲染”的符号化方案，这个渲染方案被一起发布到了影像服务里，服务端把高程值先转换成了RGB彩色表达，输出的自然就不是浮点高程了。

解决办法也简单，在ArcMap里把DEM图层的符号化改回“无”或者是标准渲染，不套拉伸函数，再重新发布。从那次以后，我给自己定了一个规矩：发布高程服务之前，一定要检查目标图层有没有挂附加的符号化系统或栅格函数，分析类函数挂在上面时要理清楚是随服务发布还是仅用于本地显示。

6.3 高程服务的验收清单

收尾前再说一个保持了很久的习惯。每次发布完高程服务，我都会按这个顺序快速过一遍：

1. 在浏览器打开服务REST端点，确认状态为“已启动”。
2. 检查“Pixel Type”是浮点型，“Compression”是LERC。
3. 用“Pixel”接口查一个已知点的高程，和原始DEM属性值比对。
4. 用前端方式以动态图层叠加一次，目视检查地形和底图贴合情况。
5. 确认服务开启“影像”“像素”“元数据”三项能力。
6. 给前端发URL之前，再让一个同事用浏览器验证一遍标准坐标查询。

这几个步骤看起来不多，但能把服务端问题提前拦住一大半。我遇到过服务本身没问题，结果是前端写错参数名一直查不到值的案例，那是前端的调试范畴，但帮他们多验证一轮，整个联调效率也会明显提升。

发布高程服务这件事，ArcMap和ArcGIS Pro两条路并没有谁绝对更好。ArcMap靠向导式发布，步骤清楚适合新手；Pro资源管理式的配置更适合大量服务统一管理的场景。关键还是把高程服务的本质想清楚：它是一份需要保真、需要可查询、需要被前端当数据接口来用的特殊影像服务。发布只是起点，真正的功夫在数据准备、参数选型和发布后的验证上。希望这篇实操笔记能帮你在项目里少走几次弯路。