1. 概述

《全国12.5米高程 DEM for WeServer 数据1.0》升级更新至2.0，这次数据的升级并没有将原来99.99%的覆盖率提升至100%，也没有将高程DEM的数据从12.5米升级为5米精度，而是对1.0版本中高程DEM数据存在的问题进行了修正。

因此，我们将《全国12.5米高程 DEM for WeServer 数据1.0》升级至2.0版本。

12.5米高程99.99%的覆盖率

2. 12.5米高程DEM数据的回顾

《全国12.5米高程DEM原始数据1.0》自发布以来就受到了大家广泛关注。

但由于数据覆盖率不够理想，后来努力对《全国12.5米高程DEM原始数据1.0》的数据进行了补充完善，将该数据的全国覆盖率提升到了99.99%，于是将该版本作为《全国12.5米高程DEM原始数据2.0》进行发布。

该数据共12360个ZIP原始数据文件，如下图所示。

共12360个ZIP原文件

12.5米高程DEM数据的原始数据为UTM投影，且数据之间存在着相互叠加的情况。

为了让该数据便于在内网中进行离线发布使用，于是我们工程师将该数据进行拼接、投影、切片和打包等一系列处理，其最后的成果即为《全国12.5米高程 DEM for WeServer 数据1.0》【点击了解】。

也就是说，全国12.5米高程DEM的原始数据只作了一次升级，共两个版本。

而全国12.5米高程DEM数据处理切片打包供WeServer调用的数据，只发布了一次，只有一个版本。

这里顺便提一下，高程数据在拼接时是基于WMTS瓦片范围检索后，在UTM坐标系下进行拼接的，这为我们本次的数据升级埋下了伏笔。

基于WMTS瓦片8_396_87范围检索拼接的数据结果

3. 发现问题

上文我们已经将全国12.5米高程数据的来龙去脉为大家作了一个简单的梳理，需要了解数据源与处理过程等详细细节，可以通过点击上文中对应的文章链接了解详情。

按理说，《全国12.5米高程 DEM for WeServer 数据1.0》【点击了解】在原始数据覆盖范围没有更新，精度没有提升的情况下，短期内应该是不会有更新的。

但自从该数据发布以后，拿到数据的客户陆续反馈高程数据存在覆盖不全的情况，起初我们以为客户指的是在东北方向那个源数据有缺失的区域，但经过与客户进行多次沟通验证之后，发现数据的确存在问题。

最后，我们不得不通过将全国12.5米高程DEM生成缩略图的方式进行全国范围的拼接，因为这样便于从整个范围检查数据的完整性。

然而，当全国高程DEM数据最后拼接完成的时候，我们发现数据果然存在有缺失的情况，如下图所示。

全国高程DEM缩略图

我们负责数据处理的工程师反复确认了12.5米高程DEM的原始数据，确认原数据是没有如此多区域有数据缺失的，那么问题到底出现在哪里呢？

4. 分析问题

如上文所述，我们发现最后打包切片的数据，即《全国12.5米高程 DEM for WeServer 数据1.0》的确存在问题，但我们反复确认过源数据是没有如此多区域存在数据缺失的。

那么问题就一定出在数据处理过程中了。

《全国12.5米高程 DEM for WeServer 数据1.0》是基于《全国12.5米高程DEM原始数据2.0》经过数据拼接、投影转换和数据切片打包处理的结果，其中哪一步是最容易导致数据缺失呢？

由于数据转换仅仅是将数据从UTM投影坐标系转换到WGS84坐标系下，而最后的切片又是基于投影转换后的成果进行处理生成的，原则上都不会导致数据出现丢失的情况。

于是，我们从数据拼接这个步骤去找原因，因为从上述的推理分析来看，只有这一步才最有可能因为数据拼接不完整而导至数据出现缺失的问题。

我们工程师从数据处理源代码着手，一步一步地进行了仔细的分析调试。

真是功夫不负有心人，最后发现是因为原始数据在UTM坐标系中存在跨带问题，从而导致拼接不完整。

也就是说，原本基于某个目标范围选择的多个高程原始数据文件，在UTM坐标系中进行拼接时，会因为数据所处的带号不同出现跨带问题，从而导致它们的坐标不一致而无法拼接到一起。

这也就是为什么出现数据缺失的区域基本都在一条线上的原因，因为他们都涉及到了UTM投影下的跨带问题，如下图所示。

UTM跨带问题导致现在真相终于大白了，那么该如何解决这个问题呢？的数据缺失

5. 解决问题

如上文所述，12.5米高程数据最后处理出来的结果导致产生数据缺失的原因，是因为在UTM坐标系投影下进行拼接时，会因为跨带问题导致数据拼接不完整。

那么如何解决个问题呢？

问题的核心关键点在于，我们一定要避免在UTM坐标系下进行高程DEM数据的拼接。

因此，我们最后的解决方案是，将处理该数据的流程从原来的"先拼接再投影最后切片"的顺序，更换为"先投影再拼接最后切片"，这里的投影是指将12.5米高程DEM原始数据的UTM投影转换为WGS84坐标系的经纬度投影。

这样一来，UTM投影坐系下拼接的跨带问题就成功避免了，因为在WGS84坐标系下不会有跨带问题，当数据在进行拼接时就不会现在数据丢失的情况了。

这意味着，我们需要将全国12.5米高程DEM数据进行重新处理，这是一个比较消耗时间的事，公司的数据处理服务器时刻都在马不停蹄的运转，如以下视频所示。

全国12.5米高程DEM数据重投影与切片处理中

最后的数据处理成果，即为《全国12.5米高程 DEM for WeServer 数据2.0》，将该数据的处理结果生成缩略图之后，可以看到之前的数据缺失问题已经得到了完美的解决，如下图所示。

处理成果缩略图

6. 《全国12.5米高程 DEM for WeServer 数据2.0》生产处理流程

我们对《全国12.5米高程 DEM for WeServer 数据1.0》经过发现问题、分析问题和解决问题之后，终于完成《全国12.5米高程 DEM for WeServer 数据2.0》的处理，并整理存放于288TB数据阵列柜中。

其中，标记为"存在数据缺失问题"的数据，为《全国12.5米高程 DEM for WeServer 数据1.0》数据处理的中间过程与结果，如下图所示。

数据备份

现在，我们来总结一下《全国12.5米高程 DEM for WeServer 数据2.0》的生产处理过程。

首先，对原始数据"04全国12.5米NASA高程DEM_A原始数据_ZIP文件_UTM投影"进行解压，由于解压后的文件比较多，我们只将TIF文件提取保存在"04全国12.5米NASA高程DEM_B解压文件_TIF文件_UTM投影"文件夹中。

UTM原始数据样例

然后，将解压后的TIF文件从原始的UTM投影转换为WGS84坐标系，并将投影转换后的结果保存在"04全国12.5米NASA高程DEM_C投影转换_TIF文件_WGS84"文件夹中。

投影转换后的数据样例

接下来，将投影转换后的结果基于标准的WMTS瓦片范围进行拼接，并将拼接后的结果保存在"04全国12.5米NASA高程DEM_D拼接文件2.0_WGS84"文件夹中。

拼接后的数据样例

最后，基于拼接的结果基于标准的WMTS瓦片范围进行切片，并打包为用于WeServer可以发布的DAT文件格式，保存在"04全国12.5米NASA高程DEM_for WeServer 数据2.0"目录中。

7. 数据样例说明

在上文中的数据生产处理流程说明中，为了便于理解，我们是以标准的WMTS瓦片"8_396_87"的范围作为示例说明的，该瓦片范围的位置如下图所示。

WMTS瓦片8_396_87

打开瓦片的"显示网格"功能，我们也可以通过查询定位到目标位置，不过需要说明的是在微图中的瓦片级别编号比较准的WMTS瓦片编号大2，行列号分别大1，因此定位WMTS瓦片"8_396_87"时，应该转换为"10_397_88"，如下图所示。

查询定位到目标瓦片

通过将WMTS瓦片"8_396_87"与12.5米高程原始数据接图表进行叠加后，小红框的范围为瓦片所在位置，如下图所示。

瓦片范围与原始数据接图表叠加

放大之后，可以看见WMTS瓦片"8_396_87"与多个12.5米高程DEM原始数据文件的范围相交，这里我们选择相交区域范围相相对比较大的"AP_09286_FBD_F0550_RT1"为例。

红框区域为目标瓦片范围，有阴影的区域为"AP_09286_FBD_F0550_RT1"高程数据文件范围，如下图所示。

AP_09286_FBD_F0550_RT1文件范围

从上述示例数据范围可以看出，我们需要切片的目标范围通常是与多个原始高程数据范围相交的，这就是为什么要将高程数据进行拼接的原因。

而将多个高程数据文件进行拼接时，一定不能在UTM坐标系下进行，因为会由于跨带的问题导致个别数据不能拼接到一起，这就是为什么我们要先将数据从UTM转换为WGS84，然后再进行拼接的原因了。

8. 总结

以上就是将《全国12.5米高程 DEM for WeServer 数据1.0》升级至2.0的全部内容，主要包括了对12.5米高程DEM数据的回顾，以及对1.0数据中存在问题的分析与解决大概过程的梳理。

如果你对本文中所述的内容有任何疑问，请联系我们客服或拔打24小时热线电话400-028-0050进行反馈！