干这一行久了你会发现影像和高程服务的发布工作横跨的不只是两个软件而是两代产品逻辑。我这些年从ArcMap 10.6一路用到ArcGIS Pro 3.x手里的DEM和DOM数据换了一批又一批发布服务的流程也跟着换了两套思路。很多东西在ArcMap里是默认就会的到了Pro里菜单路径全变了反过来在Pro里很容易配置的高程服务类型在ArcMap里想实现同样的效果却得绕好几个弯。这篇文章就是把我实际整理过的一套发布流程摊开来讲——ArcMap怎么做影像服务和高程服务、ArcGIS Pro怎么做同样的工作、两种流程的参数取舍和选型逻辑以及我踩过几次之后总结出的排查经验。不管是还在维护旧平台项目的朋友还是已经开始迁移到Pro的同仁应该都能在里头找到自己需要的那一段。1. 影像服务与高程服务的服务端差异先弄懂这几件事再动手1.1 影像服务本质上是栅格服务高程服务是它的“专业分支”先说一个很多人容易混淆的概念。ArcGIS Server上的影像服务Image Service和高程服务Elevation Service底层跑的都是栅格服务那套机制。发布之后客户端都可以通过REST端点访问、动态切图、查询像素值影像服务还支持镶嵌、裁剪、导出等操作。区别在于高程服务额外携带了“高程语义”。换句话说高程服务不仅要告诉客户端“这个像素的值是多少”还要告诉客户端“这个值表示的是海拔高度单位是米该以什么规则去插值计算”。所以ArcGIS Pro里发布高程服务时软件会要求你确认数据是整型还是浮点型、单位是米还是英尺这些都会被写进服务的属性里供高级分析功能读取。我见过不少朋友把DEM用影像服务的标准流程直接发布结果在客户端做剖面分析时得到的高度值跟原始数据对不上。大概率不是数据错了而是服务定义里缺少高程语义——服务类型选错了。1.2 ArcMap和Pro的发布入口差异实质是两代服务定义模型的差异ArcMap 10.x走的是“连接ArcGIS Server→共享为服务→服务编辑器”这条老路。服务编辑器里能看到完整的上古参数缓存设置、能力选项卡、池化配置、服务描述……每一样都能精确控制但结构偏旧新增的高程语义选项很少。ArcGIS Pro走的是“共享为Web图层”这条路。它把发布过程封装成向导式对话框更强调门户集成和新型服务类型高程Web图层、甚至三维场景服务都能直接发布。对刚从ArcMap迁过来的人来说最大的不适应是很多ArcMap里手动控制的选项Pro里变成了自动判断而Pro里新增的高程分析相关开关ArcMap里根本没有。我的建议是如果服务器还在用10.x版本并且短期内不打算升级ArcMap的流程依然要掌握如果你已经用上了新版本或是走门户管理那就索性把精力全部放到Pro流程上别两套混着记容易串。1.3 发布之前先想清楚你的数据到底是“影像”还是“高程”这两个词在业务上经常混着用但在服务端是严格区分的。判断标准很简单你需要服务提供方计算坡度、坡向、剖面、视线分析这类三维空间分析能力吗如果答案是肯定的哪怕表面上你只需要一张看得见的地形图也应当发布成高程服务。反过来如果只是底图浏览、像素值查询、波段组合那影像服务就够了。一个典型的场景是林业项目里的地形底图需求。甲方说要“一张好看的地形晕渲图”但实际使用中还要做淹没分析和通视分析这种就必须走高程服务。我遇到过项目做到一半才发现服务类型发布错了不得不重新发布、重配缓存的尴尬变更成本远比一开始就选对类型要高出好几倍。2. 影像高程服务发布前的数据准备金字塔、坐标系、NoData一个都不能少2.1 先构建金字塔和统计数据别把问题留给服务器很多人拿到原始栅格的第一反应是赶紧打开ArcMap看效果然后直接共享服务。这是大忌。原始影像通常是大尺寸单景文件没有金字塔和统计数据服务器得临时去计算全图范围、像素统计和重采样轻则首次访问卡死重则直接把服务发布请求超时。按要求发布前先对栅格做这些预处理构建金字塔ArcMap的栅格图层属性里就有“金字塔”选项卡建议选择最近邻或双线性重采样按2倍递增生成多级金字塔级别数根据数据量来普通级别的DOM数据生成到第8层左右基本够用。计算统计数据右键栅格数据源在目录窗口里选择“计算统计数据”。这样服务发布后前端拉伸渲染的范围才是正确的不然影像往往发灰或者过曝。检查数据源格式虽然GeoTIFF、IMG、CRF都能发布但实测下来GeoTIFF兼容性最好尤其要发给其他部门SDK调用时TIFF基本不会出幺蛾子。这里有一个常见误区图层右键的“创建金字塔”和工具箱里的“构建金字塔”功能是一样的但前者只对当前图层有效后者会对数据源本身操作。发布服务时服务端读取的是数据源所以必须在数据源层面完成构建而不是只给图层加个影像金字塔。用目录窗口对数据源执行是最稳妥的方式。2.2 坐标系和像素深度高程服务尤其要较真影像服务的坐标系错误往往表现为“图层能显示但各位移”或者“无法与其他图层对齐”高程服务的坐标系错误则直接会让高程值变成负数或者大得离谱。这是因为高程服务发布时服务器需要根据坐标系去判断水平单位和垂直单位从而决定高程值保持原样还是做换算。发布高程服务前我几乎每次都会做两个检查检查栅格的空间参考参数确认水平坐标系是WGS84还是国家坐标系避免自身坐标系未定义导致的“服put到服务器上再配一次”的麻烦。检查栅格的像素类型Pixel Type和深度。DEM数据通常是16位整型或32位浮点。发布高程服务时浮点型数据当然要保留浮点精度如果是整型DEM注意看是否有符号——无符号整型不适合直接表示负海拔遇到有负值的地区需要先做偏移处理。这里补充一个实操细节在ArcGIS Pro的目录里右键栅格选择“属性”能看到详细的栅格信息包括像元类型、深度、NoData值。发布前养成先看一遍属性的习惯能省下很多发布后排查的功夫。2.3 NoData值怎么设置直接影响服务端查询结果NoData不是一个可选项而是一个必须显式设置的值。原始数据里通常用-9999或32767这类“超出物理范围”的数表示无效区域ArcGIS在读入后只有在栅格属性里正确设置了NoData服务端在做像素查询和函数分析时才会自动忽略这些区域。没设置NoData的后果我在实项目中见过两次一次是服务发布后影像上出现整片黑块/白斑另一次是在Web端做高程查询时无效区域返回值变成了-9999结果剖面图直接画出了一条掉到地心的“飞线”。设置方法很简单在“构建栅格属性”或数据预处理阶段用“复制栅格”工具把NoData值显式指定为目标值然后勾选“将NoData设置为当前值”。如果你用ArcMap直接发布也可以在图层属性→源→NoData里手动填。但要注意这个设置只影响服务端读取不会改变原始文件像素值所以一旦换台机器重新发布就得再设一次。2.4 镶嵌数据集和批量文件的情况如果你的影像不是一个文件而是一堆分幅的DOM或者DEM直接发布单文件不现实。传统做法是用“创建镶嵌数据集”然后把所有分幅添加进去构建轮廓、镶嵌和概览最后发布镶嵌数据集的影像服务。ArcMap和Pro都支持这一流程Pro里的“镶嵌数据集”工具集更顺手。另一个相当有用的做法是在Pro里把分幅数据做成“镶嵌图层”再共享为Web图层。这种方式发布出来的服务在服务端仍然保留单景的边界信息前端可以做到按需访问那幅数据适合大数据量的分幅业务。当然如果你只是临时展示不想维护镶嵌数据集也可以用“管理栅格目录”或直接发布多文件——“共享为Web图层”对话框里其实允许选择多个栅格Pro会自动把它们作为集合处理。但这种方法发布的动态度一般不推荐生产环境长期使用。3. ArcMap发布路径服务编辑器里的关键取舍3.1 从ArcMap共享为服务第一步是配置Server连接ArcMap里发布服务前必须要有一个能发布的ArcGIS Server连接。在目录窗口的“GIS服务器”节点下双击“添加ArcGIS Server”选择“使用GIS服务”输入服务器地址和管理员账号。这里有个容易忽略的权限点执行发布操作的账号必须具有ArcGIS Server的发布权限通常对应“publisher”或“admin”角色。如果用只读账号连接共享为服务的选项就是灰的。不少小团队把管理员密码做成了“公共密码”人人可发布出了乱子反而找不到责任人建议还是按权限分号来管理。连接建立后先右键这个服务器连接选择“服务器属性”能看到可用的服务目录、机器配置和存储位置。我习惯在发布前先确认“服务器上是否已经存在同名服务”同名服务在覆盖发布时经常出一堆乱七八糟的缓存冲突建议删除旧服务或改名。3.2 服务编辑器里的关键选项缓存、能力、池化进入发布流程内容列表里加载好栅格图层调好符号化一般是拉伸或者唯一值然后右键图层→“共享为”→“服务”——这一步ArcMap会弹出一个“共享为服务”向导依次选择发布到ArcGIS Server、选择服务文件夹和名称、最后进入服务编辑器。服务编辑器其实是几乎所有发布经验集中体现的地方。打开左侧面板主要看这么几项参数包含“返回所有像素值”、“允许导出的影像格式”、“最大影像请求数”等栅格服务参数。其中比较重要的是“允许导出”——如果业务需要客户端下载原始像素必须勾上只做浏览建议关闭导出以保护原始数据。缓存决定服务是动态渲染还是切片缓存。影像服务一般推荐动态渲染因为影像本身已经做过金字塔服务端直接按需读块、重采样效率很快没必要再做一层切片高程服务也一样。如果发布的是影像底图且访问量大可以切片后面再细说。能力勾选合适的服务能力。影像服务至少要勾“影像”和“WMS”高程服务建议再多勾一个“WCS”或者“KML”方便外部门做数据分析。能力勾多了会影响性能但高程分析需要的能力一般默认就是开的。池化里头与实例数参数有关。栅格服务是相对轻量的常规并发下实例数设置成1~2就够了但如果有三维客户端或频繁分析请求可以适当调高实例数。设置完成后点击“分析”按钮执行预检。绿色对勾基本可以发布黄色警告要注意红色错误必须解决。一个常见的红色错误就是“数据源未注册”解决办法是在服务器上创建数据库链接或栅格数据注册目录把数据源路径注册进去。ArcMap发布向导里也可以直接把数据复制到服务器但数据量一大复制过程的耐心是必须有的。3.3 发布后的验证从REST端点检查服务状况服务发布成功后别忘了去验证。打开浏览器访问ArcGIS Server的REST服务目录找到刚发布的服务点进去检查服务状态显示“已启动”服务URL能返回JSON格式的元数据在“导出”或“影像”操作里试着请求一张最小尺寸的图片观察返回是否正常在“高程”能力下做一个示例查询检查高程值范围和原始数据是否一致。我在团队里一直倡导发布即验证的习惯。服务发布完紧接着就做一次REST验证能够把“服务没发布成功”和“客户端代码的问题”快速区分开。很多时候Web端程序报错第一反应是前端代码有Bug结果排查半天发现是服务端影像请求范围设置小了这类问题在REST端点一测就能看出来。4. ArcGIS Pro发布路径高程Web图层的完整配置4.1 ArcGIS Pro的影像发布逻辑与ArcMap的差异ArcGIS Pro的默认工作流是“共享为Web图层”。在Pro里你不需要单独建立服务器连接后做文件夹选择而是在地图的内容列表里选择图层右键→“共享为”→“Web图层”。接下来会弹出发布窗格依次设置名称、数据位置、服务器和文件夹。有个跟ArcMap特别不一样的地方Pro里发布的Web图层默认是把数据复制到服务器端。这个行为在“共享为Web图层”的“数据管理”选项卡里可以看到。如果数据已经在服务器数据存储中注册过路径可以不复制直接引用原数据源。两种方式各有优劣复制到服务器的优点是服务和数据耦合后续做测试环境迁移比较省事引用原始路径则有利于大数据的实时更新不用重新发布服务只要源文件更新服务端立刻能读到新数据。像我们做定期更新的高程数据用的就是“引用原始路径”的模式。每次新的DEM文件替换掉同名旧文件服务自动反映最新数据省掉了每次发布后手工请求缓存的环节。4.2 高程服务类型是如何被识别的又如何覆盖在Pro里如果你把DEM栅格加载到地图中并设置了适当的渲染方式如高程拉伸右键图层共享时发布窗格会自动判断类型。通常它会识别成“影像”或“高程”。如果识别成了影像而你需要高程语义就需要手动在图层属性或发布窗格里调整类型选项。具体调节路径在“共享为Web图层”发布窗格中有一项“图层类型”或“高程——用于分析”。当数据被识别为高程且需要启用高程分析时建议将其发布成“高程”Web图层。如果Pro识别不了可以先把图层符号系统设置成“地表”系列对DEM做一次预处理再重新尝试发布。那这里我要特别强调ArcMap几乎无法直接把DEM变成“高程服务”发布。它发布的影像服务即便描述了高程值也不会把这些语义完整传达给Web端分析模块。如果你的环境还是ArcMap为主又要做高程服务我建议你先把数据放到Pro里发布再在ArcMap或Server Manager中做后续配置。4.3 高程服务发布参数详解缓存、分析范围与坐标系在Pro的高程Web图层发布窗格里重点需要关注以下参数高程表面Elevation Surfaces这个选项在一些版本里比较靠前可指定发布高程服务所用的表面。它决定服务对客户端进行高程查询的语义级别。切片缓存方案高程图层如果使用切片缓存会失去动态高程查询能力所以一般情况下高程服务不适合预先切片应保持动态发布。动态发布时客户端可针对任意点实时请求高程值是三维分析的核心。数据管理如上所述选择复制数据还是引用数据。服务能力确认“高程”能力已被勾选并检查是否包含高程单位、垂直坐标系等信息。若服务用于Google Earth等可再勾选“KML”能力。还有一点容易被忽略高程服务的范围。发布时务必确认“分析范围”覆盖了数据的全部有效区域。默认情况下Pro会根据图层本身的范围自动判断但如果你对图层做过裁剪或设置过显示范围发布的范围可能偏小导致Web端只能查到局部的高程数据。这个坑我也踩过一次——发布后发现山体北坡全查不到高程最后发现是发布前设置了当前地图的显示范围白白浪费了一天时间。4.4 Pro里的一次典型高程服务发布操作顺序把典型的高程数据发布操作串成一条线来看帮助刚上手的朋友有整体概念在Pro里加载DEM栅格到2D地图用拉伸渲染器查看是否正常显示。右键栅格图层选择“属性→源”检查像元类型、深度、NoData值是否正确不对的话回数据预处理阶段修正。右键图层选择“共享为”→“Web图层”。在发布窗格设置名称、服务器和文件夹。名称尽量用拼音或英文避免某些SDK在读取中文名称时出现编码问题。确认服务器与数据管理策略复制或引用。在“高程”能力配置中确认单位为米、表面类型为DEM。点击“分析”进行预检查看错误和警告。高危问题优先处理。点击“发布”。发布完成以后Pro会提示你是否可以打开“管理Web图层”页面可以直接去查看服务。如果条件允许在Scene场景里把发布的地形服务加载进来看看三维效果这是最快、最直观的验证方式。4.5 用高程服务做前端分析时的服务端注意事项服务发布后前端就可以通过ArcGIS API或Leaflet/SDK里的ElevationProfile、LineOfSight等组件直接调用。服务端需要确认以下参数否则分析功能很容易返回异常结果高程单位的正确设置。如果数据是厘米级精度建模但单位误设成了米前端分析出来的坡度过大、距离参数失真。服务支持的最大/最小高程范围。有的场景只需要特定海拔区间配置分析范围可以有效节省计算资源。查询容差设置。高程查询时客户端通常会发起点查询服务端需要考虑是否允许点在像素边缘做插值计算这直接关系到分析结果的平滑度。在这些参数里最影响体验的、便是查询响应速度。如果服务在Web端做连续剖面分析卡顿优先检查数据是否构建了金字塔、服务实例是否足够、服务器与数据库之间的网络带宽是否存在瓶颈。一般来说金字塔做全之后高程查询属于轻量计算响应时间正常应在毫秒级。5. 两套流程的对比与选型建议5.1 ArcMap与ArcGIS Pro发布流程对比一览把两套流程放在一起看差异很明显对比维度ArcMap发布流程ArcGIS Pro发布流程发布入口文件→共享为→服务右键图层→共享为→Web图层服务编辑器左侧完整能力树可逐项配置发布窗格形式自动判断较多服务类型识别基本只有影像服务、地图服务、要素服务影像、高程、要素、场景等多种Web图层类型高程语义支持弱需手动配置大量参数原生支持Elevation Web Layer数据复制策略需在服务编辑器里手动指定发布窗格统一管理选择复制或引用缓存策略服务编辑器里手动配置发布窗格里默认动态可覆盖适合场景老10.x平台维护精细控制新平台、门户环境、三维分析5.2 我的选型建议如果今天让我接一个新项目我会毫不犹豫选用ArcGIS Pro流程。因为Pro不仅原生支持高程服务发布还适配未来的云和门户架构整个发布体验相比ArcMap是降维打击。但是现实中很多团队还在维护10.x系列服务器也是老配置。这种场景下强行把数据迁到Pro反而会碰到连接老版本Server不兼容、整体升级成本过高等问题。我的建议是存量项目老老实实用ArcMap流程在它的能力树里手动把影像服务配到最优新项目果断走Pro路线从一开始就把高程语义和三维分析的能力建好。此外有不少团队两个平台并存ArcMap负责老业务Pro负责新业务。这种情况我强烈建议把发布文档拆成两本一本写ArcMap的发布基线参数照旧一本写Pro的发布基线高程语义为主不要混在一起。否则在实际操作里很容易因为菜单路径差异导致配置错误。6. 发布后的检查与高频坑位排查6.1 发布后必做的六项检查服务发布完成后我基本会按固定顺序检查一遍缺一项都不放心REST端点的服务状态是“已启动”服务根元素里能看到影像/高程相关能力节点用REST端点提交一次导出或高程查询返回值正常在ArcMap或Pro客户端里加载该服务URL正确显示且速度可接受检查日志目录无ERROR级别的报错记录如果服务需要外网访问再确认端口开放和防火墙规则已调整。这套检查看起来简单但每一次都能帮我拦截到发布时没暴露的问题。比如第五项很多临时性错误只在服务器日志里出现不主动翻日志根本不知道服务其实在持续波动。影像服务发布后出现偶发性白屏多半就是这种被日志记录下来但平时没人看的问题。6.2 高频坑位与解决思路这些年遇到的高频问题基本集中在以下四类第一类数据源路径无法被服务器访问。大部分是服务器账号权限不足或数据源路径为局域网映射盘导致。解决办法用UNC路径、注册数据存储、或者干脆把数据复制到服务器本地。第二类NoData区域出现黑块或白边。正如前面说的发布前必须显式设置NoData值。如果你用的是镶嵌数据集还要关注镶嵌函数里的NoData配置是数据级配置不是图层级配置。第三类高程服务在Web端分析返回异常。优先检查单位设置、表面类型、垂直坐标系是否符合预期。很多DEM数据自带垂直坐标系信息但发布后Pro默认把它当“未知”处理需要手动在服务属性里补上。第四类服务发布后访问缓慢。这种做法有很多导致成分但最常见是金字塔缺失和实例数不足。前者回到2.1节补构建金字塔后者可以考虑调高池化配置中的实例数。还有一个隐蔽问题切片缓存与动态高程查询的冲突。如果你在Pro发布时不小心勾选“构建切片缓存”而前端是做高程分析而非底图浏览那么每次查询都命中不了缓存反而更慢。高程服务不用切片这点我在团队里耳提面命了好几次。6.3 性能调优从服务端到前端的可感知优化影像和高程服务的性能优化一般建议从三层入手服务端数据层原始栅格做金字塔和统计数据格式用压缩GeoTIFF或CRF。CRF在大影像场景下优势明显但Pro对它做了深度支持ArcMap对CRF的支持相对弱这个要按平台选。服务配置层实例数、最大请求数、缓存内存上限。对栅格服务来说“允许的每个请求的像素数上限”尤其关键设置太小会导致大范围导出被拒绝设置太大会吃满服务器内存。通常建议根据服务器内存大小和业务最大出图范围来折中。网络与前端层使用压缩格式传输、启用HTTP缓存头、适当增大代理服务器的超时时间。前端做高程分析的请求经常是高频小请求如果代理层把超时设置得太短很容易造成大量请求被中断。性能问题往往是综合性的我建议不要一上来就把锅甩给“服务端慢”。先看服务端直接REST请求的耗时一般应在几百毫秒级以内排除服务端后再去看网络和前端能省下大把联调时间。7. 写在最后的几点实操体会发布影像和高程服务这个活儿乍一看是熟练工种实际上非常讲究“发布前多想一步”。数据预处理不到位的上了服务就各种幺蛾子服务类型选错的后面每一次分析功能开发都在还债。我个人最大的感悟是ArcMap的流程适合精细控制老系统ArcGIS Pro的流程适合新业务快速落地两者不是谁完全取代谁的关系。在过渡期里把两套流程都捋清楚能少走很多弯路。而无论用哪个平台数据准备不偷懒、服务参数不拍脑袋、发布后必须做REST验证这三条原则是通用的。最后分享一个小技巧我每次新建高程服务时都会把原始的DEM文件名、坐标系、单位、NoData值记录在一个表格里跟服务名一一对应。三个月后回头维护服务或者在群里答疑时这份台账就是最好的排查依据。发布服务这件事好记性永远不如烂笔头。
