OpenLayers学习

"OpenLayers学习" OpenLayers是美国ESRI公司开发的一种空间数据开放格式，目前许多空间数据都以此格式进行存储、管理、共享，这证明了shape格式的实用性，也侧面证明了ESRI公司的实力和影响力。Shapefile格式保存了图形的矢量信息和其属性信息，一般由以下几个文件组成： * .shp - 存储空间几何对象。 * .shx - 存储空间几何对象在*.shp文件中偏移索引。 * .dbf - 存储空间几何对象的属性信息。 除了以上三个文件格式之外，还可以有其它文件的支持，这样能够优化访问数据库的性能： * .sbn 和 .sbx - 空间几何对象空间索引。 * .fbn 和 .fbx - 存储只读空间几何对象空间索引。 * .ain 和 .aih - 存储列表中活动字段的属性索引。 * .prj - 保存空间参考信息。 * .shp.xml - 保存的元数据。 关于*.shp、*.shx、*dbf 文件的读取，可以去网站http://shapelib.maptools.org/下载源代码进行研究。shapefile文件格式的白皮书可以去网站http://dl.maptools.org/dl/shapelib/shapefile.pdf下载 在使用OpenLayers时，需要注意以下几点： 1.利用SHPObject对象时，每次都对Z、M值进行了分配空间，开发人员可以自己修改shapelib库源代码，在没有M、Z值情况下不分配内存空间； 2.开发者重写函数一个读取函数：SHPReadObject( SHPHandle hSHP, int iShape, SHPObject obj)，obj对象不必每次读取都重新重复分配内存，只有在上一个对象占用的内存空间小于此次读取对象时再重新分配空间； 3.修改SHPObject结构，将顶点坐标的x、y值交互存放，和物理存储位置一致，例如：x1 y1 x2 y2 x3 y3...； 4.利用quadtree进行空间搜索，加快空间数据搜索速度； 5.完全重新设计SHPObject结构，使其与自己系统的空间数据对象一致，再重新开发shapeobject读写函数，自己从文件中解析数据，直接形成自己的内存数据结构去分析、绘制等工作，而不是利用ShpObject进行中转； 6.注意shapefile格式中的Polygon，是拥有对个环的Polygon，环间可以嵌套形成洞、岛等现象，虽然ESRI规定，换走向的右侧为Polygon内部，但很多时候shapefile的存储并未遵守这一规则，而且环的存储顺序也很混乱，即：内环不一定紧随其外环存储，在读取中特别注意。 此外，warmerdam这位老仙儿，在shapefile读取库中，加入了quadtree的支持。但是，如果你把这些代码独立编译成dll，然后去调用会出现问题。SearchDiskTree()中要求传入的是FILE*，而这个参数是在你的工程（DLL或EXE）中打开的，程序运行时崩溃。最好在shapelib中添加一个函数SearchDiskTreeEx()，改为传*.qix文件名吧。 在shptree代码中，有分配内存的函数，却没有回收内存的函数，也需要自己添加一个，避免不同空间中非配、回收内存。 OpenLayers也可以用来解析GML文件，但是存在一些问题，例如低效率的问题，对于一个像美国states的gml文件，大小约为300K左右，有95个面对象，所有面对象一共包含11000个左右的点，这么一个gml文件，不算从WFS请求过来的时间，就是放在本地就用OpenLayers脚本解析，耗时也在10s以上，虽然这里机器不太好，属于上个世纪的戴尔机器，内存256，CPU2.8G，但是这么长的耗时实在是说不过去。后来试用精简了的武汉数据，大小大概400K，只有一个面对象，不过这个面包含很多个点，16145左右，从WFS请求，结果在客户端根本就画不出来，IE死掉了。后来查看OpenLayers解析gml数据的代码，很容易就可以发现问题。OpenLayers对于Geometry对象的组织是这样的，其实最基本的就是点，然后MultiPoint由点构成，继承自OpenLayers的Geometry对象。