关于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同仁一起探讨!

转载自:https://blog.csdn.net/zhouxuguang236/article/details/17041341

You may also like...