《地理信息系统概论》汤国安第5章 空间数据组织与管理

《地理信息系统概论》汤国安第5章 空间数据组织与管理 5 空间信息技术包括空间数据获取、空间数据处理和空间数据应用技术三个部分，而空间 数据管理必将成为上述三种技术的基础和核心。在数据获取过程中，空间数据库用于存贮和 管理空间信息及非空间信息；在数据处理系统中，它既是资料的提供者，也可以是处理结果 的归宿处；在检索和输出过程中，它是形成绘图文件或各类地理数据的数据源。然而，空间 数据以其惊人的数据量及其空间上的复杂性，使得空间数据的组织与管理给传统数据库系统 带来巨大挑战。本章主要介绍空间数据库在数据管理组织方式、空间索引、空间查询语言等 方面的技术和特点。 5.1空间数据库概述 通用数据库作为文件管理的高级阶段，是建立在结构化数据基础上的。而空间数据具有 其自身的特殊性，这就使得通用数据库管理系统在管理空间数据时表现出较多不相适应的地 方，从而空间数据库应运而生。 5.1.1 数据库基础 数据库是在应用需求推动下、在计算机软硬件下基础上，经历了人工管理阶段和文件管 理阶段之后发展而来的。 数据是描述事物的符号记录，可以是数字形式，也可以是文字、图形、图像、声音、语 言等多种表现形式。人们收集并抽取出应用所需的大量数据后，将其保存起来以供进一步加 工处理，抽取有用信息。随着科学技术飞速发展，人们的视野越来越广，对数据的需求量急 剧增加。过去人们把数据存放在文件柜里，现在借助计算机和数据库技术就能保存和管理大 量复杂的数据。数据库是长期储存在计算机内的、有组织的、可共享的数据集合。数据库中 的数据按一定的数据模型组织、描述 和储存，具有较小的冗余度、较高的文件系统 数据独立性和易扩展性，并可为各种 用户共享。 目前，数据库领域中最常用的数 据模型有四种：层次模型网状数据库管理系统 层次数据库管理系统 （Hierarchical Model）、网状模型 （Network Model）、关系模型 （Relational Model）和面向对象模型面向对象数据库管理系统 关系数据库管理系统 （Object Oriented Model）。其中层次 模型和网状模型统称为非关系模型。 非关系模型的数据库系统在20世纪 70年代至80年代非常流行，在数据 对象关系数据库管理系统 库系统产品中占据了主导地位，现在 已逐渐被关系模型的数据库系统取 . 图5.1 数据模型演化 代。20世纪80年代以来，面向对象的 方法 快递客服问题件处理详细方法山木方法pdf计算方法pdf华与华方法下载八字理论方法下载 和技术在计算机各个领域，包括程序 设计 领导形象设计圆作业设计ao工艺污水处理厂设计附属工程施工组织设计清扫机器人结构设计 语言、 软件工程、信息系统设计、计算机硬件设计等各方面都产生了深远的影响，也促进数据库中 面向对象数据模型的研究和发展。数据库数据模型发展如图5.1所示。 5.1.2空间数据库 地理信息系统的数据库（简称空间数据库或地理数据库）是某一区域内关于一定地理要 素特征的数据集合；是地理信息系统在计算机物理存储介质存储的与应用相关的地理空间数 据的总和，一般是以一系列特定结构的文件的形式组织在存储介质之上的。换句话说，空间 数据库是地理信息系统中用于存储和管理空间数据的场所。空间数据库系统在整个地理信息 系统中占有极其重要的地位，是地理信息系统发挥功能和作用的关键，主要表现在：用户在 决策过程中，通过访问空间数据库获得空间数据，在决策过程完成后再将决策结果存储到空 间数据库中。空间数据库的布局和存储能力对地理信息系统功能的实现和工作的效率影响极 大。如果在组织的所有工作地点都能很容易地存取各种数据，则能使地理信息系统快速响应 组织内决策人员的要求；反之，就会妨碍地理信息系统的快速反应。如果获取空间数据很困 难，就不可能进行及时的决策，或者只能根据不完全的空间数据进行决策，其结果都可能导 致地理信息系统不能得出正确的决策结果，可见空间数据库在地理信息系统的意义是不言而 喻的。 空间数据库与一般数据库相比，具有以下特点： ? 数据量特别大，地理信息系统是一个复杂的综合体，要用数据来描述各种地理要素， 尤其是要素的空间位置和空间关系等，其数据量往往很大； ? 不仅有地理要素的属性数据（与一般数据库中的数据性质相似），还有大量的空间数 据，即描述地理要素空间分布位置的数据，并且这两种数据之间具有不可分割的联系； ? 数据应用广泛，例如地理研究、环境保护、土地利用和规划、资源开发、生态环境、 市政管理、道路建设等。 空间数据库的组成，从类型上分有栅格数据库和矢量数据库两类，其中栅格数据包括航 空遥感影像数据和DEM数据；矢量数据则包括各种空间实体数据（图形和属性数据）。如 图5.2所示。 空间数据库 数字影 空间对象 高程 模型 像 图形 属性 5.2 空间数据管理 图5.2 空间数据库组成 5.2.1 空间数据的基本特征 1. 空间特征 每个空间对象都具有空间坐标，即空间对象隐含了空间分布特征。这意味着在空间数据 组织方面，要考虑它的空间分布特征。除了通用性数据库管理系统或者文件系统关键字的索 引和辅关键字索引外，一般都需要建立空间索引。 2. 非结构化特征 在当前关系数据库管理系统中，数据记录中每条记录都是定长的（结构化），数据项不 能再分，不允许嵌套记录。而空间数据不能满足这种定长（结构化）要求。若将一条记录表 达一个空间对象，其数据项可能是变长的，例如一条弧段的坐标，其长度是不可限定的，可 能是两对坐标，也可能是成百上千对坐标；另一方面，一个对象可能包含另外的一个或多个 对象，例如一个多边形，可能含有多条弧段。若一条记录表示一条弧段，则该多边形的记录 就可能嵌套多条弧段的记录，故它不满足关系数据模型的结构化要求，从而使得空间图形数 据难以直接采用通用的关系数据管理系统。 3. 空间关系特征 空间数据除了空间坐标隐含了空间分布关系外，还通过拓扑数据结构表达了多种空间关 系。这种拓扑数据结构一方面虽然方便了空间数据查询和空间分析，但另一方面也给空间数 据的一致性和完整性维护增加了复杂度。特别是有些几何对象，没有直接记录空间坐标的信 息，如拓扑的面状实体仅记录组成它的弧段标识，因而进行查找、显示和分析操作时都需要 操纵和检索多个数据文件。 4. 多尺度与多态性 不同观察比例尺具有不同的尺度和精度，同一地物在不同情况下也会有形态差异。如， 城市在空间上占据一定的范围，在较大比例尺中可以作为面状空间实体对象，而在较小比例 尺中，则是作为点状空间对象来处理的。 5. 分类编码特征 一般情况下，每个空间对象都有一个分类编码，这种分类编码往往是按照国家 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 ，或 者行业标准、地区标准来应用的，每一种地物类型在某个GIS中的属性项个数是相同的。因而在许多情况下，一种地物类型对应一个属性数据表文件。当然，如果几种地物类型的属 性项相同，也可以多种地物类型共用一个属性数据表文件。 6. 海量数据特征 GIS中数据量非常庞大，远大于一般的通用数据库，可称之为海量数据。一个城市地理 信息系统数据量可达几十GB，如果考虑影像数据的存储，可能达到几百个GB。这样的数 据量在城市管理的其他数据库中是很少见的。由此，需要在二维空间上划分块或图幅，在垂 直方向上划分层来进行组织。 由于空间数据存在非结构化特征、空间关系特征，使得通用数据库管理系统在管理空间 数据时，面临较多问题。 ? GIS需要一些复杂的图形功能，一般的DBMS不能支持。 ? DBMS一般都难以实现对空间数据的关联、连通、包含、叠加等基本操作。 ? 地理信息表达复杂，表达单个地理实体需多个文件、多条记录，或许包括大地网、 特征坐标、拓扑关系、空间特征量测值、属性数据的关键字以及非空间专题属性等，一般的 DBMS也难以支持。 ? 具有高度内部联系的GIS数据记录需要更复杂的安全性维护系统，为了保证空间数 据库的完整性，保护数据文件的完整性，保护系列必须与空间数据一起存储，否则一条记录 的改变就会使其他数据文件产生错误。这是一般的DBMS都难以保证的。 ? GIS中空间数据记录是变长的（存储的坐标点的数目随空间对象的变化而变化），而 一般数据库都只允许把记录的长度设定为固定长度。另外，在存储和维护空间数据拓扑关系 方面，DBMS也存在着严重的缺陷。因而，一般要对通用的DBMS增加附加的软件功能。 5.2.2 矢量数据的管理 对于矢量数据，其位置数据和属性数据通常是分开组织的。这一特点使得在管理时需要 同时顾及空间位置数据和属性数据，其中属性数据很适合用关系数据库来管理，空间位置数 据则不太适合用关系数据库管理。空间数据管理方式与数据库发展是密不可分的，按照发展 的过程，对矢量数据的管理有文件/关系数据库混合管理、全关系管理、对象关系数据库管 理等方式。 1. 文件-关系数据库混合管理 由于空间数据的非结构化持征，早期关系型数据库难以满足空间数据管理的要求。因此， 传统GIS软件采用文件与关系数据库混合方式管理空间数据，比较典型的是ArcInfo，有的 系统也采用纯文件方式管理空间数据，如MapInfo；即用文件系统管理几何图形数据，用商用关系型数据库管理属性数据，两者之间通过目标标识或内部连接码进行连接，如图5.3所 示。 在这一管理模式中，除通过OID(object，ID)连接之外，图形数据和属性数据几乎是完 全独立组织、管理与检索的。其中图形系统采用高级语言(如C语言，Delphi等)编程管理，可以直接操纵数据文件，因而图形用户界面与图形文件处理是一体的，两者中间没有逻辑裂 缝。但由于早期的数据库系统不提供高级语言的接口，只能采用数据库操纵语言，因此图形 用户界面和属性用户界面是分开的。在GIS工作过程中，通常需要同时启动图形文件系统 图形用户界面 属性用户界面 和关系数据库系统，甚至两个系统来回切换，使用起来很不方便。如图5.4所示。 OID（目标ID 图形数据 或内部连接码） 属性数据 DBMS 图形处理 图5.3 文件-关系型数据连接 图形文件库 属性数据库 图5.4 图形数据和属性数据的连接方式 近年来，随着数据库技术的发展，越来越多的数据库系统 提供了高级语言的接口，使得GIS可以在图形环境下直接操纵 属性数据，并通过高级语言的对话框和列表框显示属性数据；或通过对话框输入SQL语句，并将该语句通过高级语言与数据库的接口来查询属性数据，然后在GIS的用户界面下显示在询结果。这种工作模式，图形与属性完全在一个界面下进行咨询与维护，而不需要启动一 个完整的数据库管理系统，用户甚至不知道何时调用了数据库系统。 在ODBC(Open Database Consortium，开放性数据 GIS用户界面 库连接协议)推出之前，各数据库厂商分别提供一套自己 的与高级语言的接口程序。因此，GIS软件开发商就不 得不针对每个数据库系统开发一套自己的接口程序，导 C等高级语言 C语言或ODBC 致在数据共享(或数据复用)上受到限制。ODBC推出之 后，GIS软件开发商只要开发GIS与ODBC的接口，就 DBMS 图形处理系统 可以将属性数据与任何一个支持ODBC协议的关系型 数据库管理系统连接。无论是通过高级语言还是ODBC 与关系型数据库连接，GIS用户都是在同一个界面下处 属性数据库 图形文件库 理图形和属性数据，如图5.5所示，称为混合方式。该 方式要比图5.4的方式方便得多。 图5.5 图形和属性结合的混合处 这种管理方式的不足之处在于：?属性数据和图形 理模式 数据通过ID联系起来，使查询运算，模型操作运算速 度慢；? 数据分布和共享困难；?属性数据和图形数据分开存储，数据的安全性、一致性、 完整性、并发控制以及数据损坏后的恢复方面缺少基本的功能；?缺乏表示空间对象及其关 系的能力。因此，目前空间数据管理正在逐步走出文件管理模式。 2. 全关系型数据库管理 属性数据 空间数据 GIS界面 （定长记录）（变长记录） 关系表 二进制 块 DBMS 空间数据库 图5.6 全关系管理空间数据 全关系数据库管理方式下，图形数据与属性数据都采用现有的关系型数据库存储，使用 关系数据库标准连接机制来进行空间数据与属性数据的连接。对于变长结构的空间几何数 据，一般采用两种方法处理，如图5.6。 ? 按照关系数据库组织数据的基本准则，对变长的几何数据进行关系范式分解，分解 成定长记录的数据表进行存储。然而，根据关系模型的分解与连接原则，在处理一个空间对 象时，如面对象时，需要进行大量的连接操作，非常费时，并影响效率。 ? 将图形数据的变长部分处理成Binary二进制Block块字段。当前大多数商用数据库都提供二进制块的字段域，以管理多媒体数据或可变长文本字符等。如Oracle公司引入Long Raw数据类型；Informix版本引入的BLOB（二进制数据块）数据类型；SQL Server引入 IMAGE数据类型。在SQL-99（SQL-3）中，BLOB被定义为新的数据类型，目前通用的数据库访问接口（ADO、ODBC）都支持BLOB类型数据的访问，通过这些接口可以对其进 行读取、增加、删除和修改操作，对BLOB的数据的所有操作和运算都需要相应的应用程 序来支持。GIS利用这种功能，通常把图形的坐标数据，当作—个二进制块整理交给关系数据库管理系统进行存储和管理。其缺陷是，这种存储方式，虽然省去了前面所述的大量关系 连接操作，但是二进制块的读写效率要比定长的属性字段慢得多，特别是涉及对象的嵌套， 速度更慢。 3. 对象-关系数据库管理 由于直接采用通用的关系数据库管理系统的效率不高，而非结构化的空间数据又十分重 要，所以许多数据库管理系统的软件商在关系数据库管理系统中进行扩展，使之能直接存储 和管理非结构化的空间数据（ 图5.7），如Informix和Oracle等都推出了空间数据管理的专用模块，定义了操纵点、线、面、圆、长方形等空间对象的API函数。这些函数，将各种中间对象的数据结构进行了预先的定义，用户使用时必须满足它的数据结构要求，用户不能根 据GIS要求（即使是GIS软件商）再定义。例如，这种函数涉及的空间对象一般不带拓扑 关系，多边形的数据是直接跟随边界的空间坐标，那么GIS用户就不能将设计的拓扑数据 结构采用这种对象-关系模型进行存储。 这种扩展的空间对象管理模块主要解决了空间数据GIS应用 的变长记录的管理，由数据库软件商进行扩展，效率要 比前面所述的二进制块的管理高得多。但是它仍然没有 解决对象的嵌套问题，空间数据结构也不能内用户任意商用DBMS 定义，使用上仍受到一定限制。 空间数据管理 矢量图形数据与属性数据的管理问题已基本得到解 专用模块 决。然而，从概念上说，空间数据还应包括数字高程模 型、影像数据及其他专题数据。虽然利用关系数据库管 理系统中的大对象字段可以分块存贮影像和DEM数据， 但是对于多尺度DEM数据，影像数据的空间索引、无缝 空间和属性数据库 拼接与漫游、多数据源集成等技术还没有一个完整的解 决 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 。 图5.7 对象－关系管理空间数据 5.3.3 栅格数据的管理 随着GIS应用的深入，影像数据和数字高程模型（Digital Elevation Model，DEM）数据在整个GIS领域的应用越来越广泛。影像数据具有信息丰富、覆盖面广和经济、方便、 快速获取等优点。DEM数据表现了整个覆盖区域的地形起伏，可以广泛用于地理分析。目 前，多数商业化的GIS软件都可以将影像数据、DEM数据作为背景影像与矢量数据进行叠 加显示输出。在实施栅格数据管理中，影像数据与DEM数据的组织与管理差别不大，这里 以影像数据管理为例说明如何管理栅格数据。 栅格影像不仅包含了属性信息，还包含了隐藏的空间位置信息（即格网的行、列信息）， 即隐含着属性数据与空间位置数据之间的关联关系。其管理分为基于文件的影像数据库管 理、文件结合数据库影像管理和基于关系数据库管理三种方式。 1. 文件管理方式 目前大部分GIS软件和遥感图像处理软件都是采用文件方式来管理遥感影像数据。由于 遥感影像数据库并不是仅仅包含图像数据本身，而且还包含大量的图像元数据信息（如图像 类型、摄影日期、摄影比例尺等），遥感图像数据本身还具有多数据源、多时相等特点，另 外，数据的安全性、并发控制和数据共享等都将使文件管理无法应付（图5.8）。 影像数据001影像数据002影像数据003 . . .影像数据004影像数据005 图5.8 影像数据的文件管理 2. 文件-数据库管理方式 为了改进文件方式管理影像数据的效率，一种新的管理方式被提出来：文件+数据库管理方式。实施这种方式管理影像数据时，影像数据仍按照文件方式组织管理；在关系数据库 中，每个文件都有唯一的标识号（ID）对应影像信息，如文件名称、存储路径等（图5.9）。 这种方式管理影像数据，不是真正的数据库管理方式，影像数据并没有放入数据库中， 数据库管理的只是其索引。由于影像数据索引的存在，使影像数据的检索效率得到提高。 表5.1 影像信息数据库表 … 影像名称 块号 Image 001 011001 … Image 002 011002 … 影像数据001影像数据002影像数据003 Image 003 011003 … Image 004 021001 … . . .影像数据004影像数据005 Image 005 021002 … … … … … … … … … … … 图5.9 影像数据的文件+数据库管理 3. 关系数据库管理 由于关系数据库发展成熟，具有良好的安全措施和数据恢复机制；目前关系数据库系统 提供了存储复杂数据类型的能力，使利用关系数据库来管理影像数据成为可能。基于扩展关 系数据库的影像数据库管理是将影像数据存储在二进制变长字段中，然后应用程序通过数据 访问接口来访问数据库中的影像数据。同时影像数据的元数据信息业存放在关系数据库的表 中，二者可以进行无缝管理。数据库方式管理影像数据具有以下特点： ? 所有数据集中存储，数据安全，易于共享。 ? 较方便管理多数据源和多时态的数据。 ? 支持事务处理和并发控制，有利于多用户的访问与共享。 ? 影像数据和元数据集成到一起，能方便的进行交互式查询。 ? 对Client/Server的分布式应用支持较好，网络性能和数据传输速度都有很大提高。 ? 影像数据访问只能通过数据库驱动接口访问，有利于数据的一致性和完整性控制， 数据不会被随意移动、修改和删除。 ? 支持异构的网络模式，即应用程序和后台数据库服务器可以在不同操作系统平台 下运行。现有商用数据库都有良好多的网络通讯机制，本身能够实现异构网络的分布 式计算，使得应用程序的开发相对简单化。 5.3.4 空间数据库引擎 采用关系数据库与文件混合管理模式的传统GIS数据库系统技术，在应用上取得了一定的成功，但不得不部分地采取文件方式管理，总体上无法达到数据库技术冗余度、独立性 等要求，用现代数据库技术统一存放和管理空间数据与属性数据是GIS发展的必然趋势。1996年，ESRI公司与Oracle等数据库开发商合作，开发出一种能将空间图形数据也存放到 大型关系数据库中管理的产品，将其定名为“spatial database engine”，简称SDE，即为“空间 数据库引擎”。之后许多的GIS厂商和数据库厂商纷纷提出自己的商业化的产品和解决方案， 比较成熟的有GIS厂商ESRI公司的ArcSDE，MapInfo公司的SpatialWare，数据库厂商Oracle 客户应用 ArcSDE客户端ArcSDE客户端 （间接）（直接） TCP/IP ArcSDE应用服务器 SQL 命令 SQL 命令 SQL引擎 存储管理 数据文件 RDBMS 服务器 图5.10 ArcSDE原理示意图 公司的Spatial，Informix公司的Spatial Data B1ade等产品和技术。 就其实质而言，空间数据引擎主要是为解决存储在关系数据库中的空间数据与应用程序 之间的数据接口问题。目前空间数据库引擎主要有两种主要方式，一种以ESRI与数据库开发商联合开发的空间引擎SDE为代表，可称之为“中间件”方式的空间数据库引擎。另一种 空间数据引擎由数据库厂商开发。这些厂商凭借其在数据库核心技术上的优势，在关系数据 库管理系统本身作出扩展，使之支持空间数据管理。如Oracle公司的Spatial即是支持空间数据管理的专用模块，这种方式可成为“嵌入式”空间数据库引擎。其中，Oracle Spatial 实际上只是在原来的数据库模型上进行了空间数据模型的扩展，实现的是“点、线、面”等简单要素的存储和检索，所以它并不能存储数据之间复杂的拓扑关系，也不能建立一个空间几何网 络。ArcSDE则解决了这些问题，并利用空间索引机制来提高查询速度，利用长事务和版本 机制来实现多用户同时操纵同一类型数据，利用特殊的表结构来实现空间数据和属性数据的 无缝集成等，ArcSDE原理示意如图5.10所示。 5.3 空间数据组织 无论采用上述何种模式管理空间数据，空间数据的组织方式均非常重要。不同的管理模 式所对应的空间数据组织方式可能不一样，不同的GIS系统之间，其空间数据组织方式也 不相同。下面以文件-关系型管理模式为例，讨论空间数据的组织问题。 5.3.1 图幅数据组织 GIS中将某一问题域或某一项GIS任务称为一个GIS工程。由于GIS工程涉及范围广（如全市、全省、全国甚至全球），在管理空间数据时必须进行分幅管理（同传统地图分幅）。 图幅一般对应一块区域，常见的分幅方式有标准分幅和区域分幅。例如研究县域的土地利用 现状图就会有乡镇分幅和1：1万分幅两种形式。上世纪90年代以来，在新的应用需求和技 术条件下，人们需要“无缝、无边界”的地图。在这种方式下，分幅管理表现为无缝大图上的 分幅和分区索引，以满足用户对具体的局部区域和专题层的操作和检索需要。 根据需要往往将一幅或相邻几幅图当作一个工作单元，称之为工作区（workspace）。其组成关系如图5.11所示。工作层被定义为空间数据处理的一个工作单元，工作区由若干工 作层组成。如图5.12所示，道路、水系、居民地等可看作工作层，在此基础上构建了工作 区。工作区中，除了包含相应图幅的各层空间数据之外，还包含对数据库的连接与操作。用 户可以随时将当前工作环境以某一工作区版本的方式存储下来，下次打开该工作区时，GIS系统根据该工作区的组成，调出属于它的工作层，就可以直接恢复进入原有工作状态。 GIS工程 ……. 工作区1 工作区2 工作区m ……. 图幅1 图幅2 图幅n ……. 工作层1 工作层2 工作层p ……. 地物类1 地物类2 地物类q ……. 地物1 地物2 地物r 图5.11 GIS数据的组织管理 结构 工作层在范围上可能与工作区一致，但在垂直方向上则因软件系统不同而名称和定义不 同。ARC/INFO的工作层称为coverage，一个coverage就是一个工作目录，该目录下包含控 制点信息文件，标示点文件、弧段文件、多边形文件等；MGE的工作层就是一个DGN文件，也称为cotalog；在GeoStar中，一个工作层就是一个GDA文件。一个工作层可以是一个逻辑层，也可以是某一个覆盖层。工作层由一种或多种地物类组成，可以根据需要自行定 义。例如一个工作层可以是某一层地物，如交通线；甚至是某一类地物，如地铁；还可以是 多层地物，甚至可以包含一个工作区的所有各层地物。MGE和GeoStar等软件的工作层对所包含的地物层的内容不象coverage限定严格（一个coverage中不允许同时有点状地物和面状地物），定义工作层纯粹为了提高工作效率和方便需要。许多情况下，一个工作层就是 一个工作区，此时逻辑层的概念比较重要。 在工作层的基础上，如果研究对象过于庞杂（例如所有地物类），或者需要分类研究， 或者为了显示、制图和查询方便，仍需要对其进行分层，此时进行可以进行逻辑层（logic layer）的划分。如研究全国道路交通网，可以需要分别研究铁路、公路（高速公路、等级公 路、等外公路）等，此时，可以在道路层的基础上划分逻辑层，如图5.12。 工作区 工 作……水系居民地道路地表高程层 铁路公路 逻 辑 层 高速公路等级公路等外公路 图5.12 工作区、工作层、逻辑层示意图 在GeoStar中，逻辑层可以任意定义，根据用户需要，一个逻辑层可以包含任意多个地 物类，而且允许交叉，例如河流可以添加到水系逻辑层中，也可以包含在交通逻辑层中，但 河流的物理存储位置和关系没有变化，仅仅是与相应逻辑层建立了一个对照关系，即每个逻 辑层包含了哪些指向地物类的指针而已。 地物类是类型相同的地物总称。同类地物一般用相同的显示颜色和绘图符号表示，而 且严格按照点状地物类、线状地物类和面状地物类进行划分。有些软件将点状地物、线状地 物、面状地物分不同的数据文件进行管理，如ARC/INFO；而MGE、GeoStar则将工作区中 的所有地物（无论点、线、面）用一个文件进行统一管理。 5.3.2 空间数据的图库管理 具备工作层、工作区的这样的地理空间数据管理层次和数据处理单元，GIS数据管理的工作仍然没有完结。在大型数据库管理中，需要建立“图库管理”职能。当GIS所管理的区域和所要求的比例尺都比较大时，如在城市规划管理信息系统中，数据库会包含大量的图幅， 涉及多个工作区及很多工作层的数据组织和管理，这时一个GIS系统会包含几百、几千， 甚至上万个工作区。这时，GIS软件必须让用户能在整个区域内进行众多图幅（分区）、工 作层的调用，图幅拼接和跨图幅的剪切、开窗，跨图幅工作层的漫游、查询、分析和制图等。 这就涉及到图库的管理。在无缝大地图的方式下，图库管理职能通过有效的分幅（分区）、 分层的空间索引，以满足用户对具体的局部区域和专题层的操作、检索的需要。 图库管理是海量空间数据管理的需要，是大型GIS软件的必备功能，其管理效率是衡 量GIS软件优劣的重要指标之一。为了提高海量空间数据的管理效率，GIS必须建立强有力的空间索引和查询机制。具体内容及实现方式请参阅后续章节“空间索引”的内容。 5.3.3 属性数据组织 属性数据由关系数据库管理系统管理，但它的文件组织方式也要服从上述工作层、工作 区和图库的要求，以便于图形文件协调工作，共同组成工作区、工作层，并进行跨图幅操作。 在不同的商业化软件中，属性文件组织方式各不相同。主要的三种方式如下： ? 与工作层对应的组织方式： 一个工作区对应一个属性文件，属性文件建立在工作区 目录下。Arc/Info采用这种方式，属性数据文件一般建立在对应的coverage目录之下。无论一个工作区包含多少地物类，其目录下仅有一个AAT表（记录弧段属性数据）和一个PAT表（记录多边形属性数据）。为了表达不同地物类的不同属性项，可以按照每个地物类建立 一个扩展的属性表，让它们通过地物编码和内部连接码与AAT表和PAT表相连。因此在查询某一空间地物的属性时，先从AAT表和PAT表中得到部分信息，再从关系连接查询到扩 展属性信息。 ? 与地物类对应的组织方式：一个地物类文件对应一个属性表，在这种方式中，可以 把这些属性文件放在工程（项目）目录下集中管理，以方便属性查询。MGE的属性数据文件是建立在地物类的基础上，而且将所有的属性文件均放在对应的工程目录之下。也就是说， 不同工作区的相同地物类的属性是放在一起的，这样属于属性的工程管理，而且大大提高了 在工程范围内查找某一属性的速度。需要注意的是，MGE并不要求每个地物类都带有属性表，一些无关紧要的地物可以不要属性表，这位GIS的空间数据组织提供了一定的灵活性。 ? 混合方式：由于上述两种方式都存在一定缺陷，例如一个工作区对应一个属性文件 时，如果工作区涉及多个工作层，工作层下再细分出逻辑层，采用这种管理方式会给属性信 息检索和更新带来极大不便；采用单个地物类对应单属性数据时又过于死板，更具弹性的方 式是既可以设计一个地物类有一个属性表，又可以多个地物类共用一个属性。GeoStar的属 性数据文件组织与管理方式吸收了前两者的优点，在GeoStar中，既可以对每一个地物类设计属性表，也可以对属性项相同或相近的多个地物类设计一个公用的属性表。以交通地理信 息系统为例，高速公路、一级公路、二级公路、乡镇公路等，它们的地物类型编码可能不同， 但它们的属性项可能相同，因而它们可以共有一个属性表，以便于查询、显示和最佳路径分 析；GeoStar的属性数据文件的组织则于MGE基本类似，在建立工程之前，属性数据文件 位于与工作区平行的目录之下；在工程建立之后，则直接位于工程目录之下。一个属性文件 包括了该工程内所有同类空间对象的属性，当属性文件趋于庞大时，则有必要建立关键字索 引机制。 5.4 空间索引 经对研究区空间数据输入并建立空间数据库以后，得到了一个庞大的数据库，如何从该 数据库中快速检索、提取所需的空间数据来满足空间分析、模拟与决策的需要是一个重要的 问题。空间索引就是指依据空间对象的位置和形状或空间对象之间的某种空间关系按一定的 顺序排列的一种数据结构，其中包含空间对象的概要信息，如对象的标识、外接矩形及指向 空间对象实体的指针。作为一种辅助性的空间数据结构，空间索引介于空间操作算法和空间 对象之间，它通过筛选作用，大量与特定空间操作无关的空间对象被排除，从而提高空间操 作的速度和效率。空间索引的性能的优劣直接影响空间数据库和地理信息系统的整体性能， 它是空间数据库和地理信息系统的一项关键技术。常见的空间索引一般是自顶向下、逐级划 分空间的各种数据结构空间索引，比较有代表性的包括BSP树、K-D-B树、R树、R+树和 CELL树等。此外，结构较为简单的格网空间索引有着广泛的应用。 5.4.1 对象范围索引 在记录每个空间实体的坐标时， 记录包围每个空间实体的外接矩形 D 的最大最小坐标。这样，在检索空间查询窗口 实体时，根据空间实体的最大最小范 B 围，预先排除那些没有落入检索窗口 内的空间实体，仅对那些外接矩形落C 在检索窗口的空间实体作进一步的 判断，最后检索出那些真正落入窗口 内的空间实体，如图5.13所示的查 询窗口中，对所有空间实体的外接矩 形最大最小坐标进行落入判别，其中E A F 空间实体B、C完全落入查询窗，从 图5.13 基于实体范围的空间数据检索 空间数据库中提取B和C的相应数据。 这种方法没有真正创建真正的空间索引文件，而是在空间对象的数据文件中增加了最大 最小范围，主要依靠空间计算进行判别。此方法仍需要对整个数据文件的空间对象进行检索， 只是某些对象可以通过判别予以直接判别，而有些对象仍需要进行复杂计算才能判别。虽然 该方法仍需要花费大量时间来进行空间检索，但随着计算机的处理速度的加快，这种方法在 一定程度上能够满足查询检索的效率要求。 空间索引表 实体索引表 Peano码 实体 实体 Peano码 7 B A 25-25 21 23 29 31 53 55 61 63 14 F B 7-7 15 F C 54-55 20 22 28 30 52 54 60 62 25 A C 60-60 26 F D 32-33 17 19 25 27 49 51 57 59 C 32 D D 35-35 16 18 24 26 48 50 56 58 33 D D 38-38 A 5 7 13 15 37 39 45 47 35 D,G F 14-15 37 F F 26-26 4 6 12 14 36 38 44 46 38 D F 37-37 39 F F 39-39 F 1 3 9 11 33 35 41 43 B 48 F F 48-48 0 2 8 10 32 34 40 42 50 F F 50-50 54 C G 35-35 G 55 C D 60 C 图5.14 基于Peano码的格网法空间索引 5.4.2 格网索引 格网型空间索引思路比较简单，容易理解和实现。其基本思想是将研究区域用横竖线条 划分大小相等和不等的格网，记录每一个格网所包含的空间实体。当用户进行空间查询时， 首先计算出用户查询对象所在格网，然后再在该网格中快速查询所选空间实体，这样一来就 大大地加速了空间索引的查询速度。 将覆盖整个研究区的范围按照一定的规则划分成大小相等的格网，然后记录每个格网内 所包含的空间实体，为了便于建立空间索引的线性表，将每个格网按Morton码或称Peano码进行编码，建立Peano码与空间实体的关系，该关系表就成为格网索引文件。如图5.14所示。 从上例中可以看到，没有包含空间实体的格网，在索引表中没有出现该编码，即没有 该条记录。如果一个格网中含有多个地物，则需要记录多个实体的标识，如图5.14中的35号格网，含有线状目标和点状目标两个地物，故记录了两个实体的标识。如果需要表格化， 则需要使用串行指针将多个空间目标联系到一个格网内。 按格网法对空间数据进行索引时，所划分的格网数不能太多，否则，索引表本身太大而 不利于数据的索引和检索。 5.4.3 四叉树空间索引 四叉树作为一种有效的数据结构，不仅可以用来对栅格数据进行组织，它还可用于建 立空间数据的索引。四叉树中的线性四叉树和层次四叉树都可以用于建立空间索引。 在建立四叉树索引时，根据所有空间对象覆盖的范围，进行四叉树分割，使每个子块 中包含单个实体，然后根据包含每个实体的子块层数或子块大小，建立相应的索引。在四叉 树索引中，大区域空间实体更靠近树的根部，小实体位于叶端，以不同的分辨率来描述不同 实体的可检索性。 线性四叉树采用十进制Morton码或Peano码来表示四叉树的大小和层数（图5.18）。 在图5.15中，空间实体E的外接矩形范围很大，涉及到由节点0开始的4×4个节点，所以在索引表的第一行，Peano码为0（表示涉及整个区域），边长为4，实体标识符为E；空间实体D虽然仅涉及Peano码为0和2两个格网，但对四叉树来说，它所涉及的0、1、2、3四个节点不可再分割，因此它需要2×2的节点来表达。同理，实体C也需要用2×2的节点表达。而点状实体A、F、G本身没有大小，直接使用最低一级节点来表示。由此就可建立 Peano码与空间实体的索引关系。在进行空间数据检索和提取时，根据Peano码和边长值就可以检索出某一范围内的对象。 使用层次四叉树建立空间数据的索引与线性四叉树基本相同，但是它需要记录不同层次 节点间的指针，建立索引和 维护都较困难。 peano码 边长 实体 B G 0 4 E 5.4.4 R树和R+树空间索E 5 7 13 15 0 2 D 引 1 1 A F 4 6 12 14 4 1 F 与实体范围索引类似，R 树和R+树利用空间实体的8 2 C 外接矩形来建立空间索引。15 1 B、G A 1 3 就R树而言，认为有N个实 体被N个外接矩形 8 C （Rectangles，R）所包围， 0 D 2 现欲寻找某一特定的矩形， 或是检索一个矩形中某一特 图5.15 用线性四叉树组织的空间索引 定的点，若对数据不进行适 当组织的话，那么测试的次 数与外接矩形的个数成正比。假如有成千上万个矩形，则检索特定的空间数据所需的时间太 多，检索效率低下。 R树空间索引不仅利用单个实体的外接矩形，还将空间位置相近的实体的外接矩形重新 组织为一个更大的虚拟矩形。在构造虚拟矩形时，虚拟矩形方向与坐标方位轴一致，同时满 足以下条件：包含尽可能多的空间实体；矩形间的重叠率尽可能少；允许在每个矩形内再划 分小矩形。对这些虚拟的矩形建立空间索引，它含有指向所包围的空间实体的指针。 R树空间索引就是按包含实体的矩形来确定的，树的层次表达了分辨率信息，每个实体 与R树的结点相联系，这点与四叉树相同。矩形的数据结构为： RECT（Rectangle-ID，Type，Min-X，Min-Y，Max-X，Max-Y） 其中Rectangle-ID为矩形的标识符；Type用于表示矩形的类别是实体的外接矩形还是 虚拟矩形；Min-X、Min-Y为该矩形的左下角坐标；Max-X，Max-Y为该矩形的右上角坐标。 在虚拟矩形与实体的外接矩形重合时，两者的标识符相同。由于虚拟矩形允许再划分， 还必须建立不同层次矩形的相互关系： PS（上层虚拟矩形标识符，下层虚拟矩形标识符） A B K F G D I E H J M N L C （a）二层不重叠矩形 A B C L D H M N E F J G I5.18 K R树 （b）层状结构 结构 示意 图 在进行空间数据检索时，首先判断哪些虚拟矩形落入查询窗口内，再进一步判别哪些I 实体是被检索的内容，这样可以提高数据检索的速度。图5.16 给出了R树空间数据索引的 实例。在该例中，仅有2层，内层矩形为实体的外接矩形，外层矩形为建立的虚拟矩形。如 虚拟矩形B中包含了实体外接矩形H、I、J、K。 图5.16 R树结构示意图 在构造R树时，要求虚拟矩形之间尽量不要相互重叠，而且一个空间实体通常仅被一 个同级虚拟矩形所包围。但由于空间对象的复杂性，实体的外接矩形通常是相互重叠的，使 包含它们的虚拟矩形难免会重叠。R+树是对R树索引的一种改进，它允许虚拟矩形可以相互重叠，并分割下层虚拟矩形，允许一个空间实体被多个虚拟矩形所包围。在构造虚拟矩形 时，尽量保持每个虚拟矩形包含相同个数的下层虚拟矩形或实体外接矩形，以保证任一实体 具有相同的检索时间（图5.17）。 R+树的数据结构与R树的相同，但是，对于被分割的下层虚拟矩形或实体外接矩形， 还要增加关系表达： DECOMP（原矩形标识符，分割后矩形1的标识符，分割后矩形2的标识符）。 CG AFFG D1 D2 ABD1CED2 B E 图 5.17 R+树结构示意图 5.5 空间数据库查询语言 查询语言是与数据库交互的主要手段，是数据库管理系统的一个核心要素。SQL是用 于关系数据库管理系统的常见结构化查询语言，具有易用、直观、通用的特点。由于关系模 型适合与处理简单数据类型，如字符串、日期类型等；而空间数据比较复杂，由点、线、多 边形等混合而成，于是希望能将SQL扩展，用来支持空间数据。 5.5.1 标准查询语言 SQL（Structured Query Language）是1974年由Boyce和Chamberlin提出的。1975年~1979年IBM公司在其关系数据库管理系统原型system R并实现了这种语言。由于它功能 丰富、语言简捷而被众多计算机公司和软件公司所采用，经不断修改、扩充和完善，从最初 的SQL-86，经历SQL-89、SQL-92（SQL-2）发展到SQL-99（SQL-3，支持空间数据），SQL发展成为关系数据库的标准语言。其中SQL-86为SQL的最初版本，亦称为SQL-1；SQL-92是SQL成为关系数据库标准语言的版本，也称为SQL-2；而在设计SQL-99时则主要考虑对通用SQL进行扩展，以支持空间数据，是SQL的第三个版本，也称为SQL-3。 SQL是一种介于关系代数与关系演算之间的结构化查询语言，它不仅仅是查询，是一 个通用的、功能极强的关系数据库语言。SQL语言是一个综合的、功能极强同时又简捷易 学的语言。SQL语言集数据查询（Data Query）、数据操纵（Data Manipulation）、数据定义（Data Definition）和数据控制（Data Control）功能于一体，主要特点包括：综合统一，SQL集数据定义、操纵、控制功能于一体，能很好的满足数据操作要求；高度非结构化，SQL进行数据操作时，只需提出“做什么”，操作由系统自动完成；面向集合的操作方式；语言简 捷，易学易用等特点。 SQL语言功能极强，但由于设计巧妙，语言十分简单，完成核心功能只用9个动词，如表5.2所示。SQL语言接近英语口语，因此容易学习，容易使用。 表5. 2 SQL语言的动词 SQL功能 动词 数据查询 Select 数据定义 Create, Drop, Alter 数据操纵 Insert, Update, Delete 数据控制 Grant, Revoke 5.5.2 扩展SQL处理空间数据 SQL不足之处是只提供简单的数据类型：整型、日期型、字符串型等。空间数据库（SDB）的应用必须能处理多点、线和多边形这样的复杂的数据类型。亟需对SQL语言进行空间扩展。SQL的空间扩展，需要一项普遍认可的标准。OGIS协会（Open GIS）是由一些主要软件供应商组成的联盟，负责制定与GIS互操作相关的行标准。OGIS的空间数据模型可以嵌 入到各种编程语言中，例如C、Java、SQL等等，提出了一套 规范 编程规范下载gsp规范下载钢格栅规范下载警徽规范下载建设厅规范下载 ，把二维地理空间ADT（abstract data type, 抽象数据类型）整合到SQL之中，并且包括了指定拓扑的操作和空间 分析操作。在OGIS标准中，所指定的操作可分成三类，如表5.3所示： ? 用于所有几何类型的基本操作。例如，SpatialReference返回所定义对象几何体采用 的基础坐标系统。常见的参照系统的例子包括：人们熟悉的经纬度（1atitude and longitude）系统和用得最多的通用横轴墨卡托（Universal Traversal Mercator，UTM）。 ? 用于空间对象间拓扑关系的操作测试。例如，overlay判断两个对象内部是否有一个 非空的交集。 ? 用于空间分析的一般操作。例如，distance返回两个空间对象之间的最短距离。 表5.3 OGIS标准定义的一些操作 SpatialReference（） 返回几何体的基本坐标系统 Envelope（） 返回包含几何体的最小外接矩形 Export（） 返回以其他形式表示的几何体 基本函数 IsEmpty（） 如果几何体是空集则返回真 IsSimple（） 如果几何体是简单的（即不自交）则返回真 Boundary（） 返回几何体的边界 Equal 如果两个几何体的内部和边界在空间上相等，则返回真 Disjoint 如果内部和边界不相交，则返回真 Intersect 如果几何体不相交，则返回真 Touch 如果两个面仅仅是边界相交但是内部不相交，则返回真 拓扑/集合运算 Cross 符 如果一条线和面的内部相交，则返回真 Within 如果给定的几何题的内部不和另一个几何体的外部相交，则返回真 Contains 判断给定的几何体是否包含另一个给定的几何体 Overlap 如果两个几何体的内部有非空交集，则返回真 Distance 返回两个几何体之间的最短距离 Buffer 返回到给定几何体的距离小于或等于指定值得几何体的点集合 ConvexHull 返回几何体的最小闭包 Intersection 返回由两个几何体的交集构成的几何体 空间分析 Union 返回由两个几何体的并集构成的几何体 Difference 返回几何体与给定几何体不相交的部分 SysmmDiff 返回两个几何体与对方互不相交的部分 OGIS规范SQL-99（SQL-3）在一定程度上解决了将通用SQL扩展到空间的目标，但仍存在以下问题。 ? OGIS规范仅仅局限用于空间的对象模型，考虑到空间信息可以映射到场模型，OGIS正在开发针对场数据类型和操作的统一模型。 ? 即使在对象模型中，对于简单的选择-投影-连接查询来说，OGIS的操作也存在局限性。 ? OGIS标准过于关注基本拓扑的和空间度量的关系，而忽略了对度量操作的类的支持， 不支持那些基于方位（例如，北、南、左、前等）谓词的操作。 ? OGIS标准不支持动态的、基于形状以及基于可见性的操作。 专业术语 空间数据库 空间数据库引擎（SDE） 空间索引 对象范围索引 格网索引 R树和R+树索引 复习思考题 一、思考题（基础部分） 1、什么是空间数据库，具有什么特点？ 2、矢量数据的管理方式有哪些，各有什么优缺点？ 3、栅格数据的管理方式有哪些，各有什么优缺点？ 4、数据库中空间数据是如何进行分幅分层组织的？ 5、空间数据的索引方式有哪些，比较各种方法的优缺点。 二、思考题（拓展部分） 1、通过阅读资料，比较ArcSDE、Oracle Spatial等空间数据引擎的特点。 2、以江苏省为例，讨论建立江苏省省级GIS的数据管理思路和方法。 3、分析常用GIS软件的空间和属性数据管理的特点。 4、试比较ArcGIS、MGE和GeoStar的属性数据管理策略之特点。