共享数据的三种主要方式：
数据共享。数据共享是一种数据仓库的方法，使大范围的用户能够获得数据。数据从各个数据所 有者处获得，并装载进一个集中的数据仓库。然后，就可以通过基于Web的数据浏览器将数据提供给 数据共享联盟的每一个成员，或者用不同的格式分发给众多数据使用者。

数据复制。这种方法一般适用于用户数量较大、地理分布较广、而且还需要实时地访问相同数据 的情况。为了能够减少网络负荷，并提高数据访问的性能，可以把数据复制给位于不同地点的多个数据库。数据库在定期同步（通常是每晚）进行更新。

分布式数据访问。在这种情况中，数据仓库只是简单地作为一个数据分发的节点，数据仍然保存 在数据所有者的服务器中，而数据仓库所起的作用是通过一个LAN、WAN或Intranet动态地连接到提 供者的数据。因为不同的数据库可能有不同的数据格式（如ESRI ArcSDE、Oracle Spatial等），空间数据的ETL（Extract、Transform、Load）工具必须能够读出所有这些要访问或提供的数据格式。不同于数据复制和数据共享的是，分布式数据访问方法不需要维护数据的多个拷贝。

本文将具体阐述数据复制、数据共享或分布式数据访问涉及到的一些问题。

数据共享和复制中的问题

一旦同意进行数据的共享和复制，就要面临数据更新维护的问题。空间数据是在持续地改变的， 例如新的基础设施、新的组织结构、或更精确的数据的收集，这些都会带来数据的变化。要维持数据 库的现势性，就要求各个数据“拥有者”必须与共享单位交换最新的数据。这可以通过以下两种途径 来实现：

数据完整装载。这是一种最直接的方法，即：先将当前的数据移去，再用新的数据完全替换。但是这种方法往往因为庞大的数据量而不够现实，因为海量数据的传送和装载所需的时间相当长，将导 致用户无法正常地访问数据库。

变更增量更新。用这种方法只更新发生变化（修改、删除和增加）的数据，因而只要求对少量的 数据进行传输。由于数据量小，变更增量更新所要求的装载时间也大大减少了。不过，更新的过程比 数据完整装载方式要复杂得多。

对于需要与外部用户（在其管理范围之外）共享数据的单位来说，“变更增量更新”方式可能将产 生一系列潜在的问题，例如数据的所有权、要素ID的冲突、坐标精度和数据版本等。通常，数据仓库的格式与工作数据库（如ESRI Geodatabase，Oracle Spatial，MapInfo TAB，GeoMedia，AutoCAD等）也会存在不同。而且，数据仓库和应用数据库的数据模型（或模式）也可能不同。可以通过脚本（Posting scripts）来控制不同数据库之间的转换，并且这种脚本需要能够处理这些不同的配置问题 和格式问题。参见图1。

图2：数据复制举例

数据格式（Data Formats）：当数据仓库和工作数据库的格式不一样时，脚本必须可以解决格式转换。如果某些工作数据库是CAD格式（AutoCAD、MicroStation），则格式转换可能会更加复杂，因为 用户可能希望符号体系、文本位置保持不变。并且，由于CAD格式不能处理数据库中的大数据范围， 所以还会要进行分片（tiling）操作。

模式映射（Schema Mapping）：在数据复制的情况下，数据库之间的数据模式一般是完全相同的，也就是说，在不同数据库之间同一要素（feature）的表格和属性是一一对应的。而数据共享往往涉及 复杂的模式映射，可能存在一个要素类映射到多个目标要素类，或者反之。在一般情况下，要用属性 值作为映射的关键字，例如：通过“Type”属性可以控制要素如何从一个源表映射到目标数据库中的 几个不同的表，参见图4。

　　模式映射必须是可逆的，转入工作数据库的要素还要能够转回为数据仓库中同样的要素。

要素的惟一标识符（Unique Feature Identifiers）：为了简化数据的更新过程，要通过ID来跟 踪哪些要素发生了变更。在理想状态下，所有的要素都有一个惟一标识符，例如UK OS TOID、Microsoft’s UUID、或者Geographic Data BC GOID等，这些标识符在其所有要共享的数据中是公共的。对于数据复制方式这是容易实现的，因为它的数据库都是复制而来，并且数据归属于同一个单位。而在与外部组织机构进行数据的共享时，或者数据格式、数据模式有所不同时，这种公共ID就不容易 实现。虽然大多数的数据库也要求有要素的惟一标识符，但它们在各数据库之间往往不能够相互兼容， 包括数据类型不同（如integer，character）、数据长度不同等各种情况。在这种情况下，有必要建 立一个ID参照表，以便使工作数据库中的标识符能与数据仓库中所用的标识符相匹配，同时要标明 ID的所有者，即来源。如果又多个工作数据库可能产生新要素，那么就还要建立起一套方法来保证所 有的ID都是惟一的。

　　如果在数据共享联盟内难以保证维护公共的ID，那么就必须保证要素是相互匹配的，导入要素时必须能够根据图形或属性与数据仓库中已有的要素相匹配，这种计算量甚至与数据完整装载是相当的。数据所有权（Data Ownership）：澄清数据的所有权对于消除潜在的冲突是非常重要的。例如：“电 杆”数据的所有者是公共设施部门、电缆公司还是电信部门？哪个单位具体负责电杆的位置和它的属 性数据的维护？数据的所有权也可能是要共享的。例如：市政当局可能要求精确的电杆位置，而公共 设施部门可能就只需要电杆的相对位置，对于他们来说属性数据可能更为重要。

坐标系和精度（Coordinate Systems and Accuracy）：工作数据库和数据仓库之间一般都是采用不同的坐标系统。例如：如果数据仓库比工作数据库的覆盖范围大，那么数据仓库可能采用的是地理（经度/纬度）坐标系，而工作数据库则可能采用笛卡尔坐标系（如UTM）。坐标转换算法可能导致 坐标的偏移，但一般都是可以忽略的。要考虑的应该是数据库中坐标的分辨率，很多数据库存储的坐 标都是整型数据，并且坐标的分辨率通常都是根据空间数据的覆盖范围来决定的。如果工作数据库的 坐标分辨率和数据仓库中的不一样，数据可能会因为来回转换而产生明显的坐标错位。由此产生的一 个问题就是在坐标取整的过程中，相邻点可能会变成重复点。而一个要素如果具有重复点，往往是非 法的、会被数据装载过程舍弃掉。另外，还有可能因为不同的数据库有不同的坐标维，结果造成Z坐 标的丢失。

事务处理表（Transaction Tables）：事务处理表是跟踪对数据所做的改变的一组记录，也就是发生了修改、增加或删除操作的要素的列表。它通常记录的是所做改变的类型（修改、删除或增加）和其它元数据。事务处理表还可以用于跟踪要素的办更历史，包括图形和改变和属性的改变。通常，变更前后的记录是采用一种开放的格式（如GML2）、作为BLOB存储到数据库中。这些变更记录的处理顺 序是非常重要的，因为在写入事务处理表之前，可能正在对同一个要素做好几项变更。现在已经有一 些软件可以帮助生成事务处理表，如ESRI公司的Job Transaction Server，或GeoMedia Transaction Manager，但这些软件都还需要再进行用户化。

版本（Versioning）：许多空间数据库都支持长事务版本。需要注意决定的是到底要如何才能成为一个新的版本；尤其是在数据仓库中，如果根据工作数据库的每次更新都产生一个单独的版本的话，那么版本数量将会变得非常大。

数据检查（Data Validation）：在数据共享联盟中不同的数据提供者可能会有不同的质量标准。可以利用脚本确保原始数据符合议定的数据模型和数据标准。如果某些要素之间的关系非常重要，也必须进行检查，例如，多边形要求有相应的标识点，或者反过来标识点也要求相应的多边形。脚本也能配置数据清理功能，例如去除无用的要素类型，清除多余的属性数据或CAD数据（如图例和标题栏）。

数据安全及所有权数据（Data Security and Proprietary Data）：在数据共享联盟中，往往有些成员只能访问指定的有限区域的数据。虽然这并不影响到数据的更新过程，但数据的分发操作必须符合这些数据权限规定，数据的所有者必须能确定只有授权用户才能访问到被限制的数据。

实现
　　以下是使用Spatial ETL（Extract，Transform，Load）工具来控制数据复制和数据共享的一些组织机构：

NIMA（国家图像与地图测绘局）数据共享＆复制

Southwest Bell 数据复制

Geographic Data Technologies 数据共享

BC Integrated Cadastral Information Society 数据共享

IHS Energy 分布式数据访问

　　实现数据共享和数据复制的方案，是使用可配置的Spatial ETL工具，如FME。以前，Spatial ETL工具都被用作直接的数据转换程序。脚本控制着从源格式到目标格式的映射以及模式映射。而且， 如果Spatial ETL工具能在转换过程中对数据进行操纵，例如坐标变换、剪切、构面、节点过滤、以 及属性操作等，将会更加有用。对于数据的复制和共享来说，脚本应该是可配置的，这样前面提到的 几个问题才能得以解决，如读取事务处理表、映射模式和处理不同的更新类型（改变、增加、删除）。

　　开发脚本的工作量基本上完全取决于数据仓库和工作数据库之间的模式差异、以及前面提到的那 些问题有哪些要考虑。工作数据库和数据仓库之间的模式越是相似，脚本就越简单。

　　当对较多来源的数据进行共享时，利用GML2这样的中性的、标准的格式来建立数据分发体系往往 是有益的。数据分发格式的数据模型可以尽量地反映数据仓库的模式，简化质检和数据加载过程，图 5就是一个通过中间数据分发格式来进行数据共享的例子。数据的提供者负责利用它们拥有的Spatial ETL工具将数据输出到分发格式，数据装载是使用标准化的脚本，这个脚本只需要处理数据分发格式 和数据仓库中的模式。这种方法既可用于数据的完全加载，也可用于变更增量加载。

　　除了利用脚本控制更新过程以外，还存在数据的初始装载问题，即：覆盖区域内的所有要素都从数据仓库加载到工作数据库。当要提取穿越覆盖范围边界的要素时，或者对其进行裁剪——那就不能在工作数据库中对它进行编辑，或者作为一个完事的要素进行转移——这样会产生一个“长毛”的区域，要素可能延伸到覆盖范围（AOI, Area Of Interest）之外。这也是UK Ordnance Survey分发MasterMap时采用的办法。

　　分布式数据访问大大地简化了这个过程。数据的所有者要负责提供他们同意共享的数据的服务，数据仓库只是相当于一个指向多个数据服务器的动态链接。脚本被用来从各个数据服务器中提取数据、然后按照公认的模式和格式进行分发。数据只在有用户请求的时候才会被传输，不需要另外考虑数据 更新过程。不过，数据访问速度会受到使用的网络类型、数据服务器的性能等因素影响，这些往往是 没有太大控制余地的。

总 结
　　本文在前面提到的方法在多个项目中得到了成功的应用，对于实现数据共享或数据复制所要解决的一些实际的问题也都进行了讨论。

然而，还有一些可能更难解决的问题：
数据复制与共享，数据的传递通常会同时包括这两个方面；
政治问题。数据所有权、对公共ID及其它一些问题的协议，通常不是简单的技术方面的问题，更 是政治方面的问题，因而更难以解决。

　　远程数据访问消除了复杂的数据更新周期，也不需要考虑数据质量的问题，从而减少了数据仓库的复杂度。但对硬件和网络基础设施的要求却更复杂，数据访问性能可能成为关键问题。