关于OGR开源库的一些思考

        很久没有写博客了，今天趁着周末有时间，就将我使用OGR的体会做一下总结。

        我想你如果正在看这篇文章的话，你应该知道OGR是干什么用的。说白了OGR就是读取各种矢量数据的一个开源的抽象库，其实OGR本身没有读取数据，最终读取基本上都是试用各种数据格式的原生API来实现的。例如，读取shapefile文件就是用到了shapelib这个库，这个库就是C语言的，非常简洁好用。大家都说这个GDAL/OGR好用，但是这个库本身还是存在着一些坑的，所以进行数据读写的时候要注意这些坑。究竟有哪些坑，下面我就来列举下。

     1、获得图层的要素个数

      图层类的获得要素个数的接口定义如下：

   

int OGRLayer::GetFeatureCount( int bForce )

{
    OGRFeature     *poFeature;
    int            nFeatureCount = 0;

    if( !bForce )
        return -1;

    ResetReading();
    while( (poFeature = GetNextFeature()) != NULL )
    {
        nFeatureCount++;
        delete poFeature;
    }
    ResetReading();

    return nFeatureCount;
}

从上面的定义可以看出，参数bForce如果为true的话，就直接给你返回-1，这实在是坑，还有，如果传参数true的话，那很遗憾的告诉你，它就必须遍历整个图层才能获得要素个数，这种设计在我看来其实不是很合理，一般数据格式都会记录要素的个数信息，我不知道OGR这样做是为什么，不懂，求解答！

 

      2、读取mapinfo的数据时候要小心

      mapinfo内部格式的FID是从1开始的，如果你使用GetFeature接口读取要素的话，对于shapefile数据没问题，可以正确读取。然而你正在读取mapinfo tab数据时，GetFeature（0）你就获取不到数据。我在想既然OGR是一个抽象库，为何不在上层提供统一使用的方法。其实mapinfo的数据底层是使用了mitab开源库，这个库的在解析mapinfo的数据依赖OGR库，我想对于FID的问题就适合在这个库中进行处理。以前编译过这个mitab库，我觉得非常不错，提供给用户的是简单的C语言接口。

 

      3、个人建议在OGRLayer类中增加类似OGRGeometry* GetGeometry(int nIndex)的接口

        假如我们现在只需要显示数据，那么我们就只关心空间数据了，然而属性数据在这时候就不是我们关心的对象，GetFeature是读取了空间数据和属性数据，这就带来了程序的内存开销会大一些，而提供一个类似的只获取图形数据的接口，或许这样更美。对于属性数据也是，建议在OGRLayer类中单独增加一个接口读取属性数据。

      对于上面的一些感慨和建议纯属个人意见，也欢迎各位GIS同仁一起探讨！