OpenLayers是一个非常不错的开源的GIS库，纯js编写。我实习的公司原本打算开发一套自己的客户端API，在开发过程中发现OpenLayers的设计和我们自己的设计有很多相似的地方，而且OpenLayers本身已经比较完善。所以在后期，我们放弃了自己开发的API，转向了OpenLayers，结合我们已经开发的那一部分，将OpenLayers的修改成符合我们需求。
目前大部分地方完成了，现在的主要工作是性能优化，特别是对于VML渲染速度的优化。研读了一下OpenLayers的关于VML渲染的代码，发现它的设计虽然比较完善，但是在代码的执行效率上还有很多需要改进的地方。
1、由于OpenLayers对于Geometry的层层套嵌的组织方式，导致Geometry.Point执行的次数太多，而prototypejs那种Class和initialize的方式可能比较慢（没具体测试过），所以这里来是一个可以改进的地方。要么将Geometry.Point改成原生的Function方式来声明，要么直接在Geometry.Polygon这样的类中不使用Geometry.Point。
2、在由Geometry转化的过程中，拼path串时，OpenLayers采用的是path+="abc"这样的方式，这时目前导致效率低下的第一原因。将这种方式改为path.push("abc")然后path.join(" ")这种方式之后，整体效率大大提高。
3、对于点没有进行去重复的处理。即当一个Geometry转化程屏幕上的VML时，有很多点是重合的。
4、即使一个Geometry不在viewPort范围之内，OpenLayers仍然会画出一个Geometry。不过这又分出两种情况，一种情况是整个Geometry都不在范围内，二是只有部分不在范围内。对于第二种情况的处理比较麻烦。
暂时总结这么多吧。
目前大部分地方完成了，现在的主要工作是性能优化，特别是对于VML渲染速度的优化。研读了一下OpenLayers的关于VML渲染的代码，发现它的设计虽然比较完善，但是在代码的执行效率上还有很多需要改进的地方。
1、由于OpenLayers对于Geometry的层层套嵌的组织方式，导致Geometry.Point执行的次数太多，而prototypejs那种Class和initialize的方式可能比较慢（没具体测试过），所以这里来是一个可以改进的地方。要么将Geometry.Point改成原生的Function方式来声明，要么直接在Geometry.Polygon这样的类中不使用Geometry.Point。
2、在由Geometry转化的过程中，拼path串时，OpenLayers采用的是path+="abc"这样的方式，这时目前导致效率低下的第一原因。将这种方式改为path.push("abc")然后path.join(" ")这种方式之后，整体效率大大提高。
3、对于点没有进行去重复的处理。即当一个Geometry转化程屏幕上的VML时，有很多点是重合的。
4、即使一个Geometry不在viewPort范围之内，OpenLayers仍然会画出一个Geometry。不过这又分出两种情况，一种情况是整个Geometry都不在范围内，二是只有部分不在范围内。对于第二种情况的处理比较麻烦。
暂时总结这么多吧。
