基于多媒体的GIS系统平台构造与生成方法的研究

1、基于多媒体的GIS系统辅助开发平台构造与生成方法的研究 关键词：GIS，语法分析及解释执行，多媒体技术，DBMS，DXF格式文件,CASE技术1概述 而信息的处理在计算机软件技术中今天发挥着越来越大的作用，人们已远远不能满足传统的信息管理系统依旧采用数字/文字的事物表述方式，随着计算机多媒体技术的突破性进展，及相应半导体及芯片技术的进一步发展，大容量信息的存取瓶颈从硬件上得到进一步缓解，基于多媒体的软件开发技术日益受到关注。 GIS（地理信息系统）技术作为一种新兴技术在管理信息系统中扮演着越来越重要的角色。基于GIS技术可以充分利用其较容易在二维空间里描述实体间的关系，使其在计算机辅助分析、提

2、供战略决策方面有着传统信息管理系统无法比拟的优势。程序辅助开发工具/程序自动生成工具（CASE）的研究也是近年来较为热门的课题，国内很多人在此方面做了很多的工作，市场上也常看到此类的产品，一般多采用悬挂在宿主开发系统（一般多为桌面级数据库管理系统）以外的附属系统，也有内置解释或编译程序的独立开发工具。2GIS系统开发平台的软件结构及说明2 11 最终用户2 GIS APPLICATION（GIS应用）3 二级增值开发商4 GIS描述宏脚本（GIS SCRIPT）5 GIs DEVELOP PLATFORM（GIs开发平台） （包括地图输入，地图/图形一般处理 ，数据库数据处理，自定义宏语法分析

3、，解释执行，组件程序的管理调度等，地图的自定义格式及数据描述）6 API（ODBC，WINSOCKET，DBLIB） -7 DBMS（OPENBASE/SYBASE/ORACLE）、OS（WINDOWS/WINDOWS95/WINDOWS NT/SOLORIES）、PROTOCOL（TCP/IP，IPX/SPX）很明显，本结构中第五层担负着承上启下的工作，大量的工作都落在第五层，对于第三层来说，他所见仅是本系统底层平台之上的第一层虚拟系统，而在第五层中定义了脚本描述语言（SCRIPT）及图形/地图数据的通用处理方法的支持下，由第三层来描述第二层具体应用系统，所以，对于第一层（最终系统使用者）来

4、说，他所见已是本系统底层平台之上的第二层虚拟系统；而如果按照传统专有系统的结构，我们一般可省略3，4和5的一部分。事实上，步骤5的宏语言语法定义、分析、执行，组件程序的管理调度、地图的自定义格式及数据描述比一般专有系统大大增加了设计和开发难度。 22地图及实体关系数据录入IS地理底图的录入一般有两种方法：扫描仪光栅图录入和数字化仪矢量图录入，前者的录入方便，扫描速度快，但占用空间大，处理速度慢，在地图无极放缩时明显失真，更为严重的是光栅图本身无意义，对于空间实体关系的描述能力较差。后者录入较为繁琐，但图纸描述效率高，在地图无极放缩时不失真，并且可以按一定方法定义地图的含义，可以较为清晰的描述空

5、间实体之间的关系。目前，较为流行和通用的方法为采用光栅图矢量化成矢量图纸的办法：具体为把扫描而来的光栅图经矢量化程序处理后输出为某种较为通用的矢量图文件格式，再使用此类文件格式的编辑程序进行补充编辑，在通过格式转换程序转化为自定义的文件格式，在对于此文件进行再编辑，以期在自定义的文件中对空间实体之间的关系及相应数据进行较为详尽的描述。因此我们认为地理底图的数据输入宜采用最后一种方法。相应软件的结构如下： 转换1 转换2 编辑1 转换3 编辑2地图=扫描仪-光栅图文件-通用矢量图文件-自定义矢量图文件1 2 3 4 5 其中，从图中，我们可看出转换2，3可以直接简化为转换3，但这样事实上对于光栅

6、图的处理就无法利用一些商品化工具，事实上，对于转换1，编辑2都增加了许多方面的处理。2 3矢量图的处理方法 详见3关于地图矢量文件的描述方法243关于地图矢量文件的描述方法 地理信息系统关于地理图的描述是其中极为重要的部分，它的设计直接影响整个系统的运行速度和质量。 在实际应用中，地理图往往相当多，以一个50100万人口的中等城市来讲，1:500的地图至少应有200张以上，这样大数量的地图往往要占用相当多的磁盘空间，而且严重影响整个系统的运行速度，更不用说大量的数据存取过程（包括数据库的访问）。所以过去IS系统仅仅能够在高档图形工作站上运行，而且处理能力也相对较弱。即使在现在,多媒体技术高速发

7、展的今天,在此类设计中,依旧要注意尽力使”既让马儿跑,又让马儿不吃草”。 一般来说，地理信息系统对于通用图形文件格式多采取兼容处理的办法，如MAPINFO的处理，然后再进行进一步定义和补充。 当地图由光栅图转化为通用格式矢量图时，一般存储空间会大幅度下降，（当然不排除矢量程序矢量化处理效果不好，或光栅图扫描效果不佳时使矢量图纸生成效果不理想的情况），一般仅为原地图的20%-50% 甚至更小；而由通用数据格式转化为自定义数据格式时存储空间的升降，往往取决于整个系统的软件结构及本自定义格式所采取的具体方式。一般来说，因为采用了数据压缩技术，大小基本都有所下降。一般平均下降20%-40%不等。仅仅对

8、地图占用空间的压缩还是不够的，必须对地图显示进行进一步的调度优化，我们知道，在一定的地图比例尺下，当前用户所处理的地图仅仅占所有地图的一小部分，假设一个城市地图有1000张，每行50张，每列20张，设在1：5000的比例下每次在用户区仅能处理10张，那么，我们就可以使用一个（50*20）的稀疏矩阵M5020，对于当前用户区内的一个元素MIJ来说，（其中0=I=49,0=J=19）可以确定与其相邻的元素MI,J必然在I-5=I=I+5和J-2=J=0、I-2 =0、J+5=50、I-2=20）,这样以来，我们就可以确定当前客户区内的为M中的哪些元素，设每个元素为一个链表的HEAD，同时在其中可以

9、填加相应信息，这样就可以简单的利用M进行空间的调度了，可以推论，如果我们对每张地图进一步细分直至基本图元，这样就可以对整张地图进行调度管理了。1 2 3 4 5 67 8 9 10 111213 14 15 16 17 1819 20 21 22 23 24如上图示，假设共有24张地图合并成整个地图的话，而当前仅对9、10、15、16操作的话，我们就可以认为在此稀疏矩阵M1中，仅有M12，1、 M13，1、M12，2、M13，2为真值。也就是说可以仅仅将这四个元素调出来。 如果对整张地图进行管理的话，那么一个不容回避的问题是如何对自定义地图格式进行合理的定义，一张地图经过矢量化处理后，一般可以

10、分为以下几种基本图元：点、圆、弧、折线、直线、多边型、文字 ；我们可以分别把它们定义为每个链表的一个节点（NODE）可以基本按下列方法进行描述（按类似于C+类的描述方法进行描述） CLASS NODE 关于节点基本描述； 关于节点基本方法； CLASS META：NODE 层次描述； 颜色描述； 填充描述； 位置描述； 适用比例描述； 文字描述1 文字描述2 文字描述3 脚本描述 填充方法； 绘图方法； 查询定位方法； 剪裁方法； 适用比例范围超出方法； 。CLASS LINE：META 对父类的方法进行重载； 相应图元的具体描述和相应方法；同理 可以类似推导出其它图元的定义。适用比例范围概念

11、的引入，以便可以处理不同比例的地图，例如有10张1：10000的地图，100张1：500的地图，200张光栅示意图1：100；我们可以在处理时在适用进行比例范围超出方法中定义如果超过相应的比例尺时所应该进行的操作，具体的说，可以在比例尺超过10000时，调入相应的1：10000地图来进行显示，并以稀疏矩阵M210来说明10张1：10000的地图，而当比例尺小于1：100时，调入相应的1：100光栅地图来进行显示，并使用稀疏矩阵M3200来说明200张光栅示意地图。 4 关于系统描述宏的定义 对于一个开发平台来讲，必须在构造可增量原型的基础上，对用户的选择及操作行为给予相应的解释，换句话说，也就

12、是在可增量原型的外层构造一层解释器或编译器，加载用户的操作脚本进行执行；有关编译器或解释器的构造原理相应的资料已有充分的介绍；对于用户自定义宏的定义，在一开始就应该对相应语法是否规范、是否满足要求、底层平台和数据操作的定义能否满足其要求，解释或编译程序和语法分析程序能否较容易编制等都进行充分的考虑。 根据以上的分析，我们可以得到知道：要合理的定义相应的宏，必须合理分析相应目标的定义，对每个系统目标的分析须对各种事件进行进一步细化，而把命令集内部的多余单元去掉。对于通用操作部分： 对于单个操作或较为简单的命令，可以使用交互式界面，内部设置对应此操作的词法分析器及解释器，由解释器直接加载运行。如具

13、体进行A操作，直接调用平台内设的A操作的引擎函数；而对于较为复杂的命令（指含有控制结构的语句），如果可以分解为多个简单操作的话，由对应此操作的语法分析器及解释器直接加载运行。此处的语法分析器一般在其内部调用词法分析器或是词法分析器的继承类。如具体进行B操作，而B操作本身可分为B1和B2两步简单操作，它们无非有三种情况， 1 B1先运行 2 B2先运行 3 B1和B2同时运行（这里假设1、2、3都不包含任意条件）那么我们可以简单将对B的相应运行方式进行描述。同理，对于更复杂的C（假设由C1，C2，C3组成）我们可以近似地将C描述成（C1，C2），C3，然后在进行下一步的描述。对于用户自定义命令，

14、先应提供交互式界面来进行描述和定义，然后使用组件管理程序进行管理，如果是用户自定义程序，先应加入组件管理库中，否则，从已有的组件集合中加以选择来进行组合。对于平台下管理的基本操作，一般来说，应把基本操作尽可能化为程序组件，平台提供给用户最基本的操作手段，用户还可以对操作进行再定义。对于数据库描述部分 因为程序的运行很大一部分数据来自数据库，所以如何定义平台相应模型来与用户的数据库结构对应起来是一个较为复杂的问题，结构化查询语言SQL是目前较为通用的数据库查询语言，它提供了相当强的数据库操作功能，不足之处是它不是一种结构化的语言。在这里，我们可以采用以下方法来解决：1我们可以把其他与具体数据库紧

15、密关联的部分作成组件与平台进行相关，并定义相应操作命令。2我们还可以把SQL语言分为两类，第一种为须返回结果集合；第二种仅进行一般数据操作，而不需返回结果集合。然后，利用已定义的结构控制命令，对相应的SQL语句进行描述，发送相应SQL语句到平台的语言解释程序，并利用通用或专用数据库接口对相应操作进行调用或传送。有结果集合返回的，利用相应接口获取返回数据。具体如下： DDE是16位WINDOWS 所最早支持的不同程序进行通讯的方式之一，DDE的基本概念此处不做介绍；利用DDE技术和组件管理程序，将具体程序作为DDE的SERVER，平台本身定义有限个较为通用的方法及协议由平台来与其进行交互。例如查

16、询某表，可以在平台本身定义“查询”操作，而使用数据库前端开发工具作为DDE的SERVER，并具体对某表进行查询，某表为平台对SERVER发送的参数。 我们还可以使用如前所诉的语言解释程序对相应的SQL语句发送到ODBC接口，对于有结果集合返回的操作，在平台内部定义相应的FETCH程序进行结果的检取和显示。5应用背景基于多媒体的GIS系统在电信、电力部门有极其广阔的应用空间，从我们部为沈阳电业局开发的第一个基于SUN SPARC WORKSTATION的版本到现在覆盖PC和工作站两种平台，基于SOLORIES、WINDOWS 3。1 /WINDOWS 95/WINDOWS NT、ORACLE/S

17、YBASE/OPENBASE/ODBC多种版本、在山东临沂、淄博、济宁、威海；辽宁沈阳、营口、丹东、本溪、湖南长沙、邵阳及浙江萧山、温州、河北秦皇岛、石家庄、河南新乡、福建南平等地的几十家电力、电信单位得到广泛应用，得到用户的好评和认可。5 1临沂供电局GIS应用情况 临沂电业局的电力配电辅助系统由工作站和微机两种版本组成，数据库采用SYBASE 10，微机端使用ODBC对数据库进行访问，微机版运行于WINDOWS 3.1之下，使用VC+1.5/POWERBUILDER 4开发，工作站版运行于SUN SPARC 20 下，使用ANSI C+/XVIEW/嵌入SQL开发，整个系统平台使用了用户交互界面和用户配置文件来与应用开发者进行交互，用户界面友好，对于较为复杂的辅助决策模块，采用了用户自定义组件外挂的