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格式,方便下次打开时内容和状态读取。
这趟AE之旅到此就结束了,简单说,AE的球在技术上并没有太多先进和有特色的地方,或者我能力有限,没看出来。不过在产品上,借助Online的强力支持,在产品体系的完善和定位上,落子很很到位,提供了这样一款轻量级的Online 3D客户端。本身提供的功能不多,但考虑都比较周到,尽管有缺陷,也都是技术成分的,而在产品设计方面我都很羡慕,一种说不出的不服和佩服。