关于上次地形切片之后纬度偏移1.7度的问题偶然解决

最新推荐文章于 2023-06-30 11:23:02 发布

xinleicol

最新推荐文章于 2023-06-30 11:23:02 发布

阅读量560

点赞数 3

分类专栏：日常写bug

本文链接：https://blog.csdn.net/xinleicol/article/details/115282505

版权

日常写bug 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

关于上次地形切片之后纬度偏移1.7度的问题偶然解决

0. 前言

前两天对原始地形进行填洼处理之后，使用cesiumlab进行切片，发现纬度整体像北偏移了1.7度左右，当时一直也没找到原因，今天在偶然的原因下，发现了上次出现的问题。
上次问题原文链接：记录一个我一下午没有弄明白的问题——填洼处理+地形切片后坐标纬度整体向北发生了偏移

1. 发现可能原因的过程

由于对.shp文件的格式有些疑惑，就开始在网上查找资料，谷歌上解释如下：

Shapefile使用点、线、多边形存储要素的形状，具有简单、快速显示的优点；缺点是不能存储拓扑关系。一个shapefile是由若干个文件组成的，空间信息和属性信息分离存储，所以称之为“基于文件”的GIS数据格式。

觉得不够详细，继续查找，然后发现一片文章，标题还挺有意思，链接如下：
Shapefile 必须死
其中有一个关于空间参考的编码说明引起了我的注意，原文是：

图中又出现了一个叫「EPSG」的东西，EPSG 是个组织维护着空间参照对象的数据集，它将不同空间参照系配置了一个唯一 ID，比如「EPSG:4326」代表著名的 WG4-84 地理坐标系，「EPSG: 3857 」就代表 WGS-84 椭球体 - web 墨卡托投影坐标系。你可以在这个网站上查询不同 ID 代表的空间参照系信息。

关于EPSG:4326和EPSG:3857，一个是地理坐标系，一个是地图的墨卡托投影坐标系，两者都是基于WGS84椭球体，一个是经纬度表示的球面坐标系，一个是xy表示的平面坐标系。
那么，cesiumlab在地形切片的过程中是可以选择参考坐标系的，当然也可以不选，软件默认会从影像里面提取。之前发生的偏移的可能是因为没有手选参考坐标系。所以也许是坐标系的问题。

2. 结果发现

于是，我将ArcMap填洼处理后的地形影像重新导入cesiumlab中，手动选择坐标系：EPSG:3857
切片之后，查看meta.json文件中的坐标范围，果然发现坐标已经正常了：

选择3857后的坐标：
{“east”:118.795133829117,“north”:31.9241988658905,“south”:31.9055306911469,“west”:118.773161172867}

没选3857，默认情况下的坐标：
{“east”:118.795133829117,“north”:32.0971262454987,“south”:32.0784151554108,“west”:118.773161172867}

假设，假设我使用4326，也就是经纬度地理坐标进行切片会发生什么，我尝试了一下，最后的结果是这样的，meta.json文件中：

{“east”:13224216.796875,“north”:3753363.515625,“south”:90.0,“west”:180.0}

很明显是错的，那么我上次之所以没有发现问题出现的原因是因为，在我对填洼处理之前的地形进行切片时，是没有选择参考坐标系的，是让软件默认从文件中读取的，而那次的坐标也是没有发生偏移的，况且在ArcMap中参考坐标系也是没有改变的，所以我当时认为并不是坐标系的问题。
最后，来验证一下切片后的坐标加载进去到底有没有问题吧，我把地形加载进去之后，发现的确回到了之前的位置。（而且的确是填洼处理之后的影像，因为把我的湖的坑的地形给拉高了，小声比比，这地形精度让效果有很严重的塑料感。）
在之后，我把填洼前的影像利用cesiumlab再次进行了切片，无论是默认的参考系，还是EPGS:3857，最后切出来的结果坐标都是一样的，这就又引出了一个问题了。

3. 总结

关于参考坐标系的问题，对于学地球、地理科学的人来说肯定很重要，本人在这方面的知识还有所欠缺，最后才导致了上篇博客一直找不到原因的的问题。
关于填洼处理前后，默认切片出的结果会发生偏移的问题，我没打算继续深究下去，提供几种猜想。第一，可能是在ArcMap处理之后，文件中地理坐标发生了改变（这个和上篇博客的猜想类似）；第二，可能是在处理之后，文件中的坐标参考系参数已经丢失（可能性不大）。