ArcGIS Earth，一款轻量级的三维地球应用。因为工作关系下载试用了半天，正好借这个机会简单研究一下ArcGIS Earth的大概思路，特别是地形数据的组成和影像数据的加载，在这总结整理一下。下面ArcGIS Earth简称为AE。
好了，本文先说点人话，接着上硬菜，最后再上点调味小菜。废话不多，说走就走。
本人用的是官网最新版本，刚好发布一周，界面风格和VS的神似，相信开发人员会有一种似曾相识的感觉。不过安装过程并不顺利，安装过程中提示我安装.Net Framework4.5.2版本及以上，小E君，我可是装了VS2012的操作系统，尽管不用C#，但你这版本要求也是有点过分啊，而且需要自己手动安装Framework。最悲催的是升级完Framework后发现VS都无法使用了，得不偿失，只好卸载VS后重新安装，一番波折，不能忍啊。
安装完成后，先简单的浏览一下所有功能，总体操作比较流畅，不过鼠标操作上有较大的区别，竟然用鼠标右键来控制地球的仰角，个人觉得这有些不妥。常见的地球类应用基本都是用鼠标滑轮来控制该操作，这样右键可以用来扩展一些菜单选择。
菜单栏设计的也很简洁美观，产品设计师确实非常用心，非（因）常（为）容（功）易（能）上（不）手（多）。比如添加图层，结合ArcGIS强大的Online服务，只能让哀家一声长叹空悲切。吐槽一下，发布一款客户端产品，如何能让用户第一时间就能体验，而不是自己去找数据服务的url，甚至还需要用户自己来配置这些数据服务，看似简单的一个事情，其实需要多个部分和团队之间的协调，反而变得无法解决，时间成本太大，协调后不得不做舍去，效果也大打折扣。个人自扫门前雪，这也是万般无奈。再看看小E家，试着搜索一下关键词Population，下面就是一堆人口地图服务让你选择。
打开第一张在线地图服务，一张美国人口密度的专题图，点击加载后就可以添加到三维球上。
这样最基本的地图数据加载就可以很简单的实现，看了一下该地图为墨卡托投影，我找了一个经纬度的地图服务USA MapServer，EPSG为4326，发现也可以在地球上叠加。哎呦，不错哦，两种坐标系都可以支持，这是需要一些特殊处理的。不过一看请求地图切片的Url发现，原来客户端请求中包括动态投影的信息，最终服务端会把该4326的地图服务转换为3857的墨卡托切片返回给AE。由此可见，AE会先请求该地图服务的json信息，这样就能知道该地图服务的投影信息，然后统一请求和加载墨卡托投影对应地图切片。如此，则很大可能下，AE下的地球网格是按照墨卡托而不是经纬度，且AE本身不一定支持经纬度下地图切片的转换，所以全部切片都是直接使用服务端处理好的Tile。至于这种服务端来做动态投影的方式，孰优孰劣就不探讨了。
既然说到了地球网格，那就看看南北极的效果，发现AE的南北极的效果不错，效果平滑，而南北极因为会缩为一个点，纹理效果通常不太理想，难道AE对南北极做了特殊处理，另外补了一次？最后发现挺有意思的，小E也是心机婊啊，为了避免这个问题，南极的影像是全白的，所以只是看不出来而已。叠加了一个非纯色的南极地图服务后，问题变暴漏了。
地图叠加功能虽然有点美中不足，通过产品设计避免了技术上的问题，不过总体上还是体现了ArcGIS丰富的地图服务，同时也能叠加KML等其他数据，具有很好的扩展性，不过KML也有缺陷，不支持中文，效果如下：
OK，上手AE，总体感觉还是不错，基本的功能都可以很好的使用，即使没有太阳和光照，但是还是有大气层和星星的。提供了截图这个比较实用的功能，也提供了打印这个没意思的鸡肋。
我觉得最用心的是BaseMap这个控件,一目了然，而且下面的地形框非常人性化的开启了地形功能，另外，如果你代理成美国的IP，它会根据你当前的网络环境提供对应的美国地图服务，还是很周到的设计。
好了，既然我都已经红色高亮了地形了，你应该知道下面就是本文的核心了，AE的地形数据到底是什么结构的？好吧，先说结论，地形实现的很一般，不过学到了MRF和LERC这两个技术。
当你选择加载地形时，AE会先请求获取地形的json信息，同样地形数据也是墨卡托投影下的切片，一般情况下地形数据都是经纬度的切片，要是切成墨卡托的网格，也是很花功夫的，毕竟是全球数据。这样我们也知道地形数据的url中xyz对应的范围了。
下载一个地形数据来看看里面是什么内容，谁叫咱就好这口呢。这里说明一下，该切片应该是符合MRF的规范。MRF是Nasa提供的一种面向云存储的数据格式，既保留了传统影像数据的紧凑，有吸取了网络环境下切片数据的灵活性，对这个数据格式我也不是很熟悉。对于一个MRF规范的数据，里面会有一个Header头，记录该数据的属性信息，比如数据大小，长宽等。这样即使没有数据，该切片都是1kb的Header信息，但没有数据内容，或认为数据内容为零。下载一个大一点的地形数据来研究，发现所有地形数据的头都有一个CntZImage的标识，这也是唯一的线索。这里自然稍微松了一口气，既然小E这样的大公司也没有加密和密钥的设计，看来产品经理对待程序猿不能太苛刻，不然人家可是会变身金刚模式的。
CntZImage这个标识什么意思呢？查了一下有点绕，但原理比较简单，考虑到这是地形数据，个人猜测应该是Contrast Z Image的意思，提供一个绝对值M，Z就是高程的意思，而Image中每一个点则是相比绝对值M的一个差值。这个思路类似Google 的High water mark，可以提高压缩效率。不过猜想归猜想，还得自己去证明。
最终发现地形切片是257*257的范围，应该是为了边界缝隙的设计，里面采用了ESRI自己申请专利但开放的的有损压缩算法LERC（Limited Error Raster Compression）。该算法的优点就不在这说了，大家可以自己来了解。而且LERC已经在Nasa的MRF规范和GDAL中支持，该算法在压缩和解压中对CPU的消耗较低，尽管可能是有损的，但压缩效率和jpeg等相当，个人认为比较适合网络这种环境下，特别对js端解压缩的性能消耗
不卖关子了，ESRI在Github上提供了lerc的C++源码，编译后对地形数据解压缩，你会获取该Tile的属性信息，比如范围，后面则是Image的信息，这里可以是RGBA，也可以是float等类型，高程值自然是float类型，解析后对应的值如下：
好了，地形数据已经解析完毕，本质上就是一个DEM切片数据，并没有三角网的信息，所以AE的地形很可能是采用高度图的方式，而且并不是基于特征点构网，实时构造一个最简单的网格，所以地形效果一般。
我觉得小易可能也是万万没想到，程序员A提供了Lerc的源码（不过必须要提供，因为是开源的），程序员B用Lerc来生成地形数据，程序员C不小心知道了两者之间的秘密，这样AE的地形数据就存在泄漏和解析的可能性。
对MRF和LERC介绍的不详细，主要说了在地形数据中两者的位置和实现思路。对这方面感兴趣的可以看一下这篇论文《MRF as a Cloud Optimized Raster Format and LERC Compression》，写的很简单明了，能够对MRF格式有一个简单的认识，其实我的理解就是一个3DTiles的思路，一夜之间这种思路的格式就烂大街了。如果你亲自调试一下LERC程序解析地形文件，你应该会对这篇论文有一个不错的解读。
这样AE的地形数据就破解了，而影像数据就是常用的地图服务，这里就有一个有意思的地方，不同的影像数据可能是有偏移和无偏移的，这样在地球上会有一些位置对不准的情况，只能说Ma De in China。
好了，下面简单介绍一下AE的其他方面，POI检索功能一般般，很多中文地物支持的并不充分，相反英文的话应该还不错，找了几个都可以。
量算也不错，会考虑地形情况下的高度因素，而并不只是简单的两点距离。不过最赞的还是矢量贴地效果，而且还没有锯齿，效果不错。
最后是AE的图层管理器，也比较成熟。最后保存在ArcGISEarth.workspace中，json格式，方便下次打开时内容和状态读取。
