1、引言
日本是一个铁路交通非常发达的国家，轻轨电车、地铁、新干线遍布各处，纵横交错，把城市和乡村连成一体。为了维护交通的日常运行，及更加有效地管理各种铁路设施，日本最大的铁路公司JR东日本集团决定开发一系列铁道GIS。本系统是其中的一个基础系统，用于统一管理遍布日本全国的铁路设施，开发成功后将为JR东日本集团的指挥调度室及集团子公司使用。系统不仅数据量巨大，而且质量和性能要求非常严格。只有从功能、界面、数据、性能等各方面均满足要求，才能投入到实际工作中使用。 2、系统结构
根据要求，JR铁路GIS系统主要用作Internet/Intranet网络发布，系统将在服务器安装大型数据库客户端提供浏览器界面即可直接访问。本系统根据用户网络带宽的不同，提供了两种网络结构及对应的两个版本，以适应不同条件的用户。使得用户可在公司内外任何地方，通过Login帐号和密码控制都能访问该系统。一种为B/S结构（基于SuperMap IS 2003模板的版本，简称IS版），它主要用于发布数据和地图。适用于外部因特网和内部局域网，在网络带宽较小的情况下更能体现其优越性。另一种为C/S机构（基于SuperMap Objects 2003包装的OCX版本，简称OCX版本），适用于网络带宽较大的内部局域网，可以用它浏览和编辑地图。两种网络结构集成在一起运行，共用同一个数据库。
IS版本的系统结构简图如下。以MS IIS和SuperMap IS作为引擎，响应客户端请求并访问后台Oracle数据库。该结构能够穿透防火墙，适用于外部因特网和局域网。
OCX版本的系统结构简图如下。该版本通过VB利用SuperMap Objects 2003包装一个铁道GIS控件。该控件运行在客户端浏览器，通过局域网、专线网或虚拟专网(VPN)来直接访问服务器端Oracle数据库。
3、系统功能和界面
IS版和OCX版共有的功能：地图显示(放大、缩小、漫游、点选、前一视图、后一视图打印地图等)，旗上标注，检索（设施、里程和住所）、距离和面积量测、地图旋转、索引图、用户访问统计、数据编辑、系统管理（用户管理和系统日志部分）。
OCX版因为要用于内部管理，故功能设计得更多一些，其独有的功能有：地图连续自动漫游、比例尺设定、系统管理（地图更新和地图操作统计部分）、缓冲区分析、拷贝地图、排版打印等。
| | 图3 设施检索和IS版本的地图编辑界面 | | | | | 图4 IS版本系统总界面及矢量地图的显示 | | | | | 图5 OCX版本系统总界面及影像地图的显示 | | | | | 图6 旗上标注显示、里程检索和住所检索功能的界面 | | | | | 图7 用户管理、用户信息编辑和地图更新功能的界面 | | | | | 图8 用户登录日志管理功能的界面 |
4、地图和数据库设计
4.1 数据整理
系统中的数据分为四部分：BMP影像、铁道设施矢量数据、市街地图矢量数据、及用于提高系统查询速度和进行用户管理的辅助数据部分。
数据的结构规律是以24条首都圈铁路和3条新干线为脉络，沿线分布了航空影像和市街地图类的数据。24条首都圈铁路全部属于日本坐标系第9系（简称9系，以下类似），上越新干线跨越8系和9系，而东北新干线从首都圈出发，跨越9系和10系，山形新干线全线在10系境内。
从内容上看，系统数据以四类形式存在。
（1）铁道设施数据：铁道设施数据对用户虽然很重要，但数据量少，没有太多需要考虑的地方，只要能够跟其它三种数据协调工作就可以了。
（2）市街地图数据：相较之下，市街地图数据比较复杂，原始矢量数据有440个图层,每个图层的边界范围都是同一区域。另外，首都圈市街地图中各图层含有的对象数极为不均匀。最小的只有7个对象，最大的达到5,000,000个对象，中间有几个20万左右的，及一个178万左右的。根据一般原则，一个地图中的层数过多和过少，都会导致显示及查询效率降低。因此，数据在进库时要进行适当的分割和合并，重新组织和调整。
（3）影像数据：这类数据的特点是量大，总量达到167GB,分属于三个不同的坐标系。数据量大时首先需要大容量磁盘，同时需要较高的访问速度。
（4）辅助数据：这类数据存在的目的是辅助提高系统性能，方便系统开发，同时也包含一部分全局性的数据，用于满足一些全局性的功能，如系统管理、住所检索等。这类数据的很多内容都需要根据原始数据通过编程二次生成。
|
| 文件格式
| 数据内容
| 文件数和总尺寸
| 备注
| | 铁道设施
| SHP
| 1）首都圈（含有东北新干线）
| 13个文件，20.9MB
| 首都圈全部范围属于9系，上越新干线跨越8系和9系，东北新干线跨越9，10系
| | 2）新干线9系（含有上越和东北新干线）
| 16个文件，8.37MB
| | 3）新干线8系（含有上越新干线）
| 9个文件，3.02MB
| | 4）新干线10系（含有山形和东北新干线）
| 18个文件，7.40MB
| | 市街地图
| DWG
| 1）首都圈（含有东北新干线）
| 213个文件，1.81GB
| | 2）新干线9系（含有上越和东北新干线）
| 54个文件，411MB
| | 3）新干线8系（含有上越新干线）
| 19个文件，115MB
| | 4）新干线10系（含有山形和东北新干线）
| 43个文件，286MB
| | 航空影像
| 24位BMP+TFW
| 1）
首都圈
| 7282个文件，72GB
| | 2）新干线9系（含有上越和东北新干线）
| 3917个文件，56.8GB
| | 3）新干线8系（含有上越新干线）
| 1181个文件，13.1GB
| | 4）新干线10系（含有山形和东北新干线）
| 3453个文件，38.5GB
| | 辅助数据
| 属性数据
| 经纬度数据，中间临时数据，系统管理数据
|
| 该数据源定义为经纬坐标系，纯属性数据（坐标数据也作为属性数据存储）
|
4.2 数据组织和处理
在GIS系统开发中，数据组织、数据处理以及地图制图是紧密相关的，它们都服务于一个中心目标——系统的高效运转，并且都要基于具体基础软件（本系统中是SuperMap）的特点来实施。数据组织这个步骤并不仅仅是其本身，而且也贯穿于数据处理和地图制图阶段中，同时它也是数据库设计和系统设计的核心组成部分。因此，几大步骤往往相互交融，必须在系统设计的框架下进行前后关联考虑。
本系统中地图数据组织的目标是，通过合理控制地图尺寸和图层数，尽可能地发挥SuperMap 基础软件的技术特点，以达到最佳的显示浏览效果。既要追求地图浏览速度，同时也要保证地图图象的内容、质量和美感，为用户提供实用和高质量的地理信息服务。
原始数据文件多、种类杂、数据量也大、处理起来费时费力。按照常规的全手工处理方式，效率将会很低，需要采取手工加自动化的方式进行处理。下面分几个步骤进行简单介绍。
4.2.1 数据源、Oracle表空间及数据文件
由于系统地域跨越日本坐标系的8系、9系和10系三个不同的部分，SuperMap的坐标系信息存储在数据源中，同时为便于以后维护备份方便，能够并行访问多个磁盘/磁盘阵列甚至做到多机并行集群处理（若条件允许）提高速度。因此总体上将空间信息分成3个数据源，一个数据源存储一个系的数据，8系、9系和10系三个数据源的数据量极不均衡，其中以9系（含首都圈）最大。
为管理系统方便，把帐号、日志等一些系统维护信息放在一个单独的数据源中，同时把系统功能实现时需要的一些中间表放在这个数据源中。另外，横跨8、9、10系的初始地图需要做成地理坐标系地图，住所数据也是如此，因而创建时给该数据赋予地理坐标系投影信息。总体来说, 该数据源作为一个公共数据源存放一些具有全局性和中间性的信息。
这样，系统一共有四个数据源。在Oracle中实施时，为便于以后维护备份方便，同时能够并行访问多个磁盘，提高速度，也分别建了四个表空间，每个表空间存储一个数据源的数据。
同时根据SuperMap SDX+ for Oracle 引擎技术对矢量和影像数据存储的特点创建数据源，详细情况举例如下表。
| | | | | | | | JRGISDS8
| JRGISTSP8
| JRGISTSP8.dbf
| 2GB
| JRGISU8
| | 8系数据源
| | JRGISDS9
| JRGISTSP9
| JRGISTSP9.dbf
| 12GB
| JRGISU9
| | 9系数据源
| | JRGISDS10
| JRGISTSP10
| JRGISTSP10.dbf
| 5GB
| JRGISU10
| | 10系数据源
| | JRGISCMNDS
| JRGISTSPCMN
| JRGISTSPCMN.dbf
| 1GB
| JRGISUCMN
| | 公共数据源
|
4.2.2 数据集
（1）铁道设施数据集
铁道数据集数据量小，一种类型一个SHP文件，导进来后可以直接作为一个数据集存在，首都圈和新干线9系的铁道数据都属于9系，因此可以把同类数据集合并。 （2）市街地图数据集
对大数据的管理和读写能力，关键取决于数据库引擎的管理能力和存取速度，以及是否能够在数据组织中根据实际情况对其进行灵活有效地运用。
对于这部分矢量数据，从两个方面进行考虑。一个是横向上的区域分割与合并，另一个是纵向上的图层分解与合并。
在横向区域方面，由于对象多的图层只在大比例尺下显示，加之SuperMap本身良好的空间索引技术，即便对于大数据集，系统也能进行快速的显示。由于原始数据DWG文件众多，达到二、三百个，实际处理时，我们根据数据的特点对同类型图层在导入时进行了合并处理。
在纵向图层方面，以首都圈为例，导入进来后，图层数约为290个。再通过把多个同类和只在极小类别上有差异的小数据集（对象少）合并成一个较大数据集的方式，进行两次合并处理，首都圈范围内的市街地图图层数最后变为24个。这样，就为后面控制总图层数的前提下，在一个地图中加入其它图层留下了较大的弹性空间。不过，合并后由于一个图层包含了多种地物信息，在地图信息详细程度不能缺少的前提下，制图时必须启用专题图来表达。SuperMap带有的7种专题图功能能够满足这方面的要求。 （3）航空影像数据集
如前所述，航空影像文件数大约有15000多个，数据处理的工作量很大。按照一般的处理方法，是先把众多的小BMP影像导入SuperMap的SDB文件，进行合并。合并之后，再利用SuperMap的压缩技术存入Oracle数据库。其简要流程如下： BMP文件 --> SuperMap的Image数据集 --> 合并 --> 压缩导入Oracle数据库
上述方法的缺点是耗时长，尤其在压缩和合并阶段，中间过程需要人工干预，这样处理效率较为低下，而且容易出错。为了加快处理速度和避免出错，SuperMap专门提供了处理影像数据的工具，用于将上述处理流程尽可能一体化和自动化，直接由BMP压缩导入Oracle数据库。实施结果表明，作业时间比一般流程的作业时间减少了2/3，而且基本不出错。
导入之前，应事先设计好哪些BMP文件合并成一个SuperMap的Image数据集，同时指定压缩比率。在压缩比率上，SuperMap具有较为宽松的选择范围，在0.05—0.95之间都能得到良好的压缩质量。针对本系统数据，综合考虑质量、尺寸/图层数、速度等因素，最终把影像数据集的标准尺寸定为5GB，压缩比率定为0.07。
通过在Oracle数据库中压缩存储，原来167GB的影像数据尺寸变为大约11GB，大大节约了磁盘空间，也为后期成果备份和数据迁移提供了良好的基础。同时，对压缩在Oracle中任意范围的影像数据，进行放大、缩小、自由缩放、全幅显示等操作非常流畅，影像旋转也很快。对9系范围内将近129GB的影像进行操作，效果几乎与几十MB的影像没有什么差别，完全令人感觉不到正在操作一个大数据。 （4）公共数据集
第四类数据集是公共数据集，全部保存在公共数据源里。按照用途可以分为五类：
1）铁路线代码及名称、设施类型及名称、设施实际数据、车站实际数据；
这类数据用于系统快速查询和地图快速定位，比如当用户从线路组合框中选择了某一线路，该线路上所有车站都应被自动加在车站组合框中，而这个步骤是通过车站表完成的。车站表中同时含有地图名称和明码坐标数据，可以直接取出，以提高车站在地图上的定位速度。
2）住所数据；
住所数据分三个表，详细程度到“番地”，再下级就是门牌号。为了支持快速查询，我们在系统中建了两级索引。住所数据是点类型的数据, 其坐标信息是经纬度的, 为查询后定位方便, 入库时进行了投影转换处理, 并增加一个字段存放住所所属地图名，增加另外两个字段存放转换得到的直角坐标信息（X、Y值）。
3）系统管理数据；
系统管理数据，例如用户名、ID、登录信息、个人操作的内容、修改的几何对象等。
4）初始地图数据集；
初始地图是范围覆盖日本全境的地图，数据集跨越日本的很多坐标系，因此该类数据以地理坐标系形式存在。主要包括日本行政区域、矢量数据范围网格和全境铁路信息。
5）中间数据；
此类数据是为实现某些系统功能、方便系统编程临时存在的数据。比如旗上标注的旋转，因为标注对象的主线和文字都是水平的，当旋转地图时，用户希望线和文字仍然保持水平。因此，必须能够单独处理和控制标注层（控制包括增删对象、旋转对象、显示与非显示图层等），而不管该图层是否已经打开和显示，这要求GIS基础软件平台能够提供灵活丰富的接口。顺便指出，这里已经深入到系统详细设计阶段，这也说明了数据组织和系统设计之间具有紧密的内在联系，不可分割。 （2）MESHCODE开头，地图范围网格编码数据集系列； （3）MESHLINE开头，地图范围网格线数据集系列； （8）USEREDITCAD开头，用户编辑如增加几何对象时系统在Oracle数据库中为用户自动保存的数据集； （9）SHICAD开头，旗上标注CAD数据集，该数据集中的对象通过程序自动生成，用户修改旗上标注之前，系统会为用户在SHICAD中选中的旗上标注对象上，拷贝生成一个形状和中心位置将要改变的新对象，并保存在用户公共数据集USEREDITCAD中。同时，通过在USEREDITCAD中用一个属性字段标识这个派生对象属于哪个用户，以便该用户下次打开旗上图层时仍能看到自己上次编辑的结果。所有用户在同一数据源中拖动生成的新对象都保留在这个数据集中，但显示时通过过滤条件只显示属于这个用户的对象；同时也通过过滤条件控制SHICAD图层中的原始对象不显示。 （10）ROTATESHICAD，用户旋转地图时，旗上标注层也跟着旋转，但是用户要求旗上标注对象中的主线条和文字要始终保持水平。因此，设置一个临时图层专门用于实现这一要求。具体实现时，用地图窗口范围在SHICAD数据集中查询出当前窗口要显示的旗上标注对象，将这些结果对象围绕对象的基点反转地图的旋转角度，之后存入ROTATESHICAD临时数据集中，最后显示该数据集。注意，每次刷新地图之前（而不是保存对象之前，因为多个旗上标注图层的对象都保存在这个数据集中）都要清空临时数据集。 （11）stk开头，范围在首都圈地图里的某数据集； （12）SK开头，范围在新干线（SK8，SK9，SK10）地图里的某数据集； （13）jeSKR开头，上月新干线影像数据集系列； （14）ymgtSKR开头，山形新干线影像数据集系列； （15）thkSKR开头，东北新干线影像数据集系列； （16）stk23R开头，首都圈23区影像数据集系列； （17）stktbstR开头，首都圈其它区影像数据集系列； （18）stktmsmR开头，首都圈其它区影像数据集系列； | 
楼主
发表于 2007-9-3 11:22:43
inking Flow Model with GIS［J］.Journal of Water R esources Planning And Management,1993,119(2).
