专利名称：一种新的空间信息发布样式表处理器的转换方法
技术领域：
本发明属于信息技术中的空间信息获取与处理技术领域，特别是涉及一种新的空间信息发布样式表处理器的转换方法。
背景技术：
地理信息标记语言GML(Geography Markup Language)文档作为包含地理信息的可扩展标记语言XML(eXtensible Markup Language)文档，用于对空间和非空间信息进行编码，可以用来对异构空间数据进行集成。但GML本身不是为显示而设计的，而地理数据的显示又是空间信息发布中非常重要的部分，因此，GML文档需要转换为可显示的格式再进行发布。我们选择W3C推荐的SVG(Scalable Vector Graphics)矢量格式标准。SVG本身也是基于XML的，GML文档转换到SVG格式实质上是将一种格式的XML文档转换成另一种格式的XML文档，可以通过样式表XSLT(XML样式表转换器)实现，通过将编写好的样式表(XSLT)和GML源文件传递给XSL处理器执行而实现的。
我们从一些与XML、XSL、XSLT相关的专业技术网站上(如W3C组织的http//www.w3c.org/Style/XSL/，http//www.w3c.org/DOM/，http//www.w3c.org/XML/，IBM公司的http//www-900.ibm.com/developerWorks/cn/xml/index.shtml等)可以看到，在作XML格式转化时，首先要分别解析两个输入文件源文件，样式表文件。传统的XSLT处理器处理的方法是将这两个文件转换为DOM树存放在内存中，内存中的DOM树的大小一般达到原始数据大小的10倍或以上，这对小数据量XML数据影响不大，如样式表文件一般都不大，不超过几百K字节，将它转化为DOM树并不占用太多的内存和时间，故并不是效率的瓶颈；而GML数据源文件可能很大，可能几十兆甚至上百兆，若转为DOM树，占用的系统资源太多，很容易造成内存溢出。若再加上生成DOM树所占用的CPU资源，用户难以接收这样的转换效率，是XML文件转化时效率的瓶颈。因此，当若源文件过大，采用DOM方式不是一个好的选择。
传统做法对大文件(如几十兆或上百兆)的处理一般不直接采用XSLT处理，而采用另外两种方法一种方法是将数据分成块，通过XSLT分别转换每一块，最后对结果块合并。这样作编程比较容易，适用性较广。但是若数据过大，分块过多，这种方法消耗的时间太长，对于大数据量GML数据处理依然低效。另一种方法是通过编写一个使用SAX接口的应用程序实现XSLT样式表相同的功能。它运行起来速度会比前者快很多倍，效率很高。但基于SAX接口的编程很复杂，扩展性较差。
目前基于上述技术方法的常用XSLT处理器主要是Apache公司的Xalan-java处理器(http//xml.apache.org/index.html#xalan，最近访问时间2004年10月25日)和Michael H.Kay的Saxon处理器(http//www.saxonica.com/，最近访问时间2004年10月25日)。但是相关的实验测试数据表明这些XSLT处理器能够处理的数据量如Xalan对于20MB及以上GML文档无法处理，Saxon对于40MB及以上GML文档无法处理，即GML文档过大，处理器转换过程中产生内存溢出，导致转换失败。
故如何设计一个能高效处理大文档的XSLT处理器，成为高效地将GML向SVG转换的关键。
发明内容
针对上述问题，本发明提供了一种不需要将源文件转换为一棵DOM树的XSLT处理器，避免了生成DOM树所消耗的时空资源以及内存溢出，极大的提高了大数据量XML数据的转换效率，且适用性较广新的空间信息发布样式表处理器的转换方法。
为了解决上述问题，本发明处理器的转换方法是对于GML文档向SVG格式的转换，分别以DOM方式解析样式表文件，以SAX方式解析源文件。
将上述样式表划分为定位信息和结构信息，生成两棵样式表树，在SAX解析器解析源文档时，每遇到一个元素标记就将这两棵样式表树遍历一遍，若是需要的元素就将数据提取出来，如不需要就忽略。
上述具体转换方法是第一步骤对样式表按照定义分片，并按顺序编号；第二步骤将分片按定义划分为两类，一类为第一部分(含定位信息)，一类为第二部分(含输出XML文件的结构信息)；第三步骤将属于第一部分的分片中的每一片，读入一个文件流中，每一片对应一个文件流，产生一个文件流数组；第四步骤将属于第二部分的分片中的每一片，生成一棵DOM树，产生一个DOM树数组，并为每一棵DOM树分配一个文件流，产生一个文件流数组；第五步骤当SAX解析器解析源文档时，每遇到一个元素标记就将DOM树数组中的每一棵DOM树遍历一遍，若是需要的元素就将数据提取出来，并放入相应DOM树对应的文件流中；第六步骤当SAX解析器解析源文档结束后，将第一部分对应的文件流数组和第二部分对应的文件流数组按第一步骤中的分片顺序合并，最后生成的文件流输出就是结果文档。
本发明的特点是以DOM方式解析样式表文件，以SAX方式解析源文件。并且将样式表划分为定位信息和结构信息，生成两棵样式表树，在SAX解析器解析源文档时，每遇到一个元素标记就将这两棵样式表树遍历一遍，若是需要的元素就将数据提取出来，如不需要就忽略。转换算法能够快速地实现XML文档间的转换，并且能够处理大数据量的GML空间信息到SVG的转换。
图1为本发明与两个常用处理器的时间效率对比图。
图2为本发明与两个常用处理器的空间效率对比图。
具体实施例方式
下面结合附图进一步说明本发明。
本发明是将样式表文件以DOM方式解析为一棵DOM树存入内存中，以SAX方式解析源文件。每遇到一个元素标记就将样式表树遍历一遍，若是需要的元素就将数据提取出来，如不需要就忽略。
由于在一般情况下，样式表文件很小，只有几KB或几十KB，生成的DOM树就很小，并且以SAX方式扫描XML文件效率很高，所以本发明处理器处理速度比一般的XSLT处理器速度要快。尤其当源文件数据量很大时，一般的XSLT处理器所消耗的时间是以指数级速度上升，而本发明处理器在样式表确定的情况下，所消耗的时间是以线性速度上升的，这是因为SAX方式扫描XML文件所用的时间随着XML文件大小增加是以线性速度增加的。所以源文件数据量越大，一般的XSLT处理器效率下降的越快，并且达到一定数据量如4兆左右，一般的XSLT处理器无法处理，而本发明处理器就不存在这种情况。
为进一步提高XSLT处理器的效率，可以从两个方面入手一方面提高SAX解析器对XML文档遍历的速度，另一方面对样式表进行优化。由于一般对XML编程都是使用实现DOM接口和SAX接口的软件包提供的API，如Aparche公司提供的Xerces包，IBM公司的DOM4J包，SUN公司的JDOM等产品。一般的XSLT处理器都是以这样的一些产品为开发平台作二次开发，如应用相当广泛的XSLT处理器——Xalan处理器就是基于Xerces包开发出来的。这些软件包对于SAX接口的支持和SAX解析器的执行效率虽然略有不同，但差距不大。所以，通过提高SAX解析器对XML文档遍历的速度来提高XSLT处理器的执行效率不是一种有效的方法。
本发明处理器在作转换时，当通过SAX解析器遍历源文件时，每遇到一个元素标记就将样式表树遍历一遍，故样式表树的大小对本发明处理器的执行效率有相当大的影响。尤其当源文件相当大时，即源文件的元素相当多，如十万或几十万个元素(也许这对传统的XML应用中的XML文档来说这种情况相当少见，如电子商务中的XML数据一般只有几十个或几百个元素，这对于GML文档来说是相当常见的)，若样式表树能在不影响它的功能的情况下有效的缩小，则本发明的执行效率会得到极大提高。对样式表进行优化是提高本发明处理器执行效率的一种有效方法，本发明通过对样式表的结构进行分析，设计了一种样式表转换方法。
样式表文件由两部分组成，第一部分是对源文件相应数据的定位信息，即由XSL规范所定义的有从源文件定位数据功能的标记(如xslfor-each、xslvariable、xslcopy-of、xslvalue-of等)所构成的节点，以及包含在这些节点中的非XSL规范所定义的元素。第二部分是输出XML文件的结构信息，不符合前一部分要求的并且属于结果文档标记的所有元素。两部分在整个XSLT处理过程中起不同作用，样式表的第二部分只与结果文档有关，与源文档无关；样式表的第一部分因为有数据定位的功能所以与源文档密切相关。本发明处理器时空消耗最大的部分，在于以SAX方式解析源文档，并通过样式表的数据定位功能提取数据的过程。在这个过程中样式表树越小效率越高，而整个样式表中真正参与到这个过程当中的只有第一部分，第二部分完全与之无关。所以没有必要将整个样式表转化为样式表树，只需要将第一部分转换为树参与此过程即可。所以，本发明将样式表生成两棵样式表树，在SAX解析器解析源文档时，每遇到一个元素标记就将这两棵样式表树遍历一遍。
为了测试本发明的性能，我们选取了1MB-50MB之间的14组GML空间数据，采用相同的样式表，在相同的机器上，分别用目前最常用的XSLT处理器--Apache公司的Xalan-java处理器、Michael H.Kay的Saxon处理器与本发明做对比实验。表1是对三个处理器的测试数据和测试结果，一共14组数据。表1中Method列中Xalan表示Xalan-java处理器，Saxon表示Saxon处理器，Name列表示图层名；GML、XSL、SVG列分别表示GML、XSL、SVG文件的大小；TotalTime列表示GML文档转换为SVG图所消耗的时间，单位为ms；Memory列表示GML文档转换为SVG图所消耗的内存，单位为MB。
表1
从表1可以看出，在Xalan和Saxon实验结果中的SVG列中有若干项为零(如Xalan对于20M及以上GML文档无法处理，Saxon对于40M及以上GML文档无法处理)，表示GML文档过大，使用处理器会产生内存溢出，导致转换失败。而本发明处理器不存在这样的问题。图1是三个处理器对14组测试数据转换所耗时间的曲线图。纵坐标表示时间，单位为ms；横坐标表示GML文档大小，单位为MB。图2是三个处理器对14组测试数据转换所耗内存的曲线图。纵坐标表示所耗内存，单位为MB；横坐标表示GML文档大小，单位为MB。两个图中最下面的一条线表示本发明处理器的执行结果；图1中间的一条线、图2上面的一条线表示Saxon处理器执行结果；图1上面的一条线、图2中间的一条线表示Xalan处理器执行结果。从图中可以看出本发明处理器的时间效率和空间效率都比Xalan处理器和Saxon处理器好，而且对于10M以上的大文档本发明所耗的内存基本上呈线性增长。
本说明书中未作详细描述的内容属于本领域专业技术人员公知的现有技术。
权利要求
1.一种新的空间信息发布样式表处理器的转换方法，其特征在于对于GML文档向SVG格式的转换，分别以DOM方式解析样式表文件，以SAX方式解析源文件。
2.如权利要求1所述的新的空间信息发布样式表处理器的转换方法，其特征在于将样式表划分为定位信息和结构信息，生成两棵样式表树，在SAX解析器解析源文档时，每遇到一个元素标记就将这两棵样式表树遍历一遍，若是需要的元素就将数据提取出来，如不需要就忽略。
3.如权利要求1或2所述的新的空间信息发布样式表处理器的转换方法，其特征在于第一步骤对样式表按照定义分片，并按顺序编号；第二步骤将分片按定义划分为两类，一类为第一部分(含定位信息)，一类为第二部分(含输出XML文件的结构信息)；第三步骤将属于第一部分的分片中的每一片，读入一个文件流中，每一片对应一个文件流，产生一个文件流数组；第四步骤将属于第二部分的分片中的每一片，生成一棵DOM树，产生一个DOM树数组，并为每一棵DOM树分配一个文件流，产生一个文件流数组；第五步骤当SAX解析器解析源文档时，每遇到一个元素标记就将DOM树数组中的每一棵DOM树遍历一遍，若是需要的元素就将数据提取出来，并放入相应DOM树对应的文件流中；第六步骤当SAX解析器解析源文档结束后，将第一部分对应的文件流数组和第二部分对应的文件流数组按第一步骤中的分片顺序合并，最后生成的文件流输出就是结果文档。
全文摘要
本发明涉及一种新的空间信息发布样式表处理器的转换方法。本发明以DOM方式解析GML样式表文件，以SAX方式解析GML源文件，并且将样式表划分为定位信息和结构信息，生成两棵样式表树。在SAX解析器解析源文档时，每遇到一个元素标记就将这两棵样式表树遍历一遍，若是需要的元素就将数据提取出来，如不需要就忽略。本发明的特点是能够快速地实现XML文档间的转换，并且能够处理大数据量的GML空间信息到SVG的转换，实现空间信息的发布。
文档编号G06F17/30GK1614592SQ20041006118
公开日2005年5月11日 申请日期2004年11月25日 优先权日2004年11月25日
发明者关佶红, 周水庚, 边馥苓, 陈俊鹏, 张俊, 张建华 申请人:武汉大学