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客戶端。本身提供的功能不多，但考慮都比較周到，儘管有缺陷，也都是技術成分的，而在產品設計方面我都很羨慕，一種說不出的不服和佩服。