ArcGIS Mobile 9.4學習筆記九之資料篇

GIS資料及資料模型是功能操作的基礎，移動GIS應用程式也不例外。你是不是碰到過這樣的情況，實作某一功能的代碼肯定沒有問題(從幫助文檔裡Copy來的怎麼會有問題~)，但就是得不到預期的效果，這時候就應該考慮一下所用的資料了，本篇主要介紹如何建立有效的用于野外資料采集的資料模型。ArcGIS Mobile的資料編輯架構整合了功能強大的Geodatabase地理資料和事務處理模型，用來滿足各種野外資料編輯解決方案和工作流。在确定如何最好地支援ArcGIS Mobile應用程式的野外資料編輯時，充分考慮支援什麼資料，不支援什麼資料是很重要的。

• 多使用者地理資料庫

你可能已經建立了移動應用程式，這些移動程式直接連接配接移動地圖服務或者使用地圖服務本地緩存，移動地圖服務是用ArcGIS地圖文檔釋出的，其資料源來自于不同的地方，包含多種格式，如SHP，CAD或Geodatabase。ArcGIS Mobile的資料編輯隻支援ArcSDE地理資料庫，你的移動地圖資料可以包含其它資料源，但如果你想添加新要素或更新現有要素，那麼對不起，這個層的資料必須來自于ArcSDE Geodatabase中。用于ArcGIS Mobile資料編輯的要求如下:

1 資料存儲在多使用者的ArcSDE Geodatabase中2  圖層資料必須包含一個Global ID列

ArcGIS Mobile不支援建立一個地圖圖層或者更改圖層現有的屬性字段，地圖的架構必須已存在于ArcSDE地理資料庫中，這就意味着你必須事先設計并建立一個适當的資料庫，用于野外資料的采集和編輯。 

如果你預期需要采集的資料并不存在于現有的資料模型中，或者你需要采集非結構化的資訊，建議你在地理資料庫中建立一個額外的要素類用于滿足該資料的存儲。

• 移動地理資料庫

在建立野外解決方案的重要一步是地理資料庫資訊模型的設計，用于最好的支援您的野外工作流。您可以執行下列操作之一：

1 通過地理資料庫複制功能來利用現有的資訊模型2 通過提取，轉換和加載（ETL）來改變現有的資訊模型 

充分考慮野外從業人員如何描述他們所采集的資訊是采用何種方法的關鍵，你描述野外資訊的方式和建立在地理資料庫中的模型有時會有很大的不同。很多時候，野外采集的空間資訊是不連續的。比如：在一個城市公園采集資訊，從業人員從公園的某個角落開始走遍整個公園。他們可能會先采集部分湖的沿線，然後暫停并收集了公園的長椅資訊，然後恢複再采集湖岸線。在資料模型中，湖泊一般表示為多邊形要素，但是，在野外采集的時候通常當作線要素（湖的岸線），是以有必要為湖建立一個獨立的用于野外資料采集的岸線地理資料模型。你也可以定義用于轉化資料庫模型和野外資料模型的流程，這個流程就是所謂的ETL，對于上述例子，你可以定義一個流程，在移動地理資料庫向ArcSDE地理資料庫同步資料時，拼接和轉化岸線要素到多邊形的湖要素。 

1) 地理資料庫複制模型 

你可以為野外資料編輯，簡單的釋出地理資料庫的部分内容，并且使用版本來隔離野外的資料編輯和室内的編輯，但是這種方式會存在某些潛在問題。比如:如果你需要在野外同步資料，那麼你必須要穿過公司的防火牆來通路伺服器上的業務地理資料庫。但對于大多數公司來說，出于安全考慮這個是不可能的。一個更好的辦法是使用地理資料庫複制來隔離業務的資訊采集和室内伺服器地理資料庫的不斷更新。 利用地理資料庫複制技術，你可以建立一個單獨的地理資料庫版本用來存儲野外的編輯，并且定期的和地理資料庫母版本同步資料。使用這種方法，你隻需要複制部分野外工作所需要的資料(不需要整個資訊模型)。地理資料庫複制技術可以用在很多地方，比如一個分布式系統，子節點的野外從業人員不能連接配接到主節點;或者一個車載的筆記本電腦包含一個地理資料庫的複制版本，野外所做的編輯工作将在裝置停靠到車輛時進行。 

2) ETL模型

很多時候在地理資料庫中表述空間資訊的模型和野外建立和更新地理要素所用的模型有很大的不同，一個例子是把多邊形的湖模組化為岸線(線類型)，這樣可以更友善的采集要素;還有一個例子是連接配接企業資料庫的多個資料表或多個字段，存儲到野外資料庫的一個表或一個字段中，比如街道屬性資訊的存儲，通常街道的全名存儲在多個字段中(數字/字首/名稱/字尾等)。在ArcMap中，你可以使用一個表達式标簽來顯示街道全名。如果你想在移動裝置上顯示全面，那麼必須把上述的多個字段加入一個字段屬性中。 

你可以使用地理處理模式來管理移動地理資料庫和伺服器地理資料庫的ETL過程，也可以使用ArcGIS的資料互操作擴充來可視化的設計這些轉化過程。需要注意的是你所定義的轉化過程可能不是雙向的，是以需要定義一組地理處理轉化政策用于把資料轉換到移動裝置上，同時還需要把野外采集的資料轉換到伺服器地理資料庫所采用的模型。

• 移動事務處理模型 

一旦你建立了最适合野外編輯工作的地理資料庫模型，接下來就需要定義一個适當的用來管理野外資料更新的事務處理模型。在某種程度上，這由你定義的資料模型來決定，但同時也要考慮野外資料采集或編輯的小組數和怎麼隔離他們的編輯工作。在建立事務處理資料庫或者釋出地圖服務前，需要從地理資料庫的角度來了解特定事務處理模型的工作方式以及移動編輯應用程式如何同步更新。下面讨論在設計野外地理資料庫時需要考慮的一些關鍵因素。 

1) 編輯地理資料庫

如果你有較少的野外編輯人員并執行簡單的編輯任務（例如更新屬性字段），并且很少或不可能同時更新野外的同一個要素，那麼一個無版本(non-versioned)的事務處理模型可能最适合你的需要。這種方式的一個潛在問題是對于編輯人員來說直接的資料更新上傳是唯一的選擇，如果由于某些原因資料同步不夠完整，那麼這次同步就會成為一個大問題。如果使用版本，你的野外同步更新工作将會更加靈活。使用一個有版本的事務處理模型，你可以隔離野外資料編輯，添加額外的後續處理，上傳更新前可以確定資料品質。 

根據你要如何隔離野外資料編輯，你可以建立一個單一的版本用來存儲所有的野外編輯，或者你可以為每個野外編輯人員建立一個獨立的版本。如果你為每個野外編輯建立一個版本，你需要為每個編輯人員釋出一個移動地圖服務(you will need to publish a mobile map service for each editor)。一旦野外資料采集人員完成資料采集和修改，并且需要同步更新到地理資料庫中時，ArcGIS Desktop用來協同多個編輯的版本和母版本同步時的沖突(ArcGIS Desktop is needed to reconcile the version edits with the parent version) 

2）ArcGIS Mobile客戶編輯架構

ArcGIS Mobile應用程式沒有ArcMap中所謂的開始編輯，結束編輯和儲存編輯的概念。每次資料編輯都儲存在裝置上的移動地圖服務緩存中，直到你主動的決定需要和伺服器進行同步更新。你可以取消在應用程式中所做的編輯工作，這将復原所有的野外編輯工作，并且恢複到編輯前的原始狀态，但你不能一次隻撤銷一個要素的編輯工作。 

野外所做的采集、編輯、更新都存儲在移動裝置的地圖服務本地緩存中，野外從業人員不能保證始終都可以和伺服器保持連接配接，或者需要關機充電，這樣可以保證更新不會丢失。當與伺服器建立連接配接後，你可以與伺服器同步緩存中存儲的更新。當從移動裝置上傳更新時，隻有改變的部分被發送到伺服器。比如你改變了一個要素的屬性，隻記錄特定字段的改變，而不是整個記錄。當在野外更新資料的時候，帶寬和容量必須盡可能得到保護。根據你預期的資料編輯總量和與伺服器的連接配接類型(比如GPRS)，你也許希望能夠在傳回到辦公室後再把更新的内容上傳到伺服器，這樣可以保證穩定高速的網絡連接配接。