地理信息系统技术基础.doc

GIS技术第一部分：组件技术1． 概述组件的起源组件的发展组件技术现状2． 组件技术原理组件基础知识 基本概念 对象与接口 组件应用模型 组件复用技术 组件技术的应用基于组件的应用技术多层软件结构高级组件技术（com+ dcom mts）3． 组件开发4． 组件的使用5． 组件技术与GIS6．MapObject第二部分：网络技术1． 计算机网络技术2． 分布式GIS3． WEB GISWEB GIS基本概念WEB GIS主要特点主要web GIS系统平台介绍WEB GIS 原理及相关技术第三部分：空间数据库技术1． 空间数据库简介2． 空间概念和数据模型3． 空间查询与空间索引4． 基于WEB的空间数据库系统5． 空间数据挖掘简介6． 空间数据库发展趋势第四部分：地形三维可视技术1． 概述2． 地形三维显示的基本过程 地形三维显示中的数据准备地形表面拟合投影变换消隐与裁剪纹理映射光照模型3． OpenGL目 录目 录 3第一篇：组件对象模型（COM） 7第一章：COM概述 81.1 COM的起源 81.1.1 COM的发展简史 81.1.2组件的产生 91.2 使用组件的优点 101.3 COM特性 101.3 .1面向对象的组件模型—COM 111.3.2 客户/服务器模型 111.3.3 语言无关性 121.3.4 进程透明特性 131.3.5 可重用性 131.4 与COM相关的技术 141.4.1 ActiveX 141.4.2 DCOM 141.4.3 COM+ 141.5 COM应用 151.5.1 COM在Windows操作系统中的应用 151.5.2 COM在数据库领域的应用 151.5.3 COM在企业中应用 151.5.4 COM在Internet中的应用 16第二章 组件技术原理 172.1 对象与接口 172.1.1 COM对象 172.1.2COM接口 182.1.3全局唯一标识符——GUID 192.1.4 接口定义语言IDL 192.2组件应用模型 212.2.1客户/服务器模型 212.2.2 COM库 222.2.3通过注册表管理COM对象 232.2.4 COM客户对组件的调用 252.3组件复用技术 262.3.1 组件的聚合 262.3.2 组件的包容 26第三章 用VC++开发COM组件 273.1 基于MFC开发COM组件 273.1.1 MFC开发COM组件概述 273.1.2 用MFC开发COM组件例程 283.2 基于ATL开发COM组件 313.2.1 ATL开发COM组件概述 313.2.2 用ATL开发COM组件例程 32第四章 VC++中使用代码组件 364.1．相关基础知识 364.1.1组件的安装和注册 364.1.2 类型库与ODL 374.1.3 OLE/COM Object View 384.2在VC++中使用代码组件 394.2.1 利用COM库使用代码组件 394.2.2 利用Class Wizard库使用代码组件 414.2.3 利用#import使用代码组件 42第五章 组件技术与GIS 435.1 组件式GIS系统的特点 445.2 组件式GIS的结构 455.2.1 组件式GIS的体系结构 455.2.2 组件层次划分 475.2.3 组件功能划分 485.4 GIS 组件产品及比较 53第六章MapObject 53第二篇：空间数据库访问技术 54第一章 空间数据库简介 551.1空间数据库 551.1.1空间数据库与地理信息系统 551.1.2空间数据库的发展 561.2基于关系数据库的空间数据库管理系统 571.2.1 采用关系数据库的优点 571.2.2 基于关系数据库的GIS模型 58第二章 空间数据库访问 582.1采用ADO访问空间数据库 582.1.1 ADO对象模型 592.1.2 在Visual C++中使用ADO 612.1.3 在Visual C++中使用ADO(例程) 672.2采用ODBC接口实现多数据库支持 722.2.1 ODBC基本概念： 722.2.2 ODBC组成： 722.2.3 ODBC在GIS中的意义 732.2.4 设置ODBC数据源 74第三篇 Web GIS 77第一章 GIS与Internet、World Wide Web 781.1 Internet ── 巨大的信息库 781.2 WWW ── Internet 成功的关键因素 791.3 Intranet 日益兴起 791.4 Internet、WWW 对 GIS的影响 80第二章 WebGIS 概 述 802.1 WebGIS的概念 802.2 WebGIS与传统GIS的比较 812.3 WebGIS的体系结构 822.4 WebGIS的基本工作模式和分类 83第三章 WebGIS 中的WWW技术 853.1 WebGIS浏览器 853.2. 客户端与服务端通讯方式和接口设计 863.2.1 通用网关接口(CGI)/服务器应用程序接口方法(SAPI) 863.2.2 插入法(Plug-in) 883.2.3 Java Applet/ActiveX 893.2.4 综合性的技术方法 90第四章 Web GIS实现 924.1 MapXtreme简介 924.1.1 MapXtreme引擎 924.1.2 MapXtreme 构成 934.1.3 MapXtreme 服务器配置 934.1.4 MapXtreme 应用程序的工作流程 974.1.5 MpXtreme 数据 984.2 MapXtreme系统开发构架 994.2.1 开发构架基本概述 994.2.2 初始化地图服务器 1004.2.3 客户端向地图服务器提交请求 1024.2.4 地图服务器处理客户请求 1044.2.5 将处理结果输出给客户端 1054.2.6 释放地图服务资源 105第一篇：组件对象模型（COM）第一章：COM概述组件式是当前软件技术发展的潮流之一。

它的优点是具有高度的重用性和互用性，涉及到应用程序构成的各个方面，对应用程序的开发产生很大的影响目前主要是基于Mircrosoft的COM/DCOM规范业已成为业界的事实上的标准本书中我们主要介绍Mircrosoft的COM组件模型COM，即组件对象模型（Component Object Model），是关于如何建立组件以及如何通过组件架构应用程序的一个规范，是Mircrosoft创建的一种二进制和网络标准，它允许任意两个组件之间互相通信，而不管它们是在什么计算机上运行（只要计算机是相连的），不管各计算机运行的是什么操作系统（只要该操作系统支持COM），也不管该组件是用什么语言写的1.1 COM的起源软件工业的迅速发展，使得软件的规模越做越大，功能越来越强，版本的更新也越来越快这种变化对于传统的软件开发方式提出了新的挑战：对于用户而言：为了使用软件的少数几项功能，而不得不购买整个铁板一块的应用程序，不同的软件的功能大量重叠，造成资源的大量浪费对于软件开发商而言：首先，软件规模的不断增大，使得开发团队也越来越大，团队的协调工作变得极其复杂，应用难以被集成；其次，频繁的软件升级和改版使得软件开发陷入不可维护的境地，传统的软件开发方式及技术已经越来越不能适应软件发展的需要。

因此，软件行业迫切需要一种解决上述问题的新的方法和技术手段COM技术正是在这种情况下出现的1.1.1 COM的发展简史任何一种技术从产生到成熟都有一个长期的发展历程，作为组件化软件模型，COM的发展过程也不例外本节对Mircrosoft的组件技术的发展过程进行回顾随着桌面窗口系统中应用程序之间的交互不断深入，就在OLE技术的发展过程中产生了COM 从字面上来看，OLE所表达的是复合文档(compound document)的概念，而且，OLE的第一个版本即OLE 1也仅限于此需要指出的是，在OLEI中，组件程序和客户程序之间进行通信并没有使用COM规范，而是使用了一种被称为动态数据交换(DDE，dynamic Data Exchange)的机制，DDE建立在Windows操作系统的消息机制基础上，其最大的缺点是效率低，而且稳定性不好，使用也不够方便DDE的这些缺陷也限制了OLE 1的发展，于是，在第二个OLE版本即OLE 2中，Microsoft重新编写了底层代码，放弃了DDE，采用了新的COM模型，因此，OLE 2成了第一个用COM架构的软件系统由于采用了COM，OLE 2比OLE 1效率更高，稳定性和灵活性有了很大提高。

在以后OLE的发展过程中，由于采用了COM作为其底层结构，使用COM接口(interface)作为程序之间通信的标准，因此，OLE模块定制和扩充变得非常方便这里我顺便提一下软件版本的升级方式一般的应用系统在升级版本时，往往用新的软件模块全部替换老的程序模块，因此，升级就意味着全部更新，例如OLE 2对OLE 1进行升级，不仅软件模块作了替换，连基本技术也变了但是在OLE 2之后，由于采用了组件化的软件模型，因此，每一个底层模块可以单独升级，而且在原来软件模块的基础上，可以添加新的组件模块而不需要改变原有的组件模块因此，在OLE 2之后，OLE技术不再局限于“对象链接和嵌入”，不再局限于复合文档，而变成了在桌面系统上进行程序通信的一个技术统称因此，当人们正在等待“OLE3”出现的时候，OLE已经不再是最初的OLE了并且，用户计算机中的OLE系统也正悄悄地在进行更新1.1.2组件的产生在计算机软件发展的早期，一个应用程序通常是由单个的二进制文件组成的应用越复杂，程序就越庞大，系统开发的难度也就越大而且，当编译器生成此应用程序之后，在对下一版本重新编译并发行新生成的版本之前，应用程序一般不会发生任何变化。

操作系统、硬件及客户需求的改变都必须等到整个应用程序被重新编译之后才能够得以认可而对于庞大的程序来讲，更新版本的周期很长，在两个版本之间，如果由于操作系统发生了变化，或者硬件平台有了变化，则应用系统就很难适应这样的变化所以这类单体应用程序已经不能满足计算机软硬件的发展需要目前这种状况已经发生了变化人们认识到应用程序在发行之后不应该保持那种静止的状态从软件模型角度来考虑，一个很自然的想法就是把一个庞大的应用程序分成多个模块，每一个模块保持一定的功能独立性，在协同工作时，通过相互之间的接口完成实际的任务我们把每一个这样的模块称为组件（图1 .1）单个应用程序组件应用程序组件 1组件 2组件 3组件 4图1 .1 传统的应用程序与组件应用程序对比一个设计良好的应用系统往往被切分成一些组件，这些组件可以单独开发，单独编译，甚至单独调试和测试当所有的组件开发完成后，把它们组合在一起就得到了完整的应用系统当系统的外界软硬件环境发生变化或者用户的需求有所更改时，并不需要对所有的组件。