高性能地图优化策略
高性能地图优化策略
摘要：
高性能地图的优化涉及空间数据库技术、操作系统等多种计算机技术。本文通过介绍SuperMap软件提供的诸多地图优化策略，进一步阐明了空间数据库的基本原理和地图显示性能的影像因素。对于今后各个项目中，提高地图性能都提供了系统的、切实可行的解决方案。
关键字：数据库 空间数据 空间索引 缓存技术
1 引言
空间数据库是GIS系统的基础，通过多源数据无缝集成的海量数据，组成地图性能的高低，直接关系这整个信息系统是否能够稳定、高效的运转。而随着计算机硬件的、操作系统、计算机网络以及数据库技术的发展，空间数据库以及地图性能的提升也从中汲取了灵感，获益匪浅。
北京超图软件股份有限公司自主研发的空间数据库扩展，即SuperMap SDX+技术在利用先进计算机技术，着眼于深入研究空间数据库，为高性能地图优化提出了很多解决方案。本文就是针对高性能地图优化策略，通过地图性能的影响因素、地图性能优化方法以及实际案例的讨论，为大家系统的解密高性能地图是如何诞生的。
2 地图性能的影像因素
2.1 性能表现
从性能表现来看，地图的性能主要通过两个时间度量来体现，一个事查询时间(Query Time)，另一个是绘图时间(Draw Time)。在每次做地图操作时，都会根据显示范围和显示比例通过SDX+向数据库进行查询分析，并返回数据结果。这个阶段花费的时间就是查询时间。
而绘图时间主要是在客户端得到查询结果之后需要重新绘制地图，这个时间主要在客户端本地耗费。这两个性能指标，作为在进行地图优化的工作过程中是最为重要的，用户可以在SuperMap Deskpro 中使用到。首先保证没有SuperMap Deskpro程序运行，然后打开安装目录下.. /SuperMap/SuperMap Deskpro 6/Bin中的SuperMap.ini文件找到一下内容：
[Layer]
# 是否显示调试对话框
# 调试对话框中可以查看每一层的查询时间和显示时间，以及地图的总的刷新时间
# 0 -- 不显示调试对话框
# 1 -- 显示调试对话框
ShowDebug = 0
注意将ShowDebug参数改为1，保存后打开SuperMap Deskpro，打开任意地图或浏览数据集，就会弹出一个小窗体，如下图：
图2-1 SuperMap调试窗口
其中我们看到出现一行信息，第一列DrawID表示进行操作的ID，LN代表图层名称、QT代表查询时间、DT代表绘图时间、TT代表总时间而OC表示当前窗口浏览的记录数。通过这些信息我们可以基本看出每个图层所消耗的时间，从而体现出整个地图的性能。
下面先从几个方面讨论下究竟哪些因素会影响地图的性能，并确定其各自是影响的查询时间还是绘图时间，这对于后面采取何种对应的优化方法非常关键。
2.2 计算机环境
2.2.1 硬件及操作系统
内存在是地图显示性能的关键，因为在打开一幅电子地图之后，所有显示出来的图层都是保留在内存中的，显示的图层、对象越多占用的内存资源就越大。因此在配置地图的时候要让当前所显示的图层、对象数量以及复杂程度尽可能保持在合理的范围内。
与显示性能相关的还有显卡，显卡芯片处理图像计算的能力越强，独立显存越高，对应着地图在刷新的时候，对于同样的地图数据，绘图时间会更高。
现在的计算机基本都是支持多核CPU，而服务器则具备支持多CPU的主板，所以在运算环节上并不存在瓶颈，而需要关注的则是通过数据、操作系统等环节的设置，合理利用CPU的资源。
在存储介质上，硬盘目前仍然是一个性能提升的瓶颈，比如IDE7200转与SCSI10000转，虽然只提高了20%的转速，但性能却差异相当大，会提升2～3倍之多。目前不少服务器采用Raid（Redundant Array of Inexpensive Disks）技术，即硬盘集群技术，该项技术会带来很多优势，比如高可用性，安全性，性能的提升。但Raid技术也需要合理使用，否则不会达到理想的效果。Raid0，Raid1和Raid5，目前使用较多。另外，还有软Raid与硬Raid，后者成本较高，但性能优于软Raid，可查阅相关资料，了解更多关于磁盘集群技术的特性与使用。
而为了提高性能需要解决的一个问题是减少磁盘I/O，将一部分或者全部数据保持在内存中，所有的数据读写都是在内存中。而现在32位操作系统理论最大支持4G的RAM，比如Windows Server 2003。一般的操作系统配置最高支持3.7GRAM，而这并不是可以全部被利用的。如果采取内存数据源为策略，那么建议使用64位操作系统或64位Oracle。
另外一个需要解决的问题就是网络，对于GIS数据的传输，网络必然成为瓶颈，如果是桌面应用程序（Client）加空间数据库服务器（Database Service）的模式，每个数据请求返回的查询结果数据都要以几兆几十兆甚至更大的数据量通过网络发送到客户端。即使是以图片数据传输为主的WebGIS应用，相对于传统网站传输的数据量也是巨大的，因此合理选择网络环境，充裕的带宽，或选择专网专线，加大投入成本是非常必要的。
除了硬件因素影像地图性能意外，操作系统也是非常关键的环节。对于操作系统我们都了解，Windows OS本身设计人性化，图形化界面交互能力强，但是系统稳定性相对Unix/Linux较差。
在我们关注的性能方面，经测试，对于单客户端访问Windows，其性能会优于默认配置的Linux操作系统，其原因可能是默认配置的Linux并非最佳，一些不需要的服务和图形界面会占用资源。根据上文所述，采用无图形界面纯Linux内核的操作系统，性能肯定会优于Windows。在高并发访问上，并发数在20个以下时，Linux上的优势同样不明显，一般多于50个时，其优势会逐渐显现。
2.2.2 数据库
SQL Server和Oracle依然是现今使用最为广泛的两种数据库，SQL Server方便的界面化以及依附Windows操作系统使用的便捷性上是其重要的优势。而从性能、稳定性上还是建议使用Oracle，对于海量空间数据的管理，处理高并发，大数据量的吞吐Oracle占据了较大的优势。同时针对其性能可控制的环节更多了。
下文中主要针对Oracle数据库进行性能优化策略的分析。
2.3 数据组织
2.3.1 数据
GIS中的数据主要分为矢量和栅格数据两类，各自对于性能的影响因素不同，这跟源于其各自的数据结构：
l 矢量数据
矢量数据是用点，线，面及其X，Y坐标来构建点，线，面等具体空间要素的数据模型。
点实体：在二维空间中，点实体可以用一对坐标X，Y来确定位置；
线实体：线实体可以认为是由连续的直线段组成的曲线，用坐标串的集合（X1，Y1，X2，Y2……Xn，Yn）来记录；
面实体：在记录面实体时，通常通过记录面状地物的边界来表现，因而有时也称为多边形数据。
每个空间对象的复杂度往往和节点数有关，比如在较大比例尺的全国行政区划数据层中，每个省、自治区面对象节点数就有成千上万个，这样的数据没有进行优化的话，浏览的性能会相对低一些。
另外某些数据是类似CAD数据格式制作的，那么在导入到SuperMap数据源中之后如果依然使用复合数据集的方式管理，那么在显示性能方面也会存在些问题。
首先复合数据集是可以同时存储点、线、面、文本数据的，也就是所有的地图数据全部在一个图层中，如果在全幅显示的情况下，速度会比较慢，而如果选择导入为简单数据集，那么后面经过地图图层显示比例的控制，可以很好的提升地图的整体性能。
总之，在矢量数据的组织上，建议合理降低数据本身的复杂度，同时尽可能分层管理数据，并进行显示比例的控制，达到地图调优的目的。
l 栅格数据
栅格数据的范围和分辨率是影响地图性能的主要因素，同时大多数的影像格式都对影像进行了压缩，根据影像用途的不同影像压缩的方式也不同，压缩比越高的数据显示性能越高，但数据精度越低。而使用SuperMap导入的影像并没有主要采取压缩的策略进行优化，而是采用了影像金字塔的方式，在保持数据原有数据精度的基础上提高了数据的显示效率。
l 编码技术
矢量和栅格数据都可以使用编码压缩技术，对数据进行压缩，提高数据的显示效率。
矢量数据有SDC和SWC两种，应用于线、面类型，对点数据集不起作用。压缩比为4倍。精度损失为1/216。数据集中对象大小比较平均的情况下，推荐使用此种编码方式。
SDC，DWORD编码类型，应用于矢量数据集（线、面类型）的一种编码方式，对点数据集不起作用。压缩比为2倍。精度损失为1/232，按照全球大小的对象估计，精度损失在毫米级。总结其优势：压缩速度快，损失小，原图和编码后的图对比浏览时，基本看不到差别。可以说SDC是几乎接近无损的一种编码方式，一般的数据推荐使用SDC。
栅格数据使用DCT编码方式，即离散余弦变换，是最适合于遥感影像的一种编码方式，压缩比一般为20倍。另外SuperMap自主研发的影像压缩格式SIT，并没有对影像进行压缩，而是采用影像金字塔技术，提高了数据的显示性能，同时这类数据导入到由SuperMap创建的数据源中的效率也是非常高的。
2.3.2 图层划分
前面已经提到过，如果要配置一幅高性能的地图，数据组织上最好通过分层管理的方式。由于地图性能主要取决于当前地图窗口中可显示的图层，因此合理设置每个图层的显示比例，是最基础也是效果最突出的优化方式。
控制图层显示比例的目的是为了使原本保存在同一个数据集中的数据，由于其中的几类数据不适合显示在同一比例下，才采用了分层管理的方式。然而，如果图层过多，而很多图层的显示比例是一样的，这样就没有必要了，地图的性能也会受影响。所以，是否需要分层还需要根据数据规范、业务逻辑来进行分析判断。
1 地图性能优化方法
1.1 服务器优化
l 只安装必要的选件
l 关闭界面美化选项
如在Windows操作系统，系统属性里，有一个性能选项（Performance Options），一般选择性能优先，而不是显示优先。如应用系统中不做三维图形显示，可将操作系统中的显示属性/Settings/Advanced/Troubleshoot中，硬件加速（Hardware acceleration）调到None。
l 设后台服务优先
在“系统属性”的“性能选项”中，“高级”页面，调整Processor Scheduling为后台服务优先（Background services）。
l 关闭不必要的服务和端口
检查您操作系统中所有的服务和端口，对于一些用不到的服务和端口，可将其停止或关闭。
l 尽量将数据库服务器与WebGIS服务器分开
多数情况下，针对数据库服务器和WebGIS服务器的优化是有冲突的，而且若这两者在同一台设备上，也会产生资源争用的情形，WebGIS服务器对内存的消耗也是非常大。另外，有一点值得注意，最好不要将这两类服务器分到两个子网中，即中间最好不要有路由器。
l 关于杀毒软件
一些杀毒软件在运行查毒时，非常消耗资源，服务器尽量不要安装杀毒软件，在一些优化措施已实施的情况下，比如关掉不必要的服务和端口，病毒一般也不会感染服务器。在Windows Server 2003下若要安装杀毒软件，也尽量将查毒时间放在系统闲时；而在Solaris，AIX或Linux下，最好不要安装杀毒软件。
1.2 数据库优化
1.2.1 只安装必需的软件包
以Oracle 11g为例（以下同），在安装Oracle过程中建议使用高级安装—>定制方式安装。因为如果默认安装之后，不会使用到的组件可能会自动启动一个服务，占用系统资源，所以在选择可用产品组件时建议根据实际需要选择必需的组件。
图3-1 Oracle 11g 选择安装组件
1.2.2 建库只选必需的选件
在建立数据库时也要注意数据库组件的选择，为创建的数据库进行瘦身。比如要创建一个SuperMap SDX+ for Oralce 的数据源，那么Oracle Spatial的组件就不需要添加了。除非应用数据库就是Oracle Spatial的，那么它就是必需的。
1.2.3 分配合适的内存
对于Oracle 内存的分配并不是越大越好，首先要考虑这台服务器会运行哪些程序，是否其即作为数据库服务器，同时也作为Web服务器等等。这就要求服务器的内存除了满足Oracle运行之外，还要分配给其它程序。
如果服务器内存比较充裕，分配给Oracle一般1G-2G即可，如果服务器内存只有1G内存，那么建议Oracle不要超过60%。
1.2.4 设置合理的参数
这部分的优化解决的主要矛盾是数据吞吐效率和用户并发效率。大部分初始化参数可以进行优化调整以提高数据库性能，用户可注意修改几个参数，在Oracle 11g 中以下几个参数的默认值都有了比较大的提升，采用默认也是可行的：
l cpu_count为分配给Oracle数据库的CPU个数，默认为2，如果服务器是多核CPU，则可以把此值增大，在分配CPU时也要考虑服务器的用途，适当为操作系统其它程序预留CPU，服务器整体性能的提升才能更好的提高Oracle运行的速度。
l db_file_multiblock_read_count影响Oracle在执行全表扫描时一次读取Block的数量，默认为128。用户可以根据自己的系统环境更改。此值受系统I/O最大能力的影响：Max（db_file_multiblock_read_count）=Max（系统I/O）/db_block_size，一般可以改成32，甚至更大。
l db_block_size 不应小于8192。
l Open_cursors 根据并发用户数决定，但一般不应小于300。
l Sessions：根据并发用户数决定。
l Job_queue_processes：不应小于100。
通过以上的方法对数据库优化之后，在做数据入库或者数据库查询返回大量的数据结果的效率会有较大提升，这一点在Oracle 10g上比较明显，因为它的默认参数都比较低，必需修改后才能看到效果。
1.3 地图显示速度优化
地图显示速度的优化，原则就是在一定比例尺下，一定地理范围内只显示最适合显示的图层或对象。让地图显示的对象越少越好，同时兼顾系统对业务数据的特定要求和地图的美观。下面结合实践介绍几个优化的基本方法。
1.3.1 对象过滤显示
l 过滤对象尺寸
在很多大比例尺的数据，比如流域水系、土地利用当中，对象数量多，小而碎的数据也会比较多，这样的数据即看起来不美观，也会影响显示性能。这时合理设置对象过滤尺寸可以将这些小而碎的数据过滤掉，而且也不会对空间查询结果产生影响，因为这仅仅是显示上的处理。
l 过滤显示条件
同样是过滤的方式，只是方法是设置过滤条件，通过SQL语句来控制显示符合条件的对象。这里还可以灵活使用，通过开发可以实现不同比例尺，不同显示范围下显示符合不同条件的对象，即优化了地图显示性能，又实现了特定的业务逻辑。
l 文本过滤显示
在矢量数据中比较耗费资源的，文本算是一类。因为其每个文本对象结构相对复杂，除了记录空间位置，属性数据之外还记录了字体风格样式的信息。
这类数据显示时，建议当前地图窗口中同时显示的文本对象个数不要超过200个，大于这个数量级速度就会比较慢了。由于显示200个文本的地图已经严重影响了美观，所以这个界限已经比较高了。
另外为了处理文本压盖的问题，可以通过设置标签专题图文本风格的自动避让，以及设置地图的文本过滤属性，都可以解决这个问题。过滤掉的文本会在放大了比例，有足够空间范围显示的情况下显示出来。
1.3.2 图层过滤显示
设置的原则是，首先保证当前比例尺下该图层显示性能较低（通过肉眼观察或ShowDebug可以清楚判断）的图层放到更大比例尺下显示。例如：点、线数据过于密集；或者制作了标签专题图之后，标签基本被过滤掉；或者显示的对象太多，明显影响了刷新速度等等。这时就需要将此图层放到更大比例尺下显示。
其次就是尽可能的使地图每次缩放操作都有图层显示的变化。这样地图的层次感就显现出来了。
1.3.3 地图缓存
地图缓存我们可以分为两种，一种是将当前地图按照设置的比例尺和缓存范围生成一系列的缓存图片。在浏览此地图时可以直接读取缓存中的图片，从而提高地图显示的速度。系统提供了JPG、PNG、位图、TIFF、GIF等5种格式，针对用户不同的需求进行选择。
这种方式主要应用于Web发布时使用，对于单纯浏览的应用来讲，也是最快的一种地图方式。
另一种缓存机制叫做用户缓存，这种缓存是针对某一个数据集的设置。一旦注册了某个数据集为用户缓存模式，那么在客户端第一次浏览该数据集的时候，从服务器查询获得的数据会在本地生成一些数据压缩包文件。这些文件的路径也是可以通过Deskpro或者Objects的配置文件设置的。
如果第一次浏览有点慢的话，第二次刷新这个图层的时候，数据无需从数据库查询计算、通过网络传输，而是直接从本地读取，速度会有很大提升。
1.3.4 建立索引
SuperMap 为了提高矢量数据的查询、访问、排序、浏览等操作，提供了多种文件索引，包括字段索引、四叉树索引、R树索引、动态索引和图库索引（原三级索引）。下表为 SuperMap 各引擎对文件索引的支持情况：
l 创建字段索引
字段索引是数据库系统或者其他计算机系统中提供键值快速定位的数据结构。字段索引提供了对特定键值的数据快速访问的能力。适用于数据较小的矢量数据，例如普通创建的矢量数据集。
SuperMap提供的了数据集字段索引功能，以方便对数据集建立或删除字段索引。该功能可以为数据集中的一个或者多个字段创建索引，有助于快速查找、浏览和排序数据。
实际应用中的数据有的是分幅的，会有一个属性字段记录该数据的分幅信息，那么建议可以使用这个字段创建字段索引，有助于快速查找和浏览数据。
l 创建空间索引
随着GIS的发展，GIS的数据量逐渐增大，使得空间数据的访问速度降低，而空间索引就是用来提高数据的空间查询和访问效率的数据结构。
地理信息系统中的空间索引是相对于字段索引而言的。由于空间数据特有的位置相关性，传统的字段索引不能满足空间数据快速定位的需求，因此需要空间索引的提供位置相关的数据的快速访问能力。
SuperMap SDX+ 提供的四种空间索引：四叉树索引、R树索引、动态索引和图库索引（原三级索引）。
空间索引管理：数据在导入导出，编辑修改后，空间索引可能会破坏，这时就需要对数据集重新计算，建立新的空间索引，以便于进行快速查寻和浏览。
l 创建图库索引（原三级索引）
在 SuperMap SDX + 中根据数据集的某一属性字段或根据给定的一个范围（图幅的长和宽），将空间对象进行分类，通过索引进行管理已分类的空间对象，以此提高查询检索速度。
在创建图库索引功能中提供了提供了两种创建图库索引的方式，字段索引和范围索引。
n 字段索引
即根据数据集的某一属性字段将空间对象进行分类，通过索引进行管理已分类的空间对象，以此提高查询检索速度。建议使用与位置信息相关的字段进行图库索引的创建，例如对于全国县级行政区域图，可以使用表示行政区域代码的字段进行图库索引的创建。
n 范围索引
即根据给定的一个范围（图幅的长和宽）将空间对象进行分类，通过索引进行管理已分类的空间对象，以此提高查询检索速度。对于按标准比例尺分幅存储(如1:25万数据、1:10万数据、1:5万数据等)的数据合并到数据库中后生成的数据集，图库索引有着优异的效果，可以提供非常好的查询性能，与 SuperMap 提供的地图缓存功能搭配使用可以达到更好的地图浏览速度。默认采用数据集长宽各三十分之一的大小进行图库索引的创建。
图库索引目前仅支持的是数据库型数据源中的点、线、面、文本和 CAD 数据集。在使用范围索引时，我们要考虑如何确定图幅的范围。如果对数据集创建了范围索引，每次查询的数据结果都是分块下载到客户端的，如果范围过大，那么下载一块的数据量会比较大，性能范围没有得到提升。一般建议平均每块范围内的记录数在3000-5000之间，这样就可以计算一下，比如2000000条记录的数据2000000/5000=400(20*20)，因此设置数据集长宽个二十分之一就可以了。
另外范围索引最好适用于数据分布比较平均的数据，比如道路、居民地等等。
1.3.5 创建影像金字塔
为减小影像的传输数据量和优化显示性能，有时需要为影像建立影像金字塔。
影像金字塔是栅格数据集的简化分辨率（reduced resolution）图像的集合。影像金字塔技术通过影像重采样方法，建立一系列不同分辨率的影像图层，每个图层分割存储，并建立相应的空间索引机制，从而提高缩放浏览影像时的显示速度。
如图所示的影像金字塔的一个例子，底部是影像的原始最高分辨率的表示，为512×512图像分辨率，越往上的影像的分辨率越小，分别为256×256，128×128，顶部是影像金字塔的最低分辨率的图像64×64，因此这个影像金字塔共有4层，即4个等级的分辨率。显然影像的图像分辨率越高，影像金字塔的等级越多。对于图像分辨率为2a×2b的（a>b）影像，SuperMap中将会为其建立（b-6）+1层的金字塔。
为影像建立了影像金字塔之后，以后每次浏览该影像时，系统都会获取其影像金字塔来显示数据，当您将影像放大或缩小时，系统会自动基于用户的显示比例尺选择最合适的金字塔等级来显示该影像。
为影像建立了影像金字塔可以显著地提高影像缩放显示过程中重画的速度，提高海量影像数据显示的性能，但是同时影像金字塔的建立会增加数据集的存储空间，即增大影像数据集所在数据源（.sdb）文件的大小，这是因为建立的影像金字塔实际上就是影像在不同分辨率下的图像的集合，这些不同分辨率下的图像都和数据一起存储在数据源文件中，从而增大了数据源文件的大小。而且栅格数据集数据量越大建立金字塔的时间越长，影像金字塔的存储空间也就越大，但是会为以后的影像浏览节约了更多的时间，所以对于海量影像数据，创建金字塔不失为一种优化效率的选择。
SuperMap SIT影像文件存储格式是集成了影像压缩及高效的影像金字塔技术的数据格式，因而可以超快速地显示影像数据，与影像数据大小基本无关，即使在很低配置的机器上也能非常流畅地对海量影像数据进行显示。
1.3.6 其它
除了以上优化方式之外，还有一些需要注意的地方：
l 有的线或者面数据虽然在显示时对象很少，但是却相当耗时，这有可能是数据节点太多，有点对象甚至有几十万个节点。这么多的节点并不是冗余的，而可能是某些业务对数据精度有较高要求。如果分析应用中对于数据精度要求并不高的话，可以对数据进行重采样。重采样的数据节点数根据重采样距离有所减少，速度提高的同时在精度上会有所损失。
l 线形反走样的设置可以使线形更美观，但是性能会有所损失。如果数据量较大，线节点数较多的情况下不建议使用线形反走样。
l 尽量使用简单的符号、线形、和填充风格。可以验证一下，比如线形中前几个WIN32 System的线性在性能上就其它复杂的线性效率要高。
把所有图层设置为不可捕捉、不可选择……
1 优化案例
1.1 初始条件
l 数据
矢量数据：以北京市范例数据，需要特别关注居民地图层，记录数176509条。
l 计算机配置
CPU : Intel Core 2 Duo 2.2GHz
2级缓存：4M
内存：2G DDR2
显卡：FX570 512M
1.2 优化步骤
1.2.1 设置地图过滤显示
在新建地图之后，地图属性中就已经默认设置了文本过滤显示。过滤对象尺寸设置默认值，因为需要显示的数据中没有小而碎的数据。
1.2.2 设置图层显示比例
数据在入库之后添加几个图层配置地图，在没有进行任何优化之前，我们测试地图的显示性能。（时间单位：毫秒）
| 图层名称 |
查询时间 |
绘图时间 |
总时间 |
记录数目 |
| 居民地R@北京 |
224.076 |
2598.695 |
2822.771 |
176509 |
| 铁路L@北京 |
11.853 |
395.790 |
407.643 |
667 |
| 面区界R@北京 |
14.275 |
17.798 |
32.073 |
18 |
| 国道L@北京 |
5.454 |
2.297 |
7.751 |
16 |
| 省道L@北京 |
2.929 |
1.099 |
4.028 |
88 |
| 平均 |
51.718 |
603.136 |
654.853 |
35459.600 |
| 总计 |
258.588 |
3015.680 |
3274.267 |
177298 |
表4-1 地图初始状态
图4-1 地图初始状态
在全副状态下，居民地图层记录数最多，有176509条，查询时间比较高超过了200ms，绘图时间很长，那么说明这个比例尺下不适合显示。通过可见比例的设置之后，图层显示更具层次感，同时性能有明显提升。
全副的状态下配置了区域面的单值专题图，测试刷新时间结果如下：
| 图层名称 |
查询时间 |
绘图时间 |
总时间 |
记录数目 |
| 面区界R@北京 |
12.507 |
18.662 |
31.170 |
18 |
| 界线@北京 |
8.004 |
10.789 |
18.793 |
77 |
| 国道L@北京 |
6.167 |
2.405 |
8.572 |
16 |
| 平均 |
8.893 |
10.619 |
19.512 |
37.000 |
| 总计 |
26.679 |
31.856 |
58.535 |
111 |
表4-2 设置显示比例后的全幅效果
1.2.3 重采样
在上一步的基础上进行放大，在第二级比例尺中，发现铁路线数据的绘图时间比较长。
| 图层名称 |
查询时间 |
绘图时间 |
总时间 |
记录数目 |
| 铁路L@北京 |
8.851 |
280.330 |
289.181 |
667 |
| 面区界R@北京 |
164.139 |
22.187 |
186.326 |
18 |
| 界线@北京 |
23.988 |
4.465 |
28.452 |
74 |
| 国道L@北京 |
5.470 |
1.804 |
7.274 |
14 |
| 省道L@北京 |
4.912 |
1.537 |
6.448 |
88 |
| 平均 |
41.472 |
62.064 |
103.536 |
172.200 |
| 总计 |
207.360 |
310.322 |
517.682 |
861 |
表4-3 重采样之前
经过查看实际数据发现是铁路线数据节点数较多，好几条线的节点数超过了2万个。对于这种情况如果只是作为底图使用的话，可以对其进行重采样，或者再进行一下编码压缩。
| 图层名称 |
查询时间 |
绘图时间 |
总时间 |
记录数目 |
| 铁路L@北京 |
6.956 |
160.449 |
167.405 |
667 |
| 界线@北京 |
63.681 |
4.610 |
68.291 |
74 |
| 面区界R@北京 |
15.546 |
20.155 |
35.701 |
18 |
| 国道L@北京 |
5.282 |
2.387 |
7.669 |
13 |
| 省道L@北京 |
2.708 |
1.159 |
3.867 |
88 |
| 平均 |
18.835 |
37.752 |
56.587 |
172.000 |
| 总计 |
94.173 |
188.760 |
282.933 |
860 |
表4-4 重采样之后
1.2.4 建立索引
当地图继续进行缩放几个比例尺发现居民地图层耗时非常大，其中主要是因为查询时间非常长
| 比例尺 |
中心点X |
中心点Y |
||
| 9793.371212 |
449121.418376 |
4421816.002618 |
||
| 图层名称 |
查询时间 |
绘图时间 |
总时间 |
记录数目 |
| 居民地R@北京 |
2495.055 |
27.560 |
2522.615 |
1216 |
| 平均 |
2495.055 |
27.560 |
2522.615 |
1216.000 |
| 总计 |
2495.055 |
27.560 |
2522.615 |
1216 |
表4-5 建立索引之前
同时我们观察到这个数据分布是比较均匀的。
图4-2 居民地数据
所以我们采用创建图库索引的方式进行优化。居民地数据一共有176509条记录，我们可以采用默认的长宽各三十分之的标准创建范围索引。
创建了三级索引之后的结果可以根据上表中的比例尺和中心点坐标，确定和之前的同一个范围的数据做对比，发现查询时间速度提高得相当快。
| 比例尺 |
中心点X |
中心点Y |
||
| 9793.371212 |
449121.418376 |
4421816.002618 |
||
| 图层名称 |
查询时间 |
绘图时间 |
总时间 |
记录数目 |
| 居民地R@北京 |
297.664 |
26.572 |
324.235 |
1216 |
| 平均 |
297.664 |
26.572 |
324.235 |
1216.000 |
| 总计 |
297.664 |
26.572 |
324.235 |
1216 |
表4-6 建立索引之后
1.2.5 设置缓存
虽然对数据创建了三级索引，查询效率提升很多，但是对于当前比例尺下还是有1216个对象要显示出来，放到下一级比例尺才显示该图层也不太适合。这时我们可以设置数据集的用户缓存模式，做进一步的优化。
首先，我们关闭Deskpro，在安装目录下的BIN文件夹中找到supermap.ini文件，查看CacheFilePath = F:/SmCacheFile，设置一个文件路径，并在这个路径下创建一个SmCacheFile文件夹，用来保存用户缓存文件。
重新启动Deskpro，选择居民地数据集，在属性中勾选用户缓存，点击应用完成。通过以上的操作，我们再对同样区域的数据进行浏览，观察测试结果。
第一次浏览时可能会慢一些，因为缓存文件还没有在本地生成，数据还是通过数据库服务器下载到本地的。不过第二次浏览之后的速度就会非常快了，因为数据是从本地读取的。
| 图层名称 |
查询时间 |
绘图时间 |
总时间 |
记录数目 |
| 居民地R@北京 |
1.112 |
18.255 |
19.367 |
0 |
| 平均 |
1.112 |
18.255 |
19.367 |
0.000 |
| 总计 |
1.112 |
18.255 |
19.367 |
0 |
表4-7 居民地最终优化成果
从以上一系列的优化可以说明文本过滤显示、图层显示比例等操作是对地图进行优化的常规武器，对于地图的优化具有普遍意义。而建立索引特别是图库索引结合用户缓存的方式堪称强力武器，实现了两千五百多毫秒直至不到而是毫秒的惊人效果。
2 总结
通过本文的研究分析，我们可以大致确定三个层次的优化策略。
首先是在数据服务端，通过数据库为核心，配套操作系统和硬件环境，实现服务器端的性能优化。
其次是纯地图显示上，通过控制显示比例、过滤显示、数据压缩等方式让地图显示的内容更少、更简单，提高了显示性能。
最后是专业性较强，主要利用数据引擎实现的，通过创建适合的空间索引，用户缓存的方式大大提高查询效率。
总之，优化的方法有很多种，在实际操作时，我们必须要在熟练掌握操作方法，理解方法原理的前提下，才能根据实际情况分析出性能损失的真正原因，对症下药。再通过耐心的调试，最终才能制作出一份既美观，又性能卓越的电子地图来。
相信，随着新技术的不断更新，高性能地图优化策略也会与时俱进，如今的性能瓶颈必定会在新技术、进产品的推动下，被轻松的跨越，成为历史。