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)，你也许希望能够在返回到办公室后再把更新的内容上传到服务器，这样可以保证稳定高速的网络连接。
更多关于ArcGIS Mobile的开发：http://www.cnblogs.com/ECNU-GIS-LIUJIE
